Teaching with ETIS¶

A real, evolving teaching framework for undergraduate and graduate software engineering education

Engineering Trustworthy Intelligent Systems (ETIS) is not only a book project. It is a working educational framework currently used to teach software engineering at both the undergraduate and graduate level.

ETIS supports a modern software engineering course model built around repository-centered engineering, AI-assisted development, governance, review, validation, release evidence, operational maturity, and professional accountability.

A representative implementation is COMP 330/474, Software Engineering, where students progress through two engineering cycles, use GitHub as the authoritative project record, document meaningful AI use, defend releases with evidence, and improve operational maturity through observability, governance, security, and risk reduction.

Educational Purpose¶

ETIS is designed for the AI era of software engineering.

Students are no longer entering a profession where the central challenge is simply learning to write code. They are entering a profession where AI systems can generate code, documentation, tests, summaries, workflow recommendations, architectural alternatives, and operational analysis. That acceleration changes the responsibility of the engineer.

The purpose of teaching with ETIS is to help students develop the judgment, discipline, and professional habits needed to build systems that can be understood, reviewed, governed, operated, improved, and trusted.

ETIS teaches that:

working code is not the same as engineered software,
generated output is not the same as verified engineering work,
a repository is not merely a place to store code,
a demo is not operational proof,
governance is not paperwork,
and trustworthy systems require visible evidence.

What Students Learn¶

A course taught with ETIS helps students connect software engineering concepts to professional practice.

Students learn to:

distinguish programming activity from disciplined software engineering,
use lifecycle models as coordination strategies under uncertainty,
organize team work through roles, commitments, reviews, and visible accountability,
create requirements, acceptance criteria, assumptions, risks, and scope boundaries,
develop architecture artifacts that identify components, interfaces, dependencies, and governance points,
use GitHub issues, branches, commits, pull requests, reviews, and CI/CD evidence professionally,
use AI tools responsibly without surrendering engineering judgment,
document meaningful AI use in reviewable repository evidence,
create validation, defect, release, and operational-readiness evidence,
defend engineering decisions through reviewable artifacts,
analyze defects, risks, tradeoffs, limitations, and operational concerns using evidence,
and improve systems through postmortems, feedback, observability, governance, and stewardship.

Teaching Model¶

ETIS works best when the course is organized as a small professional software engineering organization rather than a traditional programming class.

The course model emphasizes:

team-based engineering,
repository-centered evidence,
two-cycle delivery,
review and governance checkpoints,
AI-use disclosure and validation,
release-readiness defense,
operational maturity improvement,
and professional reflection.

The central operating model is simple:

Use the learning management system to understand what to do. Use the repository to prove what the team actually did.

Two-Cycle Engineering Structure¶

A strong ETIS course uses two delivery cycles.

Cycle 1 — Can It Work?¶

Cycle 1 focuses on controlled construction.

Students define the project, organize the team, establish the repository, document requirements, plan work, create architecture, implement a controlled vertical slice, review changes, test the system, and prepare release evidence.

Cycle 1 asks students to demonstrate that the system can work under controlled conditions.

Cycle 2 — Can It Survive?¶

Cycle 2 focuses on maturity.

Students improve the system using feedback, defects, risks, evidence, observability, governance, security, operational readiness, and release discipline.

Cycle 2 asks students to demonstrate that the system is not merely functional, but more stable, reviewable, governable, observable, and defensible.

This distinction is central to ETIS.

A system that works once is not necessarily trustworthy. A trustworthy system must be explainable, reviewable, testable, recoverable, governable, and improvable over time.

Example Semester Progression¶

A semester implementation may progress through the following instructional arc.

Foundations¶

Software Engineering in the AI Era
Why Software Projects Fail
Classical SDLC Models
AI Changes the SDLC
Teams, Roles, and Accountability

Cycle 1 Launch and Engineering Evidence¶

Project launch
Repository setup
Team roles
Workflow expectations
AI-use expectations
Requirements engineering
AI-assisted requirements
Planning and estimation
Engineering tradeoffs

Architecture and Construction¶

Architecture fundamentals
Intelligent systems architecture
Design and peer review
AI-assisted construction
GitHub workflow and CI/CD
AI code review and dependency governance

Verification and Release Readiness¶

Testing AI systems
AI validation
Release readiness
Cycle 1 presentations
Evidence-backed release defense

Operational Maturity¶

Cycle 2 launch
Observability
Security and governance
Enterprise AI architecture
final presentations
course capstone

