UNIT IUNIT IIntroduction to Software Introduction to Software

EngineeringEngineeringPresented ByPresented By

Prof.Hitesh MohapatraProf.Hitesh MohapatraDept. of Computer Engg.Dept. of Computer Engg.

Software’s Dual RoleSoftware’s Dual Role

Software is a productSoftware is a product Delivers computing potentialDelivers computing potential Produces, manages, acquires, modifies, displays, or Produces, manages, acquires, modifies, displays, or

transmits informationtransmits information Software is a vehicle for delivering a productSoftware is a vehicle for delivering a product

Supports or directly provides system functionalitySupports or directly provides system functionality Controls other programs (e.g., an operating system)Controls other programs (e.g., an operating system) Effects communications (e.g., networking software)Effects communications (e.g., networking software) Helps build other software (e.g., software tools)Helps build other software (e.g., software tools)

What is What is Software?Software?

Software is a set of items or objects that form a “configuration” that includes • programs • documents • data ...

What is What is Software?Software?

software is engineeredsoftware is engineered software doesn’t wear outsoftware doesn’t wear out software is complexsoftware is complex

Wear vs. Wear vs. DeteriorationDeterioration

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

Software Software ApplicationsApplications system softwaresystem software

application softwareapplication software engineering/scientific engineering/scientific

software software embedded software embedded software product-line softwareproduct-line software Web Apps (Web applications)Web Apps (Web applications) AI softwareAI software

Software—New CategoriesSoftware—New Categories Ubiquitous computingUbiquitous computing—wireless networks—wireless networks Net sourcingNet sourcing—the Web as a computing engine—the Web as a computing engine Open sourceOpen source—”free” source code open to the —”free” source code open to the

computing community (a blessing, but also a computing community (a blessing, but also a potential curse!)potential curse!)

Also … (see Chapter 32)Also … (see Chapter 32) Data miningData mining Grid computingGrid computing Cognitive machinesCognitive machines Software for nanotechnologiesSoftware for nanotechnologies

Legacy SoftwareLegacy Software

software must be software must be adaptedadapted to meet the needs to meet the needs of new computing environments or of new computing environments or technology.technology.

software must be software must be enhancedenhanced to implement to implement new business requirements.new business requirements.

software must be software must be extended to make it extended to make it interoperableinteroperable with other more modern with other more modern systems or databases.systems or databases.

software must be software must be re-architectedre-architected to make it to make it viable within a network environmentviable within a network environment.

Why must it change?

Software MythsSoftware Myths Management MythsManagement Myths

We have books of standards, my staff will have sufficient info.We have books of standards, my staff will have sufficient info. I work very hard to put the latest, greatest, fastest, state-of-I work very hard to put the latest, greatest, fastest, state-of-

the-art hardware in front of all my programmers.the-art hardware in front of all my programmers. We have the greatest CASE tools around.We have the greatest CASE tools around. If we get behind, we can just add more programmers.If we get behind, we can just add more programmers.

Customer mythsCustomer myths A general statement of objectives is sufficient to start coding, A general statement of objectives is sufficient to start coding,

fill in the details later.fill in the details later. Project requirements change constantly, but change is easy Project requirements change constantly, but change is easy

because software is flexible.because software is flexible.

Programmer mythsProgrammer myths Once the program is written and working, our job is done.Once the program is written and working, our job is done. Until the program is running, there is no way to assess quality.Until the program is running, there is no way to assess quality. The only deliverable for a successful project is the working The only deliverable for a successful project is the working

program.program.

Software Engineering Software Engineering PracticePractice

- Software engineering practiceSoftware engineering practice- Communication practicesCommunication practices- Planning practicesPlanning practices- Analysis modeling practicesAnalysis modeling practices- Design modeling practicesDesign modeling practices- Construction practicesConstruction practices- Deployment practices Deployment practices

Software Engineering PracticeSoftware Engineering Practice

Consists of a collection of concepts, principles, methods, Consists of a collection of concepts, principles, methods, and tools that a software engineer calls upon on a daily and tools that a software engineer calls upon on a daily basisbasis

