Department of

Computer
Engineering

UNIT 1
Introduction and
Software Process
Models

Subject Code:
01CE0607
 • Software engineering
• Dual role of software
• Software Crisis history
• Various Myths Associated with Software
• Different Software Process Models
• The Linear Sequential Model
• The Prototyping Model
Contents • The RAD Model
• Evolutionary Process Models
• Component-Based Development
• Process, Product and Process
• Agile Method
• Manifesto
• Various Agile Modelling Techniques: XP, Scrum,
Crystal
 ●As technology advances, the ability to build quality
software while considering design, development,
security, and maintenance is sought after amongst all
kinds of companies, from finance and banking to
healthcare and national security.
Why ●Software Engineering applies the knowledge and
Software theoretical understanding gained through computer
science to building high-quality software products. As a
Engineeri maturing discipline, software is becoming more and
more important in our everyday lives.
ng? ●According to the Bureau of Labor Statistics’
Occupational Outlook Handbook, 2014-15 Edition,
“software engineers are among the occupations
projected to grow the fastest and add the most new jobs
over the 2012-2022 decade, resulting in excellent job
prospects.”
●Enable to understand different phases of software
development
●Enables to appreciate their role and contribution in
different phases of software development
●Introduce well known methods to analyse requirement
of a client and to design a system that meet these
requirements
●Help to realise the need for good practices in
developing software
●Introduce effective methods of testing software
●Help to understand the importance of adhering to the
quality standards
 • Software encompasses:
1. Instructions (computer programs) that
when executed provide desired features,
What is function, and performance
Software? 2. Data structures that enable the
programs to store and manipulate
information
3. Documentation that describes the
operation and use of the programs.
 • Software products may be of two types
1.Generic products:-
Software
Developed to be sold to a range of different
Products customers
2.Customized products:-
developed for a single customer according
to their specification
 Application
Software

Web-based System
software software

Software Software

Application
Artificial
intelligence
Applicatio Real-time
software. n software
Domains
Domains
Embedded Business
software software

Engineerin
g/ scientific
software
 The application of a
What is systematic, disciplined,
Software quantifiable approach to the
Engineering development, operation, and
?
maintenance of software
 • Software Engineering is the science and
What is art of building (designing and writing
programs) a software systems that are:
Software 1. on time
Engineering 2. on budget
? 3. with acceptable performance
4. with correct operation
Product Development from an IT failures perspective
1 2 3 4 5

© http://www.projectcartoon.com/
10
6 7 8 9
 Dual role of software:
1. A Product
• Information transformer
• Producing, managing, acquiring,
Dual role of modifying, displaying, or transmitting
information
software 2. The vehicle for delivering a product
• The control of the computer(ex. OS)
• The communication of information(ex.
Networking software)
• Helps build other software (ex.
Software Tools)
 Change
Request

System Impact
Dual role of Release Analysis

software

System Release
Update Planning
 When modern computer is built, it is
necessary to answer the following
questions:
• Why does it take so long to get software
Dual role of finished?
software • Why are development costs so high?
• Why can't we find all the errors before we
give the software to customers?
• Why do we continue to have difficulty in
measuring progress as software is being
developed and maintained?
 Increasing Increasing Increasing
Demand Complexity Challenges

Software:
A Crisis on SOFTWARE CRISIS
the
Horizon
Same Same Same
Workforce Method Tools
 • Maintenance cost of software is as
expensive as development cost
• Projects was running over-time
Causes of
Software • Less efficient

Crisis • Low quality

• Software often did not meet requirements
• Software was never delivered on time
Solution
of
SOFTWARE ENGINEERING
Software
Crisis
 ●Reduction in software Over-Budget
●The quality of software must be high.
●Less time needed for software project
Guidelines ●Experience team members on
software project
●Software must be delivered on time.
 1.USABILITY

2.REUSABILITY

Software 3.FLEXIBILITY

