ONLINE TUTORIAL

2013-14

Submitted By: Guided By:

Anupan Prabha Dr.Ashendra Kumar Saxena
Dr.Ambuj Kumar Agarwal

Page 1
 I have a great pleasure in acknowledging the help given by various
individuals throughout the project work. This project is itself an
acknowledgement to the inspiration, drive and technical assistance
contributed by many individuals.

We take this opportunity to express our immense gratitude to our

project guide Dr Ambuj Agarwal in our project Online Tutorial.
We are grateful for his prolonged interest in our work and excellent
guidance. He has been a constant source of motivation to us.

We are highly indebted to Mr. R K Dwivedi, HOD of

Department of Computer Applications for their valuable
guidance and timely suggestion in our project and training.

We would also like them and other faculty members for their
encouragement and guidance to us throughout our academic period.

At last I express my warm feeling of thank to all those who were

source of inspiration & were directly or indirectly involved with the
project Work.

Thank you to all sincerely

Anupam Prabha

Page 2
 Problem Statement
The software can be implemented over a network with a centralized database with
the help of which various client machines can be connected to the remote server to
provide information and facilities. The application can be easily implemented on a
touch screen machine as well.

Page 3
 Feasibility Study

As the need of system development says that first the project should be analyzed by the
System Analyst. But as we are not working on a big scale all the work is done by me for this
project. As I analyzed the project I should also go through all the rules of the System Analysis. So I
particularly went through the following points of the analysis:

1) System Planning and the initial investigation.

2) Information Gathering.
3) Feasibility Study.
4) Cost/Benefit Analysis.

Therefore particularly I had paid interest on these topics to analyze the project.
Let us discuss them briefly:

1) System Planning and the initial investigation:

The most critical phase of managing system projects is planning. To launch a

system investigation I needed a master plan detailing the steps to be taken. The problem is to be
questioned. The initial investigation has the objective of determining whether the users request
has the potential merit.

a) After that I worked on my dimensions of the planning such as:

i) High interest rates make it more important that business realizes a good
return on investment.

Page 4
 ii) Inflation puts pressure on profit when it occurs.
iii) The growing trend toward guaranteed employment suggests that costs are
becoming fixed and the commitment to business expansion may not be
easily changed.
iv) Resource shortages impede expansion.
b) Initial investigation:

This is a users request to change, improve or enhance an existing system.

Because there is likely to be a stream of such requests but as there is no particular
requests in our case as we are competing our project in the campus we have to
investigate for ourselves. The standard procedures must be established to deal
with them. The initial investigation is one way of handling this.

v) Assigned title of work to be done.

vi) Nature of work to be done.
vii) Job objective
viii) Expected benefits
ix) Input/output description-Quantity, Name, Frequency etc.
.
Needs Identification:

It has not given much emphasis because all the needs were generated by me only
by the surveys. Therefore there were no students to ask and follow the identification part
of the software.

2. Information Gathering:

A key part of the feasibility analysis is gathering information about the system to
be made. It was known by me that what information to gather, where to find it, how to collect it
and what to make of it.

Page 5
 Kinds of information that I needed:

Before I determine where to go for information, or what tools to use, the first
requirement was to figure out what information to gather. The information that I had to
gather was

(i) Information about the user staff.

(i) Information about user staff:

Another kind of information that I had to gather was the knowledge about the people who run the
present system - their job functions and information requirements, the relationship of their jobs
in the existing systems, and the inter personal network that holds the user group together where
actually focusing on the peoples role, authority relationships, job status and functions,
information requirements, and inter personal relationships. Information of this kind highlights
the organization charts and establishes bases for determining the importance of the existing
systems for the organization.

I had to focus and to find out what people are going to be dealing with and
what each person expects to get out of a candidate system before it goes to design and
final implementation.

3. Feasibility Study:

After organizing and summarizing the data, I get through knowledge of the system.
According to the analysis the following information should be available after organizing and
summarizing the data:

1. Interview and correspondence records.

2. Updated system documentation.
3. Specification of the good and bad features of the current system.
4. Understanding how well the actual problems facing the system are inline with
the problems stated in the user request form.

Page 6
 The outcome of the initial investigation is to determine whether an alternative
system is feasible. At this time I have given importance to the user.

Actually as the feasibility study says to check out whether the system is feasible to
the environment, organization, economics, behavior, legal or not. So I checked out all the aspects
for the feasibility of the system and preferred the most feasible system that I had thought of.

4. Cost/Benefit Analysis:

Cost and benefits may be tangible or intangible, director indirect, fixed or variable.
Cost estimates also take into consideration hardware, personnel, facility, and supply costs for final
evaluation. Cost/benefit analysis, then, identifies the costs and benefits of a given system and
categorizes them for analysis. Then a method of evaluation is selected and the results are
interpreted for action. The evaluation methods range from the simple net benefit analysis to more
complex methods such as present value and payback analyses.

Cost and Benefit Categories

1. Hardware costs

Hardware Costs relate to the actual purchase or lease of the computer and
peripherals (for example, printer, disk drive, tape unit). Determining the actual cost of
hardware is generally more difficult when the system is shared by various users than for a
dedicated stand-alone system. My system needs a single computer to work on, along with
a printer to generate the bills of the students checked out.

2. Personal Costs

Page 7
Costs incurred during the development of a system are one-time costs and are labeled
developmental costs. Once the system is installed, the costs of operating and maintaining
the system become recurring costs.

Procedure for Cost/Benefit Determination

There is a difference between expenditure and investment. We spend to

get that we need, but we invest to realize a return on the investment. Building a
computer-based system is an investment. Costs are incurred throughout its life cycle.
Benefits are realized in the form of reduced operating costs, improved corporate image, or
revenues. The determination of costs and benefits entails the following steps:

1. Identify the costs and benefits pertaining to a given project.

2. Categorize the various costs and benefits for analysis.
3. Select a method for evaluation.
4. Interpret the results of the analysis.
5. Take action.

TABLE OF CONTENTS

1. Introduction

General
Page 8
 Objective

Web Based Application

2. System Analysis

2.1 Review of Existing System

2.2 Requirement of proposed System

2.3 Modeling

2.3.1 Functional Modeling

2.3.2 Behavioral Modeling

2.7 Software requirement Specification

2.7.1 Data Flow Diagram

2.8 Entity Relationship Diagram

2.9 Software Engineering Paradigm

3. System Design

a. 3.1 General

b. 3.2 Review Benefits, Cost target & Constraints

3.2.1 Database Design

3.2.2 Program Design

c. 3.3 Process Logic

d. 3.4 Physical & Logical Design

e. 3.5 Forms Print

4. System Testing

a. 4.1 Testing Strategies

b. 4.2 Testing Web Based Application

c. 4.3 Implementation

d. 4.3.1 Design of Test Data

e. 4.5 Training

f. 4.6 Post Implementation Review

5.System Maintenance

Page 9
 6.Future Scope

1.1 General: A tutorial is a method of transferring knowledge and may be used as a part of
a learning process. More interactive and specific than a book or a lecture; a tutorial seeks
to teach by example and supply the information to complete a certain task

An online tutorial is a gathering of Web pages designed to help teach you something. A
Web page design tutorial is an online tutorial designed to teach you Web page design.
From these you can learn everything there is to know about designing a Web page from
the HTML code to how to promote your site.

Internet computer tutorials can take the form of a screen recording, a written document
(either online or downloadable), or an audio file, where a person will give step by step
instructions on how to do something.
Tutorials usually have the following characteristics:

A presentation of content, usually with an example or examples, often broken up into

discrete modules or sections.
Some method of review that reinforces or tests understanding of the content in the related
module or section.
A transition to additional modules or sections that builds on the instructions already
provided. Tutorials can be linear or branching.

While many writers refer to a mere list of instructions or tips as a tutorial, this usage can be
misleading.
Obviously to remain firm in the market, one has to harness the potential of Information
technology and related e-commerce to boost the sales and e-education is also boost the education
.

1.2 Objective: It is proposed to develop a Windows Form(Software) for On Line Tutorial of

ASP.NET like etc. The Companies intending to teach the customer and the customers interested in
live example of ASP.NET will register in the registration form.

1.3 Web Based Application: There is little debate that Web-Based system and application

are different than the many other categories of the computer software discussed Powel

Page 10
summarizes the primary differences when he states that the Web-Based system involves a
mixture between and technology.

The following attributes are encountered in the vast majority:

1. Network intensive: By its nature, a Web-Based Application is network intensive. It

resides on a network and must serve the needs of the diverse community of the clients. A
Web-Based Application may reside on the internet (thereby enabling open worldwide
communication). Alternatively, an application may be placed on an intranet
(implementing communication across an organization) or an Extranet (inter-network
communication).

2. Content Driven: In many cases, the primary function of a Web-based application is to use
hypermedia to present text, graphics, audio, and video, content to the end user.

3. Continuous Evolution: Unlike conventional application software that evolves over a

series of planned, chronological spaced releases, web application evolves continuously. It
is not unusual for some Web-Based application to be updated on an hourly schedule.

Some argue that the continuous evolution of a Web-Based application

makes the work performed on them analogous to gardening. Engineering is about adopting a
consistent and scientific approach, tempered by a scientific practical context, to development and
commissioning of the system of application. Web Site development is often much more about
creating and infrastructure and tending the information which grows and blooms within this
garden Over time the garden (i.e. Web-Site) will continue to evolve, change , and grow. A good
initial architecture should allow this growth to occur in a controlled and consistent manner. We
could have tree surgeons that prune trees (i.e. section of the site) within the garden (the site
itself) while ensuring cross referential integrity. We could have garden nurseries where young
plants (i.e. design patterns for Web-Sites) are grown. Continual care and feeling allows a Web-Site
to grow (in robustness and important). But, unlike a garden, web application must serve (adapt
to) the needs of more then the gardener. The following Web-Based application characteristics
drive the process.

Page 11
 2 .SYSTEM ANALYSIS

2.1 Review of Existing System: The existing system of record maintenance are to maintain
them upon ledgers, registers etc. The prime issue with them is that they are good as once entered
will never get washed off but still their maintenance is really a tough job. Keeping them safe is just
next to impossible if they are needed to being accessed for every issue.

2.2 Requirement of proposed System: Under various groups of products and categories of
items, the selling companies will registers and enter the particulars and specifications of their
products together with prices. The consumers will registers with bank details and other particular
for viewing/searching the available products and for buying them.

Once the consumers confirms the buying transactions the systems

prompts him to enter the bank details for processing and debit the amount. Through the
authorized gateways the debit so raised will be sent for credits to companys account for selling. A
receipt for transaction conformation is generated by the system for consumer with a copy to the
respective company for delivery of the goods.

2.5 Modeling: We create functional models to gain a better understanding of the actual entity
to be built. When the entity is a physical thing, we can build a model that is identical in form and
shape but smaller in scale. However when the entity to be built is software, our model must take a
different form. It must be capable of representing the information that software transform to
occurrence, and the behavior of the system as the transformation is taking place.

The second and third operational analysis principles require that we build models of function and
behavior.

2.5.1 Functional Modeling: Software transforms information, and in order to accomplish this,
it must perform at least three generic function; input, processing and output .When functional
models of an applications are created, the software engineer focuses on problem specific function.
The functional model begins with a single context level model. Over a series of attractions, more

Page 12
and more functional detail is provided, until a through delineation of all system functionality is
represented.

2.5.2 Behavioral Modeling: Most software response to events from the outside world. This
stimulus\response characteristic forms the basic of the behavioral model. A computer
programmer always exists in some state\and externally observable mode of behavior that
is changed only when some event occurs.

2.7 Software Requirement Specification

System Analysis is the application of the system approach to the study and solution of the
problems using computer-based system. An activity encompasses most of the tasks collectively
called as Computer System Engineering. Analysis is a detailed study of the various operation
performed by a system and their relationship within and outside of the system. This involves
gathering information and using structured tool for analysis such as DFD (data flow diagram),
Decision Tree etc. During analysis data are collected on the available files, decision points and
transactions handled by the present system. The fact finding and information gathering for
proposed system is the key part of system analysis. Information is gathered from sources both
internal and external to the organization. The external sources include vendors, supplier
professional journals and other similar systems. The primary internal sources include the
system users, system documentation existing programs, and reports. Analysis is the process of
diagnosing situations, done with a defiant aim, with the system kept in mind to produce a report
based on the findings. Analysis is a fact of finding technique where studies like the system
requirement specifications, boundaries of feasibility analysis and cost benefit analysis are
carried out. The requirements of both the system and the software are document and reviewed
with the user.

Requirements analysis is a software engineering task that bridges the gap between
system level requirement engineering and software design. Requirement engineering activities
result in the specification of softwares interface with other system elements, and establish
constraints that software interface with other system elements, and establish constraints that
software must meet. Requirements analysis allows the software engineer to refine domains that
will be treated by software. Requirement analysis provides the software designer with a
representation of information, function, and behavior that can be translated to data, architectural,
interface, and component-level designs. Finally, the requirements specification provides the
developer and the customer with the means to assess quality once software is built.

Software requirements analysis may be divided into five areas of effort:

Page 13
 1. Problem recognition.

2. Evaluation and synthesis.

3. Modeling.

4. Specification.

5. Review.

Initially, the analyst studies the System Specification and the Software Project

Plan. It is important to understand software in a System context and to review the software scope
that was used to generate planning estimates so that problem recognition is ensured. The goal is
recognition of the basic problem elements as perceived by the customer/users.

Problem evaluation and solution synthesis is the next major area of effort for analysis. The
analyst must define all externally observable data objects, evaluated the flow and content of
information, define and elaborate all software function, understand software behavior in the
context of events that affect the system, establish system interface characteristics, and uncover
additional, and uncover additional design constraints. Each of these tasks serves to describe the
problem so that an overall approach or solution may be synthesized.

2.8 Entity Relationship Diagram

The object/ relationship pair is the cornerstone of the data model. These pairs can be represented
graphically using the entity/relationship diagram. The ERD was originally proposed by peter
Chen for the design of relational database systems and has been extended by others. A set of
primary components are identified for the ERD: data objects, attributes, relationships, and various
type indicators. The primary purpose of the ERD is to represent data objects and relationships.

Data objects are represented by a labeled rectangle. Relationships are indicating with a
labeled line connecting objects. In some variations of the ERD, the connecting line contains a
diamond that is labeled with the relationship. Connections between data objects and relationships
are established using a variety of special symbols that indicate cardinality and modality.

ER-Diagram:-

Page 14
2.9 Software Engineering Paradigm
Page 15
Sometimes called the classical life cycle or the waterfall model, the linear sequential model
suggests a systematic approach to software development that begins at the system level and
progresses through analysis, design, coding, testing, and maintenance and support. After a
conventional engineering cycle, the linear sequential model encompasses the following activities.

System Requirements
Review & Validation
User Requirement Specifications

Software Requirements
Software Requirements
Review & Validation

Preliminary Design
Review & Validation
Detailed Functional Specifications

Detailed Design Global Implementation Specifications &

Review & Validation Detailed Implementation Specifications

Code and Debugging

Review & Validation Coding & Debugging

Testing
Testing
Review & Validation

Maintenance
Review & Validation Maintenance

Page 16
 3 .System Design

2.1 General: System design refers to the technical specification that will be applied in
implementing the candidate system. This involves input/output, file and processing design.
System design is a solution, a how to approach to the creation of new system. This important
phase is composed of several steps.

It provides the understandings and procedural details necessary for implementing the system
recommended in feasibility study. Emphasis is on translating the performance requirements into
design specifications.

Design goes through logical and physical stages of development. Logical design reviews the
present physical system; prepares input and output specification; makes edit, security, and
control specifications details the implementation plan; and prepares a logical design
walkthrough. The physical design means out the details of the physical system, plans the system
implementation, devises a test and implementation plan, and specifies any new H/W or S/W.

The design phase focus on the detail implementation of the system recommended in the
feasibility study emphasis is on translating performance specifications into design specifications.
The design phase is a transition from a user-oriented document (system proposal) to a
document oriented to the programmers or database personal.

System design goes through two phases of development: Logical and physical design. A data flow
diagram shows the logical flow of the system and defines the boundaries of the system. For a
candidate systems it describe the inputs (source), outputs (destination), databases (data store),
and procedures (data flows).

Page 17
 In the logical system design it specify the user needs at a level of detail that virtually
determines the information flow into and out of the system and the required data resources. The
design covers the following:

Reviews the current physical system- its data flows, file contains, volumes, frequencies, etc.

Prepare output specifications- that are determined the formats content, and frequency of
report, including terminal specification and locations.

Reparse input specification-formats content, and most of the input functions. This includes
determining the flow of the document from input data stores to the actual input locations.

Prepare edit, security, and control specifications- This includes specifying the rules for edit
correction, backup procedures and the controls that insure processing and file integrity.

Specify the implementation plan.

Prepare a logical design walkthrough- involves the information flow output, inputs controls,
and implementation plan.

3.2 Reviews benefits, costs target dates, and System constraints:

Several development activities are carried out during structured design. They are data base
design, implementation planning, system test preparation, and system interface specification and
user documentation.

3.2.1 Data base design: This activity deals with the design of the physical database. A
key is to determine how the access paths are to be implemented. A physical path is derived from
logical paths.

3.2.2 Program design: In conjunction with the database design is a decision on

programming language to be used and the flowcharting, coding, and debugging procedure prior
to conversion.

