Project Scheduling and Staffing, Software Configuration Management Plan

Project Scheduling and Staffing, Software Configuration

Management Plan
Project Scheduling and Staffing
After establishing a goal on the effort front, we need to establish the goal for delivery
schedule. With effort estimate(person-months), it may be tempting to pick any project duration
based on convenience and then fix a suitable team size to ensure that the total effort matches
the estimate. Person and months are fully interchangeable in software project.
For a project with some estimated effort, multiple schedules are possible. For example, for
a project whose effort estimate is 56 person-months, a total schedule of 8 months with 7 people
or 7 months with 8 people is possible, as is a schedule of approximately 9 months with 6 people.
In other words, once the effort is fixed, there is some flexibility in setting the schedule by
approximately staffing the project, but this flexibility is not unlimited.
One method to determine the overall schedule is to determine it as a function of effort. Such
function can be determined from data from completed projects using statistical techniques like
fitting a regression curve through the scatter plot obtained by plotting the effort and schedule
of past projects. This curve is generally nonlinear because the schedule does not grow linearly
with effort. The IBM Federal Systems Division found that the total duration, M. in calendar
months can be estimated by
M = 4.1E0.9
In COCOMO, the equation for schedule for an organic type of software is
M = 2.5E0.38

Another method for checking a schedule for medium-sized projects is the rule of thumb
called the square root check. This check suggests that the proposed schedule can be around the
square out of the total effort in person-months. This schedule can be met if suitable resources
are assigned to the project. For example, if the effort estimate is 50 person-months, a schedule
of about 7 to 8 months will be suitable.
Often the staffing level is not changed continuously in a project and approximations of the
Rayleigh curve are used: Assigning a few people at the start having the peak team during the
coding phase, and then leaving a few people for integration and system testing. If we consider
design and analysis, build, and test as the major phases, the manpower ramp-up in projects
typically resembles the function shown in Figure:

1
For ease of scheduling, particularly for smaller projects, often the required people are
assigned together around the start of the project. This approach can lead to some people being
unoccupied at the start and inward the end. This slack time is often used for supporting project
activities like training and documentation. Design requires about a quarter of the schedule,
build consumes about half, and integration and testing consume the remaining quarter.
COCOMO gives 19% for design. 62% for programming and 18% for integration.
Software Configuration Management Plan

Configuration management (CM) is concerned with the policies, processes, and tools for
managing changing software systems. It is easy to lose track of what changes and component
versions have been incorporated into each system version. Versions implement proposals for
change, corrections of faults, and adaptations for different hardware and operating systems.
There may be several versions under development and in use at the same time. If you don’t
have effective configuration management procedures in place, you may waste effort modifying
the wrong version of a system, deliver the wrong version of a system to customers, or forget
where the software source code for a particular version of the system or component is stored.
Configuration management is useful for individual projects as it is easy for one person to
forget what changes have been made. It is essential for team projects where several developers
are working at the same time on a software system. Sometimes these developers are all working
in the same place but, increasingly, development teams are distributed with members in
different locations across the world. The use of a configuration management system ensures
that teams have access to information about a system that is under development and do not
interfere with each other’s work.
2
Figure : Configuration management activities
The configuration management of a software system product involves four closely related
activities
1. Change management This involves keeping track of requests for changes to the software
from customers and developers, working out the costs and impact of making these
changes, and deciding if and when the changes should be implemented.
2. Version management This involves keeping track of the multiple versions of system
components and ensuring that changes made to components by different developers do
not interfere with each other.
3. System building This is the process of assembling program components, data, and
libraries, and then compiling and linking these to create an executable system.
4. Release management This involves preparing software for external release and keeping
track of the system versions that have been released for customer use.
Configuration management policies and processes define how to record and process
proposed system changes, how to decide what system components to change, how to manage
different versions of the system and its components, and how to distribute changes to
customers. Configuration management tools are used to keep track of change proposals, store
versions of system components, build systems from these components, and track the releases
of system versions to customers.
Configuration management is sometimes considered to be part of software quality
management with the same manager having both quality management and configuration
management responsibilities. When a new version of the software has been implemented, it is
handed over by the development team to the quality assurance (QA) team. The QA team
checks that the system quality is acceptable. If so, it then becomes a controlled system, which
means that all changes to the system have to be agreed on and recorded before they are
implemented.
Reference:
1. Ian Sommerville: Software Engineering, 9th Edition, Pearson Education Ltd, 2011.
2. Pankaj Jalote, Software Engineering, Wiley India Pvt Ltd (2010) Paul C Jorgensen
Software Testing A CraftMan’s Approach, 2nd edition, CRC Press.

Project Scheduling and Staffing, Software Configuration Management Plan

Uploaded by

Copyright:

Available Formats

Project Scheduling and Staffing, Software Configuration Management Plan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Scheduling and Staffing, Software Configuration Management Plan

Uploaded by

Copyright:

Available Formats

Project Scheduling and Staffing, Software Configuration

Software Configuration Management Plan

You might also like