CPIA Module 9, Section 1: SDLC Models (Waterfall, Agile, Hybrid)
MODULE 9: THE SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

Section 1: SDLC Models (Waterfall, Agile, Hybrid)

An exploration of the core methodologies that govern software projects. We’ll compare the rigid, sequential Waterfall model with the flexible, iterative Agile framework to understand how different projects demand different approaches.

SECTION 9.1

Understanding the Blueprints of Development

Choosing the right project methodology is the single most important factor determining a project’s success.

9.1.1 The “Why”: Predictability vs. Adaptability

Before we dissect specific models, we must understand the fundamental tension at the heart of every technology project. It is a constant battle between two opposing, yet equally valid, goals: the desire for predictability and the need for adaptability. The methodology a team chooses is simply its strategy for managing this conflict.

Predictability is the goal of the project manager, the finance department, and the hospital executives. They need to know: What exactly are we building? How much will it cost? When will it be done? They crave detailed plans, fixed budgets, and firm deadlines. They want to minimize risk by defining everything upfront, creating a clear, linear path from start to finish. This approach values documentation, control, and adherence to the original plan. In the world of healthcare IT, predictability means being able to tell the Chief Nursing Officer that the new barcode medication administration (BCMA) system will be live across all 30 hospitals in the system on June 1st of next year, and that the final cost will be within 5% of the $15 million budget. This is the language of capital planning and operational management.

Adaptability, on the other hand, is the reality of the clinical world. Medicine is not static. A new clinical guideline is published by the American Heart Association. A critical drug shortage forces a change in the standard TPN formulation. A competitor hospital implements a new feature that your physicians now demand. A workflow that looked perfect on paper proves to be clunky and unsafe in practice. Clinicians and end-users need the development process to be flexible enough to respond to these discoveries and changing realities. They value working software over comprehensive documentation and collaboration over contract negotiation. They need to see, touch, and use the product as it’s being built to provide meaningful feedback. Adaptability means that when a pharmacist testing the new BCMA system discovers that scanning a patient’s wristband logs them out of the entire EHR, the development team can immediately pivot to fix this critical safety flaw, even if it wasn’t part of the original plan for that week.

Understanding this core conflict is essential. When you, as an informatics pharmacist, feel frustrated by a project’s rigid inability to change, you are feeling the constraints of a predictability-focused model like Waterfall. When you feel overwhelmed by constant changes and a seemingly shifting finish line, you are experiencing the challenges of an adaptability-focused model like Agile. Neither is inherently “good” or “bad.” They are simply different tools for different jobs. Your expertise lies in helping the organization choose the right tool and then mastering your role within that chosen framework. Your ability to speak both languages—the language of fixed timelines and budgets to leadership, and the language of iterative feedback and workflow improvement to clinicians—will define your success as an informatics leader.

Retail Pharmacist Analogy: The Pharmacy Remodel

Imagine your pharmacy is undergoing a major renovation. The choice of how to manage this construction project is a perfect parallel to choosing an SDLC model.

Option A: The “Waterfall” Remodel. The corporate office sends an architect. You have one meeting where you describe everything you want: a new consultation window, a larger will-call area, an automated dispensing cabinet. The architect goes away for two months and comes back with a complete, final blueprint. It is signed, sealed, and sent out to bid. A construction crew arrives, puts up walls, and for the next six months, you are locked out of the space. You have no input. One day, they reveal the “finished” pharmacy. It’s exactly what the blueprint said, but you immediately see a problem: the new consultation window is directly in the path of the workflow from the drive-thru, creating a constant bottleneck. It’s a critical design flaw, but it’s too late. Changing it now would require demolition, new blueprints, and a massive budget increase. You are stuck with a beautiful, but functionally flawed, pharmacy. This is the risk of prioritizing predictability over adaptability.

