Tag des Systems Engineering 2014
The Gesellschaft für Systems Engineering e.V. - The German Chapter of INCOSE (GfSE) invited the German speaking systems engineering community to meet in Bremen from 12 to 14 November for the annual German systems engineering conference, the Tag des Systems Engineering. The first day was traditional reserved for tutorials. On the other two days, the conference programme featured keynotes and paper presentations. One track on the last day was dedicated to the finalists of this year's student awards to present their papers. The student award winners were then announced at the closing plenary. The exhibition and the social events provided plenty opportunities to meet and to communicate.
For me, this year's TdSE was an important opportunity to introduce myself in the new role as systems engineering trainer, coach and consultant. Since my first appearance in the INCOSE perimeter I had always been an employee of EADS. Thus, I had to explain my motivation for taking up new challenges repeatedly. To make me known in my new role I had decided to take a sponsorship for the TdSE. This gave me the opportunity to introduce the logo and to get my training flyer distributed with the conference files. This was one reason why I did not follow the presentations very much. The other reason was my own involvement with a tutorial, a paper, and the student awards.
On Wednesday I held a tutorial on the subject Value Stream Oriented Systems Engineering Management (Wertschöpfungskettenorientiertes Systems Engineering Management). The context of systems engineering management is defined by the system life cycle and the enterprise performing systems engineering with respect to a particular system. For defining the systems engineering management processes a staged approach is proposed. On the top level, a Programme Management Plan defines the actual system life cycle including the information and organisational interfaces between the individual system life cycle phases. For the system life cycle phases concerned with system development, a Systems Engineering Management Plan (SEMP) is proposed defining the coordination between all the engineering teams in charge of particular systems and system elements. I still prefer the term SEMP even it has been deprecated by INCOSE in favour of the term Systems Engineering Plan (SEP). There are two main reasons for this preference. First, the focus is on system life cycle phase management and not on detailing all processes. Second, the SEP is intended to provide a complete process definition. In the proposed three-stage-approach this objective has to be satisfied by the System Development Plans (SDP) of every system and system element. The process definitions in the Programme Management Plan and the Systems Engineering Management Plan focus on those areas for which a common process definition is needed. For example, the PMP contains the process interface definitions between life cycle phases whereas the SEMP defines the cooperation of all the development teams in charge of all the systems and system elements.
The reasoning continues with designating the usual practice - to generate a time schedule with fixed days individual documents have to be delivered - as a non-practical theory. Especially in innovative development programmes, so much lessons learned have to be incorporated what cannot be coordinated by an informal process alone. Only managing the development flow based on executing the value stream sequentially in each iteration provides the necessary continuous control of the evolving content of the final development configuration baseline. The remaining parts of the tutorial illustrates the guidelines for efficient and effective flow management.
The next day I presented my paper titled Qualität im System Design. Based on the requirements on a quality management system as well as the legislation regarding product liability and product safety, three quality objectives are derived:
- Stakeholder needs including customer needs have to be satisfied
- The allocated requirements imposed by the engineering team in charge of the upper level system have to be fulfilled
- The allocated requirements defined for the system element are feasible to be implemented by the system elements on all lower architectural levels within the given time and resource constraints
In order to satisfy these objectives, the engineering team has to develop a technical solution that is expressed by three consistent and complementary views of system requirements, functional definition and architectural definition. These views focus on the emerging features and behaviours on the particular architectural level. Emergence in this context means the system characteristics that cannot be fully expressed in the scope of the system elements.
On Friday, I was completely busy with the student awards. As the chairman of the student awards committee I chaired the finalists' track. Assessing the presentations by myself, and merging all the results from the paper review and the presentation assessment results from the committee members Dr. David Endler, Dr. Herbert Klenk, Prof. Dr. Werner Kohl und Prof. Dr. Gerald Lichtenegger kept me so busy that I missed to update one prepared slide for the award presentation at the closing plenary. The issue was that the ranking of the awarded students had changed due to the presentation assessment. I hope I will avoid the same faux pas again in future.
After the conference has been closed, the annual general meeting of the GfSE took place before recovery from three eventful days could begin.
