Chapter 14 Construct Deliver and Maintain Systems Projects

  • Slides: 51
Download presentation
Chapter 14 Construct, Deliver, and Maintain Systems Projects

Chapter 14 Construct, Deliver, and Maintain Systems Projects

Objectives for Chapter 14 • The sequence of events that constitute the in-house development

Objectives for Chapter 14 • The sequence of events that constitute the in-house development phase of the SDLC • The tools used to improve the success of system construction and delivery activities (CASE tools; PERT and Gantt charts) • The distinction between the structured and object-oriented design approaches • Multi-level DFDs in the design of business processes • The different types of system documentation and the purposes they serve • The role of accountants in the construct and delivery of systems • The advantages and disadvantages of the commercial software option, the decision-making process used to select commercial software

Systems Development Life Cycle Business Needs and Strategy Legacy Situation Business Requirements 1. Systems

Systems Development Life Cycle Business Needs and Strategy Legacy Situation Business Requirements 1. Systems Strategy - Assessment - Develop Strategic Plan System Interfaces, Architecture and User Requirements Feedback: User requests for New Systems 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 3. In-house Development Feedback: User requests for System Improvements and Support 4. Commercial Packages - Construct - Deliver - Configure - Test - Roll-out New and Revised Systems Enter into Production 5. Maintenance & Support - User help desk - Configuration Management - Risk Management & Security

Overview of Phases 3, 4 and 5 • Phase 3 - in-house development –

Overview of Phases 3, 4 and 5 • Phase 3 - in-house development – appropriate when organizations have unique information needs – steps include: • • • analyzing user needs designing processes and databases creating user views programming the applications testing and implementing the completed system

Overview of Phases 3, 4 and 5 • Phase 4 - commercial packages –

Overview of Phases 3, 4 and 5 • Phase 4 - commercial packages – when acceptable, most organizations will seek a pre-coded commercial software package – advantages include: • • lower initial cost shorter implementation time better controls rigorous testing by the vendor – risk • must ensure that the user gets a package that adequately meets his or her needs and is compatible with existing systems

Overview of Phases 3, 4 and 5 • Phase 5 - maintenance and support

Overview of Phases 3, 4 and 5 • Phase 5 - maintenance and support – acquiring and implementing the latest software versions of commercial packages – making in-house modifications to existing systems to accommodate changing user needs – may be relatively trivial, such as modifying an application to produce a new report, or more extensive, such as programming new functionality into a system

Phase 3 In-House Development

Phase 3 In-House Development

Up to 25% of all systems projects fail! Why? • Poorly specified systems requirements

Up to 25% of all systems projects fail! Why? • Poorly specified systems requirements – communication problems – time pressures systems • Ineffective development techniques developer – paper, pencils, templates, erasers instead of software tools, such as CASE • Lack of user involvement in systems development end user

Prototyping • Prototyping is a technique for providing users a preliminary working version of

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

Prototyping Techniques Identify Conceptual User Specifications Develop Prototype Present Prototype to Users Obtain User Feedback Change Prototype Per User Feedback Discard Prototype and Develop System Under Traditional SDLC Procedures Develop Prototype into Finished System

Computer-Aided Software Engineering (CASE) • CASE technology involves the use of computer systems to

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.

Uses of CASE Tools • Define user requirements • Create physical databases from conceptual

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

CASE Spectrum of Support Tools for the SDLC

CASE Spectrum of Support Tools for the SDLC

Project Evaluation and Review Technique (PERT) Deliver Phase Construct Phase 2 sta D =

Project Evaluation and Review Technique (PERT) Deliver Phase Construct Phase 2 sta D = ll 2 an W d T ee es ks t. E qu De C = sig 4 n. P W ro eek ce s ss 4 ip 3 m en E = 5 Weeks Create Data Structures F = 5 Weeks Code Programs G Te = 3 st W Pr ee og ks ram s 1 n io t a nt 5 t ks el ee onn 3 W rs = Pe K rain T t en ks pm ee qui W E 3 = ase A rch Pu B = 4 Weeks Design Data Model 7 In e ks cum e e W Do 3 are = H rep I = 3 Weeks P Convert Data Files 6 m J ste Te = 4 y S st We s Sy ek ek ew e ste s N m 4 W r to = L Ove t Cu 9 8 PERT charts show the relationship among key activities that constitute the construct and delivery process.

Gantt Chart represents time horizontally and activities vertically Purchase Equipment Design Data Model Design

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 Current Point in Time Convert Data Files Test System Prepare Documentation Train Personnel Cut Over to New System Budgeted Actual 1 2 3 4 5 6 7 8 9 10 11 12 Project Week 13 14 15 16 17 18 19 20 21

The Structured Design Approach… • is a disciplined way of designing systems from the

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 DFD and structure diagrams

Object-Oriented Design Approach • It builds information systems from reusable standard components or objects.

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.

Elements of the Object. Oriented Approach • Objects: equivalent to nouns – vendors, customers,

Elements of the Object. Oriented Approach • 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

Characteristics of an Inventory Object Attributes Part Number Description Quantity on Hand Reorder Point

Characteristics of an Inventory Object Attributes Part Number Description Quantity on Hand Reorder Point Order Quantity Inventory Object Operations Reduce Review Quantity Reorder Replace

Classes and Instances • An object class is a logical grouping of individual objects

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. Inventory Object Class Instance Wheel Bearing Alternator Water Pump

Inheritance • Inheritance means that each object instance inherits the attributes and operations of

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.

Systems Design • This stage follows a logical sequence of events: – data model

Systems Design • This stage follows a logical sequence of events: – data model the business process and design conceptual views – design the normalized database tables – design the physical user views (output and input views) – develop the process modules – specify the system controls – perform a system walkthrough

Data Modeling • Data Modeling is the task of formalizing the data requirements of

Data Modeling • Data Modeling is the task of formalizing the data requirements of the business process as a conceptual model. • The primary tool is the 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.

Physical User Views: Output Views • Output is the information produced by the system

Physical User Views: Output Views • Output is the information produced by the system to support user tasks and decisions. • Output attributes: – relevant – summarization – except orientation – timely – accurate – complete – concise

Output Reporting Techniques • Different users prefer different styles of output (tables, matrices, charts,

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.

Physical User Views: Input Views • Data input views are used to capture the

Physical User Views: 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.

Designing Hard Copy Input • Items to Consider: – How will the document be

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.

Designing Electronic Input may be from either hardcopy or electronic

Designing Electronic Input may be from either hardcopy or electronic

Data Entry Devices • • Point-of-sale terminals Touch screens Mouse Magnetic ink character recognition

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

Designing the Process Component • This phase begins with the DFDs produced in the

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.

Data Flow Diagrams (DFDs) • DFDs are used to represent multiple levels of detail.

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.

Lower-Level DFD for an AP Process

Lower-Level DFD for an AP Process

The Modular Approach • Each module performs a single task. • Correctly designed modules

The Modular Approach • 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)

Design System Controls • The last step in the detailed design phase. Need to

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.

System Design Walkthrough • This step is performed by the development team to ensure

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.

Program Application Software • If the organization intends to develop software in-house, then a

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

The Modular Approach to Programming • Promotes programming efficiency since modules can be both

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

Deliver the System: Testing • Programs must be thoroughly tested before they are implemented.

Deliver the System: 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.

Deliver the System: Documenting • Documentation describes how the system works and should be

Deliver the System: Documenting • Documentation describes how the system works and should be made for: – designers and programmers - comment lines in programs, system flowcharts, and program flowcharts – operator documentation - run manuals – user documentation - instructions on how to use the system, tutorials, and help features – accountants and auditors - all of the above as well as document flowcharts

Deliver the System: Converting the Databases • This is the transfer of data from

Deliver the System: 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

Deliver the System: Converting the Databases Three approaches: • Cold turkey cutover - the

Deliver the System: Converting the Databases Three approaches: • 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.

Deliver the System: Post-Implementation Review • The objective is to measure the success of

Deliver the System: 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.

Deliver the System: The Role of Accountants • Most system failures are due to

Deliver the System: 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 in accordance with SAS 78

Phase 4 Commercial Packages

Phase 4 Commercial Packages

The Purchase of Commercial Systems Packages • Four factors have stimulated the growth of

The Purchase of Commercial Systems Packages • Four factors have stimulated the growth of commercial software: – relatively low cost – prevalence of industry-specific vendors – growing demand by small businesses – trend toward downsizing and distributed data processing

Trends in Commercial Packages • Turnkey systems are completely finished and tested systems that

Trends in Commercial Packages • Turnkey systems are completely finished and tested systems that are ready for implementation. • Backbone systems provide a basic system structure on which to build. • Vendor-supported systems are customdeveloped and maintained by a vendor for a customer. • ERP systems are difficult to classify since they have characteristic of all of the above.

Pros and Cons of Commercial Packages • Advantages: – decreased implementation time – decreased

Pros and Cons of Commercial Packages • Advantages: – decreased implementation time – decreased cost – reduced probability of program errors • Disadvantages: – reduced independence - the customer is dependent on the vendor for maintenance – less flexibility in system – greater difficulty in modifying the system as needs change over time

Four Steps in Choosing a Commercial Package 1. Analyze needs and develop detailed specifications

Four Steps in Choosing a Commercial Package 1. Analyze needs and develop detailed specifications of the system requirements. 2. Send out the request for proposals to all prospective vendors to serve as a comparative basis for initial screening. 3. Gather the facts about each vendor’s system using multiple sources and techniques. 4. Analyze the findings and make a final selection.

Phase 5 Maintenance and Support

Phase 5 Maintenance and Support

Maintenance and Support • Approximately 80% of the life and costs of the SDLC

Maintenance and Support • Approximately 80% of the life and costs of the SDLC • Can be outsourced or done with in-house resources • User support is a critical aspect of maintenance. Can be facilitated by: – knowledge management - method for gathering, organizing, refining, and disseminating user input – group memory - method for collecting user input for maintenance and support

The Iceberg Effect

The Iceberg Effect