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

2. Agenda zAdministrivia zCourse Overview zFailures - “Design Manifesto” zSystem Development zModeling zAnalysis - Preliminary Study zHomework 1 & Project

3. Administrivia zSyllabus zDoing it in Seven zWaivers zPresentations

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

5. Course Overview zAnalysis and Design of Information Systems zUML (Unified Modeling Language) z“What” not “How” to make zCore, GSIA course zHomework (teams) zProject & Final (solo)

6. In Class Exercise zGroups of 3 zMost Frustrating/Annoying Application zWhat makes it that way? zWhat would fix it? zExample: Forwarded WebTV mail & Mulberry

7. Failures zTechnology Failures zKapor - “Design Manifesto” zCost of Changes

8. Technology Failures A technology failure occurs when a system fails to meet expectations. zSystem zExpectations zFails to meet

9. “System” zSoftware zHardware/Technology zProcedures/Business Process

10. Whose Expectations? z“Stakeholders” yTop Management yLine Management yIS Management yUsers yShareholders - Market yIS Developers

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

12. Expectations about What? zAnything yCost yPerformance yFunctionality yReliability y……

13. “Fails to Meet” zUser Survey as Measure of Quality yGood Idea? zRange of satisfaction yNot always binary

14. Causes of Failures zNumerous zRight System yWrong place or time yWrong process zMissed Expectations

15. Cost of Failures zInitial, Complete Failure yTotal Development Cost yRework/Reengineering yRetraining z“Minor” Failures yCost to fix driven by when need for change is identified

16. Cost of Changes

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

18. Design Manifesto zMitch Kapor yFounded Lotus yDesigner of 1-2-3 zNeed for Design zWhat is Design zTraining Designers

19. Need for Design zLarge MIS Departments z“Conspiracy of silence” z“Secret shame of the industry” zSystems are hard to use zUsers learn minimum to get by

20. What is Design zPeople, Process, Technology zNot just interface design zArchitects not Construction Engineers yCreating buildings yDefining public spaces yKnowledge of use and function zProfile 1 (where the analogy falls short)

21. Well Designed zFirmness - no bugs zCommodity - useful for intended purpose zDelight - use is pleasurable

22. Training Designers zTechnical Knowledge zHuman-Computer Interaction zDesign Studio yPractice yApprentice zIntegration of design into development

23. Goals for Course zWhat to make not how to make it zUML - communication tool zExposure to design issues and ideas zShift focus from technology to understanding people and processes

24. System Development zGoals zPhases zCommon Characteristics zObject-Oriented Development

25. Goals zBuild good systems yQuality yCost-effective zWhat people want zWhat people will pay for

26. Generic Phases zAnalysis zDesign zCoding zTesting zImplementation zMaintenance

27. Analysis zProblem definition zCurrent state zScope zDescription of solution zRequirements

28. Design zModel of solution zData structure zInterface design zSystem architecture zProgram details

29. Coding zWrite it zSearch for reuse zCatalog for reuse z“Unit” testing

30. Testing zDoes it work? zIntegration/subsystem testing zSystem testing zUsability testing zUser acceptance testing

31. Implementation zPut the system in place zInstall new hardware/technology zInstall new software zTraining zPackaging and delivery zConversion

32. Maintenance zError Correction - fix bugs zAdaptation yHardware or operating system changes yNetwork changes yLegal requirements zEnhancement

33. Common Characteristics zPhases  Activities  Tasks zIncremental yFuture builds on past zMilestones zDeliverables zDifferent skills needed for different development tasks

34. Object-Oriented Development - The Unified (?) Process zInception zElaboration zConstruction zTransition

35. Modeling zWhat is a model? zWhy use a model? zAlternative Models zLiddle - Conceptual Models zDrawbacks of Models

36. What is a Model? zRepresentation zSimplification zAbstraction zFocus/Important Aspects zSemantic Information vs. Notation

37. Why Model? zSave Time zGenerate Agreement zThinking Tool zCapture Design Decisions zGenerate Useful Product z Organize and Simplify z Explore Alternatives z Master Complexity

38. Types of Models zIdeal - complete zPartial zTool-Based

39. Alternative Models zDifferent yViews yAspects yPerspectives yContexts yLevels of Abstraction z Static Model yStructure z Dynamic Model yBehavior

40. Model Example zXerox Star - User’s Conceptual Model zDesign Process yIdentify Tasks yBuild Scenarios yDesign Graphical Display xDisplay Elements xControls xUser’s Conceptual Model

41. User’s Conceptual Model zWhat the user thinks zHow the user responds zDesktop Metaphor yabstractions yrecognition over recall yprogressive disclosure

42. Drawbacks of Models zUnderstandability zOver Simplification zPoor Model Choice zOver Reliance on Model zDifficult Conversion zModel Longer to Develop zMaintenance

43. Analysis zRequirements zCommunication zActivities zDeliverables

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 zA desired feature, property or behavior of a system zExpectations - explicit through implicit zSystem - software, hardware/technology, procedures/business processes z“What” not “How”

46. Types of Requirements zBusiness Process zSystem Transactions - User’s Perspective z“Look and Feel” zSystem Specific

47. System Specific Requirements zLimits, Constraints, Priorities zReliability and Quality zSpeed and Response Time zData Volume zError Handling

48. Quality Function Deployment zMitsubishi zTypes of Requirements yNormal - explicit - satisfied user yExpected - implicit yExciting - “go beyond”

49. Collecting Requirements zIdentify Users/Stakeholders yDifferent Ones - Different Needs zEstablish Problem Domain yWhat is it? What isn’t it? yHow big is it? yGet to know it zWorkflows - Business Processes yCurrent yFuture

50. Collecting Requirements zPartitioning yDecompose problem into separate parts yUnderstand relationships between the parts yWay to handle complexity yHierarchy xIncreasing detail with depth

51. Collecting Requirements zQuestioning zListening zDiscussing

52. Collecting Requirements Prototyping zPrototype: software model of system zClosed-Ended - throwaway zOpen-Ended - evolutionary zExplorative - identify requirements zExperimental - try options z“Entire” System zKey elements only

53. Candidates for Prototyping zDynamic visual displays zHeavy user interaction zComplex algorithms or calculations zAmbiguous or conflicting requirements

54. Prototyping Considerations zUser Resources zDecision Makers zIS Resources - Tools, People zUser Understanding of Prototype yTime to completion yFull functionality yPerformance requirements yClosed-ended z“Paper Prototype” zCommunication Tool (Model)

55. Analysis Communication Challenges zExplicit Requirements zImplicit Requirements zAll Stakeholders zShared Knowledge zGetting Agreement

56. Analysis Communication zInterviews zUser Documentation zUser Training zRAD/FAST zModels zProject Documentation/Deliverables zReviews

57. Interviews zQuestions zOpen-ended questions zSurvey zOne-on-one zObservation of work in progress zFollow up yThank you yMinutes - notes yQuestions

58. User Materials zTraining yNew employees yManuals zDocumentation yProcedure manuals yException handling yWorkflow documentation y“Unwritten” yForms

59. RAD/FAST zRAD yRapid Application Development yRapid Analysis and Design zFAST yFacilitated Application Specification Technique

60. RAD/FAST zStructured Workshop zAll stakeholders yusers, developers, support areas, management zDecision Makers zEstablished Rules and Agenda zInterviews and Other Data Collection First zCareful Documentation on Decisions zMultiple Meetings - Several Days/Weeks zPrototyping Possible zReview Results

61. Analysis Models zCommunication Tool zModel drawbacks raised earlier zUser training in understanding modeling method and meaning

62. Project Documentation zWritten for user review zWritten for management review zWritten for next development phase zEverything on paper (disk) zGlossary: technical & business zOutstanding issues

63. Review zFormal or Informal zAlong the way and after Analysis “complete” zGoal is agreement zSign offs

64. Preliminary Study zOverview zAssumptions/Issues zContext Diagram zBusiness Process Models zIs-State zDescription of Actors zDescription of Interfaces zRequirements zPrioritized List of Use Cases zRecommendation zAppendices

65. Preliminary Study zOverview yDescription of project, goals, benefits, possible risks, summary of recommendation zAssumptions/Issues yOpen issues, unanswered questions, assumptions made throughout rest of document zRecommendation yShould development proceed? If so, how? What decisions need to be made? What is the project team’s recommendation for those decisions?

66. Context Diagram zDiagram showing the relationship between the system and all external entities ySystem - large circle yExternal entity - box xProducer or consumer of information that resides outside the system (user or another system) yRelationship - line with arrow showing direction of flow labeled with data

67. Context Diagram Student Enrollment System Student Billing System Registrar Dept Desired Courses Available Courses Roster Available Courses Student Billing Room Assignments Unassigned Courses Schedule

68. Business Process Model zModel of existing business processes zModel of new/changed business processes zShows procedure or workflow zEmphasis is individual activities yObject state when significant zRelationship, precedence, timing of activities zResponsibilities (swim lanes) zActivity Diagrams (pp. 146-149)

69. Activity Diagrams Start Finish Activity Condition [cond]

70. Activity Diagrams Synchronization Constraints Splitting Multiple Transitions {AND}{OR}{XOR} * for each/all

71. Activity Diagrams Object State To State Required State Object [state] Object [state] Object [state]

72. Register for Courses Sign OnEnter Courses Sign Off Check Preqs Check Avail Add to Waitlist Add Student Billing [paid] Billing [due] * each course * all courses Display Schedule [ok] [avail] [full] {AND}

73. “Is-State” zDescription of current “system” zBusiness Process Models zText Descriptions zIdentify current problems zTotally New Development ycompetitors, alternatives

74. Preliminary Study zDescription of Actors yBrief description of each actor - who does what xActor: abstraction for external entities (user or system) that interact directly with the system xDetermined by role not person zDescription of Interfaces yBrief description of external systems that only provide data to the system but do not interact with it yExternal entities that are not actors

75. Documenting Requirements zSpecification - representation (model) of requirements (explicit) yText description/narrative yOutline (1, 1.1, 1.1.1, etc…) yBusiness Process Models yPrototypes ySample forms, reports, screens

76. Documenting Requirements zUnderstandable to all zFormat and content relevant to problem zInformation should be nested zDiagrams should be consistent zRevisable

77. Prioritized List of Use Cases zUse Case: specification of sequence of actions that a system can perform by interacting with actors zScenarios zTransactions zBusiness Event or Operation zComprehensive

78. Prioritizing Use Cases zDifference between “normal” and “exciting” requirements zWhat must be done right away? zWhat can wait? zNeeded versus Desired zDifferent users have different priorities yRAD/FAST to help determine zCost/Complexity y80/20 Rule

79. Appendices zArchitectural Model yWhat hardware, software and other technology will be needed for this project? yHow experienced is the team with this technology? yWhat special tools or training will be needed to develop the project? yAre there any other technical considerations that should be noted?

80. Appendices zInformation Sources yWhat were the sources of information used in creating the Preliminary Study? zAlternative Solutions yWhat are the alternative solutions to the recommended one? yWhy was each alternative not selected? yMake vs. Buy Decision

81. Appendices zTechnical Glossary yDefinition and description of technical terms or terms that have specialized meanings y“technical” in technology sense y“technical” in business sense

82. Homework zTVList.com zDocument Assumptions zFill in “blanks” zTeam Effort - Be both user and developer zMade Consistent zHomework #1 yPreliminary Study

83. Project zIndividual Effort zComputing or Technology Failure zCauses and Prevention zBooks on Reserve - Go Beyond Them zThree Parts yOverview - 2/5 yPresentation - 2/26 yWritten Report - 2/26