SE chapters 6-7

390 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
390
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SE chapters 6-7

  1. 1. Chapter 6 System Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
  2. 2. System Engineering <ul><li>Elements of a computer-based system </li></ul><ul><ul><li>Software </li></ul></ul><ul><ul><li>Hardware </li></ul></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Procedures </li></ul></ul><ul><li>Systems </li></ul><ul><ul><li>A hierarchy of macro-elements </li></ul></ul>
  3. 3. The Hierarchy
  4. 4. System Modeling <ul><li>define the processes that serve the needs of the view under consideration. </li></ul><ul><li>represent the behavior of the processes and the assumptions on which the behavior is based. </li></ul><ul><li>explicitly define both exogenous and endogenous input to the model. </li></ul><ul><ul><li>exogenous inputs link one constituent of a given view with other constituents at the same level of other levels; endogenous input links individual components of a constituent at a particular view. </li></ul></ul><ul><li>represent all linkages (including output) that will enable the engineer to better understand the view. </li></ul>
  5. 5. Business Process Engineering <ul><li>uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise </li></ul><ul><li>focuses first on the enterprise and then on the business area </li></ul><ul><li>creates enterprise models, data models and process models </li></ul><ul><li>creates a framework for better information management distribution, and control </li></ul>
  6. 6. System Architectures <ul><li>Three different architectures must be analyzed and designed within the context of business objectives and goals: </li></ul><ul><ul><ul><li>data architecture </li></ul></ul></ul><ul><ul><ul><li>applications architecture </li></ul></ul></ul><ul><ul><ul><li>technology infrastructure </li></ul></ul></ul><ul><li>data architecture provides a framework for the information needs of a business or business function </li></ul><ul><li>application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose </li></ul><ul><li>technology infrastructure provides the foundation for the data and application architectures </li></ul>
  7. 7. The BPE Hierarchy <ul><li>Information strategy planning (ISP) </li></ul><ul><ul><li>strategic goals defined </li></ul></ul><ul><ul><li>success factors/business rules identified </li></ul></ul><ul><ul><li>enterprise model created </li></ul></ul><ul><li>Business area analysis (BAA) </li></ul><ul><ul><li>processes/services modeled </li></ul></ul><ul><ul><li>interrelationships of processes and data </li></ul></ul><ul><li>Application Engineering </li></ul><ul><ul><li>a.k.a ... software engineering </li></ul></ul><ul><ul><li>modeling applications/procedures that address (BAA) and constraints of ISP </li></ul></ul><ul><li>Construction and delivery </li></ul><ul><ul><li>using CASE and 4GTs, testing </li></ul></ul>
  8. 8. Information Strategy Planning <ul><li>Management issues </li></ul><ul><ul><li>define strategic business goals/objectives </li></ul></ul><ul><ul><li>isolate critical success factors </li></ul></ul><ul><ul><li>conduct analysis of technology impact </li></ul></ul><ul><ul><li>perform analysis of strategic systems </li></ul></ul><ul><li>Technical issues </li></ul><ul><ul><li>create a top-level data model </li></ul></ul><ul><ul><li>cluster by business/organizational area </li></ul></ul><ul><ul><li>refine model and clustering </li></ul></ul>
  9. 9. Defining Objectives and Goals <ul><li>Objective —general statement of direction </li></ul><ul><li>Goal —defines measurable objective: “reduce manufactured cost of our product” </li></ul><ul><ul><li>Subgoals : </li></ul></ul><ul><ul><ul><li>decrease reject rate by 20% in first 6 months </li></ul></ul></ul><ul><ul><ul><li>gain 10% price concessions from suppliers </li></ul></ul></ul><ul><ul><ul><li>re-engineer 30% of components for ease of manufacture during first year </li></ul></ul></ul><ul><li>Objectives tend to be strategic while goals tend to be tactical </li></ul>
  10. 10. Business Area Analysis <ul><li>define “naturally cohesive groupings of business functions and data” (Martin) </li></ul><ul><li>perform many of the same activities as ISP, but narrow scope to individual business area </li></ul><ul><li>identify existing (old) information systems / determine compatibility with new ISP model </li></ul><ul><ul><li>define systems that are problematic </li></ul></ul><ul><ul><li>defining systems that are incompatible with new information model </li></ul></ul><ul><ul><li>begin to establish re-engineering priorities </li></ul></ul>
  11. 11. The BAA Process sales acct manufacturing QC eng’ring distribution admin. Data Model Process Decomposition Diagram Matrices e.g., entity/process matrix Process Flow Models
  12. 12. Product Engineering
  13. 13. Product Architecture Template
  14. 14. Architecture Flow Diagram
  15. 15. System Modeling with UML <ul><li>Deployment diagrams </li></ul><ul><ul><li>Each 3-D box depicts a hardware element that is part of the physical architecture of the system </li></ul></ul><ul><li>Activity diagrams </li></ul><ul><ul><li>Represent procedural aspects of a system element </li></ul></ul><ul><li>Class diagrams </li></ul><ul><ul><li>Represent system level elements in terms of the data that describe the element and the operations that manipulate the data </li></ul></ul><ul><li>These and other UML models will be discussed later </li></ul>
  16. 16. Deployment Diagram
  17. 17. Activity Diagram
  18. 18. Class Diagram
  19. 19. System Engineering <ul><li>A system view of a product encompasses more than just the software. </li></ul><ul><li>Elements of a computer-based system: </li></ul><ul><ul><li>Software </li></ul></ul><ul><ul><li>Hardware </li></ul></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Procedures </li></ul></ul><ul><ul><li>Other computer-based systems </li></ul></ul>
  20. 20. Chapter 7 Requirements Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
  21. 21. Requirements Engineering <ul><li>Inception —Establish a basic understanding of the problem and the nature of the solution. </li></ul><ul><li>Elicitation —Draw out the requirements from stakeholders. </li></ul><ul><li>Elaboration —Create an analysis model that represents information, functional, and behavioral aspects of the requirements. </li></ul><ul><li>Negotiation —Agree on a deliverable system that is realistic for developers and customers. </li></ul><ul><li>Specification —Describe the requirements formally or informally. </li></ul><ul><li>Validation —Review the requirement specification for errors, ambiguities, omissions, and conflicts. </li></ul><ul><li>Requirements management —Manage changing requirements. </li></ul>
  22. 22. Inception <ul><li>Ask “context-free” questions </li></ul><ul><ul><li>Who is behind the request for this work? </li></ul></ul><ul><ul><li>Who will use the solution (product/system)? </li></ul></ul><ul><ul><li>What will be the economic benefits? </li></ul></ul><ul><ul><li>How would you characterize “good” output from the system? </li></ul></ul><ul><ul><li>What problems does this solution address? </li></ul></ul><ul><ul><li>What environment will the product be used in? </li></ul></ul><ul><ul><li>Are you the right person to answer these questions? </li></ul></ul><ul><ul><li>Are these question relevant? </li></ul></ul><ul><ul><li>Can anyone else provide additional information? </li></ul></ul><ul><ul><li>Should I be asking you anything else? </li></ul></ul>
  23. 23. Getting Requirements Right <ul><li>“ The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” </li></ul><ul><li>— Fred Brooks </li></ul><ul><li>“ The seeds of major software disasters are usually sown within the first three months of commencing the software project.” </li></ul><ul><li>— Capers Jones </li></ul><ul><li>“ We spend a lot of time—the majority of project effort—not implementing or testing, but trying to decide what to build.” </li></ul><ul><li>— Brian Lawrence </li></ul>
  24. 24. Eliciting Requirements <ul><li>Why is it so difficult to clearly understand what the customer wants? </li></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><ul><li>The boundary of the system is ill-defined. </li></ul></ul></ul><ul><ul><ul><li>Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives. </li></ul></ul></ul><ul><ul><li>Understanding </li></ul></ul><ul><ul><ul><li>Customers are not completely sure of what is needed. </li></ul></ul></ul><ul><ul><ul><li>Customers have a poor understanding of the capabilities and limitations of the computing environment. </li></ul></ul></ul><ul><ul><ul><li>Customers don’t have a full understanding of their problem domain. </li></ul></ul></ul><ul><ul><ul><li>Customers have trouble communicating needs to the system engineer. </li></ul></ul></ul><ul><ul><ul><li>Customers omit detail that is believed to be obvious. </li></ul></ul></ul><ul><ul><ul><li>Customers specify requirements that conflict with other requirements. </li></ul></ul></ul><ul><ul><ul><li>Customers specify requirements that are ambiguous or untestable. </li></ul></ul></ul><ul><ul><li>Volatility </li></ul></ul><ul><ul><ul><li>Requirements change over time. </li></ul></ul></ul>
  25. 25. Collaborative Requirements Gathering <ul><li>Meetings are attended by all interested stakeholders. </li></ul><ul><li>Rules established for preparation and participation. </li></ul><ul><li>Agenda should be formal enough to cover all important points, but informal enough to encourage the free flow of ideas. </li></ul><ul><li>A facilitator controls the meeting. </li></ul><ul><li>A definition mechanism (blackboard, flip charts, etc.) is used. </li></ul><ul><li>During the meeting: </li></ul><ul><ul><li>The problem is identified. </li></ul></ul><ul><ul><li>Elements of the solution are proposed. </li></ul></ul><ul><ul><li>Different approaches are negotiated. </li></ul></ul><ul><ul><li>A preliminary set of solution requirements are obtained. </li></ul></ul><ul><ul><li>The atmosphere is collaborative and non-threatening. </li></ul></ul>
  26. 26. Quality Function Deployment <ul><li>Function deployment determines the “value” (to the customer) of each function required of the system. </li></ul><ul><li>Information deployment identifies data objects and events. </li></ul><ul><li>Task deployment examines the behavior of the system. </li></ul><ul><li>Value analysis determines the priority of requirements. </li></ul>
  27. 27. Elicitation Work Products <ul><li>Statement of need and feasibility . </li></ul><ul><li>Statement of scope . </li></ul><ul><li>List of participants in requirements elicitation. </li></ul><ul><li>Description of the system’s technical environment . </li></ul><ul><li>List of requirements and associated domain constraints . </li></ul><ul><li>List of usage scenarios . </li></ul><ul><li>Any prototypes developed to refine requirements . </li></ul>
  28. 28. Use-Cases <ul><li>A use-case scenario is a story about how someone or something external to the software (known as an actor ) interacts with the system. </li></ul><ul><li>Each scenario answers the following questions: </li></ul><ul><li>Who is the primary actor , the secondary actor(s)? </li></ul><ul><ul><li>What are the actor’s goals ? </li></ul></ul><ul><ul><li>What preconditions should exist before the story begins? </li></ul></ul><ul><ul><li>What main tasks or functions are performed by the actor? </li></ul></ul><ul><ul><li>What exceptions might be considered as the story is described? </li></ul></ul><ul><ul><li>What variations in the actor’s interaction are possible? </li></ul></ul><ul><ul><li>What system information will the actor acquire, produce, or change? </li></ul></ul><ul><ul><li>Will the actor have to inform the system about changes in the external environment? </li></ul></ul><ul><ul><li>What information does the actor desire from the system ? </li></ul></ul><ul><ul><li>Does the actor wish to be informed about unexpected changes? </li></ul></ul>
  29. 29. Elements of the Analysis Model <ul><li>Scenario-based elements </li></ul><ul><ul><li>Use-case—How external actors interact with the system (use-case diagrams; detailed templates) </li></ul></ul><ul><ul><li>Functional—How software functions are processed in the system (flow charts; activity diagrams) </li></ul></ul><ul><li>Class-based elements </li></ul><ul><ul><li>The various system objects (obtained from scenarios) including their attributes and functions (class diagram) </li></ul></ul><ul><li>Behavioral elements </li></ul><ul><ul><li>How the system behaves in response to different events (state diagram) </li></ul></ul><ul><li>Flow-oriented elements </li></ul><ul><ul><li>How information is transformed as if flows through the system (data flow diagram) </li></ul></ul>
  30. 30. Use-Case Diagram
  31. 31. Activity Diagram for RE
  32. 32. Class Diagram
  33. 33. State Diagram
  34. 34. Analysis Patterns <ul><ul><li>Pattern name: Captures the essence of the pattern. </li></ul></ul><ul><ul><li>Intent: What the pattern accomplishes or represents. </li></ul></ul><ul><ul><li>Motivation: A scenario that illustrates how the pattern solves a problem. </li></ul></ul><ul><ul><li>Forces and context: External issues (forces) that affect how the pattern is used, and external issues resolved when the pattern is applied. </li></ul></ul><ul><ul><li>Solution: How the pattern is applied to solve the problem; emphasizes structural and behavioral issues. </li></ul></ul><ul><ul><li>Consequences : What happens when the pattern is applied; what trade-offs exist during its application. </li></ul></ul><ul><ul><li>Design : How the pattern can be achieved via known design patterns. </li></ul></ul><ul><ul><li>Known uses : Examples of uses within actual systems. </li></ul></ul><ul><ul><li>Related patterns : Patterns related to the named pattern because </li></ul></ul><ul><ul><ul><li>they are commonly used with the named pattern; </li></ul></ul></ul><ul><ul><ul><li>they are structurally similar to the named pattern; </li></ul></ul></ul><ul><ul><ul><li>they are a variation of the named pattern. </li></ul></ul></ul>
  35. 35. Negotiating Requirements <ul><li>Identify the key stakeholders </li></ul><ul><ul><li>These are the people who will be involved in the negotiation </li></ul></ul><ul><li>Determine each of the stakeholders “win conditions” </li></ul><ul><ul><li>Win conditions are not always obvious </li></ul></ul><ul><li>Negotiate </li></ul><ul><ul><li>Work toward a set of requirements that lead to “win-win” </li></ul></ul>
  36. 36. Validating Requirements <ul><li>Is each requirement consistent with the objective of the system? </li></ul><ul><li>Have all requirements been specified at the proper level of abstraction ? </li></ul><ul><li>Is the requirement really necessary ? </li></ul><ul><li>Is each requirement bounded and unambiguous ? </li></ul><ul><li>Does each requirement have attribution ? </li></ul><ul><li>Do any requirements conflict with other requirements ? </li></ul><ul><li>Is each requirement achievable in the system’s technical environment ? </li></ul><ul><li>Is each requirement testable , once implemented? </li></ul><ul><li>Does the model reflect the system’s information, function and behavior ? </li></ul><ul><li>Has the model been appropriately “partitioned” ? </li></ul><ul><li>Have appropriate requirements patterns been used? </li></ul>
  37. 37. Example CRG Meeting <ul><li>First CRG meeting of the SafeHome project. </li></ul><ul><ul><li>After Q&A session (inception meeting), stakeholders write a two page product request , which is delivered to those attending the first CRG meeting. </li></ul></ul><ul><ul><li>Attendees are asked to make a rough list of objects , services , constraints , and performance criteria for the product. </li></ul></ul><ul><ul><li>At the meeting, a combined list is created in each topic. </li></ul></ul><ul><ul><li>Subgroups write mini-specifications for each list item. </li></ul></ul><ul><ul><li>Relevant features in mini-specifications are added to the list. </li></ul></ul>
  38. 38. Example CRG Meeting <ul><li>Our research indicates that the market for home management systems is growing at a rate of 40 percent per year. The first SafeHome function we bring to market should be the home security function . Most people are familiar with “alarm systems” so this would be an easy sell. </li></ul><ul><li>The home security function would protect against and/or recognize a variety of undesirable “situations” such as illegal entry , fire , flooding , carbon monoxide levels , and others . It’ll use our wireless sensors to detect each situation, can be programmed by the homeowner , and will automatically telephone a monitoring agency when a situation is detected. </li></ul>
  39. 39. Example CRG Meeting <ul><li>Objects – control panel, smoke detectors, window and door sensors, motion detectors, an alarm, an event (sensor has been activated), a display, a PC, telephone numbers, a telephone call, … </li></ul><ul><li>Services – configuring the system, setting the alarm, monitoring the sensors, dialing the phone, programming the control panel, reading the display, … </li></ul><ul><li>Constraints – System must recognize when sensors are not operating, must be user friendly, must interface directly to a standard phone line, … </li></ul><ul><li>Performance criteria – Sensor event should be recognized within one second, an event priority scheme should be implemented, … </li></ul>
  40. 40. Example CRG Meeting <ul><li>Mini-specification for Control Panel </li></ul><ul><ul><li>The Control Panel is a wall-mounted unit that is approximately 9 x 5 inches in size. The control panel has wireless connectivity to sensors and a PC. User interaction occurs through a keypad containing 12 keys. A 2 x 2 inch LCD display provides user feedback. Software provides interactive prompts, echo, and similar functions. </li></ul></ul>

×