1.

PROJECT PLANNING
1.1 PLANNING PROCESS
The key to the successful project is the planning process or phase. Creating a
project plan is the initial phase for undertaking any kind of project. Writing the planning
phase for project provides a structured framework

about how the project will be

conducted.
1.2 PROJECT GOALS
The goal of the Telephone dictionary system is to display the telephone no with
code, name of the person and residential address of the person.
The people involved in this project are
Telephone administrator
User
a.) Telephone administrator
The person who is having authority or responsible for any operation such as
updation , addition, deletion of the database.
b.) User
The person who are in need of other persons details such as name, address and
telephone number. The Telephone dictionary system is used to analyse the other persons
details and view the name, address, telephone number.
1.3 PROJECT DELIVERABLES:
The deliverables of the Telephone directory Application include the following

Application

Documentation :

This is the main product that is to be delivered to the client.

This includes the user manual given to the user and the code

documentation made available to developers and the user.

Source Code

Since this is an Open Source project, the source code is provided to

the user.

Create a list of things that the project needs to deliver in order to meet the specified
goals.
The deliverables of Telephone dictionary system are
Administrator
The person who have right authority to update, add, delete new or old persons
details.
User
The person who has the right to view only the persons telephone number,

address

and name.

1.4 PROJECT SCHEDULE

Create a list of tasks or activities that need to be carried out for each deliverables
identified in project deliverables. The modules of Telephone dictionary system is

Authentication
Add an entry
Remove an entry
Look up
Change the phone number in entry
List all entries.

a.) Authentication
This module is mainly for signing in to have the authority of viewing the person
details. This is done by giving user id and password.
b.) Add an entry
The administrator have the right authority to add the new person details such as
name, telephone number and residential address.

c.) Remove an entry

The administrator can delete the specified persons details and update the database.
d.) Look up
The user or administrator can view the address of the person by entering the
telephone number.
e.) Change the phone number in entry
The administrator is responsible for changing the phone number in database.
f.) List all entries.
The user or administrator can view all the details of the person such as name,
telephone number and address.
1.5 GNATT CHART

1.6 SUPPORTING PLANS

a.) RISK MANAGEMENT
Risk management is very important in identifying many risks during the project
development. The main factors involved is time, cost, resources, team members etc.
Time and cost are too optimistic.
Unexpected budget constraint.
Lack of resources involved.

 Poor communication team members.

These factors may result in misunderstandings, poor quality software product,
high degree of lacking concentration towards development of objectives or goals
specified in project.

2. SOFTWARE REQUIREMENT ANALYSIS

2.1 Introduction
2.1.1 Product Overview:
The telephone dictionary system is used to display the telephone no with codename of the subscriber, the residential address of the subscriber accounting to country,
state and district wise. This information are displayed by having any one of the
information.
2.1.2 Purpose
The propose of this document is to illustrate ;the requirement of the requirement
of the project . It gives detailed description of both functional and non-functional
requirement given by the client.
The document is constructed after many consultations with the client consultation
with the client considering complete requirement specification.
2.1.3 Scope:
a) Product Characteristics and Requirements:
1. Secured database system
2. Answering
3. Calculating the goals.
4. Viewing the information.
b) Project Management Deliverables:
1. Project Plan.
2. Work Breakdown Structure.
3. Scope Statement.
4. Project character etc.

c) Product Related deliverables:

1. Design Document
2. Software code & hardware
3. Test plan
4. Project benefits measurement plan, etc
d) Project Success Criteria:
1. The main goal of the project is to complete within allotted time deadline & within
the budget
2. It is necessary to develop a method for obtaining the benefit while the telephone
dictionary system is being developed & tested.
2.1.4 References:
1. www.google.co.in
2. www.yahoo.com
3. www.scribd.com
2.1.5 Definition and Abbreviation
The following are the definition and Abbreviation of the term used in the project is
Admin: administrator in the controller of the system.
User: user of the system.
System: the whole functionality of the project implemented.
2 .2 Overall Descriptions
2.2.1 Product Perspective
The system provides search functionality to facilitate the search of the telephone
no, name& address of the person.
The admin has the full fledged rights of the system.
Datas in the System are self contained and independent.

2.2.2 Project Function

These are two different persons will be using this project

Admin

User

The following are the functions for the administrator, update, add, Delete.
The following are the functions the user,
He/She has the rights to view the information no alteration can be made.
2.2.3 User Characteristics
There are various kinds of user for the product.
Usually web products are visited (or) viewed by various users for different
reasons.
They include
User-who is using the product to view the information through online,.
Admin-who is acting as the controller of the project.
2.2.4 General Constraints.
The admin entering into the system must use the correct id and password.
The information stored in the database are correct i.e., the telephone no, name,
address of the person.
2.2.5 Assumptions and Dependencies
The admin should have sufficient knowledge about how to use the system.
The user must know the English, as the interface is English.
2.3. Specific Requirements
2.3.1 External Interface Requirements
This part describes how the software interacts with other software products.

2.3.2 User Interfaces

The design (or) layout of the form will be clear and consistent.
This describes the graphical user interface.
It should include a set of screen dumps to illustrate user interface features.
2.3.3 Hardware Requirements
Operating system : Windows XP
Processor : Pentium 3.0 or higher
RAM : 2 GB
2.3.4 Software Requirements
Database : Microsoft Access
Application : Microsoft Visual Basic 6.0
2.3.5 Memory Requirements
There is no specific limit on the usage of memory.
2.3.6 Software product features
The product features is more (or) less similar to product perspective. The
important features include,
The admin is allowed to update, add, delete (or) view the information.
The user is allowed only to view the information by searching it.

4. SOFTWARE ESTIMATION

The ability to accurately estimate the time and/or cost taken for a project to come
in to its successful conclusion is a serious problem for software engineers. The use of a
repeatable, clearly defined and well understood software development process has, in
recent years, shown itself to be the most effective method of gaining useful historical
data that can be used for statistical estimation. In particular, the act of sampling more
frequently, coupled with the loosening of constraints between parts of a project, has
allowed more accurate estimation and more rapid development times.

Popular methods for estimation in software engineering include:

Parametric Estimating

Wideband Delphi

COCOMO

SLIM

SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk. Mimimum

time and staffing concepts based on Brooks's law

Function Point Analysis

Proxy-based estimating (PROBE) (from the Personal Software Process)

The Planning Game (from Extreme Programming)

Program Evaluation and Review Technique (PERT)

Analysis Effort method

A PRICE Systems Founders of Commercial Parametric model that estimates the

scope, cost, effort and schedule for software projects.

Evidence-based Scheduling Refinement of typical agile estimating techniques

using minimal measurement and total time accounting.

The estimation of cost in the Dictionary application is performed using the basic
COCOMO (The Constructive Cost Model) model.
Basic COCOMO computes software development effort (and cost) as a function
of program size. Program size is expressed in estimated thousands of lines of code
(KLOC).
COCOMO applies to three classes of software projects:
1. Organic projects - "small" teams with "good" experience working with "less
than rigid" requirements
2. Semi-detached projects - "medium" teams with mixed experience working
with a mix of rigid and less than rigid requirements
3. Embedded projects - developed within a set of "tight" constraints (hardware,
software, operational, ...)
This model uses three sets of {a, b} depending on the complexity of the software only:
i.

For simple, well-understood applications, a = 2.4, b = 1.05;

ii.

For more complex systems, a = 3.0, b = 1.15;

iii.

For embedded systems, a = 3.6, b = 1.20.

In order to estimate the telephone dictionary software we use COCOMO [The

Constructive Cost Model].
Basic COCOMO computes software development effort (and cost) as a function of
program size. Program size is expressed in estimated thousands of lines of code (KLOC).
The basic COCOMO equation takes the form
Effort Applied=ab (KLOC) b [Persons-Three, Months-Three]
Development Time=cb (Effort Applied) d [Months-one]
People required=Effort Applied/Development Time [Count-Three]
Basic COCOMO is good for quick estimate of software costs. However it does not
account for differences in hardware constraints, personnel quality and experience, use of
modern tools and techniques, and so on.

The basic COCOMO model is simple and easy to use. As many cost factors are not
considered, it can only be used as a rough estimate.Basic COCOMO is good for quick
estimate of software costs. However it does not account for differences in hardware
constraints, personnel quality and experience, use of modern tools and techniques, and so
on.

4. SOFTWARE DESIGN
Unified Modelling Language (UML)
The Unified Modeling Language (UML) is a standard language for writing
software blueprints. A modeling language is a language whose vocabulary and rules
focus on the conceptual and physical representation of the system.
The primary goals of UML are:
Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
Provide extensibility and specialization mechanisms to extend the core concepts.
Be independent of particular programming languages and development processes.
Provide a formal basis for understanding the modeling language.
Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
Diagrams in the UML
A diagram is the graphical presentation of a set of elements, Each UML diagram is
designed to let developers and customers view a software system from a different
perspective and in varying degrees of abstraction.
There are nine diagrams:

Class Diagram

Package Diagram

Component Diagram

Activity Diagram

Use Case Diagram

Sequence Diagram

Collaboration Diagram

State chart Diagram

Deployment Diagram

These diagrams can be categorized as Structural and Behavioral diagrams. The first four
diagrams are structural and the next five are behavioral.

A) STRUCTURAL DIAGRAMS
Structural diagrams deal with the static parts and the behavioral diagrams deal
with the dynamic parts of the system. A type of diagram that depicts the elements of a
specification that is irrespective of time. This includes class, composite structure,
component, deployment, object, and package diagrams

4.1 Class Diagram

Class Diagrams show the different classes that make up a system and how they
relate to each other. Class Diagrams are said to be static diagrams because they show
the classes, along with their methods and attributes as well as the static relationships
between them: which classes know about which classes or which classes are part of
another class, but do not show the method calls between them

DATA BASE
Name : char
Telephone No. : int
Address : Char
State : Char
District : Char
Add()
Delete()
Update()
search()

ADMINISTRATOR
Name : Char
Telephone No. : int
Address : Char
Add Entry()
Delete Entry()
Update Entry()

USER
Name : Char
Telephone No. : int
Address : Char
search()

A class is represented by a rectangle. The following diagram shows a typical class

in a class diagram:

The structure of a class

Class diagrams are widely used to describe the types of objects in a system and
their relationships. Class diagrams model class structure and contents using design
elements such as classes, packages and objects. 2 Class diagrams describe three different
perspectives when designing a system, conceptual, specification, and implementation. 1
These perspectives become evident as the diagram is created and help solidify the
design. This example is only meant as an introduction to the UML and class diagrams

4.2 Component Diagram

A component diagram shows the organizations and dependencies among a set of
components .A component diagram in the Unified Modeling Language, depicts how
components are wired together to form larger components and or software systems
Components are wired together by using an assembly connector to connect the required
interface of one component with the provided interface of another component. This
illustrates the service consumer - service provider relationship between the two
components.

ADMINISTRATOR

USER

DATABASE

The component diagram contains components and dependencies. Components

represent the physical packaging of a module of code. The dependencies between the
components show how changes made to one component may affect the other components
in the system. Dependencies in a component diagram are represented by a dashed line
between two or more components. Component diagrams can also show the interfaces
used by the components to communicate to each other

4.3 Deployment Diagram

Deployment Diagram displays the configuration of run-time processing elements

and the software components, processes, and objects that live on them.A deployment
diagram in the Unified Modeling Language serves to model the physical deployment of
artifacts on deployment targets. Deployment diagrams show "the allocation of Artifacts

to Nodes according to the Deployments defined between them." Deployment of an

artifact to a node is indicated by placing the artifact inside the node. The deployment
diagram contains nodes and connections. A node usually represents a piece of hardware
in the system. A connection depicts the communication path used by the hardware to
communicate and usually indicates a method such as TCP/IP.

Web
Browser

Regiona
l Service

Login
DB

Main
Server

Dictiona
ry DB

B) BEHAVIOURAL DIAGRAMS
A type of diagram that depicts behavioural features of a system or business
process. This includes activity, state machine, and use case diagrams as well as the four
interaction diagrams.
The diagrams explaining the behaviour are called Behavioural Diagrams.
Behavioural diagrams put the object model as a dynamic model.

4.4 Use Case Diagram

Use Case Diagram displays the relationship among actors and use cases. Use Case
Diagrams describe the relationships and dependencies between a group of Use Cases and
the Actors participating in the process. A use case illustrates a unit of functionality
provided by the system.

Login

Add Entry

User

Administrator
Delete Entry

Update

Look Up

The main purpose of the use-case diagram is to help development teams visualize
the functional requirements of a system, including the relationship of "actors" (human
beings who will interact with the system) to essential processes, as well as the
relationships among different use cases. Use-case diagrams generally show groups of use
cases either all use cases for the complete system, or a breakout of a particular group
of use cases with related functionality (e.g., all security administration-related use cases)

4.5 Sequence Diagram

Sequence Diagram is an interaction diagram that displays the time sequence of
the objects participating in the interaction Sequence diagrams show a detailed flow for a
specific use case or even just part of a specific use case. They are almost self
explanatory; they show the calls between the different objects in their sequence and can
show, at a detailed level, different calls to different objects.
Sequence diagrams demonstrate the behavior of objects in a use case by
describing the objects and the messages they pass. the diagrams are read left to right and
descending. The example below shows an object of class 1 start the behavior by sending
a message to an object of class 2. Messages pass between the different objects until the
object of class 1 receives the final message.

a.) ADMINISTRATOR

Database

Administrator

Login for correct adminstrator

Login Accepted

Enter the new details of Person

Person Details are Updated

Delete the Details of the Person

Person Details are Deleted and Updated

Prompt for Logout

Exit

b.) USER

User

Database
Prompt for viewing details of person

Displaying the details of states

Select the State

District details are displayed

Select the District

View Details Page is Displayed

Select the NAME or ADDRESS or TEL no.

Enter the TEL No. or ADDRESS in Text Box

Persons Details are displayed

Exit to come out of webpage

4.6 Collaboration Diagram

Collaboration Diagram is an interaction diagram that shows the structural
organization of the objects that send and receive messages. Collaboration Diagrams show
the interactions occurring between the objects participating in a specific situation. This is
more or less the same information shown by Sequence Diagrams but there the emphasis
is put on how the interactions occur in time while the Collaboration Diagrams put the
relationships between the objects and their topology in the foreground.
In Collaboration Diagrams messages sent from one object to another are represented
by arrows, showing the message name, parameters, and the sequence of the message.
Collaboration Diagrams are especially well suited to showing a specific program flow or
situation and are one of the best diagram types to quickly demonstrate or explain one
process in the program logic.
ADMINISTRATOR
Administra
tor

1: Login for correct adminstrator

4: Person Details are Updated
7: Prompt for Logout

2: Login Accepted
3: Enter the new details of Person
5: Delete the Details of the Person
6: Person Details are Deleted and Updated
8: Exit

Database

Collaboration diagrams are also relatively easy to draw. They show the relationship
between objects and the order of messages passed between them. The objects are listed
as icons and arrows indicate the messages being passed between them. The numbers next
to the messages are called sequence numbers. As the name suggests, they show the
sequence of the messages as they are passed between the objects. There are many
acceptable sequence numbering schemes in UML. A simple 1, 2, 3... Format can be
used, as the example below shows or for more detailed and complex diagrams a 1, 1.1,
1.2, 1.2.1... Scheme can be used.
USER

Database

1: Prompt for viewing details of person

5: Select the District
7: Select the NAME or ADDRESS or TEL no.
9: Persons Details are displayed

User

2: Displaying the details of states

3: Select the State
4: District details are displayed
6: View Details Page is Displayed
8: Enter the TEL No. or ADDRESS in Text Box
10: Exit to come out of webpage

4.7 State Diagram (State Chart Diagram)

State Diagram displays the sequences of states that an object of an interaction goes
through during its life in response to received stimuli, together with its responses and
actions.
State diagrams have very few elements. The basic elements are rounded boxes
representing the state of the object and arrows indicting the transition to the next state.
The activity section of the state symbol depicts what activities the object will be doing
while it is in that state. All state diagrams being with an initial state of the object. This
is the state of the object when it is created. After the initial state the object begins
changing states. Conditions based on the activities can determine what the next state the
object transitions to.
The state chart diagram models the different states that a class can be in and how
that class transitions from state to state. It can be argued that every class has a state, but
that every class shouldn't have a state chart diagram. Only classes with "interesting"
states that is, classes with three or more potential states during system activity
should be modeled.

Create
Admin

Add person
Details

Logout

Delete Person
Details

Lookup
Operation

Select State
,District

Perform Search
Operation

4.8 Activity Diagram

Activity Diagram shows the flow from one activity to another within a system. It
shows a set of activities, the sequential or branching flow of one activity to another and
the objects that act and are acted upon. Activity diagrams show the procedural flow of
control between two or more class objects while processing an activity. Activity
diagrams can be used to model higher-level business process at the business unit level, or
to model low-level internal class actions.
Activity diagrams show the flow of activities through the system. Diagrams are
read from top to bottom and have branches and forks to describe conditions and parallel
activities. A fork is used when multiple activities are occurring at the same time. The
diagram below shows a fork after activity1. This indicates that both activity2 and
activity3 are occurring at the same time. After activity2 there is a branch. The branch
describes what activities will take place based on a set of conditions. All branches at
some point are followed by a merge to indicate the end of the conditional behavior
started by that branch. After the merge all of the parallel activities must be combined by
a join before transitioning into the final activity state.

Enter Website

User or
Admin

user
User Enter
Telephone no.

Admin
Add / Delete
Entry
Add Entry
Details

Delete Entry
Details

Update

Exit

Details are
display

4.9 Package diagram

A package diagram in the Unified Modeling Language depicts the dependencies
between the packages that make up a model. Package diagrams can use packages
containing use cases to illustrate the functionality of a software system.
Package diagrams can use packages that represent the different layers of a
software system to illustrate the layered architecture of a software system. The
dependencies between these packages can be adorned with labels / stereotypes to
indicate the communication mechanism between the layers

Lookup

Search

Login

Telephone
Dictionary
Update

Add

Database

Delete

5. DATAMODELING AND IMPLEMENTATION

Data modelling in software engineering is the process of creating a data model by
applying formal data model descriptions using data modelling techniques. Data
modelling is a technique for defining business requirements for a database. It is
sometimes called database modelling because a data model is eventually implemented in
a database.
The figure illustrates the way data models are developed and used today. A
conceptual data model is developed based on the data requirements for the application
that is being developed, perhaps in the context of an activity model. The data model will
normally consist of entity types, attributes, relationships, integrity rules, and the
definitions of those objects. This is then used as the start point for interface or database
design.
The data modeling process

The telephone dictionary is implemented using visual basic 6.0 and Ms-Access.
As mentioned before the project consists of following modules.

Authentication
Add an entry
Remove an entry
Look up
Change the phone number in entry
List all entries.

IMPLEMENTATION

5.1 FORM 1

5.2 FORM 2

5.3 FORM 3

5.4 FOR M 4

5.6 CODING:

5.6.1 FORM 1
Private Sub Command1_Click()
Form5.Show
End Sub
Private Sub Command2_Click()
Form4.Show
End Sub
5.6.2 FORM2
Option Explicit
Dim db As Database
Dim rs As Recordset
Private Function fprvPopulateListview(vQuery As String)
fpubDBConnect
vpubDBRecordset.Open (vQuery)
With vpubDBRecordset
If .BOF = False Then
.MoveFirst
While Not .EOF
List1.AddItem (rs.Fields(0))
.MoveNext
Wend
End If
End With
vpubDBRecordset.Close
End Function
Private Sub Command1_Click()
Dim I As Integer
I=0
rs.MoveFirst

If Option1.Value = True Then

While Not rs.EOF
If Text1.Text = rs.Fields(0) Then
I=1
List2.AddItem (rs.Fields(0))
List3.AddItem (rs.Fields(1))
List4.AddItem (rs.Fields(2))
End If
rs.MoveNext
Wend
If I = 0 Then
MsgBox ("NO DATA FOUND")
End If
End If
If Option2.Value = True Then
While Not rs.EOF
If Text1.Text = rs.Fields(2) Then
I=1
List2.AddItem (rs.Fields(0))
List3.AddItem (rs.Fields(1))
List4.AddItem (rs.Fields(2))
End If
rs.MoveNext
Wend
If I = 0 Then
MsgBox ("NO DATA FOUND")
End If
End If
If Option3.Value = True Then
While Not rs.EOF
If Text1.Text = rs.Fields(1) Then

I=1
List2.AddItem (rs.Fields(0))
List3.AddItem (rs.Fields(1))
List4.AddItem (rs.Fields(2))
End If
rs.MoveNext
Wend
If I = 0 Then
MsgBox ("NO DATA FOUND")
End If
End If
End Sub
Private Sub Command2_Click()
Form1.Show
End Sub
Private Sub Form_Load()
Set db = OpenDatabase("E:\eswarrr\KUM.MDB")
Set rs = db.OpenRecordset("UPDATE")
End Sub
Private Sub Option1_Click()
Text1.Text = ""
List2.Clear
List3.Clear
List4.Clear
End Sub
Private Sub Option2_Click()
Text1.Text = ""
List2.Clear
List3.Clear
List4.Clear
End Sub

Private Sub Option3_Click()

Text1.Text = ""
List2.Clear
List3.Clear
List4.Clear
End Sub
5.6.3 FORM 3
Dim db As Database
Dim rs As Recordset
Private Sub Command1_Click()
rs.MoveFirst
a: If Text1.Text = rs.Fields(0) And Text2.Text = rs.Fields(1) Then
Form6.Show
Else
rs.MoveNext
If rs.EOF Then
MsgBox ("wrong username and password")
End If
GoTo a:
End If
End Sub
Private Sub Form_Load()
Set db = OpenDatabase("E:\eswarrr\KUM.MDB")
Set rs = db.OpenRecordset("LOGIN")
End Sub

5.6.4 FORM 4

Dim db As Database
Dim rs As Recordset
Private Sub Command1_Click()
rs.MoveLast
rs.AddNew
rs.Fields(0) = Text1.Text
rs.Fields(1) = Text2.Text
rs.Fields(2) = Text3.Text
rs.Update
MsgBox (" person details are added")
End Sub
Private Sub Command2_Click()
rs.MoveFirst
a: If ((rs(0) = Text1.Text) And (rs(1) = Text2.Text) And
(rs(2) = Text3.Text)) Then
rs.Delete
Else
rs.MoveNext
If rs.EOF Then
MsgBox ("PERSON DETAILS CANCELLED")
End If
GoTo a:
End If
End
End Sub
Private Sub Command3_Click()
Text1.Text = " "
Text2.Text = " "
Text3.Text = " "
End Sub
Private Sub Command4_Click()

Form5.Show
End Sub
Private Sub Form_Load()
Set db = OpenDatabase("E:\eswarrr\KUM.MDB")
Set rs = db.OpenRecordset("UPDATE")
End Sub

6. SOFTWARE TESTING
Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test. Software testing also
provides an objective, independent view of the software to allow the business to
appreciate and understand the risks at implementation of the software. Test techniques
include, but are not limited to, the process of executing a program or application with the
intent of finding software bugs.
Software testing can also be stated as the process of validating and verifying that
a software program/application/product:
1. Meets the business and technical requirements that guided its design and

development;
2. Works as expected; and
3. Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be

implemented at any time in the development process. However, most of the test effort
occurs after the requirements have been defined and the coding process has been
completed. As such, the methodology of the test is governed by the software
development methodology adopted.
Different software development models will focus the test effort at different
points in the development process. Newer development models, such as Agile, often
employ test driven development and place an increased portion of the testing in the
hands of the developer, before it reaches a formal team of testers. In a more traditional
model, most of the test execution occurs after the requirements have been defined and
the coding process has been completed.

Testing method s:

White box testing

Black box testing

Grey box testing

Testing levels:

Unit testing

Integration testing

System testing

System integration testing

Regression testing

Acceptance testing

Alpha testing

Beta testing

Non-functional testing:

Software performance testing and load testing

Stability testing

Usability testing

Security testing

Internationalization and localization

Destructive testing

Software testing is a critical elements of the software quality assurance and represents
the ultimate review of the specification, design, and code generation. Testing is a process
of executing a program with the intent of finding an error. Once source has been
generated software must be tested to uncover as many as errors as possible before
delivery to you customer.
6.1 Unit Testing:
Unit Testing is normally considered as an adjunct to the coding step. After source
level code has been developed, reviewed, and verified for correct syntax, and unit test
case design begins. A review of design information provides guidance for estimating test
cases that are likely to uncover errors in each of other categories. Each test case should
be coupled with a set of expected results.
6.2 Integration Testing:
Integration testing is a systematic technique for constructing the program
structure while conducting testes to uncover errors associated with interfacing. The
objective is to take the unit tested modules and build a program structure that has been
dictated by design.
6.3 Black Box Testing:
Black Box Testing focuses on the functional requirements of the software. Black
Box testing enables the software engineer to drive sets of input conditions that will fully
exercises the entire functional requirement for a program. Black Box testing attempts to
find errors in the following categories.
1. Incorrect or Missing functions
2.

Interface errors.

3. Errors in data structures or external data base access

4. Performance errors
5. Initialization and termination errors.

6.4 White Box Testing:

White Box testing, sometimes called glass box testing, is a test case design
method that uses of control structure of the procedural design to drive test cases.
Using white box testing methods, the software engineer can derive test cases that
1. Guarantee that all independent paths within a module have been
exercised least once.
2. Exercise all logical decisions on their true and false sides.
3. Execute all loops at their boundaries and with their operational
bounds.
4. Exercise internal data structure to assure their validity.
6.5 Functional Testing:
Functional testing determines whether the valid inputs produce valid outputs.
6.6 Condition Testing:
Condition testing is a test case design method that exercises the logical conditions
contained in a program module. A simple condition is a Boolean variable or a
relational expression, possibly preceded with one NOT operator.

6.7 Test cases

Validation Conditions:
Sno Test Case

Search KeyBy Name

Admin Login

Expected Result

Actual Result

Status

Show the Error If the

User name and
Password not Matches

Display the Error

Invalid User

Pass

Display the Error No

Data Found

Pass

Show the Error If the

file if name is not
matches with the data
base

Search KeyBy Telephone

No.

Show the Error If the

contact no. not
Matches with
Database

Display the Error No

data found

Pass

Search Key
By City

Show the Error If the

city spell not matches

Display the Error No

Data Found

Pass

Add Entry

Should enter into the

database by name ,
contact no. and
address

Display the message

box Person details
successfully added

Delete Entry

Should enter into the

label box by name ,
contact no. and
address

Display the message

box Person details
successfully Deleted

Navigation Conditions:

Pass

pass

S No.

Test

Expected result

Status

Keyboard

All main menu items are accessible by

Fail

shortcut to

keyboard

condition
1.

menu
2.

Keyboard

All sub menu items are accessible by

shortcut to

keyboard

Fail

menu items
3.

4.

Button access

All accesses to different screens through

to screens

buttons are done correctly

Modal

The confirmation and information dialogs are

dialogs

modal(i.e. the user prevented from accessing

Pass

Pass

other functions when this screen is active)

5.

Application

A number of instances of the application can

instances

be opened at the same time

Fail

6. SOFTWARE DEBUGGING
Debugging is a methodical process of finding and reducing the number of bugs,
or defects, in a computer program or a piece of electronic hardware, thus making it

behave as expected. Debugging tends to be harder when various subsystems are tightly
coupled, as changes in one may cause bugs to emerge in another. Many entire books
have been written about debugging (see below: Further reading), as it involves numerous
aspects, including: interactive debugging, control flow, integration testing, log files,
monitoring, memory dumps, Statistical Process Control, and special design tactics to
improve detection while simplifying changes.
The purpose of debugging is to locate and x the offending code responsible for a
symptom violating a known specication. Debugging typically happens during three
activities in software development, and the level of granularity of the analysis required
for locating the defect differs in these three.
The rst is during the coding process, when the programmer translates the design
into an executable code. During this process the errors made by the programmer in
writing the code can lead to defects that need to be quickly detected and xed before the
code goes to the next stages of development. Most often, the developer also performs
unit testing to expose any defects at the module or component level. The second place for
debugging is during the later stages of testing, involving multiple components or a
complete system, when unexpected behavior such as wrong return codes or abnormal
program termination (abends) may be found. A certain amount of debugging of the test
execution is necessary to conclude that the program under test is the cause of the
unexpected behavior and not the result of a bad test case due to incorrect specication,
inappropriate data, or changes in functional specication between different versions of
the system. Once the defect is conrmed, debugging of the program follows and the
misbehaving component and the required x are determined. The third place for
debugging is in production or deployment, when the software under test faces real
operational conditions. Some undesirable aspects of software behavior, such as
inadequate performance under a severe workload or unsatisfactory recovery from a
failure, get exposed at this stage and the offending code needs to be found and xed
before large-scale deployment. This process may also be called problem determination,
due to the enlarged scope of the analysis required before the defect can be localized.

The activities that involve debugging, testing, and verification in a typical software
development process
Debugging techniques
Print debugging is the act of watching (live or recorded) trace statements, or print
statements, that indicate the flow of execution of a process.
Often the first step in debugging is to attempt to reproduce the problem. This can be a
non-trivial task, for example as with parallel processes or some unusual software bugs.
Also, specific user environment and usage history can make it difficult to reproduce the
problem.
After the bug is reproduced, the input of the program needs to be simplified to
make it easier to debug. For example, a bug in a compiler can make it crash when
parsing some large source file. However, after simplification of the test case, only few
lines from the original source file can be sufficient to reproduce the same crash. Such
simplification can be made manually, using a divide-and-conquer approach. The
programmer will try to remove some parts of original test case and check if the problem
still exists. When debugging the problem in a GUI, the programmer can try to skip some

user interaction from the original problem description and check if remaining actions are
sufficient for bugs to appear. To automate test case simplification, delta debugging
methods can be used.
After the test case is sufficiently simplified, a programmer can use a debugger
tool to examine program states (values of variables, plus the call stack) and track down
the origin of the problem(s). Alternatively, tracing can be used. In simple cases, tracing is
just a few print statements, which output the values of variables at certain points of
program execution.
Remote debugging is the process of debugging a program running on a system
different than the debugger. To start remote debugging, debugger connects to a remote
system over a network. Once connected, debugger can control the execution of the
program on the remote system and retrieve information about its state.
Post-mortem debugging is the act of debugging the memory dump (or core dump) of a
process. The dump of the process space could be obtained automatically by the system,
or by a programmer-inserted instruction, or manually by the interactive user. Crash
dumps (core dumps) are often generated after a process has terminated due to an
unhandled exception.

TELEPHONE DICTIONARY