Software Process Models

2
A Layered Technology
Software EngineeringSoftware Engineering
a “quality” focus
process model
methods
tools
+ + + +
*

3
Common process framework
Umbrella Activities
A Common Process Framework
Framework activities
work tasks
work products
milestones &
deliverables
QA checkpoints

4
Umbrella Activities
 Software project management (SPM)
 Formal technical reviews (FTRs)
 Software quality assurance (SQA)
 Software configuration management (SCM)
 Document preparation and production
 Reusability management
 Measurement
 Risk management (RA&M)

5
Testing
6
Feasibility
Study
1
Maintenance
9Review
8
Implementation
7
System
Specification
2
System
Development
5
Detailed Design
4
Outline Design
3
System Development
Life Cycle

6
Project Life Cycle Perspective
Planning Analysis Design
Implem-
entation
Testing
Main-
tenance
Software Configuration Management
Software Engineering/Project Management
Software Engineering Process (CMM)
Software Engineering Tools and Methods
Software Quality
http://www.

7
SOFTWARE DEVELOPMENT PROCESS MODELS
 A process model is chosen based upon the:
 nature of the project,
 application,
 methods and tools to be used, and
 controls and deliverables that are required.
 Regardless of the process model chosen, all the four activities
coexist simultaneously at some level of detail.
 Problem solving loop with basic four activities, i.e., problem
analysis, problem definition, technical development and
solution integration.

9
Important features
 All activities are to be performed in an order and one after the
other. The output of one is the input to the other.
 Verification and validation is to be performed after the end of each
phase.
 The inputs & outputs at each phase must be defined (i.e. goal of
each group is defined).
 Once the outputs of a phase are produced (i.e. phase completed) then
these should not be changed as it is input to the other. The certified
output of a phase that is released for the next phase is called a
baseline.
 It suggests a systematic, sequential approach to s/w development.
(1) The waterfall model

10
Outline design
Review
Maintenance
Feasibility
Study
System
Specification
Detailed
Design
System
Development
Testing &
Integration
Implementation
Req. Document
Project Plan
Feasibility
Report
System
Design
Document
Det Design
Document
Programs
Test Plans,
Test Reports
And Manuals Installation
Report
Review
Reports Supplements
Work Tasks &
Work Products

11
Limitations of Waterfall Model
1. Limits and freezes the requirements of the system.
• Suits to the automation of existing manual system. But having
unchanging (or changing few) requirements is unrealistic for new
systems.
2. Freezing requirements may result in purchase of an obsolete
hardware as the software development usually takes years (and h/w
technology is changing fast).
3. Does not support partial system development. This is specially
required as client also plays important role in the requirement
specification.

12
T I M E
Testing
Maintenance
Implemen-
tation
Design
Planning
Requirements
Analysis
Evolutionary Models
XP (Xtreme Programing)

13
 This approach is developed to counter the first two limitations
of the waterfall model.
 A customer may define a set of general objectives for software
but does not identify detailed input, processing, or output
requirements.
 The developer may be unsure of (1) the efficiency of an
algorithm, (2) the adaptability of an operating system, or (3)
the form the human machine interaction should take.
(2) Prototyping
 Instead of freezing the requirements before design, coding can
proceed, a throwaway prototype is built to help understand the
requirements.

14
 This prototype is based on the currently available requirements and
put on trail.
 Although the development of prototype also goes through the
design and coding phases but main stress is not put on formal
procedures.
 By using the prototype the user gets the true working environment
of the actual system to be designed and developed later on.
 Hence more realistic requirement of the required system are brought
in.
 Typically useful for the areas where a system (manual or
automated) does not exist or the overall system is very large and
complex.
 Also provides an implemented feasibility, which provides
effective method of demonstration.
Prototyping…..

15
Disadvantages:
 The only drawback seems the duplication of efforts and cost
involved in build-twice approach.
 Prototyping need not be very costly and can actually reduce the
overall development cost.
 The prototypes are usually not complete systems and many of the
details are not built in.
 In addition, cost of testing and writing detail documents is
reduced, which reduces the cost of developing prototype.
 Further the experience gained during prototyping is very useful for
developers when developing the final system. This experience also
reduces the cost of development of actual system, and results in
more reliable and better design.
Requirements Analysis
Design
Code
Test
Justifications:
Design Code Test

16
 high-speed RAD is achieved by using a component-based project
construction approach.
 Rapid application development (RAD) is a linear sequential S/W
