Жизненный цикл (жц) по ис

ЖЦ ПО ИС является одним из базовых понятий методологии проектирования ИС

(System Development Life Cycl - ) – непрерывный процесс, кот. начинается с момента принятия решения о создании ИС и заканчивается в момент полного изъятия из эсплуатации.

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

Этапы проектирования ИС

1. Анализ (деятельности организации).

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

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

Конечные продукты этого этапа из схемы Захмана. на основании поставленных задач выбирается архитектура ПС

3. Релизация.

По готовым моделям реализация

4. Тетирование

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

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

   3. тесты на проверку надежности работы (проверка возможности отказов в ПО, проверка функциональности, показ заказчику и т.д.)

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

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

• каскадная

• поэтапная с промежуточным контролем

• спиральная

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

Каждый этап завершается выпуском комплекта документов, достаточных для того чтобы работа над ИС могла быть продолжена (в этом «+» модели)

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

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

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

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

ИС разрабатывается как некоторый проект.

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

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

Состав проектной документации.

Типы:

1. Организационно-распорядительная, определяющая правовые и хозяйственные отношения участников создания ИС

2. Предпроектная, включающая заявку на разработку ИС, ТЗ и технико-экономическое обоснование

3. Проектная, кот включает технический проект и рабочую документацию

2 + 3 = Техническая документация

Организационно-распорядительная создается на каждой стадии процесс проектирования.

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

ТЗ составляется на основе ГОСТа.

На стадии технического и рабочего проектирования на основе ТЗ создается комплекса проект, кот включает:

• пояснительную записку

• описание организационной структуры

• выбор техн средств

• описание постановок задач

• описание организации Иого обеспечения

• требование к ПО

• расчет экономической эффективности

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

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

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

1. По степени автоматизации

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

   2. компьютерное проектирование (CASE)

2. По степени использования типовых решений

   1. оригинального (индивидуального) проектирования, исп-ся когда проектирование начинается с «нуля»; (каноническое)

   2. типового проектирования, предполагают конфигурацию ИС из готовых типовых проектных решений

3. По степени адаптивности проектных решений

   1. методы реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов

   2. методы параметризация, когда проектные решения настраиваются в соответствии с изменяемыми параметрами

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