36
II ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации документооборота ООО
«Руф монтаж сервис»
2.1.1 Этапы жизненного цикла проекта автоматизации
документооборота ООО «Руф монтаж сервис»
Под понятием «программное обеспечение» (далее ПО)
подразумевается совокупность программ обработки данных и необходимых
для их эксплуатации документов.
Проектированием программного обеспечения является процесс
создания проекта ПО. Проектирование ПО - этап жизненного цикла (далее
ЖЦ) ПО, во время прохождения которого изучается структура и
взаимосвязанность элементов разрабатываемой системы.
ЖЦ ПО – это определенный период времени, начинающийся с момента
принятия решения о создании программного продукта (далее ПП) и
заканчивается в момент полного закрытия его эксплуатации.
В соответствии со стандартом СТБ ИСО / МЭК 12207–2003 жизненный
цикл программного обеспечения или системы означает совокупность
процессов, действий и задач, включая разработку, эксплуатацию и
обслуживание программного обеспечения или системы и покрытие их жизни
от формулировки концепции до прекращения использования. Жизненный
цикл ПС состоит из процессов. Каждый процесс жизненного цикла делится
на набор работ. Каждая работа разделена на набор задач.
В настоящее время проектирование ПО является одним из главных
направлений при формировании ИС. При создании ИС такие ступени, как:
подготовка, обоснование, согласование замыслов и решений заказчика
совместно с разработчиком о концепции создания или модернизации
существующего ПО являются основными составляющими затрат времени и
труда.
37
В учебном пособии Орлова С. А. «Технологии разработки
программного обеспечения»
были выделены следующие этапы жизненного
цикла ИС:
планирование и анализ – определяет, что должна выполнять ИС;
проектирование – определяет как будет функционировать система;
разработка - создание модулей приложения;
тестирование - проверка функционального и параметрического
соответствия системы показателям, определенным на этапе анализа;
внедрение - установка и ввод в эксплуатацию информационной
системы;
техническое обслуживание - обеспечение нормального процесса
работы системы на предприятии заказчика.
В вышеуказанном учебном пособии сказано, что состав требований и
выбранная модель процесса, опыта проектировщика влияют на зависимость
хода процесса проектирования и его результаты.
Наиболее распространенными моделями ЖЦ являются:
каскадная модель;
поэтапная итерационная модель;
спиральная модель.
Для разработки информационной системы по теме исследования
подходит поэтапная итерационная модель (рис. 2.1).
Итеративная модель жизненного цикла ПО используется, если
необходимо исправить ошибки и упущения, сделанные на более ранних
этапах ЖЦ, необходимо повторить выполнение всех или некоторых работ
этих этапов.
38
Рисунок 2.1 – Графическое представление итеративной модели
жизненного цикла разработки ПО
Преимущества итеративной модели:
Модель хорошо известна конечным пользователям.
Она решает трудности упорядоченным образом и хорошо работает
для проектов, которые достаточно ясны.
Она проста и удобна в использовании, поскольку процесс разработки
осуществляется поэтапно.
Характеризуется требованиями стабильности.
Хорошо работает, когда требования к качеству преобладают над
требованиями к стоимости и срокам проекта.
Способствует строгому контролю над управлением проектами.
Проектирование сложных ИС с помощью CASE-технологий
ориентировано на разработку и поддержку полного жизненного цикла ИС.
Такие технологии используются для производства программного продукта,
для решения исследовательских и проектных задач.
В учебном пособии «Разработка и эксплуатация автоматизированных
информационных систем»
в качестве основных достоинств CASE-технологий
выделяют:
39
высокое качество создаваемого ПО с помощью средств
автоматической генерации и контроля;
ускоренный процесс проектирования и разработки;
возможность за короткие сроки создать прототип будущей системы;
поддержку многократного использования компонентов;
поддержку развития и сопровождения ПО.
Благодаря развитию CASE-технологий в последнее время широкое
распространение получила методология быстрой разработки приложений –
Rapid Application Development (далее RAD).
RAD - это набор специальных инструментальных средств для быстрой
разработки автоматизированных информационных систем, которые
позволяют работать с определенным набором графических объектов, что
функционально отображаются отдельными информационными
компонентами приложений.
Методология быстрой разработки приложений это процесс разработки
информационных систем, основанный на трех элементах:
небольшая команда программистов (обычно от 2 до 10 человек);
тщательно разработанный график работы за относительно короткий
период разработки (от 2 до 6 месяцев);
модель итеративной разработки, основанная на тесном
взаимодействии с заказчиком - по мере развития проекта разработчики
уточняют и внедряют требования, выдвигаемые заказчиком в продукте.
40
Рисунок 2.2 – Методология быстрой разработки приложений -
RAD
Следующие принципы RAD были изложены для решения этой и
других проблем Джеймсом Мартином и его последователями:
минимизация временных затрат - инструментарий должен быть
направлен на сокращение времени разработки;
прототипирование - создание прототипов для уточнения требований
заказчика;
цикл разработки - каждая новая версия продукта основана на оценке
результата предыдущей версии работы заказчиком;
сотрудничество - команда разработчиков должна тесно сотрудничать
друг с другом, каждый участник должен быть готов выполнить несколько
обязанностей;
итеративный подход к разработке;
комбинированное тестирование и проектирование системы.
Принципы RAD используются не только во время реализации, но и
применяются ко всем этапам жизненного цикла, в частности, на этапе
обследования организации, формирования требований, анализа и
проектирования.
Возможность использовать этот подход во многом является
41
результатом применения принципов объектно-ориентированного
проектирования.
Логика приложения, созданного с использованием RAD,
ориентирована на события. Каждый объект, являющийся частью
приложения, может генерировать события и отвечать на события, которые
создаются другими объектами. Примеры событий: открытие и закрытие окон,
нажатие кнопки, нажатие клавиши клавиатуры, перемещение мыши,
изменение данных в базе данных и т. д.
Разработчик реализует логику приложения, определяя обработчик для
каждого события - процедуру, которую объект выполняет, когда происходит
соответствующее событие. Например, обработчик события нажатия кнопки
может открыть диалоговое окно. Таким образом, управление объектами
осуществляется с помощью событий.
Таким образом, выбранный подход полностью соответствует целям и
задачам автоматизации документооборота ООО «Руф монтаж сервис».
2.1.2 Характеристика нормативно-справочной, входной и
оперативной информации
Информационная поддержка является важной частью автоматизации
документооборота.
Согласно ГОСТ 34.003-90 «Информационные технологии. Набор
стандартов для автоматизированных систем. Термины и определения»:
«Нормативной и справочной информацией автоматизированной системы
является информация, заимствованная из нормативных документов и
справочников и используемая при работе АС».
Документация для автоматизированной системы представляет собой
набор взаимосвязанных документов, которые полностью определяют
технические требования к АС, проектные и организационные решения для
создания и эксплуатации автоматизированной системы документооборота.
Методологическое и правовое сопровождение (МПС) - набор
методологических принципов и правовых норм для функционирования АС.
42
Это довольно важный тип поддержки АС, который определяет
легитимность действий делопроизводителей, выполняющих их функции.
МПО включает в себя набор законов, правительственные решения о развитии
делопроизводства и смежных областях (информационные технологии,
Интернет, электронные ресурсы, права доступа к информации и т. д.). Это
такие документы как:
Федеральный закон № 53-ФЗ от 01.06.2005 «О государственном
языке Российской Федерации»
Федеральный закон № 149-ФЗ от 27.07.2006 «Об информации,
информационных технологиях и о защите информации»
Федеральный закон № 63-ФЗ от 06.04.2011 «Об электронной
подписи»
ГОСТ Р 6.30–2003. Унифицированные системы документации.
Унифицированная система организационно-распорядительной
документации. Требования к оформлению документов
Рассмотрев характеристику предметной области, определяем, что
входной информацией для данной работы являются справочники, входящие
и исходящие документы, данные о которых содержатся в таблицах базы
данных: Справочник корреспондентов, Справочник подразделений,
Справочник должностей, Справочник видов документов, Справочник видов
доставки, Справочник сотрудников.
2.1.3 Характеристика результатной информации
Результатная информация формируется в виде базы документов:
Исходящие документы и Входящие документы, а также запросов к базе
данных: Входящие документы на контроле, Исполнено в срок,
Зарегистрировано входящих, Зарегистрировано исходящих, Просроченные
задания, Сводка об исполнении документов.
На основе сформированных запросов программа должна выводить
соответствующие отчеты:
Входящие документы на контроле.
43
Исполнено в срок.
Зарегистрировано входящих.
Зарегистрировано исходящих.
Просроченные задания.
Сводка об исполнении документов.
2.2 Программное обеспечение задачи
2.2.1 Общие положения
Описание объекта на языке функций представлено на рис.2.3.
Рисунок 2.3 – Дерево функций
На основании дерева функций разработан сценарий диалога,
схематически представленный на рисунке 2.4.
44
Рисунок 2.4 – Сценарий диалога
2.2.2 Характеристика базы данных
Диаграммы «сущность-связь» используются для проектирования
реляционных баз данных. С ее помощью определяются важные для
предметной области объекты, их свойства и отношения друг с другом
(связи).
При разработке схемы объект-отношение получили такие объекты:
ВидДокумента, ВидДоставки, Входящие документы, Исходящие документы,
Корреспонденты, Сотрудники, Справочник_должностей и
Справочник_подразделений .
Далее была создана модель предметной области на логическом уровне
представления данных, которая содержит все сущности и показывает связи
между ними (рисунок 2.5).
45
Рисунок 2.5 – Диаграмма ER-уровня модели данных
«deloproizvodstvo»
Каждая сущность имеет свои атрибуты. Сущности с атрибутами
представлены на рисунке 2.6.
Рисунок 2.6 – Логический уровень модели данных
«deloproizvodstvo»
Для атрибутов сущности были добавлены типы данных и получили
прототип физической модели данных (рис.2.7).
Входящие документы
Исходящие документы
Сотрудники
Справочник видов документов
Справочник видов доставки
Справочник должностей
Справочник корреспондентов
Справочник подразделений
Входящие документы
Рег_ном
Рег_дата
Исх_ном
Исх_дата
Код_вид_док (FK)
Код_кор (FK)
Сод
Код_вид_дос (FK)
Файл
Рез
Таб_ном (FK)
Срок_исп
Дата_исп
Исп
Контроль
Исходящие документы
Рег_ном
Рег_дата
Таб_ном (FK)
Код_вид_док (FK)
Сод
Код_вид_дос (FK)
Код_кор (FK)
Файл
Сотрудники
Таб_ном
ФИО
Код_подр (FK)
Код_долж (FK)
Справочник видов документов
Код_вид_док
Вид_док
Справочник видов доставки
Код_вид_дос
Вид_дос
Справочник должностей
Код_долж
Наим_долж
Справочник корреспондентов
Код_кор
Наим_кор
Адрес
Тел
Справочник подразделений
Код_подр
Наим_подр