58
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Процессы жизненного цикла проекта автоматизации
Определение жизненного цикла становится одним из главных понятий
методологии проектирования ИС. Жизненный цикл любой ИС можно
отобразить как непрерывный процесс, который начинается в момент принятия
решения о разработке ИС и заканчивается в момент завершения ее
эксплуатации.
Жизненный цикл ИС включает в себя все стадии и этапы ее создания,
сопровождения и развития:
• Анализ предметной, формирование функциональной и информационной
моделей объекта, для которого предназначается ИС;
• Проектирование ИС, основанное на разработке проектных решений,
которые отвечают всем требованиям ТЗ;
• Создание системы (в т. ч. программирование и тестирование ПО на базе
проектных спецификаций подсистем, утвержденных на стадии проектирования);
• Тестирование ИС и отслеживание сбоев для их последующего устранения;
• Внедрение и эксплуатация системы;
• Модернизация системы.
Жизненный цикл идет в соответствии с выбранной моделью ЖЦ.
Имеется целый ряд стандартов, определяющих ЖЦ ПО, а иногда и процессы
разработки.
Среди самых известных стандартов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе стадии и
этапы их создания. Также в нем имеется описание содержания работ на всех
этапах. Стадии и этапы работы, отраженные в стандарте, зачастую
соответствуют каскадной модели жизненного цикла.
• ГОСТ Р 12207-2010 - стандарт на процессы и реализацию жизненного
цикла. Применяется ко всем видам заказного ПО. Стандарт не имеет описания
стадий, фаз и этапов.
• Custom Development Method по созданию прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
59
документов, которые рассчитаны на применение в проектах совместно с Oracle.
Используется CDM для типовой модели ЖЦ (имеются все работы/задачи и
этапы), а также для случаев "быстрой разработки" (Fast Track) или
"облегченного подхода", которые будут оптимальны в малых проектах.
• Rational Unified Process (RUP) включает в себя итеративную модель
разработки, имеющую четыре фазы: старт, анализ, создание и использование.
Все эти фазы могут быть разделены на этапы (итерации), по итогу которых
имеется версия для внутреннего или внешнего использования. Реализация
четырех основных фаз считается циклом разработки, и любой такой цикл
завершается созданием версии системы. В случае, если работа над проектом не
прекращается и после этого, полученный продукт продолжает оптимизироваться
и снова проходит те же фазы. Суть реализации в рамках RUP - это разработка и
сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) похож на RUP, так же имеет четыре
фазы: исследование, построение, создание, стабилизация, является
итерационным, включает в себя применение объектно-ориентированного
моделирования. MSF в отличии от RUP в сильнее ориентирован на создание
бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование (самая
молодая среди остальных методологий) было реализовано в 1996 году. В основе
методологии лежит командная работа, четкая коммуникация между
исполнителем и заказчиком в течение всего срока проекта, а сама разработка
реализуется методом последовательной доработки прототипов.
Стандарт ISO/IEC серии 12207.
В стандарте ISO/IEC 12207 нет конкретной модели жизненного цикла и
методик разработки, его характеристики становятся общими для любых моделей
жизненного цикла. Моделью обычно называется структура, позволяющая
выразить последовательность реализации и взаимосвязи процессов, задач и
действий в процессе всего жизненного цикла.
В настоящее время существует две основные модели жизненного цикла – это
каскадная и спиральная модели. В каскадной модели процесс разработки идет
поэтапно, шаг за шагом. Переход к следующему этапу происходит только после
60
завершения предыдущего. В спиральной модели разработка проходит по
нарастающей. На начальном этапе разрабатывается система с высоким уровнем
абстракции, а на последующих витках эта разработка все больше и больше
конкретизируется. Для жизненного цикла текущего проекта была выбрана
каскадная модель, так как для разрабатываемой системы больше подходит
поэтапная разработка. Переход к следующему этапу происходит только после
завершения всех работ на предыдущем этапе включая подготовку полного пакета
документации, достаточной для того, чтобы разработка могла быть продолжена
другой группой разработчиков и есть возможность планирования сроков
завершения работ и затрат на их выполнение.
Анализ
На этом этапе проводится исследование
проблемы, которая должна быть решена,
четко формулируются все требования
заказчика. Результатом, получаемым на
этом этапе, является техническое
задание, согласованное со всеми
заинтересованными сторонами.
Разработка проектных решений,
удовлетворяющих всем требованиями,
сформулированным в ТЗ. Результатом
этого этапа является комплект проектной
документации, содержащей все
необходимые данные для реализации
проекта.
Последний этап — сдача
готового проекта, и ввод
его в эксплуатацию.
Проектирование
Реализация
Внедрение
Сопровождение
Проводится проверка полученного
программного обеспечения на предмет
соответствия требованиям, заявленным в
ТЗ. Опытная эксплуатация позволяет
выявить различного рода скрытые
недостатки, проявляющиеся в реальных
условиях работы информационной
системы.
Реализация проекта. Здесь осуществляется
разработка программного обеспечения в
соответствии с проектными решениями,
полученными на предыдущем этапе.
Методы, используемые для реализации, не
имеют принципиального значения.
Результатом выполнения этого этапа
является готовый программный продукт.
Рисунок 2.1 Каскадная схема разработки ПО.
Каскадный метод хорошо подходит для построения систем, где в самом
начале разработки можно достаточно точно и полно сформулировать все
требования, с тем, чтобы предоставить разработчикам свободу реализовывать их
как можно лучше с технической точки зрения. Однако в случае, если в середине
разработки вскрываются ошибки, допущенные в начале, то приходится прибегать к
энтраверсии проекта и реальная схема каскадной модели приобретает другой вид.
Таким образом, каскадный метод более всего подходит к конкретной разработке.
61
Анализ
Проектирование
Реализация
Внедрение
Сопровождение
Рисунок 2.2 Реальный процесс разработки ПО по каскадной схеме.
Спиральная модель (англ. spiral model) была разработана в середине 1980-х
годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-
check-act). При использовании этой модели ИС создается в несколько итераций
(витков спирали) методом прототипирования.
Прототип — действующий компонент ИС, реализующий отдельные
функции и внешние интерфейсы. Каждая итерация соответствует созданию
фрагмента или версии ИС, на ней уточняются цели и характеристики проекта,
оценивается качество полученных результатов и планируются работы следующей
итерации.
На каждой итерации оцениваются:
Риск превышения сроков и стоимости проекта
Необходимость выполнения еще одной интеграции
Степень полноты и точности понимания требований к системе
Целесообразность прекращения проекта.
Один из примеров реализации спиральной модели — RAD (англ. Rapid
Application Development, метод быстрой разработки приложений).
Естественное развитие каскадной и спиральной моделей привело к их
сближению и появлению современного итерационного подхода, который
представляет рациональное сочетание этих моделей. Различные варианты
62
итеграционного подхода реализованы в большинстве современных технологий и
методов: RUP, MSF, XP.
В связи с небольшим объемом проектных работ, а также характером
проекта выберем спиральную модель для описания жизненного цикла. В
соответствии с этим в него будут входить следующие этапы:
Формирование требований;
Проектирование;
Реализация;
Тестирование;
Ввод в действие;
Эксплуатация и сопровождение.
Для выполнения работ в описанных рамках необходимо привлечь
следующих специалистов:
программист;
тестер;
консультант (сотрудник склада);
менеджер проекта – системный администратор.
Существует 4 основных стратегии внедрения информационной системы:
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.
Параллельная стратегия не подходит, так как компания не располагает
достаточными ресурсами для ведения учета одновременно в автоматизированном и
ручном вариантах. Стратегия Скачок не позволяет плавно перейти на
использование разработки, узкое место больше подходит для использования в
подобных компаниях. Поэтому в качестве стратегии внедрения ИС была выбрана
«Опытная эксплуатация пилотного проекта».
Таким образом, в дипломном проекте выбран стандарт ЖЦ ИС ISO/IEC
серии 12207, выбрана модель спиральная ЖЦ ИС, стратегия внедрения «Опытная
эксплуатация пилотного проекта».
63
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Любой проект по созданию информационной системы предприятия всегда
включает множество задач, связанных с общим управлением проектом,
разработкой ПО, проектированием ИС, внедрением, каждая из которых сама по
себе является проектом с присущими ему особенностями. Поэтому в ходе
разработки существуют различные риски.
Риски заказчика связаны с неполным достижением целей проекта и не
эффективно израсходованными средствами, а риски исполнителя - с возможностью
резкого превышения фактической себестоимости работ по сравнению с плановой.
Необходимость ведения параллельных и подчас принципиально отличающихся по
своему характеру работ приводит к тому, что многократно возрастает уровень
риска проекта.
Наиболее характерные риски проекта приведены в таблице 2.1.
Таблица 2.1
Возможные риски проекта
Этапы возникновения дефектов и ошибок
Типы первичных дефектов и ошибок
программного средства и
документации
Формирование
требований
Разработка требований
к ПО
Дефекты исходных требований
заказчика
Проектирование
Планирование работ
Дефекты, обусловленные реальной
сложностью проекта
Проектирование
архитектуры системы
Ошибки планирования и системного
проектирования программного
средства
Детальное
проектирование ПО
Системные и алгоритмические
дефекты и ошибки проекта
Реализация
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов
программного средства
Тестирование
Тестирование ПО
Программные и алгоритмические
ошибки программного средства и
документации
Ввод в действие
Разработка
документации
Дефекты и ошибки обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
64
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает в
себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль
«Регистрация»
Модуль
«Ввод»
Модуль
«Отчеты»
Сотрудники
Чтение
Полный
Ввод
данных
Полный
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
- использованием программно-аппаратных комплексов;
- разработкой и соблюдением политик безопасности;
- использованием защищенных каналов связи при передаче информации;
- использованием антивирусных средств;
- физической защитой помещений с наиболее ценной информацией.
Характеристика используемых средств от внешних угроз информационной
безопасности приведена в таблице 2.3.
65
Таблица 2.3
Характеристика используемых средств защиты от внешних угроз
информационной безопасности
Способ (метод)
Описание (наименование средства)
Программно-аппаратные комплексы
защиты информации
КСЗИ «Панцирь-К»
Разработка и соблюдение политик
безопасности
- ограничение доступа пользователей к
информации;
- анализ и статистика нарушений
информационной безопасности;
- информационный мониторинг;
- распределение ответственности по
обеспечению информационной
безопасности;
- определение порядка работы с
информацией, являющейся
конфиденциальной.
Защита каналов связи
протокол SSH
Антивирусная защита
Kaspersky Total Space Security
Физическая защита помещений
- система контроля и управления
доступом;
- оборудование помещений решетками
на окнах;
- разграничение прав доступа в
помещения.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области. Кроме
того, она объясняет, на основе каких входных документов и какой нормативно-
справочной информации происходит выполнение функций по обработке данных и
формирование конкретных выходных документов. Информационная модель
представлена на рис. 2.3.
66
Учет пользователей Учет запросыУчет оборудования Учет запчастей
Спр Работы
Спр Работы*
Т Запросы
Спр Запчасти
Спр Запчасти*Спр Цеха*
Спр Цеха
Сотрудник
ИС Сотрудник
Т Запросы*
Т Пользователи
Т Пользователи*
Спр Оборудование
Спр Оборудование*
Сведения о
пользователях
Поступающий запрос
на выполнение работ
Сведения об
имеющимся
оборудовании
Сведения о запчастях
Отчет по количеству
поступивших заявок за период
за каждый цех сравнительно с
другими цехами
Отчет по количеству
поступивших заявок за
период за каждый цех
сравнительно с другими
цехами
Отчет по простаивающему
оборудованию в настоящий
момент
Отчет по
простаивающему
оборудованию в
настоящий момент
Сравнительный отчет по
простою оборудования
каждого цеха за период
Сравнительный отчет по
простою оборудования
каждого цеха за период
Сравнительный отчет по
количеству выполненных
заявок за период за каждый
отдел сравнительно с
другими отделами ремонтного
подразделения
Сравнительный отчет
по количеству
выполненных заявок за
период за каждый отдел
сравнительно с другими
отделами ремонтного
подразделения
По оборудованию, которое
более всего простаивало за
период (сравнительно по
типам)
По оборудованию,
которое более всего
простаивало за период
(сравнительно по типам)
Отчет по загруженности
работников ремонтной службы
за определенный промежуток
времени
Отчет по загруженности
работников ремонтной
службы за
определенный
промежуток времени
Рисунок 2.3 Информационная модель системы
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Входной информацией для разрабатываемой информационной системы
являются данные о запросах, пользователях системы, запчастях и оборудовании..
Эти данные поступают как в цифровом, так и в печатном виде.
Входная информация содержит следующие данные:
1 Сведения о пользователях:
Фамилия
Имя
Отчество
67
Логин
Пароль
Тип пользователя
Телефон
еmail
Отдел
2 Поступающий запрос на выполнение работ
Пользователь
Оборудование
Дата запроса
Вероятная причина
Примечание
Описание
3 Сведения об имеющимся оборудовании:
Тип оборудования
Наименование
Инв._номер
Серийный_номер
Дата_учета
Примечание
К справочной информации относятся справочники Цеха, Работы,
Оборудование, Запчасти.
Экранная форма для ввода данных в справочник Цеха приведен на рисунках
ниже.