CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT 1 - SOFTWARE PROCESS AND AGILE DEVELOPMENT

1.1 INTRODUCTION
1.1.1 Software
➤ Software is a set of instructions that provides desired features, function, and
performance on execution.
➤ Software is a data structure that enables the programs to adequately
manipulate information

1.1.2 Characteristics
1. Software is developed or engineered and not manufactured.
2. Software doesn't wear out.
3. Although the industry is moving toward component-based construction, most
software continues to be custom built.

1.1.3 Categories of Computer Software

➤ System software is a set of programs that serve other programs.
➤ Application software is stand-alone programs that solve a specific business
need.
➤ Engineering software has been characterized by "number crunching"
algorithms. Eg: CAD, CAM
➤ Embedded software is the software that 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. Eg: microwave oven, Air Conditioner, washing machine etc
➤ Product-line software provide a specific capability for use by many different
customers. Eg: word processor.
➤ Web applications called "WebApps," provide a wide array of applications.
➤ Artificial intelligence software makes use of non numerical algorithms to
solve complex problems. Eg: Expert systems, Robotics, Neural networks etc.

Page 1 of 31
1.1.4 Software Myths
Management Myth:
Myth: Is the existing standards and procedures are enough for building software?
Reality: It is not used, not up to date, not complete, not focused on quality, time, and
money Myth: If we are behind the schedule, more programmers can be added to meet
the deadline
Reality: Adding people to a late software project makes it later. Training time,
increased communication lines
Myth: By outsourcing the project to a third party, I can just relax
Reality: Software projects need to be controlled and managed. Outsourced project need
proper support for development

Customer Myth:
Myth: A general objective is enough to begin the code and the details can be filled later
Reality: Ambiguous statement of objectives spells disaster
Myth: Project requirements continuously change, but change can be easily
accommodated because software is flexible
Reality: Impact of change depends on where and when it occurs in the software life
cycle

Practitioner's Myth :
Myth: Once the program is executed then the job is done
Reality: 60% to 80% of all effort expended on software occurs after it is delivered
Myth: The only deliverable work product for a successful project is the working
program
Reality: A working program is only one part of a software configuration that includes
many elements.

Page 2 of 31
1.1.5 Layered Technology

 Software Engineering is defined as the application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of software.
 Software engineering is a layered technology

Tools
Methods
Process

A Quality Focus

Fig: Software Engineering Layers

Process

 Process defines a framework for effective delivery of software engineering technology.

 The software process is the basis for the control of software projects and provides the
context in which technical methods are applied, work products are produced, milestones
are established, quality is ensured, and change is properly managed.

Methods

 Software engineering methods provide the technical how-to’s for building software.
 Methods include tasks like communication, requirements analysis, design modeling,
program construction, testing, and support.

Tools

 Software engineering tools provide automated support for the process and the methods.
When tools are integrated, the information created by one tool can be used by another
1.2 SOFTWARE PROCESS
 A software process is a collection of activities, actions, and tasks that are required to
build high-quality software.
 A process defines who is doing what when and how to reach a certain goal.

Page 3 of 31
  The aim of software process is effective on-time delivery of software with quality.
1.2.1 Elements of a software Process

Activity:
 An activity helps to achieve a broad objective (e.g., communication with stakeholders)
and is applied regardless of the application domain, size, complexity and degree of rigor
with which software engineering is to be applied.
Action
 Actions consist of the set of tasks that is used to produce the product.
Task
 A task focuses on a small, but well-defined objective that produces a tangible outcome.

1.2.2 Process framework

 A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all
software projects.
Process framework activities:
Communication
 Before starting any technical work, it is important to communicate and collaborate
with the customer and other stakeholders.
 The main objective is to understand stakeholders’ objectives for the project and to
gather requirements that helps to define software features and functions.
Planning
 Software project plan defines the software engineering work by describing the
technical tasks to be conducted, the risks that are likely, the resources that will be
required, the work products to be produced, and a work schedule.
Modeling
 Model helps to better understand software requirements and the design that will
achieve those requirements.
Construction
 This activity combines code generation and the testing that is required to uncover
the errors in the code.

Page 4 of 31
Deployment
 The software is delivered to the customer, who evaluates the product and provides
