Course audit report

Software Engineering

Done Role: Backend Engineer Working On Real-Time Distributed Systems 4 Findings Software Engineering — Process, Lifecycle, And Project Management
Auditor Done Market Fit Done Topics Done
Run another role
4 findings · 2 medium 2 low
Outdated 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 ✓ Source checked

jakarta.ee ↗

Java EE technologies contributed by Oracle are being used to create the new Jakarta EE platform... Initially Jakarta EE was the exact equivalent to the Java EE 8 platform.

What to learn instead

Refer to Jakarta EE (the current standard maintained by the Eclipse Foundation since 2018) rather than 'J2EE'. The 'J2EE' brand was renamed to 'Java EE' with version 5 in 2006, and again to 'Jakarta EE' when stewardship was transferred from Oracle to the Eclipse Foundation. Modern equivalents include Jakarta EE and Spring.

Outdated L2-Ch2 SW Processes.pptx, Slide 55 ('The SEI capability maturity model')

What the slide says

The SEI capability maturity model: Initial / Repeatable / Defined / Managed / Optimising

Primary source ✓ Source checked

www.sei.cmu.edu ↗

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

Teach the current CMMI maturity levels — Initial, Managed, Defined, Quantitatively Managed, Optimizing — rather than the retired Software CMM v1.1 levels (which used 'Repeatable' at level 2). The Software CMM was superseded by CMMI starting in 2002, and the CMMI product suite was transferred to the CMMI Institute (now part of ISACA) in 2013; CMMI V3.0 was released in 2023.

Outdated Ch1 Introduction.pptx, Slide 25

What the slide says

Interface development technologies such as AJAX and HTML5 have emerged that support the creation of rich interfaces within a web browser.

Primary source ✓ Source checked

www.w3.org ↗

HTML and DOM shall be developed principally in the WHATWG, following WHATWG Living Standard (LS) specification process... W3C agrees to discontinue its release plans for W3C versions of HTML 5.3 and DOM 4.1.

What to learn instead

Refer to 'the HTML Living Standard' (maintained by WHATWG) rather than 'HTML5'. Since the May 2019 W3C/WHATWG MOU, the W3C stopped publishing versioned HTML 5.x recommendations and recognizes the WHATWG Living Standard as the single authoritative HTML/DOM specification.

Outdated L4-Ch23 Project planning-v2.pptx, Slide 67 ('The exponent term')

What the slide says

The company has a CMM level 2 rating.

Primary source ✓ Source checked

www.sei.cmu.edu ↗

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

Update worked examples to reference 'CMMI maturity level 2 (Managed)'. The standalone Software CMM was retired in favor of CMMI; certifications since 2002 have been issued against CMMI, not the original SW-CMM.

Within its declared scope (software engineering process), the curriculum is a faithful 2014 Sommerville-style course — strong on UML, Scrum/XP, GoF patterns, COCOMO II, and CMM — but its three in-scope process artifacts that haven't kept pace with 2026 backend practice are tool-less version control (no Git), the absence of CI/CD pipelines (with the curriculum still asserting CI is 'practically impossible' at scale), and an architectural pattern catalog that stops at client-server and never reaches microservices.

Gaps

Git (modern distributed version control)

Version control is squarely in scope (configuration management is a core software-engineering-process topic and IS taught in Ch7). However, the curriculum teaches it only at the abstract 'version management system' level — Ch7 Slide 46 says 'Version management, where support is provided to keep track of the different versions of software components,' but never names Git, GitHub, branching strategies, pull requests, merge conflicts, or distributed version control. In 2026 this is the single most universal backend tool (9/12 postings demand it explicitly). The taught form is the 2014 Sommerville-era abstraction; the market form is hands-on Git fluency. For a real-time distributed systems specialization, Git is the substrate on which trunk-based development and continuous delivery sit.

CI/CD pipelines (continuous integration and continuous delivery as a process practice)

Build/integrate/release automation is a software-engineering-PROCESS topic, not infrastructure — it belongs to this course's actual subject area. The curriculum touches automated test harnesses (JUnit) and 'frequent system builds' but never teaches CI/CD pipelines, build servers, or deployment automation. Worse, it teaches an outdated position: Ch3 Slide 53 explicitly states 'Continuous integration is practically impossible' (in the context of large-scale agile). That 2014-era assessment has been overturned in practice — 8/12 backend postings now require CI/CD as a baseline expectation. For real-time distributed systems, where multi-service deployment cadence and automated rollback are routine, the absence of CI/CD pipelines in the process curriculum is a substantive gap.

Microservices architecture pattern

Architectural design is in scope (Ch6 is dedicated to architectural patterns). The curriculum teaches MVC, Layered, Repository, Client-Server, and Pipe-and-Filter (Ch6 Slides 23-38) — the canonical 2014 pattern catalog — but never introduces microservices, service decomposition, bounded contexts, inter-service communication patterns, or distributed-system trade-offs (CAP, eventual consistency, saga patterns). 8/12 postings list 'microservices' as a required or preferred skill. Given the user's specialization on real-time distributed systems, this is the single most directly relevant architectural gap: the student leaves the course able to draw a 4+1 view of a monolith but without vocabulary for the dominant 2026 distributed-backend architectural style.

What the curriculum actually teaches (23 skills)
  • Waterfall SDLC model · software_engineering
    Ch2 SW Processes, Slide 9: 'Waterfall model phases: Requirements analysis and definition; System and software design; Implementation and unit testing; Integration and system testing; Operation and maintenance.'
  • Incremental / iterative development · software_engineering
    Ch2 SW Processes, Slide 7: 'Incremental development - Specification, development and validation are interleaved. May be plan-driven or agile.'
  • Agile Manifesto principles · software_engineering
    Ch3 Agile, Slide 5: 'Individuals and interactions over processes... Customer collaboration over contract negotiation... Responding to change over following a plan.'
  • Extreme Programming (XP) practices: user stories, refactoring, test-first, pair programming · software_engineering
    Ch3 Agile, Slide 14: 'Key practices: User stories for specification; Refactoring; Test-first development; Pair programming.'
  • Scrum framework (sprints, product backlog, scrum master, daily scrums) · software_engineering
    Ch3 Agile, Slide 35-37: 'Sprints are fixed length, normally 2–4 weeks. The starting point for planning is the product backlog... The role of the Scrum master is to protect the development team from external distractions.'
  • Test-driven development (TDD) with JUnit · software_engineering
    Ch3 Agile, Slide 22: 'Writing tests before code clarifies the requirements to be implemented... Usually relies on a testing framework such as Junit.' Reinforced in Ch8 Testing, Slide 44.
  • User stories and scenarios for requirements elicitation · software_engineering
    Ch3 Agile, Slide 15: 'User requirements are expressed as user stories or scenarios. These are written on cards and the development team break them down into implementation tasks.'
  • Functional vs. non-functional requirements specification · software_engineering
    Ch4 Req Eng, Slide 14: 'Functional requirements: Statements of services the system should provide... Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints.'
  • Requirements elicitation via interviews, ethnography, and use-case scenarios · software_engineering
    Ch4 Req Eng, Slide 38: 'Formal or informal interviews with stakeholders are part of most RE processes.' Slide 41: 'A social scientist spends a considerable time observing and analysing how people actually work.'
  • UML modeling: use-case, sequence, class, state-machine, and activity diagrams · software_engineering
    Ch5 System modeling, Slide 6: 'Activity diagrams... Use case diagrams... Sequence diagrams... Class diagrams... State diagrams, which show how the system reacts to internal and external events.'
  • Architectural patterns: MVC, Layered, Repository, Client-Server, Pipe-and-Filter · software_engineering
    Ch6 Architectural design, Slides 23-38: 'The Model-View-Controller (MVC) pattern... Layered architecture... Repository architecture... Client-server architecture... Pipe and filter architecture.'
  • 4+1 architectural view model · software_engineering
    Ch6 Architectural design, Slide 19: '4 + 1 view model of software architecture: A logical view... A process view... A development view... A physical view... Related using use cases or scenarios (+1).'
  • GoF design patterns: Observer, Façade, Iterator, Decorator · software_engineering
    Ch7 Implementation, Slide 38: 'Tell several objects that the state of some other object has changed (Observer pattern)... Façade pattern... Iterator pattern... Decorator pattern.'
  • Generic configuration management / version management (no tool named) · software_engineering
    Ch7 Implementation, Slide 46: '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 — Git, SVN, Mercurial — named anywhere in the curriculum.)
  • Unit, component, interface, system, regression, release, and acceptance testing · software_engineering
    Ch8 Testing, Slide 18: 'Unit testing... Component testing... System testing.' Slide 48: 'Regression testing is testing the system to check that changes have not broken previously working code.' Slide 59: 'Alpha testing... Beta testing... Acceptance testing.'
  • Equivalence partitioning and guideline-based test case design · software_engineering
    Ch8 Testing, Slide 27: 'Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. Test cases should be chosen from each partition.'
  • Performance and stress testing · software_engineering
    Ch8 Testing, Slide 56: 'Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable. Stress testing is a form of performance testing where the system is deliberately overloaded to test its failure behavior.'
  • Software evolution, legacy reengineering, and refactoring · software_engineering
    Ch9 Evolution, Slide 49: 'Software reengineering: Restructuring or rewriting part or all of a legacy system without changing its functionality.' Slide 55: 'Refactoring is the process of making improvements to a program to slow down degradation through change.'
  • Risk management process (identification, analysis, planning, monitoring) · software_engineering
    Ch22 Project management, Slide 13: 'Risk identification... Risk analysis... Risk planning... Risk monitoring.'
  • Project scheduling with bar charts and activity networks · software_engineering
    Ch23 Project planning, Slide 30: 'Bar charts are the most commonly used representation for project schedules. They show the schedule as activities or resources against time. Activity networks show task dependencies.'
  • Agile planning game and team velocity estimation · software_engineering
    Ch23 Project planning, Slide 40: 'Stories are assigned effort points reflecting their size and difficulty of implementation. The number of effort points implemented per day is measured giving an estimate of the team's velocity.'
  • COCOMO II algorithmic cost estimation (application composition, early design, reuse, post-architecture sub-models) · software_engineering
    Ch23 Project planning, Slide 57: 'COCOMO 2 incorporates a range of sub-models... Application composition model... Early design model... Reuse model... Post-architecture model.' Slide 61 gives the formula PM = A * Size^B * M.
  • SEI Capability Maturity Model (CMM) levels · software_engineering
    Ch2 SW Processes, Slide 55: 'Initial... Repeatable... Defined... Managed... Optimising.'

The three in-scope, market-validated process gaps are: (1) hands-on Git as the concrete instantiation of the course's 'version management' abstraction (75% of postings, 9/12), (2) microservices added to Ch6's architectural-pattern catalog (66.7%, 8/12) — the most directly relevant gap to the student's real-time distributed-systems specialization, and (3) CI/CD pipelines as a first-class process practice replacing the curriculum's outdated 'CI is practically impossible' position (66.7%, 8/12). Together these touch every one of the 12 backend postings analyzed.

These three prescriptions close 100% of the gaps surfaced by Market-fit (3 of 3) and are the only in-scope deltas — Market-fit's other top-frequency demands (SQL, Docker, Postgres, REST API, AWS, Linux, Redis, Kubernetes, Kafka, Python, Go, OAuth/JWT, Nginx, Prometheus, GraphQL) are out of this course's declared scope (programming-language implementation, frameworks, databases, infrastructure, deployment) and therefore cannot be addressed here without violating the scope contract — they are gaps for OTHER courses in the curriculum to own, not this one. Honest read: fixing these three brings the software-engineering-process course up to 2026 backend practice; it does not by itself make a student job-ready for backend roles.

#1 ~14h to learn

Hands-on Git: distributed version control, branching strategies, pull requests, merge-conflict resolution, and trunk-based development

Upgrade Ch7's tool-less 'version management' slide to a real Git workflow — the substrate every real-time distributed-systems team commits, reviews, and ships on.

gitbranchingpull requestmerge conflicttrunk-based developmentdistributed version control

Where it fits

software_engineering · Configuration management / version management is already a declared topic in Ch7 Implementation (Slide 46). The natural fix is to replace the abstract 'version management system' treatment with a concrete Git module that still belongs to the process-and-lifecycle scope of the course — branching strategies, pull-request review workflow, and merge-conflict resolution are process practices, not infrastructure or framework knowledge.

Prerequisites

  • Generic configuration management / version management concept · already covered in software_engineering
  • Incremental / iterative development · already covered in software_engineering
  • Command-line basics not yet covered
#2 ~18h to learn

Microservices architecture pattern: service decomposition, bounded contexts, inter-service communication, and distributed-system trade-offs (CAP, eventual consistency, saga patterns)

Extend Ch6's pattern catalog past client-server into microservices — the architectural vocabulary 8 of 12 backend roles, and every real-time distributed-systems posting, expect graduates to already speak.

microservicesservice decompositionbounded contextscap theoremeventual consistencysaga

Where it fits

software_engineering · Architectural design is an explicit chapter (Ch6) and currently teaches MVC / Layered / Repository / Client-Server / Pipe-and-Filter. Microservices is the next architectural pattern in that same catalog — the addition stays inside the course's declared 'architectural patterns' subject area without bleeding into framework-specific implementation. It can be taught as a pattern with structure, when-to-use, and trade-offs, in the same shape as the existing GoF and architectural patterns.

Prerequisites

  • Architectural patterns: MVC, Layered, Repository, Client-Server, Pipe-and-Filter · already covered in software_engineering
  • 4+1 architectural view model · already covered in software_engineering
  • Functional vs. non-functional requirements specification · already covered in software_engineering
  • UML modeling: component / sequence diagrams for inter-service interaction · already covered in software_engineering
#3 ~12h to learn

CI/CD pipelines as a software-engineering process practice: automated build, integration, test, and release pipelines

Replace Ch3's 'CI is practically impossible' slide with a real CI/CD pipeline module — the deploy-cadence backbone real-time distributed-systems teams rely on for safe multi-service rollout and rollback.

ci/cdcontinuous integrationcontinuous deliverybuild automationrelease pipelineautomated rollback

Where it fits

software_engineering · Build/integrate/release automation is squarely a software-engineering PROCESS topic — it is the modern realization of 'frequent system builds' and the test-harness culture the course already endorses (Ch3 TDD, Ch8 Testing). The fix also requires retiring Ch3 Slide 53's 2014-era claim that 'continuous integration is practically impossible' at scale, which is no longer the industry consensus. Treated as a process practice (pipelines, gates, automated rollback), it fits the course scope without crossing into infrastructure-tool teaching.

Prerequisites

  • Test-driven development (TDD) with JUnit · already covered in software_engineering
  • Unit, component, interface, system, regression, release, and acceptance testing · already covered in software_engineering
  • Generic configuration management / version management · already covered in software_engineering
  • Hands-on Git workflow not yet covered