76
В стандартной комплектации маршрутизатор имеет три встроенных
порта Gigabit Ethenet и слоты расширения для установки интерфейсных карт
77
2 Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
ЖЦ является непрерывным процессом, который изначально
начинается с момента выражения решения о необходимости его создания и
заканчивается после факта изъятия из обращения.
Среди самых популярных стандартов часто выделяют такие:
ГОСТ 34.601-90 – используется в АИС и устанавливает все
этапы и стадии их создания. Также он описывает содержание работ для
любого этапа. Стадии и этапы, закрепленные внутри стандарта, больше
всего соответствуют каскадной модели ЖЦ;
ISO/IEC 12207 – стандарт, указывающий процессы и
организацию ЖЦ. Может использоваться в любом виде заказного ПО.
Стандарт не имеет описания стадий и этапов;
Custom Development Metho – технологический материал по
созданию прикладных ИС, детализированный до уровня заготовок
проектных решений, которыми пользуются в проектах с использованием
средств Oracle. Применяется CDM для классической модели ЖЦ (есть все
этапы и описанные задачи), а также в процессе «оперативной разработки»
или «облегченного прохода», которые применяются в рамках малых
проектов;
Rational Unified Process (RUP) – применяет интерактивную
модель разработки, включающую 4 фазы: старт, изучение, создание и
внедрение. Каждая из фаз может делится на этапы, которые в итоге создают
версию для внутреннего или внешнего применения. Завершение всех 4 фаз
– это цикл разработки, и по завершению одного цикла генерируется новая
версия системы. Если по факту проект продолжается, то сам продукт тоже
78
изменяется и проходит вновь эти 4 фазы. Суть работы при использовании
RUP – создание и поддержка моделей на базе UML;
Microsoft Solution Framework (MSF) – аналогичен RUP, тоже
состоит из 4 фаз: изучение, разработка, реализация и проверка, считается
итерационным и включает применение объектно-ориентированных
моделей. MSF в отличии от RUP чаще всего используется для создания
бизнес ПО;
Extreme Programming (XP) – экстремальное программирование
(современная методология, создана в 1996 году). Ее суть составляют
командная работа, постоянная коммуникация с заказчиком в рамках всего
проектирования ИС, создание проекта с использованием последовательно
оптимизируемых прототипов.
Для определения стандарта главным фактором выступает более
подробное и полноценное описание работы на этапах и стадия АС.
Стандарт ISO/IEP 12207 не включает полноценного описания работы
на этапах и стадиях реализации АС.
Стандарт CDM оправдан при работе с проектами, включающими
Oracle-технологий, которые в нашем случае не используются.
Стандарт MSF, как было описано выше, направлен на бизнес-сферу.
Стандарт XP предпочтителен для команды. Поэтому в нашем случае
будет использоваться ГОСТ 34.601-90, т.к. именно он имеет описание
работы на любом этапе создания АС.
Основные стадии создания АС включают в себя:
1) Определение требований к системе;
2) Подготовка концепции;
3) Подготовка ТЗ;
4) Реализация технического проекта;
5) Написание документации;
6) Установка и использование.
79
Рисунок 2.1. Базовые стадии реализации ИС
В рамках этапа «Выведение требований к системе» реализуется
следующее:
Изучается сам объект;
Готовятся требования пользователя;
Указывается важность разработки.
В данном этапе используются такие участники, как: IT-менеджер,
руководитель отдела производства. По факту создания всех задач готовится
отчет о выполненной работе – описывается объект автоматизации,
выделяются требования системе, отражаются расходы на создание,
введение в работу и поддержку, указывается возможный эффект от
реализации и отражаются условия для корректной работы системы.
По факту реализации этапа «Отражение требований к системе»
готовятся виды концепций. Создается ряд доступных концепции и планов
реализации, анализируют ресурсы, требуемые для реализации ИС и ее
адекватной работы, изучают недостатки и преимущества всех методов,
сверяют требования пользователей и показатели всех предлагаемых систем.
В рамках этапа «Подготовка концепции» используется только IT-
менеджер. По факту завершения всех описанных работ определяется самый
удачный из всех приемлемых вариантов, который сможет полностью
удовлетворить всем требованиям.
80
По факту завершения этапа «Подготовка концепции» выполняется ТЗ
проекта автоматизации. По факту его подготовки нужно его согласовать и
утвердить. В этом этапе принимают участие: IT-менеджер и руководитель
отдела делопроизводства. По факту завершения этот пункт отражает -
функции ИС и подсистем, состав совокупных и персональных задач,
концепцию БД, состав СУБД, параметры и функции программных средств.
По факту утверждения ТЗ реализуется разработка проектного
решения. IT-менеджер и программист готовят физическую и логическую
модель БД, отражают совокупную организацию данных.
По факту окончания этапа «Подготовка технического проекта» IT-
менеджер и программист готовят рабочую документацию, состоящую из:
программных и технических требований, руководства по применению. По
итогу всех работ и написания документации нужно лишь установить
систему.
Этап установки состоит из: подготовки исследуемого объекта,
тренинг сотрудников, проведение пуско-наладочных и монтажных работ,
реализация испытаний, первый опытный запуск и приемочные испытания.
На данном этапе задействованы: IT-менеджер, сисадмин, руководитель
делопроизводства. По итогу происходит изучение итогов испытаний ИС,
проверка соответствия ТЗ, устранения возможных неполадок и подпись
всех актов.
Сейчас все чаще применяют такую следующую модель ЖЦ:
Каскадная модель (рис. 2.2) включает в себя последовательную
реализацию описанных этапов в порядке очередности. Переход на
дальнейший этап отражает полную готовность на всех предыдущих.
81
Рисунок 2.2. - Каскадная модель ЖЦ ИС
Поэтапная модель с серединным контролем (Рисунок 2.3). Создание
ИС происходит итерациями с циклами обратной связи по каждому этапу.
Межэтапные проверки помогают учесть реально возникающие
взаимовлияния итогов проектировки на различных этапах; время жизни
любого из этапов равно совокупному периоду создания.
Рисунок 2.3. - Поэтапная модель с серединным контролем
82
Спиральная модель (Рисунок 2.4). Каждый цикл реализует создание
другой версии продукта, утверждаются правила проекта, проверяется
уровень его качество, рассматриваются работы будущего цикла.
Рисунок 2.4. - Спиральная модель ЖЦ ИС
Большое внимание уделено стартовым этапам разработки –
разработке и изучению, где все технические решения корректируются и
доказываются методом создания прототипов.
Сам ЖЦ любого ПО описывает некий промежуток времени, который
приходит от момента решения о начале внедрения ПО и заканчивается в
точке его фактического изъятия из использования в системе. И весь данный
цикл – процесс существования и улучшения ПО.
Само понимание о ЖЦ программы пришло, когда программисты
поняли всю важность перехода от персональных локальных программных
решений к единому технологичному созданию ПО. И часто в такие решения
многие стараются привнести опыт их других сфер производства. Так и было
перенято понимание самого ЖЦ программных продуктов.
Выделяют ряд этапов ЖЦ:
• Изучение выдвинутых требований;
• Подготовка макета;
83
• Создание кода программы;
• Проверка и исправление недочетов;
• Запуск в серию и применение.
Сложностью в процессе создания ПО выступает принятие решений на
начальных этапах и их реализации на заключительных этапах. А выделение
ошибочных требований к проекту могут не только надолго застопорить
работу, но и привести к полному провалу проекта. Изменение в специфике
ПО часто ведет за собой полное перестроение уже пройденных этапов
разработки ПО в рамках реализации приложения.
Сам ЖЦ можно назвать процессом непрерывным, который стартует с
момента принятия решения о важности создания проекта и заканчивается в
момент вывода из использования конкретного ПО.
Основным документом, который контролирует процесс создания ЖЦ
ПО является общепринятый стандарт ISO/IEC 12207 (ISO, International
Organization of Standardization – Мировая стандартизирующая коомпания,
IEC, International Electrotechnical Commission – Международная коллегия по
электротехнике). И включает он саму структуру ЖЦ, куда входят все
процессы, действия и задачи, которые проводят подготовку в рамках
создания ПО.
Каждый описанный процесс можно определить отдельными задачами
и методами их решения, исходной информацией, приобретенной на
предыдущем этапе, и итогами. Результаты исследования, например,
включают функциональные и информационные модели, а также
построенные на их основе диаграммы. ЖЦ ПО инерционного плана: итоги
уже завершенного этапа изменяют решения по проектам, которые были на
более ранних этапах.
ЖЦ информационных продуктов и услуг становится основой для ЖЦ
ИТ и, конечно, самих ИС. Поэтому все описанное выше смело отнесем и к
нашей системе.
84
ИС включаются в состав СУБД и становятся узконаправленным
прикладным ПО.
Сама модель ЖЦ ПО описывает структуру, которая показывает
порядок реализации и взаимосвязь процессов, задач и деятельности в
рамках всего ЖЦ. Модель ЖЦ может меняться в рамках классификации,
масштаба и сложности исходного проекта и конкретных условий, где
система находится, работает и развивается.
Основную популярность получили 4 модели ЖЦ:
• Каскадный подход;
• Спиральный подход;
• Итеративны подход;
• V-подход.
Зачастую ЖЦ ПО часто включает совокупность этапов, работ и
операций в очередности их реализации и взаимосвязях, которые отражают
ведение работ от написания ТЗ до финальных проверок версий и окончания
использования ПО или ИС. Часто такие стандарты включают правила
описания исходных данных, методики реализации контроля, отслеживания
тех документов и эксплуатационных правил на комплексы ПО. Они
отражают совокупную структуру коллектива, помогают реализовать
грамотное разделение и планировку заданий, выполняют контроль
реализации всех этапов создания совокупных ПС.
Каскадный подход чаще всего используется при создании
нетребовательных ИС, когда по началу проекта цели и требования можно
довольно точно описать пожелания к системе. Главным минусом такого
подходя становится то, что процесс практической реализации проекта не
всегда укладывается в жесткую схему и всегда есть потребность в
возвращении к уже пройденным этапам для пересмотра или изменения уже
выполненных решений. По итогу сам процесс разработки ИС становится
полноценной моделью с серединным контролем.
85
Имеется несколько плюсов при применении каскадного подхода:
• Любой этап состоит из готовой проектной документации,
который отвечает требованиям согласованности и полноты;
• Все проведенные в правильной последовательности работы
помогают планировать сроки выхода на финишную прямую по всем этапам
проекта.
Цикличная модель ЖЦ была внедрена для минимизации описанных
выше проблем. В рамках выполнения этапов по проекту изучается
адекватность ТЗ и удовлетворенность потребностей заказчиков в рамках
оценки созданных прототипов. Любой цикл описывал создание некоторого
рабочего фрагмента или версии готовой программы. Такой подход помогает
уточнить цели и параметры проекта, описать совокупное качество модели,
определить требуемые работы на следующем цикле. По итогу, это позволяет
углубить детальность проекта, а по итогу получается финальный вариант,
удовлетворяющий всем требованиям заказчика, который в последствии
будет доведен до финальной стадии.
Но даже модель с циклами не помогает полноценно оперативно
реагировать на все проводимые изменения. Уточнение параметров
согласуется с пользователями лишь в конкретных точках, которые
установлены уже по факту завершения объема работ, а общие требования к
ИС отражены в ТЗ на всей протяжённости создания. Именно поэтому
иногда пользователи имеют по итогу систему, которая не может полностью
удовлетворить их потребности.
Итеративная разработка отражает текущий цикл разработки сложных
систем. Модель позволяет перенестись на последующий этап без окончания
предыдущего для того, чтобы решить главную проблему – представить
потребителю/заказчику исходный продукт, что поможет быстрее перейти к
процессу доработки и корректировки.