310443 management information systems

20 July 01 Email: [email protected]

1

310443 Management 310443 Management Information SystemsInformation Systems

10. Developing Workgroup I nformation Systems

by

Asst. Prof. Wichai Bunchua- 4E mail : wichai@bucc .buu.ac.th

://..../~/3 1 0 4 4 3 .html


2

Developing Workgroup Information Systems

The workgroup systems DevelopmentProcess

Problem definition stage Requirements stage Evaluation stage Design stage Implementation stage Dataflow diagrams


3

The Workgroup Systems Development

Process

The Systems Development Life Cycle (SDLC) process

Define the problem Specify the requirements Evaluate alternatives Design the system Implement the system


4

Problem Definition Stage

Ploblem definition Feasibility Assessment Project plan building


5

Problem Definition

Perception of what is and what shoul d be

Many perceptions Concensus

Understanding Acceptance Support

Realistic axpectations


6

Assess Feasibility

Four dimensions of feasibility Costs Schedule Technology Politcal feasibility must address soci

al dynamics of the group


7

Build Project Plan

More complecated than with persona l systems because of greater comple

xity and scale - Build project development team ide

ntify workgroup members who will pa rticipate in the systems development

Allow time for review, discussion, andrework


8

Requirements Stage

General strategy Output requirements Input requirements processing scale estimates Constraints determination Requirements documentation


9

Determine Output to Be produced

For communication applications: Nature of communications, communicati

ons format and content For analysis applicationss:

Types of analysis; ways in which membe rs will share data and results; means b

y which work load will be divided


10

Determine Output (cont.)

For tracking and monitoring applications:Format of reports, screen display, and

menus; nature of ad hoc query requests Beware of inconsistent terminology

and differences between form and content

Use prototypes for clarity


11

Determine Necessary Input

Examine output requirements and wo rk backward to determine input neces

sary to produce that putput or Examine existing workgroup forms, co

llect data from them, consider additio nal requirements suggested by forms

Use DFDs to learn of existence of both input and output requirements


12

Estimate Processing Scale

Amount of data Growth of data Frequency of data changes Frequency of report production Amount of concurrent of work load Growth in concurrent work load Response time requirements


13

Determine Constraints

Hardware Programs Data Procedures - especially control People


14

Document Requirements

Need for concensus on requirements

Requirements document Prototypes Request for proposal


15

Guidelines for an Effective Requirements

Review Meeting

Publish an argenda before meeting that sets out the following

Starting time Ending time Purpose Place

Distribute requirements document befor e meeting

Require that participants read requireme nts document before meeting


16

Guidelines for an Effective Requirements Review Mee

ting (cont.)

Have a meeting moderator to keep the discussion on track

Start and stop meeting on time, hold more meetings if not finished

Clarify that purpose of meeting is to define requirements not solutions

Do not use meeting to air grievances or conduct departmental business

Give respectful consideration to all suggestions

Keep minutes and distribute them afterwards


17

Evaluation Stage

Transition in the users’ role Requirements evaluation Alternative vendor identification Vendor communication Alternative selection Proposal evaluation The contract


18

Sources of Vendor Contracts

Your company’s MIS department Coonsultants Professional colleagues Departments with similar needs in o

ther companies Professional organizations Professional meetings


19

Sources of Vendor Contr acts (cont.)

Hardware dealers Local chapters of professional

associations like Data Processing Management Association (DPMA) and Association of Computing Machinery(ACM)

Local computer clubs Advertising in your trade’s publications


20

Vendor Communication

Coordinate with your corporation’s purchasing department

Make full disclosure of your problem , needs, and requirements

Meet with vendors singly, if possible Specify that all copiesof the RFP are

to be returned


21

Characteristics of a Good RFP

RFP = Request for proposal Clearly written Consistent Complete


22

Characteristics of a Goo d RFP (cont.)

Description of: Background, context, and processing enviro

nment Specific requirements Constraints on system Constraints on procurement process Need ont solutions (unless a particular solut

ion required) General description of evaluation criteria Response dates Single point of contact for questions


23

Intangible Factors in Alternative Selection

Ease of system expansion Vendor reputation or position in the

marketplace Simplicity or other beauty of design Anticipation of future technology Especially effective vendor personnel

or management Local support office


24

Proposal Evaluation

Check for vendor and product reputation Formal, quantitative, or subject

evaluation can work Other criteria:

Responsive to RFP? Understand problem and requirements? All costs included? Schedule realistic and acceptable?

Get help evaluating, if necessary


25

Contract

Do not sign “standard” contract Get legal help for all but the

smallest and simplest contracts


26

Design Stage

Manage as for any technical project Assess people Follow intuition Get help when necessary

Hardware Develop specification


27

Design Stage (cont.)

Program Develop specification Design structure and logic of custom

programs Data

Develop data standards Create data model and transform it

into database design


28

Design Stage (cont.)

Procedures Develop for both user and operations

procedures Develop for normal and failure recovery

procedures Check for completeness and feasibility Ensure that data-entry and conversion

procedures are appropriate People

Redraw draft of new or altered job descriptions Prepare for personnel training


29

Implementation Stage

Hardware Install and test

Programs Install and test

Data Enter and verify


30

Implementation Stage (cont.)

procedures Document and test

People Hire and train

Dress rehearsal Repeat, if necessary Installation


31

Installation

Four major styles of system installation

Parallel installatin Phased installatin Pilot installatin Plunge installatin


32

DataFlow Diagrams

Purpose The purpose of a DFD is to identify a

nd record the essence of office proc essing by representing the flow of d

ata among processes A DFD is a snapshot of the data mov

ement in ann organization or in a w orkgroup within an organization


33

Elements of DFDs

Elements of DFDs External entities rocesses Dataflows Data stores


34

- Multiple Level DFDs

Context diagrams Level 1 DFDs 2 22222


35

Building DFDs

22222222 2 2 22 22 22 222222222 222222 s. Start with papers of use a CASE to

ol Second, start anywhere.

Top down Bottom up

222222222 2 2222 222222 22 222 22. erything into a single diagram


36

Documenting Dataflows with the Data Dictionary

Data dictionary is a file or a dtabase that documents data requirements and expla

in, in detail, the meaning of each dataflow

Data dictionary entries for each dataflow Name (of dataflow) Description Type Format


37

Dataflow Characteristics

Two charateristics - Elementaty dataflow cannot be fur

ther decomposed - Composite dataflow contains man

y other data items


38

Documenting Process Logic with Procedure

Specifications

Procedure specifications explain how the process transforms the inputs it receives into the output it produces

Structured English shows the logic used to express the policy statements. It is documented in a semiformal manner

310443 management information systems

Documents