SWE 3710: Software Development Laboratory I

Fall 2023 and later

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.

Prereqs: SWE 2410, SWE 2710 (quarter system prereqs: SE 2800, SE 2811)

Format: 2 lecture hours, 2 lab hours, 3 credits

There is no textbook for this course.

Course Learning Outcomes: On successful completion of this course, the student will be able to

Grading: 

  Percentage  
Sprints  60%
Contribution Report  25%
Peer evaluation   5%
Presentations  10%
Total: 100%

The MSOE grading scale will be used, though higher grades may be awarded to individual students if it increases fairness. In addition, successfully demonstrating mastery of course outcomes is a prerequisite for a passing grade. Failing to meaningfully participate in the project may result in being administratively dropped from the course.

For an A in the course, you must make significant contributions. This includes both technical and process contributions. Process contributions include project tracking, reviewing deliverables, providing leadership in an aspect, etc. Technical contributions include designs, implementations, tests, and other activities leading to a viable product. Both are required of all students; simply writing code is not sufficient. To engage effectively in both and get an A, you will need to log at least 125 hours for the term. This must be distributed evenly throughout the term, meaning you need to plan on approximately 10 hours per week on the project. If this is too much time, you may wish to postpone engaging in SDL. Students can put in more time without penalty, but the 130 hours (spread evenly) per term is sufficient except when a student is explicitly informed they need to do more to address inadequate performance. While 130 can be considered the minimum number of hours, it is not the maximum. However, working more than 130 hours does not, in itself, increase the likelihood of earning an A.

Team Formation

The course coordinator and instructor will work together to determine team and project assignments. Assignments will be based on such factors as student interest, loads between sections, and the needs of individual projects. Generally a student will remain on the same team for SWE 3710 and 3720, but this may change when necessary. Reasons for changes include (but are not limited to) students studying abroad, students failing any of the courses in the sequence, and product owners determining a project is finished.

Schedule

Each term is broken into four sprints with additional planning weeks. The schedule is as follows:

Ensure your spike PBIs have verifiable acceptance criteria. "Customer approves" is not an appropriate acceptance criteria; express it in terms of actions that can be accomplished by users.

A key element of these spikes is that they will not be moved into your project. We will require that different group members implement each of the features given here in sprint 24f3.

Weeks Sprint Objectives
1 Initial Project Planning
  • Meet with Product Owner (PO)
  • Assign Product Owner Proxy (POP) for year
  • Assign roles for sprints 24f1, 24f2. The other roles are
    • Note-taker: responsible for capturing notes from each meeting, including the review and retrospective. Notes must be shared on the appropriate forum. The note-taker is responsible for sending the review and retrospective document to the product owner. The note-taker will record meeting notes starting with the flex week.
    • ScrumMaster: responsible for ensuring appropriate process is followed.
    • DevOps Lead: responsible for documenting build instructions (to be in the doc folder), for documenting any test procedures, and for monitoring and maintaining the running status of any CI systems.
    Teams may identify other roles in consultation with the instructor.
  • There is to be a single repository for each project. (Prototypes can go into a separate project if convenient, but any code and documents relevant to a future team must be in one repository.)
  • Initialize the repository with "main", "dev" branches and "doc" folder (again, all lower case). The doc folder will contain build and deployment instructions, general requirements, mock-ups/storyboards, designs, and other information that is required to maintain the system. The doc folder should not contain project reports or other materials related to process.
  • The team will create PBI-specific branches; how those branches are named is up to the team, but please do use lower case letters for their names.
  • Create a Readme file at the top level of the project. This file must include
    • The names of all team members.
    • The names and organizations of key external clients, especially the PO.
    • The project's purpose in a sentence or two.
    • Key technologies used for the project.
    • The name of the file in the doc folder giving build and test instructions.
  • Identify technology assignments by team member.
  • Set up your GitLab issue board with the following columns:
    • Open - issue is in the sprint and ready for work
    • In Development - issues for which work has been started
    • Blocked - issues for which progress is blocked by an external entity (not your PO!)
    • Ready for Review - issues which the developer considers done
    • Closed - issue closed by the PP
  • Create sprint 24f1; note that the ' f ' is lower case
  • Create the 24f1 backlog; see the 24f1 discussion below.
  • Identify key epics to be completed for the project. This list is expected to grow as the project matures.
