How do we know when our output is successful? Well, when the customer takes acquisition can be the first tangible evidence for many organizations the output is “good”. So we know what we mean by good, I provide a brief list: capabilities of the output can be deployed suitable quality (Key Product Characteristics are met) […]
Our organization’s structure can confound what constitutes and output. Consider the company that is structured as a “functional” organization, the output from one group will typically go to another group in the system. This organization structure is sometimes referred to as “silo” since each part of the company, group or department is segregated by expertise. This has […]
Each process produces some sort of, at least intermediate output. The ultimate output will be the resultant of the series of inputs, processes and outputs, and will be directed toward the ultimate end customer. Therefore the ultimate output capability is the collection of all of the inputs and processes of the systems of the organization. […]
The process refers to the actions or activities we will take to achieve our objectives. This link to specific objectives is essentially the rationale for the process. In our previous example, the Systems Engineering group may have requirements elicitation activities as well as concept generation and critique actions culminating in system requirements specifications. These various […]
When we write about input, we are discussing the nature of the exchange to the depending group. The Systems Engineers, in our previous example, need some input from the Marketing staff to be able to design something to achieve the marketing personnel objective and subsequently meet the customer’s need. What is that input? For example, […]
We like the title Random Acts of Product Development. It often appears that product development is a collection of ill-conceived and poorly executed tasks. Those planning refuse to recognize dependencies between groups and tasks and are unable or unwilling to acknowledge they are really working within a system – blinded by the solely important launch […]
We see well-meaning people adopt an attitude “if it needs done, then I will do it” even if their job or position in the company does not define them as the person to solve the problem. I call this absorption and it is part of the much ballyhooed “can-do attitude” upon which many companies thrive. […]
We strongly recommend automated testing whenever this approach is feasible. The test team can use a language designed for this kind of testing; for example, the National Instruments product Labview. The software should be able to read in the documented test cases, execute the test cases against the product, and finish by producing a […]
Extreme testing occurs when we deliberately “torture” both the hardware and software to see what happens under undesirable conditions. Some examples of extreme testing include: Random voltages within the allowable voltage boundaries Voltage slews Deliberately introduced random noise on the data bus Extremely high bus loading (over 80% and sometimes over 90%) to see […]
Stochastic testing occurs when we allow a reasonably well-seasoned test engineer to go with their “gut” and feel their way about the product’s performance. During the development of numerous embedded automotive products, we have seen stochastic testing elicit roughly the same amount of test failures as combinatorial testing. We are not recommending that stochastic testing […]