Software Process and Agile Development 1.

1
SOFTWARE PROCESS AND
AGILE DEVELOPMENT

 INTRODUCTION
 SOFTWARE CHARACTERISTICS
 CATEGORIES OF SOFTWARE
 SOFTWARE MYTHS
 ATTRIBUTES OF GOOD SOFTWARE
 CHALLENGES OF SOFTWARE ENGINEERING
 LAYERED TECHNOLOGY
 SOFTWARE PROCESS

 SOFTWARE PROCESS MODELS

 INTRODUCTION TO AGILITY

 AGILE PROCESS

 EXTREME PROGRAMMING

 XP PROCESS
1. 2 Software Engineering

SOFTWARE PROCESS AND AGILE MANAGEMENT

1.1 INTRODUCTION
The computers have been used for commercial purposes. With every aspects of computer
development, software engineers have been tasked to solve larger and complex programs and
in a cost effective and efficient manner. Also the development and maintenance of the
software product has become an important criteria. Thus, emerged the software engineering
principles.
In early years, engineers faced many problems, without having an better knowledge in
this field, such as late delivery of software, development teams exceeding the budget, poor
quality, user requirements are not completely supported by the software, difficult
maintenance and unreliable software and lack of systematic approach. Thus number of large
size projects failed called software runaways resulted in software crisis. Only 2% of the
projects were used and 3% of the products were used after modification and 47% were used,
but only delivered and 19% were rejected or reworked and 29% were not even delivered.

(e.g.) Some failure software projects are British public accounts, space shuttle Columbia,
Ministry of agriculture in United Kingdom, Anane 5 launcher, Revenue service and so on.
Thus to develop a software product, the following criteria has to be satisfied :
• User needs and constraints must be determined and explicitly stated.
• The source code must be tested thoroughly.
• The product must satisfy the user needs.
• Supporting documents such as principles of operation, users guide,
installation procedures and maintenance documents must be prepared.
The software development is not merely the coding but systematically developing and
maintaining that software.
What is Software?
• Computer programs and associated documentation.
• Software products may be developed for a particular customer or may be developed
for a general market.
• Software products may be
 Generic - developed to be sold to a range of different customers.
 Bespoke (custom) - developed for a single customer according to their
specification.
Software Process and Agile Development 1. 3

What is Software Engineering?

Various Definitions
Software Engineering is the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.

Software Engineering (IEEE standard): (1) The application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of software; that is, the
application of engineering to software. (2) The study of approaches as in (1).
Software Engineering is concerned with software systems developed by teams rather
than individual programmers, uses engineering principles in the development of these system,
and is made up of both technical and non – technical aspects.
Software Engineering is a discipline that integrates methods, tools and procedures for the
development of computer software.
Software Engineering is an emerging discipline that focuses on the creation,
development, operation and maintenance of cost effective, reliably correct, and high quality
solutions to software problems.
Software Engineering is defined as the systematic approach to develop and maintain a
software product in a cost effective and efficient way.

What is the difference between Software Engineering and Computer Engineering?

• Computer science is concerned with theory and fundamentals; software engineering

is concerned with the practicalities of developing and delivering useful software.

• Computer science theories are currently insufficient to act as a complete

underpinning for software engineering.

What is the difference between Software Engineering and System Engineering?

• System engineering is concerned with all aspects of computer-based systems

development including hardware, software and process engineering. Software
engineering is part of this process.

• System engineers are involved in system specification, architectural design,

integration and deployment.
Why study Software Engineering?
• To acquire skills to develop large programs.
 Exponential growth in complexity and difficulty level with size.
1. 4 Software Engineering

• Ability to solve complex programming problems:

 How to break large projects into smaller and manageable parts?
• Learn techniques of:
 Specification, design interface development, testing, project management etc.,
• To acquire skills to be a better programmer:
 Higher Productivity
 Better Quality Program.
Goals of Software Engineering

The primary goal of software engineering is to improve the quality of software products
and to increase the productivity and job satisfaction of software engineers.
1.1.1 Software Characteristics
Software is a logical rather than a physical system element. The various software
characteristics are:-
1. Software is developed or engineered, it is not manufactured: Unlike hardware,
software is logical rather than physical. It has to be designed well before producing it.
In spite of availability of many automated software development tools, it is the skill
of the individual, creativity of the developers and proper management by the project
manager that counts for a good software product.
2. Software does not “wear out”: As time progresses, the hardware components start
deteriorating-they are subjected to environmental maladies such as dust, vibration,
temperature etc. and at some point of time they tend to breakdown. The defected
components can then be traced and replaced. But, software is not susceptible to the
environmental changes. So, it does not wear out. The software works exactly the
same way even after years it was first developed unless any charges are introduced to
it. The changes in the software may occur due to the changes in the requirements.
And these changes may introduce some defects in it thus, deteriorating the quality of
software, So, software need to maintained properly.

3. Most software is custom-built, rather than being assembled from existing

components: Most of the engineered products are first designed before they are
manufactured, Designing includes identifying various components for the product
before they are actually assembled. Here several people can work independently on
these components thus making the manufacturing system highly flexible. In software,
breading a program into modules is difficult task , since each module
Software Process and Agile Development 1. 5

