Approaches to Software Development: Plan-Driven, Agile, and Hybrid Paradigms

UPI Study › Courses › Software Engineering › Free lessons › Lesson 1.3 Free with a free account

Approaches to Software Development: Plan-Driven, Agile, and Hybrid Paradigms

Software Engineering · Chapter 1: Foundations of Software Engineering and Process ModelsSection 1.3 · lesson 3 of 1039 min · free with a free account

← The Software Engineering Process: From Requirements Through DeploymentNext lesson: Analyzing Systems Within the Software Engineering Workflow →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

3 approaches to software development, and how to choose among them.

  • Explain the core assumption each approach makes about requirements
  • Describe the plan-driven and agile approaches
  • Explain what a hybrid approach is, and why teams blend
  • Weigh a project's trade-offs to judge which approach fits

Transcript

Everything said in the video, section by section (1,204 words). Read along, or search it.

Foundations of Software Engineering and Process Models

Plan-Driven, Agile, and Hybrid

Two teams can both be doing professional software engineering, and still work in completely different ways. This section covers the two dominant families of development approach, plan-driven and agile, and the hybrid family that blends them. And how to judge which one a given piece of work actually calls for.

2 Teams, 1 Company

Both Doing It Right

A mid-size retail company is replacing its aging inventory system. That team spends the first two months writing a detailed specification, gets it signed off by every stakeholder, and only then starts building. A different team, on the same company's mobile app, starts coding almost immediately. It shows a working slice every couple of weeks, and lets the specification evolve as customers react. Both teams are doing legitimate, professional software engineering. They simply hold different beliefs about how much can be known in advance, and how that uncertainty should be managed. Every development approach is, at bottom, a bet about how well the destination can be described before the journey begins.

Table 1.3.1

3 Approaches, 3 Assumptions

That one distinction separates three families of approach. Plan-driven assumes requirements can be known well enough, up front, to plan against. Its shape is one long planning phase, then one long construction phase. Agile assumes requirements cannot be fully known until users react to real progress. Its shape is short, repeating cycles, each producing something real. Hybrid assumes different parts of the same project carry different amounts of uncertainty. Some work has a stable destination. Government payroll, aircraft flight control, and medical billing compliance are fixed by law or by physics. Other work does not. A consumer app, a startup's first product, or a tool whose users do not yet know what they need. For those, the people who will use the system cannot fully describe what they want until they see something real.

Plan-Driven (Predictive)

Deciding Before Doing

A plan-driven approach, sometimes called predictive, treats requirements, design, and planning as work to substantially finish before construction starts. Requirements are captured in detailed, written documents, and formally approved before design begins. Progress is tracked against a schedule set at the start, and scope changes go through a formal review. Fixed-price contracts often favor this approach, because both sides want to know exactly what will be delivered before money changes hands. Its strength is predictability. It can tell a sponsor, months ahead, roughly what will exist, when, and for how much. Its weakness is the mirror image. When the requirements were wrong, or the market moved, that rigidity becomes expensive. Changing direction after a detailed plan is approved and staffed, costs far more than changing before anything was locked down.

Agile (Adaptive)

Learning by Building

An agile approach, sometimes called adaptive, starts from the opposite assumption. Requirements cannot be fully known at the outset. So build a small piece, show it to the people who will use it, learn from their reaction, and adjust. Work is organized into short, repeating cycles, each producing something real that can be inspected. This is not the absence of planning. It is planning done continuously, in small increments. Its strength is tolerance for change. A misunderstanding surfaces after a couple of weeks of work, instead of after eight months. Its weakness is that same tolerance, seen from another angle. It is hard to promise a sponsor, on day one, exactly what will exist six months later. And it depends on continuous stakeholder involvement. Someone with real authority has to be available throughout, not just at the start and the end.

Figure 1.3.3

One Spectrum, Not 3 Boxes

The three approaches are best seen as positions along one spectrum. At one end, requirements are knowable up front, and plan-driven work decides first, then builds. At the other end, requirements emerge as users react, and agile work builds, learns, and adjusts. Hybrid sits in between, matching the approach to each part of the project. The position is set by one thing. How much can genuinely be known about requirements before work begins.

Hybrid

Blending on Purpose

Very few real efforts are purely plan-driven, or purely agile, from end to end. A single system often contains a stable core, such as a database schema tied to financial regulation, or a payment processor's integration contract. Beside it sits a changeable shell, such as the screens users interact with every day. A hybrid approach applies plan-driven discipline to the stable parts, and agile discovery to the uncertain parts. It might lock down and approve the data model and regulatory logic early, while building the customer interface in short, reviewable increments. Large organizations with legacy systems, regulation, and many dependent teams often land here. Hybrid is not a compromise chosen out of indecision. It recognizes that predictability is a different answer for different parts of the same project.

Table 1.3.2

Choosing an Approach

Choosing an approach comes down to honest questions about the work, not about which approach is fashionable. Requirements stability. Well understood and fixed by law or contract favors plan-driven. Uncertain and expected to change favors agile. The cost of a late change. Very high, because of certification, safety, or contract penalties, favors plan-driven. Low to moderate favors agile. Stakeholder availability. Sign-off up front suits plan-driven. Agile needs continuous involvement. The need for an early, fixed commitment. A sponsor who needs firm scope, schedule, and cost up front points to plan-driven. And team size. Large, multi-team efforts needing tight coordination favor plan-driven. Small, co-located teams favor agile. No single factor decides alone. The honest answer is usually some of both, which is exactly what hybrid handles.

Judgment, Not Loyalty

2 Systems, 1 Hospital

Picture a hospital building two systems at once. One calculates radiation dosage for cancer treatment. The rules are fixed, and a late change could be catastrophic. That points to plan-driven. The other lets patients message their care team through a mobile app. Users will react, and needs will shift. That points to agile. And if every message also had to be logged for regulatory review, a hybrid approach would fit, locking down the logging while iterating on the app. Mismatches are costly. Plan-driven, on a fast-moving product, wastes effort planning things that will change anyway. Agile, on a system where a late change means re-certifying a medical device, is not flexible. It is reckless. The skill worth building is not loyalty to one approach, but the judgment to match the approach to the work.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A plan-driven approach treats planning and design as substantially complete before construction begins. An agile, or adaptive, approach builds in short, repeating cycles, learning from real feedback. A hybrid approach applies plan-driven discipline to stable parts of a project, and agile discovery to uncertain parts. Predictability is how reliably scope, schedule, and cost can be promised in advance. And the cost of change is how expensive it is to alter direction, once work has been planned or built.

Key Takeaways

What to Carry Forward

To pull this together. Every development approach is a bet about how well requirements can be known before work begins. Plan-driven trades flexibility for predictability. Agile trades some early predictability for the ability to absorb change cheaply. Hybrid applies each one to the parts of a project where it fits, rather than forcing one approach across everything. Weigh requirements stability, the cost of a late change, stakeholder availability, the need for early commitment, and team size. And no approach is objectively superior. The skill is matching the approach to what the work actually demands.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Approaches to Software Development: Plan-Driven, Agile, and Hybrid Paradigms

What is the difference between plan-driven and agile software development?
Plan-driven development assumes requirements can be known well enough up front to plan against, so requirements, design and planning are largely finished before construction. Agile assumes requirements cannot be fully known until users react to real progress, so work runs in short, repeating cycles that each produce something inspectable. Plan-driven trades flexibility for predictability; agile trades some early predictability for cheaper change.
What is a hybrid software development approach?
A hybrid approach applies plan-driven discipline to the stable parts of a project and agile discovery to the uncertain parts. For example, a team might lock down and approve a regulated data model or payment integration early, while building the customer-facing screens in short, reviewable increments. Hybrid is not indecision; it recognizes that different parts of one project carry different amounts of uncertainty.
How do you choose between a plan-driven and an agile approach for a project?
Choose by asking honest questions about the work rather than following fashion. Stable requirements fixed by law or contract, a very high cost of late change, a need for firm scope and cost up front, and large multi-team efforts favor plan-driven. Uncertain requirements, a low cost of change, continuously available stakeholders and small co-located teams favor agile. Often the answer is some of both.
Does agile development mean there is no planning?
No. Agile is not the absence of planning; it is planning done continuously, in small increments, as each short cycle produces feedback. Its real trade-off is that it is hard to promise a sponsor on day one exactly what will exist months later. It also depends on continuous stakeholder involvement, so someone with real authority must be available throughout, not just at the start and end.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →