32
под программную среду в условиях АО «Петроэлектросбыт». Также,
разрабатываемая система ИС должна иметь возможности по доработке
функционала при изменении потребностей организации. Система не должна
иметь неиспользуемого функционала. Система должна представлять собой:
приложение Windows, обладать понятным пользовательским интерфейсом,
интерфейс администратора должен иметь набор необходимых функций, также
должна быть реализована возможность по формированию отчетности согласно
поставленным задачам.
При реализации проекта необходимо определить следующие стадии [11,
стр.30]:
1. Проведение анализа существующих бизнес-процессов деятельности
службы технической поддержки с использованием разработанного программного
решения. Предполагает проведение сбора и анализа технологии работы
специалистов.
2. Определение функций, подлежащих автоматизации.
3. Определение стратегии автоматизации. Проведение анализа
существующих стратегий автоматизации и подбора наиболее подходящего
варианта для АО «Петроэлектросбыт».
4. Разработка документа «Техническое задание» и сроков исполнения работ
Далее проведем выбор стратегии автоматизации применительно к данному
проекту.
Принятыми в настоящее время стратегиями автоматизации являются [10,
стр.44]:
- Кусочная (предполагает автоматизацию для каждой из задач с
использованием собственной информационной системы;
- По участкам (автоматизируются участки деятельности с использованием
собственного ПО);
- По направлением (производится автоматизация направления
деятельности);
- Полная автоматизация (весь технологический процесс автоматизирован с
использованием одного программного продукта).
33
В рамках данного проекта в качестве способа автоматизации была выбрана
стратегия автоматизации по направлению, направлением является «деятельность
службы технической поддержки». Использование полной автоматизации
нецелесообразно, так как остальные направления деятельности АО
«Петроэлектросбыт» не имеют связи с изучаемой технологией.
1.4.3. Выбор и обоснование способа приобретения ИС для
автоматизации задачи
Сравнение способа индивидуального проектирования, который был выбран
для АО «Петроэлектросбыт» в создании информационной системы деятельности
службы технической поддержки с методами, использующими пакеты программ
или модельного проектирования, может быть осуществлен в рамках данного
проекта с привлечением опыта создания пакета прикладных программ силами
коллектива программистов. Для коллектива программистов требуется
обязательно наличие руководителя проекта – системного программиста, который
осуществляет системную разработку проекта и распределяет его разные участки
между разработчиками. Здесь требуются организаторские способности,
способности увидеть сильные стороны каждого программиста – участника
проекта и талант, чтобы оптимальным образом распределить разные участки
проекта между всеми его участниками. Требуется согласованная работа всех
участников, составление плана работа, его периодическая сверка и возможная
модификация в связи с непредвиденными или обычными обстоятельствами.
Очень много таких проектов были провалены из-за некомпетентности их
руководителя, который хотя сам и мог быть профессиональным программистом,
но как руководитель группы программистов он оказался дилетантом и своей
безграмотностью в руководстве, неумения заметить сильные и слабые стороны
участников проекта являлся причиной провала проекта. Сложность такого
проекта и его трудоемкость, временные затраты и затраты финансов в разы и
десятки раз превышают затраты финансов в случае индивидуальной разработки.
В этом преимущество индивидуальной разработки.
34
Недостатки индивидуальной разработки сводятся в основном в
сравнительно невысоком качестве разработанного программного обеспечения (за
исключением редких случаев) из-за ограниченного количества человеко-часов
разработки, из-за применения простейших средств разработки, исключающих
обычно создания сложнейший объектно и предметно ориентированных схем и
методов программирования и соответствующих программных библиотек,
сведения процесса разработки программного обеспечения в основном к методам
структурного программирования, уступающего по глубине и эффективности
методам ООП (объекто-ориентированного программирования).
Далее проведем выбор способа приобретения программного решения для
информационной системы деятельности службы технической поддержки».
Существуют следующие способы приобретения программных решений [10,
стр.22]:
Приобретение готового специализированного программного решения;
Разработка программного решения силами специалистов компании;
Привлечение специалистов сторонней организации для разработки
программной системы;
Приобретение системы с последующей её доработкой.
В рамках данного проекта выбран способ приобретения программного
продукта через собственную разработку в силу следующих причин [15, стр.46]:
- Наличие в штате специалистов, способных провести разработку системы;
- Возможность доработки системы под специфику организации;
- Отсутствие зависимости от сторонних разработчиков, которые могут
изменять ценовую политику при разработке и сопровождении, либо отказаться от
проекта.
1.5. Обоснование проектных решений
1.5.1 Обоснование проектных решений по техническому обеспечению
Под техническим (аппаратным) обеспечением информационной системы
понимается весь комплекс электронных, электрических и механических
устройств, входящих в состав системы и/или сети, исключая программное
35
обеспечение и хранимую информацию. В этот комплекс входят: компьютеры,
периферийные устройства ввода/вывода и хранения информации, а также сетевое
оборудование различных типов и энергетическое оборудование (батареи и
аккумуляторы).
Параметры аппаратного обеспечения серверной части определены согласно
требованиям к СУБД, требования к рабочей станции – по оценке нагрузки на
рабочую станцию приложения для автоматизации системы документооборота по
обработке заявок службы технической поддержки.
Требования к техническому обеспечению формировались исходя из
аппаратных требований используемого программного обеспечения, и
представлены в таблице 11.
Таблица 11
Аппаратные требования информационной системы
Сервер
Клиент
Процессор
2,9 ГГц (с архитектурой x64).
Оптимальное число ядер – от 4.
От 2,6 ГГц
ОЗУ
От 4ГБ
От 2ГБ
Видеокарта и
монитор
монитор SVGA (с минимальным разрешением 1024х768
точек)
Жесткий диск
120 Гб
Для работы программы
необходимо от 100 МБ
Оптический
привод
DVD-RW (возможно
использование внешнего USB-
привода)
-
Устройства
ввода
клавиатура и мышь
ЛВС
Пропускная способность 1GB/c
Анализ аппаратных требований дает основание утверждать, что
существующих средств технического обеспечения для функционирования
создаваемой информационной системы деятельности службы технической
поддержки достаточно, необходимость в модернизации и замене отсутствует.
36
1.5.2 Обоснование проектных решений по информационному
обеспечению
Информационное обеспечение – совокупность проектных решений по
объемам, размещению, формам организации информации (единой системы
классификации и кодирования информации унифицированных систем
документации, схем информационных потоков), циркулирующей в организации,
а также методология построения баз данных. [8]
Все информационного обеспечения можно разделить на два типа:
внемашинное и внутримашинное информационное обеспечение.
Внемашинное информационное обеспечение включает показатели,
необходимые для решения управленческих задач; их объемно-временные
характеристики и информационные связи; различные классификаторы и коды;
унифицированную систему документации для отражения показателей; формы
вывода результатов обработки.
Автоматизация управленческих операций требует приведения всего
множества показателей в единую, целостную систему, установления их
содержательного и терминологического единства (однозначности), а также
четких взаимодействий между ними.
В процессе проектирования информационной системы деятельности
службы технической поддержки» АО «Петроэлектросбыт» потребуется
использование ряда классификаторов:
Локальный классификатор клиентов;
Локальный классификатор видов неисправностей;
Локальный классификатор оборудования.
В качестве входных документов информационной системы используются:
Заявка на выполнение работ в службу технической поддержки
Выходной информацией будет являться сформированная отчетность по:
Отчет по неисполненным заявкам;
Ведомость по специалистам службы технической поддержки;
Свод по функционированию оборудования.
37
В большинстве случаев, использование унифицированных форм в
управлении системой документооборота не представляется возможным, так как
такие формы отсутствуют.
1.5.3. Обоснование проектных решений по программному
обеспечению
Программное обеспечение - совокупность программ системы обработки
информации и программных документов, необходимых для эксплуатации этих
программ. [6]
В таблице 12 приведен перечень проектных решений по видам
программного обеспечения, используемых в данной работе.
Таблица 12
Перечень программного обеспечения, используемого в
проекте автоматизации АО «Петроэлектросбыт»
Тип ПО
Наименование
ПО
Назначение ПО
Системное ПО
Windows 2012
Server
Управление ресурсами
вычислительной сети АО
«Петроэлектросбыт» , контроль
учетных записей, использование
административных политик
Офисное ПО
OpenOffice.org
4.1, MS Office
2010
Работа по подготовке
документов, электронных
таблиц, отчетности различного
типа, вывод данных из внешних
приложений
Инструментальное
ПО
Embarcadero
Delphi XE10
Разработка приложения для
автоматизации технологии
работы специалистов
СУБД
MS SQL Server
2008
Работа с базами данных
прикладных программных
комплексов
Прикладное ПО
1С: Предприятие
8.3
Работа специалистов по кадрам,
бухгалтерскому, складскому
учету, специалистов по кадрам
ПО для
обеспечения
информационной
безопасности
Kaspersky
EndPoint Security
10
Обеспечение антивирусной
защиты
38
Таким образом, при расчете требований к параметрам технического
обеспечения необходимо учитывать системные требования для обеспечения
функционирования всего комплекса программного обеспечения, используемого в
условиях АО «Петроэлектросбыт».
39
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Проведем выбор концепции жизненного цикла в рамках проектирование
системы автоматизации службы технической поддержки АО
«Петроэлектросбыт».
Жизненным циклом информационной системы является период создания и
использования информационной системы, который охватывает различный её
состояния, начиная с момента появления необходимости в ее реализации и
заканчивая моментом вывода системы из эксплуатации [9, стр.20].
В настоящее время к наиболее распространенным стандартам,
регламентирующим вопросы реализации жизненного цикла информационных
систем, относятся [17, стр.70]:
- ГОСТ 34 (ГОСТ 34.601-90 «Автоматизированные системы Стадии
создания»),
- ISO 12207 «Standard for Information Technoiogy - Software Life Cycle
Processes», ISO 15288 «Standard for Information Technoiogy - System Life Cycle
Processes».
Стандарт ГОСТ 34.601-90 в рамках создания и развития
автоматизированных систем является достаточно обобщенным, при этом
предъявляет набор жестких требований к структуре жизненного цикла
информационной системы, а так же к объемам, свойствам и содержанию
проектной документации. В настоящее время данный стандарт считается
устаревшим. Стандарты ISO 12207 и ISO 15288 являются международными
стандартами, регламентирующими структуру жизненного цикла. Данные
стандарты являются более современными, по сравнению с ГОСТ 34. Различия
данных стандартов состоят в том, что ISO 12207 используется при разработке
исключительно программных продуктов, а стандарт ISO 15288 нацелен на полный
анализ автоматизированных систем, включая программную и аппаратную
платформы. В силу этого, в данном проекте будет применен стандарт жизненного
цикла ISO 12207.
40
Существуют следующие основные стратегии внедрения системы [10]:
1. Параллельная стратегия, при которой одновременно функционируют
старая (ручная) и новая система, и производится сравнение их выходных
документов. Если они согласуются длительное время, производится переход на
новую систему.
2. "Скачок". Данная стратегия привлекательна, но не рекомендуется.
3. "Пилотный проект". Это наиболее часто используемая стратегия.
"Пилотный проект" - это тактика "скачка", но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок работы.
Данный подход снижает риски и является наиболее надежным. Практически все
предприятия применяют эту тактику сегодня.
4. "Узкое место"- это малая часть технологического процесса. При
использовании похода "узкое место" план внедрения выполняется только для
"узкого места" и для людей, работающих в нем. Точность данных повышается
только для изделий в данном "узком месте"; переподготовка необходима только
для сотрудников, работающих в нем; анализ эффекта затрат делается только для
него и т.д.
В качестве стратегии внедрения системы выбрана модель пилотного
проекта.
Модель ЖЦ ИС включает в себя [21]:
1. Стадии
2. Результаты выполнения работ на каждой стадии
3. Ключевые события — точки завершения работ и принятия решений.
Стадия — часть процесса создания ИС, ограниченная определенными
временными рамками и заканчивающаяся выпуском конкретного продукта
(моделей, программных компонентов, документации), определяемого заданными
для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных
в стандарте ГОСТ Р ИСО/МЭК 12207-2010, и наоборот, один и тот же процесс
может выполняться на различных стадиях. Соотношение между процессами и
стадиями также определяется используемой моделью жизненного цикла ИС [24]
Модели жизненного цикла ИС
41
В рамках каскадной модели предполагается последовательное исполнение
всех стадий проекта в строго определенном порядке. Переход к следующему
этапу производится только при полном завершении работ на предшествующей
стадии. Проводится четкое документирование требований в форме технического
задания. Окончание каждого этапа предполагает издание полного комплекта
документов, достаточного для того, продолжения разработки другой группой
специалистов.
Понятие «жизненный цикл проекта» можно интерпретировать как период
времени от зарождения идеи проекта до его завершения, который можно
разделить на соответствующие фазы или этапы [8]:
Стадия замысла
Стадия разработки
Стадия производства
Стадия применения
Стадия поддержки применения
Стадия прекращения применения и списания
Не существует единого оптимального метода, позволяющего определить
наиболее подходящий жизненный цикл и структуру проекта. У некоторых
организаций существуют принятые принципы, согласно которым для каждого
проекта подразумевается один и тот же жизненный цикл, в то время как остальные
организации позволяют команде управления проектом самим выбирать
жизненный цикл, наиболее подходящий для проекта [26].
Модель жизненного цикла программного обеспечения - структура,
определяющая последовательность выполнения и взаимосвязи процессов,
действий и задач на протяжении жизненного цикла. Модель жизненного цикла
зависит от специфики, масштаба и сложности проекта и специфики условий, в
которых система создается и функционирует.
Модели жизненного цикла [15]:
Каскадная модель - подразумевает последовательное выполнение всех
этапов проекта в строго определенном порядке. Переход на следующий
этап выполняется только после полного завершения работ на предыдущем.