SOFTWARE DEVELOPMENT
METHODS
Table of Contents
Introduction
Who Am I? Motivation
Software Development Life Cycle
Software Development Methods
Waterfall (Obsolete) Agile
Extreme
What Are Software Development
Methods?
Semi-Formal Methodologies for building software.
Series of [hopefully] deterministic steps to build
quality software.
Reaction to “Software Crisis” of 1960s, 1970s,
1980s.
See “The Humble Programmer.” Edsger W. Dijkstra, ACM Turing Lecture 1972. ([1])
Notable Quote: “The sooner we can forget that FORTRAN
has ever existed, the better, for as a vehicle of thought it is no longer adequate: it wastes our brainpower, is too risky and therefore too expensive to use. ”
Software Crisis
Software Dev. Costs skyrocketed as time passed.
“Frequently Software was never completed, even after further significant investment was made” [2]
Lots of impossibilities:
Impossible to maintain. Impossible to fix bugs.
But why Software Engineering?
Simple software is easy to write.
Complex software is… well… Complex.
Complexity leads to complicated development methods.
Larger teams require more management
Hopefully, we’ll get some more predictable results
Less bugs
Better fulfillment of requirements Easier to maintain
Software Development Life Cycle
Time / Maturity based life line of software.
5-7ish Phases (Varies by literature)
Requirements Design
Implementation Verification
Requirements
Three stages
Ellicitation
“What do we want our Software to do?”
Specification
“This is what it will do.”
Analysis
“What do we need to know in order to make it do what we
Design
Primarily concerned with Architecture
Over-arching, cross-cutting design decisions, e.g.,
Choice of language
Modular vs. Monolithic vs. Three-Tier vs. Plug-in vs. etc…
Most important phase of SDLC. Should have most time spent on it (arguably). Rarely does.
Once set, hard to change.
Questions:
Implementation
Coding phase.
How do we codify the requirements?
How does the code satisfy the architecture?
How should we implement the design to reflect the
Verification and Validation
Does it do what we want it to do? Does it do it
correctly?
Biggest bang for the buck.
Functional requirements
Does it satisfy functionality?
Non-functional requirements?
Does it render an image in under 3 seconds?
Bad Behavior
Does it crash and burn or exit gracefully on a rainy day?
Maintenance
Chronologically longest stage of SDLC. Some
systems last for decades.
Ergo, most expensive stage.
Updates. Bug fixes. Patches. New Functionality.
Troubleshooting / Testing / Fixing unforeseen and
Pictures: SDLC V-Model
Pictures: SDLC Spiral-Model
Software Development Methods
Waterfall
Oldest, still used, but obsolete. And terrible.
Agile.
Reactionary. Hippies.
Extreme Programming (XP).
Learning based. Communist hippies.
Software Product Lines (SPLE)
Thank You Henry Ford!
Software Ecosystem (SECO)
Waterfall
Oldest Software Development Method
See [5]
Views Life Cycle as a set of waterfalls you “flow”
through sequentially.
Can’t flow up a waterfall. Once a stage is done, it’s
done. Set in stone.
Waterfall: Explained
Once each step is completed, results are set in
stone.
When requirements are done, requirements are set in stone and cannot be changed.
When design is done, architecture is set in stone.
Waterfall: Pro’s and Con’s
Very Structured
Very Disciplined
Great for Shrinkwrap
BUFD Saves Time.
Emphasis on Dox.
Very inflexible.
Horrible for Custom Not Elegant.
BUFD can corner us.
Worthless Artifacts =>
Worthless Dox
REQUIREMENTS
CHANGE
Waterfall Reaction: Agile
Reactionary method developed in response to
“heavily regulated, regimented, micromanaged, waterfall model[s] of development” [2].
Follows Agile Manifesto (Communists?)
Focuses on being “agile” and able to handle
changing requirements and design concerns quickly and elegantly.
Agile: Twelve Principles
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
Deliver working software frequently, from couple of weeks to a
couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout
the project.
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to
Agile: Another Wall of Text
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design
enhances agility.
Simplicity--the art of maximizing the amount of work not done--is
essential.
The best architectures, requirements, and designs emerge from self
organizing teams.
At regular intervals, the team reflects on how to become more
That’s groovy, but in English?
Agile promotes
Limited Managerial Interaction
Self Organization
Working Software, not documentation
Collaboration of Client and Development
Trust in development team
Things Agile Does
Constant Code Refactoring
Write Code, Analyze Code, Rewrite Code, Improve Quality
Makes code more clear, more concise, more efficient or better by design
Limited Documentation
Very limited documentation.
When code is refactored, documentation must be refactored. Solution: Don’t document.
Incremental Process
Functionality sliced into increments.
Increments implemented over a development iteration.
Iterative Development Process
Each iteration represents a complete SDLC. Iterations typically 1-4 weeks with Timeboxing.
Even Moar Things…
Scrum
Lets hold hands.
Test Driven Development
Write tests that fail. Write code. Write code to pass tests.
Pair Programming
I love this.
Continuous Integration
As soon as two modules are completed, integrate and test.
Agile: Pro’s and Con’s
Great for Small Teams Great for changing
requirements
Uncertain Domains
Constant Code Refactoring
leads to constant improvement
TDD minimizes bugs and
complications. Face-to-Face communication and collaboration Hippies. No Documentation. Project-Lead-Hit-By-Bus-Syndrome No models, no formalism Adaptive, not predictive Face-to-Face
communication and collaboration
Extreme Programming (XP)
Started by Kent (NOT GLEN) Beck, circa 1996.
Agile, by nature. Just as hippie. Twice as commie.
If a little bit of good practice is a little bit of good,
a lot of good practice is a lotta bit good.
Takes software engineering best practices to the extreme
Values, the first four
Communication
Give all developers a shared view of the system which matches the view held by the users
Simplicity
Code for what we need today, not what we need tomorrow. Start simple, add addt’l functionality later.
Feedback
Feedback from customer, from system, from team.
Respect
Respect for customer, for system, for team. Respect one’s own work, strive for excellence. Don’t commit project breaking code.
Values, courage
Courage (wtf)
Courage to design and code for today, not tomorrow.
It’s really hard to do things right when you can do them
easy.
The courage to throw away code when necessary.
I’ve got no problems doing find-replace-all. I also love deleting code.
The courage to remain persistent in the face of a difficult problem.
Three Principles
Feedback
Only useful if it is rapidly available.
Assuming simplicity
Treat every problem as if there exists a simple solution.
Embracing Change
Embrace the ever changing requirements from a client that doesn’t know what they want.
Four Activities
Coding
The truth is in the code. The only important product of the
system is the code.
Testing
A little testing can eliminate a few flaws. A lot of testing can eliminate a lot of flaws.
Listening
We cannot develop software if we cannot communicate
what can and cannot be done, technically, to the client.
Designing
We can get a long way by coding, testing and listening, but
Things XP does…
Pair Programming
Teaching method for programming.
Timeboxing
Fixed iterations with no extensions.
Refactoring
We already talked about this.
Collective code ownership
Everyone is responsible for all the code. Anyone can edit anyone’s code.
Other stuff
TDD
Refactoring
Constant integration
The Planning Game
Testathons
XP: Pro’s and Con’s
Great for Small Teams Great for changing
requirements
Uncertain Domains
Pair Programming serves
not only to produce good code, but to teach novice developers.
TDD minimizes bugs and
complications.
Hippies. And Commies.
Not scalable. Only works for small
teams.
No Documentation. Only Code. Project-Lead-Hit-By-Bus-Syndrome No BUFD. Refactoring design is
extremely expensive.
Incremental requirements leave
requirements open. When are we done?
Practice areas piggyback on each
other [6].
Do we still have time?
Software Product Lines?
Next time: (*DD) Something-Driven Development Attribute Model Test UML Software Ecosystems
Software Product Line Dev.
New. Fairly New. Kind of new.
Arose from “Software Factories” of 15 years ago in Japan.
Focuses on Strategic Reuse of all software
development assets.
Follows Product Line Methodology
What is a product line?
Garners huge Return on Investment given proper
What is a product line?
Set of related products by size, types, colors,
quantities or prices.
Products are usually similar. New research shows
that they don’t have to be, though.
Product Lines of Product Lines and such…
Can be things like…
Cars, Refrigerators, Laptops, almost anything that fits the above definition. Sort of.
My Car: The Honda Civic
What components make up a Honda Civic?
Body
All civics have a body.
Engine
V4 or V6?
Transmission
Automatic or Standard?
Doors
Two door? Four Door?
Windows
Two or Four?
Additional Features
Discussion
Products in PL composed of parts (features)
Some features required
Body
Some have disjoint alternatives
Manual or Automatic
Some have subsequent requirements
Manual requires V6
And some are optional
What is a Software Product Line?
A software product line is a set of
software-intensive systems that share a common,
managed set of features satisfying the specific
needs of a particular market segment or mission
and that are developed from a common set of
core assets in a prescribed way [7].
SPL Definition Breakdown
Software Intensive Systems
We’re talking about software. Not hardware. We’re talking about multiple systems.
Share a common, managed set of features.
Common. They occur naturally across multiple products. We do not shoe-horn features into a product.
Managed. We do not shoe-horn features into our set of features. They are managed, not thrown together.
SPL Definition Breakdown
Specific needs of a particular market.
We don’t product line for product lining’s sake. We
product line because there is a business motivation. We have a business scope.
Developed from a common set of core assets
We have a common set of building blocks with which to build each product.
In a prescribed way.
This isn’t software as abstract art. Our composition is a structured method.
More simply:
We build a similar set of products with attributes of
commonality and variability.
Certain features are common to all products.
Certain features have variations across products.
Certain features are optional to products.
The bases.
Software developed from two artifact-bases:
Core Asset Base: Components that are used across some or all products.
Product Asset Base: Components specific to a product.
Core assets are designed to be “reusable.” All core
assets have an attached process that documents that asset and how it is used. Think JavaDocs, but better (we hope).
Core Assets
Core Assets do not have to be code.
Can anyone think of any assets that are not code?
Core assets have an attached process.
Because our development is divided into asset
development and product development, a core asset is necessary.
Must have a reason to be there:
Can’t include stuff because “It might be useful later” E.g., My cool intelligent dialog window (bad)
Scoping
Key to a proper product line is a tightly defined
scope.
Scope is constantly re-evaluated.
What do each of the products have in common?
What do they do differently?
Commonality / Variability analysis
If two products differ too widely, they probably
What is a variation point?
Points in architecture where variation can occur.
Example: Automatic Windows vs. Power Windows.
Variations are bound at particular times. Binding
times.
Window control is bound at assembly. Color is bound after assembly.
Variability Management
Based on Binding Time
Code Instantiation Time (Coding)
Static Instantiation (Assembling of Code) Build Time (Compilation)
Run Time (Configuration Time) Dynamic Binding (While Running)
What are examples of variation mechanisms in
Variability Management: Answers
Mechanisms for Binding
Code itself, inheritance. Preprocessing directives Makefile generation
Input Files
SPL: An Example
Turbo Tax: Tax filing software
Five versions:
Basic, Deluxe, Premier, Home & Business, Business.
Developed simultaneously through asset reuse.
Modified and Maintained on a yearly basis to
Gains
Improved productivity by as much as 10x
Increased quality by as much as 10x
What is quality?
Decreased cost by as much as 60%
Decreased labor needs by as much as 87%
Decreased time to market (to field, to launch) by as
References
[1] E. W. Dijkstra. “The Humble Programmer.” ACM Turing Lecture, 1972.
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html Accessed 11/14/11
[2] “Information Systems and Strategy, Session 2, The Software Crisis.” Euromed Marseille School of Management, World
Med MBA Program - Information Systems and Strategy Course http://www.chris-kimble.com/Courses/World_Med_MBA/Software_Crisis.html Accessed 11/14/11
[3] Clarus Concept of Operations. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.
[4] Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
[5] W. Royce. (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26
(August): 1–9.
[6] M. Stephens. The Case Against Extreme Programming: A Self-Referential Safety Net.
http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp Written August 26, 2001. Updated January 26, 2003. Accessed 11/14/11.
[7. P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley Professional; 3rd edition
