Comparison of Change Management Systems

More documents

Recommendations

Info

42 Software Engineering Usability.Intuitiveness: Type: Marketing Product Quality Re- quirement. Ambition: Any potential user, any age, can immediately discover and correctly use all functions of the product, without training, help from friends, or external documentation. Scale: % chance that defined [User] can successfully complete defined [Tasks] with no external help. Meter: Consumer reports tests all tasks for all defined user types, and gives public report. Goal [Market = USA, User = Seniors, Product = New Version, Task = Photo Tasks Set, When = 2012]: 80% ±10%
stop. This is a slight variation on the ‘5 Whys’ technique [11], which is normally used to identify root causes of problems (rather than high-level requirements). Assume that our stakeholders will usually state their values in terms of some perceived means to get what they really value. Help them to identify (The 5 Whys?) and to acknowledge what they really want, and make that the ‘official’ requirement. Don’t insult them by telling them that they don’t know what they want. But explain that you will help them more-certainly get what they more deeply want, with better and cheaper solutions, perhaps new technology, if they will go through the ‘5 Whys?’ process with you. See Figure 9. Why do you require a ‘password’? For Security! What kind of security do you want? Against stolen information. What level of strength of security against stolen information are you willing to pay for? At least a 99% chance that hackers cannot break in within 1 hour of trying! Whatever that level costs up to €1 million. So that is your real requirement? Yep. Can we make that the official requirement, and leave the security design to both our security experts, and leave it to proof by measurement to decide what is really the right design? Of course! The aim being that whatever technology we choose, it gets you the 99%? Sure, thanks for helping me articulate that! Figure 9 Example of the requirement, not the design feature, being the real requirement Note that this separation of designs from the requirements does not mean that you ignore the solutions/designs/architecture when software engineering. It is just that you must separate your requirements - including any mandatory means - from any optional means. The key thing is Figure 10 to understand what is optional so that you consider alternative solutions. See Figure 10, which shows two alternative solutions: Design A with Designs B and C, or Design A with Design D. Assuming that say, Design B was mandatory, could distort your project planning. Figure 10 A graphical way of understanding performance attributes (which include all qualities) in relation to function, design and resources. Design ideas cost some resources, and design ideas deliver performance (including system qualities) for given functions. Principle 6. Capture explicit information about value How can we articulate and document notions of value in a requirement specification? See the example for Intuitiveness, a component quality of Usability, given in Figure 11, which expands on Figure 6. Usability.Intuitiveness: Type: Marketing Product Requirement. Stakeholders: {Marketing Director, Support Manager, Training Center}. Impacts: {Product Sales, Support Costs, Training Effort, Documentation Design}. Supports: Corporate Quality Policy 2.3. Ambition: Any potential user, any age, can immediately discover and correctly use all functions of the product, without training, help from friends, or external documentation. Scale: % chance that a defined [User] can successfully complete the Software Engineering defined [Tasks] , with no external help. Meter: Consumer Reports tests all tasks for all defined user types, and gives public report. Analysis Trend [Market = Asia, User = {Teenager, Early Adopters}, Product = Main Competitor, Projection = 2013]: 95%±3%
Page 1: Engineering Productivity: Some ways
Page 4 and 5: 04 Welcome Editor’s note Quarterl
Page 6 and 7: 06 Management Agile software develo
Page 8 and 9: 08 Management driven development—
Page 10 and 11: 10 Management for are developing. O
Page 12 and 13: 12 Management Important factor here
Page 14 and 15: 14 Management behavior. They all lo
Page 16 and 17: 16 Management Figure 2 - Buffer man
Page 18 and 19: 18 Quality in Project Productivity
Page 20 and 21: 20 Quality in Project Engineering O
Page 22 and 23: 22 Quality in Project For example i
Page 24 and 25: 24 Quality in Project measure of en
Page 26 and 27: 26 Quality in Project Figure 1 What
Page 28 and 29: 28 Quality in Project early complet
Page 30 and 31: 30 Software Engineering Comparison
Page 32 and 33: 32 Software Engineering has a poor
Page 34 and 35: 34 Software Engineering or function
Page 36 and 37: 36 Software Engineering Let’s loo
Page 38 and 39: 38 Software Engineering What’s fu
Page 40 and 41: 40 Software Engineering Note, unles
Page 44 and 45: 44 Software Engineering Figure 11 A
Page 46 and 47: 46 Software Engineering cyclical le
Page 48 and 49: 48 Software Testing motivating if t
Page 50 and 51: 50 Software Testing This concept of
Page 52 and 53: 52 Software Testing defects, or the
Page 54 and 55: 54 Software Testing 5. A Critical M
Page 56 and 57: 56 Software Testing Equivalence par
Page 58 and 59: 58 Software Testing little more com
Page 60 and 61: 60 Software Testing Good, now let
Page 62 and 63: 62 Software Testing an important pa
Page 64 and 65: 64 Software Testing the software de
Page 66 and 67: 66 Software Testing Five Types of R
Page 68 and 69: 68 Software Testing Figure 2 A typi
Page 70 and 71: 70 Software Testing Figure 4 Typica
Page 72 and 73: 72 Software Testing Confrontation o
Page 74 and 75: 74 Software Testing Quality Managem

Comparison of Change Management Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?