2. Typical Production Cycle
Prev   Site Home   Next

2. Typical Production Cycle

Typically producing a new software product follows a road map similar to the following flow chart. (Figure 1)

Figure 1. Typical Production Cycle

Typical Production Cycle

2.1. Typical Cycle Explained

An explanation of the typical software production cycle in figure 1 follows. Each item mentioned in the description corresponds to the numeric labels in figure 1

  • Item 1: This is the idea phase. Someone or some group (Marketing?) feels that they have discovered a consumer need that will fit in with the companies expertise and expand them into new markets.

  • Item 2: This is the "brain storming phase" The purpose of this phase is to decided if the company will go ahead with the idea or not. In most production environments feasibility is limited to perceptions of resources (Do we need more people) and market (Is it large enough to justify perceived effort.) Often Engineering managers are called in at this point as "consultants" to the group making the marketing call. If it is decided that the idea has merit but is not a good fit or not doable the idea may be kicked back to the originator for clarification or modification. This is the "rethink loop". If it is determined that the concept is viable it is kicked from there into Engineering for the coding phase. (NOTE: At this point a Marketing spec should be created but often this important step is ignored!)

  • Item 3: This is the coding phase. Usually in most situations the individual(s) who had served "consultants" to the "brain storming phase" impart their impression of what the management group wants to the engineering group. The proposed product is discussed ideas on what is/isn't needed are tossed about and the product is divided up into modules to be developed and coded. (NOTE: At this point an Engineering spec should be created. Unfortunately, for most products, this step as well is skipped.) On occasion QC/QA personnel may be present to learn what the product will be and take notes. However QC/QA considerations are not normally part of the design process. This sets up the first of several high cost loops. The "Doesn't work, Neat new idea loop". This is a combination of New features/incorrectly understood features being added to a product in production, combined with push back from engineering relative to things that cannot be done do to limitations of programming language or the target OS. This process of continuous change often leads to high turnover of engineering personnel due to frustration as well as missed release dates because of constantly having to scrap large sections of code.

  • Item 4: Module integration phase. This is where the various modules created by engineering are integrated into a "product" by the build master There is a small loop here created by build and integration problems encountered by the build master. This is a normal loop that will always occur to some extent but could be nearly eliminated by TQA.

  • Item 5: At this point for the first time the product enters the QC/QA domain. This phase of production creates 3 separate loops (These loops are the bases of a lot of frustration with the QC/QA process and team.) The first is the "What is it loop" Without a proper Marketing Spec or an Engineering Spec, QC/QA personnel need to waste a considerable amount of time trying to find out what it is the product is supposed to be/do. Very often during this discovery process they accidentally kick off a new round of the "Neat idea" loop when they are trying to resolve what the product is and what the expectations are both from the Marketing people as well as the Engineering team. Additional loops set off are the QC/QA version of the "Doesn't work" loop and then an additional loop for normal bugs. Quite often at this point the company has entered a death march phase where all parties involved are on edge and tense. At this point as well bugs begin to be categorized as to fix/don't fix, anything to get the product out of the door. Lines between QC/QA begin to blur as everyone is rushing around trying to get the product out, resulting quite often in the wrong person doing a job simply because they are there.


Prev   Up   Next
1. Introduction  Home  3. Moving from the Typical model to the TQA model