Вы находитесь на странице: 1из 59

VIBRANT GUJARAT 080240107089

Practical-1 : CASE STUDY


Study of different software engineering models.

THE WATERFALL MODEL

Sometimes called the classic life cycle or the waterfall model, the linear sequential
model suggest a systematic, sequential approach to software that begins at the system
level & progresses through analysis, design, coding, testing, and sup- port. Figure
illustrates the linear sequential model for software engineering. Modeled after a
conventional engineering cycle, the linear sequential model encompasses the following
activities:

System/information engineering and modeling.

Because software is always part of a larger system (or business), work begins by
establishing requirements for all system elements and then allocating some subset of these
requirements to software. This system view is essential when software must interact

with other elements. such as hardware, people, and databases. System engineering and
analysis encompass requirements gathering at the system level with a small amount of top
level design and analysis. Information engineering encompasses requirements gathering at
the strategic business level and at the business area level.

HGCE Page 1
VIBRANT GUJARAT 080240107089

Software requirements analysis.


The requirements gathering process is intensified and focused specifically on software. To
understand the nature of the program(s) to be
built, the software engineer ("analyst") must understand the information domain for the
software, as well as required function, behavior, performance, and interface. Requirements
for both the system and the software are documented and reviewed with the customer.

Design.
Software design is actually a multistep process that focuses on four distinct attributes of a
program: data structure, software architecture, interface representations, and procedural
(algorithmic) detail. The design process translates requirements into a representation of the
software that can be assessed for quality before coding begins. Like requirements, the
design is documented and becomes part of the software configuration.

Code generation.
The design must be translated into a machine-readable form. The code generation step
performs this task. If design is performed in a detailed manner, code generation can be
accomplished mechanistically.

Testing.
Once code has been generated, program testing begins. The testing process focuses on the
logical internals of the software, ensuring that all statements have been tested, and on the
functional externals; that is, conducting tests to uncover errors and ensure that defined
input will produce actual results that agree with required results.

Support.
Software will undoubtedly undergo change after it is delivered to the customer (a possible
exception is embedded software). Change will occur because errors have been
encountered, because the software must be adapted to accommodate changes in its
external environment (e.g., a change required because of a new operating system or
peripheral device), or because the customer requires functional or performance
enhancements. Software support/maintenance reapplies each of the preceding phases to an
existing program rather than a new one.
The linear sequential model is the oldest and the most widely used paradigm for
software engineering. However, criticism of the paradigm has caused even active
supporters to question its efficacy [HAN95]. Among the problems that are sometimes
encountered when the linear sequential model is applied are:

HGCE Page 2
VIBRANT GUJARAT 080240107089

1. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The linear
sequential model requires this and has difficulty accommodating the natural uncertainty
that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not be
available until late in the project time-span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.
In an interesting analysis of actual projects Bradac [BRA94], found that the
linear nature of the classic life cycle leads to “blocking states” in which some project
team members must wait for other members of the team to complete dependent tasks. In
fact, the time spent waiting can exceed the time spent on productive work! The block- ing
statetends to be more prevalent at the beginning and end of a linear sequential process.
Each of these problems is real. However, the classic life cycle paradigm
has a definite and important place in software engineering work. It provides a template
into which methods for analysis, design, coding, testing, and support can be placed. The
classic life cycle remains a widely used procedural model for software engineering. While
it does have weaknesses, it is significantly better than a haphazard approach to software
development.

THE PROTOTYPING MODEL

Often, a customer defines a set of general objectives for software but does not identify
detailed input, processing, or output requirements. In other cases, the developer may be
unsure of the efficiency of an algorithm, the adaptability of an operating system, or the
form that human/machine interaction should take. In these, and many other situations, a
prototyping paradigm may offer the best approach.

The prototyping paradigm (the following figure) begins with requirements gathering.
Developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
A "quick design" then occurs. The quick design focuses on a representation of those
aspects of the software that will be visible to the customer/user (e.g., input approaches and
output formats). The quick design leads to the construction of

HGCE Page 3
VIBRANT GUJARAT 080240107089

a prototype. The prototype is evaluated by the customer/user and used to refine


requirements for the software to be developed. Iteration occurs as the prototype is tuned to
satisfy the needs of the customer, while at the same time enabling the developer to better
understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software
requirements. If a working prototype is built, the developer attempts to use existing
program fragments or applies tools (e.g., report generators, window managers) that enable
working programs to be generated quickly.
But what do we do with the prototype when it has served the purpose just
described? Brooks [BRO75] provides an answer:

In most projects, the first system built is barely usable. It may be too slow, too big,
awkward in use or all three. There is no alternative but to start again, smarting but smarter,
and build a redesigned version in which these problems are solved . . . When a new system
concept
or new technology is used, one has to build a system to throw away, for even the best
planning is not so omniscient as to get it right the first time. The management question,
therefore, is not whether to build a pilot system and throw it away. You will do that. The
only question is whether to plan in advance to build a throwaway, or to promise to deliver
the throwaway to customers . . .

The prototype can serve as "the first system." The one that Brooks
recommends we throw away. But this may be an idealized view. It is true that both

HGCE Page 4
VIBRANT GUJARAT 080240107089

customers and developers like the prototyping paradigm. Users get a feel for the actual
system and developers get to build something immediately. Yet, prototyping can also be
problematic for the following reasons:

1.. The customer sees what appears to be a working version of the software, unaware that
the prototype is held together “with chewing gum and baling wire,” unaware that in the
rush to get it working no one has considered over all software quality or long-term
maintainability. When informed that the product must be rebuilt so that high levels of
quality can be maintained, the customer cries foul and demands that "a few fixes" be
applied to make the prototype a working product. Too often, software development
management relents.

2.. The developer often makes implementation compromises in order to get a prototype
working quickly. An inappropriate operating system or programming language may be
used simply because it is available and known; an inefficient algorithm may be
implemented simply to demonstrate capability. After a time, the developer may become
familiar with these choices and forget all the reasons why they were inappropriate. The
less-than-ideal choice has now become an integral part of the system.

Although problems can occur, prototyping can be an effective paradigm for


