Что такое жизненный цикл информационной системы
Проектирование информационных систем
Лекции
2. ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1. Структура жизненного цикла информационной системы.
2.2. Основные процессы жизненного цикла.
2.3. Организационные процессы жизненного цикла.
2.4. Вспомогательные процессы жизненного цикла.
2.5. Распределение обязанностей между участниками проекта.
Вопросы для самопроверки.
2.1. Структура жизненного цикла информационной системы
Понятие жизненного цикла (ЖЦ) является одним из ключевых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации [4].
Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02 «Информационная технология. Процессы жизненного цикла программных средств» [5]. Согласно стандарту структура жизненного цикла основывается на трех группах процессов.
Рис.2.1. Классификация процессов жизненного цикла
2.2. Основные процессы жизненного цикла
В следующей таблице предпринята попытка сопоставления стадий классического жизненного цикла (автор Уинстон Ройс, 1970 г.) [43], стандарта ИСО/МЭК 12207-02, ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00.
Таблица 2.1. Стадии (основные процессы) жизненного цикла информационной системы
| Классический ЖЦ | ИСО / МЭК 12207 | ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00 | ||
| Стадия | Основные этапы (работы) | |||
| Формирование требований | Заказ | Формирование требований к ИС | Технико- экономическое обоснование1 (ТЭО) | 1. Обследование объекта и обоснование необходимости создания ИС. 2. Формирование требований Заказчика к ИС. 3. Оформление договора между Разработчиком и Заказчиком. |
| Анализ требований | Разработка | Разработка концепции ИС (для комплексных многоуровневых и интегрированных систем) | 1. Поиск путей удовлетворения требований Заказчика на уровне концепции создаваемой системы (структура, функции, программно-техническая платформа, режимы). 2. Рассмотрение альтернативных вариантов концепции системы, их анализ и выбор лучшей концепции. | |
| Проектирование | Техническое задание (ТЗ) | Разработка, согласование и утверждение ТЗ на создание ИС. | ||
| Эскизный проект (для комплексных многоуровневых и интегрированных систем) | Разработка предварительных проектных решений2 по системе и ее частям. | |||
| Пилот-проект (макетирование3, прототипирование) (при необходимости) | 1. Разработка частей проекта для испытаний в реальных, но ограниченных условиях функционирования с целью проверки предварительно принятых решений. 2. Проведение испытаний на головном объекте или стенде и анализ результатов испытаний. | |||
| Технический проект | 1. Разработка проектных решений по системе и ее частям. 2. Разработка документации на ИС и ее части. 3. Разработка документации на поставку изделий для комплектования ИС и/или технических заданий на их разработку. 4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации (строительство, монтаж, наладка и др.). | |||
| Кодирование (реализация) | Рабочая документация | 1. Разработка рабочей документации на систему и ее части. 2. Разработка программных и технических средств и/или адаптация приобретаемых. 3. Тестирование средств. | ||
| Тестирование | Интеграция и тестирование | 1. Загрузка БД типовыми исходными данными и тестами. 2. Интеграция программ и тестирование в имитированной среде. 3. Интеграция программных средств с аппаратными в реальной операционной и внешней среде. 4. Тестирование в реальной среде. 5. Разработка комплекта документации для пользователей. | ||
| Эксплуатация | Поставка и эксплуатация | Ввод в действие на головном объекте (ввод в эксплуатацию, внедрение) | 1. Подготовка объекта автоматизации к вводу ИС в действие. 2. Подготовка персонала. 3. Комплектация ИС поставляемыми изделиями. 4. Проведение предварительных испытаний4 и передача ИС для опытной эксплуатации5. 5. Проведение опытной эксплуатации. 6. Проведение приемочных испытаний6 по сдаче ИС в постоянную эксплуатацию. | |
| Тиражирование (при внедрении на нескольких объектах) | 1. Передача эталона загрузочных модулей ПО и эксплуатационной документации в группу сопровождения или ОФАП7 ОАО «РЖД». 2. Тиражирование документации. 3. Обучение и консультации пользователей. 4. Поставка ПО и документации на объекты внедрения. | |||
| Сопровождение и эксплуатация | Сопровождение (авторский надзор) и эксплуатация | 1. Выполнение работ в соответствии с гарантийными обязательствами8. 2. Оказание научно-технических услуг в послегарантийный период9. 3. Разработка методики оформления отчетов об ошибках и предложениях на изменение версий. 4. Учет состояния конфигураций ИС. | ||
Примечания:
1. Не по ГОСТ и ОРММ ИСЖТ.
2. Основные проектные решения на создание ИС включают в себя определение:
– функциональной и организационной структур системы;
– состава и структуры комплекса технических и программных средств;
– применяемых инструментальных средств;
– технологии обработки информации;
– состава, структуры и технологии ведения информационной базы;
– входных и выходных форм;
– алгоритмов обработки данных.
3. Цель макетирования (прототипирования) – снять неопределенность в требованиях Заказчика.
4. Предварительные испытания информационной системы проводят для определения ее работоспособности и решения вопроса о возможности приемки ее в опытную эксплуатацию.
5. Опытную эксплуатацию проводят с целью определения фактических значений количественных и качественных характеристик информационной системы; готовности персонала к работе с ней; фактической эффективности ее работы; корректировки (при необходимости) документации.
6. Приемочные испытания проводят для определения соответствия информационной системы ТЗ, оценки качества опытной эксплуатации и решения вопроса о возможности приемки ИС в постоянную (промышленную) эксплуатацию.
7. ОФАП – отраслевой фонд алгоритмов и программ.
8. Гарантийные обязательства (выполняются бесплатно согласно договору):
– устранение выявленных недостатков и ошибок;
– внесение необходимых изменений в программы и документацию;
– внесение изменений в технологический процесс;
– консультации пользователей.
9. Послегарантийные обязательства (выполняются за отдельную плату):
– анализ функционирования системы;
– выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений и установление причин этих отклонений;
– устранение выявленных недостатков и обеспечение стабильности эксплуатационных характеристик ИС;
– внесение необходимых изменений в документацию на ИС;
– передача очередных версий.
В табл. 2.1 отсутствует процесс поставки из стандарта ИСО/МЭК 12207-02, так как он определяет работы, выполняемые на всем протяжении жизненного цикла. Эти работы связаны с управлением и обеспечением проекта, начиная с момента подготовки договора и заканчивая сопровождением.
Согласно ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00 допускается:
– исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях;
– объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект»;
– выполнять отдельные этапы работ до завершения предшествующих стадий;
– параллельное во времени выполнение этапов работ;
– включение дополнительных этапов работ.
2.3. Организационные процессы жизненного цикла
В следующей таблице приведена краткая характеристика организационных процессов.
Таблица 2.2. Организационные процессы жизненного цикла
| Организационный процесс | Работы |
| Управление проектами | Планирование и управление процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности. |
| Создание инфраструктуры проекта | Установление и обеспечение инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы. |
| Обучение | Планирование и проведение обучения персонала, включая разработку учебных материалов. При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. Например, разработчики должны быть обучены технологиям и средствам программирования, принятым в организации, и даже обучены правильно внедрять и обучать конечных пользователей работе с системой. Как бы это ни парадоксально звучало, но обучать правильной методике и приемам обучения тоже необходимо. |
| Усовершенствование | Оценка, контроль и улучшение процессов жизненного цикла. |
2.4. Вспомогательные процессы жизненного цикла
В следующей таблице приведена краткая характеристика вспомогательных процессов.
Таблица 2.3. Вспомогательные процессы жизненного цикла
| Вспомогательный процесс | Работы |
| Документирование | Разработка, выпуск, редактирование, распространение и сопровождение документов, в которых нуждаются все заинтересованные лица. |
| Управление конфигурацией (конфигурационное управление) | Определение и установление состояния программных объектов в системе. Управление изменениями и выпуском объектов. Обеспечение полноты, совместимости и правильности объектов. Управление хранением, обращением и поставкой объектов. |
| Обеспечение качества | Обеспечение соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам. |
| Верификация | Работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации. |
| Аттестация | Работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы. |
| Аудит | Работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора. |
| Совместный анализ | Оценка состояния или результатов какой-либо работы (системы). |
| Разрешение проблем | Анализ и устранение проблем, обнаруженных при реализации проекта. |
2.5. Распределение обязанностей между участниками проекта
В процессе разработки и эксплуатации системы участвует определенный круг лиц (представители заказчика и разработчика), заинтересованных в успешной реализации проекта. В этом процессе между ними распределяются роли, за каждой из которых закрепляется определенный набор функций (обязанностей). При этом один и тот же человек может выступать в разных ролях (качествах). Так, например, один и тот же человек может быть проектировщиком и программистом, в то же время в проекте может принимать участие несколько экспертов, проектировщиков или программистов. В следующей таблице приведен типичный список ролей и их функций.
Таблица 2.4. Роли участников в проекте
| Роль | Функции |
| Руководитель (менеджер) проекта | Ищет потенциальных заказчиков. Заключает договор на разработку системы. Отвечает за планирование сроков и ресурсов. Выполняет управление и контроль за ходом выполнения проекта. Отвечает за взаимодействие с заказчиком. |
| Эксперт-технолог | Делает постановку задачи. Определяет (совместно с системным аналитиком) основные функциональные и нефункциональные требования к системе. Определяет технологию использования разрабатываемой системы. Консультирует разработчиков в процессе создания системы. Участвует в процессе приемки системы в эксплуатацию. |
| Системный аналитик (архитектор, главный конструктор) | Определяет функциональные и нефункциональные требования к системе, а также технологию ее использования. Выполняет анализ требований и ищет пути их реализации на уровне концепции системы. Задает архитектуру (скелет) системы и несет ответственность за соответствие моделей системы заданной архитектуре (отвечает за проектирование). Квалифицированный аналитик должен быть специалистом в области разработки программного обеспечения и должен быть (стать) специалистом в предметной области. |
| Проектировщик | Разрабатывает модели системы на основе архитектуры. |
| Программист | Реализует модели в виде программного обеспечения. |
| Тестировщик | Разрабатывает тесты и тестирует модели системы и разработанное программное обеспечение. |
| Технический редактор (писатель) | Готовит документацию для пользователей на разработанную систему. В комплект документации могут входить технологические инструкции, руководства пользователя, администратора системы, БД и т.д. |
| Инженер по внедрению | Внедряет разработанную систему на объекте автоматизации. В его функции может входить как первоначальная установка и настройка системы, так и обучение пользователей. |
| Пользователь | Эксплуатирует систему в штатном режиме. Кроме этого, желательно, чтобы пользователь (помимо эксперта-технолога) был вовлечен в процесс формирования требований к системе. |
У проекта должен быть один руководитель и, как правило, один системный аналитик. За остальные роли в крупных проектах отвечает обычно по несколько человек. В табл. 2.4 роли эксперта-технолога и пользователя выполняют представители заказчика, остальные роли – представители разработчика. Эксперты-технологи могут быть приглашены из сторонней организации. По мере необходимости в проекте могут принимать участие координатор работ (ответственный) со стороны заказчика, аудиторы и т. д.
Вопросы для самопроверки
1. Дайте определение понятию «жизненный цикл информационной системы».
2. Назовите группы процессов жизненного цикла.
3. Перечислите стадии жизненного цикла системы согласно ГОСТ 34.601-90 и дайте краткую характеристику каждой из них.
4. Перечислите роли участников проекта.
Источник
Жизненный цикл информационной системы – это процесс ее построения и развития.
Жизненный цикл информационной системы – период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации[1].
Стандарты жизненного цикла ИС
- ГОСТ 34.601-90
- ISO/IEC 12207:1995 (российский аналог – ГОСТ Р ИСО/МЭК 12207-99)
- Custom Development Method (методика Oracle)
- Rational Unified Process (RUP).
- Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
- Экстремальное программирование (англ. Extreme Programming, XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
Стандарт ГОСТ 34.601-90
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:
- Формирование требований к АС
- Обследование объекта и обоснование необходимости создания АС
- Формирование требований пользователя к АС
- Оформление отчета о выполнении работ и заявки на разработку АС
- Разработка концепции АС
- Изучение объекта
- Проведение необходимых научно-исследовательских работ
- Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
- Оформление отчета о проделанной работе
- Техническое задание
- Разработка и утверждение технического задания на создание АС
- Эскизный проект
- Разработка предварительных проектных решений по системе и ее частям
- Разработка документации на АС и ее части
- Технический проект
- Разработка проектных решений по системе и ее частям
- Разработка документации на АС и ее части
- Разработка и оформление документации на поставку комплектующих изделий
- Разработка заданий на проектирование в смежных частях проекта
- Рабочая документация
- Разработка рабочей документации на АС и ее части
- Разработка и адаптация программ
- Ввод в действие
- Подготовка объекта автоматизации
- Подготовка персонала
- Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
- Строительно-монтажные работы
- Пусконаладочные работы
- Проведение предварительных испытаний
- Проведение опытной эксплуатации
- Проведение приемочных испытаний
- Сопровождение АС.
- Выполнение работ в соответствии с гарантийными обязательствами
- Послегарантийное обслуживание
Эскизный, технический проекты и рабочая документация – это последовательное построение все более точных проектных решений по всем видам обеспечения информационной системы. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели.
Стандарт ISO/IEC 12207/ и его применение
Стандарт ISO/IEC 12207:1995 «rmation Technology – Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ИС. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.
Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения. Связи по входным данным при этом сохраняются.
Процессы жизненного цикла ИС
- Основные:
- Приобретение (действия и задачи заказчика, приобретающего ИС)
- Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
- Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
- Эксплуатация (действия и задачи оператора – организации, эксплуатирующей систему)
- Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение – внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
- Вспомогательные
- Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)
- Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ИС для определения состояния компонентов ИС, управления ее модификациями).
- Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
- Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
- Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
- Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
- Аудит (определение соответствия требованиям, планам и условиям договора)
- Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
- Организационные
- Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
- Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
- Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
- Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
- Инициирование приобретения
- Подготовка заявочных предложений
- Подготовка и корректировка договора
- Надзор за деятельностью поставщика
- Приемка и завершение работ
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
- Формирование требований к системе
- Формирование списка программных продуктов
- Установление условий и соглашений
- Описание технических ограничений (среда функционирования системы и т. д.)
Стадии жизненного цикла ИС, взаимосвязь между процессами и стадиями
Модель жизненного цикла ИС – структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ ИС включает в себя:
- Стадии
- Результаты выполнения работ на каждой стадии
- Ключевые события – точки завершения работ и принятия решений.
Стадия – часть процесса создания ИС, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ИС.
Модели жизненного цикла ИС
Каскадная модель
Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
- Формирование требований
- Проектирование
- Реализация
- Тестирование
- Ввод в действие
- Эксплуатация и сопровождение
Спиральная модель
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ИС создается в несколько итераций (витков спирали) методом прототипирования.
Прототип – действующий компонент ИС, реализующий отдельные функции и внешние интерфейсы. Каждая итерация соответствует созданию фрагмента или версии ИС, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
- Риск превышения сроков и стоимости проекта
- Необходимость выполнения еще одной итерации
- Степень полноты и точности понимания требований к системе
- Целесообразность прекращения проекта.
Один из примеров реализации спиральной модели – англ. Rapid Application Development, метод быстрой разработки приложений).
Итерационная модель
Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: RUP, MSF, XP.
Литература
- Братищенко В.В. Проектирование информационных систем. – Иркутск: Изд-во БГУЭП, 2004. – 84 с.
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2000.
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. – М.: Интернет-университет информационных технологий – ИНТУИТ.ру, 2005.
- Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 2000. – 240 с.
Примечания
- ↑ Стандарт IEEE Std 610.12, Глоссарий
Wiki Foundation. 2010.
Источник