Progress Reviews

Now it's time for the implementation stages. Finally, we're going to start making our application vision a reality. We will use an Agile Software Engineering strategy for our project (for the most part). In part, this means planning a build schedule and with each build reviewing progress as compared to the original requirements and making the necessary adjustments. Note that there is some expectation of project drift, but try to keep to your schedule as best you can for the sake of your end product. Also note that your progress review grades will in part be based on how closely you follow your initially planned build schedule.

Your implementation cycle will require a scheduled 1 hour meeting each week with an assigned TA to review your progress. This means a deployed build for each week all the way through to the end of the semester. Your finished project (which is your 6th and final build) will be demonstrated as part of a recorded presentation. Also note the following:

• Version Control: to start with, setup your GitHub repository. Your version control repository should be kept in proper order and carefully used to prevent versioning conflicts between teammates and to help merge updates. In addition, it serves as a record of contributions made by team members and must be produced upon request. The assumption made will be that commits reflect the work the teammates did in the implementation stages.
  
  
• Deployment Platform: for each build, you will be expected to deploy your work to a publicly available server of your choice. Note that during the progress reviews, work will only be graded if deployed. No localhost! Note that the platform you use is up to you. If you are unsure, note that Heroku is likely the easiest setup for a MERN stack deployment, though you'll find disagreement among developers and things constantly change.
  
  
• CI/CD: Note that in the first benchmark you will be setting up your deployment as well as how you plan to test your application. In addition, you will be setting up your plan for Continuous Integration/Continuous Deployment (more on this below).
  
  
• Build Process: Before starting your implementation, each team should also decide upon the project build process to be used. This means choosing your development environment and also the procedure team members should follow when starting, committing, and then deploying completed work each day. Teams will want to get into good habits of providing descriptive comments within the code as well with each commit, and so together, teams should run through this process and make sure all team members are comfortable with the agreed procedures. Note that this step is also just to make sure all team members are comfortable with all the tools being used. No team member left behind! Your team should also decide on team rules for commits, like what constitutes changes worthy of a commit?
  
  

Project Management

This semester, we will use Monday for project management. Note there are a million tools out there and you may prefer another but for the purpose of consistency for teams, the Teaching Assistants, and the course instructor, it's best if we all use the same one. This tool is fairly straightforward, has task scheduling and assignments and has multiple project views, like Gantt Chart views. This is what we'll be using to review your project management progress, so make sure you carefully assign work with this tool to your teammates and specify things like delivery dates and dependencies.

Build Schedule

In all there will be six builds implemented over seven weeks, with the first being a special setup build and the last being your finished product. Note that there are special requirements for builds one and two, which are explained below. Each team then has to decide what work will be done for the remainder of the implemention.

• Build #1 - this is a special build. It involves making consequential decisions you are stuck with for the duration of the project. To complete this stage you will need to do the following:
  • Choose a Server for Deployment - this is where you'll host your site. Again, you will be deploying as you go so you will become well familiar with your selected deployment. Note that you should be careful to select a platform that can host your application keeping in mind we'll be dealing with GeoJSON files, which can be large (though we'll only use small countries).
  • Deploy a Bare-Bones Full-Stack Project - deploy an initial project to your server that demonstrates use of all the project's capabilities. So, it should have a running back-end server that makes database reads and writes in some way. Your project should also have a front-end that sends requests to this back-end server to trigger these reads and writes.
  • Implement some front-end tests - use the Cypess IO testing tool to demonstrate at least two front-end tests of your project. Note, this can be simple stuff but you should start to get yourselves familiar with its capabilities.
  • Implement some back-end tests - use the SuperTest and Jest testing tools to demonstrate the testing of at least two back-end routes. Again, this can be simple stuff, but again, note you should start to get yourselves familiar with their capabilities. Note, you will be using these testing libraries (Cypress IO, SuperTest, and Jest) for the rest of the semester, adding tests with each build.
  • Setup your CI/CD - the premise of CI/CD is to automate project deployment in such a way that it integrates automated testing so that tests are run every time your project is deployed. There are many tools you can use for this, for this semester you should use GitHub Actions and setup actions such that committing to the repository will run multiple tests (front and back-end) and deploy your project.
  • Map out your complete Build Schedule - Build #1 and Build #2 have specific requirements but for the rest of the builds (Builds #3-6), you will need to plan what will be done when. For this, you'll need to map out a build schedule using your project management software. Note, you should schedule the implementation of all Use Cases required by your application, dividing them up among the various builds.
  
  
  
• Build #2 - in this build you should create and style all of your front-end views, which will require you to define all of your React components and the styling associated with them. Note, they should be non-functional at this time, and so your JSX may contain hard-coded values, but the views should look as intended. Over the rest of the builds you will implement Use Cases that add functionality. Note again, your components at this time do not need to be hooked-up yet to any state variables (or back-end anything). So this build does not require any functionality, it is about component composition and complete layout and style. This means you will have to do the following:
  • All Front-End Routes - setup your front-end so that all routes are accommodated
  • Layout All Screens - setup your user interface with proper CSS positioning, sizing, and styling so that it looks as required by your application. Note, points will be assigned for it looking good.
  • Link your React Components using their proper Composition - make sure you provide definitions and make use of all your designed React components. This means your components should use your other components here.
  • Hard-code all Rendering - note that your screens should look good with example data but does not need to be pulled from state variables. It can simply be hard-coded.
  The important thing here is that you are setting up all of your components. You may make changes from your UI model as long as it makes your UI better. Note that at your TA meeting you will have to show all screens so make sure there are mechanisms to access all your UI model views.
  
  
• Builds #3-6 - in these builds you will now start to hook-up the front-end components with state management and back-end API services. Over the course of these four builds you will add all the Use Cases, following the schedule you set in Build #1. So again, this means you will need to break down required work into discrete programming "tasks" and schedule/assign that work. Note that use cases make for easily quatifiable work, but some are complicated and should be broken down into multiple programming tasks. For the final build teams should have implemented all use cases specified in team project requirements planning.
  
  

Weekly Progress Reviews

Each team will meet with your supervisor to review your project's progress for an hour to go over all the implementation details. These meetings can be online, but cameras must be turned on and all team members must be present for these meetings. At these meetings, teams will demonstrate the latest target build. Note that tasks that are not completed must be completed the following week.

Build Testing

Note that with each build you should setup front and back-end tests that get run as part of your CI/CD setup. This is an important part of test-driven development and note during Progress Reviews it will be the first thing TAs will look for.

---

Web page created and maintained
by Richard McKenna