3.2.3 System and programs test preparation: Each aspect of the system has separate
test requirement. System testing is done after all programming and testing is completed. The test
cases cover every aspect of the candidate system actual operations, user interface and so on.

Page 18
 3.2.4 System interface specification: This phase specifies for the user how
information should enter and leave the system.

Physical and Logical Design

Logical Design: The DFD shows the logical flow of system. It describes the inputs(sources),
outputs(destinations), databases(data stores), and procedures(data flows). Based on this, the
logical system design made which specify the user needs at a level of details that virtually
determine the information flow into and out of system and required data resources. Thus it
consists of design of input, output specifications (formats, contents), files, control specifications
and implementation.

Physical Design: Following logical design is physical design. This produces the working system
by defining the design specifications that tell programmers exactly what the candidate system
must do. Thus the physical system design consists of specifying input/output media, physical
storage, design of data structures and data bases and specifying backup procedures

0-Level DFD

Page 19
One level DFD

Page 20
Page 21
Screen Shots of Form Pages
Home page:-

Page 22
Login:-

Page 23
Asp.net examples:-

1.Query String:-

Page 24
Post Back:-

Page 25
Auto postback:-

Page 26
Grid view:-

Page 27
 4. System testing
Software Testing Steps

The last high-order testing step falls outside the boundary of software engineering and into the
broader context of computer system engineering. Software, once validated, must be combined
with other system elements (e.g. , hardware, people, databases). System testing verifies that all
elements mesh properly and that overall system function/performance is achieved.

Page 28
Unit Testing: Unit testing focuses verification efforts on the smallest unit of software design- the
software component or module. Using the component-level design description as a guide,
important control paths are tested to uncover errors within the boundary of the module. The
relative complexity of tests and uncovered errors is limited by the constrained scope established
for unit testing. The unit test is white-box oriented, and the step cab be conducted in parallel for
multiple components.

Unit Test Considerations: The module interface is tested to ensure that information properly
flows into and out of the program unit under test. The local data structure is examined to ensure
that data store temporarily maintains its integrity during all steps in an algorithms execution.
Boundary conditions are tested to ensure that the module operates properly at boundaries
established to limit or restrict processing. All independent paths through the control structure are
exercised to ensure that all statements in a module have been executed at least once. And finally,
all error handling paths are tested.

Interface

Local data structure boundary

Conditions Independent path Error

Page 29
 handling paths.

Module

Test

Cases

Tests of data flow across a module interface are required before any other test is initiated.
If data do not enter and exit properly, all other tests are moot. In addition, local data
structure should be ascertained during unit testing.

Selective testing of execution paths is an essential task during the unit test. Test
cases should be designed to uncover errors due to erroneous computations, incorrect
comparisons, or improper control flow. Basis path and loop testing are effective
techniques for uncovering a broad array of path errors.

Among the more common errors in computation are:

1. Misunderstood or incorrect arithmetic precedence.

2. Mixed mode operations.

3. Incorrect initialization.

4. Precision inaccuracy.

Page 30
 5. Incorrect symbolic representation of an expression.

Test Cases should uncover errors such as:

1. Comparison of different data types.

2. Incorrect logical operators or precedence.

3. Exception of equality when precision error makes equality unlikely.

4. Incorrect comparison of variables.

5. Improper or nonexistent loop termination.

6. Failure to exit when divergent iteration is encountered.

7. Improperly modified loop variables.

Integration Testing: Integration testing is a systematic technique for constructing the program
structure while at the same time conducting tests to uncover errors associated with interfacing.
The objective is to take unit tested components and build a program structure that has been
dictated by design.

There is often a tendency to attempt no incremental integration; that is, to construct the
program using a big bang approach. All components are combined in advance. The entire
program is tested as a whole. And chaos usually results! A set of errors is encountered. Correction
is difficult because isolation of causes is complicated by vast expanse of the entire program. Once
these errors are corrected new ones appear and the process continues in a seemingly endless
loop.

Incremental integration is the antithesis of the big bang approach. The program is
constructed and tested in small increments, where errors are easier to isolate and correct;
interfaces are more likely to be tested completely; and a systematic test approach may be applied.

The various integration testing are as follows:

a.) Top- Down integration.

b.) Bottom-Up integration.

Page 31
 c.) Regression Testing

d.) Smoke Testing.

Validation Testing: At the culmination of integration testing, software is completely assembled

