Anda di halaman 1dari 79




1.1 Purpose:

The main aim of our project is to issue appropriate paychecks. Payroll department also
identifies the employee by a federal code and keep a running tally on total income and

1.2 Scope:

• In the present Payroll System just by giving the Employee id our system will
automatically generate a pay slip, which consists of Salary details of an employee like
Basic Pay, Allowances and Deductions.
• In this automation we can easily maintain and modify the employee details without
any errors.

1.2 Definitions:

This glossary contains the working definitions for the key concepts in the system

 Administrator: A person who is responsible in maintaining a system.

 Employee: A person who is working in the institute and capable of

accessing his details.

 Database: It stores the entire information of each employee who works for
an institution.

 Login: This is used to authenticate the user of the system. It may be either an
employee or an administrator.

S.K.T.R.M.C.E 1

 Report: It is a statement describing in details about the things happened in a


1.4 Abbreviations:

 .NET Network Enabling Technology

 SQL Structured Query Language

 UML Unified Modeling Language

 CSE Computer Science and Engineering

 IT Information Technology

 EC Electronics and Communications

 EEE Electrical and Electronic Engineering

 EPF Employee Provident Fund

 DA Dearness Allowance

 HRA House Rent Allowance

 PT Professional Tax

 LIC Life Insurance Corporation

S.K.T.R.M.C.E 2




Before creating this automation, every employee details and pay slips are maintained
in records. It will take long time to generate pay slips of each employee.

It is very difficult to maintain and modify the details of an employee in the manual
system. Sometimes error may occur.

S.K.T.R.M.C.E 3


By keeping all the above existing activities we developed a system named as “Employee
Payroll System” which generates pay slips by entering the unique id of an employee.

In this automation system we can maintain and modify the employee details easily
without any errors.

2.3 Feasibility Study:

A Feasibility Study is a process which defines exactly what a project is and what
strategic issues need to be considered to assess its feasibility or likelihood of succeeding.

A feasibility study main goal is to assess the economic viability of the proposed
business. The feasibility study needs to answer the question: “Does the idea make
economic sense?” The study should provide a thorough analysis of the business opportunity,
including a look at all the possible roadblocks that may stand in the way of the cooperative’s
success. The outcome of the feasibility study will indicate whether or not to proceed with the
proposed venture. If the results of the feasibility study are positive, then the cooperative can
proceed to develop a business plan.

If the results show that the project is not a sound business idea, then the project should
not be pursued.

Economic Feasibility:

S.K.T.R.M.C.E 4

Economic feasibility attempts to weigh the costs of developing and implementing a

new system, against the benefits that would occur from having the new system in place. This
feasibility study gives the top management.

Payroll provides better economic feasibility by replacing the existing system and
eases the maintenance. It replaces the existing paper pay slips with the automated computer
pay slips which are faster and safer than the old one. It provides more benefits with little cost.
Of course it’s costlier than the past but it offers more benefits which is not possible with the
old one.

Operational Feasibility:

Proposed project is beneficial only if it can be turned into information systems that
will meet the organizations operating requirements. This test of feasibility asks if the system
will work when it is developed and installed.

Since the proposed system was developed based on the users requirements and
considering existing system disadvantages, so it helps to reduce the hardships encountered.
With the existing manual system, the new system was considered to be operational feasible.

Technical Feasibility:

The technology used to build the PAYROLL is C# .NET which is a feasible one
developed by the Microsoft for developing the windows applications. It’s been filtered from
the most successful Object oriented language java and it also incorporating many new
features to make the building applications so easy. It doesn’t require more efforts to
understand and get used to the Payroll because today everybody using the Microsoft’s
windows operating system, Payroll doesn’t bring anything new to the user and it has things
that already known to everybody. So, Payroll is technically feasible.

S.K.T.R.M.C.E 5

3.1 Software Requirements:

o Operating System : Windows XP/ 2007

o User Interface : Windows GUI
o Programming Language : .NET (C#)
o Database connectivity API : SQL server 2005
o Case Tool : Rational Rose 98
o Web Browser : Internet Explorer / Mozilla Firefox
o Documentation Tool : MS-word 2003/ 2007
o Developing Software : Microsoft Visual Studio 2005

3.2 Hardware Requirements

 Processor : Pentium IV
 Hard Disk : 80 GB
 RAM : 2 GB
 Processor Speed : 2 GHz

3.3 Specific Requirements:

S.K.T.R.M.C.E 6

It contains all the software requirements to a level of detail sufficient to enable

designers to design a system to satisfy those requirements, and testers to test that the system
satisfies those requirements.

3.4 Use-case reports:

There are two types of users who use this system. They interact with the system at
different levels and with different interfaces.

So our project consists of two modules.



The functional requirements of the users are described in the use-case reports.


Employee is able to modify his own profile and can look out his pay report. But he
will be able to do this only if it was allowed by the administrator.


Name : Authentication


The Employee can login into Server using Employee login ID and Password.

S.K.T.R.M.C.E 7


Employee details should be stored already in Database.

Post Conditions

Employee is given control over the application completely.

Basic Course of Action:

1. Login ID and Password are Entered.

2. Login ID and Password are authenticated using database.

3. If entered data is correct then Employee is directed to his profile.

Alternate Course of Action:

If either of login ID or Password is incorrect then Error message is displayed.

ACKNOWLEDGEMENTEmployee Operations>

S.K.T.R.M.C.E 8

Name : Employee Operations


An authorized Employee who works in an institution


An Employee should be already logged in.

Post Conditions

He will have the control over his own applications.

Basic Course of Action:

1. Modify profile
2. View pay reports
3. Change password

Alternate Course of Action:

If the Employee doesn’t want to perform any changes (or) work is done, then he can
logout the application.

S.K.T.R.M.C.E 9


Responsible in maintaining, modifying the employee details. And can add employee
and department, view employee details and pay reports and can change his own password.


Name : Authentication


The administrator can login into Server using administrator login ID and Password.


Administrator details should be stored already in Database.

Post Conditions

Administrator is given control over the application completely.

Basic Course of Action:

1. Login ID and Password are Entered.

2. Login ID and Password are authenticated using database.

3. If entered data is correct then administrator is directed to the application.

S.K.T.R.M.C.E 10

Alternate Course of Action:

If either of login ID or Password is incorrect then Error message is displayed.

ACKNOWLEDGEMENTAdministrator Operations>

Name : Administrator Operations


The authorized administrator who manages the system


Administrator should be already logged in.

Post Conditions

He will have the control over his own details and on all the employees of the

Basic Course of Action:

1. Show employee profile

S.K.T.R.M.C.E 11

2. Add employee
3. Modify employee details
4. Add department
5. Reports on pay
6. Change his own password

Alternate Course of Action:

If administrator doesn’t want to perform any changes (or) work is done, then he can
logout the application.



4.1 Architecture Diagram:

S.K.T.R.M.C.E 12


It is a process of converting a relation to a standard form. The process is used to

handle the problems that can arise due to data redundancy i.e. repetition of data in the
database, maintain data integrity as well as handling problems that can arise due to insertion,
updating, deletion anomalies.

S.K.T.R.M.C.E 13

Decomposing is the process of splitting relations into multiple relations to eliminate

anomalies and maintain anomalies and maintain data integrity. To do this we use normal
forms or rules for structuring relation.

Insertion anomaly: Inability to add data to the database due to absence of other data.

Deletion anomaly: Unintended loss of data due to deletion of other data.

Update anomaly: Data inconsistency resulting from data redundancy and partial update

Normal Forms: These are 5 rules for structuring relations that eliminate anomalies.

4.3 Data Dictionary:

After carefully understanding the requirements of the client the entire data storage
requirements are divided into tables. The below tables are normalized to avoid any anomalies
during the course of data entry.



Emp_id Varchar(10) Primary key
Emp_name Varchar(20) Not null
Passwd Varchar(10) Unique
Gender Varchar(10) Not null
Date_of_birth Varchar(20) Not null
Age Int Not null
Dept_name Varchar(10) Not null
Experience Int Null

S.K.T.R.M.C.E 14

Qualification Varchar(20) Not null



Emp_id Varchar(10) Foreign key
Ph_no Varchar(10) Unique
Street Varchar(20) Not null
H_no Varchar(10) Not null
Place Varchar(20) Not null
Dist Varchar(20) Not null



Emp_id Varchar(10) Foreign key
dept_type Varchar(10) Not null
Dept_name Varchar(10) Foreign key
Basic_pay Int Not null
DA Int Not null
HRA Int Not null
EPF Int Not null
PT Int Not null
IT Int Not null
LIC Int Not null
Month Varchar(10) Not null
Year Int Not null
Total_leaves Int Null
Loss_of_pays Int Null
Account_no Varchar(20) Not null
Bank Varchar(20) Not null
Gross_pay Int Not null

S.K.T.R.M.C.E 15



Dept_no Int Not null
Dept_name Varchar(10) Primary key
Dept_type Varchar(10) Not null



Adm_id Varchar(10) Unique
Passwd Varchar(10) Unique
Adm_name Varchar(10) Unique


A data flow diagram is graphical tool used to describe and analyze movement of data
through a system. These are the central tool and the basis from which the other components
are developed. The transformation of data from input to output, through processed, may be
described logically and independently of physical components associated with the system.
These are known as the logical data flow diagrams. The physical data flow diagrams show
the actual implements and movement of data between people, departments and workstations.
A full description of a system actually consists of a set of data flow diagrams. Using two
familiar notations Yourdon, Gane and Sarson notation develops the data flow diagrams. Each
component in a DFD is labeled with a descriptive name. Process is further identified with a
number that will be used for identification purpose. The development of DFD’s is done in
several levels. Each process in lower level diagrams can be broken down into a more
detailed DFD in the next level. The lop-level diagram is often called context diagram. It
consist a single process bit, which plays vital role in studying the current system. The
process in the context level diagram is exploded into other process at the first level DFD.

S.K.T.R.M.C.E 16

The idea behind the explosion of a process into more process is that understanding at
one level of detail is exploded into greater detail at the next level. This is done until further
explosion is necessary and an adequate amount of detail is described for analyst to understand
the process.

Larry Constantine first developed the DFD as a way of expressing system

requirements in a graphical from, this lead to the modular design.

A DFD is also known as a “bubble Chart” has the purpose of clarifying system
requirements and identifying major transformations that will become programs in system
design. So it is the starting point of the design to the lowest level of detail. A DFD consists
of a series of bubbles joined by data flows in the system.


In the DFD, there are four symbols

1. A square defines a source(originator) or destination of system data

2. An arrow identifies data flow. It is the pipeline through which the information flows
3. A circle or a bubble represents a process that transforms incoming data flow into outgoing
data flows.
4. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow

S.K.T.R.M.C.E 17

Source or Destination of data

Data flow

Data Store


Several rules of thumb are used in drawing DFD’s:

1. Process should be named and numbered for an easy reference. Each name should be
representative of the process.
2. The direction of flow is from top to bottom and from left to right. Data traditionally flow
from source to the destination although they may flow back to the source. One way to
indicate this is to draw long flow line back to a source. An alternative way is to repeat the
source symbol as a destination. Since it is used more than once in the DFD it is marked
with a short diagonal.
3. When a process is exploded into lower level details, they are numbered.
4. The names of data stores and destinations are written in capital letters. Process and
dataflow names have the first letter of each work capitalized

A DFD typically shows the minimum contents of data store. Each data store should
contain all the data elements that flow in and out.

Questionnaires should contain all the data elements that flow in and out. Missing
interfaces redundancies and like is then accounted for often through interviews.

S.K.T.R.M.C.E 18


1. The DFD shows flow of data, not of control loops and decision are controlled
considerations do not appear on a DFD.
2. The DFD does not indicate the time factor involved in any process whether the
dataflow take place daily, weekly, monthly or yearly.
3. The sequence of events is not brought out on the DFD.


1. Current Physical
2. Current Logical
3. New Logical
4. New Physical


In Current Physical DFD process label include the name of people or their positions or the
names of computer systems that might provide some of the overall system-processing label
includes an identification of the technology used to process the data. Similarly data flows
and data stores are often labels with the names of the actual physical media on which data are
stored such as file folders, computer files, business forms or computer tapes.


S.K.T.R.M.C.E 19

The physical aspects at the system are removed as much as possible so that the current
system is reduced to its essence to the data and the processors that transform them regardless
of actual physical form.


This is exactly like a current logical model if the user were completely happy with the
user were completely happy with the functionality of the current system but had problems
with how it was implemented typically through the new logical model will differ from current
logical model while having additional functions, absolute function removal and inefficient
flows recognized.


The new physical represents only the physical implementation of the new system.


1) No process can have only outputs.
2) No process can have only inputs. If an object has only inputs than it must be a
3) A process has a verb phrase label.

S.K.T.R.M.C.E 20


1) Data cannot move directly from one data store to another data store, a process
must move data.
2) Data cannot move directly from an outside source to a data store, a process, which
receives, must move data from the source and place the data into data store
3) A data store has a noun phrase label.


The origin and /or destination of data

1) Data cannot move direly from a source to sink it must be moved by a process
2) A source and /or sink has a noun phrase land

1) A Data Flow has only one direction of flow between symbols. It may flow in both
directions between a process and a data store to show a read before an update.
The later is usually indicated however by two separate arrows since these happen
at different type.
2) A join in DFD means that exactly the same data comes from any of two or more
different processes data store or sink to a common location.
3) A data flow cannot go directly back to the same process it leads. There must be at
least one other process that handles the data flow produce some other data flow
returns the original data into the beginning process.
4) A Data flow to a data store means update (delete or change).
5) A data Flow from a data store means retrieve or use.
6) A data flow has a noun phrase label more than one data flow noun phrase can
appear on a single arrow as long as all of the flows on the same arrow move
together as one package.

S.K.T.R.M.C.E 21

Data Flow Diagrams:

Context level diagram:


0 level data flow diagram:



S.K.T.R.M.C.E 22



1st Level Diagram:


S.K.T.R.M.C.E 23

S.K.T.R.M.C.E 24


S.K.T.R.M.C.E 25


S.K.T.R.M.C.E 26

S.K.T.R.M.C.E 27


Unified Modeling Language is a standard language for writing software

blueprints. The UML is appropriate for modeling systems ranging from enterprise
information systems to distributed web-based applications and even to hard real
time embedded systems. The UML is a language for Visualizing, Specifying,
Constructing, Documenting the artifacts of a software-intensive system.

Building blocks of the UML:

The vocabulary of the system encompasses three kinds of building blocks:

1. Things
2. Relationships
3. Diagrams


1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

Structural things:

Structural things are the nouns of UML models. These are the mostly static
parts of a model, representing elements that are either conceptual or physical. In
all 7 kinds of structural things

S.K.T.R.M.C.E 28


Class is a description of a set of objects that share the same attributes.

Operations, relationships and semantics .A class implements one or more
interfaces. Graphically, Class is rendered as a rectangle, usually including its
name, attributes and operations.




Is a collection of operations that specify a service of a class or component

.It describe the externally visible behavior of that element .An interface might
represent the complete behavior of a class or component or only a part of that
behavior .Graphically an interface is rendered as a circle together with its name
.An interface rarely stand alone, it is typically attached to a class or component
but realizes the interface.



It defines an interaction and is a society of roles and other elements that

work together to provide some cooperative behavior that’s bigger than the sum of
all the elements .Therefore, collaborations have a structural as well as behavioral
dimension. Graphically collaboration is rendered as an ellipse with dashed lines,
usually including only its name.

S.K.T.R.M.C.E 29

Use Case:

Is a description of set of sequences of action that a system performs that

yields an observable result of value to a particular actor .A use case is used to
structure the behavioral things in a model .Graphically a use case is rendered as an
ellipse with solid lines usually including its name.

Active Class:

Active class is a class whose objects own one or more processes or threads
and therefore can initiate control activity .An active class is just like a class
except that its objects represent elements whose behavior is concurrent with other
elements .Graphically an active class is rendered just like a class, but with heavy
lines, usually including its name, attributes and operations.




A component is a physical and replaceable part of a system that conforms to

and provides the realization of a set of interfaces .A component typically
represents the physical packaging of otherwise logical elements, such as class,
interfaces and collaborations .Graphically a component is rendered as a rectangle
with tabs, usually including only its name.

S.K.T.R.M.C.E 30


A node is a physical element that exists at run time and represents a

computational resource, generally having at least some memory and may often
processing capability .A set of components may reside on a node and may also
migrate from node to node .Graphically a node is rendered as a cube usually
including only its name.


Behavioral Things:

Behavioral things are the dynamic parts if the UML models .These are the
verbs of a model, representing behavior over time and space .In all there are two
primary kinds of behavioral things


An interaction is a behavior that comprises a set of messages exchanged

among a set of objects within a particular context to accomplish a specific purpose
.An interaction involves a number of other elements, including messages, action
sequences and links .Graphically a message is a rendered as a directed line, almost
including the name of its operation.

State machine:

A state machine is a behavior of that specific the sequence of states an

objects or an interaction goes through during its lifetime in response to events,
together with its responses to those events. A state machine involves a number of

S.K.T.R.M.C.E 31

other elements, including states, transitions and events. Graphically a state is

rendered as a rounded rectangle usually including its name and its sub states.

Grouping Things:

Grouping things are the organizational parts of UML models .These are the
boxes into which a model can be decomposed .In all there is one primary kind of
grouping thing namely packages.


