CSE216: Software Engineering Programming Assignment #0
Instructor: Prof. Liang Cheng Assigned: 2/15/2021 Project Assistants (PAs)/Mentors: Andrew Ha, Thanos Kougionis, Maximillian Machado, Buckley Ross
Due: 3/1/2021
Problem Statement
Your initial experiments went well, and you¡¯ve given your response to management. You¡¯re all in. Now it¡¯s time to forge a team and start designing and building software.
You decide to use an agile process. Along with like-minded coworkers, you decide to allot two weeks for your first sprint. Remember: time is of the essence, because the company needs a secure place for professional social interaction. Employees from across the globe want to be able to share ideas, vote on proposals, and make sure NakedMoleRat is a success. At the end of the sprint, you plan to actively engage employees as users of the system, so that you can refine your design and flesh out more details in preparation for future sprints.
The goal is to start small… a cloud-hosted web system so that employees can post short messages, and other employees can up-vote and down-vote. But you know this is going to get big… real big… so it would be good to do things right the first time, and anticipate the growing pains that you¡¯re sure to encounter once everyone realizes that you¡¯ve invented the next big thing.
The excitement is palpable. There¡¯s so much energy on the team, it feels like the room is buzzing with excitement. To kick off the project, you suggest a name… ¡°let¡¯s call our new social app ¡¯The Buzz¡¯…¡±
Deliverables
This project will be collected by checking out your team¡¯s git repository, so be sure to check in your code often, and to follow the rules for the project. In particular, your team should obey the rules about who works on which parts of the project. You should be trying to work as an effective team, not just trying to finish each task.
To that end, there should be a master branch, which is only updated three times during this phase of the project. Each of the three programmers (web, back end, and admin) should work with a separate branch, and the project manager will merge each branch with the main branch only after completing a code review (see below).
The Project Manager
The project manager needs to create a team repository at Bitbucket and invites all team members, the team¡¯s mentor and the instructor to join.
First and foremost, the project manager must launch the phase 1 backend code onto Heroku. Heroku provides free HTTPS, free database (albeit only a small amount), and up to 700 hours of server time per month for free. Plus, it¡¯s a Platform as a Service, so there¡¯s no server maintenance or security upgrades.
Normally, the program manager wouldn¡¯t be taking on a job like this, but it¡¯s got to get done, and everyone else is going to be racing to get their parts of the project in order. The project manager will need to figure out how to deploy the server to the Heroku. There¡¯s a lot to the ¡°Ops¡± side of ¡°DevOps¡±, and exploring Heroku will help you to gain an appreciation for it. Tutorial 8 [1] only scratches the surface… be sure to document everything you learn, so that your teammates can take on this role in future phases of the project.
Note that this task needs to happen early, because it will affect everything that your teammates do.
You should also submit documentation for the user interface for your app.
The project manager, in consultation with the back end and web developers, should devise a strategy for how two programmers can build their components simultaneously, when they depend on each other. Note that it is possible to do most of the development of both components independently. However, some approaches have more redundancy and worse integration costs than others.
The project manager must also perform a code review of each team member¡¯s code. The project manager should sit with the programmer, and review every line, checking for correctness, comments, etc. This cannot be done until after all tests pass, of course. It should end with the programmer¡¯s branch being merged with the main code base, by the project manager.
The project manager is expected to use Trello to track the state of the project at all times, and to document the tasks that comprise this sprint.
The project manager will also be responsible for preparing a document (we will provide a template) that describes the state of the project. This will allow us to assess each team member¡¯s contribution, and to assign grades accordingly.
The project manager must ensure that the standards for documentation are being met. This will include, for example, ensuring that the source code results in proper JavaDocs, and that there is a README in the root of the repository that provides all of the necessary information to use ¡°The Buzz¡±, as well as all information about its APIs.
Lastly, the project manager explores ideas to extend the project for a potential start-up and researches on what the target users/markets are. Brainstorm with team members so that the team has an Application Definition Statement. Fill in the template provided for Design-oriented Thinking; the template is available in the CourseSite.
The Back End
The student who assumes the role of Back-End Developer for this task will use the Java Spark Framework [2] to create a dynamic web server. Based on the design from class, the server will provide several ¡°routes¡±, through which users can ¡°POST¡± new messages by sending JSON, and ¡°like¡± messages, again by sending JSON. The server will return a list of messages, along with a count of ¡°likes¡±, as JSON. The server must return proper HTTP status codes.
The back-end programmer will be persisting the results of the HTTP requests to a PostgreSQL database. The server must read its configuration (at least the port on which to listen, and the reference to the database) from environment variables. Heroku will give you the variables you need for using PostgreSQL.
The back end developer must also produce unit tests that are appropriate for ensuring the correctness of the back end. Remember: the back end will change in the next phase: things that shouldn¡¯t break as the back end is extended should have tests that accompany them.
The Web Developer
Your team¡¯s web developer will create a basic web application that performs GET and POST requests to the server, in order to show a list of messages, allow the creation of new messages, and allow a user to ¡°like¡± messages. The web app must be ¡°live¡±, and interact directly with the back end. You should implement your program as a ¡°single-page web app¡±, where the back end is as uncoupled from the web front end as possible. It is OK to rely on the backend for serving static content, but the only dynamic
content it serves should be JSON, never HTML.
The Web Developer should work with the Project Manager to develop a reasonable workflow for building the web source (starting from the ideas behind ¡°deploy.sh¡± in Phase 0). The process by which team members can deploy the web code must be straightforward and clean. The web frontend sources should not be checked into the back-end¡¯s folder hierarchy.
Note: the web front end should also use Handlebars [5] for templating, and Bootstrap [6] for styling. The web developer must also produce Jasmine tests for both the logic and the UI of the web front end.
The Admin App
If your team has only less than 4 members, the Project Manager will also work as the Admin App Developer. There is not much work to be done on the admin app, but the work is important. You should make sure that a standalone Java program is able to drop tables from the database, recreate tables from the database, and do any other maintenance that needs to be done. And, of course, there should be unit tests.
In addition, the admin app developer should directly assist the other programmers in two ways. First, through peer programming, the admin app developer can sit with another teammate and provide over-the- shoulder advice. Second, while the admin app developer can¡¯t check in code for teammates, the admin app developer can help teammates to develop a good testing strategy as the testing ¡°czar¡±. In this role, the admin app developer will review teammates¡¯ tests, and advise them on deficiencies and invalid assumptions.
Tips for Success
There are a lot of steps to help you succeed. Start early. Design a solution together, as a team. Get the back-end onto Heroku as quickly as possible. Write tests before writing code. Communicate with each other.
Note: the project manager and admin app developer are ¡°easier¡± roles, in terms of programming, but they have much more responsibility and authority. These teammates will be programmers in later phases. If the code is in a poor state, they will have to do more work to catch up. Thus it is in their best interest to help teammates to succeed. You will be graded individually, but if your teammate receives an F for this phase, it means you will have more work some time in the future.
Mentorship
Each team will have one Project Assistant assigned as a mentor, and each team should have meetings with the mentor twice per week in which the mentor can mentor the team and assess its performance. Teams should take advantage of this opportunity, especially when it comes to teamwork, priorities, and technical obstacles.
T utorials
Every student should do tutorials #8, #9, and #10 [7] in order to have the necessary background for succeeding during the rest of the semester. However, it is especially important that the project manager does tutorial #8 early, and that the web developer does tutorial #10 early.
Turn-in Instructions
We will make a copy of your team¡¯s repository at some point on or after the due date. Be sure to commit and push your solution prior to the due date by branching from master into a new branch called ¡°phase1¡±.
Late Submission Policy
If you complete all the tasks, your last commit to the phase1 branch should contain the message ¡°All tasks complete, ready to be graded¡±. This will be viewed as a submission, and any future commits will not be included in your grade. If you do not push a commit with the message ¡°All tasks complete, ready to grade¡± then a snapshot of your repo will be taken by the 4th day after the deadline and used for grading. The following policy will be used for grading late submissions.
Submission late for 1 day: 15% penalty; Submission late for 2 days: 30% penalty; Submission late for 3 days: 45% penalty; Submission late for 4 days: 60% penalty;
A submission late for more than 4 days will not be graded thus receiving 0 point.
Acknowledgments
The creation and updates of this project were funded in part by the Kern Entrepreneurial Engineering Network [1]. We thank Professor Michael Spear and the Kern Family Foundation for making this project possible, and we encourage our students to emphasize the ¡°Three C¡¯s¡± in all aspects of this project.
References
[1] The Kern Family Foundation. KEEN-Engineering Unleashed, 2021. http://engineeringunleashed.com. [2] The Spark Team. Spark Framework – A tiny Java web framework, 2021. http://sparkjava.com/.
[3] Atlassian, Inc. Bitbucket, 2021. https://bitbucket.org/.
[4] The Git Open Source Project. Git, 2021. https://git-scm.com/.
[5] Handlebars.js. Handlebars.js: Minimal Templating on Steroids, 2021. http://handlebarsjs.com/.
[6] Twitter, Inc. Bootstrap – The world¡¯s most popular mobile-first and responsive front-end framework, 2021. http://getbootstrap.com/.
[7] Michael Spear. Lehigh University Software Engineering Tutorial Series, www.cse.lehigh.edu/~spear/cse216_tutorials/.