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

• Apply software engineering practices and tools to the development of significant software components and systems
• In a small team, identify client needs, document the scope of work to be done in a term, and develop a framework leading to potential solutions
• Develop deliverable prototypes for evaluation by clients
• Plan and track project activities with students serving in both leadership and team membership roles
• Describe the role of continuous testing in project development and demonstrate a testing environment which verifies portions of the delivered system
• Communicate project and process information in written and oral form
• Research and apply independently learned knowledge and skills to the development of software components and systems

Grading

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 130 hours for the term, counting both time in class and time out-of-class. This must be distributed evenly throughout the term, meaning you need to plan on approximately 10 hours per week, with slightly more than 6 of those hours outside of class time. If this is too much for your load, consider taking SDL later. This is a minimum time; students certainly can put in more time without penalty. However, working more than 130 hours does not, by itself, increase the likelihood of earning an A.

Team Formation

The course coordinator will work with instructors 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. Students usually stay on the same team for both SWE 3710 and 3720 unless such reasons as project completion, studying abroad, or failing either 3710 or 3720.

Team members will have different roles over the course of the semester. One student will serve as Product Owner Proxy (POP) for the semester; this role will change for SWE 3720. The other students will share the other roles:

• 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; must document meetings and any issues coming out of those meets
• 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.
• Other roles as determined by the team and instructor. You will report on your actions in each sprint.

Repository

There is to be a single repository for each project. Prototypes can be placed in a separate project that is visible to the instructor, but any delivered code and documentation is to be in the main repository. Use the Wiki for internal notes, reports, and planning, but not deliverables. Including project documentation in the Wiki is a problem because materials in the Wiki are often unavailable to future teams.

The organization of your repository is to be

• Include a main branch that is projected from pushes
• Include a dev branch that captures completed PBIs (product backlog items) before deployment; all PBI branches will be off dev
• Create a doc folder for all deliverable documentation
• Create a Readme file at the top level of the project. At a minimum, 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 It is important that you use lower case for all branch and folder names. Upper case will cause problems. Consistency in this is very important.

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
• Externally Blocked - issues for which progress is blocked by an external entity (not your PO or another team member!)
• Ready for Review - issues which the developer considers done
• Closed - issue closed by the POP Note the Product Owner Proxy has the ability and responsibility to close PBIs. If an error is found by the PO later, simply create a new PBI.

Schedule

Each semester consists of multiple sprints with additional planning weeks. The fall schedule is as follows. See the SWE 3720 syllabus for the spring schedule.

Week 1: Initial Project Planning

• Meet with Product Owner (PO)
• Assign Product Owner Proxy (POP) and other roles; remember other roles rotate
• Set up the repository as described above.
• Identify technology assignments by team member.
• Create sprint 26f1; note that the term (' f ' or `'s') is lower case, consistent with other project process items
• Create the 26f1 backlog; see the 26f1 discussion below.
• Identify key epics to be completed for the project. This list is expected to grow as the project matures.

Sprint 26f1: Finalizing Project Scope

• If needed, create 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.
• Complete technology assignments as assigned in week 1. At least 25% of your sprint grade will be based on this completion. Ensure the PBI is accurate, document lessons learned in the Wiki, and submit reports. Use this PBI to log time. 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.
  • 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 26f2 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 26f2 and 26f3, including acceptance criteria.
• Create high level design diagrams capturing system architecture. Present your solution to your instructor and incorporate feedback.

Sprint grades are assigned based on a combination of completed deliverables and following the appropriate process.

Sprint 26f2: Work towards the MVP

• Ensure the project backlog includes PBIs that lead to a minimally viable product (MVP) at the end of sprint 26f3. 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.
• Ensure all PBIs have independently verifiable acceptance criteria.
• Do not assign PBIs to individuals. Assigning PBIs should only happen when someone begins to actually work on the PBI. If you want to indicate who is likely to work on a PBI, add a note.
• Create an initial "definition of done." It is expected the team will update this throughout the year. Check it in to the Wiki as the first document with a suitable title.
• Create PBIs for sprint 26f2. Ensure they are sprint-ready including both a user story where appropriate (or a clear description where not) and verifiable acceptance criteria.

Remaining sprints

• At the start of each sprint, review the PBIs, ensure they are pointed appropriately, determine a sprint velocity target (typically between 25 and 30 points), identify which PBIs will be in the sprint, and move them into the sprint in priority order.
• During the sprint, hold a sprint planning session for the following sprint so that you are always ready for the next sprint before the sprint starts.
• Open the initial PBIs by assigning them to a team member. There should be no more than two or three PBIs open at any time unless all PBIs are small (3 points or less).
• 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.

A note on Sprint 26f4

• This sprint covers four weeks, including Thanksgiving break. This sprint also includes a presentation day; this helps ensure the sprint length is the approximately the same for all sprints.
• The presentation will be part of this sprint's grade.

Week 15

• Prepare the product backlog for the following semester. This will be part of your overall grade. It is important that you are ready to start the first sprint on day one of the sprint semester.
• Prepare your presentation.
• Close out any remaining PBIs that can be finished.
• Move all work into branch dev, closing all PBI branches. For branches that cannot be closed, talk to your instructor; it may be best to simply delete the work.
• Move deployable work to branch main. You will demonstrate out of this branch.
• 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).

Finals Week

• 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.

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:

• Being ill. Don't come to SDL if you're too sick to get to class! Do let your instructor and your team know you cannot make it.
• Absences excused by the Vice President of Academics for such things as university-sponsored activities. Be sure to give advance notice.
• In lieu of other absences, one missed day can be excused, but not for a day involving a sprint ceremony (finalizing the backlog or doing reviews and retrospectives). You must have approval at least one week in advance. This is the general solution for students needing to attend job interviews.

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. Lab time should follow the “closest 5-minute” rule, so will typically be recorded 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 "26f1 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 Teams 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. 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.