MODULE 2: LIFECYCLE TYPES AND THEIR RATIONALE

2.1 Systems Development Lifecycles (SDLC)

2.2 SDLC Models
2.2.1The Waterfall model.
2.2.2The V model.
2.2.3The Iterative model.
2.2.4The Spiral model.
2.2.5The Agile model.
2.2.5.1The Scrum methodology.
2.2.5.2The Extreme Programming methodology.
2.2.6The Rad Model.
2.2.7The Software Prototype model.
2.2.8The Big Bang model.

Unit Objective: The objective is to understand the range of systems development lifecycles, their application,
advantages and disadvantages.

SDLC is a process which defines the various stages involved in the development of software for delivering a high-
quality product. SDLC stages cover the complete life cycle of a software i.e. from inception to retirement of the product.

Adhering to the SDLC process leads to the development of the software in a systematic and disciplined manner.

An effective System Development Life Cycle (SDLC) should result in a high quality system that meets customer
expectations, reaches completion within time and cost evaluations, and works effectively and efficiently in the current
and planned Information Technology infrastructure.

System Development Life Cycle (SDLC) is a conceptual model which includes policies and procedures for developing
or altering systems throughout their life cycles.

How the SDLC Works

SDLC works by lowering the cost of software development while simultaneously improving quality and shortening
production time. SDLC achieves these apparently divergent goals by following a plan that removes the typical pitfalls
of software development projects. That plan starts by evaluating existing systems for deficiencies.

Next, it defines the requirements of the new system. It then creates the software through the stages of analysis,
planning, design, development, testing, and deployment. By anticipating costly mistakes like failing to ask the end-user
or client for feedback, SLDC can eliminate redundant rework and after-the-fact fixes.

It’s also important to know that there is a strong focus on the testing phase. As the SDLC is a repetitive methodology,
you have to ensure code quality at every cycle. Many organizations tend to spend few efforts on testing while a stronger
focus on testing can save them a lot of rework, time, and money. Be smart and write the right types of tests.

Next, let’s explore the different stages of the Software Development Life Cycle.
What Is the Software Development Life Cycle (SDLC)?

The term “Software Development Life Cycle” dates back to the 1950s.

At that time, there weren’t any other methods or frameworks available.

There was only one method described as the Software Development Life Cycle — “develop large-scale
functional business systems in an age of large-scale business conglomerates. Information systems activities
revolved around heavy data processing and number crunching routines.”

Today, the definition of the software development life cycle is the following:
Build high-quality software in the least possible time by following the 7 phases of the software
development life cycle.

Now, there are various SDLC methodologies, Waterfall being the oldest and most popular one dating back
to the 1960s. Each software development life cycle model differs from the others.

What Are The 7 Stages Of The Software Development Life Cycle?

Planning — in this phase, you are conducting thorough research on the product you are planning to develop.
You are then discussing your plans with clients and stakeholders.
You are also identifying the pros and cons of the current software methods you are using. Thus, you can
double down on the pros and reduce the cons to a minimum.

In order to make this research process as accurate as possible, you should take a look at your customer’s
feedback. Feedback should include surveys, interviews, questionnaires, quizzes, and more.

It’s super important to know what your customers want so that you can build it for them. In the end, you are
not going to make a profit if you don’t deliver the product your customers truly desire.

But be careful! Sometimes, even your customers don’t know what they really want. As the great Henry
Ford put it — “If I had asked people what they wanted, they would have said faster horses.” Therefore, try to
understand the real meaning behind the words of your customers.

Requirements Analysis — Once the research is completed you can proceed forward to creating
an SRS (Software Requirements Specification) document. In this document, you are going to describe all the
product’s features. Then you are going to present the SRS doc to the stakeholders so that they can either
accept it or reject it. It depends on the time and financial constraints.

Design — Once the SRS doc is completed, your team, specifically the product architects, will create another
document — the DDS (Design Document Specification).

In the DDS, you’ll have your features thoroughly described. Inside the document, you’ll also have the budget
and time estimates required for the product to be completed successfully. You’ll basically have everything
your developers need to start working on the actual product.
But prior to that, the DDS must be approved by the client and the stakeholders. Sometimes, changes are
required due to various reasons ranging from time and budget estimates to software robustness.

Implementation / Development — The implementation phase in SDLC typically takes the longest period of
time as it involves the actual development of the product.

Your developers will work on creating a product based on the DDS.

Also, depending on DDS’s robustness, developers will either code without much hassle or will have trouble
along the way.

They must also select the most appropriate coding language for the type of software you are building.

It’s vital to notice that the communication between your team at this phase must be effective and accurate.
That’s because your developers will need to communicate with the QA (quality assurance) testers, the
product, and project managers. This will help them in developing a product your customers will genuinely
enjoy.

Since DevOps is becoming popular lately, developers are starting to broaden their coding skills. This makes
them responsible for a large part of the entire software development life cycle process including the testing
stage.

Testing — Once the product is developed, the software development life cycle testing phase follows. Here,
the QA testers have to go through the codebase in order to find bugs and errors. If issues are reported, the
product is turned back to the developers for them to rectify the flaws and roll it out again. This phase repeats
until the product becomes flawless.

Deployment — Once all the errors are removed, the product is rolled out to the market automatically.

Maintenance and improvement — After deployment, you should observe how the market reacts to your
product. Then based on the feedback you receive, you create reports on what needs to be improved.

What Are The Advantages And Disadvantages Of The SDLC?

If the stages of the software development life cycle process are taken into serious consideration, chances
are you’ll end up with an outstanding product. Your developers will create software that your users will
happily talk about and recommend.

That’s because the programmers on your team will have comprehensive documentation to work with (DDS
and SRS docs). They’ll also have the feedback of the product managers and stakeholders. Everybody will
be on the same page. Thus, you’ll be able to develop a product that will outperform the competition in most
cases.

However, if the end-user feedback isn’t conducted properly, don’t expect to get a big bang for your buck.
So make sure that your research process is done properly. If you are able to understand what your users
really want, you can:
 Save time and money.
 Improve communication between your team members.
  Bring transparency into your projects and put everybody on the same page.
 Enhance development speed.
 Repeat the process over and over again with future projects.
 Also, minimize the risk potential during any given development project.
 And develop a high-quality product that your end-users truly love.
 However, “by failing to plan, you are planning to fail” — as Benjamin Franklin put it. And your failed
planning will result in:
 Bad product and unsatisfied customers. Your customers might talk bad about your software, and
thus no one will pay for it.
 Bad team communication. It can result in utterly disorganized team management.
 Overspending. If your product and features aren’t planned well, you’ll probably need to spend more
allocated budget on fixing the bugs and issues that occur.
 Missed deadlines. By spending more resources on fixing bugs and issues, you might also miss
your deadlines which can leave your clients unhappy.
 Yet, keep in mind that sometimes, having a lot of documents might leave your team perplexed as
well.

Many documents can make the SDLC process cumbersome and slow it down.

What Are The Different SDLC Models?

Honestly, there are a lot of software development life cycle methodologies out there. Based on the project’s
needs and preferences, some SDLC methodologies will be better suited for you than others.

Today, we are going to stress on the 10 most popular SDLC methods. And we will also help you to pick the
right one for your team. Here are they:

1. The Waterfall model.

2. The V model.
3. The Iterative model.
4. The Spiral model.
5. The Agile model.
6. The Scrum methodology.
7. The Extreme Programming methodology.
8. The Rad Model.
9. The Software Prototype model.
10. The Big Bang model.

1. Waterfall Model

Being the oldest and most popular one, the Waterfall model deserves the first place on our list. It dates back
to the 1960s, and people are still using it today.

The name “Waterfall” stems from the sequential order in which tasks are completed. The output of the first
assignment serves as the input for the second one (incremental approach). And this process is repeated until
the whole product is completely developed.
What’s cool about the SDLC Waterfall model is that it’s relatively simple to use. Backed up by a lot of planning
and documentation, the Waterfall model allows you to map out every step of the development process.

Team communication is also super effective as there aren’t many hurdles along the way.

The SDLC Waterfall model follows the same 7 software development life cycle phases — planning,
requirements, design, implementation, testing, deployment, and maintenance.

With the Waterfall method, there is typically a lot of planning involved as you need to come up with an exact
image of the end product.

Developing an SRS and DDS document is pretty much the same. You design all the features that need to be
developed, then thoroughly describe them, and present the docs to the stakeholders to get approved.

The implementation phase takes from 3 to 12 months, sometimes even more.

This is actually considered as a downside because the end-user isn’t able to see a working product until the
late stages of development.

Think of Windows. They release a new version every couple of years. This means that they are using the
Waterfall model. After the product is developed, it must be tested. If bugs occur, they should be removed.
And then you are ready for the deployment.

Once you deploy, you should observe how the market reacts to your product. Then make adjustments in
order to improve the software and leave your end-users happy. Thus, you’ll get the word about your product
spread easily.

The Waterfall model — Pros

 The software development life cycle documentation is really on point here. Thorough planning will
definitely set up your development team for success.
 Easy to understand and use. Every step of the way is mapped out for your team members to
comprehend and follow them. You can put novices on board and have them quickly grasp the idea
behind the project and start producing quality code.
 The Waterfall method is also quite easy to manage. You don’t have any external resources involved.
You can clearly see what’s on the table and come up with the next essential step you need to take
in order to move the project towards the goal line. The time your team spends on trivial tasks is
minimized as there is a rigid prioritization of your tasks.
 Deadlines can be met easily. That’s because you are provided with specific instructions so that you
don’t spend time figuring out everything yourself.
 It’s best suited for bigger teams and projects as there is heavy documentation involved. And you
probably don’t want to waste your time conducting thorough research on a product that will take you
a month to develop.

All in all, with Waterfall, everything’s made to be simple and straightforward.

The Waterfall Model — Cons
 The bad thing with the Waterfall methodology is that changes can be extremely costly or even
impossible to make. That’s because each step must be completed sequentially. Therefore, if you’ve
missed to note down a feature in your backlog, you’ll have a hard and expensive time of reverting
the whole process.
 Also, it takes a while for working software to appear. Your client will not be able to see the bang for
his buck immediately. In most cases, it takes from eight to nine months to produce working software.
 It’s also quite risky. If you have a precise budget and your team happens to develop a software that
isn’t what the users want, then you are, merely said, screwed. To avoid being screwed, you’ll have
to stress on making thorough customer research. That will help you to find out what your users desire.
With Waterfall, you either plan well or create a great product, or you don’t plan well and create a
product nobody wants.
 Sometimes, even the customers don’t know what they want, which can lead you to create a product
that nobody desires. You’ll have to dive deep when doing your user’s research and try to understand
the real meaning behind the words of your end-users.
 It’s not suitable for smaller teams and projects as you’ll waste too much time on researching for a
project that might take you less than a month.
 It’s also quite difficult to measure the progress your team is making as there is no working software
delivered until late in the development cycle.

When To Use The Waterfall Model — Examples

We’ve already mentioned Windows and how they use the Waterfall model. This methodology is based on
long-term projects that can take you over a year, just like Windows 7, 8, 10, etc.

2. V – Model

The SDLC V method is basically an improved version of the Waterfall model. You’re working at one phase
at a time. And only when you finish a task, you can move on to the next one.

The name stems from the parallel V structure this model follows.

Software development life cycle testing is included in every stage — and that’s actually the main difference
between this method and the Waterfall model.

The V methodology consists of 9 different SDLC phases — Requirement analysis, System design,
Architecture design, Module design, Coding, Unit testing, Integration testing, System testing, and Acceptance
testing.

It’s worth mentioning that there are two parts of the equation here — Verification (planning & building) and
Validation (testing & improving).

The stages from the Requirement analysis to the Module design are located in the Verification stage.
Whereas the stages from the Unit testing to the Acceptance testing are put in the Validation phase.

Only the Coding phase is neutral — it’s involved in both.

Verification Stages

1. The Requirement analysis phase — this is actually the most important one. It’s where the
communication between you and your end-users happens. It’s the time and place where you are
trying to find out what the user really wants and how to give it to them.
2. The System design phase — You then create the requirements documentation alongside all the
product expectations — budget, deadlines, features, robustness, etc. Once you have every feature
and requirement mapped out, you can then create the entire system design of your product. It
includes every tiny detail about the hardware and communication setup of your product. The System
design basically gives you an overall picture of how your product will look like and what’s it going to
do.
3. The Architecture design phase — Here, you are mapping out the technical approaches your team
is going to take to build the product. Typically, there are a couple of technical methods. They are
mostly based on financial feasibility. If everything makes sense, you are then breaking down the
project into smaller tasks your team needs to follow.
4. The Module design phase — This is the stage where you should ensure internally that the design
of the product is compatible with other modules as well as different external sources.

The Coding Phase

This is where the magic happens. Your developers must keep regular communication between the product
managers and the stakeholders. It will help them to develop an outstanding product. The perfect coding
language is selected by the developers based on the type of product you are building. The developers are
constantly reviewing the code and making sure that everything is brought down to a science.

Validation Stages
1. The Unit Testing phase — in this stage, the code is being tested and optimized. All the bugs and
errors that occur along the way are removed. The developers are working hard to ensure that they
deliver a flawless code.
2. The Integration testing phase — We are testing the communication of the internal modules within
the system to make sure that everything is well synchronized.
3. The System testing phase — Here, we are testing the communication of the external systems. This
is actually the place where some hardware and software issues might be discovered and therefore
fixed.
4. The Acceptance design phase — Here, you’ve already rolled out the product to the market and
observed how it reacts to it. Based on the user feedback you receive, you decide whether to make
further improvements or leave it that way.
The V Model — Pros
 You have a lot of planning involved which makes grasping the whole process much easier.
 You can meet all of your deadlines quite easily as there are specific instructions mapped out for your
team. Thus, you can clearly see what’s ahead of you and form precise time and budget estimates.
 The whole process is quite easy to manage as there aren’t many hurdles along the way. You are
following a step-by-step process. You have to finish each task entirely before moving on to the next
one. This keeps you focused at one assignment at a time.
 It’s suitable for bigger teams and projects as you’ll have a clear image of how the end product will
look like.

The V Model — Cons

 Like the Waterfall model, you can’t make changes once a task is finished. This makes it a high-risk
model. When planning to use the V method, you have to make sure you have a thorough
understanding of the product. And you need every step of the development phase mapped out
precisely. All of that ensures that risks are reduced.
 Changing is either impossible or very costly. If you happen to miss something important during your
planning process, you’ll have a hard time coping with the change.
 Also, a lot of software development life cycle documentation can be overwhelming.
  Not suitable for smaller projects as it will take you an enormous amount of time to plan the process
and do the research.
 Your end-users or clients aren’t able to see an actual product until the late stages of development,
which typically take 8–9 months.

When To Use The V Model — Examples

The V model is very similar to the Waterfall method. Therefore, the V model is also suitable for larger projects
where a lot of planning is involved.

Typically, large projects require a specific picture of the end product and every step of the way must be
mapped out precisely. Your developers will be able to work without experiencing a lot of hurdles.

It’s easily graspable by novices in the beginning. However, the inexperienced developers will need to gain a
deep understanding of how the development process goes in your company in order to work effectively using
the V model.

All in all, if you’d like to get some more testing along the way, then we’d recommend picking the V model over
the Waterfall method.

3. The Iterative Model

Compared to the traditional software development life cycle models — Waterfall and V model — the Iterative
approach is a bit different.

There isn’t typically a lot of planning involved in the initial stages of building the product. With the Iterative
approach, you break down the entire project into smaller chunks — product builds, known as iterations.

Each iteration goes through the typical stages of the software development life cycle — planning, design,
implement, test, and deploy. And each cycle builds on the others.

The cool thing here is that once the product build is completed, you can deploy it immediately. Therefore,
your customers can see working software right off the bat. This keeps them highly engaged throughout the
entire development process.

Also, with the Iterative framework, you can work on a couple of iterations at once. However, you have to keep
your team organized as this might confuse them and cause you to slow down.

The Iterative method also allows you to make slight changes along the way. Allowing you to adjust the
software to fit the market’s needs.

But keep in mind that the Iterative Model isn’t made to embrace change completely. Though the cost of
making adjustments is lower compared to the Waterfall model, it still follows a rigid structure whereby your
end product is developed.
So, you’ll have to be careful with the changing environment. Gather enough data to get your team well started
on the coding phase. But don’t rush it because you might find it very difficult to adapt to bigger changes.

The Iterative Model — Pros

 You can make slight changes to the software. Your project can evolve along the way in order to
satisfy the customers’ wants.
 There’s not as thorough planning involved in the initial stages as it is in the Waterfall method.
However, either way, you should still do some planning to get yourself familiar with the requirements
of the product. Otherwise, you won’t be able to understand clearly what you are developing.
 Working software is released as soon as possible. Thus, the client and the end-user can see the
value of your software immediately. This keeps them engaged along the way.
 Also, by deploying constantly working software, you can measure the progress you are making.
Keeping your team motivated towards reaching the goal line.
 You can work on a couple of iterations simultaneously. But you have to be careful. Sometimes, it is
a double-edged sword. It might leave your team highly perplexed and slow down the coding phase.
 It’s better suited for bigger teams and projects.

The Iterative Model — Cons

 Even though the Iterative approach allows you to evolve your software, it’s not very suitable for
change as there is a lot of management involved in the process.
 You don’t have a clear image of how the end product should look like as there’s a lack of serious
documentation. In the end, you might develop quite a different project than what was planned initially.
  Typically, software engineers are required to be highly skilled to adopt new technologies.
Commitment also is vital. The team must be entirely focused on building the product in order to stay
current with the market.
 There might be architecture bugs and design issues along the way due to the lack of specific
requirements.

When To Use The Iterative Model — Examples

You can use this method if you believe your team is skilled enough to adapt to new technologies. Keep in
mind that the Iterative model is also a bit rigid and follows some strict guidelines. Therefore, you might not
be able to resist a strong changing environment. All in all, it’s better suited for bigger teams and projects.

4. Spiral Model

The Spiral approach is a combination of the Iterative model with some controlled aspects of the Waterfall
method. It focuses on releasing software constantly through iterations.

The name stems from the spirals that the product typically goes through.

What’s cool about the Spiral model is that, similar to the Iterative method, it enables you to test every step of
the process. Thus, you can ensure that you are coming up with flawless product builds.

The four software development life cycle phases of the Spiral model are as follows: Identification, Design,
Build, Evaluation.

Identification
This is the stage where planning and creating the documents actually happens. Here, you’ll survey your end-
users and collect feedback.

You are also listing the requirements of the software you are about to build — deadlines, budget estimates,
features. The more detailed the software development life cycle documentation is, the easier it will be for
your developers to build the product.

Design
Similar to the V model, this stage involves the building of the system design, the architecture design, as well
as the module design.

You are basically analyzing the whole development process in order to identify potential risks. When the risks
are identified, you can start brainstorming risk-mitigation strategies.

Build
This is the phase where the software is being developed.

At the end of this phase, the developers already have an “a-ready-to-deploy” piece of software. Once you roll
it out, you can then collect feedback from the market and evolve.
Evaluation
In this stage, monitoring and observing prevail.

Here, you’ll have to assess how the whole spiral went. You can also see how the market reacts to your first
functional part of the software.

You’re basically collecting feedback on what you did right and wrong. Then, in the next spiral, you double
down on what was right and try to avoid what you did wrong.

The whole product build goes through a couple of spirals until the final product is developed. And hopefully,
throughout the spiral builds, you were able to adapt to the market’s needs to build a product that your users
actually want.

The Spiral Model — Pros

 The main benefit of the Spiral model is that you can add extra features and elements along the way
as opposed to the Waterfall model.
 Though it’s part of the Waterfall model, it allows slight changes to the product.
 It also allows you to receive feedback through the deployment that happens after each spiral. You
are continuously improving your software.
 Moreover, working software can be deployed early in the software development life cycle stages.
Your customers can see that you are actually providing value.
  Also, development can be broken down into smaller chunks. You can then prioritize tasks and your
team will work on building the features your market wants to see first.

The Spiral Model — Cons

 There is strict management involved in the Spiral approach to ensure that the spirals don’t go on
indefinitely. If your management is terrible, the development process can be slowed down
significantly.
 The whole method can be quite complex as there are multiple spirals that the product build needs to
go through.
 It’s not suitable for smaller projects as it can be expensive due to the constant testing and
deployment.
 You lack a clear image of the end product. Therefore, you might come up with a different project than
what was initially planned.

When To Use The Spiral Model — Examples

Well, if there are some risky budget estimations involved in the project, you can rest assured that the Spiral
model will bring the overspending to a minimum. That’s because there is a constant evaluation of the product.

If there isn’t thorough documentation created initially, it might be a good option to stick with the Spiral
approach as it allows the product to evolve along the way.

If you’d like to show your customers the immediate value of the product you are building, you can go with the
Spiral Model. It enables you to deploy after every spiral and see how the market reacts to the working
software.

The Spiral approach is also fantastic for teams looking for constant user feedback. After each deployment,
you can collect customer feedback and make adjustments.

If you are expecting new technology adoption, then the Spiral model is a good fit for you too. However, it
can’t resist a strong changing environment which may cause the spirals to go on indefinitely.

5. Agile

The SDLC Agile model is actually one of the most popular SDLC methods today. It was originally developed
by 17 software engineers in Utah back in 2001.

The Agile principle is more of a philosophy. It consists of 12 major components known as the Agile manifesto:

1. Customer satisfaction is the most important.

2. Change is embraced as it is inevitable.
3. Delivering working software frequently enough to satisfy the customer.
4. Daily cooperation between the team is essential.
5. A motivated team is the best as it can handle all the challenges it faces.
6. Face-to-face communication is highly encouraged.
 7. You can measure your progress by delivering working software.
8. The workflow and the pace your team is moving with should be maintained constant.
9. There should be attention to technical details.
10. It’s not just about doing more work. It’s about doing more in the shortest amount of time.
11. Teams that can manage themselves are the best.
12. Your team should regularly receive feedback and adapt to the changing environment.

We can say that the SDLC Agile model is the complete opposite of the Waterfall model. The Waterfall model
isn’t releasing any software until the late stages of development. Whereas the Agile process focuses on
releasing working software continuously.

With the Waterfall approach, you have to do in-depth research. Whereas with the SDLC Agile model, you’re
not bound to do any of that — you can hop right into the battlefield and adapt as you move along the way.

With Agile, big projects are broken down into smaller chunks — iterations. Each iteration goes through the
typical phases of the Agile SDLC process — plan, design, implement, test, deploy, and maintain.

Also, every iteration takes somewhere between two and four weeks to be finished. After that, it is deployed
to the market. And you collect feedback.

The communication between you and your customers is super vital here. You need to know precisely what
the end-users are telling you and adjust the product accordingly.

There are a lot of methodologies that fall under the software development life cycle Agile model. Here are
some — XP (Extreme programming), Scrum, Kanban, Lean, Crystal Clear, Feature-driven development
(FDD), Adaptive System Development, Rational Unified Process (RUP), Agile Modeling, and more.

The Agile Model — Pros

 The main thing about the Agile development model is that you are constantly releasing working
software and getting feedback from the market. Thus, you can adjust your product to fit the market’s
needs.
 Moreover, you don’t have to do any laborious documentation. That’s because the philosophy
embraces change and even encourages it.
 It’s suitable for smaller projects as you can hop right into the battlefield. With Waterfall, you would
spend a lot of time on doing your thorough research.
 Through face-to-face interaction and daily communication, you can bring everybody on the same
page. Your team will be able to move with twice the speed it used to.

The Agile Model — Cons

 The thing with the Agile development model is that you don’t have a clear picture of the end product.
Therefore, the product you develop in the end can be a whole lot different from what was initially
planned.
 Also, because there’s constant change, the team must be highly experienced to evolve along with
your software. Your team members need to be able to adopt new technologies in order to develop a
great product.
  Your team must be 100% committed to getting the project completed. Your teammates shouldn’t
focus on side tasks as every distraction can be detrimental to the project.
 Determining a solid end date can be quite difficult as you lack thorough documentation.

When To Use The Agile Model — Examples

It’s typically more suitable for smaller projects as you don’t have to do a lot of planning. And you are also
able to adapt to the changing environment. However, it’s not preferred for long-term projects where you have
to know every tiny detail. For bigger projects, you need to have a precise picture of what you are trying to
develop. And with the Agile model, that’s highly unlikely to happen.

But all in all, if you are keen on flexibility and would like to see how the market reacts to the product you are
trying to develop, go with the Agile model.

6. Scrum Methodology

The software development life cycle Scrum method is actually a subset of the Agile model. This means that
Scrum also adheres to the 12 principles of the Agile methodology.

The Scrum framework operates in timeboxes called sprints. Each sprint lasts between two and four weeks.
At that time, the team is working on delivering working software. Once the software is finished, it is deployed
to the market, and feedback is collected.

Usually, there are three leading roles in the Scrum methodology. There is a Product Owner, a Scrum Master,
and a Scrum team.

The Product Owner communicates with the stakeholders and the customers to come up with a great product.
Then, the Product Owner creates the product backlog. That’s the place where all the features that need to
be developed are listed.

The Scrum Master then takes a look at the product backlog and creates the scrum backlog. In the scrum
backlog, each feature is broken down into smaller tasks that need to be completed throughout the sprint.
Those tasks are called user stories.

User stories typically show you how the product looks through the eyes of the customer. And what steps the
customer needs to take in order to complete a particular task.

It’s important to note that the Scrum Master isn’t a manager. Every member of the Scrum team is responsible
for its tasks and needs to make sure that he is meeting the product requirements.

The Scrum team is cross-functional. Because everyone is responsible for its own assignments, each
member of the team should be highly experienced. Team commitment is also absolutely essential as there
will be changes along the way.
The Scrum team also does daily Scrum meetings. It’s the time and place where everybody shares what they
did yesterday, what they are going to do today, and if they are facing any challenges. Thus, if someone is
falling behind, the others can bring him back on track.

Each scrum meeting lasts between 5–15 minutes.

Once the sprint is over, there is a Scrum Review meeting where the work completed so far is discussed. The
Scrum team then looks back at the development process and improves it based on what went right and what
went wrong.

The Scrum team also uses burndown charts to track progress.

The Scrum Methodology — Pros

 What’s cool about the Scrum method is that it can adapt to change and adhere to a strict process as
well. Throughout the sprint, it’s not advisable to make changes to the backlog. However, when the
sprint ends, the team can fix stuff that went wrong and add more assignments to the scrum backlog.
 Also, accountability is at a very high level. That’s because there is no manager to manage the team.
Everybody is responsible for what they are doing and highly experienced as well. If you get such a
team, you won’t have problems with delivering great software on time.
 The daily scrum meetings are also great for your team to stay on the same page.

The Scrum Methodology — Cons

 Because Scrum is a part of Agile, you don’t have a clear image of the end product. The end result
might be a whole lot different from what was planned initially.
 Also, there must be a very high team commitment. Due to the changing environment, your team must
be able to react swiftly and adopt new technologies if needed.
 You don’t have a specific time and cost estimates.

When to Use The Scrum Methodology — Examples

This one is perfectly utilized within a smaller team of 10 people or less. That’s because there is a constant
team communication and everybody needs to be on the same page.

Also, there is a continuous interaction between the product and the market. Thus, you can make the
necessary changes to your software to meet the market’s needs. For that to happen, you’ll need a highly
experienced team of mid-sized and senior developers. All in all, Scrum is the most popular Agile methodology
out there.

7. The XP (Extreme Programming) Methodology

The XP methodology is also a subset of Agile.

It consists of 5 major components:

 1. Simplicity
2. Team communication
3. Customer feedback
4. Courage
5. Respect

Simplicity
Everything should be done in the simplest way possible. There shouldn’t be any more tasks and features
than needed.

The XP method encourages the MVP (minimum viable product) framework. It strives to develop a “just-
enough” product that serves the market needs well.

Team Communication
The Extreme Programming framework aims for daily face-to-face communication to bring everybody on the
same page.

Effective team communication is especially crucial in the beginning stages of developing a product as there
is a lack of documentation. And yes, with the XP model you don’t need to do a lot of planning initially to get
your team started. But you need to do a lot of team communication. In XP, the developers are usually the
guys that also do the testing part.

Customer Feedback
You are also releasing working software continuously in order to see how the market reacts to it. After release,
you collect feedback, assess the situation, and make the required changes to satisfy the customer.

Courage
Yes, courage. You and your team need to be courageous. This means that you should have the courage to
accept changes when they occur. You should have the courage to adopt new technologies when necessary.
And you should have the courage to take feedback constructively to build an outstanding software solution
to your market’s problems.

Respect
Your team members should respect each other. They should help each other. Because what makes a
successful product most of the time is a strongly bonded team. You have to ensure that the atmosphere
within your team is amazing. You need to make sure that everybody can’t wait to get back to work after the
weekend (that might be a bit of an exaggeration).

All in all, XP is a typical Agile methodology. You have to embrace the changing environment and adjust your
product to fit the market.

You stress on team communication and gathering customer feedback constructively to ensure you are
developing a real solution to the market’s problems.

