System
Implementation
1
System Implementation
includes
1. Source code
2. Database
3. User documentation
4. Staff training
5. File conversion
2
Source code
Source code may be in one of the following
categories
1. Standard off- the –shelf package
2. Bespoke package
3. Amended standard package
4. standard package plus additions
3
Standard off- the –shelf package
• The organization purchases and installs a ready-made
solution.
• Advantages:
– Available immediately
– Cheaper
– High quality
– Can be update
– Relatively free of bugs
– Easy to handle
• Disadvantages
– It may be not well suited
– Competitors may well use the same package.
4
The factors to consider when choosing an off-
the –shelf application package
1. User requirements - does the package fit the user's
requirements
2. Processing times – Are the processing time fast enough?
3. Documentation – Is there full and clear documentation for the
user?
4. Compatibility-Is the package compatible with existing
hardware and software?
5. Controls – Access and security controls should be included
6. User-interface – the interface should be clear, logical and
consistent
7. Modification – can the package be modified by the user
8. Support maintenance and update
9. cost 5
2. Bespoke package
• Programmers write an application to meet the
specific needs of the organization.
• This can be a time-consuming and expensive
process
• It is involves all the tasks included in the
software development and testing cycle
6
Advantages
• The software should meet the organization's
specific needed.
• Competitive advantage
• It can make modification for future needs
• Disadvantages:
– It make risk
– Greater chance of bugs
– Waste time and cost
7
3. Amended standard package
• A standard package is purchased, but some
customization is undertaken so that the
software meets the organizations
requirements.
• This may require access to the source code.
• Development time should be much quicker.
• User can get good knowledge about the
software
8
4. standard package plus additions
• The purchased standard package is not
amended itself, but additional software that
integrates with the standard package is
developed. This also may require access to the
source code.
9
USER DOCUMENTATION
Technical manual
• The technical manual should include the following;
– Contact details for the original developers
– System overview
– System specifications including performance details
– Hardware technical specification
– System objectives
– Flowcharts or Data flow diagrams
– Entity models and life histories
– Individual program specifications
– Data dictionary
11
User manual
• The manual provides full documentation of
the operational procedures necessary for the
‘hands-on’ running of the system;
• Systems set-up procedures
• Security procedures
• Reconstruction control procedures
• System messages
• samples
12
STAFF TRAINING
Staff training
• Senior management training
– Executive Support System and Decision Support System
– Awareness of information technology, project mgt. skills
• Middle managers training
– Computing skill
– Management information system
– Office type software
• Operational staff
– Training should focus on specific tasks
14
Types of Tests
• Black-Box Testing
• White-Box Testing
• Gray-Box Testing
Black-box testing
• Black Box testing takes an external perspective of the
test object to derive test cases.
• The test designer selects valid and invalid inputs and
determines the correct output.
• There is no knowledge of the test object's internal
structure.
• Typical black box test design techniques include:
• Decision table testing
• Pair wise testing
• State transition tables
• Use case testing
• Cross-functional testing
16
White-box testing
• White box testing (clear box testing, glass box
testing, transparent box testing, or structural
testing) uses an internal perspective of the
system to design test cases based on internal
structure.
• It requires programming skills to identify all
paths through the software.
17
White-box testing cont..
• The tester chooses test case inputs to exercise
paths through the code and determines the
appropriate outputs.
• Typical white box test design techniques
include:
• Control flow testing
• Data flow testing
• Branch testing
18
Gray Box Testing
• Gray Box Testing is a software testing method
which is a combination of Black Box Testing
method and White Box Testing method.
19
Levels of testing
20
Unit testing
– unit testing is a software verification and validation
method in which a programmer tests if individual
units of source code are fit for use.
– Unit tests find problems early in the development
cycle
– Unit Testing is performed by using the White Box
Testing method.
Who performs it?
performed by software developers themselves
21
verification and validation
Criteria Verification Validation
Definition The process of evaluating work-products The process of evaluating
(not the actual final product) of a software during or at the end of
development phase to determine the development process to
whether they meet the specified determine whether it satisfies
requirements for that phase. specified business requirements.
Question Are we building the product right? Are we building the right
product?
Evaluation Items Plans, Requirement Specs, Design Specs, The actual product/software.
Code, Test Cases
Activities •Reviews •Testing
•Walkthroughs
•Inspections
22
2. Integration testing
• Integration is the phase in software testing in
which individual software modules are combined
and tested as a group.
• The purpose of integration testing is to verify
functional, performance, and reliability
requirements placed on major design items.
23
3. System Testing
System Testing is a level of the software testing
process where a complete, integrated
system/software is tested.
METHOD
Black Box Testing method is used.
Who performs it
independent Testers perform System Testing.
24
4. User acceptance testing
• User Acceptance Testing (UAT) is a process to
obtain confirmation by a Subject Matter Expert
(SME), preferably the owner or client of the
object under test, through trial or review, that
a system meets mutually agreed-upon
requirements.
25
FILE CONVERSION
File conversion
• This may be according to one of four
approaches
1. Direct changeover
2. Parallel running
3. Pilot operation
4. Phased changeover
27
1. Direct changeover
The old system is completely replaced by
the new system in one move
28
2. Parallel running
The old and new systems are run in
parallel for a period of time.
29
Pilot operation
The pilot operation involves selecting part or parts of an
organization to operate running the new system in parallel with
the existing system. When the branch or department piloting the
system is satisfied with the new system, they cease to use the old
system. The new system is then piloted in another area of the
organization.
30
Phased changeover
Selecting a complete section of the system for a direct
changeover. Introduce the rest phase by phase.
31
Method Advantages Disadvantages
Direct changeover Quick Risky
Minimal cost Could disrupt
Minimizes workload operations
If fails, will be costly
Parallel running Safe, built-in safety Costly-two systems
Provides way of verifying need to be operated
results of new system Time –consuming
Additional workload
32
Method Advantages Disadvantages
Pilot operation Less risky than direct Can take a long time to
changeover achieve Total
Less costly than changeover
complete parallel Not as safe as
running complete parallel
running
Phased changeover Less risky than a single Can take a long time to
direct changeover achieve total
Any problems should changeover
be in one area-other Interfaces between
operations unaffected parts of the system
may make this
impractical
33
System Maintenance
The process of modifying a software system or
component after delivery to correct faults,
improve performance or other attributes, or
adapt to a changed environment
34
Maintenance is thus concerned with:
• correcting errors found after the software has
been delivered
• adapting the software to changing
requirements, changing environments, ...
35
Kinds of maintenance activities
• corrective maintenance: correcting errors
• adaptive maintenance: adapting to changes in the
environment (both hardware and software)
• perfective maintenance: adapting to changing user
requirements
• preventive maintenance: increasing the system’s
maintainability
36
Key to maintenance is in development
• Higher quality less maintenance (corrective
maintenance)
• Anticipating changes less maintenance (adaptive
and perfective maintenance)
• Better tuning to user needs less maintenance
(perfective maintenance)
• Less code less maintenance
37
END