feedback based on the evaluation.
 Generally, the framework activities are applied iteratively as a project progresses.
 Each project iteration produces a software increment that provides stakeholders with a
subset of overall software features and functionality.
 As each increment is produced, the software becomes more and more complete.
 The Process framework activities are complemented by a number of umbrella activities
which helps to manage and control progress, quality, change, and risk.
Umbrella activities:
 Software project tracking and control helps to assess progress against the
project plan and take any necessary action to maintain the schedule.
 Risk management assesses risks that may affect the outcome and quality of the
project.
 Software quality assurance defines the activities required to ensure software
quality.
 Technical reviews assess the products to uncover and remove errors before they
are propagated to the next activity.
 Measurement defines and collects process, project, and product measures that
assist the team in delivering software that meets stakeholders’ needs.
 Software configuration management manages the effects of change throughout
the software process.
 Reusability management defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.
 Work product preparation and production encompasses the activities required
to create work products such as models, documents, and lists.
 So a process adopted for one project might be significantly different than a process
adopted for another project.

Page 5 of 31
1.3 PROCESS MODEL

SOFTWARE PROCESS
PROCESS FRAMEWORK
UMBRELLA ACTIVITIES
Framework activity #1
Software Engineering action #1.1
Work tasks
Task sets
Work Products
Quality Assurance Points
Project milestones

Software Engineering action #1.k

Work tasks
Task sets Work Products
Quality Assurance Points
Project milestones

.
.
Framework activity #n
Software Engineering action #n.1
Work tasks
Work Products
Task sets Quality Assurance Points
Project milestones

Software Engineering action #n.m

Work tasks
Work Products
Quality Assurance Points
Task sets Project milestones

Fig: A Generic Process Model

 Process Flow:
Process flow describes how the framework activities and the actions and tasks that
occur within each framework activity are organized with respect to sequence and
time
 Linear process flow executes each of the five activities in sequence.
 An iterative process flow repeats one or more of the activities before
proceeding to the next.

Page 6 of 31
  An evolutionary process flow executes the activities in a circular manner.
Each evolution leads to a more complete version of the software.
 A parallel process flow executes one or more activities in parallel with other
activities.

1.3.1 Defining a Framework Activity:

 Defining refers to specifying what actions are appropriate for a framework activity, given
the nature of the problem to be solved, the characteristics of the people doing the work,
and the stakeholders.

Page 7 of 31
  For a small software project, the communication activity includes contacting the
stakeholder, discuss the requirements, generate a brief statement of the requirement and
get the review and approval of it from the stakeholder.
 For complex Projects, the communication activity might have six distinct actions:
inception, elicitation, elaboration, negotiation, specification, and validation.
1.3.2 Identifying a Task Set
 A task set defines the actual work to be done to accomplish the objectives of a software
engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
 Eg: For a small project, the task set may include:
 Make a list of stakeholders for the project.
 Informal meeting with stake holders to identify the functions required
 Discuss requirements and build a final list.
 Prioritize requirements.
 Choose the task sets that achieve the goal and still maintain quality and agility.

1.3.3 Process Patterns

 A process pattern provides a template for describing problem solutions that is
encountered during software engineering work
 The template for describing a process pattern:
o Pattern Name. - a meaningful name describing the pattern within the context
(e.g., Technical Reviews).
o Forces - The environment where the pattern is encountered.
o Type - The pattern type is specified. They are three types of patterns:
1. Stage patterns define a problem associated with a framework activity for the
process. A stage pattern has multiple related task patterns. Eg: Establishing
Communication includes the task pattern Requirements Gathering and others.
2. Task patterns define a problem associated with a software engineering action or
work task and relevant to successful software engineering practice.

Page 8 of 31
 3. Phase patterns define the sequence of framework activities that occur with the
process. Eg: Sprial Model or Prototyping
o Initial context - This describes the conditions under which the pattern applies.
o Problem - The specific problem to be solved by the pattern.
o Solution - Describes how to implement the pattern successfully and how the initial
state of the process is modified as a consequence of the initiation of the pattern.
o Resulting Context - Describes the conditions that will result once the pattern has
been successfully implemented.
o Related Patterns - Provide a list of all process patterns that are directly related to
this one. Eg: the stage pattern Communication encompasses the task patterns: Project
Team, Collaborative Guidelines, Scope Isolation, Requirements Gathering, Constraint
Description, and Scenario Creation.
o Known Uses and Examples - Indicate the specific instances in which the pattern is
applicable.
 Process patterns provide an effective mechanism for addressing problems associated with
any software process.
 After developed the process patterns can be reused for the definition of process variants.
1.4 PRESCRIPTIVE PROCESS MODELS
 Prescriptive process models stress detailed definition, identification, and application of
process activities and tasks.
 Their intent is to improve system quality, make projects more manageable, make delivery
dates and costs more predictable, and guide teams of software engineers as they perform
the work required to build a system.
Prescriptive Process model

Waterfall Incremental Evolutionary model

model Process model

Incremental RAD model Prototyping Spiral Concurren

model model t model

Page 9 of 31
1.4.1 Waterfall Model
 This is also referred as classic life cycle or linear - sequential model
 It is the oldest paradigm for SE.
 This model is used for developing projects where the requirements are well defined and
reasonably stable, it leads to a linear fashion.
 Waterfall model suggests a systematic, sequential approach to software development.
 Phases:
o Communication: Customer specification of requirements
o Planning - identifying the work task, analysing the risk involved, scheduling the
project and estimating the effort and time needed to complete the project etc
o Modelling which involves translating the requirements gathered into a design
o Construction – converting the design into the executable code and testing to
uncover the errors.
o Deployment includes delivery of the product and evaluation of the software.

Fig: Waterfall Model

 Problems/ Drawbacks:
1. Real projects rarely follow the sequential process flow.
2. The linear model can accommodate iteration, but it does so indirectly which can
cause confusion as the project team proceeds.
3. It is difficult for the customer to state all requirements explicitly.
4. The customer must have patience. A working version of the program will not be
available until late in the project time span. A major blunder, if undetected until
the working program is reviewed, can be disastrous.
 The linear nature of the classic life cycle leads to “blocking states” in which some
project team members must wait for other members of the team to complete dependent

Page 10 of 31
 tasks. The time spent waiting can exceed the time spent on productive work. The
blocking states tend to be more prevalent at the beginning and end of a linear sequential
process.
 It can serve as a useful process model in situations where requirements are fixed and
work is to proceed to completion in a linear manner.

1.4.2 V-Model
 A variation of waterfall model is referred as V model which includes the quality
assurance actions associated with communication, modeling and early code construction
activities.
 Team first moves down the left side of the V to refine the problem requirements.
 Once code is generated, the team moves up the right side of the V, performing a series of
tests that validate each of the models created.
 The V-model provides a way of visualizing how verification and validation actions are
applied at the different stages of development.

Fig: V - Model
1.4.3 Incremental Process Models
 Incremental models construct a partial implementation of a total system and then slowly
add increased functionality
 The incremental model prioritizes requirements of the system and then implements them
in groups.

Page 11 of 31
 Each subsequent release of the system adds function to the previous release, until all
designed functionality has been implemented.
 It combines elements of both linear and parallel process flows.
 Each linear sequence produces deliverable increments of the software.
 The first increment is the core product with many supplementary features.
 After implementation and 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 includes additional features and functionality.
 This process is repeated following the delivery of each increment, until the complete
product is produced.

Fig: Incremental Model

 For example, word-processing software developed using the incremental paradigm might
deliver basic file management, editing, and document production functions in the first
increment; more sophisticated editing and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced page
layout capability in the fourth increment.
 It should be noted that the process flow for any increment can incorporate the prototyping
paradigm.
 The incremental process model focuses on the delivery of an operational product with
each increment.
 Incremental development can be used when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. If the

Page 12 of 31
 core product is well received, then additional staff if required can be added to implement
the next increment.
 Increments can be planned to manage technical risks.

RAD (Rapid Application Development)

 RAD model is based on prototyping and iterative development with no specific planning
involved.
 Different phases of RAD model include
