Software Design and Engineering using UML

1. Software Design and Engineering using UML January 15, 2000

2. Agenda • Administrivia • Course Overview • Failures - “Design Manifesto” • System Development • Modeling • Analysis - Preliminary Study • Homework 1 & Project

3. Administrivia • Syllabus • Doing it in Seven • Waivers • Presentations

4. Presentations • review of the assigned chapter(s) • review of the profile at the end of the chapter (if appropriate) • example of a "well designed" web site or software package • reasons why you consider it "well designed"

5. Course Overview • Analysis and Design of Information Systems • UML (Unified Modeling Language) • “What” not “How” to make • Core, GSIA course • Homework (teams) • Project & Final (solo)

6. In Class Exercise • Groups of 3 • Most Frustrating/Annoying Application • What makes it that way? • What would fix it? • Example: Forwarded WebTV mail & Mulberry

7. Failures • Technology Failures • Kapor - “Design Manifesto” • Cost of Changes

8. Technology Failures A technology failure occurs when a system fails to meet expectations. • System • Expectations • Fails to meet

9. “System” • Software • Hardware/Technology • Procedures/Business Process

10. Whose Expectations? • “Stakeholders” • Top Management • Line Management • IS Management • Users • Shareholders - Market • IS Developers

11. What Expectations? Explicit Documented Implicit Unwritten Expectations can be contradictory Explicit Expectations can be incorrect

12. Expectations about What? • Anything • Cost • Performance • Functionality • Reliability • ……

13. “Fails to Meet” • User Survey as Measure of Quality • Good Idea? • Range of satisfaction • Not always binary

14. Causes of Failures • Numerous • Right System • Wrong place or time • Wrong process • Missed Expectations

15. Cost of Failures • Initial, Complete Failure • Total Development Cost • Rework/Reengineering • Retraining • “Minor” Failures • Cost to fix driven by when need for change is identified

16. Cost of Changes

17. Preventing Failures • Correctly capturing and determining how to meet everyone's expectations • Software (System) Designer (Winograd) • One foot in world of people & processes • One foot in world of technology • Correctly meeting expectations • Software (System) Engineer

18. Design Manifesto • Mitch Kapor • Founded Lotus • Designer of 1-2-3 • Need for Design • What is Design • Training Designers

19. Need for Design • Large MIS Departments • “Conspiracy of silence” • “Secret shame of the industry” • Systems are hard to use • Users learn minimum to get by

20. What is Design • People, Process, Technology • Not just interface design • Architects not Construction Engineers • Creating buildings • Defining public spaces • Knowledge of use and function • Profile 1 (where the analogy falls short)

21. Well Designed • Firmness - no bugs • Commodity - useful for intended purpose • Delight - use is pleasurable

22. Training Designers • Technical Knowledge • Human-Computer Interaction • Design Studio • Practice • Apprentice • Integration of design into development

23. Goals for Course • What to make not how to make it • UML - communication tool • Exposure to design issues and ideas • Shift focus from technology to understanding people and processes

24. System Development • Goals • Phases • Common Characteristics • Object-Oriented Development

25. Goals • Build good systems • Quality • Cost-effective • What people want • What people will pay for

26. Generic Phases • Analysis • Design • Coding • Testing • Implementation • Maintenance

27. Analysis • Problem definition • Current state • Scope • Description of solution • Requirements

28. Design • Model of solution • Data structure • Interface design • System architecture • Program details

29. Coding • Write it • Search for reuse • Catalog for reuse • “Unit” testing

30. Testing • Does it work? • Integration/subsystem testing • System testing • Usability testing • User acceptance testing

31. Implementation • Put the system in place • Install new hardware/technology • Install new software • Training • Packaging and delivery • Conversion

32. Maintenance • Error Correction - fix bugs • Adaptation • Hardware or operating system changes • Network changes • Legal requirements • Enhancement

33. Common Characteristics • Phases  Activities  Tasks • Incremental • Future builds on past • Milestones • Deliverables • Different skills needed for different development tasks

34. Object-Oriented Development - The Unified (?) Process • Inception • Elaboration • Construction • Transition

35. Modeling • What is a model? • Why use a model? • Alternative Models • Liddle - Conceptual Models • Drawbacks of Models

36. What is a Model? • Representation • Simplification • Abstraction • Focus/Important Aspects • Semantic Information vs. Notation

37. Save Time Generate Agreement Thinking Tool Capture Design Decisions Generate Useful Product Organize and Simplify Explore Alternatives Master Complexity Why Model?

38. Types of Models • Ideal - complete • Partial • Tool-Based

39. Different Views Aspects Perspectives Contexts Levels of Abstraction Static Model Structure Dynamic Model Behavior Alternative Models

40. Model Example • Xerox Star - User’s Conceptual Model • Design Process • Identify Tasks • Build Scenarios • Design Graphical Display • Display Elements • Controls • User’s Conceptual Model

41. User’s Conceptual Model • What the user thinks • How the user responds • Desktop Metaphor • abstractions • recognition over recall • progressive disclosure

42. Drawbacks of Models • Understandability • Over Simplification • Poor Model Choice • Over Reliance on Model • Difficult Conversion • Model Longer to Develop • Maintenance

43. Analysis • Requirements • Communication • Activities • Deliverables

44. Requirements “Correct and thorough requirements specifications is essential to a successful project.” “No matter how well designed or well coded, a poorly analyzed and specified program will disappoint the user and bring grief to the developer.” “It is indispensable for analysts to get acquainted with the application domain.”

45. Requirements • A desired feature, property or behavior of a system • Expectations - explicit through implicit • System - software, hardware/technology, procedures/business processes • “What” not “How”

46. Types of Requirements • Business Process • System Transactions - User’s Perspective • “Look and Feel” • System Specific

47. System Specific Requirements • Limits, Constraints, Priorities • Reliability and Quality • Speed and Response Time • Data Volume • Error Handling

48. Quality Function Deployment • Mitsubishi • Types of Requirements • Normal - explicit - satisfied user • Expected - implicit • Exciting - “go beyond”

49. Collecting Requirements • Identify Users/Stakeholders • Different Ones - Different Needs • Establish Problem Domain • What is it? What isn’t it? • How big is it? • Get to know it • Workflows - Business Processes • Current • Future

50. Collecting Requirements • Partitioning • Decompose problem into separate parts • Understand relationships between the parts • Way to handle complexity • Hierarchy • Increasing detail with depth