des - software process models

Process

A series of steps taken to produce an intended output

1. Activities

2. Constraints

3. Resources

The 3 things that is involved in ‘Steps’

1. Tools

2. Techniques

The 2 things involved in ‘Process’

Process

Prescribes all major activities

Process

Uses resources and is subject to a set of constraints (ex. schedule, no. of people working)

Process

Can have subprocesses with hierarchy or links

Process

Each activity in this has an entry and exit criteria

Process

Activities are organized in sequence, so timing is clear

Process

Each process has guiding principles, including goals of each activity

Process

Constraints can apply to an activity, resource, or product

Process

Imposes consistency and structure on a set of activities

Process

Guides us to understand, control, examine, and improve the activities

Process

Enables us to capture our experiences and pass them along

Process Model

Description of a process at a given level

Process Model

An anticipation of what the process will look like

Process Model

What the process shall be (It will be determined during actual system development)

Process Model

Forms a common understanding

Process Model

Finds inconsistencies, redundancies, omissions. It also finds and evaluates appropriate activities for reaching process goals.

Process Model

Tailors a general process for a particular situation

1. Waterfall

2. Prototyping

3. V-Model

4. Incremental

5. Iterative

6. Spiral

7. RUP

8. Agile

8 common software process models

Waterfall Model

One of the first process models ever proposed. It is simple and easy to explain to customers.

Requirements → System Design → Program Design → Coding → Unit & Integration Testing → System Testing → Acceptance Testing → Operation & Maintenance

The SDLC in a waterfall model

Waterfall Model

It presents a very high-level view of the development process and a sequence of process activities

Artefacts

In a waterfall model, each major phase is marked by milestones and deliverables otherwise known as ___

Waterfall Model

This model has no iterations and provides no guidance on how to handle changes to products and activities during development. It assumes requirements are frozen and cannot be changed.

Waterfall Model

Views software development as a manufacturing process rather than a creative process

Waterfall Model

This model has no iterative activities that lead to creating a final project. And customers would wait long before the final product

Prototype

This is a partially developed product

Prototype

This model helps developers assess alternative design strategies (design prototype) and users understand what the system will be like (user-interface prototype)

Prototype

This model is useful for verification and validation

Prototype

Waterfall Model with Prototyping

Prototype

Interacting with users and stakeholders at their respective phases

Prototype

Having a working model leads to better understanding and having quicker user feedback leads to better solutions.

Prototype

Errors can be detected much earlier and missing, ambiguous, complex functionality can be identified easily.

Prototype

It validates the requirements and leads to quick implementation of incomplete, but functional application

Prototype

Leads to implementing and then repairing the system a lot of time. This method can increase the complexity of the system and its scope may expand beyond original plans.

Prototype

Can cause the application to not be used as the full system was designed incomplete or can have inadequate problem analysis

Prototye

Use this model when the desired system has lots of user interaction (eg., online systems, or web interfaces).

Prototype

Use this system when end users constantly work with the system.

Feedback → Incorporate in the Prototype → Useable System

V-Model

A variation of the waterfall model.

V-Model

It uses unit testing to verify procedural design

Integration testing to verify architectural (system) design

Acceptance testing to validate the requirements.

V-Model

In this model, if problems are found during verification and validation, the left side of the V can be re-executed before testing on the right side is re-enacted

V-Model

V-Model

Requirements like BRS and SRS begin the life cycle, just like in waterfall. But, in this model, a system test plan is created before development starts.

System Test Plan

This plan focuses on meeting the functionalities specified in the requirements gathering

High-Level Design (HLD)

This phase of the V-Model focuses on system architecture and design. It provides an overview of the solution, platform, system, product, and service/process.

During this phase, an integration test is created as well to test the pieces of the software systems ability to work together.

Low-Level Design (LLD)

This phase of the V-Model is where the actual software components are designed. It defines the actual logic for each and every component of the system.

In this phase, component tests are created as well. We also create class diagrams with all the methods and relations between classes.

Coding

This is at the very bottom of the V-Model. Module design is converted into code.

V-Model

Simple and easy to use, but also has testing activities and test designs before coding starts, which saves a lot of time and leads to a higher chance of success over the waterfall model.

V-Model

Has proactive defect tracking, which means defects are found at an early stage. It avoids the downward flow of defects.

V-Model

Works best for small projects where requirements are easily understood

V-Model

This model is very rigid and is the least flexible among all models.

V-Model

Software is developed during the implementation phase, so no early prototypes are produced. If any changes happen midway, then the test documents along with requirement documents has to be updated.

V-Model

Since there are no prototypes involved in this model, there is a very high risk involved in meeting customer expectations.

Only choose this model if there is a high confidence in the customer.

Incremental Model

In this model, the whole requirement has various builds. It has multiple development cycles which is why its also called sometimes as the “multi-waterfall cycle”

Incremental Model

