1. SYSTEMS ANALYSIS & DESIGN
PHASE 4
SYSTEMS IMPLEMENTATION
Application Development

2. 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

3. Chapter 10
Application Development

4. 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

5. 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

6. 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

7. 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

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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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?

21. 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

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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

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

31. 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

32. 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

33. 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

34. 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