SDL Project Proposals

Thank you for your interest in providing projects for the Software Development Lab (SDL). In SDL, each team of 3 to 5 students works on a moderately large project for a full academic year. Projects start in September, with final delivery toward the end of May. Teams will attempt to deliver running systems, but deployment is the responsibility of the client.

Successful projects have several characteristics:

They must be projects that clients find valuable. If you're interested, it will be easy to get students interested.
Projects should not be in the critical path of the sponsor's business plan. Student solutions are often innovative, and they strive for robust solutions. However, there is no guarantee of success and student schedules make it difficult for them to respond to critical failures in a timely manner.
Projects must have well-defined solutions based on known algorithms. If the project involves algorithms research, other courses may be a better fit. If you're not sure, send us a proposal and we will either make suggestions to change it or help you find where it would be a better fit.
It is helpful when more than one person from the organization can be involved in the project, even if just one person meets with the students. It is rare to have one person involved in more than one project.
Projects should not involve excessive proprietary or sensitive material. Proprietary agreements are possible, but limited in forcefulness. Sensitive data is typically handled by providing anonymized versions.

Students respond particularly well to projects that provide value to a larger community. Projects for non-profits certainly fall into this category. But projects that benefit businesses also work; we just need to identify a benefit to people other than investors. Students are also interested in learning new technologies and addressing new problem areas. The key element is motivation: building useful systems and providing opportunities to learn new skills.

Clients are expected to engage with the students throughout the project:

They should plan to meet with the students approximately twice a month, possibly with additional meetings early in the project. It is great when the client can visit the lab, but video-based meetings work as well.
A particular student will be tasked as the primary point of communication, but we encourage clients to contact the instructor if there are questions the team cannot answer or issues to discuss.
It is important that the client contact the instructor if business needs change and the project is no longer useful. We will then redirect the team to other tasks. If a client continues a project in spite of losing interest in the outcome, student morale drops and the organization can receive poor word-of-mouth publicity. Successful projects often provide opportunities for recruitment.
There is no up-front cost to the client. Teams have access to internal servers they can use to stage the software, but deployment will have to be done using off-campus servers set up by the client.
Generally, the client pays for travel and additional resources such as specialized hardware, but we may be able to find sources of funding for some public-service projects.
It's fine to specify the platform and programming language. It is common for teams to learn new technologies to support projects.

We will consider multi-year projects, but we cannot guarantee that any particular project will be picked up by a team in the following year. It generally works best to break large projects into smaller pieces with a different portion implemented each year. It is critical that students in successive years have important new features to implement rather than simply refining existing features done by previous teams.

Constraints

Projects must be hosted using the school's GitLab account. We typically restrict source code access to just the instructor, students, and the client.
The expectation is that the students will be fully responsible for the design and implementation of the system. This is important to ensuring the students have ownership of project outcomes. However, the expectation is that the students will follow any (feasible) guidance provided by the client.

Process and Timelines

Ideally, we start collecting new projects in March. However, we will accept ideas any time in the year.

When proposing a project, clients should write a paragraph briefly describing the problem to be solved, how that system will benefit users, and what technologies will be involved. Email that to hasker (at msoe.edu). You are encouraged to contact Dr. Hasker either by email or phone (414-277-7326) if you have questions or need help refining the idea.
Dr. Hasker will use the paragraph to compile a list of potential projects to be sent to the students.
Mid-April: students will rank the projects by interest. In the past we have made final assignments during the summer, but we are experimenting with notifying students earlier.
End of August: clients will be contacted by instructors to arrange a first meeting with each team.
First week of September: initial meetings with teams establishing basic scope and expectations for the projects. Teams will interview the clients for more information.
First three-week "sprint": teams will refine the requirements and develop storyboards capturing how users will interact with the system.
Week 3 or 4 of the fall term: teams will review the storyboards with clients and develop prototypes.
By the end of the fall semester: teams will have completed two full sprints implementing core features.
Spring semester: teams will continue the project with a goal of delivering a final version, including an automated test suite, by the end of the academic year. Students are also asked to prepare materials describing the system structure for use by future teams working on the same project.

Note there is no expectation that students will work on the projects over the summer months.

Successful Projects

The following is a partial list of successful projects to help clients determine scope and evaluate ideas:

For an avionics company, software to track system vulnerabilities.
Kiosk systems for art work at a company.
Software used by the computer science and software engineering programs to collection programming solutions and evaluate them against a number of test cases.
A registration system used by Tutoring Services at MSOE to allow students to request tutoring and to assign tutors to those students. This allows tutors to start working with students much earlier in the term.

Projects from previous years are available: