Project Overview

The individual and team project for this class are designed to mirror the experiences of a software engineer joining a new development team: you will be “onboarded” to our codebase, make several individual contributions, and then form a team to propose, develop and implement new features.

All implementation will take place in the TypeScript programming language, using React for the user interface.

Overview of project deliverables

• Tuesday May 13, 6pm eastern: Team Formation Survey

  Specify preferences for teammates

• Thursday May 15 - Monday May 19: Project Kickoff Meeting

  Schedule a meeting with your mentor TA during this period (earlier is better!)

• Tuesday May 20, 6pm eastern Wednesday, May 21, 6pm eastern: Preliminary Project Plan

  Propose new user stories and satisfying features that can be completed in the following four weeks

• Tuesday May 27, 6pm eastern: Revised Project Plan

  Refine the scope of your feature based on course staff feedback, define detailed requirements and project acceptance criteria.

• Tuesday June 10, in-class: Demo your project in class

• Monday June 16, 6pm eastern: Project Delivery - Implementation and Documentation

  Deliver/Deploy your new features, including design documentation and tests

• Tuesday June 17, Wednesday June 18, in class — Project presentation

• Wednesday June 18, 11:59pm eastern — Individual reflection

Project grading

Your overall project grade (which will account for 40% of your final grade in this course) will be the weighted average of each of the deliverables.

Planning (20%)

• This includes the Preliminary Project Plan and the Revised Project Plan.

Process (20%)

This includes: use of a structured development process, including regular git commits, pull requests, code reviews, timely completion of progress reports and individual/team surveys, and weekly meetings with TA Mentor. To pass the class, each student must demonstrate participation in this structured development process.

This also includes appropriate division of labor within the project (i.e., roughly equal). To pass the class, each student must demonstrate participation in software development; a necessary (but not necessarly sufficient) condition is that each member must have at least 2 commits during each sprint (even when using pair programming).

Finally, this includes evaluations, self-evaluations, and final reflection (final reflection is required to receive an A).

Product (40%)

• 20% Successful delivery of your Minimum Viable Product as defined in your project plan
• 10% Desirable delivered features
• 10% Test suite of your features.

Reports (20%)

• 10% Final Report
• 10% Poster and in-class presentation

In cases where team members do not equally contribute to the project, we may assign different grades to different individuals. This deduction will not be greater than 50% unless the student doesn’t contribute enough to demonstrate success at software engineering and software development (which would make them unable to pass the course).

We will evaluate each individual’s contribution on the basis of a variety of factors, including progress reports at weekly meetings, through inspecting version control history, through each students’ self-reflection, and through each students’ peer evaluations during and after at the end of the project. We will make regular efforts to collect and distribute this feedback throughout the project.

How the project works

Team Formation

All projects will be completed in a team of 3-4 students. The very first deliverable for the project will be a self assessment and team preference survey: you will be able to indicate your preferences for teammates. The instructors will assign students to the teams based on a number of factors including your responses to the survey and diversity of skills for the teammates.

Team Meetings with TA Mentor

Each team will be assigned a TA to act as a mentor, who will work closely with you for the entire project and also will serve as your point of contact for project questions and grading.

Towards the end of the second week, you will arrange a “Kickoff Meeting” with your TA mentor, where you will meet your TA mentor and have the opportunity to share any early ideas that you might want feedback on before submitting the your preliminary project plan.

Once project begins in full force, you will have at least weekly meetings (twice weekly is not a bad idea!) with your TA mentor (scheduled at your team’s and the TA’s convenience) in order to help ensure that you are making progress on the project, and to help address problems that you encounter (be they technical or non-technical problems). These meetings will often include review of your pull requests, github commits, code reviews and demos from each group.

Preliminary Project Plan

All projects will involve frontend and backend development of new features for Strategy.town. Once teams have been formed, you and your team will decide what kind of new features you would like to build. Your features should be something that can be implemented within the timeframe allotted (just under four weeks!), and will be implemented in a fork of the main codebase. Given that you will be up-to-speed on the project codebase (and have been introduced to TypeScript, React, NodeJS, and testing frameworks), and that you will have a team of three or four, we expect that the feature that you propose will be more complex than the features implemented in the individual projects.

The project plan will focus on two sections:

• User stories and conditions of satisfaction that describe the features that you plan to implement. Each condition of satisfaction must be appropriately numbered and must have a priority (Essential, Desirable, or Extension). The set of essential items will constitute the “Minimum Viable Product” discussed above.

• Work breakdown: Map your user stories to engineering tasks. Assign each task to a team member (or pair of team members), provide an estimate for how long each task will take, a brief rationale for that estimate, and schedule those stories into sprints.

Creating a GitHub Repository

Your team’s development must take place within a GitHub repository in our GitHub Classroom. This repository will be private, and visible only to your team and the course staff. After the semester ends, you are welcome to make it public - you will have complete administrative control of the repository.

We will provide instructions to set up these repositories for all groups; the starter code will be the same as the starter code for the third individual project. You can use, with attribution, code written by group members for the first two individual projects, but not from the third individual project.

Revised Project Plan

Based on the feedback that you receive from the course staff, you will revise your preliminary project plan, creating a more detailed plan to implement your new feature.

The project plan will include:

• Revised user stories and conditions of satisfaction (based on feedback on the preliminary project plan)
• Revised work breakdown (based on feedback on the preliminary project plan) Your team will self-organize, as agile teams do, and will use the work breakdown and schedule as the basis for weekly check-ins with your team’s TA.

Software Development Process

Each team is expected to use of a structured development process, including use of pull requests and code reviews for their regular github commits. You will also need to ensure appropriate division of labor within the project (the expectation is that this is roughly equal). Teams will also be expected to complete regular progress reports (or sprint retrospectives), and provide honest feedback as part of individual/team surveys. Peer evaluations will also be used after each sprint.

Please note that one of the most important factors in successfully completing a team project is having open, honest and effective communication between all team members as well as stakeholders.

Project Implementation and Documentation

Your final team deliverable will be a deployed “release” with tests that run automatically on GitHub (with tests), and will be accompanied by an in-class demo.

Your final team deliverable will include:

• The implementation of your new features
• Automated tests for your new features
• A Final Report
• A Poster & Demo

The details for the final project deliverable and associated rubrics will be released by Week 5.

Individual reflection

The final deliverable will be an individual reflection, which every student must submit on their own. This will include your reflections on:

• The evolution of your project concept: How does the project that you delivered compare to what you originally planned to deliver? What caused these deviations?
• The software engineering processes that you feel could have been improved in your project: were there any procesess that in hindsight, you wish that you followed, or wish that you followed better?
• Your team dynamic: Provide a frank (and ideally, blameless) postmortem of your and your teammates collaborative performance and participation. If you had to do this same project over with the same teammates, what would you have done differently (or not) to improve your team’s overall performance?