Generating Tool-based Process-Environments from ...

Generating Tool-based Process-Environments from formal Process Model Descriptions – Concepts, Experiences and Samples Marco Kuhrmann, Georg Kalus, Norbert Diernhofer Technische Universität München, Institut für Informatik, Software & Systems Engineering Boltzmannstr. 3, 85748 Garching Germany {kuhrmann|kalus|diernhof}@in.tum.de ABSTRACT Developing software and managing projects according to a defined process model is widely accepted to minimize dangers of project-failures. Our experience shows that many processes are hardly accepted and often ignored. Managers and developers have different views on a project, with negative impacts on project-performance due to communication lacks that lead to misunderstandings and quality issues. Introducing processes using accepted working- and tool-environments may increase the acceptance of a process by providing a common platform for project operation supporting all the roles that participate in a project. This paper presents a concept for generating such tool-environments directly from a process description. We focus on process elements that can be used to provide additional project management assistance e.g. cockpit-like controlling mechanisms. We discuss our concept using samples from a case study that used the formal structured German V-Modell®XT as a source and Microsoft SharePoint 2007 Services and Visual Studio Team Foundation Server as target environments. KEY WORDS Software Methodologies, Project Management, Tools, Cooperative Work Support

1. Introduction Well defined and structured software development processes can help to decrease the danger of a project failure [1, 2]. Theories say that documented and structured processes are providing advantages as they reflect best practices and proven methods. In fact we know from practice: lived processes in projects differ from organization-wide introduced ones. Managers having documented processes in mind, often think of heavy-weighted processes like the Rational Unified Process (RUP) [3]. On the other hand developers see no advantage in using these formalized frameworks and their tasks but increased effort due to more documentation. So often documentation is only created as far as it is necessary to satisfy the process’s

needs. Usually this distorts the view on the project. Developers need work patterns, check lists etc. to support their daily work. That’s why agile methods like XP [4] became popular during the last years. Agile methods promise less documentation and more development-oriented processes avoiding fixed structures. The developer’s view on a project usually is code. Processes are often seen as a tool for manager. Managers need input and status information for estimating projectprogress and tools giving them the ability to control the project. Most process models contain corresponding information how to do this. Furthermore, process models can be used to derive project plans. Plans are the viewpoint of a manager. It is necessary to consolidate both views. Several tools try to integrate management- and development-process parts. But only a few processes support this by defining concrete methodologies including management- and development-techniques. So often an introduced process is ignored as it is seen as useless. This often leads to lags in communication, less effective work or quality issues. To increase the acceptance of a process, we learned that it is necessary to integrate process models as tight as possible into established tools. Several tools such as integrated development environments (IDE) provide interfaces for an appropriate extension (process guidance, samples, task- and check lists, reports etc.) [5, 7, 10]. Other tools provide support for collaborative or cooperative work (document repositories, dashboards, wiki-systems, chats etc.). During the introduction of a process, existing tools should be used in the process infrastructure. On the one hand they should be enriched with process content and functionality. On the other hand, also the process to be introduced has to be adopted respecting the used tools. In this paper we present an approach for generating templates and working environments for development- and collaboration-tools out of a formal described development process model. We show how to translate the structure of a process in the context of a specific tool. The paper is

structured as follows: Section 2 gives a short overview over the process we used. It also presents a compact process for process model-transformation and a set of common translation rules. We discuss the rules in the context of the V-Modell XT elements. As samples we use content- and scheduling-elements and give an impression of rule-application and combination. Finally in section 3 we give two real world samples where the presented concepts are used to automatically create project environments out of a tailored V-Modell XT instance.

2. Processes and Translation Rules Lots of current process models are based on formal metamodels e.g. Rational Unified Process [3], V-Modell XT [8] or processes conform to ISO/IEC 24744. The foundation of a formal metamodel (often UML 2-based, see [9]) allows rich tool-supported (e.g. Eclipse Process Framework, EPF, available at http://www.eclipse.org/epf). The problem is that current tools are very specialized. • They support process engineers during editing or customizing a process (RUP/EPF Composer, V-Modell XT Editor). • They support project managers to prepare a project (V-Modell XT Project Assistant). • They support managers in operating a project (inStep Project Management Tool – see http://www.microtool.de/ instep/de/index.asp or Software Project Cockpits [10, 11]). Developers are usually not addressed by today’s processrelated tools. Here we can add additional guidance and support. Processes differ in philosophy, depth or applicability, but we always find similar structures (metamodels) with similar element types (artifacts, activities, roles and so on). We also find similar dependencies between the elements (responsibilities, creational- or content-related dependencies, see [9] for further samples). The element- and structure-types are the process API, which can be used by the tools. 2.1 V-Modell XT Metamodel elements In this paper we present approaches and concepts developed during the project CollabXT [13]. CollabXT provides enhanced tool-support for the V-Modell XT that transparently completes the reference tool-chain. Further information about the V-Modell XT metamodel is available at the web-portal of the German Ministry of the Interior (see www.v-modell-xt.de, English versions are included). This is the landing page where all relevant information are collected and maintained. V-Modell XT elements: First of all we look at the relevant structural elements of the process (metamodel) that are useful for a tool-implementation. A process model always defines a set of artifacts (V-Modell speaks of products) that have to be created during a project. A set of

activities creates or works on the products to be delivered during a project. Finally a process model defines a set of roles describing capabilities and responsibilities of people involved in a project. Fig. 1 is an extraction of the V-Modell XT metamodel and gives a short impression of the elements and their relationships. The V-Modell XT contains some special structures in its metamodel: Usually roles are assigned to activities at first and connected to artifacts only as a flag [3, 9]. Activities have sets of products assigned that they create or work on. V-Modell XT is a product-centered process model and connects roles with products. Roles are responsible for product-quality; activities lay in the background and are not worked out in detail. Since project plans need activities to be scheduled, additional concepts are necessary to derive plans. Activity

responsible 0..1 Role

0..1 Product

0..* supports

0..* 0..* Decision Gate 0..* 0..* Project Execution Strategy

Fig. 1 V-Modell XT Metamodel-extract (content-holding elements to be used for generation) V-Modell XT initial schedule: The metamodel defines element-types that are used to determine the progress of the project related to the plan. V-Modell XT products are assigned to so-called decision gates (milestones with quality gates) that themselves are referred by project execution strategies (see Fig. 1). Project execution strategies are templates for plan-generation. Plans of V-Modell XT projects are not activity-driven. They are oriented on the products (deliverables) to be created on first sight. The activities are connected to the products, but don’t dictate concrete methodologies. During the generation of the schedule, the activities are used to create tasks in the plan. Decision gates are exported to milestones. V-Modell XT Tailoring: The tailoring of the V-Modell XT is used to fit the requirements of a concrete project. The generic V-Modell XT is usually reduced in complexity by removing unnecessary products, activities and roles. The tailoring is supported by the V-Modell XT Project Assistant [15]. During the tailoring project-specific contents and at least one project execution strategy are select-

ed. The selected strategies can be used to “roll-out” an initial project plan by defining an order over the available decision gates. Possible paths between the decision gates are also defined by the project execution strategy. Having completed this procedure, a complete result set of all products relevant for the project can be calculated. This product-set is used to calculate the activities and their assignment to milestones. An initial plan can be created based on this information [12]. Tools and elements to be integrated: Other process models like EPF, RUP or MSF [5, 6] define similar concepts related to metamodels and tools. EPF as an example referes to method- and process-content on the metamodellayer and provides an integration concept. MSF on the other hand has a strict separation of documentation and work items (process/scheduling). Concrete elements and combinations are dependent from the environment and the addressees. Developers for instance need other products and tools as managers. While developers are usually more interested in frames for tests or code-skeletons, managers need reports, schedules and budgets etc. So it is a requirement that from one commonly used process different tools for different roles can be supported. The implemented process has always to be consistent with the project environment – a hard requirement for software cockpits [16] or complex management- and development environments.

structural changes, the second stage preserves all given content and only completes it. This is important at this point if the process to be transformed is certified. Samples: The generation-stage can exist in variants. Currently we have a C#-coded generator for Sharepoint as a first target (see 3.1.) and a scripting-based one for Visual Studio as the second target (see 3.2.). Both generators are derived from our concept. Other specifications may address additional targets, e.g. Lotus Notes.

Targetspecification

Process Model

Tailoring/ Customizing

Enrich, Transform & Generate

Specific Process Elements

2.2 Translation Process To provide working environments only a few process elements have to be taken into consideration. In a simple model managers as well as developers need their particular products, activity-descriptions and some guidance. Plans and dependencies are calculated automatically. In this section we present the overall translation process and present some significant rules for translation. Process stage 1: The abstract process is shown in Fig. 2, which is the starting point in our context with a formal process model, in our case the V-Modell XT. The process can be tailored if necessary. Usually process models provide specialized tools for such operations. In this stage only content-related operations are performed without changes on the metamodel. Process stage 2: The second stage is the translation and generation stage (Fig. 2, center). In this stage, the given process can be enriched by user-defined contents during the generation process. The generation is controlled by a specification of the target to be addressed. The specification contains concrete rules and information for selecting structures and content used for the transformation. In this stage operations on the metamodel are possible. New or updated structures are emitted by the generator. These changes are defined by mapping and translation. As a result of the generation-stage the input-process has been transformed according to the target-specification. As the first stage performs content-related customization without

... Translated Process Model 1

Translated Process Model n

Fig. 2 Overall Translation-/Generation-Process 2.3 Translation Rules In this section we give some simple but impressive examples of translation rules. The rules are extracted from the CollabXT-concept. A translation rule is given in pseudocode and describes the creation of elements in the target environment from elements of the source process model. Relevant elements are: products, activities, schedule and the process guidance. We give some samples: 1. Tasks (Sharepoint): Sharepoint defines different kinds of task lists that can also be used in the context of a (simple) project-plan. The rule that makes Sharepoint-tasks from V-Modell XT activities is given by the rule: for each(Decisiongate in plan.DecisionGates) { create(new Milestone(Decisiongate)); for each(Product in Decisiongate.Products) {

create(new Task(Product.Activity)); Milestone.assign(Task); }

available in the TFS-work item tracking system. So the rule is modified as follows:

} The activities and decision gates are given by the initial schedule. As mentioned in section 2.1., relevant activities can be calculated from the product-sets assigned to the decision gates. The lists of activities and decision gates are transformed to a combined list of milestones that have tasks assigned. The Task-entity is provided by Sharepoint as default (task list). The Milestone-entity is provided by an additional project-planning web part-component. 2. Tasks (Visual Studio): Visual Studio also provides task management capabilities. The target specification uses its own work item type (WIT, see section 3.2.) that models are specialized tasks for the V-Modell XT – so called Action Items. The rule is similar to the Sharepointrule: for each(Decisiongate in plan.DecisionGates) { for each(Product in Decisiongate.Products) { create(new ActionItem(Product.Activity)); map(Decisiongate, Areapath); map(Decisiongate, Iterationpath); connect(ActionItem, AreaPath); connect(ActionItem, IterationPath); } } Area- and iteration-paths are fields from TFS-infrastructure used for work item tracking, security and reporting. Work items are assigned to an iteration, which is mapped to a decision gate. The mapping is prefabricated and is based on decision gate-types from V-Modell XT. 3. Documents (Sharepoint): The V-Modell XT standardtools create specialized sets of documents for the tailored process. This so called product library has to be provided, too. For Sharepoint the following rule is used: for each(Productgroup in process.ProductGroups) { create(new DocumentLibrary(Productgroup)); for each(Product in Productgroup) { add(Product, DocumentLibrary); // make connections to other elements… connect(Product, Activity); } } The product library contains content related products. By default the product library is given by a directory-hierarchy and RTF-files. This structure is stored to Sharepoint. 4. Documents (Visual Studio): TFS document management is also based on Sharepoint [5]. So the rule can be reused here but needs some extensions respecting TFS’s needs. Due to the separate work item tracking system, specialized work items are needed that represent concrete product-instances. These elements are required to link the content- and scheduling-systems. This makes products

for each(Productgroup in process.ProductGroups) { create(new DocumentLibrary(Productgroup)); for each(Product in Productgroup) { // for Sharepoint… add(Product, DocumentLibrary); // create also a work item for TFS create(new ProductItem(Product)); // make necessary connections… connect(ProductItem, AreaPath); connect(ProductItem, IterationPath); } } The rule creates document libraries as a first step. In the following steps “proxy”-work items are created and included in the work item tracking system. The connection is also possible between product work items, tasks and so on. All elements in this platform are traceable due to the link structures. Realization: We only gave four examples addressing two different targets. All tools take a (tailored) V-Modell XT instance as input, which is an XML-file and can be parsed e.g. using XPath. Depending on the target platform the XML-selection is either be transformed to another XMLbased structure (Visual Studio process template) or interpreted to execute code (Sharepoint).

3. CollabXT – Samples In this section we extend the basics to an integrated approach that is able to generate whole collaboration-supporting tool-environments. In the following we present results from two case studies realizing generators for the V-Modell XT. Each case study used an own interpretation, we will shortly introduce. 3.1 Sample: V-Modell XT-Sharepoint Integration The integration of the V-Modell XT with Sharepoint uses a fully automated generator. All components (expect the Sharepoint layout-template) are completely generated. The Sharepoint-solution we already introduced in [13]. On the web a web cast can be found at http://zfs.in.tum.de (German) that gives further impressions. Due to the availability of an English version of the V-Modell XT we can support English Sharepoint-users, too. In addition to the last section’s statements, Sharepoint provides task lists, programmable web part-components and document libraries. Document libraries in our scenario are used to store VModell XT product libraries (see rule 3). Task lists are, according to rule 1, used to hold activity-based data from the imported V-Modell XT schedule. All elements are connected according the definitions from the V-Modell XT including the process guidance. As sample we give

the product Projecthandbook, which is located in the product group Projectmanagement and is created by an activity Create Projecthandbook. According to rule 3 a Sharepoint document library named “Projectmanagement” is created. The library contains a product “Projecthandbook”, which has assigned a task “Create Projecthandbook” that is created according to rule 1. In addition the task is stored in a task list and is referred by a milestone Project defined that is generated from a decision gate. The task is filled with information (relationships, documentation) from the V-Modell XT. V-Modell XT also contains information for project progress determination. In this scenario we chose the product state machine to create traffic-light indicators as shown in Fig. 3.

model for the project execution strategies are also part of the meta-template. V-Modell XT Template creation: Generating a concrete V-Modell XT-based process template only requires the meta-template and a tailored V-Modell XT instance from the Project Assistant. The V-Modell XT instance consists of the exported HTML-documentation, the product library and the tailored V-Modell XT XML-file. The CollabXTgenerator merges according to the process in Fig. 2 the VModell XT instance with the meta-template, creates concrete project structures based on the selected project execution strategies and default work items based on the initial project plan. The product library is imported to the project’s Sharepoint portal according to rule 4. Furthermore the V-Modell XT documentation is integrated as well in the Sharepoint portal as in the Visual Studio IDE.

Fig. 3 A generated project portal with traffic-light elements for status determination (German process version) The Sharepoint-integration is a simple scenario addressing project managers and non-development settings. The focus is document-based collaboration and simple task management. 3.2 Sample: V-Modell XT-TFS Integration This second case study uses a generator that is partially automated. As Team Foundation Server (TFS) [5] uses a template-based system for managing processes, we decided to prefabricate core elements of the V-Modell XT according to an export-/translation list. Stable elements are included in a non-insatiable meta-process-template. This template is enriched by a generator with content from a tailored V-Modell XT-instance during the generation process. The TFS-Meta Template: TFS is a generic process platform that can manage several processes. The TFS web portal on Microsoft Developers Network (MSDN, http://msdn2.microsoft.com/en-us/teamsystem/) refers to some implementations of RUP, MSF or Scrum [14]. The process management is template-based. A process template is a simple directory structure containing templates for the Sharepoint portal, a set of work item type definitions including a list of defaults, the process guidance, queries and reports. For our scenario we constructed a meta-process template that contains all relevant concepts from V-Modell XT as work item types, e.g. product-, action- or decision gate-item types. Specialized queries for the newly defined work item types and a generic phase

Fig. 4 Sample, integrated Visual-Studio environment created by the generator (German process version) The generated process template can be imported to the process template manager of TFS. V-Modell XT is now available for new development projects using the Visual Studio environment (Fig. 4).

4. Conclusion In this paper we presented our process-integration concept developed and tested for CollabXT. The concept requires a metamodel-based process model and a customizable target tool-environment. Using abstract, process-related rules for translating certain process elements or whole process sub-models to any object model we are able to address many tools appropriate for process support and operation. The usage of translation rules enables users also to define controlling elements, e.g. a product state-

machine as shown in section 3.1. This enables process engineers not only to define process (controlling) structures but also to prepare process improvements. The concept itself is generic. We can use all process models as input that are based on a metamodel and are available in a machine-readable format like XML. Many different tools can be addressed. CollabXT can be seen as proof of concept. Currently the approach is tested only using the fully formalized V-Modell XT (German edition). The rules we defined till now only address this process so that other processes need own rules or at least rule extensions. Another limitation is the requirement that some process outcomes, e.g. templates and documentation, need to be exported. All generator-components are designed to extend the V-Modell XT reference tool-chain. The first implementation that makes connections to non-V-Modell XT tools is provided by the CollabXT generator for Team Foundation Server. Next evaluation steps are tests with English models. Next research steps are the extension of the rule-/generator-system to be more configurable and dynamic as well as include sophisticated concepts from software (project) cockpits [11, 16] to provide additional value.

[4] K. Beck & C. Andres, Extreme Programming Explained. Embrace Change: Embracing Change (Xp) (Addison-Wesley, 2004).

One of the most important advantages of this concept is the straight forward tool-support. The rules define what process elements are provided to a tool and in consequence are shown to the user. The support is transparent to the users and fully integrated into their familiar working-environments. Based on one process as input for the generator-system with more than one target, all users are given the optimal piece of the process. And only the pieces they need. The capabilities in monitoring, controlling and reporting added with this high degree of automation also support software process improvement (SPI). Necessary information for assessments (e.g. CMMI, ISO 9000) about process/project environments can be modeled during the generators’ target definition. Assessments can be supported by reports generated from prefabricated data structures and live project data. Furthermore projects are executed more homogenous since accepted tools are supported and integrated with an established process.

[11] M. Kuhrmann, J. Münch & A. Rausch, Metamodellbasierte Integration von Projekt Controlling Mechanismen in das V-Modell XT – Positionspapier, In Informatik 2006 - Beiträge der 36. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 2006, 103-109.

References

[15] M. Kuhrmann, D. Niebuhr & A. Rausch, Application of the V-Modell XT - Report from A Pilot Project, In Proceedings of International Software Process Workshop, SPW 2005, 2005, 463-473.

[1] R. Buscheröhle, H. Eckhoff & B. Joskow, Success – Erforlgs- und Misserfolgsfaktoren bei der Durchführung von Hard- und Softwareentwicklungsprojekten in Deutschland (BIS-Verlag, 2006). [2] The Standish Group International, Chaos Reports (2004). [3] P. Kroll & P. Kruchten, The Rational Unified Process Made Easy – A Practinioner’s Guide to RUP (AddisonWesley, 2003).

[5] S. Guckenheimer & J. J. Perez, Software Engineering with Visual Studio Team System (Addison Wesley, 2005). [6] M. Turner, Microsoft Solutions Framework Essentials (Microsoft Press, 2006). [7] N. ben Ahmed Boulila, A Framework for Distributed Collaborative Software Design Meeting (PhD-Thesis, Technische Universität München, 2005). [8] A. Rausch, R. Höhn, M. Broy, K. Bergner & S. Höppner, Das V-Modell XT (Springer, to appear in 2007). [9] Object Management Group (OMG), Software Process Engineering Metamodel Specification (OMG, 2005). [10] J. Münch & J. Heidrich, Software project control centers: concepts and approaches, The Journal of Systems and Software, 70, 2004, 3-19.

[12] K. Bergner, Plangenerierung im V-Modell XT 1.2, In Informatik 2006 - Beiträge der 36. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 2006, pp94. [13] G. Kalus & M. Kuhrmann, CollabXT – Ein Ansatz zur automatischen Erzeugung von Kollaborationsportalen aus dem V-Modell XT, In Proceedings des 14. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.V. (GI), 2007, 29-40. [14] K. Schwaber, Agile Project Management with Scrum (Mircosoft Press, 2004).

[16] J. Münch & J. Heidrich, Software project control centers: concepts and approaches, In The Journal of Systems and Software, 2004, 3-19.