development process model that emphasizes on extremely short
development cycle.
 If requirements are well understood
and project scope is constrained (i.e.
goals/ are fixed / freezed); the RAD
enables a development team to
create a “fully functional system”
within very short time (e.g. 60-90
days).
(3) RAD Model

17
1. Business Modeling (Business Processes)
• What information is generated?
• Who generates it?
• Where does the information go?
• Who processes it?
2. Data Modeling (Entities)
(1) The information flow is refined into a set of data objects that are needed
to support the business.
(2) Characteristics (attributes) of each object are identified and
(3) Relationships between these objects are defined.
3. Process modeling (Processes/Functions)
(1) The data object defined in the data modeling phase are transformed to
achieve the information flow necessary to implement a business function
(i.e. transformation of input-object to output object defines flow of
information in a process/function)
(2) Such processing descriptions are created for adding, modifying, deleting,
or retrieving a data object.
Information flows among business functions is modeled such that
answers the questions:
RAD Phases

18
4. Application Generation
(1) RAD is based on the use of 4GT.
(2) RAD process works to re-use existing components (when possible).
(3) Create re-useable components (when necessary). In all cases automated
tools are used to facilitate construction of S/W.
5. Testing and Turnover
(2) New components must be tested and all interfaces must be fully
exercised. Optimally,
Drawbacks
For large scalable projects, RAD requires sufficient human resources to
create right number of RAD teams.
RAD requires developers & customers committed to complete a system
in a short time frame, other wise if commitment is lacking from either
side, RAD projects will fail.
(1) Re-use releases from testing, as such components, are already tested.
(3) If a business application can be modularized such that each major
function can be completed in less than 3 months time, each can be
addressed by a separate RAD team, and then integrated (to give
working system in 3-6 months)

19
OR Iterative Enhancement Model
1. Solves the problem of 3rd limitation of the waterfall
model.
4. Applies linear sequences in a staggered fashion as
time progresses.
3. At each step, extensions and design modifications can
be made .
2. Basic idea: software should be developed in
increments; each increment adding some
functionality until the full system is implemented.
(5) The Incremental Model

20
analysis design code test
increment 2 delivery of 2nd increment
3rd increment
delivery ofanalysis design code testincrement 3
increment 1
delivery of 1st incrementAnalysis Design Code Test
delivery of
analysis design code testincrement n
nth increment

21
Advantages
1. Major advantage: it can result in better testing since testing
each increment is likely to be easier than testing the entire
system.
2. Similar to prototype each increment provides feed back which
is useful for determining further/final requirements of the
system.
3. Model proceeds in steps starting from the simple and key
aspects of the system.
4. A project control list is prepared that contains, in order, all the
tasks to be implemented in the final system; provides a better
control and progress monitoring of development.

22
 The activities in this model can be organized like a spiral. The
spiral has many cycles.
 The radial dimension represents the commutative
cost incurred in accomplishing the steps done so
far, and
 The angular dimension represents the progress
made in completing each cycle of the spiral.
(6) Spiral Model

23
(1) Each cycle begins with the identification of objectives and
different alternative possible to achieve the objectives.
(2) In the next step different alternatives are evaluated and
uncertainties and risks are identified.
(3) Next step is to develop strategies that resolve uncertainties of
risks and software development takes place.
(4) Finally the evaluation is made to help plan the next stage.
(5) The spiral is based on risk driven nature, which enables any
mixture of specification-oriented, prototype-oriented, simulation-
oriented, or some other approach.

24
An Evolutionary (Spiral) Model

25
Features
 Each Cycle is completed with a review, which covers all the
products developed in that cycle.
 Equally useful for development and enhancement projects.
 More cycles can be added to add activities not covered in the
model (e.g. feasibility)
 Provides Project management and planning activities, in addition
to development project.

26
 Object technology provides the technical framework for
component-based process model for SE.
 The OO paradigm is based on the creation of classes that
encapsulate both data and algorithms.
 If properly designed and implemented, OO classes are re-useable
across different applications and computer architecture.
 Resembles and incorporates many of characteristics of spiral
model.
 It is iterative, but composes application from components/pre-
packed S/W (sometimes called “classes”).
(7) The Component Assembly Model

