------------------------------------------------------------------------------- 7th International Software Process Workshop Yountville, California, October 25 1991 ------------------------------------------------------------------------------- Software Process Modeling Example Solution Creating ReadyToUse East-Environments Ian Simmonds, SFGL Ian.Simmonds@sfgl.fr ------------------------------------------------------------------------------- 1. Introduction The definition of the Software Process Modelling Example Problem for ISPW7 [SPMEP7] states that there may be many approaches for providing solutions for the problem. This paper analyses various approaches that might be taken for solving the problem, as suggested in the position papers [ISPW7] of the participants in ISPW7, before stating how East-Environment would be adapted to answer the needs of the problem. East-Environment is a process-centered environment which supports software processes primarily though the facilities of the East framework. This framework is data centered, and supports the uniform viewing, browsing, manipulation and querying of both product and process artifacts. The kernel of East-Environment, based upon PCTE, provides facilities that allow non-programmers and data administrators to create process specific functional extensions to the environment. It is expected that, given this basis, any process modelling formalisms used within East-Environment will be primarily Project Management Oriented. Project management tools deal with relatively `coarse grain' process issues and so can be integrated with a relatively `coarse grain' process modelling formalism. Relatively `fine grain' process issues are better supported by functional extensions forming part of the ReadyToUse environment. Due to an unhealthy workload at the time of addressing the problem, this paper merely hints at a solution to the Process Problem. Hopefully a more detailed solution will be presented at the ISPW7 problem class. 2 Community opinion of process support -------------------------------------- In order to be invited to the 7th International Software Process Workshop, all prospective participants were invited to state their position on Software Engineering Processes in the form of Position Papers[ISPW7]. The papers of those invited can be classified in the following way: Formalisms and Simulations: within these a process engine can be used to (at least) simulate a software process. The process engine is driven by process programs written in a process modelling formalism Project Management Oriented: these papers state that the prime interest of a defined software process is to guide project managers---any explicit definition of the software process is used primarily within project management tools. Moreover, there is no `best' process modelling formalism---indeed, there is even no real requirement to use a single process modelling formalism across a project Framework Process Support: these papers describe how a process-centered environment} can be built upon a software engineering environment framework}. Again, no particular process modelling formalism} is assumed since many aspects of the software process can be supported without} a process engine. Of further interest, the sources of these papers are from different groups of people: Formalisms and Simulations: the majority of these proposals come from Universities and the Research Labs of large Corporations Project Management Oriented: these statements come mostly from software engineering consultants. The papers practically speak with one voice, a voice consistent with the project management aims of East-Environment Framework Process Support: these come from those interested in the short to medium term deployment of software engineering environments into industry. 3 Role of Explicit Process Models within East-Environment --------------------------------------------------------- The intention of East-Environment is to provide generic facilities that can be used to support a variety of software processes. Of the three primary positions expressed in the Software Process Workshop listed in the previous section, East-Environment is focused towards a Project Management Orientation and a high level of Framework Process Support. Consequently, the role of defining explicit process models, when customisating East-Environment to support a particular organisation's software process, is primarily to support the project manager in managing projects. The customisation of East-Environment to support a particular organisation's software process is known in East as the provision of a ReadyToUse Environment. The specification of a process model to support project management tools is only one part of providing a ReadyToUse Environment, as we shall see in the following sections. 4 Rationale for a Common Repository ----------------------------------- East-Environment is a data centered environment. Many engineering processes can be directly supported by the data manipulation model of the underlying object management system---PCTE. East-Environment's data manipulation model (that of PCTE) was carefully designed to support software processes by satisfying the process oriented needs of both project managers and developers---it is expected that both project results and process related data are stored in the repository. While project managers are not forced to use project management facilities that store their data in the PCTE repository, there are significant advantages in doing so. Not only is all information within the repository subject to the same integrity protection as supported by the PCTE data manipulation model}, but: Traceability: PCTE can be used to maintain relationships not only within the otherwise separated project and product worlds, but also relationships spanning these two worlds Uniformity: East-Environment offers many facilities for browsing, viewing and querying the repository. When project and product data are both stored within the repository, such browsing, viewing and querying can span both worlds This degree of integration of the project and process worlds is only possible through the use of a common repository. Moreover, in such a world, it is hard to find a role for the kind of process engine proposed by many Universities and Research Labs---its apparent `role' is filled by the data manipulation model of the PCTE repository. 5 Functional extension: Data Models and Forms --------------------------------------------- The specification of a ReadyToUse environment includes the tailoring of predefined generic services by the specification of ReadyToUse models. One class of ReadyToUse model is used to guide project management in their use of project management tools---these are called process models. However, a significant proportion of the extensions made to East-Environment when customising the environment involves actually extending the functionality of the environment to support the client's software process. The forms interface of East is a generic facility that supports the development of new views of the repository by non-programmers. These forms can be compared to SQL forms in the relational world. However, there are several significant differences: they show actual data, not query results: a form really is an extension of the user interface of the environment. A new type of form acts as a new tool, making use of the facilities of the East User Interface Management System. they support the PCTE data manipulation model: not only does the form display actual data, but it acts as a tool supporting modifications of the repository new views can be associated with all object types: in particular, views can be defined for viewing and manipulating all types added to East-Environment within a ReadyToUse environment. These simple `tools' can be added to the environment by non-programmers. The last point is a result of the fact that the East repository---PCTE---does not have a single global data schema. The schema can be extended `piecewise' to added new functionality. The provision of a new schema `piece' and a set of new forms can be seen to functionally extend the environment. It is strongly recommended that the addition of schema `pieces' to the environment is controlled by someone with detailed knowledge of the principles of the PCTE data manipulation model, and the existing types within the environment. The second point ensures the maximum level of integration of newly added schema pieces with existing environment functionality, and maximum possible upwards compatibility with future functional extensions. 6 Examples of Process-Related Functional Extensions --------------------------------------------------- IN THIS VERSION OF THE DOCUMENT THIS SECTION IS INCOMPLETE. It merely lists the kind of functionality that can easily be added within a ReadyToUse East-Environment Possible functional extensions include: Software Problem Report: a form for describing software faults, with an underlying object type SPR. An SPR object would have attributes for the description of the problem, and links to the originator of the report (an object of type client or person) and the software version in which the fault was found Originator Problem Report List: a list to which all problem reports found by a team could be attached. This would allow the monitoring of all change requests that they sent Responsible's Problem Report List: a list used by Software Support Staff containing all outstanding Change Requests Problem Analysis Report: another Change Control Process related form Change Work Authorisation: etc... Review Proposal: an object type with attributes indicating the place and time of a review, with links to the document(s) to be reviewed, document(s) used as reference material for the review, people to be involved in the review, the author of the document (although this information is more likely to be attached to the document), the chairman of the review meeting. Links to the documents under review can guarantee that these documents cannot be altered (PCTE `stability') Review Results: another object type linked to the original review proposal In this way a ReadyToUse} environment can support the storage}, viewing} and manipulation} of many process artifacts} without the intervention of tool writers. These artifacts, being subject to the PCTE data manipulation model, can themselves implicitly support specific processes, without being under the control of a process engine. 7 Environment modularity ------------------------ The examples point towards schemes for change management, and other inter- and intra-team activities. With this level of support, an organisation may feel that it prefers to store project management data outside the East Repository (for example: on a PC using a commercial project management tool), while maintaining process artifacts within the East Repository. This allows a high degree of traceability between process related events (recorded as process artifacts), and produced results (product artifacts) while allowing the continued use of currently used project management tools and procedures. However, we suggest that there are considerable advantages from using a project management toolset that is fully integrated into the environment and actually stores its data in the repository. It is for this reason that we offer our own project management tools. Project management tools deal with relatively `coarse grain' process issues and so can be integrated with a relatively `coarse grain' process modelling formalism. Relatively `fine grain' process issues can be supported by functional extensions within the ReadyToUse environment. 8 References ------------ [SPMEP7] Software Process Modeling Example Problem M Kellner, P Feiler, A Finkelstein, T Katayama, L J Osterweil, M H Penedo, H D Rombach, 7th International Software Process Workshop Yountville, California, 16-18 October 1991 [ISPW7] Position Paper Preprints 7th International Software Process