Because software projects span many different types of organizations, a variety of different application areas, and a wide range of technologies, it is likely that any process model developed for use on these projects will have to be adapted to local circumstances. The intent of the Adaptable Process Model (APM) is to:
1. provide a common process framework (CPF) for all projects;
2. define generic framework activities that are applicable across all projects;
3. define a process model that can be adapted to local requirements, standards, and culture;
4. define a process model that is appropriate regardless of the paradigm (e.g., linear sequential life cycle model, prototyping, evolutionary model) that is chosen for process flow;
5. provide guidance to project teams that will enable these teams to adapt the APM intelligently to their environment.
The process model is adapted by considering two characteristics of the project: (1) project type, and (2) a set of adaptation criteria that defines the degree of rigor with which software engineering is to be applied.
1.1 Project Types
Project type refers to the characteristics of the project. In this context, the following project types are defined:
I. Concept Development Projects that are initiated to explore some new business concept or application of some new technology,
II. New Application Development Projects that are undertaken as a consequence of a specific customer request.
III. Application Enhancement Projects that occur when existing software undergoes major modifications to function, performance or interfaces that are observable by the end-user,
IV. Application Maintenance Projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end user.
V. Reengineering Projects that are undertaken with the intent of rebuilding an existing (legacy) system in whole or in part.
VI. Web Application Development Projects that are undertaken when web sites and related internet-based applications must be developed.
Although each of the projects types differ in subtle and profound ways, all can be approached using a consistent software engineering framework. These are described in the following section.
1.2 Framework Activities
An effective process model should define a small set of framework activities that are always applicable, regardless of project type. The APM defines the following set of framework activities:
project definition - tasks required to establish effective communication between developer and customer(s) and to define requirements for the work to be performed
planning - tasks required to define resources, timelines and other project related information and assess both technical and management risks
engineering and construction - tasks required to create one or more representations of the software (can include the development of executable models, i.e., prototypes or simulations) and to generate code and conduct thorough testing
release - tasks required to install the software in its target environment, and provide customer support (e.g., documentation and training)
customer use - tasks required to obtain customer feedback based on use and evaluation of the deliverables produced during the release activity
Each of the above framework activities will occur for every project. However, the set of tasks (we call this a task set) that is defined for each framework activity will vary depending upon the project type (e.g., Concept Development Projects will have a different task set than Application Enhancement Projects) and the degree of rigor selected for the project.
1.3 Umbrella Activities
In addition to the framework activities in Section 1.2, the APM defines a set of umbrella activities that persist across the entire software process. These umbrella activities include:
software project management
formal technical reviews
software quality assurance
software configuration management
document preparation and production
Each of these umbrella activities is defined by a set of tasks that are adapted to the project type and degree of rigor with which software engineering is to be applied.
Return to "How to Use the APM"