1. Business Modeling
On basis of the flow of information and distribution between various business
channels, the product is designed.
2. Data Modeling
The information collected from business modeling is refined into a set of data
objects that are significant for the business
3. Process Modeling
The data object that is declared in the data modeling phase is transformed to
achieve the information flow necessary to implement a business function
4. Application Generation
Automated tools are used for the construction of the software, to convert process
and data models into prototypes
5. Testing and Turnover
As prototypes are individually tested during every iteration, the overall testing
time is reduced in RAD.

Page 13 of 31
Advantages
 Use of reusable components helps to reduce the cycle time of the project.
 Encourages user involvement
 Reduced cost.
 Flexible and adaptable to changes
Disadvantages
 For large scalable projects, RAD requires sufficient human resources to create the right
number of RAD teams.
 If developers and customers are not committed to the rapid-fire activities, then project
will fail.

Page 14 of 31
  If a system cannot properly be modularized, building the components necessary for RAD
will be problematic.
 The use of powerful and efficient tools requires highly skilled professionals.
 Customer involvement is required throughout the life cycle.

1.4.4 Evolutionary Models

 In some cases the requirement changes over time, for such projects evolutionary approach
can be used where a limited version is delivered to meet competitive pressure.
 In this model, a set of core product and requirements is well understood, but the details
and extension have yet to be defined.
 It is iterative that enables to develop increasingly more complete version of the software.
 Two types of evolutionary approaches are there namely
o Prototyping and
o Spiral models.
Prototyping
 The process of building a preliminary design, trying it out, refining it, and trying again
has been called an iterative process of systems development.
 Prototyping is more explicitly iterative than the conventional life cycle, and it actively
promotes system design changes.
 Prototyping consists of building an experimental system rapidly and inexpensively for
end users to evaluate.
 By interacting with the prototype, users can get a better idea of their information
requirements.
 The prototype can be used as a template to create the final system.
 The prototype is a working version of the system or part of the system, but it is meant to
be only a preliminary model. After implementing, the prototype will be further refined
until it conforms precisely to users’ requirements.
 When to use:
Customer defines a set of general objectives but does not identify detailed
requirements or the developer may not be sure of the efficiency of an algorithm.

Page 15 of 31
 Fig: Prototype model
 Phases:
 Begins with communication by meeting with stakeholders to define the objective,
identify whatever requirements are known, outline areas where further definition is
necessary.
 A quick plan for prototyping and modeling is determined.
 Quick design focuses on a representation of those aspects the software that will be
visible to end users.
 Design leads to the construction of a prototype which will be deployed and evaluated.
Stakeholder’s comments will be used to refine requirements.
Advantages and Disadvantages of Prototyping:
 Prototyping is most useful when there is some uncertainty about requirements or design
solutions.
 Because prototyping encourages end-user involvement throughout the systems
development life cycle, it is more likely to produce systems that fulfill user requirements.
 If the completed prototype works reasonably well, there is no need for reprogramming
and redesign.

Page 16 of 31
Spiral Model
 Spiral model couples the iterative nature of prototyping with the systematic aspects of the
waterfall model
 It is a risk-driven process model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
 Two main distinguishing features:
- Cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
- Set of anchor point milestones for ensuring stakeholder commitment to feasible
and mutually satisfactory system solutions.
 A series of evolutionary releases are delivered.
 During the early iterations, the release might be a model or prototype. During later
iterations, increasingly more complete version of the engineered system are produced.
 The first circuit in the clockwise direction might result in the product specification;
subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software.
 After each iteration, the project plan has to be refined. Cost and schedule are adjusted
based on feedback. Also, the number of iterations will be adjusted by project manager.

Advantages & disadvantages:

 Good to develop large-scale system as software evolves as the process progresses and
risk should be understood and properly reacted to.
 Prototyping is used to reduce risk.

Page 17 of 31
  It is difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise.
Three Concerns on Evolutionary Processes
 First concern is that prototyping poses a problem to project planning because of the
uncertain number of cycles required to construct the product.
 Second, it does not establish the maximum speed of the evolution. If the evolution occurs
too fast, without a period of relaxation, it is certain that the process will fall into chaos.
On the other hand, if the speed is too slow then productivity could be affected.
 Third, software processes should be focused on flexibility and extensibility rather than on
high quality. The speed of the development should be prioritized over zero defects.
Extending the development in order to reach high quality could result in a late delivery of
the product when the opportunity niche has disappeared.

