Running Head: LAB I – uRai$e PRODUCT DESCRIPTION 1

advertisement
Running Head: LAB I – uRai$e PRODUCT DESCRIPTION
Lab I – uRai$e Product Description
Wayne M Stilwell
Old Dominion University
Janet Brunelle
Version 3
1
LAB I – uRai$e PRODUCT DESCRIPTION
2
Table of Contents
1
INTRODUCTION ................................................................................................................... 3
2
uRai$e DESCRIPTION ........................................................................................................... 4
3
2.1
Key Product Features and Capabilities ............................................................................ 4
2.2
Major Components (Hardware/Software) ........................................................................ 6
2.3
Target Market/Customer Base ......................................................................................... 8
uRai$e PROTOTYPE DESCRIPTION ................................................................................. 10
3.1
Prototype Functional Goals and Objectives ................................................................... 10
3.2
Prototype Architecture (Hardware/Software) ................................................................ 13
3.3
Prototype Features and Capabilities ............................................................................... 14
3.4
Prototype Development Challenges ............................................................................... 16
GLOSSARY ................................................................................................................................. 18
REFERENCES ............................................................................................................................. 20
List of Figures
Figure 1. Major Functional Component Diagram ...........................................................................7
Figure 2. Revenue of Nonprofit Organizations ...............................................................................9
Figure 3. Prototype Major Functional Component Diagram.........................................................14
List of Tables
Table 1. Algorithms in the Prototype .............................................................................................11
Table 2. Features of the Prototype .................................................................................................15
LAB I – uRai$e PRODUCT DESCRIPTION
3
Lab I – uRai$e Product Description
1
INTRODUCTION
America is in the middle of a financial crisis. The United States Bureau of Labor
Statistics (2011) reported that the national unemployment rate was 9.0% in January 2011. In
other words, nearly one out of every ten Americans capable of working did not have a job.
Banks are also repossessing homes at high rates. In the first quarter of 2010, banks repossessed
close to 258,000 properties. This was a 35% jump from the first quarter of 2009. Then, in the
second quarter of 2010, almost 270,000 homes were repossessed. In comparison, 38% less
homes were taken in the same quarter a year earlier (Lazo, 2010). With citizens struggling to
make ends meet, charities are unable to meet their financial goals. In 2009, there was a 3.6%
decline in total giving. This was the biggest drop in over fifty years (National Park Service,
2010). Contributions to colleges dropped 11.9% that same year, the greatest decline in
university giving ever recorded (Council for Aid to Education, 2010).
Smaller nonprofit groups are finding it difficult to meet their financial objectives. On top
of the economy and donations being down, traditional methods of fundraising are very
ineffective. Nonprofits risk annoying potential donors by telemarketing and going door-to-door.
Also, sometimes charities limit their audience to a certain geographic area. When groups stand
outside in a public location, like the Salvation Army, only people passing by are able to donate.
When charities go around neighborhoods, the only potential donors are the residents in those
areas. Another big issue is that many of these traditional styles of raising money are cash or
check only. People who solely carry credit or debit cards for safety reasons do not get the
opportunity to give to such fundraisers.
LAB I – uRai$e PRODUCT DESCRIPTION
4
uRai$e is a web-based fundraiser management system. It allows donors to contribute to a
nonprofit organization (NPO) any time of the day from any location, and it gives NPOs a wider
audience by integrating with social networks. The system also accepts gifts via text messages
over the Short Message Service (SMS). The primary goal of uRai$e is to maximize donations
for smaller NPOs who cannot afford the overhead involved in traditional fundraising schemes.
These less profitable NPOs make up the majority of uRai$e’s target customer base. This is due
to the system’s ability to lower fundraising costs. uRai$e reduces overhead by sending thank
you letters, generating IRS reports, and cutting advertising fees.
2
uRai$e DESCRIPTION
To attract NPOs, uRai$e tries to lower the cost of advertising and helps groups reach the
largest number of donors possible. Utilizing the Internet lets donors give anytime, anywhere.
Taking advantage of social networks ensures that more people hear about fundraisers. Targeted
notifications make sure the people who do hear about the fundraisers are actually interested in
them. Accepting mobile donations gives donors a quick and easy way to give to causes they care
about.
2.1
Key Product Features and Capabilities
Philanthropists wanting to donate through uRai$e can do so by registering on the uRai$e
web site. Donors sign up for uRai$e at no cost. After creating an account, they then setup their
donor profile. The profile allows the donor to customize their experience with uRai$e. First,
donors can add (or “tag”) NPOs and causes they are interested in donating to. They begin by
typing the name of the NPO or cause in a text box, and a list of matching results appear that the
donor can select from. Donors also save their notification preferences in the profile. They can
pick how frequently, if at all, they wish to be emailed by NPOs.
LAB I – uRai$e PRODUCT DESCRIPTION
5
On the other hand, NPOs wishing to join uRai$e must first be verified to be registered
with the IRS. This is done by querying the IRS database with a unique tax identification number
the NPO will supply. If the NPO is valid, uRai$e will charge them a monthly fee. NPOs may
create a fundraiser in uRai$e and tag it with descriptive keywords. uRai$e then matches the
keywords with donor interests, and any donors who may like this fundraiser are notified (if their
notification preferences allow it). Donors may also see the new fundraiser on the website, under
a list of suggested fundraisers.
uRai$e will provide a search page so users can query for fundraisers. Another way for
donors to find fundraisers is through social networks. Twitter and Facebook give NPOs the
potential to reach millions of people. Each time a NPO creates a new event, uRai$e will
automatically post a tweet on their Twitter page. Their followers will see this in their feed and
be able to follow a link to the fundraiser’s page on the uRai$e site. uRai$e will also notify
Facebook friends of the NPO by a wall post. People will be able to make a donation on
Facebook without ever having to come to the uRai$e website. Users wishing to do this will have
to install the uRai$e application. People who give through Facebook will only be able to donate
via credit card. uRai$e will process Facebook donations the same way it processes credit card
donations on its own site. This is because the Facebook application is essentially just web pages.
Along with targeted notifications and social networking, the other innovative aspect of
uRai$e is the ability to accept mobile donations. Every fundraiser will have a unique
identification number. People can donate by sending a text to uRai$e with the identification
number in the message. uRai$e will respond with a verification message to make sure the
message was not sent in error. At this time, mobile donations can only accept gifts in multiples
of five dollars. So if the user confirms, five dollars will be added to their phone bill. uRai$e will
LAB I – uRai$e PRODUCT DESCRIPTION
6
use BilltoMobile to handle the money exchange with the donor’s phone carrier. BilltoMobile
will charge the carrier, and the carrier will add the donation to the donor’s monthly bill. After
the next billing and payment period, BilltoMobile will send the money from the carrier to
uRai$e.
For every donation, the user will receive a unique confirmation, or “tracking” number.
With this number, the donor can check the current status of their donation on the uRai$e website.
If their donation was done via SMS, they will also have the option to cancel their donation and
have it removed from their phone bill. Refunds are only available on mobile donations because
it can take two to three months before an NPO gets those funds. Credit card gifts processed on
the uRai$e site exchange funds far more rapidly, so those donations cannot be canceled.
uRai$e reduces overhead by automatically generating tax forms, thank you letters, and
account summaries. uRai$e creates tax forms for both donors and NPOs. Members can log in to
the website and generate this form at any time. However, every January, uRai$e will email
members a link to the site to pull the tax information for the previous year. Once funds have
successfully transferred to the NPO, uRai$e will automatically send a thank you letter to the
donor for their contribution. This “thank you” is in addition to a confirmation email the donor
will receive, letting them know their donation is being processed. When a gift is finished
processing, it will appear in the donor’s account summary. Account summaries are accessible
from the donor profile. The summary shows a breakdown of what types of NPOs a donor gives
to and how much they give to each type. Donors can use this to review their giving habits.
2.2
Major Components (Hardware/Software)
At the core of uRai$e is its database, which has numerous tables such as donor
information, NPO information, fundraisers, interests, accounts and so forth. The front end for
LAB I – uRai$e PRODUCT DESCRIPTION
7
the database is the website. These are both hosted on Google’s App Engine, which meets
Payment Card Industry standards. That means it is secure enough to legally store sensitive
information such as credit card numbers.
There is also an SMS server for accepting mobile donations. This information is then
forwarded to the mobile carrier to add the donation to the user’s cell phone bill. People can
utilize a Facebook application to make donations to uRai$e without ever visiting the site. NPOs
also have the ability to post Twitter updates through uRai$e, and tweets are automatically posted
each time they create a fundraiser.
Figure 1. Major Functional Component Diagram
LAB I – uRai$e PRODUCT DESCRIPTION
8
The site is not hosted on a traditional server and instead takes advantage of cloud
computing. In the cloud, there are several engines that drive the uRai$e system. The fundraiser
suggestion engine presents donors with fundraisers they may be interested in when they visit the
website. This is based off of keyword interests they enter or “tag” in their profile. The alerts
services engine notifies donors of new fundraising events. The credit card engine charges a
donor’s card when they give on the website. The mobile donation engine handles donations via
SMS. The bank engine ensures that once uRai$e has the funds from the donor, they are
deposited into the correct NPO bank account. The presentation layer relies on these engines to
interact with users. The presentation layer includes the uRai$e site, the Facebook application,
and the web services that let uRai$e communicate with Facebook and Twitter.
Business rules for the system are stored in the business rules application logic. These
rules derive from the objects in the business objects domain model. The data access layer
ensures users only see information intended for them. For example, NPOs should not be able to
update a donor’s profile. Checking business rules and the data access layer helps maintain the
integrity of the uRai$e database. The uRai$e database will store all information related to
fundraisers, donations, NPOs, and donors. The fundraiser suggestion data warehouse temporarily
stores information for the fundraiser suggestion engine each time the engine is activated.
2.3
Target Market/Customer Base
Larger NPOs such as the American Red Cross have less trouble raising money. The
current fundraising systems these NPOs already have in place are effective for them. For this
reason, uRai$e will target the smaller groups. These organizations need to maximize their
income, and simultaneously lower the overhead involved in the fundraising process. The Urban
Institute released a fundraising survey for the first nine months of 2010. They found that almost
LAB I – uRai$e PRODUCT DESCRIPTION
9
a fourth of charities, 22%, were forced to use volunteers in what used to be paid positions. This
was a seven percent increase from the same period in 2009. They also discovered that the more
money a group spent, the more likely they were to report an increase in donations. This suggests
that the smaller nonprofits are struggling to meet their financial objectives (Urban Institute,
2010).
Revenue of Nonprofit Organizations
August 2010
800,000
700,000
600,000
500,000
Number of
Registered 400,000
Organizations
300,000
200,000
100,000
0
< $100K $100K - $250K - $500K $249K $499K $999K
$1M $5M
$5M $10M
$10M $100M
> $100
M
Level of Total Revenue
Figure 2. Revenue of Nonprofit Organizations
The National Center for Charitable Statistics reports that there are over 1.6 million
nonprofit organizations that are registered with the Internal Revenue Service (IRS). In order to
register with uRai$e, an NPO will be required to give a tax identification number that can be
verified with the IRS. Once they are setup on uRai$e, this verification will also occur each time
the NPO creates a new fundraiser. Data in Figure 2 shows that the majority of registered NPOs
LAB I – uRai$e PRODUCT DESCRIPTION
10
are the type that uRai$e will target. Of the 1.1 million groups that reported their revenue, almost
800,000 brought in less than $100,000 (National Center for Charitable Statistics, 2011).
3
uRai$e PROTOTYPE DESCRIPTION
The prototype for uRai$e will demonstrate the essential features of the system. The
prototype will use Old Dominion University (ODU) as a case study. It will focus on raising
money for scholarships and various groups across campus. Some features are either left out or
not fully implemented in the prototype due to time and budget constraints. This section explains
what will be included in the prototype, how it will differ from the real world product (RWP), and
why there are differences between the two.
3.1
Prototype Functional Goals and Objectives
The prototype will show how the end systems of the RWP will work together by using
simulations and pre-populated data. The goal is to prove that the concepts that make uRai$e
innovative can be done and can work together. Another objective is to show the intuitiveness
and ease of use of the website and Facebook application. NPOs should be convinced that the
system will help them raise more money and reach more potential donors in a way that is easy
and cost-effective.
The prototype addresses risk mitigation by making several assumptions, the first being
that the hosting server will not go down. It will be up at all times and users can visit the website
at any time. Another big assumption is that all communication with uRai$e is done securely.
When a user makes a donation on the site or when funds are being exchanged, personal
information will not be compromised. It also assumed that money transfers are efficient and that
no funds are lost. All transactions will be completed, and uRai$e will not process refunds for the
prototype. Only credit cards and mobile donations will be accepted forms of payment. This is
LAB I – uRai$e PRODUCT DESCRIPTION
11
also true in the RWP. The prototype assumes that the IRS database of registered NPOs is always
available, and always updated. This is to prevent a NPO who has expired with the IRS from
scamming innocent donors. Finally, and maybe most importantly, the prototype presumes that
banks and cell phone companies are willing to work with uRai$e.
Some things in the prototype should work as they would in the RWP. For example,
logging in to the site, sending donor notifications, creating fundraisers, searching fundraisers,
and retrieving an account summary will all be fully functional. Other features will be reduced or
simulated. Since the prototype will have less fundraisers and less donation histories to data
mine, the algorithms for suggesting fundraisers and calculating a donor’s interest will be
simplified, as shown in Table 1. The prototype should be able to send and receive SMS
messages from donors and update a dummy database to simulate a mobile donation. Checking
for legal NPOs and showing the transfer of funds through uRai$e will also utilize dummy
databases, but the process in which they work will be similar to the RWP.
NAME
RWP
Membership/donor Organizations and
verification
donors login to the
site with a user
name and
password.
Fundraiser
suggestion
PROTOTYPE
INPUT
OUTPUT
Fully functional
Username,
password
Boolean flag
(valid user/
not valid
user)
Donor ID,
donor tags,
donor history,
donor table,
donation
history table,
fundraiser
table
List of
fundraisers
Pull fundraisers that Only show
match a donor’s
fundraisers that
tag, that donors
match a donor’s tag.
with similar tags
donate to, and that
donors with a
similar history give
to. Pull the top
fundraisers using
interest rankings.
LAB I – uRai$e PRODUCT DESCRIPTION
12
NAME
RWP
PROTOTYPE
INPUT
OUTPUT
Mobile donation
Integrate with cell
phone carriers to
charge donation
expense to the
donor’s cell phone
bill.
Simulate the cell
phone carrier
integration with
scripted results and
test data.
SMS text
donation
message
SMS text
confirmation
message
Process incoming
Facebook requests
Handle HTTP
requests from
Facebook to
provide fundraiser
search results and
route credit card
payment requests to
the payment
algorithm.
Fully functional
REST HTTP
requests
JSON and
XML
encoded
result sets
Automate tax
forms
Generic tax form
for printing.
Fully functional
Tax form ID
Tax form
Thank you letters
Automated email
sent after donation
is received or letter
generated to be
printed.
Fully functional
Donor ID
Thank you
letter
Charge credit card
Use credit card
information to send
allotted funds to
organization.
Simulate the use of
a credit card to
donate to an
organization.
Credit card
and donor
information
Charge
confirmation
Create fundraiser
Organization is
verified, then
information with
target goal is input.
Fully functional
Database of
verified
organizations,
tax ID
Fundraiser
created
message
Calculate interest
rank
Ranks fundraisers a
donor may like
based on tags and
similar donors’
donation history.
Primarily focus on
tags. The more
matching tags a
fundraiser has for a
donor, the higher it
will rank.
List of
fundraisers,
how the
fundraiser
was pulled
List of
fundraisers
ordered based
on a donors
interests
LAB I – uRai$e PRODUCT DESCRIPTION
13
NAME
RWP
PROTOTYPE
INPUT
OUTPUT
Determine legal
fundraisers
Integrate with IRS
services to verify
the organizations
nonprofit status.
Simulate the IRS
integration by
validating
organization’s
nonprofit status
using an internal
data.
IRS verified
organizations
Boolean flag
(legal/not
legal)
Organization
requests fund
Organization would
request fund then
uRai$e would
deliver them to
verified bank
account.
Simulate the fund
going from uRai$e
to organization’s
bank account.
Organization
ID, fundraiser
ID, bank
account info
Flag stating
that fund
transfer was
successful
Account summary
Generate a page
with the complete
history of a donor’s
transactions.
Fully functional
Donor ID
Summation
of transaction
history
Table 1. Algorithms in the Prototype
3.2
Prototype Architecture (Hardware/Software)
To develop the prototype as similarly to the RWP as possible, the prototype will also be
developed on Google’s App Engine. The web pages in the prototype, as in the RWP, will be
written with Java, PHP, XHTML, CSS, JavaScript, and jQuery. To prevent real money from
being transferred in the prototype, a MySQL database on an ODU Computer Science (CS) server
will have dummy tables for bank accounts and mobile carriers. To simulate money changing
hands, specific rows in the dummy tables will be updated accordingly.
[This space intentionally left blank.]
LAB I – uRai$e PRODUCT DESCRIPTION
14
Figure 3. Prototype Major Functional Component Diagram
Figure 3 shows the major functional components of the prototype. Both credit card and
mobile donations will be simulated from an ODU CS workstation. The workstation will have a
cell phone emulator installed to demonstrate giving via SMS. It will also have various web
browsers to handle different ways users may access the website. With the website NPOs will be
able to post tweets to Twitter like in the RWP. This is done via JavaScript and web services. An
application to handle credit card donations from Facebook will be developed in PHP. The
application will not actually accept payments in the prototype in the event someone stumbles
across it and thinks it is real.
3.3
Prototype Features and Capabilities
The features of the prototype are described in Table 2. Suggesting fundraisers, posting
updates to Twitter, and compiling transaction histories will all be fully functional in the
prototype. The user profiles for donors and NPOs will essentially be fully functional, as well.
The only difference is that they will run off of fake data in pre-generated tables.
Sending donations through SMS will be done through an emulator. This is for
demonstration purposes and to reduce the amount of hardware needed. During the
LAB I – uRai$e PRODUCT DESCRIPTION
15
demonstration of the prototype, audience members will be able to send fake SMS donations and
see their contribution populated in a fake table. uRai$e will not actually charge five dollars to
their cell phone bill, but the audience will still be subject to their carrier’s messaging rates.
Credit card donations will be simulated because paying with a card online is not an
innovative aspect of uRai$e. Sending notifications will work in the prototype, but with a fake
table of donors. A Facebook application will be developed, but it will not accept real payments
in the prototype. This is to prevent somebody from mistaking uRai$e for a real organization.
The prototype will be able to generate all the required data for thank you letters and tax forms.
Creating dynamic HTML forms to simulate IRS tax forms will take more time than is available
this semester. Although available in the prototype, they will not be as attractive as in the RWP.
Features
Real World Product
Prototype
Fundraiser
suggestion
A fundraiser will be
Fully functional.
suggested to a donor based on
their interests.
Mobile donation Donors will be able to send Simulated with the use of a cell phone
funds through a text message. emulator.
Donate with credit Donors can send funds with
card
the use of a credit card.
Simulated with fake credit card information.
Send notifications Fundraiser administrators
will have the ability to send
notifications of a fundraiser
to registered donors.
Simulated with a created database of users.
This will be simulated by showing a created
fundraiser sending a notification to the users.
Facebook
integration
Donors will be able to donate A Facebook application will be developed,
through the uRai$e Facebook however the donations to a fundraiser may
Application. Organizations have to be simulated.
will be able to post news and
new fundraiser through the
Facebook Application.
Twitter
integration
Organizations can post news Fully functional.
to their Twitter account
through uRai$e.
LAB I – uRai$e PRODUCT DESCRIPTION
16
Features
Real World Product
Donor profile
Donors will be able to view The donor profile will be fully functional
donation history, search
except that the search function will contain a
based on interests, add/delete simulated database of fundraisers.
interests, track fundraisers,
and edit their information.
Nonprofit
organization
profile
Organizations will be able to
send notifications, view
fundraiser progress, view
donations, and request funds.
There will be a simulated view in which there
are no real funds. The profile will still allow
the use of sending notifications, viewing
progress, and viewing donations.
Automate tax
forms and thank
you letters
When a donor sends funds,
an administrator can
automatically send a thank
you letter and tax form.
The tax form will not be as aesthetically
pleasing in the prototype, but will still contain
all required information.
Compile a
transaction
history
Prototype
Generates a report for a user Fully functional.
that contains a transaction
history over a set period of
time.
Table 2. Features of the Prototype
3.4
Prototype Development Challenges
The Yellow Team will encounter a few challenges while implementing the prototype.
The biggest may be creating the site on Google App Engine. Of the team members who have
experience in web development, only one has experience with the App Engine. Also, Google
uses Big Table for its database. The majority of the team members are more familiar with
relational databases, which Big Table is not. This will present some problems when it comes
time to setup the backend. The group may find it easier to use a traditional LAMP environment
for the prototype.
Handling SMS communication may also prove to be a little difficult. First the group will
need a number for people to text to. They will also need a SMS server or SMS gateway to
handle the sending and receiving of text messages. The prototype then needs to be able to
correctly communicate with donors. For example, it would first send a message asking if they
LAB I – uRai$e PRODUCT DESCRIPTION
17
did in fact want to donate. Depending if the donor confirms or denies, it must then send a
different response back and proceed with the donation if the user confirmed.
Many of the group members have little to no experience in dealing with web services.
This knowledge is vital in implementing the Facebook application. In order for uRai$e to
retrieve donation information from Facebook, web services have to be set up so that uRai$e and
Facebook can communicate with each other. Without them, the application will not work.
Varying experience with web development among group members could also be interesting.
Those who are the best at implementing user interfaces will, ironically, be better suited to
develop the backend. It will be easier for inexperienced members to learn how to make web
pages than learn the stuff behind the scenes, not to mention that setting up the backend of the
website goes more smoothly when that person understands how HTML forms work.
Demonstrating the transfer of money is another challenge for the group. The team will
not be using real money or real bank accounts. No actual cell phone carriers are involved, either.
The prototype also does not utilize BilltoMobile, which handles the exchange of money between
cell carriers and uRai$e. It will be difficult to show how money can be reliably and efficiently
moved from uRai$e to the NPOs, or from the phone carriers to uRai$e. Receiving money from
the donors when they use their credit cards will not be an issue though, as this is not innovative
and many sites already do this.
LAB I – uRai$e PRODUCT DESCRIPTION
18
GLOSSARY
Administrator- The member of a nonprofit organization who logs into uRai$e and maintains
fundraisers. In other words, an uRai$e user for a nonprofit organization.
Alert- An email, text message, or social network update that notifies donors of new fundraisers.
Cloud computing- Platform where web applications are hosted on virtual web servers over the
Internet.
Database- A system that stores information, often in tables.
Data interface- A visual interpretation of the information stored in a database.
Donor- A person who wishes to help a particular cause through monetary gifts.
Extensible Markup Language (XML)- Used to store and transport data between applications.
Fundraiser- An event to raise money for a certain cause.
Graphical User Interface (GUI)- The visual aspect of a computer program that end-users interact
with.
Hypertext Transfer Protocol (HTTP)- The means by which data is transferred across the Internet.
Internal Revenue Service (IRS)- Federal agency responsible for enforcing tax laws.
JavaScript Object Notation (JSON)- A human-readable format of exchanging data over a
network.
Major Functional Component Diagram (MFCD)- A figure that shows how the main pieces of a
software system work together.
Member- A donor or nonprofit organization that has signed up with uRai$e.
Mobile carrier- A company that provides cell phone service to its customers, like Verizon.
Mobile donation- A monetary gift that is sent by a SMS text message. The amount the donor
gives is added to their cell phone bill, and the receiving party gets the money after the
following billing cycle.
Nonprofit organization (NPO)- A group, like a charity, that raises money to achieve some goal.
They do not raise money to get rich.
Overhead- Variable expenses for a business that can be limited.
LAB I – uRai$e PRODUCT DESCRIPTION
19
Payment Card Industry (PCI) standards- A set of security guidelines for companies that process
or hold credit card information.
Representational State Transfer (REST)- A style of software architecture for large systems that
utilizes the protocols of the Internet.
Real world product (RWP)- Refers to the final uRai$e product that would be sold if it were
developed.
Social network- Online community where people communicate with one another.
Secure Sockets Layer (SSL)- Protocol that provides communication security over the Internet.
Short Message Service (SMS)- Text message communication.
Tag- A keyword that either describes a fundraiser, or something that a donor is interested in
giving to.
Web server- In this context, a computer that contains all of the files for a web site and allows the
site to be accessible over the Internet.
Web service- A way for two devices to exchange data over the Internet.
LAB I – uRai$e PRODUCT DESCRIPTION
20
REFERENCES
Bureau of Labor Statistics. (2011, February 4). Employment Situation Summary. Retrieved from
http://www.bls.gov/news.release/empsit.nr0.htm
Council for Aid to Education. (2010, February 3). Voluntary Support of Education 2009 Press
Release. Retrieved from http://www.cae.org/content/pdf/VSE_2009_Press_Relsease.pdf
Lazo, Alejandro. (2010, July 15). U.S. home foreclosures reach record high in second quarter.
Los Angeles Times. Retrieved from http://articles.latimes.com/2010/jul/15/business/la-fiforeclosures-20100715
National Center for Charitable Statistics (2011). NCCS All Registered Nonprofits Table Wizard.
Retrieved from http://www.nccsdataweb.urban.org/tablewiz/tw_bmf.php
National Park Service. (2010). Giving Statistics. Retrieved from
http://www.nps.gov/partnerships/fundraising_individuals_statistics.htm
Urban Institute. (2010, November 29). The Nonprofit Research Collaborative: November 2010
Fundraising Survey. Retrieved from http://www.urban.org/publications/1001467.html
Download