HINF 450 Test 1

• •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

• •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!

•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

• •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

•Structure

•Methods

•Controls

•Checklist

• Needed
• for successful development

z

• •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

●

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

•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!!

• 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

DIMENSIONS:

• 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

• 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

4.Heroics

• •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
• IN DEVELOPMENT OF HEALTHCARE SYSTEMS

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

–“politicians”,”researchers”,”isolationists”,”generalists”

• 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

Requirements gathering, quick design, build prototype, evaluate, engineer project

•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

•

•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

• •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

•

• •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

•Inheritance

•Aggregation

• •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

•

• •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

• •Two
• key concepts to model:

–Events

–Things

• •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

•Scenario

• –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

–

• –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

EVENT, TRIGGER, SOURCE, ACTIVITY, RESPONSE, DESTINATION

• •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

• •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

Spiral

• •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

Advantages:

• •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

• 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

uMiddleware

• 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 








uAccessibility

• 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








uSecurity

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

uReliability

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

uThroughput

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

• uVolatile
• standards

• lWeb
• standards change rapidly

• 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

• •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)

EXAMPLE:

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

• •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

• •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)

•

• •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 ASSESSMENT:

• •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 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

RISK IDENTIFICATION:

• •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

• •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)