is highly interlinked with other modules. Further, it requires lot of skill to integrate
different modules into one. Now a days the term component is widely used in
software industry where object oriented system is in use.

Failure rate

“Infant
“Wear out”
Mortality”

Time

Fig. 1.1 Failure Curves for Hardware

increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time
Fig. 1.2 Failure Curves for Software

1.1.2 Categories Of Software

The computer software can be classified into following categories:
1. System software

System software is a collection of program written to service other program. e.g.,

Compliers, OS, Editors, File management utilities etc.,
2. Application software

Application software consists of standalone program that solve a specific business

need. This software are mainly used in database applications.
1. 6 Software Engineering

3. Engineering / Scientific software

This software applications range from astronomy to volcanology, from automatic
stress analysis to space shuttle orbital dynamics and from molecular biology to
automated manufacturing modern Engineering / Scientific software is based on
complex numerical computations.
4. Embedded software
This software resides within a product or system and is used to implement and
control features and functions for the end – user and for the system itself. e.g.,
Digital functions in an automobile such as Fuel control, Dashboard displays, Braking
system etc.,
5. Product line software (or) Personal computer software
This software is designed to provide a specific capability for use by many different
customers. e.g., Word processing, Spread sheets, Computer graphics, Multimedia
etc.,
6. Web Applications
The web pages retrieved by a browser as software that incorporates executable
instructions. e.g., CGI, HTML, Perl, Java, DHTML etc.,
7. Artificial Intelligence software
This software is based on knowledge based expert systems and it is used to solve
complex problems that are not amenable to computation or straight forward analysis.
e.g., Pattern recognition (image and voice), Artificial neural networks, Theorem
proving, Game playing etc.,

1.1.3 Software Myths

• Software standards provide software engineers with all the guidance they need. The
reality is the standards may be outdated and rarely referred to.
• People with modem computers have all the software development tools. The reality is
that CASE tools are more important than hardware to producing high quality
software, yet they are rarely used effectively.
• Adding people is a good way to catch up when a project is behind schedule. The
reality is that adding people only helps the project schedule when is it done in a
planned, well-coordinated manner.
• Giving software projects to outside parties to develop solves software project
management problems. The reality is people who can’t manage internal software
development problems will struggle to manage or control the external development
of software too.
Software Process and Agile Development 1. 7

• A general statement of objectives from the customer is all that is needed to begin a
software project. The reality is without constant communication between the
customer and the developers it is impossible to build a software product that meets
the customer’s real needs.
• Project requirements change continually and change is easy to accommodate in the
software design. The reality is that every change has far-reaching and unexpected
consequences. Changes to software requirements must be managed very carefully to
keep a software project on time and under budget.
• Once a program is written, the software engineer’s work is finished. The reality is
that maintaining a piece of software is never done, until the software product is
retired from service.

• There is no way to assess the quality of a piece of software until it is actually running
on some machine. The reality is that one of the most effective quality assurance
practices (formal technical reviews) can be applied to any software design product
and can serve as a quality filter very early in the product life cycle.

• The only deliverable from a successful software project is the working program. The
reality is the working program is only one of several deliverables that arise from a
well-managed software project. The documentation is also important since it provides
a basis for software support after delivery.
Software engineering is all about the creation of large and unnecessary documentation.
The reality is that software engineering is concerned with creating quality. This means doing
things right the first time and not having to create deliverables needed to complete or
maintain a software product. This practice usually leads to faster delivery times and shorter
development cycles.

1.1.4 Attributes Of Good Software

The software should deliver the required functionality and performance to the user and
should be maintainable, dependable and usable.
• Maintainability
 Software must evolve to meet changing needs.
• Dependability
 Software must be trustworthy.
• Efficiency
 Software should not make wasteful use of system resources.
• Usability
 Software must be usable by the users for which it was designed.
1. 8 Software Engineering

1.1.5 Challenges Of Software Engineering

The key challenges facing software engineering are
• Coping with legacy systems, coping with increasing diversity and coping with
demands for reduced delivery times.
• Legacy systems
 Old, valuable systems must be maintained and updated.
• Heterogeneity
 Systems are distributed and include a mix of hardware and software.
• Delivery
 There is increasing pressure for faster delivery of software.

1.1.7 Layered Technology

Software Engineering is a layered technology (Referring to Fig.1.3). Any engineering
approach (including software engineering) must rest on an organizational commitment to
quality focus.
The foundation for software engineering is the process layer. Software engineering
process is the glue that holds the technology layers together and enables rational and timely
development of computer software.
Process defines a framework for a set of key process areas that must be establish for
effective delivery of software engineering technology.

TOOLS
methods
process
A quality focus

Fig. 1.3 Software Engineering Layers

Software engineering methods provide the technical how-to’s for building software.
Methods encompass a broad array of tasks that include requirements analysis, design,
program construction, testing and maintenance.
1.2 SOFTWARE PROCESS
A Software Process is a set of activities and associated results which produces a software
product. These activities are mostly carried out by software engineers. There are four
fundamental process activities which are common to all software processes.
Software Process and Agile Development 1. 9