This model has cycles which are smaller, more easily managed modules.

Modules are phases, and subsequent releases (which are also modules) adds function to the previous release. The process continues until the complete system is achieved.

Incremental Model

First Module → Working Version of Software → Working software early on during the SDLC

Incremental Model

Incremental Model

It generates working software quickly and early during the software life cycle. It’s more flexible and costs less to change scope and requirements. It is easier to test and debug as it’s a smaller iteration

Incremental Model

Model where customers can respond to each build. It lowers initial delivery cost and makes it easier to manage risk as risky pieces are identified and handled during its iteration

Incremental Model

This model needs good planning and design and a clear and complete definition of the whole system before it can be broken down and built incrementally

Incremental Model

One disadvantage of this model is the price. Its total cost is higher than the total cost in the waterfall model.

Iterative Model

Doesn’t require a full specification of requirements at the start. The development begins by specifying and implementing just part of the software, which is then reviewed in order to identify further requirements.

The process is then repeated, producing a new version of the software for each cycle of the model

Iterative Model

Iterative Model

Only creates a high-level design of the application before beginning the actual product and defines the design solution for entire product.

Iterative Model

Design a system and build a skeleton version of that, and then evolve the design based on what had been build. Basically building and improving the product step by step

Iterative Model

It tracks defects at early stages, and has reliable user feedback. Less time on documenting, and more on designing

Iterative Model

Each phase of an iteration is rigid with no overlaps. The system architecture might become expensive or design issues may arise since not all requirements are gathered up front for the entire life cycle

Spiral Model

This model is similar to the incremental model but is more focused on risk analysis

Spiral Planning

This model has 4 phases: Planning, Engineering, Risk Analysis, and Evaluation.

A prototype is produced at the end of the risk analysis phase.

Engineering Phase

This phase in the Spiral Model determines goals, alternatives, and constraints

Risk Analysis

This phase in the Spiral Model evaluates alternatives and risks

Spiral Model

This model has a high amount of risk analysis. Hence, avoidance of risk is enhanced making it good for large and mission-critical projects. It doesn’t work as well as it does on smaller projects.

Spiral Model

This model has strong approval and documentation control. Functionalities can be added at a later date. And software is produced early in the software life cycle.

Spiral Model

This model can be costly. And it requires a highly specific set of expertise as it has high risk analysis. The project’s success is highly dependent on the risk analysis phase.

Rapid Application Development (RPD) Model

It is a type of incremental model where components/functions are developed in parallel as if they were mini projects.

Rapid Application Development (RPD) Model

Developments are time-boxed, delivered, and then assembled into a working prototype. It quickly gives customers something to see and use, and to provide feedback regarding the delivery and the requirements.

Business Modeling

This is a phase in the RDP Model where information flows between various business functions

Data Modelling

This is a phase in the RDP Model where information flows lead to data objects

Process Modeling

This is a phase in the RDP Model where the created Data Objects in the previous phase, is created to achieve some specific business objective + description.

CRUD of data objects.

Application Generation

This is a phase in the RDP Model where automated tools are used with the process models. Code + Actual System

Testing and Turnover

This is a phase in the RDP Model where new components and all interfaces are tested

RDP Model

Rapid Application Development (RPD) Model

This model reduces development time and increases the reusability of components.

Rapid Application Development (RPD) Model

This model encourages customer feedback and initial reviews occur quickly in the life cycle. The integration testing in the beginning also solves a lot of integration issues

Rapid Application Development (RPD) Model

This model depends on a strong team (highly skilled developers/designers) and individual performances for identifying business requirements.

Rapid Application Development (RPD) Model

This model has a high dependency on modeling skills. Systems that can be modularized can be built using RAD.

Rapid Application Development (RPD) Model

Inapplicable to cheaper, smaller projects as the cost of the modeling and automated code generation is very high

Agile Model

A type of incremental model where the software is developed in incremental, rapid cycles.

Agile Model

Small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. it is used for time critical applications

Extreme Programming (XP)

Currently one of the most well known agile development life cycle model

Agile Model

Agile Model

Ensures customer satisfaction by rapid, continuous delivery of useful software. People and interactions are emphasized rather than process and tools. Customers, developers, and testers constantly interact with each other.

Agile Model

Working software is delivered frequently (weeks rather than months). Face-to-face conversation is the preferred form of communication.

Agile Model

Continuous attention to technical excellence and good design. Regular adaptation to changing circumstances, where even late changes in requirements are welcomed.

Agile Model

in some software deliverables, especially large ones, it is difficult to assess the effort required at the beginning of the SDLC.

Agile Model

There is lack of emphasis on necessary designing and documentation and the project can easily get taken off track if the customer representative is not clear on the final outcome they want.

Agile Model

Only senior programmers are capable of decision-making during the development process. Hence, creating a space where newbie programmers are unwelcomed in unless they have experienced resource.