Ten Quality Methods which probably won't improve product quality; and ten quality methods that more...

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

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. "

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

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

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

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.

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!)

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!

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.

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.

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

RUP SE Example of dealing with quality [RUP]

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%)

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

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

16 Kent Beck XP

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

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]

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?

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?

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?

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?

23 Stuart Woodward comments XP [email protected]

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

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

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.

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.

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.

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.

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)

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

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.

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?

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

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

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

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

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).

39 Value delivery in Omar Project

40 An example of a typical one-week Evo cycle at the HP Manufacturing Test Division during a project. [MAY96]

41 Impact Table for Step Management

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)

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]

44 Intel View of Industrial Evo cycle Courtesy: Erik Simmons, Intel Oregon

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

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

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

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

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

End of Talk! Next slides are for extra detail later.

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...

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.

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.

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.

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.

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.

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.

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)

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

Slides added after printed documentation made for conference

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

89 CMM Level 3 Results

This is the last slide of the set of slides!

Ten Quality Methods which probably won't improve product quality; and ten quality methods that more...

Documents

Transcript of Ten Quality Methods which probably won't improve product quality; and ten quality methods that more...