On Issues With Software Quality Models

Published Date: 02 Nov 2017

Abstract:

Software quality model & metrics plays an important role in measurement of software system quality. A quality model defines the various software metrics and measurement techniques that an organization uses to measure quality of system. Currently, different types of software quality models & metrics are used to build quality of software in industry. During our research on measuring software quality using quality models, we identified many issues that are related with existing software quality models. The objective of this paper is to identify a range of issues in existing software quality models and provides some ways of software quality assessment.

Key Terms:

CMS (Content management system)

ISO (International standard organization)

1. Introduction:

"Quality comprises all characteristics and important features of a product or system which relate to the completion of defined requirements". With the high level innovations in our software industry, the software quality also gains major importance to focus more about. The main objective of software industries is to balance cost and quality to compete its competitors. In the past several years, software industry has created different type of products, such as open source software, Ecommerce, CMS, & Customized solutions. With these new products, the expectations of the customers also increase in terms of quality and usability. Different organizations such as ISO and IEEE

try to standardize software quality models, and combining and relating their characteristics and

sub-characteristics. Software metrics are used as tools to measure programs source code, architecture and performances. We use software metrics and software models for software quality assessment [3]. But there are still some open issues with many models. In the first part of this paper, we review software assessment methods, some problems, and solutions. There are a number of requirements that need to be met by a quality model, in order to get that software a quality model correctly capture quality requirements, and correctly reflects how well those requirements have been met. A quality model links together and defines various software metrics and measurement techniques that organization uses. [4]

By working in software quality patterns, different things should be taken into account when using large software systems.

We start by following quality metrics and measurement approaches. A major example will be the lack of requirements quality estimation, proper test planning strategy & proper time estimation of quality process which may affect quality factors such as the cost & profit. Proper documentation of software quality process is another major problem, because changing requirements usually requires updating the documentation.

The next part of this paper is section 2 which will describe what software quality is all about; section 3 will describe some of open issues related to existing software quality models. In section 4 we will describe our approach to Software Quality Evaluation which contains series of steps for effective software quality assessment. Section 5 will summarize the main recommendation for future research on software quality improvements.

2. Software Quality:

Software Quality means quality of software product, its services, information, process & people. It means transforming user requirements into measurable characteristics which provide product satisfaction. The quality is now considered as an important element in business success. Furthermore, the quality of software product is essential since for example in some critical systems – such as real-time systems, control systems, etc. – The poor quality may lead to financial loss, mission failure, permanent injury or even loss of human life. There are several definitions for "software Quality" term, for examples, it is defined by the IEEE [1990] as the degree to which a system, component or process meets specified requirements and customer (user) needs (expectations). Pressman [2004] defines it as "conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software." [5]

The ISO, by contrast, defines "quality" in ISO 14598-1 [ISO, 1999] as "the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs," and Petrarch [1999] defines it as "the existence of characteristics of a product which can be assigned to requirements." There are a number of quality models in software engineering literature, each one of these quality models consists of a number of quality characteristics

(or factors, as called in some models). These quality characteristics could be used to reflect the quality of the software product from the view of that characteristic. Selecting which one of the quality models to use is a real challenge.

The progress in the field of software quality has been time-consuming & ambiguous. Software quality models & software metrics are known as major reference in the field of software quality assessment but there is still no clear methods for assessing software quality via software metrics.

3. Open Issues

The following result shows the modification and improvement of existing process for software quality assessment.

3.1 Human Estimation

A person analyzes the source code or software products and judges their performance and quality. Human evaluation is subjective measurement of quality & considered as the best source of software quality assessment.

The Problem:

– Different view: Software evaluation of one person cannot be acceptable by other person because different persons have different views on product quality. For example to listen the other people advise for choosing a different operating system or a word processor.

– Impractical approach: Assessing the quality of software by your own is not practical: It is impossible that every person have that level of technical knowledge and the ability to evaluate the software performance and quality. It is difficult and time consuming task.

The solution: Similar taste congregate in groups: To categorize the people who deal with software at different levels by considering their need for software quality, and then we can design a custom models for each group, or can define range of values which are acceptable for similar people. For example, most of end users have similar ideas about software quality, but these ideas maybe different for those people who deal with the maintenance & evolution of the same software.

3.2 Software Metrics

Software metrics are standards of software quality measurement, used to judge the attributes of something such as quality or complexity, in an objective manner.

The Problem:

– Evaluation of software code quality is not enough: Considering a source code without execution is the same as considering the body without its sprit. Software metrics are like e.g. coupling, complexity, computing size, filiations, & cohesion. These attributes are related to code only but the quality of software is not only code dependent.

– Metrics evaluation by value: it is hard to find a numerical value for quality by using different views of quality, acceptable by all the people. Also having different views affect software categorization by considering the numerical value as the only parameter used for software evaluation.

The Solution: Code without execution is not valuable: The value of software metrics can be changed by runtime values for better results. Also, using good design pattern & architecture could increase the software quality. Thus, we want to consider the architectural quality of software by using design patterns in the software architecture.

3.3 Quality Model

A quality model is used to better explain of our view of quality. Some quality models can predict fault proneness with reasonable accuracy. Other quality models are used to evaluate several quality characteristics but fail at providing reasonable accuracy, from lack of data mainly.

The Problem:

–Whether all sub-characteristics equal in affecting software characteristics: As quality model defines the relationship between quality characteristics and sub-characteristics. For example: as mentioned in theory that Adaptability and Insatiability are two sub-characteristics related to Portability, the question is: If we get the value of Adaptability as A and the value of Insatiability as B, then whether the value of Portability equals to A+B or (any factor) *A + (any factor)* B.

–Main quality concepts are missing: Quality does not distribute in specific part, when we talk about software quality, we talk about assessing entire items which are part of the concept of quality.

The Solution:

–Coefficient: Objective quality is dependent on sets of software attributes and client’s requirements. These attributes are explained as different level of characteristics and sub-characteristics in quality models, but the relation and impact of each characteristic and sub-characteristic should be distinguished. By using coefficients, models can be made more meaningful for different persons which relate characteristic and sub-characteristic.

3.4 Requirements Quality Estimation:

Requirements quality estimation allows to define, measure, improve and manage the quality of the requirements specifications.

The Problem:

–Volatile requirements: Requirements which keep on changing during software development. Quality of requirements is affected due to changing requirements of client’s over time & changing business needs.

–3 C’s Issue: In order to achieve high quality, requirements specifications need to be checked against the 3C’s - Consistency, Completeness and Correctness. This is especially difficult when working with both natural language requirements and associated semi-formal modeling representations. [6]

The Solution:

–Automated tools analyzer: To perform semi-automated checking of natural language and semi-formal requirements modeling.

–Use case interaction patterns: We use a concept of essential use case interaction patterns to perform the correctness and completeness analysis on the semi-formal representation. We highlight potential inconsistencies, incompleteness and incorrectness using visual differencing in our support tool.

3.5 Planning/Time Estimation:

Based on high-level understanding of software product, we design a project plan including all the major features & milestones of the project with their estimated completion dates w.r.t time.

The Problem:

–Requirements handling issues: Quality of requirements is affected due to changing nature of requirements from client’s over time & changing business needs. It’s difficult to make a fix planning structure according to volatile nature of requirements.

–Bug issues: Improper planning estimation leads us towards bug’s generation in software products.

–Complexity issues: improper planning creates complexity in overall project lifecycle management.

The Solution:

–Automated support: Using automated tools, test plan templates, release notes & different type of automated tools for planning estimation w.r.t time.

3.6 Documentation

Software documentation is the most important manifest of the software product. It is the guide which includes technical manuals, user manuals and other instructions that facilitate the use and operation of a software product or services. The documentation may include where necessary, the source code, error codes and their meanings.

The Problem:

–Requirements Change issue: By changing need of the customers, we have to update the documentation accordingly, if we did not do so this will lead us towards miscommunication and complexity in different phases of software development life cycles.

–Miscommunication: between end users, developers & all the stakeholders which are directly and indirectly related to the software product.

The Solution:

–Change management by updating document: By enlisting test cases, test scenarios, documents updating with changing requirements & solutions.

3.7 User Acceptance

User Acceptance Testing is often the final step before release of the application. Usually the end users use & test the application before accepting it. Acceptance testing gives the end users the confidence that the application being delivered to them meets their needs.

The Problem:

–Files transferring issues: Due to missing some components of software product while transferring files to end users may cause the problem.

–Load/Stress issues: when end users use the software product by giving maximum peak input values, then application might crash by it.

The Solution:

–Retesting on production environment: QA team can test the quality of deployed software product on production server.

–Re-download testing: Download that software product files again, and build it again to test.

4. Our approach to Software Quality Evaluation

To highlight some solutions of the above mentioned problems, we deal with the 13 steps needed to apply our approach to software quality evaluation, which solves some of the open issues described above.

4.1 Step by Step:

To implement software quality assessment we need to implement the following steps:

Step1: Choosing Category of People: Select at least single person from the defined category of people, which our software evaluation will be implemented for, for example: programmers, customers, end users & other stake holders.

Step2: Identify Sample Program: Choose a sample program (SP) to be considered as sample evaluation set of our model.

Step3: Build a Quality Model. The creation of quality model decomposes in two main tasks generally:

– Choosing a super-characteristic.

–Choosing and organizing sub-characteristics related to super-characteristic [10].

Step4: Human Evaluation: Small group, or at least single person from the group, must look in the sample program SP and evaluate the quality characteristics. The evaluation could be in form of numerical value or identifying different levels by using Lickert scale.

Step5: Requirements quality estimation: To improve and manage the quality of the requirements specifications.

Step6:

Planning/time estimation: Proper planning estimation should be conducted to minimize the complexities during process.

Step7:

Documentation: to check that document has been updated according to requirements.

Step8: Compute Software Metrics over SP. By using software metrics we evaluate SP numerical values related to software internal attributes.

Step9: Machine Learning Tools(e.g. WEKA, JRip): To generate the relation between human evaluation of software quality and value of software metrics.

Step10: Computing Software Metrics over EP. Software metrics are used to assess the values of internal attributes over the EP in the same way as they were for the evaluation of SP

Step11: Adapting Metric. By using ratio over the values from Step10 and Step8, we can relate these numerical values. The following method will be used for relation evaluation:

Step12: Software Evaluation. Now, we can evaluate other programs (EP) by applying the adjusted RULE (from Step11) and software metrics evaluation over the EP.

Step 13: User Acceptance: By user acceptance testing, end users can get the idea that software product is implemented according to their needs.

5. Conclusion

In this paper, we reported our experience in using software quality models & metrics to assess software quality. Our conclusions are:

– Software quality models must clearly define their target users and define the relationship between super-characteristics and sub-characteristics to be more useful and comparable.

–Software quality models must be used to know other aspects of software such as their architecture, performance & runtime adequacy through the assessment of design patterns.

– More experience is needed to describe out advantage and disadvantage of our quality assessment method.

– Each organization must use different metric approaches to measure different quality attributes according to their benefit.

–Requirements quality estimation must be taken into account to solve the issues of 2 C’s ( consistency, completeness and correctness).

–Proper planning/time estimation must be followed to handle the complexities issue.

–Documentation must be updated along with the requirements change. & user acceptance test must be conducted to verify the correctness of software product services w.r.t. customer’s defined requirements.

We would like to discuss the identified open issue and their proposed solutions with the participants and opportunities of improving software quality models further.

Future Scope:

We have been further working on the analysis of software quality factors and issues particularly in software companies in Pakistan. The authors are trying to find out more complex issues which should be resolved to provide good quality assessment methods for different organizations.