Модель жизненного цикла программы это

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

Стандарт ISO/IEC 12207 не предлагает конкретные модель жиз­ненного цикла и методы разработки ПП. Положения стандарта являются общими для любых моделей жизненного цикла, мето­дов и технологий разработки ПП.

Стандарт описывает структуру процессов жизненного цикла ПП, но не уточняет, как выполнить действия и задачи, включен­ные в эти процессы.

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

Тестировщик с нуля / Урок 7. Модели разработки ПО. Водопадная, итерационная и V-модель

Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:

каскадная модель, или «водопад» (Waterfall model);

V-образная модель (V-shaped model);

модель прототипирования (Prototype model);

модель быстрой разработки приложений, или RAD-модель (RAD — Rapid Application Development model);

многопроходная модель (Incremental model); спиральная модель (Spiral model).

Краткие характеристики каждой из перечисленных моделей приведены в таб-лице 1.

Таблица 1- Модели жизненного цикла разработки программного продукта

Название	Характеристики
Каскадная модель	Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы. Разрабатываемое программное обеспечение не доступно для изменений
V-образная модель	Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования
Модель прототипирования	Создается «быстрая» частичная реализация сис­темы до составления окончательных требований. Обеспечивается обратная связь между пользо­вателями и разработчиками в процессе выпол­нения проекта. Используемые требования не полные
Модель быстрой разработки приложений	Проектные группы небольшие (3. 7 человек) и составлены из высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 мес) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки
Многопроходная модель	Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки. Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации
Спиральная модель	Охватывает каскадную модель. Расчленяет фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с ПП на более раннем этапе благодаря прототипам

2) Каскадная модель

«Модели жизненного цикла программного обеспечения»

В однородных информационных системах 1970-х и 1980-х годов прикладные ПП представляли собой единое целое. Для разработ­ки такого типа ПП применялась каскадная модель, или «водопад» (waterfall) показанная на рисунке 8).

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

Требования к разрабатываемому ПП, определенные на этапе формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждый этап завершается выпус­ком полного комплекта документации, достаточной для того, что­бы разработка могла быть продолжена другой командой разработ­чиков. Критерием качества разработки при таком подходе являет­ся точность выполнения спецификаций технического задания. При этом основное внимание разработчиков сосредоточивается на до­стижении оптимальных значений технических характеристик раз­рабатываемого ПП — производительности, объема занимаемой памяти и др.

Преимущества каскадного способа:

на каждой стадии формируется законченный набор проектной документации, от-вечающий критериям полноты и согласованности; выполняемые в логичной по-следовательности стадии работ позволяют планировать сроки завершения всех работ и соответ­ствующие затраты.

Каскадный подход хорошо зарекомендовал себя при построе­нии инфор-мационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все тре­бования с целью предоставить разработчикам свободу реализо­вать их технически как можно лучше. В эту категорию попада­ют сложные системы с большим числом задач вычислительного характера, системы реального времени и др.В то же время данный подход обладает рядом существенных недостатков, обусловленных прежде всего тем, что реальный процесс разработки ПП никогда полностью не укладывается в такую жесткую схему. Этот процесс носит, как правило, итерационный характер: резуль­таты очередного этапа часто вызывают изменения в проект­ных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к преды­дущим этапам и уточнении или пересмотре ранее принятых ре­шений. В результате реальный процесс разработки принимает иной вид рисунок 9.

Изображенную на рисунке.9 схему часто относят к отдельной так называемой модели с проме­жуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя и увеличивают весь период разработки.

Основными недостатками каскадного подхода являются суще­ственное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.

Практика показывает, что на начальной стадии проекта пол­ностью и точно сформулировать все требования к будущей систе­ме не удается.

Это объясняется следующими причинами:

пользователи не в состоянии сразу изложить все свои требо­вания и не могут предвидеть, как они изменятся в ходе разра­ботки;

за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

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

Рисунок. 3.1. Каскадная модель

Рисунок 3.2.Схема реального

процесса разработки програм-

Та­ким образом, пользователи могут внести существенные замеча­ния только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их из­менения в течение длительного периода создания ПП пользова­тели получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.

