BS Software Engineering

Users, requirements, and a refusal (S1B0E01) is a 45-credit course on BS Software Engineering, with 450 notional learning hours. By the end, students can draw the system, name the constraint that binds it, and compare two responses, using Users, requirements, and a refusal as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a system description, an indicator note, and a project option paper. Seminar time is for the decision, not for reading the materials aloud. Assessment is a recommendation for one decision, with the evidence and the downside. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. This course does not confer a professional engineering licence.

• System boundary, constraint, and actors — Users, requirements, and a refusal
• Indicators, sources of error, and a better measure — Users, requirements, and a refusal
• Two options on cost, time, and downside — Users, requirements, and a refusal
• Safety, environmental limit, and who bears the risk — Users, requirements, and a refusal
• A site, grid, or product decision — Users, requirements, and a refusal
• A recommendation with evidence and residual risk — Users, requirements, and a refusal

Build and review (S1AGE03) is a 45-credit course on BS Software Engineering, with 450 notional learning hours. By the end, students can draw the system, name the constraint that binds it, and compare two responses, using Build and review as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a system description, an indicator note, and a project option paper. Seminar time is for the decision, not for reading the materials aloud. Assessment is a recommendation for one decision, with the evidence and the downside. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. This course does not confer a professional engineering licence.

• System boundary, constraint, and actors — Build and review
• Indicators, sources of error, and a better measure — Build and review
• Two options on cost, time, and downside — Build and review
• Safety, environmental limit, and who bears the risk — Build and review
• A site, grid, or product decision — Build and review
• A recommendation with evidence and residual risk — Build and review

Security and responsibility (S19WF05) is a 45-credit course on BS Software Engineering, with 450 notional learning hours. By the end, students can map one named system, write a threat model, and specify the controls that would stop the most likely path, using Security and responsibility as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses control catalogues, incident write-ups, and a short technical standard. Seminar time is for the decision, not for reading the materials aloud. Assessment is a defensive design with a test plan and a statement of residual risk. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

• Assets, trust boundaries, and the adversary model — Security and responsibility
• Threat modelling and attack paths — Security and responsibility
• Identity, logging, and segmentation — Security and responsibility
• Detection, containment, and evidence — Security and responsibility
• Residual risk and what a control does not stop — Security and responsibility
• Defensive design, test plan, and after-action review — Security and responsibility

Workplace project in Software Engineering (S19CG07) is a 45-credit course on BS Software Engineering, with 450 notional learning hours. By the end, students can draw the system, name the constraint that binds it, and compare two responses, using Workplace project in Software Engineering as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a system description, an indicator note, and a project option paper. Seminar time is for the decision, not for reading the materials aloud. Assessment is a recommendation for one decision, with the evidence and the downside. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. This course does not confer a professional engineering licence.

• System boundary, constraint, and actors — Workplace project in Software Engineering
• Indicators, sources of error, and a better measure — Workplace project in Software Engineering
• Two options on cost, time, and downside — Workplace project in Software Engineering
• Safety, environmental limit, and who bears the risk — Workplace project in Software Engineering
• A site, grid, or product decision — Workplace project in Software Engineering
• A recommendation with evidence and residual risk — Workplace project in Software Engineering