A framework for project management

Software Quality Journal 5, (1996) 97-105

A framework for project management

MIKE CURTIS Computer Associates Plc, 220 Wharfedale Road, Winnersh Triangle, Wokingham, RG4I 5TP, UK

Received 1 April 1996

Various technologies have been developed to try to realize the ideal of a fully integrated project support environment, including: centralized repositories, complex configuration management systems, process modelling and workflow, cooperating objects. The different approaches have led to a number of partial solutions and it has often proved difficult to integrate two or more of them to give more complete lifecycle coverage or a more complete view. This paper sets out some requirements for support environments for the management of software engineering projects by considering the major elements that constitute such a project and the necessary interactions between those elements.

Keywords: Integrated Project Support Environment (IPSE), project management

1. Introduction

The purpose of this paper is to describe some ongoing work in the field of project support environments being carried out by the PEIS unit of ICL Enterprises. Some of this work has been previously reported in [l] and [2]. Closely related work is being carried out at Southampton University [3].

One aim of this work is to produce a taxonomy of dependencies between types of information maintained during a software development project so that it becomes possible to provide a suitable language, or collection of languages, that can be used to describe and eventually model the growth of the information base and the information flow between the elements that make up such a project. Such a model could be used to estimate the amount of resources needed for the project, assess the risk and perform impact analysis.

Basic data items are described and their aggregation into objects, the relationships between objects are categorized and examples given,

The major result of this work so far has been ToolPark, an ICL development, which is a generic framework for project support environments. ToolPark is described in section 6. This paper represents the start of an attempt to capitalize on the success of ToolPark and provide a more formal basis for describing the ways in which it can be customized to provide what becomes essentially a bespoke environment for a specific project. In effect it describes a language for describing the structure and operation of a project and a toolset for sup- porting a project. The work to connect the two so that a project description can be directly used to customize ToolPark remains to be done. For a full description of ToolPark see [4].

One major aspect of the work that has not yet been done is the consideration of suitable metrics for measuring progress. ToolPark does however provide the means for representing such metrics and integrating tools for their analysis.

0963-9314 0 1996 Chapman & Hall

98 Curtis

2. Terminology

The following terms are used to indicate various basic items which are used to describe the main project elements and their interrelationships.

work item A piece of work that has to be done as part of the project. The granularity of work items depends on the nature and scale of the project and may range for example from producing a particular software module along with its associated documenta- tion to making a minor amendment to one particular document.

document A physical object produced as the result of a work item. A document has an attribute, its status which reflects the amount of resources so far spent on it and hence an estimate of the amount needed for its completion.

duration A length of time, again the granularity will depend on the nature of the project. timespan A fixed period of time with a start and a finish. resource The use of a physical object for one or more durations. The kinds of objects are

typically people or machines but may also include, for example, books. task One or more work items along with a budget of resources and a timespan. role An entity that can perform a task. The objective being of course to complete the

work item in the given timespan using the given resources. trigger A particular type of work item that involves the assignment of a task to a r61e, thus

initiating work on the work items in the task. Work may not start immediately but the timespan start time provides a point at which work should start.

Each instance of a basic item is represented as data in the project model. Larger scale entities are considered which each constitute major elements of a project (see section

3). These elements are composed of instances of the basic items described above. Such elements are referred to as objects. While they are not currently described as objects in the object-oriented sense there are obvious and close parallels in their behaviour which are worthy of further consideration.

Two categories of relationship between objects are defined.

data action

where some or all of the data can be shared between both objects; where a trigger in one object affects the other. They may in this case be the same object.

The objects in a project that are considered are as follows:

l the Project Plan, l the Document Library, l the Product Configuration, and l the Workflow Description.

3. Project elements

3.1 The Project Plan The Project Plan is central to any project. Its main constituent is a set of triggers. It also contains a set of documents, the deliverables. Consideration of the status of each of the deliverables provides a measure of the progress. One role that must be present is that of manager with the task of perform- ing this analysis of the status and modifying the set of triggers appropriately. The initiation of a

A framework for project management 99

