38
1.4.Обоснование проектных решений
1.4.1.Обоснование проектных решений по информационному обеспечению
Рассмотрим следующую экономическую задачу: обработка заявок на
ремонт техники, которая осуществляется диспетчерской и ремонтной службой.
Приведем диаграммы функционального моделирования IDEF0 и
диаграммы потоков данных DFD, отражающие ситуацию, которая должна быть
на момент внедрения информационной системы (TO-BE).
Для создания диаграмм IDEF0 и DFD будем использовать
специализированное CASE-средство BPWin 4.0.
Рис. 1.10. Контекстная диаграмма
39
Рис. 1.11. Диаграмма декомпозиции А0
Рис. 1.12. Диаграмма декомпозиции А1
40
Рис. 1.13. Диаграмма декомпозиции А2
На вход системы поступает следующая информация: Справочная
информация, Сведения о ремонтниках, Сведения о клиентах, Заявка на ремонт.
На выходе получаем: Реестр заявок, График ремонтов, Отчеты. Механизмы и
управление остались такими же как и в модели AS-IS.
При построении модели TO-BE появились новые активности:
Ведение справочников, Учет клиентов, Учет и обработка заявок,
Формирование отчетов (Обработка заявки диспетчерской службой);
Учет ремонтников, Обработка заявок, Работа с отчетами (Обработка
заявки ремонтной службой).
Соответствующие активности модели AS-IS полностью заменены новыми
активностями модели TO-BE.
Планируемые улучшения, достигаемые путем реорганизации модели
бизнес-процессов от AS-IS к TO-BE за счет использования информационных
технологий, должны позволить вести единый, оперативный и актуальный учет и
обработку заявок в компании.
41
Рис. 1.14. Диаграмма потоков данных А0
Рис. 1.15. Диаграмма потоков данных А1
42
Рис. 1.16. Диаграмма потоков данных А2
Изменение модели IDEF0 повлияло и на движение потоков данных,
отражаемых в модели DFD. Для централизованного хранения данных
предполагается использование соответствующих хранилищ данных:
Справочники, Заявки, Клиенты, Ремонтники. Хранилище данных
«Справочники», отражаемое на диаграммах потоков данных, объединяет в себе
несколько справочных таблиц будущей базы данных.
1.4.2.Обоснование проектных решений по программному обеспечению
ПО системы включает совокупность программ (общего и специального
назначения), описаний и инструкций по применению данных программ на ПК
пользователей.
В состав общего ПО для рассматриваемой задачи входят ОС и СУБД.
Специальное ПО включает совокупность прикладных программ, которые
разработаны для решения конкретных задач.
В качестве ОС для ПК выбрана система Windows XP и выше.
43
СУБД представляет собой комплекс языковых и программных средств,
который предназначен для создания, ведения и совместного использования БД
многими пользователями. СУДБ является вторым по важности, после ОС,
программным средством, которое необходимо выбрать для успешной
реализации автоматизируемой задачи.
Для реализации ИС выбрана СУБД Microsoft Access. В качестве
специального ПО используется ИС «Обработка заявок».
1.4.3.Обоснование проектных решений по техническому обеспечению
Техническое обеспечение автоматизируемой задачи включает в себя
только клиентскую часть.
Для сбора, регистрации, хранения и обработки данных, на рабочих местах
пользователей привлекаются ПК.
В настоящее время на рабочих местах сотрудников уже установлены ПК.
Для печати отчетов и выходных документов используются принтеры, которые
совместимы с имеющимися ПК.
Реализация данной выпускной квалификационной работы
предусматривает максимальное применение используемых в организации
технических средств (ТС), а также адаптацию проектных решений к
используемому техническому обеспечению (ТО). Данное решение определяется
соображениями экономической целесообразности: ограничениями, которые
накладываются имеющимся финансированием на обновление ВТ в организации,
техническим состоянием данной техники, уровнем подготовки пользователей и
др.
44
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла (ЖЦ) – это структура, которая содержит
процессы, действия и задачи, осуществляемые в ходе разработки,
функционирования и сопровождения ПО в течение всей его жизни (от
определения требований к системе до завершения ее использования).
Общая схема ЖЦ, а также схема ЖЦ программного продукта приведены
на рис. 2.1-2.2..
Рис. 2.1. Общая схема ЖЦ
Рис. 2.2. Схема ЖЦ программного продукта
45
К настоящему времени наибольшее распространение получили
следующие основные модели ЖЦ: задачная, каскадная и спиральная модели.
При задачной модели разработка системы ведется «снизу-вверх» от
отдельных задач ко всей системе (задачная модель), что приводит к тому, что
единый поход к разработке теряется, в результате возникают проблемы при
информационном соединении отдельных компонент. Как правило, по мере
увеличения количества задач нарастают и трудности. В результате чего
приходится постоянно изменять уже существующие программы и структуры
данных. Скорость развития ИС замедляется, что соответственно тормозит
развитие самой организации.
При разработке небольших по объему и однородных ИС каждое
приложение можно рассматривать как единое целое. Для разработки
приложений данного типа применялся каскадная модель. Основной
характеристикой данной модели является разбиение всей стадии разработки на
этапы, причем переход от одного этапа к следующему этапу выполняется только
после полного завершения работы на текущем этапе (рис. 2.3). Каждый этап
завершается выпуском полного комплекта документации, который достаточен
для того, чтобы разработка могла быть продолжена другой командой
разработчиков.
Рис. 2.3. Каскадная модель ЖЦ
Преимуществами каскадной модели являются:
формирование полного набора проектной документации на каждом этапе;
46
выполняемые в логичной последовательности этапы работ позволяют
планировать сроки завершения всех работ, а также соответствующие
затраты.
Каскадная модель хорошо зарекомендовала себя при построении ИС, для
которых в самом начале разработки можно достаточно точно и полно
сформулировать все основные требования.
Недостатками каскадной модели являются:
реальный процесс создания ИС никогда полностью не укладывается в
такую жесткую схему;
постоянное возникновение потребности в возврате к предыдущим этапам
и уточнении ранее принятых решений;
существенное запаздывание с получением результатов;
большие затраты на разработку ПО.
Спиральная модель ЖЦ делает упор на начальные этапы ЖЦ, т.е. анализ и
проектирование. На данных этапах реализуемость технических решений
проверяется посредством создания прототипа. Каждый виток спирали
соответствует созданию некоторого фрагмента или версии ПО. На каждом этапе
уточняются цели и характеристики проекта, а также определяется его качество и
планируются работы следующего витка спирали.
Разработка системы итерациями отражает объективно существующий
спиральный цикл создания ИС. Неполное завершение работ на каждом этапе
разработки позволяет переходить на следующий этап, не дожидаясь полного
завершения работы на текущем этапе. При итеративном способе разработки всю
недостающую работу можно выполнить на следующей итерации. Главная
задача: как можно быстрее показать пользователям ИС работоспособный
продукт, при этом активизируя процесс уточнения и дополнения требований.
Основной проблемой спирального цикла является определение
наилучшего момента перехода на следующий этап. Переход между этапами
осуществляется в соответствии с планом, даже если не вся запланированная
работа закончена. План составляется на основе статистических данных, которые
47
получены в предыдущих проектах, и личного опыта разработчиков. На рис. 2.4.
представлено графическое изображение спиральной модели ЖЦ ИС.
Рис. 2.4. Спиральная модель ЖЦ ИС
Наиболее оптимальным для нас является выбор спиральной модели, так
как в данной модели были учтены все недостатки каскадной и задачной модели.
При этом в рамках доработки уже существующей ИС часто возникают новые
замечания от пользователей, которые можно реализовать на новом витке
спиральной модели.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Однако на каждой фазе выполнения проекта присутствуют определенные
риски. Так, например, могут возникать следующие риски:
Фаза разработки концепции: недальновидный анализ сроков проекта и
его, неправильно подобранный проектный состав исполнителей может
повлечь за собой отсутствие командной работы.
Фаза планирования: не корректно сформированная архитектура
используемого решения;
Фаза разработки: неправильная интерпретация технического задания
(ТЗ), отсутствие должной квалификации у программиста в том языке, на
котором решено реализовывать программу;