Google
 
Showing posts with label Process Improvement. Show all posts
Showing posts with label Process Improvement. Show all posts

Friday, March 28, 2008

Rework effort in SELC

Rework is an ongoing problem in software development. As per SEI (Software Engineering Institute) report it has been indicated that 60-80% of the cost of software development is rework effort. This effort is used to correct defects associated with base-lined work-products. Unfortunately, the reason is a gap between the state of the art and the state of the practice of software engineering.

In SELC (Software Engineering Life Cycle) all out put is treated as work-product. E.g. Project Plan Document, Requirement Specification Document, Source Code, Test Specification, Test Report, Release Note etc. And when a work-product is approved or validated by the relevant stakeholders for using next level users than it called base-lining.

Common causes of re-works in SELC:

  1. Requirement Analysis Gap (main root case of rework)
  2. Wrong Software design (e.g. performance issue not considered in the design)
  3. Poor Code development (e.g. features not developed as is software design)
  4. Inadequate Test Case development (e.g. insufficient test cases for each requirement)

Despite successes in reducing rework, it is generally accepted that rework cannot be eliminated entirely. However, rework effort can be reduced by taking process improvement. For example:

  • Introduce or improve the formal review process in requirement, design and coding phases. [If formal review is implemented then defect will be identified from the earlier stage of SELC, it will reduce rework significantly.]
  • Integrate test cases with requirements [if each test case is mapped with requirements then it will be easier to measure that sufficient test cases is developed/not to test that requirement]
  • Conduct Inspection [periodical inspection on work-products and processes implementation helps to identify defects as well as increase the consciousness of project team members to develop quality work-products and follow the processes]

Therefore, to reduce the rework effort it is required the use of disciplined engineering practices by skilled software engineers.

Wednesday, February 20, 2008

CMMI Instead of ISO 9001:2000

When a ISO 9001:2000 certified company goes for CMMI then definitely some questions raise into the practitioners mind, why CMMI instead of ISO 9001? Is CMMI better then ISO 9001?


There are numbers of documents available in the internet to give you clarification theoretically for those questions, but I want to share my own experience to implementing CMMI, where I also manage ISO 9001:2000 compliance processes.
  • Primary focus of ISO 9001:2000 is customer satisfaction, whereas CMMI focuses on achieving organization goals. CMMI specifies Process Improvement (PI) should be done to achieve all of the organization goals.
  • ISO standard description is very brief, where as CMMI model content is elaborate (better assists for process improvements). ISO requirements only ‘what’ should be done, but CMMI also specifies ‘how’ can be done.
  • CMMI model has detailed information for institutionalization of processes compared to ISO contents on institutionalization. ISO is weak in institutionalization compared to CMMI (CMMI models' GGs & GPs assists for institutionalization).
  • CMMI is strong in Training function, which is a very important function for any organization. Without continuous improvement of HR skill PI is very difficult. You know integration of People, Process and Technology can make an organization successful. ISO 9001 is not strong in this area.
  • CMMI allows tailoring of processes. It is realistic, because for different type and size of the projects or functions same process might not be work.
  • ISO requires only direct evidence from the practitioners as per standards which leads to disconnected process development and implementation. But CMMI requires both direct and indirect evidence from practitioners, which leads to develop integrated processes.
  • ISO doesn’t deal with the performance of the processes, but CMMI do.
  • ISO requires a MR (Management Representative), CMMI requires EPG (Engineering Process Group) which is more effective for PI.

But, for any ISO certified organization, it becomes easy to implement CMMI based process improvements as ISO brings good discipline on process approach.

You also might want to know exact mapping between ISO 9001 and CMMI. I don’t find any mapping document between CMMI V1.2 with ISO 9001. But on the SEI website, there is a document that shows the mapping between CMMI (V1.1 - the prior version) and ISO 9001. Here is the link:
http://www.sei.cmu.edu/cmmi/adoption/pdf/iso-mapping.pdf
Another useful document on ISO 9001:2000-CMMI Synergy for Process Improvement is
http://www.sei.cmu.edu/cmmi/presentations/sepg03.presentations/cmmi-iso.pdf