32
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационной системы — период времени,
который начинается с момента принятия решения о необходимости
создания информационной системы и заканчивается в момент ее полного
изъятия из эксплуатации.
Базовым нормативным документом, регламентирующим состав
основных этапов ЖЦ проекта автоматизации, является международный
стандарт ISO/IES 12207:1995 “Information Technology – Software Life Cycle
Processes”. Его аналогом является ГОСТ Р ИСО/МЭК 12207-99, введенный
в действие в июле 2000 года. Существует еще множество других
стандартов разработки ИС:
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и
этапы создания автоматизированной системы:
1. Формирование требований к АС
2. Обследование объекта и обоснование необходимости создания
АС
3. Формирование требований пользователя к АС
4. Оформление отчета о выполнении работ и заявки на
разработку АС
5. Разработка концепции АС
6. Изучение объекта
7. Проведение необходимых научно-исследовательских работ
8. Разработка вариантов концепции АС и выбор варианта
концепции АС, удовлетворяющего требованиям пользователей
9. Оформление отчета о проделанной работе
10. Техническое задание
33
11. Разработка и утверждение технического задания на создание
АС
12. Эскизный проект
13. Разработка предварительных проектных решений по системе и
ее частям
14. Разработка документации на АС и ее части
15. Технический проект
16. Разработка проектных решений по системе и ее частям
17. Разработка документации на АС и ее части
18. Разработка и оформление документации на поставку
комплектующих изделий
19. Разработка заданий на проектирование в смежных частях
проекта
20. Рабочая документация
21. Разработка рабочей документации на АС и ее части
22. Разработка и адаптация программ
23. Ввод в действие
24. Подготовка объекта автоматизации
25. Подготовка персонала
26. Комплектация АС поставляемыми изделиями (программными
и техническими средствами, программно-техническими
комплексами, информационными изделиями)
27. Строительно-монтажные работы
28. Пусконаладочные работы
29. Проведение предварительных испытаний
30. Проведение опытной эксплуатации
31. Проведение приемочных испытаний
32. Сопровождение АС.
33. Выполнение работ в соответствии с гарантийными
обязательствами
34
34. Послегарантийное обслуживание
Стандарт ISO/IEC 12207:1995 «Information Technology — Software
Life Cycle Processes» является основным нормативным документом,
регламентирующим состав процессов жизненного цикла ИС. Он
определяет структуру жизненного цикла, содержащую процессы, действия
и задачи, которые должны быть выполнены во время создания ИС.
Каждый процесс разделен на набор действий, каждое действие — на набор
задач. Каждый процесс, действие или задача инициируется и выполняется
другим процессом по мере необходимости, причем не существует заранее
определенных последовательностей выполнения. Связи по входным
данным при этом сохраняются.
Разработке данной работы было решено производить на основе
стандарта ISO/IEC 12207:1995 «Information Technology — Software Life
Cycle Processes», так как процесс разработки АРМ может быть не
последователен и процесс за процессом может выполняться по мере
необходимости. Руководство компании посчитало этот вариант наиболее
приемлемым, так как наиболее важно за время разработки АРМ не терять
прибыль.
Рассмотрим этапы жизненного цикла:
1. Анализ первичных требований и планирование работ
Основными задачами этапа являются: анализ первичных бизнес-
требований, предварительная экономическая оценка проекта, построение
план-графика выполнения работ, создание и обучение совместной рабочей
группы.
2. Проведение обследования деятельности предприятия
В рамках данного этапа осуществляется:
35
· предварительное выявление требований, предъявляемых к будущей
системе;
· определение оргштатной и топологической структур отдела;
· определение перечня целевых задач (функций) отдела;
· анализ распределения функций по сотрудникам;
· определение перечня применяемых средств автоматизации.
При этом выявляется функциональные взаимодействия между
сотрудниками, информационные потоки внутри отдела и между
сотрудниками.
В качестве исходной информации при проведении обследования и
выполнении дальнейших этапов служат:
· данные по оргштатной структуре отдела;
· информация о принятых технологиях;
· стратегические цели и перспективы развития;
· результаты интервьюирования сотрудников (от руководителей до
исполнителей нижнего звена);
· предложения сотрудников по усовершенствованию бизнес-
процессов предприятия;
· нормативно-справочная документация.
По окончании обследования строится и согласуется
предварительный вариант функциональной модели отдела, включающей
идентификацию внешних объектов и информационных взаимодействии с
ними, а также детализацию до уровня основной деятельности сотрудников
и информационных связей между этими сотрудниками.
36
3. Построение моделей деятельности отдела
На данном этапе осуществляется обработка результатов
обследования и построение моделей деятельности отдела следующих двух
видов:
модели "как есть", представляющей собой "снимок" положения дел на
предприятии (оргштатная структура, взаимодействия подразделений,
принятые технологии, автоматизированные и неавтоматизированные
бизнес-процессы и т.д.) на момент обследования и позволяющей
понять, что делает и как функционирует компания;
системного анализа, а также на основе автоматической верификации
выявить ряд ошибок и узких мест и сформулировать ряд предложений
по улучшению ситуации;
модели "как должно быть", интегрирующей перспективные
предложения руководства и сотрудников предприятия, экспертов и
системных аналитиков и позволяющей сформировать видение новых
рациональных технологий работы предприятия;
Каждая из моделей включает в себя полную структурную
функциональную модель деятельности, информационную модель (как
правило, с использованием нотации "сущность-связь"), а также, в случае
необходимости, событийную (описывающую поведение) модель (с
использованием диаграмм переходов состояний).
Переход от модели "как есть" к модели "как должно быть"
осуществляется следующими двумя способами.
1) Совершенствование технологий на основе оценки их
эффективности. При этом критериями оценки являются стоимостные и
временные затраты выполнения бизнес-процессов, дублирование и
противоречивость выполнения отдельных задач бизнес-процесса, степень
загруженности сотрудников ("легкий" реинжиниринг).
37
2) Радикальное изменение технологий и переосмысление бизнес-
процессов ("жесткий" реинжиниринг). Например, вместо попыток
улучшения бизнес-процесса проверка данных клиента, может быть следует
задуматься, а нужна ли вообще такая проверка? Возможно затраты на
такие проверки каждого из клиентов во много раз превышают убытки,
которые может понести компания в отдельных случаях
недобросовестности.
Построенные модели являются не просто реализацией начальных
этапов разработки системы и техническим заданием на последующие
этапы. Они представляют собой самостоятельный отделяемый результат,
имеющий большое практическое значение, в частности:
1) Модель "как есть" включает в себя существующие
неавтоматизированные технологии, работающие на предприятии.
Формальный анализ этой модели позволит выявить узкие места в
технологиях и предложить рекомендации по ее улучшению (независимо от
того, предполагается на данном этапе автоматизация предприятия или
нет).
2) Она позволяет осуществлять автоматизированное и быстрое
обучение новых. работников конкретному направлению деятельности
предприятия (так как ее технология содержится в модели) с
использованием диаграмм.
3) С ее помощью можно осуществлять предварительное
моделирование нового направления деятельности с целью выявления
новых потоков данных, взаимодействующих подсистем и бизнес-
процессов.
4. Разработка системного проекта
Данный этап является первой фазой разработки собственно системы
автоматизации (именно, фазой анализа требований к системе), на которой
требования заказчика уточняются, формализуются и документируются.
Фактически на этом этапе дается ответ на вопрос: "Что должна делать
38
будущая система?". Именно здесь лежит ключ к успеху всего проекта
автоматизации. В практике создания больших программных систем
известно немало примеров неудачной реализации именно из-за неполноты
и нечеткости определения системных требований. На этом этапе
определяются:
архитектура системы, ее функции, внешние условия ее
функционирования, распределение функций между
аппаратной и программной частями;
интерфейсы и распределение функций между человеком и
системой;
требования к программным и информационным компонентам
системы, необходимые аппаратные ресурсы, требования к базе
данных, физические характеристики компонент системы, их
интерфейсы;
состав людей и работ, имеющих отношение к системе;
ограничения в процессе разработки (директивные сроки
завершения отдельных этапов, имеющиеся ресурсы,
организационные процедуры и мероприятия, обеспечивающие
защиту информации).
5. Разработка предложений по автоматизации предприятия
На основании системного проекта осуществляется:
составление перечня автоматизированных рабочих мест
предприятия и способов взаимодействия между ними;
анализ применимости существующих систем управления
предприятиями для решения требуемых задач и формирование
рекомендаций по выбору такой системы;
совместное с заказчиком принятие решения о выборе
конкретной системы управления предприятием или разработке
собственной системы;
39
разработка требований к техническим средствам;
разработка требований к программным средствам;
разработка предложений по этапам и срокам автоматизации.
6. Разработка технического проекта
На данном этапе на основе системного проекта и принятых решений
по автоматизации осуществляется проектирование системы. Этот этап
разделяется на два под этапа:
1. проектирование архитектуры системы, включающее
разработку структуры и интерфейсов ее компонент
(автоматизированных рабочих мест), согласование функции и
технических требовании к компонентам, определение
информационных потоков между основными компонентами,
связей между ними и внешними объектами;
2. детальное проектирование, включающее разработку
спецификаций каждой компоненты, разработку требований к
тестам и плана интеграции компонент, а также построение
моделей иерархии программных модулей и межмодульных
взаимодействий и проектирование внутренней структуры
модулей.
При этом происходит расширение системного проекта:
за счет его уточнения;
за счет построения моделей автоматизированных рабочих мест,
включающих подсхемы информационной модели и
функциональные модели, ориентированные на эти подсхемы
вплоть до идентификации конкретных сущностей
информационной модели;
за счет построения моделей межмодульных и
внутримодульных взаимодействий с использованием техники
структурных карт.
7. Разработка и тестирование
40
Тестирование представляет собой набор процедур и действий,
предназначенных для демонстрации корректной работы АРМ в заданных
режимах и внешних условиях. Цель тестирования - выявить наличие
ошибок или продемонстрировать их отсутствие, что возможно лишь в
отдельных случаях. Важно различать тестирование и сопутствующее
понятие "отладка".
Отладка - это набор процедур и действий, начинающихся с
выявления самого факта наличия ошибки и заканчивающихся
установлением точного места, характера этой ошибки и способов ее
устранения.
8. Внедрение
На этапе внедрения проводятся подготовка и постепенное освоение
разработанной проектной документации АРМ заказчиком. В процессе
выполнения работ на этой стадии осуществляется выявление частных и
системных недоработок в предлагаемом для внедрения проектном
решении.
Существует четыре стратегии внедрения новой системы:
1. Параллельная стратегия.
2. «Скачок».
3. Пилотный проект.
4. «Узкое место».
Специфика работы паспортно-визового отдела предполагает
невозможность приостановки работы отдела из-за внедрения нового АРМ,
поскольку это может повлечь за собой приостановку работ по оформлению
визы и, как следствие, упущенную прибыль. Также риск влияния
неудачного внедрения на эффективность работы отдела должен быть
минимальным или отсутствовать.
Метод «скачка» предусматривает полный отказ от работающей
системы и моментальный и безусловный переход на новое АРМ. Это
может стимулировать пользователей системы к быстрому ее освоению,
41
однако возникает большая вероятность остановки технологического
процесса получения и обработки информации при условии, если в новой
системе возникнет сбой.
Метод «узкого места» является принципиально неприемлемым для
разрабатываемого проекта, так как предполагает внедрение АРМ в
наиболее критический участок работы предприятия, с тем, чтобы в
дальнейшем перейти к полномасштабному внедрению на всем
предприятии. Решаемая задача изначально решается на одном участке,
переход на уровень всего предприятия в целом не запланирован.
Таким образом, наиболее приемлемыми представляются два
варианта технологии внедрения АРМ – параллельная стратегия и стратегия
«скачка». Их сравнительная характеристика приведена в таблице 4.
Таблица № 4
Сравнительная характеристика стратегий внедрения ИС.
Позиция
Параллельная стратегия
«Скачок»
Случай
применения
Старую работающую систему
необходимо заменить новой
Полный отказ от работающей
системы и моментальный и
безусловный переход на новое
АРМ
Область
применения
Не имеет значения
Не имеет значения
Риск срыва
работы
Риск минимальный
Риск высок
Продолжение таблицы № 4
Позиция
Параллельная стратегия
«Скачок»
Дублирование операций
Есть
Есть