HINF 450 Test 1

  1. Problems with Health IT
    • •Doctors
    • and nurses have petitioned the hospital administration to have the system
    • turned off

    • •The
    • system doesn’t interface properly with existing databases and systems

    • •The
    • staff believe it may actually be causing medication errors

    • •Staff
    • find the system very difficult to learn how to use

    • •Deadlines
    • for final implementation have continually been “postponed”

    • •Very
    • few users of modules that are up and running

    • •The
    • system is behind schedule and not running

    • •Resources
    • are being drained from healthcare to this project

    • •Academics
    • have argued that the system is not being designed and developed properly

    • •The
    • first objective, that of deploying a scheduling system, has not been met

    • •Estimates
    • for cost of completing the project are skyrocketing
  2. Why
    is this? (i.e. why are healthcare information systems so hard to design and
    • •Failure to consider healthcare workflow
    • during design

    • •Failure to understand user information
    • needs

    •Shortchanged requirements gathering

    •Use of inappropriate design methodologies

    • •Lack of consideration of specific
    • contexts of use

    •Lack of consideration of cost-benefits

    • •Lack of knowledge of health informatics
    • by leaders of projects

    •…. And more!
  3. Possible
    Reasons for Failure in Healthcare
    •Complexity of healthcare

    • •High level of user interactivity
    • (this complicates design, particularly traditional approaches!)

    •High risk

    •Uncertainty in what can work

    • •In
    • many cases “D” (development projects) become more like “R&D” in healthcare!
    • (despite what vendors say)

    •Safety concerns and issues

    • •Not
    • present in many business domains to this extent, but present in other, like
    • aviation, that we can learn from
  4. SDLC & Phases
    • •The systems development life cycle (SDLC) is a general term used to
    • describe the method and process of developing a new information system

    • •Without the structure and
    • organization provided by SDLC approach projects are at risk for missed
    • deadline, low quality etc.

    •SDLC provides





    • Needed
    • for successful development


    • •Sets of related activities are
    • organized into “phases”:

    • (1)Project
    • planning phase

    • (2)Analysis
    • phase

    • (3)Design
    • phase

    • (4)Implementation
    • phase

    • (5)Support
    • phase

    • In “classical” life cycle these phases
    • are sequential, but there are variations as we will see

  5. Classic waterfall life cycle

    why traditional “waterfall” approach (which is used widely in healthcare) is
    Analysis, Design, Implementaion, Support

    • •Requirements can’t be adequately
    • nailed down in analysis phases alone (since too complex and may even change!)

    • •Flexibility is needed (to catch
    • problems early in lifecycle when they are easier, and cheaper! to fix) –
    • changes at architectural level may be needed

    •Safety aspects require continual user input and higher degree of testing

    • •Requirements aspects need continual user input and involvement (or will
    • never get them “right”)
  6. Functional and Technical Requirements
    •Functional Requirements

    • •A
    • system requirement that describes a function or process that the system must
    • support

    • •E.g.
    • “system will generate an alert if medications are inappropriate for patient”

    •Technical Requirements

    • •A
    • system requirement that describes an operating environment or performance
    • objective

    • •E.g.
    • “must run in a client-server environment with Windows NT”, “must have one
    • second response time”

    •Non-functional Requirements

    • •Things
    • like usability, privacy, enjoyability,
    • learnability

    • •Not
    • typically formally considered but may end up being key to acceptance or
    • rejection of systems!!
  7. Rapid development, dimensions of rapid development, 4 pilars
    • A
    • “rapid-development project”

    • –Any
    • project that needs to emphasize development speed (fits lots of projects!)

    • –Note
    • – more than 80% of software projects run overtime and over budget ! (Standish
    • Group)

    • –Healthcare
    • systems are often overtime and overbudget

    • •Success
    • at development depends on:

    • –Choosing
    • effective practices rather than ineffective practices

    • –Choosing
    • practices that are oriented  specifically
    • toward achieving your schedule objectives

    • •Can
    • be challenging given the large number of software practices that are out there
    • to choose


    • 1.People
    • •Results
    • of studies indicate a 10-1 difference in productivity among different
    • developers

    • •“Peopleware”
    • issues have more impact on software productivity than any other factor

    • •NASA
    • concluded that technology is not the answer, the most effective practices
    • leveraged human potential of developers

    • •Studies
    • indicate that effects of individual ability, individual motivation, team
    • ability and team motivation dwarf
    • other productivity factors

    • 2.  
    • Process

    • •“Process”
    • includes both management and technical methodologies

    • •Companies
    • that have focused on process (e.g. NASA, Xerox) have cut their time-to-market
    • by about one half and reduced cost and defects by factors of 3 to 10

    • •Rework
    • avoidance

    • –Orient
    • your process so you avoid doing things twice

    • •Quality
    • assurance

    • –To
    • ensure product has acceptable level of quality

    • –To
    • detect errors at the stage they are least time consuming and costly to fix

    • •Development
    • fundamentals

    • •Risk
    • management

    • •Resource
    • targeting

    • •Lifecyle
    • planning (and selection)

    • •Customer
    • orientation

    • 3.  
    • Product

    • •If
    • you can reduce a product’s feature set you can reduce the product’s schedule

    • •80/20
    • rule – 80 % of the product takes only 20% of the time (typical in health system
    • development)

    • •Product
    • size – the biggest single contributor to development schedule (effort required
    • to build software increases disproportionately faster than the size of the
    • software)

    • •Product
    • characteristics – hard to reach goals regarding peformance,
    • memory use etc. will take longer

    • 4.  
    • Technology

    • •Changing
    • from less effective tools to more effective tools can be a fast way to improve
    • development speed

    • •The
    • change from low-level languages to high-level languages was one of the most
    • important changes in software development

    • •Choosing
    • tools effectively and managing the risks involved are important
  8. Classic mistakes that are made all the time in IT
    • PEOPLE
    • related mistakes

    • 1.Undermined
    • motivation

    • •Motivation
    • has biggest effect on productivity

    • 2.Weak
    • Personnel

    • –Has
    • next most important influence on productivity

    • 3.Uncontrolled
    • Problem Employees


    • •Encourages
    • too much risk taking

    • 5.Adding
    • people to a late project

    • •Like
    • “pouring gasoline on a fire” (Brooks, 1975)

    • 6.Noisy
    • crowded offices

    • 7.
    • Friction between developers and customers

    • –Customers
    • may not think developers are delivering and developers may think customers are
    • unreasonable

    • 8.
    • Unrealistic expectations

    • 9.
    • Lack of effective project sponsorship

    • –Projects
    • need high level support

    • 10.
    • Lack of stakeholder buy-in

    • –Need
    • complete buy-in from all stakeholders

    • 11.
    • Lack of user input

    • –Standish
    • group found #1 reason projects succeed is user
    • involvement – lack of continual
    • user input (i.e. throughout the design process) is perhaps the NUMBER 1 PROBLEM

    • 12.
    • Politics placed over substance – can be fatal


    • 13.
    • Wishful thinking –e.g. “we could pull it off ”

    14. Overly optimistic schedules

    15. Insufficient risk management

    16. Contractor failure

    17. Insufficient planning

    • 18. Abandonment of planning under
    • pressure

    • 19. Wasted time during the fuzzy
    • front end

    • –Time
    • before project really gets off the ground

    • 20.
    • Shortchanged upstream activities

    • –Since
    • requirements analysis, architecture and design don’t directly produce code
    • often shortchanged

    • 21.
    • Inadequate design

    • 22.
    • Shortchanged quality assurance

    • 23.
    • Insufficient management controls

    • 24.
    • Premature or overly frequent convergence

    • 25.
    • Omitting necessary tasks from estimates

    • 26.
    • Planning to catch up later

    • 27.
    • Code-like-hell programming (this is not what is meant by rapid development!!)

    • 28.
    • Requirements gold-plating

    • –Projects
    • with more requirements than they need

    • 29.
    • Feature creep

    • –Average
    • project experiences about 25% increase in requirements over time

    • 30.
    • Developer gold-plating

    • –Developers
    • trying out new features

    • 31.
    • Push-me, pull-me negotiation

    • –Completely
    • behind schedule but then add new tasks when change schedule!

    • 32.
    • Research-oriented development

    • 33.
    • Silver-bullet syndrome

    • –Too
    • much reliance on previously unused technology

    • –E.g.
    • too much reliance on a CASE tool that is supposed to generate good code

    • 34.
    • Overestimated savings fr om new
    • tools or methods

    • –Benefits
    • from new tool can be offset by learning curves

    • 35.
    • Switching tools in the middle of a project

    • –E.g.
    • switching versions or even tool used for coding

    • 36.
    • Lack of automated source-code control

    • –If
    • done manually may easily get out of sync
  9. Rapid protoyping
    Requirements gathering, quick design, build prototype, evaluate, engineer project
  10. Case Tools
    •Development speed

    •Flexibility and power

    •Techniques and capabilities

    • •WYSIWYG
    • (what you see is what you get)

    • •Generation
    • of complete programs, program skeletons, or database schemas from diagrams

    • •Rapid
    • customization of software libraries or components

    • •Error-checking
    • and debugging capabilities
  11. Quality Assurance and testing
  12. EHR design case study, Webcis, Patcis and Palmcis

    •What is a patient record?

    • •It is an amalgam of all the data acquired and created during a
    • patient’s course through the healthcare system

    •Its purpose:

    • •To
    • recall observations, to inform others, to instruct students, to gain knowledge,
    • to monitor performance and to justify interventions

    • •A repository of electronically
    • maintained information about an individual’s lifetime health status and health
    • care, stored such that it can serve the multiple legitimate users of the record

    •EMR – the electronic record in a physician’s office

    •EPR – the electronic record in a hospital or facility

    • •EHR – the longitudinal electronic record of an individual that contains
    • data from multiple EMRs and EPRs (shared and/or interoperable across settings)

    • •PHR – the electronic record
    • containing personal health information entered and maintained by the patient or
    • layperson

    • •Adds information management tools to provide clinical reminders and
    • alerts, linkages with knowledge sources for health-care decision support, an
    • analysis of aggregate data

    •A system that manages many computer-based patient records

    • 5
    • Functional Components of a EHR

    1. Integrated view of patient data

    2. Clinical decision support

    3. Clinician order entry

    4. Access to knowledge resources

    5. Integrated communication support
  13. UML Activity Diagram
    • •Is
    • a standardized way of showing workflow (across people, computers etc.) using
    • UML

    • •Can
    • add any number of “actors” across the columns

    • •Can
    • show flow of activities in the functional system

  14. UML Class diagram
    • •Object-oriented
    • approach models classes of objects instead of data entities

    • –Classes
    • have attributes and associations (like entities)

    • –Classes
    • also have cardinality

    • –Main
    • difference:  Objects do the actual
    • processing in a system (as well as storing)

    • –Object
    • oriented approach also has some additional features

    • •Generalization/specialization
    • hierarchies



    • •Hierarchies
    • that structure or rank classes from the more general superclass to the more
    • specialized subclasses (sometimes called inheritance hierarchies)

    • •Generalizations group
    • similar types of things like all cars share certain features (e.g. wheels, engine
    • etc.)

    • •Specializations are
    • judgments that categorize different types of things (e.g. sports car is a
    • special type of car)

    • •A
    • generalization/specialization
    • hierarchy structures things from the more general down to the more special

    • –Each class has a more general class
    • above it – a superclass

    • –A class may have a more specialized
    • class below – a subclass

  15. Object oriented aproach to requirements
    • •Object
    • Oriented approach (OO):

    • –(using class diagrams etc.) views a
    • system as a collection of interacting objects which are capable of their own behavior (methods)

    • •Question:
    • what does the system do when an event occurs?

    • •Traditional
    • approach:

    • –(using entity-relationship diagrams
    • etc.) views a system as a collection of processes
    • (like computer programs, a set of instructions)

    • –When the process executes it
    • interacts with data

    –So traditional emphasizes processes, data, inputs/outputs

    • •Object
    • Oriented approach (OO):

    • –(using class diagrams etc.) views a
    • system as a collection of interacting objects which are capable of their own behavior (methods)

    • –There are NO
    • conventional processes and data files per se, just interacting objects
  16. UML Use Case.
    Relation of use case and UML class diagrams
    • •Two
    • key concepts to model:



    • •Event
    • – an occurrence at a specific time and place, that can be described and is
    • worth remembering

    • –E.g.
    • customer placing an order, shipping identifies a backorder, nuclear reactor
    • goes to meltdown

    • •When
    • defining system requirements it is useful to begin by asking what events occur
    • that will affect the system being studied

    • –What
    • events will occur that the system will have to respond to?

    • –Allows
    • you to focus on external environment to keep you at high level view of system
    • (not the workings of it)

    • •Use
    • Case – a single use or function performed by the system for those who use the
    • system

    • –Describes
    • the activity the system carries out in response to an event

    • –E.g.
    • examples of use cases for word processing

    • •“write
    • a letter”, “print a newsletter”

    • –Two
    • concepts

    • •A
    • person is involved, the person uses the system

    • •Actor: 
    • a role played by a user of the system (a stick figure)

    • –Eg. For
    • RMO, use case “Create new order” might involve a sales representative talking
    • to the customer on the phone

    • •There
    • may be a whole series of individual steps to accomplish a use case


    • –A particular sequence of activities
    • within a case

    • –NOTE - one use case may have
    • several different scenarios

    • •In
    • the RMO example, for the use case “Create new order” there are at least two
    • scenarios

    –“Customer creates telephone order”

    –“Customer creates web order”

    • •Describe
    • individual steps with a narrative called a flow
    • of activities

  17. Events (temporal, external state)
    • –Also
    • allows you to focus on the interfaces of the system to outside people and
    • systems

    • –End
    • users can easily describe system needs in terms of events that affect their
    • work, so useful when working with users

    • –Gives
    • a way to divide (or decompose) the system requirements so you can study each
    • separately (complex systems need to be decomposed based on events)

    • •Fig.
    • 7-5 (next slide) shows the 14 use cases for external events (triggered by
    • external actors) for RMO example – order entry subsystem

    • •Note
    • that internally triggered events are often not represented by use case diagrams
  18. Event table (event, trigger, etc)

    • •Event
    • Table:  A table that lists events in rows and key
    • pieces of information about each event in columns

    • –The trigger:
    • an occurrence that tells the system that an event has occurred (either the
    • arrival of data needing processing or of a point in time)

    • –The source:
    • an external agent or actor that supplies data to the system

    • –The activity:
    • behavior that the system performs when an event occurs

    • –The response:
    • an output, produced by the system, that goes to a destination

    • –The destination:
    • An external agent or actor that receives data from the system
  19. Lifecycle planning (pure waterfall, spiral, etc)
    • •Every
    • software-development effort goes through a “life-cycle”

    • –Consists of all the activities
    • between the first glimmer and the time of the initial release

    • –A lifecycle model is a prescriptive
    • model of what should happen during that period

    • –Main function of lifecycle is to
    • establish the order in which a project specifies, prototypes, designs,
    • implements, reviews, tests and performs its other activities

    • –Establishes criteria to determine
    • whether to proceed from one task to the next

    • •The
    • lifecycle model you choose has as much influence over the project’s success as
    • any other planning decision

    • –The appropriate model can
    • streamline your project and ensure each step moves closer to your goal

    • –Can improve development speed,
    • improve quality, improve project tracking and control, minimize overhead,
    • minimize risk exposure

    • –The wrong
    • lifecycle model can be a constant source of slow work, repeated work,
    • unnecessary work and frustration

    • –Not
    • choosing a lifecycle can produce the same negative effects

    Pure Waterfall

    • •Project
    • progresses through an orderly sequence of steps from the initial software
    • concept to testing

    • •The
    • project holds a review at the end of each phase to determine whether its ready
    • to advance

    • •It
    • is document driven – the main products carried from phase to phase are
    • documents

    • •In
    • the pure waterfall model, the phases are discontinuous – they do not overlap

    • •See
    • Figure 7-1 (and
    • previous lecture notes) for diagram of pure waterfall model


    • •At
    • the other end of the sophistication scale is the spiral model

    • •A
    • risk-oriented lifecycle model that breaks a project up into miniprojects

    • •Each
    • miniproject
    • addresses one or more risks until all the major risks have been addressed

    • •“Risk”
    • is broadly defined

    • –Can refer to poorly understood
    • requirements, architectures, performance, problems with underlying technology
    • etc.

    • –After the major risks have been
    • addressed the spiral model terminates as a waterfall lifecycle would

    –Also called “cinnamon roll” – see Figure 7-4

    • •You
    • start small and expand the project scope in increments, but you expand the
    • scope only after you’ve reduced the risks for the next increment to an
    • acceptable level

    • •Each
    • iteration involves six steps

    • –Determine objectives, alternatives
    • and constraints

    –Identify and resolve risks

    –Evaluate alternatives

    • –Develop the deliverables for that
    • iteration, and verify they are correct

    –Plan the next iteration

    • –Commit to an approach for the next
    • iteration (if you decide to have one

    • •Early
    • iterations are the cheapest

    Code and Fix

    • •Seldom
    • useful but common

    • •If
    • you have not explicitly chosen another lifecycle model, you are probably using
    • the code-and-fix by default

    • •If
    • you haven’t done much project planning, you are undoubtedly using code-and-fix

    • •Combined
    • with a short schedule, code-and-fix gives rise to code-like-hell approach

    • •You
    • start with a general idea of what you want, then you do whatever combination of
    • informal design , code, debug and test methodologies that suits you until the
    • product is ready to release


    • •It
    • has no overhead

    • –You don’t spend any time on planning, documentation,
    • quality assurance, standards enforcement or any other activities other than
    • pure coding (and since you just jump into programming you show signs of
    • progress immediately and nearly anyone can do programming)

    • •For
    • tiny projects that you intend to throw away shortly after they are built it can
    • be useful

    • •For
    • small proof-of-concept programs, short-lived demos etc. could also be OK
  20. Client server & web architecture
    • uShared components among multiple
    • people or groups in organization (e.g. large hospital)

    uMulti-tiered computers

    • lClient-server
    • network based systems

    • lInternet-based
    • systems

    • uImplementation
    • diagram –
    • physical components of system

    • lDeployment
    • diagram
    • – shows components across different locations
    • Internet based systems:

    • uImplement three-layer design in
    • Web-based architecture

    uSimple Internet architecture

    • lStatic
    • Web pages

    • uTwo-layer architecture for user
    • interaction

    • lSystem
    • responds to user requests (inputs/outputs)

    • uThree-layer architecture for user
    • interaction

    • lDomain
    • layer added for business logic

    • lExample:
    • Case study – WebCIS
    • architecture

    • Client Server Architecture
    • uCurrently
    • a dominant architectural model for distributing information resources

    • lServer
    • computer (server):  A computer that provides services to other
    • computers on the network

    • lClient
    • computer:
    • A computer that requests services from other computers on the network

    • uE.g.
    • print server on a network, that clients (other PCs on the network) can send
    • print jobs to


    • lComputer
    • software that implements communication protocols on the network and helps
    • different systems communicate

    • uData
    • layer

    • lA
    • layer on a client-server configuration that contains the database

    Advantages of WWW over traditional client server approaches 


    • lWeb
    • browser and Internet connections are nearly ubiquitous and are accessible to
    • large numbers of users

    • uLow-cost
    • communication

    • lHigh-capacity
    • WAN form the Internet backbone are funded primarily by governments (a company
    • can use the Internet as a low-cost WAN)

    • uWidely
    • implemented standards

    • lWeb
    • standards are well known  and many
    • computer professionals are trained in their use

    • lUse
    • of intranet or extranet enjoys all the advantages of web delivery

    • lReally
    • represents evolution of client-server computing to the WWW

    Negative aspects of WWW application


    • lWeb
    • servers are well-defined target for security breaches


    • lInternet
    • protocols do not guarantee a minimum level of network throughput or that a
    • message will get sent OK


    • lData
    • transfer capacity of many users limited by analog modems

    • uVolatile
    • standards

    • lWeb
    • standards change rapidly
  21. UML Notation (components and nodes)
    • uComponent
    • symbol –
    • executable module

    • lAll
    • classes complied into single entity

    • lDefined
    • interfaces, or public methods, accessible by other programs or external devices

    • lApplication
    • program interface (API)
    • – set of public methods available to the outside world

    • uNode
    • symbol –
    • physical entity at specific location

    • uFrameset
    • high-level object holds items to be displayed by a browser
  22. Client server and web architectures
  23. Data Flow Diagram
    • •DFD
    • fragment: A DFD that represents the system response to one
    • event
    • within a single
    • process symbol

    • –A
    • fragment is created for each
    • event in the event list – it is a
    • self-contained model showing how the system responds to a single event

    • –Created
    • one at a time

    • –Fig.
    • 6-7 shows 3 DFD fragments for a course registration system

    • –Each
    • fragment represents all processing for an event within a single process symbols

    • –The
    • data stores in the DFD fragment represent entities in the ERD (Entity
    • Relationship Diagram)

    • •Data
    • Flow Diagram (DFD)

    • –A
    • graphical system model that shows all of the main requirements for an
    • information system:  inputs,
    • outputs, processes and data storage

    • –Everyone
    • working on the project (and end users) can see all the aspects of the project
    • in the diagram with minimal training (simple – only 5 symbols)


    • •The
    • square is an external agent

    • –A
    • person or organization, outside the boundary of a system that provides data
    • inputs or accepts data outputs

    • •The
    • rectangle with rounded edges is a process

    • –A
    • symbol that represents an algorithm or procedure by which data inputs are tranformed
    • into data outputs

    • •The
    • lines are data flows

    • –Represents
    • movement of data

    • •The
    • flat three-sided rectangle are data stores (a file or part of a database)

    • –A
    • place where data is held

    • •Figure
    • corresponds to event
    • “Customer wants to check item available”
  24. Objected oriented vs systems analysis and design
  25. Context flow diagrams
    • •Context
    • Diagram:  A DFD that summarizes all processing activity
    • within the system in single
    • process symbol

    • –Describes
    • highest level view of a system

    • –All
    • external agents and all data flows into and out of a system are shown in the
    • diagram

    • –The
    • whole system is represented as one process

    • •Example
    • – shows a context diagram for a university course registration system that
    • interacts with 3 agents: academic dept., student, and faculty member
  26. DFD Diagrams.  Event partition DFD "glue of all the fragments"
    • •DFD
    • fragment: A DFD that represents the system response to one
    • event
    • within a single
    • process symbol

    • –A
    • fragment is created for each
    • event in the event list – it is a
    • self-contained model showing how the system responds to a single event

    • –Created
    • one at a time

    • –Fig.
    • 6-7 shows 3 DFD fragments for a course registration system

    • –Each
    • fragment represents all processing for an event within a single process symbols

    • –The
    • data stores in the DFD fragment represent entities in the ERD (Entity
    • Relationship Diagram)

  27. Rapid development/risk management.  What are the stages of risk managment??
    • •Implement
    • the components from one vendor

    • –Impossible
    • in hospitals with existing systems from various vendors

    • –No
    • one vendor provides across the board good systems in every domain of medicine
    • (very niched market)

    • •Attempt
    • “best of breed” approach

    • –Vendor
    • may say their system will integrate with others but often don’t


    • •Risk
    • Identification

    • –Produces
    • a list of risks that have the potential to disrupt the project’s schedule

    • •Risk
    • Analysis

    • –Assesses
    • the likelihood and impact of each risk and the risk levels of alternative
    • practices

    • •Risk
    • Prioritization

    • –Produces
    • a list of risks prioritized by impact. This list serves as a basis for risk
    • control


    • •Risk
    • Identification

    • –Produces
    • a list of risks that have the potential to disrupt the project’s schedule

    • •Risk
    • Analysis

    • –Assesses
    • the likelihood and impact of each risk and the risk levels of alternative
    • practices

    • •Risk
    • Prioritization

    • –Produces
    • a list of risks prioritized by impact. This list serves as a basis for risk
    • control


    • •First
    • step in managing risk is to identify the
    • factors that pose a risk to your schedule

    • •Three
    • general risks to avoid:

    • –Making
    • one of the classic mistakes

    • –Ignoring
    • the development basics

    • –Failing
    • to actively manage risks described in this lecture

    • •In
    • addition to these there are many
    • other types of risks – can be classified by where they occur in SDLC
  28. UML Sequence diagrams
    • •Use case diagram does not show flow of
    • information

    • •Two types of diagrams describe flow of
    • information and interactions between objects

    • –Collaboration
    • diagram
    • emphasizes the objects that interact together to support a use case

    • –Sequence
    • diagram
    • focuses more on the messages

    • –Those who prefer a top-down approach tend
    • to draw a collaboration diagram

    • –Those who prefer a bottom-up approach
    • tend to draw a sequence diagram

    • •A sequence diagram shows information flow
    • within a single use case or a single scenario

    • •To develop a sequence diagram we use both
    • the class diagram and the flow of events for each scenario

    • –We identify which objects collaborate and
    • what interactions are necessary

    •Sequence Diagrams

    • –Shows the sequence of interactions
    • between objects that occur during the flow of events in a single scenario or
    • use case

    •Four basic symbols in a sequence diagram

    –The actor symbol (a stickman)

    • –The object symbol (a rectangle with the
    • name underlined)

    • –The lifeline symbol (a dashed line or a
    • narrow vertical rectangle)

    • –The message symbol (a directional arrow
    • with a message descriptor)
  29. SSD = System sequence diagram
  30. Selection and procurement... Issues? What are some new approaches?
Card Set
HINF 450 Test 1