14
- комплексная автоматизация деятельности предприятия;
- модульная структура позволяет внедрять каждый из модулей по
отдельности;
- формирование календарных планов для выполнения работ и установления
потребности в ресурсах.
На основании рассмотренной классификации автоматизированных
информационных систем можно сказать, что многие из них позволяют улучшить
процессы планирования и принятия управленческих решений.
Однако готовое решение не всегда позволяет учитывать масштабы и
специфику деятельности предприятия, поэтому многие предприятия предпочитают
выполнять собственную разработку.
1.2 Жизненный цикл и модели жизненного цикла АИС
Жизненный цикл информационной системы является периодом
существования системы от начала разработки до ее сдачи в эксплуатацию. В состав
жизненного цикла входят этапы и модели, позволяющие описать взаимосвязь
между процессами разработки и сдачи в эксплуатацию системы.
В соответствии с международным стандартом ISO/IEC 12207 все процессы
жизненного цикла в автоматизированной информационной системе разделяются на
три основные группы с выделением основных, вспомогательных и
организационных процессов [15, c.43].
В состав основных процессов входят покупка, поставка, разработка,
эксплуатация и дальнейшее сопровождение автоматизированной информационной
системы. Вспомогательные процессы включают в свой состав процессы
документирования, управления конфигурацией, обеспечения качества, решение
проблем, связанных с работой модулей, проведением аудита, аттестации,
совместной оценки и верификации системы. Организационные процессы связаны с
процессами создания IT-инфраструктуры, управления, обучения и
совершенствования.
15
Рассмотрим выделенные процессы жизненного цикла автоматизированной
информационной системы более детально. Процесс покупки предусматривает
взаимодействие заказчика и исполнителя.
Заказчик – это лицо или юридическая организация, выполняющая заказ
разработки или покупки информационной системы. Заказчиком реализуются
процессы инициирования, подготовки заявки, договора, а также контроля
деятельности разработчика и приемка информационной системы. На входе этого
процесса выполняются работы по обследованию предметной деятельности или
процесса, который подлежит автоматизации. Также выполняют анализ рынка
программного обеспечения для выявления аналогов и формирования концепции
разработки, проводят комплексное тестирование существующих решений. В
результате процесса формируется технико-экономическое обоснование на
разработку или внедрение информационной системы, составляется техническое
задание, заключается договор на поставку или разработку системы.
Вспомогательные процессы выполняют функции поддержки выполнения
основных процессов по разработке программного обеспечения и связаны с
выполнением проекта с необходимым уровнем качества, проверкой и
тестированием программного обеспечения [20, c.103].
Организационные процессы направлены на установку задач и действий,
выполняемых заказчиком и разработчиком в процессе реализации IT-проекта. Для
поддержки и практического применения международного стандарта ISO/IEC 12207
применяются такие технологические документы.
Наиболее известной моделью жизненного цикла является каскадная модель,
которая относится к стандартным моделям и предусматривает последовательное
выполнение процессов разработки автоматизированной информационной системы.
В состав этой модели входят такие процессы, как анализ требований,
проектирование, реализация и тестирование.
На этапе анализа требований ведется разработка технического задания, в
котором излагаются требования к функциональности разрабатываемого
программного продукта.
16
На этапе проектирования в соответствии с техническим заданием
производится разработка концептуальной, логической и физической моделей, а на
этапе реализации на основании выбранного языка программирования
разработчиком выполняется разработка пользовательского интерфейса,
включающего в свой состав различные модули и базу данных.
Выполненная разработка на этапе тестирования подвергается оценке
качества с последующим устранением возникающих ошибок в работе модулей и
передачей выполненных разработок заказчику.
Для каскадной модели характерен набор стадий, каждая из которых
выполняется последовательно. При этом следующая стадия не может быть начата
до тех пор, пока не завершена предыдущая. Для пользователя создана возможность
ознакомления с программным продуктом только после выполнения всех этапов
разработки [23, c.37].
Наиболее жестким ограничением этой модели является необходимость
строгого выполнения требований, изложенных в техническом задании. Это
позволяет минимизировать риски увеличения стоимости и невыполнения сроков,
установленных в договорах, заключенных заказчиком.
Более совершенной является каскадная модель с обратной связью, структура
которой приведена на рисунке 3.
Рисунок 3 – Схема каскадной модели с обратной связью
Как видно из рисунка 3, в этом случае все стадии выполняются
последовательно как при первой разработке программного продукта, так и при ее
совершенствовании. В этом случае следующий этап не может быть начат до
завершения предыдущего.
17
Процесс разработки выступает не просто линейной моделью, а включает в
свой состав различные итерации и действия, позволяющие совершенствовать
программный продукт.
Наиболее дорогостоящими этапами являются этапы утверждения требований
заказчика и проектирования модели будущей автоматизированной
информационной системы. Поэтому каскадная модель может применяться только в
том случае, когда все требования заранее известны и не подвергаются изменению в
процессе разработки системы [2, c.90].
Расширяет возможности каскадной модели жизненного цикла V-образная
модель, в основе которой находится планирование и тестирование разработанной
модели. Схема v-образной модели жизненного цикла разработки программного
обеспечения приведена на рисунке 4.
Рисунок 4 – Схема v-образной модели жизненного цикла
разработки программного обеспечения
Как видно из рисунка 4, в V-модели установлена взаимосвязь между каждой
фазой жизненного цикла и выделяется фаза тестирования. Горизонтальная и
вертикальная оси отображают уровни абстракции и время разработки.
Подобно каскадной модели этапы разработки выполняются
последовательно, но в V-модели допускается и параллельное выполнение работ. На
этапе определения требований производится сбор информации о потребностях
пользователя, а параллельно производится разработка функциональных и тестовых
примеров.
18
На уровне архитектурного проектирования производится разработка
компонентов интерфейса в соответствии с функциональными требованиями к
разрабатываемой автоматизированной информационной системе. На этом же этапе
проектируются и проводятся интеграционные испытания работы модулей с
последующим формированием спецификации [10, c.142].
Тестовые примеры также разрабатываются для оценки работы программного
обеспечения. Как правило, в этой модели изменения неизбежны, поэтому
разработчиком формируются системные требования, которые оперативно
реагируют на условия и выполненные этапы разработки.
Для поддержки итерации можно использовать модели с приращениями и
эволюционные модели. Модели с приращениями предусматривают разработку
спецификации и дизайна будущего программного продукта, определение этапов
сдачи его в эксплуатацию.
Эволюционные модели отличаются тем, что в этом случае используется
спираль, то есть разрабатывается первая версия продукта, а затем выпускаются его
более совершенные версии.
Основными отличиями между моделями являются подходы к формированию
требований. По моделям с приращениями заказчик может определить требования к
программному обеспечению и выяснить, какие из них являются для него наиболее
важными.
Итерационная модель предусматривает разработку программного продукта
по итерации, каждая из которых включает определенные этапы и процессы. При
этом требования заказчика к разработке увеличиваются по мере реализации каждой
из итераций.
Схема итерационной модели с перекрытием итераций приведена на рисунке
5.
19
Рисунок 5 – Схема итерационной модели с перекрытием итераций
Как видно из рисунка 5, на основании требований и предварительного
проектирования выполняется разработка нескольких версий проекта. При этом
каждый из этих процессов включает последовательную реализацию этапов
проектирования, реализации и тестирования.
Модель с приращениями имеет преимущества в сравнении с обычными
моделями [14, c.93]:
- заказчику не нужно ожидать, пока разработка автоматизированной
информационной системы не будет полностью выполнена. На первой итерации
определяется соответствие полученного продукта требованиям заказчика;
- заказчик может использовать предыдущие итерации для формирования
требований, позволяющих улучшить программное обеспечение.
В сравнении с моделями приращений эволюционные модели применяются в
тех случаях, когда требования к разработке на первоначальном этапе сформировать
сложно. Среди наиболее известных эволюционных моделей следует отметить
спиральную модель. Спиральная модель была предложена Боэмом Б. и она
позволяет учитывать риски разработанного программного продукта с выпуском
каждой из его версий.
Схема спиральной модели приведена на рисунке 6.
20
Рисунок 6 – Схема спиральной модели жизненного цикла
разработки программного обеспечения
Как видно из рисунка 6, каждый цикл в спиральной модели разделён на 4
сектора, каждый из которых учувствует в постановке задач, определении целей,
альтернатив и ограничений, разработке и проверке продукта.
1.3 Проектирование и основные технологии разработки АИС
Проектирование автоматизированных информационных систем
предусматривает построение информационной системы с выполнением требований
к ее функциональности и качеству обработки. К основным задачам проектирования
автоматизированных информационных систем относится [18, c.59]:
- обеспечение соответствия процесса разработки информационной системы
целям и задачам предприятия и предъявляемым требованиям к автоматизации
бизнес-процессов;
- создание гарантий успешного выполнения разработки информационной
системы в условиях оговоренного бюджета финансирования;
- сопровождение и возможность расширения функций автоматизированной
информационной системы в условиях работы предприятия;
21
- разработка информационной системы в соответствии с требованиями к
масштабируемости, открытости и переносимости;
- возможность использования разработки во всех бизнес-процессах
предприятия.
Целевые установки проектов по разработке информационных систем
сводятся к выполнению условий, позволяющих получать и обрабатывать
информацию с необходимым уровнем пропускной способности, безопасности и
простоты эксплуатации [3, c.21].
Проектирование автоматизированной информационной системы включает
выполнение канонического и типового проектирования.
Каноническое проектирование отражает особенности технологий разработки
автоматизированной информационной системы, а типовое проектирование
направлено на тиражирование созданного программного продукта и обеспечение
возможности его многократного использования.
Каноническое проектирование предусматривает выбор технологий
проектирования, подбор исполнителей и инструментария.
Как правило, оно применяется для разработки небольших
автоматизированных информационных систем с минимальным набором
требований.
Для организации канонического проектирования в большей степени
используется каскадная модель с выделением предпроектной стадии, проектной
стадии и послепроектной стадии.
Краткая характеристика основных стадий канонического проектирования
приведена в таблице 2.
22
Таблица 2
Краткая характеристика основных стадий канонического
проектирования
Стадия
Описание
Формирование
требований к
разработке АИС
Формирование требований к информационной системе,
обследование объекта и обоснование необходимости
разработки информационной системы и оформляется
отчет по выполненным проектам
Разработка концепции
информационной
системы
Исследование объекта автоматизации, проведение
исследовательских работ и создание нескольких
вариантов концепции
Подготовка
документов для
разработки проекта
Разработка технического задания на создание
программного продукта, подготавливается эскизная и
техническая документация
Разработка и сдача в
эксплуатацию
Выполняется разработка информационной системы и ее
адаптация к требованиям, отраженным в техническом и
эскизном проектах
Сопровождение
разработки
Объекты сопровождаются необходимой документацией
Предпроектное обследование объекта предусматривает изучение материалов
и составление технического задания на разработку программного продукта. На
этапе обследования определяется стратегия внедрения информационной системы,
производится оценка деятельности организации.
Основной задачей этапа обследования является определение требований
заказчика к получению полнофункционального программного продукта. Эти
требования отражаются в технико-экономическом обосновании проекта, влияют на
график выполнения работ [13, c.24].
Техническое задание является документом, в котором отражены требования,
цели, исходные данные к разработке программного продукта. При разработке
технического задания решаются следующие задачи:
- установить общую цель разработки АИС, определить состав подсистем и
функциональных задач;
- разработать и обосновать требования, предъявляемые к подсистемам;
- разработать и обосновать требования, предъявляемые к информационной
системе, программному и математическому обеспечению;
23
- установить общие требования к проектируемой информационной системы
и определить перечень исполнителей;
- провести предварительный расчёт затрат на создание системы и определить
уровень экономической эффективности внедрения.
Технический проект включает в свой состав техническую документацию,
отражающую общесистемные проектные решения, алгоритмы решения задач, а
также результаты экономической оценки эффективности автоматизированной
системы. На этом этапе проводится научно-исследовательские и
экспериментальные работы по выбору проектных решений. На стадии рабочего
проектирования выполняется создание программного продукта и подготовка
комплекта сопровождающей документации [19, c.60].
В состав сопровождающей документации входит вся информация по
обеспечению выполнения работ и ввода информационной системы в
эксплуатацию.
Для информационной системы проводят предварительные, опытно-
эксплуатационные и приемочные испытания.
На стадии предварительных испытаний определяют работоспособность
системы и решают вопросы по приемке в опытную эксплуатацию. Опытная
эксплуатация предусматривает определение фактических качественных и
количественных показателей по ее функционированию, корректировку в случае
необходимости документации. На стадии приемочных испытаний определяют
соответствие разработанного программного продукта техническому заданию.
Типовое проектирование отличается от канонического проектирования тем,
что в его основе находится декомпозиция проектируемой информационной
системы, выделение в ней программных модулей, подсистем, комплексов задач.
Для разработки компонентов применяют типовые решения, позволяющие
увеличить функциональность программного продукта. Типовое проектирование
предусматривает обязательное наличие документации, позволяющей описать
процедуру разработки и настройки системы.
На первом этапе определяется область, в отношении которой производится
разработка. На втором этапе выбираются средства для реализации пилотного