PHASE 4 SYSTEMS IMPLEMENTATION Application Development SYSTEMS ANALYSIS & DESIGN

PHASE 4SYSTEMS IMPLEMENTATION

Application Development

SYSTEMS ANALYSIS & DESIGN

PHASE 42

SYSTEMS ANALYSIS & DESIGN 3E

SDLC Phases

Phase 4: Systems ImplementationObjectives

Learn about application development, including designing, writing, testing, and documenting programs and code modules

Perform installation and evaluation tasks, including user training, file conversion, system changeover, and evaluation of the results

PHASE 43


Chapter 10


PHASE 44


Objectives

Describe the major tasks and activitiesthat are completed during the systems implementation phase

Discuss the role of the systems analyst during application development

Explain the importance of quality assurance and the role of software engineering in software development

PHASE 45


Objectives

Describe the different types of documentation the systems analyst must prepare

Explain the different phases of testing including unit testing, link testing, and system testing

Describe top-down design and modular design and the advantages of these approaches

PHASE 46


Introduction

During the systems implementation phase, the development team uses the system design specification as a blueprint for constructing the new system

Analysts and programmers have different roles during application development

An analyst's main task is to deliver clear, accurate specifications to a programmer

PHASE 47


Quality Assurance

Quality assurance is vitally important in all business areas, including IS functions

The main objective of quality assurance is to detect and avoid problems as early as possible

Quality assurance can detect Inaccurate requirements Design or coding errors Faulty documentation Ineffective testing

PHASE 48


Quality Assurance

Software engineering Stresses quality in software design

Solid design Effective structure Accurate documentation Careful testing

Click to see Figure 10-1Click to see Figure 10-1Package

PHASE 49


Quality Assurance Software engineering

Stresses quality in software design Solid design Effective structure Accurate documentation Careful testing

Software Engineering Institute (SEI) Mission is to improve quality of software-

based systems Capability Maturity Model is designed to

improve quality, reduce development time, and cut costs

Click to see Figure 10-2bClick to see Figure 10-2bPackage

Click to see Figure 10-2aClick to see Figure 10-2a Package

PHASE 410



Planning the overall design strategy Use top-down (modular) approach and partition

the system into subsystems and modules

Develop programs and modules Design, code, test, and document

Test the system Link test System test Complete all documentation


PHASE 411



Documentation review and application design Program designs are based on

System design specification Prior phase documentation DFDs Process descriptions Screen layouts Report layouts Source documents Data dictionary entries

PHASE 412



Documentation review and application design Structure (hierarchy) charts

Show the organization of program modules and the functions they perform


PHASE 413





Program flowcharts Show the internal logic needed to perform

program tasks and provide output


PHASE 414





Program flowcharts Show the internal logic needed to perform

program tasks and provide output Pseudocode

Documents the program’s logical steps


PHASE 415



Coding Process of turning program logic into specific

instructions that can be executed by the computer system

Many programming languages exist Visual C++ Access Basic Visual Basic SQL HTML Java


PHASE 416



Testing the application Testing is necessary to ensure that all programs

function correctly First step is to detect syntax errors and obtain a

clean compilation Next step is to eliminate logic errors

Techniques include desk checking, structured walkthrough, and code review

Final step is testing Unit, link, and systems testing



PHASE 417



Testing the application Unit testing

Involves an individual program Objective is to identify and eliminate

execution errors and any remaining logic errors

Stub testing is a technique of using stubs to represent entry or exit points that will be linked later to another program or data file

PHASE 418



Testing the application Link testing

Involves two or more programs that depend on each other

Also called string testing, series testing, or integration testing

Link testing ensures that the job streams are correct

Test data is necessary to simulate actual conditions and test the interface between programs

PHASE 419


Application Development Testing the application

System testing Involves the entire information system and

includes all typical processing situations Requires users to verify all processing

options and outputs Uses live data Involves a final test of all programs Ensures that proper documentation is ready Verifies that all system components work

correctly Confirms that the system can handle

predicted data volumes in a timely and efficient manner

PHASE 420


TRADEOFF How far should you go with system testing? Tradeoff: pressure for the new system from

users and managers vs. the need to avoid major errors

Typical issues to consider What is the judgment of analysts, programmers,

IS management, and the project manager? Do potential problems exist that might affect the

integrity or accuracy of data? Can minor changes be treated as future

maintenance items?

PHASE 421


A KEY QUESTION

During the first two weeks of system testing, a number of minor problems were detected and fixed

One department manager insists on a “no-risk” guarantee, while other users are clamoring for the new system to become operational

How do you respond?


PHASE 422


Documentation

Explains the system and helps peopleinteract with it

Types of documentation Program documentation System documentation Operations documentation User documentation

PHASE 423


Documentation

Program documentation Begins in the systems analysis phase and

continues during systems implementation Includes process descriptions and report layouts Programmers provide documentation with

comments that make it easier to understand and maintain the program

An analyst must verify that program documentation is accurate and complete

PHASE 424


Documentation

System documentation System documentation describes the system’s

functions and how they are implemented Most system documentation is prepared during

the systems analysis and systems design phases Documentation consists of

Data dictionary entries Data flow diagrams Screen layouts Source documents Initial systems request

PHASE 425


Documentation

Operations documentation Typically used in a minicomputer or mainframe

environment with centralized processing and batch job scheduling

Documentation tells the IS operations group how and when to run programs

Common example is a program run sheet, which contains information needed for processing and distributing output

PHASE 426


Documentation User documentation

Typically includes the following items System overview Source document description, with samples Menu and data entry screens Reports that are available, with samples Security and audit trail information Responsibility for input, output, processing Procedures for handling changes/problems Examples of exceptions and error situations Frequently asked questions (FAQ) Explanation of Help & updating the manual


PHASE 427


Documentation

User documentation Written documentation material often is

provided in a user manual Analysts prepare the material and users review it

and participate in developing the manual


PHASE 428


Documentation User documentation

Written documentation material often is provided in a user manual

Analysts prepare the material and users review it and participate in developing the manual

Online documentation can empower users and reduce the need for direct IS support Context-sensitive Help Interactive tutorials Hints and tips Hypertext On-screen demos


PHASE 429


Management Approval

After system testing is complete, the results are presented to management Test results Status of all required documentation Input from users who participated Detailed time schedules, cost estimates, and

staffing requirements

If approved, a schedule for system installation and evaluation will be established

PHASE 430


SOFTWEAR, LIMITED

The ESIP development team reviewed True Blue Systems’ design recommendation


PHASE 431


SOFTWEAR, LIMITED

The ESIP development team reviewed True Blue Systems’ design recommendation

The team then used a top-down approach to partition the system into a set of modules

Each module represented a program or function to be performed by one or more macros or code procedures

The team carefully reviewed all ESIP system tasks and prepared a structure chart


PHASE 432


SOFTWEAR, LIMITED Mainframe interface

Extract module tasks Prepare a design for the extract module Write the commands, using Visual Basic Unit test the ESIP program module with test

data, using stubs to indicate inputs and outputs

Verify the results Create a procedure for downloading the

deduction file from the mainframe to the ESIP server

Test the download procedure and update the documentation

PHASE 433


SOFTWEAR, LIMITED ESIP server

Database development tasks Finish switchboard and screen designs, with

user input, including custom menus & icons Design all necessary reports Verify ERDs record designs Define data tables, identify primary keys,

and link tables into a relational structure Load test data Design and test queries Design and test macros and code modules Complete work on security features

PHASE 434


SOFTWEAR, LIMITED

Completing application development ESIP design and unit testing was completed in

three weeks Link testing was performed successfully System testing revealed that several minor

changes and corrections were necessary All changes received user approval and were

documented carefully A user manual was developed, with substantial

input and participation from users themselves