SOFTWARE DEVELOPMENT
METHODS
CPSC 215, Clemson University, Fall 2011
Table of Contents



Rock Paper Scissor Tournament
Extra Credit Assignment
Software Engineering At Large
 Motivation
 Software
Development Life Cycle
 Software Development Methods
 Waterfall
(Obsolete)
 Agile
 Extreme
 Software
Product Lines? Maybe.
Rock Paper Scissors Tournament

Round Two…
 But
first, I need Mr. DeClue and Mr. Kuisel
EC Asg: An Overview of Compilation

Compilation is a series of language transformation.
Code  Intermediate Language 
Intermediate Language  …  Executable and
Interpretable Code
 Source

Four main phases
 Lexical
Analysis
 Parsing
 Semantic
Analysis
 Code Generation
Compilation Process: Lexical Analysis


Examines program and tokenizes it into a set of
symbols.
Valid symbols belong to the set of terminal symbols that
are described by the grammar of the language.


Invalid symbols result in a syntactic compilation error


Numbers, Variables, Strings, Reserved words, Symbols (+*/%&), etc.
Ever have a horizontal tab in a C++ file?
Results in a set of tokens that are used to parse the
source file.
Compilation Process: Parsing



Every programming language is defined by a Context Free
Grammar.
The grammar can be used to generate strings that belong to the
‘language of the grammar.’
Parsing seeks to determine whether a given source file belongs to
the ‘language of the grammar’.



Via top-down parsing, where we begin at our start symbol and try to
generate the program in question.
Via bottom-up parsing, where we begin with our program and apply
the productions or rewrite rules of our grammar backwards to reduce
the program to the start symbol.
Errors are usually syntactic in nature, but can be semantic.


int a = int;
float f = ‘c’ + 7.3 * true;
Semantic Analysis



Typically done in tandem with parsing.
As we use a rewrite rule or production in our
grammar, we have some semantics that go with the
production.
Interprets the source code into an intermediary
language that is simpler than the source code itself
in syntax and semantics.
 int
a = 7; 
 (a,
mem_alloc, 4, 1)
 (a, int_assign, 7, 0)
Inbetween Analysis




After we’ve done our parsing and semantic analysis,
we’re left with the program in some intermediary
language.
At this point, we may evaluate the intermediary
code for compilation optimizations, correctness and
bug detection, etc.
Each activity will transform the code from one
language into another language, each time refining
the code under compilation to make it better.
Totally optional.
Code Generation



After parsing, semantic analysis and any number of
optimization steps, we’re left with the original
source code, translated into an intermediary
language.
The code generator then generates something that
is ‘closer’ to executable code from this program in
its intermediary language.
Could be assembly code, could be machine code,
could be interpreter code (like Java Byte Code).
Extra Credit Assignment

For the extra credit assignment…
The attached MainDriver.java is the result of the compilation
process. The code generation outputs Java code.
 Our task is to implement all the classes that are required for
the Java code generated from this compiler we can’t see.
 We don’t have to do any lexical analysis, parsing, semantic
analysis, code optimization or code generation.
 Just implement the classes, try to run MainDriver.java


Any questions?
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.
Impossible to match functionality to requirements.
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
 Predictable development costs
Software Development Life Cycle


Time / Maturity based life line of software.
5-7ish Phases (Varies by literature)
 Requirements
 Design
 Implementation
 Verification
 Delivery/Maintenance
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
say it will do?”
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:
 How
do we ensure modules work together prior to
implementing them in code?
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
business requirements from the Requirements phase?
Verification and Validation

Does it do what we want it to do? Does it do it
correctly?
 Biggest

Functional requirements
 Does

it satisfy functionality?
Non-functional requirements?
 Does

bang for the buck.
it render an image in under 3 seconds?
Bad Behavior
 Does
day?
it crash and burn or exit gracefully on a rainy
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
emergent behaviors.
Pictures: Linear SDLC
Pictures: SDLC V-Model
See [4]
Pictures: SDLC Spiral-Model
See [4]
Software Development Methods

Waterfall


Agile.


Learning based. Communist hippies.
Software Product Lines (SPLE)


Reactionary. Hippies.
Extreme Programming (XP).


Oldest, still used, but obsolete. And terrible.
Thank You Henry Ford!
Software Ecosystem (SECO)

I hate biology.
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.
 Except
in flowback models of waterfall…
Waterfall
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.

“Measure Twice, Cut Once.” Big Upfront Design.
Waterfall: Pro’s and Con’s
Pro’s




Very Structured
Very Disciplined
Great for Shrinkwrap
BUFD Saves Time.
Emphasis on Dox.
Con’s






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
and within a development team is face-to-face conversation
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
effective, then tunes and adjusts its behavior accordingly
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
Cheech Marin and Tommy Chong, Agile Developers
 And more...
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.
Agile Iterative-Incremental Dev.
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
Pro’s


Great for Small Teams
Great for changing
requirements




Con’s



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-BusSyndrome
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

Five Values, Three Principles, Four Activities
Values, the first four

Communication


Simplicity


Code for what we need today, not what we need tomorrow.
Start simple, add addt’l functionality later.
Feedback


Give all developers a shared view of the system which matches
the view held by the users
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

Assuming simplicity
 Treat

useful if it is rapidly available.
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.

Sounds like a mantra to me…
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
without designing, we’re stuck.
Things XP does…

Pair Programming
 Teaching

Timeboxing
 Fixed

iterations with no extensions.
Refactoring
 We

method for programming.
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
More, so much more…
XP: Pro’s and Con’s
Pro’s


Great for Small Teams
Great for changing
requirements



Con’s



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?
Software Product Line Dev.

New. Fairly New. Kind of new.
 Arose
from “Software Factories” of 20 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
scoping and sustained use.
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.

Example…
My Car: The Honda Civic

What components make up a Honda Civic?

Body


Engine


Two door? Four Door?
Windows


Automatic or Standard?
Doors


V4 or V6?
Transmission


All civics have a body.
Two or Four?
Additional Features

Power Windows, Power Locks, AM/FM, CD, XM, etc…
Discussion

Products in PL composed of parts (features)


Some features required


Manual or Automatic
Some have subsequent requirements


Body
Some have disjoint alternatives


Some features represent ‘variation points’, points at which
variation can occur in product instantiation.
Manual requires V6
And some are optional

Power Locks, Power Windows, etc.
What is a Software Product Line?


A software product line is a set of softwareintensive 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].
That’s kind of long. Let’s break it down.
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.
Certain features are unique to products.
The bases.

Software developed from two artifact-bases:
 Core
Asset Base: Components that are used across most
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
aren’t good in a product line together.
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.
 Automotive
Window control is bound at assembly.
 Car Color is bound after assembly.

What are some examples of binding times in code?
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
each of these?
Variability Management: Answers

Mechanisms for Binding
 Code
Instantiation: Code itself, inheritance.
 Static Instantiation: Preprocessing directives
 Build Time: Makefile generation
 Run Time: Input Files
 Dynamic Binding: Polymorphism
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
reflect new tax laws in every state.
Gains





Improved productivity by as much as 10x
Increased quality by as much as 10x
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
much as 98%
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.chriskimble.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
August 30, 2001.