Introduction of Systems Engineering - Following WW II products like cars and airplanes became more complex and the chief engineers could no longer understand everything necessary to achieve a balanced design. This lead to the introduction of specialists in the design of various subsystems or analytical specialties like stress analysis or aerodynamics. For example instead of just mechanical engineers specialists in structural analysis and thermal analysis developed to support the designers. Soon it became impossible for the chief engineer to understand how the engineering data from all the various specialists impacted the overall design. That is when systems engineering emerged and a team of systems engineers replaced the chief designer. It is easy to see that as more and more specialists were needed the engineering design teams grew larger and larger. The large engineering teams of specialists and systems engineers developed some fantastic products such as the Boeing 747, the Space Shuttle and supersonic jet fighter planes.
It became difficult or impossible to co-locate the large teams and the communications needed to keep the systems engineers and the specialists teams current became complex and slow compared to the previous methods. As a result information latency grew along with the complexity of the products and the size of the engineering teams needed to develop the products. This lead to longer and longer development cycle times. The design process became a sequential process with periodic design reviews to evaluate status and design integrity. This evolution took place roughly between 1950 and 1980 and enabled very complex products to be developed. However, the product development cycles were often years long and exhibited undesirable cost and schedule overruns. In addition product quality was sometimes lacking. Examination of this process reveals four fundamental flaws:
1. Too much time and money passes before design errors are found at design reviews
2. Integration of knowledge required for product development is greatly complicated by the separation of specialists into functional groups
3. There are attempts to specify cost, schedule and quality; however, only two are independent.
4. Products often reach manufacturing before manufacturing processes are fully developed.
Introduction of Concurrent Engineering - New methods emerged in the 1980s and 1990s to address the flaws in the sequential process. These new methods emphasized concurrence. Manufacturing and test processes are developed concurrently with the product design. Concurrent systems engineering and design engineering replaces the sequential development of specifications and design. Concurrency is facilitated by early involvement of manufacturing, reliability, procurement, vendors etc. in the design process. The new methods emphasize preventing problems rather than fixing problems by incorporating verification and validation at each step.
The IEEE Std 1220-1998 document “IEEE Standard for Application and Management of the Systems Engineering Process” defines concurrent engineering as “The simultaneous engineering of products and life cycle processes to ensure usability, producibility, and supportability, and to control life cycle and total ownership costs.” Concurrent engineering is sometimes called integrated product development (IPD) or integrated product and process development (IPPD). Here the IEEE definition of concurrent engineering is used for the product design process and IPD for the way the product development personnel are organized to conduct concurrent engineering. There are no universal agreements for these definitions, or other systems engineering nomenclature, so the reader is again cautioned to be careful in interpreting systems engineering terms from different sources.
Accompanying the development of concurrent engineering in the 1980s and 1990s were techniques for improving product quality. Two such techniques imported from Japan are Quality Functional Deployment (QFD) and Taguchi Design of Experiments. The term robust design emerged to describe engineering methodologies using these quality improvement techniques. Three excellent books on these subjects are:
“Total Quality Development-A Step-By-Step Guide to World-Class Concurrent Engineering” by Don Clausing, ASME Press, 1994
“Quality Engineering Using Robust Design” by Madhav Phadke, PTR Prentice Hall, 1989.
“Strategic Design: A Guide to Managing Concurrent Engineering” by Bart Huthwaite, 1994
Further Improvements in Design Methods - Engineering is inherently an iterative process due to the fact that engineers, just like other workers, make mistakes in their work. Engineering work involves making hundreds of decisions in each task and often involves complex analysis. It is almost impossible to do such work without making some mistakes on the first pass. A result of this fact is that design quality and design cost are linked by the number of design iterations performed. This is shown schematically in Figure 1 for a product of some specific complexity being developed with specific methods and tools. If a design of quality q is desired then n iterations are needed and the cost will be c for the given set of design tools and methodologies. Notice that the schedule cannot be specified together with specifying cost and quality. If a certain schedule is required then either the cost or the quality can be specified, but not both. All three are not independent variables.
Also note that this simple diagram shows that if an organization wishes to lower costs, or shorten the design cycle, for a given quality it is necessary to introduce new tools, new methods or both. A major factor in determining the cost, quality and schedule relationships is whether the design team uses practices that prevent design problems rather than find and then fix problems. It is much cheaper and faster to prevent problems than it is to find and fix the problems. Two methodologies introduced to facilitate preventing problems rather than fixing problems are peer reviews and spiral development.
Peer Reviews - Rather than depend on design reviews to find problems peer reviews are held as soon as an individual or small team completes a task. Self-checks catch most mistakes but the best way to find errors after performing self-checks is for the engineer to review the work in detail with highly experienced peer engineers. Experienced peers provide an independent and often different experience background that helps reveal errors.
Catching errors at peer reviews allows the errors to be corrected before the results of the work are incorporated in following tasks. Thus little rework is involved in fixing errors found during peer reviews. In contrast errors found at periodic design reviews involve considerable rework because often the erroneous work has been incorporated in several following tasks that must also be reworked. It is this extensive rework due to errors found at design reviews on complex product developments that contributes to cost and schedule overruns.
Figure 1 Design quality is linked to design cost by the number of design iterations performed by relationships that are dependent on the product complexity and the engineering methods used.
If teams are disciplined in holding peer reviews then the design reviews can become more of a status and decision gate review to communicate to managers and customers the state of the design and to check that all required actions are complete per a design review checklist. Further, if any reviewers wish to go into detail on some design point the documentation engineers have previously used in the peer reviews serve for more detailed discussions. This reduces the time and costs involved in preparing for design reviews.
Spiral Development - Instead of designing the ultimately desired and often highly complex system in one step spiral development sets limited objectives for the first development effort, i.e., the first spiral. Lessons learned from the first spiral are then incorporated in the second spiral. Just like peer reviews spiral development recognizes the inherent iterative nature of product design engineering. The nature of spiral development can be understood from the diagram in Figure 1. A highly complex product would have a diagram with a very steep curve relating design iterations to cost. By developing a lower complexity product in the first spiral the relationship is less steep; that is the cost for a given number of iterations is lower. Similarly, the quality is higher for a given number of iterations for the lower complexity product. Thus the quality of the first spiral can be adequate for lower cost than for a more complex design. The same holds for later spirals. The lessons learned on any spiral are applied to later spirals, resulting in more favorable relationships between cost, schedule and quality than if the work is done in one spiral.
Progressive Freeze - Progressive freeze of design decisions is another technique introduced to manage schedule during the development of complex products. It involves freezing a design detail as soon as it becomes likely that further work won’t change it and before the next major design review. This enables more detailed design work to begin ahead of the design review intended to gate such detailed design. This provides schedule and staffing flexibility. More will be discussed about peer reviews and progressive freeze in later posts.
Concurrent engineering, IPD or IPPD, spiral development, and robust design represent the typical engineering processes for product development in use at the turn of the 21st century and are still widely used. However, the engineering design process has not stopped evolving to match the ever increasing complexity of products. It is the newer methods that are the intended focus of this material. But before introducing these newer methods it is worthwhile to stop and review some fundamentals, which are the subject of the next post.
No comments:
Post a Comment