8.5 Исследование и определение концепции
Данная работа открывает период первоначального планирования, в течение которого оценивают технические, стратегические и рыночно-экономические аспекты системы путем всесторонних исследований, опытной разработки и оценки ее концепции. Решения, предложенные для реализации определенной потребности, могут быть однозначными или альтернативными, разработанными на основе оценки возможностей, прикидок (таких как стоимость, график работ, перспективы продажи, интеллектуальность и логистика); изучения компромиссных вариантов и проведения анализов. Выходными результатами данной работы, передаваемыми в следующую работу, являются предварительные общие требования к системе и возможные программные средства, выбранные в качестве прототипа.
Процессы заказа, поставки и разработки могут быть использованы для:
- помощи при установлении предварительных требований к системе;
- определения прототипов разработки;
- анализа и учета взаимодействий (обратной связи) с пользователем по предложенным решениям.
Сам по себе процесс разработки может быть использован в качестве метода для разработки программного средства, реализующего аналитические или имитационные модели, необходимые при исследованиях и принятии определенных решений.
Процессы заказа, поставки и разработки могут быть использованы для:
- помощи при установлении предварительных требований к системе;
- определения прототипов разработки;
- анализа и учета взаимодействий (обратной связи) с пользователем по предложенным решениям.
Сам по себе процесс разработки может быть использован в качестве метода для разработки программного средства, реализующего аналитические или имитационные модели, необходимые при исследованиях и принятии определенных решений.
8.6 Демонстрация и аттестация
При выполнении данной работы уточняют характеристики системы, ее концепции и принятые решения, включая вычислительные ресурсы, используя при этом методы системной инженерии, определяют предварительные требования к программному средству и его прототипам, включая их тестирование и аттестацию. Характеристики системы, а также выбранные концепции и решения аттестуют для демонстрации того, что система, включая технические и программные средства, пригодна для технологической разработки. Требования к системе являются основой для дальнейшего их разбиения по компонентам системы, таким как технические средства, компьютеры, программные средства и персонал. Данные выходные результаты передают в следующую работу.
Процессы заказа, поставки и разработки могут быть использованы для анализа и определения требований к системе, принятия общих проектных решений по системе и предварительных требований для компонентов системы, включая программные средства. Процесс разработки может быть использован в качестве метода для анализа, демонстрации, аттестации, тестирования и макетирования соответствующих требований и проектных решений.
Процессы заказа, поставки и разработки могут быть использованы для анализа и определения требований к системе, принятия общих проектных решений по системе и предварительных требований для компонентов системы, включая программные средства. Процесс разработки может быть использован в качестве метода для анализа, демонстрации, аттестации, тестирования и макетирования соответствующих требований и проектных решений.
8.7 Проектирование и разработка
Данная работа охватывает период проектирования, создания, интеграции (сборки), тестирования и оценки системных технических средств, компьютеров, программных средств, оборудования, персонала подсистем, его обучения и объектов сопровождения. Выходными результатами данной работы являются система, достаточно близкая к создаваемой, документы, необходимые для последующей работы, и результаты тестирования качества создаваемой системы.
При проведении данной работы полностью применим ГОСТ Р ИСО/МЭК 12207. При этом для выполнения разработки или модернизации программного средства должны быть выбраны, соответствующим образом адаптированы и использованы процессы, работы и задачи из процессов заказа, поставки и разработки. Данная работа может включать в себя однократное или многократное использование процесса разработки, скоординированное с другими компонентами системы. Результатами данной работы являются исходные требования к программному средству, его проект и соответствующие программы.
Если программное средство разрабатывают как часть системы, то должны быть востребованы все работы процесса разработки. Дополнительно уточняют, должен ли разработчик выполнять или обеспечивать работы, связанные с системой. Если программное средство разрабатывают в виде автономного продукта или продукта, не являющегося частью системы, тогда нет необходимости в выполнении работ, связанных с системой, но их следует учесть (предусмотреть).
При проведении данной работы полностью применим ГОСТ Р ИСО/МЭК 12207. При этом для выполнения разработки или модернизации программного средства должны быть выбраны, соответствующим образом адаптированы и использованы процессы, работы и задачи из процессов заказа, поставки и разработки. Данная работа может включать в себя однократное или многократное использование процесса разработки, скоординированное с другими компонентами системы. Результатами данной работы являются исходные требования к программному средству, его проект и соответствующие программы.
Если программное средство разрабатывают как часть системы, то должны быть востребованы все работы процесса разработки. Дополнительно уточняют, должен ли разработчик выполнять или обеспечивать работы, связанные с системой. Если программное средство разрабатывают в виде автономного продукта или продукта, не являющегося частью системы, тогда нет необходимости в выполнении работ, связанных с системой, но их следует учесть (предусмотреть).
8.8 Создание и производство
Во время данной работы спроектированную и разработанную систему изготовляют для заказчика (пользователей) или рынка (потребителей). Период создания охватывает работы от постановки на производство до поставки и приемки системы. Целями данной работы являются квалифицированное изготовление и поставка работоспособной и сопровождаемой системы заказчику (пользователям). Период производства охватывает деятельность от постановки на производство до перепроектирования или снятия системы с производства. Целями данной работы являются квалифицированное производство и поставка работоспособной и поддерживаемой системы потребителям (на рынок).
Для программных средств, по сравнению с техническими средствами, работа по созданию и производству незначительна. Она состоит из копирования (тиражирования) разработанного программного средства и документов к нему на соответствующие носители для различных пользователей (потребителей). (Конкретные задачи по реализации данной работы в ГОСТ Р ИСО/МЭК 12207 не установлены.) В этом случае могут быть использованы конкретные промышленные методы и соответствующие государственные акты. Для контроля за выполнением указанных задач может быть использована работа по управлению выпуском и поставкой из процесса управления конфигурацией. Также могут быть использованы другие соответствующие работы, такие как верификация сборки.
Для программных средств, по сравнению с техническими средствами, работа по созданию и производству незначительна. Она состоит из копирования (тиражирования) разработанного программного средства и документов к нему на соответствующие носители для различных пользователей (потребителей). (Конкретные задачи по реализации данной работы в ГОСТ Р ИСО/МЭК 12207 не установлены.) В этом случае могут быть использованы конкретные промышленные методы и соответствующие государственные акты. Для контроля за выполнением указанных задач может быть использована работа по управлению выпуском и поставкой из процесса управления конфигурацией. Также могут быть использованы другие соответствующие работы, такие как верификация сборки.
8.9 Распространение и продажа
При выполнении данной работы систему поставляют заказчику (пользователям) или покупателям (на рынок). Период распространения начинается с поставки первой работоспособной системы заказчику (пользователям или сопровождающей организации). Период продажи охватывает деятельность от поставки первой партии систем потребителям до изъятия системы с рынка.
Процессы заказа, поставки и разработки могут быть использованы для ввода в действие и наладки разработанного или модифицированного программного средства.
Процессы заказа, поставки и разработки могут быть использованы для ввода в действие и наладки разработанного или модифицированного программного средства.
8.10 Эксплуатация
Данная работа включает в себя эксплуатацию, применение или использование системы пользователями (потребителями), заканчиваясь снятием ее с эксплуатации.
Процессы заказа, поставки и эксплуатации могут быть использованы при эксплуатации программного средства и обеспечении эксплуатационной поддержки соответствующих пользователей.
Процессы заказа, поставки и эксплуатации могут быть использованы при эксплуатации программного средства и обеспечении эксплуатационной поддержки соответствующих пользователей.
8.11 Сопровождение и поддержка
При выполнении данной работы систему модифицируют, что связано с наличием в ней ошибок, дефектов, возникновением проблем, появлением запросов пользователей или появлением в данной организации потребностей в ее адаптации или усовершенствовании. Данная работа включает в себя предоставление логистической, технической и ремонтной поддержки пользователям (или потребителям) системы.
Процессы заказа, поставки и сопровождения могут быть применены для сопровождения программного средства и предоставления услуг по поддержке системы в соответствующих организациях, у пользователей (потребителей).
При этом должны быть определены все взаимосвязи (интерфейсы) с процессом разработки. В зависимости от важности решаемой проблемы могут быть в разной степени применены работы из процесса разработки (в зависимости от конкретной ситуации).
Процессы заказа, поставки и сопровождения могут быть применены для сопровождения программного средства и предоставления услуг по поддержке системы в соответствующих организациях, у пользователей (потребителей).
При этом должны быть определены все взаимосвязи (интерфейсы) с процессом разработки. В зависимости от важности решаемой проблемы могут быть в разной степени применены работы из процесса разработки (в зависимости от конкретной ситуации).
8.12 Снятие с эксплуатации (утилизация)
В этот период систему снимают с обслуживания. Данная работа включает в себя архивирование снимаемой системы и обеспечение ограниченной поддержки ее пользователей в данный период.
Процесс заказа и работа по снятию с эксплуатации из процесса сопровождения могут быть использованы при снятии с эксплуатации программного средства и обеспечении услуг по поддержке системы в данный конкретный период в организациях, у пользователей (потребителей).
Процесс заказа и работа по снятию с эксплуатации из процесса сопровождения могут быть использованы при снятии с эксплуатации программного средства и обеспечении услуг по поддержке системы в данный конкретный период в организациях, у пользователей (потребителей).
8.13 Процессы жизненного цикла программного средства в общей модели жизненного цикла системы
В таблице 2 приведен пример распределения процессов жизненного цикла программного средства по периодам жизненного цикла системы. Показаны только основные процессы из ГОСТ Р ИСО/МЭК 12207. Вспомогательные или организационные процессы должны быть использованы через основные процессы. Буквой "П" обозначено использование процесса из ГОСТ Р ИСО/МЭК 12207, а буквой "М" - использование соответствующего метода. Обозначение "(П)" или "(М)" указывает на возможность использования соответствующего процесса или метода.
Таблица 2 - Процессы жизненного цикла программного средства в общей модели жизненного цикла системы
Периоды жизненного цикла системы | Процессы жизненного цикла программного средства | ||||
Заказ | Поставка | Разработка | Эксплуатация | Сопровождение | |
Определение потребностей |  | (  ) | |||
Исследование и определение концепции | | ( ) | ( ), | ||
Демонстрация и аттестация | | |  | ||
Проектирование и разработка | | | | ||
Создание и производство | |||||
Распространение и продажа | | | | ||
Эксплуатация | | | | ||
Сопровождение и поддержка | | | | ||
Снятие с эксплуатации | | | |||
ПРИЛОЖЕНИЕ А (справочное). Процессы качества и требования к оценке
Вспомогательные процессы жизненного цикла, связанные с качеством программного средства, показаны в сгруппированном виде, выделенном серым фоном, на рисунке 1 в ГОСТ Р ИСО/МЭК 12207. Такими процессами являются:
- обеспечение качества;
- верификация;
- аттестация (валидация);
- совместный анализ;
- аудит.
При реализации каждого из основных процессов могут быть привлечены не только вышеперечисленные вспомогательные процессы, связанные с деятельностью по оценке или аттестации, но также и дополнительные задачи по оценке, за решение которых персонально отвечает определенное лицо. Такие дополнительные задачи предназначены для последовательного повышения качества выполнения других задач, работ и процессов. В некоторых проектах подобный метод может привести к дублированию работ или выполнению большего объема работ, чем необходимо, для создания высококачественного продукта. Для других проектов, таких как критичные оборонные проекты, необходимы все процессы, работы и задачи по проведению соответствующих оценок. Поэтому ключевым моментом использования ГОСТ Р ИСО/МЭК 12207 является адаптация процессов, связанных с качеством, проведенная до начала реализации проекта, а также распределение ролей данных конкретных процессов, реализуемых в проекте. ГОСТ Р ИСО/МЭК 12207 формулирует эту важную задачу в виде подготовки плана обеспечения качества, подкрепленного, при необходимости, другими связанными с ним планами, такими как планы верификации и аттестации.
Применение задач, связанных с качеством, может привести к объединению конкретных задач или выполнению обязанностей, связанных с качеством, другими задачами. Например, в малых проектах по разработке управляющей информационной системы, используемой внутри компании, план обеспечения качества должен допускать проведение верификации и аттестации группой проектантов и предусматривать элементарный процесс управления анализом. Для большой критичной оборонной системы, разрабатываемой для заказчика, в ее проекте должны быть запланированы независимые группы по верификации и аттестации, а также совместные анализы и аудиторские проверки. В этом случае решающую роль играют объем и сложность проекта вместе с уровнем интеграции создаваемого приложения или системы.
В таблице А.1 показаны требования, связанные с оценками продуктов, услуг и процессов. В соответствующей работе жизненного цикла проекта или процесса эксперт должен оценить либо программные продукты и услуги самой организации, либо сторонние программные продукты или услуги. В ГОСТ Р ИСО/МЭК 12207 данные оценки сгруппированы в пять нижеперечисленных типов (см. таблицу А.1). Первые четыре типа оценок реализуют на проектном уровне, а последний - на уровне организации. Данные оценки должны быть выбраны и адаптированы пропорционально области применения, важности, сложности и критичности проекта (или стратегии) и потребностям организации. Отчеты о проблемах, несоответствиях или необходимых усовершенствованиях, полученные в результате оценок, передают в процесс решения проблем.
- обеспечение качества;
- верификация;
- аттестация (валидация);
- совместный анализ;
- аудит.
При реализации каждого из основных процессов могут быть привлечены не только вышеперечисленные вспомогательные процессы, связанные с деятельностью по оценке или аттестации, но также и дополнительные задачи по оценке, за решение которых персонально отвечает определенное лицо. Такие дополнительные задачи предназначены для последовательного повышения качества выполнения других задач, работ и процессов. В некоторых проектах подобный метод может привести к дублированию работ или выполнению большего объема работ, чем необходимо, для создания высококачественного продукта. Для других проектов, таких как критичные оборонные проекты, необходимы все процессы, работы и задачи по проведению соответствующих оценок. Поэтому ключевым моментом использования ГОСТ Р ИСО/МЭК 12207 является адаптация процессов, связанных с качеством, проведенная до начала реализации проекта, а также распределение ролей данных конкретных процессов, реализуемых в проекте. ГОСТ Р ИСО/МЭК 12207 формулирует эту важную задачу в виде подготовки плана обеспечения качества, подкрепленного, при необходимости, другими связанными с ним планами, такими как планы верификации и аттестации.
Применение задач, связанных с качеством, может привести к объединению конкретных задач или выполнению обязанностей, связанных с качеством, другими задачами. Например, в малых проектах по разработке управляющей информационной системы, используемой внутри компании, план обеспечения качества должен допускать проведение верификации и аттестации группой проектантов и предусматривать элементарный процесс управления анализом. Для большой критичной оборонной системы, разрабатываемой для заказчика, в ее проекте должны быть запланированы независимые группы по верификации и аттестации, а также совместные анализы и аудиторские проверки. В этом случае решающую роль играют объем и сложность проекта вместе с уровнем интеграции создаваемого приложения или системы.
В таблице А.1 показаны требования, связанные с оценками продуктов, услуг и процессов. В соответствующей работе жизненного цикла проекта или процесса эксперт должен оценить либо программные продукты и услуги самой организации, либо сторонние программные продукты или услуги. В ГОСТ Р ИСО/МЭК 12207 данные оценки сгруппированы в пять нижеперечисленных типов (см. таблицу А.1). Первые четыре типа оценок реализуют на проектном уровне, а последний - на уровне организации. Данные оценки должны быть выбраны и адаптированы пропорционально области применения, важности, сложности и критичности проекта (или стратегии) и потребностям организации. Отчеты о проблемах, несоответствиях или необходимых усовершенствованиях, полученные в результате оценок, передают в процесс решения проблем.
Таблица А.1 - Требования к оценкам продуктов, услуг и процессов
Тип оценки | Пункт ГОСТ Р ИСО/МЭК 12207 | Назначение | Исполнитель | Примечание |
Оценки внутри процесса | 5.1-5.5 | Ежедневная работа | Персонал, выполняющий задачи по оценке в процессе | - |
Обеспечение качества | 6.3 | Независимое подтверждение соответствия программных продуктов и услуг требованиям договора и соблюдения установленных планов | Персонал, организационно независимый от тех, кто отвечает за разработку программного средства | Можно использовать результаты других работ в качестве исходных данных. Можно скоординировать данные работы с другими работами по оценке |
Верификация и аттестация (валидация) | 6.4 и 6.5 | Верификация и аттестация продуктов с различной степенью зависимости от проекта | Заказчик, поставщик, разработчик, оператор, персонал по сопровождению или независимый персонал, или третья сторона | Можно не дублировать или заменять другими оценками, т.е. данные оценки дополнительны |
Совместные анализы и аудиторские проверки | 6.6 и 6.7 | Оценка состояний и завершенности продуктов и работ по согласованным графикам | Оценивающая сторона (аналитик или аудитор) и оцениваемая сторона (анализируемая или проверяемая) совместно | - |
Оценка и усовер- шенствование | 7.3 | Эффективное управление и самоусовершенствование | Администратор | - |
ПРИЛОЖЕНИЕ В (справочное). Классификация выходных результатов процессов
В настоящем приложении определены выходные результаты процессов (см. таблицы В.1-В.4), которые должны быть документально оформлены в соответствии с требованиями или рекомендациями ГОСТ Р ИСО/МЭК 12207. Перечислены только те пункты ГОСТ Р ИСО/МЭК 12207, по которым требуются выходные результаты. Документы по данным выходным результатам должны быть выбраны и скомплектованы пропорционально области применения, значимости, сложности и критичности проекта или организации. В графе "Выходные результаты" таблицы B.1 наименования или заголовки соответствующих документов не указаны.
Таблица B.1 - Выходные результаты основных процессов жизненного цикла
Процесс | Пункт ГОСТ Р ИСО/МЭК 12207 | Выходные результаты | Тип выходного результата |
Заказ | 5.1.1.8 | План заказа | План |
5.1.1.9 | Стратегия и условия заказа | Описание | |
5.1.2.1 | Заявка на подряд (тендер) | Описание | |
5.1.2.1 | Документы по заказу | Описание | |
5.1.3.1 | Процедура выбора поставщика | Процедура | |
5.1.3.4 | Договор | Договор | |
Поставка | 5.2.2.1 | Предложение | Предложение |
5.2.4.5 | План(ы) управления проектом | План | |
5.2.6.4 | Отчеты о проведенных оценках, анализах, аудиторских проверках, испытаниях и реализованных решениях возникших проблем | Отчет | |
Разработка | 5.3.1.2 | Протоколы о проблемах и несоответствиях | Протокол |
5.3.1.4 | Планы разработки | План | |
5.3.2.1 | Технические требования (спецификация) к системе | Описание | |
5.3.3.1 | Документ по архитектуре системы | Описание | |
5.3.3.1 | Документ на привязку к объектам системы | Описание | |
5.3.4.1 | Технические требования к программному средству | Описание | |
5.3.4.2 | Результаты оценки технических требований к программному средству | Протокол | |
5.3.5.1 | Объект программной конфигурации | Программное средство | |
5.3.5.1 | Требования к архитектуре (эскизный проект) | Описание | |
5.3.5.2 | Требования к интерфейсам программного средства (эскизный проект) | Описание | |
5.3.5.3 | Эскизный проект базы данных | Описание | |
5.3.5.4 | Руководство(а) пользователя | Руководство | |
5.3.5.5 | Требования к испытанию (тестированию) программного средства | Описание | |
5.3.5.6 | Анализ проекта | Протокол | |
Разработка | 5.3.6.1 | Технический проект | Описание |
5.3.6.2 | Уточненные требования к интерфейсам программного средства (технический проект) | Описание | |
5.3.6.3 | Технический проект базы данных | Описание | |
5.3.6.5 | Требования к тестированию программных модулей | Описание | |
5.3.6.7 | Анализ технического проекта | Протокол | |
5.3.7.1 | Программные модули и базы данных | Программные средства | |
5.3.7.1 | Процедура испытаний (тестирования) | Процедура | |
5.3.7.2 | Результаты тестирования программных модулей | Протокол | |
5.3.7.5 | Анализ результатов программирования и тестирования | Протокол | |
5.3.8.1 | План сборки программного средства | План | |
5.3.8.2 | Результаты сборки и тестирования программного средства | Протокол | |
5.3.8.5 | Анализ плана сборки и документирования программного средства | Протокол | |
5.3.9.1 | Результаты квалификационных испытаний (тестирования) объекта программной конфигурации | Протокол | |
5.3.9.3 | Анализ сборки программного средства | Протокол | |
5.3.9.4 | Аудиторская проверка сборки программного средства | Протокол | |
5.3.10.1 | Результаты сборки и испытания системы | Протокол | |
5.3.10.2 | Требования к квалификационным испытаниям системы | Описание | |
5.3.10.3 | Анализ квалификационного испытания системы | Протокол | |
5.3.11.1 | Результаты квалификационных испытаний системы | Протокол | |
5.3.11.3 | Результаты аудиторских проверок системы | Протокол | |
5.3.12.1 | План по вводу в действие программного средства | План | |
5.3.12.2 | Реализация и результаты ввода в действие программного средства | Протокол | |
5.3.13.1 | Готовность к приемке и приемочные испытания программного средства | Протокол | |
Эксплуатация | 5.4.1.1 | План эксплуатации | План |
5.4.1.2 | Процедура подготовки отчетов по проблеме | Процедура | |
5.4.1.2 | Отчетность по проблеме | Протокол | |
5.4.1.3 | Процедура тестирования в эксплуатационной среде | Процедура | |
Сопровождение | 5.5.1.1 | План сопровождения | План |
5.5.1.1 | Процедура сопровождения | Процедура | |
5.5.1.2 | Процедуры описания проблемы и реализации заявки на внесение изменений | Процедура | |
5.5.2.4 | Протокол фиксации сообщения о проблеме или заявки на внесение изменения | Протокол | |
5.5.3.1 | Протоколы внесения изменений | Протокол | |
5.5.3.2 | Результаты тестирования внесенных изменений | Протокол | |
5.5.5.2 | План переноса программного средства | План | |
5.5.6.1 | План снятия с эксплуатации | План |
Таблица В.2 - Выходные результаты вспомогательных процессов жизненного цикла
Процесс | Пункт ГОСТ Р ИСО/МЭК 12207 | Выходные результаты | Тип выходного результата |
Документирование | 6.1.1.1 | План документирования | План |
Управление конфигурацией | 6.2.1.1 | План управления конфигурацией | План |
6.2.4.1 | Отчеты и протоколы по управлению конфигурацией | Протокол | |
Обеспечение качества | 6.3.1.3 | План обеспечения качества | План |
6.3.1.4 | Протоколы по обеспечению качества | Протокол | |
Верификация | 6.4.1.5 | План верификации | План |
Аттестация | 6.5.1.4 | План аттестации | План |
Совместный анализ | 6.6.1.4 | Результаты совместного анализа | Протокол |
Аудит | 6.7.1.5 | Результаты аудиторских проверок | Протокол |
Решение проблем | 6.8.1.1 | Отчет о проблеме | Протокол |
Таблица В.3 - Выходные результаты организационных процессов жизненного цикла
Процесс | Пункт ГОСТ Р ИСО/МЭК 12207 | Выходные результаты | Тип выходного результата |
Управление | 7.1.2.1 | План управления | План |
7.1.3.3 | Анализы проблем | Отчет | |
Создание инфраструктуры | 7.2.1.2 | План создания инфраструктуры | План |
7.2.2.1 | Конфигурация инфраструктуры | Описание | |
Усовершенствование | 7.3.1.1 | Процедуры организационных процессов | Процедура |
7.3.2.1 | Процедура оценки процесса | Процедура | |
Обучение | 7.4.1.1 | План обучения | План |
7.4.3.1 | Протоколы об обучении | Протокол |
Процесс адаптации из приложения А к ГОСТ Р ИСО/МЭК 12207 используют как дополнительный. В случае применения данный процесс должен иметь следующие выходные результаты (таблица В.4).
Таблица В.4 - Выходные результаты процесса адаптации
Таблица В.4 - Выходные результаты процесса адаптации
Процесс | Пункт ГОСТ Р ИСО/МЭК 12207 | Выходные результаты | Тип выходного результата |
Адаптация | А.4.1 | Принятые решения по адаптации и их обоснования | Протокол |
ПРИЛОЖЕНИЕ С (справочное). Модели жизненного цикла
Существует множество моделей жизненного цикла, но три из них - фундаментальные. Этими фундаментальными моделями жизненного цикла являются:
- каскадная;
- инкрементная;
- эволюционная.
Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла. При этом конкретную модель жизненного цикла следует выбирать так, чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между собой и определены их взаимосвязи с предшествующими процессами, работами (видами деятельности) и задачами (заданиями).
В настоящем приложении описаны три фундаментальные модели жизненного цикла с присущими им недостатками (аргументами против их применения) и преимуществами (выгодами). Эти недостатки и преимущества должны быть учтены при выборе модели жизненного цикла для проекта.
- каскадная;
- инкрементная;
- эволюционная.
Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла. При этом конкретную модель жизненного цикла следует выбирать так, чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между собой и определены их взаимосвязи с предшествующими процессами, работами (видами деятельности) и задачами (заданиями).
В настоящем приложении описаны три фундаментальные модели жизненного цикла с присущими им недостатками (аргументами против их применения) и преимуществами (выгодами). Эти недостатки и преимущества должны быть учтены при выборе модели жизненного цикла для проекта.
C.1 Каскадная модель
Каскадная модель жизненного цикла по существу реализует принцип однократного выполнения каждого из следующих видов деятельности в их естественных границах:
- установление потребностей пользователя;
- определение требований;
- проектирование системы;
- изготовление системы;
- испытание;
- корректировка;
- поставка или использование.
При применении такого принципа разработки каждого программного объекта соответствующие работы и задачи процесса разработки обычно выполняют последовательно (см. рисунок C.1). Однако они могут быть частично выполнены параллельно в случаях перекрытия последовательных работ.
Каскадная модель жизненного цикла по существу реализует принцип однократного выполнения каждого из следующих видов деятельности в их естественных границах:
- установление потребностей пользователя;
- определение требований;
- проектирование системы;
- изготовление системы;
- испытание;
- корректировка;
- поставка или использование.
При применении такого принципа разработки каждого программного объекта соответствующие работы и задачи процесса разработки обычно выполняют последовательно (см. рисунок C.1). Однако они могут быть частично выполнены параллельно в случаях перекрытия последовательных работ.
 | |
| 500 × 440 пикс. Открыть в новом окне | |
Рисунок С.1 - Пример каскадной модели
Когда несколько программных объектов разрабатывают одновременно, для всех этих объектов работы и задачи процесса разработки могут быть выполнены параллельно. Процессы сопровождения и эксплуатации обычно реализуют после процесса разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки.
C.1.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
a) требования к объектам определены недостаточно четко;
b) система обычно слишком велика, чтобы все работы по ее созданию выполнять однократно;
c) предполагаемые скорые изменения в технологиях работ;
d) возможные текущие изменения требований к системе;
e) ограниченность ресурсов, например средств или персонала;
f) промежуточный продукт может быть непригоден для использования.
С.1.2 Преимущества
Преимущества использования данной модели:
Преимущества использования данной модели:
a) однократное представление всех возможностей (характеристик) системы;