Safety

Safety is concerned with the occurrence of accidents or mishaps, defined in terms of external
consequences (accidents happen). The difference of intentsgood things (services) must
happen vs. bad things (accidents) must not happengives rise to the following paradox: If the
services are specified incorrectly, a system can be dependable but unsafe; conversely, it is
possible for a system to be safe but undependable.
A system might be dependable but unsafe for example, an avionics systems that continues
to operate under adverse conditions yet directs the aircraft into a collision course. A system
might be safe but undependable for example, a railroad signaling system that always failsstops
6.1.2 Taxonomy The taxonomy for the safety attributes defines conditions of the system (hazards)
that might lead to undesirable consequences (mishaps); methods normally used to identify
hazards, evaluate the consequences of a hazard, and eliminate or reduce the possibility of
mishaps; and indicators of safety in the aggregate (system, environment, users and operators).

Security
is a measure of the system's ability to resist unauthorized usage while still providing
its services to legitimate users. An attempt to breach security is called an attack [1]
and can take a number of forms. It may be an unauthorized attempt to access data
or services or to modify data, or it may be intended to deny services to legitimate
users. [1] Some security experts use "threat" interchangeably with "attack." Attacks,
often occasions for wide media coverage, may range from theft of money by
electronic transfer to modification of sensitive data, from theft of credit card
numbers to destruction of files on computer systems, or to denial-of-service attacks
carried out by worms or viruses. Still, the elements of a security general scenario are
the same as the elements of our other general scenariosa stimulus and its source,
an environment, the target under attack, the desired response of the system, and
the measure of this response. Security can be characterized as a system providing
nonrepudiation, confidentiality, integrity, assurance, availability, and auditing. For
each term, we provide a definition and an example. 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. This means you cannot deny that you ordered that
item over the Internet if, in fact, you did. 2. Confidentiality is the property that data
or services are protected from unauthorized access. This means that a hacker
cannot access your income tax returns on a government computer. 3. Integrity is the
property that data or services are being delivered as intended. This means that your
grade has not been changed since your instructor assigned it. 4. Assurance is the
property that the parties to a transaction are who they purport to be. This means
that, when a customer sends a credit card number to an Internet merchant, the
merchant is who the customer thinks they are. 5. Availability is the property that the
system will be available for legitimate use. This means that a denial-of-service
attack won't prevent your ordering this book. 6. Auditing is the property that the
system tracks activities within it at levels sufficient to reconstruct them. This means

that, if you transfer money out of one account to another account, in Switzerland,
the system will maintain a record of that transfer.

Portability: Can an application be easily executed on a different software/

hardware platform to the one it has been developed for? Portability depends on
the choices of software technology used to implement the application, and the
characteristics of the platforms that it needs to execute on. Easily portable code
bases will have their platform dependencies isolated and encapsulated in a
small set of components that can be replaced without affecting the rest of the
application.
Portability is the software codebase feature to be able to reuse the existing code instead of creating
new code when moving software from an environment to another.
Portability = (No. of successful ports) / (Total no. of ports) * 100

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

Effort required testing a program to ensure that it performs its intended function. Testability

can be calcluated as
= (Time spent in testing the functionality) / (Total development time) * 100

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.

Extent to which a program can be expected to perform its intended function with required

precision. The formula of reliability is

= (Mean Time To Failure) / (Total Run Time) * 100
It can also be calculated as
= (Mean Time Between Failure) / (Total Run Time) * 100

Usability

Usability = (Total Training Time) / (Total development time) * 100

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: l

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? l

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

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

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

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

In the last five years, our understanding of the relation between usability and
software architecture has deepened (see the sidebar Usability Mea Culpa).
The normal development process detects usability problems through building
prototypes and user testing. The later a problem is discovered and the deeper
into the architecture its repair must be made, the more the repair is
threatened by time and budget pressures.

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

Extent to which a program can be used in other applications. It is related to the packaging and

scope of the functions that programs perform.

Reusability = (No. of reusable components) / (Total no. of components) * 100

ability of the system to tolerate unexpected or unplanned external or

environmental conditions.A software system is robust if the consequences of an error in its operation,
Robustness: Robustness

in the input, or in the hardware, in relation to a given application, are inversely proportional to the
probability of the occurrence of this error in the given application.
- Frequent errors (e.g. erroneous commands, typing errors) must be handled with particular care.
- Less frequent errors (e.g. power failure) can be handled more laxly, but still must not lead to
irreversible consequences.

Efficiency: The ability of a software system to place as few demands as possible

on hardware resources, such as processor time, space occupied in internal and
external memories, bandwidth used in communication devices. The constant
improvement in computer power, impressive as it is, is not an excuse for
overlooking efficiency. Software construction is difficult precisely because it
requires taking into account many different requirements, some of which, such as
correctness, are abstract and conceptual, whereas others, such as efficiency, are
concrete and bound to the properties of computer hardware. Efficiency is only
one of the factors of quality; we should not (like some in the profession) let it rule
our engineering lives. But it is a factor, and must be taken into consideration,
whether in the construction of a software system or in the design of a
programming language. If you dismiss performance, performance will dismiss
you.
The amount of computing resources and code required by a program to perform a function.
Efficiency = (Memory Usage) / (Total Memory) * 100

Learnability: Learnability of a software system depends on:

- The design of user interfaces
- The clarity and the simplicity of the user instructions (tutorial or user manual).
The user interface should present information as close to reality as possible and permit efficient
utilization of the softwares failures.
The user manual should be structured clearly and simply and be free of all dead weight. It should
explain to the user what the software system should do, how the individual functions are activated,
what relationships exist between functions, and which exceptions might arise and how they can be
corrected. In addition, the user manual should serve as a reference that supports the user in quickly
and comfortably finding the correct answers to questions.

Modularity
Modularity is the measure of the extent to which software is composed of
separate, interchangeable components, each of which accomplishes one
function and contains everything necessary to accomplish this. Modularity
increases cohesion and reduces coupling and makes it easier to extend the
functionality and maintain the code.

Resilience is the ability of the system to tolerate anticipated faults.

satisfaction i.e. customer and user. It provide all the climate to the user. With the
help of resilience factor increased software quality and reliability.

UNDERSTANDABILITY
Software systems tend to depart more and more from the principle of simplicity and
become increasingly complex. The increase in size and complexity of software
drastically affects several quality attributes, especially understandability and
maintainability. Software developers and maintainers need to read and understand
source programs and other documents of software. The significance of
understandability is very obvious that can be perceived as If we can't learn
something, we won't understand it. If we can't understand something, we can't use
it - at least not well enough to avoid creating a money pit. We can't maintain a
system that we don't understand - at least not easily. And we can't make changes to
our system if we can't understand how the system as a whole will work once the
changes are made [16]. Understandability of software documents is thus important
as the better we know what the thing is supposed to do, the better we can test for
it. Despite the fact that understandability is vital and highly significant to the
software development process, it is poorly managed [1]. The fundamental reality of
measurement we cannot control what we cannot measure highlights the
importance and significance of good measure of software understandability [13].
There are some aspects of software artifacts that either directly or indirectly affects
understandability of software. Classes that are huge and complex are hard to
understand by humans, especially if the class is of low cohesion. A good software
design with manageable complexity usually provides proper data abstraction; it
reduces coupling while increasing cohesion that make them easily understandable.
Researchers and Practitioners advocated that understandability aspect of software is
highly desirable and significant for developing quality software. Literature survey
reveals that there are various aspects of software, including understandability factor
that either directly or indirectly influence testability of software [6], [7], [15].
Aforementioned facts reveal that understandability is a key factor to testability.

Complexity

The extent to understand and comprehend the internal and external structure of
classes and their relationships at a level of difficulty

Adaptability
https://www.researchgate.net/publication/228668019_Adaptability_Evaluation_at_Software_Architectu
re_Level