310443 Management Information Systems

1. 310443 Management Information Systems 10. Developing Workgroup Information Systems by Asst. Prof. Wichai Bunchua E-mail : wichai@bucc4.buu.ac.th http://homework.sci.buu.ac.th/~wichai/310443.html Email: wichai@bucc4.buu.ac.th

2. Developing Workgroup Information Systems • The workgroup systems Development Process • Problem definition stage • Requirements stage • Evaluation stage • Design stage • Implementation stage • Dataflow diagrams Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

4. Problem Definition Stage • Ploblem definition • Feasibility Assessment • Project plan building Email: wichai@bucc4.buu.ac.th

5. Problem Definition • Perception of what is and what should be • Many perceptions • Concensus • Understanding • Acceptance • Support • Realistic axpectations Email: wichai@bucc4.buu.ac.th

6. Assess Feasibility Four dimensions of feasibility • Costs • Schedule • Technology • Politcal feasibility must address social dynamics of the group Email: wichai@bucc4.buu.ac.th

7. Build Project Plan • More complecated than with personal systems because of greater complexity and scale • Build project development team - identify workgroup members who will participate in the systems development • Allow time for review, discussion, and rework Email: wichai@bucc4.buu.ac.th

8. Requirements Stage • General strategy • Output requirements • Input requirements • processing scale estimates • Constraints determination • Requirements documentation Email: wichai@bucc4.buu.ac.th

9. Determine Output to Be produced • For communication applications: Nature of communications, communications format and content • For analysis applicationss: Types of analysis; ways in which members will share data and results; means by which work load will be divided Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

11. Determine Necessary Input • Examine output requirements and work backward to determine input necessary to produce that putput or • Examine existing workgroup forms, collect data from them, consider additional requirements suggested by forms • Use DFDs to learn of existence of both input and output requirements Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

13. Determine Constraints • Hardware • Programs • Data • Procedures - especially control • People Email: wichai@bucc4.buu.ac.th

14. Document Requirements • Need for concensus on requirements • Requirements document • Prototypes • Request for proposal Email: wichai@bucc4.buu.ac.th

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 before meeting • Require that participants read requirements document before meeting Email: wichai@bucc4.buu.ac.th

16. Guidelines for an Effective Requirements Review Meeting (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 Email: wichai@bucc4.buu.ac.th

17. Evaluation Stage • Transition in the users’ role • Requirements evaluation • Alternative vendor identification • Vendor communication • Alternative selection • Proposal evaluation • The contract Email: wichai@bucc4.buu.ac.th

18. Sources of Vendor Contracts • Your company’s MIS department • Coonsultants • Professional colleagues • Departments with similar needs in other companies • Professional organizations • Professional meetings Email: wichai@bucc4.buu.ac.th

19. Sources of Vendor Contracts (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 Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

21. Characteristics of a Good RFP RFP = Request for proposal • Clearly written • Consistent • Complete Email: wichai@bucc4.buu.ac.th

22. Characteristics of a Good RFP (cont.) • Description of: • Background, context, and processing environment • Specific requirements • Constraints on system • Constraints on procurement process • Need ont solutions (unless a particular solution required) • General description of evaluation criteria • Response dates • Single point of contact for questions Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

25. Contract • Do not sign “standard” contract • Get legal help for all but the smallest and simplest contracts Email: wichai@bucc4.buu.ac.th

26. Design Stage • Manage as for any technical project • Assess people • Follow intuition • Get help when necessary • Hardware • Develop specification Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th

29. Implementation Stage • Hardware • Install and test • Programs • Install and test • Data • Enter and verify Email: wichai@bucc4.buu.ac.th

30. Implementation Stage (cont.) • procedures • Document and test • People • Hire and train • Dress rehearsal • Repeat, if necessary • Installation Email: wichai@bucc4.buu.ac.th

31. Installation Four major styles of system installation • Parallel installatin • Phased installatin • Pilot installatin • Plunge installatin Email: wichai@bucc4.buu.ac.th

32. DataFlow Diagrams Purpose • The purpose of a DFD is to identify and record the essence of office processing by representing the flow of data among processes • A DFD is a snapshot of the data movement in ann organization or in a workgroup within an organization Email: wichai@bucc4.buu.ac.th

33. Elements of DFDs Elements of DFDs • External entities • rocesses • Dataflows • Data stores Email: wichai@bucc4.buu.ac.th

34. Multiple-Level DFDs • Context diagrams • Level 1 DFDs • Level 2 DFDs Email: wichai@bucc4.buu.ac.th

35. Building DFDs • Building a DFD is an iterative process. Start with papers of use a CASE tool • Second, start anywhere. • Top down • Bottom up • Use leveling. Donot expect to get everything into a single diagram Email: wichai@bucc4.buu.ac.th

36. Documenting Dataflows with the Data Dictionary • Data dictionary is a file or a dtabase that documents data requirements and explain, in detail, the meaning of each dataflow • Data dictionary entries for each dataflow • Name (of dataflow) • Description • Type • Format Email: wichai@bucc4.buu.ac.th

37. Dataflow Characteristics Two charateristics • Elementaty dataflow - cannot be further decomposed • Composite dataflow - contains many other data items Email: wichai@bucc4.buu.ac.th

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 Email: wichai@bucc4.buu.ac.th