Equips managers to manage software projects and Equips managers to manage software projects and software engineers to build computer programssoftware engineers to build computer programs

Provides necessary technical and management how to’s in Provides necessary technical and management how to’s in getting the job donegetting the job done

Transforms a haphazard unfocused approach into Transforms a haphazard unfocused approach into something that is more organized, more effective, and something that is more organized, more effective, and more likely to achieve successmore likely to achieve success

The Essence of Problem The Essence of Problem SolvingSolving

1)1) Understand the problem (communication and analysis)Understand the problem (communication and analysis)• Who has a stake in the solution to the problem?Who has a stake in the solution to the problem?• What are the unknowns (data, function, behavior)?What are the unknowns (data, function, behavior)?• Can the problem be compartmentalized?Can the problem be compartmentalized?• Can the problem be represented graphically?Can the problem be represented graphically?

2)2) Plan a solution (planning, modeling and software Plan a solution (planning, modeling and software design)design)

• Have you seen similar problems like this before?Have you seen similar problems like this before?• Has a similar problem been solved and is the solution Has a similar problem been solved and is the solution

reusable?reusable?• Can sub problems be defined and are solutions available for Can sub problems be defined and are solutions available for

the sub problems?the sub problems?

The Essence of Problem The Essence of Problem Solving (continued)Solving (continued)

3)3) Carry out the plan (construction; code generation)Carry out the plan (construction; code generation)• Does the solution conform to the plan? Is the source Does the solution conform to the plan? Is the source

code traceable back to the design?code traceable back to the design?• Is each component of the solution correct? Has the Is each component of the solution correct? Has the

design and code been reviewed?design and code been reviewed?

4)4) Examine the results for accuracy (testing and quality Examine the results for accuracy (testing and quality assurance) assurance)

• Is it possible to test each component of the solution?Is it possible to test each component of the solution?• Does the solution produce results that conform to the Does the solution produce results that conform to the

data, function, and behavior that are required?data, function, and behavior that are required?

Seven Core Principles for Software Seven Core Principles for Software EngineeringEngineering

1)1) Remember the reason that the software existsRemember the reason that the software exists• The software should provide value to its users and satisfy the requirementsThe software should provide value to its users and satisfy the requirements

2)2) Keep it simple, stupid (KISS)Keep it simple, stupid (KISS)• All design and implementation should be as simple as possibleAll design and implementation should be as simple as possible

3)3) Maintain the vision of the projectMaintain the vision of the project• A clear vision is essential to the project’s successA clear vision is essential to the project’s success

4)4) Others will consume what you produce Others will consume what you produce • Always specify, design, and implement knowing that someone else will later have to Always specify, design, and implement knowing that someone else will later have to

understand and modify what you didunderstand and modify what you did5)5) Be open to the futureBe open to the future

• Never design yourself into a corner; build software that can be easily changed and Never design yourself into a corner; build software that can be easily changed and adapted adapted

6)6) Plan ahead for software reusePlan ahead for software reuse• Reuse of software reduces the long-term cost and increases the value of the program Reuse of software reduces the long-term cost and increases the value of the program

and the reusable componentsand the reusable components7)7) Think, then actThink, then act

• Placing clear, complete thought before action will almost always produce better Placing clear, complete thought before action will almost always produce better resultsresults

15

Communication PracticesCommunication Practices(Requirements Elicitation)(Requirements Elicitation)

CommunicationProject initiationRequirements gathering

PlanningEstimatingSchedulingTracking

ModellingAnalysisDesign

ConstructionCode Test Deployment

DeliverySupportFeedback

Communication PrinciplesCommunication Principles

1)1) Listen to the speaker and concentrate on what is being saidListen to the speaker and concentrate on what is being said2)2) Prepare before you meet by researching and understanding the Prepare before you meet by researching and understanding the

problemproblem3)3) Someone should facility the meeting and have an agendaSomeone should facility the meeting and have an agenda4)4) Face-to-face communication is best, but also have a document or Face-to-face communication is best, but also have a document or

presentation to focus the discussionpresentation to focus the discussion5)5) Take notes and document decisionsTake notes and document decisions6)6) Strive for collaboration and consensusStrive for collaboration and consensus7)7) Stay focused on a topic; modularize your discussionStay focused on a topic; modularize your discussion8)8) If something is unclear, draw a pictureIf something is unclear, draw a picture9)9) Move on to the next topic a) after you agree to something, b) if you Move on to the next topic a) after you agree to something, b) if you

cannot agree to something, or c) if a feature or function is unclear cannot agree to something, or c) if a feature or function is unclear and cannot be clarified at the momentand cannot be clarified at the moment

10)10) Negotiation is not a contest or a game; it works best when both Negotiation is not a contest or a game; it works best when both parties winparties win

17

Planning PracticesPlanning Practices((Defining a Road Map)Defining a Road Map)

CommunicationProject initiationRequirements gathering Planning

EstimatingSchedulingTracking Modelling

AnalysisDesign Construction

CodeTest Deployment

DeliverySupport

Feedback

Planning PrinciplesPlanning Principles

1)1) Understand the scope of the projectUnderstand the scope of the project2)2) Involve the customer in the planning activityInvolve the customer in the planning activity3)3) Recognize that planning is iterative; things will changeRecognize that planning is iterative; things will change4)4) Estimate based only on what you knowEstimate based only on what you know5)5) Consider risk as you define the planConsider risk as you define the plan6)6) Be realistic on how much can be done each day by Be realistic on how much can be done each day by

each person and how welleach person and how well7)7) Adjust granularity as you define the planAdjust granularity as you define the plan8)8) Define how you intend to ensure qualityDefine how you intend to ensure quality9)9) Describe how you intend to accommodate changeDescribe how you intend to accommodate change10)10) Track the plan frequently and make adjustments as Track the plan frequently and make adjustments as

requiredrequired

Barry Boehm’s WBarry Boehm’s W55HH PrincipleHH Principle

Why is the system being developed?Why is the system being developed? What will be done?What will be done? When will it be accomplished?When will it be accomplished? Who is responsible for each function?Who is responsible for each function? Where are they organizationally located?Where are they organizationally located? How will the job be done technically and managerially?How will the job be done technically and managerially? How much of each resource is needed?How much of each resource is needed?

The answers to these questions lead to a definition of key project characteristics and the resultant project plan.

Modeling PracticesModeling Practices((Analysis and Design)Analysis and Design)

CommunicationProject initiationRequirements gathering Planning

EstimatingSchedulingTracking

ModellingAnalysisDesign Construction

CodeTest

DeploymentDeliverySupportFeedback

Analysis Modeling PrinciplesAnalysis Modeling Principles

1)1) The The information domaininformation domain of a problem (the data that flows of a problem (the data that flows in and out of a system) must be represented and in and out of a system) must be represented and understoodunderstood

2)2) The The functionsfunctions that the software performs must be that the software performs must be defineddefined

3)3) The The behaviorbehavior of the software (as a consequence of of the software (as a consequence of external events) must be representedexternal events) must be represented

4)4) The models that depict information, function, and The models that depict information, function, and behavior must be partitioned in a manner that uncovers behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashiondetail in a layered (or hierarchical) fashion

5)5) The analysis task should move from essential The analysis task should move from essential information toward implementation detailinformation toward implementation detail

Design Modeling PrinciplesDesign Modeling Principles1)1) The design should be traceable to the analysis modelThe design should be traceable to the analysis model2)2) Always consider the software architecture of the system to be builtAlways consider the software architecture of the system to be built3)3) Design of data is as important as design of processing functionsDesign of data is as important as design of processing functions4)4) Interfaces (both internal and external) must be designed with careInterfaces (both internal and external) must be designed with care5)5) User interface design should be tuned to the needs of the end-user User interface design should be tuned to the needs of the end-user

and should stress ease of useand should stress ease of use6)6) Component-level design should be functionally independent (high Component-level design should be functionally independent (high

cohesion)cohesion)7)7) Components should be loosely coupled to one another and to the Components should be loosely coupled to one another and to the

external environmentexternal environment8)8) Design representations (models) should be easily understandableDesign representations (models) should be easily understandable9)9) The design should be developed iteratively; with each iteration, the The design should be developed iteratively; with each iteration, the

designer should strive for greater simplicitydesigner should strive for greater simplicity

External quality factors: those properties that can be readily observed

Internal quality factors: those properties that lead to a high-quality design from a technical perspective

Construction PracticesConstruction Practices

CommunicationProject initiation

Requirements gathering Planning

EstimatingScheduling

TrackingModellingAnalysisDesign Construction

CodeTest Deployment

DeliverySupport

Feedback

Coding PrinciplesCoding Principles(Preparation before coding)(Preparation before coding)

1)1) Understand the problem you are trying to solveUnderstand the problem you are trying to solve2)2) Understand basic design principles and conceptsUnderstand basic design principles and concepts3)3) Pick a programming language that meets the needs of Pick a programming language that meets the needs of

the software to be built and the environment in which it the software to be built and the environment in which it will operatewill operate

4)4) Select a programming environment that provides tools Select a programming environment that provides tools that will make your work easierthat will make your work easier

5)5) Create a set of unit tests that will be applied once the Create a set of unit tests that will be applied once the component you code is completedcomponent you code is completed

Coding PrinciplesCoding Principles(As you begin coding)(As you begin coding)

1)1) Constrain your algorithms by following structured Constrain your algorithms by following structured programming practicesprogramming practices

2)2) Select data structures that will meet the needs of the designSelect data structures that will meet the needs of the design3)3) Understand the software architecture and create interfaces Understand the software architecture and create interfaces

that are consistent with itthat are consistent with it4)4) Keep conditional logic as simple as possibleKeep conditional logic as simple as possible5)5) Create nested loops in a way that makes them easily Create nested loops in a way that makes them easily

testabletestable6)6) Select meaningful variable names and follow other local Select meaningful variable names and follow other local

coding standardscoding standards7)7) Write code that is self-documentingWrite code that is self-documenting8)8) Create a visual layout (e.g., indentation and blank lines) that Create a visual layout (e.g., indentation and blank lines) that

aids code understandingaids code understanding

Coding PrinciplesCoding Principles(After completing the first round (After completing the first round

of code)of code)1)1) Conduct a code walkthroughConduct a code walkthrough2)2) Perform unit tests (black-box and white-box) and correct Perform unit tests (black-box and white-box) and correct

errors you have uncoverederrors you have uncovered3)3) Refactor the codeRefactor the code

Testing PrinciplesTesting Principles

1)1) All tests should be traceable to the software All tests should be traceable to the software requirementsrequirements

2)2) Tests should be planned long before testing beginsTests should be planned long before testing begins3)3) The Pareto principle applies to software testingThe Pareto principle applies to software testing

• 80% of the uncovered errors are in 20% of the code80% of the uncovered errors are in 20% of the code4)4) Testing should begin “in the small” and progress toward Testing should begin “in the small” and progress toward

testing “in the large”testing “in the large”• Unit testing --> integration testing --> validation testing --> Unit testing --> integration testing --> validation testing -->

system testingsystem testing5)5) Exhaustive testing is not possible . Exhaustive testing is not possible .

Test ObjectivesTest Objectives

1)1) Testing is a process of executing a program with the Testing is a process of executing a program with the intent of finding an errorintent of finding an error

2)2) A good test case is one that has a high probability of A good test case is one that has a high probability of finding an as-yet undiscovered errorfinding an as-yet undiscovered error

3)3) A successful test is one that uncovers an as-yet A successful test is one that uncovers an as-yet undiscovered error undiscovered error

Deployment PracticesDeployment Practices

CommunicationProject initiation

Requirements gathering Planning

EstimatingScheduling

Tracking ModellingAnalysisDesign Construction

CodeTest Deployment

DeliverySupport

Feedback

Deployment PrinciplesDeployment Principles1)1) Customer expectations for the software must be Customer expectations for the software must be

managedmanaged• Be careful not to promise too much or to mislead the userBe careful not to promise too much or to mislead the user

2)2) A complete delivery package should be assembled and A complete delivery package should be assembled and testedtested

3)3) A support regime must be established A support regime must be established beforebefore the the software is deliveredsoftware is delivered

4)4) Appropriate instructional materials must be provided Appropriate instructional materials must be provided to end usersto end users

5)5) Buggy software should be fixed first, delivered laterBuggy software should be fixed first, delivered later

Software ProcessSoftware Process

Process ModelsProcess Models

Waterfall modelWaterfall model Incremental Process ModelsIncremental Process Models

Rapid application development modelRapid application development model Incremental modelIncremental model

Evolutionary Process ModelsEvolutionary Process Models Prototyping modelPrototyping model Spiral modelSpiral model

Specialized Process ModelsSpecialized Process Models Component-Based DevelopmentComponent-Based Development Formal Method modelFormal Method model

Comparison of life-cycle modelsComparison of life-cycle models

Waterfall modelWaterfall model

Requirements are reasonably understood.Requirements are reasonably understood. When work flow is linear in fashionWhen work flow is linear in fashion Systematic sequential approachSystematic sequential approach

Waterfall M

odel (or)

Classical Life

cycle (or)

Linear Sequentia

l Model

Incremental modelIncremental model

Evolution of waterfall modelEvolution of waterfall model New features added to 1New features added to 1stst Increment(core Increment(core

product)product) Incremental software development model may be Incremental software development model may be

applicable to projects where:applicable to projects where: Software Requirements are well defined, but realization Software Requirements are well defined, but realization

may be delayed.may be delayed. The basic software functionality are required earlyThe basic software functionality are required early

TimeS

W F

un

ctio

nal

ity

and

fea

ture

s

Inc 1

Inc 2

Inc 3

RAD ModelRAD Model

Rapid Application DevelopmentRapid Application Development Short development cycleShort development cycle Faster development (60-90) daysFaster development (60-90) days High quality resultsHigh quality results Use of (CASE) ToolsUse of (CASE) Tools Component based constructionComponent based construction System delivered in short time (2 to 3 months)System delivered in short time (2 to 3 months) Useful where requirements are well Useful where requirements are well

understood and scope is limitedunderstood and scope is limited

40

The RAD ModelThe RAD Model

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

Process ModelsProcess Models Waterfall modelWaterfall model Incremental Process ModelsIncremental Process Models

Rapid application development modelRapid application development model Incremental modelIncremental model

Evolutionary Process ModelsEvolutionary Process Models Prototyping modelPrototyping model Spiral modelSpiral model

Specialized Process ModelsSpecialized Process Models Component-Based DevelopmentComponent-Based Development Formal Method modelFormal Method model

Unified ProcessUnified Process Comparison of life-cycle modelsComparison of life-cycle models

PrototypingPrototyping

Early approximation of a final system Early approximation of a final system Linear and iterativeLinear and iterative Customer is unable to define the systemCustomer is unable to define the system Requirements are not freezed Requirements are not freezed a prototype is built to understand the a prototype is built to understand the

requirements requirements

43

Evolutionary Models: Evolutionary Models: PrototypingPrototyping

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

Spiral ModelSpiral Model

Simplified formSimplified form Waterfall model plus risk analysisWaterfall model plus risk analysis

Precede each phase byPrecede each phase by AlternativesAlternatives Risk analysisRisk analysis

Follow each phase byFollow each phase by EvaluationEvaluation Planning of next phasePlanning of next phase

45

Evolutionary Models: The Evolutionary Models: The SpiralSpiral

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

Specialized Process Models Specialized Process Models 1)Component Based 1)Component Based

DevelopmentDevelopment COTSCOTS

Commercial off-the-shelf software components Commercial off-the-shelf software components developed by vendors who offer them as products.developed by vendors who offer them as products.

Decomposition of the engineered systems into Decomposition of the engineered systems into functional or logical components with well-functional or logical components with well-defined interfaces used for communication defined interfaces used for communication across the components.across the components.

Com

pone

nt in

tegr

atio

n

Des

ign

arch

itect

ure

Mod