Option B: The “Agile” Remodel. Instead of a final blueprint, the architect and a small construction team work with you in two-week phases (“sprints”). Sprint 1: They just frame the new walls with tape on the floor. You and your technicians walk through the “space” and say, “This feels too tight.” They adjust the tape immediately. Sprint 2: They build the will-call counter. You realize it’s too high for patients in wheelchairs. They lower it the next day. Sprint 3: They install the consultation window. You immediately spot the workflow bottleneck from the drive-thru. They work with you to redesign its location before it’s permanently installed. At the end of each two-week sprint, your pharmacy is a little more complete and has been improved by your constant feedback. The final result might not be exactly what was imagined at the very beginning, but it is guaranteed to be highly functional and tailored to your actual needs. This is the power of prioritizing adaptability.

9.1.2 Deep Dive: The Waterfall Model

The Waterfall model is the oldest and most traditional of the SDLC methodologies. Its name perfectly describes its structure: each phase of the project flows downwards, like a waterfall, into the next. A phase cannot begin until the previous phase is 100% complete and signed off on. There is no going back up the waterfall. This approach is rooted in the physical engineering and construction worlds, where building a foundation before designing the roof is a physical necessity. It prizes thorough documentation, formal reviews, and rigid control over scope.

Visualizing the Waterfall Flow

1. Requirements

Define & document everything.

2. System Design

Create the technical blueprint.

3. Implementation

Write the code.

4. Testing

Verify against requirements.

5. Deployment

Go-live.

6. Maintenance

Support & bug fixes.

The Role of the Pharmacist in Each Waterfall Phase

Phase 1: Requirements Gathering & Analysis

This is the most critical phase in a Waterfall project, and it is where the informatics pharmacist’s contribution is most vital. The goal is to create a comprehensive, unambiguous, and complete document that outlines every single thing the final software must do. This document, often called a Business Requirements Document (BRD) or Functional Specification Document (FSD), becomes the “bible” for the rest of the project. If a feature is not in the BRD, it will not be built. Period.

Your role here is that of the Subject Matter Expert (SME) and Clinical Translator. You will participate in dozens of hours of meetings with business analysts and project managers. You will lead them on “gemba walks” to observe current-state workflows in the central pharmacy, on nursing units, and in clinics. You will be asked to articulate not just the “happy path” workflow, but every possible exception, every edge case, every potential error state. You are responsible for ensuring the final document accurately reflects the complexities of clinical practice and medication safety. This means thinking through questions like: What happens if the prescriber enters a pediatric dose for an adult patient? What alert should fire? What if the ordered medication is on the Beers list for an elderly patient? What happens if the ordered IV is incompatible with the patient’s running maintenance fluid? Each of these scenarios must be thought through, debated, and documented with precision before this phase can be considered complete.

The Peril of Missed Requirements in Waterfall

Imagine your team is building a new CPOE order set for a chemotherapy regimen. During the requirements phase, you meticulously detail the drug, dose, diluent, and infusion rate. The BRD is 200 pages long and is signed off. Six months later, during final testing, you realize you forgot to specify that the infusion requires a specific 0.22-micron filter. This requirement was never documented. Because you are in a Waterfall model, this discovery is catastrophic. The development team rightly states that “in-line filter” was not in the BRD. Adding it now is not a simple tweak; it requires going all the way back to the design phase. It impacts the database, the user interface for nursing, the MAR display, and potentially the billing module. The project sponsor is now faced with a terrible choice: delay the project by months and spend thousands of unbudgeted dollars to add the filter, or release the order set without this critical safety feature. This is the immense pressure of the Waterfall requirements phase. Getting it right upfront is everything.

Phase 2: System Design

Once the BRD is signed and locked, the technical teams take over. Architects design the database structure, developers plan the software’s internal logic, and UI/UX designers create mockups and wireframes that represent the visual layout of the application. The key thing to understand is that they are designing a solution based only on what is written in the BRD. They will interpret the text of the document and translate it into a technical design.

Your role here is that of a Validator. You will be shown these design documents and mockups and asked to confirm that they correctly interpret the requirements. This is your last chance to catch a major misunderstanding before coding begins. You might look at a wireframe for a new prescription entry screen and notice that the “Days Supply” field is placed before the “SIG” field, which is counterintuitive to a pharmacist’s workflow. While you can’t add a new feature, you can and should provide feedback on the layout and usability to ensure the design is safe and efficient. For example: “Based on the requirement that we must capture a diagnosis for all sedative-hypnotic orders, this mockup correctly includes a diagnosis field. However, its placement at the bottom of the screen makes it easy to miss. Can we move it adjacent to the medication name and make it a required field to ensure compliance?”

Phase 3: Implementation (Coding)

This is typically the longest phase of a Waterfall project. The development team takes the design documents and begins writing the code. For the clinical team, including the informatics pharmacist, this phase is often a long period of silence. You have given them the blueprints, and now they have gone off to build the house. You have very little visibility into the day-to-day progress. Your involvement is minimal, usually limited to answering occasional, specific questions from the developers when they encounter ambiguity in the specification document. A developer might email you and ask, “The BRD says the dose for Medication X should be ‘renally adjusted,’ but it doesn’t specify the exact dose ranges for each CrCl bucket. Can you provide those details?” Your ability to provide a swift, precise answer is crucial to keeping the project on track.

Phase 4: Testing / Verification

After all the code is written, the completed software is handed over to a dedicated Quality Assurance (QA) team. Their job is to test the application rigorously, not from a workflow perspective, but from a technical one. They are testing to ensure it meets the specifications laid out in the BRD. “When I click button X, does dialog box Y appear?”

After the QA team has finished, your primary role comes back into focus: User Acceptance Testing (UAT). You, along with a team of end-users (other pharmacists, technicians, nurses), will be given the software and a series of test scripts. Your job is to perform these scripted workflows to confirm, from a clinical perspective, that the software functions as expected. This is not the time to suggest new ideas; it is a formal process of verifying that the final product matches the original blueprint. Every bug or issue discovered is formally logged, triaged, and fixed by the development team in a cycle of “test-fix-retest” until the software is deemed stable enough for release.

Phase 5 & 6: Deployment and Maintenance

Deployment in a Waterfall project is almost always a “big bang” event. On a specific date, the old system is turned off, and the new system is turned on for everyone. Your role during this “go-live” is one of support. You will be a super-user, a trainer, and a front-line problem solver, helping your colleagues navigate the new system. Following deployment, the project transitions into the Maintenance phase. Your role becomes one of ongoing support, troubleshooting user-reported issues, and, critically, beginning the process of gathering requirements for the *next* major version or project.

Masterclass Table: Pros and Cons of the Waterfall Model

Strengths of Waterfall Weaknesses of Waterfall
High Predictability: Because the scope is fixed from the start, it’s easier to estimate timelines and budgets. This is highly valued by hospital leadership. Extreme Inflexibility: The model’s greatest strength is also its fatal flaw. It cannot accommodate change. A new regulatory requirement or clinical guideline discovered mid-project can be impossible to incorporate.
Comprehensive Documentation: The emphasis on creating a detailed BRD means there is a robust, written record of the system’s intended functionality. This is invaluable for training and future maintenance. Delayed User Feedback: End-users do not see or touch the software until the very end of the project during UAT. By this time, it is often too late to make meaningful changes to the core design.
Simple, Clear Structure: The sequential phases are easy to understand and manage. Everyone knows what phase the project is in and what the deliverables are for that phase. High Risk of Building the Wrong Product: The biggest risk in Waterfall is that the team can spend months or years perfectly executing a flawed plan, delivering a product that meets the specification document but fails to meet the actual, evolving needs of the clinicians.
Excellent for Stable Projects: If the requirements are truly known, fixed, and unlikely to change (e.g., building a system to integrate with a specific piece of hardware like a new IV pump), Waterfall can be a very efficient model. Very Slow Time-to-Value: No value is delivered to the end-users until the entire project is complete. A project could be in development for 18 months with no tangible benefit seen by the pharmacy until “go-live” day.

9.1.3 Deep Dive: The Agile Methodology

Agile is not a single methodology, but rather a mindset or philosophy, a collection of principles and values that prioritize adaptability over predictability. It was born in the early 2000s as a direct response to the widespread failures of large-scale Waterfall projects. The creators of Agile recognized that for most software projects, especially in complex and rapidly changing fields like healthcare, it is impossible to know all the requirements upfront. The Agile approach, therefore, embraces change. It is designed to deliver small pieces of working software in short, iterative cycles, gathering user feedback at every step of the way to ensure the final product truly meets the users’ needs.

The Agile Manifesto: A Pharmacist’s Translation

The core of Agile is captured in four simple values. To be an effective Agilist, you must internalize these and apply them to your clinical informatics work.

  • Individuals and interactions over processes and tools.
    Pharmacist’s Translation: A 15-minute conversation with a nurse about a proposed workflow is more valuable than a 200-page specification document. We solve problems by talking to each other, not by pointing to a document.
  • Working software over comprehensive documentation.
    Pharmacist’s Translation: It is better to have a simple, functioning CPOE order set that we can test and get feedback on this week than to spend six months writing a perfect document about what the order set will eventually do.
  • Customer collaboration over contract negotiation.
    Pharmacist’s Translation: The pharmacist (the customer) is not an outsider who just signs a requirements document. You are an embedded, daily member of the development team, working together towards a shared goal.
  • Responding to change over following a plan.
    Pharmacist’s Translation: During development, we discover a major safety concern with our initial design. We don’t say, “It’s too late to change.” We celebrate that we found the issue early and immediately pivot our plan to address it.

The Agile Ecosystem: Understanding Scrum

While Agile is the philosophy, **Scrum** is the most popular framework or “operating system” for putting that philosophy into practice. It is a lightweight yet powerful set of rules and roles that helps teams structure their work in iterative cycles called **Sprints**.

The Three Scrum Roles
  • The Product Owner: This is the most likely role for an informatics pharmacist. The Product Owner is the “voice of the customer.” They are responsible for understanding the clinical needs, defining the features that need to be built, and, most importantly, prioritizing those features in a master list called the Product Backlog. They do not manage the team, but they are the ultimate authority on what the team should be working on to deliver the most clinical value.
  • The Scrum Master: This individual is a servant-leader and coach for the team. They are not a project manager. Their job is to facilitate the Scrum process (the meetings, the rules) and, crucially, to remove any impediments that are slowing the development team down.
  • The Development Team: This is a cross-functional group of individuals (developers, QA testers, designers, analysts) who have all the skills necessary to turn the Product Owner’s vision into a piece of working software. They are self-organizing and are responsible for deciding *how* to build the features prioritized by the Product Owner.
The Scrum Cycle: An Iterative Engine

Scrum operates in short, time-boxed cycles called Sprints, which are typically 1-4 weeks long. The goal of each Sprint is to produce a potentially shippable increment of working software.

A Typical 2-Week Sprint

Product Backlog
→
Sprint Planning
→
The Sprint (2 Weeks)

Daily Scrums, Build, Test, Collaborate

→
Sprint Review

Demo Working Software

Agile in Action: Building a New Vancomycin Dosing Protocol Tool

Let’s walk through a few sprints of a real-world project, with you, the informatics pharmacist, acting as the Product Owner.

The Vision: To build a new EHR tool that helps pharmacists dose vancomycin using AUC/MIC calculations, replacing the old trough-based method.

Sprint 0 – Preparation: Before the first sprint, you work with stakeholders (ID pharmacists, renal pharmacists, IT leadership) to create the initial Product Backlog. This is a list of everything the tool could possibly do, written as “User Stories.” Examples:

  • “As a pharmacist, I want to input a patient’s age, weight, and serum creatinine so that the system can calculate a CrCl.”
  • “As a pharmacist, I want the tool to recommend a loading dose based on actual body weight.”
  • “As a pharmacist, I want to simulate a vancomycin AUC based on a proposed maintenance dose.”
  • “As a pharmacist, I want the tool to pull in the latest SCr lab values automatically.”

You then prioritize this list, putting the most critical, highest-value features at the very top.

Sprint 1 (2 weeks):

  • Sprint Planning: The team pulls the top two stories from the backlog: “Calculate CrCl” and “Recommend a loading dose.” They believe they can complete this work in two weeks.
  • During the Sprint: You are available every day to answer the team’s questions. “Which CrCl formula should we use? Cockcroft-Gault or MDRD?” “What is the max loading dose we should cap it at?”
  • Sprint Review: At the end of the two weeks, the team demos what they built. It’s a simple screen where you can manually enter patient data, and it displays a calculated CrCl and a recommended loading dose. It is working software. You and other stakeholder pharmacists play with it. The feedback is immediate: “This is a great start! But we need it to default to the Cockcroft-Gault equation, with an option to switch to MDRD. Also, can we make the loading dose recommendation pop in a yellow box to draw attention to it?”

Sprint 2 (2 weeks):

  • Sprint Planning: The team creates new stories based on your feedback from the last review. They also pull the next highest priority item from the backlog: “Simulate a vancomycin AUC.”
  • During the Sprint: The developers work on the complex pharmacokinetic equations needed for the AUC simulation.
  • Sprint Review: The team demos the updated tool. It now has the CrCl formula toggle, the yellow box for the loading dose, and a new section where you can enter a maintenance regimen and see a projected 24-hour AUC. The feedback is again immediate: “The AUC calculation is fantastic! But it would be even better if it showed a graph of the concentration curve over time. Also, we need it to pull in lab values automatically; manual entry is too risky.”

This cycle continues, sprint after sprint. Each cycle delivers a more refined, more valuable piece of the final tool. You never wait months to see the product. You are steering its development in real-time, ensuring it meets the real-world needs of your pharmacy colleagues. The risk of building the wrong thing is virtually eliminated.

9.1.4 Deep Dive: The Hybrid Model

The reality of large, complex healthcare organizations is that neither “pure” Waterfall nor “pure” Agile is a perfect fit for every situation. A multi-year, $500 million EHR implementation cannot be managed like a small software startup with no fixed budget or timeline. Conversely, trying to define every single workflow and order set for an entire health system years in advance using a Waterfall approach is a proven recipe for failure. This has led to the rise of Hybrid Models, which seek to combine the best of both worlds.

The most common hybrid approach blends a Waterfall structure for high-level planning and governance with an Agile/Scrum framework for the actual execution of the work. It’s a strategy that provides predictability for leadership while giving adaptability to the frontline build teams.

Hybrid in Action: A New EHR Implementation

Let’s consider the massive undertaking of replacing a hospital’s legacy EHR with a new system like Epic or Cerner.

The Waterfall “Wrapper” (The Macro Plan)

The overall project is managed in large, sequential phases over several years:

  1. Phase 1 – Selection & Contracting (6-12 months): A formal, sequential process of evaluating vendors, signing contracts, and establishing the overall budget and timeline.
  2. Phase 2 – Foundational Build (12-18 months): A high-level design phase where major, irreversible decisions are made. What modules will be purchased? How will the servers be architected? What will the standard nomenclature for departments be? These are big-picture decisions made in a Waterfall-like manner.
  3. Phase 3 – Application Build-Out (18-24 months): This is where the model shifts. The project is broken down into clinical workstreams (Pharmacy, Inpatient, Oncology, etc.). Each of these workstreams will now operate using Agile/Scrum.
  4. Phase 4 – Integrated Testing & Training (6 months): A formal, Waterfall-like phase where all the pieces built by the Agile teams are brought together and tested end-to-end.
  5. Phase 5 – Go-Live & Support: The “big bang” deployment, followed by a maintenance phase.
The Agile “Engine” (The Micro Execution)

Inside Phase 3, your life as an informatics pharmacist on the Pharmacy workstream team looks very Agile:

  • Your team works in 3-week sprints.
  • As the Product Owner for medication order sets, you have a product backlog of hundreds of order sets that need to be built.
  • In Sprint Planning, you work with the team of analysts and builders to select the next 5-10 highest priority order sets (e.g., Sepsis, Community-Acquired Pneumonia, VTE Prophylaxis).
  • You have Daily Scrums to sync on progress and impediments.
  • At the end of each sprint, you hold a Sprint Review where you demo the completed, functional order sets to a group of stakeholder physicians and pharmacists. They provide immediate feedback (“Can you add a hard stop if the CrCl is less than 30?”), which you turn into new stories for your backlog.
The Pharmacist’s Role in a Hybrid Project: Code-Switching

To succeed in a hybrid environment, you must become adept at “code-switching” between the two mindsets. On Monday morning, you might be in a high-level project governance meeting, speaking the language of Waterfall—discussing timelines, milestones, and budget adherence with hospital leadership. On Monday afternoon, you’ll be in a Sprint Planning meeting with your build team, speaking the language of Agile—prioritizing user stories, estimating effort, and embracing change based on last week’s feedback. Mastering this ability to operate in both the world of long-term predictability and short-term adaptability is a hallmark of a seasoned informatics professional.

Masterclass Table: Comparing SDLC Model Characteristics

Characteristic Waterfall Agile (Scrum) Hybrid
Core Philosophy Predictability & Control Adaptability & Feedback Structured Adaptability
Requirements Defined once, upfront, and frozen. Evolve continuously throughout the project. High-level requirements are fixed; detailed requirements evolve.
Planning Detailed, long-term plan for the entire project. Detailed plan only for the current sprint. High-level, phased plan with detailed sprint-level planning.
Delivery One single delivery at the end of the project. Small, functional increments delivered every sprint. Working increments are produced in sprints, but major releases are tied to the high-level plan.
Pharmacist Involvement Heavy at the beginning (Requirements) and end (UAT), minimal in the middle. Constant, daily involvement as a Product Owner or key stakeholder. Varies; periodic involvement in high-level planning and daily involvement with the build team.
Handling Change Change is discouraged, difficult, and expensive. Requires formal change control process. Change is expected and welcomed. The backlog is constantly re-prioritized. Change is managed at two levels: difficult at the macro (project) level, easy at the micro (sprint) level.
Risk Management Risk of building the wrong product is very high, but budget/timeline risk is managed tightly. Risk of building the wrong product is very low, but scope/timeline risk is higher and requires active management. A balanced approach, attempting to mitigate both types of risk.
Best For… Small, simple projects with clear, unchanging requirements (e.g., a simple reporting tool). Complex projects with uncertain or evolving requirements where user feedback is critical (e.g., a new clinical decision support tool). Very large, enterprise-wide projects that require both high-level governance and frontline flexibility (e.g., EHR implementations).

9.1.5 Conclusion: From Participant to Strategic Partner

The Software Development Life Cycle is more than just a process; it’s the language of technological change within a healthcare organization. As a pharmacist, your clinical expertise is invaluable, but to translate that expertise into tangible improvements in the systems you use every day, you must become fluent in this language. Understanding the fundamental differences between Waterfall, Agile, and Hybrid models elevates you from a person who simply uses software to a person who strategically shapes it.

You are no longer just a requestor, submitting a ticket and hoping for the best. You are now a strategic partner. You can analyze a clinical problem and help leadership determine not only *what* needs to be built, but *how* it should be built. You can advocate for an Agile approach when you know a workflow is complex and will require iterative feedback from nurses. You can understand the constraints of a Waterfall project and focus your energy on making the upfront requirements as perfect as possible. You can navigate the complexities of a Hybrid EHR rollout, contributing effectively at both the macro and micro levels. This knowledge is your key to moving from the pharmacy bench to the digital architect’s table, ensuring that the next generation of healthcare technology is not only powerful but, most importantly, safe and effective for the patients you serve.