The XP Methodology — Pros

  You are delivering working software constantly. Thus, the customer can see the bang for his buck
almost immediately. And what’s cooler is that the customer is involved throughout the whole
development journey. You can collect feedback and suggestions from him to come up with a better
product.
 Change is embraced. You can adjust things along the way if something goes wrong.
 It focuses on reducing the cost of the entire project as opposed to Waterfall, where the cost of making
changes is enormously high.
 Team communication is one of the major principles the XP model consists of. Extreme Programming
strives for great team communication through face-to-face interactions and daily meetings.

The XP Methodology — Cons

 Similar to any Agile method, it requires the team to be highly experienced and committed to making
the project successful.
 You are missing a precise picture of the end product. You might end up with something completely
different than what was planned initially.
 Your team needs to attend frequent daily meetings in order to bring everybody on the same page as
there is a lack of documentation.

When To Use The XP Methodology — Examples

It’s good for you to use the XP methodology when your team is highly experienced and is made of 10 people
or less. Also, if your client doesn’t provide you with specific requirements, the XP method will be a good pick
for you. If the technology you are currently using allows you to make automated unit and functional tests, the
XP model will straighten up the work process.

And finally, if you think that there is high risk involved due to inappropriate time estimates, you can still go
with the XP model as it will reduce the risk.

8. RAD Model

Rapid Application Development model, is very similar to the Iterative approach.

The RAD methodology consists of iterations, known as prototypes. Each prototype is a functioning part of
the overall software. What’s cool about the RAD process is that it allows you to deploy each prototype
separately. Thus you can collect valuable feedback from the market throughout development.

Moreover, every prototype is developed in a way that makes it reusable for future projects. This saves time
and money. Also, with the RAD model, you aren’t required to create laborious documents to get your team
started. The RAD framework embraces change and enables you to adapt to the changing environment.

It consists of five SDLC phases, and each prototype goes through these phases separately.

The first one is the business modeling. It’s the phase where a thorough business analysis takes place to
determine the functions of your product.

The second stage is data modeling. Here, all the data that has been gathered in the previous stage is
thoroughly analyzed. Further specifications are developed in order to make the development process clearer.
The third phase is the process modeling. In this stage, the information defined in the data modeling phase
is broken down further. More product requirements are listed. Thus, the team is able to come up with the
exact product objectives that need to be completed. Also, enhancements and improvements can be made in
this stage.

The fourth one — coding phase. Here, actual development happens. The team makes an overall
assessment of the development process and picks the programming language that is going to be used.

And finally, you have the testing phase. Once the prototype goes through this one and all the flaws removed,
it is deployed. After that, you collect valuable feedback for you to use in the next prototype.

The RAD Model — Pros

 The main thing about the RAD model is that it stresses on developing reusable prototypes. This is
an actual time and money saver when planning your future projects.
 It also focuses on delivering working prototypes to the market. Thus, the customer sees the bang for
his buck regularly and stays involved in the development process.
 You are collecting feedback from the market with your constant prototype releases.
 You can measure the progress easily by delivering working prototypes continuously.
 It works great when the team is smaller — around eight people.

The RAD Model — Cons

 It requires your team members to be highly skilled and committed to the product you are trying to
develop. That’s because the RAD method encourages constant iterations. And your team must be
able to evolve along with the changing environment and adopt new technologies.
 If the software can’t be broken down into smaller chunks — prototypes, you’ll have a hard time
utilizing this SDLC methodology.
 There’s some management involved which may make the work process more difficult.
 It also requires the client to be constantly involved in the development stage. If there is commitment
lacking on either side, then you probably won’t build a great product.

The RAD Model — Examples

The RAD method is perfect for projects where you can break down the product into prototypes. And then
reuse these prototypes for future software releases. The RAD model also encourages changes and iterations.
Therefore, if you expect your team to adopt new technologies, go with the RAD method.

Otherwise, you don’t want to pick the RAD method for projects where you need well-defined requirements
as there is a lack of documentation.

9. The Software Prototype Model

The Software Prototype method also consists of developing working prototypes (obviously). However, the
difference here is that the Software Prototype framework only develops “just-enough” prototypes. Which
means that the prototypes may have limited features. Yet, with this approach, you can deliver working
prototypes quite rapidly and collect the user feedback swiftly.

If team management is poor, chances are you may build prototypes that are very, very different from the
initially planned software. Also, the wrong management can cause your prototypes to become unusable for
future projects.

So, keep in mind that this is a very delicate model. It can be of enormous help as it builds “just-enough”
prototypes promptly. But it can also be detrimental to your project as it can waste you a lot of time and money
if you don’t manage your team properly.

A couple of types of software prototyping are available:

The first one is rapid prototyping. This one is used to develop a functional part of the end product very
quickly and sparsely. This type of prototyping contains only the main functions and features that the customer
desires.

The second type of prototyping is evolutionary. It is based on heavy user feedback. You jump right into the
battlefield with a quickly developed prototype and adjust it along the way.

