Getting Started

Slides

The major outcome for this course is a project that demonstrates your skills in computer science, software development, and other areas relevant to your chosen degree program. This page provides an overview that will help you get started on your project.

Research Topic

Starting in Spring 2023, we now have a special track for topics that fall generally under the heading of “research” instead of a software development project. This includes projects that may have a significant experimental component where the focus is less on developing a software project and more about creating software to support a research task. If you feel that your project fits this description, you should skip to the Research Topic page.

Recommended Timeline

Here is a recommended timeline for your project:

Week 1: Identify a project, get a project advisor.
Week 2: Report your project topic and advisor. Start developing.
Week 3: “Hello World” Complete.
Weeks 3-8: Overview & Requirements Presentations & First Round of Development.
Week 8: Minimum Viable Product (MVP) Complete.
Weeks 9-14: Design Presentations & Second Round of Development.
Week 14: Schedule Final Presentation & Create Promotional Materials
Week 15: Version 1.0 Feature Complete.
Weeks 15-16: Final Presentations.
Week 16: Submit Final Materials.

Choosing a Topic

The first major step is to identify a possible topic for your project. It should align with your interests in the field, and it may also fit well with previous courses you’ve taken or possibly future career paths. You may also choose to use your project to explore a new topic or framework that you’d like to get experience with.

You are also welcome to choose to try and duplicate an existing program from scratch, putting your own spin on it and writing the code from scratch. For example, you may choose to try and duplicate the underlying code and features for a popular social network - in effect your project is driven by their design, but you have to figure out how to build it and code it yourself.

Finally, if you are having trouble finding a topic, consult the Project Ideas folder on Canvas for project ideas that have been submitted or previous projects that could be continued. You can also chat with the course instructors to get some ideas of a project to consider, or if you have an advisor you’d like to work with, chat with them for some ideas.

Topic Limitations

We do not recommend choosing a project topic that you have no prior knowledge or experience with. For example - do not choose to make a complex video game if you haven’t made a game before, either as part of the class or as an independent project. Likewise, do not choose to develop a single-page web application if you don’t already know HTML, CSS, JavaScript, and the basics of web application development.

Generally students who choose a project topic that requires a large amount of learning end up producing inferior projects simply due to the amount of time spent early in the semester learning the basics. It is best to choose something you already know something about, but would like to explore further.

Features to Consider

As you consider project topics, remember that completed projects must include these two items:

Problem/Solution In the initial discussion of the project, you should be able to phrase your project as a solution to a selected problem. For example, you could say that the problem is “a need for accurate record keeping for a winter warming shelter” and that your solution is a “web application that is accessible on mobile devices.”
Algorithmic Functionality Each project must include some significant algorithmic component. This means that web applications must do more than just present and store data using the basic CRUD database functions, and video games must have more than just hard-coded levels and enemies. So, be thinking about how you can demonstrate a significant algorithmic component in your project.

Code First

When selecting your project topic, remember that the goal of this project is to develop a large amount of code as part of a software project. So, if you plan on using tools such as a drag & drop UI creator or a visual game engine such as Unity, you still need to make sure that the bulk of the project is code that you’ve written yourself. Any code generated by these tools is not considered a core part of your project since it doesn’t demonstrate your programming skill.

You can demonstrate your skill instead by building UIs directly in code, writing algorithms to automatically generate assets in a video game, or choosing to use a “code-first” UI design or game engine.

Finding an Advisor

Once you’ve identified a project, you’ll need to select a faculty advisor to work with. Throughout the semester, you’ll meet regularly to discuss your project with your faculty advisor, and follow their guidance to produce a quality product.

Typically you want to choose a faculty advisor that is familiar with your project area, since they will be most likely to be able to provide good assistance and feedback as you work on your project.

If you aren’t sure which faculty members may fit well with your project idea, contact the course instructors or consult the information on the CS Faculty webpage.

Advisor Responsibilities

Each advisor approaches senior projects differently, but in general your advisor will typically ask you to do the following:

Provide an overview of the project and a list of features to be developed.
Meet weekly to provide status updates on the project.
Read or review additional information, research papers, etc. related to your project.
Share your code and other project artifacts for review
Schedule a final project presentation

Initial Artifacts

At the very beginning of your project, you should create a few initial artifacts to start the development process:

Writeup: prepare a short, 1 page writeup that describes your project topic. It should give some basic use cases and a rough idea of the architecture or platforms you plan on using in the project. Your writeup must include clear sections containing the following:
- Problem/Solution A clear statement of a problem that you are trying to solve, and how your project will fill the role as a solution to that problem. There are many ways to approach this statement - consult the course instructors for assistance if you are unsure how to phrase your project in this way.
- Use Cases A list of a few simple use cases that help describe how users will interact with your project.
- Algorithmic Functionality A clear statement of the intended algorithmic functionality of your project. Your project must include some algorithmic functionality beyond the basics. For example, a web application should provide more than just the basic CRUD database operations. Likewise, a video game should include some complex algorithmic component such as procedurally-generated terrain or a learning AI beyond just simple, hard-coded content.
- Student Qualification A clear statement explaining why you are qualified to take on this project. You must describe your background and experience with the chosen project and related technologies. If you have no prior experience, consider choosing a different project.
- Project Advisor List your project advisor. You must have permission from your advisor confirming that they will supervise your project before submitting!
Feature Lists: prepare three sets of feature lists for your project:
- Minimum Viable Product (MVP) or must haves: these are features that must be present in the project for it to function in the basic sense. It usually doesn’t include much in the way of user interface beyond the basic interactions, and it may be missing some additional items to make it more useable. A project that has these features could be considered a Minimum Viable Product. Typically you want to have these features completed in the first 8 weeks of development.
- Version 1.0 or should haves: these are features that should be present in the project for it to be considered complete. This would involve additional usability features or links to other APIs as needed. A project with these features would be considered a 1.0 product, and could be used by others. Typically these features are completed in the second 8 weeks of development.
- Version 2.0 or would like to haves: these are cool features that would be useful to have in a finalized project, but they may be outside the scope of what is achievable in a single semester. The lack of these features should not impact the useability or functionality of the project. Typically these features are simply listed on the “Future Work” portion of the final presentation, but if you complete the project ahead of schedule you may consider adding one or more of these features to the project.
Time Management Plan: prepare a detailed time management plan for each week of the semester. This helps ensure that you are able to devote 9 hours each week to this class, and also ensures that you save enough time for other classes and activities.

These artifacts are not “set in stone” and can be easily adjusted throughout the project. For example, you may find that a feature previously on the Version 2.0 list is not critical, and it moves to an earlier list.

Hello World

The next step in creating a successful project is getting to the “Hello World” stage. This typically involves configuring your development environment, creating a new project or downloading an existing project, and confirming that you can successfully build and run the project in its simplest form. Ideally, you should be at the “Hello World” stage of your project no later than week 3, and ideally much sooner. This is especially important if you are learning how to use a new framework, programming language, or tool, as it may require significant work to get to this stage alone.

Once you are at the “Hello World” stage, you are at the point where you can start adding features to your project from the feature lists described above. A great way to think of those feature lists is like the Product Backlog in the agile software methodology - it is a list of project requirements to be completed.

Warning

OneDrive is NOT good for code - use git!

One common issue that students run into in this class is storing their code repository folders in a folder synched with OneDrive causes issues - especially if you use OneDrive to sync your work between multiple systems. This can cause all sorts of headaches since OneDrive wasn’t designed to work well with code, and large projects can result in thousands of text files that need to be constantly synched and updated as you make changes. It is further exacerbated by putting a git repository inside of a OneDrive folder - that is a recipe for your git repository to become corrupted and potentially unrecoverable if a sync error occurs.

Instead, you should always store your code repository folders outside of anything synched to OneDrive (I like to just make a projects folder inside of my profile folder on my system, so the path would be C:\users\russfeld\projects or /home/russfeld/projects) and work from there. Inside of that folder, you should clone your GitHub Classroom repository that has already been set up for you and start working from there. If you’ve already created a project, you’ll need to manually copy the code into that folder and commit it - you can’t push an existing repository to GitHub Classroom without causing major issues.

Also, if you haven’t created a .gitignore file for your project, now is a great time to do so. You should never commit binary files, build artifacts, or external libraries to your GitHub repository - that just causes unnecessary repository bloat and makes things much harder to deal with down the road. There is a GitHub repository full of sample .gitignore files for just about every IDE and framework imaginable - see https://github.com/github/gitignore.

Tip

Project Scale and Scope

One area that many students struggle with is finding a project that has the appropriate scale and scope for a senior project. While there are no clear rules for this, and each student’s situation is different, here are some suggestions for finding an appropriately sized project.

The course is 3 credit hours, which roughly equates to an expectation of 9 hours of work each week. Across a 16 week semester, that comes to a total of 144 hours, or just over three and a half 40 hour work weeks if you worked on it full time. You’ll be tracking your hours worked throughout the semester, and that may help you make sure you are spending enough time on your project.
If you are working in a new framework or language, you should work completely through the initial tutorial in the first couple of weeks of class. Your finished project must go significantly beyond what is covered in the tutorial.
Typically projects will have 3-4 major features that make up the minimum viable product, and another 3-4 major features for version 1.0. Each feature should require 1-2 weeks of effort to implement.
Your advisor and course instructors can help you determine if your proposed project has appropriate scope, or if it needs modification. You should consult with them early on in the process, and continually update them on your progress, especially if your planned features change.

Next Steps

At this point, you should be well into development on your project. The next page discusses the weekly work to be performed as part of this project.