|
| |
|
Systems Analysis and Design
Systems
Implementation Stage
1. Application development, including
designing, writing, testing, and documenting programs and code modules
2. Perform installation and evaluation
tasks, including user training, file conversion, system changeover, and
evaluation of the results
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 |
| 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 |
|
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 |
|
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 |
|
| 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 |
|
|
| 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 |
|
| 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 |
|
|
| 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 |
|
|
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 |
|
|
|
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 |
|
|
|
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? |
Documentation
| Explains the system and helps people
interact with it |
| Types of documentation
| Program documentation |
| System documentation |
| Operations documentation |
| User 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 |
|
| 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 |
|
|
| 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 |
|
| 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 |
|
| 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 |
|
|
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 |
| Recommendations |
| Detailed time schedules, cost estimates, and staffing requirements |
|
| Management Options
| Return to Design Phase |
| Retest |
| Proceed with Implementation |
|
| If approved, a schedule for system installation and evaluation will be
established |
| |
Notice: These notes are intended to be a supplement, not a substitute, to
attending class.
|
