Файл: GOSY.doc

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

Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler, 2004], например, определяет эволюционную модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] пишет: “Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада.”

Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:

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

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

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

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

Рис.3.2. Инкрементная стратегия

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

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

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

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

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

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

Спиральная стратегия

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

Рис. 3.3. Спиральная стратегия

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

Достоинства модели:

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

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

• обеспечивает большую гибкость в управлении проектом;

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

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

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

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

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

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

 Сравнительный анализ моделей 

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

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

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

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

При разработке системы под итоговым продуктом и промежуточным программным обеспечением согласно [12] следует понимать:

· ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

· модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;

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

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

В соответствии с приведенной классификацией итоговым продуктом для любой из моделей жизненного цикла является обязательная к передаче версия или очередь системы. Разработка очередями характерна при инкрементной стратегии. В качестве промежуточного программного обеспечения следует рассматривать ревизии и модификации. Как было отмечено выше, частая передача ревизий и модификаций конечным пользователям (особенно занятым другими производственными делами) нежелательна. Согласно [12] смена версий информационных систем на железнодорожном транспорте должна выполняться не чаще одного - двух раз в год, а модификаций – не чаще раза в месяц.

Вопрос 3 – Создать док след вида.

Экзаменационный билет №5

Вопрос 1 – Преобразование на плоскости. Понятие однородных координат точки. Простейшие аффинные преобразования на плоскости: поворот, перенос, масштабирование.

Допустим, на плоскости введена прямолинейная координатная система. Тогда каждой точке M ставится в соответствие упорядоченная пара чисел (x, y) ее координат (рис. 1). Вводя на плоскости еще одну прямолинейную систему координат, поставим в соответствие той же точке M другую пару чисел – (x*, y*).

Рис. 1

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

                                      (*)

где    – произвольные числа, связанные неравенством:

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

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

Рис. 2 

 А. Поворот вокруг начальной точки на угол j  (рис. 2а) описывается формулами

                                                  Б. Растяжение (сжатие) вдоль координатных осей (рис. 2б) можно задать так:

                                         В. Отражение относительно оси абсцисс (рис. 2в) задается при помощи формул

                                         Г. Перенос (рис. 2г) обеспечивают соотношения

                                                  Как доказывается в курсе аналитической геометрии, любое преобразование вида (*) всегда можно представить как последовательное исполнение (суперпозицию) простейших преобразований вида А, Б, В и Г.          Для эффективного использования этих известных формул в задачах компьютерной графики более удобной является их матричная запись. Матрицы, для случаев А, Б и В легко строятся и имеют соответственно следующий вид: