K.

RAMAKRISHNAN COLLEGE OF ENGINEERING

(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

Module – I – SOFTWARE PROCESS MODEL

Software Process Model : Generic Process Model – Perspective Process Model – Specialized
Process Model – Unified Process Model – Personal and Team Process Model – Traditional
SDLC vs Agile Development

Software Process Model

A road map that helps you create a timely, high-quality result. The road map that you follow is
called a “software process.” A process was defined as a collection of work activities, actions,
and tasks that are performed when some work product is to be created. Each of these activities,
actions, and tasks reside within a framework or model that defines their relationship with the
process and with one another.
1.1 GENERIC PROCESS MODEL
A generic process framework for software engineering defines five framework activities—
communication, planning, modeling, construction, and deployment. In addition, a set of
umbrella activities—project tracking and control, risk management, quality assurance,
configuration management, technical reviews, and others—are applied throughout the process.

Fig.1.1 A software process framework

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

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

Fig.1.2 Linear process flow

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

Fig.1.3 Iterative process flow

An evolutionary process flow executes the activities in a “circular” manner. Each circuit
through the five activities leads to a more complete version of the software.

Fig.1.4 Evolutionary process flow

A parallel process flow executes one or more activities in parallel with other activities (e.g.,
modeling for one aspect of the software might be executed in parallel with construction of
another aspect of the software).

Fig.1.5 Parallel process flow

For a small software project requested by one person (at a remote location) with simple,
straightforward requirements, the communication activity might encompass little more than a
phone call with the appropriate stakeholder. Therefore, the only necessary action is phone
conversation, and the work tasks (the task set) that this action encompasses are:

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

1. Make contact with stakeholder via telephone.

2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
If the project was considerably more complex with many stakeholders, each with a different
set of) requirements, the communication activity might have six distinct actions : inception,
elicitation, elaboration, negotiation, specification, and validation.
Identifying a Task Set
A task set defines the actual work to be done to accomplish the objectives of a software
engineering action.
Each software engineering action (e.g., elicitation, an action associated with the
communication activity) can be represented by a number of different task sets—each a
collection of software engineering work tasks, related work products, quality assurance points,
and project milestones.
Process pattern
A process pattern describes a process-related problem that is encountered during software
engineering work, identifies the environment in which the problem has been encountered, and
suggests one or more proven solutions to the problem. Stated in more general terms, a process
pattern provides you with a template - a consistent method for describing problem solutions
within the context of the software process. By combining patterns, a software team can solve
problems and construct a process that best meets the needs of a project.
Patterns can be defined at any level of abstraction. In some cases, a pattern might be used to
describe a problem (and solution) associated with a complete process model (e.g., prototyping).
In other situations, patterns can be used to describe a problem (and solution) associated with a
framework activity (e.g., planning) or an action within a framework activity (e.g., project
estimating).

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

Fig.1.6 An example process pattern

The software development process involves several key components to create reliable and
functional software. Here are the essential steps:
1. Communication: The user initiates a request for a desired software product, and the
software organization discusses requirements with the customer1.
2. Requirement Gathering: The development team collects information from
stakeholders about the software’s needs, including user requirements, system
requirements, and functional specifications.
3. Feasibility Study: Algorithms analyze whether the software can meet user
requirements and assess financial, practical, and technological feasibility.
4. System Analysis: Developers plan the project, understand product limitations, and
evaluate its impact on the organization.
5. Software Design: Based on requirements and analysis, a design plan for the software
is created.
6. Coding: Writing the actual code that forms the backbone of the software.
7. Testing: Ensuring the software is bug-free and meets user expectations.
8. Integration: Combining different components of the software into a cohesive whole.
9. Implementation: Deploying the software for use.
10. Operation and Maintenance: Regular updates and troubleshooting to ensure smooth
operation.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

1.2 PERSPECTIVE PROCESS MODEL

Prescriptive process models were originally proposed to bring order to the chaos of software
development.
All software process models can accommodate the generic framework activities described in,
but each applies a different emphasis to these activities and defines a process flow that invokes
each framework activity (as well as software engineering actions and tasks) in a different
manner.
1.2.1 Waterfall model
The Waterfall Model There are times when the requirements for a problem are well
understood—when work flows from communication through deployment in a reasonably linear
fashion. This situation is sometimes encountered when well-defined adaptations or
enhancements to an existing system must be made (e.g., an adaptation to accounting software
that has been mandated because of changes to government regulations). It may also occur in a
limited number of new development efforts, but only when requirements are well defined and
reasonably stable. The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed software.

Fig.1.7 The waterfall model

V model
A variation in the representation of the waterfall model is called the V-model. The V-model
depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities. As a software team moves down
the left side of the V, basic problem requirements are refined into progressively more detailed
and technical representations of the problem and its solution. Once code has been generated,

the team moves up the right side of the V, essentially performing a series of tests (quality
assurance actions) that validate each of the models created as the team moved down the left
CGB1203- Agile Development Methodologies
Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

side. In reality, there is no fundamental difference between the classic life cycle and the V-
model. The V-model provides a way of visualizing how verification and validation actions are
applied to earlier engineering work.

Fig.1.8 The V model

1.2.2 Incremental Process Models
The incremental model combines elements of linear and parallel process flows. The
incremental model applies linear sequences in a staggered fashion as calendar time progresses.
When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features (some known, others unknown)
remain undelivered.

Fig.1.9 The incremental model

The core product is used by the customer (or undergoes detailed evaluation). As a result of use
and/or evaluation, a plan is developed for the next increment. The plan addresses the
modification of the core product to better meet the needs of the customer and the delivery of
additional features and functionality. This process is repeated following the delivery of each
increment, until the complete product is produced.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

The incremental process model focuses on the delivery of an operational product with each
increment. Early increments are stripped-down versions of the final product, but they do
provide capability that serves the user and also provide a platform for evaluation by the user.
1.2.3 Evolutionary Process Model
Evolutionary models are iterative. They are characterized in a manner that enables you to
develop increasingly more complete versions of the software.
1.2.3.1 Prototyping
Prototyping - 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. In these, and
many other situations, a prototyping paradigm may offer the best approach.

Fig.1.10 The prototyping paradigm

The prototyping paradigm begins with communication. You meet with other stakeholders to
define the overall objectives for the software, identify whatever requirements are known, and
outline areas where further definition is mandatory. A prototyping iteration is planned quickly,
and modeling (in the form of a “quick design”) occurs.
A quick design focuses on a representation of those aspects of the software that will be visible
to end users (e.g., human interface layout or output display formats). The quick design leads to
the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who
provide feedback that is used to further refine requirements. Iteration occurs as the prototype

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to
better understand what needs to be done.
1.2.3.2 The Spiral Model
The spiral model is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the waterfall model. It provides the
potential for rapid development of increasingly more complete versions of the software.
Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced.

Fig.1.11 A typical spiral model

A spiral model is divided into a set of framework activities defined by the software engineering
team. Anchor point milestones—a combination of work products and conditions that are
attained along the path of the spiral—are noted for each evolutionary pass. The first circuit
around the spiral might result in the development of a product specification; subsequent passes
around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software. Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from
the customer after delivery.
The spiral model is a realistic approach to the development of large-scale systems and software.
It maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reflects the real world. The

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

spiral model demands a direct consideration of technical risks at all stages of the project and,
if properly applied, should reduce risks before they become problematic.
1.2.4 Concurrent Models
The concurrent development model, sometimes called concurrent engineering, allows a
software team to represent iterative and concurrent elements of any of the process models. This
model provides a schematic representation of one software engineering activity within the
modeling activity using a concurrent modeling approach. The activity modelling may be in any
one of the states noted at any given time. Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented in an analogous manner. All software
engineering activities exist concurrently but reside in different states.

Fig.1.12 The concurrent process model

Early in a project the communication activity has completed its first iteration and exists in the
awaiting changes state. The modeling activity which existed in the inactive state while initial
communication was completed, now makes a transition into the under development state. If,
however, the customer indicates that changes in requirements must be made, the modeling
activity moves from the under development state into the awaiting changes state. Concurrent
modeling defines a series of events that will trigger transitions from state to state for each of
the software engineering activities, actions, or tasks. For example, during early stages of design
(a major software engineering action that occurs during the modeling activity), an

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

inconsistency in the requirements model is uncovered. This generates the event analysis model
correction, which will trigger the requirements analysis action from the done state into the
awaiting changes state.
1.3 SPECIALIZED PROCESS MODEL
Specialized process models take on many of the characteristics of one or more of the traditional
models presented. However, these models tend to be applied when a specialized or narrowly
defined software engineering approach is chosen.
1.3.1 Component-Based Development
The component-based development model incorporates many of the characteristics of the spiral
model. It is evolutionary in nature, demanding an iterative approach to the creation of software.
However, the component-based development model constructs applications from prepackaged
software components. Modeling and construction activities begin with the identification of
candidate components. These components can be designed as either conventional software
modules or object-oriented classes or packages of classes.
The component-based development model incorporates the following steps:
1. Available component-based products are researched and evaluated for the application
domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
The component-based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits.
1.3.2 The Formal Methods Model
The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify, develop, and verify
a computer-based system by applying a rigorous, mathematical notation. A variation on this
approach, called cleanroom software engineering , is currently applied by some software
development organizations. When formal methods are used during design, they serve as a basis
for program verification and therefore enable you to discover and correct errors that might
otherwise go undetected. The formal methods model offers the promise of defect-free software.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

 The development of formal models is currently quite time consuming and expensive.
 Because few software developers have the necessary background to apply formal
methods, extensive training is required.
 It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
1.3.3 Aspect-Oriented Software Development
As modern computer-based systems become more sophisticated (and complex), certain
concerns—customer required properties or areas of technical interest—span the entire
architecture. When concerns cut across multiple system functions, features, and information,
they are often referred to as crosscutting concerns. Aspectual requirements define those
crosscutting concerns that have an impact across the software architecture. Aspect-oriented
software development (AOSD), often referred to as aspect-oriented programming (AOP).
AOP is a relatively new software engineering paradigm that provides a process and
methodological approach for defining, specifying, designing, and constructing aspects
“mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting
concern”.
It is likely that such a process will adopt characteristics of both evolutionary and concurrent
process models. The evolutionary model is appropriate as aspects are identified and then
constructed. The parallel nature of concurrent development is essential because aspects are
engineered independently of localized software components and yet, aspects have a direct
impact on these components. Hence, it is essential to instantiate asynchronous communication
between the software process activities applied to the engineering and construction of aspects
and components.
1.4 UNIFIED PROCESS MODEL
The Unified Process is an attempt to draw on the best features and characteristics of traditional
software process models, but characterize them in a way that implements many of the best
principles of agile software development. The Unified Process recognizes the importance of
customer communication and streamlined methods for describing the customer’s view of a
system.
Components of unified process model
1. Communication

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

2. Planning
3. Modeling
4. Construction
5. Deployment

Fig.1.13 The unified process

Five generic framework activities or phases of Unified process:
The inception phase of the UP encompasses both customer communication and planning
activities. By collaborating with stakeholders, business requirements for the software are
identified; a rough architecture for the system is proposed; and a plan for the iterative,
incremental nature of the ensuing project is developed.
The elaboration phase encompasses the communication and modeling activities of the generic
process model. Elaboration refines and expands the preliminary use cases that were developed
as part of the inception phase and expands the architectural representation to include five
different views of the software—the use case model, the requirements model, the design model,
the implementation model, and the deployment model.
The construction phase of the UP is identical to the construction activity defined for the
generic software process. Using the architectural model as input, the construction phase
develops or acquires the software components that will make each use case operational for end
users. To accomplish this, requirements and design models that were started during the
elaboration phase are completed to reflect the final version of the software increment. All
necessary and required features and functions for the software increment (i.e., the release) are
then implemented in source code. As components are being implemented, unit tests are
designed and executed for each. In addition, integration activities (component assembly and
CGB1203- Agile Development Methodologies
Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

integration testing) are conducted. Use cases are used to derive a suite of acceptance tests that
are executed prior to the initiation of the next UP phase.
The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) activity. Software
is given to end users for beta testing and user feedback reports both defects and necessary
changes. In addition, the software team creates the necessary support information (e.g., user
manuals, troubleshooting guides, installation procedures) that is required for the release. At the
conclusion of the transition phase, the software increment becomes a usable software release.
The production phase of the UP coincides with the deployment activity of the generic process.
During this phase, the ongoing use of the software is monitored, support for the operating
environment (infrastructure) is provided, and defect reports and requests for changes are
submitted and evaluated.

1.5 PERSONAL AND TEAM PROCESS MODEL

The best software process is one that is close to the people who will be doing the work. If a
software process model has been developed at a corporate or organizational level, it can be
effective only if it is amenable to significant adaptation to meet the needs of the project team
that is actually doing software engineering work.
1.5.1 Objectives of PSP :
The aim of PSP is to give software engineers with the regulated methods for the betterment
of personal software development processes. The PSP helps software engineers to:
 Improve their approximating and planning skills.
 Make promises that can be fulfilled.
 Manage the standards of their projects.
 Reduce the number of faults and imperfections in their work.
1.5.2 Personal Software Process (PSP) framework activities
Every developer uses some process to build computer software. The process may be haphazard
or ad hoc; may change on a daily basis; may not be efficient, effective, or even successful; but
a “process” does exist.
The PSP model defines five framework activities:

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

Planning: This activity isolates requirements and develops both size and resource estimates.
In addition, a defect estimate (the number of defects projected for the work) is made. All
metrics are recorded on worksheets or templates. Finally, development tasks are identified and
a project schedule is created.
High-level design: External specifications for each component to be constructed are developed
and a component design is created. Prototypes are built when uncertainty exists. All issues are
recorded and tracked.
High-level design review: Formal verification methods are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
Development: The component-level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
Postmortem: Using the measures and metrics collected (this is a substantial amount of data
that should be analyzed statistically), the effectiveness of the process is determined. Measures
and metrics should provide guidance for modifying the process to improve its effectiveness.
1.5.3 Objectives of Team Software Process (TSP)
The goal of TSP is to build a “self directed” project team that organizes itself to produce high-
quality software. Humphrey defines the following objectives for TSP:
• Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPTs) of 3
to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
• Accelerate software process improvement by making CMM Level 5 behavior normal and
expected.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
1.5.4 Team Software Process framework activities
TSP defines the following framework activities: project launch, high-level design,
implementation, integration and test, and postmortem.
Like their counterparts in PSP (note that terminology is somewhat different), these activities
enable the team to plan, design, and construct software in a disciplined manner while at the

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

same time quantitatively measuring the process and the product. The postmortem sets the stage
for process improvements.
TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team
members in their work. “Scripts” define specific process activities (i.e., project launch, design,
implementation, integration and system testing, postmortem) and other more detailed work
functions (e.g., development planning, requirements development, software configuration
management, unit test) that are part of the team process.
Like PSP, TSP is a rigorous approach to software engineering that provides distinct and
quantifiable benefits in productivity and quality. The team must make a full commitment to the
process and must undergo thorough training to ensure that the approach is properly applied.
1.6 TRADITIONAL SDLC VS AGILE DEVELOPMENT METHODOLOGY
1.6.1 Traditional SDLC models
1. Waterfall model
2. Spiral model
3. Iterative model
4. V model
5. Big bang model
The Big bang model is an SDLC model that starts from nothing. It is the simplest model
in SDLC (Software Development Life Cycle) as it requires almost no planning. However, it
requires lots of funds and coding and takes more time. The name big bang model was set
after the “Great Big Bang” which led to the development of galaxies, stars, planets, etc.
Similarly, this SDLC model combines time, efforts, and resources to build a product. The
product is gradually built as the requirements from the customer come, however, the end
product might not meet the actual requirements.

Fig.1.14 Big bang model

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

Design :
The product requirements are understood and implemented as they arrive. The complete
modules or at least the part of the modules are integrated and tested. All the modules are run
separately and the defective ones are removed to find the cause. It is a suitable model where
requirements are not well understood and the final release date is not given. In simple, it can
be phased out in 3 points i.e.
1. Integrate each individual’s modules to give a unique integrated overview
2. Test each module separately to identify any error or defects
3. If any error found then separate that module and identify the cause of the error
When to use it and where not to :
This SDLC model is suitable for small projects when few people are working on the project,
the customer’s demands are not exact and keep changing, or if it is a dummy/side-project. As
there is no proper planning in this model it is considered the worst SDLC model and is highly
unsuitable for large projects.
It is recommended to go for the Big Bang model only due to the following cases i.e.
1. Developing a project for learning purposes or experiment purposes.
2. No clarity on the requirements from the user side.
3. When newer requirements need to be implemented immediately.
4. Changing requirements based on the current developing product outcome.
5. No strict guideline on product release or delivery date.
Features of Big Bang Model :
 Not require a well-documented requirement specification
 Provides a quick overview of the prototype
 Needs little effort and the idea of implementation
 Allows merging of newer technologies to see the changes and adaptability
