CCS356- ODJECT ORIENTED SOFTWARE ENGINEERING

UNIT-I

SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering

Software definition:
Definition1: Software is instructions (computer programs) that are intended to provide
desired Features, function, and performance;
Definition2: Software is a data structure that enables the programs to adequately manipulate information.

Characteristics of software are

1. Software is developed or engineered; it is not manufactured in the classical sense.
In both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems that are nonexistent for
software
2. Software doesn’t “wear out.”
The failure rate curve for software should take the form of the “idealized curve”
shown in Figure. Undiscovered defects will cause high failure rates early in the life of a
program. However, these are corrected and the curve flattens as shown. The idealized curve
is a gross oversimplification of actual failure models for software. However, the implication
is clear—software doesn’t wear out.
 3. Although the industry is moving toward component-based construction, most software
continues to be custom built.

Software Application Domains

Seven broad categories of computer software

1) System software—a collection of programs written to service other programs. Some
system software are compilers, editors, and assembler. The purpose of the sysem
software is to establisha communication with the hardware.
2) Applicationsoftware—stand-aloneprogramsthatsolveaspecificbusinessneed.

3) Engineering/scientificsoftware—hasbeencharacterizedby“numbercrunching”algorithms.

4) Embedded software—resides within a product or system and is used to implement and

control features and functions for the end user and for the system itself.
5) Product-linesoftware—designedtoprovideaspecificcapabilityforusebymanydifferent
customers.
6) Webapplications—called“WebApps,”thisnetwork-centricsoftwarecategoryspansawide
array of applications.
7) Artificialintelligencesoftware—makesuseofnonnumericalalgorithmstosolvecomplex
problems that are not amenable to computation or straightforward analysis

Legacy software systems:

Legacy software systems were developed decades ago and have been continually modified to
meet changes in business requirements and computing platforms.
A few simple realities to build software that is ready to meet the challenges of the twenty-first
century are:
1. Aconcertedeffortshouldbemadetounderstandtheproblembeforeasoftwaresolutionis developed.

2. Design becomes a pivotal activity

3. Software should exhibit high quality

4. Software should be maintainable

Softwareinallofitsformsandacrossallofitsapplicationdomainsshouldbe engineered.
Software engineering:
A definition proposed by Fritz Bauer is
 [Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.
The IEEE definition is:
Software Engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the application
of engineering to software. .
Software engineering is a layered technology.

1) Quality focus

A disciplined quality management is a backbone of software engineering technology.

2) Process layer:

The foundation for software engineering is the process layer. Process defines a
framework that must be established for effective delivery of software engineering technology.
3) Methods:

Software engineering methods provide the technical how-to’s for building software. Methods
encompass a broad array of tasks that include communication, requirements analysis, design
modeling, program construction, testing, and support.
4) Tools:

Software engineering tools provide automated or semi automated support for the process and the
methods. When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering, is established.
 SOFTWAREPROCESS:

 A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created.
 An activity strives to achieve a broad objective (e.g., communication with stakeholders)
and is applied regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural design model).

 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
 In the context of software engineering, a process is not a rigid prescription for how to
build computer software. Rather, it is an adaptable approach that enables the people doing
the work(the software team) to pick and choose the appropriate set of work actions and
tasks. The intent is always to deliver software in a timely manner and with sufficient
quality to satisfy those who have sponsored its creation and those who will use it.

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,
regardless of their size or complexity.
A generic process framework for software engineering encompasses five activities:
1) Communication:

Before any technical work can commence, it is critically important to communicate and
collaborate with the customer. The intent is to understand stakeholders’ objectives for the project
and to gather requirements that help define software features and functions.
2) 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.
3) Modeling:

Software engineers will create models to better understand software requirements and the design
 that will achieve those requirements.
4) Construction:

This activity combines code generation and the testing that is required uncovering errors in the code.
5) Deployment:

The software is delivered to the customer who evaluates the delivered product and provides
feedback based on the evaluation.
These five generic framework activities can be used during the development of small, simple
programs, the creation of large Web applications, and for the engineering of large, complex
computer-based systems

