Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 (520) 621-6561

Similar presentations


Presentation on theme: "The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 (520) 621-6561"— Presentation transcript:

1

2 The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ (520) Copyright © Bahill

3 © 2009 Bahill 2 5/31/2014

4 References Terry Bahill and Jesse Daniels, Using object-oriented and UML tools for hardware design: a case study, Systems Engineering, 6(1): 28-48, My template for writing use cases is available at My guidance for naming UML things may also be useful © 2009 Bahill 3 5/31/2014

5 Evolution 20th century systems were mechanical hardware systems. 21st century systems are electronic software systems. Systems engineering tools are also evolving. These new tools are being used by both systems and software engineers. Systems and software engineers are speaking the same language. © 2009 Bahill 4 5/31/2014

6 Adopt the new tools Software engineers have been about five years ahead of systems engineers. Our tools have their origins in the 1950s and 1960s: they have improved our tools. The Unified Modeling Language (UML) is a standard for using these tools. (Previously this was called object-oriented analysis and design.) The Systems Modeling Language (SysML) has extensions specifically created for system design. We should use UML and SysML. © 2009 Bahill 5 5/31/2014

7 The deficiency Systems engineering design tools are old fashioned do not link together are used differently by different people Systems and software engineers do not communicate well. Some systems engineers are still using waterfall processes. Flow-down of requirements causes excess design margins and expensive redesigns. Late changes in requirements cause costly redesign. © 2009 Bahill 6 5/31/2014

8 What the UML is not The tools of the UML do not replace all other tools. A fool with a tool is still a fool. © 2009 Bahill 7 5/31/2014

9 Commercial products IBM Rational Rose I-Logix Rhapsody Telelogic Tau UML Suite DOORS Rose Link Enterprise Architect I have a site license for Enterprise Architect © 2009 Bahill 8 5/31/2014

10 UML helped Raytheon win DD(X) Brain Wells and Paul Weeks said they used object- oriented analysis (OOA) at the system level. Of their preproposal, their customer said use of OOA was a weakness. When they won the contract in 2003 it was said to be a major strength. Creating a common language and a common vision for all engineers helped them to win this $1.36 billion contract. On DD(X) they are using UML for Systems Architecture, System Design and System Analysis, as well as Software Design. The DD(X) is now called DDG1000 Zumwalt class © 2009 Bahill 9 5/31/2014

11 USS Zumwalt © 2009 Bahill 10 5/31/2014

12 Joint Strike Fighter In 2001, Lockheed Martin beat Boeing in the Joint Strike Fighter (JSF) competition. Early on, they noted a government suggestion in the RFP that object-oriented design and UML tools be used for the system design. Lockheed Martins proposal was substantially superior in this aspect. The JSF is now called the F-35. © 2009 Bahill 11 5/31/2014

13 The UML tools are graphical* © 2009 Bahill 12 5/31/2014

14 Using UML improves communications The UML is an engineering method for communicating and modeling systems. It helps software and hardware engineers to communicate. It helps software and systems engineers to communicate. It improves communications with our NATO partners. © 2009 Bahill 13 5/31/2014

15 Unified Systems Engineering Process Iterative, incremental elaborations Vertical requirements development Dont throw it over the wall. Requirements are developed, not passed off. Five major themes: (1) requirements (get them early and get them right, but plan for change), (2) architecture (design the interfaces early), (3) design is use case based, (4) plan frequent small iterations and (5) manage risk (start risk analysis early and develop high-risk subsystems first). © 2009 Bahill 14 5/31/2014

16 © 2009 Bahill 15 5/31/2014

17 Comparison of life cycle phases © 2009 Bahill 16 5/31/2014

18 Baselines In industry baselines often have names such as, business model, requirements model, logical model, analysis model, design model, implementation model, component model, deployment model, run time model, etc. These models are roughly associated with a system life cycle phase, as shown in the next slide. © 2009 Bahill 17 5/31/2014

