Overview of Software Development Life Cycle Models

Software Development Life Cycle (SDLC)

A conceptual framework that describes the stages, activities, tasks, and deliverables involved in the development, deployment, and maintenance of a software system.

Purpose of SDLC Models

To provide a structured and systematic approach to the complex process of software engineering, aiming to produce high-quality software that meets or exceeds customer expectations, and is completed on time and within budget.

Roadmap for Development Teams

Models offer a roadmap for development teams to follow, ensuring a clear understanding of what needs to be done, how it will be done, and when it will be done.

Phases of SDLC Models

Distinct stages of the software development process, such as requirements gathering, analysis, design, implementation (coding), testing, deployment, and maintenance.

Activities and Tasks in SDLC

Specific actions performed within each phase to achieve its objectives.

Deliverables in SDLC

Tangible outputs produced at the end of each phase or activity, such as a requirements specification document, design documents, source code, test plans, or a deployed system.

Tools and Techniques in SDLC

Recommended software tools, methodologies, or best practices to be used during development.

Implications of Model Selection

The choice of an SDLC model has significant implications for how a project is managed and executed.

Effects of Model Selection

It affects the level and type of planning required, the way progress is tracked and reported, the frequency and nature of deliverables, the roles and interactions of team members, and the degree of flexibility to accommodate changes.

Waterfall Model

The Waterfall Model is one of the oldest and most straightforward approaches to software development.

Linear-Sequencial Life Cycle Model

Another name for the Waterfall Model.

Spiral Model

A software development model that combines iterative development with the systematic aspects of the Waterfall model.

Rapid Application Development (RAD) Model

A type of incremental model that emphasizes an extremely short development cycle.

Agile Model

A software development methodology that promotes iterative development, collaboration, and flexibility.

Key Elements of SDLC Models

Common elements that define the structure and execution of SDLC models.

Understanding SDLC Models

The process of comprehending the various models used in software development.

System Analysis and Design

A field of study focused on the analysis and design of information systems.

Bachelor of Technical-Vocational Teacher Education

An academic program that prepares students for teaching technical and vocational subjects.

ITSD220-T

A course code for System Analysis and Design.

ITCW122-T

A course code for Computer Workshop 1.

Requirement Gathering and Analysis

All possible requirements of the system to be developed are captured and documented in this initial phase.

System Design

The requirements specifications from the first phase are studied, and a comprehensive system design is prepared.

Implementation (Coding)

With the system design as input, the actual coding of the software takes place.

Testing

The individual units developed in the implementation phase are integrated into a complete system.

Deployment

Once testing is successfully completed and the system is validated against its requirements, the product is deployed to the customer's environment or released to the market.

Maintenance

After deployment, the system enters the maintenance phase.

Waterfall Model Requirements

When requirements are very well understood, clearly defined, documented, and fixed, with minimal risk of changing during the project.

Waterfall Model Stability

When the product definition is stable and not subject to frequent modifications.

Waterfall Model Development Stack

When the development stack is well-understood and not dynamic.

Waterfall Model Project Size

For smaller or shorter projects where the scope is well-contained.

Waterfall Model Advantages

Its straightforward, rigid structure makes it easy to grasp and manage.

Waterfall Model Deliverables

Each phase has specific deliverables and a review process, making progress easy to track against a defined plan.

Waterfall Model Documentation

Enforces discipline in completing phases thoroughly and typically results in comprehensive documentation.

Waterfall Model Task Arrangement

The sequential nature makes it simple to arrange tasks.

Waterfall Model Change Accommodation

It's very difficult and costly to accommodate changes in requirements once a phase is complete.

Waterfall Model Working Software

No working software is produced until late in the project lifecycle.

Waterfall Model Error Propagation

If requirements are misunderstood at the start, errors can propagate and be very expensive to fix later.

Waterfall Model Complexity

Poor choice for complex, object-oriented projects, or long projects where requirements are likely to evolve.

Waterfall Model Delivery Time

The sequential nature can lead to a long delivery time for the entire system.

V-Model

The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape.

V-Model Definition

It is also known as Verification and Validation model.

V-Model Extension

The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage.

V-Model Testing Phase

This means that for every single phase in the development cycle, there is a directly associated testing phase.

V-Model Discipline

This is a highly-disciplined model and the next phase starts only after completion of the previous phase.

V-Model Parallel Planning

Under the V-Model, the corresponding testing phase of the development phase is planned in parallel.

Business Requirement Analysis

In this initial phase, the requirements are gathered and analyzed from the customer's perspective to understand their expectations.

Acceptance Test Cases

Acceptance test cases are designed based on these business requirements to validate the system against user needs at the end of the development.

System Test Plans

Plans and test cases prepared based on the system design to verify the entire system's functionality and integration with other systems.

Architectural Design (High-Level Design)

The system design is broken down into modules, and the high-level architecture defining the components, their interfaces, and interactions is created.

Integration Test Plans

Designed to verify that the different modules of the system interact and communicate correctly with each other as per the architectural design.

Module Design (Low-Level Design)

Detailed internal design for each system module is specified in this phase, ensuring compatibility with other modules and external systems.

