Ch2 SW Processes 1 16

Main ideas & lessons

• Software development requires multiple tasks to reach a single goal (software production) Like registering for a course—going to the system, entering the registration service, viewing courses, selecting one, and submitting—software development also involves several coordinated activities to produce the final software product.

• Purpose of the chapter (topics covered)

  • Types of software processes
  • Types/models of software processes
  • Common tasks performed during software development
  • How to handle changes in requirements during development
  • How to improve quality of the work

• What a “software process” means

  • A software process is a structured, systematic description of activities used to develop a product.
  • It includes:
    • Activities/tasks (e.g., requirements)
    • Data collection and analysis
    • Phases/stages, such as:
      • requirements → design/programming → validation → evolution/ongoing development after releases

• The “four important tasks” (core workflow)

  1. Gather and analyze requirements
  2. Design and develop the software
  3. Validate (confirm design/programming meets the requirements)
  4. Accommodate new changes in existing systems

• Key principles when discussing process outcomes

  • Outputs of process activities can be many things, not only “the product,” for example:
    • documents
    • user interfaces
    • libraries
  • Each task has responsibilities (who does what).

  • Activities have pre-conditions and post-conditions. Example: you can’t proceed with solving/implementation until required inputs (e.g., requirements) are ready.

  • Processes are not one-size-fits-all:

    • different projects need different approaches
    • there is no single universally correct method

Types of planning/approach: Plan-driven vs Agile

1) Plan-driven

• Requires a complete plan from start to finish
• Works best when there is high clarity/completeness of:
  • requirements
  • team
  • project plan details
• Not ideal when clarity is missing or incomplete

2) Agile (plan-by-phases)

• Instead of planning the whole project upfront:
  • divide work into phases
  • plan only the current phase
  • produce Plan 1, Plan 2, Plan 3, etc.
• Suitable when the project does not have complete upfront clarity
• Real-world practice may use:
  • plan-driven
  • agile
  • a hybrid combining both
• The choice itself isn’t “right vs wrong”—differences are in execution method and project needs.

Software process models (the three models presented)

Overview of the idea

• The video presents “process models” as common ways to structure development.
• It emphasizes that organizations may need different combinations of models.

Detailed instruction-style bullet points: the models

A) Waterfall model (plan-driven)

When it’s appropriate

• When requirements are fully understood or very highly clear (e.g., ~90%+ clarity as stated)

How it is organized

• Development is split into sequential phases/stages, typically in this order:
  1. Requirements/specification
  2. Development/design & programming
  3. Testing / validation
  4. Operations / release stage (including whether improvement is needed)

Main characteristic / risk

• Mistakes found late are very costly
• Changes are “deadly” or difficult because work was already committed earlier

Illustrative lesson (“waterfall problem”)

• A late discovery of an error (e.g., restaurant orders with the wrong item discovered only when food arrives) leads to:
  • inability to efficiently undo prior steps
  • high cost to fix/rewind
  • compromises that do not deliver the desired value

---

B) Incremental development (phased smaller releases)

Goal

• Solve the waterfall issue where errors are discovered only at later stages.

How it works

• Break the larger project into smaller iterations/increments
• For each increment:
  • run the same core activities but on a smaller scope:
    • requirements/specification (initial version for that increment)
    • development
    • validation/testing
    • release of that increment/version

Illustrative lesson (“incremental restaurant order”)

• Instead of one complete order, send orders in smaller batches
  • if the issue appears in an early batch, you can stop/cancel remaining batches
• This leads to discovering mistakes earlier.

Advantages listed

• Earlier error discovery
• Customer can see and interact with progress sooner
• Easier handling of customer changes based on early feedback
• Faster production of visible results (e.g., “every two weeks they see something”)

Trade-offs / challenges

• Many changes may cause:
  • reduced clarity over time
  • potential lowering of quality because previously completed work may need rework
• Requires ongoing refactoring

Refactoring concept (as described)

• When changes happen, you must revisit and modify earlier work to ensure compatibility between old and new requirements/components.
• The video notes this can be tiring because it involves continuous renovation/adjustment.

---

C) Integration and configuration (reuse existing systems)

When it’s appropriate

• When you have existing software/systems you want to reuse
• Avoid building everything from scratch or replacing everything at once

Core idea

• Reuse existing components by integrating them into the new system.

COTS concept (Commercial Off-The-Shelf)

• Reuse a commercially available existing product rather than building it entirely new.

Types of reusable software components (examples given)

• Standalone applications integrated into the new system Example: connect/link an existing accounting program rather than rebuilding it

• Libraries reused instead of rewriting functions Example: a facial recognition library used within a broader AI system

• Web services consumed from external providers Example: fetch weather forecasts or stock prices via external services

Speakers / sources featured

• No specific individual name is provided in the subtitles.
• The source/speaker appears to be a course instructor addressing “Peace be upon you” and delivering a lecture on software processes.