Requirements to Products and Processes for Software of Safety Important NPP I&C Systems

2022 ◽  
pp. 212-246
Author(s):  
Vladimir Sklyar ◽  
Andriy Volkoviy ◽  
Oleksandr Gordieiev ◽  
Vyacheslav Duzhyi
Keyword(s):  
Life Cycle ◽  
Software Development ◽  
Software Verification ◽  
Software Requirements ◽  
Software Components ◽  
Software Life Cycle ◽  
Regulatory Documents ◽  
And Control

Features of software as a component of instrumentation and control (I&C) systems are analyzed. Attention is paid to the importance of functions performed by software and hazards of such software. Requirements for characteristics of software as a component of I&C systems are analyzed. Different regulatory documents are considered in order to disclose common approaches to the use of dedicated software and off-the-shelf software components. Classification of software, as well as classification of requirements, is described. Criteria of selection and structuring of requirements, as well as criteria for software verification, are defined. As long as the characteristics of software components directly depend on the quality of the processes of software development and verification, requirements for software life cycle processes are considered.

Requirements to Products and Processes for Software of Safety Important NPP I&C Systems

2020 ◽  
pp. 97-131
Author(s):  
Vladimir Sklyar ◽  
Andriy Volkoviy ◽  
Oleksandr Gordieiev ◽  
Vyacheslav Duzhyi
Keyword(s):  
Life Cycle ◽  
Software Development ◽  
Software Verification ◽  
Software Requirements ◽  
Software Components ◽  
Software Life Cycle ◽  
Regulatory Documents ◽  
And Control

Features of software as a component of instrumentation and control (I&C) systems are analyzed. Attention is paid to the importance of functions performed by software and hazards of such software. Requirements for characteristics of software as a component of I&C systems are analyzed. Different regulatory documents are considered in order to disclose common approaches to the use of dedicated software and off-the-shelf software components. Classification of software, as well as classification of requirements, is described. Criteria of selection and structuring of requirements, as well as criteria for software verification, are defined. As long as the characteristics of software components directly depend on the quality of the processes of software development and verification, requirements for software life cycle processes are considered.

Software of Safety Important I&C Systems

2014 ◽  
pp. 146-177
Author(s):  
Vyacheslav Kharchenko ◽  
Vladimir Sklyar ◽  
Andriy Volkoviy
Keyword(s):  
Software Development ◽  
Nuclear Power ◽  
Software Verification ◽  
Software Requirements ◽  
Software Components ◽  
Software Life Cycle ◽  
Regulatory Documents ◽  
And Control

Features of software as a component of Instrumentation and Control (I&C) systems are analyzed. Attention is paid to the importance of functions performed by software and hazards of such software. Requirements for characteristics of software as a component of I&C systems are analyzed. Different regulatory documents are considered in order to disclose common approaches to the use of dedicated software and off-the-shelf software components. Classification of software, as well as classification of requirements, is described. Criteria of selection and structuring of requirements, as well as criteria for software verification, are defined. As long as the characteristics of software components directly depend on the quality of the processes of software development and verification, requirements for software life cycle processes are considered. The second part of this chapter is dedicated to evaluation of software for nuclear power plant I&C system. Criteria and principles of evaluation are observed. Evaluation of the characteristic of software as a product and software development and verification processes are considered.

Computable metrics of personal performance in software development teams

2019 ◽  
Author(s):  
Andriy Lishchytovych ◽  
Volodymyr Pavlenko
Keyword(s):  
Life Cycle ◽  
Software Development ◽  
Product Quality ◽  
Performance Indicators ◽  
Key Performance Indicators ◽  
Project Manager ◽  
Development Life Cycle ◽  
Software Product ◽  
Software Development Life Cycle

The present article describes setup, configuration and usage of the key performance indicators (KPIs) of members of project teams involved into the software development life cycle. Key performance indicators are described for the full software development life cycle and imply the deep integration with both task tracking systems and project code management systems, as well as a software product quality testing system. To illustrate, we used the extremely popular products - Atlassian Jira (tracking development tasks and bugs tracking system) and git (code management system). The calculation of key performance indicators is given for a team of three developers, two testing engineers responsible for product quality, one designer, one system administrator, one product manager (responsible for setting business requirements) and one project manager. For the key members of the team, it is suggested to use one integral key performance indicator per the role / team member, which reflects the quality of the fulfillment of the corresponding role of the tasks. The model of performance indicators is inverse positive - the initial value of each of the indicators is zero and increases in the case of certain deviations from the standard performance of official duties inherent in a particular role. The calculation of the proposed key performance indicators can be fully automated (in particular, using Atlassian Jira and Atlassian Bitbucket (git) or any other systems, like Redmine, GitLab or TestLink), which eliminates the human factor and, after the automation, does not require any additional effort to calculate. Using such a tool as the key performance indicators allows project managers to completely eliminate bias, reduce the emotional component and provide objective data for the project manager. The described key performance indicators can be used to reduce the time required to resolve conflicts in the team, increase productivity and improve the quality of the software product.

scholarly journals DevOps phases across Software Development Lifecycle

2021 ◽  
Author(s):  
Mayank Gokarna
Keyword(s):  
Life Cycle ◽  
Software Development ◽  
Implementation Strategy ◽  
Quality Of Services ◽  
Comprehensive Collection ◽  
Development Lifecycle ◽  
Development Life Cycle ◽  
Software Development Lifecycle ◽  
Software Development Life Cycle

DevOps is the combination of cultural mindset, practices, and tools that increases a team's ability to release applications and services at high velocity. The development and operations teams always have a conflict around the scope of responsibility. With these differences the quality and speed of delivery across software Development Life Cycle is negatively impacted. DevOps is about removing the barriers between two traditionally delimited teams, development and operations. With DevOps, these two teams work together to optimize both the productivity of developers and the reliability of operations. They strive to communicate frequently, increase efficiencies, and improve the quality of services they provide. They take full ownership for their services, often beyond where their stated roles or titles have traditionally been scoped. Transitioning to DevOps requires a change in culture and mindset first. It is quite difficult to persuade a whole company to change its culture at once. This paper aims to bring different phases of software development lifecycle into DevOps implementation strategy and presents a comprehensive collection of leading tools used across Software Development life Cycle to automate and integrate different stages of software delivery. This paper also highlights on DevOps practices which span across different phases of the Software Development Lifecycle and how those can be implemented with different tools available.

What, Why, Who, When, and How of Software Requirements

2014 ◽  
pp. 1-18 ◽  
Author(s):  
Linda Westfall
Keyword(s):  
Life Cycle ◽  
Software Development ◽  
Software Requirements ◽  
Development Life Cycle ◽  
Software Development Life Cycle ◽  
The Right

If software requirements are not right, companies will not end up with the software they need. This chapter discusses the various levels and types of requirements that need to be defined, the benefits of having the right software requirements, the stakeholders of the software requirements and getting them involved in the process, requirements activities throughout the software development life cycle, and techniques for eliciting, analyzing, specifying, and validating software requirements.

Formal Specifications of Software Model Evolution Using Contracts

2011 ◽  
pp. 184-208
Author(s):  
Claudia Pons ◽  
Gabriel Baum
Keyword(s):  
Software Development ◽  
Development Process ◽  
Formal Specifications ◽  
Software Development Process ◽  
Software Life Cycle ◽  
Software Artifacts ◽  
Software Model ◽  
Intelligent Analysis ◽  
Software Engineers

During the object-oriented software development process, a variety of models of the system is built. All these models are semantically overlapping and together represent the system as a whole. In this chapter, we present a classification of relationships between models along three different dimensions, proposing a formal description of them in terms of mathematical contracts, where the software development process is seen as involving a number of agents (the development team and the software artifacts) carrying out actions with the goal of building a software system that meets the user requirements. In this way, contracts can be used to reason about correctness of the development process, and to compare the capabilities of various groupings of agents in order to accomplish a particular contract. The goal of the proposed formalization is to provide formal foundations for tools that perform intelligent analysis on models assisting software engineers through the software life cycle.

Software Requirements Risk and Maintainability

2005 ◽  
pp. 2562-2566
Author(s):  
Norman F. Schneidewind
Keyword(s):  
Risk Factors ◽  
Life Cycle ◽  
Software Metrics ◽  
Space Shuttle ◽  
Software Requirements ◽  
Requirements Specifications ◽  
Requirements Change ◽  
Code Metrics ◽  
Change Requests

In order to continue to make progress in software measurement, as it pertains to reliability and maintainability, there must be a shift in emphasis from design and code metrics to metrics that characterize the risk of making requirements changes. By doing so, the quality of delivered software can be improved because defects related to problems in requirements specifications will be identified early in the life cycle. An approach is described for identifying requirements change risk factors as predictors of reliability and maintainability problems. This approach can be generalized to other applications with numerical results that would vary according to application. An example is provided that consists of 24 space shuttle change requests, 19 risk factors, and the associated failures and software metrics.

Effective Software Verification and Validation Approach for Nuclear Power Plant Digital Instrumentation and Control Systems

2010 ◽  
Author(s):  
Steve Yang ◽  
Jun Ding ◽  
Huifang Miao ◽  
Jianxiang Zheng
Keyword(s):  
Life Cycle ◽  
Nuclear Power ◽  
Power Plants ◽  
Nuclear Power Plants ◽  
Software Verification ◽  
Verification And Validation ◽  
Common Cause ◽  
Digital Instrumentation ◽  
And Control ◽  
Software Verification And Validation

All 1000 MW nuclear power plants currently in construction or projected to-be-built in China will use the digital instrumentation and control (I&C) systems. Safety and reliability are the ultimate concern for the digital I&C systems. To obtain high confidence in the safety of digital I&C systems, rigorous software verification and validation (V&V) life-cycle methodologies are necessary. The V&V life-cycle process ensures that the requirements of the system and software are correct, complete, and traceable; that the requirements at the end of each life-cycle phase fulfill the requirements imposed by the previous phase; and the final product meets the user-specified requirements. The V&V process is best illustrated via the so-called V-model. This paper describes the V-model in detail by some examples. Through the examples demonstration, it is shown that the process detailed in the V-model is consistent with the IEEE Std 1012-1998, which is endorsed by the US Regulatory Guide 1.168-2004. The examples show that the V-model process detailed in this paper provides an effective V&V approach for digital I&C systems used in nuclear power plants. Additionally, in order to obtain a qualitative mathematical description of the V-model, we study its topological structure in graph theory. This study confirms the rationality of the V-model. Finally, the V&V approach affording protection against common-cause failure from design deficiencies, and manufacturing errors is explored. We conclude that rigorous V&V activities using the V-model are creditable in reducing the risk of common-cause failures.

scholarly journals A Multistep Approach for Managing the Risks of Software Requirements Volatility

2016 ◽  
Vol 9 (1) ◽  
pp. 101
Author(s):  
Nedhal A. Al-Saiyd
Keyword(s):  
Software Requirements ◽  
Software Project ◽  
Font Size ◽  
Software Usability ◽  
Proposed Model ◽  
Requirements Volatility ◽  
And Control ◽  
Requirement Changes ◽  
The Impact

<p><span style="font-size: 10.5pt; font-family: 'Times New Roman','serif'; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: 宋体; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA;" lang="EN-US">Software is changed continuously in order to respond to different users and business needs. Requirements are changed dynamically to improve software usability and increase its value, but requirement volatility sometimes cause failures for many projects because of inadequate understanding of the changing causes and the consequences of these changes. This research highlights the importance of managing requirement changes, classify them, and control the impact risks of requirement volatility on software project. The proposed model is designed based on software requirements risks factors and how to reduce their impacts. Generally, requirements changing is considered as a difficult, costly and time-consumed task, and consequently it is too important to study the inter-relationships between the changes and their impacts on the other phases of software system. The good understanding of the changing causes and their consequences can improve and support requirements management process and also lead successfully to the predicted goals of changes. The high quality of the requirements influences the success of a software project during software development and maintenance processes.</span></p>

scholarly journals Metabolomics Approach for Discrimination and Quality Control of Natural and Commercial Fallopia multiflora Products in Vietnam

2020 ◽  
Vol 2020 ◽  
pp. 1-8
Author(s):  
Nguyen Thi Thoa ◽  
Nguyen Hai Dang ◽  
Do Hoang Giang ◽  
Nguyen Thi Thu Minh ◽  
Nguyen Tien Dat
Keyword(s):  
Clustering Analysis ◽  
Principal Component ◽  
Multivariate Statistical Methods ◽  
Multivariate Statistical ◽  
Fda Guidance ◽  
Promising Tool ◽  
Precision And Accuracy ◽  
And Control

A precise HPLC-DAD-based quantification together with the metabolomics statistical method was developed to distinguish and control the quality of Fallopia multiflora, a popular medicinal material in Vietnam. Multivariate statistical methods such as hierarchical clustering analysis and principal component analysis were utilized to compare and discriminate six natural and twelve commercial samples. 2,3,4′,5-Tetrahydroxystilbene 2-O-β-D-glucopyranoside (THSG) (1), emodin (4), and the new compound 6-hydroxymusizin 8-O-α-D-apiofuranosyl-(1⟶6)-β-D-glucopyranoside (5) could be considered as important markers for classification of F. multiflora. Furthermore, seven phenolics were quantified that the variation in the contents of selected metabolites revealed the differences in the quality of natural and commercial samples. Recovery of the compounds from the analytes was more than 98%, while the limits of detection (LOD) and the limits of quantitation (LOQ) ranged from 0.5 to 6.6 μg/ml and 1.5 to 19.8 μg/ml, respectively. The linearity, LOD, LOQ, precision, and accuracy satisfied the criteria FDA guidance on bioanalytical methods. Overall, this method is a promising tool for discrimination and quality assurance of F. multiflora products.

Sign in / Sign up

Export Citation Format

Share Document