Class notes

IT6602 SOFTWARE ARCHITECTURES L T P C 3 0 0 3
OBJECTIVES:
• Understand software architectural requirements and drivers
• Be exposed to architectural styles and views
• Be familiar with architectures for emerging technologies
UNIT I INTRODUCTION AND ARCHITECTURAL DRIVERS 9
Introduction – What is software architecture? – Standard Definitions – Architectural
structures – Influence of software architecture on organization-both business and technical –
Architecture Business Cycle- Introduction – Functional requirements – Technical constraints
– Quality Attributes.
UNIT II QUALITY ATTRIBUTE WORKSHOP 9
Quality Attribute Workshop – Documenting Quality Attributes – Six part scenarios – Case
studies.
UNIT III ARCHITECTURAL VIEWS 9
Introduction – Standard Definitions for views – Structures and views - Representing views-
available notations – Standard views – 4+1 view of RUP, Siemens 4 views, SEI's
perspectives and views – Case studies
UNIT IV ARCHITECTURAL STYLES 9
Introduction – Data flow styles – Call-return styles – Shared Information styles - Event styles
– Case studies for each style.
UNIT V DOCUMENTING THE ARCHITECTURE 9
Good practices – Documenting the Views using UML – Merits and Demerits of using visual
languages – Need for formal languages - Architectural Description Languages – ACME –
Case studies. Special topics: SOA and Web services – Cloud Computing – Adaptive
structures
OUTCOMES:
Upon Completion of the course, the students will be able to
• Explain influence of software architecture on business and technical activities
• Identify key architectural structures
• Use styles and views to specify architecture
• Design document for a given architecture
TEXT BOOKS:
1. Len Bass, Paul Clements, and Rick Kazman, “Software Architectures Principles and
Practices”, 2 nd Edition, Addison-Wesley, 2003.
2. Anthony J Lattanze, “Architecting Software Intensive System. A Practitioner's Guide”,
Auerbach Publications, 2010.
REFERENCES:
1. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo
Merson, Robert Nord, and Judith Stafford, “Documenting Software Architectures. Views
and Beyond”, 2nd Edition, Addison-Wesley, 2010.
2. Paul Clements, Rick Kazman, and Mark Klein, “Evaluating software architectures:
Methods and case studies. Addison-Wesley, 2001.
3. Rajkumar Buyya, James Broberg, and Andrzej Goscinski, “Cloud Computing. Principles
and Paradigms”, John Wiley & Sons, 2011
4. Mark Hansen, “SOA Using Java Web Services”, Prentice Hall, 2007
5. David Garlan, Bradley Schmerl, and Shang-Wen Cheng, “Software Architecture-Based
SelfAdaptation,” 31-56. Mieso K Denko, Laurence Tianruo Yang, and Yan Zang (eds.),
“Autonomic Computing and Networking”. Springer Verlag, 2009
1

UNIT I
INTRODUCTION AND ARCHITECTURAL DRIVERS
Introduction – What is software architecture? – Standard Definitions – Architectural
structures – Influence of software architecture on organization-both business and technical –
Architecture Business Cycle- Introduction – Functional requirements – Technical constraints
– Quality Attributes.
Introduction
What is software architecture?
What is software architecture and what is not?
Figure 1 : Typical, but uninformative, presentation of a software architecture
Figure 1, taken from a system description for an underwater acoustic simulation, purports to
describe that system's "top-level architecture" and is precisely the kind of diagram most often
displayed to help and explain architecture. Exactly what can we tell from it?
• The system consists of four elements
• Three of the elements— Prop Loss Model (MODP), Reverb Model (MODR), and
Noise Model (MODN)— might have more in common with each other than with the
fourth—Control Process (CP)— because they are positioned next to each other.
• All of the elements apparently have some sort of relationship with each other, since
the diagram is fully connected.
Is this architecture? What can we not tell from the diagram?
 What is the nature of the elements?
What is the significance of their separation? Do they run on separate processors? Do they run
at separate times? Do the elements consist of processes, programs, or both? Do they represent
ways in which the project labor will be divided, or do they convey a sense of runtime
separation? Are they objects, tasks, functions, processes, distributed programs, or something
else?
 What are the responsibilities of the elements?
What is it they do? What is their function in the system?
 What is the significance of the connections?
Do the connections mean that the elements communicate with each other, control each other,
send data to each other, use each other, invoke each other, synchronize with each other, share
some information-hiding secret with each other, or some combination of these or other
2

relations? What are the mechanisms for the communication? What information flows across
the mechanisms, whatever they may be?
 What is the significance of the layout?
Why is CP on a separate level? Does it call the other three elements, and are the others not
allowed to call it? Does it contain the ot her three in an implementation unit sense? Or is there
simply no room to put all four elements on the same row in the diagram?
This diagram does not show software architecture. We now define what does constitute
software architecture:
Standard Definitions
1. "The software architecture of a program or computing system is the structure or
structures of the system, which comprise software components, the externally
visible properties of those components, and the relationships among them."
2. Software Architecture is the global organization of a software system, including
• the division of software into subsystems/components,
• policies according to which these subsystems interact,
• the definition of their interfaces.
3. “Fundamental concepts or properties of a system in its environment embodied in its
elements, relationships, and in the principles of its design and evolution.”
Let's look at some of the implications of this definition in more detail.
Architecture defines software elements. The definition makes clear that systems can
and do comprise more than one structure and that no one structure can irrefutably claim to be
the architecture. The definition implies that every computing system with software has
software architecture because every system can be shown to comprise elements and the
relations among them.
The behavior of each element is part of the architecture in so far as that behavior can
be observed or discerned from the point of view of another element. Such behavior is what
allows elements to interact with each other, which is clearly part of the architecture.
The definition is indifferent as to whether the architecture for a system is a good one
or a bad one, meaning that it will allow or prevent the system from meeting its behavioral,
performance and lifecycle requirements.
The study of software architecture is an attempt to abstract the commonalities inherent
in system design, and as such it must account for a wide range of activities, concepts,
methods, approaches, and results.
Architecture is high-level design. Other tasks associated with design are not architectural,
such as deciding on important data structures that will be encapsulated.
Architecture is the overall structure of the system. The different structures provide the
critical engineering leverage points to imbue a system with the quality attributes that will
render it a success or failure. The multiplicity of structures in an architecture lies at the heart
of the concept.
Architecture is the structure of the components of a program or system, their
interrelationships, and the principles and guidelines governing their design and evolution
over time. Any system has an architecture that can be discovered and analyzed independently
of any knowledge of the process by which the architecture was designed or evolved.
Architecture is components and connectors. Connectors imply a runtime mechanism for
transferring control and data around a system. When we speak of "relationships" among
elements, we intend to capture both runtime and non-runtime relationships.
3

ARCHITECTURAL PATTERNS, REFERENCE MODELS & REFERENCE
ARCHITECTURES
An architectural pattern is a description of element and relation types together with a set of
constraints on how they may be used.For ex: client-server is a common architectural pattern.
Client and server are two element types, and their coordination is described in terms of the
protocol that the server uses to communicate with each of its clients. Together with data flow
between the pieces.
A reference model is a standard decomposition of a known problem into parts that
cooperatively solve the problem.
Reference architecture is a reference model mapped onto software elements (that
cooperatively implement the functionality defined in the reference model) and the data flows
between them. Whereas a reference model divides the functionality, A reference architecture
is the mapping of that functionality onto a system decomposition.
Reference models, architectural patterns, and reference architectures are not architectures;they
are useful concepts that capture elements of an architecture. Each is the outcome of early
design decisions. The relationship among these design elements is shown in Figure 2.2. A
software architect must design a system that provides concurrency, portability, modifiability,
usability, security, and the like, and that reflects consideration of the tradeoffs among these
needs.
4

WHY IS SOFTWARE ARCHITECTURE IMPORTANT?
There are fundamentally three reasons for software architecture’s importance from a
technical perspective.
 Communication among stakeholders: software architecture represents a common
abstraction of a system that most if not all of the system’s stakeholders can use as a basis for
mutual understanding, negotiation, consensus and communication.
 Early design decisions: Software architecture manifests the earliest design decisions about
a system with respect to the system's remaining development, its deployment, and its
maintenance life. It is the earliest point at which design decisions governing the system to be
built can be analyzed.
 Transferable abstraction of a system: software architecture model is transferable across
systems. It can be applied to other systems exhibiting similar quality attribute and functional
attribute and functional requirements and can promote large-scale re-use.
ARCHITECTURE IS THE VEHICLE FOR STAKEHOLDER COMMUNICATION
 Each stakeholder of a software system – customer, user, project manager, coder, tester and
so on - is concerned with different system characteristics that are affected by the architecture.
 For ex. The user is concerned that the system is reliable and available when needed; the
customer is concerned that the architecture can be implemented on schedule and to budget;
the manager is worried that the architecture will allow teams to work largely independently,
interacting in disciplined and controlled ways.
 Architecture provides a common language in which different concerns can be expressed,
negotiated, and resolved at a level that is intellectually manageable even for large, complex
systems.
ARCHITECTURE MANIFESTS THE EARLIEST SET OF DESIGNDECISIONS
Software architecture represents a system’s earliest set of design decisions. These early
decisions are the most difficult to get correct and the hardest to change later in the
development process, and they have the most far-reaching effects.
 The architecture defines constraints on implementation
o This means that the implementation must be divided into the prescribed elements, the
elements must interact with each other in the prescribed fashion, and each element must
fulfill its responsibility to the others as dictated by the architecture.
 The architecture dictates organizational structure
o The normal method for dividing up the labor in a large system is to assign different groups
different portions of the system to construct. This is called the work breakdown structure of a
system.
The architecture inhibits or enables a system’s quality attributes
o Whether a system will be able to exhibit its desired (or required) quality attributes is
substantially determined by its architecture.
o However, the architecture alone cannot guarantee functionality or quality.
o Decisions at all stages of the life cycle— from high-level design to coding and
implementation —affect system quality.
o Quality is not completely a function of architectural design. To ensure quality, a good
architecture is necessary, but not sufficient.
 Predicting system qualities by studying the architecture
o Architecture evaluation techniques such as the architecture tradeoff analysis method
support top-down insight into the attributes of software product quality that is made possible
(and constrained) by software architectures.
 The architecture makes it easier to reason about and manage change
o Software systems change over their lifetimes.
o Every architecture partitions possible changes into three categories: local, nonlocal, and
5

architectural.
o A local change can be accomplished by modifying a single element.
o A nonlocal change requires multiple element modifications but leaves the underlying
architectural approach intact.
 The architecture helps in evolutionary prototyping
o The system is executable early in the product's life cycle. Its fidelity increases as prototype
parts are replaced by complete versions of the software.
o A special case of having the system executable early is that potential performance problems
can be identified early in the product’s life cycle.
 The architecture enables more accurate cost and schedule estimates
o Cost and schedule estimates are an important management tool to enable the manager to
acquire the necessary resources and to understand whether a project is in trouble.
ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL
The earlier in the life cycle re-use is applied, the greater the benefit that can be achieved.
While code reuse is beneficial, re-use at the architectural level provides tremendous
leverage for systems with similar requirements.
 Software product lines share a common architecture
A software product line or family is a set of software-intensive systems sharing a common,
managed set of features that satisfy the specific needs of a particular market segment or
mission and that are developed from a common set of core assets in a prescribed way.
 Systems can be built using large. Externally developed elements
Whereas earlier software paradigms focused on programming as the prime activity, with
progress measured in lines of code, architecture-based development often focuses on
composing or assembling elements that are likely to have been developed separately, even
independently, from each other.
Less is more: it pays to restrict the vocabulary of design alternatives
We wish to minimize the design complexity of the system we are building. Advantages to
this approach include enhanced reusemore regular and simpler designs that are more easily
understood and communicated, more capable analysis, shorter selection time, and greater
interoperability.
 An architecture permits template based development
An architecture embodies design decisions about how elements interact that, while reflected
in each element's implementation, can be localized and written just once.
Templates can be used to capture in one place the interelement interaction mechanisms.
 An architecture can be the basis for training
The architecture, including a description of how elements interact to carry out the required
behavior, can serve as the introduction to the system for new project members.
ARCHITECTURAL STRUCTURES AND VIEWS
Architectural structures can by and large be divided into three groups, depending on the
broad nature of the elements they show.
 Module structures.
Here the elements are modules, which are units of implementation. Modules represent a
code-based way of considering the system. They are assigned areas of functional
responsibility. There is less emphasis on how the resulting software manifests itself at
runtime. Module structures allow us to answer questions such as what is the primary
functional responsibility assigned to each module? What other software elements is a module
allowed to use? What other software does it actually use? What modules are related to other
modules by generalization or specialization (i.e., inheritance) relationships?
 Component-and-connector structures.
6

Here the elements are runtime components (which are the principal units of computation) and
connectors (which are the communication vehicles among components).
Component-and-connector structures help answer questions such as What are the major
executing components and how do they interact? What are the major shared data stores?
Which parts of the system are replicated? How does data progress through the system? What
parts of the system can run in parallel? How can the system's structure change as it executes?
 Allocation structures.
Allocation structures show the relationship between the software elements and the elements
in one or more external environments in which the software is created and executed. They
answer questions such as what processor does each software element execute on? In what
files is each element stored during development, testing, and system building? What is the
assignment of software elements to development teams?
SOFTWARE STRUCTURES
 Module
Module-based structures include the following structures.
 Decomposition: The units are modules related to each other by the "is a sub module of "
relation, showing how larger modules are decomposed into smaller ones recursively until
they are small enough to be easily understood.
 Uses: The units are related by the uses relation. One unit uses another if the correctness of
the first requires the presence of a correct version (as opposed to a stub) of the second.
 Layered: Layers are often designed as abstractions (virtual machines) that hide
implementation specifics below from the layers above, engendering portability.
 Class or generalization: The class structure allows us to reason about re-use and the
incremental addition of functionality.
 Component-and-connector
Component-and-connector structures include the following structures
 Process or communicating processes: The units here are processes or threads that are
connected with each other by communication, synchronization, and/or exclusion operations.
 Concurrency: The concurrency structure is used early in design to identify the
requirements for managing the issues associated with concurrent execution.
 Shared data or repository: This structure comprises components and connectors that
create, store, and access persistent data
 Client-server: This is useful for separation of concerns (supporting modifiability), for
physical distribution, and for load balancing (supporting runtime performance).
 Allocation
Allocation structures include the following structures
 Deployment: This view allows an engineer to reason about performance, data integrity,
availability, and security
7

 Implementation: This is critical for the management of development activities and builds
processes.
 Work assignment: This structure assigns responsibility for implementing and integrating
the modules to the appropriate development teams.
RELATING STRUCTURES TO EACH OTHER
Each of these structures provides a different perspective and design handle on a system, and
each is valid and useful in its own right. In general, mappings between structures are many to
many. Individual structures bring with them the power to manipulate one or more quality
attributes. They represent a powerful separation-of- concerns approach for creating the
architecture.
WHICH STRUCTURES TO CHOOSE?
Kruchten's four views follow:
 Logical. The elements are "key abstractions," which are manifested in the object-oriented
world as objects or object classes. This is a module view.
 Process. This view addresses concurrency and distribution of functionality. It is a
component-and connector view.
 Development. This view shows the organization of software modules, libraries,
subsystems, and units of development. It is an allocation view, mapping software to the
development environment.
 Physical. This view maps other elements onto processing and communication nodes and is
also an allocation view
THEARCHITECTURE BUSINESS CYCLE
The software architecture of a program or computing system is the structure or structures of
the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.
Software architecture is a result of technical, business and social influences. Its existence in
turn affects the technical, business and social environments that subsequently influence future
architectures.
We call this cycle of influences, from environment to the architecture and back to the
environment, the Architecture Business Cycle (ABC). This chapter introduces the ABC in
detail and examines the following:
 How organizational goals influence requirements and development strategy.
 How requirements lead to architecture.
 How architectures are analyzed.
 How architectures yield systems that suggest new organizational capabilities and requirements.
WHERE DO ARCHITECTURES COME FROM?
An architecture is the result of a set of business and technical decisions. There are many
influences at work in its design, and the realization of these influences will change depending
on the environment in which the architecture is required to perform. Even with the same
requirements, hardware, support software, and human resources available, an architect
designing a system today is likely to design a different system than might have been designed
five years ago.
ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS
 Many people and organizations interested in the construction of a software system are
referred to as stakeholders. E.g. customers, end users, developers, project manager etc.
 Figure below shows the architect receiving helpful stakeholder “suggestions”.
8

Having an acceptable system involves properties such as performance, reliability,availability,
platform compatibility, memory utilization, network usage, security, modifiability, usability,
and interoperability with other systems as well as behavior.
 The underlying problem, of course, is that each stakeholder has different concerns and
goals, some of which may be contradictory.
 the reality is that the architect often has to fill in the blanks and mediate the conflicts.
ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATIONS.
 Architecture is influenced by the structure or nature of the development organization.
 There are three classes of influence that come from the developing organizations:
immediate business, long term business and organizational structure.
 An organization may have an immediate business investment in certain assets, such as
existing architectures and the products based on them.
 An organization may wish to make a long-term strategic goals and may review the
proposed system as one means of financing and extending that infrastructure.
 The organizational structure can shape the software architecture.
ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND
EXPERIENCE OF THE ARCHITECTS.
 If the architects for a system have had good results using a particular architectural
approach, such as distributed objects or implicit invocation, chances are that they will
try that same approach on a new development effort.
 Conversely, if their prior experience with this approach was disastrous, the architects may
be reluctant to try it again.
 Architectural choices may also come from an architect’s education and training, exposure
to successful architectural patterns, or exposure to systems that have worked particularly
poorly or particularly well.
9

 The architects may also wish to experiment with an architectural pattern or technique
learned from a book or a course.
ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT
 A special case of the architect’s background and experience is reflected by the technical
environment.
 The environment that is current when an architecture is designed will influence that
architecture.
 It might include standard industry practices or software engineering prevalent in the
architect’s professional community.
RAMIFICATIONS OF INFLUENCES ON ARCHITECTURE
 The influences on the architect, and hence on the architecture, are shown in Figure 1.3.
Influences on architecture come from a wide variety of sources. Some are only implied, while
others are explicitly in conflict.
 Architects need to know and understand the nature, source, and priority of constraints on
the project as early as possible.
 Therefore, they must identify and actively engage the stakeholders to solicit their needs
and expectations.
 Architects are influenced by the requirements for the product as derived from its
stakeholders, the structure and goals of the developing organization, the available technical
environment, and their own background and experience.
THE ARCHITECTURE AFFECTS THE FACTORS THAT INFLUENCE THEM
 Relationships among business goals, product requirements, architects experience,
architectures and fielded systems form a cycle with feedback loops that a business can
manage.
 A business manages this cycle to handle growth, to expand its enterprise area, and to take
advantage of previous investments in architecture and system building.
10

 Figure 1.4 shows the feedback loops. Some of the feedback comes from the architecture
itself, and some comes from the system built from it.
1) The architecture affects the structure of the developing organization. Architecture
prescribes a structure for a system it particularly prescribes the units of software that must be
implemented and integrated to form the system. Teams are formed for individual software
units; and the development, test, and integration activities around the units. Likewise,
schedules and budgets allocate resources in chunks corresponding to the units. Teams
become embedded in the organization’s structure. This is feedback from the architecture to
the developing organization.
2) The architecture can affect the goals of the developing organization. A successful system
built from it can enable a company to establish a foothold in a particular market area.The
architecture can provide opportunities for the efficient production and deployment of the
similar systems, and the organization may adjust its goals to take advantage of its newfound
expertise to plumb the market. This is feedback from the system to the developing
organization and the systems it builds.
3) The architecture can affect customer requirements for the next system by giving the
customer the opportunity to receive a system in a more reliable, timely and economical
manner than if the subsequent system were to be built from scratch.
4) The process of system building will affect the architect’s experience with subsequent
systems by adding to the corporate experience base.
5) A few systems will influence and actually change the software engineering culture. i.e,
The technical environment in which system builders operate and learn.
SOFTWARE PROCESSES AND THE ARCHITECTURE BUSINESS CYCLE
Software process is the term given to the organization, ritualization and management of
software development activities.The various activities involved in creating software
architecture are:
11

 Creating the business case for the system
o It is an important step in creating and constraining any future requirements.
o How much should the product cost?
o What is its targeted market?
o What is its targeted time to market?
o Will it need to interface with other systems?
o Are there system limitations that it must work within?
o These are all the questions that must involve the system’s architects.
o They cannot be decided solely by an architect, but if an architect is not consulted in the
creation of the business case, it may be impossible to achieve the business goals.
 Understanding the requirements
o There are a variety of techniques for eliciting requirements from the stakeholders.
o For ex:
 Object oriented analysis uses scenarios, or “use cases” to embody requirements.
 Safety-critical systems use more rigorous approaches, such as finite-state-machine models
or formal specification languages.
o Another technique that helps us understand requirements is the creation of prototypes.
o Regardless of the technique used to elicit the requirements, the desired qualities of the
system to be constructed determine the shape of its structure.
 Creating or selecting the architecture
o In the landmark book The Mythical Man-Month, Fred Brooks argues forcefully and
eloquently that conceptual integrity is the key to sound system design and that conceptual
integrity can only be had by a small number of minds coming together to design the system's
architecture.
 Documenting and communicating the architecture
o For the architecture to be effective as the backbone of the project’s design, it must be
communicated clearly and unambiguously to all of the stakeholders.
o Developers must understand the work assignments it requires of them, testers must
understand the task structure it imposes on them, management must understand the
scheduling implications it suggests and so forth.
 Analyzing or evaluating the architecture
o Choosing among multiple competing designs in a rational way is one of the architect’s
greatest challenges.
o Evaluating an architecture for the qualities that it supports is essential to ensuring that the
system constructed from that architecture satisfies its stakeholders needs.
o Use scenario-based techniques or architecture tradeoff analysis method (ATAM) or cost
benefit analysis method (CBAM).
 Implementing the system based on the architecture
o This activity is concerned with keeping the developers faithful to the structures and
interaction protocols constrained by the architecture.
o Having an explicit and well-communicated architecture is the first step toward ensuring
architectural conformance.
 Ensuring that the implementation conforms to the architecture
o Finally, when an architecture is created and used, it goes into a maintenance phase.
o Constant vigilance is required to ensure that the actual architecture and its representation
remain to each other during this phase.
WHAT MAK ES A “GOOD” ARCHITCTURE?
Given the same technical requirements for a system, two different architects in different
organizations will produce different architectures, how can we determine if either one of
12

them is the right one?We divide our observations into two clusters: process recommendations
and product (or structural) recommendations.
Process recommendations are as follows:
 The architecture should be the product of a single architect or a small group of architects
with an identified leader.
 The architect (or architecture team) should have the functional requirements for the system
and an articulated, prioritized list of quality attributes that the architecture is expected to
satisfy.
 The architecture should be well documented, with at least one static view and one dynamic
view, using an agreed-on notation that all stakeholders can understand with a minimum of
effort.
 The architecture should be circulated to the system’s stakeholders, who should be actively
involved in.
 The architecture should be analyzed for applicable quantitative measures (such as
maximum throughput) and formally evaluated for quality attributes before it is too late to
make changes to it.
 The architecture should lend itself to incremental implementation via the creation of a
“skeletal” system in which the communication paths are exercised but which at first has
minimal functionality. This skeletal system can then be used to “grow” the system
incrementally, easing the integration and testing efforts.
 The architecture should result in a specific (and small) set of resource contention areas, the
resolution of which is clearly specified, circulated and maintained.
Product (structural) recommendations are as follows:
The architecture should feature well-defined modules whose functional responsibilities are
allocated on the principles of information hiding and separation of concerns.
 Each module should have a well-defined interface that encapsulates or “hides” changeable
aspects from other software that uses its facilities. These interfaces should allow their
respective development teams to work largely independent of each other.
 Quality attributes should be achieved using well-known architectural tactics specific to
each attribute.
 The architecture should never depend on a particular version of a commercial product or
tool.
 Modules that produce data should be separate from modules that consume data. This tends
to increase modifiability.
 For parallel processing systems, the architecture should feature well-defined processors or
tasks that do not necessarily mirror the module decomposition structure.
 Every task or process should be written so that its assignment to a specific processor can
be easily changed, perhaps even at runtime.
 The architecture should feature a small number of simple interaction patterns.
13

Quality Attributes
• Overview
• Common Quality Attributes
• Additional Resources
Overview
Quality attributes are the overall factors that affect run-time behavior, system design, and user
experience. They represent areas of concern that have the potential for application wide impact across
layers and tiers. Some of these attributes are related to the overall system design, while others are
specific to run time, design time, or user centric issues. The extent to which the application possesses
a desired combination of quality attributes such as usability, performance, reliability, and security
indicates the success of the design and the overall quality of the software application.
When designing applications to meet any of the quality attributes requirements, it is necessary to
consider the potential impact on other requirements. You must analyze the tradeoffs between multiple
quality attributes. The importance or priority of each quality attribute differs from system to system;
for example, interoperability will often be less important in a single use packaged retail application
than in a line of business (LOB) system.
This chapter lists and describes the quality attributes that you should consider when designing your
application. To get the most out of this chapter, use the table below to gain an understanding of how
quality attributes map to system and application quality factors, and read the description of each of the
quality attributes. Then use the sections containing key guidelines for each of the quality attributes to
understand how that attribute has an impact on your design, and to determine the decisions you must
make to addresses these issues. Keep in mind that the list of quality attributes in this chapter is not
exhaustive, but provides a good starting point for asking appropriate questions about your
architecture.
Common Quality Attributes
The following table describes the quality attributes covered in this chapter. It categorizes the attributes
in four specific areas linked to design, runtime, system, and user qualities. Use this table to understand
what each of the quality attributes means in terms of your application design.
14

Category Quality attribute Description
Design
Qualities
Conceptual
Integrity
Conceptual integrity defines the consistency and coherence of the overall
design. This includes the way that components or modules are designed, as well
as factors such as coding style and variable naming.
Maintainability Maintainability is the ability of the system to undergo changes with a degree of
ease. These changes could impact components, services, features, and interfaces
when adding or changing the functionality, fixing errors, and meeting new
business requirements.
Reusability Reusability defines the capability for components and subsystems to be suitable
for use in other applications and in other scenarios. Reusability minimizes the
duplication of components and also the implementation time.
Run-time
Qualities
Availability Availability defines the proportion of time that the system is functional and
working. It can be measured as a percentage of the total system downtime over
a predefined period. Availability will be affected by system errors,
infrastructure problems, malicious attacks, and system load.
Interoperability Interoperability is the ability of a system or different systems to operate
successfully by communicating and exchanging information with other external
systems written and run by external parties. An interoperable system makes it
easier to exchange and reuse information internally as well as externally.
Manageability Manageability defines how easy it is for system administrators to manage the
application, usually through sufficient and useful instrumentation exposed for
use in monitoring systems and for debugging and performance tuning.
Performance Performance is an indication of the responsiveness of a system to execute any
action within a given time interval. It can be measured in terms of latency or
throughput. Latency is the time taken to respond to any event. Throughput is the
number of events that take place within a given amount of time.
Reliability Reliability is the ability of a system to remain operational over time. Reliability
is measured as the probability that a system will not fail to perform its intended
functions over a specified time interval.
Scalability Scalability is ability of a system to either handle increases in load without
impact on the performance of the system, or the ability to be readily enlarged.
Security Security is the capability of a system to prevent malicious or accidental actions
outside of the designed usage, and to prevent disclosure or loss of information.
A secure system aims to protect assets and prevent unauthorized modification of
information.
System
Qualities
Supportability Supportability is the ability of the system to provide information helpful for
identifying and resolving issues when it fails to work correctly.
15

Testability Testability is a measure of how easy it is to create test criteria for the system
and its components, and to execute these tests in order to determine if the
criteria are met. Good testability makes it more likely that faults in a system can
be isolated in a timely and effective manner.
User
Qualities
Usability Usability defines how well the application meets the requirements of the user
and consumer by being intuitive, easy to localize and globalize, providing good
access for disabled users, and resulting in a good overall user experience.
The following sections describe each of the quality attributes in more detail, and provide
guidance on the key issues and the decisions you must make for each one:
• Availability
• Conceptual Integrity
• Interoperability
• Maintainability
• Manageability
• Performance
• Reliability
• Reusability
• Scalability
• Security
• Supportability
• Testability
• User Experience / Usability
Availability
Availability defines the proportion of time that the system is functional and working. It can be
measured as a percentage of the total system downtime over a predefined period. Availability will be
affected by system errors, infrastructure problems, malicious attacks, and system load. The key issues
for availability are:
• A physical tier such as the database server or application server can fail or become
unresponsive, causing the entire system to fail. Consider how to design failover support for
the tiers in the system. For example, use Network Load Balancing for Web servers to
distribute the load and prevent requests being directed to a server that is down. Also, consider
using a RAID mechanism to mitigate system failure in the event of a disk failure. Consider if
there is a need for a geographically separate redundant site to failover to in case of natural
disasters such as earthquakes or tornados.
16

• Denial of Service (DoS) attacks, which prevent authorized users from accessing the system,
can interrupt operations if the system cannot handle massive loads in a timely manner, often
due to the processing time required, or network configuration and congestion. To minimize
interruption from DoS attacks, reduce the attack surface area, identify malicious behavior, use
application instrumentation to expose unintended behavior, and implement comprehensive
data validation. Consider using the Circuit Breaker or Bulkhead patterns to increase system
resiliency.
• Inappropriate use of resources can reduce availability. For example, resources acquired too
early and held for too long cause resource starvation and an inability to handle additional
concurrent user requests.
• Bugs or faults in the application can cause a system wide failure. Design for proper exception
handling in order to reduce application failures from which it is difficult to recover.
• Frequent updates, such as security patches and user application upgrades, can reduce the
availability of the system. Identify how you will design for run-time upgrades.
• A network fault can cause the application to be unavailable. Consider how you will handle
unreliable network connections; for example, by designing clients with occasionally-
connected capabilities.
• Consider the trust boundaries within your application and ensure that subsystems employ
some form of access control or firewall, as well as extensive data validation, to increase
resiliency and availability.
Conceptual Integrity
Conceptual integrity defines the consistency and coherence of the overall design. This includes the
way that components or modules are designed, as well as factors such as coding style and variable
naming. A coherent system is easier to maintain because you will know what is consistent with the
overall design. Conversely, a system without conceptual integrity will constantly be affected by
changing interfaces, frequently deprecating modules, and lack of consistency in how tasks are
performed. The key issues for conceptual integrity are:
• Mixing different areas of concern within your design. Consider identifying areas of concern
and grouping them into logical presentation, business, data, and service layers as appropriate.
• Inconsistent or poorly managed development processes. Consider performing an Application
Lifecycle Management (ALM) assessment, and make use of tried and tested development
tools and methodologies.
• Lack of collaboration and communication between different groups involved in the
application lifecycle. Consider establishing a development process integrated with tools to
facilitate process workflow, communication, and collaboration.
• Lack of design and coding standards. Consider establishing published guidelines for design
and coding standards, and incorporating code reviews into your development process to
ensure guidelines are followed.
17

• Existing (legacy) system demands can prevent both refactoring and progression toward a new
platform or paradigm. Consider how you can create a migration path away from legacy
technologies, and how to isolate applications from external dependencies. For example,
implement the Gateway design pattern for integration with legacy systems.
Interoperability
Interoperability is the ability of a system or different systems to operate successfully by
communicating and exchanging information with other external systems written and run by external
parties. An interoperable system makes it easier to exchange and reuse information internally as well
as externally. Communication protocols, interfaces, and data formats are the key considerations for
interoperability. Standardization is also an important aspect to be considered when designing an
interoperable system. The key issues for interoperability are:
• Interaction with external or legacy systems that use different data formats. Consider how you
can enable systems to interoperate, while evolving separately or even being replaced. For
example, use orchestration with adaptors to connect with external or legacy systems and
translate data between systems; or use a canonical data model to handle interaction with a
large number of different data formats.
• Boundary blurring, which allows artifacts from one system to defuse into another. Consider
how you can isolate systems by using service interfaces and/or mapping layers. For example,
expose services using interfaces based on XML or standard types in order to support
interoperability with other systems. Design components to be cohesive and have low coupling
in order to maximize flexibility and facilitate replacement and reusability.
• Lack of adherence to standards. Be aware of the formal and de facto standards for the domain
you are working within, and consider using one of them rather than creating something new
and proprietary.
Maintainability
Maintainability is the ability of the system to undergo changes with a degree of ease. These changes
could impact components, services, features, and interfaces when adding or changing the application’s
functionality in order to fix errors, or to meet new business requirements. Maintainability can also
affect the time it takes to restore the system to its operational status following a failure or removal
from operation for an upgrade. Improving system maintainability can increase availability and reduce
the effects of run-time defects. An application’s maintainability is often a function of its overall
quality attributes but there a number of key issues that can directly affect maintainability:
• Excessive dependencies between components and layers, and inappropriate coupling to
concrete classes, prevents easy replacement, updates, and changes; and can cause changes to
concrete classes to ripple through the entire system. Consider designing systems as well-
defined layers, or areas of concern, that clearly delineate the system’s UI, business processes,
and data access functionality. Consider implementing cross-layer dependencies by using
18

abstractions (such as abstract classes or interfaces) rather than concrete classes, and minimize
dependencies between components and layers.
• The use of direct communication prevents changes to the physical deployment of components
and layers. Choose an appropriate communication model, format, and protocol. Consider
designing a pluggable architecture that allows easy upgrades and maintenance, and improves
testing opportunities, by designing interfaces that allow the use of plug-in modules or
adapters to maximize flexibility and extensibility.
• Reliance on custom implementations of features such as authentication and authorization
prevents reuse and hampers maintenance. To avoid this, use the built-in platform functions
and features wherever possible.
• The logic code of components and segments is not cohesive, which makes them difficult to
maintain and replace, and causes unnecessary dependencies on other components. Design
components to be cohesive and have low coupling in order to maximize flexibility and
facilitate replacement and reusability.
• The code base is large, unmanageable, fragile, or over complex; and refactoring is
burdensome due to regression requirements. Consider designing systems as well defined
layers, or areas of concern, that clearly delineate the system’s UI, business processes, and data
access functionality. Consider how you will manage changes to business processes and
dynamic business rules, perhaps by using a business workflow engine if the business process
tends to change. Consider using business components to implement the rules if only the
business rule values tend to change; or an external source such as a business rules engine if
the business decision rules do tend to change.
• The existing code does not have an automated regression test suite. Invest in test automation
as you build the system. This will pay off as a validation of the system’s functionality, and as
documentation on what the various parts of the system do and how they work together.
• Lack of documentation may hinder usage, management, and future upgrades. Ensure that you
provide documentation that, at minimum, explains the overall structure of the application.
Manageability
Manageability defines how easy it is for system administrators to manage the application, usually
through sufficient and useful instrumentation exposed for use in monitoring systems and for
debugging and performance tuning. Design your application to be easy to manage, by exposing
sufficient and useful instrumentation for use in monitoring systems and for debugging and
performance tuning. The key issues for manageability are:
• Lack of health monitoring, tracing, and diagnostic information. Consider creating a health
model that defines the significant state changes that can affect application performance, and
use this model to specify management instrumentation requirements. Implement
instrumentation, such as events and performance counters, that detects state changes, and
expose these changes through standard systems such as Event Logs, Trace files, or Windows
19

Management Instrumentation (WMI). Capture and report sufficient information about errors
and state changes in order to enable accurate monitoring, debugging, and management. Also,
consider creating management packs that administrators can use in their monitoring
environments to manage the application.
• Lack of runtime configurability. Consider how you can enable the system behavior to change
based on operational environment requirements, such as infrastructure or deployment
changes.
• Lack of troubleshooting tools. Consider including code to create a snapshot of the system’s
state to use for troubleshooting, and including custom instrumentation that can be enabled to
provide detailed operational and functional reports. Consider logging and auditing
information that may be useful for maintenance and debugging, such as request details or
module outputs and calls to other systems and services.
Performance
Performance is an indication of the responsiveness of a system to execute specific actions in a given
time interval. It can be measured in terms of latency or throughput. Latency is the time taken to
respond to any event. Throughput is the number of events that take place in a given amount of time.
An application’s performance can directly affect its scalability, and lack of scalability can affect
performance. Improving an application’s performance often improves its scalability by reducing the
likelihood of contention for shared resources. Factors affecting system performance include the
demand for a specific action and the system’s response to the demand. The key issues for performance
are:
• Increased client response time, reduced throughput, and server resource over utilization.
Ensure that you structure the application in an appropriate way and deploy it onto a system or
systems that provide sufficient resources. When communication must cross process or tier
boundaries, consider using coarse-grained interfaces that require the minimum number of
calls (preferably just one) to execute a specific task, and consider using asynchronous
communication.
• Increased memory consumption, resulting in reduced performance, excessive cache misses
(the inability to find the required data in the cache), and increased data store access. Ensure
that you design an efficient and appropriate caching strategy.
• Increased database server processing, resulting in reduced throughput. Ensure that you choose
effective types of transactions, locks, threading, and queuing approaches. Use efficient
queries to minimize performance impact, and avoid fetching all of the data when only a
portion is displayed. Failure to design for efficient database processing may incur
unnecessary load on the database server, failure to meet performance objectives, and costs in
excess of budget allocations.
• Increased network bandwidth consumption, resulting in delayed response times and increased
load for client and server systems. Design high performance communication between tiers
20

using the appropriate remote communication mechanism. Try to reduce the number of
transitions across boundaries, and minimize the amount of data sent over the network. Batch
work to reduce calls over the network.
Reliability
Reliability is the ability of a system to continue operating in the expected way over time. Reliability is
measured as the probability that a system will not fail and that it will perform its intended function for
a specified time interval. The key issues for reliability are:
• The system crashes or becomes unresponsive. Identify ways to detect failures and
automatically initiate a failover, or redirect load to a spare or backup system. Also, consider
implementing code that uses alternative systems when it detects a specific number of failed
requests to an existing system.
• Output is inconsistent. Implement instrumentation, such as events and performance counters,
that detects poor performance or failures of requests sent to external systems, and expose
information through standard systems such as Event Logs, Trace files, or WMI. Log
performance and auditing information about calls made to other systems and services.
• The system fails due to unavailability of other externalities such as systems, networks, and
databases. Identify ways to handle unreliable external systems, failed communications, and
failed transactions. Consider how you can take the system offline but still queue pending
requests. Implement store and forward or cached message-based communication systems that
allow requests to be stored when the target system is unavailable, and replayed when it is
online. Consider using Windows Message Queuing or BizTalk Server to provide a reliable
once-only delivery mechanism for asynchronous requests.
Reusability
Reusability is the probability that a component will be used in other components or scenarios to add
new functionality with little or no change. Reusability minimizes the duplication of components and
the implementation time. Identifying the common attributes between various components is the first
step in building small reusable components for use in a larger system. The key issues for reusability
are:
• The use of different code or components to achieve the same result in different places; for
example, duplication of similar logic in multiple components, and duplication of similar logic
in multiple layers or subsystems. Examine the application design to identify common
functionality, and implement this functionality in separate components that you can reuse.
Examine the application design to identify crosscutting concerns such as validation, logging,
and authentication, and implement these functions as separate components.
• The use of multiple similar methods to implement tasks that have only slight variation.
Instead, use parameters to vary the behavior of a single method.
• Using several systems to implement the same feature or function instead of sharing or reusing
functionality in another system, across multiple systems, or across different subsystems
21

within an application. Consider exposing functionality from components, layers, and
subsystems through service interfaces that other layers and systems can use. Use platform
agnostic data types and structures that can be accessed and understood on different platforms.
Scalability
Scalability is ability of a system to either handle increases in load without impact on the performance
of the system, or the ability to be readily enlarged. There are two methods for improving scalability:
scaling vertically (scale up), and scaling horizontally (scale out). To scale vertically, you add more
resources such as CPU, memory, and disk to a single system. To scale horizontally, you add more
machines to a farm that runs the application and shares the load. The key issues for scalability are:
• Applications cannot handle increasing load. Consider how you can design layers and tiers for
scalability, and how this affects the capability to scale up or scale out the application and the
database when required. You may decide to locate logical layers on the same physical tier to
reduce the number of servers required while maximizing load sharing and failover
capabilities. Consider partitioning data across more than one database server to maximize
scale-up opportunities and allow flexible location of data subsets. Avoid stateful components
and subsystems where possible to reduce server affinity.
• Users incur delays in response and longer completion times. Consider how you will handle
spikes in traffic and load. Consider implementing code that uses additional or alternative
systems when it detects a predefined service load or a number of pending requests to an
existing system.
• The system cannot queue excess work and process it during periods of reduced load.
Implement store-and-forward or cached message-based communication systems that allow
requests to be stored when the target system is unavailable, and replayed when it is online.
Security
Security is the capability of a system to reduce the chance of malicious or accidental actions outside
of the designed usage affecting the system, and prevent disclosure or loss of information. Improving
security can also increase the reliability of the system by reducing the chances of an attack succeeding
and impairing system operation. Securing a system should protect assets and prevent unauthorized
access to or modification of information. The factors affecting system security are confidentiality,
integrity, and availability. The features used to secure systems are authentication, encryption,
auditing, and logging. The key issues for security are:
• Spoofing of user identity. Use authentication and authorization to prevent spoofing of user
identity. Identify trust boundaries, and authenticate and authorize users crossing a trust
boundary.
• Damage caused by malicious input such as SQL injection and cross-site scripting. Protect
against such damage by ensuring that you validate all input for length, range, format, and type
using the constrain, reject, and sanitize principles. Encode all output you display to users.
22

• Data tampering. Partition the site into anonymous, identified, and authenticated users and use
application instrumentation to log and expose behavior that can be monitored. Also use
secured transport channels, and encrypt and sign sensitive data sent across the network
• Repudiation of user actions. Use instrumentation to audit and log all user interaction for
application critical operations.
• Information disclosure and loss of sensitive data. Design all aspects of the application to
prevent access to or exposure of sensitive system and application information.
• Interruption of service due to Denial of service (DoS) attacks. Consider reducing session
timeouts and implementing code or hardware to detect and mitigate such attacks.
Supportability
Supportability is the ability of the system to provide information helpful for identifying and resolving
issues when it fails to work correctly. The key issues for supportability are:
• Lack of diagnostic information. Identify how you will monitor system activity and
performance. Consider a system monitoring application, such as Microsoft System Center.
• Lack of troubleshooting tools. Consider including code to create a snapshot of the system’s
state to use for troubleshooting, and including custom instrumentation that can be enabled to
provide detailed operational and functional reports. Consider logging and auditing
information that may be useful for maintenance and debugging, such as request details or
module outputs and calls to other systems and services.
• Lack of tracing ability. Use common components to provide tracing support in code, perhaps
though Aspect Oriented Programming (AOP) techniques or dependency injection. Enable
tracing in Web applications in order to troubleshoot errors.
• Lack of health monitoring. Consider creating a health model that defines the significant state
changes that can affect application performance, and use this model to specify management
instrumentation requirements. Implement instrumentation, such as events and performance
counters, that detects state changes, and expose these changes through standard systems such
as Event Logs, Trace files, or Windows Management Instrumentation (WMI). Capture and
report sufficient information about errors and state changes in order to enable accurate
monitoring, debugging, and management. Also, consider creating management packs that
administrators can use in their monitoring environments to manage the application.
Testability
Testability is a measure of how well system or components allow you to create test criteria and
execute tests to determine if the criteria are met. Testability allows faults in a system to be isolated in
a timely and effective manner. The key issues for testability are:
• Complex applications with many processing permutations are not tested consistently, perhaps
because automated or granular testing cannot be performed if the application has a monolithic
design. Design systems to be modular to support testing. Provide instrumentation or
implement probes for testing, mechanisms to debug output, and ways to specify inputs easily.
23

Design components that have high cohesion and low coupling to allow testability of
components in isolation from the rest of the system.
• Lack of test planning. Start testing early during the development life cycle. Use mock objects
during testing, and construct simple, structured test solutions.
• Poor test coverage, for both manual and automated tests. Consider how you can automate user
interaction tests, and how you can maximize test and code coverage.
• Input and output inconsistencies; for the same input, the output is not the same and the output
does not fully cover the output domain even when all known variations of input are provided.
Consider how to make it easy to specify and understand system inputs and outputs to
facilitate the construction of test cases.
User Experience / Usability
The application interfaces must be designed with the user and consumer in mind so that they are
intuitive to use, can be localized and globalized, provide access for disabled users, and provide a good
overall user experience. The key issues for user experience and usability are:
• Too much interaction (an excessive number of clicks) required for a task. Ensure you design
the screen and input flows and user interaction patterns to maximize ease of use.
• Incorrect flow of steps in multistep interfaces. Consider incorporating workflows where
appropriate to simplify multistep operations.
• Data elements and controls are poorly grouped. Choose appropriate control types (such as
option groups and check boxes) and lay out controls and content using the accepted UI design
patterns.
• Feedback to the user is poor, especially for errors and exceptions, and the application is
unresponsive. Consider implementing technologies and techniques that provide maximum
user interactivity, such as Asynchronous JavaScript and XML (AJAX) in Web pages and
client-side input validation. Use asynchronous techniques for background tasks, and tasks
such as populating controls or performing long-running tasks.
24

UNIT II QUALITY ATTRIBUTE WORKSHOP
Quality Attribute Workshop – Documenting Quality Attributes – Six part scenarios – Case
studies.
Quality Attribute Workshop
Quality Attribute Workshops (QAWs) provide a method for identifying a system's
architecture-critical quality attributes, such as availability, performance, security,
interoperability, and modifiability, that are derived from mission or business goals. The
QAW does not assume the existence of a software architecture. It was developed to
complement the SEI Architecture Tradeoff Analysis Method (ATAM) in response to
customer requests for a method to identify important quality attributes and clarify system
requirements before there is a software architecture to which the ATAM could be applied.
Challenges
1. How can you determine which quality attribute requirements are important before a system
is built?
2. How can you find out stakeholders' needs and expectations in an organized and effective
way?
3. How do you improve and increase communication among stakeholders?
Description
In the QAW, an external team facilitates meetings among stakeholders during which
scenarios representing the quality attribute requirements are generated, prioritized, and
refined (i.e., adding additional details such as the participants and assets involved, the
sequence of activities, and questions about quality attributes requirements). The process of
refining the scenarios allows stakeholders to communicate among them, thereby exposing
assumptions that may not have surfaced during requirements elicitation. The refinement also
provides insights as to how these attributes interact, forming a basis for making tradeoffs
between these attributes.
There may be more than one scenario-generation workshop, depending on the number and
type of organizations and stakeholders involved in the development, maintenance, or use of
the system. The QAW process ends with the list of prioritized, refined scenarios. The refined
scenarios can be used in different ways, for example as seed scenarios for ATAM or as test
cases in an acquisition effort.
The QAW involves these steps:
1. QAW Presentation and Introductions: QAW facilitators describe the motivation for the
QAW and explain each step of the method.
25

2. Business/Programmatic Presentation : A representative of the stakeholder community
presents the business and/or programmatic drivers for the system.
3. Architectural Plan Presentation: A technical stakeholder presents the system
architectural plans as they stand with respect to early documents, such as high-level system
descriptions, context drawings, or other artifacts that describe some of the system's technical
details.
4. Identification of Architectural Drivers : Architectural drivers often include high-level
requirements, business/mission concerns, goals and objectives, and various quality attributes.
During this step, the facilitators and stakeholders reach a consensus about which drivers are
key to the system.
5. Scenario Brainstorming: Stakeholders generate real-world scenarios for the system.
Scenarios comprise a related stimulus, an environmental condition, and a response.
Facilitators ensure that at least one scenario addresses each of the architectural drivers
identified in Step 4.
6. Scenario Consolidation : Scenarios that are similar in content are consolidated.
7. Scenario Prioritization: Stakeholders prioritize the scenarios through a voting process.
8. Scenario Refinement: The top four or five scenarios are further clarified and the
following are described:
1. the business/programmatic goals that are affected by those scenarios
2. the relevant quality attributes associated with those scenarios
In addition, stakeholders get a chance to ask questions and raise any concerns they have about
those scenarios.
Organizations can use the QAW results to
1. Update the organization’s architectural vision
2. Refine system and software requirements
3. Guide the development of prototypes
4. Exercise simulations
5. Understand and clarify the system’s architectural drivers
6. Influence the order in which the architecture is developed
7. Describe the system’s operation
In addition, after the architecture is created, the scenarios can be used as seed scenarios
during an ATAM evaluation.
26

Benefits
The QAW helps you determine the right qualities for your system before it is developed—
something that is crucial for system success and for your stakeholders' satisfaction. Clarifying
those requirements and then achieving them in the first version of your system saves money
and avoids future rework. The QAW provides a structured and efficient setting for
communicating with your stakeholders and supports analysis and testing throughout the life
of the system.
The QAW provides a forum for a wide variety of stakeholders to gather in one room at one
time early in the development process. It is often the first time such a meeting takes place and
generally leads to the identification of conflicting assumptions about system requirements.
Documenting Quality Attributes
"A science is as mature as its measurement tools," (Louis Pasteur in Ebert Dumke, p. 91).
Measuring software quality is motivated by at least two reasons:
Risk Management: Software failure has caused more than inconvenience. Software errors
have caused human fatalities. The causes have ranged from poorly designed user interfaces to
direct programming errors. An example of a programming error that led to multiple deaths is
discussed in Dr. Leveson's paper.This resulted in requirements for the development of some
types of software, particularly and historically for software embedded in medical and other
devices that regulate critical infrastructures: "[Engineers who write embedded software] see
Java programs stalling for one third of a second to perform garbage collection and update the
user interface, and they envision airplanes falling out of the sky.". In the United States, within
the Federal Aviation Administration (FAA), the Aircraft Certification Service provides
software programs, policy, guidance and training, focus on software and Complex Electronic
Hardware that has an effect on the airborne product (a “product” is an aircraft, an engine, or a
propeller)".
Cost Management: As in any other fields of engineering, an application with good structural
software quality costs less to maintain and is easier to understand and change in response to
pressing business needs. Industry data demonstrate that poor application structural quality in
core business applications (such as Enterprise Resource Planning (ERP), Customer
Relationship Management (CRM) or large transaction processing systems in financial
services) results in cost and schedule overruns and creates waste in the form of rework (up to
45% of development time in some organizations). Moreover, poor structural quality is
27

strongly correlated with high-impact business disruptions due to corrupted data, application
outages, security breaches, and performance problems.
However, the distinction between measuring and improving software quality in an embedded
system (with emphasis on risk management) and software quality in business software (with
emphasis on cost and maintainability management) is becoming somewhat irrelevant.
Embedded systems now often include a user interface and their designers are as much
concerned with issues affecting usability and user productivity as their counterparts who
focus on business applications. The latter are in turn looking at ERP or CRM system as a
corporate nervous system whose uptime and performance are vital to the well-being of the
enterprise. This convergence is most visible in mobile computing: a user who accesses an
ERP application on their smart phone is depending on the quality of software across all types
of software layers.
Both types of software now use multi-layered technology stacks and complex architecture so
software quality analysis and measurement have to be managed in a comprehensive and
consistent manner, decoupled from the software's ultimate purpose or use. In both cases,
engineers and management need to be able to make rational decisions based on measurement
and fact-based analysis in adherence to the precept "In God (we) trust. All others bring data".
((mis-)attributed to W. Edwards Deming and others).
CISQ's Quality Model
Even though "quality is a perceptual, conditional and somewhat subjective attribute and may
be understood differently by different people" (as noted in the article on quality in business),
software structural quality characteristics have been clearly defined by the Consortium for IT
Software Quality (CISQ). Under the guidance of Bill Curtis, co-author of the Capability
Maturity Model framework and CISQ's first Director; and Capers Jones, CISQ's
Distinguished Advisor, CISQ has defined five major desirable characteristics of a piece of
software needed to provide business value.[16] In the House of Quality model,these are
"Whats" that need to be achieved:
1. Reliability: An attribute of resiliency and structural solidity. Reliability measures the level
of risk and the likelihood of potential application failures. It also measures the defects
injected due to modifications made to the software (its “stability” as termed by ISO). The
goal for checking and monitoring Reliability is to reduce and prevent application downtime,
application outages and errors that directly affect users, and enhance the image of IT and its
impact on a company’s business performance.
28

2. Efficiency: The source code and software architecture attributes are the elements that
ensure high performance once the application is in run-time mode. Efficiency is especially
important for applications in high execution speed environments such as algorithmic or
transactional processing where performance and scalability are paramount. An analysis of
source code efficiency and scalability provides a clear picture of the latent business risks and
the harm they can cause to customer satisfaction due to response-time degradation.
3. Security: A measure of the likelihood of potential security breaches due to poor coding
practices and architecture. This quantifies the risk of encountering critical vulnerabilities that
damage the business.
4. Maintainability: Maintainability includes the notion of adaptability, portability and
transferability (from one development team to another). Measuring and monitoring
maintainability is a must for mission-critical applications where change is driven by tight
time-to-market schedules and where it is important for IT to remain responsive to business-
driven changes. It is also essential to keep maintenance costs under control.
5. Size: While not a quality attribute per se, the sizing of source code is a software
characteristic that obviously impacts maintainability. Combined with the above quality
characteristics, software size can be used to assess the amount of work produced and to be
done by teams, as well as their productivity through correlation with time-sheet data, and
other SDLC-related metrics.
Software functional quality is defined as conformance to explicitly stated functional
requirements, identified for example using Voice of the Customer analysis (part of the Design
for Six Sigma toolkit and/or documented through use cases) and the level of satisfaction
experienced by end-users. The latter is referred as to as usability and is concerned with how
intuitive and responsive the user interface is, how easily simple and complex operations can
be performed, and how useful error messages are. Typically, software testing practices and
tools ensure that a piece of software behaves in compliance with the original design, planned
user experience and desired testability, i.e. a piece of software's disposition to support
acceptance criteria.
The dual structural/functional dimension of software quality is consistent with the model
proposed in Steve McConnell's Code Complete which divides software characteristics into
two pieces: internal and external quality characteristics. External quality characteristics are
those parts of a product that face its users, where internal quality characteristics are those that
do not.
29

Six part scenarios
Actual quality attribute requirements are stated in terms of quality attribute scenarios, the
non-functional equivalent of a user story. Much like a user story, it has a styled format,
consisting of 6 parts:
1. Source of stimulus: the entity generating the stimulus. Could be anactor, an actuator, a
sensor, and so on.
2. Stimulus: a condition arriving at a system. Includes faults, stated intentions by actors, and
so on.
3. Environment: the conditions surrounding the stimulus. Might be normal operation,
degraded operation, overload, and so on.
4. Artifact: the part or parts of the system stimulated.
5. Response: the response the system takes to the stimulus.
6. Response measure: how the response can be measured and tested.
For the different quality attributes, we can define a general scenario template by constraining
the kinds of items that may be used for each of the six parts. Specific quality attribute
scenarios may then be generated for a component, project or product by using specific values
from the template.
Evaluating the Quality Attribute Scenarios
Each scenario should be evaluated in terms of its importance, difficulty, and, maturity
support:
1. Importance - The product owner evaluates each scenario on its importance to the specific
project (since different project may prioritize the same scenario differently)
2. Difficulty - The architect evaluates the difficulty of supporting and implementing each
scenario within the system architecture
3. Maturity Support - The architect evaluates how well the proposed or current architecture
meets (or does not meet) the scenario.
30

Class notes

More Related Content

What's hot

Viewers also liked

Similar to Class notes

Recently uploaded

Class notes