Team Project Information

Table of Contents

  1. Team Project Overview
  2. Base Requirements
  3. Core Use Cases and Features
  4. Team Roles
  5. Artifact Document Templates
  6. Sprint Information
    1. Sprint 1: Team Organization
    2. Sprint 2: Requirements Elicitation
    3. Sprint 3: Heroku + Google Login
    4. Sprint 4: Amazon S3 Storage
    5. Sprint 5: Requirements Change
    6. Sprint 6: Beta Version
    7. Beta Testing
    8. Final Sprint
  7. Final Grading Information

Team Project Overview

This semester, our class projects are all about sharing and lending! We all have tons of stuff in our rooms, our homes, our offices (seriously, look at Sherriff’s office sometime… it’s full of video games…) that we might not use all the time, but others would love to borrow. Your teams are going to be building cataloging and lending applications that can be used for any type of thing you want. Maybe you’ll focus on books and have your app scan barcodes to look up information from an online database. Or perhaps you’ll do the same thing with your video game collection. Another option is tools - hammers, wrenches, screwdrivers, etc. - that you want to keep track of. There are numerous possibilities here! The main thing to consider is it has to be something that you 1) have a “collection” of in some capacity and 2) can lend out to other people. It will be up to your team to figure out what your app will do for your particular set of users.

From here on, we will use the following terminology and abbreviations:

  • The team projects for CS 3240 will be collectively called “Cataloging and Lending Apps” (CLAs)
  • Any individual thing that will be cataloged and made available for people to borrow will be called “items.” Example: if you are doing a book lending app, each copy of a book would be considered an item.
  • A grouping of items will be called a “collection.” Example: you decide to make a collection of all your video games that have Mario as a main character.
  • A “library” will be the full set of all items in your CLA. So, a library will have [0 to many] items and [0 to many] collections.

Base Requirements

All CLAs must meet the base requirements listed below.

  1. All CLAs must incorporate Google user accounts as the primary way that someone logs into the system. You will need to use the Google account API to make this work. There are several libraries that are built for Django to work with Google accounts with tutorials.
  2. There are four different user types you have to consider:
    • Anonymous users: users that will go to your CLA that do not have accounts and want to look around with limited access
    • Patrons: users that have accounts in the CLA and will have a login (through Google), a profile, and can request to borrow various items
    • Librarians: users that have accounts in the CLA and will have a login (through Google), a profile, can borrow various items (same as Patrons), but also have the ability to add new items and collections to the CLA
    • Django administrators: users who have access to the Django Admin page through the Django login system (do not have to use Google login) and have no access to the app (e.g., they cannot borrow items)
  3. We will refer to CLA users that have accounts (Patrons and Librarians) as “regular users.” Regular users DO NOT include anonymous users (because they cannot login to the system) or Django administrators (because they ONLY have access to the Django admin page, and not the CLA itself).
  4. Regular users must only login through Google login and NOT through the Django login system. CLAs SHOULD NOT provide a Django login page for regular users.
  5. CLAs must provide a separate login page for Django admin users. This page is typically auto-generated by Django and is at the /admin URL. Teams are welcome to customize this page if they want. Regular users should not be able to login to the Django admin site.
  6. All CLAs must incorporate cloud storage through Amazon S3 to handle file uploads. No uploads should be stored in Heroku as they will be deleted when your dyno is restarted! Also no files should be stored in the PostgreSQL database as this is generally bad practice. Application data, such as users, items, collections, etc. will be stored in the PostgreSQL database using Django’s model infrastructure.
  7. All projects must be built using the prescribed language (Python 3), database system (PostgreSQL), framework (Django 5), build environment (GitHub Actions CI), source control management (GitHub), cloud hosting (Heroku), and cloud storage (Amazon S3). No exceptions to these will be granted.
    • Note: All projects must use the PostgreSQL database engine for production on Heroku and continuous integration (on GitHub Actions). You are allowed to use SQLite for local testing so you do not have to install PostgreSQL on your own machine, but another option is to change your settings.py file point to the PostgreSQL DB on Heroku at all times.
  8. All CLAs should have a footer on each page that indicates that this system is a class project, the system is not monitored, and no real information should be submitted. If appropriate, direct the user to an appropriate external resource.

Core Use Cases and Features

