Your SlideShare is downloading. ×
Cba   Ipi   Cmm Intro   Session 2   Level 2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Cba Ipi Cmm Intro Session 2 Level 2

844
views

Published on

http://www.upcoming.vn …

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
844
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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