Software Engineering I Session 9

1. Software Engineering ISession 9 Software Project Management and Planning

2. Software Engineering and Project Management • Software engineering, as a discipline, is concerned with both the technical and project management aspects of software development. • The technical aspect of software engineering is focused on individual technical skills. • The project management aspect of software engineering is focused on activities with project wide scope, • such as planning, risk management, people management, budget control, etc.

3. Today • You are a software project manager • Not a software engineer (programmer, testing engineer, requirement analyst, …)

4. Software Project Management • The primary objectives of software project management are to: • Deliver the software to the customer on time (time) • Keep overall costs within budget (cost) • Deliver software that meets customer expectations (quality) • Maintain a coherent and well-functioning development team (person)

5. Software Project Management • Software project management shares many similarities with project management in other engineering disciplines. • However, several key factors make software engineering different from other disciplines • make software project management particularly challenging: • The product is intangible. • Projects are often one-off. • Software processes are variable and organisation specific.

6. Software Project Management • Project managers may work in quite different ways • There are several cornerstone activities that are common to all software project management endeavours: • Risk management • Project planning • scheduling and costing • Proposal writing • People management • Reporting • Software project management practices tend to differ from organisation to organisation. • Factors influencing difference in organisational practice include: • Organisation size • Customer demands • Software size • Software type • Organisational culture • Software development processes

7. Risk management

8. Risk Management • Risk management is concerned with • identifying threats to project success and • drawing up plans to eliminate those threats or minimise their effect. • Risks can be categorised as follows:

9. Examples of project, product, and business risks

10. The risk management process (IAPM) • Risk identification • Identify project, product and business risks; • Risk analysis • Assess the likelihood and consequences of these risks; • Risk planning • Draw up plans to avoid or minimise the effects of the risk; • Risk monitoring • Monitor the risks throughout the project;

11. Risk Identification • A checklist of common risks may be used to identify actual risks in a project，including: • Technology risks • Organisational risks • People risks • Requirements risks • Estimation risks • Identified risks should be added to a risk register.

12. Examples of different risk types

13. Risk Analysis • In risk analysis, identified risks should be ranked on the basis of their probability/likelihood and their likely effect/impact.

14. Risk types and examples (1)

15. Risk types and examples (2)

16. Risk Planning • Risk planning firstinvolves deciding which risks to manage: • No risks are acceptable: all risks should be managed. • Low risks are acceptable: only medium and high risks should be managed. • Low and medium risks are acceptable: only high risks should be managed. • Risk planning also involves the choice of one of the following risk management strategies: • Avoidance (Stop the risk arising). • Minimisation (Reduce the impact). • Contingency plans (Deal with the risk outcome).

17. What-if questions • What if several engineers are ill at the same time? • What if an economic downturn leads to budget cuts of 20% for the project? • What if the performance of open-source software is inadequate and the only expert on that open source software leaves? • What if the company that supplies and maintains software components goes out of business? • What if the customer fails to deliver the revised requirements as predicted?

18. Strategies to help manage risk (1)

19. Strategies to help manage risk (2)

20. Risk Monitoring • Risk management is not a one-off activity • Risk monitoring is a process of checking that • The assumption about the product, process, and business risks have been changed • Existing risks should be regularly reassessed • changes to their likelihood? • changes of their potential impact? • New risks should be identified, analysed and managed.

21. Risk indicators

22. Project planning

23. Project Planning • The project plan is a formal, approved document • used to guide both project execution and project control. • The primary uses of the project plan are to: • Document planning assumptions and decisions • Facilitate communication among project stakeholders • Document approved scope, cost, and schedule baselines • Measure progress • Project planning is axiomatic to project success. • Project planning involves: • Breaking down the overall task into manageable sub-tasks. • Assigning sub-tasks to project team members. • Anticipating problems that might arise and • preparing tentative solutions to those problems.

24. Planning Stages • Project planning is an ongoing and iterative activity • takes place at different stages in the project lifecycle

25. Detailed Planning • In addition to planning the project schedule, risk management and resource allocation, software project planning will generally involve one or more of the following: • Test planning • Configuration management planning • Deployment planning • Quality assurance planning • Maintenance planning.

26. Approaches to Planning • The approach to planning used for a project is entirely determined by the preferred software process model. • Projects using plan-driven approaches to software development require detailed, up-front planning • resulting in a comprehensive set of planning documents. • Projects utilising agile methods, work on value-driven principles and principles of adaptability • plan only as far as the next iteration and release.

27. Plan-driven Approaches to Project Planning • The planning process for plan-driven projects.

28. Plan-driven Approaches to Project Planning • In a plan-driven development project, the project plan sets out • the tasks to be completed, the resources available to the project, and a schedule for carrying out the tasks. • Indicative plan sections (document)include: • Introduction • Project organisation • Risk analysis • Hardware and software resource requirements • Work breakdown • Project schedule • Monitoring and reporting mechanisms • Supplementary plans: • Configuration management plan • Deployment plan • Maintenance plan • quality plan • Validation plan

29. Project scheduling

30. Plan-driven Project Scheduling • Project scheduling involves: • Subdividing the project into separate tasks. • Estimating how long each task will take to complete. • Estimating the effort (in person hours) required to complete each task. • Estimating the human resources required to complete each task. • Estimating other resources (e.g. specialised hardware and software, office space, travel costs, etc.). • Allocating human and other resources to specific tasks. • Most scheduling work is dependent on estimates. • Good estimates are a result of experience gained in a project manager role.

