KPA SUMMARY

Span of the KPA's:

REQUIREMENTS MANAGEMENT

PURPOSE: To establish a common understanding between the customer and the software project of the customer's requirements to be addressed by the software project.

WHAT IT INVOLVES:

1. Establishing and maintaining an agreement with the customer on the software project.
   

GOALS:

1. Customer requirements are controlled to form a baseline for technical and management use.
   
2. Software plans, products and activities are kept consistent with the user requirements
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy to manage the user requirements.
   

ABILITY TO PERFORM:

1. Software requirements are documented.
   
2. Adequate resources and funding are provided to manage the requirements.
   
3. Members of the project and related groups are trained to perform their RM activities.
   

ACTIVITIES PERFORMED:

1. The project reviews the requirements before they are incorporated.
   
2. The project uses the requirements as the basis for software plans, work products and activities. (Pre-requisite for other KPAs - SPP and SPT)
   
3. Changes to requirements are reviewed and incorporated into the software project.
   

MEASUREMENT AND ANALYSIS:

1. Measurements are made and used to determine the status of the RM activities.
   

VERIFYING IMPLEMENTATION:

1. RM Activities are reviewed with senior management on periodic basis.
   
2. RM activities are reviewed with the PM on both periodic and event-driven bases.
   

PURPOSE: To establish reasonable plans to perform execute and managing the project.

WHAT IT INVOLVES:

1. Developing estimates for the work to be performed;
   
2. Establishing the necessary commitments;
   
3. Defining the plan to perform work.
   

GOALS:

1. Software estimates are documented for use in planning and tracking the project.
   
2. Software project activities and commitments are planned and documented.
   
3. Affected groups and individuals agree to their commitments related to the project.
   

COMMITMENT TO PERFORM:

1. A project manager (PM) is designated to negotiate the commitments and make development plan.
   
2. The project follows a written organizational policy for SPP.
   

ABILITY TO PERFORM:

1. A documented and approved work statement exists for the software project.
   
2. Responsibilities for making development plan are assigned.
   
3. Adequate resources and funding are provided for SPP.
   
4. Those involved in SPP are trained in s/w estimating & planning procedures.
   

ACTIVITIES PERFORMED:

1. The s/w project team participates on the project proposal team.
   
2. Project team participates with other affected groups in the overall project planning.
   
3. Project commitments to external parties are reviewed with the senior management.
   
4. SDLC with pre-defined stages of manageable size is defined.
   
5. A development plan is made according to a documented procedure.
   
6. The project plan is documented.
   
7. Software work products (SWPs) for controlling the project are identified.
   
8. Size estimates of the SWPs are derived according to a documented procedure.
   
9. Effort, cost estimates and schedule, are derived according to a documented procedure.
   
10. Critical computer resources are estimated according to a documented procedure.
    
11. Project risks are identified, evaluated and documented.
    
12. Plans for project facilities and support tools are prepared.
    
13. Software planning data are recorded.
    

MEASUREMENT AND ANALYSIS

1. Status of software planning activities
   

VERIFYING IMPLEMENTATION

1. Activities are reviewed with senior management on periodic basis.
   
2. Activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SQAG reviews/audits the planning activities and work products and reports the results.
   

PURPOSE: To provide visibility into the project to enable management of take actions when performance deviates significantly from plans.

WHAT IT INVOLVES:

1. Tracking and reviewing the achievements and results against estimates and plans;
   
2. Adjusting the plans based on actual achievements and results.
   

GOALS:

1. Results and performances are tracked against plans.
   
2. Corrective actions are taken and managed to closure.
   
3. Affected groups and individuals agree to changes to project commitments.
   

COMMITMENT TO PERFORM:

1. A PM is designated to be responsible for project's software activities and results.
   
2. The project follows a written organizational policy for managing the project.
   

ABILITY TO PERFORM:

1. A software project plan is documented and approved. (Output of the earlier KPA – SPP)
   
2. PM assigns responsibility for software work products (SWP) and activities.
   
3. Adequate resources and funding are provided for tracking the project.
   
4. S/w managers are trained in managing technical and personnel aspects of the project.
   
5. Team Leaders receive orientation in the technical aspects of the project.
   

ACTIVITIES PERFORMED:

1. The project activities are tracked and status is communicated using the development plan.
   
2. Project development plan is revised according to a documented procedure.
   
3. Project commitments to external parties are reviewed with the senior management.
   
4. Changes to project commitments are communicated to project and affected groups.
   
5. Size of SWPs and their changes are tracked and corrective actions are taken.
   
6. Costs and efforts are tracked and corrective actions are taken.
   
7. Critical computer resources are tracked and corrective actions are taken.
   
8. Schedules are tracked and corrective actions are taken.
   
9. Technical activities are tracked and corrective actions are taken.
   
10. Project risks are tracked.
    
11. Measurement data and re-planning data are recorded.
    
12. Periodic internal reviews are held to track progress, plans, performance and issues.
    
13. Achievements and results are reviewed at milestones according to a documented procedure.
    

MEASUREMENT AND ANALYSIS

1. Status of software tracking and oversight activities
   

VERIFYING IMPLEMENTATION

1. Activities are reviewed with senior management on periodic basis.
   
2. Activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SQAG reviews/audits the project tracking activities and SWPs and reports the results.
   

PURPOSE: To provide management with visibility into the process that is being used and products being built.

WHAT IT INVOLVES:

1. Reviewing and auditing the software products and activities to verify that they comply with the applicable procedures and standards;
   
2. Providing project and other managers with the review/audit results.
   

GOALS:

1. SQA activities are planed.
   
2. Adherence of products and activities to the applicable standards, procedures and requirements is verified objectively.
   
3. Affected groups are informed of SQA results
   
4. Noncompliance issues that cannot be resolved within the project, are escalated to SM.
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy for implementing the SQA activities.
   

ABILITY TO PERFORM:

1. An SQAG exists (for coordinating and implementing SQA activities).
   
2. Adequate resources and funding are provided for SQA activities.
   
3. SQAG members are trained to perform SQA activities.
   
4. Project members receive orientation on SQAG's role, responsibility, authority and value.
   

ACTIVITIES PERFORMED:

1. SQAP is prepared for the project.
   
2. SQAG activities are performed in accordance with SQAP.
   
3. SQAG participates in the preparation & review of the development plan, standards and procedures.
   
4. SQAG reviews the project activities to verify compliance.
   
5. SQAG audits designated SWPs to verify compliance.
   
6. SQAG periodically reports the results to the project team.
   
7. Deviations in the products and activities are documented and handled according to a documented procedure.
   
8. If appropriate, SQAG periodically reviews its activities and findings with customer's SQAG.
   

MEASUREMENT AND ANALYSIS

1. Cost and schedule of SQA activities.
   

VERIFYING IMPLEMENTATION

1. SQA activities are reviewed with senior management on periodic basis.
   
2. SQA activities are reviewed with project manager both on periodic and event-driven bases.
   

PURPOSE: To establish and maintain integrity of the products throughout the project's SDLC.

WHAT IT INVOLVES:

1. Identifying the software configuration (selected SWPs and their description) at given points of time;
   
2. Systematically controlling changes to the configuration;
   
3. Maintaining the integrity and traceability throughout the SDLC.
   

GOALS:

1. SCM activities are planed.
   
2. Selected SWPs are identified, controlled and available.
   
3. Changes to SWPs are controlled.
   
4. Affected groups and individuals are informed the status and contents of baselines.
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy for implementing the SCM activities.
   

ABILITY TO PERFORM:

1. An SCCB with authority for managing the project's baselines exists or is established.
   
2. An SCMG with responsibility for coordinating and implementing the project SCM, exists.
   
3. Adequate resources and funding are provided for SCM activities.
   
4. SCMG members are trained in the (objectives, procedures and methods for) SCM activities.
   
5. Project members are trained to perform their SCM activities.
   

ACTIVITIES PERFORMED:

1. SCMP is prepared for each project according to a documented procedure.
   
2. SCM activities are performed using a documented and approved SCMP.
   
3. A CM Library system is established as a repository for the s/w baselines.
   
4. SWPs to be placed under CM are identified.
   
5. Change requests and problem reports for all configuration items are initiated, reviewed, approved (or rejected) and tracked according to a documented procedure.
   
6. Changes to baselines are controlled according to a documented procedure.
   
7. Baseline library products are created and their release is controlled according to a documented procedure. (Difference between 7 and 8?)
   
8. CI status is recorded according to a documented procedure.
   
9. SCM activities and baseline contents are communicated to the affected groups.
   
10. Baseline audits are conducted according documented procedure.
    

MEASUREMENT AND ANALYSIS

1. Status of SCM activities
   

VERIFYING IMPLEMENTATION

1. SCM activities are reviewed with senior management on periodic basis.
   
2. SCM activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SCMG periodically audits the software baselines to verify that they conform to the documentation that defines them.
   
4. SQAG reviews/audits the activities and work products of SCM and reports the results.
   

LEVEL-3 KEY PROCESS AREAS AND KEY PRACTICES

ORGANIZATION PROCESS FOCUS

PURPOSE: To establish the organizational responsibility for software process activities that improve the organization's overall software process capability.

WHAT IT INVOLVES:

1. Developing and maintaining an understanding of software processes (of the organization and the projects);
   
2. Coordinating the activities to assess, develop, maintain and improve these processes.
   

GOALS:

1. S/W process development and improvement activities are coordinated across organization.
   
2. Strengths and weaknesses of the s/w processes are identified relative to a process standard.
   
3. Organization-level process development and improvement activities are planned.
   

COMMITMENT TO PERFORM:

1. The organization follows a written organizational policy for coordinating software process development and improvement (SPDI) activities across the organization.
   
2. Senior management sponsors and oversees the SPDI activities.
   

ABILITY TO PERFORM:

1. A group (SEPG) responsible for organization's software process activities exists.
   
2. Adequate resources and funding are provided for organization's software process activities.
   
3. SEPG members receive required training to perform these activities.
   
4. Project and support group members receive orientation of organization's s/w process activities and their role in these activities.
   

ACTIVITIES PERFORMED:

1. S/W process is assessed periodically and action plans are develop to address the assessment findings. (Assessments are typically conducted every 1.5 to 3 years)
   
2. Organization development and maintains a plan for SDPI activities.
   
3. At the organization level, the activities for developing and improving their s/w processes are coordinated.
   
4. At the organization level, the use of the organization's software process database is coordinated.
   
5. New processes, methods and tools in limited use in the organization, are monitored, evaluated and transferred to other parts.
   
6. Training for the organization's and project's s/w processes is coordinated across the organization.
   
7. Groups involved in implementing the s/w processes are informed of the SPDI activities.
   

MEASUREMENT AND ANALYSIS

1. Status of organization's process development and improvement activities
   

VERIFYING IMPLEMENTATION

1. SPDI activities are reviewed with senior management on periodic basis.
   

PURPOSE: To develop and maintain a usable set of s/w process assets that improve process performance and provide a basis for cumulative, long term benefits to the organization.

WHAT IT INVOLVES:

1. Developing and maintaining the organization's standard software process, along with process assets (e.g., s/w lifecycles, process tailoring guidelines, OSSP database etc.)
   

GOALS:

1. OSSP is developed and maintained.
   
2. Information related to the use of OSSP by the projects, is collected, reviewed and made available.
   

COMMITMENT TO PERFORM:

1. The organization follows a written organizational policy for developing and maintaining OSSP and related process assets.
   

ABILITY TO PERFORM:

1. Adequate resources and funding are provided for developing and maintaining the organization's standard software process (OSSP) and related process assets.
   
2. Those who develop and maintain OSSP receive required training to perform these activities.
   

ACTIVITIES PERFORMED:

1. OSSP is developed and maintained according to a documented procedure.
   
2. OSSP is documented according to established standards.
   
3. Description of approved life cycles are documented and maintained.
   
4. Project's tailoring guidelines of OSSP are developed and maintained.
   
5. Organization's software process database is established and maintained.
   
6. Library of software process-related documents is established and maintained.
   

MEASUREMENT AND ANALYSIS

1. Status of organization's process definition activities
   

VERIFYING IMPLEMENTATION

1. SQAG reviews/audits the activities and work products for developing and maintaining OSSP and related process assets and reports the results.
   

TRAINING PROGRAM

PURPOSE: To develop the skills and knowledge of individuals so they can perform their roles effectively.

WHAT IT INVOLVES:

1. Identifying the training needed by the organization, projects and individuals
   
2. Developing or procuring training to address the identified needs.
   

GOALS:

1. Training activities are planned.
   
2. Training needs for software management and technical roles is provided.
   
3. Individuals in the project and related groups receive necessary training to perform their roles.
   

COMMITMENTS TO PERFORM:

1. The organization follows a written organizational policy for meeting the training needs.
   

ABILITY TO PERFORM:

1. A training group responsible for fulfilling organization's training needs exists
   
2. Adequate resources and funding are provided for implementing the training program.
   
3. Training group members have necessary skills and knowledge to perform training.
   
4. Software managers receive orientation on the training program.
   

ACTIVITIES PERFORMED:

1. Project develops and maintains a training plan that specifies the training needs.
   
2. Organization training plan is developed and maintained according to documented procedure.
   
3. Organization training is performed according to documented procedure.
   
4. Organization level training courses are developed and maintained as per organization standards.
   
5. Waiver procedure is established and used.
   
6. Training records are maintained.
   

MEASUREMENT AND ANALYSIS:

1. Status of organization's process definition activities
   
2. Quality of the training program.
   

VERIFYING IMPLEMENTATION:

1. Training program activities are reviewed with senior management on periodic basis.
   
2. Training program is independently evaluated on a periodic basis for consistency with and relevance to the organization's needs.
   
3. Training program activities and work products are reviewed and/or audited and results are reported.
   

SOFTWARE MANAGEMENT

PURPOSE: To integrate the software engg and management activities into a coherent, defined software process that is tailored from the OSSP.

WHAT IT INVOLVES:

1. Developing the project defined software process (PDSP)
   
2. Managing the project using this PDSP.
   

GOALS:

1. Project defined software process (PDSP) is a tailored version of OSSP.
   
2. Project is planned and managed according to the PDSP.
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy for planning and managing the project using the OSSP.
   

ABILITY TO PERFORM:

1. Adequate resources and funding are provided for implementing the training program.
   
2. Individuals responsible for PDSP receive required training in tailoring the OSSP and using the process assets.
   
3. Software managers receive required training in managing the tech, admin and personnel aspects of projects based on PDSP.
   

ACTIVITIES PERFORMED:

1. PDSP is developed by tailoring the OSSP according to a documented procedure.
   
2. Each PDSP is revised according to a documented procedure.
   
3. Software development plan that describes the use of PDSP is developed and maintained.
   
4. The project is managed to PDSP.
   
5. The organization's software process database is used for software planning and estimating.
   
6. Size of work products and their changes, is managed according to documented procedure.
   
7. Project's software effort and costs are managed according to documented procedure.
   
8. Critical computer resources are managed according to documented procedure.
   
9. Critical dependencies and critical paths of the schedule are managed according to documented procedure.
   
10. Project's software risks are identified, assessed, documented and managed according to documented procedure.
    
11. Periodic project reviews are performed to determine actions to bring project performance in line with the needs of business, customer and end-user.
    

MEASUREMENT AND ANALYSIS:

1. Effectiveness of the ISM activities.
   

VERIFYING IMPLEMENTATION:

1. Activities are reviewed with senior management on periodic basis.
   
2. Activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SQAG reviews/audits the activities and work products and reports the results.
   

SOFTWARE PRODUCT ENGINEERING

PURPOSE: To consistently perform a well-defined engineering process that integrates all s/w engineering activities to produce correct, consistent software products effectively and efficiently.

WHAT IT INVOLVES:

1. Performing the engineering tasks to build and maintain the software using the PDSP.
   

GOALS:

1. Software engg. tasks are defined, integrated and consistently performed to produce the s/w.
   
2. Software work products are kept consistent with each other.
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy for performing the s/w engg activities.
   

ABILITY TO PERFORM:

1. Adequate resources and funding are provided for performing the s/w engg tasks.
   
2. Project technical staff receives required training to perform their technical assignments.
   
3. Project technical staff receives orientation in related software engineering disciplines.
   
4. PM and software managers receive orientation in technical aspects of the project.
   

ACTIVITIES PERFORMED:

1. Appropriate software engg. methods and tools are integrated into the PDSP (project's defined software process).
   
2. Software requirements are developed, maintained, documented and verified by systematically analyzing the customer requirements according to the PDSP.
   
3. Software design is developed, maintained, documented and verified according to the PDSP, to accommodate the software requirements to form the framework for coding.
   
4. Software code is developed, maintained, documented and verified according to the PDSP to implement the software requirements and design.
   
5. Software testing is performed according to the PDSP.
   
6. Integration testing is planned and performed according to the PDSP.
   
7. System and acceptance testing of the software are planned and performed to demonstrate that the software satisfied the requirements.
   
8. The documentation that will be used to operate and maintain the software is developed and maintained according to the PDSP.
   
9. Defect data from peer reviews and testing are collected and analyzed according to PDSP.
   
10. Consistency is maintained across software work products (s/w plans, process descriptions, user requirements, software requirements, design, code, test plans and test procedures).
    

MEASUREMENT AND ANALYSIS:

1. Functionality and quality of software products
   
2. Status of software product engineering activities
   

VERIFYING IMPLEMENTATION:

1. Activities are reviewed with senior management on periodic basis.
   
2. Activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SQAG reviews/audits the activities and work products and reports the results.
   

INTERGROUP COORDINATION

PURPOSE: To establish a means for the project to participate actively with the other technical groups so the project is better able to satisfy the customer's needs effectively and efficiently.

WHAT IT INVOLVES:

1. Project's participation with other technical groups to address system-level requirements, objectives and issues
   

GOALS:

1. The customer's requirements are agreed to by all the affected groups.
   
2. Commitments between the technical groups are agreed by the affected groups.
   
3. The technical groups identify, track and resolve intergroup issues.
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy for establishing interdisciplinary technical teams.
   

ABILITY TO PERFORM:

1. Adequate resources and funding are provided for performing the s/w engg tasks.
   
2. The support tools used by the different technical groups are compatible to enable effective communication and coordination.
   
3. All managers receive required training in teamwork.
   
4. All task leaders in each technical group receive orientation in the processes, methods and standards used by the other technical groups.
   
5. Technical staff receives orientation in teamwork.
   

ACTIVITIES PERFORMED:

1. The project and other technical groups participate with the customer and users to establish the requirements.
   
2. Project representatives work with the other technical groups to monitor and coordinate technical activities and resolve technical issues.
   
3. A documented plan is used to communicate intergroup commitments and to coordinate and track the work performed.
   
4. Critical dependencies between the technical groups are identified and tracked according to a documented procedure.
   
5. Items provided as inputs by other technical groups are reviewed by representatives of the receiving groups to endure that the items meet their needs.
   
6. Intergroup issues not resolvable by the individual project representatives are handled according to a documented procedure.
   
7. Project's technical representatives conduct periodic technical reviews and interchanges.
   

MEASUREMENT AND ANALYSIS:

1. Status of the Intergroup coordination activities
   

VERIFYING IMPLEMENTATION:

1. Activities are reviewed with senior management on periodic basis.
   
2. Activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SQAG reviews/audits the activities and work products and reports the results.
   

PEER REVIEWS

PURPOSE: To remove defects from the work products early and efficiently and to develop a better understanding of the work products and of defects that might be prevented..

WHAT IT INVOLVES:

1. A methodical examination of the work products by the producer's peers to identify defects and areas where changes are needed.
   

GOALS:

1. Peer reviews are planned.
   
2. Defects from the work products are identified and removed.
   

COMMITMENT TO PERFORM:

1. The project follows a written organizational policy for performing peer reviews.
   

ABILITY TO PERFORM:

1. Adequate resources and funding are provided for performing peer reviews on each work product to be reviewed.
   
2. PR leaders receive required training on how to lead peer reviews.
   
3. Reviewers in peer reviews, receive required training in the objectives, principles and methods of peer reviews.
   

ACTIVITIES PERFORMED:

1. PRs are planned and the plans are documented.
   
2. PRs are performed according to a documented procedure.
   
3. Data on the conduct and results of PRs are recorded.
   

MEASUREMENT AND ANALYSIS:

1. Status of peer review activities
   

VERIFYING IMPLEMENTATION:

1. Activities are reviewed with senior management on periodic basis.
   
2. Activities are reviewed with project manager both on periodic and event-driven bases.
   
3. SQAG reviews/audits the activities and work products and reports the results.