Systems Development Life Cycle

Business Needs and Strategy Legacy Situation

Business Requirements

1. Systems Strategy
- Assessment - Develop Strategic Plan

Feedback: User requests for New Systems

System Interfaces, Architecture and User Requirements

High Priority Proposals undergo Additional Study and Development

2. Project Initiation
- Feasibility Study - Analysis - Conceptual Design - Cost/Benefit Analysis

Selected System Proposals go forward for Detailed Design

Feedback: User requests for System Improvements and Support

3. In-house Development
- Construct - Deliver

4. Commercial Packages
- Configure - Test - Roll-out

New and Revised Systems Enter into Production

5. Maintenance & Support

- User help desk - Configuration Management - Risk Management & Security

Chapter Four In-House Systems Development

Many organizations require systems that are highly tuned to their unique operations. These firms design their own information systems through in-house systems development activities.

steps include:
analyzing user needs designing processes and databases creating user views programming the applications testing and implementing the completed system
2

4.1. System Project failures

Systems development projects are not always success stories. Estimates hold that up to 25 percent of all systems projects fail three problems that account for most systems failures are: end 1) Poorly specified systems requirements user communication problems time pressures 2) Ineffective development techniques paper, pencils, templates, erasers instead of software tools, such as CASE 3) Lack of user involvement in systems development 3

Tools for improving system development

a) Prototyping b) Computer Aided Software Engineering (CASE) approach c) Project Evaluation and Review Technique (PERT) chart d) Gantt Chart

a) Prototyping
Prototyping is a technique for providing users a preliminary working version of the system. It is built quickly and relatively inexpensively with the intention it will be modified. As the users work with the prototype and make suggestions for changes, a better understanding of the true requirements of the system is achieved.

Prototyping Techniques

Identify Conceptual User Specifications

Develop Prototype

Present Prototype to Users

Obtain User Feedback

Change Prototype Per User Feedback

Develop Prototype into Finished System

Discard Prototype and Develop System Under Traditional SDLC Procedures

b) Computer-Aided Software Engineering (CASE) CASE technology involves the use of computer systems to build computer systems. CASE tools are commercial software products consisting of highly integrated applications that support a wide range of SDLC activities.
7

Uses of CASE Tools Define user requirements Create physical databases from conceptual user views Produce system design specifications Automatically generate program code Facilitate the maintenance of programs created by both CASE and non-CASE techniques
8

CASE Spectrum of Support Tools for the SDLC

c) Project Evaluation and Review Technique (PERT)

PERT charts show the relationship among key activities that constitute the construct and delivery process.
Construct Phase Deliver Phase

B = 4 Weeks Design Data Model 1 3

E = 5 Weeks Create Data Structures 6

I = 3 Weeks Convert Data Files 9

4
5 8

The principal features of this diagram include Activities, Events, Paths and Critical path.
10

d) Gantt Chart
represents time horizontally and activities vertically
Purchase Equipment Design Data Model Design Process Install and Test Equipment Code Programs Test Programs

Create Data Structures

Convert Data Files Test System Prepare Documentation Train Personnel Cut Over to New System Current Point in Time 1 2 3 4 5 6 7 8 9 10

Budgeted Actual 11 12 13 14 15 16 17 18 19 20 11 21

Project Week

4.2. Construct the System

The main goal of the construct phase is to design and build working software that is ready to be tested and delivered to its user community. This phase involves : modeling the system, programming the applications, and application testing. The design and programming of modern systems follows one of two basic approaches i. Structured Design approach ii. Object-Oriented Design Approach
12

4.2.1. System Design Approaches i) The Structured Design Approach

is a disciplined way of designing systems from the top down starts with the big picture of the proposed system and gradually decomposes it into greater detail so that it may be fully understood utilizes Data Flow Diagram (DFD) and structure diagrams
13

14

ii) Object-Oriented Design Approach

It builds information systems from reusable standard components or objects. Once created, standard modules can be used in other systems with similar needs. A library of modules can be created for future use.

15

Elements of the Object-Oriented Approach

In object oriented design approach, both data and programming logic are encapsulated in modules to represent objects. Elements of this approach include: Objects: equivalent to nouns vendors, customers, inventory, etc. Attributes: equivalent to adjectives part number, quantity on hand, etc. Operations: equivalent to verbs review quantity on hand, reorder item
16

Characteristics of an Inventory Object

Attributes Part Number Description

Quantity on Hand

Reorder Point

Order Quantity

Object

Inventory

Operations Reduce

Review Quantity

Reorder

Replace

17

Classes and Instances

An object class is a logical grouping of individual objects that share the same attributes and operations. An instance is a single occurrence of an object within a class.
Object Class

