Chapter 1. Software Engineering Supporting Processes

Transcription

1 Chapter 1 Software Engineering Supporting Processes 1. Introduction to IEEE/EIA Standard IEEE/EIA Standard establishes a common framework for software life cycle processes. The standard contains processes, activities and tasks that are to be applied during the acquisition of a system that contains software, a stand-alone software product, and software service during the supply, development, operation, and maintenance phases of software products. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) published ISO/IEC 12207, Information Technology - Software Life Cycle Processes, in August IEEE/EIA Standard is an American version of the international standard. IEEE/EIA Standard consists of clarifications, additions, and changes accepted by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Association (EIA) during a joint project by the two organizations. IEEE/EIA Standard contains concepts and guidelines to foster better understanding and application of the standard. Thus, this standard provides industry a basis for software practices that is usable for both national and international businesses. IEEE/EIA Standard may be used to: Acquire, supply, develop, operate, and maintain software. Support the above functions in the form of quality assurance, configuration management, joint reviews, audits, verification, validation, problem resolution, and documentation. Manage and improve the organization's processes and personnel. Establish software management and engineering environments based upon the life cycle processes as they are adapted and tailored to serve business needs. Foster improved understanding between customers and vendors and among the parties involved in the life cycle of a software product. Facilitate world trade in software. IEEE/EIA Standard is partitioned into three parts. The three parts are: IEEE/EIA Standard , Standard for Information Technology» Software Life Cycle Processes: Contains ISO/IEC in its original form and six additional annexes (E through J): Basic concepts; Compliance; Life cycle process objectives; Life cycle data objectives; Relationships; and Errata. A unique IEEE/EIA foreword is included. IEEE/EIA Standard , Guide for ISO/IEC 12207, Standard for Information Technology -- Software Life Cycle Processes - Life cycle Data: Provides additional guidance on recording life cycle data. 1

2 IEEE/EIA PI , Guide for ISO/IEC , Standard for Information Technology Software Life Cycle Processes -- Implementation Considerations: Provides additions, alternatives, and clarifications to ISO/IEC 12207's life cycle processes as derived from U.S. practices. 2. Application of IEEE/EIA Standard This paragraph lists the software life cycle processes that can be employed to acquire, supply, develop, operate, and maintain software products. IEEE/EIA Standard groups the activities that may be performed during the life cycle of software into five primary processes, eight supporting processes, and four organizational processes. One of the primary processes, development, is emphasized in this tutorial set. 2.1 Development processes The development process contains the activities and tasks of the developer. The process contains the activities for requirements analysis, design, coding, integration, testing, and installation and acceptance related to software products. It may contain system related activities if stipulated in the contract. The developer performs or supports the activities in this process in accordance with the contract. The developer manages the development process at the project level following the management process, which is instantiated in this process. The developer next establishes an infrastructure under the process following the infrastructure process. Lastly, the developer tailors the process for the project; and manages the process at the organizational level following the improvement process and the training process. This process consists of the following activities: 1. Process implementation 2. System requirements analysis 3. System architectural design 4. Software requirements analysis 5. Software architectural design 6. Software detailed design 7. Software coding and testing 8. Software integration 9. Software qualification testing 10. System integration 11. System qualification testing 12. Software installation 13. Software acceptance support. This tutorial covers only seven of the above processes: system requirements analysis, design and software requirements, software architecture and detailed design, implementation (coding), testing and maintenance.8 are listed below 2

3 1. System requirements analysis. Describes the functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, maintenance requirements, design constraints and system measurements. 2. System architectural design. Identifies items of hardware, software, and manualoperations. All system requirements should be allocated among the items. Hardware configuration items, software configuration items, and manual operations are subsequently identified from these items. 3. Software requirements analysis. Establishes and documents software requirements including functional, performance, external interfaces, design constraints, and quality characteristics (see ISO/IEC Standard 9126 for details). 4. Software architectural design. Transforms software item requirements into an architecture that describes its top-level structure and identifies the software components. Each requirement for the software item is allocated to its corresponding software component and further refined to facilitate detailed design. 5. Software detailed design. Develops a detailed design for each software component of the software item. The software components are refined into lower levels containing software units that can be coded, compiled, and tested. All software requirements are allocated from the software components to software units. 6. Software coding and unit testing. Code and unit test each software configuration item. 7'. Software integration and testing. Integrate the software units and software components into the software system. Perform qualification testing to ensure the final system meets the software requirements. 8. Software maintenance. Modification of a software product to correct faults, to improve performance or other attributes, or to adapt the product to a changing environment. 2.2 Supporting life cycle processes The supporting life cycle processes consist of eight processes. A supporting process supports another process as an integral part with a distinct purpose and contributes to the success and quality of the software project. A supporting process is employed and executed, as needed, by another process. The supporting processes are: 1. Documentation process. Defines the activities for recording the information produced by a life cycle process. 2. Configuration management process. Defines the configuration management activities. 3. Quality assurance process. Defines the activities for objectively assuring that software products and processes are in conformance with their specified requirements and adhere to their established plans. Joint reviews, audits, verification, and validation may be used as techniques of quality assurance. 3

4 4. Verification process. Defines the activities (for the acquirer, the supplier, or an independent party) for verifying the software products and services in varying depth depending on the software project. 5. Validation process. Defines the activities (for the acquirer, the supplier, or an independent party) for validating the software products belonging to the software project. 6. Joint review process. Defines the activities for evaluating the status and products of a project. This process may be employed by any two parties, where one party (reviewing party) reviews another party (reviewed party) in a joint forum. 7. Audit process. Defines the activities for determining compliance with the requirements, plans, and contract. This process may be employed by any two parties, where one party (auditing party) audits the software products or activities of another party (audited party). 8. Problem resolution process. Defines a process for analyzing and removing the problems (including non-conformance), regardless of nature or source, which are discovered during the execution of development, operation, maintenance, or other processes. 2.3 Organizational life cycle processes The organizational life cycle processes consist of four processes. These are employed by an organization to establish and implement an underlying structure composed of associated life cycle processes and personnel, then used to continuously improve the structure and processes. They are typically employed outside the realm of specific projects and contracts; however, lessons from such projects and contracts contribute to the improvement of the organization. The organizational processes are: 1. Management process. Defines the basic activities of management, including project management related to the execution of a life cycle process. 2. Infrastructure process. Defines the basic activities for establishing the underlying structure of a life cycle process. 3. Improvement process. Defines the basic activities that an organization (acquirer, supplier, developer, operator, maintainer, or the manager of another process) performs for establishing, measuring, controlling, and improving its life cycle process. 4. Training process. Defines the activities for providing adequately trained personnel. 3. Introduction to Tutorial This tutorial (Volume 2 of the set) has been partitioned into chapters along the lines of the supporting and organizational processes of IEEE/EIA Standard (A description of the development processes can be found in Volume 1 of this tutorial set). In accordance with accepted practices, verification and validation and reviews and audits are combined into one chapter. Problem resolution process has been combined with software configuration management, primarily due to the dearth of publications on the subject. Improvement and training are included since both subjects are smaller in scope. AH other supporting and organizational processes are isolated into separate chapters. 4

5 Each chapter is initiated with an introduction that introduces both the subject and the supporting papers and standards. Each introduction incorporates the appropriate clauses from IEEE/EIA Standard In general, there is one paper and one standard for each supporting process. However, there are some exceptions: The IEEE Computer Society did not develop a general documentation process standard. The most applicable standard is IEEE Standard for Users Documentation, which is included. The IEEE Computer Society did not develop a problem resolution process standard. Therefore, a standard is not provided. The software Review and Audits chapter contains two papers: one by John Marciniak discussing reviews and audits and the other by Frank Ackerman describing software inspections. These were included to provide adequate coverage of these areas. The standards for the management process can be found in a separate Computer Society Press tutorial, Software Engineering Project Management, 2nd edition, by Richard H. Thayer. Be sure to obtain the latest printing, dated The three standards included in the Project Management tutorial are: > IEEE Standard , IEEE Standard for Software Project Management Plans (draft) r" IEEE Standard , IEEE Recommended Practice for Software Acquisition > IEEE Standard , IEEE Standard for Software Life Cycle Processes- Risk Management. The last three operational processes infrastructure, improvement, and training -- do not have matching IEEE standards. However, papers describing these processes are provided. 4. Articles A very short paper by Raghu Singh is included in this chapter, which provides additional information on IEEE/EIA Standard and to provide credit to the standards working group for their efforts. Raghu Singh (IEEE Co-chair) and Perry DeWeese (EIA Co-chair) were chairs of the IEEE/EIA Standard working group and Leonard Tripp (IEEE Cochair) and Perry DeWeese (EIA Co-chair) were chairs of the IEEE/EIA Standard working group.

6

7 The Software Life Cycle Processes standard Raghu Singh Space and Naval Warfare Systems Command Anew standard, Software Life Cycle Processes (ISO/IEC 12207), developed over the past six years, has recently been approved by JTC1 (Joint Technical Committee 1 of the International Organization for Standardization and the International Electrotechnical Commission). While software has been established as an integral part of scientific and business disciplines, environments for developing and managing software have proliferated without a common, uniform framework for the software life cycle. This standard provides such a framework, so that software practitioners can "speak the same language" when they create and manage software. Practitioners can use the framework to acquire, supply, develop, operate, and maintain software. The processes The new standard establishes a top-level architecture for the software life cycle, from concept definition to disposal. The architecture is built with a set of processes and interfaces between those processes. The processes are derived and identified on the basis of the principles of modularity and responsibility. Each process is placed under the responsibility of a party (or participant) in the software life cycle. The party uses the processes to fulfill its business purpose. The 17 processes are grouped into three broad classes: primary, supporting, and organizational. The five primary processes are acquisition, supply, development, operation, and maintenance; they are the prime movers in the life cycle. The eight supporting processes are documentation, config- UFE CYCLE Acquisition The activities and tasks of the acquirer of software products and services. The acquirer may be the owner or a user. Supply- The activities and tasks of the supplier providing development, operation, or maintenance service to the acquirer. Development The activities and tasks of the software developer. This developer may be required to perform or support system-level activities. Operation The activities and tasks of the operator of a system containing software. Maintenance The activities and tasks of the maintainer. This process uses the development process when software is modified. Documentation Used to record information produced by a life cycle process. Configuration Management Used to identify and baseline software (configuration) items; control their modification and release; record and report their status; and control their storage, handling, and delivery. Quality Assurance Assures independent and objective compliance of products and services and adherence of plans to contractual requirements. To prevent bias, the process is kept autonomous that is, divorced from persons directly responsible for the products or services. Verification Used to verify an activity's products against requirements established by previous activities. Validation Used to determine whether the final product fulfills its specific intended use. (Verification and PROCESSES Validation may be combined into one Verification and Validation Process or may be conducted by an independent party. In the latter situation, the processes are called Independent Verification Process, Independent Validation Process, or Independent Verification and Validation Process.) Joint Review Used by the reviewing and reviewed parties to jointly review technical status and progress. Audit Used by an auditor to assess an organization's products and tasks, but with emphasis on compliance with requirements and plans. Problem Resolution A closed-loop process for resolving problems and nonconformances, taking corrective actions, and reversing trends in those problems or nonconformances. Management Provides the generic activities and tasks for managing a software life cycle process. The management-related tasks of the primary processes and of some supporting processes are instantiations of this process. Infrastructure Used to establish and maintain the infrastructure needed for a life cycle process. Improvement Used to assess, measure, control, and improve a life cycle process. Training Used to acquire or develop personnel resources and skills. Tailoring A special, normative process used to tailor the standard to a particular project. This process itself, however, cannot be tailored. 7 November 1995

8 uration management, quality assurance, joint review, audit, verification, validation, and problem resolution. A supporting process supports another process with a distinct purpose. The four organizational processes are management, infrastructure, improvement, and training. An organization may use these processes at the corporate level to establish, implement, manage, and improve its life cycle processes. Each process is defined in terms of its own constituent activities, and each of these is defined in terms of its constituent tasks. There are 74 activities and 224 tasks. A task is expressed as a requirement, a self-declaration, a recommendation, or a permissible action. Attributes The Software Life Cycle Processes standard establishes the necessary link between the software and its parent system, defining a narrow spectrum for the system life cycle and placing the software life cycle within it. Software is culled out of the system, designed and implemented, and integrated back into the system. Thus, software engineers participate in systems engineering. The standard also implements TQM (total quality management) principles. It equips each process with a built-in "plan-do-check-act" cycle and appropriates quality-related tasks to each process. Moreover, the standard is flexible in usage. An organization, a project, or the parties to an agreement can select appropriate processes, activities, and tasks to fulfill a particular business purpose. An organization can execute T he standard can be applied internally by an organization or contractually by ; v :iw;f^;n Crt»;: more than one process, and a process can be executed by more than one organization. And the standard can be applied internally by an organization or contractually by two or more parties. The tasks are expressed in contractual language. When applied solely within an organization or by an individual, the contractual language is interpreted as self-imposed tasks. 1SO/IEC is responsive to the rapidly evolving software technologies. It can be used with known software engineering models, methods, and environments. Moreover, it provides an acquirer an avenue for specifying a product or service, while encouraging the supplier to be creative in using appropriate technologies. According to the standard, certain outputs from the processes are documented. However, the details of specific metrics and indicators and the formats for the outputs are left to the standard's users. Finally, the standard permits compliance at the project and organizational levels. Appropriate processes, activities, and tasks are selected and tailored for a particular project's compliance. At the organizational level, as a condition of trade, a public declaration specifies a set of processes, activities, and tasks from the standard that suppliers to the organization comply with. THE SOFTWARE LIFE CYCLE PROCESSES standard is not a substitute for systematic, disciplined management and engineering of software systems. The standard merely provides a framework within which the processes, activities, and tasks can be judiciously selected, planned, and executed. One key point to remember is that the standard contains only a set of well-defined building blocks (processes); the user of the standard must select, tailor, and assemble these processes appropriately and cost-effectively for the project or organization. However, the standard strongly recommends that such tailoring preserve the architecture, intent, and integrity of the standard. Acknowledgments This standard was developed under the sponsorship of Subcommittee 7 (Software Engineering) of the Joint Technical Committee 1 (Information Technology) of ISO and IEC. The working-group convener was James R. Roberts of the US (affiliated with Bell Communications Research) and the editor of the standard was the author of this article. The following countries participated in this standard's development: Australia, Brazil, Canada, Czech Republic, Denmark, Finland, France, Germany, Hungary, Ireland, Italy, Japan, Korea, The Netherlands, Spain, Sweden, the United Kingdom, and the United States. A guidebook that will provide basic concepts and guidance on applying ISO/IEC12207 is under development. For more information on this standard, contact Raghu Singh, Space and Naval Warfare Systems Command, SPAWAR 10-12, 2451 Crystal Dr. (CPK-5), Arlington, VA ; singhr@$mtp-gw.spawar. navy. mil. 8