Cba Ipi Cmm Intro Session 2 Level 2

1,030 views

Published on

http://www.upcoming.vn

http://www.tuvinh.com

http://www.tuvinh.com.vn

http://blog.tuvinh.com

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

  • Be the first to like this

No Downloads
Views
Total views
1,030
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cba Ipi Cmm Intro Session 2 Level 2

  1. 1. Introduction to CMM Ver 1.1 Repeatable Level
  2. 2. TYPICAL CHARACTERISTICS OF REPEATABLE LEVEL ORGANISATION <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>SOFTWARE CONFIGURATION MANAGEMENT </li></ul><ul><li>SOFTWARE QUALITY ASSURANCE </li></ul><ul><li>SOFTWARE SUBCONTRACT MANAGEMENT </li></ul><ul><li>SOFTWARE PROJECT TRACKING AND OVERSIGHT </li></ul><ul><li>SOFTWARE PROJECT PLANNING </li></ul><ul><li>REQUIREMENTS MANAGEMENT </li></ul>
  4. 4. REQUIREMENTS MANAGEMENT <ul><li>PURPOSE IS TO ESTABLISH A COMMON UNDERSTANDING BETWEEN THE CUSTOMER AND THE SOFTWARE PROJECT OF THE CUSTOMER’S REQUIREMENTS THAT WILL BE ADDRESSED </li></ul><ul><li>INVOLVES </li></ul><ul><ul><li>Document and control of customer requirements. </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><ul><li>Customer can be system engineering group, marketing group, another internal organisation, or an external organisation. </li></ul></ul>
  5. 5. Requirements Management - Common Features <ul><li>COMMITMENT </li></ul><ul><ul><li>Written Organisational Policy for managing System requirements </li></ul></ul><ul><li>ABILITY </li></ul><ul><ul><li>Allocated requirements are documented </li></ul></ul><ul><li>MEASUREMENTS </li></ul><ul><ul><li>to determine status of activities pertaining to Requirements Management </li></ul></ul>
  6. 6. Requirements Management - Activities <ul><li>SYSTEM REQUIREMENTS ALLOCATED TO SOFTWARE ARE CONTROLLED TO ESTABLISH A BASELINE FOR SOFTWARE ENGINEERING AND MANAGEMENT USE. </li></ul><ul><ul><li>Software Engineering Group Reviews the allocated requirements before they are incorporated into the project. </li></ul></ul><ul><li>SOFTWARE PLANS, PRODUCTS, ACTIVITES ARE KEPT CONSISTENT WITH THE SYSTEM REQUIREMENTS ALLOCATED TO SOFTWARE. </li></ul><ul><ul><li>The Software Engineering Group uses the allocated requirements as the basis for software plans, work products and activities. </li></ul></ul>
  7. 7. Requirements Management - Activities <ul><li>SOFTWARE PLANS, PRODUCTS, ACTIVITES ARE KEPT CONSISTENT WITH THE SYSTEM REQUIREMENTS ALLOCATED TO SOFTWARE. </li></ul><ul><ul><li>Changes to the allocated requirements are reviewed and incorporated into the software project. </li></ul></ul>
  8. 8. Good Practices <ul><li>RSI for profiling of clients </li></ul><ul><li>Training on requirements gathering process </li></ul><ul><li>Usage of Tools like Requisite Pro </li></ul>
  9. 9. 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 is the basis for performing and managing project’s activities </li></ul></ul>
  10. 10. Software Project Planning - 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 organisational 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>
  11. 11. Software Project Planning -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>
  12. 12. Software Project Planning -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 COMMIEMENTS RELEATED 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 organisation are reviewed with Senior Management according to a documented procedure </li></ul></ul>
  13. 13. Good Practices <ul><li>Risk management planned as part of the MS Project itself </li></ul><ul><li>Usage of FMEA for identification of risks especially product related risks </li></ul><ul><li>Combined effort for project planning in case of interdependencies between other groups like embedded systems and communication group etc, DBA group and Project group etc </li></ul>
  14. 14. 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 - replanning or taking actions to improve the performance. </li></ul></ul>
  15. 15. Software Project Tracking and Oversight - 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 organisational 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 aspects of the 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>
  16. 16. Software Project Tracking and Oversight - Activities <ul><li>ACTUAL RESULTS AND PERFORMANCES ARE TRACKED AGAINST THE SOFTWARE PLANS. </li></ul><ul><ul><li>A documented Software Development Plan 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 replanning 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>
  17. 17. Software Project Tracking and Oversight - Activities <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 according to a documented procedure. </li></ul></ul><ul><ul><li>The size of the work products, changes to size, effort and costs, critical computer resources,k 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 replanning data for the software project are recorded. </li></ul></ul>
  18. 18. Software Project Tracking and Oversight - Activities <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 organisation 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>
  19. 19. Software Project Tracking and Oversight - Activities <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 organisation 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>
  20. 20. Good Practices <ul><li>Risk tracking through MS Project itself </li></ul><ul><li>Usage of detailed checklist for project meetings with well planned agenda </li></ul><ul><li>Project level meetings and organization level meetings where members from senior management, SQA and other Support groups participate to tackle and track issues and share good practices and lessons learnt </li></ul>
  21. 21. SOFTWARE SUBCONTRACT 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>
  22. 22. Software Sub contract Management - Common Features <ul><li>COMMITMENT </li></ul><ul><ul><li>Written organisational 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>
  23. 23. Software Sub contract Management - 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>
  24. 24. Software Sub contract Management - Activities <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>
  25. 25. SOFTWARE QUALITY ASSURANCE <ul><li>PURPOSE IS TO PROVIDE MANAGEMENT WITH APPROPRIATE VISIBILITY IN TO 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>
  26. 26. Software Quality Assurance - Common Features <ul><li>COMMITMENT </li></ul><ul><ul><li>Written organisational 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>
  27. 27. Software Quality Assurance - Activities <ul><li>SOFTWARE QUALITY ASSURNACE 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>
  28. 28. Software Quality Assurance - 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>
  29. 29. Good Practices <ul><li>Detailed plan for SQA group </li></ul><ul><li>Structuring of SQA functions and management of the group like a project itself with detailed plan, schedules, configuration management etc </li></ul><ul><li>SLAs for SQA group also </li></ul><ul><li>Rotation mechanism for SQA team members for career planning </li></ul><ul><li>Release approval authority for the SQA </li></ul><ul><li>Effectiveness measurement of SQAs </li></ul>
  30. 30. 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>
  31. 31. Software Configuration Management - Common Features <ul><li>COMMITMENT </li></ul><ul><ul><li>A written organisational 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>
  32. 32. Software Configuration Management - 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. </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>
  33. 33. Software Configuration Management - 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>
  34. 34. Good Practices <ul><li>Extensive usage of tools like VSS </li></ul><ul><li>Extensive and detailed training on the tools </li></ul><ul><li>Usage of features of tools as standard operating process and defining them as part of the process </li></ul><ul><li>Extensive traceability mechanisms which provide help during maintenance phases </li></ul>

×