These activities are

1. Software Specification:- The functionality of the software and constraints on its

operation must be defined.
2. Software Development:- The software to meet the specification must be produced.

3. Software Validation:- The software must be validated to ensure that it does what the
customer wants.
4. Software Evolution:- The software must evolve to meet changing customer needs.
1.2.1 Generic Process Framework

Fig. 1.4 A Software Process Framework

1. 10 Software Engineering

The software process can be characterized as shown in Fig.1.4. A common process

framework is established by defining a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity.
Task sets
A number of task sets – each a collection of software engineering work tasks, project
milestone, software work products and deliverables and software quality assurance points.
Framework Activities
The task sets enable the framework activities to be adopted to the characteristics of the
software project and the requirements of the project team. The Generic process framework
activities are
1. Communication
The customer requirement information gathering is done by communication.
2. Planning
The planning activity defines the engineering work plan, describes technical risks, list
resource requirements, work products produced and defines work schedule.
3. Modeling
The modeling activity defines the requirement analysis and design.
4. Construction
The construction activity implements the corresponding coding and testing.
5. Deployment
The software delivered for customer evaluation and feedback is obtained.
Umbrella Activities
Umbrella activities – such as quality assurance, software configuration management
and measurement. Umbrella activities are independent of any one framework activity and
occur throughout the process. The umbrella activities are
1. Software project tracking and control
This activity helps to asses the software team progress and take corrective action to
maintain schedule.
2. Risk management
This activity analysis the risk that may affect the project quality.
3. Software quality assurance
This activity maintain the required software quality.
Software Process and Agile Development 1. 11

4. Formal technical reviews

This activity helps to analyze the engineering work products to uncover and clear
errors before they proceed to next activity.
5. Software configuration management
This activity manages the configuration process when any change in the software
process.
6. Work product preparation and production
This activity defines the model, document forms and lists to be carried out.
7. Reusability management
This activity defines the work product reuse.
8. Measurement
This activity defines the project and product measure to assist the software team in
delivery the required software.
1.2.2 Process Assessment and Improvement
Software Process (SP) cannot guarantee that software will be delivered on time, meet the
needs, or has the desired technical characteristics. However, the process can be assessed to
ensure that it meets a set of basic process criteria that have been shown to be essential for a
successful software engineering.
The various approaches to the process assessment and improvement which has been
proposed for the last few decades are:
• Standard CMMI Assessment Method for Process Improvement (SCAMPI)
— provides a five step process assessment model that incorporates five phases:
initiating, diagnosing, establishing, acting and learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides
a diagnostic technique for assessing the relative maturity of a software organization;
uses the SEI CMM as the basis for the assessment.
• SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for
software process assessment. The intent of the standard is to assist organizations in
developing an objective evaluation of the efficacy of any defined software process.
[ISO08]
• ISO 9001:2000 for Software—a generic standard that applies to any organization
that wants to improve the overall quality of the products, systems, or services that it
provides. Therefore, the standard is directly applicable to software organizations and
companies.
1. 12 Software Engineering

1.2.3 Software Engineering Paradigm

A software paradigm or process model is an abstract representation of a process.

The process model is chosen based on nature of software project and application and
then to obtain deliverable product method and tools are applied.
All software development can be characterized as a problem solving loop as shown
Fig. 1.5 in which four distinct stages are encountered:
Status quo represents the existing status.
Problem definition identifies the specific problem to be solved.
Technical development solves the identified problem with appropriate technology.
Solution integration which delivers the results

Problem
definition

Existing Technical
status development

Solution
integration

Fig. 1.5 The Phase of a Problem Solving Loop

The problem solving loop is very difficult to implement in software development process
because we cannot strictly categorize the development in these phases. There may be a
requirement of cross talk within and across stages. Hence various software process models
are suggested depending upon nature of the software.
1.2.4 Need for Life Cycle Models
The primary goal of life cycle model is to develop a software in a systematic and
disciplined manner. When a program is developed by a single programmer, he has the
freedom to decide the exact steps through which he can develop the program. However, when
a software is developed by a team, it is necessary to have a good understanding among the
team members as to when to do what. Otherwise, it results in product failure. Usually in the
case of large projects, it is splitted into many modules and each module
Software Process and Agile Development 1. 13

is done by various team members. Finally all the modules are interfaced and checked for the
efficiency. Severe problem arise in interfacing the different parts and in managing the overall
development.

Software development organizations normally prepare an accurate documentation of the

life cycle model followed by them. A documented life cycle model are that it enhances the
understanding of the process among the developers and mandates the software development
organization to accurately define every activity in the life cycle. It helps to identify where
exactly the requirement tailoring should occur. It is also a mandatory requirement of the
modern quality assurance techniques. A life cycle model normally defines the entry and exit
criteria for every phase. A phase can begin only when the corresponding phase-entry criteria
are satisfied. Similarly a phase can be completed when the corresponding phase exit criteria
are satisfied. The first step is to represent the software requirements specification document
and it should be internally reviewed and approved by the customer. Only when these criteria
are satisfied the next phase can start. Several life cycle models have been developed. The
following life cycle models are described in detail:
(i) Waterfall Model
(ii) Prototyping Model
(iii) Incremental Model
(iv) Spiral Model
(v) WIN WIN Spiral Model
(vi) Evolutionary Model
(vii) Object Oriented Model

