Objective 2: Identify Key System Functionality

This is the second objective in the Inception phase, and you should work on it as you identify your use cases. It is important to decide which use cases are the most essential or architecturally significant to ensure that you spend more time up front on the most critical use cases.

The project manager and architect should work hand-in-hand on this activity, involving other stakeholders (such as the customer) as necessary, and using several criteria to determine which use cases are critical.

  1. The functionality is the core of the application, or it exercises key interfaces of the system, and will hence have a major impact on the architecture. Typically an architect identifies these use cases by analyzing redundancy management strategies, resource contention risks, performance risks, data security strategies, and so on. For example, in a Point-Of-Sale system, Check Out and Pay would be a key use case because it validates the interface to a credit-card validation system ”it is also critical from a performance and load perspective.

  2. The functionality must be delivered. The functionality captures the essence of the system, and delivering the application without it would be fruitless. Typically the domain and subject-matter experts know what this functionality is from the user perspective (primary behaviors, peak data transaction, critical control transactions, and so on). For example, you cannot deliver an order-entry system if you cannot enter an order.

  3. The functionality covers an area of the architecture that is not covered by any other critical use case. To ensure that you address all major technical risks, you need to have a good enough understanding of each area of the system. Even if a certain area of the architecture does not seem to be of high risk, it may conceal unexpected technical difficulties that can be exposed by designing, implementing, and testing some of the functionality within that part.

Items A and C will be of greater concern to the architect; project managers will focus mainly on items A and B.

For a system with 20 use cases, typically 3 to 4 of them are critical. [1] During Inception, it is important to understand all the critical use cases you identify and provide a fairly detailed description of them. However, you may postpone describing some of the alternative flows for these critical use cases until later in the project, as long as they do not have a major impact on the architecture.

[1] Note that for some systems, one or two use cases may constitute the core of the application, with a larger number of "supporting" use cases enabling execution of the core use cases. In this situation, fewer than 20 to 30 percent of use cases are architecturally significant, and we would typically implement several scenarios for each core use case.

The critical use cases are listed in the Software Architecture Document (SAD; see Chapter 16).

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

  • Project Ganymede, a small green-field project: graphics/g_icon.gif The architect and the project manager is the same person. The architect/project manager suggests 4 of the 15 identified use cases as being critical. After discussion with the customer, a fifth use case is added. The architect/project manager gets the entire team together and spends an hour explaining why these are the most critical use cases. The team agrees, with potential changes made, and the architect/project manager documents the critical use cases in the SAD.

  • Project Mars, a large green-field project: graphics/m_icon.gif The architect proposes a list of 8 of the 40 use cases as being architecturally significant, strictly from a technical risk mitigation standpoint. The project manager suggests a set of 9 use cases that are critical to the stakeholders. The project manager would like stakeholder buy-in on the functionality of these as soon as possible. Five of the use cases overlap. After a few days of discussion between the architect and project manager, the project manager drops 2 use cases from the list (the project can delay getting feedback on those use cases from the users). The architect sees a way to mitigate some of the risks in 8 of the use cases through some of the use cases the project manager added. They end up with a joint list of 9 use cases, which the architect documents in the SAD.

  • Project Jupiter, a second generation of a large project: graphics/j_icon.gif A lot of time will be spent on improving existing use cases, which means that fewer use cases will be critical than for green-field development. The architect identifies one of the existing use cases as critical because it involves using some unexplored new technology. The architect also identifies 2 of the 9 new use cases as being architecturally significant. The project manager identifies one additional use case as critical from the user perspective. The architect documents the 4 critical use cases in the SAD.



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