You are on page 1of 97

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

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

WORKLOAD MATRIX
AHAMED Initiation Introduction Selection of Methodology Schedule Planning Project Planning Control Feasibility Study Cost Estimation Risk Management Requirements Analysis Requirement Analysis Problem Background Proposed Solution Logical Design Process Modeling Data Modeling Data Dictionary Design Principles and Concepts Architectural Design Physical Design Interactive Screen Design Report Design Build Programming Environment Development Test Testing Implementation Overall Documentation (Layout) TOTAL 100% 50% 50% 25% 25% 25% 25% 100% 100% 100% 100% DESHAN DILSHAN

100% 100%

50% 100% 100%

50%

30% 50% 25%

40% 50%

30% 50% 25% 100% 100%

40% 50%

30% 25%

30% 25%

80%

10%

10%

34%

33%

33%

ii

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

iii

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

iv

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

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

vi

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

vii

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.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 its 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 its too late to correct it or
2

the damage is permanent. This will add to additional costs to the company when it tries to rectify its errors.

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 specialists 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

4.0 PROJECT MANAGEMENT


4.1 SCHEDULE PLANNING
A3 PAGE HERE

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.

Parkinsons 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 customers 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.

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 Specify the user type, such as helpdesk operator, specialist. Object Screen Weightage 1

Module 10 Report Screen 1

The user provides the user name and password.

Module Report 2

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

Screen

is valid. If the login details are valid, system will allow the Module user to log in to the system. When a new call is made, information such as CallerID, Report Screen 2

ID of helpdesk operator and other vital information will be Module 10 saved in the Call Log for future references. The caller name will be checked against a register of all personnel to retrieve the caller's ID, job title, and department. The equipment will also be checked against a register of equipment to find the equipment type and make. Report Screen 2

Module Report Screen 2

Module Report Screen 2

The software will be checked to see if it is licensed software. 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. According to the problem details, help desk operator will give an appropriate problem type for it. At the same time
8

Module Report Screen 1

Module Report -

Screen

Module 10

the problem details will be saved in the Problem Log table. 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. 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. If the problem cannot be solved immediately the helpdesk operator will direct the problem to a specialist in order to get the solution. Once an unsolved problem is received, help desk operator will select an appropriate specialist to solve the problem.

Report

Screen

Module Report -

Screen

Module Report Screen 2

Module 10 Report Screen 1

Module Report Screen 2

The specialist will be selected by considering their specialized fields and the current workload they have. Once the specialist solves the problem, the problem solution will be provided to the caller, and at the same

Module Report Screen 2

Module -

time the resolved details will be saved in the solution table Report along with the problem number, date and time. Monthly and yearly the company administrative will get a report of all calls. 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 10 Report Screen 5 2

Module Report 5

TOTAL

90

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.)

10

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.

11

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 systems changes. It is for this purpose that change management is used, to manage and maintain the changes that are made to the system.

12

4.5 RISK MANAGEMENT


Risks Management of the Probability client High Effects Serious

organization not being cooperative with the developers. Inadequate or incompatible High Tolerable

hardware and/or software at the end user consoles. Skilled staff is not available at the High client organization to work on the system to gain full efficiency of the system. Staff tasked with developing the Low system fall sick in large numbers. Misunderstandings between team Low members. Inefficient code being done by Moderate developers System hardware or/and software Moderate gets corrupted and becomes Serious Catastrophic Serious Serious Tolerable

unusable. Proper system requirements are not Very High provided by the client. The client keeps changing the Very High requirements at different stages which will hinder the development process in the given timeline. The time allocated to complete a Very High task goes over the estimated time taken to complete it. Serious Serious Catastrophic

Project goes over the allocated Very High

Serious

13

budget. Expired or outdated tools being Very High used for development can cause inability to make use of new features available in tools. Tolerable

14

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.

15

(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.

16

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.

17

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 customers 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. Its 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.

18

5.5.1 ADVANTAGES OF WATERFALL METHODOLOGY


1. 2. 3. 4.

Its easy to implement because its a linear model. Minimal amount of resources are required to implement this model. End of every stage, documentation is produced. 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)

19

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.

20

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% wont 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.
21

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
22

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 specialists 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.

23

6.0 DATA FLOW DIAGRAMS


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


7.1 DATA STORES
Name Description Employee Records 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. Employee ID Employee Details Employee Records= EmpID+ EmpName+ EmpDept+ EmpJob+ EmpEmail

Input Data Flows Output Data Flows Data Structure

Name Description

Input Data Flows Output Data Flows Data Structure

Caller Record 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. Caller ID and Problem Number N/A Caller Record= CallerID+ CallerName+ CallDate+ CallTime+ EmpID+ CallType+ CallerRecStatus

Name Description

Computer Hardware and Software Records. This data store will take note of the faulty equipment and/or
29

Input Data Flows Output Data Flows Data Structure

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. Equipment Details N/A Computer Hardware and Software Records= HWType+ HWSerialNumber+ HWName+ HWDescription+ HWRecStatus + SWName+ SWDescription+ SWStatus+ SWRecStatus

Name Description

Input Data Flows

Output Data Flows Data Structure

Problem Log 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. Problem Details Problem Details Updated Problem Details Problem Solution Details Problem Type Problem Solution Problem Log= ProbID+ ProbDescription+ ProbType+ ProdStatus+ ProbSolution+ SWID+ SplID+ HWID+ ProbRecStatus

30

Name Description

Input Data Flows Output Data Flows Data Structure

Specialist Details 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. Updated Specialist Work Log Updated Specialist Work Log Specialist Details Specialist Details= SplID+ SplName+ SplTel+ SplDept+ SplSpecialities+ SplEmail+ SplRecStatus+

31

7.2 DATA FLOWS


Name Description Employee ID and Equipment Details This flow will take key details from the caller so that the system can process who is calling and what equipment is faulty. Caller External Entity 1.1 Search Employee Details Process Employee ID and Equipment Details=EmpID+ HWType+ HWSerialNumber+ HWName+ HWDescription+ HWRecStatus+ SWName+ SWDescription+ SWStatus+ SWRecStatus

Origin/Source Destination Data Structure

Name Description

Origin/Source Destination Data Structure

Employee ID Carries the Employee ID to the database so that the details of the employee matching the ID can be extracted from the database. 1.1 Search Employee Details Process Employee Records Data Store Employee ID= EmpID

Name Description Origin/Source Destination Data Structure

Employee Details Returns the details of the employee searched to the process so it can be displayed on the system. Employee Records Data Store 1.1 Search Employee Details Process Employee Details = EmpID+ EmpName+ EmpDept+ EmpJob+ EmpEmail

Name Description

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


32

Origin/Source Destination Data Structure

records of the call and the equipment can be saved with the details of the employee. 1.1 Search Employee Details Process 1.2 Record Call Details Employee ID= EmpID

Name Description Origin/Source Destination Data Structure

Problem Number The process will provide the caller with a problem number that is associated with the problem that he has called regarding. 1.2 Record Call Details Process Caller External Entity Problem Number= ProbID

Name Description Origin/Source Destination Data Structure

Caller Details and Problem Number This flow will take the call details such as time of call and the duration to be written into the Call Record data store. 1.2 Record Call Details Process Caller Record Data store Caller Details and Problem Number= CallerID+ ProbID+ CallerName+ OperatorID+ CallDate+ CallTime+ EmpID+ CallType+ CallRecStatus

Name Description Origin/Source Destination Data Structure

Equipment Details Takes the details of the equipment or software that is causing a problem and writes it to the database. 1.2 Record Call Details Process Computer Hardware and Software Records Data Store Equipment Details= HWType+ HWSerialNumber+ HWName+ HWDescription+
33

HWRecStatus + SWName+ SWDescription+ SWStatus+ SWRecStatus

Name Description

Origin/Source Destination Data Structure

Problem Details Carries the details of problem key words to the database so that the database can be searched and all matching problems be displayed. 2.1 Search Problem Record Process Problem Log Data store Problem Details= ProbType

Name Description Origin/Source Destination Data Structure

Problem Details Takes the details of the new problem so that they can be written into the Problem Log data store. 2.2 Record Problem Details Process Problem Log Data Store Problem Details= ProbID+ ProbDescription+ ProbType+ ProdStatus+ ProbSolution+ SWID+ SplID+ HWID+ ProbRecStatus

Name Description

Origin/Source Destination Data Structure

New Problem Details Provides the system with new information regarding an existing problem. This information will be given written into the system adding to the existing information. Caller External Entity 2.2 Record Problem Details Process New Problem Details= ProbID+ ProbDescription+ ProbType+
34

Name Description Origin/Source Destination Data Structure

Updated Problem Details Sends the information required to be written to the system database. 2.2 Record Problem Details Process Problem Log Data Store Updated Problem Details= ProbID+ ProbDescription+ ProbType+

Name Description Origin/Source Destination Data Structure

Problem Type Provides the process with a list of problem types to select from in order to select a specialist. Problem Log Data Store 3.1 Select Problem Type Process Problem Type= ProbType

Name Description Origin/Source Destination Data Structure

Selected Problem Type This is the problem type that the operator of the system has selected from the list that is available. Operator External Entity 3.1 Select Problem Type Process Selected Problem Type= ProbType

Name Description Origin/Source Destination Data Structure

Problem Type This is the problem type that the operator of the system has selected from the list that is available. 3.1 Select Problem Type Process 3.2 Search and Display Solution Process Selected Problem Type= ProbType

Name Description

Problem Solution The information that is being sent here are the solutions, if available, regarding the problem type that the operator has
35

Origin/Source Destination Data Structure

selected. Problem Log Data Store 3.2 Search and Display Solution Process Problem Solution= ProbID+ ProbSolution

Name Description Origin/Source Destination Data Structure

Problem Solution Provide the caller with the solution for the problem selected if it is available in the system. 3.2 Search and Display Solution Process Caller External Entity Problem Solution= ProbID+ ProbSolution

Name Description Origin/Source Destination Data Structure

Update Specialist Work Log Sends the new work load details to the system so that it can update the specialist work log. 5 Problem Solution Management Process Specialist Details Data Store Update Specialist Work Log= SplID+ SplWorkLoad

Name Description

Origin/Source Destination Data Structure

Solved Log Details 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. Specialist External Entity 5 Problem Solution Management Process Solved Log Detail= ProbID+ ProbSolution

Name Description Origin/Source Destination

Problem Solution Details This flow carries the information to the database to be written into the problem log database. 5 Problem Solution Management Process Problem Log Data Store
36

Data Structure

Problem Solution Details ProbID+ ProbSolution

Name Description

Origin/Source Destination Data Structure

Specialist Details Provides the process with information of the specialist available for a particular problem type so that the process can allocate a specialist. Specialist Details Data Store 4 Allocate Specialist Process Specialist Details= SplID+ SplName+ SplDpt+ SplSpecialities+ SplWorkLoad

Name Description

Origin/Source Destination Data Structure

Problem Details 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. 4 Allocate Specialist Process Specialist External Entity Problem Details= ProbID+ ProbDescription+ ProbType+ ProdStatus+ ProbSolution+ SWID+ SplID+ HWID+ ProbRecStatus

Name Description Origin/Source Destination Data Structure

Updated Specialist Work Log Updates the specialists work log to include the current task that is being handled by the specialist. 4 Allocate Specialist Process Specialist Details Data Store Update Specialist Work Log= SplID+
37

SplWorkLoad

Name Description

Origin/Source Destination Data Structure

Problem Details Provides the specialist allocation process with information regarding the problem so that the process is able to select the correct specialist for the task. 3 Classifying New Problem Process 4 Allocate Specialist Process Problem Details= ProbID+ ProbDescription+ ProbType

Name Description Origin/Source Destination Data Structure

Problem Details Provides the problem details supplied by the caller to help identify the type of problem at hand. 2 Record New Problem Process 3 Classifying New Problem Process Problem Details= ProbID+ ProbDescription+ ProbType+ ProdStatus+ ProbSolution+ SWID+ SplID+ HWID+ ProbRecStatus

Name Description Origin/Source Destination Data Structure

Problem Details Provides the problem details supplied by the caller so that it can be recorded in the system. 1 New Call Process 2 Record New Problem Process Problem Details= ProbID+ ProbDescription+ ProbType+ ProdStatus+ ProbSolution+ SWID+
38

SplID+ HWID+ ProbRecStatus

39

7.3 EXTERNAL ENTITIES


Name Description Caller 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. Data Problem Number Problem Solution Data Employee ID and Equipment Details New Product Details

Input Flows Output Flows

Name Description

Input Flows Output Flows

Operator 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. Data N/A Data Selected Problem Type

Name Description

Input Flows Output Flows

Specialist 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. Data Problem Details Data Solved Log Details

40

7.4 PROCESSES
Name Description 1.1 Search Employee details This process will be used to identify and extract the callers details from the system database using the caller ID. This information once extracted will be sent to the Record Call Details Process. Employee ID and Equipment Details Employee Details Employee ID Employee ID 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

Input Data Flows Output Data Flows Process Description

Name Description Input Data Flows Output Data Flows Process Description

1.2 Record Call Details This process will write to the database the details of the call and the details of the faulty equipment to the system records. Employee ID Caller Details and Problem Number Equipment Details Problem Number BEGIN GET Employee ID from 1.1 Search Employee Details Process WRITE Caller Details and problem Number to Caller Record Database
41

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 Description

Input Data Flows Output Data Flows Process Description

2.1 Search Problem Records 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. N/A Problem Details

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 Description

Input Data Flows Output Data Flows Process Description

2.2 Record Problem Details This process will be used to write to the system a new problem details or update an existing problem with new information. New Problem Details Problem Details Updated Problem Details BEGIN GET Problem Type from 2.1 Search Problem Records Process IF Problem Type EQUALS TRUE UPDATE Problem Log with New Problem Details ELSE
42

WRITE New Problem Details to Problem Log Database END IF END

Name Description Input Data Flows Output Data Flows Process Description

3.1 Select Problem Type Process This process will be used to present the help desk operator with the types of problems that are available in the system. Select Problem Type Process Problem Type N/A 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 Description

Input Data Flows Output Data Flows Process Description

3.2 Search and Display Solution Process 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. Problem Solution Problem Type Problem Solution 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

43

Name Description

Input Data Flows Output Data Flows Process Description

4.0 Allocate Specialist Process 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. Problem Details Specialist Details Problem Details Updated Specialist Work Log 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 UPDATE Specialist Work Log END IF END

Name Description

Input Data Flows Output Data Flows Process Description

5 Problem Solution Management Process 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. Solved Log Details
BEGIN READ Solved Log Details WRITE Solution to Problem Log database UPDATE Specialist Work Log END

Problem Solution Details Updated Specialist Work Log

44

8.0 - ENTITY RELATIONSHIP DIAGRAM

45

9.0 ENTITY LIFE HISTORY


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


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 shouldnt suffer from Tunnel Vision. Design process shouldnt 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
52

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. Its 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.

53

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 dont 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.)

54

11.0 ARCHITECTURAL DESIGN


11.1 WHAT IS ARCHITECTURAL DESIGN?
Its 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. Its the system preliminary logical structure stage. The diagram bellow gives a brief idea about this.

Paste diagram in here..

55

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


Solution Recording

