53
Операционная система
Windows 7/8/10
.NET Framework
V 4.5
Система состоит из трех компонент:
- сервер базы данных;
- администраторская часть системы;
- клиентские приложения.
Первые две части размещаются на серверном ПК, это может быть любой
из ПК включенный в локальную сеть организации. Для удобного пользования и
опперативного доступа ПК должен быть в прямом доступе начальника отдела
ОТОиР. Клиентские приложения устанавливаются на ПК пользователей.
Для полноценной работы серверной и администраторской части системы
рекомендуемые аппаратные требования такие:
Таблица 1.3 - Таблица с описанием рекомендуемых аппаратных
требований
Процессор
Двухъядерный с частотой не менее 2GHz, рекомендуемый
процессор: Intel Core i3-9100F 3.6GHz/8GT/s/6MB
ОЗУ
4096 Мб
Периферия
Клавиатура, мышь
Принтер
Струйный/Лазерный
54
II ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта зависит от многих факторов и параметров.
Основную роль играют: глобальность системы и широта функционального
охвата, сроки, выделяемые на проект, планируется ли выход последующих
версий, какой срок планируется эксплуатировать систему (с учетом обновления
версий).
Существует целый ряд стандартов, регламентирующих ЖЦ ИС, а в
некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие.
ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Стадии создания
(дата введения 1992-01-01) – распространяется на автоматизированные системы
и устанавливает стадии и этапы их создания. Кроме того, в стандарте
содержится описание содержания работ на каждом этапе. Стадии и этапы
работы, закрепленные в стандарте, в большей степени соответствуют каскадной
модели жизненного цикла.
ISO/IEC 12207:1995 Information Technology – Software Life Cycle
Process(принят в качествероссийского стандарта ГОСТ Р ИСО/МЭК 12207-99 –
Информационные технологии. Процессы жизненного цикла программных
средств, дата введения 2000-07-01) – стандарт на процессы и организацию
жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не
привязан к конкретной модели ЖЦ. Стандарт не содержит описания фаз,
стадий и этапов.
ISO/IEC 15288 Systems engineering. System life cycle processes
(Системная инженерия. Процессы жизненного цикла систем). Принят в
качестве российского стандарта ГОСТ Р ИСО/МЭК 15288-2005 –
55
Информационная технология. Системная инженерия. Процессы жизненного
цикла информационных систем.
Стандарт применим для любого рода систем, но его основное
предназначение – поддержка создания компьютеризированных
информационных систем.
В стандарте ISO/IEC 15288 предусмотрены следующие стадии создания
систем (табл. 1.1).
Таблица 2.1 - Стадии создания систем (ISO/IEC 15288)
№ п/п
Стадия
Описание
1
Формирование
концепции
Анализ потребностей, выбор концепции и проектных
решений
2
Разработка
Проектирование системы
3
Реализация
Изготовление системы
4
Эксплуатация
Ввод в эксплуатацию и использование системы
5
Поддержка
Обеспечение функционирования системы
6
Снятие с эксплуатации
Прекращение использования, демонтаж, архивирование
системы
Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует
включать следующие группы процессов:
1. Договорные процессы:
2. Процессы предприятия:
3. Проектные процессы:
4. Технические процессы:
Основные задачи, рассматриваемы в дипломном проекте, относятся к
проектным и техническим процессам.
Рассмотрим стадии жизненного цикла инфолрмационной системы в
разрезе согласованности основных стандартов.
56
Таблица 2.2 - Стадии жизненного цикла информационной системы
Клас-
кий ЖЦ
ИСО/МЭК
12207
ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00
Стадия
Основные этапы (работы)
Системный
анализ
Заказ
Формирование
требований к
ИС
Технико
-экономическое
обоснование (ТЭО)
1. Обследование объекта и обоснование
необходимости создания ИС.
2.Формирование требований Заказчика к ИС.
3.Оформление договора между Разработчиком и
Заказчиком.
Анализ
требова
ний
Разработка
Разрабо
тка
концеп
ции ИС
1. Поиск путей удовлетворения требований
Заказчика на уровне концепции создаваемой
системы (структура, функции, программно-
техническая платформа, режимы).
2.Рассмотрение альтернативных вариантов
концепции системы, их анализ и выбор лучшей
концепции.
Проектирование
Техническое
задание (ТЗ)
Разработка, согласование и утверждение ТЗ на
создание ИС.
Эскизный проект
Разработка предварительных проектных решений
по системе и ее частям.
Пилот
-
проект
1. Разработка частей проекта для испытаний в
реальных, но ограниченных условиях
функционирования с целью проверки
предварительно принятых решений.
2. Проведение испытаний на головном объекте
или стенде и анализ результатов испытаний.
Технический проект
1.Разработка проектных решений по системе и ее
частям.
2.Разработка документации на ИС и ее части.
3.Разработка документации на поставку изделий
для комплектования ИС и/или технических
заданий на их разработку.
4.Разработка заданий на проектирование в
смежных частях проекта объекта автоматизации
(строительство, монтаж, наладка и др.).
57
Кодирование
(реализация)
Рабочая
документация
1.Разработка рабочей документации на систему и
ее части.
2.Разработка программных и технических средств.
3. Тестирование средств.
Тестиро
вание
Интегр
ация и
тестиро
вание
1.Загрузка БД типовыми исходными данными и
тестами.
2.Интеграция программ и тестирование в
имитированной среде.
3.Интеграция программных средств с
аппаратными в реальной операционной и внешней
среде.
4.Тестирование в реальной среде.
5.Разработка комплекта документации для
пользователей.
Внедрение и сопровождение
Поставка и
эксплуатация
Ввод в
действи
е на
головно
м
объекте
(ввод в
эксплуа
тацию,
внедрен
ие)
1.Подготовка объекта автоматизации к вводу ИС в
действие.
2.Подготовка персонала.
3.Комплектация ИС поставляемыми изделиями.
4.Проведение предварительных испытаний и
передача ИС для опытной эксплуатации.
5.Проведение опытной эксплуатации.
6.Проведение приемочных испытаний
Тиражи
рование
(при
внедрен
ии на
несколь
ких
объекта
х)
1.Передача эталона загрузочных модулей ПО и
эксплуатационной документации в группу
сопровождения от организации.
2.Тиражирование документации.
3. Обучение и консультации пользователей.
4. Поставка ПО и документации на объекты
внедрения.
Сопровождени
е и
эксплуатация
Сопровождени
е (авторский
надзор)
1.Оказание научно-технических услуг в
послегарантийный период.
2. Разработка методики оформления отчетов об
ошибках и предложениях на изменение версий.
Модель ЖЦ определена особенностями организации труда в компании,
особенностями проекта, целесообразностью и личными предпочтениями
руководителей проекта.
В случае рассматриваемого проекта применяется исключительно
классическая каскадная модель ЖЦ с обратной связью.
Основная причина выбора такой модели продиктована особенностями
проекта: раз в 2-3 года планируется выход новой версии комплекса, эта версия
в целом основана на предыдущих, но с исправлениями и добавлениями новых
функций. Основной причиной такого выбора является сложность в
определении всех нужных функций, особенностей реализации и т.д. На каждой
отдельной итерации удобно и целесообразно использовать каскадную модель с
обратной связью. На рис. 2.1 видно, что в ходе работы над проектом может
меняться даже первоначальные требования и спецификация. С одной стороны
58
это выглядит немного странно, но в данном случае это приемлемо, так как
удобство и покрытие нужд организации может быть полноценно
протестировано только в ходе непосредственной эксплуатации.
Этапы разработки ПК (программного комплекса) выбираем согласно
ГОСТ Р ИСО/МЭК 12207-2010
Представление проекта на уровне этапов (рис. 2.1)
Разработку программного обеспечения можно разделить на отдельные
стадии, в каждой из которых в свою очередь, можно выделить отдельные
этапы и работы. Согласно ГОСТ-у, обычно выделяют следующие стадии при
разработке программного обеспечения:
1. Техническое задание.
2. Эскизный проект.
3. Технический проект.
4. Рабочий проект.
5. Внедрение.
59
Формирование
спецификации новой
версии
Отзывы и замечания
пользователей
предыдущей версии
Моделирование и
математическое
обеспечение алгоритмов
Разработка алгоритмов
и их внедрение в
комплекс
Тестирование и экспертная оценка
специалистов консультантов
Изменения в интерфейсе ПО
Выпуск релиза версии
Приёмочное тестирование
Внедрение новой версии ПК
Сопроводительная
документация
Отчет
Корректировки спецификации
Корректировки мат. методов
Корректировки спецификации
Корректировки алгоритмов и методов
Интерфейсные изменения
Использование в реальных условиях бизнес-процессов компании
Подготовка документации
Корректировки различных уровней
Рисунок 2.1 – Этапы реализации проекта
На первой итерации (когда еще нет предыдущих версий) первый блок
заменяется на: «Результаты интервьюирования и набор ожидаемых заказчиком
функций». Результаты интервьирования служат базой для написания
постановки задачи (технического задания), которые описывают спецификации
будущего программного продукта.
60
Понятие стратегии автоматизации включает в себя базовые принципы,
используемые при автоматизации предприятия. В ее состав входят следующие
компоненты:
цели: области деятельности предприятия и последовательность, в
которой они будут автоматизированы
способ автоматизации: по участкам, направлениям, комплексная
автоматизация
долгосрочная техническая политика - комплекс внутренних
стандартов, поддерживаемых на предприятии
ограничения: финансовые, временные и т.д.
процедура управления изменениями плана
Стратегия автоматизации в первую очередь должна соответствовать
приоритетам и стратегии (задачам) бизнеса. В понятие стратегии также должны
входить пути достижения этого соответствия.
Способ автоматизации – «по участкам»(автоматизируется отдельный
участок деятельности отдела ОТОиР), выбранный тип стратегии - «узкое
место». Такая стратегия определяется самой постановкой задачи, ведь
автоматизация учета и контроля заявок на ремонт оборудования эта малая часть
от всех существующих бизнес-процессов.
Данная стратегия также характерна: план внедрения затрагивает
преимущественно автоматизируемый процесс, частичная переподготока
(обучение и инструктажи) нужны только для сотрудников, принимающих
непосредственное активное участтие в протекании процесса (администратор
системы, ответсвенные работники - исполнители). Для других сотрудников
(сотрудники_заявители) достаточно создать справку-инструкцию и правильно
продумать интерфейс формы для оформления заявки.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Основные риски данного проекта связаны с неправильной оценкой
потребности и реализация функционала, который не соответствует
61
ожидаемому. Эти риски можно минимизировать предварительным детальным
исследованием проблемы и предпроектным моделирование. Именно последнее
дает возможность выявить часть несоответствий еще до начала стадии
программной реализации. Кроме основных рисков, существуют и риски,
которым подвержен практически любой проект. Основные риски представлены
в табл. 2.3
45
Таблица 2.3 – Риски проекта
Тип (категория
риска)
Риск
Последствия
Меры по
предотвращению
Меры по
минимизации
последствий
Вероятность
свершения риска [P]
Степень ущерба
[L]
Влияние
(фактор риска)
[R] = [P] x [L]
ошибки,
присущие
расписанию,
организационный
Сложно четко
спланировать
работы и
оценить сроки
Не соблюдение
оговоренных сроков
реализации проекта
Постоянный
контроль,
динамическое
перепланирование и
перераспределение
трудовых ресурсов
согласование
сроков с
заказчиком с
резервом времени
8
8
64
Неправильные
архитектурные
решения
Неправильный
выбор
изначальных
конфигураций,
архитектуры и
технологий
Невозможность
масштабирования,
невозможность
реализации отдельных
функций. В критичном
случае – полный крах
проекта
Серьёзный уровень
анализа и
моделирования
Обращение к
опыту разработки
подобных
проектов
4
10
40
Смена
сотрудников
Зависит от
уровня
сотрудника и его
роли в проекте
При смене рядового
кодера – последствия
минимальны, при смене
архитектора проекта –
большие риски с
успешным завершением
Риск трудно
предотвратим
Четкая детальная
документация всех
фаз и этапов,
документация кода
и отслеживание
4
7
32