AIS Developme nt

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

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

Typical Conceptual Design Specifications - II 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 - III 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 - IV 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 - V System Components –Control and security Features –Type –Purpose –Specific system components affected –method of correcting error or establishing security

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

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

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

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

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

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

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

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

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

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

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

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

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

Standards development –System components –Performance –Documentation Documentation File conversion Implementation Activities - III

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

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

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

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? Basic Rules of Flowcharting - I

Source Document Destroy From prior processing 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:

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: Input document Output document Manual Process Basic Rules of Flowcharting - III

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 Basic Rules of Flowcharting - IV

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 Basic Rules of Flowcharting - V

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: Customer Credit Satisfactory? Reject Order Accept Order Rejection Letter Acknowledgement Sales Order To Customer To sales Order Processing From prior processing Basic Rules of Flowcharting - VI