1. Project Planning Copyright, 2002 © Jerzy R. Nawrocki Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/mse/require/ Requirements Engineering Lecture 12 Requirements Engineering Lecture 12

2. J. Nawrocki, Requirements Eng. (12) Plan of the lecture Planning at CMM Level 2 Risk Management

3. J. Nawrocki, Requirements Eng. (12) IntroductionIntroduction Documented procedures for.. developing an SDP estimating size, effort, cost, critical computer resources, and schedule planning SQA activities planning SCM...

4. J. Nawrocki, Requirements Eng. (12) IntroductionIntroduction Product measures Process measures SizeEffort Cost (not applicable?) (Computer) resources Delivery date (schedule) Measures at CMM Level 2

5. J. Nawrocki, Requirements Eng. (12) AbilitiesAbilities Ab2. Responsibilities for developing the software development plan are assigned. The project manager co-ordinates the project’s planning. Responsibilities for the software work products and activities are partitioned and assigned to in a traceable, accountable manner.

6. J. Nawrocki, Requirements Eng. (12) AbilitiesAbilities Ab3. Adequate resources and funding are provided for planning the project. Is it enough?

7. J. Nawrocki, Requirements Eng. (12) AbilitiesAbilities Ab4. The software managers, software engineers, and other individuals involved in the  software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility.

8. J. Nawrocki, Requirements Eng. (12) ActivitiesActivities Ac4. Software project commitments made to individuals and groups external to the organisation are reviewed with senior management (A.W. or B.W.) according to a documented procedure.

9. J. Nawrocki, Requirements Eng. (12) ActivitiesActivities Ac5. A software life cycle with predefined stages of manageable size is identified or defined.

10. J. Nawrocki, Requirements Eng. (12) ActivitiesActivities Ac6. The project’s software development plan is developed according to a documented procedure.  How to write SDP

11. J. Nawrocki, Requirements Eng. (12) ActivitiesActivities The SDP is based on the customer’s and project’s standards, IPD, and SRS. Plans are negotiated with the affected groups (3rd year!). The agreements are documented. The SDP is reviewed, and managed and controlled.  How to write SDP The planning procedure at PUT

12. J. Nawrocki, Requirements Eng. (12) ActivitiesActivities  How to write SDP The planning procedure at PUT The SDP is approved by the Project Area Manager (Bartek or Adam). The SDP is available through the project’s web page along with all the previous versions of it. That web page is referenced in the Initial Project Description (IPD).

13. J. Nawrocki, Requirements Eng. (12) ActivitiesActivities Ac7. The plan for the software project is documented.  SDSD P

14. J. Nawrocki, Requirements Eng. (12) Plan of the lecture Planning at CMM Level 2 Risk Management

15. J. Nawrocki, Requirements Eng. (12) IntroductionIntroduction What is a risk?

16. J. Nawrocki, Requirements Eng. (12) IntroductionIntroduction Two approaches to risk Reactive Proactive

17. J. Nawrocki, Requirements Eng. (12) Risk description IntroductionIntroduction Probability Impact catastrophic critical marginal negligible

18. J. Nawrocki, Requirements Eng. (12) RMMM IntroductionIntroduction RMMM = Risk Mitigation, Monitoring, and Management Mitigation= minimising the probability Monitoring= observing factors/indicators Management= if it happens..

19. J. Nawrocki, Requirements Eng. (12) Risk analysis IntroductionIntroduction IBM: > 100 risk factors For each risk factor an MMM plan. Risk management becomes a project in itself! Pareto analysis: the 80-20 principle

20. J. Nawrocki, Requirements Eng. (12) Selected risk factors General Poor planning Poor configuration control Poor progress tracking Poor quality assurance Poor requirements Poor development Risk areas

21. J. Nawrocki, Requirements Eng. (12) Selected risk factors Corporate politics (at client side) Crowded office conditions (< 9 m 2 ) Excessive paperwork (> 50 docs, > 6 pages/FP) Friction with client or senior management Lack of specialisation Low productivity (?) Low quality ( -> Poor QA) Low user satisfaction Malpractice (Management) General

22. J. Nawrocki, Requirements Eng. (12) Selected risk factors Inaccurate sizing of software deliverables Inadequate risk analysis Inadequate tools and methods Lack of reusable estimates Lack of reusable project plans Missed schedules (unrealistic schedules; schedules not updated after changes; inadequate planning methods; lack of historical data from past projects) Partial life-cycle definitions Poor planning

23. J. Nawrocki, Requirements Eng. (12) Selected risk factors Inadequate configuration control Schedules not updated after changes Poor configuration control

24. J. Nawrocki, Requirements Eng. (12) Selected risk factors Inadequate measurement Inadequate tools and methods Poor progress tracking

25. J. Nawrocki, Requirements Eng. (12) Selected risk factors Inadequate software policies and standards Inadequate tools and methods (QA) Lack of reusable test plans and test cases Poor quality assurance

26. J. Nawrocki, Requirements Eng. (12) Selected risk factors Creeping requirements Lack of reusable requirements Poor requirements

27. J. Nawrocki, Requirements Eng. (12) Selected risk factors Inadequate tools and methods (Soft.Eng., Tech. Documentation) Lack of reusable components (architecture, code, design, doc, human interfaces) Malpractice (technical staff) Poor development

28. J. Nawrocki, Requirements Eng. (12) Selected risk factors A team member stops his studies A team member passes his exams in April A team member is late is project tasks (e.g. he is ill) Customer representative is not available The tools are not available or not working There is a computer/disk crash Team members are not satisfied (e.g. The work is boring) The acceptance criteria are not clear SDS specific risks

29. J. Nawrocki, Requirements Eng. (12) SummarySummary Planning at CMM Level 2 Risk is described by three elements: name, probability, impact. Selected risk factors (SDS specific risk factors)

30. J. Nawrocki, Requirements Eng. (12) Further readings  [CMM] M.C. Paulk et. al.,The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading, 1994. [Jon] Capers Jones, Assessment and control of software risks, Prentice Hall, Englewood Cliffs, NJ, 1994. [Pres] Roger Pressman, Software Engineering. A Practitioner’s Approach, McGraw Hill, 1997.

31. J. Nawrocki, Requirements Eng. (12) Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how?