Prescriptive process models

The Waterfall Model,

V-model,
Incremental Process Models,
Evolutionary Process Models,
Concurrent Models

Waterfall Model
● The Waterfall model is also known as ‘Linear sequential model‘ or ‘Classic life cycle
model‘.

● It is used in small projects where requirements are well defined and known before starting
the project. Activities are carried out in a linear and systematic fashion.

● The process starts with communication, where requirements are gathered from the
customer and recorded.

● Then goes to the planning stage where the cost and time constraints are estimated, a
schedule is outlined and project tracking variables are defined.

● Modelling is where a design based on the requirements and keeping the project constraints
in mind is created. After this, code is generated and the actual building of the product is
started in the construction phase.

● Testing (unit testing, integration testing) is done after code completion in this phase.

● Deployment is the last stage where the product is delivered, customer feedback is received
and, support and maintenance for the product are provided.
Advantages of the waterfall model

● A simple model to use and implement.

 ● Easily understandable workflow.

● Easy to manage since requirements are known prior to the start of the project.

● Can be applied to projects where quality is preferred over cost.

Disadvantages of the waterfall model

● It may be difficult for the customer to provide all the specific requirements beforehand.

● Cannot be used for complex and object-oriented projects.

Incremental Process Model

● The Incremental process model is also known as ‘Successive version
model‘.
● In the Incremental process model, a series of releases, called increments, are
built and delivered to the customer.
● First, a simple working system(core product), that addresses basic
requirements, is delivered.
● Customer feedback is recorded after each incremental delivery.

● Many increments are delivered, by adding more functions, until the required
system is released.
● This model is used when a user demands a model of product with limited
functionality quickly.
Advantages of incremental process model
● Flexible to change requirements.

● Changes can be done throughout the development stages.

● Errors are reduced since the product is tested by the customer in each phase.

● Working software available at the early stage of the process.

● Easy to test because of small iterations.

● The initial cost is lower.

Disadvantages of incremental process model

● Requires good planning and design.

● Modules and interfaces should be well defined.

● The total cost is high.

● Refining requirements in each iteration may affect system architecture.

 V-Model
● The V-model is an SDLC model where execution of processes happens in a
sequential manner in a V-shape. It is also known as Verification and
Validation model.

● 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.

●This means that for every single phase in the development cycle, there is a
directly associated testing phase. This is a highly-disciplined model and the
next phase starts only after completion of the previous phase.
V-Model - Design
● Under the V-Model, the corresponding testing phase of the development
phase is planned in parallel.
●So, there are Verification phases on one side of the ‘V’ and Validation phases
on the other side. The Coding Phase joins the two sides of the V-Model.
V-Model - Verification Phases
● There are several Verification phases in the V-Model, each of these are
explained in detail below.

1.Business Requirement Analysis

● This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective.
● This phase involves detailed communication with the customer to understand
his expectations and exact requirement.
 ● This is a very important activity and needs to be managed well, as most of the
customers are not sure about what exactly they need. The acceptance test
design planning is done at this stage as business requirements can be used as
an input for acceptance testing.
●
2.System Design
● Once you have the clear and detailed product requirements, it is time to
design the complete system. The system design will have the understanding
and detailing the complete hardware and communication setup for the product
under development.

3.Architectural Design
● Architectural specifications are understood and designed in this phase.
Usually more than one technical approach is proposed and based on the
technical and financial feasibility the final decision is taken.
4.Module Design
● In this phase, the detailed internal design for all the system modules is
specified, referred to as Low Level Design (LLD).
● It is important that the design is compatible with the other modules in the
system architecture and the other external systems.
● The unit tests are an essential part of any development process and helps
eliminate the maximum faults and errors at a very early stage. These unit tests
can be designed at this stage based on the internal module designs.

5.Coding Phase
● The actual coding of the system modules designed in the design phase is
taken up in the Coding phase. The best suitable programming language is
decided based on the system and architectural requirements.
 ●

● Diagram Explaintion
● A variation of waterfall model depicts the relationship of quality assurance actions to the
actions associated with communication, modeling and early code construction activates.

● Team first moves down the left side of the V to refine the problem requirements. Once
code is generated, the team moves up the right side of the V, performing a series of tests
that validate each of the models created as the team moved down the left side.

Evolutionary Process Models

Evolutionary Process Models

● Evolutionary models are iterative type models.

● They allow to develop more complete versions of the software.

● Following are the evolutionary process models.

1. The prototyping model

2. The spiral model
3. Concurrent development model
Prototyping
 ● In cases when the requirements are unclear and are likely to change or when the developer
is doubtful about working of an algorithm, a solution is to build a prototype and find out
what is actually needed.

● Hence, in this model, one or more prototypes are made with unrefined currently known
requirements before the actual product is made.

Diagram Explaination:
Step 1: Requirements gathering and analysis

● A prototyping model starts with requirement analysis. In this phase, the requirements of
the system are defined in detail. During the process, the users of the system are
interviewed to know what is their expectation from the system.

Step 2: Quick design

 ● The second phase is a preliminary design or a quick design. In this stage, a simple design
of the system is created. However, it is not a complete design. It gives a brief idea of the
system to the user. The quick design helps in developing the prototype.
Step 3: Build a Prototype
● In this phase, an actual prototype is designed based on the information gathered from
quick design. It is a small working model of the required system.
Step 4: Initial user evaluation
● In this stage, the proposed system is presented to the client for an initial evaluation. It
helps to find out the strength and weakness of the working model. Comment and
suggestion are collected from the customer and provided to the developer.
Step 5: Refining prototype
● If the user is not happy with the current prototype, you need to refine the prototype
according to the user’s feedback and suggestions.
● This phase will not over until all the requirements specified by the user are met. Once the
user is satisfied with the developed prototype, a final system is developed based on the
approved final prototype.
Step 6: Implement Product and Maintain

● Once the final system is developed based on the final prototype, it is thoroughly tested
and deployed to production. The system undergoes routine maintenance for minimizing
downtime and prevent large-scale failures.
Advantages of prototyping

● Active involvement of the user.

● Errors are detected earlier.

● Feedback after each prototype helps in understanding the system better.

● Does not need to know detailed processes, input and output from the beginning.

Disadvantages of prototyping

● Multiple prototypes can slow down the process.

● Frequent changes can increase complexity.

● Unsatisfied client leads to multiple throwaways.

● The customer may not be interested or satisfied after evaluating the initial prototype.
 Spiral Model
In spiral model, the software is developed through a series of increments. The diagram
looks like a spiral with loops where each loop is a phase. Each phase is split into four
sectors/quadrant.

● this evolutionary process begins, the software team performs activities that are implied by
a circuit around the spiral in a clockwise direction, beginning at the center.

Advantages of spiral model

● Reduces risk.

● Recommended for complex projects.

● Changes can be incorporated at a later stage.

● Strong documentation helps in better management.

Disadvantages of spiral model

● Costly and not recommended for small projects.

● Demands risk assessment expertise.

 ● Looping is a complex process.

● Heavy documentation.
The concurrent Development Model

● The concurrent development model, sometimes called concurrent engineering, can be

represented schematically as a series of framework activities, Software engineering actions
of tasks, and their associated states.

● The concurrent model is often more appropriate for system engineering projects where
different engineering teams are involved.

Diagram Explaination

● The concurrent development model is called as concurrent model.

● The communication activity has completed in the first iteration and exits in the awaiting
changes state.
 ● The modeling activity completed its initial communication and then go to the
underdevelopment state.

● If the customer specifies the change in the requirement, then the modeling activity moves
from the under development state into the awaiting change state.

● The concurrent process model activities moving from one state to another state
● Figure above provides a schematic representation of one Software engineering task within
the modeling activity for the concurrent process model.

● The activity – modeling- may be in any one of the states noted at any given time.

● All activities exist concurrently but reside in different states.

● For example, early in the project the communication activity has completed its first
iteration and exists in the awaiting changes state. The modeling activity which existed in
the none state while initial communication was completed now makes a transition into
underdevelopment state.

● If, however, the customer indicates the changes in requirements must be made, the
modeling activity moves from the under development state into the awaiting changes state.

● The concurrent process model defines a series of events that will trigger transitions from
state to state for each of the Software engineering activities, actions, or tasks.

Agile Process
● The meaning of Agile is swift or versatile."Agile process model" refers to a software
development approach based on iterative development.
 ● Agile methods break tasks into smaller iterations, or parts do not directly involve long
term planning.

● The project scope and requirements are laid down at the beginning of the development
process. Plans regarding the number of iterations, the duration and the scope of each
iteration are clearly defined in advance.
● Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks.

● The division of the entire project into smaller parts helps to minimize the project risk and
to reduce the overall project delivery time requirements.

● Each iteration involves a team working through a full software development life cycle
including planning, requirements analysis, design, coding, and testing before a working
product is demonstrated to the client.
Phases of Agile Model:
Following are the phases in the Agile model are as follows:

● Requirements gathering

● Design the requirements

● Construction/ iteration

● Testing/ Quality assurance

● Deployment

● Feedback
● Agility Principles
● The Agile Alliance defines 12 agility principles for those who want to achieve agility:
 ● 1. Our highest priority is to satisfy the customer through early and continuous
● delivery of valuable software.
●

● 2. Welcome changing requirements, even late in development. Agile processes

● harness change for the customer’s competitive advantage.
●

● 3. Deliver working software frequently, from a couple of weeks to a couple of

● months, with a preference to the shorter timescale.
● 4. Business people and developers must work together daily throughout the
● project.
● 5. Build projects around motivated individuals. Give them the environment and
● support they need, and trust them to get the job done.
●

● 6. The most efficient and effective method of conveying information to and

● within a development team is face-to-face conversation.
●

● 7. Working software is the primary measure of progress.

●

● 8. Agile processes promote sustainable development. The sponsors, developers,

● and users should be able to maintain a constant pace indefinitely.
●

● 9. Continuous attention to technical excellence and good design enhances

● agility.

10. Simplicity—the art of maximizing the amount of work not done—is

essential.

11. The best architectures, requirements, and designs emerge from self–
organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
XP Values
● The five values of XP are communication, simplicity, feedback, courage, and respect and
are described in more detail below.
1.Communication
2.Simplicity
3.Feedback
4.Courage
5.Respect
1.Communication

● Software development is inherently a team sport that relies on communication to transfer

knowledge from one team member to everyone else on the team.

● XP stresses the importance of the appropriate kind of communication – face to face

discussion with the aid of a white board or other drawing mechanism.

2.Simplicity

● Simplicity means “what is the simplest thing that will work?” The purpose of this is to
avoid waste and do only absolutely necessary things such as keep the design of the system
as simple as possible so that it is easier to maintain, support, and revise.

● Simplicity also means address only the requirements that you know about; don’t try to
predict the future.
3.Feedback

● Through constant feedback about their previous efforts, teams can identify areas for
improvement and revise their practices.

● Feedback also supports simple design. Your team builds something, gathers feedback on
your design and implementation, and then adjust your product going forward.
4.courage:

● This definition shows a preference for action based on other principles so that the results
aren’t harmful to the team.

● You need courage to raise organizational issues that reduce your team’s effectiveness.
 ● You need courage to stop doing something that doesn’t work and try something else. You
need courage to accept and act on feedback, even when it’s difficult to accept.
3.Feedback

● Through constant feedback about their previous efforts, teams can identify areas for
improvement and revise their practices.

● Feedback also supports simple design. Your team builds something, gathers feedback on
your design and implementation, and then adjust your product going forward.
4.courage:

● This definition shows a preference for action based on other principles so that the results
aren’t harmful to the team.

● You need courage to raise organizational issues that reduce your team’s effectiveness.

● You need courage to stop doing something that doesn’t work and try something else. You
need courage to accept and act on feedback, even when it’s difficult to accept.

Scrum
● Scrum is an agile process most commonly used for product development, especially
software development.

● Scrum is a project management framework that is applicable to any project with

aggressive deadlines, complex requirements and a degree of uniqueness.

● In Scrum, projects move forward via a series of iterations called sprints. Each sprint is
typically two to four weeks long.
● Scrum Overview - Introduction to Scrum Terms
1.Scrum team:

● A typical scrum team has between five and nine people, but Scrum projects can easily
scale into the hundreds. However, Scrum can easily be used by one-person teams and often
is.
 ● This team does not include any of the traditional software engineering roles such as
programmer, designer, tester or architect. Everyone on the project works together to
complete the set of work they have collectively committed to complete within a sprint.

2.Product owner: The product owner is the project’s key stakeholder and represents users,
customers and others in the process.

● The product owner is often someone from product management or marketing, a key
stakeholder or a key user.
3.Scrum Master: The Scrum Master is responsible for making sure the team is as productive as
possible.

● The Scrum Master does this by helping the team use the Scrum process, by removing
impediments to progress, by protecting the team from outside, and so on.

4.Product backlog: The product backlog is a prioritized features list containing every desired
feature or change to the product.

● Note: The term “backlog” can get confusing because it’s used for two different things. To
clarify, the product backlog is a list of desired features for the product. The sprint backlog
is a list of tasks to be completed in a sprint.
5.Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held, during
which the product owner presents the top items on the product backlog to the team.

● The Scrum team selects the work they can complete during the coming sprint. That work
is then moved from the product backlog to a sprint backlog, which is the list of tasks
needed to complete the product backlog items the team has committed to complete in the
sprint.

6.Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted.
This meeting helps set the context for each day’s work and helps the team stay on track. All team
members are required to attend the daily scrum.

7.Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they accomplished
during the sprint.

8.Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective,
which is a meeting during which the team (including its ScrumMaster and product owner) reflect
on how well Scrum is working for them and what changes they may wish to make for it to work
even better.
 ●

● This graphic is an introduction to the essential elements of using Scrum for agile software
development. On the left, we see the product backlog, which has been prioritized by the
product owner and contains everything desired in the product that’s known at the time.
The two to four week sprints are shown by the larger green circle.

● At the start of each sprint, the team selects some amount of work from the product backlog
and commits to completing that work during the sprint. Part of figuring out how much they
can commit to is creating the sprint backlog, which is the list of tasks (and an estimate of
how long each will take) needed to deliver the selected set of product backlog items to be
completed in the sprint.

● At the end of each sprint, the team produces a potentially shippable product increment —
i.e. working, high-quality software. Each day during the sprint, team members meet to
discuss their progress and any impediments to completing the work for that sprint. This is
known as the daily scrum, and is shown as the smaller green circle above.
● What is kanban
What is kanban?

● Kanban is a popular framework used to implement agile and DevOps software

development.

● It requires real-time communication of capacity and full transparency of work. Work

items are represented visually on a kanban board, allowing team members to see the state
of every piece of work at any time.
 ● Agile software development teams today are able to leverage these same JIT principles by
matching the amount of work in progress (WIP) to the team's capacity. This gives teams
more flexible planning options, faster output, clearer focus, and transparency throughout
the development cycle.
● Kanban boards

● The work of all kanban teams revolves around a kanban board, a tool used to visualize
work and optimize the flow of the work among the team. While physical boards are
popular among some teams, virtual boards are a crucial feature in any agile software
development tool for their traceability, easier collaboration, and accessibility from multiple
locations.

● A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However,
depending on a team's size, structure, and objectives, the workflow can be mapped to meet
the unique process of any particular team.

● The kanban methodology relies upon full transparency of work and real-time
communication of capacity, therefore the kanban board should be seen as the single source
of truth for the team's work.
●

Kanban cards
● The main purpose of representing work as a card on the kanban board is to allow team
members to track the progress of work through its workflow in a highly visual manner.

● Kanban cards feature critical information about that particular work item, giving the entire
team full visibility into who is responsible for that item of work, a brief description of the
job being done, how long that piece of work is estimated to take, and so on.

● Cards on virtual kanban boards will often also feature screenshots and other technical
details that is valuable to the assignee.

● Allowing team members to see the state of every work item at any given point in time, as
well as all of the associated details, ensures increased focus, full traceability, and fast
identification of blockers and dependencies.