Software Engineering: 3. Project planning

recourse: "Software Engineering", Ian Sommerville

Keywords for this chapter:

planning
scheduling
cost estimation

Project planning takes place at three stages in a project life cycle:

At the proposal stage (When you are bidding for a contract to develop or provide a software system).
- Do you have the resources to complete the work?
- work out the price that you should quote to a customer.
During the project startup phase When you have to plan:
- who will work on the project
- how the project will be broken down into increments
- how resources will be allocated across your company
- etc
Periodically throughout the project

Planning at the proposal stage is inevitably speculative [ɪ'nevɪtəblɪ] ['spekjʊlətɪv] , as you do not usually have a complete set of requirements for the software to be developed. Rather, you have to respond to a call for proposals based on a high-level description of the software functionality that is required.

There are three main parameters that you should use when computing the costs of a software development project:

effort costs ( the costs of paying software engineers and managers)
hardware and software costs, including maintenance
travel and training costs

The plan should define project monitoring mechnisms. You must keep track of the progress of the project and compare actual and planned progress and costs.

Agood manager should be able to form a clear picture of what is going on through informal discussions with project staff.

1. Software pricing

When calculating a price, you should take the following iterms into account:

Market opportunity
Cost estimate uncertainty
Contractual terms
Requirements volatility
Financial health

1.1 market opportunity

A development organization may quote a low price because it wishes to move into a new segment of the software market. Accepting a low profit on one project may give the organization the opportunity to make a greater profit later. The experience gained may also help it develop new products.

1.2 Cost estimate uncertainty

If an organization is unsure of its cost estimate, it may increase its price by a contingency over and above its normal profit.

1.3 Contractual terms

A customer may be willing to allow the developer to retain ownership of the source code and reuse it in other prohects. The price charged may then be less than if the software source code is handed over to the customer.

1.4 Requirements volatility

If the requirements are likely to change, an organization may lower its price to win a contract. After the contract is awarded, high prices can be charged for changes to hte requirements.

1.5 Financial health

Developers in financial difficulty may lower their price to gain a contract. It is better to make a smaller than normal profit or break even than to go out of business. Cash flow is more important than profit in difficult economic times.

2. Plan-driven development

Plan-driven or plan-based development is an approach to software engineering where the development process is planned in detail.

2.1 Project plans

In a plan-driven development project, a project plan normally include the following sections:

Introduction: This briefly describes the objectives of the project and sets out the constraints (e.g., budget, time, etc.) that affect the management of the project.
Poject organization: This describes the way in which the development team its organized, the people involved, and their roles in the team.
Risk analysis: This describes possible project risks, the likelihood of these risks arising, and the risk reduction strategies that are proposed.
Hardware and software resource requirements
Work breakdown: milestones and deliverables associated with each activity.
Project schedul
Monitoring and reporting mechanisms : This defines the management reports that should be produced, when these should be produced, and the project monitoring mechanisms to be used.

2.2 The planning process

The figure below is a UML activity diagram that shows a typical workflow for a project planning process.

contraints: delivery date, staff available, overall budget, available tools, and so on.

3. Project scheduling

Project scheduleing is the process of deciding:

how the work will be organized as separate tasks
when and how these tasks will be executed
calandar time
who will work on the tasks
resources needed

3.1 Schedule representation

Project schedules may simply be represented in a table or spreadsheet showing the tasks,effort, expected duration, and task dependencies.

There are two types of representation that are commonly used:

Bar charts: calendar-based, show who is responsible for each activity, the expected elapsed time, and when the activity is scheduled to begin and end. (Gantt charts)
Activity networks: network diagrams, show the dependencies between the different activities making up a project.

Project activities are the basic planning element. Each activity has:

a duration in clendar days or months
an effort estimate
a deadline
a defined endpoint. This represents the tangible result of completing the activity. This coud be a document, the holding of a review meeting, the successful execution of all tests, etc.

The table below shows tasks, estimated effort, duration, and task interdependencies.

It can be seen from the table that T3 is dependent on task T1. Task T1 must, therefore, be completed before T starts.

The bar chart below takes the information in table above and presents the project schedule in a graphical format.

Project managers have to allocate resources to tasks as well.

The table below shows when staff are working on the project.

4. Agile planning

Agile methods of software development are iterative approaches where the software is developedand delivered to customers inincrements.

(important but skip here)