The software quality is basic factor for its successful implementation and exploitation.
According to the standards of ISO 25010 [1], ISO 25030 [2] the software quality is the ability of the software to meet the stated and predicted needs when using under certain conditions. This definition differs from the definition of software quality of ISO 9000 [3] mainly because this definition of software quality provides for needs satisfaction, while the definition of ISO 9000 [3] provides for requirements satisfaction.The development of modern software system is user-oriented [4], namely the software quality is the important characteristic in terms of the stakeholders (especially customers). Obviously, even attracting the best experts for the development of technologies and standards of the software systems quality assurance doesn't guarantee sufficient software quality.
The essential and integral feature of modern software systems is their complexity, so the attempts to describe the software objects with abstraction from their complexity lead to the abstraction from their essence. The constant growth of the software functions complexity inevitably leads to the increasing their volume and laboriousness (effort applied) [5].One of the most important causes of poor quality of large software projects are the increasing the number of components (subsystems) and the interfaces between them, and uncontrolled complexity of software systems, in opinion of the researchers The Standish Group International [6].Research [6] shows that statistics of success of small, moderate, medium, large and grand software projects is significantly different -Fig. 1. Analysis of Fig. 1 provides the conclusion that 62% of small projects are successful while both only 6% of large projects and only 2% of grand projects are successful, i.e. small projects are ten times more successful than large and thirty times more successful than grand projects. This conclusion is confirmed by the statistics of software projects, that is presented in [5], on the basis of the function points as the main modern units of software size -Fig. 2.
During the software project, we often can not estimate the share of the informational indeterminacy of the project. Identification of the information, that appears in the process of interaction of "subsystems-interfaces-data-external influences", is especially difficult. Identification of future properties of developed software, that will display this information, is even more difficult task.
The cause of appearance of informational indeterminancy of the project is the low level of knowledge documentation, especially at the system level (Fig. 3 [7]). Fig. 4 depicts the situation, characterized by premature design decisions and their documentation, prior to understanding the design. Fig. 4 shows an area, referred to as the "knowledge gap," that is the result of the low level of knowledge documentation and the root cause of many engineering failures [8].The size of knowledge gap is not constant for software project -during the lifecycle it can increase and decrease, since new information appears and it should be taken into account.The presented on Fig. 4 viewpoint on the knowledge gap does not quite correspond to reality. We assume that partial consideration of the subject domain information in the software quality models and impact of this information on only finished product lead to increase of the knowledge gap size during the life cycle (new boundaries of knowledge gap are delineated dotted line on Fig. 5), that can be the cause of the software accidents and disasters [9]. For safe software functioning the knowledge gap size is desirable to reduce. This can be done by the consideration of as much subject domain information in the software quality models and standards.Reducing the knowledge gap size will provide the improvement of the software quality.
Given the above, all the available knowledge and information about the software system can be represented as the diagram, which has the sector that reflects the volume of unsufficient (unknown) information (knowledge gap) -Fig. 6. This sector consists of unconsiderated subject domain information.The size of this sector is not determined, because it is unclear what information and how much information is unknown. Sector of the unknown information should be narrow by fully consideration of subject domain information.The smaller size of sector of the unknown information indicates to the higher quality and safer work of software system, i.e. the main task is the reducing the share of unknown information about software system. Then the actual task is the assessment of information sufficiency as to software (for example, the possibility of obtaining of trustworthy information on the measures for calculation of the values of the software quality characteristics and subcharacteristics), on the basis of which software quality (by ISO 25010 [1]) is determinated.Incompleteness and inaccuracy of such information lead to fall of veracity of software quality assessments.So the purpose of this study is the development the approach to the assessment of information sufficiency for software quality determination.
The most used model for software quality assessment is the model ISO 25010 [1].The idea of this standard is that each of the characteristics is something we can analyse directly at the software product.Model ISO 25010 proposes to assess the software quality as a function of the eight characteristics, each of which is a function of several subcharacteristics (total 31 subcharacterics).But subcharacteristcs, in turn, are the functions of several measures.Analysis of [10][11][12][13], ISO 9126-2 [14], ISO 9126-3 [15] and revised on their basis ISO 25023 [16] provide the determination the dependence of quality subcharacteristics from the measures (total 203 measures).The basic idea is that the assessment of quality, its characteristics and subcharacteristics should be comprehensively performed, considering all these characteristics, subcharacteristics and measures accordingly. Some of the measures are part of several quality subcharacteristics.So, if such measures are inaccurate or missing, then simultaneously use of these subcharacteristics in determining the several quality characteristics will significantly affect to the veracity of the software quality estimates.In such situation the condition of the mitigation of influence of these subcharacteristics cross-correlation is the important when using them in the quality models.Such mitigation is performed by identifying the joint measures, improving the accuracy of their values, or, if possible, limitating the simultaneous using of subcharacteristics that containing the same measures.
The information on determining the software quality characteristics and subcharacteristicsis conveniently presented as semantic networks or other structures, which provide the displaying of the causal relationships between concepts. One of these structures is ontology.The advantages of ontology are the systematic approach to the study of the subject domain, the possibility of the holistic filing of known subject domain information, the identification of the overlaps and gaps in knowledge on the basis of the visualization of missing logical relationships.
Researhers have already used the ontologies in software design.E.Burov proposed methods and tools for deve-lopment of software systems based on the ontological models [17,18]. I.Shostak & I.Butenko developed the ontological models and methods of forming the profile during the software certification [19]. L.Babenko proposed the ontological approach to specifying the features of software systems and their components [20].We use ontologies for assessment of information sufficiency for software quality determination. The components of the base ontology are: base ontology for Functional Suitability (Fig. 8), the base ontology for Reliability (Fig. 10), the base ontology for Usability (Fig. 12), the base ontology for Security (Fig. 14) , base ontology for Performance Efficiency (Fig. 16), the base ontology for Maintainability (Fig. 18), the base ontology for Compatibility (Fig. 20), the base ontology for Portability (Fig. 22).
The developed base ontology provides the following conclusions: 1) Functional Suitability: subcharatceristcs Functional Completeness, Functional Appropriateness In addition, there are measures, which are included in the formulas of several subcharacteristics of different characteristics (for example, measure Operation Time is included in subcharacteristics of all 8 quality characteristics).One of the basic properties of the base ontology is precisely the possibility of manifestation of crosscorrelation of characteristics and subcharacteristics when using them in quality models.Because the important condition is the mitigation of the cross-correlation of such subcharacteristics when using them in quality models, therefore during assessment of the software quality it is necessary to pay special attention to those measures, which are part of simultaneously several subcharacteristics.
Ontological approach to the assessment of information sufficiency for software quality determination (by ISO 25010:2011 [1]) consists of the next steps: 1) analysis of the software requirements specification for the concrete software project for the presence of measures, that necessary for determining the quality characteristics and subharacteristics of software project and software; 2) the development of ontology for determining the quality of the concrete software; 3) comparison of the developed ontology with base ontology for software quality determination, components of which are shown on Fig. 8, 10, 12, 14, 16, 18, 20, 22; 4) identification of measures, which are absent in the ontology for determination of the quality of the concrete software; 5) identification of quality characteristics and subcharacteristics, that cannot be calculated on the basis of the existing measures (at the same time should remember about the basic idea of ISO 25010 [1], which says that the quality assessment should be performed comprehensively, considering all quality characteristics;the assessment of quality characteristics also should be performed comprehensively, considering all subcharacteristics; the assessment of quality subcharacteristics, in turn, should be performed comprehensively, considering all measures); 6) the presence of subcharacteristics and characteristics, values of which cannot be determined on the basis of measures, that available in the software requirements specification, indicates the need to complement of this specification by the neccessary measures (at this stage adding the necessary information and deleting other relevant information are possible); 7) repeating the steps 2-6 until all quality characteristics and subcharacteristics will be possible to identify or until the conclusion will be formed, that data for software quality determination are insufficient.
During the study the specification of automated system for large-format photo print was analyzed.On the basis of the specification analysis the available measures were determined, that necessary for determining the quality characteristics and subcharacteristics of software project and software.These measures provides the development of ontology for determination of the quality of this software, consisting of the: onto-logy for Functional Suitability (Fig. 9), ontology for Reliability ( Fig. 11), ontology for Usability (Fig. 13), ontology for Security (Fig. 15), ontology for Performance Efficiency (Fig. 17), ontology for Maintainability (Fig. 19), ontology for Compatibility (Fig. 21), ontology for Portability (Fig. 23) for concrete software project.
The comparison of the developed ontology for software project of automated system with fragments of the base ontology for subject domain "Software engineering" provides to find that in the ontology for project the 4 measures (Number of Functions, Operation Time, Number of Data Items, Number of Test Cases) are missing.
In addition, on the basis of the comparison of the ontology for software project of automated system for large-format photo print with base ontology was found that in the concrete ontology the data for determination of some quality characteristics and sub-characteristics are insufficient due to the absence of the above 4 measures.
Analysis of Fig. 8 and Fig. 9 provides the conclusion that the data for determination of all 3 subcharacteristics of Functional Suitability are insufficient. Therefore, none of subcharacteristics cannot be calculated, so Functional Suitability of software project cannot be determined too, and therefore the quality of the software project cannot be determined. Analysis of Fig. 10 and Fig. 11 provides the conclusion that the data for determination of all 4 subcharacteristics of Reliability are insufficient. Therefore, none of subcharacteristics cannot be calculated, so Reliability of software project cannot be determined, and therefore the quality of the software project cannot be determined. Analysis of Fig. 12 and Fig. 13 provides the conclusion that the data for determination of 3 from 6 subcharacteristics of Usability are insufficient. Therefore, 3 subcharacteristics cannot be calculated, so Usability of software project cannot be determined, and therefore the quality of the software project cannot be determined. Analysis of Fig. 14 and Fig. 15 provides the conclusion that the data for determination of 2 from 5 sub characteristics of Security are insufficient. Therefore, 2 sub characteristics cannot be calculated, so Security of software project cannot be determined, and therefore the quality of the software project cannot be determined. Analysis of Fig. 16 and Fig. 17 provides the conclusion that the data for determination of all 3 sub characteristics of Performance Efficiency are insufficient. Therefore, none of sub characteristics cannot be calculated, so Performance Efficiency of software project cannot be determined, and therefore the quality of the software project cannot be determined. Analysis of Fig. 18 and Fig. 19 provides the conclusion that the data for determination of 4 from 5 subcharacteristics of Maintainability are insufficient. Therefore, 4 subcharacteristics cannot be calculated, so Maintainability of software project cannot be determined, and therefore the quality of the software project cannot be determined. Analysis of Fig. 20 and Fig. 21 provides the conclusion that the data for determination of all 2 subcharacteristics of Compatibility are insufficient. Therefore, none of subcharacteristics cannot be calculated, so Compatibility of software project cannot be determined, and therefore the quality of the software project cannot be determined. Analysis of Fig. 22 and Fig. 23 provides the conclusion that the data for determination of 2 from 3 subcharacteristics of Portability are insufficient. Therefore, 2 subcharacteristics cannot be calculated, so Portability of software project cannot be determined, and therefore the quality of the software project cannot be determined. Then the lack of 4 these measures in software requirements specification led to the impossibility of detarmination of all quality characteristics and the quality of the project and developed software.
For the concrete software project there are characteristics and sub characteristics, that are impossible to define or possible to insufficient define according to available information in the specification. Because the proposed approach to the assessment of information sufficiency for software quality determination is iterative, then the complement of the software requirements specification was conducted. The measures Number of Functions, Number of Data Items were added, and then the new version of the ontology for determination of the quality of the concrete software was created.
Comparative analysis of the new version of ontology with the base ontology showed that changes have occurred in the determination of Functional Completeness, Capacity, Appropriateness Recognisability, Analyzability, and Replaceability of the concrete software project. But the lack other 2 measures in specification (Operation Time, Number of Test Cases) leaves impossible the determination of all software quality characteristics and the quality of the project and developed software (still insufficient information).The process of complement the specification is iterative. But customer of developed lautomated system has decided that further complement of the specification is economically inexpedient therefore the conclusion about insufficient data for determination of the software quality was formed.
The measures analysis is an effective mean of assessing the software quality upon availability of veracity information for it conduct. One of the factors affecting the veracity of such information is sufficiency of the volumes of information about measures in the SRS. Therefore, solving the task of assessment of sufficiency information about measures in the SRS generally enhances the veracity of software quality assessment.
In the analysis of software quality subcharacteristics (as sources of information) the cross-correlation of these subcharacteristics because they have joint measures. Correlation of subcharacteristics, that displayed by base ontology, should be considered because it can reduce the accuracy and veracity of software quality assessment.
Knowledge of experienced professionals on interference and correlation of software quality subcharacteristics are valuable, so they should be stored and used in assessing the software specifications in terms of information sufficiency for software quality characteristics and subcharacteristics.
For displaying of these knowledge we selected ontologies that became the basis of the approach to the assessment of information sufficiency for software quality determination (according to ISO 25010: 2011).
The proposed ontological approach provides the development of recommendations for improvement of the software specification that illustrated by the example of the assessment of information sufficiency for determination of quality for software of automated system of large-format photo print.