State Waterfall SDLC –The State’s (previous) Waterfall System Development Life Cycle (SDLC) model was a ten-phase methodology intended to reduce the risk of project failure through the application of a plan driven development process. This methodology established procedures and practices governing the initiation, definition, design, development, deployment, operations, maintenance, enhancement and eventual retirement of the automated information systems.

However, with proven results of a value driven solution delivery, providing value early in a project and lower costs, the State’s Waterfall SDLC is no longer supported. This SDLC was previously developed to include tailored content for commercial-off-the-shelf (COTS) implementations, hardware upgrades, multiple release projects, expanded role definitions, glossaries, and acronyms. Agencies are reminded that technology projects should be built on solid business processes, and the work to define business processes and rules is as important as the technology that supports it.

The State’s (previous) SDLC waterfall model was characterized as a plan-driven software development methodology. A plan driven model was traditional engineered with systematically well-defined processes. Careful up-front, long drawn-out planning, lengthy requirements, requirements traceability and testability, and acceptance criteria were paramount. This plan-driven methodology was characterized by strong documentation and detailed traceability of requirements through design, code, testing, and implementation. Waterfall development was generally considered to be the least risky development model, which made it popular for large software development projects, particularly in the government sector.

While the traditional SDLC waterfall model seemed complete, and comprehensive to most statewide mission-critical systems, it also had drawbacks. When too strictly applied, excessive emphasis was placed on documentation, and the true objective of the project became inadvertently subordinate to the process. Also, waterfall projects were time consuming, and functionality was not delivered until the end of the effort, which resulted in lower value to the agency as business needs were not met, leading to frustration for the development teams and end users.

A decision to adopt a waterfall methodology should not be taken lightly, and most important, should not be imposed by a potential solutions vendor. Agencies electing to use the previous Waterfall SDLC or a plan driven alternative need to seek approval by DoIT prior to Initiation.

Plan Driven Alternatives

Incremental Waterfall – The incremental waterfall methodology has the same first three to four phases as the traditional waterfall model, but it deviates for phases five through ten by creating mini releases and segmenting requirements into an incremental series of products, each of which is developed fairly independently from the others. Incremental waterfall is highly dependent on the development of a complete up front set of requirements, designed and implemented in a series of smaller projects or releases. Each increment adheres to the waterfall sequence.

The incremental waterfall methodology’s benefits include:

• Lower cost and less time required for first release
  
• Focus on essential requirements, thereby reducing the amount of unnecessary functionality
  
• Less risk inherent in developing smaller, more manageable systems represented by increments
  
• Possible reduction in the number of developers
  
• Possible decrease of user requirement changes because of the faster time to first release
  
• Possibility for incremental funding
  
• Phase-level control
  

 The disadvantages of incremental waterfall include:

• Longer-term commitment from stakeholders/business
  
• Additional effort to implement more rigorous project management controls
  
• Additional effort and costs associated with increased regression testing
  

 Incremental waterfall may be utilized when:

• Functionality of the application can be broken down into meaningful products
  
• Stakeholders are available and committed to support the project through all iterations
  

Spiral Models – The spiral model decomposes a large single development cycle of a single phase waterfall into multiple smaller development cycles, each cycle building on the previous one. In spiral development, the end requirements are unknown prior to first release execution. Usually referred to as the “build a little, test a little” approach, it is best suited for projects that have unclear requirements and necessitate only moderate changes. Since unclear requirements are unacceptable on State projects, this model has little applicability.

Rational Unified Process (RUP) – The Rational Unified Process is an iterative and flexible software development framework originally developed by the Rational Corporation and now owned by IBM. Methodologies are more prescriptive and detailed, whereas frameworks are more general and allow for much more tailoring. Key aspects of RUP are that it is use case driven, iterative, and architecture centric. The RUP framework can actually accommodate many different development processes, both plan-driven and agile. Although certain RUP practices improve projects, RUP is contradictory to the core SDLC principles of early, detailed, and long-term planning as well as deliverable and phase review and approval. As a result, careful planning is required to incorporate RUP practices while maintaining critical elements of the waterfall approach.

RUP’s four-phase life cycle of Inception, Elaboration, Construction, and Transition are often conducted in multiple iterations. RUP stresses exit criteria for each phase; a phase is exited only after the project team demonstrates that it has met the phase specific criteria.

Within each iteration, tasks are categorized into nine core workflows: six development disciplines (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment) and three support disciplines (Configuration and Change Management, Project Management, Environment). These workflows are executed in parallel throughout a series of iterations. For example, unlike traditional or incremental waterfall, RUP allows for the concurrent execution of requirements definition, design, implementation, and test within a project phase (Elaboration).

The advantages of RUP include:

• Stakeholders are able to view working products much earlier in the life cycle than with traditional waterfall methodologies
  
• Requirements definition is strengthened by greater stakeholder involvement and review of working products
  
• Lower cost and less time required for first release
  
• Incremental work allows higher technical risks to be addressed in an early iteration
  
• Enhances the possibility that software meets actual stakeholder needs rather than perceived needs

 

The disadvantages include:

• Work products are not completely finished until the system is released to production
  
• Full lifecycle costs are unknown early in project
  
• Effective management and execution are complex and require personnel expertise in RUP
  
• Flexibility of framework may not provide enough explicit guidance, resulting in project chaos and lack of control

 

Although State projects require significant up-front planning and requirements definition and do not allow for the concurrent execution of the Requirements Analysis, Design, Development, Testing, and Implementation phases, the following RUP-inspired practices may be utilized to optimize project performance:

• Use case development
  
• Controlled requirements management
  
• Iterative system development
  
• Visual software modeling
  
• Early use of prototyping in requirements analysis and design
  
• Continuous quality verification
  
• Rigorous change control
  
• Utilization of tools to automate processes
  
• Modeling business processes prior to Requirements Analysis
  
• Testing throughout the project
  
• Robust configuration management controls and tools
  
• Beta testing