Upload
sheena-fowler
View
227
Download
2
Tags:
Embed Size (px)
Citation preview
Information SystemsAnalysis and Design
Lê Ngọc Tiến
http://tienhuong.wordpress.com
2
Outline
1. Information Systems: the big picture2. Information Systems for competitive advantage3. Organizational Information Systems4. Entreprise-Wide Information Systems5. Information Systems Development & Acquisition6. Managing the Information Systems Project7. Systems Planning 8. Determining System Requirements9. Structuring System Requirements: Process Modeling10.Structuring System Requirements: Conceptual Data Modeling11.Object Oriented Analysis and Design12.Designing the Human Interface13.Systems Implementation and Operation
Chapter 1
Information Systems:The Big Picture
4
Chapter 1 Objectives
Understand the term information systems (IS)Understand IS components:
Technology, people, organizations
Understand IS career opportunitiesUnderstand types of information systemsUnderstand IS and organizational success or failureUnderstand the future of IS management
5
Information Systems Defined
Combinations of hardware, software, and telecommunications networks that people build and use to collect, create, and distribute useful data in organizations
6
Key Elements of Information Systems
7
Data
Data: raw material, unformatted informationInformation: processed data (meaningful)Knowledge: understanding relationships between pieces of informationWisdom: knowledge accumulated and applied
8
Knowledge as a Business Resource
Knowledge WorkerA well-educated professional who creates, modifies, or synthesizes knowledge in one’s profession
Knowledge SocietyAlso called digital society, new economyWorking with brains instead of handsThe importance of educationDigital divide
9
Technology and Information Systems
Computer-Based Information SystemsOne type of technologyTechnology – any mechanical and/or electrical means to supplement, extend, or replace human activityInformation Technology (IT) – machine technology controlled by or using information
The goal of IS is to provide useful data to usersIS can be local or global, organizational or enterprise-wide
10
IS Managerial Personnel
CIOIS directorAccount ExecutiveInfo Center ManagerDevelopment ManagerProject ManagerMaintenance ManagerSystems ManagerIS planning ManagerOperations ManagerProgramming Manager
Systems Programming ManagerManager of Emerging TechnologiesTelecommunications ManagerNetwork ManagerDatabase AdministratorAuditing or Computer Security ManagerQuality Assurance ManagerWebmaster
11
Integrating Skills and Knowledge
Technologyhardware, software, networking
Businessbusiness, management, social, communications
SystemsIntegration, development methods, critical thinking, problem solving
12
Hot Skills in IS Workers
Office / E-mailLanguagesApplicationsRDBS AdministrationDevelopment ToolsInternetworkingOperating SystemsLAN AdministrationNetworking
13
IS Within the Firm
Traditionally a love/hate relationship“Techies” vs. mere “users” (us vs. them)Poor service, lousy attitudes
Now: progress toward better customer service
Better relationships within the companyCooperation, not rivalry
14
The Spread of Technology in Organizations
Technology infiltrates business unitsDual role for IS workers:
Work with IS technical groupWork with business unit (marketing, finance, etc.)
15
The Spread of Technology in Organizations
Benefits of centralized IS functionCoordinated planningConsistent managementSystems compatibility and connectivity
16
Questions
1.Define and understand the term information systems (IS)
2.Explain the technology, people, and organizational components of an information system.
Chapter 2
Information Systems for Competitive Advantage
18
Chapter 2 Objectives
Understand the IS in automation, organizational learning, and strategic supportUnderstand IS for strategic organizational successUnderstand the need for making an IS business caseUnderstand technological innovations to improve competitive advantage
19
Why Use Information Systems?
Automating: doing things fasterOrganizational learning: doing things betterSupporting Strategy: doing things smarter
20
Automating: Doing Things Faster
Technology is used to automate a manual process
Doing things faster, better, cheaperGreater accuracy and consistency
Loan application exampleManual processingTechnology-supported processCompletely automated
21
Organizational Learning: Doing Things Better
Going beyond automationInvolves learning to improve the day-to-day activities within the processLooking at patterns and trends
Organizational LearningUsing acquired knowledge and insights to improve organizational behavior
Total Quality Management (TQM)Monitoring an organization to improve quality of operations, products, and services
22
Supporting Strategy: Doing Things Smarter
Strategic PlanningCreate a vision: setting the directionCreate a standard: performance targetsCreate a strategy: reaching the goal
23
Question
Now, it should be fairly obvious why an IS professional should be able to make a business case for a given system. Why, however, is it just as important for non-IS professionals? How are they involved in this process? What is their role in information systems planning?
Chapter 3Organizational
Information Systems
25
Chapter Objectives
Understand characteristics of operational, managerial, and executive information systemsUnderstand characteristics of transaction processing systems, management information systems, and executive information systemsUnderstand characteristics of information systems that span organizational boundaries
26
Decision-Making Levels of an Organization
27
Decision-Making Levels of an Organization
Executive level (top)Long-term decisionsUnstructured decisions
Managerial level (middle)Decisions covering weeks and monthsSemistructured decisions
Operational level (bottom)Day-to-day decisionsStructured decisions
28
General Types of Information Systems
Transaction Processing Systems (TPSs)TransactionsUsed at Operational level of the organizationGoal: to automate repetitive information processing activities
Increase speedIncrease accuracyGreater efficiency
29
General Types of Information Systems
Data inputManual data entrySemiautomated data entryFully automated data entry
Examples:PayrollSales and orderingInventoryPurchasing, receiving, shippingAccounts payable and receivable
30
General Types of Information Systems
Management Information Systems (MISs)
Two Types:Management of IS in organizationsSpecific information systems for mid-level managers
Used at managerial level of the organization
31
General Types of Information Systems
Management Information SystemsTypes of reports:
Scheduled reportKey-indicator reportException reportDrill-down reportAd hoc report
32
General Types of Information Systems
Management Information Systems (MISs)
Examples:Sales forecastingFinancial management and forecastingManufacturing planning and schedulingInventory management and planningAdvertising and product pricing
33
General Types of Information Systems
Executive Information Systems (EISs)Used at executive level of the organizationHighly aggregated formData types
Soft data – news and nonanalytical dataHard data – facts and numbers
34
General Types of Information Systems
Executive Information Systems (EISs)Examples:
Executive-level decision makingLong-range and strategic planningMonitoring internal and external eventsCrisis managementStaffing and labor relations
35
1.351.35
36
Information Systems that Span Organizational Boundaries
37
Information Systems that Span Organizational Boundaries
Decision Support Systems (DSSs)Designed to support organizational decision making“What-if” analysis
Example of a DSS tool: Microsoft ExcelText and graphs
Models for each of the functional areasAccounting, finance, personnel, etc.
38
Information Systems that Span Organizational Boundaries
Expert Systems (ESs)Mimics human expertise by manipulating knowledgeRules (If-then)Inferencing
39
Information Systems that Span Organizational Boundaries
Office Automation Systems (OASs)Examples:
Communicating and schedulingDocument preparationAnalyzing dataConsolidating information
40
Information Systems that Span Organizational Boundaries
Collaboration TechnologiesVirtual teamsVideoconferencingGroupwareElectronic Meeting Systems (EMSs)
41
Information Systems that Span Organizational Boundaries
Functional Area Information SystemsGeared toward specific areas in the company:
Human ResourcesBenefitsMarketing
42
43
Information Systems that Span Organizational Boundaries
Global Information SystemsInternational ISTransnational ISMultinational ISGlobal IS
Chapter 4Enterprise-Wide
Information Systems
45
Chapter Objectives
Understand how information technology supports business activitiesUnderstand enterprise systems and how they evolvedUnderstand software applications that are internally or externally focusedUnderstand how to implement enterprise systems
46
Enterprise Systems
Enterprise systemsAlso known as enterprise-wide information systemsInformation systems that allow companies to integrate information across operations on a company-wide basis
47
Before an entreprise system
48
With an entreprise sytem
49
Types of Enterprise Systems
Packaged applicationsCustom applicationsStand-alone applications
50
Types of Enterprise Systems
Enterprise Resource PlanningIntegrated applicationsERP systems
BaanOraclePeopleSoftSAP
51
Types of Enterprise Systems
ERP ImplementationModulesCustomizationsBest practicesBusiness process reengineering (BPR)
52
Types of Enterprise Systems
Customer Relationship Management (CRM)
Sales Force Automation (SFA)New opportunities for competitive advantageExamples:
MGMAmerican AirlinesMarriott International
53
CRM system
54
Types of Enterprise Systems
Supply Chain Management (SCM)Supply chain – the producers of supplies that a company usesSupply networkWhat if supply chain does not collaborate?Two objectives of upstream information flow:
Accelerate product developmentReduce costs associated with suppliers
55
Supply chain management
56
The Formula for Enterprise System Success
Secure executive sponsorshipGet help from outside expertsThoroughly train usersTake a multidisciplinary approach to implementation
57
Questions
1. List the different classes of information systems described in this chapter. How do they differ from each other?
2. Of the information systems listed in the chapter, how many do you have experience with? What systems would you like to work with? What types of systems do you encounter at the university you are attending?
3. Consider an organization that you are familiar with, perhaps the one in which you work or one with which you have done business. Describe the type of information systems that organization uses and whether or not they are useful or up-to-date. List specific examples for updating or installing information systems that improve productivity or efficiency.
Chapter 5Information Systems
Development & Acquisition
59
Chapter Objectives
Understand the process of IS managementUnderstand the system development life cycle (SDLC)Understand alternative approaches to system developmentUnderstand in-house system developmentUnderstand external acquisition, outsourcing, and end-user development
60
The Need for Structured Systems Development
Systems analysis and design – the process of designing, building, and maintaining information systems
Systems analystBlending technical and managerial expertise
61
The Need for Structured Systems Development
Evolution of IS developmentFrom “art” to a “discipline”Standardized development methodsSoftware engineering
62
The Need for Structured Systems Development
Options for Obtaining Information Systems
Build your ownBuy a prepackaged systemOutsource development to a 3rd partyEnd user development
63
The Need for Structured Systems Development
Information Systems Development in Action
Breaking large complex problems into manageable piecesDecomposing large, complex problems
64
The Need for Structured Systems Development
System Construction Process1. Identify a large IT problem to solve 2. Break the large problem into several
smaller, more manageable pieces3. Translate each “piece” (small problem)
into computer programs4. Piece together each program into an
overall comprehensive IS that solves the problem
65
The Need for Structured Systems Development
The Role of Users in the Systems Development Process
Knowledgeable of needsEffective partnership
66
Information Systems Analysis and Design
Systems Analyst performs analysis and design based upon:
Understanding of organization’s objectives, structure and processesKnowledge of how to exploit information technology for advantage
67
Systems Analysis and Design: Core Concepts
Major goal: to improve organizational systems by developing or acquiring software and training employees in its useApplication software, or a system, supports organizational functions or processes
68
Systems Analysis and Design: Core Concepts
System: Turns data into information and includes:
Hardware and system softwareDocumentation and training materialsJob roles associated with the systemControls to prevent theft or fraudThe people who use the software to perform their jobs
69
70
Software Engineering Process
A process used to create an information systemConsists of:
MethodologiesA sequence of step-by-step approaches that help develop the information system
TechniquesProcesses that the analyst follows to ensure thorough, complete and comprehensive analysis and design
ToolsComputer programs that aid in applying techniques
71
72
System
A system is an interrelated set of business procedures used within one business unit working together for a purposeA system has nine characteristicsA system exists within an environmentA boundary separates a system from its environment
73
Characteristics of a System
ComponentsInterrelated ComponentsBoundaryPurposeEnvironmentInterfacesConstraintsInputOutput
74
75
Important System Concepts
DecompositionThe process of breaking down a system into smaller componentsAllows the systems analyst to:
Break a system into small, manageable subsystemsFocus on one area at a timeConcentrate on component pertinent to one group of usersBuild different components at independent times
76
77
Important System Concepts
ModularityProcess of dividing a system into modules of a relatively uniform sizeModules simplify system design
CouplingSubsystems that are dependent upon each other are coupled
CohesionExtent to which a subsystem performs a single function
78
A Modern Approach to Systems Analysis and Design
Systems IntegrationAllows hardware and software from different vendors to work togetherEnables procedural language systems to work with visual programming systemsVisual programming environment uses client/server model
79
Data and Processes
Three key components of an information system
DataData FlowsProcessing Logic
Data vs. InformationData
Raw factsInformation
Derived from dataOrganized in a manner that humans can
understand
80
Data and Processes
DataUnderstanding the source and use of data is key to good system designVarious techniques are used to describe data and the relationship amongst data
Data FlowsGroups of data that move and flow through the systemInclude description of sources and destination for each data flow
Processing LogicDescribe steps that transform data and events that trigger the steps
81
82
Approaches to Systems Development
Process-Oriented ApproachFocus is on flow, use and transformation of data in an information systemInvolves creating graphical representations such as data flow diagrams and chartsData are tracked from sources, through intermediate steps and to final destinationsNatural structure of data is not specifiedDisadvantage: data files are tied to specific applications
83
Approaches to Systems Development (2)
Data-Oriented ApproachDepicts ideal organization of data, independent of where and how data are usedData model describes kinds of data and business relationships among the dataBusiness rules depict how organization captures and processes the data
84
85
Databases and Application Independence
DatabaseShared collection of logically related dataOrganized to facilitate capture, storage and retrieval by multiple usersCentrally managedDesigned around subjects
CustomersSuppliers
Application IndependenceSeparation of data and definition of data from applications
86
Role of the Systems Analyst
Study problems and needs of an organizationDetermine best approach to improving organization through use of:
PeopleMethodsInformation technology
Help system users and managers define their requirements for new or enhanced systems
87
Role of the Systems Analyst
Assess options for system implementation
In-house developmentOutsourced developmentOutsourced development and operationCommercial application
For in-house projects, work on a team of analysts and developers
88
Skills of a Successful Systems Analyst
AnalyticalUnderstanding of organizationsProblem-solving skillsSystem thinking
Ability to see organizations and information systems as systems
TechnicalUnderstanding of potential and limitations of technology
ManagerialAbility to manage projects, resources, risk and change
InterpersonalEffective written and oral communication skills
89
Systems Development Life Cycle
System Development MethodologyStandard process followed in an organizationConsists of:
AnalysisDesignImplementationMaintenance
90
Systems Development Life Cycle
Series of steps used to manage the phases of development for an information systemConsists of four phases:
Planning and SelectionAnalysisDesignImplementation and Operation
91
Systems Development Life Cycle
Phases are not necessarily sequentialEach phase has a specific outcome and deliverableIndividual companies use customized life cycle
92
Phases of the Systems Development Life Cycle
Systems Planning and SelectionTwo Main Activities
Identification of needInvestigation and determination of scope
Systems AnalysisStudy of current procedures and information systems
Determine requirementsGenerate alternative designsCompare alternativesRecommend best alternative
93
Systems Development Life Cycle
System DesignLogical Design
Concentrates on business aspects of the systemPhysical Design
Technical specifications
Implementation and OperationImplementation
Hardware and software installationProgrammingUser TrainingDocumentation
OperationSystem changed to reflect changing conditionsSystem obsolescence
94
95
Alternative approaches
PrototypingBuilding a scaled-down working version of the systemAdvantages:
Users are involved in designCaptures requirements in concrete form
Rapid Application Development (RAD)Utilizes prototyping to delay producing system design until after user requirements are clear
Joint Application Design (JAD)Users, Managers and Analysts work together for several daysSystem requirements are reviewedStructured meetings
96
97
Summary
Information systems analysis and design
Process of developing and maintaining an information system
Modern approach to systems analysisProcess-OrientedData-Oriented
98
Summary
Systems Development Life Cycle (SDLC)Systems Planning and SelectionSystems AnalysisSystems DesignSystems Implementation
Alternatives to Systems Development Life Cycle
PrototypingRapid Application Development (RAD)Joint Application Design (JAD)
99
Questions
1. In what way are organizations systems?2. List and explain the different phases in the systems
development life cycle.3. Why is it important to use systems analysis and
design methodologies when building a system? Why not just build the system in whatever way seems to be “quick and easy”? What value is provided by using an “engineering” approach?
4. Explain the traditional application-based approach to systems development. How is this different from the data-based approach?
5. What is prototyping?6. What is JAD? What is Participatory Design?
Chapter 6 Managing the Information Systems Project
101
Learning Objectives
Discuss skills required to be an effective project managerDescribe skills and activities of a project manager during project initiation, planning, execution and closedownExplain Gantt Charts and Network DiagramsReview commercial project management software packages
102
Case of Pine Valley Furniture
Manufacturing CompanyProduct: Wood FurnitureMarket: U.S.Organized into functional areas
ManufacturingSales
Three independent computer systems were converted to a database in 1990s
103
104
Managing the Information Systems Project
Focus of project managementTo ensure that information system projects meet customer expectations
Delivered in a timely mannerMeet constraints and requirements
105
Project ManagerSystems Analyst responsible for
Project initiationPlanningExecutionClosing down
Requires diverse set of skillsManagementLeadershipTechnicalConflict managementCustomer relations
Managing the Information Systems Project
106
107
Project Management Process
ProjectPlanned undertaking of related activities to reach an objective that has a beginning and an end
Four Phases1. Initiation2. Planning3. Execution4. Closing down
108
Initiating the Project
1. Establish project initiation team2. Establish relationship with customer3. Establish project initiation plan4. Establish management procedures5. Establish project management
environment and workbook
109
Planning the Project
1. Describe project scope, alternatives and feasibility
Scope and FeasibilityUnderstand the projectWhat problem is addressedWhat results are to be achievedMeasures of successCompletion criteria
110
Planning the Project
2. Divide the project into manageable tasks• Work breakdown structure• Gantt chart
3. Estimate resources and create a resource plan
4. Develop a preliminary schedule• Utilize Gantt Charts and Network Diagrams
5. Develop a communication planOutline communication processes among customers, team members and managementTypes of reportsFrequency of reports
111
112
Planning the Project
6. Determine project standards and proceduresSpecify how deliverables are tested and produced
7. Identify and assess riskIdentify sources of riskEstimate consequences of risk
8. Create a preliminary budget9. Develop a statement of work
Describe what the project will deliver
10. Set a baseline project planEstimate of project’s tasks and resources
113
Executing the Project
1. Execute baseline project planAcquire and assign resourcesTrain new team membersKeep project on schedule
2. Monitor project progressAdjust resources, budget and/or activities
3. Manage changes to baseline project planSlipped completion datesChanges in personnelNew activities
4. Maintain project workbook5. Communicate project status
114
Closing Down the Project
1. TerminationTypes of termination
NaturalRequirements have been met
UnnaturalProject stopped
DocumentationPersonnel Appraisal
2. Conduct post-project reviewsDetermine strengths and weaknesses of:
Project deliverablesProject management processDevelopment process
3. Close customer contract
115
Representing and Scheduling Project Plans
Gantt ChartsUseful for depicting simple projects or parts of large projectsShow start and completion dates for individual tasks
Network DiagramsShow order of activities
116
117
118
Summary
Skills of an effective project managerActivities of project manager
InitiationPlanningExecutionClosedown
Gantt Charts and Network DiagramsCommercial PM Software
119
Questions
1. List and describe the common skills and activities of a project manager. Which skill do you think is most important? Why?
2. Describe the activities performed by the project manager during project initiation.
3. Describe the activities performed by the project manager during project planning.
4. Describe the activities performed by the project manager during project execution.
Chapter 7 Systems Planning
121
Learning Objectives
Discuss the content of and need for a Statement of Work and Baseline Project PlanDescribe a structured walkthrough
122
First documents
Baseline Project Plan (BPP) : internal documentScopeBenefitsCostsRisksResources
Statement of Work (SOW) : Outlines objectives and constraints of the project to the customer
Describes deliverablesOutlines work needed to be performed
123
124
Building the Baseline Project Plan
ObjectivesAssures that customer and development group have a complete understanding of the proposed system and requirementsProvides sponsoring organization with a clear idea of scope, benefits and duration of project
Four SectionsIntroductionSystem DescriptionFeasibility AssessmentManagement Issues
125
Building the Baseline Project Plan
IntroductionBrief overviewRecommended course of actionProject scope defined
Units affectedInteraction with other systemsRange of system capabilities
126
Building the Baseline Project Plan
System DescriptionOutline of possible alternative solutionsNarrative format
Feasibility AssessmentProject costs and benefitsTechnical difficultiesHigh-level project schedule
127
Building the Baseline Project Plan
Management IssuesOutlines concerns that management may have about the projectTeam compositionCommunication planProject standards and procedures
128
129
Reviewing the Baseline Project Plan
ObjectivesAssure conformity to organizational standardsAll parties agree to continue with project
130
Reviewing the Baseline Project Plan
WalkthroughPeer group reviewParticipants
CoordinatorPresenterUserSecretaryStandards BearerMaintenance Oracle
ActivitiesWalkthrough review formIndividuals polledWalkthrough action list
AdvantagesAssures that review occurs during project
131
132
133
Summary
Baseline Project Plan (BPP)Created during project initiation and planningContains:
IntroductionHigh-Level description of systemOutline of feasibilityOverview of Management Issues
Statement of Work (SOW)Describes what project will deliverLists all work to be performed
134
Questions
1. What is contained in a Baseline Project Plan? Are the content and format of all baseline plans the same? Why or why not?
2. Describe the structured walkthrough process. What roles need to be performed during a walkthrough?
Chapter 8 Determining System Requirements
136
Learning Objectives
Describe options for designing and conducting interviewsDiscuss planning an interviewDiscuss using questionnaires to determine system requirementsExplain advantages and disadvantages of observing workers and analyzing business documents to determine requirements
137
Learning Objectives
Learn about Joint Application Design (JAD) and PrototypingDiscuss appropriate methods to elicit system requestsExamine requirements determination for Internet applications
138
Activities in Requirement Gathering
1.0Identify the right Stakeholders &Artefacts
1.0Identify the right Stakeholders &Artefacts
0.0Outline information to be sought
0.0Outline information to be sought
2.0Use most appropriate investigation techniques
2.0Use most appropriate investigation techniques
4.0Document the requirements
4.0Document the requirements
Objective: determine the functions & information that must be provided by the information system
3.0Determine duration
3.0Determine duration
139
Performing Requirements Determination
Gather information on what the system should do from many sources
UsersReportsFormsProcedures
140
Performing Requirements Determination
Characteristics for gathering requirementsImpertinence
Question everything
ImpartialityFind the best organizational solution
Relaxation of constraintsAttention to detailReframing
View the organization in new ways
141
Deliverables and Outcomes
Types of deliverables:Information collected from usersExisting documents and filesComputer-based informationUnderstanding of organizational components
Business objectiveInformation needsRules of data processingKey events
142
Deliverables and Outcomes
143
Traditional Methods for Determining Requirements
144
Traditional Methods for Determining Requirements
Interviewing and ListeningGather facts, opinions and speculationsObserve body language and emotionsGuidelines
PlanChecklistAppointment
Be neutralListenSeek a diverse view
Interview QuestionsOpen-Ended
No prespecified answersClose-Ended
Respondent is asked to choose from a set of specified responses
145
146
147
148
Traditional Methods for Determining Requirements
Administering QuestionnairesMore cost-effective than interviewsChoosing respondents
Should be representative of all usersTypes of samples
ConvenientRandom samplePurposeful sampleStratified sample
DesignMostly closed-ended questionsCan be administered over the phone, in person or over the Internet or company intranet
149
Traditional Methods for Determining Requirements
Questionnaires Vs. InterviewsInterviews cost more but yield more informationQuestionnaires are more cost-effective
150
151
Traditional Methods for Determining Requirements
Directly Observing UsersServes as a good method to supplement interviewsOften difficult to obtain unbiased data
People often work differently when being observed
152
Analyzing Procedures and Other Documents
Types of information to be discovered:Problems with existing systemOpportunity to meet new needOrganizational directionNames of key individualsValues of organizationSpecial information processing circumstancesRules for processing data
153
154
Modern Methods for Determining Requirements
Joint Application Design (JAD)Brings together key users, managers and systems analystsPurpose: collect system requirements simultaneously from key peopleConducted off-site
PrototypingRepetitive processRudimentary version of system is builtReplaces or augments SDLCGoal: to develop concrete specifications for ultimate system
155
Joint Application Design (JAD)
ParticipantsSession LeaderUsersManagersSponsorSystems AnalystsScribeIS Staff
End ResultDocumentation detailing existing systemFeatures of proposed system
156
157
Prototyping
Quickly converts requirements to working version of systemOnce the user sees requirements converted to system, will ask for modifications or will generate additional requestsMost useful when:
User requests are not clearFew users are involved in the systemDesigns are complex and require concrete formHistory of communication problems between analysts and usersTools are readily available to build prototype
158
Prototyping
DrawbacksTendency to avoid formal documentationDifficult to adapt to more general user audienceSharing data with other systems is often not consideredSystems Development Life Cycle (SDLC) checks are often bypassed
159
Summary
InterviewsOpen-ended and close-ended questionsPreparation is key
QuestionnairesMust be carefully designedCan contain close-ended as well as open-ended questions
160
Summary
Other means of gathering requirementsObserving workersAnalyzing business documents
Joint Application Design (JAD)Prototyping
161
Questions (1)
1. Describe systems analysis and the major activities that occur during this phase of the systems development life cycle.
2. What are some useful character traits for an analyst involved in requirements determination?
3. Describe four traditional techniques for collecting information during analysis. When might one be better than another?
4. What are the general guidelines for conducting interviews?5. What are the general guidelines for designing questionnaires?6. Compare collecting information by interview and by
questionnaire. Describe a hypothetical situation in which each of these methods would be an effective way to collect information system requirements.
162
Questions (2)
7. What are the general guidelines for collecting data through observing workers?
8. What are the general guidelines for collecting data through analyzing documents?
9. Describe how prototyping can be used during requirements determination. How is it better or worse than traditional methods?
Chapter 9 Structuring System Requirements:
Process Modeling
164
Learning Objectives
Understand the logical modeling of processes through studying data flow diagramsHow to draw data flow diagrams using rules and guidelinesHow to decompose data flow diagrams into lower-level diagramsBalancing of data flow diagrams
165
Learning Objectives
Discuss the use of data flow diagrams as analysis tools Discuss process modeling for Internet Applications
166
Process Modeling
Graphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system componentsData flow diagrams (DFD)
Graphically illustrate movement of data between external entities and the processes and data stores within a system
167
Process Modeling
Modeling a system’s processUtilize information gathered during requirements determinationStructure of the data is also modeled in addition to the processes
Deliverables and OutcomesSet of coherent, interrelated data flow diagrams
168
Process Modeling
Deliverables and outcomes (continued)Context data flow diagram (DFD)
Scope of system
DFDs of current systemEnables analysts to understand current system
DFDs of new logical systemTechnology independentShow data flows, structure and functional requirements of new system
169
170
Data Flow Diagramming Mechanics
Data FlowDepicts data that are in motion and moving as a unit from one place to another in the systemDrawn as an arrowSelect a meaningful name to represent the data
171
Data Flow Diagramming Mechanics
Data StoreDepicts data at restMay represent data in:
File folderComputer-based fileNotebook
Drawn as a rectangle with the right hand vertical line missingLabel includes name of the store as well as the number
172
Data Flow Diagramming Mechanics
ProcessDepicts work or action performed on data so that they are transformed, stored or distributedDrawn as a rectangle with rounded cornersNumber of process as well as name are recorded
173
Data Flow Diagramming Mechanics
Source/SinkDepicts the origin and/or destination of the dataSometimes referred to as an external entityDrawn as a square symbolName states what the external agent isBecause they are external, many characteristics are not of interest to us
174
175
176
Data Flow Diagramming Definitions
Context DiagramA data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system
Level-O DiagramA data flow diagrams (DFD) that represents a system’s major processes, data flows and data stores at a higher level
177
Developing DFDs: An Example
Hoosier Burger’s automated food ordering systemContext Diagram contains no data stores
178
179
Developing DFDs: An Example
Next step is to expand the context diagram to show the breakdown of processes
180
181
Data Flow Diagramming Rules
Basic rules that apply to all DFDsInputs to a process are always different than outputsObjects always have a unique name
In order to keep the diagram uncluttered, you can repeat data stores and data flows on a diagram
182
Data Flow Diagramming Rules
ProcessA. No process can have
only outputs (a miracle)
B. No process can have only inputs (black hole)
C. A process has a verb phrase label
Data StoreD. Data cannot be moved
from one store to another
E. Data cannot move from an outside source to a data store
F. Data cannot move directly from a data store to a data sink
G. Data store has a noun phrase label
183
Data Flow Diagramming Rules
Source/SinkH. Data cannot move
directly from a source to a sink
I. A source/sink has a noun phrase label
Data FlowJ. A data flow has only
one direction of flow between symbols
K. A fork means that exactly the same data go from a common location to two or more processes, data stores or sources/sinks
184
Data Flow Diagramming Rules
Data Flow (Continued)L. A join means that exactly the same data come from
any two or more different processes, data stores or sources/sinks to a common location
M. A data flow cannot go directly back to the same process it leaves
N. A data flow to a data store means updateO. A data flow from a data store means retrieve or useP. A data flow has a noun phrase label
185
Decomposition of DFDs
Functional decompositionAct of going from one single system to many component processesRepetitive procedureLowest level is called a primitive DFD
Level-N DiagramsA DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram
186
Balancing DFDs
When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decompositionThis is called balancingExample: Hoosier Burgers
In Figure 5-4, notice that there is one input to the system, the customer orderThree outputs:
Customer receiptFood orderManagement reports
187
Balancing DFDs
Example (Continued)Notice Figure 5-5. We have the same inputs and outputsNo new inputs or outputs have been introducedWe can say that the context diagram and level-0 DFD are balanced
188
Balancing DFDs:An Unbalanced Example
In context diagram, we have one input to the system, A and one output, BLevel-0 diagram has one additional data flow, CThese DFDs are not balanced
189
Balancing DFDs
We can split a data flow into separate data flows on a lower-level diagram
190
Balancing DFDs:Four Additional Advanced Rules
191
Guidelines for Drawing DFDs
1. CompletenessDFD must include all components necessary for systemEach component must be fully described in the project dictionary or CASE repository
2. ConsistencyThe extent to which information contained on one level of a set of nested DFDs is also included on other levels
192
Guidelines for Drawing DFDs
3. TimingTime is not represented well on DFDsBest to draw DFDs as if the system has never started and will never stop
4. Iterative DevelopmentAnalyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled
5. Primitive DFDsLowest logical level of decompositionDecision has to be made when to stop decomposition
193
Using DFDs as Analysis Tools
Gap AnalysisThe process of discovering discrepancies between two or more sets of data flow diagrams or discrepancies within a single DFD
Inefficiencies in a system can often be identified through DFDs
194
Using DFDs in Business Process Reengineering
Example: IBM CreditCredit approval process required six days before Business Process Reengineering (see Fig 5-12)
195
Using DFDs in Business Process Reengineering
After Business Reprocess Engineering, IBM was able to process 100 times the number of transactions in the same amount of time
196
Summary
Data flow diagrams (DFD)SymbolsRules for creatingDecompositionBalancing
DFDs for AnalysisDFDs for Business Process Reengineering (BPR)
197
Questions
1. What is a data flow diagram? Why do systems analysts use data flow diagrams?
2. What is decomposition? What is balancing? How can you determine if DFDs are not balanced?
3. Explain the convention for naming different levels of data flow diagrams.
4. How can data flow diagrams be used as analysis tools?
Chapter 10Structuring System Requirements:
Conceptual Data Modeling
199
Learning Objectives
Define key data-modeling termsConceptual data modelEntity-Relationship (E-R) diagram Entity typeEntity instanceAttributeCandidate keyMultivalued attributesRelationshipDegreeCardinalityAssociative entity
200
Learning Objectives
Ask the right kinds of questions to determine data requirements for an ISLearn to draw entity-relationship diagrams (ERD)Review the role of conceptual data modeling in overall design and analysis of an information systemDiscuss relationships and associative entitiesDiscuss relationship between data modeling and process modeling
201
Conceptual Data Modeling
Representation of organizational dataPurpose is to show rules about the meaning and interrelationships among dataEntity-Relationship (E-R) diagrams are commonly used to show how data are organizedMain goal of conceptual data modeling is to create accurate E-R diagramsMethods such as interviewing, questionnaires and JAD are used to collect informationConsistency must be maintained between process flow, decision logic and data modeling descriptions
202
Process of Conceptual Data Modeling
First step is to develop a data model for the system being replacedNext, a new conceptual data model is built that includes all the requirements of the new systemIn the design stage, the conceptual data model is translated into a physical designProject repository links all design and data modeling steps performed during SDLC
203
Deliverables and Outcomes
Primary deliverable is the entity-relationship diagramThere may be as many as 4 E-R diagrams produced and analyzed during conceptual data modeling
Covers just data needed in the project’s applicationE-R diagram for system being replacedAn E-R diagram for the whole database from which the new application’s data are extractedAn E-R diagram for the whole database from which data for the application system being replaced are drawn
204
205
Deliverables and Outcomes
Second deliverable is a set of entries about data objects to be stored in repository or project dictionary
Repository links data, process and logic models of an information systemData elements that are included in the DFD must appear in the data model and converselyEach data store in a process model must relate to business objects represented in the data model
206
Gathering Information for Conceptual Data Modeling
Two perspectivesTop-down
Data model is derived from an intimate understanding of the business
Bottom-upData model is derived by reviewing specifications and business documents
207
Introduction to Entity-Relationship (E-R) Modeling
Notation uses three main constructsData entitiesRelationshipsAttributes
Entity-Relationship (E-R) DiagramA detailed, logical and graphical representation of the entities, associations and data elements for an organization or business
208
Entity-Relationship (E-R) ModelingKey Terms
EntityA person, place, object, event or concept in the user environment about which the organization wishes to maintain dataRepresented by a rectangle in E-R diagrams
Entity TypeA collection of entities that share common properties or characteristics
AttributeA named property or characteristic of an entity that is of interest to an organization
209
210
Entity-Relationship (E-R) ModelingKey Terms
Candidate keys and identifiersEach entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same typeCandidate key
Attribute (or combination of attributes) that uniquely identifies each instance of an entity type
211
Entity-Relationship (E-R) ModelingKey Terms
IdentifierA candidate key that has been selected as the unique identifying characteristic for an entity typeSelection rules for an identifier
Choose a candidate key that will not change its valueChoose a candidate key that will never be nullAvoid using intelligent keysConsider substituting single value surrogate keys for large composite keys
212
Entity-Relationship (E-R) ModelingKey Terms
Multivalued AttributeAn attribute that may take on more than one value for each entity instanceRepresented on E-R Diagram in two ways:
Double-lined ellipseWeak entity
213
Entity-Relationship (E-R) ModelingKey Terms
RelationshipAn association between the instances of one or more entity types that is of interest to the organizationAssociation indicates that an event has occurred or that there is a natural link between entity typesRelationships are always labeled with verb phrases
214
Conceptual Data Modeling and the E-R Diagram
GoalCapture as much of the meaning of the data as possible
Result A better design that is easier to maintain
215
Degree of Relationship
DegreeNumber of entity types that participate in a relationship
Three casesUnary
A relationship between the instances of one entity typeBinary
A relationship between the instances of two entity types
TernaryA simultaneous relationship among the instances of three entity typesNot the same as three binary relationships
216
217
Cardinality
The number of instances of entity B that can be associated with each instance of entity AMinimum Cardinality
The minimum number of instances of entity B that may be associated with each instance of entity A
Maximum CardinalityThe maximum number of instances of entity B that may be associated with each instance of entity A
218
Electronic Commerce Development: Conceptual Data Model
Conceptual data modeling for Internet applications is no different than the processed followed for other types of applicationsPine Valley Furniture WebStore
Four entity types definedCustomerInventoryOrderShopping cart
219
220
ER diagram for Pine Valley furniture
222
223
Summary
Process of conceptual data modelingDeliverablesGathering information
Entity-Relationship ModelingEntitiesAttributesCandidate keys and identifiersMultivalued attributes
Degree of relationship
224
Summary
CardinalityAssociative entitiesConceptual data modeling and Internet development
225
Questions
1. List the four types of E-R diagrams produced and analyzed during conceptual data modeling.
2. What elements of a data flow diagram should be analyzed as part of data modeling?
3. What is the degree of a relationship? Give an example of each of the relationship degrees illustrated in this chapter.
4. Explain why a ternary relationship is not the same as three binary relationships.
5. Which of the following types of relationships can have attributes associated with them: one-to-one, one-to-many, many-to-many?
6. Give an example of a ternary relationship (different from any example in this chapter.)
Chapter 11Object-Oriented Analysis and Design
227
Learning Objectives
Discuss the concepts and principles underlying the object-oriented approachLearn to develop requirements models using use-case diagramsLearn to develop requirements models using state and sequence diagramsLearn to use class diagrams to develop object models of the problem domain
228
The Object-Oriented Modeling Approach
Benefits1. The ability to tackle more challenging problem
domains2. Improved communication among users, analysts,
designers and programmers3. Reusability of analysis, design and programming
results4. Increased consistency among the models
developed during object-oriented analysis, design, and programming
5. Explicit representation of commonality among system components
229
The Object-Oriented Modeling Approach
Object-Oriented systems development life cycle:
Process of progressively developing representation of a system component (or object) through the phases of analysis, design and implementationThe model is abstract in the early stagesAs the model evolves, it becomes more and more detailed
230
The Object-Oriented Systems Development Life Cycle
Analysis PhaseModel of the real-world application is developed showing its important propertiesModel specifies the functional behavior of the system independent of implementation details
Design PhaseAnalysis model is refined and adapted to the environment
Implementation PhaseDesign is implemented using a programming language or database management system
231
The Object-Oriented Systems Development Life Cycle
Unified Modeling Language (UML)A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business modelsTechniques and notations
Use casesSequence diagrams Activity diagramsClass diagramsState diagrams
232
Components ViewComponents View
An architecture-based vision
Deployment ViewDeployment ViewProcess ViewProcess View
Logical ViewLogical View
Use Case ViewUse Case View
Functional needsMajor classes
Functional needsMajor classes
codingcoding
System performancesSystem performances Servers and network organization
Servers and network organization
233
Use Cases diagramsFunctional modelling
Sequence Diagrams Dynamic modelling of
scenarios
Class DiagramsStatic modelling
System’s structure
Collaboration diagramDynamic modelling, focusing on spatial
relationships between objects
Statecharts DiagramsDynamic modelling,
focusing on an object. Activities done in each
state correspond to operations
Activity DiagramsDynamic modelling,
focusing on an activity
Objects DiagramsStatic modelling
Context
1
234
Use-Case Modeling
Applied to analyze functional requirements of the systemPerformed during the analysis phase to help developers understand functional requirements of the system without regard for implementation detailsUse Case
A complete sequence of related actions initiated by an actor
ActorAn external entity that interacts with the system
235
Use-Case Modeling
Use cases are always initiated by an actorUse cases represent complete functionality of the systemUse cases may participate in relationships with other use-casesUse cases may also use other use cases
236
Use cases diagram
Use cases diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.Use cases diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system.
Here is a scenario for a medical clinic: 1. A patient calls the clinic to make an appointment for a yearly
checkup. 2. The receptionist finds the nearest empty time slot in the
appointment book 3. and schedules the appointment for that time slot
A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play
237
A use case and his actor
238
A use case diagram
239
240
Explanation
A system boundary rectangle separates the clinic system from the external actors.A use case generalization shows that one use case is simply a special kind of another. Pay Bill is a parent use case and Bill Insurance is the child. A child can be substituted for its parent whenever necessary. Generalization appears as a line with a triangular arrow head toward the parent use case.Include relationships factor use cases into additional ones. Includes are especially helpful when the same use case can be factored out of two different use cases. Both Make Appointment and Request Medication include Check Patient Record as a subtask. In the diagram, include notation is a dotted line beginning at base use case ending with an arrows pointing to the include use case. The dotted line is labeled <<include>>.An extend relationship indicates that one use case is a variation of another. Extend notation is a dotted line, labeled <<extend>>, and with an arrow toward the base case. The extension point, which determines when the extended case is appropriate, is written inside the base case.
241
242
Use case diagrams are helpful in three areas
Determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape. Communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. Generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.
Use case example
Online HR system
244
245
246
Update Benefits description
247
Dynamic Modeling:Sequence Diagrams
Sequence DiagramA depiction of the interaction among objects during certain periods of time
ActivationThe time period during which an object performs an operation
MessagesMeans by which objects communicate with each other
248
249
250
Explanation
The Reservation window sends a makeReservation() message to a HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation.Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message.In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration (to make sure there is available room for each day of the stay in the hotel). The expression in square brackets, [ ], is a condition.The diagram has a clarifying note, which is text inside a dog-eared rectangle. Notes can be put into any kind of UML diagram.
251
Collaboration diagram
Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links.The object-role rectangles are labeled with either class or object names (or both). Class names are preceded by colons ( : ).Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.
252
Collaboration diagram
253
Activity diagram
An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related
While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.
For our example, we used the following process."Withdraw money from a bank account through an ATM."The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.
254
255
Class diagrams
A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static: they display what interacts but not what happens when they do interact
256
Class notations
257
Class stereotypes
258
Example
The following class diagram models a customer order from a retail catalog.
The central class is the Order. Associated with it are the Customer making the purchase and the Payment.
A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.
259
260
Representing Associations
AssociationA relationship between object classesDegree may be unary, binary, ternary or higherDepicted as a solid line between participating classes
Association RoleThe end of an association where it connects to a classEach role has multiplicity, which indicates how many objects participate in a given association relationship
261
262
Representing Generalization
GeneralizationAbstraction of common features among multiple classes, as well as their relationships, into a more general class
SubclassA class that has been generalized
SuperclassA class that is composed of several generalized subclasses
263
Representing Generalization
DiscriminatorShows which property of an object class is being abstracted by a generalization relationship
InheritanceA property that a subclass inherits the features from its superclass
Abstract ClassA class that has no direct instances, but whose descendents may have direct instances
Concrete ClassA class that can have direct instances
264
265
266
Representing Aggregation
AggregationA part-of relationship between a component object and an aggregate objectExample: Personal computer
Composed of CPU, Monitor, Keyboard, etc
267
Composition and Aggregation
Associations in which an object is part of a whole are aggregations. Composition is a strong association in which the part can belong to only one whole
The part cannot exist without the whole. Composition is denoted by a filled diamond at the whole end.
The following diagram shows that a BoxOffice belongs to exactly one MovieTheater. Destroy the MovieTheater and the BoxOffice goes away!
The collection of Movies is not so closely bound to the MovieTheater.
268
269
Dependencies and constraints
A dependency is a relation between two classes in which a change in one may force changes in the other. Dependencies are drawn as dotted lines.
In the class diagram below, Co_op depends on Company. If you decide to modify Company, you may have to change Co_op too.
A constraint is a condition that every implementation of the design must satisfy. Constraints are written in curly braces { }.
The constraint on our diagram indicates that a Section can be part of a CourseSchedule only if it is not canceled.
270
271
Packages
To simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements.
Packages appear as rectangles with small tabs at the top. The package name is on the tab or inside the rectangle. The dotted arrows are dependencies: One package depends on another if changes in the other could possibly force changes in the first.
272
273
Object diagrams
Object diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.This small class diagram shows that a university Department can contain lots of other Departments.
274
275
Object ModelingObject Diagrams
Object Diagramalso called an instance diagramObject is represented as a rectangle with two compartments
OperationA function or service that is provided by all the instances of a class
EncapsulationThe technique of hiding the internal implementation details of an object from its external view
276
Objects notations
277
278
Statecharts diagram
Objects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state.State
A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some eventsShown as a rectangle with rounded corners
State TransitionThe changes in the attribute of an object or in the links an object has with other objectsShown as a solid arrowDiagrammed with a guard condition and action
EventSomething that takes place at a certain point in time
279
Example
Our example diagram models the login part of an online banking system.
Logging in consists of entering a valid social security number and personal id number, then submitting the information for validation.Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN, Validating, and Rejecting. From each state comes a complete set of transitions that determine the subsequent state.
280
281
Explanation
Our diagram has two self-transition, one on Getting SSN and another on Getting PIN.The initial state (black circle) is a dummy to start the action. Final states are also dummy states that terminate the action.The action that occurs as a result of an event or condition is expressed in the form /action. While in its Validating state, the object does not wait for an outside event to trigger a transition. Instead, it performs an activity. The result of that activity determines its subsequent state.
282
283
Moving to Design
Start with existing set of analysis modelProgressively add technical detailsDesign model must be more detailed than analysis modelComponent Diagram
A diagram that shows the software components or modules and their dependencies
Deployment DiagramA diagram that shows how the software components, process and objects are deployed into the physical architecture of the system
284
Component and deployment diagrams
A component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams show the physical configurations of software and hardware.The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions.The physical hardware is made up of nodes. Each component belongs on a node. Components are shown as rectangles with two tabs at the upper left.
285
286
Summary
Object-Oriented modeling approachBenefitsUnified Modeling Language
Use casesClass diagramsState diagramsSequence diagrams
Use-case modeling
287
Summary
Object Modeling: Class DiagramsAssociationsGeneralizationsAggregation
Dynamic Modeling: State DiagramsDynamic Modeling: Sequence DiagramsMoving to Design
Chapter 12Designing the Human Interface
289
Learning Objectives
Explain the process of designing forms and reports and the deliverables for their creationDiscuss general guidelines for formatting text, tables and listsLearn how to effectively format text, tables and listsExplain the process of designing interfaces and dialogues and the deliverables for their creation
290
Learning Objectives
Discuss the general guidelines for interface design including:
Layout and designStructuring data entry fieldsProviding feedbackSystem help
Discuss the design of human-computer dialogues and the use of dialogue diagrammingExplain interface design guidelines unique to the design of Internet-based electronic commerce systems
291
Designing Forms and Reports
System inputs and outputs are produced at the end of the analysis phase
Precise appearance was not defined during this phase
Forms and reports are integrally related to DFD and E-R diagrams
292
Designing Forms and Reports:Key Concepts
FormA business document that contains some predefined data and may include some areas where additional data are to be filled inAn instance of a form is typically based on one database record
ReportA business document that contains only predefined dataA passive document for reading or viewing dataTypically contains data from many database records or transactions
293
The Process of Designing Forms and Reports
User-focused activityFollows a prototyping approachRequirements determination
Who will use the form or report?What is the purpose of the form or report?When is the report needed or used?Where does the form or report need to be delivered and used?How many people need to use or view the form or report?
294
The Process of Designing Forms and Reports
PrototypingInitial prototype is designed from requirementsUsers review prototype design and either accept the design or request changesIf changes are requested, the construction-evaluation-request cycle is repeated until the design is accepted
295
Deliverables and Outcomes
Design specifications are major deliverable and contain three sections
1. Narrative2. Screen Design3. Testing and usability assessment
296
General Formatting Guidelines for Forms and Reports
HighlightingUse sparingly to draw user to or away from certain informationBlinking and audible tones should only be used to highlight critical information requiring user’s immediate attentionMethods should be consistently selected and used based upon level of importance of emphasized information
297
298
299
General Formatting Guidelines for Forms and Reports
Displaying TextDisplay text in mixed upper- and lowercase and use conventional punctuationUse double spacing if space permits. If not, place a blank line between paragraphsLeft-justify text and leave a ragged right marginDo not hyphenate words between linesUse abbreviations and acronyms only when they are widely understood by users and are significantly shorter than the full text
300
General Formatting Guidelines for Forms and Reports
Displaying tables and listsLabels
All columns and rows should have meaningful labelsLabels should be separated from other information by using highlightingRedisplay labels when the data extend beyond a single screen or page
301
General Formatting Guidelines for Forms and Reports
Displaying tables and lists (continued)Formatting columns, rows and text
Sort in a meaningful orderPlace a blank line between every 5 rows in long columnsSimilar information displayed in multiple columns should be sorted verticallyColumns should have at least two spaces between themAllow white space on printed reports for user to write notesUse a single typeface, except for emphasisUse same family of typefaces within and across displays and reportsAvoid overly fancy fonts
302
General Formatting Guidelines for Forms and Reports
Displaying tables and lists (continued)Formatting numeric, textual and alphanumeric data
Right-justify numeric data and align columns by decimal points or other delimiterLeft-justify textual data. Use short line length, usually 30 to 40 characters per lineBreak long sequences of alphanumeric data into small groups of three to four characters each
303
304
305
306
Designing Interfaces and Dialogues
Focus on how information is provided to and captured from usersDialogues are analogous to a conversation between two peopleA good human-computer interface provides a unifying structure for finding, viewing and invoking the different components of a system
307
Designing Interfaces
Designing LayoutsStandard formats similar to paper-based forms and reports should be usedScreen navigation on data entry screens should be left-to-right, top-to-bottom as on paper forms
308
Designing Layouts
Flexibility and consistency are primary design goals
Users should be able to move freely between fieldsData should not be permanently saved until the user explicitly requests thisEach key and command should be assigned to one function
309
Structuring Data Entry
Entry Never require data that are already online or that can be computed
Defaults Always provide default values when appropriate
Units Make clear the type of data units requested for entry
Replacement Use character replacement when appropriate
Captioning Always place a caption adjacent to fields
Format Provide formatting examples
Justify Automatically justify data entries
Help Provide context-sensitive help when appropriate
310
Controlling Data Input
One objective of interface design is to reduce data entry errorsRole of systems analyst is to anticipate user errors and design features into the system’s interfaces to avoid, detect, and correct data entry mistakesTable 8-9 describes types of data entry errorsTable 8-10 lists techniques used by system designers to detect errors
311
312
313
Providing Feedback
1. Status InformationKeeps users informed of what is going on in systemDisplaying status information is especially important if the operation takes longer than a second or two
2. Prompting CuesBest to keep as specific as possible
3. Error and Warning MessagesMessages should be specific and free of error codes and jargonUser should be guided toward a result rather than scoldedUse terms familiar to userBe consistent in format and placement of messages
314
Providing Help
Place yourself in user’s place when designing helpGuidelines
SimplicityHelp messages should be short and to the point
OrganizationInformation in help messages should be easily absorbed by users
DemonstrateIt is useful to explicitly show users how to perform an operation
315
Providing Help
Context-Sensitive HelpEnables user to get field-specific help
Users should always be returned to where they were when requesting help
316
Designing Dialogues
DialogueSequence in which information is displayed to and obtained from a user
Primary design guideline is consistency in sequence of actions, keystrokes, and terminologyThree-step process1. Design dialogue sequence2. Build a prototype3. Assess usability
317
Designing the Dialogue Sequence
Define the sequenceHave a clear understanding of the user, task, technological and environmental characteristicsDialogue Diagram
A formal method for designing and representing human-computer dialogues using box and line diagramsConsists of a box with three sections
Top: Unique display reference number used by other displays for referencing dialogueMiddle: Contains the name or description of the displayBottom: Contains display reference numbers that can be accessed from the current display
318
319
Designing Dialogues:Building Prototypes and Assessing
Usability
Often optional activitiesTask is simplified by using graphical design environment
320
321
Web-based Application:Designing Interfaces and Dialogues for Pine Valley
Furniture’s Webstore
General GuidelinesSeveral factors have contributed to poor design of Web interfaces
Web’s single “click-to-act” method of loading static hypertext documentsLimited capabilities of most Web-browsers to support finely grained user interactivityLimited agreed-upon standards for encoding Web content and control mechanismsLack of maturity in Web scripting and programming languages
322
Web-based Application:Designing the Human Interface at Pine Valley
Furniture
Design GuidelinesNavigation via cookie crumbs
A technique that uses a series of tabs on a Web page to show users where they are and where they have been in the siteTabs are hyperlinks to allow users to move backward easily within the siteTwo important purposes
Allows users to navigate to a point previously visitedShows users where they have been and how far they have gone from point of entry into site
323
Web-based Application: Design Guidelines
Lightweight GraphicsThe use of small images to allow a Web page to be displayed more quickly
Forms and Data IntegrityAll forms that record information should be clearly labeled and provide room for inputClear examples of input should be provided to reduce data errorsSite must clearly designate which fields are required, which are optional and which have a range of values
324
Summary
Designing Forms and ReportsGeneral guidelines for designing forms and reportsFormatting text, tables and listsDesign guidelines for interfaces
Layout designStructuring data entry fieldsProviding feedbackDesigning help
325
Questions
1. To which initial questions must the analyst gain answers in order to build an initial prototype of a system output?
2. Describe the process of designing interfaces and dialogues. What deliverables are produced from this process? Are these deliverables the same for all types of system projects? Why or why not?
Chapter 13Systems Implementation and Operation
327
Learning Objectives
Describe the process of coding, testing and converting an organizational information systemDiscuss four installation strategies
DirectParallelSingle locationPhased installation
Describe the deliverables for documenting the system and for training and supporting the usersCompare the many modes available for organizational system training, including self-training and electronic performance support systems
328
Learning Objectives
Discuss the issues of providing support to end usersDiscuss system implementation failureExplain four types of maintenanceDescribe several factors that influence the cost of maintaining an information system
329
System Implementation and Maintenance
Seven major activitiesCodingTestingInstallationDocumentationTrainingSupportMaintenance
PurposeTo convert final physical system specifications into working and reliable softwareTo document work that has been doneTo provide help for current and future users
330
The Process of Coding, Testing and Installation
CodingPhysical design specifications are turned into working computer code
TestingTests are performed using various strategiesTesting can be performed in parallel with coding
InstallationProcess during which the current system is replaced by the new system
331
Deliverables
Action Deliverable Coding Code
Program Documentation Testing Test scenarios (test plan) and test data
Results of program and system testing Installation User guides
User training plans Installation and conversion plan
332
The Process of Documenting the System, Training Users and Supporting Users
Two audiences for documentationThe information systems personnel who will maintain the system throughout its productive lifeThe people who will use the system as part of their daily lives
333
Deliverables
DocumentationSystem documentationUser documentation
User training planClassesTutorials
User training modulesTraining materialsComputer-based training aids
User support planHelp deskOn-line helpBulletin boards and other support mechanisms
334
The Process of Maintaining Information Systems
Process of returning to the beginning of the SDLC and repeating development steps focusing on system change until the change is implementedFour major activities
1. Obtaining maintenance requests2. Transforming requests into changes3. Designing changes4. Implementing changes
335
336
Deliverables
Development of a new version of the software, new versions of all design documents and training materials created or modified during the maintenance effort
337
Software Application Testing
A test plan is developed during the analysis phaseDuring the design phase, a unit test plan and a system test plan are developedThe actual testing is done during implementationTest plans provide improved communication among all parties involved in testing
Serve as checklists
338
Types of Testing
InspectionA testing technique in which participants examine program code for predictable language-specific errors
WalkthroughA peer group review of any product created during the systems development process; also called a structured walkthrough
Desk CheckingA testing technique in which the program code is sequentially executed manually by the reviewer
339
Types of Testing
Unit TestingEach module is tested alone in an attempt to discover any errors in its code, also called module testing
Integration TestingThe process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in a top-down, incremental fashion
340
Types of Testing
System TestingThe bringing together of all the programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion
Stub TestingA technique used in testing, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules
341
The Testing Process
1. The purpose of the testing is confirming that the system satisfies requirements
2. Testing must be plannedTest Case
A specific scenario of transactions, queries or navigation paths that represent a typical, critical or abnormal use of the systemTest cases and results should be thoroughly documented so they can be repeated for each revision of an application
342
343
Acceptance Testing by Users
The process whereby actual users test a completed information system, the end result of which is the users’ acceptance of it
344
Acceptance Testing by Users
Alpha TestingUser testing of a completed information system using simulated dataRecovery testing
Forces the software (or environment) to fail in order to verify that recovery is properly performed
Security testingVerifies that protection mechanisms built into the system will protect it from improper penetration
Stress testingTries to break the system
Performance testingDetermines how the system performs on the range of possible environments in which it may be used
345
Acceptance Testing by Users
Beta TestingUser testing of a completed information system using real data in the real user environment
346
Installation
The organizational process of changing over from the current information system to a new oneFour approaches
Direct InstallationChanging over from the old information system to a new one by turning off the old system when the new one is turned on
Parallel InstallationRunning the old information system and the new one at the same time until management decides the old system can be turned off
347
Installation
Single location installationTrying out an information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization
Phased InstallationChanging from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system
348
349
Planning Installation
ConsiderationsData conversion
Error correctionLoading from current system
Planned system shutdownBusiness cycle of organization
350
Documenting the System
System documentationDetailed information about a system’s design specifications, its internal workings and its functionalityInternal documentation
System documentation that is part of the program source code or is generated at compile time
External documentationSystem documentation that includes the outcome of structured diagramming techniques such as data flow and entity relationship diagrams
351
Documenting the System
User DocumentationWritten or other visual information about an application system, how it works, and how to use it
Preparing user documentationTraditional source has been information systems departmentApplication-oriented documentation is now often supplied by vendors and users themselves
352
Training Information System Users
Potential training topicsUse of the systemGeneral computer conceptsInformation system conceptsOrganizational conceptsSystem managementSystem installation
353
Training Information System Users
Training methodsResident expertComputer-aided instructionFormal coursesSoftware help componentsTutorialsInteractive training manualsExternal sources, such as vendors
354
355
Training Information System Users
Electronic performance support system (EPSS)
Component of a software package or application in which training and educational information is embedded
356
Supporting Information System Users
Support is extremely important to usersJ.D. Power and Associates survey found user support to be number one criterion contributing to user satisfaction with personal computing
Most organizations provide support by two means
Information centerHelp desk
357
Supporting Information System Users:Information Center
An organizational unit whose mission is to support users in exploiting information technologyStaff might perform the following tasks
Install new hardware or software and set up user accountsConsult with users writing programs in fourth-generation languagesExtract data from organizational databases onto personal computersAnswer basic on-demand questionsProvide a demonstration site for viewing hardware and softwareWork with users to submit system change requests
358
Supporting Information System Users:Help Desk
A single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department
359
Why Implementation Sometimes Fails
Two conditions necessary for a successful implementation
Management support of the system under developmentInvolvement of users in the development process
360
Why Implementation Sometimes Fails
Insights about implementation process
RiskCommitment to the projectCommitment to changeExtent of project definition and planningRealistic user expectations
Implementation success factorsExtent to which system is usedUser’s satisfaction with system
361
Project Close Down
Evaluate teamReassign members to other projects
Notify all affected parties that the development project is ending and that you are switching to operation and maintenance modeConduct post-project reviewsClose out customer contract
Formal signoff
362
Conducting System Maintenance
Corrective maintenanceChanges made to a system to repair flaws in its design, coding, or implementation
Adaptive maintenanceChanges made to a system to evolve its functionality to changing business needs or technologies
Perfective maintenanceChanges made to a system to add new features or to improve performance
Preventive maintenanceChanges made to a system to avoid possible future problems
363
Conducting System Maintenance:The Cost of Maintenance
Many organizations allocate eighty percent of information systems budget to maintenanceFactors that influence system maintainability
Latent defectsNumber of customers for a given systemQuality of system documentationMaintenance personnelToolsWell-structured programs
364
Conducting System Maintenance:Measures of Effectiveness
Number of failuresTime between each failureType of failureMean time between failures (MTBF)
A measurement of error occurrences that can be tracked over time to indicate the quality of a system
365
Controlling Maintenance Requests
Determine type of requestErrorAdaptationEnhancement
Figure 10-9 shows a flowchart for a request procedure
366
367
Configuration Management
The process of assuring that only authorized changes are made to the systemBaseline modules
Software modules that have been tested, documented, and approved to be included in the most recently created version of a system
System librarianA person responsible for controlling the checking out and checking in of baseline modules when a system is being developed or maintained
Build routinesGuidelines that list the instructions to construct an executable system from the baseline source code
368
Summary
Process of coding, testing and converting an organizational information systemFour installation strategies
DirectParallelSingle locationPhased installation
369
Summary
DocumentationSystemUser
User trainingProviding support for end usersSystems implementation failures
370
Summary
MaintenanceCorrectiveAdaptivePerfectivePreventive
Cost of maintenanceMeasuring effectiveness of maintenance
371
Summary
Controlling maintenance requestsConfiguration managementInternet development