Pros of Big Bang Model :
 There is no planning required for this.
 Suitable for small projects
 Very few resources are required.
 As there is no proper planning hence it does not require managerial staffs
 Easy to implement

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

 It develops the skills of the newcomers

 Very much flexible for the developers working on it
Cons of Big Bang Model :
 Not suitable for large projects.
 Highly risky model and uncertain
 Might be expensive if requirements are not clear
 Poor model for ongoing projects
1.6.2 Agile development methodology
Agile : Agile is an approach to project management that centers around incremental and iterative
steps to completing projects. The incremental parts of a project are carried out in short-term
development cycles. The approach prioritizes quick delivery, adapting to change, and
collaboration rather than top-down management and following a set plan.
In the Agile process, there is continuous feedback, allowing team members to adjust to challenges
as they arise and stakeholders an opportunity to communicate consistently. Though originally
created for software development, the Agile approach is now widely used in executing many
different types of projects and in running organizations.
Agile methodology : The Agile methodology is a project management approach that involves
breaking the project into phases and emphasizes continuous collaboration and improvement.
Teams follow a cycle of planning, executing, and evaluating.
Popular Agile methodologies include:
 Scrum
 Kanban
 Lean
 Crystal
 Extreme Programming (XP)
 Feature-Driven Development (FDD)
 Domain-Driven Design (DDD)
 Dynamic Systems Development Method (DSDM)
 ScrumBan
 Agile-Waterfall/Hybrid Agile
 Scrum XP Hybrid

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

Benefits of agile methodology

1. Satisfied customers
By involving customers in the development process, Agile teams keep them in the loop and
show that they value their opinion. Stakeholders want to be engaged throughout the project life
cycle so they can offer feedback and ensure that the final product will be suited to their needs.
These tailor-made deliverables will likely improve the overall user experience and boost
customer retention.
2. Improved quality
Agile methodologies use an iterative approach to project management, meaning processes are
improved upon each time an interval is repeated. This consistent focus on improvement and
quality control is one of the core principles of Agile, and it helps to create superior products.
3. Adaptability
The central theme of Agile is flexibility. Agile teams are responsive to change, even at the last
minute, and can adapt to it without much disruption. Project deliverables are not set in stone,
so teams can easily reassess their plans and adjust their priorities to align with updated goals.
Being adaptable means teams can deliver consistently and manage clients’ changing
requirements effectively.
4. Predictability
Agile teams work in short time periods, sometimes referred to as sprints. These fixed durations
(e.g., two weeks) make it easier for project managers to measure team performance and assign
resources accordingly. It is also easier to predict costs for shorter time periods than for a long-
term project, simplifying the estimation process.
5. Reduced risk
Developers regularly assess progress during sprints, meaning they have better visibility into
the project and can spot potential obstacles quickly. These minor issues can be tackled before
they escalate, creating an effective risk mitigation process and giving the project a greater
chance of success.
6. Better communication
Agile teams prioritize face-to-face communication and continuous interaction. They will
usually conduct daily meetings to ensure everyone is on the same page and working towards

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

the same objectives. By regularly communicating with each other, they eliminate potential
confusion to successfully achieve their objectives.
Differences between Traditional SDLC and Agile methodology
Table 1.1 Traditional vs Agile model
Traditional Software Development Agile Software Development
It is used to develop simple software. It is used to develop complicated software.
In this methodology, testing and
In this methodology, testing is done once the
development processes are performed
development phase is completed.
concurrently.
It follows a linear It follows an iterative organizational
organizational expectation structure. structure.
It provides less security. It provides high security.
Client involvement is less as compared to Client involvement is high as compared to
Agile development. traditional software development.
It provides all the functionality needed by
It provides less functionality in the software.
the users.
It supports a changeable development
It supports a fixed development model.
model.
It is used by freshers. It is used by professionals.
Development cost is less using this Development cost is high using this
methodology. methodology.
It majorly consists of five phases. It consists of only three phases.
It is less used by software development It is normally used by software development
firms. firms.

Adaptability is favored in the agile

