Thursday, February 14, 2008

Software Architecture Quality Attributes

Following on to my previous blog-entry about Software Architecture Views and Perspectives, the book "Software Architecture in Practice" also describes a method called Attribute-Driven Design or ADD. This is not yet-another-design-method like BDD or TDD. ADD is concerned software architectural design (so it's at the "architecture-level" rather than what we might normally think of as the "design-level").

ADD is concerned with explicitly identifying the desired quality attributes of an architecture. Many of us know that simply implementing the (functional) requirements correctly is just the beginning of any good design, and possibly not even the most important attribute of the design. In addition to other attributes like security or availability, there are also attributes like modifiability of an architecture. And it is often these attributes that, if attained, are the true indication of whether or not we've done a good job.


Some of the more commonly desired quality attributes are:
  • Availability
  • Modifiability
  • Performance
  • Security
  • Testability
  • Usability
Many of us have also often had difficulty trying to explain to management the importance of things like "refactoring" and what that modifiability gives us in return. ADD makes such quality attributes an explicit goal of the architecture design process. One of the first things it asks us to do is the necessary homework (research and interviews) to analyze and identify what are the desired quality attributes for our architecture and its stakeholders. It also defines use-case-like entities called Quality Attribute Scenarios, which is a way of expressing such non-functional requirements as an explicit use-case (which can then have an associated business-value).

ADD also explicitly mentions the use of patterns and tactics as part of its methodology for achieving quality attributes and making design tradeoffs (quality attributes are often the "forces" for a pattern). For each of the common quality attributes above, it identifies a taxonomy of common tactics and patterns used to make good tradeoff decisions for particular aspects of the design.

Although it look s a bit heavyweight, ADD looks promising in its use of patterns and tactics and recursive/iterative nature. But what I like most about it is that fact that it makes explicit the kinds of quality attributes and their non-functional use-cases or "stories" which can then have business value/priority associated with it, and thereby justify the existence of activities that help realize those attributes of the system.

For some more information on ADD, see the following:
Now I want to ask the question of applying this same idea to software processes and software process architecture: Seems to me that in Agile development, we're really not anti-process, but there are some really important things (quality attributes of a process?) that we feel are often left out to pasture by a lot of the very formal, CMMI-based processes we witness. Perhaps they're ignoring these important process-design quality attributes? (as embodied in the Agile Manifesto?)

4 comments:

anilkuppa said...

Hi Bradd,
Interesting to read your thoughts.
However, 1 point regarding the following quote of yours
---------------------------------------
--quote
---------------------------------------
Seems to me that in Agile development, we're really not anti-process, but there are some really important things (quality attributes of a process?) that we feel are often left out to pasture by a lot of the very formal, CMMI-based processes we witness. Perhaps they're ignoring these important process-design quality attributes? (as embodied in the Agile Manifesto?)
---------------------------------------
--unquote------------------------------
---------------------------------------

Question / Request for verification/explanation of the above after reading the below link
http://www.sei.cmu.edu/pub/documents/07.reports/07tn002.pdf

Brad Appleton said...

Hi Anilkuppa,

I;m not sure I understand your question. I'm not sure what specific part or parts of the paper you reference you feel relate to what I said. I didn't see any examples of CMMI-based process there. I saw things that described the CMMI framework and principles and concepts.

What I didn't see was one or examples of instances of CMMI-based processes. I think there are lots of things that get left out when folks try to apply CMM or CMMI in their own environment. That includes a great many things that even the CMM/CMMI say is important, but which are all too commonly passed over somehow (despite even CMM/CMMI saying they are important)

Anonymous said...

" But what I look most about it is that fact that it makes explicit the kinds of quality attributes and their non-functional use-cases or "stories" which can then have business value/priority associated with it, and thereby justify the existence of activities that help realize those attributes of the system."

Brad thanks for making me aware of ADD. I wasn't. And should be.

I have campaigned since 'time immemorial' (Software Metrics book 1976 for example) to get quality factors integrated into our development process. There is some progress, but the Agile community is a step backward in that they really manage to ignore qualities, and focus on coding functions etc.

I have a great deal more to say with pragmatic detail at www.gilb.com

Tom@Gib.com

Eudisley Gomes said...

Hi Braad,
I have begun my PhD in Software Architecture Qualities. I read your post and it cleared a lot of ideas in my mind. Now I will read and know more about your Blog.

Thank you so much for your contributions.

Eudis