1 / 38

310443 Management Information Systems

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. Developing Workgroup Information Systems. The workgroup systems Development Process

juliet
Download Presentation

310443 Management Information Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related