Towards an Integration of Process Modeling and Project Planning
(a)eInsuranceSystem 200xDesign(b)starts after endstarts after endIncrement 1starts after endBusiness LayerImplementationDatabase LayerImplementationIncrement 2ends after endErrorManagementImplementationends after endends after endends after endDatabase LayerIntegration TestErrorManagementIntegration TestBusiness LayerIntegration Testends after endends after endends after endBusiness LayerIntegration TestDatabase LayerIntegration TestFigure 5. Structural Project Plan Showing Activities:(a) Valid Instantiation, (b) Invalid InstantiationAccording to the process model in Figure 2, in thestructural project plan in Figure 5 (a) the Business LayerImplementation has to start after the end of the eInsuranceSystem 200x Design. However, the fact, that the BusinessLayer Integration Test has to end after the DatabaseLayer Integration Test is just mentioned in form of a hintin the process model in Figure 2. This ordering is neverthelessrequired, because the Business Layer Implementationhas a uses dependency to the Database Layer Implementation,as defined by the component architecture inFigure 3. In contrast, Figure 5 (b) does not provide a validinstantiation of the process model from Figure 2.Let us also assume that the project manager decides tobuild the “eInsurance System 200x” in two increments.The first increment contains business and database layerwhile the second increment contains the error management.As shown in Figure 5 (a), the Error ManagementImplementation is starting after the first increment hasbeen finished (which in practice is not the best idea butsuits us here).The problem is that the process model does not containall necessary information in terms of a formal description.This means that a derivation of a structural project plancannot be done automatically. In our example, the requiredinputs seem to be the system’s component architectureand the assignment of the components to increments.For a clever project manager it is easy to keep anoverview of the “eInsurance System 200x” project example.However, for projects more realistic in size, as well asfor process models more realistic in size, building a projectplan, which is consistent to the company’s standardizeddevelopment process model, will get very complexand tedious.3. A Layered Modeling ApproachStandardized software development process models arequite different in practice and usually contain specificsolutions for certain types of projects and organizations.Therefore, providing a single process model, which allowsfor the consistent instantiation of a project plan,would to be a little contribution. Furthermore, processmodels such as the V-Modell 97  for example, whichcan be adapted to almost every project, are so generic thattheir usefulness as a guideline for a concrete project mightbe doubted.Our modeling approach, depicted in Figure 6, is toprovide a Process Metamodel, which establishes a com-
mon language for describing Process Models. We use alayered modeling approach according to the metamodelstructure provided in . A process engineer can use thelanguage defined by the Process Metamodel to describe acompany’s specific software development process model(see also ). The Process Metamodel offers clear definitionsfor terms like activity or work product and theirpossible relations.MetamodelLayerModelLayerProjectLayerInstantiationConstraints ModelInstanceInstanceInstantiationConstraintsProject ContextInstanceProcessMetamodelProcess ModelInstanceStructural ProjectPlanFigure 6. Overview of the Proposed LayeredModeling ApproachA Process Model is an instance of a Process Metamodel,providing for example an “implementation” activityand an “implementation” work product. The ProcessModel serves as a model for the Structural Project Plan,since according to our approach the Structural ProjectPlan itself is an instance of the Process Model. Hence, theProcess Metamodel has to specify the elements and theirrelationships in the Structural Project Plan as well, sincethese are instances of instances of the Process Metamodel.For example, the Structural Project Plan might contain anactivity “business layer implementation” as well as anactivity “database layer implementation”, which are bothinstances of the “implementation activity” of the ProcessModel (, which in turn are instances of the activity in theProcess Metamodel).The instantiation of the Process Model involves multipleinstantiations of certain elements, according to theProject Context, which contains for example the concreteproject’s component architecture. On the model layer, theprocess engineer has to provide Instantiation Constraintsfor the Process Model. The Project Context is an instanceof these Instantiation Constraints. On the metamodellayer, there is an Instantiation Constraints Model to providea model (or language constructs) for the processengineer of how to constrain the instantiation of the ProcessModel.Integrating process modeling and project planning isthe basis for a tool-supported derivation of a structuralproject plan from a process model. In our approach, thecoherence of process model and structural project plan ismade explicit by specifying the language as well as theinstantiation constraints for process models in form of ametamodel layer. Process engineers using this metamodellayer have a common language to take care of the applicabilityof their process models for automatically derivinga structural project plan.In order to be able to refer to instances of instances accordingto our modeling approach in the following text,we use the term “instances” for entities in the model layer,and the term “occurrences” for entities in the project layerin the rest of the paper.4. Process Models and Project PlansThis section provides examples according to our layeredmodeling approach. Section 4.1 shows our exemplarymetamodel layer; section 4.2 shows a correspondingprocess model layer and section 4.3 a possible projectlayer. The examples provided here are the same in contentas the examples introduced in section 2.4.1 Exemplary Process Metamodel LayerFigure 7 shows according to our modeling approach aninstantiation constraints model and a process metamodel.The upper part of Figure 7 contains an abstraction (depictedas classes with UML stereotype )from the concrete metamodel in the lower part of thefigure.From an abstract point of view a process metamodelconsists of model classes that are related by binary, directedmodel associations. Model associations can be ofcertain types, establishing particular consistency constraintsfor valid occurrences of model associations in theplan. For example, an association of type one-all statesthat an occurrence of this model association in the projectplan relates one occurrence of a model class with all occurrencesof associated model classes in the plan.Planning units in the instantiation constraints modelare the inputs needed for deriving a structural project planfrom the process model automatically. They determine themultiple instantiation of Model Concepts in the structuralproject plan. Each planning unit has only one instance inthe process model (depicted as classes with stereotype in Figure 7 ), but several occurrences inthe structural project plan. Planning units are composed ofmodel classes and model associations. The intended semanticsis that for one occurrence of a planning unit in theproject plan there has to be at least one occurrence of allmodel classes and associations the planning unit is composedof.