Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Инкрементная модель жизненного цикла разработки ПО

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

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

Рис. 1.9. Инкрементная модель жизненного цикла

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

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

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

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

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

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

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

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

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

· ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);

· риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);

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

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

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

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

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

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

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

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

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

· заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены;

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

· для модели необходимо хорошее планирование и проектирование;

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

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

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

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

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

· степени важности различных свойств системы распределяется равномерно;

· при разработке программ, связанных с низкой или средней степенью риска;

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

· когда однопроходная разработка системы связана с большой степенью риска;

· когда результативные данные получаются через регулярные интервалы времени.

Выбор приемлемой модели жизненного цикла разработки ПО

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

1. Проанализировать следующие отличительные категории проекта, помещенные в таблицах 1.1 – 1.4.

2. Ответить на вопросы, приведенные для каждой категории, выбрав в качестве ответа слова «да» или «нет».

3. Расположить по степени важности вопросы, относящиеся к каждой категории, относительно проекта, для которого выбирается приемлемая модель.

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

Требования. Категория требований (таблица 1.1) состоит из вопросов относительно требований, которые предъявляет пользователь к проекту. В терминологии их иногда называют свойствами системы, которая будет создаваться в ходе данного проекта.

Табл. 1.1. Выбор модели жизненного цикла на основе характеристик требований

Требования Каскад- ная V-образ- ная Прототи- пирование Спираль- ная RAD Инкре- ментная
Являются ли требования легко определимыми и/или хорошо известными? Да Да Нет Нет Да Нет
Могут ли требования заранее определяться в цикле? Да Да Нет Нет Да Да
Часто ли будут изменяться требования в цикле? Нет Нет Да Да Нет Нет
Нужно ли демонстрировать требования с целью определения? Нет Нет Да Да Да Нет
Требуется ли для демонстрации возможностей проверка концепции? Нет Нет Да Да Да Нет
Будут ли требования отражать сложность системы? Нет Нет Да Да Нет Да
Обладает ли требование функциональными свойствами на раннем этапе? Нет Нет Да Да Да Да

 

Команда разработчиков. По возможности, в состав команды разработчиков лучше всего отобрать персонал еще до того, как будет выбрана модель жизненного цикла. Характеристики такой команды (таблица 1.2) играют важную роль в процессе выбора, поскольку она несет ответственность за удачное выполнение проекта и может оказать помощь в выборе адекватной модели.

Табл. 1.2. Выбор модели жизненного цикла на основе характеристик участников команды разработчиков

Команда разработчиков проекта Каскад- ная V-образ- ная Прототи- пирование Спираль- ная RAD Инкре- ментная
Являются ли проблемы предметной области проекта новыми для большинства разработчиков? Нет Нет Да Да Нет Нет
Является ли технология предметной области проекта новой для большинства разработчиков? Да Да Нет Да Нет Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков? Да Да Нет Да Нет Нет
Изменяются ли роли участников проекта во время жизненного цикла? Нет Нет Да Да Нет Да
Могут ли разработчики проекта пройти обучение? Нет Да Нет Нет Да Да
Является ли структура более значимой для разработчиков, чем гибкость? Да Да Нет Нет Нет Да
Будет ли менеджер проекта строго отслеживать прогресс команды? Да Да Нет Да Нет Да
Важна ли легкость распределения ресурсов? Да Да Нет Нет Да Да
Приемлет ли команда равноправные обзоры и инспекции? Да Да Да Да Нет Да

 

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

Табл. 1.3. Выбор модели жизненного цикла на основе характеристик коллектива пользователей

Коллектив пользователей Каскад- ная V-образ- ная Прототи- пирование Спираль- ная RAD Инкре- ментная
Будет ли присутствие пользователей ограничено в жизненном цикле? Да Да Нет Да Нет Да
Будут ли пользователи знакомы с определением системы? Нет Нет Да Да Нет Да
Буду ли пользователи ознакомлены с проблемами предметной области? Нет Нет Да Нет Да Да
Будут ли пользователи вовлечены во все фазы жизненного цикла? Нет Нет Да Нет Да Нет
Будет ли заказчик отслеживать ход выполнения проекта? Нет Нет Да Да Нет Нет

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

Табл. 1.4. Выбор модели жизненного цикла на основе характеристик типа проектов и рисков

Тип проекта и риски Каскад- ная V-образ- ная Прототи- пирование Спираль- ная RAD Инкре- ментная
Будет ли проект идентифицировать новое направление продукта для организации? Нет Нет Да Да Нет Да
Будет ли проект иметь тип системной интеграции? Нет Да Да Да Да Да
Будет ли проект являться расширением существующей системы? Нет Да Нет Нет Да Да
Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла? Да   Да   Да   Нет   Да   Нет  
Ожидается ли длительная эксплуатация продукта в организации? Да   Да   Нет   Да   Нет   Да
Должна ли быть высокая степень надежности? Нет   Да   Нет   Да   Нет   Да  
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения? Нет   Нет   Да   Да   Нет   Да  
Является ли график ограниченным? Нет   Нет   Да   Да   Да   ^ J  
Являются ли «прозрачными» интерфейсные модули? Да   Да   Нет   Нет   Нет   Да  
Доступны ли повторное используемые компоненты? Нет   Нет   Да   Да   Да   Нет  
Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)? Нет   Нет   Да   Да   Нет   Нет  

 

Подгонка модели жизненного цикла разработки ПО

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

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

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

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

1. Ознакомьтесь с различными моделями.

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

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

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

5. Сформулируйте набор фаз и действий, образующих каждую фазу.

6. Определите внутренние и внешние производимые продукты.

7. Определите шаблоны и внутреннее содержимое поставляемых продуктов.

8. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта.

9. Выполните оценку эффективности схемы жизненного цикла и проведите ее модернизацию там, где это необходимо.

Резюме

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

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

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

Задания к выполнению работ

1.Подготовьте краткое словесное описание Вашей задачи/подсистемы/системы, которая является предметомия?

2. Составьте матрицы, относящиеся к выбору модели ЖЦ Вашего проекта, ответив на вопросы, приведенные для каждой категории в таблицах 1.1-1.4 При этом для ответов Да – используйте, значение 1, ответов Нет – используйте, значение 0, все остальным ответам присвойте значения в интервале от 0 до 1, в зависимости от близости к Да или Нет

3. Расположите по степени важности вопросы, относящиеся к каждой категории, относительно Вашего проекта, для которого выбирается приемлемая модель.

4. Проанализируйте полученные результаты и сделайте выводы о приемлемой модели ЖЦ для Вашего проекта.

5. Подготовить ответы на контрольные вопросы

Номера контрольных вопросов взять у преподавателя.

6. Оформить в электронном или печатном виде отчет о выполнении работы.

В состав отчета входят:

· Письменные ответы на контрольные вопросы

· Краткое описание Вашей задачи/подсистемы/системы?

· Результаты выполнения практического задания

· Выводы по результатам практического задания

На титульном листе отчета должны быть указаны номер и тема практического занятия, ФИО и группа студента.

 


[1] В строительном проекте задача заключается в том, чтобы, имея хорошо понятный проект, определить все задачи, выделить соответствующие средства, определить действия и взаимозаменяемые компоненты, а затем выполнять задания так, чтобы бюджет и/или критический путь были минимальными.

 

Последнее изменение этой страницы: 2016-07-22

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...