software engineering. The key is to define the rules of the game at the beginning; that is,
the customer and developer must both agree that the prototype is built to serve as a
mechanism for defining requirements. It is then discarded (at least in part) and the actual
software is engineered with an eye toward quality and maintainability.

THE INCREMENTAL MODEL

The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping. Referring to Figure, the
incremental model applies linear sequences in a staggered fashion as calendar time
progresses. Each linear sequence produces a deliverable “increment” of the software
[MDE93]. For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production
functions in the first increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment. It should be noted
that the process flow for any increment can incorporate the prototyping paradigm.
When an incremental model is used, the first increment is often a core
product. That is, basic requirements are addressed, but many supplementary features
(some known, others unknown) remain undelivered. The core product is used by the
customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is
developed for the next increment. The plan addresses the modification of the core product
to better meet the needs of the customer and the delivery of additional features and

HGCE Page 5
VIBRANT GUJARAT 080240107089

functionality. This process is repeated following the delivery of each increment, until the
complete product is produced.

The incremental process model, like prototyping and other evolutionary approaches, is
iterative in nature. But unlike prototyping, the incremental each increment model focuses
on the delivery of an operational product with. Early increments are stripped down
versions of the final product, but they do provide capability that serves the user and also
provide a platform for evaluation by the user Incremental development is particularly
useful when staffing is unavailable for a complete implementation by the business
deadline that has been established for the project. Early increments can be implemented
with fewer people. If the core product is well received, then additional staff (if required)
can be added to implement the next increment. In addition, increments can be planned to
manage technical risks. For example, a major system might require the availability of new
hardware that is under development and whose delivery date is uncertain. It might be
possible to plan early increments in a way that avoids the use of this hardware, thereby
enabling partial functionality to be delivered to end-users without inordinate delay.

THE SPIRAL MODEL

The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software


process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model. It provides the potential for rapid

HGCE Page 6
VIBRANT GUJARAT 080240107089

development of incremental versions of the software. Using the spiral model, soft ware is
developed in a series of incremental releases. During early iterations, the incremental
release might be a paper model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced.
A spiral model is divided into a number of framework activities, also called
regions. Typically, there are between three and six task regions. Figure depicts a spiral
model that contains six task regions.

• Customer communication-- tasks required to establish effective communication


between developer and customer.

• Planning-- tasks required to define resources, timelines, and other project related
information

• Risk analysis-- tasks required to assess both technical and management risks.

• Engineering-- tasks required to build one or more representations of the application.

• Construction and release-- tasks required to construct, test, install, and provide user
support (e.g., documentation and training).

• Customer evaluation-- tasks required to obtain customer feedback based on evaluation


of the software representations created during the engineering stage and implemented
during the installation stage.

HGCE Page 7
VIBRANT GUJARAT 080240107089

Each of the regions is populated by a set of work tasks, called a task set,
that are adapted to the characteristics of the project to be undertaken. For small projects,
the number of work tasks and their formality is low. For larger, more critical projects, each
task region contains more work tasks that are defined to achieve a higher level of
formality.
As this evolutionary process begins, the software engineering team moves
around the spiral in a clockwise direction, beginning at the center. The first circuit around
the spiral might result in the development of a product specification; subsequent passes
around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software. Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback derived
from customer evaluation. In addition, the project manager adjusts the planned number of
iterations required to complete the software.
Unlike classical process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the computer software. An
alternative view of the spiral model can be considered by examining the project entry
point axis, also shown in Figure . Each cube placed along the axis can be used to represent
the starting point for different types of projects. A “concept development project” starts at
the core of the spiral and will continue (multiple iterations occur along the spiral path that
bounds the central shaded region) until concept development is complete. If the concept is
to be developed into an actual product, the process proceeds through the next cube (new
product development project entry point) and a “new development project” is initiated.
The new product will evolve through a number of iterations around the spiral, following
the path that bounds the region that has somewhat lighter shading than the core. In
essence, the spiral, when characterized in this way, remains operative until the software is
retired. There are times when the process is dormant, but whenever a change is initiated,
the process starts at the appropriate entry point (e.g., product enhancement).
The spiral model is a realistic approach to the development of large-scale
systems and software. Because software evolves as the process progresses, the developer
and customer better understand and react to risks at each evolutionary level. The spiral
model uses prototyping as a risk reduction mechanism but, more important, enables the
developer to apply the prototyping approach at any stage in the evolution of the product. It
maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reects the real world. The
spiral model demands a direct consideration of technical risks at all stages of the project
and, if properly applied, should reduce risks before they become problematic.
But like other paradigms, the spiral model is not a panacea. It may be
difficult to convince customers (particularly in contract situations) that the evolutionary
approach is controllable. It demands considerable risk assessment expertise and relies on
this expertise for success. If a major risk is not uncovered and managed, problems will
undoubtedly occur. Finally, the model has not been used as widely as the linear sequential
or prototyping paradigms. It will take a number of years before efficacy of this important
paradigm can be determined with absolute certainty.

HGCE Page 8
VIBRANT GUJARAT 080240107089

THE RAD MODEL

Rapid application development (RAD) is an incremental software development process


model that emphasizes an extremely short development cycle. The RAD model is a “high-
speed” adaptation of the linear sequential model in which rapid development is achieved
by using component-based construction. If requirements are well understood and project
scope is constrained, the RAD process enables a development team to create a “fully
functional system” within very short time periods (e.g., 60 to 90 days) [MAR91]. Used
primarily for information systems applications, the RAD approach encompasses the
following phases [KER94]:

Business modeling.-- The information flow among business functions is modeled in a


way that answers the following questions: What information drives the business process?
What information is generated? Who generates it? Where does the information go? Who
processes it?

Data modeling.-- The information flow defined as part of the business modeling phase
is refined into a set of data objects that are needed to support the business. The
characteristics (called attributes ) of each object are identified and the relationships
between these objects defined

HGCE Page 9
VIBRANT GUJARAT 080240107089

Process modeling.-- The data objects defined in the data modeling phase are trans
formed to achieve the information flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a data
object.

Application generation.-- RAD assumes the use of fourth generation techniques


Rather than creating software using conventional third generation programming languages
the RAD process works to reuse existing program components (when possible) or create
reusable components (when necessary). In all cases, automated tools are used to facilitate
construction of the software.

Testing and turnover.-- Since the RAD process emphasizes reuse, many of the
program components have already been tested. This reduces overall testing time.
However, new components must be tested and all interfaces must be fully exercised.

The RAD process model is illustrated in Figure Obviously, the time


constraints imposed on a RAD project demand “scalable scope” [KER94]. If a business

HGCE Page 10
VIBRANT GUJARAT 080240107089

application can be modularized in a way that enables each major function to be completed
in less than three months (using the approach described previously), it is a candidate for
RAD. Each major function can be addressed by a separate RAD team and then integrated
to form a whole.

Like all process models, the RAD approach has drawbacks [BUT94]:
• For large but scalable projects, RAD requires sufficient human resources to create the
right number of RAD teams.
• RAD requires developers and customers who are committed to the rapid-fire activities
necessary to get a system complete in a much abbreviated time frame. If commitment is
lacking from either constituency, RAD projects will fail.
• Not all types of applications are appropriate for RAD. If a system cannot be properly
modularized, building the components necessary for RAD will be problematic. If high
performance is an issue and performance is to be achieved through tuning the interfaces to
system components, the RAD approach may not work.
• RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software requires a high
degree of interoperability with existing computer programs.

HGCE Page 11
VIBRANT GUJARAT 080240107089

ACKNOWLEDGEMENT

We express our sincere thanks to Mr.Nikhil shah for his constant


guidance and support in the understanding, analyzing, designing during the
project. In spite of being very busy, he always ready to help us whenever
and whatever is being required. He provides us continuous guidance and
aware us about our project and in each and every stage of Analysis, Design,
& Development .

Last but not the lease we are thankful to all of my friends and also the well
us

Richa Patel
Mansi Vachhani
Khushbu Khatri
Rupal Parmar

HGCE Page 12
VIBRANT GUJARAT 080240107089

ABSTRACT
The website of “VIBRANT GUJARAT” shows the growth and achievement
of Gujarat. It gives the information about Gujarat like History, Tourism, 5th Global
Summit held, currently running major projects, etc.

The Vibrant Gujarat Summit has become a model for economic success for
many states. This event provides a great opportunity to the State to display its
strengths, progressive stance, initiatives taken to improve governance, investor
friendly climate and art & culture of Gujarat. The event not only gives local players
an opportunity to interact with national and international players, but also with top
Government officials from various departments and sectors. This event encourages
the bureaucracy, and motivates government workers and agencies to work hard and
get organized.

Vibrant Gujarat 2011 succeeded in establishing Gujarat as the most favored


destination of India along with sharing of knowledge and technology from across the
world. Participation of different Countries and Indian States who used the platform
for showcasing their strength has contributed towards ‘Vibrant Gujarat’ summit
transforming itself into the premier business and knowledge summit of the Country.

HGCE Page 13
VIBRANT GUJARAT 080240107089

CHAPTER- 1

INTRODUCTION

OF CURRENT PROJECT

HGCE Page 14
VIBRANT GUJARAT 080240107089

1.1 PROJECT SUMMARY:

The website of Vibrant Gujarat is a comprehensive web-based. It is designed to


get knowledge about Gujarat. The visitor can get full knowledge about Gujarat like
History, Tourism, 5th Global Summit held, currently running major projects, etc.

In history section imparts information regarding Gujarat’s history. In tourism


section user will get information about famous places in Gujarat. In Major project
section, it gives the knowledge of currently running major projects like River Front,
Mahatma Mandir and BRTS project. The 5th Global summit shows the deal and event
happened during summit held.

1.2 PURPOSE:

1.2.1 Goal:

1. To develop an efficient and useful website.


2. To provide all the essential requirements for better working of the website.
3. To make the website user friendly and increase the satisfaction among the user.
4. To store all information of Gujarat.

1.2.2 Objectives:

1. To provide easy access to users by providing facility to see data any time.
2. To provide various functionalities and various information to users regarding
the current system.
3. To allow the users to easily access various functionalities of the website.

1.3 SCOPE:

We will improve service by providing an information system to respond to visitor’s


inquiries. Software scope is defined by addressing context, function and performance.

1.3.1 Context

VIBRANT GUJARAT is a online that can hosted on internet and accessible by website
visitors.

HGCE Page 15
VIBRANT GUJARAT 080240107089

1.3.2 Function and Performance:

What it can do?

To provide online access to all the users for 24 hours. Visitors can access full
access on it. They can check any information at any time.

What it can’t do?

This website has some limitation provides limited information. Also it doesn’t
allow some functionalities to validate online requirements.

1.4 TECHNOLOGY AND LITERATURE OVERVIEW

1.4.1 What is HTML?

HTML is a language for describing web pages.

• HTML stands for Hyper Text Markup Language


• HTML is not a programming language, it is a markup language
• A markup language is a set of markup tags
• HTML uses markup tags to describe web pages

HTML Tags

HTML markup tags are usually called HTML tags

• HTML tags are keywords surrounded by angle brackets like <html>


• HTML tags normally come in pairs like <b> and </b>
• The first tag in a pair is the start tag, the second tag is the end tag
• Start and end tags are also called opening tags and closing tags

HTML Documents = Web Pages

• HTML documents describe web pages


• HTML documents contain HTML tags and plain text
• HTML documents are also called web pages

The purpose of a web browser (like Internet Explorer or Firefox) is to read HTML
documents and display them as web pages. The browser does not display the HTML
tags, but uses the tags to interpret the content of the page:

HGCE Page 16
VIBRANT GUJARAT 080240107089

1.4.2 What is CSS?

• CSS stands for Cascading Style Sheets


• Styles define how to display HTML elements
• Styles were added to HTML 4.0 to solve a problem
• External Style Sheets can save a lot of work
• External Style Sheets are stored in CSS files

Styles Solved a Big Problem


HTML was never intended to contain tags for formatting a document.
HTML was intended to define the content of a document, like:

<h1>This is a heading</h1>
<p>This is a paragraph.</p>

When tags like <font>, and color attributes were added to the HTML 3.2 specification, it
started a nightmare for web developers. Development of large web sites, where fonts and
color information were added to every single page, became a long and expensive process.
To solve this problem, the World Wide Web Consortium (W3C) created CSS.

