Systems engineering process

A systems engineering process is a process for applying systems engineering techniques to the development of all kinds of systems. Systems engineering processes are related to the stages in a system life cycle. The systems engineering process usually begins at an early stage of the system life cycle and at the very beginning of a project, but as stated by Bahill and Briggs (2001), systems engineering can also start at the middle. A variety of systems engineering processes have been proposed by different organizations.

History

Several systems engineering methods and process guidelines have been developed since 1969. These methods describe all the activities and deliverables of a systems engineering project.

The first, Mil-Std-499 is a military standard of the U.S. Department of Defense and was used to create complex systems, for example, a nuclear submarine or missiles. The build up body of knowledge has become known as systems engineering. Since IEEE has developed 1220, the systems engineering standard has become commercial.

The early systems engineering methods, such as Mil-Std-499B (see figure 1), are focused on the verification and development life cycle functions, but the later methods cover almost the whole system life cycle. Systems engineering and software engineering have evolved as independent processes, but recent process guidelines and standards emphasize the need for integrating both these processes. (Boehm, 2005)

Process description

The meta-model in figure 2 shows a systems engineering method. The activities in the model can be somewhat different in a specific project. This is derived from several existing standards, marked in figure 1. ANSI/EIA 632 serves as the basis for this method, since many current systems engineering methods are based on this standard. Further, ISO/IEC 15288 and the INCOSE Systems Engineering Handbook, which are more recent, serve as source for this method. The final source is an older standard, Mil-Std-499B. The activities and concepts in the model are explained here. The model is separated in four main processes. The Agreement, Project, Technical and Evaluation processes. These will be explained in further detail below.

Agreement processes

The first step in the systems engineering process is to establish an agreement with the customer, an order to build a new software product. This order is set when the outcome of the feasibility study is positive: there is a need for a new software product and there is no other product that can be used or it will be more cost effective to create a new product. When the outcome is negative, the project will end here. The input of the feasibility study is an acquisition phase and a problem definition. A well known way to acquire knowledge is the structured or unstructured interview. This technique and several other acquisition techniques can be used to define the needs of the customer, user and other stake holders.

Project processes

After an agreement is made, the planning of the project will begin and this results in a project plan, which can be modified during the technical processes. In fact, the project processes are not sequential processes and go in parallel with the whole project, because at each moment a project needs planning, assessment and control. The design loop indicates that during the technical processes, after each step the project-management will assess whether changes have to be made in for example the schedule, which falls under project management. To ensure that a project will be successful the project management takes care that objectives are met within time, costs and a certain performance level, to help the project-management with this a work breakdown structure is made. Configuration management records the changes that are made in the design or requirements. This enables stakeholders to comment on a certain change proposal. But very important for a project success is risk control. Identifying risks and think about solutions in an early stage will save a lot of work and money in a later stage.

Technical processes

The technical processes cover the design, development and implementation phase of a system life cycle. In the earlier agreement phase top level (or customer) requirements have been established. This set of top level requirements are translated into software requirements which will define the functionalities of the software product. These software requirements can lead to a few alternate designs for the product. Each requirement is periodically examined for validity, consistency, desirability and attainability (see evaluation processes). With these examinations, or evaluations a decision can be made on the design. With the chosen design a requirements analysis will be performed and a functional design can be made. This functional design is a description of the product in the form of a model: the functional architecture. This model describes what the product does and of which items it consists of (allocation and synthesis). Thereafter, the product can actually be developed, integrated and implemented in the user environment.

Evaluation processes

Another loop in the model is the evaluation loop. During and after the creation of a software product the following questions have to be answered: Does the product do what it is intended to do? Are the requirements met? and as mentioned in the previous paragraph: Are the requirements valid and consistent? How is the requirements prioritization? This requires that the requirements are testable. For example a usability requirement, such as “the software product must be easy to use” can be tested through a heuristic evaluation.During the lifetime of a software product it will be continuously revised, updated and re-evaluated until the product is not used anymore and is disposed of.

Meta-model

On the left side of the process-data model (figure 2) are the activities, as they are explained in the activity table. The right side shows the concepts and deliverables of the systems engineering process and are explained in the table of concepts.

Example

To clarify the systems engineering process, figure 3 contains an example of such a process. It is a quite simple example and not every step of the process is mentioned. Furthermore, systems engineering might be more appropriate for a more complex system, but the example gives a slight idea of the practical use of systems engineering. The CEO of a software company encounters a problem: a (systems engineering) method has been made, but now he wants to share this method with his employees. To acquire all their needs, interviews with stake holders, including the CEO are performed. This results in a list with initial requirements. The feasibility study points out that there is no such system already available that would be appropriate and less expensive than creating a new framework to display the method. There are three possible solutions to the problem: A book that describes the method, a CD-ROM or some XML pages that can be used over an intranet. The Requirement that one has to be able to quickly search through the processes can be met by creating a CD-ROM or the XML pages. But during the project another requirement is added to the list: the content must be reusable. This rules out the CD-ROM, because with each update a new CD-ROM has to be given to the employees. This would also object the low-cost requirement. So, only the last alternative, the XML pages, is sufficient. Even when the requirements and solution are re-evaluated this alternative is the best design. Then, a functional architecture is made and the product is divided in sub functionalities. After creating the sub products, it is integrated and implemented in the organization. Because of all the evaluation and the involvement of the user the intranet is commonly used. The project is successful.

Activities

Concepts

See also

Another (funny) example can be found [http://www.gmu.edu/departments/seor/insert/story/story1.html here] . This story is about mowing in the graveyard.

Other Wikipedia entries that might be interesting:

*Systems Engineering
*Software Engineering
*Requirements analysis

*Meta-modeling
*Meta-Process model

*Configuration management
*Risk management
*Project management
*Process architecture

References

*(2004) Defense Acquisition Guidebook, Chapter 4: Systems Engineering. Retrieved February 15, 2006. [http://akss.dau.mil/dag/Guidebook/IG_c4.0.asp]

*Bahill, T. & Briggs, C. (2001).The Systems Engineering Started in the Middle Process: A Consensus of Systems Engineers and Project Managers. Systems Engineering, Vol. 4, No. 2 (2001)

*Bahill, T. & Dean, F. (2005). What Is Systems Engineering? Retrieved February 15, 2006. [http://www.sie.arizona.edu/sysengr/whatis/]

*Boehm, B. (2005). Some Future Trends and Implications for Systems and Software Engineering Processes. Systems Engineering, Vol. 9, No. 1 (2006)

*Vasquez, J. (2003). Guide to the Systems Engineering Body of Knowledge - G2SEBoK. Retrieved February 15, 2006, from the International Council on Systems Engineering. [http://g2sebok.incose.org/app/mss/menu/index.cfm]