Unit Test Cases

Designed for each module to verify its individual functionality against its design specifications.

Coding Phase

The point where the 'V' transitions from the left (design) arm to the right (testing) arm, where actual coding of the system modules occurs.

Unit Testing

The unit test cases designed during the Module Design phase are executed on the actual code of individual modules or components to identify and fix defects at the earliest possible stage.

Integration Testing

The integrated modules are tested according to the integration test plans to ensure that they work together correctly as defined in the architectural design.

System Testing

The entire system is tested as a whole against the system test plans to validate that all functionalities are implemented as per the system design and that it interacts correctly with any external systems.

Acceptance Testing

Typically conducted by the end-users or client in their environment to ensure the system meets their needs and is ready for deployment.

Use Case

Application scenarios for the V-Model that are similar to those for the Waterfall model.

Well-defined Requirements

Requirements that are clearly documented and stable.

Advantages of V-Model

Test planning and design occur early, in parallel with development phases.

Disadvantages of V-Model

Similar to Waterfall, it's rigid and doesn't easily accommodate changes to requirements.

Iterative Model

In the Iterative model, iterative process starts with a simple implementation of a small set of the software requirements and iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed.

Iterative

Means you're refining and improving things through cycles.

Incremental

Means you're adding new pieces of functionality in each cycle.

Requirements Phase

This phase sets the general direction and provides a high-level understanding so the team can start breaking the project into manageable chunks or 'builds.'

Iterative Phases

Each 'build' is an increment of the system.

Design & Development Phase

For each specific build or increment, the team would take the requirements relevant to that build, carry out detailed design for those specific features or components, and then developers write the code to bring those designs to life for that particular build.

Testing Phase

Once a build's 'Design & Development' is done, that build needs to be tested.

Implementation Phase

This phase takes the tested build and deploying it or making it available.

Advantages

Functional parts of the system are available early in the lifecycle.

Disadvantages

If the initial architecture isn't robust, it may require significant refactoring as the system evolves.

Objective Identification

In this quadrant, the objectives for the current phase (or iteration) are defined, and different alternative approaches to achieve these objectives are explored.

Alternate Evaluation

This is a critical part of the Spiral Model where alternatives identified in the first quadrant are evaluated, focusing on identifying potential risks and developing strategies to mitigate them.

Product Development

Based on the objectives and risk mitigation strategies, the actual development and verification of the product for the current iteration takes place.

Next Phase Planning

The results of the current iteration are reviewed, and decisions are made regarding the continuation of the project and the plan for the next loop of the spiral.

Requirements Planning (Scoping)

This phase involves a workshop-like meeting with users and management to agree on the high-level scope, objectives, and constraints of the project.

User Design (Iterative Prototyping)

Users work closely with analysts and developers to create, test, and refine prototypes of the system's user interface and functionality.

Construction

Once the user design is largely agreed upon through the prototypes, the development team focuses on building the final system.

Implementation (Cutover)

This phase involves deploying the new system into the live operational environment.

Typical Phases in RAD

Activities include data conversion from old systems (if any), user training, and switching over from the old system to the new one.

Modularization in RAD

The system can be modularized, allowing for functionalities to be built and delivered as separate components.

Business Need for RAD

There's a clear business need for rapid delivery.

User Participation in RAD

Users are available and committed to participating actively throughout the project.

Project Scope in RAD

The project scope is relatively well-defined, even if detailed requirements are not fully fleshed out initially.

Technology and Tools for RAD

The necessary technology and tools (like CASE tools or 4GLs) are available to support rapid prototyping and development.

User Interface Focus in RAD

The system primarily focuses on user interface interactions rather than complex, computation-intensive processing.

Advantages of RAD

Significantly reduces development time, leading to quick delivery of a working system.

User Satisfaction in RAD

Leads to better user satisfaction as the system is built collaboratively.

Incorporating Changes in RAD

Changes can be easily incorporated during the iterative prototyping stages.

Early User Interaction in RAD

Users see and interact with working prototypes early on.

Continuous Feedback in RAD

Continuous feedback helps catch misunderstandings early.

Disadvantages of RAD

Needs experienced developers proficient with RAD tools and techniques.

User Availability in RAD

Relies heavily on users being consistently available and actively participating.

Complex Systems in RAD

Less suitable for large, complex systems that can't be easily modularized or that have high technical risks not addressable by RAD tools.

Project Management in RAD

The fast-paced, iterative nature requires strong project management and discipline to avoid chaos.

Architectural Integrity in RAD

The intense focus on speed might lead to overlooking long-term architectural integrity or quality if not carefully managed.

Documentation in RAD

Often results in less comprehensive formal documentation.

Agile Philosophy

Instead, it's better understood as a philosophy or a mindset for software development that prioritizes flexibility, collaboration, customer feedback, and the rapid delivery of high-quality, functional software.

The Agile Manifesto

A document created in 2001 that formalizes the Agile philosophy, outlining four core values.

Individuals and interactions over processes and tools

Valuing skilled people and effective communication more than rigid processes or over-reliance on specific tools.