Post on 06-Feb-2016
description
Software Design and Engineering using UML
January 15, 2000
Agenda
AdministriviaCourse OverviewFailures - “Design Manifesto”System DevelopmentModelingAnalysis - Preliminary StudyHomework 1 & Project
Administrivia
SyllabusDoing it in SevenWaiversPresentations
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 packagereasons why you consider it "well
designed"
Course Overview
Analysis and Design of Information Systems
UML (Unified Modeling Language)“What” not “How” to makeCore, GSIA courseHomework (teams)Project & Final (solo)
In Class Exercise
Groups of 3Most Frustrating/Annoying ApplicationWhat makes it that way?What would fix it?
Example: Forwarded WebTV mail & Mulberry
Failures
Technology FailuresKapor - “Design Manifesto”Cost of Changes
Technology Failures
A technology failure occurs when a system fails to meet expectations.
SystemExpectationsFails to meet
“System”
SoftwareHardware/TechnologyProcedures/Business Process
Whose Expectations?
“Stakeholders” Top Management Line Management IS Management Users Shareholders - Market IS Developers
What Expectations?
Explicit
Documented
Implicit
Unwritten
Expectations can be contradictory
Explicit Expectations can be incorrect
Expectations about What?
Anything
Cost Performance Functionality Reliability ……
“Fails to Meet”
User Survey as Measure of Quality Good Idea?
Range of satisfaction Not always binary
Causes of Failures
Numerous
Right System Wrong place or time Wrong process
Missed Expectations
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
Cost of Changes
0
10
20
30
40
50
60
70
Analysis Design Code Test After Release
x E
xpen
se
Preventing Failures
Correctly capturing and determining how to meet everyone's expectations Software (System) Designer (Winograd)
One foot in world of people & processesOne foot in world of technology
Correctly meeting expectations Software (System) Engineer
Design Manifesto
Mitch Kapor Founded Lotus Designer of 1-2-3
Need for DesignWhat is DesignTraining Designers
Need for Design
Large MIS Departments“Conspiracy of silence”“Secret shame of the industry”Systems are hard to useUsers learn minimum to get by
What is Design
People, Process, TechnologyNot just interface designArchitects not Construction Engineers
Creating buildings Defining public spaces Knowledge of use and function
Profile 1 (where the analogy falls short)
Well Designed
Firmness - no bugsCommodity - useful for intended
purposeDelight - use is pleasurable
Training Designers
Technical KnowledgeHuman-Computer InteractionDesign Studio
Practice Apprentice
Integration of design into development
Goals for Course
What to make not how to make itUML - communication toolExposure to design issues and ideasShift focus from technology to
understanding people and processes
System Development
GoalsPhasesCommon CharacteristicsObject-Oriented Development
Goals
Build good systems Quality Cost-effective
What people wantWhat people will pay for
Generic Phases
AnalysisDesignCodingTestingImplementationMaintenance
Analysis
Problem definitionCurrent stateScopeDescription of solutionRequirements
Design
Model of solutionData structureInterface designSystem architectureProgram details
Coding
Write itSearch for reuseCatalog for reuse“Unit” testing
Testing
Does it work?
Integration/subsystem testingSystem testingUsability testingUser acceptance testing
Implementation
Put the system in placeInstall new hardware/technologyInstall new softwareTrainingPackaging and deliveryConversion
Maintenance
Error Correction - fix bugsAdaptation
Hardware or operating system changes Network changes Legal requirements
Enhancement
Common Characteristics
Phases Activities TasksIncremental
Future builds on pastMilestonesDeliverablesDifferent skills needed for different
development tasks
Object-Oriented Development - The Unified (?) Process
InceptionElaborationConstructionTransition
Modeling
What is a model?Why use a model?Alternative ModelsLiddle - Conceptual ModelsDrawbacks of Models
What is a Model?
RepresentationSimplificationAbstractionFocus/Important Aspects
Semantic Information vs. Notation
Why Model?
Save TimeGenerate
AgreementThinking ToolCapture Design
DecisionsGenerate Useful
Product
Organize and Simplify
Explore Alternatives
Master Complexity
Types of Models
Ideal - completePartialTool-Based
Alternative Models
Different Views Aspects Perspectives Contexts Levels of
Abstraction
Static Model Structure
Dynamic Model Behavior
Model Example
Xerox Star - User’s Conceptual Model
Design Process Identify Tasks Build Scenarios Design Graphical Display
Display ElementsControlsUser’s Conceptual Model
User’s Conceptual Model
What the user thinksHow the user responds
Desktop Metaphor abstractions recognition over recall progressive disclosure
Drawbacks of Models
UnderstandabilityOver SimplificationPoor Model ChoiceOver Reliance on ModelDifficult ConversionModel Longer to DevelopMaintenance
Analysis
RequirementsCommunicationActivitiesDeliverables
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
A desired feature, property or behavior of a system
Expectations - explicit through implicitSystem - software, hardware/technology,
procedures/business processes
“What” not “How”
Types of Requirements
Business ProcessSystem Transactions - User’s
Perspective“Look and Feel”System Specific
System Specific Requirements
Limits, Constraints, PrioritiesReliability and QualitySpeed and Response TimeData VolumeError Handling
Quality Function Deployment
Mitsubishi
Types of Requirements Normal - explicit - satisfied user Expected - implicit Exciting - “go beyond”
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
Collecting Requirements
Partitioning Decompose problem into separate parts Understand relationships between the
parts Way to handle complexity Hierarchy
Increasing detail with depth
Collecting Requirements
QuestioningListeningDiscussing
Collecting RequirementsPrototyping
Prototype: software model of system
Closed-Ended - throwaway Open-Ended - evolutionary
Explorative - identify requirements Experimental - try options
“Entire” System Key elements only
Candidates for Prototyping
Dynamic visual displaysHeavy user interactionComplex algorithms or calculationsAmbiguous or conflicting
requirements
Prototyping Considerations
User ResourcesDecision Makers IS Resources - Tools, PeopleUser Understanding of Prototype
Time to completion Full functionality Performance requirements Closed-ended
“Paper Prototype”Communication Tool (Model)
Analysis Communication Challenges
Explicit RequirementsImplicit RequirementsAll StakeholdersShared KnowledgeGetting Agreement
Analysis Communication
InterviewsUser DocumentationUser TrainingRAD/FASTModelsProject Documentation/DeliverablesReviews
Interviews
Questions Open-ended questionsSurveyOne-on-oneObservation of work in progressFollow up
Thank you Minutes - notes Questions
User Materials
Training New employees Manuals
Documentation Procedure manuals Exception handling Workflow documentation “Unwritten” Forms
RAD/FAST
RAD Rapid Application Development Rapid Analysis and Design
FAST Facilitated Application Specification
Technique
RAD/FAST
Structured WorkshopAll stakeholders
users, developers, support areas, managementDecision MakersEstablished Rules and Agenda Interviews and Other Data Collection FirstCareful Documentation on DecisionsMultiple Meetings - Several Days/WeeksPrototyping PossibleReview Results
Analysis Models
Communication ToolModel drawbacks raised earlierUser training in understanding
modeling method and meaning
Project Documentation
Written for user reviewWritten for management reviewWritten for next development phaseEverything on paper (disk)Glossary: technical & businessOutstanding issues
Review
Formal or InformalAlong the way and after Analysis
“complete”Goal is agreementSign offs
Preliminary Study
OverviewAssumptions/IssuesContext DiagramBusiness Process Models Is-StateDescription of ActorsDescription of InterfacesRequirementsPrioritized List of Use CasesRecommendationAppendices
Preliminary Study
Overview Description of project, goals, benefits, possible
risks, summary of recommendation
Assumptions/Issues Open issues, unanswered questions, assumptions
made throughout rest of document
Recommendation Should development proceed? If so, how? What
decisions need to be made? What is the project team’s recommendation for those decisions?
Context Diagram
Diagram showing the relationship between the system and all external entities System - large circle External entity - box
Producer or consumer of information that resides outside the system (user or another system)
Relationship - line with arrow showing direction of flow labeled with data
Context Diagram
Student Enrollment System
Student
Billing System
Registrar
DeptDesired Courses
Available Courses
RosterAvailable Courses
Student Billing
Room Assignments
Unassigned Courses
Schedule
Business Process Model
Model of existing business processesModel of new/changed business processes
Shows procedure or workflowEmphasis is individual activities
Object state when significant
Relationship, precedence, timing of activitiesResponsibilities (swim lanes)Activity Diagrams (pp. 146-149)
Activity Diagrams
Start
Finish
Activity
Condition[cond]
[cond]
Activity Diagrams
Synchronization
Constraints
Splitting
Multiple Transitions
{AND} {OR} {XOR}
* for each/all
Activity DiagramsObject State
To State
Required State
Object
[state]
Object
[state]
Object
[state]
Register for Courses
Sign On Enter 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”
Description of current “system”Business Process ModelsText DescriptionsIdentify current problems
Totally New Development competitors, alternatives
Preliminary Study
Description of Actors Brief description of each actor - who does
whatActor: abstraction for external entities (user or
system) that interact directly with the systemDetermined by role not person
Description of Interfaces Brief description of external systems that only
provide data to the system but do not interact with it External entities that are not actors
Documenting Requirements
Specification - representation (model) of requirements (explicit) Text description/narrative Outline (1, 1.1, 1.1.1, etc…) Business Process Models Prototypes Sample forms, reports, screens
Documenting Requirements
Understandable to allFormat and content relevant to
problemInformation should be nestedDiagrams should be consistentRevisable
Prioritized List of Use Cases
Use Case: specification of sequence of actions that a system can perform by interacting with actors
ScenariosTransactionsBusiness Event or OperationComprehensive
Prioritizing Use Cases
Difference between “normal” and “exciting” requirements
What must be done right away?What can wait?Needed versus DesiredDifferent users have different priorities
RAD/FAST to help determineCost/Complexity
80/20 Rule
Appendices
Architectural Model What hardware, software and other
technology will be needed for this project? How experienced is the team with this
technology? What special tools or training will be
needed to develop the project? Are there any other technical
considerations that should be noted?
Appendices
Information Sources What were the sources of information
used in creating the Preliminary Study?Alternative Solutions
What are the alternative solutions to the recommended one?
Why was each alternative not selected? Make vs. Buy Decision
Appendices
Technical Glossary Definition and description of technical
terms or terms that have specialized meanings
“technical” in technology sense “technical” in business sense
Homework
TVList.comDocument AssumptionsFill in “blanks”Team Effort - Be both user and
developerMade Consistent Homework #1
Preliminary Study
Project
Individual EffortComputing or Technology FailureCauses and PreventionBooks on Reserve - Go Beyond ThemThree Parts
Overview - 2/5 Presentation - 2/26 Written Report - 2/26