CS 5150: Software Engineering (Spring 2025)


Projects

Software engineering concerns the production of software by teams of developers for use by others. Therefore, a major component of CS 5150 is a semester-long team project whose requirements must be extracted from clients. The main constraints are:

Project Deliverables

Teams have some freedom to define their own milestones and intermediate deliverables, but several reports and presentations are required at predefined intervals (typically once per three-week development session). Reflections and peer evaluations will also be collected at these times.

  1. Project plan (due Fri., Feb. 7)
  2. Report #2 (due Fri., Feb 28)
  3. Report #3 (due Fri., March 25)
  4. Report #4 (due Fri., April 18)
  5. Final delivery (due Tue., May 10)

Presentations must be given to clients and instructors during sessions 3 & 5.

  1. Midpoint presentation (March 7–25)
  2. Final presentation (April 18 – May 10)

The contents of the intermediate reports will largely depend on a team’s selected methodology, but some common elements will be required of all teams.

External projects

External projects must meet certain requirements to be eligible for CS 5150.

Business considerations

External projects must take into account potential concerns regarding copyright, patents, trade secrets, data stewardship, and conflicts of interest. Included with your project plan should be a signed agreement between the client and your team addressing any relevant considerations. The client must be allowed to use and extend your software after it is delivered, so at a minimum you must decide how this permission will be granted (typically by either transferring copyright to the client or by providing the client with an unrestricted license).

See copyright for external projects for examples of external client agreements from previous semesters.

Internal projects

Teams in CS 5150 may add features to one of the following open-source projects. These host projects are all developer tools, allowing everyone to be familiar with the problem domain (this also allows you to incorporate dogfooding into your development process).

Gerrit

A code review tool maintained by Google to facilitate their contributions to open-source projects in Git repositories (such as Android).

Website
www.gerritcodereview.com
Backend
Java 11
Frontend
Polymer, TypeScript
Build system
Bazel
Data store
Git (via NoteDb)

Review Board

An open-source code review tool developed since 2006.

Website
reviewboard.notion.site/reviewboard
Backend
Python 3.7 (Django)
Frontend
HTML (Jinja), LessCSS, JavaScript
Test framework
nose→pytest, Jasmine
Data store
SQL database

Code Translation

A tool that translates code from one language to another.

Language Pairs
C/C++ to Rust, Javascript to TypeScript, Java to Kotlin
Project Selection
The source project should have at least 1000 lines of code, be open-source, and have at least 100 stars on Github. A list of pre-approved projects will be provided.
Quality Assurance
The translated code should be functionally equivalent to the original code, the code should be well-documented, and should be thoroughly tested.
Pre-approved projects:
Project List

See internal project options for a list of capabilities that course staff would like to see added to the above applications.

Stakeholders

Ideally, the clients requesting these features would be distinct from the course staff, but that arrangement is not feasible for this offering of the course. Therefore, in order to keep discussions of “class mechanics” (grades, lecture material) out of your client interactions, please reserve such topics for office hours. For scheduled meetings, course staff will always assume a client role.