27-09-2012, 12:51 PM
SonarJ White Paper
[attachment=34595]
Point 1 and 2 are explored in broad depth. Point 3 is often underestimated in its importance,
but finally the source code (or what is deployed) does the job and needs to be enhanced and
changed many times over its lifecycle by different developers. To amortize the money
invested into the development of a software system its lifetime should have an adequate
length - the longer it runs the better. For software to be run over a long period of time it must
be possible to test it effectively and make changes to it without enormous extra costs and
risks. Moreover new developers should be able to understand the system within a reasonable
time span.
If we want to achieve this goal we need to keep in mind the internal structure of the software
(its architecture) and some other basis characteristics related to technical quality. A healthy
software basis is needed to manage a development project successfully over a longer period in
time. Documentation is required, but it dos not prevent a software system to perform poorly –
the software itself does not care about documented features (“The software is the design”
[ASD]). Getting the real requirements worked out, which in itself is already difficult and
really important, won’t help if technical quality is not. „Quality is terrible as a control
variable. You can make very short-term gains (days or weeks) by deliberately sacrificing
quality, but the cost –human, business, and technical – is enormous“[EXP].
The software is designed upfront with some basic ideas (a so called ‘architecture vision’)
emerged from a team of architects. Everyone in the team more or less commits to this vision.
Furthermore nobody in the development team would say “let us discard effective testability”,
“lets go and make the code overwhelmingly complex”, “lets go and use 10 different xml
parsers and logging frameworks” - no! Everyone would say “let’s go and make our job easier
by assuring a certain level of technical quality to cope with the real existing complexity –the
implementation of what the end user needs”. So everyone would naturally commit to the
following statement: „For software to be tested effectively, it must be designed from the start
with that goal in mind … Testability, like quality itself, cannot be an afterthought: it must be
considered from the start –before the first line of code is ever written “ [LSD].
Summary
Controlling and managing allowed dependencies between logical components of a software
system is not just an option for medium and large projects –it is a precondition for success.
This assumption is heavily underpinned by relevant literature (see references), research and
practical experience.
Therefore you must have a strategy for dependency management, if you want to make a
medium or large project successful without risking significant schedule or budget overruns.
To implement such a strategy, you need at least one person, which takes responsibility for the
overall structure of the system. In many cases this responsibility will be taken by the leading
software architect. But how can this person enforce a given architectural software structure?
One way would be to use some open source tools (e.g. JDepend) to analyze dependencies and
compute some overall metrics. This approach will work to a certain degree
[attachment=34595]
Point 1 and 2 are explored in broad depth. Point 3 is often underestimated in its importance,
but finally the source code (or what is deployed) does the job and needs to be enhanced and
changed many times over its lifecycle by different developers. To amortize the money
invested into the development of a software system its lifetime should have an adequate
length - the longer it runs the better. For software to be run over a long period of time it must
be possible to test it effectively and make changes to it without enormous extra costs and
risks. Moreover new developers should be able to understand the system within a reasonable
time span.
If we want to achieve this goal we need to keep in mind the internal structure of the software
(its architecture) and some other basis characteristics related to technical quality. A healthy
software basis is needed to manage a development project successfully over a longer period in
time. Documentation is required, but it dos not prevent a software system to perform poorly –
the software itself does not care about documented features (“The software is the design”
[ASD]). Getting the real requirements worked out, which in itself is already difficult and
really important, won’t help if technical quality is not. „Quality is terrible as a control
variable. You can make very short-term gains (days or weeks) by deliberately sacrificing
quality, but the cost –human, business, and technical – is enormous“[EXP].
The software is designed upfront with some basic ideas (a so called ‘architecture vision’)
emerged from a team of architects. Everyone in the team more or less commits to this vision.
Furthermore nobody in the development team would say “let us discard effective testability”,
“lets go and make the code overwhelmingly complex”, “lets go and use 10 different xml
parsers and logging frameworks” - no! Everyone would say “let’s go and make our job easier
by assuring a certain level of technical quality to cope with the real existing complexity –the
implementation of what the end user needs”. So everyone would naturally commit to the
following statement: „For software to be tested effectively, it must be designed from the start
with that goal in mind … Testability, like quality itself, cannot be an afterthought: it must be
considered from the start –before the first line of code is ever written “ [LSD].
Summary
Controlling and managing allowed dependencies between logical components of a software
system is not just an option for medium and large projects –it is a precondition for success.
This assumption is heavily underpinned by relevant literature (see references), research and
practical experience.
Therefore you must have a strategy for dependency management, if you want to make a
medium or large project successful without risking significant schedule or budget overruns.
To implement such a strategy, you need at least one person, which takes responsibility for the
overall structure of the system. In many cases this responsibility will be taken by the leading
software architect. But how can this person enforce a given architectural software structure?
One way would be to use some open source tools (e.g. JDepend) to analyze dependencies and
compute some overall metrics. This approach will work to a certain degree