19 Baseline models © 2009 Bahill 18 5/31/2014

20 Black box --- white box The requirements model is often called a black box model, because we see only input and output behavior, not the inner workings of the black box. The analysis model is often called a grey box model, because we have hints of what is inside the box. The design model is often called a white box model, because we not only see the components inside the box, but we also design them. © 2009 Bahill 19 5/31/2014

21 Design should be use case driven A use case is an abstraction of required functions of a system. A use case produces an observable result of value to the user. Each use case describes a sequence of interactions between one or more actors and the system. © 2009 Bahill 20 5/31/2014

22 The slots of a use case © 2009 Bahill 21 Name:*Precondition: Iteration:Trigger: Brief description:Main Success Scenario: Added value:*Alternate Flows: Goal: *Postcondition: Level:Specific Requirements Scope: Functional Requirements: Primary actor: Nonfunctional Requirements: Supporting actor:Author/owner: Frequency:Date: My template for writing use cases is available at 5/31/2014

23 Use cases Describe required functional behavior Identify requirements Provide test cases Give a skeleton for the users manual May be used by sales and marketing 5/31/2014 © 2009 Bahill 22

24 Case study Design a heating, ventilation and air conditioning (HVAC) system for a typical Tucson family house Lets start in the first iteration of the Inception life- cycle phase and explore the business model. © 2009 Bahill 23 5/31/2014

25 HVAC Business use case 1 Name:* Sell HVAC Equipment and Services Name:* Buy and Operate HVAC System Iteration: 1.0 Brief description: Our company sells Heating, Ventilation and Air Conditioning (HVAC) equipment and services to home owners in Tucson. Added value: The house is comfortable, therefore Home Owner is more productive. Scope: A Tucson house Primary actor:* Home Owner or BICS Supporting actors: HVAC Company Precondition: *Home Owner owns a house in Tucson. © 2009 Bahill 24 5/31/2014

26 HVAC Business use case 2 Main Success Scenario: 1. Home Owner buys an air conditioning system on average every ten years. 2. Home Owner buys a heating system on average every 15 years. 3. Home Owner performs maintenance on the air conditioner in May. 4. Home Owner performs maintenance on the heater in November. © 2009 Bahill 25 5/31/2014

27 HVAC Business use case 3 Unanchored Alternate Flow: Home Owner performs repairs on the HVAC system whenever a component fails. Specific Requirements Functional Requirement: Home Owner shall buy, maintain and repair an HVAC system [from HVAC Business use case].* Nonfunctional Requirement: Home Owner desires maintenance services when scheduled and repair services within 48 hours [from customer interviews]. © 2009 Bahill 26 5/31/2014

28 HVAC Business use case 4 Rules: Rule1: There are 200,000 houses in the Tucson area. Rule2: Each maintenance service costs about $70. Rule3: Each repair service costs about $300. Author: Terry Bahill Date: September 6, 2005 © 2009 Bahill 27 5/31/2014

29 Work products of the business model A context model (an object or data flow diagram) showing how the system fits into its overall environment High-level business requirements (essential use cases) A glossary A domain model (a class diagram) depicting major business classes A business process model (an activity diagram) depicting a high-level overview of the business process © 2009 Bahill 28 5/31/2014

30 Requirements model In the second iteration of the Inception phase we investigate the requirements model. *Start with a skeleton of the highest priority (highest- risk) subsystems. © 2009 Bahill 29 5/31/2014

31 Regulate Temperature use case 1 Iteration: 2.0 Brief description: Maintain the room temperature (roomTemp) between lowerThreshold (see Rule1) and upperThreshold (see Rule2) degrees Fahrenheit using a Heater and an Air Conditioner (AC). Added value: The House is comfortable, therefore Home Owner is more productive. Scope: An HVAC controller for a Tucson house Primary actor: Home Owner Supporting actors: Heater and Air Conditioner Precondition: The system is turned on and the roomTemp is between lowerThreshold and upperThreshold. © 2009 Bahill 30 5/31/2014

