The process of creating software

Software creation is a set of processes leading to the creation of a software product. These processes are mainly based on software engineering technologies. There are 4 fundamental processes that are inherent in any software development project.

1. Development of the specification of requirements for software. Requirements determine the functional characteristics of the system and are mandatory for execution.

2. Creating software. Development and creation of software according to the specifications for it.

3. Certification of software. Created software must pass certification to confirm compliance with customer requirements.

4. Improving (upgrading) software. The software must be such that it can be upgraded according to the changed requirements of the consumer.

When executing various software projects, these processes can be organized in various ways and described at various levels of detail. The duration of the implementation of these processes is also not always the same. And in general, various organizations involved in the production of software often use different processes to create software products of even the same type. On the other hand, certain processes are more suitable for creating software products of one type and less - for a different type of application. If an inappropriate process is used, this can lead to a decrease in the quality and functionality of the software being developed.

Software development processes are described in detail in Chapter 3, and an extremely important topic of improving the technology of creating software products is discussed in Chapter 25.

Software creation process model

Such a model is a simplified description of the software creation process - a sequence of practical steps necessary for the development of a software product being created. Such models, despite their diversity, serve as an abstract representation of the actual software creation process. Models can reflect the processes that are part of the software development process, components of software products, and the actions of people involved in software development.

The software development model is a general abstract representation of this process. Each such model represents the process of creating software in some kind of its “cut”, using only a certain part of all information about the process. This section presents generalized models based on an architectural approach. In this case, you can see the entire structure of the software creation process, abstracting from the particular details of the individual components of its stages.

These generic models do not contain an accurate description of all stages of the software creation process. On the contrary, they are useful abstractions that help to "apply" different approaches and technologies in the development process. In addition, it is obvious that the process of creating large systems is not unique, but consists of many different processes leading to the creation of individual parts of a large system.

We describe briefly the types of models of the technological process of creating software.

1. Model of the work sequence. Shows the sequence of steps performed in the software creation process, including the start and end of each step, as well as the relationship between the steps. The stages in this model correspond to the specific work performed by software developers.

2. Models of data flows and processes. In them, the process of creating software is represented as a set of activities (processes), during the implementation of which certain data are converted. For example, the input of the activity (process), the creation of a software specification, receives certain data, the output of this activity receives data that goes to the input of the activity, the corresponding software design, etc. Activity in such a model is often a process of lower order than the stages of work in a model of the previous type. Transformation of data during the implementation of activities can be performed by both software developers and computers.

3. Role model. A model of this type represents the roles of the people involved in the software creation process, and the actions they perform in these roles.

Consider the following software creation models.

1. Cascade model. The main basic activities performed in the process of creating software (such as specification development, design and production, software certification and modernization) are presented as separate stages of this process.

2. Evolutionary (spiral) model of software development. Here, the stages of requirements formation, software development and its certification are alternately interleaved. The original software system is quickly developed based on some abstract common requirements. Then they are refined and detailed in accordance with the requirements of the customer. Next, the system is being finalized and certified according to the new updated requirements.

3. Model of formal systems development . It is based on the development of a formal mathematical specification of a software system and the conversion of a specification using special mathematical methods to executable programs. Verification of compliance with specifications and system components is also performed by mathematical methods.

4. Software development model based on previously created components. Assumes that the individual components of the software system already exist, that is, created earlier. In this case, the process of creating software focuses on the integration of individual components into a common whole, rather than their creation.

Cascade and evolutionary development models are widely used in practice. The formal system development model has been successfully applied in many projects [219, 239, 8 *, 18 *], but the number of development organizations that constantly use this method is small. The use of ready-made system components is practiced everywhere, but most organizations do not strictly observe software development models based on previously created components. At the same time, this method should be widely adopted in the 21st century, since the compilation of systems from ready-made or previously used components greatly accelerates software development.

cascade model

This is the first model of the software creation process, generated by models of other engineering processes [300]. It is shown in Fig. 3.1. This model is also sometimes referred to as the software life cycle model *. The main principal stages (stages) of this model reflect all the basic types of activity necessary for creating software.

* Software life cycle - is a set of processes occurring in the period from the moment of the decision to create software to its complete decommissioning. Thus, the "software life cycle" is a broader concept than the software development process model. However, the cascade model can be considered as one of the models of the software life cycle. - Approx. ed.

