Sunteți pe pagina 1din 14

Gift Registry Portal

PROJECT CHARTER
_____________________________________________________________________________

Table of Contents

Executive Summary ……………………………………………………………………..


Project Objectives ……………………………………………………………………….
Project Scope ……………………………………………………………………………
Assumptions …………………………………………………………………………….
Dependencies and Constraints …………………………………………………………
Risk Analysis ……………………………………………………………………………..
Completeness Criteria …………………………………………………………………….
Quality Assurance Requirements …………………………………………………………
Procurement Requirements ……………………………………………………………….
Proposed team, roles and responsibility …………………………………………………..
Deliverables and Major Milestone
Estimated Operational and Capital Charges ………………………………………………
Implementation Strategy …………………………………………………………………...
Project Management ………………………………………………………………………

2
_____________________________________________________________________________

Executive Summary

The document provides major information about the project development in the frame of the
PRJ845 course.

ECommerce application “Gift Registry Portal” is taken as the example of the project. The project
is divided into mini-projects each of which is assigned to the team of 3 students.
Each mini-project allows full cycle of project development and project management.

Expected results:
- Skills in the computer system design using UML
- Skills in object-oriented design basing on MVC paradigm
- Skills in software development (pseudo – code) and documentation
- Skills in software testing planning
- Skills in the computer system architecture development
- Skills in Project Management
- Skills in team work organization

Project Objective

Design and development and implementation solutions of eCommerce application Gift


Registry Portal (GRP). Design and implementation solutions are to be presented as Rational
Rose Diagrams. Development is to be done on pseudo code. Project technical and
management documentation is to follow PMI recommendations.

GRP is defined as an online portal to serve big events when a recipient expects a lot of guests
and gifts, like for example a wedding event. The event’s Recipient creates the list of desirable
gifts basing on Retailers’ proposals of products. Wish list may be composed from the
products delivered by different Retailers. This list is available online for his guests
(Customers) to view, to make the order and finally to buy or to cancel. Created Order is to be
sent to the Retailer respectively to confirm or to reject it. Evidently, a few orders may be
created to cover a given wish list. For the confirmed order GRP produces Invoice and sends
it by e-mail to a Customer.

There is also a possibility to operate with prepackaged gift basket as an alternative to wish
list. This option is available to a customer directly, with no connection to wish list.
Prepackaged basket has been provided by a single retailer, it can be ordered and paid after
confirmation.

GRP provide payment option by credit card for both Recipient and Customer. Recipient is to
pay fee for the wish list service. Customer pays for the order in accordance to the invoice.

GRP acts as a single contact point between Recipient, Customer and Retailer in respect to all
the operations except shipping. Shipping is arranged by Retailer directly to the address
provided.

3
_____________________________________________________________________________

Note: The project development major goal is learning the project management and
implementation technique, not the implementation of commercial version of GRP. That’s
why not all the functions will be taken for the development, and not all the aspects are
presented respectively to the real life situation.

Project Scope
In scope

The following groups of functions are included into the project:


 End User’s account creating and login to the system
 Retailer’s Interface including
a. Registration and obtaining Price List ID.
b. Creating pre-packaged baskets.
c. Retailer’s Discount and PO confirmation.
d. Online support of price lists.
 Recipient Interface
a. Recipient’s Subscription for service
b. Recipient’s Wishes List Creating based on the catalog
c. “Thank you letter” sending facility.
 Customer Interface
a. Customer’s Registration
b. Customer’s PO based on Recipient’s wish list
c. Customer’s PO for a pre-packaged basket
 GRP Admin interface
a. Invoice creating facility to provide payment and Registry Status Update. GRP
supports ongoing state of the ‘Wishes List” automatically.
b. Support tables online maintenance. The list of tables contains
i. Catalogue
ii. Event type
iii. Category

Out of scope

Following groups of functions are out of scope:


1. Credit Card validation
2. Products Inventory
3. Accounting
4. Products Shipping
5. Price Lists initial loading
6. Initial creating of the catalog
7. Archiving and garbage gathering

4
_____________________________________________________________________________

Brief description of the function groups is provided in the table below:

Group Functions Group Description


Li
ne
#
Main End User’s account creating and Any end user starts with login to the system. The
login to the system first time there will be a user’s ID created
automatically and password created by the user.
User’s account record is stored in the table
CREDENTIALS.
Every next login there will be a form based
authentication implemented. End user must
provide correct ID and password to get allowed
to the system. He is allowed to make up to 5
attempts after what the user’s account shall be
blocked if all the attempts failed
Retailer’s Interface
1 Registration and obtaining Price New Retailer
List ID From GUI Retailer fill in his profile information
which will be stored in RDB. Then they are
looking through the Category table to select the
category of products they are going to offer. For
each selected category the application organizes
the match Retailer – Category and generates
Price List ID, that later will be used to populate
Price List table.
Existing Retailer can change the profile (except
Retailer_ID) and add more categories and price
lists to his operations
2 Retailer makes prepackaged Prepackaged baskets have been offered for some
basket particular types of event, for example a “new
baby” event, or St. Patrick Day. Retailer selects
the event and then, looking through price lists of
him selects the products to be included. Total
price has been calculated for him. Retailer can
change the selection as long as the confirmation
has not happened. After confirmation, the basket
content has been stored in RDB
3 Retailer provides Discount, and From GUI Retailer can give a discount for some
PO confirmation for the selected event for a specified period of time. As well he is
collection of items to review Purchase Orders made on the basis of a
wish list, and to confirm or to decline each item
ordered
4 Online support of price lists After being loaded and stored in RDB, price lists

5
_____________________________________________________________________________
can be updated online. The following operations
are allowed:
- Add new records.
- Delete records.
- Change the product price in existing records.
Recipient Interface
5 Recipient’s Subscription for New Recipient
service He is to submit his personal information, credit
card data and the expected event type and date.
Registry record is created. Fixed service fee is
paid once credit card validation is successful. If
not, he will be asked to submit other credit card
data. It might happen the registration activity
will be interrupted before payment.
Existing Recipient
May continue with payment by credit card, or
with updating personal information (except
Recipient_ID) or credit card data.
6 Recipient Wish List Creating After successful subscription, Recipient gets the
right to create his Wish List for a particular
event. To do this he is searching through the
catalog to select the products he wishes to get.
After confirmation, the selection of products is
stored into Wish List.
For more convenience the products in the catalog
are organized by the categories giving the ability
to see firstly the list of categories, to select one,
and then to browse through the list of products.
7 “Thank you letter” sending Recipient reviews his wish list to identify the
items ordered. The list also contains indication if
the letter has been sent already. Information
about respective customers is displayed for
review. He confirms his desire to send “Thank
You” letter. The letter is created and sent
automatically. The database records are marked
and stored.
Customer Interface
8 Customer’s Registration Assumption: a Customer was provided with the
Recipient’s Registry ID before she starts working
with the system.
From GUI a Customer makes her subscription
for online purchasing. Before to fill in the form
she has the ability to make sure that this is the
right place. Using Recipient ID she may find out
that such event is really registered. Then she is to
submit her personal information and provide the

6
_____________________________________________________________________________
way of payment (credit card or check payment).
For credit card – to obtain and validate data.
Facilities to update personal information and
credit card data also should be provided.
9 Buying prepackaged basket Customer indicates she wants to view the baskets
for a given event. The list of baskets with
detailed content has been shown to her. If there is
a discount announced for this type of event at the
time of purchasing, discounted price also will be
calculated and shown to the customer. Customer
selects the basket and requests for payment by
credit card. If the payment transaction is
successful, the record has been created, stored in
RDB and sent to the customer by email.
10 Customer’s Purchase Order for The first thing to start with PO is to submit the
the wish list items Registry ID from GUI. Then a Customer reviews
the Wish List and decides about the Retailer to
buy from. Narrowed Price List from a specified
Retailer appears with the information about
current prices and discounts. Customer makes
the final selection and Purchase Order is created.
Relevant records are stored in the database tables
GRP Owner Interface
11 Invoice creating and sending to Periodically, for example at the end of every
the Customer by eMail business day, from GRP Business Owner’s GUI
to look through the list Purchase Orders to find
out those that have not been confirmed yet. This
may be determined by the value of the flag
indicating that Invoice is not sent. Find out if the
purchase order items are confirmed by Retailer
and create Invoices for confirmed items. Email
Invoice to the Customer. Wishes status in the
table STATUS is to be installed as “ordered” and
“ITEM_NEEDED” value in the table WISHES is
updated to: (QTY_NEEDED = Current –
Ordered).
View Invoice history activity

12 GRP Owner’s Facilities to GRP Owner is provided with the facilities to


maintain support tables maintain online the following tables:
 Event type
 Category
 Catalog
For each table all 3 major functions should be
available (view, insert, delete)

7
_____________________________________________________________________________

Assumptions

GRP business owner is expected to provide all necessary infrastructure components to support
the project development, such as Database Management Server, Rational Rose Enterprise
Edition, MS Office tools, computer system equipment.

The development is based on the assumption that the implementation infrastructure allows up to
date technology for eCommerce application and includes all necessary components to implement
online payment system, database support, batch procedures for Electronic Document Exchange,
suitable volume of bandwidth and other applicable components.

All the expenses needed to arrange the GRP implementation including any specific payments for
Internet presence (Merchant Account, DNS registration etc.) are the owner’s responsibility.

The business owner assigns a Product Manager to present the business requirements to the
development team.

Relational Database design is provided by the Product Manager.

There is no requirement to provide a single GUI solution for the whole project. Each team
considers the assigned mini-project as self sufficient from the development standpoint.
Each mini-project does use the common database design solution.

Mini-Projects

Mini- Title Groups of functions included


project ID
1 Retailer Interface: Retailer Registration and obtaining Price List ID.
registration
2 Retailer Interface: Online Retailer makes prepackaged baskets.
support of sales
3 Retailer Interface: Online Retailer provides Discount and PO confirmation.
support of sales
4 Retailer Interface: Online Online price lists support.
support of price lists
5 Recipient Interface: Recipient’s Subscription for service.
Recipient’s Subscription for
service
6 Recipient Interface: Wish list Recipient Wish List Creating
7 Customer Interface: Buy a Buying prepackaged baskets
basket
8 Customer Interface: Purchase Customer’s PO for the wish list items.
Order
9 GRP Owner Interface: Invoice creating and sending to the Customer by

8
_____________________________________________________________________________
Invoice eMail

Note to mini-projects scope

User’s login activity must not be included. The assumption is that a user has been
authenticated and authorized before a mini-project starts. The mini-project functionality
starts from business functional main menu.

9
_____________________________________________________________________________

Dependencies and Constraints

 Computer equipment and development tools are available no later than January 16.
 Computer system is supported by the business owner personnel. The system availability
is not less than 80% of time allotted to the project development.
 Each development team does its work and brings the result in time.
 The project must be completed by the April, 2007.

Risk Analysis

Risk Description Ways of Mitigation


Some team member’s skills may be not Each team member will be doing his/her own
sufficient to provide the expected result and the development and provide his/her solution.
overall team result may be affected Personal results shall not be affected
System availability may be not sufficient to The solution may be presented in written
provide development in time basing on UML methodology

Completeness Criteria

The project is completed when the major goal is achieved. Each student should submit the
documents related to the mini-project he/she is involved. The documents are listed in the section
Deliverables below.

Quality Assurance Requirements

Technical solutions are to be documented and tested. Testing Plan must be developed to provide
testing.

Project documentation must be developed accordingly to the project standards using document
templates.

Procurement Requirements
N/A

Proposed Team, Roles and Responsibility

Staffing requirements table is below:

Role Name/TBD Responsibility Skills


required *)
Product Manager T.O. Provide business requirements

10
_____________________________________________________________________________
and specification
Project Manager TBD for each Organize team meeting(s)
mini-project,
rotated
Technical Leader TBD for each Present alternatives for technical
mini-project, solutions
rotated
Developers TBD for each Development and discussion
mini-project,
rotated

Note: to achieve the major project goal all the roles are rotated among students, except Product
Manager’s role

11
_____________________________________________________________________________

Deliverables and Major Milestones

Stage/ Subject Deliverable Document presented Presented Percent Responsible


ID for evaluation for of Total for delivery
(Tools) evaluation
at week #
Project Definition PD1 Project Charter – Project 4, 5 Technical
and Planning Scope section (MS Word) Leader A

Technical Functional and Non-


Requirements Functional Requirements
(MS Word)
Mock-up screens draft

Project Executing PE2 Use Case Diagram (Rational 6, 10 Technical


– High level Rose) Leader B
design Activity Diagram (Rational
Rose)

Project Executing PE3 Mock-up screens 10, 10 Technical


– High level Complete Sequence Diagram Leader C
design Complete Class Diagram
(Rational Rose)

Project Executing PE4 Components Diagram 11, 15 Personal


– Development (Rational Rose)
Java Source Code Generated
by Rose
Pseudo code to implement
MVC

Project Executing PE5 Testing Plan including Test 12, 10 Personal


– Testing Cases – MS Word

Note about responsibility

Work on a deliverable can be split among team members, however Responsible for the delivery
Technical Leader must collect the results and integrate them into a single item. This relates
specifically to Rational Rose model that must be a single item for the whole mini-project.

Estimated Operating and Capital Charges

N/A

12
_____________________________________________________________________________
Implementation Strategy

The strategy is to divide the project into a few mini-projects of a comparable size. Each mini-
project is to comprise all the tiers of multi-tiered architecture to give the most complete
experience. Personal work is concentrated around mini-project design and development.

Team work experience is obtained through the team deliverables and project team meetings. Role
rotating allows to each student to try himself and to learn the ways of presentation for:
- Planning information – Project Manager role
- Technical information – Technical Leader role

Practical skills are obtained through mini-projects design using UML and development on
pseudo-code. The most important thing is not the completed development but learning the
methods, alternatives and ways of problems resolution.
All the mini-projects are under development in parallel.

Project Management Plan

Communication Management

Communication Plan

Audience Content Medium for Frequency/ Communication Who is


Delivery Timing Deliverables responsible
Development Current Team Weekly Meeting agenda Project
Team development meetings and minutes. Manager
state Issues log.
Decisions log.

Project Resource Project Bi-weekly Project Project


Sponsor spending monitoring monitoring Manager
Project meeting report
development
progressing
Information Security Electronic As scheduled Project Technical
security requirements documents documents leader
department implementation

Risk Management Plan

Risks and ways of mitigating are described in the section above. Any other risks should be
escalated to the Product Manager

Issue Management

13
_____________________________________________________________________________

Issues must be escalated at the project team meeting and recorded into Issue Log. Major
decisions are to be recorded into Decision Log

Change Management

N/A

14

S-ar putea să vă placă și