Кто определяет стандарты в индустрии программного обеспечения для пк

Обновлено: 28.06.2024

ГОСТ Р ИСО/МЭК 25051-2017

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системная и программная инженерия

ТРЕБОВАНИЯ И ОЦЕНКА КАЧЕСТВА СИСТЕМ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (SQuaRE)

Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию

Information technologies. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25051:2014* "Системная и программная инженерия. Оценка и требования к качеству программного обеспечения и систем (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию" (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).

________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.

ИСО/МЭК 25051 разработан подкомитетом ПК 7 "Системная и программная инженерия" совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Январь 2019 г.

7 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Введение

Второе издание ИСО/МЭК 25051 прекращает действие и заменяет первое издание ИСО/МЭК 25051:2006, которое было технически пересмотрено. Это издание также включает в себя Техническую поправку ИСО/МЭК 25051:2006/Кор.1:2007.

Основные изменения заключаются в следующем:

- исправлены заголовки на английском и французском языках;

- внесены изменения в определение готового к использованию программного продукта (RUSP), область его применения и соответствующие примеры;

- достигнута гармонизация с текущей серией стандартов SQuaRE.

ИСО/МЭК 25051 является составной частью серии международных стандартов SQuaRE, которая состоит из следующих разделов:

- Управление качеством (ИСО/МЭК 2500n);

- Модель качества (ИСО/МЭК 2501n);

- Измерение качества ИСО/МЭК 2502n);

- Требования к качеству (ИСО/МЭК 2503n);

- Оценка качества (ИСО/МЭК 2504n);

- Расширения (ИСО/МЭК 25050 - ИСО/МЭК 25099).

Область применения RUSP непрерывно расширяется, и их правильная эксплуатация имеет большое значение для ведения бизнеса, обеспечения безопасности и удовлетворения личных потребностей.

RUSP представляет собой пакеты программного обеспечения, получаемые приобретающей стороной, которая не имеет возможность влиять на их функции и качества. Как правило, программное обеспечение продается в виде пакета либо может быть загружено через интернет вместе с документацией пользователя. RUSP может также считаться программный продукт*, с которым пользователь может работать в любое время посредством облачных вычислений. Информация, указанная на упаковке или представленная на интернет-сайте поставщика, зачастую является единственным инструментом, с помощью которого поставщик или маркетинговая организация может взаимодействовать с приобретателем или пользователем. Поэтому особенно важно предоставлять информацию, дающую возможность приобретающей стороне оценить качественные характеристики готового к использованию программного продукта с учетом их потребностей.

* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.

Выбор готового к использованию программного продукта высокого качества имеет большое значение, поскольку к RUST может предъявляться требование о возможности его использования в разных средах. Кроме того, может отсутствовать возможность сравнения данного продукта с другими схожими продуктами. Поставщикам необходимо убедиться в возможности использования функций RUSP пользователями. Некоторые поставщики могут предпочесть, чтобы оценка или сертификация таких функций проводилась группой оценки соответствия.

Кроме того, если пользователям необходима уверенность в отношении бизнес-процессов или критически важных рисков безопасности, то они для этой цели могут использовать методы, выбор которых производится уже после покупки. В настоящем стандарте не рассматриваются минимальные требования к безопасности или качеству RUSP, критические для ведения бизнеса, однако даются ссылки на соответствующую информацию (см. приложение А).

ИСО/МЭК 25051:2006 разработан на основе ИСО/МЭК 9126-1:2001 и заменяет ИСО/МЭК 12119:1994. Второе издание ИСО/МЭК 25051 представляет собой версию ИСО/МЭК 25051:2006, пересмотренную с целью соответствия ИСО/МЭК 25010:2011, который заменил модель качества ИСО/МЭК 9126-1:2001.

Указанные выше документы представляют собой основу для второй редакции стандарта, содержащей набор требований к готовому к использованию программному продукту и требования к тестированию RUSP на предмет соответствия.

1 Область применения

Настоящий стандарт применяется к готовому к использованию программному продукту (RUSP). Сокращение "RUSP" в настоящем стандарте используется как определение, означающее "готовый к использованию программный продукт".

1 Ниже приводится неисчерпывающий список примеров RUSP: текстовые процессоры, таблицы, ПО для управления базами данных, графические пакеты, ПО для работы с встроенными техническими, научными или интерактивными функциями, ПО для управления персоналом, продажами, приложения для смартфонов, бесплатное ПО и веб-приложения, такие как программы для создания веб-сайтов и (или) веб-страниц.

2 Программное обеспечение с открытым исходным кодом не относится к RUSP.

Настоящий стандарт устанавливает:

a) требования к RUSP;

b) требования к документации по тестированию RUSP, включая план тестирования, описание тестов и их результатов.

Примечание - Набор документов для тестирования называется документацией по тестированию;

c) инструкции по оценке соответствия RUSP.

В стандарт также входят рекомендации в отношении RUSP, критически важные для безопасности и ведения бизнеса.

Настоящий стандарт предназначен исключительно для того, чтобы обеспечить пользователям уверенность в соответствии предлагаемых свойств RUSP их требованиям. Стандарт не относится к реализации продукции (включая мероприятия по продаже и промежуточные продукты, например спецификации). Система обеспечения качества поставщика не входит в область применения настоящего стандарта.

Целевая аудитория настоящего стандарта включает:

a) поставщиков, которые:

1) определяют требования к RUSP;

2) оценивают собственные программные продукты на предмет соответствия заявленным характеристикам;

3) выпускают декларации соответствия (см. ИСО/МЭК 17050);

4) обращаются за сертификатами или знаками соответствия (см. Руководство 23 ИСО/МЭК);

b) сертифицирующие органы, которые могут устанавливать схемы сертификации (международные, региональные или национальные) (см. Руководство 28 ИСО/МЭК);

c) испытательные лаборатории, которые должны следовать соответствующим инструкциям в ходе тестирований для выдачи сертификата или знака соответствия (см. ИСО/МЭК 17025);

d) организации для аккредитации регистрирующих или сертифицирующих органов и лабораторий тестирования;

e) потенциальных приобретателей, которые могут:

1) сравнивать требования к запланированным рабочим задачам с информацией, содержащейся в описаниях существующих программных продуктов;

2) осуществлять поиск сертифицированного RUSP;

3) проверять соответствие требованиям иными способами;

f) конечных пользователей, которые могут извлекать преимущества из программных продуктов более высокого качества;

1) при создании сред управления и технического оснащения на базе требований к качеству и методов, изложенных в настоящем стандарте;

2) при управлении и совершенствовании собственных процессов по обеспечению качества "и управления персоналом";

h) регулирующие органы, которые могут требовать соблюдения или рекомендовать соблюдение требований настоящего стандарта в отношении RUSP, используемого для критически важных приложений, обеспечивающих безопасность или ведение бизнеса.

2 Соответствие требованиям

RUSP соответствует настоящему стандарту, если:

a) обладает свойствами, приведенными в разделе 5;

b) протестирован в соответствии с документацией по производственному тестированию, которая соответствует требованиям раздела 6;

c) выявленные в ходе тестирования несоответствия документируются и устраняются до момента выпуска продукта. Несоответствия, связанные с заявленными функциями, должны быть либо устранены, либо необходимо прекратить рекламирование таких функций. Известные несоответствия могут быть признаны приемлемыми, если:

1) не нарушают заявленный уровень качества;

2) поставщик должным образом исследовал характер и влияние несоответствия на потенциального приобретателя и признал его незначительным, а также сохранил документацию по выявленным несоответствиям для их устранения в будущем.

Раздел 7 и приложение А носят справочный характер.

Примечание - Чтобы облегчить оценку соответствия, требования настоящего стандарта должны иметь структуру, отвечающую трем условиям (с нумерацией в формате Х.Х.Х.Х). Справочные примечания дополняют эти условия и выступают в качестве инструкций.

3 Нормативные ссылки

Нормативные документы*, полностью или частично упомянутые в настоящем стандарте, обязательны для их применения. Для датированных документов используют только указанные издания. Для недатированных документов используют самые последние издания (с учетом всех изменений).

ISO/IEC 25000 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE (Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Руководство по SQuaRE)

ISO/IEC 25010 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения)

Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

Если коротко, то основные этапы разработки требований — это:

Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.

Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.

В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.

Так что же такое требования и почему важно уметь их разрабатывать?

Итак, обратимся к истокам:

То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

1. Зачем?

Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.

Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.

Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.

Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.

Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.

Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.

Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.

Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.

И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.

2. Что?

Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.

Чтобы сократить процесс согласования счетов, мы можем:

А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.

Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.

В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.

Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.

У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.

3. Как?

Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.

Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.

Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов — это бизнес-требование. А возможно, и бизнес-правило.
Из бизнес-требования следует, что у пользователя должна быть возможность прикрепить фото к анкете — это пользовательское требование. То есть требование, описывающее действия пользователя.
Получается, что система должна иметь функционал прикрепления фото к анкете — это уже функциональное требование, описывающее поведение системы. Или как должна работать система, чтобы выполнять исходное пользовательское требование.
Будем хранить все фото в формате base64 в отдельной таблице в БД. Это — нефункциональные требования.
Фото в очень хорошем качестве нам не нужно, а также мы не хотим покупать много памяти для сервера. Поэтому сделаем ограничение на размер загружаемого фото: не более 10Мб.

На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.

Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.

4. Когда?

В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.

Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.

В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).

А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.

Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.

Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.

Понятие

Любой современный ПК — настольный, портативный или серверный, наполняется по схожему принципу. Если убрать лишнее, то любое ПО, даже простейшее, строится по похожему алгоритму. Должны выполняться пошаговые действия — следующий шаг начинается только после того, как завершился предыдущий.

Так, введенные с клавиатуры символы отображаются на экране, по командному клику пользователя принтер начинает печатать их на бумаге, а расчеты происходят сами после введения формулы. Любой шаг заранее программируется и называется командой для компьютера, совокупность этапов обозначается программируемым кодом.

Программисты — это люди, которые разрабатывают и настраивают ПО. Они могут управлять ПК с помощью одной строчки, в которую вводят части закодированной информации. Несколько символов в определенной последовательности включают музыку, отправляют документ на печать или открывают конкретную страницу интернет-ресурса.

Оборудование

Какие бывают типы программного обеспечения: характеристика программ

В современных компьютерах постоянно запускается и активно функционирует большое количество ПО с самым разным функционалом. Одни занимаются арифметическими расчетами, другие строят диаграммы, рисуют или помогают оставаться на линии с собеседниками через почту.

Однако ничего не активизируется просто так. Все действует под влиянием операционной системы. Кажется, что ОС совершенно не нужна — можно ведь запускать все напрямую. Иногда этот метод тоже применяется. Так работают станки ЧПУ, крупные автоматы производств, ЭВМ, другие серьезные механизмы, когда нужно постоянно повторять один и тот же алгоритм.

Но для персонального компьютера частое повторение команды не подходит. Пользователю хочется знать, какая погода в другом городе, как включить музыку и открыть текстовый документ для редактирования. Необходимо, чтобы ОС поддерживала режим многозадачности.

Со стороны программистов типы ПО обоснованы практической значимостью. Если бы не было операционной системы, пришлось бы все функции и алгоритмы вносить в один огромный код. Затраты времени на это были бы колоссальными.

ОС берет на себя большую часть рутинных задач, давая пользователям возможность работать в режиме многозадачности. Поэтому становится возможным запускать одновременно от 2 до бесконечности редакторов или визуализаторов.

Какие основные виды ПО бывают по назначению

Программное обеспечение, установленное на ПК, делится на 3 разновидности:

прикладное;
системное;
инструментальное.

Системное

Это часть системы, которая помогает следить за аппаратной стороной ПК и управлять ею. Сюда входят программы, контролирующие работу оперативной памяти, центрального процессора, видеокарты, устройств ввода и вывода информации, сетевые подпрограммы.

Таким ПО считается:

Драйверы — утилиты небольшого размера, функционирование которых заключается в обеспечении корректной работы остальных элементов оборудования;
ОС;
Дополнения — языковые пакеты или настройки расширения экрана.

Прикладное

Наиболее обширная доля классификации. Сюда относятся графические и текстовые редакторы, браузеры, базы данных и все, что люди используют в привычной работе за компьютером. Здесь же находятся антивирусные пакеты, бухгалтерия и различные архивы.

Смысл этой разновидности в выполнении четко поставленной задачи: рисовать, учитывать, открывать сетевые страницы, набирать текст. Если утилита нужна для конкретного выполнения действия, то она является прикладным ПО.

Инструментальное

Специфическое обеспечение любой компьютерной техники. Его можно было бы отнести к прикладному, но из-за специфики применения его выделили в отдельный вид. Основная функция — отладка, настройка, переписывание программного кода.

Постоянно пользоваться этим кодом базовым пользователям довольно сложно, поэтому были разработаны системы, которые позволяют переводить обычную речь в двоичную, привычную для ПК.

Разница между часто используемыми компиляторами и интерпретаторами заключается в том, что первый генерирует готовый файл, который можно запускать. А второй создает архив, который функционирует только с помощью самого сервиса.