Umbrella activities:
Umbrella activities are applied throughout a software project and help a software team manage
and control progress, quality, change, and risk.
Typical umbrella activities include:
1) Software project tracking and control—allows the software team to assess progress against
the project plan and take any necessary action to maintain the schedule.
2) Risk management—assesses risks that may affect the outcome of the projector the quality of
the product.
3) Softwarequalityassurance—definesandconductstheactivitiesrequiredtoensuresoftware
quality.
4) A technical review—assesses software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
5) Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs.
6) Software configuration management—manages the effects of change throughout the
software process.
 Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.

Work product preparation and production—encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.
 PRESCRIPTIVE PROCESS MODELS (OR) LIFE CYCLE MODELS:

The process model can be defined as the abstract representation of process. The appropriate process
model can be chosen based on abstract representation of process. These process models will follow some rules
for correct usage.
It is called “prescriptive” model because they prescribe a set of process elements—framework activities,
software engineering actions, tasks, work products, quality assurance, and change control mechanisms for
each project. Each process model also prescribes a process flow (also called a work flow)—that is the manner
in which the process elements are interrelated to one another.

The Waterfall Model:

 The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential
approach to software development that begins with customer specification of requirements and
progresses through planning, modeling, construction, and deployment, culminating in ongoing
support of the completed software.
 The waterfall model is the oldest paradigm for software engineering.

 Inrequirementgatheringandanalysisphasethebasicrequirementsofthesystemmustbe understood by
software engineer, who is called analyst.
 Thedesignisanintermediatestepbetweenrequirementsanalysisandcoding.
Design focuses on:
1) Data Structure
2) Software architecture
3) Interface representation
4) Algorithm details
 Coding is a step in which design is translated into machine readable form.

 Testing begins when coding is done. The purpose of testing is to uncover errors, fix the bugs and
meet the customer requirements.
 Maintenance is the longest life cycle phase. The purpose of maintenance is when the system is
installed and put in practical use then error may get introduced, correcting such errors and putting
it in use.
Advantages:
1) The waterfall model is simple to implement
2) For implementation of small systems it is use full.
Problems in waterfall model:
1. Real projects rarely follow the sequential flow that the model proposes. Changes can cause
confusion as the project team proceeds.
2. It is difficult for the customer to state all requirements explicitly. The waterfall model requires
this and has difficulty accommodating the natural uncertainty that exists at the beginning of manyprojects.
3. The customer must have patience. A working version of the program(s) 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.

 V-Model: In each phase, testing will be done.

A variation in the representation of the water fall model is called the V-model.
 The V-model depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities. As a software team moves down the
left side of the V, basic problem requirements are refined into progressively more detailed and
technical representations of the problem and its solution.
 Once code has been generated, the team moves up the right side of the V, essentially performing a
series of tests (quality assurance actions) that validate each of the models created as the team
moved down the left side.
 In reality, there is no fundamental difference between the classic life cycle and the V-model. The
V-model provides a way of visualizing how verification and validation actions are applied to
earlier engineering work.
Incremental Process Models
 The incremental model combines elements of linear and parallel process flows.

 The incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.
 The incremental model combines elements of linear and parallel process flows. The incremental
model applies linear sequences in a staggered fashion as calendar time progresses.
 Eachlinearsequenceproducesdeliverable“increments”ofthesoftwareinamannerthatis similar to the
increments produced by an evolutionary process flow.
When we can choose incremental:
1) When initials of software requirements are reasonably well defined
2) When the overall scope of the development effort precludes purely linear process.
3) When limited set of software functionality needed quickly.
  The incremental model applies linear sequences in a staggered fashion as calendar time
progresses.
 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 checkinginthethirdincrement;andadvancedpagelayoutcapabilityinthe fourth
increment. It should be noted that the process flow for any increment can incorporate the
prototyping paradigm.
 The first increment is often a core product. That is, basic requirements are addressed but many
supplementary features remain undelivered.
 The core product is used by the customer. As a result of use, a plan is developed for the next
increment. The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality. This process is repeated
following the delivery of each increment, until the complete product is produced.
 Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early
increments can be implemented with fewer people.
 If the core product is well received, then additional staff (if required) can be added to implement
the next increment. In addition, increments can be planned to manage technical risks.
Advantages:
1) Generatesworkingsoftwarequicklyandearlyduringthesoftwarelifecycle.

2) This model is more flexible–less costly to changes cope and requirements.

3) It is easier to test and debug during a small reiteration

4) In this model customer can respond to each built.

5) Lowers initial delivery cost.

6) Easier to manage risk because risky pieces are identified and handled during it’s iteration.

Disadvantages:
1) Needs good planning and design.

2) Needs a clear and complete definition of the whole system before it can be broken down and
built incrementally.
3) Total cost is higher than waterfall.
4)
 Evolutionary Process Models:
 Business and product requirements often change as development proceeds, making a straight line
path to an end product unrealistic; In such case, the iterative approach needs to be adopted. Evolutionary
process model is also called as iterative process model
 Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
Prototyping
 Software prototyping, refers to the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. It is an activity that can occur in software
development and is comparable to prototyping as known from other fields, such as mechanical
engineering or manufacturing.
 When we can choose Prototype:

o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o Thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofan operating
system
o When requirements are fuzzy.

o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o Thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofan operating
system
o When requirements are fuzzy
 o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o Thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofan operating
system
o When requirements are fuzzy
 The prototyping assists you and other stakeholders to better understand what is to be built when
requirements are fuzzy.
 The prototyping paradigm begins with communication. You meet with other stakeholders to
define the overall objectives for the software, identify whatever requirements are known, and outline
areas where further definition is mandatory.
 A prototyping iteration is planned quickly, and modeling (in the form of a “quick design” )occurs.
A quick design focuses on a representation of those aspects of the software that will be visible to end
users (e.g., human interface layout or output display formats).
 Thequickdesignleadstotheconstructionofaprototype.Theprototypeisdeployedandevaluated by
stakeholders, who provide feedback that is used to further refine requirements.

 Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at
the same time enabling you to better understand what needs to be done
 Ideally, the prototype serves as a mechanism for identifying software requirements. If a working
prototype is to be built, you can make use of existing program fragments or apply tools (e.g., report
generators and window managers) that enable working programs to be generated quickly.
 In most projects, the first system built is barely usable. It may be too slow, too big, akward in use
or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version
in which these problems are solved.
 The prototype can serve as “the first system.” The one that Brooks recommends you throw away.
But this may be an idealized view. Although some prototypes are built as “throwaways,” others are
evolutionary in the sense that the prototype slowly evolves into the actual system.
 Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the
actual system, and developers get to build something immediately.
Advantages:
1) Users are actively involved in the development

2) Sinceinthismethodologyaworkingmodelofthesystemisprovided,theusersgetabetter understanding
of the system being developed.
3) Errors can be detected much earlier.

4) Quicker user feedback is available leading to better solutions.

5) Missing functionality can be identified easily

 6) Confusing or difficult functions can be identified Requirements validation, Quick implementation
of, incomplete, but functional, application.

Disadvantages:
1) Stakeholders see what appears to be a working version of the software, unaware that the
prototype is held together has hazard, unaware that in the rush to get it working you haven’t
considered overall software quality or long-term maintainability.
2) Software engineer make implementation compromises in order to get a prototype working
quickly.
3) An inappropriate operating system or programming language may be used simply because it is
available and known; an inefficient algorithm may be implemented simply to demonstrate
capability.
Usage of prototyping:
 Although problems can occur, prototyping can be an effective paradigm for software
Engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders should
agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at
least in part), and the actual software is engineered with an eye toward quality.

The Spiral Model.

 The spiral model is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the water fall model. It provides the potential
for rapid development of increasingly more complete versions of the software.
 The spiral development model is a risk-driven process model generator that is used to guide
multi-stakeholder concurrent engineering of software intensive systems.
It has two main distinguishing features.
(1) One is a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.

(2) The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
  A spiral model is divided into a set of framework activities defined by the software engineering
team. Each of the framework activities represents one segment of the spiral path.
 The spiral model is a realistic approach to the development of large-scale systems and
software. Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.
 The spiral model uses prototyping as a risk reduction mechanism but enables you to apply the
prototyping approach at any stage in the evolution of the product. It maintains the systematic
stepwise approach suggested by the classic life cycle but incorporates it into an iterative
framework that more realistically reflects the real world.
 The spiral model demands a direct consideration of technical risks at all stages of the project and,
if properly applied, should reduce risks before they become problematic.

The functions of these four quadrants are discussed below-

 Objectives determination and identify alternative solutions (Concept development

projects): Requirements are gathered from the customers and the objectives are identified,
elaboratedandanalyzedatthestartofeveryphase.Thenalternativesolutionspossibleforthe phase
are proposed in this quadrant.
  Identify and resolve Risks (New product development projects): During this cond quadrant
all the possible solutions are evaluated to select the best possible solution. Then the risks
associated with that solution is identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, Prototype is built for the best possible solution.
 Develop next version of the Product (Product Enhancement projects): During the third
quadrant, the identified features are developed and verified through testing. At the end of the
third quadrant, the next version of the software is available.
 Review and plan for the next Phase (product Maintenance projects):In the fourth quadrant,
theCustomersevaluatethesofardevelopedversionofthesoftware.Intheend,planningforthe next
phase is started.
Advantages:
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added a talaterdate.
 Software is produced early in the software lifecycle.
Disadvantages:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.
 Concurrent development Models
 The concurrent development model, sometimes called concurrent engineering, allows a software
team to represent iterative and concurrent elements of any of the process models.
 For example, the modeling activity defined for the spiral model is accomplished by invoking one
or more of the following software engineering actions: prototyping, analysis, and design.
 Figure provides a schematic representation of one software engineering activity within the
modeling activity using a concurrent modeling approach. The activity—modeling—may be in any one of
the states noted at any given time.
 Similarly, other activities, actions, or tasks (e.g., communication or construction) can be
represented in an analogous manner. All software engineering activities exist concurrently but reside in
different states.
 For example, early in a project the communication activity has completed its first iteration and
exists in the awaiting changes state. The modeling activity (which existed in the inactive state while
initial communication was completed, now makes a transition into the under development state.
 If the customer indicates that changes in requirements must be made, the modeling activity moves
from the under development state into the awaiting changes state.
 Concurrent modeling defines a series of events that will trigger transitions from state to state for
each of the software engineering activities, actions, or tasks.
 For example, during early stages of design (a major software engineering action that occurs
during the modeling activity), an inconsistency in the requirements model is uncovered. This
generates the event analysis model correction, which will trigger the requirements analysis action
from the done state into the awaiting changes state.
 Concurrent modeling is applicable to all types of software development and 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 in the process network trigger transitions among the states.
Advantages:
1) The concurrent development model, sometimes called concurrent engineering. It’s can be
represented schematically as a series of frame work activities, software engineering actions,
software engineering task and their associated states.
2) The concurrent process model defines a series of events that will trigger transition from state to
state for each of the software engineering activities and action or task.
3) The concurrent process model is applicable to all types of software development and provides an
accurate picture of the current state of a project.
 Disadvantages:
1) The SRS must be continually updated to reflect changes.
2) It requires discipline to avoid adding too many new features too late in the project.

SPECIALIZED PROCESS MODELS

 Specialized process models take on many of the characteristics of one or more of the traditional
models. However, these models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen.
Component-Based Development
 Commercial off-the-shelf (COTS) software components, developed by vendors who offer the mas
products, provide targeted functionality with well-defined interfaces that enable the component to be
integrated into the software that is to be built.
 The component-based development model incorporates many of the characteristics of the spiral
model. It is evolutionary in nature, demanding an iterative approach to the creation of software.
  However, the component-based development model constructs applications from prepackaged
software components.
 Modeling and construction activities begin with the identification of candidate components.
These components can be designed as either conventional software modules or object-oriented classes or
packages16 of classes.
 Regardless of the technology that is used to create the components, the component-based
development model incorporates the following steps (implemented using an evolutionary approach):
1) Available component-based products are researched and evaluated for the application domain in
question.
2) Component integration issues are considered.
3) Software architecture is designed to accommodate the components.

4) Components are integrated into the architecture.

5) Comprehensive testing is conducted to ensure proper functionality.
 The component-based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits. Your software engineering team can achieve a
reduction in development cycle time as well as a reduction in project cost if component reuse becomes
part of your culture.
Advantages:
 The component based development model leads to software re-used and re-usability provides a
number of tangible benefits.
 It leads to reduction in development cycle time.
 It leads to significant reduction in project cost.
 It leads to significant increase in productivity.
Disadvantages:
1) Customization
2) Problem to adapt a component
3) The integration of are usable component tint new component is also a major problem
4) Security is another major concern for the developers
5) Efficiency of the Software applications developed using CBD is also debatable.

The Formal Methods Model

 The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical notation. A variation on this approach,
called clean room software engineering is currently applied by some software development organizations.
 When formal methods are used during development, they provide a mechanism for eliminating
many of the problems that are difficult to overcome using other software engineering paradigms.
 Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily—not
through ad hoc review, but through the application of mathematical analysis. When formal methods are
used during design, they serve as a basis for program verification and therefore enable you to discover
and correct errors that might otherwise go undetected.
Advantage:
 Although not a mainstream approach, the formal methods model offers the promise of defect-free
software.
Disadvantages:
1) Thedevelopmentofformalmodelsiscurrentlyquitetimeconsumingandexpensive.
2) Becausefewsoftwaredevelopershavethenecessarybackgroundtoapplyformalmethods, extensive
training is required.
3) It is difficult to use the models as a communication mechanism for technically un sophisticated
customers.

Aspect-Oriented Software Development

 Regardless of the software process that is chosen, the builders of complex software invariably
implement a set of localized features, functions, and information content. These localized software
characteristics are modeled as components (e.g., object oriented classes) and then constructed within the
context of a system architecture.
 As modern computer-based systems become more sophisticated (and complex), certain concerns
—customer required properties or areas of technical interest—span the entire architecture.

 Some 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).
 When concerns cut across multiple system functions, features, and information, they are often
referred to as crosscutting concerns. Aspectual requirements define those crosscutting concerns that have
an impact across the software architecture.
 Aspect-oriented software development (AOSD), often referred to as aspect-oriented programming
(AOP), is a relatively new software engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects— “mechanisms beyond
subroutines and inheritance for localizing the expression of a crosscutting concern”
 A distinct aspect-oriented process has not yet matured. However, it is likely that such a process
willadoptcharacteristicsofbothevolutionaryandconcurrentprocessmodels.
 Technology in this current era is progressing faster than ever, enforcing the global software
companiestoworkinafast-pacedchangingenvironment.Becausethesebusinessesareoperatinginan ever-
changing environment, it is impossible to gather a complete and exhaustive set of software
requirements. Without these requirements, it becomes practically hard for any conventional software
model to work.
Agilewasspeciallydesignedtomeetstheneedsoftherapidlychangingenvironmentby embracing the
idea of incremental development and develop the actual final product.

Introduction to Agile Process:

 In1980’stheheavy weight, plan based software development approach was used to develop any
software product.

Agile Methodology:
When incremental delivery is coupled with other agile practices such as continuous unit testing and
pair programming then the cost of changes can be controlled.
The following graph represents the how the software development approach has astrong influence on
the development cost due to changes suggested.

 Inthisapproachtoomanythingsaredonewhichwerenotdirectlyrelatedtosoftwareproduct being
produced.
 If requirements get changed, then rework was essential. Hence new methods were proposed in
1990’s which are known as agile process.
 Theagileprocessislight-weightmethodswhicharepeople-basedratherthanplan-based methods.
 The agile process forces the development team to focus on software itself rather than design and
documentation.
 The agile process believes in iterative method.

 The aim of agile process is to deliver the working model of software quickly to the customer.
Conventional software Development Methodology:
 The conventional wisdom in software development is that the cost of change increases nonlinearly
as a project progresses.
 It is relatively easy to accommodate a change when a software team is gathering requirements. A
usage scenario might have to be modified, a list of functions may be extended, or a written
specification can be edited.
  As the progresses and if the customer suggest the changes during the testing phase of the SDLC
then to accommodate these changes the architectural design needs to be modified and ultimately
these changes will affect other phases of SDLC. These changes are actually costly to execute.
Principles:
There are famous 12 principles used as agile principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shortest timescale.
4. Business people and developers must work together throughout the project.
5. Buildprojectsaroundmotivatedindividuals.Givethemtheenvironmentandthesupportthey 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 constant development. The sponsors, developers, and users should be
able to maintain a constant.
9. Continuousattentiontotechnicalexcellenceandgooddesignenhancesagility.
10. Simplicity the art of maximizing the amount of work not done is essential.
11. The team must be self–organizing teams for getting best architectures ,requirements ,and designs
emerge from
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly
Extreme programming:
Extreme programming (XP) is one of the best known agile processes.
XP values:
The set of five values that serve as a basis for all work performed as part of XP—communication,
simplicity, feedback, courage, and respect. Each of these values is used as a driver for specific XP
activities, actions, and tasks.
1. Communication:
To achieve effective communication between software engineers in order to covey
important concepts and to get continuous feedback.

2. Simplicity:
 XP focuses on the current needs instead of future needs to incorporate in the design.
Hence the XP believes that the Software design should be simple.
3. Feedback:
The feedback for the software product can be obtained from the developers of the
software, customers and other software team members.
4. Courage:
The strict adherence to certain XP practices require courage. The agile XP team must be
disciplined to design the system today, recognize the future requirements and make the
changes dramatically as per demand.
5. Respect:
By following the above states XP values the agile team can win the respect of the
stakeholders.
XP Process:
The extreme programming process is explained as follows-

 Customer specifies and priorities the system requirements. Customer becomes or of the
important members of development team. The developer and customer together prepare a story-
card in which customer needs are mentioned.

 The developer team then aims to implement the scenarios in the story-card.

 After developing the story-card the development team breaks down the total work in small
tasks. The efforts and the estimated resources required for these tasks are estimated.

 The customer priorities the stories for implementation. If the requirement changes then
sometimes unimplemented stories have to be discarded. Then release the complete software in
small and frequent releases.

 For accommodating new changes, new story-card must be developed.

 Evaluate the system a long with the customer.
 XP Principle Description

User story-cards Instead of creating a large requirement document user stories are
Written by the customer in which what they need is mentioned.
Release planning A release plan for overall project is
Prepared from which the iteration plan can be prepared for individual
iteration
Small releases The developer breaks down the user
Stories into small releases and a plan for releasing the small
Planning
functionalities is prepared.

Iterative process Divide the development work into small iterations. Keep the iteration
of nearly constant length. Iterative development helps in quick or
agile development.
Standup The stand up meetings must be, conducted for the current out comes of
meetings the project.
Simple design Simple design always takes less time than the complex design. It is always
Good to keep the things simple to meet the current requirements
Spike solution For answering the tough technical
Problems create the spike solutions. The goal of these solutions should
Designing be to reduce the technical risks.
Refactoring Refactoring means reductions in the redundancy, elimination of
unused functionalities, redesign the obsolete designs. This will
Improve the quality of the project.
Customer The most essential requirement of the XP is availability of the
Coding availability Customer. In Extreme programming the customer not only helps
the developer team but it should be the part of the project.

Paired All the code to be included in the project must be coded by groups of
programming two people working at the same computer. This will increase the
quality of coding
Collective code By having collective code ownership approach the everyone
ownership contributes new ideas and not any single person becomes the
bottleneck of the project. Anyone can change any line of code to fix a
bug or to re factor.
Unit testing The test framework that contains automated test cases unit is used to
the code. All the code must be using unit testing before its release.
 Applications of Extreme Programming (XP): Some of the projects that are suitable to
develop using XP model are given below:
 Small projects: XP model is very useful in small projects consisting of small teams as
face to face meeting is easier to achieve.
 Projects involving new technology or Research projects: This type of projects face
changing of requirements rapidly and technical problems. So XP model is used to
complete this type of projects.

Industrial XP:
The industrial XP (IXP) is an organic evolution of XP. It is customer- centric. It has expanded role for
customers, and its advanced technical practices.
Various new practices that are appended to XP to create IXP are as follows:
1. Readiness Assessment:
Prior to the initiation of an IXP project, the organization should conduct a readiness assessment.
(1) An appropriate development environment exists to support IXP
(2) The team should contain appropriate and skilled 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.
(5) The broader project community will be populated appropriately.
2. Project Community:
Skilled and efficient people must be chosen as the agile team members for the success of the
project. The team is referred as the community when extreme programming approach is
considered. The project community consists of technologies, customers, and other stakeholder
who play the vital role for the success of the project. The role of the community members must be
explicitly defined.

3. Project charting:
Projectchartingmeansassessingthejustificationfortheprojectasabusinessapplication.That means,
the IXP team assess whether the project satisfies the goals and objectives of the organization.
4. Test driven management:
For assessing the state of the project and its progress the industrial XP needs some measurable
criteria.Intestdrivenmanagementtheprojectistestedwiththehelpofthesemeasurablecriteria.
5. Retrospectives:
After delivering the software increment, the specialized review is conducted which is called as
retrospective. The intention of retrospective is to improve the industry