<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <journal-title-group>
        <journal-title>Kyiv, Ukraine, June</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Information Technology of Predicting the Characteristics and Evaluating the Success of Software Projects Implementation</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Andriy Krasiy</string-name>
          <email>andriy-krasiy@yandex.ua</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Tetiana Hovorushchenko</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="editor">
          <string-name>Key Terms: Model-Based Software System Development, Software Compo-
nent, Software System, Specification Process.</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Khmelnitsky National University</institution>
          ,
          <addr-line>Khmelnitsky</addr-line>
          ,
          <country country="UA">Ukraine</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2016</year>
      </pub-date>
      <volume>2</volume>
      <fpage>1</fpage>
      <lpage>24</lpage>
      <abstract>
        <p>The aim of this research is the development of the information technology (model, method and tools) of predicting the characteristics and evaluating the success of the software projects implementation based on the analysis of the software requirements specification (ITPCES). ITPCES structure was first time proposed. One of the non-realized components of ITPCES is the intelligent system of predicting the characteristics and evaluating the success of the software projects implementation (SPCES). This research is devoted to design of SPCES and experiments with it. SPCES gives the conclusion about probably category of success of the software project implementation by analyzing the software requirements specification (at the early stages of the life cycle). The SPCES conclusions provide to the customer the ability of the comparing the proposed software projects and provide to the customer the data for the grounded and informed choice of the most successful software project.</p>
      </abstract>
      <kwd-group>
        <kwd>software requirements specification (SRS)</kwd>
        <kwd>SRS indicators</kwd>
        <kwd>software project characteristics</kwd>
        <kwd>success of project implementation</kwd>
        <kwd>the category of success of project implementation</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        In recent years, the software industry has reached a level of evolution where the
development of software systems is user-oriented [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. At the present definition of
software quality [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], if the goals of the project don't meet the needs of users, the
software will not be qualitative and successful, even if the modern technologies and
the most qualified developers were involved to its development. But until now the
development of successful and high-quality software products don't become the norm
- statistics [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] says that in 2012 only 39% of software projects are successful, but 43%
      </p>
      <p>
        - 88
of software projects are challenged and 18% of software projects are failed, i.e. 61%
software projects aren't successful and qualitative - Fig. 1.
In [
        <xref ref-type="bibr" rid="ref4 ref5 ref6">4-6</xref>
        ] the fact, that almost all the causes of software incidents and accidents are
latent in the software requirements specification (SRS), is confirmed. The vast
majority of software accidents arises from false requirements but not from coding
bugs. Software versions, written by the different developers for the same
requirements, contain the number of the common bugs associated with errors or
inaccuracies of requirements (SRS) [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. Paper [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] says, that the main causes of the
failure of software projects are the misconceptions of project managers on real
deadline and budget for providing the user functional requirements. So paper [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]
again confirmed that the most of the software problems are associated with SRS.
Then the quality and success of the software project implementation depend on the
SRS, resulting in the need to deepen the analysis of specifications.
      </p>
      <p>Then the actual task is the ability to evaluate the potential success of software
project implementation based on the software project characteristics (project cost,
duration, complexity, usability, cross-platform, quality), the predicted values of which
can be obtained by analyzing the SRS indicators. The success of software project
implementation is timely execution of software project within the allocated budget
and with realization of all necessary features and functionality.</p>
      <p>
        The analysis of SRS structure [
        <xref ref-type="bibr" rid="ref8 ref9">8, 9</xref>
        ] showed, that the SRS requirements provide
the set of indicators, on the basis of which the customer and the developer can get the
predicted quantitative values of the characteristics of software projects. For
establishment of the dependence between the basic software project characteristics
and SRS indicators the software requirements specifications and finished applications
(realized by these SRS) were analyzed. For this analysis six types of software projects
(Web-applications, mobile applications, e-learning applications, applications for
statistics and accounting, automated systems, information systems) were considered.
For each type of software projects 30-50 tasks of different complexity were studied.
For each task 1-3 SRS (proposed by the various developers) and 1-3 finished
applications (written by the analyzed specifications) were selected. For this the course
projects in discipline "Technology of software systems design", the diploma papers,
the projects of students scientific group «SOFTWARE» of Khmelnitsky National
University (15% of all projects; moreover only student projects, that were devoted to
solving the real-world tasks and were successfully applied in different industries, was
considered), the SRS and applications of the software companies of Khmelnitsky
(“Avivi”, “Smile”, LLC «STU Electronics») were studied. Thus, we selected 200
tasks, for which 410 SRS and appropriately 410 applications were developed (for
various industries, i.e. software projects of different types were selected) and we
analyzed them: what SRS indicators differed in the selected specifications, what
characteristics of finished applications changed depending on it, and what values had
the SRS indicators in these SRS. The conducted analysis of finished SRS and
applications led to the conclusion about dependence the basic software project
characteristics on the SRS indicators for all types of software projects [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ].
      </p>
      <p>
        The analysis of the methods and tools for determination of the software projects
characteristics [
        <xref ref-type="bibr" rid="ref11 ref12">11, 12</xref>
        ] led to the conclusion that they are focused on ready code, but
not on existing SRS that is unusable at the early stages of the software projects life
cycle. The research of the methods and tools of the SRS analysis [
        <xref ref-type="bibr" rid="ref13 ref14 ref15">13-15</xref>
        ] showed that
they are aimed at monitoring the implementation of requirements and don't determine
the predicted values of software projects characteristics. Thus, the existing methods
and tools of SRS analysis and software project characteristics determination are not
acceptable for the quantitative evaluation of the software project characteristics based
on only requirements analysis and for evaluating the success of the software projects
implementation.
      </p>
      <p>The task of this research is the development of the information technology
(model, method and tools) of predicting the characteristics and evaluating the success
of software projects implementation based on analysis of the SRS.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Information Technology of Predicting the Characteristics and</title>
    </sec>
    <sec id="sec-3">
      <title>Evaluating the Success of Software Projects Implementation (ITPCES)</title>
      <p>
        Considering the definition of information technology [
        <xref ref-type="bibr" rid="ref16 ref17">16, 17</xref>
        ], the structure of the
information technology of predicting the characteristics and evaluating the success of
software projects implementation is represented on Fig. 2:
      </p>
      <p>Fig. 2 shows that the basis of ITPCES is the developed neuronet model of
predicting the software projects characteristics based on the SRS analysis and method of
evaluating the success of software projects implementation based on analysis of SRS
(MESSPI) and also intelligent system of predicting the characteristics and evaluating
the success of software projects implementation, which should be design.</p>
      <p>
        The neuronet model of predicting the software projects characteristics based on
the SRS analysis was developed for evaluation the software projects characteristics
based on the processing of SRS indicators [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. The basis of this model is the
artificial neural network (ANN), which performs the approximation of SRS indicators and
provides the predicted relative evaluation of the characteristics of the software, which
will be developed by the analyzed specification. The input data for ANN are three sets
of indicators: the set of indicators of section 1 of the SRS R1={Tv, Qv, Sa, Qcs, Sc},
where Tv – predicted realization time, Qv – quantity of performers, Sa – predicted
quantity of users, Qcs – quantity of software components, Sc – predicted size (LOC);
the set of indicators of section 2 of the SRS R2={Cos, Cdb, Cc, Cdt, Cud, Sud},
where Cos – cost of used operating systems, Cdb - cost of used databases, Cc – cost
of used compilers, Cdt – cost of development tools, Cud – quantity of user
documentation pages, Sud – cost of user documentation; the set of indicators of
section 1 of the SRS R3={Qfr, Cfr, Qa, Cb, Cui, Qmi, Cmi, Qai, Cai, Qci, Cci, Qnfr,
Cnfr}, where Qfr – quantity of functional requirements, Cfr – cost of functional
requirements, Qa – quantity of algorithms, Cb – average predicted cost of bug, Cui –
cost of user interfaces, Qmi – quantity of intermodule interfaces, Cmi – cost of
intermodule interfaces, Qai - quantity of hardware interfaces, Cai – cost of hardware
interfaces, Qci - quantity of communication interfaces, Cci – cost of communication
interfaces, Qnfr – quantity of non-functional requirements, Cnfr – cost of
nonfunctional requirements. The result of ANN functioning is the set of the predicted
relative evaluation of the software project characteristics SCH={Cs, Dsp, Cx, Cp, Ub,
Qs}, where Cs – software project cost, Dsp – duration, Cx – complexity, Cp –
crossplatform, Ub – usability, Qs – quality [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. These characteristics provide the
comprehensively analysis of the possible success of software projects implementation – in
terms not only quality of developed software products (quality, cross-platform,
usability), but quality of software projects management (cost, duration, complexity). ANN
was realized in Matlab, was trained with training sample of 6030 vectors by different
training methods and was tested with testing sample of 610 vectors [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. The analysis
of charts of the ANN training and testing led to the conclusion that the ANN was
trained with high accuracy and precision. In [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] the analysis of ANN training results
(by different training functions with different performance functions) was also
conducted. The performance function msereg and the training functions OSS, SCG,
RPROP were selected on the basis of the following criteria: training performance,
training time, and number of epochs.
      </p>
      <p>The structure chart of the ANN layers in Simulink is shown on Fig. 3.</p>
      <p>
        The developed method of evaluating the success of software project
implementation based on analysis of SRS (MESSPI) consists of the next stages [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]:
1. neuronet prediction of characteristics of software project based on the analysis of
specification (the basis of which is the neuronet model of predicting the software
projects characteristics based on the SRS analysis [
        <xref ref-type="bibr" rid="ref10 ref11">10, 11</xref>
        ]). The result of this stage
is the set of the predicted relative evaluations of the software project characteristics
SCH={Cs, Dsp, Cx, Ub, Cp, Qs}, Cs € [0..1], Dsp € [0..1], Cx € [0..1], Ub € [0..1],
Cp € [0..1], Qs € [0..1], where 0 – insufficient data for prediction of the
characteristics (in this case MESSPI does not work), 0.08 – characteristic negative
affects on the success of software project implementation (high cost, duration,
complexity, low usability, cross-platform, quality), 1 – characteristic positive
impacts on the success of software project implementation (low cost, duration,
complexity, high usability, cross-platform, quality);
2. interpretation of the received relative values of the software project characteristics
– criteria for this interpretation is the integrative indicator of software project (Fig.
4):
      </p>
      <p>IipSp=0.5*0.866*(Cs*Cx+Cx*Dsp+ Dsp*Ub+ Ub*Cp+Cp*Qs+ Qs*Cs) (1)
3. evaluation of the degree of success of the software project implementation on the
basis of the integrative indicator:</p>
      <p>PIip=IipSp/Iipmax=IipSp/2.598=0.385*IipSp (2)
4. testing of the stability and acceptability of compensations of software project
characteristics: the indicator AceSp of stability and acceptability of compensatory
effects of the characteristics has the value “True”, if the hexagon (Fig. 4) is convex
(if the sum of the angles of hexagon is 720° and sines of angles have the same
signs).</p>
      <p>
        Thus, the input data for MESSPI is the set of SRS indicators, and the result of the
method is the evaluation of the degree of success of the software project
implementation [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], which provides to perform the reasonable choice of SRS for the
further implementation of the project.
      </p>
      <p>
        For the completion of ITPCES we need to develop the intelligent system of
predicting the characteristics and evaluating the success of software projects
implementation based on the developed method MESSPI [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ].
      </p>
    </sec>
    <sec id="sec-4">
      <title>Intelligent System of Predicting the Characteristics and</title>
    </sec>
    <sec id="sec-5">
      <title>Evaluating the Success of Software Projects Implementation</title>
      <p>
        The input of the intelligent system of predicting the characteristics and evaluating the
success of software projects implementation (SPCES) are the selected in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] 24 SRS
indicators, and the result of its work are: the relative values of the software project
characteristics, the conclusion about stability and acceptability of compensatory
effects of the software project characteristics,the integrative indicator of software
project (graphical representation and value), the value of the degree of success of the
software project implementation and the conclusion about category of success of
software project implementation (the successful, the challenged or the failed project is
expected).
      </p>
      <p>The structure (algorithmic-focused vision with elements of architectural solutions)
of the intelligent system of predicting the characteristics and evaluating the success of
software projects implementation is represented on Fig. 5.</p>
      <p>
        SPCES consists of the next components:
1. module of introduction of the SRS analysis – is the part of the user interface; reads
the user information about the quantitative values of 24 SRS indicators, which are
necessary for prediction of the software project characteristics;
2. module of the user support – is the part of the user interface; provides to the user
the information about the structure of the software requirements specification,
about the SRS indicators (which are required for prediction of the software projects
characteristics), about the valid (for the system) ranges of the SRS indicators
values (defined in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] based on the analysis of the above-described 410 SRS),
about the process of forming the results of the system (SPCES) functioning;
3. module of the previous processing of the input SRS indicators – tests the
acceptability of the input values of the SRS indicators under the rules of the knowledge
base; forms the input vector for ANN: ANN has 5 inputs хʹ, 6 inputs хʺ and 13
inputs х; on the inputs хʹ the indicators of the section 1 of the SRS are submitted, on
the inputs хʺ - the indicators of the section 2 of the SRS, on the inputs х – the
indicators of the section 3 of the SRS under the rules of the knowledge base;
4. knowledge base – consists of the data section and rules section; in the data section
accumulates the values of the SRS indicators and results of the system SPCES
functioning; the rules section contains: rules for the testing of acceptability of input
values of SRS indicators, rules for the forming of ANN input vectors, rules for the
testing and preparation of ANN results to the display, rules for the testing of the
stability and acceptability of compensatory effects of the software project
characteristics, rules for the forming of the conclusion about category of success of
the software project implementation;
5. artificial neural network (ANN) of predicting the software project characteristics –
detailed described in paragraph 2 and in the papers [
        <xref ref-type="bibr" rid="ref10 ref11">10, 11</xref>
        ];
6. module of the analysis of ANN results – tests and prepares of ANN results to the
display, calculates the value of indicator AceSp of stability and acceptability of
compensatory effects of the characteristics according to the 4-th stage of the
method MESSPI [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ] and forms the conclusion about stability and acceptability of
compensatory effects of the software project characteristics, forms the graphical
representation and calculates the value of the integrative indicator IipSp of the
software project according to the 2-nd stage of the method MESSPI [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], evaluates the
degree PIip of success of software project implementation according to the 3-rd
stage of the method MESSPI [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ] and forms the conclusion about category of
software project implementation success (conclusions are formed using the rules
from the knowledge base);
7. module of the results display – is the part of the user interface; provides to the user
the relative values of the software projects characteristics, the conclusion about
stability and acceptability of compensatory effects of the software project
characteristics, the graphical representation and the value of the integrative
indicator of the software project, the degree of success of software project
implementation and the conclusion about category of software project
implementation success (successful, challenged or failed project is expected).
      </p>
      <p>
        The rules for the testing of acceptability of input values of SRS indicators (are
substantiated by the valid (for the SPCES) ranges of the SRS indicators values, that were
defined in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] based on the analysis of the above-described 410 SRS) have the form:
1. if Tv € [1..24] (months), then flag=true, else flag=false;
2. if Qv € [1..10] (persons), then flag=true, else flag=false;
3. if Sa € [1..1000] (persons), then flag=true, else flag=false;
4. if Qcs € [1..50] (components), then flag=true, else flag=false;
5. if Sc € [50..50000] (lines of code), then flag=true, else flag=false;
6. if Cos € [0..1250] (USD), then flag=true, else flag=false;
7. if Cdb € [0..1250] (USD), then flag=true, else flag=false;
8. if Cc € [0..1250] (USD), then flag=true, else flag=false;
9. if Cdt € [0..1250] (USD), then flag=true, else flag=false;
10. if Cud € [1..50] (pages), then flag=true, else flag=false;
11. if Sud € [50..2500] (USD), then flag=true, else flag=false;
12. if Qfr € [5..300] (requirements), then flag=true, else flag=false;
13. if Cfr € [50..4750] (USD), then flag=true, else flag=false;
14. if Qa € [1..500] (algorithms), then flag=true, else flag=false;
15. if Cb € [10..960] (USD), then flag=true, else flag=false;
16. if Cui € [50..3000] (USD), then flag=true, else flag=false;
17. if Qmi € [50..2450] (interfaces), then flag=true, else flag=false;
18. if Cmi € [25..2500] (USD), then flag=true, else flag=false;
19. if Qai € [5..100] (interfaces), then flag=true, else flag=false;
20. if Cai € [25..1500] (USD), then flag=true, else flag=false;
21. if Qci € [5..125] (interfaces), then flag=true, else flag=false;
22. if Cci € [25..1750] (USD), then flag=true, else flag=false;
23. if Qnfr € [1..9] (requirements), then flag=true, else flag=false;
24. if Cnfr € [50..4000] (USD), then flag=true, else flag=false;
25. if flag=true, then the input values of the SRS indicators are acceptable, else if
flag=false the input values of the SRS indicators are not acceptable, in this case the
method MESSPI and the system SPCES cannot be used for this SRS and project.
      </p>
      <p>The rules for the forming of ANN input vectors (are substantiated by the quantities
of the elements of the above-described sets R1-R3) have the form:
1. on the input xʹi (i=1..5) the value of i-th element of set R1 of the indicators of the
section 1 of the SRS is submitted;
2. on the input xʺk (k=1..6) the value of k-th element of set R2 of the indicators of the
section 2 of the SRS is submitted;
3. on the input xj (j=1..13) the value of j-th element of set R3 of the indicators of the
section 3 of the SRS is submitted;
4. if the user doesn’t enter the value of indicator, then corresponding input of ANN is
-1.</p>
      <p>The rules for the testing and preparation of ANN results to the display (are
substantiated by the above-described approach to ANN training) have the form:
1. if Cs=0 or Dsp=0 or Cx=0 or Cp=0 or Ub=0 or Qs=0, then insufficient data for
prediction of the software project characteristics, in this case the method MESSPI
and the system SPCES cannot be used for this SRS and project;
2. output y1 - Cs – the relative value of the software project cost, output y2 – Dsp –
the relative value of the software project duration, output y3 - Cx – the relative
value of the software project complexity, output y4 – Ub – the relative value of the
software project usability, output y5 – Cp – the relative value of the software
project cross-platform, output y6 – Qs – the relative value of the software project
quality.</p>
      <p>The rules for the testing of the stability and acceptability of compensatory effects
of the software project characteristics (are substantiated by the above-described
method MESSPI) have the form:
1. if the hexagon (Fig. 4) is convex (if the sum of the angles of hexagon is 720° and
sines of angles have the same signs), then the indicator AceSp of stability and
acceptability of compensatory effects of the characteristics has the value “True”;
2. if the hexagon (Fig. 4) isn’t convex (if the sum of the angles of hexagon isn’t 720°
or sines of angles have the different signs), then the indicator AceSp of stability and
acceptability of compensatory effects of the characteristics has the value “False”;
3. if AceSp=True, then the chararcteristics are stable, the compensations of
characteristics are acceptable, the method MESSPI and the system SPCES are suitable for
this software project and this SRS, else if AceSp=False, then the chararcteristics are
unstable, the compensations of characteristics are unacceptable, the method
MESSPI and the system SPCES are not suitable for this software project and this
SRS.</p>
      <p>
        The degree of success of the software project implementation, which is defined
under the 3-rd stage of method MESSPI, is uninformative to the developers and to the
customers through the complexity and ambiguity of interpretation of its value in the
predicting the category of the success of the software project. For the facilitation of
the interpretation of the value of the degree of success of the software project
implementation we define thresholds values of this degree, which provide the
conclusion about the category of the project success. For establishment of these
thresholds values (for creation of the rules for the forming of the conclusion about
category of success of the software project implementation) we have analyzed 410
above-described SRS, for which the degrees PIip of success of the software project
implementation were determined according to method MESSPI [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], and 410 finished
applications, for which the categories of the success are known. In general, based on
the proposed definition of the success of software project implementation and current
reports [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], there are three categories of success of the software projects
implementation: successful (are projects, that delivered on time, on budget and have
required features and functions), challenged (are projects, that late, over budget,
and/or with less than the required features and functions), failed (are projects, that
cancelled prior to competition or delivered and never used). The results of this
analysis are shown in Table 1.
      </p>
      <p>
        The rules for the forming of the conclusion about category of success of the
software project implementation (considering the empirical estimates from Table 1,
which in general correspond to the statistical evaluations [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] from Fig. 1) have the
form:
1. if the value of the degree of success of the software project implementation
      </p>
      <p>PIip≤0.19, then software project is predictably failed;
2. if the value of the degree of success of the software project implementation
0.19&lt;PIip≤0.62, then software project is predictably challenged;
3. if the value of the degree of success of the software project implementation</p>
      <p>PIip&gt;0.62, then software project is predictably successful.
4</p>
    </sec>
    <sec id="sec-6">
      <title>Experiments with SPCES</title>
      <p>The input data for the SPCES are the SRS indicators for five software projects, that
were developed by the different groups of developers for the solution of the one task –
the development of the automated system for large-format photo print – to the order
by LLC «Deymos», Khmelnitsky (Table 2).</p>
      <p>After the introduction of the SRS indicators values the module of the previous
processing of the input SRS indicators saves this data in the data section of the
knowledge base and tests the acceptability of the input values of the SRS indicators
under the rules of the rules section of the knowledge base - if input values are not
valid, then the system gives the message to the user: "The input values of SRS
indicators are unacceptable, the system of predicting the characteristics and evaluating
the success of software projects implementation cannot be used for such SRS". For
the proposed software projects the valid values of the SRS indicators were entered, so
the ANN input vector is formed for each software project. Block of the forming of
ANN input vectors generates the vectors for the appropriate ANN inputs - Table 3.
The ANN of predicting the software project characteristics of the project processes
the input vector and gives the results (the predicted relative evaluations of the
software project characteristics), that also is shown in Table 3.</p>
      <p>Block of the testing and preparation of ANN results to the display tests the ANN
results – if the value of even one ANN output is 0, the system gives the message to
the user: "The data for predicting the software project characteristics are insufficient,
so the system of predicting the characteristics and evaluating the success of software
projects implementation cannot be used for such SRS". For the proposed software
projects the input data were sufficient, so the ANN results were prepared to the
display according to the above rules.</p>
      <p>Block of the testing of the stability and acceptability of compensatory effects of
the software project characteristics calculates the indicator AceSp of stability and
acceptability of compensatory effects of the characteristics (Table 4) and forms the
conclusion about stability and acceptability of compensatory effects of the software
project characteristics. If AceSp = False, the user gets the message: "The software
projects characteristics are unstable, the compensations of characteristics are
unacceptable, so the system of predicting the characteristics and evaluating the
success of software projects implementation is not suitable for this project and for this
SRS". If AceSp = True, then the system calculates the integrative indicator of software
project, the degree of success of the software project implementation and forms the
conclusion about category of software project implementation success. For the
proposed software projects №1, №2, №3, №5 the characteristics are stable, the
compensations of characteristics are acceptable, so the obtained predicted relative
values of the characteristics are processed according to the method MESSPI. For the
proposed software project №4 the system gives the message to the user: "The
software projects characteristics are unstable, the compensations of characteristics are
unacceptable, so the system of predicting the characteristics and evaluating the
success of software projects implementation is not suitable for this project and for this
SRS".</p>
      <p>Block of the forming of the integrative indicator of software project forms the
graphical representation and calculates the value of integrative indicator IipSp of
software project (Table 4).</p>
      <p>Block of the evaluation of the degree of success of the software project
implementation estimates the value of the degree of success PIip of the software
project implementation (Table 4).</p>
      <p>Block of the forming of the conclusion about category of software project
implementation success uses the rules of the knowledge base and forms the
conclusion about category of software project implementation success (Table 4).</p>
      <p>Let's analyze of the results: the category of software project implementation
success was defined for the projects №1, №2, №3, №5, for which the predicted values
of characteristics are stable, their compensations are acceptable. The software project
№1 has the best characteristics, it predictably belongs to the category of successful
projects. The software projects №2, №3, №5 have the worst characteristics and
predictable are classified as challenged projects. For the project №4 the system
SPCES cannot determine the category of implementation success because the
predicted characteristics are unstable and their compensations are unacceptable. So
the conclusion of the intelligent system of predicting the characteristics and
evaluating the success of software projects implementation recommends to LLC
"Deymos" to order the implementation of software project №1 (to the development of
the automated system for large-format photo print) that will be successful with the
greatest probability.</p>
      <p>Nowadays the developer and customer select the software project based on only
own intuition and the cost and duration that predicted in the SRS. But SRS developers
cannot always correctly predict the oriented cost and duration of software project
during development of the SRS. Predicted (in the SRS) values of cost and duration for
the four examined alternative software projects (for which SPCES determines the
category of implementation success) are represented in Table 5.</p>
      <p>The values of the characteristics of software projects from Table 5 show, that all
four software projects have the different duration but the same cost that predicted in
the SRS. But the results of Table 3 show, that projects have significantly different
relative values of all characteristics, including the cost, which were calculated taking
into account all significant SRS indicators. Thus, the relative cost ranges from 0.518
(for Project №2) to 0.789 (for Project №1). So, if we evaluate the cost, taking into
account all significant SRS indicators, then it values are not the same for the four
examined projects. As for the value of project duration, this value isn't defined for
project №5, for example, then software project in this case will be evaluated solely on
the basis of its cost value. Therefore, the customer and developer can make the wrong
conclusion about choice of project on the basis of solely cost and time that predicted
in the SRS. In addition, such conclusion is difficult in the real conditions. For
example, according to Table 5, the lowest cost has the software project №3, and the
lowest duration has the software project №1 (but the value is unknown for the
software project №5), i.e. the customer and the developer must make the choice of
software project in this case on the basis of one criterion - or by cost, or by the
duration.</p>
      <p>In addition, the success of software projects implementation depends not only on
the cost and duration, but also on the functionalities of developed software, i.e. on the
rest of the main characteristics of the software project - complexity, usability,
crossplatform and quality, which aren't defined in the SRS explicitly in the quantitative
form. In addition, Table 4 shows that the examined software projects have the
different category of software project implementation success. Therefore, the values of
main characteristics, provided by ANN and the conclusions of SPCES about the
category of software project implementation success will help to make the right choice
and to implement the software project which will be successful with the greatest
probability (among from four examined software projects is Project №1). But if the
developer and the customer made the choice of the software project on the basis of the
only duration, they probably would choose the project №3, which really has a low
degree of success of the implementation and with the high probability will be
challenged software project (wrong choice).
5</p>
    </sec>
    <sec id="sec-7">
      <title>Conclusions</title>
      <p>In the article the structure of information technology of predicting the
characteristics and evaluating the success of software projects implementation
(ITPCES) is first time proposed. The basic components of ITPCES are the previously
developed by the author the neuronet model of predicting the software projects
characteristics and the method of evaluating the success of software projects
implementation based on analysis of SRS and also (yet not developed) the intelligent
system of predicting the characteristics and evaluating the success of software
projects implementation, to the designing of which this research is dedicated.</p>
      <p>The structure of the intelligent system of predicting the characteristics and
evaluating the success of software projects implementation (SPCES) are proposed.
SPCES consists of the next components: module of introduction of the SRS analysis;
module of the user support; module of the previous processing of the input SRS
indicators; knowledge base; artificial neural network (ANN); module of the analysis of
ANN results; module of the results display. This system gives the conclusion about
the probably category of success of the software project implementation based on
analysis of the SRS (at the early stages of the life cycle).</p>
      <p>The practical significance of the proposed information technology ITPCES is this
fact, that system's conclusions about the category of the success of software project
implementation provide to the customers the comparison of the proposed software
projects and the data for the reasoned and informed choice of the most successful
software project (not just on the basis of the project cost and duration, as is currently).</p>
      <p>The authors’ following perspective for future researches are: 1) development of
DEF0-block diagram and UML component/deployment diagrams for the SPCES;
2) realization of the intelligent system of predicting the characteristics and evaluating
the success of software projects implementation for prediction of characteristics and
evaluation of success of software project implementation based on analysis of the
SRS; 3) realization of the information technology of predicting the characteristics and
evaluating the success of software projects implementation.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. ISO 10002:
          <year>2014</year>
          <article-title>Quality management - Customer satisfaction - Guidelines for complaints handling in organizations (</article-title>
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Bourque</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fairley</surname>
          </string-name>
          , R.:
          <article-title>Guide to the software engineering body of knowledge (SWEBOK): Version 3.0. A project of the IEEE Computer Society (</article-title>
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3. The Standish Group International: CHAOS Manifesto -
          <article-title>Think big, act small</article-title>
          .
          <source>Technical report, CHAOS Knowledge Center</source>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Levenson</surname>
            ,
            <given-names>N.G.</given-names>
          </string-name>
          :
          <article-title>Systemic factors in software-related spacecraft accidents</article-title>
          .
          <source>In: AIAA Space Conference and Exposition</source>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>11</lpage>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Levenson</surname>
            ,
            <given-names>N.G.</given-names>
          </string-name>
          :
          <article-title>Software challenges in achieving space safety</article-title>
          .
          <source>Journal of the British Interplanetary Society</source>
          .
          <volume>62</volume>
          ,
          <fpage>265</fpage>
          -
          <lpage>272</lpage>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Ishimatsu</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Levenson</surname>
          </string-name>
          , N.,
          <string-name>
            <surname>Thomas</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fleming</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Katahira</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miyamoto</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ujiie</surname>
          </string-name>
          , R.:
          <article-title>Hazard analysis of complex spacecraft using systems-theoretic process analysis</article-title>
          .
          <source>Journal of Spacecraft and Rockets</source>
          .
          <volume>51</volume>
          ,
          <fpage>509</fpage>
          -
          <lpage>522</lpage>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Yourdon</surname>
          </string-name>
          , E.: Death March:
          <article-title>The complete software developer's guide to surviving “Mission impossible” projects: 2nd edition</article-title>
          . Prentice Hall (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8. IEEE 1031
          <article-title>-2011 - IEEE Guide for the Functional Specification (</article-title>
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9. IEEE 29148
          <article-title>-2011 - Systems and software engineering - Life cycle processes - Requirements engineering (</article-title>
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Krasiy</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Research of artificial neural network's component of method of characteristics predicition and evaluating the success of software projects implementation</article-title>
          . Transactions of Khmelnitsky National University.
          <volume>1</volume>
          ,
          <fpage>24</fpage>
          -
          <lpage>31</lpage>
          (
          <year>2016</year>
          ) [in Ukrainian]
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Krasiy</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Modelling of process of prediction of software characteristics based on the analysis of specifications</article-title>
          . Computer-Integrated Technologies: Education, Science, Industry.
          <fpage>66</fpage>
          -
          <lpage>76</lpage>
          (
          <year>2014</year>
          ) [in Ukrainian]
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Fenton</surname>
          </string-name>
          , N.:
          <article-title>Software metrics: A rigorous approach (3rd edition)</article-title>
          . CRC Press (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Chen</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Beatty</surname>
          </string-name>
          , J.:
          <article-title>Visual models for software requirements</article-title>
          . MS Press, Washington (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Fatwanto</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Software requirements specification analysis using natural language processing</article-title>
          technique In: International Conference on Quality in Research, pp.
          <fpage>105</fpage>
          -
          <lpage>110</lpage>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Rehman</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Khan</surname>
            ,
            <given-names>M.N.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Riaz</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          :
          <article-title>Analysis of requirement engineering processes</article-title>
          ,
          <source>tools/techniques and methodologies. I.J. Information Technology and Computer Science</source>
          .
          <volume>40</volume>
          -
          <fpage>48</fpage>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Leon</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Leon</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <source>Fundamentals of Information Technology: 2nd Edition</source>
          . Vikas
          <string-name>
            <surname>Publishing</surname>
          </string-name>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Korneev</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ksandopulo</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mashurtsev</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          : Information Technologies: Tutorial. Publishing house “Prospekt” (
          <year>2009</year>
          ) [in Russian]
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Hovorushchenko</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Krasiy</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Method of Evaluating the Success of Software Project Implementation Based on Analysis of Specification Using Neuronet Information Technologies</article-title>
          .
          <source>Proceedings of the 11th International Conference on ICT in Education, Research and Industrial Applications: Integration, Harmonization and Knowledge Transfer. CEURWS</source>
          .
          <volume>1356</volume>
          ,
          <fpage>100</fpage>
          -
          <lpage>107</lpage>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>