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

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

 

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

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

• Требования: таблица 1.
• Команда разработчиков: таблица 2.
• Коллектив пользователей: таблица 3.
• Тип проекта и риски: таблица 4.

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

Отличительные категории проекта

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

 

 

Задание

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

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

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

 

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

 

2.Корпорация  по разработке электронных компонентов  недавно приняла решение вложить  средства в проектирование карманных  компьютеров (Personal digital assistants, PDA), по образу и подобию карманных компьютеров Palm Pilot. В этом случае предполагается применение сотовых модемов. Компания имеет значительный опыт в выпуске серий продуктов, аналогичных этому, и считает, что, продавая его по более низкой цене, достигнет успеха на рынке. Таким образом, организация хотела разработать рабочую модель, которая будет представлена на международной специализированной выставке по прошествии трех месяцев. Каков наиболее подходящий принцип построения жизненного цикла? В чем заключаются преимущества такого принципа для данного проекта? 

Прототипирование  — это процесс построения рабочей  модели системы. Прототип — это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.

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

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

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

 

3. Корпорация недавно завершила  трехлетний процесс разработки  глобальной системы менеджмента  конфигурации. Теперь она готова  перейти на следующую фазу, на  которой приблизительно каждые три месяца будет выпускаться новый вариант программного продукта. В каждый выпуск будет включено в среднем 12 новых свойств и соответствующее количество безошибочных вариантов. Над каждым выпуском будут работать команды, состоящие из 1-3 инженеров и находящиеся в Индии, России и Соединенных Штатах. Время, отведенное на разработку новых свойств = от 1 до 5 месяцев. Для некоторых свойств может возникнуть необходимость в выпуске нескольких вариантов вплоть до их полной реализации. Что представляет собой, на ваш взгляд, самый подходящий принцип построения жизненного цикла? В чем заключаются преимущества такого принципа для данного проекта?