1. Software Engineering I Session 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.
In professional practice, is it possible to be a project manager without first being a software engineer?
Software project management is an essential part of SE

3. You are a software project manager
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)
1. Why is software project management inherently more difficult than project management in other engineering disciplines?

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.
In what way are software products more complex than other products (for example, in construction)?
It is not surprising that some software projects are late, overbudget, and behind schedule.

6. Software Project Management
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
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
Give examples of two software process models that require radically different approaches to project management.
How might organisational culture affect software project management?
Despite differences dictated by project and organisation specifics,

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:
Project risks
Affecting schedule and/or resources.
Loss of key staff. Budget shortfall. Management change. Tool unavailability, etc.
Product risks
Affecting quality or performance of software being developed.
Requirements change. Substandard craftsmanship. Tool under-performance, etc.
Business risks
Affecting the organisation developing or procuring the software.
Emergence of competitor product. Product redundancy due to changes in underlying technologies, etc.
1. Give further examples of project, product and business risks.

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.
1. Give examples of one risk from each of the listed categories.

12. Examples of different risk types
Possible risks
Estimation
The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
Organisational
The organisation is restructured so that different management are responsible for the project.
Organisational financial problems force reductions in the project budget.
People
It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Requirements
Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Technology
The database used in the system cannot process as many transactions per second as expected.
Reusable software components contain defects that mean they cannot be reused as planned.
Tools
The code generated by software code generation tools is inefficient.
Software tools cannot work together in an integrated way.

13. Risk Analysis
In risk analysis, identified risks should be ranked on the basis of their probability/likelihood and their likely effect/impact.
Low Likelihood
Medium Likelihood
High Likelihood
Low Impact
Low Risk
Medium Risk
Medium Impact
High Risk
High Impact
1. How are impact and likelihood calculated?

14. Risk types and examples (1)

15. Risk types and examples (2)

16. Risk Planning
Risk planning first involves 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).
Is it ever possible to manage all the risks in a project?
How many risks should be managed?

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.
Risk monitoring may also assess the effectiveness of current risk management processes with a view to refining practice.
factored into risk management measures

21. Risk indicators

22. Project planning

23. Project Planning 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.
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
1. How can a project plan be used to measure progress?

24. Planning Stages Project planning is an ongoing and iterative activity
takes place at different stages in the project lifecycle
Proposal stage
At the point of bidding for a contract. Outline plan showing major project milestones. Provides pricing information.
Start-up stage
Once contract is secured. Detailed plan showing detailed decomposition of task. Shows resource requirements and allocation. Details project risks and risk management.
Development stage
Once the project is underway. Refines start-up plan, resource issues and risk management.
1. Who are the primary audience for project planning documents at the proposal, start-up and development stages of a project?

25. Configuration management planning Deployment planning
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.
1. What do you think is contained in a configuration management plan?

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.
What factors will a project manager bring to bear when making estimates for project duration, resources required, etc.?
Can project estimation ever be an exact science?

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.
1. What are the advantages of using specialised tools for project planning?

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.
A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

34. Project Schedule Representation
PERT chart showing task dependencies and time estimates.
1. How might a PERT chart like the one above help us to schedule a project and allocate resources to tasks?

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. Algorithmic cost modelling
Chapter 23 Project Planning
10/12/2014
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. Application composition model
Chapter 23 Project Planning
10/12/2014
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.
Developer’s experience and capability
Very low
Low
Nominal
High
Very high
ICASE maturity and capability
PROD (NAP/month) 4 7 13 25 50

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
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
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.

50. Chapter 23 Project Planning
10/12/2014
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 ´ ESLOC B ´ M

51. Post-architecture level
PM = A * SizeB * M
Uses the same formula as the early design model but with 17 rather than 7 associated multipliers.
The code size is estimated as the sum of:
Number of lines of new code to be developed (SLOC);
Estimate of equivalent number of lines of new code computed using the reuse model (ESLOC);
An estimate of the number of lines of code that have to be modified according to requirements changes.

52. The exponent term (B)
This depends on 5 scale factors (see next slide). Their sum/100 is added to 1.01
A company takes on a project in a new domain. The client has not defined the process to be used and has not allowed time for risk analysis. The company has a CMM level 2 rating.
Precedenteness - new project (4)
Development flexibility - no client involvement - Very high (1)
Architecture/risk resolution - No risk analysis - Very Low (5)
Team cohesion - new team - nominal (3)
Process maturity - some control - nominal (3)
Sum= =16
Scale factor is therefore 1.17 (16/ =1.17)

53. Chapter 23 Project Planning
10/12/2014
Scale factors used in the exponent computation in the post-architecture model
Scale factor
Explanation
Architecture/risk resolution
Reflects the extent of risk analysis carried out. Very low means little analysis; extra-high means a complete and thorough risk analysis.
Development flexibility
Reflects the degree of flexibility in the development process. Very low means a prescribed process is used; extra-high means that the client sets only general goals.
Precedentedness
Reflects the previous experience of the organization with this type of project. Very low means no previous experience; extra-high means that the organization is completely familiar with this application domain.
Process maturity
Reflects the process maturity of the organization. The computation of this value depends on the CMM Maturity Questionnaire, but an estimate can be achieved by subtracting the CMM process maturity level from 5.
Team cohesion
Reflects how well the development team knows each other and work together. Very low means very difficult interactions; extra-high means an integrated and effective team with no communication problems.