1. Analysis and the formation of requirements. By consulting with the software customer, the functionality, limitations, and goals of the software system being created are determined.

2. System and software design. The system design process divides system requirements into hardware requirements and system software requirements. A general system architecture is being developed. Software design provides for the definition and description of the main software components and their interrelations.

3. Coding and testing software modules. At this stage, the software architecture is implemented as a set of programs or program modules. Testing of each module includes verification of compliance with the requirements for this module.

4. Build and test the system. Individual programs and software modules are integrated and tested as a complete system. It is checked that the system meets its specification.

5. Operation and maintenance of the system. Usually (although not always) this is the longest phase of the software life cycle. The system is installed, and the period of its operation begins. Maintenance of the system includes error corrections, were not detected at earlier stages of the life cycle, improvement of system components and "adjustment" of the system's functionality to new requirements.

Fig. 1. Software life cycle

In principle, the result of each stage must be documented (this is a signal about the end of the stage). Then the next stage can not begin until the completion of the previous one. However, in practice, the stages may overlap with the constant flow of information from one stage to another. For example, at the design stage it may be necessary to clarify system requirements or at the coding stage there may be problems that can be solved only at the design stage, etc. The process of creating software cannot be described by a simple linear model, since it inevitably contains a sequence of repetitive processes.

Since at each stage certain works are carried out and the accompanying documentation is drawn up, the repetition of stages leads to repeated works and significant costs. Therefore, after a small number of repetitions, part of the software creation stages, such as the requirements definition stage, is usually “frozen”, but the following steps continue. Emerging problems, the solution of which requires a return to the "frozen" stages, are ignored or attempts are made to solve them programmatically. The “freezing” of the requirements definition stage may result in the system being developed not meeting all customer requirements. This can lead to a poorly structured system if the omissions of the design phase are corrected only with the help of programmer tricks.

The last stage of the software life cycle (operation and maintenance) is the "full" use of the software system. At this stage there may be errors made, for example, at stage 1 of the formation of requirements. There may also be design and coding errors, which may require the definition of new system functionality. On the other hand, the system should always remain operational. Making the necessary changes to the software system may require repeating some or even all the steps of the software creation process.

The disadvantages of the cascade model include a rigid breakdown of the software creation process into separate fixed stages. In this model, decisions are made on the system at early stages and then they are difficult to cancel or change, especially with regard to the formation of system requirements. Therefore, the cascade model is used when the requirements are formalized quite clearly and correctly. However, the cascade model well reflects the practice of creating software. Software development technologies based on this model are used everywhere, including for the development of systems that make up large engineering projects.

In the process of transformation, the formal mathematical representation of the system is consistently and mathematically correctly transformed into program code, gradually becoming more and more detailed. These transformations are performed until all items of the formal specification are NOT transformed into an equivalent program. Transformations are performed mathematically correctly - there is no problem of checking the conformity of the specification and the program.

The advantage of the formal transformation method, which lies in the exact correspondence of the final program to the specification, is ensured by the fact that the distance between successive transformations is much less than the distance between the specification and the program. The proof of the correctness of the code for large scalable systems is usually very long, and often simply not feasible. In this respect, the formal transformation method, consisting of a sequence of small formal steps, is very attractive. However, the choice to apply the appropriate formal transformations is complex and non-obvious.

The most famous example of the formal transformation method is the Cleanroom method developed by IBM [239, 310, 219, 284]. This method involves step-by-step software development, when formal transformations are applied at every step. This eliminates the need to test individual software modules, and testing of the entire system occurs after its assembly. This approach is discussed in more detail in Chapter 19.

Both the “clean room” method and other formal transformation methods are based on the B-method [348]. All these methods have several "inherent" disadvantages, and the cost of developing software using these methods is not much different from the cost of developing other methods. Formal transformation methods are usually used to develop systems that must meet the stringent requirements of reliability, dependability and security, since they guarantee the compliance of the created systems with their specifications.

In addition to the development of this type of system, the methods of formal transformations are not widely used, since they require special knowledge and experience in use. In addition, for most systems, these methods do not provide a significant gain in cost or quality compared to other software development methods. The main reason is that the operation of most systems is difficult to describe by the method of formal specifications - with the creation of most software systems, most of the efforts of developers are spent on creating specifications.