In HTML 4.0, all formatting could be removed from the HTML document, and stored in
a separate CSS file.
All browsers support CSS today.
CSS Saves a Lot of Work!
CSS defines HOW HTML elements are to be displayed.
Styles are normally saved in external .css files. External style sheets enable you to change
the appearance and layout of all the pages in a Web site, just by editing one single file!

HGCE Page 17
VIBRANT GUJARAT 080240107089

CHAPTER-2
PROJECT MANAGEMENT

HGCE Page 18
VIBRANT GUJARAT 080240107089

2.1 PROJECT PLANNING AND SCHEDULING:

2.1.1 Project Development Approach

Waterfall Model

As the process model for our project we use Waterfall model .The definition of business
requirements, design, build and test are undertaken in a linear fashion. Provided the
desired project outcomes can be clearly defined from the outset, this approach is swift
and effective. Difficulties arise when unforeseen risks are encountered in later stages,
requiring an unwinding of the process and the generation of significant project rework.
The waterfall model is well understood and time tested but generally considered to be
less useful than it once was due to the increasing complexity of systems. It “works well
for automating the tasks of clerks and accountants, less well for knowledge works such as
experts trying to solve problems” (Information Center Quarterly article, Larry Runge).
Another problem is that in the waterfall model users only input is in specifying
requirements and that all requirements must be specified at one points before production
begins. However, requirements typically change through the process and require more
feedback.

We use waterfall model because,

HGCE Page 19
VIBRANT GUJARAT 080240107089

• It is easy for managers to understand, plan by and to test progress against as it has
very clear sequential milestones
• It encourages good design practices such as early clarification of system goals,
which in turn save time and money (the earlier a bug is caught, the less harm it
can cause)

• Due to lots of up front design planning, should the project be stopped and taken
up at a later date, or should project members change, implementation can continue
far easier than with more agile development models where there is considerably
less design documentation.

• It is compatible with a wide range of design strategies

• In sense of 10% customization in this model , users may change requirements


often, at stages beyond the requirements stage

• In sense of testing, constant verification of each stage is required to ensure that


the next phase can start on a correct base Technology may change during
development.

2.1.2 Project Plan:

Project planning is one of the major tasks that are performed during the development of
the project. Using project planning, the task of finding the size of the project is done and
with that total amount of time and cost required for project development is calculated.

Planning of this project was done using a special approach. After getting the project
definition, upper level analysis was performed first. That analysis was confined to the
whole project level. That analysis gave the idea about the size and the structure of the
project and using that analysis information, planning of the project was done.

The approach to develop the software system should follow some systematic way i.e.
Software Development Life Cycle. Using the upper level analysis and the environment of
the project, which lifecycle model would fit properly for this project for this project was
judged. After deciding the proper software development lifecycle model, the
development of this project according to the model was done.

Milestones:

The project milestone can be identified during the development of the project. Milestone
associated with the system is the web based project and so lots of validation are needed to
be provided with the system as any type of end user can use it.

Deliverables:

HGCE Page 20
VIBRANT GUJARAT 080240107089

The deliverables of the system is to get the all the services be useful for the end users and
deliver an easy and required services. So maximum user satisfaction needs to be
achieved.

Dependencies:

System is dependent on all the information about Gujarat development. All the
information that is stored in various tables are related to each other. So all the information
is interdependent on each other.

Project Team:

Our project team consists of following members:

RICHA PATEL
MANSI VACHHANI
RUPAL PARMAR
KHUSHBU KHATRI

The “best” team structure depends on the management style of the organization,
the number of people who will populate the team and their skill levels, and the overall
problem difficulty.

We are working as a team of two persons. By system analysis & design we


partitioned our project into manageable modules. Then according to the time &
availability of a member of the team, the work was assigned among us. Hence, this
helped us in parallel development of project and give sufficient time & attention to
every module & stage of project.

2.2 RISK MANAGEMENT:

2.2.1 Risk Identification:

Some roughly predicted risks which may arise in our project development are:
Project Risk:
• Institute Management System is a very scientific application. Developers
and users must have basic knowledge of functionality of Institute
Management System(IMS).

Technical Risk:

HGCE Page 21
VIBRANT GUJARAT 080240107089

• The user/operator must have some basic knowledge of ASP technology.


• It may not be possible for us to complete the project in given strict time
deadline if we try to add all functionalities to IMS.

2.2.3 Risk Planning:

Interviewing:

More number of times the requirements were gathered and filtered so more refined data
was collected so as the chances of changes in software would be minimal and risk of the
irregular communication could be avoided.\

Research:

A lot of research was done and major part of information was collect through old
developed system and past system literature works.

Studied old works:

Many new-purposed advanced technologies were studied through this project


development duration and old system pseudo codes were quiet studied in depth to avoid
the technical risk.

2.3 Estimation:

2.3.1 Effort Estimation:

“Software project scheduling is an activity that distributes estimated efforts across the
planned duration by allocating the effort to specific software engineering tasks.”

Program Evaluation And Review Technique (PERT) and Critical Path Method (CPM)
are two most widely used techniques in project management. Historically speaking,
PERT and CPM developed independently out of research studies conducted by U.S.
Navy and DuPont Company. The PERT was applied to Research and Development tools,
while CPM was used to construct the projects.
These two project management & scheduling method that can be applied to software
development. Both techniques are driven by information already developed in earlier
project planning activities:

• Estimation of effort.
• A decomposition of the product function.
• The selection of appropriate process model and task set.
• Decomposition of tasks.

HGCE Page 22
VIBRANT GUJARAT 080240107089

There are some differences between PERT and CPM for selecting it as project
management technique like:

In PERT total project duration is regarded as a random variable and therefore associated
probabilities are calculated to characterize it. PERT is normally used for project
involving activities of non- repetitive in nature which time estimates are uncertain.

PERT helps in pin pointing critical areas in a project so that necessary adjustment can be
made to meet the scheduled completion date of the project. While In CPM duration was
known with certainty, therefore it is deterministic approach. It involves repetitive
activities.

HGCE Page 23
VIBRANT GUJARAT 080240107089

CHAPTER 3

SYSTEM REQUIREMENTS STUDY

HGCE Page 24
VIBRANT GUJARAT 080240107089