1.3 PERSPECTIVE PROCESS MODELS

• Defines a distinct set of activities, actions, tasks, milestones, and work products that
are required to engineer high-quality software
• The activities may be linear, incremental, or evolutionary
1.3.1 Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential
flow; hence it is also referred to as a linear-sequential life cycle model. This means that any
1. 14 Software Engineering

phase in the development process begins only if the previous phase is complete. In waterfall
model phases do not overlap.
Waterfall Model Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In “The Waterfall” approach, the whole process of software
development is divided into separate phases. In Waterfall model, typically, the outcome of
one phase acts as the input for the next phase sequentially.
Following Fig. 1.6 is a diagrammatic representation of different phases of waterfall
model.

Fig. 1.6 Different Phases in Waterfall Model

The sequential phases in Waterfall model are:
❖ Requirement Gathering and analysis: All possible requirements of the system to
be developed are captured in this phase and documented in a requirement
specification doc.
❖ System Design: The requirement specifications from first phase are studied in this
phase and system design is prepared. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture.
❖ Implementation: With inputs from system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality which is referred to as Unit Testing.
Software Process and Agile Development 1. 15

❖ Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
❖ Deployment of system: Once the functional and non functional testing is done, the
product is deployed in the customer environment or released into the market.
❖ Maintenance: There are some issues which come up in the client environment. To fix
those issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
“Waterfall Model”. In this model phases do not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:
❖ Requirements are very well documented, clear and fixed.
❖ Product definition is stable.
❖ Technology is understood and is not dynamic.
❖ There are no ambiguous requirements.
❖ Ample resources with required expertise are available to support the product.
❖ The project is short.
Waterfall Model Pros and Cons
Advantage
The advantage of waterfall development is that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one.
Development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order.
Disadvantage
The disadvantage of waterfall development is that it does not allow for much reflection
or revision. Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-documented or thought upon in the concept stage.
1. 16 Software Engineering

The following table lists out the pros and cons of Waterfall model:

Pros Cons
• Simple and easy to understand and use • No working software is produced until
late during the life cycle.
• Easy to manage due to the rigidity of the • High amounts of risk and uncertainty.
model . each phase has specific
deliverables and a review process.
• Phases are processed and completed • Not a good model for complex and
one at a time. object-oriented projects.
• Works well for smaller projects where • Poor model for long and ongoing
requirements are very well understood. projects.
• Clearly defined stages. • Not suitable for the projects where
requirements are at a moderate to high
risk of changing. So risk and uncertainty
is high with this process model.

• Well understood milestones. • It is difficult to measure progress within

stages.

• Easy to arrange tasks. • Cannot accommodate changing

requirements.

• Process and results are well documented. • No working software is produced until
late in the life cycle.

• Adjusting scope during the life cycle can

end a project.
• Integration is done as a “big-bang. at the
very end, which doesn’t allow identifying
any technological or business bottleneck
or challenges early.

1.3.2 V-Model
The V - model is SDLC model where execution of processes happens in a sequential
manner in V-shape. It is also known as Verification and Validation model.
Software Process and Agile Development 1. 17

V - Model is an extension of the waterfall model and is based on association of a testing

phase for each corresponding development stage. This means that for every single phase in
the development cycle there is a directly associated testing phase. This is a highly disciplined
model and next phase starts only after completion of the previous phase.
V- Model design
Under V-Model, the corresponding testing phase of the development phase is planned in
parallel. So there are Verification phases on one side of the .V. and Validation phases on the
other side. Coding phase joins the two sides of the V-Model.
The below Fig. 1.7 illustrates the different phases in V-Model of SDLC.

Fig. 1.7 Different Phase in

V - Model
Verification Phases
Following are the Verification phases in V-Model:
❖ Business Requirement Analysis: This is the first phase in the development cycle
where the product requirements are understood from the customer perspective. This
phase involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and need to be
managed well, as most of the customers are not sure about what exactly they need.
The acceptance test design planning is done at this stage as business requirements can
be used as an input for acceptance testing.
❖ System Design: Once you have the clear and detailed product requirements, it.s time
to design the complete system. System design would comprise of understanding and
detailing the complete hardware and communication setup for the product under
1. 18 Software Engineering

