Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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