About

WWW.indiahotproperties.CO
M

www.indiahotproperties.com is India’s largest Real Estate

website, visited by thousands of property
buyers/sellers/lessors everyday. Advertising your projects,
properties and services on indiaproperties.com offers you
tremendous mileage. Indiahotproperties is open to innovative
advertising concepts for that extra brand visibility and
mileage.

About Company:

 CSE INDIA is an India based offshore software development and

IT consulting Services Company and provides cost-effective
offshore software development and customer -centric IT consulting
services for customers across the globe. My role as an Application
and Web-Site Developer.

 Our capability of addressing technologies like .Net, j2EE, and

Automated Testing tools, with varied domain expertise leads to on
time and within budget completion of software development
projects.

Preface :
www.indiahotproperties.com is India’s largest Real Estate
website, visited by thousands of property
buyers/sellers/lessors everyday. Advertising your projects,
properties and services on indiaproperties.com offers you
tremendous mileage. Indiahotproperties is open to innovative
advertising concepts for that extra brand visibility and
mileage.

Web site comprises following modules:

• Administration Module
• User Module
• Advertisement Module
• Search Module
• Sell/Lease Out module
• Purchase/Rent Module
• Member & Agent Module
• Property Tools Module
• City Description Module
• Database Design

This website is developed to facilitate and manage the

various peoples to search for their Properties .This web
site is developed in ASP.Net, MsSql Server 2000 and Java
Script for designing. We also use HTML, DHTML and XML.

First part of report gives all information about the project,

about the company under which we developed.

Second part of the report over the problem Definition,

Methodology we have used and System Requirements.
Third part covers the Design of the system, main functions,
how data is flowing between different modules, Relation
ship between different entities, database used.

Fourth part of the report describes the project plan

assumption we have made.

Fifth part covers the Screen shots of the project

In Sixth part describes the coding standards and

conventions used.

In the end describes the testing of the system.

 Problem Definition

&

Description

Statement about the Problem

Till date searching the property were done by the persons own self
from the property Dealer or through Internet sites there was a
limitation of matching choice of your property but these sites takes
much time in searching and purchasing a property. In both the cases
the time was very essential. So to solving this problem a stock of
problems can be listed in the existing system. After gaining an in-
depth knowledge to the various processes and the manner in which
they are carried out, it was realized that these were not only tedious
and cumbersome but also error prone. These bottlenecks are
featured in consideration with the overall aspects of the present
functioning system.

Following are the problems in the existing system:

 Increased time taken by personnel. It is

very tedious job to find a proper material
as per your choice and for the other.
 At the time of searching property all the
Time
Consideration records have to be scanned and even
after the people can’t be sure that they
will be able to find a proper property .
 In addition, owner wants to update their
records each time a deletion or addition.
 And the transactions of payments with
the client also take a lot of time.
  A large number of peoples are involved

to maintain the whole system that is very

expensive.
 The cost also increases to the buyer with
Cost
Consideration the increasing of shop maintenance.

 A large number of manpower is involved

to maintain the whole system, which is
very expensive and cumbersome.
 Unreliable and inefficient data entry.
 Lesser user friendly.
Other diverse
problems  Redundant data storage.
 Use of a lot registers for maintain
records.
 Hardware
&
Software Requirement

Hardware specification

Server
Processor : Pentium 3,500 MHz (or above).
RAM : 128 MB (or above).
HDD : 20 GB (or Above).
Client
Processor : Celeron 500 MHz or above, Pentium
2,350 MHz or above.
RAM : 64 MB (or Above).
HDD : 10 GB (or Above).
Software Specification

Operating System Windows 98, 2000, ME, XP, NT

Web Browser IE4 or Netscape 4x or upwards.

Development Tools ASP.NET, C#, JavaScript, HTML, DHTML

Database Microsoft SQL Server 2000

Scope
&
Objective Of Project

Scope
The system is highly flexible one and is well efficient to make easy
interactions with the client. The key focus is given on data security,
as the project is online and will be transferred in network. The speed
and accuracy will be maintained in a proper way.

This will be a user-friendly one and can successfully overcome strict

and severe validation checks. The system will be a flexible one and
changes whenever can be made easy. Using the facility and
flexibility in .NET and SQL, the software can be developed in a neat
and simple manner there by reducing the operator's work.
Since the project is developed in ASP.NET as a front-end and SQL
as a back-end it can be modified easily and used for a long period.

Through this project I have tried to automate the task of:

 Category of property
 Features of property
 Details Of Property
 Price Details
 Special Offer List for Registered Users
 Property detail by Messaging

 Available Properties Information

 Member Management
 Member Id is generated automatically from the table by auto
generation
 Entering the details like Primary Information, Religious
Background Educational & Professional Information, Contact
Information, and Other Information.
 Checking Password and Confirm Password
 Add Banners and Property Images
 Save time of Search
 Give a modification power to site’s owner at any label. So,
Administrator of site can make any changes such like can
add a new property, Features and Property Details on the
working windows.
  Administrator can also change the Banner and also can
change the list of special offer property.

Objective

Property site is available to anybody and

anywhere. This saves a lot of time of the
Time customer and in a very little time span the
Effective
and Cost registered user may look the “what’s a offer on
the special products purchasing”. This plan cost
offered is economic too.
A database of the registered users will be
created and this will help the users to fetch the
Database
details of recent property as per requirements.
Creation
There is a separate database for administrator
for updating the site.
Internet is available to everybody anywhere
Mobility
anytime here, this makes the site highly mobile.
The site has all the necessary details about the
concerned property and materials hence,
provide all the relevant information therefore.
Informative For example, searching of appropriate property
has done, then the information of purchasing is
provided to registered users by mailing.
 Any person can visit it. User can register with or
Wide
without photographs. Therefore it has a wide
Approach
range of users.
Proper authorization and authentication
provisions have been made for the security of
the site so that only the registered users can
Security
look the special offer details. Without proper
login no one is allowed to access the special
offer list of this site.
The site is flexible to any expansion or
contraction in the future. For example:
Flexible
Magazines section can be added, sending,
telegrams can be included etc.

SYSTEM
ANALYSIS

ANALYSIS OF PROPOSED SYSTEM:

Indiahotproperties web site is a distributed project.

Projects can be categorized in two ways:-
1. Local area network Projects

2. Distributed projects

Local area Network projects are those projects where

application has to be in cooperated in the Local area
network of the client i.e. with in its premises only. In LAN
cases, server is not remotely located and client access this
application through this network. Here the question of
platform independence does not arise and we use
technologies like: Visual Basic, Fox pro, D2K or C, C++.

But Distributed projects are those projects where

application is remotely situated. In these kind of projects
application is remotely situated on to the remote server
from where client machine connects to the remote server
and application is downloaded on to client machine. Here
the question of platform independence arises and we use
technologies like ASP.NET.

Data Gathering:

This project is a Business to Consumer and is a well-

commercial site of property which serves Indians and
others, with a variety of property.

Business system Elements:

 Objectives

Constraints

Controls

Input Processing Output

Feed
Back

1. Objective: The system analyst must be aware of

exactly what the user requires room a specific system. That
is management goals or objectives must be fully
understood.

2. Constraints: The analyst and the user must both

recognize any limitations or constraints that may be
imposed when the analyst is designing a computerized
system. Some types are:
• Legal constraints
• Budgetary Constraints
• Equipment Constraints

3. Controls: The user must familiarize the analyst with

the ways in which errors are minimized under the current
system.

4. Input: All input data that server as their basis for,

desired output must be studied where all data used for
processing originates. How often is each type of input
generate? If there are code or abbreviations used for input
does the analyst have complete list of these. What happens
to input documents after has been processed?

5. Processing: The analyst must then analyze the

processing or type of operations that are currently
performed in order to achieve the desired results.

Feasibility Study

A feasibility study is conducted top select the best system

that meets performance requirement. The key
consideration in feasibility analysis is:

1. Economic Feasibility

2. Technical Feasibility

Economic Feasibility:
The proposed system is economically feasible because the
cost involved in purchasing that hardware and the software
are within approachable. The personal cost like salaries of
employees hired are also nominal, because working in this
system need not required a highly qualified professional
.The operating –environment costs are marginal .The less
time involved also helped in its economical feasibility.

Technical Feasibility:

Hardware’s used in this project are –p3 processor 733

MHz, 64 MB RAMS, 10 GB hard disk, floppy drive. These
hard wares were already available on the existing
computer system. The software like MS-ACCESS, VB, MS-
WORD and operating system used were already installed
on the existing. So no additional hardware and software
were required to purchase and it is technically feasible.

Tools Used:

1. HTML, DHTML

2. Java Script

3. SQL SERVER-2000

4. ASP.Net

Promotion of the site:

Site will be promoted through various means:

1. Through personal approach by marketing division.

2. Through telemarketing.

3. Through advertisement such like various newspapers

etc.

4. Through web Marketing.

Methodology

System:

A system is the combination of people, devices, and

methods interrelated in working towards a common goal.

Information system:

An information system is a computer based business,

system that provides the data processing capabilities
information that an organization needs to be informed
about various aspects of its operation, are-

1. Value useful system & Provide accurate information

2. Provide timely information & Be capable of

communicating that information to the people in the
company who need it.
 Software Requirement
Specification

Software Requirement Specification:

Purpose:

indiahotproperties is a well-known company serving

Indians and others, with a variety of properties that
represent the property include Residential Flat, Land,
Hotel, Shopping Complex.

User friendliness:

This project will have user-friendly screens. The screens

designed will have very simple functionality for retrieving/
adding/ updating the in information.

Consistency:

The consistency in the proposed system will provide high

efficiency due to smaller learning curves and increased
data integrity.

Compatibility:

This project offers great compatibility, as it will be

designed with proper methodology, new tools and
technology

Security:
This project is a secured system, which will provide
corporate level security. Only the authorized people will be
able to access critical information. Also that will enable a
user to view /edit/ add the information, based on roles and
privilege assigned to that user.

Reliability & Robustness:

This project is built with proper architecture and design

and it will provide a reliable and robust application to the
users.

Performance:

The performance of this application will be high because of

it’s optimize design and sound architecture.

Extensibility:

This project has a modular design and would provide the

flexibility of adding, future modules to the application

Flexibility:

This project has the flexibility of adding new modules when

needed.

Methodology

One can perform cost estimation at any point in the

software lifecycle. As the cost of the project depends on
the nature and characteristics of the project, at any point,
the accuracy of the estimate will depend on the amount of
reliable information we have about the final product.
Clearly when the product is delivered the cost can be
accurately determined, as all the data about the project
and the resources spent can be fully known by then. This
is cost estimation with complete knowledge about the
project. On the other extreme is the point when the project
is being initiated or during the feasibility study. At this time
we have only some idea of the classes of data the system
will get and produce the major functionality of the system.
There is a great deal of uncertainty about the actual
specification of the system.

An estimation model for computer software uses

empirically derived formulas to predict effort as a function
of LOC or FP is estimated. The empirical data that support
most estimation models are derived from a limited sample
of projects. For this no estimation model is appropriate for
all classes of software and in all development environment.
The result obtained from such models must be used
judiciously.

The Structure of Estimation Models

A typical estimation model is derived using regression

analysis on data collected from past software projects. The
overall structure of such models takes the form

E= A + B*(eV)

Where A, B and C are empirically derived constants, E is

effort in person month and eV is the estimation variable
(either LOC or FP).
In addition to the relationship noted in the Equation, the
majority of estimation models have some form of project
adjustment component that enables E to be adjusted by
other project characteristics like problem complexity, staff
experience and development environment.

Such uncertainty represent a range of possible final

products not one precisely defined product. Hence, the
cost estimation based on this type of information cannot be
accurate. Estimates at this phase of the project can be off
from the actual final cost.

The COCOMO Model

COCOMO (Constructive Cost Model) is most widely used

for software estimation. This model also estimates the total
effort in terms of person month of the technical project
staff. The effort estimate includes development,
management and support task but does not include the
cost of the secretarial and other staff that might be needed
in an organization. The basic steps in this model are:
1. Obtain an initial estimate of the development effort
from the estimate of thousands of delivered lines of source
code (KLOC).

2. Determine a set of 15 multiplying factors from different

attributes of the project.

3. Adjust the effort estimate by multiplying the initial

estimate with all the multiplying factors.

The initial estimate is determined by an equation of the

form used in the static single-variable models, using
KDLOC as the measure of size. To determines the initial
effort Ei in Person-month. The equation used is of the type

Ei = a*(KDLOC) b

The value of the constraints a & b depend on the project

type. In COCOMO project are categorized into three types
organic, semi-detached and embedded.

Organic projects are in area in which the organization has

considerable experience and requirements are less
stringent. Such systems are usually developed by a small
team. Examples of this type of project are simple business
system, Simple Inventory Management System and Data
Processing System.

Projects of the embedded type are ambitious and novel;

the organization has little experience and stringent
requirements for such aspect as interface and reliability.
These systems have tight constraint from the environment
(software, hardware and people). Examples are embedded
avionics system and real time command system.
Semidetached system falls between these two types.
Examples of semi-detached systems include developing
new operating systems a database management system
and complex inventory management system. The constant
a, b, c and d for different systems are given in following
table:

The Software Equation

The Software Equation is a dynamic multivariable model

that assumes a specific distribution of effort over the life of
a software development project. The model has been
derived from productivity data collected for over four
thousand contemporary software project based on this
data, an estimation model of the form

E= [LOC * B /P] *(1/t)

Where E = effort in person-months or person-years

T = project duration in months or years

B = "special skills factor"

P = "productivity parameter" that reflects

" Overall process maturity and management practices.

" The extent to which good software engineering

practices are used

" The level of programming languages used

" The state of software environment

" The skills and experience of the software team

" The complexity of the application

Typical values might be

P= 2,000 for development of real-time embedded software.

P=10,000 for telecommunication and systems software.

P= 28,000 for business system applications.

The Productivity parameter can be derived for local

conditions using historical data collected from past
development efforts.

Analysis and Design

Awareness can be increased about the different schemes

of shopping sites. General public interests can be
generated in the sites.

Better Productivity and comforts can be provided by the

system.

Customers will be able to check their queries with ease.

Users can able to perform Transactions like:

Maintaining the details in master files which can be easily

updated

Keeping Transactions Like:

1. Adding Property Type

2. Adding Property Features

3. Adding property Details

4. Modifying Property

5. Modifying property Features and Details

6. Adding Property rates, electricity Rates

7.City Description

8. Adding Banners

Preliminary Investigation

In preliminary Investigation to check that is there is any

need of this type of system and shall we survive without
this system, is the system is feasible for us etc. First of all,
the need of the system is checked. If the system is
developed shall it give any revenue to us?
Feasibility Study
Feasibility Study
There are three types of Feasibility study:

(1) Technical Feasibility

(2) Economical Feasibility
(3) Operational Feasibility

Technical Feasibility

Meaning: Can the work for the project be done with current
equipment existing software technology and available
personnel? If new technology is needed, what is the
likelihood that it can be developed?

Reply: In this project the work cannot be done by the

current system because currently all the records, filling,
transactions, entries, are done by manuals. It is really time
consuming and margin of error is more.

Yes, the current available personnel can develop this

system but special training should be given to those
personnel to improve their skills. Yes new technology or
software, which is currently working in the market, is to be
needed to develop this system.

It can be developed easily with this software and for a long

term it is working effectively and margin of error is less.

To run this product the following technological

consideration has to be kept in mind by the Company.
SQL server as back-end is a good DBMS software with
long-standing track record in industry for the good
technical aspect, extensibility, concurrency and support
needed for this purpose.

SQL server2000 and Windows NT operating system are

used while making this product. Language such as .NET is
also used while making this project.

SQL server can run on the different windows operating

systems from Windows 95 to windows 2000, Win NT, and
Win 98.

Economical Feasibility

Meaning: Are there sufficient benefits in creating the

system to make the costs acceptable? Or Are the costs of
not creating the system so great that it is advisable to
undertake the project.

This will include three major costs as described below:-

• Cost of Hardware and Software

• Cost of software to be acquired to build and run the
product is a one time cost.
• Buying a back end database is the major part of
hardware and software cost. Comparison between the
Oracle database high cost and better features with the SQL
server low cost and better support for the same vendor
operating system make this decision need oriented.

Benefits in reduced cost, error and Savings will be made

by reduction of present system expenses, time saving and
increased accuracy.
Cost Avoidance

Future cost reduction in from of reduction in the number of

administrative staff needed and manual records maintains
in organization.

Rise in cost will be avoided.

Operational Feasibility

Meaning: The system will be used if it is developed well

then be resistance from users that undermine the possible
application benefits.

Dealer Support :

Dealer and user support for present system is there, as the

current procedure used takes more time and effort than
proposed system.