1.4.5 Concurrent Model

 Allow a software team to represent iterative and concurrent elements of any of the
process models. For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions: prototyping, analysis
and design.
 The Figure shows modeling may be in any one of the states at any given time.

 For example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition into the

Page 18 of 31
 under development state. If customer indicates changes in requirements, the modeling
activity moves from the under development state into the awaiting changes state.
 Concurrent modeling is applicable to all types of software development
 This provides an accurate picture of the current state of a project.
 Rather than confining software engineering activities, actions and tasks to a sequence of
events, it defines a process network.
 Each activity, action or task on the network exists simultaneously with other activities,
actions or tasks.
 Events generated at one-point trigger transitions among the states.
1.5 SPECIALIZED PROCESS MODEL
 These models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen.
1.5.1 Component-Based Development
 The component-based development model incorporates many of the characteristics of the
spiral model.
 It is evolutionary in nature, uses an iterative approach to the creation of software.
 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 to develop the
software:

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.

Page 19 of 31
  The component-based development model leads to software reuse, and reusability
provides software engineers with a number of measurable benefits.
 This model helps to reduce the development cycle time as well as the project cost

1.5.2 The Formal Methods Model

 Every software engineering methodology is based on a recommended development

process proceeding through several phases:
 Requirements, Specification, Design
 Coding, Unit Testing
 Integration and System Testing, Maintenance
 Formal methods can
 Be a foundation for designing safety critical systems
 Be a foundation for describing complex systems
 Provide support for program development
 The formal methods model has a set of activities that leads to formal mathematical
specification of computer software.

 Formal methods help to specify, develop, and verify a computer-based system by

applying a mathematical notation.

 Ambiguity, incompleteness, and inconsistency can be discovered and corrected more

easily
 When formal methods are used during design, they help in program verification and
therefore enable to discover and correct errors.
 Thus the formal methods model provides defect-free software.
 Drawbacks:
 The development of formal models is 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.

Page 20 of 31
1.5.3 Aspect-Oriented Software Development

 Aspect-oriented software development (AOSD) aims to address crosscutting concerns by

providing means for systematic identification, separation, representation and
composition.
 Crosscutting concerns are encapsulated in separate modules, known as aspects, so that
localization can be promoted. This results in better support for modularization hence
reducing development, maintenance and evolution costs.
 Some Crosscutting concerns are high-level properties of a system (e.g., security, fault
tolerance). Other concerns affect functions (e.g., the application of business rules), while
others are systemic (e.g., task synchronization or memory management).
 Aspect-oriented software development (AOSD) is often referred as aspect-oriented
programming (AOP), provides a process and methodological approach for defining,
specifying, designing, and constructing aspects.
 An aspect-oriented process is likely to adopt 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.
Advantages:
 Provides better modularization support of software designs, reducing software design,
development and maintenance costs
 Because concerns are encapsulated into different modules, localization of crosscutting
concerns is better promoted and handled.
 Promotes reusability of code
 Smaller code size, due to tackling cross cutting concerns

Aspect-oriented component engineering (AOCE):

 AOCE uses a concept of horizontal slices through vertically-decomposed software

components, called “aspects,” to characterize cross-cutting functional and non-functional
properties of components.

Page 21 of 31
  Systemic aspects include user interfaces, collaborative work, distribution, persistency,
memory management, transaction processing, security, integrity and so on.
 Components may provide aspect details relating to a particular aspect, such as a viewing
mechanism, extensible affordance and interface kind (user interface aspects); event
generation, transport and receiving (distribution aspects); data store/retrieve and indexing
(persistency aspects); authentication, encoding and access rights (security aspects);
transaction atomicity, concurrency control and logging strategy (transaction aspects); and
so on.

1.6 INTRODUCTION TO AGILITY

1.6.1 What is Agility?
 Agility is effective (rapid and adaptive) response to change (changes in team members,
new technology, requirements etc) that may have an impact on the product being
developed.
 It encourages effective communication in structure and attitudes among all team
members, technological and business people, software engineers and managers.
 It emphasizes rapid delivery of operational software and de-emphasizes the importance of
intermediate work products (not always a good thing);
 It involves the customer in the development team and works to eliminate the “us and
