Course audit report

Software Engineering

Done Role: Software Engineer 3 Findings Software Engineering — Process, Requirements, And Project Management
Auditor Done Market Fit Done Topics Done
Run another role
3 findings · 1 high 1 medium 1 low
Incorrect 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 ✓ Source checked

agilemanifesto.org

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.

Outdated 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 ✓ 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

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.

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

www.oracle.com

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.

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.

Gaps

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

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)

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

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.

What the curriculum actually teaches (30 skills)
  • Software lifecycle models (Waterfall, Incremental, Reuse-oriented / Integration & Configuration) · L2-Ch2 SW Processes.pptx
    Ch2 Slide 7: 'The waterfall model — Plan-driven model. Separate and distinct phases of specification and development. Incremental development — Specification, development and validation are interleaved... Integration and configuration — The system is assembled from existing configurable components.'
  • Agile manifesto principles · Ch3. Agile SW Dev-V2.pptx
    Ch3 Slide 5 (Agile manifesto): 'Individuals and interactions over processes / Tools over comprehensive documentation / Customer collaboration over contract negotiation / Responding to change over following a plan.'
  • Scrum (sprints, product backlog, Scrum master, daily Scrum, Scrum-of-Scrums) · Ch3. Agile SW Dev-V2.pptx
    Ch3 Slide 35: 'Sprints are fixed length, normally 2–4 weeks. The starting point for planning is the product backlog... selection phase involves all of the project team who work with the customer to select the features...'
  • Extreme Programming practices (pair programming, refactoring, user stories, on-site customer) · Ch3. Agile SW Dev-V2.pptx
    Ch3 Slide 14 (Influential XP practices): 'User stories for specification / Refactoring / Test-first development / Pair programming.'
  • Test-Driven Development (TDD) using JUnit-style automated test frameworks · Ch3. Agile SW Dev-V2.pptx, Ch8.Testing.pptx
    Ch8 Slide 23 (Automated testing): 'In automated unit testing, you make use of a test automation framework (such as JUnit) to write and run your program tests.' Ch3 Slide 22: 'Usually relies on a testing framework such as Junit.'
  • Requirements engineering process (elicitation, specification, validation, change management) · Ch4 Req Eng.pptx
    Ch4 Slide 28: 'a number of generic activities common to all processes — Requirements elicitation; Requirements analysis; Requirements validation; Requirements management.'
  • Functional vs non-functional requirements with measurable metrics · Ch4 Req Eng.pptx
    Ch4 Slide 25 (Usability requirements example): 'Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)'
  • User stories and scenarios for requirements specification · Ch3. Agile SW Dev-V2.pptx, Ch4 Req Eng.pptx
    Ch4 Slide 45: 'Scenarios and user stories are real-life examples of how a system can be used. Stories and scenarios are a description of how a system may be used for a particular task.'
  • Ethnography for requirements discovery · Ch4 Req Eng.pptx
    Ch4 Slide 41 (Ethnography): 'A social scientist spends a considerable time observing and analysing how people actually work.'
  • UML modeling — class diagrams, sequence diagrams, use case diagrams, state machine diagrams, activity diagrams · Ch5 System modeling.pptx
    Ch5 Slide 6 (UML diagram types): 'Activity diagrams... Use case diagrams... Sequence diagrams... Class diagrams, which show the object classes in the system and the associations between these classes. State diagrams...'
  • Model-Driven Engineering / MDA (CIM, PIM, PSM) · Ch5 System modeling.pptx
    Ch5 Slide 50 (Types of model): 'A computation independent model (CIM)... A platform independent model (PIM)... Platform specific models (PSM).'
  • Architectural patterns — MVC, Layered, Client-Server, Repository, Pipe-and-Filter · Ch6 Architectural design.pptx
    Ch6 Slide 23: 'The Model-View-Controller (MVC) pattern.' Ch6 Slide 33: 'Client-server architecture / Distributed system model which shows how data and processing is distributed across a range of components.' Ch6 Slide 36: 'Pipe and filter architecture.'
  • Multi-tier web/application architecture (web server / app server / database server) · Ch6 Architectural design.pptx
    Ch6 Slide 51: 'These systems are often implemented as multi-tier client server/architectures... The web server is responsible for all user communications, with the user interface implemented using a web browser; The application server is responsible for implementing application-specific logic... The database server moves information to and from the database and handles transaction management.'
  • Service-oriented systems and APIs (conceptual) · Ch1 Introduction.pptx, Ch5 System modeling.pptx
    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. Direct service-to-service communication is therefore possible.'
  • Object-oriented design process (context modeling, object identification, interface specification) · Ch7 Implementation.pptx
    Ch7 Slide 7 (Process stages): 'Define the context and modes of use of the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces.'
  • Gang-of-Four design patterns (Observer, Façade, Iterator, Decorator) · Ch7 Implementation.pptx
    Ch7 Slide 38 (Design problems): 'Tell several objects that the state of some other object has changed (Observer pattern). Tidy up the interfaces to a number of related objects... (Façade pattern). Provide a standard way of accessing the elements in a collection... (Iterator pattern). Allow for the possibility of extending the functionality of an existing class at run-time (Decorator pattern).'
  • Configuration management — version management, system integration, problem tracking (tool-agnostic) · Ch7 Implementation.pptx
    Ch7 Slide 46 (Configuration management activities): '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. System integration... Problem tracking...'
  • Open-source license models (GPL, LGPL, BSD) · Ch7 Implementation.pptx
    Ch7 Slide 59 (License models): 'The GNU General Public License (GPL)... The GNU Lesser General Public License (LGPL)... The Berkley Standard Distribution (BSD) License.'
  • Software testing levels (unit, component, system, release, user/acceptance) · Ch8.Testing.pptx
    Ch8 Slide 18 (Development testing): 'Unit testing, where individual program units or object classes are tested... Component testing, where several individual units are integrated... System testing, where some or all of the components in a system are integrated...'
  • Equivalence partitioning and partition-based test case design · Ch8.Testing.pptx
    Ch8 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.'
  • Regression testing and automated test harnesses · Ch8.Testing.pptx
    Ch8 Slide 48 (Regression testing): 'Regression testing is testing the system to check that changes have not "broken" previously working code... with automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program.'
  • Performance and stress testing (release-stage) · Ch8.Testing.pptx
    Ch8 Slide 56 (Performance testing): '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...'
  • Software evolution, legacy-system management, refactoring and re-engineering · Ch9 Evolution.pptx
    Ch9 Slide 55 (Refactoring): 'Refactoring involves modifying a program to improve its structure, reduce its complexity or make it easier to understand. When you refactor a program, you should not add functionality but rather concentrate on program improvement.'
  • Risk management process (identification, analysis, planning, monitoring) · L3-Ch22 Project management.pptx
    Ch22 Slide 13 (The risk management process): 'Risk identification — Identify project, product and business risks; Risk analysis — Assess the likelihood and consequences of these risks; Risk planning... Risk monitoring...'
  • Team composition and motivation (task/self/interaction-oriented; Maslow needs) · L3-Ch22 Project management.pptx
    Ch22 Slide 35: 'Task-oriented people, who are motivated by the work they do... Interaction-oriented people, who are motivated by the presence and actions of co-workers. Self-oriented people, who are principally motivated by personal success and recognition.'
  • Project scheduling — bar charts, activity networks, milestones, deliverables · L4-Ch23 Project planning-v2.pptx
    Ch23 Slide 30 (Schedule presentation): '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.'
  • Algorithmic cost estimation with COCOMO II (application composition, early design, reuse, post-architecture) · L4-Ch23 Project planning-v2.pptx
    Ch23 Slide 57 (COCOMO 2 models): 'Application composition model... Early design model... Reuse model... Post-architecture model.'
  • Agile planning game / story-points / team velocity / iteration & release planning · L4-Ch23 Project planning-v2.pptx
    Ch23 Slide 40 (Story-based planning): '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".'
  • SEI Capability Maturity Model (Initial → Repeatable → Defined → Managed → Optimising) · L2-Ch2 SW Processes.pptx
    Ch2 Slide 55 (The SEI capability maturity model): 'Initial — Essentially uncontrolled / Repeatable... / Defined... / Managed — Quality management strategies defined and used / Optimising — Process improvement strategies defined and used.'
  • Continuous integration (mentioned, framed as difficult at scale) · Ch3. Agile SW Dev-V2.pptx
    Ch3 Slide 53 (Scaling up to large systems): 'Continuous integration is practically impossible. However, it is essential to maintain frequent system builds and regular releases of the system.' Ch3 Slide 9 (XP): 'New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully.'

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.

