email tisk

2008-05-21 17:21:16 | zobrazeno: 6776x
ASWI - RUP Case Studies. Anglicky. Autor: Ing. MSc. Přemysl Brada Ph.D. Tento obsah je převzat z portálu ZČU. Na portále to nešlo pořádně vytisknout. Tady to půjde.

RUP Case Studies

This document illustrates the activities done on RUP-based projects, by the way of example projects.  It puts together the case studies described in Chapters 5-8 of the book The Rational Unified Process Made Easy, by Per Kroll and Philippe Kruchten (Addison-Wesley 2003).

Created in May 2008 by Přemek Brada, Department of Computer Science and Engineering, University of West Bohemia in Pilsen, Czech Republic

Step \ Project "G" (small green field) "M" (large green field) "J" (large, version 2)
Project characteristics
  • completely new application,
    new domain
  • external customer
  • team of cca 6 developers including manager
  • prj manager = architect
  • cca 15 use cases
  • completely new application,
    new domain
  • external customer - world-wide,
    offices on all contintents
  • 3 teams of cca 6 developers + manager
  • analysts, architect, prj manager, developers, testers, external mentor
  • cca 40 use cases
  • update (release of version 2) of existing application
  • external customer
  • 3 teams of cca 6 developers + manager
  • architect, prj manager, developers
  • cca 8 new use cases

Inception phase

Objectives -> means, artefacts
  1. understand what to build -> vision, key actors and use cases
  2. indentify key functionality
  3. determine at least one possible solution
  4. understand cost, schedule, risks
  5. decide what process to follow
Overview 1-2 iterations (small app, quick to understand what to build) 2-3 iterations (complex app, need to obtain stakeholder buy-in, new field) 1 short iteration (app is understood, need to analyze few use cases and some bug reports, ensure key things not missed)
Iteration 1 ad 1. (understand)  Initial product description was created during project bid and proposal.  Prj manager/architect spends 1 day writing 3-page Vision doc. Team spends 1/2 day brainstorming initial actors and use cases -> 13 use cases, each team member takes 4-5 of them and spends 1/2 hr on each to describe it. Team meeting to consolidate use cases -> 4 new, 2 merged, 1 dropped. Team spends another 8 hrs total to detail the critical use cases.  [1x1 + 0.5x5 + 0.5x5 + 0.5x5 + 1x6 = 15 man-days]
ad 2. (key func)  Architect selects 4 use cases as most critical, discusses with customer, adds 1 more. Team meeting, architect explains why these are critical. Architect documents the critical use cases in initial SRS.  [0.5x1 + 0.5x1 + 1x1 = 2 man-days]
ad 3. (potential solution)  Team builds functional (executable) prototype based on 1 most critical use case, to suggest architecture including components to buy. Team builds bits and pieces of functionality to understand how the technology can be used.  [cca 2x5 + 2x5 = 20 man-days]
ad 4. (risks)  Architect writes 2-page memo ("business case") for the customer, discusses it and corrects.  [0.5x1 + 0.5x2 + 0.5x1 = 2 man-days]
ad 5. (process)  Team has a 1 hr meeting to discuss how they should work. Prj manager/architect then creates a description of the process and rules (what tasks to perform, what artifacts should be produced, what templates to use, how to document) related to the Inception iteration.
ad 1. (understand) Analysts interact with key stakeholders and write Vision draft. Team spends 2 days on use-case workshop with 8 key stakeholders, after which they have reasonable use-case model and glossary.
ad 3. (potential solution)  Team builds a mock-up prototype, and discusses it with the customer representatives.
ad 4. (risks)  Prj manager produces a 12-page Plan, referencing Risk list and other management artefacts. Prj manager has 1/2 day review meeting with key stakeholders to discuss Vision, Risk list, and Plan.
ad 5. (process)  Mentor spends some time with the prj manager and architect, to understand project needs, then creates a description of the process and rules for the whole project (detailed for Inception only). Mentor uses the rules to influence training for the team.
ad 1. (understand)  Team updates the existing Vision, clearly labeling what will be part of the second release. Team tries to identify use cases to be added and details the critical ones.
ad 2. (key func)  Team adds 1 new use case and details most of the use cases not yet described. Team analyses major defects (bug reports) that must be corrected. Architect identifies 1 use case as critical (new technology) and another 2 as influencing the architecture.
ad 3. (potential solution)  Team creates mock-up prototype for 2 key use cases, demonstrates it to customer and analyses their reactions. Half of the prototype uses new technologies to evaluate them.
ad 4. (risks)  Prj manager updates project Plan and Risk list with items related to the update, and has a 2 hr meeting with key stakeholders to review the plans.
ad 5. (process)  Processes and rules from first version project are updated using team members' suggestions.
Iteration 2 (not performed) ad 1. (understand)  Team refines the Vision. Team spends 1/2 day describing the key use cases defined by the Architect [below] and updates the use-case model.
ad 2. (key func)  Architect identifies 8 use cases as architecturally significant to reduce technical risk. Prj manager suggests 9 use cases as critical to the stakeholders. After several days of discussion and interaction with the customer, they end up with a joint list of 9 use cases which are key to the product.
ad 3. (potential solution)  Team performs technology tests and implements bits and pieces of functionality (based on critical use cases) to verify the potential technologies.
(not performed)

Elaboration phase

Objectives -> means, artefacts
  1. detailed understanding of requirements
  2. design, implement, validate and baseline the architecture
  3. reduce key risks, produce more accurate plan (cost, schedule)
  4. refine process and set up development environment
Overview 1 iteration (small app, architecture can be found quickly), maybe 2 iterations if there is a lot of new technology 2-3 iterations (complex app, no experience) to understand and reduce technical risks 0 (zero, i.e. no) iterations (no or few changes to architecture)
Iteration 1 ad 1. (requirements)  While analyzing use cases, team finds another 1 use case and 1 actor. Team details another 4 use cases which takes 2 hr per use case; they now have 8 of the total 15 use cases detailed and at least 4 described briefly.
ad 2. (architecture baseline)  Team evolves prototype from Inception Iteration 1 to find and define the architecture. They show that it is working by testing it on key functionality, and running performance tests. A single key component of the product emerges in the architecture.
ad 3. (reduce risks)  Prj manager/architect spends several hours updating cost and schedule estimates.  Writes memo describing risks and how to reduce them. Prj manager/architect has 1/2 hr meeting with team, explaining both items.  He sends an email message with the information to project customer.
ad 4. (process)  Whole team has 1 hr discussion about processes and tools used in Inception, prj manager/architect then updates the rules (what tasks to perform, what artifacts should be produced, what templates to use, how to document). Team sets up a configuration management system including daily build support. Prj manager/architect helps the team to adopt the processes and tools as a mentor.
ad 1. (requirements)  The team refines the Vision and finds 3 new use cases. Team details another 12 use cases; they now have 21 out of the total 43 use cases detailed.
ad 2. (architecture baseline)  The team builds a functional prototype based on the mock-up prototype from Inception, to find and define the architecture.
ad 4. (process)  Mentor discusses with the team what did and what did not work during the Inception phase, then updates the rules (what tasks to perform, what artifacts should be produced, what templates to use, how to document). 
(not performed as iteration)  Architect verifies how the proposed updates and bug fixes affect the architecture (using partial implementation of 2 key use cases) and updates its documentation where needed.  Team interacts with the sales department to identify a few beta customers who will be willing to beta-test the product update.  Processes and tools familiar from previous release work are briefly reviewed, updated and used.
Iteration 2 (not performed) ad 1. (requirements)  Team finds 1 new use case, but also finds that 2 current use cases are "out of scope". Team details another 13 use cases; they now have 34 out of the total 43 use cases detailed.
ad 2. (architecture baseline)  Team tests the functional prototype on key functionality, and do performance and scalability tests which are critical for the product. These reveal a number of issues. The architecture is significantly reworked (this saves a lot of time in Construction). The updated architecture is again tested.
ad 4. (process)  Mentor uses the rules to influence training for the team.
(not performed)
Iteration 3 (not performed) ad 2. (architecture baseline)  Architect reviews the architecture, and after some corrections it is baselined.  Architect has a 1/2 day meeting with the team to explain it.
ad 3. (reduce risks)  Team has identified 8 champion users on three different continents to represent the spectrum of users, they will be treated as an extended part of the team.
(not performed)

Construction phase

Objectives -> means, artefacts
  1. minimize development costs and time -> enforce architecture, maintain continual progress
  2. develop a complete product ready for transition
Overview 3 iterations (gradually developing the product) 4 iterations, the last one focused on integration and testing 2 iterations
Iteration 1-(n-1) ad 1. (efficiency)  Team designates one member as main person responsible for design, implementation and verification of the key component. Team has frequent meetings to discuss architectural issues, review each other's design and implementation, and solve problems. Daily builds are used to ensure code quality and progress.
ad 2. (develop)  Team has allocated time for consulting with future system users.  After use case is implemented and tested, the product is demonstrated to customer at a meeting and feedback is recorded.
ad 1. (efficiency)  Each of the 3 teams is allocated responsibility for 1-2 major subsystems. The team members have clearly allocated roles (design, coding, testing). Teams have weekly meetings to discuss architectural issues. Architect reviews the work of variousteams and resolves issues.  Bi-weekly builds are done, using the configuration management system set up in Elaboration.
ad 2. (develop)  Team distributes iteration releases to the champion users and obtains feedback by online communication and prepared questionnaires.
ad 1. (efficiency)  Each of the 3 teams is allocated responsibility for 1-2 major subsystems. The team members have clearly allocated roles (design, coding, testing). Architect reviews the work of variousteams and resolves (very few) issues.  Bi-weekly builds are done, using the configuration management system already in place.
ad 2. (develop)  Beta customers are exposed to an internal release, team members visited them onsite to install and start the product update.
Iteration n (not performed. Thanks to continuous user involvment, very little time is needed for beta and final release preparation. This is done as part of the last normal development iteration.) ad 2. (develop)  The team arranges a week of training for the champion users, so they will be able to run beta program in their offices. (not performed)

(Transition phase omitted in the source, unfortunately.)
 
 

Zdroj:  Portál ZČU - ASWI