Topic II

Systems Development Life Cycle

Def: A framework that describes the

activities performed at each stage of a
software development project.
 Learning Outcomes
At the end of the section, the students should be able to;
Describe the SDLC
Mention the different approaches/methodologies/
models of Software Development
Explain the criteria for selecting a model
 SDLC
Systems Systems Requirements
Investigation Analysis Engineering

Systems
Systems Testing Systems Design
Development

Systems
Systems
Implementation
Maintenance
and evaluation
 Systems Investigation
Some authors omit it, it is an important phase without
which an information system will not have a basis
and it determines the success of the project.

The deliverable at this phase is the feasibility report

containing the problem definition and summarized
objectives. Management must make a decision on
whether to proceed with the proposed system
 Feasibility Reports
Technical feasibility - whether the technology exists to
implement the proposed system.
Economic feasibility – cost-benefit analysis.
Legal feasibility – e.g., will the system contravene the
Information Privacy Act?
Operational/Behavioural feasibility - whether the
current work practices and procedures are adequate to
support the new system, the social factors on employees.
Time/Schedule Feasibility – Whether the project will be
implemented in time
Environmental Feasibility – to ensure the project will
not have adverse negative effects on the environment.
 Systems Analysis
Studies the system operation by studying data flows or
process flows with the view of improving it using e.g.
Entity Relation Diagram (ERD), Entity Life History
(ELH) (diagrammatic presentation of how information
may change over time), Data Flow Diagram (DFD)
{storage, information flow, processes, and entities all
represented diagrammatically} to chart the input, output
& processes of the business functions in a structured
graphical form. A data dictionary is developed (lists all
the data items & specifications).
 Requirements Engineering
The deliverable at this phase is the System
Requirements Specification (SRS) document
Types of requirements
 Business Requirements: the critical activities that
must be performed to meet the objectives of the
company
 User Requirement: how the users want the system
to support them in their work.
 Requirements Engineering…
Types of requirements…
 Functional Requirement: the core operations of the
system e.g. process payroll, store information etc.
 Non functional Requirements: how well the
system should operate e.g. security, operational
efficiency, speed, scalability etc
 System Requirements (Physical): Software and
Hardware requirements etc.
 System Design

Accomplishes the logical (What sys must do) and

physical (how to work) design of the IS.
During system design, the analyst/designer emphasizes
the graphical user interface (GUIs), Input/output
design, backend databases and system architecture in
form of a prototype. Analyst should emphasize on User
Interface, designing files/databases that will store much
of the data needed by decision maker and controls and
backup procedures to protect the system and data.
 Systems Development
The design is built physically. Programmers write
codes/programs the system will use to execute its
functional requirements. The system design is put into
its physical shape ready to be used (implemented).
 
Testing and documentation can be done concurrently
e.g. procedure manuals, online help etc. documentation
tells users how to use software and what to do if
software problems occur.
 Testing
To see its compatibility with user requirements and
how it effectively addresses the identified problems.
Testing is also meant to identify bugs in the software.
 Systems Implementation and
Evaluation
The developed system is put into operation. It involves
training users (on job or off job) to handle the system by
vendors. The system analyst must also plan for the
smooth conversion of the new system from the old
system. Conversion involves converting file from old
format, building databases, installing equipment and
bringing the new system into production.
 
Its at this phase that the users takes over the system for
use and evaluate its performance the analyst is sign off.
 System Maintenance
After the system is installed, is must be maintained i.e.
keeping it up to date by upgrading software, hardware
etc. The system should be maintained to reflect
business requirements but when the system becomes
obsolete, the IS life cycle is repeated.

It is important to document each stage for usage, future

reference and troubleshooting
 Software Development
Approaches/Models/Methodologies
Prototyping
Waterfall method
Rapid Application Design
Joint Application Design
Spiral model
V-Shaped model
Structured System Analysis and Design Method
Extreme Programming
Dynamic System Development Method
 Other methodologies
Parallel development
Phased development
Throwaway prototyping
Cumulative Model
Adaptive Software Development (ASD)
Feature Driven Development (FDD)
Crystal Clear
Scrum
Rational Unify Process (RUP)
etc
 Criteria for selecting a Methodology
