Sie sind auf Seite 1von 2

Using Six Sigma Methodology for Software Development Project Management

Adapted from response by Michael on Friday, December 17, 2004 Six Sigma is a disciplined methodology for continuous improvement in activities (processes). The function of Six Sigma is to produce an environment in which the process does not support errors. When performance and errors are mapped, on X and Y coordinates, a bell shaped curve is the result. In that bell shaped curve, there are levels of significance. Six Sigma references the sixth point of significance in that curve. For example, two sigma references the point were 308,537 errors occur in 1,000,000 operations (activities). Three sigma - 66,807 errors, four sigma - 6210 errors, five sigma - 233 errors per million operations (activities). The reference 'six sigma' represents that portion of the bell shaped performance curve in which the error rate is extremely low. The point that references the six sigma states that 3.4 errors will occur in every 1,000,000 operations (activities). Performance of any activity is preceded by a philosophy that predicts the outcome of that performance. In Six Sigma all activities are dictated by the philosophy that continuous improvement is always overriding factor when 'guesses' have to be made. Six Sigma says before you take action, know which paths are available, if there is a new path, do not take the journey until that path is understood. While I was in software development, we undertook an initiative to reduce errors. It was 1980 before the Philosophy of Six Sigma existed. Our philosophy stated that our process was not to create errors and we instituted a very rigorous activity to remove errors from the activities of software development. Here is what we did. A business analyst produced a written document that defined in general what a 'screen' was to accomplish. That 'design' was detailed enough to explain what was to be done, but not how it was to be done. Real data could be 'flowed' through the design to test the design. The design was reviewed by other business analysts and a programming manager. Ambiguities were pointed out and the business analyst would redesign the document. Sometimes 5 or 6 iterations occurred before the design was released to a programmer. The programmer would review the design and in a structured meeting get answers to questions to remove ambiguities in the programmer's mind. The programmer then produced a document to address the design. The document was in a pseudo code we called Chapin Charting. Chapin Charting was a language of logic diagrams that was structured to an extreme and contained fewer than 100 words and symbols. Once the programmer had created the Chapin Chart, the design was submitted to a review group comprised of a business analyst, a programming manager, and three other programmers. The review meeting suggested enhancements to the document and data was flowed through the design to insure integrity. The meeting was re-iterative until all parties were satisfied that the end result would serve as a solution to the task. Only now was the programmer allowed to write any code.

Once the code was written, it was reviewed by three programmers and a programming manager to insure that the proper tools (Subroutines) were used and that the code followed the logic diagram. In our 'process', coding was only 10% of the activities. Errors were few. Our pilot customers loved the product. There was only one problem. The market place was changing and the PC was becoming the rage. Our product was written for mini-computers. We could not compete in the marketplace. It seems that the management team that implemented the philosophy of reducing errors had not followed their own advice when they designed the front part of the system. This activity was extremely labor intensive but it worked. When we wrote a BOM explosion routine, it was fewer than 50 lines of code. Our MRP explosion routine was fewer than 200 lines of code. Our testing was so exact that in the design of our MRP routine, we predicted an error would occur if there was no order policy assigned to an item. Since we knew that an Item could not be created without an order policy the error we assigned to this occurrence was 'THIS ORDER POLICY ERROR WILL NEVER OCCUR'. Guess what happened when we first ran MRP? You are correct; we got a part that produced the error 'THIS ORDER POLICY ERROR WILL NEVER OCCUR'. This is what I believe could be an example of implementing Six Sigma in a programming environment.