SE 3010: Software Development Lab I, 2021-22

Instructors: Dr. Rob Hasker, Dr. Jonathon Magaña, Dr. Josiah Yoder

Office hours:

Dr. Hasker: See his home page, https://faculty-web.msoe.edu/hasker/
Dr. Magaña: See Blackboard
Dr. Yoder: See his home page, https://faculty-web.msoe.edu/yoder/current

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.

Prereqs: SE 2800, SE 2811

Format: 4 lecture 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  
Sprint 1  20%
Sprint 2  20%
Sprint 3  20%
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 90 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 90 hours (spread evenly) per term is sufficient except when a student is explicitly informed they need to do more to address inadequate performance. While 90 can be considered the minimum number of hours, it is not the maximum. However, working more than 90 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 SE 3010, 3020, and 3030, 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 three sprints and one "flex" week. In the fall, 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 22f3.

Weeks Sprint Objectives
1 Flex Week
  • Meet with Product Owner
  • Assign Product Owner Proxy (POP) for year
  • Assign roles for sprints 22f1, 22f2. 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 team.
  • 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 product owner.
    • 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.
  • Create sprint 22f1; note that the ' f ' is lower case
  • Create the 22f1 backlog; see the 22f1 discussion below.
  • Identify key epics to be completed for the project. This list is expected to grow as the project matures.
2-4 22f1
  • Identify the main user story lines and build storyboards. Verify these are aligned with product owner expectations.
  • Draft low fidelity mockups to capture the app as described in storyboards. Verify these with the product owner.
  • Develop high-fidelity mockups which capture the app as described in storyboards and previous mockups. Verify product owner alignment.
  • technology assignments: individual assignments geared toward learning a technology to be applied in the year. 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.
    • 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!
  • In general, your PBIs for this sprint will capture constructing storyboards and mockups. The mockup PBIs should be tied to specific user stories, and the acceptance criteria should be specific to those stories. Include "verify with product owner" in each PBI (except technology assignments); this verification can take place by email as long as you also verify the artifacts at a regular meeting.
5-7 22f2
  • 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 22f3. 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 22f3
  • 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 quarter.
  • 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 SE 3020.
  • 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 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.
  • For SE 3010, the presentation can be from localhost, but future presentations will be 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 quarter (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 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 (Slack, Snapchat, email, or whatever). Discuss with your instructor whether they wish to be included in those communications.

All students are expected to subscribe to coursewide Slack channels. Many announcements will be made there and nowhere else. Instructors will monitor Slack 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.

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.

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.