Requirements Management & Requirements Development

Requirements Management (RM) is at Level 2, while Requirements Development (RD) is at Level 3 in a staged representation. A quite often asked question is how can one manage requirements without first developing them. Logically, requirements are to be developed (both implicit and explicit customer needs are elicited), and later on managed (thru horizontal and vertical RTM).

However, from a staged representation perspective, an organization at Level 2 need only to manage requirements. Different projects would take up this activitiy in their own way (No Institutionalization). Also, customer needs are not elicited at this level. So, requirements from customers pour in, and the organization merely manages them thru a bi-directional traceability matrix.

For an organization at Level 3, however, requirements ought to be developed first. Both implicit and explicit customer needs are elicited. The requirements are then managed thru a bidirectional traceability matrix. The needs development & management activities at this level are uniform across all projects in the ogranization (Institutionalization).

Interpretation of Level IV & V in CMMI V1.2

Level IV and V process areas remain the same in CMMI V1.2. The way these process areas should be interpreted, however, has changed.

OPP and QPM are at Maturity Level IV, while OID and CAR occupy Maturity Level V. At maturity level III, the focus is on institutionalization. For a company moving from level II towards level III, it would simply mean practicing the same processes across all the projects and bring in uniformity. CAR is done to identify the causes of any repeating problem. This is the CAR at Level III. Measures are taken to contain it.

Through OPF (At level III), the company defines at a macro level what the EPG responsibilities are; through OPD the company defines how its QMS is established and functions. Process performance is monitored using M&A. Note that there is no process stability at this stage. Projects are quantitatively managed when the processes driving it are stable.

At level IV the project’s quality and process performance objectives are defined and only those processes are picked up, which are stable (using past data…in our case it is the Process Capability Baseline sheet.). Sub-processes of the Process are defined & monitored (depending on the organization’s and project’s quality objectives); variation is tracked using statistical techniques. The statistical tools help in identifying variation, and setting up corrective action.
Spikes (significant deviation from the normal) in the process performance are identified; those sub-processes are picked up (for improvement) which are vital, and contribute to process control and improvement. CAR is done to find out root cause of the variation. Measures are taken to ensure that these are not repeated. [This is level IV CAR].

Level V CAR is done to shift the mean. Shifting the mean is a process improvement activity. After shifting the mean, the sub-process performance is monitored for stability and is fine tuned.

Verification & Validation

SCAMPI - A

1. Briefing by lead appraiser to appraisal team, sponsor, delivery head, and appraisal participants.
2. Forming of mini teams based on PA (Project Management, Engineering, and Support Process Areas)
3. Document reviews: Review of Filled-in PIID (Practice Implementation Indicators Description). Gather evidences of Direct Artifacts, and Indirect Artifacts. Report strengths and weaknesses.
4. Conduct individual and group interviews, note down affirmations, and tag the notes.
   - Individual interviews for Delivery Head, followed by Project Managers, OT Head, OID Head
   - Group Interviews for Project Teams
5. Characterize Practice Implementation (Fully Implemented/Largely Implemented/Partially Implemented/Not Implemented/ Not Yet Implemented)
6. Aggregate practice implementation to OU (Organization Unit) Level.
7. Report Preliminary findings to project teams (excluded sr. management) and addressed concerns/objections if any.
8. Rate Maturity Levels.
9. Presentation of Final Findings (to all the members including sr. management)
10. Executive Session
11. Sign Appraisal Disclosure Statement (as per SCAMPI V1.2)
12. Fill SCAMPI – A Feedback form in the SEI Appraisal System: http://sas.sei.cmu.edu/AppSys/ (a web application through which SEI sets up and tracks SCAMPI-A appraisals).

Software Quality Gap Analysis

Software Quality Gap Analysis is based on customer's Process Improvement requirements mapped to Quality Models and the Desired/Targeted State. The customer may want to benchmark against a quality model, or may want to target a specific area like PPQA, and restrict to that area alone. Gap Analysis in such case is performed against the best practices and industry standards in that area.

Gap Analysis can be done against models like CMMI, ISO, COBIT, PCMMI, ITIL, etc. apart from targeting specific process areas.

Sometimes, in-house quality gap analysis is also carried out. SEPG studies the process improvement plans and comes up with changes (or in a few cases redefines the existing process) or deploys a new process. The feasibility is studied and plans are made for a pilot deployment. Measures are defined; projects are selected on which the new process would be experimented. Subsequent to training the selected project teams, and implementation of the process, metrics are collected regularly to study the process performance. If it is along expected / projected lines, then the process is institutionalized.