No major training and new skills are required as it is based

on DBMS model.

It will help in the time saving and fast processing and

dispersal of user request and applications.

New product will provide all the benefits of present system

with better performance suchlike Improved information,
better management and collection of the reports.

User Support :
User involvement in the building of present system is
sought to keep in mind the user specific requirement and
needs.

User will have control over there own information.

Important information such as pay-slip can be generated at
the click of a button.

Faster and systematic processing of user applications will

save user from cumbersome process of filling forms and
submitting them at different places and then waiting for
applications to be processed.

Old method used for application approval, allocation of

IDs, payments, etc. used had greater chances of error due
to wrong information entered

Structure
Designing
 DATA FLOW DIAGRAM
A newer graphic for defining input, processes and outputs is the
data flow diagram. Only a few symbol are used, as shown in figure
and these symbols may be located in a rather informal way.

1. Data Transformation

2. Temporary Data Storage

3. Data Flow

DATA FLOW DIAGRAM OF MESSAGE MODULE:

Context Level DFD

Admin
Index Indiahotproperties Search Result
Details Property

LEVEL ONE DFD

DFD 1

Adding &
Admin Modifying
Login Property
Property’s
Detail

Property type, Features of property, city, Banner

DFD 2

Index
property Property
Features

Details

DFD3

Submit the
Details

Search Search
Results

DFD In Structural Designing

This is the first step in the structure design method. In our
project, there are two input files: file1 and file2 and two
outputs are required: the merit list and the waiting list. A
high level DFD for this is given. The diagram is fairly clear.
First we receive the application forms. Then with the help
of input file1 and file2 we check for the validation of forms,
if correct then store them in temporary database else they
are rejected and send the rejection letter. The record from
First level factoring: The first-level structure chart can
easily be obtained and is shown in figure. In the structure
chart, instead of having one output module for each of the
three outputs, as is shown in the data flow diagram, we
have only one output module, which then invokes three
output modules for the different outputs.

Factoring I/O modules:

The output module does not need any factoring. According

to the design methodology, the input module which
validates the input will have on input module to get the
array of validated forms by referring to the other input
files. This input module can then be factored into other
input modules to get the validation done. The input module
will get data from input file2 and validate the given forms
the structure chart is shown in the figure.

Design Analysis:

Here we list each major requirement and then list the

modules in the structure chart that implements that
requirement.

Analysis using information flow Metrics:

Based on the structure chart the design of the system was
first specified completely: This required formally specifying
the data structure and all the modules. For each module
we specified the purpose of the module, its interface, the
modules it invokes, and the estimated size of the module
(in LOC). This formed the first version of the design
document. The first thing that could be noted was that
when specifying a complete design from the structure chart
the design usually expands.

We can develop the code for the given project using the
sketched design in any of the languages which fit into the
software requirements.

EFFORT ESTIMATION

As this project is some what small, we will use the simple

method of determining the effort based on average
productivity. Based on experience and capability of
programmers (through no data has been formally collected
for this), from the require merits, the ratings of different
cost drivers, attributes were assessed. These rating along
with multiplying factors are: -

Cost Drivers Rating

1. Software Reliability 1.0Normal

2. Database Size 1.16 high

3. Product complexity 1.15 High

4. Execution Time 1.0Normal

5. Storage 1.13 Low

6. Virtual Machine Volatility 1.0Normal

7. Analyst capability 1.17 Low

8. Application Experience 1.06 High

9. Programmer Capability 1.0Normal

10. Programming language experience 1.0Normal

11. Modern programming practice 1.0Normal

12. Use of Software Tools 1.0Normal

13. Requirement development Schedule 1.0Normal

All other factors had a normal rating. From these, the effort
adjustment factor (EAF) is:

EAF =
1.0*1.16*1.15*1.0*1.13*1.0*1.17*1.06*1.0*1.0*1.0*1.0*1.0*
1.0

= 1.8695 = 1.87 approx.

The initial effort estimation for the project is obtained from

relevant equation where Initial effort estimation (Ei) =
a*(KLOC) b

Where a & b are constants which depends on the project

type. As our project is an organic medium project so the
values will be:

ai = 3.2 & bi = 1.05

So, Ei= 3.2*(5.0)1.05

=3.2*5.418

=17.34 PM

Using the effort adjustment factor and initial effort

estimation we get the total project effort.

Ef = EAF * Ei

= 1.87 * 17.34

= 32.4258

= 32.4 PM

To get a phase wise breakup of the effort we use the

distribution of the effort as per COCOMO model. The
formula for calculating the effort phase wise is

Ep = µb * Ef

Where µb is the coefficient of effort And Ef is total project

effort.

The phase wise breakup for the project is:

Sequence No. Phases Formula Result

1. Plan & requirement 0.6 * 32.4 19.44

2 System Design 0.16*32.4 5.184

3. Detailed design 0.24*32.4 7.776

4. Code & Test 0.38*32.4 12.312

5. Integration Test 0.22*32.4 7.128

Configuration Control Plan

In this project, we will only have configuration control for

the code. The design will not be under configuration
management. The requirements are assumed to be frozen;
any change will be negotiated with the management.

The configuration control board (CCB) will consist only of

the group leader. A module will be taken for configuration
management, only after it has been successfully unit
tested and its unit test results have been approved by the
group leader. Change requests will be made to the CCB
through electronic mail, and the requester will have to
justify the request. Request changes will generally be
allowed if the change does not change the interface of the
module, and the project is not behind the schedule.
Changes that will modify the module interface or affect
other programmers will, in general, not be approved unless
there are good reasons for doing so. In this case, all the
concerned parties will informed of the change through
electronic mail.

Quality Assurance Plans

