1

• A SDLC – Software Development Lifecycle

• It’s a set of tools, artifacts, and work practices an organization uses to create

software.

• That SDLC is integrated into a workflow process within the organization to get

the requirements gathered, the software built, the testing done, the bugs

fixed.

• As an example – I’m going to talk about scrum

2

What is scrum:

• 3 roles

• 3 rituals

• 3 artifacts

3

• It matters, because companies spend billions of dollars on software each year.

The Standish Group (1995) reported that companies spent over $250 billion

on application development of approximately 175 thousand projects.

Certainly this has expanded greatly in the almost 20 years since.

• We get a better end product, a better development outcome, and a

standardized process where scope expectations are clear, deliverables are

clear, and team roles are clear.

• Organizations that have an intentional software development process have a

much better chance of producing software with quality, that meets customers

needs, on a repeating basis.

• Coordination of large teams - We can facilitate large teams working on a

project together, but we can only do that if it’s done in an organized and

efficient manner.

4

• Was the SDLC used by organizations for project creation the same as for

project maintenance?

• Were the strengths of the SDLC used for project creation consistent with the

needs of the team for software maintenance?

5

6

• As I mentioned before, billions, maybe trillions of dollars are spent on

software development yearly.

• Selecting the “right” methodology can have a significant impact on project

cost and quality

• Picking any methodology reduces cost, risk, uncertainty, disorganization, poor

requirements and poor quality

7

• There are some companies that have no methodology. So they probably can’t

build repeatable software on larger scale.

• SDLCS support certifications like ISO9001, CMM

• Contracts with some governments or other institutions

8

• Alister Cockburn in his paper “Selecting a Project’s Methodology talked about

reducing the controversy over methodologies, by breaking it down to the

“dimensions along which they vary”. He starts out with Staff size and system

criticality.

• “A larger group needs a larger methodology”

• A larger project needs more rigor

• And more formal methods

• More defined roles for team members

9

• A more critical system… needs more publicly visible correctness” – the idea of

transparency into the project

• His definition of criticality was pretty clear-cut.

• Loss of comfort

• Loss of discretionary money

• Loss of irreplaceable money

• Loss of Life

• From this principal – the team can justify greater development

expenses as the criticality increases.

• “A relatively small increase in methodology size or density adds a relatively

large amount of project cost”

• For example adding daily standups to improve communication and

reduce uncertainty costs 15minutes per day per employee in the

project. (3% of the work day)

• More planning meetings to mitigate the risk of complexity /

uncertainty also cost more time..

• My favorite quote “All methodology is based on fears” (Kent Beck)

• Afraid designers will leave – write extensive design doc

• Afraid programmers will make mistakes – hold code reviews

10

• Todd Little in 2005 wrote a paper titled “Context-Adaptive Agility: Managing

Complexity and Uncertainty. Using this matrix they categorized projects.

• Dogs – simple projects, low uncertainty

• Colts – simple projects, high uncertainty

• Cows – complex projects, low uncertainty

• Bulls – complex projects, high uncertainty

• Using this matrix they developed a core set of work practices that were used

on every project. Then depending on complexity or uncertainty they added

other practices.

11

Here you can see the drivers of a projects complexity

12

And here you can see the drivers of project uncertainty

13

• In little’s core practices he had

• Aggregate Product Plan – target date, high level prioritized set features,

product vision

• Feature List (must have, should have, could have)

• Quality agreement – set the expectation

• Continuous integration

• Expert user involvement

• Project dashboard

14

• To the core work practices they added:

• Colts

• Add short iterations

• Daily stand-up meetings

• Automated unit tests

• Cows

• Requirements management

• Functional specifications of interfaces

• Critical-Path identification

• Bulls

• Colts + Cows

• Seasoned Project manager

• Summary: Project SDLC didn’t really change (they use Agile, but they add

artifacts and rigor based upon complexity & uncertainty.

15

• Avison & Fitzgerald in their 2005, 3rd edition, textbook “information systems

development” go into great detail about SDLCs, criteria for selection, and

frameworks for doing the selection.

• You can see from this slide, they have a comprehensive list of criteria for

comparing methodologies.

16

• Grunner suggests an algorithm that provides a way to compare various

methodologies using a framework.

• He uses this algorithm along with the Avison & Fitzgerald framework to

evaluate a sample project comparing 3 different SDLCs

• The important thing here is: the algorithm that starts with building the

selection team, evaluating fameworks, evaluating SDLCs, and ends with

presenting the findings.

17

• Yusof, Shukar, and Abdullah created the CuQuP framework that gives a

quantitative comparison of SDLCs for a given project taking into account

complexity, uncertainty, and the project phase strengths of each SDLC.

• They integrated the complexity/uncertainty component from Little (2005)

• They integrated the phased based weighting from Avison and Fitzgerald (2005)

• The Cu factor of CuQuP is the weighting of complexity/uncertainty

18

• Methodologies are weighted based upon their strengths in the 10 phases from

Avison & Firzgerald

• Items that are bright green score a 3 because the methodology covers that

phase in great detail. Light green a 2 because it covers that phase in some

detail, etc.

19

• I created and executed a development methodology survey

• I surveyed 6 development managers or development management

consultants. They had a varying amount of experience and education. They

were a cross section of companies that build software for internal systems,

software for clients, and software to be sold to multiple clients.

• Using the survey tool below I asked the participants what SDLCs they used and

why. What criteria they used to decide how to build their production and

maintenance software.

• 5 of the 6 interviews were done in person. One was done on the telephone.

During the interview process I learned additional and supporting information

which deepened my understanding of the individuals and their organizations.

20

21

• I got a great cross section of organizations

• Company A – Produces Software as a Service (Saas) electronic medical

record.

• Company B – A nationwide retail store.

• Company C – A nationwide transportation company.

• Company D – A medium sized membership organization.

• Company E – Produces regulatory compliance software they license to

clients for Osha and like

• Company F – A national airline

22

• Most organizations do not use different SDLCs for production versus

maintenance. This likely due to three factors:

• Their projects don’t vary much. The organizations do not have projects

that are significantly different from each other, so going through the

selection process each time yields little value for the cost;

• They don’t want to have 2 (or more) processes. Organizations build a

process around a particular methodology and cannot easily modify the

process to fit other methodologies

• Development managers are not intimately familiar with SDLC choices

that are available to them and so continue to use the status quo

methodology. Of the six companies surveyed, only one had different

formal SDLCs for project development versus maintenance. That

organization is using SCRUM for its project development and KANBAN

for its project maintenance.

23

• Here are the SDLCs being used by the various companies

• A – Scrum

• B – IE (Information Engineering)

• C – Rupp

• D – Waterfall

• E – Scrum

• F – Scrum / Kanban

24

• Release Cycle: How often products or updates are released? (biweekly,

quarterly, when ready, as soon as it can be fixed, etc.)

• Product type: Is the product a website where they can have several updates,

or a machine EPROM where it is costly to have more than one update?

• Product/Project Risk: What is the risk to the business, users, others if the

software doesn’t work?

• Team location: Are the users, developers all in the same location?

• Team experience: Are the developers experienced in the business domain &

software tools to be used?

• Team Size: How many analysts, testers, developers are on the team?

• Timeframe from development to release: How long from the time they start is

the first deliverable due?

• It’s interesting to see how these criteria compare to Avison & Fitzgerald’s list.

25

• Here you can see the recommended SDLCs for development and maintenance

for each organization based upon the survey information.

• Company A-Using Scrum: recommends Scrum for development Kanban

for maintenance

• Company B - Using proprietary IE: recommends IE for development,

Scrum for maintenance

• Company C – Using proprietary Rupp: recommends IE, Rad/Rupp for

maintenance

• Company D- Using Waterfall: recommends Scrum for both

• Company E – Using Scrum: recommends Scrum for both

• Company F – using Scrum / Kanban: Recommends Scrum, Rad for

maintenance

26

27

• On Project Maintenance versus development

• Different SDLCs should be considered. Maintenance is less complex

and less uncertain. So it seems logical; maintenance projects with

smaller scopes and shorter durations could use a lighter-weight

methodology.

• On SDLC Selection

• Project complexity and uncertainty are the main drivers for selection of

an SDLC. But the quality components and delivery periodicity are also

important. Companies selecting an

• Agile SDLC indicated the regular delivery periodicity was one of the

main reasons they selected and use Agile

• Selecting ANY SLDC is better than not having one. (Even a bad one).

• Most organizations where using a SDLC methodology that fit them well

even though they didn’t do a formal SDLC evaluation.

• On Selection Frameworks

• Quantitative Evaluation - The selection frameworks make it easier to

quantitatively demonstrate to a group that a particular SDLC fits an

organization better than another.

• Best Fit – for complexity/uncertainty & quality. Using a selection

framework to evaluate the complexity, uncertainty and quality

requirements gives you the best fit for an organization.

28

• A SDLC methodology does not exist in a vacuum. It is surrounded by people,

processes, and tools. The implementation an SDLC into an organization is

challenging. The analysts, developers, and managers need to be trained to

use the methodology. Organizational processes need to be created to handle

things like support tickets, rework, requirements gathering, and other

activities that support internal and external customers.

• The savings has to be there for 2 SDLCs to make sense. For an organization to

select two SDLCs and implement them into their organization could be

difficult. Although a lighter weight methodology might make sense, it has to

be weighed against additional overhead incurred by having more processes

surrounding the additional SDLC, additional training, and possibly additional

capital outlays for more tools.

• The bottom line is “it depends”. The decision is not clear-cut. Organizations

should thoughtfully evaluate the methodology they are using now and

determine if it is meeting their needs. If the reduction in overhead, by using a

different maintenance SDLC, outweighs the additional cost of having

additional processes, then it probably makes sense to use the right tool for the

job.

29

30