A package is a general-purpose mechanism for organizing elements into

group’s .Structural things, behavioral things and even other grouping things may
be placed in a package .Graphically a package is rendered as a tabbed folder
usually including only its name and sometimes its contents.

busines s rules

Annotational Things:

Annotational things are the explanatory parts of UML model .These are the
comments we apply to describe, illuminate and remark about any elements in a
model .There is one primary kind of annotational thing called a note.


A note is simply a symbol for rendering constraints and comments attached

to an element or a collection of elements .Graphically a note is rendered as a
rectangle with a dog-eared corner together with textual or graphical comments.

S.K.T.R.M.C.E 32

Relationships in the UML:

There are four kinds of relationships in the UML

1. Dependency
2. Association
3. Generalization
4. Realization


A dependency is a semantic relationship between two things in which a

change to one thing may affect the semantics of the other thing .Graphically a
dependency is rendered as a dashed line possibly directed and occasionally

a label.


A association is a structural relationship that describes a set of links, a link

being a connection among objects .Aggregation is a special kind of association
representing a structural relationship between a whole and its parts .Graphically an
association is rendered as a solid line possibly directed occasionally including a
label and often containing other adornments such as multiplicity and role names.

S.K.T.R.M.C.E 33


A generalization is a specialization/generalization relationship in which

objects of the specialized element are substitutable for objects of the general
element .In this way the child shares the structure and the behavior of the
parent .Graphically a generalization relationship is rendered as a solid line with a
hallow arrowed pointing to the parent.


A realization is a semantic relationship between classifiers, where in one

classifier specifies that another classifier guarantees to carry out .Graphically a
realization relationship is rendered as a cross between a generalization and a
dependency relationship.

S.K.T.R.M.C.E 34

S.K.T.R.M.C.E 35

Diagrams in UML:

A diagram is the graphical presentation of a set of elements most often rendered as a

connected graph of vertices and arcs .UML includes nine diagrams.

1. Class diagrams

2. Object diagrams

3. Use case diagrams

4. Sequence diagrams

5. Collaboration diagrams

6. State chart diagrams

7. Activity diagrams

8. Component diagrams

9. Deployment diagrams

Use Case Diagrams:

A use case diagram shows a set of use cases and actors and their relationships. Use
case diagram address the static use case view of a system .These diagrams are especially
important in organizing and modeling the behavior of a system.

Use case diagram for EMPLOYEE:

S.K.T.R.M.C.E 36

Use case diagram for ADMINISTRATOR:

S.K.T.R.M.C.E 37

S.K.T.R.M.C.E 38

Interaction diagrams:

An interaction diagram shows an interaction, consisting of a set of objects and their

relationships, including the messages that may be dispatched among them. Interaction
diagrams address the dynamic view of a system.

Sequence diagrams & Collaboration diagrams:

A sequence diagram is an interaction diagram that emphasizes the time ordering of

messages ,a collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages .Sequence diagram and
collaboration diagrams are isomorphic ,meaning that you can take one and transform it into
the other.

S.K.T.R.M.C.E 39

Sequence diagram for EMPLOYEE:

Sequence diagram of ADMINISTRATOR:

S.K.T.R.M.C.E 40

Collaboration diagram for EMPLOYEE:

S.K.T.R.M.C.E 41

S.K.T.R.M.C.E 42

Collaboration diagram for ADMINISTRATOR:


Implementation is the process of having systems personnel check out and put new
equipment into use, train users, install the new app depending on the size of the organization

S.K.T.R.M.C.E 43

that will be involved in using the application and the risk associated with its use, system
developers may choose to test the operation in only one area of the firm, say in one
department or with only one or two persons. Sometimes they will run old and new systems
together to compare the results. In still other situation, developers will stop using the old
system one day and begin using the new one the next. As it is seen that each implementation
strategy has its merits, depending on the business situation in which it is considered.
Regardless of the implementation strategy used, developers strive to ensure that the system’s
initial use in trouble free.

Once installed, applications are often used for many years. However, both the
organization and the users will change, and the environment will be different over weeks and
months. Therefore, the application will undoubtedly have to be maintained; modifications
and changes will be made to the software, files, or procedures to meet emerging user
requirements. Since organization systems and the business environment undergo continual
change, the information systems should keep space. In this sense, implementation is ongoing

S.K.T.R.M.C.E 44


C# is a language designed to be fully compatible with Microsoft's .NET initiative
while taking advantage of what has been learned from C and C++ (as well as Java).

C# is designed to be a platform-independent language in the tradition of Java. Its

syntax is similar to C and C++ syntax, and C# is designed to be an object-oriented language.
There are, for the most part, minor variations in syntax between C++ and C#. Main has no
return type, there are no semicolons after class names, there are some (to C++ programmers)
strange decisions regarding capitalization - such as the capitalisation of Main. Other a few
differences, the syntax is often the same. This decision is reasonable, in light of the fact that
C syntax has been used with several other languages - notably Java.

Similar to Java, C# does not support multiple inheritances; instead it provides Java's
solution: interfaces. Interfaces implemented by a class specify certain functions that the class
is guaranteed to implement. Interfaces avoid the messy dangers of multiple inheritances while
maintaining the ability to let several classes implement the same set of methods.

The potential for C# is great if the .NET platform succeeds. C# is designed to take
advantage of the design of .NET, and Microsoft has poured a great deal of money into .NET.


Microsoft .NET (pronounced “dot net”) is a software component that runs on the
Windows operating system. .NET provides tools and libraries that enable developers to create
Windows software much faster and easier. .NET benefits end-users by providing application

S.K.T.R.M.C.E 45

of higher capability, quality and security. The .NET Framework must be installed on a user’s
PC to run .NET applications.

This is how Microsoft describes it: “.NET is the Microsoft Web services strategy to
connect information, people, systems, and devices through software. Integrated across the
Microsoft platform, .NET technology provides the ability to quickly build, deploy, manage,
and use connected, security-enhanced solutions with Web services. .NET-connected solutions
enable businesses to integrate their systems more rapidly and in a more agile manner and help
them to realize the promise of information anytime, anywhere, on any device.”


 The Framework is Multilanguage and Extensible

 Runtimes are nothing new for programming languages. The critical role of the
runtime in the .NET Framework (and what really sets it apart) is that it provides a
unified environment across all programming languages.
 The base classes of the .NET Framework (provided within the Base Class Library or
BCL) provide a unified, object-oriented, hierarchical, extensible set of class libraries
for developers to use. Today, as a developer using C++ you might use the Microsoft
Foundation Classes (MFC), as a Java developer, you might use the Windows
Foundation Classes (WFC), and as a Visual Basic® developer you would use Visual
Basic APIs.
 The .NET Framework unifies the disparate frameworks that you need to work with
today. As a result, you no longer have to learn multiple frameworks to do your work.
As a component developer you don’t have to decide what language to target, as you
can simply target the CLR, knowing that your work will be accessible from all
 Cross-Language Interoperability
 Among the many strengths of .NET is language transparency. Whichever managed
language you choose, you have equal access to the platform. By creating a common
set of APIs across all programming languages, the .NET Framework enables cross-
language inheritance, error handling, and debugging. As a developer, you can take
advantage of the .NET platform using your preferred language.
 Multi-Platform Design

S.K.T.R.M.C.E 46

 .NET represents a new way of developing software for Windows and potentially other
platforms. .NET is not inextricably tied to the Windows operating system. For
example, the intermediate code (MSIL) generated by .NET language compilers, is not
processor specific and the BCL classes are designed to work on any operating system.
 .NET’s Base Class Library (BCL)
 The .NET Framework Base Class Library (BCL) are a huge collection of managed
code classes that tightly integrate with the common language runtime. One of the
main advantages of the .NET base classes is that they have been designed to be easy
to use and to be virtually self-documenting. The classes are also organized into
 As you would expect from an object-oriented class library, the .NET Framework
types enable you to accomplish a range of common programming tasks, including
tasks such as string management, data collection, database connectivity, and file
access. In addition to these common tasks, the class library includes types that support
a variety of specialized development scenarios. For example, you can use the .NET
Framework to develop the following types of applications and services:
 Console applications.
 Scripted or hosted applications.
 Windows GUI applications (Windows Forms).
 ASP.NET applications.
 XML Web services.
 Windows services.


A database management system (DBMS) is computer software designed for the

purpose of managing databases, a large set of structured data, and run operations on the data

requested by numerous users. Typical examples of DBMSs include Oracle, DB2, Microsoft
Access, Microsoft SQL Server, My SQL, FileMaker and Sybase Adaptive Server Enterprise.
DBMSs are typically used by Database administrators in the creation of Database systems.
Typical examples of DBMS use include accounting, human resources and customer support

S.K.T.R.M.C.E 47

Originally found only in large companies with the computer hardware needed to
support large data sets, DBMSs have more recently emerged as a fairly standard part of any
company back office.


A DBMS is a complex set of software programs that controls the organization,

storage, management, and retrieval of data in a database. A DBMS includes:

 A modeling language to define the schema of each database hosted in the DBMS,
according to the DBMS data model.

• The four most common types oforganizations are the hierarchical, network,
relational and object models. Inverted lists and other methods are also used. A
given database management system may provide one or more of the four models.
• The optimal structure depends on the natural organization of the application's
• And optimal structure depends on the application's requirements (which include
transaction rate (speed), reliability, maintainability, scalability, and cost).
• The dominant model in use today is the ad hoc one embedded in SQL, despite the
objections of purists who believe this model is a corruption of the relational
model, since it violates several of its fundamental principles for the sake of
practicality and performance. Many DBMSs also support the Open Database
Connectivity API that supports a standard way for programmers to access the

 Data structures (fields, records, files and objects) optimized to deal with very large
amounts of data stored on a permanent data storage device (which implies relatively
slow access compared to volatile main memory)
 A database query language and report writer to allow users to interactively interrogate
the database, analyze its data and update it according to the users privileges on data.

• It also controls the security of the database.

• Data security prevents unauthorized users from viewing or updating the database.
Using passwords, users are allowed access to the entire database or subsets of it

S.K.T.R.M.C.E 48

called sub schemas. For example, an employee database can contain all the data
about an individual employee, but one group of users may be authorized to view
only payroll data, while others are allowed access to only work history and
medical data.
• If the DBMS provides a way to interactively enter and update the database, as
well as interrogate it, this capability allows for managing personal databases.
However, it may not leave an audit trail of actions or provide the kinds of controls
necessary in a multi-user organization. These controls are only available when a
set of application programs are customized for each data entry and updating

 A transaction mechanism, that ideally would guarantee the ACID properties, in order
to ensure data integrity, despite concurrent user accesses (concurrency control), and

• It also maintains the integrity of the data in the database.

• The DBMS can maintain the integrity of the database by not allowing more than
one user to update the same record at the same time.

The DBMS can help prevent duplicate records via unique index constraints: ACID
properties for more information (Redundancy avoidance).

The DBMS accepts requests for data from the application program and instructs the
operating system to transfer the appropriate data.

When a DBMS is used, information systems can be changed much more easily as the
organization's information requirements change. New categories of data can be added to the
database without disruption to the existing system.

Organizations may use one kind of DBMS for daily transaction processing and then
move the detail onto another computer that uses another DBMS better suited for random
inquiries and analysis. Overall systems design decisions are performed by data administrators
and systems analysts. Detailed database design is performed by database administrators.

S.K.T.R.M.C.E 49

Database servers are specially designed computers that hold the actual databases and
run only the DBMS and related software. Database servers are usually multiprocessor
computers, with RAID disk arrays used for stable storage. Connected to one or more servers
via a high-speed channel, hardware database accelerators are also used in large volume
transaction processing environments.

DBMSs are found at the heart of most database applications. Sometimes DBMSs are
built around a private multitasking kernel with built-in networking support although
nowadays these functions are left to the operating system.


Structured Query Language (SQL) is the language used to manipulate relational

databases. SQL is tied very closely with the relational model.

In the relational model, data is stored in structures called relations or tables.

SQL statements are issued for the purpose of:

Data definition: Defining tables and structures in the database (DDL used to create, alter and
drop schema objects such as tables and indexes).

Data manipulation: Used to manipulate the data within those schema objects (DML
Inserting, Updating, Deleting the data, and Querying the Database).

A schema is a collection of database objects that can include: tables, views, indexes and

List of SQL statements that can be issued against an Oracle database schema are:

• ALTER - Change an existing table, view or index definition (DDL)

S.K.T.R.M.C.E 50

• AUDIT - Track the changes made to a table (DDL)

• COMMENT - Add a comment to a table or column in a table (DDL)
• COMMIT - Make all recent changes permanent (DML - transactional)
• CREATE - Create new database objects such as tables or views (DDL)
• DELETE - Delete rows from a database table (DML)
• DROP - Drop a database object such as a table, view or index (DDL)
• GRANT - Allow another user to access database objects such as tables
• INSERT - Insert new data into a database table (DML)
• No AUDIT - Turn off the auditing function (DDL)
• REVOKE - Disallow a user access to database objects such as tables and
• ROLLBACK - Undo any recent changes to the database (DML -
• SELECT - Retrieve data from a database table (DML)
• TRUNCATE - Delete all rows from a database table (cannot be rolled back)
• UPDATE - Change the values of some data items in a database table (DML)

HTML, an initial of Hyper Text Markup Language, is the predominant markup
language for web pages. It provides a means to describe the structure of text-based
information in a document — by denoting certain text as headings, paragraphs, lists, and so
on — and to supplement that text with interactive forms, embedded images, and other
objects. HTML is written in the form of labels (known as tags), surrounded by angle brackets.
HTML can also describe, to some degree, the appearance and semantics of a document, and
can include embedded scripting language code which can affect the behavior of web
browsers and other HTML processors.

HTML is also often used to refer to content of the MIME type text/html or even more
broadly as a generic term for HTML whether in its XML-descended form (such as XHTML
1.0 and later) or its form descended directly from SGML.

S.K.T.R.M.C.E 51

Hypertext Markup Language (HTML), the languages of the World Wide Web
(WWW), allows users to produces Web pages that include text, graphics and pointer to other
Web pages (Hyperlinks).

HTML is not a programming language but it is an application of ISO Standard 8879,

SGML (Standard Generalized Markup Language), but specialized to hypertext and adapted to
the Web. The idea behind Hypertext is that instead of reading text in rigid linear structure, we
can easily jump from one point to another point. We can navigate through the information
based on our interest and preference. A markup language is simply a series of elements, each
delimited with special characters that define how text or other items enclosed within the
elements should be displayed. Hyperlinks are underlined or emphasized works that load to
other documents or some portions of the same document.

HTML provides tags (special codes) to make the document look attractive. HTML
tags are not case-sensitive. Using graphics, fonts, different sizes, color, etc., can enhance the
presentation of the document. Anything that is not a tag is part of the document itself.

Basic HTML Tags:

<! -- --> specifies comments

<A>……….</A> Creates hypertext links

<B>……….</B> Formats text as bold

<BIG>……….</BIG> Formats text in large font.

<BODY>…</BODY> Contains all tags and text in the HTML document

<CENTER>...</CENTER> Creates text

<DD>…</DD> Definition of a term

<DL>...</DL> Creates definition list

<FONT>…</FONT> Formats text with a particular font

S.K.T.R.M.C.E 52

<FORM>...</FORM> Encloses a fill-out form

<FRAME>...</FRAME> Defines a particular frame in a set of frames

<H#>…</H#> Creates headings of different levels (1-6)

<HEAD>...</HEAD> Contains tags that specify information about a document

<HR>...</HR> Creates a horizontal rule

<HTML>…</HTML> Contains all other HTML tags

<META>...</META> Provides meta-information about a document

<SCRIPT>…</SCRIPT> Contains client-side or server-side script

<TABLE>…</TABLE> Creates a table

<TD>…</TD> Indicates table data in a table

<TR>…</TR> Designates a table row

<TH>…</TH> Creates a heading in a table.


The attributes of an element are name-value pairs, separated by "=", and written
within the start label of an element, after the element's name. The value should be enclosed in
single or double quotes, although values consisting of certain characters can be left unquoted
in HTML (but not XHTML).Leaving attribute values unquoted is considered unsafe.

Most elements take any of several common attributes: id, class, style and title. Most
also take language-related attributes: Lang and dir.

The id attribute provides a document-wide unique identifier for an element. This can
be used by style sheets to provide presentational properties, by browsers to focus attention on
the specific element or by scripts to alter the contents or presentation of an element. The class
attribute provides a way of classifying similar elements for presentation purposes. For

S.K.T.R.M.C.E 53

example, an HTML document (or a set of documents) may use the designation
class="notation" to indicate that all elements with this class value are all subordinate to the
main text of the document (or documents). Such notation classes of elements might be
gathered together and presented as footnotes on a page, rather than appearing in the place
where they appear in the source HTML.

An author may use the style non-attribute codes presentational properties to a

particular element. It is considered better practice to use an element’s son- id page and select
the element with a style sheet, though sometimes this can be too cumbersome for a simple ad
hoc application of styled properties. The title is used to attach sub textual explanation to an
element. In most browsers this title attribute is displayed as what is often referred to as a
tooltip. The generic inline span element can be used to demonstrate these various non-


 A HTML document is small and hence easy to send over the net. It is small
because it does not include formatted information.
 HTML is platform independent.
 HTML tags are not case-sensitive




S.K.T.R.M.C.E 54

S.K.T.R.M.C.E 55



S.K.T.R.M.C.E 56



S.K.T.R.M.C.E 57


S.K.T.R.M.C.E 58


S.K.T.R.M.C.E 59



S.K.T.R.M.C.E 60

S.K.T.R.M.C.E 61



S.K.T.R.M.C.E 62


S.K.T.R.M.C.E 63



S.K.T.R.M.C.E 64


S.K.T.R.M.C.E 65


S.K.T.R.M.C.E 66



S.K.T.R.M.C.E 67

S.K.T.R.M.C.E 68


The separation of debugging from testing was initially introduced by Glen ford J.
Myers in his 1978 book the "Art of Software Testing". Although his attention was on
breakage testing it illustrated the desire of the software engineering community to separate
fundamental development activities, such as debugging, from that of verification. Drs. Dave
Gelperin and William C. Hetzel classified in 1988 the phases and goals in software testing as
follows: until 1956 it was the debugging oriented period, where testing was often associated
to debugging: there was no clear difference between testing and debugging. From 1957-1978
there was the demonstration oriented period where debugging and testing was distinguished
now - in this period it was shown, that software satisfies the requirements. The time between
1979-1982 is announced as the destruction oriented period, where the goal was to find errors.
1983-1987 is classified as the evaluation oriented period: intention here is that during the
software lifecycle a product evaluation is provided and measuring quality. From 1988 on it
was seen as prevention oriented period where tests were to demonstrate that software satisfies
its specification, to detect faults and to prevent faults. Dr. Gelperin chaired the IEEE 829-
1988 (Test Documentation Standard) with Dr. Hetzel writing the book "The Complete Guide
of Software Testing". Both works were pivotal in to today's testing culture and remain a
consistent source of reference. Dr. Gelperin and Jerry E. Durant also went on to develop High
Impact Inspection Technology that builds upon traditional Inspections but utilizes a test
driven additive.

What is testing?

S.K.T.R.M.C.E 69

The primary purpose of testing is to detect flaws in the quality and the functionality of
an application relative to the specifications determined during the specifications and design
phases. Testing should be a high priority in the development process for the following

• Reducing development costs. Defects in a program cost many times more to fix after
the program is deployed than they do while it is still in development.
• Predictability. A program that behaves as expected (deterministic) is more desirable
than one that is unpredictable (non-deterministic) in behavior.
• Reducing the total cost of ownership. Customers require less training and support
when an application works as described in the specification and documentation.
• Quality. There will be bugs in any sizeable project. Only through thorough testing can
the quality of a product reach a level that will be acceptable and build trust with the
users of the program.

What is a test case?

“A test case has components that describe an input, action or event and an expected
response, to determine if a feature of an application is working correctly.”

The basic objective of writing test cases is to validate the testing coverage of the
application. If you are working in any CMMI company then you will strictly follow test
cases standards. So writing test cases brings some sort of standardization and minimizes the
ad-hoc approach in testing.

Test Case Format:

Test case id :
Unit to test : What to be verified?
Assumptions :
Test data : Variables and their values
Steps to be executed :
Expected result :

S.K.T.R.M.C.E 70

Actual result :

Basic format of test case statement:

Using [tool name, tag name, dialog, etc]
With [conditions]
To [what is returned, shown, demonstrated]

Verify: Used as the first word of the test case statement.

Using: To identify what is being tested. You can use ‘entering’ or ‘selecting’ here instead of
using depending on the situation.

Our Application has been tested successfully so far with the Mircrosoft’s Software
IDE Visual Studio 2008. It has the tools needed for testing and includes the test Project to
verify and validat all the fields of the software. It presents all the information regarding
testing .

White-box and black-box testing:

White box and black box testing are terms used to describe the point of view a test
engineer takes when designing test cases. Black box being an external view of the test object
and white box is an internal view. Software testing is partly intuitive, but largely systematic.
Good testing involves much more than just running the program a few times to see whether it
works. Thorough analysis of the program under test, backed by a broad knowledge of testing
techniques and tools are prerequisites to systematic testing. Software Testing is the process of
executing software in a controlled manner; in order to answer the question “Does this
software behave as specified?” Software testing is used in association with Verification and
Validation. Verification is the checking of or testing of items, including software, for
conformance and consistency with an associated specification. Software testing is just one
kind of verification, which also uses techniques as reviews, inspections, walk-through.

S.K.T.R.M.C.E 71

Validation is the process of checking what has been specified is what the user actually

• Validation: Are we doing the right job?

• Verification: Are we doing the job right?

In order to achieve consistency in the Testing style, it is imperative to have and follow a
set of testing principles. This enhances the efficiency of testing within SQA team members
and thus contributes to increased productivity. The purpose of this document is to provide
overview of the testing, plus the techniques.
At SDEI, 3 levels of software testing are done at various SDLC phases:
• Unit Testing: in which each unit (basic component) of the software is tested to verify
that the detailed design for the unit has been correctly implemented
• Integration testing: in which progressively larger groups of tested software
components corresponding to elements of the architectural design are integrated and
tested until the software works as a whole.
• System testing: in which the software is integrated to the overall product and tested to
show that all requirements are met.

A further level of testing is also done, in accordance with requirements:

• Acceptance testing: upon which the acceptance of the complete software is based. The
clients often do this.
• Regression testing: is used to refer the repetition of the earlier successful tests to
ensure that changes made in the software have not introduced new bugs/side effects.
• In recent years the term grey box testing has come into common usage. The typical
grey box tester is permitted to set up or manipulate the testing environment, like
seeding a database, and can view the state of the product after his actions, like
performing a SQL query on the database to be certain of the values of columns. It is
used almost exclusively of client-server testers or others who use a database as a
repository of information, but can also apply to a tester who has to manipulate XML
files (DTD or an actual XML file) or configuration files directly. It can also be used
of testers who know the internal workings or algorithm of the software under test and
can write tests specifically for the anticipated results.

S.K.T.R.M.C.E 72

Test levels

• Unit testing tests the minimal software component and sub-component or modules by
the programmers.
• Integration testing exposes defects in the interfaces and interaction between integrated
components (modules).
• Functional testing tests the product according to programmable work.
• System testing tests an integrated system to verify/validate that it meets its
• Acceptance testing can be conducted by the client. It allows the end-user or customer
or client to decide whether or not to accept the product. Acceptance testing may be
performed after the testing and before the implementation phase.
• Alpha testing is simulated or actual operational testing by potential users/customers or
an independent test team at the developers' site. Alpha testing is often employed for
off-the-shelf software as a form of internal acceptance testing, before the software
goes to beta testing.

• Beta testing comes after alpha testing. Versions of the software, known as beta
versions, are released to a limited audience outside of the company. faults or bugs.
• Sometimes, beta versions are made available to the open public to increase the
feedback field to a maximal number of future users.

It should be noted that although both Alpha and Beta are referred to as testing it is in fact
use emersion. The rigors that are applied are often unsystematic and many of the basic tenets
of testing process are not used. The Alpha and Beta period provides insight into
environmental and utilization conditions that can impact the software.

After modifying software, either for a change in functionality or to fix defects, a

regression test re-runs previously passing tests on the modified software to ensure that the
modifications haven't unintentionally caused a regression of previous functionality.
Regression testing can be performed at any or all of the above test levels. These regression
tests are often automated.

S.K.T.R.M.C.E 73

Test cases, suites, scripts and scenarios:

A test case is a software testing document, which consists of event, action, input,
output, expected result and actual result. Clinically defined (IEEE 829-1998) a test case is an
input and an expected result. This can be as pragmatic as 'for condition x your derived result
is y', whereas other test cases described in more detail the input scenario and what results
might be expected. It can occasionally be a series of steps (but often steps are contained in a
separate test procedure that can be exercised against multiple test cases, as a matter of
economy) but with one expected result or expected outcome. The optional fields are a test
case ID, test step or order of execution number, related requirement(s), depth, test category,
author, and check boxes for whether the test is automatable and has been automated. Larger
test cases may also contain prerequisite states or steps, and descriptions. A test case should
also contain a place for the actual result. These steps can be stored in a word processor
document, spreadsheet, database or other common repository. In a database system, you may
also be able to see past test results and who generated the results and the system configuration
used to generate those results. These past results would usually be stored in a separate table.

The term test script is the combination of a test case, test procedure and test data.
Initially the term was derived from the byproduct of work created by automated regression
test tools. Today, test scripts can be manual, automated or a combination of both.

The most common term for a collection of test cases is a test suite. The test suite often
also contains more detailed instructions or goals for each collection of test cases. It definitely
contains a section where the tester identifies the system configuration used during testing.

A group of test cases may also contain prerequisite states or steps, and descriptions of
the following tests.

Collections of test cases are sometimes incorrectly termed a test plan. They might
correctly be called a test specification. If sequence is specified, it can be called a test script,
scenario or procedure.

S.K.T.R.M.C.E 74

A sample testing cycle:

Although testing varies between organizations, there is a cycle to testing:

1. Requirements Analysis: Testing should begin in the requirements phase of the
software development life cycle.

During the design phase, testers work with developers in determining what aspects of
a design are testable and under what parameter those tests work.

2. Test Planning: Test Strategy, Test Plan(s), Test Bed creation.

3. Test Development: Test Procedures, Test Scenarios, Test Cases, Test Scripts to use
in testing software.
4. Test Execution: Testers execute the software based on the plans and tests and report
any errors found to the development team.
5. Test Reporting: Once testing is completed, testers generate metrics and make final
reports on their test effort and whether or not the software tested is ready for release.
6. Retesting the Defects

Not all errors or defects reported must be fixed by a software development team.
Some may be caused by errors in configuring the test software to match the development or
production environment. Some defects can be handled by a workaround in the production
environment. Others might be deferred to future releases of the software, or the deficiency
might be accepted by the business user.


S.K.T.R.M.C.E 75



Limitations of the system:

• Every employee has the access right for only viewing.

• System works in all platforms and its compatible environments.
• Advanced techniques are not used to check the authorization.

Future Enhancements:
It is not possible to develop a system that makes all the requirements of the user. User
requirements keep changing as the system is being used. Some of the future enhancements
that can be done to this system are:

• As the technology emerges, it is possible to upgrade the system and can be adaptable
to desired environment.
• Because it is based on object-oriented design, any further changes can be easily
• Based on the future security issues, security can be improved using emerging

S.K.T.R.M.C.E 76


The Employee Payroll System has been developed in order to automate the existing
system. It also includes the employee personal details

This application software has been computed successfully and was also tested
successfully by taking “test cases”. It is user friendly, and has required options, which can be
utilized by the user to perform the desired operations.

The software is developed using .NET as front end and Oracle as back end in
Windows environment. The goals that are achieved by the software are:

 Instant access.
 Improved productivity.
 Optimum utilization of resources.
 Efficient management of records.
 Simplification of the operations.
 Less processing time to get required information.
 User friendly.

S.K.T.R.M.C.E 77

 Portable and flexible for further enhancement.

During course of this project, a number of books, projects and websites were referred.
Some of them are as listed as follows:

1. Software Engineering

Author - RS Pressman

2. Programming Language
MICROSOFT VISUAL C# step by step

S.K.T.R.M.C.E 78

Morgan Kaufmann C sharp

Balaguruswamy C#
C# .NET Web developers guide

3. Unified Modeling Language

Author - Grady Booch

- James Rumbaugh

Publishing - Pearson Education

4. Data Base Management System

Author - C.J. Date

5. Web Programming:

Author - Chris Bates



S.K.T.R.M.C.E 79