Ten Quality Methods which probably won't improve product
quality; and ten quality methods that more probably will succeed -
for all aspects of quality Tom Gilb www.Gilb.com [email protected]
Result Planning Limited MASTER Version May 8th 2002
Slide 2
Slide 2 wont improve (means, in this talk) You do not end up
getting as good as you expected, when you invested in the method.
You would not have used the method, if that were the result
ALTERNATIVE TALK TITLE "Ten Quality Methods which probably won't
improve product quality, and ten quality methods that more probably
will succeed - for all aspects of quality - not just bugs. "
Slide 3
Slide 3 Software All elements of the software (not just
code)The code The updates The data and databases The online user
instruction The interfaces The user manuals The training materials
The development and maintenance documentation The test planning The
test scripts Anything else which is not clearly hardware
Slide 4
Slide 4 Quality All stakeholder valued aspects of system
performance, including quality and savings Speed Capacity
Adaptability Maintainability Availability Reliability Portability
Reusability Testability Usability And very many more
Slide 5
Slide 5 Here are some popular methods or approaches which
people expect some software quality from, but I suggest they will
in practice be disappointed - often because of poor teaching and
implementation - often because of lack of quality focus
Slide 6
Slide 6 1. Go for CMM Level X The Software Engineering
Institutes Capability Maturity Models CMM and CMMI Levels 2 to 5
Results of Level 3 Why Not? Not quality oriented CMM Bureaucracy
overwhelms any idea of quality Intended mainly to put reasonable
software engineering processes in place, but Does not directly
address any quality aspect of a system Maybe you can get quality in
spite of CMM but not because of it.
Slide 7
Slide 7 2. Demand Better (Conventional) Testing Conventional
Software Testing is not normally directed towards product or system
quality levels It looks for bugs (to oversimplify quite a bit!)
Conventional Testing is function oriented (not quality-oriented) It
does not measure multiple quality type levels Conventional Testing
is too late in the development cycle You get quality by designing
it in, not testing it in! Test can prove presence of bugs/defects
but cannot prove their absence (Note I will suggest Evolutionary
Testing as a way of improving software quality later. Evo testing
is not conventional, yet!)
Slide 8
Slide 8 3. Use Cases Use cases are not directed to qualities of
a system Use cases cannot express quality requirements Use cases
are not judged on the degrees of quality they deliver to an
architecture There is no evidence published about the relationship
between Use cases and any sort of quality Id be happy to be
informed of evidence I have overlooked!
Slide 9
The list of problems with Use Cases and UML I have no intention
of going through this in detail during my talk, but I wanted to
make the details available to the participant - to lend more
credibility to my point. The details are at the end of these
slides.
Slide 10
Slide 10 A Use Case Critique Summary By Don Mills [Mills01]
This Appendix lists the problems with use cases that I found in my
brief, and unscientific, survey of the literature (a mixture of
books on my and my employers shelves, with articles found by
browsing the Internet). The first eight entries come from the UI
Design.net editorial for October 1999
(http://www.uidesign.net/1999/imho/oct_imho.html).http://www.uidesign.net/1999/imho/oct_imho.html
Solutions to all of the problems exist, but not within the RUP or
the UML (or only clumsily, ambiguously, or inconsistently), while
outside those strictures many competing solutions have been
proposed. Note that this is not intended as an exhaustive list..
DETAILS AT END OF THESE SLIDES.
Slide 11
Slide 11 4. RUP, RUP SE System Quality Provides the views to
support addressing system quality issues in an architecture driven
process [RUP SE] In RUP SE, [RUP] this idea is carried forward,
adding systems engineers to the mix. Their area of concern is the
design and specification of the hardware and system deployment to
ensure that the overall system requirements are addressed. Rational
Unified Process never did address quality. RUP SE (Systems
Engineering) is a belated, but weak (TG Opinion) attempt to patch
that hole in RUP
Slide 12
Slide 12 RUP SE Example of dealing with quality [RUP]
Slide 13
Slide 13 5. Conventional Inspection, Peer reviews, Reviews
Reviews do not generally focus on quality. Specific reviews may
attempt to address quality. But in my view not professionally
(quantified!). Conventional Inspections as they are usually done
will fail to deal with quality in general, and will be very cost
ineffective for quality in terms of bugs Why are Conventional
inspections a failure route? They focus on clean up of bad work
(high bug injection rates) Their effectiveness for bugs is maximum
60% (one pass) They are rarely done at full effect ( likely effect
10%- 30%)
Slide 14
Slide 14 5. (continued) Inspections, to deal with quality,
must: Deal with all aspects of quality engineering including
quality requirements, quality design Define required quality
practices in terms of process Rules (failed rule = defect, detected
by Inspection) Like: All quality requirements will be defined with
a scale of measure All design specification will be evaluated
quantitatively on an impact estimation table
Slide 15
Slide 15 6. Extreme Programming XP XP has no direct focus on
quality But there are several mechanisms which can help reduce
injection of bugs in XPare That does not deal with many other types
of quality. XP cant hurt you but it does not pretend to solve the
larger quality attribute problem Click here for XP development
methodClick here for XP development method
Slide 16
16 Kent Beck XP
Slide 17
17 XP Pair Programming IEEE Software July/Aug 2000 By working
in tandem, the pairs completed their assignments 40% to 50% faster.
As Beck writes, Even if you werent more productive, you would still
want to pair, because the resulting code quality is so much higher.
10
Slide 18
18 Different View 12 March 2002 u dear tom, u browsing through
your presentation "10 guaranteed ways..." u that i did not have the
opportunity to listen to, i noticed u that you also have a slide
concerning the XP practice of pair u programming. you might be
interested in a new study on u pair programming to be found at u
http://dialspace.dial.pipex.com/town/drive/gcd54/conference2001/papers/nawro
u cki.pdf. u the study is essentially contradicting earlier
findings by u laurie williams. u i actually set up a paper "Extreme
Programming Considered u Harmful for Reliable Software Development"
that you can u find at u
http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf u
and you might want to have a look at it. u regards, u gerold keefer
u
=====================================================================
u AVOCA GmbH - Advanced Visioning of Components and Architectures u
Kronenstrasse 19 u D-70173 Stuttgart u fo +49 711 2271374 fa +49
711 2271375 u http://www.avoca-vsm.com
mailto:[email protected]
Slide 19
19 Woodward asks about XP 1/3 Questions on XP from
[email protected] In response to
http://www.extremeprogramming.orghttp://www.extremeprogramming.org
1.How do you manage required changes in Software Architecture? Not
all programmers are architects and not all architects are
programmers so who does the work and what do the programmers do
while the architecture is changed? 2.It seems to assume that all
team members are equally experienced and skilled i.e. can make
changes to the system with equal levels of confidence and
competence. Otherwise, who is responsible for the integrity of the
system, data models etc? 3.Who specifies the requirements? How are
they specified? Or do the programmers have free reign to interpret
often-fuzzy statements by the users however they want to? 4.What
does the Project Manager do? 5.Why is XP different to what is known
as RAD? OR DSDM? Or Evo? Or RUP? 6.XP promotes good practice,
right? So where is the Process? 7.How does a system programmed via
XP allow changing requirements to be implemented more easily than
in other methods? Getting early feedback will not itself provide
the answers. 8.How does XP help to prevent bugs getting into code
in the first place? You cannot test quality into software; you must
build it in. 9.It assumes very close contact with end users, right?
This is rarer than you might think. And who co-ordinates and
organises and presents the user requirements? Who checks them and
makes sure that they do not invalidate the integrity of the system,
current or proposed? 10.All the XP documentation that I have seen
seems to set it up as the only way to handle changing requirements.
I refer again to point 5 above. 11.How does XP mitigate risk?
Slide 20
20 Woodward on XP 2/3 12.How can XP handle projects with many
man-years of estimated effort? Or many and complex interfaces? 13.
(deleted as redundant) 14.How are the goals of XP different to
those of any other method i.e. to produce software to the customer
on time and to budget? Why should XP have different goals (if they
do)? (Possibly redundant SW) 15.Why should XP make it any easier to
produce quality products than any other method? Why should software
engineering be easy just because the rules are? (Possibly redundant
SW) 16.What s difference between User Stories (XP) and Use Cases +
UML? Why should XP be better in this respect? 17.What is
refactoring and how does it product the most effective
architecture? How does this differ to what we do already? 18.Is XP
telling me that programmers can do effective functional testing in
pairs or otherwise? How? What does XP see as the purpose of
testing? 19.If the Customers are expected to write User Stories and
they do not use some form of precise language then where is the
quality, accuracy, consistency etc built in? Is this not a recipe
for getting all the ambiguities into the code i.e. hacking?
Slide 21
21 Woodward on XP 3/3 20.Don't bother dividing the project
velocity by the length of the iteration or the number of
developers. This number isn't any good to compare two project's
productivity because each project team will have a different bias
to estimating stories and tasks, some estimate high, some estimate
low. It doesn't matter in the long run. Tracking the total amount
of work done during each iteration is the key to keeping the
project on an even keel. I agree you must measure and compare
estimates with actuals to learn! 21.Iterative Development adds
agility to the development process. Divide your development
schedule into about a dozen iterations of 1 to 3 weeks in length.
Gilb says 2%. I think this is arbitrary and a natural size develops
(environmental factors). Team size plays a part see OMAR. 22.Don't
schedule your programming tasks in advance. Instead have an
iteration planning meeting at the beginning of each iteration to
plan out what will be done. It is also against the rules to look
ahead and try to implement anything that it is not scheduled for
this iteration. There will be plenty of time to implement that
functionality when it becomes the most important story in the
release plan. When you never add functionality early and practice
just-in-time planning it is easy to stay on top of changing user
requirements. YUP!iteration planninglook aheadrelease plan 23.What
if the real customers cannot be available?
Slide 22
22 Woodward on XP 3/3 20.Don't bother dividing the project
velocity by the length of the iteration or the number of
developers. This number isn't any good to compare two project's
productivity because each project team will have a different bias
to estimating stories and tasks, some estimate high, some estimate
low. It doesn't matter in the long run. Tracking the total amount
of work done during each iteration is the key to keeping the
project on an even keel. I agree you must measure and compare
estimates with actuals to learn! 21.Iterative Development adds
agility to the development process. Divide your development
schedule into about a dozen iterations of 1 to 3 weeks in length.
Gilb says 2%. I think this is arbitrary and a natural size develops
(environmental factors). Team size plays a part see OMAR. 22.Don't
schedule your programming tasks in advance. Instead have an
iteration planning meeting at the beginning of each iteration to
plan out what will be done. It is also against the rules to look
ahead and try to implement anything that it is not scheduled for
this iteration. There will be plenty of time to implement that
functionality when it becomes the most important story in the
release plan. When you never add functionality early and practice
just-in-time planning it is easy to stay on top of changing user
requirements. YUP!iteration planninglook aheadrelease plan 23.What
if the real customers cannot be available?
Slide 24 7. Better Programmers Programmers do not design
quality into systems Designers, engineers, architects do Good
Programmers will correctly program low quality into a system to
meet bad requirements or design on time
Slide 25
Slide 25 8. Outsourcing Outsourcing will not in itself give you
better software quality You have to contract for it You have to
specify the levels you want You have to confirm you got it
Slide 26
Slide 26 Evolutionary Project Management Contract Modifications
1/2 Design idea: designed to work within the scope of present
contract with minimum modification. An Evo step is considered a
step on the path to delivering a phase. You can choose to declare
this paragraph has priority over conflicting statements, or to
clean up other conflicting statements. 30. Evolutionary Result
Delivery Management. 30.1 Precedence. This paragraph has precedence
over conflicting paragraphs. 30.2 Steps of a Phase. The Society may
optionally undertake to specify, accept and pay for evolutionary
usable increments of delivery, of the defined Phase, of any size.
These are hereafter called Steps. 30.3 Step Size. Step size can
vary as needed and desired by the Society, but is assumed to
usually be based on a regular weekly cycle duration. 30.4 Intent.
The intent of this evolutionary project management method is that
the Society shall gain several benefits: earlier delivery of
prioritised system components, limited risk, ability to improve
specification after gaining experience, incremental learning of use
of the new system, better visibility of project progress, and many
other benefits. This method is the best known way to control
software projects (now US DoD Mil Standard 498. 1994). 30.5
Specification Improvement. All specification of requirements and
design for a phase will be considered a framework for planning, not
a frozen definition. The Society shall be free to improve upon such
specification in any way that suits their interests, at any time.
This includes any extension, change or retraction of framework
specification which the Society needs.
Slide 27
Slide 27 Evolutionary Project Management Contract Modifications
2/2 30.6 Payment for Acceptable Results. Estimates given in
proposals are based on initial requirements, and are for budgeting
and planning purposes. Actual payment will be based on successful
acceptable delivery to the Society in Evolutionary Step deliveries,
fully under Society Control. The Society is not obliged to pay for
results which do not conform to the Society-agreed Step
Requirements Specification. 30.7 Payment Mechanism. Invoicing will
be on a Step basis triggered by end of Step preliminary (same day)
signed acceptance that the Step is apparently as defined in Step
Requirements. If Society experience during the 30 day payment due
period demonstrates that there is a breach of specified Step
requirements, and this is not satisfactorily resolved by the
Company, then a Stop Payment signal for that Step can be sent and
will be respected until the problem is resolved to meet specified
Step Requirements. 30.8 Invoicing Basis. The documented time and
materials will be the basis for invoicing a Step. An estimate of
the Step costs will be made by the Company in advance and form a
part of the Step Plan, approved by the Society. 30.9 Deviation.
Deviation plus or minus of up to 100% from Step cost and times
estimates will normally be acceptable (because they are small in
absolute terms), as long as the Step Requirements are met. (The
Society prioritises quality above cost). Larger deviations must be
approved by the Society in writing before proceeding with the Step
or its invoicing. 30.9 Scope. This project management and payment
method can include any aspect of work which the Company delivers
including software, documentation and training, maintenance,
testing and any requested form of assistance.
Slide 28
A Subcontracting Policy 1. Specifications are to made to give
both us, and the suppliers, the highest degree of flexibility ( for
changes and unforeseen things) to carry out the real intent of the
contract. For example: we shall avoid giving detailed design or
feature lists, when we can control the product or service quality
and performance better by a higher level statement which forces all
necessary detail to happen. For: instead of a list of usability
features, we should make sure we have the measurable testable
usability quality requirements specified. If necessary the proposed
detail can be a variable attachment which itself is not mandatory
but for guidance.
Slide 29
Policy Quality Control All contracts, Requests for proposal and
attached technical specifications will be Inspected using a
rigorous inspection process against our current specification rules
for contracts or whatever document types we are using. Exit (for
signing or reviewing) will be given when it is measured that there
are less than 0.1 major defects/Logical page probably
remaining.
Slide 30
Evo Form for quantified stepwise specs of the quality levels
you want Buyer Requirements Functional Requirements
Benefit/Quality/Performance Requirements Tag:____________ GIST:
__________ SCALE:_____ METER [END STEP ACCEPTANCE TEST] ___
PAST[WHEN?, WHERE?] ___ MUST [when?, where?]____________
PLAN[when?, where?]____________ Tag:____________ AMBITION LEVEL:
__________ SCALE:_____ METER [END STEP ACCEPTANCE TEST] ___
PAST[WHEN?, WHERE?] ___ MUST [when?, where?]____________
PLAN[when?, where?]____________ Resource Constraints: Calendar
Time: Work-Hours: Qualified People: Money (Specific Cost
Constraints for this step): Other Constraints Design Constraints
Legal Constraints Generic Cost Constraints Quality Constraints
Assumptions: Dependencies: Design: Technical Design (for Benefit
Cost requirements) Tag: Description (or pointer to tags defining
it): Expected impacts: Evidence (for expected level of impacts)
Source (of evidence)
Slide 31
Slide 31 9. Deadline Pressure When the deadline is clear and
holy, but the quality is not clear and not holy Deadline will win
You will fail to get the quality you want
Slide 32
Slide 32 10. Define Quality in terms of Bugs in code Do you
define food quality in terms of bugs per liter? The qualities you
and your stakeholders want are many and varied, and bugs is only
one measure, and not the most important one.
Slide 33
Slide 33 11. Re-usable software One client of mine invested on
a very large scale in reusable modules But when it came time to
reuse them over 60% of the modules had far too many bugs in them to
use at all. What is the lesson?
Slide 34
Slide 34 Summary of 10+1 Ways to Fail at Improving Software
Quality 1. Go for CMM Level X 2. Demand Better Testing 3. Use Cases
4. RUP 5. Inspection, Peer reviews, Reviews 6. Extreme Programming
7. Better Programmers 8. Outsourcing 9. Deadline Pressure 10.
Define Quality in terms of Bugs in code 11. Re-usable software
Slide 35
Slide 35 Ten Better Approaches to Improve Software Quality
Better? More effective More efficient (effect/cost) Better proven
documented track record available More direct attack on measurable
quality levels themselves Improve? Quantitative increase in quality
levels attainable at a given cost. Significant increase
Slide 36
Slide 36 10. Evolutionary Testing What is it? All quality
attributes can be measured at each Evo step There are many steps
(about 50 steps) Delivered quality levels are compared to numeric
plans Tracking is done on an impact estimation table Delivery steps
are to real stakeholders, not just testers - Why is it better?
Focus is on total system ( people, data, platforms, real work) not
code alone Early and frequent measurement Opportunity to learn from
small failures and to prevent big ones
Slide 37
37 Philips Evo Pilot May 2001 The GxxLine PXX Optimizer EVO
team proudly presents the success of the Timing Prediction
Improvement EVO steps. Shown are the results of the test set used
to monitor the improvement process. The size of the test set has
grown, as can be seen in the first column. (In the second column
the week number is shown.) We measured the quality of the timing
prediction in percentages, in which 5% means that the prediction by
the optimizer is 5% too optimistic. Excellent quality (5% to +10%)
is given the color green, very good quality quality is yellow, good
quality is orange, & the rest is red. The results are for the
ToXXXz X(i) and EXXX X(i), and are accomplished by thorough
analysis of the machines, and appropriate adaptation of the
software. The GXXline Optimiser Team presented the word document
below to the Business Creation Process review team. The results
were received with great applause. The graphics are based on the
timing accuracy scale of measure that was defined with Jan
verbakel. Classification:Unclassified Frank van Latum, The Manager
36
Slide 38
38 Erieye Project: Inspection Cleanup per Evo Delivery. Getting
all causes of bad quality at early stages The graph shows the total
Major defects/page for all documents types for all inspections in
each delivery. The total number of inspections is 994. Source: Leif
Nyberg, Project manager, Ericsson Sweden, in a case study [Personal
Communication to TG] The deliveries in the graph below are ordered
in time. Observe also that the deliveries differ quite a lot in
size (e.g. numbers 6 and 20 are very small).
Slide 39
39 Value delivery in Omar Project
Slide 40
40 An example of a typical one-week Evo cycle at the HP
Manufacturing Test Division during a project. [MAY96]
Slide 41
41 Impact Table for Step Management
Slide 42
Evo and Requirements, Conceptually Design is what delivers
performance, and costs resource Terminal (functions) Reliability
Usability Storage 1 Storage 2 Other Resources Other Performance One
or more constraints Evo development gradually delivers performance,
while eating up resources by Implementing design 1 1 1 1 1 1 n n 2
2 2 2 2 2 Design X (done on step 1) Design Y (done on step 2)
Design _ (done on step n) Evo development gradually delivers
performance, while eating up resources by Implementing design n n
Design _ (done on step n)
Slide 43
43 Multiple Test Levels of Microsoft Evo Vital 3rd Office 2002
Level 6->10 Weeks Reference: Cusomano: Microsoft Secrets.
Drawing by TG See reference [MacCormack2001]
Slide 44
44 Intel View of Industrial Evo cycle Courtesy: Erik Simmons,
Intel Oregon
Slide 45
Slide 45 9. Defect Prevention Process DPP What is DPP? CMM
Level 5 Continuous Process learning Maybe 2000 small changes per
year (IBM MN) Avoiding defect injection (bad doesnt happen!) 13x
more cost effective than defect removal (Inspection). 50% to 95% of
all defects can be prevented Why is it better for Quality? It
attacks upstream (requirements, design, contracts) It is completely
general (deals with all quality aspects, not just bugs) For more
detail on DPP see Gilb, Software Inspection, Ch 7 & 17 (by
Robert Mays) DPP Inventor
Slide 46
46 The Bottom Line The Bottom Line for Process Improvement...
Appraisal cost Prevention cost 10 20 30 40 50 1987 1988 1989
19901991 1992 Start Improvement Initiative Cost of rework $15.8
million Savings in rework alone ROI = 770% Raymond Dion, Process
Improvement and the Corporate Balance Sheet (July 93) IEEE
Software, July 1993, pp 28-35
Slide 47
47 Reduced Cost of Quality 50% 40% 30% 20% 10% 0%
19881989199019911992199319941995 Philip Crosbys Cost Of Quality
COC=Appraisal + Prevention CONC= cost of fix and check fix (rework)
COC (Cost for doing it right) CONC (Cost of doing it wrong) Cost Of
Quality = COConformance + CONonConformance 65% 23% Cost of
Quality=COC
Slide 48
48 Half-day Inspection Economics. [email protected] Defect
Prevention Experiences: Most defects can be prevented from getting
in there at all % of usual defects prevented Years of continuous
improvement effort 50% 70% 80% 90% Mays & Jones (IBM) 1990 Mays
1993, User 1996 "72% in 2 years" Stakeholder Measure & Study
Results
Slide 76
Slide 76 Some Better Ways to Get Software Quality you might
like to learn more about. 10. Evolutionary Testing 9. Defect
Prevention Process 8. Motivate by Reward for Quality 7. Entry Level
Defect Control: No Garbage In 6. Exit Level Defect Control: No
Garbage Out 5. Quantify Quality Requirements 4. Contract Towards
Quality 3. Reuse Known Quality 2. Evolve Towards Quality 1. Design
to Quality
Slide 77
End of Talk! Next slides are for extra detail later.
Slide 78
Slide 78 A Use Case Critique Summary By Don Mills [Mills01]
This Appendix lists the problems with use cases that I found in my
brief, and unscientific, survey of the literature (a mixture of
books on my and my employers shelves, with articles found by
browsing the Internet). The first eight entries come from the UI
Design.net editorial for October 1999
(http://www.uidesign.net/1999/imho/oct_imho.html).http://www.uidesign.net/1999/imho/oct_imho.html
Solutions to all of the problems exist, but not within the RUP or
the UML (or only clumsily, ambiguously, or inconsistently), while
outside those strictures many competing solutions have been
proposed. Note that this is not intended as an exhaustive
list...
Slide 79
Slide 79 Use Cases ? 1 [The precise role of use cases is
defined in The UML User Guide to be the description of a set of
actions performed by a system to deliver value to a user: that is,
system process design (at the user interface level).] Understanding
the problem -- the business and its rules -- must happen first.
Defining business process, system operating procedures or lines of
communication is secondary. Use Cases lead to definition of
procedures without proper understanding of the problem domain.
Developing Use Cases with a User Group or Business Analyst group
leads to premature interaction design by unskilled practitioners.
Its hard to determine the completeness of Use Cases because of
their single path nature. This can lead to developers using their
imagination to complete exception handling cases or rarely taken
paths. This can quickly ruin a good Interaction Design. Use Cases
do not lend themselves to OO development due to their nature as
procedural descriptions of functional decomposition.
Slide 80
Slide 80 Use Cases ? 2 The User Group defining them are
required to second guess the future system operation. They find
this difficult or even impossible. This leads to new systems which
dont make an adequate improvement in operations procedures and can
miss the opportunity to simplify a process and remove unnecessary
people. Use Cases because of their procedural nature lend
themselves to action-object User Interface designs. If you need or
want to have an object-action UI Design (aka OOUI) then Use Cases
are a poor foundation. Use Cases can end up as the repository for
the whole requirements. Everything goes into the Use Cases and the
Business Analyst group will claim, the design is done already, now
write the code. This is very very bad for Interaction Design. Use
Cases are poor input for Object Modeling. They can lead to poor
definition of classes from noun extraction as you may otherwise be
hoping to eliminate some of the domain terms used within the object
model. The UML Specification is so non-specific and lacking in
obligatory integrity checking that it is easy to produce
fragmentary, inconsistent, ambiguous use cases while still
following an arguably correct interpretation of all of the UMLs
requirements. Cockburn identified 18 different definitions of Use
Cases, yielding over 24 different combinations of Use Case
semantics.
Slide 81
Slide 81 Use Cases ? 3 Use cases do not require backward or
forward traceability of requirements. Standard UML specifications
of use cases, together with descriptions in the Rational Object
Technology Series of publications, lack a number of important
testability elements, such as domain definitions for input and
output variables, testable specifications of input-output
relationships, and sequential and interactional constraints and
dependencies between use cases. Use cases, by definition in the UML
Specification, emphasise ordering (sequences of messages
exchanged... [and] actions performed by the system, V1.3). Physical
sequence of operations is normally a process restriction, not a
true requirement, and when truly required can be defined more
abstractly by preconditions. Early emphasis on ordering is among
the worst mistakes an O-O project can make, but is hard to avoid if
use cases are relied on for analysis, since the UML Specification
provides no standard way of expressing the common situation of
optional or flexible sequences of action. Because the UML can
neither express structure between use cases nor a structural
hierarchy of use cases in an easy and straightforward way, use
cases are developed as an uncoordinated sprawl of (by definition)
discrete and unrelated functions. This creates a loose collection
of separate partial models, addressing narrow areas of the system
requirements, and presenting problems of relating these partial
models and keeping them consistent with each other.
Slide 82
Slide 82 Use Cases ? 4 The UML Specification provides no clear
semantics of what a use case really is (representing a coherent
unit of functionality but representing in what way(s)?), and no
consistent guidelines on how it should be described. This
flexibility may be seen as a good thing, but as the scale of design
problems rises, with larger design teams and more and more use
cases, the sort of studied sloppiness that can be beneficial for
rapid design of modest problems begins to become a stumbling block.
The UML Specification requires a use case to represent actions
performed by the system, but (despite a popular interpretation)
does not restrict these to externally visible actions. It is not
clear what kind of events we should concentrate on while describing
use cases: external-stimuli and responses only, or internal system
activities as well. Use cases may not overlap, occur
simultaneously, or influence one another, although actual uses of a
computer system may do all of these. The level of abstraction of
use cases, and their length, are a matter of arbitrary choice just
enough detail, but not too much. The only level of detail that is
enough is a level that removes all ambiguity.
Slide 83
Slide 83 Use Cases ? 5 Furthermore, no modularisation concepts
are given to manage large use case models. The include and extend
concepts are presented as a means to provide extensibility, but no
rigorous semantics are provided for these concepts, allowing for
multiple disparate interpretations and uses. Use cases in general
are descriptions of specific business processes from the
perspective of a particular actor. As such they do not give a clear
picture of the overall business context and imperatives that
actually generate the requirements for these business processes.
This means that they can be quite incomprehensible to non-domain
experts. For the same reasons, the important business requirements
and imperatives underlying the use case model become invisible when
taken out of business context and expressed in discrete use cases.
Subsequent readers of the use case model may be quite unable to
explain the forces and business requirements that shaped the model.
Developing Use Cases with a User Group or Business Analyst group
leads to a focus on how users see the systems operation. But the
system doesnt exist yet. (A previous system might exist, but if it
were fully satisfactory you would not be asked to change or rewrite
it.) So the system picture that use cases will present is based on
existing processes, computerised or not. The system builders task
is to come up with new, better scenarios, not to perpetuate
antiquated modes of operation.
Slide 84
Slide 84 Use Cases ? 6 of 6 slides A UML use case model cant
specify interaction requirements where the system initiates an
interaction between the system and an external actor. Because the
UML Specification forbids interactions between actors, use cases
cannot model a rich system context involving such interactions. The
UML requires use cases to be independent of one another, which
means that it offers no way to model persistent state across use
cases, or to identify how the initial system state required by a
use case (specified in Pre-conditions) is to be achieved.
Slide 85
Slide 85 References 1 RPL: www.result-planning.com (Gilb
site)www.result-planning.com Requirements Slides Evo method slides
Inspection slides and papers Planguage Glossary (part of CE book)
CE: Competitive Engineering book by Tom Gilb Forthcoming 2002
Addison Wesley A systems engineering and software engineering
handbook, based on Planguage. (parts at www.result-planning.com)
Inspection: GG: Gilb and Graham: Software Inspection (1993) RR:
Ronald A. Radice: High Quality Low Cost Software Inspections 2002,
Paradoxicon Publishing, Andover MA, USA PoSEM: Gilb: Principles of
Software Engineering Management (1988, Addison Wesley)
Slide 86
Slide 86 References 2 RUPSE: Rational Unified Process for
Systems Engineering RUP SE1.0 A Rational Software White Paper
(possibly avialble via www.rational.com?) TP 165, 8/01 This paper
attempts to tackle the problem of system architecture for multiple
quantified quality requirements. TG It fails in that it is not
dealing with multiple quality requirements simultaneously, and is
not doing much more than arm waving.It does not do what I would
calla good job of quantifying quality. It does not do a good job of
what I would consider showing the releation between a design and
multiple qualities and costs. But it is the best attempt to
recognize the need and the problem to come out of Rational so far.
TG Mills01:Whats the Use of a Use Case? Don Mills Copyright
Software Education Associates Ltd Wellington, New Zealand, 2001
Should be available at www.softed.comShould be available at
www.softed.com [MacCormack2001] Evo in MIT Sloan Review Winter 2001
Product-Development Practices That Work: How Internet Companies
Build Software
Slide 87
Slides added after printed documentation made for
conference
Slide 88 I think you are conflating two concepts--how you
cre"> I think you are conflating two concepts--how you create a
process and how > you create a community to use the process.
> > I was quite "scientific" in my creation of XP. First I
read voraciously and > asked lots of questions about a topic.
Then I experimented with a technique > myself, generally to
extremes so I understood the range of possible > behavior.
Whatever worked best for me I taught to a few people I trusted. If
> they reported good results I taught it to people I didn't
know. Only if they > reported good results would I begin
recommending the practice in speeches > and in print. I tried
combinations of practices (not exhaustively, but I > tried to be
aware of interactions when they occurred). > > I put
"scientific" in quotes above, because it isn't science like physics
is > science, but it is science as described by Sir Francis
Bacon, and as > contrasted to Aristotelian pure reasoning. My
notebooks certainly wouldn't > survive review by a physical
scientist. But we aren't in the physical > science business.
> > Now I had some tested ideas, and I was ready to see them
implemented on a > large scale (we can get into motivation
later). Given my resources, viral > marketing driven by
storytelling was the only option. > > Does that answer your
question? Return to main sequence"> I think you are conflating
two concepts--how you cre" title="88 Kent Beck eXtreme Programming
(QUOTED WITH PERMISSION) On 18/01/02 14:25, "Kent Beck" wrote: >
I think you are conflating two concepts--how you cre">
88 Kent Beck eXtreme Programming (QUOTED WITH PERMISSION) On
18/01/02 14:25, "Kent Beck" wrote: > I think you are conflating
two concepts--how you create a process and how > you create a
community to use the process. > > I was quite "scientific" in
my creation of XP. First I read voraciously and > asked lots of
questions about a topic. Then I experimented with a technique >
myself, generally to extremes so I understood the range of possible
> behavior. Whatever worked best for me I taught to a few people
I trusted. If > they reported good results I taught it to people
I didn't know. Only if they > reported good results would I
begin recommending the practice in speeches > and in print. I
tried combinations of practices (not exhaustively, but I > tried
to be aware of interactions when they occurred). > > I put
"scientific" in quotes above, because it isn't science like physics
is > science, but it is science as described by Sir Francis
Bacon, and as > contrasted to Aristotelian pure reasoning. My
notebooks certainly wouldn't > survive review by a physical
scientist. But we aren't in the physical > science business.
> > Now I had some tested ideas, and I was ready to see them
implemented on a > large scale (we can get into motivation
later). Given my resources, viral > marketing driven by
storytelling was the only option. > > Does that answer your
question? Return to main sequence
Slide 89
89 CMM Level 3 Results
Slide 90
Slide 90 This is the last slide of the set of slides!