Comprehensive Study Notes – Security, Reuse, Architecture, Management & Quality

Learning Outcomes

• Across Units 18 – 31 you should be able to:
  • Analyse, model and specify security / dependability, risk, quality and configuration-management requirements.
  • Apply UML, testing and software-evolution procedures to real-world systems.
  • Design and evaluate secure, resilient, service–oriented and distributed architectures.
  • Investigate reuse-based, component-based and product-line engineering strategies.
  • Manage projects (planning, scheduling, costing, people, quality, CM) end-to-end.

Security & Dependability Fundamentals

• Security = ability to protect assets from malicious attacks; tightly inter-linked with reliability, availability, safety & resilience.
• 4 classical threat classes (Sommerville §13):
  1. Interception (access) 2. Interruption (unavailability) 3. Modification (tamper) 4. Fabrication (false info).
• 3 complementary control strategies:
  • Avoid (vulnerability avoidance) • Detect (attack detection / neutralisation) • Recover (exposure limitation, backup, mirroring).
• Cost–benefit principle: never spend more to secure an asset than its value ➜ adopt risk-based security policy.

Security Policy Essentials

• Define: assets to protect, protection levels, responsibilities, legacy procedures to retain.
• High-level, non-technical, organisation-wide; engineering process realises these goals.

Security Risk-Assessment Process (Fig 13.3)

Asset I.D ➜ Value ➜ Exposure ➜ Threat ➜ Attack ➜ Controls ➜ Feasibility ➜ Requirements

• Applied preliminary, design & operational phases; generates avoidance / detection / mitigation requirements.

Security Requirements (Firesmith 10-fold taxonomy)

1. Identification 2. Authentication 3. Authorisation 4. Immunity 5. Integrity
2. Intrusion detection 7. Non-repudiation 8. Privacy 9. Auditing 10. Maintenance security.

• Mostly "shall-not" constraints; broader than safety (hostile environment, intelligent adversary, no shutdown option).

Misuse-Case Modelling

• Black ellipse complements use-case; documents threat instances (intercept, interrupt, modify, fabricate) – drives security design & tests.

Secure-System Design

• Security must be built-in; bolted-on is expensive and ineffective.
• Key design viewpoints:
  • Architectural protection layers (platform / application / record-level).
  • Distribution vs protection trade-off.
  • 10 Good-practice guidelines (Schneier, Viega & McGraw): explicit policy, defence-in-depth, fail-secure, balance usability, log actions, diversity+redundancy, input validation, compartmentalise, design-for-deployment & recovery.
• Design-Risk Assessment interleaves with architecture ⇒ generates multifactor auth, etc.

Security Testing & Assurance

• Difficult because:
  • requirements are negative • attackers are intelligent.
• 4-way strategy: Experience-based / Pen-testing / Tool-based analysis / Formal verification.

Resilience Engineering & Cyber-Security (Unit 21)

• Resilience = ability to maintain critical services under disruptive events (recognition / resistance / recovery / reinstatement).
• Cyber-threats = confidentiality, integrity, availability violations. 4-R planning (Fig 14.2) combines asset classification to reinstatement.
• Sociotechnical resilience emphasises organisational abilities: respond, monitor, anticipate, learn; use Swiss-cheese defensive layers.
• Survivable-systems analysis 4-stage loop (Fig 14.3): understand ➜ identify critical ➜ simulate attacks ➜ soft-spots & strategies.

Reuse-Based SE Landscape (Unit 22)

• Scales: objects ↜ components ↜ subsystems ↜ full applications.
• Benefits: accelerated delivery, dependable tried-and-tested assets, cost & risk reduction.
• Problems: library cost, discovery/adaptation effort, maintenance mis-match, tool support, NIH syndrome.
• Landscape map (Fig 15.1): patterns, frameworks, CBSE, product lines, MDE, SOA, generators, ERP, COTS, wrapping.

Application Frameworks & MVC

• Provide skeleton architecture; extended via subclassing + plug-ins. WAF typical services: security, dynamic pages, DB abstraction, session mgmt, AJAX/HTML5 UI.

Software Product Lines (SPL)

• Shared core + variability points; 3 component types: core (immutable), configurable, domain-specific replaceable.
• Adaptation at design-time or deployment-time.

