Международный iso/iec стандарт 12207

Вид материала

Документы

Содержание В.4 Вопросы адаптации и применения Приложение С (информативное) Руководство по процессам и организациям С.1 Процессы с различных ключевых позиций. С.2 Процессы, организации и отношения. Приложение Д (информационное) Библиография

Подобный материал:

• Information technology. Guide for the application of gost r iso/iec 12207 (Software, 841.1kb.
• Політика інформаційної безпеки ат «УкрСиббанк» (зовнішня), 61.8kb.
• Разработан Международной организацией по стандартизации (iso) и Международной электротехнической, 136.47kb.
• Международная организация по стандартизации (iso) является всемирной федерацией национальных, 247.41kb.
• Выпуск №16, 1000kb.
• Заявка на проведение работ по стандарту iso/iec 27001, 74.59kb.
• Iso 9001 Сертификат iso 9001, 23.99kb.
• Госстандарт Республики Беларусь идёт навстречу этой тенденции и осуществляет переводы, 70.53kb.
• Приложение 1 Конференция «Управление жизненным циклом. Системная инженерия» Москва,, 19.35kb.
• Организация это систематизированное сознательное объединение действий людей преследующих, 60.68kb.

В.4 Вопросы адаптации и применения

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

Организационные работы. Определяется, какие из организационных работ уместны и применимы: работы, связанные с компьютерными языками, сохранностью и безопасностью, требования к резерву аппаратуры и управление риском. Следует сохранить пункты данного Международного Стандарта, относящиеся к этим организационным службам.

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

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

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

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

Работы (этапы) жизненного цикла системы. Определяется, какая из текущих служб жизненного цикла системы уместна и применима: инициация проекта покупателя, разработка поставщика и сопровождение. Некоторые сценарии:

Покупатель инициирует или определяет требования к системе. Изучается выполнимость и устанавливаются прототипные требования и конструкция. Может быть разработан программный код для прототипов, который может использоваться, а может и нет в дальнейшем, при разработке программных продуктов в соответствии с контрактом. Могут быть разработаны требования к системе и предварительные требования к программному обеспечению. В этих случаях Процесс Разработки (5.3) может быть использован скорее как руководство, чем как требование; может не потребоваться строгое отношение к квалификации и оценке; и могут не потребоваться совместные наблюдения и ревизии.

Разработчик производит программный продукт в соответствии с контрактом. В этом случае требования к Процессу Разработки (5.3) следует рассматривать во время адаптации.

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

Характеристики Уровня Системы. Определяется, какие из характеристик уровня системы уместны и применимы: количество элементов программного обеспечения, типы, размер и критичность программных продуктов и технические риски. Если программный продукт имеет много программных элементов, компонентов и единиц, то Процесс Разработки (5.3) следует тщательно адаптировать к каждому программному элементу. Следует рассмотреть все требования к интерфейсу и интеграции. Определяется, какие типы программных продуктов включены, так как различные типы программных продуктов могут требовать различных решений по адаптации. Некоторые примеры:

а) Новая разработка. Должны быть рассмотрены все требования, особенно к Процессу Разработки (5.3).

b) Использование программного продукта "с полки" "как есть". Весь Процесс разработки может быть излишним. Должны быть оценены выполнение, документация, присваивание права собственности, использование, гарантийные и лицензионные права и дальнейшая поддержка, относящиеся к программному продукту.

с) Модификация программного продукта "с полки". Документации может не быть в наличии. В зависимости от критичности и ожидаемых дальнейших изменений, Процесс Разработки (5.3) следует реализовать как Процесс Сопровождения (5.5). Должны быть оценены выполнение, документация, присваивание, право собственности, использование, гарантийные и лицензионные права и дальнейшая поддержка, относящиеся к программному продукту.

d) Программный или микропрограммный продукт встроен или присоединен к системе. Так как такой программный продукт является частью большой системы, то следует рассматривать службы Процесса Разработки (5.3), относящиеся к системе. В службах, относящихся к системе, необходимо выбрать только один из глаголов: "осуществлять" или "поддерживать". Если программный или микропрограммный продукт, скорее всего, не будет модифицироваться в дальнейшем, то следует тщательно исследовать размер документации.

e) Отдельный программный продукт. Так как такой программный продукт не является частью системы, то не требуется рассматривать службы Процесса Разработки (5.3), относящиеся к системе. Следует тщательно исследовать потребности в документации, особенно для поддержки.

f) Программный продукт, не предназначенный для поставки. Так как никакие его элементы не должны покупаться, поставляться или разрабатываться, то не следует рассматривать никакие положения данного Международного Стандарта, исключая 5.3.1.5 в Процессе Разработки (5.3). Тем не менее, если покупатель решает купить часть такого программного продукта для дальнейшего применения и поддержки, то этот продукт следует трактовать как в вышеперечисленных случаях b) или c).

Другие рассмотрения.

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

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

Приложение С (информативное) Руководство по процессам и организациям

Это приложение, для лучшего понимания, представляет обсуждение процессов, организаций и их отношений с точек зрения (позиций) основных субъектов использования программного обеспечения.

С.1 Процессы с различных ключевых позиций.

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

На рисунке С.1 изображены процессы жизненного цикла программного обеспечения и их отношения с позиций основных субъектов использования данного Международного Стандарта. Основными действиями субъектов являются : заключение контракта, управление, применение, инженерные действия и поддержка. С позиции заключения контракта, покупатель и поставщик ведут переговоры и вступают в контакт, применяя при этом Процесс Покупки и Процесс Поставки соответственно. С позиции управления, покупатель, поставщик, разработчик, оператор, персонал по сопровождению или другие стороны управляют своим соответственным процессом. С позиции применения, оператор обеспечивает для пользователя возможность оперирования программным обеспечением. С инженерной позиции, разработчик или персонал по сопровождению выполняют свои инженерные задачи, чтобы, соответственно, создавать или модифицировать программные продукты. С позиции поддержки, стороны (такие как управление конфигурацией, контроль качества) обеспечивают другим поддержку в выполнении специфических, уникальных задач. Также показаны (см. нижнее окно) организационные процессы; они применяются организацией на уровне объединения, чтобы установить и реализовать структуру, лежащую в основе объединяемого процесса (процессов) жизненного цикла системы и персонала и непрерывно улучшать ее.

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

Позиция заключения контракта связана с двумя процессами жизненного цикла (см.верхнее затененное окно Первичных Процессов Жизненного Цикла): Процесс Покупки для покупателя и Процесс Поставки для поставщика. Для каждого процесса показаны составляющие его работы. Эти процессы определяют задачи для покупателя и поставщика с точки зрения контракта.

Позиция выполнения инженерных действий связана с двумя процессами жизненного цикла (см. левое нижнее затененное окно в Первичных Процессах Жизненного Цикла): Процесс Разработки и Процесс Сопровождения. Для каждого процесса показаны составляющие его работы. Процесс Разработки применяется инженерами-разработчиками для создания программного продукта. Процесс сопровождения применяется инженерами по сопровождению для модификации программного обеспечения и сохранения его текущего состояния.

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

Позиция управления качеством связана с шестью процессами жизненного цикла (см. затененное окно в Процессах Жизненного Цикла, осуществляющих Поддержку): Процесс Гарантии Качества; Процесс Верификации; Процесс Проверки Достоверности; Процесс Объединенных Наблюдений и Процесс Ревизии. Составляющие их работы не показаны. Эти, относящиеся к качеству процессы, применяются для управления качеством на протяжении жизненного цикла программного обеспечения. Процессы Верификации, Проверки Достоверности, Объединенных Наблюдений и Ревизии могут применяться разными сторонами отдельно и также в качестве технологии выполнения Процесса Гарантии Качества.

Позиция Управления имеет один процесс (см. затененное окно в Организационных Процессах Жизненного Цикла): Процесс Управления, который используется любой организацией для управления соответствующим ей процессом. Показаны службы, составляющие этот процесс.

С.2 Процессы, организации и отношения.

Процессы и организации (или стороны) связаны только функционально. Они не диктуют организации (или стороне) ее структуру. В данном Международном Стандарте термины "организация" и "сторона" являются бдизкими по значению (почти синонимами). Организация является объектом, состоящим из лиц, организованных для некоторой специфической цели; примером является клуб, союз, корпорация или общество. Если вся организация или ее часть участвует в контракте, то она является стороной. Организации являются раздельными объектами, а стороны могут быть из одной организации или из разных.

Организация или сторона получает свое имя от процесса, который они выполняют; например, она называется "Покупатель", если она выполняет Процесс Покупки.

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

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

Приложение Д (информационное) Библиография

ISO/IEC 12119:1994, Информационная технология - Пакеты Программного Обеспечения - Требования качества и испытание.


Содержание