The expectation is favored in the traditional
methodology.
model.
Traditional software development Agile software development methodologies
approaches are formal in terms of are casual. In other words, customers who
communication with customers. work with companies that utilize Agile
software development approaches are more

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

likely to interact with them than customers

who work with companies that use
traditional software development
methodology.
For starters, typical software development
approaches employ a predictive approach.
There is full specification and prediction of Here, a flexible approach is used as the
the software development processes software development approaches are
because the product is produced through founded on the notion of continual design
rigorous and explicit planning. Changes are improvement and testing relies on team and
not permitted in this technique because the client feedback.
time and cost of project development are
fixed.
Examples
Examples
 Office productivity suites
 Sky
 Data management software
 Phillips
 Media players
 JP Morgan Chase
 Security programs

Example – Real time problem solved using different software development models
Developing a Real-Time Traffic Management System
Objective: Create a traffic management system that can monitor and manage traffic flow in
real-time to reduce congestion and improve road safety.
Using Waterfall model
1. Planning
 Objective: Define project scope, goals, and deliverables.
 Tasks:
o Identify stakeholders (e.g., city planners, traffic authorities, drivers).
o Conduct a feasibility study to determine technical and economic viability.
o Develop a project plan outlining timeline, resources, and budget.
 Outcome: Clear understanding of project requirements and constraints.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

2. Analysis
 Objective: Gather detailed requirements and analyze them.
 Tasks:
o Conduct interviews and workshops with stakeholders to gather requirements.
o Analyze current traffic management processes and identify pain points.
o Define system requirements, including real-time data processing, integration
with existing infrastructure, and user interface needs.
 Outcome: Comprehensive requirements document and system specifications.
3. Design
 Objective: Create architectural and detailed design of the system.
 Tasks:
o Design the system architecture, including data flow diagrams and system
components.
o Create wireframes and prototypes for the user interface.
o Define hardware and software requirements.
o Plan for real-time data handling and integration with sensors and traffic
cameras.
 Outcome: Design specifications and blueprints for development.
4. Development
 Objective: Build the system based on the design specifications.
 Tasks:
o Implement the system's core functionalities, such as real-time traffic data
collection, analysis algorithms, and traffic signal control.
o Develop the user interface and integrate with backend systems.
o Perform unit testing to ensure each component functions correctly.
 Outcome: Working version of the system.
5. Testing
 Objective: Ensure the system meets all requirements and is free of defects.
 Tasks:
o Conduct various types of testing, including functional, performance, and stress
testing.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o Validate real-time data processing and accuracy.

o Perform user acceptance testing (UAT) with stakeholders to ensure the system
meets their needs.
 Outcome: Identified and fixed defects, validated system performance.
6. Deployment
 Objective: Launch the system into a live environment.
 Tasks:
o Prepare deployment plan and schedule.
o Install the system in the production environment, including any necessary
hardware and software components.
o Provide training for users and administrators.
o Monitor the system post-deployment to ensure it operates correctly.
 Outcome: System operational and in use.
7. Maintenance
 Objective: Ensure the system remains effective and up-to-date.
 Tasks:
o Monitor system performance and address any issues or bugs.
o Implement updates and enhancements based on user feedback and evolving
requirements.
o Provide ongoing support and maintenance to ensure system reliability.
 Outcome: Continuous improvement and adaptation of the system.

Using Spiral model

1. First Spiral: Initial Planning and Feasibility Study
 Objective: Define initial goals, assess feasibility, and plan for the project.
 Tasks:
o Requirements Gathering: Identify stakeholders (city planners, traffic
authorities, drivers), and gather high-level requirements for the traffic
management system.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o Feasibility Study: Assess technical feasibility, considering current technology

for real-time data processing and system integration. Evaluate economic
feasibility including budget constraints.
o Risk Analysis: Identify potential risks such as technology challenges,
integration issues, and budget constraints. Develop risk mitigation strategies.
o Prototype Planning: Plan for a proof-of-concept or prototype to demonstrate
key functionalities, such as real-time data monitoring and traffic signal control.
 Outcome: Feasibility report, initial project plan, and a prototype or proof-of-concept
for key functionalities.
2. Second Spiral: Detailed Design and Development
 Objective: Develop detailed design and begin actual development.
 Tasks:
o Detailed Design: Create detailed design documents including system
architecture, data flow diagrams, user interface designs, and integration points
with existing infrastructure.
o Development: Start with building core components of the system such as data
acquisition modules, real-time traffic analysis algorithms, and user interfaces.
o Risk Assessment: Reassess risks, focusing on issues encountered during initial
development. Update risk management plans.
o Prototyping: Refine and expand prototypes based on feedback. Develop
iterative versions to validate design choices and functionality.
 Outcome: Detailed design documents, initial development of system components, and
refined prototypes.
3. Third Spiral: Testing and User Feedback
 Objective: Validate the system through testing and gather user feedback.
 Tasks:
o System Testing: Conduct thorough testing, including functional, performance,
and stress tests. Ensure the system handles real-time data correctly and
integrates seamlessly with existing infrastructure.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o User Feedback: Deploy the system in a controlled environment or pilot area.

Collect feedback from users such as traffic operators and city planners to
evaluate system performance and usability.
o Risk Assessment: Analyze any new risks discovered during testing and
feedback phases. Adjust risk management strategies as needed.
o Iteration: Based on testing results and user feedback, make necessary
adjustments and improvements to the system.
 Outcome: Tested system with user feedback, refined system based on testing results,
and updated risk management plans.
4. Fourth Spiral: Deployment and Maintenance
 Objective: Deploy the system and ensure its ongoing maintenance and improvement.
 Tasks:
o Deployment: Roll out the system to the production environment. Ensure full
integration with existing traffic management infrastructure and provide training
for users.
o Monitoring and Maintenance: Monitor system performance, address any
issues that arise, and perform regular updates based on new requirements or
technological advancements.
o Risk Assessment: Continuously assess risks related to system maintenance and
operational issues. Implement strategies to address new challenges.
o Iteration: Plan for future iterations based on ongoing feedback and
performance data. Continue improving the system through iterative cycles.
 Outcome: Fully deployed and operational system with ongoing support and iterative
improvements.

Using Unified Process Model

1. Inception Phase
 Objective: Define the scope, objectives, and feasibility of the project.
 Tasks:
o Identify Stakeholders: Engage with city planners, traffic authorities, drivers,
and other stakeholders to understand their needs and expectations.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o Define System Scope: Outline the primary goals of the traffic management
system, such as real-time traffic monitoring, traffic signal control, and data
reporting.
o Conduct Feasibility Study: Assess technical, operational, and economic
feasibility. Identify potential risks and constraints.
o Develop Initial Use Cases: Create high-level use cases that describe how the
system will be used to achieve its goals.
o Project Plan: Develop an initial project plan that includes scope, timeline,
budget, and resource allocation.
 Outcome: Feasibility report, initial project scope, and high-level use cases.
2. Elaboration Phase
 Objective: Refine requirements, design architecture, and address major risks.
 Tasks:
o Requirements Gathering: Collect detailed functional and non-functional
requirements. Engage stakeholders to refine use cases and ensure all
requirements are captured.
o Architecture Design: Develop an architectural design for the system, including
system components, data flow, and integration points. Create architecture
diagrams and models.
o Risk Management: Identify and analyze major risks. Develop mitigation
strategies for high-risk areas, such as real-time data handling and integration
with existing infrastructure.
o Prototyping: Develop prototypes or proof-of-concept systems to validate key
aspects of the design and gather early feedback from stakeholders.
 Outcome: Detailed requirements, architectural design, risk management plan, and
prototypes.
3. Construction Phase
 Objective: Build and integrate the system components.
 Tasks:

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o System Development: Implement system components according to the

architectural design. This includes real-time data processing modules, traffic
signal control algorithms, and user interfaces.
o Iterative Development: Develop the system in iterations, allowing for regular
feedback and adjustments. Each iteration should produce a working version of
the system with increasing functionality.
o Integration: Integrate system components and ensure they work together
seamlessly. This may involve integration with existing traffic management
infrastructure and real-time data sources.
o Testing: Perform unit testing, integration testing, and system testing to ensure
functionality and performance meet requirements. Include real-time
performance and stress testing.
 Outcome: Functional system components, integrated system, and completed testing.
4. Transition Phase
 Objective: Deploy the system and transition it to the operational environment.
 Tasks:
o Deployment: Roll out the system to the production environment. Ensure that
all components are properly installed and configured.
o User Training: Provide training for users and administrators on how to operate
and maintain the system.
o Documentation: Prepare and distribute user manuals, technical documentation,
and maintenance guides.
o Monitoring and Support: Monitor system performance post-deployment and
provide support for any issues that arise. Ensure that the system is operating as
expected and address any immediate concerns.
 Outcome: System deployed and operational, user training completed, and
documentation provided.
5. Maintenance Phase
 Objective: Ensure the system remains effective and up-to-date.
 Tasks:

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o Ongoing Support: Provide ongoing technical support and address any bugs or
issues reported by users.
o System Updates: Implement updates and enhancements based on user
feedback, new requirements, or changes in technology.
o Performance Monitoring: Continuously monitor system performance and
make improvements as necessary to ensure it meets performance expectations.
o Risk Management: Address any new risks that arise and update risk
management strategies accordingly.
 Outcome: Continuous system improvement, updated features, and ongoing support.

Using Incremental Model

1. Identify Core Requirements and Plan Increments
 Objective: Determine the core functionalities of the traffic management system and
plan the development of increments.
 Tasks:
o Gather Requirements: Identify essential features for the system, such as real-
time traffic monitoring, signal control, and reporting.
o Define Increments: Break down the system into smaller increments or
modules. Each increment should deliver a specific functionality or
improvement.
o Prioritize Increments: Determine the order of development based on
importance and dependencies. For instance, basic monitoring might be
prioritized over advanced traffic signal control.
2. Increment 1: Basic Traffic Monitoring
 Objective: Develop and deliver a foundational increment that focuses on real-time
traffic monitoring.
 Tasks:
o Design: Create a design for the basic monitoring system, including data
collection from traffic cameras or sensors, and basic user interface elements for
viewing traffic data.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o Development: Implement the core functionalities, such as capturing and

displaying real-time traffic data.
o Testing: Conduct unit and integration tests to ensure that the monitoring
functions correctly.
o Deployment: Deploy the monitoring system to a test environment or pilot area.
o Feedback: Gather feedback from users on the basic monitoring features and
performance.
3. Increment 2: Traffic Data Analysis and Reporting
 Objective: Add functionality for analyzing traffic data and generating reports.
 Tasks:
o Design: Extend the design to include data analysis algorithms and reporting
features. Determine how to process traffic data to generate insights and reports.
o Development: Implement data analysis and reporting functionalities. Ensure
integration with the monitoring system.
o Testing: Test the analysis algorithms and reporting features to verify accuracy
and usability.
o Deployment: Integrate the new features into the existing system and deploy to
the test environment.
o Feedback: Collect user feedback on the analysis and reporting capabilities.
4. Increment 3: Traffic Signal Control
 Objective: Develop and integrate traffic signal control functionalities.
 Tasks:
o Design: Design the traffic signal control module, including algorithms for signal
timing and coordination based on real-time traffic data.
o Development: Implement the control logic and interface for managing traffic
signals. Ensure compatibility with the monitoring and analysis modules.
o Testing: Perform rigorous testing of the signal control functionality, including
simulations of various traffic scenarios.
o Deployment: Deploy the signal control features to a controlled environment or
pilot area.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT
 K. RAMAKRISHNAN COLLEGE OF ENGINEERING
(Autonomous)
Samayapuram , Tiruchirappalli,Tamil Nadu

o Feedback: Gather feedback on the effectiveness and reliability of the signal

control features.
5. Increment 4: Advanced Features and Optimization
 Objective: Add advanced features and optimize the system based on user feedback and
performance data.
 Tasks:
o Design: Identify and design additional features such as predictive analytics,
automated traffic management strategies, or integration with external systems.
o Development: Implement advanced features and optimize existing
functionalities for better performance.
o Testing: Conduct comprehensive testing to ensure that new features work
seamlessly with the existing system.
o Deployment: Deploy the enhanced system to the production environment.
o Feedback: Continuously collect feedback and monitor system performance for
further improvements.
6. Continuous Improvement and Maintenance
 Objective: Ensure ongoing support, maintenance, and iterative improvement of the
system.
 Tasks:
o Monitoring: Continuously monitor system performance and user feedback.
o Maintenance: Address any issues or bugs that arise and perform regular
updates.
o Enhancements: Plan and develop further increments as needed based on
evolving requirements or technological advancements.

CGB1203- Agile Development Methodologies

Prepared by : B.Rama , AP-IT