Capability Maturity Model for Software (SW-CMM )

Size: px
Start display at page:

Download "Capability Maturity Model for Software (SW-CMM )"

Transcription

1 PHASE-IV: SYSTEMS IMPLEMENTATION Software Quality Assurance Application Development Installation and Support Software Quality Assurance Capability Maturity Model for Software (SW-CMM ) The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes. The Software CMM has become a de facto standard for assessing and improving software processes. Through the SW-CMM, the SEI and community have put in place an effective means for modeling, defining, and measuring the maturity of the processes used by software professionals.

2 What is CMM? The Capability Maturity Model for Software describes the principles and practices underlying software process maturity and is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is organized into five maturity levels: 1) Initial. The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. 2) Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. 3) Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. 4) Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. 5) Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. Key Process Areas of CMM Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process. The key process areas at Level 2 focus on the software project's concerns related to establishing basic project management controls. They are Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management. The key process areas at Level 3 address both project and organizational issues, as the organization establishes an infrastructure that institutionalizes effective software engineering and management processes across all projects. They are Organization

3 Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are Quantitative Process Management and Software Quality Management. The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement. They are Defect Prevention, Technology Change Management, and Process Change Management. Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.

4 Software Quality Assurance (Continued) The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built and designed. The primary purpose of this document is to standardize the policies and procedures with respect to Software Quality Assurance. This document will establish a formal written policy for handling Software Quality Assurance. Additionally, the purpose is to provide quality software. Quality should be measured via a set of the following attributes: Portability: the ability of the software to be transferred easily from one computer to another. Efficiency: the ability of the software to perform with minimum use of computer resources. Usability: the ability of the software to be easily understood and used by human users. Testability: the ability of the software to be easily verified by execution. Understandability: the ability of the software to be read by a software maintained. Modifiability: the ability of the software to be revised by a software maintained. Goals Ensuring customer satisfaction through involvement of all employees in learning how to reliably produce and deliver quality software. The Software Quality Assurance Group (SQAG) should provide a structured environment for all team members to work together to improve the quality of the software and promote communication and teamwork. All Software Quality Assurance activities are planned in advance by one member from the team. Adherence of the software products and activities to the standards, procedures, and requirements is verified objectively by individuals that are not associated with the particular project. The adherence is documented by reviews. Affected groups and individuals are informed of software quality assurance activities and results. These reports will also be made available to include each project member, and the project leader. This notification will be done formally through the project review form. Noncompliance issues that can't be resolved within the software project are addressed by senior management, along with the group's project leader. Communication to the project leader can be done by several methods. If there is an actual non-compliance issue, the Non-Compliance Form can be generated with the appropriate information and sent to the proper personnel. If there is a possible upcoming problem detected, then just a communiquè to the project leader can be generated.

5 Commitment to Perform Team Members Each Team Member is responsible for learning what quality in the Software Life Cycle is and how to produce quality work throughout. Quality evolves from correct requirements, design, coding and then comprehensive testing. Oranizational Policy Each project must follow the established written organizational policy. Reviews will be performed biweekly to ensure that all SQA functions are in place and being utilized by Projects. Ability to Perform Responsibility Responsibility for Software Quality Assurance will be one member of the team. Documentation All documentation for the Software Quality Assurance groups will be maintained and archived for future reference. The format of the individual reports will depend on the circumstance and the situation at hand, but the reports in appendix four will be used and archived. Documentation of noncompliance issues will be provided to all project members upon completion of the audits and copies will be sent to all senior management. Training Team members will be made aware of their duties and responsibilities. This is one of the actions of SQA. The primary training that needs to be performed is to inform the SQA members of the policies and procedures for SQA throughout the Software Life Cycle. All objectives and activities will also be explained to the members of the SQA group. Training on the use of the tools that are to be used will be performed on an as-needed basis. Activities Performed The Software Quality Assurance group will work with the project during its early stages and through the quarter to establish plans, standards, and procedures that will add value to the software project and satisfy the constraints of the project and the organization's policies. By participating in establishing the plans, standards, and procedures, the Software Quality Assurance group helps ensure they fit the projects needs and verifies that these plans will be usable for performing reviews and audits throughout the software project life cycle to ensure quality.

6 SQA Plan A SQA plan will be prepared for each project according to the following guidelines. The SQA plan is developed in the early part of the project. In most cases this will be in the beginning of a quarter. It is recommended that the plan be developed in the beginning of a quarter so that it can be followed for the duration of a developer's (student's) time spent on the project. The SQA plan is to be developed along with the overall project plan. A copy of the project plan will be given and stored by the SCM group. The SQA plan developed for the project is reviewed by senior management (the professor), the project leader, the SQA group, the customer (if possible) and other software process groups, such as the SCM group. The SQA plan developed is placed under the control of the SCM group. The SQA plan is revised using established polices (according to configuration management) and modifications to the SQA plan must be reviewed and approved by the SQA group and senior management. Only an approved SQA plan will be used. The SQA plan for the project will follow this format. (A description for these plans is included in appendix four). Design and Coding Standards Structured Life Cycle Reviews Audits Review and Audit Guidelines Documentation Standards Configuration Management Testing Standards Verification and Validation Tools, Techniques and Methodologies Documentation Reference The SQA plan, once approved is handed to the SCM group to be placed under configuration management. SQA Group Activities The SQA group is established to execute SQA activities. The SQA group is responsible for making sure that each project follows a previously defined SQA plan (mentioned earlier). The SQA group performs random audits of each project. In order to avoid conflicts of interest, only the members of the SQA group who are not involved with the project perform the audit. Results of the audit are discussed with the full SQA group and the

7 members of the project. Any problems that are found can be discussed and resolved at this time. If a resolution cannot be reached senior management is brought in to arbitrate. The SQA group is responsible for providing management with information concerning adherence to the established software process. The SQA group is also responsible for providing management with information concerning defects in software products. The SQA group is responsible for verification and validation of the software and maintaining statistics and other information regarding defects in the code. The SQA group is expected to require at least the following resources: 1) a computer with database, spreadsheet, and word-processing software, 2) access to all documentation pertaining to the software process, 3) access to senior-management (the professor), 4) access to any revision control databases, 5) access to all requirements, design documents, and project plans. The SQA group will need to be present (or at least represented) in all meetings regarding development plans for each project. (This will be the case since one member of each project team is a member of the SQA group.) The SQA group will produce (through audits and questionnaires), evaluations of each project team with respect to adherence to software development policy, as well as evaluations of the quality of the software being developed. The SQA group will monitor deviations from established policies after a solution has been implemented to verify compliance. Follow up audits may be required to verify that the problems have been solved. (This information as with all information concerning problems will be recorded in a database.) Milestone reports will be generated at each documented milestone according to the project plan. The SQA group will be required to verify that software products meet customer requirements prior to delivery. In addition the SQA group will verify that the product meets standards. These standards are derived from the functional requirements. Any deviations will be resolved prior to release to the customer. SQA group will provide reports on the project. These reports will be made available to all members of the team for review and comment. When appropriate, the customer should also be provided with these reports, as well as senior management. Measurement and Analysis SQA Measures Measuring the quality of the software should consist of measuring the attributes that make up quality. Understandability and Modifiability:

8 o Naming conventions should be chosen for data items and logic structures that reflect and reinforce the meaning of what they do. o Make the code simple, structured and modular. o Use indentations and white space to clarify logic organization and make it visually appealing. o Organize the code logic to make it easier to read and reference. o Use a consistent and easy to understand style. o Comments at the beginning of each module, at each subfunction, complex section of code, interface, collection of data items, and individual data items. o Provide appropriate overall historic information such as a record of changes with dates and names of programmers. o To accomplish Understandability and Modifiability, the above coding standards must be followed. A review and or audit must take place to ensure that these standards are being followed. Testability: o To accomplish testability, each requirements should be traceable to a test case Usability: o Reviews must take place to verify that the systems contains the usability characteristics required for the intended user audience. Efficiency: o Efficiency must be quantified in Functional Requirements. During testing, efficiency must be evaluated and comply with the Requirements. Portability: o If portability is specified in the Requirements, then software should be able to run on other types of specified types of environments. The SQA group will maintain records related to completion of various milestones as defined in each project's SQA plan. The records will consist of separate Milestone reports. The SQA group will establish standards for projects to maintain and record results of meetings. Verifying Implementation Reviews Periodic reviews by management will be performed on at least a quarterly basis. These reviews will be conducted to ensure that the SQA group is performing all of its assigned tasks properly. Peer Reviews Reviews of SQA activities will be conducted. These reviews will focus on the activities of the SQA group with respect to the specific project. SQA Functions and Activities Assignment and Initialization of the SQA group Develop individual SQA plan for the project Review the project plan

9 Verify Milestone Completion Project Audit Project Review Product Evaluation / Audit Assignment and Initialization of SQA During the first week of the semester, the SQA member will be identified. The project leader is not allowed to be a member of the SQA. Once the SQA group is formed, one member will be selected and will function as the SQA group leader. The selection of the leader will be done by senior management. The first actions of SQA will be to review project documentation and become familiar with the project. Develop individual SQA plan After reviewing project documentation, the SQA group will review the project SQA plan that was developed by each project team and ensure that it adheres to established SQA policies and guidelines. This SQA plan must be approved by the team. If there are changes that need to be made, the SQA group will generate a "communiqué to the project leader" informing the leader of the necessary changes that are required before the plan is approved. Review of the project plan The SQA group will review each project plan to ensure that it meets all established policies. The SQA group must pay particular attention to the establishment of milestones and ensure that the milestones can be verified. If there are any problems, they must be addressed before the project plan can be accepted. The SQA group will use the "communiqué to the project leader" form to inform the project team of the needed changes or acceptance of the project plan. (Any changes to the project plan after acceptance of the project plan must be accompanied by a "Project plan change form". The SQA group must be informed of these changes to ensure that it is able to verify adherence of the project to the plan as well as established policies. Verify Milestone Completion The SQA group will verify that each milestone is completed when the appropriate deliverable is produce (i.e. design document). The SQA group is responsible for verifying that the milestone was indeed completed The SQA group is also responsible for verifying that the milestone was completed following established policy. (i.e. The SQA group will note any obvious deviations from established policy; such as the design document was not placed under configuration management.) (The SQA group member(s) that perform this verification must fill out a "Milestone Report" as provided in appendix four.)

10 Project Audit The SQA group is permitted to perform an audit of the project at any time. Audits are expected to normally be the result of a poor review of a project during one of the scheduled biweekly reviews. Project Review The SQA group will schedule biweekly reviews with each project team to evaluate the project's status and address SQA issues. These reviews are intended to be informal sit-downs with the project team. If significant problems arise (especially if they are repeated problems), the SQA group is expected to perform an audit of the project. The SQA group will file a "Biweekly Review of Project". A copy of this review will be provided to the project team. The SQA group will pay special attention to process aspects (such as use of configuration management). The SQA group is responsible for verifying that the project follows all procedures and guidelines as specified in the project's SQA plan. Product Audit/Evaluation The SQA group is also responsible for the quality of the software that is delivered. As a result the SQA group must evaluate all software before it is released. The SQA group is not expected to debug the program, but rather evaluate it for meeting requirements as well as for software defects. A form is provided in appendix four to be filled out during an evaluation (multiple copies of the form can be used if the number of defects warrants it). A copy of the product evaluation will be given to the project leader after which the project team is expected to work in fixing the problems prior to re-submitting the project to the SQA group for evaluation. Software Quality Assurance Plan Design and Coding Standards: A set of design and coding standards need to be established. Each team member must follow these standards. Structured Life Cycle: A Structured Life Cycle needs to be chosen and documented according to the project at hand. Reviews: The following reviews must take place throughout the Software Life Cycle. Requirements Reviews Design Reviews o Peer Coding Reviews Test Reviews

11 Audits: Through normal reviews, an anomaly may be spotted. In this event, an audit team is established and presented with a task and desired finding, and given resources to complete its assignment. Review and Audit Guidelines Reviews Audit qualified and available team members resources to enable the team members to perform predefined agenda (agenda must be established) a clear picture of the goals of the review qualified and available team members resources to enable the team members to perform a clear picture of the goals of the audit a commitment from the developers that they will not obstruct the audit teams' search a clout to enable the use of the finding of the audit Documentation Standards: Documentation standards must be established and documented here. Testing Standards: Testing standards must be established and documented here. Verification and Validation: Verification and Validation criteria must be established and documented here. Tools, Techniques and Methodologies: Any tools, techniques and methodologies must be stated here. Documentation Reference: Any reference to other documentation must be stated here.