Software Engineering | Semester 5 Core Notes
Semester 5 - Page 5: Software Engineering. 26 numbered topics, highlighted rules, worked room-booking examples, answered exam questions, lifecycle/trace diagrams, comparison tables and three complete Python teaching tools. General common-core guide, not an official syllabus or production booking system.
Topic map
- Software engineering and lifecycle
- Feasibility and stakeholder analysis
- Functional and quality requirements
- Elicitation and specification
- Requirements validation and traceability
- Process models and waterfall
- Incremental, spiral and prototyping
- Agile practices and feedback
- Use cases, context and UML
- Data and behavior modeling
- Architecture and responsibility boundaries
- Cohesion, coupling and interfaces
- Design principles and patterns
- Planning, work breakdown and estimation
- Size, effort and cost models
- Risk management
- Verification versus validation
- Reviews, static analysis and test levels
- Black-box test design and boundaries
- White-box coverage and limitations
- Defect reporting and regression
- Version and configuration management
- CI, delivery, deployment and rollback
- Security, accessibility and quality assurance
- Maintenance and technical debt
- Requirements change and release evidence
1. Software engineering and lifecycle
Software engineering applies disciplined methods to build and maintain software under constraints. Lifecycle activities can repeat rather than finish once in a rigid line.
Answer: No. Useful process reduces defects and wrong assumptions; paperwork alone does not.
2. Feasibility and stakeholder analysis
Study technical, operational, economic and schedule feasibility. Stakeholders have different goals and permissions; record whose need each requirement serves.
Answer: No. Cost, operation, legal/privacy constraints and timeline matter too.
3. Functional and quality requirements
Functional requirements describe behavior; quality requirements state measurable constraints. Vague terms such as fast or friendly need observable criteria.
Answer: No. Define tasks, conditions and success measures.
4. Elicitation and specification
Interviews, observation, workshops and prototypes uncover needs. A specification records scope, assumptions, interfaces, constraints and acceptance criteria with consistent terms.
Answer: No. Check conflicts, feasibility, missing details and intended outcomes.
5. Requirements validation and traceability
Review requirements for clarity, consistency, feasibility and user fit. Trace each requirement to design, implementation and tests; traceability helps assess change impact.
Answer: No. Links need actual verified behavior and evidence.
Stakeholder need -> measurable requirement -> design responsibility -> code + tests -> release evidence + feedback
Requirements-to-test traceability gap report
requirements = {"R1": "prevent overlap", "R2": "keyboard booking", "R3": "owner approval"}
coverage = {"R1": ["unit_overlap", "database_concurrency"], "R2": [], "R3": ["owner_positive", "other_user_denied"]}
for key in sorted(requirements):
tests = coverage.get(key, [])
print(key + ": " + (", ".join(tests) if tests else "MISSING TEST LINK"))
print("Trace links are a planning check, not proof that tests passed.")
Checked output:
R1: unit_overlap, database_concurrency R2: MISSING TEST LINK R3: owner_positive, other_user_denied Trace links are a planning check, not proof that tests passed.
6. Process models and waterfall
Waterfall-style models emphasize staged planning; iterative models revisit learning. Choose a process for uncertainty, constraints and feedback, not as a quality slogan.
Answer: No. Change still needs controlled review and consequence handling.
7. Incremental, spiral and prototyping
Incremental delivery adds working slices; prototyping tests assumptions; spiral-style work emphasizes risk-driven cycles. A disposable prototype is not automatically production code.
Answer: Its shortcuts and incomplete guarantees must not be mistaken for production readiness.
8. Agile practices and feedback
Agile emphasizes working software, collaboration and response to change while recognizing value in other practices. Short iterations still need design, testing, documentation and scope choices.
Answer: No. Planning and records should support delivery and change.
9. Use cases, context and UML
A use case follows an actor's goal through main and alternate flows. Context, class, sequence and state diagrams answer different questions; choose diagrams with a clear purpose.
Answer: Not directly. A sequence diagram is suited to message order.
10. Data and behavior modeling
Model entities, relationships, invariants and state transitions. Identify what persists and who can change each state.
Answer: No. Define allowed transitions and permissions explicitly.
Requested -> Approved -> Canceled
\-> Rejected
Each transition checks actor + state + policy11. Architecture and responsibility boundaries
Architecture selects components, contracts and deployment boundaries for actual needs. UI presentation, domain rules and persistence have different responsibilities.
Answer: No. Network contracts, data and failure dependencies remain.
12. Cohesion, coupling and interfaces
High cohesion keeps a module's job focused; appropriate low coupling limits dependence on internals. Interfaces can isolate change, but needless abstraction also has cost.
Answer: No. Use boundaries that address real testing/change needs.
13. Design principles and patterns
Encapsulation hides unstable details; separation of concerns and suitable patterns organize responsibilities. A pattern is a reusable design idea, not a requirement to add layers everywhere.
Answer: No. Check complexity, contracts, behavior and actual change risks.
14. Planning, work breakdown and estimation
Break work into deliverable pieces with dependencies, review/testing/release work and uncertainty. Estimates are forecasts, not guarantees.
Answer: Unknowns, integration and changes alter effort and schedule.
Dependency-aware earliest finish calculation
tasks = {"requirements": (2, []), "design": (3, ["requirements"]),
"UI": (4, ["design"]), "API": (5, ["design"]),
"integration": (2, ["UI", "API"]), "review": (1, ["integration"])}
finish = {}
while len(finish) < len(tasks):
progress = False
for name, (duration, dependencies) in tasks.items():
if name in finish or not all(d in finish for d in dependencies):
continue
start = max((finish[d] for d in dependencies), default=0)
finish[name] = start + duration
print(name + ": start=" + str(start) + " finish=" + str(finish[name]))
progress = True
if not progress:
raise ValueError("cycle or missing dependency")
print("minimum elapsed units:", max(finish.values()))
print("Assumes unlimited parallel resources; not a real delivery promise.")
Checked output:
requirements: start=0 finish=2 design: start=2 finish=5 UI: start=5 finish=9 API: start=5 finish=10 integration: start=10 finish=12 review: start=12 finish=13 minimum elapsed units: 13 Assumes unlimited parallel resources; not a real delivery promise.
15. Size, effort and cost models
LOC, function points and model-based estimates measure different things and require calibrated assumptions. Effort is person-time; calendar duration depends on dependencies and team coordination.
Answer: No. Coordination, onboarding and serial dependencies limit gains.
16. Risk management
A risk is an uncertain event with possible consequence; an issue has already happened. Record likelihood, impact, response, owner and trigger. Reassess rather than leaving a static list.
Answer: No. Evaluate the full consequence and response options.
17. Verification versus validation
Verification checks conformance to specified requirements/design; validation checks whether the product solves the actual user need. Both matter and occur throughout development.
Answer: Yes. Specification conformance alone does not establish fitness for purpose.
18. Reviews, static analysis and test levels
Reviews/static analysis inspect without executing the target behavior. Unit, integration, system and acceptance tests address different scopes. Passing tests does not prove absence of all defects.
Answer: No. Actual integration behavior needs separate checks.
19. Black-box test design and boundaries
Equivalence partitions group input classes; boundary tests exercise edges; decision tables capture combinations; state tests exercise transitions. Expected results must come from rules, not the implementation under test.
Answer: An incorrect inequality can reject valid adjacency or accept overlap.
Exhaustive bounded interval-rule checks
from itertools import product
def overlaps(a, b):
if a[0] >= a[1] or b[0] >= b[1]:
raise ValueError("positive duration required")
return a[0] < b[1] and b[0] < a[1]
intervals = [(start, end) for start in range(5) for end in range(start+1, 6)]
checked = 0
for a, b in product(intervals, repeat=2):
# Independent reference for integer half-open intervals.
reference = bool(set(range(*a)) & set(range(*b)))
assert overlaps(a, b) == reference
checked += 1
print("intervals:", len(intervals))
print("pairs checked:", checked)
print("adjacent:", overlaps((1, 2), (2, 3)))
print("intersecting:", overlaps((1, 3), (2, 4)))
try:
overlaps((2, 2), (2, 3))
except ValueError as error:
print("invalid:", error)
Checked output:
intervals: 15 pairs checked: 225 adjacent: False intersecting: True invalid: positive duration required
20. White-box coverage and limitations
Statement, branch and path coverage describe exercised code structure. Full branch coverage still does not establish correct assertions, all data interactions or complete behavior.
Answer: No. Coverage is a measure of execution, not a correctness proof.
21. Defect reporting and regression
A defect report needs environment, steps, expected/actual behavior and useful evidence. Severity describes impact; priority describes ordering. Add regression checks for fixed behavior.
Answer: No. Release timing and affected usage also influence priority.
22. Version and configuration management
Version control tracks source changes; configuration management controls versions, dependencies and release baselines. Small reviewed changes and reproducible builds make recovery easier.
Answer: No. Review, tests and compatibility checks still matter.
23. CI, delivery, deployment and rollback
Continuous integration checks merged changes; delivery/deployment terms describe release readiness/automation under team conventions. Plan rollback or forward recovery, especially for data migrations.
Answer: No. Data transformations may be irreversible or require explicit recovery.
Change -> review -> build/tests -> release baseline -> deploy -> health + user outcome checks -> recovery plan when needed
24. Security, accessibility and quality assurance
Quality includes security, accessibility, reliability, performance and maintainability with stated priorities. QA practices prevent/manage problems; testing is one part, not the whole activity.
Answer: No. Channel confidentiality and access policy are distinct.
25. Maintenance and technical debt
Corrective work fixes defects; adaptive work responds to environment change; perfective work improves behavior; preventive work reduces future risk. Debt choices need visible cost and follow-through.
Answer: No. Evaluate actual change cost, risk and intentional tradeoffs.
26. Requirements change and release evidence
Review a change's reason, affected users/contracts/data/tests and acceptance criteria. Verify both the new behavior and retained expectations after release.
Answer: When agreed behavior is implemented, reviewed, tested and verified under its actual delivery conditions.
Requirement-to-check examples
| Requirement | Design | Evidence |
|---|---|---|
| No overlapping approvals | Service rule + durable concurrency control | Unit boundaries + concurrent DB test |
| Own records only | Server-side object authorization | Owner succeeds; other user denied |
| Keyboard booking | Labels, focus and controls | Actual keyboard flow check |
| Search within target time | Measured load assumptions | Performance test under stated conditions |
Test and review scope
| Activity | Checks | Does not establish alone |
|---|---|---|
| Static review | Design/source issues | Runtime behavior |
| Unit | Small rule/module | Whole system concurrency |
| Integration | Real boundaries working together | Every user workflow |
| System | End-to-end system behavior | Fitness for every real user |
| Acceptance | Agreed user criteria | Absence of all future defects |
Maintenance distinctions
| Type | Purpose | Example |
|---|---|---|
| Corrective | Fix a defect | Repair overlap inequality |
| Adaptive | Changed environment | Update API integration |
| Perfective | Improve behavior/usability | Simplify approval screen |
| Preventive | Reduce future risk | Improve tests and fragile structure |
Revision and project checklist
Write testable requirements, draw responsibility boundaries, trace tests, include uncertainty in plans and distinguish verification from validation. Test double booking at a real durable boundary, not only by a local arithmetic predicate. Record release evidence and recovery choices.
Resources and sources
Engineering knowledge areas, testing guidance and version-control documentation support these concepts. All diagrams, examples and offline tools here are original.
Comments
Post a Comment