Items

  1. Items are the “primary objects” in the CLA. They must contain, at a minimum:
    • Title
    • A primary identifier (e.g., a QR code, a barcode, a key value the user makes or is generated by the system, ISBN, UPC)
    • Status (e.g., checked-in, in circulation, being repaired, etc.)
    • Location (e.g., home library, work library, etc.)
    • Description
    • Representative images (can start as a default image provided by system, but Librarian can add [0 to many] files uploaded to Amazon S3)
    • Ratings and comments posted by Patrons about the item, implemented as part of the CLA (i.e. not using an external app)
    • [0 to many] Collections it is a part of
  2. All patrons can see all items that are NOT in a collection
  3. We anticipate that there will be other fields for your items based upon your chosen domain. These requirements will come as a part of your requirements elicitation.
  4. When an item is deleted, all information stored in the PostgreSQL database and all files stored on Amazon S3 should be deleted as well. Items cannot be recovered after they have been deleted.

Collections

  1. Collections are a group of items that a Library puts together based on some theme.
  2. Collections must contain, at a minimum:
    • Title
    • Description
    • [0 to many] Items
    • Public or Private setting
    • If Private, a list of users that have the ability to see this collection and borrow items (note that librarians can always see all collections)
  3. Items can belong to more than one public collection at a time.
  4. If an item is in a private collection, it is only allowed to be in that one private collection and no other collections, either public or private.

Libraries

  1. Libraries must be searchable by any user, based upon their access requirements (see user requirements below).
  2. Users can search for items by title and any appropriate keyword or tagging that your app implements.
  3. Users can search for any collection by title and any appropriate keyword or tagging that your app implements.
  4. Users can search within any collection for items title and any appropriate keyword or tagging that your app implements.

Anonymous Users

  1. The CLA shall allow an anonymous user to browse all items that are not in a collection and all items in public collections, but not private collections.
  2. Anonymous users cannot see the titles of private collections at all. They should not show up in any listings or searches.
  3. Anonymous users cannot rate items, leave comments, or request to borrow an item.
  4. The CLA shall provide a button for an anonymous user to login to the system.

Patrons

  1. The CLA shall allow a patron to create an account in the system using their Google account.
  2. When a patron creates an account, a profile should be created for the user. A profile should consist of, at a minimum, the user’s real name, the user’s Google account/address, a profile picture, and the date they joined the CLA. Other data, such as interests, description, birthday, etc. can be added based on the requirements elicitation activity.
  3. A patron shall have the ability to browse all items that are not in a collection and all items in public collections, but not private collections.
  4. A patron shall have the ability to see the titles of all private collections, but not any items inside these collections.
  5. A patron shall have the ability to request permission to access a private collection through a button associated with the collection in some reasonable way in the interface.
  6. A patron shall have the ability to request to borrow an item. The request is then sent to the librarians for approval.
  7. A patron shall be able to see a list of all items they currently have borrowed and any other pertinent information about the lending (e.g, due date, etc.)

Librarians

  1. A librarian shall have the ability to upgrade a patron user to librarian status.
  2. A librarian shall have the ability to add, edit, and delete items in the CLA, per the requirements regarding items above.
  3. A librarian shall have the ability to add, edit, and delete collections in the CLA, per the requirements regarding collections above.
  4. Any librarian shall have the ability to see, approve, and deny borrowing requests from patrons. If a request is approved, the patron should be notified that they can collect their item. If a request is denied, the patron should similarly be informed.
  5. A librarian shall have the ability to move items into and out of collections, per the requirements above.

Django Administrator

  1. A Django Administrator is created only through the createsuperuser Django command.
  2. A Django Administrator can only access the Django admin page. No other account type should have access to the Django admin page.
  3. The primary use case of a Django Administrator is to create the first librarian in a new CLA and to repair any data model issues that cannot be handled by a librarian.
  4. No “normal” usage of the CLA should require use of the Django Administrator account. This includes any requirement listed above or any new requirement from the elicitation process. The Django Administrator account is intended for SPECIAL CASE MAINTENANCE ONLY.

Variations and Themes

  1. Your team’s app can take the requirements above and place the app in whatever domain your team is interested in.
  2. Extended requirements for your app will come from the requirements elicitation activity you will in the first few weeks of class.

Team Roles

Each member of your five person team will take on one of these roles. Each role has different responsibilities, but ALL ROLES require that you be an active contributor to the code of the project. In other words, if you take on Scrum Master, that doesn’t mean you don’t have to contribute as much code as someone else. Please see the information on Assessment and Grading for more information.

Scrum Master - The Scrum Master could also be called the Team Leader, but it’s not really a “leader” position, per se, in that they are not making major decisions about the project itself. The Scrum Master is responsible for keeping everyone on track, facilitating all team meetings, and monitoring team status / issues. The course staff will come to the Scrum Master first if there are any team issues or questions, and similarly the Scrum Master needs to know what’s going on with the team and can communicate with the staff if someone is falling behind, etc.

  • Reasons to be the Scrum Master: You like keeping schedules; you like keeping things organized; you don’t mind being the point of contact with the staff.
  • Reasons not to be the Scrum Master: You are not the most organized person; you don’t think you can stay on top of what the team is working on; you don’t like talking to the staff.

Major Artifact: Scrum Master Final Report, due at the end of the semester

Requirements Manager - The Requirements Manager is responsible for keeping up with the features of the project. This person will take the lead on the requirements elicitation process (which takes place in the first couple weeks of the project) as their major activity. Note that the Requirements Manager doesn’t do the whole process - they just lead the effort. Everyone else has to participate as well! Then throughout the semester they will manage the feature/issue tracker in GitHub, monitoring the state of the project.

  • Reasons to be the Requirements Manager: You are interested in learning how requirements are created; you want to find out what your fellow students are excited about with your project; you like knowing “what’s coming next” in the project.
  • Reasons to not be the Requirements Manager: You have no interest in interacting with other people to find out what they want in a system; your first couple weeks of the semester are super hectic and you don’t have the time for the elicitation process.

Major Artifact: Requirements Elicitation Document, due within the first few weeks of the semester

Testing Manager - The Testing Manager is responsible for ensuring that the system is thoroughly tested, for developing the overall testing plan/philosophy of the team, and spearheading the beta testing effort at the end of the semester. The Testing Manager is responsible for executing beta testing at the end of the semester and creating the Beta Testing Document. The Testing Manager is also responsible for overseeing the testing philosophy throughout the semester, ensuring unit tests are being written. Note that the Testing Manager does not write every test case in the system - they just keep up with what everyone else is doing and lend support as needed.

  • Reasons to be the Testing Manager: You want to learn more about testing procedures; you love seeing that unit test result bar turn green; you took HCI or something similar and are interested in setting up user testing.
  • Reasons not to be the Testing Manager: You don’t see the value in writing tests; you don’t want to work with your fellow students in doing in-person testing.

Major Artifact: Beta Testing Report, due near the end of the semester

DevOps Manager - The DevOps Manager is the support tech for the team in a sense. They are responsible for the management and support of all the systems we are using in the class, namely GitHub, GitHub Actions, Amazon S3, and Heroku. They should be a person that is relatively comfortable tinkering with computers and settings. The DevOps Manager does not have to have all the answers, but would be the contact person for going to the staff to get help on any particular issues. The DevOps Manager does need to have access to a credit card for setting up the various accounts for the team.

  • Reasons to be the DevOps Manager: You are familiar with the tools mentioned already, or you are really interested in learning more about them; you like to tinker with settings to get things working “just right”; you have the patience to help those on your team who might need assistance getting their environments working.
  • Reasons not to be the DevOps Manager: You do not feel comfortable helping others with technical issues; you are very unfamiliar with the tools above and would rather just have a “turnkey” solution for doing your work this semester.

Major Artifact: DevOps Report, due near the end of the semester

Software Architect - Midway through the project, a requirements change will be introduced to the base requirements listed above. The job of the Software Architect is to determine how to implement the change, document the steps that need to be taken, and then help the team implement the change. The Software Architect is not the primary coder for the project and should not be treated as such.

  • Reasons to be the Software Architect: You enjoy solving a puzzle using critical thinking and you are interested in how software is put together.
  • Reasons not to be the Software Architect: You hate troubleshooting code.

Major Artifact: Requirments Change Analysis, due after the requirements change is introduced

Sixth Team Member - If your team has 6 members, the member without a role listed above should come to office hours with the professor to discuss options. The role will be determined based on interest and needs of the team.

Only Four Team Members - If your team only has 4 members due to the number of students in the course or because a student drops, the role that should be left out is Software Architect. All other roles must still be filled. A team with 4 members does not have to submit the Requirements Change Analysis document, but will still implement the change.

Artifact Document Templates

Team Documents

Sprint Report
Final Submission Pledge

Scrum Master

Scrum Master Final Report

Requirements Manager

Requirements Elicitation Document

Testing Manager

Beta Testing Report

DevOps Manager

DevOps Report

Software Architect

Requirments Change Analysis

Sprint Information

For each sprint check, your team must meet the minimum requirements shown below for each sprint to earn full XP. Faculty will not override a TA’s decision except in extreme circumstances.

Sprint 1: Team Organization

Sprint Duration: 01/26-02/01
Sprint Due: 02/02

Goal: Have your initial meeting as a team and determine who will be doing what on the team. This meeting can be any time between when your team is formed and your sprint check meeting with your TA on the first Sunday or Monday of the sprint. The Scrum Master of each team MUST complete this form with the team as a part of the Sprint: Team Declaration Form. Also, Scrum Masters should initialize the team GitHub repo through GitHub Classroom. Please use your assigned team number for the identifier when prompted (e.g., A-03). Other team members can then go to that link and accept the assignment, selecting the proper team.

Requirements and XP Allocation:

  • 15 XP: Complete the Team Declaration form above.
  • 10 XP: GitHub repo initialized and all team member accounts have joined the project.

Team Evals: No Team Evals this week.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope by noon on Sunday at the completion of the sprint so they can reference it. Scrum Masters -must- select their team members in Gradescope when submitting so all members will earn the XP for the sprint. (No, you won’t have much to report this week, but think about what’s coming up and discuss that.)

Sprint 2: Requirements Elicitation

Sprint Duration: 02/02-02/08
Sprint Due: 02/09

Goal: Spend most of this sprint working as a team to elicit the full requirements for your system. Note that while the final Requirements Document is the responsibility of the Requirements Manager, all team members are expected to contribute to gathering and refining the final set of requirements. Once you have a good set of user stories / issues / tasks for your team to work on, add these as Issues to your GitHub Issues page on your team’s repository.

Requirements: The team must have a “reasonable” set of user stories / issues in GitHub Issues to begin with (around 10 is a lower-bound target). We do not expect you to have your final set of features at this point. However, you need to be able to show the TA that you have gathered requirements data and that you have converted at least some of this information into GitHub Issues. The Requirements Manager will receive a separate score for the requirements document, which is due by the date indicated in Gradescope. The team also needs to ensure Heroku is set up properly and that you can deploy at least the basic, default Django app.

XP Allocation:

  • 15 XP: Team has populated GitHub Issues with a reasonable number of issues/features (~10 at least) that are appropriate for the project.
  • 10 XP: Team can deploy the basic, default Django app to Heroku.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope by noon on Sunday at the completion of the sprint so they can reference it. Scrum Masters -must- select their team members in Gradescope when submitting so all members will earn the XP for the sprint. Your GitHub Issues page should be populated with your team’s project requirements. (NOTE: If you would like to use GitHub Projects instead of Issues, you may do so.) The requirements manager should submit the requirements document to the appropriate assignment by the separate due date listed. No other team members should submit the requirements document.

Sprint 3: Heroku + Google Login

Sprint Duration: 02/09-02/22
Sprint Due: 02/23

Goal: All CLAs must have a user account feature for students to login with. To accomplish this, you are to integrate Google login to your app.

Requirements: A user with a Google Account can login to the system and the system shows in some way that that user has indeed logged in. You must show that both a patron and a librarian account can login and that they get different screens. Note the requirements for the different types of users above. Print the user’s name and account name to the screen to show that it works. Your team must be updating GitHub Issues as appropriate throughout the rest of the project.

XP Allocation:

  • 15 XP: Team can show that a patron and a librarian can both login and be shown something different based upon their user role.
  • 10 XP: Team worked on other features other than the Google login and is on track.

Team Evals: At the end of Sprints 3-6 and at the end of the semester, you will need to fill out an evaluation for each member of your team! You can find the evaluation form here: Student Team Sprint Evaluations. Students who do not fully participate in the team evaluation process will be penalized on their final Team and Staff Evaluation score.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope by noon on Sunday at the completion of the sprint so they can reference it. Scrum Masters -must- select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The main branch of your GitHub repo should be live on Heroku.

Sprint 4: Amazon S3 Storage

Sprint Duration: 02/23-03/15
Sprint Due: 03/16

Goal: All projects must allow a user to upload files to Amazon S3.

Requirements: Using Amazon S3, implement the necessary features to allow patrons to upload profile pictures and for librarians to add images for the items in the CLA. GitHub Actions CI should be operational with at least multiple test cases in order to earn full XP. As you are just getting started with testing, this is more showing us that you have the process setup and that you have some passing tests. Your team must be updating GitHub Issues as appropriate throughout the rest of the project.

XP Allocation:

  • 15 XP: Team can demonstrate user profile pictures and items with associated images.
  • 10 XP: Team worked on other features other than Amazon S3 and is on track.

Team Evals: At the end of Sprints 3-6 and at the end of the semester, you will need to fill out an evaluation for each member of your team! You can find the evaluation form here: Student Team Sprint Evaluations. Students who do not fully participate in the team evaluation process will be penalized on their final Team and Staff Evaluation score.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope by noon on Sunday at the completion of the sprint so they can reference it. Scrum Masters -must- select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The main branch of your GitHub repo should be live on Heroku.

Sprint 5: Requirements Change

Sprint Duration: 03/16-03/29
Sprint Due: 03/30

Goal: The Software Architect takes the lead in guiding the team through the requirements change.

Requirements: At the beginning of Sprint 5, the staff will introduce a requirements change to the project. The Software Architect is responsible for leading the team through this change and documenting the needed architectural changes to handle the update.

Requirments Change: Will be revealed just before Sprint 5 begins.

XP Allocation:

  • 15 XP: Requirements change handled effectively.
  • 10 XP: Team worked on other features other than Amazon S3 and is on track.

Team Evals: At the end of Sprints 3-6 and at the end of the semester, you will need to fill out an evaluation for each member of your team! You can find the evaluation form here: Student Team Sprint Evaluations. Students who do not fully participate in the team evaluation process will be penalized on their final Team and Staff Evaluation score.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope by noon on Sunday at the completion of the sprint so they can reference it. Scrum Masters -must- select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The main branch of your GitHub repo should be live on Heroku.

Sprint 6: Beta Version

Sprint Duration: 03/30-04/12
Sprint Due: 04/13

Goal: After Sprint 6 is complete, you are going to have other students test your system. So you need a working system with most all of your functionality ready to go. The app may not be fully polished and still needs a bit of work, but it needs to be usable from beginning to end. Your team must be updating GitHub Issues as appropriate throughout the rest of the project.

Requirments and Full Beta Version: In the opinion of the TA, you have an app that is ready for other students to test out (e.g. it doesn’t crash, it looks reasonably good, it has most features, etc.). You will earn 25 XP for the sprint check plus 100 XP as the first half of your overall project score of 250 XP (basically, if you have a working app at this point, we know your final project grade will be at least 100/250 XP, so we can give you those points now).

XP Allocation:

  • 100 XP: Beta Version works! App turns on and does things! It’s ready for users!
  • 15 XP: CLA is nearly feature complete.
  • 10 XP: User interface shows thoughtfulness on the part of the team and is ready for beta testers.

Team Evals: At the end of Sprints 3-6 and at the end of the semester, you will need to fill out an evaluation for each member of your team! You can find the evaluation form here: Student Team Sprint Evaluations. Students who do not fully participate in the team evaluation process will be penalized on their final Team and Staff Evaluation score.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope by noon on Sunday at the completion of the sprint so they can reference it. Scrum Masters -must- select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The main branch of your GitHub repo should be live on Heroku.

Beta Testing

Sprint Duration: 04/13-04/19
Sprint Due: 04/20

Goal: You now have a “working” version of your project that you can have others use. Follow the instructions in the Beta Testing Document to have others work through a script of testing your software, similar to what we did with the Guided Practice. You can ask anyone to test your system, even those currently in CS 3240. It would be nice to ask at least some folks that you included in your requirements elicitation so they can see what all you have built! Refer to the lectures where this was discussed for more information. Once you have done your testing, keep polishing your system for final submission!

Final Sprint

Sprint Duration: 04/20-04/28
Sprint Due: 04/29

Goal: It’s the final week to polish up your app and make changes based on the Beta Testing feedback! Good luck!

Final Grading Information

The final project is worth a total of 250 XP. (100 XP will be awarded after Sprint 6 for your Beta version and the remaining 150 XP will be awarded by the professors after final demos.) Like the other assessments in this course, grading is overall holistic - that is, there is no specific point-for-point breakdown for the rubric. One reason for this is that this is simply not how software is delivered in real-life. There are basically only four outcomes:

  • You meet the expectations of the customer within reason and both parties are satisfied with the outcome;
  • You exceed the expectations of the customer, potentially generating more good will, a good reference, or more future business;
  • You do not quite meet the expectations of the customer, leaving some room for improvement;
  • You ship a system that simply does not work to the expectations of the customer.

We will grade your projects in a similar vein, with some flexibility for minor adjustments.

Thus, the grading levels will be:

  • Above and Beyond - Min XP: 250 / Max XP: 255
  • Complete - Min XP: 200 / Max XP: 250
  • Lacking - Min XP: 150 / Max XP: 200
  • Insufficient - Min XP: 0 / Max XP: 150

Aspects that will determine the exact grade within a range include but are not limited to:

  • UI design
  • Overall flow of application
  • Special features
  • Obvious bugs that should have been corrected
  • Polish

Final Team Evals: All team members will complete a final, overall team evaluation at the end of the course. Final Student Team Sprint Evaluations. Students who do not fully participate in the team evaluation process will be penalized on their final Team and Staff Evaluation score.

The final version of the project must be in GitHub and hosted on Heroku no later than 04/29!