Software Process Architecture Views and Quality Attributes

After my previous postings on Software Architecture Views and Perspectives, Software Architecture Quality Attributes and Software Modifiability Tactics, the question remains as to what all this has to do with Agile processes or with CM.

Well, about a year ago I wrote that Software CM is NOT a Process! ...

Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.

The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.

So now I want to take the perspective of Software CM as an architecture, and I want to consider questions like:

• What are the views and perspectives of an SCM solution architecture?


• How do software architecture quality attributes relate to software CM (or even process) quality attributes?


• What are the quality attributes that, if attained, will make the resulting software CM and/or process environment Agile?

I think I answered the first of these questions in my Dimensions and Views of SCM Architecture. I take the perspective of a 4+2 views model comprising Product, Project, Evolution, Environment, Process (+1), and Enterprise (+2). These views straddle the conceptual and physical aspect of both the content and context of the different kinds of "containers" that are to be managed and interrelated. And the dimensions of SCM complexity that prove most challenging are those of scale and diversity, and of differences between artifact change/creation time and decision binding-time.

The next question involves translating what Availability, Modifiability, Performance, Security, Testability, and Usability mean for a "process" architecture. I'll make an initial stab at that (feedback is encouraged):

• Process Availability might correspond to the availability of the underlying tools and technology that support the process. But it might also need to include both the physical and cognitive "availability" of the process itself. It probably also needs to include the availability of key information (i.e., metrics and reports) to create information radiators, and big visible charts & reports.
  


• Process Modifiability is the ease with which the process itself can be adapted, extended/contracted, perhaps even "refactored", and ultimately improved. Rigid processes can't be changed very rapidly in response to a change in business need or direction.
  


• Process Performance is probably what most closely translates to flow or throughput of software development. (Although for tools and the supporting computing environment, it clearly has the usual meaning there.)
  


• Process Security is ... hmmn, that's a tough one! Would it mean "safety" as in keeping the practitioner safe/secure? Would it mean process quality? Or might it mean the security of the process itself in terms of making sure that only authorized/authenticated persons have access to the knowledge of the system (its requirements, designs, etc.) which may be proprietary/confidential and a significant competitive advantage, and that only those authorized individuals are allowed to execute the roles & workflows that create & modify that system knowledge? Perhaps "security" in this context is all about trust and trustworthiness: How well does the process ensure the trust and integrity of the system and of itself? How well does it foster trust among its practitioners and consumers?
  


• Process Testability might correspond to the ease with which the process and its results can be tracked/reported (transparency) and audited (auditability). Perhaps it is also related to the ease with which parts of the process can be automated.
  


• Process Usability probably has to do with the amount of "friction" the process imposes on the flow/throughput of development. Is it too big? too complex? a poor fit? easy to understand and execute? easy to tell if you did it correctly?

What are the "quality" attributes of an "agile" process? Do they include ALL of the above? what about: adaptive? lean? result-driven (i.e. "working software")? self-organization? iterative? collaborative?

How about some of the traditional "quality" attributes of a CM system: traceability (vs. transparency?), reproduceability? repeatability?