Page 206 -

CHAPTER 7 PROJECT SCHEDULING AND TRACKING 177

7.4 SELECTING SOFTWARE ENGINEERING TASKS

In order to develop a project schedule, a task set must be distributed on the project
time line. As we noted in Section 7.3, the task set will vary depending upon the proj-
ect type and the degree of rigor. Each of the project types described in Section 7.3
may be approached using a process model that is linear sequential, iterative (e.g., the
prototyping or incremental models), or evolutionary (e.g., the spiral model). In some
cases, one project type flows smoothly into the next. For example, concept develop-
ment projects that succeed often evolve into new application development projects.
An adaptable process As a new application development project ends, an application enhancement proj-
model (APM) includes a ect sometimes begins. This progression is both natural and predictable and will occur
variety of task sets and is
available for your use. regardless of the process model that is adopted by an organization. Therefore, the
major software engineering tasks described in the sections that follow are applica-
ble to all process model flows. As an example, we consider the software engineering
tasks for a concept development project.
Concept development projects are initiated when the potential for some new tech-
nology must be explored. There is no certainty that the technology will be applica-
ble, but a customer (e.g., marketing) believes that potential benefit exists. Concept
development projects are approached by applying the following major tasks:
Concept scoping determines the overall scope of the project.

Preliminary concept planning establishes the organization’s ability to
undertake the work implied by the project scope.
Technology risk assessment evaluates the risk associated with the tech-
nology to be implemented as part of project scope.
Proof of concept demonstrates the viability of a new technology in the soft-
ware context.
Concept implementation implements the concept representation in a
manner that can be reviewed by a customer and is used for “marketing” pur-
poses when a concept must be sold to other customers or management.
Customer reaction to the concept solicits feedback on a new technology
concept and targets specific customer applications.
A quick scan of these tasks should yield few surprises. In fact, the software engi-
neering flow for concept development projects (and for all other types of projects as
well) is little more than common sense.
The software team must understand what must be done (scoping); then the team
(or manager) must determine whether anyone is available to do it (planning), con-
sider the risks associated with the work (risk assessment), prove the technology in
some way (proof of concept), and implement it in a prototypical manner so that the
customer can evaluate it (concept implementation and customer evaluation). Finally,
if the concept is viable, a production version (translation) must be produced.