<!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>Problems Review, High-Level Architecture, Identification Stakeholders and Their Requirements During the Implementation of Quality Control in the Case of Software Development</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Michail V. Druzhinin</string-name>
          <email>michaildrujinin@gmail.com</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Alexander N. Kulemin</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>ABC Solutions</institution>
          ,
          <addr-line>Moscow</addr-line>
          ,
          <country country="RU">Russia</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Ural Federal University</institution>
          ,
          <addr-line>Yekaterinburg</addr-line>
          ,
          <country country="RU">Russia</country>
        </aff>
      </contrib-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Nowadays current software solutions happen on a short notice and with limited resources.
The importance of software quality assurance stems from the pace of IT-companies development
ant their interest in the product’s competitiveness. In that case developers may ignore the necessity
of providing a certain level of software solutions exposing the project to risks.</p>
      <p>
        It requires elaboration of key indicators which define the ability to work well and produce
quality products. Key indicators characterize the dynamic of project development in measurable
units used for planning of project during the entire life cycle of software. Indicators directly
connected to mistakes found in the program – bugs. Detection and elimination of those defects in
early stages of software development would cost the company much less than in later operational
phases[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>Testing allows aggregate information about mistakes that are already found in the process of
development. Timely report about a defect to project managers, developers and analytics decreases
the odds of repeating those mistakes which positively influences software quality and also provides
with ability to control the course of development by redistributing resources in time.</p>
      <p>
        Testing system is a set of regulated measures in the end of which there is an analysis of
obtained results[
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. Set of measures consists of:
 Planning of testing;
 Analysis of testing results;
 Tests verification;
 Report verification; etc.
      </p>
      <p>There are manual testing, via test engineer, and auto testing. Auto tests partly exclude time
wasted on their replication and inclusion of human factor in testing process. Companies benefit
from using auto tests, if the required tests are repeated and of the same type, because in that case
there will be released resources for redistribution within the project.</p>
      <p>In work itself object of the research is a software life cycle. Research goal is application of
systematic approach to system design of quality control at the stage of determination of
stakeholders.</p>
      <p>
        Figure 1 - V–diagram of a life cycle[
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]
Software lifecycle presented in V–diagram implies four levels of verification:
1. Program and methodology of testing units
2. Subsystem verification plan
3. System verification plan
4. System validation plan
While designing quality control system (QCS) level one is taken into account. For identification of
stakeholders on the testing level we’ll consider QCS as a ―black box‖ in the operational context.
Systems exchange with QCS streams will affect quality control process, which means in SOE there
are interested parties. Table 1 shows stakeholders and their roles[
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>Function of conducting quality control in software development is carried out by testers. To
fixate a certain level of quality there are different metrics such as: ratio of successful tests to all of
the tests. Metrics allow assessing product’s quality, its pace of development and adjusting the
course of development.</p>
      <p>Quality assurance – is a set of measures for the entire software development lifecycle
including measures for achieving a certain level of quality. Starting from the step of determining
stakeholders’ requirements, where QA engineers validate if realization of the requirements is
possible in the context of the current state of the system. Based on that, a decision can be made
about advisability of system modification. To make this decision it is necessary to analyze the
system ability to change and predict options of product quality development. This leads to changing
tests scripts and update of testing documentation.</p>
      <p>Requirements of different stakeholders need further design of model-oriented
businessanalysis which includes defining correlation between business-function and business-functional
connection, defining business-structures and business-interfaces for their detailing and defining
goals of every interested party. During specification of requirements new stakeholders may appear
that were not there during ―black box‖ approach. Establishing goals of an interested party improves
understanding while designing the system, which directly affects product quality. This approach
helps define main and secondary goals which give more flexibility while making decisions on
distributing resources.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. ISO/IEC 9126-1:2001 Software engineering
          <article-title>- Product quality - Part 1: Quality model</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2. ISO 9000:
          <year>2015</year>
          <article-title>Quality management systems - Fundamentals and vocabulary - Part 3: Terms and definitions</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>Aleksandr</given-names>
            <surname>Kosyakov</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Uilyam N.</given-names>
            <surname>Svit</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Semyuel</given-names>
            <surname>Dzh</surname>
          </string-name>
          . Seymur,
          <string-name>
            <surname>Stiven M. Bimer</surname>
          </string-name>
          (
          <year>2014</year>
          )
          <article-title>Systems Engineering: Principles and Practice</article-title>
          . Moscow: DMK Press.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>Stakeholder</given-names>
            <surname>Needs</surname>
          </string-name>
          and Requirements. (
          <year>2015</year>
          , June 29). SEBoK, .
          <source>Retrieved</source>
          <volume>11</volume>
          :
          <fpage>20</fpage>
          ,
          <string-name>
            <surname>June</surname>
            <given-names>6</given-names>
          </string-name>
          , 2018 from http://www.sebokwiki.org/w/index.php?title=Stakeholder_Needs_and_Requirements&amp;oldid=
          <fpage>51430</fpage>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>