Software Design and Engineering using UML January 15, 2000

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

Administrivia zSyllabus zDoing it in Seven zWaivers zPresentations

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"

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)

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

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

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

“System” zSoftware zHardware/Technology zProcedures/Business Process

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

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

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

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

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

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

Cost of Changes

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

Design Manifesto zMitch Kapor yFounded Lotus yDesigner of zNeed for Design zWhat is Design zTraining Designers

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

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)

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

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

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

System Development zGoals zPhases zCommon Characteristics zObject-Oriented Development

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

Generic Phases zAnalysis zDesign zCoding zTesting zImplementation zMaintenance

Analysis zProblem definition zCurrent state zScope zDescription of solution zRequirements

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

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

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

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

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

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

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

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

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

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

Types of Models zIdeal - complete zPartial zTool-Based

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

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

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

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

Analysis zRequirements zCommunication zActivities zDeliverables

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.”

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”

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

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

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

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

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

Collecting Requirements zQuestioning zListening zDiscussing

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

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

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)

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

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

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

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

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

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

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

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

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

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

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?

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

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

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 )

Activity Diagrams Start Finish Activity Condition [cond]

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

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

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}

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

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

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

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

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

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

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?

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

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

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

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