SYSTEM DEVELOPMENT

AND
IMPLEMENTATION
STRUCTURE CHART
(program design)
Structure Chart
Describes functions and sub-functions of each part of
system

Shows relationships between modules of a computer

program

Simple and direct organization

Each module performs a specific function

Each layer in a program performs specific activities

Chart is tree-like with root module and branches

Structure Chart Symbols

Structure Chart symbols represent

Modules
Conditions
Loops
Data couples
Control couples
Structure Chart - Module

- Rectangle represents a module (program or

subroutine)
- Control Modules (mainline) branch to sub-
modules
- Library modules are reusable and can be
invoked from more than one
- Control Module elsewhere in the system
Structure Chart – Module (cont.)
Structure Chart - Data Couple

• Arrow with an empty circle

• Shows the data one module passes to another
 Structure Chart - Control Couple
• Arrow with filled circle
• Shows a message (flag) which one module sends to another
• Module uses a flag to signal a specific condition or action to
another module
Structure Chart - Condition
• A line with a diamond
• Indicates that a control module determines which
subordinate module will be invoked
Structure Chart - Loop
• A curved arrow representing a loop
• One or more modules are repeated
A Simple Structure Chart for the
Calculate Pay Amounts Module
Structure Chart for Entire Payroll Program
Structure Chart & DFDs
Structure Chart & DFDs
Cohesion and Coupling
Cohesion measures the scope of a certain module,
and the processing characteristics of the module. A
module that performs only one function or task has a
high degree of cohesion

Coupling measures the relationship and mutual

dependence among the modules. What is needed is for
it to be a module that is less dependent on another
module, or what is called loosely coupled.
Evaluating the Quality of a Structure
Chart
Module coupling
Measure of how module is connected to
other modules in program
Goal is to be loosely coupled (independent)
Module cohesion
Measure of internal strength of module
Module performs one defined task
Goal is to be highly cohesive
Cohesion (contd)
 Test Planning
Testing starts with the tester’s developing a
test plan that defines a series of tests that will
be conducted.
It is impossible to test every possible
combination of input and situation; there are
simple too many possible combinations.
A really good test would include a test case
with potentially valid data.
Test Plan
Types of Tests
Testing Separate Modules
 Unit Testing
Black Box Testing
Focuses on whether the unit meets requirements stated in
specification
White-Box Testing
Looks inside the module at actual code
 Integration Testing
User interface testing
Tests each interface function
Use-scenario testing
Ensures that each use scenario works correctly
Data flow testing
Tests each process in a step-by-step fashion
System interface testing
Ensures data transfer between systems
 System Testing
Requirements Testing
Ensures that integration did not cause new errors
Usability Testing
Tests how easy and error-free the system is in use
Security Testing
Assures that security functions are handled properly
Performance Testing
Assures that the system works under high volumes of activity
Documentation Testing
Analysts check the accuracy of documentation
 Acceptance Testing
Alpha Testing
Performed by users to assure they accept the
system; frequently repeats earlier tests
Beta Testing
Uses real data, not test data. Actual users monitor
for errors or needed improvements.
Error Discovery Rates for Different
Stages of Tests
Documentation
Documentation describes an information system
and helps the users, managers, and IT staff who
must interact with it.
Accurate documentation can reduce system
downtime, cut costs, and speed up
maintenance tasks
Documentation includes program
documentation, system documentation,
operations documentation, and user
documentation.
Program Documentation
Program documentation describes the inputs, outputs,
and processing logic for all program modules.
The program documentation process starts in the
systems analysis phase and continues during systems
implementation.
Systems analysts prepare overall documentation, such as
process descriptions and report layouts, early in the
SDLC.
This documentation guides programmers, who construct
modules that are well supported by internal and external
comments and descriptions that can be understood and
maintained easily.
System Documentation
System documentation describes the system’s
functions and how they are implemented.
System documentation includes data dictionary
entries, data flow diagrams, object models,
screen layouts, source documents, and the
systems request that initiated the project.
System documentation is necessary reference
material for the programmers and analysts
who must support and maintain the system.
Operations Documentation
If the information system environment involves a
minicomputer, a mainframe, or centralized servers, the analyst
must prepare documentation for the IT group that supports
centralized operations.
A mainframe installation might require the scheduling of batch
jobs and the distribution of printed reports.
In this type of environment, the IT operations staff serves as
the first point of contact when users experience problems with
the system
Typical operations documentation includes:
Scheduling information for printed output, such as report
run frequency and deadlines
E-mail and report distribution lists
Error and informational messages to operators and restart
procedures
Special instructions, such as security requirements
User Documentation
User documentation consists of instructions and
information to users who will interact with the
system and includes user manuals, Help screens,
and tutorials.
User documentation includes the following:
A system overview that clearly describes all major
system features, capabilities, and limitations
Overview of menu and data entry screen options,
contents, and processing instructions
Explanation of responsibility for specific input, output,
or processing requirements
Procedures for requesting changes and reporting
problems
Frequently asked questions