|
|
@@ -0,0 +1,295 @@
|
|
|
+# Модели жизненного цикла АИС.
|
|
|
+
|
|
|
+### Содержание
|
|
|
+
|
|
|
+1.Описание моделей ЖЦ
|
|
|
+
|
|
|
+* Каскадная модель
|
|
|
+
|
|
|
+* Спиральная модель
|
|
|
+
|
|
|
+* Инкреметная модель
|
|
|
+
|
|
|
+2.Вопросы
|
|
|
+
|
|
|
+3.Вывод
|
|
|
+
|
|
|
+4.Список литературы
|
|
|
+
|
|
|
+**Модель ЖЦ** – это некоторая структура, определяющая последовательность осуществления процессов, действий и решения задач, возникающих на протяжении ЖЦ, а также взаимосвязи между этими процессами, действиями и задачами.
|
|
|
+
|
|
|
+Она не зависит от специфики АС и условий, в которых она будет разрабатывается и эксплуатироваться, поэтому не существует общих моделей для любого случая. Выбор модели ЖЦ определяется сложностью АС, ее масштабом, желанием заказчика, предпочтениями разработчика и другими условиями. При этом все работы на этапах должны быть обеспечены необходимым программным инструментарием.
|
|
|
+
|
|
|
+## Модели ЖЦ
|
|
|
+
|
|
|
+##### Каскадная модель
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Каждая стадия заканчивается получением некоторых результатов, кото-рые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому программному обеспечению, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
|
|
|
+
|
|
|
+Каскадная модель может использоваться при создании информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают, как правило, системы с высокой критичностью: сложные системы с большим количеством задач вычислительного характера, системы управления производственными процессами повышенной опасности и другие.
|
|
|
+
|
|
|
+###### Основные этапы разработки
|
|
|
+
|
|
|
+1.Анализ требований заказчика.
|
|
|
+
|
|
|
+На данном этапе проводится детальное исследование проблемы, и четко формулируются требования заказчика. На выходе формируется **техническое задание**, согласованное всеми сторонами.
|
|
|
+
|
|
|
+**Техническое задание** – это документ или несколько документов, определяющих цель, структуру, свойства и методы какого-либо проекта, и исключающие двусмысленное толкование различными исполнителями.
|
|
|
+
|
|
|
+Иными словами — это инструмент коммуникации между заказчиком и исполнителем, который помогает выстроить линию общения с помощью создания внутри него некоего абстрактного элемента, наделенного видением, чувствами и знаниями заказчика.
|
|
|
+
|
|
|
+2.Проектирование.
|
|
|
+
|
|
|
+На этом этапе разрабатываются проектные решения, удовлетворяющие требованиям ТЗ. Если разрабатывается устройство, то определяется перечень комплектующих устройств, типы микросхем и схемные реализации.
|
|
|
+
|
|
|
+Если разрешенная ИС, то на этом этапе определяются все объекты или таблицы БД, связи между таблицами, перечень атрибутов и список ключевых атрибутов для каждой таблицы.
|
|
|
+
|
|
|
+Определяются тип и правила запросов в БД и формы представления входных и выходных документов и определяются формы отчетов, и вся эта информация оформляется в виде **технического проекта**.
|
|
|
+
|
|
|
+3.Разработка.
|
|
|
+
|
|
|
+На этом этапе осуществляется разработка конкретного программного обеспечения в соответствие с техническим проектом. Выходом этапа является готовая система с документацией который является **эскизным проектом**.
|
|
|
+
|
|
|
+4.Тестирование и опытная эксплуатация.
|
|
|
+
|
|
|
+Здесь осуществляется проверка разработанного программного обеспечения на соответствие требованиям ТЗ и требованиям заказчика. Выходом является протокол тестирования о соответствии разработанной системе техническому заданию.
|
|
|
+
|
|
|
+5.Сдача готового продукта.
|
|
|
+
|
|
|
+На данном этапе происходит сдача готового продукта. Также подготавливаются инструкции пользователя, излагаются требования к организации АС.
|
|
|
+
|
|
|
+###### Достоинства
|
|
|
+
|
|
|
+* на каждом этапе формируется полный комплект проектной документации, а на заключительном – пользовательская документация;
|
|
|
+
|
|
|
+* выполнение работ в логической последовательности позволяет планировать сроки завершения работ и затраты на них.
|
|
|
+
|
|
|
+Но, существуют исследования по срокам разработок каскадной системы и считается 31% работ не выполняется; 53% перерасходуют бюджет и только 16% укладываются в бюджет и в сроки.
|
|
|
+
|
|
|
+###### Недостатки
|
|
|
+
|
|
|
+* длительное ожидание результатов. В процессе разработки могут устаревать модели автоматизируемого объекта;
|
|
|
+
|
|
|
+* ошибки и недоработки на любом из этапов, как правило, выявляются на последующих этапах, следовательно, необходим возврат на предыдущий этап работ, из-за чего срываются сроки работ;
|
|
|
+
|
|
|
+* сложность распараллеливания работ. Даже если проект можно разбить на подсистемы, то необходимо постоянное согласование разрабатываемых частей;
|
|
|
+
|
|
|
+* чрезмерная информационная перенасыщенность каждого из этапов;
|
|
|
+
|
|
|
+* сложность управления проектом. Необходимо хорошее административное управление для соблюдения сроков сдачи этапа и контроля полноты передаваемой документации;
|
|
|
+
|
|
|
+* высокий уровень риска и ненадежность инвестиций;
|
|
|
+
|
|
|
+* позднее обнаружение проблем;
|
|
|
+
|
|
|
+* выход из календарного графика, запаздывание с получением результа-тов;
|
|
|
+
|
|
|
+* избыточное количество документации;
|
|
|
+
|
|
|
+* невозможность разбить систему на части (весь продукт разрабатыва-ется за один раз);
|
|
|
+
|
|
|
+* высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.
|
|
|
+
|
|
|
+Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:
|
|
|
+
|
|
|
+* пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;
|
|
|
+
|
|
|
+* за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.
|
|
|
+
|
|
|
+
|
|
|
+В действительности эту модель принимают в виде **циклической**, когда можно вернуться на предыдущие этапы и выполнить необходимые доработки с учетом измененных требований или желаний заказчика.
|
|
|
+
|
|
|
+
|
|
|
+##### Спиральная модель
|
|
|
+
|
|
|
+Даная модель представляет собой **итерационный процесс** (последовательное приближение) разработки АС. Спиральная модель была разработана в середине 1980-х годов Барри Боэмом.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Она основана на классическом цикле Деминга PDCA (планируй-делай-проверяй-действуй). При использовании этой модели АС создается в несколько итераций (витков спирали) методом прототипирования
|
|
|
+
|
|
|
+В этой схеме возрастает роль этапов анализа и проектирования, так как именно на этих этапах проверяется и обосновывается реализуемость технических решений.
|
|
|
+
|
|
|
+**Итерация** – это законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия. Версии от итерации к итерации совершенствуются, чтобы, в конце концов, стать законченным продуктом.
|
|
|
+
|
|
|
+Каждый виток спирали соответствует созданию фрагмента или версии программного продукта, где уточняются цели и характеристики объекта, определяется его качество и планируются работы на следующий виток спирали.
|
|
|
+
|
|
|
+Здесь можно переходить на следующий этап, не дожидаясь полного завершения работ на предыдущем. Недоделанная работа выполняется на следующей итерации.
|
|
|
+
|
|
|
+Основная задача итерации – быстрое создание работоспособного продукта с целью демонстрации его пользователю, активизируя тем самым процесс уточнения и дополнения требований.
|
|
|
+
|
|
|
+Окончание работ по такой схеме осуществляется после того как заказчик полностью удовлетворен работой системы. При такой схеме легко вносить изменения в документацию каждого из этапов.
|
|
|
+
|
|
|
+**Прототип** — действующий компонент АС, реализующий отдельные функции и внешние интерфейсы. Каждая итерация соответствует созданию фрагмента или версии АС, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
|
|
|
+
|
|
|
+На каждой итерации оцениваются:
|
|
|
+
|
|
|
+* Риск превышения сроков и стоимости проекта
|
|
|
+
|
|
|
+* Необходимость выполнения еще одной итерации
|
|
|
+
|
|
|
+* Степень полноты и точности понимания требований к системе
|
|
|
+
|
|
|
+* Целесообразность прекращения проекта.
|
|
|
+
|
|
|
+* Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений).
|
|
|
+
|
|
|
+Принципиальные особенности спиральной модели:
|
|
|
+
|
|
|
+* отказ от фиксации требований и назначение приоритетов пользователь-ским требованиям;
|
|
|
+
|
|
|
+* разработка последовательности прототипов, начиная с требований наивысшего приоритета;
|
|
|
+
|
|
|
+* идентификация и анализ риска на каждой итерации;
|
|
|
+
|
|
|
+* использование каскадной модели для реализации окончательного про-тотипа;
|
|
|
+
|
|
|
+* оценка результатов по завершении каждой итерации и планирование следующей итерации.
|
|
|
+
|
|
|
+
|
|
|
+###### Достоинства
|
|
|
+
|
|
|
+* упрощение внесения изменений в проект при изменении требований заказчика;
|
|
|
+
|
|
|
+* отдельные элементы системы соединяются в единую систему постепенно. Т.к. интеграция идет при малом количестве соединяемых элементов, то и проблем при ее проведении меньше;
|
|
|
+
|
|
|
+* уменьшение уровня риска. Риск максимален в начале разработки и уменьшается в конце;
|
|
|
+
|
|
|
+* гибкость в управлении проектом. Можно вносить изменения в разрабатываемое изделие;
|
|
|
+
|
|
|
+* упрощается повторное использование компонентов. Общие компоненты выявляются на первых витках спирали и в дальнейшем могут усовершенствоваться;
|
|
|
+
|
|
|
+* получается более надежная и устойчивая система, т.к. по мере ее развития ошибки и слабые места обнаруживаются и исправляются на каждой итерации.
|
|
|
+
|
|
|
+* ускорение разработки (раннее получение результата за счет прототи-пирования);
|
|
|
+
|
|
|
+* постоянное участие заказчика в процессе разработки;
|
|
|
+
|
|
|
+* разбиение большого объема работы на небольшие части;
|
|
|
+
|
|
|
+* снижение риска (повышение вероятности предсказуемого поведения системы).
|
|
|
+
|
|
|
+Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
|
|
|
+
|
|
|
+
|
|
|
+###### Недостатки
|
|
|
+
|
|
|
+* сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);
|
|
|
+
|
|
|
+* сложность применения модели с точки зрения менеджеров и заказчи-ков (из-за привычки к строгому и детальному планированию);
|
|
|
+
|
|
|
+* напряженный режим работы для разработчиков (при краткосрочных итерациях).
|
|
|
+
|
|
|
+
|
|
|
+Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла.
|
|
|
+
|
|
|
+Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее — враг хорошего».
|
|
|
+
|
|
|
+Поэтому завершение итерации необходимо проводить строго в соответствии с планом, даже если не вся запланированная работа закончена. Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков
|
|
|
+
|
|
|
+Спиральная модель избавляет пользователей и разработчиков программного обеспечения от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкрети-зируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
|
|
|
+
|
|
|
+##### Инкрементная модель
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Представляет собой пример итеративного подхода к разработке программного обеспечения ИС, который предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включающий все фазы жизненного цикла в применении к созданию отдельных версий системы, обладающих меньшей функциональностью по сравнению с проектом, в целом.
|
|
|
+
|
|
|
+При этом на каждой итерации получается работающая версия программной системы, обладающая функциональностью всех предыдущих плюс текущей итерации. В результате финальной итерации получается конечный продукт, обеспечивающий реализацию всех требований.
|
|
|
+
|
|
|
+С точки зрения структуры жизненного цикла модель называют итеративной (говоря о процессе). С точки зрения развития продукта – инкрементной (имеется ввиду наращивание функциональности продукта).
|
|
|
+
|
|
|
+**Инкремент** – приращение, увеличение (например, в языке программирование – увеличение значения переменной на 1).
|
|
|
+
|
|
|
+Для каждого инкремента выполняется:
|
|
|
+
|
|
|
+* Анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;
|
|
|
+
|
|
|
+* Проектирование, на котором происходит проектирование архитектуры, до проектирование тех вещей, которые не были сделаны на предыдущем инкременте;
|
|
|
+
|
|
|
+* Разработка;
|
|
|
+
|
|
|
+* Тестирование.
|
|
|
+
|
|
|
+Важно, что каждый инкремент **заканчивается работающим продуктом**.
|
|
|
+
|
|
|
+###### Достоинства
|
|
|
+
|
|
|
+* на момент создания определенного инкремента требования стабилизируются, поскольку не являющиеся особо важными изменения отодвигаются на момент создания последующих инкрементов;
|
|
|
+
|
|
|
+* не требуется заранее тратить средства, необходимые для разработки всего проекта, поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска;
|
|
|
+
|
|
|
+* в результате выполнения каждого инкремента получается функциональный продукт;
|
|
|
+
|
|
|
+* ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);
|
|
|
+
|
|
|
+* риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);
|
|
|
+
|
|
|
+* в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика.
|
|
|
+
|
|
|
+###### Недостатки
|
|
|
+
|
|
|
+* в модели не предусмотрены итерации в рамках каждого инкремента;
|
|
|
+
|
|
|
+* определение полной функциональности системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов;
|
|
|
+
|
|
|
+* формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;
|
|
|
+
|
|
|
+* поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах;
|
|
|
+
|
|
|
+* для модели необходимо хорошее планирование и проектирование;
|
|
|
+
|
|
|
+* может возникнуть тенденция к оттягиванию решений трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки
|
|
|
+
|
|
|
+### Вопросы
|
|
|
+
|
|
|
+1.Что такое **Инкремент**?
|
|
|
+
|
|
|
+А) **приращение**
|
|
|
+
|
|
|
+Б) **увеличение**
|
|
|
+
|
|
|
+В) анализ
|
|
|
+
|
|
|
+2.Что предполагает из себя инкрементная модель?
|
|
|
+
|
|
|
+А) быстрое создание работоспособного продукта
|
|
|
+
|
|
|
+Б) **разбиение жизненного цикла проекта на последовательность итераций**
|
|
|
+
|
|
|
+В) осуществления разработки конкретного программного обеспечения
|
|
|
+
|
|
|
+3.Основные этапы разработки Каскадная модель
|
|
|
+
|
|
|
+А) **Анализ требований заказчика**
|
|
|
+
|
|
|
+Б) **Разработка**
|
|
|
+
|
|
|
+В) **Проектирование**
|
|
|
+
|
|
|
+4.Что такое **Протатип**?
|
|
|
+
|
|
|
+А) быстрое создание работоспособного продукта с целью демонстрации его пользователю
|
|
|
+
|
|
|
+Б) это инструмент коммуникации между заказчиком и исполнителем
|
|
|
+
|
|
|
+В) **действующий компонент АС, реализующий отдельные функции и внешние интерфейсы**
|
|
|
+
|
|
|
+## Вывод
|
|
|
+
|
|
|
+Модели жизненного цикла информационных систем предназначены для использования, в первую очередь, разработчиками этих систем. Очень важно выбрать именно такую модель, которая будет востребована при реальной эксплуатации, в наибольшей степени отвечая характеру проекта и реальным условиям его реализации.
|
|
|
+
|
|
|
+## Список литературы
|
|
|
+
|
|
|
+https://studfile.net/preview/7657340/page:5/
|
|
|
+
|
|
|
+https://edu.tltsu.ru/sites/sites_content/site216/html/media67140/lec3_is-2.pdf
|
|
|
+
|
|
|
+https://www.zinref.ru/000_uchebniki/02800_logika/011_lekcii_raznie_33/298.htm
|
|
|
+
|
|
|
+https://moluch.ru/archive/91/19862/
|
|
|
+
|
|
|
+https://studref.com/364008/informatika/zhiznennyy_tsikl_avtomatizirovannyh_informatsionnyh_sistem
|
|
|
+
|
