Presentation Transcript

1. Software Development Methods

   CPSC 215, Clemson University, Fall 2011
2. 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.
3. Rock Paper Scissors Tournament Round Two… But first, I need Mr. DeClue and Mr. Kuisel
4. 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
5. 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.
6. 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;
7. 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)
8. 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.
9. 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).
10. 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?
11. 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. ”
12. 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.
13. 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
14. Software Development Life Cycle Time / Maturity based life line of software. 5-7ish Phases (Varies by literature) Requirements Design Implementation Verification Delivery/Maintenance
15. 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?”
16. 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 togetherprior to implementing them in code?
17. 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?
18. 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?
19. 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.
20. Pictures: Linear SDLC
21. Pictures: SDLC V-Model See [4]
22. Pictures: SDLC Spiral-Model See [4]
23. 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.
24. 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…
25. Waterfall
26. 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.
27. Waterfall: Pro’s and Con’s Pro’s 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
28. 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.
29. 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
30. 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
31. 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
32. 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.
33. 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.
34. Agile Iterative-Incremental Dev.
35. 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.
36. Agile: Pro’s and Con’s Pro’s 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
37. 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
38. 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.
39. 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.
40. 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…
41. 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.
42. 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.
43. Other stuff TDD Refactoring Constant integration The Planning Game Testathons More, so much more…
44. XP: Pro’s and Con’s Pro’s 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].
45. Do we still have time? Software Product Lines?
46. Software Product Line Dev. New. Fairly New. Kind of new. Arose from “Software Factories” of 20years 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.
47. 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…
48. 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…
49. 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.
50. What is a Software Product Line? A software product line is a set of software-intensive systemsthat share a common, managed set of featuressatisfying 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.
51. 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.
52. 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.
53. 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.
54. 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).
55. 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)
56. 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.
57. 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?
58. 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?
59. Variability Management: Answers Mechanisms for Binding Code Instantiation: Code itself, inheritance. Static Instantiation: Preprocessing directives Build Time: Makefilegeneration Run Time: Input Files Dynamic Binding: Polymorphism
60. 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 basisto reflect new tax laws in every state.
61. 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%
62. 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.” EuromedMarseille 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.