Principles and Practices of Software Production

ASIA PACIFIC INSTITUTE OF INFORMATION

TECHNOLOGY

INCOURSE ASSIGNMENT

PRINCIPLES AND PRACTICES IN SOFTWARE

PRODUCTION

Prepared By

A.N.Ahamed Nishadh (CB004081)

S.D.Ilangakoon (CB004041)

M.J.Dilshan Zuhdi (CB004050)

Module Code & Title

CE00003-2-PPSP

Cohort

HF11B1SE

Date of Submission

28th May 2012

Instructor

Ms.Nadeera Ahangama

Submitted in partial fulfillment for the degree of

Bachelor of Science (Hons) in Computing

i

ACKNOWLEDGEMENTS

Firstly we would like to thank our lecturer Ms.Nadeera Ahangama for all the help

and guidance given while doing this assignment.

Also there are many individuals who have helped us in numerous ways directly

and indirectly so that we were able to complete this assignment.

APIIT Lanka for providing us with resources and the Tech Team at APIIT Lanka

for their assistance at required times.

And last but not least our friends, parents and the well-wishers without whose

moral support and encouragement, we would not have been able to do a good job.

Finally, if there are any shortcomings in this project, then we request to excuse us

for all those and accept this documentation.

Ahamed Nishadh

Deshan Ilangakoon

Dilshan Zuhdi

ii

WORKLOAD MATRIX

AHAMED DESHAN DILSHAN

Initiation

Introduction 100%

Selection of Methodology 100%

Schedule Planning 100%

Project Planning Control 100%

Feasibility Study

Cost Estimation 100%

Risk Management 100%

Requirements Analysis

Requirement Analysis 50% 50%

Problem Background 100%

Proposed Solution 100%

Logical Design

Process Modeling 30% 40% 30%

Data Modeling 50% 50%

Data Dictionary 25% 50% 25%

Design Principles and

Concepts

100%

Architectural Design 100%

Physical Design

Interactive Screen Design 40% 30% 30%

Report Design 50% 25% 25%

Build

Programming Environment 50% 25% 25%

Development 50% 25% 25%

Test

Testing 100%

Implementation

Overall Documentation

(Layout)

80% 10% 10%

TOTAL 34% 33% 33%

iii

TABLE OF CONTENTS

1.0 - INTRODUCTION ............................................................................................... 1

2.0 – PROBLEM BACKGROUND OF CURRENT SYSTEM .................................. 2

3.0 – OVERVIEW OF THE PROPOSED SYSTEM ................................................... 4

4.0 – PROJECT MANAGEMENT .............................................................................. 5

4.1 – SCHEDULE PLANNING .......................................................................... 5

4.2 – COST ESTIMATION ................................................................................. 6

4.2.1 – TECHNIQUES USED IN COST ESTIMATION ............................... 6

4.2.2 –CONSTRUCTIVE COST MODEL (COCOMO) ................................. 7

4.2.3 – OBJECT POINTS CALCULATION ................................................... 8

4.3 – CONFIGURATION MANAGEMENT .................................................... 11

4.4 – CHANGE MANAGEMENT .................................................................... 12

4.5 – RISK MANAGEMENT ........................................................................... 13

5.0 – SELECTION OF METHODOLOGY ............................................................... 15

5.1 – SPIRAL METHODOLOGY .................................................................... 15

5.1.1 – ADVANTAGES OF SPIRAL METHODOLOGY ........................... 16

5.1.2 – DISADVANTAGES OF SPIRAL METHODOLOGY ..................... 16

5.2 – PROTOTYPING METHODOLOGY ...................................................... 16

5.2.1 – ADVANTAGES OF PROTOTYPING METHODOLOGY ............. 17

5.2.2 – DISADVANTAGES OF PROTOTYPING METHODOLOGY ....... 17

5.3 – JOINT APPLICATION DEVELOPMENT (JAD) .................................. 17

iv

5.4 – DEFINITION OF JAD ............................................................................. 18

5.4.1 – ADVANTAGES OF JAD .................................................................. 18

5.4.2 – DISADVANTAGES OF JAD ........................................................... 18

5.5 – WATERFALL METHODOLOGY .......................................................... 18

5.5.1 – ADVANTAGES OF WATERFALL METHODOLOGY ................. 19

5.5.2 – DISADVANTAGES OF WATERFALL METHODOLOGY .......... 19

5.6 – SELECTED DEVELOPMENT METHODOLOGY ................................ 20

6.0 – REQUIREMENT ANALYSIS .......................................................................... 21

6.1 – NONFUNCTIONAL REQUIREMENTS ................................................ 21

6.2 – SYSTEM REQUIREMENT SPECIFICATIONS .................................... 21

6.2.1 – USER REQUIREMENTS .................................................................. 21

6.2.2 – SYSTEM REQUIREMENTS ...................................................... 22

6.0 – DATA FLOW DIAGRAMS ............................................................................. 24

6.1 – CONTEXT DIAGRAM ............................................................................ 24

6.2 – LEVEL 0 ................................................................................................... 25

6.3 – LEVEL 1 OF PROCESS 1 ....................................................................... 26

6.4 – LEVEL 1 OF PROCESS 2 ....................................................................... 27

6.5 – LEVEL 1 OF PROCESS 3 ....................................................................... 28

7.0 – DATA DICTIONARY ...................................................................................... 29

7.1 – DATA STORES ....................................................................................... 29

7.2 – DATA FLOWS ......................................................................................... 32

v

7.3 – EXTERNAL ENTITIES ........................................................................... 40

7.4 – PROCESSES ............................................................................................ 41

8.0 - ENTITY RELATIONSHIP DIAGRAM ........................................................... 45

9.0 – ENTITY LIFE HISTORY ................................................................................. 46

9.1 – PROBLEM LOG ...................................................................................... 46

9.2 – EMPLOYEE DETAILS ........................................................................... 47

9.3 – CALL RECORDS .................................................................................... 48

9.4 – SOFTWARE TABLE ............................................................................... 49

9.5 – HARDWARE DETAILS .......................................................................... 50

9.6 – SPECIALIST TABLE .............................................................................. 51

10.0 – DESIGN PRINCIPALS AND CONCEPTS ................................................... 52

10.1 – WHAT DESIGNING PRINCIPLE MEANS? ........................................ 52

10.2 – DESIGN CONCEPTS ............................................................................ 52

10.2.1 – ABSTRACTION .............................................................................. 52

10.2.2 – REFINEMENT ................................................................................ 53

10.2.3 – MODULARITY ............................................................................... 53

10.2.4 – INFORMATION HIDING .............................................................. 54

10.2.5 – DESIGN AND REUSE OF PATTERNS ........................................ 54

11.0 – ARCHITECTURAL DESIGN ........................................................................ 55

11.1 – WHAT IS ARCHITECTURAL DESIGN? ............................................ 55

11.2 – SYSTEM LOGICAL ARCHITECTURE ............................................... 55

vi

11.3 – HIERARCHY CHART .......................................................................... 56

12.0 – SCREEN DESIGNS ........................................................................................ 58

12.1 – ADD NEW CALL .................................................................................. 58

12.2 – ADD NEW CALL .................................................................................. 59

12.3 – ADD NEW HARDWARE ..................................................................... 60

12.4 – ADD NEW OPERATOR ....................................................................... 61

12.5 – ADD NEW SOFTWARE ....................................................................... 62

12.6 - ADD NEW SPECIALIST ....................................................................... 63

12.7 – ADD SOLUTION ................................................................................... 64

12.8 – EDIT PROBLEM SOLUTION .............................................................. 65

12.9 – LOGIN .................................................................................................... 66

12.10 – MAIN MENU ....................................................................................... 67

11.0 – REPORT DESIGNS ........................................................................................ 68

11.1 – PROBLEM REPORT ............................................................................. 68

11.2 – SPECIALIST PROBLEMS SUMMARY .............................................. 69

11.3 – UNSOLVED PROBLEMS REPORT .................................................... 70

11.4 – OPERATOR PROBLEMS SUMMARY REPORT ............................... 71

12.0 – DEVELOPMENT ENVIRONMENT ............................................................. 72

12.1 – LANGUAGE OF PROGRAMMING ..................................................... 72

12.2 – PROGRAMMING TOOLS .................................................................... 72

12. 3 – DATABASE .......................................................................................... 72

vii

13.0 – TESTING ........................................................................................................ 73

13.1 – QUALITY METRIC .............................................................................. 73

13.2 – TEST LOG .............................................................................................. 78

13.2.1 – LOGIN FORM ................................................................................. 78

13.2.2 – MAIN MENU FORM ...................................................................... 79

13.2.3 – NEW CALL FORM ......................................................................... 80

13.2.4 – NEW CALL DETAILS FORM ....................................................... 81

13.2.5 – ADD SOLUTION FORM ................................................................ 82

13.2.6 – EDIT PROBLEM SOLUTION FORM ........................................... 83

13.2.7 - ADD NEW SOFTWARE FORM ..................................................... 84

13.2.8 - ADD NEW HARDWARE FORM ................................................... 85

13.2.9 – ADD NEW OPERATOR FORM .................................................... 86

13.2.10 – ADD NEW OPERATOR FORM .................................................. 87

13.0 – BIBLIOGRAPHY ........................................................................................... 88

1

1.0 - INTRODUCTION

In this assignment we have been given the task of proposing and prototyping a

system for an Internal IT Helpdesk for Ceylon Telecom (Pvt) Ltd. The system is

an office automation system and is a small part of the larger system of Ceylon

Telecom (Pvt) Ltd.

Ceylon Telecom (Pvt) Ltd. uses a vast IT network and infrastructure within its

company. To assist with any problems relating to the IT network employees

within the company may call the Help Desk and log in a complaint. On receiving

this complaint the help desk operator will attempt to handle the problem

personally by referring existing information, if this fails he will refer the problem

over to a specialist who will then attend to the problem personally. The help desk

will operate for problems within the company only.

In this assignment of ours, we would be prototyping the system we are about to

develop and in this documentation you can read about the various different

aspects of the system that would help Ceylon Telecom (Pvt) Ltd take a decision

on whether to proceed with developing the system or not.

The system would be mainly used by the internal staff of the helpdesk department

and security is essential part of the system since a potential loophole in the system

can act as a backdoor entry into the larger system of the company.

2

2.0 – PROBLEM BACKGROUND OF CURRENT

SYSTEM

The current helpdesk functions manually, this poses a problem to the effect that

the help desk operator will be unable to handle the problem personally as the only

way to refer prior information is to manually search the paper based records for a

solution. This process is time consuming and means that all problems will have to

be referred to a specialist. Therefore an automated computer system will be used

to carry out the process of maintaining the records and for referring to the records

in the event that a similar problem arises at a later date. This will allow the

company to greatly improve on their response time for IT network problems,

utilize their resource better and help to reduce fall in productivity that would be

resultant if an IT network problem arose.

1. The system currently maintains all its records manually in hardcopy form

and none of the processes are automated at all. This leads to slower and a

lot of wasted resources in attempting to maintain the system and in trying

to keep all the records up to date.

2. There is a great risk of information being misused by people who should

not be allowed to view it. This problem is slightly improved by keeping all

the records in storage closets with locks. This feature can be easily

breached and also careless oversight on the part of the employee where

records are forgotten to be locked up after use.

3. Threat of records being destroyed easily. Since all records are maintained

in hardcopy format there is a really great possibility of the information

being ruined by factors beyond human control like water damage and the

possibility of harmful products accidently falling on to the records. The

possibility also exists that an external party may remove pages from the

legers containing the information.

4. Another threat faced by the current system is the threat of incorrect

information being entered into the system by accident. This is a great

threat as it’s only human to make mistakes and taking into consideration

the large amount of information passing through the company, it is

possible that a mistake might go unnoticed until it’s too late to correct it or

3

the damage is permanent. This will add to additional costs to the company

when it tries to rectify its errors.

4

3.0 – OVERVIEW OF THE PROPOSED SYSTEM

To overcome the above mentioned problems and to integrate the department with

the larger company system, we came up with the Ceylon Telecom Internal IT

Helpdesk System and the following features are what we intend to implement on

the final system that would be made if necessary approval is given by the client to

go ahead with the project.

The proposed system will be handling the following set of features:

User administration

Register a new user (For help desk operators and specialists )

Log-in

Record new call details

Create a new call

Edit call details

View/Search a specific call or set of calls

Record and search problems and solution details

Record New Problem

Record Solution

Update Problem

Search for existing problem

Search for existing solutions

Direct a call to specific specialist

Allocate task to specialist with minimum work load

Record specialist’s solutions

Maintenance tasks, Statistics etc.

View summary of all calls and jobs (by caller, by question type, by

specialist etc.)

View a report of turnaround time for a call and job completion (by

specialist, by question type etc.)

Backup

5

4.0 – PROJECT MANAGEMENT

4.1 – SCHEDULE PLANNING

A3 PAGE HERE

6

4.2 – COST ESTIMATION

Cost estimation is one of the main areas to be considered by project managers

when projects are taken. The cost estimation will give the developers and the

client a rough understanding on what the estimated cost of developing the system

will be. Over the years, various different types of estimated cost calculation

techniques have been developed by various people and these techniques have

been used at different stages.

4.2.1 – TECHNIQUES USED IN COST ESTIMATION

Cost Estimation is mainly divided into 3 different areas. They are:

Hardware and software costs including maintenance

Travel and training costs

Effort costs ( most significant )

These different types of costs, when calculated and put together will give a rough

picture on how much the project will cost in total and if it is feasible for the

company and the client to undertake such a project. For these different types of

costs, there are different techniques used to calculate. They are as follows.

Algorithmic Cost Modeling – A model based on historical cost

information that releases some software metric to the project cost is used.

An estimate is made of that metric and the model predicts the effort

required.

Expert judgment – Several experts on the proposed software

development techniques and the application domain are consulted. Each of

them estimate the project cost. These estimates are compared and

discussed. The estimation process iterates until an agreed estimate is

reached.

Estimation by analogy – This technique is applicable when other projects

in the same application domain have been completed. The cost of a new

project is estimated by analogy with these completed projects.

7

Parkinson’s Law – The law states that work expands to fill the time

available. The cost is determined by available resources rather that by

objective assessment.

Pricing to win – The software cost is estimated to be whatever the

customer has available to spend on the project. The estimated effort

depends on the customer’s budget and not the software functionality.

When looking at the above said techniques of cost estimations, it can be seen that

the algorithmic cost modeling technique is far easier to use to calculate the cost

rather than using any other techniques. This is because; algorithmic cost modeling

technique uses mathematical formulas which can give out static output that can be

used to measure.

The general form of Algorithmic Cost Modeling is as follows:

The above formula can be described as said below.

A = Constant Factor (Depends on local practice)

Size = Code Size (Function or Object Points)

B = Exponent Value (Lies between 1 and 1.5)

M = Multiplier (process, product & development attributes such as

requirement dependability, experience of development team)

4.2.2 –CONSTRUCTIVE COST MODEL (COCOMO)

The COCOMO model is a model that is derived from statistical information by

collecting data from past projects. The COCOMO model was first developed for

procedural programming languages but with the development of new high level

programming languages, the model was revised and the COCOMO II model was

made.

8

For the project that we have been assigned to undertake the COCOMO II model

has been selected. This is the best option as we used Visual Basic.net language to

program our system which is a high level programming language.

4.2.3 – OBJECT POINTS CALCULATION

Functional Requirement Object Weightage

Specify the user type, such as helpdesk operator,

specialist.

Screen

Module

Report

1

10

-

The user provides the user name and password.

Screen

Module

Report

1

-

-

The system checks if the user type, user name, password

is valid. If the login details are valid, system will allow the

user to log in to the system.

Screen

Module

Report

2

-

-

When a new call is made, information such as CallerID,

ID of helpdesk operator and other vital information will be

saved in the Call Log for future references.

Screen

Module

Report

2

10

-

The caller name will be checked against a register of all

personnel to retrieve the caller's ID, job title, and

department.

Screen

Module

Report

2

-

-

The equipment will also be checked against a register of

equipment to find the equipment type and make.

Screen

Module

Report

2

-

-

The software will be checked to see if it is licensed

software.

Screen

Module

Report

2

-

-

The caller will give his/her problem to the help desk

operator, at the same time, the system will provide a

reference number to the caller for further enquiries about

the same problem.

Screen

Module

Report

1

-

-

According to the problem details, help desk operator will

give an appropriate problem type for it. At the same time

Screen

Module

1

10

9

the problem details will be saved in the Problem Log

table.

Report -

According to the problem type the system will check for

solutions with the similar problems from the Solutions of

previous problems and will send a notification whether

there is a solution for the problem or not.

Screen

Module

Report

3

-

-

If there a similar solution for the problem, the system will

provide the problem solution to the operator who will pass

it on to the caller.

Screen

Module

Report

2

-

-

If the problem cannot be solved immediately the helpdesk

operator will direct the problem to a specialist in order to

get the solution.

Screen

Module

Report

2

10

-

Once an unsolved problem is received, help desk operator

will select an appropriate specialist to solve the problem.

Screen

Module

Report

1

-

-

The specialist will be selected by considering their

specialized fields and the current workload they have.

Screen

Module

Report

2

-

-

Once the specialist solves the problem, the problem

solution will be provided to the caller, and at the same

time the resolved details will be saved in the solution table

along with the problem number, date and time.

Screen

Module

Report

2

-

-

Monthly and yearly the company administrative will get a

report of all calls.

Screen

Module

Report

2

10

5

And they will also get a report of turnaround time for a

job completion as well, so that it will be easy to the

company administrative when making decisions.

Screen

Module

Report

2

-

5

TOTAL 90

10

In the above equation,

A = 2.94

Size = (90 * 28)/1000 where 172 is the number of object point and 28 is

the object point constant for VB.Net.

B = 1.1

M = PERS*RCPX*RUSE*PDIF*PREX*FCIL*SCED = 2*1*1*2*1*2*1

= 8

