Что содержит техническая документация на разработку программных средств
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ
Общие требования к разработке и документированию
Embedded system software.
General requirements for development and documentation
Дата введения 2003-07-01
1 РАЗРАБОТАН Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации
ВНЕСЕН Научно-исследовательским институтом стандартизации и унификации
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 июня 2002 г. N 247-ст
3 Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени
5 ПЕРЕИЗДАНИЕ. Октябрь 2005 г.
1 Область применения
Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения.
Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт неприменим для аппаратных элементов программно-аппаратного обеспечения.
2 Нормативные ссылки
В настоящем стандарте использована ссылка на следующий стандарт:
3 Определения и сокращения
В настоящем стандарте применяют термины с соответствующими определениями по ГОСТ Р ИСО/МЭК 12207, а также приведенные ниже:
3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий для выполнения конкретной задачи.
3.2 анализ полноты покрытия: Определения степени, до которой работы процесса верификации ПО удовлетворяют поставленной цели.
3.3 аномальное поведение: Поведение, которое не соответствует заданным требованиям.
3.4 аппаратные средства: Материальная часть вычислительной системы, включающая в себя электрические и электронные элементы (например, приборы и схемы), электромеханические элементы (например, дисководы) и механические элементы (например, стойки).
3.5 архитектура: Организационная структура системы или ЭКПО, в которой идентифицированы компоненты, их интерфейсы и концепция взаимодействия между ними.
3.6 аттестация инструментальных средств: Процесс получения сертификационного доверия к программному инструментальному средству применительно к конкретной встроенной системе.
3.7 база данных: Совокупность взаимосвязанных данных, сохраненных в одном или более компьютерных файлах в виде, позволяющем обращаться к ним пользователям или компьютерным программам с помощью системы управления базой данных.
3.8 библиотека разработки ПО: Контролируемая совокупность документов, промежуточных и конечных программных продуктов, а также инструментальных средств и процедур, используемых для управления текущей разработкой и последующей поддержкой ПО.
3.9 верификация: Оценка результатов процесса с целью гарантии корректности и непротиворечивости в отношении входов и стандартов, существующих для данного процесса.
3.10 заплата: Исправление, вносимое непосредственно в объектную программу, а не в текст, на языке программирования.
3.11 изменение ПО: Модификация исходного кода, исполняемого объектного кода или сопутствующих документов относительно их базовой линии.
3.12 имитатор: Устройство, компьютерная программа или система, используемая при верификации ПО, которая принимает те же входные данные и производит те же выходные данные, что и объектная система.
3.13 интегральный процесс: Процесс разработки ПО, который остается активным на протяжении жизненного цикла ПО.
3.14 интеграция аппаратуры и ПО: Процесс объединения ПО с объектным компьютером.
3.15 интеграция ПО: Процесс объединения компонентов кода.
3.16 интерфейс: Взаимосвязь между двумя или более объектами (типа ЭКПО/ЭКПО, ЭКПО/ЭКА, ЭКПО/пользователь или между модулями ПО), которые совместно используют и обеспечивают данные или обмениваются ими.
3.17 инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
3.18 инструментальный компьютер: Компьютер, на котором разрабатывают ПО.
3.19 исходный код: Код, написанный на исходном языке программирования, таком как язык ассемблера и/или язык высокого уровня, в машинно-читаемой форме, пригодной для ввода в ассемблер или компилятор.
3.20 квалификационное тестирование: Тестирование, выполняемое с целью убедить заказчика, что ПО соответствует заданным требованиям.
3.21 класс эквивалентности: Такое разбиение входной области программы, при котором тестирование для представительного значения класса эквивалентно тестированию для любого другого значения из этого класса.
3.22 код: Реализация конкретных данных или конкретной компьютерной программы в символьной форме, такой, например, как исходный код, объектный код или машинный код.
3.23 коммерчески доступное ПО: Коммерчески доступное программное средство, продаваемое производителем по официальным каталогам. Коммерчески доступное ПО не предназначено для переделки или усовершенствования. ПО, разработанное по специальным контрактам для специализированных приложений, не является коммерчески доступным ПО.
3.24 компонент: Замкнутая часть, комбинация частей или элемент, которые выполняют в системе отдельную функцию.
3.25 контракт: Соглашение о разработке ПО, установленное между заказчиком и разработчиком.
3.26 критерии перехода: Минимальные условия, определенные процессом планирования ПО, которые должны быть выполнены для входа в процесс.
3.27 мертвый код: Исполняемый объектный код (или данные), который в результате ошибки проектирования не может быть выполнен (код) или использован (данные) в функциональной конфигурации среды объектного компьютера и не может быть прослежен в системных или программных требованиях. Исключение составляют встроенные идентификаторы.
3.28 многоверсионное неидентичное ПО: Множество из двух или более программ, разработанных отдельно по одним и тем же функциональным требованиям. Ошибки одной версии обнаруживают путем сравнения выходных результатов разных программ.
3.29 модифицированное покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз, и для каждого условия в решении должно быть показано его независимое влияние на результат решения. Независимость влияния условия на результат решения демонстрируют путем рассмотрения всех возможных комбинаций условий.
3.30 непоставляемое программное средство: Программное средство, которое в соответствии с контрактом не требуется поставлять заказчику или другому обозначенному получателю.
3.31 объектный код: Представление компьютерной программы на низком уровне, обычно не в форме, непосредственно пригодной для объектного компьютера, а в форме, включающей в себя, помимо информации о процессорных командах, информацию о размещении программы.
3.32 объектный компьютер: Компьютер, на котором эксплуатируют ПО.
3.33 отказоустойчивость: Свойство системы продолжать правильное выполнение функций при наличии ограниченного числа аппаратных или программных дефектов.
3.34 отключенный код: Исполняемый объектный код (или данные), который согласно проекту предназначен для выполнения (код) или использования (данные) только при определенных условиях.
3.35 оценка безопасности системы: Систематическая, всесторонняя оценка предлагаемой системы с целью показать, что она удовлетворяет требованиям, предъявленным к обеспечению безопасности.
3.36 ошибка: Неправильность в требованиях, проекте или коде.
3.37 передача ПО: Последовательность действий, определяющих ответственность за передачу разработанного ПО организацией, имеющей право на эти действия (обычно организацией, которая выполняет разработку ПО), в организацию, осуществляющую поддержку ПО.
3.38 перепроектирование: Процесс исследования и изменения существующей системы для преобразования ее в новую форму.
3.39 поддержка ПО: Набор действий, гарантирующий, что установленное для эксплуатационного использования ПО продолжает выполнять все функции в соответствии с предназначением системы. Поддержка ПО включает в себя сопровождение ПО, помощь пользователям и связанные с этим действия.
3.40 покрытие операторов: Такое выполнение программы при тестировании, при котором каждый оператор в программе должен быть выполнен хотя бы один раз.
3.41 покрытие решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении должно быть выполнено с каждым возможным результатом хотя бы один раз.
3.42 покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз.
3.43 поставляемое программное средство: Программное средство, требуемое по контракту, которое будет поставлено заказчику или другому обозначенному получателю.
3.44 построение: Версия ПО, отвечающая определенному подмножеству требований, которые должны быть обеспечены в конечном ПО.
3.45 прерывание: Приостановка задачи, например выполнения компьютерной программы, вызванная событием, внешним для этой задачи. Прерывание позволяет обработать возникшее событие и вернуться к прерванной задаче.
3.46 программная система: Система, состоящая из ПО и, возможно, компьютерного оборудования для его выполнения.
3.47 программное обеспечение (ПО): Совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ.
3.48 программное средство: ПО и связанные с ним документы, вновь созданные, модифицированные или сгруппированные для удовлетворения требованиям контракта.
3.49 программное средство многократного использования: Программное средство, разработанное для конкретного применения, но с возможностью другого применения, или разработанное специально для многократного использования в различных проектах или для многофункционального использования в одном проекте.
3.50 производные требования: Дополнительные требования, появившиеся в результате выполнения процессов разработки ПО, которые не являются непосредственно связанными с требованиями верхнего уровня.
3.51 процедура тестирования: Детальные инструкции для того, чтобы генерировать и выполнить множество тестовых наборов и оценить результаты их выполнения.
3.52 разработка ПО: Набор действий, результатом выполнения которых являются программные средства. Разработка ПО может включать в себя новую разработку, модификацию, многократное использование, перепроектирование или любое другое действие, требуемое для создания программных средств.
3.54 связность по данным: Зависимость программного компонента от данных, которые используются не только исключительно в этом компоненте.
3.55 связность по управлению: Степень влияния одного программного компонента на выполнение другого программного компонента.
3.56 сертификационное доверие: Принятие сертифицирующей организацией того факта, что процесс или средство удовлетворяет сертификационным требованиям.
3.57 система: Набор аппаратных и программных компонентов, созданный для выполнения определенной функции или множества функций.
3.58 словарь данных: Детальное описание данных, параметров, переменных и констант, используемых в системе.
3.59 совместный просмотр: Совещание с участием представителей и заказчика и разработчика, в процессе которого проверяют и обсуждают состояние проекта, программные средства и/или проблемы проекта.
3.60 соискатель: Человек или организация, претендующая на получение утверждения от сертифицирующей организации.
3.61 соисполнитель разработки: Организация, которая не является ни главным подрядчиком, ни субподрядчиком данной разработки, но которая принимает участие в разработке системы или проекта.
3.62 среда разработки ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для разработки ПО.
3.63 среда верификации/тестирования ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для выполнения верификации/тестирования ПО. Элементами данной среды могут являться имитаторы, статические анализаторы, генераторы тестовых данных, анализаторы путей и т.п., а также элементы, используемые в среде разработки ПО.
Техническая документация в разработке ПО: кто, зачем, когда и как описывает проект
Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.
Общаясь с большим количеством компаний, я все еще встречаю твердое убеждение в том, что написание технического задания для разработки ПО — пустая трата времени и денег. Мы в 65apps считаем иначе. Поэтому приведу несколько аргументов в пользу технической документации и расскажу, кто и как ее пишет.
Техническая документация позволяет оценить стоимость разработки и согласовать функциональность будущей системы. При возникновении споров о стоимости и сроках разработки той или иной фичи она может стать определенной гарантией для заказчика. С другой стороны, если возникнет потребность в развитии приложения, документация облегчит процесс доработки и даст четкое понимание, возможно ли встроить новую функциональность в существующую систему.
Другой пример — государственные организации или организации, чья деятельность ограничивается или подчиняется законам и надзорным органам. Они обязаны осуществлять разработку ПО по всем правилам и с соблюдением всех стандартов. В таких проектах техническая документация, подготовленная по ГОСТам, — необходимое условие.
И разумеется, грамотно составленная и актуальная документация необходима для того, чтобы каждый участник в процессе разработки мог обращаться к документам, если возникают вопросы по конкретной задаче или по всей системе в целом.
Техническое задание и технический проект — два разных документа. Техническое задание отвечает на вопрос «что нужно сделать?», его составляет аналитик в самом начале проекта. Технический проект разрабатывает технический писатель. Этот документ создается после ТЗ и отвечает на вопрос «как нужно делать?».
Кто пишет техническую документацию
Обычно разработкой ТЗ занимается аналитик. Именно он общается с заказчиком / заинтересованным лицом и выявляет у него требования. В сложных случаях к процессу можно привлечь менеджера проекта, разработчиков, тестировщиков и других специалистов. Чем сложнее проект — тем больше требований к документации. Серьезные заказчики из крупных корпораций и госсектора требуют составлять документацию в соответствии с ГОСТами, а это задача очень трудоемкая, требующая внимательности к деталям и постоянной вовлеченности в процесс. И это не только ТЗ, но и технический проект, полностью описывающий все используемые в разработке решения, подходы и методологии. На него также распространяются ГОСТы. Подготовкой такой документации должен заниматься специалист — технический писатель.
Для крупных проектов иметь в штате технического писателя просто необходимо. Разработка решений для крупных заказчиков может длиться год и более, это довольно долгий срок. За это время возникает достаточное количество изменений, провоцирующих обновление документации. Кроме того, любая долгосрочная разработка ПО предполагает развитие. В этом случае актуальная техническая документация позволит снизить риски, закладываемые в работу исполнителей.
Исключение может быть сделано для представителей госсектора. Таким организациям необязательно иметь в своем штате специалистов соответствующего профиля, так как при возникновении необходимости всегда можно обратиться к профессионалам, которые выполнят качественно свою работу.
Кто такой технический писатель
Строго сформулированного перечня должностных обязанностей технического писателя не существует: каждая компания формирует его сама, а иногда возлагает на такого специалиста и дополнительные задачи. Поэтому иногда бывает сложно даже определить род деятельности технического писателя. В нашей компании такой специалист составляет документацию, необходимую для дальнейшей разработки программного обеспечения.
Для этого он собирает информацию и материалы от участников проекта и документирует эти данные согласно требованиям заказчика, в том числе и в соответствии с ГОСТами. Речь идет о ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы». Также технический писатель следит за актуальностью технической информации, если это необходимо на длительных и сложных проектах.
Какая техническая документация нужна разработчику
Рассмотрим идеальный с точки зрения ГОСТа процесс разработки системы.
Все начинается с требований заказчика или заинтересованных лиц, которые необходимо выявить и обязательно зафиксировать в документе «Техническое задание».
Техническое задание — это документ, регламентирующий бизнес-цели, общее описание системы, объем работ, границы проекта, а также порядок разработки, оценки и приемки. Данный документ отвечает нам на вопрос «что нужно сделать?» и фактически является постановкой задачи.
Аналитик составляет ТЗ и согласует его со всеми заинтересованными сторонами. После того как собраны и утверждены все требования, можно приступать к созданию прототипов будущей системы и разработке программного обеспечения.
На этом этапе начинается разработка макетов, сценариев, архитектуры и др. Раз уж мы говорим об эталонном процессе разработки, то все это должно быть описано в техническом проекте, который также использует часть информации из ТЗ.
Технический проект — это совокупность документов, описывающих и обосновывающих все подходы, методы, архитектурные и технические решения, применяемые для создания системы. Например, в технический проект включают макеты интерфейсов, описание протоколов для интеграции со смежными системами и оборудованием, пользовательские сценарии, описание алгоритма и их формирование, структура серверов и баз данных, а также другие требования к системе и ее взаимодействию с другими внешними системами.
это далеко не все: существует много стандартов для написания технической документации, и для каждой страны они свои. В отечественных стандартах есть отдельно ГОСТ на создание автоматизированных работ и на программное изделие. Например, технический проект по ГОСТу 19 «Единая система программной документации» может включать в себя следующий перечень работ:
Теперь, когда есть четкое понимание архитектуры, функциональности и дизайна проекта, можно перейти к разработке системы и ее тестированию.
На этапе тестирования, помимо проверки работоспособности системы, проверяется также выполнение всех требований, зафиксированных в документах, что позволяет разрешить спорные ситуации с заказчиком.
Когда составлять техническую документацию
Выше я описала идеальный процесс создания программного обеспечения, но иногда некоторые документы технического проекта составляют уже после этапа разработки.
Есть проекты, в которых важно иметь полную документацию до начала работ. Это касается решений с высокими требованиями к безопасности, соблюдению законодательства и т. д. Например, мобильные приложения для банков. В этом случае важно сначала продумать все детали системы (информационная безопасность клиентов и самого банка, соответствие законам). На это уйдет больше времени, но позволит избежать финансовых и репутационных рисков.
Если разработка идет по методологии Agile, то нет смысла прописывать всю документацию до старта работ. Если заказчику важно работать по спринтам и контролировать ход разработки, документацию можно дописывать параллельно основному процессу.
В нашей компании возможны оба варианта — мы умеем адаптироваться под условия и пожелания заказчика.
На сегодняшний день технический писатель не самая распространенная специальность, но для серьезной компании-разработчика такой сотрудник не менее важен, чем, например, аналитик.
Техническая документация обязательно разрабатывается для госзаказчиков, она необходима и для долгосрочных проектов, на которых с бОльшей вероятностью могут меняться подрядчики. Имеет смысл создавать технический проект для ноу-хау технологий и проектов высокой сложности — документация понадобится отделу QA, чтобы отличить баги и фич.
Что содержит техническая документация на разработку программных средств
ГОСТ Р ИСО/МЭК 90003-2014
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РАЗРАБОТКА ПРОГРАММНЫХ ПРОДУКТОВ
Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов
Software engineering. Guidelines for the application of ISO 9001:2008 to computer software
Дата введения 2016-01-01
Предисловие
1 ПОДГОТОВЛЕН Открытым акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (ОАО «ВНИИС») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 076 «Системы менеджмента»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов, приведенных в библиографии, соответствующие им национальные и межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА
6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.
Введение
Настоящий стандарт является руководящим указанием для организаций по применению ИСО 9001:2008 к процессам, связанным с заказом, поставкой, разработкой, эксплуатацией и сопровождением программных продуктов.
Настоящий стандарт определяет вопросы, которые нужно рассматривать, и его применимость не зависит от технологий, моделей жизненного цикла, процессов в области разработки, последовательности действий и организационной структуры, которые используются организацией. Предлагаемые руководящие указания и определенные к рассмотрению вопросы предполагают обстоятельный и многосторонний, но не исчерпывающий охват изучаемого предмета. В случае когда область деятельности организации охватывает области, отличные от разработки программных продуктов, взаимосвязь между элементами системы менеджмента качества организации, имеющими отношение к программным продуктам, и остальными аспектами необходимо четко документировать в рамках системы менеджмента качества в как итоговую совокупность.
Разделы 4, 5 и 6 и составные части раздела 8 ИСО 9001:2008 применимы преимущественно на «глобальном» уровне в организации, хотя они могут иметь желательный результат и на «проектном/программном уровне». Каждый проект или разработка продукции может учитывать или ориентироваться на соответствующие элементы системы менеджмента качества организации для обеспечения соответствия требованиям, относящимся к реализуемому проекту/выпускаемой продукции.
Организации, внедрившие системы менеджмента качества для разработки, осуществления эксплуатации или сопровождения программных продуктов на основе положений настоящего стандарта, могут принимать решение об использовании процессов из ИСО/МЭК 12207 в целях обеспечения или дополнения модели процессного подхода ИСО 9001:2008. Соответствующие параграфы ИСО/МЭК 12207:2008 указаны в каждом разделе настоящего стандарта, однако они не заключают в себе требования в дополнение к тем требованиям, что имеются в ИСО 9001:2008. Дальнейшее руководство с указаниями по применению ИСО/МЭК 12207 содержится в ИСО/МЭК 24748-3. Что касается дополнительного руководства ИСО/МЭК JTC 1/SC7 вырабатывает регулярные сообщения применительно к международным стандартам для разработки программных продуктов. В случаях когда эти сообщения (ссылки) относятся непосредственно к какому-либо пункту или подпункту ИСО 9001:2008, они помещаются после руководящих указаний для данного пункта или подпункта. В случае когда они применяются повсеместно в положениях пункта или подпункта, эти ссылки помещают в конце заключительной части пункта или подпункта.
В тех местах настоящего стандарта, где текст был приведен из ИСО 9001:2008, данный текст в целях облегчения его идентификации заключен в рамку.
1 Область применения
1.1 Общие положения
Настоящий стандарт устанавливает требования к системе менеджмента качества в тех случаях, когда организация:
a) нуждается в демонстрации своей способности всегда поставлять продукцию, отвечающую требованиям потребителей и соответствующим обязательным требованиям;
b) ставит своей целью повышение удовлетворенности потребителей посредством эффективного применения системы менеджмента качества, включая процессы постоянного ее улучшения, и обеспечение соответствия требованиям потребителей и соответствующим обязательным требованиям.
1 В настоящем стандарте термин «продукция» применим только:
a) к предназначаемой для потребителя или затребованной им продукции;
b) к любым заданным результатам процессов жизненного цикла.
2 Законодательные и другие обязательные требования могут быть выражены как правовые требования.
[ИСО 9001:2008 Системы менеджмента качества. Требования] [2]
Настоящий стандарт предлагает для организаций руководящие указания по применению ИСО 9001:2008 к процессам, связанным с заказом, поставкой, разработкой, осуществлением эксплуатации и сопровождением программных продуктов и к связанным с этими процессами сервисным обслуживанием. Он не добавляет или каким-либо иным другим образом не изменяет требования ИСО 9001:2008.
В приложении А (справочном) представлена таблица с дополнительными указаниями по внедрению ИСО 9001:2008, имеющимися в международных стандартах, разработанных ИСО/МЭК JTC 1/SC7 и ИСО/ТК 176.
Руководящие указания, представленные в настоящем стандарте, не предназначены для применения в качестве оценочных критериев при проведении мероприятий, связанных с регистрацией/сертификацией систем менеджмента качества.
1.2 Применение
Требования настоящего стандарта являются общими и предназначены для применения всеми организациями независимо от их вида, размера и поставляемой продукции.
Если какое-либо требование(я) настоящего стандарта нельзя применить вследствие специфики организации и ее продукции, допускается его исключение.
При допущенных исключениях заявления о соответствии настоящему стандарту приемлемы, если эти исключения подпадают под требования раздела 7 и не влияют на способность или ответственность организации обеспечивать продукцией, соответствующей требованиям потребителей и соответствующим обязательным требованиям.
Настоящий стандарт применим к программным продуктам, которые:
— являются элементом коммерческого контракта, заключенного с другой организацией;
— представляют собой продукцию, предназначенную для продажи на потребительском рынке;
— используются для обеспечения реализации процессов организации;
— встроены в техническую продукцию/оборудование, и
— относятся к программным услугам.
Некоторые организации могут осуществлять все вышеуказанные действия; другие могут специализироваться в одной области. В любой ситуации рекомендуется, чтобы система менеджмента качества организации охватывала все аспекты (связанные с программными и непрограммными средствами) деятельности организации.
2 Нормативные ссылки
ИСО 9000:2005 Системы менеджмента качества. Основные положения и словарь.
3 Термины и определения
В настоящем стандарте применены термины и определения, данные в ИСО 9000.
В тексте настоящего стандарта термин «продукция» может означать также «услуга».
В настоящем стандарте применены термины и определения, данные в ИСО 9000:2005 [1], и некоторые термины (включенные в настоящий стандарт для удобства пользования), данные в ИСО/МЭК 12207:2008 [7].
Однако в тех случаях, когда возникают противоречия в терминах и определениях, следует применять термины и определения, установленные в ИСО 9000:2005 [1].
3.1 деятельность (activity): Совокупность взаимосвязанных задач по реализации процесса.
[ИСО/МЭК 12207:2008, 4.3]
3.2 базовая линия (baseline): Официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени жизненного цикла элемента конфигурации.
[ИСО/МЭК 12207:2008, 4.6]
3.3 элемент конфигурации (configuration item): Объект внутри конфигурации, который удовлетворяет функции конечного использования и может быть однозначно определен в данной эталонной точке.
[ИСО/МЭК 12207:2008, 4.7]
3.4 COTS (COTS Commercial-Off-The-Shelf) (предназначенный для продажи готовый продукт): Программный продукт, имеющийся в продаже, который может быть использован без выполнения действий, связанных с разработкой.
3.5 разработка (implementation): Процесс жизненного цикла программного продукта, состоящий из действий по изучению требований, проектированию, программированию, интеграции, тестированию, инсталляции и обеспечению приемки программных продуктов.
3.6 модель жизненного цикла (life cycle model): Структура, состоящая из процессов, работ и задач, относящихся к жизненному циклу программного продукта, который может быть разделен на этапы, и которая используется для лучшего взаимопонимания.
[ИСО/МЭК 12207:2008, 4.17]
3.7 измерять (measure): Проводить измерение.
[ИСО/МЭК 15939:2007, 2.16]
3.8 мера измерения (measure): Переменная, которой присваивается значение, полученное в результате проведения измерения.
[ИСО/МЭК 15939:2007, 2.15]
3.9 измерение (measurement): Совокупность операций, предназначенных для определения числового значения переменной, выраженной в заданных единицах измерения.
[ИСО/МЭК 15939:2007, 2.17]
3.10 процесс (process): Совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующая входы в выходы.
3.11 регрессивное тестирование (regression testing): Тестирование, требуемое для определения того, что изменение в отношении какого-либо компонента системы не сказалось негативным образом на функциональных возможностях, надежности или характеристиках и не привело к появлению дополнительных дефектов.
3.12 выпуск (release): Конкретная версия элемента конфигурации, которая доступна для реализации конкретной цели.
[ИСО/МЭК 12207:2008, 4.35]
3.13 тиражирование (replication): Копирование программного продукта с одного носителя на другой.
3.14 программный элемент (software item): Идентифицируемый компонент программного продукта.
3.15 программный продукт (software product): Набор машинных программ, процедур и возможно связанных с ними документации и данных.
1 Программный продукт может предназначаться для доставки в качестве неотъемлемой части другого продукта или быть использован в ходе разработки.
2 Отличается от определения ИСО 9000.
3 В настоящем стандарте термины «software» и «software product» являются синонимами.