Software Process Models & Reuse-Oriented Development – Comprehensive Notes

Waterfall Model

• Origin & Nature
  • First formally published software life-cycle model (Royce, $1970$); derived from general systems engineering.
  • Plan-driven: all major activities are scheduled and costed before execution.
• Core Phases (always the same $5$, though they may overlap in practice):
  1. Requirements analysis & definition – capture services, constraints, goals; output = system specification.
  2. System & software design – allocate functions to HW/SW; create architecture & detailed abstractions.
  3. Implementation & unit testing – produce program units; verify each unit against its spec.
  4. Integration & system testing – assemble units; validate full system against requirements; deliver to customer.
  5. Operation & maintenance – typically the longest phase; correct undiscovered errors, improve implementations, add new services.
• Management Strengths
  • Rich documentation at every phase ⇒ high process visibility for managers/auditors.
  • Consistent with other engineering disciplines → easier organisational alignment.
• Major Limitations
  • Inflexible partitioning; early commitments freeze requirements prematurely.
  • Costly to iterate because every document requires formal “sign-off”.
  • Mismatch with realities of evolving requirements ⇒ risk of systems that “won’t do what the user wants”.
• Recommended Usage
  • Suitable only when requirements are well-understood & stable, or when organisational governance demands heavy documentation.

Formal & Cleanroom Variants

• Formal System Development
  • Build a mathematical specification; refine it via provably correct transformations into executable code.
  • Basis for safety/security cases in high-integrity systems (e.g., B-Method).
  • Pros: rigorous correctness argument; simplifies regulator approval.
  • Cons: demands specialised expertise; high upfront cost; rarely cost-effective for ordinary products.
• Cleanroom Software Engineering (IBM)
  • Goal: “zero-defects” delivered software → exceptionally high reliability.
  • Process: formal specification → formal correctness proofs → implementation; no unit testing, only statistical system-level reliability testing.
  • Focuses on defect prevention rather than defect removal.

Incremental Development

• Concept
  • Build an initial working version, receive feedback, evolve through multiple increments until “adequate”.
  • Specification, development, and validation are concurrent activities with rapid feedback.
• Delivery Styles
  • Plan-driven: all increments pre-planned.
  • Agile: early increments fixed; later ones decided dynamically by customer priority & progress.
• Benefits (vs. waterfall)
  1. Lower cost of accommodating change.
  2. Easier customer feedback through executable software instead of documents.
  3. Earlier, more frequent delivery of usable functionality.
• Management & Technical Problems
  1. Process invisibility – hard for managers to gauge progress without heavy documentation.
  2. Structural degradation – successive changes corrupt architecture unless time is set aside for refactoring.
  3. Acute in large, long-lived systems: need a stable architecture & clear team responsibilities planned in advance.
• Practical Advice
  • Possible to expose increments for feedback without full deployment (avoids disrupting live operations).

Evolutionary Process Models

Evolutionary models recognise that software evolves; product is delivered through a series of growing versions.

Prototyping Paradigm

• When to Use
  • Requirements fuzzy, stakeholders “clueless about the details”.
  • Developer uncertainty about algorithms, platforms, or user interaction.
• Steps
  1. Communication → capture overall objectives & known requirements.
  2. Quick Plan & Quick Design → focus on UI/visible aspects.
  3. Construction of Prototype (may leverage existing code fragments, RAD tools).
  4. Deployment & Feedback → stakeholders evaluate; feedback loops refine requirements.
• Two Outcomes
  • Throw-away prototype: serves only for requirements discovery, then discarded (Brooks’ “Plan to throw one away”).
  • Evolutionary prototype: incrementally refined into final product (risk = poor quality foundations).
• Risks & Mitigations
  • Stakeholders mistake prototype for near-finished product → must set expectations early.
  • Quick-n-dirty technical choices may become entrenched → consciously re-engineer after learning.

Spiral Model (Boehm)

• Essence
  • Risk-driven, cyclic generator for process definition.
  • Each loop: grow system definition & implementation while reducing risk.
• Four Generic Quadrants per Loop
  1. Objective setting & planning – determine goals, constraints, alternatives.
  2. Risk analysis & prototyping – evaluate alternatives, build proof-of-concepts.
  3. Engineering & construction – design, code, test the chosen solution.
  4. Customer evaluation & next-phase planning – obtain feedback, commit to next loop.
• Anchor-point milestones: tangible criteria ensuring stakeholder commitment.
• Evolutionary Releases: early loops may produce models; later loops deliver progressively complete versions.
• Lifecycle Adaptability: same spiral can guide concept studies, new-product development, enhancements, and maintenance.
• Strengths
  • Explicit, continuous risk management.
  • Combines systematic discipline (like waterfall) with iterative learning (like prototyping).
• Challenges
  • Requires skilled risk assessors; missing a major risk can be fatal.
  • Contracting & fixed-budget environments may resist iterative replanning of cost/schedule after each loop.

Concurrent Model (Concurrent Engineering)

• View process as a network of concurrently executing activities, each in a well-defined state.
• Example states (Figure 2.8): Inactive → Under development → Under review → Baselined → Awaiting changes → Done.
  • Total distinct states illustrated = $12$.
• Events (e.g., “analysis model correction”) trigger state transitions across the network.
• Benefits
  • Accurate, real-time picture of project status.
  • Supports multi-disciplinary product engineering where different teams work in parallel.

Reuse-Oriented / Component-Based Development

• 21st-century processes increasingly focus on systematic reuse of existing software assets.
• Depend on:
  1. A large repository of reusable components (libraries, frameworks, COTS products).
  2. Integration frameworks to compose them.
• Three Typical Component Sources (text mentions but does not list all three in excerpt):
  • Black-box COTS packages (e.g., spreadsheet engine).
  • In-house reusable modules.
  • Open-source or third-party components.
• Generic Reuse-Oriented Process (Figure 2.3)
  1. Component Analysis – search repositories against requirements; perfect matches rare.
  2. Requirements Modification – adapt/specify requirements to align with discovered components; may loop back if unsuitable.
  3. System Design with Reuse – craft or reuse framework/architecture accommodating selected components; design new pieces only where necessary.
  4. Development & Integration – build missing parts, glue code, configure COTS; integration is embedded inside development, not a post-phase.
  5. System Validation – verify integrated system meets (modified) requirements.
• Benefits
  • Reduced development time & cost; potential for higher reliability (components are pre-tested).
• Issues
  • Licensing, version compatibility, interface mismatches, limited customisability.

Specialised Process Model: Component-Based Development (CBD)

• Extends reuse idea: application is constructed from pre-packaged components with well-defined interfaces.
• Inherits iterative nature of the spiral model but emphasises component identification & integration over new coding.
• Components may be conventional modules, object-oriented classes, or packages (collections of related classes).
• Process Steps (abbreviated)
  • Domain analysis → identify candidate components.
  • Component qualification → does it meet functional, performance, quality criteria?
  • Adaptation → wrap or modify to fit architecture.
  • Assembly → compose components using orchestration/glue code.
  • System evolution → replace/upgrade components over time.

Balancing Flexibility, Speed, and Quality

• Modern competitive contexts (“edge of chaos”) prioritise speed, flexibility, extensibility over “zero defects”.
• Experts (e.g., Yourdon $1995$, Bachmann $1997$) argue for evolutionary models that trade some upfront quality assurance for earlier market entry.
• Challenge: find proper balance; ultimate arbiter = customer satisfaction & critical project parameters.
• Incremental, evolutionary, and component-based models provide mechanisms to achieve this balance by delivering early value and enabling change.

Key Quotes & Scenario Illustrations

• Frederick P. Brooks: “$\text{Plan to throw one away}$ … Your only choice is whether to sell the throw-away to customers.”
• Dave Matthews Band lyric cited to emphasise journey & uncertainty: “I’m only this far and only tomorrow leads my way.”
• V. Daniel Hunt on process purpose: “Every process in your organisation has a customer, and without a customer a process has no purpose.”
• SafeHome / CPI Corporation Meeting Dialogues
  • Engineers debate process choice: waterfall deemed “old-school”; incremental/spiral embraced for reality matching.
  • Management tension: desire for fixed plan vs. need for adaptive replanning each spiral loop.
  • Highlights organisational change management: may need to “re-educate” senior management.

Comparative Takeaways

• No single model is a panacea; selection depends on
  • Stability of requirements.
  • Regulatory demands.
  • Risk profile & tolerance.
  • Need for speed vs. need for assurance.
  • Availability of reusable components & organisational culture.
• Hybrid Approaches Common
  • E.g., a plan-driven incremental backbone with agile-style prototyping for UX, plus CBD integration.
• Continuous attention to architecture & refactoring critical to prevent structural decay in incremental/evolutionary settings.
• Systematic risk assessment (spiral) and real-time state tracking (concurrent) enhance control without sacrificing flexibility.