If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

The software development cycle is composed of six (6) major phases. As a Technical Writer, I usually end up writing about a software module after it has been tested, but that is not always the case. Many times architects or others in management will ask me to create a “dummy” document that will spell out the details of how the system is to look, at least from the GUI perspective. Also, architecture and management are interested in having quality specifications determined before programming actually starts. So, yes, Technical Writing and Software Documentation are usually the “caboose” of the software development cycle, however, there are always exceptions to the rule.

Phase One: Determining the problem to solve. All software systems have been designed to help the user solve a problem or accomplish a task. This is why we have today great programs like Microsoft Office and Microsoft Developer Studio, not to mention the many open-source alternatives that exist as well. Again, the most important step is this step because one needs to clearly define the reason behind developing a software module or system.

Phase Two: Architecture. Software architects design the specifications in which code must be written. Architects determine the platform, scope, size, and depth of programming and how all aspects of the system are to communicate. The program could be a simple desktop application or it could also be a sophisticated system with a front end GUI, intermediate code, and back-end database with tables and more.

Phase Three: Programming. Once architecture has established its parameters for the system, developers next begin to code the system. It is good for programmers to insert meaningful comments in their code so that different programmers can work on the same module. Also, system documentation can be generated from these comments to provide further support for the modules as they unfold in development.

Phase Four: Quality Assurance. After all programming is done, testing is the key to ensuring that the logic of the code is strong and that there are no bugs that will affect the user. Sometimes as a Technical Writer I have to help QA write testing scripts so that the integrity of the system is really determined accurately.

Phase Five: Documentation. As mentioned above, this is the usual time at which software is actually documented and presented in the written word. Today there are many great tools to create a nice user manual or on-line help manual for those using the software. There is nothing more frustrating than trying to use a software program and simply getting stuck. This is where the Tech. Writer comes in and saves the day.

Phase Six: Implementation and Customer Feedback. At this point, all bugs have been worked out and all documentation for the program is done. The application or system simply needs to be implemented and then the user can begin putting the program to use. After the user has really put the system to work, he or she can then contact the software vendor and give some meaningful feedback. As a Tech. Writer, I have also helped to create installation guides so that users successfully install the software on their computers, and in this way they can access all options available within the system successfully.

Tags: Collaboration, Writing //