Application System Reuse

• COTS / ERP / Integrated-systems trade-offs: faster, cheaper, but req-adaptation, vendor lock-in, interoperability issues.

Component-Based SE (Unit 23)

• Component attributes: composable, deployable, documented, independent, standardised.
• Two CBSE processes:
  • For-reuse (generalise components) • With-reuse (find–adapt–compose).
• Composition forms (Fig 16.3): Sequential, Hierarchical (requires/provides), Additive; reconcile via adaptors.

Distributed Systems & SaaS (Unit 25)

• Benefits: resource sharing, openness, concurrency, scalability, fault tolerance.
• Design issues: transparency, openness, scalability, security, QoS, failure mgmt.
• Architectures: Master–slave, 2-tier, multi-tier, distributed-components, P2P.
• SaaS traits: hosted, browser access, pay-as-use; key concerns – configurability, multi-tenancy, scalability.

Service-Oriented Architectures (Unit 26)

• SOA triad: Service Provider ↔ Registry ↔ Requestor (publish/find/bind via SOAP & WSDL).
• WS-stack (Fig 18.3): transport → SOAP → WSDL/UDDI → WS-BPEL.
• RESTful alternative: resource-centric, stateless, CRUD = HTTP POST/GET/PUT/DELETE; lightweight JSON/XML.
• Service Engineering process (Fig 18.4): candidate ID ➜ design (logical, message, REST binding) ➜ implementation & deployment.
• Service Composition workflow (Fig 18.5) from outline ➜ discovery ➜ selection ➜ executable flow (e.g.
  WS-BPEL).

Socio-technical & System-of-Systems (Units 27-28)

• Layered view (Fig 19.2): technical core ⇡ ops ⇡ processes ⇡ policies ⇡ organisation ⇡ laws.
• Emergent properties, non-determinism, wicked-problem boundaries.
• SoS criteria (Maier): operational + managerial independence, evolutionary dev, emergence, geo-distribution.
• Architecting principles: deliver value when incomplete, realistic control, interface focus, collaboration incentives.
• Architectural patterns: Data-feed hub, Container w/common services, Trading Mesh.

Project Management Essentials (Units 29-30)

• Core activities: Planning, Reporting, Risk, People, Proposal writing.
• Risk-management loop: Identify ➜ Analyse (probability/impact) ➜ Plan (avoid/minimise/contingency) ➜ Monitor.
• People factors: motivation (Maslow & personality types), consistency, respect, inclusion, honesty; balanced teams, comms & workspace.
• Planning: proposal, start-up, continual re-plan; Gantt; milestones/deliverables; agile ⇢ release & iteration planning, velocity.
• Costing: pricing factors + COCOMO $Effort=A·Size^{B}·M$. Sub-models: App-comp, Early-design, Reuse, Post-arch.

Quality Management & Measurement (Unit 30)

• 3 levels: organisation (processes/standards), project (apply & audit), plan (specific goals).
• Attributes (Fig 24.2): reliability, safety, security, usability, efficiency, maintainability, etc.
• ISO 9001 provides process-quality framework; standards = product vs process.
• Reviews/Inspections: defect removal, progress, quality; phases – prep, meeting, follow-up; agile relies on pair-programming & sprint reviews.
• Metrics: product (static/dynamic), process; empirical SE; $<br /> \text{Effort}=\sum (\text{Size}\times PF)$. Beware context & data validity.

Configuration Management (Unit 31)

• 4 pillars: Version mgmt, System build, Change mgmt, Release mgmt.
• Version control: centralized (SVN) vs distributed (Git). Concepts – codeline, branch, merge, baseline.
• System build: compile-link-package; continuous integration cycle (checkout, build, test, commit).
• Change mgmt: analyse impact, cost–benefit, approve & trace.
• Release mgmt: assemble executables + config + installer + docs; track via baselines; SaaS simplifies.

Key Equations & Notation

• COCOMO II effort: $E=A\,\times\,\text{KSLOC}^B\,\times\,\prod EM_i$
• Quality metric examples:
  • Cyclomatic complexity $V(G)=E-N+2P$
  • Defect density $D=\frac{\text{Defects}}{\text{KLOC}}$