as a package, interfacing errors have been uncovered and corrected, and final series of software
test-validation testing may begin. Validation can be defined in many ways, but a simple
definition is that validation succeeds when software functions in a manner that can be reasonably
expected by the customer. At this point a battle-hardened software developer might protest:
Who or What is the arbiter of reasonable expectations?

Software validation is achieved through a series of black-box tests that demonstrate

conformity with requirements. A test plan outlines the classes of tests to be conducted and test
procedure defines specific test cases that will be used to demonstrate conformity with
requirements. Both the plan and procedure are designed to ensure that all functional
requirements are satisfied, all behavioral characteristics are achieved, all performance
requirements are attained, documentation is correct, and human- engineered and other
requirements are met.

After each validation test case has been conducted, one of two possible conditions exists:

1. The function or performance characteristics conform to specification and are

accepted.

2. A deviation from specification is uncovered and a deficiency list is created.

Deviation or errors discovered at this stage in a project can rarely be corrected
prior to scheduled delivery. It is often to negotiate with the customer to establish a
method for resolving deficiencies.

Alpha & Beta Testing: It is virtually impossible for a software developer to foresee how the
customer will really use a program. Instructions for use may be misinterpreted; strange
combinations of data may be regularly used; output that seemed clear to the tester may be
unintelligible to a user in the field.

When custom software is built for one customer, a series of acceptance

Page 32
Tests are conducted to enable the customer to validate all requirements. Conducted by the end
user rather than software engineers, an acceptance test can range from an informal test drive to
a planned and systematically executed series of tests. In fact, acceptance testing can be conducted
over a period of weeks or months, thereby uncovering cumulative errors that might degrade the
system over time.

The alpha test is conducted at the developers site by a customer. The software is used in a
natural setting with the developer looking over the shoulder of the user and recording errors
and usage problems. Alpha tests are conducted in a controlled environment.

The beta test is conducted at one or more customer sites by the end-user of the software.
Unlike alpha testing, the developer is generally not present. Therefore, the beta test is a live
application of the software in an environment that cannot be controlled by the developer. The
customer records all problems that are encountered during beta testing and reported during beta
tests, software engineers make modifications and then prepare for release of the software
product to the entire customer base.

System Testing: Software is incorporated with other system element (e.g. hardware,
people, information), and a series of system integration and validation test are conducted. These
test fall outside the scope of the software process and are not conducted solely by software
engineers. However, steps are taken during software design and testing van greatly improves the
portability of successful software integration in the larger system.

A classic system testing problem is finer-pointing. This occurs when an error is

uncovered, and each system element developer blames the other for the problem. Rather than
indulging in such nonsense, the software engineer should anticipate potential interfacing
problems and:

a.) Design error-handling paths that test all information coming from other
elements of the system.

b.) Conduct a series of tests that stimulate bad data or other potential errors at
the software interface.

c.) Record the results of tests to use as evidence if finger-pointing does occur.

d.) Participate in planning and design of system tests to ensure that software is
adequately tested.

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

Types of System Tests are as follows:

a.) Recovery Testing.

b.) Security Testing.

c.) Stress Testing.

d.) Performance Testing.

5.2 Testing Web Based Applications

Testing is the process of exercising software with the intent of finding errors. This
fundamental philosophy does not change for WebApps. In fact, because Web-based systems and
applications reside on a network and interoperate with many different operating systems,
browsers, hardware platforms, and communications protocol, search for errors represents a
significant challenge for web-based engineers.

The approach for Web-based testing adopts the basic principles for all software testing
and applies a strategy and tactics that have recommended for object-oriented systems.

1. The Content model for WebApp is reviewed to uncover errors: This testing
activity is similar in many respects to copy editing a written document. Infect, a large
Web-site might enlist the services of a professional copy editor to uncover typographical
errors, grammatical mistakes, errors in content consistency, errors in graphical
representations, and cross-referencing errors.

2. The Design model for the WebApp is reviewed to uncover navigation errors: Use-cases,
derived as part of the analysis activity, allow a Web engineer to exercise each usage
scenario against the architectural and navigation design. In essence, these no executable
tests help uncover errors in navigation. In addition, the navigation links are reviewed to
ensure that they correspond with those specified in each SNU for each user role.

Page 34
3. Selected processing components and Web pages are unit tested: When WebApps are
considered, the concept of the unit changes. Each Web page encapsulates content,
navigation links, and processing elements. It is not always possible or practical to test
each of these characteristics individually. In many cases, the smallest testable unit is the
web page. Unlike unit testing of conventional software, which tends to focus on the
algorithmic detail of a module and the data that flow across the module interface, page-
level testing for WebApps is driven by the content, processing, and links encapsulated by
the We page.