32 Regulate Temperature use case 2 Main Success Scenario: 1. The system senses roomTemp. 2a. The roomTemp exceeds upperThreshold. 3. The system turns on the Air Conditioner. 4. The roomTemp drops below upperThreshold. 5. The system turns off the AC [repeat at step 1]. Anchored Alternate Flow: 2b. The roomTemp drops below lowerThreshold. 2b1. The system turns on the Heater. 2b2. The roomTemp exceeds lowerThreshold. 2b3. The system turns off the Heater [repeat at step 1]. © 2009 Bahill 31 5/31/2014

33 Regulate Temperature use case 3 Specific Requirements Functional Requirements: 1. The system shall be capable of turning the AC on and off [from Regulate Temperature use case, steps 3 and 5]. 2. The system shall be capable of turning the Heater on and off [from Regulate Temperature use case, steps 2b1 and 2b3]. 3. The system shall be capable of sensing room temperature [from Regulate Temperature use case, step 1]. Rules: Rule1: lowerThreshold default value is 70 degrees F. Rule2: upperThreshold default value is 73 degrees F. Author: Terry Bahill Date: September 2, 2005* © 2009 Bahill 32 5/31/2014

34 Display System Status use case 1 Name: Display System Status Brief description: Indicate the health of the system Added value: Home Owner knows if the system is working properly. Scope: An HVAC controller for a Tucson house Primary actor: Home Owner Frequency: Typically once a day Main Success Scenario: 1. Home Owner asks the system for its status. 2. Each component in the system reports its status to the Controller. 3. The system accepts this information and updates the System Status display. 4. Home Owner observes the System Status [exit use case]. © 2009 Bahill 33 5/31/2014

35 Display System Status use case 2 Alternate flows go here. Specific Requirements Functional Requirements: 1. Each component shall have the capability to report its status to the Controller [from Display System Status use case, step 2]. 2. The system shall be capable of displaying System Status [from Display System Status use case, step 3]. Author: Terry Bahill Date: July 20, 2005 © 2009 Bahill 34 5/31/2014

36 Use-case diagram* © 2009 Bahill 35 5/31/2014

37 Work products of the requirements model System requirements specification (SRS) Requirements traceability Interface requirements specification Operation concept description Technical performance measures High-priority, high-risk use case models Alternative concepts Preliminary risk analysis Incipient architectural description Glossary © 2009 Bahill 36 5/31/2014

38 Other parts of the requirements model Candidate architecture Alternative concepts* Glossary Risk analysis Capacity Expense Disturbance* Business case AC $7/day Heater $3/day © 2009 Bahill 37 5/31/2014

39 © 2009 Bahill 38 5/31/2014

40 Model mapping We must create mappings to transition between models. A few slides are available at MappingsBetweenModels © 2009 Bahill 39 5/31/2014

41 Analysis model In the first iteration of the Elaboration phase we create the analysis model. Start with the skeleton use cases derived in the requirements model. Add muscle to those skeletons Create more skeleton use cases. Start to develop the classes. Accommodate the newly discovered requirement that the system should not continuously cycle on and off. © 2009 Bahill 40 5/31/2014

42 Cool House use case Iteration: 2.0 Brief description: When it is hot outside, use an Air Conditioner (AC) to maintain the room temperature (roomTemp) between ACLowerLimit and ACUpperLimit degrees Fahrenheit. Added value: The House is comfortable, therefore Home Owner is more productive. Scope: An HVAC controller for a Tucson house Primary actor: Home Owner Supporting actor: Air Conditioner Frequency: The system operates continuously. Precondition: Home Owner has turned on the cooling system and the roomTemp is between ACLowerLimit and ACUpperLimit. Main Success Scenario: … etc. © 2009 Bahill 41 5/31/2014

43 © 2009 Bahill 42 5/31/2014

44 Heat House use case 1 Brief description: When it is cold outside maintain the roomTemp between heaterLowerLimit (see Rule2) and heaterUpperLimit (see Rule3) degrees Fahrenheit using a Heater. Added value:* The house is comfortable, therefore Home Owner is more productive. Goal:* Maintain house at a comfortable temperature Scope: An HVAC controller for a Tucson house Primary actor: Home Owner Supporting actor: Heater Frequency: The system operates continuously. Precondition: The heating system is on and the roomTemp is between heaterLowerLimit and heaterUpperLimit. © 2009 Bahill 43 5/31/2014

45 Heat House use case 2 Main Success Scenario: 1. The system is sensing roomTemp. 2. The roomTemp falls below heaterLowerLimit. 3. The system turns on the Heater [in accordance with Rule1]. 4. The roomTemp rises to heaterUpperLimit. 5. The system turns off the Heater [Rule1] [go to step 1]. Unanchored Alternate Flow: 1. Home Owner smells gas.* 2. Home Owner turns off Heater [exit use case]. Specific Requirements Functional Requirements: 1. The system shall turn the Heater on and off [from steps 3 and 5 of the Heat House use case]. 2. The system shall sense room temperature [from step 1 of the Heat House use case]. © 2009 Bahill 44 5/31/2014

46 Heat House use case 3 * Nonfunctional performance requirement: On-off cycles should last at least 15 minutes [from interview with Chief Systems Engineer]. Rules: Rule1: When the Heater is on, turn the Fan on. When the Heater is off, turn the Fan off. Rule2: heaterLowerLimit default value is 70 degrees F. Rule3: heaterUpperLimit default value is 71 degrees F. Author/owner: Terry Bahill Date: September 2, 2005 © 2009 Bahill 45 5/31/2014

47 Display System Status use case 1 Iteration: 2.0 Brief description: The system shall monitor the health of each object in the system and display the status of the complete system. The display could be a simple go/no-go or it might be more sophisticated. Added value: Home Owner knows if the system is working properly. Scope: An HVAC controller for a Tucson house Primary actor: Home Owner Frequency: The system shall display system status continuously. Main Success Scenario: 1. The Fan reports status to the Controller. 2. The Air Conditioner reports status to the Controller. 3. The Heater reports status to the Controller. © 2009 Bahill 46 5/31/2014

48 Display System Status use case 2 4. The Thermostat reports status to the Controller. 5. The Controller computes the System Status and sends results to the Display. 6. The Displays shows the System Status. 7. Home Owner observes the System Status periodically [repeat at step 1]. Specific Requirements Functional Requirements: 1. Each component shall report its status to the Controller [from steps 1 to 5 of the Display System Status use case]. 2. The system shall display System Status. Nonfunctional requirement: System Status shall be displayed within 2 seconds of request. Author/owner: Terry Bahill Date: September 2, 2005 © 2009 Bahill 47 5/31/2014

49 Analysis model use-case diagram © 2009 Bahill 48 5/31/2014

50 Communication diagram © 2009 Bahill 49 5/31/2014

51 Class diagram © 2009 Bahill 50 5/31/2014

52 Work products of the analysis model 1 Elaborations of entities of requirements model Analysis packages composed of high-level use cases analysis classes interface definitions Use case realizations with textual descriptions class diagrams communication diagrams Special Requirements sections containing formal shall statement functional requirements identification of the nonfunctional requirements © 2009 Bahill 51 5/31/2014

53 Work products of the analysis model 2 Supplemental entities functional flow block diagrams object (context) diagrams The analysis model is a static model, because it shows objects and their interrelationships, but not time dependent dynamics. © 2009 Bahill 52 5/31/2014

54 Other parts of the analysis model Candidate architecture Piggyback system* Alternatives Glossary Risk analysis Business case Lessons learned © 2009 Bahill 53 5/31/2014

55 Design model In (roughly) the second iteration of the Elaboration phase we create the design model. Add muscle to the skeleton use cases of the analysis model. Develop the muscularized skeletons of the analysis model. Create more skeleton use cases. Develop the classes. Accommodate the new piggyback architecture. © 2009 Bahill 54 5/31/2014

56 Cool House use case Brief description: When it is hot outside maintain the room temperature (roomTemp) between coolerLowerLimit and coolerUpperLimit degrees Fahrenheit using a Cooler (either an Evaporative Cooler or an Air Conditioner). Scope: An HVAC controller for a Tucson house Level: Low Primary actor: Home Owner Supporting actor: Cooler Frequency: The system operates continuously. Precondition: Home Owner has selected the Cooler, systemStatus is ready, systemState is Cooler Off, and the roomTemp is below coolerUpperLimit. Trigger: The roomTemp exceeds coolerUpperLimit. Main Success Scenario: … etc. © 2009 Bahill 55 5/31/2014

57 Heat House use case 1 Brief description: When it is cold outside maintain the roomTemp between heaterLowerLimit and heaterUpperLimit degrees Fahrenheit using a Heater. Scope: An HVAC controller for a Tucson house Level: Low Primary actor: Home Owner Supporting actor: Heater Frequency: The system operates continuously. Precondition: Home Owner has selected the Heater, systemStatus is ready, system state is Heater Off, and roomTemp is above heaterLowerLimit. Trigger: The roomTemp falls below heaterLowerLimit. Main Success Scenario: 1. The system turns on the Heater [in accordance with Rule1]. © 2009 Bahill 56 5/31/2014

58 Heat House use case 2 2. The roomTemp rises to heaterUpperLimit. 3. The system turns off the Heater [Rule1] [exit use case]. Unanchored Alternate Flow: 1. Home Owner smells gas. 2. Home Owner turns off Heater [exit use case]. Postcondition: Heater is off Functional requirements… Nonfunctional performance requirement: On-off cycles should last at least 15 minutes. Rules: Rule1: When the Heater is on, turn the Fan on. When the Heater is off, turn the Fan off. Rule2: heaterLowerLimit default value is 70 degrees F. Rule3: heaterUpperLimit default value is 71 degrees F. Author/owner: Terry Bahill Date: January 31, 2002 © 2009 Bahill 57 5/31/2014

59 Display System Status use case 1 Brief description: The system shall monitor the health of each object in the system and display the status of the complete system. This display should indicate ready or fault. Scope: An HVAC controller for a Tucson house Level: Medium Primary actor: Home Owner Frequency: The systemStatus shall be computed periodically (e.g. every minute) or it may be event driven (e.g. on each state transition). The system shall display the systemStatus continuously. Main Success Scenario: 1. The Fan Interface executes its Built-in Self-Test (BiST) for the Fan and the Fan Interface and reports the results to the Controller. 2. The Air Conditioner Interface executes its BiST and reports the results to the Controller. © 2009 Bahill 58 5/31/2014

60 Display System Status use case 2 3. The Evaporative Cooler Interface executes its BiST and reports the results to the Controller. 4. The Heater Interface executes its BiST and reports the results to the Controller. 5. The Thermostat executes its BiST and reports the results to the Controller. 6. The Controller executes its BiST and computes the systemStatus. 7. The Controller sends the systemStatus to the Thermostat. 8. The Thermostat displays the systemStatus. 9. Home Owner observes the systemStatus periodically [repeat at step 1]. Specific requirements … Author: Terry Bahill Date: January 31, 2002 © 2009 Bahill 59 5/31/2014

