4.1 Introduction to the Example
This example illustrates the issues that need to be addressed to tailor an organization's standard software process to the needs of a specific project. It includes both a sample project scenario and a set of software process characteristics. The example project and process characteristics are highly simplified to help show how software processes can be tailored to the needs of a project.
4.1.1 Project Scenario
A software developer, known as XDEVEL, has been tasked to build an upgrade to one of the fighter aircraft used by the U.S. Air Force.
This aircraft needs to update its navigation system with Global Positioning System (GPS) capabilities. The GPS model chosen for this aircraft has been used in a similar application for a Navy aircraft, so it is considered to be an off-the-shelf item. Modifications to the GPS software will be required to integrate the GPS into the Air Force aircraft. Aircraft software will need to be written (and/ or modified) to support the following needs:
a. Integrate the GPS into the existing navigation system.
b. Display updated navigation information on the pilot's Head-Up Display (HUD).
c. Allow the pilot access to the modified navigation data through the Control Display Unit (CDU).
d. Communicate GPS information to ground control and to other aircraft in a mission. (No equipment upgrades are planned to support the increased communications requirements.)
The requirements for this modification are well known. The current navigation system and interface software for the aircraft is written in C, and due to the limited nature of the changes to the navigation software, no change in language will be required. MIL-STD-498 will be used as the software development and documentation standard for this acquisition.
The contractor that developed the GPS system for the Navy aircraft will make the GPS software modifications on a subcontract to XDEVEL. XDEVEL will provide a specification of the modification requirements to the subcontractor. This will reduce the cost and risk associated with modifying the GPS software.
XDEVEL has determined that about 9,000 SLOC will need to be developed and/or modified to implement this new capability in the aircraft. The condition of the existing navigation software is not known and the customer wants formal documentation, so it was assumed that the productivity for the development team will be about that of new development.
The acquirer will supply a System/Subsystem Specification (SSS), a System Design Description (SSDD), and an Operational Concept Document (OCD). The acquirer will modify the OCD during development to reflect the changing needs of the system.
The developer will be responsible for the following technical documents:
a. Software and Interface Requirements Specifications (SRS & IRS).
b. Software and Interface Design Descriptions (SDD & IDD).
c. Software test documents, including:
1. Software Test Plan (STP).
2. Software Test Description (STD).
3. Software Test Report (STR).
The developer will be responsible also for the following management and support documents:
a. Software Development Plan.
b. Software Transition Plan (STrP).
c. A Software Version Description (SVD).
This means that the software effort will take approximately 3.25 man-years over a period of 12 months. The development, test, and technical documentation effort will be approximately 2.25 man-years; the remaining 1.0 man-year will be dedicated to software project management, the support documents, SQA, and SCM. User documentation will be produced as part of the new CDU development effort. The GPS subcontractor will develop the SRS and SDD for the GPS from existing materials created for the Navy.
The pilots for this aircraft dislike the CDU and want a replacement. The current CDU has a very small keypad, and the display is only 4 lines by 40 characters. The pilots would like to at least double the display capacity, increase the display visibility, change the keypad, and add new query capabilities. The pilots want an opportunity to help determine the requirements for the CDU and to have significant inputs to the changes to the user interface.
Since the pilots want so much input to the new CDU, XDEVEL feels that prototyping will be useful to support the user interface development. Also, it is not known how many new capabilities will be added to implement the pilots' query requirements.
XDEVEL is assuming that the new CDU will have all new software. The Air Force wants the new CDU to be implemented in Ada, and the existing code is in assembly language so it is assumed that there will be no software code reuse. MIL-STD-498 also will be used for the CDU development, and as with the GPS integration, the customer is requesting significant amounts of formal documentation.
Based on XDEVEL's knowledge of the existing CDU and a rational appraisal of the possible new requirements, XDEVEL assumes that the new CDU will require about 20,000 SLOC to implement. Given the unknown nature of the new requirements, this is a soft estimate. The customer wants the new CDU to be a significant improvement from the current version, so there may be some flexibility to renegotiate the terms of the contract when the first sets of prototypes are completed and approved by the pilots.
In both parts of this aircraft upgrade, software supportability is a primary concern for the customer. Thus, planning for the software transition to the Government and for Post Deployment Software Support (PDSS) is stressed in the acquisition. This may add labor to the existing software estimates from XDEVEL.
This report uses the GPS example. The CDU example is described for the reader to use to explore the process tailoring concepts independently.
4.1.2 Introduction to the XDEVEL Standard Software Process
XDEVEL is a respected, successful development organization. The organization has a well defined, flexible process for planning for and developing software. It is known also as being an open and innovative place to work. XDEVEL received its CMM assessment as a Level 3 organization approximately one year ago.
Early software project planning is stressed, and the plans are developed to integrate effectively with the other engineering plans for each project. There is strong communication among all the engineering disciplines, and each new project is managed from an integrated system view.
The software development plans are reviewed and approved by all affected engineering groups and upper management before implementation. Software estimates are derived through expert analysis and documented for use throughout the project's life. These estimates are backed up with outputs from estimation tools that are used to give a "reality check" to the experts' initial ideas. Actual project data is retained to support an estimation improvement effort under way at XDEVEL.
Software project management metrics are used to provide visibility into project performance. When performance deviates from the initial plans, the project manager is responsible for either making changes to the way the project is being handled to bring the project back into conformance with the plan or replanning, as necessary. Software subcontracts are managed using a set of defined policies and procedures.
Software requirements, design, and code inspections are used to support development. Defect metrics from the inspections are maintained. Other product related metrics are identified and maintained for each development effort to help keep reasonable visibility into the development effort. These metrics also are used to support software project management and risk assessment.
SQA and SCM are part of all software development and maintenance efforts. Metrics from SQA product and process audits are used to help improve product quality and software process efficiency. SCM is used both in its classical role and as a support mechanism for software requirements management.
All software engineering personnel have and maintain a personal training plan that helps them keep up-to-date on their requisite engineering skills. Based on project needs, extra training may be required for special needs.
XDEVEL has three basic software life cycles that are approved for use within the organization. They are: waterfall; incremental development, which uses a basic waterfall within each "block release cycle" for an evolving product; and a spiral model that relies heavily on prototyping for the first iteration or two through the spiral. Alternatives to these life cycles are allowed as long as the alternatives are documented and approved by upper management and the SEPG. The "approved" engineering processes for XDEVEL are maintained on-line for easy access.
Testing also has defined processes from the unit level through to software system testing. All testing that comprises the formal qualification testing is performed by independent test personnel.
During the last three years, XDEVEL has implemented a "lessons learned" policy that requires that at the end of a software project, the project team meets to discuss the successes and problems encountered during project execution. The lessons learned are documented and maintained to help new projects avoid problems and to support software process improvement. The lessons learned, metrics data, approved software and management processes, and other useful information is maintained in a software engineering library for the corporation. Much of the information is accessible on line. The information that exists only in hard copy is catalogued and referenced in the on-line library. All information about each project is cross referenced for easy retrieval. SCM developed and maintains the library.
A team of engineers and managers from the software engineering organization are responsible for maintaining the building blocks in a library, keeping the approved software management and engineering processes up to date, and identifying new opportunities for improvement. This team reports to the manager of software engineering and to the corporate vice president of engineering. The vice president of engineering maintains a keen interest in the software engineering processes for the corporation. The manager of software engineering and the vice president of engineering are responsible for providing quarterly reports to the company president on the state of software engineering and software process improvement.
No comments:
Post a Comment