SPMP_Chocoholics Anonymousx

handslustyInternet και Εφαρμογές Web

14 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

1.332 εμφανίσεις

Chocoholics Anonymous (ChocAn) Software Project Management Plan (SPMP)


1.


Introduction

a.

Project Overview

b.

Project Deliverables

2.

Project Organization

a.

Process Model

b.

Organizational Structure

c.

Organizational Boundaries and Interfaces

d.

Project Responsibilities

3.

Managerial Process

a.

Management Objectives and Priorities

b.

Monitoring and Controlling Mechanisms

c.

Staffing Plan

4.

Technical Process

a.

Methods, Tools, and Techniques

b.

Software Documentation

5.

Requirements

6.

Responsibilities

7.

Additional Components

a.

Database model

b.

Class
Diagram

c.

Financial Use cases

d.

Members Use cases
















Revision Chart

This chart contains a history of this document’s revisions.

Version

Primary Author(s)

Description of Version

Date Completed

Draft

Matthew Hoover,

Justin Bass,


Chantal Fry,

George

Fang,


Joseph Wang

Initial draft created for distribution and review comments.
Included group responsibilities as well as a database
model.

10/06/2012

Draft

Chantal Fry

Updated requirements for financial, updated group
members for financial, added
financial use case diagram
and descriptions.

10/30/2012

Preface

The Software Project Management Plan is a guide to the implementation of the ChocAn Company.

This
document serves as a reference for all groups to follow and holds the schedule that everyone

must adhere to.

1.0 Introduction

a) Project Overview

ChocAn is going to revolutionize how the medical world handles chocolate addiction. There was Alcoholics An,
Gamblers An and now there is ChocAn. Our company will bring together the best of nutritionist
, exercise
experts and
dietic
ians to help anyone break the habit and become health
.

b)

Project Deliverables

Group Roles and Database layout, 10/06
/2012

Class Model, 10/13/2012

2.0 Project Organization

a)

Process Model

Group Roles and Database
layout,

10/06

An implementation and role assignments finalized. This document should be mostly complete.

b)

Organizational Structure

Chief Executive officer



The owner of the company (The professor)

Executive Vice President

In charge of manages all the grou
p leads and the server hardware and reporting to the CEO.

Group lead:

Acts as the contacts for all the group members

Group Members:



All programmers, database and front end UI coding.

c)

Organizational Boundaries and Interfaces

The group leads
are responsible for assigning group direction as well as documentation compilation. The can
also help code.


d)

Project Responsibilities

Primary Roles

Members


Lucia Diaz

Providers


Joseph Wang

Administration


George Fang

Financial


Chantal Fry

Web
UI


Matthew Hoover

Reports


Justin Bass


Secondary Roles

Members Module

Sergio Lopez, Raisa Cuevas

Provider Module

James Pham, Jian Zhang

Administration

Omar Munoz
,
Jing Qin

Financial

Raymund
Ramos

Interface Module

Kevin Moslehpour, Carolyn Ngo

Report


Dang Le, Jessica

Szeto

3
.0 Managerial Process

a)

Management Objectives and Priorities

It is the
job of the group leads to always motivate creative and quality construction of all code. Their goal is also
to hold a strict
deadline

over the amount time that is deviating from schedule. Team meetings will be held
more frequently if the time
tables fall

behind.

All tasks are expected to be ready upon the

stated

completion
date.

As a general
note
, an agenda
stating progress
will be
prepared
prior to each team meeting to be used as a
guide for discussion.

b)
Monitoring and Controlling Mechanisms

Team meetings will be held
weekly if

the time table of
deliverable’s

is held to which will be managed via Google
docs. It will be held weekly

if members fall behind on completing deliverables on time. Any failure to appear at
an agreed upon meeting will result in a notification to the CEO.

c)

Staffing Plan

This project will be completed by 6 groups, each with 1
-
3 people per group. All responsib
ilities will be handled
via the group lead that will partition the work accordingly. This may include learning JS, SQL, etc.

4.0 Technical Process

a)

Methods, Tools, and Techniques

The team

will be using:

Tomcat 5 web server

MySQL database

Java

Sencha (Ext

Js)

b)

Software Documentation

UML will be produced: TBD

5.0 Requirements

a)
Overall Requirements

1.

Monthly service fee for a member to chocA company

2.

Provider types

a.

Dieticians

b.

Nutritionists

c.

Exercise

3.

Member has 9 digit ID #

4.

Check if member is
suspended/invalid

5.

Provider when rendering a service

a.

9 digit #

b.

Member treated

c.

Service code (6 digit) (array of service codes)

d.

Comments

e.

Date

6.

End of each week: Total fees by provider to verify payment

7.

End of each week: members gets a list of services rendered

a.

Name

b.

Number

c.

Address

d.

City

e.

State

f.

Zip

g.

Service

i.

Date

ii.

Provider

iii.

Service name

8.

Emails to providers

a.

Name

b.

Number

c.

Street

d.

State

e.

Zip

f.

City

g.

Service Provided

i.

Date

ii.

Member Name

iii.

Member #

iv.

Service code

v.

Fee paid

vi.

# consolations

9.

Report EFT

10.

Report to payroll

a.

Provider name per
provider

b.

# consultations per provider

c.

Total fees per provider

d.

Total fees

e.

Total consultations

11.


Add/ Delete/ Update

a.

Members

b.

Providers

c.

Administration

6
.0
Responsibilities

Members:



Obtain login information from DB.



Hash function for storing passwords in the D
B



Ability to UPDATE member’s info.



Return query of services received per provider.


Providers:



Obtain login information from DB.



Hash function for storing passwords in the DB



Ability to UPDATE provider’s info.



Query of all services that can be provided.



TBD: C
alendar/reservations (need to do own UI)



TBD:
help members make schedule



List all providers


Reports:



Setup DB



Queries

o

Get Graph Data

o

Summary Information

o

Money Spent / Services

o

Member Services rendered

o

Provider services

o

All graph data

Interface:



Tomcat server



JSP data fetching



For members/ providers/ administration:

o

Login Page



Username



Password



Submit



Forgot password



Lockout



For members:

o

Graphs of:



Services rendered YTD



List of providers



List of services applicable by $ per insurance plan

o

Personal

info



For providers:

o

Graphs of:



Members served



Fees billed monthly and YTD



List of services that they can provide.

o

Personal info

o

Process services rendered to members



For administration

o

Personal info

o

Members info (same as member)



List all members

o

Providers
info (same as providers)

o

Service codes

o

Insurance

o

Graphs for:



Most popular service



Service by $



Most visited provider/ most visited provider category

o

Add new services.

Administration:



Service codes

o

Get all codes

o

Update codes/ prices



Graphs for:

o

Service by
$

o

Service by use

o

Service by provider

o

Service use



Insurance covers which services



Add new services



Process service codes

Financial:



Bank card processing



Move money from Member for monthly service fee to ChocAn



Query Member balance



Query Provider balance



Monthly reports with reports groups



EFT



Keep a maintained database record of transactions, bank accounts, and refunds/disputes



Move money from provider to member on a challenge of service (refund request/disputes)



Move money from insurance to providers



Sen
d monthly financial statement emails to admins


7
.0 Additional Components

a)
Database Layout

http://128.195.204.96/svn/eecs118/Docs/Database_Layout.pdf

b) Class Diagram

http://128.195.204.96/svn/eecs118/Docs/class_diagram.pdf


c)
Financial

Module

Use Case Diagram

and Descriptions


Add Bank Account

Use Case

Brief Description

The
Add Bank Account

use case
enables

a Member

and a Provider

to add a bank account that they will use
in an Electronic Fund Transfers for refunds or payments.

Step
-
By
-
Step Description

1.

The Member or Provider provides their ID, their Bank Account’s Balance, and their Bank
䅣A潵湴o
Nu浢敲.



Take the information from the Member and Provider and add information to the database.


Request Refund

Use Case

Brief Description

The
Request Refund

use case
enables

a Member

to file refund request. This use case enables the Provider
to re
view request and access the
Make a Transaction

use case

if refund request is accepted.

Step
-
By
-
Step Description

1.

The Member initiates a refund request.

2.

Acknowledge a request has been created by using the
Update Status
use case
.

3.

State the amount of the refu
nd requested by the Member by using the
Update Balance
use case
.

4.

Record any comments the Member has about the refund by using the
Update Comments
use case
.

5.

The Provider then reviews refunds request.

6.

If Provider accepts or denies request, then the
Update St
atus
use case

is used.

7.

Any Provider comments are put on the request using the
Update Comments
use case
.

8.

If the Provider accepts, then the
Make a Transaction
use case

is used to initiate a fund transfer
from the Provider to the Member.




Update Refund
Request Use Case

Brief Description

The
Update Refund Request

use case
enables

a Member to request a refund from a Provider. The
Update Refund Request

use case will update any and all parameters of a pending refund request.

Step
-
By
-
Step Description

1.

The Me
mber initiates a refund request.

2.

Add the pending refund request to the database.

3.

When a refund request is approved or denied, or any of the details of the refund is changed, the database
record will be updated accordingly.

4.

Update information in the Refund
Request Database.

5.

If a request is approved, the
Make a Transaction

use case will be used to move money from a
Provider’s account back into a Member’s account.


剥Ru敳e M潮瑨汹 䙩n慮ci慬a剥R潲t 啳e C慳a

Brief Description

The
Request Monthly Financial
Report

use case provides a Member with a history of their
transactions over the past month.

Step
-
By
-
Step Description

1.

Request transaction information from the past month from the

“Transaction” table in the


䙩Fanc楡i


T慴ab慳攮



Organize the information in
an easy to read report format.


Make a Transaction Use Case

Brief Description

The
Make a Transaction

use case allows a Member or Provider to make a payment or accept a refund.
The
Make a Transaction

use case allows the
Monthly Fee Withdrawal
,
Process
Insurance
Claim
, and
Update Bank Account

use cases to be accessed.

Step
-
By
-
Step Description

1.

Begin a transaction of the specified type (payment, refund, or monthly fee payment).

2.

Check insurance coverage and process an insurance claim using the
Process Insu
rance Claim

use
case before charging on a payment.

3.

Update the bank account based on the transaction using the
Update Bank Account
use case.

4.

Add the information regarding this transaction into the “Transaction” table of the “Financial” database.


Monthly
Fee Withdrawal Use Case

Brief Description

The
Monthly Fee Withdrawal

use case enables the
Make a Transaction

use case to create a
transaction based on the withdrawal of monthly fees. The success or failure from this transaction will enable the
Update Stat
us

use case to act accordingly.

Step
-
By
-
Step Description

1.

Attempt to withdraw the monthly fees from a Member’s account.



If the payment is successful, check if a Member’s status in the database is currently ‘suspended’. If so,
敮慢l攠tUe
Update Status

use
case to update the Member’s status to ‘active’.



If the payment was not successful, enable the
Update Status

use case to update the Member’s
status to ‘suspended’.


偲潣敳猠䥮獵牡rc攠C污業 啳攠C慳a

Brief Description

The
Process Insurance Claim

use case ena
bles the
Make a Transaction

use case to check the
type of insurance coverage a Member has and adjust the payment amount accordingly.

Step
-
By
-
Step Description

1.

Make a Transaction

use case enables the
Process Insurance Claim

use case on a
transaction.

2.

Check
in the database to determine the type of insurance coverage and if so, whether it applies to the
specified transaction.

3.

Adjust the payment amount based on the insurance, if necessary.


Update Bank Account Use Case

Brief Description

The
Update Bank Account

use case enables
the Make Transaction

use case to update a bank
account based on a payment or refund transaction.

Step
-
By
-
Step Description

1.

After determining the payment or refund amount of the transaction, attempt to withdraw or deposit the
specified amo
unt into the User’s bank account.



Attempt to update the user’s bank account information in the database.



Return the information to the
Make Transaction

use case on whether or not the payment or refund
was successful.




d)

Member

Module Use Case Diagram and Descriptions

Update

Member

Status Use Case

Brief Description

The
Update

Member

Status

use case enables the
Monthly Fee Withdrawal

use
case to update a Member’s status to ‘suspended’ or ‘active’ based on non
-
p慹浥at 潲 p慹浥nt
潦 m潮tU汹 f敥献

Step
-
By
-
Step Description

1.

If the Member’s status is currently ‘suspended’ and a monthly fee payment is made,
update their status to ‘active’.



If the Member’s status is currently ‘active’ and they fail to pay their monthly fees,
update their status to ‘suspended’.


䕭E楬iM潮瑨汹 䙩n慮c楡i 剥R潲t 啳攠C慳a

Brief Description

The
Email Monthly Financial Report

use case sends the Admin a monthly fina
ncial
report.

Step
-
By
-
Step Description

1.

On the 28
th

day of the month, generate a monthly financial report from the information
in the “Financial” database.



Compile the information in an easy to read report format.

3.

Email this report to the Admin.