management and monitoring tool designed to assist in. producing better ... necessary for the process model that best fits the projects. needs to be modified to ...
Web-Based Software Engineering Process Management Karlie Hutchens1, Michael Oudshoorn, Kevin Maciunas Department of Computer Science, University of Adelaide. {karlie, michael, kevin}@cs.adelaide.edu.au ABSTRACT It is well known that a sound software process is the basis for a successful software project. This paper discusses the development of a web-based software process management and monitoring tool designed to assist in producing better software projects. The process management tool, developed in the programming language Java, is accessed through standard World Wide Web browsers. This provides access to project management information in a transparent platformindependent manner to geographically distributed programming teams and project managers. Integrity and confidentiality of project information is preserved. Java was chosen as it can be used with standard World Wide Web browsers; it is architecturally neutral and provides good support for graphics. Numerous benefits are derived from this project. Included in these are: global access to project information allowing continuous product development to take place and be managed; a reduction in the number of necessary paper documents; and a higher level of management efficiency through the continuous availability of project information with an expected reduction in cycle time.
1. INTRODUCTION Software projects have the potential to suffer from numerous problems, including: missed deadlines, inaccurate budgets, unmet specifications, product defects, unforeseen project risks, changing requirements, poor resource planning, and poor management. These risks have the potential to turn any software product into a disaster, and to ruin a software organisation. It is possible to minimise these risks by improving project planning and management. Projects that have deficiencies in their plans have the potential to expose people to unnecessary risks [1]. Developing software by following a defined software engineering process is one widely adopted method of risk 1
management. A software engineering process covers activities including the development life-cycle model, collection of project metrics, planning based on past performance, the applicable standards that should be followed when building the software, as well as managing the process. Managing the software process is vital for the success of a project. Suitable management aims to produce better quality software products while simultaneously improving the organisations software capability [2] as specified by the Capability Maturity Model (CMM) [3,4]. Most organisations should be able to achieve levels 2 or 3 of the CMM. This means that any process used in a software organisation needs to be utilised in a manner that enables the organisation to grow and prosper. Failing to manage the process in a responsible manner causes it to degenerate into an inefficient bureaucratic exercise as staff become complacent therefore reducing the effectiveness of the software process. If management see poor results, they are likely to ignore the process which, if managed correctly, could have provided significant benefits. Management of the software process has several benefits. Project plans become more realistic and attainable because they are based on past history rather than guesses and the organisation is in a better position to plan future projects. More realistic project plans mean that resource scheduling can be achieved realistically and deadlines are more likely to be met. Many different software process models exist [5,6] including the Waterfall Model [7], the Spiral Model [8], the Prototyping Model, and the Build and Fix Model. Different process models exhibit different characteristics making some better suited to certain types of software projects. Even though there exists a wide variety of process models, it may still be impossible to select a process model for use on a particular software project because all the existing process models fail to satisfactorily meet the needs of the project. In this situation, it is necessary for the process model that best fits the projects needs to be modified to better suit the requirements of
Support provided throughout this project by the Adelaide based Motorola Australia Software Center is gratefully acknowledged.
the project. For example, suppose that the standard process model for use in an organisation is the Waterfall Model and that the project which is currently planned requires, due to customer and project demands, that an object-oriented development model is used. Therefore, the process model for this particular project should be modified to meet the needs of both the project and the customer. Many of today’s software projects have project teams undertaking the development, often with the members of the project teams being geographically dispersed. Distributed project teams have difficulties ensuring all members of the team receive the same quality and timely access to information. This is also a problem for nondistributed development teams. Having important documents shipped to different locations can lead to time delays and reduce the organisations productivity. Security is another important question raised when documents are transported to different locations. Proprietary information that is sent around the world in an insecure fashion (e.g., E-mail) is a prime target for competing organisations. The problem of receiving timely information can be addressed through the use of the World Wide Web (WWW). This provides a mechanism that can be quickly accessed by people all over the world resulting in project teams in Australia and in the United States, for example, having access to the same information without the time delays caused by shipping documents between the two locations using conventional mechanisms. However, the question of security is even more important with the use of the WWW than using the standard electronic mail system. Measuring a software process is vital to the success of the process [2] and without measurement, improvements will not occur. Process metrics are an important part of any organisation involved with a software process and the collection of these metrics can be integrated with the process. This paper discusses a General Process Management tool, GPM, that is designed to assist in the production of better software products and to assist in managing the software engineering process. GPM allows a software process to be defined, tracked and measured with information related to the process and individual projects being stored for future use. Section 2 of this paper discusses existing software engineering tools and Section 3 presents GPM. Section 4 evaluates GPM and identifies future work and some conclusions are presented in Section 5.
2. CONTEXT Many different software engineering tools exist, all of which are designed to assist with different aspects of software production. Some of the existing tools include: • configuration management tools which provide a means of controlling access to documents and software artefacts helping to make sure that consistent systems exist for different platforms etc., • coding tools which assist in writing and compiling source code, • modeling and simulation tools which allow a proposed system to be evaluated, • structure editors which are designed to allow documents to be produced, and • prototyping tools which assist with building a prototype system. Amongst this arsenal of technology there is a lack of tools explicitly designed to deal with the software process associated with managing and defining a process model. Process models and the documentation associated with a software development process are typically defined on paper, making access to these documents difficult for distributed programming teams. A tool that assists with the definition of process models, and the management of the documentation associated with a process model, is of great potential benefit to a software organisation. This lack of process management tools is surprising because it is well known that improving the software process can be beneficial to a software organisation [9,10]. In order for a software organisation to improve its software process, the process itself needs to be managed in a responsible manner. A semi-automated process management tool would assist greatly with this. A process management tool of this type should not be fully automated because important decisions regarding the deficiencies in a process model and possible ways to improve these problems require human interaction. A collection of tools to assist with the software process are surveyed in [11, 12]. Two systems which are representative of those available are PROCESS WEAVER [13] and ConversationBuilder [14].
2.1 PROCESS WEAVER PROCESS WEAVER is a work-flow process management system developed by Cap Gemini Innovation, France, and is designed to support the work of a group of people. PROCESS WEAVER brings unique benefits to an organisation including:
• allowing business procedures to be modelled, helping to ensure that any work performed conforms to the recommended business process, • allowing pending actions and task completion to be tracked, • providing a mechanism to measure a processes effectiveness through the information that is gathered on project completion, • allowing multiple processes to exist and permitting the user to choose which process is right for the job, • assisting with process improvement and maintenance, through the use of graphical editors, and • improving the responsiveness of the organisation through the editors that allow a process to be modified and the on-line coaching facilities. These benefits are achieved by providing a suite of tools designed to manage the tasks performed by individuals as well as a sequence of tasks performed by a team. Four different levels of process management roles exist: the organiser, the participant, the owner and the system administrator. Participants of the process are responsible for carrying out the process tasks. Interaction with PROCESS WEAVER is through an Agenda in which tasks are sent, received or processed. These tasks appear as icons in the user’s Agenda. Project organisers are responsible for writing process models by using three tools. These tools allow the activity hierarchy, inputs, outputs, roles, the detailed sequence of tasks, and the tasks for each participant to be defined. The process models used in PROCESS WEAVER are described using Petri Nets. Process owners are responsible for ensuring the correct execution of a process and can check the detailed status of the process and interact with it, possibly making modifications. PROCESS WEAVER follows a client/server architecture and is based on a communication architecture using a Broadcast Message Server. PROCESS WEAVER is not architecturally independent thereby reducing the availability of the tool – all users of the process management tool must be using the same hardware platform and must be connected to the same wide area network. This restricts its use for project teams consisting of geographically dispersed members. PROCESS WEAVER contains some of the desirable properties of a process management tool but omits others. A process can be defined and managed in order to provide support for project teams. No support is provided for geographically dispersed members of a project team. Although PROCESS WEAVER addresses the
majority of the desirable features its lack of support for distributed project teams is a limitation.
2.2 CONVERSATIONBUILDER ConversationBuilder [14] is an open environment which facilitates the flow of information among a group of users. The environment can be adapted to different development models and new tools can be incorporated into the environment. Dynamic changes, which occur during execution of a development model, can occur and the environment has some understanding of the actions performed by users and can use this information to provide context sensitive help. Each activity is called a conversation or protocol. The protocol provides a set of rules which govern the behaviour of conversations instansiated from the protocol. A process can be defined using a protocol although defining the process can be tedious. Each project would have a conversation describing the process to be followed. Actions within a conversation are called utterances. ConversationBuilder allows the specification of multiple protocols and allows a user to be involved in many conversations simultaneously. A set of generic actions are provided and a hypertext system exists for linking the nodes of a conversation. Information within ConversationBuilder is stored in a hypertext database. Users are presented with a collection of integrated tools that include text servers, a widget server, a graph browser and a shared whiteboard which together form ConversationBuilder. ConversationBuilder is not designed to specifically deal with a software process as PROCESS WEAVER is but rather to coordinate the work of a group of people. This means that different problems are being tackled by the different sub-systems of ConversationBuilder. However, ConversationBuilder manages to provide good support for the software process through its shared models, the ability to be involved in many conversations and the dynamic webs of interconnections which may exist between activities. A major advantage is that users are kept informed of their activities and the actions of other workers – an important need in a development project following a specific process model. ConversationBuilder, like PROCESS WEAVER, addresses most properties presented in Section 1 but also fails to provide support for distributed project teams. Another limitation is that process definitions cannot be simply created thereby reducing the flexibility of the tool. These are limitations that are addressed in GPM.
GPM aims to provide quality and accessible information to geographically distributed project teams and to assist with management of the project. It also aims to provide current project information to all levels of users whilst protecting proprietary information. Finally, GPM aims to be an easily accessible, and easy to use, tool. Both properties are important for successful adoption of the tool within an organisation. The objective of being easily accessible is addressed by providing access to GPM through standard WWW browsers which permits access from a portable computer in a hotel room as well as access from the office. GPM’s user interface relies heavily on graphics, with some text, addressing the ease-of-use goal.
ets. The server is used to control access to a central data repository. Multiple users in geographically dispersed locations can access GPM simultaneously. Each user has their own instance of GPM which is connected to the server via a socket over the WWW. Security of information is achieved through user authentication via a username and password mechanism and, by encrypting messages sent via sockets. The server runs as a Java application on any platform for which a Java interpreter is available. One restriction that is imposed is that the server must be run on the system where the database is stored. This is necessary because the server accesses the database. It can receive messages from each instance of GPM and can send messages back in response. A connection between the server and each instance of GPM is automatically established when access to GPM is requested by the user. Failure of the server causes the link to be broken and the database to become inaccessible to GPM. Error messages are supplied to the user informing them of this. The central database, as appears in Figure 1, stores information related to process definitions. The database is implemented as a collection of text files that store process definitions and associated metrics information. The database is accessed by all instances of GPM through the server. Access to the database can only be achieved by sending messages to the server and waiting for a response. This ensures a consistent data store. A locking mechanism is implemented on a per process basis which only allows one instance of GPM to modify a certain process definition at any one time. The locking mechanism does not exclude any number of readers and a locked process can be viewed. Viewing a process is described in Section 3.3 and simply means that a process definition is displayed for the user to see but not modify in any way. GPM is implemented as a series of interacting classes. A database class provides the interface between the server and the physical database. All requests for database information must by processed via the methods specified in this class. A collection of dialogue classes exist for the provision and retrieval of information from the user. The final significant class is the process tool class. This provides all the operations necessary to run GPM including the process definition and process tracking components.
3.2 SYSTEM ARCHITECTURE
3.3 OVERVIEW
GPM follows a platform independent client-server architecture as shown in Figure 1. GPM is accessed via the WWW and communicates with the server through sock-
The heart of GPM is its process definitions. Process definitions are specified using the process definition component of the tool and are based on a defined process
GPM
GPM
GPM
WWW
Server
Database Figure 1 – Client-Server Architecture.
3. GENERAL PROCESS MANAGEMENT TOOL GPM, is a web-based process management tool developed in the programming language Java [15]. Java is a programming language that has been designed with the WWW and security [16] in mind. Java allows secure, platform independent programming that can be accessed through standard WWW browsers. This means that an organisation can restrict access to the web page, which ultimately restricts access to GPM. Once started, GPM will continue to operate independently of the WWW browser from which it was started. This provides access to information in a transparent platform-independent manner to geographically distributed programming teams.
3.1 AIMS
Figure 2 – The Waterfall Model. framework using a process notation. Process definitions are extended to include project information using the process tracking component. Interactions between users and GPM occur through a graphical user interface (GUI). GPM’s GUI consists of a main window containing a process display area, various pop-up dialogue windows which can be dismissed when no longer required, and a toolbox that can be displayed or hidden as required by selecting a menu option. The GUI is illustrated in Figure 2 and is an example of GPM with the waterfall model process loaded. A process model must be defined using GPM before it can be tracked. Process models are defined using a graphical notation and are constructed from a set of basic process elements which are displayed in the toolbox, shown in Figure 3. GPM provides four types of process elements: phases, activities, transitions and documents. A phase is a process element that is used to group other process elements, and can be used to build a hierarchical process definition by encapsulating other phases. It
groups related activities together into a single unit and is often used as a synchronisation mechanism. GPM offers two types of phases: a normal phase and a decision phase, called Phase and Decision respectively, in Figure 3. A decision phase differs from a normal phase in that a Yes/No decision must be made as a result of undertaking this phase. A normal phase has no such requirement. An activity is a low level element which cannot be broken down further. Gaining management approval is an example of such an activity. A document process element is used to represent anything which is produced, including source code and design documents. The final type of process element offered by GPM is a transition of which two types exist – a single directional arrow, called Transition in Figure 3, and a bi-directional arrow, called a Double Arrow. Both types of transitions act as a connector between process elements with the transition from one process element to the next caused when the first process element is completed. The single directional arrow is used to represent flow in one direction only to-
wards the arrow head. The bidirectional arrow behaves the same as a single directional arrow in that information flows to the bold arrow head. The difference between these two process elements is that a bidirectional arrow permits backtracking through a process if necessary. This could be caused by omitting a requirement in the requirements gathering phase. A bidirectional arrow will allow an earlier phase to be re-executed to fix a problem. This arrow allows process definitions to be less cluttered than if explicit decision phases were required after every normal phase to determine if the previous phases were implemented correctly or if problems were identified. Associated with each process element, which is not a transition, is a collection of attributes that are used during process execution and to Figure 3 – assist in project planning. Each eleThe Toolbox. ment has an expected duration and an indication of who is responsible for the execution of the process element. In addition to this, a document process element also contains the name of the document and where it is located in the file system. To define a software process model for use on a project, GPM allows an existing process model to be modified. Alternatively, the process can be defined starting with an empty process. Only one user of GPM is permitted to modify a software process at any one time, thus removing the possibility of multiple concurrent updates to the process definitions. GPM only permits authorised users to define or modify a process definition therefore
adding an element of security to the process definitions. Process elements can be added to a process by selecting the required component in the toolbox and then drawing it in the process display using the mouse. Elements can be removed from a process by selecting the element and then choosing “cut” from the edit menu. When any modifications are made to a process the user is required to justify why the change was made. This is designed to provide some reasoning for the software process that is to be followed for a particular project. The justification document for the process contains all the modifications, who made them, when they were made and the reason for the change. This file can be viewed by any user at any time. Process models in GPM are defined hierarchically through the use of phases, reflecting the fact that a process consists of a series of levels. In GPM, it is possible to look inside a phase to see the elements that it contains, thus allowing activities in lower levels of the process hierarchy to be defined. An example of activities that can occur in the planning phase of the waterfall model is shown in Figure 4. Processes that do not conform to the defined process framework, which sets out rules which each process must abide by, are flagged as incomplete and may not be followed until they conform to the framework. The process framework is designed to assist in the production of quality software processes and is defined as part of GPM. This allows a process to be developed over a period of time. Storing process definitions allows previous models to be used as the basis for the construction of new process models. GPM supports the dynamic modification of process definitions. This allows process instance to evolve throughout the lifetime of the project. This is especially important for projects of long duration. When a process definition is modified whilst it is being executed, the changes made to the process must still conform to the defined process framework. When the modifications are complete and the process conforms to the process framework, process execution is permitted to continue. Storing project information permits management to inspect a process model and identify where it was successful and where it failed for a particular style of project. This provides assistance when trying to choose a suitable Figure 4 – Planning Phase of the Waterfall Model.
process model for a new project by allowing the past process history of an organisation to be viewed and a decision to be made based upon that past history. It also allows different members of a project team, as well as management, no matter where they are located in the world, to gain access the latest project information. Once a process model is defined for use on a particular project it is important that the project is implemented following the defined process model. This is the role of the project tracking component. GPM provides a number of mechanisms designed to assist with project tracking and execution. Project tracking involves monitoring a project while it is being implemented and gathering information about it. This information includes: duration of activities, the deliverables that are produced, number and location of defects found and removed, size of the product, whether estimations were met, and expected completion dates. There are many reasons why a project should be tracked as it is implemented. One reason is to ensure that a project is implemented correctly. This includes ensuring that the defined process model is followed and that no activities in the process model are omitted. Tracking is also concerned with making sure that information about the project and process that could benefit a future project is collected and stored. Tracking provides a control mechanism for a project. An important point to note is that this data must be entered manually by the users and there is little GPM can do to ensure correct project data is entered other than only allowing authorised users to enter project information. GPM assists with the execution and tracking of a software process in a number of different ways. Specific project information, including start and completion dates for an activity, needs to be entered into GPM. This information is then used to assist in the execution of the software process. GPM requires certain project information to be entered before execution of the process elements. Who assumes responsibility for a process element and the amount of time it is expected to take must be entered before the process element is executed. If all this information is entered before the project commences it can be used as the basis for project planning. GPM explicitly displays the current phases and/or activities to the user. This clearly defines which part of the process is currently being executed and what has been completed thus ensuring that no parts of the development process are missed through human oversight. GPM allows certain project information about a phase or activity to be entered only if it is currently being executed. An example of this information is the actual duration for an process element. This provides a mechanism of control over
a software project by only allowing the project activities to occur in the order specified by the process model. Information used to calculate some standard project metrics can be obtained from the project information that is entered into GPM during process execution. GPM assists in the collection of metrics by not permitting a phase or activity to be completed unless all of the relevant project information has been entered about the process element. This ensures that specific information will always be recorded, but it is management’s responsibility to ensure that the given project information is sensible and of a high quality. GPM has no way of ensuring that a defined process is a quality process or if the project information entered is useful. GPM calculates a collection of process metrics that can be used to evaluate the effectiveness of a process. Process metrics quantify attributes of the development process and of the development environment [17]. GPM calculates Defect Identification, Phase or Module Completion Over Time [18], Resource Estimates and Process Duration metrics. Defect identification metrics are concerned with the number of defects that are found, where they are found, where they are introduced, how they are found and how long they take to rectify. GPM calculates the number of defects found in a project from information collected during project tracking. For each defect found during project execution, the user is required to enter where and how it was found and which phase it was introduced in. This information is similar to that gathered manually via systems such as the Personal Software Process [19]. From this information, GPM calculates the number of defects introduced into the process, and the number found in each phase. This information is used to calculate the percentage of defects found or introduced in each phase. Process duration metrics are concerned with the amount of time spent working on the project. These metrics are calculated from information that includes the start and completion dates, as well as the actual duration information collected during project execution. For each phase the total calendar time and the actual time spent in the phase is calculated. This information and the expected duration of the phase, is used to calculate the estimation accuracy for the phase duration. This information is also calculated for the entire process. GPM also calculates the rate of phase completion over time. During the execution of a process, phases may be executed more than once when cycles are allowed, or when the process is constructed to allow backtracking. GPM records the number of times a phase is executed. Each time a phase is re-executed, a reason, the actual duration, the
Figure 5 – The Spiral Model. calendar time and the start date is recorded. This information is recorded to highlight the parts of the process that are not completed properly or fully the first time and can indicate possible deficiencies in the process. The final metric collected is concerned with the resources available to a project. For each activity, or document, in a process definition the amount of resources available for the execution of the process element must be entered. From this information GPM calculates the resources that are devoted to each phase and to the entire project. This information and the expected duration of each process element is used to calculate the expected calendar time for each phase and the entire project. This information can be used for project planning and may be entered before the project commences. It can be updated easily during project execution.
4. EVALUATION AND FUTURE WORK GPM’s process notation allows the definition of standard process models such as the Waterfall Model and the Spiral model (Figure 5). The small number of process elements available for use in a process definition assists user understanding. Although only a small number of process elements exist, it is still possible to construct a process definition, such as the Waterfall model, without the definition becoming overly cluttered. It is not yet
possible in GPM to add additional attributes to a process element or to customise process elements. This is a valuable feature in a process modelling tool, allowing process definitions to be customised to the style used by an organisation. GPM collects and calculates some basic process metrics. Although these metrics are simplistic, they are representative of process metrics used by industry. The metrics that GPM calculates allow a process to be measured before, during and after a process is executed. The current version of GPM employs a metrics system that is not customisable so an organisation cannot add new metrics to the ones that are calculated. One advantage of the metrics system is that most metrics information is not susceptible to tampering by users. The majority of the information is automatically calculated by GPM and is automatically saved to the database. This helps to ensure quality metrics information is collected during process execution. Some information, such as the actual duration of an activity, needs to be entered by authorised users. This means that management needs to ensure that the tool is being correctly used. GPM records which user inserts project information and when, so questionable metrics information can be traced back to the offending user.
The project tracking component of GPM does not allow process elements to be processed out of the order in which they appear in the process definition. In this manner, GPM helps to ensure that no parts of the process are missed during execution and that the process is not completed until all the parts have been finished. However, GPM does not have any real control over the process execution. This is because project documents and deliverables are not yet integrated with GPM due to a security restriction imposed by Java. GPM is implemented as a Java applet [20] and so is not permitted to execute any commands on a users system [21]. This makes it impossible to start a text editor running. Solving this problem is a future extension of GPM. Process execution is assisted by permitting all users to view the process, including what is currently being executed. GPM also allows any user to view who is responsible for a certain aspect of the process at any time. This allows all members of the project team and management to see the current state of the process at any time. Project management is assisted by allowing all information about process definitions and metrics information to be readily accessible to management in an easily understandable manner. Improved project planning is facilitated through the storage of information from previous projects and allowing this to be viewed at any time. This permits planning decisions to be made on past organisational history. Forcing the user to provide a reason for all changes that are made to a process definition may be regarded as a nuisance by some users and also suffers from the problem of increasing the time that it takes to define a process. Although this is a problem, storing this information is very important to prevent the reasoning behind the process from being lost as the designer moves on to other projects. Storing this information also provides management with an audit trail making it possible to determine who made what change, when and why. Another problem which exists is that GPM has no way of determining if the information provided by a user is quality information. This is a problem that management needs to address through other means. GPM stores the name of the user submitted during the authentication process so it is possible to determine who the offending person is. GPM allows dynamic modification of a process definition. This is a very valuable feature as process definitions are dynamic in nature and may change throughout the lifetime of a project. GPM monitors these changes by recording the reasons for the change. After a change is made to a process instance the process cannot be followed until it conforms to the defined process
framework once again. This helps to ensure that the process definition remains a quality one. Another good feature of GPM’s process definitions is that they are easy to understand by all users. This includes the process designers, the software engineers, the quality department and even management. The defined process framework assists in ensuring that quality process definitions are created. The process framework is not currently customisable making it impossible for an organisation to specialise the process rules to incorporate their specific policies. Storing the process definitions allows past process models to be examined and evaluated. This can be valuable when a process model is being chosen for use on a project because a successful process can be chosen. GPM does not allow any process definitions to be removed from the database so the entire history of an organisation from when GPM was first introduced is available providing a complete picture. Storing the process definitions allows past process models to be used as the basis for any new process, significantly reducing the time involved in developing a new process. Using the WWW to access GPM is an advantage for a process management tool. It provides good platform independent access to project information for distributed project teams no matter where they are located in the world. Access to this information may be slow over large distances but this time lag is an improvement on no access to current information as may be the case with distributed project teams normally. Security is an important factor which needs to be taken into consideration. GPM provides secure access to project information by authenticating users before granting access. Process definitions in GPM are protected by only allowing authorised users to modify the definitions and enter the project information. Possible extensions to GPM include integration with other tools designed to assist with the engineering of quality software, introducing a simulation mechanism that allows a project to be “executed” to test resource usage etc., and to develop a more extensive metrics gathering mechanism which has the ability to develop an organisational profile across multiple projects and allow GPM to become customisable to an organisations requirements. Organisations such as Motorola have a specific process which is tailored for each project. GPM provides good support for this allowing each new process to be based on the organisational process model.
5. CONCLUSIONS Following a software process when building a software product has been proven to improve the quality of the
software but it is important that this process is managed in a responsible manner. Any process defined using GPM should not be blindly followed, but rather it should be used in a responsible manner that includes making sensible decisions about the process and where it should be improved. At the time of writing, GPM was still under evaluation. Preliminary results indicate that GPM is a valuable organisational tool and it is about to be deployed with an organisational partner. GPM currently provides a mechanism for a software process model to be defined, modified, followed and measured. When the process is followed, project information needs to be provided to GPM. There are a number of benefits that Java has to offer to a process management tool such as GPM. Java is architecturally neutral, so GPM can operate on many different hardware platforms. The only requirement is that a Java aware WWW browser is available for that architecture. This provides access to project management information in a transparent platform-independent manner to geographically distributed programming teams and project managers whilst maintaining a high level of security. Java provides extensive tools for building GUI’s allowing GPM to be designed in a user friendly manner. It also provides good support for graphics, enabling a software process model to be pictorially displayed on the screen for the user. This also allows easy modification of process models making GPM responsive to the needs to individual organisations.
6. REFERENCES [1]
[2] [3]
[4]
[5]
[6] [7]
N.G.Leveson, High-Pressure Steam Engines and Computer Software, International Conference on Software Engineering, May 1992, pp. 2 – 14. W.S.Humphrey, Managing The Software Process, Addison-Wesley, 1990. Software Engineering Institute, Technical Report 005 – Software Capability Evaluation V2.0: Implementation Guide, CMU/SEI-94-TR-05, CMM Appraisal Project, 1994. Software Engineering Institute, Technical Report 006 – Software Capability Evaluation, Version 2.0, CMU/SEI94-TR-05, CMM Appraisal Project, 1994. R.S.Pressman, Software Engineering – A Practitioner’s Approach, 3rd Ed., McGraw-Hill International Editions, 1992, pp. 22 – 33. S.R.Schach, Classical and Object-Oriented Software Engineering, 3rd Ed., Irwin, 1996, pp. 52 – 70. W.W.Royce, Managing the Development of Large Software Systems: Concepts and Techniques, 1970 WESCON Technical Papers, Western Electronic Show and Convention, Los Angeles, August 1970, pp. A/1-1 – A/1-9.
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16] [17]
[18]
[19] [20] [21]
B.W.Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, Vol. 21, No. 5, May 1988, pp. 61 – 72. H.Wohlwend, and S.Rosenbaum, Schlumberger’s Software Improvement Program, IEEE Transactions on Software Engineering, November 1994, Vol. 20, No. 11, pp. 833 – 839. I.Bhandari, M.Halliday, E.Tarver, D.Brown, J.Chaar and R.Chillarege, A Case Study of Software Process Improvement During Development, IEEE Transactions on Software Engineering, December 1993, Vol. 19, No. 12, pp. 1157 – 1170. P.Armenise, S.Bandinelli, C.Ghezzi and A.Morzenti, Software Process Representation Languages: Survey and Assessment, Proceedings of the 4th Conference on Software Engineering and Knowledge Engineering, 1992, pp. 455 – 462. S.M.Sutton Jr, P.L.Tarr, and L.J.Osterweil, An Analysis of Process Languages, Computer Science Technical Report 95–78, University of Massachusetts, August 1995. C.Fernstrom, PROCESS WEAVER: Adding Process Support to UNIX, Proceedings of the Second International Conference on the Software Process, 1993. S.M.Kaplan, W.J.Yolone, A.M.Carroll, D.P.Bogia and C.Bignoli, Supporting Collaborative Software Development with ConversationBuilder, Symposium on Software Development Environments, December 1992. J.Gosling and H.McGilton, The Java Language Environment: A White Paper, Sun Microsystems, http://java.sun.com/doc/language_environment/, May 1996. F.Yellin, Low Level Security in Java, Sun Microsystems, http://java.sun.com/sfaq/verifier.html, December 1995. S.D.Conte, H.E.Dunsmore, and U.Y.Shen, Software Engineering Metrics and Models, Benjamin/Cummings, 1986, pg. 19. S.L.Pfleeger and C.McGowan, Software Metrics in the Process Maturity Framework, Journal of Systems Software, Vol. 12, No. 3, July 1990, pp. 255 – 261. W.S.Humphrey, A Discipline For Software Engineering, Addison-Wesley, 1995. Sun Microsystems, Writing Applets, http://java.sun.com/books/Series/Tutorial/applet/, 1996. Sun Microsystems, Frequently Asked Questions – Applet Security, http://java.sun.com/sfaq/index.html, June, 1996.
