Вопрос 2 – Каскадная, итерационная и спиральная модели жизненного цикла аис.
К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла:
каскадная;
инкрементная;
спиральная.
Дальнейшее рассмотрение моделей жизненного цикла ведется с использованием терминологии классического жизненного цикла
Каскадная стратеги
Каскадная стратегия (однократный проход, водопадная или классическая модель) подразумевает линейную последовательность прохождения стадий создания информационной системы (рис.3.1). Другими словами, переход с одной стадии на следующую происходит только после того, как будет полностью завершена работа на текущей.
Рис.3.1. Каскадная стратегия
Данная модель применяется при разработке информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования.
Достоинства модели:
на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские).
Недостатки модели:
реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;
жизненный цикл основан на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;
основной недостаток – результаты разработки доступны заказчику только в конце проекта. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС заказчик получает систему, не удовлетворяющую его потребностям.
Инкрементная стратегия
Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.
С точки зрения структуры жизненного цикла такую модель называют итеративной (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г) обеспечивают соотношения
Как доказывается в курсе аналитической
геометрии, любое преобразование вида
(*) всегда можно представить как
последовательное исполнение (суперпозицию)
простейших преобразований вида А, Б, В
и Г.
Для
эффективного использования этих
известных формул в задачах компьютерной
графики более удобной является их
матричная запись. Матрицы, для случаев
А, Б и В легко строятся и имеют соответственно
следующий вид:
Для решения задач весьма желательно
охватить матричным подходом все четыре
простейших преобразования (в том числе
и перенос), а, значит, и общее аффинное
преобразование. Этого можно достичь
путем описания произвольной точки
плоскости не двумя координатами, как
это было сделано выше, а упорядоченной
тройкой чисел.
Однородные координаты точки
Пусть M – произвольная точка плоскости с координатами x и y, вычисленными относительно заданной прямолинейной координатной системы. Однородными координатами этой точки называется любая тройка одновременно неравных нулю чисел x1, x2, x3, связанными с заданными числами x и y следующими соотношениями:
При решении задач компьютерной графики
однородные координаты обычно вводятся
так: произвольной точке M(x,
y) плоскости
ставится в соответствие точка M*(x,
y, 1) в пространстве
(рис. 3).
При помощи троек однородных координат и матриц третьего порядка можно описать любое аффинное преобразование на плоскости. Сравнивая уравнение (*) и нижеследующее, матричное:
Рис. 3
,
нетрудно заметить, что после перемножения выражений, стоящих в правой части последнего соотношения, получаются обе формулы (*) и тождество 1=1. Таким образом, сравниваемые записи являются равносильными.
Аффинные преобразования в пространстве
Для выполнения пространственных построений, аналогично двумерной задаче, три координаты точки (x, y, z) заменяются четверкой чисел (x, y, z, 1). Это дает возможность воспользоваться матричной записью и в более сложных трехмерных задачах.
Любое аффинное преобразование в трехмерном пространстве может быть представлено в виде суперпозиции вращений, растяжений, отражений и переносов. Математически все преобразования сводятся к перемножению матриц четвертого порядка. Например, матрица вращения вокруг оси абсцисс на угол j имеет вид:
.