31. Project Schedule Representation • Project schedules are most often represented in GANTT chart format. • GANTT charts are designed to show: • Decomposition of project into sub-tasks. • Duration of each task. • Start and end date for each task. • Dependencies between tasks (e.g. tasks B and C cannot begin before task A is complete). • Allocation of resources to tasks. • GANTT charts are generally drawn using specialist project management software such as Microsoft Project and Wrike.

32. Project Schedule Representation • GANTT chart showing tasks, task durations, dependencies and allocated human resources.

33. Project Schedule Representation • Another way of representing a project schedule is to use a PERT chart. • PERT=Program Evaluation Review Technique • PERT charts are used by project managers to: • Show the interdependence of tasks. • Calculate the amount of time it will take to complete a project. • Determine a project’s critical path. • Set start and end dates for tasks. • They are generally used at the start of a project. • They are not usually used as a communication tool between project managers and project staff. • A GANTT chart is used for this purpose.

34. Project Schedule Representation • PERT chart showing task dependencies and time estimates.

35. Quiz

37. Estimation techniques

38. Estimation techniques • Organisations need to make software effort and cost estimates. There are two types of technique that can be used to do this: • Experience-based techniques The estimate of future effort requirements is based on the manager’s experience of past projects and the application domain. Essentially, the manager makes an informed judgment of what the effort requirements are likely to be. • Algorithmic cost modeling In this approach, a formulaic approach is used to compute the project effort • based on estimates of product attributes, such as size, and • process characteristics, such as experience of staff involved.

39. Estimate uncertainty

40. Chapter 23 Project Planning Algorithmic cost modelling • Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: • Effort = A*SizeB*M • A is an organisation-dependent constant, • B reflects the disproportionate effort for large projects, and • M is a multiplier reflecting product, process and people attributes. • The most commonly used product attribute for cost estimation is code size. • Most models are similar but they use different values for A, B and M.

41. Algorithmic cost modelling • Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: • Effort = A*SizeB*M • A is an organisation-dependent constant, • B reflects the disproportionate effort for large projects, and • M is a multiplier reflecting product, process and people attributes. • The most commonly used product attribute for cost estimation is code size • Most models are similar but they use different values for A, B and M.

42. Estimation accuracy • The size of a software system can only be known accurately when it is finished. • Several factors influence the final size • Use of reused systems and components; • Programming language; • Distribution of system. • As the development process progresses, the size estimate becomes more accurate. • The estimates of the factors contributing to B and M are subjective and vary according to the judgment of the estimator.

43. Effectiveness of algorithmic models • Algorithmic cost models are a systematic way to estimate the effort required to develop a system. • However, these models are complex and difficult to use. • There are many attributes and considerable scope for uncertainty in estimating their values. • This complexity means that the practical application of algorithmic cost modeling • has been limited to a relatively small number of large companies, • mostly working in defense and aerospace systems engineering.

44. COCOMO cost modelling

45. COCOMO cost modelling • COCOMO= Constructive Cost Model • An empirical model based on project experience. • Well-documented, ‘independent’ model which is not tied to a specific software vendor. • Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. • COCOMO 2 takes into account different approaches to software development, reuse, etc.

46. COCOMO 2 models • COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. • Application composition model • Used when software is composed from existing parts. • Early design model • Used when requirements are available but design has not yet started. • Reuse model • Used to compute the effort of integrating reusable components. • Post-architecture model • Used once the system architecture has been designed and more information about the system is available.

47. Chapter 23 Project Planning Application composition model • Supports prototyping projects and projects where there is extensive reuse. • Based on standard estimates of developer productivity in application (object) points/month. • Takes software tool use into account. • Formula is • PM = (NAP*(1 - %reuse/100 ) ) / PROD • PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

48. Application points • NAP • The number of separate screens or web pages that are displayed • The number of reports that are produced • The number of modules in imperative programming languages • The number of lines of scripting language or database programming code

49. Early design model • Multipliers reflect • the capability of the developers, • the non-functional requirements, • the familiarity with the development platform, etc. • PERS - personnel capability; • RCPX - product reliability and complexity; • RUSE - the reuse required; • PDIF - platform difficulty; • PREX - personnel experience; • SCED - required schedule; • FCIL - the team support facilities. • Estimates can be made after the requirements have been agreed. • Based on a standard formula for algorithmic models • Effort = A*SizeB*M where • M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED; • A = 2.94 in initial calibration, • Size in KSLOC (number of thousands of lines of source code), • B varies from 1.1 to 1.24 depending on • novelty of the project, • development flexibility, • risk management approaches and • the process maturity

50. Chapter 23 Project Planning Reuse model estimates • Black-box reuse where code is not modified. An effort estimate (PM) is computed. • For generated code: • PM = (ASLOC * AT/100)/ATPROD • ASLOC is the number of lines of generated code • AT is the percentage of code automatically generated. • ATPROD is the productivity of engineers in integrating this code. • White-box reuse where code is modified. • When code has to be understood and integrated: • ESLOC = ASLOC * (1-AT/100) * AAM. • ASLOC and AT as before. • AAM is the adaptation adjustment multiplier computed from • the costs of changing the reused code, • the costs of understanding how to integrate the code, and • the costs of reuse decision making. • Effort = A´ESLOCB´M