ГОСТ Р МЭК 61508-7—2012
В процессе проверки ее результаты должны бытьформально зафиксированы модератором, роль которогодолж
на упростить проверку. По результатам всеми проверяющими должно быть достигнуто согласие. Ошибки должны быть
разделены на: а) требующие исправлениядо принятия элемента программного обеспечения и Ь) требующие исправле
ния к заданному моменту времени или этапу. После завершения проверки выявленные ошибки должны быть переданы
разработчику для последующего исправления. В зависимости от количества и контекста выявленных ошибок модера
тор может решить вопрос о необходимости повторной проверки материалов о программном обеспечении.
Литература:
Software engineering: Update. Ian Sonvnerville. Addison-Wesley Longman. Amsterdam: 81’1 ed.. 2006, ISBN
0321313798. 9780321313799.
Software Engineering. Ian Sommerville. Pearson Studium. 8. Auflage. 2007. ISBN 3827372577, 9783827372574.
The Art of Software Testing, second edition. G.J. Myers, T. Badgett. T.M. Codd. C. Sandler. John Wiley and Sons,
2004. ISBN 0471469122. 9780471469124.
Fagan. M. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal 15. 3
(1976): 182—211.
C.5.15 Сквозной контроль (программного обеспечения)
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).
Цель. Обнаружение несоответствий между спецификацией и реализацией.
Описание. Сквозной контроль является неформальным методом, выполняемым разработчиком элемента
программного обеспечения в присутствии его коллег в целях обнаружения ошибок в элементе программного обе
спечения. Он может быть выполнен для конкретных элементов программного обеспечения, созданных на любой
стадии жизненного цикла разработки программного обеспечения.
Чтобы гарантировать, что система, связанная с безопасностью, соответствует требованиям, заданным
в спецификации, необходимо исследовать и оценить заданные в спецификации функции системы, связанной
с безопасностью. Любые сомнения, связанные с реализацией и использованием создаваемой системы,
докумен тально оформляются в целях ихдальнейшего решения. В отличие от формальной проверки в процедуре
сквозного контроля разработчик принимает активное участив.
Литература:
Software engineering: Update. Ian Sommerville. Addison-Wesley Longman. Amsterdam; 81’1 ed.. 2006, ISBN
0321313798.9780321313799.
Software Engineering. Ian Sommerville. Pearson Studium. 8. Auflage. 2007. ISBN 3827372577, 9783827372574.
The Art of Software Testing, second edition. G.J. Myers, T. Badgett. T.M. Codd. C. Sandler. John Wiley and Sons.
2004. ISBN 0471469122. 9780471469124.
C.5.16 Анализ проекта
П р и м е ч а н и е — Ссыпка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).
Цель. Выявление дефектов в проекте программного обеспечения.
Описание. Под анализом проекта понимается формальное, документально оформленное, всестороннее и си
стематическое исследование проекта программного обеспечения в цепях оценки требований к проекту и возмож
ности проекта удовлетворить этим требованиям, а также для определения проблем и предложений по их решению.
Анализ проекта является средством оценки соответствия состояния проекта входным требованиям, а также
средством идентификации возможностей для его дальнейшего усовершенствования. Даже если разработка про
екта на этапах жизненного цикла выполняется успешно и основные конкретные проектные требования удовлетво
рены. то анализ проекта должен быть выполнен, чтобы исследовать все интерфейсные аспекты: гарантировать, что
проект может быть верифицирован, чтобы быть уверенным, что он удовлетворяет проектным требованиям; и
гарантировать, что проект в наибольшей степени удовлетворяет требованиям безопасности. Такой анализ, пре жде
всего, предназначен для проверки результатов работы разработчиков и должен рассматриваться какдействия по
подтверждению и совершенствованию этих результатов.
Чтобы обнаружить неправильное поведение программного обеспечения, такое как непредвиденные после
довательности выполнения операторов или логики, непреднамеренные выходы, неправильная синхронизация, не
желательные действия, может использоваться строгий метод проверки, такой как «анализ скрытых схем».
Литература:
Software engineering: Update. Ian Sommerville. Addison-Wesley Longman. Amsterdam: 8n ed.. 2006. ISBN
0321313798. 9780321313799.
Software Engineenng. Ian Sommerville, Pearson Studium. 8. Auflage. 2007. ISBN 3827372577, 9783827372574.
The Art of Software Testing, second edition. G.J. Myers, T. Badgett. T. M. Codd. C. Sandler. John Wiley and Sons,
2004. ISBN 0471469122. 9780471469124.
IEC 61160:2005. Design review.
Space Product Assurance. Sneak analysis — Part 2: Clue lisL ECSS-Q-40-04A Part 2. ESA Publications Division,
Noordwijk. 1997, ISSN 1028-396X.
http://www.everyspec.com/ESA/ECSS-Q-40-04A_Part-2_14981/.
C.5.17 Макетирование/анимация
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.З и В.5).
63