61 Set Temperature Limits use case Brief description: Home Owner changes the HVAC temperature limits Scope: An HVAC controller for a Tucson house Level: Medium Primary actor: Home Owner Frequency: Daily Precondition: Home Owner has selected the equipment and systemStatus is ready. Main Success Scenario: 1. Home Owner sets coolerUpperLimit. 2. Home Owner sets coolerLowerLimit. 3. Home Owner sets heaterUpperLimit. 4. Home Owner sets heaterLowerLimit. 5. Exit Set Temperature Limits use case. Postcondition: All four limits are set. Author/owner: Terry Bahill Date: January 31, 2002 © 2009 Bahill 60 5/31/2014

62 Configure Equipment use case 1 Brief description: Home Owner chooses which equipment to turn on: heater, air conditioner, or evaporative cooler. Added value: Necessary for operation and maintenance Scope: An HVAC controller for a Tucson house Level: High Assumption: If the Home Owner wants heating and cooling on the same day, then he or she will switch back and forth manually. Primary actor: Home Owner Frequency: Once a year Precondition: systemStatus* is ready. © 2009 Bahill 61 5/31/2014

63 Configure Equipment use case 2 Main Success Scenario: 1. March 21 Home Owner turns Heater off and Evaporative Cooler on. 2. June 21 Home Owner turns Evaporative Cooler off and Air Conditioner on. 3. September 21 Home Owner turns Air Conditioner off and Evaporative Cooler on. 4. November 21 Home Owner turns Evaporative Cooler off and Heater on [cycle back to step 1]. Postcondition: One of the three systems is active. Specific requirements … Author/owner: Terry Bahill Date: January 31, 2002 © 2009 Bahill 62 5/31/2014

64 Design model use-case diagram* © 2009 Bahill 63 5/31/2014

65 Sequence diagram for Heat House © 2009 Bahill 64 5/31/2014

66 Sequence diagram for the alternate flow Owner smells gas of Heat House use case © 2009 Bahill 65 5/31/2014

67 Design model class diagram © 2009 Bahill 66 5/31/2014

68 State machine diagram for HVAC Controller © 2009 Bahill 67 5/31/2014

69 The design model 1 May be 5 times bigger than analysis model Elaborates entities of the analysis model Contains subsystems composed of design classes interfaces use case realizations textual descriptions class diagrams sequence diagrams Special Requirements sections contain formal shall statement functional requirements nonfunctional requirements © 2009 Bahill 68 5/31/2014

70 The design model 2 Supplemental entities state machine diagrams deployment diagrams Is a dynamic model because, using sequence diagrams and state machine diagrams, it shows the timing of the functions being performed and the messages being passed © 2009 Bahill 69 5/31/2014

71 COTS We have just been given a new requirement: everything should be commercial off the shelf (COTS). This greatly simplifies the models, as is shown in the following implementation specification for the evaporative cooler subsystem. © 2009 Bahill 70 5/31/2014

72 Implementation specification Aerocool PH6800A 117-volt cooler with 1 hp motor and Phoenix Pro-Stat thermostat Cooler to thermostat interface: 66 foot 6 conductor cable. Do not cut or splice. Cooler to duct interface : barometric damper 20" by 20", bottom of duct is 22" off the roof Infrastructure: 117-volt, 15-amp receptacle and a quarter-inch copper water tube Cost: $1890 Schedule: Install March 18, 2003 Performance: 6800 cfm Test: If Tout < 100 – 0.4 humidity then Tin < 70 F © 2009 Bahill 71 5/31/2014

73 The implementation model May be 10 times bigger than design model Elaborates entities of the design model Contains components interfaces integration build plan unit test cases and procedures Supplemental entities dependencies between components © 2009 Bahill 72 5/31/2014

74 Activity diagram The following activity diagram is Figure 12.3 of Booch, Jacobson and Rumbaugh (1999). © 2009 Bahill 73 5/31/2014

75 Workflows © 2009 Bahill 74 5/31/2014

76 Verification 1 There are three common techniques for testing systems test vectors (input/output behavior) system experiments (state-based) instances of use cases (scenario-based) State-based testing is the best. © 2009 Bahill 75 5/31/2014

77 Test vectors 1 Heating System Test Vector Inputs Normal heaterUpperLimit = 71 F and heaterLowerLimit = 70 F Extremes heaterUpperLimit = 80 F and heaterLowerLimit = 78 F heaterUpperLimit = 36 F and heaterLowerLimit = 34 F Mistakes heaterUpperLimit = 70 F and heaterLowerLimit = 72 F © 2009 Bahill 76 5/31/2014

78 Test vectors 2* © 2009 Bahill 77 5/31/2014

79 Test vectors 3 Test Procedure for the Heater 1. Choose a cold day, e.g. outside temperature is less than 60 F. 2. Set Heater On/Off switch to On. 3. Set heaterUpperLimit and heaterLowerLimit according to the Test Vector [ ]. 4. Observe room temperature for one hour. 5. If it goes outside the heaterLimits, record a defect. © 2009 Bahill 78 5/31/2014

80 Test using system experiments* © 2009 Bahill 79 The system passes this test only if it produces the above output trajectory 5/31/2014

81 Test using use-case scenarios* Use Case Name: Heat House Scenario: 1. Pat Harris starts this scenario on January 8 with the outside temperature = 40 F, the heater off, systemStatus = ready, the roomTemp = 70.5 F and the heaterLowerLimit and heaterUpperLimit at their default values. 2. The roomTemp falls below 70 F. 3. The system turns on the Heater and the Fan. 4. The roomTemp rises to 71 F. 5. The system turns off the Heater and the Fan. 6. To pass this test, the roomTemp must remain greater than heaterLowerLimit for the next 15 minutes, [end of test]. © 2009 Bahill 80 5/31/2014

82 Verification 2 Test vectors: Select a variety of inputs, some normal, some extreme and some mistakes. For each input vector, describe the acceptable output vector. Write a test procedure that will invoke each test vector. Describe conditions need to pass or fail the test. State-based system experiments. Define an initial state for time equal zero. Create an input trajectory. Show the state trajectory that is required in order to pass the test. Scenarios. Select a use case that has already been written for the system. Instantiate it with particular people, places and conditions. Describe behavior that is necessary in order to pass the test. Run the system with this instantiation. © 2009 Bahill 81 5/31/2014

83 Operations phase The operations model (usually a computer simulation) should be built from the implementation model. It should reflect the structure of the system as it was actually built. It will be used to manage and improve the operational system. It will be updated anytime the operational system is changed. Most importantly, it will used to help with retirement of the system. Another UML tool called an activity diagram will be used to show the workflows, that is who does which tasks during the operations phase. © 2009 Bahill 82 5/31/2014

84 Levels 1 Most systems are impossible to study in their entirety, but they are made up of hierarchies of smaller subsystem that can be studied. User level - thermostat, controller, heater, air conditioner and evaporative cooler. Low level - colors of the wires and electrical voltages. High level - brown outs or heating of the city caused by operation of a million air conditioners. Consider use cases one level above or below, but not use cases two levels above or below. © 2009 Bahill 83 5/31/2014

85 Levels 2 © 2009 Bahill 84 5/31/2014

86 Levels 3 © 2009 Bahill 85 5/31/2014

87 Activity diagram © 2009 Bahill 86 5/31/2014

88 SysML SysML is the systems engineering extensions to the UML SysML has diagrams for showing the hierarchical relationships of requirements SysML has diagrams for representing equations SysML uses activity diagrams much like enhanced functional flow block diagrams © 2009 Bahill 87 5/31/2014

89 Challenges for old engineers Changing from functional thinking to object orientation Progressing from use cases to classes Changing from waterfall processes to incremental iterations Discovering classes that are not based on physical objects, e.g. an algorithm for selecting equipment. © 2009 Bahill 88 5/31/2014

90 Links between UML things © 2009 Bahill 89 5/31/2014

91 © 2009 Bahill 90 5/31/2014


Download ppt "The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 (520) 621-6561"

Similar presentations


Ads by Google