- Email: [email protected]
Concepts of an integrated project support environment
Conceptsof an Integrated ProjectSupportEnvironment How a companyis approachingthe task of building a systemdevelopmentenvironmentfrom scratch by M M LEHMAN
T
and N V STENNING
a general introduction
to work on integrated project supnort environments (IPSEs) at Impeiial Software Technology (IST) in the UK. The two central sections summarize, respectively, the philosophical background to the work and the approach that IST has adopted for its current env~o~ent developments. The concluding section then outlines the benefits of this approach and our expectations for future environments . his is
Background Anyone involved with the use of computers is acutely aware of the problems that arise in first finding satisfactory software for an intended application and then in maintaining cost-effective usage in a changing operational environment. This applies Abstract: The need for an antedated approach to systemdevelo~m~t and maintenance has been apparent for sometime, and has been discussed in a series of conferences on software engineering. Although the phrase Integrated Prqlect Support Environment JIPSE) is new, the concept is not. A UK company is developing such an enviro~~t, to be available crucially in early I!%%. Keywords: data processing, system development, PSE, project management. M M Lehman and N V Stenning are associated with Imperial Software Technology Ltd through the Department of Computing at Imperial College of Science and Technology.
8
0011-684x/85/030008-03$03.00
0
whether the application is considered as DP, scientific, real-time, embedded or anything else. The problems encountered include incorrect or inadequate function, late delivery, delayed response to environmental change, high costs, unreliable operation and, in general, a need for continu~g and costly attention to keep the product operating effectively. These problems have been a focus for detailed discussion for many years now. The NATO Garmisch conference’ in 1968 was entirely dedicated to such issues. It was there that the term ‘software engineering’ was first publicly used to identify a discipline that might be developed to address and solve them. Later meetings were devoted to discussions of the high cost of software and to software reliabilityzm4.They in turn, were followed by a series of major international meetings on software engineering5 held at l&month intervals. The next will be in London, at Imperial College, from 27 to 29 August 1985*. As a consequence of the resultant interest and of the ever greater and more apparent need, much progress has been made. It is now widely recognized that the problems faced in program specification, design, development and maintenance are, to a large extent, a consequence of the “Further information from Joanne Sutcliffe, ICSES organizing secretary, IEE, Savoy Place, London WCZ, UK. Tel: 01-240 1871.
1985 Butterworth &Co (Publishers) Ltd.
nature of computer application and of software; not primarily due to lack of experience or foresight on the part of the people involved. These problems are therefore amenable to study and systematic solution. In the absence of calculi that define the direct transformation of a specification into an executable program, the iterative nature of program development and validation is inevitable, even when the application, its operational environment and solution methods are well understood. The need for c~ti~uing ~int~a~e arises from the fact that any program is, itself, a part of the application it supports. That is, program execution interacts with a total operational environment, changing both that environment and human perception of that environment. The whole complex forms a cIosed-loop system whose internal feedbacks generate the pressure for change. In addition, external and environmental changes gradually produce a mismatch between system properties (such as functionality) on the one hand and the needs, expectations and ambitions of people in the operational environment on the other. Taken together, all these lead to a demand for continuing system evolution: adaptation of the total system, largely by modification of the software, to the operational environment and human perception of that environment, its needs and op~rtunities45*. As a broad concept and disciplinary goal, software engineering has e.xisted for more than 15 years. Many specific notions (e.g. requirements analysis, specification, correctness, verification, formal methods and transformation) and also methods for applying
data processing
them, have been developed, refined and extended. These provide primitives for the proposed engineering discipline. Systems such as the Programmer’s ~ork~~ck7, CAL@??, the St~~an APSE9 have sought to combine methods and tools; implementing these and other notions in a single system, a tool kit, that provides facilities to support an individual programmer or a programming team in their pursuit of some part of the programming process. Most recently, in part perhaps, as a result of various national and international IT initiatives (Alvey in the UK, Esprit in the EEC, Stars in the USA, for example), the phrase Integrated ProjectSupport Environment (IPSE) has become popular. The concept is not new, even with regard to integration. A very early reference” already recognized that such tool kits must be fully integrated with regard to the various steps of the programming process and support both programing and management roles. They must provide comprehensive support for the development and subsequent evolution of software-dependent products over their entire lifetime; not just for the initial development of the software components. The intent of the adjective ‘integrated’ and its implications are, however, not always appreciated. Currently related available progralnming methods and their support tools have, in general, been individually conceived and constructed. They are thus conceptually and physically not homogeneous; they do not possess methodological unity or directly compatible interfaces. Any attempt to link them into a single system, an environment, demands serious modification to provide common interfaces. Moreover, no amount of reworking can provide conceptual unity or procedural coherence. It is, therefore, difficult to justify the term ‘integration’ when it is applied to environments constructed by the ad hoc association of independently-developed methods
~0127no 3 april1985
and tools, merely because the func- Process model tional components have been enabled I) uring this stage, concern was with to communicate with one another. the development of an overall generic Purposeful integration, to provide model of the technical development procedural harmony and coherence, process. This resulting model reflects cannot be achieved by relying on a particular approach to development, system building through functional and encourages basic discipline and and interface matching. Nor does this h ygiene, but is generic in that it can basis for integration augur well for accommodate a variety of specific enhancement and enrichment (evolu- methods and languages. A primary tion) of the support environment or of input to this work was provided by target systems produced using it. To considerations of an ‘ideal’ approach achieve a set of Programming suPPort to software development’ l. The resultools that can be used in harmony ting process model encompasses this over the full evolutional developideal approach, but is considerably ment process6 requires them to be less prescriptive. A fundamental based on a common theory and to characteristic of both the ideal have been developed within a unified approach and the process model is conceptual framework. Moreover, the that software development is viewed methods and tools must be compreas the repeated application of a single hensive, addressing and supporting canonical step. both technical and managerial aspects Project model of a coherent process and including The process model, while generic, is mechanisms for acquisition, retention and retrieval of process and productconcerned only with the technical related information, all in a unified aspects of software development. manner. Only the development of a However, as mentioned earlier, other software development and evolution aspects of the software development process are equally important, and it process supported by an environment integrated in this sense will permit is essential that all aspects are treated mankind to cope with the ever in- within the unified conceptual framecreasing societal dependence on the work. The project model developcontinuous availability and correct ment activity, therefore, to& the operation of computer controlled SYS- process mode1 as input and produced terns. a broader model covering the technical, managerial and information manApproach agement aspects of a software deveThe previous section gave an outline lopment project. of a general philosophy regarding Unification is achieved by relating IPSEs and their development. It was all three aspects to the canonical step emphasized that realisation of in& of the process model. grated environments, in the fullest sense of the term, is dependent upon a Methods The project model, like the process common theory and a unified conceptual framework for all aspects of the model, is generic with respect to the methods and languages that can be software development process. employed. However, in order to proIn keeping with this philosophy, environment work at IST has been gress the work towards implement-adriven more by a concern with the tion it was necessary to give detailed process as a whole than by consideraconsideration to a few specific tion of any particular methods, lan- methods or method classes. This actiguages or tools. Specifically, the work vity therefore investigated a range of methods, both current and projected, has proceeded through five distinct and considered the strengths and stages, as follows.
9
weaknesses of these in the context of the project model. Three of the methods were then selected for support by the initial IPSE implementation. The selection reflected the chosen application area for that initial implementation: real-time systems in generai and teleco~~ications systems in particular. However, investigation at this stage confirmed our belief that the project model, and hence the IPSE, is suitable for use in a wide range of application areas, including conventional dara processing. Data model The next stage was to define the data model of a project conforming lo the project model and employing the Selected methods. This data model covers all the rypes of information tit are of i5tcmt te bt praicct (prolpams, doC=nw phns, m grcss rqons, etc.), the relationship8
between items of information and modes of access to informatb. Tlx data model has a skeleton which is dependent only on rhe proiect model, and within that skeleton has more detailed areas that reflect individual methods. The latter would change as the methods that are supported change, but the skeleton would rcmain the same. Environment
architecture and tools
Finally, on the basis of all previous work, an actual environment architecture and tool-set was defined, and implementation commenced. The resulting IPSE will bz released as a commercial product during the spring of 1986.
Advantages The strength of the IPSE discussed above derives immediately from the underlying philosophy and the approach that was adopted in its design. In particular, integration comes from the use of a common theory and a unified model for technical development, project management and information management. As a result, software projects can be
10
Record ofthe I973 SymP. on CO@). properly phmned and controlled, and Sofnoare Reliabili~. IEEE Comp. there is a sound basis for achieving Sot. IEEE Cat. No. 73ch-0741-9c completion on time and within bud(1973) get. The information management Proceedi~ of the Int~a~onal facilities ensure that system documenConference on Reliable Sofnoare, tation is up-to-date and correct. This, IEEE Comp. Sot. IEEE Cat. No. together with support for improved 75ch-0940-7csr (1975) system s~uctur~g, ensures the target Proceedings of the seven Internasystem can be changed more easily, tional Conferences on Software more cheaply and more responsively Engineering held so far were pubwhen the need arises. The benefits lished by the IEEE. should be visible both to users of the Lehman, M M ‘Program EvoluIPSE and to users of systems protion’ ICST Res. Rep. 82:‘l. Also in duced using the IPSE. J. Info. I’m. and ;UanuPemenf Future developments will be of IWO Georga fnsr. of Tech. vol 9: no 1 types. On the one hand, the pro(Nov. 1982) pp. 19-36. Also in”. gramming process will be more completely supported. In particular, tool 7 Dolotta, D A and Masbey, J R support for methods suited to other ‘An introduction to the Programapplication atvas will b6 tit&uced. mer’s Workbench’ l’roc. 2nd Inr. Further, v otpport will be Con5 on Software Eng. San Franppvi&iforv&ca?iCmandvaiidacisco, CA, USA (Oct. 1976) IEEE t.ion throughout the development proCat. 76ch-1125~4c, pp 164-168. ceau. On the other hand, we would 8 Hutchings, A F, McCufb, R W, tlrgect to introduce gmduaily more Elliston, A E, Trauter, B R and odrpnccd methods and use of newer Westmacott, P N ‘CADES-Softsoftware engineering technologies. ware Engineering in Practice’ For example, formal verification Proc. 4th Inc. Conf. on Software based on mechanical theorem proving Eng., IEEE Cat. No. 79ch-1479could make a major contribution 10 SC, (Sept. 1979: pp 136-152 the achievement of correct programs. 9 Buxton, J N and Stenning, V IKBS techniques offer the possibility Requirements for an Adu l’rogramof database support that is active ming Support EnzGonmenr rather than passive, alerting the proStoneman’ US L)oD, Washington grammer to inconsistencies, redunDC {Feb. 1980; dancies, items that have bcyn over- 10 Lehman, M M ‘The Programlooked, and so on. Such features, ming Process’, IBM Research Rewhen incorporated, will improve the port RC2722, IBM Research Div., process still further, resulting in faster Yorktown Heights, NY 10549, and cheaper production of more reliUSA (Dec. lW9: able and more adaptable end user 11 Lehman, M M, Stenning, V and systems. Turski, W M ‘Another Ltwk at Software Design Methodology’ References KST DOC Res., 83113, London, UK (June 1983) Also in Softw. Naur, P and Randell, B SC& Eng. Notes vol 9, no 2, (April. ware Engineering Report on a con1984) pp. 38-53 ference sponsored by the NATO Science Committee, NATO Sci. 12 Lehman, M M, Program Evolution - Phenomenon and Dynamics, Comm., Brussels (Jan. 1969) to be published by Academic Goldberg, J, (ed) ‘High Cost of Press Ltd, London, UK (Summer Software’, Proc. of a Symposium, 1985) nNaval Postgraduate School (Sept. 17-19 1973) SR7, Menlo Park, IST Ltd, 60 Albert Court, Prince Consort Rd, London SW7 ZBH, UK. 94025
data
processing
T
and N V STENNING
a general introduction
to work on integrated project supnort environments (IPSEs) at Impeiial Software Technology (IST) in the UK. The two central sections summarize, respectively, the philosophical background to the work and the approach that IST has adopted for its current env~o~ent developments. The concluding section then outlines the benefits of this approach and our expectations for future environments . his is
Background Anyone involved with the use of computers is acutely aware of the problems that arise in first finding satisfactory software for an intended application and then in maintaining cost-effective usage in a changing operational environment. This applies Abstract: The need for an antedated approach to systemdevelo~m~t and maintenance has been apparent for sometime, and has been discussed in a series of conferences on software engineering. Although the phrase Integrated Prqlect Support Environment JIPSE) is new, the concept is not. A UK company is developing such an enviro~~t, to be available crucially in early I!%%. Keywords: data processing, system development, PSE, project management. M M Lehman and N V Stenning are associated with Imperial Software Technology Ltd through the Department of Computing at Imperial College of Science and Technology.
8
0011-684x/85/030008-03$03.00
0
whether the application is considered as DP, scientific, real-time, embedded or anything else. The problems encountered include incorrect or inadequate function, late delivery, delayed response to environmental change, high costs, unreliable operation and, in general, a need for continu~g and costly attention to keep the product operating effectively. These problems have been a focus for detailed discussion for many years now. The NATO Garmisch conference’ in 1968 was entirely dedicated to such issues. It was there that the term ‘software engineering’ was first publicly used to identify a discipline that might be developed to address and solve them. Later meetings were devoted to discussions of the high cost of software and to software reliabilityzm4.They in turn, were followed by a series of major international meetings on software engineering5 held at l&month intervals. The next will be in London, at Imperial College, from 27 to 29 August 1985*. As a consequence of the resultant interest and of the ever greater and more apparent need, much progress has been made. It is now widely recognized that the problems faced in program specification, design, development and maintenance are, to a large extent, a consequence of the “Further information from Joanne Sutcliffe, ICSES organizing secretary, IEE, Savoy Place, London WCZ, UK. Tel: 01-240 1871.
1985 Butterworth &Co (Publishers) Ltd.
nature of computer application and of software; not primarily due to lack of experience or foresight on the part of the people involved. These problems are therefore amenable to study and systematic solution. In the absence of calculi that define the direct transformation of a specification into an executable program, the iterative nature of program development and validation is inevitable, even when the application, its operational environment and solution methods are well understood. The need for c~ti~uing ~int~a~e arises from the fact that any program is, itself, a part of the application it supports. That is, program execution interacts with a total operational environment, changing both that environment and human perception of that environment. The whole complex forms a cIosed-loop system whose internal feedbacks generate the pressure for change. In addition, external and environmental changes gradually produce a mismatch between system properties (such as functionality) on the one hand and the needs, expectations and ambitions of people in the operational environment on the other. Taken together, all these lead to a demand for continuing system evolution: adaptation of the total system, largely by modification of the software, to the operational environment and human perception of that environment, its needs and op~rtunities45*. As a broad concept and disciplinary goal, software engineering has e.xisted for more than 15 years. Many specific notions (e.g. requirements analysis, specification, correctness, verification, formal methods and transformation) and also methods for applying
data processing
them, have been developed, refined and extended. These provide primitives for the proposed engineering discipline. Systems such as the Programmer’s ~ork~~ck7, CAL@??, the St~~an APSE9 have sought to combine methods and tools; implementing these and other notions in a single system, a tool kit, that provides facilities to support an individual programmer or a programming team in their pursuit of some part of the programming process. Most recently, in part perhaps, as a result of various national and international IT initiatives (Alvey in the UK, Esprit in the EEC, Stars in the USA, for example), the phrase Integrated ProjectSupport Environment (IPSE) has become popular. The concept is not new, even with regard to integration. A very early reference” already recognized that such tool kits must be fully integrated with regard to the various steps of the programming process and support both programing and management roles. They must provide comprehensive support for the development and subsequent evolution of software-dependent products over their entire lifetime; not just for the initial development of the software components. The intent of the adjective ‘integrated’ and its implications are, however, not always appreciated. Currently related available progralnming methods and their support tools have, in general, been individually conceived and constructed. They are thus conceptually and physically not homogeneous; they do not possess methodological unity or directly compatible interfaces. Any attempt to link them into a single system, an environment, demands serious modification to provide common interfaces. Moreover, no amount of reworking can provide conceptual unity or procedural coherence. It is, therefore, difficult to justify the term ‘integration’ when it is applied to environments constructed by the ad hoc association of independently-developed methods
~0127no 3 april1985
and tools, merely because the func- Process model tional components have been enabled I) uring this stage, concern was with to communicate with one another. the development of an overall generic Purposeful integration, to provide model of the technical development procedural harmony and coherence, process. This resulting model reflects cannot be achieved by relying on a particular approach to development, system building through functional and encourages basic discipline and and interface matching. Nor does this h ygiene, but is generic in that it can basis for integration augur well for accommodate a variety of specific enhancement and enrichment (evolu- methods and languages. A primary tion) of the support environment or of input to this work was provided by target systems produced using it. To considerations of an ‘ideal’ approach achieve a set of Programming suPPort to software development’ l. The resultools that can be used in harmony ting process model encompasses this over the full evolutional developideal approach, but is considerably ment process6 requires them to be less prescriptive. A fundamental based on a common theory and to characteristic of both the ideal have been developed within a unified approach and the process model is conceptual framework. Moreover, the that software development is viewed methods and tools must be compreas the repeated application of a single hensive, addressing and supporting canonical step. both technical and managerial aspects Project model of a coherent process and including The process model, while generic, is mechanisms for acquisition, retention and retrieval of process and productconcerned only with the technical related information, all in a unified aspects of software development. manner. Only the development of a However, as mentioned earlier, other software development and evolution aspects of the software development process are equally important, and it process supported by an environment integrated in this sense will permit is essential that all aspects are treated mankind to cope with the ever in- within the unified conceptual framecreasing societal dependence on the work. The project model developcontinuous availability and correct ment activity, therefore, to& the operation of computer controlled SYS- process mode1 as input and produced terns. a broader model covering the technical, managerial and information manApproach agement aspects of a software deveThe previous section gave an outline lopment project. of a general philosophy regarding Unification is achieved by relating IPSEs and their development. It was all three aspects to the canonical step emphasized that realisation of in& of the process model. grated environments, in the fullest sense of the term, is dependent upon a Methods The project model, like the process common theory and a unified conceptual framework for all aspects of the model, is generic with respect to the methods and languages that can be software development process. employed. However, in order to proIn keeping with this philosophy, environment work at IST has been gress the work towards implement-adriven more by a concern with the tion it was necessary to give detailed process as a whole than by consideraconsideration to a few specific tion of any particular methods, lan- methods or method classes. This actiguages or tools. Specifically, the work vity therefore investigated a range of methods, both current and projected, has proceeded through five distinct and considered the strengths and stages, as follows.
9
weaknesses of these in the context of the project model. Three of the methods were then selected for support by the initial IPSE implementation. The selection reflected the chosen application area for that initial implementation: real-time systems in generai and teleco~~ications systems in particular. However, investigation at this stage confirmed our belief that the project model, and hence the IPSE, is suitable for use in a wide range of application areas, including conventional dara processing. Data model The next stage was to define the data model of a project conforming lo the project model and employing the Selected methods. This data model covers all the rypes of information tit are of i5tcmt te bt praicct (prolpams, doC=nw phns, m grcss rqons, etc.), the relationship8
between items of information and modes of access to informatb. Tlx data model has a skeleton which is dependent only on rhe proiect model, and within that skeleton has more detailed areas that reflect individual methods. The latter would change as the methods that are supported change, but the skeleton would rcmain the same. Environment
architecture and tools
Finally, on the basis of all previous work, an actual environment architecture and tool-set was defined, and implementation commenced. The resulting IPSE will bz released as a commercial product during the spring of 1986.
Advantages The strength of the IPSE discussed above derives immediately from the underlying philosophy and the approach that was adopted in its design. In particular, integration comes from the use of a common theory and a unified model for technical development, project management and information management. As a result, software projects can be
10
Record ofthe I973 SymP. on CO@). properly phmned and controlled, and Sofnoare Reliabili~. IEEE Comp. there is a sound basis for achieving Sot. IEEE Cat. No. 73ch-0741-9c completion on time and within bud(1973) get. The information management Proceedi~ of the Int~a~onal facilities ensure that system documenConference on Reliable Sofnoare, tation is up-to-date and correct. This, IEEE Comp. Sot. IEEE Cat. No. together with support for improved 75ch-0940-7csr (1975) system s~uctur~g, ensures the target Proceedings of the seven Internasystem can be changed more easily, tional Conferences on Software more cheaply and more responsively Engineering held so far were pubwhen the need arises. The benefits lished by the IEEE. should be visible both to users of the Lehman, M M ‘Program EvoluIPSE and to users of systems protion’ ICST Res. Rep. 82:‘l. Also in duced using the IPSE. J. Info. I’m. and ;UanuPemenf Future developments will be of IWO Georga fnsr. of Tech. vol 9: no 1 types. On the one hand, the pro(Nov. 1982) pp. 19-36. Also in”. gramming process will be more completely supported. In particular, tool 7 Dolotta, D A and Masbey, J R support for methods suited to other ‘An introduction to the Programapplication atvas will b6 tit&uced. mer’s Workbench’ l’roc. 2nd Inr. Further, v otpport will be Con5 on Software Eng. San Franppvi&iforv&ca?iCmandvaiidacisco, CA, USA (Oct. 1976) IEEE t.ion throughout the development proCat. 76ch-1125~4c, pp 164-168. ceau. On the other hand, we would 8 Hutchings, A F, McCufb, R W, tlrgect to introduce gmduaily more Elliston, A E, Trauter, B R and odrpnccd methods and use of newer Westmacott, P N ‘CADES-Softsoftware engineering technologies. ware Engineering in Practice’ For example, formal verification Proc. 4th Inc. Conf. on Software based on mechanical theorem proving Eng., IEEE Cat. No. 79ch-1479could make a major contribution 10 SC, (Sept. 1979: pp 136-152 the achievement of correct programs. 9 Buxton, J N and Stenning, V IKBS techniques offer the possibility Requirements for an Adu l’rogramof database support that is active ming Support EnzGonmenr rather than passive, alerting the proStoneman’ US L)oD, Washington grammer to inconsistencies, redunDC {Feb. 1980; dancies, items that have bcyn over- 10 Lehman, M M ‘The Programlooked, and so on. Such features, ming Process’, IBM Research Rewhen incorporated, will improve the port RC2722, IBM Research Div., process still further, resulting in faster Yorktown Heights, NY 10549, and cheaper production of more reliUSA (Dec. lW9: able and more adaptable end user 11 Lehman, M M, Stenning, V and systems. Turski, W M ‘Another Ltwk at Software Design Methodology’ References KST DOC Res., 83113, London, UK (June 1983) Also in Softw. Naur, P and Randell, B SC& Eng. Notes vol 9, no 2, (April. ware Engineering Report on a con1984) pp. 38-53 ference sponsored by the NATO Science Committee, NATO Sci. 12 Lehman, M M, Program Evolution - Phenomenon and Dynamics, Comm., Brussels (Jan. 1969) to be published by Academic Goldberg, J, (ed) ‘High Cost of Press Ltd, London, UK (Summer Software’, Proc. of a Symposium, 1985) nNaval Postgraduate School (Sept. 17-19 1973) SR7, Menlo Park, IST Ltd, 60 Albert Court, Prince Consort Rd, London SW7 ZBH, UK. 94025
data
processing