S USC
C E
University of Southern California
Center for Software Engineering
OCD: OPERATIONAL CONCEPT DEFINITION II
A. Winsor Brown, CSE-USC based on some material from Dan Port, CSE-USC Barry Boehm, CSE-USC CS 577a Lecture September 17, 2003
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 1
USC
C S E
University of Southern California
Center for Software Engineering
Agenda
Rest of Section 3 (after "Early Sections" Section 4: Proposed System Section 5: Prototype Section 6: Glossary for Domain Description Section 7: Appendices
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
2
USC
C S E
University of Southern California
Center for Software Engineering
1. Domain/Organization Description ... 3.3 Current Organization Environment 3.3.1 Structure 3.3.1.1 Worker or Outside Actor X 3.3.2 Artifacts 3.3.2.1 Artifact X 3.3.3 Processes 3.3.3.1 Process X 3.3.4 Rules 3.3.5 [Sep 17, 2003] Shortcomings OCD--II (c) 2003 USC-CSE
3
USC
3.3Current Organization Environment Includes the structure, artifacts, processes, rules,
Center for Software Engineering
C S E
University of Southern California
and shortcomings of the organization's environment into which the new system will be inserted. If the new system is replacing or updating a system that exists in the current environment, that system should be identified as the "current system". The goals of the following subsections are:
To understand the structure and the dynamics of the organization in which the new system is to be deployed (the target organization). To understand current problems in the target organization and identify improvement potentials. To ensure that customers, end users, and OCD--II 4 (c) 2003 USC-CSE [Sep 17, 2003] developers have a common understanding of
USC
C S E
3.3.1 Structure Block Diagram, Organization-Architecture Model using an AADL, or BusinessStructure Model using the UML StaticStructure and Collaboration Diagrams 3.3.1.1 Worker or Outside Actor X 3.3.2 Artifacts 3.3.2.1 Artifact X 3.3.3 Processes OCD--II 5 (c) 2003 USC-CSE [Sep 17, 2003] 3.3.3.1 Process X
3.3Current Organization Environment
Center for Software Engineering
University of Southern California
USC
C S E
University of Southern California
Center for Software Engineering
3.3.3 Processes
Representation: Create either a. A list of process names and a story to describe each process. Each story is a paragraph describing "something the system should do" b. A Business UseCase Model Create one or more UseCase Diagrams that show the processes, the actors, and the relation among them. For each process, create a Business UseCase Description, and an Activity Diagram. c. A tabular UseCase Description summarizes the key information about the process that the usecase OCD--II 6 (c) 2003 USC-CSE [Sep 17, 2003] represents.
USC
C S E
University of Southern California
Center for Software Engineering
3.3.3 Processes: Process Descriptions
The process begins when one of stakeholders makes a reservation request either through email or website, another stakeholder go ahead to approve the reservation request. If the request is denied, the stakeholder must go back to the start to make another request. The process iterates until requests are approved. I. User Request Session 1a. Users use User Agent Interface to request Equipment for a Location 1b. Staff receives notifications via Staff Tools
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 7
USC
C S E
University of Southern California
Center for Software Engineering
3.3.3 Processes: Process Descriptions (cont.)
II. Staff reviews requests via Staff Tools 2a. There might be a Conflict observed 2b. Users make a new request or Staff resolves Conflict 2c. Request is approved and put in a Schedule 2d. According to the Schedule, right Equipments will be put in the right Location III. Staff places Equipment into Location based upon schedule
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 8
USC
C S E
University of Southern California
Us e rs (Fa c ul ty)
Center for Software Engineering
Admi nis trat or
Ema il R eservation R e qu est
R eview R eq ue st
C h eck Equ ipme nt Availab i li ty
[available?]
[no]
R eview C an ce lla tio n Ma tche s
[ y es]
Ap pro ve R eq ue st
[c anc el?]
[no]
[ y es]
Up da te Spre ad sh eet Re c e ive R esult Ema il C omfirma tio n
Email D en i a l
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
9
USC
C S E
3.3.3 Processes: UseCase Description Identifier Unique identifier for traceability (e.g. Process-xx)
Center for Software Engineering
University of Southern California
Relative importance of the process to the business Yes or No List of outside actors participating in the usecase Description of state that workers, outside actors, and artifacts should be in before use-case performed. (informal text, OCL, or both) Postconditions Description of state that workers, outside actors, and artifacts are in after use-case performed. (informal text, OCL, or both) Specializes List of usecases that this usecase specializes OCD--II 10 (c) 2003 USC-CSE [Sep 17, 2003] Includes List of usecases that are directly included by this usecase
Use-Case Name Purpose Overview Organizational Goals: Priority: Abstract Actors Preconditions
Name of usecase Brief description of purpose Overview of the behavior List of organizational goals to which this process contributes
USC
C S E
University of Southern California
Center for Software Engineering
3.3.3 Processes: Process Descriptions
Currently the department receives e-mail requests or requests for equipment through its website. They have to "manually" check an Excel spread sheet to see how many reservations there are on that day and if the equipments are available. Those daily schedules are usually printed out a day or 2 days before. Although same day reservations or walk-in reservations can also be made, the availability of the requested rooms and equipments might not be guaranteed.
OCD--II
(c) 2003 USC-CSE [Sep 17, 2003]
11
USC
C S E
University of Southern California
Center for Software Engineering
D 3 .4 C u rre n t S ys te m
3.3.1 Structure Static Structure Diagram
<<re q u e sts>> <<u se >>
Fa cu lty
E q u ip m e n t
IS D S ta ff
<<re a l i ze >> <<u se s>>
<<d e ri ve >> <<u se s>>
<<de ri v e >>
MS E xce l S p re a d s h e e t
12
ro o USC-CSE [Sep 17, 2003] (c) 2003 m
OCD--II
USC
C S E
University of Southern California
Center for Software Engineering
3.3.1 Structure Static Structure Diagram
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
13
USC
C S E
University of Southern California
Center for Software Engineering
3.3.5 [Current System] Shorcomings
Supervisor spends an enormous amount of time to read email requests and manually input them into the excel sheet which is very inefficient Manual creation of separate Excel sheets for each day in semester becomes very monotonous and time consuming It is tedious to make changes to the schedules, especially with recurring schedules, which makes this process more error prone No search functionality, which forces the administrators to manually look through all requests in Excel sheets before canceling a particular request
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
14
USC
C S E
University of Southern California
Center for Software Engineering
Agenda
Rest of Section 3 (after "Early Sections" Section 4: Proposed System Section 5: Prototype Section 6: Glossary for Domain Description Section 7: Appendices
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
15
USC
C S E
University of Southern California
Center for Software Engineering
Section 4: Proposed System
4.1 4.2 4.3 4.4 4.5 Statement of Purpose Project Goals and Constraints System Capabilities Levels of Service (L.O.S.) Goals Changes in the Organization Environment Due to Proposed System 4.6 Effect on Organizations' Support Operation
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 16
USC
C S E
University of Southern California
Center for Software Engineering
Proposed System
Describes the concept & effects of the proposed system. It is the beginning of the system analysis. Specifically, it addresses the following questions:
What the proposed system is; How well it should perform.
Do not describe how it is, or will be, implemented in software (except for 17 (c) 2003 USC-CSE [Sep 17, 2003] constraints involving OCD--II mandated integrations
USC
C S E
University of Southern California
Center for Software Engineering
System Analysis
The creation of precise, consistent description of a conceptual system in terms of its high-level components Description is within the organization domain, independent of implementation Analysis goes beyond simple checklists and pictures Analysis ties the domain description to the system design and implementation OCD--II (c) 2003 USC-CSE [Sep 17, 2003]
18
USC
C S E
University of Southern California
Center for Software Engineering
Analysis Defined
A separation of a whole into its component parts An examination of a complex system, its elements, and their relations A statement of such an analysis A method in philosophy of resolving complex expressions into simpler or more basic ones
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 19
USC
C S E
University of Southern California
Center for Software Engineering
Analysis Audience
The Domain Description is for all constituents of the project Analysis is for Domain Experts - the high level leaders who understand the domain, know what they want, and have the authority to make decisions Not for implementers, who prefer design and implementation details ("hows")
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 20
USC
C S E
University of Southern California
Center for Software Engineering
Describe the purpose of the proposed system. This description should elaborate on the purpose, context, responsibilities, and organization benefits realized that are described in the Shared Vision (OCD 2). Describe how the highlevel shared vision relates to the
4.1 Statement of Purpose
shortcomings of the current organizational environment and current system (OCD 3.7), how it fits in with the organization's background (OCD 3.1) how it fits in with the organization's goals (OCD 3.2) OCD--II (c) 2003 USC-CSE [Sep 17, 2003] how it affects the operational stakeholders
21
USC
C S E
University of Southern California
Center for Software Engineering
4.2 Project Goals and Constraints - I
Describe in detail any goals and constraints that are critical to the project's success, such as:
The project shall be completed rapidly to sustain the company's competitive edge. The user interface must be compatible with other company systems. The system must be able to adapt to changes in Internet sales tax laws. The system must be compatible with legacy code or systems. The software must run on the XXYY computer system. The software must be compatible with (or use) the OCD--II 22 (c) 2003 USC-CSE [Sep 17, 2003] ABC COTS package.
USC
C S E
University of Southern California
Center for Software Engineering
Every project constraint described in Major Project Constraints (OCD 2.4) should be refined in this section. Additional project goals and constraints may derive from the organization goals (OCD 3.2) or the organization processes (OCD 3.3.3). Each project goal or constraint should be measurable, relevant, and specific (M.R.S.). You should be able to answer the following questions for each goal. M: "How is the goal measured with respect to the proposed system project?" R: "Is this related to any Organization Goal or any external constraint?" S: "What specific part of the system is this goal relevant to? What are the specific acceptable levels or thresholds OCD--II (c) 2003 USC-CSE [Sep 17, 2003]the measures used? What specific parts23 with respect to of the system are to be measured?"
4.2 Project Goals and Constraints - II
USC
C S E
University of Southern California
Center for Software Engineering
4.3 System Capabilities
Describe what the system can do, including services the operational stakeholders expect from the proposed system with respect to their organizations, including desired modifications to the current system (if it exists). Capabilities
define broad categories of system behaviors, as opposed to an operational breakdown provided by System Requirements. should realize the highlevel services described in System Boundary and Environment (OCD 2.3), and support the organization's processes (OCD 3.3.3).
(Note: capabilities correspond with Spiral Model Objectives.)
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 24
USC
C S E
University of Southern California
Center for Software Engineering
4.3 System Capabilities
Broad, high-level system behaviors. What the user should expect from the system Should be in line with Organization Goals and Activities Outline the desired modifications to the current systems entities and activities "Just Do It" approach. Work with what you know and flush out SR's later.
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 25
USC
C S E
University of Southern California
Center for Software Engineering
4.3 System Capabilities
High level overview of broad categories of system behaviors Not an operational breakdown (provided by System Requirements) System capabilities realize high-level activities in the Organization Activity Model (Reference as appropriate)
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
26
USC
C S E
University of Southern California
Center for Software Engineering
4.3 System Capabilities (cont.)
Describe a few system capabilities and work with domain experts to clarify them. Think about "What in our domain description do we want represented with technology?" Look at organization wide goals and consider what is required to carry them out. Each system responsibility may require several iterations: Consistency and redundancy are not issues at point
(c) this 2003 USC-CSE [Sep 17, 2003] OCD--II 27
USC
C S E
Example: Vacation Sick Leave OCD - I Background:
Center for Software Engineering
University of Southern California
(employees, supervisors, and HR), maintainers (ISD people), project manager, and developers. manager. Users include HR staff and 350 employees who are employed under ISD. OCD 3.4 Current System: utilized in the Human Resources(HR), is based on a current software system and a lot of paper work. It is used by staff to store and monitor vacation/sick leave of 350 employees. It is part of a University software system for payroll, personnel and benefits. Current system's user interface is menu driven textual mode system. It is accessible only by HR people. It OCD--II 28 (c) 2003 USC-CSE [Sep 17, 2003] does not provide systematic vacation leave
OCD 2.2 Stakeholders: customer(HR manager), users
USC
C S E
Example: Vacation Sick Leave OCD - II OCD 4.3 Capabilities:
Center for Software Engineering
University of Southern California
The system will provide a web based service for employees and supervisors; Submissions will be done via web page, they will be able to post a query and receive results via web, and communicate and negotiate via email The system should provide the search capability for administrators The system should provide the users with help
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
29
USC
C S E
University of Southern California
Center for Software Engineering
4.3 System Capabilities(cont.)
"Just do it" approach eliminates the pressure to get it all right on the first pass
"Go with what you know" and plan to iterate back through it. Multiple iterations of SC's reduce complexity through balanced partitions, promote focus, remove redundancies and contradictions
As more capabilities are documented, architects get a better idea of how the domain experts are viewing the proposed system
(c) 2003 USC-CSE [Sep 17, 2003]
Allow tangents to continue, even if they cross perceived system boundaries.
OCD--II
30
USC
C S E
University of Southern California
Center for Software Engineering
Finding System Capabilities
Ask Constructive Questions Avoid counter productive questions Don't obsess over issues that are addressed as part of the process (e.g. consistency, redundancy, completeness, soundness)
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
31
USC
C S E
University of Southern California
Center for Software Engineering
Constructive Questions
Some constructive, informal questions that may be useful in gaining clarity (organized brainstorming)
"What does this mean?" "Can you give me an example of this?" "What do you need to do this?" "What is involved with this?"
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
32
USC
C S E
University of Southern California
Center for Software Engineering
Constructive Question 1
"What does this mean?" Useful to define words and phrases
(document in CDL)
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
33
USC
C S E
University of Southern California
Center for Software Engineering
Construction Question 2
"Can you give me an example of this?" Useful to draw out scenarios of desired system operations
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
34
USC
C S E
University of Southern California
Center for Software Engineering
Construction Question 3
"What do you need to do this?" To find out information required to carry out a responsibility
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
35
USC
C S E
University of Southern California
Center for Software Engineering
Construction Question 4
"What is involved with this?" To discover sub-capabilities and the steps required to fulfill them This question is important as it is used to continue the process.
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
36
USC
C S E
University of Southern California
Center for Software Engineering
Counterproductive Questions
Avoid Counterproductive Questions:
"Didn't we already cover this?" "How can we possibly implement that?" "Do we really need this?" Begin by discovering what is actually wanted The modeling process answers these "save it for later" questions
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
37
USC
C S E
University of Southern California
Center for Software Engineering
Counterproductive Question 1
"Didn't we already cover this?" Don't worry about overlapping capabilities: these will be cleared up as we build the model
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
38
USC
C S E
University of Southern California
Center for Software Engineering
Counterproductive Question 2
"How can we possibly implement that?" Stay focused: this is not relevant to domain experts, only to implementers
(c) 2003 USC-CSE [Sep 17, 2003]
OCD--II
39
USC
C S E
University of Southern California
Center for Software Engineering
Counterproductive Question 3
"Do we really need this?" Don't challenge feasibility or relevance: relevance is determined by domain experts (you can send them the bill later!)
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 40
USC
C S E
Define the kinds of levels of service goals for the system (i.e., "how well" the system should perform a given capability) and indicate how the L.O.S. are relevant to the organization goals (OCD 3.2), capabilities (OCD 4.3) and project goals (4.2). (Note: Levels of Service correspond with Spiral Model Objectives or in some cases constraints, as when the level is a non-negotiable legal requirement. Each Levels of Service should be measurable, relevant, and specific (M.R.S.). The description of measures should specify the unit of measurement and the conditions to take the measurement under (e.g., normal operations vs. peakload response time).
(c) 2003 USC-CSE [Sep 17, 2003] OCD--II 41
4.4 Levels of Service (L.O.S.) Goals
University of Southern California
Center for Software Engineering
USC
C S E
University of Southern California
Center for Software Engineering
Example OCD 4.4 L.O.S. Goals
1. Simple and easy to use system
The system should be simple and attractive for the users who are searching and accessing the digital archive so that there is ease of access and usability for novice to expert computer users. For example, with regards to navigation there should only be a few steps for the user to get to the search. The main page will have only a brief description, a text entry only search, and a few links to keep the interface simple. The more advanced search will still be limited to 8 search or browse areas. The search results page will be a list of a maximum of 10 items for simplicity and ease of use. Also, 2 to 3 sample users will test the interface to ensure usability. [Organization Goal 2, 7, 8] [bhansali-WINC-6, bhansaliWINC-7, bhansali-WINC-14, bhansali-WINC-15, eballew-WINC-1, eballew-WINC-5]
2. Good Performance
The user desires quick access to the pages and speedy searches. A user only has so much patience, and the system should be usable or it will not be utilized, thereby limiting access. The wait for pages to load should be no longer than 15 seconds, and the search should take no longer than 10 seconds during peak usage times. The number of large graphics will be minimized, and slower modem connections will be used in testing. [Organization Goal 1, 2, 8] [nrm-WINC-7, eballew-WINC-8]
3. Ensure scalability
The archive should allow for increase in the volume of the resources, such as books, manuscripts, pamphlets, videos, etc. There are approximately 50,000 items to be archived. The system should scale from an archive size of 5,000 items to 50,000 items without any visible performance deterioration. The system should also scale from 5 to 100 concurrent users with the same performance. A significant OCD--II 42 (c)increase in items[Sep 17, 2003] more powerful DBMS with faster searching and indexing capabilities. 2003 USC-CSE may require a [Organization Goal 8] [bhansali-WINC-3, nrm-WINC-5, nrm-WINC-4]
USC
C S E
4.5 Changes in the Organization Environment Due describe the how the new system to Proposed System Sub-sections
University of Southern California
Center for Software Engineering
changes the environment of the organization. (This model is sometimes called an "to be" model) The description should include the
structure, ...