Cloud as a Story - Vunvulea Radu

This days I had some time to play with NDepend and I was impress to see what kind of information you can extract from your current project. There are a lot of metrics that can be extracted from NDepend, when you analyze your project for the first time with NDepend you will not know on what metrics you take into account – there are so many (and this is good). Code Quality and Code Metrics  NDepend is not only calculate different metrics of your code but is able to give you feedback related to them. Different combination of metrics will trigger alerts and warnings. This is very useful when you want to improve your code and you want to go directly to the problem. Basically, NDepend has a predefined list of code qualities attributes that are run over your solution. For example, NDepend is able to detect and display the methods that are to complex (has cyclomatic complexity to high – over 40). In this cases a critical alert will be displayed.  Another nice code quality rule ...

Last week’s I had the opportunity to configure Sonar for a pretty big project. The application has over 3M lines of code and use different languages and technologies, from C# and Silverlight to JavaScript, C++ and embedded applications. The main scope was to see if we can configure Sonar for this project. We decided at this step to exclude the embedded part of the application for Sonar. This was decided because of the time limitations. I’m almost sure that we can configure Sonar for embedded part without any kind of problems. In the next part of the post I will present different issues that I encountered during Sonar configuration. Where to store custom configuration? Sonar gives you the possibility to specify different custom configuration at server level or on each project that is analyzed. Personally I prefer to have all the configuration (tools path location, unit tests projects pattern and so on) at project level – in sonar-project.properties file. For me is more easily to ...

In the last period of time I have been involved in different projects where quality is extremely important. Because of this we started to look around us and search for tools that can measure the quality of software (of the code itself) – software/code metrics. This is why, this year I had some posts related to Sonar and different software metrics. Personally I looked on different tools that can measure this metrics and can share the content in a consistent and easy way. Until now, my search stopped over Sonar – that is a great tool, but can give you headaches when you need to configure it. There are many companies that tracks the software metrics. This is a very good think. But in the same time I observed that this companies usually push only one tool that can be used to measure this metrics – THE TOOL. For them it is not important what kind of language you use for developing or if the given tool suites your needs. For them that tool is a standard and you need to obey. Is this a g...

In one of my latest post we talk about Mean Time Between Failure software metric (MTBF) . We saw that this metrics is very useful when we need to make an idea about what is the quality of our software that is in production. Today we will talk about LCOM4 (Lack of Cohesion of Methods). The main information that we receive from this metric is the number of responsibilities (functions) that a class has. When we have a low cohesion means that we have a bad design, with classes that are very complex. This can also indicates that the class are complex, very big and can produce a lot of bugs. When we have a high cohesion that we have a very good encapsulation, each class do only one thing but it does very good. Normally, this class are not very long, the complexity of them is not very high and are simple to understand and work with. The only problem that can happen with this class is related to testing. Sometimes, this class are pretty hard to test because the coupling level between them i...

MTBF - Meantime between failure In today post I would like to talk about a software metric that can give us information related to the quality of our product and how stable it is – Meantime Between Failure. This metric measure the time interval between the moment when a failure was fixed (and the system is stable) until the moment when a new failure is detected. We could say that this metric measure the time interval when the system is up and running. Using this metric, we can obtain to important information related to our system: How stable our system is When the next failure will occur I think that the second point is pretty interesting, especially when we have a system in production. Theoretically, MTBF could tell to the operational and maintenance team when next fail over will have – in this way they can be prepared for it. MTBF can be calculated in different ways, the most simple formulate for it is the sum of all the time intervals when the system didn’t had a...