Workflow Overview

The activities of the process model are temporarily organised into phases and into disciplines with respect to content. Some of the disciplines include actitivies which contribute directly the system development (i.e. sub system development) and are called core-disciplines. Other ones include supporting acitivities which contribute indirectly (i.e. project management, quality assurance). These disciplines are called supporting disciplines.

The division of the disciplines is done mainly for a better orientation within the process model. The multitude of activities are organised with respect to content into easily comprehensible groups.


Business Process Modeling

The business processes which have to be taken into consideration or which are involved, have to be taken down, to be agreed and to be modeled.

The business processes describe the business sequences and the business management view independendly of a possible system technological realization. Requirements on the system technological support have to be analysed later in the discipline requirement analysis.


  • A-237 Workshop: Define the modelling focus and describe the aims of the company
  • A-238 Model the organisation units
  • A-239 Define the aim and the purpose of the business process modelling
  • A-240 Identify active business partners
  • A-241 Workshop: Identify the business use cases of the active business partners
  • A-242 Identify supporting business use cases
  • A-243 Identify business employees and develop an actor model
  • A-244 Define business processes
  • A-245 Describe business processes
  • A-247 Describe the business use cases essential
  • A-248 Modeling business use case sequences
  • A-269 Optimize and consolidate the business use case sequences
  • A-270 Describe business use cases in detail
  • A-271 Identify the organisational assignment and reorganise the dependencies, if necessary
  • A-272 Develop a business class model
  • A-273 Develop a business use case model
  • A-275 Describe business requirements and rules
  • A-276 Derive and identify system use cases
  • A-290 Check and update the glossary
  • Requirement Analysis

    Analysis and description of all important functional and non-functional requirements on the system which has to be developed (what should the system manage?).

    The requirements of the customer, the user and of other domain experts have to be taken down. Existing documents, for example results of the business process modeling, previous projects, existing systems, etc. have to be analysed.


  • A-15 Requirement specification
  • A-128 Define a preliminary study
  • A-176 Define an outline of the requirement specification
  • A-195 Identify Stakeholders
  • A-200 Identify system use cases
  • A-201 Collection of material
  • A-204 Set up a glossary
  • A-207 Exploratory interface-prototyping
  • A-226 Requirement workshop
  • A-228 Requirement workshop
  • A-229 Detail system use case
  • A-230 UML-business-class-model
  • A-231 Identify and describe output (artifact)
  • A-233 Develop a use case model with associations between system use cases
  • A-235 Identify non-functional requirements
  • A-236 Identify features
  • A-274 Define State Models for State Relevant Business Classes
  • A-289 Check and update the glossary
  • System Development

    Conception and realization of an usuable system, which fits the requirements and the concrete development environment or architecture. The discipline is organised into several sub disciplines.

    The system development deals with a set of small domain related parts and logical parts which have to be developed separately. The development consists of direct sequential# acitivities like analysis, design, implemention and test.


    System Development.Domain Architecture

    The whole system have to be structured into domain sub systems and components. Project internal concepts (but component comprehensive), general conceps and system parts have to be defined.


  • A-28 Identify reference models
  • A-56 Specifiy the data base scheme
  • A-68 Modelling Interaction Models
  • A-71 Check and update the glossary
  • A-86 Develop Dialogs and the Sequential Control
  • A-174 Define or update Enumeration Contents (key value tables)
  • A-206 Describe the system interface
  • A-246 Develop a Sub System Model and a first draft of the business class model, if necessary
  • A-251 Consolidate the UML-business-class-models
  • A-259 Identify dialogue doubles
  • A-260 Develop a domain architecture model
  • A-284 Identify Enumerations (tables of key values)
  • A-285 Restructure a design class model
  • System Development.Sub Systems

    Analysis, design, implemention and test of the individual sub systems (or components) of the application which have to be developed.

    Each sub system exists as an own development dicipline, i.e. the discipline System Development.Sub Systems has in each concrete project for each sub system a concrete instance. The individual sub systems have to be extensively devided and have to be developed parallel to each other in separate development processes.

    Their development have to be sychronized regularly at the end of the iteration. Their activities have to be coordinated in consideration by using a central Iteration, process and change management. A comprehensive domain coherence# is supported by the activities of the disciplin System Development.Domain Architecture.

    The number of sub systems or components depend on the growth of the project.


  • A-26 Specify a dialog
  • A-67 Describe the state model
  • A-70 Develop and Test Reports and Evaluations
  • A-74 Identify and specify data base queries
  • A-76 Develop and test data base queries
  • A-81 Identify and describe exceptions and possible errors
  • A-134 Realize and test a domain related class
  • A-151 Realize and Test the Data Base Mapping (persistancy)
  • A-157 Describe data base mapping
  • A-165 Identify Primitive Data Types
  • A-173 Integrate enumeration (key tables)
  • A-213 Identify and restructure sub system dependencies
  • A-215 Develop a sequence or a collaboration diagram
  • A-232 Develop a design class modell and an evaluated sub system model
  • A-258 Run a code review
  • A-286 Define interaction models
  • Environment and Batch

    The discipline includes all activities, which deal with the development of interfaces to existing surounding systems and with the developoment of batch-programs.

    The activities of this disciplines include mainly the analysis and conception of interfaces, the development of interface programs, the encapsulated connection of external systems and the development of batch-programs (i.e. processing programs without user interfaces and user interaction).

    If these are not project-specified interfaces, but general interface (e.g. # of a central text system, mail box, etc.) you find the relevant activitiy maybe in the discipline system development.project external/#.

    The conception and development of batch-programs are expicitely ordered to this# discipline, because they often have to be procedural developed. Because of this, they need other development activities than the object oriented sub systems within the frame of the discipline
    System Development.Sub Systems.


  • A-7 Identify and Classify System Interfaces
  • A-48 Develop and test an adapter for external interfaces
  • A-58 Identify and specify batch-programs
  • A-59 Realize and Test batch-programs
  • Technical Architecture

    Conception and development of the layer model, existing frameworks and the distribution.

    The providing and integration of technical frameworks, of basic services and cross-section, application comprehensive functionalities for example belongs to the discipline. For example persistence services, login, user and authorization services, connection and print services, E-Mail, client-server-communication, etc. Also the definition of the deployment, i.e. what services, functions and software on which computers have to be run, how the individual computer/node have to be connected, etc.


  • A-150 Set up the Data Base and the Data Base scheme
  • A-187 Define a technical architecture model
  • A-287 Develop an interaction model
  • Quality Assurance, Test, Usability

    Combination of all acitivities for quality assurance of results of the other processes.

    With each iteration the realization of a partial functionality have to be reached. Before the beginning of an iteration all expected results have to be defined. At the end of the iteration the achievement of the objective have to be measured and evaluated.

    The process includes activities, which defines evaluation-, decision- and test criteria for checking the iteration results and also prepares testdata and -cases, runs tests, prepares inspections and reviews.

    Also activities, which systematically supports, controls and combinates developer-, team- or sub systems specified tests and quality assurance measurements.

    Apart from the guarantee and support that the requirements are achieved by the project, the systematically controlling (i.e. delimitation) of the requirements and expectations on the part of the customer, user, etc. belongs to on a certain degree to that.


  • A-18 Check the mile stone achievement
  • A-39 Task review
  • A-51 Test the sub system
  • A-61 Produce/Define test cases
  • A-72 Check the development guidelines
  • A-152 Define a test plan
  • A-153 Run the User Test
  • A-175 Test enumerations (key values)
  • A-254 Develop a test concept
  • A-256 Define the test concept
  • A-257 Update the test concept
  • A-261 Mile stone review
  • A-262 Prepare the product review
  • A-263 Product review
  • A-293 Autmatical System Test
  • A-300 Plan the test strategy
  • A-302 Test the release
  • A-303 coming soon
  • Operation, Distribution and Project Externals

    Preparation of the delivery or operation set up of the software, distribution and installation of the software. Preparation and running of trainings, introduction of the hotline. Also the coordination of all project external activities.

    The transition of a new software is in general connected with numerous obstacles. Expecially the replacement of legacy software by a new one at a certain date needs careful preparation. Data from the existing systems are machanically and clearly converted. Apart from uniformal net environments a certain percentage of the installations are failed and need special support.

    Because of this, the activities deal with completely different areas in this discipline. This extends from activities for hardware and network over to data migration and the preparation of the training documents.

    Also all activities which do not concern directly to the responsibility of the project, but have been done from other projects, departments or external supplies, are included in the discipline. Widening and modification in standard applications and -functions of the system architecture, necessary updates of existing neighbour systems, clrearing of existing data files, etc. belongs to that (see also discipline
    Configuration- and environment management).


  • A-55 Develop global services and classes
  • A-95 Identify and specify project external requirements
  • A-137 Define a migration concept
  • A-138 Prepare the data- and system migration
  • A-139 Develop users documentation
  • A-140 Prepare the user training course
  • A-141 Train the users
  • A-142 Train the hotline, the support and the multiplier
  • A-144 Migrate data and the application
  • A-265 Take over the project results to the maintenance team
  • A-266 Plan the handing over of the project to the maintenance team
  • A-267 Plan the Roll-Out
  • A-268 Run the Roll-Out
  • A-279 Analyse the user questionnaires
  • A-301 coming soon
  • A-304 coming soon
  • A-305 coming soon
  • A-306 coming soon
  • A-307 Realize the Change management Concept
  • Configuration- and environment management

    Set up of the development environment for all project members and regular technical integration of the system.

    The discipline includes activities to run the technical system integration (build process), the versionizing and configuration of development results, and the set up of the necessary infrastructure and development environment. Smaller and project-specific support services for rationalization of the development process belongs to this discipline (e.g. adaption of generization scripts, tools, etc.)


  • A-23 Evaluate the Architecture and the Software Development Environment
  • A-63 Define the configuration management
  • A-155 Set up an Employee Workplace
  • A-168 Set up and fit the project environment
  • A-292 Daily Build and Smoketest
  • A-299 Develop the release
  • Iteration, process and change management

    Domain planning of the project activities in view of their goal achievements and dependencies. Reaktion on changes of the requirements and other project conditions.

    The discipline contains all acitivities to controll and coordinate all other project activities. Especially the sensible, ordered and realisticly distribution of the whole requirements on the individual iterations, i.e. with respect on the content of the organisation of the development process, the evaluation of the actually achieved intermediate results and the relevant control afterwards.

    Within the project progress external (wishes, requirements of the customer, user or legislator) or internal (new experiences about domain and technical connections, possibilities, delimitations, etc.) arising or excluding requirements, risks or chances have to be regularly evaluated and considered in the planning of a project.


  • A-12 Plan the project
  • A-16 Plan iterations and deliveries
  • A-46 Define tasks for iteration i+1
  • A-179 Assess a requirement change
  • A-193 Analyse progress reports
  • A-249 Effort Estimation Workshop
  • A-282 Change or add request for requirements
  • A-283 Approve the alteration of a requirement
  • A-294 coming soon
  • A-295 Weekly Micro-Controlling
  • A-296 Weekly Micro-Check
  • A-297 coming soon
  • Projectmanagement

    Planning and organisation of the ressources, dates, proejct-team selection and running of all activities of the project.

    The activities of the project management are devided into formal, organisational and political activities and also into activities to controll (domain related and with respect of the content) the project (included in the discipline Iteration, process and change management).

    The motivation to seperate those both into partial aspects results from the experience, that they can't done in middle sized and larger projects# by only one person.

    All activites of planning, management, and organisation of the resources (internal/external staff, tools, rooms, etc.), dates, casting and running of all activities of the project, external representation (customer, steering board, etc.) of the project, perception and the putting through of project interests toward the project environment and the whole responsibiliy for the project depends on this discipline.


  • A-2 Define the project aims and the project order.Coordinate them with each other iteratively.
  • A-147 Describe a project conclusion report
  • A-158 Kick-off-meeting
  • A-159 Iteration kick-off-meeting
  • A-172 Make a monthly/quarterly report
  • A-181 Initiate the partizipation prozedure
  • A-182 Inform the personnel council about the new application
  • A-183 Steering board conference
  • A-184 Prepare and do a project presentation
  • A-194 Develop the idea of the system and its aim
  • A-250 Risk management workshop (risks and success factors)
  • A-252 Restructurine Workshop
  • A-253 Make experience report of the project
  • A-298 coming soon
  • OEP - Object Engineering Process, v2.0, 06.11.2006 11:04:28, Copyright © 2003 by oose.de eG