Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

convergent architecture Building model driven J2EE Systems with UML - Hubert R.

Hubert R. convergent architecture Building model driven J2EE Systems with UML - Wiley publishing , 2002. - 289 p.
ISBN: 0-471-10560-0
Download (direct link): convergentarchitecturebu2002.pdf
Previous << 1 .. 92 93 94 95 96 97 < 98 > 99 100 101 102 103 104 .. 142 >> Next

-174-
Convergent Architecture
Chapter 6: The Development Process
As elaboration progresses, the assembly developer ensures that each member of the assembly development team and its subordinate component development teams produce increasingly elaborated versions of their owned resources, with focus on the ABD workflow aspects. Remember, the owned resources and the worker responsibilities are also defined in the IT-organization model. Once well elaborated, the results of the ABD workflow, the owned resources, fulfill the requirements for the RUP life-cycle objective (LCO) milestone. This means that the assembly developer has arrived at a stable version of the assembly component (also defined in the IT organization) from the design and architectural perspective. At this point, significant structural changes have slowed to the level where UCM coverage becomes reasonable and necessary for many artifacts, as described in the CCM workflow (discussed later). The remaining effort now concentrates on the completion, tuning, and testing of the business logic.
Initial operational capabilities normally should be demonstrable at the end of the second iteration in the elaboration phase. Beginning with the second iteration, an operational increment of the system is presented in the operational test environment (in the test center organization). Each of these operational increments increases the operational scope of the system. However, they are not yet transitioned into the operational systems organization for end-user use. They remain in the operational test environment. This is so because radical changes may still occur in the design and realization of these increments until later in the construction phase.
RUP Construction-Phase Variant
The construction phase constitutes a smooth, practically unnoticeable shift of focus toward the implementation cycle workflow. In these iterations, the ABD workflow has diminished significantly, with a proportionate increase of time spent in the implementation cycle and test workflows. These workflows are now the center of activity, with the models from the ABD workflow still driving development and, in particular, code generation. In our model-driven approach, the ABD workflow does not come to an abrupt end. It just shifts focus during the iteration of the construction phase, leading to rapid increases in the visible capabilities of the system.
The assembly developer, deployment manager, and system project manager plan and drive the construction-phase iterations to fulfill the requirements for deployment into the operational systems organization. The last iteration in this phase concludes with the RUP initial operational capability (IOC) milestone, where the test center manager and deployment manager agree to release the assembly to the transition organization for prerelease testing by end users in the operational systems environment.
RUP Transition-Phase Variant
The goal of the transition phase is the public release of the assembly into general usage. In this phase, the assembly development team works closely with the transition organization and focuses on the deployment and monitoring workflow. During an iteration, problem reports from the deployment and monitoring workflow propagate via the deployment manager back into the implementation cycle workflow aspects of development and result in new prerelease versions of the assembly. New feature requirements and major change requests flow to the
-175-
Convergent Architecture
Chapter 6: The Development Process
requirements manager, not to the assembly development team, as defined in the requirements management activity previously.
In addition to testing the deployed system, the operational user support organization and infrastructure and base systems organization (see the IT-organization model) are brought up to speed by the assembly development team. The end of this phase is marked by the transition manager declaring that the assembly is ready for public release. This also ends development for a single, versioned release of the assembly, which may be followed by subsequent versions during its entire life cycle. A final review is held with the assembly development team. This review provides constructive feedback to each of the IT organizations.
In addition, the review addresses further releases and further ownership of the assembly. If the normal planning flow has not already foreseen a subsequent release, then the responsibility for further planning regarding the assembly lies with the IT-organization manager, as described in the IT-organization model. Alternatively, the ongoing T-bar business analysis and requirements workflow may reinitiate a project proposal for a new version of the assembly at any time in the due course of its activities. Ownership of the assembly and its contained convergent components remains with their respective developers. If this is not possible, then resource ownership for the artifacts reverts to the architecture organization until new resource owners can be assigned.
Previous << 1 .. 92 93 94 95 96 97 < 98 > 99 100 101 102 103 104 .. 142 >> Next