double arrow

Модели ЖЦ ИС

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:

Каскадная модель (70-80г.г.) — предполагает переход на следующий этап после полного окончания работ по предыдущему этапу (рис.4).

Рис. 4. Каскадная модель

Поэтапная модель с промежуточным контролем (80-85г.г.) — итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоёмкость по сравнению с каскадной моделью; однако время жизни каждого из этапов растягивается на весь период разработки (рис.5).

Рис. 5. Поэтапная модель

Спиральная модель (86-90г.г.) — делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путём создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нём уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации (рис.6).

Рис. 6. Спиральная модель

Специалистами отмечаются следующие преимущества спиральной модели:

· накопление и повторное использование программных средств, моделей и прототипов;

· ориентация на развитие и модификацию ПО в процессе его проектирования;

· анализ риска и издержек в процессе проектирования.

Главная особенность индустрии ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоёмкости последующих этапов. Более того, нерешённые вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счёте, приводят к неуспеху всего проекта. Рассмотрим эти этапы более подробно.

Анализ требований является первой фазой разработки ПО, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе даётся ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем ПО известно немало примеров неудачной реализации проекта именно из-за неполноты и нечёткости определения системных требований.

Список требований к разрабатываемой системе должен включать:

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

· описание выполняемых системой функций;

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

Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются:

· архитектура системы, её функции, внешние условия, распределение функций между аппаратурой и ПО;

· интерфейсы и распределение функций между человеком и системой;

· требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



Сейчас читают про: