Project Lifecycles in Computer Science

In Computer Science, there are established approaches to managing projects, which vary depending on the type of project. Within these projects, writing is a crucial element. For example, written documentation will be needed for a new computer network, database, a data analytics project, a software system, etc. This chapter will consider a software development project for demonstration purposes. Keep in mind that while there are many other types of projects in the field, the steps to manage CS projects generally follow similar principles as the example we will explore here.

The Software Development Lifecycle (SDLC) is a well-defined set of steps commonly used to organize and manage software projects. Figure 4.2 provides a visual representation of the SDLC.

Following Figure 4.2, the steps of the SDLC are as follows:

1. Gather Requirements
   • Various approaches are used to gather project requirements, such as interviews, data sampling, user observation, surveys, brainstorming, use cases, focus groups, and prototyping to gather details about the project to develop a formal requirements document. This document will include all technical information determined by the requirements gathering process. Requirements documents will be examined in detail in the next section of this chapter.
2. Research the Domain
   • Understanding the project’s domain involves research to ensure that the development team is familiar with the basis of the project within the context of the business or problem. Examples of this might include educating the developers about the specific types of data that will be processed with the software, business rules, calculations, workflows, thresholds, and decisions that the software will need to handle in the business context—notice Figure 4.2, the dashed line that directs the flow back to requirements. In learning the domain, there are occasions when questions arise that require the process to return to the requirements step for clarification or additional information.
3. Propose a Solution
   • The development of a proposed solution combines the requirements and domain research to create a Project Proposal Document (PPD). The PPD is written with a non-technical audience in mind. This document includes summarized findings from requirements gathering, diagrams, images, and possibly videos to provide the non-technical audience with a clear understanding of the proposed solution. We will examine the PPD later in this chapter.
4. Customer Approval
   • Once the proposal is complete, it is presented to the customer for review and approval. This often involves written communications in electronic messaging, meeting agendas, presentations, and acceptance documents. In some cases, proposals are competitive; they are submitted in response to the customer’s request (RFP). This is called a bid process. If this is the case, the customer will select one of the proposals as the winner of the bid process. Notice, again, that Figure 4.2 indicates that the flow of the SDLC process may need to return to requirements gathering. This is often when the customer reveals additional requirements and changes during during this approval step.
5. Development (Coding)
   • When the customer accepts the proposal, writing the code for the solution may begin. Computer programming involves a great deal of writing―not only writing the code in the programming language(s) of choice, but also writing comments (non-executable statements) within the code that document its logic and maintain ongoing project management documentation, usually stored inside a project management software system. This development step is critical in the SDLC when changes may be necessary. Figure 4.2 indicates the possibility of returning to requirements gathering. While all the planning may be detailed, implementing the idea may also reveal challenges. All of the details of these challenges are recorded in writing in the project management system for review by development managers and the customer for resolution.
6. Testing the Solution
   • As components of the software system are developed and coded, they are forwarded to a testing team to test the solution. Test Engineers write additional documentation detailing the test procedures and their testing steps, outcomes, and recommendations for corrections or improvements. This documentation is shared with the programmers and managers. Steps 5 and 6 are often iterative; that is, Programmers and Test Engineers work together to produce the most accurate coded solution possible that usually involves a repeated cycle of coding and testing. Because of this, as indicated in Figure 4.2, the process may circle between these two steps for some time. Ideally, during this loop, both the programmers and testers write notes in the project management software to document their process, observations, solutions, and progress.
7. QA the Solution
   • When components have been successfully tested and signed off by the testing team, they advance to Quality Assurance (QA), where QA Engineers validate the functionality with the documented requirements, business rules, and user feedback. Throughout their process, QA Engineers continuously update project documentation with notes regarding the outcomes of their evaluations. Like the loop between Steps 5 and 6, the QA process could also cause the process to return to the programming teams for adjustments. Written documentation is critical to track changes, maintain transparency among the groups, and keep all interested parties informed.
8. Demonstrate the Solution to the Customer
   • At this point in the process, software components are presented to the customer; this step is often called a user demo. During the demo, customer requirements from Step 1 of the SDLC are shown in the context of the working solution. During the demo, customer responses, questions, and requests for changes are documented in writing and recorded in the project management system.
9. Respond to Customer Feedback
   • Based on the demo results in Step 8, the team will respond accordingly. If the customer approves of the solution, the SDLC can continue to the next step. However, if the customer disapproves of the resolution, many possible steps may need to be taken. Figure 4.2 depicts one example of returning to the development step for changes to the solution. This is only one example, however. It is possible to return to any previous action depending on the circumstances. In any case, written documentation of the customer’s feedback and recommendations are carefully documented in the project management software system. That documentation is then used to respond to the customer’s feedback accordingly.
10. Merge Solution into Production System
    • When the customer accepts the solution, the software developers communicate with other teams in the IT Department who are responsible for deploying the software. Deployment is the process of merging a solution into the production system. The merge step is intermediate and used to confirm that the new solution will function properly before releasing it to users. These steps are documented in the project management system to maintain an audit trail.
11. Release the Solution to Production
    • When the software is released into the production environment, version and installation details are documented to maintain a consistent record of updates and changes to the system. This is often when user documentation is also written or updated and released for users and help-desk technicians to use as reference.
12. Maintain the Solution
    • Over the lifespan of the software, documentation is maintained, updated, and changed as bugs are reported, changes are requested, and updates are applied to the system. When changes are needed, steps of the SDLC will begin restart where appropriate. Figure 4.2 depicts an example of returning to the development step for a change. In this scenario, all of the SDLC steps that follow will be taken as outlined above, including the written documentation to record the changes, results of testing, etc.

As you can see from this overview of the SDLC, writing is a critical part of each process step. A fully realized SDLC project will involve various forms of writing throughout each SDLC step. Depending on the scale and complexity of the project, the project’s duration can vary widely from a few weeks to many years.