These three prescriptions cover 3 of 3 gaps (100%) surfaced by Market-fit. They do NOT close the larger market-fit deficit on framework/language demands (Node.js, TypeScript, Postgres, React, CSS/Tailwind, Docker, Jest, Next.js, GraphQL, Kubernetes, AWS) — those are correctly omitted per Rule 2 because they exceed this course's process/methodology depth bound and would belong in a hands-on web-development or DevOps course instead. Honest framing: this course can be made market-aware in its process vocabulary, but cannot by itself prepare a fullstack hire — the curriculum needs a complementary implementation course.

#1 ~6h to learn

Distributed version control workflows with Git — branching strategies (trunk-based vs. GitFlow) and pull-request code review as a process artifact

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.

gitdistributed version controlbranchingpull requestcode reviewtrunk-based developmentgitflow

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.

Prerequisites

  • Version management / configuration management concepts · already covered in Ch7 Implementation.pptx (Slide 46)
  • Incremental development lifecycle · already covered in L2-Ch2 SW Processes.pptx (Slide 7)
  • Software inspection / review as a quality activity · already covered in Ch8.Testing.pptx
#2 ~4h to learn

REST as an architectural style for HTTP APIs — resources, statelessness, uniform interface via HTTP verbs (conceptual extension of client-server)

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).

resthttpresourcesstatelessnessuniform interfaceapi designclient-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.

Prerequisites

  • Client-server architectural pattern · already covered in Ch6 Architectural design.pptx (Slide 33)
  • Multi-tier web/application architecture · already covered in Ch6 Architectural design.pptx (Slide 51)
  • Service-oriented systems and APIs (conceptual) · already covered in Ch5 System modeling.pptx (Slide 55)
#3 ~4h to learn

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

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.

continuous integrationcontinuous deliveryci/cdautomated builddeployment pipelinestaging environmentrelease 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.

Prerequisites

  • Automated regression testing · already covered in Ch8.Testing.pptx (Slide 48)
  • XP frequent-build cadence / TDD · already covered in Ch3. Agile SW Dev-V2.pptx (Slides 9, 22)
  • Incremental development and release planning · already covered in L2-Ch2 SW Processes.pptx (Slide 7); L4-Ch23 Project planning-v2.pptx
  • Tool-agnostic configuration management / system integration · already covered in Ch7 Implementation.pptx (Slide 46)