Жизненный цикл и модели жизненного цикла

Основным элементом системы управления региональным транспортным процессом является региональный (городской) информационный центр транспортной логистики. Их непрерывная работа обеспечивает правильное функционирование «нервной системы» региона и, с точки зрения ИО, связана с ключевыми характеристиками, приведёнными на рис. 2.3.

Рис. 2.3. Ключевые характеристики элементов информационного центра

Управление современным информационно-логистическим центром состоит из множества задач, основными из которых является:

· Мониторинг – непрерывный сбор информации и анализ всей инфраструктуры центра;

· Составление отчётов – о производительности ресурса, объёму и эксплуатации, проводится периодически;

· Подготовка к работе – процесс обеспечения КТС, ИО и ПО – необходимых компонентов для работы центра.

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

Жизненный цикл информации

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

Управление жизненным циклом информации (ILM) – это упреждающая стратегия, позволяющая организации с ИТ эффективно управлять данными на протяжении их жизненного цикла в соответствии с заранее установленной политикой предприятия (организации). Это позволяет ИТ-компаниям оптимизировать инфраструктуру хранения данных для максимальной отдачи вложений.

ILM-стратегии должны обладать следующими характеристиками:

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

· Централизованное управление – подчинение управления принципам выбранной стратегии;

· Целостный подход – всеобщее соблюдение выбранных принципов;

· Открытость – обеспечение возможности работы с различными ИС (по типам платформ хранения данных и операционных систем);

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

ILM-стратегии состоит из четырёх видов деятельности:

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

· Выполнение стратегии посредством механизмов управления информацией не всём периоде её жизни от создания до удаления;

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

· Организация уровневого хранения ресурсов для их распределения по классам данных и хранение информации разных уровней ценности в соответствующем типе инфраструктуры.

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

ILM-стратегия обладает следующими преимуществами:

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

· Упрощённое управление путём интеграции шагов обработки и интерфейсов с индивидуальными механизмами и роста автоматизации;

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

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

· Снижение общей стоимости владения (ТСО) благодаря приведению издержек по инфраструктуре и управлению в соответствие с ценностью информации. В результате ресурсы не расходуются напрасно, а комплексный подход перестает быть управлением менее ценных данных за счёт более ценных.

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

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

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

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

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

3. Организационные (управление, обучение и др.).

Разработка ИС включает в себя все работы (анализ, проектирование и реализацию) по созданию ИС в целом и её компонентов в соответствии с заданными требованиями. Это:

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

· подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов;

· материальное обеспечение обучения персонала и т.д.

Эксплуатация – это работы по внедрению компонентов ИС в эксплуатацию (конфигурирование БД и АРМ, обеспечение ЭД, проведение обучения персонала и т.д.) и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ИС в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.

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

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

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ИС, прежде всего процессы её разработки и сопровождения. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями отражены в проекте стандарта ISO 12207-2.

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

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

Наибольшее распространение получили две модели:

· Каскадная модель (рис. 2.4);

· Спиральная модель (рис. 2.5).

Рис. 2.4. Каскадная модель разработки ИС

Рис. 2.5. Спиральная модель жизненного цикла ИС,

где 1 – анализ, 2 – определение требований, 3 – проектирование,

4 – интеграция, 5 – реализация и тестирование, 6 – эксплуатация.

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

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

· Логическая последовательность этапов позволяет осуществить их планирование с привязками к срокам реализации и затратам на них.

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

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

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

Такой подход назывался также «продолжающимся проектированием». Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: «быстрое прототипирование» (rapid prototyping approach или fast-track).

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

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

CASE-технологии

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

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

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

CASE-технология (Computer Aided Software Engineering) – это программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО и БД, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, и другие процессы.

CASE-средства вместе с системным ПО и КТС образуют полную среду разработки ИС.

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

Стандарт проектирования должен устанавливать:

· набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

· требования к конфигурации АРМ разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;

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

Стандарт оформления проектной документации должен устанавливать:

· комплектность, состав и структуру документации на каждой стадии проектирования;

· требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

· требования к настройке CASE-средств обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

· правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

· правила использования клавиатуры и мыши;

· правила оформления текстов помощи;

· перечень стандартных сообщений;

· правила обработки реакции пользователя.

Рис. 2.6. Стандарты CASE-средств

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

Рис. 2.7. Модель процесса оценки и выбора

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

· нескольких CASE-средств и выбор одного или более из них;

· одного или более CASE-средств и сохранение результатов для последующего использования;

· выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

Как видно из рисунка, входной информацией для процесса оценки является:

· определение пользовательских потребностей;

· цели и ограничения проекта;

· данные о доступных CASE-средствах;

· список критериев, используемых в процессе оценки.

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

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

Элементы процесса включают:

· цели, предположения и ограничения, которые могут уточняться в ходе процесса;

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

· критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

· формализованные результаты оценок одного или более средств;

· рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

Термин «пользовательские требования» далее означает именно такие формализованные требования. Пользователь должен определить конкретный порядок действий и принятия решений с любыми необходимыми итерациями.

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

Определение списка критериев основано на пользовательских требованиях и включает:

· выбор критериев для использования из приведенного далее перечня;

· определение дополнительных критериев;

· определение области использования каждого критерия (оценка, выбор или оба процесса);

· определение одной или более метрик для каждого критерия оценки;

· назначение веса каждому критерию при выборе.