54. Multipliers (M) Product attributes Computer attributes
Concerned with required characteristics of the software product being developed.
Computer attributes
Constraints imposed on the software by the hardware platform.
Personnel attributes
Multipliers that take the experience and capabilities of the people working on the project into account.
Project attributes
Concerned with the particular characteristics of the software development project.

55. The effect of cost drivers on effort estimates
Chapter 23 Project Planning
10/12/2014
The effect of cost drivers on effort estimates
Exponent value
1.17
System size (including factors for reuse and requirements volatility)
128,000 DSI
Initial COCOMO estimate without cost drivers
730 person-months
Reliability
Very high, multiplier = 1.39
Complexity
Very high, multiplier = 1.3
Memory constraint
High, multiplier = 1.21
Tool use
Low, multiplier = 1.12
Schedule
Accelerated, multiplier = 1.29
Adjusted COCOMO estimate
2,306 person-months
Exponent value
1.17
Reliability
Very low, multiplier = 0.75
Complexity
Memory constraint
None, multiplier = 1
Tool use
Very high, multiplier = 0.72
Schedule
Normal, multiplier = 1
Adjusted COCOMO estimate
295 person-months

56. Project duration and staffing
As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required.
Calendar time can be estimated using a COCOMO 2 formula
TDEV = 3 * (PM)( *(B-1.01))
The nominal schedule for the project (in calendar months)
PM is the effort computation
B is the exponent computed as discussed before (B is 1 for the early prototyping model).
This computation predicts the nominal schedule for the project.
The time required is independent of the number of people working on the project.

57. Agile planning

58. Agile Planning
Agile methods of software development are iterative approaches where the software is developed and delivered to customers in increments.
Unlike plan-driven approaches, the functionality of these increments is not entirely planned in advance,
but is decided during development.
The decision on what to include in an increment depends on progress and on customer priorities.
Customer priorities and requirements change so it makes sense to have a flexible plan that can accommodate these changes.

59. Agile Planning Agile methods have a two stage approach to planning:
Release planning, which looks ahead for several months and decides on the features that should be included in a release of a system.
Iteration planning, which has a shorter term outlook (2-3 weeks), and focuses on planning only the next increment of a system.
Each agile method has its own unique approach to planning:
Scrum – project backlogs, daily reviews and sprints.
Extreme Programming – The Planning Game.

60. The Planning Game – Release Planning
Release planning involves
selecting and refining the stories that will reflect the features to be implemented in a release of a system, and
the order in which the stories should be implemented.
Release planning has three phases:
Exploration Phase: Customer provides a shortlist of high-value requirements for the system in user story format.
Commitment Phase: Customer and developers commit to the functionality to be included in the next release and the release date.
Steering Phase: The plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed.

61. The Planning Game – Iteration Planning
A release is broken down into iterations.
Stories to be implemented in each iteration are chosen, with the number of stories reflecting the time to deliver an iteration (usually 2-3 weeks).
Iteration planning is also broken down into three key phases:
Exploration Phase: User stories are broken down into tasks. Tasks are recorded on task cards.
Commitment Phase: Programmers choose tasks to implement. The time it takes to complete tasks is estimated.
Steering Phase: Tasks are carried out in pairs. Tests are run (e.g. TDD).

62. The Planning Game – Scheduling – Estimation
Developers use relative estimation to assign a story point value to a story dependent on story size.
Note the use of the Fibonacci series for the scale.

63. The Planning Game – Scheduling – Estimation
Customers then rank the stories in terms of the value they deliver.

64. The Planning Game – Scheduling – Estimation
The bang for the buck score is then calculated by dividing the value points by the story points for each story.
The BFTB score represents the most value attainable in the shortest time.

65. The Planning Game – Scheduling – Estimation
Stories are then ranked in terms of BFTB score (high to low).
This gives an initial sequence in which tasks should be performed.
However, tasks will normally need to be reordered again to account for dependencies.
Task
Story P
Value P
BFTB C 3 13
4.33 E 21 55
2.62 G 5
2.6 A 34
1.68 F
1.61 B
0.62 D
0.05
Task
Story P
Value P
BFTB C 3 13
4.33 G 5
2.6 E 21 55
2.62 A 34
1.68 F
1.61 B
0.62 D
0.05

66. Scheduling – Estimation – Velocity
The initial velocity of a project is set at the number of story points completed in iteration one.
Based on the velocity, we can then calculate how long it will take to complete each remaining story point, and to schedule tasks accordingly.
To calculate how long a single story point takes to complete, we divide the time taken to complete the iteration by the velocity:
50 hours / 55 = 0.9 hours
At the end of every iteration, the velocity is recalculated and the project schedule adjusted in response.