title: Results and discussion - Namangan Institute of Engineering and Technology nammti uz
text: 2. Results and discussion. The rapid growth in the complexity and size of modern software
  systems, while simultaneously increasing the responsibility of the TSRT functions performed, has
  sharply increased the requirements from customers and users for their quality, operational
  Namangan Institute of Engineering and Technology
  nammti.uz
  10.25.2023
  Pg.278
  reliability and safety of use. The characteristics of the main projects have fundamentally changed -
  developments have moved from programming “in the small” to programming “in the large” [2].
  As the use and complexity of TSRT have increased, areas have emerged (primarily those
  associated with UAV applications) where errors or poor software quality can cause harm far
  outweighing the benefits of their use. In these critical cases, anomalies and defects in the
  functioning of the TSRT software are unacceptable in the event of any distortion of the source data,
  failures, partial hardware failures and other abnormal situations. However, sometimes excessively
  high requirements for the quality of software for such systems cannot be met in principle due to
  real limitations of all types of resources: budget, development time, characteristics of computing
  systems and qualifications of specialists. This led to the emergence, development and application
  of methods, standards and automation tools for industrial software engineering, ensuring the
  creation of complex TSRT software architectures with specified high-quality indicators under real
  restrictions on the use of development resources.
  Since the cost of failure of TSRT software, especially critical ones, is usually very high, it is
  necessary to ensure that the architectural specification of critical systems is of high quality and
  accurately reflects the real needs of the system users.
  TSRT software architecture reliability is a complex concept that must be considered at the
  system-wide level, rather than at the level of individual architectural components. Because system
  components are interconnected, a failure in one component can propagate through the system to
  other components. In complex software systems, when determining failure-free operation, a set of
  components is taken into account, among which one of the important places is occupied by software
  reliability, which is defined as the probability of software failures.
  Currently, software engineering is an independent discipline that deals with the problems of
  creating reliable and trouble-free software systems. This discipline calculates the probabilities of
  failure of various system components and determines how their combinations affect the overall
  reliability of the system.
  As the number of dependent components increases, the likelihood of system failure also
  increases. If there are many critical components in a system, then each individual component must
  be very reliable so that the probability of system failure is low. To increase reliability, components
  can be duplicated (N-variant and multi-version software design [3]). Then a group of identical
  components that duplicate each other will work correctly as long as at least one component works
  correctly.
  System reliability can be defined as a non-functional requirement, which is expressed
  numerically through the indicators proposed and discussed in [4]. To fulfill non-functional
  requirements for failure-free operation, it is necessary to additionally set functional requirements
  for the system that determine ways to eliminate system failures. Examples of such requirements
  are as follows.
  1. Establishing a specific range for all values entered by the operator, and systematically
  monitoring all entered values to check whether they fall within this range.
  2. During the initialization process, the system must check all disks for bad blocks.
  3. To implement the system shutdown control subsystem, N-variant programming should be
  used (a special method for ensuring software fault tolerance).
  4. The system must be implemented in a secure subset of a high-level programming language
  and verified using static analysis.
  There are no simple rules that can be used to derive the functional requirements for fault-free
  software architecture. Organizations developing special systems usually have some knowledge of
  possible non-failure requirements and how these requirements affect the actual reliability of the
  software.
  |