48
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла - это базовое понятие в методологии
проектирования информационных систем. У информационной системы жизненный
цикл представляет собой непрерывный процесс, начинающийся с момента принятия
решения о создании информационной системы и заканчивается в момент полного
изъятия ее из эксплуатации.
Охват жизненным циклом информационной системы происходит на всех ее
стадиях и этапах создания, сопровождения и развития:
исследуются предметные области с дальнейшим формированием
функциональной и информационной моделей объекта, для которого
предназначается информационная система;
Удовлетворение всех требований ТЗ происходит при проектировании
системы, которое заключается в разработке проектных решений;
Разработка системы (в том числе на основании проектных
спецификаций подсистем, выделенных на стадии проектирования
программирования и тестирования прикладных программ);
тестирование и выявление сбоев информационной системы с
последующим их устранением;
эксплуатация системы и ее сопровождение;
развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Так же существует целый ряд стандартов, которые
регламентируютжизненный цикл ПО, а в некоторых случаях и процессы разработки.
Также можно выделить из наиболее известных стандартов следующие:
ГОСТ 34.601-90 - распространяется на автоматизированные системы,
используемые в различных видах деятельности и устанавливает стадии и этапы
создания автоматизированные системы. Помимо этого, у стандартаимеются
описания содержания работ на каждом из этапов. Этапы и cстадии работы, которые
49
закреплены в стандарте, и соответствуют в большей степени каскадной модели
жизненного цикла.
ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного
цикла. У заказного ПО происходит распространение на все его виды. Также он не
содержит описаний стадий, фаз, и этапов.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает
четыре фазы: анализ, проектирование, разработка, стабилизация, является
итерационной, предполагает использование объектно-ориентированного
моделирования. MSF в сравнении с RUP в большей степени ориентирована на
разработку бизнес-приложений.
Rational Unified Process (RUP) использует итеративную модель
разработки, которая включает четыре фазы: начало, далее исследование, затем
построение и в конце внедрение. Каждая из фаз может разбиться на этапы
(итерации), у которых в результатепроисходит выпуска версии для внутреннего или
же для внешнего использования. После прохождение каждой из четырех основных
фаз будетназываться циклом разработки, к каждому такому циклу завершение
происходит генерацией версии системы. Если работа над проектом после этого не
остановлена, то получившийся продукт продолжает развитие и снова проходит те
же фазы. Сутью работ в рамках RUP будет создание и последующее сопровождение
моделей на базе UML.
Extreme Programming (XP). Экстремальное программирование было
сформировано относительно не давно в 1996 году. В основу данной
методологиивходит командная работа, эффективная коммуникация в течение всего
проекта по разработке ИС между исполнителем и заказчиком, а сама разработка
проходит с использованием последовательно дорабатываемых прототипов.
Стандарт ISO/IEC серии 12207
В этом стандарте нет предложения конкретных методов разработкии
моделейЖЦ и, а рекомендации данного стандартасчитаются общими для любых
моделей жизненного цикла. Под термином модель обычно считается структура,
которая определяет у процессов, последовательность выполнения и взаимосвязи,
действий и задач на протяжении всего жизненного цикла.
Существуют следующие основные стратегии внедрения системы:
50
1. Параллельная стратегия - когда одновременно работают старая (ручная) и
новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
2. "Скачок". Эта стратегия привлекательна, но не рекомендуется.
3. "Пилотный проект". Это наиболее часто используемая стратегия.
"Пилотный проекта" - это тактика "скачка", но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически
все предприятия применяют эту тактику сегодня.
4. "Узкое место". "Узкое место" - это малая часть производственного процесса.
При использовании похода "узкое место" план внедрения выполняется только
для "узкого места" и для людей, работающих в нем. Точность данных
повышается только для изделий в этом "узком месте"; переподготовка- только
для людей, работающих в нем; анализ эффект-затрат делается только для него
и т.д.
На сегодняшний день существуют две основные модели жизненного цикла -
спиральная и каскадная модели. Развитие спиральной модели продолжается.
Пошаговый процесс разработки, шаг за шагом для каскадной модели. Только после
завершения предыдущего будет переход на следующий этап. Вначале на начальном
этапе разрабатывается система с высоким уровнем абстракции, и позднее это
развитие становится более конкретным на последующих витках.
На жизненном цикле текущего проекта была выбрана каскадная модель
развития, поскольку поэтапное развитие более подходит для текущей системы. И на
следующем этапе переход происходит только в том случае, если все работы были
завершены на предыдущем этапе (рисунок 2.2), включая также подготовленный
комплектный пакет документации, объем которого будет достаточным для
дальнейшего развития дальнейших групп разработчиков, а также если есть
возможность запланировать завершение работы и затраты на их выполнение.
51
Рисунок 0.2Каскадная схема разработки ПО.
Каскадный метод хорош при построении системы, у которой при разработке
в самом начале точно и полно можно сформулировать все требования, чтобы уже
разработчики свободно смогли их реализовать как можно лучше с технической
точки зрения. Однако, если ошибки обнаруживаются в середине разработки, а не в
начале, то вам придется прибегнуть к аберрации проекта, и фактическая схема
каскадной модели приобретает другую форму (рис. 2.3).
Исходя из выше описанного, был выбран стандарт ISO/IEC серии 12207, а
выбор стратегии пал на стратегию “Узкое место” и каскадный метод, которые
наиболее всего подходят для задачи.
52
Рисунок 0.3Реальный процесс разработки ПО в каскадной схеме.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Любой проект, связанный с созданием корпоративных информационных
систем, будет включать в себя большое количество задач, которые связаны с
разработкой программного обеспечения, общим управлением проектом,
проектированием ИС, реализацией, каждый из которых является проектом с
присущими ему функциями. Исходя из этого, в процессе разработки существуют
различные риски.
Также риски заказчика могут быть связаны с неполным достижением целей
проекта, а также с не эффективным расходованием средств. А риски исполнителя -
с возможным резким превышением фактической стоимости работы по сравнению с
запланированным. Необходимость параллельного, а иногда и принципиально иного
характера работы приводит к тому, что уровень проектного риска увеличивается
многократно.
Наиболее характерные риски и методы их минимизации приведены в таблице
1.4
Таблица 1.4
Возможные риски проекта и способы их минимизации
Виды рисков/варианты
менеджмента рисков
Снижение видов риска
Снижение вероятности возникновения
риска
Риски, связанные с масштабностью
проекта
Детальный анализ каждого этапа работ,
взаимодействия участников,
организации работ
Детально проработанная программа
качества, отработанное управление
конфигурацией проекта, специальные
процедуры взаимодействия участников
Риски, связанные с недостаточным
опытом в сфере ИТ
Проведение обучения пользователей,
включая руководство, соблюдение
технологий работы
Разработка и утверждение концепции
проекта на возможно более ранней его
стадии
Технические риски проекта
Строгий отбор проектной команды по
квалификационным критериям.
Обучение участников проекта
технологии проектных работ,
инструментальным средствам
Использование стандартов предприятия
на проектные работы, разработка
стандартов проекта
Организационные риски проекта
Обучение участников проекта (курс
"управление проектом"), тренинги
команды, как можно более полная
формализация деятельности
Включение в команду администратора
проекта, детальное распределение ролей в
проекте
Операционные риски проекта
Многократное тестирование созданных
продуктов, тщательная экспертиза
документов
Строгое выполнение процедур программы
качества
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель - это блок-схема входных, промежуточных и
результирующих потоков и функций потоков. Кроме того, она объясняет, на основании
каких входных документов и какой нормативно-справочной информации выполняются
функции обработки данных и формирования конкретных выходных документов.
Информационная модель представлена на рис. 2.4.
ИС Администратор
Выбор
служб
СПР
Службы
Оповещение в
случае сбоя
Администратор
СПР
Выбранные службы
Настройка
СПР
Выбранные службы*
состояние
служб
Логи о работе
программы
Рисунок 0.4 Информационная модель системы
В соответствии с представленной информационной моделью администратор
заполняет справочник “Выбранные службы”. Далее, ИС на основании заполненного
справочника “Выбранные службы” проводит мониторинг состояния служб и далее
выводит информацию в форму и случае сбоя производит оповещение администратора.
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
В разработанном модуле предусмотрен только один пользователь –
администратор. Дерево функций модуля представлено на рисунке 2.5.
Рисунок 0.5 Дерево функций менеджера
На основании дерева функций разработан сценарий диалога, схематически
представленный на рисунке 2.6.
Рисунок 0.6 Сценарий диалога
2.3.2 Характеристика базы данных
В разрабатываемом программном продукте нет необходимости использовать
базы данных так как все необходимые параметры берутся из операционной системы
либо хранятся в ini файле самой программы.
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
Система состоит из одного модуля – это приложение для взаимодействия с
установленными службами в операционной системе, реализованного на языке
программирования Delphi.
Работа с программой осуществляется через любую операционную систему. Для
работы достаточно просто запустить программу на сервере предприятия и затем
произвести необходимые настройки для начала работы. Структурная схема
приложения представлена на рисунке. 2.7.
Рис. 0.1 Структурная схема пакета приложения
Рисунок 0.8 Структурная схема пакета
2.3.4 Описание программных модулей
На рисунке 2.9 представлена схема добавления служб и их последующая
проверка на состояние работы.
Ввод необходимых настроек
Выбор из списка, необходимых
служб
Проверка.
Службы работают?
Да
Нет
Вывод сообщения на экран
Отправка сообщения по почте
Начало
Конец
Рисунок 0.9 Схема добавления служб и их последующая проверка