Cba Ipi Cmm Intro Session 2 Level 2
description
Transcript of Cba Ipi Cmm Intro Session 2 Level 2
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