# Software Engineering — Stale course audit

- URL: https://getstale.tech/run/web_20260504T162928Z
- Target role: Software Engineer
- Course focus: Software Engineering — Process, Requirements, And Project Management
- Audit date: 2026-05-04T16:29:28Z
- Verified findings: 3
- Structured data: https://getstale.tech/run/web_20260504T162928Z.json

## Findings

### 1. Incorrect (high severity)

**Location:** Ch3. Agile SW Dev-V2.pptx slide 5

**What the slide says:**

> The slide presents the Agile Manifesto values as: 'Individuals and interactions over processes / Tools over comprehensive documentation / Customer collaboration over contract negotiation / Responding to change over following a plan'

**Primary source:** https://agilemanifesto.org/ (verified)

> Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

**What to learn instead:** Teach the four values verbatim from the canonical Manifesto for Agile Software Development: 'Individuals and interactions over processes and tools', 'Working software over comprehensive documentation', 'Customer collaboration over contract negotiation', and 'Responding to change over following a plan'. The slide currently splits 'processes and tools' across two values and replaces 'Working software' with 'Tools', producing an incorrect version of the manifesto.

### 2. Outdated (medium severity)

**Location:** L2-Ch2 SW Processes.pptx slide 55

**What the slide says:**

> Slide presents 'The SEI capability maturity model' with five levels (Initial, Repeatable, Defined, Managed, Optimising) as the current SEI model for process improvement.

**Primary source:** https://www.sei.cmu.edu/history-of-innovation/transforming-software-quality-assessment/ (verified)

> Eventually, the Capability Maturity Model Integration (CMMI) framework, managed with software community guidance by the SEI for more than a decade, evolved from the Software CMM.

**What to learn instead:** Replace references to the original Software CMM with CMMI (Capability Maturity Model Integration), which superseded it. The CMMI staged maturity levels are: Initial, Managed, Defined, Quantitatively Managed, Optimizing (note 'Repeatable' is no longer a level, and 'Quantitatively Managed' replaces the old 'Managed' level). Note also that CMMI is now stewarded by the CMMI Institute (a subsidiary of ISACA), not the SEI.

### 3. Outdated (low severity)

**Location:** L2-Ch2 SW Processes.pptx slide 15

**What the slide says:**

> 'Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.'

**Primary source:** https://www.oracle.com/java/technologies/java-ee-glance.html (verified)

> Java Platform, Enterprise Edition (Java EE) is the standard in community-driven enterprise software.

**What to learn instead:** Replace 'J2EE' with 'Jakarta EE' (or at minimum 'Java EE'). The 'J2EE' brand was retired when the platform was renamed to 'Java EE' starting with version 5 in 2006, and the platform was further transferred to the Eclipse Foundation and renamed 'Jakarta EE' in 2017–2018. Modern courses should reference Jakarta EE.

## Market fit

A 2014-vintage Sommerville-based process course that is well-aligned with timeless software-engineering fundamentals (Scrum, XP, UML, requirements engineering, testing levels, COCOMO II) but presents version control, web APIs, and continuous integration in pre-DevOps abstract terms — leaving fullstack-bound students to learn Git/PR workflows, REST API design, and CI/CD pipelines elsewhere.

### Modern distributed version control with Git (branching strategies, pull-request code review workflow) (high)

The course covers configuration management at a tool-agnostic level. Ch7 Slide 46 (Configuration management activities) only goes as far as: 'Version management, where support is provided to keep track of the different versions of software components. Version management systems include facilities to coordinate development by several programmers.' No specific tool, branching model, or code-review workflow is named. The fullstack market has standardized on Git-based workflows (branching, pull-request review, trunk-based vs. GitFlow). Extending this slide conceptually — distributed VCS vs. centralized, branching strategies, and pull-request review as a process artifact — fits the course's process/methodology depth bound without crossing into hands-on `git` syntax (which would exceed it).

### REST as an architectural style for HTTP APIs (resources, statelessness, HTTP verbs) (high)

The architecture chapter teaches client-server abstractly and mentions web APIs in passing. Ch6 Slide 33 (Client-server architecture): 'Distributed system model which shows how data and processing is distributed across a range of components... Set of stand-alone servers which provide specific services... Set of clients which call on these services.' Ch5 Slide 55 (iLearn service integration): 'Integrated services are services which offer an API (application programming interface) and which can be accessed by other services through that API.' REST is never named as the dominant style of modern client-server APIs, even though 9/12 fullstack postings demand it. Extending the architectural-patterns module with a conceptual treatment of REST (resource modeling, HTTP verbs as a uniform interface, statelessness) extends partial coverage at the conceptual level the course already operates at — without descending into framework-specific endpoint coding.

### Continuous integration and continuous delivery pipelines as a process discipline (high)

