SP models

The Waterfall Model (WM)

Basic Process

• Plan and schedule all process activities before starting software development, thus it is a plan-driven process
• In principle, the following phases should not start until previous phases have been completed.

Requirements Definition ->
System & Software Design ->
Implementation & Unit Testing ->
Integration & System Testing ->
Operation & Maintenance

Requirements Definition

1. Gather info. about the required functionalities and constraints
   1. required functionality: (The report must be in PDF format.)
   2. constraints: (Use the ASP.net/Java as technology stack )
2. Analyzes the software

3. Create details specification

   System & Software Design

4. Allocates the requirements to Systems

5. Establishes an overall system architecture

   Implementation & Unit Testing

6. The software design is realized as a set of programs or program units

7. Program units are tested to meet their specification

   Integration & System Testing

8. The individual program units or programs are integrated and tested as a complete system

9. The verified and validated software system is delivered to the user after the testing

   Operation & Maintenance

10. The system is deployed and put into practical use

11. The software system maybe continuously updated to patch for errors or security threats; to improve stability of the system; or to enhance the system’s functionality

Applications

1. Embedded Systems
   1. Software needs to interface with hardware systems
   2. Hardware is inflexible; it is often inconvenient to delay decisions on the software’s functionality until it is being implemented
2. Critical Systems
   1. There is need for extensive safety and security analysis of the software specification and design.
   2. The software specification and the design documents must be complete
   3. Safety related problems are usually expensive to correct
3. Large Software Systems
   1. Multiple partners jointly developing the software system, complete specifications may be needed to allow for the independent development of different subsystems.

The Waterfall model is NOT suitable for the software systems that must cope with change as the nature of the one-way process cannot cope with change effectively.

The V-Model (an Example of WM)

The V-model illustrates how test plans are the link between testing and development activities.

Advantage of V-M

1. Simple and easy to manege
2. Encourage verification amd validation at all phrase

3. Gives equal weight to both development and testing

   Disadvantage of V-M

4. Not suitable if the requirements are at moderate to high-risk of changging (changging cost much)

5. Not suggested for long and complex OO software project

Incremental Development

Basic Process:

1. Begins with a simple implementation of a part of the software system.

2. With each increment the product evolves with enhancements being added every time until the final version is completed.

   Feature:

3. Code is written and tested in smaller pieces, thus reduces risks associated with the process.

4. Allows changes to be included easily along the development process.

Advantages

1. Reduced the cost for implementing requirements changes (compare with WM)
2. Receiving feedback early

3. Early delivery of partially working product

   Disadvantages

4. The process is not visible

   1. Regular deliverables are needed to measure progress
   2. It is not cost effective to produce documentation for every version of the system if the incremental iteration is short
5. System structure tends to degrade as new increment are added
   1. Frequent changes lead to extra burden on source code and project management
   2. This can also be harmful to the software system architecture and as more functional components being added to the system, the existing architecture might need to be modified accordingly, which could lead to cascade effect. Thus, refactoring is often needed.

      Refactoring

      “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”

The Spiral Model (Example)

Prototype

A prototype is a temporary implementation of some functional subset of the system, often presented to users for feedback and validation, which is then discarded when the validation exercise is complete.

Proof-of-concept

A proof-of-concept is some code designed to prove that a risky element of the proposed architecture is feasible and to highlight any problems and pitfalls. A proof-of-concept is also a temporary implementation, which is discussed when it has served its purpose and the risk under investigation is understood.

Skeleton System

A skeleton implements the system’s main architectural structures but contains only a minimal subset of the system’s functionality. A skeleton system is retained rather than discarded and becomes the basis for the construction phase.”
A skeleton system is sometimes called an “evolutionary prototype”

Integration and Configuration

Stages

1. Requirements Specification
   1. The initial requirements for the system are collected.
   2. It should include brief descriptions of essential requirements and system features.
2. Software Discovery and Evaluation
   1. Outline the software requirements, and search for components and systems that provide the functionality required.
   2. Candidate components and systems are evaluated to see if they are suitable for use in the system.
3. Requirements Refinement
   1. The requirements are refined or modified using information about the reusable components and applications
4. Application System Configuration
   1. If an off-the-shelf application system is available, it can be configured for use to create the new system, then it should be considered first.
5. Component Adaptation and Integration
   1. If there are no off-the-shelf application systems available, available components and/or development of new components should be considered, then integrated to create the system.

Advantages

1. Reducing the amount of software to be developed
2. Reducing the cost and risks
   1. less development activities leads to reduced cost
   2. existing components/application systems are usually proven to be correct, stable and secure
   3. Existing components/application systems offers good Application Programming Interfaces (APIs) for integration

3. Faster delivery of the software

   Disadvantages

4. The requirements compromises may drift the original idea of the system

5. Limited control over the system evolution
   1. Newer version of the reusable components may not be compatible with the current version used, for example, refactored APIs, new functionalities, deprecated function calls, etc.

      An Universal Process Model

• A disciplined approach to assigning tasks and responsibilities within a development organization.
• Ensures the production of high-quality software that meets the needs of its users within a predictable schedule and budget.

Inception

Inception is the initial short step to establish a common vision and basic scope for the project. The purpose of the inception phase is NOT to define all the requirements, or generate a believable estimate or project plan

• Analyses part of the use cases
• Analysis of critical non-functional requirements
• E.g., security, reliability, extensibility, etc.
• Creation of business cases
• Preparation of the development environment

Elaboration

Build the core architecture, resolve the high-risk elements, define most requirements and estimate the overall schedule and resources.
• The core, risky software architecture is programmed and tested
• The majority of requirements are discovered and stabilized
• The major risks are mitigated
• It involves a series iterations
• Recommended to be between two and six weeks

Construction

• Concerned with system design, implementation and testing
• Parts of the system are developed and integrated
• On completion of this phase, a partially working system and associated documentation should be ready for delivery to users

Transition

• Deploy the system in a real production environment
• On completion of this phase, the software system should be:
1. well documented
2. working correctly
3. running in its operational environment