48
конфигурации с уже готовой базовой функциональностью, а также включать
готовые функциональные блоки в существующие конфигурации. Использование
БСП при разработке прикладных решений позволит также достичь большей
стандартизации конфигураций, что уменьшит время на изучение и внедрение
прикладных решений за счет их унификации по набору используемых
стандартных подсистем.
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение — комплекс технических средств,
определенных для работы ИС, а также подобающая документация на эти
средства и технологические процессы[12, стр. 45-67].
Комплексом технических средств является:
1. ПК удовлетворяющие минимальные требованиям;
2. Устройства по сбору, накоплению, обработке, передаче и выводу данных;
3. Устройства по передачи информации и линии связи;
4. Средств оргтехники и устройств автоматического съема данных;
5. Эксплуатационные материалы и др.
Документацией оформляется предварительная выборка технических
средств, использование их эксплуатации, технологический процесс обработки
информации, технологическое оснащение. Документацию возможно делить на
три группы:
1. Общесистемный, включающий государственный и отраслевой стандарт по
техническому обеспечению;
2. Специализированная, содержащая комплекс методик по всем этапам
разработки технических обеспечений;
3. Нормативно - справочная, применяемая при выполнении расчетов по
техническим обеспечениям.
В настоящее время сложилось две основные группы формирования
технического обеспечения (формы использования технических средств):
централизованного и частичного или полностью децентрализованного [23, стр.
46-89].
Централизованного технического обеспечения базируемого на
применении в информационную систему серверов.
49
Децентрализация технических средств дает возможность реализовать
функциональные подсистемы на ПК непосредственно на рабочих местах.
Перспективный подход следует считать, частично децентрализованным
подходом — применение технического обеспечения на базе распределенных
сетей, состоящей из ПК и сервера для хранения БД, общих для любых
функциональных подсистем [15, стр. 27-43].
Для решения выдвинутой задачи, необходимо наличие у специалиста
компании ПК и принтера. К компьютеру, который находится в пользовании
специалиста, предъявляются следующие возможные требования:
Корпус: InWin EMR009 450W black-silver mATX;
MB: ASUS P8H61-M LE/USB3;
Процессор: Intel Core i3-2100, S1155;
Cooler: CPU Intel S-1156/1155 BOX;
HDD: Seagate SATA 500Gb ST3500413AS;
RAM: 2GB DDR3 1333MHz Kingston PC3-10666;
Привод: DVD-RW NEC AD7260S SATA black.
Критерием выбора технических средств есть:
1. Надежная функциональная система;
2. Функционально полная система;
3. Быстродействие;
4. Минимизирование затрат на стоимость: аппаратного средства,
прикладной системы, сопровождения систем, развития систем.
50
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта состоит из четырех фаз:
1. начальная фаза;
2. фаза разработки;
3. фаза реализации;
4. фаза завершения.
Начальная фаза - это фаза разработки концепций проекта она состоит из
сбора исходных данных и анализа существующего состояния (предварительное
исследование), а также выявления потребностей в изменениях (в проекте).
Определение проекта:
постановка целей, задач и результатов в задаче автоматизации учета
нагрузки;
определение основных требований, ограничительных условий, критериев
проекта;
определение уровня рисков;
определение окружения проекта, предполагаемых участников;
расчет требуемого времени для разработки, ресурсов, средств и др.
В результате этапа формируется задача автоматизации учёта заявок,
происходит построение и оценка альтернативных вариантов решения данной
задачи, а также экспертиза и утверждение концепции задачи.
Фаза разработки проекта – это фаза, в результате которой разрабатывают
основной состав проекта, проводят подготовку к реализации. Основные
подэтапы этой фазы: выбор руководителя проекта и назначение команды
проекта: изучение целей, мотивации и требований заказчика и хозяина проекта, а
также других ключевых участников.
На этом этапе осуществляется структура планирования, в том числе
декомпозиция проекта (разбиение на более детальные блоки), составляют
календарные планы и графики работ, утверждают смету и бюджет проекта,
определяют необходимые ресурсы и методы контроля реализации проекта,
осуществляют определение и распределение рисков. На данном этапе
51
происходит организация и проведение торгов, заключение контрактов с
основными исполнителями, организуется выполнение основных проектных и
опытно-конструкторских работ по проекту и осуществляется представление
проектной разработки заказчику.
В выпускном квалификационном проекте по автоматизации учёта заявок
на этом этапе определяют основные критерии будущей системы, и формируют
требования к ней. Осуществляется проектирование и разработка основных
модулей информационной системы, создается интерфейс системы и происходит
пробное заполнение данными.
Фаза реализации – это фаза, в процессе которой происходит введение в
работу информационной системы. На этом этапе производиться введение в
действие средств коммуникации и связи между участниками проекта, введение в
действие системы стимулирования участников проекта, осуществление
детального проектирование, и определение технических спецификаций,
осуществление оперативного планирования работ.
Применительно к задаче ВКР на этом этапе проводится обучение
персонала, внедрение в технологию работы разработанной информационной
системы. Заполнение системы реальными данными и проверка ее соответствия
поставленным задачам.
Завершающая фаза или окончание проекта – это фаза, в процессе которой
достигаются поставленные цели проекта и подводятся итоги. К основным
работам этой фазы относятся - эксплуатационные испытания готового продукта,
подготовка кадров для эксплуатации системы, подготовка документации, сдача
объекта заказчику и ввод в эксплуатацию.
В данном выпускном квалификационном проекте на этой фазе происходит
обучение специалиста работе с информационной системой, составление
инструкции пользователя по основным критериям работы, пробная печать
отчетов.
Жизненный цикл программного обеспечения.
Важным понятием методологии проектирования ИС является понятие
жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это
непрерывный процесс, начинающийся с момента принятия решений о создании
52
информационной системы и заканчивающийся в момент ее полного изъятия из
эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО,
служит международный стандарт ISO/TEC 12207 (ISO -International Organization
of Standardization Международная организация по стандартизации, EEC -
International Electrotechnical Commission - Международная комиссия по
электротехнике). По нему определяется структура ЖЦ, содержащая процессы,
действия и задачи, выполняемые во время разработки ПО.
Структура ЖЦ ПО по стандарту ISO/TEC 12207 состоит из трех групп
процессов:
основные процессы ЖЦ ПО (приобретение, поставка, разработка,
эксплуатация, сопровождение);
вспомогательные процессы, обеспечивающие выполнение основных
процессов (документирование, управление конфигурацией, обеспечение
качества, верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание
инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ,
обучение).
Разработка содержит все работы для создания ПО и его компонентов
(анализ, проектирование и программирование) по заданным требованиям,
включая оформление проектной и эксплуатационной документации, подготовку
материалов, необходимых для проверки работоспособности и качества
программных продуктов, материалов, необходимых для организации обучения
персонала, и т.д.
Эксплуатация содержит работы для внедрения компонентов ПО, а также
для конфигурирования базы данных и рабочих мест пользователей, обеспечения
эксплуатационной документацией, проведения обучения персонала и т.д., ну и
непосредственно эксплуатация, в том числе локализация проблем и устранение
причин их возникновения, модификация ПО в рамках созданного регламента,
подготовка предложений для совершенствования, развития и модернизации
системы.
Модели жизненного цикла ПО.
53
Стандарт ISO/TEC 12207 не предлагает определенную модель ЖЦ и
методы для разработки ПО. Его регламенты база для всех моделей ЖЦ, для
методологии и технологии разработки. Стандарт ISO/TEC 12207 представляет
структуру процессов ЖЦ ПО, но не рассматривает в деталях, их реализацию или
выполнение действий и задач.
Модель ЖЦ – это структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ.
Модель ЖЦ зависит от назначения ИС и требований условий, в которых система
будет разрабатываться и функционировать. Наибольшее распространение имеют
две основные модели ЖЦ: каскадная модель (1970 - 1985 гг.) и спиральная
модель (1986 - 1990 гг.).
В однородных ИС приложения были единым целым. Для разработки
такого приложения применялся каскадный способ. Каскадный способ - это
деление всей разработки на этапы, при этом переход с одного этапа на другой
происходит только после завершения всех работ на предыдущем этапе.
Каждый этап заканчивается созданием комплекта документации, с
которой разработка может быть продолжена другой командой разработчиков.
Преимущества такого метода:
на всех этапах создается набор проектной документации, отвечающий
критериям полноты и согласованности;
выполняемые в логичной последовательности этапы дают возможность
планирования сроков завершения всех работ и соответствующих затрат.
Каскадный метод подходит для построения ИС, в которых с начала
разработки можно точно и полно сформировать все требования, и предоставить
разработчикам свободу реализовать их технически как можно грамотней. Сюда
входят сложные расчетные системы, системы реального времени и др.
Для избегания этих проблем была предложена спиральная модель ЖЦ, в
которой упор делается на начальные этапы ЖЦ: анализ и проектирование. На
этих этапах реализация всех технических решений проверяется путем создания
прототипов. Все витки спирали соответствует разработке своего фрагмента или
версии ПО, происходит уточнение целей и характеристик проекта, определяется
качество и планируется работа следующего витка спирали. Так, происходит
54
углубление и последовательная конкретизация деталей проекта результате
выбирается наилучший вариант, который доводится до реализации.
Главная задача разработки - как можно быстрее представить заказчикам
системы работоспособный продукт, таким образом, активизируя процесс
уточнения и дополнения требований.
Для создаваемой ИС подходит спиральная модель жизненного цикла. Эта
модель ЖЦ является более эффективной по сравнению с каскадной, что
позволяет получить в итоге более качественный продукт при небольшом
количестве задействованного персонала и довольно коротком графике
проектирования. Спиральная модель позволяет совершенствовать
информационную систему путем создания новых версий.
На стадии внедрения проводятся подготовка и постепенное освоение
разработанной проектной документации ИС заказчиком. В процессе выполнения
работ на этой стадии осуществляется выявление частных и системных
недоработок в предлагаемом для внедрения проектном решении.
Существует четыре способа внедрения новой системы:
1. Параллельная стратегия.
2. «Скачок».
3. Пилотный проект.
4. «Узкое место».
Специфика работы предприятия ООО “БЕВ” предполагает невозможность
приостановки работы предприятия из-за внедрения новой ИС, поскольку это
может повлечь за собой потерю клиентской аудитории, ошибки в выполнении
документооброта и, как следствие, упущенную прибыль. Также риск влияния
неудачного внедрения на эффективность работы предприятия должен быть
минимальным или отсутствовать.
Метод «скачка» предусматривает полный отказ от работающей системы и
моментальный и безусловный переход на новую ИС. Это может стимулировать
пользователей системы к быстрому ее освоению, однако возникает большая
вероятность остановки технологического процесса получения и обработки
информации при условии, если в новой системе возникнет сбой.
55
Метод «узкого места» является принципиально неприемлемым для
разрабатываемого проекта, так как предполагает внедрение ИС в наиболее
критический участок работы предприятия, с тем, чтобы в дальнейшем перейти к
полномасштабному внедрению на всем предприятии. Решаемая задача
изначально решается на одном участке, переход на уровень всего предприятия в
целом не запланирован.
Таким образом, наиболее приемлемыми представляются два варианта
технологии внедрения ИС – параллельная стратегия и стратегия пилотного
проекта. Их сравнительная характеристика приведена в таблице 7.
Таблица № 6
Сравнительная характеристика стратегий внедрения ИС
Позиция
Параллельная стратегия
Пилотный проект
Случай
применения
Старую работающую систему
необходимо заменить новой
Тактика «скачка», но
применяемая к ограниченному
числу функций.
Область
применения
Не имеет значения
Малый участок деятельности
Риск срыва
работы
предприятия
Риск минимальный
Стратегия нацелена на снижение
риска при внедрении
Дублирование
операций
Есть
Нет
При использовании параллельной стратегии внедрения проекта
одновременно работают старая и новая системы,
их результаты и выходные документы сравниваются. Если они согласуются
длительное время, можно переходить на новую систему. При замене одной
части программного обеспечения другой дублирование операций при внедрении
системы не будет иметь принципиального значения для выбора способа
внедрения.
Гораздо более значимым критерием при этом необходимо считать
снижение риска, сведение его практически к нулю. В этой связи наиболее
приемлемой представляется стратегия параллельного внедрения.
56
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
При создании любого проекта постоянно появляются ситуации, связанные
с неопределенностью, неполнотой или неточностью информации об условиях
проектирования проекта и связанные с ними затраты и результаты. Участники
проекта заинтересованы в уменьшении возможности срыва проекта из-за таких
неопределенных ситуаций. Для снижения потери от возможных просчетов и
избегания срыва проекта, методологии управления проектами содержат
специальные процедуры, которые помогают учесть факторы неопределенности и
риска на этапах проекта.
Предугадывая виды и значения рисков, возможно на них влиять, тем
самым уменьшая их плохое влияние на эффективность проекта. Так, появляются
реальные возможности управлять ими. Факторы риска и неопределенности
которые подвергаются учету в расчетах эффективности, когда при разных
возможных условиях реализации затраты и результаты по проекту различны.
Этап подготовки проекта.
1. Риск сотрудников.
Риски:
Привлечение неопытных сотрудников к выполнению проекта;
Вхождение в состав разработчиков «случайных» сотрудников, а не
основных участников автоматизируемых бизнес процессов;
Отсутствие общей стратегии автоматизации;
Отсутствие общей цели и задачи проекта;
Отсутствие мотивирования сотрудников;
Негативное отношение сотрудников к проекту;
Непродуманный план ведения работ.
Способы устранения рисков:
Полное взаимодействие с руководством в ходе проекта и своевременное
принятие решений;
Участие в проекте лучших специалистов и профессиональных
консультантов;
Грамотно сформулированные цели проекта;
Проработка основной стратегии автоматизации организации;
57
Постоянный состав рабочей группы в течение всего проекта.
2. Риски ведения проекта.
Риски:
Неверное определение границ и масштаба проекта;
Проектирование функций системы с ошибками;
Выбор неверных технологий и методов решений задач;
Не соблюдение требований заказчика.
Способы предотвращения:
Обеспечение четких границ проекта, которые определяются на начальном
этапе и остаются неизменными вплоть до окончания проекта;
Качественное планирование выполнения работ;
Обеспечение проекта нужными ресурсами;
Утверждение и согласование проектных решений;
Установка высокого порога принятия изменений.
3. Риски неверного планирования.
Риски:
Непродуманный организационный план внедрения системы;
Срывы сроков выполнения работ на каждом этапе.
Способы предотвращения:
На ранних стадиях проекта проведение проверок, организация командной
работы, распределение ролей и стимулирование сотрудников;
Документирование всех работ и обеспечение доступа к данным по
работам всем участникам проекта.
Этап разработки.
4. Риски персонала.
Риски:
Увольнение основных сотрудников, ответственных за проведение
разработки;
Недопонимание между разработчиками проекта из-за отсутствия
налаженной системы коммуникации;
Неверное представление задачи проектирования;
Выбор программистов без опыта работы с подобными системами.