What can TRESE offer?
|
What can TRESE offer? |
|
We refer to the organizations working with TRESE as customers of TRESE. Figure 1 illustrates the possible interactions between a customer and TRESE based on the effectiveness, technology and efficiency (ETE) objectives. For a customer, this interaction may be considered from the business and technical management, and from the software development perspectives. As shown in the figure, the interaction can be represented as a matrix structure, defined by the ETE objectives and the organizational perspectives. The approach of TRESE in providing these objectives is shown at the right-hand side of the figure.
In the following sections, we will explain how the ETE objectives can be provided by TRESE with respect to these three different organizational perspectives.
 | Business Manager’s Perspective: Client
Satisfaction Business managers aim at marketing products that fulfil the expectations of their customers. Client satisfaction here is the key concern. |
| Technical Manager’s Perspective:
Future Product Architecturing For the technical manager, it is essential to specify and design the architecture of the future products so that these products can be produced on time. |
| Software Engineer’s Perspective: Analysis
Techniques Software engineers need powerful requirement analysis and architecture design techniques so that they can produce the systems as they are expected to perform. |
| TRESE’s Approach: Architecture synthesis
and the Industry-As-Laboratory approach TRESE adopted a software synthesis process for architecture design. In this approach, we use requirement specifications to identify the problems to be solved. The problems are then used to discover the necessary solution techniques. The software architecture is then derived from the related solution domains, which are, in turn, verified by the requirement specification. This enables designers to define robust and relevant software architectures. The core of TRESE is formed by the cooperation between people and by joint projects. However, these joint activities must ‘interface’ with each other and with the external environment. One of the essential characteristics that we intend to bring to TRESE is for all research performed within TRESE to be based, either directly or indirectly, on customer’s problems. This is stimulated by the industry-as-laboratory approach [Potts 93], which requires a number of practical projects and cooperations with industrial software development efforts. |
The industry-as-laboratory approach is a research philosophy that provides a framework for establishing relevant research activities that are closely connected to the needs of the industry (the term ‘industry’ is meant here to include business and governmental environments as well). Figure 2 outlines the concepts of the industry-as-laboratory approach.
The aim of this approach is to drive research activities from the real needs that arise in industrial and business environments: through e.g. evaluations, pilot studies and reviews it is attempted to distill relevant problems in practical situations. The next step is to consider these concrete problems and abstract the essential issues.
The research performed by TRESE is thus always based on relevant problems. In addition, an attempt is made to obtain early feed-back upon research results. The eventual application of the final research results in industry leads to a feed-back loop as well, when another research cycle is started.
TRESE’s research activities are mostly initialized through company interviews, future product definitions and identification of research topics.
| Business Manager’s Perspective: Features
versus Time An important question in product development is what kind of features a product must have and when these features must be introduced in the market. Instead of introducing too many features for a product at a given time, it is much more preferable to have a potential technical capability of producing these features whenever they are required in the market. |
| Technical Manager’s Perspective: Satifisfying the
Quality Demands In any project, it is atmost important to provide and balance the relevant quality factors during the software engineering process. Examples for quality factors are correctness, adaptability, reusability, performance and relevancy. The current state of software technology is such that change and evolution are amongst the major hindrances for an effective construction of software. The continuous change in the application environments requires state-of-the-art application software to be extremely flexible and tailorable. The evolution of software reveals itself in two aspects: the problem of coping with changing requirements, and the difficulty in reusing and extending pre-existing software components. To overcome the aforementioned problems, software must be able to effectively deal with changes, both at run-time and throughout its life-time, and provide support for being adapted and extended. One of the major concerns with adapting software is to avoid infringing the consistency and correctness of well-tested components; adaptation through extension can avoid such problems. |
| Software Engineer’s Perspective: Technical
Solutions To produce adaptable and complex software systems, software engineers require the most relevant and reliable state-of-the-art technology suitable for their application areas. |
| TRESE’s Approach:
Quality-Oriented Software Engineering using Compositional Components The essential technical problem in dealing with the features versus time problem and realizing adaptable software is the ability to compose multiple components and tailor them. The obvious prerequisite is the availability of compositional models and techniques, supported by methods and tools. However, while defining and selecting components, software engineers have to deal with many design alternatives. To this aim, the quality-oriented software engineering enables software engineers to explicitly consider the quality factors of components and balance them at various stages of the development process. We consider quality-oriented software engineering in compositional component technology as the major force to enable the creation of a software factory. In the software factory, new software is created by reusing existing, off-the-shelf software components, and composing them into tailored software applications. This should promote the art of software construction to a manageable engineering discipline. The quality-oriented compositional object technology also allows managers to plan and optimize product features within the life-cycle of a product; features can be composed either all at the same time or can be gradually composed in due time while satisfying the desired quality factors. |
| Business
Manager’s Perspective: Low-Risk Investment Often the need for additional knowledge and expertise arises during projects, rather than before. In general it is also not cost-effective to make major investments in research before an obvious need to do so has appeared. |
| Technical Manager’s Perspective:
On-time Product Development Most organizations have well-defined goals, schedules and products to deliver. In a well-managed project research efforts, valuable as they may be, will not be allowed to obstruct on-going product development and delivery schedules. |
| Software Engineer’s Perspective: Technology
Transfer In general, it is not feasible to occupy software engineers with all kinds of research activities. On the other hand, new technologies are required to produce future products. It is therefore very important to provide the necessary technology for the software engineers in a most cost-effective manner. |
| TRESE’s Approach: Concurrent Research TRESE proposes the concurrent research approach to come up with added value for products and product development through research efforts that accelerate product development, rather than interfere with it. In this approach, research projects can be initiated during a project and focus on gradual integration of research results to contribute to the product development activities, both in the current development cycle, or for future releases. We address a number of the key issues that are dealt with in our joint projects (we will use the term TRESE project in the following) to ensure the successfulness of the project: The TRESE project objectives are derived both from the actual situation and the expected products for future releases. This ensures that the TRESE project is tightly connected to the current development activities, and will be able to cope with future developments and requirements. A number of research topics will be identified for the TRESE project, based on the observation of the issues and components in the current development project. These topics are addressed independently within the TRESE project, and the results or solutions are then gradually merged with the development project. This is done through replacement of ‘development components’ by ‘research components’. Before the start of the TRESE project, a research exploitation plan is defined that explicitly describes and schedules knowledge exchange (both from development to TRESE project and vice versa), component merging and evaluation steps. TRESE provides services to support these activities, for example to contribute to the software development project or to technology transfer activities. New concurrent projects can be initiated at a later stage in the same manner. This allows for a continuing effort to make new technology applicable within the organization, again without interfering with the mainstream product-development activities. A project management along the lines sketched above can provide an organization with the required expertise without the danger of infringing a mission-critical development activity. Only if the results of the parallel research project are sufficiently promising, they are incorporated in the main project. |
Conclusions
A joint project between TRESE and its customers has the following characteristics:
| Research is based only on relevant problems as they have appeared in practice, i.e. the main development activities. |
| It provides an organization with the required expertise and capabilities without the danger of infringing a mission-critical development activity of the customer. |
| Gradual merging and integration of research results into the development activities. |
| Projects are carefully planned and explicit schedules are made in advance to ensure that the research activities will effectively contribute to the development activities. |
| The research activities can be also supported with tailored courses. |
Through the arrangements described in this section, TRESE attempts to provide unmatched expertise and maximum effectiveness in its projects, with a minimum of risk and costs involved for its customers.
| [Potts 93] | Software Engineering Research Revisited, IEEE Software, pp. 19- 28, September 1993 |
This page was last modified by Mehmet Aksit on May 6, 2001.
