b) необходимость только единственной фазы перехода от старой системы к новой.
С.2 Инкрементная модель
Инкрементная модель жизненного цикла, называемая также запланированным усовершенствованием продукта, начинается с выдачи набора требований и реализует разработку последовательности конструкций. Первая конструкция содержит часть требований, в последующую конструкцию добавляют дополнительные требования и так далее до тех пор, пока не будет закончено создание системы. Для каждой конструкции выполняют необходимые процессы, работы и задачи, например анализ требований и создание архитектуры могут быть выполнены сразу, в то время как разработку технического проекта программного средства, его программирование и тестирование, сборку программных средств и их квалификационные испытания выполняют при создании каждой из последующих конструкций.
В данной модели при разработке каждой конструкции работы и задачи процесса разработки выполняют последовательно или частично параллельно с перекрытием. При частично одновременной разработке последовательных конструкций работы и задачи процесса разработки могут быть выполнены параллельно для ряда конструкций.
Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки (рисунок С.2).
Инкрементная модель жизненного цикла, называемая также запланированным усовершенствованием продукта, начинается с выдачи набора требований и реализует разработку последовательности конструкций. Первая конструкция содержит часть требований, в последующую конструкцию добавляют дополнительные требования и так далее до тех пор, пока не будет закончено создание системы. Для каждой конструкции выполняют необходимые процессы, работы и задачи, например анализ требований и создание архитектуры могут быть выполнены сразу, в то время как разработку технического проекта программного средства, его программирование и тестирование, сборку программных средств и их квалификационные испытания выполняют при создании каждой из последующих конструкций.
В данной модели при разработке каждой конструкции работы и задачи процесса разработки выполняют последовательно или частично параллельно с перекрытием. При частично одновременной разработке последовательных конструкций работы и задачи процесса разработки могут быть выполнены параллельно для ряда конструкций.
Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки (рисунок С.2).
 | |
| 500 × 315 пикс. Открыть в новом окне | |
 | Возможный информационный поток |
Т - требования; Пр - проектирование; П/Т - программирование и тестирование; В/ПП - ввод в действие и обеспечение приемки |
Рисунок C.2 - Пример инкрементной модели
С.2.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
а) требования к объектам определены недостаточно четко;
b) предусмотрены сразу все возможности системы;
c) предполагаемые скорые изменения в технологиях работ;
d) возможные текущие изменения требований к системе;
e) привлечение ресурсов (средств или персонала) на длительный период ограничено.
С.2.2 Преимущества
Преимущества использования данной модели:
Преимущества использования данной модели:
a) необходимость изначального использования характеристик системы;
b) пригодность для использования промежуточного продукта;
c) естественное разделение системы на наращиваемые компоненты (инкременты);
d) возможности наращивания привлекаемого персонала и средств.
С.3 Эволюционная модель
В эволюционной модели жизненного цикла систему также разрабатывают в виде отдельных конструкций, но в отличие от инкрементной модели требования изначально не могут быть полностью осознаны и установлены. В данной модели требования устанавливают частично и уточняют в каждой последующей конструкции (рисунок С.3).
В эволюционной модели жизненного цикла систему также разрабатывают в виде отдельных конструкций, но в отличие от инкрементной модели требования изначально не могут быть полностью осознаны и установлены. В данной модели требования устанавливают частично и уточняют в каждой последующей конструкции (рисунок С.3).
 | |
| 500 × 202 пикс. Открыть в новом окне | |
| | Информационный поток (уточненный) |
Т - требования; Пр - проект; П/Т - программирование и тестирование; В/ПП - ввод в действие и поддержка приемки |
Рисунок С.3 - Пример эволюционной модели
При таком методе для каждой конструкции работы и задачи процесса разработки выполняют последовательно или параллельно с частичным перекрытием.
Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки.
В таблице C.1 показано, как могут быть распределены процессы в модели жизненного цикла программного средства при создании ее для эволюционного жизненного цикла. В таблице С.1 учтены только работы процесса разработки. Отмеченные знаком " " объекты указывают на конкретную работу или задачу, а горизонтальные строки представляют собой шкалу времени. При необходимости может быть проведена дальнейшая детализация распределения процессов.
Таблица C.1 - Пример разметки эволюционной разработки
Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки.
В таблице C.1 показано, как могут быть распределены процессы в модели жизненного цикла программного средства при создании ее для эволюционного жизненного цикла. В таблице С.1 учтены только работы процесса разработки. Отмеченные знаком " " объекты указывают на конкретную работу или задачу, а горизонтальные строки представляют собой шкалу времени. При необходимости может быть проведена дальнейшая детализация распределения процессов.
Таблица C.1 - Пример разметки эволюционной разработки
Процесс/работа/ задача | Шкала времени | ||||||||||||||||||||||||||
Реализация процесса | |||||||||||||||||||||||||||
Анализ требований к системе и программному средству | |||||||||||||||||||||||||||
Архитектурный (эскизный) проект системы и программного средства | |||||||||||||||||||||||||||
Технический проект программного средства | |||||||||||||||||||||||||||
Программирова- ние и тестирование программного средства | |||||||||||||||||||||||||||
Сборка и квали- фикационные испытания программного средства | |||||||||||||||||||||||||||
Сборка и квали- фикационные испытания системы | |||||||||||||||||||||||||||
Ввод в действие и обеспечение приемки пpoграммного средства | |||||||||||||||||||||||||||
Процесс эксплуатации | |||||||||||||||||||||||||||
Процесс сопровождения | |||||||||||||||||||||||||||
Процесс доку- ментирования | |||||||||||||||||||||||||||
Процесс управления конфигурацией | |||||||||||||||||||||||||||
Процесс обеспечения качества | |||||||||||||||||||||||||||
Процесс верификации | |||||||||||||||||||||||||||
Процесс аттестации | |||||||||||||||||||||||||||
Процесс совместного анализа | |||||||||||||||||||||||||||
Процесс аудита | |||||||||||||||||||||||||||
Процесс решения проблемы | |||||||||||||||||||||||||||
Управление процессом разработки | |||||||||||||||||||||||||||
Управление процессом сопровождения | |||||||||||||||||||||||||||
Процесс создания инфраструктуры | |||||||||||||||||||||||||||
Процесс обучения | |||||||||||||||||||||||||||
Процесс усовер- шенствования | |||||||||||||||||||||||||||
С.3.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
а) все возможности системы предопределены изначально;
b) ограниченные возможности долговременного привлечения ресурсов (средств или персонала).
С.3.2 Преимущества
Преимущества использования данной модели:
Преимущества использования данной модели:
a) изначальное определение возможностей системы;
b) пригодность для использования промежуточного продукта;
c) естественное разделение системы на наращиваемые компоненты (инкременты);
d) привлечение персонала и средств по мере необходимости;
e) необходимая обратная связь с пользователем для полного понимания требований;
f) упрощение надзора за изменением технологии.
ПРИЛОЖЕНИЕ D (справочное). Примеры адаптации ГОСТ Р ИСО/МЭК 12207
D.1 Расширение области практического применения стандарта
Данный пример показывает, как ГОСТ Р ИСО/МЭК 12207 может быть практически внедрен в условиях договора путем введения новых работ, расширяющих область его применения (рисунок D.1). Пояснительный текст к данному примеру изложен подобно изложению ГОСТ Р ИСО/МЭК 12207.
Данный пример показывает, как ГОСТ Р ИСО/МЭК 12207 может быть практически внедрен в условиях договора путем введения новых работ, расширяющих область его применения (рисунок D.1). Пояснительный текст к данному примеру изложен подобно изложению ГОСТ Р ИСО/МЭК 12207.
 | |
| 650 × 875 пикс. Открыть в новом окне | |
Рисунок D.1 - Пример адаптации к практической деятельности
D.1.1 Сценарий
Ключевым аспектом анализа соответствующих требований является выбор метода удовлетворения конкретному требованию: исключительно программными решениями или изменением существующей практической деятельности в организации.
Примечание - В данном случае под практической деятельностью понимают способ решения задачи конкретным лицом при выполнении им повседневной работы. Например, обработка документа, которая может быть выполнена более эффективно в другой последовательности действий, внедренной при модернизации системы.
В ряде случаев внедрение системы, содержащей программные средства, может оказать существенное влияние на практическую деятельность соответствующей организации. Классическим примером этого являются управление системами трудовых ресурсов и информации, особенно при переходе с ручных операций на электронные. Также следует ожидать изменений в практической деятельности организации при поставке программного средства в виде готового пакета, который может быть использован с незначительными изменениями (настройками) или без них.
Ключевым аспектом анализа соответствующих требований является выбор метода удовлетворения конкретному требованию: исключительно программными решениями или изменением существующей практической деятельности в организации.
Примечание - В данном случае под практической деятельностью понимают способ решения задачи конкретным лицом при выполнении им повседневной работы. Например, обработка документа, которая может быть выполнена более эффективно в другой последовательности действий, внедренной при модернизации системы.
В ряде случаев внедрение системы, содержащей программные средства, может оказать существенное влияние на практическую деятельность соответствующей организации. Классическим примером этого являются управление системами трудовых ресурсов и информации, особенно при переходе с ручных операций на электронные. Также следует ожидать изменений в практической деятельности организации при поставке программного средства в виде готового пакета, который может быть использован с незначительными изменениями (настройками) или без них.
D.1.2 Решения по адаптации (практическому применению)
В процесс разработки внесены следующие дополнительные работы:
- практическая деятельность по анализу требований;
- практическая деятельность по проектированию и документированию;
- практическая деятельность по сборке.
В процесс эксплуатации внесена дополнительная работа - практическая деятельность по оценке.
В процесс разработки внесены следующие дополнительные работы:
- практическая деятельность по анализу требований;
- практическая деятельность по проектированию и документированию;
- практическая деятельность по сборке.
В процесс эксплуатации внесена дополнительная работа - практическая деятельность по оценке.
D.1.3 Обоснование адаптации (практического применения)
ГОСТ Р ИСО/МЭК 12207 описывает процессы жизненного цикла программных средств в общем контексте системы. Хотя основные работы по системе и процесс верификации из ГОСТ Р ИСО/МЭК 12207 обеспечивают некоторую поддержку управления практической деятельностью, предполагают, что наиболее эффективные общие решения будут приняты с учетом конкретной практической деятельности. Это особенно важно при значительном изменении существующей практической деятельности, когда требуется тщательный надзор и контроль изменений в деятельности организации.
Четыре последующих пункта изложены подобно их изложению в ГОСТ Р ИСО/МЭК 12207. В данных пунктах уточнены задачи, которые должны быть выполнены в каждой из дополнительных работ.
ГОСТ Р ИСО/МЭК 12207 описывает процессы жизненного цикла программных средств в общем контексте системы. Хотя основные работы по системе и процесс верификации из ГОСТ Р ИСО/МЭК 12207 обеспечивают некоторую поддержку управления практической деятельностью, предполагают, что наиболее эффективные общие решения будут приняты с учетом конкретной практической деятельности. Это особенно важно при значительном изменении существующей практической деятельности, когда требуется тщательный надзор и контроль изменений в деятельности организации.
Четыре последующих пункта изложены подобно их изложению в ГОСТ Р ИСО/МЭК 12207. В данных пунктах уточнены задачи, которые должны быть выполнены в каждой из дополнительных работ.
D.1.4 Практическая деятельность по анализу требований
Данная работа состоит из следующих задач, которые разработчик должен выполнить или обеспечить их выполнение в соответствии с условиями договора:
Данная работа состоит из следующих задач, которые разработчик должен выполнить или обеспечить их выполнение в соответствии с условиями договора:
а) существующая практическая деятельность должна быть проанализирована согласно работе по анализу требований к программному средству из процесса разработки с целью определить наиболее эффективные методы реализации системы. Данная работа должна охватывать обзор деловой деятельности, структуру организации, а также полномочия и обязанности каждого подразделения организации, вовлеченного в проект. Требования к практической деятельности должны быть документально оформлены;
b) практическая деятельность должна быть оценена с учетом нижеперечисленных критериев, а результаты этих оценок должны быть документально оформлены:
- отслеживания требований к системе и программному средству;
- полноты исходных данных, полученных от работодателей и профсоюзов;
- осуществимости реализации;
- согласованности с нормативными требованиями;
- выполнимости аудита системы.
- отслеживания требований к системе и программному средству;
- полноты исходных данных, полученных от работодателей и профсоюзов;
- осуществимости реализации;
- согласованности с нормативными требованиями;
- выполнимости аудита системы.
D.1.5 Практическая деятельность по проектированию и документированию
Для каждого конкретного вида практической деятельности данная работа состоит из следующих задач, при решении которых разработчик должен:
Для каждого конкретного вида практической деятельности данная работа состоит из следующих задач, при решении которых разработчик должен:
a) определить, в соответствии с интересами участников процесса, информационные потоки процесса, связанные с практической деятельностью;
b) создать предварительные версии процедурных (технологических) документов;
c) подготовить методические материалы, используемые при реализации договора, для обучения персонала соответствующей практической деятельности;
d) предусмотреть поощрительные мероприятия по стимулированию деятельности персонала организации заказчика, связанного с окончательным вводом системы в действие.
D.1.6 Практическая деятельность по сборке
Для каждого конкретного вида практической деятельности данная работа состоит из следующих задач, при решении которых разработчик должен:
Для каждого конкретного вида практической деятельности данная работа состоит из следующих задач, при решении которых разработчик должен: