Assets Auction System (AAS) for Computer Illiteracy

1. INTRODUCTION 

1.          PROJECT SUMMARY 

Assets Auction System (AAS) address the illiteracy in computer education in India. Through this system we will collect the computer systems of any organizations, companies or individuals. Companies keep on updating their system in order to matchup with current technology trends. So companies just put old computer systems aside somewhere in warehouse or they just sell it. These old computer systems can be helpful to learn computer. So we can grab those old systems from companies or organization by setting up an auction. Once we collect those systems we will refine it by doing some upgradation this will make a whole new system. And this system will be given to illiterate or poor people so that they can also learn computer at their own place. There will be 3 main users for this system a company or an organization, an NGO and an administrator. Administrator manages all the other users. An NGO can communicate with the company to setup an auction.

2.          PURPOSE 

The main purpose of this system is to provide a computer system to the poor and illiterate people. Computer illiteracy is major concern in our country and there are several reasons behind it. Poor people cannot afford to buy a new computer system. Another reason is in villages and rural areas computers systems are not easily available. Another purpose of this system is to reuse those old computer systems which are not in use. A whole new computer system can be built by recycling from old computer system and those computer systems can be useful to someone. The key objectives are as follows:

• To reuse and recycle from old assets.
• To provide a computer system to poor and illiterate people.
• To reach out the areas in which computer systems are not easily available.
• To gain computer literacy rate.

3.          SCOPE

The scope of this system to provide the platform on which the company and NGOs can co-ordinate with each other. Where NGOs can send request to companies and organization. The companies reply to the NGOs request and setup an auction if old assets are available to sell. Different NGOs can bid on the auctions the one who got the system will update to administrator. The admin will then assign these systems to technicians for refinement.

4.          TECHNOLOGY AND LITERATURE REVIEW

There may be several NGOs are working independently by their own to help those poor and illiterate peoples in their respective city or area. Though the problem with this approach is NGOs cannot get help from other organizations and companies which are located in some other cities. Similarly, there are several companies which keep updating their computer systems in timely manner and they just sell those old systems randomly. Instead of selling the systems directly what if that system can help some poor or illiterate people to learn from. Though companies and organizations don’t aware about where the poor and illiterate people are so they can’t not able to help them directly. So we are going to make a centralize approach so that companies can upload or sell the old system and NGOs can view it and bid on it if require. Though this approach companies or organization will be able to do:

• Setup an auction for products.
• Sell their old computer systems which are not through auction.
• Can gain CSR (Company Social Responsibility)
• Human Well Fare

Though this approach NGOs will be able to do:

• Can bid to auctions.
• Get the old systems from companies and organizations through the system.
• Refine new system.
• Give the system to poor and illiterate people.

2. SYSTEM REQUIREMENT STUDY

 

1.          User Specification

Types of users are as follows.

• Admin
• Technician
• Company or Organization
• NGOs
• Seller
• End User

1. Admin

• Admin can manage all the user listed above.
• Admin shall responsible to verify user’s registration.
• Admin can send request to companies and NGOs.
• Admin verifies the product submitted by companies for an auction.
• Admin keeps track of all activities which are going on such as auction, registrations etc.
• Admin will showcase all the products which has been submitted for sell.
• Admin can manage the products.
• Admin can generate the whole system work report.
• Admin can add, modify and delete a technician.
• Admin can assign work to specific technician.

2. Technicians

• Technician can view the request generated by the admin.
• Technician can submit report for generated request.
• Technician can modify request contents.

3. Companies/Organization

• Company must register.
• Company can upload the old system for sell.
• Set the prize for product to be sell.
• Company can update the product information.
• Company can delete the product.
• Company can view their own product.

4. NGOs

• NGO must register.
• NGO can view the details of products.
• NGO can search for a product.
• NGO can bid for the products listed for auction.
• NGO can modify the bidding price.

 

5. End User
   • User must register.
   • Users can upload their old products for sell.
   • Users can add, alter or delete the product.
   • Users can view the product.
   • Users can provide product information.
   • Users can view the refurbished products uploaded by sellers.
   • Users can add or update profile information.
   • User can buy refurbished product.
   • Users can track shipment.
   • Users can raise complain for a purchase he/she made.
   • Users can submit return request.

2.          Hardware and Software Requirements

 

1.      Hardware Requirements

 

1.            Server Side:

Processor : 2.20 GHz or high Ram  : 4 GB Hard Disk : 10 GB of Available Space

2.            Client Side:

Processor : 1.80 GHz or high Ram  : 1 GB Hard Disk : 4 GB of Available Space

2.      Software Requirements

 

1.            Server Side:

Operating System : Linux, Windows server 2003 or later Web Server : Apache 2.4.23 Front End : PHP 5.6.25 Back End : MySQL 5.7.14

2.            Client Side:

Operating System : Windows XP or later, Linux, Mac Browser  : Internet Explorer, Mozilla Firefox,                              Google chrome or any equivalent

3.          Constraints

 

1. Time Frames

Time is the important factor in consideration while developing any project as the project should be delivered within time. The amount of time requires to produce deliverable project is related to the requirements

2. Cost

The cost is second most important factor in consideration while developing any project. Cost covers various things such as resources, labor and rates these components defines overall cost of the project. As our system does not require any external resources expect a server that run our web application.

3. Scope

The scope generally defines the outcome of the project. This contains deliverable product to the user as per the requirement specified which need to understand by project manager The major functionality of the scope is to maintain the quality in the project if developer is failed to maintain the quality of the project than customer will not get satisfy and will create problem for both of them. As scope of our system is to provide a quality platform to two different types of user for e.g. company and NGOs so that they can communicate in better way.

4. Interface to other Applications

This constraint describes the application’s relationship to other systems. For example,

• Does the application is independent?

This application does integrate different application to provide some of the user friendly functions. Like, we have used payment gateways for payment integration etc.

• Is it replacement of another system?

No it does not replace any system. It just merges the different existing system into single frame.

5. Reliability Requirements

These requirements mean to specify the numerical reliability targets for the application based on system level reliability targets and known reliability of other components. Mainly reliability means your application should be reliable in each and every case i.e. either in erroneous code or in error free code.

6. Criticality of the Application

The main criticality of this system is if the server goes down then this system won’t work. Or else in case of traffic increasing the sever would not able to control the traffic system goes down.

7. Safety Security Consideration

The system is providing basic security to user’s account. All users accounts are secure by password and some encryption standards. If any security violation will found, then at time service will be blocked. Unauthorized user cannot login to this system.

4.          Timeline Chart and Process model
   1.      Timeline Chart

    Fig 2.4.1: Timeline Chart  

2.      Process Model

• Spiral Model

• The spiral model is combination of the iterative nature of the prototype model and controlled and systematic approach of the linear sequential model or we can say waterfall model.
• This model gives efficient development of incremental versions of the software. Here the software is developed in series of increments.
• The model is divided into a number of activities called as task region.
• Usually there are six tasks region
• It allows for incremental releases of the product, or incremental refinement through each iteration around the spiral.

 

• Why Spiral Model?

 

• If changes in requirements arises after requirement gathering, then it can be accommodated.
• Risks can be identified before it gets problematic.
• Requirements can be captured with more accuracy.
• Users see the system as early as possible.
• Development can be divided into smaller parts and riskier parts can be developed earlier which helps better risk management.

 

3. SYSTEM ANALYSIS

1. Study of Current System

Computer illiteracy is major concern in our country as recent survey has revealed only 7% peoples know how to operate or how to use a computer. Computer education is easily available in most of the area but computer systems are not easily available in many of the area most likely in rural and urban areas. Even though systems are available but many peoples cannot afford it and this may lead into illiteracy gain because they are not able to enhance their learning. Many NGOs and government educational institutions are working in their area to help illiterate and poor people. Computer education can only provide teaching and on the bases of teaching we cannot say that the person is having literacy in computer. The person must be able to use and operate the computer by his/her own and this may only happen if he/she gets real time experience with computers. We believe that the person can only be enhance his/her learning if he/she have computer system at their own place.

2. Problem and Weakness of Current System

• Computers are not made easily available in many rural and urban areas.
• No survey has ever taken for illiterate and poor peoples.
• Only computer education is provided no real time experience.
• Expensive new systems.
• No dedicated support in case of new purchase.

3.  Requirement of New System

Many companies which keep updating their computer systems in timely manner and they just sell those old systems randomly. Instead of selling the systems directly what if that system can help some poor or illiterate people to learn from. Though companies and organizations don’t aware about where the poor and illiterate people are so they can’t not able to help them directly. There may be several NGOs are working independently by their own to help those poor and illiterate peoples in their respective city or area. Though the problem with this approach is NGOs cannot get help from other organizations and companies which are located in some other cities. The main problem with this kind of approach is centralization. We are going to make a centralize approach so that companies can upload or sell the old system and NGOs can view it and bid on it if require. After purchase we must refine the old computer system by doing some upgradation and these refined systems shall be given to poor and illiterate people for low cost or for free depending upon the situation and criteria.

4. Feasibility Study

• Economic Feasibility

The Asset Auction System(ASS) can be developed economically. This project not require more amount of money to be developed so it is economically feasible. The overall cost of project depends upon the number of man hours required to develop the project.

• Operational Feasibility

This system is operationally feasible because it is very easy for the NGOs and companies to operate it. End user only require some basic knowledge about computer and web so that he/she can operate system easily.

• Technical Feasibility

  Technical feasibility specifies whether the project undertaken of development is technically feasible or not. Front-end and back-end selection

• When we decide to develop a project the first aspect is selection of suitable front-end and back-end. We should study and determine the most suitable platform that best suites the requirements as well as helps in development of the project. The aspects of study include following factors.

Front-end selection:

• GUI (graphical user interface) should be developed in such a way that it assists the end user that are not from technical background.
• It should be Flexible.
• It should be Robust.
• It should be According to the requirement specified.
• Must provide reporting features with printing support.
• It should be platform independent.
• Event driven programming facility.

According to the above stated features we have selected PHP server side scripting language as the front end tool. Back-end Selection:

• It should support multiple user.
• It Should handle data Efficiently.
• It Should Provide features for security.
• It should faster and efficient data retrieval and maintenance.
• It should support stored procedures.
• It compatible with any operating System.
• Easy to install.
• Easy to implant with the Front-end.

According to the above stated features we have selected MySQL Server as back end tool.

5.   Requirements validation

• The Id no field should contain only 10 digits.
• The Date format should be MM-DD-YYYY.
• From date and to date must be past date.
• To date must be greater than from date.
• All forms id number must be 10 digits.
• Email Id must have “.” And “@” symbol.
• Website Name must be Start with “www.”.
• Phone number must contain numeric value.
• Fax number must contain numeric value.
• Mobile number must be verified
• Mobile number must contain (+) before phone number.

6.   Functions of System

  3.6.1 Use Cases for Admin           Fig 3.6.1: Use case for Admin   3.6.2 Use Cases for Company         Fig 3.6.2: Use case for Company   3.6.3 Use Cases for NGO         Fig 3.6.3: Use case for NGO   3.6.4 Use Cases for Technician       Fig 3.6.4: Use case for Technician 3.6.5 Use Cases for End User       Fig 3.6.5: Use case for End User   3.6.6 Use Cases for Admin and Company         Fig 3.6.6: Use case for Admin and Company 3.6.7 Use Cases for NGO and Company         Fig 3.6.7: Use case for NGO and Company

7.   Data Modeling

  3.7.1 E-R Diagram     Fig 3.7.1: E-R Diagram 3.7.2 Class Diagram     Fig 3.7.2: Class Diagram   3.7.3 System Activity   Fig 3.7.3.1: Bidding Activity Fig 3.7.3.2: Swim lane Diagram for Bidding 3.7.4 Data Dictionary

1. Registration

Table Name: Registration Master Primary Key: UserId

s.no	Field	Data type	size	Constrain	Description
1	UserId	Int	-	P_K	Auto Increment , P_K
2	Name	Varchar2	20	Not null	Full Name
3	Username	Varchar2	20	Not null	Username
4	Address	Varchar2	100	Not null	Execute add
5	State Id	Varchar2	30	F_K	Name of state
6	City id	Varchar2	25	Not null	Name of city
7	Cont_no	number	10	Not null	Contact no
8	Email_id	Varchar2	10	Not null	Email ID
9	Password	Varchar2	10	Not null	Password of comp
11	Web name	Varchar2	20	Null	Name of website
12	UserType	Varchar2	10	Not null	Type of User

Table 3.7.4.1: Registration Master  

2. State Master

Table Name: State Master Primary Key: State_id

S.no	Field	Data type	size	Constraint	Description
1	State_id	Int	-	P_K	Auto increment
2	State name	Varchar2	25	Not null	Name of city

Table 3.7.4.2: State Master

3. City Master

  Table Name: City Master Primary Key: City_id

S.no	Field	Data type	size	Constraint	Description
1	City_id	Int	-	P_K	Auto increment
2	State_id	Int	-	F_K	Stores State Id
3	cityname	Varchar2	10	Not null	Name of city

    Table 3.7.4.3: City Master  

4. Bid Master

  Table Name: Bid_Master Primary Key : Bid_id

Sr. No	Column  Name	Data Type	Size	Constraint	Description
1	Bid_id	Int	-	Primary key	It stores Id of Bidding.
2	Product_ id	Int	-	Foreign key	Id of the Products(Product Master).
3	Userid	Nvarchar	25	Foreign key	It reference to User_master table.
4	Bid_Date	Datetime	-	Not Null	It stores the Date of Bidding.
5	Bid_Price	Numeric	(10,2)	Not Null	It stores the Bid price of Products.
6	StartDate	Date	-	Not Null	Bid Start Date
7	EndDate	Date	-	Not Null	Bid End Date
8	isConfirmed	Bool	-	Not Null	Check of bid confirmation

  Table 3.7.4.4: Bid Master  

5. Category Master

Table Name: Category_Master Primary Key : Cat_id  

Sr. No	Column  Name	Data Type	Size	Constraint	Description
1	Cat_id	Int	-	Primary key	It stores unique
2	CatName	Nvarchar	-	Not Null	It store category

Table 3.7.4.5: Category Master      

6. System Master

Table Name: System Master. Primary Key: Cid

Sr. No	Column  Name	Data Type	Size	Constraint	Description
1	Cid	Int	-	Primary key	It stores Id of Computer System.
2	Product_ id	Int	-	F_K	Id of the Product.
3	IsWorking	Bool	-	Not Null	Working or not
4	CompDesc	Varchar	100	Not Null	Computer Description
5	TechnicialId	Int	-	F_K	Updated By technician
6	IsAssigned	Bool	-	Not Null	Assigned or not
7	UserId	Int	-	F_K	Stores User Assigned To

  Table 3.7.4.6: System Master  

7.  News Master:

Table Name: News_Master Primary Key:  News_id

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	News_id	Int	-	Primary key	It stores News id
2	News_name	Varchar	MAX	Not Null	It stores news.
3	Desc	Varchar	MAX	Not Null	News Description

Table 3.7.4.7: News Master

8.   Feedback Master

Table Name: Feedback_Master Primary Key:  News_id

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	F_id	Int	-	Primary key	It stores Feedback id
2	Name	Varchar	15	Not Null	It stores name
3	Email	varchar	25	Not Null	It stores email.
4	Contact	Numeric	10	Not Null	It stores contact
5	Subject	Varchar	50	Not Null	It stores subject.
6	Msg	varchar	MAX	Not Null	It stores  Message.

Table 3.7.4.8: Feedback Master  

9.  People Master

Table Name: PeopleMaster Primary Key: peopleId

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	peopleId	Int	-	Primary key	Stores People Id
2	Name	Varchar	30	Not Null	It stores name
3	Address	varchar	100	Not Null	It stores Address
4	Contact	Numeric	10	Not Null	It stores contact
5	CityId	Int	-	F_K	It stores City Id.
6	StateId	Int		F_K	It stores  StateId.
7	isPoor	Bool	-	Not Null	Stores Boolean value
8	isIlitrate	Bool		Not Null	Stores Boolean value
9	isVerified	Bool		Not Null	Stores Boolean value

  Table 3.7.4.9: People Master      

10.  Transaction Master

  Table Name: Transaction_master Primarykey: TransactionId

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	TransactionId	Varchar	30	Primary Key	It stores Transaction Id
2	Date	Date	-	Not Null	It stores Date of transaction
3	UserId	Int	-	Not Null	It stores user Id
4	Amount	Number	-	Not Null	It stores amount
5	Time	Time	-	Not Null	It stores time of transaction.
6	Type	Varchar	10	Not Null	Stores type of transaction

Table 3.7.4.10: Transaction Master  

11.  Donate Master

  Table Name: Donate_master Primarykey: Id

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	Id	Int	-	Primary key	Stores Unique Id
2	TransactionId	Varchar	30	F_K	It stores Transaction Id
3	Date	Date	-	Not Null	It stores Date of transaction
4	UserId	Int	-	Not Null	It stores user Id
5	Amount	Number	-	Not Null	It stores amount
6	Time	Time	-	Not Null	It stores time of transaction.

Table 3.7.4.11: Donate Master            

12. Complain Master

Table Name: ComplainMaster Primarykey: CompId

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	CompId	Int	-	Primary key	Stores Unique Id
2	ProductId	Int	-	Not Null	Product Name
3	UserId	Int	-	Not Null	User Name
4	CompDesc	Varchar	200	Not Null	Description Of complain

Table 3.7.4.12: Complain Master

13. Courier Master

Table Name: CourierMaster Primarykey: CourierId

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	CourierId	Int	-	Primary key	Stores Unique Id
2	Name	Varchar	30	Not Null	Name of Courier
3	Address	Varchar	100	Not Null	Address Of Courier
4	CityId	Int	-	Not Null	Stores City Id
5	StateId	Int	-	Not Null	Stores State Id
6	Contact	Number	10	Not Null	Stores Contact Info
7	Email	Varchar	30	Not Null	Stores Email Address

  Table 3.7.4.13: Courier Master  

14.  Shipment Master

Table Name: ShipmentMaster Primarykey: ShipId

Sr. No	Column Name	Data Type	Size	Constraint	Description
1	ShipId	Int	-	Primary key	Stores Unique Id
2	CourierId	Int	-	Not Null	Name of Courier
3	FromCity	Int	-	Not Null	Origin City
4	ToCity	Int	-	Not Null	Destination City
5	UserId	Int	-	Not Null	User Name
6	ProductId	Int	10	Not Null	Product Name

Table 3.7.4.14: Shipment Master

8.  Control Flow Diagram

    Fig 3.8: Control Flow

9.  Main Modules of new System

 

• Admin Module
• Technician Module
• Company Module
• NGO Module
• End User Module
• Product Module
• Payment Module

 

4. SYSTEM DESIGN

 

1.         Data Structure Design

 

1.   Table & Relationship

    Fig 4.1.1: Table and Relationship

2.         System Procedural Design

 

1.   Designing Pseudo Code or Algorithm for method

The bcrypt is a one-way password hashing function which was designed by Niels Provos and David Mazières at USENIX in 1999. It is based on the Blowfish Cipher. To protect against rainbow table attacks we use one addition parameter called salt, we can increase number of iteration count in to make it slower, so it remains secure against the brute-force attacks even with increasing computation power. The bcrypt uses the prefix "$2a$" or "$2b$" (or "$2y$") in hash string in a shadow password file indicates that hash string is a bcrypt hash in modular crypt format. The rest of the hash string includes the cost parameter of the bcrypt hash, a 128-bit salt (base-64 encoded as 22 characters), and 184 bits of the resulting hash value (base-64 encoded as 31 characters). The cost parameter specifies a key expansion iteration count as a power of two, which is an input to the crypt algorithm. For example, password record is shown as below: 2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy The above hashed password specifies a cost parameter of 10, indicating 210 key expansion rounds. And the given salt while hashing is: N9qo8uLOickgx2ZMRZoMye The resulting hash is IjZAgcfl7p92ldGxad68LJZdL17lhWy. Why this bcrypt selected? The bcrypt. uses Blowfish to encrypt a string, it uses a key "derived" from the password entered by the user. Later on, when the user reenters the password the key is derived again, the user is authenticated if the cipher text produced by encrypting with that key matches the stored cipher text, however the password is stored in the database table, but the derived key is never stored in table. In order to break the cryptography, the attacker would have to recover the key from the cipher text. This type of attack is called a "known-plaintext" attack, since the attack knows the magic string that has been encrypted, but not the key used. Blowfish has been studied extensively, and no attacks are yet known that would allow an attacker to find the key with a single known plaintext. The bcrypt is just like irreversible algorithms based cryptographic digests, it produces an irreversible output, from a password, salt, and cost factor. Its strength lies in Blowfish's resistance to known plaintext attacks, which is analogous to a "first pre-image attack" on a digest algorithm. Since it can be used in place of a hash algorithm to protect passwords, bcrypt is confusingly referred to as a "hash" algorithm itself. Assuming that rainbow tables have been thwarted by proper use of salt, any truly irreversible function reduces the attacker to trial-and-error. And the rate that the attacker can make trials is determined by the speed of that irreversible "hash" algorithm. If a single iteration of a hash function is used, an attacker can make millions of trials per second using equipment that costs on the order of $1000, testing all passwords up to 8 characters long in a few months.

3.         Input/output and Interface Design

 

1.   State Transition Diagram

      Fig 4.3.1.1: State Transition for Registration       Fig 4.3.1.2: State Transition for Bidding   Fig 4.3.1.3: State Transition for Product Upload

2.   Sequence Diagram

    Fig 4.3.2.1: Sequence Diagram for Admin Activity       Fig 4.3.2.2: Sequence Diagram for NGO Activity   Fig 4.3.2.3: Sequence Diagram for Company Activity     Fig 4.3.2.4: Sequence Diagram for Combine Operation System, Company &NGO  

5. IMPLEMENTATION & PLANNING AND DETAILS

5.         IMPLEMENTATION ENVIRONMENT

 

• OS Name: Windows 10
• Version: Pro
• Other OS Description: All windows system
• OS Manufacturer: Microsoft Corporation
• System Name: neerav
• System Manufacturer: Samsung
• System Model: 300E5EV
• System Type: 64-bit Operating System
• Processor: Intel CORE I3-3120 CPU @ 2.50GHZ
• BIOS Version: 2.7
• Windows Directory: C\WINDOWS
• System Directory: C:\\WINDOWS\system32
• BOOT Device: \Device\Hard disk\Volume2
• Locale: India
• User Name: Nirav Shah
• Time Zone: (GMT+05:30) Chennai, Kolkata, Mumbai, New Delhi
• Total Physical Memory: 4.00 GB

6.          MODULE SPECIFICATION

  Following modules are included in our system.  

• Bidding
• Complain and Service
• Refurbished Product
• Shipping and Tracking
• Mailing and Password

BIDDING

• NGO can bid for the products listed for auction.
• NGO can modify the bidding price.

REFURBISHED PRODUCT

• Refurbished products are normally tested for functionality and defects before they are sold.
• It is repaired from manufacturer and resold.
• Admin will upload refurbished products for auction.
• Users will able to bid on refurbished products.

Complain and Service

• Users can raise a service or complain request.
• Technician will be assigned by to a particular request in order to resolve user’s problem.
• Technician will co-ordinate with user if require.

Shipping and Tracking

• The products will be shipped to user from concern courier partners.
• User will able to track the product form the system once it gets shipped.

Mailing and Password

• The users will get a mail confirmation for every action performed on system.
• Password will be auto generated by system for staff members.
• If user forgets his/her password, he/she will get an OTP on their registered email address upon forgot password request.
  7.          SECURITY FEATURES

Asset Auction System provides security facility in which Login Id and password verification is required. Users must have to register in order to user more functionality of the system. Once users do registration admin will verify their details and grant them access to user the system. Only authorized users will be able to login into the system. If any malicious user is found on the system, then admin will disable his/her login credentials. If user forgets his/her password, he/she will get an OTP on their registered email address upon forgot password request.

8.          CODING STANDARDS

Checks for Normal Working	ToBeChecked?
Does your system save correct data in database?	*
In update does your screen load correct data?	*
Fields are showing the data in correct format?	*
Data	*
Integer	*
String	*
Will your screen generate notification and stop if wrong data type is entered?	*
Does your system work flow is correct?	*

  Table 5.1: Coding Standards

Basic Validations
Validation for Required field is done?	*
Validation for Integer, String, Date, Time is done?	*
Type Check / Type Safety	*
Boundary Value Analysis (for highest order value and lowest order value)	*
Date Format	*

  Table 5.2: Coding Standards  

9.          SAMPLE CODING

  if(isset($_POST['submit'])){ $regAs = $_POST['regAs']; $name = $_POST['txtName']; $txtAddress = $_POST['txtAddress']; $stateId = $_POST['state']; $cityId = $_POST['city']; $txtContactPerson = $_POST['txtContactPerson']; $txtEmail = $_POST['txtEmail']; $txtContact = $_POST['txtContact']; $txtPass = $_POST['txtPass']; $txtCpass = $_POST['txtCpass']; $txtUrl = $_POST['txtUrl']; $query = "select 1 from registration where email='$txtEmail'"; $result = mysqli_query($conn,$query); if(mysqli_num_rows($result)>0){ echo ("<SCRIPT> window.alert('Email is already registered with us'); </SCRIPT>"); } elseif($txtPass!==$txtCpass){ echo ("<SCRIPT> window.alert('Password doesnt match'); </SCRIPT>"); } else{ validatedata($regAs); validatedata($name); validatedata($txtAddres); validatedata($stateId); validatedata($cityId); validatedata($txtContactPerson); validatedata($txtContact); validatedata($txtEmail); validatedata($txtPass); $txtPass = password_hash($txtPass,PASSWORD_DEFAULT); validatedata($txtUrl); $query="insert into registration(regAs,Name,address,stateId,cityId,contactPerson,contact,email,password,weburl)values('$regAs','$name','$txtAddress','$stateId','$cityId','$txtContactPerson','$txtContact','$txtEmail','$txtPass','$txtUrl')"; $result=mysqli_query($conn,$query); if($result){ header("Location:registration.php?alert=success"); } else{ header("Location:registration.php?alert=error"); } } } ?> Registration.php Sample Code

6. ­TESTING

 

4.         TESTING PLAN

  Testing Planning involves how to plan testing before we are going to start making test suite. The first step while doing system testing is testing each module one by one. After testing each module separately second step is to test all the module by linking them together. After merging all modules into one in third step we have tested each module canonically whether each module is linked up with each other correctly or not. For the testing purpose we have used both white box testing and black box               testing. In white box testing structural testing is done so all the modules are tested one               by one and finally when the project is completed black box testing is used to test the               whole system together.

5.         TESTING STRATEGY

Testing begins "in the small" and progresses "to the large". Initially individual components are tested using white box and black box techniques. After the individual components have been tested and added to the system, integration testing takes place. Once the full software product is completed, system testing is performed. The Test Specification document should be reviewed like all other software engineering work products. A sample Test Specification document appears on the SEPA web site. Strategic Approach to Software Testing

• Testing begins at the component level and works outward toward the integration of the entire computer-based system.
• Different testing techniques are appropriate at different points in time.
• The developer of the software conducts testing and may be assisted by independent test groups for large projects.
• The role of the independent tester is to remove the conflict of interest inherent when the builder is testing his or her own product.
• Testing and debugging are different activities.
• Debugging must be accommodated in any testing strategy.
• Make a distinction between verification (are we building the product right?) and validation (are we building the right product?)

Strategic Testing Issues

• Specify product requirements in a quantifiable manner before testing starts.
• Specify testing objectives explicitly.
• Identify the user classes of the software and develop a profile for each.
• Develop a test plan that emphasizes rapid cycle testing.
• Build robust software that is designed to test itself (e.g. uses anti-bugging).
• Use effective formal reviews as a filter prior to testing.
• Conduct formal technical reviews to assess the test strategy and test cases.

Unit Testing

• Black box and white box testing.
• Module interfaces are tested for proper information flow.
• Local data are examined to ensure that integrity is maintained.
• Boundary conditions are tested.
• Basis path testing should be used.
• All error handling paths should be tested.
• Drivers and/or stubs need to be developed to test incomplete software.

Integration Testing Top-down integration testing

• Main control module used as a test driver and stubs are substitutes for components directly subordinate to it.
• Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach).
• Tests are conducted as each component is integrated.
• On completion of each set of tests and other stub is replaced with a real component.
• Regression testing may be used to ensure that new errors not introduced.

Bottom-up integration testing

• Low level components are combined in clusters that perform a specific software function.
• A driver (control program) is written to coordinate test case input and output.
• The cluster is tested.
• Drivers are removed and clusters are combined moving upward in the program structure.

Regression testing

• Representative sample of existing test cases is used to exercise all software functions.
• Additional test cases focusing software functions likely to be affected by the change.
• Tests cases that focus on the changed software components.

Smoke testing

• Software components already translated into code are integrated into a build.
• A series of tests designed to expose errors that will keep the build from performing its functions are created.
• The build is integrated with the other builds and the entire product is smoke tested daily (either top-down or bottom integration may be used).

6.          TESTING METHODS

There are mainly two types of testing

• Black box testing
• White box testing (control Structure testing)

White Box Testing There exist several popular white-box testing methodologies

• Statement coverage
• Branch coverage
• Path coverage
• Condition coverage
• Mutation testing
• Data flow-based testing

Statement coverage

• Statement coverage methodology focuses on, designing test cases so that,
• Every statement in a program is executed at least once.
• No statement in the program should remain unreachable.
• The principal idea is, unless a statement is executed, we have no way of knowing if an error exists in that statement

Branch coverage Test cases are designed such that, different branch conditions

• Branch testing guarantees statement coverage.
• It is a stronger testing compared to the statement coverage-based testing.

Path coverage Design test cases such that, all linearly independent paths (LIP) in the program are executed at least once. To understand the path coverage-based testing we need to learn how to draw control flow graph of a program. A control flow graph (CFG) describes,

• The sequence in which different instructions or statements of a program get executed.
• The way control flows through the program.

Condition coverage Test cases are designed such that, each component of a composite conditional               expression It help us to,

• Gives both true and false values.
• To check for all combination of conditions.

Mutation testing The software is first tested: using an initial testing method based on white-box               strategies we already discussed. After the initial testing is complete, mutation testing is taken up. The idea behind mutation testing: make a few arbitrary small changes to a program at a time. Each time the program is changed, it is called a mutated program the change is called a mutant. If there exists at least one test case in the test suite for which: A mutated program: tested against the full test suite of the program. a mutant gives an incorrect result, then the mutant is said to be dead. Data flow-based testing Selects test paths of a program: according to the locations of definitions and uses of different variables in a program. A variable X is said to be live at statement S1, if X is defined at a statement S: there exists a path from S to S1 not containing any definition of X. For a statement numbered S,

• DEF(S) = {X/statement S contains a definition of X}
• USES(S)= {X/statement S contains a use of X}
• Example: 1: a=b; DEF (1) = {a}, USES (1) = {b}.
• Example: 2: a=a + b; DEF(1)={a}, USES(1)={a, b}

One simple data flow testing strategy: every DU chain in a program be covered               at least once. Data flow testing strategies: useful for selecting test paths of a program               containing nested if and loop statements. Black Box Testing Equivalence Partitioning

• Black-box technique that divides the input domain into classes of data from which test cases can be derived.
• An ideal test case uncovers a class of errors that might require many arbitrary test cases to be executed before a general error is observed.
• Equivalence class guidelines:

1. If input condition specifies a range, one valid and two invalid equivalence classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
4. If an input condition is Boolean, one valid and one invalid equivalence class is defined.

Boundary Value Analysis

• Black-box technique that focuses on the boundaries of the input domain rather than its center.

BVA guidelines

• If input condition specifies a range bounded by values a and b, test cases should include a and b, values just above and just below a and b.
• If an input condition specifies and number of values, test cases should be exercise the minimum and maximum numbers, as well as values just above and just below the minimum and maximum values.
• Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the minimum and maxim output reports If internal program data structures have boundaries (e.g. size limitations), be certain to test the boundaries.

1. For system testing verify that with data from database u can login is depending on the valid username and password. 2. Repeat the steps laid out in the until testing keep in mind that we are in specific user account and verify that data is for correct account. Testing usually includes many phases and should be done systematically.

7.          TEST CASES

 

1. Administrator

 

SR NO.	LABEL	DESCRIPTION	EXPECTED RESULT	ACTUAL RESULT
1	Email id	Email id is added & it is in particular format	If particular symbol is not added then it will not take this value	Test is successfully completed
2.	Password	When password is correct admin will able to login if not message will be generated	Right credential redirects admin to dashboard and wrong credentials prompt “invalid credentials”	Test is successfully completed
3	Staff User Management	Admin can add staff user for services & handling complains	Admin is able to add new staff user	Test is successfully completed
4	City and State Management	Admin can add , delete and update state and city data.	Admin is able to add, change and delete the city and state data.	Test is successfully completed
5	Inventory Management	Admin can manage inventory by adding, removing and altering.	Admin is able to manage inventory list.	Test is successfully completed
6	Computer’s Components Management.	Admin can add, update and delete computer components.	Admin is able to add, update and delete computer components.	Test is successfully completed
7	End User Management	Admin can view user information and can modify their access rights.	Admin is able to change user information and access rights.	Test is successfully completed
8	Stories and blog Management	Admin can add recent stories and blogs to the system.	Admin is able to add, modify and delete stories and blog.	Test is successfully completed
9	Refurbished Products Management	Admin can add, modify and delete refurbished product for sell.	Admin is able to add, modify and delete refurbished product for sell.	Test is successfully completed
10	Complain Management	Admin can view the complaints generated and assign to technicians	Admin is able to assign complain to technicians	Test is successfully completed
11	Mail and Managements	Admin can able to view mails and message sent by guest user	Admin is able to view mails and message sent by guest user and reply.	Test is successfully completed
12	Donation Management	Admin can able to see the donation given by the users.	Admin is able to see the donation given by the users.	Test is successfully completed

  Table 6.1: Test Cases for Admin

2. NGO

 

SR NO.	LABEL	DESCRIPTION	EXPECTED RESULT	ACTUAL RESULT
1	Email id	Email id is added & it is in particular format	If particular symbol is not added then it will not take this value	Test is successfully completed
2.	Password	When password is correct user will able to login if not message will be generated	Right credential redirects user to dashboard and wrong credentials prompt “invalid credentials”	Test is successfully completed
3	View Uploaded Products and bid on it	NGO can view products and bid on a particular product.	NGO is able to view products and bid on it as per need.	Test is successfully completed
4	Poor People Management	NGO can add , delete and update Poor people data.	NGO is able to add, delete and update Poor people data.	Test is successfully completed
5	Suggests Project	NGO can suggest project to admin for human welfare	NGO is able to suggest project to admin for human welfare	Test is successfully completed
6	Mail Management	NGO can send or receive mails from admin and company	NGO is able to send or receive mails from admin and company	Test is successfully completed
8	Stories and blog Management	NGO can add recent stories and blogs to the system.	NGO is able to add stories and blog.	Test is successfully completed
10	Raise Complain	NGO can raise the complaint generated if require	NGO is able to raise the complaint generated if require	Test is successfully completed
12	Assign Computers to people	NGO can assign computer to peoples.	NGO is able to assign computer to peoples.	Test is successfully completed
13	Profile Management	NGO can manage their user profile.	NGO is able manage their user profile.	Test is successfully completed

Table 6.2: Test Cases for NGO

3. Company

 

SR NO.	LABEL	DESCRIPTION	EXPECTED RESULT	ACTUAL RESULT
1	Email id	Email id is added & it is in particular format	If particular symbol is not added then it will not take this value	Test is successfully completed
2.	Password	When password is correct user will able to login if not message will be generated	Right credential redirects user to dashboard and wrong credentials prompt “invalid credentials”	Test is successfully completed
3	Upload Products for auction	Company can upload products	Company is able to upload products	Test is successfully completed
4	Manage company profile	Company can manage their user profile	Company is able to manage their user profile	Test is successfully completed
5	View uploaded products and search if require	Company can view uploaded products and search for uploaded product	Company is able to view uploaded products and search for uploaded product	Test is successfully completed
6	Mail Management	Company can send or receive mails from admin and company	Company is able to send or receive mails from admin and company	Test is successfully completed
8	Stories and blog Management	Company can add recent stories and blogs to the system.	Company is able to add stories and blog.	Test is successfully completed
10	Raise Complain	Company can raise the complaint generated if require	Company is able to raise the complaint generated if require	Test is successfully completed
12	Make Donation	Company can make donation.	Company is able to donate.	Test is successfully completed

Table 6.3: Test Cases for Company

4. Technician

 

SR NO.	LABEL	DESCRIPTION	EXPECTED RESULT	ACTUAL RESULT
1	Email id	Email id is added & it is in particular format	If particular symbol is not added then it will not take this value	Test is successfully completed
2.	Password	When password is correct technician will able to login if not message will be generated	Right credential redirects technician to dashboard and wrong credentials prompt “invalid credentials”	Test is successfully completed
3	Complain Management	Technician can see the list of complain raised, and change the status.	Technician is able to see the list of complain raised, and change the status.	Test is successfully completed
4	Request Part	Technician can request for components to admin	Technician is able to request for components to admin	Test is successfully completed
6	Mail Management	Technician can send or receive mails from admin and user	Technician is able to send or receive mails from admin and user	Test is successfully completed

Table 6.4: Test Cases for Technician

7. ­SCREENSHOTS

    Fig 7.1: Home Page     Fig 7.2: Login Page   Fig 7.3: Registration From   Fig 7.4: Registration Success   Fig 7.5: Staff Login       Fig 7.6: Admin Dashboard   Fig 7.7: Admin Add City     Fig 7.8: City List   Fig 7.9: Admin Add State     Fig 7.10: Admin State List   Fig 7.11: Admin Add User     Fig 7.12: Admin User List     Fig 7.13: Admin Add CPU       Fig 7.14: Admin CPU List         Fig 7.15: Company Product Upload   Fig 7.16: Company View Uploaded Products   Fig 7.17: View Products     Fig 7.18: Bid History     Fig 7.19: Place Bid   Fig 7.20: Minimum Bid     Fig 7.21: Make Donation   Fig 7.21: Company Update Profile  

8. ­LIMITATIONS AND FUTURE ENHANCEMENT

 

2.         LIMITATIONS

 

• Main limitation of this system is it works primarily on the internet so if somewhere active internet connection is not available user will not be able to use the system.

• Another limitation of this system is illiterate people can’t reach to us directly if NGO is not available in their area.

• Identifying poor people based on document could be tricky.

• To confirm bid admin need to analyze the data which could be a slower task.

 

3.         FUTURE ENHANCEMENT

• In future we will provide such facility so that poor or illiterate peoples can reach to us directly with a phone call.

• Our employee which reach to poor/illiterate people to verify the details and after verifying they will get the product.
• In future we will try to collaborate with Government to reach to the maximum numbers of people we can in our country.

9. ­CONCLUSION

The Asset Auction System(AAS) is a web application that can be used by many like companies, NGOs, Organizations, Standalone User etc. The main objectives of this system is human welfare and recycling of old asset. In this system various companies can sell their old products such as computers to us. We will try to coordinate with NGOs and NGO will bid on products uploaded by the companies and user. Those products will go for further refinement if needed and then it will be given to the poor and illiterate peoples. Form above we can conclude that this system could help those poor and illiterate people in our country those who are not aware about computers and technologies due some factors. By providing them computers they will able to learn and explore the world or technology so that countries literacy rate can be gained.