CMMI and ISO

ISO is a standard. Companies have to comply with standards. ISO has eight principle clauses.

CMMI is a process meta model. The process model is a guideline for organizations to improve their processes. CMMI is a collection of best practices in the s/w industry. CMMI tells you what to do, the HOW is left to the choice of the ogranization implementing it.

CMMI has 25 process areas (including IPPD, SS) as per v1.1

Common metrics for maintenance projects...

1. Client satisfaction index
2. Effort metrics
-Overall effort variance
-COQ
-COPQ
-Rework effort index
3. Schedule metrics
-Overall schedule variance
-On-time delivery index
4. Quality metrics
-Overall defect density
-Residual defect density
5. Performance metrics
-PCI of last audit
6. Support metrics
-FTR

Bi-directional Traceability

Traceabilities are of two kinds:

1. Vertical Traceability
2. Horizontal Traceability

Bidirectional traceability is tracing requirements both forward and backwards (in Horizontal) AND Top to Bottom, & Bottom to Top (in Vertical) through all the phases of software development lifecycle.

Vertical traceability is tracing customer requirements from requirements phase thru System Test / UAT phase and from System Test / UAT phase back to customer requirements phase. These traceabilities can be established if the requirements are well managed. Vertical traceability helps determine that all the source requirements have been completely addressed and that all lower level requirements and selected work products can be traced to a valid source.

Forward traceability ensures all requirements have been captured, while backward traceability ensures no additional functionality (gold plating) has not been introduced into the system.

If a requirement is added or withdrawn, the development team must be aware of the design elements / development modules / test cases, etc. where the impact would be felt and changes need to be carried out.

How does bidirectional traceability help?

1. To measure the impact of requirement changes. One requirement may spawn multiple design elements. In this case, each such design element should be traceable backwards to the same requirement.
2. To know that all requirements have been implemented in the system. (Forward traceability ensures this).
3. To ensure that no unwanted functionality has been incorporated into the system. (Backward traceability ensures this).

Vertical Traceability: Within a work product (BRS, SRS, HDL, LDL, Test Plan, etc.), the inter-relationships between various requirements is called vertical traceability. Each requirement is related to other requirement/s by virtue of functionality. Vertical Traceability ensures that all requirements have been captured, gaps in functionality have been identified, and that there is no duplication of requirements.

The Mythical Man-month

Frederick Brooks in his 1975 book The Mythical Man-month contends that adding more people to a behind-schedule project doesn't actually speed it up. On the contrary, ramping up resources adds up to the communication complexity (an overhead in fact) within the development group. This is because inducting new people involves a certain amount of time and resources to orient before they can be deployed for production. Weaning away time and resources from the project towards trainings / orientation results in further delay.

Function Points

Function points are a measure of the size of computer applications and the projects that build them. The size is measured from a functional, or user, point of view. It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application.

In the late seventies, IBM felt the need to develop a language independent approach to estimating software development effort. It tasked one of its employees, Allan Albrecht, with developing this approach. The result was the function point technique.

In the early eighties, the function point technique was refined and a counting manual was produced by IBM's GUIDE organization. The International Function Point Users Group (IFPUG) was founded in the late eighties. This organization produced its own Counting Practices Manual. In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual. While the GUIDE publication and each release of the IFPUG publications contained refinements to the technique originally presented by Albrecht, they always claimed to be consistent with his original thinking. In truth, it is still very close considering the nearly two decades that have elapsed since Albrecht's original publication!

During the eighties and nineties, several people have suggested function point counting techniques intended to substantially extend or completely replace the work done by Albrecht. Some of these will be briefly discussed in this FAQ. However, unless otherwise specified, information in this FAQ is intended to be consistent with IFPUG Release 4.0.
The fact that Albrecht originally used it to predict effort is simply a consequence of the fact that size is usually the primary driver of development effort. The function points measured size.

It is important to stress what function points do NOT measure. Function points are not a perfect measure of effort to develop an application or of its business value, although the size in function points is typically an important factor in measuring each. This is often illustrated with an analogy to the building trades. A three thousand square foot house is usually less expensive to build one that is six thousand square feet. However, many attributes like marble bathrooms and tile floors might actually make the smaller house more expensive. Other factors, like location and number of bedrooms, might also make the smaller house more valuable as a residence.

Read more about Function Points here:
http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm