1 / 83

Software Design and Engineering using UML

This course provides an in-depth understanding of software design and engineering using UML (Unified Modeling Language). It covers critical topics such as system development, analysis, and modeling, alongside a focus on identifying and preventing technology failures. Participants will engage in team homework, a solo final project, and in-class exercises to deepen their learning. The emphasis is on understanding user expectations, proper design practices, and improving user experience through effective software development. Gain insights into the design manifesto and strategies for successful systems.

bryony
Télécharger la présentation

Software Design and Engineering using UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related