CSCE 431: Software Engineering

Project

Introduction

Students will complete a course project in teams of 5-6. Grading will be shared among all members (i.e., the project gets a grade, not each student separately), and we will require specific proof of each member’s role in the group. Groups will be assigned to an external customer (e.g., student organization, local non-profit) to build a SaaS application. See examples of previous projects from UC Berkeley.

The timeline of the project is as follows:

Team Formation: Tue 23 Jan 2018 -- Form a team of of 5 or 6 members.
Project Selection: Tue 30 Jan 2018 -- Select a project and start talking to the customer.
Iteration 0: Tue 20 Feb 2018 -- Get ready to go.
Iteration 1: Tue 6 Mar 2018 -- Complete the milestones in the first iteration.
Iteration 2: Tue 27 Mar 2018 -- Complete the milestones in the second iteration.
First Team Peer Evaluation: Tue 3 Apr 2018 -- Submit your first team peer evaluation form.
Progress Presentation: Wed 11 Apr 2018 - Wed 18 Apr 2018 -- Classroom presentation of your project progress.
Iteration 3: Tue 10 Apr 2018 -- Complete the milestones in the third iteration.
Iteration 4: Tue 24 Apr 2018 -- Complete the milestones in the last iteration.
Final Report: Tue 1 May 2018 -- Submit your final project report.
Final Poster/Demo Presentation: Wed 2 May 2018 16:00-18:00 -- Present a poster and a demo of your project.
Customer Satisfaction Survey: Wed 2 May 2018 -- Your customer return his/her satisfaction survey.
Final Team Peer Evaluation: Wed 2 May 2018 -- Submit your final team peer evaluation form.

Project Solicitation

If your team has an idea and a customer for a project:

Check the FAQ to make sure it meets our criteria (on which we must be firm, to keep the course running smoothly).
Make sure everyone on the team agrees to this project.
Check out the call-for-project page and fill in your project information. The instructor will let you know if this project is approved.

Team Formation

Teams are self-selected. They are normally six members, but class enrollment may require some teams of five. If you cannot find a team, post on Piazza and the TAs will help you. If you are not on a team of 5 or 6 members, please post on Piazza looking for a team. If necessary we will reshuffle teams to make sure all teams have 5 or 6 members.

Please create a team name (be creative!). Team names should not include the word "Team". ONE PERSON on the team should send an email to the TA using the following format:
To: <TA Name> Subject: [CSCE 431] Project Team - (Team Name) Team Name: AgileAggies Jane Student <UIN> Joe Student <UIN> ...

Project Selection

A list of projects will be posted on the course website, and teams will email the instructor a list of their top 5 projects and bottom 5 projects. Projects will then be assigned to teams. Teams that already have an approved project will not take part in this selection. The instructor will email your project customer contact informing them of the project selection (or non-selection) and which team will contact them.

Iteration 0 (Points: 10)

This week you should set up meetings with your customer. Emphasize to them that time is short, so you need to get going right away. In the first meeting(s) you should extract their user stories, sketch low-fi user interfaces and story boards (bring something to sketch on/with), etc. It might help to record your conversation (e.g. on your phone). You can then iterate with them and prioritize the stories. Each team should select a Scrum Master and Product Owner. The Scrum Master will submit the team reports. I recommend it be the Product Owner who makes contact with the customer to set up the meetings. You need to meet with the customer every iteration, if at all possible.

Turn in the following, with all elements in a single PDF file:

Team roles: The team should elect a scrum master and product owner.

Customer meeting date/time/place: The team product owner should contact the customer and set up a meeting.

Summary: Write a two-paragraph (max) summary of the main customer need and how the application meets it, including who the stakeholders are. Include links to the video, GitHub repo and Pivotal Tracker in the document

User stories: Create at least 4 user stories on 3x5 cards. These should be in the format shown in Chapter 7. You can submit photos of the 3x5 cards or type them up. Example:


			Feature: Add a movie to Rotten Potatoes

			As a movie fan

			So that I can share a movie with other movie fans

			I want to add a movie to the Rotten Potatoes database

User interface: Create lo-fi UI mockups and storyboards for at least 4 user stories. Submit photos of these.

Pivotal Tracker: Create a free open-source public Pivotal Tracker project and enter the user stories. Give access as “observers” to the instructor and TAs.

Video: Produce a 2-minute video interview where customer describes the problem you will be solving and the application you will be building.
- See an example interview.
- Note 1: this example was made at the end of the project, so the questions are somewhat different from what you should ask.
- Note 2: you may directly embed the video in the submitted PDF file, or upload the video to vimeo or youtube and include the link in the PDF.
GitHub Repo: Populate the initial public GitHub repo for your project. An open source repo is free. Give the instructor and TAs access as collaborators.
For legacy projects: write a one-page document discussing your overall strategy for learning/improving the prior code. Also, if any of your user stories are improved/replacement stories for what was done in the past, please note that in this document.

Iterations 1 to 4 (Points: 5 per iteration)

Overall Requirements

Using Pivotal Tracker, identify a subset of stories you'll work on during this iteration and who owns each.
Use BDD+TDD to develop these stories and deploy to Heroku.
For legacy projects, understand and refactor legacy code as necessary.
Get feedback from customer and indicate how this will affect the next iteration.

Specific Milestones in Each Iteration

Pick approximately ¼ of the stories you submitted for Iteration 0 (along with any later user story additions) for each iteration, balancing the workload between each of the iterations. The selection should be based on customer meetings.
Create a comprehensive set of Cucumber and RSpec test cases for each user story to be implemented. You should have a Cucumber feature file with one or more scenarios with high-level declarative steps, corresponding to the UI sketches. The test cases must be able to run automatically. Test cases should include both successful and exceptional scenarios (happy and sad paths). Make sure that we can git checkout and run your tests from scratch.
Design diagram identifying current key entities and relationships in the app, i.e., what will be the most important models and how will they be related. A UML class diagram is one way to do this, but any understandable informal method is acceptable. Update this diagram on each iteration.
Implement the user stories selected for the iteration and make sure that all test cases can be run automatically and that the test cases pass.
Deploy to Heroku, verify that the user stories are working, and demo for the customer and obtain customer feedback.

Turn in the following, with all elements in a single PDF file:

Customer meeting date to demo this iteration.
User stories implemented in this iteration.
Design diagram for this iteration.
Any additional documentation related to the user stories, e.g. changes to lo-fi UIs.
If you were not able to implement all the stories that you initially chose for this iteration, please list which ones and why not.
If you have changed any of your stories, please write a short description of the changes made and the reason behind the changes.
If you are working on a legacy project, please list any user stories that were rewritten and code refactored.
Evaluations of your code and tests, such as SimpleCov and CodeClimate
Links to your Pivotal Tracker, Github repo, and Heroku deployment. Make sure these are up-to-date.

Please tag your git repository revision with Iteration1, Iteration2, etc. Here are some example commands for how to tag revisions:

To tag the current revision: git tag -a Iteration1
Warning: You must explicitly push your tags with the command git push --tags. Before you submit, please make sure that when we clone, we can see the tag.

Grading will be based on the quality of user stories, comprehensiveness, and success of your test cases. We might also create our own test cases. Make sure that we can git checkout and run your tests from scratch.

Team Peer Evaluation I (Points: 5)

Each team member must fill out the first team peer evaluation and must submit to eCampus. This peer evaluation will be non-graded for individual team members. However, ALL team members must submit their forms in order for the team to gain the points.

Classroom Presentation (Points: 10)

Each team will give a 15-minute prepared presentation (including 3-minute Q&A) in class on the project progress. All team members must participate in the presentation. See Schedule for the presentation schedule.

Final Report (Points: 30)

Submit a zip-compressed file to eCampus including the PDF of your poster, your progress presentation slides, and a final report (as a PDF) with following items:

Two-paragraph summary of the project as implemented, including the main customer need and how the application meets it, including who the stakeholders are. This will contrast to what you wrote in Iteration 0.
Description of all user stories (including revised/refactored stories in the case of legacy projects). For each story, explain how many points you gave it, explain the implementation status, including those that did not get implemented. Discuss changes to each story as they went. Show lo-fi UI mockups/storyboards you created and then the corresponding screen shots, as needed to explain to stories.
For legacy projects, include a discussion of the process for understanding the existing code, and what refactoring/modification was performed on the code, in addition to the user stores listed above.
List who held each team role, e.g. Scrum Master, Product Owner. Describe any changes in roles during the project.
For each scrum iteration, summarize what was accomplished and points completed.
List of customer meeting dates, and description of what happened at the meetings, e.g. what software/stories did you demo.
Explain your BDD/TDD process, and any benefits/problems from it.
Discuss your configuration management approach. Did you need to do any spikes? How many branches and releases did you have?
Discuss any issues you had in the production release process to Heroku.
Describe your implementation environment – homebrew, VirtualBox, AWS, Cloud9, etc., and any issues with it.
Describe the other tools/GEMs you used, such as CodeClimate, or SimpleCov, and their benefits.
Link to two-minute video interview with the customer. Store the video on Vimeo.
Link to the 2+ minute demo highlighting your app's main features. Here are two examples from past projects: Nurse Vacation Scheduler and Pet Foster Home Finder.
Link to your public GitHub repo. Make sure all code (including Cucumber and RSpec!) is pushed to your repo.

Notes:

See a sample final report. The report should take no more than 5 pages of 12-point text, not counting figures (e.g., screen shots).
The instructor will retain a copy of all of your project material to facilitate future legacy projects.

Final Poster/Demo Presentation (Points: 20)

Final presentations/demos will take place Wed 2 May 2018, 16:00-18:00, ETB 2005. CSE faculty will be invited. You should invite your customer to this presentation. If a customer will need parking, inform them of the location of visitor parking near ETB (map). Feel free to invite your friends as well. Refreshments will be served.
The final presentation will consists of two parts: an 8-minute prepared poster presentation and live demo (on a team member laptop), and a random testing by the instructor and TAs. Grading will be based on the quality of the poster presentation and prepared demo, and testing by the instructor and TAs.
In your poster presentation and live demo, you should describe the application and walk through the major use cases. You may also explain some of the design choices you made while working on your project. The poster should go over your application, your design, and challenges and lessons you have learned about the software engineering process. Every team member must participate in some way in the presentation and demo.
Use PowerPoint to create your poster. Your poster dimensions can be up to around 30 inches by 40 inches. Here is an award-winning 30x40 inch poster example. We will supply the easels, foam core board and binder clips to attach your poster. The cheapest option for poster printing is in Architecture (https://wikis.arch.tamu.edu/display/HELPDESK/Printing). Large format color printing is available at FedEx Kinko’s, Copy Corner, etc., but at higher cost.
When you are not presenting your poster and demo, you can visit the other posters and demos.

Customer Satisfaction Survey (Points: 5)

Each group (project owner) must send their customer the customer satisfaction survey, and ask their customer to email the instructor the completed survey by the end of the demo day.

Team Peer Evaluation (20% of your total project score)

Each team member must fill out the final team peer evaluation. Each member must submit these to eCampus separately.