CC BY
77
Выбор стандартов в соответствии с этапами жизненного цикла информационных систем
В.В. Холмогоров, В.В. Баранюк
Аннотация - Определение набора стандартов является одной из наиболее важных составляющих создания информационной системы, так как стандарты, во-первых, упрощают практически все процессы жизненного цикла за счёт своей чёткости и структурированности, а, во-вторых, позволяют при их правильном выборе и применении обезопасить команду исполнителей, заказчика и сам продукт в нормативной сфере.
В состав любой современной информационной системы, как правило, входит программное средство, которое по завершению всех работ становится программным продуктом. Создание программного продукта является трудоёмким процессом, который часто затягивается, либо вообще прекращается по различным причинам, которые, обычно, связаны с низким качеством выполнения работ, превышением временных рамок или недопониманием между исполнителем и заказчиком. В основном подобные проблемы возникают из-за того, что команда исполнителя не может грамотно определить модель реализации продукта на этапах его жизненного цикла от формирования требований до тестирования и документирования.
Стандарты нередко выступают в качестве инструкции для заинтересованных лиц. Однако выбор стандартов, неподходящих под конкретный продукт, может усложнить задачу по его реализации вместо того, чтобы её упростить, поэтому важно уметь выбирать наиболее подходящие стандарты на всех этапах жизненного цикла создаваемого продукта.
Настоящая статья демонстрирует возможный ход анализа и выбора стандартов на всех этапах жизненного цикла на примере программной системы входного профилирования абитуриентов.
Ключевые слова - набор стандартов, государственные и международные стандарты, жизненный цикл, программная система входного профилирования абитуриентов.
ВВЕДЕНИЕ
Перед разработкой любого программного средства (ПС) обычно определяется набор (профиль) стандартов, требованиям которых должны удовлетворять как процесс разработки, так и готовый программный продукт. Одной из задач стандартизации является уменьшение разногласий и непонимания между заказчиком (пользователем) и разработчиком при помощи нормативной базы, устанавливающей и структурирующей процессы разработки программного средства и документации к нему.
Статья получена 13.01.2022 г.
В.В. Холмогоров, МИРЭА (e-mail: Hvv13@mail.ru).
К.т.н., с.н.с., В.В. Баранюк, МИРЭА (e-mail: baranyuk@mirea.ru).
Вопросы выбора стандартов при разработке ПС рассматриваются на примере программной системы входного профилирования абитуриентов («Ориентир») [1], задачей которой в общем виде является помощь студентам в выборе направления обучения в высших учебных заведениях на основе результатов тестирования профориентации посредством психоанализа -совокупности методов определения психотипа человека, который несёт в себе его черты характера, интересы и особенности восприятия окружающего мира. Основной причиной создания системы тестирования абитуриентов на основе псиохоанализа является часто проявляющееся затруднение в определении абитуриентами направления обучения. Психоаналитическое тестирование должно помочь будущим студентам понять, какие направления наиболее подходят им по интересам и личностным качествам. Большое количество абитуриентов и сложность самого процесса психоанализа обуславливают необходимость автоматизации указанного процесса.
Перед разработкой программной системы следует определить набор стандартов, в соответствии с которыми она будет создаваться. Из приведённого выше общего описания системы следует, что стандарты необходимо искать в области стандартизации, связанной с информационными технологиями и разработкой ПС.
Заранее стоит отметить, что согласно пункту 3 статьи 26 Федерального закона «О стандартизации в Российской Федерации»: «применение национального стандарта является обязательным для изготовителя и (или) исполнителя в случае публичного заявления о соответствии продукции национальному стандарту, в том числе в случае применения обозначения национального стандарта в маркировке, в эксплуатационной или иной документации, и (или) маркировки продукции знаком национальной системы стандартизации», то есть при упоминании национального стандарта в договоре на разработку, и (или) техническом задании (ТЗ) ПС без конкретизации и исполнитель, и заказчик обязаны будут следовать не конкретному пункту, а всему стандарту. Более того, может произойти ситуация, когда текст стандарта, на который ссылается национальный
(межгосударственный) стандарт, изменился, а сам стандарт пока остался прежним, это может привести к нестыковкам и даже противоречиям формулировок. Поэтому, иногда лучше использовать оригиналы международных стандартов (если это возможно), либо указывать конкретные пункты стандарта. Ещё более сложным случаем является применение локализированных международных стандартов, которые
входят в единый комплекс (принятые в одно время как единая серия), так как может сложится ситуация, при которой конкретный иностранной стандарт был переведён и принят как национальный, а остальные стандарты из этого комплекса не были переведены и приняты в качестве национальных. В таком случае принятый стандарт может ссылаться только на оригинальные международные стандарты, тогда и исполнитель, и заказчик должны будут следовать не только указанному стандарту, но и всему комплексу стандартов, в состав которого входит данный.
Выбор основной серии стандартов, которые будут использоваться в процессе разработки, зависит от класса разрабатываемой системы. Стандарты серии 34 регламентируют полный цикл создания автоматизированных систем и документации к ним, стандарты серии 19 регламентируют полный цикл создания программ и программной документации.
Следует отметить, что при разработке программных систем за основу часто берутся стандарты серии 34 для описания жизненного цикла (ЖЦ) и наиболее важных требований (например, к хранению, эксплуатации и маркировке), а программная документация разрабатывается по стандартам серии 19.
Если планируемая к разработке система должна представлять некоторое ПС, то можно остановиться на стандарте ИСО/МЭК 12207-2010 [2], так как он регламентирует процессы жизненного цикла ПС. В ИСО/МЭК 12207 достаточно внимания уделено архитектуре программных средств и систем (проектированию и созданию), однако не оговариваются конкретные требования. Среди особенностей данного стандарта стоит отметить наиболее обширную, полную и проработанную систему процессов ЖЦ, и то, что большое внимание уделяется тестированию и приёмке ПС, также присутствует свободный выбор модели ЖЦ (причём совершено свободный, так как этот стандарт не подразумевает рекомендуемых моделей вообще, а лишь даёт рекомендации по основным пунктам, которые и так присутствуют во всех известных моделях). ИСО/МЭК 12207 имеет лишь рекомендации по применения моделей ЖЦ, в то время как ГОСТ 34.601-90 [3] имеет собственную модель (правда, называется она не жизненный цикл, а стадии разработки), в тоже время стандарты серии 34, в отличие от ИСО/МЭК 12207, не поддерживают все процессы ЖЦ. Несмотря на явное превосходство стандартов 34 серии с точки зрения требований, более дальновидно применение ИСО/МЭК 12207, так как он поддерживает все этапы ЖЦ, регламентирует именно ЖЦ ПС и свободнее в плане применения иных стандартов и моделей, документацию же стоит разрабатывать с помощью других стандартов, например, с помощью стандартов 34 серии и стандартов Единой системы программной документации (ЕСПД).
ФОРМИРОВАНИЕ ТРЕБОВАНИЙ
Рассматривать нормативные документы стоит в порядке обращения к ним в процессе ЖЦ разрабатываемой системы. В первую очередь следует
отметить, какие стандарты, описывающие жизненный цикл ПС, применимы к рассматриваемой системе.
Поскольку выбор стандартов рассматривается на примере программной системы «Ориентир», то предполагается, что это продукт, непосредственно связанный с системой образования и государственными высшими учебными заведениями, поэтому очень важно, чтобы все требования, функции и сроки были задокументированы, иначе говоря, должно быть разработано ТЗ. Если в модели ЖЦ определились с использованием стандартов серии 34, то ТЗ разрабатывается с уточнённым содержанием основных пунктов ГОСТ 34.602-89 [4]. Если разрабатывается программный продукт, то следует обратиться к стандартам серии 19 (главным образом - ГОСТ 19.20178 [5]).
Следует сделать небольшое отступление, определив два временных промежутка, в течении которых могут разрабатываться модели.
В первом случае разработка моделей для определения требований к системе может происходить до разработки ТЗ, совокупность таких моделей называется архитектурой, она отражает как систему в целом, так и её компоненты, а также связи между ними.
Во втором случае модели разрабатываются в рамках процесса проектирования конкретных модулей с целью подробного рассмотрения будущей системы и уменьшения вероятности принятия неправильных решений по её реализации. На основе этих моделей разрабатываются макеты, прототипы и математические модели, которые созданы для разработчиков с целью упрощения процесса создания системы и в большей степени соответствия первоначальным требованиям.
Модель разрабатываемой системы также должна соответствовать современным стандартам, которые позволяют создавать программные продукты более адаптивными и современными, для этого хорошо подходят (в вопросах моделирования систем) стандарты серии ISO и их русифицированная версия ГОСТ ИСО.
С другой стороны, большинство высших учебных заведений являются государственными объектами, что подразумевает нормативную базу и программу работы государственного уровня, где важны чёткая структурированность и определённость в создании и поддержке системы, этим требованиям удовлетворяют стандарты Российской Федерации серии ЕСПД и ГОСТ Р. Вышеупомянутое требование к современности и гибкости создаваемой системы подкрепляется необходимостью построения наиболее оптимальной модели системы и её прототипа, этому могут помочь идеи из современных технологий моделирования и управления, как CRM, так как идея того, что клиент (а в нашем случае - абитуриент) является ключевым элементом системы, идеально вписывается в концепцию системы тестирования абитуриентов; Workflow (модель поток работ) и концепция открытых информационных систем могут быть использованы для большей наглядности и прозрачности работы системы, взаимодействия с ней людей; OLAP и ETL могут быть применены для сбора данных и их обработки в общую базу с разных источников с точки зрения обобщения и
анализа (идеальный выбор с точки зрения стандартизации); ARIS, BPMN, DFD, EPC, ERD, Flowchart, UML и SADT могут использоваться для прорисовки архитектуры и моделей конкретных элементов системы.
Определившись с моделью ЖЦ, потребитель (заказчик) и исполнитель (разработчик) обсуждают требования к системе (или программному продукту), её функциональность и сроки разработки, документирование этих аспектов проводится посредством создания ТЗ, которое должно составляться совместно и заказчиком, и исполнителем, либо должно быть хотя бы согласовано в обязательном порядке обеими сторонами. Техническое задание для программного продукта, как правило, разрабатывается по соответствующим стандартом ЕСПД. Из основных преимуществ данного стандарта стоит выделить внесение упорядоченности в процесс документирования ПС, лояльность к применению дополнительной документации и изменению уже существующей. Если же для заказчика не принципиально составление подробной технической документации, то вполне подойдёт ГОСТ Р ИСО/МЭК 9294-93 [6], так как этот стандарт в общем виде даёт рекомендации по эффективному управлению документированием ПС. Он предназначен в основном для руководителей, отвечающих за создание ПС, оказывает помощь в определении стратегии и в выборе стандартов по документированию, помогает в выборе процедур документирования и в определении необходимых ресурсов, а также способствует составлению планов документирования.
РАЗРАБОТКА АРХИТЕКТУРЫ
Когда все требования определены начинается один из наиболее важных этапов создания системы -моделирование архитектуры с последующим проектированием и прототипированием. Архитектура определяет механизмы работы ПС как в целом, так и с точки зрения каждой отдельной функции, создание архитектуры - творческий высокоинтеллектуальный процесс, поэтому строгий регламент её создания не имеет смысла и, более того, может оказать негативное влияние на процесс создания. Существует множество методологий моделирования архитектуры, но практически нет стандартов по её созданию. Стандартом, который регламентирует создание архитектуры информационных систем является ISO/IEC/IEEE 42010:2011 [7]. Отечественным аналогом данного стандарта является стандарт ГОСТ Р 571002016 [8], однако его применение весьма спорно, так как данный стандарт фактически является техническим переводом ISO/IEC/IEEE 42010:2011. Вне зависимости от того, был ли выбран документ, руководящий порядком создания архитектуры, или он даже не рассматривался, моделировать архитектуру необходимо. На данный момент существует множество нотаций моделирования процессов работы систем и их взаимосвязей. Так как «Ориентир» в первую очередь является информационной системой для
государственных высших учебных заведений, то и её модели должны быть понятны и привычны государственному заказчику, с чем вполне хорошо справляются модели SADT (IDEF0, DFD, IDEF3), UML, BPMN. Документация и литература по вышеописанным технологиям полны и даже избыточны для моделирования систем, если же потребитель при выборе использования нотации UML решит, что необходимо нормативное регулирование, то можно использовать ISO/IEC 19505 [9], потому что именно этот стандарт даёт описание методологии и её применения. Однако это может лишь затормозить моделирование архитектуры, так стандарт достаточно объёмный, из-за чего времени на следование его пунктам и указаниям может уйти больше, чем на документирование всего остального ЖЦ.
РАЗРАБОТКА ПРОГРАММНОГО СРЕДСТВА
Наличие разработанной архитектуры делает возможным создание прототипа разрабатываемой системы, а в дальнейшем и создание системы целиком, и на этом этапе уже имеет смысл рассматривать стандарты, которые будут отвечать за техническую составляющую системы. Как уже отмечалось, система «Ориентир» основана на пересечении двух предметных областей - психодиагностики и приёма абитуриентов, поэтому и рассматривать стандарты, реализующие данную систему, целесообразно с двух точек зрения. Технически всё, что связано с абитуриентами, направлениями обучения, отзывами с кафедр и рекомендациями, представляет из себя базу данных с вышеперечисленной информацией. В результате работы системы в базу данных загружается информация об абитуриентах и результатах тестирования. Из неё выгружаются алгоритмы тестов, а по окончании тестирования по полученным результатам выгружаются рекомендации для абитуриентов.
Для моделирования и реализации баз данных существует множество систем управления базами данных (СУБД) и методологий. Из СУБД стоит выделить MySQL, Microsoft SQL Server, Oracle Database и PostgreSQL, из методологий моделирования баз данных - DFD, UML и BPMN (нотация BPMN не предназначена специально для моделирования баз данных, однако её элементов вполне хватает для описания потоков данных и документов в ИС). Если же потребителю необходим стандарт в области моделирования и создания баз данных, то можно обратиться к ISO/TR 9007:1987 [10] или к его межгосударственному аналогу ГОСТ 34.320-96 [11]. Несмотря на явную избыточность данных стандартов, они подробно описывают всю концепцию и терминологию баз данных, которые в том или ином виде присутствуют во всех СУБД. Для регламентирования управления базами данных могут быть применены ISO/IEC 10032:1995 [12] и его межгосударственный аналог ГОСТ 34.321-96 [13]. Данные стандарты являются идейными продолжателями ISO/TR 9007:1987 и ГОСТ 34.320-96 как по объёму, так и по содержанию, они вполне понятно и в соответствии
с современными СУБД описывают методы и процессы обмена данных внутри информационных систем и способы управления ими.
Рекомендации для абитуриентов в системе «Ориентир» строятся на основе специальных алгоритмов, соответствующих реально существующим тестам психодиагностики в сфере профориентации. Тесты психодиагностики способны определить интересы и характер человека, при этом сначала абитуриенту предлагается выбрать те направления, которые он для себя считает интересными, однако не может определиться с выбором, а после этого выбора ему предлагается пройти серию тестов по психодиагностике, которые определяют наиболее подходящие ему по интересам и психологическим метрикам направления обучения.
Следует отметить, что до сих пор не существует международной или государственной нормативной базы, которая бы позволяла на общих основаниях применять любые психологические методики в любой сфере профессионального отбора, однако стоит заметить, что некий общий свод правил применения тестов психодиагностики и методик их проведения всё же есть. Одним из регламентирующих документов создания и проведения систем тестов психодиагностики принято считать «Нормативные предписания к разработчикам и пользователям психодиагностических методик» [14]. Данный документ подробно и точно определяет требования к психодиагностической литературе и методическим материалам, требования к методикам, пользователям, психологу-психометристу (разработчику тестов), психологам-преподавателям и использованию ЭВМ в психодиагностике.
ТЕСТИРОВАНИЕ
Стандарты, посвящённые тестирования ПС, появились достаточно давно, к примеру, IEEE 1008 [15], который устанавливал порядок модульного тестирования программного обеспечения, появился ещё в 1987 году, однако основной проблемой стандартизации в тестировании каких-либо ПС являлось отсутствие международных (ISO) стандартов, которые были бы приняты в большинстве стран мира и могли бы установить некий общий порядок тестирования программного обеспечения (ПО), но на то были свои причины. Дело в том, что в теории и практике тестирования существует принцип «Context-driven testing» (контекстно-зависимое тестирование), который гласит, что тестирование должно производится в соответствии с контекстом создаваемого ПС, причём на этот контекст влияют время, стадии и цели создания. Основные постулаты context-driven testing говорят о том, что существует множество достаточно хороших практик тестирования, но среди них нет наилучшей, что многие проекты создаются и развиваются непредсказуемо, что качественное тестирование -сложный интеллектуальный процесс, который требует творческого подхода к нахождению ошибок, а также, что эффективное тестирование любого продукта должно производится в нужное время, по определённому плану
при обсуждении проекта командой с помощью знаний, которые приобретаются командой сообща на протяжении всего времени работы над проектом.
Однако международный стандарт, который мог бы регламентировать все этапы тестирования программного обеспечения на международном уровне, всё же вышел в 2013 в виде серии стандартов ISO 29119 «Testing Standard», последний стандарт из этой серии вышел в 2016 году и является 5 по счёту. Первый стандарт этой серии ISO/IEC/IEEE 29119-1:2013 [16] включает в себя концепцию и терминологию тестирования, объясняет, что такое тестирование и почему необходимо, какие существуют подходы к тестированию, роль тестирования в ЖЦ программных средств и документацию тестирования. Его отечественным переводом является ГОСТ Р 56920-2016 [17]. Второй стандарт из этой серии - ISO/IEC/IEEE 29119-2:2013 [18] (в России - ГОСТ Р 56921-2016 [19]) описывает процессы тестирования так, чтобы их могла использовать «любая организация при выполнении любых форм тестирования программного обеспечения», определяет процессы тестирования программного обеспечения на организационном уровне, уровне менеджмента тестирования и уровнях динамического тестирования. Третий стандарт этой серии ISO/IEC/IEEE 29119-3:2013 [20] (в России ГОСТ Р 56922-2016 [21]) определяет стандарты тестирования тех процессов, что были описаны во втором стандарте, главной особенностью данного стандарта является то, что они применим для всех моделей ЖЦ разработки программного обеспечения. Четвёртый стандарт данной серии ISO/IEC/IEEE 29119-4:2015 [22], как и заключительный 5 стандарт, не был принят в России в качестве национального стандарта. Стандарт полностью посвящён существующим технологиям тестирования, проектированию тестов, техникам тест-дизайна. Среди его достоинств стоит отметить то, что стандартные методы проектирования тестов подразделяются на 3 основные категории: технические характеристики, состав и методы разработки тестов, основанные на опыте. Заключительный пятый стандарт ISO/IEC/IEEE 29119-5:2016 [23], полностью посвящён Keyword Driven Testing - технологии, которая позволяет реализовать визуальное представление тестовых скриптов, когда каждому действию сопоставляются некие ключевые слова. Данная серия стандартов имеет спорный статус среди крупных специалистов в сфере QA (Quality Assurance), так как, по сути, она является переосмыслением и объединением созданных ранее стандартов (например, BS 7925-1 [24] и IEEE 829 [25]), которые раньше были необязательны, если специалисты не видят в них смысла. С международным же стандартом приходится считаться и использовать, в любом случае, данная серия пока является единственной полномасштабной серией стандартов, полностью посвящённым всем процессам тестирования. Если же по какой-то причине серия 29119 является избыточной, стоит обратиться к ISO/IEC 25051:2014 [26] или к его русифицированной версии ГОСТ Р ИСО/МЭК 250512017 [27], даже несмотря на, что данной стандарт рассчитан больше на разработчиков ПО, он содержит в
себе большинство необходимых для специалистов по обеспечению качества рекомендаций и описаний: среды тестирования, тестовую документацию, план тестирования, описание тестов и их результатов.
ДОКУМЕНТИРОВАНИЕ
Документирование информационных систем производится на всех этапах ЖЦ, от предварительного создания бизнес-плана и последующего создания ТЗ, до плана тестирования и приёмки. В эпоху активного распространения архитектуры микросервисов, индустрии обслуживания и сопровождения также активно встал вопрос документирования на этапе постпродакшна, поэтому к выбору стандартов документирования систем необходимо подходить практично и опираясь на определённую стратегию производства. Каждый стандарт или серия стандартов определяет свой (хоть иногда схожий) набор документов. Исходя из структуры и целей создаваемых систем стоит выделить два основных стандарта документирования: ГОСТ 34.201-89 [28] для автоматизированных систем и ГОСТ 19.105-78 [29] для программных. Если конкретизация создаваемой документации не нужна, но при этом существует потребность в руководстве, стратегии процессов документирования, в понимании ролей руководства, функций программной документации и в определении стандартов и руководств документирования, то хорошим решением может стать ГОСТ Р ИСО/МЭК 9294-93 [30]. Также нормальной практикой является применение одновременно нескольких стандартов документирования, как правило, подобный подход применяется в случаях, когда основные постулаты и список рекомендуемых документов одного стандарта подходят для применения их в разрабатываемой системе, однако к некоторым элементам предъявляются особые требования, тогда для описания именно этих специфичных элементов можно применить другой стандарт.
ОЦЕНКА КАЧЕСТВА
Когда основные этапы ЖЦ завершены и программное средство уже почти готово выйти на рынок (стать программным продуктом) или в эксплуатацию, производится проверка качества системы. Среди обилия стандартов, регулирующих оценку качества ПС, в настоящей статье рассмотрим наиболее часто применяемые стандарты. ГОСТ 28195-89 [31] - даже на сегодняшний день один из самых масштабных, проработанных и точных стандартов, который регламентирует оценку качества на всех этапах жизненного цикла ПС, данный стандарт имеет не только развитую иерархическую модель оценки качества (которую часто приводят как главное преимущество этого стандарта), но и множество рекомендуемых метрик. Обычно ГОСТ 28195-89 принято использовать
как отечественную альтернативу ИСО/МЭК 9126-93 [32]. Однако в настоящий момент более актуально предлагать его как альтернативу стандартам серии SQuaRE (ИСО/МЭК 25000 - ИСО/МЭК 25099), главным образом - ИСО/МЭК 2504п (где п - числа от 0 до 9), конкретнее - ГОСТ Р ИСО/МЭК 25040—2014 [33] -полный аналог ШО/ГЕС 25040:2011 [34]. Так как данный стандарт пришёл на замену ИСО/МЭК 9126 (несмотря на то, что он до сих пор действителен) и КОЛЕС 14598
[35], не просто объединяя их, а вводя новую модель и серию стандартов (которые в дальнейшем заменят всё, что осталось от серий ИСО/МЭК 9126 и ИСО/МЭК 14598) - SQuaRE, которая имеет не только богатую графическую интерпретацию, но и определённые уровни оценки и таблицу соотношения со стандартами ЖЦ (ИСО/МЭК 12207 и ИСО/МЭК 15288), что делает стандарт актуальным ещё на стадии формирования модели ЖЦ.
Следует отметить, что на одну и ту же область знания может приходиться несколько как международных, так и государственных стандартов, например, ГОСТ 28195 и ИСО/МЭК 9126. Они регламентируют оценку качества программных средств и систем, причем оба основываются на многоуровневой иерархической структуре, при этом ИСО/МЭК 9126 определяет 3 уровня, а ГОСТ 28195 - 4 уровня.
Однако среди различий между этими стандартами присутствует и то, которое определяет еще одну проблему в области стандартизации информационных технологий - характер стандартов, так, например, в ИСО/МЭК 9126 отсутствуют рекомендуемые варианты метрик и сами методы оценки качества представлены только в общем виде, в то время как в ГОСТ 28195 рекомендуемые метрики присутствуют, что позволяет разработчику ПС устанавливать уже заранее составленные метрики, их значения, а также применять более конкретные методы.
СЕРТИФИКАЦИЯ
Сертификация, которая проводится с целью получения от органа сертификации сертификата -документа, подтверждающего соответствие объекта сертификации предъявляемым к нему требованиями (Федеральный закон от 27 декабря 2002 г. N 184-ФЗ
[36]). Для получения сертификата необходимо обратиться в один из аттестованных Росстандартом органов по стандартизации или в одну из его лабораторий (однако лаборатория не может сама выдать сертификат, но может провести испытание и дать направление в соответствующий для получения сертификата орган). Важно отличать сертификацию от патентования, так как задачей сертификации является определение факта и степени соответствия создаваемого продукта нормативам, патентование должно установить то, насколько продукт является оригинальным и отличным от уже существующих продуктов (иногда даже стандартов и нормативов).
ЗАКЛЮЧЕНИЕ
Определение набора стандартов является одной из наиболее важных составляющих создания какой-либо системы, так как стандарты, во-первых, упрощают практически все процессы ЖЦ за счёт своей чёткости и структурированности, а, во-вторых, позволяют при их правильном выборе и применении обезопасить команду исполнителей, заказчика и сам продукт в нормативной сфере.
При выборе и применении стандартов важно чётко понимать их суть и уметь ориентироваться в существующих полных или частичных аналогах, уметь использовать их сбалансировано, чтобы одновременно иметь чёткую базу и план по всем этапам ЖЦ, но при этом не создавать переизбыток требований, которым нужно удовлетворять, и не создавать ситуацию противоречия стандартов друг другу.
Таким образом, выбирать профиль стандартов при разработке информационных систем нужно исходя из вида системы, требований и пожеланий заказчика, ограничений и особенностей разработки системы, а также нормативного регулирования.
БИБЛИОГРАФИЯ
[1] Холмогоров В.В., Баранюк В.В. Программная система входного профилирования абитуриентов -помощь при выборе будущей профессии / International Journal of Open Information Technologies. 2021. - Том 9. - №5. - с. 47-51.
[2] ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».
[3] ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению».
[4] ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
[5] ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению».
[6] ГОСТ Р ИСО/МЭК 9294-93 «Информационная технология. Руководство по управлению документированием программного обеспечения».
[7] ISO/IEC/IEEE 42010:2011 «Addresses the creation, analysis and sustainment of architectures of systems through the use of architecture descriptions».
[8] ГОСТ Р 57100-2016/IS0/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры».
[9] ISO/IEC 19505 «Information technology — Object Management Group Unified Modeling Language (OMG UML)».
[10] ISO/TR 9007:1987 «Concepts and terminology for the conceptual schema and the information base».
[11] ГОСТ 34.320-96 «Информационные технологии. Система стандартов по базам данных. Концепции и
терминология для концептуальной схемы и информационной базы».
[12] ISO/IEC 10032:1995 «Information technology -Reference model of data management».
[13] ГОСТ 34.321-96. «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными».
[14] А.А. Бодалева, В.В Столина, А.Г. Шмелева (МГУ), В.И. Похилько (I ММИ), А.А. Кроника (ИПАН). «Нормативные предписания к разработчикам и пользователям психодиагностических методик», URL:
http://www.voppsy.ru/issues/1987/875/875176.htm (дата обращения: 28.08.2021).
[15] IEEE 1008 «Software Unit Testing».
[16] ISO/IEC/IEEE 29119-1:2013, Part 1: Concepts and definitions, published in September 2013.
[17] ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 «Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения».
[18] ISO/IEC/IEEE 29119-2:2013, Part 2: Test processes.
[19] ГОСТ Р 56921 -2016/ISO/IEC/IEEE 29119-2:2013 «Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования».
[20] ISO/IEC/IEEE 29119-3:2013, Part 3: Test documentation.
[21] ГОСТ Р 56922-2016/ «Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования».
[22] ISO/IEC/IEEE 29119-4:2015, Part 4: Test techniques.
[23] ISO/IEC/IEEE 29119-5:2016, Part 5: Keyword-driven testing.
[24] BS 7925-1 Vocabulary of terms in software testing.
[25] IEEE 829-2008 - IEEE Standard for Software and System Test Documentation.
[26] ISO/IEC 25051:2014 «Software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing», IDT.
[27] ГОСТ Р ИСО/МЭК 25051-2017 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию».
[28] ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».
[29] ГОСТ 19.105-78 «Общие требования к программным документам».
[30] ГОСТ Р ИСО/МЭК 9294-93 «Информационная технология. Руководство по управлению документированием программного обеспечения».
[31] ГОСТ 28195-89 «Оценка качества программных средств. Общие положения».
[32] ИСО/МЭК 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению».
[33] ГОСТ Р ИСО/МЭК 25040—2014 «Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки».
[34] ISO/IEC 25040:2011 «Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation process».
[35] ISO/IEC 14598-3:2000 «Software engineering — Product evaluation — Part 3: Process for developers».
[36] Федеральный закон от 27 декабря 2002 г. N 184-ФЗ О техническом регулировании.
[37] Информационные технологии в экономике и управлении в 2 ч. Часть 2 : учебник для среднего профессионального образования / В. В. Трофимов [и др.]; под редакцией В. В. Трофимова. — 3-е изд., перераб. и доп. — Москва: Издательство Юрайт, 2018. — 245 с. — (Профессиональное образование). — ISBN 978-5-534-09139-7.
Selection of standards in accordance with the stages of the life cycle of information systems
V.V. Kholmogorov, V.V. Baranyuk
Abstract - Defining a set of standards is one of the most important components of creating an information system, since standards, firstly, simplify almost all life cycle processes due to their clarity and structure, and, secondly, allow, if they are properly selected and applied, to secure the team of performers, the customer and the product itself in the regulatory sphere.
The structure of any modern information system, as a rule, includes a software tool, which, upon completion of all work, becomes a software product. The creation of a software product is a time-consuming process that is often delayed or even stopped for various reasons, which are usually associated with poor quality of work, exceeding time limits or misunderstanding between the contractor and the customer. Generally, such problems arise due to the fact that the execution team cannot correctly determine the product implementation model at the stages of its life cycle from requirements generation to testing and documentation.
Standards often act as instructions for stakeholders. However, choosing standards that are inappropriate for a particular product can complicate the task of implementing it instead of simplifying it, so it is important to be able to choose the most appropriate standards at all stages of the product life cycle.
This article demonstrates a possible course of analysis and selection of standards at all stages of the life cycle using the example of a software system for the entrance profiling of enrollees.
Key words - set of standards, state and international standards, life cycle, software system for entrance profiling of enrollees.
References
[1] V.V. Kholmogorov, V.V. Baranyuk. Program system for entrance profiling of applicants - help in choosing a future profession / International Journal of Open Information Technologies. 2021. - Volume 9. - No. 5. -With. 47-51.
[2] GOST R ISO/IEC 12207-2010 "Information technology. System and software engineering. Software Life Cycle Processes".
[3] GOST 19.201-78 "Unified system of program documentation. Technical task. Requirements for content and design.
[4] GOST 34.602-89 "Information technology. Set of standards for automated systems. Terms of reference for the creation of an automated system.
[5] GOST 19.201-78 "Unified system of program documentation. Technical task. Requirements for content and design.
[6] GOST R ISO/IEC 9294-93 "Information technology. Software Documentation Management Guide.
[7] ISO/IEC/IEEE 42010:2011 "Addresses the creation, analysis and sustainment of architectures of systems through the use of architecture descriptions".
[8] GOST R 57100-2016/ISO/IEC/IEEE 42010:2011 "System and software engineering. Description of architecture.
[9] ISO/IEC 19505 "Information technology - Object Management Group Unified Modeling Language (OMG UML)".
[10] ISO/TR 9007:1987 "Concepts and terminology for the conceptual schema and the information base".
[11] GOST 34.320-96 "Information technologies. Database standards system. Concepts and terminology for the conceptual scheme and information base.
[12] ISO/IEC 10032:1995 "Information technology -Reference model of data management".
[13] GOST 34.321-96. "Information Technology. Database standards system. Reference Model for Data Management.
[14] A.A. Bodaleva, V.V. Stolin, A.G. Shmeleva (Moscow State University), V.I. Pokhilko (I MMI), A.A. Kronika (IPAN). "Regulatory instructions for developers and users of psychodiagnostic methods", URL: http://www.voppsy.ru/issues/1987/875/875176.htm (date of access: 28.08.2021).
[15] IEEE 1008 Software Unit Testing.
[16] ISO/IEC/IEEE 29119-1:2013, Part 1: Concepts and definitions, published in September 2013.
[17] GOST R 56920-2016/ISO/IEC/IEEE 29119-1:2013 "System and software engineering. Software testing. Part 1. Concepts and definitions.
[18] ISO/IEC/IEEE 29119-2:2013, Part 2: Test processes.
[19] GOST R 56921-2016/ISO/IEC/IEEE 29119-2:2013 "System and software engineering. Software testing. Part 2. Testing processes.
[20] ISO/IEC/IEEE 29119-3:2013, Part 3: Test documentation.
[21] GOST R 56922-2016/ "System and software engineering. Software testing. Part 3. Testing Documentation.
[22] ISO/IEC/IEEE 29119-4:2015, Part 4: Test techniques.
[23] ISO/IEC/IEEE 29119-5:2016, Part 5: Keyword-driven testing.
[24] BS 7925-1 Vocabulary of terms in software testing.
[25] IEEE 829-2008 - IEEE Standard for Software and System Test Documentation.
[26] ISO/IEC 25051:2014 "Software engineering -Systems and software Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing", IDT.
[27] GOST R ISO/IEC 25051-2017 "System and software engineering. Requirements and quality assessment of systems and software (SQuaRE). Quality Requirements for a Ready-to-Use Software Product (RUSP) and Testing Instructions.
[28] GOST 34.201-89 "Types, completeness and designation of documents when creating automated systems".
[29] GOST 19.105-78 "General requirements for program documents".
[30] GOST R ISO/IEC 9294-93 "Information technology. Software Documentation Management Guide.
[31] GOST 28195-89 "Assessment of the quality of software. General Provisions".
[32] ISO/IEC 9126-93 Information technology. Evaluation of software products. Quality characteristics and guidelines for their application.
[33] GOST R ISO/IEC 25040-2014 "Information technology (IT). System and software engineering. Requirements and quality assessment of systems and software (SQuaRE). Evaluation Process".
[34] ISO/IEC 25040:2011 "Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation process".
[35] ISO/IEC 14598-3:2000 "Software engineering -Product evaluation - Part 3: Process for developers".
[36] Federal Law No. 184-FZ of December 27, 2002 On Technical Regulation.
[37] Information technologies in economics and management in 2 hours. Part 2: a textbook for secondary vocational education / VV Trofimov [and others]; edited by V. V. Trofimov. - 3rd ed., revised. and additional - Moscow: Yurayt Publishing House, 2018. - 245 p. - (Professional education). - ISBN 978-5-534-09139-7.
