The benefit of this methodology is that it offers a
context rich model common that provides a common vocabulary for discussion in
the planning phases of a cycle. This section gives an overview of how a variety
of stakeholders can utilise its deliverables either in inception or elaboration,
and take them forward into later phases.
As each scenario and
dependency model is in the context of a clear goal suggested by the use case,
the alignment of iterations against the delivery of these will give clear and
measurable benefits to the stakeholders.
This will improve the planning since cycle and
iteration are conducted in a less ad-hoc manner (driven possibly by teams with
conflicting needs and agendas), to a more holistic manner focussing on a set of
clear objectives (or themes) for the cycle and iteration, that is executed in a
logical order of dependencies.
1. Review goals
from use case model
2. Identify
goals that bring benefit to phase
3. Review
dependency model for the chosen goals
4. Plan
iterations in order of dependency
5. Plan
interfaces in order of dependency
Some notes:
·
Don’t need to put unchanged responsibilities on here
·
Estimates for time can be based on standard metrics that are
function of complexity of responsibility, whether it is identified as new or
changed, and if extending phase – standard time for doing things. Example
metrics simple 1 day, medium 3 days, complex 5 days, special (needs bespoke
approach). Build teams need to review and agree these.
·
Such an approach is only a start – and must be tweaked to consider
testing, NFR, migration etc. This has not been shown to keep the example simple.
Component Build/Delivery Teams
Build teams can be
internal, outsourced or external. It is best that representatives from these
team are present in the early reviews of the enterprise models, especially when
responsibilities are mapped to component use cases or analysis class
responsibilities. They will have experience, especially in extending phase type
projects of judging if this mapping is correct, spotting misplaced
responsibilities, and challenging the estimates. It also allows them an early
view of resources they need to mobilise within their teams. Since the build
teams are responsible for design of their component (within the guidelines
suggested by enterprise architects), the level of design activity can be planed,
however it must be stressed that inappropriate early design can be dangerous.
Throughout construction the enterprise model must
be updated against Baselined deliverables.
This is done by:
1.
Review static model
1.
Confirm correct assignment of responsibility
2.
Review trace of responsibility to existing analysis and design artefacts
(if applicable)
3.
Review dependency model
4.
Apply metrics to estimate cost of modifying or providing realisations of
new responsibilities
5.
Plan appropriate A&D activity against impacted responsibilities as
defined by overall iteration plan
6.
Plan appropriate A&D activity to define new responsibilities
7.
Update scenario model with missing or erroneous responsibilities
flows
8.
Review trace of interfaces to existing interfaces
9.
Plan appropriate A&D activity against impacted interfaces as defined by
overall iteration plan
Architects
The architects are to review dependency models to
ensure coherence to their vision of component topography. Where external systems
(from GCS’s perspective) are shown, integration issues can be discussed, and the
mutual responsibility agreed.
This is done by:
2.
Review dependency models
3.
Validate assignment of responsibility is appropriate against cohesion
objectives
4.
Validate assignment of dependency is appropriate against coupling
objectives
5.
Identify internal interfaces impacted, and update model with the
interface names, if necessary adding additional ones to model
6.
Identify responsibilities on internal interfaces to support the component
responsibility, and update model accordingly.
7.
Review static model
8.
Ensure static model is consistent with architectural vision
9.
Review points of integration shown in use case realisations with
all impacted parties
Figure 25: Example
– dependency model used to identify coupling
In this example, the architects
would then decide if the highlighted coupling suggested was appropriate
Figure 26: Example
– elaboration model used to identify integration points
In this example, the architects from both
enterprises would review (a completed) version of the above to ensure the major
integration points are well defined. Note that even if component level use cases
are not adopted, the above should not be treated as a single enterprise,
therefore responsibilities shown at this level, do become use cases.
Testers
The “V” model for testing should balance the scope
of UAT and integration testing against the scope of enterprise scenarios. By
providing these scenarios earlier, test managers can plan this activity more
effectively.
Figure 27:
Unravelling the “V” model
The above figure outlines the “V” model – pairing
the test activity with the related development activity. Unfortunately this
pairing does not usually occur at a similar stage in the lifecycle, with
integration and UAT left to the end (effectively “opening” the V). With major
enterprises leaving the planning of integration testing at the end can be a
major reason such projects fail.
By utilising this methodology, planning for
integration and UAT testing can occur almost concurrently with the development
activities. Additionally by defining requirements against a components
responsibility, testers can be more proactive in ensuring each component team is
fulfils their responsibility in providing test data.
This is done by:
1. Review
enterprise scenarios described in use case realisations
2. Produce UAT
test plan based on each scenario
3. Produce
integration test plan based on each scenario
4. Review data
dependencies on responsibilities on dependency model
5. Ensure
components teams plan to procure this data as part of testing activities
6. Ensure all
exceptions paths in use case realisations have been considered
7. Plan test
data for all components aginst operation signatures in component knowledge
model and use case realisations
Figure 28: Example
- Use case realisation model used to show component test data
Migration Planning
Migrators have similar issues to
testers in that their ability to plan for transition, is often left at the last
moment – again a reason for project failure. But by utilising this methodology,
migration plans and migration data can be procured much earlier.
This is done by:
1. Produce
migration plan for all date identified in component knowledge model and
use case realisations
Reference Data and Screens
These supplementary activities
require special attention since the planning and scope of these are often poorly
executed.
Screens (or a presentation
layer) are shown in the end to end scenarios where they have a core
responsibility, r is the focus of the elaboration. However to show all their
incidental responsibilities on each elaboration would result in contrived
scenarios and loss of focus.
The portal team, as part of the
inception phase must examine all these implied responsibilities and assign them
to the portal in the model. This is in a similar fashion to what the architects
have done to the internal interfaces.
This is done by:
1.
Review use case realisations for any implied screens
2.
Update use case realisations to show any missing screens
3.
Produce screen mock-ups or UML screen-navigation storyboards
to support all these additional responsibilities
For referenced data, core data types are to be
shown against the component responsible for managing them (typically this would
be a core entity). These can be then planned for delivery as part of the
appropriate iteration where shown in a dependency model.
Therefore planning issues of
late delivery typically associated with reference data should be avoided since
in most dependency models, reference data is shown as the base of the dependency
chain, and will be thus planned for first, rather then last
Figure 29: Example –
core data types shown in a dependency model
Analysts
There has already been some discussion as to how
responsibilities can either map to component level use cases or operations on
analysis classes as applicable to the philosophy of the organisation. This
section discusses some other uses that can occur in inception or elaboration.
Detailed component use case description.
If the component based approach is to be used, then
the component level use cases should be elaborated using a standard use case
template. Such descriptions should still adopt a solution independent approach,
and whilst it could be argued that this is initial design, it should certainly
not be treated as detailed design.
Please refer to a separate white paper on
techniques for defining component level use cases: Codel Services
Component Level Use case approach
Screens and reports should not be elaborated using
component level use cases. Rather should be described using UML models such as
user-navigation storyboards and screen mock-ups.
Interface analysis.
Interface analysis is equally as important as
functional or responsibility analysis. Typically the major problems in an
end-to-end enterprise will be that whilst individual functions may be correct in
themselves, they don’t join up either as a result of poorly defined
responsibility, or lack of understanding of interfaces. Whilst the top-down
approach suggested here will mitigate this, a comprehensive interface analysis
in the elaboration phases is extremely worthwhile. Whilst interfaces have been
described in the dependency model, these are implicit interfaces – which
just identify the name and dependency. The activity here is to specify
explicit interfaces as shown in the following example:
Figure 30: Example
– explicitly defined interface
In the above example, by inspecting the
responsibilities of Settlement Management, component its responsibilities can be
grouped for two purposes: that around the settlement run process, and that
around reporting of this information. It would seem sensible then to offer two
public interfaces, and thus “protect” the internal responsibilities. This way
coupling points can be considerably reduced.
As a rule of thumb, consider s different explicit
interface for each component dependent of the component in question – if that
dependency is for a clearly different purpose.
Also the operations signatures (including input,
outputs, returns, NFRs and processing logic)on these interfaces can be
described, making such a model extremely rich in content.
The business
The business’s objectives are to validate the
elaborations as part of the end-to-end scenarios. By being involved in this in
the inception phases, this will aid them in reviewing lower level A&D artefacts
in the later phases.
This is done by:
1. Review goals
from use case model
2. Review
business narrative of goal
3. Review
end-to-end scenarios – either in raw form, or customised in a PowerPoint
presentation (as shown in Present the findings)