27
Identify
Candidate
Components
Extract
Components if
available
Construct nth
Iteration
Put new
components in
library
Lookup Components
in Library
Build Components
“if unavailable”
Further
a) Identification of candidate classes is accomplished by examining the data
(in the analysis phase) that are to be manipulated and the operations
(algorithms) required.
b) Class library is also called component repository. A component if found
in library may require tailoring/modification to fulfill the (new)
requirements of the application.
c) According to a survey, component assembly leads to a 70% reduction
in development cycle time, an 84% reduction in project cost.

28
 Design patterns (DP’s) is a new concept in design reuse. There
are hundreds of DP’s identified and documented (Singleton,
Mediator, Observer, Composite). A methodology/mechanism is
being searched to implement the DPs.

 Agile Software Development

• A methodology is a formalized process or set of practices
for creating software
• A set of rules you have to follow
• A set of conventions the organization decides to follow
• A systematical, engineering approach for organizing software
projects
Methodology

Evolution of Methodology
 Lots of thought on this subject since
groups started building software
 “Use of GOTO Considered Harmful”
Communications of the ACM, Dijkstra
 By the 1990’s, we had arrived at the
Waterfall methodology
– Also known as BDUF (Big Design Up Front)

The Waterfall Development
Process

• The traditional development process:
System
Requirements
Software
Requirements
Analysis
Program
Design
Coding
Testing
Operations
• Or at worst …
• But this always ends up happening!

Characteristics of Waterfall
Methodologies
 Requirements are gathered up front
– Business analysts
– End users
– Interested departments
– Maybe a JAD (Joint Application Design session?)
 Requirements lead to design
 Design leads to implementation
 Implementation leads to acceptance testing
 It is deployed

Where Does Waterfall Work
Well?
 Organizations where requirements don’t change
– Stable requirements leads to stable design…
– Stable design leads to “no surprise” implementation
– Etc.
 Who has requirements like this?
– NASA
– . . .
 What happens when requirements change?

Changing Requirements
 The later in the development cycle that a
requirement changes, the bigger the impact
on the scope of the change
 Documented by Barry Boehm
 Changes to well established code may have
a ripple effect, causing side effects in other
code
 How can you make coding changes with
confidence?

Traditional Processes are ‘Heavy’
CostofChange
Requirements Design Implementation Testing Maintenance
CostofChange

The Evolution of Agility
 Problem: much of the methodology work in software
engineering has been based on traditional engineering
– Design
– Implement
– Deploy
 Software is fundamentally different
– In its very nature
– The way that people want to design, use, and
modify software
 Problem: we’ve been trying to tell developers how to
successfully write software…maybe we should find out
how they work best

Agility
 Lots of smart guys got together and re-thought how
software is built
– In the nick of time
– Most software projects fail
– The business risk of software development is far too
high
– It seems hard to predict what will cause one project to
succeed and another fail
 Observe successful projects and figure out what they did
right
 Observe unsuccessful projects and figure out what they
did wrong
 This led to the Agile Manifesto

The Agile Alliance
 17 Really Smart Guys met in Snowbird, Utah in
February 2001:
– Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew
Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert
C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas
 They agreed on a manifesto and supporting principles

The Agile Manifesto
 “We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
– Individuals and interactions over processes and
tools
– Working software over comprehensive
documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
 That is, while there is value in the items on the right, we
value the items on the left more”.
The Agile Alliance

The Culmination of Current
Thinking
 The ideas in the Agile Manifesto didn’t
just fall from the sky
 They had been percolating for several
years in different forms
 The Agile Manifesto just documented what
a lot of people were already thinking

Principles of Agile Development
 Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
 Agile focuses on the delivery of software
 Delivering software early and often allows for quick wins
and early feedback about the requirements, the team, and
the process
 The emphasis is to deliver the most important parts first
– Development proceeds from most important to less
important
– Note that this may (and will!) change during the
course of the project

 Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
 Most projects run 1 to 3 month cycles [Cockburn]
 Within the cycle, work is done in short iterations
– Iterations usually last from 2 to 4 weeks
– The iteration is complete at the end of the iteration, at
the expense of moving requirements
– XP iterations are 2 to 3 weeks
 Users review progress throughout the process

 Working software is the primary
measure of progress.
 Code is the most important deliverable
 Agile methodologies place a premium on
getting something up and running early and
evolving it over time
 Agile does not discard the need for design
documentation
– Diagram to understand, then move to code
– Documentation is secondary to working code

 Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
 This works because of
– Early and frequent delivery of running software
– Use of iterative and time-boxing techniques
– Continual attention to architecture
– Willingness to update the design
 If you can gracefully accommodate changing
requirements and your competition cannot, you win

 Business people and developers must work together
daily throughout the project.
 There is a strong correlation between links to users and
project success [Frakes 1995]
 The best links are through onsite business expertise and
daily discussion
– The longer it takes to get information to and from the
developers, the more damage will occur in the project
– Information flow is similar to convection currents
 XP insists that business stakeholders are part of the
development team

 Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
 “It is better to have motivated, skilled people
communicating well and using no process at all
than a well-defined process used by unmotivated
individuals.” [Cockburn 2002]
 “We hire good people, give them the tools and
training to get their work done, and get out of
their way.” [Thomas]

Developers are the Key
 You cannot overemphasize this point:
developers, project managers, and business
analysts make or break the project
 "All other factors being equal, a 90th-
percentile team of analysts and
programmers will be about four times as
productive as a 15th-percentile team.“
[Boehm 1981]
 You should hire the smartest people you
can find.

 The most efficient and effective method
of conveying information to and within a
development team is face-to-face
conversation.
 Communication is like air conditioning
 Cockburn defines modalities of
communications and their effectiveness
(Agile Software Development, 2002)

Cockburn’s Modalities and
Effectiveness

Communication
 Face to face communication about specific
topics is most efficient
 Agile also takes advantage of “knowledge
radiators”
– Simple, low-tech information stores
– Poster board with index cards or Post-it notes
– Project status beside the coffee pot
– Automated build report via web browser

 The best architectures, requirements, and
designs emerge from self-organizing teams.
 This means either that architectures,
requirements, and designs emerge
– in small steps over time
– as a logical consequence of human-centric
rules the team uses
 All 3 must be allowed to adjust over time
 An architecture that grows in steps can follow the
changing knowledge of the team and the
changing wishes of the users

 Continuous attention to technical excellence and good
design enhances agility.
 The design must evolve
– You must create good designs initially
– You must review and improve designs regularly
– Design cleanup as compared to debt [Cunningham
2001]
 Technical excellence applies to all aspects of the project
– Build management
– Coding standards
– Collaboration documentation

 Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
 Social aspect
– An alert, engaged staff is more effect than a tired,
plodding staff
– Long hours are a symptom that something has gone
wrong
– Only work 8 hours a day; never put in overtime 2
weeks in a row
 Technical aspect
– Software development can be viewed as a long
strategic game
– Each move sets up the next move

 Simplicity--the art of maximizing the amount of work
not done--is essential.
 “This letter is longer than I wish, for I had not the time to
make it shorter” Blaise Pascal
 It is sometimes more difficult to make things simpler
 A cumbersome model is easier to produce than a simple
one
 DRY principle (Don’t Repeat Yourself)
 “Design for simplicity; add complexity only where you
must.” Art of Unix Programming, Raymond 2003
 “Code smell”

 At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
 Constant awareness is key
 Never get lazy
 XP encourages this every step of the way
 Questions:
– How light is too light?
– How simple is too simple?
– Can we make this simpler

Why XP Helps
 Extreme Programming is a “light” process
that creates and then exploits a flattened
cost curve
 XP is people-oriented rather than process
oriented, explicitly trying to work with
human nature rather than against it
 XP Practices flatten the cost of change
curve.

XP Cost of Change Curve
CostofChange
XP cost of
change
curve

Embrace change
 In traditional software life cycle models, the cost of
changing a program rises exponentially over time
 A key assumption of XP is that the cost of changing a
program can be hold mostly constant over time
 Hence XP is a lightweight (agile) process:
– Instead of lots of documentation nailing down what customer
wants up front, XP emphasizes plenty of feedback
– Embrace change: iterate often, design and redesign, code and
test frequently, keep the customer involved
– Deliver software to the customer in short (2 week) iterations
– Eliminate defects early, thus reducing costs

Why does XP Help?
 “Software development is too hard to spend time on
things that don't matter. So, what really matters?
Listening, Testing, Coding, and Designing.” - Kent Beck,
“father” of Extreme Programming
 Promotes incremental development with minimal up-front
design
 Results in a “pay as you go” process, rather than a high
up-front investment
 Delivers highest business value first
 Provides the option to cut and run through frequent
releases that are thoroughly tested

More on XP
 XP tends to use small teams, thus reducing
communication costs.
 XP puts Customers and Programmers in one
place.
 XP prefers index cards to expensive round-trip
UML diagramming environments
 XP's practices work together in synergy, to get a
team moving as quickly as possible to deliver
value the customer wants

Successes in industry
 Chrysler Comprehensive Compensation system
– After finding significant, initial development problems, Beck
and Jeffries restarted this development using XP principles
– The payroll system pays some 10,000 monthly-paid employees
and has 2,000 classes and 30,000 methods, went into production
almost on schedule, and is still operational today (Anderson
1998)
 Ford Motor Company VCAPS system
– Spent four unsuccessful years trying to build the Vehicle Cost
and Profit System using traditional waterfall methodology
– XP developers successfully implemented that system in less than
a year using Extreme Programming (Beck 2000).

68
(8) XP (Xtreme Programing)
An Agile process
 What is Xtreme Programming ?
heavily incremental SW development process based on using up-
front testing,
 more regular small releases and continues integration.
 Its methodology aims to promote simplicity, communication,
feedback and ultimately reduce traditional red tape.
XP (according to inventor Kent Beck) is characterized by 12
practices:
Planning Game
Small Releases
Metaphor
Simple Design
Testing
Continuous Integration
Pair Programming
Collective Ownership
Refactoring
40-Hour Week
On-Site Customer
Coding Standards
http://www.extremeprogramming.org/rules/userstories.html

69
 What Xtreme Programming is not
 that developers should have so much freedom that 30 years
of established best practices are thrown out the window. I
think this could be fairly termed XSP i.e. Xtremely Stupid
Programming.
XP (Xtreme Programing)

1 - The Planning Game
– User stories are written
– Release planning creates the schedule.
– Make frequent small releases.
– The Project Velocity is measured.
– The project is divided into iterations.
– Iteration planning starts each iteration.
– Move people around.
– A stand-up meeting starts each day.

The Planning Game – Advantages
 Reduction in time wasted on useless
features
 Greater customer appreciation of the cost
of a feature
 Less guesswork in planning

The Planning Game – Disadvantages
 Customer availability
 Is planning this often necessary?

2- Small Releases
 Small in terms of functionality
 Less functionality means releases happen
more frequently
 Support the planning game

Small Releases – Advantages
 Frequent feedback
 Tracking
 Reduce chance of overall project slippage

Small Releases – Disadvantages
 Not easy for all projects
 Not needed for all projects
 Versioning issues

3 – Metaphor
 The oral architecture of the system
 A common set of terminology
 Guide all development and conversations with a simple
shared story of how the whole system works
– Gives the team a whole picture of describing the
system, where new parts fit, etc.
 Words used to identify technical entities should be chosen
from the metaphor
 The default metaphor is the business domain, and it’s
usually just fine

Metaphor – Advantages
 Encourages a common set of terms for the
system
 Reduction of buzz words and jargon
 A quick and easy way to explain the
system

Metaphor – Disadvantages
 Often the metaphor is the system
 Another opportunity for
miscommunication
 The system is often not well understood as
a metaphor

4 – Simple Design
 K.I.S.S.
 Do as little as needed, nothing more

Simple Design – Advantages
 Time is not wasted adding superfluous
functionality
 Easier to understand what is going on
 Refactoring and collective ownership is
made possible
 Helps keeps programmers on track

Simple Design – Disadvantages
 What is “simple?”
 Simple isn’t always best

5– Testing
 Unit testing
 Test-first design
 All automated

Testing – Advantages
 Unit testing promote testing completeness
 Test-first gives developers a goal
 Automation gives a suite of regression test

Testing – Disadvantages
 Automated unit testing isn’t for everything
 Reliance on unit testing isn’t a good idea
 A test result is only as good as the test
itself

6-Refactoring
 Improve the design of existing code without
changing its functionality
– Relies on unit testing to ensure the code is
not broken
 Bad smells in code:
– Long method / class
– Duplicate code
– Methods does several different things (bad
cohesion)
– Too much dependencies (bad coupling)
– Complex / unreadable code

Refactoring – Advantages
 Prompts developers to proactively improve
the product as a whole
 Increases developer knowledge of the
system

Refactoring – Disadvantages
 Not everyone is capable of refactoring
 Refactoring may not always be
appropriate

90
7- Pair programming is...
 TWO programmers working side-by-side, collaborating on the same
design, algorithm, code or test. One programmer, the driver, has
control of the keyboard/mouse and actively implements the program.
The other programmer, the observer, continuously observes the work
of the driver to identify tactical (syntactic, spelling, etc.) defects and
also thinks strategically about the direction of the work. On demand,
the two programmers can brainstorm any challenging problem.
Because the two programmers periodically switch roles, they work
together as equals to develop software.
--Laurie Williams
North Carolina State University Computer Science
 Source: http://www.pairprogramming.com/

Pair Programming – Advantages
 Two heads are better than one
 Focus
 Two people are more likely to answer the
following questions:
– Is this whole approach going to work?
– What are some test cases that may not work
yet?
– Is there a way to simplify this?

Pair Programming
 Pairs produce higher quality code
 Pairs complete their tasks faster
 Pairs enjoy their work more
 Pairs feel more confident in their work

How It Works for Me?
 Pair programming is great for complex and
critical logic
– When developers need good concentration
– Where quality is really important
– Especially during design
– Reduces time wasting
– Trivial tasks can be done alone
 Peer reviews instead pair programming is
often alternative

Pair Programming – Disadvantages
 http://www.cenqua.com/pairon/
 Many tasks really don’t require two
programmers
 A hard sell to the customers
 Not for everyone

8. Collective Code Ownership
 Code to belongs to the project, not to an
individual engineer!
 Any engineer can modify any code
 Better quality of the code
 Engineers are not required to work around
deficiencies in code they do not own
– Faster progress
– No need to wait for someone else to fix
something

Collective Ownership – Advantages
 Helps mitigate the loss of a team member
leaving
 Promotes developers to take responsibility
for the system as a whole rather then parts
of the system

Collective Ownership - Disadvantages
 Loss of accountability
 Limitation to how much of a large system
that an individual can practically “own”

9 – Continuous Integration
 New features and changes are worked into
the system immediately
 Code is not worked on without being
integrated for more than a day

Continuous Integration -
Advantages
 Reduces to lengthy process
 Enables the Small Releases practice

Continuous Integration –
Disadvantages
 The one day limit is not always practical
 Reduces the importance of a well-thought-
out architecture

10 – 40-Hour Week
 The work week should be limited to 40
hours
 Regular overtime is a symptom of a
problem and not a long term solution

40-Hour Week – Advantage
 Most developers lose effectiveness past 40-
Hours
 Value is placed on the developers well-
being
 Management is forced to find real solutions

40-Hour Week - Disadvantages
 40-Hours is a magic number
 Some may like to work more than 40-
Hours

11- On-Site Customer
 Customer available on site
– Clarify user stories
– Make critical business decisions
 Developers don’t make assumptions
 Developers don’t have to wait for
decisions
 Face to face communication minimizes the
chances of misunderstanding

On-Site Customer – Advantages
 Can give quick and knowledgeable
answers to real development questions
 Makes sure that what is developed is what
is needed
 Functionality is prioritized correctly

On-Site Customer – Disadvantages
 Difficult to get an On-Site Customer
 The On-Site customer that is given may
not be fully knowledgeable about what the
company
 May not have authority to make many
decisions
 Loss of work to the customer’s company

12 – Coding Standards
 All code should look the same
 It should not possible to determine who
coded what based on the code itself

Coding Standards – Advantages
 Reduces the amount of time developers
spend reformatting other peoples’ code
 Reduces the need for internal commenting
 Call for clear, unambiguous code

Coding Standards – Disadvantages
 Degrading the quality of inline
documentation

Four Core Values of XP
 Communication
 Simplicity
 Feedback
 Courage

Communication
 What does lack of communication do to
projects?
 XP emphasizes value of communication in
many of its practices:
– On-site customer, user stories, pair programming,
collective ownership (popular with open source
developers), daily standup meetings, etc.
 XP employs a coach whose job is noticing when
people aren’t communicating and reintroduce
them

Simplicity
 ''Do the simplest thing that could possibly
work'' (DTSTTCPW) principle
– Elsewhere known as KISS
 A coach may say DTSTTCPW when he sees an
XP developer doing something needlessly
complicated
 YAGNI principle (''You ain’t gonna need it'')
 How do simplicity and communication support
each other?

Feedback
 Feedback at different time scales
 Unit tests tell programmers status of the system
 When customers write new user stories,
programmers estimate time required to deliver
changes
 Programmers produce new releases every
2-3 weeks for customers to review
 How does valuing feedback turn the waterfall
model upside down?

Courage
 The courage to communicate and accept
feedback
 The courage to throw code away
(prototypes)
 The courage to refactor the architecture
of a system
 Do you have what it takes?

Software Process Models

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Software Process Models

Ähnlich wie Software Process Models (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software Process Models