This course includes a project that will enable teams of students to put the lessons from this course into practice. This page provides summaries and information about each of the projects, and point to external project resources.

Staffing

Projects should have between 6 and 10 team members. Smaller projects make it difficult to have a realistic experience with putting sofware engineering principles into practice, and large projects introduce complexities that do not add to the learning experience.

Forming a project team

Projects often form based on interesting ideas from one or more class members, who then find others who would also like to work on that kind of project. Putting ideas out there and finding others to join the team members is a real-world challenge.

One mechanism is to use the "Search for Teammates" feature on Piazza. See post @5 in the CS 5500 Piazza group to post an idea. You can also use the feature to indicate that you are looking for a team to join.

The instructor can also provide help in forming teams and introducing students who have not located a team.

Registering a Project

• DUE DATE: Thu., Mar 11 2021 by 11:59:59

Once you have a project concept and have formed a core team, register the project by posting a private note to the instructors on Piazza with the summary line "Register Project" with the following information:

• Short project name (e.g., "Enterprise GitHub plugin for Slack")
• One or two sentence project description
• Project methodology (e.g., "Open-source")
• Technologies (optional)
• Team member names and Khoury IDs
• Primary contact and secondary contact

The instructor will enter your project and team information in the course management system, and create a GitHub project repository and ateam and send the information to the primary project contact. Each member of the team will have full admiminstrative capabilities for the project.

After the due date, the instructor will form teams from any students not currently on a project or assign them to existing projects. The instructor will also contact teams with fewer than the minimum number of members to facilitate merging with other teams in the same situation.

Sample Projects

Here are a few sample projects from past semesters.

• A social application for students and employees in tech industries to share studies, life, and careers.
• An application that allows users to create and attend activities based on their interests.
• A web album and front end application for a photo database.
• An online voting application.
• A food ordering application to help restaurants simplify the customer ordering experience.
• An application that for users to catalog their physical books and ebooks and information about them.
• An application for movie theater customers to rate movies, and for other customers to vote for reviews.

Setting up GitHub Repository

• DUE DATE: Thu., Mar 25 2021 by 11:59:59

• Upgrade the README.md Mark Down file to provide an overview of your project. The audience for this page is the team, as well as the course staff who will periodically visit your project to check in on how things are going. This page should provide an orientation to your project repo, with information about what is stored where. At the top of the README.md file, provide a summary of the project and a list of the project team including names and khoury-ids. Also list the primary and alternate customer representative. Here is a link to a Markdown Cheatsheet.
• Create a public webpage for your project in a new "docs" directory using the GitHub Pages feature. Even though your project is currently private, the GitHub Pages website is public within NEU. Your team can use this landing page and any related pages to provide a public face to your project, We can share GitHub Page URLs with other teams so everyone can keep up with what other teams are working on. Make it look nice!
• Create a project Wiki that can be used internally by the team to record knowledge about the project. Start with an article about the project itself. You could add articles to documment decisions your team makes, architectural information, designs, knowledge about implementation, etc.. This could be your projoect knowledge repository. Your team should discuss how (and to what extent) to use the wiki for your project. Did you know that there is a Wikipedia page about Wikipedia? Here is a link to an introduction to using a GitHub Wiki to document your project.
• Create a repository GitHub Project Board. A GitHub Project Board provides a simple way to manage a project when all of the artifacts are in a GitHub repository. Here is a link to an introduction to GitHub Project Boards.

Repository

This deliverable is the complete project checked in to the team's Khoury GitHub repository. The repository should contain all the development code plus complete documentation that enables a developer to understand the contents of the repository. This includes any external documentation for the project as PDF or MD files so they can easily be examined from GitHub. Also check in PDF versions of any presentation material. You may additionally check in the original formatted documents (e.g., MSWord or PowerPoint) with the PDF versions. Finally, the repository should have a GitHub Pages landing page with information about the project and product to share with the class. More in-depth pages are encouraged.

The contents of the repository should be complete enough that a developer could check out the code, create a project, and do further development. If the GitHub repository is a web application that includes a Node.JS project directory tree, exclude the "node_modules" directory as that can be rebuilt from the "package.json" file.

The repository "README.md" file must include:

• the name of the project
• the names and Khoury/GitHub IDs of all the project participants
• a short summary of the project and the repository contents.
• a link to the GitHub Pages landing page
• a link to a deployed application (if a web application)

Presentation

The deliverable is a 25 minute presentation about the project. The presentation should cover the following topics, in whatever ordeer makes sense for the project:

• the purpose of the application
• the major features of the application
• the technologies used in the application
• the development methodology
• the development process
• the organization of the repository
• demonstration of the application

The team can decide whether everyone presents portions of the project or one person serves as the primary presenter. Each presenter should introduce her or himself.

In lieu of a live demonstration of the application, the team may pre-record a demo of the product. If the demo is pre-recorded, provide a link to the recording in the "README.md" file. This link will also be made available to the class on the project pages below. This recording must remain available until at least the September 1 2021 so everyone has a chance to view it. The presentation may show a part of this video if it wishes.

The project will be evaluated using the following factors.

• Presentation (15 pts). This factor evaluates the team presentation, including how well-organized the presentation is, whether it covers the the important points of the project, the use of visuals, and the effectiveness of any product demonstration.
• Repository (15 pts). This factor evaluates the repository history, including whether the history of the development is reflected in the repository history, how branches were used, and the use of pull requests.
• Functionality (15 pts). This factor evaluates the functionality implemented by the product. It considers how well the functionality provided matches the requirements documented in the product requirements specification. It also considers whether the implemenation of the functionality is adequate to support the intended use of the product. Finally, it considers whether the feature set provided seems reasonable for the size of the project team.
• Organization (15 pts). This factor evaluates the organization of the repository, including the structure of the repository and its contents, and whether the repository directories provide descriptions of the contents (e.g. with "README.md" files). The evaluation will consider how easy it is for someone who is not familiar with the project to explore the repository and understand its contents.
• Methodology (15 pts). This factor evaluates evidence of applying the chosen methodology during the project. This includes communications, documentation of processes (e.g. backlog decisions, user stories, milestone tracking, issues), communications, and use of tools (e.g. GitHub project poards, wikis, issues, etc.).
• Code (10 pts). This factor evaluates the project code to ensure that it follows good engineering practices, including the quality of the code, whether the code includes adequate documention, whether any tests are provided for the code, whether there are scripts for building or packaging the code, and whether there is any external documentation describing the code, its organization, and how to build or deploy it.
• Documents (15 pts). This factor evaluates the external project documentation. This includes project organization, requirements, features, functionality interfaces or APIs, design, communications plans, and test plans

Presentations will take place on Tue, Apr 27th and Wed, Apr 28th from 12:30pm - 5:00pm. Each group had 25 minutes to present their project, with a 5-minute gap between presentations. There was a schedule break from 2:30pm to 3:00pm. Schedules for the presentations appear below. Following the presentations, Zoom links to the individual presentations will also be provided. The links are to the individual presentations on Zoom. The access code is 6=f@4U=h

1. 12:30pm - 12:55pm: Bay Area Life (view)
2. 1:00pm - 1:25pm: Book Review (view)
3. 1:30pm - 1:55pm: Cars Find You (view)
4. 2:00pm - 2:25pm: My Fitness Pal (view)
5. 2:30pm - 2:55pm: BREAK
6. 3:00pm - 3:25pm: HopLog (view)
7. 3.30pm - 3:55pm: Face Mask Detection (view)
8. 4:00pm - 4:25pm: My Review (view)
9. 4.30pm - 4:55pm: MedMinder (view)