Details of Software Engineering

1. SOFTWARE
ENGINEERING
UNIT-1

2. UNIT CONTENT
• Introduction: What is software engineering? Software Development Life Cycle,
Requirements Analysis, Software Design, Coding, Testing, Maintenance etc.
• Software Requirements: Functional and Non-functional requirements, User
Requirements, System Requirements, Interface Specification, Documentation of
the software requirements.
• Software Processes:
• Process and Project, Component Software Processes.
• Software Development Process Models.
• Waterfall Model.
• Prototyping.
• Iterative Development.
• Rational Unified Process.
• The RAD Model
• Time boxing Model.
• Agile software development: Agile methods, Plan-driven and agile development,
Extreme programming, Agile project management, Scaling agile methods.

3. Introduction To Software
A system usually consisting of several separate programs ,
configuration files which are used to set up these programs,
system documentation describing the structure of the
system and user documentation

4. Types Of Software Product
A. Generic Products –
Stand-alone systems that are produced by a development
organization and sold on the open market to any
customer.
Examples – Databases, Word Processors and Project
Management Tools
B. Customized Products –
Systems commissioned by a particular customer. A
software contractor develops the software especially for
that customer.
Examples – Control systems for electronic systems and
air traffic control systems

5. What is software engineering
• Software engineering is the process of
analysing user needs and designing,
constructing, and testing end user
applications that will satisfy these needs
through the use of software
programming languages.
• It is the application of engineering
principles to software development.
• In contrast to simple programming,
software engineering is used for larger
and more complex software systems,
which are used as critical systems for
businesses and organizations.

6. Software Development Life Cycle
SDLC stands for Software
Development Life Cycle.
SDLC is a process followed for a
software project, within a
software organization.
It consists of a detailed plan
describing how to develop,
maintain, replace and alter or
enhance specific software.
The life cycle defines a
methodology for improving the
quality of software and the
overall development process.

7. LIFE CYCLE STAGES
Stage 1: Planning and Requirement Analysis
• Requirement analysis is the most important and fundamental stage in SDLC.
It is performed by the senior members of the team with inputs from the
customer, the sales department, market surveys and domain experts in the
industry.
• This information is then used to plan the basic project approach and to
conduct product feasibility study in the economical, operational and technical
areas.
• Planning for the quality assurance requirements and identification of the risks
associated with the project is also done in the planning stage.
• The outcome of the technical feasibility study is to define the various
technical approaches that can be followed to implement the project
successfully with minimum risks.

8. Stage 2: Defining Requirements
• Once the requirement analysis is
done the next step is to clearly
define and document, the product
requirements and get them
approved from the customer or the
market analysts.
• This is done through an SRS
(Software Requirement
Specification) document which
consists of all the product
requirements to be designed and
developed during the project life
cycle.

9. Stage 3: Designing the Product Architecture
• SRS is the reference for product architects to come out with the best
architecture for the product to be developed.
• Based on the requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and documented in a DDS -
Design Document Specification.
• A design approach clearly defines all the architectural modules of the product
along with its communication and data flow representation with the external
and third party modules (if any).
• The internal design of all the modules of the proposed architecture should be
clearly defined with the minutest of the details in DDS.

10. Stage 4: Building or Developing the Product
• In this stage of SDLC the actual development starts and the product is built.
• The programming code is generated as per DDS during this stage.
• If the design is performed in a detailed and organized manner, code
generation can be accomplished without much hassle.
• Developers must follow the coding guidelines defined by their organization
and programming tools like compilers, interpreters, debuggers, etc. are used
to generate the code.
• Different high level programming languages such as C, C++, Pascal, Java
and PHP are used for coding.
• The programming language is chosen with respect to the type of software
being developed.

11. Stage 5: Testing the Product
• This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of
SDLC.
• However, this stage refers to the testing only stage of the product where
product defects are reported, tracked, fixed and retested, until the
product reaches the quality standards defined in the SRS.

12. Stage 6: Deployment in the Market and Maintenance
• Once the product is tested and ready to be deployed it is released formally
in the appropriate market.
• Sometimes product deployment happens in stages as per the business
strategy of that organization.
• The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).
• Then based on the feedback, the product may be released as it is or with
suggested enhancements in the targeting market segment.
• After the product is released in the market, its maintenance is done for the
existing customer base.

13. ESSENTIAL

14. Requirements Analysis
• Requirements analysis, also called
requirements engineering, is the process of
determining user expectations for a new or
modified product.
• These features, called requirements, must be
quantifiable, relevant and detailed.
• In software engineering, such requirements are
often called functional specifications.

15. Functional Requirement
• A function is described as a set of inputs, the behaviour, and outputs.
Functional requirements may be calculations, technical details, data
manipulation and processing and other specific functionality that define
what a system is supposed to accomplish.
• In systems engineering and requirements engineering, a non-functional
requirement (NFR) is a requirement that specifies criteria that can be
used to judge the operation of a system, rather than specific behaviours.
• They are contrasted with functional requirements that define specific
behaviour or functions.

16. Software
Requirements

17. Software Requirements
• Requirements are descriptions of the services that a software
system must provide and the constraints under which it must
operate.
• These requirements reflect the needs of customers for a system .
• The process of finding out, analysing, documenting and
checking these services and constraints is called requirements
engineering (RE).
• In some cases, a requirement is simply a high-level, abstract
statement of a service that a system should provide or a
constraint on a system. At the other extreme, it is a detailed,
formal definition of a system function.

18. Types of Requirement
• User requirements :-
1. User requirements are statements, in a natural language plus
diagrams, of what services the system is expected to provide
to system users and the constraints under which it must
operate.
2. The readers of the user requirements are not usually
concerned with how the system will be implemented and may
be managers who are not interested in the detailed facilities
of the system.

19. Types of Requirement
• System Requirement Specification :-
• The user should be provided with facilities to define the type of
external files.
• Each external file may have an associated tool which may be
applied to the file and is represented as a specific icon on the user’s
display.
• Facilities should be provided for the icon representing an external
file to be define by the user.
• When the user selects an icon representing an external file, the
effect of that selection is to apply the tool associated with the type
of external file to the file represented by the selected icon.

20. Functional and Non functional
requirements
• Software system requirements are often classified as
1. functional requirements and
2. non functional Requirements
3. Functional requirements :
• These are statements of services the system should provide, how
the system should react to particular inputs, and how the system
should behave in particular situations.
• In some cases, the functional requirements may also explicitly
state what the system should not do.

21. Functional requirements :-
• The functional requirements for a system describe what the
system should do.
• These requirements depend on the type of software being
developed, the expected users of the software, and the
general approach taken by the organization when writing
requirements.
• Functional system requirements describe the system
functions, its inputs and outputs, exceptions.
• These functional user requirements define specific facilities
to be provided by the system.

22. Functional and Non functional
requirements
2. Non-functional requirements :
• These are constraints on the services or functions offered by
the system.
• They include timing constraints, constraints on the
development process, and constraints imposed by standards.
• Non-functional requirements often apply to the system as a
whole, rather than individual system features or services.

23. Example of functional requirements
A) DESCRIPTIONS OF
DATA TO BE ENTERED
INTO THE SYSTEM.
B) DESCRIPTIONS OF
OPERATIONS
PERFORMED BY EACH
SCREEN.
WHO CAN ENTER THE
DATA INTO THE SYSTEM
DESCRIPTIONS OF
SYSTEM REPORTS OR
OTHER OUTPUTS
IN PRINCIPLE, THE
FUNCTIONAL
REQUIREMENTS
SPECIFICATION OF A
SYSTEM SHOULD BE
BOTH COMPLETE AND
CONSISTENT.
COMPLETENESS
MEANS THAT ALL
SERVICES REQUIRED
BY THE USER SHOULD
BE DEFINED.
CONSISTENCY MEANS
THAT REQUIREMENTS
SHOULD NOT HAVE
CONTRADICTORY
DEFINITIONS.

24. Non-Functional requirements
• Non-functional requirements, as the name suggests, are
requirements that are not directly concerned with the specific
services delivered by the system to its users.
• They may relate to system properties such as reliability,
response time, and store occupancy.
• Non-functional requirements, such as performance, security,
or availability, usually specify characteristics of the system
as a whole.
• Non-functional requirements are often more critical than
individual functional requirements.

25. Example of Non-Functional
requirements
• For example, if an aircraft system does not meet its reliability
requirements ,it will not be certified as safe for operation; if
an embedded control system fails to meet its performance
requirements, the control functions will not operate correctly.
• Non-functional requirements arise through user needs,
because of budget constraints, organizational policies, the
need for interoperability with other software or hardware
systems, or external factors such as safety regulations or
privacy legislation.

