Software Quality Characterstics and its Architecture Level

“Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice many alternatives”

–William A. Foster

Most of the people think that the quality is something that can be added in the software but in my opinion quality is something that must be in software and without it no software exists. It means to build a quality software it must be programmed and performed based on the mentioned quality. Today the software becomes more complex. Different hardware is integrated into one software which makes software complex. Whenever it is necessary to design anything with high complexities then architecture is needed. Thus, in software development, software architecture is needed.
Knowing the quality characteristics helps us to focus our testing on most important characteristics of the software.

Definition of software architecture

Architecture gives us the overall point of view of the whole system for monitoring the development. The word architecture has a latin root meaning “master of making”.
In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”
Mathematically software architecture is defined as follows:

where i is the indicator and i ,j is the connector between the indicator.
So, architecture is a collection of technical maps that each map includes of explaining of one specific aspect of the system. To explain the different aspects
of architecture, a series of a model is used and each model uses specific rules, signs, semantics and syntactic.

ISO(International Organization of Standardisation) 9126-1 Software Quality Characteristics

To describe the qualitative characteristics usually, the qualitative models are used. Many models have been suggested to describe the quality of software system, such as Mc Call [2], Boehm [3], FURPS [1], IEEE [4], and ISO [5]. These models have been presented as tree-construction of qualitative characteristics and their relationships.
The main characteristics of ISO 9126 are as follows:

1. Functionality: Essential purpose of any product.
2. Reliability: Can you trust the product in the difficult situation?
3. Usability: Is the product easy to use?
4. Efficiency: It refers as performance.
5. Maintainability: Are the product and its artifacts easy to maintain and support for customers?
6. Portability: Is transferring of the product to different environments enabled?

The full table of Characteristics and Sub characteristics for the ISO 9126-1 Quality Model is:-

Characteristics	Sub characteristics	Definitions
	Suitability	This is the essential Functionality characteristic and refers to the appropriateness (to specification) of the functions of the software.
	Accurateness	This refers to the correctness of the functions, an ATM may provide a cash dispensing function but is the amount correct? Any output or calculation in the product is correct and presented with significant digits.
Functionality	Interoperability	A given software component or system does not typically function in isolation. This sub-characteristic concerns the ability of a software component to interact with other components or systems. Different features interact with each other in the best way.
	Compliance	Where appropriate certain industry (or government) laws and guidelines need to comply with. This sub-characteristics addresses the compliant capability of the software. Standards the product adheres to.
	Security	This sub-characteristic relates to unauthorized access to the software functions.
	Maturity	This sub-characteristics concerns frequency of failure of the software.
Reliability (can you trust the product in the difficult situation?)	Fault tolerance	The ability of software to withstand (and recover) from a component, or environmental, failure. Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of (or one or more faults within) some of its components.
	Recoverability	Ability to bring back a failed system to full operation, including data and network connections. It is possible to recover and continue using the product after a fatal error.
	Understandability	Determines the ease of which the systems functions can be understood, relates to user mental models in Human-Computer Interaction methods.
Usability (Is the product easy to use?)	Learnability	Learning effort for different users, i.e. novice, expert, casual etc. It is fast and easy to learn how to use the product.
	Operability	Ability of the software to be easily operated by a given user in a given environment. An experienced user can perform common actions very fast.
Efficiency (Does the product performs in an efficient manner?)	Time behavior	Characterizes response times for a given thruput (rate of production), i.e. transaction rate.
	Resource behavior	Characterizes resources used, i.e. memory, CPU, disk and network usage.
	Analyzability	Characterizes the ability to identify the root cause of a failure within the software.
Maintainability (are the product and its artifacts easy to maintain and support for customers?)	Changeability	Characterizes the amount of effort to change a system.
	Stability	Characterizes the sensitivity to change of a given system that is the negative impact that may be caused by system changes. The product shouldn’t cause crashes, unhandled exceptions or script errors.
	Testability	Characterizes the effort needed to verify (test) a system change. How effectively can the deployed product be tested by the customer?
	Adaptability	Characterizes the ability of the system to change to new specifications or operating environments.
Portability(Is transferring of the product to different environments enabled?)	Installability	Characterizes the effort required to install the software. Product can be installed on intended platforms with an appropriate footprint.
	Conformance	Similar to compliance for functionality, but this characteristic relates to portability. One example would be Open SQL conformance which relates to the portability of database used. The product conforms to applicable standards, regulations, laws or ethics, similar to compliance.
	Replaceability	Characterizes the plug and plays aspect of software components, that is how easy is it to exchange a given software component within a specified environment.

Extracted form http://www.sqa.net/

Software Quality Characteristics in Architecture Level

As we discussed the need of software architecture in software development and we discussed the software quality characteristics. Now we are going to discuss on the quality in architecture level.

1. The analysis of Functionality factor at architecture level
   1. Suitability: This is the major characteristics of the software. The suitability of the software should be recognized at the architecture level by  communicating with stake holder.
   2. Accuracy: Though the accuracy can’t be measured in architecture level but by studying the defined process in architecture  the accuracy can be evaluated. One of the way to achieve this is to prepare concrete test data. For example, we are building the calculator, for this we can prepare concrete test data and validate our product against it.
   3. Interoperability: If a system has such a characteristic, at the level of architecture, the indicator(s) in order to give relating mediator role must be considered. The indicators which have the middle ware role in connections system. We may analyse the module(indicator), their relationship and impact/risk after integrated.
   4. Security: It should well investigate that who can access the product and up to which level. We should consider who are the end user. If the product is for the internal user then it may not be the high priority but if the end user is a general user like facebook then it should be in high priority.
2. The analysis of Reliability factor at architecture level: There are three sub-characteristics for reliability viz: Maturity, Fault Tolerance, and Recovery. Though these sub-characteristics are defined on the run-time events, we can anticipate the possibility of fault occurrence by investigating the indicator (s), its components, and their  relationship. The existence of exception handling will work better for reliability.
3. The analysis of Usability factor at architecture level: User mediator architecture from the conformity point of view with user mental contents of operation, possibility of error correction and guide mechanisms are subjected that can provide the aims of this factor. Using the standard design user mediator methods can have a good emphasis on providing the aims of this factor. Investigating the existence of such indications in software architecture can be a good and suitable proof to anticipate the quality do final production. We must know who are the end user of the product. If the application is for educated people then it should have such usability and if the application is for uneducated people then it should have such level of usability that they can easily learn and understand the system.
4. The analysis of Efficiency factor at architecture level: Performing processes at the minimum time with minimum resources are always the most important purposes of software designers. Doing unnecessary affairs, unnecessary use of resources like data redundancy and also improper delay (retardation) in releasing the resources are reducer samples of system output. So by investigating and controlling these points in system
   indicators, the output situation can participate and the amount of this factor in proposed architecture can be defined.
5. The analysis of Maintainability  factor at architecture level: 
   1. Analyzability: In the architecture level, we can investigate which part can be corrected or which part may cause the problem.
   2. Changeability: We can investigate the possibility of preventing the non-required affections in one part on other parts is defined by an amount of system confirmation.
   3. Stability: We can investigate the different indicator(s) separately and how it handles the negative impact. We can play with the negative scenarios and how our system will handle such negative input at the architecture level.
   4. Testability: Testability affects the amount of possibility of experiment and its operation test. To evaluate this diagnostic at the architecture level, the system can be analyzed according to indicators characteristics and their relations with each other. If the system has been divided correctly to suitable module, the system can be analyzed more easily, the changes are performed by specific affections, recoveries are simply performed in indicators and we can test any part in suitable form. So this factor can be evaluated by controlling the modularity level of the system.
6. The analysis of Portability factor at architecture level: We should investigate whether the product is under standard conformance and it follows the law. We should consider whether it is developed in standard format (n-tier).We should consider whether there are chances of product to migrate to another environment. If so how costly it will be?