Tailoring an organization's standard software process to the needs of a project is a detailed process that takes time and experience to complete successfully. The gains in streamlining software project planning and management appear to far outweigh the time and effort required to ensure that the project's defined software process (i.e., the tailored process) meets the needs of the project.
Throughout the research for this report, the following concepts emerged as important to the tailoring and planning processes:
a. Whenever possible, an organization's standard software process should be modular. It should consist of a set of building blocks that can be used in a number of ways to fulfill the needs of a software project.
b. While an organization's standard software process may need to fulfill the requirements of a process standard or other form of guidance, the organization's standard software process should be developed to fulfill the needs of the organization rather than simply comply to a specific form of guidance.
c. The organization's standard software process should be written as requirements so that compliance is mandatory and can be audited successfully.
d. The WBS, schedule, and activity network identify the processes to be employed on the project, their sequence, and their critical dependencies.
e. Software development plans contain logical descriptions of the process(es) to be employed on a software project (as exemplified in Table 3-3). These processes can be documented through references to the building blocks that will be used on the project along with descriptions of the modifications and waivers that provide the process tailoring specific to the project.
f. The software development plan forms the foundation for measurement to be implemented on a software project. It is important to ensure that the elements of the plan are measurable.
g. By using a defined, documented process to tailor the organization's standard software process to the needs of a project, a base of information can be developed that will help members of an organization understand the types of variations that can exist between projects and make the adjustments necessary to fulfill the needs of the project prior to project implementation.
The only way to finally prove the value of tailoring the OSSP to the needs of a project is to do it and to measure the results in improvements in the planning process and in project performance.
LIST OF REFERENCES
DOD-STD-2167A Defense System Software Development, 29 February 1988 GINS95 Ginsberg, Mark, "Tailoring and the CMM," Presentation to SEI Symposium, September 1995 LAKE93 Lake, Jerry, "The Work Breakdown Structure - It's Much More Than a Cost-Reporting Structure," pp. 3-9, Program Manager, July-August 1993 MAIB94 Defense System Software Development DOD-STD-2167A & DOD-STD-2168 Tailoring Tips & Software Development Cycle Chart, (c) David Maibor Associates, Inc., 1994 MIL-STD-498 Software Development and Documentation, 5 December 1994 MIL-STD-881A Work Breakdown Structures for Defense Materiel Items MIL-STD-882C System Safety Program Requirements, 19 January 1993 MIL-STD-1521B, Technical Reviews and Audits for Systems, Equipment, and Change 1 Computer Programs, 19 December 1985 PAUL93 Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber, Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24, Software Engineering Institute, February 1993
LIST OF ACRONYMS
4GL Fourth Generation Language ANSI American National Standards Institute ATE Automatic Test Equipment CDR Critical Design Review CDU Control Display Unit CFD Control Flow Diagram CMM Capability Maturity Model COTS Commercial Off-The-Shelf CPM Critical Path Method CSCI Computer Software Configuration Item CSSR Cost and Schedule Status Report DFD Data Flow Diagram DID Data Item Description FP Function Points GPS Global Positioning System GUI Graphical User Interface HUD Head-Up Display HWCI Hardware Configuration Item IDD Interface Design Description IPT Integrated Product Team IRS Interface Requirements Specification ISM Integrated Software Management KPA Key Process Area MIS Management Information System OCD Operational Concept Document PDR Preliminary Design Review PDSS Post-Development Software Support PERT Project Evaluation and Review Technique SCM Software Configuration Management SDD Software Design Description SEE Software Engineering Environment SEI Software Engineering Institute SEPG Software Engineering Process Group SLOC Source Lines of Code SPD Software Process Definition SPI Software Process Improvement SQA Software Quality Assurance SRS Software Requirements Specification SSDD System/Subsystem Design Description SSS System/Subsystem Specification STD Software Test Description STP Software Test Plan STR Software Test Report STrP Software Transition Plan SVD Software Version Description SW Software WBS Work Breakdown Structure
No comments:
Post a Comment