The third one is called extreme prototyping. This one is mainly focused on developing web applications. It
consists of three major components. The first one is known as the static prototype. It builds a basic prototype
along with all the required HTML pages. In the second stage, a lot of programming happens in a chosen web
framework using a simulated services layer. The third and last phase is where the prototype is being
deployed.

And finally, you have the incremental prototyping. This stage encourages you to build multiple functional
prototypes and then integrate them into the final product.

There are a few major steps to designing a software prototype, no matter the type. Here are they:

1. Basic Requirement Identification. This is the phase where you collect data about the product you
are building. Try to stress on gathering more data about the user interface. It’s the primary component
that will determine whether your software prototype is going to be successful or not.
2. Building. This is where the actual development happens, and it happens swiftly. We have to note
that the prototype can be a bit different from the original software as it’ll probably have a lot of
limitations.
3. Review. In this phase, you’re presenting the initial software prototype to the stakeholders and the
customers. You are then discussing if enhancements need to be made and if they are technically
and financially feasible.
4. Enhancing. Here, the developers improve the software based on the stakeholders’ feedback. Then
the prototype is presented to the stakeholders again. This process repeats itself until everybody
agrees on the working software prototype.
A software prototype can be developed in two ways. The first way demonstrates a broader view of the end
product. It stresses on the user interface without going deeper into the internal systems.
The second way in which you can develop a prototype is by focusing on a specific function or system. This
way is more technical as it shows what a particular function can do and how exactly it does it.

The Software Prototyping Model — Pros

 A working software prototype is developed swiftly. Your users can get an excellent understanding of
your end product in the initial software development life cycle stages.
 Due to the continuous deployment, you can gather valuable feedback and adjust the development
process.
 It can reduce expenses as flaws can be detected much earlier compared to traditional software
development life cycle methods.
 If there’s a function in your software that your users don’t like, you can identify it quickly and remove
it from the development process.

The Software Prototyping Model — Cons

 This method can be quite hard to manage. It might leave your team a bit confused at some point in
the development process.
 Some of the existing prototypes might not be eligible to be used again due to bad management.
 The developers in your team have to be highly skilled to be able to work using the Software
Prototyping method. That’s because they might end up putting a lot of effort into developing a
software prototype that doesn’t seem to work right.

When To Use The Software Prototyping Model — Examples

The Software Prototyping model is highly preferred in products where the user interface is one of the main
components to keep your customers happy. However, if there’s terrible management within your team, you
might want to skip the Software Prototyping method. That’s because your team will put a lot of effort into
developing a prototype that probably won’t work properly.

10. The Big Bang Model

So, if you have a very small project under your radar and you want to hop right into it without making almost
any planning initially, the Big Bang method is the right pick for you. Of course, this type of development isn’t
suitable for large projects where you need to have specific requirements to start developing.

The Big Bang method is great for small teams of 5 people working on small projects lasting no more than a
month. It’s also a good model to use when the client isn’t detailed about the instructions and doesn’t know
how the end product should look like.

The Big Bang Model — Pros

 It is perhaps the simplest method of all the listed above.

 It requires close to zero planning as it encourages the “just-do-it” philosophy.
 It’s also highly flexible. It allows developers to adapt to the changing environment.
 It’s a good model if you have new developers in your team trying to adapt to the working environment.
The Big Bang Model — Cons
  It’s a high-risk method of approaching your software. The product you develop in the end can turn
out to be completely different from what was planned initially. That’s because there is a lack of
requirements.
 It’s not a good method for complex and big projects.

When To Use The Big Bang Model — Examples

You should stick with this method when working on smaller projects where requirements from your client are
scarce. It’s also good to use this method with your novice developers as it is simple to adopt.

If you don’t have a clear picture of the end product, then you can also go with this model. The Big Bang
method isn’t a good option for long-term and complex projects where a lot of initial planning is required.

Which SDLC Model Is The Right For You?

The “great” answer to this question is… it depends. It depends on the size of your team, on the size of the
project, on the complexity of the project, on the experience of your developers, on the tools you are using,
and more importantly, it depends on your preference.

If you believe that you have a skilled team of developers, and you’d like to save time by avoiding
documentation as much as possible, then one of the Agile models can be good for you. They are flexible and
allow you to adapt to the changing environment. But they are not easy to get used to.

On the other hand, if you’d like to have everything straight and know every step of the way, then the Waterfall
or the V model can be a good fit for you. If you have novice developers on the team, they can adapt easily to
the Waterfall model. But keep in mind that changes with the Waterfall model are either very costly or
impossible to make.

In the end, I’d recommend you to just pick the one your gut is telling you to choose. You’ll have to try most of
these to see which one suits you the best. You’ll rarely pick the right model from the first time. So take it with
a salt of grain, and just pick the one that you think it’ll fit your team well right now.

ACTIVITY

1. Internet research. Look for (1) company/institution that uses one of the abovementioned SDLC
Models and prepare a concise report.
2. Is system development a creation or manufacturing process?
3. Should a development organization adopt a single model for all its system development? Discuss
the pros and cons.