55
прототипов. Каждый виток спирали соответствует образованию фрагмента
или версии ПО, где уточняются цели и свойства проекта, определяется его
качество и планируются работы дальнейших витков спирали.
Соответственно, углубляются и постепенно конкретизируются детали проекта
и в итоге определяется аргументированный вариант, доводящийся до
реализации.
Разработка итерациями отражает объективно присутствующий
спиральный цикл создания системы. Неполное окончание работ на каждой
стадии дает возможность переходить на следующий этап, не дожидаясь
полного окончания работы на текущем. Здесь недостающую работу можно
реализовать на дальнейшей итерации. Основным преимуществом
итерационной модели является возможность выпуска системы в продуктивную
среду до финальной версии. В данной модели разработка ведется частями, т.е.
итерациями. Владельцем бизнеса (в основном заказчиком системы)
устанавливаются пулы (перечень) приоритетных требований к системе в данное
время. Итерация обычно длится две-четыре недели. В процессе итерации
проводят разработку на языке программирования и затем тестируют
разработанный функционал. И данный функционал включают в релизную
версию системы и обновляют продуктивную среду на новую версию.
Ключевая проблема спирального цикла - установление момента
перехода на другой этап. Для ее устранения нужно ввести временные
ограничения на каждый этап жизненного цикла [9, c.45]. Переход
реализуется по плану, даже если не вся необходимая работа завершена. План
проектируется на базе статистических сведений, полученных в предыдущих
проектах, а также личного опыта разработчиков. На рисунке 2.3 отражено
графическое изображение спиральной модели жизненного цикла ИС.
56
Рисунок 2.3 - Спиральная модель ЖЦ ИС
Самой оптимальной является спиральная модель, поскольку в ней
устранены все упущения остальных моделей. В разрезе доработки текущей ИС
нередко бывают новые замечания от пользователей, которые можно учесть на
новом витке спиральной модели.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Сам стандарт MSF предоставляет определенную гарантию минимизации
рисков, поскольку весь жизненный цикл проекта разбит на стадии, где
присутствуют роли, за которыми зафиксированы цели, которые необходимо
реализовать. Но, так или иначе, на каждой фазе есть определенные риски.
В фазе выработки концепции могут образоваться такие риски, как:
- недальновидный анализ сроков проекта и бюджета. Для устранения
подобного риска нужно подробно и тщательно исследовать цели и задачи
проекта, устанавливать больше контрольных точек;
- неверно подобранный проектный состав исполнителей может
отрицательно повлиять на командную работу. Этот риск можно уменьшить
57
путем тщательного подбора специалистов в проектную группу (например,
тестированием не только профессиональных, но и личностных качеств).
Риски на фазе планирования:
- ошибочно созданная архитектура определяемого решения. Вероятность
образования такого риска находится в зависимости от компетенции
руководителя проекта, который должен принимать решение об определении
архитектуры разрабатываемого решения [20, c.15].
Риски на фазе разработки:
- неверное понимание технического задания, и, как результат, неверное
программирование архитектуры и сдвиг сроков выполнения задания.
Уменьшить эти риски можно с помощью более подробного написания
технического задания, которое программист сможет понять;
- отсутствие необходимой квалификации у программиста на том языке, на
котором нужно выполнить программу клиенту, которая будет распределять
заказы по менеджерам. В той ситуации, если программист не будет успевать
сделать программу целиком, есть возможность воспользоваться услугами
внешнего разработчика, т.к. «фриланс» или «аутсорсинг».
Риски на фазе тестирования:
- риски неоконченного тестирования. Бывает такое, что программный
продукт не до конца протестирован. Риск уменьшается с помощью повторного
тестирования на следующей итерации проектирования.
Риски на фазе внедрения:
- риски ошибочного принятия решения о законченности фрагмента
проекта. Образование таких рисков влечет за собой проблему незаконченности
решения и вероятность образования несостыковок с другими компонентами
проектируемой ИС. Проблему можно устранить с помощью доработки при
дальнейшей итерации [28, c.131].
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
58
Правовой компонент системы организации защиты информации (СЗИ) в
операторе мобильной связи «Билайн» базируется на нормах информационного
права и имеет юридическое закрепление взаимоотношений компании и
государства по поводу правомерности применения СЗИ, компании и штата
сотрудников по поводу обязанности сотрудников соблюдать определенные
меры защитного характера, ответственности сотрудников за нарушение порядка
защиты данных. Данный компонент включает:
- присутствие в организационных документах компании, правилах
внутреннего трудового распорядка, трудовых договорах, в должностных
инструкциях положений и обязательств по защите конфиденциальной
информации;
- разъяснение лицам, принимаемым на трудоустройство, положения о
добровольности принимаемых ими на себя ограничений, связанных с
выполнением обязанностей по защите информации [45].
Ключевыми подсистемами защиты информации в правовом плане
являются:
- закрепление на объекте режима конфиденциальности;
- разграничение доступа к данных;
- правовое обеспечение процесса защиты данных;
- идентификация конфиденциальной информации как ключевого объекта
защиты. Базируясь на государственных правовых актах на уровне «Билайн»,
создаются свои нормативно-правовые документы, направленные на реализацию
информационной безопасности.
Инженерно-технический компонент защиты данных необходим для
пассивного и активного противодействия средствам технической разведки и
формирования рубежей охраны территории с помощью комплексов технических
средств. Организация охраны - компонент общей системы защиты
конфиденциальной информации фирмы [23, c.51] Вопросы обеспечения
надежной охраны территории компании и его объектов прямым образом
59
связаны с задачами организации пропускного режима в компании. Силы и
средства, принимающие участие в выполнении данных задач, являются
компонентами системы охраны предприятия. От качества ее работы находятся
в зависимости возможность и уровень выполнения задач пропускного и
внутриобъектового режимов. Системы таких режимов формируют следующие
после системы охраны рубежи безопасности, предотвращающие доступ
злоумышленника к охраняемой фирмой сведениям.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
В CRM-системе все клиенты подлежат учету. Каждая «зацепка» («лид») в
системе, которая потом может привести к продаже, фиксируется. Таким «лидом»
может быть «холодный» звонок от клиента, e-mail сообщение, посещение офиса
и т.д. Ключевая задачи менеджера по продажам - определить, кто это и что
нужно этому потенциальному клиенту. Когда данные о клиенте заполняются,
«лид» превращается в контакт и фирму (если клиент представляет юридическое
лицо), а далее в сделку (когда, вероятно, произойдет продажа).
Работа по такой схеме (от «лида» к контакту и к сделке) в CRM-системе
«Битрикс 24» дает возможность максимально «дожать» все потенциальные
зацепки и понять факт того, насколько эффективно работает отдел сбыта [19,
c.43].
60
Рисунок 2.4 – «Лиды» в CRM-системе «Битрикс 24»
Внедрение такого типа системы в операторе мобильной связи «Билайн»
просто необходимо. Сотрудники ведут учет в бумажном виде, что может
привести к потере клиентов. Да и руководителю будет понятнее, какой курс для
фирмы выбирать дальше.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Основу ИС, нужной для управления внешним и внутренним процессом
информационной деятельности «Билайн», составляет динамическая модель
движения данных на управляемом уровне компании, проектируемая на базе
информационных потоков от пунктов зарождения информации в центральную
БД.
Исследование графов движения документов дает возможность увидеть
пути движения документов. Определяя узлы, где соединяются похожие
информационные потоки, есть возможность установить число типов рабочих
мест, которые нужно разработать, что дает возможность начать проектирование
61
технико-экономического обоснования, технического проекта сети, проекта
разработки ПО для субъектов информационного обмена.
На разработку ИС фирмы в настоящее время оказывает воздействие не
только уровень организации формы управления и средств ТО, но и
современные подходы к самой идее проектирования [22, c.41].
Рисунок 2.5 – Декомпозиция проекта внедрения ИС
Создание проектной команды является ответственной стадией в ходе
осуществления проекта. При создании проектной команды нужно принимать во
внимание личностные и психологические качества участников проекта, а также
руководствоваться критериями подбора участников проекта [11, c.234].
2.2.3. Характеристика результатной информации
В данном разделе необходимо описать таблицы или файлы с указанием
полей, образованных при реализации запросов. В данном случае необходимо
также указать на основе каких таблиц с переменной или условно-постоянной
информацией БД были получены таблицы с результатной информацией, и какой
документ получается в результате. Затем нужно привести ключевые параметры
каждой таблицы с указанием, подлежит ли она последующему хранению или нет
[21, c.44].
62
Характеристика результатных документов является ключевым пунктом
всей проектной части и представляет собой обзор результатов выполнения
определенных в аналитической части задач с точки зрения предметной
технологии. Если решение представляет собой формирование ведомостей (в
экранных или печатных формах), каждую ведомость нужно описать отдельно (в
приложении целесообразно указать заполненные экземпляры ведомостей и
экранных форм документов).
Так, нужно указать, какое место занимает ведомость в информационных
потоках компании (служит для оперативного управления или для отчетности,
является уточняющей или обобщающей и пр.).
Каждая ведомость должна приводить к определенному результату, не
иметь лишней информации, быть универсальной. Затем осуществляется
описание печатных форм, экранных макетов с перечислением и краткой
характеристикой имеющихся показателей для каждого документа. Также
говорится о том, на основе каких таблиц строится данный документ.
В том случае, когда результатная информация выражена не в форме
ведомостей (например, при разработке подсистемы распределенной обработки
информации), нужно всесторонне описать структуру сообщения и его
последующий путь, базируясь на текущей организации многопользовательской
ИС.
Для конечных файлов описывается:
- их структура и реквизитный состав;
- частота их формирования;
- на основе каких таблиц они строятся;
- каким путем они доходят до ИС – получателя файла.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
63
На каждую точку продаж в ПК и смартфон будет загружено приложение.
Теперь каждый сотрудник будет иметь доступ к базе клиентов, сможет
отслеживать входящие, пропущенные звонки, количество продаж и т.д.
Руководитель же, в свою очередь, сможет увидеть эффективность работы каждой
торговой точки и каждого сотрудника. Отчеты доступны в разрезе по сделкам,
«лидам», контактам, компаниям, счетам и предложениям.
64
Рисунок 2.6 – Аналитика в CRM «Битрикс 24»
Специальный сводный отчет состоит из ключевых отчетов по каждому
разделу CRM. Для оперативного получения сведений и оценки ситуации в
разделе CRM можно переключить представление - с обычного списка данных на
страницу с аналитическими отчетами [26, c.77].
Важнейший отчет в CRM – это воронка продаж. Она формируется онлайн,
подобно остальным отчетам. Ее этапы - это сделки на разных стадиях.
Формирование воронки продаж базируется на сведениях о том, какой процент
сделок завершен, какие находятся в работе.