58
Рисунок 27. График проекта
Следование представленным стадиям, позволит создать качественный,
функциональный программный продукт.
При разработке конфигурации стратегия внедрения будет
параллельной. По мере разработки, готовое решение будет внедрено на
предприятии, но некоторые операции будут выполнять в бумажном виде. Это
будет осуществляться до полного освоения функций разработанной
конфигурации, крайний термин переход на новую систему две недели.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На этапе инициализации необходимо определить перечень рисков. Под
риском следует понимать неопределенное событие или условие, наступление
которого отрицательно или положительно сказывается на целях проекта. На
начальном этапе, когда нет необходимых данных для проведения детального
анализа, часто ограничиваются качественной оценкой общего уровня рисков:
низкий, средний, высокий [17].
59
Риски, которые могут повлиять на проект по автоматизации расчетов с
поставщиками и подрядчиками компании ООО «Лидердор» являются
следующими:
– экономические риски – возможное изменение курса валют скажется
на общей стоимости проекта, приведет к перерасходу средств, связано с тем,
что цены на компьютерную технику связаны с курсом доллара;
– риск неполучения ожидаемой прибыли. Связано с тем, что на
данный момент те процессы, которые должны быть автоматизированы,
учитываются в другой информационной системе, и есть риск не
использования разрабатываемого решения;
– административный риск – необходимо заручиться поддержкой
руководства предприятия, на внедрение разрабатываемого решения по
автоматизации взаимодействия с клиентами, интерес директора будет
способствовать снижению риска и более благоприятно сказываться на
степени заинтересованности подчиненного персонала (менеджеров,
операторов);
– риск не выполнения запланированных работ по организационным
или иным причинам – возможно возникновение задержки непосредственно
во время самой разработки проекта, это связано с тем, что некоторые работы
попадают на праздничные дни, в связи, с чем возможно увеличение срока
разработки проекта, также существует вероятность заболевания одного или
группы исполнителей, что может привести к нарушению графика
выполнения работ.
Ответственные за управление рисками:
– руководитель проекта – управляет тремя видами риска –
административным – проводит консультации с руководством ООО
«Лидердор», с целью уменьшения негативного влияние на принятие системы.
Риск неполучения планируемой прибыли – продвигает продукт по большому
количеству клиентов, заключает контракты на внедрение не только с данной
компанией, но и с другими торгово-производительными фирмами. Риск не
60
выполнения запланированных работ в срок – постоянный мониторинг
выполнения этапов работы, анализ критических точек, коррекция плана,
привлечение других исполнителей.
– проектировщик – управляет риском не выполнения
запланированных работ в срок, путем контроля за закрепленными за ним
этапами;
– заказчик – влияет на административный риск – путем организации
собраний с коллективом для разъяснения пользы внедрения системы,
способствовать эксплуатации системы, с целью выявления и быстрого
исправления недостатков;
– программист – управляет риском не выполнения запланированных
работ в срок, путем контроля за закрепленными за ним этапами.
Риски, которые наиболее влияют на проект: наиболее потенциальным
влиянием на автоматизацию расчетов с поставщиками и подрядчиками
компании ООО «Лидердор» является риск не выполнения запланированных
работ по организационным или иным причинам.
Представим дерево решений для данного типа риска (см. рис.28).
Создание
проекта
разработчиками
Поломка
компьютерной
техники
Не выполнение
сотрудниками
плана
Техника старая
Давно проходила
плановый ремонт
Были перебои с
электричеством
Техника не выйдет
из строя,
вероятность
больше 0,75
новая нетда
Техника не выйдет
из строя,
вероятность
больше 0,5, но
меньше 0,75
Ремонт проведен в срок
Высокая
вероятность
поломки техники,
вероятность
поломки больше
0,75
Ремонт не производился
Поломка техники
имеет вероятность
от 0,5 до 0.75
да
Сотрудник
отличался ранее
недобросовестным
отношением
Сотрудник не
выполнит в срок
проект с
вероятностью
больше 0,75
да
В районе
свирепствует
эпидемия
Сотрудник не
выполнит проект в
срок с
вероятностью от
0.5 до 0,75
да
Сотрудник
выполнит проект в
срок с
вероятностью
больше 0,75
нет
нет
Рисунок 28. Дерево решений по риску не выполнения
запланированных работ по организационным или иным
причинам
61
Планирование реагирования на риски. Руководитель проекта должен
реагировать следующим образом:
– на административные риски следующим образом – усилить
консультации с высшим руководством;
– на риск не выполнения запланированных работ по организационным
или иным причинам – найти более квалифицированных и
дисциплинированных исполнителей, купить новую технику или
отремонтировать имеющуюся в расположении;
– на риск неполучения ожидаемой прибыли, предусмотреть
реализацию системы для разных компаний.
Мониторинг и контроль рисков будет производиться путем
предоставления в виде документов следующих явлений:
– проведенных консультационных занятий с персоналом
предприятия;
– количество обнаруженных ошибок при эксплуатации системы;
– выделения новых ресурсов;
– невозможности внедрения системы из-за устаревшего оборудования
заказчика.
Ранее были представлены стадии и этапы проекта автоматизации
расчетов с поставщиками и подрядчиками. Определим риски на каждом
этапе жизненного цикла.
Стадия 1. Определение требований к разработке системы, на данной
стадии возможны следующие риски:
– риск несогласованности – возможно, что требования, которые
формулирует заказчик, не учтены в полной мере разработчиком,
реагирование на данный риск, уточнение и дальнейшее согласование
требований;
– риск не понимания – возможно, что заказчик и разработчик говорят
об одном и том, же, однако их формулировки значительно разнятся, что
может привести к неоднозначности интерпретации требований. Реагирование
62
на данный риск, уточнение, упрощение формулировок, переход к
стандартным определениям, которые не допускают двузначности;
Стадия 2. Разработка технического задания может содержать
следующие риски:
– некорректно составленное техническое задание – может привести к
тому, что разработчик выполнит не совсем тот функционал информационной
системы, который ожидает заказчик. Реагирование на данный вид риска
будет следующий – привлечение сторонних экспертов, которые позволяет
разъяснить заказчику пункты технического задания или самому
скорректировать структуру данного документа;
Стадия 3. Проектирование структуры системы может содержать
следующие риски:
– непонятность составленных моделей, описаний проектных решений,
алгоритмов, по которым работает информационная система. Реагирование на
данный риск следующий – построение моделей с помощью CASE средств,
использование ГОСТа при обозначении основных узлов;
– проект может иметь необоснованные данные или сроки.
Реагирование на данный вид риска сводится к тому, что при формировании
проекта помимо проектировщика должен принимать участие и программист;
Стадия 4. Написание программного кода может содержать следующие
риски:
– не выполнение в установленный срок. Реагирование на данный вид
риска – адекватное распределение между программистами задания,
привлечение в случае необходимости сторонних исполнителей;
Стадия 5. Отладка компонентов имеет следующий вид риска:
– не нахождения ошибок. Реагирование на данный вид риска –
привлечение сторонних тестировщиков, которые имеют опыт по
тестированию программного обеспечения;
Стадия 6. Ввод в действие имеет следующий вид риска:
63
– отсутствие возможности установки ИС на оборудование заказчика.
Реагирование на данный риск следующий – доработка информационной
системы, закупка новой компьютерной техники;
– персонал заказчика не принимает информационную систему.
Реагирование на данный вид риска сводится к тому, что проводится обучение
и инструктаж по работе с системой автоматизации, привлекаются
административные лица для стимуляции персонал [16,21].
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Для формирования прав доступа необходимо определить
пользователей разрабатываемой системы и функции, которые на них
возлагаются. Представим пользователей и их функции по отношению к
разрабатываемой системе автоматизации взаимодействия с клиентами.
Основными процессами, в которых осуществляется взаимодействие с
поставщиками и подрядчиками, являются:
- закупка и последующая поставка оборудования и материалов;
- выполнение определенных видов работ подрядчиками;
- выполнение взаиморасчетов.
Представим функции основных действующих лиц, которые будут
иметь право доступа к системе.
1. Менеджер выполняет следующие функции, которые должны быть
учтены при автоматизации взаимоотношений с поставщиками:
– определяет потребность в имеющихся запасах материалов и сырья;
– формирует заказ у поставщика номенклатурных групп с указанием
наименования, количества, закупочной стоимости;
– принимает прибывшую номенклатуру от поставщика, определяет
соответствие заказа и доставки, оформляет документацию. Которая является
основанием для выполнения оплаты поставщику.
64
Руководитель производственного участка выполняет функции, по
приему подрядчиков для выполнения определенного вида работ, анализа и
контролю выполнение задач, поставленных перед подрядчиками. Действия
руководителя следующие:
– определить виды работ;
– формирование акта работ с указанием содержимого задачи, данных
подрядчика, сроком завершения работы, необходимым материалом и
комплектующих, стоимостью предоставляемых услуг и материалов.
– проверяет выполнение акта работ и может отправить задание на
доработку или подтвердить выполнение;
– формирует отчетность по выполненным работам, затраченным
материалам и выплаченным денежным средствам.
Для наглядности представим с помощью диаграмм вариантов
использования, роли основных действующих лиц.
Диаграмма вариантов использования играет наиболее важную роль в
процессе проектирования системы; диаграмма описывает функциональные
требования, которым должна соответствовать система, и среду, в которой она
находится. Эта диаграмма представляет собой совокупность сервисных
функций, которые выполняет система. В дополнение к спецификации, эта
диаграмма позволяет идентифицировать функциональность, проверять
прогресс в моделировании и реализации, а также поддерживает
взаимодействие между участниками проекта.
На рисунке 29 представлена диаграмма вариантов использования
взаимодействия менеджера с поставщиками.
65
Определить
остатки запасов
Сформировать
заказ материала
и оборудования
Сравнить заказ и
доставку
Принять
доставленный
заказ
Менеджер
Выполнить заказ
Основание
для оплаты
Сформировать
приходную
накладную
Поставщики
Косвенно
влияют на
систему
Рисунок 29. Диаграмма вариантов использования для
действующего лица «Менеджер»
На рисунке 30 представлена диаграмма вариантов использования для
действующего лица «Руководитель производственного участка», на данной
диаграмме также отображено взаимодействие с подрядчиками.
66
Сотрудничать с
подрядчиками
Сформировать
акт работ
Контролировать
выполнение
работ
Принять
выполненную
работу
Руководитель
Указать
используемые
материалы
Указать виды
работ
Определить
общую стоимость
Принять акт,
передать в
бухгалтерию
Основание
для оплаты
Рисунок 30. Диаграмма вариантов использования для
действующего лица «Руководитель»
Представленные диаграммы позволяют определить роли. В
соответствии с этим сформируем таблицу доступа к ресурсам
разрабатываемой системы учета обращений (см. таб. 3).
Таблица 3
Данные доступа к ресурсам системы
Группы
пользова-
телей
Справочни
-ки
системы
Документ
ы
системы
Отчеты
системы
Журналы
документов
Доступ в
Internet
Менеджер
Чтение/созд
ание
Чтение/соз
дание
Нет
доступа
Нет доступа
Ограничен
Руководите
ль
Чтение/созд
ание/удале
ние
Чтение/соз
дание
Формиров
ание
Чтение/Доба
вление
записи/Удале
ние записи
Не ограничен
67
Администр
атор
системы
Чтение/созд
ание/удале
ние
Чтение/соз
дание/
удаление
Изменени
е
параметро
в
Полный
Не ограничен
В дальнейшем данные из представленной таблицы будут
использоваться при создании ролей пользователей системы.
2.2 Информационное обеспечение задачи
2.2.1 Характеристика нормативно-справочной, входной и
оперативной информации
Представим информационную модель разрабатываемой системы
автоматизации расчетов с поставщиками и подрядчиками компании ООО
«Лидердор» (рис.31).
Определены следующие логические уровни модели:
1) источники информации – справочник «Клиенты», клиент,
пользователь системы;
2) первичные документы или файлы:
– документ «Заявка»;
– документ «Приходная накладная»;
– документ «Договор».
3) таблицы с первичными документами – реестр заявок;
4) таблицы с результатной информацией – справочники «Клиенты»,
«Техника и материалы (Номенклатура)», «Места хранения», «Услуги»;
5) результатные документы или файлы:
– документ «Акт работ»;
– документ «Поставка товара клиенту»;
– отчет «Остатки техники»;
– отчет «Данные по заявкам»;
– отчет «Данные по прибыли от услуг»;
– отчет «Данные по прибыли от сотрудников».
6) получателями информации:
– менеджер;
– руководитель производственного участка.