Quality Attributes

There is a good discussion on quality attributes here – Implementing System Quality Attributes. I have stolen the summary here.

Agility
The ability of a system to both be flexible and undergo change rapidly. [MIT ESD 2001]

Flexibility
The ease with which a system or component can be modified for use in applications or environments, other than those for which it was specifically designed. [Barbacci, 1995]

Interoperability
The ability of two or more systems or components to exchange information and use the information that has been exchanged. [IEEE 1990]

Maintainability

• The aptitude of a system to undergo repair and evolution. [Barbacci, 2003]
• (1) The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. [IEEE Std. 610.12]

Performance
The responsiveness of the system—that is, the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time, or by the amount of time that it takes to complete a transaction with the system. [Bass, 1998]

Reliability
The ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. [Bass 1998]

Reusability
The degree to which a software module or other work product can be used in more than one computing program or software system. This is typically in the form of reusing software that is an encapsulated unit of functionality. [IEEE 1990]

Scalability
The ability to maintain or improve performance while system demand increases.

Security
A measure of the system’s ability to resist unauthorized attempts at usage and denial of service, while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. [Bass, 1998]

Supportability
The ease with which a software system can be operationally maintained.

Testability
The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. [ IEEE 1990]

Usability

• The measure of a user’s ability to utilize a system effectively. [Clements, 2002]
• The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. [IEEE Std. 610.12]
• A measure of how well users can take advantage of some system functionality. Usability is different from utility, which is a measure of whether that functionality does what is needed. [Barbacci, 2003]

We’ll look into each one of these as we go along.

What does a software architect do?

Rather wasting time writing something on my own which will be substandard, I’ll point you to Simon Brown’s excellent content on Coding the Architecture

You can read more about this here

The role of a hands on software architect

Special thanks to Prakash for the link

Software Architecture

“[Software] Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” – IEEE

My understanding of the definition:

Organization of a system into subsystems

• Functional organization / decomposition

Example: business / functional modules. In an Retail System it could the the Store, Order Processing, Shipping, Warehouse management, Payment Processing etc.

• Implementation based organization / decomposition

Example: layers, tiers

Decisions which are hard to change at a later point in the lifetime of the system presented as strategies.

Example of decisions include (but are not limited to):

• Where (between what layers) can an optional tier boundary be introduced.
• How do we handle transactions
• How do we handle exceptions and errors
• How do we handle instrumentation
• How do we handle / design the system for non-functional requirements a.k.a. quality attributes (security, performance, scalability etc)

Layers, Tiers, Quality Attributes, more to come. Stay tuned…

PS: I work in Business Applications and so you can see the writings biased on that side of things.

An experiment

I’ll be posting a lot of entries in the coming days, months, years on an experimental basis here. It will be more of a collection of literature that I have read in the past.

“It is easy to sound smart when you are parroting smart people” – Randy Pausch, The Last Lecture.

So when I sound smart you know why. When I do not (when I sound dumb) you can see that I am writing something on my own.

I’ll give credits where they are due and please point it to me when I miss giving the credit to where it is due.

Thank You

On Consulting

Can you think of anything less improbable [sic] than taking the world’s most successful firms, leaders in their businesses, and hiring people just fresh out of school and telling them how to run their businesses, and they are willing to pay millions of dollars for their advice? – Bruce Henderson

via http://online.wsj.com/article/SB10001424052970204313604574329183846704634.html

via http://management.curiouscatblog.net/2009/08/06/bogus-theories-bad-for-business/