Материал: Автоматизация процесса ведения документации и отчетности в "ФГБУ ФИПС"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
34
1.4.3. Обоснование проектных решений по техническому обеспечению
Локально-вычислительная сеть ФИПС, в том числе и архивная его часть,
состоит из пользовательского и серверного сегментов. В состав серверного входит
следующее оборудование:
Коммутаторы D-Link DGS-3100-48 L2 управляемый стекируемый
44xGigaUTP, 4xSFP;
APC Smart-UPS 750VA
Сервер приложений;
Сервер-шлюз;
Контроллеры домена;
DNS-сервер;
Серверы для хранения данных.
Компьютеры, не входящие в серверный сегмент включают в себя:
Материнская плата: Gigabyte GA-M61PM-S2 Socket AM2
Процессор: AMD Athlon 64 X2 4200+ Energy Efficient
Память: 4 Гб DDR3
Жесткий диск: 500 Гб
Технические характеристики серверов и рабочих станций полностью
соответствуют задачам автоматизации.
Выводы по главе1: на основании рассмотреннго теоретического материала
по автоматизации процесса ведения документации и отчетности в ФГБУ ФИПС,
приходим к выводу, что данное предприятие нуждается в необходимости поиска
новых возможностей управления документооборотом. В связи с тем, что
предприятие выполняет большой объем работ, и соответственно могут допускаться
ошибки в процессе работы, теряться документы на одном из этапов работы,
необходимо минимизировать человеческий фактор путем автоматизации всех
этапов работы, тем самым сократив время для работы с документом.
35
2 ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл определяется как непрерывный процесс, который обычно
начинается с момента принятия решения о важности его реализации и
заканчивается сразу же после его изъятия из эксплуатации.
Среди наиболее популярных стандартов обычно выделяют:
ГОСТ 34.601-90 применим к автоматизированным системам и
устанавливает все стадии и этапы их разработки. Также в этом стандарте есть
описание содержания работ для каждого этапа. Этапы и стадии, которые
закреплены в данном стандарте, чаще всего соответствуют каскадной модели
жизненного цикла.
ISO/IEC 12207 стандарт, определяющий процессы и организацию
жизненного цикла. Применим к любому виду заказного ПО. В стандарте нет
описания стадий, фаз и этапов.
Custom Development Method (Oracle) технологический материал по
разработке прикладных ИС, который детализирован до уровня заготовок
проектных инструкций, которые будут использоваться в проектах с участием
Oracle. Используется CDM для классической модели ЖЦ (имеются все этапы и
задачи), а также при технологии быстрой разработки или облегченного прохода,
которые используются в случае малого проекта.
Rational Unified Process (RUP) использует некую интерактивную модель
разработки, которая включает 4 фазы: начало, исследование, построение и
внедрение. Любая из этих фаз может разбиваться на этапы, в результате которых
исполняется версия для внутреннего или внешнего использования. Проход по всем
4 фазам это цикл разработки, и каждый такой цикл завершается генерацией
версии системы. Если после этого проект продолжается, то сам продукт также
видоизменяется и проходит эти фазы еще раз. Суть работы в рамках RUP -
разработки и сопровождение моделей на базе UML.
Microsoft Solution Framework (MSF) поход на RUP, также имеет 4 фазы:
анализ, проектирование, разработка и стабилизация, является итерационным и
36
предполагает применение объектно-ориентированных моделей. MSF в сравнении с
RUP в большей степени предназначен для создания бизнес-приложений.
Extreme Programming (XP) экстремальное программирование (новейшая
методология, сформировалась в 96 году). Основу методологии составляют
командная работы, активная коммуникация с заказчиком в течение всего проекта
по созданию ИС, ведение разработки с применением последовательно
обрабатываемых прототипов.
Для выбора стандарта основным фактором будет являться более подробное и
полное описание работы на стадиях и этапах разработки АС.
Стандарт ISO/IEP 12207 не имеет подробного описания работы на разных
стадиях и этапах создания АС.
Стандарт CDM рассчитан на проекты с использованием Oracle-технологий,
которые не применяются в данном проекте.
Стандарт MSF, как было сказано выше, ориентирован на бизнес-сферу.
Стандарт XP больше рассчитан на команду. Поэтому в данном проекте
используется ГОСТ 34.601-90, поскольку именно у него есть описание работы на
каждом этапе разработки АС.
Базовыми стадиями создания АС являются:
1) Выведение требований к системе;
2) Создание концепции;
3) Написание ТЗ;
4) Составление технического проекта;
5) Подготовка документации;
6) Внедрение.
На этапе подготовки объекта к внедрению планируется провести следующие
работы:
закупить и установить сервер системы и серверное ПО;
развернуть на сервере базу данных;
установить клиентское ПО на все компьютеры АРМ системы;
сконфигурировать взаимодействие АРМ системы с сервером базы данных;
ввести учетные записи и настроить им права доступа;
заполнить справочники системы реальными данными;
37
обеспечить пользователей эксплуатационной документацией;
обучить персонал работе с системой.
В процессе внедрения системы участвуют: разработчики системы
(проектировщик, программист), системный администратор и будущие
пользователи системы. Системный администратор должен обеспечить место для
установки нового сервера; подключение к локальной сети для сервера и АРМ
пользователей системы; доступ к компьютерам, необходимым для развертывания
системы, с правами администратора. Проектировщик системы проводит обучение
пользователей, конфигурирует систему, заполняет справочники, проверяет
правильность взаимодействия всех подсистем. Программист оперативно устраняет
возникающие при развертывании системы неполадки.
Опытная эксплуатация системы должна проводиться не менее 3 месяцев. В
случае обнаружения ошибок на этапе опытной эксплуатации, осуществляется
поиск причин и устранение ошибок, внесение коррективов в программу, в
технологию обработки данных. После устранения ошибок подписывается «Акт о
проведении опытной эксплуатации», который служит началом перехода к третьему
этапу – сдаче системы в промышленную эксплуатацию. [6]
На этапе эксплуатации производятся следующие работы:
- периодическая актуализация справочников системы (осуществляется
ответственным за справочник лицом);
- периодическое архивирование информационной базы системы на CD-
носителях (администратор системы);
- локализация проблем и устранение причин их возникновения
(программист);
- модификация ПО (бизнес-анатилик, программист);
- подготовка предложений по совершенствованию системы (пользователи
системы);
- развитие и модернизация системы (бизнес-анатилик, программист).
Сама каскадная модель имеет множество преимуществ, но при условии
использования ее в проекте, приемлемом для нее. Ниже представлены ее
преимущества:
38
Модель хорошо знакома потребителям, не имевшим никакого отношения к
созданию и эксплуатации программ, а также конечным пользователям (часто
используется другими компаниями для отслеживания проектов, которые не связана
с разработкой ПО);
Она лучше справляется с трудностями и отлично срабатывает в тех проектах,
где все достаточно понятно, но трудноразрешимо;
Она очень доступна для понимания, т.к. преследует простую цель
выполнение необходимых действий;
Она проста и удобно в использовании, т.к. процесс разработки идет
поэтапно.
Но в случае, если каскадная модель используется в проекте, не
предназначенном для нее, проявляются следующие ее недостатки:
Основа модели линейная последовательная структура, и в результате
попытки вернуться назад на одну-две фазы для исправления проблемы или
недостатка приходится жертвовать временем и срывать график работ и затрат;
Она не может предотвращать итерация между фазами, которые очень часто
встречаются при создании ПО, поскольку сама модель строится согласно циклам
аппаратного инжиниринга;
Она не показывает главное свойство разработки ПО, которое направлено на
решение задачи. Отдельные фазы связаны определенными действиями, что часто
отличается от привычной работы коллектива или персонала;
Она создает ошибочное впечатление о работе с проектом. Указание, что
«35% выполнено» обычно не имеет какого-то смысла для менеджера проектов.
Исходя из недостатков каскадной модели, ее применение нужно ограничивать
ситуациями, в которых все требования для их разработки очень точны и понятны.
Каскадная модель хороша в циклах разработки программного продукта, где
используется фиксированное определение продукта и есть понятные технические
методики.
Спиральная модель особое внимание уделяет начальным этапам разработки
подготовке стратегии, проектированию и анализу, где все применяемые
технические решения проверяются и обосновываются методом создания
прототипов. Каждый виток спирали означает создание компонента или версии ПО.
Источник: https://baza.diplomsite.ru/previewfile/2054