Specialist Allocation

Help Desk Solution

Problem Search

Allocate Specialis t

Rectify Solution

Problem log

Call Recording

56

New caller

Caller details

Technical fault

Help Desk Solution

Problem Searching

Diagnose

Record Problem

New Problem

Update Problem

Help Desk Solution

Solution Recording

Update Solution

Prepare Reports

57

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.

58

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.

59

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. The clear button clears all the text fields.

60

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. The clear button clears all the text fields.

61

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. The clear button clears all the text fields.

62

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. The clear button clears all the text fields.

63

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.

64

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. The clear button clears all the text fields.

65

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.

66

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.

67

13.0 REPORT DESIGNS


13.1 PROBLEM REPORT

68

13.2 SPECIALIST PROBLEMS SUMMARY

69

13.3 UNSOLVED PROBLEMS REPORT

70

13.4 OPERATOR PROBLEMS SUMMARY REPORT

71

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 clients 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.

72

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.
73

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 noncohesive 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
74

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.


75

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

76

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.

77

15.2 TEST LOG 15.2.1 LOGIN FORM

Test Case 001

Test Description Press the Submit button with no values in the Username and Password fields. Enter correct password and username and press the Submit button. Enter incorrect Username or password and press the Submit button. Press the Clear button.

Expected Value Display error message Please Enter Username/Password. Display Login success, close Login form and open frmMainMenu form. Display Error message Login Failed. Clear all data in the Username and Password fields.

002

003

004

78

15.2.2 MAIN MENU FORM

Test Case 005 006 007

Test Description Press the New Call button.

Expected Value

008

009

010

Close frmMainMenu form and open the frmNewCall form. Press the Add Solution button. Close frmMainMenu form and open the fmAddSolution form. Press the Add New Software Close frmMainMenu form and button. open the frmAddNewSoftware form. Press the Add New Hardware Close frmMainMenu form and button. open the frmAddNewHardware form. Press the Add New Operator Close frmMainMenu form and button. open the frmAddNewSpecialist form. Press the EXIT button. Close the application.

79

15.2.3 NEW CALL FORM

Test Case 011 012 013

Test Description Press the drop down icon in Call Type field. Select call type as Return Call option in the dropdown field. Select Return Call, enter Employee ID and Call ID and press Submit button.

Expected Value Display New Call and Return Call. Enable Employee ID field.

014

015 016

Open frmCallDetails and Load call details from CallRecords Database where CallID equals call ID given in the Call ID field. Select Return Call, enter Open frmCallDetails and close Employee ID and Call ID and press frmNewCall form. Submit button. Enter invalid Call ID Display error message Invalid Call ID. Enter invalid Employee Display error message Invalid Employee ID.

80

15.2.4 NEW CALL DETAILS FORM

Test Case 017

Test Description

Expected Value

018

019

020

021

If Call type in frmNewCall equals Load call details from Return Call on form load. CallRecords Database where CallID equals call ID given in the Call ID field. If Call type in frmNewCall equals Load form and fill Problem ID New Call on form load. 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. Press the Search Solution Open form where list of available solutions are displayed. Press the Search Specialist Open form where list of available specialists are displayed. Press the Search Hardware Open form where list of available hardware are displayed.
81

022 023 024 025 026 027 028 029

Press the Search Software Press SAVE button with all fields filled. Press SAVE button without filling all details. Enter incorrect Specialist ID in Specialist ID field. Enter incorrect Hardware ID in the Hardware ID field. Enter incorrect software ID in the Software ID field. Select Problem status type as Solved Press CLEAR button.

Open form where list of available software are displayed. Save records to ProblemLog table. Display error message Enter all Required Details. Display error message Invalid Specialist ID. Display error message Invalid Hardware ID. Display Error message Invalid Software ID. Enable txtProbSol text box to allow solution to be entered. Clear all enabled data fields.

15.2.5 ADD SOLUTION FORM

Test Case 030

Test Description

Expected Value

031

Enter correct Problem ID and press Load all details from the Submit button. ProblemLog table where problem ID in text box equals ProbID in ProblemLog table. Open frmEditSolution form and close current form. Enter incorrect Problem ID and Display error message Invalid press the Submit button. Problem ID.

82

15.2.6 EDIT PROBLEM SOLUTION FORM

Test Case 032

Test Description Form Load

Expected Value

033 034

035 036 037 038 039

Load all problem details from ProblemLog table where Problem ID equal ProbID in the ProblemLog table. Select Solved problem status Enable txtProbSol text box. combo box. Press SAVE button with all fields Update records to ProblemLog filled. table where Problem ID in the text box equals to ProbID in the table. Press SAVE button without filling Display error message Enter all all details. Required Details. Enter incorrect Specialist ID in Display error message Invalid Specialist ID field. Specialist ID. Enter incorrect Hardware ID in the Display error message Invalid Hardware ID field. Hardware ID. Enter incorrect software ID in the Display Error message Invalid Software ID field. Software ID. Press CLEAR button. Clear all enabled data fields.

83

15.2.7 - ADD NEW SOFTWARE FORM

Test Case 040

Test Description Form Load.

Expected Value

041 042 043

Auto generate software ID and display in the txtSWID. ID generated should be one greater than the number last recorded in the system. Press the SAVE button with Save record into Software correct data entered. table. Press the Save button with empty Display error message Enter all fields. Required Details. Press the Clear button. Clear all the enabled fields.

84

15.2.8 - ADD NEW HARDWARE FORM

Test Case 044

Test Description Form Load.

Expected Value

045 046 047

Auto generate software ID and display in the txtHWID. ID generated should be one greater than the number last recorded in the system. Press the SAVE button with Save record into Hardware correct data entered. table. Press the Save button with empty Display error message Enter all fields. Required Details. Press the Clear button. Clear all the enabled fields.

85

15.2.9 ADD NEW OPERATOR FORM

Test Case 048

Test Description Form Load.

Expected Value

049 050 051

Auto generate software ID and display in the txtOPID. ID generated should be one greater than the number last recorded in the system. Press the SAVE button with Save record into Hardware correct data entered. table. Press the Save button with empty Display error message Enter all fields. Required Details. Press the Clear button. Clear all the enabled fields.

86

15.2.10 ADD NEW OPERATOR FORM

Test Case 052

Test Description Form Load.

Expected Value Auto generate software ID and display in the txtSPID. ID generated should be one greater than the number last recorded in the system. Save record into Hardware table. Display error message Enter all Required Details. Clear all the enabled fields. Display list of all available departments. Display list of all specialties in the system. Display list of all specialties in the system.

053 054 055 056 057 058

Press the SAVE button with correct data entered. Press the Save button with empty fields. Press the Clear button. Press the Department dropdown box. Press the Specialty 1 dropdown box. Press the Specialty 2 dropdown box.

87

16.0 BIBLIOGRAPHY
Alam, S.N., 2012. Waterfall Model Advantages and Disadvantages. [Online] Available at: http://www.buzzle.com/articles/waterfall-model-advantages-anddisadvantages.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-vsfanout-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-prototypingmodel.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/57S032.pdf [Accessed 23 May 2012 ]. Longstreet , , n.d. Fundamentals of FPA. [Online] Available at: http://www.softwaremetrics.com/fpafund.htm [Accessed 24 May 2012].

88

Margaret Rouse, 2007. waterfall model. [Online] Available at: http://searchsoftwarequality.techtarget.com/definition/waterfall-model [Accessed 13 May 2012]. Thompson, B., 2008. Boehms Spiral Revisited. [Online] Available at: http://leansoftwareengineering.com/2008/05/05/boehms-spiral-revisited/ [Accessed 13 May 2012]. 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= [Accessed 23 May 2012]. 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].

89

You might also like