This sequence can be adapted for undergraduate, graduate, capstone, professional-practice, or enterprise-training settings.

Assignment Architecture¶

ETIS assignments should operate as engineering phase gates, not as isolated homework submissions.

A typical course may use six major assignment checkpoints:

Assignment 1 — Project Launch and Repository Foundation¶

Students establish the team, repository, project structure, roles, workflow expectations, communication practices, AI-use expectations, and initial project evidence.

Assignment 2 — Requirements, Planning, Risk, and Traceability¶

Students document requirements, use cases or user stories, assumptions, acceptance criteria, risks, estimates, scope boundaries, and traceability evidence.

Assignment 3 — Architecture and Review¶

Students create architecture artifacts, identify boundaries and dependencies, document design decisions, record architecture decision records, and respond to review feedback.

Assignment 4 — Construction, Integration, Review, and Validation¶

Students implement the system using controlled workflow practices. Evidence may include issues, branches, commits, pull requests, review records, CI/CD evidence, test evidence, AI-use logs, defects, and integration notes.

Assignment 5 — Cycle 1 Release Readiness and Presentation¶

Students prepare release evidence and defend the first controlled release. The focus is not only what was built, but what evidence supports release judgment.

Assignment 6 — Final Release, Operational Maturity, and Engineering Defense¶

Students improve system maturity through observability, security, governance, risk reduction, operational readiness, postmortem learning, and final release evidence.

Repository-Centered Teaching¶

ETIS courses should treat the team repository as the authoritative engineering record.

Students should not merely submit documents. They should preserve evidence.

A strong student repository includes:

/docs
  /requirements
  /architecture
  /planning
  /reviews
  /testing
  /release_evidence
  /operations
  /security
  /governance
  /ai_governance
  /postmortems
  /runbooks
  /presentations

Recommended repository artifacts include:

project charter,
team roles,
requirements,
use cases or user stories,
acceptance criteria,
risk register,
work breakdown structure,
architecture overview,
architecture decision records,
review logs,
pull request evidence,
AI-use log,
test evidence,
defect log,
release-readiness record,
known limitations,
operational-readiness notes,
runbook,
postmortem,
final presentation,
and stewardship review.

AI Use in ETIS Courses¶

ETIS does not ask students to avoid AI.

It asks students to govern it.

Students may use AI for requirements exploration, planning support, design critique, implementation assistance, refactoring, testing ideas, documentation, review preparation, defect analysis, and operational analysis.

But AI-generated or AI-assisted work must remain subject to engineering responsibility.

Students and teams remain accountable for:

correctness,
security,
architecture fit,
maintainability,
testing,
documentation,
operational impact,
limitations,
and professional quality.

Meaningful AI use should be documented in a repository AI-use log or equivalent evidence record.

A useful AI-use record should identify:

the tool used,
the engineering task supported,
the output or recommendation produced,
what the team accepted,
what the team modified,
what the team rejected,
how the result was reviewed,
and how the result was validated.

The governing principle is:

AI proposes; engineers verify.

Review Boards and Release Defense¶

ETIS courses should include review moments that simulate professional engineering governance.

Review activities may include:

requirements review,
architecture review,
design review,
pull request review,
AI-use review,
test evidence review,
release-readiness review,
operational-readiness review,
security and governance review,
and final engineering defense.

Students should learn to defend engineering decisions with evidence.

A release presentation should answer questions such as:

What was built?
What requirements does it satisfy?
What risks remain?
What evidence supports release readiness?
What defects or limitations are known?
What AI assistance was used?
How was AI-assisted work reviewed?
What tests were run?
What would need to improve before operational use?
What did the team learn?

Classroom Activities¶

ETIS supports applied classroom activities such as:

repository audit,
requirements review,
ambiguity review,
architecture boundary review,
ADR critique,
AI-use log review,
pull request simulation,
code review workshop,
dependency governance review,
testing evidence review,
release readiness tabletop,
incident response tabletop,
postmortem analysis,
observability review,
security and governance review,
final release defense,
and trustworthy engineer portfolio review.

These activities help students see engineering as an accountable practice rather than a collection of isolated technical tasks.

Assessment Model¶

ETIS assessment should evaluate both product and evidence.

A course may assess:

engineering deliverables,
exams,
presentations,
professionalism,
accountability,
repository evidence,
AI-use documentation,
team participation,
release readiness,
and final engineering defense.

Students should be evaluated on whether another reviewer can inspect, understand, and evaluate their work from repository evidence.

A mature assessment model asks:

Did the team build something meaningful?
Did the team preserve evidence?
Did the team review its decisions?
Did the team validate what it built?
Did the team disclose and govern AI use?
Did the team manage risks and limitations honestly?
Did the team improve system maturity over time?
Did the team communicate professionally?
Did the team demonstrate engineering judgment?

Undergraduate and Graduate Use¶

ETIS can support both undergraduate and graduate software engineering education.

Undergraduate Use¶

At the undergraduate level, ETIS helps students move beyond coding assignments into professional software engineering practice. Students learn teamwork, requirements, planning, architecture, review, testing, AI-use accountability, repository evidence, and release defense.

Graduate Use¶

At the graduate level, ETIS can support deeper work in architecture, governance, intelligent systems, operational trust, enterprise AI, responsible AI, review-board practice, and organizational accountability.

Graduate courses may emphasize:

architecture tradeoffs,
governance models,
enterprise AI risk,
AI delegation boundaries,
repository evidence architecture,
operational readiness,
trustworthiness assessment,
leadership,
and professional stewardship.

Course Adoption Models¶

Instructors may adopt ETIS in several ways.

Full-Semester Software Engineering Course¶

Use ETIS as the primary framework for a team-based software engineering course.

Capstone Governance Framework¶

Use ETIS to structure capstone evidence, review checkpoints, release readiness, AI-use disclosure, and final project defense.

AI Governance Course Module¶

Use ETIS chapters, appendices, and review prompts to teach responsible AI, human oversight, evidence, and governance.

Software Architecture Course Module¶

Use ETIS architecture chapters and ADR materials to teach boundaries, dependencies, decisions, context, and governance points.

DevOps and Operational Readiness Module¶

Use ETIS operational chapters to teach observability, runbooks, release evidence, incident response, postmortems, and reliability.

Professional Practice Seminar¶

Use ETIS as a framework for teaching engineering judgment, accountability, professional communication, evidence, and stewardship.

LMU / COICP Teaching Environment¶

ETIS includes the fictional enterprise Lakeside Metropolitan University (LMU) and the Campus Operations and Incident Coordination Platform (COICP).

This continuity environment allows students to see engineering concepts across a living organizational context rather than as isolated topics.

LMU / COICP can support:

requirements scenarios,
stakeholder ambiguity,
architecture decisions,
governance questions,
AI-use risks,
operational incidents,
release decisions,
postmortems,
runbooks,
review-board simulations,
and stewardship reviews.

A future populated LMU / COICP repository can provide a concrete teaching environment where students inspect artifacts, compare lifecycle stages, review evidence, and understand how trustworthy engineering accumulates over time.

Student Starter Kit¶

A student starter kit is recommended for courses adopting ETIS.

The starter kit may include:

repository folder structure,
README templates,
issue templates,
pull request templates,
requirements templates,
ADR templates,
AI-use log templates,
review checklists,
release-readiness records,
test evidence templates,
postmortem templates,
runbook templates,
and final presentation structure.

The purpose of the starter kit is not to do the work for students. The purpose is to give students a professional evidence structure so they can focus on engineering decisions, review, implementation, validation, and accountability.

Instructor Package¶

A complete instructor package may include:

syllabus template,
semester calendar,
lecture outlines,
slide decks,
assignment prompts,
project checkpoint guidance,
rubrics,
review-board exercises,
presentation guidance,
peer evaluation materials,
exam question banks,
sample answers,
repository audit guidance,
grading guides,
and LMS-ready materials.

Some instructor materials may be distributed separately to protect assessment integrity.

Public materials may include general teaching guidance, activity descriptions, and assignment structures. Instructor-only materials may include rubrics, grading notes, exam materials, sample answers, and detailed evaluation guidance.

Teaching Philosophy¶

Teaching with ETIS means teaching students to think like accountable engineers.

The goal is not to make students memorize a process.

The goal is to help students practice the habits that make software trustworthy:

define intent,
manage ambiguity,
make decisions visible,
review generated and human work,
preserve evidence,
validate claims,
communicate risks,
disclose AI assistance,
defend releases,
learn from defects,
improve operations,
and steward systems over time.

The professional lesson is direct:

Future engineers will not be judged by how much AI-assisted output they can generate. They will be judged by whether they can responsibly govern, verify, operate, and defend increasingly capable systems.

Status¶

Teaching with ETIS is active and evolving. The framework is already being used in undergraduate and graduate software engineering instruction, while the broader instructor ecosystem continues to develop through course materials, starter repositories, review activities, assessment models, and professional-practice resources.