6.1.5 Политика сопровождения программного средства
Должны быть учтены вопросы, связанные с сопровождением программного средства. Типовыми объектами, рассматриваемыми при этом, являются:
- ожидаемый период сопровождения;
Должны быть учтены вопросы, связанные с сопровождением программного средства. Типовыми объектами, рассматриваемыми при этом, являются:
- ожидаемый период сопровождения;
- ожидаемая периодичность внесения изменений;
- критичность применения;
- определение персонала, осуществляющего сопровождение;
- определение степени квалификации данного персонала;
- определение среды, необходимой для сопровождения программного средства, включая его тестирование.
Должны быть учтены все требования к документированию программного средства, особенно если предполагают длительный период его сопровождения или внесение в него существенных изменений. При необходимости в среде документирования может быть предусмотрено средство для поиска необходимой информации.
Полезно также обеспечить в период сопровождения электронный доступ к документам.
- критичность применения;
- определение персонала, осуществляющего сопровождение;
- определение степени квалификации данного персонала;
- определение среды, необходимой для сопровождения программного средства, включая его тестирование.
Должны быть учтены все требования к документированию программного средства, особенно если предполагают длительный период его сопровождения или внесение в него существенных изменений. При необходимости в среде документирования может быть предусмотрено средство для поиска необходимой информации.
Полезно также обеспечить в период сопровождения электронный доступ к документам.
6.1.6 Модель жизненного цикла проекта
Для проекта должен быть проведен выбор одной или нескольких соответствующих моделей жизненного цикла (см. приложение С к настоящему стандарту). Должно быть установлено, является ли модель жизненного цикла программного средства составной частью модели жизненного цикла системы либо полной моделью жизненного цикла.
Каждая модель жизненного цикла в приложении С содержит некоторые процессы и работы, которые могут быть выполнены последовательно, повторно или комбинированно. Работы процессов из ГОСТ Р ИСО/МЭК 12207 должны быть отображены в выбранной модели жизненного цикла. С точки зрения создания модифицируемого, развивающегося, структурированного и планируемого продукта, результаты одной работы из модели жизненного цикла должны быть переданы следующей. В этом случае соответствующие документы должны быть созданы к окончанию данной работы, т.е. до начала следующей работы.
Для проекта должен быть проведен выбор одной или нескольких соответствующих моделей жизненного цикла (см. приложение С к настоящему стандарту). Должно быть установлено, является ли модель жизненного цикла программного средства составной частью модели жизненного цикла системы либо полной моделью жизненного цикла.
Каждая модель жизненного цикла в приложении С содержит некоторые процессы и работы, которые могут быть выполнены последовательно, повторно или комбинированно. Работы процессов из ГОСТ Р ИСО/МЭК 12207 должны быть отображены в выбранной модели жизненного цикла. С точки зрения создания модифицируемого, развивающегося, структурированного и планируемого продукта, результаты одной работы из модели жизненного цикла должны быть переданы следующей. В этом случае соответствующие документы должны быть созданы к окончанию данной работы, т.е. до начала следующей работы.
6.1.7 Разнообразие участвующих сторон
Должны быть определены стороны, участвующие в проекте, и их ответственность за конкретные процессы. Должны быть учтены все работы и задачи из ГОСТ Р ИСО/МЭК 12207, связанные с взаимодействиями (интерфейсами) между этими сторонами.
Для большого проекта, в который вовлечено много лиц, необходим развитой административный надзор и контроль. Например, проведение внутренних и независимых оценок, анализов, аудиторских проверок, инспекций и подготовка отчетов, являющихся главным инструментарием для большого проекта. Для малых проектов подобные средства контроля могут быть излишними и должны быть использованы взвешенно.
Должны быть определены стороны, участвующие в проекте, и их ответственность за конкретные процессы. Должны быть учтены все работы и задачи из ГОСТ Р ИСО/МЭК 12207, связанные с взаимодействиями (интерфейсами) между этими сторонами.
Для большого проекта, в который вовлечено много лиц, необходим развитой административный надзор и контроль. Например, проведение внутренних и независимых оценок, анализов, аудиторских проверок, инспекций и подготовка отчетов, являющихся главным инструментарием для большого проекта. Для малых проектов подобные средства контроля могут быть излишними и должны быть использованы взвешенно.
6.1.8 Типы программных средств
Должны быть определены типы программных средств, охваченных проектом, так как для различных типов требуются различные решения по внедрению ГОСТ Р ИСО/МЭК 12207. Примерами типов программных средств являются:
a) новая разработка;
b) готовое;
c) программы, реализованные техническими средствами;
d) автономное;
e) непоставляемое.
Ниже приведены некоторые важные рекомендации по основным типам программных средств. Следует запомнить, что различные типы программных средств реализуются на различных этапах процесса разработки, связанных с выполнением соответствующего набора работ.
Ниже приведены некоторые важные рекомендации по основным типам программных средств. Следует запомнить, что различные типы программных средств реализуются на различных этапах процесса разработки, связанных с выполнением соответствующего набора работ.
a) Новая разработка.
Данный тип программного средства изначально охвачен процессом разработки. Поэтому для него должны быть учтены все требования к процессу разработки.
Данный тип программного средства изначально охвачен процессом разработки. Поэтому для него должны быть учтены все требования к процессу разработки.
b) Готовое:
- используют именно готовое программное средство целиком. Данный тип программного средства уже спроектирован, запрограммирован и тестирован, но может потребоваться дополнительное тестирование в зависимости от такого его свойства, как критичность или практика применения. Данный тип программного средства охватывается процессом разработки не позднее проведения квалификационных испытаний системы, а полный процесс разработки для него является избыточным. Для данного типа должны быть оценены: качество функционирования, документы, права собственности и возможности его сопровождения (поддержки);
- готовое программное средство включают в процесс разработки без изменений, но требуется настройка его параметров под необходимую конфигурацию. В список настраиваемых параметров, например, может входить формат данных или размер бумаги. Данный тип охватывается процессом разработки после тестирования или сборки (интеграции) программных модулей разрабатываемого программного средства. Полный процесс разработки для данного типа может быть избыточным. Для данного типа должны быть оценены: качество функционирования, документы, права собственности и возможности его сопровождения (поддержки);
- модифицированное готовое программное средство, например с дополнением более подходящими форматами отчетов или отсутствием ряда документов. В данном случае, в зависимости от критичности объекта и предполагаемых изменений в нем, процесс разработки должен быть применен через процесс сопровождения. Процесс разработки подключают при программировании и тестировании модификаций данного программного средства. Для этого типа должны быть оценены: качество функционирования, документы, права собственности и возможности его сопровождения (поддержки).
- используют именно готовое программное средство целиком. Данный тип программного средства уже спроектирован, запрограммирован и тестирован, но может потребоваться дополнительное тестирование в зависимости от такого его свойства, как критичность или практика применения. Данный тип программного средства охватывается процессом разработки не позднее проведения квалификационных испытаний системы, а полный процесс разработки для него является избыточным. Для данного типа должны быть оценены: качество функционирования, документы, права собственности и возможности его сопровождения (поддержки);
- готовое программное средство включают в процесс разработки без изменений, но требуется настройка его параметров под необходимую конфигурацию. В список настраиваемых параметров, например, может входить формат данных или размер бумаги. Данный тип охватывается процессом разработки после тестирования или сборки (интеграции) программных модулей разрабатываемого программного средства. Полный процесс разработки для данного типа может быть избыточным. Для данного типа должны быть оценены: качество функционирования, документы, права собственности и возможности его сопровождения (поддержки);
- модифицированное готовое программное средство, например с дополнением более подходящими форматами отчетов или отсутствием ряда документов. В данном случае, в зависимости от критичности объекта и предполагаемых изменений в нем, процесс разработки должен быть применен через процесс сопровождения. Процесс разработки подключают при программировании и тестировании модификаций данного программного средства. Для этого типа должны быть оценены: качество функционирования, документы, права собственности и возможности его сопровождения (поддержки).
c) Программы, реализованные техническими средствами.
Это программное средство аппаратно встроено в систему или подключено к ней. Так как данное программное средство является частью большой системы, в процессе его разработки должны быть предусмотрены работы системного уровня. Из работ системного уровня должны быть выбраны те, которые определяются глаголами "выполнить" или "обеспечить". Если данный тип (программного средства в целом или входящих в него программ, реализованных техническими средствами) в дальнейшем изменять не предполагается, то требуется тщательная проверка документов к нему.
Это программное средство аппаратно встроено в систему или подключено к ней. Так как данное программное средство является частью большой системы, в процессе его разработки должны быть предусмотрены работы системного уровня. Из работ системного уровня должны быть выбраны те, которые определяются глаголами "выполнить" или "обеспечить". Если данный тип (программного средства в целом или входящих в него программ, реализованных техническими средствами) в дальнейшем изменять не предполагается, то требуется тщательная проверка документов к нему.
d) Автономное.
Данный тип охватывает автономные программные средства. Так как они не являются частью законченной системы, проведения работ системного уровня в процессе разработки для них не требуется. При этом для них должны быть тщательно проверены необходимые документы, особенно в части их сопровождения.
Данный тип охватывает автономные программные средства. Так как они не являются частью законченной системы, проведения работ системного уровня в процессе разработки для них не требуется. При этом для них должны быть тщательно проверены необходимые документы, особенно в части их сопровождения.
e) Непоставляемое.
Так как данный тип средств не является объектом заказа, поставки или разработки, соответствующие разделы ГОСТ Р ИСО/МЭК 12207 для них не учитывают, за исключением 5.3.1.5 указанного стандарта. Однако если заказчик решит заказать часть таких программных средств для последующей их эксплуатации и сопровождения, тогда к ним следует применять рекомендации в соответствии с перечислениями b) и d) данного пункта.
Так как данный тип средств не является объектом заказа, поставки или разработки, соответствующие разделы ГОСТ Р ИСО/МЭК 12207 для них не учитывают, за исключением 5.3.1.5 указанного стандарта. Однако если заказчик решит заказать часть таких программных средств для последующей их эксплуатации и сопровождения, тогда к ним следует применять рекомендации в соответствии с перечислениями b) и d) данного пункта.
6.1.9 Объем проекта
Большой проект, в который вовлечены десятки или сотни лиц, вызывает значительные трудности в управлении им по сравнению с проектом, в котором заняты, например, три человека. Большие проекты или проекты с привлечением субподрядчиков требуют тщательного административного надзора и контроля. В некоторых проектах данные мероприятия реализуют применением совместных анализов, аудиторских проверок, верификации, аттестации и обеспечением качества. Для малых проектов подобные методы контроля могут быть излишними.
Большой проект, в который вовлечены десятки или сотни лиц, вызывает значительные трудности в управлении им по сравнению с проектом, в котором заняты, например, три человека. Большие проекты или проекты с привлечением субподрядчиков требуют тщательного административного надзора и контроля. В некоторых проектах данные мероприятия реализуют применением совместных анализов, аудиторских проверок, верификации, аттестации и обеспечением качества. Для малых проектов подобные методы контроля могут быть излишними.
6.1.10 Критичность проекта
Для системы, работа которой в значительной степени зависит от правильного функционирования программных средств и своевременной выдачи результатов, необходим более тщательный надзор и контроль. Напротив, для некритичного программного средства излишний надзор и контроль, вероятно, неэффективен. (Для уточнения понятия критичности - см. 6.4.1.1 ГОСТ Р ИСО/МЭК 12207.)
Для системы, работа которой в значительной степени зависит от правильного функционирования программных средств и своевременной выдачи результатов, необходим более тщательный надзор и контроль. Напротив, для некритичного программного средства излишний надзор и контроль, вероятно, неэффективен. (Для уточнения понятия критичности - см. 6.4.1.1 ГОСТ Р ИСО/МЭК 12207.)
6.1.11 Технический риск
При разработке программного средства может иметь место технический риск. Если использована несовершенная технология программирования, то будет создано уникальное или сложное программное средство; если к программному средству предъявлены требования по безопасности и (или) защите или другие критические требования, то могут быть необходимы строгое определение технических требований, тщательное проектирование, тестирование и оценка, а также независимая верификация и аттестация.
7 Применение в организациях
7.1 Предпосылки и методы
Организации должны широко использовать ГОСТ Р ИСО/МЭК 12207 в качестве составной части деятельности по усовершенствованию процессов, связанных с программными средствами. Это может быть выполнено автономно или вместе с доступными методами оценки и определения функциональных возможностей процесса, например описанными в стандартах серии ИСО/МЭК ТО 15504.
Применение ГОСТ Р ИСО/МЭК 12207 в организации основано на тех же методах внедрения, которые используют в проектах. Организации, внедряющие ГОСТ Р ИСО/МЭК 12207, должны использовать рекомендации, приведенные в разделе 6, и политики, описанные в разделе 5 настоящего стандарта.
Применение ГОСТ Р ИСО/МЭК 12207 в организации основано на тех же методах внедрения, которые используют в проектах. Организации, внедряющие ГОСТ Р ИСО/МЭК 12207, должны использовать рекомендации, приведенные в разделе 6, и политики, описанные в разделе 5 настоящего стандарта.
7.2 Возможности применения
Причины, по которым ГОСТ Р ИСО/МЭК 12207 внедряют в организации, могут быть следующими:
- проверка совершенства существующего метода. Это обычно имеет место, когда метод был разработан самой организацией или ею был выбран и изменен существующий метод;
- практическое применение данного метода для предотвращения риска, связанного с выходом на новые секторы рынка с более жесткими требованиями, связанными с потенциальным риском;
- разработка нового метода, например для удовлетворения потребностям новой организации. Тем самым могут быть охвачены организации, созданные путем слияния или делового сотрудничества. Это может быть необходимо для сопровождения некоторых моделей процессов обеспечения конкретных работ;
- управление внедрением новой технологии, например: автоматизация ручных процессов или изменение методов, используемых при внедрении программного продукта. ГОСТ Р ИСО/МЭК 12207 устанавливает критерии, которые могут быть использованы для контроля совершенства соответствующего метода до или после изменения технологии;
- оценка внутренних возможностей стороны с точки зрения удовлетворения критериям договора, например в качестве стороны, участвующей в конкурсном (тендерном) процессе;
- определение контрольных этапов, при реализации которых могут быть разработаны более совершенные программы, например проведение аудита в соответствии с ГОСТ Р ИСО/МЭК 12207 и использование самого процесса усовершенствования.
- проверка совершенства существующего метода. Это обычно имеет место, когда метод был разработан самой организацией или ею был выбран и изменен существующий метод;
- практическое применение данного метода для предотвращения риска, связанного с выходом на новые секторы рынка с более жесткими требованиями, связанными с потенциальным риском;
- разработка нового метода, например для удовлетворения потребностям новой организации. Тем самым могут быть охвачены организации, созданные путем слияния или делового сотрудничества. Это может быть необходимо для сопровождения некоторых моделей процессов обеспечения конкретных работ;
- управление внедрением новой технологии, например: автоматизация ручных процессов или изменение методов, используемых при внедрении программного продукта. ГОСТ Р ИСО/МЭК 12207 устанавливает критерии, которые могут быть использованы для контроля совершенства соответствующего метода до или после изменения технологии;
- оценка внутренних возможностей стороны с точки зрения удовлетворения критериям договора, например в качестве стороны, участвующей в конкурсном (тендерном) процессе;
- определение контрольных этапов, при реализации которых могут быть разработаны более совершенные программы, например проведение аудита в соответствии с ГОСТ Р ИСО/МЭК 12207 и использование самого процесса усовершенствования.
7.3 Распространение административного управления
Для любой программы работ, связанной с изменениями существующей практической деятельности, внутри организации должно быть обеспечено административное управление надзором за реализацией и внесением изменений. При участии в работах многих сторон подобный метод должен быть предусмотрен договором и, в случае реализации его головной организацией, распространен на все участвующие стороны.
8 Прикладное применение модели жизненного цикла системы
Настоящий раздел иллюстрирует общую модель жизненного цикла системы или проекта и описывает, как ГОСТ Р ИСО/МЭК 12207 может быть внедрен в данной модели жизненного цикла системы. Обзор типовых моделей жизненного цикла - по приложению С к настоящему стандарту.
8.1 Модель жизненного цикла системы
Типовая модель жизненного цикла системы начинается с концепции идеи системы или потребности в ней, охватывая разработку, создание, эксплуатацию и сопровождение системы, и заканчивается снятием системы с эксплуатации (утилизацией). Модель жизненного цикла обычно разделяют на периоды реализации, например стадии или этапы. Каждый подобный период включает в себя основные реализуемые в нем работы и задачи, при завершении которых может потребоваться разрешение на переход к следующему периоду реализации.
Например, общую модель жизненного цикла системы разделяют на стадии (этапы) с последующей адаптацией каждой из них к модели жизненного цикла конкретной системы:
Например, общую модель жизненного цикла системы разделяют на стадии (этапы) с последующей адаптацией каждой из них к модели жизненного цикла конкретной системы:
a) определение потребностей;
b) исследование и описание основных концепций;
c) демонстрация и аттестация основных концепций;
d) проектирование и разработка;
e) создание и производство;
f) распространение и продажа;
g) эксплуатация;
h) сопровождение и поддержка;
i) снятие с эксплуатации (утилизация).
8.2 Модель жизненного цикла программного средства
Типовая модель жизненного цикла программного средства состоит из ряда работ. Данная модель начинается с формулировки замысла (идеи) или концепции программного продукта или услуги, продолжается работами по применению методов системной и программной инженерии, работами по эксплуатации, сопровождению и поддержке и заканчивается снятием с эксплуатации (утилизацией). В ГОСТ Р ИСО/МЭК 12207 все эти и другие, связанные с ними работы, объединены в основные, вспомогательные и организационные процессы, из которых формируют модель жизненного цикла программного средства.
8.3 Пример использования ГОСТ Р ИСО/МЭК 12207 в общей модели жизненного цикла системы
На рисунке 7 основное внимание уделено использованию ГОСТ Р ИСО/МЭК 12207 в общей модели жизненного цикла гипотетической системы. Основным назначением данного рисунка является сжатое представление метода применения ГОСТ Р ИСО/МЭК 12207. В таблице 2 (см. 8.13) представлен состав работ жизненного цикла системы и используемых процессов жизненного цикла программного средства.
 | |
| 600 × 410 пикс. Открыть в новом окне | |
Рисунок 7 - Использование ГОСТ Р ИСО/МЭК 12207 для обеспечения модели жизненного цикла системы
Организация может использовать ГОСТ Р ИСО/МЭК 12207 в любой работе или в общей модели жизненного цикла самостоятельно, а также может привлекать для этого (частично или полностью) поставщика соответствующих продуктов или услуг.
8.4 Определение потребностей
Во время данной работы выявляют и определяют замысел или потребность в новой или усовершенствованной системе. Формулируют общие потребности с учетом таких факторов, как стоимость, критичность и реализуемость планируемой системы.
Процесс заказа может быть использован для установления технологических или эксплуатационных возможностей системы до выполнения исследований, разработки и привязки. Далее процесс разработки может быть использован для создания программного средства, методов или моделей для принятия соответствующих решений.
Процесс заказа может быть использован для установления технологических или эксплуатационных возможностей системы до выполнения исследований, разработки и привязки. Далее процесс разработки может быть использован для создания программного средства, методов или моделей для принятия соответствующих решений.