Department of

Computer Engineering

Chapter 1
Introduction and
Software Process
Models

Subject Code: 01CE0607

Prof. Urvi Dhamecha
 • 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
• The RAD Model
Contents • 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
Why national security.

Software ●Software Engineering applies the knowledge and theoretical

understanding gained through computer science to building

Engineering
high-quality software products. As a maturing discipline,
software is becoming more and more important in our
everyday lives.
? ●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 analyze requirement of a client and
to design a system that meet these requirements.
● Help to realize 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, function, and
What is 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

Software 1. Generic products:-

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
Application
Artificial Software
Real-time
intelligence Application software
software. Domains

Domains
Embedded Business
software software

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

© http://www.projectcartoon.com/
1

10
6 7 8 9
Product Development from an IT failures perspective

© http://www.projectcartoon.com/
 Dual role of software:
1. A Product
• Information transformer
• Producing, managing, acquiring, modifying,
Dual role of 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 finished?
• 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 the SOFTWARE CRISIS

Horizon

Same Same Same

Workforce Method Tools
 • Maintenance cost of software is as expensive as
development cost

Causes of • Projects was running over-time

Software • Less efficient

Crisis • Low quality

• Software often did not meet requirements
• Software was never delivered on time
Solution of
Software SOFTWARE ENGINEERING
Crisis
 ● Reduction in software Over-Budget
● The quality of software must be high.
Guidelines ● Less time needed for software project
● 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 can
Characteristics introduce quality problems that 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
Characteristics

Failure curve for hardware

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

 2. Software doesn't "wear out"

Software
Characteristics

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.
• There are no software spare parts.
Software
Characteristics • Every software failure indicates an 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 continues to be custom built
• Component reused in many different programs
Software
• Modern reusable components are created so that
Characteristics the engineers can concentrate on truly innovative
elements of the design.
• In hardware, component reuse is a natural part of
the engineering process but in software world, it is
has just begun on broad scale.
 • Misleading attitudes that leads to serious
problem called myths
Various
Myths 1. Management Myths
Associated 2. Customer Myths
with
3. Practitioner's(developer)
Software
Myths
 • Myth 1: We already have a book that's full of
standards and procedures for building software which
is enough.
• Reality:
Management ✓ The book of standards may very well exist, but is it
used?
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:
✓ It takes much more than the latest model
Management mainframe, workstation, or PC to do high-quality
Myths 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 mechanistic process
Management like manufacturing

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.
Managemen • Reality:
t 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.
Customer • Reality:
✓ A formal and detailed description of software is
myths 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
• Reality:
Customer ✓ Software requirements change, but the impact of
myths 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 Pressman

 • Myth 1: Once we write the program and get it to work,
our job is done.

Practitioner's • Reality:
✓ The sooner you begin 'writing code', the longer it'll
(Developer) 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
• Reality:
Practitioner's ✓ One of the most effective software quality
(Developer) assurance mechanisms can be applied from the
myths beginning of a project—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 program.

Practitioner'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 creating
unnecessary documentation.
Practitioner's
• Reality:
(Developer)
✓ Software engineering is not about creating
myths 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 quality.
Engineering: A
• Total quality management fosters a continuous
Layered process improvement culture.
Technology • 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 tasks required
Software to be carried out for software development
Engineering: A • Process defines a framework for a set of key
Layered 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
ensured, and change is properly managed
 Methods:
• Software engineering methods provide the
Software technical how-to's for building software.
Engineering: A • It provides the technical way to implement the
Layered software.
Technology • Methods encompass a broad array of tasks that
include requirements analysis, design, program
construction, testing, and support.
 Tools:
• Software engineering tools provide automated or
Software semi automated support for the process and the
methods.
Engineering: A
• The tools are integrated i.e the information
Layered created by one tool can be used by the other tool.
Technology • 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, actions and

tasks that are performed when some work product is
Process to be created
Framework • 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 indicate progress
 • A process defines who is doing what, when and how
to reach a certain goal.
Why Software
• To deliver software in timely manner
Process
• To deliver qualitative product for those who have
Framework? given proposal for software development and those
who will use software
 • Communication:
✓ Communication with Customers / stakeholders to
Generic understand project requirements for defining
software features/functionality
Process
• Planning:
Framework
✓ Software Project Plan: It consist of complete
Activities Estimation and Scheduling for the project
development
✓ It describes work plan, technical task, risks, list of
resources, product to be produced & work schedule..
 • Modeling:
✓ Creating models to understand requirements and
shows design of software to developers as well as
Generic customers to achieve requirements
Process ✓ It consist complete requirement analysis and design
of the project like Algorithm and flowchart.
Framework
Activities ✓ Algorithm is a step by step solution of the problem.
✓ Flowchart shows complete flow diagram of
program.
 • Construction:
✓ Code Generation and coding part.
✓ Coding part implement design details using an
Generic appropriate programming language
Process ✓ Testing checks whether the flow of coding is correct
Framework or not and provide desired output or not.

Activities ✓ Code generation(either manual or automated or

both) and Testing(to uncover error in the code)
• Deployment:
✓ Delivery to the customer for evaluation, Customer
provide feedback and Software Support
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 against the project plan and take
any necessary action to maintain the schedule.
Umbrella
• Formal technical reviews: Assesses software engineering
Activities 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.
• Software configuration management: It manages the effects
of change throughout the software process.
 • 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 work
product reuse (including software components) and
Umbrella establishes mechanisms to achieve reusable components
Activities • 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 quality of the product.
 • Process models prescribe a distinct set of activities,
actions, tasks, milestones, and work products required
to engineer high quality software.
• Process models are not perfect, but provide roadmap
for software engineering work.
Software • Software models provide stability, control, and
Process Models 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
✓ Complexity of the project
Software ✓ Size of team
Process 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 Models 4. Evolutionary Process Models
5. Component-Based Development
 COMMUNICATION

1. The Linear PLANNING

Sequential
Model or MODELLING

Waterfall
CODING

Model or CONSTRUCTION
TESTING

Classic Life DEPLOYMENT

Cycle
 • Communication:
✓ Requirement gathering and analysis
1. The Linear
✓ Software Requirement Specification(SRS)
Sequential document is created
Model or • Planning:
Waterfall ✓ Assessing progress against the project plan.
Model or ✓ Perform required action to maintain schedule
Classic Life • Modelling:
✓ To transform the requirements specified in the
Cycle SRS document into a structure that is suitable for
implementation
 • Construction:
✓ Coding and Testing
1. The Linear
✓ Unit testing, Integration and System testing
Sequential • Deployment:
Model or ✓ Maintenance
Waterfall o Corrective Maintenance: Correct errors that
Model or were not discovered in development phase
o Perfective Maintenance: To enhance the
Classic Life functionalities of the system based on the
Cycle customer’s request
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
• Technology is understood

When to use? • There are no ambiguous requirements

• All the resources are very well prepared and easily
available
• The project is short
 • Simple and easy to understand.
• Phases in this model are processed one at a time.
• Each stage in the model is clearly defined.
Advantages of
• This model has very clear and well understood
the Linear milestones.
Sequential • Reinforces good habits: define-before-design, design-
Model 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.
Disadvantages • The model implies that you should attempt to
complete a given stage before moving on to the next
of the Linear stage
Sequential • Some teams sit idle for other teams to 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
Prototyping ●Initial User Evaluation
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 be built when
requirement are fuzzy.
The • Generates working software quickly and early during
Prototyping the software life cycle.
Model • Both customers and developers like the prototyping
paradigm.
• Customer/End user gets a feel for the actual
system
• Developer get to build something immediately.
 • A customer defines a set of general objectives for
software but does not identify detailed input,
processing, or output requirements.
When to 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 accommodated as
there is scope for refinement.
Advantages • 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
• Reusability for complex projects.
• Flexibility in design.
 • Costly
• Too much variation in requirements each time the
prototype is evaluated by the customer.
• It is very difficult for the developers to accommodate
all the changes demanded by the customer.
Disadvantages • 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 product if
he/she is not satisfied with the initial prototype.
 • It is based on prototyping and iterative development
with minimal planning involved.
• The functional modules are developed in parallel as
3. RAD (Rapid prototypes and are integrated to make the complete
Application product for faster product delivery.
Development) • If requirements are well understood and project
Model 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
days)
RAD (Rapid
Application
Developmen
t) Model
RAD (Rapid
Application
Developmen
t) 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.
• The developments are time boxed, delivered and
3. RAD (Rapid then assembled into a working prototype.

Application • This can quickly give the customer something to see

and use and to provide feedback.
Development)
1. Requirements Planning
Model • It involves the use of various techniques used in
requirements elicitation like brainstorming to
understand business problem
• It also consists of the entire structured plan describing
the critical data, methods to obtain it and then
processing it to form final refined model.
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
properly.
3. RAD (Rapid • Use of powerfully automated tools
Application • This is followed by acceptance testing by the user.
Development) When to Use ?
Model • 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 code generating tools.
• Resources with high business knowledge are available.
 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 of • Quick initial reviews occur.
RAD Model • Encourages customer feedback.
• 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 used.
use • Highly skilled and specialized developer are not
RAD Model available.
• Software cannot be a modularized .
 • Produce an increasingly more complete version of
