PROJECT REPORTONPAYROLL MANAGEMENT SYSTEMUNDER SUPERVISION OF:SUBMITTED BYNAME:ENROLLMENT NO:Submitted in partial fulfillment for the award of the Degree ofO Level1

ACKNOWLEDGEMENTWith Candor and Pleasure I take opportunity to express my sincere thanks and obligation to my esteemed guide.. It is because of his able and mature guidance and co-operation without which it would not have been possible for me to complete my project.It is my pleasant duty to thank all the staff member of the computer center who never hesitated me from time during the project.Finally, I gratefully acknowledge the support, encouragement & patience of my family, And as always, nothing in my life would be possible without God, Thank You!2

TABLE OF CONTENT1. System Study

1.1.Introduction6

1.2.Feasibility Study9

1.3.System Overview21

2. System Analysis

2.1.Importance of Computerized23

PAYROLL MANAGMENT System

2.2.Functional Requirements30

3. System Design

3.1.System Development Cycle34

3.2.Context Level DFD35

3.3.System Design42

4. Source Code

4.1. Input output Design 48

4.2.Source Code5352

5.Testing

5.1.Testing Phases93

5.2.Verification & Validation127

6.System Implementation

6.1Hardware Evaluation Factors129

6.2Conversation And Training131

3

6.3Training Needs1337. Post Implementation Maintenance and Review134

8. Users Manual

8.1.Operational instruction for the User138

8.2.Installation Procedure139

9. Bibliography141

4

1. SYSTEM STUDY1.1 INTRODUCTION TO THE PROBLEM:This is a Project work undertaken in context of partial fulfillment of the BIT. Since PAYROLL is associated with the lives of common people and their day to day routines so I decided to work on this project. The manual handling of the record is time consuming and highly prone to error. The user can inputs codes of

Employee he wants to see Pay Slip. The activities like see Employee Record , add Record, modify records, delete Record and finally receiving Pay Slip can be performed easily. .

I found two main key-points to design and programmed my project using TURBO C++ and its FILES facility as database storage. First, Because TURBO C++ compiler has the ability to debug the project at run time and gives appropriate error messages if it found in the project at run time. Its help is too enough to learn and study any function of a particular header file using the keyboard Keys (Ctrl + F1) to keep the cursor on that particular function. Second.

I have tried my best to make the complicated process of PAYROLL MANAGEMENT System as simple as possible using Structured & Modular technique & Menu oriented interface. I have tried to design the software in such a way that user may not have any difficulty in using this package & further expansion is possible without much effort. Even though I cannot claim that this work to be entirely exhaustive, the main purpose of my exercise is perform each PayRolls activity in computerized way rather than manually which is time consuming.

I am confident that this software package can be readily used by non-programming personal avoiding human handled chance of error.

5

NEED:I have designed the given proposed system in the C++ to automate the process of Payroll system.

The complete set of rules & procedures related to PayRoll and generating report is called

PAYROLL MANAGEMENT SYSTEM. My project gives a brief idea regarding automated Payroll activities.

The following steps that gives the detailed information of the need of proposed system are:

Performance: During past several decades, the Payroll is supposed to maintain manual handling of all the Payroll activities. The manual handling of the record is time consuming and highly prone to error. To improve the performance of the payroll system, the computerized payroll system is to be undertaken. The computerized project is fully computerized and user friendly even that any of the members can see the report and status of the pay.

Efficiency: The basic need of the project is accuracy and efficiency . The project should be efficient so that whenever a Employee is added,add his Record , delete his record, display and generate his payslip.

Control: The complete control of the project is under the hands of authorized person who has the password to access this project and illegal access is not supposed to deal with. All the control is under the administrator and the other members have the rights to just see the records not to change any transaction or entry.

6

Security: Security is the main criteria for the proposed system. Since illegal access may corrupt the database. So security has to be given in this project.

Software: Software includes the platform where the Payroll project is being prepared. I have done my project using DOS based Compiler TURBO C++ platform and the database is the FILE HANDLING MECHANISM OF TURBO C++. But it is not necessary that we have to first install Turbo C++ to run this project.

7

OBJECTIVEDuring the past several decades personnel function has been transformed from a relatively obscure record keeping staff to central and top level management function. There are many factors that have influenced this transformation like technological advances, professionalism, and general recognition of human beings as most important resources.

A computer based management system is designed to handle all the primary information required to calculate monthly statements of Employees Record which include monthly statement of any month. Separate database is maintained to handle all the details required for the correct statement calculation and generation.

This project intends to introduce more user friendliness in the various activities such as record updation, maintenance, and searching. The searching of record has been made quite simple as all the details of the Employee can be obtained by simply keying in the identification of that Employee. Similarly, record maintenance and updation can also be accomplished by using the identification of Employee with all the details being automatically generated. These details are also being promptly automatically updated in the master file thus keeping the record absolutely up-to-date.

The entire information has maintained in the database or Files and whoever wants to retrieve cant retrieve, only authorization user can retrieve the necessary information which can be easily be accessible from the file.

The main objective of the entire activity is to automate the process of day to day activities of pay.

8

1.2 FEASIBILITY STUDYThe feasibility study proposes one or more conceptual solution to the problem set of the project. In fact, it is an evaluation of whether it is worthwhile to proceed with project or not.

Feasibility analysis usually considers a number of project alternatives, one that is chosen as the most satisfactory solution. These alternatives also need to be evaluated in a broad way without committing too many resources. Various steps involved in feasibility analysis are:

1. To propose a set of solution that can realize the project goal. These solutions are usually descriptions of what the new system should look like.

2. Evaluation of feasibility of such solutions. Such evaluation often indicates shortcomings in the initial goals. This step is repeated as the goals are adjusted and the alternative solutions are evaluated.

Four primary areas of interest in feasibility study are:

Economic Feasibility: An evaluation of development cost weighed against

the ultimate income of benefit derived from the development system of product. In economic feasibility, cost benefit analysis is done in which expected cost and benefits are

evaluated.9

COST AND BENEFIT ANALYSISDeveloping an IT application is an investment. Since after developing that application it provides the organization with profits. Profits can be monetary or in the form of an improved working environment. However, it carries risks, because in some cases an estimate can be wrong. And the project might not actually turn out to be beneficial.

Cost benefit analysis helps to give management a picture of the cost, benefits and risks. It usually involves comparing alternate investments.

Cost benefit determines the benefits and savings that are expected from the system and compares them with the expected costs.

In performing cost and benefit analysis it is important to identify cost and benefits factors. Cost and benefits can be categorized into the following categories:

1. Development Costs Development costs is the costs that are incurred during the development of the system. It is one time investment.

2. Operating Costs Operating Costs are the expenses required for the day to day running of the system. Examples of Operating Costs are Wages, Supplies and Overheads.

3. Hardware/Software Costs It includes the cost of purchasing or leasing of computers and its peripherals. Software costs involves required S/W costs.

4. Personnel Costs It is the money spent on the people involved in the development of the system.

5. Facility Costs Expenses that are incurred during the preparation of the physical site where the system will be operational. These can be wiring, flooring, acoustics, lightning, and air-conditioning.

6. Supply Costs These are variable costs that are very proportionately with the amount of use of paper, ribbons, disks, and the like.

10

BENEFITSWe can define benefits asProfit or Benefit = Income CostsBenefits can be accrued by:

Increasing income, or Decreasing costs, or Both Technical Feasibility:Technical Feasibility includes existing and new H/W and S/W requirements that are required to operate the project on the platform Turbo C++. The basic S/W requirement is TURBO C++ in which the front end of the Payroll management project has been done. The basic entry forms are developed in TURBO C++ and the data is stored in the FILES.

Feasibility:Operational feasibility is mainly concerned with issues like whether the system will be used if it is developed and implemented. Whether there will be resistance from users that will effect the possible application benefits? The essential questions that help in testing the technical feasibility of a system are following:

Does management support the project? Are the users not happy with current business practices? Will it reduce the time considerably? If yes, then they will welcome the change and the new system. Have the users involved in the planning and development of the project? Early involvement reduced the probability of resistance towards the new system. Will the proposed system really benefit the organization? Does the overall response increase? Will accessibility of information be lost? Will the system effect the customers in considerable way? 11

Legal Feasibility:A determination of any infringement, violation, or liability that could result from development of the system. Legal feasibility tells that the software used in the project should be original purchased from the legal authorities and they have the license to use it or the software are pirated.

Alternatives:An evaluation of alternative approaches to the development of system or product.

Cost and Benefit Analysis of Payroll Management SystemCosts:CostCost per unitQuantityCost

Software

Turbo C++3,00013,000

Windows NT Server30,000130,000

Windows 9815,000115,000

Hardware4,00028,000

Central Computer100,00011,00,000

Client Machine50,00042,00,000

Development

Analyst50,000150,000

Developer20,000240,000

Training20,000120,000

Data Entry5,000015,000

Warranty (1 month)

Professional20,000120,000

TOTAL COST4,91,000

According to the Payroll System, Rs. 250 pay for a day of a single employee .

12

Expected increase in the number of Employee: 40 per month and number of customer for local is: 150 per day.

Let the amount collected from operations in a month: 250,000 for a month.

Amount collected from the Employee when he returns car this year =12*(40 * (250 + 450) + 150 * 30 * 30 + 250000)

=Rs. 49,56,000

For three years = 3 * 4956,000

= Rs. 1,48,68,000

Now using Net Present Value Method for cost benefit analysis we have, Net Present Value (origin) = Benefits Costs

=14868000-491000 =Rs. 14377000

gain % = Net Present Value / Investment =14377000/491000 =29.28%

Overall gain = 2928% in five year

For each year1st year:Investment = 491,000

Benefit = 49,56,000

Net Present Value for first year = 4956000-491000 =4965000

gain%=4965000/491000 =909.36% in first year

13

2nd year:Investment = 491,000

Benefit = 10412,000

Net Present Value for first year = 10412000-491000 =9921000

gain%=9921000/491000 =2020.57% at the end of second year

3rd year:Investment = 491,000

Benefit = 15859000

Net Present Value for first year = 15859000-491000 =15368000

gain%=15368000/491000 =3129.93% at the end of third year

From cost and benefit analysis we have found that the project is economically feasible since it is showing great gains (approx. above 3000%).

After economic feasibility, technical feasibility is done. In this, major issue is to see if the system is developed what is the likelihood that itll be implemented and put to operation?

Will there be any resistance from its user?

It is clear that the new automated system will work more efficiently and faster. So the users will certainly accept it. Also they are being actively involved in the development of the new system. So our system is operationally feasible.

14

After the feasibility study has been done and it is found to be feasible, the management has approved this project.

FACT FINDING TECHNIQUESThe functioning of the system is to be understood by the system analyst to design the proposed system. Various methods are used for this and these are known as fact-finding techniques. The analyst needs to fully understand the current system.

The analyst needs data about the requirements and demands of the project undertaken and the techniques employed to gather this data are known as fact-finding techniques. Various kinds of techniques and the most popular among them are interviews, questionnaires, record views, case tools and also the personal observations made by the analyst himself.

InterviewsInterview is a very important data gathering technique as in this the analystdirectly contacts system and the potential user of the proposed system.One very essential aspect of conducting the interview is that the interviewer should first establish a rapport with the interviewee. It should also be taken into account that the interviewee may or may not be a technician and the analyst should prefer to use day to day language instead of jargon and technical terms.

The advantage of the interview is that the analyst has a free hand and the he can extract almost all the information from the concerned people but then as it is a very time consuming method, he should also employ other means such as questionnaires, record reviews, etc. This may also help the analyst to verify and validate the information gained. Interviewing should be approached, as logically and from a general point of view the following guides can be very beneficial for a successful interview:

15

1. Set the stage for the interview.

2. Establish rapport; put the interview at ease.

3. Phrase questions clearly and succinctly.

4. Be a good listener; a void arguments.

5. Evaluate the outcome of the interview.

The interviews are of the two types namely structured and unstructured.

I . Structured InterviewStructured interviews are those where the interviewee is asked a standard set of questions in a particular order. All interviews are asked the same set of questions. The questions are further divided into two kinds of formats for conducting this type if interview.

II. Unstructured Interviewanswer format. This is of a much more flexible nature than the structured and The unstructured interviews are undertaken in a question-and-can be very rightly used to gather general in formation about the system.

Questionnaires:

Questionnaires are another way of information gathering where the potential users of the system are given questionnaires to be filled up and returned to the analyst.

Questionnaires are useful when the analyst need to gather information from a large number of people. It is not possible to interview each individual. Also if the time is very short, in that case also questionnaires are useful. If the analyst guarantees the anonymity of the respondent then the respondent answers the questionnaires very honestly and critically.

The analyst should sensibly design and frame questionnaires with clarity of its objective so as to do just to the cost incurred on their development and distribution.

16

Record Reviews

Records and reports are the collection of information and data accumulated over the time by the users about the system and its operations. This can also put light on the requirements of the system and the modifications it has undergone. Records and reports may have a limitation if they are not up-to-date or if some essential links are missing. All the changes, which the system suffers, may not be recorded. The analyst may scrutinize the records either at the beginning of his study which may give him a fair introduction about the system and will make him familiar with it or in the end which will provide the analyst with a comparison between what exactly is/was desired from the system and its current working.

On-Site Observation

On-site observations are one of the most effectively tools with the analyst where the analyst personally goes to the site and discovers the functioning of the system. As a observer, the analyst can gain first hand knowledge of the activities, operations, processes of the system on-site, hence here the role of an analyst is of an information seeker. This information is very meaningful as it is unbiased and has been directly taken by the analyst. This exposure also sheds some light on the actual happenings of the system as compared to what has already been documented, thus the analyst gets closer to system. This technique is also time-consuming and the analyst should not jump to conclusions or draw inferences from small samples of observation rather the analyst should be more.

17

ANALYSTS INTERVIEW WITH ADMINISTRATORAnalyst:Hi, I have come to talk to you regarding the functioning of your payroll project.Administrator:hello, do come in. I was expecting you.Analyst:Ill come straight to the point. Dont hesitate, you can be as much open you want. There are no restrictions.Administrator:Ill give you my whole contribution.Analyst:Tell me are you excited about the idea of having an automated system for your Payroll system?Administrator:Yes, I do. Very much. After all its gonna reduce our loads of work.Analyst:Will you elaborate on it?Administrator:Major problem is managing the record of the Employee , Display the record, Delete the record . At the time of payroll, it becomes more difficult to handle the report of payslip.Analyst:What do you think be ideal solution to this?Administrator:All the information of Employee should be put into computer.Itll be easy for us to check how many record are avilable or not available of employee.Analyst:Could you explain how?Administrator:Look whenever a new Employee is come he/she is allotted a any Id or Code and the is reserved for the till the employee gets leave his job.Analyst: Do you have different Employee categories? Administrator: yes we have categorization for Employee .Analyst:How do you categorize your Employee?Administrator:By ID no. and by name both.Analyst:Do you have any other expectations or suggestion for the new system?Administrator:It should be able to produce reports faster.Analyst:Reports? I completely forgot about them. What reports you people produce presently?18

Administrator:Well first is for Employee record another for Employees list .Analyst:Do you have some format for them?Administrator:Yes we do have and we want that the same format be used bythe new system.Analyst:Yes well take care of that. Any other suggestions?Administrator:No. You have already covered all the fields.Analyst:Thanks for your co-operation. It was nice talking to you.Administrator:My pleasure. Bye.19

QUESTIONNAIRES FOR STAFFInstructions: Answer as specified by the format. Put NA for non-application situation.

1. What are your expectations out of the new system (computerized)? Rate the following on a scale of 1-4 giving allow value for low priority.

(a) better cataloguing

(b) better managing of users

(c) better account and patients management

(d) computer awareness

(e) any other________________

2. How many users are you expecting?

____________________________

3. How many Employee are there ?

____________________________

4. How you want the Employee to be categorized for searching (like by id no., by name)?

____________________________

5. Is there any difference in the roles (privileges) of two or more Employee? Yes/No Please specify if Yes

_____________________________________________________________________