Development based on previously created components

Most software projects reuse some software modules. This usually happens where project developers are aware of previously created software products that have components in it, approximately satisfy the requirements of the components being developed. These components are modified to meet new requirements and then incorporated into the new system. In the evolutionary development model described in Section 3.1.2, to speed up the software creation process, the reuse of previously created components is used quite often.

An informal decision to reuse previously created software components is usually made regardless of the overall software creation process. However, over the past few years, an approach to software development has been increasingly used, based precisely on the reuse of previously created software modules.

This approach is based on the presence of a large base of existing software components that can be integrated into the new system being created. Often, such components are freely sold on the market software products that can be used to perform certain special functions, such as text formatting, numerical calculations, etc. The general model of the software development process with the re-use of previously created components is shown in Fig. 3.5.

In this approach, the initial stage of the specification of requirements and the stage of certification are the same as in other models of the software development process. And the stages located between them have the following meaning.

1. Analysis of the components. Having a specification of requirements, at this stage, a search is made for components that could satisfy the stated requirements. It is usually impossible to accurately match the functions implemented by off-the-shelf components and the functions defined by the requirements specification.

2. Modification of requirements. At this stage, the requirements are analyzed taking into account the information on the components obtained in the previous stage. Requirements are modified in such a way as to maximize the capabilities of selected components. If requirements cannot be changed, the components are reanalyzed in order to find some alternative solution.

3. System design. At this stage, the system structure is being designed or the existing structure of the reusable system is modified. The design should take into account the selected software components and build the structure in accordance with their functionality. If some off-the-shelf software components are not available, a new software is being designed.

4. Development and assembly of the system. This is the stage of direct creation of the system. Within the framework of this approach, the assembly of the system is part of the development of the system rather than a separate stage.

Fig. 5. Development with reuse of previously created components.

The main advantages of the described software development process model with the re-use of previously created components is that the number of directly developed components is reduced and the overall cost of the system being created is reduced. However, when using this approach, compromises are inevitable in determining requirements; this may lead to the fact that the finished system will not meet all customer requirements. In addition, when upgrading the system (that is, when creating its new version), there is no possibility to influence the appearance of new versions of the components used in the system, which greatly complicates the upgrade process itself.

Iterative Software Development Models

The described models of the software creation process have their own advantages and disadvantages. When creating large systems, as a rule, it is necessary to use different approaches to the development of various parts of the system, that is, in general, hybrid (mixed) models are applied to the development of the system. Therefore, an important role is played by the ability to perform individual subsystem development processes and the entire software creation process iteratively, when in response to changes in requirements certain stages of system creation are re-executed (most often, the design and coding stages).

Presents 2 hybrid iterative models that combine several different approaches to software development and are designed specifically to support an iterative way to create software.

1. A step-by-step development model where requirements specification, design, and code writing processes are broken down into a series of small steps leading to software development.

2. The spiral development model, in which the entire software creation process, from the initial design of the system to its final implementation, takes place in a spiral.

The essential difference between iterative models is that here the process of developing a specification proceeds in parallel with the development of the software system itself. Moreover, in the step-by-step development model, the complete system specification can only be obtained after completing the most recent step of the software creation process. Obviously, this approach is in contradiction with the software acquisition model, when the complete system specification is an integral part of the system development contract. Therefore, in order to apply iterative models for the development of large systems that are ordered by "serious" organizations, such as government agencies, it is necessary to change the form of the contract, to which such organizations go with great difficulty.

Fig. 6. Model of step by step development

В процессе пошаговой разработки заказчик сначала в общих чертах определяет те сервисы (функциональные возможности), которые должны присутствовать в создаваемой системы. При этом устанавливаются приоритеты, то есть определяется, какие сервисы более важны, а какие - менее. Также определяется количество шагов разработки, причем на каждом шагу должен быть получен системный компонент, который реализует определенное подмножество системных функций. Распределение реализации системных сервисов по шагам разработки зависит от их приоритетов. Сервисы с более высокими приоритетами реализуются первыми.

The sequence of development steps is determined in advance before they begin. The first steps detail the requirements for services, then to implement them (in the next steps) one of the appropriate software development methods is used. In the course of their implementation, the requirements for the components that will be developed at later stages are analyzed and detailed, and the requirements for those components that are already under development are not allowed to be changed.

After completion of the development step, we obtain a software component that is transferred to the customer for integration into the subsystem, which implements a specific system service. The customer can experiment with ready-made subsystems and components in order to clarify the requirements for the next versions of ready-made components or components that are developed in the next steps. Upon completion of the next development step, the resulting component integrates with previously developed components; thus, after each development step, the system becomes increasingly functional completeness. System-wide functions in this process can be implemented immediately or gradually, as the necessary components are developed.

The described model does not assume that the same approach to the component development process is used at every step. If the component being created has a well-developed specification, then a cascade model can be used to create it. If the requirements are not clearly defined, you can use an evolutionary model of development.

The step-by-step process has a number of advantages.

1. The customer does not need to wait for the complete development of the system to get an idea about it. The components obtained in the first development steps that meet the most critical requirements (since they have the highest priority) and can be evaluated at the earliest stage of the system creation.

2. The customer can use the components obtained in the first steps of development as prototypes and conduct experiments with them to clarify the requirements for those components that will be developed later.

3. This approach reduces the risk of system-wide errors. Although in the development of individual components possible errors, but these components must pass the appropriate testing and certification, before they are transferred to the customer.

4. Since system services with high priority are developed first, and all subsequent components are integrated with them, it inevitably turns out that the most important subsystems are subjected to more thorough comprehensive testing and verification. This greatly reduces the likelihood of software errors in critical parts of the system.

However, during the implementation of step-by-step development, certain problems may arise. The components obtained at each development step are relatively small in size (usually no more than 20,000 lines of code), but must implement some system function. Displaying a variety of system requirements for components of the desired size is quite difficult. Moreover, many systems must have a set of basic system properties that are implemented jointly by different parts of the system. Since the requirements are defined in detail until all components have been developed, it is very difficult to distribute system-wide functions among the components.

Currently, the proposed method of so-called extreme programming (extreme programming), which eliminates some of the shortcomings of the method of incremental development. This method is based on the step-by-step development of small software components that implement small functional requirements, the constant involvement of the customer in the development process and impersonal programming (see Chapter 23). The article [31] describes the method of extreme programming and contains several reports on its successful application, however, such reports can be given for all basic software development methods.

Spiral design model

Спиральная модель процесса создания программного обеспечения (рис. 3.7) была впервые предложена в статье [47] и в настоящее время получила широкую известность. В отличие от рассмотренных ранее моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможной обратной связью между ними, здесь процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внутренний виток спирали соответствует стадии принятия решения о создании ПО, на следующем витке определяются системные требования, далее идет стадия (виток спирали) проектирование системы и т.д.

Каждый виток спирали разбит на 4 сектора.

1. Определение целей. Определяются цели каждой итерации проекта. Кроме того, устанавливаются ограничения на процесс создания ПО и на сам программный продукт, уточняются планы производства компонентов. Определяются проектные риски (например, риск превышения сроков или риск превышения стоимости проекта). В зависимости от "проявленных" рисков, могут планироваться альтернативные стратегии разработки ПО.

2. Оценка и разрешение рисков. Для каждого конкретного проектного риска проводится его детальный анализ. Планируются меры по уменьшению (разрешения) рисков. Например, если существует риск, что системные требования определены неверно, планируется разработать прототип системы.

3. Development and testing. After assessing the risks, a model of the system creation process is selected. For example, if the risks associated with interface development dominate, an evolutionary software development model with prototyping would be most appropriate. If the main risks are related to the compliance of the system and the specification, most likely, a formal transformation model should be applied. A cascade model can be applied if the main risks are defined as errors that can occur during the system assembly stage.

4. Planning. Here the project is viewed and a decision is made on whether to start the next turn of the spiral. If a decision is made to continue the project, a plan is developed for the next stage of the project.

The essential difference between the spiral model and other models of the software creation process lies in the precise definition and assessment of risks. If to speak informally, the risk - those are the troubles that can happen in the process of developing the system. For example, if a new programming language is used when writing software code, the risk may be that the compiler of that language may be unreliable or the resulting code may not be sufficiently effective. Risks may also consist in exceeding the time frame or cost of the project. Thus, risk reduction (resolution) is an important element of a system project management. In Chapter 4, devoted to the management of software projects, the possible risks and ways to solve them are discussed in more detail.

Fig. 7 Spiral software creation model (© +1988 IEEE)

The first iteration of software creation in the spiral model begins with a thorough study of system indicators (system goals), such as performance indicators and system functionality. Of course, there are infinitely many alternative ways to achieve these indicators or goals. But each alternative must evaluate the cost of achieving each stated goal. The results of the analysis of possible alternatives serve as a source of project risk assessment. This occurs in the next stage of the spiral model, where a more detailed analysis of alternatives, prototyping, simulation modeling, etc. are used to assess risks. Taking into account the obtained risk assessments, one or another approach to the development of system components is selected, then it is implemented, then the next stage of the software creation process is planned.

There are no fixed stages in the spiral model, such as specification or design development. This model may include any other system development model. For example, on one coil of the helix, protyping can be used to more clearly define the requirements (and, therefore, to reduce the associated risks). But on the next turn, a cascade model can be applied. If the requirements are clearly formulated, the formal transformation method can be applied.

Formal system development

This approach to software creation has many features similar to the cascade model, but it is built on the basis of formal mathematical transformations of the system specification into an executable program. The process of creating software in accordance with this approach is shown in Fig. 3.3. Here, for simplicity, no feedback between the process steps is indicated.

Fig. 3.3. Model of formal software development

The following fundamental differences exist between this approach and the cascade model.

1. Here the specification of system requirements is in the form of a detailed formal specification, written using special mathematical notation.

2. The processes of designing, writing software code and testing system modules are replaced by a process in which a formal specification is transformed into a program being executed by successive formal transformations. This process is shown in Fig. 3.4.

Fig. 3.4. Process of formal transformation

In the process of transformation, the formal mathematical representation of the system is consistently and mathematically correctly transformed into program code, gradually becoming more and more detailed. These transformations are performed until all items of the formal specification are transformed into an equivalent program. Transformations are performed mathematically correctly - there is no problem of checking the conformity of the specification and the program.

The advantage of the formal transformation method, which lies in the exact correspondence of the final program to the specification, is ensured by the fact that the distance between successive transformations is much less than the distance between the specification and the program. Proofing the correctness of software code for large, scalable systems is usually very long, and often simply not feasible. In this respect, the formal transformation method, consisting of a sequence of small formal steps, is very attractive. However, the choice to apply the appropriate formal transformations is complicated and not obvious.

The most famous example of the formal transformation method is the Cleanroom method developed by IBM [239, 310, 219, 284]. This method involves step-by-step software development, when formal transformations are applied at each step. This eliminates the need to test individual software modules, and testing of the entire system occurs after its assembly. This approach is discussed in more detail in Chapter 19.

Both the “clean room” method and other formal transformation methods are based on the B-method [348]. All these methods have several "inherent" disadvantages, and the cost of developing software using these methods is not much different from the cost of developing other methods. Formal transformation methods are usually used to develop systems that must meet the stringent requirements of reliability, dependability and security, since they guarantee the compliance of the created systems with their specifications.

In addition to the development of this type of system, the methods of formal transformations are not widely used, since they require special knowledge and experience in use. In addition, for most systems, these methods do not provide a significant gain in cost or quality compared to other software development methods. The main reason is that the operation of most systems is difficult to describe using the method of formal specifications - when creating most software systems, most of the efforts of the developers go to the creation of specifications.

Software Engineering Methods

Software engineering methods are heuristic methods, formal methods (formal methods) and prototyping methods (prototyping methods).

Heuristic methods include structural methods based on a functional paradigm; methods oriented to the data structures manipulated by software; object-oriented methods that consider the subject area as a collection of objects; methods focused on a specific application, for example, real-time systems, security, etc.

Formal methods are based on formal specifications, analysis, proof and verification of programs. The specification is written in a language whose syntax and semantics are formally defined and based on mathematical concepts (algebra, set theory, logic). The following categories of formal methods are distinguished:

- Language and notation specifications (requirements languages ​​and notations), focused on the model, properties and behavior;

- Specification refinement (refinement specification) by transforming the final result, close to the final software product is performed;

- Verification / proving methods (verification / proving properties), which use assertion (theorems), pre- and postconditions, are formally described and used to establish the correctness of program specifications. Methods of proof were used mainly in theoretical experiments. For more than 25 years, their use has been limited due to the complexity and economic disadvantage. In 2005 The problem of verification has regained relevance in the proposed new international project “Holistic automated set of tools for verifying the correctness of substations” (T. Hoara, Open Systems, 2006, No. 6), which has set the following promising tasks:

- Development of a unified theory of building and analyzing programs;

- Building a multi-sided integrated set of verification tools for all production processes - development of formal specifications, their refinement and validation, generation of programs and test cases, refinement, analysis and evaluation;

- Creating a repository of formal specifications, verified software objects of various types and types.

Formal verification methods will cover all aspects of creating and validating programs. This will lead to the creation of a powerful verified production base and contribute to a significant reduction of errors in software (for completion and verification, see Chapter 6).

Prototyping methods (Prototyping Methods) are based on the use of the prototype software for modeling the tasks of a new system on it and are based on:

- Prototyping styles that personify the duration of the use of prototypes, for example, the style of creating temporarily used prototypes (throw away),

- Evolutionary prototyping models - transformation of a prototype into a final product and development of specifications in accordance with which it is performed;

- Techniques of evaluation / research (evaluation) of the results of prototyping.

Software Engineering Tools

Software engineering tools provide automated support for software development processes and include a variety of tools covering all life cycle processes.

Requirements Tools (Software Requirements Tools) are:

- Development Tools (Requirement Development) and requirements management (Requirement Management), focused on the analysis, collection, specification and verification of requirements;

- Requirement traceability tools are an integral part of working with requirements, their functional content depends on the complexity of projects and the level of maturity of the processes.

Design Tools (Software Design Tools) are tools for creating software using basic notations (structural SADT / IDEF, UML modeling, etc.).

Software Construction Tools are software tools for translating and combining programs. These include:

- Editors of programs (program editors) and general-purpose editing programs;

- Compilers and code generators (compilers and code generators) as independent means of combining software components in an integrated environment to obtain the original product using preprocessors, assemblers, loaders, etc.;

- Interpreters (interpreters) that provide controlled execution of programs by their description. There is a tendency to merge interpreters and compilers (for example, Java, in .NET);

- Debugger (debuggers), designed to verify the correctness of the description of the source programs and eliminate errors;

- Integrated development environment (IDE - integrated development environment) and component libraries (libraries components), which form the environment of the software development process;

- Software platforms (Java, J2EE and Microsoft .NET) and platforms for distributed computing (CORBA and WebServices, etc.).

Testing Tools (Software Testing Tools) is:

- Test generators, which help in the development of test scripts;

- Means of test execution (test execution frameworks), which ensure the execution of test scenarios and track the behavior of test objects;

- Test evaluation tools (test tools) that support the evaluation of test results and the degree of compliance of the test object with the expected behavior;

- Test management tools (test management tools), which provide engineering control of the software testing process;

- Tools for performance analysis (performance analysis tools), its quantitative evaluation and evaluation of the behavior of programs in the process of implementation.

Maintenance Tools (Software Maintenance Tools) include:

- Tools to facilitate understanding (comprehension tools) programs, for example, various visualization tools;

- Reengineering tools support the program conversion and reverse engineering activities for restoring (artifacts, specifications, architecture) outdated software or generating new product.

Configuration Management Tools (Software Configuration Management Tools) are:

- tracking tools (tracking) defects;

- Version control tools;

- Tools for managing the assembly, release version (configuration) of the product and its installation.

Engineering management tools (Software Engineering Management Tools) are divided into:

- Tools for planning and tracking project progress, quantifying the effort and cost of project work (for example, Microsoft Project 2003);

- Risk management tools used to identify, monitor risks and assess damage;

- Tools for quantitative evaluation of software properties by measuring and calculating the final value of reliability and quality.

Process support tools (Software Engineering Process Tools) are divided into:

- Modeling tools and software model descriptions (for example, UML and its tools)

- Software project management tools (for example, Microsoft Project)

- Configuration management tools to support versions and all project artifacts.

Quality Assurance Tools (Software Quality Tools) fall into two categories:

- Inspection tools to support the review (review) and audit;

- Tools for static analysis of artifacts, data, workflows and checking their properties for compliance with indicators.

Additional aspects of tool support (Miscellaneous Tool Issues) concern:

- Techniques for integrating tools (platforms, views, processes, data) for their natural communication in the integrated environment;

- Meta-tools for generating other software tools;

- Evaluation tools for their evolution.