Objective 3: Determine at Least One Possible Solution

Since the overall goal of Inception is to determine whether it makes sense to continue with the project, you need to make sure that there is at least one potential architecture that will allow you to build the system with a sensible amount of risk and at reasonable cost. As an example, you may consider three options for a client/server architecture (see Figure 6.3). By analyzing desired functionality (in the first version, as well as future versions of the application), compatibility with other applications, and requirements on operations and maintenance, you may conclude which of these three options are viable . As you explore options, ask the following questions:

  • What other, similar systems have been built, and what technology and architecture did you use? What was your cost?

  • In particular, for an evolution of an existing system, is the current architecture still satisfactory, or does it need to evolve ?

  • What technologies would you have to use within the system? Do you need to acquire any new technologies? What are the costs and risks associated with that?

  • What software components are needed within the system (database, middleware, and so on)? Can they be purchased? Can they be reused from another in-house project? What are the estimated costs? The associated risks?

Figure 6.3. Three Options for a Client/Server Architecture. During Inception, identify the type of architecture you intend to have and make implementations of necessary elements to the architecture to understand what risks you are facing . Here you see three options for a client/server architecture, each with vastly different requirements for tooling, competency, and complexity, and with different ability to address existing and future requirements on functionality, operation, and maintenance cost.

graphics/06fig03.gif

In some cases, you may need to acquire or implement some key elements of the architecture, or different suggested architectures, to better understand the risks you are facing and the options you have. For applications where stakeholders might find difficulty envisioning the end product, you should also spend time on implementing some functional prototypes , sufficiently rich to verify that the Vision makes sense.

At the end of Inception, you should have a rough idea of what risks you are facing, especially in the areas of acquisition of technology and reusable assets, such as architectural framework, packaged software, and so on. During Elaboration, you may come up with a better architecture, and that is fine. It is during Elaboration that you will address the vast majority of the architecture- and technology- related risks you identified during Inception.

For each of our three example projects, you do the following:

  • Project Ganymede, a small green-field project: graphics/g_icon.gif The team builds a functional prototype of the use case that is considered the most critical. The functional prototype identifies some key architectural components, including one that you need to purchase. The team builds bits and pieces of functionality to understand how some new technology can be used, allowing you to better understand what can be delivered.

  • Project Mars, a large green-field project: graphics/m_icon.gif The team builds a conceptual prototype in the first iteration. This helps the interaction between the team and the customer, so the team can do a better job documenting what the customer wants. The second iteration focuses primarily on understanding what technology to use and associated risks. Some of the key building blocks are outlined, and fragmented implementations of a couple of the critical use cases are done to better understand what technology choices to make.

  • Project Jupiter, a second generation of a large project: graphics/j_icon.gif The team makes mock-ups of two of the four critical use cases identified. Half of this code is throw-away, but the mock-up convinces the team that it will be able to implement the use cases, and it gets some experience with some of the new technologies it will use. The team demonstrates the mock-ups to the customers and gauges the reactions of the audience to determine their expectations.



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