SOFTWARE DEVELOPMENT METHODSCPSC 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. Source Code Intermediate Language

Intermediate Language … Executable and Interpretable Code

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. Numbers, Variables, Strings, Reserved words, Symbols

(+-*/%&), etc. Invalid symbols result in a syntactic compilation

error 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 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 emergent behaviors.

Pictures: Linear SDLC

Pictures: SDLC V-Model

See [4]

Pictures: SDLC Spiral-Model

See [4]

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)

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

Very StructuredVery 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

Pro’s Con’s

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

And more...Cheech Marin and Tommy Chong, Agile Developers

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

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

Pro’s Con’s

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 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.

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 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 More, so much more…

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].

Pro’s Con’s

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

All civics have a body. Engine

V4 or V6? Transmission

Automatic or Standard? Doors

Two door? Four Door? Windows

Two or Four? Additional Features

Power Windows, Power Locks, AM/FM, CD, XM, etc…

Discussion

Products in PL composed of parts (features) Some features represent ‘variation points’, points at

which variation can occur in product instantiation. Some features required

Body Some have disjoint alternatives

Manual or Automatic Some have subsequent requirements

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

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].

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.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 August 30, 2001.