ISO 9001 for Small Projects

Chapter

8

ISO 9001 for Small Projects

INTRODUCTION TO ISO 9001 FOR SMALL PROJECTS

Many organizations are intimidated by the amount of documentation associated with ISO 9001 conformance requirements. The benefit of ISO 9001 implementation in support of larger software development efforts is something that has long been recognized and accepted. Project managers embrace ISO 9001 for larger software development efforts as it provides early notice of project problems. Smaller pro-jects* should also strive for process control and improvement and can benefit from

it as well.

The likelihood of small businesses encountering ISO 9001 implementation prob-lems is potentially greater due to:

• Minimal available resources

• Difficulty in understanding and applying the standards

• Costs involved in setting up and maintaining a quality management system One thing that distinguishes small settings from medium to large settings is that the resources an organization would expect to use to support process improvement efforts (appraisals, consulting, and infrastructure building) would be a large per-centage of its operating budget. ISO 9001 Clauses 4.1 and 7.3 require that all crite-ria and assumptions taken into account in producing the design and development should be carefully considered and written down. This should be used in checks to make sure that there are neither conflicts nor omissions.

To help, ISO sells a book entitled ISO 9001 for Small Businesses (ISBN 92-67-10363-6). With only a few people involved, communications in a small business can often be simple and more direct. Individuals are expected to undertake a wide variety of tasks within the business. Decision making is confined to a few people (or even one). The key to implementing ISO 9001 controls on a smaller scale is to

*A small project is defined here as a project having 20 or less individuals. Each organization must decide on what it defines as a small project.

Practical Supportfor ISO 9001 Software Project Documentation.ByS. Land and J. Walz 235

have the process documentation in place. Also, instead of having all the documenta-tion relate to a single project, the supporting plans (i.e., software requirements man-agement, configuration manman-agement, quality assurance, etc.) describe the processes adopted by the managing organization. In a typical organization, you will find three layers of management: project, program, and organization.

To provide support for the small software project, the policies are developed at the organizational level and the supporting plans at the program level. The project is then required to follow these program-level plans and only write its project-specific documentation. This approach provides several immediate benefits. It allows the technical manager to get down to the business of managing development, encour-ages standardization across the organization, and encourencour-ages participation in process definition activities at the organizational level.

PROJECT MANAGEMENT PLAN-SMALL PROJECTS

The purpose of the small project plan (SPP) is to help project managers during the development of a small software project. This template is useful for projects with time estimates ranging from one person-month to one person-year. It is designed for projects that strive to follow repeatable and defined processes. This project plan is used to refer to existing organizational policies, plans, and procedures. Exceptions to existing policies, plans, and procedures must be documented with additional in-formation appropriate to each project's SPP.

The SPP provides a convenient way to gather and report the critical information necessary for a small project without incurring the overhead of documentation nec-essary to support the additional communication channels of a larger project. Soft-ware quality assurance (SQA) procedures will be captured in Appendix A of the SPP. Appendix B will be used to document software configuration management (SCM) activities. Project management and oversight activities (i.e., risk tracking and problem reporting) will be documented in Appendix C of the SPP. Require-ments for the project will be captured in Appendix D of the SPP rather than a sepa-rate software requirements specification (SRS). Table 8-1 provides a suggested out-line for a SPP.

Small Software Project Management Plan

Document Guidance

This small software project management plan template is designed to facilitate the definition of processes and procedures relating to software project management ac-tivities. This template was developed using IEEE Standards 12207.0 and 12207.1, Standards for Information Technology-Software Life Cycle Processes [39]; IEEE Std 1058, IEEE Standard for Software Project Management Plans [15]; IEEE Std 730, IEEE Standard for Software Quality Assurance Plans [3]; IEEE Std 828, IEEE Standard for Software Configuration Management Plans [4]; IEEE Std 830, IEEE Recommended Practice for Software Requirements Specifications [6]; IEEE Std

Table8-1. Small software project management plan document outline

Title Page Revision Page Table of Contents 1. Introduction 1.1 Identification 1.2 Scope 1.3 Document Overview 1.4 Relationship to Other Plans 2. Acronyms and Definitions 3. References 4. Overview 4.1 Relationships 4.2 Source Code 4.3 Documentation 4.4 Project Resources 4.5 Project Constraints 5. Software Process

5.1 Software Development Process 5.1.1 Life Cycle Model 5.2 Software Engineering Activities

5.2.1 Handling of Critical Requirements 5.2.2 Recording Rationale

5.2.3 Computer Hardware Resource Utilization 5.2.4 Reusable Software

5.2.5 Software Testing 6. Schedule

Appendix A. Software Quality Assurance Appendix B. Software Configuration Management Appendix C. Risk Tracking/Project Oversight Appendix D. Software Requirements Specification Requirements Traceability Matrix

1044, Standard Classification for Software Anomalies [13]; IEEE Std 982.1, Stan-dard Dictionary of Measures to Produce Reliable Software [7]; IEEE Std 1045, Standard for Software Productivity Metrics [14]; and IEEE Std 1061, Software Quality Metrics Methodology [16], which have been adapted to support ISO 9001 requirements.

This plan must be supplemented with separate supporting plans. The idea is that this plan may be used to support the development of an SPP for projects operating under the same configuration management, quality assurance, risk management, and so on. policies and procedures. This eliminates redundant documentation, en-courages conformity among development efforts, facilitates process improvement through the use of a common approach, and more readily allows for the cross-pro-ject transition of personnel.

Introduction

This section should provide a brief summary description of the project and the pur-pose of this document.

Identification

This subsection should briefly identify the system and software to which this SPP applies. It should include such items as identification number(s), title(s), abbrevia-tions(s), version number(s), and release number(s). It should also outline deliver-ables, special conditions of delivery, or other restrictions/requirements (e.g., deliv-ery media). An example follows:

This document applies to the software development effort in support of the development of [Software Project} Version [xx}. A detailed develop-ment timeline in support of this effort is provided in the supporting pro-ject Master Schedule.

Scope

This subsection should briefly state the purpose of the system and software to which this SPP applies. It should describe the general nature of the existing sys-tem/software and summarize the history of system development, operation, and maintenance. It should also identify the project sponsor, acquirer, user, developer, support agencies, current and planned operating sites, and relationship of this pro-ject to other propro-jects. This overview should not be construed as an official statement of product requirements. It will only provide a brief description of the system/soft-ware and will reference detailed product requirements outlined in the SRS, Appen-dix D. An example follows:

[Project Name} was developed for the [Customer Information}. [Brief summary explanation ofproduct.}

This overview shall not be construed as an official statement ofprod-uct requirements. It will only provide a brief description of the system/software and will reference detailed product requirements out-lined in the [Project Name] SRS.

Document Overview

This subsection should summarize the purpose, contents, and any security or priva-cy issues that should be considered during the development and implementation of the SPP. It should specify the plans for producing scheduled and unscheduled up-dates to the SPP and methods for disseminating those upup-dates. This subsection should also explain the mechanisms used to place the initial version of the SPP

un-der change control and to control subsequent changes to the SPP. An example is provided:

The purpose ofthe [Project Name] Small Project Plan (SPP) is to guide [Company Name] project management during the development of[Prod-uct Identification]. Software Quality Assurance (SQA) procedures are captured in Appendix A ofthe SPP. Appendix B is used to document Soft-ware Configuration Management (SCM) activities where these activities deviate from [Organization Name] SCM Plan. Project management and oversight activities (i.e., risk tracking, problem reporting) are document-ed in AppendixC ofthe SPP where these activities deviate from the [Or-ganization Name] Risk Management Plan. Requirements for the project will be captured in the [Project Name] Software Requirements Specifica-tion (SRS). This plan will be placed under configuraSpecifica-tion management controls according the [Organization Name] Software Configuration Management Plan. Updates to this plan will be handled according to rel-evant SCM procedures and reviews as described in the [Organization Name] Software Quality Assurance Plan.

Relationship toOther Plans

This subsection should describe the relationship of the SPP to other project man-agement plans. If organizational plans are followed, this should be noted here. An example is provided:

There are several other [Organization Name] documents that support the information contained within this plan. These documents include: [Orga-nization Name] Software Configuration Management Plan, [Organiza-tion Name] Software Quality Assurance Plan, and [Organiza[Organiza-tion Name] Measurement and Measurements Plan. [Project Name] project-specific documentation relating to this plan include: [Project Name] Software Requirements Specifications and [Project Name] Master Schedule. This plan has been developed in accordance with all [Organization Name] software development processes, policies, and procedures.

Acronyms and Definitions

This section should identify acronyms and definitions used within the SPP for each project.

References

This section should identify the specific references used within the SPP. Reference to all associated software project documentation, including the statement of work and any amendments should be included.

Overview

This section of the SPP should list the items to be delivered to the customer, deliv-ery dates, delivdeliv-ery locations, and quantities required to satisfy the terms of the con-tract. This list should not be construed as an official statement of product require-ments. It will only provide an outline of the system/software requirements and will reference detailed product requirements outlined in the SRS, Appendix D. An ex-ample follows:

The project schedule in support of [Project Name] was initiated [Date] with a target completion date of [Date]. Incremental product deliveries may be requested, but none are identified at this time. The delivery re-quirements are to install [Project Name] on the current [Project Name] external website. [Project Name] will be delivered once deployment has occurred, and [Customer Name] acceptance of the product. [Customer Name] may request the installation of [Product Name] at one additional location. A [Project Name] user's manual shall also be considered to be required as part ofthis delivery. Detailed schedule guidance isprovided by [document name], located [document location]. Detailed requirements in-formation is provided by [document name], located [document location].

Relationships

This subsection should identify interface requirements and concurrent or critical de-velopment efforts that may directly or indirectly affect product dede-velopment efforts.

SOUTce Code

This subsection should identify source code deliverables. An example is provided: There are no requirements for source code deliverables.

If

Documentation

This subsection should itemize documentation deliverables and their required for-mat. It should also contain, either directly or by reference, the documentation plan for the software project. This documentation plan may either be a separate docu-ment, stating how documentation is going to be developed and delivered, or may be included in this plan as references to existing standards with documentation deliver-ables and schedule detailed herein.Anexample follows:

[Project Name] will have online help; a user's manual will be created from this online help system. The user's manual will be posted on the [Project Name] website and will be available for download by requesting

customers. Please refer to the [Project Name] master schedule for a de-velopment timeline ofassociated user's online help and manual.

Project Resources

This subsection should describe the project's approach by describing the tasks (e.g., req.~design ~ implementation~test) and efforts (update documentation, etc.) required to successfully complete the project. It should state the nature of each ma-jor project function or activity and identify the individuals who are responsible for those functions or activities.

This section should also describe the makeup of the team, project roles, and in-ternal management structure of the project. Diagrams may be used to depict the lines of authority, responsibility, and communication within the project. Figure 8-1 is an example of an organizational chart.

The relationship and interfaces between the project team and all nonproject orga-nizations should also be defined by the SPP. Minimum interfaces include those with the customer, elements (management, SQA, SCM, etc.), and other support teams. Relationships with other contracting agencies or organizations outside the scope of the project that will impact the project require special attention within this section.

Project Constraints

This subsection should describe the limits of the project, including interfaces with other projects, the application of the program's SCM and SQA (including any di-vergence from those plans), and the relationship with the project's customer. This section should also describe the administrative and managerial boundaries between the project and each of the following entities: parent organization, customer organi-zation, subcontracted organizations, or any organizational entities that interact with the project.

This subsection should capture the anticipated volume of the project through quantifiable measurements such as lines of code, function points, and number of units modified, number of pages of documentation generated or changed. It may be

"...-~ Les Leader Project Leader Chief Designer I I I I

Tim Tester _{Ida Interface Carl Coder} Project Design _{Proiect Imolemenation Proiect Imolementation}

Project Tester User's Manual SCM SQA

useful, if the project is well defined in advance, to break down project activities and perform size estimates on each individual activity. This information can then be tied to the project schedule.

Software Development Process

This subsection of the SPP should define the relationships among major project functions and activities by specifying the timing of major milestones, baselines, re-views, work products, project deliverables, and signature approvals. The process model may be described using a combination of graphical and textual notations that include project initiation and project termination activities.

Life Cycle Model

This subsection of the SPP should identify the life cycle models used for the soft-ware development process. It should describe the project organizational structure, organizational boundaries and interfaces, and individual responsibilities for the var-ious software development elements.

Software Engineering Activities

Handling of Critical Requirements. This subsection should identify the overall software engineering methodologies to be used during requirements elicitation and system design. An example follows:

Please refer to the [Organization Name] Software Requirements Man-agement Plan for information regarding the elicitation and manMan-agement ofcustomer requirements.

Recording Rationale. This subsection should define the methodologies used to capture design and implementation decisions. An example is provided:

All initial design and implementation decisions will be recorded and posted in the [Project Name] portal project workspace. All formal design documentation will follow the format as described in the [Organization Name] Design Documentation Template.

Computer Hardware Resource Utilization. This subsection should describe the approach to be followed for allocating computer hardware resources and monitoring their utilization. An example text is provided:

All computer hardware resource utilization is identified in the [Project Name] Spend Plan. Resource utilization is billed hourly as an associated site contract charge. Twenty thousand dollars has been allocated to sup-port the procurement ofa development environment. Charges in supsup-port

ofproject equipment purchases will be recorded by the Project Manager, [Name}, and reported to senior management weekly.

Reusable Software. This subsection should describe the approach for identifying, evaluating, and reporting opportunities to develop reusable software products. The following example is provided:

It is the responsibility ofeach developer to identify reusable code during the development process. Any item identified will be placed in the [Orga-nization Name] Reuse library that is hosted on the [location}. It is the re-sponsibility ofeach programmer to determine whether items in the reuse library may be employed during [Project Name] development.

Software Testing. This subsection should be further divided to describe the approach for software implementation and unit testing. See the following:

This project will use existing templates for software test plans and soft-ware unit testing when planning for testing. These separate documents will be hosted on the [location].

Schedule

This section of the SPP should be used to capture the project's schedule, including milestones and critical paths. Options include Gantt charts (Milestones Etc.™, Mi-crosoft Project'Y); Pert charts, or simple time lines. Figure 8-2 is an example schedule created with Milestones, Etc.™for a short (two month) project.

Appendix A. Software Quality Assurance

This appendix should be divided into the following sections to describe the ap-proach for software quality assurance (SQA): Software quality assurance evalua-tions, software quality assurance records, independence in software quality assur-ance, and corrective action. This appendix should reference the organizational- or program-level quality assurance policies, plans, and procedures, and should detail any deviations from the organizational standard. If a separate SQA plan has been created in support of the development work, simply provide a reference to that doc-ument as follows:

Refer to the {Organization Name] Software Quality Assurance Plan for all applicable processes and procedures.

AppendixB. Software Configuration Management

This appendix should be divided into the following sections to describe the ap-proach for software configuration management (SCM): configuration

identifica-1/20/1995

Short Software Project

Any Program ORC Corporation Page 1 of 1 1994 November I December Planning/ SRS ~ 11/1 11/4 SRRI PMR !§J 1111/8 Design/ SDD/ SDR L Y 11/9 11/18 Implementation L '\1 11/21 12/2

Code and Unit Test ~

12/2 12/9

Deliverable Documentation L '\1

11/14 12/16

Delivery/ Approval @

12/22

6 \l Scheduled

•

®

Event Event Milestone Time Completion

Figure 8-2. Sample project schedule.

tion, configuration control, configuration status accounting, configuration audits, and packaging, storage, handling, and delivery. This appendix should reference the organizational- or program-level configuration management policies, plans, and procedures, and should detail any deviations from the organizational standard. If a separate SCM plan has been created in support of the development work, simply provide a reference to that document as follows:

Refer to the [Organization Name] Software Configuration Management Plan for all applicable processes and procedures.

Appendix

C.

This appendix should be divided into the following sections to describe the ap-proach for project risk identification and tracking: risk management strategies, mea-surement activities, and identified project risks. This appendix should reference the organizational- or program-level risk and project management policies, plans, and procedures, and should detail any deviations from the organizational standard. If a separate measurement and measurements plan has been created in support of the development work, simply provide a reference to that document as follows:

The following measures will be taken as part ofproject oversight activi-ties. Please refer to the [Organization Name] Software Project Measure-ment Plan for descriptions.

(list ofmeasures)

Appendix D. Software Requirements Specification

This appendix is the equivalent of the software requirements specification (SRS) re-quired for large projects. It is produced early in the project life cycle and contains descriptions of all project requirements. This appendix should reference the organi-zational- or program-level requirements management policies, plans, and proce-dures and should detail any deviations from the organizational standard. If a sepa-rate SRS has been created in support of the development work, simply provide a reference to that document.