Static Analysis helps developers prevent and eliminate defects—using thousands of rules tuned to find code patterns that lead to reliability, performance, and security problems. Over 15 years of research and development have gone into fine-tuning Parasoft's rule set.
For more information about Static Analysis please click on the link below.
http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547
2. Agenda for this session
Define static analysis
Layout strategy for evaluating and choosing a
static analysis tool that will actually work in the
field
List possible evaluation criteria
Parasoft Proprietary and Confidential
3. About Parasoft
Founded in 1987
27 Patents for automated quality processes
Build quality into the process
Static Analysis tools since 1994
Parasoft Proprietary and Confidential
5. What IS Static Analysis?
Variety of methods
Peer Review / Manual Code Review / Code Inspection
Pattern-based code scanners
Flow-based code scanners
Metrics-based code scanners
Compiler / build output
Parasoft Proprietary and Confidential
6. First things first
More organizations are adopting formal policies
regarding static analysis
Many companies use a bake-off to choose tools
Bake-offs are not very useful to select the best
tool
Parasoft Proprietary and Confidential
7. Assess Your Needs
What pains do you plain to address?
FDA, MISRA, PCI, etc.
Is your current development process stable,
repeatable, and streamlined?
Have you tried static analysis before?
Why did it fail – how can you prevent a repeat
How is your organization structured?
Corporate wide config or varied by group/project
Will analysis apply to all projects? New Code?
Legacy?
Where do you want to be in the future?
Parasoft Proprietary and Confidential
8. Compile Candidate List
Get recommendations
Perform due diligence
Even if the tool comes highly recommended
Even if the tool has been used by someone in the group
Your code, process, culture, and environment are
unique
Keep the big picture in sight
Parasoft Proprietary and Confidential
9. Explore Vendors
You’re committing to a relationship with a
vendor
What is their vision?
What best practices do they have?
Do they have a coherent strategy for the enterprise
If they don’t have best practices you’ll need to develop
them
Reputation
Who uses tool?
Case studies
Parasoft Proprietary and Confidential
10. Talk with Vendors
Evaluations are disruptive – get data upfront
Are your visions in sync with vendor?
Explain what problems you want to solve?
Find out if they think static analysis will resolve it
Can they set objective criteria to assess success
Describe your environment
How have they helped others like you?
Explain your vision for deployment and adoption
for the next 2-3 years
Do they believe its feasible?
Parasoft Proprietary and Confidential
11. Handling vision mismatch
Vendor should accept requests that fit their
general business
If they vendor disagrees with your strategy do
they have a convincing explanation and
alternative?
Does the vendor bend over backward? Even for
unreasonable requests?
Parasoft Proprietary and Confidential
12. Pilot Top Candidates
Setup test bed and run preliminary tests
Familiarize yourself with the tool
Identify obstacles
Be ready to assist those doing the actual pilot
Select one group
Real project – not static legacy code
Engineers who like new things
Parasoft Proprietary and Confidential
13. Work with pilot users
Don’t just give pilot users the program and
expect useful results
Explain
How to use it in your workflow
What parts of the application to test
What code should be tested
What to look for while using the tool
Parasoft Proprietary and Confidential
14. Pilot tasks
Pilot users should have a list of tasks
How did the tool make their lives better?
What could make it even better?
How did the tool make their lives worse?
How bad was the learning curve?
Parasoft Proprietary and Confidential
15. Compare Post-pilot Candidates
Zero in on required functionality
Evaluate vendors response to requests and
issues
Judge what the relationship will be like
Parasoft Proprietary and Confidential
16. Evaluation Criteria: Rules
Number of built-in rules you’re really willing to
enforce
Quality of built-in rules you’re really willing to
enforce
Depth and breadth of analysis
Feasible means to reduce noise
Few to no false positives
Tolerable number of missed negatives
Ease of adjusting built-in rules
Ease of adding custom rules
Level of complexity possible in new rules
Vendors plan for adding new rules
Parasoft Proprietary and Confidential
17. Evaluation Criteria: Workflow
IDE integration
Batch mode
Violation reporting / review mechanism
Automated assignment of errors to responsible
developers
Legacy code identification and support
Rule severity customization
Ability to suppress violation reporting
Automated violation correction
Parasoft Proprietary and Confidential
18. Evaluation Criteria: Scalability
Scalable usage model
Ease of updating the rule set team-wide or
organization wide
Ability to support tiered rule sets
Extensibility – API
Support for additional languages and verification
methods (unit test, code review, etc)
Speed of analysis (end-to-end)
Parasoft Proprietary and Confidential
19. Evaluation Criteria: Vendor
Product stability
Having some issues is inevitable
Defect reports
Feature requests
Overall support
Parasoft Proprietary and Confidential
20. The 2 Most Important Questions
Will our engineers really adopt it and use it?
Can you make the tool work on real code with zero
noise?
Will it scale?
Is the work-flow practical?
Is this a long-term solution?
Evaluations consume a lot of time and effort
Don’t settle for “it’s good enough”
Will it help reach your corporate goals?
Time spent now will reward you later
Avoid continuous product evaluations
Parasoft Proprietary and Confidential