Software Project Planning
1. Introduction
Project planning is one of the most important jobs of a software project manager. It is the
process of breaking down the work into parts and assigning them to project team members,
anticipating problems that may arise and preparing tentative solutions for them.
It takes place at three stages in a project life cycle:
1. Proposal stage: Where the contract is bidded to develop a software system.
Planning at this stage is inevitably speculative, as the set of requirements for the
software to be developed is not complete.
2. Project startup phase: Where it is planned who will work on the project, breaking
the project down into increments and allocating the required resources.
3. Plan update: As software requirements change, the work breakdown has to be
altered and the schedule extended, and more information is acquired about the
system and the capabilities of the development team.
2. Software Pricing
In principle, the price of a software system developed for a customer is simply the cost of
development plus profit for the developer. In practice, however, the relationship between the
project cost and the price quoted to the customer is not usually so simple. When calculating
a price, broader organizational, economic, political, and business considerations are taken
into account.
2.1 Factors affecting Software Pricing
● Contractual terms: price changes according to the ownership of the source code
● Cost estimate uncertainty: drives the organization to raise the price by a
contingency
● Financial health: cash flow is more important than profit in difficult economic times
● Market opportunity: lowering the price and accepting low profits when moving to
new segments to make greater profit later
● Requirements volatility: as requirements are likely to change, the organization may
lower the price to win a contract, then it can charge higher prices for requirement
changes later.
2.2 Pricing Strategies
● Under pricing: a company may underprice a system to win a contract or get access
to new market area
● Increased pricing: when a buyer wishes a fixed-price contract so the seller
increases the price to allow for unexpected risk.
3. Plan-driven development
It is an approach to software engineering where the development process is planned in
detail. It is based on engineering project management techniques and can be thought of as
the “traditional” way of managing large software development projects.
The problem with plan-driven development is that early decisions have to be revised
because of changes to the environments in which the software is developed and used.
3.1 Project plans
A project plan sets out the resources available to the project, the work breakdown, and a
schedule for carrying out the work. The plan should identify the approach that is taken to risk
management as well as risks to the project and the software under development.
The plans normally include: Introduction, project organization, risk analysis, hardware and
software resource requirements, work breakdown, project schedule, and monitoring and
reporting mechanisms.
Examples of such plans:
● Configuration and management plan
● Deployment plan
● Maintenance plan
● Quality plan
● Validation plan
3.2 The planning process
Project planning is an iterative process that starts when you create an initial project plan
during the project startup phase.
1. First it starts by identifying constraints, risks, milestones and deliverables
2. Defining project schedule
3. Doing the work and monitoring progress against plan
4. In case of facing minor problems, go back to step 2. In case of serious problems,
initiate risk mitigation actions and replan the project. Otherwise, the project is
finished.
4. Project Scheduling
Project scheduling is the process of deciding how the work in a project will be organized as
separate tasks, and when and how these tasks will be executed. Calendar time, effort and
resources need to be estimated.
Each project activity has a duration, an effort estimate, a deadline and a defined end-point.
Bar charts are the most commonly used representation in calendar-based project schedules.
4.1 Project scheduling process
It involves:
1. Identifying activities (from software requirements and design information)
2. Identifying activity dependencies
3. Estimating resources for activities
4. Allocating people to activities
5. Creating project charts and repeating step 3
5. Agile Planning
It is a flexible and iterative planning process where it accommodates customer priorities and
requirements change. Agile development is different from plan-driven development as the
software is developed and delivered in increments which are not planned in advance, but
decided during the development.
5.1 Agile planning stages
● Release planning: involves selecting stories that will reflect the features to be
implemented in a release of a system.
● Iteration planning: stories to be implemented in each iteration are chosen.
5.2 Story based planning (The planning game)
It is based on story identification and discussions, estimation of the amount of time they take
and assigning effort points to each story, and iteration and task planning that take place
simultaneously.
6. Estimation techniques
There are two types of estimation techniques:
1. Experience-based techniques: rely on judgments based on experience of past
projects and the effort exerted in those projects. So it is not good with new software
projects especially if they change rapidly
2. Algorithmic cost modeling: uses a mathematical function of product, project and
process attributes to predict the cost.
Effort = A*Size B*M (A is a constant factor, Size is code size, B is complexity of
software, and M is a factor that takes the mentioned attributes into account)
Despite being systematic to estimate the effort, such models are difficult to use.
7. COCOMO (Constructive Cost Modeling)
The best known algorithmic cost modeling technique is the COCOMO II model. This
empirical model was derived by collecting data from a large number of software projects of
different sizes.COCOMO II is a freely available model that is supported with open-source
tools.
It takes into account modern approaches to software development, such as rapid
development using dynamic languages, development with reuse, and database
programming.
7.1 COCOMO submodels
7.1.1 Application Composition Model
This models the effort required to develop systems that are created from reusable
components, scripting, or database programming.
It is based on an estimate of weighted application points, divided by a standard estimate of
application point productivity.
The number of application points in a program is derived from four simpler estimates:
number of separate screens, number of reports produced, number of modules, and number
of lines of scripting language.
The final formula for effort computation for system prototypes is:
PM = (NAP*(1-%reuse/100))/PROD (where PM is the effort estimated, NAP is total number
of application points, %reuse is an estimation of reused code, and PROD is the application
point productivity)
7.1.2 Early Design Model
This model may be used during the early stages of a project. It assumes that user
requirements have been agreed and initial stages of the system design process are
underway.
The goal at this stage should be to make a quick and approximate cost estimate. It is based
on a standard formula for algorithmic models.
Early design estimates: PM = A*Size B*M (where M is a set of multipliers that reflect the
capabilities of the developers, non-functional requirements, etc.)
7.1.3 Reuse Model
It is used to estimate the effort required to integrate reusable or generated code. It is based
on the number of lines of that code. It also takes into account black-box code that is reused
without change and has to be adapted, as well as white-box where the code is modified.
Reuse model estimates:
For generated code: PM = (ASLOC*AT/100)/ATPROD
When code has to be integrated: ESLOC = ASLOC*(1-AT/100)*AAM
(where ASLOC is the number of lines of generated code, AT is percentage of code
generated, ATPROD is productivity of engineering, and AAM is adaptation adjustment
multiplier computed from the costs of changed code)
7.1.4 Post-architecture Model
The post-architecture model is the most detailed of the COCOMO II models. It is used
when you have an initial architectural design for the system. The starting point for estimates
produced at the post-architecture level is the same basic formula used in the early design
estimates but with 17 rather than 7 associated multipliers.
In addition to adding 3 more estimates which are:
an estimate of the total number of lines of the new code to be developed (SLOC), an
estimate of reuse costs based on (ESLOC), and an estimate of the number of lines of
code that can be changed due to requirement changes.
There are various scale factors used in the exponent computation in the post-architecture
model, which are:
● Architecture/Risk resolution
● Development Flexibility
● Precedentedness
● Process Maturity
● Team Cohesion
7.2 Project duration and staffing
In addition to effort estimation, managers must estimate the calendar time required to
complete a project and when staff will be required.
The Calendar time can be estimated using COCOMO II formula: TDEV = 3*(PM)(0.33+0.2*(B-1.01))
The time required is independent of the number of people working on the project. Staff
required cannot be computed by dividing the development time by the required schedule. A
very rapid build-up of people often correlates with schedule slippage.
8. Conclusion
Project planning is necessary when it comes to planning a software project. The project
plan, which is created at the start of a project and updated as the project progresses, is used
to show how the work will be done and to assess progress on the project.
The price charged for the system does not depend on the development cost, as
organizational factors may mean that the price is increased to compensate for increased risk
or decreased to gain competitive advantage.
A project milestone is a predictable outcome of an activity or set of activities. At each
milestone, a formal report of progress should be presented to management. A deliverable is
a work product that is delivered to the project customer.
The agile planning game involves the whole team in project planning. The plan is
developed incrementally, and, if problems arise, it is adjusted so that software functionality is
reduced instead of delaying the delivery of an increment.
Estimation techniques for software may be experience-based, where managers judge the
effort required, or algorithmic, where the effort required is computed from other estimated
project parameters. The COCOMO II costing model is a mature algorithmic cost model that
takes project, product, hardware, and personnel attributes into account when formulating a
cost estimate.
9. Reference
Sommerville, Ian. “Project Planning.” Software Engineering, Pearson, Boston, 2016.