Evolution of Software Development Process Models

Software Process

A structured set of activities required to develop a software system. This provides stability, control, and organization to an activity so that it does not become chaotic.

This includes

• Specification : defining what the system should do
• Design and implementation : defining the organization of the system and implementing the system
• Validation : checking that it does what the customer wants
• Evolution : changing the system in response to changing customer needs.

Process Framework

Framework activities

• work tasks
• work products
• milestone & deliverables
• QA checkpoints

Umbrella activities

• Software project management
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Working product preparation and production
• Reusability management & measurement
• Risk management

Process Flow (Describe how process activities are organized)

Process Flow shows how the framework activities and the actions and the tasks that occur within each activity are organized with respect to sequence and time.

Types of process flows in SDLC

1. Linear Process Flow

A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment

2. Iterative Process Flow

An iterative process flow repeats one or more of the activities before proceeding to the next.

3. Evolutionary Process Flow

An evolutionary process flow executes the activities in a “circular” manner.

4. Parallel Process Flow

A parallel process flow executes one or more activities in parallel with other activities.

Framework activities will always be applied on every project. But the tasks for each activity will vary based on the type of project, characteristics of the project, rules and judgments.

Plan-Driven Process

Process activities are planned in advance and progress is measured against this plan.

Agile Process

Planning is incremental and it is easier to change the process to reflect changing customer requirements

Plan driven Models

1. Waterfall model
2. Prototyping models
3. Evolutionary models
4. The spiral model
5. Incremental development
6. Rapid Application Development
7. Reused-Oriented Software Development

1. Waterfall Model

This model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

2. Incremental development

Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.

User requirements are prioritised and the highest priority requirements are included in early increments

Once the development of an increment is started, the requirements are frozen, though requirements for later increments can continue to evolve.

Advantages

• Customer value can be delivered with each increment so system functionality is available earlier
• Early increments act as a prototype to help elicit requirements for later increments
• Lower risk of overall project failure
• The highest priority system services tend to receive the most testing

3. Rapid application development model

Rapid Application Development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle.

If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a ‘fully functional system’ within very short time periods (eg. 60 to 90 days)

Modeling :

• Business modeling : The information flow is identified between various business functions.
• Data Modeling : Information gathered from business modeling is used to define data objects that are needed for the business.
• Process Modeling : The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement business functions.

Construction

• Application generation : RAD assumes the use of 4GL or visual tools to generate the system using reusable components.
• Testing and turnover : New components must be tested and all interfaces must be fully exercised

Challenges :

• Required sufficient human resources to create teams
• If a system cannot be properly modularized, building the components necessary for RAD will be problematic.
• RAD is not applicable when technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs.

4. Prototyping

Throw away and Evolutionary prototyping

Throw away Prototyping

The objective is to understand the system requirements clearly. Starts with poorly understood requirements. Once the requirements are cleared, the system will be developed from the beginning.

This model is suitable if the requirements are vague but stable.

Challenges

• Some requirements cannot be prototyped
• Prototype is not an agreement (Not a legal contract)
• Non-functional requirements such as those concerning reliability, robustness and safety cannot be adequately tested in a prototype implementation.

Evolutionary Prototyping

Develop an initial implementation, exposing this to user comment and refining through many versions until an adequate system has been developed

Advantages

• Effort of prototype is not wasted
• Faster than the Waterfall model
• High level of user involvement from the start
• Technical or other problems discovered early — risk reduced

Mainly suitable for projects with vague and unstable requirements.

5. Spiral Development

Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process.

6. Unified Process (Use-case Driven, Architecture-Centric, Iterative and Incremental)

Use-case Driven : Recognize Customer View and Customer Communication

Architecture Centric : Emphasize important role of software architecture with Understandability, Reliance to future changes, Reuse

Process: Iterative and Incremental

Why UP 🤨

UP identifies the best features and characteristics of conventional software process models and integrate them with the best principles/practices of software development

UP is Incremental not Big-Bang(Develop whole at once)

Incremental development is a scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed.

UP is Iterative

Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. A typical difference is that the output from an increment is released to users(new functions), whereas the output from an iteration is examined for modification(examined, tested, with the result be marked as work in the following iteration, all prior to release)

Phase 1 : Inception Phase

Goals

• Establish a justification or business case for the project
• Establish the project scope and boundary conditions
• Outline the use cases and key requirements that will drive the design tradeoffs
• Outline one or more candidate architectures
• Identify risks
• Prepare a preliminary project schedule and cost estimate

Outcomes

• Initial Use Cases (functions, features, actors, sequence of actions, basis for project plan)
• Initial Architecture (Outline of Major sub-systems, functions, features, Refine to model different views of the system)
• Identify resources, risks, schedule, basis for phases

Phase 2: Elaboration Phase

Objectives

• Capture as many as system requirements
• Address known risks
• Establish and Validate System Architecture

Validating architecture

• Does it supports key system functionality
• Exhibit right behavior with performance, scalability and cost

Deliverable

• Plan for the construction phase (accurate and credible) address risk factors

Refine initial use-cases (Use-case Model, Analysis Model, Design Model , Implementation Model ,Deployment Model)

Create “Executable Architectural Baseline”

Review the plan (Scope, Risks, Delivery dates)

Phase 3: Construction Phase

System features are implemented in a series of short, time-boxed iterations.Each iteration results in an executable release of the software.

All increments started in elaboration phase to be completed. Develop test cases for Acceptance test and Unit Testing for each Increment as and when completed.

Integration activities and Intergration testing

Phase 4: Transitional Phase

The system is deployed to the target users. Feedback received from an initial release(s) may result in further refinements through several iterations. Includes system conversions and user training.

Beta Testing, Gather users feedback (errors and changes required). Develop supporting materials (User manuals, trouble-shooting guidelines, installation procedures etc.)

UP is Use Case driven

Use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.

UP is Architecture Centric

No single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.

UP is Risk focused

The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.

UP Best practises

Waterfall VS UP

• Waterfall : phases are equated with the process activities
• UP: phases represents business activities rather than technical information

Some other Process models

• Component based development — the process to apply when reuse is a development objective
• Formal methods — emphasizes the mathematical specification of requirements
• AOSD — provides a process and methodological approach for defining, specifying, designing, and constructing aspects