Жизненный цикл ИС

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения.

Жизненный цикл (ЖЦ) любой системы - это непрерывный процесс, который начинается с момента принятия решения о ее создании и заканчивается в момент полного изъятия системы из эксплуатации.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

1. каскадная модель (70-85 г.г.);

2. спиральная модель (86-90 г.г.).

Использование каскадной модели ЖЦ предполагает, что весь процесс проектирования разбивается на этапы рис 7.

Рис.7. Каскадная модель ЖЦ ИС.

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

Положительные стороны применения каскадного подхода заключаются в следующем:

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

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

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

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

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

Рис. 8. Спиральная модель ЖЦ ИС.

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

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

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

Структура ЖЦ программного обеспечения ИС базируется в соответствии с международным стандартом ISO/IEC 12207 на трех группах процессов:

- основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

- организационные процессы (управление проектами, обучение и др.).

Рассмотрим определения некоторых из этих процессов.

Разработка включает все работы по созданию ИС в соответствии с заданными требованиями. Разработка состоит из 4-х этапов:

1. Формирование и анализ требований к системе (предпроектное обследование);

2. Концептуальное проектирование (создание информационной модели системы без привязки к типу ЭВМ и системных программных средств);

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

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

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

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

В документе обязательно должны быть описаны:

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

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

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

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

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

- сущности, необходимые для выполнения функций системы;

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

- требования к программным и информационным компонентам ПО, требования к СУБД (если проект предполагается реализовывать для нескольких СУБД, то требования к каждой из них, или общие требования к абстрактной СУБД и список рекомендуемых для данного проекта СУБД, которые удовлетворяют заданным условиям);

- что не будет реализовано в рамках проекта.

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

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

- функции - информация о событиях и процессах, которые происходят в бизнесе;

- сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.

Двумя классическими результатами анализа являются:

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

- модель "сущность-связь" (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

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

Сопровождение - э то поддержание системы в работоспособном состоянии в период эксплуатации.

Управление проектом относится к организационным процессам ЖЦ и связано с планированием работ, созданием коллектива разработчиков, контролем за сроками и качеством работ.

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

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

Дата добавления: 2014-12-27