Home on SDL: Software Development Lab

Mon, 01 Jan 0001 00:00:00 +0000

Project Contribution Report for SDL

Write a PDF as directed below. Use sections of reports, screenshots of GitLab, screenshots of your application, sections of code, portions of documents, or other materials to provide evidence of contribution in each of the following areas. Be sure to include the material in the report; do not link to other documents. Be careful to keep your evidence relevant; it's quite preferable to provide one or two detailed examples and then describe your other work rather than simply dump everything you did into the report.

Mon, 01 Jan 0001 00:00:00 +0000

Evaluation used by Dr. Hasker

List each of the other team members. For each, give three numeric evaluations:

Their contribution to the product
Their contribution to quality efforts
Their contribution to team process

Use a scale from 1-5 for each:

Mon, 01 Jan 0001 00:00:00 +0000

Design Review

Teams are asked to present their system design in the fourth sprint of the fall semester. This presentation is to be focused on just the architecture and other design elements; the final semester presentation will be the place to review the features added (or planned) and the process. The design presentation is to be about 10 minutes in length covering

Mon, 01 Jan 0001 00:00:00 +0000

End-of-semester Presentations for SDL

Each team will present their projects:

Your primary audience is the other students in SDL. A successful presentation is one that gives good takeaways for the other students. The last slide needs to review those takeaways. Consider capturing lessons learned about software process, lessons learned about the technology you used, pithy observations about using genAI on projects, alternative technologies that you tried but abandoned, or some other takeaway that the other students are not likely to know but will help them in future projects.

Mon, 01 Jan 0001 00:00:00 +0000

Docker for SDL

Why?

There are two recurring problems in SDL projects that often block forward progress:

It works on my machine: Tests run on one person’s computer but not another’s, typically because someone has installed a slightly different library or has configured some option slightly differently. Software has to work all of the time; it is not enough that one person on the team can run the software. Everyone, including clients, must be able to run it using published configurations.

Mon, 01 Jan 0001 00:00:00 +0000

Assignment 1: BDD Introduction

Motivation: Software Development Challenges

If it ain’t tested, it’s broke. This is a quote from an avionics testing engineer. Testing cannot prove software works, but its almost certain that untested software does not work. The typical solution is do a bit of manual testing after writing code, but these tests are not repeatable. Written tests are slightly better, but too expensive to re-execute often. They do little to improve stability. But you probably have a lot of experience with software working today but not tomorrow. Errors always creep in. It critical to establish a thorough, automated test environment early in the project, and clients are unlikely to find systems without tests to be useful or maintainable.

Mon, 01 Jan 0001 00:00:00 +0000

Adding BDD to your SDL project

This assignment will give you experience with applying automated behavior-driven development (BDD) to your SDL project. It assumes that you have successfully completed the BDD introduction assignment and quiz.

Mon, 01 Jan 0001 00:00:00 +0000

Assignment 3: Knowledge Transfer Video

Assignment: Project Knowledge Transfer Video

This assignment is due Friday May 8, 2026 at 11:59 PM. NO LATE SUBMISSIONS WILL BE ACCEPTED. NO EXCEPTIONS.

Objective

The purpose of this assignment is to create a professional, high-quality video that documents your team’s project for future student groups. This video should serve as both a showcase of your work and a practical onboarding resource that helps others understand, set up, and extend your project.

Mon, 01 Jan 0001 00:00:00 +0000

Documenting Meaningful Test Suites

Include title information: A title for the assignment, your name, the date, and the course code (e.g., SWE3720).

Provide a link to a file with a suite of tests you wrote that is available on the main branch. (This means that you must perform a merge to main with at least that test if it is not already on the main branch.)

Mon, 01 Jan 0001 00:00:00 +0000

Individual Assignment: Writing Documentation

Each student will write documentation.

Ideally, this will be planned during Sprint 4, but could carry over into Sprint 5 for individual students if other activities take priority.

Mon, 01 Jan 0001 00:00:00 +0000

SDL site

Hugo site (PaperMod theme) for the Software Development Lab courses, published to GitLab Pages. The whole repository is mounted as content — see the header comments in hugo.toml.

Mon, 01 Jan 0001 00:00:00 +0000

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.

Mon, 01 Jan 0001 00:00:00 +0000

Title: Potential Projects for 2026-2027

Potential SDL Projects for 2026-2027

There are two Software Development Lab instructors for next year. Some of the following projects are assigned to a specific instructor, but others will be determined based on interest. Continuing projects include both those under current development and ones that were developed in the past. In some cases the technology is specified, but in others the team can help pick the technology with the product owner’s approval. Projects are generally in alphabetical order and numbered for convenience.

Mon, 01 Jan 0001 00:00:00 +0000

Best Practices for SDL

Teams should adhere to the following practices, but may vary from them after consultation with the instructor:

GitLab Configuration:
- All students on each team should have Developer role. We can give them Maintainer role temporarily when required. Set the expiration date to July 1 or February 1, as appropriate.
- Disallow pushes to the main branch. This is ensured by going to Settings, Repository, Branch rules, view details, Manage in protected branches, and select No one for Allowed to push and merge. Allowed to merge will be set to Maintainers (or Maintainers + Developers).
- Disallow squash commits: Settings, Merge requests, scroll down to Squash commits when merging, set to Do not allow. Save the changes.
Git standards (for all repositories):
- Configure your git setup so check-ins and check-outs are as-is. This means git will not convert line endings between Unix/Window/Mac formats. The conversions are not needed since all modern editors can handle different formats. Allowing git often breaks deployment. You can set this by editing your .gitconfig file to include the text

Mon, 01 Jan 0001 00:00:00 +0000

Use this .gitlab-ci.yml as a starting point for your CI system:

image: docker:latest
services:
- docker:dind
stages:
- build
build:
stage: build
script:
- docker build .

The first line says you are using the latest version of Docker; once things are working, specify the version for extra robustness. The build entry specifies how to do the build, which is just executing the docker build . command you are used to using in Ubuntu. The stages entry just specifies doing the build stage; one could add additional stages for things like continuous delivery or to build multiple versions of your project.

Mon, 01 Jan 0001 00:00:00 +0000

Configuring VirtualBox with Ubuntu

(If useful, also covers using Docker)

This will enable teams to develop on Linux on their laptops, avoiding problems with connecting to services over a network. Many teams will stage their system on a remote server, but enabling local access

Mon, 01 Jan 0001 00:00:00 +0000

SDL Sprint Report Instructions

Revision Spring 2026

Drs. Yoder and Hasker

Sprint Review and Retrospective

The Sprint Review and Retrospective Report summarizes what portion of your sprint goals were completed (the “review” portion) as well as how your team performed in achieving those goals (the “retrospective” portion). Prepare this document carefully! Be sure this document makes it obvious what you and the team accomplished and how the process will improve in the next sprint. Screen shots capturing your progress are critical. Consider including screen shots of other important results such as establishing a continuous integration (CI) system or meeting a code coverage milestone. This document provides evidence of your accomplishments and is a major part of each sprint’s grade.

Mon, 01 Jan 0001 00:00:00 +0000

Sprint XXX Review and Retrospective for CURRENT PROJECT NAME

===============================================================

Member 1, Member 2, Member 3, Member 4, Member 5

Sprint Start, End: date to date

Sprint Review

Sprint Goal

PLACEHOLDER: Restate the sprint goal and relate it back to the project as a whole. No need to mention PBI numbers in this section.

Mon, 01 Jan 0001 00:00:00 +0000

SWE 3710: Software Development Laboratory I

Fall 2026

Instructors: Dr. Rob Hasker, Prof. Alexander Pezewski

Office hours: see Canvas

Course Description: The software development laboratory provides students the experience of working in a team on large-scale projects using software engineering tools and techniques. In this first course in the sequence, students are introduced to the laboratory environment and work on assigned tasks as members of project teams. As students develop individual and team skills, they take on additional responsibilities on project teams.

Mon, 01 Jan 0001 00:00:00 +0000

SWE 3720: Software Development Laboratory II

Spring 2027

This document is written for the spring semester; see this page for the fall schedule

Instructors: Dr. Rob Hasker, Prof. Alexander Pezewski

Office hours: See Canvas

SDL Sprint Report Instructions

Mon, 01 Jan 0001 00:00:00 +0000

Revision f23

Drs. Yoder and Hasker

Sprint Review and Retrospective

The Sprint Review and Retrospective Report summarizes what portion of your sprint goals were completed (the “review” portion) as well as how your team performed in achieving those goals (the “retrospective” portion). Some of this material may duplicate your other planned deliverables. Your instructor direct that you place this material in those deliverables instead of your sprint report.