AIS Developm

ent

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

DesignInformation

Outputs

Designdata base

Design DataProcessingOperations

DesignData 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

SystemsPlanning

SystemsAnalysis

SystemsDesign

SystemsOperations

Determinationof DesignFeasibilitySolicitation

of Hardware

and Software Proposals

Evaluation ofSystem

Proposals

Selection ofSystem

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 Operation

s• 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

ResourcesMeasurement of Resource Usage* Personnel Time Reporting Systems* Computer-oriented Monitoring Systems* Effectiveness Monitoring Systems

Chargeback Systems* Chargeback Rates* Usage Measurements by

DepartmentTaskProjectComputer System

Performance Evaluation Systems* Personnel performance by

Clerks & OperatorsSystems professionalsSystems managers

* Equipment performance* Information system performance

EfficiencyEffectiveness

Cost accounting& control reports

Performancereports

• 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 DestroyFrom priorprocessing

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

documentOutput

documentManualProcess

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:

CustomerCredit

Satisfactory?

RejectOrder

AcceptOrder

RejectionLetter

Acknowledgement

Sales Order

To Customer

To Customer

To sales OrderProcessing

From priorprocessing

Basic Rules of Flowcharting - VI