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 final 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 we have also had good experience with projects in which all meetings are by video.
• 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 can provide opportunities for recruitment.
• There is no up-front c ost to the client. Teams have access to internal servers they can use to stage the software. Final deployment on any servers will need to be done 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 adn 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.

Constraints

• Projects must be hosted using either Atlassian products (Bitbucket, Jira, etc.) or Gitlab. We typically restrict access to source code to just the instructor, students, and the client.
• One person from the client's organization can be designated to monitor projects on our servers.
• Students are responsible for design and development results. Advising faculty and course instructors do not design or develop projects or otherwise micro-manage them. Doing so would deprive student teams of ownership of project outcomes.

Process and Timelines

We start collecting new projects in March.

1. By the end of March, clients need to 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.
2. Dr. Hasker will use the paragraph to compile a list of potential projects to be sent to the students.
3. 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.
4. End of August: clients will be contacted by instructors to arrange a first meeting with each team.
5. First week of September: initial meetings with teams establishing basic scope and expectations for the projects. Teams will interview the clients for more information.
6. First three-week "sprint": teams will refine the requirements and develop storyboards capturing how users will interact with the system.
7. Week 3 or 4 of the fall term: teams will review the storyboards with clients and develop prototypes.
8. Last 3 or 4 weeks of the fall term: teams will construct initial versions of the system.
9. Winter quarter: teams will continue the project with a goal of delivering a preliminary version by the end of the quarter.
10. Spring quarter: teams will deliver a final version of the software by the end of the year.

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.