The document outlines the project plan for an online shopping portal, detailing objectives, requirements for customers, vendors, and administrators, as well as deliverables and potential risks. It emphasizes a user-friendly web application with secure payment options, vendor management, and customer interaction features. The project team structure, success factors, and quality assurance measures are also highlighted to ensure effective development and operation.

1. ONLINE SHOPPING PORTAL
Project Plan
Team Members
Piyushree (29036)
Ranjani (29041)
Sivaraj Kumar (29053)
Akankshya Agarwal (29062)
Anandavel S (29122)

2. Statement of Work
Project Title - Online Shopping Portal
Objective - To develop a web application that allows a registered customer to purchase a
variety of products sold online by a list of registered vendors from any
location.
- To provide an easy to use Interface.
Basic Requirements
Customer – Secured registering and managing their profiles.
- Easy navigation through pages.
- Secured Payment gateway.
Vendors - Secured registering and managing their profiles.
- Add, delete or modify the already posted items.
Administrator - Authority to approve and reject requests for new items.
- Can control customer and Vendors actions.
Deliverables
- Web Portal/Application for desktop and mobile environment.
- Support Manual also detailing the risks involved. (If any)

3. Statement of Work (Contd..)
• Benefits
- Convenient Shopping.
- Single Window, Multi-Vendor Retailing.
- Selection option from different vendors offering the same product at different
prices.
- Search and sort options for a given product.
- Discussion and Review forum for each product for price negotiations.
- Simple, easy and secured payment option.
- Auto fill of Customer data required to be entered during each payment.
- Complaint Registration and support.
- The customer can download the PDF version of the manual provided the
vendor has uploaded it.
- List of recommended products are displayed to the customer.
- Detailed Sales Reporting (vendor analysis, customer analysis, keeping the
vendor and customer analysis)

4. Project Scope
Scope – In
• Websites for desktop, which is compatible with IE, Mozilla, Chrome etc.
• Purchase items available in the website.
Scope – Out
• Payment Gateways to be linked through APIs.
• Not compatible for mobile users.
Users – Customers, Sellers, Administrator

5. Critical Success Factors (CSF)
• Maintaining Backup System
• Terminating the transaction, if linkage to payment gateway is failed.
• Customer and Products information are stored in a Secured Database.
Key Performance Indicators (KPI)
• Handling maximum traffic at any point of time.
• Less number of Clicks, the customer has to perform and less number of pages to reach their desired
item and navigation between pages should be easier.

6. Architecture & Design Pattern
MVC
3 – Tier Architecture

7. Product Function Diagram
Account Setting Customer

8. Product Function Diagram (Contd..)
Vendors Admin

9. Database Details
• Customer
• Vendor
• Admin
• Inventory
• Shopping Cart
• Order Details
• Transactions
• Review
• Order Transaction
• Purchase History
• Credit Card
• Complaints

10. Team Structure
Project
Manager
Technical
Architect
Team Lead 1 Team Lead 2
Developer 4
Developer 1
Developer 2
Developer 3
Developer 5
Developer 6
Developer 8
Developer 7
Testing
Manager
Team Lead 1
Team Lead 1
Team Lead 1
Test Lead

11. Risks Involved
• Product Size Risks
- Estimated size of product in number of programs, files, transactions.
- Size of database created or used by the product.
- Number of projected changes to the requirements for the product.
Before delivery & After delivery.
• Business Risks
- Amount and quality of product documentation that must be produced and delivered to
the customer.
- Delivery deadlines.
- Costs associated with late delivery and defective product.
• Client Risks
- When working for the first time.
- Will the customer agree to spend time in formal requirements gathering meetings to
identify project scope.
- Communicating with developers.
- Understanding of the SDLC process.

12. Risks Involved (Contd..)
• Resource Risks
- Number of Resources and skillsets.
- Commitment for entire duration.
• Technology Risks
- Customer demanding new technology
- Requirements put excessive performance constraints on the product.

13. Possible Origins of Change
• New business or market conditions
• Customer demand
• Budgetary or scheduling constraints

14. CHANGE CONTROL PROCESS

15. CHANGE REQUEST FORM
• Project name
• Project sponsor
• Request number
• Date
• Originator
• Change requested by
• Description of requested changes
• Reason for change
• Areas of impact of proposed change( scope/ cost/ schedule/ risk)
• Disposition ( approved/ disproved/ deferred)
• Priority( emergency/ urgent/ low)
• Funding scheme ( mgmt reserve, budget reserve, others)
• Sign off approvals ( project manager, pjct customer, pjct sponsor, other, dates )

16. QUALITY PLAN
• Our quality plan’s effectiveness will be measured by the following
parameters:
• Ease of use of the web portal
• Customer satisfaction regarding the service
• Click-sales conversion
• Website response time
• Customer service in relation to complaints addressal
• Customer service time
• No. of clicks to find the required product
• Security of personal data.

17. PRINCIPAL PRODUCT QUALITY FACTORS
PRODUCT
QUALITY
TECHNOLOGY
•Latest versions
& as per
requirements
PEOPLE QUALITY
•Hands on
experience+
qualifications+
division of work
as per skills
BUDGET &
SCHEDULE
•No cost
overruns,
achieving
milestones,
WBS
PROCESS QUALITY
•SDLC method
used, resource
allocated, quality
& change
management

18. PRODUCT QUALITY ATTRIBUTES
• Have lowest possible response time
• Not make wasteful use of system resources- disk/ memory space/ CPU time
• Easy to use by the users( customers/ admins/ vendors)
• Ability to recover after a crash, slowdown, malware threats, unresponsive
and unforeseen events and errors.
• Trustworthy software sources
• Ease of maintenance
• Evolve to meet changing needs of customers
• Reliability ( same output every time for the similar kind of input)
• Availability even in situations of high traffic
• Codes can be reused- customers function developed and customized for
vendor as well

19. Quality Assurance Elements
• Standards – adherence to ISO, six sigma, CMMI and other standards
• Reviews and audits – quality guidelines followed for all steps of the
software development
• Testing – should not enter without login, search results match the request
• Error/defect collection and analysis – determine source of error
• Changes management
• Vendor management – vendors quality should match our requirements
related to software and process
• Security management –malware, hacking, customer info privacy
• Risk management – established contingency plans for risk management

20. 3rd PARTY ENGAGEMENT
• Payment gateway
• Technology vendors
• Customer service