Product Development: From Conceptual Design to Maintenance through the Lifecycle
Once you have a good view of the functionality of the system, you can start synthesis, which is developing the system and performing the allocation of the design criteria. You are going to start allocating performance factors requirements, allocating the support requirements, and analyzing what you have thus far. Now you are starting to synthesize something at a system level. Then you do the same at a subsystem level, basically repeating the same methodology at each level. And once you have done that you can start doing some modeling, physical prototypes, and mockups. Eventually you are going to do your detailed design and development where you actually finish your design, but first you have to do a detailed design at the system level, as well as reviews, and do some more modeling, but at the end of that detailed system design part you will have an actual prototype and a lot of modeling and simulation results that you can use to test your concepts at that level. And when you do have something, you have to do the different types of evaluations as well.
Throughout these lifecycle processes, there are mechanisms of feedback. You can always go back. In the figure below, each of these process sequences are being depicted as a waterfall model. The waterfall is sequential with some overlap and then there is a feedback mechanism. That is the main thing there. These steps also tie into program management through milestones. They are important milestones that you can actually make part of your plan. This can be basically a skeleton of a schedule with milestones that you can adapt to your own project functional baseline.
At the end of the conceptual design, the outcome of that process will be a system specification of what we call Type A. Writing such a specification is essentially answering a questionnaire that guides you through a sequence of questions about the system that you are considering as part of the processes of conceptual design. After you have created this specification, you have no choice but to have a good understanding of your system. And after completing this specification you have achieved a milestone which we call allocated baseline that has all the requirements, elements, and processes you may need to specify. The detailed design and development will rely on this work.
If you’re going to do requirement analysis you have to get the requirements before you analyze them, and once those requirements have been analyzed, then you can translate them into specifications. So, requirement analysis and requirements definition are to come up with good “whats”. Specifications is to come up with the “hows” to address the “whats”. Then, design is to implement the “hows”. The implementation here is the actual building of that design, coming up with the same physical implementation prototype at that point, or pilots, or whatever it is that the project requires. Then you have to test. When we say test here, we are talking about not only the test of the functionality and performance of our design, but also for manufacturing. One thing is to test for what a design should be doing, and that it is being done correctly, and another one is to test for whether it was manufactured correctly. These different types of tests may require that you do things in the design to allow for either or both of those. You may have a design that is perfect but that doesn’t mean that it was manufactured correctly. No manufacturing process is perfect. And as far as the end customer is concerned, she doesn’t care whether the problem is because it wasn’t designed correctly, or it wasn’t manufactured correctly. The end result from the customer perspective is the same. And customer problems are what you want to avoid. You want to ensure customer satisfaction, and then of course after your testing, there is maintenance. So, this is the most simplistic depiction of the system engineering process throughout the lifecycle which is the central to good product development.