development. System test plan is developed based on the system design. Doing this at
an earlier stage leaves more time for actual test execution later.
❖ Architectural Design: Architectural specifications are understood and designed in
this phase. Usually more than one technical approach is proposed and based on the
technical and financial feasibility the final decision is taken. System design is broken
down further into modules taking up different functionality. This is also referred to as
High Level Design (HLD).
The data transfer and communication between the internal modules and with the
outside world (other systems) is clearly understood and defined in this stage. With
this information, integration tests can be designed and documented during this stage.
❖ Module Design:In this phase the detailed internal design for all the system modules
is specified, referred to as Low Level Design (LLD). It is important that the design is
compatible with the other modules in the system architecture and the other external
systems. Unit tests are an essential part of any development process and helps
eliminate the maximum faults and errors at a very early stage. Unit tests can be
designed at this stage based on the internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the
Coding phase. The best suitable programming language is decided based on the system and
architectural requirements. The coding is performed based on the coding guidelines and
standards. The code goes through numerous code reviews and is optimized for best
performance before the final build is checked into the repository.
Validation Phases
Following are the Validation phases in V-Model:
❖ Unit Testing: Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at code level and helps eliminate
bugs at an early stage, though all defects cannot be uncovered by unit testing.

❖ Integration Testing: Integration testing is associated with the architectural design

phase. Integration tests are performed to test the coexistence and communication of
the internal modules within the system.
❖ System Testing: System testing is directly associated with the System design phase.
System tests check the entire system functionality and the communication of the
system under development with external systems. Most of the software and hardware
compatibility issues can be uncovered during system test execution.
❖ Acceptance Testing: Acceptance testing is associated with the business requirement
analysis phase and involves testing the product in user environment. Acceptance tests
Software Process and Agile Development 1. 19

uncover the compatibility issues with the other systems available in the user
environment. It also discovers the non functional issues such as load and performance
defects in the actual user environment.
V- Model Application
V- Model application is almost same as waterfall model, as both the models are of sequential
type. Requirements have to be very clear before the project starts, because it is usually expensive
to go back and make changes. This model is used in the medical development field, as it is strictly
disciplined domain. Following are the suitable scenarios to use V-Model:
❖ Requirements are well defined, clearly documented and fixed.
❖ Product definition is stable.
❖ Technology is not dynamic and is well understood by the project team.
❖ There are no ambiguous or undefined requirements.
❖ The project is short.
V- Model Pros and Cons
The advantage of V-Model is that it.s very easy to understand and apply. The simplicity
of this model also makes it easier to manage. The disadvantage is that the model is not
flexible to changes and just in case there is a requirement change, which is very common in
today.s dynamic world, it becomes very expensive to make the change.
The following table lists out the pros and cons of V-Model:
Pros Cons

• This is a highly disciplined model and • High risk and uncertainty.

Phases are completed one at a time.
• Not a good model for complex and object-
• Works well for smaller projects where oriented projects.
requirements are very well understood.
• Poor model for long and ongoing projects.
• Simple and easy to understand and use.
• Not suitable for the projects where
• Easy to manage due to the rigidity of the requirements are at a moderate to high
model each phase has specific risk of changing.
deliverables and a review process.
• Once an application is in the testing stage,
it is difficult to go back and change a
functionality

• No working software is produced until

late during the life cycle.
1. 20 Software Engineering

1.3.3 Iterative model

In Iterative model, iterative process starts with a simple implementation of a small set of
the software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just part of the
software, which is then reviewed in order to identify further requirements. This process is then
repeated, producing a new version of the software at the end of each iteration of the model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software
requirements and iteratively enhances the evolving versions until the full system is
implemented. At each iteration, design modifications are made and new functional
capabilities are added. The basic idea behind this method is to develop a system through
repeated cycles (iterative) and in smaller portions at a time (incremental).
Following Fig. 1.8 is the pictorial representation of Iterative and Incremental model:

Fig. 1.8 Iterattive and Incremental Model

Iterative and Incremental development is a combination of both iterative design or iterative

method and incremental build model for development. “During software development, more than
one iteration of the software development cycle may be in progress at the same time.” and “This
process may be described as an “evolutionary acquisition” or “incremental build” approach.”
Software Process and Agile Development 1. 21

In incremental model the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation
and testing phases. Each subsequent release of the module adds function to the previous
release. The process continues till the complete system is ready as per the requirement.

The key to successful use of an iterative software development lifecycle is rigorous validation
of requirements, and verification & testing of each version of the software against those
requirements within each cycle of the model. As the software evolves through successive cycles,
tests have to be repeated and extended to verify each version of the software.

Iterative Model Application

Like other SDLC models, Iterative and incremental development has some specific
applications in the software industry. This model is most often used in the following scenarios:

❖ Requirements of the complete system are clearly defined and understood.

❖ Major requirements must be defined; however, some functionalities or requested

enhancements may evolve with time.

❖ There is a time to the market constraint.

❖ A new technology is being used and is being learnt by the development team while
working on the project.

❖ Resources with needed skill set are not available and are planned to be used on
contract basis for specific iterations.

❖ There are some high risk features and goals which may change in the future.

Iterative Model Pros and Cons

The advantage of this model is that there is a working model of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding issues
at an early stage of development enables to take corrective measures in a limited budget.

The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software system
into further small serviceable increments/modules.
1. 22 Software Engineering

The following table lists out the pros and cons of Iterative and Incremental SDLC Model:

Pros Cons
• Some working functionality can be • More resources may be required.
developed quickly and early in the life
• Although cost of change is lesser but it
cycle.
is not very suitable for changing
• Results are obtained early and requirements.
periodically.
• More management attention is required.
• Parallel development can be planned.
• System architecture or design issues
• Progress can be measured. may arise because not all requirements
are gathered in the beginning of the
• Less costly to change the scope/ entire life cycle.
requirements.
• Defining increments may require
• Testing and debugging during smaller definition of the complete system.
iteration is easy.
• Not suitable for smaller projects.
• Risks are identified and resolved during
iteration; and each iteration is an easily • Management complexity is more.
managed milestone.
• End of project may not be known which
• Easier to manage risk - High risk part is is a risk.
done first.
• Highly skilled resources are required for
• With every increment operational product risk analysis.
is delivered.
• Projects progress is highly dependent
• Issues, challenges & risks identified from upon the risk analysis phase.
each increment can be utilized/applied to
the next increment.
• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.

• Better suited for large and mission-

critical projects.

• During life cycle software is produced

early which facilitates customer
evaluation and feedback.
Software Process and Agile Development 1. 23

1.3.4 Evolutionary Models

❖ Software system evolves over time as requirements often change as development
proceeds. Thus, a straight line to a complete end product is not possible. However, a
limited version must be delivered to meet competitive pressure.
❖ Usually a set of core product or system requirements is well understood, but the
details and extension have yet to be defined.
❖ You need a process model that has been explicitly designed to accommodate a
product that evolved over time.
❖ It is iterative that enables you to develop increasingly more complete version of the
software.
❖ Two types are introduced, namely Prototyping and Spiral models.
1.3.4.1 Spiral Model

The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model.
Spiral model is a combination of iterative development process model and sequential
linear development model i.e. waterfall model with very high emphasis on risk analysis.
It allows for incremental releases of the product, or incremental refinement through each
iteration around the spiral.
Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.
❖ Identification:This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous

communication between the customer and the system analyst. At the end of the spiral
the product is deployed in the identified market.
❖ Design:Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and
final design in the subsequent spirals.
❖ Construct or Build:Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral when the product is just thought of and
the design is being developed a POC (Proof of Concept) is developed in this phase to
get customer feedback.
1. 24 Software Engineering

Then in the subsequent spirals with higher clarity on requirements and design details
a working model of the software called build is produced with a version number.
These builds are sent to customer for feedback.
❖ Evaluation and Risk Analysis:Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
Following Fig. 1.9 is a diagrammatic representation of spiral model listing the activities
in each phase:

Fig. 1.9 Sprial model

Based on the customer evaluation, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback suggested
by the customer. The process of iterations along the spiral continues throughout the life of the
software.
Spiral Model Application
Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum risk
Software Process and Agile Development 1. 25

for the customer as well as the development firms. Following are the typical uses of Spiral
model:
❖ When costs there is a budget constraint and risk evaluation is important.
❖ For medium to high-risk projects.
❖ Long-term project commitment because of potential changes to economic priorities
as the requirements change with time.
❖ Customer is not sure of their requirements which is usually the case.
❖ Requirements are complex and need evaluation to get clarity.
❖ New product line which should be released in phases to get enough customer feedback.
❖ Significant changes are expected in the product during the development cycle.
Spiral Model Pros and Cons
The advantage of spiral lifecycle model is that it allows for elements of the product to be
added in when they become available or known. This assures that there is no conflict with
previous requirements and design.
This method is consistent with approaches that have multiple software builds and releases
and allows for making an orderly transition to a maintenance activity. Another positive aspect is
that the spiral model forces early user involvement in the system development effort.
On the other side, it takes very strict management to complete such products and there is
a risk of running the spiral in indefinite loop. So the discipline of change and the extent of
taking change requests is very important to develop and deploy the product successfully.
The following table lists out the pros and cons of Spiral SDLC Model:

Pros Cons
• Changing requirements can be • Management is more complex.
accommodated. • End of project may not be known early.
• Allows for extensive use of prototypes • Not suitable for small or low risk
• Requirements can be captured more projects and could be expensive for
accurately. small projects.
• Users see the system early. • Process is complex
• Development can be divided into smaller • Spiral may go indefinitely.
parts and more risky parts can be
• Large number of intermediate stages
developed earlier which helps better risk requires excessive documentation.
management.
1. 26 Software Engineering

1.3.4.2 Prototyping Model

The basic idea here is that instead of freezing the requirements before a design or coding
can proceed, a throwaway prototype is built to understand the requirements. This prototype is
developed based on the currently known requirements. Development of the
prototype obviously undergoes design, coding and testing. But each of these phases is not
done very formally or thoroughly. By using this prototype, the client can get an “actual feel”
of the system, since the interactions with prototype can enable the client to better
understand the requirements of the desired system.
Prototyping is an attractive idea for complicated and large systems for which there
is no manual process or existing system to help determining the requirements. In such situations
letting the client “plan” with the prototype provides invaluable and intangible inputs
which helps in determining the requirements for the system. It is also an effective method to
demonstrate the feasibility of a certain approach. This might be needed for novel systems
where it is not clear that constraints can be met or that algorithms can be developed to
implement the requirements. The process model of the prototyping approach is shown in the
Fig. 1.10 below.

Quick
Planning

Communication

Modeling
Quick Design
Deployment,
Delivery,
and Feedback