2-4 24f1
  • Finalize project scope. For some projects this will include creating storyboards, high and low fidelity mockups, and/or user interface prototypes. Discuss the project needs with your instructor and your product PO, and review any created documents with the PO.
  • Technology assignments: individual assignments geared toward learning a technology to be applied in the year. At least 25% of your sprint 1 grade will be related to completing and documenting this assignment by the end of the sprint. Create PBIs for each to allow logging time, and check the code into a new repository under the SDL GitLab folder. In some cases this assignment will be moved to the second sprint. Additional requirements:
    • The individual must fully groom the PBI for their assignment; the quality of your PBI is part of the grade.
    • The assignment must be placed in a separate repository (from the main project) and be visible to your instructor until the assignment is graded. For GitLab, give the instructor maintainer access. Document the location in the writeup.
    • Document where they are stored and ensure they are visible to your instructor (with maintainer access in GitLab) until the assignment is graded.
    • Make frequent commits showing your progress. One single check-in suggests the assignment was too simple.
    • Document the time you spend on your PBI. Do this in GitLab, but you may also find it convenient to have your own log.
    • Ensure you go beyond demonstration code. If sample code is used from exterior sources, the writeup must clarify what part is yours. Be sure to cite any other sources, including work done by other students!
  • Create PBIs for sprint 24f2 and beyond. Do not attempt to write PBIs for the full project, but do ensure you have well-written user stories for key features to be implemented in sprints 24f2 and 24f3, including acceptance criteria. Rotate project roles if appropriate.
5-7 24f2
  • Create high level design diagrams capturing system architecture. Present your solution to your instructor and incorporate feedback.
  • Create a software spike of the entire solution. The spike should include a component from each element of your architecture diagram. Check this code into a fresh repository in the SDL GitLab folder.
  • Build a project backlog of PBIs that lead to a minimally viable product at the end of sprint 24f3. PBIs should generally be small enough that one or two people can complete them in a week. Larger PBIs will likely result in work that must carry across multiple sprints, contrary to the Scrum model.
    • Often the first PBIs will also include creating new projects and build environments. Inflate your estimates for the first PBIs to account for this.
  • Create an initial "definition of done." It is expected the team will update this throughout the year.
8-10 24f3
  • Allocate PBIs. Have no more than two PBIs open at any one time (at this stage in the year).
  • Post pull requests for every major improvement (into dev), even if the full PBI is not complete.
  • Complete PBIs and have them validated by the POP.
At the end of the sprint,
  • Close all completed branches.
  • Merge dev to main.
  • Meet with your PO and demonstrate your progress. This demonstration must be out of the main branch. Identify priorities for the next semester.
  • If you cannot meet with the PO for the sprint review, perform an internal review. Ensure there is a meeting with the PO by the first class of the next term.
  • Perform a sprint retrospective, being sure to capture concrete, measurable process improvements. The retrospective can be performed before the review when appropriate.
  • Produce a sprint report capturing each team member's contribution in terms of completed work and hours logged as well as the retrospective. A format for this will be provided.
11-14 24f4
  • This sprint covers four weeks, including Thanksgiving break. This sprint also includes a presentation day; this helps ensure the effective sprint length is the same as 3.
  • Follow sprint 3 activities: allocating PBIs, posting pull requests, completing PBIs
  • The presentation will be part of this sprint's grade.
