SWE 3720: Software Development Lab II

Spring 2024 and later

Instructors: Dr. Rob Hasker, Prof. Alexander Pezewski

Office hours: See Canvas

Course Description:

This is the second course in the software development laboratory sequence. Students continue working on large-scale software projects with a goal of delivering a system that could be deployed by clients. In addition, students gain additional experience at processes assessment and improvement. This course meets the following Raider Core CLO requirement: Integrate Learning.

Prereq: SWE 2721, SWE 3710 (Quarter system prereq: SE 3010)

There is no textbook for this course.

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

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
Plan and track project activities with students serving in both leadership and team membership roles
Identify measurable process improvement opportunities and enact improvements
Communicate project and process information in written and oral form
Deliver a thoroughly tested system along with an automated testing environment which provides confidence that the system meets customer requirements
Document system operation in sufficient detail to support deployment by the client
Document key design decisions in sufficient detail to support future development

Grading:

		Percentage
	Sprints	60%
	Contribution Report	25%
	Peer evaluation	5%
	Presentation	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 130 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

As for SWE 3710, the course coordinator and instructor will determine team and project assignments. Generally a student will continue participating on the same team as SWE 3710, but this may change if necessary. Reasons for changes include (but are not limited to) students not being able to take SDL in successive terms (such as when studying abroad), students failing SWE 3710, and product owners determining a project is finished.

Schedule

The term is broken into five sprints.

Weeks Sprint Objectives

1-3 25s1

Identify a new product owner proxy (POP). Rotate other roles as appropriate.

Review and possibly update the team's Definition of Done

Allocate PBIs. Explicitly state whether team PBIs are individual or joint; if they are joint, have no more than two PBIs open at any one time.

Use GitLab's Merge Request feature to pull every major improvement into dev, even if the full PBI is not complete.

Complete PBIs and have them validated by the POP.

Ensure a CI system is in place with effective testing and that all tests pass or any failures are documented.

At the end of the sprint,

Close all completed branches.

Merge dev to the main branch.

Meet with your PO and demonstrate your progress. This demonstration must be out of the main branch. Identify priorities for the next sprint.

If you cannot perform the sprint review with the PO in a timely fashion, do a review with your instructor and organizing a meeting with your PO as soon as you can.

Conduct a sprint retrospective capturing concrete, measurable process improvements.

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 is provided.

Consider whether roles should be rotated. The product owner proxy will generally not change, but other roles should change at least once every other sprint.

4-6 25s2 Perform the same activities as for sprint 25s1. If you have not yet done so, publish your system where your client can access it so they can perform initial testing and provide useful user feedback. Rotate roles if appropriate. In addition: consult with your project advisor on the testing methodology and determine if it would be appropriate to introduce behavior-driven development (BDD) introduced into the CI system.

7-9 25s3 Perform the same activities as for sprint 25s2, including introducing or extending the BDD testing as appropriate. Rotate roles if appropriate.

10-12 25s4 Perform the same activities as for sprint 25s3.

13-15 25s5 The PBIs for this sprint should be focused on bug fixes, documenting the system operation and system design, and deploying a thoroughly tested release. The core goals are to hand off a solid system to your client and (if appropriate) capture enough design detail that the next team can pick up the project and add new functionality without major redesign or other rework. Any work to add new features must be approved by your SWE 3720 instructor.
More detail:

Ensure the system is deployed into service.

Ensure the build steps are documented! Someone with a fresh MSOE laptop should be able to use your steps to maintain and deploy the system. This likely includes stating the IDE(s) used to build the project, naming files to open within the IDE, giving any commands to run from a command prompt (if applicable), describing how to run tests and the expected output (preferably pointing at the CI environment you set up), describing any support libraries or software to be installed and key installation steps, and describing how to start the application. All of this is very obvious to you, but will be completely mysterious to future developers. You can assume the person will work out how to install support tools, but capture any key steps that would not be obvious to (say) another student. Projects without build instructions will simply be deleted as they are worse than useless.

Create useful design documents capturing the system structure, and record a video (preferably involving the full development team) in which you describe the structure of the design. This will help future teams tremendously. Store this video in the project wiki.

This project structure should be particularly careful to point out things like requirements, build scripts, sample data, and test locations. These will be very obvious to you by this point, but not obvious to the next team!

Document any known future work on the project, preferably as epics.

Close all branches; the full version should be in the main branch.

If a branch is left open because it captures work that might be useful in the future, document this very visibly in multiple places, explaining both why it would be useful and why it cannot be marked as done.

If not done yet, and if it's appropriate for the project, add the team member's names and project year to an "about" page for the project.

Review the project's Readme file and other documentation to ensure each document is current.

Perform exploratory testing and document standing issues.

15 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, where relevant, must be presented from a working server.

Process improvements and the results are to be prominent in your presentation. Consider carefully how to present those, making the issue, response, measurement, and result clear to students who have not participated in your project.

As before, clearly present delivered functionality, including documentation you provided that would enable future teams to continue your work (even if no further work is anticipated - most systems undergo maintenance over time).

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. An important part of the report is the student's contributions to the team process improvement activities. The report is also to include the total hours spent on the project in the semester (with useful breakdowns).

