information systems analysis and design myriam lewkowicz

Information SystemsAnalysis and Design

Myriam Lewkowicz

myriam.lewkowicz@utt.fr 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

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

Information Systems Defined

Combinations of hardware, software, and telecommunications networks that people build and use to collect, create, and distribute useful data in organizations

Key Elements of Information Systems

Data: raw material, unformatted informationInformation: processed data (meaningful)Knowledge: understanding relationships between pieces of informationWisdom: knowledge accumulated and applied

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

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

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

Integrating Skills and Knowledge

Technologyhardware, software, networking

Businessbusiness, management, social, communications

SystemsIntegration, development methods, critical thinking, problem solving

Hot Skills in IS Workers

Office / E-mailLanguagesApplicationsRDBS AdministrationDevelopment ToolsInternetworkingOperating SystemsLAN AdministrationNetworking

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

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

The Spread of Technology in Organizations

Benefits of centralized IS functionCoordinated planningConsistent managementSystems compatibility and connectivity

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

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

Why Use Information Systems?

Automating: doing things fasterOrganizational learning: doing things betterSupporting Strategy: doing things smarter

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

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

Supporting Strategy: Doing Things Smarter

Strategic PlanningCreate a vision: setting the directionCreate a standard: performance targetsCreate a strategy: reaching the goal

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

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

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

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

Data inputManual data entrySemiautomated data entryFully automated data entry

Examples:PayrollSales and orderingInventoryPurchasing, receiving, shippingAccounts payable and receivable

Management Information Systems (MISs)

Two Types:Management of IS in organizationsSpecific information systems for mid-level managers

Used at managerial level of the organization

Management Information SystemsTypes of reports:

Scheduled reportKey-indicator reportException reportDrill-down reportAd hoc report

Management Information Systems (MISs)

Examples:Sales forecastingFinancial management and forecastingManufacturing planning and schedulingInventory management and planningAdvertising and product pricing

Executive Information Systems (EISs)Used at executive level of the organizationHighly aggregated formData types

Soft data – news and nonanalytical dataHard data – facts and numbers

Executive Information Systems (EISs)Examples:

Executive-level decision makingLong-range and strategic planningMonitoring internal and external eventsCrisis managementStaffing and labor relations

1.351.35

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.

Expert Systems (ESs)Mimics human expertise by manipulating knowledgeRules (If-then)Inferencing

Office Automation Systems (OASs)Examples:

Communicating and schedulingDocument preparationAnalyzing dataConsolidating information

Collaboration TechnologiesVirtual teamsVideoconferencingGroupwareElectronic Meeting Systems (EMSs)

Functional Area Information SystemsGeared toward specific areas in the company:

Human ResourcesBenefitsMarketing

Global Information SystemsInternational ISTransnational ISMultinational ISGlobal IS

Chapter 4Enterprise-Wide

Information Systems

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

Enterprise Systems

Enterprise systemsAlso known as enterprise-wide information systemsInformation systems that allow companies to integrate information across operations on a company-wide basis

Before an entreprise system

With an entreprise sytem

Types of Enterprise Systems

Packaged applicationsCustom applicationsStand-alone applications

Enterprise Resource PlanningIntegrated applicationsERP systems

BaanOraclePeopleSoftSAP

ERP ImplementationModulesCustomizationsBest practicesBusiness process reengineering (BPR)

Customer Relationship Management (CRM)

Sales Force Automation (SFA)New opportunities for competitive advantageExamples:

MGMAmerican AirlinesMarriott International

CRM system

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

Supply chain management

The Formula for Enterprise System Success

Secure executive sponsorshipGet help from outside expertsThoroughly train usersTake a multidisciplinary approach to implementation

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

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

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

Evolution of IS developmentFrom “art” to a “discipline”Standardized development methodsSoftware engineering

Options for Obtaining Information Systems

Build your ownBuy a prepackaged systemOutsource development to a 3rd partyEnd user development

Information Systems Development in Action

Breaking large complex problems into manageable piecesDecomposing large, complex problems

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

The Role of Users in the Systems Development Process

Knowledgeable of needsEffective partnership

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

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

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

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

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

Characteristics of a System

ComponentsInterrelated ComponentsBoundaryPurposeEnvironmentInterfacesConstraintsInputOutput

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

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

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

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

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

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

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

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

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

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

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

Systems Development Life Cycle

System Development MethodologyStandard process followed in an organizationConsists of:

AnalysisDesignImplementationMaintenance

Series of steps used to manage the phases of development for an information systemConsists of four phases:

Planning and SelectionAnalysisDesignImplementation and Operation

Phases are not necessarily sequentialEach phase has a specific outcome and deliverableIndividual companies use customized life cycle

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

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

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

Summary

Information systems analysis and design

Process of developing and maintaining an information system

Modern approach to systems analysisProcess-OrientedData-Oriented

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)

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

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

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

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

Project ManagerSystems Analyst responsible for

Project initiationPlanningExecutionClosing down

Requires diverse set of skillsManagementLeadershipTechnicalConflict managementCustomer relations

Managing the Information Systems Project

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

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

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

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

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

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

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

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

Summary

Skills of an effective project managerActivities of project manager

InitiationPlanningExecutionClosedown

Gantt Charts and Network DiagramsCommercial PM Software

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

Learning Objectives

Discuss the content of and need for a Statement of Work and Baseline Project PlanDescribe a structured walkthrough

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

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

IntroductionBrief overviewRecommended course of actionProject scope defined

Units affectedInteraction with other systemsRange of system capabilities

System DescriptionOutline of possible alternative solutionsNarrative format

Feasibility AssessmentProject costs and benefitsTechnical difficultiesHigh-level project schedule

Management IssuesOutlines concerns that management may have about the projectTeam compositionCommunication planProject standards and procedures

Reviewing the Baseline Project Plan

ObjectivesAssure conformity to organizational standardsAll parties agree to continue with project

Reviewing the Baseline Project Plan

WalkthroughPeer group reviewParticipants

CoordinatorPresenterUserSecretaryStandards BearerMaintenance Oracle

ActivitiesWalkthrough review formIndividuals polledWalkthrough action list

AdvantagesAssures that review occurs during project

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

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

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

Learning Objectives

Learn about Joint Application Design (JAD) and PrototypingDiscuss appropriate methods to elicit system requestsExamine requirements determination for Internet applications

Activities in Requirement Gathering

1.0Identify the right Stakeholders &Artefacts

0.0Outline information to be sought

2.0Use most appropriate investigation techniques

4.0Document the requirements

Objective: determine the functions & information that must be provided by the information system

3.0Determine duration

Performing Requirements Determination

Gather information on what the system should do from many sources

UsersReportsFormsProcedures

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

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

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

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

Questionnaires Vs. InterviewsInterviews cost more but yield more informationQuestionnaires are more cost-effective

Directly Observing UsersServes as a good method to supplement interviewsOften difficult to obtain unbiased data

People often work differently when being observed

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

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

Joint Application Design (JAD)

ParticipantsSession LeaderUsersManagersSponsorSystems AnalystsScribeIS Staff

End ResultDocumentation detailing existing systemFeatures of proposed system

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

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

Summary

InterviewsOpen-ended and close-ended questionsPreparation is key

QuestionnairesMust be carefully designedCan contain close-ended as well as open-ended questions

Summary

Other means of gathering requirementsObserving workersAnalyzing business documents

Joint Application Design (JAD)Prototyping

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.

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

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

Learning Objectives

Discuss the use of data flow diagrams as analysis tools Discuss process modeling for Internet Applications

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

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

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

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

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

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

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

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

Developing DFDs: An Example

Hoosier Burger’s automated food ordering systemContext Diagram contains no data stores

Developing DFDs: An Example

Next step is to expand the context diagram to show the breakdown of processes

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

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

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

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

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

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

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

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

Balancing DFDs

We can split a data flow into separate data flows on a lower-level diagram

Balancing DFDs:Four Additional Advanced Rules

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

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

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

Using DFDs in Business Process Reengineering

Example: IBM CreditCredit approval process required six days before Business Process Reengineering (see Fig 5-12)

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

Summary

Data flow diagrams (DFD)SymbolsRules for creatingDecompositionBalancing

DFDs for AnalysisDFDs for Business Process Reengineering (BPR)

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

Learning Objectives

Define key data-modeling termsConceptual data modelEntity-Relationship (E-R) diagram Entity typeEntity instanceAttributeCandidate keyMultivalued attributesRelationshipDegreeCardinalityAssociative entity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ER diagram for Pine Valley furniture

Summary

Process of conceptual data modelingDeliverablesGathering information

Entity-Relationship ModelingEntitiesAttributesCandidate keys and identifiersMultivalued attributes

Degree of relationship

Summary

CardinalityAssociative entitiesConceptual data modeling and Internet development

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

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

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

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

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

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

Components ViewComponents View

An architecture-based vision

Deployment ViewDeployment ViewProcess ViewProcess View

Logical ViewLogical View

Use Case ViewUse Case View

Functional needsMajor classes

codingcoding

System performancesSystem performances Servers and network organization

Servers and network organization

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

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

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

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

A use case and his actor

A use case diagram

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.

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

Update Benefits description

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

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.

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.

Collaboration diagram

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.

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

Class notations

Class stereotypes

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.

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

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

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

Representing Aggregation

AggregationA part-of relationship between a component object and an aggregate objectExample: Personal computer

Composed of CPU, Monitor, Keyboard, etc

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.

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.

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.

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.

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

Objects notations

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

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.

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.

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

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.

Summary

Object-Oriented modeling approachBenefitsUnified Modeling Language

Use casesClass diagramsState diagramsSequence diagrams

Use-case modeling

Summary

Object Modeling: Class DiagramsAssociationsGeneralizationsAggregation

Dynamic Modeling: State DiagramsDynamic Modeling: Sequence DiagramsMoving to Design

Chapter 12Designing the Human Interface

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

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

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

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

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?

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

Design specifications are major deliverable and contain three sections

1. Narrative2. Screen Design3. Testing and usability assessment

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

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

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

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

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

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

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

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

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

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

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

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

Providing Help

Context-Sensitive HelpEnables user to get field-specific help

Users should always be returned to where they were when requesting help

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

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

Designing Dialogues:Building Prototypes and Assessing

Usability

Often optional activitiesTask is simplified by using graphical design environment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beta TestingUser testing of a completed information system using real data in the real user environment

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

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

Planning Installation

ConsiderationsData conversion

Error correctionLoading from current system

Planned system shutdownBusiness cycle of organization

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

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

Training Information System Users

Potential training topicsUse of the systemGeneral computer conceptsInformation system conceptsOrganizational conceptsSystem managementSystem installation

Training methodsResident expertComputer-aided instructionFormal coursesSoftware help componentsTutorialsInteractive training manualsExternal sources, such as vendors

Electronic performance support system (EPSS)

Component of a software package or application in which training and educational information is embedded

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

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

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

Why Implementation Sometimes Fails

Two conditions necessary for a successful implementation

Management support of the system under developmentInvolvement of users in the development process

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

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

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

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

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

Controlling Maintenance Requests

Determine type of requestErrorAdaptationEnhancement

Figure 10-9 shows a flowchart for a request procedure

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

Summary

Process of coding, testing and converting an organizational information systemFour installation strategies

DirectParallelSingle locationPhased installation

Summary

DocumentationSystemUser

User trainingProviding support for end usersSystems implementation failures

Summary

MaintenanceCorrectiveAdaptivePerfectivePreventive

Cost of maintenanceMeasuring effectiveness of maintenance

Summary

Controlling maintenance requestsConfiguration managementInternet development

information systems analysis and design myriam lewkowicz

Documents

ignacio lewkowicz-escuela y ciudadanía

curriculum vitae david j. lewkowicz, ph.d. february,...

myriam phd

lewkowicz - pensar sin estado

9. arq plus de sentido. sztulwark y lewkowicz

myriam edwards md

myriam ortiz

myriam fuks

myriam portafolio

andalucia myriam

myriam rodrigue's portfolio

myriam orozco

diapositivas myriam

lewkowicz ignacio - pensar sin estado

myriam melo avila

lewkowicz 2000 authenticity

myriam colin

de myriam

cv myriam ruesch

myriam nemirovsky