3) V-образная модель

Эта модель представленная на рисунке 10 была разработана как разновидность кас­кадной модели, в которой особое внимание уделяется ве-рифика­ции и аттестации ПП. Модель показывает, что тестирование про­дукта обсуждается, проектируется и планируется, начиная с ран­них этапов жизненного цикла разработки на рисунке 10 этот процесс обозначен штриховыми стрел-ками.

От каскадной модели V-образная модель унаследовала после­довательную структуру, в соответствии с которой каждая после­дующая фаза начинается только после успешного завершения предыдущей фазы.

Данная модель основана на систематическом подходе к про­блеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление тре­бований. Проектирование разделяется на высокоуровневое и де­тальное (низкоуровневое). Разработка включает в себя кодирова­ние, а обзор — различные виды тестирования.

На модели хорошо просматриваются взаимосвязи между ана­литическими фазами И фазами проектирования, которые предшествуют кодированию и тестированию.

Рисунок 10- V – образная модель

Штриховые стрелки по­казывают, что эти фазы надо рассматривать параллель-но.

Модель включает в себя следующие фазы:

составление требований к проекту и планирование — определя­ются систем-ные требования и выполняется планирование работ;

составление требований к продукту и их анализ — составляется полная спе-циификация требований к программному продукту;

высокоуровневое проектирование — определяются структура ПП, взаимосвязи между основными его компонентами и реализуемые ими функции;

детальное проектирование — определяется алгоритм работы каж­дого компонента;

кодирование — выполняется преобразование алгоритмов в го­товое программ-мное обеспечение;

модульное тестирование — выполняется проверка каждого ком­понента или модуля ПП;

интеграционное тестирование — осуществляются интеграция ПП и его тести-рование;

системное тестирование — выполняется проверка функциони­рования ПП после помещения его в аппаратную среду в соответ­ствии со спецификацией требований;

эксплуатация и сопровождение — запуск ПП в производство. На этой фазе в ПП могут вноситься поправки и может выполняться его модернизация.

большая роль придается верификации и аттестации ПП, начи­ная с ранних стадий его разработки, все действия планируются;

предполагаются аттестация и верификация не только самого ПП, но и всех полученных внутренних и внешних данных;

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

Кроме перечисленных достоинств модель обладает и рядом недостатков:

не учитываются итерации между фазами;

нельзя вносить изменения на разных этапах жизненного цикла;

тестирование требований происходит слишком поздно, поэто­му внесение изменений влияет на выполнение графика работ.

Данную модель целесообразно использовать при разработке программных продуктов, главным требованием для которых яв­ляется высокая надежность.

Рисунок 11- Модель прототипирования

Потенциальные пользователи работают с этим прототипом опре­деляя его сильные и слабые стороны, о результатах сообщают раз­работчикам ПП. Таким образом, обеспечивается обратная связь между пользователями и разработчи-ками, которая используется для изменения или корректировки спецификации требований к ПП. В результате такой работы продукт будет отражать реальные потребности пользователей.

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

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

Модель прототипирования обладает целым рядом преимуществ:

взаимодействие заказчика с разрабатываемой системой начи­нается на раннем этапе;

благодаря реакции заказчика на прототип сводится к миниму­му число неточностей в требованиях;

снижается вероятность возникновения путаницы, искажения информации или недоразумений при определении требований к ПП, что приводит к созданию более качественного ПП;

в процессе разработки всегда можно учесть новые, даже не­ожиданные требования заказчика;

прототип представляет собой формальную спецификацию, воп­лощенную в ПП;

прототип позволяет очень гибко выполнять проектирование и разработку, включая несколько итераций на всех фазах жизнен­ного цикла разработки;

заказчик всегда видит прогресс в процессе разработки ПП;

возможность возникновения противоречий между разработчи­ками и заказчиками сведена к минимуму;

уменьшается число доработок, что снижает стоимость разра­ботки:

возникающие проблемы решаются на ранних стадиях, что рез­ко сокращает расходы на их устранение;

заказчики принимают участие в процессе разработки на про­тяжении всего жизненного цикла и в конечном итоге в большей степени довольны результатами работы.

Кроме указанных достоинств модели прототипирования при­сущ и целый ряд недостатков:

решение сложных задач может отодвигаться на будущее;

заказчик может предпочесть получить прототип, а не закон­ченную полную версию ПП;

прототипирование может неоправданно затянуться;

перед началом работы неизвестно, сколько итераций придется выполнить.

Модель прототипирования рекомендуется применять в следу­ющих случаях:

требования к ПП заранее неизвестны,

требования не постоянны или неудачно сформулированы;

требования необходимо уточнить;

нужна проверка концепции;

существует потребность в пользовательском интерфейсе;

выполняется новая, не имеющая аналогов разработка;

разработчики не уверены в том, какое решение следует выб­рать.

4) Модель быстрой разработки приложений (RAD-модель)

В RAD-модели представленной на рисунке 12 конечный пользователь играет реша­ющую роль. В тесном взаимодействии с разработчиками он уча­ствует в формировании требований и апробации их на работа­ющих прототипах. Таким образом, в начале жизненного цикла на конечного пользователя выпадает большая часть работы, но в результате этого создаваемая система формируется более быстро.

В традиционном жизненном цикле разработки большую часть работы составляют программирование и тестирование. При авто­матизации программирования и повторном использовании кода, применяемых в RAD-модели, большую часть работы составляют планирование и проектирование.

На рисунке 12, поясняющем принцип RAD-модели, указаны эта­пы процесса разработки и отображено участие заказчиков (штри­ховая линия) на каждом из них.

Модель включает в себя следующий фазы:

составление требований и планирование — осуществляются с использованием так называемого метода совместного планирова­ния требований (планирование работ по созданию ПП и состав­ление требований к ПП выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых за­дач;

описание пользователя — проектирование ПП, выполняемое при непосредственном участии заказчика;

создание — детальное проектирование, кодирование и тести­рование ПП, а также поставка его заказчику;

сопровождение — приемочные испытания, установка ПП и обу­чение пользователей.

Модель обладает следующими достоинствами:

использование современных инструментальных средств позво­ляет сократить время цикла разработки;

привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым ПП;

повторно используются компоненты уже существующих про­грамм.

В то же время ей присущи и недостатки:

если заказчики не могут постоянно участвовать в процессе раз­работки, то это может негативно сказаться на ПП;

для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;

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

Рассмотренную RAD-модель можно применять при разработке ПП, которые хорошо поддаются моделированию, когда требова­ния к ПП хорошо известны, а заказчик может принять непосред­ственное участие в процессе разработки.

Рисунок 12- RAD- модель

5) Многопроходная модель

Многопроходная модель — это несколько итераций процесса построения прототипа ПП с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности ПП.

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

Преимущества многопроходной модели:

в начале разработки требуются средства только для разработки и реализации основных функций ПП;

после каждого инкремента получается функциональный про­дукт;

снижается риск неудачи и изменения требований;

улучшается понимание как разработчиками, так и пользовате­лями ПП требований для более поздних итераций;

Раздел 2. Создание программного продукта

Источник: studopedia.su

Основы тестирования. Часть 4. Модели жизненного цикла.

В третьей части мы познакомились с понятием SDLC. Думаю, у части читающих могли возникнуть довольно обоснованные вопросы: «Действительно ли следуя этапам можно разработать качественный продукт? Что делать, если в ходе тестирования найдена ошибка и требуется доработать продукт, а этап разработки уже пройден?». Это базовые вопросы, которые приходят в голову, но если поразмыслить, можно придумать намного больше.

И тут нам на помощь приходят модели жизненного цикла. Для начала стоит дать определение.

Модель жизненного цикла ПО — описание того, как проходит процесс разработки ПО, какие этапы проходит ПО — от рождения идеи до завершения использования и что происходит с ПО на этих этапах.

Таких моделей достаточно много. В основном в литературе описываются следующие:

1. Code and fix (модель кодирования и устранения ошибок).
2. Waterfall Model (каскадная модель, или «водопад»).
3. V-model (V-образная модель, разработка через тестирование).
4. Incremental Model (инкрементная модель).
5. Iterative Model (итеративная или итерационная модель).
6. Spiral Model (спиральная модель).
7. The chaos model (модель хаоса).
8. Prototype Model (прототипная модель).

