SYSTEMS ANALYSIS & DESIGN PHASE 4 SYSTEMS IMPLEMENTATION Application Development

SDLC Phases Phase 4: Systems Implementation Objectives 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

Chapter 10 Application Development

Objectives Describe the major tasks and activities that 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

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

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

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

Quality Assurance Software engineering Stresses quality in software design Solid design Effective structure Accurate documentation Careful testing Click to see Figure 10-1

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-2a Click to see Figure 10-2b

Application Development 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 Click to see Figure 10-3

Application Development 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

Application Development Documentation review and application design Structure (hierarchy) charts Show the organization of program modules and the functions they perform Click to see Figure 10-4

Application Development Documentation review and application design Structure (hierarchy) charts Show the organization of program modules and the functions they perform Program flowcharts Show the internal logic needed to perform program tasks and provide output Click to see Figure 10-5

Application Development Documentation review and application design Structure (hierarchy) charts Show the organization of program modules and the functions they perform Program flowcharts Show the internal logic needed to perform program tasks and provide output Pseudocode Documents the program’s logical steps Click to see Figure 10-6

Application Development 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 Click to see Figure 10-7

Application Development 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 Click to see Figure 10-8 Click to see Figure 10-9

Application Development 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

Application Development 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

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

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?

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? Click to see Figure 10-10

Documentation Explains the system and helps people interact with it Types of documentation Program documentation System documentation Operations documentation User documentation

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

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

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

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 Click to see Figure 10-11

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 Click to see Figure 10-12

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 Click to see Figure 10-13

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

SOFTWEAR, LIMITED The ESIP development team reviewed True Blue Systems’ design recommendation Click to see Figure 10-14

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 Click to see Figure 10-15

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

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

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