26. Software Requirements Document
• The software requirements document (sometimes called the
software requirements specification or SRS) is an official
statement of what the system developers should implement.
• It should include both the user requirements for a system and a
detailed specification of the system requirements.
• Requirements documents are essential when an outside contractor
is developing the software system.
• The requirements document has a diverse set of users, ranging
from the senior management of the organization that is paying for
the system to the engineers responsible for developing the
software.

28. The standard structure of SRS
specified by IEEE is layout as under:
1. Introduction
1.1 Purpose
1.2 Definition
1.3 System overview
1.4 References
2. Overall description
2.1 Product perspective
2.1.1 System Interfaces
2.1.2 User Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Operations

29. 2.2 Product functions
2.3 User characteristics
2.4 Constraints,assumptions and dependencies
3 Specific requirements
3.1 External interface requirements
3.2 Functional requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Logical database requirement
3.6 Software System attributes
4 Other requirements
5 Appendices
6 Index

30. Software
Processes
A software process is a
structured set of activities
required to develop a
software system.

31. Software Processes
The four types of fundamental activities
• Software specification – defining what the system should
do;
• Software design and implementation – defining the
organization of the system and implementing the system.
• Software validation – checking that it does what the
customer wants
• Software evolution – changing the system in response to
changing customer needs.

32. Software Process Models
A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.
Generic software process models are:
1. The Waterfall Model: This model has separate and distinct
phases of specification and development .
2. Evolutionary Development : The specification and
development are interleaved and an initial system is n abstract
specification.
3. Reuse-based Development or Component-Based software
engineering : The system is assembled from existing
components.

33. Software Process Models
• Waterfall model – This takes the fundamental process activities of specification,
development, validation and evolution and represents them as separate process
phases such as requirement specification, software design, implementation, testing
and so on
• Evolutionary development – This approach interleaves the activities of specification,
development and validation. An initial system is rapidly developed from abstract
specifications then refined with customer input to produce a system that specifies the
customers needs
• Component based software engineering – This approach is based on the existence of
a significant number of reusable components. The system development process
focuses on integrating these components into a system rather than developing them
from scratch also called as Reuse-based Development.

34. Waterfall Model
• It is the first published model of the software development process
• Because of the cascade from one phase to another this model is known as
waterfall model or software life cycle

35. The principal stages of Waterfall model
• Requirement analysis and definition – The system’s services, constraints and
goals are established by consultation with the system users. They are then
defined in detail and serve as a system specification
• System and software design – The system design process partitions the
requirements to either software or hardware systems. It establishes an overall
system architecture. Software design involves identifying and describing the
fundamental software system abstractions and their relationships
• Implementation and unit testing – During this stage the software design is
realised as a set of programs or program units. Unit testing involves verifying
that each unit meets its specification
• Integration and system testing – The program units are integrated and tested as
a complete system to ensure that the software requirements have been met.
After testing the software is delivered to the customer
• Operation and maintenance – This is the longest life cycle phase in which the
system is installed and put to use. This stage also involves correcting errors
which are not discovered in earlier stages of life cycle, improving and enhancing
the system services

36. Evolutionary Model or Prototype
Model
• This approach is based on the idea of rapidly developing an initial
software implementation from very abstract specifications and
modifying this according to your appraisal.
• Each program version Inherits the best features from earlier versions.
Each version is refined based upon feedback from yourself to
produce a system which satisfies your needs.
• At this point the system may be delivered or it may be re-
implemented using a more structured approach to enhance
robustness and maintainability, Specification development and
validation activities are concurrent with strong feedback between
each.

37. Evolutionary Model or Prototype Model

38. Evolutionary Model or Prototype
Model
There are two fundamental types of evolutionary development
• Exploratory development where the objective of the process is to work with
the customer to explore their requirements and deliver a final system. The
system evolves by adding new features proposed by the customer
• Throwaway prototyping where the objective of the evolutionary
development process is to understand the customers requirement and hence
develop a better requirements definition for the system. The prototype
concentrates on experimenting with the customer requirements that are
poorly understood

39. Evolutionary Model or Prototype Model
Advantages
• Exact destination of customer
requirements can be known.
• It is also reducing the
maintenance tasks duration
because before delivery of a
module, the customers are
consulted.
• As the individual module takes
place, so final product will
contain limited number of
errors.
Disadvantages
• It is only helpful for large s/w
products because we can find
individual modules for
incremental implementation.
• It is also used when the
customer is ready to receive
the product.

40. Component-based Software-
Engineering
It is based on systematic reuse where systems are integrated from
existing Component or COTS (Commercial-off-the-shelf) systems.
The various process stages are:
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration

41. Software
Process Model
Process Iteration
Incremental
Delivery
Spiral
Development

42. Process Iteration
• System requirements change as the business
procuring the system responds to management
changes
• As new technologies become available designs &
implementations change and hence the process
activities are repeated regularly.

43. Process
Iteration
• Two process models have been explicitly
designed to support iteration process
• Incremental delivery – The software
specification, design and implementation are
broken down into series of increments that
are each developed in turn
• Spiral development – The development of
the system spirals outwards from an initial
outline through to the final developed
system
• The essence of the iterative process is that the
specification is developed in conjunction with
the software
• In incremental approach there is no complete
system specification until the final increment is
specified.

44. Incremental
Delivery
• Waterfall model of development requires customers
for a system to commit to a set of requirements
before design begins and the designer to commit to
particular design strategies before implementation
• An evolutionary approach to development allows
requirements and design decisions to be delayed
but also leads to software that may be poorly
structured and difficult to understand and maintain
• Incremental delivery is an in-between approach that
combines the advantages of these models

45. Incremental
Delivery
• In an incremental development process
customer identify the services to be provided by
the system also called as increments
• Once these increments are defined each one of
these are prepared sequentially
• Once an increment is completed and delivered
customers can put it into service thereby using it
helping them to clarify their doubts
• As the new increments are completed they are
integrated with existing increments so that
system functionality improves with each
delivered increment

47. Incremental
Delivery
• This incremental development process has number of
advantages
• Customers do not have to wait until the entire system is
delivered before they can gain value from it. The first
increment satisfies their most critical requirements so they
can use the software immediately
• Customers can use early increment as prototypes and gain
experience that informs their requirements for later
system increments
• There is a lower risk of overall project failure. Although
problems may be encountered in some increments it is
likely that some will be successfully delivered to the
customers
• As the highest priority services are delivered first and later
increments are integrated with them it is inevitable that
most important system services receive the most testing.
This means that customers are less likely to encounter
software failures in the most important part of the system

48. Incremental
Delivery
• Incremental development process has
following disadvantages
• Increments should be relatively small
and each increment should deliver
some system functionality
• It may be difficult to map the
customers requirements onto
increments of right size
• As the requirements are not defined
in detail until an increment is to be
implemented it is hard to identify
common facilities that are needed by
all increments

49. Incremental Delivery Example

50. Spiral Development
• It represents a software process as a spiral loop
• Each loop in spiral represents a phase of the software process.
Thus, innermost loop might be concerned with system feasibility,
the next loop with requirements definition and so on
• Each loop in the spiral is split into four sectors
• Objective Setting – Specific objectives for that phase of the
project are defined. Constraints on the process and the product
are identified and a detailed management plan is drawn. Project
risks are identified. Alternative strategies depending on these
risks may be planned.

51. Spiral Development
• Risk Assessment and reduction – For each identified project risks a
detailed analysis is carried out. Steps are taken to reduce the risks
• Development and Validation – After risk evaluation a development
model for the system is chosen.
• Planning – The project is reviewed, and a decision is made whether
to continue with a further loop of the spiral

52. Spiral Development Contd.

53. W Model

54. RAD &
Time Boxing
RAD Model:
It is a team based technique that speeds up information
system development and produces a functioning
information system.
Timeboxing Model :
In Timeboxing model, development is done iteratively as
in the iterative enhancement model.

55. RAD
• Rapid application development is a software development
methodology that uses minimal planning in favour of rapid
prototyping. A prototype is a working model that is functionally
equivalent to a component of the product.
• In the RAD model, the functional modules are developed in parallel as
prototypes and are integrated to make the complete product for faster
product delivery. Since there is no detailed preplanning, it makes it
easier to incorporate the changes within the development process.
• RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer
representatives and other IT resources working progressively on their
component or prototype.
• The most important aspect for this model to be successful is to make
sure that the prototypes developed are reusable.

56. RAD Model Design
RAD model distributes the analysis, design, build and test phases into a
series of short, iterative development cycles.
Following are the various phases of the RAD Model −
• Business Modelling
The business model for the product under development is designed in
terms of flow of information and the distribution of information between
various business channels.
A complete business analysis is performed to find the vital information for
business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.

57. RAD Model Design
•Data Modelling
• The information gathered in the Business Modelling phase is reviewed and
analysed to form sets of data objects vital for the business.
• The attributes of all data sets is identified and defined.
• The relation between these data objects are established and defined in
detail in relevance to the business model.
•Process Modelling
• The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model.
• The process model for any changes or enhancements to the data object sets
is defined in this phase.
• Process descriptions for adding, deleting, retrieving or modifying a data
object are given.

58. RAD Model Design
• Application Generation
The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.
• Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration.
However, the data flow and the interfaces between all the components need to
be thoroughly tested with complete test coverage.
Since most of the programming components have already been tested, it
reduces the risk of any major issues.

60. Time Boxing Model
• In time boxing model, development is done iteratively as in the iterative
enhancement model.
• However, in time boxing model, each iteration is done in a timebox of
fixed duration.
• The functionality to be developed is adjusted to fit the duration of the
timebox.
• Moreover, each timebox is divided into a sequence of fixed stages where
each stage performs a clearly defined task (analysis, implementation,
and deploy) that can be done independently.
• This model also requires that the time duration of each stage is
approximately equal so that pipelining concept is employed to have the
reduction in development time and product releases.

61. Time Boxing Model
• There is a dedicated team for each stage so that the work can
be done in pipelining. Thus, stages should be chosen in such a
way that each stage perform some logical unit of work that
becomes the input for next stage.
• In addition to the advantages of iterative model, time boxing
model has some other advantages too. Various advantages and
disadvantages associated with timeboxing model are listed in
Table.

62. Time Boxing Model
• Advantages
1. Speeds up the development process and shortens the delivery
time
2. Well suited to develop projects with a number of features in
short time period
• Disadvantages
1. Project management becomes more complex.
2. Not suited to projects in which entire development work cannot
be divided into multiple iterations of almost, equal duration

63. Time Boxing Model

64. Agile Model

65. What is
Agile?
The word ‘agile’ means −
• Able to move your body quickly and
easily.
• Able to think quickly and clearly.
• In business, ‘agile’ is used for describing
ways of planning and doing work wherein
it is understood that making changes as
needed is an important part of the job.
• Business‘agililty’ means that a company is
always in a position to take account of the
market changes.

66. Agile software
development:
• Agile is a software development
methodology to build a software
incrementally using short iterations of 1
to 4 weeks so that the development
process is aligned with the changing
business needs.
• Instead of a single-pass development of
6 to 18 months where all the
requirements and risks are predicted
upfront, Agile adopts a process of
frequent feedback where a workable
product is delivered after 1 to 4 week
iteration.

68. Roles in
Agile
• Scrum Master
• A Scrum Master is a team leader and
facilitator who helps the team members to
follow agile practices so that they can meet
their commitments. The responsibilities of a
scrum master are as follows −
• To enable close co-operation between all
roles and functions.
• To remove any blocks.
• To shield the team from any disturbances.
• To work with the organization to track the
progress and processes of the company.

69. Roles in Agile
Scrum Master
To ensure that Agile Inspect & Adapt processes are
leveraged properly which includes
• Daily stand-ups,
• Planned meetings,
• Demo,
• Review,
• Retrospective Meetings, and
• To facilitate team meetings and decision-making process.

70. Product Owner
A Product Owner is the one who drives the product from business
perspective.
The responsibilities of a Product Owner are as follows −
• To define the requirements and prioritize their values.
• To determine the release date and contents.
• To take an active role in iteration planning and release planning
meetings.
• To ensure that team is working on the most valued requirement.
• To represent the voice of the customer.
• To accept the user stories that meet the definition of done and defined
acceptance criteria.

71. Cross-
functional
Team
• Every agile team should be a self-sufficient
team with 5 to 9 team members and an
average experience ranging from of 6 to 10
years.
• Typically, an agile team comprises of 3 to 4
developers, 1 tester, 1 technical lead, 1
product owner and 1 scrum master
• Product Owner and Scrum master are
considered to be a part of Team Interface,
whereas other members are part of
Technical Interface.

72. •Cross-functional Team

73. Plan-driven and agile development
• Plan Driven and Agile Development — Both are
development processes
• Plan Driven:-
The development process in which all the activities to be
done in the process is planned initially or in advance, this
development process is called Plan Driven Process.
• In this way, we can measure the progress of the process
against this plan.
” Plan Driven development only works in situation where
product managers and business stakeholders know exactly
what they want, will not change their minds, are clear on
priorities and are sure that the business process does not
change.”

75. Plan-driven
• Water-Fall Model is Plan-Driven model.

