<!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 />
    <article-meta>
      <title-group>
        <article-title>A Human-Centered Approach to Assessment of Team Diversity in Multi-Version Software Development</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Serhii Lilikovych</string-name>
          <email>fsergiy.lilikovych@gmail.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Volodymyr Sokol</string-name>
          <email>vlad.sokol@gmail.comg</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="editor">
          <string-name>Key Terms: ModelBasedSoftwareDevelopmentMethodology, Model, Soft-
wareSystem</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Introduction: Problem Actuality and Research Aims</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>National Technical University Kharkiv Polytechnic Institute</institution>
          ,
          <addr-line>Kyrpychova str., 21, Kharkiv, Ukraine 61002</addr-line>
        </aff>
      </contrib-group>
      <fpage>18</fpage>
      <lpage>21</lpage>
      <abstract>
        <p>The article proposes comprehensive approach to personal diversity level assessment of involved developers in order to improve e ciency of multi-version software development. The approach allows to build project teams with prede ned level of diversity intentionally. A common conceptual scheme of the approach is elaborated, an appropriate criteria and metrics to estimate personal diversity of target software products diversity are given, and future research work is outlined as well.</p>
      </abstract>
      <kwd-group>
        <kwd>human-centered</kwd>
        <kwd>diversity</kwd>
        <kwd>multi-version software</kwd>
        <kwd>criteria</kwd>
        <kwd>metrics</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>approach, in Section 3 we outline rst implementation issues for this one, and in
Section 4 the paper concludes with a short summary, and with outlook on the
future research work to be done.
2</p>
      <p>
        Conceptual Scheme of Human-centered Approach
to Assessment of Team Diversity in N-Version
Programming
One of the proven techniques of software diversi cation is N-version
programming (NVP). It assumes a development of N 2 independent software versions,
wherein all versions are supposed to satisfy the same initial system requirements.
Taking into account one of the well-known NVP work ows [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], we propose to
extend it with the DDTs forming procedure, as shown in gure 1 in the form of
an UML activity diagram [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ].
no
no
Personal diversity
assessment
DDTs forming
procedure
      </p>
      <p>Provide a valid
set of DDDs
no
yes</p>
      <p>Are DDDs available?</p>
      <p>Set NVP project
infrastructure</p>
      <p>Are DDTs available?
yes
no</p>
      <p>Common NVP
activities</p>
      <p>yes Is DDTs deivneorusigfihc?ation level
Is DFD level enough?
yes</p>
      <p>
        deNliVveSry
1. set up initial NVP projects infrastructure with selection of technological
parameters for choosing appropriate DDD; the process continuea until a
valid set of DDDs is available (see gure 1);
2. prove the condition, whether a number of DDTs needed is available, where
any DDT has to be considered as an additional dimension in DDD collection;
3. in case both DDD and DDTs are given, the common NVP-projects activities
can be executed, and a Distinct Failure Diversity (DFD) of software product
may be calculated using the appropriate metrics (see below);
4. if DFD value is acceptable (enough), then NVS product may be delivered,
otherwise Step 3 has to be repeated;
5. If DDTs are not available by checking on Step 2, the personal diversity
forming procedure has to be started in order to create new DDTs, and it requires
Personal diversity assessment to be provided using appropriate methods:
e.g., Minnesota Multiphasic Personality Inventory (MMPI), or Myers-Briggs
Type Indicator (MBTI) [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>
        The proposed DDT forming procedure is based on the hypothesis that
certain properties of any developer (age, social status, education degree, sex, etc.)
a ect projects diversi cation level in general. Moreover, such properties have an
in uence on software code they create [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. Consequently, we may identify speci c
developers programming styles by analyzing certain attributes of their code.
3
      </p>
      <p>
        First Implementation Issues for the Proposed Approach
Personal properties set of each software developer can be evaluated using the
MMPI method, which has 8 scales and assumes 16 di erent types of
personality[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. The goal is to create software development teams with diversi cation
levels as low as possible inside the team, and as high as possible between the
teams in order to maximize diversity level between NVP's versions and minimize
it inside teams. The diversi cation level of source code may be assessed using
a set of metrics for developers programming style. There are 50 such metrics
presented in [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] which can be used for software authorship identi cation. Some
of them are given in table 1.
      </p>
      <p>
        In table 1 the value M varies depending on the speci c programming
languages which are used. An e ectiveness evaluation of DDT formation process
may be done with the help of reliability value at the current NVS development
iteration. The following formula may be used to calculate the DFD value [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]:
i versions, which are supposed to be identi ed on the current NVP projects
iteration; therefore ki = Ki=K. Such way we get a diversity level indicator as a
normalized value between 0 and 1, namely: DFD 2 [0; 1].
4
      </p>
      <p>Conclusions and Future Work
In this paper we have presented the human-centered approach to the assessment
of team diversity in N-version programming based on the hypothesis of existence
a correlation between certain number of developers personal properties and their
speci c programming styles. Therefore, the possibility of creation development
teams with target diversi cation level can be provided. It a ects positively a
software product diversi cation level in general, and consequently improves its
reliability. Next steps in this research will be dealing with the following
theoretical and practical tasks:
1. perform a more sophisticated investigation of personal diversity assessment
methods and di erent metrics of developers programming styles;
2. provide a motivated choice of measurement method which should be used to
determine the correlation between parameters mentioned above;
3. propose a formalized DDT forming procedure with a pre-de ned diversity
level, e.g. using some linear programming methods;
4. design and implement the corresponding CASE-tool for automated execution
of all steps in the elaborated DDTs forming procedure;
5. develop the methodology, and to perform a number of simulation
experiments to check the workability and e ectiveness of the proposed approach
in real-life software development.</p>
      <p>The resolution of these issues is foreseen in the framework of the
PhDresearch, which is planned for the period of years 2017-2020.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Capretz</surname>
            ,
            <given-names>L.F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ahmed</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>Why do we need personality diversity in software engineering</article-title>
          ?
          <source>ACM SIGSOFT Software Engineering Notes</source>
          <volume>35</volume>
          (
          <issue>2</issue>
          ),
          <volume>1</volume>
          {
          <fpage>11</fpage>
          (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Ding</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Samadzadeh</surname>
            ,
            <given-names>M.H.</given-names>
          </string-name>
          :
          <article-title>Extraction of Java program ngerprints for software authorship identi cation</article-title>
          .
          <source>Journal of Systems and Software</source>
          <volume>72</volume>
          (
          <issue>1</issue>
          ),
          <volume>49</volume>
          {
          <fpage>57</fpage>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Liang</surname>
            ,
            <given-names>T.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wu</surname>
            ,
            <given-names>J.C.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jiang</surname>
            ,
            <given-names>J.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Klein</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>The impact of value diversity on information system development projects</article-title>
          .
          <source>International Journal of Project Management</source>
          <volume>30</volume>
          (
          <issue>6</issue>
          ),
          <volume>731</volume>
          {
          <fpage>739</fpage>
          (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Lyu</surname>
            ,
            <given-names>M.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>He</surname>
            ,
            <given-names>Y.T.</given-names>
          </string-name>
          :
          <article-title>Improving the N-version programming process through the evolution of a design paradigm</article-title>
          .
          <source>IEEE Transactions on Reliability</source>
          <volume>42</volume>
          (
          <issue>2</issue>
          ),
          <volume>179</volume>
          {
          <fpage>189</fpage>
          (
          <year>1993</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <article-title>5. O cial Website of OMG consortium</article-title>
          . http://www.omg.org/spec/UML/2.0/
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Partridge</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Krzanowski</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Distinct failure diversity in multiversion software</article-title>
          .
          <source>Res. Rep</source>
          <volume>348</volume>
          ,
          <issue>24</issue>
          (
          <year>1997</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Schaefer</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rabiser</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Clarke</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bettini</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Benavides</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Botterweck</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pathak</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Trujillo</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Villela</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Software diversity: state of the art and perspectives</article-title>
          . Springer (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>