Transcript Development Techniques - University of Sunderland

High Ceremony Programming
(HCP)
CSE301
University of Sunderland
Harry R. Erwin, PhD
Where do High Ceremony
Methods Fit?
• Projects where the risk is low.
• Projects where you and your customer
know where you’re going.
• Projects where the technology is evolving
slowly.
• Projects where you have to get it right the
first time.
Seven Kinds of High Ceremony
Projects
1.
2.
3.
4.
5.
6.
7.
Technical risk must be controlled (no surprises)
Schedule must be controlled
Cost must be controlled.
Security requirements
Life or mission-critical requirements
Performance requirements
Customer requirements
Schedule and cost co-vary for optimally managed
programmes. You can usually control just one of
cost, schedule, and technical risk!
Why High-Ceremony?
• For low-technical-risk projects, waterfall is
fastest and cheapest.
• Ensures you get a known product on time.
(The demonstration project for XP was a
failure.)
• Keeps the customer from interfering. (Amateur
systems engineers with approval authority are
a recipe for disaster—as the UK Government
demonstrates over and over.)
• Ensures critical requirements are met.
High Ceremony Programming
Defined
• Is defined by the following:
–
–
–
–
Values
Practices
Activities
Roles
• Vulnerable to the cost of change curve.
High Ceremony Principles
• Our highest priority is to satisfy the customer
through on-time delivery of software that meets a
known requirement.
• Do not welcome changing requirements,
especially late in development.
• Deliver working systems periodically and
predictably.
Principles (II)
• You still build projects around motivated individuals.
Give them the environment and support they need, and
trust them to get the job done.
• The most reliable method of conveying information to
and within a development team is in the form of
documentation.
• Regular delivery of working systems is the primary
measure of progress.
• High ceremony processes promote sustainable
development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
Principles (III)
• Continuous attention to technical excellence and
good design enhances quality and reliability.
• Simplicity—the art of maximizing the amount of
work not done—remains essential.
• The best architectures, requirements, and designs
emerge from well-organized teams.
• At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
Problems Targeted by HCP
•
•
•
•
•
Lack of communication
Requirements volatility
Software development that isn’t used.
Out of date documentation
Obsolescence
HCP Values
• Communication—written.
• Simplicity—always do the right thing.
• Feedback—on a controlled basis from the
customer.
• Courage—willingness to stand your ground.
Communication—Written
• Reduces the chance of misunderstanding.
• Creates risks, however:
– Too much paperwork.
– You’re vulnerable to demoralization.
• YMMV.
Simplicity—Always do the Right
Thing.
• You Ain’t Gonna Need It (YAGNI).
• Absolute simplicity isn’t always the best
solution, so be as simple as possible but not
too simple.
• Nonfunctional requirements will affect
simplicity.
• Maintain standards.
Feedback—on a Controlled Basis
from the Customer.
• Go ask the customer, but be careful what
you ask.
• Can be used in design:
– Build a first-order prototype
– Test it
– Adjust it until it’s right.
• A little bit of analysis can replace a lot of
being jerked around by feedback.
Courage—Willingness to Stand
Your Ground.
• But be willing to make design changes
when they are right.
• It helps a lot to have an automatic test suite
to tell you that you’re still OK.
HCP Activities
•
•
•
•
•
Coding
Testing
Listening
Designing
Thinking
HCP Roles
•
•
•
•
•
•
•
Programmer/Analyst
Specialist
Tester
Tracker/Checker
Coach
Consultant
Big boss
HCP Practices
• Test-driven
development
• Requirements analysis
• Management to plan
• Whole team
• Right-sized cycles
• Metaphor
• Simple design
•
•
•
•
•
•
•
•
Refactor mercilessly
Collective ownership
Pair programming
Continuous integration
Sustainable pace
Coding standards
Acceptance tests
(Elegant design)
Test-Driven Development
• ‘The test-driven development is the method
of software development where tests specify
interfaces of implementation and all code
must have passed the tests.’ (Wikipedia)
• Martin (2003): ‘programmers work in very
short cycles, adding a failing test, then
making it work.’
Requirements Analysis
• Documents what the user needs.
• Describes how the system is supposed to work.
You stop when you know how to build the
system.
• Carefully and completely done. The most
dangerous kind of requirements error is the
requirement you didn’t know about.
• Sufficient detail to support estimation.
• “If you don’t know where you’re going, don’t
start walking.” (Barry Boehm)
Management to Plan
• Plan realistically, based on your experience
with the project team.
• Keep a 25% contingency reserve.
• Manage to the plan
• Update the plan to reflect what you learn.
HCP Life Cycle
• Waterfall or spiral model (terminating in a
waterfall)
• Feedback from later phases
• Plan for maintenance
Metaphor
• The system architect leads the team to a
shared vision of how the program works.
Simple Design
• Keep the design exactly suited for the
planned functionality of the system. It
passes all the tests, contains no duplication,
expresses everything the authors want
expressed, and contains as little code as
possible.
Simple Design
• The simplest design that can meet the user
needs.
• “You aren’t going to need it.”
• Once and only once—no code duplication.
Refactor Mercilessly
• We’ve discussed this.
• Don’t churn the code.
• Keep it clean to support extension.
Collective Ownership
• Any pair of programmers can improve any
code under development at any time.
Pair Programming
• Martin (2003): “All production software is
built by two programmers, sitting side by
side, at the same machine.”
• Boehm (2004) indicates that pair
programming is about 10% slower, but the
software fault rate of the resulting code is
about 60% less. This is a ‘silver bullet’.
Pair Programming
• Pair Programming
(ExtremeProgrammingPractice) requires two
engineers to participate in one development effort
at one workstation. Each member performs the
action the other is not currently doing: While one
types in unit tests the other thinks about the class
that will satisfy the test, for example. Studies have
shown that, after training for the "PeopleSkills"
involved two programmers are more than twice as
productive as one for a given task. (Wikipedia)
Continuous Integration
• Martin (2003): “The team keeps the system
fully integrated at all times.”
Sustainable Pace
• Martin (2003): “The team is in it for the
long term. They work hard, at a pace that
can be sustained indefinitely. They conserve
their energy, treating the project as a
marathon rather that a sprint.”
Coding Standards
• Martin (2003): “All the code in the system
looks as if it was written by a single—very
competent—individual.”
Acceptance Tests
• As part of selecting each desired feature, the
customers define acceptance tests to show
that the feature is working.
Elegant Design
• The initial design and architecture is as right
as possible.
• You’ll have to live with it for 10-20 years.
• Help it emerge through refactoring so it is
right.
Conclusions
• If HCP is the answer, what is the question?
• Certain kinds of problems, especially those
where you don’t know where you’re going,
are not suitable for HCP, so be prepared to
use a light-weight process when necessary.