Relacionados con la estructura del instrumento

So far, in this chapter, we have primarily discussed techniques and approaches that can be used as part of architecture assessment, but we have not shown how these parts are integrated in a full-scale architecture assessment process. Although the reader may have deduced this from the discussion in this and previous chapters, we will here explicitly define the main steps in architecture assessment.

First, one should observe that architecture assessment is an iterative activity that is part of an iterative design process. Once the architecture is assessed for the first time, it will enter the transformation phase, assuming it does not already fulfil all its requirements. After transformation, the architecture will, again, be assessed for its quality attributes.

The first time the architecture is assessed, or possibly even before functionality- based design is performed, the profiles for the relevant quality attributes should be defined. It is important no notice that it is generally not feasible nor useful to assess

Performing Architecture Assessment

all or many quality attributes. As in any engineering discipline, the benefit should outweigh the cost for each activity. Since both the definition of the profile and the, repetitive, assessment process are time-consuming activities, only those quality attributes should be selected for explicit assessment that are crucial for system suc- cess and for which it is unclear whether they will be fulfilled.

Once the relevant quality attributes have been selected and the profiles for these quality attributes have been defined, the next step is to select an assessment tech- nique. As a very general rule, our experience is that development quality attributes are generally most easily assessed using a scenario-based approach whereas opera- tional quality attributes can be assessed using either simulation-based assessment or a mathematical or metrics-based model. However, each system is unique and may require deviation from this general rule. In certain cases, one may decide to use two techniques to assess the same quality attribute. This allows the software architect to cross-reference results and to increase confidence in the assessment or, alterna- tively, investigate inconsistencies.

The above steps are generally performed once during architecture design, for instance the first time assessment of the architecture is performed. During the design iterations, the actual architecture assessment is performed during every iter- ation and for each quality attribute. Assuming one is able to achieve quantitative predictions for each quality attribute, the result is a table containing, for each ver- sion of the architecture, the required level, the predicted level and an indication for each quality attribute. The indication may simply show that the attribute is or is not fulfilled, but also that the attribute needs to be renegotiated with the customer or that a, generally negative, relation exists to another quality attribute.

Concluding, the process of architecture assessment can be divided into two compo- nents, i.e. a part that is performed once and a part that is executed for every design iteration:

•

Select the relevant quality attributes and define the required levels

•

Define a profile for each quality attribute

•

Select an assessment technique for each quality attribute

For each design iteration:

•

Perform the quality attribute assessment for the current version of the architec- ture

•

Assemble the results and decide upon continuation, renegotiation or termination

Assessing Software Architectures

8. Concluding Remarks

Assessment of software architectures is the process of predicting quality attributes of the system developed based on a software architecture. We have identified three different goals with architecture assessment. First, relative assessment is used to compare two alternative architectures. Although useful, the disadvantage of relative assessment is that when comparing alternative architectures for more than one qual- ity attribute, one has only ‘boolean’ data to base the selection on. Second, the soft- ware architect can perform absolute assessment resulting in quantitative statements about the quality attributes for the assessed architecture. This allows the software architect to decide whether the requirements are met by the assessed architecture. However, absolute assessment provides no means to determine upon the theoretical limits for the architecture and the distance between the current level and the theo- retical maximum or minimum. The third goal of architecture assessment is to deter- mine the theoretical maximum of a software architecture for a particular quality attribute. In our experience, techniques are available for the first two assessment goals, but no work, to the best of our knowledge, is currently available with respect to the third goal.

The meaning of quality requirements in the requirement specification is often rather vague and imprecise. In this chapter, we propose to define scenario profiles that define the meaning of quality requirements more precisely. Two approaches to defining profiles exist, i.e. complete profiles and selected profiles. The first defines all relevant scenarios for a particular quality attribute, whereas the second selects a limited number of scenarios from a large population of possible scenarios. To struc- ture the selection process, scenario categories are defined to divide the population into parts.

We have presented three architecture assessment techniques, i.e. scenario-based, simulation-based and mathematical model-based architecture assessment. The sce- nario-based approach assesses the impact of the scenarios in the profile and predicts the quality attribute based on the impact data. Simulation-based assessment devel- ops an abstract system context that is simulated and a high-level implementation of the architecture. Generally, for practical reasons, also the profile that is used for the assessment is implemented. During the simulation, relevant data is collected and the quality attribute can be predicted using the collected data. Finally, the software architect can use a, often adapted, mathematical model developed by one of the quality attribute research communities. The adapted model can be used to predict the quality attribute.

Further Reading

We have discussed the importance of experience in software architecture assess- ment and design. Although our goal is to improve the state of practice by providing objective and quantitative means to reason about architectures, it is explicitly not our intention to diminish the value of experience and creative insight in the archi- tecture design process. Experienced and creative software architects and engineers are a necessary ingredient in any successful software development project.

Finally, we have briefly mentioned the overall software architecture assessment process. This process can be divided in two parts. The first part is performed once during the design of a software architecture and includes activities such as selecting and defining the relevant quality attributes, developing the associated profiles and selecting an assessment technique for each quality attribute. The second part of the process is performed for each iteration of the architecture and consists of perform- ing the assessment for the relevant quality attributes, collecting the results and to decide upon continuation, renegotiation or termination of the design project.

In document PROSPECTO DEFINITIVO (página 51-56)