CHAPTER 5: IMPLEMENTATION

5.1 Introduction

Implementation, according to Krugman (2016) is the process of delivering the working

system to the user. This phase therefore involves the system coding, validation, verification,
system testing as well as system installation. Successful implementation of the proposed
system should satisfy the user requirements defined in the objectives cited in the problem
definition.

The implementation phase focuses on the ways of presenting the application of the system to
the end users that is the actual activities that are undertaken for the system to be ready for
presentation. Therefore, there are some steps that have to be followed for a system to be
finally delivered to the final user and these include

 The Modules of the system

 Pseudo code

 Testing

 Installation

 User training

 System conversion

 Maintenance

5.2 Coding (Pseudo code)

Pseudo-Code is a programming-like formal form of English used to express a programming

plan to solve a problem. The pseudo code of the proposed system shows the general but full
overview of the system operations (Prat, J.F, 2013). It shows the entire process from data
input, processing to output for the system to produce the necessary required reports. Below is
a full pseudo code of the entire proposed system.

User Login Module

// Authenticates users and restricts access to unauthorized entry.

Accept Username, Password

Select username and password from users table.

Where username and password match the entered details.

If a match is found Then

Direct user to user’s main Page

Else

Display error message of login failure

// Close User Login Module

View goods in Kwekwe Polytechnic stock module

//allows the Kwekwe Polytechnic procurement officer to view products in stock

Accepts product name

Select product number from delivery table.

Where the product name matches the one entered.

If a match is found Then

Display a message of product availability

Else

Display a message of product inavailability

// Close View good in Kwekwe Polytechnic Stock Module

User Maintenance Module

Function Capture User Details

Check to see all textboxes

If all are filled then

Capture new supplier details;

Select user folder;

 Store data in supplier table;

Else

Popup message

Please fill up all fields

End if

// close capture details function

Score Card Maintenance Module

Function Score Card Details

Enter the supplier name;

Enter the rating of the score card;

Store data in online score card table;

// close score card details function

Function Output

Read entered score card details;

IF Rating is greater or equal to fifty and less than seventy five Then

Output Good;

Show score card details;

ELSE IF Rating is greater than seventy five Then

Output very good;

Show score card details;

Else

Output poor;

Show score card details;

// end if statement
 // close output function

// Close Score Card Module

Upload Quotation Module

Function Capture Quotation Details

If all fields have been filled Then

Capture new quotation details;

Select quotation folder;

Store details in quotation table;

Else

Display pop up message

Enter all details

// end if statement

// close quotation function

// Close Quotation Module

Upload order Module

Function Capture order Details

If all field are filled then

Capture new order details;

Select order folder;

Store details in order table;

Else

Popup message

Please fill up all fields

// close capture order details function

5.3 Testing

According to Pressman (2011), once source code has been produced, the software needs to be
tested so as to reveal and correct as many errors as possible before delivery of the system to
the customer. Pressman (2011) also stresses out that there is need to design a series of test
cases that have a high likelihood of finding errors so that they can be corrected. Testing was
carried out by the developer throughout the implementation phase to make sure that system
works as expected without giving any errors. The main purpose of system testing is to
discover bugs and correct them through debugging

Unit testing

Module
testing

Integration
testing

System
testing

Acceptance
testing

Fig 5.1 Testing procedure

5.3.1 Unit testing

Unit testing puts emphases on the testing of the every part of the system independently
(Pressman, 2011). This was carried out by testing every single component of the web based
and standalone Kwekwe Polytechnic procurement system. Unit testing was done to make
sure that the database connections are working properly; SQL statements are operating as
expected and data reports are generated correctly. The units tested were done in two
scenarios:

 Black box testing- this testing method not need any knowledge of internal design or
source code but is rather focused on the functionality, testing it against the functional
specifications in order to check for normal and abnormal behaviour of the system
(Pressman, 2001). The designer considered at the program specification and created a
set of test data that covers all the input, outputs and program functions.

 White box testing – this method uses the control structure of the procedural design to
come up with test cases (Pressman, 2001). This was done to test the running of the
code without error rather than its functionality. Therefore a study of the program was
made to test each possible path in the program until the developer was satisfied.

5.3.2 Module testing

Kendall and Kendall (2012) assert that module testing is a testing method that combines
dependent components and then tests them together to see if they can interact well with each
other. Using this testing method, each module was created separately and tested separately
then linked together. Usually module testing is done using the set objectives to measure the
reliability and functionality of our modules.

5.3.3 Sub-system testing

Modules that are related form subsystems, subsystem tests are therefore carried out to test for
data, stress, and error integrity (Sommerville, 2014). The database is also tested as a
subsystem of its own, known as link testing which it tests a collection of modules, which
have been integrated into subsystems so as to make sure that the job streams are correct.
Interface mismatches are corrected using this type of testing.

5.3.4 System Testing

System testing refers to a series of different tests done primarily to entirely exercise the
developed system (Pressman, 2011). It is carried out to ensure that the system is working well
(error free). Although each test serves a different purpose, they all work to verify that system
components are well integrated and perform their functions. System testing ensures the
system is error free and that all the mandatory fields are filled before data is stored. The
system’s functionality is measured using the stated objectives and other issues such as
compatibility are discussed and verified during systems testing.

5.3.5 Acceptance Testing

Pressman (2011) asserts that acceptance tests enable the end users to validate all
requirements. For the users to accept the system, they have to test the system in the actual
working environment. During this stage errors and omissions that the developers might have
missed are discovered. The system will be installed to a sample group of users who will
provide feedback on the systems’ functionality.

5.3.6 Alpha testing (Verification)

Alpha testing seeks to answer the question “Are we building the product right?” and this
according to Eppingner (2016), refers to the group of activities that are carried out to make
sure that the new software correctly implements a particular function. After comparing the
system functionality with the requirements specification, it has been concluded that the
system solves all stated

5.3.7 Beta testing (Validation)

Unlike alpha testing, Beta testing is done in an environment that cannot be controlled by the
developer (Pressman, 2011). The users recorded all problems encountered during beta testing
and reported these to the developer. As a result of problems reported during beta tests, the
developer made alterations. Errors and omissions in system requirements were discovered
and corrected resulting in a system that meet user requirements.
The system should be able to identify all the inventory that is available in the system
and also show the category

To show all purchases that are available for purchase whenever there is need
for a purchase
To record all the new purchases made by the system
To make new Requisitions orders

To item issuance of the things taken from requisition

5.4 Installation

The process of installation includes the conversion of data from the old system into the new
system and it is of great importance that at this stage enter data of the old system accurately
into the new (Sommerville, 2007). All suppliers and users of the Kwekwe Polytechnic
procurement system have be entered into the new system. A data clean-up will be done
initially so as to avoid carrying forward irrelevant data. The data capture clerks had to make
visual checks of the data.

5.5 Conversion methods

After taking into account a number of conversion methods, the best method was chosen. The
methods that were taken into account include the following:

 Pilot conversion

 Direct conversion

 Phased conversion
  Parallel conversion

5.5.1 Pilot conversion

According to Bentely (2014), pilot conversion is a selective implementation method. The new
system is installed in only those departments that require its use. Since only one location runs
both systems and the risk of failure is reduced to the pilot site, cost and risk are relatively
moderate. When the pilot site is satisfied with the new system, then the system is piloted to a
new pilot site. This may take a little while before the implementation of the system on a full
scale.

5.5.2 Direct Conversion

Direct conversion is an implementation process that requires the old system to be completely
“switched off” and the new system to be “switched on” immediately Kendall and Kendall
(2012). The old system is no longer available for use from that point onwards and all its valid
data is copied into the new system.In the context of the Procurement system of Kwekwe
Polytechnic, this means putting aside the old paper based entry and lookup system entirely
and have all users and participants use the new web based solution the next business day.This
method may prove to be very costly and resulting in loss of data if the new system does not
work as expected and it may also take time before the users understand it well. The risks to
the business of direct conversion far outweigh the financial benefit from simply switching off
the current system and immediately replacing it with the new solution.

5.5.3 Phased Conversion

In phased conversion, the new system is gradually introduced, replacing elements of the old
system bit by bit until the new system is fully implemented (Kendall and Kendall, 2012).
Users can adjust to the new system and cost and risk are relatively moderate since the system
is implemented in stages and the risk is limited to the module being implemented.

However, it may take a long time for the new system to be fully implemented as element by
element of the current system is replaced by its electronic counterpart. Phased conversion is
also relatively expensive as the system is implemented in stages as opposed to all at once
(such as in direct conversion).

5.5.4 Parallel Conversion

In this method of conversion, both system are run together for a period of time, comparing
results and if the new system produces good results, then the old system is dumped and the
new one is left (Kendall and Kendall, 2012). The advantage with this method is that it may
prove to be expensive, time wasting and resource wasting since it requires both time, human
resources and equipment for both systems. It is usually used when there is no full confidence
in the new system or when there is too much risk involved.

5.5.5. Recommended conversion method

The recommended conversion method would be a phased conversion, where the current
paper based system is transposed with the new system, process by process. Testing and
training would occur during the implementation of each new element during the
implementation. The time taken for complete conversion would take a lot longer than direct
conversion and more expensive, but the risk of system wide catastrophic failure is mitigated
by the virtues of a phased conversion. Extensive training would be required as the current and
the new system are diametrically distinct.With a phased conversion, the training could occur
over an extended period of time as opposed to all at once.

5.6 Maintenance

After handing over the system to its users, there is need for continuous check-ups to make
sure it continuously performs efficiently. Sommervile (2014) states that maintenance is a
process that is done on a regular basis to ensure that the newly implemented system meets the
objectives for which it was developed to address. Periodic review, audit or monitoring of the
system will be held with users or representatives of the development so as to ensure that the
system is operating properly and meets the organization’s objectives.

The system maintenance is important because:

 A system continues to change and evolves as it is used.

 The changes will be arising, change and evolve as it is used.

 The changes will be arising from change request due to the problems.

 Reports from operating groups who identifies the bugs in the system that must be
fixed.

 Changes will be arising from users.

There are three different types of system maintenance, which are:

 Corrective maintenance

 Perfective maintenance

 Adaptive maintenance

5.6.1 Corrective Maintenance

This is maintenance to repair software faults (Sommervile, 2014). Coding errors are usually
relatively cheap to correct; design errors are more expensive as they may involve the
rewriting of several program components. Requirements errors are the most expensive to
report because of the extensive system redesign which may be necessary. All the corrections,
activities from the investigation to the implementation are documented. Corrective
maintenance is performed at unpredictable intervals because a component's failure time is not
known. Corrective maintenance is done so as to restore the system to satisfactory operation
within the shortest possible time. Corrective maintenance is typically carried out in three
steps:

 Diagnosis of the problem. The developer must take time to locate the failed parts
or otherwise satisfactorily assess the cause of the system failure.

 Repair and/or replacement of faulty component. Once the cause of system

failure has been determined, action must be taken to address the cause, usually by
replacing or repairing the components that caused the system to fail.

 Verification of the repair action. Once the components in question have been
repaired or replaced, the maintenance technician must verify that the system is
again successfully operating.

5.6.2 Adaptive Maintenance

This will be performed whenever there are some new environments have to be applied. The
software has to be changed sometimes when a different hardware platform or operating
system has to be used (Sommerville, 2014). This will occur to the website as it will
constantly be updated to meet user requirements and also to provide the best of quality
services. As new requirements popup, the developer recommended a webmaster and a
systems administrator is employed to periodically check the validity of the system in meeting
its goals.
5.6.3 Preventative Maintenance

Preventive maintenance, unlike corrective maintenance, is proactive in nature that is the

practice of replacing components or subsystems before they fail in order to promote
continuous system operation (Sommerville, 2014). The schedule for preventive maintenance
is based on observation of past system behavior, component wear-out mechanisms and
knowledge of which components are vital to continued system operation. Cost is always a
factor in the scheduling of preventive maintenance. In many circumstances, it is financially
more sensible to replace parts or components that have not failed at predetermined intervals
rather than to wait for a system failure that may result in a costly disruption in operations.

5.7 Verification and validation

Verification is concerned with the input of details in all required fields and validation is
concerned with entering valid data and required in each field. In order for the database to
store data that is consistent there is need for proper validation of data as it is entered in the
system. Validation was considered when designing the system because of the following
reasons - :

 Data consistence - The new system will require the supplier to input data online.
Such information is very vital for the system’s proper functionality since it is such
data that will be manipulated by the system during the execution of draft statements.

 Reductions of errors - input errors are reduced by proper validation. This is so

because users will be notified or the system automatically rejects a command, thereby
stopping the error to occur.

5.8 Conclusion

This phase has looked in detail at the various testing procedures that were used, coding and
implementation of the Procurement system. Most testing was done on areas that correspond
to the objectives of the system. The objectives having been met and the system having been
implemented successfully, the project can thus be said to be a resounding success. Proper
verification and validation of the system was done so as to come up with a system with data
integrity. Finally the overall objectives stated in the initial stages of the project were met.
Bibliography

Bentley,T.D.(2004) Systems Analysis And Design Methods (6th Edition), Tata McGraw-
Hill: New Delhi.

Edwards, P. (1993), Systems Analysis and Design, McGraw-Hill: Watsonville.

Eppingner, E (2008), Software Engeneering, Prentice Hall: Dehli.

Godfrey, A (1999), System Design, Pearson education, United Kingdom

Kendall, E. and Kendall, J. (2002), System analysis and design 5th Edition, Prentice Hall:
Dehli.

Pressman,S.R. (2005) Software Engeneering:A practitioner’s approach 6th edition

,McGraw-Hill:Dehli.

Scot, C (19990 Database Principles, Prentice Hall, United States of America

Shtub,A. Bard,F.J. and Globerson,S., Project Management: Engineering, Technology and

Implementation, Prentice Hall: New jersey.
Sommerville, I. (2007), Software Engineering, Pearson Education: London

Stellman, A. and Greene, J.(2006) Applied Software Project management, O’Reilly:Texas.

www.zimparks.org(accessed on 21/02/2013).

http//:www.answers.reference.com/information/terminology (accessed on 19/02/2014).

http://www.overnightprogrammer.com/dreamweaver/codes (accessed 3 may 2014)

http://www.php.net/MySQL (accessed 1 may 2014)

http://www.sqltuner.com/databaseconnection/ (accessed 25 april 2014)