SCA in an Agile World | June 2010


Published on

Check out this slideshow from Klocwork to learn more about SCA (Static Code Analysis) and Agile development.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Introduce variable = introducewayariablevayRename = enameray
  • Good chance to wrap-up and pitch the ROI. Mention that as the customer goes through the POC w/ Klocwork we’ll develop an ROI based on their defect data & assumptions.Assumptions:10 person team (fairly standard size), 2 week iterations, 5 stories/iteration based on experience with various teams/customers, each story creates about 300 LOCBug Detection:Based on data from our customer base, SCA finds approximately 3 bugs for every 1000 LOC. In a case study (from Johns Hopkins...which isn’t yet available, so don’t quote), this customer determined that by using SCA (Klocwork) they were able to save 4 hours/bug.Developers now have an additional 18 hours/iteration to work on new stories rather than fixing defects.Refactoring:Refactoring is all about making your code more inheritable for the next developer who may work on it. In this case, the savings is small per developer, about ¼ of an hour.Developers now have an additional 12.5 hours to work on stories, since they are able to understand the intent of the code quickly.Code Review:Assumption – Code review includes 4 developers in a 1 hour meeting (for a total of 4 developer hours)In a study done at the Royal Military College of Canada, it was determined that developers were 50% more efficient when allowed to review code when/where they wanted to (i.e. Reading it on their desktop) than by performing the same code review in a meeting. Developers now have an additional 10 hours to work on productive development activities.Real world ROI examplesLLNL - – from Motorola case study – from Kevin Pendleton customer quote
  • SCA in an Agile World | June 2010

    1. 1. Source Code Analysis in an Agile World<br />Todd Landry – Senior Product Manager<br />
    2. 2. About Me<br />13+ years in Product Management<br />Klocwork PM for 2+ years<br />Worked with multiple Agile teams<br />Certified Scrum Product Owner<br />Contact Info:<br />EMAIL:<br />TWITTER:<br />BLOG:<br />
    3. 3. Before We Get Started <br />Not a sales pitch<br />Intended as an educational session<br />Provides a high level overview of Agile and Static Code analysis<br />Understand how they can work together<br />
    4. 4. Agenda <br />Agile Overview<br />Introducing Static Code Analysis <br />Adopting tools into Agile<br />How Klocwork Fits in Agile<br />Summary<br />Questions<br />
    5. 5. Agile Adoption Has Reached Mainstream Proportions<br />“Please select the methodology that most closely reflects the development process you are currently using.” (select only one)<br />Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009 | Forrester Research, Inc.<br />
    6. 6. Who Uses Agile?<br />Software organizations everywhere<br />Aerospace: Raytheon, Northrup Grumman<br />Automotive: GM, DaimlerChrysler<br />Banking: Merrill Lynch & Co., T. Rowe Price Group<br />Communications: Verizon Wireless, SBC<br />...<br />
    7. 7. Why Agile? What’s Wrong With Waterfall ?<br />Nothing really, still the most widely used development methodology today<br />Most predictable of all know (for the most part), what you’re getting and approximately when<br />Well documented set of requirements (and most everything else)<br />Structured approach (not chaos like those Agile-guys)<br />However, there are drawbacks<br />Commitments are made early on, and are difficult and costly to change <br />Not always sure you will meet the market needs at release time<br />Risk is pushed to the end of the development period during testing phases<br />Hard to react to problems when so late in the development process<br />
    8. 8. Why Agile?<br />Visibility - stakeholder collaboration and validation throughout the development life-cycle <br />Value - continuous delivery of much more measurable business value <br />Adaptability - the ability to rapidly respond to changes in strategy, priorities, and plans <br />Risk - the reduction in aggregate project risk as a result of #1-3 above<br />So what is Agile development?<br />
    9. 9. Introduction To Agile<br />Agile first surfaced in mid-1990’s<br />Reaction to waterfall development <br />Bureaucratic, slow, and inconsistent with the ways that software developers actually perform effective work<br />Different ‘types’ of Agile<br />Scrum<br />XP<br />Feature driven development<br />Lean development<br />Adaptive Software Development<br />Dynamic Systems Development Method (DSDM)<br />Kanban<br />
    10. 10.
    11. 11. Agile Manifesto Summarized<br />Agile development is an approach<br />Continuous and rapid delivery of working software<br />Embrace change<br />Collaboration and communication<br />All about the Team<br />Simplicity<br />
    12. 12. Agile vs. Waterfall<br />Waterfall Development<br />Agile Development<br />Verification<br />Implementation<br />Maintenance<br />Design<br />Requirements<br />x months/years<br />2-4 weeks<br />
    13. 13. Typical Agile Process<br />24 h<br />2-4 Weeks<br />Product Backlog<br />Iteration Backlog<br />Iteration<br />Working Increment of the software<br />
    14. 14. The Iteration<br />Verification<br />Implementation/<br />Development<br />Design<br />Deployment/<br />Maintenance<br />
    15. 15. What Happens with Bugs in Agile?<br />During the iteration, bug fixes are addressed before any new feature/task is started<br />At the end of an iteration, any outstanding bugs typically go to the top of the list for the next iteration<br />New features are not started until all bugs are fixed<br />Schedule starts to slip<br />Morale can decline<br />BACKLOG<br />Awesome Feature 1<br />Cool Feature 2<br />Cool Feature 3<br />
    16. 16.
    17. 17. Introduction toSource Code Analysis<br />
    18. 18. Source Code Analysis (SCA) – The Basics<br />What is source code analysis?<br />The analysis of computer software (source code) that is performed without actually executing programs built from that software.<br />Automated code analysis technology finds weaknesses in source code <br />Logic errors and implementation defects<br />Security vulnerabilities<br />Architecture validity<br />Concurrency violations and rare boundary conditions <br />Software metrics generation and management<br />Distinct from more traditional dynamic analysis techniques, such as unit or penetration tests<br />Underlying technology is called static analysis<br />Work is performed at build time using only the source code of the program or module<br />Complete view of every possible execution path, rather than an aspect of observed runtime behavior<br />Confidential<br />
    19. 19. SCA – A History Lesson<br />1st Generation SCA<br />2nd Generation SCA<br />3rd Generation SCA<br />1970’s<br />2000<br />Today<br />
    20. 20. Source Code Analysis - Historical perspective<br />Lint was invented as a developer’s tool<br />Lots of problems with the model<br />Noise, inaccuracies, too-small a locality of reference<br />But it was always intended to “just give better compiler errors to the developer”<br />Seen by developers as “opt-in” and “mine”<br />What was Lint doing?<br />Scanning, initially<br />Looking for “known aberrant” problems with C<br />Missing / extra semi-colons<br />Missing curlicues<br />Potentially dangerous implicit casts<br />
    21. 21. SCA – A History Lesson<br />1st Generation SCA<br />2nd Generation SCA<br />3rd Generation SCA<br />1970’s<br />2000<br />Today<br />
    22. 22. Source Code Analysis - Historical perspective<br />2nd generation static analysis provided better core analysis capabilities that extended beyond syntactical and semantic analyses to include:<br />Sophisticated inter-procedural, control- and data-flow analysis <br />New approaches for pruning false paths<br />Estimating the values that variables will assume<br />Simulating potential runtime behavior<br />Moved away from being a developer tool<br />In order to produce good analysis, must do it at integration build<br />So it’s not part of the developer’s workflow, it’s asynchronous<br />So when a bug is found it’s too late<br />The developer is already on some other task and must be dragged back<br />
    23. 23. What kind of bugs?<br />Local bugs vs. inter-procedural bugs<br />Local bugs are “easier” to find, and certainly easier to understand<br />Picture “slapping head”<br />Inter-procedural bugs are the big payoffs<br />Difficult for different developers working on projects to deal with each other’s code rationally<br />Lots of fingers in lots of pies = lots (and lots) of bugs<br />What kinds of bugs?<br />Resource management<br />Pointer management (and yes, this means Java too)<br />Security vulnerabilities (injections, overflows, naivety, stupidity, …)<br />Concurrency<br />
    24. 24. The Costs of Bug Containment<br />2nd Generation Source Code Analysis<br />Confidential<br />
    25. 25. SCA – A History Lesson<br />1st Generation SCA<br />2nd Generation SCA<br />3rd Generation SCA<br />1970’s<br />2000<br />Today<br />
    26. 26. 3rd Generation Source Code Analysis<br />Deliver 2nd generation analysis capabilities right to the developer desktop<br />Focus on enabling the developer, not blaming them<br />If the tool is “mine” I’m more likely to use it when I’m in process<br />If I use it in process, I’ll find and understand the bugs more quickly<br />If I understand the bugs, I’ll fix them faster<br />If I fix the bugs, the code stream isn’t polluted, my QA time isn’t wasted, and my product gets better<br />Bottom line<br />Don’t check in code that doesn’t work!<br />Build defensive coding into the organization from the ground up<br />Narrow the gap between the rock stars and the interns<br />Make a better product<br />
    27. 27. The Costs of Bug Containment<br />2nd Generation Source Code Analysis<br />Confidential<br />
    28. 28. The Costs of Bug Containment<br />3rd Generation Source Code Analysis<br />2nd Generation Source Code Analysis<br />Confidential<br />
    29. 29. The Iteration with SCA<br />Verification<br />Implementation/<br />Development<br />Design<br />Deployment/<br />Maintenance<br />
    30. 30.
    31. 31.
    32. 32. Adopting Tools for Agile<br />
    33. 33. Agile team members<br />Developers have their feet under the table now<br />Provide input on what’s being done<br />Determine whether it makes sense<br />Agile tools tend to cater to the process of teaming<br />Product manager tools<br />Project manager tools<br />Time management tools<br />Customer relationship tools<br />So where do we come in?<br />None of these tools are targeted at the developer<br />
    34. 34. There are very few developer tools…<br />Continuous integration<br />OK, but is that all there is?<br />CI helps out with the production process<br />Where are the tools for actual development?<br />Some IDEs / languages are awesome<br />Java, Ruby, Python, all great productive languages<br />C/C++, not so much<br />Agile isn’t just web pages and prototypes<br />Mission critical applications are being developed using Agile now<br />And they use those unpleasant languages.<br />
    35. 35. Agile developer tools?<br />We all know that Agile isn’t about tools, we’ve all read it<br />First thing the manifesto breaks out<br />“Individuals and interactions over processes and tools”<br />Times have changed…so have the tools…<br />What kind of tools could help Agile developers?<br />Architectural coherence and sustainability<br />Refactoring support<br />Organic peer review<br />
    36. 36. How Does Klocwork Help?<br />
    37. 37. Klocwork Agile Desktop <br />Early Defect Detection<br />Collaborative Mitigation<br />Refactoring<br />Code Review<br />
    38. 38. Find Defects Really Early<br />Agile requires a product every iteration<br />If you don’t hit that milestone, then you fix first, implement later in the next iteration<br />The worse it gets, the more bug debt you accumulate<br />Velocity deteriorates the further into the project you get<br />Bug debt kills projects<br />Low velocity  Low morale  Angry (or at best skeptical) customers<br />Until, finally… “This process doesn’t work!”<br />So fix early, fix often<br />Maintain high quality, low bug debt, high velocity<br />
    39. 39. Klocwork in Visual Studio<br />
    40. 40. Keep Everyone in the Loop<br />Short iterations require rapid communication<br />Klocwork provides collaborative mitigation for all reported issues<br />Developers can change the status/add comments for these issues<br />Status changes and added comments are automatically synchronized with other developers<br />No duplication of issue fixes<br />Complex bugs can be worked on/tracked as a team<br />
    41. 41. Refactoring…OK, but why?<br />Refactoring = The process of simplifying and clarifying code without changing the program’s behaviour<br />Well established practice in the Agile development process<br />Developers do this all the time…but it’s hard to do<br />Need ways to do this faster, more efficiently<br />Anything that has a lifecycle to it needs to be created thinking of the future<br />In a development team, the future frequently means different people<br />Make the code you’re creating as simple to inherit as possible<br />So refactor early, refactor often<br />
    42. 42. Refuctoring<br />Refuctoring is the process of taking a well designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone other than yourself<br />Common refuctorings include:<br />Pig Latin (for naming conventions)<br />Treasure hunt<br />Rainy day module<br />Developer foxhole<br />The Waterfall Alliance<br />
    43. 43. Code Review<br />Almost always part of the development process, but is:<br />Time consuming<br />Belittling<br />Boring<br />Embarrassing<br />
    44. 44. Code Reviews – Mandatory<br />“To what extent are code reviews a part of your regular release cycle?”<br />87%<br />Source: A commissioned study conducted by Forrester Consulting on behalf of Klocwork, February 2010<br />
    45. 45. Klocwork Inspect<br />So how have we changed code reviews?<br />Organic, bottom-up, rather than imposed, top-down<br />Peer-based, not hierarchical<br />Early and often, not after the fact<br />Asynchronous, rather than “around the table”<br />Defects found through SCA integrated into the code review<br />Don’t bring the person to the review, bring the review to the person<br />
    46. 46. How much can Klocwork help? Some examples...<br />2 week iteration & 10 person team<br />5 stories – 300LOC/story<br />Real world customer ROI examples…<br />Lawrence Livermore saved $200,000 on 365 KLOC project<br />Motorola reduced # of issues found at System Test by 50%<br />Mentor Graphics found 1000 bugs with no involvement from testing<br />
    47. 47. All Good Stuff...But <br />There needs to be a balance<br />Tools must help develop better code, and not hinder individual interaction <br />Tools must do the job with minimal effort, and minimal side effects<br />Be flexible...Fit the tool to the team, not the team to the tool...otherwise you’re toast! <br />
    48. 48. Summary<br />Agile is a development methodology<br />Many different flavours...Klocwork can help in all of them<br />Klocwork provides tools for the developer<br />Finding issues as early as possible in the SDLC eliminating costly rework<br />Allowing near-real time collaboration on issues<br />Allowing users to refactor their code for better consistency<br />Provide a non-intrusive process for a critical (but painful) component of software development...the code review<br />
    49. 49.<br /><br />