Home | Guide | Process Core | Collaboration | Environment | Glossary | Events | Partner | Publications | References/Links | About OS-PE.org | Impressum


Process Core - Main Elements

ospe-core

Although the engineering process is a multidimensional event of complex interaction patterns one can identify some 'core' of this process which is responsible for the 'content' and the final 'output' of the process. Nevertheless, the following explanations should not be understood as a clearcut definition but as a tentative description, which has further on incrementally to be refined.

  1. The process starts with some problem P which someone (the stakeholder)  is presenting and which will be accepted from some engineering team. The problem is usually associated with certain aspects of an environment E, which has to be considered for the requirements.
  2. The problem P has to become transformed into a requirements document RD by a requirements engineering process R()
  3. Based on the requirements document RD a team can start at least two things: (i)  a modeling process M() which should produce some useful formal models MD for to handle the problem P; (ii) can by some test development TD generate a test procedure T(), which is able to test, whether a system S is conforming to the requirements stated in RD. The system S can either be a pure abstract model --like MD-- or a more or less concrete model --like IS--. The test T() is only targeting the observable input-output behaviour of systems (Black-Box Test). The test results stated in the test protocol TP1 can help either to improve the actual model MD or clarify some requirements in RD.
  4. To implement a model MD as a concrete running system IS one has to convert the model MD during an implementation process I() where one has also to cope with all the known architectural constraints ARCH, resulting from imposed technical frameworks.
  5. The concrete running system IS has also to be tested during a test process T().  The test results stated in the test protocol TP2 can help either to improve the actual model IS or clarify the abstract model MD or help to clarify some requirements in RD.
  6. If the results of TP2 are classified as being acceptable then one can deploy D() the concrete system as a living system LS.
  7. While the living system is in usage U() this can generate  different kinds of user feedback F, which can be positiv or negative. This feedback  can be use for a further improvement of the system.

Revision: 2006/08/12 - 18:41 - © OS-PE.org
Page Start Back Print Search Sitemap Hint LOGIN