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
Line #
Main
1
Functions Group
Description
End User’s account creating and
login to the system
Any end user starts with login to the system. The
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
Registration and obtaining Price
List ID
2
Retailer makes prepackaged
basket
3
Retailer provides Discount, and
PO confirmation for the selected
collection of items
4
Online support of price lists
New Retailer
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
Prepackaged baskets have been offered for some
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
From GUI Retailer can give a discount for some
event for a specified period of time. As well he is
to review Purchase Orders made on the basis of a
wish list, and to confirm or to decline each item
ordered
After being loaded and stored in RDB, price lists
can be updated online. The following operations
are allowed:
5
_____________________________________________________________________________
- 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
way of payment (credit card or check payment).
For credit card – to obtain and validate data.
6
_____________________________________________________________________________
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
maintain support tables
GRP Owner is provided with the facilities to
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
Miniproject ID
1
2
3
4
5
6
7
8
9
Title
Groups of functions included
Retailer Interface: Retailer
registration
Retailer Interface: Online
support of sales
Retailer Interface: Online
support of sales
Retailer Interface: Online
support of price lists
Recipient Interface:
Recipient’s Subscription for
service
Recipient Interface: Wish list
Customer Interface: Buy a
basket
Customer Interface: Purchase
Order
GRP Owner Interface:
Invoice
Registration and obtaining Price List ID.
Retailer makes prepackaged baskets.
Retailer provides Discount and PO confirmation.
Online price lists support.
Recipient’s Subscription for service.
Recipient Wish List Creating
Buying prepackaged baskets
Customer’s PO for the wish list items.
Invoice creating and sending to the Customer by
eMail
8
_____________________________________________________________________________
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
Some team member’s skills may be not
sufficient to provide the expected result and the
overall team result may be affected
System availability may be not sufficient to
provide development in time
Ways of Mitigation
Each team member will be doing his/her own
development and provide his/her solution.
Personal results shall not be affected
The solution may be presented in written
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
Product Manager
T.O.
Provide business requirements
Skills
required *)
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
ID
for evaluation
(Tools)
Project Definition
and Planning
PD1
Technical
Requirements
Project Charter – Project
Scope section (MS Word)
Presented
for
evaluation
at week #
Percent Responsible
of
for delivery
Total
4,
5
Technical
Leader A
Functional and NonFunctional Requirements
(MS Word)
Mock-up screens draft
Project Executing
– High level
design
PE2
Use Case Diagram (Rational
Rose)
Activity Diagram (Rational
Rose)
6,
10
Technical
Leader B
Project Executing
– High level
design
PE3
Mock-up screens
Complete Sequence Diagram
Complete Class Diagram
(Rational Rose)
10,
10
Technical
Leader C
Project Executing
– Development
PE4
Components Diagram
(Rational Rose)
Java Source Code Generated
by Rose
Pseudo code to implement
MVC
11,
15
Personal
Project Executing
– Testing
PE5
Testing Plan including Test
Cases – MS Word
12,
10
Personal
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 miniproject 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
Delivery
Frequency/
Timing
Communication
Deliverables
Development
Team
Current
development
state
Team
meetings
Weekly
Meeting agenda Project
and minutes.
Manager
Issues log.
Decisions log.
Project
Sponsor
Resource
spending
Project
development
progressing
Security
requirements
implementation
Project
Bi-weekly
monitoring
meeting
Project
monitoring
report
Project
Manager
Electronic
documents
Project
documents
Technical
leader
Information
security
department
As scheduled
Who is
responsible
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