Agile and CMMI - a potential blend
Upcoming SlideShare
Loading in...5
×
 

Agile and CMMI - a potential blend

on

  • 362 views

Presented at Agile in Business conference at Bangalore. This presentation focuses on code metrics that can be used as lead indicators to effectively control and predict the application quality

Presented at Agile in Business conference at Bangalore. This presentation focuses on code metrics that can be used as lead indicators to effectively control and predict the application quality

Statistics

Views

Total Views
362
Views on SlideShare
362
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Timely, cost effective, objective
  • Can tere better way, for eg: can our requirements show its indwelling charetecters? Can we figure out a way to bering it oiut. Can I have a structural view of it, which brings out its charecterricts. Eg in use case, in code – knowing complexity etc?Architecture is abt decision making. Can there be an indictator for our decision making?This is where we are heading to.JIDOKA in s/w as we see it is controlling the indwelling factors. We cant obsviouslycontroll the outdwellers. Somewhere the industry is unhealthily skwed towards customer sats without controlling the indwelling factors. Our egrs,BA, archs are confident in their own way, but not able to pass the maturity around. Customer apprecuation creates gaga, customer mute, then no recognition,!!Extend of measurement indicates our maturity
  • Put Note for abbrevsChallenge dealing with SIT, importance of way we chose SIT. Industry benchmark. Defects coming in system test phase; clear cause of matrurity issue. Inability to find defects early-> is the way we are doing engg process. First we thougt coding has clue, then we figured, requiremsts has the cluie. Hence way we strctureengg process properly.
  • 92% of classes were within those values. It was within those other 8, we found this.Study from a university: tried the similar exercise internally. Each class was one data point, tried to map to system testing defects.
  • Which were those 8, what were those that contributed to SIT defects
  • http://www.eclipsezone.com/articles/pmd/http://pmd.sourceforge.net/pmd-report.htmlhttp://checkstyle.sourceforge.net/config_metrics.htmlhttp://docs.codehaus.org/display/SONAR/Java+Metric+Definitionshttp://www.cs.umd.edu/~jfoster/papers/issre04.pdfhttp://findbugs.cs.umd.edu/papers/MoreNullPointerBugs07.pdfhttp://findbugs.cs.umd.edu/papers/FindBugsExperiences07.pdf<< Knock off PMD and find bugs>><<<change :: Baselined set of metrics list, use of techniques previously, next box for tools, deploymente- with eclipse and continous integration with build tools like hudsonetc
  • <>

Agile and CMMI - a potential blend Agile and CMMI - a potential blend Presentation Transcript

  • Agile with CMMi - A potent blend… Mosesraj R Collabera Solutions Bangalore 1
  • CMMI & Agile Level 4/5 SCRUM/XP Practices PrinciplesLevel 2/3 Manifesto Organization Project level focus focus 2
  • Fundamental challenge - measurability People Engineering 3
  • Genrich Altshuller scanned 400,000 patentdescriptions, and found that only 2% were reallynew. This means, 98% of all new problems canbe solved using previous experience/learning(s). 4
  • 5
  • “. . . .Yo u r hands can’t Structural hit what application profile Codestructure Test case adequacy your eyes can’t s e e … . .” Requirements structure Muhammad Ali 6
  • Typical Lifecycle in Collabera System Requirem Architectu Design & Unit /Functiona ents re Coding Testing l Testing Requirements & Continuous Integration & IterationArchitecture Baseline Releases 7
  • 8
  • 9
  • Can ‘defect prone’ tendency be isolated?• A study on eclipse (published in PROMISE 2007) – Defects are mapped to less than 15% of files• Study on Firefox – Security issues are mapped a low % of code (predominantly java script interpreter)• Publication from CAST – In a US based bank around 30% defects in tests are attributed to identifiable poor code structures 10
  • The problem of plenty…Cyclomatic % comment Lines Density of comment Violationscomplexity lines%Branch Java NCSS Public undocumented Complexity API distribution byStatements methodDepth of Npath Complexity Duplicated linesInheritance Duplicated blocks ComplexityCalls/method Class Fan Out distribution by class Complexity Number of childrenMethods / Class Afferent couplings Class Data Abstraction File dependencies toClass Coupling coupling Lack of cohesion cutMaintainability methodsIndex Boolean Expression Package dependencies complexity to cut 11
  • Influence ofSIT with engineering metrics Correlating complexity attribute II % Branches Block Depth % Branches Block Depth Cyclomatic Complexity Max Cyclomatic Complexity 12 Bridging the eagle’s eye and worm’s view Slide 12
  • Composite parameter analysis Study from European university Number of Class vs SIT defects 2% 1% 1% 4%  Key parameters measured  Cyclomatic complexity/LOC  No. of methods/class  No. of Calls/method 92%  LOC/method8% of classes is contributing to 100% of SIT defects 13
  • Toxicity Analysis Correlates to AT & SIT defectsDetailed study of the data shows most of the SIT & AT defects are occurring amongst the top four Java classes shown in the sample data above which have highly toxic code with high method length 14
  • UC complexity v/s cyclomatic complexity 2.3.47.2 2.3.41.2 2.3.42.2 2.3.43.2 2.3.44.2 2.3.13.22.3.15.2 2.3.48.2 2.3.11.2 2.3.23.2 2.3.20.2 2.3.1.2 2.3.19.2 2.3.20.2 2.3.30.2 2.3.32.2 2.3.37.22.3.16.2 2.3.25.2 2.3.49.2 2.3.38.2 2.3.33.2 2.3.36.2 2.3.4.2 2.3.5.2 2.3.26.2 2.3.2.2 2.3.50.22.3.17.2 2.3.39.2 2.3.34.2 2.3.52.2 2.3.6.2 2.3.9.2 2.3.27.2 2.3.7.2 2.3.45.22.3.18.2 2.3.40.2 2.3.35.2 2.3.12.2 2.3.10.2 2.3.53.2 2.3.10.12.3.22.2 2.3.46.2 15
  • See code akin to a city map... 16
  • Developer’s Structural Analysis Kit Parameters Tools Process• Max /Avg. Cyclomatic • Source monitor • Integration to build tools Complexity • PMD • Prior to code review• Methods Per Class • Checkstyle • Analysis before release• Avg Statements Per Method • iPlasma & Code city• % Branch statements • Sonar• Max Block Depth• Cyclomatic complexity• No. of Calls/method• LOC/method• LOC/Program• Fan out• Data abstraction coupling 17
  • Shifting to the better – Project level 18
  • Shifting to the better – Org level1816141210 Dec-108 Dec-116420 Max Code Methods per Statement Branches % Max Block Complexity Class per Method Depth 19
  • Improved Pre-SIT Detection Dec-09 Dec-11 Till Date 20
  • Shift in defect distributionRequirements & Code Review Unit Test System Test Post Release Design review Pre Post 21
  • Customer Satisfaction Overall Engagement Level ViewEngagement Planning Engagement Execution Engagement Results People Overall 2010 22
  • Qualitative Benefits• Objective measures; language of developer• Improve ability to isolate and deal with the defective ones• Improved risk management and transparency 23
  • Thank youMosesraj R - (mosesrajr@collabera.com) 24