E-TENDERING SYSTEM

by Ashish Desai (ID No. 092002) Pranav Bambhroliya( ID No. 092003)

A project submitted in Partial fulfillment of the requirements For the degree of

BACHELOR OF TECHNOLOGY in Computer Engineering

Internal Guide: Prof. P.M. Jadav Associate Professor Dept. of Computer Engineering, DDU, Nadiad External Guide: Mr. Mishit Vora Sr. Software Engineer, DataSoft India Pvt. Ltd.

Department of Computer Engineering Faculty of Technology, Dharmsinh Desai University College Road, Nadiad-387001 April 2013
i

CANDIDATES DECLARATION
I declare that final semester report entitled E-Tendering System is my own work conducted under the supervision of the external guide Mr. Mishit Vora from DataSoft India Pvt. Ltd.

I further declare that to the best of my knowledge the report for B.Tech. Final semester does not contain part of the work which has been submitted for the award of B.Tech. Degree either in this or any other university without proper citation.

Ashish Desai Branch: Computer Engineering Student ID: 092002

Pranav Bambhroliya Branch: Computer Engineering Student ID: 092003

ii

CERTIFICATE

This is to certify that the project work titled E-TENDERING SYSTEM

Is the Bonfire work of ASHISH DESAI (ID. - 092002) PRANAV BAMBHROLIYA (ID. 092003)
carried out in the partial fulfillment of the degree of Bachelor of Engineering in Computer Engineering at Dharmsinh Desai University in the academic session December 2005 to April 2006.

Mr. Prashant M. Jadav Associate Prof. Dept. of Computer Engg., Date:

Prof. C.K. Bhensdadia Head, Dept. of Computer Engg., Date:

Faculty Of Technology Department Of Computer Engineering Dharmsinh Desai University

iii

E-TENDERING SYSTEM Project by Ashish Desai (ID: 092002) Pranav Bambhroliya (ID: 092003) ABSTRACT
In the past, there wasnt any process for issuing a new tender online. All process were offline on paper. If any new tender was issued then the organization would give an advertisement on its website, newspaper or any other media. Newspapers contain only few detail of tender, if any more details are required then the contractors have to physically visit the organization. All process from issue of a new tender to allocate a tender to the contractor would have to be done on paper and personally. So the tenders and corrigendums, contractors portfolio and bid details are managed manually. No online registration and subscription were provided. This e-tendering system (electronic tendering system) facilitates the complete tendering process from the advertising of the requirement through to the placing of the contract on online. All the tender details, corrigendum details can be shown online. In e-tendering system client can bid for the tenders online and portfolio can be submitted at the time of bidding. Client can search tender department wise, date wise, amount wise etc.

iv

ACKNOWLEDGEMENT

It gives us immense pleasure and satisfaction in presenting this report of System development Project undertaken during the 8th semester of B.Tech. As it is the first step into our Professional Life, we would like to take this opportunity to express our sincere thanks to several people, without whose help and encouragement, it would be unfeasible for us to carry out the desired work. We would like to thank to Mr. Mishit D. Vora(Project Leader) for giving us an opportunity to work with one of the most esteemed organization of the world. An enviable work culture and an environment that encourages creativity and innovation have inculcated in us a sense of discipline and perseverance. From the bottom of our heart, I would like to express my sincere thanks to our Head of Department Prof. C.K. Bhensdadia and our internal guide Prof. Prashant Jadav, who gave us an opportunity to undertake such a great challenging and innovative work. We are grateful to them for their guidance, encouragement, understanding and insightful support in the development process. Finally, we would like to thank to all DataSoft employees, all faculty members of our college, our friends and our family members for providing their support and continuous encouragement throughout the project.

With sincere regards, Ashish Desai, Pranav Bambhroliya

Table of Contents
Candidate Declaration i Certificate ii Abstract.iii Acknowledgementiv List of Tables vii List of Figures viii Abbreviations ix 1 Introduction 1 1.1 Project Details 2 1.2 Purpose 2 1.3 Scope 5 1.4 Objective 5 1.5 Technology and Literature Review 6 2 Project Management 20 2.1 Feasibility Study 21 2.1.1 Technical feasibility 21 2.1.2 Time schedule feasibility 21 2.1.3 Operational feasibility 22 2.1.4 Implementation feasibility 22 2.2 Project Planning 22 2.2.1 Project Development Approach and Justification 22 2.2.2 Project Plan 24 2.2.3 Milestones and deliverables 25 2.2.4 Roles and Responsibilities 25 2.2.5 Group Dependencies 26 2.3 Project Scheduling 26 2.3.1 Project Scheduling Chart 26 3 System Requirements Study 27 3.1 Study of Current System 28 3.2 Problem & weakness of Current System 28 3.3 User Characteristics 28 3.4 Hardware and Software Requirements 29 3.5 Constraints 30 3.5.1 Regulatory Policies 30 3.5.2 Hardware Limitations 30 3.5.3 Interfaces to other Applications 30 3.5.4 Parallel Operations 30 3.5.5 Higher Order Language Requirements 31 3.5.6 Criticality of the Application 31 3.5.7 Security 31 3.6 Assumptions 32 4 System Analysis 33 vi

4.1 Requirements of New System 34 4.1.1 Use Case Diagram 34 4.1.2 System Requirements 34 4.2 System Requirements Specification 36 4.3 Features of new system. .38 4.4 Navigation Chart 38 4.5 System Activity 39 4.6 Data Modeling 40 4.7 Data Flow Diagrams41 5 System Design 46 5.1 System Architecture Design 47 5.1.1 Component Diagram 47 5.1.2 Deployment Diagram 48 5.2 Database Design 49 5.2.1 Table & Relationship 50 5.2.2 Data Dictionary 51 5.3 Implemented Algorithm 54 6 Implementation Planning 56 6.1 Implementation Environment 57 6.2 Coding Standards 59 6.3 Implemented Classes 60 6.4 Screenshots 61 7 Testing 61 7.1 Testing Plan 62 7.2 Testing Strategy 64 7.3 Testing Methods 65 7.4 Test Cases 68 7.5 Testing Screenshots77 8 Conclusion and Future Extensions 80 8.1 Conclusion 81 8.2 Future Extension 82 References 83

vii

Conclusion And Future Extension LIST OF TABLES Table Table 1.1 Table 2.1 Table 3.1 Table 5.1 Table5.2 Table 5.3 Table 5.4 Table 5.5 Table 5.6 Table 5.7 Table 5.8 Table 5.9 Table 5.10 Table 7.1 Table 7.2 Table 7.3 Name Technologies Used Technical Feasibility Hardware Required Client Registration DB Inquiry DB Category DB Sub-Category DB Tender DB Corrigendum DB F.A.Q. DB Portfolio DB Security DB Result DB Test Cases for Login Test Cases for Registration Test Cases for Tender management Page No. 4 19 27 49 50 50 50 51 51 52 52 52 53 75 75 76

VIII

LIST OF FIGURES Figures Figure 1.1 Figure 1.2 Figure 1.3 Figure 1.4 Figure 2.1 Figure 2.5 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 4.7 Figure 4.8 Figure 5.1 Figure 5.2 Figure 6.1 Figure 7.1 Name Struts Flow Diagram Struts with J2EE Freemarker Overview Hibernate Architecture Iterative model Gantt Chart Use Case Diagram Navigation Chart for channel Activity Diagram For Login ER Diagram Client DFD Level 0 Client DFD Level 1 Client DFD Level 2 Admin DFD Level 1 Component Diagram Deployment Diagram Implementation Environment Testing steps Page No. 10 12 15 17 23 26 34 38 39 40 42 43 44 45 47 48 57 68

Abbreviations

GUI SQL J2EE XML MVC UML POJO

Graphical User Interface Structured Query Language Java 2 Enterprise Edition Extensible Markup Language Model View Controller Unified Modeling Language Plain Old Java Object

CHAPTER 1 INTRODUCTION

1.1 Project Details:

Project Definition:E-Tendering System. An e-Tendering System (or Electronic Tendering System) facilitates the complete tendering process the entire tender and the corrigendum details can be viewed. Also the tender notices, tender documents, corrigendum notices can be downloaded from the website. It involves online bidding with Client Details. .

1.2 PURPOSE:
Existing System
No Automated Bidding Process: The bidding process is completely manual and so very time consuming. There is no provision for online bidding. The tenders have to download the documents from the website while the rest of the process is manual. Security: The manual process is not very secure. In the new system, the passwords are generated automatically so only the members know their passwords. Tender Status: Finding out the tender status (Allocated/Non-Allocated) is time consuming. No Searching Facility: There are no searching facilities for tenders such as such as search by tendering department, category, amount, date, type, etc. in the existing system. Limited Tender Details Available Online: Only the name of work, issue date and bid closing date is available online. Other details like estimated cost, tendering department, category etc. are not displayed.

 Not As Accurate And Fast: Retrieving information is slower as everything is managed manually. Since, everything is managed manually; there might be a lack of accuracy.

The workflow of the existing system is as explained below:

1) All Details Managed Manually: The tenders and corrigendum, their notices and documents, contractors records and bid details are managed manually. No online registration and subscription provided. 2) Bidding Process: The bidding process which involves both the technical bid and the financial bid is not automated. Bidders send the necessary documents like their solvency certificate, technical resources data and their quotations through post. In the bidding process, technical bid is the first stage wherein the Tenderers have to give the proof of his solvency and the data about his financial position. Then he is required to give the details of the technical resources available with him.. Both the technical bid and the price bid are kept in two separate covers which are again kept in one main cover. Only those bidders price bid is opened whose financial records and technical bid are satisfactory. Earned Money Deposit of those bidders who are not qualified at the technical bid stage will be refunded. After proper evaluation, the final bid is selected and the tendered whose bid is selected will have to pay some amount as a security deposit. This amount will be adjusted later on. 3) Tender download The name of work of tender, its issue date and bid closing date is displayed on The Ahmedabad Municipal Corporations website (www.egov.amc.com).

Need for a new system

To automate the bidding process and provide the tender details online: The manual bidding process is very time consuming and slow. The records of data is also maintained manually which slows down the retrieval of information. The tenders should be able to make a bid online. All the important details of the tenders should be made available online. Tender and corrigendum notices should be displayed as well. To check the status of Tenders: Such a facility will enable the contractors to know the status (Allocated/NonAllocated) of the tenders easily and quickly. Security: The existing system is not so secure. In the new system, Faster retrieval of information: Retrieval of information becomes easier compared to the manual system. Details regarding tenders, corrigendum, bidders, feedback etc are available easily.

1.3 SCOPE:
Table updates according to user input Deleting and Modification of existing records update the table accordingly. Graphical User Interface Facility. Java environment provides the user with graphical / visual interface. Improvised reports. Reports have been improvised with the facility for individual and group items separately. Multiple Operations available in a single form. Facility to add, modify, delete, update etc. are provided in the same form so that the user does not have to switch over from one form to another form to the same. Tangible Benefits: Reduction of paper work as a result cost of stationery reduces. Category wise Tender reports. Automatic Bidding and Result. Automatic Result Mailing System. Intangible Benefits: Accurate and timely reports are available as a result efficiency of the employee increases. Since the application is accessible from anywhere the time in accessing the information is highly reduced. Security would be available from unauthorized users and each users access to the different parts of the application.

1.4 OBJECTIVE:

Implementing online creation, editing of bids by administrator. Implementing viewing, applying for bids by client. Implementing email based registration/password recovery.

1.5 TECHNOLOGY AND LITERATURE REVIEW:

TECHNOLOGY USED:

Sr. No 1 2 3

Type Operating System Technology used in front tier Application Development Environment

Description Windows 7 Struts JSP,JSTL

Tools for Development

5 Technology used in back end

Eclipse My-SQL

TABLE 1.1 Technologies Used

1.5.1 Technology related to front tier:

-Struts has been used as a front tier technology.

1.5.1.1 Struts Framework:

Struts is an open source framework used for developing J2EE web applications using Model View Controller (MVC) design pattern. It uses and extends the Java Servlet API to encourage developers to adopt an MVC architecture.

1.5.1.2 Description:

Struts is a framework for J2EE which promotes the MVC architecture Struts framework provides three key components:

A request handler provided by the application developer that is used to map to a particular URI.

A response handler which is used to transfer the control to another resource which will be responsible for completing the response.

A tag library which helps developers to create the interactive form based applications with server pages.

Struts provide you the basic infrastructure for implementing MVC allowing the developers to concentrate on the business logic. MVC Architecture

The main aim of the MVC architecture is to separate the business logic and application data from the presentation data to the user.

Here are the reasons why we should use the MVC design pattern. They are reusable: When the problems recur, there is no need to invent a new solution; we just have to follow the pattern and adapt it as necessary. They are expressive: By using the MVC design pattern our application becomes more expressive.

10

1.5.1.3 Framework:

Model: The model object knows about all the data that need to be displayed. It is model who is aware about all the operations that can be applied to transform that object. It only represents the data of an application. The model represents enterprise data and the business rules that govern access to and updates of this data. Model is not aware about the presentation data and how that data will be displayed to the browser.

View: The view represents the presentation of the application. The view object refers to the model. It uses the query methods of the model to obtain the contents and renders it. The view is not dependent on the application logic. It remains same if there is any modification in the business logic. In other words, we can say that it is the responsibility of the view's to maintain the consistency in its presentation when the model changes.

Controller: Whenever the user sends a request for something then it always go through the controller. The controller is responsible for intercepting the requests from view and passes it to the model for the appropriate action. After the action has been taken on the data, the controller is responsible for directing the appropriate view to the user. In GUIs, the views and the controllers often work very closely together.

Overview of the Struts Framework

The Struts framework is composed of approximately 300 classes and interfaces which are organized in about 12 top level packages. Along with the utility and helper classes framework also provides the classes and interfaces for working with controller and presentation by the help of the custom tag libraries. It is entirely on to us which model we want to choose. The view of the Struts architecture is given below:

11

The Struts Controller Components: Whenever a user request for something, then the request is handled by

the Struts Action Servlet. When the Action Servlet receives the request, it intercepts the URL and based on the Struts Configuration files, it gives the handling of the request to the Action class. Action class is a part of the controller and is responsible for communicating with the model layer. The Struts View Components: The view components are responsible for presenting information to the users and accepting the input from them. They are responsible for displaying the information provided by the model components. Mostly we use the Java Server Pages (JSP) for the view presentation. To extend the capability of the view we can use the Custom tags, java script etc. The Struts model component: The model components provide a model of the business logic behind a Struts program. It provides interfaces to databases or back- ends systems. Model components are generally a java class. There is not any such defined format for a Model component, so it is possible for us to reuse Java code which is written for other projects. We should choose the model according to our client requirement.

12

Fig 1.1 Struts Flow Diagram

web.xml: Whenever the container gets start up the first work it does is to check the web.xml file and determine what struts action Servlets exist. The container is responsible for mapping all file requests to the correct action Servlet.

A Request: This is the second step performed by the container after checking the web.xml file. In this the user submits a form within a browser and the request is intercepted by the controller.

The Controller: This is the heart of the container. Most Struts application will have only one controller that is Action Servlet which is responsible for directing several Actions. The controller determines what action is required and sends the information to be processed by an action Bean. The key advantage of having a controller is its ability to control the flow of logic through the highly controlled, centralized points.

struts.config.xml: Struts has a configuration file to store mappings of actions. By using this file there is no need to hard code the module which will be called within a component. The one more responsibility of the controller is to check the struts.config.xml file to determine

13

which module to be called upon an action request. Struts only reads the struts.config.xml file upon start up.

Model: The model is basically a business logic part which takes the response from the user and stores the result for the duration of the process. This is a great place to perform the preprocessing of the data received from request. It is possible to reuse the same model for many page requests. Struts provide the Action Form and the Action classes which can be extended to create the model objects.

View: The view in struts framework is mainly a jsp page which is responsible for producing the output to the user.

Struts tag libraries: These are struts components helps us to integrate the struts framework within the project's logic. These struts tag libraries are used within the JSP page. This means that the controller and the model part can't make use of the tag library but instead use the struts class library for strut process control.

Property file: It is used to store the messages that an object or page can use. Properties files can be used to store the titles and other string data. We can create many property files to handle different languages.

Business objects: It is the place where the rules of the actual project exist. These are the modules which just regulate the day- to- day site activities.

The Response: This is the output of the View JSP object.

14

Struts embedded onto J2EE:

Fig 1.2 Struts with J2EE

1.5.2 Eclipse IDE:

Eclipse is a Java IDE:

Widely regarded as the Java development environment With all the bells and whistles Language-aware editors, views, Refracting support Integrated unit testing and debugging Incremental compilation and build Team development support

Eclipse is an IDE Framework: Eclipse + JDT = Java IDE First class framework for Java Language aware editor Incremental build Integrated debugging

Eclipse + CDT = C/C++ IDE

15

First class framework for C/C++ Language aware editor Refactoring, search

Eclipse is a Tools Framework: Extensibility through Struts implementation Plug-ins make Eclipse whatever you need it to be

Focus on developing a universal platform of frameworks and exemplary tools Tools extend the Eclipse platform using plug-ins Business Intelligence and Reporting Tools (BIRT) Eclipse Communications Framework (ECF) Web Tools Project (WTP) Eclipse Modelling Framework (EMF) Graphical Editing Framework (GEF) Test and Performance Tooling Project (TPTP)

Eclipse is a Application Framework:

Remove the IDE elements, Java language support, team development support, and youre left with a pretty comprehensive general application framework

Support for multiple platforms

Linux, Windows, Mac OSX, UNIX, embedded

Rich widget set, graphics Native-OS integration (drag and drop, OLE/XPCOM integration)

1.5.3 Front-End Technologies:

1.5.3.1 JSP: Java Server Pages or JSP for short is Sun's solution for developing dynamic web sites.

16

JSP provide excellent server side scripting support for creating database driven web applications. JSP enable the developers to directly insert java code into jsp file, this makes the development process very simple and its maintenance also becomes very easy. JSP pages are efficient, it loads into the web servers memory on receiving the request very first time and the subsequent calls are served within a very short period of time. Java is known for its characteristic of "write once, run anywhere." JSP pages are platform independent. Your port your .jsp pages to any platform. 1.5.3.2 Freemarker: FreeMarker is a template engine: a generic tool to generate text output (anything from HTML to autogenerated source code) based on templates. It's a Java package, a class library for Java programmers. It's not an application for end-users in itself, but something that programmers can embed into their products. FreeMarker is designed to be practical for the generation of HTML Web pages, particularly by servlet-based applications following the MVC (Model View Controller) pattern. The idea behind using the MVC pattern for dynamic Web pages is that you separate the designers (HTML authors) from the programmers. Everybody works on what they are good at. Designers can change the appearance of a page without programmers having to change or recompile code, because the application logic (Java programs) and page design (FreeMarker templates) are separated. Templates do not become polluted with complex program fragments. This separation is useful even for projects where the programmer and the HTML page author is the same person, since it helps to keep the application clear and easily maintainable.

17

Although FreeMarker has some programming capabilities, it is not a full-blown programming language like PHP. Instead, Java programs prepare the data to be displayed (like issue SQL queries), and FreeMarker just generates textual pages that display the prepared data using templates.

Fig1.3 Freemarker overview

FreeMarker is not a Web application framework. It is suitable as a component in a Web application framework, but the FreeMarker engine itself knows nothing about HTTP or servlets. It simply generates text. As such, it is perfectly usable in non-web application environments as well. Note, however, that we provide out-of-the-box solutions for using FreeMarker as the view component of Model 2 frameworks such as Struts. FreeMarker is Free, released under a BSD-style license. It is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative.

18

1.5.4 Data Access Technology: 1.5.4.1 Hibernate: Hibernate is a high-performance Object/Relational persistence and query service which is licensed under the open source GNU Lesser General Public License (LGPL) and is free to download. Hibernate not only takes care of the mapping from Java classes to database tables (and from Java data types to SQL data types), but also provides data query and retrieval facilities. Hibernate is an Object-Relational Mapping(ORM) solution for JAVA and it raised as an open source persistent framework created by Gavin King in 2001. It is a powerful, high performance ObjectRelational Persistence and Query service for any Java Application. Hibernate maps Java classes to database tables and from Java data types to SQL data types and relieve the developer from 95% of common data persistence related programming tasks. Hibernate sits between traditional Java objects and database server to handle all the work in persisting those objects based on the appropriate O/R mechanisms and patterns.

19

Fig 1.4 Hibernate Architecture

Hibernate uses various existing Java APIs, like JDBC, Java Transaction API(JTA), and Java Naming and Directory Interface (JNDI). JDBC provides a rudimentary level of abstraction of functionality common to relational databases, allowing almost any database with a JDBC driver to be supported by Hibernate. JNDI and JTA allow Hibernate to be integrated with J2EE application servers.

1.5.5 Back-End Technology: 1.5.5.1 MySQL:

MYSQL,

THE

MOST

POPULAR

OPEN SOURCE SQL

DATABASE

MANAGEMENT SYSTEM, IS DEVELOPED, DISTRIBUTED, AND SUPPORTED BY

MYSQL AB. MYSQL AB MYSQL

IS A COMMERCIAL COMPANY, FOUNDED

BY THE

DEVELOPERS. THAT

IT

IS A SECOND GENERATION

OPEN
AND

SOURCE

COMPANY

UNITES

OPEN SOURCE

VALUES

METHODOLOGY WITH A SUCCESSFUL BUSINESS MODEL.

20

THE MYSQL WEB

SITE (HTTP://WWW.MYSQL.COM/) PROVIDES THE

LATEST INFORMATION ABOUT MYSQL SOFTWARE AND MYSQL AB.

MYSQL IS A DATABASE MANAGEMENT SYSTEM. A

DATABASE IS A STRUCTURED COLLECTION OF DATA.

IT

MAY BE

ANYTHING FROM A SIMPLE SHOPPING LIST TO A PICTURE GALLERY OR THE VAST AMOUNTS OF INFORMATION IN A CORPORATE NETWORK.

TO

ADD, ACCESS, AND PROCESS DATA STORED IN A COMPUTER DATABASE, YOU NEED A DATABASE MANAGEMENT SYSTEM SUCH AS

MYSQL

SERVER. SINCE

COMPUTERS ARE VERY GOOD AT HANDLING LARGE

AMOUNTS OF DATA, DATABASE MANAGEMENT SYSTEMS PLAY A CENTRAL ROLE IN COMPUTING, AS STANDALONE UTILITIES, OR AS PARTS OF OTHER APPLICATIONS.

MYSQL IS A RELATIONAL DATABASE MANAGEMENT SYSTEM. A RELATIONAL DATABASE STORES DATA IN SEPARATE TABLES RATHER
THAN PUTTING ALL THE DATA IN ONE BIG STOREROOM. SPEED AND FLEXIBILITY.

THIS

ADDS

THE SQL

PART OF

MYSQL

STANDS FOR

STRUCTURED QUERY LANGUAGE. SQL

IS THE MOST COMMON

STANDARDIZED LANGUAGE USED TO ACCESS DATABASES AND IS DEFINED BY THE

ANSI/ISO SQL STANDARD. THE SQL STANDARD HAS 1986

AND SEVERAL VERSIONS EXIST. IN THIS

BEEN EVOLVING SINCE MANUAL,

SQL-92

REFERS TO THE STANDARD RELEASED IN

1992,
AND

SQL:1999 SQL:2003 WE

REFERS TO THE STANDARD RELEASED IN

1999,

REFERS TO THE CURRENT VERSION OF THE STANDARD.

USE THE PHRASE

THE SQL

STANDARD TO MEAN THE CURRENT

VERSION OF THE SQL STANDARD AT ANY TIME.

MYSQL SOFTWARE IS OPEN SOURCE. OPEN SOURCE

MEANS THAT IT IS POSSIBLE FOR ANYONE TO USE AND

MODIFY THE SOFTWARE. SOFTWARE FROM THE ANYTHING.

ANYBODY

CAN DOWNLOAD THE

MYSQL

INTERNET

AND USE IT WITHOUT PAYING

IF

YOU WISH, YOU MAY STUDY THE SOURCE CODE AND

CHANGE IT TO SUIT YOUR NEEDS.

THE MYSQL

SOFTWARE USES THE

GPL

(GNU

GENERAL

PUBLIC

LICENSE), 21

HTTP://WWW.FSF.ORG/LICENSES/, TO DEFINE WHAT YOU MAY AND MAY NOT DO WITH THE SOFTWARE IN DIFFERENT SITUATIONS. IF YOU FEEL UNCOMFORTABLE WITH THE

GPL

OR NEED TO EMBED

MYSQL

CODE

INTO A COMMERCIAL APPLICATION, YOU CAN BUY A COMMERCIALLY LICENSED VERSION FROM US. FOR

SEE THE MYSQL LICENSING OVERVIEW

INFORMATION

MORE

(HTTP://WWW.MYSQL.COM/COMPANY/LEGAL/LICENSING/). THE MYSQL DATABASE SERVER

TO USE. IS VERY FAST, RELIABLE, AND EASY

IF THAT IS WHAT YOU ARE LOOKING FOR, YOU SHOULD GIVE IT A TRY. MYSQL SERVER
ALSO HAS A PRACTICAL SET OF FEATURES

DEVELOPED IN CLOSE COOPERATION WITH OUR USERS. A PERFORMANCE COMPARISON OF

YOU CAN FIND

WITH OTHER

MYSQL SERVER

DATABASE MANAGERS ON OUR BENCHMARK PAGE.

MYSQL SERVER

WAS ORIGINALLY DEVELOPED TO HANDLE LARGE

DATABASES MUCH FASTER THAN EXISTING SOLUTIONS AND HAS BEEN SUCCESSFULLY USED IN HIGHLY DEMANDING PRODUCTION

ENVIRONMENTS FOR SEVERAL YEARS. DEVELOPMENT,

ALTHOUGH

UNDER CONSTANT

MYSQL SERVER

TODAY OFFERS A RICH AND USEFUL

SET OF FUNCTIONS. ITS CONNECTIVITY, SPEED, AND SECURITY MAKE

MYSQL SERVER HIGHLY SUITED INTERNET.

FOR ACCESSING DATABASES ON THE

MYSQL SERVER WORKS IN CLIENT/SERVER OR EMBEDDED SYSTEMS. THE MYSQL DATABASE SOFTWARE IS A CLIENT/SERVER SYSTEM THAT
CONSISTS OF A MULTI-THREADED

SQL

SERVER THAT SUPPORTS

DIFFERENT BACK ENDS, SEVERAL DIFFERENT CLIENT PROGRAMS AND LIBRARIES, ADMINISTRATIVE TOOLS, AND A WIDE RANGE OF

APPLICATION PROGRAMMING INTERFACES (APIS).

WE

ALSO PROVIDE

MYSQL SERVER

AS AN EMBEDDED MULTI-

THREADED LIBRARY THAT YOU CAN LINK INTO YOUR APPLICATION TO GET A SMALLER, FASTER, EASIER-TO-MANAGE STANDALONE PRODUCT.

22

LARGE

AMOUNT

OF

CONTRIBUTED

MYSQL

SOFTWARE

IS

AVAILABLE.

IT IS VERY LIKELY THAT YOUR FAVORITE APPLICATION OR LANGUAGE

SUPPORTS THE MYSQL DATABASE SERVER.

THE OFFICIAL WAY TO PRONOUNCE MYSQL IS MY ESSQUE ELL (NOT MY

SEQUEL), BUT WE DO NOT MIND IF YOU PRONOUNCE IT AS

MY SEQUEL OR IN SOME OTHER LOCALIZED WAY.

23

CHAPTER 2 PROJECT MANAGEMENT

24

2.1: Feasibility Study:

2.1.1 Technical Feasibility:

Amidst, technical analysis evaluates technical merits of the system at the same time collection additional information about performance, reliability, maintainability and productivity. In some cases, an analysis step also includes research and design.

Technical Requirement Back end Front end Local Host Server Documentation Tools Communication Tools

How Accomplished? MySQL Server 5.5.8, J2EE,Struts JSP ----Apache Tomcat 6.0 Microsoft Office Tools IP Call Lines, Remote Desktop sharing etc Table 2.1 Technical Feasibility

2.1.2 Time Feasibility Time schedule plays a vital role in clients project. If the project is not delivered at due time then it can cause a project failure. Hence before undertaking particular project high concentration should be focused on the time management by project manager. It should also be taken care that the staff, which is related with the project, should be able to complete the technical tasks in given schedule. If the current staff is not sufficient in completing the project tasks, project manager should allot more technical persons.

25

2.1.3 Operational Feasibility The users of the client organization should be able to operate the application easily, for whom the application is developed, to gain the advantages of the application. This demands good user interface. During the application development process prototypes of the application are developed initially and are shown to client, so the client can give some additional changes as per their requirements. As the application is developed and modified as per the comments of the users, there is very little possibility that there will be resistance from end users. 2.1.4 Implementation Feasibility Implementation feasibility is concerned with specifying external resources and softwares that will successfully satisfy the user requirements. We have given more importance to external resources and configuration of the system rather than the actual map of the hardware. Financial consideration was also considered at this stage.

2.2: PROJECT PLANNING:

2.2.1: Project Development Approach and Justification: Most software teams still use a waterfall process for development projects. Taking an extreme waterfall approach means that you complete a number of phases in a strictly ordered sequence: requirements analysis, design,

implementation/integration, and then testing. You also defer testing until the end of the project life cycle, when problems tend to be tough and expensive to resolve; these problems can also pose serious threats to release deadlines and leave key team members idle for extended periods of time. In practice, most teams use a iterative waterfall approach, breaking the project down into two or more parts, sometimes called phases or stages. In addition, this approach allows you to prototype areas you deem risky or difficult and to use feedback from each stage to modify your design. This article will explore the improvements that an "iterative" approach to the software development process offers over the traditional waterfall approach.

26

ITERATIVE WATERFALL MODEL:-

FIG 2.1: ITERATIVE MODEL.

THE FOUR BASIC PROCESS AREAS OF THE ITERATIVE MODEL ARE:

THE REQUIREMENTS PHASE, IN WHICH THE REQUIREMENTS FOR THE

ARE GATHERED AND ANALYZED.

SOFTWARE

ITERATION

SHOULD

EVENTUALLY RESULT IN A REQUIREMENTS PHASE THAT PRODUCES A COMPLETE AND FINAL SPECIFICATION OF REQUIREMENTS.

DESIGN PHASE, IN WHICH SOFTWARE

ARCHITECTURE AND

COMPONENTS TO MEET THE REQUIREMENTS ARE DESIGNED; THIS MAY BE A NEW DESIGN, OR AN EXTENSION OF AN EARLIER DESIGN.

AN IMPLEMENTATION

PHASE, WHEN THE SOFTWARE IS CODED,

INTEGRATED AND TESTED.

REVIEW PHASE, IN WHICH THE SOFTWARE IS EVALUATED, THE

CURRENT REQUIREMENTS ARE REVIEWED, AND CHANGES AND ADDITIONS TO REQUIREMENTS PROPOSED.

27

Advantages of the Iterative Model: A

COMPARISON OF THE TRADITIONAL LIFE CYCLE TO THE ITERATIVE ONE

REVEALS THAT THE ITERATIVE MODEL IS MORE FLEXIBLE, AS IT PRESENTS MORE OPPORTUNITIES TO INTRODUCE CHANGE. IN THE ITERATIVE MODEL, CHANGE IS AN ACKNOWLEDGED, INTEGRAL COMPONENT.

REWORK

IS ACCEPTED, BUT SHOULD

DIMINISH RAPIDLY; THE CHANGES SHOULD BE LESS WIDESPREAD AS THE ARCHITECTURE STABILIZES AND IDEALLY, THE HARD ISSUES ARE BEING RESOLVED EARLY.

THE EMBRACE OF SOURCE CODE REVISION HAS A PROFOUND AND POSITIVE WHEN
ERRORS ARE FOUND, THEY CAN BE

IMPACT ON SOFTWARE QUALITY.

CORRECTED AT BEST REAL-TIME, AT WORST IN THE NEXT ITERATION.

CONTRAST

THIS TO THE WATERFALL MODEL, WHERE SOFTWARE IS OFTEN RELEASED WITH MAJOR DEFECTS--BECAUSE IT IS TOO LATE IN THE LIFECYCLE TO REWRITE, OR REDESIGN COMPONENTS.

2.2.2: PROJECT PLAN:

IN
MANAGING ANY PROJECT THE WHOLE PLAN OF THE PROJECT IS MADE

BEFORE ITS ACTUAL IMPLEMENTATION. THE PLAN OF THE PROJECT HELPS TEAM TO WORK AS PER THE SCHEDULE AND HELPS TO SUCCESSFULLY COMPLETE THE PROJECT.

TO PLAN A PROJECT THE MAIN REQUIREMENTS THAT ARE CALCULATED ARE

COST, DURATION, EFFORT, SCHEDULING, MANPOWER, RESOURCE ALLOCATION, RISK MANAGEMENT ETC.

THE COCOMO

EFFORT AND DURATION INVOLVED WERE CALCULATED IN THE MODEL WHICH UTILIZED SEMIDETACHED TYPE OF MODEL FOR ITS

CALCULATION.

PROPER

MANAGEMENT OF THE WHOLE PROJECT WAS DONE IN

ORDER TO COMPENSATE WITH THE DURATION WHICH WAS LESS THAN ESTIMATED.

THE COST INVOLVED WAS ONLY ON THE RESOURCES AND THE OTHER CHARGES LIKE
PAYING THE DEVELOPERS WAS NOT INVOLVED AS TRAINEES MADE IT.

THUS,

THE WHOLE PROJECT WAS FEASIBLE.

THE

RISK MANAGEMENT WAS

ALSO HANDLED AS IT GOT OVER IN REQUIRED DURATION.

28

2.2.3: MILESTONES AND DELIVERABLES:

EVERY
PHASE HAS ENTRY AND EXIT CRITERIA. IT IS ON THE BASIS OF THIS

CRITERIA THE DEVELOPERS MOVE AHEAD INTO NEXT PHASE.

HENCE,

SUCH

MILESTONES AND DELIVERABLES ARE ESSENTIAL PART TO KEEP THE WHOLE PROJECT TEAM IN PROPER TRACK FOR COMPLETING THE PROJECT IN TIME. IT IS THIS MILESTONE WHICH HELPS THE TEAM MEMBERS TO ACTUALLY REALIZE THAT A PARTICULAR PHASE OF THE PROJECT HAS BEEN COMPLETED.

SOMETIMES

DEVELOPERS JUMP TO OTHER PHASE WITHOUT THE KNOWLEDGE THAT INITIAL PHASE ARE INCOMPLETE WHICH RESULTS IN THE PROBLEM IN THE FINAL PHASES OF THE PROJECT.

Activities Feasibility study Requirement analysis Design study Requirement specification Implementation Testing

Milestone Feasibility report user requirement architectural design system requirement coding details testing report

THE

APPLICATION ALSO INVOLVES NUMBER OF MILESTONES THAT COULD

ENABLE THE PROJECT TEAM TO FIND THE CRITERIA TO ENTER NEXT PHASE:

2.2.4: Roles and Responsibilities:

To keep a project smooth-going a proper team structure has to be maintained. As few members were involved in the whole team each of them had to perform the task as system analyst, project management, coder, tester, developer, designer etc. as the project proceeded through its different phases. This helped each one to develop all kinds of skills in all the phases.

29

2.2.5: Group Dependencies:

The team structure depends on the management style of the organization, the number of people in the team, their skill levels and the problem difficulty. Democratic problems was

Considering all these points our Team organization was Decentralized. In which there is no team leader. Decision on the

made by group consensus. Communication among the team members was horizontal.

2.3: PROJECT SCHEDULING:

Scheduling the project tasks is an important project planning activity. It involves deciding which tasks should be taken up and when. In order to schedule the project activities, a software project manager needs to do the following: Identify all the tasks needed to complete the project. Break down large tasks into small activities. Determine dependencies amongst different activities. Establish most likely estimates for the time durations necessary to complete the activities. Allocate resources to activities. Plan the starting and ending dates for various activities.

Dec 2012

Jan 2013 1/6 1/13 1/20 1/27 2/3

Feb 2013 2/10 2/17 2/24 3/3

Mar 2013 3/10 3/17 3/24

ID

Task Name

Start

Finish

Duration
12/9 12/16 12/23 12/30

1 2 3 4 5

Analysis Database Design UML and UI design Coding Testing

12/10/2012 12/31/2012 1/15/2013 1/31/2013 3/11/2013

12/28/2012 1/14/2013 1/29/2013 3/8/2013 3/28/2013

15d 11d 11d 27d 14d

Fig 2.2. Gantt Chart

30

CHAPTER 3 SYSTEM REQUIREMENTS STUDY

31

3.1: STUDY OF CURRENT SYSTEM

In Past, there is no any process online for issue a new tender. But all process work offline on paperwork. If any new tender is issue than organization gives an advertisement in a website, newspaper or any other resources. Newspaper contains only few detail of tender, if any more detail required than contractor physically visited the organization .All process from issue a new tender to allocate a tender to the contractor is on paper work. So the tenders and corrigendums, contractors Portfolio and bid details are managed manually. No online registration and subscription provided.

3.2: PROBLEM AND WEAKNESS OF CURRENT SYSTEM

The bidding process is completely manual and so very time consuming. There is no provision for online bidding. The tenders have to download the documents from the website while the rest of the process is manual. The manual process is not very secure. In the new system, the passwords are generated automatically so only the members know their passwords. Retrieving information is slower as everything is managed manually. Since, everything is managed manually; there might be a lack of accuracy.

3.3: USER CHARACTERISTICS

In our application there are 3 types of users which are as below. Visitor. Client. Admin.

32

3.4: HARDWARE AND SOFTWARE REQUIREMENTS

HARDWARE REQUIRED: Application Server and Database Server

Pentium IV PC with 2.4 Ghz CPU 1024 MB of RAM 80 GB Hard Disk CD read/write 17'' Flat screen color graphics Monitor Key Board Mouse LAN connectivity by 10/100 MBPS Ethernet card/Internet Connectivity

For Client Machine

Pentium II/III/IV PC Min. 64 MB of RAM (Recommended :256 MB) Key Board Mouse LAN connectivity by 10/100 MBPS Ethernet card/Internet Connectivity TABLE 3.1: HARDWARE REQUIRED.

SOFTWARE REQUIRED:

Java Runtime Environment (1.5 and above).

33

3.5: CONSTRAINTS

3.5.1: Regulatory Policies

As per the Company's policy any developer has to maintain the Coding Standards. Also each and every user should maintain the subversion and commit the modification with appropriate comment so to have track of work and also of the code modification. From the clients perspective: DEVELOPER SHOULD USE WELL KNOWN TECHNOLOGY. DEVELOPER SHOULD USE WELL KNOWN CODING STANDARDS.

3.5.2: Hardware Limitations

The hardware limitation is very low. The configuration of the client's PC should be high memory wise. FROM THE CLIENTS PERSPECTIVE: CLIENT
SYSTEM. IS HAVING REQUIRED SYSTEM CONFIGURATION TO RUN THE

3.5.3: Interfaces to other Applications

There is no application using this application as an interface so-far.

3.5.4: Parallel Operations

There are no parallel operations as such executing during the operation of the current application.

34

3.5.5: Higher Order Language Requirements

No high order language is required as such. Java language is the only language used in the application. If there is some need to use then we can use that easily.

3.5.6 Reliability Requirements

Reliability requirements of the system are one of the prime ones in the list. The system needs to be highly reliable in terms of performance but at this stage where the complete system is far from completion we cannot gauge its reliability. All we could do is to make the individual module we have developed to be as reliable as possible.

3.5.7: Criticality of the Application:

Criticality means any occurrence of miss operating of the system or any accidental event in software which can damage the resources of software as well as hardware. As per my knowledge there is no criticality in our Application.

3.5.8: Safety and Security Considerations

The main concern for the safety is that only the users registered on this site should be able to access the tenders Moreover the pages to manage the working capital should only be accessible to the DataSoft employees having admin rights to the system. Both these concerns have been attended to by using various measures.

35

3.6 ASSUMPTIONS AND DEPENDENCIES:

The following assumptions have been made during the development of the advance payment system: The admin knows what he is doing while crediting the account or cancelling the credit. .

36

CHAPTER 4 SYSTEM ANALYSIS

37

4.1: REQUIREMENTS OF NEW SYSTEM 4.1.1 Use Case Diagram

Fig 4.1. Use Case Diagram

38

4.1.2 System Requirements

General An e-Tendering System (or Electronic Tendering System) facilitates the complete tendering process the entire tender and the corrigendum details can be viewed. Also the tender notices, tender documents, corrigendum notices can be downloaded from the website. It involves online bidding with Client Details.

Purpose Deleting and Modification of existing records update the table accordingly. Table layouts are designed in such a way such that unnecessary duplication of data is avoided. Thus effectively reducing the total amount of data storage required data in a large mass of data. Java environment provides the user with graphical / visual interface. Reports have been improvised with the facility for individual and group items separately. Facility to add, modify, delete, update etc. are provided in the same form so that the user does not have to switch over from one form to another form to the same.

39

4.2 SYSTEM REQUIREMENTS SPECIFICATION

THE SYSTEM SHALL DO FOLLOWING ACTIVITY. R1. Login Input : username and password Output : successful or not Processing : system checks database and give correct output based upon that R2. Search tender Input : tender name Output : tender details Processing : system search tender database and provide its details R3. Logout Processing: user logout R4. Add category Input: user add category data Output: successfully category add Processing: system store category data into database and provide message R5. FAQ Input : user press question Output : answer of that question provided R6. Forgot password Input : user give proper email data or security question Output : password of that user in email Processing : system match user data with database and provide data based upon that. R7. Inquiry Input : user provide email id and inquiry Output : get inquiry

40

R8. Portfolio Input : user provide data Output : portfolio updated R9. Corrigendum Add Input : corrigendum data Output : corrigendum added R10. Download Portfolio Input : download button pressed Output : save dialog box R11. Add Tender Input : tender data Output : tender added R12. Register Input : user data Output : user registered Processing : system stores user data in database R13. Change password Input : user provide previous password and new password Output : password changed R14. Edit Tender Input : replace old data with new user data Output : tender details edited. R15. Edit category Input : new category data Output : category edited

41

4.3. FEATURES OF NEW SYSTEM

SIMPLIFIES PAYMENTS FOR PURCHASES. REDUCES MANUAL LABOR.

4.4. NAVIGATION CHART

Home Page
Contact Us

Inquiry

FAQ

About Us

FIG 4.2. NAVIGATION CHART FOR THE WEBSITE

42

4.5. SYSTEM ACTIVITY

Access channel with encrypted URL

Login Successful

Login Failed

Show Home Page

Show Unauthorised access page

Fig 4.3. Activity Diagram for Login

43

4.6 Data Modeling

Subcat Name

Sucat_id

Cat_id

Sec_id

Sec_Que

Cat_id

Cat_Name

Subcategory Subat_Desc M Security M Category M

Cat_id

Subcat_id

Manage Manage

Tender_id

Tender Name Description M Issue Tender 1 1 1 1

Manage

Tender

1 Admin 1 P_id

Open Date

Location 1

View Portfolio & Allocate Tender

Close Date Quotation Issue Date Faq_id Manage

Regst_id M Portfolio

Manage F.A.Q M

Tender_id M Expereince Quotation

M Faq_que Faq_ans

T_id M Corrigendum

Crg_id File Path

Crg_Name

Crg_Date

Crg_Desc Inq_id

Reply

M M Inquiry

Inquiry

Inquiry E_mail id

Can View Can Place

Can View

Can Upload

M Search & View Tender M

M Client M

Fig 4.4. ER Diagram.

44

4.7 Data Flow Diagram

The data flow diagrams are pictorial or graphical representation of the outline of the system study. The data flow diagram covers all the processes and data storage area which takes place during any transaction in the system. The data flow diagrams are functionally divided into context level, Zero level, and First level and Second level data flow diagrams. Symbols used in DFD: Process: A process done in the system is denoted by this symbol. For example prepare attendance report, pay slip, etc.

External Entity: A source or destination of data which is external to the system.

A data flow: It is packet of data. It may be in the form of document, letter etc.

Data store: Any store data but with no reference to the physical method of storing.

45

Visit site,do inquiry Visitors Response E-Tendering System

Response Client Seach Tender,Bid Render & upload portfolio

Response

Manage Tender and allocate tender,reply inquiry

Admin

Fig 4.5. Level 0 DFD.

46

Request For Login Client Successfully Login 1.0 Login Process Get Details Registration

Bid Tender

2.0 Tender Process

Store Bid Details Portfolio

Get Acknowledgement

Search Tender

View Tender

3.0 Search Tender Process

Request View Tender Get Tender Details

Request Corrigendum 4.0 Corrigendum Process View Corrigendum

Request View Corrigendum Get Corrigendum Details

Ask Inquiry Question

5.0 Inquiry Process

Store Inquiry Data Inquiry

Request For Update Password 6.0 Change Password

Update Password Registration Password Updated

Successfully Updated

Request For Logout 7.0 Logout Process

Successfully Logout

Fig 4.6. Level 1 DFD for Client

47

Client

Client search Tender

3.0.1 Search Tender

Get Data Tender

Search Tender Categorywise

3.0.2 Typewise Search

Get data categorywise

After Searching Tender client can bid and upload portfolio

3.0.3 Bid Tender and Upload portfolio

Store bid and portfolio

Portfolio

Fig 4.7. Level 2 DFD for Client

48

Request For Login Admin Successfully Login 1.0 Login Process Get Details Registration

Add Category 2.0 Category Process Successfully Add

Store Category Data Category Get Detail

Add Subcategory

3.0 Subcategory Process

Store Subcategory Data Subcategory Get Detail

Successfully Add

Add Corrigendum

Store Corrigendum Data 4.0 Corrigendum Process Get Corrigendum Details Corrigendum

View Corrigendum

Issue New Tender 5.0 Tender Process View Issue New Tender

Store Data Tender Get Tender Data

View or Insert FAQ 6.0 F.A.Q Process Successfully done

Store FAQ Data FAQ Get FAQ Data

View Inquiry 7.0 Inquiry Process Successfully Mail To Client Inquiry Get Data

Allocate Tender View Portfolio 8.0 Portfolio Process View Allocate Tender Result Get Data

View or Insert Security 9.0 Security Process

Store Data Security Get Data

View Security Question

Request For Logout 10.0 Logout Process

Successfully Logout

Fig 4.8. Level 1 DFD for Admin

49

CHAPTER 5 SYSTEM DESIGN

50

5.1 SYSTEM ARCHITECTURE DESIGN

5.1.1 Component Diagram

Admin

CreditAccount ViewData

Data acess

<<DATABASE>> JDBC

Fig 5.1. Component Diagram

51

5.1.4 Deployment Diagram

Fig 5.2. Deployment Diagram

52

5.2 DATA DICTIONARY

5.1. Table name:- Client Registration

SR.NO
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

FIELD
NAME

DATA
TYPE

SIZE CONSTRAINTS DESCRIPTION

50 100 255 50 30 5 10 50 50 25 25 100 100 Primary Key Client id Client name Company name Address Company website Qualification Grade of company Gender Contact number City name Email id (username) Password Confirm password Security question Security answer

Rid Cname Company name Address Company website Qualification Grade Gender Contact number City Email id (user name) Password Confirm password Security question Security answer

Auto inc. Varchar Varchar Varchar Varchar Varchar Varchar Varchar Integer Varchar Varchar Varchar Varchar Varchar Varchar

53

5.2. Table Name:- Inquiry SR.NO

1 2 3

FIELD NAME
I1id Name Email Id

DATA TYPE
Auto Inc. Varchar Varchar

SIZE CONSTRAINTS DESCRIPTION

20 25 P.K. inquiry Id Visitor Name Email Id

5.3. Table Name:- Category: SR.NO

1 2

FIELD NAME
cId Category

DATA TYPE
Auto Increment Varchar

SIZE CONSTRAINTS DESCRIPTION

25 P.K. Category Id Category Name

5.4. Table Name:-Sub Category: SR.NO

1 2 3 4

FIELD NAME
scId cid Sub Category Description

DATA TYPE
Auto Increment Auto Increment Varchar Varchar

SIZE CONSTRAINTS DESCRIPTION

30 100 P.K. F.K. Sub Category Id Category Id Sub Category Sub Category Desc.

54

5.5. Table Name:-Tender: FIELD NAME

TId Tender Name Loc_work Issue Date Open Date Closing Date Quotation Description Cat_Id Scid

SR.NO
1 2 3 4 5 6 7 8 9 10

DATA TYPE
Auto Inc. Varchar Varchar Date Date Date Big Int Varchar Integer Integer

SIZE CONSTRAINTS
100 50 20 100 F.K. F.K. P.K. -

DESCRIPTION
Tender Id Tender name Location of Work Issue Date Open Date Closing date Quotation Tender Description Category Id SubCategory Id

5.6. Table Name:-Corrigendum: FIELD NAME

CId Crname Cr Date Cr Description Tender Id

SR.NO
1 2 3 4 5

DATA TYPE
Auto Inc. Varchar Date Varchar Integer

SIZE CONSTRAINTS
25 100 P.K. F.K.

DESCRIPTION
Corrigendum Id Corrigendum name Corrigendum Date Corrigendum Description Tender Id

55

7. Table Name:-F.A.Q: FIELD NAME

FId F.A.Q ANS

SR.NO
1 2 3

DATA TYPE
Auto Inc. Varchar Varchar

SIZE CONSTRAINTS
255 255 P.K. -

DESCRIPTION
Frequently Asked Question Id Frequently Asked Question Frequently Asked Questions Answer

5.8. Table Name:-Portfolio: FIELD NAME

PId Rid Tender Id File Path Experience Quotation

SR.NO
1 2 3 4 5 6

DATA TYPE
Auto Inc. Integer Integer Varchar Integer Big Int

SIZE CONSTRAINTS
100 20 P.K. F.K. F.K. -

DESCRIPTION
Portfolio Id Client Id Tender Id Document Path Experience of Work Quotation

5.9. Table Name:-Security:

SR.NO
1 2 3

FIELD NAME
SId Security Question Security Answer

DATA TYPE
Auto Increment Varchar Varchar

SIZE CONSTRAINTS
100 100 P.K. -

DESCRIPTION
Secuity Id Security Question Security Answer

56

5.10. Table Name:-Result: FIELD NAME

Rst_id Client Name Company Name E-Mail id Quotation Tender Name

SR.NO
1 2 3 4 5 6

DATA TYPE
Auto Increment Varchar Varchar Varchar Varchar Varchar

SIZE CONSTRAINTS
100 100 100 100 100 P.K. -

DESCRIPTION
Secuity Id Security Question Security Answer Client email id Quotation Tender Name

57

5.3 IMPLEMENTED ALGORITHM

In order to test the concept in this study, a generic algorithm was developed. This algorithm was used to rank and sort results so as to get the best bidder. This algorithm considers the three main methods of bid evaluation namely; Technical evaluation, Commercial evaluation and Financial evaluation. This would aid decisionmaking fervently at the managerial level. This algorithm starts with determining the total weight a given bidder can attain.

The following code snap-shots shows how this algorithm was implemented in the prototype. //THEN GET EXPERIENCE FROM SUM OF PROJECT PERIODS // THIS REWARDS BIDDER WITH MORE EXPERIENCE display="SELECT EXPRIENCE FROM SOLICITATION_DETAILS WHERE CODE="+solicitation+""; rs= stmt.executeQuery(display); rs= stmt.executeQuery(display); while(rs.next()) { system_experience=rs.getInt(1); }//while weight_experience=(period1+period2)/system_experience;

The above code is explained and represented in equation 4.2 below: The system evaluates the weight experience of a bidder based on similar or related projects he has undertaken before. To achieve this, we compare the solicitation details each particular bidder submits as integers in terms of projects a given bidder has undertaken in providing similar or related services as those being tendered. The weight experience therefore, is computed as the sum of period 1 and period 2 divided by the system experience. (We) of (p1 + p2) divided by the system experience (e).

This evaluation assumes that the more projects a bidder has undertaken in the past, the

58

more scores he is likely to attain; thus evaluating competence based on experience in similar or related work. Once the weighted experience is attained, the system evaluates the price (bid cost) and compares with the system ceiling price for a given tender. The following code-snap shot shows how this evaluation was implemented in the prototype. //THEN COMPARE BID PRICE WITH SOLICITATION PRICE // THIS REWARDS BIDDER WITH LEAST PRICE display="SELECT PRICE FROM SOLICITATION_DETAILS WHERE CODE="+solicitation+""; rs= stmt.executeQuery(display); rs= stmt.executeQuery(display); while(rs.next()) { system_price=rs.getInt(1); }//while weight_price=system_price/bid_price; Before any procurement is initiated in government departments, market prices are explored and inflation factors computed, this is ideally done to ensure viability of a bid commercially. At the time of tendering for goods or services, there is a minimum price a bidder must offer for the product in question in this case referred to as the system (ceiling) price. The lower the price as compared with the ceiling price, the more scores one attains. In this study, it was assumed that if we get a bigger price difference, the more we save on the resources allocated to that vote given the budget deficits apparent in the ministry. In this algorithm therefore, weight price is expressed as a difference of system price and bid price. Hence the formula:

In which the weight price (Wp) is expressed as a difference of the system price (Sp) and the bid price (Bp). After attaining the price margin offered, we evaluate the period in which the bidder will be able to accomplish a tender. The system is pre-set with an estimated time within which a good or service can be delivered. The more the bidder offers a completion period far away from the expected time, the least score he gets and vice versa. This is displayed in the following code snap-shot below. //THEN COMPARE BID PERIOD WITH SOLICITATION PERIOD // THIS REWARDS BIDDER WITH LEAST COMPLETION PERIOD display="SELECT PERIOD FROM SOLICITATION_DETAILS WHERE CODE="+solicitation+""; rs= stmt.executeQuery(display); rs= stmt.executeQuery(display); while(rs.next()) { system_period=rs.getInt(1);

59

}//while weight_period=system_period/period;

60

CHAPTER 6 IMPLEMENTATION

61

6.1 IMPLEMENTATION ENVIRONMENT:

FIG 6.1 IMPLEMENTATION ENVIRONMENT

62

TECHNOLOGIES USED: FRAMEWORK

APACHE
DEVELOPMENT. STRUTS HAS BEEN USED AS THE FRAMEWORK FOR

APACHE STRUTS IS

AN OPEN-SOURCE WEB APPLICATION

FRAMEWORK FOR DEVELOPING JAVA EXTENDS THE JAVA

EE WEB

APPLICATIONS. IT USES AND

SERVLET API TO

ENCOURAGE DEVELOPERS TO ADOPT

A MODELVIEWCONTROLLER

(MVC) ARCHITECTURE.

FRONT-END TECHNOLOGY FREEMARKERHAS BEEN USED TO GENERATE THE FRONT END OF THE
APPLICATION.FREEMARKER IS A JAVA-BASED ARCHITECTURE.

TEMPLATE ALTHOUGH

ENGINE FOCUSING

ON THE

MVC SOFTWARE

IT'S MOSTLY USED FOR SERVLET-BASED WEB APPLICATION DEVELOPMENT, IT CAN BE USED FOR ANY OTHER KIND OF TEXT OUTPUT, SUCH AS GENERATING

CSS, JAVA

SOURCE CODE, ETC.

UNLIKE JSP,

IT IS NOT

DEPENDENT ON THE SERVLET ARCHITECTURE OR ON

HTTP. THUS IT CAN BE

USED FOR NON-WEB TASKS AS WELL. FREEMARKER IS FREE SOFTWARE.

DATA ACCESS TECHNOLOGY HIBERNATE

AND THE HAS BEEN USED AS THE BRIDGE BETWEEN THE SYSTEM END.HIBERNATE IS FOR AN OBJECT-RELATIONAL PROVIDING

BACK

MAPPING

(ORM)

LIBRARY

THE JAVA LANGUAGE,

A FRAMEWORK FOR MAPPING AN OBJECT-ORIENTED DOMAIN MODELTO A TRADITIONAL RELATIONAL RELATIONAL IMPEDANCE DATABASE.

HIBERNATE

SOLVES OBJECTBY REPLACING

MISMATCH PROBLEMS

DIRECT PERSISTENCE-RELATED DATABASE ACCESSES WITH HIGH-LEVEL OBJECT HANDLING FUNCTIONS.

BACK-END TECHNOLOGY MYSQL

[5][6]

HAS BEEN USED AS THE BACK-END FOR MANAGING

THE DATABASE.MYSQL IS (AS OF USED OPEN

2008) THE WORLD'S MOST WIDELY

DATABASE MANAGEMENT

SOURCE RELATIONAL

63

SYSTEM

(RDBMS)[7] THAT

RUNS AS A SERVER PROVIDING MULTI-

USER ACCESS TO A NUMBER OF DATABASES.

6.2 CODING STANDARDS:

First of all, analysis of the old application is done. The analysis document is made to reflect the analysis done and understand the flow of the particular webpage. After getting the verification from the guide we proceed with designing part. It starts by preparing the design document. The coding phase starts as soon as the design phase gets over. The input to the coding phase is the design document. After the coding every module is identified individually. After committing the work done i.e. integrating with the application it is tested. Thus objective of this phase is to transform design of a system as in the document to high level language code and to unit this code. For Coding different coding standards and coding guidelines are defined. Coding standards are well-defined for all organizations. Coding standards are some suggestions which make the code better. To check whether coding standards have been followed or not code reviews are carried out.

Reasons for using the coding standards are Uniform distribution Sound understanding

Encourages Good programming skills.

64

6.3SOME IMPLEMENTED CLASSES AND THEIR FUNCTIONS:

65

6.4 SCREENSHOTS: Home Page:

This is the home page cum login page of E-Tendering System.

66

Password Sent via mail:

If the user forgets the login password, it can be retrieved through his registered email id provided during registration. Tender View Page:

If the visitor wants to see the which are the tenders going on, they can see the listing of it.

67

Search Tender:

If the Client wants to search the Tender, he can search by category-wise.

68

Portfolio Upload Page:

If client wants to bid some Particular tender he can upload the portfolio from this page. Allocate Tender Page:

Admin can view the allocated tender details.

69

After Tender Allocation, client gets an email alert:

70

CHAPTER 7. TESTING

71

7.1: TESTING PLAN:

Correctness is the degree to which a software system performs its required function. Correctness is the extent to which a software system is free from any faults.

Software Testing is the critical element of software quality assurance and represents the ultimate review of specifications, design and coding. Testing represents an interesting analogy for the software. The testing phase involves testing of the system using various test data. Preparation of the test data plays a vital role in the system testing.

After preparing the test data, the system under study is tested using those data. Errors found were corrected and corrections were recorded for future references. Thus, a series of testing is performed on the system before it is ready for implementation

The development of the software system involves a series of production activities where opportunities for injection of human fallibility are enormous. Errors may begin to occur at very inception of the process where the objectives may be erroneously or imperfectly specified as well as in the later design and development stages. Because of human inability to perform and communicate with perfection, software development is followed by a quality assurance activity.

72

START

UNIT
TESTING

SUCC
ESS

INTEGRATIO
N TESTING

SUCC
ESS

SYSTEM TESTING

SUCC
ESS

USER
TESTING

SUCC
ESS

SIGN OFF

END

Fig 7.1 Testing steps

73

7.2: TESTING STRATEGY:

A Correct system must accomplish the following:

Compute correct results. Operate safely and cause the system containing the software to operate safely. Perform the tasks required by the system containing the software to operate safely. Perform the tasks required by the system containing the software, as explained in the software applications. Achieve these goals for all inputs. Recognize inputs outside its domain.

We shall see that satisfying these pre-requisites depends on a variety of things. One of these things is to provide clear and correct software specifications.

Testing like development can easily become task that perpetuates itself. As such, the application specifications and subsequently the test plan, should define the minimum acceptable quality to ship the application.

Testing for Performance: After you have identified specific performance requirements, you can begin testing to determine whether the application meets those requirements. Performance testing presumes that the application is functioning, stable, and robust. As such, it is important to eliminate as many variables as possible. For example, bugs in the code can create the appearance, performance problem or even mask performance problem.

Testing for Reliability: Testing for reliability is about exercising an application so that failures are discovered and removed before the system is deployed because the different combinations of pathways through an application are high; it is 74

unlikely that you can identify all potential failures in complex application.

7.3: TESTING METHODS

Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing Black box testing treats the software as a "black box," without any knowledge of internal implementation. Black box testing methods include: Equivalence partitioning:Equivalence partitioning is a software testing technique in which test cases are designed to execute representatives from each equivalence partition, i.e. a partition of input values undergoing similar treatment. In principle, test cases are designed to cover each partition at least once. To reduce the number of test cases to a necessary minimum. To select the right test cases to cover all possible scenarios.

Boundary value analysis:Boundary value analysis is a software testing design technique used to determine test cases covering off-by-one errors. All-pairs testing:All-pairs testing or pairwise testing is a combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameter pairs. The number of tests is typically O(nm), where n and m are the number of possibilities for each of the two 75

parameters with the most choices.

Fuzz testing:Fuzz testing; fuzzing, Robustness Testing or Negative Testing is a software testing technique that provides random data ("fuzz") to the inputs of a program. If the program fails (for example, by crashing, or by failing built-in code assertions), the defects can be noted. The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior.

Model-based testing:Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT). Traceability matrix:A traceability matrix is a table that correlates any two baseline documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (sometimes known as marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases. Exploratory testing:Exploratory testing is a method of manual testing that is concisely described as simultaneous learning, test design and test execution. CemKaner, who coined the term in 1983, now defines exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."

76

Specification-based testing:Specification-based testing aims to test the functionality of software according to the applicable requirements. Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is

not" the same as the expected value specified in the test case. Specificationbased testing is necessary, but it is insufficient to guard against certain risks. Advantages and disadvantages The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers don't. But, on the other hand, black box testing has been said to be "like a walk

in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed. That's why there are situations when (1) a black box tester writes many test cases to check something that can be tested by of the back end are not tested at all. Therefore, black box testing has the advantage of "an unaffiliated opinion," on the one hand, and the disadvantage of "blind exploring," on the other. only one test case, and/or (2) some parts

White box testing

White box testing, by contrast to black box testing, is when the tester has access to the internal data structures and algorithms (and the code that implement these) Types of white box testing The following types of white box testing exist: api testing - Testing of the application using Public and Private APIs. 77

code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once.

fault injection methods. mutation testing methods. static testing - White box testing includes all static testing.

Code completeness evaluation White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are: function coverage, which reports on functions executed And statement coverage, which reports on the number of lines executed to complete the test. They both return coverage metric, measured as a percentage.

Grey Box Testing

In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as "grey-box," because the input and output are clearly outside of the "black-box" that we are calling "the software under test." (This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test.) Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages.

Acceptance testingAcceptance testing can mean one of two things:

A smoke test is used as an acceptance test prior to introducing a build to the main testing process.

78

Acceptance testing performed by the customer is known as user acceptance testing (UAT).

Regression Testing
Regression testing is any type of software testing that seeks to uncover software regressions. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically regressions occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. Non Functional Software Testing Special methods exist to test non-functional aspects of software. Performance testing checks to see if the software can handle large quantities of data or users. This is generally referred to as software scalability. This activity of Non Functional Software Testing is often times referred to as Load Testing. Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers. Internationalization and localization is needed to test these aspects of software, for which a pseudo localization method can be used. In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing. Nonfunctional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as errorhandling routines. Various commercial non-functional testing tools are linked

79

from the Software fault injection page; there are also numerous open-source and free software tools available that perform non-functional testing.

7.4TEST CASES
Test cases for Login Table 7.1 Test Cases for Login Module Description: Login Module ID: Type of Testing: Black Box Sr.No Purpose Input 1 2 Successful Login Login Failed Correct URL Wrong URL Version#:1.1 Test Case Description: Verifying Functionality of Login Expected Output Actual Output Results Login success Unauthorized access As expected As expected Pass Pass

Test cases for Registration Table 7.2 Test Cases for Registration Module Description: Registration Module ID: Type of Testing: Black Box Sr.No Purpose Input 1 Successful Registration Successful Registration Proper personal details Password should be alphanumeric and char >=6 Version#:1.1 Test Case Description: Verifying Functionality of new user registration and validation. Expected Output Actual Output Results Account created As expected and password sent to email. Account created As expected and password sent to email. Pass

Pass

80

Test cases for Tender Management Table 7.3 Test Cases for Tender Management Module Description: Manage Module ID: Type of Testing: Black Box Sr.No Purpose Input 1 Create Tender Version#:1.1 Test Case Description: Verifying Functionality of Tender management Expected Output Actual Output Results As expected Pass

Tender details Tender Created and minimum amount Select appropriate tender Relevant tender

View Tender

As expected

Pass

3 4 5

Corrigendum Search tender

View tender Corrigendum changes if any details Tender Category Relevant tender

As expected As expected As expected

Pass Pass Pass

Portfolio upload Tender details Bid Successful with price > min. Forgot Password Username and Password sent to Security email question

As expected

Pass

81

7.5 TESTING SCREENSHOTS

Client side Validation : User Login Validation Page:

If the user does not enter the user E-mail id, password and so login failed.

82

If the user enters the user E-mail id, password which is wrong it would display an error as login failed.

83

Registration Page Validation Page:

In the registration page all fields are necessary. If User will not fill any of the field so registration will not confirmed.

84

Forgot Password Validation Page:

If the client wants to get back the Password then he should fill up the valid information. Change Password Validation:

If the client wants to change the password then fill the valid information.

85

CHAPTER 8 CONCLUSION AND FUTURE EXTENSIONS

86

8.1

CONCLUSION:

The E-Tendering System has been developed by me through the guidance of our internal guide and referring certain books and browsing some sites. During this period of five months, I learned how to work in a professional environment. I worked sincerely and with camaraderie. I also learnt about the current requirements of IT field regarding the work force. This project taught me to work like professionals. In the initial phase of my project, I was feeling like a ship without radar. But thanks to all those people who guided me so well that I could finish my project satisfactorily. They showed me the right direction and enabled me to complete my work. I cannot find words to express my gratitude towards these personalities. But as nothing is perfect, there are also some limitations in my project. There is always a scope of improvement and new versions can be developed.

I would like to thank the project guide and all those who extended all their support and helped me finish this project successfully.

87

Conclusion And Future Extension

The future enhancements that can be done are to solve these limitations:

8.2.

FUTURE ENHANCEMENT:

Edit bid facility could be added in the bidding module.

Bidding Payment, Tender Fees.

Mobile SMS Alert to Client regarding Tenders could be provided.

VIII

Limitation & Future Enhancement

REFERENCES
Books
Writing Enterprise Applications with Java 2 SDK, Enterprise Edition by Monica Pawlan Java Bible 2nd Edition by John Fronckowiak, Aaron E. Walsh J2EE: The complete Reference by James Keogh

Web References
http://www.roseindia.net/struts/ http://www.vaannila.com/struts/struts-tutorial/struts-tutorial.html http://wiki.apache.org/struts/StrutsTutorials http://viralpatel.net/struts http://www.egov.com

DDU (FACULTY OF TECH., DEPT. OF IT)

117