Software Development Methodologies

Process · Chapter 2

Overview

Architects usually must work within the methodology their organization has already adopted, but they may influence or even select it. Knowing the common models and their trade-offs lets you suggest process improvements. Agile methodologies now dominate over traditional ones, though many Agile variants exist. Choosing a methodology unsuited to the project is a common, avoidable mistake.

The Waterfall model

A sequential model: each life-cycle stage is completed fully before the next begins.

Advantages

• Simple and easy to understand.
• Predictable for stakeholders (timeline, functionality, cost).
• Produces documentation artifacts per phase — helps maintenance, onboarding, and reduces the impact of employee turnover.

Phases

Phase	What happens
Requirements	Elicit and analyze requirements; capture in a requirements document.
Design	Create technical design specs detailing how requirements are met.
Implementation	Actual coding against the design specs.
Verification	Testing to confirm correctness and requirement fulfillment.
Maintenance	Post-deployment bug fixes and enhancements.

Names vary (coding/testing instead of implementation/verification); some orgs add analysis or deployment steps.

When it might fit (rarely all true): team already knows the domain and business rules; requirements well-understood and stable; scope fixed; technology/architecture known and stable; project small and low-complexity; acceptable that no working software appears until late; a fixed deadline is already set.

Issues with Waterfall

• No testing feedback until late (testing follows all implementation).
• Users get no working software until the end — feedback arrives too late and requirements can be missed.
• Late changes are expensive → cost/time overruns.
• If time runs out, end-stage testing gets cut, lowering quality.
• Rigidity is a major problem because change in software is almost inevitable.

Agile software development methodologies

Created by practitioners from real-world experience to address traditional-model limitations. Variants include Scrum, Kanban, Extreme Programming (XP), and Crystal — all centered on adaptability to change and balancing too-little vs. too-much process.

Core values (Agile Manifesto)

• Individuals and interactions over processes and tools — people understand the business and drive development.
• Working software over documentation — keep only enough documentation.
• Customer collaboration over contract negotiation — continuous engagement increases fit to real needs.
• Responding to change over following a plan — short iterations let requirements be added/changed anytime they add value.

Documented in the Agile Manifesto plus its 12 principles.

Iterative and incremental

• Software is built incrementally; each iteration satisfies part of the requirements and ends in a working version.
• Testing happens in the same iteration as coding → continuous feedback, problems surface sooner.

Adaptive rather than predictive

• Instead of heavy up-front planning to predict the future, Agile adapts to change as it occurs.
• User/tester feedback is incorporated immediately into subsequent iterations.

Daily stand-up meeting (daily scrum in Scrum)

• Brief, usually early in the day; everyone gives a status update.
• A rotating facilitator runs it (no reliance on one person; keeps the team talking to each other).
• Each person answers three questions: What did I do yesterday? What will I do today? Any impediments?
• Larger discussions are taken offline to keep it short.
• Benefits: shared awareness of current work; impediments surface so the team can help; reinforces team identity.

Related

• Legacy transitions: moving to an agile approach.
• Delivery culture: DevOps.

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.2 “Software development methodologies”, pp. 90-101.