84
заключается в том, что данные чаще всего необходимо собирать в то время, пока
приложение находится в фоновом режиме. За счет особенностей системы iOS
такой функционал стандартными средствами невозможно решить, из-за чего
приходится прибегать к определенным уловкам, благодаря чему приложение
регулярно входит в активный режим и собирает геоданные пользователя.
Для отладки ошибок приложения зачастую недостаточно встроенных
средств аналитики, которые отправляют диагностику на сервер. Необходимо иметь
возможность собрать журнал активности в приложении локально, либо иметь
доступ к «тонким» системным настройкам. Кроме того, иногда для отладки
ошибки требуется просмотреть журнал сетевых запросов или ошибок соединения.
Предусмотрена возможность отправки содержимого журнала запросов и ошибок
внутри приложения в чат или в другое приложение. Для этого перед отправкой
формируется текстовый файл лога и открывается контроллер определения пункта
отправки файла. Далее пользователь решает, куда хочет отправить файл.
На рисунке 18 представлена структурная схема программного продукта.
Вызов всех модулей осуществляется с помощью главного меню приложения,
а также с основного экрана, который открывается после успешной авторизации
пользователя.
2.4.2 Описание программных модулей
На рисунке 19 представлена блок-схема учета клиентов.
При учете клиентов используются необходимые реквизиты, в том числе
наименование и контактные данные клиентов.
85
Рисунок 18. Структурная схема вызова программных модулей
Рисунок 19. Блок-схема учета клиентов
2.5 Апробация результатов исследования
Для приведенных модулей был разработан пользовательский интерфейс и
реализована логика взаимодействия. Далее описаны экранные формы для всех
модулей.
86
Для создания задачи необходимо определить блок основных параметров и
дополнительных. Основные параметры присутствуют во всех категориях, тогда как
ДП для каждой категории может варьировать.
Экранная форма создания задачи приведена на рисунке 20.
Рисунок 20. Форма создания задачи
Среди основных параметров задачи можно перечислить категорию (в
зависимости от категории будет меняться форма постановки задачи, так как будут
варьировать ДП), текст задачи, комментарий при постановке, срок исполнения
задачи, список прикрепленных файлов и исполнители.
В качестве ДП в категории iOS Backlog будут указаны iOS Проект и
Недельный спринт, где первый является списком с одиночным выбором, а второй -
задача из другой категории.
Для удобства сотрудников компании была создана категория «Отпуск». В
этой категории кроме основных параметров (как в предыдущем пункте),
определены другие ДП, такие как дата «С какого», дата «По какое», ФИО того кто
идет в отпуск (если за сотрудника отпуск заказывает его коллега) и Вид отпуска
(ежегодный оплачиваемый, не оплачиваемый…). Соответствующие экранные
87
формы приведены на рисунке 21.
Рисунок 21. Оформление отпуска
Сотрудники также могут поставить отсутствие (вне рабочего места более 15
минут) в соответствующую категорию, в этой категории определены такие ДП как
От кого ставится отсутствие, уведомить того, кому поставлено отсутствие (если
отсутствие ставят за сотрудника), список других сотрудников, которых необходимо
уведомить об отсутствии, дата «С какого», дата «По какое», вид отсутствия
(Удаленная работа, встреча, больничный…), место, где сотрудник планирует
находится во время отсутствия, степень занятости (занят, не занят, доступен для
звонков…), описание встречи, участники встречи, тема события, кто организатор и
дополнительный переключатель «Целый день», который автоматически заполняет
даты «С» и «По» на весь день. Соответствующие экранные формы приведены на
рисунке 22.
88
Рисунок 22. Постановка отсутствия
Каждый сотрудник может предложить новость, чтобы ее опубликовали в
общей ленте новостей компании, для этого необходимо заполнить форму с
заголовком новости, аннотацией, полным описанием, датой публикации (можно
сделать отложенную публикацию на определенную дату) и изображением к
новости. Форма создания новости приведена на рисунке 23.
89
Рисунок 23. Создание новостной статьи
Зачастую менеджерам после общения с клиентом требуется сделать
несколько заметок по нему, для этого создана специальная форма, которую
менеджер может заполнить из мобильного приложения, в форме поле Клиент
является контактом клиента, по которому пишется заметка, Событие - задача, в
которой описывается встреча и по порядку идут набор стандартных текстовых
заметок по этому клиенту. Форма редактирования заметки по клиенту приведена на
рисунке 24.
90
Рисунок 24. Заметка по клиенту
Для создания прозрачности работы в компании, чтобы и сотрудники и
руководство понимали чем каждый занимается, была создана категория Описания
роли сотрудника в компании. Эту форму каждый сотрудник заполняет за себя,
здесь он описывает свою роль в компании, список ближайших задач, процентная
оценка собственной эффективности, вектор развития, препятствия, которые
мешают работать, негатив в компании, по какой причине сотрудник находится в
компании и что его делает счастливым. Форма представлена на рисунке 25.
91
Рисунок 25. Форма оценки сотрудника
Выводы по главе 2
В ходе проектной части были проанализированы гибкие методологии и
выбрана методология Scrum для разработки проекта, определены риски на всех
этапах проекта и способы их предупреждения, описана система принятия
управленческих решений и выбрана система коллективной работы в проекте.
Также были определены ключевые обеспечения проекта, разработана
информационная модель, дерево функций и сценарий диалога. В качестве
итогового результата была разработана БД и основные программные модули
приложения.
92
Обоснование экономической эффективности проекта
3.1 Выбор и обоснование методики расчёта экономической
эффективности
Под «оценкой экономической эффективности ИС» стоит понимать комплекс
оценочных действий, проведение которых поможет понять, определить и измерить,
приносимую (принесенную) внедрением ИС на предприятии эффективность с
точки зрения экономики. Обычно, рассмотрение экономической полезности
состоит в оценке изменения в соотношении доходов и расходов предприятия,
вызванного инвестированием в ИС.
Метод, с помощью которого можно оценить эффективность ИС,
представляет собой, либо способ, либо комплекс средств, позволяющих провести
оценку ИС в целом. Он может содержать процедуры формального и
неформального характера. В качестве неформальных процедур стоит понимать ряд
быстрых, в большинстве своем субъективных, оценочных процедур, в основе
которых не лежит оценка цифровых параметров. Формальными же процедурами
стоит признать те, механизмы которых позволяют провести максимально
объективную и рациональную оценку, базой для которой в свою очередь
выступают недвусмысленные данные.
Общеизвестно, что мероприятия по внедрению современных IT-технологий
отличаются дороговизной. В условиях рынка каждый шаг, преобразующий систему
управления предприятием и влияющий на эффективность его функционирования,
необходимо, как минимум, анализировать в части возникающих последствий
экономического характера, но гораздо рациональней будет проведение
всеобъемлющей оценки его эффективности.
Проведение подобной оценки в части внедрения ИС представляет собой
сложную и трудоемкую работу, которая требует владения не только техническими,
но и экономическими навыками.
Основной целью экономического обоснования рассматриваемой ИС будет
количественное и качественное обоснование экономической целесообразности
разработки или модернизации ИС, а также определение главных экономических и
организационных условий для ее успешного функционирования.
93
При разработке отдельных компонентов или элементов ИС результаты
экономического анализа составляются непосредственно по ним. Важно помнить,
что в любом процессе проектирования ИС обязательно содержится несколько
аспектов экономического обоснования.
Программное обеспечение занимает особое место в составе комплексного
средства автоматизации. Оно также включает в себя программные модули или
отдельные пакеты программ, разработанные для использования другой ИС
(заимствованные), или созданные для широкого использования в разных ИС
(другими словам – универсальные), или абсолютно стандартные для различных
сфер применения компьютеров. Помимо такого типа ПО почти в каждой ИС
имеются оригинальные, специально созданные программы и алгоритмы, которые
необходимы для нормальной работы данной ИС. Важно всегда выделять процесс
создания ПО из общего процесса разработки автоматизированной системы.
Для правильного планирования процесса создания ПО и расчета его
стоимости важно определить трудоемкость разработки программных средств.
Распределение труда в процессе разработки ПО всегда вызывает огромные
трудности, как и с любой другой творческой деятельностью, элементы которой
могут определяться только на основе экспертных оценок опытных программистов,
либо жесткими и неизменными сроками реализации всего проекта. Творческая
часть труда программистов нормированию поддается, но точность этих норм имеет
большой разброс и зависит от ряда факторов. Только на основе опытно-
статистических данных от разных фирм, занимающихся программированием, были
разработаны несколько методов расчета трудоемкости разработки ПО.
В основе расчета экономической эффективности данной работы лежит
сравнение двух вариантов решения задачи: базового и предлагаемого. Базовый
вариант позволяет автоматизировать лишь часть процессов учета, предлагаемая же
модель предоставляет полную автоматизацию процесса.
Суммарная экономическая эффективность обычно складывается из пары
составляющих:
прямого эффекта, который позволяет сократить время на обработку и
получение информации, уменьшением трудоёмкости процесса работы и затрат на
обработку производимых операций;