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

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 2410, and either SWE 2710 or SWE 2712

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
• Apply the principles of Behavior-Driven Development (BDD) to introduce executable acceptance tests that are readable by non-technical clients
• Deliver a thoroughly tested system along with an automated testing environment
• Document system operation in sufficient detail to support deployment by the client
• Document key design decisions in sufficient detail to support future development

As discussed above, this course provides an opportunity to develop your skills in the Common Learning Outcome (CLO) Integrate Learning: connecting, synthesizing, and transferring learning across new contexts to address complex problems. This appears in two ways: applying knowledge from previous courses and experiences to deploy a working solution meeting your client’s needs, and through using BDD to capture your client’s acceptance criteria as executable tests.

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.

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 140 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 140 hours does not, by itself, increase the likelihood of earning an A.

The out-of-sprint activities are additional activities such as final presentations, peer evaluations, and additional assignments.

Teams

In mose cases, you will be on the same team as for SWE 3710. PThe POP (Product Owner Proxy) should be a different person.

Schedule

The spring semester has five sprints. The assumption is that you are starting the semester with a sprint-ready product backlog. If your backlog is not ready, the team is expected to either put in extra time the first week to set up the backlog or to log time over spring break.

Sprint 27s1

In addition to standard items, do the following at the start of this sprint:

• Identify a new product owner proxy (POP)
• Rotate other roles as appropriate
• Update the team's Definition of Done
• Review the Definition of Done with your instructor and your client

Sprint 27s2

In addition to standard activities from SWE 3710, add a PBI (to be completed by all team members) to complete of the the Behavior-Driven Development (BDD) activities. This includes both part 1 and part 2. Write Cucumber tests related to a previously-implemented PBI and ensure these tests pass. Your instructor will create an assignment which allows the team to report on their experiences.

In addition, publish an executable implementation of the system where your client can access it.

Sprint 27s3

In addition to standard activities, use BDD to specify acceptance criteria for at least two PBIs before those PBI are implemented, and close those PBIs only when all acceptance criteria pass. Include your experience with BDD in the sprint report.

Update the published version of the system.

Sprint 27s4

Perform standard sprint activities, including applying BDD to your project and publishing an updated version of the system.

Sprint 27s5

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 explicitly approved by your instructor.

Additional detail:

• Ensure the final version of the system is deployed. Include only those features that are well-tested and approved by at least the product owner proxy.
• Ensure all builds pass with no errors. If there are known bugs, write tests (unit tests, Cucumber tests, etc.) exposing the bug, and comment out the test with a TODO marker that indicates the date the test was written, who wrote it, and what needs to be fixed.
• 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 (especially by this point in the project), 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.
• So that future teams know which warnings are significant and which are not, capture a screen recording of your system being built from scratch showing all of the warnings and steps you see. This will help new teams know if a particular warning is because of a change in libraries or has always been present.
• 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.
• Clean the whiteboard. If there is anything there that would be important to future teams, capture an image and put it in the documentation folder along with comments. Cleaning it makes it clear that no remaining information is useful.
• Ensure the project README (at the top level) contains references to requirements documents, build scripts, sample data, and test locations. Again, these will not be obvious to future developers.
• Document any known future work on the project, preferably as epics.
• Ensure the project README includes the names of the client, the product owner, and all developers (including past developers). If appropriate, include your names in a project About page accessible by the user.
• Close all branches. The final 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.
• Review the project's README file and other documentation to ensure each is current.
• As time permits, perform exploratory testing and document any identified issues. Strongly consider turning these into commented-out Cucumber tests as described above.

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, 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.
• 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 an additional, mid-semester presentation.

Sprint Grades

Sprint grades are divided as follows:

• 20%: ensuring the sprint backlog is fully groomed and pointed by the end of the first class session of the sprint
• 20%: process conformance during the sprint, including documenting and quantifying process improvement
• 60%: individual contribution towards sprint goals, including appropriate commit comments, naming branches by the PBI description (all lower case, underscores or dashes between words), and frequent, incremental pull requests

Attendance and Logging Time

The attendance policy for SWE 3720 is the same as SWE 3720. That is,

• attendance is mandatory unless seriously ill,
• unexcused absences and tardies result in grade penalties,
• notify your instructor and team (via Teams) for missed classes/tardies,
• log time to the closest 5 minutes with adequate description, and
• log time to a ceremonies PBI as appropriate.

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.

Generative AI

The generative AI policy in the SWE 3710 Syllabus 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.