Software Development Performance Index (SDPI) for measuring Agile Teams performance.
The concept and principle is described in this whitepaper of "The impact of Agile Quantified" (from the Software Engineering Institute, the organization managing the CMMI model:
Mostrar mensagens com a etiqueta Metrics. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Metrics. Mostrar todas as mensagens
terça-feira, 3 de setembro de 2019
sexta-feira, 11 de janeiro de 2019
Maintainability: A promising new metric to track maintainability
A promising new metric to track maintainability - JAXenter
Quoting:
"[A] new metric to track maintainability.
A good metric to measure software maintainability is the holy grail of software metrics. What we would like to achieve with such a metric is that its values more or less conform with the developer’s own judgment of the maintainability of their software system. If that would succeed we could track that metric in our nightly builds and use it as the canary in the coal mine. If values deteriorate it is time for refactoring. We could also use it to compare the health of all the software systems within an organization. And it could help to make decisions about whether it is cheaper to rewrite a piece of software from scratch instead of trying to refactor it.
A good starting point for achieving our goals is to look at metrics for coupling and cyclic dependencies. High coupling will definitely affect maintainability in a negative way. The same is true for big cyclic group of packages/namespaces or classes. Growing cyclic coupling is a good indicator for structural erosion. (...)"
(...)
"Try it yourself
Quoting:
"[A] new metric to track maintainability.
A good metric to measure software maintainability is the holy grail of software metrics. What we would like to achieve with such a metric is that its values more or less conform with the developer’s own judgment of the maintainability of their software system. If that would succeed we could track that metric in our nightly builds and use it as the canary in the coal mine. If values deteriorate it is time for refactoring. We could also use it to compare the health of all the software systems within an organization. And it could help to make decisions about whether it is cheaper to rewrite a piece of software from scratch instead of trying to refactor it.
A good starting point for achieving our goals is to look at metrics for coupling and cyclic dependencies. High coupling will definitely affect maintainability in a negative way. The same is true for big cyclic group of packages/namespaces or classes. Growing cyclic coupling is a good indicator for structural erosion. (...)"
(...)
"Try it yourself
Now you might wonder what this metric would say about the software you are working on. You can use our free tool Sonargraph-Explorer to compute the metric for your system written in Java, C# or Python.
is currently only considered for Java and C#. For systems written in C or C++ you would need our commercial tool Sonargraph-Architect."
terça-feira, 27 de março de 2018
SW Testing: 64 Essential Test Metrics For Measuring Software Quality, Testing & More
Should you measure things while testing? Sure. In order to be able to manage the phase (and the resources available to execute it) it is mandatory... What should you measure? Here is an interesting article on the topic:
Quoting:
"Software testing metrics are a way to measure and monitor your test activities. More importantly, they give insights into your team’s test progress, productivity, and the quality of the system under test. When we ask ourselves “What have we tested?”, metrics will give us better answers than just “we have tested it.” Different teams measure various aspects depending on what they want to track and control or improve.
A metric usually conveys a result or a prediction based on the combination of data.
Result Metrics: metrics that are mostly an absolute measure of an activity/process completed.
Example: Time taken to run a set of test cases in a suite
Predictive Metrics: metrics that are derivatives and act as early warning signs of an unfavorable result.
Example: Defects created vs. Resolved chart shows the rate of defect fixing. This grabs the team’s attention if this rate is slower than the rate desired.
Are you using the right software test metrics? Get answers, best practices and strategies in our 14-page guide to improving your software quality through data and analytics.
Why Test Metrics? Why Should You Care?
The aim of collecting test metrics is to use the data for improving the test process, rather than to just show fancy reports. This includes finding tangible answers to the questions:
The Fundamental Metrics
As a tester, your road to metric creation has to start somewhere. Fundamental QA metrics are a combination of absolute numbers that can then be used to produce derivative metrics.
Absolute Numbers:
Quoting:
"Software testing metrics are a way to measure and monitor your test activities. More importantly, they give insights into your team’s test progress, productivity, and the quality of the system under test. When we ask ourselves “What have we tested?”, metrics will give us better answers than just “we have tested it.” Different teams measure various aspects depending on what they want to track and control or improve.
A metric usually conveys a result or a prediction based on the combination of data.
Result Metrics: metrics that are mostly an absolute measure of an activity/process completed.
Example: Time taken to run a set of test cases in a suite
Predictive Metrics: metrics that are derivatives and act as early warning signs of an unfavorable result.
Example: Defects created vs. Resolved chart shows the rate of defect fixing. This grabs the team’s attention if this rate is slower than the rate desired.
Are you using the right software test metrics? Get answers, best practices and strategies in our 14-page guide to improving your software quality through data and analytics.
Why Test Metrics? Why Should You Care?
The aim of collecting test metrics is to use the data for improving the test process, rather than to just show fancy reports. This includes finding tangible answers to the questions:
- How long will it take to test?
- How much money will it take to test?
- How bad are the bugs?
- How many bugs found were fixed? reopened? closed? deferred?
- How many bugs did the test team did not find?
- How much of the software was tested?
- Will testing be done on time? Can the software be shipped on time?
- How good were the tests? Are we using low-value test cases?
- What is the cost of testing?
- Was the test effort adequate? Could we have fit more testing in this release?
The Fundamental Metrics
As a tester, your road to metric creation has to start somewhere. Fundamental QA metrics are a combination of absolute numbers that can then be used to produce derivative metrics.
Absolute Numbers:
- Total number of test cases
- Number of test cases passed
- Number of test cases failed
- Number of test cases blocked
- Number of defects found
- Number of defects accepted
- Number of defects rejected
- Number of defects deferred
- Number of critical defects
- Number of planned test hours
- Number of actual test hours
- Number of bugs found after shipping"
terça-feira, 13 de março de 2018
Metrics: Three metrics for measuring engineering speed (company / team velocity)
Three metrics for measuring engineering speed - SD Times
Quoting:
"Companies want to deliver high quality software fast, but how fast is fast enough? A recently released report by CircleCI found three important development metrics to predict an organization’s velocity and maturity.
The metrics are:
“Most teams have no idea what speed actually means,” said Jim Rose, CEO of CircleCI. “They are deploying and they are doing it at a rate that feels good to them, but they don’t necessarily know where that stacks up compared to the rest of the market.”
The study looked at a sample of organizations built on the CircleCI’s cloud platform from June 1 to July 31, 2017."
Quoting:
"Companies want to deliver high quality software fast, but how fast is fast enough? A recently released report by CircleCI found three important development metrics to predict an organization’s velocity and maturity.
The metrics are:
- mainline branch stability,
- deploy time and
- deploy frequency.
“Most teams have no idea what speed actually means,” said Jim Rose, CEO of CircleCI. “They are deploying and they are doing it at a rate that feels good to them, but they don’t necessarily know where that stacks up compared to the rest of the market.”
The study looked at a sample of organizations built on the CircleCI’s cloud platform from June 1 to July 31, 2017."
sexta-feira, 19 de maio de 2017
Standards: Automated Function Point (AFP) Specification (from CISQ)
The beauty of standards continues: Now (some years ago, in fact), a standard for counting function points (which is a measure of "size" of software source code):
"AFP provides a standard for automating the popular Function Point measure according to the counting guidelines of the International Function Point User Group (IFPUG). AFP provides a standard for automating the popular Function Point measure according to the counting guidelines of the International Function Point User Group (IFPUG). While there are several automated counters available in the market, there has never been a standard that ensures they are all counting the same way."
OMG has adopted it (in 2013 ;):
"The announcement by OMG of a specification for [AFP] counting should dramatically expand the use of Function Points for sizing IT applications," stated Dr. Bill Curtis, Director, CISQ. "By dramatically reducing the cost of counting and eliminating the problem of inconsistency among manual counters, automated Function Point measurement can become a standard component of the software development and maintenance process."
The standard can be found here: http://www.omg.org/spec/AFP/
Also be sure to check the AEP and the ACQS (also from CISQ)
Also be sure to check the AEP and the ACQS (also from CISQ)
Subscrever:
Mensagens (Atom)