76. Agile Development
” The agile methodology is a much a philosophical shift as it is a
process shift.”
• The development process in which planning of activities is incremental
and it’s easier to change the processes due to the changing of activities
or adding or removing the activities, is called Agile development
process.
• As activities can be changed, so the progress of development process is
not measured exactly.

77. Agile Development
• In software development processes, it is very reliable as mostly customers don’t know what
they want and it is very difficult to gather all the requirements in the beginning of
development process.
• Hence, Agile development approach is iterative approach. If there is risk of changing
requirements then we mostly use Agile development approach.
• Incremental model is mostly Agile model, But it becomes Plan-Driven model when
requirements remain unchanged.
• Iterative model is the example of Agile development process.

78. Agile Development

80. Agile Project
Management

81. Agile project management
• Agile Project Management is one of the revolutionary methods
introduced for the practice of project management.
• This is one of the latest project management strategies that is mainly
applied to project management practice in software development
• Therefore, it is best to relate agile project management to the software
development process when understanding it.

82. Scope of Agile Project Management
In an agile project, the entire team is responsible in managing the
team and it is not just the project manager's responsibility. When it
comes to processes and procedures, the common sense is used over
the written policies.
This makes sure that there is no delay is management decision making
and therefore things can progress faster.
In addition to being a manager, the agile project management
function should also demonstrate the leadership and skills in
motivating others. This helps retaining the spirit among the team
members and gets the team to follow discipline.
Agile project manager is not the 'boss' of the software development
team. Rather, this function facilitates and coordinates the activities
and resources required for quality and speedy software development.

83. Responsibilities of an Agile Project Manager
• The responsibilities of an agile project management function are given
below. From one project to another, these responsibilities can slightly
change and are interpreted differently.
• Responsible for maintaining the agile values and practices in the
project team.
• The agile project manager removes impediments as the core function
of the role.
• Helps the project team members to turn the requirements backlog into
working software functionality.

84. Responsibilities of an Agile Project Manager
• Facilitates and encourages effective and open communication within the
team.
• Responsible for holding agile meetings that discusses the short-term plans
and plans to overcome obstacles.
• Enhances the tool and practices used in the development process.
• Agile project manager is the chief motivator of the team and plays the
mentor role for the team members as well.

85. What is Extreme Programming?
• XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and
fun way to develop a software.
• Extreme Programming (XP) was conceived and developed to address the
specific needs of software development by small teams in the face of
ambiguous and changing requirements.
• Extreme Programming is one of the Agile software development
methodologies. It provides values and principles to guide the team
behaviour. The team is expected to self-organize. Extreme Programming
provides specific core practices where each practice is simple and self-
complete.
• Combination of practices produces more complex and emergent behaviour.

86. Extreme Programming

87. XP values
Extreme Programming initially recognized
values are:
Communication
Simplicity
Feedback
Courage
Respect

88. Extreme Programming Advantages
Extreme Programming solves the following problems often faced in the
software development projects −
• Slipped schedules − and achievable development cycles ensure timely
deliveries.
• Cancelled projects − Focus on continuous customer involvement ensures
transparency with the customer and immediate resolution of any issues.
• Costs incurred in changes − Extensive and ongoing testing makes sure the
changes do not break the existing functionality. A running working system
always ensures sufficient time for accommodating changes such that the
current operations are not affected.

89. Extreme Programming Advantages
• Production and post-delivery defects: Emphasis is on − the unit tests
to detect and fix the defects early.
• Misunderstanding the business and/or domain − Making the customer
a part of the team ensures constant communication and clarifications.
• Business changes − Changes are considered to be expected and are
accommodated at any point of time.
• Staff turnover − Intensive team collaboration ensures enthusiasm and
good will. Unity of multi-disciplines raises the team spirit.

90. Extreme
Programming
Process Cycle
• Extreme Programming is iterative and
incremental and is driven by Time-Boxed
Cycles. Therefore, the rhythm of the
Extreme Programming process is crucial.
• Extreme Programming has the following
activity levels −
• Product Life Cycles
• Releases
• Iterations
• Tasks
• Development
• Feedback

91. • Each of the activity levels provides the minimal inputs required for
the next level. They are −
• Product life cycle activities provide inputs for release cycles.
• Release planning sessions provide inputs for iteration cycles.
• Iteration planning sessions provide inputs for task cycles.
• Task development provides inputs for development episodes.
• Development produces the product.
• Feedback is a continuous activity throughout the project and across
all the above activity levels.