• Save
SCA in an Agile World | June 2010
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


SCA in an Agile World | June 2010

Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    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 - http://www.nxtbook.com/nxtbooks/sqe/bettersoftware0708/index.php?startid=36Moto – from Motorola case study http://www.klocwork.com/resources/case-study/motorolaMentor – from Kevin Pendleton customer quote


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