Some instructors may require additional, mid-semester presentations.

Sprint grades are broken into 50% for documented effort and process and 50% for other deliverables.

Weeks	Sprint	Objectives
1-3	25s1	Identify a new product owner proxy (POP). Rotate other roles as appropriate. Review and possibly update the team's Definition of Done Allocate PBIs. Explicitly state whether team PBIs are individual or joint; if they are joint, have no more than two PBIs open at any one time. Use GitLab's Merge Request feature to pull every major improvement into dev, even if the full PBI is not complete. Complete PBIs and have them validated by the POP. Ensure a CI system is in place with effective testing and that all tests pass or any failures are documented. At the end of the sprint, Close all completed branches. Merge dev to the main branch. Meet with your PO and demonstrate your progress. This demonstration must be out of the main branch. Identify priorities for the next sprint. If you cannot perform the sprint review with the PO in a timely fashion, do a review with your instructor and organizing a meeting with your PO as soon as you can. Conduct a sprint retrospective capturing concrete, measurable process improvements. 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 is provided. Consider whether roles should be rotated. The product owner proxy will generally not change, but other roles should change at least once every other sprint.
4-6	25s2	Perform the same activities as for sprint 25s1. If you have not yet done so, publish your system where your client can access it so they can perform initial testing and provide useful user feedback. Rotate roles if appropriate. In addition: consult with your project advisor on the testing methodology and determine if it would be appropriate to introduce behavior-driven development (BDD) introduced into the CI system.
7-9	25s3	Perform the same activities as for sprint 25s2, including introducing or extending the BDD testing as appropriate. Rotate roles if appropriate.
10-12	25s4	Perform the same activities as for sprint 25s3.
13-15	25s5	The PBIs for this sprint should be focused on bug fixes, documenting the system operation and system design, and deploying a thoroughly tested release. The core goals are to hand off a solid system to your client and (if appropriate) capture enough design detail that the next team can pick up the project and add new functionality without major redesign or other rework. Any work to add new features must be approved by your SWE 3720 instructor. More detail: Ensure the system is deployed into service. Ensure the build steps are documented! Someone with a fresh MSOE laptop should be able to use your steps to maintain and deploy the system. This likely includes stating the IDE(s) used to build the project, naming files to open within the IDE, giving any commands to run from a command prompt (if applicable), describing how to run tests and the expected output (preferably pointing at the CI environment you set up), describing any support libraries or software to be installed and key installation steps, and describing how to start the application. All of this is very obvious to you, but will be completely mysterious to future developers. You can assume the person will work out how to install support tools, but capture any key steps that would not be obvious to (say) another student. Projects without build instructions will simply be deleted as they are worse than useless. Create useful design documents capturing the system structure, and record a video (preferably involving the full development team) in which you describe the structure of the design. This will help future teams tremendously. Store this video in the project wiki. This project structure should be particularly careful to point out things like requirements, build scripts, sample data, and test locations. These will be very obvious to you by this point, but not obvious to the next team! Document any known future work on the project, preferably as epics. Close all branches; the full version should be in the main branch. If a branch is left open because it captures work that might be useful in the future, document this very visibly in multiple places, explaining both why it would be useful and why it cannot be marked as done. If not done yet, and if it's appropriate for the project, add the team member's names and project year to an "about" page for the project. Review the project's Readme file and other documentation to ensure each document is current. Perform exploratory testing and document standing issues.
15	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, where relevant, must be presented from a working server. Process improvements and the results are to be prominent in your presentation. Consider carefully how to present those, making the issue, response, measurement, and result clear to students who have not participated in your project. As before, clearly present delivered functionality, including documentation you provided that would enable future teams to continue your work (even if no further work is anticipated - most systems undergo maintenance over time). 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. An important part of the report is the student's contributions to the team process improvement activities. The report is also to include the total hours spent on the project in the semester (with useful breakdowns). Some instructors may require additional, mid-semester presentations.

Process: completing PBIs, process improvement, process documentation, team work (which includes not completing all PBIs very late in the sprint). In this term, process improvement activities must be quantified and you must report on the effectiveness of your improvements.
Name branches by the PBI description; all lower case, underscores or dashes between words
Pull requests are evidence of contribution
You are required to submit pull requests when there is significant progress, not just when the PBI is completed

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. 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 ceremonies PBI. Leave that PBI in the backlog. 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, Discord, email, or whatever). Discuss with your instructor whether they wish to be included in those communications.

All students are expected to subscribe to the course 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

There are times when it might be helpful to take SWE 3720 while studying abroad. However, it is difficult to manage a project in which some students are remote and in a different time zone. This increases the workload for both instructors and other team members. The preference is that students take advantage of being abroad by taking courses at their host institution. Note that the student will be able to take SWE 3720 once they return to campus. If not taking SWE 3720 while studying abroad means delaying graduation by an extra term, the student must obtain approval from the course coordinator and SWE program director to participate remotely.

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.