By substituting the above values to the equation,

Effort = 2.94 * [(90*28)/1000]1.1 * 8 = 65.19

We can assume that the Average Cost per One Person Month is 50,000/-

Therefore,

Software Cost = Effort Estimate * Average Cost per One Person Month

= 65.19 * 50,000

= 3,259,500 /=

(http://www.qsm.com, n.d.)

11

4.3 – CONFIGURATION MANAGEMENT

Configuration management is a tool or a practice used to help when the

developers of a system or program requires to upgrade an existing system. This

change requires for large costs and effort to be expended and this configuration

management aims to manage this process and to control and limit unnecessary

resources.

There can be many reasons for changing the system or for upgrading the system.

Some of the reasons being the need to implement the system on a new Operating

System or as the original system having a few technical problems that have be

resolved in the new system or for modifications or additional features that have

been developed.

Many internationally accepted standards are available that will govern the way

that the configuration of a system will have to be carried out. Some of the

standards that are available are the IEEE Standard 828 – 1990 IEEE Standard for

Software Configuration Management Plans or the ISO 10007 – 1995Quality

Management, Guidance for Configuration Management are among several

standards that are available (Anon., 2002).

Types of documents to be changed – This section pertains to the management of

the documents that will be affected due to the changes that will be made to the

system. In managing the documents the team has to be careful not to overlook any

of the documents that require amendments to be made to it. This can be caused by

the fact that there may be over thousands of documents on a system depending on

how complex and how comprehensive the documentation on the system has been

made.

Documentation Naming Scheme – A clear and effective naming standard should

be followed when maintaining the document names so that they can be clearly be

referred to and the slandered is maintained right throughout the duration of the

project life cycle. The naming should be carried out in a hierarchical scheme

where the multilevel method is the easiest and the simplest to carry out.

12

CM Database used to Record Configuration Information – A configuration

database is used to maintain the information of the all information relating to

various aspects of the system in order to cater to the various questions regarding

the information system. The database will contain information like the current

version of the system, platform and what components of the system will change

when a certain action is performed.

4.4 – CHANGE MANAGEMENT

Systems during the course of their life undergo rigorous changes are aimed at

facing short comings and to add new additional features that were not previously

available in the system. Managing these changes is essential for any system as

sometimes these changes can be extensive and programmers may be

overwhelmed and miss out on certain segments that require upgrading.

To ensure that this problem of oversight and miscarriage of the new system

upgrades does not occur, it is vital to manage the changes that are being made to

the system and to make a systematic plan on what the changes to the system have

to be and the best and most systematic way of implementing the system’s

changes. It is for this purpose that change management is used, to manage and

maintain the changes that are made to the system.

13

4.5 – RISK MANAGEMENT

Risks Probability Effects

Management of the client

organization not being cooperative

with the developers.

High Serious

Inadequate or incompatible

hardware and/or software at the

end user consoles.

High Tolerable

Skilled staff is not available at the

client organization to work on the

system to gain full efficiency of the

system.

High Tolerable

Staff tasked with developing the

system fall sick in large numbers.

Low Serious

Misunderstandings between team

members.

Low Serious

Inefficient code being done by

developers

Moderate Catastrophic

System hardware or/and software

gets corrupted and becomes

unusable.

Moderate Serious

Proper system requirements are not

provided by the client.

Very High Catastrophic

The client keeps changing the

requirements at different stages

which will hinder the development

process in the given timeline.

Very High Serious

The time allocated to complete a

task goes over the estimated time

taken to complete it.

Very High Serious

Project goes over the allocated Very High Serious

14

budget.

Expired or outdated tools being

used for development can cause

inability to make use of new

features available in tools.

Very High Tolerable

15

5.0 – SELECTION OF METHODOLOGY

The most important and difficult task is to select the most appropriate

methodology and implement the chosen methodology. These methodologies have

a history of more than 40 years. These methodologies sometimes result in defects

such as low budgets, better quality and shorter delivery time of the developed

product and etc. All the system must not suit one software methodology. Each

methodology has their own feathers which are different to others.

There are many different types of methodologies, they are

5.1 – SPIRAL METHODOLOGY

Spiral methodology was developed by Boehm in 1988. This is an evolutionary

version of incremental prototyping. A cycle in the spiral is represented by an

iteration of the prototype. This methodology is risk oriented. The project

requirements will be very difficult and where the new technologies are used. And

these are also used for large scope projects.

16

(Thompson, 2008)

5.1.1 – ADVANTAGES OF SPIRAL METHODOLOGY

Estimation of schedule, budget becomes easier as work progresses because

important issues are identified earlier.

Software engineers can start their works on the project earlier.

User and client involvement in the development is greater.

Based on the workload the cost is balanced.

5.1.2 – DISADVANTAGES OF SPIRAL METHODOLOGY

Risk of not meeting the budget and schedule.

The project control will be a problem by repeating process.

To implement and handle the method professional and skilled project

managers are needed.

Its highly customized and limiting re-usability.

(IT Acumens Discussion Zone, 2008)

5.2 – PROTOTYPING METHODOLOGY

The basic idea of the prototype is instead of finalizing the requirements before a

design or coding can precede, a throwaway prototype is built to understand the

requirements. This is built based on the currently known requirements. Prototype

development consists of coding designing and testing but these phases are not

done thoroughly or formally. By this client can get a “real feel” of the system.

And the interactions with prototype can satisfy the client by understanding the

requirements of the desired system. This prototyping method is very useful for

complicated and large systems to determining the requirements of the existing

system. The diagram below shows the prototyping approach.

17

5.2.1 – ADVANTAGES OF PROTOTYPING METHODOLOGY

User gets a better understanding about the system which is developed

because in this method user gets a working model of the system.

Errors can be identified much earlier as the system is mode side by side.

Leading to better solutions quicker user feedback is available.

Users are actively involved in the development.

5.2.2 – DISADVANTAGES OF PROTOTYPING

METHODOLOGY

It can complicate the system scope and expand beyond original plans.

Sometimes problems cannot be identified till system testing.

Until the system is fully coded system performance cannot be checked.

It can lead to implementing and then repairing way of building the system.

(http://www.freetutes.com, n.d.)

5.3 – JOINT APPLICATION DEVELOPMENT (JAD)

In 1977 Chunk Morris of IBM conceived JAD. It was a method of gathering

requirements for geographically distributed systems. In late 1890s many

companies were implementing facilitated JAD workshops for analysis and design.

18

5.4 – DEFINITION OF JAD

Joint Application Development (JAD) is a process that accelerates the design of

information technology solutions. JAD uses customer involvement and group

dynamics to accurately depict the user's view of the business need and to jointly

develop a solution. Before the advent of JAD, requirements were identified by

interviewing stakeholders individually. The ineffectiveness of this interviewing

technique, which focused on individual input rather than group consensus, led to

the development of the JAD approach.

5.4.1 – ADVANTAGES OF JAD

It Enhances quality.

It allows teamwork with the customer.

It Accelerates design.

Creates a design from the customer’s perspective.

It lowers the development and maintenance costs.

5.4.2 – DISADVANTAGES OF JAD

Need talented and skilled people to operate the process.

Work must be done according to schedule.

Expensive methodology compared to others.

5.5 – WATERFALL METHODOLOGY

Waterfall methodology is one of the oldest software development processes. It’s

considered as classic approach to the system development life cycle. This model

unless a particular stage is completed the next stage cannot be started off. And the

development method is liner and sequential. If has distinct goals for each phase of

development. The bellow diagram describes the water fall methodology.

19

5.5.1 – ADVANTAGES OF WATERFALL METHODOLOGY

1. It’s easy to implement because it’s a linear model.

2. Minimal amount of resources are required to implement this model.

3. End of every stage, documentation is produced.

4. After every major stage of software coding testing is done to check the

correct running of the code.

5.5.2 – DISADVANTAGES OF WATERFALL

METHODOLOGY

Small changes or errors that arise in the completed software may cause a

lot of problems.

Often, the client is not very clear of what he exactly wants from the

software. Any changes that he mentions in between may cause a lot of

confusion.

It depends on the early identification and specification of requirements.

(Alam, 2012)

20

5.6 – SELECTED DEVELOPMENT METHODOLOGY

After a thorough research about all the methodologies we decided to apply

waterfall methodology in our project. We selected this methodology for our

project because there were several important facts. The main point is the

requirements, objectives and the solution of the project was given clearly. The

helpdesk system needs to developed in 2 months’ time, there are no users middle

of project and the budget should be reasonable because we are not developing a

large system and for all these things we decided the waterfall methodology will be

the correct methodology to implement this system.

Waterfall methodology allows us to analyze and planning of the project. In this

we have to complete one process at a time without completing we cannot move to

other process. By this stepwise process allows us to test the completed process.

By this we can find the errors and fix it before we move to our other process.

Since this is not a large project the waterfall methodology will be easy to

implement and identify the system requirements.

And we also discussed about other methodologies like Spiral methodology, this

methodology is identified as the best methodology for identifying risks of the

system. In this project the requirements, objectives are clear and the time period

and budget are less we decided to drop this methodology. We considered about

the Hybrid methodology but this methodology needed more time period and a

larger budget. (Margaret Rouse, 2007)

Considering all these matters we decided to implement the waterfall methodology

in our project.

21

6.0 – REQUIREMENT ANALYSIS

6.1 – NONFUNCTIONAL REQUIREMENTS

Cannot run on other operating systems like Mac or Linux. Because our

software is developed in VB. And this is only works with MS

Windows. So we have to use a computer with MS windows XP or

higher version.

While running the software the system will 99% won’t crash if the

user follows the user manual.

User s who is not having experiences with automated systems will

averagely take a moth to get used to the system with training.

Users who have experiences with automated systems will averagely

take 3 weeks to get used to the system with training.

300MB of Hard disc space must need to install this software.

3sec must be taken to switch from one window to another window.

The software will be using to develop the system is Microsoft visual

studio 2010. The programing language is visual basic. Operating

system will be Microsoft windows 7.

The devices that use this system must be a laptop or a desktop with

Microsoft windows version installed.

While using the system pop up messages like” Do you want to delete”,

“Do you want to save “etc. are shown in for the safety of the data.

Passwords are highly protected 100% secured in database.

6.2 – SYSTEM REQUIREMENT SPECIFICATIONS

6.2.1 – USER REQUIREMENTS

1. Validate the user who will log into the system with user names and

passwords.

2. Maintain information of caller.

3. Maintain details of problems that callers have complained about.

22

4. Direct call to a specialist if needed.

5. Store information of all system records offline so that information will not

be lost.

6.2.2 – SYSTEM REQUIREMENTS

1. Username and Password

1.1. Retrieve user name and the password that is given by the user of the

system in the appropriate fields.

1.2. Compare user name and the password against the User name and

password fields that are in the User Database.

1.3. If user name can be mapped to a user name that is located in the User

database and the user password which is entered in the appropriate

password text field matches to that which is set for the specified user

display welcome message and take user to the Main Form of the system.

Else display an error message, clear the user name and password text

fields and ask the user to re-enter the information.

2. Caller Information

2.1.System user will ask for the caller name and record the information in the

new call form.

2.2.System will check if the caller is name entered in the new call form

matches that which is available in the Caller_Details database and then the

system will retrieve the caller ID, Job Title and Department matching to

the phone number from the Caller_Details database.

2.3.Enter the details of the defective computer, the operating system the

computer is running on and the software being used that the system user

will get from the caller and enter in the New Call Form which later will be

saved in the Problem_Details Table.

2.4.Search the caller information in the Caller_Details database by caller

number.

2.5.Add new caller information into the Caller_Details database if the caller

number is not matched to a caller ID in the database.

2.6.Edit Caller information in the event that the caller number has been

changed or the person using the number has changed. In this case the

23

system will pull up information of the caller from the Caller_Details

database and overwrite the existing information with new information.

3. Problem Details

3.1. Identify the problem by using a drop down search feature that is available

in the Problem_Details form which will get information from the

Problem_Details table.

3.2. Update records in the Problem_Details form if and when new information

is provided to the user of the system.

4. Solution Details

4.1.If caller problem cannot be solved immediately allocate a Specialist for

the task by searching for a suitable specialist in the Specialist database

and assigning the specialist to the task by entering the Specialist ID in the

Work_Order database.

4.2.When specialist is required to attend a problem search specialist in the

specialist database using the keywords of the problem to identify a

specialist who is allocated for a certain region. If more than one specialist

is found, check the specialist’s workload in the Work_Order database and

allocate the work to the specialist with the least amount of tasks allocated

to him.

5. Backup

5.1. Data in all databases will be copied and duplicated exactly in a separate

location regularly to ensure no data will be lost if original data is lost or

corrupted.

24

6.0 – DATA FLOW DIAGRAMS

6.1 – CONTEXT DIAGRAM

25

6.2 – LEVEL 0

26

6.3 – LEVEL 1 OF PROCESS 1

27


28


29

7.0 – DATA DICTIONARY

7.1 – DATA STORES

Name Employee Records

Description This table is a dummy table designed for simple purpose of

running the system. When the system is fully installed in the

company the main database this data store will be replaced

with the records pertaining to the employees that is already

available in the system.

Input Data Flows Employee ID

Output Data

Flows

Employee Details

Data Structure Employee Records=

EmpID+

EmpName+

EmpDept+

EmpJob+

EmpEmail

Name Caller Record

Description This data store will be used purely for recording the details of

the call. The call time, duration and the maker of the call will

be recorded in this data store. This record is needed as each

time a person calls the help desk the system is expected to

record the details of each and every call.

Input Data Flows Caller ID and Problem Number

Output Data

Flows

N/A

Data Structure Caller Record=

CallerID+

CallerName+

CallDate+

CallTime+

EmpID+

CallType+

CallerRecStatus

Name Computer Hardware and Software Records.

Description This data store will take note of the faulty equipment and/or

30

the software that is appearing to malfunction. This record will

be highly useful at later dates to know if the machine been

reported has had any previous records of malfunctions.

Input Data Flows Equipment Details

Output Data

Flows

N/A

Data Structure Computer Hardware and Software Records=

HWType+

HWSerialNumber+

HWName+

HWDescription+

HWRecStatus +

SWName+

SWDescription+

SWStatus+

SWRecStatus

Name Problem Log

Description The problem log is another vital part of the system. This log

will maintain records of all complaints that the help desk

receives and if the problem has been solved. This is vital

information as if a problem has a recurring nature then the

help desk operator will be able to provide the caller with the

information on how to solve the problem directly without

having to assign a specialist for the task.

Input Data Flows Problem Details

Problem Details

Updated Problem Details

Problem Solution Details

Output Data

Flows

Problem Type

Problem Solution

Data Structure Problem Log=

ProbID+

ProbDescription+

ProbType+

ProdStatus+

ProbSolution+

SWID+

SplID+

HWID+

ProbRecStatus

31

Name Specialist Details

Description This database contains the information of the specialist that

the company has at its disposal to attend to any new and

immediately irresolvable problems. The system will use the

details in the database to allocate new problems to specialist

depending on who has the lowest workload.

Input Data Flows Updated Specialist Work Log

Updated Specialist Work Log

Output Data

Flows

Specialist Details

Data Structure Specialist Details=

SplID+

SplName+

SplTel+

SplDept+

SplSpecialities+

SplEmail+

SplRecStatus+

32

7.2 – DATA FLOWS

Name Employee ID and Equipment Details

Description This flow will take key details from the caller so that the

system can process who is calling and what equipment is

faulty.

Origin/Source Caller External Entity

Destination 1.1 Search Employee Details Process

Data Structure Employee ID and Equipment Details=EmpID+

HWType+

HWSerialNumber+

HWName+ HWDescription+

HWRecStatus+

SWName+

SWDescription+

SWStatus+

SWRecStatus

Name Employee ID

Description Carries the Employee ID to the database so that the details of

the employee matching the ID can be extracted from the

database.

Origin/Source 1.1 Search Employee Details Process

Destination Employee Records Data Store

Data Structure Employee ID=

EmpID

Name Employee Details

Description Returns the details of the employee searched to the process so

it can be displayed on the system.

Origin/Source Employee Records Data Store

Destination 1.1 Search Employee Details Process

Data Structure Employee Details =

EmpID+

EmpName+

EmpDept+

EmpJob+

EmpEmail

Name Employee ID

Description Provides the Employee ID to the Record process so that the

33

records of the call and the equipment can be saved with the

details of the employee.

Origin/Source 1.1 Search Employee Details Process

Destination 1.2 Record Call Details

Data Structure Employee ID=

EmpID

Name Problem Number

Description The process will provide the caller with a problem number that

is associated with the problem that he has called regarding.

Origin/Source 1.2 Record Call Details Process

Destination Caller External Entity

Data Structure Problem Number=

ProbID

Name Caller Details and Problem Number

Description This flow will take the call details such as time of call and the

duration to be written into the Call Record data store.


Destination Caller Record Data store

Data Structure Caller Details and Problem Number=

CallerID+

ProbID+

CallerName+

OperatorID+

CallDate+

CallTime+

EmpID+

CallType+

CallRecStatus

Name Equipment Details

Description Takes the details of the equipment or software that is causing a

problem and writes it to the database.


Destination Computer Hardware and Software Records Data Store

Data Structure Equipment Details=

HWType+

HWSerialNumber+

HWName+

HWDescription+

34

HWRecStatus +

SWName+

SWDescription+

SWStatus+

SWRecStatus

Name Problem Details

Description Carries the details of problem key words to the database so that

the database can be searched and all matching problems be

displayed.

Origin/Source 2.1 Search Problem Record Process

Destination Problem Log Data store

Data Structure Problem Details=

ProbType


Description Takes the details of the new problem so that they can be

written into the Problem Log data store.

Origin/Source 2.2 Record Problem Details Process

Destination Problem Log Data Store


ProbID+

ProbDescription+

ProbType+

ProdStatus+

ProbSolution+

SWID+

SplID+

HWID+

ProbRecStatus

Name New Problem Details

Description Provides the system with new information regarding an

existing problem. This information will be given written into

the system adding to the existing information.

Origin/Source Caller External Entity

Destination 2.2 Record Problem Details Process

Data Structure New Problem Details=

ProbID+

ProbDescription+

ProbType+

35

Name Updated Problem Details

Description Sends the information required to be written to the system

database.

Origin/Source 2.2 Record Problem Details Process


Data Structure Updated Problem Details=

ProbID+

ProbDescription+

ProbType+

Name Problem Type

Description Provides the process with a list of problem types to select from

in order to select a specialist.

Origin/Source Problem Log Data Store

Destination 3.1 Select Problem Type Process

Data Structure Problem Type=

ProbType

Name Selected Problem Type

Description This is the problem type that the operator of the system has

selected from the list that is available.

Origin/Source Operator External Entity

Destination 3.1 Select Problem Type Process

Data Structure Selected Problem Type=

ProbType

Name Problem Type

Description This is the problem type that the operator of the system has

selected from the list that is available.

Origin/Source 3.1 Select Problem Type Process

Destination 3.2 Search and Display Solution Process

Data Structure Selected Problem Type=

ProbType

Name Problem Solution

Description The information that is being sent here are the solutions, if

available, regarding the problem type that the operator has

36

selected.

Origin/Source Problem Log Data Store

Destination 3.2 Search and Display Solution Process

Data Structure Problem Solution=

ProbID+

ProbSolution

Name Problem Solution

Description Provide the caller with the solution for the problem selected if

it is available in the system.

Origin/Source 3.2 Search and Display Solution Process

Destination Caller External Entity

Data Structure Problem Solution=

ProbID+

ProbSolution

Name Update Specialist Work Log

Description Sends the new work load details to the system so that it can

update the specialist work log.

Origin/Source 5 Problem Solution Management Process

Destination Specialist Details Data Store

Data Structure Update Specialist Work Log=

SplID+

SplWorkLoad

Name Solved Log Details

Description This is the information regarding how to solve the problem at

hand that the specialist has come up with, to be used in the

event that the problem reoccurs.

Origin/Source Specialist External Entity

Destination 5 Problem Solution Management Process

Data Structure Solved Log Detail=

ProbID+

ProbSolution

Name Problem Solution Details

Description This flow carries the information to the database to be written

into the problem log database.

Origin/Source 5 Problem Solution Management Process


37

Data Structure Problem Solution Details

ProbID+

ProbSolution

Name Specialist Details

Description Provides the process with information of the specialist

available for a particular problem type so that the process can

allocate a specialist.

Origin/Source Specialist Details Data Store

Destination 4 Allocate Specialist Process

Data Structure Specialist Details=

SplID+

SplName+

SplDpt+

SplSpecialities+

SplWorkLoad


Description Provides the specialist selected for a particular problem with

the details of the problem so that the specialist will know the

details of the problem.

Origin/Source 4 Allocate Specialist Process

Destination Specialist External Entity


ProbID+

ProbDescription+

ProbType+

ProdStatus+

ProbSolution+

SWID+

SplID+

HWID+

ProbRecStatus

Name Updated Specialist Work Log

Description Updates the specialist’s work log to include the current task

that is being handled by the specialist.

Origin/Source 4 Allocate Specialist Process

Destination Specialist Details Data Store

Data Structure Update Specialist Work Log=

SplID+

38

SplWorkLoad


Description Provides the specialist allocation process with information

regarding the problem so that the process is able to select the

correct specialist for the task.

Origin/Source 3 Classifying New Problem Process

Destination 4 Allocate Specialist Process


ProbID+

ProbDescription+

ProbType


Description Provides the problem details supplied by the caller to help

identify the type of problem at hand.

Origin/Source 2 Record New Problem Process

Destination 3 Classifying New Problem Process


ProbID+

ProbDescription+

ProbType+

ProdStatus+

ProbSolution+

SWID+

SplID+

HWID+

ProbRecStatus


Description Provides the problem details supplied by the caller so that it

can be recorded in the system.

Origin/Source 1 New Call Process

Destination 2 Record New Problem Process


ProbID+

ProbDescription+

ProbType+

ProdStatus+

ProbSolution+

SWID+

39

SplID+

HWID+

ProbRecStatus

40

7.3 – EXTERNAL ENTITIES

Name Caller

Description This will be the caller who will contact the help desk

requesting for assistance with any faulty equipment. The

caller will provide the his/her relevant employee ID so that

the callers details can be extracted from the system. The

caller will also provide information regarding the problem

and will also provide further information that become

available at a later date.

Input Data

Flows

Problem Number

Problem Solution

Output Data

Flows

Employee ID and Equipment Details

New Product Details

Name Operator

Description Though through the operator all the call details and will be

recorded, the main input to the system will when the operator

selects the problem type where searching for a solution or a

suitable specialist to handle the problem at hand.

Input Data

Flows

N/A

Output Data

Flows

Selected Problem Type

Name Specialist

Description The specialist will be called on when the problem presented

contains no available solutions in the database. Once a

problem has been handled the specialist will update the

system with the information on how the problem was solved.

Input Data

Flows

Problem Details

Output Data

Flows

Solved Log Details

41

7.4 – PROCESSES

Name 1.1 Search Employee details

Description This process will be used to identify and extract the caller’s

details from the system database using the caller ID. This

information once extracted will be sent to the Record Call

Details Process.

Input Data

Flows

Employee ID and Equipment Details

Employee Details

Output Data

Flows

Employee ID

Employee ID

Process

Description

BEGIN

READ Employee ID

READ Equipment Details

GET Employee ID list from Employee Records

Database

LOOP UNTIL Employee ID NOT EQUALS Null

IF Employee ID EQUALS Employee ID from

Database

GET Employee Details

DISPLAY Employee Details

PUT Employee ID to 1.2 Record Call Details

Process

ELSE

DISPLAY Error Message

END IF

END LOOP

END

Name 1.2 Record Call Details

Description This process will write to the database the details of the call

and the details of the faulty equipment to the system records.

Input Data

Flows

Employee ID

Output Data

Flows

Caller Details and Problem Number

Equipment Details

Problem Number

Process

Description

BEGIN

GET Employee ID from 1.1 Search Employee Details

Process

WRITE Caller Details and problem Number to Caller

Record Database

42

WRITE Equipment Details to Computer Hardware

and Software Records Database.

DISPLAY Problem Number

PUT Problem Details to 2.2 Record Problem Details

Process

PUT Problem Details to 2.1 Search Problem Records

Process

END

Name 2.1 Search Problem Records

Description This process is used to identify if a problem is existing in the

system or not. If the problem is available then new

information will be written in to the existing problem or if it

is unavailable then a new problem log will be created.

However this process is only tasked with identifying if a

problem exists or not, and not with writing of information.

Input Data

Flows

N/A

Output Data

Flows

Problem Details

Process

Description

BEGIN

GET Problem Details from 1.2 Record Call Details

Process

READ Problem Type from Problem Log Database

RUN 2.2 Record Problem Details Process

END

Name 2.2 Record Problem Details

Description This process will be used to write to the system a new

problem details or update an existing problem with new

information.

Input Data

Flows

New Problem Details

Output Data

Flows

Problem Details

Updated Problem Details

Process

Description

BEGIN

GET Problem Type from 2.1 Search Problem Records

Process

IF Problem Type EQUALS TRUE

UPDATE Problem Log with New Problem

Details

ELSE

43

WRITE New Problem Details to Problem Log

Database

END IF

END

Name 3.1 Select Problem Type Process

Description This process will be used to present the help desk operator

with the types of problems that are available in the system.

Input Data

Flows

Select Problem Type Process

Problem Type

Output Data

Flows

N/A

Process

Description

BEGIN

GET Problem Type from Problem Log database

DISPLAY All Problem Type

READ Selected Problem Type from Operator

PUT Problem Type to 3.2 Search and Display

Solution Process

END

Name 3.2 Search and Display Solution Process

Description This process will take the information from the problem log

and display the solution to the caller and inform then on how

to solve the problem.

Input Data

Flows

Problem Solution

Problem Type

Output Data

Flows

Problem Solution

Process

Description

BEGIN

GET Problem Type from Select Problem Type

Process

GET Problem Type from Database

IF Problem Type from Database EQUAL Problem

Type from Operator

GET Problem Solution

DISPLAY Problem Solution

ELSE

RUN 4 Allocate Specialist Process

END IF

END

44

Name 4.0 Allocate Specialist Process

Description This process will look for a specialist who fits the problem

type and who has currently the lowest tasks at hand and

assign him to the problem at hand.

Input Data

Flows

Problem Details

Specialist Details

Output Data

Flows

Problem Details


Process

Description

BEGIN

GET Problem Details from 3 Classifying New Problem

Process

GET Specialist list from Specialist Details Database

IF Specialist Type EQUALS Problem Type

SELECT Specialist

CALCULATE Lowest work Load of

SELECTED Specialist

DISPLAY Problem Details to SELECTED

Specialist

UPDATE Specialist Work Log

ELSE

SELECT General Specialist

DISPLAY Problem Details to SELECTED

Specialist


END IF

END

Name 5 Problem Solution Management Process

Description This task will gather the information from the specialist

regarding the problem that has been solved and the solution

will be written into the Problem Log database for future

reference. The process will also update the Specialist Details

database to reflect the completion of the task.

Input Data

Flows

Solved Log Details

Output Data

Flows

Problem Solution Details


Process

Description

BEGIN

READ Solved Log Details

WRITE Solution to Problem Log database


END

45

8.0 - ENTITY RELATIONSHIP DIAGRAM

46

9.0 – ENTITY LIFE HISTORY

9.1 – PROBLEM LOG

47

9.2 – EMPLOYEE DETAILS

48

9.3 – CALL RECORDS

49

9.4 – SOFTWARE TABLE

50

9.5 – HARDWARE DETAILS

51

9.6 – SPECIALIST TABLE

52

10.0 – DESIGN PRINCIPALS AND CONCEPTS

10.1 – WHAT DESIGNING PRINCIPLE MEANS?

Designing principles gives a brief idea to the designer to arrange the various

elements of the system to be in a standard form for all the pages of that system.

The Main Design Principles Software engineers use are

Design process shouldn’t suffer from “Tunnel Vision”.

Design process shouldn’t reinvent the wheel.

Design process should minimize the intellectual distance between the

software and the problem in real world.

Design process should be traceable to the analysis model.

Design process should not be coding.

Design process should be valued for quality.

Design process should be built up to suit the purpose.

Design process should review to reduce conceptual errors.

Design process should be built up to degrade gently.

Design process should exhibit uniformity and integration.

10.2 – DESIGN CONCEPTS

Design concepts are very important while implementing software. For

implementing a quality software, must follow the below design concepts.

(www.itu.edu.tr, n.d.)

10.2.1 – ABSTRACTION

Abstraction allows one to concentrate on a problem at some level of

generalization without regard to irrelevant low level details. In high level

abstraction a result is stated in broad terms using problem environment of the

language. And in lower level abstraction a more procedural orientation is taken.

There are three forms of abstractions. They are

53

Data Abstraction- A named set of data that defines a data object.

Procedural Abstraction- A named sequence of instructions that has a

specific and limited function.

Control Abstraction- Implies a program control mechanism without

specifying internal details.

10.2.2 – REFINEMENT

One or more instructions of the program are decomposed into more detailed

instructions and are called refinement. It’s also known as top down Stepwise

refinement strategy. The basic architecture is developed iteratively and the step

wise hierarchy is developed. And it forces the designer to develop low level

details to design decisions at each stage while the design progresses.

10.2.3 – MODULARITY

In Modularity software is divided in into uniquely named and addressable

components called modules. And by this a complex problem is broken down to

many manageable pieces or modules.

Cognitive psychologists have proved that when humans dealing with complexity

they can only manage with five to nine chunks of information at a time. So when

designing the design of the system the strategy must undergo with the above

information.

And there are some objectives of Modularity

Modular Decomposability- It decomposes a problem into sub

problems by a systematic mechanism.

Modular Composability- It assembles into a new system by reuse of

existing components.

Modular Understandability- If the module can be understood as a

standalone unit, if it can be understood then it is easier to understand

and change.

54

Modular Continuity- Individual modules results in changes by small

changes to the system requirements rather than system wide changes

then the impact of the effects is reduced.

Modular Protection- If an error is found in the module then those

errors are localized and must not spread to other modules.

10.2.4 – INFORMATION HIDING

In this modules only interact through well-defined interfaces. It enforces access to

local entities and those they are visible through interfaces. Modules are

characterized by design decisions and they are hidden from others. Information

hiding is very useful in reducing coupling and accommodating change.

By information hiding it can reduce the global impact of local design decisions. It

emphasizes communication through controlled interface. It discourages the use of

global data and all these things leads to high quality software.

10.2.5 – DESIGN AND REUSE OF PATTERNS

In this we should concentrate about the design patterns. We have managed to keep

the consistency and similarity of our design pattern throughout our software.

First must concentrate about the past patterns of the project. If past patterns don’t

suit then creating a new one should be the next step of consideration and

contributing to the pattern library for the use of future projects. The design

patterns are range from architectural level down to component detail design.

(University of Technology, n.d.)

55

11.0 – ARCHITECTURAL DESIGN

11.1 – WHAT IS ARCHITECTURAL DESIGN?

It’s the first stage of the system process. It represents the links between the

specification and design processes, often carried out in parallel with some

specification activities. Also architectural design involves identifying major

system components and their communications.

11.2 – SYSTEM LOGICAL ARCHITECTURE

Form the Level 0 diagram the system can be divided in to many modules. The

diagram bellow has been divided in to 4. It gives a brief idea to identify the

preliminary phases that the system should contain. It’s the system preliminary

logical structure stage. The diagram bellow gives a brief idea about this.

Paste diagram in here..

56

From the above diagram the system divides into 4 sub modules. They are :

1. Call Recording

2. Problem Searching

3. Specialist Allocation

4. Solution Recording

By dividing the Level 0 DFD diagram as above, the data flows that do not

flow among other processes can be seen and those flows are independent and

by this the system can be divided into subsystems. This helps the designer

while designing the system. After identifying the sub systems the next step

will be hierarchy chart it shows the logical architecture of the system.

11.3 – HIERARCHY CHART

Hel

p D

esk

Solu

tio

n

Cal

l

Rec

ord

ing

New

calle

r

Pro

ble

m

Sear

ch

Spec

ialis

t

Allo

cati

on

So

luti

on

Rec

ord

ing

Pro

ble

m

log

Cal

ler

det

ails

Tech

nic

al

fau

lt

Allo

cate

Spec

ialis

t

Rec

tify

Solu

tio

n

57

Help Desk Solution

Problem

Searching

Diagnose Record

Problem

New

Problem

Update

Problem

Help Desk Solution

Solution Recording

Update

Solution

Prepare

Reports

58

12.0 – SCREEN DESIGNS

12.1 – ADD NEW CALL

This is the interface for adding a new call where firstly the call type, i.e. new call

or return call, is selected.

If the selected call type is new call, an employee ID is entered and the ‘submit’

button is then clicked after which the user is redirected to the new call details UI.

If the selected call type is return call, the call ID textbox gets enabled after which

the employee ID as well as the call ID is entered. The ‘submit’ button is then

clicked and the user is directed to the new call details UI.

59

12.2 – ADD NEW CALL

This is the interface for adding the new call details where the problem ID,

operator ID, employee ID and call date/time is auto generated.

The problem type is then entered and the problem status, i.e. pending or solved, is

selected. If the problem status is pending, a description of the problem is given

and the specialist ID, hardware ID and software ID are searched for by clicking

on each of the search buttons beside it. This opens another form where the

specialist, hardware and software IDs are noted and typed into the box.

If the problem status selected is solved, the problem solution text box gets enabled

and a solution is searched by clicking the ‘search solution’ button.

Upon completion of this form, the ‘save’ button is clicked after which a message

box saying ‘Problem Saved’ appears.

The ‘clear’ button clears all the text fields.

60

12.3 – ADD NEW HARDWARE

This is the interface for adding a new hardware where the hardware ID is auto

generated.

The name, type, serial number and a description of the hardware is then entered

into the respective textboxes and the ‘save’ button is clicked.


61

12.4 – ADD NEW OPERATOR

This is the interface for adding a new operator where the operator ID is auto

generated.

The name, user name and password are then entered into the respective textboxes

and the ‘save’ button is clicked.


62

12.5 – ADD NEW SOFTWARE

This is the interface for adding a new software where the software ID is auto

generated.

The name and description of the software is then entered into the respective

textboxes and the ‘save’ button is clicked.


63

12.6 - ADD NEW SPECIALIST

This is the interface for adding a new specialist where the specialist ID is auto

generated.

The name, telephone and email address is then entered into the respective

textboxes. The department, speciality 1 and speciality 2 are selected from the drop

down lists and then, the ‘save’ button is clicked.


64

12.7 – ADD SOLUTION

This is the interface for adding a new solution where the problem ID is entered

and the ‘submit’ is then clicked after which the form for editing the problem

opens.

65

12.8 – EDIT PROBLEM SOLUTION

This is the interface for editing a problem solution where the problem ID,

specialist ID, hardware ID and software ID are auto generated.

The problem type is then entered and the problem status, i.e. solved or pending, is

selected. If the problem status is solved, a problem description and problem

solution is entered.

If the problem status is pending, only a problem description is given.

Upon completion of this form, the ‘save’ button is clicked after which a message

box saying ‘Problem Updated’ appears.


66

12.9 – LOGIN

This is the interface for the login form which lets the user gain access into the

system by entering a user name and password.

When the ‘submit’ button is clicked, a message box appears with the message

‘Login Success’.

If the ‘clear’ button is clicked, the text fields get cleared.

67

12.10 – MAIN MENU

This is the interface of the main menu which appears once the user has

successfully logged into the system. It consists of buttons which, when clicked

directs the user to the required form.

The ‘exit’ button will shut down the entire system.

68

13.0 – REPORT DESIGNS

13.1 – PROBLEM REPORT

69

13.2 – SPECIALIST PROBLEMS SUMMARY

70

13.3 – UNSOLVED PROBLEMS REPORT

71

13.4 – OPERATOR PROBLEMS SUMMARY REPORT

72

14.0 – DEVELOPMENT ENVIRONMENT

While designing the system, we as a team thought in terms of developing this

system in the future too so that it can be successfully implemented once the

development it done completely. Keeping in mind the knowledge of the team

members of the project and the client’s requirements we decided to develop the

system in the following methods.

14.1 – LANGUAGE OF PROGRAMMING

All 3 members of the group were well versed in Visual Basic.net, C

Programming, C++ Programming, Java Programming and C# Programming. And

after much discussion, we unanimously decided to develop the system in Visual

Basic.net since all three of us were well versed in the language and we found it

easy to work with.

14.2 – PROGRAMMING TOOLS

All three members of the group were well accustomed to use and program using

Microsoft Visual Studio 2010 and since we decided to go ahead using this IDE

software tool to develop the system too. We would be using the Microsoft .Net

Framework 4.0 as it is one of the latest standards in the industry.

14. 3 – DATABASE

Since it is an obvious fact that a system of this magnitude needs to be linked with

a server to store and retrieve data from, we decided to use the Microsoft SQL

Server 2008 for this purpose. The integration between MS SQL Server and MS

Visual Studio 2010 is very close; it would be easy to work with this database

technology. Also the security concerns were looked into when the decision was

made.

73

15.0 – TESTING

15.1 – QUALITY METRIC

The quality metric for a system is used to measure software systems quantitatively

and qualitatively. Most often this hard to be done on software system but now,

using the quality metric measures it is possible to ascertain a proper value on a

software system by examining individual components of the quality metric of a

system.

(Anon., 2010)

Fan in/ Fan out:

This is a measure of the number of functions that will be calling in on

other functions. The larger the number of functions that are called by one

function the more the complexity of the system will arise. As a general

principal of practice software designers prefer to keep the fan in to a

maximum of seven at the very most.

When developing the system for Ceylon Telecom (Pvt) Ltd. great care was

taken to keep the number of function calls made my one function to the

only the most essential.

(Borysowich, 2007)

Length of Code

This metric is used to ascertain the quality of a program by evaluating the

length of code that is used to develop the system. The greater and the more

complex the code the more complex and more prone to error the system

becomes. However code length will have to be lengthy if the solution is

complex. Yet this still poses a problem where systems are more likely to

fail.

In the development of this project yet again great care was taken to

maintain the simplicity and the size of the code.

74

Cohesion

Cohesion refers to the oneness or the way in which a single class or

component works to achieve a single goal. If a single class has several

functions all trying to achieve a common goal then the class can be said to

be cohesive. On the other hand if a class has several functions striving to

achieve different and unrelated objectives then the system can be said to

be non-cohesive. In the case a class or component is said to be non-

cohesive then it is better to divide the class or component into smaller

separate parts to perform their task and achieve their goals separately.

Therefore if a system has a high cohesion then it is said to be better than if

it does not.

(Loh & Sai Peck Lee, 2009)

The current system that is being developed great precaution has been

taken to avoid such situation where a single components attempts to

achieve more than one objective. Also that as a whole the system works to

achieve a single objective.

Coupling

Coupling refers to how each module or component has been connected

with one another and how they interact with one another. How complex

the system is can be derived from how complex the connections are. The

general rule of thumb is that the more complex and higher coupling will

be more prone to errors and failures.

(Vanderfeesten et al., n.d.)

Several of the connections in the system being developed are of slightly

high coupling however most of the coupling has been kept at a minimum.

Cyclomatic complexity

Cyclomatic Complexity is related to the number of decision logic that the

software will contain. This measure is used for two main purposes and

thus makes it a vital aspect of the quality metric measures. The first aspect

75

that this measure is used for is to ascertain how many tests should be

carried out on the developed software. The other major purpose of this test

is to manage the software and to keep it reliable and manageable and

provide control to a system.

(Watson & McCabe, 1996)

Maintain the control of the system being developed was a challenge as the

system tends to go out of scope and out of proportion if not properly

managed. Great care was taken to minimize this from happening and to a

great extent this has been managed.

Depth of Conditional Nesting

This metric is charged with observing the depth to which the nesting of IF

conditions proceed. The more nested if condition there are within a single

if condition the greater the chance of error and the more likely the

programmer will miss a vital part of the nested condition.

To reduce this occurring great care has been taken to reduce the number of

nested conditions by replacing them where possible with switch cases to

minimize complexity and the possibility of errors occurring within the

system.

Fog Index

The fog index is used to focus on the readability of the code that has been

written for the system. One of the greatest problems faced after the initial

development of the system is that any programmer who comes on

afterwards to work on maintenance of the system will be unable to clearly

read and understand the program. Generally it is defined that the higher

the fog index the less readable the system becomes.

(Buse & Weimer, 2008)

The code for the system being developed was continuously checked to

ensure readability. This was achieved through using simple

understandable naming conventions with regards to classes and variables.

76

Also proper indentation of code was used so that in future reference to the

code it will be easy to locate segments of the code.

Source Lines of Code

This refers to number of lines of code that are written in the system.

Source lines of code are generally measured by two different styles and

are used to predict the effort and the productivity or cost of a system. The

two styles used are called physical and logical lines of code.

The physical lines of code count the lines of text in a program, while

logical lines of code attempt to measure the number of statements. This is

much harder as identifying the end of statements varies from programing

language to language.

(Anon., n.d.)

To ensure simplicity and minimize error due to over complexity of the

system great care has gone to ensure that the system lines of code are kept

to minimal and unwanted or waste lines of code are removed.

Number of Procedure Parameters

This, as clearly stated in the title of the metric is used to observer the

parameters passed around from function to function. The metric watches

to see how complex and how lengthy the parameters are. This is because

the longer and more complicated the parameters tend to become the more

likely the system is to run into errors during compilation and run time.

To avoid this great care was taken in ensuring that the system being built

kept the number of parameters at only what was essential and to keep the

parameters being passed simple.

Function Point Analysis

Function point analysis is rapidly becoming a highly favored metric of

choice among software engineers. The main reason behind this being that

function point analysis allows for a broader range of measure. It allows the

77

engineers to proceed with tasks like estimation, measuring quality and

gathering the requirements need for a proper functioning system.

The key to this analysis is that function point looks at the system from a

user perspective and assess if the system is meeting the requirements of

the user. This is vital for the success of any system by gauging the

productivity of the system.

(Heller , n.d.) (Longstreet , n.d.)

In application to the system being developed for Ceylon Telecom major effort

was utilized to ensure that the system will meet the final expectations of the user

and meet the users many functional requirements.

78

15.2 – TEST LOG

15.2.1 – LOGIN FORM

Test

Case

Test Description Expected Value

001 Press the “Submit” button with no

values in the “Username” and

“Password” fields.

Display error message “Please

Enter Username/Password”.

002 Enter correct password and

username and press the “Submit”

button.

Display “Login success”, close

“Login” form and open

“frmMainMenu” form.

003 Enter incorrect Username or

password and press the “Submit”

button.

Display Error message “Login

Failed”.

004 Press the “Clear” button. Clear all data in the “Username”

and “Password” fields.

79

15.2.2 – MAIN MENU FORM

Test

Case


005 Press the “New Call” button. Close “frmMainMenu” form and

open the “frmNewCall” form.

006 Press the “Add Solution” button. Close “frmMainMenu” form and

open the “fmAddSolution” form.

007 Press the “Add New Software”

button.

Close “frmMainMenu” form and

open the “frmAddNewSoftware”

form.

008 Press the “Add New Hardware”

button.


open the “frmAddNewHardware”

form.

009 Press the “Add New Operator”

button.


open the “frmAddNewSpecialist”

form.

010 Press the “EXIT” button. Close the application.

80

15.2.3 – NEW CALL FORM

Test

Case


011 Press the drop down icon in “Call

Type” field.

Display “New Call” and “Return

Call”.

012 Select call type as “Return Call”

option in the dropdown field.

Enable “Employee ID” field.

013 Select “Return Call”, enter

Employee ID and Call ID and press

“Submit” button.

Open “frmCallDetails” and Load

call details from “CallRecords”

Database where “CallID” equals

call ID given in the “Call ID”

field.

014 Select “Return Call”, enter

Employee ID and Call ID and press

“Submit” button.

Open “frmCallDetails” and close

“frmNewCall” form.

015 Enter invalid Call ID Display error message “Invalid

Call ID”.

016 Enter invalid Employee Display error message “Invalid

Employee ID”.

81

15.2.4 – NEW CALL DETAILS FORM

Test

Case


017 If Call type in “frmNewCall” equals

“Return Call” on form load.

Load call details from

“CallRecords” Database where

“CallID” equals call ID given in

the “Call ID” field.

018 If Call type in “frmNewCall” equals

“New Call” on form load.

Load form and fill “Problem ID”

with auto generated value. Load

Operator ID automatically from

login details. Load Employee ID

from value entered in

“frmNewCall”. Load Date and

time from system date and time.

019 Press the “Search Solution” Open form where list of

available solutions are

displayed.

020 Press the “Search Specialist” Open form where list of

available specialists are

displayed.

021 Press the “Search Hardware” Open form where list of

available hardware are

displayed.

82

022 Press the “Search Software” Open form where list of

available software are displayed.

023 Press “SAVE” button with all fields

filled.

Save records to “ProblemLog”

table.

024 Press “SAVE” button without filling

all details.

Display error message “Enter all

Required Details”.

025 Enter incorrect Specialist ID in

“Specialist ID” field.

Display error message “Invalid

Specialist ID”.

026 Enter incorrect Hardware ID in the

“Hardware ID” field.


Hardware ID”.

027 Enter incorrect software ID in the

“Software ID” field.

Display Error message “Invalid

Software ID”.

028 Select Problem status type as

“Solved”

Enable “txtProbSol” text box to

allow solution to be entered.

029 Press “CLEAR” button. Clear all enabled data fields.

15.2.5 – ADD SOLUTION FORM

Test

Case


030 Enter correct Problem ID and press

the “Submit” button.

Load all details from

“ProblemLog” table where

problem ID in text box equals

“ProbID” in “ProblemLog” table.

Open “frmEditSolution” form

and close current form.

031 Enter incorrect Problem ID and

press the “Submit” button.


Problem ID”.

83

15.2.6 – EDIT PROBLEM SOLUTION FORM

Test

Case


032 Form Load Load all problem details from

“ProblemLog” table where

Problem ID equal “ProbID” in

the “ProblemLog” table.

033 Select “Solved” problem status

combo box.

Enable “txtProbSol” text box.

034 Press “SAVE” button with all fields

filled.

Update records to “ProblemLog”

table where Problem ID in the

text box equals to “ProbID” in

the table.

035 Press “SAVE” button without filling

all details.



036 Enter incorrect Specialist ID in

“Specialist ID” field.


Specialist ID”.

037 Enter incorrect Hardware ID in the

“Hardware ID” field.


Hardware ID”.

038 Enter incorrect software ID in the

“Software ID” field.

Display Error message “Invalid

Software ID”.

039 Press “CLEAR” button. Clear all enabled data fields.

84

15.2.7 - ADD NEW SOFTWARE FORM

Test

Case


040 Form Load. Auto generate software ID and

display in the “txtSWID”. ID

generated should be one greater

than the number last recorded in

the system.

041 Press the “SAVE” button with

correct data entered.

Save record into “Software”

table.

042 Press the “Save” button with empty

fields.



043 Press the “Clear” button. Clear all the enabled fields.

85

15.2.8 - ADD NEW HARDWARE FORM

Test

Case



display in the “txtHWID”. ID



the system.



Save record into “Hardware”

table.


fields.




86

15.2.9 – ADD NEW OPERATOR FORM

Test

Case



display in the “txtOPID”. ID



the system.




table.


fields.




87

15.2.10 – ADD NEW OPERATOR FORM

Test

Case



display in the “txtSPID”. ID



the system.




table.


fields.




056 Press the “Department” dropdown

box.

Display list of all available

departments.

057 Press the “Specialty 1” dropdown

box.

Display list of all specialties in

the system.

058 Press the “Specialty 2” dropdown

box.

Display list of all specialties in

the system.

88

16.0 – BIBLIOGRAPHY

Alam, S.N., 2012. Waterfall Model Advantages and Disadvantages. [Online]

Available at: http://www.buzzle.com/articles/waterfall-model-advantages-and-

disadvantages.html [Accessed 13 May 2012].

Anon., 2002. Configuration Management Standards. [Online] Available at:

http://www.snuffybear.com/ucmcentral_standards.htm [Accessed 21 May 2012].

Anon., 2010. Software Quality Metrics. [Online] Available at:

http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics [Accessed 24

May 2012].

Anon., n.d. Project Code Meter. [Online] Available at:

http://www.projectcodemeter.com/cost_estimation/help/GL_sloc.htm [Accessed

23 May 2012].

Borysowich, C., 2007. Design Principles: Fan-In vs Fan-Out. [Online] Available

at: http://it.toolbox.com/blogs/enterprise-solutions/design-principles-fanin-vs-

fanout-16088 [Accessed 23 may 2012].

Buse, R. & Weimer, W., 2008. Slide Share. [Online] Available at:

http://www.slideshare.net/arrestedcomputing/a-metric-for-code-readability

[Accessed 23 May 2012].

Heller , , n.d. An Introduction to Function Point Analysis. [Online] Available at:

http://www.qpmg.com/fp-intro.htm [Accessed 24 May 2012].

http://www.freetutes.com, n.d. Prototyping Software Life Cycle Model. [Online]

Available at: http://www.freetutes.com/systemanalysis/sa2-prototyping-

model.html [Accessed 13 May 2012].

http://www.qsm.com, n.d. Function Point Languages Table. [Online] Available

at: http://www.qsm.com/resources/function-point-languages-table [Accessed 20

May 2012].

