5/23/10 31P5 Software Engineering

Thursday, April 13, 2023

31P5 Software Engineering 1

31P5: Software Engineering I

Project Planning



Aims

• To understand the main management activities involved in Project Planning

• To develop a behavioural model of Project Management and to use it to ask “What if” questions

• To consider a number of project costing techniques



Management activities

• No standard job description for Software Manager

• Generally involves the following activities:– proposal writing

– project planning and scheduling

– project costing

– project monitoring and reviews

– personnel selection and evaluation

– report writing and presentations



Software project planning• The project plan sets out the resources

available, the work breakdown, and the schedule• The project plan may be: a single document

including all the different types of plans such as:– Quality plan: quality procedures and standards to be

used for system validation

– Validation plan: approach, resources and schedule for system validation

– Configuration management plan: configuration management procedures and structures used

– Maintenance plan: predicts maintenance requirements of system, maintenance costs and effort required

– Staff development plan: describes how skills and experience of project team members developed



Planning (cont’d)

• Or, a document concerned with the development process:– Introduction: briefly, the objectives of project and sets

constraints (e.g., budget, time, etc.) which affect project management

– Project organisation: way in which development team are organised, the people involved and their roles in the team

– Risk analysis: possible project risks, their likelihood of occurrence, and risk reduction strategies proposed

– Hardware/software: support required for the development; if hardware to be bought, estimates of price and delivery schedule



Planning (cont’d)

– Work breakdown: breakdown of project into activities and tasks, and identifies milestones and deliverables associated with each task

– Project schedule: dependencies between activities, estimated time required to reach each milestone, and allocation of people to activities

– Monitoring and reporting mechanisms: management reports which should be produced, when, and the monitoring mechanism.



An Integrative View

• Integrates:– management-type functions of planning, controlling,

staffing

– production-type functions of designing, coding, reviewing, testing

• “The behaviour of an individual subsystem in isolation may be different from its behaviour when it interacts with other subsystems.”

• Software project management is a DYNAMIC and COMPLEX process.

• Control of the process involves application of FEEDBACK CONTROL SYSTEMS principles

• Feedback control may be positive or negative



Critical management decisions

1 A project is behind schedule. Possible management actions include revising the completion date, holding to the planned completion date but hiring more staff, and holding to the planned completion date but working current staff overtime. What are the implications of the alternatives?

2 How much of the development effort should be expended on quality assurance and how does that affect completion time and total cost?

3 What is the impact of different distributions of effort among project phases (e.g., should the division of effort between development and testing be 80:20 or 60:40 percent)?



Critical management decisions (cont’d)

4 What are the reasons for and implications of the differences among potential productivity, actual productivity, and perceived productivity?

5 Why does the “90% completion syndrome”, whereby a project appears to get stuck when it reaches the 90% completion point, chronically occur?



Simple Model: software project process



Simple Model: software project process

1 Project resources: manpower, facilities, equipment2 Work completed on project reported through

project control system3 Reports accumulate and are processed to create

project’s forecast completion date by adding indicated time remaining to current date

4 Assessing remaining time:– effort (person-days) to complete job– level of personnel working on project– perceived productivity of project team

5 Original scheduled completion date6 Feedback loop closed: difference (5-4) causes

adjustments in magnitude or allocation of resources



Adding more people to a late project



Adding more people to a late project

• Model suggests direct relationship• Increase people resources Increase in work

rate• Problem:

– more people higher communication, training cost

– lower project team productivity

– lower progress rates

– delay to already late project

– additional round of loop

– more people

– …..

• Brook’s Law: adding more people to a late project makes it later



Adjusting schedule of late project



Adjusting schedule of late project• Impact of project pressures (e.g., schedule

pressure) on developers’ actions/decisions• Project behind schedule:

– developers work longer hours

– concentrate on essential task

• Boehm experiment: found number of person-hours devoted to project increased by 100%

• Schedule pressure affects Productivity• Problem:

– Schedule pressure increased error rate

– rework on project: negative effect• “People under time pressure don’t work better, they just

work faster … The first casuality [is] the quality of the software delivered”







• Impact of schedule pressure on workforce turnover rate:

• Workforce turnover rate increases when scheduling pressure persists– can be very costly

– high turnover rate lower productivity on project



How late is a late project?



How late is a late project?

• Difficult to assess real progress on a project because of the nature of software (intangible?); very few sensible and usable metrics

• Therefore,– Perceived progress rate =|= Real progress rate

• Errors in perceived cumulative progress + bias (overoptimism) + delay (in gathering and processing control information) distorts reported progress



Comprehensive Model

• Model so far too simple• It needs:

– significantly more depth and detail

– a systematic way to organise the information

• To achieve this need to consider a number of subsystems, including HUMAN RESOURCE MANAGEMENT, SOFTWARE PRODUCTION, CONTROL, PLANNING



Single-Project Model



Overview of Single-Project Model

• Human Resource Management Deals with Hiring, Assimilation and Transfer of People

• Workforce may be Newly Hired or Experienced1 needed to capture differences in productivity,

error proneness2 allows the capture of training processes to

assimilate new members:– normally, veterans train newcomers

– training overheads significantly affect project’s progress by utilising veterans’ productivity



Software Production

• Includes Designing, Coding, Testing• Reviews to detect errors, e.g., quality

assurance via structured walkthroughs• Some errors are caught by testing• Productivity = Potential productivity — Faulty

process losses• Potential productivity depends on the nature of

– communication overheads

– coordination overheads

– low motivation



Control

• As progress is made, it is reported• Information is often inaccurate!

– Problems to deal with• information flow• time lags• distortion

– early in project: progress measured by resources used

– later: progress measured by work actually accomplished



Planning

• Project resources and schedule estimates are made and revised, e.g.,– project behind schedule

– Workforce needed = Person-days remaining / Time remaining

• Time remaining is affected by workforce stability and workforce ceiling limitations (e.g., budget constraints)

• Possible to extend our single-project model to multi-project model– coupling between single-project models, e.g., at the

human resources level with sharing of staff



Project Planning Estimation

• The major issues which the project plan addresses are:– Cost estimation

– Schedule and milestones

– Personnel plan

– Team structure

– Software quality assurance plans

– Configuration management plans

– Project minotoring plans

– Risk management plans



Major cost estimation techniquesMethod Strengths Weaknesses

Algorithmic Objective, repeatable,analysable formulae

Efficient, good forsensitivity analysis

Objectively calibratedto experience

Subjective inputs

Assessment ofexceptional circumstances

Calibrated to past,not future

Expertjudgement

Assessment ofrepresentativenessinteractions, exceptions

No better thanparticipants

Biases, incomplete recallAnalogy Based on representative

experienceRepresentativeness ofexperience

Parkinson Correlates with someexperience

Re-enforces poorpractice

Price-to-win Often gets contract! Generally produceslarge overruns

Top-down System level focus,efficient

Less detailed basis;less stable

Bottom-up More detailed basis

More stable

Fosters individualcommitment

May overlook systemscosts

Requires more effort



Summary

• A number of management activities associated with project planning have been identified

• A simple model of project management has been developed and used to discuss simple problems and their solutions

• Cost/effort estimation approaches, their strengths and weaknesses considered

• In the next section, a particular cost/effort/schedule technique will be highlighted

Technology

5/23/10 31P5 Software Engineering