Cmm Level2

3,096 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,096
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
132
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cmm Level2

  1. 1. CAPABILITY MATURITY MODEL for Software (CMM) Version 1.1 Maturity Level – 2 (Repeatable Level)
  2. 2. Characteristics of Level2 organizations <ul><li>Planning and managing projects is based on experience with similar projects </li></ul><ul><li>Software project management processes are documented and followed </li></ul><ul><li>Organizational policies guide the projects in establishing management processes </li></ul><ul><li>Successful practices developed on earlier projects can be repeated </li></ul><ul><li>Data available are primarily related to size, effort and schedule which are shared across projects through informal practices </li></ul>
  3. 3. Key process areas - level 2 <ul><li>Requirements management (RM) </li></ul><ul><li>Software project planning (SPP) </li></ul><ul><li>Software project tracking and oversight (SPTO) </li></ul><ul><li>Software subcontract management (SSCM) </li></ul><ul><li>Software quality assurance (SQA) </li></ul><ul><li>Software configuration management (SCM) </li></ul>
  4. 4. Requirements Management <ul><li>Purpose </li></ul><ul><ul><li>Establish a common understanding between customer requirements and software project </li></ul></ul><ul><ul><li>This agreement with the customer is the basis for planning the software project. </li></ul></ul><ul><ul><li>Following an effective change control process </li></ul></ul><ul><li>RM involves </li></ul><ul><ul><li>Document and control of customer requirements (technical and non-technical) </li></ul></ul><ul><ul><li>Keeping plans, products, and activities consistent with the requirements </li></ul></ul><ul><ul><li>Reviewing the initial and revised system requirements allocated </li></ul></ul><ul><li>(Note : customer can be system engineering group, marketing group, another internal organization, or an external organization.) </li></ul>
  5. 5. RM Goals & Activities <ul><li>Goal 1 - allocated requirements are controlled to establish baseline </li></ul><ul><ul><li>Software engineering group reviews allocated requirements before they are incorporated into the project </li></ul></ul><ul><li>Goal 2 - software plans, products, activities are kept consistent with the allocated requirements </li></ul><ul><ul><li>Software engineering group uses the allocated requirements as the basis for software plans, work products and activities. </li></ul></ul><ul><ul><li>Changes to the allocated requirements are reviewed and incorporated into the software project </li></ul></ul>
  6. 6. RM Common Features <ul><li>Commitment </li></ul><ul><ul><li>Written organizational policy for managing system requirements </li></ul></ul><ul><li>Ability </li></ul><ul><ul><li>For each project, responsibility is established for analyzing documenting requirements </li></ul></ul><ul><ul><li>Allocated requirements are documented </li></ul></ul><ul><ul><li>Adequate resources and funding are provided for managing the allocated requirements </li></ul></ul><ul><ul><li>Members of the software engineering group and other software related groups are trained to perform their RM activities </li></ul></ul><ul><li>Measurements </li></ul><ul><ul><li>Measurements are made and used to determine the status of the activities for managing the allocated requirements </li></ul></ul>
  7. 7. Software Project Planning <ul><li>Purpose is to establish reasonable plans for performing the software engineering and for managing the software project </li></ul><ul><li>Involves </li></ul><ul><ul><li>Developing estimates(size, cost, effort, schedule & resources) for the work to be performed </li></ul></ul><ul><ul><li>Establishing the necessary commitments </li></ul></ul><ul><ul><li>Defining the plan to perform the work </li></ul></ul><ul><ul><li>Using the plan as the basis for performing and managing project’s activities </li></ul></ul><ul><ul><li>Assessing the risks </li></ul></ul>
  8. 8. SPP Common Features <ul><li>Commitments </li></ul><ul><ul><li>A project software manager is designated to be responsible for project activities </li></ul></ul><ul><ul><li>Written organizational policy for planning a software project </li></ul></ul><ul><li>Ability </li></ul><ul><ul><li>Approved statement of work </li></ul></ul><ul><ul><li>Responsibilities for developing software development plan </li></ul></ul><ul><ul><li>Resources and funding </li></ul></ul><ul><ul><li>Training on software estimation and planning </li></ul></ul><ul><li>Measurements </li></ul><ul><ul><li>To determine status of activities pertaining to software planning </li></ul></ul>
  9. 9. SPP Goals & Activities <ul><li>Software estimates are documented for use in planning and tracking of software projects. </li></ul><ul><ul><li>Estimates for size (or changes to size), effort and cost, critical computer resources, software schedule are derived according to a documented procedure. </li></ul></ul><ul><ul><li>Software planning data are recorded. </li></ul></ul><ul><li>Software project activities and commitments are planned and documented. </li></ul><ul><ul><li>Project planning is initiated in the early stages </li></ul></ul><ul><ul><li>A software life cycle with predefined stages of manageable size is defined </li></ul></ul><ul><ul><li>Software development plan is defined according to a documented procedure and documented </li></ul></ul><ul><ul><li>Software work products are identified </li></ul></ul>
  10. 10. SPP Goals & Activities <ul><li>Software project activities and commitments are planned and documented. </li></ul><ul><ul><li>Risks associated with cost, resource, schedule and technical aspects of the software project are identified, assessed and documented. </li></ul></ul><ul><ul><li>Plan for software engineering facilities and support tools are prepared </li></ul></ul><ul><li>Affected groups and individuals agree to their commitments Related to the software project. </li></ul><ul><ul><li>Software engineering group participates in the project proposal team and with other groups in the overall project planning. </li></ul></ul><ul><ul><li>Project commitments made to individuals and groups external / internal to the organization are reviewed with senior management according to a documented procedure </li></ul></ul>
  11. 11. Software Project Tracking and Oversight <ul><li>Purpose is to provide adequate visibility into actual progress so that management can take effective actions when performance deviates significantly from the plan. </li></ul><ul><li>Involves </li></ul><ul><ul><li>Tracking and reviewing software accomplishments and results against documented estimates, commitments, and plans. </li></ul></ul><ul><ul><li>Adjusting plans based on actual accomplishments and results. </li></ul></ul><ul><ul><li>When plans are not being met, take corrective actions by re-planning or taking actions to improve the performance </li></ul></ul>
  12. 12. SPTO - Common Features <ul><li>Commitment </li></ul><ul><ul><li>Project software manager is designated to be responsible for the projects activities and results. </li></ul></ul><ul><ul><li>Written organizational policy for managing software projects </li></ul></ul><ul><li>Ability </li></ul><ul><ul><li>Software development plan is documented and approved </li></ul></ul><ul><ul><li>Responsibility for every work product is assigned explicitly </li></ul></ul><ul><ul><li>Resources and funding for tracking </li></ul></ul><ul><ul><li>Training on technical and personnel on software project </li></ul></ul><ul><ul><li>Orientation on technical aspects of the project for software managers. </li></ul></ul><ul><li>Measurements </li></ul><ul><ul><li>To determine the status of project tracking activities </li></ul></ul>
  13. 13. SPTO Goals & Activities <ul><li>Actual results and performances are tracked against the software plans. </li></ul><ul><ul><li>A documented SDP is used </li></ul></ul><ul><ul><li>The size of the work product, effort and cost, critical computer resources, software schedule, software engineering and technical activities are tracked and corrective action taken when necessary. </li></ul></ul><ul><ul><li>Risks associated with cost, resource, schedule and technical aspects are tracked </li></ul></ul><ul><ul><li>Actual measurement data and re-planning data are recorded </li></ul></ul><ul><ul><li>Software engineering group conducts periodic internal reviews and track technical progress, plan, performance, and issues against the software development plan. </li></ul></ul><ul><ul><li>Formal reviews to address the accomplishments and results of the project are conducted at selected project milestones according to a doc.Proc </li></ul></ul>
  14. 14. <ul><li>Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans. </li></ul><ul><ul><li>The project’s software development plan is revised </li></ul></ul><ul><ul><li>The size of the work products, changes to size, effort and costs, critical computer resources, software schedule and engineering technical activities are tracked and corrective actions are taken as necessary. </li></ul></ul><ul><ul><li>Actual measurement data and re-planning data for the software project are recorded. </li></ul></ul><ul><li>Changes to software commitments are agreed to by the affected groups and individuals. </li></ul><ul><ul><li>Software project commitments and changes to commitments made to individuals and groups external to the organization are reviewed with senior management </li></ul></ul><ul><ul><li>Approved changes to commitments that affect the software project are communicated to the members of the SEG and other software related groups. </li></ul></ul>SPTO Goals & Activities
  15. 15. <ul><li>Changes to software commitments are agreed to by the affected groups and individuals. </li></ul><ul><ul><li>Software project commitments and changes to commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure. </li></ul></ul><ul><ul><li>Approved changes to commitments that affect the software project are communicated to the members of the software engineering group and other software related groups. </li></ul></ul>SPTO Goals & Activities
  16. 16. Software S/C Management <ul><li>Purpose is to select qualified software subcontractors and manage them effectively </li></ul><ul><li>Involves </li></ul><ul><ul><li>Selecting a software subcontractor. </li></ul></ul><ul><ul><li>Establishing plans, requirements , standards and commitments with the subcontractor. </li></ul></ul><ul><ul><li>Tracking and reviewing the subcontractor’s performance and result. </li></ul></ul><ul><ul><li>Managing a software sub contractor and managing the software component that is sub contracted which includes software and hardware. </li></ul></ul><ul><ul><li>Performing tracking and oversight activities for the subcontracted work. </li></ul></ul><ul><ul><li>Ensuring that the software products delivered by the subcontractor satisfy the acceptance criteria. </li></ul></ul>
  17. 17. SSM - Common Features <ul><li>Commitment </li></ul><ul><ul><li>Written organizational policy for managing the software sub contract. </li></ul></ul><ul><ul><li>A sub contract manager is designated to be responsible for establishing and managing the software sub contract. </li></ul></ul><ul><li>Ability </li></ul><ul><ul><li>Adequate resources and funding </li></ul></ul><ul><ul><li>Training for those who manage sub contract activity on performing sub contract related activities and technical aspects. </li></ul></ul><ul><li>Measurements </li></ul><ul><ul><li>To determine the status of the activities for managing the software sub contract. </li></ul></ul>
  18. 18. SSM - Activities <ul><li>The prime contractor selects qualified software sub contractors </li></ul><ul><ul><li>The work to be sub contracted is defined and planned according to a documented procedure. </li></ul></ul><ul><ul><li>The software subcontractor is selected, based on an evaluation of the subcontract bidders’ ability to perform the work, according to a documented procedure. </li></ul></ul><ul><li>The prime contractor and the software subcontractor agree to their commitments to each other </li></ul><ul><ul><li>The contractual agreement between the prime contractor and the software subcontractor is used as the basis for managing the subcontract. </li></ul></ul><ul><ul><li>A documented subcontractor’s software development plan is reviewed and approved by the prime contractor </li></ul></ul>
  19. 19. <ul><li>Prime contractor and the software subcontractor agree to their commitments to each other. </li></ul><ul><ul><li>Changes to the software subcontractor’s statement of work, subcontract terms and conditions and other commitments are resolved according to a documented procedure </li></ul></ul><ul><li>The prime contractor and the software subcontractor maintain ongoing communications. </li></ul><ul><ul><li>The prime contractor's management conducts periodic status/ coordination reviews with the software subcontractor’s management </li></ul></ul><ul><ul><li>Periodic technical reviews and interchanges are held with the software subcontractor. </li></ul></ul>SSM - Activities
  20. 20. Software Quality Assurance <ul><li>Purpose is to provide management with appropriate visibility into the process being used and the products being built. </li></ul><ul><li>Involves </li></ul><ul><ul><li>Establishing a quality assurance group who has required independence. </li></ul></ul><ul><ul><li>Participation of SQA in establishing the plans, standards and procedures for the project. </li></ul></ul><ul><ul><li>Reviewing and auditing the software products and activities to ensure that they comply with the applicable procedures and standards. </li></ul></ul><ul><ul><li>Providing the software project and other appropriate managers with the results of those reviews and audits. </li></ul></ul><ul><ul><li>Escalating unresolved issues to an appropriate level of management. </li></ul></ul>
  21. 21. SQA - Common Features <ul><li>Commitment </li></ul><ul><ul><li>Written organizational policy for implementing software quality assurance </li></ul></ul><ul><li>Ability </li></ul><ul><ul><li>A group that is responsible for coordinating and implementing SQA for the project exists </li></ul></ul><ul><ul><li>Adequate resources and funding </li></ul></ul><ul><ul><li>Members of SQA group are trained to perform their SQA activities. </li></ul></ul><ul><ul><li>Orientation to members of the projects on SQA activities and roles and responsibilities </li></ul></ul><ul><li>Measurement </li></ul><ul><ul><li>To determine the status, cost and schedule of SQA activities. </li></ul></ul><ul><li>Verification </li></ul><ul><ul><li>Experts independent of the SQA group periodically review the activities of SQA group </li></ul></ul>
  22. 22. SQA Goals & Activities <ul><li>Software quality Assurance activities are planned </li></ul><ul><ul><li>A SQA plan is prepared for the software project according to a documented procedure. </li></ul></ul><ul><ul><li>The SQA group’s activities are performed in accordance with the SQA plan. </li></ul></ul><ul><li>Adherence of software products and activities to be applicable standards, procedures, and requirements is verified objectively. </li></ul><ul><ul><li>The SQA group’s activities are performed in accordance with the SQA plan </li></ul></ul><ul><ul><li>The SQA group participates in the preparation and review of the project’s software development plan, standards and procedures. </li></ul></ul><ul><ul><li>The SQA group reviews the software engineering activities to verify compliance </li></ul></ul><ul><ul><li>The SQA group audits designated software work products to verify compliance. </li></ul></ul>
  23. 23. SQA Goals & Activities <ul><li>Affected groups and individuals are informed of software quality assurance activities and results. </li></ul><ul><ul><li>The SQA group periodically reports the results of its activities to the software engineering group. </li></ul></ul><ul><ul><li>Deviations identified in the software activities and software work products are documented and handled according to a documented procedure. </li></ul></ul><ul><ul><li>The SQA group conducts periodic reviews of its activities and findings with customers SQA personnel, as appropriate. </li></ul></ul>
  24. 24. Software Configuration Management <ul><li>Purpose is to establish and maintain the integrity of the products of the software project throughout the software life cycle. </li></ul><ul><li>Involves </li></ul><ul><ul><li>Establishing a group for managing configuration management activities for a project. </li></ul></ul><ul><ul><li>Identifying configuration items/units. </li></ul></ul><ul><ul><li>Establishing baselines as they are developed. </li></ul></ul><ul><ul><li>Systematically controlling changes through change control and baseline audits. </li></ul></ul><ul><ul><li>Maintaining integrity and traceability of the configuration throughout the software life cycle. </li></ul></ul>
  25. 25. SCM Common Features <ul><li>Commitment </li></ul><ul><ul><li>A written organizational policy for implementing SCM. </li></ul></ul><ul><li>Ability </li></ul><ul><ul><li>A software configuration control board exists. </li></ul></ul><ul><ul><li>SCM group for a project exist </li></ul></ul><ul><ul><li>Adequate resources and funding </li></ul></ul><ul><ul><li>Training to SCM group on objectives, procedures and methods of performing SCM activities. </li></ul></ul><ul><ul><li>Training to software engineering group to perform SCM activities </li></ul></ul><ul><li>Measurements </li></ul><ul><ul><li>To determine the status of the SCM activities </li></ul></ul>
  26. 26. SCM Goals & Activities <ul><li>Software configuration management activities are planned. </li></ul><ul><ul><li>A SCM plan is prepared for each software project according to a documented procedure. (Part of SDP in Tarang) </li></ul></ul><ul><ul><li>A documented and approved SCM plan is used as the basis for performing the SCM activities . </li></ul></ul><ul><li>Selected software work products are identified, controlled, and available. </li></ul><ul><ul><li>A documented and approved SCM plan is used as the basis for performing the SCM activities. </li></ul></ul><ul><ul><li>A configuration management library system is established as a repository for the software baselines. </li></ul></ul><ul><ul><li>The software work products to be placed under configuration management are identified. </li></ul></ul><ul><ul><li>Products from the software baseline library are created and their release is controlled according to a documented procedure </li></ul></ul>
  27. 27. SCM Goals & Activities <ul><li>Changes to identified software work products are controlled. </li></ul><ul><ul><li>Change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved, and tracked according to a documented procedure. </li></ul></ul><ul><ul><li>Changes to baselines are controlled according to a documented procedure. </li></ul></ul><ul><li>Affected groups and individuals are informed of the status and content of software baselines. </li></ul><ul><ul><li>The status of configuration items/units is recorded according to a documented procedure. </li></ul></ul><ul><ul><li>Standard reports documenting the SCM activities and the contents of the software baseline are developed and made available to affected groups and individuals. </li></ul></ul><ul><ul><li>Software baseline audits are conducted according to a documented procedure. </li></ul></ul>
  28. 28. End of Repeatable Level (L2) KPAs

×