Software Engineering: A Practitioner s s Approach, 6/e Chapter 6 System Engineering copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1 System Engineering! Elements of a computer-based system! Software! Hardware! People! Database! Documentation! Procedures! Systems! A hierarchy of macro-elements 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 2
The Hierarchy 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 3 System Modeling! define the processes that serve the needs of the view under consideration.! represent the behavior of the processes and the assumptions on which the behavior is based.! explicitly define both exogenous and endogenous input to the model.! exogenous inputs link one constituent of a given view with other constituents at the same level or other levels; endogenous input links individual components of a constituent at a particular view.! represent all linkages (including output) that will enable the engineer to better understand the view. 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 4
Business Process Engineering! uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise! focuses first on the enterprise and then on the business area! creates enterprise models, data models and process models! creates a framework for better information management distribution, and control 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 5 System Architectures! Three different architectures must be analyzed and designed within the context of business objectives and goals:! data architecture! applications architecture! technology infrastructure! data architecture provides a framework for the information needs of a business or business function! application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose! technology infrastructure provides the foundation for the data and application architectures 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 6
The BPE Hierarchy! Information strategy planning (ISP)! strategic goals defined! success factors/business rules identified! enterprise model created! Business area analysis (BAA)! processes/services modeled! interrelationships of processes and data! Application Engineering! a.k.a... software engineering! modeling applications/procedures that address (BAA) and constraints of ISP! Construction and delivery! using CASE and 4GTs, testing 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 7 Information Strategy Planning! Management issues! define strategic business goals/objectives! isolate critical success factors! conduct analysis of technology impact! perform analysis of strategic systems! Technical issues! create a top-level data model! cluster by business/organizational area! refine model and clustering 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 8
Defining Objectives and Goals! Objective general statement of direction! Goal defines measurable objective: reduce manufactured cost of our product! Subgoals: " decrease reject rate by 20% in first 6 months " gain 10% price concessions from suppliers " re-engineer 30% of components for ease of manufacture during first year! Objectives tend to be strategic while goals tend to be tactical 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 9 Business Area Analysis! define naturally cohesive groupings of business functions and data (Martin)! perform many of the same activities as ISP, but narrow scope to individual business area! identify existing (old) information systems / determine compatibility with new ISP model! define systems that are problematic! defining systems that are incompatible with new information model! begin to establish re-engineering priorities 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 10
The BAA Process admin. manufacturing sales QC acct distribution eng ring Process Flow Models Data Model Process Decomposition Diagram Matrices e.g., entity/process matrix 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 11 Product Engineering 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 12
CASE and Business Process Engineering: Data oriented Tools Supporting information engineering by James Martin and others. Data is seen as the main resource of the enterprise. Based on data-models defining the basic data units and data relationship for the entire enterprise. Databases and process logic are derived from these models. Information matrices, entity-relationship diagrams (ERD), entity-hierarchy diagrams, process-hierarchy diagrams, dialog-flow diagrams, screen-design, data-structure-diagrams, database-generators, COBOL-generators. Information Engineering Facility (IEF), Information Engineering Workbench (IEW), ER-Designer (ERD). Business Process Engineering 9 Information Engineering Facility (IEF) Enforces top-down planning, analysis, design, and implementation. Primarily used for developing on-line/batch, screen-oriented administrative systems. Supports developing windows-based applications. Strong separation of database and process-logic. Information planning, analysis and design is done on a workstation, after relevant parts of the entire data model has been downloaded from main-frame. Compilation of modules, database generation and code generation takes place on the mainframe. Business Process Engineering 10
Information Engineering Facility II Information strategy planning Business area analysis Business application design Technical design Business Process Engineering 11 IEF - Information planning C = Create R = Read U = Update D = Delete Entity Types Customer Order Order Line Product Part Supplier Warehouse Business Functions Matrices Marketing Customer registration Accept Order Change Order Cancel order R C U D U D Producing Business Process Engineering 12
IEF - Analysis Customer Supplier Supplies Part Places Supplies Consists of Stored in Order Product Is stored in Warehouse Consists of Mentions Order line Entity relationship diagrams Business Process Engineering 13 IEF - Analysis II Running the company Marketing Selling Customer registration Order processing Accept order Change order Cancel order Producing Process hierarchy Business Process Engineering 14
IEF - Analysis III Order request Order inf Order Change Order Orders Accept order Order Product inf Available products Order Cancelled Orders Cancel order Process dependencies Business Process Engineering 15 IEF - Analysis: Process-handling Process: ACCEPT ORDER ACCEPT ORDER IMPORTS: Entity View to_be_ordered_product... EXPORTS: Entity View confirmed order_line... ENTITY ACTIONS:Entity View confirmed order_line... READ to_be_controlled product WITH name EQUAL TO to_be_ordered product name WHEN not found ESCAPE... CREATE confirmed order SET date TO "system date" SET number TO "next free value" ASSOCIATE WITH to_be_controlled customer WHICH places IT ASSOCIATE WITH confirmed order_line WHICH details IT WHEN already exists... MOVE confirmed order TO accepted order, Business Process Engineering 16
IEF - Design: Dialog-flow Menu Accept order Accept order header Accept order lines Accept customer Business Process Engineering 17 IEF - Design: Screen design TRANCODE ORDER PROCESSING MM-DD-YY HH:MM:SS ORDER NUMBER: 9999999 CUSTOMER NUMBER: 9999999 NAME: XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XX XXXXXXXXX XXXXXXXXXXXXXXXX ORDER DATE: MM-DD-YY STATE: XX LINE PRODUCT DESCRIPTION QTY UN UNIT PRICE 999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXX 9999 XX $,$$$,$$9.99 999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXX 9999 XX $,$$$,$$9.99 999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXX 9999 XX $,$$$,$$9.99 999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXX 9999 XX $,$$$,$$9.99 <<<ERR>>> <<<ERR>>> <<<ERR>>> <<<ERR>>> <<<ERR>>> <<<ERR>>> <<<ERR>>> <<<ERR>>> <<<PFK>>> <<<PFK>>> <<<PFK>>> <<<PFK>>> <<<PFK>>> <<<PFK>>> <<<PFK>>> <<<PFK>>> Business Process Engineering 18
IEF: From Analysis to Code Information Strategy Planning 1-5 Business Area Analysis A 6-11 Business System Design 17 xxx xxx xxxx x x x x xxx xxx xxxx x x x x A 12-16 Technical Design Database generation generering Kode-generering Code generation Business Process Engineering 19 IEF: From Analysis to Code Information Strategy Planning: 1 Matrix Processor 2 Organizational Hierarchy Diagram 3 Subject Area Diagram 4 Function Hierarchy Diagram 5 Function Dependency Diagram Business System Design: 12 Dialog Flow Diagram 13 Screen Design 14 Prototyping 15 Procedure Action Diagram 16 Structure Chart Business Area Analysis: 6 Entity Relationship Diagram 7 Process Hierarchy Diagram 8 Process Dependency Diagram 9 Process Action Diagram 10 Structure Chart 11 Matrix Processor Technical Design: 17 Data Structure Diagram Business Process Engineering 20
Requirements Engineering Elicitation determining what the customer requires Analysis & negotiation understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Requirements specification building a tangible model of requirements 22 Requirements Engineering System Modeling building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation reviewing the model Management identify, control and track requirements and the changes that will be made to them 23
System Allocation objects processes Allocation performance software hardware people data system components constraints documents procedures support infrastructure Product Engineering 24
Product Architecture Template 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 13 Architecture Flow Diagram 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 14
System Modeling with UML! Deployment diagrams! Each 3-D box depicts a hardware element that is part of the physical architecture of the system! Activity diagrams! Represent procedural aspects of a system element! Class diagrams! Represent system level elements in terms of the data that describe the element and the operations that manipulate the data These and other UML models will be discussed later 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 15 Deployment Diagram CLSS processor Sorting subsystem Operator display Sensor data acquisition subsystem shunt controller Conveyor Pulse tach Bar code reader Shunt actuator 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 16
Activity Diagram start conveyor line read bar code get conveyor speed valid bar code invalid bar code determine bin location set for reject bin send shunt control data get shunt status read bar code get conveyor status produce report entry conveyor stopped conveyor in motion 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 17 Class Diagram class name Box barcode forwardspeed conveyorlocation height width depth weight contents readbarcode() updatespeed() readspeed() updatelocation() readlocation() getdimensions() getweight() checkcontents() attributes note use of capital letter for multi-word attribute names operations (parentheses at end of name indicate the list of attributes that the operation requires) 6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 18
XP User Stories - Exploring with the Customer 30 Gathering Requirements Responsibilities Key Point: The Customer is responsible for the requirements. Programmers help to gather and clarify requirements. Customers especially need help with non-functional requirements and with working out the details of acceptance tests. Documentation User Stories Acceptance Test Cases 31
32 User Stories A short description of the behavior of the system from the point of view of the Customer Use the Customer s terminology without technical jargon One for each major feature in the system Must be written by the users Are used to create time estimates for release planning Replace a large Requirements Document 33
User Stories continued Drive the creation of the acceptance tests: Must be one or more tests to verify that a story has been properly implemented Different than Requirements: Should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. Different than Use Cases: Written by the Customer, not the Programmers, using the Customer s terminology More friendly than formal Use Cases 34 User Stories continued User stories have three crucial aspects: Card Enough information to identify the story Conversation Customer and Programmers discuss the story to elaborate on the details Verbal when possible, but documented when required Confirmation Acceptance tests to confirm that the story has been properly implemented 35
User Story Examples A user wants access to the system, so they find a system administrator, who enters in the user's First Name, Last Name, Middle Initial, E-Mail Address, Username (unique), and Phone Number. Risk: Low Cost: 2 points 36 User Story Examples continued The user must be able to search for a book. Risk: High Cost: (too large!) 37
User Story Examples continued The user must be able to search for a book by Title, and display the results as a list. Risk: Med. Cost: 1 point 38 User Story Examples continued The user must be able to search for a book by Author, and display the results as a list. Risk: Med. Cost: 1 point 39
User Story Examples continued The user must be able to search for a book by ISBN number, and display the results as a list. Risk: Med. Cost: 1 point 40 User Story Examples continued The user must be able to search for a book by Category, and display the results as a list. Risk: Med. Cost: 2 points 41
Acceptance Tests Formal test to determine if a system satisfies its acceptance criteria, i.e. the User Stories At least one Acceptance Test for each Story User story is not complete before succeeding its acceptance tests. 42 Acceptance Tests 2 New tests for each iteration, or the development will report zero progress. A story may have one or many acceptance tests. Should be automated to be run often. The XP team schedules time to fix any failed tests for each iteration. 43
Release Planning Too big Split a Story (Customer) Sort Stories by Value (Customer) Write a Story (Customer) Estimate a Story (Programmer) Declare Velocity (Programmer) Don t know how Spike a Story (Programmer) Choose Scope (Customer) Exploration Planning 44