SOFTWARE DEVELOPMENT METHODS CPSC 215, Clemson University, Fall 2011.
-
Upload
scarlett-loren-marshall -
Category
Documents
-
view
214 -
download
0
Transcript of SOFTWARE DEVELOPMENT METHODS CPSC 215, Clemson University, Fall 2011.
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.