- Email: [email protected]
The European Space Software Development Environment
Annual R+dew of Aukmatic Progmmming Vol. 16.pp.95-102.1992 printed in GreatBritaio.AUrightsresewed
0066-413&9ys15.00 Q 1992PcqamollR?dsLtd
THE EUROPEAN SPACE SOFTWARE DEVELOPMENT ENVIRONMENT J.-P. P&cigout* and J. Favarof *European Space Agenq, EsTEc/wME, P.O. Box 299,Keplerhm I, 2200AG Noomiwijk TheNetherlmds tlntecs Sister’S.p.A., Via Fmtti 14,56125 Piss, Italy
ABSTRACT With the rapidly increasing importance of software in space systems, it is essential that methods and tools are established to ensure reliable costeffective production of this software. The European Space Agency (ESA) has therefore started a program to establish an ESSDE (European Space Software Development Environment) which contains tools supporting the Agency methodologies and standards. The ESSDE shall provide a basic platform for the production and maintenance of software and is expected to be used in ESA projects to prepare onboard and ground future software. The establishment of the ESSDE has been entrusted to a working group consisting of interested parties from Columbus, Hermes and the ESA Technical Directorate, which initiated a project to investigate technically weak software engineering areas; to improve commonality between Columbus and Hermes SDEs; and to study technical areas potentially useful in the future.
KEYWORDS Software development environment, process modelling, software reuse, configuration management, testing, integrated project support environment
INTRODUCTION AND HISTORY OF THE PROJECT Nearly twenty-five years after the announcement of the "software crisis," the software industry has arrived at another crucial juncture. The so(IPSEs) that have been called "Integrated Project Support Environments" developed as a response to the software crisis have matured to the point where they are ready to be used in serious industrial software development. At the same time, the European Space Agency has experienced a steep rise in the amount of software required in its projects, leading it to make a commitment to introducing IPSE technology into its own software development the technology has not converged to a single Unfortunately, projects. standard and ESA was forced as early as 1989 to confront the danger of an incoherent set of approaches being introduced into the major areas of software production in the Agency. Going hand-in-hand with the choice of a coherent IPSE technology is the need for a coherent set of standards and procedures for software development within the Agency. In this area, the Agency had already done outstanding work with the creation and maintenance of the PSS family of standards, which have by now gained a reputation as a model for organisational software development standards. Nonetheless, an overall coordinating effort that satisfied the needs of Columbus, Hermes, Operations and the Technical Directorate was deemed necessary. The goal of this overall coordinating effort is the establishment of a single European
%
J.-P.
Mcigcut andJ.Favaro
Space Software Development Environment (ESSDE). An ESSDE Working Group was created with representatives from the major interested areas. This group developed a Software Requirement Document for a future ESSDE, but decided that, due to the limited resources of the working group, a full-fledged project was required to support the work of establishing a Reference Facility for the ESSDE. Reflecting its origins, this new project was financed in equal shares with funds from three areas (Columbus, Hermes and the Technical Directorate). Reflecting also the pervasive themes of harmonisation and consensus, the ESSDE Reference Facility Project was structured in some novel ways. Rather than immediately concentrate on the establishment of a reference facility, the organisers of the project chose to identify first several key areas in which either the Agency knew that it was technically weak (e.g. in relatively new areas such as reuse) or in which the Agency realised that it was critical to achieve a broad consensus on procedures and standards (e.g. for configuration management). The result was a total of twelve workpackages, each of which was designed to illuminate the best technical and procedural paths for the Agency to follow in the establishment of the ESSDE. Consensus was sought both within the Agency and within the industry serving Thus, the elaboration of these twelve workpackages was the Agency. entrusted neither to a single company nor a single department within the Agency. Instead, a two-phase structure was created for the project whereby in Phase 1 a designated Prime Contractor was to select a set of participating companies from a cross section of European space industry. Only after the formation of a suitable consortium of companies was the work to proceed in Phase 2. The resulting consortium consisted of five companies (Intecs Sistemi, 2i SynSpace, DNV, E2S and Rigel Engineering) from four nations (Italy, Switzerland, Norway, and Belgium). Thus, a representative presence in the project from the side of industry was obtained. In order to obtain a similarly broad-ranging presence from the side of the Agency, a system was set up for the provision of consultants from all major centers of activity in the Agency that had a special interest in the included representatives from various project. The list of consultants sections in the Technical Directorate (e.g. the ESA Quality Assurance section the Division); and ESA Contracts several space-related organisations in Toulouse including the Hermes Directorate; the European Space Operations Center (ESOC) in Darmstadt; and the prime contractors for the Hermes and Columbus software development environments. Two main consultants were initially associated with each work package; as the project progressed, other consultants were added. In retrospect, this system of consultants proved to be one of the major factors in the success of the project. It is doubtful that any kind of meaningful consensus could have been achieved without the advice - on both technical matters and procedural matters - of those most directly affected by the results of the project. With the selection of contractors and system of consultants in place, work began on Phase 2 in November of 1991. Although most activities were carried out according to plan and schedule, several "mid-course corrections" were made during the project. The most important of these occurred after about five months from project start, when ESTEC Software Engineering personnel decided to intensify the focus of the project on the production of a detailed "procedural roadmap" for software production at the Agency. At that point it became evident that future activities in the project would fall under the umbrella of @tprocess modelling," which has been the subject of much recent activity in the software engineering field. The project coordinators from ESTEC and Intecs Sistemi then attended the First European Workshop on Process Modelling and used the results of that workshop to redirect the work. Process modelling terminology was introduced, some subtasks were consolidated and renamed, and the development of an overall
EuropeanSpace Software
process model for software development remainder of the project.
91
at the Agency was undertaken
for the
Another change in the planned activities occurred during execution of the concerning reuse. A relatively workpackage minor investigation into organisational and contractual aspects of reuse resulted in two contacts, one within the NATO CIS Ada Support and Control Capability (NACISA) and one within the contracts department of the Agency, that provided an unexpected opportunity to treat the subject in considerably more detail than originally planned. The remaining activities of the workpackage were redirected to permit this unplanned effort to continue beyond the original schedule. and procedural issues, the Although the work treated both technical issues proved to be the most controversial procedural (perhaps not Some of the most intense discussions occurred among the surprisingly). consultants and contractors in areas in which a consistent terminology needed to be agreed, such as configuration management and testing. Other areas of controversy included operations and maintenance, where certain new concepts such as the "missionisation" concept of Hermes were not yet familiar to those outside Hermes. In some cases, the amount of controversy generated made it necessary to introduce new divisions between subtasks in order not to impede progress. For example, during the work on software classification, the main controversy centered around the classification procedure itself, and therefore a separation of concerns was introduced to allow work to continue on the identification of standards for software development within the different categories subsequent to classification, while discussion of the actual classification procedures continued in parallel.
MAIN RESULTS Although the work performed in the project covered a wide range of topics, it was possible to combine workpackages into groups that were investigated The main results achieved in each line of investigation are together. presented below.
L!?SE-Related
Technaloav
IPSE technology has now evolved to the point where it is no longer possible to study the technical environment in isolation from the entire lifecycle. For this reason, both technical and procedural issues were studied together in this work package. On the procedural side, such issues were studied as a consistent Agency-wide approach to configuration management; of an Agency-wide identification approach to the problem operations and maintenance; and most importantly, a first attempt to create for all software development at the Agency. On the technical
an overall
process
of
model
side, the main issues studied were
the state of the art in IPSE technology: the standardisation of interfaces within the ESSDE. The results of the various procedural studies were intended to form the background for a process-centered software development environment based upon the technical underpinnings identified in the technical studies.
J.-P. Frhigout and J. Favaro
98
ct Support Environment . Due to the newness of the IPSE technology and the variety of approaches now being proposed on the market, it was necessary to take a critical look at the state of the art from the point of view of the needs of the Agency. The approach to be taken by the Agency to the establishment of a single ESSDE must be compatible with the existing Software Requirements Document and the major Agency PSS standards. The major outputs of the tasks became new software requirements to add to the ESSDE Software Requirements Document. The recommended ESSDE approach defines an IPSE as an SDE supporting the development lifecycle, as well as administrative and whole software management tasks such as scheduling, resource allocation, task monitoring information must be managed by the IPSE. But the etc. All related fundamental requirement for an IPSE is its extensibility and its provisions for tool integration. We further required that the tool interfaces should be public, i.e. the IPSE should be open. An ideal IPSE should allow tool integration at three levels: data level, control level and presentation level. On top of lower level integration services, a process integration service allows customising the IPSE to a specific project policy. This support and enforce led to the identification of the main benefits of an IPSE as compared with a traditional SDE: Integration services on four levels (data, control, presentation and process) are available and standardised, Openness, vendor-independence and portability, Tool construction is less complex because the framework services can be reused, Process integration allows tailoring the SDE to the project's needs. We investigated the possible integration mechanisms for each integration type. We concluded that an IPSE providing both data integration by an object oriented repository and control integration services looks very promising. It has clear advantages as opposed to the other approaches. The only problem remaining is the limited experience that is available using such IPSE environments. The technology is new, especially the object oriented variant. . This often the longest phase of the software life cycle and also the most expensive, when one considers that software maintenance typically represents 60%-70% of the total software costs. A review of the normal activities of the development life cycle based on the ESA Software Engineering Standards (ESA PSS-OS-O) was performed in order to identify in which areas different methodologies or to improve the final product from the procedures may be introduced viewpoint, while trying to take into consideration the maintenance different types of maintenance.
Because of the intrinsic complexity of the "software maintainability" which is related to the fact that specifying, designing, concept implementing and verifying maintainable systems is a full lifecycle all the software development activities were considered and activity, suggestions were introduced to improve the maintainability of the final product. A particular
emphasis was put on the following topics:
a systematic approach to prevent defects during software development; specification and verification of maintainability related (user and software) requirements; the impact of the use of good techniques and practices during the Architectural and Detailed Design phases of the software life cycle:
EuropeanSpace Software
99
the importance of recording the information items underlying decisions taken during the development process; the importance of knowledge transfer between development maintenance organisations and/or teams.
the and
tion vt SuDoort . In the first part of this task, we developed a model for software configuration management that provides the necessary support for keeping control of very complex software systems. Since there was not enough consistent CM terminology available, several concepts were defined, but care was taken to remain in line with existing standards. As a result, we obtained a generic model for SCM customisable on many levels, for different policies. This model was called the "ESSDE generic SCM model." Project specific instantiations could be made of it through a Software Configuration Management Plan. In the same subtask, existing SCM approaches such as the Hermes and Columbus approach were compared and evaluated departing from the model and terminology that was defined. The provisions for SCM described in the relevant ESA standards were also compared with the model, as far as the details of the procedures were available. One of the results of this comparison was that we were able to point out inconsistencies in the CM change control procedures described in the (draft) standards. It was also striking how the different projects and/or documents used different terminology. This also showed the need for standard terminology for several CM concepts such as baselines, change control forms, change control boards etc. The terminology defined in this task is a first step towards the use of common terminology. This would be a major break-through and would enable in-depth discussions among people with a similar understanding of the CM domain. The next step consisted of filling in the generic model and defining a detailed process model or operational scenario for Software Configuration Management in the ESSDE. This operational scenario forms the ESSDE CM approach. It describes higher level concepts as a logical extension of the generic model. The scenario is operational in the sense that the concepts presented are ready to be introduced in a software development environment, independent of the availability of an automated environment. The following main topics were discussed as part of the scenario : Criteria, timing and responsibility for the selection of configuration items and entities were defined. Special attention was paid to the mapping of the baselines to a multi-level software development life-cycle derived from ESA PSS-OS0. We also described the contents of each baseline, when they are established and at which specific review the respective baselines are frozen. The composition and task description of the Configuration Control Board (CCB), established by each contractor was defined. We described the areas that are involved in the software development life-cycle and showed how configuration items move from one area to another under control of the CCB. The different change control forms, their purpose, contents and approval cycle were defined. Finally, a summary of the different roles, tasks and entities process model was given in a formal (graphical) notation.
of the CM
s MO&$. . The quality of a software product is largely determined by the quality of the process used to develop and maintain it. Thus, product improvements can be effectively achieved by improving the various software development processes and their interactions. This sub task has defined a process model for ESA software developed within an ESSDE.
J.-P. Recigoutand J.Favaro
100
The results of such a software process modelling the following purposes:
activity
can be used for
to have a basis for better understanding of the software development process (and subsequent evaluating and improving); to define clear interfaces between different activities, avoiding duplication of efforts (e.g. between contractor and subcontractor, but also within one software team); to use this information to identify the most adequate (SDE) support, for guiding the SDE users through the development path, for reducing the mental load and for me,asuring purposes. Automating a software process only makes sense if the process is adequately defined. The role of an environment (i.e. an ESSDE) is to support effective use of an effective process. After the process has become stable and has proved to be reasonably effective, we can consider automation to improve its efficiency. The major results of this process modelling effort still have to come from the readers of this document. The process model aims to be a basis for discussion about what the process should really look like. It emphasises the activities to be done, the interactions between the activities, the data produced, and the roles responsible for the activities. This allows us to have a far more operational definition of the software development process, with regard to the standards that mainly describe the deliverables required. In the end, this can lead to better standards and a clear idea about the process that is to be supported by the ESSDE. A greater process visibility also leads to the identification of a number of aspects where standards, thought to be complete, do not provide an answer. The experience of actually doing process modelling also allowed us to define a number of requirements for a process modelling approach. There is a clear need for a process modelling method. Such a method should offer a set of properly integrated (most of them probably existing) techniques and formalisms.
in this section was carried out under frequent The work described consultation and coordination with the ESA Quality Assurance section. Later in the project, a link was established between this work and related work being carried out mainly by Alcatel Research of Austria. Software in this workpackage was to . The first task undertaken attempt to coalesce all of the testing terminology currently in use in ESA projects (especially Hermes and Columbus) into a consistent and common test terminology, with as few terms as possible. After much vigorous discussion and consultancy from interested parties at the Agency, a single terminology was proposed in a task report. The
most
of this task concerned the development of a There has been great concern within the Agency that too many testing roles and activities are duplicated needlessly, and it was considered vital within the project to obtain a clear overview the Agency's procedures. The process model that was a set of roles, tasks, developed to address this concern identified activities and products that compose the software testing process. The notation used to describe this process was later used as the basis for the work on the overall process model. software
important
testing
I
result
process
*
model.
A software classification scheme is needed in Classlflcation. software projects developing software which may have critical consequences if they fail. Yet it is necessary to avoid costly or too strict use of standards and methods for less critical software. In this workpackage, a classification scheme consisting of four classes was proposed. A key notion in this scheme was that the software is never considered in isolation from
Software
European Space Software
101
the total system in which it participates. Thus, it is not possible to assign software to a criticality class independently of other parts of the total system. The actual scheme for classification proved to be the most controversial topic of the workpackage, due in great measure to the dependence of criticality on the total system. The following procedure was eventually proposed: Functional analysis: functionality of the overall system; Failure mode analysis: related to activities, objects, locations (or combination); Failure cause and consequence analysis: in terms of environment and operations; Assessment of functional and item reliability requirements; Software criticality determination: a class is assigned to each software component. .
.
t SoftVertiication and Vution (ISVV). The concept of having a third (and presumably neutral) party carry out V&V activities has been proposed often for organisations like the Agency which produce software with strict quality requirements. In this workpackage, the concept was investigated and evaluated for its relevance to the environment at the Agency. The main conclusions included the following: Use ISVV only when developing software of the highest criticality class (ISW is expensive); Emphasise ISW in the early phases of the software life cycle (the cost of removing errors increases rapidly in later phases). At the same time, Apply ISW on a product only when the product has attained a certain maturity (applied too early, ISW is a waste of resources).
.
are Soeuic
I
sUDQQ&
This group of investigations comprises a series of very specialised topics in software engineering. They are directly related only in the sense of their immediate relevance to software development at the Agency. t of Database AD&cations at the Aaencv . The present ESA standard software development life cycle has been designed for conventional software systems development; its suitability for database applications is less clear. In this workpackage, several modifications to the ESA standard life cycle were proposed, from the perspective of a database development are to be found in the life cycle. The most significant modifications Software Requirements Definition Phase, and - to an even greater extent Design Phase and the in the design phases, both in the Architectural Detailed Design and Production Phase. The Agency-standard Hierarchical Object-Oriented Design (HOOD) method was found to be inadequate for database design. It was recommended to use the (Extended) Entity-Relationship method to "bridge the gap" between HOOD on the one side and more database-oriented principles on the other side. we Reu. This workpackage was included on the premise that the field mature that an attempt sufficiently may be has become of reuse realistically made to introduce a program of reuse into the Agency. As in the rest of the ESSDE Reference Facility Project, two paths were followed a technical and a procedural path. The main objective of this task was to investigate all aspects of starting a program of reuse within the Agency, from the most purely technical to the
102
J.-P.
F'rGgout and J. Favaro
most purely organisational. The work began with a general overview of the concept of reuse as reflected in the state of the art. The next phase of the task was devoted entirely to the investigation of technical issues. Particular account was taken of the fact that the Agency uses the Ada programming language and the HOOD design method. One objective of this phase was to identify a practical way to achieve reuse at the design level, since the design level is viewed as a more effective level for reuse than the code level. investigating technical issues, of the first phase Upon completion attention was focused on "organisational" issues. Since the Agency does much of its software development by contracting, an activity was launched aspects of the ESA contracting "life cycle" (i.e. to investigate identification of requirements, Statement of Work, Invitation to Tender, contract award, etc.) as they are affected by reuse. Next, a sub-activity was launched to survey the state of the art in tool support and to make recommendations based upon criteria of low cost and suitability for the chosen reuse infrastructure at ESA. Finally, a sub-activity was carried out to propose ways to organise a step-by-step introduction to reuse into an This includes recommendations for training, ESA department. for introductory domain analysis, and for choosing candidate departments for the first introduction of reuse.
CONTINUATION
WORK
The work described in this report was concluded in the Spring of 1992. The ESSDE Reference Facility Project is continuing with a third Phase beginning in late 1992. The main areas of emphasis in the continuation work are: ction of Softwe Rew into EsB . Building upon the results, both technical and organisational, of the Phase 2 investigations into software reuse, an attempt will be made to introduce a reuse culture into software development at the Agency. The goal of this work will be to introduce software reuse into a carefully selected set of ESA areas, by first performing a domain analysis and then assisting the relevant ESA personnel in the establishment of the necessary procedures to support a program of reuse. on of the ESSDE Process Mod&l . As noted at the beginning process model is a fundamental of this report, a coherent prerequisite for the introduction of sophisticated tool support for the software development process. At the end of Phase 2, a preliminary version of an overall process model for the Agency was produced using a newly-agreed notation and terminology. The work of the next phase will consolidate this preliminary work into a more stable and consistent form. tion of the FSSDE Software Reawts Docw . Each of the investigations of Phase 2 concluded with a set of recommendations for augmentation or modification of specific ESSDE requirements. During the continuation phase, these individual recommendations will be consolidated together with the original requirements into a new software requirements document intended for use as a reference for the establishment of the ESSDE. IPSE fr. The main thrust of the continuation work will be directed at the of the ESSDE Reference establishment of a first implementation Facility based upon a Commercial Off-The-Shelf IPSE selected by the Agency and a set of commercial CASE tools selected together by the Agency and the Contractor. The driving factors behind this first implementation will be a subset of the consolidated requirements for available, selected according to the resources the the ESSDE, and the services provided by the Agencydevelopment schedule, selected IPSE.
0066-413&9ys15.00 Q 1992PcqamollR?dsLtd
THE EUROPEAN SPACE SOFTWARE DEVELOPMENT ENVIRONMENT J.-P. P&cigout* and J. Favarof *European Space Agenq, EsTEc/wME, P.O. Box 299,Keplerhm I, 2200AG Noomiwijk TheNetherlmds tlntecs Sister’S.p.A., Via Fmtti 14,56125 Piss, Italy
ABSTRACT With the rapidly increasing importance of software in space systems, it is essential that methods and tools are established to ensure reliable costeffective production of this software. The European Space Agency (ESA) has therefore started a program to establish an ESSDE (European Space Software Development Environment) which contains tools supporting the Agency methodologies and standards. The ESSDE shall provide a basic platform for the production and maintenance of software and is expected to be used in ESA projects to prepare onboard and ground future software. The establishment of the ESSDE has been entrusted to a working group consisting of interested parties from Columbus, Hermes and the ESA Technical Directorate, which initiated a project to investigate technically weak software engineering areas; to improve commonality between Columbus and Hermes SDEs; and to study technical areas potentially useful in the future.
KEYWORDS Software development environment, process modelling, software reuse, configuration management, testing, integrated project support environment
INTRODUCTION AND HISTORY OF THE PROJECT Nearly twenty-five years after the announcement of the "software crisis," the software industry has arrived at another crucial juncture. The so(IPSEs) that have been called "Integrated Project Support Environments" developed as a response to the software crisis have matured to the point where they are ready to be used in serious industrial software development. At the same time, the European Space Agency has experienced a steep rise in the amount of software required in its projects, leading it to make a commitment to introducing IPSE technology into its own software development the technology has not converged to a single Unfortunately, projects. standard and ESA was forced as early as 1989 to confront the danger of an incoherent set of approaches being introduced into the major areas of software production in the Agency. Going hand-in-hand with the choice of a coherent IPSE technology is the need for a coherent set of standards and procedures for software development within the Agency. In this area, the Agency had already done outstanding work with the creation and maintenance of the PSS family of standards, which have by now gained a reputation as a model for organisational software development standards. Nonetheless, an overall coordinating effort that satisfied the needs of Columbus, Hermes, Operations and the Technical Directorate was deemed necessary. The goal of this overall coordinating effort is the establishment of a single European
%
J.-P.
Mcigcut andJ.Favaro
Space Software Development Environment (ESSDE). An ESSDE Working Group was created with representatives from the major interested areas. This group developed a Software Requirement Document for a future ESSDE, but decided that, due to the limited resources of the working group, a full-fledged project was required to support the work of establishing a Reference Facility for the ESSDE. Reflecting its origins, this new project was financed in equal shares with funds from three areas (Columbus, Hermes and the Technical Directorate). Reflecting also the pervasive themes of harmonisation and consensus, the ESSDE Reference Facility Project was structured in some novel ways. Rather than immediately concentrate on the establishment of a reference facility, the organisers of the project chose to identify first several key areas in which either the Agency knew that it was technically weak (e.g. in relatively new areas such as reuse) or in which the Agency realised that it was critical to achieve a broad consensus on procedures and standards (e.g. for configuration management). The result was a total of twelve workpackages, each of which was designed to illuminate the best technical and procedural paths for the Agency to follow in the establishment of the ESSDE. Consensus was sought both within the Agency and within the industry serving Thus, the elaboration of these twelve workpackages was the Agency. entrusted neither to a single company nor a single department within the Agency. Instead, a two-phase structure was created for the project whereby in Phase 1 a designated Prime Contractor was to select a set of participating companies from a cross section of European space industry. Only after the formation of a suitable consortium of companies was the work to proceed in Phase 2. The resulting consortium consisted of five companies (Intecs Sistemi, 2i SynSpace, DNV, E2S and Rigel Engineering) from four nations (Italy, Switzerland, Norway, and Belgium). Thus, a representative presence in the project from the side of industry was obtained. In order to obtain a similarly broad-ranging presence from the side of the Agency, a system was set up for the provision of consultants from all major centers of activity in the Agency that had a special interest in the included representatives from various project. The list of consultants sections in the Technical Directorate (e.g. the ESA Quality Assurance section the Division); and ESA Contracts several space-related organisations in Toulouse including the Hermes Directorate; the European Space Operations Center (ESOC) in Darmstadt; and the prime contractors for the Hermes and Columbus software development environments. Two main consultants were initially associated with each work package; as the project progressed, other consultants were added. In retrospect, this system of consultants proved to be one of the major factors in the success of the project. It is doubtful that any kind of meaningful consensus could have been achieved without the advice - on both technical matters and procedural matters - of those most directly affected by the results of the project. With the selection of contractors and system of consultants in place, work began on Phase 2 in November of 1991. Although most activities were carried out according to plan and schedule, several "mid-course corrections" were made during the project. The most important of these occurred after about five months from project start, when ESTEC Software Engineering personnel decided to intensify the focus of the project on the production of a detailed "procedural roadmap" for software production at the Agency. At that point it became evident that future activities in the project would fall under the umbrella of @tprocess modelling," which has been the subject of much recent activity in the software engineering field. The project coordinators from ESTEC and Intecs Sistemi then attended the First European Workshop on Process Modelling and used the results of that workshop to redirect the work. Process modelling terminology was introduced, some subtasks were consolidated and renamed, and the development of an overall
EuropeanSpace Software
process model for software development remainder of the project.
91
at the Agency was undertaken
for the
Another change in the planned activities occurred during execution of the concerning reuse. A relatively workpackage minor investigation into organisational and contractual aspects of reuse resulted in two contacts, one within the NATO CIS Ada Support and Control Capability (NACISA) and one within the contracts department of the Agency, that provided an unexpected opportunity to treat the subject in considerably more detail than originally planned. The remaining activities of the workpackage were redirected to permit this unplanned effort to continue beyond the original schedule. and procedural issues, the Although the work treated both technical issues proved to be the most controversial procedural (perhaps not Some of the most intense discussions occurred among the surprisingly). consultants and contractors in areas in which a consistent terminology needed to be agreed, such as configuration management and testing. Other areas of controversy included operations and maintenance, where certain new concepts such as the "missionisation" concept of Hermes were not yet familiar to those outside Hermes. In some cases, the amount of controversy generated made it necessary to introduce new divisions between subtasks in order not to impede progress. For example, during the work on software classification, the main controversy centered around the classification procedure itself, and therefore a separation of concerns was introduced to allow work to continue on the identification of standards for software development within the different categories subsequent to classification, while discussion of the actual classification procedures continued in parallel.
MAIN RESULTS Although the work performed in the project covered a wide range of topics, it was possible to combine workpackages into groups that were investigated The main results achieved in each line of investigation are together. presented below.
L!?SE-Related
Technaloav
IPSE technology has now evolved to the point where it is no longer possible to study the technical environment in isolation from the entire lifecycle. For this reason, both technical and procedural issues were studied together in this work package. On the procedural side, such issues were studied as a consistent Agency-wide approach to configuration management; of an Agency-wide identification approach to the problem operations and maintenance; and most importantly, a first attempt to create for all software development at the Agency. On the technical
an overall
process
of
model
side, the main issues studied were
the state of the art in IPSE technology: the standardisation of interfaces within the ESSDE. The results of the various procedural studies were intended to form the background for a process-centered software development environment based upon the technical underpinnings identified in the technical studies.
J.-P. Frhigout and J. Favaro
98
ct Support Environment . Due to the newness of the IPSE technology and the variety of approaches now being proposed on the market, it was necessary to take a critical look at the state of the art from the point of view of the needs of the Agency. The approach to be taken by the Agency to the establishment of a single ESSDE must be compatible with the existing Software Requirements Document and the major Agency PSS standards. The major outputs of the tasks became new software requirements to add to the ESSDE Software Requirements Document. The recommended ESSDE approach defines an IPSE as an SDE supporting the development lifecycle, as well as administrative and whole software management tasks such as scheduling, resource allocation, task monitoring information must be managed by the IPSE. But the etc. All related fundamental requirement for an IPSE is its extensibility and its provisions for tool integration. We further required that the tool interfaces should be public, i.e. the IPSE should be open. An ideal IPSE should allow tool integration at three levels: data level, control level and presentation level. On top of lower level integration services, a process integration service allows customising the IPSE to a specific project policy. This support and enforce led to the identification of the main benefits of an IPSE as compared with a traditional SDE: Integration services on four levels (data, control, presentation and process) are available and standardised, Openness, vendor-independence and portability, Tool construction is less complex because the framework services can be reused, Process integration allows tailoring the SDE to the project's needs. We investigated the possible integration mechanisms for each integration type. We concluded that an IPSE providing both data integration by an object oriented repository and control integration services looks very promising. It has clear advantages as opposed to the other approaches. The only problem remaining is the limited experience that is available using such IPSE environments. The technology is new, especially the object oriented variant. . This often the longest phase of the software life cycle and also the most expensive, when one considers that software maintenance typically represents 60%-70% of the total software costs. A review of the normal activities of the development life cycle based on the ESA Software Engineering Standards (ESA PSS-OS-O) was performed in order to identify in which areas different methodologies or to improve the final product from the procedures may be introduced viewpoint, while trying to take into consideration the maintenance different types of maintenance.
Because of the intrinsic complexity of the "software maintainability" which is related to the fact that specifying, designing, concept implementing and verifying maintainable systems is a full lifecycle all the software development activities were considered and activity, suggestions were introduced to improve the maintainability of the final product. A particular
emphasis was put on the following topics:
a systematic approach to prevent defects during software development; specification and verification of maintainability related (user and software) requirements; the impact of the use of good techniques and practices during the Architectural and Detailed Design phases of the software life cycle:
EuropeanSpace Software
99
the importance of recording the information items underlying decisions taken during the development process; the importance of knowledge transfer between development maintenance organisations and/or teams.
the and
tion vt SuDoort . In the first part of this task, we developed a model for software configuration management that provides the necessary support for keeping control of very complex software systems. Since there was not enough consistent CM terminology available, several concepts were defined, but care was taken to remain in line with existing standards. As a result, we obtained a generic model for SCM customisable on many levels, for different policies. This model was called the "ESSDE generic SCM model." Project specific instantiations could be made of it through a Software Configuration Management Plan. In the same subtask, existing SCM approaches such as the Hermes and Columbus approach were compared and evaluated departing from the model and terminology that was defined. The provisions for SCM described in the relevant ESA standards were also compared with the model, as far as the details of the procedures were available. One of the results of this comparison was that we were able to point out inconsistencies in the CM change control procedures described in the (draft) standards. It was also striking how the different projects and/or documents used different terminology. This also showed the need for standard terminology for several CM concepts such as baselines, change control forms, change control boards etc. The terminology defined in this task is a first step towards the use of common terminology. This would be a major break-through and would enable in-depth discussions among people with a similar understanding of the CM domain. The next step consisted of filling in the generic model and defining a detailed process model or operational scenario for Software Configuration Management in the ESSDE. This operational scenario forms the ESSDE CM approach. It describes higher level concepts as a logical extension of the generic model. The scenario is operational in the sense that the concepts presented are ready to be introduced in a software development environment, independent of the availability of an automated environment. The following main topics were discussed as part of the scenario : Criteria, timing and responsibility for the selection of configuration items and entities were defined. Special attention was paid to the mapping of the baselines to a multi-level software development life-cycle derived from ESA PSS-OS0. We also described the contents of each baseline, when they are established and at which specific review the respective baselines are frozen. The composition and task description of the Configuration Control Board (CCB), established by each contractor was defined. We described the areas that are involved in the software development life-cycle and showed how configuration items move from one area to another under control of the CCB. The different change control forms, their purpose, contents and approval cycle were defined. Finally, a summary of the different roles, tasks and entities process model was given in a formal (graphical) notation.
of the CM
s MO&$. . The quality of a software product is largely determined by the quality of the process used to develop and maintain it. Thus, product improvements can be effectively achieved by improving the various software development processes and their interactions. This sub task has defined a process model for ESA software developed within an ESSDE.
J.-P. Recigoutand J.Favaro
100
The results of such a software process modelling the following purposes:
activity
can be used for
to have a basis for better understanding of the software development process (and subsequent evaluating and improving); to define clear interfaces between different activities, avoiding duplication of efforts (e.g. between contractor and subcontractor, but also within one software team); to use this information to identify the most adequate (SDE) support, for guiding the SDE users through the development path, for reducing the mental load and for me,asuring purposes. Automating a software process only makes sense if the process is adequately defined. The role of an environment (i.e. an ESSDE) is to support effective use of an effective process. After the process has become stable and has proved to be reasonably effective, we can consider automation to improve its efficiency. The major results of this process modelling effort still have to come from the readers of this document. The process model aims to be a basis for discussion about what the process should really look like. It emphasises the activities to be done, the interactions between the activities, the data produced, and the roles responsible for the activities. This allows us to have a far more operational definition of the software development process, with regard to the standards that mainly describe the deliverables required. In the end, this can lead to better standards and a clear idea about the process that is to be supported by the ESSDE. A greater process visibility also leads to the identification of a number of aspects where standards, thought to be complete, do not provide an answer. The experience of actually doing process modelling also allowed us to define a number of requirements for a process modelling approach. There is a clear need for a process modelling method. Such a method should offer a set of properly integrated (most of them probably existing) techniques and formalisms.
in this section was carried out under frequent The work described consultation and coordination with the ESA Quality Assurance section. Later in the project, a link was established between this work and related work being carried out mainly by Alcatel Research of Austria. Software in this workpackage was to . The first task undertaken attempt to coalesce all of the testing terminology currently in use in ESA projects (especially Hermes and Columbus) into a consistent and common test terminology, with as few terms as possible. After much vigorous discussion and consultancy from interested parties at the Agency, a single terminology was proposed in a task report. The
most
of this task concerned the development of a There has been great concern within the Agency that too many testing roles and activities are duplicated needlessly, and it was considered vital within the project to obtain a clear overview the Agency's procedures. The process model that was a set of roles, tasks, developed to address this concern identified activities and products that compose the software testing process. The notation used to describe this process was later used as the basis for the work on the overall process model. software
important
testing
I
result
process
*
model.
A software classification scheme is needed in Classlflcation. software projects developing software which may have critical consequences if they fail. Yet it is necessary to avoid costly or too strict use of standards and methods for less critical software. In this workpackage, a classification scheme consisting of four classes was proposed. A key notion in this scheme was that the software is never considered in isolation from
Software
European Space Software
101
the total system in which it participates. Thus, it is not possible to assign software to a criticality class independently of other parts of the total system. The actual scheme for classification proved to be the most controversial topic of the workpackage, due in great measure to the dependence of criticality on the total system. The following procedure was eventually proposed: Functional analysis: functionality of the overall system; Failure mode analysis: related to activities, objects, locations (or combination); Failure cause and consequence analysis: in terms of environment and operations; Assessment of functional and item reliability requirements; Software criticality determination: a class is assigned to each software component. .
.
t SoftVertiication and Vution (ISVV). The concept of having a third (and presumably neutral) party carry out V&V activities has been proposed often for organisations like the Agency which produce software with strict quality requirements. In this workpackage, the concept was investigated and evaluated for its relevance to the environment at the Agency. The main conclusions included the following: Use ISVV only when developing software of the highest criticality class (ISW is expensive); Emphasise ISW in the early phases of the software life cycle (the cost of removing errors increases rapidly in later phases). At the same time, Apply ISW on a product only when the product has attained a certain maturity (applied too early, ISW is a waste of resources).
.
are Soeuic
I
sUDQQ&
This group of investigations comprises a series of very specialised topics in software engineering. They are directly related only in the sense of their immediate relevance to software development at the Agency. t of Database AD&cations at the Aaencv . The present ESA standard software development life cycle has been designed for conventional software systems development; its suitability for database applications is less clear. In this workpackage, several modifications to the ESA standard life cycle were proposed, from the perspective of a database development are to be found in the life cycle. The most significant modifications Software Requirements Definition Phase, and - to an even greater extent Design Phase and the in the design phases, both in the Architectural Detailed Design and Production Phase. The Agency-standard Hierarchical Object-Oriented Design (HOOD) method was found to be inadequate for database design. It was recommended to use the (Extended) Entity-Relationship method to "bridge the gap" between HOOD on the one side and more database-oriented principles on the other side. we Reu. This workpackage was included on the premise that the field mature that an attempt sufficiently may be has become of reuse realistically made to introduce a program of reuse into the Agency. As in the rest of the ESSDE Reference Facility Project, two paths were followed a technical and a procedural path. The main objective of this task was to investigate all aspects of starting a program of reuse within the Agency, from the most purely technical to the
102
J.-P.
F'rGgout and J. Favaro
most purely organisational. The work began with a general overview of the concept of reuse as reflected in the state of the art. The next phase of the task was devoted entirely to the investigation of technical issues. Particular account was taken of the fact that the Agency uses the Ada programming language and the HOOD design method. One objective of this phase was to identify a practical way to achieve reuse at the design level, since the design level is viewed as a more effective level for reuse than the code level. investigating technical issues, of the first phase Upon completion attention was focused on "organisational" issues. Since the Agency does much of its software development by contracting, an activity was launched aspects of the ESA contracting "life cycle" (i.e. to investigate identification of requirements, Statement of Work, Invitation to Tender, contract award, etc.) as they are affected by reuse. Next, a sub-activity was launched to survey the state of the art in tool support and to make recommendations based upon criteria of low cost and suitability for the chosen reuse infrastructure at ESA. Finally, a sub-activity was carried out to propose ways to organise a step-by-step introduction to reuse into an This includes recommendations for training, ESA department. for introductory domain analysis, and for choosing candidate departments for the first introduction of reuse.
CONTINUATION
WORK
The work described in this report was concluded in the Spring of 1992. The ESSDE Reference Facility Project is continuing with a third Phase beginning in late 1992. The main areas of emphasis in the continuation work are: ction of Softwe Rew into EsB . Building upon the results, both technical and organisational, of the Phase 2 investigations into software reuse, an attempt will be made to introduce a reuse culture into software development at the Agency. The goal of this work will be to introduce software reuse into a carefully selected set of ESA areas, by first performing a domain analysis and then assisting the relevant ESA personnel in the establishment of the necessary procedures to support a program of reuse. on of the ESSDE Process Mod&l . As noted at the beginning process model is a fundamental of this report, a coherent prerequisite for the introduction of sophisticated tool support for the software development process. At the end of Phase 2, a preliminary version of an overall process model for the Agency was produced using a newly-agreed notation and terminology. The work of the next phase will consolidate this preliminary work into a more stable and consistent form. tion of the FSSDE Software Reawts Docw . Each of the investigations of Phase 2 concluded with a set of recommendations for augmentation or modification of specific ESSDE requirements. During the continuation phase, these individual recommendations will be consolidated together with the original requirements into a new software requirements document intended for use as a reference for the establishment of the ESSDE. IPSE fr. The main thrust of the continuation work will be directed at the of the ESSDE Reference establishment of a first implementation Facility based upon a Commercial Off-The-Shelf IPSE selected by the Agency and a set of commercial CASE tools selected together by the Agency and the Contractor. The driving factors behind this first implementation will be a subset of the consolidated requirements for available, selected according to the resources the the ESSDE, and the services provided by the Agencydevelopment schedule, selected IPSE.