Skip to main content

Waterfall Development

A traditional linear and sequential development methodology where each phase must be completed before moving on to the next.

Practices Employed

  • Approvals: Waterfall emphasizes formal reviews and sign-offs at the end of each phase to ensure that all stakeholders agree on the work completed and the plans for the next phase. Referred to as:
    • Review and Sign Off
  • Coding: The implementation phase in Waterfall involves converting design documents into functional software through coding. Referred to as:
    • Implementation
  • Design: The system design phase in Waterfall includes both high-level and low-level design to create a blueprint for the implementation phase. Referred to as:
    • System Design
  • Documentation: Detailed documentation is created and maintained throughout each phase in Waterfall to ensure clarity and traceability.
  • Issue Management: The maintenance phase in Waterfall involves managing issues and bugs that arise post-deployment and making necessary updates and improvements. Referred to as:
    • Maintenance
  • Prioritising: Waterfall involves detailed project planning and management, which includes prioritizing tasks to ensure the project progresses according to schedule and within budget. Referred to as:
    • Project Management and Planning
  • Release: The deployment phase in Waterfall involves releasing the completed software product to the production environment for end-users. Referred to as:
    • Deployment
  • Requirements Capture: The requirements gathering and analysis phase in Waterfall involves collecting and documenting all possible requirements of the system to be developed.
  • User Acceptance Testing: The integration and testing phase in Waterfall includes system and acceptance testing to ensure the product meets the specified requirements and the needs of the users. Referred to as:
    • Integration and Testing
    • User Acceptance Testing

Addresses / Mitigates

RiskPractices
Communication Risk
  • Approvals: Provides formal communication of acceptance and readiness.
  • Design: Provides a clear structure and organization, making the system easier to understand and use.
  • Documentation: Provides clear guidelines and information, reducing misunderstandings.
  • Issue Management: Facilitates communication about issues and their status among team members.
  • Requirements Capture: Helps in explaining exactly what should be built.
  • User Acceptance Testing: Facilitates feedback from end users, improving the final product.
Coordination Risk
Deadline Risk
  • Prioritising: In order to hit a deadline, you can de-prioritise less important work.
Feature Fit Risk
  • Coding: Build or improve some features which our clients will find useful.
  • Release: Putting new features in the hands of users can make your product fit their needs better.
  • Requirements Capture: Ensures that features align with client needs and expectations.
  • User Acceptance Testing: Ensures that the software meets the client's requirements and expectations.
Funding Risk
  • Prioritising: Allocates resources efficiently to high-impact areas.
  • Release: Delivering features might mean you get paid for the software you write.
Implementation Risk
  • Approvals: Ensures that work meets the required standards and specifications before progressing.
  • Design: Guides the development process, ensuring that the system meets requirements and design specifications.
  • Issue Management: Tracks and manages defects and issues, ensuring they are resolved.
  • User Acceptance Testing: Validates that the implementation meets the specified requirements.
Internal Model Risk
  • Documentation: Detailed documentation helps manage and understand complex systems.
  • User Acceptance Testing: As a feedback mechanism, UAT helps improve understanding of users and their requirements.
Market Risk
  • Design: (Research and) design allows you to leapfrog competitors and provide new sources of value.
  • Prioritising: Ensures that the most valuable features and opportunities are addressed first.
  • Release: Delivering features means you get market feedback.
Operational Risk
  • Design: Ensures that the system architecture supports operational requirements and scalability.
  • Issue Management: Provides a systematic approach to managing and addressing operational issues.
Process Risk
  • Coding: Problems and edge cases with software processes can be fixed by adding code.
Reputational Risk
Schedule Risk
Security Risk

Attendant Risks

Attendant RiskPractices
Complexity Risk
  • Coding: Writing new code adds complexity to a project.
  • Documentation: Documentation is also a source of complexity on a project and can slow down change.
  • Issue Management: Managing an excessive number of logged issues can add complexity.
Coordination Risk
  • Approvals: Requires coordination among stakeholders to provide timely sign-off.
  • User Acceptance Testing: Requires coordination between the development team and end users.
Deadline Risk
  • Prioritising: Establishing an order of events often places deadlines on the earlier events completing or the later events starting.
  • User Acceptance Testing: Can often go on longer than expected, leading to deadline issues.
Feature Fit Risk
  • Design: Too much design up-front can create problems meeting feature requirements.
Funding Risk
  • Design: Design can be an expensive bet that doesn't lead to improved software.
Implementation Risk
  • Coding: Changes in code can introduce new bugs and regressions.
Legal Risk
  • Release: Publishing or releasing code may involve licensing, Intellectual Property, Liability or other legal compliance."
Lock-In Risk
  • Design: Design decisions can create boundaries that limit flexibility and adaptability.
Market Risk
  • Prioritising: Prioritising a single client or narrowing scope reduces diversification, increasing exposure to changes in the market.
Operational Risk
  • Release: Releasing software means that the software has to be supported in production.
Process Risk
  • Approvals: Adding approvals to a process increases the number of stakeholders involved and can impact process performance.
  • Issue Management: The issue lifecycle from creation to resolution is a process, therefore a source of process risk.
  • Release: Complex release procedures are a source of process risk.
Reliability Risk
  • Design: Creates dependencies on software components and design patterns.
  • Prioritising: Prioritization can create dependencies on specific tasks or features.
  • Release: Releases can introduce discontinuities in software service if not managed well.
Reputational Risk
  • Release: Poor release management can destroy reputation and good-will.
Schedule Risk
  • Approvals: Waiting for approvals can introduce delays in the project timeline.
  • Documentation: Creating and maintaining documentation can be time-consuming.
  • Issue Management: Managing and resolving logged issues can impact project timelines.
  • Release: Delays in the release process can impact overall project time-lines.
  • Requirements Capture: Thorough requirements capture can be time-consuming.
  • User Acceptance Testing: UAT can be time-consuming, potentially delaying the release.

Description

"The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks... The waterfall model is the earliest SDLC approach that was used in software development." - Waterfall model, Wikipedia

Waterfall Development is a traditional project management methodology that follows a linear and sequential approach. Key phases in Waterfall include requirements gathering and analysis, system design, implementation, integration and testing, deployment, and maintenance. Each phase must be completed before the next phase begins, ensuring a structured and disciplined approach to software development.

See Also

No documents tagged