The article proposed set-theoretic models of nonfunctional characteristics of software used to systematize information on nonfunctional characteristics and bring it to the common (unified) form in accordance with ISO 25010:2011, ISO 25023:2016. In addition, basic and real ontological models of nonfunctional characteristics of software are developed based on ISO 25010:2011 and ISO 25023:2016 standards. These models provide the basis for choosing the sufficient information to evaluate nonfunctional characteristics of software.
Now mankind is often requiring the software for solving the difficult problems and
the high-value software projects are rapidly developed. Therefore, software errors
threaten with disasters that lead to human and environmental casualties, disasters,
losses of time and finances. Most software failures were due to errors in the
requirements specification [
The evaluation of nonfunctional characteristics-components of quality of software
according to ISO 25010 standard [
In order to solve the problem of assessing the adequacy of the volume of
information for determining the nonfunctional characteristics in the specifications of
the requirements, it’s necessary the basic (universal) ontology for software quality
domain based on ISO 25010 [
Base ontology
Ontology for concrete software
Base ontology
Ontology for concrete software
Models of NonFunctional Characteristics-Software Quality
Components
Models of nonfunctional characteristics-components of quality of software contain
information about nonfunctional characteristics, their subcharacteristics and attributes,
taken from the standards [
According to the ISO 25010: 2011 standard, such nonfunctional characteristics as
Functional Suitability (Fs), Performance Efficiency (Pe), Usability (Ub), Reliability (Rb),
Compatibility (Cb), Security (Scr), Maintainability (Mb), Portability (Pb) are functions of
several subcharacteristics, then we represent each of the above-mentioned nonfunctional
characteristics as a function of the subcharacteristic [
Ub = f3 (A_R, Lb, Ob, U_E_P, U_I_A, Ab), where A_R – Appropriateness Recognisability, Lb – Learnability, Ob – Operability, U_E_P – User Error Protection, U_I_A – User Interface Aesthethics, Ab – Accessibility; F_S = f1 (F_Com, F_Cor, F_Appr),
P_E = f2 (T_B, R_U, Cc), Rb = f4 (Mat, Avb, F_T, Rcv),
Cb = f5 (C_E, Ib), where C_E – CoExistence, Ib – Interoperability;
Scr = f6 (Conf, Int, N_R, Acb, Auth), where Conf – Confidentiality, Int – Integrity, N_R – Non Repudiation, Acb – Accountability, Auth – Authenticity;
Mb = f7 (Mod, Rub, Anb, Mdfb, Tsb), (8) where Mod – Modularity, Rub – Reusability, Anb – Analysability, Mdfb – Modifability, Tsb – Testability;
Pb = f8 (Adb, Inb, Rpb), (9) where Adb – Adaptability, Inb – Installability, Rpb – Replaceability.
Then the sets of the subcharacteristics of nonfunctional characteristics have a form:
A = {F_Com, F_Cor, F_Appr} – the set of the subcharacteristics of Functional Suitability;
B = {T_B, R_U, Cc} – the set of the subcharacteristics of Performance Efficiency; C = {A_R, Lb, Ob, U_E_P, U_I_A, Ab} – the set of the subcharacteristics of Usability,
D = {Mat, Avb, F_T, Rcv} – the set of the subcharacteristics of Reliability; E = {C_E, Ib} – the set of the subcharacteristics of Compatibility; (2) (3) (4) (5) (6) (7) F = {Conf, Int, N_R, Acb, Auth} – the set of the subcharacteristics of Security; G = {Mod, Rub, Anb, Mdfb, Tsb} – the set of the subcharacteristics of Maintainability; H = {Adb, Inb, Rpb} – the set of the subcharacteristics of Portability.
At the same time, each subcharacteristic of nonfunctional characteristics is a function of certain attributes described in ISO 25023. Depending on the subcharacteristics from the attributes is represented as follows:
F_Com = φ1 (N_o_F, F_I_Cn, F_Aq, F_I_C), (10) (11) (12) (13) (15) (16) where Nm_o_T – Number of Tasks, R_T – Response Time, N_o_E – Number of Evaluations, Tn_T – Turnaround Time, Tsk_T – Task Time, M_A_Thr – Mean Amount of Throughput;
R_U = φ5 (O_T, N_o_Fl, N_o_E, N_IO_R_E, U_W_T, N_M_R_E, N_T_R_E, T_Cc, IO_U, N_o_L_C_D, IO_L_L, M_M_U, M_T_U, M_O_T_E), (14) where N_o_Fl – Number of Failures, N_IO_R_E – Number of IO Related Errors, U_W_T – User Waiting Time of IO Device Utilization, N_M_R_E – Number of Memory Related Errors, N_T_R_E – Number of Transmission Related Error, T_Cc – Transmission Capacity, IO_U – IO Utilization (Number Of Buffers), N_o_L_C_D – Number of Line of Code Directly, IO_L_L – IO Loading Limits, M_M_U – Maximum Memory Utilization, M_T_U – Maximum Transmission Utilizaton, M_O_T_E – Mean Occurrence of Transmission Error;
F_Cor = φ2 (O_T, N_I_C, N_D_I, C_A, Pc), where O_T – Operation Time, N_I_C – Number of Inaccurate Computations Encountered by Users, N_D_I – Number of Data Items, C_A – Computational Accuracy, Pc – Precision; where N_o_F – Number of Functions, F_I_Cn – Functional Implementation Completeness, F_Aq – Functional Adequacy, F_I_C – Functional Implementation Coverage;
F_Appr = φ3 (O_T, N_o_F, F_I_Cn, F_Aq, F_I_C, Pc), T_B = φ4 (O_T, Nm_o_T, R_T, N_o_E, Tn_T, Tsk_T, M_A_Thr),
Cc = φ6 (N_D_I, N_C_U, C_Bw, M_A_Thr, S_Db), where N_C_U – Number of Concurrent Users, C_Bw – Communication Bandwidth, S_Db – Size of Database;
A_R = φ7 (N_o_F, N_o_Tt, N_IO_D_I, Cn_D, F_Ua, Ua_IO), where N_o_Tt – Number of Tutorials, N_IO_D_I – Number of IO Data Items, Cn_D – Completeness of Description, F_Ua – Function Understandability, Ua_IO – Understandable Input and Output;
Lb = φ8 (N_o_F, O_T, E_F_L, Nm_o_T, H_Fq, E_U_D_H_S, H_Aa, where E_F_L – Ease of Function Learning, H_Fq – Help Frequency, E_U_D_H_S – Effectiveness of the User Documentation and / or Help System, H_Aa – Help Accessibility, C_U_D_H – Completeness of User Documentation and / or Help Facility;
Ob = φ9 (N_o_F, O_T, E_Cr, N_S_F, N_U_E_C, N_A_C, N_IO_R_E, N_Op, N_I_W_C_C_V_D, N_M_I, N_I_E, Ph_A, N_E_U_M), (18) where E_Cr – Error Correction, N_S_F – Number of Screens or Forms, N_U_E_C – Number of User Errors or Changes, N_A_C – Number of Attempts to Customize, N_Op – Number of Operations, N_I_W_C_C_V_D – Number of Items which Could Check for Valid Data, N_M_I – Number of Messages Implemented, N_I_E – Number of Interface Elements, Ph_A – Physical Accessibility, N_E_U_M – Number of Easily Understood Messages;
U_E_P = φ10 (N_U_R_S, N_U_E_C, O_T_P_D_O, N_O_U_H_E_O, N_I_E_W_U_S_C, N_A_C_I_E, N_E_C_W_U_S_C, T_N_E_C_T, N_F_I_U_E_T,
T_N_F_R_T_C, T_N_I_O_P), (19) where N_U_R_S – Number of Unsuccessfully Recovered Situation, O_T_P_D_O – Operation Time Period During Observation, N_O_U_H_E_O – Number of Occurrences of User’s Human Error Operation, N_I_E_W_U_S_C – Number of Input Errors which the User Successfully Corrects, N_A_C_I_E – Number of Attempts to Correct Input Errors, N_E_C_W_U_S_C – Number of Error Conditions which the User Successfully Corrects, T_N_E_C_T – Total Number of Error Conditions Tested, N_F_I_U_E_T – Number of Functions Implemented with User Error Tolerance, T_N_F_R_T_C – Total Number of Functions Requiring the Tolerance Capability, T_N_I_O_P – Total Number of Incorrect Operation Patterns;
U_I_A = φ11 (N_I_E, N_I_G_E, D_I_P_U, D_I_S_U, D_E_A, D_R_W_M_U), (20) where N_I_G_E – Number of Interface Graphical Elements, D_I_P_U – Degree of Increase the Pleasure of User, D_I_S_U – Degree of Increase the Satisfaction of User, D_E_A – Degree of Ergonomic Attractiveness, D_R_W_M_U – Degree of Real World Metaphors Use;
Ab = φ12 (E_W_S_C_B_U_U_S_D, E_W_U_S_D, F_F_R_U_S_D, S_U_S_D, P_P_S_A), (21) where E_W_S_C_B_U_U_S_D – Extent to which Software Can Be Used by Users with Specified Disabilities, E_W_U_S_D – Effectiveness of Work of Users with Specified Disabilities, F_F_R_U_S_D – Freedom from Risk for Users With Specified Disabilities, S_U_S_D – Satisfaction of Users With Specified Disabilities, P_P_S_A – Presence of Properties That Support Accessibility;
Avb = φ14 (O_T, T_T_D_W_S_I_S, N_O_B, T_D_T), where T_T_D_W_S_I_S – Total Time During which the Software Is in an UpState, N_O_B – Number of Observed Breakdowns, T_D_T – Total Down Time;
F_T = φ15 (N_o_Fl, N_T_C, N_Bd, N_o_F, N_I_O), where N_Bd – Number of Breakdowns, N_I_O – Number of Illegal Operations;
Rcv = φ16 (O_T, N_Bd, T_t_R, D_T, N_Rs, N_Rn, Ray), where T_t_R – Time to Repair, D_T – Down Time, N_Rs – Number of Restarts, N_Rn – Number of Restoration, Ray – Restartability;
C_E = φ17 (O_T, N_o_Fl, N_o_F, N_D_I),
Ib = φ18 (O_T, N_D_F_R_T, N_D_F_B_E, N_I_P, D_Eay), where N_D_F_R_T – Number of Data Formats Regarded by Tool, N_D_F_B_E – Number of Data Formats to Be Exchanged, N_I_P – Number of Interface Protocols, D_Eay – Data Exchangeability;
Conf = φ19 (O_T, N_I_O, N_T_C, N_I_D_C, N_D_I, N_A_T, N_C_R, A_Ca,
N_D_I_C_E_D, N_D_I_B_R_E_D), Mat = φ13 (O_T, N_o_Ft, N_o_Fl, P_S, N_T_C, N_R_F, N_C_F, F_D_A_T_C, F_Rn, F_Rl, M_T_B_F, T_My, E_L_F_D, F_Dy), (22) where N_o_Ft – Number of Faults, P_S – Product Size, N_T_C – Number of Test Cases, N_R_F – Number of Resolved Failures, N_C_F – Number of Corrected Faults, F_D_A_T_C – Failure Density Against Test Cases, F_Rn – Failure Resolution, F_Rl – Fault Removal, M_T_B_F – Mean Time Between Failures, T_My – Test Maturity, E_L_F_D – Estimated Latent Fault Density, F_Dy – Fault Density; (23) (24) (25) (26) (27) (28) (30) (31) where N_I_D_C – Number of Instances of Data Corruption, N_A_T – Number of Access Types, N_C_R – Number of Controllability Requirements, A_Ca – Access Controllability, N_D_I_C_E_D – Number of Data Items Correctly Encrypted Decrypted, N_D_I_B_R_E_D – Number of Data Items to be Required Encryption Decryption;
Int = φ20 (O_T, N_I_O, N_T_C, N_I_D_C, N_D_I, N_A_T, N_C_R, A_Ca), (29)
N_R = φ21 (N_E_P_U_D_S, N_E_R_N_R_P), where N_E_P_U_D_S – Number of Events Processed Using Digital Signature, N_E_R_N_R_P – Number of Events Requiring Non-Repudiation Property;
Acb = φ22 (N_A_S_D_R_S_L, N_A_A_O), where N_A_S_D_R_S_L – Number of Accesses to System and Data Recorded in the System Log, N_A_A_O – Number of Accesses Actually Occured;
Auth = φ23 (N_P_A_M), where N_P_A_M – Number of Provided Authentification Methods;
Mod = φ24 (O_T, N_o_Fl, N_R_F, N_M_M, N_V, N_o_F, N_M), where N_M_M – Number of Modifications Made, N_V – Number of Variables, N_M – Number of Modules;
Rub = φ25 (F_Cy, N_F_Cy, V_Rn, Aay, Tay, C_Ra), where F_Cy – Functional Commonality, N_F_Cy – Non Functional Commonality, V_Rn – Variability Richness, Aay – Applicability, Tay – Tailorability, C_Ra – Component Replaceability;
Anb = φ26 (N_o_Fl, N_D_I, Er_T, N_I_R_B_L, N_D_F_R, A_T_C), (35) where Er_T – Error Time, N_I_R_B_L – Number of Items Required to Be Logged, N_D_F_R – Number of Diagnostic Functions Required, A_T_C – Audit Trail Capability;
Mdfb = φ27 (O_T, N_R_V, N_R_F, Er_T, N_o_F, C_C_Ca, N_T_C_P_B_M,
N_T_S_P_A_M), where N_R_V – Number of Revised Versions, C_C_Ca – Change Control Capability, N_T_C_P_B_M – Number of Troubles within Certain Period Before Modification, N_T_S_P_A_M – Number of Troubles in Same Period After Modification; Tsb = φ28 (O_T, N_T_C, N_R_F, N_B_T_F_R, N_T_D_O_S, N_Cp), (37) where N_B_T_F_R – Number of Built in Test Functions Required, N_T_D_O_S – Number of Test Dependencies on Other Systems, N_Cp – Number of Checkpoints; Adb = φ29 (N_o_F, O_T, N_o_Ft, P_U_F, N_D_I, N_D_S, Aa_D_S, H_E_A, S_E_A, N_O_F_T_W_N_C_A, T_N_F_W_T_D_E), (38) where P_U_F – Porting User Friendliness, N_D_S – Number of Data Structures, Aa_D_S – Adaptability of Data Structures, H_E_A – Hardware Environmental Adaptability, S_E_A – Software Environmental Adaptability, N_O_F_T_W_N_C_A – Number of Operational Functions of which Tasks Were Not Completed or Adequated, T_N_F_W_T_D_E – Total Number of Functions which Were Tested in Different Environment;
Inb = φ30 (N_o_Ft, N_S_O, N_I_S, E_o_I), (39) (32) (33) (34) (36) where N_S_O – Number of Setup Operations, N_I_S – Number of Installation Steps, E_o_I – Ease of Installation;
Rpb = φ31 (N_o_F, N_D_I, N_Et), (40) – the set of attributes for Analysability; AI = {O_T, N_R_V, N_R_F, Er_T, N_o_F, C_C_Ca, N_T_C_P_B_M, N_T_S_P_A_M} – the set of attributes for Modifability; AJ = {O_T, N_T_C, N_R_F, N_B_T_F_R, N_T_D_O_S, N_Cp} – the set of attributes for Testability;
AK = {N_o_F, O_T, N_o_Ft, P_U_F, N_D_I, N_D_S, Aa_D_S, H_E_A, S_E_A, N_O_F_T_W_N_C_A, T_N_F_W_T_D_E} – the set of attributes for Adaptability; AL = {N_o_Ft, N_S_O, N_I_S, E_o_I} – the set of attributes for Installability; AM = {N_o_F, N_D_I, N_Et} – the set of attributes for Replaceability.
Considering the resulting sets of attributes and sub-characteristics of nonfunctional
characteristics, obtained functions of dependencies of characteristics on
subcharacteristics and characteristics on attributes, as well as the relationship between the
concepts of ontology "depends on", we develop basic ontological models of
nonfunctional software characteristics (principles of developing basic ontological models are
presented in [
Then, for example, base ontological model of Functional Suitability is: OFs = {{F_S, A, I, J, K}, “depends on”, {f1, φ1, φ2, φ3}} = ={{fsa1,…,fsa19}, “depends on”, {f1, φ1, φ2, φ3}}, (41) where fsa1 = F_S, {fsa2,…,fsa4} € A, {fsa5,…,fsa8} € I, {fsa9,…,fsa13} € J, {fsa14,…,fsa19} € K.
Ontologies (ontological knowledge base), which are developed by models (41)
etc., are filled up based on the information taken from ISO 25010 [
The ontological models of concrete software nonfunctional characteristics have the form, for example, ontological model of Functional Suitability is:
OFs_real = {{fsa1,…,fsam}, “depends on”, {f1, φ1, φ2, φ3}}, (42) where m≤19 – the number of attributes of subcharacteristics of functional suitability, available in the specification requirements for the specific software, as well as the number of functional suitability subcharacteristics that can be calculated based on available attributes.
Ontologies (ontological knowledge bases), which are developed on the models
(42) etc., are filled up based on the information taken from the specification
requirements for the specific software [
Practical case of selection of accurate scope of information for evaluation of the
nonfunctional characteristics is represented at [
Conclusions The urgency of the task of automation of evaluating the life cycle initial phases based on analysis of specifications necessitates the development of software quality models, in particular, the models of nonfunctional characteristics-software quality components.
This article proposed set-theoretic models of nonfunctional characteristics of software used to systematize information on nonfunctional characteristics and bring it to the common (unified) form according to ISO 25010: 2011, ISO 25023: 2016 standards, as well as basic (universal) ontological models and ontological models of specific software nonfunctional characteristics, based on the requirements of ISO 25010 and ISO 25023standards. These models are basis for selecting the sufficient volume of information to evaluate the software nonfunctional characteristics.
The proposed models will become the theoretical basis for the model and method of activity of the intelligence agent on the basis of the ontological approach for assessing the specifications of the requirements for software, the operation of which will be based on the comparison of ontologies. Such the intelligence agent will compare the ontology of the specific software with basic ontology and determine how many and which attributes are not sufficient to determine the particular nonfunctional characteristic, which will make the decision on the adequacy or lack of information on nonfunctional characteristics in the specification requirements to software.