At the end of the sprint, perform the same activities as for sprint 3.
15 Spring Planning
  • Ensure there are enough sprintable PBIs for two sprints on the top of the backlog. These should have the following characteristics:
    • They must have a name that distinguishes the PBIs from others
    • The PBI must follow the standard format complete with testable acceptance criteria. At this point, there should be at least one sunny-day AC and at least one error AC.
    • The PBIs must be listed in priority order.
16 Finals
  • Each team presents their work. Everyone should be involved in presenting the material.
  • Practice your presentation to ensure it fits within the time allotment.
  • All presented functionality must be built from the project's main branch and presented on a working server.
  • Presentations should introduce the problem, demonstrate the solution, describe the architecture, and discuss lessons learned. The demonstration must be early in the presentation.
  • Students must be good audience members with laptops closed.
  • Each student writes a contribution report capturing their accomplishments, both in terms of completed PBIs and pull requests as well as indirect contributions such as showing leadership, completing their roles, and identifying errors when reviewing pull requests and other resources. The report is also to include the total hours spent on the project in the semester (with useful breakdowns).
Sprint grades are broken into 50% for documented effort and process and 50% for other deliverables.

Attendance and Logging Time

Teamwork is critical to SDL, so attendance is mandatory and missing results in grade penalties as determined by circumstances and your instructor's policies. The exceptions are:

When you do miss, send email to your team and your instructor briefly stating the reason for the absence and describing how you will make up the lost time with a verifiable activity.

Tardiness also impacts the team. Arriving more than 5 minutes late three times will result in a penalty, and arriving an hour late may be treated as an absence. Likewise, leaving before the end of the class time will also be penalized.

Log time to tasks on the appropriate story board. Log all time to the closest five minutes, and be sure the description distinguishes the work from other time logs. Log all time, both in class and outside, including non-development tasks as well as time researching solutions and time writing code. Failing to include a description will likely result in the time being ignored. Unless you really do stay approximately 120 minutes, the lab time should be logged as 110 or 115 minutes. If you find a mistake in how you entered the time within a few days, fix it. If many days pass before you find the error, talk to your instructor.

As a special case, log all time to sprint ceremonies (planning, reviews, retrospectives, etc.) to a sprint-specific ceremonies PBI. Create a new ceremony item for each sprint and include the name of the sprint, such as "24f1 Ceremonies". Assign 0 points to the ceremonies PBI and close it at the end of the sprint. Standups get special treatment: since they should be quick, you can log that time to the first task you work on for the day.

Communication

Communication is particularly important in SDL. It is expected that your team will establish effective communication channels (Teams, Slack, or other). Discuss with your instructor whether they wish to be included in those communications.

All students are expected to monitor the course wide Team channel. Many announcements will be made there and nowhere else. Instructors will monitor Teams and email on a daily basis, though some instructors may not be able to monitor them on weekends. Students are expected to do the same.

Study Abroad

Students occasionally wonder if they can participate in SWE 3710 while studying abroad. While it may be appropriate for SWE 3720, it is not appropriate for SWE 3710 because this is the first experience with long-term, open-ended projects, and the difficulties of communicating while overseas make it challenging to fully participate as a team member.

Integrity

Students are expected to engage in this course ethically and with integrity. It is expected you will work with your peers, however it is unacceptable to submit the work of your peers as your own. Fabricating evidence of participation (through misleading time logs, grossly inaccurate status reports, claims to have reviewed documents without examining them, etc.) are forms of academic dishonesty and may result in penalties discussed in the Policy on Student Integrity in the catalog. The academic integrity guidance for CSC and SWE courses applies to this course as well.

Additional Notes

Students with documented disabilities, chronic medication conditions and mental health concerns: MSOE provides services to make reasonable accommodations available. If you are a student who requires or anticipates the need for accommodations, please contact Student Accessibility Services Office at 414-277-7281, by email at moureau@msoe.edu, or in person at K250 to discuss appropriate accommodations and eligibility requirements.