Construction
Of Prototype

Fig. 1.10 Prototyping Model

The basic reason for little common use of prototyping is the cost involved in this built-it-
twice approach. However, some argue that prototyping need not be very costly and can actually
reduce the overall development cost. The prototype are usually not complete systems and many of
the details are not built in the prototype. The goal is to provide a system with overall functionality.
Software Process and Agile Development 1. 27

In addition, the cost of testing and writing detailed documents are reduced. These factors
helps to reduce the cost of developing the prototype. On the other hand, the experience of
developing the prototype will very useful for developers when developing the final system.
This experience helps to reduce the cost of development of the final system and results in a
more reliable and better designed system.
Advantages of Prototyping
1. Users are actively involved in the development
2. It provides a better system to users, as users have natural tendency to change their
mind in specifying requirements and this method of developing systems supports this
user tendency.
3. Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
4. Errors can be detected much earlier as the system is mode side by side.
5. Quicker user feedback is available leading to better solutions.
Disadvantages
1. Leads to implementing and then repairing way of building systems.
2. Practically, this methodology may increase the complexity of the system as scope of
the system may expand beyond original plans.
1.3.4.3 The Concurrent Development Model
The concurrent development model, sometimes called concurrent engineering, can be
represented schematically as a series of Framework activities, Software engineering actions
of tasks, and their associated states.
The concurrent model is often more appropriate for system engineering projects where
different engineering teams are involved.
Figure above provides a schematic representation of one Software engineering task
within the modeling activity for the concurrent process model. The activity – modeling-
may be in any one of the states noted at any given time.
All activities exist concurrently but reside in different states.
For example, early in the project the communication activity has completed its first
iteration and exists in the awaiting changes state. The modeling activity which existed in the
none state while initial communication was completed now makes a transition into
underdevelopment state.
If, however, the customer indicates the changes in requirements must be made, the
modeling activity moves from the under development state into the awaiting changes state.
1. 28 Software Engineering

Fig. 1.11 The Concurrent Development Model

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

1.4 SPECIALIZED PROCESS MODELS

1.4.1 Component Based Development
Commercial off-the-shelf (COTS) Software components, developed by vendors who
offer them as products, can be used when Software is to be built. These components provide
targeted functionality with well-defined interfaces that enable the component to be integrated
into the Software.
The component-based development model incorporates many of the characteristics of the
spiral model.
Software Process and Agile Development 1. 29

The component-based development model incorporates the following steps:

• Available component-based products are researched and evaluated for the application
domain in question.
• Component integration issues are considered.
• Software architecture is designed to accommodate the components.
• Components are integrated into the architecture.
• 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.4.2 The Formal Methods Model

• Encompasses a set of activities that leads to formal mathematical specification of

computer software
• Enables a software engineer to specify, develop, and verify a computer-based system
by applying a rigorous, mathematical notation
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily through mathematical analysis
• Offers the promise of defect-free software
• Used often when building safety-critical systems
Challenges
• Development of formal methods 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.4.3 Aspect-Oriented Software Development

Aspect-Oriented Software Development (AOSD), sometimes just called Aspect-Oriented
Programming (AOP), is a new approach to software design that addresses modularity problems
that are not handled well by other approaches, including Structured Programming and Object-
Oriented Programming (OOP). AOSD complements, but doesn’t replace those approaches.
 1. 30 Software Engineering

Typical enterprise and internet applications today have to address “concerns” like security,
transactional behavior, logging, etc.. The subsystems that provide these services can be
implemented in a modular way. However, to use these services, you must insert the same
“boilerplate” code fragments into various places in the rest of the application to invoke these
services. This violates the “don’t repeat yourself” (DRY) principle and it compromises the
overall system modularity, because the same invocation code is scattered throughout the
application.
For example, if you want to control access to certain services in your application, you
could insert authorization-checking boilerplate at the beginning of every method that needs this
control. Because this redundant boilerplate appears in many places in the code, it would now be
difficult and error prone to modify or replace this security approach later, should that become
necessary. Also, your application code is now tangled with code for the security (and probably
other) concerns, which both compromises clarity and makes it hard to reuse your code in
another context, since you would have to drag along the same security approach, which may
not be appropriate.

1.5 INTRODUCTION TO AGILITY

• Agility means effective (rapid and adaptive) response to change,

effective communication among all stockholder.
• Drawing the customer onto team and organizing a team so that it is in control
work performed. -The Agile process, light-weight methods are People-based
than plan-based methods.
• The agile process forces the development team to focus on software itself rather
than design and documentation.
• The agile process believes in iterative method.
• The aim of agile process is to deliver the working model of software quickly
to the customer For example: Extreme programming is the best known of agile process.

1.6 AGILE PROCESS IN SOFTWARE ENGINEERING

Agile principles
• The highest priority of this process is to satisfy the customer.
• Acceptance of changing requirement even late in development.
• Frequently deliver a working software in small time span.
• Throughout the project business people and developers work together on
daily basis.
• Projects are created around motivated people if they are given the proper
environment and support.
• Face to face interaction is the most efficient method of moving information
in the development team.
Software Process and Agile Development 1. 31

