project management - Personal.Psu.Edu

texturegainfulMobile - Wireless

Dec 10, 2013 (3 years and 10 months ago)

277 views

Page
1

of
37

Version Date: 04/12
/2012







PROJECT PLAN



For Project:

Final Report


For PSU Course:

Spring 2012, IST 440W, Section 3


Date of Submission:

04/12
/2012


Revision

Date

Modification

1

02/05/12

First draft of
the document

2

02/15/12

Added in information and clarified sections based on feedback from the
TA, most notably the communities of interest.

3

03/01/12

Expanded to include Technical Design and relevant sections.

4

04/12/12

Added in requirements for
Final Report










Page
2

of
37

Version Date: 04/12
/2012

Table of Contents


Table of Contents

................................
................................
................................
................................
..

2

PREFACE

................................
................................
................................
................................
.............

4

Document Identification
................................
................................
................................
......................

4

Privacy Information

................................
................................
................................
............................

4

INTRODUCTION

................................
................................
................................
................................
..

5

Purpose of Plan

................................
................................
................................
................................
.

5

Background Information About the Project
................................
................................
.........................

5

Statement of Problem Being Solved

................................
................................
................................
..

5

Project Approach

................................
................................
................................
...............................

6

Project Goals and Business Objectives

................................
................................
.............................

6

Project Goals

................................
................................
................................
................................
..

6

Business Objectives

................................
................................
................................
........................

6

Project Scope

................................
................................
................................
................................
.....

6

Deliverables

................................
................................
................................
................................
....

7

REQUIREMENTS DEFINITION

................................
................................
................................
............

7

Requirements Gathering Process

................................
................................
................................
......

7

Literature Search

................................
................................
................................
...............................

7

Functional Requirements

................................
................................
................................
...................

9

Non
-
Functional Requirements

................................
................................
................................
.........

10

Performance

................................
................................
................................
................................
.

10

Security

................................
................................
................................
................................
.........

10

Back
-
up and Disaster Recovery

................................
................................
................................
....

10

Portability

................................
................................
................................
................................
......

10

Scalability

................................
................................
................................
................................
......

11

Interchangeability

................................
................................
................................
..........................

11

Sustainability

................................
................................
................................
................................
.

11

Interoperability

................................
................................
................................
..............................

11

Usability

................................
................................
................................
................................
........

11

Technical Requirements

................................
................................
................................
..................

11

Input and Output Requirements

................................
................................
................................
....

11

Platform Requirements

................................
................................
................................
.................

12

Data Requirements

................................
................................
................................
................................
...............................

13

Communication Requirements

................................
................................
................................
......

13

Development Requirements

................................
................................
................................
..........

13

Technical Requirements Mapping

................................
................................
................................
.

14

Design Constraints

................................
................................
................................
........................

15

FUNCTIONAL DESIGN

................................
................................
................................
......................

15

Activity Diagrams

................................
................................
................................
.............................

16

Use Cases

................................
................................
................................
................................
.......

17

Technical / Application Architecture

................................
................................
................................
.

18

Flow of Data and Information

................................
................................
................................
........

18

Development and production

................................
................................
................................
........

18

Hardware Configuration

................................
................................
................................
................

19

PROJECT MANAGEMENT

................................
................................
................................
.................

23

Project Assumptions

................................
................................
................................
........................

23

Project Constraints

................................
................................
................................
...........................

23

Page
3

of
37

Version Date: 04/12
/2012

Work Breakdown Structure (WBS) Gantt Chart

................................
................................
...............

24

Roles and Responsibilities

................................
................................
................................
...............

24

Change Management

................................
................................
................................
......................

25

Issue Management

................................
................................
................................
..........................

25

Issue Log

................................
................................
................................
................................
.........

25

Communications and Control

................................
................................
................................
...........

25

PROJECT DEMONSTRATION

................................
................................
................................
...........

26

PROJECT SUMMARY STATEMENT

................................
................................
................................
.

26

APPENDICES

................................
................................
................................
................................
.....

27

Appendix 1: WEEKLY STATUS REPORTS

................................
................................
.....................

27

Appendix 2: EXTERNAL COMMUNICATIONS

................................
................................
................

31

Appendix 3: GLOSSARY

................................
................................
................................
.................

31

Appendix 4: TEAM CONTRACT

................................
................................
................................
......

31

Team Name: 31

................................
................................
................................
..............................

31

Course/ Section: IST 440W Section 3

................................
................................
.............................

31

Project Team Members Names and Sign
-
off

................................
................................
...................

31

Code of Conduct
-

Three Strike Policy

................................
................................
.............................

32

Participation

................................
................................
................................
................................
.....

32

Division of Work

................................
................................
................................
...............................

32

Communication

................................
................................
................................
................................

33

Meeting Guidelines

................................
................................
................................
..........................

33

Appendix 5: DATA DICTIONARY

................................
................................
................................
................................
......

34




























Page
4

of
37

Version Date: 04/12
/2012

PREFACE

Document Identification


Project Name: Functional Design Report

Document Owner: Eric Papamarcos


The primary contact for questions regarding this document is:


Project Team Members:



Name: Eric Papamarcos



Phone: (610) 348
-
5766



Email:
eap
194@
psu
.
edu




Name: Kristen Glaser



Phone: (717) 891
-
8977



Email:
keg
5141@
psu
.
edu




Name: Lucas Kozaczki



Phone: (814) 860
-
1380



Email:
ljk
191@
psu
.
edu




Name: Tyler Lewkovich



Phone: (703) 999
-
3085



Email:
tjl5147@psu.edu




Name: AnastassiaIoujanina



Phone: (814) 933
-
6902



Email:
aii
1@
psu
.
edu


Privacy Information




This document may contain information of a sensitive nature. This information should not be
given to persons other than those who are involved in the Functional Design Report project or who
wil
l become involved during the life
-
cycle.






Page
5

of
37

Version Date: 04/12
/2012

INTRODUCTION


This project addresses the issue of the missing connection between people who are in need of
help in the United States and those with the ability to provide it. Our goal is to alleviate this issue

by
implementing an IT
-
based, innovative solution.

Purpose of Plan


This report describes the functional design of our capstone project. We discuss the motivation
behind the project, its objectives and business goals, and outline our plan for its successfu
l
completion.

Background Information About the Project


The main concept for this project was originally developed by team member Eric Papamarcos
for the first individual exercise. The team saw innovative value in the idea and adapted it for a small
-
scale

implementation manageable by a group of our size. We assessed the skills and experience of
team members to decide what was within our capabilities, and as part of the process, we narrowed
the scope from worldwide to nationwide. We also decided to exclude
food from the list of items we’d
connect people over, to avoid complications of federal regulation compliance.


Statement of Problem Being Solved



Poverty is one of the biggest issues in the U.S. today that prevent people from living a quality
life. Many

families are unable to purchase the basic essentials in life such as clothing. At the same
time, there are people who are simply throwing away old clothes and other goods that they don’t need
anymore. Many of these goods, which are still useful, simply go

to waste because there is no way for
organizations to directly connect the people who need them with the people who are throwing them
away.


