1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 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. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 15 User Interface Design

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Agenda  The Golden Rules  UI Design  Task Analysis and Modeling  Interface Design Activities  Implementation Tools  Design Evaluation

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Interface Design Easy to use? Easy to understand? Easy to learn?

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Interface Design lack of consistency too much memorization no guidance / help no context sensitivity poor response Arcane/unfriendly Typical Design Errors

6. 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Golden Rules  Place the user in control  Reduce the user’s memory load  Make the interface consistent

7. 7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Place the User in Control Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Provide for flexible interaction. Allow user interaction to be interruptible and undoable. Streamline interaction as skill levels advance and allow the interaction to be customized. Hide technical internals from the casual user. Design for direct interaction with objects that appear on the screen.

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Reduce the User’s Memory Load Reduce demand on short-term memory. Establish meaningful defaults. Define shortcuts that are intuitive. The visual layout of the interface should be based on a real world metaphor. Disclose information in a progressive fashion.

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Make the Interface Consistent Allow the user to put the current task into a meaningful context. Maintain consistency across a family of applications. If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.

10. 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 User Interface Design Models  System perception — the user’s mental image of what the interface is(end-user)  User model — a profile of all end users of the system(human-engineer)  System image — the “presentation” of the system projected by the complete interface(implementers)  Design model — data, architectural, interface and procedural representations of the software(software-engineer)

11. 11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 User Interface Design Process

12. 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Task Analysis and Modeling  All human tasks required to do the job (of the interface) are defined and classified  Objects (to be manipulated) and actions (functions applied to objects) are identified for each task  Tasks are refined iteratively until the job is completely defined

13. 13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Interface Design Activities 1. Establish the goals and intentions for each task. 2. Map each goal/intention to a sequence of specific actions. 3. Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level. 4. Indicate the state of the system, i.e., what does the interface look like at the time that a user scenario is performed? 5. Define control mechanisms, i.e., the objects and actions available to the user to alter the system state. 6. Show how control mechanisms affect the state of the system. 7. Indicate how the user interprets the state of the system from information provided through the interface.

14. 14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Interface Design Issues  Systems response time (time between the point at which user initiates some control action and the time when the system responds)  User help facilities (integrated, context sensitive help versus add-on help)  Error information handling (messages should be non-judgmental, describe problem precisely, and suggest valid solutions)  Command labeling (based on user vocabulary, simple grammar, and have consistent rules for abbreviation)

15. 15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Evaluation Cycle

16. 16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 UI Design Evaluation Criteria  Length and complexity of written interface specification provide an indication of amount of learning required by the users  Number of user tasks and the average number of actions per task provide an indication of interaction time and overall system efficiency  Number of tasks, actions, and system states in the design model provide an indication of the memory load required of system users  Interface style, help facilities, and error handling protocols provide a general indication of system complexity and the degree of acceptance by the users

17. 17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 16 Component-Level Design

18. 18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Agenda  Structured Programming  Graphical Design Notation  Tabular Design Notation  Program Design Languages (PDL)  Comparison of Design Notation

19. 19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Component-Level Design  the closest design activity to coding  the approach:  review the design description for the component  use stepwise refinement to develop algorithm  use structured programming to implement procedural logic  use ‘formal methods’ to prove logic

20. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; take key out; find correct key; find correct key; insert in lock; insert in lock; endif pull/push door move out of way; end repeat

21. 21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Component-Level Design Model  represents the algorithm at a level of detail that can be reviewed for quality  options:  graphical (e.g. flowchart, box diagram)  pseudocode (e.g., PDL)... choice of many  programming language  decision table  conduct walkthrough to assess quality

22. 22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Structured Programming for Procedural Design uses a limited set of logical constructs: sequence conditional — if-then-else, select-case — if-then-else, select-case loops — do-while, repeat until — do-while, repeat until leads to more readable, testable code important for achieving high quality, but not enough

23. 23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 A Structured Procedural Design

24. 24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Program Design Language (PDL) if-then-else if condition x then process a; else process b; endif PDL easy to combine with source code machine readable, no need for graphics input graphics can be generated from PDL enables declaration of data as well as procedure easier to maintain

25. 25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Why Design Language?

26. 26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Notation Assessment Criteria  Modularity (notation supports development of modular software)  Overall simplicity (easy to learn, easy to use, easy to write)  Ease of editing (easy to modify design representation when changes are necessary)  Machine readability (notation can be input directly into a computer-based development system)  Maintainability (maintenance of the configuration usually involves maintenance of the procedural design representation)  Structure enforcement (enforces the use of structured programming constructs)  Automatic processing (allows the designer to verify the correctness and quality of the design)  Data representation (ability to represent local and global data directly)  Logic verification (automatic logic verification improves testing adequacy)  Easily converted to program source code (makes code generation quicker)