project takes place when, as some task in a higher-level project a manager is appointed who may then define an initial set of deliverables and triggers.

It is one of the fundamental features of this view of the software development process that the project plan is not an immutable object that must be strictly adhered to during the whole lifetime of the project but is something that evolves. A major problem in many projects is that reality diverges from the plan and because the plan is regarded as unchangeable people pretend that they are still in line with the plan and its relevance diminishes because it no longer contains accurate information. An encouraging development in recent years has been the appearance of evolutionary methodol- ogies, exemplified by DSDM (Dynamic Systems Design Method) which encompasses JAD (Joint Application Development) where the user is closely involved at all stages of a project so that changes can be made to the functionality expected in the final result in order to maintain the costs, both time and money, within strict limits.

3.2 The Document Library

The Document Library contains all documents produced during the course of a project. It should be noted that the definition of documents used here is deliberately somewhat vague and encompasses any entity that exists in a computer’s filestore and which persists at least until the termination of the project. Documents within the library must be subject to strict change control.

There must be a role of Librarian to manage the Library and so one of the triggers within the plan will pertain to this r61e, and can hence be considered a part of the library. The library will also contain other work items to do with the maintenance of individual documents.

There will exist a documentary form of the project plan which is contained in the library.

3.3 The Product Configuration

The presumed output from a project will contain a number of items, for example executable code and user manuals. These, together with the items that are necessary to produce them, for example the source code, belong to the Product Configuration. These will be maintained by a Configuration Management tool. Many of the items held here will also be a part of the document library.

3.4 The Workflow Description

In order to carry out the tasks a set of procedures must be defined. These define the interactions between roles and the flow of information between the other objects. Typically the workflow is described using, for example, RADs (Role Activity Diagrams). The Workflow Description also describes the availability of resources and imposes a partial ordering among tasks.

The Workflow Description contains rBles and tasks.

4. Relationships

The two categories of relationship defined in section 2 can be further subdivided.

100 Curtis

4.1 Data relationships

Data relationships are of one of three kinds.

shared

derived

This is where a single data item belongs to more than one object. For example a user manual is part of the document library and also of the product configuration. This is where one data item is derived from another, this is normally but not exclu- sively applied to documents. For example a specification will be derived from a set of requirements. A derived data relationship will normally be associated with an action relationship as there is an implication that a change to one data item may need a change to any that are derived from it.

referenced This is where one data item references another either explicitly or implicitly. For example the rBle of Configuration Manager will reference the manual for the Con- figuration Management tool which is held in the Document Library.

4.2 Action relationships

Action relationships are of one of two kinds.

doit

decide

This is where a tusk must be done. For example a trigger in the plan to write a specific document. This is where the task may or may not need to be performed. For example the change in a resource may require a modification to the plan, or it may be possible to continue without any action being taken.

4.3 Diagrammatic representation

Diagrammatically these relationships are represented as shown in Fig. 1 which shows two objects, the Plan and the Library, as described in section 3 below. Two relationships are shown: a data relationship Dl and an action relationship Al. The kind of each relationship is indicated; these kinds are defined in section 4. This diagram shows that there is an item of data shared between the Plan and the Library, and that there is a trigger in the Plan for a task that will affect an item in the Library.

There may of course be many kinds of relationships between individual data items. These are not our immediate concern except to note that a relationship between objects can be expanded into a set of relationships between individual items, an example of this is shown in Fig. 2.

The one form of relationship that is taken for granted throughout is that of composition where a basic item is considered as part of an object, or one basic item may be considered a part of another.

5. Requirements

A Project Support Environment must provide the following three things.

5.1 A repository

There must be somewhere to store all the basic data items that are produced during a project. This does not necessarily imply that all data must be stored in one single central repository. It may be


Fig. 1. Relationships between objects.

perfectly possible to use the individual repositories provided for each tool, provided that it is possible to maintain the relationships between data items that may reside in different repositories by some means. Two other common approaches are:

l encapsulate each tool as an object (in the object-oriented sense) and access them through an ORB (Object Request Broker);

l maintain a single master repository and import/export data to and from individual tool repositories as required.

5.2 A workflow engine

A tool which can be used to define roles and their interactions and which can also implement a trigger mechanism to start tasks.

5.3 A communication mechanism

A means by which information can flow between tasks. This may be realized by the use of a central repository, where information does not have to actually move but the flow is implemented by modifying access to a static item of data. An alternative again is the use of a message passing service and ORBS.

6. ToolPark

ICI’s ToolPark environment framework consists of a closely integrated set of facilities and tools built on IS0 standard PCTE [5]. The architecture of the environment itself and the tools and facilities within it are object-oriented. To avoid confusion when referring to objects in the object-oriented sense as opposed to objects in the PCTE sense or objects as defined in section 2 they will be referred to as (00) objects. Each tool contains at least the following (00) objects.

l The Tool Object Management System (OMS) which maintains the partition of the PCTE object base that is used by the tool. In the case of a facility this is usually the only (00) object. The set of methods for this object is known as the Tool Object Interface.

l The Tool State (00) object which holds a description of all possible states of the tool and the transitions between them. These are described using high level Petri-nets.

l A set of Tool Window (00) objects, each of which represents a window on the screen.

6.1 PC7-E

PCTE manages what is essentially an entity relationship database. A PCTE installation will

102 Curtis

-----------------------*

action relationship Al

module

Fig. 2. An expanded relationship.

maintain a set of objects and a set of links between those objects. Objects and links may have attributes, links in particular can have key attributes. Objects, links and attributes are typed. The types of objects links and attributes used by an application are defined in one or more schema definition sets (SDS). A process using PCTE must set its working schema to contain one or more SDSs, that process will then only have visibility of the object, link and attribute types that are defined in those SDSs. This means that different processes may have different views on the objects that they are manipulating, seeing a different set of links and attributes on the same objects. Type definitions may be imported into one SDS from another, object and link types can then be extended. PCTE supports multiple inheritance, object types can inherit attributes and links from one or more other object types. A basic set of types is defined in a set of standard SDSs including the base object type object from which all others are derived. A special family of object types can have contents; these would be descendants of the standard types file, pipe and device. Operations to open, close, read and write objects with contents are very similar to the Unix operations, indeed some PCTE implementations provide a version of the standard C input-output library which means that some programs only need relinking in order to work on PCTE.

Links belong to one of five categories: COMPOSITION, EXISTENCE, REFERENCE, IMPLI- CIT and DESIGNATION; which have different combinations of four properties: relevance to the origin, referential integrity, existence and composition. For example a designation link does not have referential integrity, its destination may not exist. Composition and Existence links have the existence property which means that deletion of the link may result in the deletion of the object if it is not the destination of other links. A set of objects connected by composition links will form a composite object. Many PCTE operations may be equally applied to composite objects as well as to atomic objects.

In PCTE virtually everything is represented by objects and links. Processes are represented by a particular type of object and so even are the types defined in an SDS. The set of objects and links that represent types is known as the metabase. The fact that an object is of a


instanceJcmd.kind t

I t

lobiect 1

node-type

4 A t

II i referencejdex.refersJo

elemmt.prcvious

attachment-name.nafers-to

Fig. 3. Lookup facility data model.

particular type is represented by a link from the object to the object that represents the type in the metabase.

6.2 Too/Park common facilities

There are some features that are common to all or most tools in an environment. For example there should be context sensitive help available to a user which should be invoked in a consistent way and which should provide a means of access into a more general information facility, which- ever tool is actually being used. Some examples of ToolPark facilities are as follows:

The user support facility which supplies context sensitive help. The finder facility which finds all the objects in the object base that satisfy a set of arbi-

trarily complicated criteria.

104 Curtis

The registration facility for registering entities when they are installed. The lookup facility which saves and retrieves objects or string values by means of a refer-

ence, which is a sequence of strings. The accreditation facility which provides information about users and the roles that they can

assume. The version facility which ensures that all objects can be kept under strict change control. The report facility which extracts information stored by the lookup facility and inserts it

into a text skeleton.

6.2.1 The lookup facility

The lookup facility is the basis of the document library organizer (see section 6.6). The data model for this facility therefore shows the way in which the document library is organized. This data model is shown in Fig. 3.

Each instance of the lookup facility, such as the document library organizer, consists of a root object and a set of node objects which are organized as a directed acyclic graph. The links from the root to nodes and between nodes are of type next and have a string key attribute element. Access to a particular node can be done by supplying a reference which is a sequence of string values. Nodes have two attributes; total which is a count of all nodes that can be reached by following links of type next, and value which is a string that can be assigned to the reference that denotes that node. It is also possible to attach any type of object to a node by means of links of type refers-to or named-refers-to depending on whether the user wishes to name the link or not.

6.3 Too/Park tools

These are some of the ToolPark tools that are currently available.

Library Organizer which manages a document library. Time Recorder which manages timesheets. Configuration Manager which builds on the version facility to allow users to specify config-

urations of components within a system. Builder which builds on the Configuration Manager to provide a build pro-

cess for configurations. Work Assignment which handles the issuing of assignment briefs and debriefs.

6.4 The Too/Park tntegration Toolkit

The Integration Toolkit provides two distinct forms of integration.

l Each tool and facility provides an API that provides external access to its functionality and its object base from either C or Ada code, and from the command line.

l Advanced code generators enable the construction of new tools that combine the functionality of existing tools and facilities.

6.5 The Too/Park Encapsulation Toolkit

PCTE is a complete environment framework in that it provides all the facilities necessary to


implement tools. It is, however, desirable that there must be some interoperability between Tool- Park and the underlying operating system. It must be possible for a ToolPark user to invoke a Unix program that operates on objects in the PCTE object base. It must also be possible to invoke ToolPark tools from Unix. Both these operations are straightforward. It is, however, necessary that the Unix tools should be able to access PCTE objects, particularly files, and vice versa. PCTE does allow for access to Unix files and some implementations of PCTE allows links from Unix filestore to PCTE file objects. It is, however, sometimes necessary for files to be copied between PCTE and Unix. ToolPark provides a toolkit that assists in the encapsulation of Unix programs for use within it. One example of encapsulation is the use of a C compiler to compile C code maintained within ToolPark.

6.6 Library organizer

This tool manages a document library. It uses the version facility to manage change, the lookup facility to provide access to documents by means of a reference and the accreditation facility to provide information about the various roles involved in document production such as Author, Reviewer and Authorizer. In addition it maintains and provides complete information about the derivation of documents from others and keeps track of cross-references.

A document is represented by an object, which could be a single file or the root of a more complex configuration. This object can be attached to a lookup facility node (see section 6.2.1) by means of a link of type named-refers-to. Objects containing other information about the document can be similarly attached. Cross-references are represented by links of type refers-to.

7. Conclusions

Clearly a great deal of further work needs to be done but the use of ToolPark in a number of situations has shown it to be extremely useful and that the consideration of the structure of a project and its modelling by means of a generic framework such as ToolPark can show clear ben- efits in terms of Quality Control in the software development process. The goal of the current work which is to automate the customization process in such a way as to allow more accurate estimation of costs and more flexibility seems desirable. The refinements of the ideas described here and their application in a practical situation will be reported in a later paper.

References

1. Anderson, M. and Curtis, M. An experiment in automating quality control in software development. In Proceedings of Second International Conference on Software Quality Management (Computational Mechanics, 1994), 2, pp. 619-632.

2. Sivess, V. and Curtis, M. The software lifecycle: an alternative perspective. In Proceedings of First international Conference on Software Quality Management (Computational Mechanics, 1993), pp. 345-360.

3. Sivess, V. Non-functional requirements in the software development process. In Proceedings of the Second International Conference on Software Quality Management (Mechanical Engineering Publica- tions, 1966); pp. 425-436.

4. Curtis, M. ToolPark: an architecture for cooperating tools. In Proceedings of the PCTE94 Conference (PIMB, 1994), pp. 205217.

5. Information Technology - Portable Common Tool Environment (PCTE). ISOjIEC IS 13719, 1994.