Management I:

1. Management I:

2. implement traceability Manage evolution validate requirements Requirements Management Elicit requirements Requirements Model requirements

3. Why Metrics are important • Without metrics we can not communicate in a precise manner. “ When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you can not measure it, and when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind.“ (Lord Kelvin) http://www.groups.dcs.stand.ac.uk/~history/Mathematicians/Thomson.html • The requirements process (as well as the whole software development process) must have associated metrics, to allow one to demonstrate benefits in a transparent way.

4. Configuration Management • Change Control • Version Control • Access to different configurations

5. Definitions • Component (artifact) version • component + modifications • Temporal axis • Initial component (1a. Version) • Software Version (release) • Set of components taken at a specific point in time • Configuration • Selection of components that are part of a determined set (Ex: components of release 3.1)

6. Configuration Management • Advantages • Avoid potentially destructive or frivol changes on requirements • Keep/maintain updated revisions of requirements documentation • Facilitate the recovery and reconstruction of previous versions • Offer support to a configuration strategy for new versions • Prevent simultaneous changes

7. Version Control • Coordinate and manage objects in evolution • Successive Refinements • requirements • models • code • Keep intermediary versions • Log of changes

8. Example Configuration V Version Configuration IV Configuration III Configuration II Configuration I Configuration Where C – Scenario V - Version

9. Management • Escope • Changes • Risc • Traceability • Prioritization

10. Requirement Management • Manage Requirements is to ensure all clients requests are being examined during the SDLC • For this it is essential that such requests are related to software products (requirements allocation)

11. Requirement Management • It is orthogonal to the process of requirements definition (elicitation, modelling and analysis) • Supervene the whole process of software development and evolution

12. Requirements Management

13. ESCOPE RESOURCES Time Due Date What is Scope? • Combination of functionality, resources and time

14. Scope • Problems: • NFR: May consume a big portion of time and resources • Not all resources are available or are known at the beginning • Typical culture that software is always LATE • (time) – save time is an illusion !!! • “Add people to a late project will only get this project worst” Brooks

15. Controlling the scope • “Since” Syndrome – keep adding requirements • Caper Jones reports that requirements that “crawl under the scope” represent • risk of 80% to information system projects • risk of 70% to military projects

16. Controlling the scope • Crawling Requirements • New functionality • modifications • requirements • bigger scope SAY NO !!!

17. What is Prioritize? [Wiegers] • Trade off between: • scope • time • resources • Assure that the Essential is done

18. Why prioritize? • High Expectations • Short Time • Limited Resources • Saying: “We do what we can not what we want”

19. Prioritization techniques • Formal • QFD • Informal • CAN 100 • Categorize

20. QFD (quality function deployment) • Participants: • Manager • Key figures • developers [Cohen95/Wiegers]

21. QFD • Steps of the process: 1. List in a spreadsheet the requirements, functionality or use cases that you want to prioritize 2. Estimate the relative benefit of each one using a 1-9 scale, where 1 means a neglectable one and 9 a grate value requirement

22. QFD 3. Estimate the penalty the client or the business will suffer if the requirements is not included. 1 means a minimum penalty while 9 means a huge loss 4. Create a column - total value – which represents the sum of the benefit and penalty 5. Use a spreadsheet to calculate the percentage of the total value that each item represents (value%)

23. QFD 6. Estimate the implementation cost for each item also using a 1(low) to 9 (High) scale 7. Use the spreadsheet to calculate the percentage of the total cost each item represents (cost%) 8. Estimate the risk each item represents using a 1 to 9 scale 9. Use the spreadsheet to calculate the percentage of the total risk that each item represents (risk%)

24. QFD • Once we have all the estimative: • Organize the item using a descending order in priority Priority = value%____________ (cost%*cost)+(risk%*risk)

25. QFD Critics: • Semi-quantitative method • Not very precise • Depends on personal skills. How well one can estimate benefits, cost and risk

26. Informal Techniques [Leffingwell] CAN 100 • Carried out during a meeting • Each participant is given CAN 100 to spend buying requirements • Write in a piece of paper how much money you would spend in each requirement • Tabulate results • Requirements ranking

27. Informal Techniques Categorization • off line • Each interested part gets a list of requirements • Classify according the following criteria • Critical – indispensable • Important – represents loss of functionality or loss off market share • Useful – makes life easier • Set values 1,2 or 3 (where 1 is critical) • Make a ranking with the results

28. Risk Management • Occurrences that may impact the project • Combination of probability and type of consequence • processes: • identification • Weighing • planning • control

29. Identifying Risks • Conditions, activities, decisions that may affect the success of the project • Types of risk • scope (larger/smaller) • evolution • resources • Personal (outsourced, partners, employees) • New technologies • NFR (very tight (rigid) constraints)

30. Identifying risks • Risk Levels • intolerable • Acceptable if reduction is out of question • Acceptable • negotiable

31. Weighing risks • Probability • low • Very low • high • Very high • Risk list sorted by probability • Risk list sorted by level of risk, type and probability

32. Risk List Risk level Type of Risk probability Risk description

33. Planning • Detecting the sooner the possible from top of the list (level, probability) • alternatives for correction • alternatives to live with

34. Control • Verification points between the global plan and the risk list • Responsibilities • Action (following alternatives)

35. Link Requirements to software components • Also called Traceability, because it must allow one to browse through software products, including the requirements, regarding clients demands.

36. Lel entry: Room / RoomsNotion: Part of a hallway section . A room can be a computer lab , an office , a hardware lab , a meeting room, and or a peripheral room . Behavioral responses: All rooms in a hallway section can be accessed via a connected hallway sectionFor each room , the chosen light scene can be set by using the room control panel For each room , the default light scene can be set by using the roomcontrol panel . For each room , the value of T1 can be set by using the roomcontrol panel . Exemple: User occupies room - Version 1 Goal: establish the procedure for occupied roomContext: 4th floor of building 32 , motion detector in order, user entered roomResource: value T1Default light scene for this room, Chosen light scene valueActors: user, Control system Episodes: 1. user enters room2. user chooses light scene3. IF room is reoccupied wihtin T1 minutes THEN activate last Chosen light scene 4.IF room is reoccupied after T1 minutes THEN activate Default light scene

37. User occupies room - Version 3 Goal : establish the procedure for occupied roomContext: 4th floor of building 32 , motion detector in order, user entered roomResource: value T1, outdoor light sensor last correct management value, Default light scene for this room, Chosen light scene value, Actors: user, Central Control, outdoor light sensor , Control panel, roomEpisodes: 1. user enters room2. In case of malfunction , outdoor light sensor sends last correct measurement to room3. user chooses light scene using the Control panel Exception: user input is not reasonable4. IF room is reoccupied wihtin T1 minutes THEN activate last Chosen light scene stored in room5. IF room is reoccupied after T2 minutes THEN activate Default light scene stored in room LEL entry: Room/RoomsNotion:CRC card corresponding to the concept of a roomBehavioral responses:keep the outdoor light sensor measurements store value T1IF room is reoccupied within T1 minutes THEN activate last chosen light sceneIF room is reoccupied after T1 minutes THEN activate default light scenestore chosen light scenestore moment when person left the room

38. How can we keep register of the relationships between scenario versions and corresponding versions of the lexicon ? Traceability

39. Requirements traceability • Definition: • Ability to follow the life of a requirements • Pre e pos traceability • Implicit and explicit • Internal (to the artifact) and external

40. Pre e pos traceability

41. Pre e pos traceability • Pre traceability: • Before adding to the requirements document • Where it comes from? • Who suggested? • Why? • pos traceability: • After something is added to the requirements document

42. problem REQUIREMENTS Req. Doc Version 1 UofD Req. Document definition Req. Doc Version 3 Req. Doc. Version 2 a e c design j g b software implementation d f i h maintenance Pre Traceability Pos traceability

43. Implicit and explicit • Explicit • Shows the relationship among artifacts • Develop/create relationships from external considerations given by team members • implemented (link or explicit indicator) • Implicit • artifacts show indicative • The relationship among artifacts is manually done by whom is interested

44. Example OO Model

45. Why Tracing ??? • Follow requirements evolution during development; register status of each requriements relating it to development, accepted changes and associated justifications • Stablish a common view between the client and the development team as for which requirements will be met. Project Management

46. Why trace??? • Changes in requirements during the development process are natural; • motives: needs not identified before; changes in the context; errors fixing; new perspectives from the stakeholders; • Changes in requirements may implicate changes in design, code, use case tests etc. Managing Changes

47. Why Trace??? • Aspects related to quality: CMM, CMMI, ISO 9001 • CMMI: continued modes in levels (staged): staged is similar to CMM, but includes KPAs (Key Process Areas) as well as some changes • KPAs level 2 in CMM are strongly related to ISO 9001 Quality Assurance

48. Internal X External • Internal • Relationship between artifacts of the same type • For example: scenarios • Other scenarios • Other versions of the same scenario • External • Relationship between different artifacts • Example: scenarios and class diagram • Example: requirement and Java code

49. traceability (vertical) Level 1 Solicitations: Requirements: Level 2 Especification: Level 3 Design: Level 4

50. Traceability (matrix) Software Requirements Compo- nents R1 R2 R3 ... C1 X X C2 X C3 ...