Towards a Logical Schema Integrating Software Process Modeling and Software Measurement

Towards a Logical Schema Integrating Software Process Modellingand Software MeasurementRichard Webby * and Ulrike BeckerFraunhofer Institute for Experimental Software EngineeringSauerwiesen 6, D-67661 Kaiserslautern, Germany*On sabbatical until June 1997 from the Centre for Advanced Empirical Software Research, University of New South Wales, Sydney 2052, AustraliaAbstractThis paper introduces a logical schema for the integration of software process modelling and software measurement. The schema promotes a common understanding of concepts and terminology, serving as a bridge across the fields of process modelling and software metrics. It presents a formal unified view of the major information entities and their inter-relationships. The schema is designed to be general enough to be used with a variety of different process modelling formalisms and metrics approaches. It incorporates several abstraction mechanisms to support the handling of complex process information and multiple evolving versions of that information. The schema should be useful for both researchers and practitioners in empirical process modelling studies of large-scale systems development and evolution. This paper concludes by contrasting our position with the conceptual schema developed at the Software Engineering Institute. The SEI schema has been a major influence on our work, but the paper also outlines some significant differences between their schema and our own position.Keywords: software process modelling, software measurement.1. BackgroundThis paper presents a logical schema which aims to promote the integration of software process modelling and software measurement. The schema is designed to enable the modelling and measurement of software development and evolution processes in a manner independent of specific metrics approaches and process modelling languages.We anticipate that this work will have several benefits to both practitioners and researchers:• The explicit formulation of a logical schema or ‘meta-model’ bridging the two fields of process modelling and software metrics will lead to more precisely defined terminology and better understanding of common concepts and their inter-relationships.• The abstraction of the schema from the specifics of process representation formalisms and measurement methods enables a high level of independence between the data stored and the views of the data [CK92]. This moves us closer to the goal of organisational software experience bases [Ba94,KP93].• The definition of the interfaces between process models and measurement will enable tighter coupling of modelling tools and measurement technology. In so doing, the vision of an integrated software engineering environment [Lo93] is more achievable. T he ideas that we present in our schema are based extensively on existing work from both the fields of software process modelling and software metrics. From the process modelling perspective, our work borrows heavily from the conceptual schema for process definitions and models developed at the Software Engineering Institute (SEI) by Kellner and his colleagues [AK94]. Our work extends that schema, moving towards a more precise logical model of software process information. We present a comparison of the schema of the SEI group with our approach in section 3 of this paper.Other influences on our work from the process modelling perspective include the experiences gained with the process modelling language MVP-L [BL95], strategic dependency models [YM94], the E 3 project [Mo95] and numerous interviews with, and feedback from,practitioners of software process engineering.From the measurement side, we have been influenced by many sources, particularly the work on the TAME resource model [JB88] within the context of the GQM measurement paradigm and the recent work related to the SQUATter project [Wa96] within the Model-Measure-Manage paradigm (M 3P) [OJ97].2. PositionTo graphically and formally present the schema, we have adopted the recently released Unified Modelling Language (UML) developed by Booch, Jacobsen and Rumbaugh [Ra97]. The object-oriented notation of the UML was chosen as it is likely to become a standard in the field.2.1 Relationships among classesThe schema incorporates support for a variety of relationships among the classes used to represent real-world entities in the domains of software process modelling and measurement. The general types of relationships supported are common to those found in object-oriented modelling. We have chosen to present the relationships prior to a detailed discussion of the classes because much of the power and succinctness in the schema comes from the application of these relationships.2.1.1 InstantiationA major challenge in designing the schema was to allow modellers to specify abstract “types” (eg. an IEEE standard, a code complexity metric) as well as actual real-world “instances”, or values, of those types. The goal was that the schema would be useful for both:• prescriptive modelling, in which the activities that should be performed, the artefacts that should be produced and the measurements that should be taken can be indicated for a given type of project, and• descriptive modelling, in which observations of the actual activities performed, artefacts produced and measurements taken are made for a specific actual project.For the purpose of clearly separating type and instance data without creating a host of additional classes, a class called Enactment was designed to serve as the intermediary between any Element (eg. Activity, Artefact) and the Values assigned to its Attributes (see figure 3). The Enactment class also has the benefit of providing formal support for tracking multiple versions and measurements at different points in time during process performance. This allows flexible maintenance of historical, planned and current measurement data and models.2.1.2 AggregationWith complex process models, there is frequently the need to aggregate activities and artefacts into higher level entities. Aggregation is shown by the diamond symbol in the figures. Where possible, measurements should be taken for the lowest level entities (“elementary processes”), but this is not always possible in practice, so is not enforced in the schema. Measurement at the low level allows propagation of these values to the higher levels of aggregation in the model.2.1.3 SpecialisationAny Entity class may be sub-typed (see figure 1) to allow specialisation of its attributes and associations. For example, attributes such as “effort” could be specified at the root level of the Activity class and inherited by all other Activities.2.1.4 Other AssociationsOther domain-specific associations are described in the context of discussing the classes in the next section.2.2 ClassesNote that for space reasons, only the major classes in the schema are presented in this paper.2.2.1 Project-related classes (fig. 1)Figure 1 shows the major schematic entities that are related to the Project class. The Project class is an abstraction of a real-world project or a type of project. This is accomplished in the schema by instantiation (section 2.1.1). A Project may contain activities, artefacts and roles and it may also contain sub-projects through the aggregation relationship (section 2.1.2). The Project class also can be specialised (section 2.1.3), allowing attributes to be inherited by more specialised projects (eg., a hypermedia development project being a specialised form of development project).Activities are abstractions of the ‘things that are done’in the real world of software development and evolution. Our schema allows activities to be broken down into many sub-activities and a sub-activity to be aggregated into more than one activity. This handles the case where, for example, the activity of testing a system component could be viewed as a sub-activity of ‘testing all components’ or a sub-activity of ‘producing that specific component’.Artefacts are abstractions of the ‘things’ used or produced in the real world. These may be documents or files in physical or electronic form. Artefacts and Activities are related through ‘consumes’ and ‘produces’relationships.Roles represent logical groupings of functions associated with the Resources involved in the software process. Some examples of Roles include ‘author’, ‘review team’, and ‘compiler’. Roles act as a link between Activities and Resources (people, teams, and tools). The separation of Resources, Roles and Activities provides flexibility in assigning an Activity to an individual, a team, or an intelligent agent.2.2.2 Resource-related classes (fig. 2)Resources can be modelled independently of Projects.A Resource may be a Tool, an Organisation (which includes teams) or a Person. Organisations and people are related through a many-to-many relationship - many people may be in many different organisations - and people may assume a Position within the Organisation.Activities can be divided up into Tasks. A task is the specific part of a given activity performed by one specificResource acting in one specific Role. This enables attributes such as ‘effort’ to be measured at the necessary level of granularity. The TAME resource model’s [JB88]notion of “Resource-Use” is very similar to our notion of Task.2.2.3 Element associations (fig. 3)Figure 3 shows how the instantiation relationship is supported in our schema. Each Element (project, activity,artefact, task, role, resource) can be enacted and measured at any point in the software process. The Enactments, or states of the elements, are stored in an ordered list to enable retrieval of previous states. Each Enactment contains any number of Values related to the Attributes of the Element.Events may cause a change in state, affecting Attributes through the evaluation of an Expression, which could include simple assignment or entry of a value by a programmer, or could involve the calculation of a complex metric. Some events may be have Constraints which relate to other Attributes in the model. The major event categories that we have identified include:• Scheduled events, such as a milestone which may indicate a measurement point;• Requested events, where an element changes state due to the request of a process performer or due to the triggering of entry/exit criteria;• Selection events, where some path is chosen among competing alternatives (e.g. further testing iswarranted due to the outcome of a product defect metric); or• Unexpected events, such as the loss of a key person,which may be modelled descriptively, perhaps for the purpose of subsequent risk analysis.2.2.4 Attribute associations (fig. 4)Attributes are modelled separately from the actual entities in the model, following the lead of MVP-L. An Attribute has a type (string, integer, etc) and may be optionally assigned a default Value. An Attribute may be calculated using a Metric and fed as input to other Metrics.A Metric is a collection of Expressions, which may be Logical or Arithmetic Expressions, for instance.2.3 Summary of our positionThe logical schema affords a number of benefits to both practitioners and researchers. For practitioners, it helps unify the fields of software process modelling and software measurement, presenting common concepts in an explicit familiar representation (the UML). The schema provides the groundwork for tools to integrate software measurement and process modelling. For researchers, the flexibility in the design of this schema permits the extension of classes such as Metric and Event to incorporate more specific types.**consumes produces******involvescontainsArtifactcontainsProject is_a*1**contains**Entity A ActivityRole{same subtype}Element AnamedescriptionFigure 1. Project-related classesTool belongs to*PersonOrganisation **reports to*PositionResource A *Element ARole ActivityTaskassumes**involves1**11***Figure 2. Resource-related classes*1EnactmenthasValue*constrainsEventConstraintElement A 0..1hasAttribute*instantiates *Dateaffects**constrains **alters***ExpressionLogicalExpression0..1**affects{ordered}(state)**Figure 3. Major element associationsExpression0..1defaultValueAttribute typeLogicalExpression Arithmetical Expression***output toMetric*input to**0..1usesFigure 4. Attribute associations3. ComparisonThe work of the SEI group [AK94, AB94] is compared in this section with our position. Although, as stated, our work is based heavily on the SEI schema, there are a number of practical differences between their schema and ours.First, our schema is closer to being a logical schema than the SEI schema. We have attempted to be more precise and formal by using the UML [Ra97] to specify our schema. In so doing, it is possible that we may have lost some of the generality of the SEI approach. The SEI schema is strong in defining a rich set of process elements and a comprehensive library of possible interconnections between them. We have excluded a number of elements from our schema. For example, the SEI defines an additional entity called Procedure, to separate the “how it is done” information from the “what is done” information in the Activity. We have not yet included Procedure as a distinct entity in our schema, because we desired to achieve a simple initial version of our schema and regarded Procedure as non-essential to the schema’s structure.Second, although we have not represented all the SEI schema in our work, we have also gone further in some areas, so in this sense our work is broader in scope. For example, in the area of measurement, we have defined how metrics and expressions relate to attributes, making the integration with enactment and measurement technology more explicit in our schema.The third major difference is that the SEI schema defines a set of relationship and behaviour classes, whereas our approach was to explicitly specify relationships and behaviours by using the UML’s object-oriented notation. Our schema is suited to implementation in an object-oriented database or equivalent, while the SEI schema is better suited as an introduction to the concepts and as an checklist of the contents of a software process definition.One strong similarity between our position and that of the SEI work, is that the goal of producing a “common denominator schema” [CK92] or “canonical form”[AK94], whereby the schema can be used for translation among different modelling languages and tools, is a common one. We hope that we have contributed in the progression of research toward that goal in this paper. 4. References[AK94]Armitage, JW and Kellner MI. “A Conceptual Schema for Process Definitions and Models”. In Proc. 3rd Int. Conf. on the Software Process, October 1994, pp 153-165.[AB94]Armitage, JW, Briand L, Kellner MI, Over JW, Phillips RW. “Software Process Definition Guide: Content of Enactable Software Process Representations”, Special Report CMU/SEI-94-SR-21, December 1994[Ba94]Basili VR, Caldiera G and Rombach HD.“Experience Factory.” In Encyclopedia of Software Engineering (Marciniak ed.), pp 469-476. Wiley, New York.[BL95]Bröckers A, Lott CM, Rombach HD, Verlage M.MVP-L Language Report Version 2. Interner Bericht 265/95, Fachbereich Informatik, Universitat Kaisersläutern, 1995. [CK92]Curtis B, Kellner M and Over J. “Process Modeling”, Communications of the ACM 35(9), Sept 1992, pp 75-90 [KP93]Kellner MI and Phillips RW. “Practical technology for process assets”. Proc. 8th Int. Soft. Process Workshop, Wadern Germany, March 1993, pp. 107-112[OJ97]Offen RJ and Jeffery DR. “A model-based approach to establishing and maintaining a software measurement program.” To be published in IEEE Software, March 1997. [JB88]Jeffery DR and Basili VR. “Validating the TAME Resource Data Model”. In Proc. 10th Int. Conf. on Soft.Eng., Singapore 1988, pp 187-200.[Lo93]Lott, CM. “Process and measurement support in SEEs”, Software Engineering Notes, 18(4), Oct 1993, pp 83-93.[Mo95]Morisio, M. “A methodology to measure the software process”. In Proceedings of the 7th Annual Oregon Workshop on Software Metrics, Silver Falls, OR, 1995.[Ra97]Rational Software Corporation, Unified Modelling Language, version 1.0, January 1997, downloadable from [Wa96]Walkerden F. “A design for a software metrics repository”. CAESAR Technical Report #96/7, University of NSW, Sydney Australia.[YM94]Yu ESK and Mylopoulos J, “Understanding ‘why’ in software process modelling analysis and design”. In Proc.16th Int. Conf. on Soft. Eng. Sorrento Italy, May 1994, pp 159-1685. BiographyRichard Webby is a Lecturer in the School of Informa-tion Systems, and a Researcher in the Centre for Advanced Empirical Software Research (CAESAR), at the University of New South Wales. During 1996-97 he is on sabbatical for one year as a Visiting Researcher at the Fraunhofer Institute for Experimental Software Engineering in Kaiserslautern, Germany. His research interests lie in the fields of software engineering and decision support sys-tems. Specifically, he seeks to explore the software proc-esses underlying graphical user interface development, and to empirically measure and assess software end-products. His PhD research involved the development of a graphical interactive decision support system and empirical assessment of its effectiveness in terms of decision quality. His recent research has been in the design of a prototype process modelling tool called Spearmint.Ulrike Becker received her Master's degree from the University of Kaiserslautern in 1996. She is a member of the Process Modelling group at the Fraunhofer Institute for Experimental Software Engineering. Her main research interests are in software process modelling, especially multi-view modelling, and how to integrate data collected on a role-specific basis. She is currently also involved in the development of the Spearmint process modelling tool.。