Clarity of User requirements: when user
requirements are not clear, prototyping, DSDM, XP
and RAD are appropriate.
Familiarity with technology: when the developers are
not familiar with the technology that they need to
develop a system, a lot of risks are involved, therefore
methodologies such as Spiral model are preferred.
System complexity: some systems are more complex
to develop, therefore choice should be of indepth
analysis – XP, Spiral etc
 Criteria…
System Reliability: Some systems e.g. for medical
equipment, missile control systems etc need a high
degree of reliability, comprehensive testing should be
done during the cycle, e.g. in XP and V-Model
Short time schedules: systems that have a short
time scope for development need methodologies like
RAD, DSDM, XP and prototyping. Waterfall method
is the most time consuming.
 Criteria…
Schedule visibility: some systems need constant
checking to determine whether its on schedule. There
is need to measure pace of development; XP is the
most appropriate.
Need for end user involvement: systems that
require high participation of end users would dictate
on the methodology to use. The best to use would be
JAD, XP, RAD
 Problems when Initiating New or
Modified Systems
 Fear that employee will lose his/ her job, power, or influence
within the organization
 Belief that the proposed system will create more work than it
eliminates
 Reluctance to work with “computer people”/IT technicians
 Anxiety that proposed system will negatively alter
organization’s structure
 Belief that other problems are more pressing, or that the
system is being developed by people unfamiliar with “the way
things need to get done”
 Unwillingness to learn new procedures or approaches
 Prototyping
An iterative approach to systems development
Prototyping is the process of building a model of a
system. In terms of an IS, prototypes are employed
to help system designers build an IS that is
intuitive and easy to manipulate for end users.
Prototyping is an iterative process that is part of
the analysis phase of the SDLC.
 Prototyping…
Prototypes can be;
Operational prototype
Accesses real data files, edits input data, makes
necessary computations and comparisons, and
produces real output
Non-operational prototype
A mockup, or model
 Prototyping…
During the requirements determination stage, system
analysts gather info about the organization's current
procedures and b’ness processes related to the proposed
IS. In addition, they study the current IS, and conduct
user interviews and collect data. This helps the analysts
develop an initial set of system requirements.

Prototyping can augment this process because it

converts these basic, yet sometimes intangible,
specifications into a tangible but limited working model
of the desired IS.
 Prototyping…
The user feedback gained from developing a physical
system that the users can touch and see facilitates
an evaluative response that the analyst can employ
to modify existing requirements as well as
developing new ones.
Prototyping comes in form of;
Low tech sketches or paper screens (Pictive) from
which users and developers can paste controls and
objects
High tech operational systems using CASE
(computer-aided software engineering) or 4th GLs
etc. Many organizations use multiple prototyping
tools.
An Iterative Approach to Systems
Development
Summary Illustration
 Prototyping is comprised of the
following steps:
 Requirements Definition/Collection: not as
comprehensive as that of Waterfall. The info collected is
usually limited to a subset of the complete system
requirements.
 Design: Once the initial layer of requirements info is
collected, or new info is gathered, it is rapidly integrated
into a new or existing design so that it may be folded into
the prototype.
 Prototype Creation/Modification: The info from the
design is rapidly rolled into a prototype. This may mean
the creation/modification of paper information, new
coding, or modifications to existing coding.
 Prototyping steps….
Assessment: The prototype is presented to the
customer for review. Comments and suggestions are
collected from the customer.
Prototype Refinement: Information collected from
the customer is digested and the prototype is refined.
The developer revises the prototype to make it more
effective and efficient.
System Implementation: In most cases, the system
is rewritten once requirements are understood.
Sometimes, the Iterative process eventually
produces a working system that can be the
cornerstone for the fully functional system.
 Problems/Challenges Associated
with the Prototyping Model
Can lead to false expectations; it often creates a
situation where the customer mistakenly believes that
the system is "finished" when in fact it is not.
Can lead to poorly designed systems; The design
of the system can sometimes suffer because the
system is built in a series of "layers" without a global
consideration of the integration of all other
components.
Can lead to System Scope creep
 Advantages of Prototyping
