Тема 1.2 Жизненный цикл АИС и модели жизненного цикла АИС

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

Жизненный цикл АИС –это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.

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

Добиться этого на протяжении всего ЖЦ АИС — довольно сложная по ряду объективных и субъективных причин задача, в результате подавляющее большинство проектов АИС внедряется с нарушениями качества, сроков или сметы; почти треть проектов прекращают свое существование незавершенными. По данным Standish Group в 1996 г. 84 % проектов АИС не были завершены в установленные сроки, в 1998 г. это число сократилась до 74 %, после 2000 г. оно не опускается ниже 50 %. Главной причиной такого положения является то, что уровень технологии анализа и проектирования систем, методов и средств управления проектами не соответствует сложности создаваемых систем, которая постоянно возрастает в связи с усложнением и быстрыми изменениями бизнеса.

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

Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):

• ГОСТ 34.601—90 — стандарт на стадии и этапы создания АИС, соответствующие каскадной модели ЖЦ ПО (рассматривается ниже). Приводится описание содержания работ на каждом этапе;

• 180/1ЕС 12207:1995 — стандарт на процессы и организацию жизненного цикла; распространяется на все виды заказного программного обеспечения; не содержит описания фаз, стадий и этапов;

• Custom Develoment Method (методология Oracle) — технологический материалпо разработке прикладных АИС, детализированный до уровня заготовок проектных документов в расчете на использование Oracle.Применяется для классической модели ЖЦ (предусмотрены все работы, задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.

• Rational Unified Process (методология RUP)— технологический материал по реализации итеративной модели разработки, включающей четыре фазы (цикл разработки): начало, исследование, построение и внедрение. Каждая фаза разбита на этапы (итерации), результатами которых являются версии для внутреннего или внешнего использования. Каждый цикл завершается генерацией очередной версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова проходит те же фазы. Суть работы в рамках RUP-методологии — создание и сопровождение моделей на базе UML;

• Microsoft Solution Framework (методология MSF) — технологический материал по реализации итеративной модели разработки, аналогично RUP включает четыре фазы: анализ, проектирование, разработку, стабилизацию; предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений;

• Extreme Programming (ХР) — экстремальное программирование (самая новая среди рассматриваемых методологий); сформировалось в 1996 г. Основой методологии является работа в команде, эффективные коммуникации между заказчиком и исполнителем в течение всего проекта; разработка АИС ведется с использованием последовательно дорабатываемых прототипов.

Стандарт ISO/IЕС 12207 в структуре жизненного цикла определяет процессы, которые выполняются при создании ПО АИС. Эти процессы подразделяют на три группы:

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

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

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

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

Разработка АИС включает все работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями. Этот процесс также предусматривает:

• оформление проектной и эксплуатационной документации;

• подготовку материалов, необходимых для тестирования разработанных программных продуктов;

• разработку материалов, необходимых для обучения персонала.

Как правило, составляющими процесса разработки являются стратегическое планирование, анализ, проектирование и реализация (программирование).

К процессу эксплуатации относятся:

• конфигурирование базы данных и рабочих мест пользователей;

• обеспечение пользователей эксплуатационной документацией;

• обучение персонала.

Основные эксплуатационные работы включают:

• непосредственно эксплуатацию;

• локализацию проблем и устранение причин их возникновения;

• модификацию программного обеспечения;

• подготовку предложений по совершенствованию системы;

• развитие и модернизацию системы.

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

К предварительным действиям при организации технического обслуживания АИС относятся:

• выделение наиболее ответственных узлов системы и определение для них критичности простоя (это позволит выделить наиболее критичные составляющие АИС и оптимизировать распределение ресурсов для технического обслуживания);

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

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

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

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

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

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

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

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

• выбор методов и инструментальных средств реализации проекта;

• определение методов описания состояния процесса разработки;

• разработку методов и средств испытаний созданного программного обеспечения;

• обучение персонала.

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов АИС.

Верификация — процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.

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

В 2002г. Был опубликован стандарт на процессы ЖЦ автоматизированных систем (ISO/IEC 15288 System Life cycle processes). В разработке стандарта участвовали специалисты из различных областей деятельности; учитывался практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ включены следующие группы процессов.

1. Договорные процессы:

• приобретение (внутренние решения или решения внешнего поставщика);

• поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

• управление окружающей средой предприятия;

• инвестиционное управление; в управление ЖЦ ИС;

• управление ресурсами;

• управление качеством.

3. Проектные процессы:

• планирование проекта;

• оценка проекта;

• контроль проекта;

• управление рисками;

• управление конфигурацией;

• управление информационными потоками;

• принятие решений.

4. Технические процессы:

• определение требований;

• анализ требований;

• разработка архитектуры;

• внедрение;

• интеграция;

• верификация;

• переход;

• аттестация;

• эксплуатация;

• сопровождение;

• утилизация.

5. Специальные процессы:

• определение и установка взаимосвязей исходя из задач и целей.

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

В 1970-х гг. корпорация IBM предложила методологию Business System Planning (BSP) или методологию организационного планирования.

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

Таблица 1.4. Стадии создания АИС (ISO/IEC 15288)

По опубликованным данным [19, 21] каждый этап разработки АИС требует определенных затрат времени. В основном (45—50 %) время уходит на кодирование, комплексное и автономное тестирование (рис.14). В среднем разработка АИС занимает одну треть всего ЖЦ системы (рис.1.5).

Рис.1.4. Распределение времени при разработке АИС

Рис. 1.5. Распределение времени при разработке, эксплуатации и сопровождении АИС

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

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

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

Модель ЖЦ АИС включает:

• стадии;

• результаты выполнения работ на каждой стадии;

• ключевые события или точки завершения работ и принятия решений.

В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС — каскадную, итерационную, спиральную.

I. Каскадная модельописывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970—80-х гг.

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

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

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

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

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

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

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

Ввод в действие

Тестирование

Реализация

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

Разработка требований

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

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

Преимущества каскадной модели:

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

2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.

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

Недостатки каскадной модели:

• существенная задержка в получении результатов;

• ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата;

• сложность параллельного ведения работ по проекту;

• чрезмерная информационная перенасыщенность каждого из этапов;

• сложность управления проектом;

•высокий уровень риска и ненадежность инвестиций.

Задержка в получении результатов проявляется в том, что последовательном подходе к разработке согласование результатов с заинтересованными сторонами производится только е завершения очередного этапа работ. В результате может оказаться, что разрабатываемая АИС не соответствует требованиям, и такие несоответствия могут возникать на любом этапе разработки; кроме того, ошибки могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязаны хорошо разбираться в тех предметных областях, для которых разрабатывается АИС.

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

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

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

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

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

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

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

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

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

II. Итерационная модель заключается в серии коротких циклов (шагов) по планированию, реализации, изучению, действию.

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

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

Недостатки итерационной модели:

· время жизни каждого этапа растягивается на весь период работки;

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

· запутанность архитектуры;

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

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

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

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

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

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

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

Преимущества итерационного подхода:

• итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

• при использовании спиральной модели отдельные элементы АИС интегрируются в единое целое постепенно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении;

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

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

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

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

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

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

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