25
Docsvision 5.5 принципиально отличается от предыдущих версий тем,
что спроектирована как современная ECM-система. Теперь возможно
хранение всего цифрового контента организации, управление документами и
процессами на единой платформе:
Нет ограничений по нагрузке, заложена возможность роста;
Быстрая работа с документами, быстрый поиск и доступ к данным;
Удобство установки, обновления и обслуживания;
Простая интеграция.
Redmine - открытое серверное веб-приложение для управления
проектами и отслеживания ошибок, написано на Ruby и представляет собой
приложение на основе веб-фреймворка Ruby on Rails. Интерфейс достаточно
интуитивен, легко осваивается обычными пользователями.
Список возможностей системы:
- ведение нескольких проектов;
- система отслеживания ошибок;
- оповещение об изменениях посредством электронной почты и RSS-
каналов;
- настраиваемые статусы задач;
- настраиваемые произвольные поля для задач, временных затрат,
проектов и пользователей;
- учет временных затрат (часов);
- диаграммы Ганта и календарь;
- Wiki для каждого проекта;
- ведение новостей проекта, управление файлами и документами;
- форумы для каждого проекта;
- многоязыковой интерфейс, в том числе русский;
- легкая интеграция с репозиториями (SVN, CVS, Git, Mercurial, Bazaar
и Darcs);
- система разделения доступа, основанная на ролях;
- поддержка множественной аутентификации LDAP;
26
- возможность самостоятельной регистрации новых пользователей;
- расширение функциональности системы посредством установки
дополнительных плагинов;
- поддержка СУБД: MySQL, PostgreSQL, SQLite, MS SQL Server (с
версии 2.3)
1.3.2. Выбор и обоснование стратегии автоматизации задачи
В реализации проекта по созданию систем данного типа можно
выделить несколько этапов:
Предпроектный анализ требований заказчика– оценка
поставленных задач, оценка сложности разработки проекта;
Создание и согласование списка задач, регламента работ и
технического задания – анализ и создание списка задач, которые должна
отрабатывать система. Согласование технического задания и списка
требований с заказчиком;
Разработка программного продукта - непосредственная разработка
и создание программы для ведения электронного документооборота;
Проверка работоспособности системы и тестирование аварийных
ситуаций – проведение полного комплекса тестов, продукт должен
соответствовать стандартам безопасности и требованиям заказчика.
Этап внедрения. Установка системы. Отладка системы.
Данная стратегия автоматизации является полной, так как создание
каждой конкретной системы представляет собой основной бизнес-процесс
компании и влияет на работу остальных бизнес-процессов.
1.3.3. Выбор и обоснование способа приобретения ИС для
автоматизации задачи
На сегодняшний день существует несколько вариантов приобретения
информационных системы. Можно приобрести либо арендовать уже готовое
решение. Ее также можно заказать сторонним специалистам для
изготовления под ваши нужды, сконфигурировать готовую систему, или же
построить своими силами с нуля.
27
Рассмотрим каждый из вариантов в отдельности:
Приобретение или аренда ранее написанного программного
решения, подразумевает наличие комплексных решений, когда-либо
воплощенных, либо для других проектов, либо универсальные системы,
способные исполнять большой спектр различных функций. Во-первых, есть
очень большой риск того, что проект, для которого программное обеспечение
уже было написано ранее, отличается от того, который необходимо
автоматизировать в данный момент. Во-вторых, системы часто перегружены
лишним функционалом, за который приходится платить лишние деньги,
испытывать из-за него торможения системы в работе, при этом не используя
его.
Заказ разработки программного продукта у третьих лиц решает
поставленную задачу, но крайне неудобен при динамической разработке
программного обеспечения в условиях развивающегося предприятия. В этом
случае, предприятие либо зависит от компании, которой было разработано
программное обеспечение, либо возникает возможность не получить
своевременной поддержки через некоторое время, что может крайне
отрицательно сказаться как на работоспособности предприятия в целом, так
и на качестве продукции в частности, что может привести к крайне
неприятным убыткам.
Создание программного продукта с нуля. Этот вариант наиболее
гибок и удобен, особенно при разработке узкоспециализированного
программного обеспечения. Он позволяет ещё на стадии проектирования
полностью отразить и учесть все необходимые нюансы эксплуатации, а также
позволяет подготовить всю необходимую для дальнейшей работы
техническую документацию. Так же в данном варианте существенно
упрощается последующая поддержка продукта, так как поддержанием
программного решения будут заниматься люди, которые непосредственно
участвовали в его разработке и создании, что значительно упростит их
работу. Этот вариант приобретения информационной системы имеет один
28
существенный недостаток. Для создания комплексного программного
решения полностью своими силами, предприятию необходимо иметь в
составе сотрудников штат полностью подготовленных и обученных
программистов, с опытом работы в данной области.
Создание программного продукта на основе имеющейся базы. Это
вариант также наиболее гибок и удобен, а также бесплатный. Дописав
необходимые условия, полностью отражаются необходимые условия
эксплуатации. Для создания данного программного обеспечения,
предприятию необходимо иметь программистов, разбирающихся в данной
сфере.
Так как поставленная перед нами задача имеет уникальность, так как
каждый отдел предприятия уникальный в части касающейся своей работы,
для апробации данной автоматизации системы документооборота был
выбрано подразделение АО «ГПТП «Гранит» СКБ «Меридиан». Также
необходимо учитывать, что СКБ «Меридиан» АО «ГПТП «Гранит» имеет в
своем составе подготовленных, обученных инженеров-программистов и
инженеров-конструкторов. В связи с этим был выбран вариант создания
программного продукта на основе имеющейся базы.
29
Глава 2. Разработка проекта автоматизации ведения конструкторской
документации
2.1. Этапы жизненного цикла проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационных систем – это период их создания и
использования, охватывающий различные состояния, начиная с момента
возникновения необходимости в такой системе и заканчивая моментом ее
полного выхода из употребления у пользователей.
Жизненный цикл информационных систем включает в себя четыре
стадии: предпроектную, проектировочную, внедрение, функционирование.
От качества проектировочных работ зависит эффективность
функционирования системы, поэтому каждая стадия разделяется на ряд
этапов и предусматривает составление документации, отражающей
результаты работ.
В данный момент известны такие модели жизненного цикла
информационных систем как:
Каскадная стратегия (однократный проход, водопадная или
классическая модель) подразумевает линейную последовательность
выполнения стадий создания информационной системы. Другими словами,
переход с одной стадии на следующую происходит только после того, как
будет полностью завершена работа на текущей.
30
Рисунок 5. Каскадная модель жизненного цикла
Данная модель применяется при разработке информационных систем,
для которых в самом начале разработки можно достаточно точно и полно
сформулировать все требования.
31
Достоинства модели:
На каждой стадии формируется законченный набор документации,
программного и аппаратного обеспечения, отвечающий критериям полноты
и согласованности;
Выполняемые в четкой последовательности стадии позволяют
уверенно планировать сроки выполнения работ и соответствующие ресурсы
(денежные, материальные и людские).
Недостатки модели:
Реальный процесс разработки информационной системы редко
полностью укладывается в такую жесткую схему. Особенно это относится к
разработке нетиповых систем;
Основана на точной формулировке исходных требований к
информационной системе. Реально в начале проекта требования заказчика
определены лишь частично;
Основной недостаток – результаты разработки доступны заказчику
только в конце проекта. В случае неточного изложения требований или их
изменения в течение некоторого периода создания ИС заказчик получает
систему, не полностью удовлетворяющую его потребностям.
Инкрементная стратегия подразумевает разработку информационной
системы с линейной последовательностью стадий, но в несколько версий, т.
е. с запланированным улучшением продукта.
32
Рисунок 6. Инкрементная модель жизненного цикла
В начале работы над проектом определяются все основные требования
к системе, после чего выполняется ее разработка в виде последовательности
версий. При этом каждая версия является законченным и работоспособным
продуктом. Первая версия реализует часть запланированных возможностей,
следующая версия реализует дополнительные возможности и т. д., пока не
будет получена полная система.
Данная модель жизненного цикла характерна при разработке сложных
и комплексных систем, для которых имеется четкое видение (как со стороны
заказчика, так и со стороны разработчика) того, что собой должен
представлять конечный результат (информационная система). Разработка
версиями ведется в силу разного рода причин:
Отсутствия у заказчика возможности сразу профинансировать весь
дорогостоящий проект;
33
Отсутствия у разработчика необходимых ресурсов для реализации
сложного проекта в сжатые сроки;
Требований поэтапного внедрения и освоения продукта конечными
пользователями. Внедрение всей системы сразу может вызвать у ее
пользователей неприятие и только «затормозить» процесс перехода на новые
технологии.
Достоинства и недостатки этой стратегии такие же, как и у
классической. Но в отличие от классической стратегии заказчик может
раньше увидеть результаты. Уже по результатам разработки и внедрения
первой версии он может незначительно изменить требования к разработке,
отказаться от нее или предложить разработку более совершенного продукта
с заключением нового договора.
Спиральная стратегия (Рисунок 7) подразумевает разработку в виде
последовательности версий, но в начале проекта определены не все
требования. Требования уточняются в результате разработки версий.
34
Рисунок 7. Спиральная модель жизненного цикла
Данная модель жизненного цикла характерна при разработке
новаторских (нетиповых) систем. В начале работы над проектом у заказчика
и разработчика нет четкого видения итогового продукта (требования не могут
быть четко определены) или стопроцентной уверенности в успешной
реализации проекта (риски очень велики). В связи с этим принимается
решение разработки системы по частям с возможностью изменения
требований или отказа от ее дальнейшего развития. Как видно из рисунка 7,
развитие проекта может быть завершено не только после стадии внедрения,
но и после стадии анализа риска.
Достоинства модели:
Позволяет быстрее показать пользователям системы
работоспособный продукт, тем самым, активизируя процесс уточнения и