IT Acumens Discussion Zone, 2008. Advantages and Disadvantages of Spiral

Model. [Online] Available at:

http://discuss.itacumens.com/index.php?topic=33422.0 [Accessed 13 May 2012].

Loh, C.H. & Sai Peck Lee, 2009. Towards Cohesion-based Metrics as Early

Quality Indicators of. [Online] Available at: http://www.ipcsit.com/vol1/57-

S032.pdf [Accessed 23 May 2012 ].

Longstreet , , n.d. Fundamentals of FPA. [Online] Available at:

http://www.softwaremetrics.com/fpafund.htm [Accessed 24 May 2012].

http://www.buzzle.com/articles/waterfall-model-advantages-and-disadvantages.html

http://www.buzzle.com/articles/waterfall-model-advantages-and-disadvantages.html

http://www.snuffybear.com/ucmcentral_standards.htm

http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics

http://www.projectcodemeter.com/cost_estimation/help/GL_sloc.htm

http://it.toolbox.com/blogs/enterprise-solutions/design-principles-fanin-vs-fanout-16088

http://it.toolbox.com/blogs/enterprise-solutions/design-principles-fanin-vs-fanout-16088

http://www.slideshare.net/arrestedcomputing/a-metric-for-code-readability

http://www.qpmg.com/fp-intro.htm

http://www.freetutes.com/systemanalysis/sa2-prototyping-model.html

http://www.freetutes.com/systemanalysis/sa2-prototyping-model.html

http://www.qsm.com/resources/function-point-languages-table

http://discuss.itacumens.com/index.php?topic=33422.0

http://www.ipcsit.com/vol1/57-S032.pdf

http://www.ipcsit.com/vol1/57-S032.pdf

http://www.softwaremetrics.com/fpafund.htm

89

Margaret Rouse, 2007. waterfall model. [Online] Available at:

http://searchsoftwarequality.techtarget.com/definition/waterfall-model [Accessed

13 May 2012].

Thompson, B., 2008. Boehm’s Spiral Revisited. [Online] Available at:

http://leansoftwareengineering.com/2008/05/05/boehms-spiral-revisited/


University of Technology, n.d. Design Concepts and Principles. [Online]

Available at:

http://www.itswtech.org/Lec/Rand(SoftwareEng)/Software%20Engineering%20

%20%20%209.pdf [Accessed 15 May 2012].

Vanderfeesten, I. et al., n.d. Quality Metrics for Business Process Models.

[Online] Available at:

http://www.google.lk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CG

AQFjAD&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload

%3Fdoi%3D10.1.1.74.6133%26rep%3Drep1%26type%3Dpdf&ei=utfAT8jfKcL

PrQeJ1a3MCQ&usg=AFQjCNEn4RbUvEfGkUV4h5FwZFXylcOaaA&sig2=


Watson, A.H. & McCabe, T.J., 1996. Structured Testing: A Testing Methodology

Using the Cyclomatic Complexity Metric. [Online] Available at:

http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/chapter2.htm [Accessed 23

May 2012 ].

www.itu.edu.tr, n.d. Chapter 13 - Design Concepts and Principles. [Online]

Available at: http://web.itu.edu.tr/~gokmen/SE-lecture-6.pdf [Accessed 15 May

2012].

http://searchsoftwarequality.techtarget.com/definition/waterfall-model

http://leansoftwareengineering.com/2008/05/05/boehms-spiral-revisited/

http://www.itswtech.org/Lec/Rand(SoftwareEng)/Software%20Engineering%20%20%20%209.pdf

http://www.itswtech.org/Lec/Rand(SoftwareEng)/Software%20Engineering%20%20%20%209.pdf

http://www.google.lk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CGAQFjAD&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.74.6133%26rep%3Drep1%26type%3Dpdf&ei=utfAT8jfKcLPrQeJ1a3MCQ&usg=AFQjCNEn4RbUvEfGkUV4h5FwZFXylcOaaA&sig2=




http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/chapter2.htm

http://web.itu.edu.tr/~gokmen/SE-lecture-6.pdf

Documents

Principles and Practices of Software Production