The course already touches CI but stops short. Ch3 Slide 53 (Scaling up to large systems) explicitly says: 'Continuous integration is practically impossible. However, it is essential to maintain frequent system builds and regular releases of the system' — framing CI as infeasible. Ch3 Slide 9 (XP) says 'New versions may be built several times per day... All tests must be run for every build and the build is only accepted if tests run successfully', and Ch8 Slide 48 covers automated regression testing. The pieces of CI/CD (automated tests + frequent builds + incremental releases) are taught separately but not assembled into the modern pipeline concept that 7/12 fullstack postings name explicitly. Extending these slides to cover CI/CD as a process model (automated build + test + deploy on every commit; staging vs production environments; release vs deploy decoupling) stays within the methodology depth bound; specific YAML pipeline tooling would not.

## Recommended topics

The three prescriptions — Git/PR workflows (rank 1, 92% of postings), REST as a named architectural style (rank 2, 75%), and CI/CD as an assembled process discipline (rank 3, 58%) — together close every gap surfaced by Market-fit. Each one extends a slide that already exists (Ch7 Slide 46, Ch6 Slides 33/51, Ch3 Slides 9/53) and adds only conceptual/process-level content, respecting the course's methodology depth bound.

### #1 Distributed version control workflows with Git — branching strategies (trunk-based vs. GitFlow) and pull-request code review as a process artifact (~6h to learn)

Extend the configuration-management slide from generic 'version management' to the Git branching + pull-request review workflow that 11 of 12 fullstack postings assume students already understand.

Keywords: git, distributed version control, branching, pull request, code review, trunk-based development, gitflow

Where it fits: Ch7 Implementation.pptx — Slide 46 (Configuration management activities) · Ch7 already teaches configuration management generically ('Version management... include facilities to coordinate development by several programmers. System integration... Problem tracking...'). The natural extension is to name distributed VCS (Git) as the dominant model and to introduce the pull-request review loop as a process artifact that connects version management, problem tracking, and quality control. This stays at the methodology/process level the course operates at — no `git` syntax, no GitHub-specific UI walkthrough.

### #2 REST as an architectural style for HTTP APIs — resources, statelessness, uniform interface via HTTP verbs (conceptual extension of client-server) (~4h to learn)

Promote REST from an unnamed background assumption to a first-class architectural pattern in Ch6 — 9 of 12 fullstack postings demand it, and the course already teaches every prerequisite (client-server, multi-tier, service APIs).

Keywords: rest, http, resources, statelessness, uniform interface, api design, client-server

Where it fits: Ch6 Architectural design.pptx — Slide 33 (Client-server architecture) and Slide 51 (Multi-tier web/application architecture) · Ch6 already teaches client-server architecture abstractly and introduces multi-tier web systems (web server / app server / database server). Ch5 Slide 55 mentions APIs at the conceptual level ('Integrated services... offer an API... can be accessed by other services'). The natural extension is to name REST as the dominant architectural style of modern client-server APIs and treat it as an architectural-pattern entry alongside MVC, Layered, and Pipe-and-Filter. This stays conceptual (resource modelling, statelessness, HTTP verbs as a uniform interface) without descending into Express/Spring endpoint coding, which would breach the depth bound.

### #3 Continuous integration and continuous delivery as a process discipline — assembling frequent builds, automated regression tests, staging vs. production environments, and the release-vs-deploy distinction (~4h to learn)

Rewrite Ch3's 'CI is practically impossible' note into the modern CI/CD pipeline concept — the course already teaches every ingredient (frequent builds, automated regression, incremental releases); 7 of 12 fullstack postings now name the assembled pipeline by name.

Keywords: continuous integration, continuous delivery, ci/cd, automated build, deployment pipeline, staging environment, release management

Where it fits: Ch3. Agile SW Dev-V2.pptx — Slide 53 (Scaling up) and Slide 9 (XP build cadence), reinforced in Ch8.Testing.pptx Slide 48 (Regression testing) · The course teaches the constituent pieces piecemeal — XP's 'New versions may be built several times per day... All tests must be run for every build' (Ch3 Slide 9), automated regression testing (Ch8 Slide 48), and incremental delivery (L2-Ch2). It also explicitly says 'Continuous integration is practically impossible' at scale (Ch3 Slide 53), framing CI as a problem rather than today's standard practice. The natural extension is to update Slide 53 and assemble the existing pieces into the modern CI/CD pipeline as a process model: build + test + deploy on every commit, environment promotion, and decoupling release from deploy. Implementation tooling (GitHub Actions YAML, Jenkinsfile internals) is correctly out of scope for this methodology course.

---
Produced by Stale (https://getstale.tech). Request a course audit: https://getstale.tech/request-audit