Adaptable Process Model Adapting the Model to Local Needs
	IMPORTANT NOTICE: The complete Adaptable Process Model (APM) is provided for informational purposes and for assessment by potential users. The APM is copyrighted material and may not be downloaded, copied, or extracted for use in actual project work. The full hypertext (html) version of the APM may be licensed for use and customization within your organization. Contact R.S. Pressman & Associates, Inc.for complete licensing information.
	Selecting the Task Set for Your Project The APM provides a systematic method for choosing the set of software engineering tasks that will best accommodate the needs of pilot project. The task set to be chosen must provide enough discipline to achieve high software quality. But at the same time, it must not burden the project team with unnecessary work. APM task sets are defined for each of five project types. These tasks sets are further refined by assessing adaptability criteria that will enable a project team to select the tasks that will provide the required degree of rigor for the project. Degrees of Rigor Even for a project of a particular type, the degree of rigor with which the software process is applied may vary significantly. The degree of rigor is a function of many project characteristics. As an example, small, non-mission critical projects can generally be addressed with somewhat less rigor than large, complex mission critical applications. It should be noted, however, that all projects must be conducted in a manner that results in timely, high quality deliverables. Four different degrees of rigor are defined for the APM: Casual. All APM framework activities are applied, but only a minimum task set is required. In general, umbrella tasks will be minimized and documentation requirements will be reduced. All basic principles of software engineering are still applicable. Structured. The APM framework will be applied for this project. Framework activities and related tasks appropriate to the project type will be applied and umbrella activities necessary to ensure high quality will be applied. SQA, SCM, documentation and measurement tasks will be conducted in a streamlined manner. Strict. The APM will be applied for this project with a degree of discipline that will ensure high quality. All umbrella activities will be applied and robust documentation will be produced. Quick Reaction. The APM will be applied for this project, but because of an emergency situation, only those tasks essential to maintaining good quality will be applied. "Back-filling" (e.g., developing a complete set of documentation, conducting additional reviews) will be accomplished after the application/product is delivered to the customer. The APM provides a systematic approach for selecting the degree of rigor that is appropriate for a particular project. Project planning begins with the computation of a task set selector value. This is described in the section that follows. Characterizing Your Software Project Project type and adaptation criteria are used to determine the recommended degree of rigor with which software engineering (and the APM) should be applied on a project. Using the buttons that follow, select the characteristics that best describe your project. -------------------------------------------------------- UNDER CONSTRUCTION COMPUTATIONS REQUIRED TO DETERMINE THE TSS VALUE ARE CURRENTLY UNDER CONSTRUCTION. -------------------------------------------------------- Project Type Select the project type that best describes the software work to be performed: Concept Development Projects that are initiated to explore some new business concept or application of some new technology, New Application Development Projects that are undertaken as a consequence of a specific customer request, Application Enhancement Projects that occur when existing software undergoes major modifications to function, performance or interfaces that are observable by the end-user, Application Maintenance Projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end user, Reengineering Projects that are undertaken with the intent of rebuilding an existing (legacy) system in whole or in part. Web Application Development Projects that are applicable when Internet-based applications and Web site are developed for buinsess and e-commerce applications. Adaptation Criteria To determine the degree of rigor and task set for your project, select the characterization that best describes your project for each of the characteristics that follow: Size of project. This criterion can be estimated in work units (e.g., person-months) or product units (e.g., number of lines of code to be generated). less than 3 person-months and/or 3,000 LOC or 30 function points between 3 and 9 person months and/or 3,000 and 6,000 LOC (30 to 60 function points) a moderate-size project, between 6 and 12 person-months and/or 5,000 and 20,000 LOC (50 to 200 function points) between 9 and 24 person-months and/or 10,000 and 30,000 LOC (100 and 300 function points) between 18 and 48+ person-months and over 25,000 LOC (250 function points) Number of potential users. This criterion provides information on the potential market and by inference, the amount of support required. 1 to be used by local staff only, no immediate outside use 2 a product with a limited internal customer base 3 a product with over 1-9 geographically separate customers 4 a product with over 10 - 99 geographically separate customers 5 a product with over 100 geographically separate customers Mission criticality. This criterion provides an indication of the relative business/mission impact of the project. 1 R&D project, no immediate business impact 2 supports minor business/technical function, not critical 3 supports major mission objective; critical, but workaround exists 4 lack of application will cause severe mission related problems 5 no workaround exists; absolutely critical Application longevity. This criterion estimates the number of years that the product/application to be built/maintained will be in active use. 1 use projected at less than 1 year 2 use projected between 1 and 3 years 3 use projected between 2 and 5 years 4 use projected between 4 and 7 years 5 use projected to be over 7 years Stability of requirements from external customer. This criterion indicates the degree to which software requirements are understood and will remain stable throughout the project. 1 scope is documented and well understood 2 scope is understood, but not documented by customer 3 complex requirements that are fully understood by customer and developer 4 moderately complex requirements that must be negotiated with customer 5 complex requirements that are not fully understood by customer and developer Ease of customer-developer communication. This criterion provides an indication of the ease with which communication can be conducted between customer and developer. It is often affected by the location of developer and customer. 1 customer is the developer 2 customer and developer work in the same group or organization 3 customer and developer are geographically separated or organizationally separated 4 customer and developer are separated by service and/or international boundaries 5 poor communication has been exhibited in past endeavors • Maturity of technology. This criterion provides a relative indication of the risk associated with the technology to be implemented. 1 technology is well understood and mature 2 technology is well understood but there is little local experience with it 3 technology is less well understood (or has high risk) 4 technology is less well understood (or has high risk) and there is little local experience with it 5 technology is not well understood and is high risk Performance constraints. This criterion provides a relative indication of the overall performance demanded of the product and the risk associated with achieving it. 1 run-time performance and/or data capacity are not issues 2 run-time performance and/or data capacity are important 3 run-time performance and/or data capacity are critical 4 specialized performance requirements must be accommodated 5 software is coupled intimately with hardware Embedded/non-embedded characteristics. This criterion identifies whether the software is a support application or whether it is to be embedded directly into the product. 1 stand-alone application software in a conventional computing environment 2 application software residing in computing environment that services/controls a product 3 embedded software to be developed in a high-order programming language 4 embedded software to be developed in assembly language 5 embedded software with special high performance or design constraints Project staffing. This criterion defines the type of staffing to be used for this project. 1 internal staff, high competency and experience 2 external contractor, past experience has been positive 3 internal staff, lower competency and experience 4 internal staff, little experience 5. external contractor, first encounter Interoperability. This criterion indicates the degree to which the application interacts with other applications. 1 the application is standalone 2 the application is standalone but does access an external file structure or database 3 the application communicates with less than 3 other applications and/or access less than 3 external file structures or databases 4 the application communicates with between than 3 and 10 other applications and/or accesses more than 3 external file structures or databases 5. the application communicates with between more than 8 other applications and/or accesses more than 3 external file structures or databases Reengineering factors. This criterion describes techncial characterisitics of the application to be reengineered: 1 the system is to be reengineered with little or no change to requirements; good descriptive information already exists; 2 the system is to be reengineered with minor changes to requirements; descriptive information must be reworked; 3 the system is to be reengineered with major changes to requirements; descriptive information must be reworked; 4 the system is to be reengineered with major changes to requirements; no descriptive information exists; 5 the system is to be reengineered with major changes to requirements; no descriptive information exists; major changes are also expected in the techncial infrastructure that supports the application Once you have selected the project type and specified all adaptation criteria, the APM will compute a "Task Set Selector" value for your project. -------------------------------------------------------- UNDER CONSTRUCTION COMPUTATIONS REQUIRED TO DETERMINE THE TSS VALUE ARE CURRENTLY UNDER CONSTRUCTION. -------------------------------------------------------- To compute the task set selector, press the submit button. -------------------------------------------------------- UNDER CONSTRUCTION COMPUTATIONS REQUIRED TO DETERMINE THE TSS VALUE ARE CURRENTLY UNDER CONSTRUCTION. -------------------------------------------------------- Interpreting the Task Set Selector Value Now that you've determined the task set selector value, the following guidelines will assist you in selecting the appropriate degree of rigor and the resulting task set for a project: Task set selector value Degree of Rigor TSS < 1.2 casual 1.0 < TSS < 3.0 structured TSS > 2.4 strict Selecting a Task Set The overlap in TSS values from one recommended task set to another is purposeful and is intended to illustrate that sharp boundaries are impossible to define when making task set selections. In the final analysis, the task set selector value, past experience, and common sense must all be factored into the choice of the final APM task set. Choose from one of the four options noted below: Casual Task Set Structured Task Set Strict Task Set Quick Reaction Task Set A detailed APM process design language description (with hypertext links that provide detail) can be obtained to provide a comprehensive discussion of each software engineering task. Return to "How to Use the APM"