• Primary measure of progress is a working software.

• Agile process helps in sustainable development.
• Continuous attention to technical excellence and good design increases agility.
• From self organizing teams the best architecture, design and requirements are emerged.
• Simplicity is necessary in development.

1.7 EXTREME PROGRAMMING AND XP PROCESS

• Extreme programming uses an object-oriented approach as its preferred development

paradigm.
• Extreme programming encompasses a set of rules and practices that occur within the
context of four framework activities: planning, design, coding, and testing.

Fig.1.12 Extreme Programming Process

1. Planning:

• The planning activity begins with the creation of a set of stories that describe required
features and functionality for software to be built.
• Each story is written by the customer and is placed on an index card. The customer
assigns a value to the story based on the overall business value of the feature of function.
 1. 32 Software Engineering

• Members of the XP (Extreme Programming) team then assess each story and assign a
cost – measured in development weeks – to it.
• If the story will require more than three development weeks, the customer is asked to
split the story into smaller stories, and the assignment of value and cost occurs again.
• Customers and the XP team work together to decide how to group stories into the
next release to be developed by the XP team.
• Once a basic commitment is made for a release, the XP team orders the stories that
will be developed in one of three ways:

1. All stories will be implemented immediately.

2. The stories with highest value will be moved up in the schedule and implemented
first.
3. The riskiest stories will be moved up in the schedule and implemented first.

• As development work proceeds, the customer can add stories, change the value of an
existing story, split stories or eliminate them.
• The XP team then reconsiders all remaining releases and modifies its plan
accordingly.

2. Design :

• XP design follows the KIS (Keep It Simple) principle. A simple design is always
preferred over a more complex representation.
• The design provides implementation guidance for a story as it is written – nothing
less, nothing more.
• XP encourages the use of CRC (Class Responsibility Collaborator) cards as an
effective mechanism for thinking about the software is an object oriented context.
• CRC cards identify and organize the object oriented classes that are relevant to
current software increment.
• The CRC cards are the only design work product produced as a part of XP process.
• If a difficult design is encounter as a part of the design of a story, XP recommends the
immediate creation of that portion of the design called as ‘spike solution’.
• XP encourages refactoring – a construction technique.

3. Coding

• XP recommends that after stories are developed and preliminary design work is done, the
team should not move to cord, but rather develop a series of unit test that will be exercise
each stories.
• Once the unit test has been created, the developer better able to focus on what must be
implemented to pass the unit test.
• Once the code complete, it can be unit tested immediately, thereby providing
instantaneous feedback to the developer.
Software Process and Agile Development 1.33

o A key concept during the coding activity is pair programming. XP recommends

that two people work together at one computer workstation to create code for a
story. This provides a mechanism for real time problem solving and real time
quality assurance.

• As pair programmers complete their work, the code they developed is integrated
with the work of others.
• This continuous integration strategy helps to avoid compatibility and interfacing
problems and provides a smoke testing environment that helps to uncover errors
early.

4.Testing :

• The creation of unit test before coding is the key element of the XP approach.
• The unit tests that are created should be implemented using a framework that enables
them to be automated. This encourages regression testing strategy whenever code is
modified.
• Individual unit tests are organize into a “Universal Testing Suit”, integration and
validation testing of the system can occur on daily basis. This provides the XP team with
a continual indication of progress and also can raise warning flags early if things are
going away.
• XP acceptance test, also called customer test, are specified by the customer and focus on
the overall system feature and functionality that are visible and reviewable by the
customer.
1. 54 Software Engineering

REVIEW QUESTIONS
PART - A

1. Mention the characteristics of software.

2. Define process.
3. Define Software Engineering.
4. What is meant by Software Engineering Paradigm?
5. Define process model.
6. How waterfall model works?
7. Mention the advantages and disadvantages of waterfall model.
8. How incremental model works?
9. Mention the advantage of incremental model.
10. How spiral model works?
11. What are the different phases in spiral model?
12. Mention the advantages of spiral model.
13. How prototyping model works?
14. What are the advantages of prototyping?
15. Write about three layers of software process model.
16. What are the different phases of Software Engineering?
17. What are the types of changes encountered in maintenance?
18. Explain the stages involved in problem solving loop?
19. Define Risk and its characteristics.
20. What is meant by Aspect-Oriented software development?
21. Mention the differnet phases of Unified process.

22. Define: Extreme Programming & its types.

23. What is Agility?

24. What are the principles of Agile process?

25. What is XP process?

Software Process and Project Management 1. 55

PART – B

1. Compare Waterfall Model and Spiral Model of software development. Give the
advantage and disadvantages of each.
2. Explain Prototype Model and Iterative Model in detail.
3. Explain Software Process Framework in detail.
4. What is the need for software life cycle model? Explain any two life cycle models in
detail.
5. Explain any two perspective process models in detail.
6. Explain the specialized process model in detail.
7. What is meant by UP? Explain the various phases of UP in detail.
8. Explain the Extreme Programming Process in detail.
9. Explain the XP Process model in detail.
10. Discuss about the Agility in detail.
11. Write short notes on Agile Process.