them” attitude that continues to pervade many software projects
 It recognizes that planning in an uncertain world has its limits and that a project plan
must be flexible.
 Agility can be applied to any software process but it is essential that the process should
support incremental delivery strategy that gets working software to the customer as
rapidly as feasible for the product type and operational environment.

1.6.2 Agility and the Cost of Change

 The cost of change increases nonlinearly as a project progresses.
 It is easy to accommodate a change in the early stages of a project and cost will be
minimal but in case of major functional change, it requires a modification to the
architectural design, construction, testing etc. so the Costs escalate quickly.

Page 22 of 31
DOWNLOADED FROM STUCOR APP

 A well-designed agile process may “flatten” the cost of change curve by coupling the
incremental delivery with agile practices such as continuous unit testing and pair
programming. Thus team can accommodate changes late in the software project without
dramatic cost and time impact.

1.6.3 Agility Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face–to–face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.

Page 23 of 31
 11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
1.6.4 Human Factors
 “Agile development focuses on the talents and skills of individuals, molding the
process to specific people and teams.” i.e. The process molds to the needs of the
people and team, not the other way around.
 The key traits that must exist among the people on an agile team are:
 Competence.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.
1.6.5 Agile Process
 Agile software process addresses a number of key assumptions say:
1. It is difficult to predict in advance which software requirements will persist and which
will change. It is equally difficult to predict how customer priorities will change as the
project proceeds.
2. For many types of software, design and construction are interleaved. It is difficult to
predict how much design is necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning point
of view) as we might like.
 An agile process must be adaptable in order to manage the unpredictability.
 An agile software process must adapt incrementally.
 Agile SDLC model is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of working
software product.
 Agile Methods break the product into small incremental builds.

Page 24 of 31
 Each build is incremental in terms of features and the final build holds all the features
required by the customer.
 Every iteration involves cross functional teams working simultaneously on various areas
like −
 Planning
 Requirements Analysis
 Design
 Coding
 Testing
 In Agile methodology, there is no detailed planning and there is clarity only in respect of
what features need to be developed. The team adapts to the changing product requirements
dynamically.
 The product is tested very frequently, through the release iterations, minimizing the risk of
any major failures in future.

 Program specification, design, and implementation are interleaved.

 The system is developed as a series of frequent versions or increments.
 Stakeholders involved in version specification and evaluation.
 Extensive tool support (e.g. automated testing tools) used to support development.
 Minimal documentation - focus on working code.

Page 25 of 31
Advantages:
 Rapid Functionality development
 Promotes team work
 Adaptable to changing requirements
 Delivers early partial working solutions.
 Flexible and Easy to manage.
Disadvantages
 Not suitable for complex projects/dependencies.
 Depends heavily on customer interaction, so if customer is not clear, team can be driven
in the wrong direction.
 Prioritizing changes can be difficult where there are multiple stakeholders.
Note:
Agile methods include Rational Unified Process, Scrum, Extreme Programming, Adaptive
Software Development, Crystal clear, Feature Driven Development, and Dynamic Systems
Development Method. These are now collectively referred to as Agile Methodologies.

1.7 Extreme Programming (XP)

What is Extreme Programming?
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way
to develop a software.
 Extreme Programming (XP), the most widely used approach to agile software
development proposed by Kent Beck.
 Recently, a variant of XP, called Industrial XP (IXP) has been proposed which refines XP
and targets the agile process specifically for use within large organizations.
1.7.1 XP Values
 XP is based on the 5 values:
1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect.

Page 26 of 31
  Each of these values is used as a driver for specific XP activities, actions, and tasks.
Communication
 To achieve effective communication, XP emphasizes close, informal (verbal)
collaboration between customers and developers.
Simplicity
 To achieve simplicity, XP restricts developers to design only for immediate needs, rather
than consider future needs. The design can be refactored later if necessary.
Feedback
 Feedback is derived from three sources: the implemented software itself, the customer,
and other software team members.
Courage
 Team should be prepared to make hard decisions that support the other principles and