ule

Inte

gera

tion.

Com

preh

ensi

ve te

stin

g.

2) Formal Methods Model2) Formal Methods Model

Mathematically based techniques for Mathematically based techniques for representing and analysis of software.representing and analysis of software.

Formal methods includeFormal methods include Formal specificationFormal specification Specification analysis and proofSpecification analysis and proof Transformational developmentTransformational development Program verificationProgram verification

Formal Methods ModelFormal Methods Model

Reduces requirements errors as it forces a Reduces requirements errors as it forces a detailed analysis of the requirements detailed analysis of the requirements

Incompleteness and inconsistencies can be Incompleteness and inconsistencies can be discovered and resolveddiscovered and resolved

Currently very time consuming and Currently very time consuming and expensiveexpensive

Extensive training requiredExtensive training required Difficult to use this model to communicate Difficult to use this model to communicate

with the customer.with the customer.

Unified ProcessUnified Process

Contains features of OOA and OOD.Contains features of OOA and OOD. UML- Unified Modeling LanguageUML- Unified Modeling Language

It was created to support the OO design and modeling.It was created to support the OO design and modeling. iterative and incremental processiterative and incremental process

Phases of Unified processPhases of Unified process

All the phases are concurrent in natureAll the phases are concurrent in nature InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition ProductionProduction

52

inceptioninception

The Unified Process (UP)The Unified Process (UP)

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

UP (contd)UP (contd)

InceptionInception Customer communicationCustomer communication PlanningPlanning

Identify resources, assess risks, defines scheduleIdentify resources, assess risks, defines schedule Business requirements are identifiedBusiness requirements are identified

In the form of use cases.In the form of use cases. Rough architectureRough architecture

A tentative outline of major sub-systems, functions and A tentative outline of major sub-systems, functions and features that populate them.features that populate them.

UP (contd)UP (contd)

ElaborationElaboration Customer communicationCustomer communication Modeling activityModeling activity Expands the use cases.Expands the use cases. Expands the architecture to:Expands the architecture to:

Use case model, analysis model, design model, Use case model, analysis model, design model, implementation model and deployment model.implementation model and deployment model.

Review plan and make modificationsReview plan and make modifications Evaluate scope, risks, project delivery datesEvaluate scope, risks, project delivery dates

UP (contd)UP (contd)

ConstructionConstruction Develop software components (that make the use cases Develop software components (that make the use cases

operational).operational). Complete the analysis and design models.Complete the analysis and design models. Implement all functions and features for that Implement all functions and features for that

increment.increment. Conduct unit testing for the componentsConduct unit testing for the components Integrate components.Integrate components.

UP (contd)UP (contd)

TransitionTransition Create user manuals, guidelines, installation Create user manuals, guidelines, installation

procedures.procedures. Software is given to users for beta testing.Software is given to users for beta testing. Get user feedbackGet user feedback The increment is now a useable software release.The increment is now a useable software release.

57

UP Work ProductsUP Work ProductsInception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment

Delivered software increment Beta test reports General user feedback

Agile Software DevelopmentAgile Software Development

Is a group of software development methodologies Is a group of software development methodologies based on iterative and incremental development, based on iterative and incremental development, where requirements and solutions evolve through where requirements and solutions evolve through collaboration between self-organizing, cross-collaboration between self-organizing, cross-functional teams.functional teams.

Self Organization: is the process where a structure Self Organization: is the process where a structure or pattern appears in a system without central or pattern appears in a system without central authority.authority.

Cross-Functional team : is a group of people with Cross-Functional team : is a group of people with different functional expertise working toward a different functional expertise working toward a common goal.common goal.

Extreme ProgrammingExtreme Programming

Is a software development methodology which is Is a software development methodology which is intended to improve software quality and intended to improve software quality and responsiveness to changing customer responsiveness to changing customer requirements.requirements.

It releases product in short development cycles It releases product in short development cycles (time boxing)(time boxing)

Pair Programming: Driver and ObserverPair Programming: Driver and Observer Time BoxingTime Boxing Code ReviewCode Review Unit TestingUnit Testing