Perform Gap Analysis
Note: Though this step is presented in a logical order, one might need to alternate between it and the
other 3 steps contained in this task or perform some of them in parallel.
This step is performed by doing a pair-wise comparison of the COTS packages identified in the context of the
marketplace sphere to the information gathered from the architecture and design sphere, stakeholder needs and business
processes sphere, and programmatics and risks sphere. The focus is on trying to understand where they match, where they
don't match, and a characterization of the mismatches.
The pair-wise comparison does not have to focus on all the spheres at the same time. For instance, the step could start
by comparing the identified COTS packages to the information gathered from the architecture and design sphere only, in
order to access how each COTS package fits into the enterprise architecture. Based on this information, some tradeoffs
could be negotiated and a solution formed. Then, the information gathered from the stakeholder needs and business
processes sphere could be added in order to assess how each COTS package supports the required user business processes.
Based on this information, some tradeoffs could be negotiated and the solution refined. This process
continues until the solution is formed based on all the available information gathered from the spheres.
|
Negotiate Tradeoffs
Note: Though this step is presented in a logical order, one might need to alternate between it and the
other 3 steps contained in this task or perform some of them in parallel.
This is a key step to make sure that any identified mismatch is understood and resolved. It is imperative to understand
how important each mismatch is to the solution and understand the possible ways the mismatch can be resolved.
Mismatches can be resolved through negotiating with stakeholders to modify user business processes and stated
stakeholder needs; gathering more information about the capabilities of the COTS packages and their ability to be
tailored to accommodate the mismatch; changing the way the architecture uses the COTS packages; or creating a custom
component to provide the necessary capability. If a mismatch cannot be sufficiently resolved, the candidate solution
can be removed from further consideration.
|
Form Solution
Note: Though this step is presented in a logical order, one might need to alternate between it and the
other 3 steps contained in this task or perform some of them in parallel.
With an understanding of the matches and mismatches, a solution is formed (or updated) by assembling one or more COTS
packages or COTS package components, legacy systems (piece of the systems being replaced), reuse libraries, other reuse
sources (for example, freeware, shareware), any required custom code (including wrappers and "glue") and appropriate
linkage to the broader organization's architecture with which the solution must interface. The solution architecture
and design is capture in the solution dossier.
|
Score Solution
Note: Though this step is presented in a logical order, one might need to alternate between it and the
other 3 steps contained in this task or perform some of them in parallel.
The objective of this step is to score the solution against the project's constraints, including the critical use cases
and the critical non-functional requirements, architectural and design constraints, project management constraints, and
any constraint related to business processes. The rating is done by using Requirements Attributes. Again, involving all stakeholders (or empowered
representatives) is highly recommended while performing this step in order to gather as much feedback as possible on
the candidate solution.
|
|