В данной статье я бы хотел рассмотреть четыре основные модели: водопадную, инкрементную, итеративную и инкрементно-итеративную как самые используемые в современной разработке.

Также хотел бы сразу ввести ещё один интересный термин:

Minimal Viable Product (MVP, минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.

Waterfall Model (каскадная модель, или «водопад»)

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

Waterfall Model

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

Плюсы модели:

• Простота;
• В один момент времени выполняется только один этап — легко контролировать результаты проекта;
• Можно рано спрогнозировать стоимость проекта (за счёт проработанных требований).

Минусы модели:

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

Инкрементная модель

Разработка в этой модели идёт по так называемым «инкрементам».

Инкремент — это постоянно увеличивающаяся величина.

Продукт в процессе разработки постоянно увеличивается, «наращивается».

Первое, что создаётся в этой модели, — минимально работающий продукт (MVP), который можно быстро выпустить на рынок, получить обратную связь от пользователей, а затем продолжить его развивать, постепенно расширяя и улучшая функционал приложения.

К примеру, при разработке онлайн-магазина, мы можем в рамках одной SDLC цепи (всех этапов, которые есть в рамках SDLC) разработать и протестировать авторизацию, регистрацию и возможность бронирования продукта(-ов) в магазине. Да, мы реализовали не все функции, которые хотим в конечном продукте, НО мы уже сейчас можем выпустить данный сайт на рынок и собрать обратную связь, а также получить первую прибыль.

Далее, повторяя такой процесс циклично для следующих версий мы всегда будем иметь на рынке новый и рабочий инкремент.

Источник: dzen.ru

Модели жизненного цикла для разработки программных систем

Аннотация: Описываются основные модели жизненного цикла, которые используются в практике проектирования программных систем. Рассмотрен стандарт ISO/IEC 12207 и подходы к формированию рабочих моделей жизненного цикла на его основе. Дана характеристика фундаментальных моделей ЖЦ (водопадной, спиральной, инкрементной, эволюционной) и стандартной модели

За десятилетия опыта построения программных систем был наработан ряд типичных схем последовательности выполнения работ при проектировании и разработки ПС. Такие схемы получили название моделей ЖЦ.

Модель жизненного цикла — это схема выполнения работ и задач в рамках процессов, обеспечивающих разработку, эксплуатацию и сопровождение программного продукта, и отражающая эволюцию ПС, начиная от формулировки требований к ней до прекращения пользоваться ею [1.14], [[2.2- 2.6].

Исторически в эту схему работ включают:

• разработку требований или технического задания;
• разработку системы или технического проекта;
• программирование или рабочее проектирование;
• пробную эксплуатацию;
• сопровождение и улучшение;
• снятие с эксплуатации.

Основное назначение моделей ЖЦ состоит в следующем:

• планирование и распределение работ между разработчиками и ресурсов, а также управление программным проектом;
• обеспечение взаимодействия между разработчиками проекта и заказчиком;
• наблюдение и контроль работ, оценивание промежуточных продуктов ЖЦ на соблюдение спецификаций требований, правильное их выполнение, оценивание продукта и реальных затрат, в том числе и по применяемым программным средствам и инструментам;
• согласование промежуточных результатов с заказчиком;
• проверка правильности конечного продукта путем его тестирования на запланированных и согласованных с заказчиком наборах тестов;
• оценивание соответствия характеристик качества полученного продукта заданным требованиям;
• обсуждение используемых процессов ЖЦ в плане оценки их возможностей и недостатков, проявившихся при их применении, а также определение направлений усовершенствования или модернизации ЖЦ и др.

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

2.1. Процессы ЖЦ стандарта ISO/IEC 12207

При выборе схемы модели ЖЦ для конкретной предметной области , решаются вопросы включения важных для создаваемого продукта видов работ или не включения несущественных работ . На сегодня основой формирования новой модели ЖЦ для конкретной прикладной системы является стандарт ISO /IEC 12207, который задает полный набор процессов (более 40), охватывающий все возможные виды работ и задач, связанных с построением ПС, начиная с анализа предметной области и кончая изготовлением соответствующего продукта. Данный стандарт содержит основные и вспомогательные процессы (рис. 2.1 и рис. 2.2).

увеличить изображение
Рис. 2.1. Схема основных процессов ЖЦ ПС

На рис. 2.1. представлены процессы, связанные непосредственно с разработкой ПС. К категории основных процессов относятся также «первичные» процессы, определяющие порядок подготовки договора на разработку ПС, мониторинг деятельности поставщиков ПС заказчику.

Стандарт ISO /IEC 12207 предоставляет структуру процессов ЖЦ, но не обязывает использовать все процессы в модели ЖЦ ПО или в конкретной методологии разработки ПО .

увеличить изображение
Рис. 2.2. Схема вспомогательных процессов ЖЦ ПС

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

Процессы, действия и задачи приведены в стандарте в наиболее общей естественной последовательности. Это не значит, что в такой же последовательности они должны быть применены в конкретной модели ЖЦ ПС. В зависимости от проекта процессы, действия и задачи стандарта выбираются, упорядочиваются и включаются в модель ЖЦ.

При применении они могут перекрывать, прерывать друг друга, выполняться итерационно или рекурсивно. Это определяет «динамический» характер стандарта и позволяет реализовать с его помощью произвольную модель ЖЦ ПС. Поэтому организации, которая намерена применить этот стандарт в своей работе, понадобятся дополнительные стандарты или процедуры, определяющие разные детали по применению выбранных элементов ЖЦ. Отметим, что комитет ISO выпускает руководства и процедуры, дополняющие стандарт 12207.

Кроме этого, стандарт ISO /IEC 12207 предоставляет основу для принятия ряда других связанных с ним стандартов, таких как

стандарты по управлению ПО , обеспечению качества, верификации и валидации, управлению конфигурацией, метриками ПО и т.д.

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

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

• если процесс вызывается процессом и только процессом , то принадлежит ;
• если функция вызывается более чем одним процессом, то она становится отдельным процессом;
• проверка любой функции в ЖЦ является обязательной.

Иными словами, если задача требуется более чем одному процессу, то она может стать процессом, используемым однократно или многократно на протяжении жизни конкретной системы. Каждый процесс должен иметь внутреннюю структуру, установленную в соответствии с тем, что он должен выполнять.

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

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

Важную роль при формировании модели ЖЦ имеют организационные аспекты:

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

Внедрение модели ЖЦ в практическую деятельность по созданию программного продукта позволяет упорядочить взаимоотношения между субъектами процесса разработки ПС и учитывать динамику модификации требований к проекту и к системе.

Пример. ЖЦ разработки ПС с задачами и действиями для процесса тестирования. Основное назначение процесса тестирования ЖЦ — выполнение задач процесса на основе входов ( входные данные для выполнения задач процесса) и выходов при завершении задач, а также ролей и действий исполнителей этих задач.

В соответствии со стандартом ISO /IEC 12207 были выявлены задачи тестирования и распределены по процессам ЖЦ ПС. В результате был получен единый непрерывный процесс тестирования разных ПС, задачами которого являются подготовка, проведение и оценивание результатов тестирования, которые распределились по 20 действиям (шагам) процесса разработки [2.7, 2.9]. Данный подход к тщательному тестированию ПС целесообразно применять, например, для систем реального времени.

На шаге подготовки осуществляется анализ рабочих продуктов процесса разработки ПС (входных для данного шагу процесса тестирования) для определения целей, объектов, сценариев и ресурсов тестирования, адекватных шагу тестирования. Результаты выполнения шагов подготовки тестирования должны фиксироваться в планах тестирования.

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

Каждый шаг процесса разработки состоит из набора решаемых задач, распределение по процессам и подроцессам ЖЦ (рис. 2.3).

Шаги процесса и отдельные задачи могут выполняться циклически для разных объектов ПС при их тестировании.

увеличить изображение
Рис. 2.3. ЖЦ разработки ПС с конкретизированными задачами на подпроцессах тестирования

Источник: intuit.ru