To ensure quality, the following documents (besides this
plan and the requirements document) will be produced
during the development:

" System design document

" Code

" Unit test plan

" System test reports

The following methods will be used for quality control:

" Preliminary design review

" Unit testing

" System test plan review

" System testing

It is felt that because the system is small, a detailed

incremental testing is not needed. A two-level testing is
used: unit testing followed by system testing. The system
test plan, however, will be reviewed before the testing is
performed. No code review will be done.

Monitoring Plans

Three basic methods will be used for project monitoring -

project logs, biweekly meetings and reviews. Because we
do not have a time sheet processing system, each project
member will keep a multipurpose log in which he will
record the different activities he performs and the date and
duration of the activity. The failure and error data obtained
during testing will also be recorded in the log.

Cross checking of the log data can be done by those

events in which more than one person of the team
participated. The format of the log entries is:

Date Time Time Time Activity Comments

From To In Type
Minute
s

Activity type is one of the following: requirement

understanding, design (system or detailed), coding,
testing, report writing, meeting, debugging (including
correcting errors), and others. In the comment field, the
errors encountered during testing have to be recorded.

Reviews to be held are defined earlier. In addition to

reviews, a biweekly meeting will be held to discuss the
progress of the project.

Risk Management

The project has no major hazards associated with it. The

only risks it has are the cost and schedule risks. Although
analysis can easily be done regarding the schedule risks
involved, it is felt that because the team has one part-time
member (who is largely under-used) schedule slippage can
be easily handled. Similarly, because the costs are low in
this small project, it is felt that an analysis of the cost risk
is unnecessary.

FLOW CHART

Start

Index Checking Details

Acce
Accept Enter the pt
the
Details
Details

Pro
Details
ces Out put
sing

Stop
 NAVIGATIONAL FLOW CHART
It would be helpful if you could provide us with a navigational flow chart
for your website. This is very much in the format of a family tree with
your home page at the top of the tree/chart with branches/links to all
other pages and then sub pages

Ne
w
Start
use
r

No

Make Registration

Login in with password &

user name

Search the property

No
Flat Logout

Select mode of
payment

Make
Transactions

Continue on the next page if necessary

 E-R DIAGRAM

User name
Passw
ord

Users Logi Valid User

n
Adding
Property Adding
Feature
s
Modifying Search Adding
the details details

Perfor
Transactions m
System Testing
&
Validation
 High Level System Designing

The purpose of this phase will be to design the overall functioning of

the proposed system and finalize the input and output formats. The
administrator and the projects teams should present the document
of functional specifications in a language that can be understood.
The client must approve the design, and the project team should
then be able to move on to the subsequent phases

. NET FRONT END

CONTAINS
User
Admin
Search

DATA BASE
Process Input
Text File
Indiahotproperties

Input Text File

Objective of System Testing

Testing is vital to the success of any system, Testing is done at

different stages within the development phase. System testing
makes a logical assumption that if all parts of the system are
correct, the goals will be achieved successfully, inadequate tests or
no testing leads to errors that may come up after when correction
would be extremely difficult. Another objective of testing is its utility
as a user-oriented vehicle before implementation.

Each module will be tested individually so as to

Unit Testing make the individual component error free. Also
other attached modules will also be error free.
Each module will be tested of its effect on other
modules by integrating the modules. This will
Integration
remove further errors from the system and may
Testing
also result in some changes in the individual;
modules.
Now testing is done to ensure that if users enter

Validation any superfluous data, it does not reach to the

Testing database but are asked to record the data in the
acceptable format.
Here, the whole system is tested fully. The errors
now should be meager. This will ensure flawless
System Testing
working of the system at the user’s site rather
than giving troubles after installation.
System Testing Here, the whole system is tested fully. The
errors now should be meager. This will
 ensure flawless working of the system at the
user’s site rather than giving troubles after
installation.
This testing is predicated on close
examinations of procedural details. Providing
White box
test cases that exercise specific sets of
testing
condition or loops tests logical paths through
the software.
This Testing method focuses on the
Black Box
functional requirements of the proposed
Testing
software.
It is a test case design method that exercise
Condition
the logical conditions contained in a program
Testing
module.
This method selects paths of a program
Data flow
according to the locations of definitions and
Testing
uses of variables in the program.

The testing of the system was done on both artificial and live data.
The following types of tests are performed.

Unit Testing

This testing focuses verification on the module. Using procedural

design description as a Guide; important control paths are tested to
uncover errors with in the boundaries of the module. The relative
complexity of tests and uncovered errors is limited by the constraints
scope established for unit testing. The unit testing can be conducted
in parallel for several modules.

Integration Testing
Generally a combined approach known as sandwich testing using
features of top down testing strategy for upper levels of the program
structure, coupled with the bottom up strategy for subordinate
modules.

Functional testing

This is done for each module/sub module of the system. Functional

testing serves as a means of validating weather the functionality of
the system confirms the original user requirement i.e. done the
module do what is supposed to do. The separate schedules were
made for functional testing .it involves preparation of bugs listing for
non-conformities.

System Testing
System testing is done when the entire system has been fully
integrated. The purpose of the system testing is to test how the
different modules interact with each other and whether the system
provides the functionality that was expected.

It consists of the following steps.

1. Program Testing

2. String Testing

3. System Testing

4. System Documentation

5. User Acceptance Testing

Validations and verifications

Testing

Testing presents an interesting anomaly for the software engineer.

During earlier software engineering activities, the engineer attempts
to build software from an abstract concept to a tangible product.
Now comes testing. The engineer creates a series of test cases that
are intended to “demolish” the software that has been built. In fact,
testing is the one step in the software process that could be viewed
(psychologically, at least) as destructive rather than constructive.

Software engineers are by their nature constructive people. Testing

requires that the developer discard preconceived notions of the
“correctness” of software just developed and overcome a conflict of
interest that occurs when errors are uncovered.

If testing is conducted successfully (according to the objectives

stated previously), it will uncover errors in the software. As a
secondary benefit, testing demonstrates that software functions
appear to be working according to specification, that behavioral and
performance requirements appear to have been met. In addition,
data collected as testing is conducted provide a good indication of
software reliability and some indication of software quality as a
whole. But testing cannot show the absence of errors and defects, it
can show only that software errors and defects are present. It is
important to keep this (rather gloomy) statement in mind as testing
is being conducted.

Testing principles:

Before applying methods to design effective test cases, a software

engineer must understand the basic principle that guide software
testing.

All tests should be traceable to customer requirements.

Tests should be planned long before testing begins.

80 percent of all errors uncovered during testing will likely be

traceable to 20 percent of all program components. The problem, of
course, is to isolate these suspect components and to thoroughly
test them.

Testing should being “in the small” and progress toward testing “in
the large”.
Exhaustive testing is not possible.

To be most effective an independent third party should conduct

testing.

A rich variety of test case design methods have evolved for

software. These methods provide the developer with a systematic
approach to testing. More important, methods provide a mechanism
that can help to ensure the completeness of tests and provide the
highest likelihood for uncovering errors in software.

Any engineered product (and most other things) can be tested in

one of two ways.

(1) Knowing the specified function that a product has been

designed to perform, tests can be conducted that demonstrate each
function is fully operational while at the same time searching for
errors in each function.

(2) Knowing the internal working of a product, tests can be

conducted to ensure that “all gears mesh,” that is, internal
operations are performed according to specifications and all internal
components have been adequately exercised. The first test
approach is called black box testing and the second, white-box
testing.

White box testing, sometimes called glass-box testing is a test case

design method that uses the control structure of the procedural
design to derive 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 at least once,

(2) Exercise all logical decisions on their true and false sides,

(3) Execute all loops at their boundaries and within their operational
bounds, and

(4) Exercise internal data structures to ensure their validity.

White-box testing of software is predicated on close examination of
procedural detail. Providing test cases that exercise specific sets of
conditions and/or loops tests logical paths through the software. The
“status of the program” may be examined at various points to
determine if the expected or asserted status corresponds to the
actual status. Basis path testing is a white-box testing technique first
proposed by Tom McCabe. The basis path method enables the test
case designer to derive a logical complexity measure of a
procedural design and use this measure as a guide for defining a
basis set of execution paths. Test cases derived to exercise the
basis set are guaranteed to execute every statement in the program
at least one time during testing.

Black box testing, also called behavioral testing, focuses on the

functional requirements of the software. That is, black box testing
enables the software engineer to derive sets of input conditions that
will fully exercise all functional requirements for a program. Black
box testing is not an alternative to white-box techniques. Rather, it is
a complementary approach that is likely to uncover a different class
of error than white-box methods. When computer software is
considered, black box testing alludes to tests that are conducted at
the software interface. Although they are designed to uncover
errors, black-box tests are used to demonstrate that software
functions are operational, that input is properly accepted and output
is correctly produced and that the integrity of external information is
maintained. A black-box test examines some fundamental aspect of
a system with a little regard for the internal logical structure of the
software. 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 database access,

(4) Behavior or performance errors, and

(5) Initialization and termination errors.

 By applying black-box techniques, we derive a set of test cases that
satisfy the following criteria:

(1) Test cases that reduce, by a count that is greater than one, the
number of additional test cases that must be designed to achieve
reasonable testing and
(2) Test cases that tell us something about the presence or absence
of classes of errors, rather than an error associated only with the
specific test at hand.

White-box testing should not, however, be dismissed as impractical.

A limited number of important logical paths can be selected and
exercised. Important data structures can be probed for validity. The
attributes of both black and white box testing can be combined to
provide an approach that validates the software interface and
selectively ensures that the internal workings of the software are
correct.

VALIDATION CHECKS

The major decisions of a validation stage are concerned with

handling errors and distribution of data. The data relevant to the
system enters it through a set of validation procedures. Often they
are caused by a generalized input validation package tailored for the
needs of a particular system.

There are various ways of handling errors open to the designer that
includes rejection of the item of input or processing the next item,
writing error record and signaling the appropriate message to the
user. Error procedures must be specified in detail showing
decisions, actions and exceptions.

In most of the cases where error occurs an error message is popped

to the user who is supposed to realize the fact and do the necessary
steps. The program developed is checked thoroughly for errors by
testing it with data and the errors that are raised during this can be
clarified. The program may halt during an unpredictable error.
 Testing
&
Implementation
TESTING (TESTING TECHNIQUE SAND TESTING
STRATEGIES) AND IMPLEMENTATION
Unit testing of the modules is done so as to check that each of the
modules works, as they should be. Following is the module wise
testing of this project:

Test Case1:

Login Form

Valid User name and Password

Input=Login Id, Password

Output: Corresponding Form Show

Implementation of Test Case:

User Enters valid User name and Password (administrator, User).

Login Values are mapped in database table to check login id and
password is ok. If entry exits then Login process will be successful.

Test Case 2:

Wrong user Id and Password:

Input: Wrong Login Id and Password:

Output: Error Message generated

Implementation of Test Case:

User enters wrong user name and Password. Error message is

shown only for 3 times after that it will exit from the current form by
showing an aborting message.
Test Case 3:

Modifying Property

Output: Displaying the Properyt details

Implementation of Test Case:

Modifying the Property Details

Test case 4:

Modifying property and details

Output: Displaying details of property and features

Implementation of the Test case:

Modifying Category and Sub Category Details

Test Case 5:

Adding city, Banner,features etc

Output: Adding Property

Implementation of Test case:

Adding Property, Features, Banner, and city etc.

EVALUATION
In evaluation we prepare the team to evaluate the system. The
review team prepares a formal review plan around the objectives of
the review, the type of evaluation to be carried out and the time
schedule required. An overall plan covers the following areas:

Administrative plan: Review area objectives, operating costs,

actual operating performance and benefits.

Personnel requirements plan: Review performance objectives and

training performance to data.

Hardware plan: Review performance specifications.

All plans have been done by taken proper care and seriousness and
each module is evaluated using simulated data. This review not only
evaluated how well the current system is designed and
implemented, but also is a valuable source of information that can
be applied to the next system project.
Project Management Plan
This Project management Plan for the Helpdesk explains the
following:

• It provides an overview of the project in terms of its purpose,

what it covers & what it delivers.
• It provides an insight into the structure of the project team &
resources needed.
• It also explains the software development life cycle adopted for
the project in terms of the phases, iterations, and work procedures.

The way project will be managed throughout its life cycle, in terms of
detailed phase wise plan, process of monitoring, control & process
of risk management. Also, the plan of supporting activities required
for project management is mentioned.

Purpose

This plan details the strategy to administer, monitor and control the
Helpdesk project. It is to be used, along with project status reports,
to manage and track the project by the Project Leader and the
Project Management Office.

Scope

This version of PMP covers project management & software

engineering methodology for the FG project.

Responsibilities
Of
Team Members
 Responsibilities
Project Manager

• Ensure adequate resources are available

• Facilitate required training for the team
• Review the plans, estimates and deliverable
• Participates on module end reviews
• Project Initiation and wind up.
• Ensure that the project follows the Quality Management
System.
• Represent the project status in meeting and escalate any
issues/risks o senior management.

Project Leader

• Customer interaction
• Developing and administering the project’s PMP
• Requirement Management
• Resolution of technical issues between project team
• Provide Inputs and feedback to the Module Leader on
Technical and Non-Technical issues
• Design Review
• Ensuring Timeliness and quality of all deliverables
• Ensuring Project’s Defined Software Process identified in PMP
are followed
• Status reporting to PM
• Review of test plans & test cases
• Plan and Participate in Review and Audits

Module Leader

• Technical assistance and guidance to the team

• Design
• Backups
• Requirement Analysis
• Participation in Reviews and Audits
• Prepare Release Note.
• Integration of all developed units.
• Prepare installable & release to testing team.
• Coding
• Code reviews
• Self Testing

Developers

• Coding
• Code Review
• Self Testing
• Repair defects
• Peer Review
• Review of unit test cases..
• Participate in Review & Audits

Configuration Controller (CC)

For CC the responsibilities are defined how tools will be used during
project development

Testing Engineer

• Develop Test Plan

• Develop Test Cases
• Conduct Testing
• Report Testing Result Tailoring Decisions and Project’s Defined
Software Process
Project’s Defined Life Cycle
For
Indihotproperties
Project’s Defined Life Cycle (PDSP)
Our team will develop the software in accordance with PDSP
iterative lifecycle. Artifacts and evidence of results of software
development activities will be managed and controlled as per
Software Configuration Management Plan and made available to
support management reviews, metrics calculations, quality audits,
product evaluations, and preparation of product deliverables.

Phases of Life cycle

Four distinct phases are followed in the project, which are Inception,
Elaboration, and Construction & Transition. Which are indicators of
the progress of the project.

1. Inception—this phase brings to light an original vision of a

potential product, and transform it into an actual project. The
following important activities will be done in this phase-
• Feasibility Study of existing process.
• Collection of core project’s requirement
• One or more prototype development
• Initial Risk assessment and Initial project management
plan showing phase and iterations
• Test planning
• Estimation
• Phase end reviews

2. Elaboration—the main goal of this phase is to more thoroughly

analyze the problem domain, to define and stabilize the architecture,
and address the highest risk element of the project. The following
important activities will be done in this phase-

• Detailed Project Management plan is prepared.

• Most of the Critical project risks are mitigated.
• Review of prototype by customer and rework.
• Re-estimation
• Review of requirements and approval
• High Level Design
• Low Level Design
• Review of test plan
• System Test cases identification.
• Phase end review

3. Construction— in this phase the construction of product is

made. The following important activities will be done in this phase-

• Coding of Modules
• Unit testing & Code review.
• The Software product integration on the required platform.
• Re-estimation
• Close of open defects
• Peer Reviews of code
• Self testing by developers
• Phase end review

4. Transition—in this phase the product is put in the hands of its

end user. The important activities will be done in this phase are:

• System testing to validate the new system against user

expectations
• Training of users and maintainers.
• Project windup activities.
• Each phase emphasizes on some key aspects of the
development essential for the purpose of demonstrating progress on
the project. Each phase end is a key milestone with defined goals,
which is described in the “Project plan” section of this PMP.

Iteration
 Each phase is broken into one or more iterations. From a technical
perspective the software development is seen as a succession of
iterations, through which the software under development evolves
incrementally.

Iteration is a complete development loop resulting in a release

(internal or external) of an executable product, a subset of the final
product under development, which grows incrementally from
iteration to iteration to become the final system.

The project has multiple iterations as defined in the SDP and at the
end of the each iterations, a build will be made and will be delivered
to the customer. The core procedure followed and the major
activities performed here–in are described in subsequent sections.

Requirements Management

Following activities will be performed for Requirements

Management:

i. Study the requirements and seek clarifications

ii. The requirement received from the client will be documented in
SR.
iii. Prepare Screen designs.
iv. Review of SR with users requirements.

Design

Following activities will be performed for Design:

• Develop Reports design.

• Develop Database Design.
• Prepare Design Document. There will be only one document for
both the above.
• Review and inspect the Design
• Outputs
• Design document

Implementation

Following activities will be performed for implementation:

• Study Requirements and Design document
• Decide methodology of development
• Select and customize coding standards
• Develop units
• Code
• Self test will be done before submitting it to Code
• Review
• Code review will be done by peers, by the method of
walkthrough
• Unit test by test engineers.
• Integration of components
• Integration testing
• Preparation of Installable
• Release to testing team
• Outputs
• Integrated and tested units
• Peer Review
• Code Review Log

Testing
Following activities will be performed for Testing:

• Develop Test Plan

• Review test plan
• Develop test cases
• Review test cases
• Execute integration test
• Execute System test

Outputs

• Test plan
• Test cases
• Testing records and defect List

Deployment
Following activities will be performed for Deployment:

• Secure the deliverable

• Prepare appropriate media, ensure correctness of version and
check product integrity
• Check for virus, worms or any other element that could cause a
damage
• Prepare Delivery Note, in case of final delivery
• Close Field Defects
• Get Acceptance Certificate from customer
• Get the Project Evaluation Form filled by the Customer

User Acceptance Plan

No separate acceptance plan would be made. It would be found

accepted, if developed module is delivered as per requirements
mentioned in SR.

Project Estimates

The Helpdesk Project Manager & Project Leader will do estimation

for the project.

Phase Plan and Milestones

Phase Iteration Major Milestones Start End

& Releases Date Date
Inception Iteration Prototype ? ?
-1
Inception Iteration SR ? ?
-1
Elaboration Iteration Design ? ?
-2 Document
Elaboration Iteration System Test ? ?
-2 plan
Construction Iteration– Beta Version ? ?
3
Transition Iteration– Final Release ? ?
4
? = Till now not known
 Maintenance
&
Security Measure
MAINTENANCE
Maintenance is the last part of the System Development Life Cycle
that is actually the implementation of the post-implementation review
plan.

When this system is installed it is used for long period. The average
life of a system is 4 to 6 years and maximum used for 10 years.
However, this period of use brings with it the need to continually
maintain the system, but this system can be modified and new
technologies can be used which are prevalent in market at that
period of time.

SECURITY MEASURES TAKEN

Security options provided with the SQL server and Win NT are relied
upon heavily for security of the organizational information and user
privacy:

Users are provided with the login name and password to use to
login to the site. Users are divided into their categories so that only
links that are visible to them are links they have access to. Links
those are not required by the user or not required to perform their
duties are hidden from them.

Provide two type of security mode one is WINDOWS NT

authentication and other is SQL Server mix mode. If user log on the
site using Windows NT domain then first security mode is good to
use. If there exists the combination of system that runs on Operating
system as WIN 95/98 then it is the only option available to log on to
server. Mix mode authentication is more complex as it has more
layer of processing security.
 Conclusion
&
Future
Enhancement
 FUTURE SCOPE OF THE PROJECT

The system is highly flexible one and is well efficient to make easy
interactions with the client. The key focus is given on data security,
as the project is online and will be transferred in network. The speed
and accuracy will be maintained in a proper way.

This will be a user-friendly one and can successfully overcome strict

and severe validation checks. The system will be a flexible one and
changes whenever can be made easy. Using the facility and
flexibility in .NET and SQL, the software can be developed in a neat
and simple manner there by reducing the operator's work. Since the
project is developed in .NET as a front-end and SQL as a back-end
it can be modified easily and used for a long period.

CONCLUSION
Working on the project was good experience. I understand the
importance of Planning and designing as a part of software
development. But it’s very difficult to complete the program for single
person.

Developing the project has helped us some experience on real-time

development Procedures.
BIBLIOGRAPHY
 Bibliography

 ASP.NET 1.1 with C# .NET 2003- Professional

---------- Wrox

 ASP.NET UNLEASED

------Stephan Walther

 COMPLETE ASP.NET

BPB Publication
----------

 MICROSOFT SQL SERVER-2000

---Rankin, Paul & Jensen

 BUILDING WEBSITE WITH ASP.NET COMMUNITY

-------Christian Darie & K.Scott Allen

 SQL SERVER-2000

-----Dusan Petkovic
 Appendix

SAMPLE FORMATS

PROJECT GOALS

GOALS STRATEGY
PROJECT SCHEDULE

S.NO MILESTONE DELIVERABLE PLANNED ACTUAL REASON

DATE DATE FOR
DEVIATOI
N
TEST CASE REPORT

PROJECT NAME:

DEVELOPERS:

TYPE OF TEST (UNIT/INTEGRATION/FUNCTIONAL):

DATE:

S.NO TEST TEST EXPECTED ACTUAL PASSED/FAILED

DECRIPTIO DAT RESULT RESULT
N E
DEFECT REPORT

PROJECT NAME:

DATE:

DEVELOPERS:

Location Description Category Corrective Corrected Verified Closed

Action by by on
PERFORMANCE PARAMETERS:

S.NO Performance Measurement Target Status Remarks

area Criteria
1 Schedule Number of dead
adherence lines missed
2 Defect-free Number of
deliverables category’s’ defects at
final deliverable
stage
3 Adherence to Number of non
standards conformances
processes
4 Documentation Number of items
accuracy and incomplete/inaccurat
completeness e
Home Page

Sell
Emi Calculator
Area Conversion
Buy
AIRLINE RESERVATION SYSTEM

by

Deepanjali Jaiswal (Group Leader)

Padmija Srivastava(Team Member)
Swatika Rawat(Team Member)

Comp Science Department

APRIL15 2010