1 / 30

AIS Development

AIS Development. Approaches to Systems Development. Top-Down versus Bottom-up In-House versus Outsourcing Re-engineering Prototyping. System Components Output . Features Name Purpose Distribution to users Contents General format Frequency or trigger Timeliness Output medium.

kmcallister
Télécharger la présentation

AIS Development

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. AIS Development

  2. Approaches to Systems Development • Top-Down versus Bottom-up • In-House versus Outsourcing • Re-engineering • Prototyping

  3. System Components Output Features Name Purpose Distribution to users Contents General format Frequency or trigger Timeliness Output medium Typical Conceptual Design Specifications - I

  4. System Components Data base Features File or table name File or table type File size Contents of record or table Record or table layout File organization method Storage medium Data characteristics Updating frequency Data structure Typical Conceptual Design Specifications - II

  5. System Components Data processing Features Sequence of steps or runs Processing modes, cycles, volumes Modes of data communication Processing capabilities at each physical location Typical Conceptual Design Specifications - III

  6. System Components Data input Features Name Purpose Source Method of collecting data Volume (peak and average) Contents (data elements) General format Data entry method Typical Conceptual Design Specifications - IV

  7. System Components Control and security Features Type Purpose Specific system components affected method of correcting error or establishing security Typical Conceptual Design Specifications - V

  8. Systems Acquisition Options • Purchasing versus leasing • Single vendors versus multiple vendors • In-house system versus outsourcing computing services • In-house software development versus commercial software packages • Types of commercial software • General accounting systems • Turnkey software systems

  9. Advantages of Commercial Software • Products available without lengthy developmental periods • Soundly designed and well-tested and thus efficient and reliable • Reasonable pricing

  10. Limitations of Commercial Software • Generalized in nature • Acquiring firm is dependent on the software vendor for support and maintenance and upgrades

  11. The Sequence in Designing System Components Design Controls & Security Measures Design Information Outputs Design data base Design Data Processing Operations Design Data Inputs

  12. A List of Design Principles • Foster system objectives • Incorporate reasonable tradeoffs • Focus on functional requirements • Serve multiple purposes • Relate to users’ concerns • Provide a tailored product • Integrate system modules and components • Avoid design excesses • Apply sound methodology

  13. Determination of Design Feasibility Systems Planning Solicitation of Hardware and Software Proposals Evaluation of System Proposals Systems Analysis Selection of System Hardware and Software Systems Design Systems Operations System Justification & Selection in the Systems Development Life Cycle Systems Justification & Selection

  14. A List of Resource Specifications - I • Systems Design Specifications • Output • Data-base • Processing • Input • Control & security

  15. A List of Resource Specifications - II • Hardware Specifications • Processor speeds and capabilities • Secondary storage capacities and access capabilities • Input-output speeds and capabilities • Compatibility features • Modularity features • Error detection and correction techniques • Data communication capabilities • Special features, such as multiprogramming and virtual storage • maximum allowable downtime as a percentage of total time

  16. A List of Resource Specifications - III • Software Specifications • Programming languages and compilers • Utility packages • Application packages • Operating system capabilities • Data management packages • System Support Specifications • Programming assistance • Training programs • Test facilities and time available • Backup facilities • Maintenance assistance

  17. Techniques for Proposal Evaluation • The benchmark problem technique • Simulation model technique • Weighted-Rating analysis technique

  18. Systems Implementation: Preliminary Actions • Establish implementation plans and controls • Gantt chart • Network diagrams • Recognize behavioral concerns • Review the organization of the project team • Complete arrangement for selected system resources

  19. Implementation Activities - I • Personnel selection and training • Physical site preparation • Detailed system design • Output design • Database design • Input design • Processing design • Controls design

  20. Implementation Activities - II • Application software development • Coding • Structured programming • Software testing • Desk checking • String testing • System testing • Acceptance testing

  21. Implementation Activities - III • Standards development • System components • Performance • Documentation • Documentation • File conversion

  22. Implementation Activities - IV • System conversion: cutover • Direct conversion approach • Parallel operation approach • Modular conversion approach • Phased conversion approach • User signoff

  23. Systems Operations • Fine tuning • Post-implementation evaluation • To assess the degree to which the objectives of the system project have been met • To spot any additional modifications that might be needed in the newly designed system • To evaluate the project team’s performance, both in terms of a quality product and adherence to the project schedule and work plan • To serve as the basis for improving future systems developments and accuracy of cost and benefit estimates

  24. Measurement of Resource Usage * Personnel Time Reporting Systems * Computer-oriented Monitoring Systems * Effectiveness Monitoring Systems Performance Evaluation Systems * Personnel performance by Clerks & Operators Systems professionals Systems managers * Equipment performance * Information system performance Efficiency Effectiveness Chargeback Systems * Chargeback Rates * Usage Measurements by Department Task Project Computer System Cost accounting & control reports Performance reports A Framework Pertaining to the Control of System-Related Resources

  25. Basic Rules of Flowcharting - I • 1) The flow begins at the upper left-hand corner of the sheet and generally moves from left to right and from top to bottom • 2) All steps are clearly presented in a sequence, or a series of sequences. No obvious gaps in the procedure should be present • 3) Symbols are used consistently throughout. Thus the symbol for manual processing (an inverted trapezoid) should appear each time a clerk performs a step in the procedure • Examples: What is what?

  26. Source Document From prior processing Destroy Basic Rules of Flowcharting - II • 4) The dispositions of all documents and reports are shown. In fact, the final “resting place” of every copy of every of every prepared document should be specified. Typical dispositions include placing documents in files, sending documents to outside parties such as customers, forwarding documents to connecting procedures (such as a general ledger procedure), and distributing reports to managers. If the disposition consists of destroying a document, this action may be represented in the manner shown below:

  27. Manual Process Input document Output document Basic Rules of Flowcharting - III • 5) The “sandwich” rule is consistently applied. This rule states that a processing symbol should be sandwiched between an input symbol and an output symbol, in the manner shown below:

  28. Basic Rules of Flowcharting - IV • 6)When a document crosses an organizational line within the flowchart, the document is pictured again in the new organizational unit. However, the repetition is not usually necessary in some instances if the organizational units are adjacent • 7) All symbols contain a brief but specific label written inside the symbols • 8) Multiple copies of documents are drawn as an overlapping group and are numbered in the upper right-hand corners; these numbers remain the copies during their flows through the procedure

  29. Basic Rules of Flowcharting - V • 9) Added comments are included within annotation symbols and are attached to appropriate symbols, such as the processing symbols to which the comments are related • 10) Ample connections (cross-references) are provided. The symbols used in forming the connections depend on the situation. Thus, if two sheets are needed to to contain the flowchart, the flows between pages are formed by off-page connector symbols. In those cases where the procedure being flowcharted links to an adjoining procedure, the connection can be formed by a terminal symbol

  30. Reject Order Rejection Letter To Customer From prior processing Accept Order Acknowledgement Customer Credit Satisfactory? To Customer Sales Order To sales Order Processing Basic Rules of Flowcharting - VI • 11) Exceptional Occurrences, such as back orders, are clearly noted. They may appear as (i) comments within annotation symbols, (ii) separate flowcharts, with references to the main flowchart, or (iii) decision branches, as shown below:

More Related