PROJECT RESOURCES

The second software planning task is estimation of the resources required to accomplish
the software development effort. IMAGE illustrates development resources
as a pyramid. The development environment—hardware and software tools—sits at
the foundation of the resources pyramid and provides the infrastructure to support
the development effort. At a higher level, we encounter reusable software components—
software building blocks that can dramatically reduce development costs and
accelerate delivery. At the top of the pyramid is the primary resource—people. Each
resource is specified with four characteristics: description of the resource, a statement of availability, time when the resource will be required; duration of time that
resource will be applied. The last two characteristics can be viewed as a time window.
Availability of the resource for a specified window must be established at the
earliest practical time.
 Human Resources
The planner begins by evaluating scope and selecting the skills required to complete
development. Both organizational position (e.g., manager, senior software engineer)
and specialty (e.g., telecommunications, database, client/server) are specified. For
relatively small projects (one person-year or less), a single individual may perform
all software engineering tasks, consulting with specialists as required.
The number of people required for a software project can be determined only after
an estimate of development effort (e.g., person-months) is made. Techniques for estimating
effort are discussed later in this chapter.
Reusable Software Resources
Component-based software engineering (CBSE) emphasizes reusability—that is, the
creation and reuse of software building blocks Such building blocks, often
called components, must be cataloged for easy reference, standardized for easy application,
and validated for easy integration.
Bennatan Suggests four software resource categories that should be considered
as planning proceeds:
Off-the-shelf components. Existing software that can be acquired from a
third party or that has been developed internally for a past project. COTS
(commercial off-the-shelf) components are purchased from a third party, are
ready for use on the current project, and have been fully validated.
Full-experience components. Existing specifications, designs, code, or
test data developed for past projects that are similar to the software to be built for the current project. Members of the current software team have had
full experience in the application area represented by these components.
Therefore, modifications required for full-experience components will be relatively
low-risk.
Partial-experience components. Existing specifications, designs, code, or
test data developed for past projects that are related to the software to be
built for the current project but will require substantial modification. Members
of the current software team have only limited experience in the application
area represented by these components. Therefore, modifications
required for partial-experience components have a fair degree of risk.
New components. Software components that must be built by the software
team specifically for the needs of the current project.
The following guidelines should be considered by the software planner when
reusable components are specified as a resource:
1. If off-the-shelf components meet project requirements, acquire them. The
cost for acquisition and integration of off-the-shelf components will almost
always be less than the cost to develop equivalent software.6 In addition, risk
is relatively low.
2. If full-experience components are available, the risks associated with modification
and integration are generally acceptable. The project plan should
reflect the use of these components.
3. If partial-experience components are available, their use for the current project
must be analyzed. If extensive modification is required before the components
can be properly integrated with other elements of the software,
proceed carefully—risk is high. The cost to modify partial-experience components
can sometimes be greater than the cost to develop new components.
Ironically, reusable software components are often neglected during planning, only
to become a paramount concern during the development phase of the software
process. It is better to specify software resource requirements early. In this way technical
evaluation of the alternatives can be conducted and timely acquisition can occur.
Environmental Resources
The environment that supports the software project, often called the software engineering
environment (SEE), incorporates hardware and software. Hardware provides
a platform that supports the tools (software) required to produce the work products
that are an outcome of good software engineering practice.Because most software organizations have multiple constituencies that require access to the SEE, a project
planner must prescribe the time window required for hardware and software and
verify that these resources will be available.