NDepend is a static analysis tool for .NET code that makes life easier for developers. The product comes with a slew of performance metrics to make your code cleaner, more flexibility, and easier to maintain. Ndepend makes adhering to SOLID Principles easy to measure and communicate. It fully integrates with Visual Studio, but has it's own GUI.
But the number one reason and feature why I would by this product and this product alone is the ability to estimate total work effort (credit) and technical debt. This is essential for any developer to communicate to team and management budgetary requirements. Always a tough task. All developers have been under the gun, and stuck with this repeated question;
Work effort (credit and debt) is bases on the "controversial" measurement of LOC (Line of Code) produced per day.
LOC is "controversial" because is no definite clear picture of how to count number of lines because it depends on the length of code which is hard to measure (compact one liners, vs beautified code) and productivity ratios of the code expressability is different in different languages. NDepend mitigates this by using logical LOC of code instead of a physical LOC, which is independent from the language. Still LOC depends on complexity and functionality.
NDepend measures complexity in a number of ways;
NbLinesOfCode, NbLinesOfComment, PercentageComment, NbILInstructions, NbMethods, NbFields, NbInterfacesImplemented, Type level, Type rank,Afferent coupling at type level (TypeCa), Efferent coupling at type level (TypeCe), Lack of Cohesion Of Methods (LCOM), Lack of Cohesion Of Methods Henderson-Sellers (LCOM HS), Code Source Cyclomatic Complexity, IL Cyclomatic Complexity (ILCC), Size of instance, Association Between Class (ABC) Number of Children (NOC), Depth of Inheritance Tree (DIT), PercentageCoverage, NbLinesOfCodeCovered, NbLinesOfCodeNotCovered
But back to work effort, NDepend measures "Estimated Dev Effort" (credit) the total time the project development effort and "Techinal Debt". "Technical Debt" is the work effort required to fix all issues based on slue of best practice rules for a specific duration. The rules and duration are configurable (see next image below).
NDepend allows to you set your own work effort estimates, based on your project as it stabilizes.
The default value, out of the gate is 18 man-days which represents an average of 55 new lines of code (LOC), 100% covered by unit-tests, written per day, per developer.
In NDepend, the setting called "SQALE Debt Ratio". "SQALE Debt Ratio" is the estimated number of man-days to develop 1,000 logical lines of code setting. This estimated setting also needs to take into account the cost of writing unit-tests.
"SQALE" is short for Software Quality Assessment based on Lifecycle Expectations is a method to support the evaluation of a software application source code. It is a generic method, independent of the language and source code analysis tools.
If you are starting a new project, then the default NDepend of 55 new lines of code (LOC) per day, per developer maybe bang on as productivity tends to decrease as the project grows larger and team grows.
Here are some ballpark starter LOC estimates to get you started;
But the number one reason and feature why I would by this product and this product alone is the ability to estimate total work effort (credit) and technical debt. This is essential for any developer to communicate to team and management budgetary requirements. Always a tough task. All developers have been under the gun, and stuck with this repeated question;
"Well how much time is this going to take?" Answer this question easily with NDepend.
Work effort (credit and debt) is bases on the "controversial" measurement of LOC (Line of Code) produced per day.
LOC is "controversial" because is no definite clear picture of how to count number of lines because it depends on the length of code which is hard to measure (compact one liners, vs beautified code) and productivity ratios of the code expressability is different in different languages. NDepend mitigates this by using logical LOC of code instead of a physical LOC, which is independent from the language. Still LOC depends on complexity and functionality.
NDepend measures complexity in a number of ways;
NbLinesOfCode, NbLinesOfComment, PercentageComment, NbILInstructions, NbMethods, NbFields, NbInterfacesImplemented, Type level, Type rank,Afferent coupling at type level (TypeCa), Efferent coupling at type level (TypeCe), Lack of Cohesion Of Methods (LCOM), Lack of Cohesion Of Methods Henderson-Sellers (LCOM HS), Code Source Cyclomatic Complexity, IL Cyclomatic Complexity (ILCC), Size of instance, Association Between Class (ABC) Number of Children (NOC), Depth of Inheritance Tree (DIT), PercentageCoverage, NbLinesOfCodeCovered, NbLinesOfCodeNotCovered
But back to work effort, NDepend measures "Estimated Dev Effort" (credit) the total time the project development effort and "Techinal Debt". "Technical Debt" is the work effort required to fix all issues based on slue of best practice rules for a specific duration. The rules and duration are configurable (see next image below).
 |
| Technical Debt of 33 days to fix all issues for this project completely |
NDepend allows to you set your own work effort estimates, based on your project as it stabilizes.
The default value, out of the gate is 18 man-days which represents an average of 55 new lines of code (LOC), 100% covered by unit-tests, written per day, per developer.
In NDepend, the setting called "SQALE Debt Ratio". "SQALE Debt Ratio" is the estimated number of man-days to develop 1,000 logical lines of code setting. This estimated setting also needs to take into account the cost of writing unit-tests.
"SQALE" is short for Software Quality Assessment based on Lifecycle Expectations is a method to support the evaluation of a software application source code. It is a generic method, independent of the language and source code analysis tools.
If you are starting a new project, then the default NDepend of 55 new lines of code (LOC) per day, per developer maybe bang on as productivity tends to decrease as the project grows larger and team grows.
Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever increasing quantity of the calendar time available. When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added. The Mythical Man Month by Fred Brooks
Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever increasing quantity of the calendar time available. When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added. The Mythical Man Month by Fred Brooks
Here are some ballpark starter LOC estimates to get you started;
- Capers Jones measured productivity of around 16 to 38 LOC per day across a range of projects.
- McConnell measured productivity of 20 to 125 LOC per day for small projects (10,000 LOC) through to 1.5 to 25 LOC per day for large projects (10,000,000 LOC).
- Jeff Sutherland, Co-Creator of Scrum measured productivity around 26 LOC per day
Hope you are convinced as I that NDepend tool is worth the buy.
No comments:
Post a Comment