Question

Modifiability comes in many flavors and is known by many names. Find one of the IEEE or ISO standards dealing with quality attributes and compile a list of quality attributes that refer to some form of modifiability. Discuss the differences.

Answer 1

MODIFIABILITY

Modifiability is about the cost of change.

Modifiability General Scenario Generation
Portion of Scenario	Possible Values
Source	End user, developer, system administrator
Stimulus	Wishes to add/delete/modify/vary functionality, quality attribute, capacity
Artifact	System user interface, platform, environment; system that interoperates with target system
Environment	At runtime, compile time, build time, design time
Response	Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification
Response Measure	Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes

Sample modifiability scenario

Functionality and Architecture

·       Functionality and quality attributes are orthogonal.

·       What is functionality? It is the ability of the system to do the work for which it was intended. A task requires that many or most of the system's elements work in a coordinated manner to complete the job. If the elements have not been assigned the correct responsibilities or have not been endowed with the correct facilities for coordinating with other elements

·       Functionality may be achieved through the use of any of a number of possible structures. In fact, if functionality were the only requirement, the system could exist as a single monolithic module with no internal structure at all. Instead, it is decomposed into modules to make it understandable and to support a variety of other purposes. In this way, functionality is largely independent of structure. Software architecture constrains its allocation to structure when other quality attributes are important.

2. Architecture and Quality Attributes

·       Achieving quality attributes must be considered throughout design, implementation, and deployment.

·       Architecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural level.

·       Architecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the details.

·       Types of quality attributes:

1.     Qualities of the system

2.     Business qualities

3.     Qualities that are about the architecture itself

3. System Quality Attributes

QUALITY ATTRIBUTE SCENARIOS

A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts.

·        Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that generated the stimulus.

·        Stimulus. The stimulus is a condition that needs to be considered when it arrives at a system.

·        Environment. The stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true.

·        Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.

·        Response. The response is the activity undertaken after the arrival of the stimulus.

·        Response measure. When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

Quality attribute parts

SECURITY

·       Security is a measure of the system's ability to resist unauthorized usage while still providing its services to legitimate users.

·       Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance, availability, and auditing.

1.     Nonrepudiation is the property that a transaction (access to or modification of data or services) cannot be denied by any of the parties to it.

2.     Confidentiality is the property that data or services are protected from unauthorized access.

3.     Integrity is the property that data or services are being delivered as intended.

4.     Assurance is the property that the parties to a transaction are who they purport to be.

5.     Availability is the property that the system will be available for legitimate use.

6.     Auditing is the property that the system tracks activities within it at levels sufficient to reconstruct them.

Security General Scenario Generation
Portion of Scenario	Possible Values
Source	Individual or system that is correctly identified, identified incorrectly, of unknown identity who is internal/external, authorized/not authorized with access to limited resources, vast resources
Stimulus	Tries to display data, change/delete data, access system services, reduce availability to system services
Artifact	System services; data within system
Environment	Either online or offline, connected or disconnected, firewalled or open
Response	Authenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services
Response Measure	Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied

TESTABILITY

·       Software testability refers to the ease with which software can be made to demonstrate its faults through testing.

·       Testability refers to the probability that it will fail on its next test execution.

·       For a system to be properly testable, it must be possible to control each component's internal state and inputs and then to observe its outputs.

Testability General Scenario Generation
Portion of Scenario	Possible Values
Source	Unit developer, Increment integrator, System verifier, Client acceptance tester, System user
Stimulus	Analysis, architecture, design, class, subsystem integration completed; system delivered
Artifact	Piece of design, piece of code, complete application
Environment	At design time, at development time, at compile time, at deployment time
Response	Provides access to state values; provides computed values; prepares test environment
Response Measure	Percent executable statements executed Probability of failure if fault exists Time to perform tests Length of longest dependency chain in a test Length of time to prepare test environment

USABILITY

Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. It can be broken down into the following areas:

·        Learning system features. If the user is unfamiliar with a particular system or a particular aspect of it, what can the system do to make the task of learning easier?

·        Using a system efficiently. What can the system do to make the user more efficient in its operation?

·        Minimizing the impact of errors. What can the system do so that a user error has minimal impact?

·        Adapting the system to user needs. How can the user (or the system itself) adapt to make the user's task easier?

·        Increasing confidence and satisfaction. What does the system do to give the user confidence that the correct action is being taken?

Usability General Scenario Generation
Portion of Scenario	Possible Values
Source	End user
Stimulus	Wants to learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortable
Artifact	System
Environment	At runtime or configure time
Response	System provides one or more of the following responses: to support "learn system features": help system is sensitive to context; interface is familiar to user; interface is usable in an unfamiliar context to support "use system efficiently": aggregation of data and/or commands; re-use of already entered data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities to "minimize impact of errors": undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources to "adapt system": customizability; internationalization to "feel comfortable": display system state; work at the user's pace
Response Measure	Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ratio of successful operations to total operations, amount of time/data lost

COMMUNICATING CONCEPTS USING GENERAL SCENARIOS

Quality Attribute Stimuli
Quality Attribute	Stimulus
Availability	Unexpected event, nonoccurrence of expected event
Modifiability	Request to add/delete/change/vary functionality, platform, quality attribute, or capacity
Performance	Periodic, stochastic, or sporadic
Security	Tries to display, modify, change/delete information, access, or reduce availability to system services
Testability	Completion of phase of system development
Usability	Wants to learn system features, use a system efficiently, minimize the impact of errors, adapt the system, feel comfortable

5. Other System Quality Attributes

·       Scalability

·       Portability

·       Interoperability

6. Business Qualities

·        Time to market.

·        Cost and benefit.

·        Projected lifetime of the system.

·        Targeted market.

·        Rollout schedule.

·        Integration with legacy systems.

7. Architecture Qualities

·       Conceptual integrity is the underlying theme or vision that unifies the design of the system at all levels. The architecture should do similar things in similar ways. Conceptual integrity is the most important consideration in system design.

·       Correctness and completeness are essential for the architecture to allow for all of the system's requirements and runtime resource constraints to be met. A formal evaluation is the architect's best hope for a correct and complete architecture.

·       Buildability allows the system to be completed by the available team in a timely manner and to be open to certain changes as development progresses.