Заказать курсовые, контрольные, рефераты...
Образовательные работы на заказ. Недорого!

Область применения спиральной модели

РефератПомощь в написанииУзнать стоимостьмоей работы

Для организаций, которые не могут себе позволить выделить заранее все необходимые для выполнения проекта денежные средства, и когда в процессе разработки отсутствует финансовая поддержка; Выбор приемлемой модели жизненного цикла разработки ПО Выбор приемлемой модели жизненного цикла разработки ПО для проекта может осуществляться в ходе использования следующего процесса. При выполнении… Читать ещё >

Область применения спиральной модели (реферат, курсовая, диплом, контрольная)

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

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

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

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

для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

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

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

когда требования слишком сложные;

при разработке новой функции или новой серии продуктов;

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

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

в случае больших проектов;

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

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

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

с целью демонстрации качества и достижения целей за короткий период времени;

когда в процесс вовлекаются новые технологии, такие как впервые применяемые объектно-ориентированные принципы;

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

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

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

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

Требования: таблица 1.

Команда разработчиков: таблица 2.

Коллектив пользователей: таблица 3.

Тип проекта и риски: таблица 4.

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

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

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

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

В табл. 1−4 приведен набор матриц, предназначенных для использования на стадиях 1−5 процесса выбора модели жизненного цикла (см. предыдущую лекцию, «Основные процессы ЖЦ ПС»).

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

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

Требования.

Каскадная.

V-образная.

Прототипи-рование.

Спиральная.

RAD.

Инкрементная.

1. Являются ли требования легко определимыми и/или хорошо известными?

Да.

Да.

Нет.

Нет.

Да.

Нет.

2. Могут ли требования заранее определяться в цикле?

Да.

Да.

Нет.

Нет.

Да.

Да.

3. Часто ли будут изменяться требования в цикле?

Нет.

Нет.

Да.

Да.

Нет.

Нет.

4. Нужно ли демонстрировать требования с целью определения?

Нет.

Нет.

Да.

Да.

Да.

Нет.

5. Требуются ли для демонстрации возможностей или проверка концепции?

Нет.

Нет.

Да.

Да.

Да.

Нет.

6. Будут ли требования отражать сложность системы?

Нет.

Нет.

Да.

Да.

Нет.

Да.

7. Обладает ли требование функциональными свойствами на раннем этапе?

Нет.

Нет.

Да.

Да.

Да.

Да.

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

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

Команда разработчиков проекта.

Каскадная.

V-образная.

Прототипиро-вание.

Спиральная.

RAD.

Инкрементная.

1. Являются ли проблемы предметной области проекта новыми для большинства разработчиков?

Нет.

Нет.

Да.

Да.

Нет.

Нет.

2. Является ли технология предметной области проекта новой для большинства разработчиков?

Да.

Да.

Нет.

Да.

Нет.

Да.

3. Являются ли инструменты, используемые проектом, новыми для большинства разработчиков?

Да.

Да.

Нет.

Да.

Нет.

Нет.

4. Изменяются ли роли участников проекта во время жизненного цикла?

Нет.

Нет.

Да.

Да.

Нет.

Да.

5. Могут ли разработчики проекта пройти обучение?

Нет.

Да.

Нет.

Нет.

Да.

Да.

6. Является ли структура более значимой для разработчиков, чем гибкость?

Да.

Да.

Нет.

Нет.

Нет.

Да.

7. Будет ли менеджер проекта строго отслеживать прогресс команды?

Да.

Да.

Нет.

Да.

Нет.

Да.

8. Важна ли легкость распределение ресурсов?

Да.

Да.

Нет.

Нет.

Да.

Да.

9. Приемлет ли команда равноправные обзоры и инспекции, менеджмент (обзоры) заказчика, а также стадии?

Да.

Да.

Да.

Да.

Нет.

Да.

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

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

Коллектив пользователей.

Каскадная.

V-образная.

Прототипиро-вание.

Спиральная.

RAD.

Инкрементная.

1. Будет ли присутствие пользователей ограничено в жизненном цикле?

Да.

Да.

Нет.

Да.

Нет.

Да.

2. Будут ли пользователи знакомы с определением системы?

Нет.

Нет.

Да.

Да.

Нет.

Да.

3. Буду ли пользователи ознакомлены с проблемами предметной области?

Нет.

Нет.

Да.

Нет.

Да.

Да.

4. Будут ли пользователи вовлечены во все фазы жизненного цикла?

Нет.

Нет.

Да.

Нет.

Да.

Нет.

5. Будет ли заказчик отслеживать ход выполнения проекта?

Нет.

Нет.

Да.

Да.

Нет.

Нет.

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

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

Тип проекта и риски.

Каскадная.

V-образная.

Прототипиро-вание.

Спиральная.

RAD.

Инкрементная.

1. Будет ли проект идентифицировать новое направление продукта для организации?

Нет.

Нет.

Да.

Да.

Нет.

Да.

2. Будет ли проект иметь тип системной интеграции?

Нет.

Да.

Да.

Да.

Да.

Да.

3. Будет ли проект являться расширением существующей системы?

Нет.

Да.

Нет.

Нет.

Да.

Да.

4. Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла?

Да.

Да.

Да.

Нет.

Да.

Нет.

5. Ожидается ли длительная эксплуатация продукта в организации?

Да.

Да.

Нет.

Да.

Нет.

Да.

6. Должна ли быть высокая степень надежности?

Нет.

Да.

Нет.

Да.

Нет.

Да.

7. Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения?

Нет.

Нет.

Да.

Да.

Нет.

Да.

8. Является ли график ограниченным?

Нет.

Нет.

Да.

Да.

Да.

Да.

9. Являются ли «прозрачными» интерфейсные модули?

Да.

Да.

Нет.

Нет.

Нет.

Да.

10. Доступны ли повторно используемые компоненты?

Нет.

Нет.

Да.

Да.

Да.

Нет.

11. Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)?

Нет.

Нет.

Да.

Да.

Нет.

Нет.

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