ГОСТ Р 56713-2015 (ISO/IEC/IEEE 15289:2011). Национальный стандарт Российской Федерации. Системная и программная инженерия. Содержание информационных продуктов процесса жизненного цикла систем и программного обеспечения (документация)
10. Содержание определенной информационной единицы (документа)
10.1 Общие положения
Определенное содержание информационных позиций должно быть предоставлено, как требуется в настоящем подразделе. Для каждого информационного термина универсальное содержание, как указано в разделе 7, должно быть частью требуемого содержания позиции. Информационное содержание позиции служит контрольным списком, который может быть удовлетворен отображением содержания организации, шаблонами и информационными моделями. Настоящий подраздел не предназначается, чтобы обратиться ко всему возможному информационному содержанию позиции или передать под мандат название информационной позиции, заказ или названия разделов в информационной позиции.
Некоторое содержимое дублировано или адаптировано в многократных информационных позициях и информационных типах изделия. Единственный исходный репозиторий (такой как система управления контентом) должен использоваться для подобного содержания для непротиворечивости и простоты развития. План управления информацией, план развития и план документации должны включать в себя тип информации и уровня детализации, который будет предоставлен в каждой информационной позиции, где дублирования в содержании существуют.
Содержание информационных позиций, идентифицированных в разделе 10, включает явно идентифицированные (но может не требоваться для соответствия) и неявно идентифицированные в ИСО/МЭК 12207:2008, ИСО/МЭК 15288:2008 и ИСО/МЭК 20000-1:2005, ИСО/МЭК 20000-2:2005.
В настоящем стандарте проект был выбран в качестве контекста для описания процессов, касавшихся планирования, оценки и управления. Принципы, связанные с этими процессами, могут быть применены в любой области управления организации (например, для программы или организации).
Определители и прилагательные (такие как программное обеспечение, архитектура, компонент, итоговый, предварительный, клиент, заинтересованные стороны, предприятие) могут быть применены как часть информационной позиции или названия документа.
Информационные позиции для систем могут быть специализированы для программного обеспечения.
Пример - Описание системы элемента, произведенное для позиции программного обеспечения, можно назвать описанием элемента программного обеспечения. Запрос на изменение для программного обеспечения можно назвать запросом модификации программного обеспечения.
10.2 План принятия
ИСО/МЭК 15288:2008, подпункт 6.3.1.3 b)
ИСО/МЭК 12207:2008, подпункт 6.1.1.3.1.9
Универсальный тип: план
План принятия должен подготовиться к принятию на основе определенной стратегии принятия и критериев. Это указывают объективные критерии определения приемлемости поставляемых предметов деятельности и любых технических процессов, методов или инструментов, требуемых для приемки продукта. Должны быть указаны методы, такие как тестирование, демонстрация, анализ и проверка. Это указывает степень участия поставщика. Если принятие основывается на тестах, оно может сослаться или обеспечить полный испытательный план.
См. также: интеграция программного обеспечения проверяет план.
10.3 Приемочный контроль и проверяющий отчет
ИСО/МЭК 12207:2008, ссылка 6.4.8.3.1.1
Универсальный тип: отчет
Приемочный контроль и проверяющий отчет указывают, что аквизитор рассмотрел и проверил продукт. Это указывает, принят ли продукт.
10.4 План закупок
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.1.8, 6.1.1.3.1.9, 6.1.1.3.1.12
Универсальный тип: план
План закупок включает в себя:
a) определение технических и управленческих процессов, необходимых для удовлетворения требований приобретения программного обеспечения, т.е. следующих операций приобретения: инициирование процесса, запрос предложений (RFP), (тендер) подготовка, подготовка договора и обслуживание, поставщик, контролирующий принятие и завершение;
b) системные требования, запланированную занятость систем, тип договора, организационную ответственность и понятие поддержки;
c) риски и методы для управления рисками;
d) опционы приобретения и критерии для включения риска, стоимость и преимущества для каждого опциона, который рассматривают.
Опционы приобретения включают стандартный продукт, продукт, разработанный внутренне или нанятый по контракту, и повторное использование или улучшение существующего продукта или услуги или любая комбинация этого.
План закупок должен включать в себя:
a) критерии отбора поставщика;
b) цель системы или программного обеспечения;
c) описание общего характера системы и компонентов, включая программное обеспечение;
d) схему процессов цикла ожидаемого ресурса и потребности в системном развитии, работе и обслуживании;
e) идентификацию проектного спонсора, организации аквизитора, пользовательских организаций и служб поддержки;
f) проектный обзор и контрольные этапы;
g) текущие и запланированные операционные стороны.
План закупок может включать затраты и бюджеты для приобретения.
10.5 План управления активами
ИСО/МЭК 12207:2008, подпункты 7.3.2.2, 7.3.2.3.1.1, 7.3.2.3.1.3, 7.3.2.3.2.2
Универсальный тип: план
План управления активами определяет стратегию, управление и технические процессы для управления активами. Это определяет систему классификации актива, хранение актива, обработку и поисковый механизм, принятие актива, сертификационные процедуры и процедуры выбытия.
10.6 Контрольный отчет о подтверждении
ИСО/МЭК 12207:2008, подпункт 7.2.7.3.1.6
Универсальный тип: отчет
Контрольный отчет о подтверждении признает, что аудит заканчивается и представляет запланированное разрешение проблем стороне аудита.
10.7 План аудита
ИСО/МЭК 12207:2008 (Станд. ИИЭР 12207-2008), подпункты 6.2.1.3.2.2, 7.2.7.3.2.1
ИСО/МЭК 20000-1:2005, подраздел 4.3
ИСО/МЭК 20000-2:2005, подраздел 4.3
Универсальный тип: план
План аудита определяет полную контрольную программу, а также определенные процессы, услуги или другие операции, которые будут подвергнуты аудиту. Это включает контрольные цели и приоритеты, предметы аудитов, включая предметы деятельности и записи, которые будут рассмотрены, и планирует запись и сообщение контрольных результатов.
10.8 Аудиторская процедура
ИСО/МЭК 12207:2008, подпункт 7.2.7.3.1.4
ИСО/МЭК 20000-1:2005, подразделы 4.3, 9.1, 9.2
Универсальный тип: процедура
Аудиторская процедура включает контрольные критерии, объем, частоту и методы для проведения аудитов. Это обрисовывает в общих чертах, как недостатки будут зарегистрированы и сообщает о том, кто ответственен за инициирование и выполнение корректирующего действия.
10.9 Аудиторский отчет
ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.15, 6.4.6.3.1.3, 7.1.7.3.1.4, 7.2.7.3.1.6
ИСО/МЭК 20000-1:200, подраздел 4.3
ИСО/МЭК 20000-2:2005, подраздел 9.1.5
Универсальный тип: отчет
Аудиторский отчет обеспечивает контрольные результаты и поставлен подвергнутой аудиту стороне. Это идентифицирует участников, сертификацию об аудиторской независимости, соглашение по ресурсам, вовлеченным в аудит, контрольный график, список позиций, которые будут подвергнуты аудиту, объем аудита, аудиторские процедуры, критерии входа и выхода, ссылка на проблемные записи, ответственность за намеченное мероприятие и критерии закрытия и соответствия. Это может включать контрольную стратегию, названия подвергнутых аудиту организаций, подвергнутый аудиту продукт или услугу, имя аудитора, даты и расположения аудита, контрольных критериев, статуса предыдущих контрольных намеченных мероприятий, новых намеченных мероприятий (включая ответственное лицо или организацию и дату оплаты) и результаты.
10.10 Полный план
ИСО/МЭК 20000-1:2005, подраздел 6.5
ИСО/МЭК 20000-2:2005, подраздел 6.5
Универсальный тип: план
Полный план документирует предсказанное или фактическое исполнение систем инфраструктуры с точки зрения составляющего и использования ресурсов. Это включает оценки будущей рабочей нагрузки (требования к мощностям). Это определяет подход для прогнозирующего анализа для определения, когда и сколько дополнительной способности должно быть получено для обновления услуги. Это включает справочные предложения с оценками затрат для рекомендуемых решений. Полный план должен обновляться по крайней мере ежегодно.
10.11 Процедура управления мощностями
ИСО/МЭК 20000-1:2005, подраздел 6.5
Процедуры управления мощностями объясняют, как организация контролирует и обеспечивает соответствующую способность и настраивает сервисную производительность.
10.12 Запрос на изменение
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.4.3, 6.1.2.3.3.2, 6.3.9.3.4.3, 6.4.9.3.1.3, 6.4.9.3.4.1, 6.4.9.3.4.2, 6.4.10.3.1.2, 6.4.10.3.2.1, 6.4.10.3.2.4, 7.2.2.3.3.1, 7.2.8.2, 7.3.1.3.1.3, 7.3.1.3.5.1, 7.3.2.3.3.6, 7.3.2.3.3.7, подраздел F.3.2, подпункт F.3.3.2.1
ИСО/МЭК 20000-1:2005, ссылка 2.11, 4.4.2, 6.5, 7.2, 9.1, 9.2, 10.1
ИСО/МЭК 20000-2:2005, ссылка 5.1.2, 9.1.3, 9.2.1, 9.2.2
Универсальный тип: запрос
Запрос на изменение идентифицирует элемент конфигурации, систему, услугу, аппаратные средства, программное обеспечение, интерфейс, актив или проблему документации или желаемое улучшение и просит модификации. Это ввод для инициирования изменений договора и процесса управления изменениями. Это может отразить запросы и связанные действия от клиентов и пользователей для помощи и консультации или просьбу удалить элемент конфигурации. Запрос на изменение должен представить преимущество и объем изменения, включая новый или измененный актив, функции или проблему, которая будет исправлена, приоритет, предположения и ограничения. Это может относиться к влиянию на графики, стоимость, продукты и тестирование.
См. также: отчет о проблеме.
Примечание - Запросы на изменение должны быть зарегистрированы и могут использовать ту же систему, которая записывает жалобы, инциденты и проблемы.
10.13 Процедура рассмотрения жалобы
ИСО/МЭК 20000-1:2005, подраздел 7.2
ИСО/МЭК 20000-2:2005, пункт 7.2.2
Универсальный тип: процедура
Процедура рассмотрения жалобы определяет то, что составляет жалобу (запись воспринятого несоблюдения соглашения об уровне обслуживания или неудовлетворенности клиента услугой). Это идентифицирует точку контакта поставщика услуг для официальных жалоб. Это документирует, как получить запись, приоритизировать, исследует, рассматривает, возрастает, решает и близкие жалобы, и как сообщить относительно жалоб и обеспечить обратную связь.
См. также: процедура управления инцидентами, сообщение о происшествии, процедура управления проблемой, отчет о проблеме.
10.14 Понятие операций
ИСО/МЭК 15288:2008, подпункт 6.4.1.2 a), пункт D.4 a
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.1.1, 6.4.1.2, 6.4.1.3.2.3
Универсальный тип: описание
Понятие операций (или операционное понятие) включает:
a) описание того, как система будет работать с точки зрения пользователей;
b) идентификацию потребностей заинтересованной стороны и ожидаемые типы системных пользователей;
c) идентификацию интерфейсов к существующим и будущим системам;
d) резюме операционных, организационных и влияние развития;
e) обзоры стоимости, критичности и выполнимости намеченной системы.
Понятие операций может включать:
a) намеченное взаимодействие системы в ее оперативной обстановке, такой как сценарии, модели или последовательности деятельности бизнес-процессов, обработанных системой, как основание для определения системных требований. Сценарии (или случаи использования) должны включать события, действия, стимулы, информацию и взаимодействия;
b) контекст использования услуг, таких как пользовательская культура, системные ограничения, операционная ситуация, потребности и требования, наложенные обществом, ограничения, наложенные организацией поставщика возможностями и ограничивающими характеристиками штата;
c) описание существующей системы или ситуации, включая фон, операционные политики и ограничения, режимы работы, оперативную обстановку, пользовательские классы, взаимодействие к внешним системам или процедурам, возможностям/функциям, рабочим характеристикам и среде поддержки;
d) сравнение процессов, как есть, к будущим процессам, которые будут обрабатываться новой системой;
e) идентификация проблем изменения, включая приоритеты, предположения и ограничения и изменения, которые рассматривают, но не рекомендуют.
См. также: оценка потребности продукта, спецификация системных требований.
Примечание - ИИЭР 1362-1998 обеспечивает дополнительное разъяснение.
10.15 План управления конфигурацией и политика
ИСО/МЭК 15288:2008, подпункт 6.3.5.3
ИСО/МЭК 12207:2008, подпункты 6.3.5.3.1.1, 7.2.2.3.1.1
ИСО/МЭК 20000-1:2005, подразделы 9.1, 9.2, 10.1
ИСО/МЭК 20000-2:2005, пункты 9.1.1, 10.1.2, 10.1.4
Универсальный тип: план, политика
Политика управления конфигурацией (CM) (или управление изменениями или политика выпуска) включает политику для того, как определяются элемент конфигурации и его компоненты. Политика управления изменениями определяет то, что составляет чрезвычайное изменение и обязанности по поручению и реализации нормальных и чрезвычайных изменений. Политика выпуска устанавливает требуемую частоту и тип выпусков, власти для выпуска в приемочное испытание и производственные среды, схему для однозначного определения выпуска и его содержания и подходов для группировки изменений в однозначно определенный выпуск, автоматизацию выпуска, проверку и принятие выпуска.
Примечания
1 Политика управления конфигурацией может быть включена в план управления конфигурацией или как отдельный набор политик. Точно так же политика выпуска может быть включена в план управления выпуска или как отдельный набор политик.
Как указано в ИСО/МЭК 20000-1:2005, управление конфигурацией должно быть запланировано и реализовано с планом управления выпуска и изменениями. План управления конфигурацией (CM) (или управление изменениями или план управления выпуска) описывает ответственную организацию по поручению и выполнению этих операций и их отношения с другими организациями, такими как разработка программного обеспечения, управление активами, поставщики и субподрядчики и обслуживание. Для наблюдательного совета или специальной организации, созданной для выполнения операций CM по проекту, план должен описать свою цель, членство и присоединение, рамки полномочий, операционные методы.
Для программного обеспечения план CM должен включать, как организация будет работать:
a) идентификация конфигурации, включая схему идентификации и классификации записей позиции программного обеспечения и информационных позиций и их версий, и учреждения оснований;
b) управление конфигурацией и управление изменениями;
c) учет статуса конфигурации;
d) аудит конфигурации и оценка, включая запись недостатков, инициирование корректирующих действий и отчетность.
План управления выпуска обеспечивает полное направление для планирования выпуска. Определенный план выпуска включает применимые подробные данные для определенного выпуска.
2 ИИЭР 828-2005 стандартов ИИЭР для планов управления конфигурированием ПО обеспечивает дополнительное разъяснение.
См. также: план выпуска.
10.16 Процедура управления конфигурацией
ИСО/МЭК 20000-1:2005, подразделы 9.1, 9.2. 10.1
ИСО/МЭК 20000-2:200, подразделы 9.2.1, 10.1.2, 10.1.7
Универсальный тип: процедура
Процедура управления конфигурацией (или управление изменениями, или процедура управления выпуска) представляет, как выполнить подробные операции для управления конфигурацией или процессов выпуска или управления изменениями. Как указано в ИСО/МЭК 20000-1:2005, процесс управления выпуска должен быть интегрирован с процессами управления конфигурацией и управления изменениями.
Процедуры включают:
a) внедрение процесса;
b) идентификацию конфигурации;
c) управление конфигурацией;
d) управление изменениями;
e) процедуры для утверждения полноты и правильности систем и выпусков программного обеспечения;
f) учет статуса конфигурации;
g) оценку конфигурации;
h) управление выпуском и поставкой;
i) определенную процедуру для управления чрезвычайными изменениями или выпусками, когда нормальная процедура недостаточна;
j) как неуспешное изменение может отменяться или исправляться.
Они должны включать:
a) процедуры для начального определения исходного состояния предметов деятельности;
b) регистрацию и анализ влияния запросов на изменение;
c) документирование объема изменений;
d) операции правления управления изменениями;
e) отслеживание происходящих изменений;
f) обновление данных конфигурации;
g) уведомление заинтересованных сторон, когда основания сначала установлены или позже изменены. Они могут включать процедуры управления активами, такие как уход актива.
10.17 Отчет о статусе конфигурации
ИСО/МЭК 12207:2008, подпункты 7.2.2.2 e), 7.2.2.3.4.1, 7.2.2.3.5.1
ИСО/МЭК 20000-2:2005, подраздел 6.5, подпункты 9.1.1, 9.1.4, 9.2.1
Универсальный тип: отчет
Отчет о статусе конфигурации (или отчет об управлении изменениями) обеспечивает статус управляемых элементов конфигурации, включая основания, идентификаторы выпуска и расположение позиции или ведущей версии программного обеспечения. Это может включать число изменений для проекта, истории версии, числа выпусков и сравнений выпусков. Это может быть в том же формате, как аудиторский отчет.
10.18 Договор
ИСО/МЭК 15288:2008, подпункты 6.1.1.2, 6.1.1.3, 6.1.2.2, 6.1.2.3, 6.1.3.3
ИСО/МЭК 12207:2008, подпункты 6.1.1.2, 6.1.1.3.4.2, 6.1.1.3.4.3, 6.1.2.2, 6.1.2.3.3.1, 6.1.2.3.6.2, 6.4.1.3.2.1, B.3.2.2.1, B.3.2.2.2, B.3.1.2.2, B.3.1.3.2, F.3.3.1.1, F.3.3.1.2, F.3.3.5.1
ИСО/МЭК 20000-2:2005, пункты 7.3.2, 7.3.3, 7.3.4
Универсальный тип: спецификация
Договор является формальным соглашением между аквизитором и поставщиком. Это обращается к следующему:
a) идентификация работающих организаций;
b) ведомость работ, которая будет выполнена с задачами на основе процесса управления службами, или системы или модели жизненного цикла программного обеспечения и объема задач;
c) системные требования и определение требований к программному обеспечению и аналитические результаты;
d) договорная цена и график платежей;
e) результаты, включая стандартные продукты идентифицируются;
f) график для поставщиков продукта или услуги;
g) права собственности к системам и техническим данным и правам на интеллектуальную собственность программного обеспечения: использование, владение, гарантия и лицензионные права;
h) положения для контроля, отчетности, проверки и критерии приемки;
i) процедуры для изменений договора, исключения, решения споров и завершения, такие как ответственность поставщика в случае ожидаемого или преждевременного расторжения договора или формального соглашения и передачи услуг другой стороне.
Договор может указать методы наиболее успешной практики для включения стандартов и стратегий процессов, операций и задач.
Неофициально обязательства или соглашения могут быть указаны между частями той же организации (меморандуме о договоренности).
10.19 Исследование удовлетворенности клиентов
ИСО/МЭК 12207:2008, подпункт 6.2.5.3.1.4
ИСО/МЭК 20000-2:2005, пункты 7.2.3, 10.1.8
Универсальный тип: запрос
Опрос удовлетворенности клиентов о производительности сервиса. Серия исследований может быть выпущена для отслеживания трендов в удовлетворенности клиентов.
10.20 Описание проектирования баз данных
ИСО/МЭК 12207:2008, подпункты 7.1.3.3.1.3, 7.1.4.3.1.3
Универсальный тип: описание
Описание проектирования баз данных является дизайном верхнего уровня для баз данных. Это включает следующее:
a) обзор базы данных и идентификация;
b) проектирование баз данных (включая описания применимых уровней дизайна, например, концептуальный, внутренний, логичный и физический);
c) ссылку для проектирования описаний программного обеспечения, используемого для доступа к базе данных или манипулирования;
d) объяснение для проектирования баз данных;
e) проектные решения всей базы данных о ее деятельности с точки зрения пользователя на встрече ее функциональных и эксплуатационных требований.
Описание детального проектирования базы данных касается позиций программного обеспечения, используемых для получения доступа или управления данными. Это обеспечивает видимость в дизайн и информацию, необходимую для управления базой данных. Это используется в качестве основания для реализации базы данных и связанных позиций программного обеспечения. Это включает следующее:
a) резюме истории развития базы данных, использования и обслуживания;
b) проектирование баз данных на концептуальных, внутренних, логических и физических уровнях;
c) идентификацию каждой позиции программного обеспечения, используемой для доступа к базе данных или манипулирования;
d) любые ограничения, оговорки или необычные особенности в дизайне позиций программного обеспечения базы данных;
e) типы ошибок, влияющих на базу данных и обработку ошибок;
f) отслеживаемость между каждой базой данных или связанной позицией программного обеспечения и системой или требованиями позиции программного обеспечения.
Детальное проектирование базы данных может указать:
a) методы доступа к базе данных;
b) предприятия данных и их отношения;
c) безопасность и ограничения целостности;
d) требования хранения данных;
e) ожидаемый размер элементов данных.
10.21 План развития
ИСО/МЭК 12207:2008, подпункты 7.1.1.3.1.3, 7.1.1.3.1.4, 7.1.3.3.1.5
Универсальный тип: план
План развития представляет, как организация или планы проекта для проведения опытно-конструкторских разработок (стратегия внедрения программного обеспечения). Это включает следующее:
a) идентификацию целей и стандартов, которые будут использоваться в системе или процессе разработки программного обеспечения;
b) идентификацию системы или модели жизненного цикла программного обеспечения, которая будет использоваться для удовлетворения требований продукта или услуги, на основе объема проекта, величины и сложности;
c) отображение операций процесса развития и методов наиболее успешной практики к выбранной модели жизненного цикла;
d) график, ресурсы, методологию, инструменты, стратегию повторного использования, намеченные мероприятия, роли и обязанности, которые будут использоваться в развитии и тесте;
e) квалификацию всех требований, включая безопасность;
f) ссылки для отделения планов или процедур для обращения к различным операциям в стадии разработки или процессу, таким как внедрение процесса развития, анализ системных требований, системный дизайн архитектуры, система и спецификация требований к программному обеспечению, высокоуровневая и низкоуровневая система или проектирование программного обеспечения, строительство программного обеспечения или кодирование, системный тест элемента или тест единицы программного обеспечения, система или тест на интеграцию программного обеспечения, система или испытания качества программного обеспечения, система или установка программного обеспечения и принятие;
g) идентификация примечаний и соглашений, обозначения, используемые в разработке.
10.22 План размещения
ИСО/МЭК 15288:2008, подпункт 6.4.11.3
ИСО/МЭК 12207:2008, подпункт 6.4.11.3.1.1
ИСО/МЭК 20000-1:2005, раздел 5
Универсальный тип: план
План размещения (или пенсионная программа) представляет, как операции будут проводиться для ликвидации систем или позиций программного обеспечения или услуг и связанных документов. Это идентифицирует заинтересованные стороны и пользовательские организации или пользователей, чтобы быть уведомленным относительно запланированного выбытия услуги, заменяющих систем и услуг, если таковые имеются, график для прекращения поддержки и планы относительно системного размещения или архивации программного обеспечения и документации. Это включает графики, действия и ресурсы для разборки или уничтожения системы, принося это в социальном отношении в физически приемлемое состояние в соответствии с требуемой безопасностью, конфиденциальностью и экологическими стандартами, директивами и законами и предотвращением последующих неблагоприятных воздействий на заинтересованные стороны, общество и среду. Это рассматривает связанные системы предоставления возможности и места хранения.
10.23 План документации
ИСО/МЭК 12207:2008, подпункты 6.3.6.3, 7.2.1.2, 7.2.1.3.1.1
Универсальный тип: план
План документации идентифицирует и указывает документацию проекта (информационные позиции). Это указывает цель, аудиторию, содержание, структуру, среду и формат каждого набора документов и документа. Это идентифицирует документы и информацию, которая будет получена, снова использована или разработана, и включает график, ресурсы, методологию, инструменты, управление контентом или стратегию повторного использования документации, намеченных мероприятий и ролей и обязанностей, соответствующих плану управления информацией. Это включает графики для развития документа, обзор и утверждение. Это идентифицирует, кто получит или имеет доступ к ограниченным документам. План документации должен включать шаблон управления или стандарт для каждого документа.
См. также: план управления информацией.
10.24 План разработки предметной области
ИСО/МЭК 12207:2008, подпункт 7.3.1.3.1.1
Универсальный тип: план
Разработка предметной области планирует то, как организация намеревается провести процедуры разработки предметной области и операции. Это описывает процесс для обработки запросов на изменение.
10.25 Отчет об оценке
ИСО/МЭК 15288:2008, подпункт 6.2.5.3
ИСО/МЭК 12207:2008, подпункты 6.1.2.3.1.15, 6.1.2.3.4.8, 6.1.2.3.4.15, 6.4.2.3.2.1, 6.4.3.3.2.1, 6.4.5.3.2.2, 6.4.6.3.1.2, 7.1.2.3.1.2, 7.1.3.3.1.6, 7.1.4.3.1.7, 7.1.5.3.1.5, 7.1.6.3.1.5, 7.1.7.3.1.3
ИСО/МЭК 20000-2:2005, пункт 9.2.2
Универсальный тип: отчет
Отчет об оценке обеспечивает результаты обзоров и оценок, таких как оценка ограничений дизайна, удовлетворенности клиентов, анализа записей изменения или финансовых различий. Это включает критерии оценки. Оценки могут основываться на критериях отслеживаемости, непротиворечивости, контролируемости, удобства пользования, удовлетворенности и выполнимости. Это предоставляет информацию и рекомендации помочь будущему принятию решений, и это может указать тренды и рекомендации для будущих сопоставимых ситуаций. Для оценок управления конфигурированием ПО отчет предоставляет информацию о функциональной полноте позиций программного обеспечения против их требований и физической полноте позиций программного обеспечения (отражают ли их дизайн и код актуальное техническое описание).
См. также: аудиторский отчет, контрольный отчет, отчет об управлении и отчет о проверке протокола, сервисный отчет, отчет о проверке.
10.26 Процедура внедрения
ИСО/МЭК 15288:2008 подпункт 6.4.4.3 b)
Универсальный тип: процедура
Процедура внедрения детализирует, как система или системные элементы будут произведены для удовлетворения конструктивных требований. Процедуры внедрения могут обратиться к оборудованию системы и конфигурации программного обеспечения, созданию программного обеспечения и приведению в операционную готовность.
См. также операционную процедуру тестирования, учебную документацию.
10.27 План улучшения
ИСО/МЭК 12207:2008, подпункты 6.2.1.3, 6.3.4.3.1.5
ИСО/МЭК 15288:2008, подпункты 6.2.1.3, 6.3.4.3
ИСО/МЭК 20000-1:2005 подраздел 4.3, пункты 4.4.2, 4.4.3, подразделы 6.1, 8.3, 8.3.9, 9.2, 9.3, 10.1
ИСО/МЭК 20000-2:2005, подраздел 4.3, пункты 4.4.2, 6.1.3, 6.6.7, 7.2.2, 7.2.3, 8.2.2, 8.3.9, 9.1.5, 9.2.2, 10.1.9
Универсальный тип: план
План улучшения представляет, как организация планирует улучшить обслуживание (сервисный план улучшения) или процесс (план совершенствования процесса). Улучшение должно быть связано с организационными целями. План включает, как будут рассмотрены процессы, а также то, как рекомендуемые улучшения и запросы на изменение будут идентифицированы, зарегистрированы, приоритизированы, разрешены, выполнены, измерены, оценены и сообщены. Справочная документация основания плана улучшения процесса или уровня обслуживания, который будет улучшен и может указать услугу, или цель совершенствования процесса (новый уровень). План улучшения идентифицирует, какие информационные позиции (политики, процедуры и планы) должны быть обновлены для отражения оптимизированного процесса или услуги. План улучшения может включать оценку организационной культуры и отношений менеджеров и возможности адаптироваться, доступные ресурсы, средства и инструменты и финансовые ограничения на проект улучшения.
Примечание - ИСО/МЭК 15504-4 дает дополнительное разъяснение.
10.28 Политика улучшения
ИСО/МЭК 20000-1:2005, пункт 4.4.1
ИСО/МЭК 20000-2:2005, пункт 4.4.1
Универсальный тип: политика
Политика улучшения выражает обязательства организации улучшить свои услуги или продукты путем создания их более эффективными и имеющими большую силу. После "План действительно проверяют" - акт, методология для непрерывного улучшения, политические основы, как улучшение будет включено в планы относительно определенных процессов и услуг. Это идентифицирует роли и обязанности для операций улучшения.
10.29 Процедура управления инцидентами
ИСО/МЭК 20000-1:2005, подразделы 6.6, 8.2, 8.3
ИСО/МЭК 20000-2:2005, подразделы 6.6.6, 8.2.2, 8.3.7
Универсальный тип: процедура
Процедура управления инцидентами (или процедура управления инцидентами безопасности) определяет, как получить запись, приоритизировать, увеличить, разрешить, закрыть инциденты или запросы на обслуживание, включая инциденты безопасности, и как обеспечить обратную связь. Это включает определение того, что составляет инцидент, основной инцидент и проблему. Это покрывает инициирование действия, уведомление, классификацию, анализ тренда, рост, резолюцию, отслеживание статуса и отчетность и управление делопроизводством инцидента. Это включает процедуру, чтобы гарантировать, что все инциденты безопасности исследованы и получают ответ управления.
См. также: процедура управления проблемой.
10.30 Сообщение о происшествии
ИСО/МЭК 20000-1:2005, ссылка 6.6, 8.2
ИСО/МЭК 20000-2:2005, ссылка 6.6.6, 8.2.1
Универсальный тип: отчет
Сообщение о происшествии или сообщение о происшествии безопасности решает проблемы или несоответствие (отклонение) с требованиями по контракту, сообщенные проблемы клиента. Отчет может быть консолидацией инцидентов или жалоб.
Это должно включать информацию для использования в будущем, чтобы предотвратить проблемы (извлеченные уроки) и идентифицировать дублирование проблем и трендов.
Это может включать:
a) отчетность о контрольном числе и связанной информации об управлении;
b) идентификацию репортера инцидента;
c) дату и время возникновения инцидента, роста, резолюции и закрытия;
d) расположение (среда) инцидента в системе, программном обеспечении или информационном элементе конфигурации;
e) применимое предоставление договора или требование соответствия;
f) причину, природу и влияние (серьезность) инцидента;
g) слова "непосредственное корректирующее действие" рекомендованы;
h) связанные намеченные мероприятия, ответственное лицо или организацию и дату оплаты;
i) ссылки на подобные инциденты, кто сообщил о проблемах и известных ошибках;
j) ответственное лицо или организацию, вместе с надлежащим утверждением показа подтверждения и внедрением решения;
k) информацию о закрытии инцидента;
l) информацию из организационных (внутренних) обзоров.
Примечание - ИСО/МЭК 20000-1:2005 и ИСО/МЭК 20000-2:2005 различают отчеты о проблеме и сообщения о происшествии. Реагирование на инциденты имеет дело с восстановлением услуги пользователям, тогда как разрешение проблемы касается идентификации и удаления причин инцидентов. Отчет о возможности подобен, но включает в себя анализ потенциальных положительных событий.
См. также: отчет о проблеме, запрос на изменение.
10.31 План управления информацией
ИСО/МЭК 15288:2008, подпункт 6.3.6.3, D.4 m)
ИСО/МЭК 12207:2008, подпункты 6.2.3.3.3.2, 6.2.4.3.4.1, 6.2.4.3.4.5, 6.3.6.3.1, 6.3.6.3.2.5, 7.2.4.3.2.5
Универсальный тип: план
План управления информацией (или план управления документацией, или план управления знаниями) представляет, как проектировщик или поставщик услуг планирует провести управление информацией или операции управления знаниями в течение жизненного цикла. Это включает:
a) описания процесса и операций для поручения, разработки, рассмотрения, хранения, сообщения и поддержания знания или информации в электронных и печатных средах;
b) идентификацию информации, которая будет получена, снова использована, произведена и поддержана;
c) ресурсы, методологию, инструменты, намеченные мероприятия и роли и обязанности, соответствующие полному плану управления проектом;
d) положения для стратегии управления контентом или повторного использования и управление версионностью (управление конфигурацией документа);
e) графики для информационного развития, обзор и утверждение;
f) кто получит или имеет доступ к закрытой информации;
g) организационную политику и процесс для отставания или выбытия от информации и записей после закрытия проекта.
План управления знаниями включает определение инфраструктуры и обучение поддерживать факторы и пользователей интеллектуальных активов организации, схемы классификации для активов и критериев актива.
См. также: план документации.
10.32 План информационной безопасности
ИСО/МЭК 20000-1:2005, подраздел 6.6
ИСО/МЭК 20000-2:2005, пункты 6.6.6, 6.6.7
Универсальный тип: план
План информационной безопасности включает следующее:
a) описание того, как организация идентифицирует, управляет и защищает физическую и логическую безопасность систем, активов и информации;
b) описание того, как будут реализованы требования для конфиденциальности, целостности и доступности информации;
c) описание того, как система или услуга лишает несанкционированного доступа, разрешает санкционированный доступ, защищает данные при передаче, хранении и обработке и обеспечивает безопасность экономически эффективным способом;
d) описание того, как будут идентифицированы угрозы безопасности и связанные средства управления, включая средства управления доступом;
e) описание контроля систем, контроля для обнаружения инцидентов безопасности и анализа трендов безопасности;
f) конкретные процедуры по защите чувствительных персональных данных и классифицированных безопасностью данных расследования проблем безопасности и отчетности;
g) процедуры для анализа эффективности политики информационной безопасности, процедур и операций;
Примечание - ИСО/МЭК 27002:2005 обеспечивает инструкции для управления информационной безопасностью. ИСО/МЭК 27001:2005 обрабатывает для установления, реализации, работы, контроля, рассмотрения, поддержания и улучшения информационной безопасности.
10.33 Политика информационной безопасности
ИСО/МЭК 12207:2008, подпункт 6.1.2.3.4.5
ИСО/МЭК 20000-1:2005, подраздел 6.6
ИСО/МЭК 20000-2:2005, пункты 6.6.1, 6.6.5
Универсальный тип: политика
Политика информационной безопасности включает следующее:
a) обязательства организации идентифицировать, управлять и защищать физическую и логическую безопасность информации и систем, ранее хранивших, передававших и обрабатывавших информацию;
b) цели для сохранения конфиденциальности, целостности и доступности информации;
c) правила для необходимости и доступа к информации на каждом уровне организации работ по проекту;
d) методологию для управления рисками и для установления и контроля управления безопасностью, включая аудиты;
e) подход для обучения информационной безопасности и осведомленность для сотрудников и клиентов.
10.34 Инсталляционный план
ИСО/МЭК 15288:2008, пункт 6.4.7.3
ИСО/МЭК 12207:2008, подпункт 6.4.7.3.1.1
Универсальный тип: план
Инсталляционный план обеспечивает подход для установки элемента конфигурации в его целевой среде. Это включает предпосылки программного и аппаратного обеспечения, решенные проблемы, обходные решения для нерешенных проблем, положения для пользовательского обучения, преобразования от существующих систем, инсталляционного контрольного списка и инсталляционных инструкций. Это обеспечивает точку контакта для вопросов, касающихся установки, вспомогательного материала и любых проблем относительно безопасности и конфиденциальности. Для установки программного обеспечения это предоставляет информацию о приложении и инициализации базы данных, выполнении и завершении.
10.35 Отчет об установке
ИСО/МЭК 15288:2008, подпункт 6.4.7.3
ИСО/МЭК 12207:2008, подпункт 6.4.7.3.1.2
Универсальный тип: отчет
Отчет об установке обеспечивает результаты установки, включая связанные события, инсталляционное расположение, устанавливаемую версию, даты установки и завершенный инсталляционный контрольный список.
10.36 Интеграция и отчет о тесте
ИСО/МЭК 12207:2008, подпункты 6.4.5.3.1.1, 7.1.6.3.1.2
ИСО/МЭК 20000-2:2005, пункт 9.1.2
Универсальный тип: отчет
На основе системы или требований к программному обеспечению, интеграции представляют отчеты о тесте, результаты интеграции и тестирования системы, которая может включать компоненты программного обеспечения или программное обеспечение, объединенное с позициями аппаратной конфигурации и ручными операциями. Результаты должны продемонстрировать соответствие с планом теста на интеграцию и требованиями позиции и интеграцией позиций в следующую версию интегрированного основания. Это включает идентификацию позиции, дату тестирования, интеграции и испытательных требований и критериев, испытательный идентификатор, обзор результатов, детализированные результаты и объяснение для решений. Это описывает проблемы, с которыми сталкиваются, и отклонения от запланированных процедур тестирования.
10.37 План интеграции
ИСО/МЭК 15288:2008, подпункты 6.4.4.3, 6.4.5.3
ИСО/МЭК 12207:2008, подпункты 7.1.6.3.1.1, 7.1.6.3.1.2, 7.1.6.3.1.5
Универсальный тип: план
План интеграции (или план внедрения) описывает подход к внедрению, интеграции или собранию системных элементов, включая предоставление средств, инструментов и ресурсов и подготовки к тестированию интеграции. Для систем план внедрения определяет схему действий, синхронизацию и ресурсы, управляющие строением, покупкой или действиями повторного использования, которые делают доступными системный элемент готовым к системному собранию. Это определяет задачи для дизайна системных элементов, процессы производства и ограничения, надлежащие выбранной среде производства, технологии, обеспечивая инструменты и оборудование. Для программного обеспечения план интеграции определяет, как единицы программного обеспечения и компоненты будут связаны или объединены для формирования поставляемой позиции программного обеспечения. Это включает отслеживаемость системы или требования к программному обеспечению. Это включает или ссылается на испытательный план с испытательными требованиями и процедурами тестирования.
См. также: план улучшения.
Примечание - В управлении обслуживанием план внедрения может быть подготовлен к проекту реализации новой услуги или улучшения существующего обслуживания, как описано в TR ИСО/МЭК 20000-5:2010.
10.38 Описание интерфейса
ИСО/МЭК 15288:2008, подпункт 6.4.3.3
ИСО/МЭК 12207:2008, подпункты 6.3.5.3.2.2, 6.4.3.2 d), 7.1.3.3.1.2, 7.1.4.3.1.2
ИСО/МЭК 20000-1:2005, подразделы 7.3, 9.1
Универсальный тип: описание
В описании интерфейса приведены интерфейсные характеристики единицы одной или более систем, подсистем, областей, позиций аппаратных средств, позиций программного обеспечения, ручных операций (процессов) или других системных компонентов. Это представляет интерфейсные характеристики, включая системы или элементы конфигурации, выполняющие интерфейс (включая человеческую систему и человеческие интерфейсы пользователя), стандарты и протоколы, ответственные стороны, график операций и обработку ошибок. Это включает схемы интерфейсов для изображения интерфейсов. Это должно определить существующие или постоянные интерфейсные характеристики и то, что разрабатывается или изменяется.
10.39 Политика жизненного цикла и процедура
ИСО/МЭК 15288:2008 подпункты 6.2.1.2, 6.2.1.3, 6.2.3.3 b) 1) iii), пункты 2.3, B.2.3
ИСО/МЭК 12207:2008, подпункты 6.2.1.1, 6.2.1.2, 6.2.1.3.1.1, 6.2.1.3.3.1, пункт 2.3.1
Универсальный тип: политика, процедура
Политика жизненного цикла и процедура включают высокоуровневое политическое руководство и определенные шаги, чтобы выбрать, адаптировать и реализовать модель жизненного цикла в проекте. Это определяет роли, ответственность, учет и власть для управления процессами жизненного цикла, включая совершенствование процесса. Это идентифицирует критерии ввода и завершения каждого этапа жизненного цикла. Это идентифицирует и описывает процессы организации, которые будут применены в проектах.
10.40 План обслуживания
ИСО/МЭК 15288:2008, подпункт 6.4.10.3
ИСО/МЭК 12207:2008, подпункт 6.1.1.3.1.7, 6.4.10.1, 6.4.10.3.1.1, 7.3.2.3.3.6
Универсальный тип: план
План обслуживания представляет то, как организация или проект планируют соответствовать системным требованиям доступности и требованиям (логистике) обслуживания. Это включает следующее:
a) цели, стратегии и подходы для системы или специалиста по обслуживанию программного обеспечения для решения проблем, обновляющего систему и проверяющего новые обновления;
b) критерии выполнения обслуживания;
c) подход к следующим операциям: внедрение процесса обслуживания (как просить обслуживание) проблема и анализ модификации, внедрение модификации, обновление обслуживания, обзор и принятие, миграция и уход программного обеспечения;
d) результаты процесса обслуживания;
e) выполнение ресурсами (например, средствами, программным обеспечением, аппаратными средствами, инструментами и персоналом) всех аспектов обслуживания и взаимосвязи среди ресурсов;
f) запланированные периоды для выполнения обслуживания;
g) специальные процедурные требования во время обслуживания (например, безопасность, права доступа и управление документацией).
Это должно идентифицировать определенные стандарты, методы, инструменты и обязанности по запланированному и профилактическому техническому обслуживанию.
10.41 Правила технического обслуживания
ИСО/МЭК 15288:2008, подпункт 6.4.10.3
ИСО/МЭК 12207:2008, подпункт 6.4.10.3.1.1
Универсальный тип: процедура
Правила технического обслуживания касаются процессов для получения, записи и отслеживания проблемных отчетов и запросов на изменение (запросы модификации) от пользователей, выполнение профилактического и корректирующего обслуживания и обеспечение обратной связи поддержки клиентов для пользователей. Это должно идентифицировать определенные стандарты, методы, инструменты и обязанности по техническому обслуживанию. Это может идентифицировать систему или области программного обеспечения, которые могли измениться, и потребности в обучении. Правила технического обслуживания по системам касаются стратегии разборки, методов обнаружения ошибок и последовательностей тестирования и повторной сборки.
10.42 План измерения
ИСО/МЭК 15288:2008, подпункт 6.3.7.3
ИСО/МЭК 12207:2008, подпункт 6.3.7.2 c), 6.3.7.3.1.1, 6.3.7.3.1.3, 6.3.7.3.1.4, 6.3.7.3.2.1
ИСО/МЭК 20000-2:2005, раздел 4.3
Универсальный тип: план
План измерения идентифицирует потребности и требования для измерения в организации, проекте или услуге. Это идентифицирует выбранные меры и сбор данных, хранение, анализ и процедуры отчетности. Это определяет, как процесс и измерения будут оценены. Позиции, которые будут измерены, включают достижение сервисных целей, удовлетворенности клиентов, использования ресурсов, главных проблем и трендов.
10.43 Контроль и отчет об управлении
ИСО/МЭК 15288:2008, подпункты 6.3.2.3, 6.3.4.3 b), 6.3.7.1, 6.3.7.3 b)
ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.8, 6.1.2.3.4.15, 6.3.2.3, 6.3.4.3.3.4, 6.3.4.3.6.3, 6.3.7.1, 6.3.7.3.2.4, 7.3.2.3.3.5, 7.3.2.3.3.7
ИСО/МЭК 20000-1:2005, подразделы 4 c), 6.1, 9.2
ИСО/МЭК 20000-2:2005, подпункты 6.1.3, 6.3.2, 9.2, 9.2.1, 9.2.4
Универсальный тип: отчет
Отчет о контроле и управлении обеспечивает контролирующие результаты. Это может включать следующее:
a) историю всех контрольных результатов и действий управления и результатов отдельных контрольных аудитов;
b) измерения процессов и услуг против целей и требований;
c) контроль динамики технических показателей, смягчение рисков, стоимости и графиков, отчетность статуса проекта;
d) анализ эффектов рисков на достижении системного качества, своевременности и прибыльности;
e) результаты повторного использования актива, включая информацию о первоначальном разработчике или владельце актива, стоимости многократного использования актива и сбережений и преимуществ от многократного использования актива.
10.44 Операционная процедура тестирования
ИСО/МЭК 12207:2008, подпункты 6.4.9.3.1.3, 6.4.9.3.2.2
Универсальный тип: процедура
Операционная процедура тестирования определяет, как проверить систему или программное обеспечение перед его операционным выпуском в его намеченной среде. Это включает критерии приемки, идентификацию версии системы или проверяемого программного обеспечения, данные испытаний и аналитическую процедуру после испытания, чтобы гарантировать, что тестирование проведено, как запланировано. Это объясняет использование процедуры разрешения проблемы организации.
См. также: процедура испытаний качества.
10.45 Процедура управления проблемой
ИСО/МЭК 12207:2008, подпункты 6.2.1.3.2.1, 6.4.9.3.1.2, 6.4.9.3.1.3, 7.2.8.3.1.1
ИСО/МЭК 20000-1:2005, подраздел 6.6, 8.3
ИСО/МЭК 20000-2:2005, подпункты 7.2.2, 7.2.3, 8.3.7
Универсальный тип: процедура
Процедура управления проблемой определяет, как получить запись, приоритизировать, увеличить, разрешить близкие проблемы, как управлять влиянием проблем и как обеспечить обратную связь. Это включает определение того, что составляет основную проблему или инцидент. Это покрывает инициирование действия, уведомление, классификацию, анализ первопричины, анализ тренда, проблемный рост, разрешение проблемы, отслеживание статуса, отчетность и управление делопроизводством задач.
Примечание - Согласно ИСО/МЭК 20000, проблемные процедуры управления являются отдельными, но связанными с процедурами для инцидентов, выполнения запросов на обслуживание и претензий клиента.
См. также: процедура управления инцидентами.
10.46 Отчет о проблеме
ИСО/МЭК 15288:2008, подпункты 6.3.3.3 a) 2), 6.4.5.3 b), 6.4.6.2 b), 6.4.6.3 b), 6.4.7.2 e), 6.4.7.3 b), 6.4.8.3 b), 6.4.9.2 c), 6.4.10.2 e), 6.4.10.3 b)
ИСО/МЭК 12207:2008, подпункты: 6.1.2.3.4.15, 6.3.2.3.2.1, 6.3.3.3.1.3, 6.3.3.3.3.1, 6.4.8.2, 6.4.8.3.1.1, 6.4.8.3.1.3, 6.4.9.3.1.3, 6.4.9.3.4.2, 6.4.9.3.5.2, 6.4.10.3.1.2, 6.4.10.3.2.1, 6.4.10.3.2.4, 7.1.1.3.1.2, 7.2.8.2 f), 7.2.8.3.1.1, 7.2.8.3.2.1, 7.3.1.3.1.3, 7.3.2.3.3.6, 7.3.3.3.5.3, B.3.2.3.2
ИСО/МЭК 20000-1:2005, подраздел 8.3
ИСО/МЭК 20000-2:2005, пункт 8.3.6
Универсальный тип: отчет
Отчет о проблеме (также названный отчетом несоответствия или запросом корректирующего действия) сообщает о проблемах или несоответствии (отклонении) с требованиями по контракту. Это может быть консолидация проблемных записей. Это служит вводом к ИСО/МЭК 12207:2008 процесса разрешения проблемы.
Это должно включать информацию для использования в будущем, чтобы предотвратить проблемы (извлеченные уроки) и идентифицировать дублирование проблем и трендов.
Это может включать:
a) сообщение о проблеме, контрольном числе и связанной информации об управлении;
b) идентификацию репортера проблемы;
c) дату и время возникновения задач, роста, резолюции и закрытия;
d) расположение (среду) проблемы в системе, программном обеспечении или информационном элементе конфигурации;
e) применимое предоставление договора или требование соответствия;
f) причину, природу и влияние (серьезность) проблемы;
g) это решение или корректирующее действие рекомендованы;
h) связанные намеченные мероприятия, ответственное лицо или организацию и дату оплаты;
i) ссылки на подобные проблемы, ранее сообщенные;
j) ответственное лицо или организацию вместе с надлежащим утверждением показа подтверждения и внедрением решения;
k) проблемную информацию о закрытии;
l) информацию из организационных (внутренних) обзоров.
Для проблем, происходящих во время тестирования или работы, это должно включать вводы, ожидаемые результаты, фактические результаты, аномалии, дату и время, шаг процедуры, среду, попытки повторить проблему и наблюдателей. Это может сообщить о временном или постоянном решении проблемы.
Примечание - ИСО/МЭК 20000-1:2005 и ИСО/МЭК 20000-2:2005 различают отчеты о проблеме и сообщения о происшествии. Реагирование на инциденты имеет дело с восстановлением услуги пользователям, тогда как разрешение проблемы касается идентификации и удаления причин инцидентов. Отчет о возможности подобен, но включает в себя анализ потенциальных положительных событий.
См. также: запрос на изменение, сообщение о происшествии.
10.47 Обработать процедуру оценки
ИСО/МЭК 12207:2008, подпункт 6.2.1.3.2.1
Универсальный тип: процедура
Процедура оценки процесса описывает, как провести совершенствование процесса жизненного цикла и как оценить пригодность и эффективность организационных процессов. Это может включать цели оценки.
10.48 Отчет об анализе совершенствования процесса
ИСО/МЭК 15288:2008, подпункты 6.2.1.3 c), 6.3.7.3 c)
ИСО/МЭК 12207:2008, подпункты 6.2.1.3.3.2, B.3.3.1.2, B.3.3.2.2, B.3.3.3.2, 6.3.7.3.3
Универсальный тип: отчет
На основе исторического, технического и данных об оценке отчет об анализе совершенствования процесса представляет подходы, чтобы оптимизировать процессы, рекомендовать изменения и определить технологические потребности продвижения. Это может включать качественные данные о затратах, чтобы оптимизировать процессы организации и определить стоимость качества.
10.49 Оценка потребности продукта
ИСО/МЭК 15288:2008, подпункт 6.1.2.3
ИСО/МЭК 12207:2008, подпункты 6.1.1.2, 6.1.1.3.1.1
Универсальный тип: отчет
Оценка потребности продукта используется для получения согласия среди аквизитора, разработчика и поддержки пользовательских организаций по спросу на предложенную систему. Это может сфокусировать на сообщении потребностей пользователя разработчику или идей разработчика пользователю и другим заинтересованным сторонам. Это включает следующее:
a) решение и объяснение для приобретения разработки или улучшения системы, программного продукта или услуги;
b) описание предложенной системы с точки зрения пользователя должно быть выполнено, отношение системы к существующим или запланированным системам или процедурам и способу, которым система должна использоваться (понятие операций).
Оценка потребности продукта может включать:
a) анализ улучшений, недостатков и ограничений и рассмотренных альтернатив и компромиссов;
b) оценки для технической, стратегической, экономической и маркетинговой базы и исследований совместимости;
c) предварительную информацию о системных требованиях, системных прототипах, возможной системной занятости, возможных понятиях поддержки;
d) предварительную информацию о типе договора;
e) текущую и потенциальную ответственность организаций;
f) определение рисков и методы управления рисками.
См. также: понятие операций.
10.50 Отчет о ходе работ
ИСО/МЭК 15288:2008, подпункты 6.1.2.3, 6.2.3.3, 6.3.2.2, 6.3.2.3, 6.3.3.2, 6.3.3.3
ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.15, 6.3.2.2, 6.3.2.3.1.1, 6.3.2.3.2.2, 6.3.3.2, 6.3.3.3.3.1, 6.3.3.3.3.1
ИСО/МЭК 20000-1:2005, подразделы 4.2, 4.3, пункты 4.4.2, 4.4.3, раздел 5
Универсальный тип: отчет
Отчет о ходе работ обеспечивает результаты контроля выполнения определенного плана или процессов для внутреннего или внешнего распределения. Это включает резюме решений, контроль результатов, намеченные мероприятия, процесс или сервисные характеристики и зарегистрированные совершенствования процесса. Это оценивает степень приверженности планам. Это предоставляет информацию о спроектированной стоимости, производительности и рисках графика, любых изменениях ранее утвержденных планов и связанном влиянии на проект, корректирующих действиях, действиях обработки риска, отслеживании задач и анализе задач.
10.51 План управления проектом
ИСО/МЭК 15288:2008, подпункты 6.1.2.3, 6.2.3.3, 6.3.1.1, 6.3.1.2, 6.3.1.3
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.4.3, 6.1.2.3.4.3, 6.1.2.3.4.5, 6.1.2.3.4.6, 6.2.2.3.1.2, 6.2.3.3.1.6, 6.2.3.3.2.1, 6.3.1.1, 6.3.1.2, 6.3.1.3.2.1, 6.3.1.3.3.3, 6.3.2.3.2.1, 6.2.3.3.1.6, 7.2.6.3.1.1, 7.2.6.3.2.1, F.3.3.5.3
Универсальный тип: план
План управления проектом представляет, как проектные процессы и операции будут выполнены для уверения успешного завершения проекта и качества поставляемого продукта или услуги. Это включает следующее:
a) идентификацию выбранной системы или модели жизненного цикла программного обеспечения для удовлетворения договорных требований и отображения процессов, операций и задач к выбранной модели жизненного цикла;
b) организационную структуру проекта, показывая власть и ответственность каждой организационной единицы, включая внешние организации и ответственность аквизиторов, поставщиков и пользователей;
c) требования для потребностей ресурса и участия аквизитора в обеспечении ресурсов;
d) ожидаемое участие аквизитора в совместных рассмотрениях, аудитах, неофициальных встречах, отчетах, запросах на изменение, внедрениях, утверждениях, принятиях и доступе к сервисам;
e) ожидаемое участие пользователя в спецификации требований, обзорах и оценках;
f) политику безопасности для управления доступом к системам и позициям программного обеспечения, информации о проекте, данным и инфраструктурам;
g) средние значения отчетности и документов и информационных позиций, которые будут поставлены;
h) другие планы, которые будут произведены как отдельные документы во время проекта;
i) риски и анализ степени риска для технического, стоимостного и временного рисков;
Это должно включать Work Breakdown Structure (WBS) процессов жизненного цикла и операций, включая продукты, услуги и непоставляемые позиции, которые будут предоставлены, такие как установление проектной инфраструктуры.
Это может включать следующее:
a) процедуры для перепланирования;
b) опционы для разработки продукта или предоставления услуги и анализа рисков, связанных с каждым опционом;
c) планы относительно управления субподрядчиками, включая выбор субподрядчика и участие между субподрядчиком и аквизитором;
d) планы относительно завершения проекта, включая разбирательства проектного перевода по службе персонала и штата, архивные материалы проекта и подготовку окончательного отчета для включения опыта, а также анализ достигнутых целей проекта.
См. также: план управления службами.
Примечания
1 В дополнение к проектам планы управления могут быть подготовлены к программам, организациям или процессам, включая процесс управления портфелем.
2 ИИЭР 1058-1998 обеспечивает дополнительное разъяснение.
10.52 Предложение
ИСО/МЭК 15288:2008, подпункты 6.1.1.3, 6.1.2.2, 6.1.2.3
ИСО/МЭК 12207:2008, подпункты 6.1.2.2 b), B.3.2.1.2
Универсальный тип: описание
Предложение является информацией, подготовленной потенциальным поставщиком, поддерживать предложения договора, включая стоимость, график, отчеты риска, методологию для удовлетворения запроса предложений (RFP), опыта и возможностей, любые рекомендации адаптировать RFP или договор и подпись утверждения поставщика власти. Неофициально предложения могут быть подготовлены в организации относительно того, что касается повторного использования программного обеспечения.
10.53 Процедура испытаний качества
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.6.1, 6.1.1.3.6.2, 6.4.5.3.2.1, 7.1.6.3.1.4, 7.2.7.3.2.1
Универсальный тип: процедура
Документы процедуры испытаний качества (процедура приемки), такие как приемочный контроль и тестирование поставляемого продукта или услуги, которые будут проводиться, и условия, которые должны быть удовлетворены перед принятием. Процедура приемки первоначально подготовлена аквизитором, соответствующим плану закупок. Процедура испытаний качества обеспечивает ряд тестов так, чтобы каждое требование квалификации было удовлетворено для позиций программного обеспечения или системы. Это включает отображение требований к испытаниям качества и полных требований для выполнения тестирования квалификации, испытательных целей, испытательных критериев, испытательных конфигураций, приготовлений, пробные дела (вводы, шаги и результаты), ожидаемые результаты и аналитические процедуры после испытания.
10.54 Отчет об испытаниях качества
ИСО/МЭК 12207:2008, подпункты 7.1.7.3.1.1, 7.1.7.3.1.3, 7.2.7.3.2.1
Универсальный тип: отчет
Отчет испытаний качества указывает, что система была проверена на соответствие с каждым системным требованием, привела к ожидаемым результатам и подходит к управлению и поддержке. Это обеспечивает результаты каждых испытаний качества и заявляет, были ли все требования удовлетворены. Это включает системную идентификацию и обзор, требования квалификации и критерии, обзор результатов, идентификацию проверенных позиций и даты тестирования детализированных результатов, проблемы, с которыми сталкиваются, и объяснение для решений.
10.55 План управления качеством
ИСО/МЭК 15288:2008, подпункты 6.2.5.3, 6.3.1.3
ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.3, 6.2.5.3.1.5, 6.3.1.3, 7.2.3.3.1.3
Универсальный тип: план
План управления качеством (или план обеспечения качества), в соответствии с ИСО/МЭК 9001:2008 или другим стандартом качества, представляет подход для выполнения качественных аспектов программы, проекта, продукта или услуги. Это включает следующее:
a) проект или заданные уровни качества организации и качественные политики организации;
b) планы улучшения продукта или услуги;
c) планы оценки продукта и услуги с требованиями оценки, критериями, ответственностью и распределениями;
d) стандарты, методы, процедуры или инструменты, необходимые для управления качеством;
e) идентификацию требуемых записей качественных операций и задач, а также записей проблем и разрешений проблемы;
f) управление конфигурацией записей;
g) определенные обзоры, оценки и аудиты, которые будут выполнены, со ссылками на связанное тестирование, проверку, проблемную отчетность и процессы корректирующего действия;
h) оценку методов управления конфигурацией для системы или элементов конфигурации программного обеспечения и среды;
i) требуемую координацию операций обеспечения качества программного обеспечения с другими проектными операциями.
10.56 Политика управления качеством и процедура
ИСО/МЭК 12207:2008, подпункты 6.2.5.2, 6.2.5.3.1.1
ИСО/МЭК 15288:2008, подпункты 6.2.5.2, 6.2.5.3, 6.2.5.3.1.1
ИСО/МЭК 20000-2:2005, пункт 4.4.1
Универсальный тип: политика, процедура
Политика управления качеством и процедура (или процедура обеспечения качества) определяют структуру для установления и рассмотрения заданных уровней качества. Это объясняет, как заданные уровни качества будут встречены и выражают вклад частного лица во все имеющее отношение к качеству продукта или услуги. Качественная процедура детализирует, как качественные аспекты программы, продукт или услуга будут выполнены. Это включает процедуры для обзоров договора, проверок, оценок, обзоров и аудитов. Это обращается к процедурам для задач тестирования, проблемной отчетности, совершенствования процесса и корректирующего действия, как включено в управление качеством, обеспечение качества программного обеспечения, аудит программного обеспечения, проверку и процедуры совершенствования процесса.
Примечание - политика управления качеством может быть включена в процедуры планового управления или управления качеством или в отдельный набор политик.
10.57 План выпуска
ИСО/МЭК 12207:2008, подпункты 6.4.10.3.5.2, 6.4.11.3.2.1
ИСО/МЭК 20000-1:2005, раздел 10.1
ИСО/МЭК 20000-2:2005, пункты 10.1.1, 10.1.3, 10.1.8
Универсальный тип: план
План выпуска (или план миграции, или план) представляет, как система, услуга или программный продукт или выпуск программного обеспечения будут переданы новой среде с датами выпуска. Это включает результаты, включая обновления к связанному SLA, операционным процедурам и пользовательской документации. Это ссылается на связанные запросы на изменение, идентифицированные элементы конфигурации, известные ошибки и проблемы. Это должно включать идентифицированные риски, потенциальные проблемы и предложенные резолюции. Это покрывает то, как выпуск разрешается, планируется, координируется и отслеживается. План миграции включает описание результатов, зависимостей и запланированных дат, ожидаемой конфигурации целевой среды во время миграции, планов возврата или восстановления, процедур проверки и процедур приемки и коммуникации и обучения клиенту и техническому персоналу. Это должно включать планирование списывания замененных систем или услуг.
См. также: план управления конфигурацией и политика (выпускают план управления и политику), процедура управления конфигурацией (процедура выпуска).
10.58 Запрос предложений (RFP)
ИСО/МЭК 15288:2008, подпункт 6.1.1.3
ИСО/МЭК 12207:2008, пункты 4.24, 4.36, подпункты 6.1.1.3.1.10, 6.1.1.3.1.11, 6.1.1.3.2.1, 6.1.2.2, 6.1.2.3.2.1, 6.1.2.3.2.3, 6.4.1.3.2.1
Универсальный тип: запрос
Запрос предложений (RFP) является запросом информации аквизитора и обязательствами, необходимыми от поставщика, которые требуются, чтобы быть включенными в предложение потенциального поставщика. Это заявляет о своем намерении потенциальным участникам торгов получить указанную систему, программный продукт или услугу программного обеспечения. Это включает следующее:
a) системные требования заинтересованных сторон;
b) отчет объема;
c) инструкции участника торгов;
d) объем задач, на которые сошлются в проекте договора;
e) поставляемый список продукта;
f) условия;
g) этапы договора (например, обзор и аудит прогресса поставщика);
h) управление субподрядным договором;
i) процедурные и технические ограничения (например, среду назначения);
j) процессы поддержки и исполняющие их организации, включая ответственность (если не поставщик), права поставщиков в их предложениях, определяющие подход к каждому определенному процессу.
Это может обрисовать в общих чертах критерии отбора поставщика.
Примечание - Фактическое содержание зависит от правовой среды. Также известный как требования приобретения документ о приобретении, требование предложений (CFP), приглашение на участие в тендере (ITT), запрос для тендера.
10.59 Запрос ресурса
ИСО/МЭК 15288:2008, подпункты 6.3.1.3 d), 6.3.2.3 b
ИСО/МЭК 12207:2008, подпункт 6.3.1.3.3.2
Универсальный тип: запрос
Запрос о ресурсах является результатом проекта или сервисного планирования и направлен к управлению тому, кто может направить ресурсы и при необходимости утвердить изменение договора.
10.60 План повторного использования
ИСО/МЭК 12207:2008, подпункты 7.3.3.1, 7.3.3.3.2.1, 7.3.3.3.3.3, 7.3.3.3.4.1, 7.3.3.3.4.2, 7.3.3.3.4.3, 7.3.3.3.5.2
Универсальный тип: план
План повторного использования представляет, как операции будут проводиться для поддержки повторного использования систем или программных ресурсов и связанных документов. Это определяет стратегию повторного использования, области, где повторным использованием будут управлять, и подход внедрения, включая поддержку инфраструктуры.
10.61 Протоколы обзора
ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.15, 6.4.10.3.5.6, 7.2.6.2, 7.2.6.3.1.5
ИСО/МЭК 20000-1:2005, подраздел 7.2
ИСО/МЭК 20000-2:2005, пункт 7.2.1
Универсальный тип: отчет
Протоколы обзора (или протоколы совместного рассмотрения, или сервисные протоколы обзора) обеспечивают отчет об обзоре, проводимом аквизитором и поставщиком. Протоколы включают посетителей, программу рассматриваемого продукта или услуги, пункты входа и выхода для обзора, основных тем обсуждения, предположений, материала презентации, утверждений, намеченных мероприятий и их статуса и критериев закрытия. Протоколы документируют оценку статуса и соответствие продуктов и услуг и операции и состояние графика. Протоколы включают найденные проблемы и методы их решения или ожидаемую резолюцию.
10.62 Запрос действия риска
ИСО/МЭК 15288:2008, подпункт 6.3.4.3
ИСО/МЭК 12207:2008, подпункты 6.3.4.3.2.3, 6.3.4.3.4.1
Универсальный тип: запрос
Запрос действия риска подан от организации управления проектами или управления службами до заинтересованных сторон. Это включает рекомендуемые альтернативы для обработки риска.
10.63 Политика в области управления рисками и план
ИСО/МЭК 15288:2008, подпункт 6.3.4.3
ИСО/МЭК 12207:2008, подпункты 6.3.4.3.1.1, 6.3.4.3.1.2, 6.3.4.3.2.1
Универсальный тип: план, политика
Политика в области управления рисками и план представляют условия, при которых будут выполнены управление рисками и контекст управления рисками, такие как управление и технические цели, предположения и ограничения. Это определяет подход к идентификации, оценке, обработке (включая предотвращение, смягчение и планы непредвиденных обстоятельств) и контроль рисков, а также подход для регистрации рисков, создания и поддержания профилей рисков (записи) и отчетность о статусе риска. Это устанавливает категории риска и критерии оценки риска.
Примечание - ИСО/МЭК 16085:2006 "Системное проектирование и разработка программного обеспечения. Процессы жизненного цикла. Управление рисками" обеспечивает дополнительное разъяснение.
10.64 Сервисная доступность и план непрерывности
ИСО/МЭК 20000-1:2005, подраздел 6.3
ИСО/МЭК 20000-2:2005, подразделы 6.1.2, 6.3.4
Универсальный тип: план
Сервисный план доступности и непрерывности описывает положения для предоставления доступа к услугам, доступным в случае отказа места или системного компонента. Сервисный план непрерывности должен быть доступен в печатных средах всем затронутым. Копии сервисного плана непрерывности и применимых соглашений и договоров должны быть доступны в безопасном удаленном расположении, где планируется, чтобы альтернативная услуга была предоставлена. Это включает следующее:
a) требования доступности для услуги, как указано в соглашениях об уровне обслуживания;
b) влияние на бизнес сервисной недоступности на различное время и приоритетов для восстановления услуг;
c) процедуры и альтернативные средние значения предоставления услуги (такие как бумажные записи), в то время как автоматизированные системы восстанавливаются;
d) роли и обязанности для системного восстановления, включая точки контакта людей, разрешенных для вызова по планам непредвиденных обстоятельств и актам в чрезвычайных ситуациях;
e) процедуры для восстановления услуги;
f) процедуры для тестирования плана непрерывности;
g) предварительные операции для подготовки к сервисным сбоям, таким как системные резервные копии вне места работы или соглашения с провайдерами экстренной службы.
10.65 Сервисный каталог
ИСО/МЭК 20000-2:2005, пункты 6.1.1, 7.3.3
Универсальный тип: описание
Сервисный каталог описывает услуги информационных технологий, доступные клиентам. Для каждой услуги это определяет услугу, идентифицирует ответственных за то, что предоставили услугу, включает график сервисной доступности и недоступности, положения управления доступом и точек контакта для требования помощи или отчетности об инцидентах, и суммирует уровни обслуживания, как далее указано в соглашении об уровне обслуживания (SLA).
10.66 Соглашение об уровне обслуживания (SLA)
ИСО/МЭК 20000-1:2005, подразделы 2.13, 3.2, раздел 5, подразделы 6.1, 7.3
ИСО/МЭК 20000-2:2005, пункты 6.1.2, 10.1.1, 10.1.7
Универсальный тип: спецификация
Соглашение об уровне обслуживания (SLA) между поставщиком услуг и клиентом, должно быть разрешено сервисным поставщиком и аквизитором. Это указывает следующее:
a) требования для услуги;
b) объем и лимиты рабочей нагрузки (верхний и ниже);
c) ответственность поставщика и клиента;
d) подробные данные сервисной доступности (часы услуги), на которые можно сослаться в сервисном каталоге;
e) процедуры для инцидента и проблемного управления, роста, уведомлений и жалоб;
f) меры и критерии приемки, такие как производительность, доступность, сервисный период, оператор и скорость отклика обслуживания;
g) процесс связи для периодической отчетности о достигнутом уровне обслуживания клиенту.
Это может включать цели вне минимального допустимого уровня услуги.
10.67 План управления службами
ИСО/МЭК 12207:2008, пункт 6.4.9.3.1.1
ИСО/МЭК 20000-1:2005, подразделы 3.1, 3.2, 4.1, 4.2, пункты 4.4.1, 4.4.3, раздел 5
ИСО/МЭК 20000-2:2005, подраздел 3.2, пункты 3.3.2, 3.3.3, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.4.1, 6.2.1
Универсальный тип: план
План управления службами (или операционный план) представляет, как обслуживать операции поставщика услуг и как будут ими управлять, выполнять, измерять для успешного предоставления услуги. Это идентифицирует следующее:
a) политики, цели и требования для услуги вместе с ожидаемыми результатами;
b) планы по ресурсам и преемственность планируют укомплектовать услугу;
c) организации, вовлеченные в реализацию, работу и поддержание услуги, и план управления службами и отношениями всех, кто находится во взаимодействии, включая поставщиков;
d) координация интерфейсов среди связанных услуг, процессов и операций;
e) планы относительно отчетов, обзоров и связей с заинтересованными сторонами и гарантией удовлетворенности клиентов.
План управления службами может быть подготовлен к новому, существующему, измененному, улучшенному сервису.
См. также: план внедрения, план улучшения, план управления рисками.
10.68 Сервисный отчет
ИСО/МЭК 12207:2008, подпункт 6.2.5.3.1.4
ИСО/МЭК 20000-1:2005, подраздел 6.2
ИСО/МЭК 20000-2:2005, подраздел 6.2, пункты 6.2.1, 6.2.2, 6.2.3, 7.3.2
Универсальный тип: отчет
Сервисный отчет сообщает управлению или клиентам об уровне предоставленной услуги. Он сообщает о результатах и обзоре производительности поставщиком против согласованных целей уровня обслуживания и других договорных обязательств. Он периодически выпускается после крупных событий и изменений в услуге. Это оценивает производительность против целей уровня обслуживания в SLA, включая исследования удовлетворенности клиентов. Это включает резюме контроля результатов, трендов и исторического анализа и зарегистрированных сервисных улучшений. Это предоставляет информацию о несоответствии, намеченных мероприятиях, корректирующих действиях и действия обработки риска. Это должно включать фактический объем рабочей нагрузки и запланированную рабочую нагрузку и консультировать по вопросам ожидаемых проблем.
См. также: отчет об оценке, контроле и отчет об управлении, отчет о ходе работ.
10.69 Описание архитектуры программного обеспечения
ИСО/МЭК 12207:2008, подпункты 6.4.3.2, 6.4.3.3.1.1, 7.1.1.2, 7.1.3.2, 7.1.3.3.1, 7.1.3.3.1.1, 7.3.1.2, 7.3.1.3.3.1, 7.3.1.3.3.3.
Универсальный тип: описание
Описание архитектуры программного обеспечения включает следующее:
a) фундаментальную концепцию программного обеспечения для интересуемой системы с точки зрения ее цели, качества программного обеспечения (такие как производительность, удобство пользования и безопасность), ограничения и решения;
b) заинтересованные стороны архитектуры и связанные с архитектурой проблемы заинтересованных сторон. Среди ключевых заинтересованных сторон - клиент, пользователи, разработчики, аквизиторы, поставщики и специалисты по обслуживанию;
c) определения точек зрения, чтобы задокументировать процедуры для создания, интерпретации, анализа и оценки архитектурных данных;
d) одно или более представлений системы. Каждое представление архитектуры является представлением полной системы с точки зрения одной или более проблем для ее заинтересованных сторон.
Описание архитектуры программного обеспечения должно сделать следующее:
a) обеспечить объяснение для архитектурных решений;
b) установить принципы для разделения программного обеспечения в элементы дизайна;
c) записать важные свойства и отношения среди этих элементов способом, соответствующим структуре перечня работ по операциям;
d) продемонстрировать, что архитектурно значительные требования удовлетворены и распределены по элементам дизайна;
e) обеспечить основание для спецификации требований к программному обеспечению и проектировать обработку.
Описание архитектуры программного обеспечения может представить следующее:
a) понятие работы с точки зрения его элементов;
b) модель области или справочную архитектуру для семьи или системы программного обеспечения.
См. также: описание системы архитектуры.
Примечание - Описание архитектуры программного обеспечения можно рассмотреть как спецификацию для проектирования программного обеспечения. Для большей информации об описании архитектуры смотри ИСО/МЭК 42010.
10.70 Описание проектирования программного обеспечения
ИСО/МЭК 12207:2008, подпункты 6.4.10.2, 6.4.10.3.3.1, 7.1.1.3.1.2, 7.1.4.3.1.1, 7.2.2.3.5.1, 7.3.1.3.3.3
Универсальный тип: описание
Описание проектирования программного обеспечения представляет характеристики одной или более систем, подсистем, позиций программного обеспечения или других системных компонентов и их интерфейсов. Это включает следующее:
a) идентификацию внешних интерфейсов, компонентов программного обеспечения, единиц программного обеспечения и других интерфейсов;
b) распределение требований позиции программного обеспечения по компонентам программного обеспечения, далее усовершенствованным по мере необходимости для упрощения подробного дизайна;
c) описание позиций (системы, элементы конфигурации, пользователи, аппаратные средства, программное обеспечение и т.д.), которые должны общаться с другими позициями, чтобы передать и получить данные, инструкции или информацию.
Это включает следующее:
a) публикуемость;
d) понятие выполнения, включая поток данных и поток управления;
e) соображения безопасности;
f) элементы повторного использования;
g) обработку ошибок.
Это должно включать следующее:
a) спецификацию протоколов;
b) разделение программного обеспечения в предприятия дизайна и описания важных свойств и отношений среди тех предприятий.
Описание проектирования программного обеспечения низкого уровня или описание интерфейса дизайна позиции программного обеспечения, включая программное обеспечение, проектные решения всей позиции, дизайн архитектуры позиции программного обеспечения и детальное проектирование, должны были реализовать программное обеспечение. Низкоуровневое описание разрешает разработку программного обеспечения или выбор позиций для повторного использования без потребности в дополнительной информации. Это обеспечивает видимость в дизайне и информацию, необходимую для повторного использования программного обеспечения и поддержки. Это используется в качестве основания для реализации программного обеспечения.
Это включает следующее:
a) подробное описание структуры компонентов программного обеспечения (к уровню единицы программного обеспечения, который будет закодирован, собран и проверен);
b) распределение компонентных требований программного обеспечения по позициям программного обеспечения, далее усовершенствованным по мере необходимости для упрощения подробного дизайна и отслеживаемости от каждой позиции программного обеспечения до требований позиции программного обеспечения, распределенных по нему;
c) проектные решения программного обеспечения всей позиции о поведенческом дизайне позиции программного обеспечения (как это ведет себя с точки зрения пользователя, в соответствии его требованиями, игнорируя внутреннее внедрение);
d) решения, влияющие на выбор и дизайн позиций программного обеспечения, составляющих позицию программного обеспечения;
e) детальное проектирование для внешних интерфейсов компонентов программного обеспечения к позиции программного обеспечения, между связанными компонентами программного обеспечения и между связанными единицами программного обеспечения;
f) интерфейсные характеристики единицы одной или более систем, подсистем, позиций аппаратных средств, позиций программного обеспечения, ручных операций или других системных компонентов.
Это должно включать следующее:
a) описания размера, частоты или других характеристик элементов данных;
b) ссылка на известные ограничения синхронизации;
c) спецификацию протоколов.
См. также: описание системы элемента.
Примечание - ИИЭР 1016-2008 обеспечивает дополнительное руководство.
10.71 Спецификация требований к программному обеспечению
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.1.2, 6.1.1.3.1.7, 6.1.1.3.1.8, 6.1.1.3.1.11, 6.4.11.2, 7.1.2.2, 7.1.2.3.1.1, 7.1.3.3.1.5
Универсальный тип: спецификация
Спецификация требований к программному обеспечению включает следующее:
a) предшествование и критичность требований;
b) описание методов и инструментов, раньше определяло отслеживаемость от системных требований до системной архитектуры, требований к программному обеспечению, архитектуры программного обеспечения, и позиций программного обеспечения и единиц;
c) предположения продукта и зависимости;
d) ссылки на стандарты дизайна и тестирования и процедуры;
e) функции продукта и система функциональных требований;
f) бизнес-, организационные и пользовательские системные требования;
g) разработка человеческих факторов (эргономика) требования;
h) системные требования критичности;
i) безопасность и показатели качества и системные требования к качеству;
j) требования для внутренних и внешних взаимодействий с системой, аппаратными средствами, коммуникациями, человеческие пользователи и другое программное обеспечение;
k) ограничения дизайна и требования системного проектирования;
l) системное тестирование и требования квалификации;
m) требования принятия;
n) требования адаптации места;
o) требования для пользовательской документации и обучения;
p) требования для упаковки, установки, операций, обновления продукта и обслуживания.
См. также: спецификация системных требований.
Примечание - ИИЭР 830-1998 ИИЭР обеспечивает дополнительное руководство.
10.72 Описание единицы программного обеспечения
ИСО/МЭК 12207:2008, подпункт 7.1.5.3.1.1
Универсальный тип: описание
Описание единицы программного обеспечения представляет объект программного обеспечения или код. Это может быть предоставлено вложенной документацией или комментариями в коде.
10.73 Процедура тестирования единицы программного обеспечения
ИСО/МЭК 12207:2008, подпункты 6.4.10.3.3.2, 7.1.4.3.1.5, 7.1.5.3.1.1
Универсальный тип: процедура
Процедура тестирования единицы программного обеспечения включает испытательные шаги, которые будут использоваться для тестирования каждой единицы программного обеспечения. Это включает испытательный график единицы программного обеспечения и испытательный подход для выделения единиц программного обеспечения к лимитам требований. Это может включать спецификации пробного дела для документирования фактических значений, используемых для ввода, вместе с ожидаемыми результатами. Это включает положения для разрешения проблемы.
10.74 Единица программного обеспечения проверяет отчет
ИСО/МЭК 12207:2008, подпункты 6.4.10.3.3.2, 7.1.5.3.1.2
Универсальный тип: отчет
Доклад теста единицы программного обеспечения обеспечивает результаты тестирования компонентов программного обеспечения (единицы, позиции) и определяет, были ли удовлетворены все применимые требования. Это включает идентификацию позиции, дату тестирования испытательных требований и критериев, испытательный идентификатор, обзор результатов, детализированные результаты, проблемы, с которыми сталкиваются, и объяснение для принятия решений.
10.75 Процедура управления поставщиками
ИСО/МЭК 20000-1:2005, подраздел 7.2
ИСО/МЭК 20000-2:2005, пункты 7.3.1, 7.3.3, 7.3.4
Универсальный тип: процедура
Процедура управления поставщиками объясняет, как управлять поставщиком для обеспечения поставки предоставленных услуг и поставок. Это включает коммуникацию, отчетность и процессы административного управления и процедуру для решения споров по контракту. Это включает процесс для окончания соглашения и передачи новому поставщику.
См. также: план управления проектом.
10.76 Процедура отбора поставщика
ИСО/МЭК 12207:2008, подпункт 6.1.1.3.3.1
Универсальный тип: процедура
Процедура отбора поставщика объясняет, как выбрать поставщика, включая весовой коэффициент критериев и требований оценки предложения.
10.77 Описание системы архитектуры
ИСО/МЭК 15288:2008, подпункты 6.3.1.3, 6.4.3.1, 6.4.3.2, 6.4.3.3
Универсальный тип: описание
Описание системы архитектуры включает следующее:
a) фундаментальную концепцию системы интереса с точки зрения ее цели, системные качества (такие как выполнимость, производительность, безопасность и возможность взаимодействия) ограничения и проектные решения и объяснение;
b) идентификацию заинтересованных сторон архитектуры и связанных с архитектурой проблем заинтересованных сторон. Среди ключевых заинтересованных сторон - клиент, аквизиторы, контрольные устройства, поставщики, специалисты по обслуживанию и операторы;
c) определения точек зрения, задокументированные процедуры для создания, интерпретации, анализа и оценки архитектурных данных;
d) одно или более представлений системы. Каждое архитектурное представление является представлением полной системы с точки зрения одной или более системных проблем для ее заинтересованных сторон.
Описание системы архитектуры должно сделать следующее:
a) установить принципы для разделения системы в системные элементы (такие как аппаратные средства, программное обеспечение и операции);
b) записать важные свойства и отношения среди элементов способом, соответствующим структуре перечня работ по операциям;
c) продемонстрировать, что архитектурно значительные требования удовлетворены и распределены для служения основой для спецификации требований и обработки дизайна.
Описание системы архитектуры может сделать следующее:
a) представить концепцию системы работы с точки зрения системных элементов;
b) представить модель области или справочную архитектуру для семьи или системы.
См. также: описание архитектуры программного обеспечения.
Примечание - Описание архитектуры систем можно рассмотреть как спецификацию для системного проектирования. Для получения дополнительной информации об описании архитектуры смотри ИСО/МЭК 42010.
10.78 Описание системы элемента
ИСО/МЭК 15288:2008, подпункт 6.4.3.2
Универсальный тип: описание
Описание системы элемента применяет описание системы архитектуры и описание проектирования программного обеспечения к низкоуровневым системным элементам конфигурации и элементам. Описание системы элемента на уровне детализации для разрешения дизайна, внедрения и теста. Системные описания элемента должны быть рассмотрены, чтобы гарантировать последовательность архитектуры интегрированной системы.
10.79 Спецификация системных требований
ИСО/МЭК 12207:2008, подпункты 6.2.2.2, 6.2.2.3.1.1, 6.2.2.3.2.1, 6.4.1.2, 6.4.1.3.2, 6.4.2.2, 6.4.2.3.1.1
ИСО/МЭК 15288:2008, подпункты 6.1.1.3, 6.2.2.2, 6.3.1.3, 6.4.1.3, 6.4.2.2, 6.4.2.3
ИСО/МЭК 20000-2:2005, пункты 9.1.2, 9.1.5, 10.1.7
Универсальный тип: спецификация
Примечание - Эта информационная позиция может быть разделена на спецификацию требований заинтересованной стороны и спецификацию системных требований.
В предварительном этапе системные требования включают потребности бизнеса, организации и пользователя (заинтересованной стороны) (основание требований заинтересованной стороны). Требования заинтересованной стороны определяют систему, которая может предоставить услуги, необходимые пользователям и другим заинтересованным сторонам в определенной среде, включая их потребности, желания, ожидания и их существенные ограничения, такие как последствия существующих соглашений, управленческих решений и технических решений. Требования заинтересованной стороны определяют меры эффективности для ключевых потребностей.
Спецификация системных требований включает следующее:
a) технические спецификации для выбранной системы - интереса;
b) спецификации удобства пользования для предусматриваемого взаимодействия человеческой системы;
c) функции системного уровня;
d) требования безопасности;
e) критические максимальные и минимальные ограничения производительности;
f) ссылки на связанные стандарты системного проектирования и тестирования.
Это может включать требования для инфраструктуры и системы предоставления возможности для организации, включая ресурсы и инструменты.
Примечания
1 Требования могут быть представлены при помощи случаев использования и сценариев.
См. также: понятие операций, спецификации требований к программному обеспечению.
2 ИСО/МЭК/ИИЭР 12207 отсылает к спецификации системных требований, когда программное обеспечение считается системой. ИИЭР 1233-1998 (R2002) обеспечивает дополнительное разъяснение.
10.80 Учебная документация
ИСО/МЭК 12207:2008, подпункты 6.2.4.3, B.3.4.1.2
ИСО/МЭК 15288:2008, подпункт 6.2.4.3
ИСО/МЭК 20000-2:2005, пункт 8.3.10
Универсальный тип: процедура
Учебная документация включает учебные руководства, обучающие программы и материал презентации, используемый в обеспечении инструкции. Это может включать список материалов, которые необходимо разработать и реализовать, учебные руководства и презентации.
10.81 Учебный план
ИСО/МЭК 12207:2008, подпункты 6.2.4.3.2.1, 6.2.4.3.2.3, 6.2.4.3.4.1
ИСО/МЭК 15288:2008, подпункт 6.2.4.3
ИСО/МЭК 20000-2:2005, пункты 3.3.2 c), 3.3.3 f), 5.1.2
Универсальный тип: план
Учебный план (или профессиональный план развития) представляет, как знанием будут управлять, и сообщать, как навыки будут развиты. Это включает отчет об обучении, которое будет подготовлено, проведено и оценено. Это идентифицирует требуемые результаты обучения, требуемые ресурсы, управление и технические навыки штата и категории необходимости персонала и обеспечения обучения, типы и уровни обучения и знания для удовлетворения потребностей персонала, проектной команды или организации, интеллектуальные активы, темы или содержание курса, график реализации и подход оценки.
10.82 Пользовательская документация
ИСО/МЭК 15288:2008, подпункт 6.4.9.3
ИСО/МЭК 12207:2008, подпункты 6.1.1.3.1.7 b), 6.4.9.3.3.1, 6.4.9.3.4.1, 6.4.10.2, 7.1.1.3.1.2, 7.1.3.3.1.4, 7.1.4.3.1.4, 7.1.5.3.1.3, 7.1.6.3.1.3, 7.1.7.3.1.2, 7.2.7.3.2.1
ИСО/МЭК 20000-2:2005, подпункты 8.3.9, 8.3.10, 10.1.3, 10.1.5, 10.1.7, 10.1.8
Универсальный тип: процедура
Пользовательская документация обеспечивает пользовательские процедуры для выполнения указанных задач при помощи системы или программного обеспечения. Это может включать внедрение, интеграцию (собрание), установку и демонтаж, работу и процедуры ухода и размещения.
Пользовательская документация для систем или программное обеспечение включают следующее:
a) краткое описание надлежащего использования системы (понятие операций);
b) как следует поступать для идентифицированного риска, предупреждений, предостережений и примечаний с корректирующими действиями;
c) поставляемые и требуемые ресурсы и оперативную обстановку (аппаратные средства/программная платформа);
d) пользовательские процедуры (инструкции) на пронумерованных шагах для выполнения указанных задач, используемые (управляют) системой;
e) поиск и устранение неисправностей и процедуры коррекции ошибок;
f) доступность проблемной отчетности и помощи.
Пользовательская документация программного обеспечения обеспечивает процедуры, чтобы получить доступ и выйти из программного обеспечения. Это должно перечислить и объяснить команды программного обеспечения и предоставленные системой сообщения пользователю.
Примечание - ИСО/МЭК 26514:2008 обеспечивает требования и руководство на процессе, содержании, структуре и форматирует для пользовательской документации программное обеспечение.
10.83 Пользовательское уведомление
ИСО/МЭК 12207:2008, подпункты 6.4.10.3.5.3, 6.4.10.3.5.5, 6.4.11.3.2.2, 7.3.2.3.3.8
Универсальный тип: отчет
Пользовательское уведомление (или уведомление клиента, или информация о версии) объявляет, что система, позиция программного обеспечения или актив собираются быть или были перемещены, изменены или удалены. Это обеспечивает объяснение и график для изменения, описывает новую среду и идентифицирует опционы поддержки или положения размещения или архивации для отставных инфраструктур, систем или программного обеспечения. Пользовательские уведомления могут также быть отправлены бизнес-штату и поставщику услуг.
10.84 План проверки
ИСО/МЭК 15288:2008, подпункт 6.4.8.3
ИСО/МЭК 12207:2008, подпункт 7.2.5.3.1.4
Универсальный тип: план
План проверки представляет стратегию проверки: как процесс проверки будет проводиться, включая позиции, подвергающиеся проверке, критерии проверки, задачи проверки, ресурсы, ответственность, инструменты и график и процедуры для записи и отчетности о результатах проверки. Это идентифицирует методы, используемые для проверки, такие как анализ, оценка, обзор, проверка, оценка и тестирование продуктов, интерфейсов и процессов, которые произвели продукты. Это указывает организационные отношения и степени независимости между операциями проверки и опытно-конструкторскими разработками. Это может идентифицировать уровень целостности программного обеспечения и схему.
Примечание - ИИЭР 829-2008 обеспечивает дополнительную подробность.
10.85 Отчет о проверке
ИСО/МЭК 15288:2008, подпункт 6.4.8.3
ИСО/МЭК 12207:2008, подпункт 7.2.5.3.1.4 d)
Универсальный тип: отчет
Отчет о проверке обеспечивает результаты и заключения системы или проверки программного обеспечения на позиции программного обеспечения, системы или подсистемы. Это позволяет аквизитору оценить проверку и ее результаты. Это включает системную идентификацию и обзор, требования проверки и критерии, обзор результатов, идентификацию утвержденных позиций и даты проверки, детализированных результатов, проблемы, с которыми сталкиваются, и объяснение для решений.
10.86 Спецификация теста проверки
ИСО/МЭК 12207:2008, подпункты 7.2.5.3.2.1, 7.2.5.3.2.2, 7.2.7.3.2.1
Универсальный тип: спецификация
Спецификация теста проверки детализирует условия для тестирования проверки, включая среду, цели, сценарии или пробные дела, критерии приемки и ожидаемые результаты, которые утвердят это, пользователи могут успешно достигнуть своих намеченных задач при помощи системы или программного обеспечения.
10.87 План проверки
ИСО/МЭК 15288:2008, подпункт 6.4.6.3
ИСО/МЭК 12207:2008, подпункт 7.2.4.3.1.5, 7.2.4.3.1.6
Универсальный тип: план
План проверки (или интеграция и испытательный план) может также обратиться к единице, системе и испытаниям качества. Это позволяет провести оценку соответствия планирования тестирования. Это включает:
a) стратегию проверки и как процесс проверки будет проводиться;
b) операции жизненного цикла, систему и программные продукты подвергают проверке;
c) требуемые задачи проверки для каждой деятельности жизненного цикла и продукта;
d) организационные отношения и степень независимости между опытно-конструкторскими разработками и операциями проверки;
e) предварительные испытательные требования и график для интеграции программного обеспечения;
f) объем, подход, ресурсы и график операций тестирования. Как события около графика для каждого испытательного типа испытательный график должен быть обновлен для обеспечения более подробной информации;
g) методы, используемые для проверки, такие как анализ, оценка, обзор, проверка, оценка и тестирование продуктов и процессов, которые произвели продукты;
h) испытательные цели, отображение тестов к удовлетворенным требованиям;
i) список применимых единиц программного обеспечения, компонентов программного обеспечения и ранее интегрированных позиций программного обеспечения для каждой задачи интеграции программного обеспечения и теста;
j) позиции, которые будут проверены, особенности, которые будут проверены, задачи тестирования, которые будут выполнены;
k) возложенные обязанности для выполнения процедур тестирования, включая расположения и организации для менеджера по тесту, тестеров, обеспечения качества, управления конфигурацией, проверяют оценку, отчетность и участие поставщика в тестировании;
l) описание условий испытаний, инструментов тестирования и аппаратного и программного обеспечения поддержки;
m) испытательные приготовления и пробные случаи, которые будут сконфигурированы или построены;
n) списки данных, которые будут использоваться во время тестирования, для каждого пробного случая;
o) последовательность событий (последовательность выполнения процедур тестирования), процедуры/шаги для выполнения теста (например, предварительные требования процедуры, испытательная установка, проверка выполнения, аналитические шаги после испытания, инструкции по завершению);
p) ожидаемые результаты испытаний (выходные данные) для каждого испытательного шага;
q) как результаты испытательного выполнения будут зарегистрированы, чтобы показать, что требования продукта или услуги были удовлетворены;
r) процедура для направления проверки сообщается тем, кто нуждается в них;
s) риски, связанные с планом.
Это может включать следующее:
a) уровень целостности программного обеспечения и схему;
b) оставшиеся недостатки, ограничения или оговорки в системе;
c) влияние условий испытаний;
d) рекомендуемые улучшения дизайна, работы или тестирования программного обеспечения.
Примечание - ИИЭР 829-2008 стандартов ИИЭР для программного обеспечения и системной испытательной документации обеспечивает дополнительную подробность.
10.88 Отчет о проверке
ИСО/МЭК 15288:2008, подпункт 6.4.6.3 b)
ИСО/МЭК 12207:2008, подпункт 7.2.4.3.1.5
Универсальный тип: отчет
Отчет о проверке обеспечивает результаты и заключения проверки на позиции программного обеспечения, системы или подсистемы. Это позволяет аквизитору оценить проверку и ее результаты. Это включает системную идентификацию и обзор, требования проверки и критерии, обзор результатов, идентификацию проверенных позиций и даты проверки детализированных результатов, проблемы, с которыми сталкиваются, и объяснение для решений.
См. также: отчет об оценке.
Подписаться на обновления