Assets Auction System (AAS) for Computer Illiteracy

12626 words (51 pages) Dissertation

16th Dec 2019 Dissertation Reference this

Tags: Computing

Disclaimer: This work has been submitted by a student. This is not an example of the work produced by our Dissertation Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NursingAnswers.net.

  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.
  1.          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.
  1.          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.
  1.          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.
  1. 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.
  1. Technicians
  • Technician can view the request generated by the admin.
  • Technician can submit report for generated request.
  • Technician can modify request contents.
  1. 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.
  1. 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.
 
  1. 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.
  1.          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
  1.            Client Side:
Processor : 1.80 GHz or high Ram  : 1 GB Hard Disk : 4 GB of Available Space
  1.      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
  1.            Client Side:
Operating System : Windows XP or later, Linux, Mac Browser  : Internet Explorer, Mozilla Firefox,                              Google chrome or any equivalent
  1.          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
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1.          Timeline Chart and Process model
    1.      Timeline Chart
  F:\Study\College Study\BE\8th SEM\Report\diagrams\Time line chart1.jpg   Fig 2.4.1: Timeline Chart  
  1.      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.
C:\Users\nirav\Downloads\333px-Spiral_model_(Boehm,_1988).svg.png  
  • 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.
  1. 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.
  1.  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.
  1. 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.
  1.   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.
  1.   Functions of System
  3.6.1 Use Cases for Admin     F:\Study\College Study\BE\7th SEM\Project\Diagrams\Usecase\Admin.jpg       Fig 3.6.1: Use case for Admin   3.6.2 Use Cases for Company     F:\Study\College Study\BE\7th SEM\Project\Diagrams\Usecase\Company.jpg     Fig 3.6.2: Use case for Company   3.6.3 Use Cases for NGO     F:\Study\College Study\BE\7th SEM\Project\Diagrams\Usecase\NGO.jpg     Fig 3.6.3: Use case for NGO   3.6.4 Use Cases for Technician     C:\Users\Nirav Shah\Desktop\techinican.png   Fig 3.6.4: Use case for Technician 3.6.5 Use Cases for End User     F:\Study\College Study\BE\7th SEM\Project\Diagrams\Usecase\consumer.jpg   Fig 3.6.5: Use case for End User   3.6.6 Use Cases for Admin and Company     F:\Study\College Study\BE\7th SEM\Project\Diagrams\Usecase\ADMIN & COMPANY.jpg     Fig 3.6.6: Use case for Admin and Company 3.6.7 Use Cases for NGO and Company     F:\Study\College Study\BE\7th SEM\Project\Diagrams\Usecase\NGO & Company.jpg     Fig 3.6.7: Use case for NGO and Company
  1.   Data Modeling
  3.7.1 E-R Diagram   F:\Study\College Study\BE\7th SEM\Project\Diagrams\Various\ER.jpg   Fig 3.7.1: E-R Diagram 3.7.2 Class Diagram   F:\Study\College Study\BE\7th SEM\Project\Diagrams\Various\classdiagrame.jpg   Fig 3.7.2: Class Diagram   3.7.3 System Activity   F:\Study\College Study\BE\7th SEM\Project\Diagrams\activity diagrams\Activity1.jpg Fig 3.7.3.1: Bidding Activity F:\Study\College Study\BE\7th SEM\Project\Diagrams\activity diagrams\swimelane.jpg 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  
  1. 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
  1. 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  
  1. 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  
  1. 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      
  1. 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  
  1.  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
  1.   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  
  1.  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      
  1.  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  
  1.  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            
  1. 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
  1. 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  
  1.  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
  1.  Control Flow Diagram
  F:\Study\College Study\BE\8th SEM\Report\diagrams\flow.jpg   Fig 3.8: Control Flow
  1.  Main Modules of new System
 
  • Admin Module
  • Technician Module
  • Company Module
  • NGO Module
  • End User Module
  • Product Module
  • Payment Module
 
  1. SYSTEM DESIGN
 
  1.         Data Structure Design
 
  1.   Table & Relationship
  F:\Study\College Study\BE\7th SEM\Project\Diagrams\Various\table and relation.jpg   Fig 4.1.1: Table and Relationship
  1.         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. F:\Study\College Study\BE\8th SEM\Report\diagrams\PNYHA.png 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.
  1.         Input/output and Interface Design
 
  1.   State Transition Diagram
  F:\Study\College Study\BE\7th SEM\Project\Diagrams\State_Registration.jpg     Fig 4.3.1.1: State Transition for Registration   F:\Study\College Study\BE\7th SEM\Project\Diagrams\State_NGO.jpg    Fig 4.3.1.2: State Transition for Bidding F:\Study\College Study\BE\7th SEM\Project\Diagrams\State_Company.jpg   Fig 4.3.1.3: State Transition for Product Upload
  1.   Sequence Diagram
  F:\Study\College Study\BE\7th SEM\Project\Diagrams\sequance diagrams\sequance1.jpg   Fig 4.3.2.1: Sequence Diagram for Admin Activity   F:\Study\College Study\BE\7th SEM\Project\Diagrams\sequance diagrams\sequance3.jpg     Fig 4.3.2.2: Sequence Diagram for NGO Activity F:\Study\College Study\BE\7th SEM\Project\Diagrams\sequance diagrams\sequance2.jpg   Fig 4.3.2.3: Sequence Diagram for Company Activity F:\Study\College Study\BE\7th SEM\Project\Diagrams\sequance diagrams\SEQ_NGOComp.vsdx.jpg     Fig 4.3.2.4: Sequence Diagram for Combine Operation System, Company &NGO  
5. IMPLEMENTATION & PLANNING AND DETAILS
  1.         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
  1.          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.
    1.          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.
  1.          CODING STANDARDS
Checks for Normal Working ToBeChecked?
  1. Does your system save correct data in database?
*
  1. In update does your screen load correct data?
*
  1. Fields are showing the data in correct format?
*
  1. Data
*
  1. Integer
*
  1. String
*
  1. Will your screen generate notification and stop if wrong data type is entered?
*
  1. Does your system work flow is correct?
*
  Table 5.1: Coding Standards
Basic Validations  
  1. Validation for Required field is done?
*
  1. Validation for Integer, String, Date, Time is done?
*
  1. Type Check / Type Safety
*
  1. Boundary Value Analysis (for highest order value and lowest order value)
*
  1. Date Format
*
  Table 5.2: Coding Standards  
  1.          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
  1. ­TESTING
 
  1.         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.
  1.         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).
  1.          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.
  1.          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
  1. 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
  1. 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
  1. 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
  1. ­SCREENSHOTS
  H:\home.jpg   Fig 7.1: Home Page   H:\login1.jpg   Fig 7.2: Login Page F:\Study\College Study\BE\8th SEM\Report\screenshots\registraion with filled data.png   Fig 7.3: Registration From F:\Study\College Study\BE\8th SEM\Report\screenshots\registration success.png   Fig 7.4: Registration Success F:\Study\College Study\BE\8th SEM\Report\screenshots\admin login.png   Fig 7.5: Staff Login     C:\Users\Nirav Shah\Desktop\Admin Dashboard.png   Fig 7.6: Admin Dashboard F:\Study\College Study\BE\8th SEM\Report\screenshots\add city.png   Fig 7.7: Admin Add City   F:\Study\College Study\BE\8th SEM\Report\screenshots\city added.png   Fig 7.8: City List F:\Study\College Study\BE\8th SEM\Report\screenshots\add state.png   Fig 7.9: Admin Add State   F:\Study\College Study\BE\8th SEM\Report\screenshots\state added.png   Fig 7.10: Admin State List F:\Study\College Study\BE\8th SEM\Report\screenshots\admin add user fill.png   Fig 7.11: Admin Add User   F:\Study\College Study\BE\8th SEM\Report\screenshots\admin add user.png   Fig 7.12: Admin User List   F:\Study\College Study\BE\8th SEM\Report\screenshots\add cpu.png   Fig 7.13: Admin Add CPU     F:\Study\College Study\BE\8th SEM\Report\screenshots\cpu added.png   Fig 7.14: Admin CPU List       F:\Study\College Study\BE\8th SEM\Report\screenshots\Asset_Auction_uploaded.jpg   Fig 7.15: Company Product Upload F:\Study\College Study\BE\8th SEM\Report\screenshots\Asset_Auction_showProduct.jpg   Fig 7.16: Company View Uploaded Products F:\Study\College Study\BE\8th SEM\Report\screenshots\Asset_Auction_-_Home_product.jpg   Fig 7.17: View Products   F:\Study\College Study\BE\8th SEM\Report\screenshots\Asset_Auction_-_Refurbished_Sell_-bid again.jpg   Fig 7.18: Bid History   F:\Study\College Study\BE\8th SEM\Report\screenshots\Asset_Auction_bid.jpg   Fig 7.19: Place Bid F:\Study\College Study\BE\8th SEM\Report\screenshots\Asset_Auction_1.jpg   Fig 7.20: Minimum Bid   H:\donateonline.jpg   Fig 7.21: Make Donation H:\editProfile.jpg.png   Fig 7.21: Company Update Profile  
  1. ­LIMITATIONS AND FUTURE ENHANCEMENT
 
  1.         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.
 
  1.         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.
  1. ­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.

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this dissertation and no longer wish to have your work published on the UKDiss.com website then please: