The goals of the architecture review may be summarised as follows :

• Having the review forces us to document the architecture. We would like to know "is the architecture understandable", "is  a clear comrehensive notation used", "is it too brief, or too long". We also hope that by doing this we can clear up misunderstandings among our development team on assumptions about their components. Preparing for the review has already helped to clear up some of these problems.

• Evaluate early and carefully before it becomes a blueprint for software. A team of seven people have been working on the design for approximately 2 months and we think that sufficient progress has been made to have this review now. We have identified some key design issues, and would like to make some strategic design choices. These are clearly described and we are particularly keen to get feedback on these points as soon as possible before design choices get set in stone. Basically the sooner we find the problems, the easier it should be to fix them.

• Point out places where architecture fails to meet requirements and show alternative designs that would work better. The input to review is the description of the architecture. The assignment of functionality to components and their interfaces are specified in detail. We also identify important quality requirements which should be used in the assessment of the architecture during the review. These address other important software attributes, such as modifiability, maintainability, interoperability etc. An assessment method is suggested, based on use cases (or scenarios) for evaluating whether the architecture meets all its requirements.

• Validate the requirements. Discussion and examination of how well an architecture meets requirements also opens requirements up for discussion. We hope to get a clearer understanding of requirements and a better understanding of their relative priority. We have also surely missed a number of important requirements.

• Determine where finer-grain depictions of architecture are needed. The review will help to identify which parts of the architecture are too complex and where further work may be needed to get a more detailed description of the components.

• Ensure consistency across entire system. Having one architect and one design team responsible for all software frameworks should help minimise the problems of unnecessary duplication and thereby improve maintainability. We shouldnt use two database components, where one will do. Components used to fulfil a function in one corner of the system should be used wherever that function is neeeded system-wide. The review should certainly address this issue to make sure that this is the case.

• Disseminate ideas on what constitutes a good architecture. This could be an important means of getting a more universal understanding of the vocabulary and deeper insights on architectural issues.

• Determine whether can proceed to next stage of development. We would like to make this review before proceeding to the implementation and subsequent release of the software at Christmas.

• Follow-up. Questions asked and errors found will be recorded. The development team should then work through the list of problems identified in the review. Checks will be made to verify that the rework has been done. These records will also allow us to make questionnaires and checklists for future reviews and to devise metrics for measuring quality.

• Reapply. If this review is successful we would aim  to make reviewing a regular activity. We intend to have reviews of all software products i.e. documents, designs, code (i.e. code inspections), test procedures etc.

        Reviews - Discusses aims of the  LHCb Architecture Review : J.Harvey  (ppt, ps)