4. The architecture is constructed and integration test are conducted: The strategy for
integration testing depends on the architecture that has been chosen for WebApp. If the
WebApp has been designed with a linear, grid, or simple hierarchical structure, it is
possible to integrate Web pages in much the same way as we integrate modules for
conventional software. However, if a mixed hierarchy or network(Web) architecture is
used, integration testing is similar to the approach used for OO systems. Thread-based
testing can be used to integrate the set of Web pages required to respond to a user event.
Each thread is integrated and tested individually. Regression testing is applied to ensure
that no side effects occur. Cluster testing integrates a set of collaborating pages. Test cases
are derived to uncover errors in the collaborations.

5. The assembled WebApp is tested for overall functionality and content delivery: Like
conventional validation, the validation of Web-based system and applications focus on
user-visible actions and user-recognizable output from the system. To assist in the
derivation of validation test, the tester should draw upon use-cases. The use-cases provide
a scenario that has a high likelihood of uncovering errors in user interaction
requirements.

6. The WebApp is implemented in a variety of different environmental configurations and is

tested for compatibility with each configuration: A cross-reference matrix that defines all
probable operating systems, browsers, hardware platforms, and communications
protocols is created. Tests are then conducted to uncover errors associated with each
possible configuration.

7. The WebApp is tested by a controlled and monitored population of end users: A

population of users that encompasses every possible user role is chosen. The WebApp is
exercised by these users and the results of their interaction with the system are evaluated

Page 35
 for content and navigation errors, usability concerns, compatibility concerns, and WebApp
reliability and performance.

Because many WebApps evolve continuously, testing process is an ongoing activity,

conducted by Web support staff that use regression tests derived from the tests developed when
the WebApps was first engineered.

5.3 Implementation

A crucial phase in the system life cycle is the successful implementation of the new system design.
Implementation includes all those activities that take place to convert from the old system to the
new. The new system may be totally new, replacing an existing manual or automated system.

Even the best systems can be weakened if the analysts managing the implementation do
not attend to every important detail.

5.3.1 Design of Test Data:

Test Data: The design of test data for software and other engineered products can be as
challenging as the initial design of the product itself. Yet, for reasons that we have already
discussed, software engineers often treat testing as an afterthought, developing test cases that
may feel right but have little assurance of being complete. Recalling the objectives of testing, we
must design tests that have the highest likelihood of finding the most common errors with a
minimum amount of time and effort.

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 products can be tested in one of the two ways:

Page 36
 1. Knowing the specified function that product has been designed to perform, tests can be
conducted that demonstrates each function is fully operational while at the same time
sear chin for errors in each function

2. Knowing the internal workings 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 excursed.

5.5 Training

Even well-designed and technically elegant systems can succeed or fail because of the way
they are operated and used. The quality of training received by the personnel involved with the
system in various capacities helps or hinders. Those who will be associated with or affected by the
system must know in detail that:-

What their roles will be

How they can use the system

What the system will or will not do.

Both systems operators and users need training.

Training Systems Operators

Running of the system successfully depend on the personnel working in the computer
centre. They are responsible for providing the necessary support. Their training must ensure that
they are able to handle all possible operations.

The operators training should include:-

Knowledge of what constitutes normal operation and use, what common malfunctions
may occur, how to recognize them, and what steps to take when they arise.

Operators should be given a troubleshooting list which :

Page 37
 Identifies possible problems and remedies for them,

Names and telephones numbers of individuals to contact when unexpected or unusual problems
arise.

Familiarization with run procedures, which involves working through the sequence of
activities needed to use a new system on an ongoing basis.

User Training

User training may involve:

Equipment use, say a microcomputer is in use, and then in these cases, users must be
instructed first in how to operate the equipment.

It must instruct individuals in troubleshooting the system, determining whether a

problem that arises is caused by the equipment or software or by something they have
done in using the system. Including a troubleshooting guide in system documentation.

User training deals with the operation of the system itself. Training in data coding
emphasizes the methods to be followed in capturing data from transactions or preparing
data needed for decision support activities.

Users will have to prepare disks, load paper into printers, or change ribbons on printers.
In other words user training must include some time devoted to systems maintenance
activities.

5.6 Post Implementation Review

After the system is implemented and conversion is complete, a review should be

conducted to determine whether the system is meeting expectations and where improvements
are needed.

A post implementation review measures the systems performance against pre-defined

requirements. It determines how well the system continues to meet performance specifications.

A post implementation review is an evaluation of a system in terms of the extent to which the
system accomplishes stated objectives and actual project costs exceed initial estimates. It is

Page 38
usually a review of major problems that need converting and those that surfaced during the
implementation phase.

The post implementation study begins with the review team, which gathers and reviews
requests for evaluation. Unexpected change in the system that affects the user or system
performance is a primary factor that prompts system review. Once request is filed, the user is
asked how well the system is functioning to specifications or how well the measured benefits
have been realized. Suggestions regarding changes and improvements are also asked for.

6. SYSTEM MAINTENANCE

Once the system is delivered and installed, there is a brief warranty period during which time
the sales unit is responsible for maintenance. The last part of the system development life cycle is
system maintenance which is actually the implementation of the post-implementation review
plan. When systems are installed, they are generally used for long periods. However, this period of
use brings with it the need to continually maintain the system.

The study on the maintenance requirement for the information system revealed that:

a) 60-90 per cent of the overall cost of software during the life of a system is spent on
maintenance.

b) In documented cases, the cost of maintenance, when measured on the basis of writing
each instruction in coding form, is more than 50 times the cost of developing a system.

c) The software demand is increasing at faster rate than supply. Many programmers are
devoting more time on systems maintenance than on new software development. There is
a backlog of new development work.

The maintenance can be classified as corrective, adaption or perfective. Corrective

maintenance means repairing, processing or performance failures or making alteration s because
of previously ill-defined problems. Adaption maintenance means changing the program functions.
Enhancing the performance or modifying the programs according to users additional or changing
Page 39
needs is included in perfective maintenance. Maintenance covers a wide range of activities
including correcting coding and design errors, updating documentation and test data and
upgrading user support.

The keys to reduce the need for maintenance while making it possible to carry on with
essential tasks more efficiently are as follows:

a) More accurately defining the users requirement during systems development.

b) Preparation of system documentation in a better way.

c) Using more effective ways for designing processing logic and communicating it to
project team members.

d) Making better use of existing tools and techniques.

e) Managing the systems engineering process effectively.

An addition factor in the success of the maintenance programmer is the work

environment. Maintenance programmers have generally been paid less amount and receive less
recognition than other programmers. Maintenance demands more orientation and training than
any other programming activities, especially for entry-level programmers. The environment must
recognize the needs of the maintenance programmer for tools, methods and training.

7. FUTURE SCOPE

1. This model can be enhanced and applied to similar product categories of special
operations like Automobiles, Property, Books etc. and other B2C Ecommerce websites.

2. Initially it is text based which can be enhanced to support multimedia and hypermedia
application. The items can be displayed in the audio and video format.

3. A Web based application needs provision to support scalability to cater to growth. The
Architecture should support the constant continuous growth of operation.

Page 40
 4. Dynamic and periodic pupations of data information flow ,operations of data information
flows, operation required.

5. Security features, fraudulent transactions to be properly taken care of .Theft or misuse of

any kind should be averted and system should have built in feature for prevention of such
things and protection.

6. Faster processing of information as compared to the current system with high accuracy
and reliability.

7. Automatic and error free report generation as per the specified format.

8. Automatic calculation and generation of correct and precise Bills-thus reducing much of
the workload on the accounting staff and the errors arising due to manual calculations.

9. Better vigilance of the Salesmen and tracking of carats is now possible.

10. Better sales management is foreseen with the a few enhancements in this application.

A future application of this system lies in the fact that the proposed system would remain relevant
in the future. In case there be any additions or deletion of the products, addition or deletion of any
salesman in the any type of modification in future can be implemented easily.

Bibliography

1) WWW.GOOGLE.COM

2) WWW.WIKIPEDIA.COM

4) BLACK BOOK

Page 41
 BIBLIOGRAPHY

The books which I referred during the development of this project where of great

Help to me. It assisted me a lot and rather gave me the confidence to perform such a work. The
name of some of these books is listed below:

1. Visual C# (Beginning C#)

By Microsoft Training Academy

2 C#.Net

By E.Balagurusamy

(Tata McGraw-Hill Publishing Company Ltd.)

3. Software Engineering(Fifth Edition)

By Pankaj Jalote, Ph.D.

(MC Graw Hill)

Page 42
 I am very grateful to the writers of these books which has been of great help to me. I am
really very thankful to them.

Page 43