Waterfall Development Life Cycle
Sequential software development life cycles are characterized by processes which proceed from project initiation in a series of sequential steps to release and maintenance of a software product (Bruegge & Dutoit, 2010, p. 637). Traditionally, sequential life cycles are characterized by the Waterfall software development life cycle which can be summarized in seven sequential steps; 1) project initiation, 2) requirements, 3) design, 4) construction, 5) testing, 6) release, and 7) maintenance (Ahmed, 2011, pp. 132-133). Throughout the development process, documentation is used to guide processes and artifacts are generated at each phase.
Project Documentation
A project artifact represents “a component of the software product, such as a specification document, a code module, or a manual” (Schach, 2011, p. 18). Artifacts, some of which are code and some of which are not, constitute integral components of the software product. In addition to artifacts, processes within the development process can be monitored with reports consisting of metrics measuring project, process, or product quality characteristics (Schach, 2011, pp. 133-134). As the diagram in Attachment A illustrates, artifacts and metrics are developed and utilized at each phase of the development life cycle.
Project Initiation
Artifacts generated at project initiation include the project charter, scope, objectives and project plan. In preparation of the project plan, measures of resources, cost and timeline are developed using effort-based and activity-based approaches. A project management plan is also produced which sets forth key metrics and reports which will be used throughout the project. Project management metrics and reports include;
- Action Items. Action items will be generated at each phase of the development life cycle and for each action item the date originated, the person or area responsible for addressing, and the date if was effectively resolved will be recorded (Lee, 2020).
- Project Cost. As project costs accumulate, they will be reported and compared to budgeted cost for the project at that phase (Schach, 2011, p. 134).
- Person-Months Report. Actual person-months to complete the software product will be compared to those budgeted in original effort and activity estimates (Schach, 2011, p. 134).
- Test Backlog. The test backlog report will not be populated until completion of the test plan in the testing phase. However, project managers see the testing process as a key to quality and wish to be updated on this report as soon as it is available.
- Active System Users. The ultimate measure of success is the number of active users of the new employee tracking system. This report will first be populated after the first release of the product.
- Customer Bug Reports. As a measure of ongoing quality, the bugs reported by customers, along with resolutions, will be tracked once the initial release has been completed.
- Stage Gate Reviews. Certain transition points are critical for determining the on-track status of the project, offering a critical point to review the progress of the project. These are referred to as Stage Gate Reviews (Department of Health and Human Services, 2012) and are scheduled to be completed after project initiation, design, and testing phases.
Requirements
The primary artifact of the requirements phase is a comprehensive requirements document detailing specifications for functional and non-functional requirements. Additionally, requirements change control procedures are established for the project at this point. An important characteristic of the requirements workflow “is how rapidly the requirements team determines the client’s real needs” (Schach, 2011, p. 353). When requirements are initially developed, review and approval is required by stakeholders before moving on to system design. Consequently, the number of requirements changes during this phase captures how quickly the developers captured project needs. The project action item report also becomes an active reporting tool at this phase of development as well.
Design
The design phase of develop begins with use-case specifications, entity-object identification to the development of use-case sequence diagrams and an overall system class diagram including necessary classes and packages within the software system (Bruegge & Dutoit, 2010, pp. 173-255). Once the system has been designed, the number of modules, classes, and couplings can be useful metrics (Schach, 2011, p. 490). The number of modules and classes can be compared to initial estimates used in the effort-based estimation of person-months and overall project cost. Once the flow diagrams are complete for the system, cyclomatic complexity can also be calculated to determine the overall system complexity (Schach, 2011, p. 490). Measures of code content and complexity should both be evaluated in light of those used during the project initiation cost and timeline estimation phase.
Once the complexity and effort levels have been determined, comparisons to those used in original project estimates will be collected into a Stage Gate Review document for approval from stakeholders before proceeding to the development phase.
Development
The development phase will require first guiding artifacts for coding standards, activities mapping, and resource assignments. Test-Driven Development (TDD) as summarized by Martin (2009, pp. 122-132) will provide guiding principles for the development of code. Additionally, the development team will be given coding standards for code formatting, architecture, coding best practices, non-functional requirements and object-oriented design principles (Gutha, 2015). During code construction, weekly code reviews and inspections will be conducted. An important measure of coding quality is the defect rate measured with defects discovered on weekly inspection. Another relative measure to be used by the project will be the code churn rate, a measure of how often the developer needs to redo lines of code (Stackify, 2017).
Testing
The first artifact for the testing phase is guiding documentation for testing efforts, a test plan, which includes unit testing, integration testing, system testing, and user use-case testing plans (Bruegge & Dutoit, 2010, pp. 451-471). As tests of the software are performed, results will be recorded in a comprehensive testing report. For each test performed, the record will note the date the test was originally planned, the date the test was run, and whether or not the test passed. A test backlog report will be maintained to reflect the number of scheduled tests which have yet to be performed. Moreover, as individual defects are identified with failed tests, resolution of the defect will be included in a defect tracking report (Ahmed, 2011, p. 196).
Once testing of all functional and non-functional specifications have been completed, a testing report will be included in a Stage Gate review document for stakeholder approval before the project will proceed to the release phase.
Release
Prior to the actual release of the product, the first artifact of the release phase will be a user manual and an online tutorial for how to use the employee tracking software (Ahmed, 2011, p. 203). Additionally, in anticipation of user bug reports upon release, a change control procedure should be established for changes which may be necessary after release. The metrics for the release phase will include an implementation report tracking the number of users trained through the online tutorial, the number of planned users of the system, and a record of the number of users actually using the system.
Maintenance
With the change control procedure developed pre-release, the maintenance phase involves receiving customer bug reports, verifying bugs, and resolving bugs in the software wherever possible. The project action item report will also include customer bug reports and resolutions.
Storage
For the employee tracking application, stakeholders, project managers, and the development team will all need ready access to project documentation, artifacts, and metrics. Artifacts including completed code will be maintained on a dedicated project location in GitHub (2020). GitHub offers project management tools which will allow project managers to designate access to different artifacts based on team member roles and responsibilities. Additionally, GitHub also offers add products to facilitate code reviews, change control, and version control.
Summary
The Waterfall software development life cycle, while simple in purpose and appearance, requires a systematic approach to documentation of artifacts and project metrics. This article has reviewed the scenario of a proposed employee tracking application. The artifacts, metrics, and review documents suggested herein offer a path to development which includes an ongoing monitoring of project, product, and process quality. Seven project quality tools are suggested for monitoring throughout the project. Process quality tools ranged from code complexity for overall system design to code defect rates and code reviews. Finally, product quality is addressed through metrics in testing, release, and maintenance phases. The unresolved customer bug report will provide an ongoing measure of quality during the maintenance phase. Documentation for the project, including all artifacts, metrics, reports, and completed versions of the product will be maintained at a central repository on GitHub.
Project Artifacts by Life Cycle Phase
