1. Project Planning Copyright, 2002 © Jerzy R. Nawrocki Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/mse/quality/ Quality Management Auxilliary Material Quality Management Auxilliary Material

2. J. Nawrocki, Project Planning IntroductionIntroduction CMM Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management CMM Level 2 - Repeatable

3. J. Nawrocki, Project Planning IntroductionIntroduction Documented procedures for.. developing an SDP estimating size, effort, cost, critical computer resources, and schedule planning SQA activities planning SCM...

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

5. J. Nawrocki, Project Planning Work products IPD Concept of the system SRS (Intermediate) design Implementation (a set of modules) Acceptance tests Bachelor thesis Specification Implementation idea Code Test bed Test cases

6. J. Nawrocki, Project Planning AbilitiesAbilities Ab1. A documented and approved statement of work exists for the software project.

7. J. Nawrocki, Project Planning AbilitiesAbilities Scope of the work Technical goals and objectives Identification of customers & end users Imposed standards Assigned responsibilities Cost and schedule constraints and goals Statement of Work (I)

8. J. Nawrocki, Project Planning AbilitiesAbilities Dependencies between the software project and other organisations (customer, subcontractors, j.v. partners) Resource constraints Other constraints Statement of Work (II) Statement of work is reviewed. It is managed and controlled.

9. J. Nawrocki, Project Planning 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.

10. J. Nawrocki, Project Planning AbilitiesAbilities Ab3. Adequate resources and funding are provided for planning the project. Is it enough?

11. J. Nawrocki, Project Planning 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.

12. J. Nawrocki, Project Planning ActivitiesActivities Ac1. The software engineering group participates on the project proposal team. The software engineering group reviews the proposed commitments.

13. J. Nawrocki, Project Planning Overall planning ActivitiesActivities Ac2. Software project planning is initiated in the early stages of, and in parallel with, the overall project planning. Software planning At PUT: software project = overall proj.

14. J. Nawrocki, Project Planning ActivitiesActivities Ac3. The software engineering group participates with other affected groups in the overall project planning throughout the project’s life. The software engineering group reviews the project-level plans.

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

16. J. Nawrocki, Project Planning ActivitiesActivities Ac5. A software life cycle with predefined stages of manageable size is identified or defined.

17. J. Nawrocki, Project Planning ActivitiesActivities IPD Concept of the system (scenarios) Soft. requirements specification Conceptual design & detailed planning Release 1 (from reqs to acceptance) Release 2 Final acceptance (bachelor degree) Software life cycle at PUT

18. J. Nawrocki, Project Planning ActivitiesActivities Ac6. The project’s software development plan is developed according to a documented procedure.  How to write SDP

19. J. Nawrocki, Project Planning 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

20. J. Nawrocki, Project Planning 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).

21. J. Nawrocki, Project Planning ActivitiesActivities Ac7. The plan for the software project is documented.  SDSD P

22. J. Nawrocki, Project Planning Wide-band Delphi method Rand Corporation, Boehm’81 A few experts individually produce size estimates. A Delphi process is used to reach a consensus. Pythia

23. J. Nawrocki, Project Planning Wide-band Delphi method 1. Experts get the specification and an estimation form 2. They meet for discussion (project goals, assumptions, estimation issues) 3. Each expert anonymously lists the tasks and estimates the size 4. The estimates go to the estimate moderator. He tabulates the results and returns them to the experts. The Delphi procedure The estimate moderator

24. J. Nawrocki, Project Planning Wide-band Delphi method Estimator: Jerzy Nawrocki Date: 22.06.1999 Project: Sorting routine The estimates from the 1st round: e E M e e 0 20 40 60 80 100 e - estimates, E - your estimate, M - median estimate Your estimate for the next round:......... LOC A rationale for your estimate:.........................................................................................................................................

25. J. Nawrocki, Project Planning Wide-band Delphi method 5. The experts meet to discuss the results. They review the tasks they have defined but not their size estimates. 6. The procedure is repeated from step 3 until the estimates are acceptably near The Delphi procedure The estimate moderator

26. J. Nawrocki, Project Planning IntroductionIntroduction What is a risk?

27. J. Nawrocki, Project Planning IntroductionIntroduction Two approaches to risk Reactive Proactive

28. J. Nawrocki, Project Planning Risk description IntroductionIntroduction Probability Impact catastrophic critical marginal negligible

29. J. Nawrocki, Project Planning RMMM IntroductionIntroduction RMMM = Risk Mitigation, Monitoring, and Management Mitigation= minimising the probability Monitoring= observing factors/indicators Management= if it happens..

30. J. Nawrocki, Project Planning 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

31. J. Nawrocki, Project Planning Selected risk factors General Poor planning Poor configuration control Poor progress tracking Poor quality assurance Poor requirements Poor development Risk areas

32. J. Nawrocki, Project Planning 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

33. J. Nawrocki, Project Planning 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

34. J. Nawrocki, Project Planning Selected risk factors Inadequate configuration control Schedules not updated after changes Poor configuration control

35. J. Nawrocki, Project Planning Selected risk factors Inadequate measurement Inadequate tools and methods Poor progress tracking

36. J. Nawrocki, Project Planning Selected risk factors Inadequate software policies and standards Inadequate tools and methods (QA) Lack of reusable test plans and test cases Poor quality assurance

37. J. Nawrocki, Project Planning Selected risk factors Creeping requirements Lack of reusable requirements Poor requirements

38. J. Nawrocki, Project Planning 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

39. J. Nawrocki, Project Planning 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

40. J. Nawrocki, Project Planning SummarySummary Work products and their measures The planning procedure Wide-band Delphi Method Risk is described by three elements: name, probability, impact.

41. J. Nawrocki, Project Planning 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.

42. J. Nawrocki, Project Planning 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?