Quality 4.MAINTAINABLITY
Attributes
5.PORTABILITY

6.RELIABILITY

7. FUNCTIONALITY
 1. Software is developed or engineered, it is
not manufactured
• It is not manufactured like hardware
Software • The manufacturing phase for hardware
Characteristi can introduce quality problems that
cs are nonexistent (or easily corrected)
for software
• Both require the construction of a
"product" but the approaches are
different.
 2. Software doesn't "wear out"

Software
Characteristi
cs

Failure curve for hardware

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressman

 2. Software doesn't "wear out"

Software
Characteristi
cs

Idealized and actual failure curves for software

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressman
 2. Software doesn't "wear out"
• When a hardware component wears
out, it is replaced by a spare part.
Software • There are no software spare parts.
Characteristi • Every software failure indicates an
cs error in design or in the process
through which design was translated
into machine executable code.
• Software maintenance involves
considerably more complexity than
hardware maintenance.
 3. The industry is moving toward
component-based assembly, most
Software software continues to be custom built
Characteristi • Component reused in many different
programs
cs
• Modern reusable components are
created so that the engineers can
concentrate on truly innovative
elements of the design.
• In hardware, component reuse is a
natural part of the engineering process
 • Misleading attitudes that leads to
serious problem called myths
Various
Myths
1. Management Myths
Associate
2. Customer Myths
d with
3. Practitioner's(develo
Software
per) Myths
 • Myth 1: We already have a book that's full
of standards and procedures for building
software which is enough.
• Reality:
Managemen ✓ The book of standards may very well
exist, but is it used?
t Myths ✓ Are software practitioners aware of its
existence?
✓ Does it reflect modern software
engineering practice?
✓ Is it complete? Is it streamlined to
improve time to delivery while still
maintaining a focus on quality?
 • Myth 2: We have the newest computers
and tools
• Reality:
Managemen ✓ It takes much more than the latest
t Myths model mainframe, workstation, or PC to
do high-quality software development
✓ CASE tools are more important than
hardware for achieving good quality
and productivity
✓ Majority of software developers still do
not use tools effectively
 • Myth 3: We can add more programmers
and catch up the schedule
• Reality:
✓ Software development is not a
Managemen mechanistic process like manufacturing

t Myths ✓ As new people are added, people who

were working must spend time
educating the newcomers thereby
reduce the amount of time spent on
productive development effort
✓ People can be added but only in a
planned and well-coordinated manner
 • Myth 4: If I decide to outsource the
software project to a third party, I can
just relax and let that firm build it.

Managem • Reality:

ent Myths ✓ If an organization does not

understand how to manage and
control software projects internally,
it will invariably struggle when it
outsources software projects.
 • Myth 1: A general statement of objectives
is sufficient to begin writing programs—
we can fill in the details later.
• Reality:
Customer
✓ A formal and detailed description of
myths software is essential.
✓ Detailed requirements gathered with
effective communication between
customer and developer.
 • Myth 2: Project requirements continually
change, but change can be easily
accommodated because software is
flexible
Customer • Reality:
myths ✓ Software requirements change, but the
impact of change varies with the time
at which it is introduced.
✓ Early requests for change can be
accommodated easily.
 • Myth 2: Project requirements continually
change, but change can be easily
accommodated because software is
flexible

Customer
myths

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressma

 • Myth 1: Once we write the program and
get it to work, our job is done.
Practitioner' • Reality:
s ✓ The sooner you begin 'writing code', the
(Developer) longer it'll take you to get done.
myths ✓ Industry data indicate that between
60% to 80% of all effort expended on
software will be expended after it is
delivered to the customer for the first
time
 • Myth 2: I can not achieve quality until
program is running

Practitioner' • Reality:
s ✓ One of the most effective software
quality assurance mechanisms can be
(Developer) applied from the beginning of a project
myths —the formal technical review.
✓ Software reviews are a "quality filter"
that have been found to be more
effective than testing for finding certain
classes of software defects.
 • Myth 3: The only deliverable work product
for a successful project is the working
Practitioner' program.
s • Reality:
(Developer) ✓ A working program is only one part of a
software configuration
myths
✓ Documentation, Model and plans
provides a foundation for successful
engineering and, more important,
guidance for software support.
 • Myth 4: Software engineering is about
Practitioner' creating unnecessary documentation.
s • Reality:
(Developer) ✓ Software engineering is not about
myths creating documents. It is about creating
quality.
✓ Better quality leads to reduced rework.
And reduced rework results in faster
delivery times.
 CASE Tools

Software How to’s

Engineering:
A Layered Bedrock
Framework

Technology

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressman

 Quality Focus:
Software • Any engineering approach must rest
on an organizational commitment to
Engineering: quality.
A Layered • Total quality management fosters a
Technology continuous process improvement
culture.
• The bedrock that supports software
engineering is a quality focus.
 Process Layer:
• The foundation for software
engineering is the process layer
• It covers all activities, actions and
Software tasks required to be carried out for
Engineering: software development
A Layered • Process defines a framework for a set
of key process areas (KPAs)
Technology
• KPA establish the context in which
technical methods are applied, work
products (models, documents, data,
reports, forms, etc.) are produced,
milestones are established, quality is
 Methods:
• Software engineering methods provide
Software the technical how-to's for building
Engineering: software.
A Layered • It provides the technical way to
implement the software.
Technology
• Methods encompass a broad array of
tasks that include requirements
analysis, design, program
construction, testing, and support.
 Tools:
• Software engineering tools provide
Software automated or semi automated support
for the process and the methods.
Engineering:
• The tools are integrated i.e the
A Layered information created by one tool can be
Technology used by the other tool.
• CASE(computer-aided software
engineering) tools automate many of
the activities involved in various life
cycle phases.
Software
Process
Framework

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressman

 • Define a small number of framework
activities that are applicable to all
software projects, regardless of their size
or complexity
Software • A process is a collection of activities,
Process actions and tasks that are performed
Framework when some work product is to be created
• Each framework activities are divided
into set of task.
• Each task sets identifies work to be
completed, product to be produced,
quality assurance points & milestones to
 • A process defines who is doing what,
Why when and how to reach a certain goal.
Software • To deliver software in timely manner
Process • To deliver qualitative product for those
Framework? who have given proposal for software
development and those who will use
software
 • Communication:
✓ Communication with Customers /
Generic stakeholders to understand project
requirements for defining software
Process features/functionality
Framework • Planning:
Activities
✓ Software Project Plan
✓ It describes technical task, risks,
resources, product to be produced &
work schedule
 • Modeling:
✓ Creating models to understand
requirements and shows design of
Generic software to developers as well as
customers to achieve requirements
Process
• Construction:
Framework
✓ Code generation(either manual or
Activities automated or both) and Testing(to
uncover error in the code)
• Deployment:
✓ Delivery to the customer for evaluation,
Customer provide feedback and
Process
Flow

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressman

Process
Flow

Pic Courtesy : Software Engineer - A practitioner’s Approach By Roger Pressman

 Umbrella activities applied throughout the
software project & help a software team to
manage and control progress, quality, change &
risks
• Software project tracking and control: It
allows the software team to assess progress
Umbrella against the project plan and take any
Activities necessary action to maintain the schedule.
• Formal technical reviews: Assesses software
engineering work products in an effort to
uncover and remove errors before they are
propagated to the next activity.
• Software quality assurance: Defines and
conducts the activities required to ensure
software quality.
 • Document preparation and production: It
encompasses (includes) the activities required
to create work products such as models,
documents, logs, forms and lists.
• Reusability management: It defines criteria for
Umbrella work product reuse (including software
Activities components) and establishes mechanisms to
achieve reusable components
• Measurement: Defines and collects process,
project and product measures that assist the
team in delivering software that meets
stakeholders’ needs.
• Risk management: Evaluates risks that may
affect the outcome of the project or the
 • Process models prescribe a distinct set of
activities, actions, tasks, milestones, and
work products required to engineer high
quality software.
Software • Process models are not perfect, but
provide roadmap for software engineering
Process work.
Models • Software models provide stability, control,
and organization to a process that if not
managed can easily get out of control
• Software process models are adapted to
meet the needs of software engineers and
managers for a specific project.
 • Process model is selected based on
different parameters
✓ Type of the project & people
Software ✓ Complexity of the project
Process ✓ Size of team
Models ✓ Expertise of people in team
✓ Working environment of team
✓ Software delivery deadline
 1.The Linear Sequential Model
2.Prototyping Model
Software 3.The RAD Model
Process 4.Evolutionary Process Models
Models 5.Component-Based Development
 COMMUNICATION

1. The
Linear PLANNING

Sequential
Model or
MODELLING
CODING

Waterfall CONSTRUCTION

Model or
TESTING

Classic Life DEPLOYMENT

Cycle
 • Communication:
1. The ✓ Requirement gathering and analysis
Linear ✓ Requirement specification(SRS)
Sequential • Planning:
Model or ✓ Assessing progress against the project
plan.
Waterfall ✓ Perform required action to maintain
Model or schedule
Classic Life • Modelling:
Cycle ✓ To transform the requirements
specified in the SRS document into a
structure that is suitable for
implementation
 • Construction:
✓ Coding and Testing
1. The ✓ Unit testing, Integration and System
Linear testing
• Deployment:
Sequential ✓ Maintenance
Model or o Corrective Maintenance: Correct
Waterfall errors that were not discovered in
development phase
Model or o Perfective Maintenance: To enhance
the functionalities of the system
Classic based on the customer’s request
Life Cycle o Adaptive Maintenance: To port the
software to work in a new
environment
 • Requirements are very well known, clear
and fixed
• Product definition is stable
When to • Technology is understood
use? • There are no ambiguous requirements
• Ample resources with required expertise
are available freely
• The project is short
 • Simple and easy to understand.
• Phases in this model are processed one at
Advantages a time.
of the • Each stage in the model is clearly defined.
• This model has very clear and well
Linear understood milestones.
Sequential • Reinforces good habits: define-before-
Model design, design-before-code.
• This model works well for smaller projects
and projects where requirements are well
understood.
 • It is often difficult for the customer to state
all requirements explicitly.
Disadvantag • The model implies that you should
es of the attempt to complete a given stage before
moving on to the next stage
Linear • Some teams sit idle for other teams to
Sequential finish
Model • Appropriate when the requirements are
well-understood and changes will be fairly
limited during the design process.
2.The
Prototyping
Model

Pic Courtesy : https://www.geeksforgeeks.org2

 ●Requirement Gathering
●Quick Design
The ●Build a Prototype
Prototypin ●Initial User Evaluation
g Model ●Refining Prototype
●Implement Product and Maintain
 • It can be used as standalone process
model. Prototype can be serve as “the
first system”.
• Model assist software engineer and
customer to better understand what is to
The be built when requirement are fuzzy.
Prototyping • Generates working software quickly and
Model early during the software life cycle.
• Both customers and developers like the
prototyping paradigm.
• Customer/End user gets a feel for the
actual system
• Developer get to build something
 • A customer defines a set of general
objectives for software but does not
identify detailed input, processing, or
When to output requirements.
use? • The developer may be unsure of the
efficiency of an algorithm, the
adaptability of an operating system, or
the form that human/machine interaction
should take.
 ●Rapid Throwaway
Types of ●Evolutionary Prototype
Prototype ●Incremental Prototype
 • The customers get to see the partial
product early in the life cycle. This
ensures a greater level of customer
satisfaction and comfort.
• New requirements can be easily
Advantages accommodated as there is scope for
refinement.
• Missing functionalities can be easily
figured out.
• Errors can be detected much earlier
thereby saving a lot of effort and cost
and enhance the quality
 • Costly
• Too much variation in requirements each
time the prototype is evaluated by the
customer.
Disadvantag • It is very difficult for the developers to
accommodate all the changes demanded
es by the customer.
• Uncertainty in determining the number of
iterations
• Developers in a hurry to build prototypes
may end up with sub-optimal solutions.
• The customer might lose interest in the
 • It is based on prototyping and iterative
development with minimal planning
3. RAD involved.
(Rapid • The functional modules are developed in
parallel as prototypes and are integrated
Application to make the complete product for faster
Developmen product delivery.
t) Model • 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 (e.g., 60 to 90
RAD
(Rapid
Application
Developm
ent) Model
RAD
(Rapid
Application
Developm
ent) Model
 • The RAD model is a “high-speed”
adaptation of the linear sequential model
in which rapid development is achieved
by using component-based construction.
3. RAD • The developments are time boxed,
(Rapid delivered and then assembled into a
Application working prototype.

Developmen • This can quickly give the customer

something to see and use and to provide
t) Model feedback.
1. Requirements Planning
• It involves the use of various techniques
used in requirements elicitation like
brainstorming to understand business
2. User Description
• This phase consists of taking user
feedback and building the prototype
using developer tools.
3. Construction
• In this phase, refinement of the
prototype and delivery takes
place. All the required modifications
and enhancements are too done in
this phase.
 4. Cutover
• All the interfaces between the
independent modules developed by
separate teams have to be tested
3. RAD properly.
(Rapid • Use of powerfully automated tools
Application • This is followed by acceptance testing by
Developmen the user.
t) Model When to Use ?
• There is a need to create a system that can
be modularized in 2-3 months of time.
• High availability of designers and budget for
modeling along with the cost of automated
 1.Rapid Prototype
• Allows customer to get quick initial
views about the product.
Features of 2. Use of powerful development tool
RAD Model • Development time goes down eg CASE
tool.
3. Active user involvement
• It increases the acceptability of
software.
 • Reduced development time.
• Increases reusability of components.
Advantages
• Quick initial reviews occur.
of RAD
• Encourages customer feedback.
Model
• Integration from very beginning solves a
lot of integration issues.
 • Users can’t be involved continuously.
When not to • Tools and reusable component can’t be
use used.
RAD Model • Highly skilled and specialized developer
are not available.
• Software cannot be a modularized .
 • Produce an increasingly more complete
version of the software with each
iteration.
4.
• Evolutionary Models are iterative.
Evolutionary
• Evolutionary models are:
Process
• Incremental Process Model
Model
• Spiral Model
• Concurrent Development Model
4.
Evolutiona ●Evolutionary model is also referred to as

ry Process the successive versions model and sometimes as

the incremental model.
Model ●The development first develops the core modules
(independent) of the system.
●Each successive version/model of the product is a fully
functioning software capable of performing more work than
the previous versions/model.
●These are useful for very large products, where it is
easier to find modules for incremental implementation.
 4.1
Incremental
Process
Model

Pic Courtesy : Software Engineer - A practitioner’s Approach By

 • Generates working software quickly and
early during the software life cycle.
• It is easier to test and debug during a
Advantages smaller iteration.
of • Customer can respond to each built and
Incremental developer can accommodate those
Process changes.
Model • Lowers initial delivery cost.
• Easier to manage risk because risky
pieces are identified and handled during
iterations.
• Works with small sized team.
 • Needs good planning and design.
• Needs a clear and complete definition of
Disadvantag the whole system before it can be broken
es of down and built incrementally.
Incremental • Problems might cause due to system
Process architecture as such not all requirements
collected up front for the entire software
Model lifecycle
4.2 Spiral
Model

Pic Courtesy :https://www.researchgate.net/publication/224086904

Spiral Model
 • Couples iterative nature of prototyping with
the controlled and systematic aspects.
• Using spiral, software developed in a series of
evolutionary release.
• Early iteration, release might be on paper or
prototype.
• Later iteration, more complete version of
Spiral Model software.
• Divided into framework activities (C,P,M,C,D).
Each activity represent one segment.
• The spiral model is a realistic approach to the
development of large scale system and
software.
• Radius of the spiral represent the cost of the
project.
 ●Identification/Planning
Spiral ●Risk Analysis
Model ●Engineering (Build + Testing)
Phases ●Progress & Customer Feedback
 • When costs and risk evaluation is
important.
When to • For medium to high-risk projects.
• Users are unsure of their needs.
use?
• Requirements are complex.
• Significant changes are expected.
 • Risk Handling
• Good for large projects
• Flexibility in Requirements
• Customer Satisfaction
• Prototyping Model also support risk
Advantages handling, but the risks must be identified
completely before the start of the
development work of the project. But in real
life project risk may occur after the
development work starts, in that case, we
cannot use Prototyping Model
 • Complex as it is risk driven.
• Expensive
Disadvantag • Too much dependable on Risk Analysis
es • Difficulty in time management
• Requires knowledgeable and experienced
staff
4.3
Concurrent
Developmen
t Model

ic Courtesy: R.Pressman
 • It represented schematically as series of
major technical activities, tasks, and their
associated states.
• It is often more appropriate for system
Concurrent engineering projects where different
Developmen engineering teams are involved.
t Model • The activity “modeling” may be in any one
of the states for a given time.
• All activities exist concurrently but reside in
different states.
 • E.g. The “analysis” activity (existed in the
none state while initial customer
communication was completed) now makes
a transition into the under development
Concurrent state.
Developmen • Analysis activity moves from the under
development state into the awaiting
t Model changes state only if customer indicates
changes in requirements.
• Series of event will trigger transition from
state to state.
 • Applicable to all types of software
development processes.
Advantages • Easy to understand and use.
• It provide an accurate picture of the current
state of a project.
 • It needs better communication between the
team members. This may not be achieved
Disadvantag all the time.
es • It requires to remember the status of the
different activities.
 • Component-based development (CBD)
model incorporates many of the
5. characteristics of the spiral model.
Component- • It is evolutionary by nature and iterative
based approach to create software.
• CBD model creates applications from
development prepackaged software components (called
classes).
Component-
based
development
 • The engineering activities begin with identification of
candidate components.
• Classes created in past software engineering projects
are stored in a class library or repository.
• Once candidate classes are identified, the class
library is searched to determine if these classes
Component- already exist.
based • If class is already available in library extract and
reuse it.
development •
If class is not available in library, it is engineered or
developed using object-oriented methods.
• The first iteration of the application to be built is then
composed, using classes extracted from the library
and any new classes built to meet the unique needs
of the application.
 • CBD model leads to software reusability.
• Based on studies, CBD model leads to 70 %
Advantages reduction in development cycle time.
• 84% reduction in project cost.
• Productivity is very high.
 Product

In the context of software engineering, Product includes any

software manufactured based on the customer’s request.

Product This can be a problem solving software or computer based

and system. It can also be said that this is the result of a project.

Process Process

Process is a set of sequence steps that have to be followed

to create a project. The main purpose of a process is to

improve the quality of the project.

 • If the process is weak, the end product will suffer. But
an over-reliance on process is also dangerous.
• People derive as much satisfaction from the creative
process as they do from the end product.
• Like an artist enjoys the brush strokes as much as
the framed result.
Product and • A writer enjoys the search for the proper metaphor
Process (comparison) as much as the finished book.
• As creative software professional, you should also
derive as much satisfaction from the process as the
end product.
• The duality of product and process is one important
element in keeping creative people engaged as
software engineering continues to evolve.
What is Agile • Agile is a light weight methods that are
Software people based rather than plan based.
Development • It forces development team to focus on
? software rather than design and
documentation.
• The aim is to deliver the working model
of the software quickly to the customer.
What is Agile
Software
Development
?
 ●In the conventional development
method, as the project makes progress
the cost of changes increases non
linearly.
Why Agile ●The Agile methodology allow the
Methodolog software team to accommodate changes
y? late in the software project without drastic
cost and time impact.
●Incremental delivery + Agile practices
=> controlled cost changes
Agile
Software
Developmen
t
 • Agile is a term used to describe approaches
to software development that employs
• Adaptability
What is Agile
• Team collaboration
Software
Development • Incremental development

? • Learning and improvement

• Early delivery
• Encourages flexible responses to change.

© www.eudigital.co
 Customer satisfaction and valuable
software

Dynamic in development

Working software is delivered frequently

Agile
Principles Cooperation between business people and developers

Motivate the project developers

F2F Communication
 Progressive measure

Sustainable development

Attention to technical design

Agile
Principles Simplicity

Need of Self-organizing

Being effective
 • Agile Process addresses this key assumption

What is Agile 1. Difficulty in predicting S/W

requirement(Change) and priority of
Software customer
Development 2. It is difficult to predict how much of
? design is required before Construction.
3. Analysis, Design, Coding and Testing are
not predictable as we might say it is
Manifesto for
Agile
Software
Development

© www.ontoborn.com
 • Project is not very urgent, too complex
or novel
• Project plan & requirements are clear &
Where agile unlikely to change
methodology • Your customer requires neat
not work documentation of each development
cycle
• Unclear understanding of Agile Approach
among Teams
• Big Enterprises where team
collaboration is tough
 Agile Model Waterfall Model
• Agile method proposes incremental • Development of the software flows
and iterative approach to software sequentially from start point to end
design point.
• The agile process is broken into • The design process is not broken
individual models that designers into an individual models
work on

Agile Model • The customer has early and frequent •

opportunities to look at the product
The customer can only see the
product at the end of the project
Vs Waterfall and make decision and changes to
the project

Model • Development process is iterative, •

and the project is executed in short
The development process is
phased, and the phase is much
(2-4) weeks iterations. Planning is bigger than iteration. Every phase
very less. ends with the detailed description
of the next phase.
• It requires close communication with • Developer does not involve in
developers and together analyze requirement and planning process.
requirements and planning Usually, time delays between tests
and coding
 Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method

(DSDM)

Agile Process Scrum

Models
Feature Driven Development (FDD)

Crystal

Agile Modelling (AM)

 • The most widely used agile process,
originally proposed by Kent Beck.
• It is lightweight, efficient, low-risk,
flexible, predictable way to develop a
1. Extreme software.
• Follows Object Oriented approach.
Programmin • Five values of XP:
g (XP) 1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect
 • Constantly changing demands or
requirements
• Customer are not sure about the
When to functionality of the system
use? • Small projects consisting of small teams
as face to face meeting is easier to
achieve
• Projects involving new technology or
Research projects
1. Extreme
Programmin
g (XP)

© www.researchgate.net
 • User story-cards
• Release planning
XP - • Small releases
Planning • Iterative process
• Stand up meetings - F2F at same location
 • Simple design
• It is always good to keep the things
simple to meet the current
requirements
• Spike solution
XP - Design • For answering the tough technical
problem
• Refactoring
• Reduction in the redundancy,
elimination of unused functionalities
• Encourage the use of CRC (class-
responsibility-collaborator) cards
CRC cards (Class-Responsibility-
Collaborator)

©https://www.lucidchart.com/blog/what-is-extreme-programming
XP - Coding • Pair programming - Driver/Supporter.
• Collective code ownership - All
contribute, one person doesn’t become
bottleneck of the project.
• Continuous integration of codes.
 • Unit tests should be automated.
• Encourages regression testing whenever
XP - Testing code is modified.
• Integration and validation testing on daily
basis.
• Acceptance tests are derived from user
stories that have been implemented as
part of software release.
 Weekly Cycle
The Weekly Cycle is synonymous to an iteration

Quarterly Cycle
The Quarterly Cycle is synonymous to a release.
The customer lays out the overall plan for the team in terms of
features desired within a particular quarter
Extra
Slack

The idea behind slack in XP terms is to add some low priority

tasks or stories in your weekly and quarterly cycles that can be

dropped if the team gets behind on more important tasks or

stories.
 • This model is developed by Jeff Sutherland
and Ken Schwaber in 1995.
• Scrum is an agile process model which is
2. Scrum used for developing the complex software
systems.
• It is a lightweight process framework.
• Lightweight means the minimum overhead of
the process in order to maximize the
productivity.
• Iterative and incremental approach.
 • There are small working teams on the
projects due to which there is maximum
communication and minimum overhead.
• The task of people must be partitioned into
small and clean packets/partitions.
Scrum • The process must accommodate the
technical or business changes, if they occur.
Principles • The process should produce software
increments.
• During product building, constant testing and
documentation must be conducted.
• The SCRUM process must produce the
working model of the product whenever
required or demanded.
 • Product Owner
• The product owner is the project’s key stakeholder and
represents users, customers and others in the process.

• Scrum Master
• Typically a Team Leader

Roles • Responsible for enacting Scrum values and practices

• Remove impediments / politics, keeps everyone
productive
(Scrum)
• Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• This team does not include any of the traditional SE
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
Roles
Product
Owner

©warren2lynch.medium.com
Roles
Scrum
Master

©codersera.com
 Product backlog: The product backlog is a prioritized
features list containing every desired feature or
change to the product.
Some more
Terminology

Sprint backlog:The sprint backlog is a list of tasks to

be completed in a sprint.
Scrum

©www.c-sharpcorner.com
 • 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.
Sprint • The Scrum team selects the work they can complete during
Planning 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.
©www.agilemarketing.net
 • Backlog
• It is a list of project requirements or
features that must be provided to the
customer.
• The items can be included in the backlog
Scrum at any time.
Developme • The product manager analyses this list
and updates the priorities as per the
nt Activities requirements.
• Sprint
• These are the work units that are needed
to achieve the requirements mentioned in
the backlogs.
• Typically the sprints have fixed duration or
 • Meetings
• There are 15 minutes daily meetings to
report the completed activities, obstacles
and plan for next activities.(Development
Team)
• Following are three questions that are
Scrum mainly discussed during the meetings.
Developme 1. What are the tasks done since last
nt Activities meeting ?
2. What are the issues that team is
facing ?
3. What are the next activities that are
planned ?
• Demo
• During this phase implemented
 ●Crystal method is an agile software
development approach that focuses primarily
on people and their interactions when working
on a project rather than on processes and
tools
●Properties of Crystal method:
1. Frequent delivery
3. Crystal 2. Reflective improvement
3. Communication
4. Personal Safety
5. Focus
6. Easy access to expert/users
7. Technical Tools
The Crystal Family:

●Crystal method depends on three dimensions:

●First, Team size
●Second, Criticality
●Third, the priority of the project
 ●CLEAR - 6 or less people involved, small
projects, requires some documentation.
●YELLOW - 7 to 20 people, Small to medium
project, feedback is collected from customer,
automated testing is conducted.
●ORANGE - 20-40 people, medium project,
teams are divided as per functional skills, 1-2
years, incremental development with delivery
Crystal every 3-4 months.
● RED - 40-80 people, Large projects, teams
are formed as per work required,
●MAROON - 80-200 people, similar to crystal
red.
●Diamond and Sapphire - very large teams,
used in extremely critical project, high risk is
involved
Crystal
Family
THANK YOU