Purpose

The goal of this semester-long project is to give you a thorough understanding and appreciation for building a large software system within a team. Throughout the semester, you will be faced with many decisions - many of which have no "right" answer, just consequences for your work later on.

Project Goals

The primary goal of this project is to show how the individualized act of programming can be transformed into a large need maintained by a team of engineers. We'll walk you through the whole software development life cycle, which means looking deeper at each step.

That said, you'll also learn a lot of web development along the way. There's no better way to learn something than to practice it.

We're asking you to work with some industrial-strength web application frameworks. We believe that this will give you a very valuable experience as a full-stack developer using tools and technologies that you are likely to experience in a professional environment.

Think of the technical documentation as another one of your textbooks. For example, the Spring guides and the Angular docs. These sources will have a lot more information than you need, but you're expected to consult them first whenever you need something. Thus, beyond our startup tutorials, we will not hold your hand. We will give you broad overviews and wisdom, but the project itself will involve learning on the fly - which is a skill in and of itself.

"Need" Overview

There are so many none-for-profit organization around the globe with unmet needs and few ways to connect them with those who can help. Each organization faces unique challenges based on their area of expertise, their vision for a better future and the changing environments in which they operate. There are many types of needs which are unique to each organization. Some for example may have needs for physical goods, whereas others may be looking for purely monetary support; others may require volunteers to labor on a project or skills from someone to help make it possible. Independent of their needs and types of needs each organization will always have a collection of them (a "Cupboard"). This cupboard not only reflects the types and size of those needs but also the current circumstance (e.g. some needs may yet to be met, others have been "fulfilled".
Because of the lack of expertise in software development and unique customization, many organizations opt for acquiring software that is crafted to their needs, instead of a pre-fabricated platform like Go-fund-me or Fundly. That's where we come in.

MVP Features

The Product Owner desires a minimal viable need (MVP) which includes these features:

  • Minimal Authentication for Helper/U-fund Manager login & logout
    • The server will (admittedly insecurely) trust the browser of who the user is. A simple username to login is all that is minimally required. Assume a user logging in as admin is the U-fund Manager.
    • You are not expected to do full credential and session management, although the system will look different depending on who is logged in. Obviously this isn't how things are done in real life, but let's sidestep that complexity for this class.
  • Helper functionality
    • Helper can see list of needs
    • Helper can search for a need
    • Helper can add/remove an need to their funding basket
    • Helper can proceed to check-out and fund all needs they are supporting
  • Needs Management
    • U-fund Manager(s) can add, remove and edit the data of all their needs stored in their needs cupboard
    • A U-fund Manager cannot see contents of funding basket(s)
  • Data Persistence
    • Your system must save everything to files such that the next user will see a change in the needs cupboard based on the previous user's actions. So if a Helper had something in their funding basket and logged out, they should see the same needs in their cupboard when they log back in.
    • Ordinarily, we would want to use a database for this - but this semester our system will not reach a complexity that requires a database. You learned basic file I/O in your programming courses, so utilize what you know from there.
  • Your 10% additional feature enchantment(s)
    • Your team will propose this to your instructor by end of Sprint 1, and then build it into your solution as the semester progresses. See below for more details.

NOTE: The Product Owner reserves full control over the details of operation for MVP. This Vision Document includes no details of the specific u-fund. It is the responsibility of the team to collaborate with the Product Owner to obtain an understanding of those details. The team does not have the prerogative to define the details of operation or user interface experience without consulting with the Product Owner

Any time that the team asks itself the question, "How should X operate?" where X is some aspect of the u-fund app, and the team itself can not answer that question, they must ask the Product Owner. For best possible information exchange between all stakeholders including the team, comply with the use of the Communications Platform chosen for this purpose by your Product Owner (e.g. Slack).

You will need to choose your small non-for-profit organization. Think of a culture, a person, a location, a cause, or a current known need where you as a team would like to make a difference. . Good possible examples for none-for-profits that could benefit from this project:

  • A nationwide disaster recovery relief organization that handles natural catastrophies and connects providers with the people affected.
  • A Delaware fishing cooperative that manages distribution of their collective catch to its members in an equitable way and with participants having different needs at regular established intervals.
  • A Rochester faith-based organization that aggregates donations and meets different types of necessities from basics for the marginalized individuals, to needs from a specific neighborhood or community group.
  • A nature preservation society headquartered in California, that coordinates efforts to upkeep and maintain a variety of nature trails and campsites in the country.
  • An elderly care facility in Troy, NY that provides regular activities for their residents focusing on their physical and mental wellbeing.

These are examples of bad choices:

  • Gofundme clone. Too big.
  • A web development contractor service. Too meta.
  • General-purpose content management system for any set of needs. Not unique enough.

Your 10% feature enhancement(s)

[NOTE: You must seek approval from your Product Owner but understand this will be ambiguous initially and a final decision may only be possible until your work on Sprint 2 is nearing completion. Avoid spending time on "bells and whistles" before completing a robust MVP.]
Your 10% feature enhancement(s) needs to be complex enough to be useful to the unique chosen organization. The feature enhancement(s) need to reflect a custom workflow.
Using the examples above:

  • In the nationwide disaster recovery relief organization the concept of location may be required to properly funnel help. There may be bundles of needs like health kits or survival supply bags that are considered a grouping of needs
  • For the Delaware fishing cooperative it would have to accomodate management of multiple vessels at each port participating in the cooperative. Addressing operating needs that require costly and frequent maintenance and repair. With equipment that varies depending on intended catch and which present additional challenges (for example broken netting, cleaning crews and dispensary).
  • The scenario involving the Rochester faith-based organization. You would identify and sort higher priority, time sensitive or most frequently needed items. Establish means to sort and bundle basic needs like food, clothing and toiletries. This could expand to neighborhood beautification services and many other types of volunteering activities.
  • In the nature preservation society the trails vary significantly from region to region. There are classifications such as length, level of difficulty, state of disrepair and costs of maintenance and project timelines.
  • For the elderly care facility in Troy, NY the services expand to providing elderly care and transport on a regular basis. Many of these activities are serviced on known weekly schedules and routes such as scheduled pickups and dropoffs for people to their place of worship or transport to and from medical appointments.

Here are some examples of bad 10% feature enhancement(s):

  • Your non-for-profit solution adds a few text fields to the needs to accomodate description and rationale for the need.- Too simple. This is better: add the concept of messaging with the helper so there can be a more personalized engagement and the interested parties can talk back and forth with instructions and clarifications.
  • Your non-for-profit organization ties in so many features like tax calculations, IRS compliance or serious accounting. - Too back-end complex and doesn't divide easily between teammates or is realistic for the timeline. This is better: organizations are able to provide basic statistics of their performance. (e.g. total donation per month, average time to fulfill a need, number of needs met).
  • Your project tries to implement fancy front-end features at the expense of a clean workflow and a product that actually works - Ignores the real needs of the customer, adds complexity to the design and undue burden to the team. This is better: be driven by functionality that works and adds value to whom you are building for. Add the bells-and-whistles after.

Architecture

Teams will use the following technologies for development of the u-fund

Since many of the lectures touch upon these technologies,There will be no deviations from this technology stack. You are welcome to add dependencies to your application with the approval of the Product Owner. This decision is one that the team unanimously must agree upon.

Process

The team will use the OpenUP methodology for strategic planning activities across the life span of the project. The team will use the Scrum process for tactical day-to-day operations.