Reduces development time and costs.
Requires user involvement
Developers receive quantifiable user feedback.
Facilitates system implementation since users know
what to expect.
Results in higher user satisfaction.
Exposes developers to potential future system
enhancements
 Advantages of Prototyping
Early detection of errors and omissions
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness
of additional needed functionality
 Disadvantages of Prototyping
Can lead to insufficient analysis.
 Users expect the performance of the ultimate system to
be the same as the prototype.
 Developers can become too attached to their
prototypes
Can cause systems to be left unfinished and/or
implemented before they are ready.
 Sometimes leads to incomplete documentation.
Overall maintainability may be overlooked
Process may continue forever (scope creep)
 When to use Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a waterfall
model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-
oriented development.
 Prototyping

Because prototypes inherently increase the quality and

amount of communication between the
developer/analyst and the end user, its' use has
become widespread. In the early 1980's,
organizations used prototyping approx 30% of the
time in development projects. By the early 1990's, its
use had doubled to 60%. Although there are
guidelines on when to use software prototyping, two
experts believed some of the rules developed were
nothing more than conjecture.
 Rapid Application Development
(RAD)
A technique that employs tools, techniques,
and methodologies designed to speed
application development
It compresses the analysis, design, build, and test
phases into a series of short, iterative development
cycles.
Staffed with small integrated teams of developers,
end users, and IT technical resources for speed, unity
of vision and purpose, effective informal
communication and simple project management.
Illustration
Illustration
 Advantages of RAD
Iteration allows for effectiveness and self-correction.
RAD forces teamwork, and interaction between the
different staff groupings
Reduced cycle time and improved productivity with
fewer people means lower costs
Focus moves from documentation to code
(WYSIWYG).
Documentation is produced as a by product of
completing project tasks
Uses modeling concepts to capture information about
business, data, and processes.
 Disadvantages of RAD
Its intensity can burn out the participants
The method requires all the participants to have skills
in RAD systems development tools and techniques
It requires a larger percentage of users’ and
stakeholders’ time than the other approaches
Accelerated development process must give quick
responses to the user
 Disadvantages of RAD…
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
 When to use RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized
 Joint Application Development

A process for data collection and

requirements analysis involving group
meetings

It brings together users and IT professionals in a highly

focused workshop with agenda, facilitators, visual
aids, constant feedback and encourages creativity.
 JAD
JAD sessions are:
Very focused
Conducted in a dedicated environment
Quickly drive major requirements and interface
"look & feel"
 JAD
JAD participants typically include:
Facilitator – facilitates discussions, enforces rules
End users – 3 to 5, attend all sessions
Developers – 2 or 3, question for clarity
Observers – 2 or 3, do not speak
Subject Matter Experts – limited number for
understanding business & technology
Illustration
 Advantages of JAD
A dramatic shortening of the time it takes to
complete a project.
Improves the quality of the final product by
focusing on the up-front portion of the development
lifecycle, thus reducing the likelihood of errors that
are expensive to correct later on.
 Disadvantages
Due to the fact that is involves many participants,
sometimes some may have different views
It is sometimes costly to run the workshops
 The Waterfall Model
Under this model, each phase of systems
development has to be completed and
signed off before moving to another phase.
Therefore this model takes a long time and is very
rigid
 The Waterfall Model
It is the earliest method of structured system
development. Although it has come under attack in
recent years for being too rigid and unrealistic when
it comes to quickly meeting customer's needs, the
Waterfall Model is still widely used.
It is attributed with providing the theoretical basis for
other Process Models, because it most closely
resembles a "generic" model for software
development.
Illustration…
 Steps in The Waterfall Model
System Conceptualization; the consideration of all
aspects of the targeted business function or process,
with the goals of determining how each of those
aspects relates with one another, and which aspects will
be incorporated into the system.
Systems Analysis; the gathering of system
requirements, and determining how these requirements
will be accommodated in the system. Extensive
communication between the customer and the
developer is essential.
 Steps in The Waterfall Model
System Design; it is necessary to identify in detail how
the system will be constructed to perform necessary
tasks. System Design phase is focused on the data
requirements (what information will be processed in
the system?), the software construction (how will the
application be constructed?), and the interface
construction (what will the system look like? What
standards will be followed?).
 Steps in The Waterfall Model
Coding; aka programming, involves the creation of the
system software. Requirements and systems
specifications from the System Design step are
translated into machine readable computer code.
Testing; to ensure that the software is working
correctly and efficiently. Generally focused on two
areas: internal efficiency (to make sure that the
computer code is efficient, standardized, and well
documented) and external effectiveness (to verify that
the software is functioning according to system design,
and that it is performing all necessary functions or sub-
functions).
 Problems/Challenges
 Real projects rarely follow the sequential flow that the
model proposes.
 At the beginning of most projects there is often a great
deal of uncertainty about requirements and goals, and it
is therefore difficult for customers to identify these
criteria on a detailed level. The model does not
accommodate this natural uncertainty very well.
 Developing a system using the Waterfall Model can be a
long, painstaking process that does not yield a working
version of the system until late in the process.
 Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost
or schedule
 Waterfall Deficiencies
All requirements must be known upfront
Deliverables created for each phase are considered
frozen – inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software
development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system
(until it may be too late)
 When to use the Waterfall Model
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
 V-Shaped Model
A variant of the Waterfall that emphasizes the
verification and validation of the product.
Testing of the product is planned in parallel with a
corresponding phase of development
The process steps are bent upwards after the
coding phase, to form the typical V shape.
The V-Model demonstrates the relationships between
each phase of the development life cycle and its
associated phase of testing.
V-Shaped Model
 V-Shaped Steps
 Project and Requirements
Planning – allocate
resources
 Product Requirements and
Specification Analysis –
complete specification of
the software system
 Architecture or High-
Level Design – defines how
software functions fulfill the
design
 Detailed Design – develop
algorithms for each
architectural component
 Production, operation and
maintenance – provide for
enhancement and
corrections
 System and acceptance
testing – check the entire
software system in its
environment
 Integration and Testing –
check that modules
interconnect correctly
 Unit testing – check that
each module acts as
expected
 Coding – transform
algorithms into software
 V-Shaped Strengths
Emphasize planning for verification and validation
of the product in early stages of product development
Each deliverable must be testable
Project management can track progress by
milestones
Easy to use
 V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in
requirements
Does not contain risk analysis activities
 When to use the V-Shaped Model
Excellent choice for systems requiring high
reliability – hospital patient control applications
All requirements are known up-front
When it can be modified to handle changing
requirements beyond analysis phase
Solution and technology are known
 Spiral Model
The Spiral Model introduces risk-assessment. Similar
to the Prototyping Model, an initial version of the
system is developed, and then repetitively modified
based on input received from customer evaluations.
Unlike the Prototyping Model, however, the
development of each version of the system is
carefully designed using the steps involved in the
Waterfall Model. With each iteration around the
spiral (beginning at the center and working outward),
progressively more complete versions of the system
are built.
 Spiral Risk Analysis
Risk assessment is included as a step in the
development process as a means of evaluating each
version of the system to determine whether or not
development should continue. If the customer
decides that any identified risks are too great, the
project may be halted. E.g. incase of too much cost
increment, the project may be stopped
 Steps in the Spiral Model
 Project Objectives determination; Similar to the system
conception phase of the Waterfall Model. Objectives are
determined, possible obstacles are identified and alternative
approaches are weighed.
 Risk Assessment; Possible alternatives are examined by the
developer, and associated risks/problems are identified.
Resolutions of the risks are evaluated and weighed in the
consideration of project continuation.
 Engineering & Production. Detailed requirements are
determined and the software piece is developed.
 Planning and Management. The customer is given an
opportunity to analyze the results of the version created in the
Engineering step and to offer feedback to the developer.
 Spiral Quadrant
Determine objectives, alternatives and constraints
 Objectives: functionality, performance, hardware/software
interface, critical success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
Evaluate alternatives, identify and resolve risks
 Study alternatives relative to objectives and constraints
 Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by continuing