3.1 USER CHARACTERSTICS:

This project is a package of various modules that are used for various utilities. So,
different users will interact with the packages.

1. Administrator :

Administrator is the main user who has all access permission. She/he is able to do
any activity that is related do this online application. Admin can use any functions that
are provided in application. Admin can update, insert, delete any records. Any stored
information can be accessed or retrieved by the Admin at any time.

2. User :

As we all know Vibrant Gujarat is directly and indirectly connected to the people.
But this online application has been developed in a way that the people are not able to
surf the all pages. User can get information about Vibrant Gujarat.

3.2 HARDWARE AND SOFTWARE REQUIREMENTS:

Server Side Requirements:

Hardware Requirements:
• P4 processor
• 128 MB Ram or above
• 5GB hard disk space
• 104 keyboard, mouse, monitor.

Software Requirement:

Operating System:

• Windows XP Professional or higher

Software Tools:

• HTML

HGCE Page 25
VIBRANT GUJARAT 080240107089

Client Side Requirements:

Hardware Requirements:

• P4 Processor
• 128 MB Ram or above
• 5GB hard disk space
• 104 keyboard, mouse, monitor.

Software Requirements:

Operating System:

• Windows XP Professional or higher

Software Tools:

• Higher Internet Explorer 6.0


• Mozilla Web browser

3.3 CONSTRAINTS:

There are some constrains of developing this Web portal:

• This website provides limited information about Gujarat. To view this web site
must need Web browser.

• In this web portal, only limited users are allowed to access the information.

3.3.1 Regulatory Policies:

The regulatory policy provided for the application is shown in table. It matches the User
ID and Password with administrator table and provides the access according to the user.

Field Name Field Description


User ID Enter User id for login.

HGCE Page 26
VIBRANT GUJARAT 080240107089

Password Enter Password for login.

Table: 3.1 Field Functionality

Button Name Description


Login Click to login into user profile

Table: 3.2 Button Functionality

3.3.2 Interfaces to Other Applications:

Basically this application will be independent and will be capable to operate alone
provided that data sources are available.

3.3.3 Parallel Operation:

Parallel operation is possible as it is connected through web and as much as no. of clients
Which supports the connection pool can access this web portal.

3.3.4 Higher Order Language Requirements:

We are using HTML as the coding language.

3.3.5 Reliability Requirements:

Reliability of system is complex concept, which should always be considered at the


System rather than the individual component level. Because the components is a system
interdependent, a failure in one component can be propagated thorough the system and
affect the operation of together components. We have prepared reliability metrics were
first devised for hardware components. Hardware component failure is inevitable due to
physical factors such as mechanical abrasion, electrical heating, etc.

3.3.6 Safety and Security Consideration:

The application is secure enough as here is the system where username and password are
Not shown on the URL while loading the web portal and back button is clicked it is
logout
automatically so to sign in again. And the query are not applied directly instead
procedure
database is used to pass username and password

HGCE Page 27
VIBRANT GUJARAT 080240107089

CHAPTER-4
SYSTEM ANALYSIS

HGCE Page 28
VIBRANT GUJARAT 080240107089

4.1 STUDY OF CURRENT SYSTEM:

VG is a comprehensive web-based Information site. This web site provides latest


information about growth and development of Gujarat. This web site gives better
information about Gujarat.

4.2 PROBLEM AND WEAKNESS OF CURRENT SYSTEM:


• Earlier information gathering process was difficult.

• The information gathering was costly before.

• Some time too time consuming to get particular information from the Internet.

4.3 REQUIREMENT OF NEW SPECIFICATION:

User who knows how to use internet can easily use our website otherwise only little bit
training can make them able to use our website easily.

Functional Requirements:

Following are the basic functions our project is required to perform:


Information:
Our website provides all latest information and history of Gujarat.
The information about currently running projects, global summit and tourism of Gujarat.

Non-Functional Requirements:
User Interface:
User should be provided a friendly interface.

HGCE Page 29
VIBRANT GUJARAT 080240107089

Response Time:
It is the difference of time between giving input & getting desired output. Conversion
must take place quickly. Means our program code should not take much time to give
desire output.

4.4 FEASIBILITY STUDY:

A Feasibility Study is a preliminary study undertaken before the real work of a project
starts to ascertain the likelihood of the project’s success. It is an analysis of all possible
solutions to a problem and a recommendation on the best solution to use. It involves
evaluating how the solution will fit into the corporation.

A Feasibility Study is a short, focused study, which aims to answer a number of


questions:
• Does the system contribute to the overall objectives of the
organization?
• Can the system implemented using the current technology and within
given cost and schedule constraints?
• Can the system be integrated with systems which are all ready in the
place?

There are various types of feasibility studies…

Operational Feasibility
Technical Feasibility
Scheduling Feasibility
Economical Feasibility
Implementation Feasibility
Now each of them is explained briefly, as below

Operational Feasibility:

HGCE Page 30
VIBRANT GUJARAT 080240107089

Operational Feasibility measures how well the solution will work in the organization and
how end user & management will feel about the system. Proposed system is helpful for
the scientists, researchers, developers, geologists, engineers, etc. It will allow them to
query them to get the appropriate and adequate information. Here are the questions that
will help test the operational feasibility of the project.
1) Is there sufficient support for the project from the management? From the users? If the
current a system is well liked and used to the extent that person will not be able to see for
a change, there may be resistance.
Ans: Yes there is a enough and more support and motivation from the management. The
existing system has got series of limitations that has been mentioned in the earlier
chapters.
2) Are current methods acceptable to the users? If they are not, users may welcome a
change that will bring about a more operational and useful system.
Ans: No the current methods are not completely acceptable to the users, which leaded to
the requirement of the new enhanced software.
3) Have the users been involved in the planning and development of the project?
Ans: Yes, the users are completely engrossed in the planning and development of the
projects, at each stage the users gives the feed back to the developers as per their
requirements.
4) Will the proposed system cause harm? Will it produce poor result in any respect or
area? Will loss of controlled result in any area? Will accessibility of information be lost?
Will individual performance be poor after implementation, than before? Will users be
affected in undesirable way? Will the systems slow performance in any area?
Ans: No. the proposed system will in no way produce wrong results; it will all together
Won’t produce outputs, but will never produce error some outputs. No, the accessibility
to information will not be lost. Yes, if the attached file is larger then it does take bit of
more time to process, due to huge amount of byte size, for sending it to the server.
 On studying the operational feasibility of the project, the following
conclusions could be derived:

HGCE Page 31
VIBRANT GUJARAT 080240107089

 Operationally the software will be most feasible due to its strong


requirement for the school management.

 Due to good accuracy percentage of software, it can be easily deployed.

 Due to its easy functionality for users , who are not from IT background
easily, can use the software.

Thus, it is operationally feasible to develop the proposed system.

Technical Feasibility:

Can the work for the project be done with current equipment, existing software
technology and available personnel? If the new technology is required, what is the
likelihood that it can be developed? All the answers to the above and below given
questions comprises of the technical feasibility. Technical feasibility tries to answer the
following question to make the software feasible to develop.

• The software or tools necessary for building and running the application
are easily available or not?

• The compatibility amongst software exists or not?

• Are developers aware of these technologies?

• What about the alternative of these chosen technologies?

In this project, ASP Technology is used, which is most feasible for this application due to
following reasons:

• ASP with VB has OOPS structure so it offers many features, which are not
present in most of other languages. ASP handles Graphics elegantly.

HGCE Page 32
VIBRANT GUJARAT 080240107089

• The selected technologies have greater advantages over other challenger


technologies.

SDK is freely available from the Microsoft.

Schedule Feasibility:

Projects are initiated with specific deadline. We need to evaluated whether the deadline
are mandatory or desirable. Time is the one of the critical and crucial factor in the
development of any system but this kind of feasibility is hardly perfect in any system.
We have been asked to complete the project within the working days of the organization
having period of 3-4 months approximately. So we have managed to complete the project
before given deadline. In the project planning section we elaborate our ideas to develop
the system within the given period. Please refer to that section for through idea.
Hence, it is feasible to develop a system in predetermined time interval.

Economic Feasibility:

o Economical feasibility address to the following issues:

o Is organization having the suitable budget to develop the proposed


system?

o How much profit can be earned from the system by an organization?

o Would it be cost-effective to develop the system or it is worthwhile to


remain with current system?

We would like to answer for the above question, as given below:

• No training is required.

• Processors are already available so no hardware cost is added.

HGCE Page 33
VIBRANT GUJARAT 080240107089

Commercial software is costly as compared to the indigenous software designed by the


institute itself. So, the cost of hardware necessary for deploying the software & the cost
of actual software is reduced to almost zero so this software is economically feasible.

Implementation Feasibility:

Under the study of implementation feasibility, we‘ve got to the certain issues, like:
• It is possible to install the software within the given government?

• Will organization management and users support for the installation of the
software?

• Will proposed system cause any harm to the operations of the


organization?

The overall strategy that is well decided implies the feasibility of the project
implementation. The software components are light weight and easily manageable and so
forth easy to handle during implementation.

Operationally, this system can be installed and it can work according to its
functionalities. There would be very little barriers in implementation, if application will
be prepared according to the hardware barriers. The management has already approved
this software to be developed and it won’t cause any harm to user operation or day-today
activities

4.5 REQUIREMENT VALIDATION:


Requirement Validation is concerned with showing that the requirements actually define
the system which the customer wants.

It means that the developed software is as per requirement or not? Simply stating
whatever we are doing is right or wrong as per requirements? Here we check each and

HGCE Page 34
VIBRANT GUJARAT 080240107089

every requirement and compare with our product and that it satisfies the user need. It is a
most crucial part of analysis phase. If the validation is inadequate, errors in requirements
will be propagated to the system design and implementation. For validating the
requirements, our project guide, and guided us at every stage of analysis.

Admin Login:
 If the admin has already id and password then he can directly login

 A new admin first must fill the registration form to get the admin-
id and password.

 Here the specified range must be followed for entering the


password.

 Here the retype password is again asked to ensure the security of


the password.

Date of Birth:

 Date of Birth has a Day, a Month, and a Year.

 Here the specified range for a day say from 1 to 31 must be


followed.

 Here the specified range for a month say from 1 to 12 must be


followed.

 Here the specified range for a year say from 1970 to 2005 must be
followed.

Empty Fill Check:


If any field is compulsory and if that one is left blank then an error message will be
displayed

HGCE Page 35
VIBRANT GUJARAT 080240107089

PRACTICAL 3
Draw different diagrams for your current project

4.6 Function Of System: VERIFIED USER


4.6.1 USE CASE DIAGRAM
<<excludes>>
<<excludes>>

LOGIN REMOVE
USER

SURF
INFORMATION
ADD USER

ADD
INFORMATIO
USER N

MAJOR ADMIN
HISTORY PROJECT
GLAOBA
L S
SUMMIT

GUJARAT
TOURISM

HGCE Page 36
GUJARAT AT A
GLANCE
VIBRANT GUJARAT 080240107089

4.7 DATA MODELLING::


4.7.1 ENTITY-RELATIONSHIP DIAGRAM

HGCE Page 37
VIBRANT GUJARAT 080240107089

4.7.2 SEQUENCE DIAGRAM

4.7.2.1 LOGIN

HGCE Page 38
VIBRANT GUJARAT 080240107089

ADMIN USER LOGIN VG

ADMIN MASTER
USER NAME

PASSWORD
SUCCESSFUL
LOGIN
INVALID
USER

4.7.2.2 ADMIN-SEQUENCE DIAGRAM

HGCE Page 39
VIBRANT GUJARAT 080240107089

4.7.2.3 INFORMATION-SEQUENCE DIAGRAM

HGCE Page 40
VIBRANT GUJARAT 080240107089

4.8 Functional & Behavioral Modeling


4.8.1.1 LOGIN

HGCE Page 41
VIBRANT GUJARAT 080240107089

4.9 FLOW CHART

Admin Flow Chart

HGCE Page 42
VIBRANT GUJARAT 080240107089

Gujarat At
a Glance

HGCE Page 43
VIBRANT GUJARAT 080240107089

CHAPTER-5
IMPLEMENTATION AND PLANNING

5.1 IMPLEMENTATION ENVIRONMENT:

In this project the implementation environment is Multi-User Environmental the


developers of the project are working on Team Explorer. All can work simultaneously on
the same project. Two developers cannot access same from at the same time. The latest

HGCE Page 44
VIBRANT GUJARAT 080240107089

version of the project can be accessed by any developer at any time. The environment is
GUI-based as the project is developed in Active Server Pages.
Multiple users can be used. Uniform GUI Design SQL server name and authentication
required for normal/network base accessor.
Internet support

5.1.1 Implementation Planning:

Implementation phase requires precise planning and monitoring mechanism in order to


ensure schedule and completeness. We developed the software in various sub phases in
Implementation Phase.

5.1.1.1 Database Implementation:

This phase involved creation of database table and specifying relationships among them
in SQL Server.

5.2 MODULES SPECIFICATION:

1) Admin:
Admin is the main user of the system that has been developed. Admin ,also, main module
of this Institute Management System(IMS). It contains five Forms that make Admin
module complete.
Web Forms for Admin module.

User Master:
To be logged in System it is necessary to have User ID and Password which can be taken
from the User Master contained in Admin Module.

2) History:
This module contains history of Gujarat user can access this page through valid login id.

3) 5Th Global Summit:


This module contains information regarding the latest Summit held, the events took
place during the summit & about the achievements the state got.

HGCE Page 45
VIBRANT GUJARAT 080240107089

4)Major Projects:
This module gives information regarding thr major projects that has been completed as
well as currently running.
Names of major projects are:
1.BRTS
2.Sabarmati Riverfront
3.Mahatma mandir

5) Tourisum:
This module gives information regarding the famous and historical places situated in
Gujarat

5.3 SECURITY FEATURES:

Security is of prime concern while carrying out this online system. This system has
implemented proper security measures such as creating secure space between client

HGCE Page 46
VIBRANT GUJARAT 080240107089

machine and proper access rights control is been implemented, So the system will
provide the secure environment to each system user on terminal to make work easily as
well as return required information in easiest way.

There is sufficient support to project from the management and from the management
and from the intended users of the system. The current business methods can very well be
incorporated into the proposed system. The proposed system has more chance of being
accepted by intended users.

For security purpose, we have used “Session”. The HTTP session API is an essential
component in constructing interactive web sites. This is required because the Hypertext
Transfer Protocol (HTTP) employed for web browser to web server requests is a stateless
protocol. As a result, a web server has no means of associating a series of requests with a
specific browser or user.

Another security features taken into care is of “Encrypting Password”. A secure


computing environment would not be complete without consideration of encryption
technology. The term encryption refers to the practice of obscuring the meaning of a
piece of information by encoding it in such way that it can only be decoded, read and
understood by people for whom the information is intended. It is the process of encoding
data to prevent unauthorized parties from viewing or modifying it

5.4 Coding Standards:


The coding standard is the well-defined and standard style of coding. With the help of the
coding standard any person can go into any code and figure out what's going on and new
people can get up to speed quickly. A coding standard sets out standard ways of doing
several things such as the way variables are to be named, the comments are to be
described, the work of function are to carried out etc.
This section describes the coding standards, which we have used in the program. In the
context of coding standard the tag consists of one to three lower case characters followed
by an underscore and is used to indicate the type of a control, or variable. The action
name applies to stored procedures' names as a prefix.

We have adopted the following coding standards.

Variable Declarations
We have placed the local variable declarations at the beginning of the script.

Block of declarations has aligned.

Naming Conventions

HGCE Page 47
VIBRANT GUJARAT 080240107089

• The name of variable that I have used in script represents the content or purpose
or role of the variable.

• Variable names are declared same as their name meaning.

• Constants name are used with name is preceded by its type. And they are
combined with underscore. As an example, paramlist , userid etc.

Controls

The controls are named according to their type.

Naming conventions of controls

CONTROLS TAG
Radio Button rb
Label lb
GridView grd
TextBox txt
Hyperlink hyplnk
DropDown List ddl

Source Code
• We have added comments for each and every line of code that we have made.
• We have added description of each and every function and their attributes and
parameters.
• Separate the consecutive methods with some “-“character line.
General Coding Standards
• It is acceptable to break up long statements on to multiple lines or leave it in one
long line.
• Do not put multiple statements in one line.
• Every coding block must be indented.

• All the functions, variables and constants have to be declared on the top of the file
in particular form.

PRACTICAL 4

HGCE Page 48
VIBRANT GUJARAT 080240107089

Software testing using testing tools.


(White Box –Black Box Testing)

CHAPTER 6

HGCE Page 49
VIBRANT GUJARAT 080240107089

TESTING
6.1 TESTING PLAN:

The aim of the testing process is to identify all defects existing in software Product.
However for most practical systems, even after satisfactorily carrying out the testing
phase, it is not possible to guarantee that the software is error free. This is because of the
fact that the input data domain of most software products is very large. It is not practical
to test the software exhaustively with respect to each value that the input data may
assume. Even with this practical limitation of the testing process, the importance of
testing should not be underestimated. It must be remembered that testing does expose
many defects existing in a Software product. Thus testing provides a practical way of
reducing defects in a System and increasing the users’ confidence in a developed system.

Functional Testing:

The testing technique that is going to be used in the project is black box testing. In black
box testing the expected inputs to the system are applied and only the outputs are
checked.
The working or the other parameters of the functionality are not reviewed or tested on the
black box testing technique. There is a specific set of inputs for each and every module
which is applied and for each set of inputs the result or the output is verified and if found
as per the system working this testing is termed or result is declared as pass.

If the set of inputs that are provided to each module are not giving the outputs as per the
expected results from the module then the result of that testing is to be declare failed.

Moreover the bottom up integration of the modules is applied herein so that each module
can be verified at the initial stage and if it is found that the independent module is
perfectly alright, only then it is going to be integrated with other related modules
otherwise the module is checked for flaws and then if it satisfies all the specific
requirements of the module, is integrated to other related modules to form and
incorporate a system.

In the black-box testing approach, test cases are designed using only the functional
specification of the software, i.e. without any knowledge of the internal structure of the
software. For this reason, black-box testing is known as functional testing.

Equivalence Class Partitioning:

In this approach, the domain of input values to a program is partitioned into a set of

HGCE Page 50
VIBRANT GUJARAT 080240107089

equivalence classes. This partitioning is done such that the behavior of the program is
similar for every input data belonging to the same equivalence class. The main idea
behind defining the equivalence classes is that testing the code with any one value
belonging to an equivalence class is as good as testing the software with any other value
belonging to that equivalence class. Equivalence classes for software can be designed by
examining the input data and output data.

Boundary Value Analysis:

A type of programming error frequently occurs at the boundaries of different equivalence


classes of inputs. The reason behind such errors might purely be due to psychological
factors. Programmers often fail to see the special processing required by the input values
that lie at the boundary of the different equivalence classes. For example, programmers
may improperly use < instead of <=, or conversely <= for <. Boundary value analysis
leads to selection of test cases at the boundaries of the different equivalence classes.

Structural Testing:

In the white-box testing approach, designing test cases requires thorough knowledge
about the internal structure of software, and therefore the white-box testing is called
structural testing.

Testing Process.

HGCE Page 51
VIBRANT GUJARAT 080240107089

6.2 TESTING STRATEGY:

The black box testing is going to be used for the project. The entire module is going to be
checked for the specific inputs and the output is going to be checked. We are going to test
the modules individually and thereafter if found to be working as per the expectations
they are going to be integrated with other successfully tested modules and then on
integrated.

At last all the modules are integrated and thereafter it is checked on a broader basis and
all the requirements which are specified are checked for each integrated system modules.
If all the functionalities are successfully satisfied than the entire integrated system is
found to be working perfectly alright.

The integration is going to be in a bottom up manner where in each individual modules


are going to be checked for the first time initially. Later on as and when other modules
are developed and are in a working condition than they are integrated and the entire
system is going to be generated. As mentioned before these entire system will finally be
tested as per the requirements specified by the customer if any flaws are seen they are
immediately required to be solved. In short the entire system should be working as per
the requirements with no unexpected results.

6.3 TESTING METHODS


White Box
Also known as glass box, structural, clear box and open box testing. A software testing
technique whereby explicit knowledge of the internal workings of the item being tested
are used to select the test data. Unlike black box testing, white box testing uses specific
knowledge of programming code to examine outputs. The test is accurate only if the
tester knows what the program is supposed to do. He or she can then see if the program
diverges from its intended goal. White box testing does not account for errors caused by
omission, and all visible code must also be readable.

HGCE Page 52
VIBRANT GUJARAT 080240107089

White box testing is concerned only with testing the software product, it cannot guarantee
that the complete specification has been implemented. Black box testing is concerned
only with testing the specification; it cannot guarantee that all parts of the implementation
have been tested. Thus black box testing is testing against the specification and will
discover faults of omission, indicating that part of the specification has not been fulfilled.
White box testing is testing against the implementation and will discover faults of
commission, indicating that part of the implementation is faulty. In order to fully test a
software product both black and white box testing are required.

White box testing is much more expensive than black box testing. It requires the source
code to be produced before the tests can be planned and is much more laborious in the
determination of suitable input data and the determination if the software is or is not
correct. The advice given is to start test planning with a black box test approach as soon
as the specification is available. White box planning should commence as soon as all
black box tests have been successfully passed, with the production of flow graphs and
determination of paths. The paths should then be checked against the black box test plan
and any additional required test runs determined and applied.

The consequences of test failure at this stage may be very expensive. A failure of a white
box test may result in a change which requires all black box testing to be repeated and the
re-determination of the white box paths. The cheaper option is to regard the process of
testing as one of quality assurance rather than quality control. The intention is that
sufficient quality will be put into all previous design and production stages so that it can
be expected that testing will confirm that there are very few faults present, quality
assurance, rather than testing being relied upon to discover any faults in the software,
quality control. A combination of black box and white box test considerations is still not
a completely adequate test rationale.

Black Box Testing


Also known as functional testing. A software testing technique whereby the internal
workings of the item being tested are not known by the tester. For example, in a black

HGCE Page 53
VIBRANT GUJARAT 080240107089

box test on a software design the tester only knows the inputs and what the expected
outcomes should be and not how the program arrives at those outputs. The tester does not
ever examine the programming code and does not need any further knowledge of the
program other than its specifications.

The advantages of this type of testing include:

• The test is unbiased because the designer and the tester are independent of each
other.

• The tester does not need knowledge of any specific programming languages.

• The test is done from the point of view of the user, not the designer.

• Test cases can be designed as soon as the specifications are complete.

The disadvantages of this type of testing include:

• The test can be redundant if the software designer has already run a test case.

• The test cases are difficult to design.

HGCE Page 54
VIBRANT GUJARAT 080240107089

Regression Testing:

After I make some change in the one module, we have to check


whether other modules are working perfectly or not.

Security Testing:

Testing how well the system protects against unauthorized internal or


external access, willful damage, etc; may require sophisticated
testing techniques.

Storage Testing:

The server saving the database is of higher capability.

Stress Testing:

I have checked for the system working with maximum number of users
and its performance time.

HGCE Page 55
VIBRANT GUJARAT 080240107089

PRACTICAL 5
LIMITATION AND FUTURE
ENHANCEMENT

7.1 LIMITATION:

HGCE Page 56
VIBRANT GUJARAT 080240107089

• For better performance minimum 64kbps bandwidth required.

• Power failure breaks the continuity.

• It provides limited information.

7.2 FUTURE ENHANCEMENT:

• User will able to surf many pages.

• Give answer through image.

• User can get latest information regarding growth and development of


Gujarat.

HGCE Page 57
VIBRANT GUJARAT 080240107089

PRACTICAL 6

CONCLUSION
AND DISCUSSION

Since it is said nothing is impossible so we also worked on the path following this

phrase and complete our project work successfully

HGCE Page 58
VIBRANT GUJARAT 080240107089

After doing this project, we have learned many things and we would like to thank the

entire concerned individuals who have contributed to my precious learning.

We have learned to prepare the requirement catalogue, functional specification,

System development life cycle in practical development and also learned real life

software development coding tools having interactive features.

Though the Project was taking too long and we faced many difficulties which had

been resolved effective guidance of my project guide and professors.

Richa Patel
Mansi Vachhani
Rupal Parmar
Khushbu Khatri

HGCE Page 59