Inventory

Instance

Wheel Bearing

Alternator

Water Pump
18

Inheritance
Inheritance means that each object instance inherits the attributes and operations of the class to which it belongs. Object classes may also inherit from other object classes.

19

4.2.2. Systems Design process This stage follows a logical sequence of events:
1. 2. 3. 4. data modeling for business process design conceptual user views design the normalized database tables design the physical user views (output and input views) 5. develop the process modules 6. specify the system controls 7. perform a system walkthrough

20

1. Data Modeling
Data model is the blueprint for ultimately creating the physical database. Data Modeling is the task of formalizing the data requirements of the business process as a conceptual model. The primary tool is the Entity Relationship (ER) diagram which is used to depict the entities or data objects in the system. Each entity in an ER diagram is a candidate for a conceptual user view that must be supported by the database. This technique is used to depict the entities or data objects in the system.
21

22

2. Conceptual User Views

Once the entities have been represented in the data model, the data attributes that define each entity can then be described. These attributes represent the conceptual user views that must be supported by normalized database tables.

3. Normalized Data tables

Physical database tables are constructed from the data model with each entity in the model being transformed into a separate physical table.
23

4. Physical User Views

Are the media for conveying and presenting data. Include output report, document and input screens. a) Output views Output is the information produced by the system to support user tasks and decisions. At transaction process level, output tends to be extremely detailed. The GL/FRS and MRS produce output that is more summarized. Example of system outputs (see next table)

24

25

Output attributes include:

Relevance- output should support decision or task. summarization exception Orientation- identify activities that are about
to go out of control and ignore that are functioning within the normal limit.

timely accurate complete Concise- reports should be visually pleasing and logically organized.

26

Output Reporting Techniques

Different users prefer different styles of output (tables, matrices, charts, and graphs) and modes of output (hard copy vs. display screen). Systems designers must identify these styles and provide output in the desired style. The issue of whether output should be hard copy (paper) or electronic must be addressed.

27

b) Input Views
Data input views are used to capture the relevant facts about the resources, events, and agents involved in business process transactions. Input may be either hard copy input documents or electronic input.

28

Designing Hard Copy Input

Items to Consider:
How will the document be handled? What quality paper? How long will the form be stored and in what type of environment? How many copies are required? What size form is necessary? Non-standard form can cause printing and storage problems.

29

Designing Electronic Input

Input may be from either hardcopy or electronic

30

Data Entry Devices

Point-of-sale terminals Touch screens Mouse Magnetic ink character recognition devices Optical character recognition devices Voice and touch-tone recognition devices

31

5. Designing the Process Component

This phase begins with the DFDs produced in the general design phase. The first task is to decompose the existing DFDs to a degree of detail that will serve as the basis for creating structure diagrams. The structure diagrams will provide the blueprints for writing the actual program modules.
32

Data Flow Diagrams (DFDs)

DFDs are used to represent multiple levels of detail. Context-level DFDs are used to present an overview model of the business activities and the primary transactions processed by the system. It does not include a detailed definition of data files and specific procedures.

33

34

Lower-Level DFD for an AP Process

35

36

The Modular Approach

The creation of the structure diagram requires analysis of the DFD to divide its processes into input, process, and output functions. The modular approach involves arranging the system in a hierarchy of small, discrete modules, each of which performs a single task Each module performs a single task. Correctly designed modules possess two attributes: loosely coupled (low amounts of exchange of data between modules) strongly cohesive (small number of tasks performed in each module)
37

38

6. Design System Controls

The last step in the detailed design phase. Need to consider: computer processing controls data base controls manual controls over input to and output from the system operational environment controls This step allows the design team to review, modify, and

evaluate controls with a system-wide perspective that did not exist when each module was being designed independently.
39

7. System Design Walkthrough

This step is performed by the development team to ensure the design is free from conceptual errors that could become programmed into the final system. Some firms may use a quality assurance group to perform the task. This is an independent group of programmers, analysts, users, and internal auditors.
40

Program Application Software

If the organization intends to develop software in-house, then a programming language must be selected, such as:
procedural languages or 3GLs (COBOL) event-driven languages (Visual Basic) object-oriented languages (Java)

41

The Modular Approach to Programming

Promotes programming efficiency since modules can be both programmed and tested independently Promotes maintenance efficiency since small modules are easier to analyze and change Promotes greater control since they are less likely to contain material errors of fraudulent logic

42

4.3. Deliver the System:

In this phase: database structures are populated with data, equipment is purchased and installed, employees are trained, The system is documented, new system is rolled-out and The old system is terminated.

Major activities:
Testing the entire system Documenting the system Converting the data base Post implementation review

43

4.3.1. Testing
Programs must be thoroughly tested before they are implemented. Individual modules should be tested with test data containing both good and bad data. All logic procedures should be tested. After the individual modules have been tested, the entire system should tested as a whole.

44

The testing procedure involves

using the system to process hypothetical data, The outputs of the system are then reconciled with predetermined results, the test is documented to provide evidence of the systems performance. Finally, when those conducting the tests are satisfied with the results, a formal acceptance document should be completed

45

4.3.2. Documenting
Documentation describes how the system works and should be made for four groups:

1. designers and programmers

Need to debug errors and maintain the sysytem. they document the comment lines in programs, system flowcharts, and program flowcharts

2. Computer operator documentation

Computer operators use documentation describing how to run the system called a run manual.

46

The typical contents of a run manual include: The name of the system, such as Purchases System. The run schedule (daily, weekly, time of day, and so on). Required hardware devices File requirements for all the transaction files used in the system.

47

3. user documentation
Users need documentation describing how to use the system, tutorials, and help features User tasks include such things as entering input for transactions, making inquiries of account balances, updating accounts, and generating output reports. The nature of user documentation will depend non the users degree of sophistication with computers and technology. Thus, before designing user documentation, the systems professional must assess and classify the users skill level.
48

 The following is one classification scheme:

Novices Occasional users Frequent light users Frequent power users user documentation often takes the form of a user handbook, as well as online documentation.

49

The typical user handbook will contain the following items: An overview of the system and its major functions Instructions for getting started Descriptions of procedures with step-by-step visual references Examples of input screens and instructions for entering data A complete list of error message codes and descriptions A reference manual of commands to run the system A glossary of key terms Service and support information

50

4. accountants and auditors

With responsibility for the design of certain security procedures, accounting controls, and audit trails, accountants are stakeholders in all AIS applications For these tasks, accountants may draw upon all of the documentation described previously as well as document flowcharts

51

4.3.3. Converting the Databases

This is the transfer of data from its current form to the format or medium required by the new system. Data conversion is risky and must be carefully controlled by the following precautions: validation - old database must be inspected before conversion reconciliation - after the conversion, the new database must be reconciled against the original backup - copies of the original files must be kept as backup against discrepancies in the converted data

52

Three approaches of data conversion:

Cold turkey cutover - the firm switches to the new system on a particular day and simultaneously terminates the old system.
This is the riskiest approach.

Phased cutover - modules are implemented in a piecemeal fashion.

The risk of a devastating failure can be reduced.

Parallel operation cutover - the old system and new system are run simultaneously.
This is the safest, yet costliest, approach.

53

4.3.3. Post-Implementation Review

The objective is to measure the success of the system and of the process after the dust has settled. Want to assess:
system design adequacy accuracy of time, cost, and benefit estimates

This information can provide feedback to improve future systems development projects.

54

System Design Adequacy

The physical features of the system should be reviewed to see if they meet user needs. The reviewer should seek answers to the following types of questions: 1. Does the output from the system possess such characteristics of information as relevance, timeliness, completeness, accuracy, and so on? 2. Is the output in the format most useful and desired by the user (such as tables, graphs ,electronic, hard copy, and so on)? 3. Are the databases accurate, complete, and accessible? 4. Did the conversion process lose, corrupt, or duplicate 55 data?

5. Are input forms and screens properly designed and

meeting users needs? 6. Are the users using the system properly? 7.Does the processing appear to be correct? 8. Can all program modules be accessed and executed properly, or does the user ever get stuck in a loop? 9. Is user documentation accurate, complete, and easy to follow? 10. Does the system provide the user adequate help and tutorials?

56

Accuracy of Time, Cost, and Benefit Estimates

Uncertainty complicates the task of estimating time, costs, and benefits for a proposed system. a review of actual performance compared to budgeted amounts provides critical input for future budgeting decisions.

57

 The following questions provide some insight: 1. Were PERT and Gantt chart estimates accurate to within 10
percent? 2. What were the areas of significant departures from budget? 3. Were departures from the budget controllable (internal) in the short run or non-controllable (for example, supplier problems)? 4. Were estimates of the number of lines of program code accurate? 5. Was the degree of rework due to design and coding errors acceptable? 6. Were actual costs in line with budgeted costs? 7. Are users receiving the expected benefits from the system? 8. Do the benefits seem to have been fairly valued?
58

4.4. The Role of Accountants

Most system failures are due to poor designs and improper implementation. Accountants should provide their expertise to help avoid inadequate systems by:
providing technical expertise for financial reporting requirements specifying documentation standards for auditing purposes verifying control adequacy

59