system development
 Spiral Quadrant

Develop next-level Plan next phase

product
Typical activities: Typical activities
Create a design Develop project plan
Review design Develop
Develop code configuration
Inspect code management plan
Test product Develop a test plan
Develop an
installation plan
 Spiral steps
• Objectives are determined • Possible alternatives
are determined
• Risks are analyzed

Project Risk
Objectives Assessment

Planning & Engineering

Mgt & Prodn
• Users are given system to • System is
review developed
 Advantages of Spiral Model
The risk assessment component of the Spiral Model
provides both developers and customers with a
measuring tool
The practical nature of this tool helps to make the
Spiral Model a more realistic Process Model.
Provides early indication of insurmountable risks,
without much cost
Users see the system early because of rapid
prototyping tools
 Advantages of Spiral Model
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
 Spiral Model Weaknesses
 Time spent for evaluating risks too large for small or low-
risk projects
 Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-development
phase activities
 May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
 When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of
potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and
exploration)
 Structured System Analysis and
Design Method (SSADM)
SSADM is a systems approach to the analysis and
design of IS. The method adopts the waterfall model of
systems development, where each phase has to be
completed and signed off before the subsequent phases
can begin.
SSADM uses a combination of three techniques which
are cross referenced against each other to ensure the
completeness and accuracy of the whole system. The
techniques include:
 SSADM Techniques
Logical data modeling: The process of identifying, modeling
and documenting the data requirements of the system being
designed. The data is separated into entities like customer
information, order etc, and relationships between the entities.
Data flow modeling: The process of identifying, modeling and
documenting how data moves round the IS. It examines processes
(activities that transform data from one form into another), data
storage, external entities (what sends data into the IS) and data
flows (routes by which data can flow).
Entity behavior modeling: The process of identifying,
modeling and documenting the events that affect each entity and
the sequence in which these events occur.
 Agile SDLC’s
A group of software development
methodologies based on iterative and incremental
development, where requirements and solutions
evolve through collaboration between self
organizing, cross functional teams.
It promotes adaptive planning, evolutionary
development and delivery, a time-boxed iterative
approach, and encourages rapid and flexible response
to change.
 When to use Agile SDLC’s
Speed up or bypass one or more life cycle phases
Usually less formal and reduced scope
Used for time-critical applications
Used in organizations that employ disciplined
methods
 Dynamic Systems Development
Method (DSDM)
DSDM was originally based upon the RAD method. In
2007 DSDM became a generic approach to project
management and solution delivery.
It embraces principles of Agile development, including
continuous user/customer involvement.
DSDM fixes cost, quality and time at the outset and
uses the MoSCoW prioritisation of scope
into musts, shoulds, coulds and won't (want to) haves to
adjust the project deliverable to meet the stated time
constraint.
 DSDM…
As the name suggests, it develops the system
dynamically (i.e. it is a RAD method that uses
incremental prototyping).
This method is particularly useful for the systems to
be developed in short time span and where the
requirements cannot be frozen at the start of the
application building.
Whatever requirements are known at a time, design
for them is prepared and design is developed and
incorporated into system.
 DSDM…
In DSDM, analysis, design and development phase
can overlap. Like at one time some people will be
working on some new requirements while some will
be developing something for the system. In DSDM,
requirements evolve with time.
 Phases of DSDM
Feasibility study: here the problem is defined, the
technical feasibility of the desired application is
verified and it is checked if the application is suitable
for RAD.
Business study: the overall business study
(requirements) of the desired system is done and the
maintainability level is identified (since it uses RAD
and incremental development).
 Phases of DSDM
Functional Model Iteration: The prototype is built
iteratively and reviewed by the users. The prototype
is improved through demonstration to the user,
taking the feedback and incorporating the changes.
This cycle is repeated until a part of functional model
is agreed upon consisting of analysis model and
some software components containing the major
functionality
 Phases of DSDM
Design and Build Iteration: This phase stresses
upon ensuring that the prototypes are satisfactorily
and properly engineered to suit their operational
environment. The software components designed
during the functional modelling are further refined
till they achieve a satisfactory standard. The product
of this phase is a tested system ready for
implementation.
 Phases of DSDM
NB: There is no clear line between the functional
model iteration and design and build iteration phases
and there may be cases where while some component
has flown from the functional modelling to the
design and build modelling while the other
component has not yet been started. The two phases,
as a result, may simultaneously continue.
 Phases of DSDM
Implementation: users are trained and the system is
actually put into the operational environment. At the
end of this phase, there are four possibilities:
Everything was delivered as per the user demand,
so no further development is required.
A new functional area was discovered, so return
to business study phase and repeat the whole
process
 Phases of DSDM
Implementation……
A less essential part of the project was missed out
due to time constraint and so development returns
to the functional model iteration.
Some non-functional requirement was not
satisfied, so development returns to the design and
build iterations phase.
Illustration
 DSDM….
DSDM assumes that all previous steps may be
revisited as part of its iterative approach. Therefore,
the current step needs to be completed only enough
to move to the next step, since it can be finished in a
later iteration.
This premise is that the business requirements will
probably change anyway as understanding increases,
so any further work would have been wasted.
 DSDM…
According to this approach, the time is taken as a
constraint i.e. the time is fixed, resources are fixed
while the requirements are allowed to change. This
does not follow the fundamental assumption of
making a perfect system the first time, but provides a
usable and useful 80% of the desired system in 20%
of the total development time. This approach has
proved to be very useful under time constraints and
varying requirements.
 Pros and Cons of DSDM
DSDM Model Advantages
Active user participation throughout the life of the
project.
DSDM ensures rapid deliveries.
Leads to reduced project costs
DSDM Model Limitations
It is a relatively new model. It is not very common
and so it is difficult to understand.
 Extreme Programming
Extreme Programming (XP) is based on values of
simplicity, communication, feedback, and courage. It
works by bringing the whole team together in the
presence of simple practices, with enough feedback
to enable the team to see where they are and to tune
the practices to their unique situation.

Coding is the main activity through out

 Extreme Programming
Every contributor to the project is an integral part of the
“Whole Team”. The team forms around a business
representative called “the Customer”, who sits with
the team and works with them daily. An XP team can
comprise of even more than 30 members.
 XP Whole Team comprises of
Customer – business representative who provides
the requirements, sets the priorities, and steers the
project, mostly an end user of the software
Analysts – help the Customer to define the
requirements.
Programmers – help in the coding
Testers - help the Customer define the customer
acceptance tests.
 XP Whole Team …
Coach - who helps the team keep on track, and
facilitates the process.
Manager - providing resources, handling external
communication, coordinating activities.

NB: The best teams have no specialists, only general

contributors with special skills.
 Phase I
Whole Team: XP teams use a simple form of
planning and tracking to decide what should be done
and to predict when the project will be done. Focused
on business value, the team produces the software in
a series of small fully-integrated releases that pass all
the tests the Customer has defined.
 Phase II
Planning Game, Small Releases (time boxing),
Customer Tests: Extreme Programmers work
together in pairs and as a group, with simple design
and obsessively tested code, improving the design
continually to keep it always just right for the current
needs.
 Phase III
Simple Design, Pair Programming, Test-Driven
Development, Design Improvement: The XP team
keeps the system integrated and running all the time.
The programmers write all production code in pairs
of two, and all work together all the time. They code
in a consistent style so that everyone can understand
and improve all the codes as needed.
 Phase IV
Continuous Integration, Collective Code
Ownership, Coding Standard: The XP team shares
a common and simple picture of what the system
looks like. Everyone works at a pace that can be
sustained indefinitely.
 Phases V & VII
Metaphor: XP teams develop a common vision of
how the program works. The metaphor is a simple
evocative description of how the program works.
Sustainable Pace: XP teams work hard, and at a
pace that can be sustained indefinitely.
Illustration of XP…
 Pros and Cons of XP
Advantages of XP
Extensive testing reduces errors
Its has a flat management structure
The problem is better understood and changes in the
customer's requirements are catered for
Frequent communication with the customer
Disadvantages of XP
Problems with unstable requirements
Compromises and user conflicts
Lack of an overall design specification or document.