1.Case Study

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 support. 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


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


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 blocking 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


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 conceptor 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


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


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


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


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


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


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


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


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 PatelMansi VachhaniKhushbu KhatriRupal Parmar

HGCE


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


CHAPTER- 1

INTRODUCTION

OF CURRENT PROJECT

HGCE


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


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:

1.4.2 What is CSS?

HGCE


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 ProblemHTML 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


CHAPTER-2

PROJECT MANAGEMENT

HGCE


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


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


The deliverables of the system is to get the all the services be useful for the end users anddeliver 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 PATELMANSI VACHHANIRUPAL PARMARKHUSHBU 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 overallproblem difficulty.

We are working as a team of two persons. By system analysis & design wepartitioned our project into manageable modules. Then according to the time &availability of a member of the team, the work was assigned among us. Hence, thishelped us in parallel development of project and give sufficient time & attention toevery 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


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 theirregular 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


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


CHAPTER 3

SYSTEM REQUIREMENTS STUDY

HGCE


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


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 DescriptionUser ID Enter User id for login.

HGCE


Password Enter Password for login.

Table: 3.1 Field Functionality

Button Name DescriptionLogin 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 systeminterdependent, a failure in one component can be propagated thorough the system andaffect 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

logoutautomatically so to sign in again. And the query are not applied directly instead

proceduredatabase is used to pass username and password

HGCE


CHAPTER-4

SYSTEM ANALYSIS

HGCE


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.

Response Time:

HGCE


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


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:

Operationally the software will be most feasible due to its strong

requirement for the school management.

HGCE


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.

The selected technologies have greater advantages over other challenger

technologies.

HGCE


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


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

every requirement and compare with our product and that it satisfies the user need. It is a

HGCE


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


PRACTICAL 3

Draw different diagrams for your current project

4.6 Function Of System:

4.6.1 USE CASE DIAGRAM

HGCE

LOGIN

GUJARAT AT A GLANCE

HISTORY

SURF INFORMATION

GLAOBAL SUMMIT

GUJARAT TOURISM

MAJOR PROJECT

S

ADD INFORMATION

ADD USER

REMOVE USER

VERIFIED USER

<<excludes>><<excludes>>

USER

ADMIN


4.7 DATA MODELLING::

4.7.1 ENTITY-RELATIONSHIP DIAGRAM

HGCE


4.7.2 SEQUENCE DIAGRAM

4.7.2.1 LOGIN

HGCE


4.7.2.2 ADMIN-SEQUENCE DIAGRAM

HGCE

ADMIN USER LOGIN VG

ADMIN MASTERUSER NAME

PASSWORD

SUCCESSFUL LOGIN

INVALID USER


4.7.2.3 INFORMATION-SEQUENCE DIAGRAM

HGCE


4.8 Functional & Behavioral Modeling

4.8.1.1 LOGIN

HGCE


4.9 FLOW CHART

Admin Flow Chart

HGCE

Gujarat At a Glance


CHAPTER-5

IMPLEMENTATION AND PLANNING

HGCE


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 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.

HGCE


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.

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

HGCE


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 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 standardcoding 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 DeclarationsWe have placed the local variable declarations at the beginning of the script.

HGCE


Block of declarations has aligned.

Naming Conventions

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

CONTROLSCONTROLS TAGRadio ButtonRadio Button rbLabelLabel lbGridViewGridView grdTextBoxTextBox txtHyperlinkHyperlink hyplnkDropDown List 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.

HGCE


PRACTICAL 4

Software testing using testing tools.

(White Box –Black Box Testing)

HGCE


CHAPTER 6

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.

HGCE


Equivalence Class Partitioning:

In this approach, the domain of input values to a program is partitioned into a set ofequivalence 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.

HGCE


Testing Process.

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.

HGCE


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.

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

HGCE


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

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.

HGCE


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.

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


PRACTICAL 5

LIMITATION AND FUTURE ENHANCEMENT

HGCE


7.1 LIMITATION:

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


PRACTICAL 6

CONCLUSIONAND DISCUSSION

HGCE


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

phrase and complete our project work successfully

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 PatelMansi VachhaniRupal ParmarKhushbu Khatri

HGCE

1.Case Study

Documents

Transcript of 1.Case Study