• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cmm Level2
 

Cmm Level2

on

  • 2,759 views

 

Statistics

Views

Total Views
2,759
Views on SlideShare
2,755
Embed Views
4

Actions

Likes
0
Downloads
104
Comments
0

1 Embed 4

http://www.slideshare.net 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cmm Level2 Cmm Level2 Presentation Transcript

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