practices.
Respect
By following each of these values, the agile team inculcates respect among its members,
between other stakeholders and team members, and indirectly, for the software itself.
1.7.2 XP Process
Extreme Programming uses an object-oriented approach that encompasses a set of rules
and practices that occur within the context of four framework activities:
 Planning
 Design
 Coding
 Testing

Page 27 of 31
XP Planning
 The planning activity is also called as planning game.
 Planning begins with a requirements gathering where customers and developers negotiate
requirements in the form of User stories captured on index cards.
 User stories describe the required output, 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 (i.e., a priority) to the story based on the overall business
value of the function.
 Agile team assesses each story and assigns a cost measured in development weeks.
 If the story is estimated to 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.
 Stories are grouped to for a deliverable increment and a commitment is made on delivery
date.
 Stories are 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.
Fig: Sample Index card with User stories
#5
Customer can change his/her personal information in
the system

Priority: 2 (high/low/medium)
Estimate: 4 (development weeks)
 After the first increment, the XP team computes project velocity.
 Project velocity is the number of customer stories implemented during the first release.
 Project velocity can be used to
1. help estimate delivery dates and schedule for subsequent releases.
2. determine whether an over commitment has been made for all stories across the
entire development project.

Page 28 of 31
  During development, the customer can add new stories, change the value of an existing
story, split stories, or eliminate them. The XP team then reconsiders all and modifies its
plans accordingly.
XP Design
 XP design follows the KIS (keep it simple) principle.
 A simple design is preferred than complex representation.
 Design provides implementation guidance for the story.
 XP encourages the use of CRC cards. CRC (class-responsibility collaborator) cards
identify and organize the object-oriented classes that are relevant to the current software
increment.
 Eg: sample CRC for ATM system
Class : User Menu
Responsibility Collaborators
Display Main menu Bank System
Ask PIN
Validate PIN .
Select transaction type
Debit amount Printer
Print balance etc

 The CRC cards are the only design work product produced as part of the XP process.
 For difficult design problems, XP recommends creation of an intermediate operational
prototype called a spike solution.
 XP encourages “refactoring”—an iterative refinement of the internal program design
XP Coding
 XP recommends the construction of a unit test for a store before coding commences.
 A key concept during the coding activity is “pair programming”
 This provides a mechanism for real-time problem solving and real-time quality assurance.
 As pair programmers complete their work, the code they develop 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.

Page 29 of 31
XP Testing
 XP uses Unit and Acceptance Testing.
 All unit tests are executed daily
o “Acceptance tests” are defined by the customer and executed to assess customer
visible functionality
 The unit tests that are created should be implemented using a framework that enables
them to be automated.
 This encourages a regression testing strategy whenever code is modified.
 The individual unit tests are organized into a “universal testing suite”, integration and
validation testing of the system can occur on a daily basis.
 This provides the XP team with a continual indication of progress and also can raise
warning flags early if things go awry.
 XP acceptance tests (customer tests), are specified by the customer and focus on overall
system features and functionality. Acceptance tests are derived from user stories.

1.7.3 Industrial XP
IXP incorporates six new practices that are designed to help ensure that an XP project
works successfully for significant projects within a large organization.
1. Readiness assessment:
The assessment ascertains whether (1) an appropriate development environment
exists to support IXP, (2) the team will be populated by the proper set of stakeholders, (3)
the organization has a distinct quality program and supports continuous improvement, (4)
the organizational culture will support the new values of an agile team, and (5) the
broader project community will be populated appropriately.
2. Project community:
Classic XP suggests that the right people be used to populate the agile team to
ensure success. The people on the team must be well-trained, adaptable and skilled, and
have the proper temperament to contribute to a self-organizing team.
3. Project chartering:
Chartering also examines the context of the project to determine how it
complements, extends, or replaces existing systems or processes.

Page 30 of 31
4. Test-driven management:
Test-driven management establishes a series of measurable “destinations “and
then defines mechanisms for determining whether or not these destinations have been
reached.
5. Retrospectives:
An IXP team conducts a specialized technical review after a software increment is
delivered. Called a retrospective, the review examines “issues, events, and lessons-
learned” across a software increment and/or the entire software release.
6. Continuous learning:
Because learning is a vital part of continuous process improvement, members of
the XP team are encouraged to learn new methods and techniques that can lead to a
higher quality product.

Page 31 of 31