There is a different way to produce a document alike SDLC (Software Development Life Cycle) known as DDLC (Document Development Life Cycle). In an enterprise, DDLC is a common methodology to create documents. DDLC and SDLC work abreast. There are different types of documents for each phases of SDLC. However, in this blog we will dive deeper into the phases of DDLC and tools used for each phase. Until now, you have just read what DDLC is but this article will practically guide you through each steps.
From the diagram below, we can deduce there are 5 phases in DDLC. They are:
1. Documentation Research and Analysis
2. Documentation Design
3. Content Development
4. Editing, Proofreading, and Peer review
5. Publishing and Maintenance
1. Documentation Research and Analysis
In this stage, a technical writer gathers necessary information about the scenario for what they will be documenting. In an enterprise each product phase is tracked using a ticketing tool like JIRA. A ticket is assigned to a technical writer, elaborating on the issues, enhancements, bug fixes, or new features. A technical writer can collaborate with developer, quality assurance engineer, engineering manager, subject matter expert, product owner, and the main client through ticket. From the given information, a mental map is built on what should be included in a technical guide.
It usually takes 2-3 hours to understand the overall scenario, however, the time limit varies based on the issues linked to the JIRA ticket. The best part about JIRA is you can log numbers of hours spent to complete the task. This helps the team lead to keep track of your progress. Furthermore, there are requirement specific documents and design documents. The template for these documents are maintained in Confluence. Confluence is a cloud-based collaboration platform used as a knowledge base to store information and can be accessed remotely.
So, how to get started if you are new to documentation research and analysis? Firstly, get acquainted with the pdf generating tool like Sphinx, DITA, etc. Then, read the style guide to understand the tones and grammatical rules for creating a standard guide. Next, review templates for technical guides and prior technical guides if available. Then try to understand the the JIRA issue and the type of technical document requirement(s) like release note, manuals, guides, or how-to-videos. Sounds tedious? Keep calm, you will soon start to enjoy the process.
2. Documentation Design
Most of the enterprises have fixed style guides and template for documents. As a technical writer, it is mandate to understand the style, tone, word range, and grammatical rule. While working, you will be experiencing "redundancy" and constrained sentences, word range, vocabulary, and format, which can be overwhelming. In the case of documentation design, a technical writer consult with a product team, product owner, engineering manager, and lead architect to discuss the content structure.
Furthermore, the tools used to design technical documents includes, pdf generating tools and markup language Sphinx and reST, image editing tool Snagit, video editing tool Screenflow, and grammar accuracy measurement tool like Grammarly. The generated manuals are stored and maintained using the versioning control system in GitHub. This is where the concept of "DOC as Code" comes into effect. Interestingly, documents are made available in a centralized repository and some are open source, where readers can contribute and recommend changes.
3. Content Development
The design of a content depends upon the task assigned in the JIRA ticket. For every bug fix or enhancement or release of new applications, writers develop content including, release notes, manuals, blogs, videos, etc. Additionally, writers also update the rule book. To develop the content you use the same tools dicussed in the documentation design section.