Инкрементная (поэтапная модель с промежуточным контролем)

Инкрементная модель (англ. increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.

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

В начале работы над проектом определяются все основные требования к системе, подразделяются на более и менее важные.

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

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

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

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

· отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

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

· требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у её пользователей неприятие и только “затормозить” процесс перехода на новые технологии. Образно говоря, они могут просто “не переварить большой кусок, поэтому его надо измельчить и давать по частям”.

·

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

Достоинства:

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

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

· у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью.

Недостатки модели:

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

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

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

Подход rad

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

- небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

- короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

- определение функций, которые должна выполнять система;

- выделение наиболее приоритетных функций, требующих проработки в первую очередь;

- описание информационных потребностей. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков.

Кроме того, на данной стадии реализуются следующие задачи:

- ограничивается масштаб времени;

- устанавливаются временные рамки для каждой из последующих стадий.

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

Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО.

Проектирование.

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

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

- более детально рассматриваются процессы системы;

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

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

- определяется состав необходимой документации.

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

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

- входной элемент приложения (входной документ или экранная форма);

- выходной элемент приложения (отчет, документ, экранная форма)

- запрос (пара «вопрос/ответ»);

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

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

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

Результатом данной стадии должно быть:

- общая информационная модель системы;

- функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

- точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

- построенные прототипы экранных форм, отчетов, диалогов.

Реализация.

На этой стадии выполняется непосредственно сама быстрая разработка приложения.

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

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

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

Реализация системы завершается выполнением следующих работ:

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

- Производится физическое проектирование базы данных;

- формируются требования к аппаратным ресурсам;

- устанавливаются способы увеличения производительности;

- завершается разработка документации проекта.

Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

Внедрение.

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

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

- разрабатывается совершенно новая система;

- уже было проведено обследование организации и существует модель ее деятельности;

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

Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

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