Releases s and Phases An RUP Case Study Inception Elaboration Construction Stuart Anderson Preliminary Architect. Architect. Devel. Devel. Devel. CS2 Software Engineering Note 7. An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external). s and Workflows Business ing Requirements Workflow Analysis Design Workflow Implementation Workflow Test Workflow Business Use-Case Each major workflow describes how to create and maintain a particular model realized by Design implemented by Implementation verified by Test Bringing It All Together... Phases Process Workflows Supporting Workflows Workflows group activities logically Business ing Requirements Analysis & Design Implementation Test Deployment Configuration Mgmt Management Environment Inception Preliminary (s) #1 Elaboration #2 #n Construction #n+1 s In an iteration, you walk through all workflows #n+2 #m #m+1 1
The Problem You have been asked to provide a system that will be used as part of a patient management system in healthcare systems in the UK. The system is intended to manage certain classes of patients with mental health problems. The goal is to manage patients detained against their will under various sections of the Mental Health (Scotland) Act 1984. Problem ctd Under the Mental Health (Scotland) Act a person may be: Detained against their will Given medical treatment against their will Various sections of the act give various powers. For detention to take place, the hospital must be satisfied that: The patient is suffering from a mental disorder, and The disorder is serious enough to need treatment, and For the patient s health and safety or for the protection of others they should be detained The patient can only be treated in a hospital Problem ctd (Sect 24) Patient may be admitted and required to stay for 72 hours (emergency admission). (Sect 25) Patient may be detained in a hospital for 72 hours (emergency detention), A nurse can detain any voluntary patient for up to 2 hours. (Sect 26) After detention under Sect 24 or 25 the consultant psychiatrist may detain the patient for up to a further 28 days (short term detention). (sect 18) The patient can then be detained for a further 6 months, renewable after 6 months and then annually (involves Sheriff court) (full detention). There are other types of detention that are out of scope From Inception to Elaboration After iterations in the Inception phase have: enhanced use cases, improved planning, developed the environment, understood project risk. It is time to move to Elaboration. Inception generates: A vision document. An initial use-case model (10%-20% complete). An initial project glossary. An initial business case. An initial risk assessment. A project plan, showing phases and iterations. A business model, if necessary. One or several prototypes. 2
Lifecycle Objectives Milestone Evaluation Criteria Stakeholder agreement on scope definition and cost/schedule estimates. Requirements understanding as evidenced by the fidelity of the primary use cases. Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype that was developed. Actual expenditures versus planned expenditures. Elaboration : Building an Architectural Prototype Example of an early elaboration iteration. Each iteration involves a full development cycle, involving all the workflows, in this case: Project management: plan the iteration, risk assessment on the plan, set architectural objectives. Requirements: Decide on primary use cases chosen to drive architecture. Understand drivers. Reconsider use cases and risks. Prototype user interface. Use cases: a summary Each use case describes what needs to be done to accomplish the functionality described in the use case. Process is: Establish the system boundary e.g. how much of the legal system is inside the system? Roughly delineate the system boundaries, then actors and use cases refine the definition. Discover Actors: Hospital Administrator, Nurse, Consultant, Doctor, Trust Administrator, Social Worker, GP, Patient, Next-of-Kin, To identify actors ask yourself: Who are the actors? Who: Uses the system? Installs the system? Starts up the system? Maintains the system? Shuts down the system? Gets information from the system? Provides information to the system? What: Other systems use the system? Automatic actions are taken at set intervals? 3
Spelling out Use Cases Identify the names of the use cases by asking: What functions does each actor require to happen? If the systems stores information - which actor provides, uses, modify, delete the information? Does an actor need to be notified if the system changes state in some way? What external events does the system need to know about? Use Cases in the Mental Health Example Register patient as detained under the act, involves hospital administrator, patient, consultant, GP, social worker, Next of Kin. Extend detention, involves hospital administrator, patient, consultant, GP, social worker, sheriff court, Next of Kin. Discharge patient, involves hospital administrator, patient, consultant, GP, social worker, Next of Kin. Change ward, involves consultant, and 2 nurses. Change responsible consultant, involves 2 consultants. Gather statistics, involves Trust Administrator. Monitor ward caseload, Nurse. Monitor doctor caseload, Consultant. Others involving backup, restore, secure access, access control, log-in, log-out, distributed working, Periodic or Timed Use Cases Many systems incorporate timed or periodic events, two common ways of dealing with this are to: Treat time like actors that instigate certain use case. For example, we might introduce an actor for each periodic event and let the actor instigate the event. Treat use cases as time and associate time with all the actions, placing constraints on the times. 1. A title, Use Case Comprises 2. Actors involved, 3. Preconditions describing the circumstances under which the use case is applicable. 4. Flow of events: usually consists of a primary sequence with some description of the alternate sequences that might arise. 5. Postcondition describing the state of the system after the functionality of the use case has been carried out. 4
Use case: Register Patient 1. Register patient. 2. Involves: Hospital Administrator, Consultant, Patient, GP, Social Worker, Next of Kin. 3. Precondition: the patient is not detained under the act but the consultant believes the patient should be detained Register Patient Ctd. 4. Flow of Events: i. Use case starts when the administrator elects to register a patient. ii. The administrator gathers data on the patient, enough to identify the patient and the GP, Social Worker and next of kin. iii. The administrator gets authorisation to section the patient from the consultant (maybe two opinions?). iv. The administrator allocates the patient a ward. v. The administrator allocates the patient to the consultant. vi. The administrator informs GP, social worker, next of kin. 5. Postcondition: patient is added to the list of people detained under the act in the hospital. Use Cases to Drive Architecture We select an initial set of use cases to drive the architectural design. Initially we may choose a small number to get the basic functionality agreed. In the example we might choose: Register patient Extend detention Discharge patient As the basic use cases to drive early architectural design this omits many essential aspects e.g. access control, confidentiality, etc. Understand Drivers Revisit and refine the use cases. Revise the overall collection in the light of the better understood use cases. For example, in our case study, it may become obvious that we need the system to operate across a number of sites and to make data available in real time to the other sites. This will change the structure of the driver use case and may introduce new use cases to handle synchronisation issues. 5
Reconsider Use Cases and Risks Reconsider the use case set chosen as a driver possible modify the set in the light of the revised use cases and revise the iteration plan. Reassess risk in the light of better understanding - in our example, risks might change because: We understand the requirements on distributed data better. We know the system has some real time aspects and these may increase the likelihood of failure and may introduce new risks. Prototype UI Aims to support validation, we can show the user how the key use cases will be reflected in the system allows early feedback. In our case study: May choose a forms-based interface with one screen for each item in the flow of events. Mock up the screens in PowerPoint and use these to illustrate example scenarios for each use case. Building an Architectural Prototype Analysis and design: Identify classes, find subsystems, check use cases. Refine classes, identify architectural elements. Consider implementation mechanism for architectural classes, review how design meets key use cases. Consider distribution and concurrency in the design. Review the architecture. Architectural Prototype: Analysis and Design In the case study the main classes are the class model associated with the patient this includes the basic admin data plus any treatment associated classes. In addition, the collection of patient objects is of prime importance since that is the main repository of patient information. In refining the classes we would look at determining the implementation packages needed to implement the classes. In considering implementation we would explore the middleware and components we might want to use, e.g. the choice of database system and delivery middleware (maybe we want intranet delivery this implies using some web middleware product). Concurrency and distribution will play an important role if the system is distributed round many sites try to decide policies and access protocols maybe this comes for free with the implementation components. 6
Building an Architectural Prototype Implementation: Decide on the implementation strategy for the architectural classes. Implement the architecture classes and integrate. Integrate the implemented classes. Test: Plan integration and system tests. Assess the executable architecture. Project management: Assess the iteration prior to commencing the next elaboration. Case Study: Implementation and Test In the case study: Implementation could be a throw away prototype that does not implement any of the concurrency or distribution. It may have some aspects of the architecture. The UI may be more faithful to the design. Testing may be quite superficial. Summary Early elaboration phase iteration. Aimed at creating an initial version of the architecture. Identify the key use cases to drive the implementation. Elaborate the key use case to deepen understanding. Use these key use cases to drive the architectural design. Implementation issue are taken into account (the architecture has to be realisable 7