Elaboration and Iterations

In the Elaboration phase, many risks are mitigated by producing an executable architecture, that is, a subset of the most essential aspects of the system that allow you to very concretely demonstrate key capabilities and therefore unambiguously assert that the risks are eliminated. If you've already built a system with the same technology that you're using in your project, then you can often achieve this objective in a single iteration because there is a limited amount of risk to address. You can reuse solutions from the past and thus make rapid progress.

But if you're inexperienced in the application domain, if the system is very complex, or if you're using new technology, then you may need two or three iterations to get the architecture right and to mitigate key risks. Other factors that will lead you to require multiple iterations include doing distributed development, having many stakeholders or complex contractual agreements, or needing to comply with safety regulations or other external standards.

For each of our three example projects, you would typically have the following iterations pattern:

  • Project Ganymede, a small green-field project: graphics/g_icon.gif Because the application is small, you can typically get the architecture right in a short time. You probably need only one iteration, but if you have a lot of new technology and are building an unprecedented application, you may need two iterations.

  • Project Mars, a large green-field project: graphics/m_icon.gif Because the application is more complex and you have never built this type of system before, you need some time to understand and mitigate technical risks and get the architecture right. You probably need two, or maybe even three, iterations in Elaboration.

  • Project Jupiter, a second generation of a large project: graphics/j_icon.gif You are primarily adding features and making bug fixes without making major changes to the architecture. You will use some new technology and develop some new subsystems, but one iteration should be sufficient. If you are not making anything but minor changes to the architecture, you may not have any iteration at all.

Assuming that our large green-field project would have two iterations, the general aim is to implement the use cases that are most essential to customers, as well as those associated with the most technical risk in the first iteration. Especially in the first iteration, and to some extent the second, start with only partial implementation of use cases (that is, implement only some of the scenarios within the use case) to quickly drive out as much risk as possible and to get a reasonable implementation before detailing the use cases. Each iteration could look as follows .

First Iteration in Elaboration

  • Design, implement, and test a small number of critical scenarios to identify what type of architecture and architectural mechanism you need. Do this as early as possible to mitigate the most crucial risks.

  • Identify, implement, and test a small, initial set of architectural mechanisms.

  • Do a preliminary logical database design.

  • Detail the flow of events of roughly half of the use cases you intend to detail in Elaboration, in order of decreasing priority.

  • Test enough to validate that your architectural risks are mitigated. Do you, for example, have the right level of performance?

Second Iteration in Elaboration

  • Fix whatever was not right from the previous iteration.

  • Design, implement, and test the remaining architecturally significant scenarios. The focus in this iteration should be on ensuring architectural coverage (see the section Ensure Architectural Coverage later in this chapter for more information).

  • Outline and implement concurrency, processes, threads, and physical distribution, as necessary, to address technically high-risk issues. Focus on testing performance, load, and interfaces between subsystems and external interfaces. (Note that planning what is done when is based on mitigating top risks early in the project. For some systems, resolving concurrency, processes, threads, and so on may entail very high risk. If that is the case, then you should already have started addressing these issues in the first iteration in Elaboration.)

  • Identify, implement, and test remaining architectural mechanisms.

  • Design and implement a preliminary version of the database.

  • Detail the second half of the use cases that need to be specified in Elaboration.

  • Test, validate, and refine your architecture to the point where it can be your baseline. A baseline means that you use the architecture as a stable reference point. You can still make changes to it, but you want to avoid major rework except to resolve critical problems. If you cannot reach a sufficiently stable state on your architecture, you should add another iteration to Elaboration. This is likely to delay the project, but it will cost you even more to continue building on quicksand, that is, to invest further in an architecture that keeps going through major changes.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net