Customer-focused Web Application Development for Community Partners

In CSCI312 “Software Development” students spend the second-half of the semester (6 weeks) working in teams of 5-7 developing modern web applications. Past projects have been wide-ranging including social media sites, games, tools in-class learning, interactive art projects and more. An example of a past CSCI312 project is https://www.middmarkit.com. Historically the students propose the projects and serve as their own “customers”. Working with actual stakeholders would simultaneously enhance the learning experience and create value for community partners in need of technology tools.

Middlebury Contact: Michael Linderman

CSCI312 is focused on the process of software development, not a specific domain area. Thus, there are few, if any, constraints on the goal or purpose of the application. The specific technologies students are learning are best suited for (and the course learning goals centered around) applications designed to dynamically respond to user input and/or actions as opposed to conveying relatively static information.

The CSCI312 faculty provide feedback and guidance on the student’s development processes, design and implementation. They are experienced software developers, but may not have hands-on experience with all the particular tools students are using, e.g., Google Maps, or be knowledgeable in the topic area (e.g., energy monitoring)

Students will have spent the first half of the semester learning how to develop “full-stack” web applications using the Next.js framework and React. These are “lower-level” tools for building highly interactive websites (as opposed to building applications with a content-management system like WordPress). Students will further be practicing techniques for working with stakeholders to define desired features and respond to changing requirements. The students are required to use these tools and processes for the project.

We typically offer CSCI312 each semester. Students submit project proposals at the beginning of week 5 and begin working on the project in week 6. The first week is focused on defining the desired features and beginning the design process. The remaining 6 weeks are divided into 3 two-week “sprints” in which student teams are developing new features for their applications. Each sprint begins with a design meeting to identify the goal for the next two weeks, and culminates in a short demo and process retrospective. Students teams will have approximately 300 person hours to dedicate to the project.
While there are few constraints on the goal of the project, the following kinds of applications are generally not a good fit for this course:
  • A mostly “static” website, or a site that could be managed with an off-the-shelf Content Management System (CMS), e.g. WordPress or Drupal.
  • Native mobile applications.
  • Applications that rely on frameworks or APIs, e.g. Salesforce, with lengthy approval processes or that don’t have free starter/trial plans that students can use to get started without arranging payment.
  • Applications that handle sensitive data (e.g. health data protected by HIPAA or FERPA-protected student data).
  • Applications with intellectual property/ownership concerns.
  • Applications that rely on domain-specific technologies not covered in the class itself, e.g. GIS. While individual students may have relevant domain expertise, we are unlikely to be able to assemble a full team with such expertise.

Students are often building their first such application and doing so in a compressed time frame. Further, the course learning goals emphasize “perfect practice” over development velocity. As a result, the final product is often more of a proof-of-concept than a polished, production-ready, application. Projects that are not on an organization’s “critical path” but instead complements existing efforts, or are an exploratory proof-of-concept would be the best fit. During the proposal phase, the instructors would work with the partner to develop a 1-page proposal outlining the major functionality (as a series of structured sentences, e.g., “As a potential volunteer I want to complete the entire volunteer application online, including submitting contact information for my references, so that I can efficiently sign-up to become a volunteer”). During the project itself we would want the student teams to connect with their partners at least every two weeks to demo the current progress and identify the goals for the next two weeks (typically 0.5-1 hour). At the end of the semester we host a longer set demos where the teams show all the features of their applications. Student teams may also have questions in between the scheduled demos.

Categories:


Published On: February 29, 2024

Share This Opportunity!