Модели жизненного цикла АИС.

Содержание

1.Описание моделей ЖЦ

Каскадная модель
Спиральная модель
Инкреметная модель

2.Вопросы

3.Вывод

4.Список литературы

Модель ЖЦ – это некоторая структура, определяющая последовательность осуществления процессов, действий и решения задач, возникающих на протяжении ЖЦ, а также взаимосвязи между этими процессами, действиями и задачами.

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

Модели ЖЦ

Каскадная модель

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

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

Основные этапы разработки

1.Анализ требований заказчика.

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

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

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

2.Проектирование.

На этом этапе разрабатываются проектные решения, удовлетворяющие требованиям ТЗ. Если разрабатывается устройство, то определяется перечень комплектующих устройств, типы микросхем и схемные реализации.

Если разрешенная ИС, то на этом этапе определяются все объекты или таблицы БД, связи между таблицами, перечень атрибутов и список ключевых атрибутов для каждой таблицы.

Определяются тип и правила запросов в БД и формы представления входных и выходных документов и определяются формы отчетов, и вся эта информация оформляется в виде технического проекта.

3.Разработка.

На этом этапе осуществляется разработка конкретного программного обеспечения в соответствие с техническим проектом. Выходом этапа является готовая система с документацией который является эскизным проектом.

4.Тестирование и опытная эксплуатация.

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

5.Сдача готового продукта.

На данном этапе происходит сдача готового продукта. Также подготавливаются инструкции пользователя, излагаются требования к организации АС.

Достоинства

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

Но, существуют исследования по срокам разработок каскадной системы и считается 31% работ не выполняется; 53% перерасходуют бюджет и только 16% укладываются в бюджет и в сроки.

Недостатки

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

Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:

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

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

Спиральная модель

Даная модель представляет собой итерационный процесс (последовательное приближение) разработки АС. Спиральная модель была разработана в середине 1980-х годов Барри Боэмом.

Она основана на классическом цикле Деминга PDCA (планируй-делай-проверяй-действуй). При использовании этой модели АС создается в несколько итераций (витков спирали) методом прототипирования

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

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

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

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

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

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

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

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта
Необходимость выполнения еще одной итерации
Степень полноты и точности понимания требований к системе
Целесообразность прекращения проекта.
Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений).

Принципиальные особенности спиральной модели:

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

Достоинства

упрощение внесения изменений в проект при изменении требований заказчика;
отдельные элементы системы соединяются в единую систему постепенно. Т.к. интеграция идет при малом количестве соединяемых элементов, то и проблем при ее проведении меньше;
уменьшение уровня риска. Риск максимален в начале разработки и уменьшается в конце;
гибкость в управлении проектом. Можно вносить изменения в разрабатываемое изделие;
упрощается повторное использование компонентов. Общие компоненты выявляются на первых витках спирали и в дальнейшем могут усовершенствоваться;
получается более надежная и устойчивая система, т.к. по мере ее развития ошибки и слабые места обнаруживаются и исправляются на каждой итерации.
ускорение разработки (раннее получение результата за счет прототи-пирования);
постоянное участие заказчика в процессе разработки;
разбиение большого объема работы на небольшие части;
снижение риска (повышение вероятности предсказуемого поведения системы).

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

Недостатки

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

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

Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее — враг хорошего».

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

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

Инкрементная модель

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

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

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

Инкремент – приращение, увеличение (например, в языке программирование – увеличение значения переменной на 1).

Для каждого инкремента выполняется:

Анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;
Проектирование, на котором происходит проектирование архитектуры, до проектирование тех вещей, которые не были сделаны на предыдущем инкременте;
Разработка;
Тестирование.

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

Достоинства

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

Недостатки

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

Вопросы

1.Что такое Инкремент?

А) приращение

Б) увеличение

В) анализ

2.Что предполагает из себя инкрементная модель?

А) быстрое создание работоспособного продукта

Б) разбиение жизненного цикла проекта на последовательность итераций

В) осуществления разработки конкретного программного обеспечения

3.Основные этапы разработки Каскадная модель

А) Анализ требований заказчика

Б) Разработка

В) Проектирование

4.Что такое Протатип?

А) быстрое создание работоспособного продукта с целью демонстрации его пользователю

Б) это инструмент коммуникации между заказчиком и исполнителем

В) действующий компонент АС, реализующий отдельные функции и внешние интерфейсы

Вывод

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