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, 20075. 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.

IntroductionWhat 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 life- cycle 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 ofconstraints 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 DESIGNDECISIONSSoftware 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 implementationo 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 structureo 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 attributeso 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 goodarchitecture is necessary, but not sufficient. Predicting system qualities by studying the architectureo 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 changeo 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 underlyingarchitectural approach intact. The architecture helps in evolutionary prototypingo 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 estimateso Cost and schedule estimates are an important management tool to enable the manager toacquire the necessary resources and to understand whether a project is in trouble.

ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODELThe earlier in the life cycle re-use is applied, the greater the benefit that can be achieved. While code re- use is beneficial, re-use at the architectural level provides tremendous leverage for systems with similar requirements. Software product lines share a common architectureA 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 elementsWhereas 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 alternativesWe 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 easilyunderstood and communicated, more capable analysis, shorter selection time, and greater interoperability. An architecture permits template based developmentAn 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 trainingThe 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 VIEWSArchitectural 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 ModuleModule-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-connectorComponent-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). AllocationAllocation structures include the following structures

7

Deployment: This view allows an engineer to reason about performance, data integrity, availability, and security 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 OTHEREach 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 CYCLEThe 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.

8

Figure below shows the architect receiving helpful stakeholder “suggestions”.

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 willtry 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.

9

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. 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.

10

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.

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 beimplemented 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.

11

SOFTWARE PROCESSES AND THE ARCHITECTURE BUSINESS CYCLESoftware process is the term given to the organization, ritualization and management of software development activities.The various activities involved in creating software architecture are: Creating the business case for the systemo 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 requirementso 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 architectureo 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 architectureo 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 architectureo 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 architectureo 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 ensuringarchitectural conformance. Ensuring that the implementation conforms to the architectureo 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 representationremain to each other during this phase.

12

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 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 tomake 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

CategoryQuality 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.

15

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.

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

16

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.

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.

17

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.

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-

18

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

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

19

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.

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.

20

Increased network bandwidth consumption, resulting in delayed response times and increased

load for client and server systems. Design high performance communication between tiers

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.

21

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

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.

22

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.

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:

23

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.

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