1

Introduction to CMMVer 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