=Paper=
{{Paper
|id=Vol-3309/paper1
|storemode=property
|title=A Risks management method based on the quality requirements communication method in agile approaches
|pdfUrl=https://ceur-ws.org/Vol-3309/paper1.pdf
|volume=Vol-3309
|authors=Vasyl Yatsyshyn,Oleh Pastukh,Andriy Lutskiv,Viktor Tsymbalistyy,Nataliia Martsenko
|dblpUrl=https://dblp.org/rec/conf/ittap/YatsyshynPLTM22
}}
==A Risks management method based on the quality requirements communication method in agile approaches==
https://ceur-ws.org/Vol-3309/paper1.pdf
A Risks management method based on the quality requirements
communication method in agile approaches
Vasyl Yatsyshyna, Oleh Pastukha, Andriy Lutskiva , Viktor Tsymbalistyya, Nataliia Martsenkob
a
Ternopil Ivan Puluj National Technical University, Ruska, 56 street, Ternopil, 46001, Ukraine
b
West Ukrainian National University, Lvivska, 11, Ternopil, 46009, Ukraine
Abstract
In this paper proposed a risks management method based on the quality requirements
communication method and SEI risks model. The main value of the method is to increase
completeness and traceability of risks during agile software development. This has been
achieved by risks identification and its integration to the quality requirements models.
Additionally, in the article proposed a formalization of SEI model and the structure of agile
software development process, built hierarchical tree with the bipartite vertex at the attributes
level (requirement-risk).
Keywords 1
Risk, software, management, agile, quality requirements
1. Introduction
Software engineering characterized by using and application of different kinds of software life cycle
models. Choosing of the concrete model is defined and dependent from the type of designed system,
for instance, software for general market, critical and medical systems, real-time system, etc [1].
Software life cycle models, except for general processes, include a set of activities and sub processes,
which are oriented to ensure the quality of the end-user software in the way of taking into account
project budget and deadlines.
An important aspects and processes of software engineering are risks identifying, management and
monitoring at the different stage of life cycle. Different results would have received at the each life
cycle phase in the relation of methods and technologies, which are using to manage risks. In this article,
we proposed the method of risks management and monitoring at the stages of software life cycle in case
of using agile approach. The main content of this method assumes using and application of requirements
communication method [10], which take into account SEI model [2].
In general, a risk of software may defined as a possibility of decreasing quality of final product,
increasing in cost of software development, a delay in the completion of the development or a disruption
of the project. It has relations to the inefficiency, imperfection, and immaturity of the methods,
techniques and technology processes at the different stage of life cycle.
From the point of project development view, the most important risks are technical risks.
Considering that, it is very fatefully to identify technical risks in the relation of the requirements,
because they form a fundament of the future project development and evolution.
Generally, risks divide by two groups: internal and external [3,4].
Internal risks can be presented like a risk events, which has relations to the internal features of some
software project development. Development team wield tools and technologies that help to identify,
control and manage these events. For example, risk managers use CASE-tools to estimate a duration of
some activities, to define deadlines, to make cost estimation and recruitment.
ITTAP’2022: 2nd International Workshop on Information Technologies: Theoretical and Applied Problems, November 22–24, 2022,
Ternopil, Ukraine
EMAIL: vyatcyshyn@gmail.com (A. 1); oleg.pastuh@gmail.com (A. 2); l.andriy@gmail.com (A. 3); nata.martsenko@gmail.com (B)
ORCID: 0000-0002-5517-6359 (A. 1); 0000-0002-0080-7053 (A. 2); 0000-0002-9250-4075 (A. 3); 0000-0003-0947-5179 (B);
©️ 2021 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
External risks can be defined as risk events, which appear outside of development team competition
and team does not affect to these features (market of software, laws, etc.) [5].
Project Management Institute (PMI) defined system approach to the process of risks management
and display it in Project Management Body Of Knowledge (PMBOK).
PMBOK define six main processes of risks management:
Planning risks management;
Risks identification;
Qualitative risks analysis;
Quantitative risk analysis;
Planning risks reactions планування реакції на ризики;
Risks Control and management.
There are many articles and publications devoted to the risks management research [6-8], some of
these ideas and concepts are implemented in the standards of software development. The most useful
and practical paradigm of risks project management is developed by Software Engineering Institute [7].
2. Analysis of risks management approaches
Many formal and non-formal methods are used to identify and evaluate risks of software failures.
The choosing one or another method defines by software application (critical software, software for
general market) and criticality of consequences when failures are on.
The most famous formal methods of risks failures analysis is Event Tree Analysis (ETA), Fault Tree
Analysis (FTA) and Failure Modes and Effects Analysis (FMEA). Its application is effective in case of
complex computer systems designing at the stage of requirements analysis, system architecture design
and implementation. These methods help to analyze possible failure modes, develop designs and
technical solutions to minimize the consequences of failures.
Event Tree Analysis method provide identification of components in case of failure events which
have influence on the security of system functionality. The consequences of each event are traceable
until failures of high level will not be define. During creating the chain of events identification, we can
calculate probability for each event failure and events combination.
The tree events display a full set of possible consequences for some event of component failure, but
do not define reasons of the event.
FMEA and it’s edition are generally present as a table methods. Their application can be as additional
tools to the previous described methods or can be used as an independent method. FMEA is assigned
for the detection of possible kinds of software failures, and conditions of its appearance. These methods
are built on the principles of inductive analysis theory, that is effective in the field of identification the
conditions of failures appearance in the software components and consequences of defined failures for
the whole system.
3. SEI model and methodologies
3.1 Software risks analysis, identification and management
General taxonomies of risks, which had proposed SEI, are useful and convenient for identification
of general sources of software project risks, but they need to be adapted to the concrete situations.
Software Engineering Institute define three methodologies of project risks management:
Software Risk Evaluation (SRE), which includes formal method of risk identification,
analysis, monitoring and elimination; it uses in early stages of software development (before
deal) and periodically during software life cycle;
Continuous Risk Management (CRM) based on some principles of risks management during
software life cycle and it is independent from concrete methods and tools of risks estimation
and elimination;
Team Risk Management (TRM) defines additional activities of risks management, which
has relation to the collaborative working under the project from development team and
stakeholders.
In general, workflow of risks analysis might be present in the next sequence:
Assigning of an experienced team of experts;
Preparation of special questions and appointment with experts;
Choosing of risks analysis technique
Defining risks factors and its priority
Creating the mechanism of risks action
Assigning relation between some risks and the total effect from its action
Risks distribution between members of the project
Preparation of risks report and its analysis.
Expert assessment method is usually uses in business projects and it can be implemented in the way
of studying opinions of experienced specialists. When this method apply, it is important to define
allowable, critical and disastrous factors, which take into account its level and probability. To improve
results of expert assessment method, it is convenient to use fuzzy logic during risks level evaluation
under the expert assessments.
To reduce the procedure of risks identification uses classification, which was proposed SEI. The
classification based with taking into account main processes of software life cycle. It includes the most
general areas of risks, which have relations to the software features and characteristics, environment
and software development process, project constraints, etc.
3.2 Risks classification
The main attention in the article we pay to the software risks at the early stages of life cycle. The
most important in this research are internal risks, which has communication with requirements and
technical aspects of software development. In the table 1 presented classification of those risks [7].
Many methodologies can be used for gathering information about risks, but the most popular are:
Expert survey.
Brain storm.
Delphi method.
Crawford cards.
All of the presented before methodologies uses interviewing of experienced specialists, which can
make preliminary evaluation of the software project. On our opinion, the most important component in
each methodologies is detailed project description. Quality of gathered information define quality of
expert conclusions. Because, it is necessary to create rules of software description at different stages of
life cycle.
The task of building rules of software description is not trivial, but now there are a few methods,
which allow to resolve it with the defined level of acceptability.
Primarily, these are methodologies and methods, which are using at the stage of software
specification and design. The most common of them are:
Diagrams of structured system analysis like ER-diagrams, SADT, IDEF.
UML diagrams.
Currently, UML is a standard tool of software projects description and support features of object-
oriented software development. So far, we can consider that UML is convenient and effective tool of
description and gathering input information for risks identification.
The model of complex system, which built using UML notation, describes future software product
and includes four main parts:
logical view;
implementation view;
representation of system functionality;
representation of system structure.
Each part of software description contains a few types of diagrams. These diagrams present some
aspect of software model.
Table 1
Technical software risks classification
Class of risks source Class description Class element Attribute of element
Stability
Completeness
Ability to implementation
Requirements Credibility
features Reliability
Availability
Scalability
Novelty
Related to the Functionality
main processes of Complexity
Technical aspects of
life cycle and quality Design and Interfaces
software development
characteristics of implementation Productivity
software features Testability
Hardware constraints
Reuse components
Maintainability
Reliability
Non-functional and
Safety
quality
Security
characteristics
Human factors
Usability
When experts define software risks at the stages of life cycle, they use kinds of diagrams, which are
displayed in the table 2.
Table 2
UML diagrams application during software project development
Title of UML diagram Project description
Requirements of software project
Use Case diagram
Preliminary software architecture
Class diagram
Sequence diagram,
Software algorithms and functions implementation
Activity diagram
Composite structure diagram Description of hardware configuration
A number of tools, which will be using during software
Component diagram implementation
UML gives possibility to describe software project and helps experts to receive information in clear
and structured view, but it limits their information needs only in technical aspects of software. As a
result, data described with UML is not completeness and does not allow expert to carry out a full risks
identification.
According to the SEI risks classification (table 1), UML gives opportunity to evaluate completely
or partially only functional requirements and project characteristics. In the table 3, presented attributes
of classes (risks), which cannot be identified with UML.
Table 3
Risks, which cannot be defined with UML
Class of risks source Class description Class element Attribute of element
Requirements
Novelty
features
Related to the
main processes of
Technical aspects of
life cycle and quality Non-functional
software development Maintainability
characteristics of and quality
Human factors
software characteristics
During risks identification, experts need to receive as input information, except for detailed project
description, reports about previously executed projects.
It is necessary to note, that UML is not a single modelling tool, which allows to describe future
software. But when developers uses object-oriented methodology, UML application is more powerful
and gives the most advantages.
Except for disadvantages of UML, which have relation to the technical aspects of software
production like novelty, human factors and maintainability, there are some another: time, deadlines and
project budget. In spite of such UML disadvantages, perspectives of this tool application are very
essential to the process of risk identification.
3.3 Formal description of SEI model
SEI model defines eighteen the most common risks sources, which can be displayed in the formula 1,
as a set of these sources
𝑅𝑆 = {𝑟𝑠1 , … , 𝑟𝑠18 } (1)
where 𝑟𝑠𝑖 – potential source of risks (𝑖 = 1 … 18).
As a source of risks might be software technical risks, which can be displayed as a set of:
𝑇𝑅𝑆 = {𝑟𝑠1 , … , 𝑟𝑠7 } (2)
where 𝑇𝑅𝑆 ⊂ 𝑅𝑆 – a subset of sources of technical risks, where: 𝑟𝑠1 – functional characteristics; 𝑟𝑠2 –
quality characteristics; 𝑟𝑠3 – reliability; 𝑟𝑠4 – applicability;𝑟𝑠5 – productivity (time); 𝑟𝑠6 –
maintainability; 𝑟𝑠7 – reuse components.
Except for technical risks, defined a risks subset, which have relation to the project budget:
𝐶𝑅𝑆 = {𝑟𝑠8 , … , 𝑟𝑠10 } (3)
where 𝑇𝑅𝑆 ⊂ 𝑅𝑆 – a subset of cost risks, 𝑟𝑠8 – a limit of total project budget; rs9 – an unavailable
project cost; rs10 – a low degree of realism when estimating project costs.
The success and quality of the project are also affected by the risks, associated with the project
planning process. Formally, they can be represented as a subset:
𝑃𝑅𝑆 = {𝑟𝑠11 , … , 𝑟𝑠13 } (4)
where 𝑃𝑅𝑆 ⊂ 𝑅𝑆 – a subset of planning risks sources, 𝑟𝑠11 – features and possibilities of plan flexibility
changing; rs12 – possibilities of violate defined deadlines at life cycle stages; rs13 – a low level of plan
realism at the life cycle phases.
One more risks subset can be defined during project development which have relation to the
additional and organizational procedures and processes of life cycle. That subset can be presented in
the view:
𝑀𝑅𝑆 = {𝑟𝑠14 , … , 𝑟𝑠18 }, (5)
where 𝑀𝑅𝑆 ⊂ 𝑅𝑆 – a subset of risks sources for the project management processes and procedures,
rs14 – project strategy; rs15 – project planning; rs16 – project evaluation; rs17 – project documentation;
rs18 – project forecasting.
In general, we can display SEI model as a hierarchical structure (Fig.1).
Figure 1: SEI model structure
For each subset, presented previously, defined sets of corresponding attributes:
𝑇𝑅 = {𝑡𝑟𝑖 } ∈ 𝑇𝑅𝑆, 𝑖 = ̅̅̅̅̅̅̅
1…𝑁
𝐶𝑅 = {𝑐𝑟𝑗 } ∈ 𝐶𝑅𝑆, 𝑖 = ̅̅̅̅̅̅
1…𝐽 (6)
𝑃𝑅 = {𝑝𝑟𝑘 } ∈ 𝑃𝑅𝑆, 𝑖 = ̅̅̅̅̅̅̅
1…𝐾
𝑀𝑅 = {𝑚𝑟𝑙 } ∈ 𝑇𝑅𝑆, 𝑖 = ̅̅̅̅̅̅̅
1…𝐿
where 𝑇𝑅 – a set of attributes of technical risks, 𝐶𝑅 – a set of attributes of costs risks, 𝑃𝑅 – a set of
attributes of planning risks, 𝑀𝑅 – a set of attributes of additional and organizational risks, 𝑁, 𝐽, 𝐾, 𝐿 –
a number of attributes of corresponding sets of risks.
In the next sections of the article, this model will be implement to the general process of software
development using agile approach and integrated with requirements quality model.
4. Software quality model and requirements communication method
Software quality model is defined in ISO 25010 standard [9]. It includes three models, which display
different aspects of software quality. The structure of the model can be presented as hierarchical model,
like SEI model, but it includes more levels of hierarchy. The full structure of ISO 25010 models are
showed in the Figure 2.
In the [10,11] had proposed method of requirements definition using ISO 25010 models (Fig. 3).
The main value of this method is to provide possibilities of displaying requirements in the structured,
standard and unified form.
Generally, the process of software requirements analysis and specification begins with the domain
analysis, and after that goes sub processes of gathering, classification and defining priority for each
requirement. As we watch in the Fig. 3, requirements presentation executed with supporting of three
quality models, which allow to structure and provide communication between them with simultaneous
standardization.
The main point of quality model using under the requirements to the software is provide a possibility
to display them at the different stages of life cycle. For example, requirements, in the view of quality in
use model, are useful at the stage of system testing. External quality model requirements can be used at
the stage of software architecture design, internal quality model requirements – at the stage of software
development (programming code).
Figure 2. Structure of ISO 25010 quality models
Except for this, in the article [10] developed the method of software requirements communication,
which helps to provide requirements tracing at the life cycle stages (Figure 4).
Requirements
specification
Requirements
validation
System
requirements
Start
documentation
process
Domain analysis Priority definition
Elimination of
Requirements
conflicting
gathering
requirements
Requirements
classification
Quality in use External quality Internal quality
requirements requirements requirements
Quality in use External quality Internal quality
model model model
Figure 3. The process of requirements identification and analysis using quality models
Figure 4. Displaying and communication requirements to the process at life cycle stages
After that, it is necessary to identify risks for each requirement [11]. This way, we will increase
completeness of technical risks and provide their traceability during software project development. So
far, we can also add risks defined before and included to the SEI model using expert classification
methods. As a result, we receive hierarchical tree showed in the Figure 5.
Figure 5. Quality model with integrated to the requirements' attributes SEI risks
Quality model with integrated risks we can look as a graph or a tree and we can apply the signature
of graph theory to it. This will help us to define another features of risks, calculate their importance.
SEI model, quality models with integrated risks, requirements communication method constitute the
basis of proposed risks management method. In this article, we consider that relation between
requirement and risk is one-to-one. The vertex of the graph is bipartite at the attributes level. But, in
more general case, model, presented in the Fig. 5, must be investigate as a hypergraph. Because on each
level, except for metrics level, exists connections between elements. In the next section of this article,
we define formal description of agile software development process based on the proposed solutions
and method.
5. Risks management method in agile software development
One of the early processes of software development based on agile approach is customer needs
analysis [6]. As a result of this iteration received some necessary data, which can be presented as a set,
which include two components: need and time label:
𝑁𝑒𝑒𝑑𝑠 = {𝑛𝑖 , 𝑡𝑗 }, (7)
where 𝑛𝑖 – a customer need in the concrete time moment, 𝑖 = 1, 𝑁 – needs number; 𝑡𝑗 – a concrete time
moment, 𝑗 = 1, 𝑇 – a number of time moments,
At the next step, it is necessary to define detailed requirements to the software, which can be
presented as:
𝑅𝑒𝑞 = {𝑟𝑖 , 𝑁𝑒𝑒𝑑𝑠𝑖𝑗 }, (8)
where 𝑟𝑖 – a requirement to the software, 𝑖 = 1, 𝑅 – a number of requirements; 𝑁𝑒𝑒𝑑𝑠𝑖𝑗 – customer
need, 𝑗 ∈ 1. . 𝑁 – a number of needs related to the requirement.
For each requirement, which belong to the 𝑅𝑒𝑞, it is necessary to define it’s priority and detailed
requirements will be display as:
𝑅𝑒𝑞 = {𝑟𝑖 , 𝑁𝑒𝑒𝑑𝑠𝑖𝑗 , 𝑊𝑒𝑖𝑔ℎ𝑡𝑖 }, (9)
where 𝑊𝑒𝑖𝑔ℎ𝑡𝑖 – a weight importance coefficient for the i-th requirement.
The values of weight importance coefficients may be define by expert methods, for instance, Saaty
methods, methods of simple selection algorithms, methods of average weighted, etc.
Application of agile methodologies involves planning of architectural components at the most
highest level. At this level, we can describe system architecture as a set of components:
𝐴𝑟𝑐𝐻𝑖𝑔ℎ = {𝑐𝑜𝑚𝑝𝑖 }, (10)
where 𝑐𝑜𝑚𝑝𝑖 – a component of software at the conceptual level.
Architecture components implement functional requirements from the set 𝑅𝑒𝑞 (9), so we can note
that:
{𝑅𝑒𝑞𝑖 } → 𝑐𝑜𝑚𝑝𝑗 , 𝑜𝑟 𝑐𝑜𝑚𝑝𝑖 → 𝑅𝑒𝑞𝑖𝑗 , (11)
where {𝑅𝑒𝑞𝑖 } ∈ 𝑅𝑒𝑞, 𝑖 = 1. . 𝐻 – a subset of requirements, which implement some subsystem; 𝐻 – a
number of requirements, which define component at the conceptual level.
To define priority of a software subsystem or a component proposed to calculate average weighted
of requirements priorities, which will be implement in them:
1
𝑊𝑒𝑖𝑔ℎ𝑡(𝑐𝑜𝑚𝑝𝑖 ) = 𝑁 ∑𝐻 𝑗=1 𝑊𝑒𝑖𝑔ℎ𝑡𝑗 (12)
where 𝑊𝑒𝑖𝑔ℎ𝑡(𝑐𝑜𝑚𝑝𝑖 )– a weight importance coefficient for an architecture component at the
conceptual level; 𝑊𝑒𝑖𝑔ℎ𝑡𝑗 – a weight importance coefficient for j-th requirement in i-th component.
Defined weight importance coefficients for architecture components in future will be include to a sprint
planning.
To implement software components we need to plan tasks of their realization. But before it is
necessary to make decomposition of large components to the elementary units and after that include
them to the sprint. In general, tasks we can present as a set:
𝑇𝑎𝑠𝑘 = {𝑐𝑜𝑚𝑝𝑖 {𝑒𝑐𝑜𝑚𝑝𝑖𝑘 }, 𝑡𝑎𝑠𝑘𝑖𝑘𝑗 }, (13)
where 𝑒𝑐𝑜𝑚𝑝𝑖𝑘 – an elementary unit of i-th component, 𝑘 = 1. . 𝐾, 𝐾 – a number of elementary units;
𝑡𝑎𝑠𝑘𝑖𝑘𝑗 – tasks, which need to implement for i-th component development.
Sprint is one of the important part in agile methodologies, which can be displayed as a set:
𝑆𝑝𝑟𝑖𝑛𝑡 = {𝑇𝑎𝑠𝑘𝑖 , {𝑃𝑒𝑟𝑠𝑜𝑛}, 𝑡𝑠𝑡𝑎𝑟𝑡 , 𝑡𝑒𝑛𝑑 } (14)
where 𝑇𝑎𝑠𝑘𝑖 – a set of tasks during the sprint; {𝑃𝑒𝑟𝑠𝑜𝑛} – a set of team members who implement
tasks; 𝑡𝑠𝑡𝑎𝑟𝑡 – time of sprint starting; 𝑡𝑒𝑛𝑑 – time of sprint finishing.
As we proposed before, technical risks are related to the requirements and we can integrate them to
the general agile process in the way:
𝑅𝑒𝑞 = {{𝑟𝑖 , {𝑅𝑖𝑠𝑘𝑖𝐿 }}, 𝑁𝑒𝑒𝑑𝑠𝑖𝑗 , 𝑊𝑒𝑖𝑔ℎ𝑡𝑖 } , (15)
where 𝑅𝑖𝑠𝑘𝑖𝐿 – a set of risks related to the requirement, 𝑖 = ̅̅̅̅̅
1, 𝑁, 𝐿 = ̅̅̅̅̅
1, 𝑟𝑖
𝑅𝑖𝑠𝑘𝑖𝐿 belong to the union of sets:
𝑅𝑖𝑠𝑘𝑖𝐿 ∈ 𝑇𝑅𝑆⋃𝐶𝑅𝑆⋃𝑃𝑅𝑆⋃𝑀𝑅𝑆 (16)
In future, software risks will be taken into account to each sprint and will increase the process of
risks management.
CONCLUSION
In the paper the analysis of software risks management approaches and methods was carried out and
defined their main advantages and disadvantages. Application of SEI risks model is very useful during
modern software development and it was important to formalize it and integrate to the quality
requirements communication method. It provide to improve quality of finish product in the way of
effective risks management at the life cycle stages. In this paper we proposed to identify risks according
to the requirements and add additional risks defined by SEI model. As a result, we received hierarchical
structure, which was integrated with the ISO 25010 quality models. The vertex of the graph is bipartite
at the attributes level. But, in more general case, the model must be investigate as a hypergraph and it
will be our future task. Also, the paper describe a formal representation of agile software development
process structure based on the proposed solutions and method.
References
[1] Ian Sommerville. Software Engineering, Global Edition. Pearson Higher Ed, 2016, 816 pages.
[2] Fenton N. Risk Assessment and Decision Analysiswith Bayesian Networks. CRC Press. –2012.
– Р. 33-38.
[3] Soumya Krishnan M. Software Development Risk Aspects and Success Frequency on Spiral and
Agile Model /M. Soumya Krishnan // Int. Journal of Innovative Research in Computer and Comm. Eng.
– 2015. - Vol. 3. – Р. 122-129.
[4] Abdullahi M. Strength and Weakness of Software Risk Assessment Tools. International Journal
of Software Engineering and Its Applications. – 2014. – Vol. 8. – № 3. - P. 389-398.
[5] Woody С. Supply-Chain Risk Management: Incorporating Security into Software Development.
Software Engineering Institute Carnegie Mellon University. – 2010. – Р. 166-178.
[6] Britkin A.I. Model estimate the duration of the iterative software development process. Open
education, 2009. – №4. – P. 75.
[7] William R. Project Management Body of Knowledge. PMI Standard Committee. 2006. 182 р.
[8] Hijazi H. A Review of Risk Management in Different Software Development Methodologies.
Int. Journal of Computer Appl. – 2013. – Vol. 48, № 3. – Р.1441-1453.
[9] ISO/IEC 25010:2011ю Systems and software engineering — Systems and software Quality
Requirements and Evaluation (SQuaRE) — System and software quality models
[10] Yatsyshyn V, Kharchenko А, Galay І. The Method of Quality Management Software.
Proceeding of the VIIth International Conference "Perspective technologies and methods in MEMS
design" 11-14 May 2011 - Polyana, Ukraine: Publishing House Vezha&Co. 2011.- p. 228-230.
[11] Kharchenko A., Bodnarchuk І., Yatcysyn V. The Method for Comparative Evaluation of
Software Architecture with Accounting of Trade-offs. American Journal of Information Systems, 2014,
Vol. 2, No. 1, 20-25/Режим доступу - http://pubs.sciepub.com/ajis/2/1/5/