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).
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 [
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.
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].
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.
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.
Each part of software description contains a few types of diagrams. These diagrams present some aspect of software model.
When experts define software risks at the stages of life cycle, they use kinds of diagrams, which are displayed in the table 2.
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.
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.
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). , = ̅1̅̅…̅̅̅ , = ̅1̅̅…̅̅̅̅ , = ̅1̅̅…̅̅̅̅ (6) 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.
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).
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
validation
Start process
Domain analysis
Priority definition
System requirements documentation Requirements gathering
Requirements specification
Elimination of
conflicting requirements Requirements classification Quality in use requirements
External quality requirements
Internal quality requirements Quality in use model
External quality model
Internal quality model 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. 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: 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:
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.
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) (8) (9) (10) (11) (12) (13) number of requirements, which define component at the conceptual level. of requirements priorities, which will be implement in them:
To define priority of a software subsystem or a component proposed to calculate average weighted } ∈ , = 1. . – a subset of requirements, which implement some subsystem; – a ℎ ( ) = 1 ∑ =1 ℎ )– a weight importance coefficient for an architecture component at the ℎ – 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
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: = { { }, }, where
– an elementary unit of i-th component, = 1. . , – a number of elementary units; – tasks, which need to implement for i-th component development. that: where { where conceptual level;
ℎ ( planning. 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: ℎ = { where
– a component of software at the conceptual level.
Architecture components implement functional requirements from the set (9), so we can note Sprint is one of the important part in agile methodologies, which can be displayed as a set: 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: , where – a set of risks related to the requirement, = ̅1̅,̅̅̅, = ̅1̅̅,̅̅ = {{ , { }},
,
In future, software risks will be taken into account to each sprint and will increase the process of
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. (14) (15) (16) Agile Model /M. Soumya Krishnan // Int. Journal of Innovative Research in Computer and Comm. Eng.
Proceeding of the VIIth International Conference "Perspective technologies and methods in MEMS