There are undoubtedly existing organizations that are trying to solve this problem, but they
have been
unsuccessful. In this case, examples of organizations would include homeless shelters,
YMCAs, and any other organization whose goal is to improve the quality of life of other people. This is
because even if someone donates items to these organizations, the
re is no guarantee that the items
will end up in the hands of the people who need them the most, or end up being used at all. For
example, someone might donate a winter jacket to a shelter, but the person who really needs that
winter jacket is actually in
another shelter across town. This is because there is no easy or convenient
way to find out whether a personal possession that no longer has value to one person is desperately
sought after by someone less fortunate. We think that if there is a way to conne
ct the needy to those
who can provide aid to them, it will greatly improve the quality of life of many Americans.


There are three major communities of interest in this project: the donor, the organization, and
“Joe” (the typical person in need). While we
believe this project is innovative in at least some way for
each of the three communities of interest, this website will be truly innovative for the organization. For
the most part, donors don’t care who their donations go to, as long as they help someone
in need.
And, people like Joe don’t care where the donations come from, as long as the items are what they’re
looking for. Thus, even though this may be an innovative product for the donor and Joe, the potential
Page
6

of
37

Version Date: 04/12
/2012

for innovation lies with the organization. T
he website will allow the organization that facilitates the
interaction between these two groups of people to become more innovative. This website is just the
beginning of an improved “matching” process for donors and recipients. The organization will do a

better job distributing donated items because of this website. The solution that this website provides
is just the tip of the iceberg for this problem. Organizations will be in a position to continue to innovate
on this idea. Therefore, this is not just a
n innovative product
--

it will allow organizations to become
more innovative.

Project Approach


Our group will take an iterative, spiral approach to this project. With relatively little time to
complete deliverables, the spiral method of software developm
ent will allow us to move quickly to
make sure each deadline is met and each deliverable is of high quality. Our group will have regular
meetings to determine next steps; the team leader will make sure everyone is on track. We will set
internal or group de
adlines that come before the project deadlines to make sure there is a review
period for each deliverable. Our group will create prototypes throughout the process so that we can
get an idea of how our product will work. We will make any necessary changes a
fter evaluating our
prototypes.

Project Goals and Business Objectives


Project Goals

Our overall goal for this project is to design an efficient, innovative, and relatively easy
-
to
-
use
application that allows organizations to connection those who are in ne
ed with those who are willing
to donate clothing and other goods. We hope to close the gap between these two groups and
increase the amount of aid available for those less fortunate in the U.S.


Business Objectives

The business objectives for this project
are to create an innovative solution that fulfills the
goals of the project, and to remain ethically responsible while developing a not
-
for
-
profit application.
Our team will have a clearly defined schedule and plan to make sure that these goals are
accompl
ished using the resources at our disposal. We will keep in mind through the decision
-
making
process that this project is to help those in need, not to be a money
-
making application for its
creators.

Project Scope


Our website will launch for use by organiz
ations in State College, PA, USA. While the website
will be built to scale to other communities throughout the United States, the website will initially only
launch in State College. It is possible that the website could potentially be used worldwide, but
that is
outside the scope of this project.


The website will be used by organizations to connect those in their organization with donors.
Donors will list items that they would like to donate, and those affiliated with the organization will be
able to “sel
ect” these items. Those in the organization may also indicate that they are “Looking for”
something, and donors can indicate that they “have” this item to donate. Donors will drop off items at
Page
7

of
37

Version Date: 04/12
/2012

the organization’s location. If the organization is willing, th
e organization may also pick up items at the
donor’s house or apartment. The website will not process financial transactions because there is no
exchange of money in this process.

We will create a database with sample data that will be used to demonstrate
how the
application would work in real life. It will have a simple front
-
end interface, and will provide sufficient
security on the back
-
end.


Deliverables

Item #

Deliverable Description

Estimated Completion Date

1

Functional Design Report

2/2/2012

2

Technical Design Report

3/1/2012

3

Project Presentation

3/30/2012

4

Final Report

4/12/2012


REQUIREMENTS DEFINITION


This section describes how we identified properties of the functional and technical designs, as well as
the requirements of the
application.


Requirements Gathering Process




In order to determine the functional requirements of this website, we tried to imagine ourselves
as each of the three different stakeholders: donors, organizations, and members of those
organizations who are
in need. We tried to understand what attributes or information about the items
being donated would be necessary to list on the website. It is extremely important to include all of the
necessary attributes or information about an item in order to facilitate

a successful matching between
donors and those in need. We determined these attributes by brainstorming a simple but complete list
of attributes that would be necessary to identify each item. These attributes include size, condition,
color, and an optiona
l description. We also tried to figure out the best way to facilitate these
transactions by analyzing other e
-
commerce websites, and identifying the different features that allow
these websites to exchange goods between different people.

Literature Search




We have examined multiple web
-
based sources pertaining to the general nature of the
problem we are trying to address. The primary findings are that this is indeed a problem, that there
are other people or organizations trying to solve it, and that there

haven’t been any successful
solutions to this problem yet. By analyzing different organizations’ websites that attempt to solve this
problem, we were able to identify what type of solution would be the most effective in solving this
problem.


Page
8

of
37

Version Date: 04/12
/2012

Red Cross


After visiting the Red Cross’ website, we found that it was probably the most versatile of the
three sites we examined. There is both a national and local (Centre County) version of the website,
but the local version is out
-
of
-
date and not very functional.

We found that users are limited to donating
money on the national website, but that there was an option to donate directly to the local Red Cross
chapter. The national website also included the ability to find the closest chapter in your area and
direct y
ou to this location. Additionally, on the national website, you can specifically target an area
where you would like your money to be donated. Donations can be targeted towards your local
chapter, “who needs the donation most,” or to a disaster relief fund
. The website has a high priority on
the organization’s main mission, donating blood, and includes information about upcoming blood
drives.


Goodwill


Like the Red Cross, there is both a national and local website for Goodwill. It seems as though
the main
purpose of the national website is to provide background information about Goodwill, as well
as direct you to your local chapter’s website. On the local website, there is information about how and
where to make donations. However, there is no way to donate

particular items, or find out which of
the many Goodwill locations are in need of particular items. The website is limited to purchasing gift
certificates. The Goodwill website suffers from the same problem as the Red Cross’ website
--

there
is no way to
directly donate items.


The Salvation Army


The Salvation Army has a website for its Centre County chapter, where visitors are provided
with information on donating money, auction items, clothes, furniture, and what they refer to as gift
-
in
-
kind (car, boat
, store inventory, collectible). Only monetary donations can be made online, and
clothing can be dropped off at three different bins located in the State College area. For all other
items, donors have to make special arrangements to discuss the details of
the donation. Monetary
gifts can be specified to be intended for a particular cause, but, beyond that, the donor really has no
control over who gets the benefit of the donation. It is not explained on the site how the Salvation
Army determines who is eligi
ble, and who is in need. Furthermore, there is no way for those in need
to find out whether the Salvation Army has an item they are in desperate need of, or to request it.


What makes our website different?



Our
website will differ from the

websites liste
d above because it will form a solid connection
between donors, organizations, and those in need. The current websites for the Red Cross, Goodwill,
and the Salvation Army focus primarily on monetary donations. Our site will focus on the supply and
demand o
f physical items, such as clothing and furniture. We will list both the items that donors have
donated, as well as items that are needed by the less fortunate. This will allow donors to donate more
effectively. It will also make it easier for a person in n
eed to find the specific item that he or she is
looking for. Overall, our site will help organizations like the Red Cross and Goodwill to better serve
their communities by allowing them to match up donors and people in need of donations.


Page
9

of
37

Version Date: 04/12
/2012

Functional Requir
ements

The following is a comprehensive listing of all the things our application will do, as well as
requirements on how it will carry out those functions. They are coded as one of the following:



Mandatory

-

Absolutely essential; project will fail if not
included



Optional

-

Nice
-
to
-
have; one or more of these could be omitted without affecting the project's
viability.


Requirement
#

Description

Mandatory/
Optional

FR001

There shall be a screen for a user to enter information about a
donated item.

Mandatory

FR002

There shall be a way to store the information collected

Mandatory

FR003

The application shall be accessible from the Internet.

Mandatory

FR004

The application shall support all major browsers versions

Optional

FR005

The application
shall provide a registration screen for a
donation collection center to register

Mandatory

FR006

The application shall provide a registration screen for a donor

Mandatory

FR007

The application shall provide a user the ability to search for a
donated item

Mandatory

FR008

The application shall provide a map of charitable organizations
within a certain range of the user

Optional

FR009

The application will ensure protection of personal information
saved

Mandatory

FR010

The application will provide
descriptive information on all donated
items, including how they can be obtained

Mandatory

FR011

The application shall provide a logon screen for registered donors to
enter a logon Id and password

Mandatory

FR012

The application shall provide a logon scr
een for donation collection
centers to enter a logon id and password

Mandatory


The achievement of these functional and technical requirements will be verified by users in a
preliminary test of the application.





Page
10

of
37

Version Date: 04/12
/2012

Non
-
Functional Requirements


This
section describes the non
-
functional requirements of the application and how the non
-
functional
requirements are verified. The non
-
functional requirements are listed below.


Performance



The website will be available for operation 24 hours a day and 7 day
s a week, with the
exception of occasional scheduled maintenance. There also might be unscheduled emergency
downtime, but, because we are using shared hosting for the website, this is largely out of our control.
The reliability of the website should be str
ong due to the reliability of the shared hosting company,
HostMonster, in the past. If the site gains traction and has a large increase in user, we will work with
HostMonster to upgrade our hosting plan to allow for heavier traffic.


Security




Because th
is website processes and stores user information, security is very important. User
data should only be accessible by those who absolutely need to view it. Both the transmission and
storage of user information should be strong.



Users on the website will
be given different permissions based on their role. A user who is not
logged in will not be able to view anything but static information on the website. Registered users will
be able to use the different functions of the website such as listing a winter co
at for donation. Users
who are affiliated with an organization will be given the ability to facilitate drop
-
offs and contact
donors. Users given administrative privileges will be given access to almost all dat
a

on the website
with the exception of secure i
nformation such as passwords. Therefore, different users will be given
different access rights depending on their role in the system.



There is also a need for physical and network security for the database servers. However,
because we are using HostMonst
er for our hosting, we are relying on their trusted service to protect
their servers and databases.


Back
-
up and Disaster Recovery




Because there is a heavy reliance on user information and user
-
created information for this
website, it is imperative that

this information is backed up on a regularly scheduled interval.
Fortunately, HostMonster provides this backup functionality
.All we need to do is have a plan in place
to restore user data as quickly as possible in the event of a disaster
.


Portability

The

website will be accessible and compatible with all major browsers, meaning that the service can
be used on a wide variety of platforms and devices. This means that the website can also be viewed
on tablets and smartphones.




Page
11

of
37

Version Date: 04/12
/2012

Scalability



For this websit
e, scalability depends on our hosting company’s ability to handle heavy traffic if
there is a substantial user increase. If this does happen, we will need to upgrade to a more
comprehensive hosting plan from HostMonster. It also involves the number of work
space and
employees. For example, an increase in the number of users of the website will also likely result in
the need for more employees or workers.


Interchangeability



Allowing developers to update the website is crucial to the long
-
term success of th
e website.
One way we are able to accomplish this is by separating the logic of the website with the styling of it.
Different styles can be applied to the website in such a way that it doesn’t affect the actual
functionality of the website. To clarify, a d
eveloper could make a change to how a form looks (the
style), but this won’t affect the actual processing of the user input (the logic).


Sustainability



In order to be sustainable, we must be able to adapt to additional requirements, feature
requests, an
d user feedback. We must also be able to adapt to changing technologies and standards.
Adapting to change is crucial when trying to achieve sustainability.


Interoperability



Interoperability is critical when exchanging information with charities and
users. Users must be
able to effectively communicate with these organizations in order for the website to be a success. If
users are not able to properly exchange and communicate information, the website will not meet its
goals and purpose.


Usability



The website can have very powerful features, but if it’s not easy to use, then this doesn’t
matter. We hope to design the website in a way that makes it easy for users to navigate throughout
the website and accomplish the different tasks set forth by the w
ebsite. We will design the menu
structure in a way to that is easy to understand. There will also be clear descriptions of what different
functions will do. We will use a light color scheme that will put the focus on the content and
functionality of the we
bsite. There will also be a way for users to contact the site developers if they
are having trouble using the website.


Technical Requirements


Input and Output Requirements



All data inputted into the website and its database will be directly from an inp
ut form on the
website. There will be no manual data process (ex: from a paper form to digital form on the website).
This website will support data input from all users of the application, although the data inputted by
Page
12

of
37

Version Date: 04/12
/2012

each user may be different based on t
heir role in the system. For example, a donor will be able to
input information about an item that they would like to donate. The person in need will also be able to
input information about an item that they are “looking for.” However, even though these tw
o users are
both inputting data about items, the person in need would probably not specify, for example, the
“condition” of the item they are looking for. Users will be able to edit their listings, and site
administrators will be able to edit information f
or all users to correct mistakes, etc.



Essentially, all of the data that is inputted into the website and its database will be outputted in
some way. For security reasons, personal user information may not be displayed to other users.
Listings of items w
ill be outputted to users in an easy to read and printable form. When an item is
ready to be picked up, users will be able to print out an email or confirmation message to present
during the exchange of items.



For the launch of this application, there wi
ll not be any automatic data input. It is possible that
in the future data could be automatically imported based on needs by other charitable organizations,
but that is outside the scope of this project.



Platform Requirements


Hardware

Hardware Functiona
lity

This website is designed to be used on several devices, including desktops, laptops, tablets, and
smart phones. The website is not designed for any particular set of hardware. The only hardware
requirement is that the device has an Internet connection
, whether it’s through 3G, Wi
-
Fi, or Ethernet.
The device must also have a screen and a way to navigate the website.

If on a laptop or desktop, the
computer should have at least 2GB of RAM and a 2.2 GHz processor

The website can work on
different desktop a
nd mobile operating systems including Windows, OS X, iOS, Android, and
Windows Phone.


Hardware Characteristics

The desktop, laptop, or phone being used should conform to the latest Internet connection standards.
For example, for a wireless connection, the

device should conform to the industry
-
standard 802.11n
wireless standard.


Software

Software Functionality

This website will use several different programming and scripting languages including HTML, PHP,
CSS, JavaScript, and MySQL. The website will use a
combination of PHP and MySQL to interact with
the database. This will allow for both the inputting and outputting of information in the database. We
will use Google Analytics to track activity on the website. This will allow us to identify user trends on
t
he website. We will use PHP’s native error handling to trac
k bugs and errors.


Software Characteristics

In order to iterate quickly, we will reuse code as much as possible. This will allow us to make changes
that easily propagate throughout the application

instead of having to update code for each page, etc.
For example, by implementing a reusable function in a shared “functions” file, each page will be able
Page
13

of
37

Version Date: 04/12
/2012

to use the same function and we will not need to copy and paste the same code contained in the
funct
ion on each page. Reusable and modular code will allow for faster development and quickened
maintenance and updates.


Data Requirements

The diagram below shows how the main item data for this application will be stored in the database.
There will be five t
ables: ITEM, ITEM_TYPE, ITEM_SUBTYPE, AVAILABILITY, and CONDITION.


ITEM
_
TYPE
PK
TYPE
_
ID

TYPE
_
NAME
ITEM
_
SUBTYPE
PK
SUBTYPE
_
ID

SUBTYPE
_
NAME
FK
1
TYPE
_
ID
ITEM
PK
ITEM
_
ID

ITEM
_
DESC

ITEM
_
SIZE

ITEM
_
COLOR

PIC
_
NAME
FK
1
SUBTYPE
_
ID
FK
2
AVAILABILITY
_
ID
FK
3
CONDITION
_
ID
CONDITION
PK
CONDITION
_
ID

CONDITION
_
NAME
AVAILABILITY
PK
AVAILABILITY
_
ID

AVAILABILITY
_
NAME


A data dictionary is included in Appendix 5 of this report, including sample data.


Communication Requirements



At launch, this website will not use any
external interfaces outside of its own database. As
mentioned before, this application could have the possibility of interacting with other databases and
APIs, but that is out
side the scope of this project.


Development Requirements



In order to develop t
his website, we will need both an Integrated Development Environment
(IDE) and a tool for creating a database. The IDE must be able to edit and save PHP, HTML, CSS,
and JavaScript code. The database tool must be able to create database tables and input sam
ple
data.







Page
14

of
37

Version Date: 04/12
/2012


Technical Requirements Mapping


The table below maps (or matches) functional and non
-
functional requirements with their
corresponding technical requirements.


Requirement
#

Description

Mandatory/Optional

FR
Map

TR001

There shall be a user

input form that captures
information about a donated item and transfers it into
the database.

Mandatory

FR001

TR002

There shall be a MySQL database that is used to
store the information that is collected.

Mandatory

FR002

TR003

The website shall only be
usable when there is a
successful Internet connection and the database is
able to connect properly.

Mandatory

FR003

TR004

The application shall use proper HTML and CSS
conventions such that it displays and operates
properly in all major browsers, includin
g Google
Chrome, Mozilla Firefox, Microsoft Internet Explorer,
and Apple Safari.

Optional

FR004

TR005

The website shall have a user input form that
registers a charitable organization and inputs the
organization’s information into the database.

jandato特

䙒MMR

q到o6

qhe⁷eb獩瑥⁳ a汬⁨ave⁡⁵se爠rnpu琠form⁴ha琠
registers a donor and inputs the user’s information
楮io⁴he databaseK

jandato特

䙒MM6

q到oT

qhe⁷eb獩瑥⁳ a汬⁰牯r楤i⁴he u獥爠瑨e⁡b楬楴i⁴o
獥a牣栠the database 景爠r瑥m猠u獩湧⁡⁵ser
J
獵bm楴ied
景牭K

jandato特

䙒MMT

q到oU

qhe⁷eb獩瑥⁳ a汬⁩ 瑥g牡瑥⁡ 䝯og汥ljap猠sidge琠
瑨a琠show猠s p of⁣ha物瑡b汥牧an楺a瑩tns⁷楴i楮ia
捥牴r楮i牡ngef 瑨e use爮

佰瑩tnal

䙒MMU

q到o9

qhe⁷eb獩瑥⁷楬氠l牥ren琠ba獩挠s兌⁩ 橥捴楯n and
upp⁡瑴a捫猠瑯 en獵re 瑨e
p牯瑥捴con of⁰e牳rna氠
楮io牭a瑩tn⁩n⁴he⁤a瑡ba獥K

jandato特

䙒MM9

q到oM

qhe⁷eb獩瑥⁳ a汬⁰牯r楤i⁡⁷ay⁴o⁩ pu琠and ed楴i
de獣物p瑩te⁩ fo牭a瑩tnn a汬⁤ona瑥d⁩瑥m猠u獩湧⁡n
楮iu琠景牭K

jandato特

䙒M1M

Page
15

of
37

Version Date: 04/12
/2012

TR011

The website shall have a login page for
registered
users that verifies a user’s identity and allows them
access to protected pages on the website.

Mandatory

FR011



Design Constraints



There are two main design constraints affecting this project: time and cost. Like with many
projects, time and cost affects the features that can be added. With limited time and resources, not
every feature can be added. In particular, limited financial co
ntributions require us to use a cheap
hosting plan to host the website, which may result in fewer people being able to access the
website

at
one time, and perhaps decrease the amount of data that can be stored in the database. Because
there is limited time
, not only does this limit the number of features that can be added, it limits the
number of features that can be tested. Therefore, trade
-
offs need to be made in order to complete
this project in the required time and with limited financial input.


FUNCTI
ONAL DESIGN




The overall function of our application is to connect the people who are in need of clothing and
other basic life necessities with those who are able to donate these goods. Users on the site will be
able to post a picture of the item, in add
ition to its size, condition, location, the gender it is intended
for, and additional comments. Once the item is posted, those who are in need of the garment can go
onto the website and search for garments that are nearby and can get into contact with thos
e who
actually are in possession of the garment.










Page
16

of
37

Version Date: 04/12
/2012

Acti
vity Diagrams




The following activity diagrams depict the functionality of the application.



The first diagram depicts the functionality of when a user enters information to be donated. The
a
lternative path is shown for when the information for the item is not correct. It also shows the
simultaneous paths of a successful record.



This simple diagram shows the basic activity for when a user performs a search. It shows that even a
search
that returns zero records still returns successfully and it not treated as an error.








Page
17

of
37

Version Date: 04/12
/2012

Use Cases


Use cases are to be prepared to address the functionality of the application.


Use Case 1
--

Find Item

A user is looking for a winter jacket on the
website.

1.

User accesses website from supported browser

2.

User enters information to search

3.

User clicks button to perform search

4.

Search returns with items found


Use Case 1
-

Alternative 1
-

No records found

1.

Users enters information to search

2.

Users clicks but
ton to perform search

3.

Search returns zero items

4.

Message displayed to user that not records found that matched search


Use Case 2
--

Donate Item (registered user)

A user has an old winter jacket that they would like to list on the website.

1.

User accesses the

website from a supported browser

2.

User accesses logon page from main screen

3.

User enters correct logon ID and password information

4.

User clicks button to logon

5.

User is taken to donation page

6.

User enters information about item to be donated

7.

User clicks button

to save record

8.

Record is successfully written to storage

9.

Success message is displayed to user


Use Case 2
-

Alternative 1
-

Incorrect logon ID entered

1.

User accesses logon page from main screen

2.

User enters incorrect logon ID

3.

User clicks button to logon

4.

Error message is displayed to user that the logon ID is invalid


Use Case 3
--

Select Item

A user finds a winter jacket on the website and wants to “select” the item.

1.

User accesses website from supported browser

2.

User enters information to search

3.

User click
s button to perform search

4.

Search returns with items found

5.

User clicks on item to view more details

6.

User clicks button to indicate intention to pick
-
up/receive item

7.

Record is successfully written to storage

8.

Success message is displayed to user

Page
18

of
37

Version Date: 04/12
/2012

TECHNICAL
DESIGN

Technical / Application Architecture


Flow of Data and Information


The data being used for our website will come directly from the users who access it every day. Data
can come from two different sources: donors who have items and people who need
items. If a donor
has something to donate to an organization, such as a winter coat or a pair of shoes, he or she can fill
out a donation form on the website. Any data that is entered into the form will be stored in the
database (server). Additionally, if
a user is in need of a particular item, he or she can fill out a request
form on the site and send that data to the database. Our website will then be used to display the user
-
submitted information to different organizations in order to help them better se
rve their members and
the community.



Development and production



For the creation of our website, we will be utilizing HTML, PHP, CSS, and JavaScript. Most of
the website will be hard coded. Some GUI design may be done using Adobe Dreamweaver. To
interact with our database, we will use PHP and MySQL. phpMyAdmin will be used to create the
database tables. We will use HostMonster as our host to store our data since we lack access to our
own server. To track usage of our site, we will use Google Analy
tics. This will allow us to see who and
from where users are accessing the website, as well as view usage patterns.

Page
19

of
37

Version Date: 04/12
/2012

Hardware Configuration

The hardware configuration required for our website is basic and straightforward. All that is needed to
access our w
ebsite is a computer with a functioning Internet connection. In order for our site to work
properly, the site must be connected to our server. Our server will be operated by a third party hosting
site.

Design Guidelines



It is important for all of our dat
a to be well
-
organized. The data will be stored in different
database tables, and will be indexed in such a way that allows for fast data retrievals. Once it’s time
to display information to the user, this information will be sorted in alphabetical order o
r by category,
depending on the type of information being displayed.



Another important design guideline for the website is the verification of data submitted by a
user on the website. We must be sure that the form will properly read in and store what the

user
enters. For example, if an input field requires a user’s name, the user should not be allowed to input a
number. This will require careful use of PHP, HTML, and JavaScript. The information collected from
the online forms will be crucial for the organ
izations that we are assisting through the use of this
website.

Handling Risks



We will be using HostMonster, a third party hosting site, as a host for our website’s data.
Therefore, we will not be directly responsible for dealing with the risks associate
d with the handling
and sorting of our website’s data. Instead, these risks will be transferred to the third party.
HostMonster will monitor the hardware necessary for the data storage. By transferring this risk to
HostMonster, we can focus our attention o
n the actual functionality of the website.





Page
20

of
37

Version Date: 04/12
/2012

UML Diagrams


Data from
Website
-
userId
:
int
-
type
:
string
-
email
:
string
-
password
:
string
-
name
:
string
-
address
:
string
-
phone
:
int
User
-
donationId
:
int
-
userId
:
int
-
itemId
:
int
Donations
-
requestId
:
int
-
userId
:
int
-
itemId
:
int
Requests
-
itemId
:
int
-
itemCategory
:
string
-
itemName
:
string
-
itemCondition
:
string
-
itemSize
:
string
-
itemColor
:
string
Item


This UML diagram shows a high
-
level overview of how user, donation, request, and item information
will be stored in the database. Information stored about users
includes their type (regular,
organization, administrator), email address, password, name, address, and phone number, Each
donation and request (looking for) has its own id number, and is connected with a particular user.
Each donation and request is also
connected with a particular item through an itemId. Each item has
a category, name, condition, size, and color.


Page
21

of
37

Version Date: 04/12
/2012

QUALITY MANAGEMENT

Activity Reviews/Walk
-
throughs




As stated previously, we are going to reuse code as much as possible. This will make it
easier
to actually code, but it will also be easier to perform walk
-
throughs and review to ensure that
everything is working properly. Reusable and modular code will allow for faster development and
quickened maintenance and updates.



We are also going to

check and review each section, or block, of code. It is much easier to test
a smaller section and will be much easier to find what section of code is not working properly.
Additionally, once we complete each of the code reviews, we can write a review repo
rt for the
stakeholders. This will ensure that the stakeholders know exactly how the project is going and will
give them the ability to communicate their thoughts to the rest of the team.



This website will use several different programming and scripting
languages including HTML,
PHP, CSS, JavaScript, and MySQL. Because we are going to be using multiple programming and
scripting languages, the reviews and tests need to be completed in order to ensure that the
integration of all of these different language
is working properly.


Tools and Techniques



We are using several tools and techniques for this project. We are using Adobe Dreamweaver
as our text editor to write PHP, HTML, CSS, MySQL, and JavaScript, and FileZilla as a File Transfer
Protocol (FTP) clien
t to upload files to the server. We are using phpMyAdmin to create the database.
We are using Microsoft Word to prepare reports such as this one and Microsoft Visio to create the
different UML diagrams such as activity diagrams, use case diagrams, and ER d
iagrams. We are
using a CSS table
-
less layout for the design of the website, and we will be using white
-
box and black
-
box techniques for testing. More information about our testing techniques is described in the section
below.


User Acceptance/Verification



User acceptance is very important for verifying that the website achieves its goal and
objectives. We will do our best to gain acceptance from a real, live user at a charitable organization
who can verify that this website is indeed helpful. To gain acc
eptance, the user will simply need to tell
us that our website is useful to them and that it provides a service that is helpful towards their
mission. Due to the time constraints of this project, it made be difficult to gain user acceptance for
every phase

of the project including requirements gathering, functional design, technical design, and
quality assurance. However, we will make sure that the main features are verified and accepted by
users. This also includes the other two users in our system, the do
nor and the person in need.
Because of the time frame of this project, we have already been forced to maintain a narrow scope of
features and requirements, so we do not anticipate the drifting of requirements.



Page
22

of
37

Version Date: 04/12
/2012


Testing is a crucial part of any software p
roject, and this website is no different. Although there
is not very much time in this project to perform testing, there are some simple ways that testing can
be implemented throughout development of the website that will reduce bugs and errors.



Testing,

like security, should be a part of the development process, not an afterthought. One
example of doing this is by testing small code blocks throughout development. For example, after
writing a simple function, you should immediately test this function. Thi
s is known as white
-
box
testing. White
-
box testing is when developers familiar with the code test code blocks and functions
such as this.



We will also do black
-
box testing. Black
-
box testing is testing done by users who have no
knowledge of the code base

or how different functions are implemented. For this website, we will
perform beta testing, a type of black
-
box testing.

We will ask friends and family members who do not
have prior coding or system environment knowledge to try and “break” the system
. The
se users are
able to come up with test cases that developers are not able to because they have no knowledge of
the inner workings of the website. It also gives a different point of view of the website and may point
out something that the team did not see d
ue to their closeness to the application.

Project and Industry Standards


This section identifies the standards agreed to used by the project team. These standards govern the
way in which the project will be conducted.


Languages



HTML, PHP, CSS, JavaScript, and MySQL. Additionally, the website will use a
combination of PHP and MySQL to interact with the database.


DBMSs


MySQL and phpMyAdmin


Tools


Google Analytics, Adobe Dreamweaver, FileZilla, and testing tools


Status repo
rting



Weekly status reports, post
-
deliverable reports, and stakeholder reports


Staff meetings



Weekly staff meetings every Monday at 11:15am. Additional meetings will be
scheduled as needed.


Product Review:
Testing results will be reported after the
completion of each set of tests. Tests will
be performed according to the testing plan.


Product review acceptance criteria
-

Different stakeholders will be contacted for approval after
major phases of the project are completed according to the user accept
ance and verification plan.











Page
23

of
37

Version Date: 04/12
/2012

PROJECT MANAGEMENT

Project Assumptions




There are many assumptions that go into the management of this specific project. First, we
assume that our website is the solution to our problem. We assume that people who are

better
-
off are
willing to help out the needy. This is a partial assumption because there are so many other examples
that illustrate that people are willing to help out the less fortunate. Additionally, we assume that we, as
a team, have the resources (tec
hnical experience, software, etc.) to create the website. We have
spoken as a team, and are under the strong assumption that each member will be on time and will
meet all deliverable deadlines and there will not be any scheduling conflicts. Again, this is
a partial
assumption because we have discussed these issues and believe that we have covered all group
expectations and possible scheduling conflicts.

Project Constraints




There are several constraints for this project. First, there is limited time to co
mplete the
website. Our group has limited resources to set up and build a website. Because this website is not
for profit, we can’t rely on making money in the future to cover our costs to build the website. We
have a limited skill level
--

not everyone is

a technical expert on any of the tools being used.


























Page
24

of
37

Version Date: 04/12
/2012

Work Breakdown Structure (WBS) Gantt Chart




Roles and Responsibilities


Name

Role

Description

Eric Papamarcos

CEO

Project sponsor, directly oversees CIO, primary
kill point
decision maker

Kristen Glaser

CIO

Monitors project, recruits the project team staff,
reports to the CEO

Lucas Kozaczki

Project Manager

Plans the project, executes the project directly
oversees project and project team

Tyler Lewkovich

Co
-
Director of
Technology
Operations (IT OPS)

Directs the project manager and guidance from
the overall functional and operational standpoint

AnastassiaIoujanina

Co
-
Director of Technology
Operations (IT OPS)

Directs the project manager and guidance from
the overall fu
nctional and operational standpoint


Page
25

of
37

Version Date: 04/12
/2012

Change Management




Our group will use Google Docs to make sure our documentation is quickly accessible and
editable for all members. Google Docs automatically records edits to documents, so each group
member will b
e able to easily track the changes to the document. We will use Dropbox as a central
location for the code base so that each group member always has an up
-
to
-
date version of the project
files on their computer. Dropbox automatically creates versions for fi
les, so each group member will
be able to easily access the version history for all project files.

Issue Management




Our group will use a separate Google Doc to track issues that arise. Possible solutions to
issues will be listed next to each issue until

there’s a resolution for the issue.

Issue Log


Issue
#

Date
submitted

Description

Resolution

Date
Resolved

001

2/2/2012

The team acknowledges that the full
definition of the application functionality is
not complete as of the submission of this
document

The team will continue
to revise these sections
as we move forward
into the technical
design phase.

2/2/2012

002

2/16/2012

Our group member Darrin Kirk was moved
to a different team and Tyler Lewkovich
replaced him. He was unfamiliar with the
project and
the details of the website we
are creating.

We explained the
project to Tyler at our
weekly status meeting.

2/20/2012

003

3/19/2012

Group member AnastassiaIoujanina failed
to create the logo for our website.

Kristen Glaser created
the logo instead.

3/26/2012


Communications and Control




The team is going to be utilizing email, Google Docs, phone (text/calls), class time, and weekly
team meetings to communicate throughout the project lifecycle. During the weekly team meetings,
the team will discuss

the status of the project, collaborate to complete any difficult portions of the
project to make sure that the project stays within its designed scope and to stay on schedule. The
weekly team meetings are going to be the main venue to control the overall
project. Additionally, the
weekly progress reports are going to be constructed and stakeholder communication will be
discussed and addressed during the team’s weekly meeting. The main mechanism for
communicating with the stakeholders will be via email and,

if needed, in person.

Page
26

of
37

Version Date: 04/12
/2012


PROJECT DEMONSTRATION



Our project demonstration consisted of an interactive demo of our Donator website. We chose this
option because it was

more

hands
-
on than a PowerPoint presentation, poster, or any of the other

traditional

typ
es of demonstration methods.
We had three group members participate in the demo,
each one representing a different community of interest (organization, donor, and person in need).
Our demo started
with
one of
our group member
sexplaining the problem our web
site is designed to
solve. We then went through an actual scenario of someone looking for an item, someone donating
an item, and the organization (and the website) facilitating the match between these two people. Our
demo ended with the donor receiving an
email confirmation

(which contained a thank you message
from the person in need)

on her phone that the person in need had picked up the item.


We were pleasantly surprised with
the response to our demo from the parents and prospective
students who stopped
by our table. They were engaged in the demo, and asked relevant questions.
The parents, especially, had indicated that our website would be very beneficial to actual
organizations. Although a seemingly simple feature, almost everyone who stopped by our tab
le was
impressed by the email notification and thank you message sent to the donor that showed up
immediately on her phone after the item had been picked up.


PROJECT SUMMARY STATEMENT


Our group was very impressed with what we were able to accomplish in
such a short amount of time.
Our functional website used in the demo was able to correctly facilitate a match between items that
were donated and what people in need were looking for. Our team did not run into too many problems
along the way. Perhaps the b
iggest problem was the loss and addition of a group member during the
middle of the project. We were required to adjust our team’s strategy to fill in the holes left by our
departed team member and play to the strengths of our added team member.


There wer
e a few lessons
we
learned
throughout working on this

project. First, we learned that it is
extremely important to have a w
eekly meeting outside of class to work on our deliverables and
discuss our ideas. Early in the project, we did not have a weekly meet
ing, and everything seemed to
be unorganized. After we started having weekly meetings, we were more organized and everyone
seemed to be on the same page. We also learned the importance of having group deadlines several
days before project deadlines so that

work could be reviewed in advance. For the first phase of the
project, we did not have a group deadline, and we were working on the project literally a few minutes
before the deadline. For the rest of the deliverables, because we had group deadlines, we c
ompleted
the phases well in advance, and had time to review and correct work with plenty of time before the
deadline. Group deadlines are also important when group members failed to do their assigned work
because it left time for someone else to step in an
d complete that section.







Page
27

of
37

Version Date: 04/12
/2012


APPENDICES

Appendix 1: WEEKLY STATUS REPORTS


Date:
1/26/2012

Time: 10:45am

Location: IST 206


Attendees
: Darrin Kirk, Kristen Glaser, AnastassiaIoujanina,
Eric Pap
a
marcos

Missing: Lucas Kozaczki (family emergency)


Discussion points:

1.

We discussed the project topic and decided to implement Eric’s individual project on a small
scale. This is a website that coordinates donations of items such as furniture and clothing with
centers such as Good Will.

2.

We also discussed t
eam technical capabilities and determined that Eric and Darrin would focus
mostly on the development work. Anastassia would help with the graphics needed for the site.

__________________________


Date: 2/7/2012

Time: 9:45
-
11:15

Location: IST 301A


Attendees: Darrin Kirk, Lucas Kozaczki, Eric Pap
a
marcos

Missing: Kristen Glaser, AnastassiaIoujanina


Discussion Points:

1.

We further discussed the functional design and exactly what/how we are going accomplish
with our application.

2.

We created a model of the

application and discussed the feedback we received for Phase 1

3.

Discussed when we can hold our weekly team meetings and preliminary responsibility and
team roles.


Plans for this week:

1.

Attend a pre
-
functional design review meeting on 2/9 from 8:45
-
9 AM

2.

Att
end functional design review 2/9 from 9
-
10 AM

3.

Attend post
-
functional design review meeting from 10
-
11 AM

4.

Make changes to Phase 1 based on feedback

____________________________


Date: 2/9/2012

Time: 9
-
10AM

Location: 108 IST

Attendees: Darrin Kirk, Eric Pap
a
marcos, Kristen Glaser, AnastassiaIoujanina, John Hill

Missing: Lucas Kozaczki


Page
28

of
37

Version Date: 04/12
/2012

Discussion Points:

1.

Discussed the functional design review and feedback

2.

Further developed and ironed out the plan of action for our application

3.

How our application makes the
community of interest more innovative

4.

How our application distinguishes itself from other similar solutions

____________________________


Date: 2/9/2012

Time: 10
-
10:30AM

Location: Fishbowl

Attendees: Darrin Kirk, Eric Pap
a
marcos, Kristen Glaser,
AnastassiaIoujanina

Missing: Lucas Kozaczki


Discussion Points:

1.

Discussed feedback from functional design review

2.

Discussed who should contact the TA for detailed grading feedback on first Phase 1
submission

3.

Our application’s name


Plans for this week:

1.

Team

meeting Monday morning at 108 IST 11:15am
-
12:30pm

____________________________


Date: 2/13/2012

Time: 11:15
-
12:30

Location: IST 108

Attendees: Darrin Kirk, Lucas Kozaczki, Eric Papamarcos, Kristen Glaser, AnastassiaIoujanina

Discussion Points:

1.

Discussed
the functional design revisions that need to be done

2.

Went through the TA and Prof. Hill’s feedback and how we can revise it

3.

Discussed the Literature section of the functional design review and how we can fully address
this section

4.

Looked at Goodwill, Red C
ross, Salvation Army website and discussed how their websites are
different from each other and how our tool would differentiate from what is already available

5.

Discussed the database construction and types of data we want to collect with our application

6.

Pl
an’s for the current week:

7.

Get the revision’s done by class time tomorrow morning at 9:45

8.

Meet with the TA and Prof. Hill tomorrow after class to discuss the feedback (if possible)


____________________________


Date: 2/20/2012

Time: 11:15
-
12:30

Location:
IST 108

Attendees: Lucas Kozaczki, Eric Papamarcos, Kristen Glaser, TylerLewkovich

Missing: AnastassiaIoujanina

Discussion Points:

1.

Introduced Tyler to the rest of the team

Page
29

of
37

Version Date: 04/12
/2012

2.

Discussed the Phase 1 resubmission

3.

Went over the plan of attack for the Technical De
sign Report

4.

Divided up the entire Technical Design Report

Plans for the current week:

1.

We are not meeting on class on Thursday

2.

Get assigned sections done by next Monday

3.

If you have any questions on your section
-

bring it to the meeting or email the group so we
can clarify.

____________________________


Date: 2/27/2012

Time: 11:15
-
12:30

Location: IST 108


Attendees: Lucas Kozaczki, Eric Pap
a
marcos, Kristen Glaser, Tyler
Lewkovich, AnastassiaIoujanina

Missing: None


Discussion Points:

1.

Chose a time slot for the technical design review that worked for the entire group


Monday,
March 12, 2012 from 10 AM


11 AM.

2.

Went through the technical design report and raised questions t
o the group about possible
problems encountered when writing assigned sections.

3.

Discussed clarifications and questions that need to be raised during class on Tuesday to
complete the technical design report.


Plans for the current week:

1.

Collaborate online a
nd during tomorrow’s class to finish the technical design review

2.

Option to meet during class period on Thursday

____________________________


Date: 3/12/2012

Time: 11:00am
-
12:30pm

Location: IST 108


Attendees: Lucas Kozaczki, Eric Papmarcos, Kristen
Glaser, Tyler Lewkovich, AnastassiaIoujanina

Missing: None


Discussion Points:

1.

What exactly what we wanted to accomplish during our live demonstration.

2.

Discussed the page layout/navigation of the website and website tabs.

3.

Discussed the relationship between

the organization/donor/”Joe” and how they interact with
each other and the website.

Planned Work for the Current Week:

1.

Eric
-

Design website forms

Anastassia
-

Logo and Header

Kristen
-

5 items, pictures, and descriptions

Luke
-

5 items, pictures, and d
escriptions

Page
30

of
37

Version Date: 04/12
/2012

Tyler
-

Home page with About information, Map, Address of IST Building

2.

Not me
eting in class on Tuesday 3/13
and Thursday 3/15

____________________________


Date: 3/19/2012

Time: 11:15am
-
12:30pm

Location: 106 IST


Attendees: Lucas Kozaczki,

Eric Papmarcos, Kristen Glaser, AnastassiaIoujanina

Missing: Tyler Lewkovich


Discussion Points:

1.

Reviewed logo designs

2.

Reviewed user input form design

3.

Finalized field names and options for different user input forms

4.

Discussed plans for poster


Plans for
the current week:

1.

Anastassia will finalize logo by end of the day

2.

Luke will draft a design for the poster

3.

Eric will continue work on the development of the website

4.

Kristen will take pictures of more items to fill the database

____________________________


Date: 3/26/2012

Time: 11:15am
-
12:15pm

Location: 106 IST


Attendees: Lucas Kozaczki, Eric Papmarcos, Kristen Glaser, Missing: Tyler Lewkovich,
AnastassiaIoujanina


Discussion Points:

1.

Discussed that Kristen had to design the log
o

2.

Discussed team member contri
butions and lacking contributions.

3.

Reviewed and tested the new additions to the website

4.

Demonstration Notes:



Kristen


Donor, Luke


Looking for, Eric


Organization for demonstration.



Luke is going to type his name to start the presentation



Eric is going
to have Kristen’s email pre copied so he can paste it, instead of typing it,
during

the presentation



There is no email notification as of now


will be added today. For the demonstration


we
are going to have a pre
-
sent email in case the notification fail
s



Possible tagline “Helping organizations match donors with people in need”



Plans for the current week:

Page
31

of
37

Version Date: 04/12
/2012

1.

Dry run through at 4:30PM on Wednesday March, 26th at IST outside the room (by the TVs)

2.

Eric is to send Luke image files for the poster to create the
poster.

3.

Pease try to be in class tomorrow for further discussions.

____________________________


Date: 4/2/2012


No meeting this week.


Plans for the current week:

1.

Eric will make corrections for the Final Report, and add in the remaining sections.

2.

Eric wil
l send out a draft of the Final Report.

3.

Group members will make any necessary corrections to the Final Report.


Appendix 2: EXTERNAL COMMUNICATIONS

There was no communication with any
non
-
student project team members
.


Appendix 3: GLOSSARY

IT = Information

Technology

Google Docs = a free, web
-
based office suite

Dropbox = a web
-
based file hosting service


Appendix 4: TEAM CONTRACT

Team Name: 31

Course/ Section: IST 440W Section 3

Project Team Members Names and Sign
-
off

A team leader is:



Responsible for
managing the group project, beginning with a work plan that includes a topic selection and
responsibility matrix. Creating a communication plan may be as simple as coordinating email or an Angel
group. The leader also may schedule meetings (live or virtual
) and mediate member performance.



Primary liaison with instructors, including posting milestones to Angel dropboxes.
Note that each team
member is free to meet with the instructor
.



Member Name (Print)


Contact Information

Member Signature

Acknowledging
Compliance


Eric Papamarcos

eap
194@
psu
.
edu

Eric Papamarcos


Kristen Glaser

keg
5141@
psu
.
edu

Kristen Glaser

Page
32

of
37

Version Date: 04/12
/2012


Lucas Kozacz
ki

ljk
191@
psu
.
edu

Lucas Kozaczki

Tyler Lewkovich

ljk191@psu.edu

Tyler Lewkovich

AnastassiaIoujanina

aii
1@
psu
.
edu

AnastassiaIoujanina

Code of Conduct
-

Three Strike Policy

We agree to:



Communicate

at a minimum frequency of a weekly basis through email and/or telephone to keep all team
members up to date with project work, and



Participate

actively in weekly meetings, and



Make sufficient effort

to complete the project, on time, and on scope, and



Allocate work equally

among team members, and



Confront

each other to resolve any conflicts within our team, and



Authorize

our team leade
r to inform our instructor in the case any conflict escalates out of control, and



Notify

all team members, in advance, if a team member cannot:



participate in a meeting, or



complete an assigned task on time.



Honor and respect

all university rules and regulations.


Participation

We agree to:



Check

emails daily and in order to not miss important emails regarding the group project coming from
other team members.



Respond

each time an email is received from a team member, so that t
here is no doubt whether the email
was received.



Allocate

the work equally among the team members.



Allow

the team leader to set due dates with agreement from the other team members.



Monitor
, at each meeting, the work that was due from each team member at t
hat meeting.



Exchange and review

the work done by all other team members.



Discuss

work that is not up to group expectations.



It is the contributor’s responsibility to revise his/her work to be satisfactory by the next night, and he/she will
then distribute

the improved work to all team members at that time.


Division of Work

We agree to:



Allocate

work roughly equally between all members. NO one person should complete an entire
assignment.



Set and meet

deadlines that allow review and edit of all documents b
y all team members.

Page
33

of
37

Version Date: 04/12
/2012



Monitor

all project activities to assure that each member works on for every assignment to ensure that no
one is doing more or less than others.

Communication

We agree to:



Use Email

for our daily communication skills, however for more s
erious issues we will schedule face to
face meeting times.



Use GoogleDocs
for discussing group deliverables along with the actual documents.



Assure

the exchange of all documents to all team members so the entire team is fully informed.

Meeting Guidelines

We

agree to:



Create

and fill out a doodle document to establish a meeting time that is acceptable for all.



Work together

to make sure we accomplish all that need to be done at our meetings.



Record

the agreements reached concerning important dates and assignm
ents agreed during team
meetings.
























Page
34

of
37

Version Date: 04/12
/2012

Appendix 5: DATA DICTIONARY


This section contains a listing of the data items used by the application, and specifies the data type of
each data item.


Schema:


Table: ITEM

Column Name

Data Type

Size

Nullable

Key

item_id

int


No

PK

subtype_id

int

20

No

FK

item_desc

varchar

255

No


item_size

varchar

64

Yes


item_color

varchar

32

Yes


condition_id

varchar

10

Yes


availability_id

int


No

FK

pic_name

varchar

24

Yes




Table:ORGANIZATION

Column
Name

Data Type

Size

Nullable

Key

org_id

int


No

PK

org_name

varchar

64

No

UK

org_description

varchar

128

No


org_address_1

varchar

128

No


org_address_2

varchar

128

Yes


Page
35

of
37

Version Date: 04/12
/2012

org_city

varchar

128

No


org_state

char

2

No


org_zip

varchar

10

No


verify_status_id

int


No

FK



Table:VERIFY_STATUS

Column Name

Data Type

Size

Nullable

Key

verify_status_id

int


No

PK

verify_status_desc

varchar

15

No




Sample Data:


ITEM_TYPE

type_id

type_name

1

Clothing

2

Furniture

3

Small Appliance



ITEM_SUBTYPE

subtype_id

subtype_name

type_id

1

Winter Jacket

1

2

Sweatshirt

1

3

Table

2

Page
36

of
37

Version Date: 04/12
/2012

4

Couch

2

5

Microwave

3



ITEM

item_id

subtype_id

item_color

item_size

item_desc

condition_id

available_id

pic_name

1

1

Blue and
White

Adult XL

Starter Jacket
with Penn State
Logo

2

1

img001.jpg

2

2

Grey

Youth
Medium

Nike swoosh with
"Just Do It"

4

1

img002.jpg

3

3

Cherry Oak

48" x 24" x
36"

Dining room table
and 4 chairs

3

2

img003.jpg

4

3

White

24" x 18" x
24"

Night Stand table

3

1

img004.jpg

5

4

Green

(null)

Sectional with
recliner

3

2

(null)

6

5

Silver

1.1 Cu. Ft
-

1100 Watt

GE Microwave
only 1 year old

4

1

(null)



CONDITION

condition_id

condition_name

1

Poor

2

Fair

3

Good

4

Excellent




Page
37

of
37

Version Date: 04/12
/2012

AVAILABILITY

available_id

availability_desc

1

Available

2

Unavailable