Lecture Date: Thursday, September 2
One of the main differences in “writing code” and “engineering software” is following a specified process. By process, we mean a series of steps or phases that a team goes through every time to ensure that they are building the software correctly.
Broadly, we are looking at:
Yes… the phases of development again. But the question you have to ask when looking at these phases is “how much time/effort do I put into each phase?” Depending on your answer to that question, it will lead your team to choose potentially substantially different methods for building the software.
Can you constantly communicate with your customer and make changes while building? Or do you have to get all of your requirements exactly right before moving on? One of these would be considered more “agile,” while the other is “plan-driven.”
It’s important to know that “agile” doesn’t equate with “good,” nor “plan-driven” with “bad.” Different types of software projects and teams need to use a variety of methods to work effectively together. So, how do you choose?
Plan Driven Methodologies
A hallmark of whether to use a more plan-driven methodology versus an agile methodology is the potential for requirements change. If you have a project in which the requirements are set in stone up front and should not change, then you are probably going to be using plan-driven methods.
Why is this the case? Well, if you know (or have to know) all the requirements up front then the project:
- Could have a large base of customers / stakeholders, where you cannot engage them one-on-one like you would with agile
- May have higher reliability or security constraints
- Could involve hardware in which the interface is already known
- Might have to go through an approval process (FDA, FAA, etc.)
So, if the requirements are known, there are other aspects of project that are likely to be true - all of which point to plan-driven.
Software Process and Methodologies