Processes and Requirements

Shows how different software artifacts can be validatied — not a process model

1. Validation: "Did we build the right product?" (business perspective)

2. Verification: "Did we build the product right?" (technical perspective)

→ Validation is case-based; Verification checks consistency between artifacts

Meeting in which a Software artifact is examined/evaluated (looking at quality and correctnes,…)

Types

• inspection (check if there are problems)

• team review

• walkthrough

• pair programming (one is coding one is checking)

• pass-around, ad-hoc review (documentation is produced, send around and comments are expected)

=> remove 60-90% of errors before testing is even started

Why not used?

- consultants cannot make money

- not new

- increased up front cost

- requires consideration of psychological factors

Dangers of Reviews:

• Testing is omitted because teams assume reviews catch all errors

• Authors feel frustrated or even violated by harsh reviews

• Sloppiness: "Errors will be found during review anyway"

Dangers for Reviews:

• Managers cut review time under deadline pressure

• Reviewers are unprepared, making the process a waste

• Obfuscation: Authors hide errors behind tricky or unclear code/documents

Benefits

-> Quality, correctness

-> improved understanding on project (less dependency on one person)

-> Teaching for beginners

-> better code (readibility, good documentation)

1. Planning – Schedule, define goals, select participants

2. Overview – Author presents artifact and context

3. Preparation – Reviewers study the material individually

4. Meeting – Team discusses findings and defects

5. Rework – Author fixes identified issues

6. Follow-Up – Check if rework was done correctly

7. Causal Analysis – Identify root causes of common defects

1. Author – Creates the artifact

2. Moderator – Organizes and leads the review

3. Reader(s) – Reads the document aloud or explains it

4. Recorder – Logs all findings and decisions

5. Verifier – Confirms whether issues have been resolved

(see 7 steps)

• based on test cases

• hypothesis based reading

• architectural reading

1. The Alcoholic Pattern

   • Roles: Addicted (e.g., always late/unprepared), Helper, Punisher, Ashamed

   • Dysfunction: Review becomes a loop of enabling and blame, not improvement

2. The "Now-I-Have-Got-You" Pattern

   • Reviewer A catches B's mistake and uses it to dominate

   • B is defenseless → leads to fear and silence

3. The "See-What-You-Made-Me-Do" Pattern

   • A blames their error on reviewer B’s previous suggestion

   • Undermines mutual responsibility and trust

4. The "If-It-Were-Not-For-You" Pattern

   • A claims: “If it weren’t for you, I’d have succeeded”

   • A uses hypothetical blame to avoid accountability

5. The "Look-How-Hard-I-Tried" Pattern

   • A highlights effort to excuse poor results

   • Shifts focus from quality to sympathy

6. The "Yes-But" Pattern

   • B blocks improvements by deflecting with "yes, but..."

   • Avoids responsibility while defending poor solutions

7. The "Wouldn’t-It-Be-Nice-If" Pattern

   • B suggests fancy additions to show off, ignoring A’s constraints

   • May push A into defensive or "yes-but" mode

w

A software process model is an abstract representation of a software development process.

It defines:

• Activities to be carried out

• Roles and responsibilities

• Artifacts to be produced

• techniques and tools to be used

→ Models that define the order of phases and transition criteria are Life cycle models (e.g., Waterfall, V-Model)

The Waterfall model is a sequential process model with feedback to earlier phases.

Phases:

1. Planning

2. Definition

3. Design

4. Implementation

5. Test

6. Use & Maintenance

→ "we can specify a system completely upfront"

The V-Model is a verification and validation-oriented life cycle model.

• Left side: Development phases (from requirements to implementation)

• Right side: Corresponding testing phases (unit test to acceptance test)

• The “V” shape shows that each development step has a test counterpart

→ Encourages early thinking about tests and traceability from requirement to test

Iterative processes develop software in repeated cycles, allowing feedback and changes at each iteration.

Key Characteristics:

• Each iteration includes: requirements → design → implementation → test

• Working software is delivered early and improved continuously

• Promotes feedback-driven development and risk reduction

→ Helps deal with uncertainty, evolving requirements, and complex systems

Incremental development delivers the system in small, functional pieces, each adding value.

Evolutionary development allows the system to adapt and evolve as understanding improves.

• waterfall model

• the original V model

• the spiral model

explaining how to incorporate

1. development phases

2. testing

3. risk management

such that a full grown process can be pieced together

The Unified Process (UP) is a framework for development.

Defines

• 4 Phases

• 9 Disciplines

Benefits:

• iterative und incremental

• risk-driven

• client-driven

• architecture-centric

1. Inception

   • Define project vision, scope, and feasibility

   • Identify critical use cases, initial risks, rough estimate

2. Elaboration

   • Refine requirements, establish baseline architecture

   • Resolve high risks, plan construction phase in detail

3. Construction

   • Build the system incrementally

   • Focus on coding, testing, and integration

4. Transition

   • Deliver the final product to users

   • Handle user feedback, training, and defect correction

1. Business Modeling – Understand business context

2. Requirements – Capture and manage stakeholder needs

3. Analysis & Design – Define and design the system structure

4. Implementation – Code and build components

5. Testing – Verify functionality and quality

6. Deployment – Deliver and install the product

7. Configuration Management – Manage versions and artifacts

8. Project Management – Plan, track, and control project progress

9. Environment – Provide tools, standards, and processes

RUP additionally defines roles, activities/tasks, and artefacts/work products