Which Approach
Home Business Change Analysis & Design Agile Testing Templates About us

Introduction
Approach
Enterprise Planning
Enterprise Elaboration
Refine - Analysis Classes
Refine - Combined
Which Approach
Uses of Deliverables
Other Methodologies

How to decide on analysis elaboration approach

This methodology has shown three different ways in elaborating the scenarios identified in the inception phase. Which approach is right for your organisation?

Enterprise projects tend to have a large scope and are often characterised by poor initial scoping. Such projects are often fraught with issues internal politics and overlapping roles within the company structure, issues that could be avoided if scope is very clearly defined. If the project is a multi-million pound project that will span several years then the extra effort associated with hybrid approach will be worth it.

If the management of component delivery is likely to be an issue – for example if likely to be outsourced, or if components have a danger of having overlapping boundaries, then a component level approach should be considered.

If the scope of the enterprise is small, or the architecture is simple an approach with a greater emphasis on analysis class modelling will be more useful.

The following table summarises the key differences and advantages/disadvantages of how scenarios can be elaborated. Whilst either will bring real benefits to scoping and project stability, there will be situation where one may be more suitable than the other.

Table 2: Elaboration approach

Area

Component level approach

Analysis Class level approach

Hybrid Approach

OO Considerations

-

+

+

Architecture Considerations

+

-

+

Management and Testing Considerations

+

-

+

Time to produce

+

+

-

Use case style

White box “System of System” approach to use cases

Black box “Enterprise” approach to use cases

Black box “Enterprise” approach to use cases

Responsibility Style

Responsibility assigned to component (component drives this decision)

Responsibility assigned to analysis (or domain) class

Responsibility assigned to both analysis class and component

Explanation of above

"OO Considerations"

bullet

For component level approach there is a danger of functional decomposition (although less of an issue if components are cohesive since they will likely map to the core domain classes – e.g. Trade Management component will map to Trade Management class). Also any associated class models will be fragmented– missing “entities” (and difficult to control).

bullet

For ACM and hybrid, as these adopt a “pure” OO approach, the analysis class model will be consistent. This is a greater or lesser issue depending on whether OO is used in detailed design and development.

"Architecture Considerations"

bullet

For component and hybrid level approach focus on delivery of components in model:

bullet

Very clear assignment of responsibility to components at earliest stages

bullet

Acknowledges core emphasis of components to enterprise

bullet

For ACM approach reliance on traditional UML component model:

bullet

Assignment of responsibility to components often cursory or poor.

bullet

Hard to give a view of the ACM that is interesting to component.

bullet

Some classes not important and even for those that are some responsibilities are not.

bullet

Important to realise ACM on its own will only ever be the starting point for design, be this detailed design or high level design as suggested here in inception phase

"Management and Testing Considerations"

bullet

For component and hybrid approach

bullet

Easier to review and test from end-to-end perspective

bullet

Self contained unit of delivery – that can be tracked and managed and form an element in iteration plan.

bullet

Component use cases discretely managed as deliverable

bullet

For ACM

bullet

Harder to review from end-to-end perspective

bullet

Class operations on own cannot form coherent delivery – must be linked together with others in end-to-end way to make a meaningful iteration – but since iterations involve components this must also respect components – a weakness of ACM only approach

 

Back Next

© 2002-2005 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com