Weekly Schedule

Software Engineering Applications

ESOF 423 is the interdisciplinary capstone for Computer Science–Business Applications (CSBA) and Computer Science–Interdisciplinary (CSIN) students. Teams of two Developers build a semester-long software product for an outside user or client. Each Developer connects the software work to their minor or second discipline and uses external feedback to guide product decisions.

Course Description

ESOF 423 Software Engineering Applications: 3 Credits (1 Lec, 2 Lab)

Prerequisite:ESOF 322. Application of software engineering techniques and methodologies acquired in previous courses to solve an open-ended software engineering problem provided by stakeholders. Students use a team-based approach to requirements gathering, design, implementation, testing, integration, and delivery of the software solution. CSCI 440 is recommended.

Course Outcomes

After successfully completing this course, students will be able to:

  1. Design and implement a solution to an open-ended software engineering problem defined by a stakeholder.
  2. Evaluate alternative solutions to a software engineering problem.
  3. Use software quality-assurance techniques to evaluate the quality of a developed software engineering solution.
  4. Use written, oral, and visual communication to document and present the solution to the stakeholder.
  5. Work in a software-development team in an Agile environment.

The capstone also requires Developers to demonstrate how their minor or second discipline informs product decisions and how external-user or client feedback affects the product.

Instructor

Daniel DeFrance

Meeting Times

10:00–10:50 a.m. in Gianforte Hall 210

  • Monday: software engineering topics and product-development preparation
  • Wednesday and Friday: Scrum meetings, demos, workshops, and team development

Projects and Teams

  • Developers work in teams of two on semester-long projects identified through outreach to outside users or clients.
  • Each Developer connects product decisions to their minor or second discipline.
  • Teams use user stories, product backlogs, and sprint backlogs to plan and manage their work.
  • Teams are self-organizing and negotiate achievable scope with the Product Advisor.
  • Teams seek feedback from their outside user or client throughout the semester and use it to guide product decisions.
  • Teams use Git and GitHub to make branching, review, integration, and individual contributions visible.
  • Teams apply quality-assurance methods appropriate to their product, technology stack, users, and risks.
  • Teams must not commit credentials, private client data, or FERPA-protected information.

Course Roles

  • The instructor serves as Product Advisor.
  • Students serve as Developers.
  • One Developer serves as Scrum Master during each sprint.
  • The Scrum Master role rotates each sprint.
  • The Scrum Master facilitates the process; they are not the team boss.
  • Both Developers remain responsible for planning, implementation, testing, documentation, communication, and delivery.

Sprint Structure

The course uses six two-week instructional sprints. Fall Break does not count as a sprint workweek. Each sprint includes kickoff and planning, a signed SMART Sprint Goal, backlog work, standups and Scrum labs, project-appropriate testing, a product increment and demo, and reflection and adaptation.

Not meeting the Sprint Goal does not mean the sprint failed. Progress, adaptation, and learning matter more.

Testing

Testing must fit the project's actual technology stack, architecture, users, and risks. Evidence may include unit, integration, system, end-to-end, accessibility, usability, performance, security, or other appropriate testing. No single testing framework is required for every team.

Teams must explain what risks their testing addresses, why the selected methods and tools fit the project, what the results show, and what remains untested or uncertain.

Grading and Assessment

Individually Graded — 50%

  • 30% Individual assignments: work based on course topics and individual reflection
  • 15% Scrum-lab participation: preparation, attendance, professional collaboration, and visible contribution
  • 5% Final-presentation participation: support, learn from, and ask questions of other teams

Team Graded — 50%

  • 30% Development releases: five product increments and demonstrations leading toward the final product
  • 20% Final release: product, presentation, portfolio, repository, documentation, and recorded demonstration

The final release includes:

  • Product: a functional, appropriately scoped product supported by evidence of testing and user or client feedback
  • Presentation: a client-focused presentation in which each Developer speaks for approximately three to five minutes and explains their contribution
  • Portfolio: a technical account of the product's architecture, interdisciplinary design decisions, maintainability, quality-assurance methods, user impact, and potential future enhancements
  • Repository: source code, issues, technical documentation, review history, and meaningful contributions from both Developers
  • Documentation: clear user-facing instructions, developer documentation, and Agile artifacts that record goals, backlogs, progress, reflection, and adaptation
  • Recorded demonstration: a clear 10–15 minute demonstration showing how an end user operates the product

Sprint and release assessment considers the product increment, development process and Agile artifacts, project-appropriate testing, maintainability and scope control, professionalism and work ethic, reflection and adaptation, and user/client and interdisciplinary evidence. Canvas provides current assignment instructions, submission settings, points, and rubrics.

Letter grades are determined after any curving takes place. A curve, if used, will only lower the minimum percentages required for letter grades; it will never raise them. Without a curve, the following scale applies:

Letter grade
Minimum percentage
A
93
A-
90
B+
87
B
83
B-
80
C+
77
C
73
C-
70
D+
67
D
63
D-
60
F
Below 60

Participation and Absences

Scrum meetings and team work sessions depend on both Developers being prepared and present. If a Developer must miss a Scrum meeting, notify the Product Advisor and the other Developer in advance by email, explain the impact on the team, and coordinate required follow-up work.

Absence and emergency circumstances are handled under the course policies. Canvas contains assignment-specific attendance and make-up requirements.

Course Systems

  • Git and GitHub: authoritative development record for team products and individual contributions
  • Canvas: modules, announcements, dates, submissions, rubrics, and student-facing links
  • Public course page: official living syllabus and schedule
  • GitHub organization 423F26: team product repositories, project1 through project6

Resources

Course Policies

See the policies page for expectations and consequences related to collaboration, academic integrity, copyright, AI-tool use, lateness, and emergencies.

Additional MSU Resources