the software with each iteration.
• Evolutionary Models are iterative.
4. Evolutionary • Evolutionary models are:
Process Model • Incremental Process Model
• Spiral Model
• Concurrent Development Model
4.
Evolutionary
Process ●Evolutionary model is also referred to as 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 Roger Pressman

 • Generates working software quickly and early during
the software life cycle.
• It is easier to test and debug during a smaller
iteration.
Advantages of • Customer can respond to each built and developer
Incremental can accommodate those changes.
Process 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 the whole
system before it can be broken down and built
Disadvantages incrementally.
of Incremental • Problems might cause due to system architecture as
Process Model such not all requirements collected up front for the
entire software 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.
Spiral Model • Later iteration, more complete version of 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 Model ●Risk Analysis
Phases ●Engineering (Build + Testing)
●Progress & Customer Feedback
 • When costs and risk evaluation is important.
• For medium to high-risk projects.
When to use? • Users are unsure of their needs.
• Requirements are complex.
• Significant changes are expected.
 • Risk Handling
• Good for large projects
• Flexibility in Requirements
• Customer Satisfaction
Advantages • Prototyping Model also support risk 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
Disadvantages • Too much dependable on Risk Analysis
• Difficulty in time management
• Requires knowledgeable and experienced staff
4.3 Concurrent
Development
Model

Pic Courtesy: R.Pressman

 • Inactive: No any activity
• Under Development: Any activity performed
Concurrent • Awaiting Changes: If customer wants any changes
Development • Under Review: Testing activity starts
Model Working • Under Revision: Do all required changes
• Baselined: As per SRS document
• Done: Project completed and deployed
 • It represented schematically as series of major technical
activities, tasks, and their associated states.
Concurrent • It is often more appropriate for system engineering
projects where different engineering teams are involved.
Development • The activity “modeling” may be in any one of the states
Model 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.
Development • Analysis activity moves from the under development
Model state into the awaiting 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 all the time.
Disadvantages • It requires to remember the status of the different
activities.
 • Component-based development (CBD) model
incorporates many of the characteristics of the spiral
5. Component- model.
based • It is evolutionary by nature and iterative approach to
create software.
development
• CBD model creates applications from 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.

Component- • Once candidate classes are identified, the class library is searched to
determine if these classes 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 % reduction in
Advantages 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. This can be a problem

Product and solving software or computer based system. It can also be said that this is

Process the result of a project.

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
Product and result.
•A writer enjoys the search for the proper metaphor (comparison)
Process 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.
 • Agile is a light weight methods that are people based
What is Agile rather than plan based.
Software
• It forces development team to focus on software
Development? 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 software team to
Methodology? accommodate changes late in the software project
without drastic cost and time impact.
●Incremental delivery + Agile practices => controlled
cost changes
Agile Software
Development
 • Agile is a term used to describe approaches to software
development that employs
• Adaptability
What is Agile • Team collaboration
Software • Incremental development
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
1. Difficulty in predicting S/W requirement(Change)
What is Agile and priority of customer
Software 2. It is difficult to predict how much of design is
Development? 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 & unlikely to
Where agile change
• Your customer requires neat documentation of each
methodology development cycle
not work • 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
• The customer has early and • The customer can only see the
Agile Model Vs frequent opportunities to look at the
product and make decision and
product at the end of the project

Waterfall Model •
changes to the project
Development process is iterative, • The development process is
and the project is executed in short 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 software.
1. Extreme • Follows Object Oriented approach.
Programming • Five values of XP:
1. Communication
(XP) 2. Simplicity
3. Feedback
4. Courage
5. Respect
 • Constantly changing demands or requirements
• Customer are not sure about the functionality of the
system
When to 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
Programming
(XP)

© www.researchgate.net
 • User story-cards
• Release planning
XP - Planning • Small releases
• 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
• For answering the tough technical problem
XP - Design • 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 code is
XP - Testing 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.

Extra The customer lays out the overall plan for the team in terms of features desired within a particular quarter

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 used for
2. Scrum 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
Principles •
changes, if they occur.
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
• Responsible for enacting Scrum values and practices

Roles (Scrum) • Remove impediments / politics, keeps everyone productive

• 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 at any time.
• The product manager analyses this list and updates the
Scrum priorities as per the requirements.
Development • Sprint
Activities • These are the work units that are needed to achieve
the requirements mentioned in the backlogs.
• Typically the sprints have fixed duration or time box
(1 to 4 weeks).
• Thus sprints allow the team members to work in stable
and short-term environment.
 • 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 mainly discussed
during the meetings.
Scrum 1. What are the tasks done since last meeting ?
Development 2. What are the issues that team is facing ?
Activities 3. What are the next activities that are planned ?
• Demo
• During this phase implemented functionalities are
demonstrated to the customer
• Review:
• Activity to Introspect and Adapt
 ●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
Crystal divided as per functional skills, 1-2 years, incremental
development with delivery 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