45
• Деление объемных работ в рамках реализации проекта на
относительно малые части;
• Последовательная реализации базовых функций с максимальным
уровнем риска, что поможет при желании стазу завершить работы над проектом
на начальной стадии и уменьшить расходы;
• Актуальность гибкого проектирования, основанная на
преимуществах каскадной модели при параллельной реализации итераций;
• Использование сильных сторон инкрементной модели (передача
инкрементов, минимизация графика работ, повышение стабильности ресурсов
при росте системы);
• Частая связь с пользователем на стартовых этапах модели, что
помогает создать требуемый продукт хорошего качества;
• Возможность оценивания системы пользователем на стартовых
этапах, благодаря использованию ЖЦ реализации оперативного
прототипирования;
• Участие пользователей в процессах планирования, изучения рисков,
разработки, внедрении, оценивании;
• Улучшение административного контроля процессами материальных
и денежных затрат, контроль кадров и графика работ, что обычно реализуется
проведением анализа по итогу любой итерации;
• Повышение результативности благодаря использованию
подходящих для повторного использования итогов;
• Повышение возможности угадывания поведения системы из-за
уточнения описанных ранее целей;
• Выполнение оценки общих затрат, что ведет к их коллективной
минимизации.
Негативные моменты спиральной модели ЖЦ:
• Высокая стоимость модели из-за сторонних затрат времени на
планирование, определение целей, составление анализа рисков и построение
прототипа при выполнении цикла по спирали;
46
• Большая стоимость модели для проектов, имеющих минимальные
риски или малые размеры;
• Сложность модельной структуры, ведущая к усложнению ее
использования заказчиками, разработчиками и менеджерами;
• Требование специализированных знаний для проведения оценки
рисков;
• Изменение сроков завершения работ над проектом из-за пожеланий
заказчика изменять любую созданную версию;
• Четкая поставка работ между разработчиками;
• Сложность определения параметров для выполнения процесса
реализации на дальнейшей итерации;
• Применение лишь мощных средств и методов прототипирования.
Проект создания ИС анализа конкурентоспособности товара, как и все
остальные проекты по созданию ПО, включает множество неопределенных
моментов, которые могут повлечь за собой риски срыва реализации проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо значительно
уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
Модно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот косвенные
риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
47
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений, точно
ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее, выгода,
полученная от осуществления проекта больше, чем затраты на него, что случится,
если ключевые поставщики в силах будут выполнить свои обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии правильного
завершения проекта, требования понятны и стабильны, область действия четко
фиксирована или будет расширяться в будущем и т.п.);
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В данном проекте можно выделить следующие основные риски на каждом
этапе жизненного цикла (таблица 2.1).
48
Таблица 0.8
Основные риски на этапах жизненного цикла информационной системы
Этап
Риск
Мероприятия
Проектирование
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов
решения поставленных задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта,
определенных на начальном
этапе, вплоть до окончания
проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
Недостаточно опыта у
персонала заказчика,
который будет
эксплуатировать систему
Предоставить заказчику
услуги собственного
специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность
действий персонала
исполнителя и сотрудников
предметных областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана
внедрения ИС
Кроме того, в процессе эксплуатации и сопровождения разработанной ИС
могут возникнуть:
• технические риски;
• риски персонала.
49
Причинами технических рисков становятся:
• Использование вредоносных программ (логические бомбы, вирусы,
трояны, черви, шифровальщики), активированные в корыстных целях внутри
найденных ошибок (дыр) в ПО,
• Перехват данных по сетям связи, воровство данных;
• Неправильная эксплуатация оборудования;
• Проблемы в работе третьего лица (к примеру, провайдера Интернет
услуг), что влечет за собой недоступность передачи отчетов из филиалов и
контроля работы филиалов;
• Расхождение функциональных возможностей системы текущим
бизнес-процессам в комплекс задач ввиду проведенных реорганизационных
изменений.
Минимизировать данные обстоятельства можно, соблюдая некоторые
моменты:
• Подробное тестирование и выявление ошибок на этапе создания
проекта;
• Устранение всех недочетов и ошибок в минимальные сроки силами
прошедших подготовку на этапе внедрения технических специалистов;
• Сам администратор сети обязан следить за безопасностью данных,
применять и вовремя обновлять антивирусное ПО, грамотно настроить FireWall,
разделяющий локальную и внешнюю сеть, давать работникам компании
возможность работы только с той информацией, которая им нужна для
реализации своих служебных обязанностей;
• Разделение клиентского и серверного оборудования, а также
привлечение обученного работе с системой опытного персонала;
• Доступность альтернативных средств выхода в Интернет или
наличие других способов отправки информации;
• Запись и фиксирование всех технических условий и их утверждение
со всеми основными участниками проекта;
• Обязательное утверждение проведенных изменений.
50
Факторами реализации риска персонала становится такие обстоятельства,
как:
• Нарушение режима ИБ – есть вариант утечки данных из-за
злоумышленных действий сотрудников и не желании взаимодействовать с новой
системой;
• Не отражен этап выхода их проекта представителей заказчика.
В противовес этому выступает:
• Реализация системы поощрений персонала заказчика,
применяющего систему;
• Прием на работу сотрудников при условии сохранения
коммерческой тайны, в противном случае – использование штрафных или иных
санкций;
• Грамотное планирование сроков проекта и момента завершения
работы над проектом со стороны исполнителя.
2.2 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
Информационная модель представлена на рисунке 2.1.
51
ИС
Спр Статус заявки
Спр Статус
заявки*
Спр Пользователь
Т Заявка
Т Услуги в заявке*
Спр Услуга
Т Услуги в заявке
Т Заявка*
Учет
клиентов
Учет
сотрудников
Список
сотрудников
Учет типов
пользовател
ей
Список услуг
Учет заказа
Сотрудник
Сотрудник
Список
клиентов
Учет услуг
список
клиентов
список
договоров
Отчет Заявка
Отчет Заявка
Отчет Договор
Отчет
Договор
Спр
Пользователь*
Спр Тип
пользователя*
Спр Тип
пользователя
Спр Услуга*
Список типов
пользователей
Журнал учета
заявок
Журнал
учета заявок
Прайс-лист
Прайс-лист
Отчет по
работе
менеджеров
список
пользовател
ей
Рисунок 0.9 Информационная модель системы
Информационная модель включает в себя три области – область 1, в
которой происходит заполнение справочников, область 2, в которой показана, как
осуществляется учет выданных книг, и область 3, где указано, каким образом
осуществляется получение выходных документов.
Пользователь системы на основании имеющихся документов вводит
данные в справочники системы, тем самым подготавливая ее к работе. После
этого происходит учет клиентов и заказов, на основании чего формируются
выходные документы, перечисленные на модели, исключительно в электронной
форме.
Справочники не предоставляются уже наполненными, поэтому требуется
их предварительная настройка. Кроме того, в процессе эксплуатации, может
возникнуть потребность корректировки справочных значений или добавление
новых. Перечень используемых справочников приведен в таблице 2.3.
52
Таблица 0.9
Перечень используемых справочников
Название
справочника
Ответственный
за ведение
Средний
объём
справочника
в записях
Средняя
частота
актуализации
Средний
объем
актуализации,
%
Пользователь
Администратор
5
1 раз в год
10
Статус заявки
Администратор
100
1 раз в год
20
Тип
пользователя
Администратор
50
1 раз в год
20
Услуга
Администратор
50
1 раз в год
20
Реквизитный состав справочников приведен в Таблице 2.4.
Таблица 0.10
Реквизитный состав справочников
Наименование
Перечень реквизитов
Тип пользователя
• Название;
• Права.
Статус заявки
• Название статуса
Услуга
• Название услуги;
• Описание услуги;
• Стоимость.
Пользователи
• фамилия;
• имя;
• отчество;
• статус в системе;
• пароль;
• логин;
• дата регистрации.
В системе используются следующие входные документы:
• сведения о пользователях, поступающие от инспектора по кадрам
компании;
• заявки, поступающие от клиентов;
• Сведения о клиентах;
• Список услуг, поступающий от директора компании..
Список пользователей содержит следующие сведения о пользователях
системы:
• фамилия;
• имя;
53
• отчество;
• должность.
На основании данного документа формируется содержимое справочника
Пользователи.
При учете услуги используются такие реквизиты, как ее описание и
стоимость.
При учете заявок учитываются данные клиента, данные объекта охраны,
оказываемые услуги, документы.
В качестве выходных в разработанной системе учета работы с клиентами
формируются следующие документы:
• список пользователей – содержит перечень пользователей;
• список клиентов – содержит перечень клиентов;
• список договоров– содержит перечень договоров;
• Отчет Заявка;
• Отчет Договор;
• Журнал учета заявок;
• Прайс-лист;
• Отчет по работе менеджеров.
Отчет Заявка содержит следующие реквизиты:
• Код заявки
• Дата регистрации
• Договор (Дата)
• Договор (Номер)
• Клиент
• Название объекта
• Адрес объекта
• Описание объекта
• Дата отправки последнего Email сообщения
• Количество отправленных Email сообщений
• Стоимость, руб.
• Зарегистрировал
54
• Зарегистрированные документы
• Услуги
• Общая стоимость услуг.
Отчет Договор содержит все сведения по заключаемому договору, в том
числе наименование клиента, предмет договора, стоимость, продолжительность.
Журнал учета заявок содержит:
• Код заявки
• Дата регистрации
• Договор (Дата)
• Договор (Номер)
• Клиент
• Название объекта
• Адрес объекта
• Стоимость, руб.
• Зарегистрировал
Прайс-лист содержит наименование услуги, ее описание и стоимость.
Отчет по работе менеджеров содержит:
• Фамилия, Имя, Отчество менеджера;
• Телефон
• Зарегистрировал(а);
• Количество Клиентов;
• Количество Заявок;
• Количество Документов;
• Количество Услуг;
• Сумма заявок, руб.
2.3 Программное обеспечение задачи
Основная функция разрабатываемой информационной системы – это учет
заявок клиентов. Однако для ее реализации необходимо наличие других,
второстепенных функций, которые позволяют полноценно функционировать