___________________________

6. Do you want facility of generating the payslip? Yes/No

7. Do you have data of Employee entered into some kind of database? Yes/No

8. How do you want users to be categorized?

_______________________or

_______________________

9. Would you like online registration for users rather than the printed form? Yes/No

10. Do you already have some existing categorization of Employee on the basis as specified in question 4 above?

Yes/No

20

11. Any other specific suggestion/expectation out of the proposed system.

_____________________________________________________________________

_______________________________

1.3 SYSTEM OVERVIEWThe limited time and resources have restricted us to incorporate, in this project, only a main activities that are performed in a PAYROLL MANAGEMENT System, but utmost care has been taken to make the system efficient and user friendly. PAYROLL MANAGEMENT System has been designed to computerized the following functions that are performed by the system:

1. EMPLOYEES Detail Functions

a) Adding a New RECORD

b) Modification to RECORD assigned

a) Admission of New EMPLOYEE .

b) Deleting of EMPLOYEE record.

2. Report/Details Functions

a) Statement of Pay Details a.1) DA

a.2) HR

b) Total number of EMPLOYEE.

c) Individual EMPLOYEE Report .

21

22

2.1 IMPORTANCE OF COMPUTERIZED PAYROLLMANAGEMENT SYSTEMThere are several attributes in which the computer based information works. Broadly the working of computer system is divided into two main groups:

Transaction System

Decision Support System

Transaction System:A transaction is a record of some well-defined single and usually small occurrence in a system. Transactions are input into the computer to update the database files. It checks the entering data for its accuracy. This means that numeric data appears in numeric field and character data in character field. Once all the checks are made, transaction is used to update the database. Transaction can be inputted in on-line mode or batch mode. In on-line mode, transactions are entered and updated into the database almost instantaneously. In batch mode, transactions are collected into batches, which may be held for a while and inputted later.

Decision Support System:It assists the user to make analytical decision. It shows the various data in organized way called analysis. This analysis can be made to syrdy preferences and help in making decisions.

Computer system works out best with record maintenance. It will tell you which EMPLOYEE would get how much pending/reports statements. It will also help to

23

search the information about a particular person by simply entering his telephone number.

User can store information as per requirement, which can be used for comparison with other reports.

FUNCTIONDETAILSThe basic objective of PAYROLL MANAGEMENT SYSTEM is to generalize and simplify the monthly or day to day activities of Payroll like Admission of New employee, payroll, payslip Assigning related to particular employee, Reports of Number of Employee and delete the employee record etc. which has to be performed repeatedly on regular basis. To provide efficient, fast, reliable and user-friendly system is the basic motto behind this exercise.

Let us now discuss how different functions handle the structure and data files:

1. Function ADD RECORD ( )

This is the function used to open a new record for a employee so that he/she can assign a separate Record. In that screen, the automatic EMPLOYEE number . After opening a new record for the employee, finally a CODE is assigned to a EMPLOYEE . This function is used for employee in our company after entering his all personal details like Name, Address, Phone, Sex including date of joining , he have his own convence or Not and his salary. 24

2. Function EDIT( )

This function is used to delete the employee details from database. When the user inputs his code number, the same account number will be checked in the database, if the code number is matched in the database, then the employee record will be deleted from the database and transferred the record of the deleted employee to another table of database so that the Payroll Management has the record of deleted employee to fulfill his legal liabilities. 3. Function GENERATE_ PAYSLIP()

When any employee required his payslip, his/her bill is generated automatically by calculated salary, DA ,HRA etc. It also give its code and date of joining. 4. Function DISPLAY_RECORD()

This function is used to display all the transaction including the Employee name, address, phone, code number to him/her in the screen. This is a global report to display all the transaction records in the screen. 25

TESTINGStandard C and Pre-Standard C1989 Standard C is widespread enough now that it is ok to use its features in new programs. There is one exception: do not ever use the "trigraph" feature of Standard C.1999 Standard C is not widespread yet, so please do not require its features in programs. It is ok to use its features if they are present. However, it is easy to support pre-standard compilers in most programs, so if you know how to do that, feel free. If a program you are maintaining has such support, you should try to keep it working.

To support pre-standard C, instead of writing function definitions in standard prototype form,

int

foo (int x, int y)

...

Write the definition in pre-standard style like this,

int

foo (x, y) int x, y;...

and use a separate declaration to specify the argument prototype:

int foo (int, int);

26

You need such a declaration anyway, in a header file, to get the benefit of prototypes in all the files where the function is called. And once you have the declaration, you normally lose nothing by writing the function definition in the pre-standard style.

This technique does not work for integer types narrower than int. If you think of an argument as being of a type narrower than int, declare it as int instead.

There are a few special cases where this technique is hard to use. For example, if a function argument needs to hold the system type dev_t, you run into trouble, because dev_t is shorter than int on some machines; but you cannot use int instead, because dev_t is wider than int on some machines. There is no type you can safely use on all machines in a non-standard definition. The only way to support non-standard C and pass such an argument is to check the width of dev_t using Autoconf and choose the argument type accordingly. This may not be worth the trouble.

In order to support pre-standard compilers that do not recognize prototypes, you may want to use a preprocessor macro like this:

/* Declare the prototype for a general external function. */ #if defined (__STDC__) || defined (WINDOWSNT) #define P_(proto) proto

#else

#define P_(proto) () #endif

27

Conditional CompilationWhen supporting configuration options already known when building your program we prefer using if (... ) over conditional compilation, as in the former case the compiler is able to perform more extensive checking of all possible code paths.

For example, please write

if (HAS_FOO)

...

else

...

instead of:

#ifdef HAS_FOO

...

#else

...

#endif

A modern compiler such as GCC will generate exactly the same code in both cases, and we have been using similar techniques with good success in several projects.

While this is not a silver bullet solving all portability problems, following this policy would have saved the GCC project alone many people hours if not days per year.

In the case of function-like macros like REVERSIBLE_CC_MODE in GCC which cannot be simply used in if( ...) statements, there is an easy workaround. Simply introduce another macro HAS_REVERSIBLE_CC_MODE as in the following example:

#ifdef REVERSIBLE_CC_MODE

28

#define HAS_REVERSIBLE_CC_MODE 1

#else

#define HAS_REVERSIBLE_CC_MODE 0

#endif

Formatting Error MessagesError messages from compilers should look like this:

Source-file-name:lineno: messageIf you want to mention the column number, use one of these formats:

Source-file-name:lineno:column: messageSource-file-name:lineno.column: messageLine numbers should start from 1 at the beginning of the file, and column numbers should start from 1 at the beginning of the line. (Both of these conventions are chosen for compatibility.) Calculate column numbers assuming that space and all ASCII printing characters have equal width and assuming tab stops every 8 columns.

In an interactive program (one that is reading commands from a terminal), it is better not to include the program name in an error message. The place to indicate which program is running is in the prompt or with the screen layout. (When the same program runs with input from a source other than a terminal, it is not interactive and would do best to print error messages using the non-interactive style.)

The string message should not begin with a capital letter when it follows a program name and/or file name. Also, it should not end with a period.

Error messages from interactive programs, and other messages such as usage messages, should start with a capital letter. But they should not end with a period.

29

2.2 FUNCTIONAL REQUIREMENTThe platform is the hardware and software combination that the Client/Server runs on. While hardware systems vary widely in features and capabilities, certain common features are needed for the operating system software.

HARDWARE SPECIFICATIONSHardware is a set of physical components, which performs the functions of applying appropriate, predefined instructions. In other words, one can say that electronic and mechanical parts of computer constitute hardware.

This package is designed on a powerful programming language Visual Basic. It is a powerful Graphical User Interface. The backend is ORACLE, which is used to maintain database. It can run on almost all the popular microcomputers. The following are the minimum hardware specifications to run this package: -

Processors and memoryThe best system to start with is one based on Pentium II with a minimum 32 MB of RAM. Adequate performance requires at least 64 MB of RAM. But for a database server at least 64 to 128 MB of RAM is required.

Video displaysEarlier, the IBM-compatible computers had a simple text-only monochrome for the video display. Now, they use the advanced high-resolution color displays. For Client/Server systems one should have VGA or better video display.

In the following table TLA stands for the various types of adapters that can be used with IBM compatible PCs and the standard resolution for each one of them.

30

ADAPTER TYPETLASTANDARD RESOLUTION

MonochromeDisplayMDAText only (80 characters by 25

Adapterlines)

Color Graphics AdapterCGA640200

EnhancedGraphicsEGA640350

Adapter

Video Graphics ArrayVGA640480

Super VGASVGA800600 or 1024 768

Disk DrivesEach client computer must have enough disk space available to store the client portion of the software and any data files that needs to be stored locally.

It is best to provide a local disk drive for each client computer. However Client/Server applications can use the diskless workstations for which the only disk access is the disk storage located on a network file server. The hard disk drive at database server should be at least of the capacity 4.1 GB. But it is recommended to have one of capacity 8.2 GB.MouseA mouse is a must for the client software running under Windows OS or any other graphical environment.KeyboardEach client must have a 104 keys extended keyboard.

31

SOFTWARE REQUIREMENTSThe software is a set of procedures of coded information or a program which when fed into the computer hardware, enables the computer to perform the various tasks. Software is like a current inside the wire, which cannot be seen but its effect can be felt.

Application software :TURBO C++ [Dos Based]

32

SYSTEM DESIGN33

3.1 SYSTEM DEVELOPMENT LIFE CYCLEUserRevised Requirement

RequirementSpecification

RequirementInitialFeasibil

DeterminationRequirement

ity

DecisionInvestigation

Analysi

Design Information

System

Feasibility

Test PlanStudy

.

Logical System DesignFunctional Spec.

System

SystemSpecifica

Systemtion

Design

ImplementationAnalysis

Physical

Requirement

SystemConfiguration

Data

ScheduleBudget

SystemHardware

EvaluationStudy

System ModificationImproved System

Maintenance

34

3.2 Data Flow DiagramCONTEXT LEVEL DFD PAYROLLMANAGEMENT SYSTEM

CODE EMPLOYEEPAYROLLMANAGEMENTSYSTEMDELETEDGENERATE

EMPLOYEEPAYSLIP

RECORD

35

DATA FLOW DIAGRAMOPENING A EMPLOYEE RECORD

1 GeneratingEMPLOYEE new CODEnumber1.1 DisplayFormFILEProcess1.2 Get

Details

Update Table

Employee Document1.41.3 Open

new code

Update

36

DATA FLOW DIAGRAMADMISSION OF A NEW EMPLOYEE

1 Assigning aEMPLOYEE newcodenumber1.1 DisplayFormFILEProcessUpdate Table1.2 GetDetailsemployee1.41.3

generate

Update

display

37

DATA FLOW DIAGRAM RECORD MODIFICATION

USER

1 Read the employeecodeScan Record2Show theDetails of FILE RecordProcessingUpdate3 Modify Details of Record38

DATA FLOW DIAGRAM DELETE OF EMPLOYEE

EMPLOYEEFILE

1 Scan the EMPLOYEE number1.1 DisplayFormProcessUpdate TableEmployee Details1.2 Get1.4DetailsUpdate39

DATA FLOW DIAGRAM LISTING OF EMPLOYEE

FILEEMPLOYEE

Scan Record

12 Select

Read theRecord

codefrom

numberDatabase

40

3 CopySelectedRecordProcessing4 Output UnitER-DIAGRAM

DesignationEmp_Name

Allowance

AddressDeduction

Emp_codeEmp_code

NameMonth

GradeDate

LoanBasic

Da

EmployeePayslipSalary

41

3.3 System DesignThe design document that we will develop during this phase is the blueprint of the software. It describes how the solution to the customer problem is to be built. Since solution to complex problems isnt usually found in the first try, iterations are most likely required. This is true for software design as well. For this reason, any design strategy, design method, or design language must be flexible and must easily accommodate changes due to iterations in the design . Any technique or design needs to support and guide the partitioning process in such a way that the resulting sub-problems are as independent as possible from each other and can be combined easily for the solution to the overall problem. Sub-problem independence and easy combination of their solutions reduces the complexity of the problem. This is the objective of the partitioning process. Partitioning or decomposition during design involves three types of decisions: -

Define the boundaries along which to break; Determine into how money pieces to break; andIdentify the proper level of detail when design should stop and implementation should start.

Basic design principles that enable the software engineer to navigate the design process suggest a set of principles for software design, which have been adapted and extended in the following list:

Free from the suffer from "tunnel vision." A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.

The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.

The design should not repeat the same thing. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist.

42

The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain.

The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.

The design activity begins when the requirements document for the software to be developed is available. This may be the SRS for the complete system, as is the case if the waterfall model is being followed or the requirements for the next "iteration" if the iterative enhancement is being followed or the requirements for the prototype if the prototyping is being followed. While the requirements specification activity is entirely in the problem domain, design is the first step in moving from the problem domain toward the solution domain. Design is essentially the bridge between requirements specification and the final solution for satisfying the requirements.

The design of a system is essentially a blueprint or a plan for a solution for the system. We consider a system to be a set of components with clearly defined behavior that interacts with each other in a fixed defined manner to produce some behavior or services for its environment. A component of a system can be considered a system, with its own components. In a software system, a component is a software module.

The design process for software systems, often, has two levels. At the first level, the focus is on deciding which modules are needed for the system, the specifications of these modules, and how the modules should be interconnected. This is what is called the system design or top-level design. In the second level, the internal design of the modules, or how the specifications of the module can be satisfied, is decided. This design level is often called detailed design or logic design. Detailed design essentially expands the system design to contain a more detailed description of the processing logic and data structures so that the design is sufficiently complete for coding.

Because the detailed design is an extension of system design, the system design controls the major structural characteristics of the system. The system design has a major impact

43

on the testability and modifiability of a system, and it impacts its efficiency. Much of the design effort for designing software is spent creating the system design.

The input to the design phase is the specifications for the system to be designed. Hence, a reasonable entry criteria can be that the specifications are stable and have been approved, hoping that the approval mechanism will ensure that the specifications are complete, consistent, unambiguous, etc. The output of the top-level design phase is the architectural design or the system design for the software system to be built. This can be produced with or without using a design methodology. A reasonable exit criteria for the phase could be that the design has been verified against the input specifications and has been evaluated and approved for quality.

A design can be object-oriented or function-oriented. In function-oriented design, the design consists of module definitions, with each module supporting a functional abstraction. In object-oriented design, the modules in the design represent data abstraction (these abstractions are discussed in more detail later). In the function-oriented methods for design and describe one particular methodology the structured design methodology in some detail. In a function- oriented design approach, a system is viewed as a transformation function, transforming the inputs to the desired outputs. The purpose of the design phase is to specify the components for this transformation function, so that each component is also a transformation function. Hence, the basic output of the system design phase, when a function oriented design approach is being followed, is the definition of all the major data structures in the system, all the major modules of the system, and how the modules interact with each other.

Once the designer is satisfied with the design he has produced, the design is to be precisely specified in the form of a document. To specify the design, specification languages are used. Producing the design specification is the ultimate objective of the design phase. The purpose of this design document is quite different from that of the design notation. Whereas a design represented using the design notation is largely to be used by the designer, a design specification has to be so precise and complete that it can be used as a basis of further development by other programmers. Generally, design specification uses textual structures, with design notation helping in understanding.

44

SchedulingScheduling of a software project does not differ greatly from scheduling of any multi-task engineering effort. Therefore, generalized project scheduling tools and techniques can be applied with little modification to software projects.

Program evaluation and review technique (PERT) and critical path method (CPM) are two project scheduling methods that can be applied to software development. Both techniques are driven by information already developed in earlier project planning activities.

Estimates of Effort A decomposition of the product function The selection of the appropriate process model and task set Decomposition of tasks Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project Work Breakdown Structure (WBS) are defined for the product as a whole or for individual functions.

Both PERT and CPM provide quantitative tools that allow the software planner to (1) determine the critical path-the chain of tasks that determines the duration of the project;

(2) establish "most likely" time estimates for individual tasks by applying statistical models; and (3) calculate "boundary times" that define a time window" for a particular task.

Boundary time calculations can be very useful in software project scheduling. Slippage in the design of one function, for example, can retard further development of other functions. It describes important boundary times that may be discerned from a PERT or CPM network: (I) the earliest time that a task can begin when preceding tasks are completed in the shortest possible time, (2) the latest time for task initiation before the minimum project completion time is delayed, (3) the earliest finish-the sum of the earliest start and the task duration, (4) the latest finish- the latest start time added to task duration, and (5) the total float-the amount of surplus time or leeway allowed in scheduling tasks so that the network critical path maintained on schedule. Boundary time calculations lead

45

to a determination of critical path and provide the manager with a quantitative method for evaluating progress as tasks are completed.

Both PERT and CPM have been implemented in a wide variety of automated tools that are available for the personal computer. Such tools are easy to use and take the scheduling methods described previously available to every software project manager.

46

47

4.1 Input and Output screensINPUT OUTPUT SCREENS

48

49

50

51

52

4.2 Source Code//********************************************************** // PROJECT PAYROLL //**********************************************************//********************************************************** // INCLUDED HEADER FILES //**********************************************************#include #include #include #include #include #include #include #include #include //********************************************************** // THIS CLASS CONTAINS ALL THE DRAWING FUNCTIONS //**********************************************************class LINES{public :void LINE_HOR(int, int, int, char) ; void LINE_VER(int, int, int, char) ; void BOX(int,int,int,int,char) ;void CLEARUP(void) ; void CLEARDOWN(void) ;} ;//********************************************************** // THIS CLASS CONTROL ALL THE FUNCTIONS IN THE MENU53

//**********************************************************class MENU{public :void MAIN_MENU(void) ;private :void EDIT_MENU(void) ; void INTRODUCTION(void) ;} ;//********************************************************** // THIS CLASS CONTROL ALL THE FUNCTIONS RELATED TO EMPLOYEE //**********************************************************class EMPLOYEE{public :void NEW_EMPLOYEE(void) ; void MODIFICATION(void) ; void DELETION(void) ;void DISPLAY(void) ; void LIST(void) ;void SALARY_SLIP(void) ;private :void ADD_RECORD(int, char[], char[], char[], int, int, int, char[], char, char, char, float, float) ;void MODIFY_RECORD(int, char [], char [], char [], char [], char, char, char, float, float) ;void DELETE_RECORD(int) ; int LASTCODE(void) ;int CODEFOUND(int) ; int RECORDNO(int) ; int FOUND_CODE(int) ;void DISPLAY_RECORD(int) ; int VALID_DATE(int, int, int) ;int code, dd, mm, yy ;54

char name[26], address[31], phone[10], desig[16] ; char grade, house, convense ;float loan, basic ;} ;//********************************************************** // THIS FUNCTION CONTROL ALL THE FUNCTIONS IN THE MAIN MENU //**********************************************************void MENU :: MAIN_MENU(void){char ch ; LINES L ; L.CLEARUP() ; while (1){clrscr() ; L.BOX(28,7,51,9,218) ; L.BOX(10,5,71,21,218) ; L.BOX(11,6,70,20,219) ; gotoxy(31,8) ;cout max). If the input specifies a set of values and the requirements specify different behavior for different elements in the set, then a valid equivalence class is formed for each of the elements in the set and an invalid class for an entity not belonging to the set.

Essentially, if there is reason to believe that the entire range of an input will not be treated in the same manner, then the range should be split into two or more equivalence classes. Also, for each valid equivalence class, one or more invalid equivalence classes should be identified. For example, an input may be specified as a character. However, we may have reason to believe that the program will perform different actions if a character is an alphabet, a number, or a special character. In that case, we will split the input into three valid equivalence classes.

It is often useful to consider equivalence classes in the output. For an output equivalence class, the goal is to generate test cases such that the output for that test case lies in the output equivalence class. Determining test cases for output classes may be more difficult, but output classes have been found to reveal errors that are not revealed by just considering the input classes.

98

Boundary Value AnalysisIt has been observed that programs that work correctly for a set of values in an equivalence class fail on some special values. These values often lie on the boundary of the equivalence class. Test cases, that have values on the boundaries of equivalence classes are, therefore, likely to be "high-yield" test cases, and selecting such test cases is the aim of the boundary value analysis. In boundary value analysis, we choose an input for a test case from an equivalence class, such that the input lies at the edge of the equivalence classes. Boundary values for each equivalence class, including the equivalence classes of the output, should be covered. Boundary value test cases are also called "extreme cases." Hence, we can say that a boundary value test case is a set of input data that lies on the edge or boundary of a class of input data or that generates output that lies at the boundary of a class of output data.

In case of ranges, for boundary value analysis it is useful to select the boundary elements of the range and an invalid value just beyond the two ends (for the two invalid equivalence classes). So, if the range is 0.0 < x < 1.0, then the test cases are 0.0, 1.0 (valid inputs), and - 0.1, and 1.1 (for invalid inputs). Similarly, if the input is a list, attention should be focused on the first, and last elements of the list. We should also consider the outputs for boundary value analysis. If an equivalence class can be identified in the output, we should try to generate test cases that will produce the output that lies at the boundaries of the equivalence classes. Furthermore, we should try to form test cases that will produce an output that does not lie in the equivalence class.

99

Cause-Effect GraphingOne weakness with the equivalence class partitioning and boundary value methods is that they consider each input separately. That is, both concentrate on the conditions and classes of one input. They do not consider combinations of input circumstances that may form interesting situations that should be tested. One way to exercise combinations of different input conditions is to consider all valid combinations of the equivalence classes of input conditions. This simple approach will result in an unusually large number of test cases, many of which will not be useful for revealing any new errors. For example, if there are n different input conditions, such that any combination of the input conditions is valid, we will have 2 test cases.

Cause-effect graphing is a technique that aids in selecting combinations of input conditions in a systematic way, such that the number of test cases does not become unmanageably large. The technique starts with identifying causes and effects of the system under testing. A cause is a distinct input condition, and an effect is a distinct output condition. Each condition forms a node in the cause-effect graph. The conditions should be stated such that they can be set to either true or false. For example, an input condition can be "file is empty," which can be set to true by having an empty input file, and false by a nonempty file. After identifying the causes and effects, for each effect we identify the causes that can produce that effect and how the conditions have to be combined to make the effect true. Conditions are combined using the Boolean operators "and," "or," and "not," which are represented in the graph by &, I, and ""'. Then, for each effect, all combinations of the causes that the effect depends on which will make the effect true, are generated (the causes that the effect does not depend on are essentially "don't care"). By doing this, we identify the combinations of conditions that make different effects true. A test case is then generated for each combination of conditions, which make some effect true.

100

Cause:c1. Command is add c2. Command is deletec3. employee number is valid c4. Transaction_amt. is validEffects:el. Print "invalid command"e2. Print "invalid employee-number" e3. Print "Debit amount not valid" e4. displaye. generate payslipLIST OF CAUSES AND EFFECTSLet us illustrate this technique with a small example. Suppose that for a bank database there are two commands allowed:

creditacct-numbertransaction_amount

debitacct-numbertransaction_amount

The requirements are that if the command is credit and the acct-number is valid, then the account is credited. If the command is debit, the acct-number is valid, and the transaction_amount is valid (less than the balance), then the account is debited. If the command is not valid, the account number is not valid, or the debit amount is not valid, a suitable message is generated. We can identify the following causes and effects from these requirements.The cause effect of this is shown in Figure. In the graph, the cause-effect relationship of this example is captured. For all effects, one can easily determine the causes each effect depends on and the exact nature of the dependency. For example, according to this graph, the effect E5 depends on the causes c2, c3, and c4 in a manner such that the effect E5 is enabled when all c2, c3, and c4 are true. Similarly, the effect E2 is enabled if c3 is false.

From this graph, a list of test cases can be generated. The basic strategy is to set an effect to I and then set the causes that enable this condition. The condition of causes forms the test case. A cause may be set to false, true, or don't care (in the case when the effect does

101

not depend at all on the cause). To do this for all the effects, it is convenient to use a decision table. The decision table for this example is shown in Figure

This table lists the combinations of conditions to set different effects. Each combination of conditions in the table for an effect is a test case. Together, these condition combinations check for various effects the software should display. For example, to test for the effect E3, both c2 and c4 have to be set. That is, to test the effect "Print debit amount not valid," the test case should be: Command is debit (setting: c2 to True), the account number is valid (setting c3 to False), and the transaction money is not proper (setting c4 to False).

C1VC2V

V

C3

VV

C4

V

E1E2E3E5E4102

THE CAUSE EFFECT GRAPHSNo.12345

Cl01Xx1

C20x11x

C3x0111

C4xx011

El1

E21

E31

E41

E51

DECISION TABLE FOR THE CAUSE-EFFECT GRAPHCause-effect graphing, beyond generating high-yield test cases, also aids the understanding of the functionality of the system, because the tester must identify the distinct causes and effects. There are methods of reducing the number of test cases generated by proper traversing of the graph. Once the causes and effects are listed and their dependencies specified, much of the remaining work can also be automated.

Special CasesIt has been seen that programs often produce incorrect behavior when inputs form some special cases. The reason is that in programs, some combinations of inputs need special treatment, and providing proper handling for these special cases is easily overlooked. For example, in an arithmetic routine, if there is a division and the divisor is zero, some special action has to be taken, which could easily be forgotten by the programmer. These special cases form particularly good test cases, which can reveal errors that will usually not be detected by other test cases.

Special cases will often depend on the data structures and the function of the module. There are no rules to determine special cases, and the tester has to use his intuition and experience to identify such test cases. Consequently, determining special cases is also called error guessing.

103

The psychology is particularly important for error guessing. The tester should play the "devil's advocate" and try to guess the incorrect assumptions that the programmer could have made and the situations the programmer could have overlooked or handled incorrectly. Essentially, the tester is trying to identify error prone situations. Then, test cases are written for these situations. For example, in the problem of finding the number of different words in a file (discussed in earlier chapters) some of the special cases can be: file is empty, only one word in the file, only one word in a line, some empty lines in the input file, presence of more than one blank between words, all words are the same, the words are already sorted, and blanks at the start and end of the file.

Incorrect assumptions are usually made because the specifications are not complete or the writer of specifications may not have stated some properties, assuming them to be obvious. Whenever there is reliance on tacit understanding rather than explicit statement of specifications, there is scope for making wrong assumptions. Frequently, wrong assumptions are made about the environments. However, it should be pointed out that special cases depend heavily on the problem, and the tester should really try to "get into the shoes" of the designer and coder to determine these cases.

Structural TestingA complementary approach to testing is sometimes called structural or White box or Glass box testing. The name contrasts with black box testing because the tester can analyse the code and use knowledge about it and the structure of a component to derive the test data. The advantage of structural testing is that test cases can be derived systematically and test coverage measured. The quality assurance mechanisms, which are setup to control testing, can quantify what level of testing is required and what has be carried out. In the previous section, we discussed functional testing, which is concerned with the function that the tested program is supposed to perform and does not deal with the internal structure of the program responsible for actually implementing that function. Thus, functional testing is concerned with functionality rather than implementation of the program. Various criteria for functional testing were discussed earlier. Structural testing, on the other hand, is concerned with testing the implementation of the program. The

104

intent of structural testing is not to exercise all the different input or output conditions (although that may be a by-product) but to exercise the different programming structures and data structures used in the program.

To test the structure of a program, structural testing aims to achieve test cases that will force the desired coverage of different structures. Various criteria have been proposed for this. Unlike the criteria for functional testing, which are frequently imprecise, the criteria for structural testing are generally quite precise as they are based on program structures, which are formal and precise. Here we will discuss three different approaches to structural testing: control flow-based testing, data flow-based testing, and mutation testing.

Control Flow-Based CriteriaBefore we consider the criteria, let us precisely define a control flow graph for a program. Let the control flow graph (or simply flow graph) of a program P be G. A node in this graph represents a block of statements that is always executed together, i.e., whenever the first statement is executed, all other statements are also executed. An edge (i, j) (from node i to node j) represents a possible transfer of control after executing the last statement of the block represented by node i to the first statement of the block represented by node j. A node corresponding to a block, whose first statement is the start statement of P, is called the start node of G, and a node corresponding to a block whose last statement is an exit statement is called an exit node. A path is a finite sequence of nodes (n1, nz, nk), k > I, such that there is an edge (ni, ni+1) for all nodes n; in the sequence (except the last node nk). A complete path is a path whose first node is the start node and the last node is an exit node.

Now, let us consider control flow-based criteria. Perhaps, the simplest coverage criteria is statement coverage, which requires that each statement of the program be executed at least once during testing. In other words, it requires that the paths executed during testing include all the nodes in the graph. This is also called the all-nodes criterion. This coverage criterion is not very strong, and can leave errors undetected. For example, if

105

there is an if statement in the program without having an else clause, the statement coverage criterion for this statement will be satisfied by a test case that evaluates the condition to true. No test case is needed that ensures that the condition in the if statement evaluates to false. This is a serious shortcoming because decisions in programs are potential sources of errors. As an example, consider the following function to compute the absolute value of a number:

int xyz (y)

int y;

{

if (y >= 0) y = 0 -y;

return (y)

}

This program is clearly wrong. Suppose we execute the function with the set of test cases {y-a} (i.e., the set has only one test case). The statement coverage criterion will be satisfied by testing with this set, but the error will not be revealed.

A little more general coverage criterion is branch coverage, which requires that each edge in the control flow graph be traversed at least once during testing. In other words, branch coverage requires that each decision in the program be evaluated to true and false values at least once during testing. Testing based on branch coverage is often called branch testing. The 100% branch coverage criterion is also called the all-edges criterion. Branch coverage implies statement coverage, as each statement is a part of some branch. In other words, Cbranch =} Cstmt. In the preceding example, a set of test cases satisfying this criterion will detect the error.

The trouble with branch coverage comes if a decision has many conditions in it (consisting of a Boolean expression with Boolean operators and and or). In such situations, a decision can evaluate to true and false without actually exercising all the conditions. For example, consider the following function that checks the validity of a data item. The data item is valid if it lies between 0 and 100.

106

int check(y)

int y;

{

if y >=) && (y 0). The condition (y < 200) never evaluates to false during this test, hence the error in this condition is not revealed.

This problem can be resolved by requiring that all conditions evaluate to true and false. However, situations can occur where a decision may not get both true and false values even if each individual condition evaluates to true and false. An obvious solution to this problem is to require decision/condition coverage, where all the decisions and all the conditions in the decisions take both true and false values during the course of testing.

Studies have indicated that there are many errors whose presence is not detected by branch testing because some errors are related to some combinations of branches and their presence is revealed by an execution that follows the path that includes those branches. Hence, a more general coverage criterion is one that requires all possible paths in the control flow graph be executed during testing. This is called the path coverage criterion or the all-paths criterion, and the testing based on this criterion is often called path testing. The difficulty with this criterion is that programs that contain loops can have an infinite number of possible paths. Furthermore, not all paths in a graph may be

107

"feasible" in the sense that there may not be any inputs for which the path can be executed. It should be clear that C path => Cbranch.

As the path coverage criterion leads to a potentially infinite number of paths, some efforts have been made to suggest criteria between the branch coverage and path coverage. The basic aim of these approaches is to select a set of paths that ensure branch coverage criterion and try some other paths that may help reveal errors. One method to limit the number of paths is to consider two paths as same, if they differ only in their sub-paths that are caused due to the loops. Even with this restriction, the number of paths can be extremely large.

Another such approach based on the cyclomatic complexity has been proposed namely, the test criterion. The test criterion is that if the cyclomatic complexity of a module is V, then at least V distinct paths must be executed during testing. We have seen that cyclomatic complexity V of a module is the number of independent paths in the flow graph of a module. As these are independent paths, all other paths can be represented as a combination of these basic paths. These basic paths are finite, whereas the total number of paths in a module having loops may be infinite.

It should be pointed out that none of these criteria is sufficient to detect all kind of errors in programs. For example, if a program is missing out some control flow paths that are needed to check for a special value (like pointer equals nil and divisor equals zero), then even executing all the paths will not necessarily detect the error. Similarly, if the set of paths is such that they satisfy the all-path criterion but exercise only one part of a compound condition, then the set will not reveal any error in the part of the condition that is not exercised. Hence, even the path coverage criterion, which is the strongest of the criteria we have discussed, is not strong enough to guarantee detection of all the errors.

108

Data Flow-Based TestingCriteria that select the paths to be executed during testing based on data flow analysis, rather than control flow analysis. In the data flow-based testing approaches, besides the control flow, information about where the variables are defined and where the definitions are used is also used to specify the test cases. The basic idea behind data flow-based testing is to make sure that during testing, the definitions of variables and their subsequent use is tested. Just like the all-nodes and all-edges criteria try to generate confidence in testing by making sure that at least all statements and all branches have been tested, the data flow testing tries to ensure some coverage of the definitions and uses of variables. Approaches for use of data flow information have been proposed in. Our discussion here is based on the family of data flow-based testing criteria that were proposed. Some of these criteria are discussed here.

For data flow-based criteria, a definition-use graph (def-use graph, for short) for the program is first constructed from the control flow graph of the program. A statement in a node in the flow graph representing a block of code has variable occurrences in it. A variable occurrence can be one of the following three types:

def represents the definition of a variable. The variable on the left-hand side of an assignment statement is the one getting defined.

c-use represents computational use of a variable. Any statement (e.g., read/write an assignment) that uses the value of variables for computational purposes is said to be making c-use of the variables. In an assignment statement, all variables on the right-hand side have a c-use occurrence. In a read and a write statement, all variable occurrences are of this type.

p-use represents predicate use. These are all the occurrences of the variables in a predicate (i.e., variables whose values are used for computing the value of the predicate), which is used for transfer of control.

Based on this classification, the following can be defined. Note that c- use variables may also affect the flow of control, though they do it indirectly by affecting the value of the p-

109

use variables. Because we are interested in the flow of data between nodes, a c-use of a variable x is considered global c-use if there is no def of x within the block preceding the c-use. With each node i, we associate all the global c-use variables in that node. The p-use is associated with edges. If x1, x2 . xn had p-use occurrences in the statement of a block from where two edges go to two different blocks j and k (e.g., with an if then else), then x1, xn are associated with the two edges (i, j) and (i, k).

A path from node i to node j is called a del-clear path with respect to (w.r.t.) a variable x if there is no def of x in the nodes in the path from i to j (nodes i and j may have a def). Similarly, a def-clear path w.r.t. x from a node i to an edge (j, k) is one in which no node on the path contains a definition of x. A def of a variable x in a node i is a global def, if it is the last def of x in the block being represented by i, and there is a def -clear path from i to some node with a global c-use of x. Essentially, a def is a global def if it can be used outside the block in which it is defined.

The def-use graph for a program P is constructed by associating sets of variables with edges and nodes in the flow graph. For a node i, the set deft (i) is the set of variables for which there is a global def in the node i, and the set c-use (i) is the set of variables for which there is a global c-use in the node i. For an edge (i, j), the set p-use (i, j) is the set of variables for which there is a p-use for the edge (i, j).

Suppose a variable x is in def (i) of a node i. Then, dcu (x, i) is the set of nodes, such that each node has x in its c-use, x E def (i), and there is a def-clear path from i to j. That is, dcu (x, i) represents all those nodes in which the (global) c-use of x uses the value assigned by the def of x in i. Similarly, dpu (x, i) is the set of edges, such that each edge has x in its p-use, x def (i), and there is a def-clear path from i to (j, k). That is, dpu (x, i) represents all those edges in which the p-use of x uses the value assigned by the def of x in i.

Based on these definitions proposed, a family of test case selection criteria were proposed, a few of which we discuss here. Let G be the def/use graph for a program, and let P be a set of complete paths of G (i.e., path l representing a complete execution of the program). A test case selection criterion, defines the contents of P.

110

P satisfies the all-defs criterion if for every node i in G and every x in def (i), P includes a def-clear path w.r.t. x to some member of dcu (x, i) or some member of dpu (x, i). This criterion says that for the def of every variable, one of its uses (either p-use or c-use) must be included in a path. That is, we want to make sure that during testing the use of the definitions of all variables is tested.

The all-p-uses criterion requires that for every x E def (i), P include a "def-clear path w.r.t. x from i to some member of dpu (x, i). That is, according to this criterion all the p-uses of all the definitions should be tested. However, by this criterion a c-use of a variable may not be tested. The all-p-uses, some-c-uses criterion requires that all p-uses of a variable definition must be exercised, and some c-uses must also be exercised. Similarly, the all-c-uses, some-p-uses criterion requires that all c-uses of a variable definition be exercised, and some p-uses must also be exercised.

The all-uses criterion requires that all p-uses and all c-uses of a definition must be exercised. That is, the set P must include, for every node i and every x E def (i), a def-clear path w.r.t. x from i to all elements of dcu (x, i) and to all elements of dpu (x, i).

In terms of the number of test cases that might be needed to satisfy the data flow- based criteria, it has been shown that though the theoretical limit on the size of the test case set is up to quadratic in the number of two-way decision statements in the program, the actual number of test cases that satisfy a criterion is quite small in practice.

As mentioned earlier, a criterion C1 includes another criterion C2 (represented by C1 => C2 if any set of test cases that satisfy criterion C1 also satisfy the criterion C2. The inclusion relationship between the various data flow criteria and the control flow criteria is given in Figure 6.5.

111

all paths (path average)

all user

all-p-user/

all-c-uses/ some-p-usessome-c-uses

all-defsall-p-uses

all-edges (branch coverage)

all-nodes (statement coverage)

RELATIONSHIP AMONG THE DIFFERENT CRITERIAIt should be quite clear that all-paths will include all-uses and all other structure based criteria. All-uses, in turn, include all-p-uses, all defs, and all-edges. However, all defs does not include all-edges (and the reverse is not true). The reason is that all defs is focusing on all definitions getting used, while all-edges is focusing on all decisions evaluating to both true and false. For example, a decision may evaluate to true and false in two different test cases, but the use of a definition of a variable x may not have been exercised. Hence, the all-defs and all-edges criteria are, in some sense, incomparable.

Inclusion does not imply that one criterion is always better than another. At best, it means that if the test case generation strategy for two criteria C1 and C2 is similar, and if C1 C2, then statistically speaking, the set of test cases satisfying C1 will be better than a set of test cases satisfying C2. The experiments reported show that no one criterion (out of a set of control flow-based and data flow-based criteria) does significantly better than another, consistently. However, it does show that testing done by using all-branch or all-uses criterion, generally, does perform better than randomly selected test cases.

112

System TestingSoftware is only one element of a larger computer-based system. Ultimately, software is incorporated with other system elements and a series of system integration and a validation test are conducted. These tests fall outside the scope of software engineering process and are not conducted solely by the software developer.

System testing is actually a series of different test whose primary purpose is to fully exercise the computer-based system. Although each test has a different purpose, all work to verify that all system elements have been properly integrated and perform allocated functions.

Mutation TestingMutation testing is another structural testing technique that differs fundamentally from the approaches discussed earlier. In control flow-based and data flow-based testing, the focus was on which paths to execute during testing. Mutation testing does not take a path-based approach. Instead, it takes the program and creates many mutants of it, by making simple changes to the program. The goal of testing is to make sure that during the course of testing, each mutant produces an output different from the output of the original program. In other words, the mutation-testing criterion does not say that the set of test cases must be such that certain paths are executed; instead, it requires the set of test cases to be such that they can distinguish between the original program and its mutants.

Test Plan Activities During TestingA test plan is a general document for the entire project that defines the scope, approach to be taken, and the schedule of testing as well as identifies the test items for the entire testing process and the personnel responsible for the different activities of testing. The test planning can be done well before the actual testing commences and can be done in parallel with the coding and design phases. The inputs for forming the test plan are: (1) project plan, (2) requirements document, and (3) system design document. The project plan is needed to make sure that the test plan is consistent with the overall plan for the project and the testing schedule matches that of the project plan. The requirements

113

document and the design document are the basic documents used for selecting the test units and deciding the approaches to be used during testing. A test plan should contain the following:

Test unit specification.

Features to be tested.

Approach for testing.

Test deliverables.

Schedule.

Personnel allocation.

One of the most important activities of the test plan is to identify the test units. A test unit is a set of one or more modules, together with associated data, that are from a single computer program and that are the objects of testing. A test unit can occur at any level and can contain from a single module to the entire system. Thus, a test unit may be a module, a few modules, or a complete system.

Unit TestingUnit testing compromises the set of tests performed by an individual programmer prior to integration of the unit into a larger system. The situation is illustrated as follows:

Coding and debuggingUnit Integration Testing

A program unit is usually small enough programmer who developed it can test it in great detail, and certainly in greater detail the will be possible when the unit is integrated into an evolving software product. There are four categories of tests that a programmer will typically perform on a program unit:

Function Tests

Performance Test

Stress Tests

114

Structure Tests

Functional test cases involve exercising the code with nominal input values for which the expected results are known, as well as boundary values (minimum values, maximum values, and values on and just outside the functional boundaries) and special values such as logically related inputs, 1x1 matrices, the identity matrix, files of identical elements, and empty files.

A test coverage (or test completion) criterion must be established for unit testing, because program units usually contain too many paths to permit exhaustive testing. This can be seen by the examining the program segment in Figure 6.7. As illustrated in Figure 6.7, loops introduce combinatorial numbers of execution paths and make exhaustive testing impossible.

N P 0 2N14

2810 2048 P=2N+1115

Even if it were possible to successfully test all paths through a program, correctness would not be guaranteed by path testing because the program might have missing paths and computational errors that were not discovered by the particular test cases chosen. A missing path error occurs when a branching statement and the associated computations are accidentally omitted. Missing path errors can only be detected by functional test cases derived from the requirements specifications. Thus, tests based solely on the program structure cannot detect all the potential errors in a source program. Coincidental correctness occurs when a test case fails to detect a computation error. For instance, the expressions (A + A) and (A*A) have identical values when A has the value 2.

Program errors can be classified as missing path errors, computational errors and domain errors. Tai has observed that N + m1 linearly independent test cases are required to

establish computational correctness of a program that performs only linear calculations on N input variables. By linear calculations, we mean that all computations are linear functions of the input variables when symbolic execution techniques)

Integration TestingBottom-up integration is the traditional strategy to integrate the components of a software system into a functioning whole. Bottom-up integration consists of unit testing, followed by subsystem testing, followed by testing of the entire system. Unit testing has the goal of discovering errors in the individual modules of the system. Modules are tested in isolation from one another in an artificial environment known as a test harness, which consists of the driver programs and data necessary to exercise the modules. Unit testing should be as exhaustive as possible to ensure that each representative handled by each module has been tested. Unit testing is eased by a system structure that is composed of small, loosely coupled modules.

A subsystem consists of several modules that communicate with each other through well-defined interfaces. Normally, a subsystem implements a major segment operation of the interfaces between modules in the subsystem. Both control and of subsystem testing: lower level subsystems are successively combined to form higher-level subsystems. In most software systems, exhaustive testing of subsystem capabilities is not feasible due to

116

the combinational complexity of the module interfaces; therefore, test cases must be carefully chosen to exercise the interfaces in the desired manner.

System testing is concerned with subtleties in the interfaces, decision logic, control flow, recovery procedures, throughput, capacity, and timing characteristics of the entire system. Careful test planning is required to determine the extent and nature of system testing to be performed and to establish criteria by which the results will be evaluated.

Disadvantages of bottom-up testing include the necessity to write and debug test harness for the modules and subsystems, and the level of complexity that results from combining modules and subsystems into larger and larger units. The extreme case of complexity results when each module is unit tested in isolation and big bang approach to integration testing. The main problem with big-bang integration is the difficulty of isolating the sources of error.

Test harnesses provide data environments and calling sequences for the routines and subsystems that are being tested in isolation. Test harness preparation can amount to 50 per cent or more of the coding and debugging effort for a software product.

Top-down integration starts with the main routine and one or two immediately subordinate routines in the system structure. After this top-level, when skeleton has been thoroughly tested, it becomes the test harness for its immediately subordinate routines. Top-down integration requires the use of program stubs to simulate the effect of lower-level routines that are called by those being tested.

Regression Testing

When some errors occur in a program then these are rectified. For rectification of these errors, changes are made to the program. Due to these changes some other errors may be incorporated in the program. Therefore, all the previous test cases are tested again. This type of testing is called regression testing.

In a broader context, successful tests (of any kind) result in the discovery of errors, and errors must be corrected. Whenever software is corrected, some aspect of the software

117

configuration (the program, its documentation, or the data that supports it) is changed. Regression testing is the activity that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors.

Regression testing may be conducted manually, by re-executing a subset of all test cases or using automated capture/playback tools. Capture/playback tools enable the software engineer to capture test cases and results for subsequent playback and comparison.

The regression test suite (the subset of tests to be executed) contains three different classes of test cases:

A representative sample of tests that will exercise all software functions.

Additional tests that focus on software functions that are likely to be affected by the change.

Tests that focus on the software components that have been changed.

As integration testing proceeds, the number of regression tests can grow quite large.

Therefore, the regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program functions. It is impractical and inefficient to re-execute every test for every program function once a change has occurred.

118

Levels of TestingNow let us turn over attention testing process. We have seen that faults can occur during any phase in the software development cycle. Verification is performed on the output of each phase, but some faults are likely to remain undetected by these methods. These faults will be eventually reflected in the code. Testing is usually relied on to detect these faults, in addition to the faults introduced during the coding phase itself. Due to this, different levels of testing are used in the testing process; each level of testing aims to test different aspects of the system.

ClientAcceptance

Needs Testing

RequirementsSystem

Testing

Design

Integration

Testing

CodeUnit

Testing

The basic levels are unit testing, integration testing, testing system and acceptance testing. These different levels of testing attempt to detect different types of faults. The relation of the faults introduced in different phases, and the different levels of testing as shown in figure 6.8.

The first level of testing is called unit testing. In this, different modules are tested against the specifications produced during design for the modules. Unit testing is, essentially, for verification of the code produced during the coding phase, hence the goal is to test the internal logic of the modules. It is typically done by the programmer of the module. A module is considered for integration and use by others only after it has been unit tested satisfactorily. Due to its close association with coding, the coding phase is frequently called coding and unit testing. As the focus of this testing level is on testing the code,

119

structural testing is best suited for this level. In fact, as structural testing is not very suitable for large programs, it is used mostly at the unit testing level.

The next level of testing is often called integration testing. In this, many unit-tested modules are combined into subsystems, which are then tested. The goal here is to see if the modules can be integrated properly. Hence, the emphasis is on testing interfaces between modules. This testing activity can be considered testing the design.

The next levels are system testing and acceptance testing. Here the entire software system is tested. The reference document for this process is the requirements document, and the goal is to see if the software meets its requirements. This is essentially a validation exercise, and in many situations, it is the only validation activity. Acceptance testing is sometimes performed with realistic data of the client to demonstrate that the software is working satisfactorily. Testing here focuses on the external behavior of the system; the internal logic of the program is not emphasized. Consequently, mostly functional testing is performed at these levels.

120

TEST DATA

Specifications

for PAYROLL

SYSTEM user

form1

Test Date27-4-2010Programmer name:Payroll System

Tested By:Project ID:11105454

Employee CodeEmployee Name

the fields are required.Can enter only letters, spaces, hyphens, and apostrophes. No numeric & special characters are allowed( Length upto 32 characters)Will accept only letters, numbers, underscores, and one dot (.)Employee Address

PhoneSelect MonthDDYYYYSelect here.

DesignationSelect here

Grade

Housepassword length >Don't use your

than 6 alphanumericName or ID

Conveyencepassword length > than 6 alphanumeric

121

LoanSelect OneUse 4 characters

or more- not case

sensitive

Basic Salary

Positive Test cases for registrat