Lecture 4
SOFTWARE DEVELOPMENT
LIFE CYCLE MODELS
Chapter 2 from Object-oriented and classical software Engineering (7ed)
by
Stephen R. Schach
Outlines
•
•
•
•
Classic models
Agile models
Rational Unified Process (IBM CD)
Microsoft model (Student Presentation)
Waterfall Model
• Characterized by
– Feedback loops
– Documentation-driven
• Advantage
– Maintenance is easier
• Disadvantage
– Can not see the product until the end
Spiral Model
Figure 2.11
• Precede each phase by
– Alternatives
– Risk analysis
• Follow each phase by
– Evaluation
– Planning of the next phase
• Strengths
– Identify and manage risks
• Weaknesses
– For large-scale software only
– For internal (in-house) software only
Rapid Prototyping Model
• Characterized by
Rapid prototyping to determine what the client
needs
• Advantage
– Deliver what the client really wants
– No feedback loop needed
• Requires
– Rapid prototyping
– Modify prototype easily
Iteration and Incrementation
• Real software development process is
iterative and incremental process
– We make mistakes
– Moving target
– Miller’s Law
• Iteration is performed during each
incrementation
• We can consider the project as a whole as
a set of mini projects (increments)
• During each mini project we
– Extend the artifacts (increment);
– Check the artifacts (test)
– If necessary, change the relevant artifacts
(iteration)
• The final set of artifacts is the complete
product
• Each iteration can be viewed as a waterfall
life-cycle model
– Requirements phase
– Analysis phase
– Design phase
– Implementation phase
Strengths of Iterative-andIncremental Model
• There are multiple opportunities for
checking that the software product is
correct
• We can mitigate (resolve) risks early
• We have a working version of the software
product from the start
Code-and-Fix Model
• No design
• No specification
– Maintenance
nightmare
Agile Software
Development Methodology
To satisfy the customer through early and continuous
delivery of valuable software
Agile Software Development Methods - Review and Analysis
Manifesto for Agile Software Development
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.
Comparisons
Model
Strength
Weakness
Code-and-fix
Fine for short program that
require no maintenance
Totally unsatisfactory
for nontrivial program
Waterfall
Disciplined approach,
documentation driven
Delivered product may
not meet client’s needs
Rapidprototyping
Ensure the delivered product
meets the client’s needs
Not used widely
Iterative-andincremental
Multiple chances to check for
errors
Always have a working version
Mitigate risks early
Spiral model
Risk driven
Only for large in-house
project
Competent in risk
management
Extreme Programming
The term “extreme” comes from
taking those commonsense principles and practices them
to extreme levels
Extreme Programming Explained – Embrace Change
By
Kent Beck
What is Extreme Programming?
XP is a light-weight methodology for smallto-medium-sized teams developing
software in the face of vague or rapidly
changing environment.
Values of Extreme Programming
•
•
•
•
Communication
Simplicity
Feedback
Courage
Communication
• Most problems in development are caused by
communication problems
• XP aims to keep the right communications
flowing by employing many practices that can’t
be done without communicating:
– unit testing
– pair programming
– task estimations
• XP employs a coach whose job It is to notice
when people aren’t communicating and
reintroduce them.
Simplicity
• Simplicity is not easy.
– It is the hardest thing in the world not to look toward
the things you’ll need to implement tomorrow and
next week and next month.
• XP is making a bet.
– It is betting that it is better to do a simple thing today
and pay a little more tomorrow to change it if it needs
it, than to do more complicated thing today that never
be used anyway.
Feedback
• Feedback works at the scale of minutes
and days.
• Feedback works at the scale of weeks and
months.
Courage
• When there is an architectural flaw and
there is no way forward, fix the flaw.
• Throwing code away if you know it is not
the most promising solution.
XP Life Cycle
Role and Responsibilities
• Programmer
– Analyze, design, test, program and integrate.
• Customer
– define stories to be implemented,
– the order stories implemented
– Define functional test cases
• Tester
–
–
–
–
Help customers write functional test cases
Run functional tests regularly
Broadcast test results
Maintain testing tools
• Tracker (your are the conscious of the team)
– Trace the estimates made by team and give feedback
on how accurate they are
– Trace the progress and evaluate whether a goal is
reachable given the resource and time constrains
• Coach
– Responsible for the process as a whole
– Remain calm when everyone is panicking
• Consultant
– External member possessing the specific technical
knowledge needed
• Manager (big boss)
– Makes the decisions
Roots of XP Practices
Practices
•
•
•
•
•
•
•
Planning game
Small/short releases
Metaphor
Simple design
Testing
Refactoring
Pair programming
•
•
•
•
•
•
•
Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards
Open workspace
Just rules
• Planning game
Close interaction between the customer and the programmers. The programmers
estimate the effort needed for the implementation of customer stories and the
customer then decides about the scope and timing of releases.
• Small/short releases
A simple system is “productionized” rapidly – at least once in every 2 to 3 months.
New versions are then released if not daily, but at least monthly.
• Metaphor
The system is defined by a metaphor/set of metaphors between the customer and the
programmers. This “shared story”guides all development by describing how the
system works.
• Simple design
The emphasis is on designing the simplest possible solution that is implementable at
the moment. Unnecessary complexity and extra code are removed immediately.
• Testing
Software development is test driven. Unit tests are implemented before the code
and are run continuously. Customers write the functional tests.
• Refactoring
Restructuring the system by removing duplication, improving communication,
simplifying and adding flexibility.
• Pair programming
Two people write the code at one computer.
• Collective ownership
Anyone can change any part of the code at any time.
• Continuous integration
A new piece of code is integrated into the code-base as soon as it is ready. Thus,
the system is integrated and built many times a day. All tests are run and they have
to be passed for the changes in the code to be accepted.
• 40-hour week
A maximum of 40-hour working week. No two overtime weeks in a row are allowed.
If this happens, it is treated as a problem to be solved.
• On-site customer
Customer has to be present and available full-time for the team.
• Coding standards
Coding rules exist and are followed by the programmers. Communications through
the code should be emphasized.
• Open workspace
A large room with small cubicles is preferred. Pair programmers should be placed
in the center of the space.
• Just rules
Team has its own rules that are followed, but can also be changed at any time.
The changes have to be agreed upon and their impact has to be assessed.
Scope of Use
• Aimed for small and medium sized teams (3 to 20
people)
• The physical environment and the business culture
affecting the development unit
• If you want to try XP, for goodness sake don’t try to
swallow it all at once. Pick the worst problem in
your current process and try to solving it the XP
way.”(Beck 1999a)