Проект стартапа

Отображение основной информации: о цене, режиме работы и вместимости.

Сокращение времени на поиск парковочного места.

Уменьшение использования ресурсов (бензин и время) на прибытие к пункту назначения.

Возможность выбора наиболее выгодного и качественного варианта.

Таким образом, функции мобильного приложения следующие:

Отображение информации о всех платных парковках на территории Перми.

Предоставление корректных и актуальных данных.

Возможность положить наикратчайший путь до парковочного места.

Возможность ознакомиться с положительными и отрицательными аспектами парковки через отзывы.

Таким образом, исходя из определенной целевой аудитории в п.1.1.5, ценностное предложение будет выглядеть следующим образом: мы предлагаем информацию о всех платных парковках на территории Перми, чтобы наши пользователи, автомобилисты, могли выбрать любое парковочное пространство, быть уверенным в его доступности, близости и качестве и, тем самым, проложив наикратчайший путь, добраться до него с минимальными издержками и потратить больше времени на досуг.

2.1.7 Взаимоотношение с клиентами

Взаимоотношение с клиентами подразумевает установление отношений компании с потребительскими сегментами. Мотивы для определения отношений могут быть следующими: приобретение и удержание клиентов, а также увеличение продаж.

Данный стартап подразумевает несколько типов взаимоотношений с клиентами, а именно: персональная поддержка и совместное создание.

Персональная поддержка подразумевает возможность обращения в службу поддержку, которая ответит на вопрос, даст подсказку или отреагирует на ошибку, заявленную пользователем. Данный способ позволяет поддерживать не только обратную связь с пользователем, но и корректную работу мобильного приложения.

Совместное создание предполагает возможность пользователю оставлять отзывы о той или иной парковке, что создает ценность для других автомобилистов, подыскивающих платное парковочное место.

Таким образом, вышеописанные взаимоотношения с клиентами позволяют повысить ценность приложения и не только удержать уже существующих клиентов, но и приобрести новых.

2.1.8 Рыночное исследование

Целью рыночного исследования является выявление количества потенциальных пользователей, которые готовы пользоваться данным мобильным приложением. Необходимо отметить, что существует два основных подхода при расчете рынка, а именно: сверху вниз и снизу вверх.

При подходе «Сверху вниз» анализ начинается с крупной категории рынка и заканчивается более мелким рынком. Подход «Снизу вверх» характеризуется тем, что основой является проблема, которую решает продукт. На основе данной проблемы рассчитывается потенциальное количество пользователей, которые испытывают данную проблему. В рамках данной работы будет рассмотрен расчет рынка потенциальных пользователей «снизу вверх».

Для того чтобы оценить рынок проекта данным способом, было поставлено две задачи: понять, сколько людей заинтересованы в проекте и сколько человек смогут позволить себе платные парковки. Таким образом, был проведен анализ по данным статистики ключевых слов Яндекс, статистика показов словосочетания «платные парковки Пермь» составляет 1660 показов в месяц [31]. Следовательно, предполагается, что данное количество людей имеют машину или ищут информацию для друзей или родственников, имеющих частный автотранспорт. Что касается доходов, то по данным службы государственной статистики, более 43% населения Перми получают заработную плату выше 27 000 рублей (по данным выборочных исследований) [26],

Таким образом:

потенциальных пользователей

Исходя из данных, полученных путем опроса, можно предположить, что за первый месяц работы возможно будет привлечь не менее 700 человек.

2.1.9 Монетизация

Для того, чтобы получать доход с деятельности мобильного приложения «Агрегатор коммерческих парковок», необходимо рассмотреть существующие прямые и косвенные модели монетизации [17].

Прямые.

Подписка. Характеризуется взиманием заранее оговоренной платы с пользователя согласно предопределенному временному графику. Такая модель характеризуется предсказуемостью и регулярностью денежного потока и имеет разновидности, такие как:

Фримиум. Пользователь может пользоваться бесплатным приложением с ограниченной функциональностью или платной без ограничений или бесплатная версия с покупкой дополнительных возможностей.

Тестирование. Бесплатное пользование приложением в период тестового режима и переход на платный режим после его окончания.

Полностью платный доступ. Доступ к сервису только после полной его оплаты.

Микротранзакции. Иными словами, небольшие покупки внутри сервиса. Характеризуется возможностью постепенного расширения ассортимента и облегченными сборами платежей, поскольку небольшие выплаты являются наиболее комфортными для пользователей.

Косвенные.

Рекламная модель. Получение дохода с пользователей не на прямую, а через «внимание» пользователя. Полностью бесплатный характер приложения позволяет привлечь большее количество пользователей.

Генерирование продаж. Доход представляет собой комиссию от продажи или часть цены продаваемого продукта.



В таблице 2.5. приведен выбор модели монетизации.

Таблица 2.5 - Выбор модели монетизации

Модель	«Основная»/ «Запасная»/ «Не подходящая»
Подписка	Не подходящая
Фримиум	Не подходящая
Тестирование	Не подходящая
Полностью платный доступ	Не подходящая
Микротранзакции	«Запасная», по мере увеличения функций приложения.
Реклама	Основная
Генерирование продаж	Не подходящая

Как результат, реализуемый в виде бесплатного мобильного приложения проект «Агрегатор коммерческих парковок» нацелен на получение прибыли за счет использования рекламы. Имеется два способа монетизации путем привлечения платной рекламы, а именно:

Баннерная реклама.

Полноэкранная реклама.

Как уже было сказано, данный сервис будет нацелен только на жителей Перми. Следовательно, в процессе увеличения количества пользователей приложения, будет появляться возможность не только размещать рекламу, но и привлекать партнерские программы.

2.1.10 Анализ способов привлечения инвестиций

Существует несколько способов привлечения инвестиций в стартап-проект, а именно:

Краудфандинг. Групповое сотрудничество людей, объединяющих свои деньги или другие ресурсы на добровольной основе, зачастую через интернет, с целью поддержать усилия и начинания других людей. Наиболее популярными платформами являются Kickstarter и Indiegogo [6].

Бизнес-ангелы. Частные инвесторы, обладающие высоким уровнем дохода, которые готовы вкладывать собственные денежные средства в развитие компании.

Венчурные инвестиции. Отдельные лица или целые фонды, направленные на вложение средств в инновационные проекты (стартапы).

Каждый способ привлечения инвестиций имеет свои достоинства. Краудфандинг предоставляет возможность изначально изучить спрос на продукт или услугу через интерес людей, участвующих в инвестировании данного стартапа. Бизнес-ангелы обычно инвестируют стартапы на самой ранней стадии развития и представляют собой хороший способ получить быстрый доступ к капиталу. Что касается венчурных инвестиций, то они являются наиболее популярным способом мобилизации капитала для стартапа и оказывают стартапам поддержку в росте и развитии.

Наиболее предпочтительным вариантом из вышеперечисленных является привлечение бизнес ангелов, поскольку, как уже было сказано, они вкладывают денежные средства на начальном этапе стартапа, в то время как венчурные фонды характеризуются вложением средств на этапе расширения. Привлекать бизнес-ангелов можно как через их личные сайты, так и через открытые ресурсы, такие как: StartUpStep, AskCap.

Более того, возможно привлечь денежные средства в виде грантов или инвестиций следующим образом:

1.Фонд «Бортника».

2. ФРИИ.

3. Сколково.

4. ИТ-инкубаторы [17].

Стоит отметить, что в данном случае существует высокая вероятность получения денежных средств без обязательного их возвращения, в то время как получить обычный кредит в банке под только что созданный бизнес является трудным и далеко не всегда результативным вариантом.



2.2 Проектирование мобильного приложения

2.2.1 Постановка задачи

Мобильное приложение «Агрегатор коммерческих парковок» предполагает предоставление пользователям информации о платных парковочных местах в городе Перми. Пользователь после регистрации в приложении имеет возможность просмотреть расположение на карте платных парковок. Далее, выбрав конкретную платную парковку, посмотреть основную информацию о ней: режим работы, адрес, общая вместимость, цену за час и сутки. Для того, чтобы добраться до парковки более коротким путем, пользователь использует функцию «маршрут». В данном случае система осуществляет поиск наиболее короткого маршрута до выбранной парковки.

Наряду с просмотром и выбором платной парковки, пользователь имеет возможность просмотреть отзывы о парковке, а также написать свой. В случае возникновения неполадок или неточностей в предоставленной информации, пользователь может написать письмо в службу поддержки. Также, пользователь имеет возможность просматривать рекламу, которая монетизирует приложение, и отключать её.

Функциональные требования:

Для доступа к карте парковок, пользователь заходит в приложение и регистрируется или авторизуется, если осуществлял регистрацию ранее.

Пользователь может выбрать определенную парковку и увидеть основную информацию о ней: режим работы, стоимость, адрес.

Для просмотра отзывов, пользователь нажимает переходит в соответствующее окно через блок информации о конкретной парковке.

Пользователь имеет возможность оставить свой собственный отзыв.

Пользователь может проложить наиболее короткий путь к выбранной парковке.

В случае возникновения технических проблем, пользователь отправляет письмо в службу поддержки и ожидает ответ на указанный им e-mail. С целью визуализации структуры системы и понимания работы программы изнутри, используются UML диаграммы, поскольку они достаточно просты и понятны, а также позволяют охватить множество различных аспектов поведения системы.

2.2.2 Построение UML диаграмм

Диаграмма вариантов использования отражает отношение между актерами, ролями, а также прецедентами, последовательностью действий, что позволяет описать систему на концептуальном уровне. Диаграмма вариантов использования представлена на рисунке 2.7.

Рисунок 2.7. Диаграмма вариантов использования

Каждый прецедент описан с помощью документально зафиксированного потока событий. Данное документирование представлено далее в приложении А.

Для того, чтобы отразить разложение деятельности на составные части, осуществлено построение диаграмм деятельности. Таким образом, регистрация пользователя осуществляется только в том случае, если он первый раз использует устройство для входа в данное приложение. Регистрация осуществляет посредством выбора страны и ввода номера телефона. Более того, если данный номер уже был зарегистрирован в системе, то возможно восстановить данные, имя пользователя. Данная диаграмма для регистрации пользователя представлена на рисунке 2.8.



Рисунок 2.8. Диаграмма активности «Регистрация пользователя»

Для того чтобы авторизоваться, зарегистрированному пользователю необходимо ввести логин и пароль, если они не верны, то повторить свои действия. Данная диаграмма активности представлена на рисунке 2.9.

Рисунок 2.9. Диаграмма активности «Авторизация пользователя»

Зарегистрированный пользователь имеет возможность просмотреть расположение всех платных парковок на карте города (рис.2.10.).

Рисунок 2.10. Диаграмма активности «Просмотр всех парковок»

Пользователь имеет возможность определить свою геопозицию, чтобы найти расположение ближайших парковок. Если геопозиция не определяется автоматически, то пользователь вводит ближайший адрес, что представлено на рисунке 2.11.

Рисунок 2.11. Диаграмма активности «Определение текущего местоположения»

Пользователь имеет возможность искать определенную парковку. Вводит название парковки (адрес), если информация введена верно, то выводится основная информация, при неправильном вводе - пользователь повторяет попытку. Данная диаграмма представлена на рисунке 2.12.

Рисунок 2.12. Диаграмма активности «Поиск конкретной парковки»

После просмотра основной информации о конкретной парковке, пользователь имеет возможность просмотреть отзывы о ней, а затем написать свой. Данная диаграмма активности отображена на рисунке 2.13.

Рисунок 2.13. Диаграмма активности «Оставить отзыв»



Также, при просмотре основной информации о конкретной парковке, пользователь может проложить до нее короткий путь. Если геопозиция автомобилиста определена верно, то он запускает функцию определения короткого маршрута, в противном случае, автомобилист вводит адрес своего местонахождения. Данная диаграмма отображена на рисунке 2.14.

Рисунок 2.14. Диаграмма активности «Поиск наикратчайшего пути»

Автомобилист, в случае возникновения технических неисправностей в мобильном приложении или в случае обнаруженных ошибок, имеет возможность написать в службу поддержки при этом указав свой e-mail для получения ответа. Диаграмма активности представлена на рисунке 2.15.

Рисунок 2.15. Запрос в службу поддержки

Пользователь в любое время может просмотреть рекламу либо отказаться от её просмотра. Данная диаграмма представлена на рисунке 2.16.

Рисунок 2.16. Диаграмма активности «Просмотр рекламы»



Далее, созданные диаграммы последовательностей отражают временную последовательность действий и представлены ниже. В диаграмме последовательности для функции «регистрация пользователя» внешний субъект - пользователь принимает решение о регистрации в мобильном приложении. Сообщение с вводом номера отправляется в сервер приложения. Номер сохраняется в БД (база данных) приложения. Пользователь получает код регистрации, вводит его, а БД проверяет правильность введения кода. Затем пользователь вводит логин и пароль в сервер приложения и результат сохраняется в БД, что отображено ниже (рис.2.17.).

Рисунок 2.17. Диаграмма последовательности функции «Регистрация пользователя»

Диаграмма последовательности для функции «Авторизация пользователя» представлена на рисунке 2.18. Пользователь ввод логин и пароль, которые проверяются в сервере БД приложения. Результат проверки отправляется в сервер, откуда результат авторизации отправляется к пользователю.



Рисунок 2.18. Диаграмма последовательности для функции «Авторизация пользователя»

Диаграмма последовательности для функции «Просмотр всех парковок» представлена на рисунке 2.19. Внешний субъект - пользователь принимает решение о просмотре всех платных парковок. Сообщение «Авторизация» отправляется в сервер приложения. Проверка логина и результат проверки осуществляется в сервере БД приложения. Также пользователь делает запрос на показ всех платных парковок в сервер приложения, а в сервере БД приложения осуществляется обработка запроса и выводится результат запроса в сервер. Затем результат отправляется пользователю.

Рисунок 2.19. Диаграмма последовательности функции «Просмотр всех парковок»

Диаграмма последовательности для функции «Поиск конкретной парковки» представлена на рисунке 2.20. Пользователь производит авторизацию и отправляет запрос с адресом парковки в сервер приложения, откуда запрос отправляется в БД. Если парковка с таким адресом существует, то в сервер выводится сообщение с данными о парковке, в противном случае, сообщение об отсутствии парковки с указанными координатами. Затем и сервера, сообщение отправляется пользователю.

Рисунок 2.20. Диаграмма последовательности функции «Поиск конкретной парковки»

Диаграмма последовательности для функции «Оставить отзыв» представлена на рисунке 2.21. После авторизации пользователь пишет отзыв, который отправляется в сервер приложения, проверяется, и публикуется через сервер БД приложения. Затем из сервера БД приложения поступает информация о публикации отчета в сервер приложения. Так, пользователь получает сообщение об успешной публикации отзыва.

Рисунок 2.21. Диаграмма последовательности функции «Оставить отзыв»

Диаграмма последовательностей для функции «Поиск кратчайшего пути» представлена на рисунке 2.22. Пользователь вводит адрес необходимой ему парковки. Из сервера приложения данная информация отправляется в БД, где информация обрабатывается и выводится в сервер приложения, либо сообщение с координатами, либо сообщение с ошибкой. В случае, если парковка была найдена в БД, то сервер приложения отправляет запрос в сервер определения геопозиции и указывается текущая геопозиция пользователя. На уровне сервера приложения определяется кратчайший путь и информация отображается пользователю.

Рисунок 2.22. Диаграмма последовательности функции «Поиск кратчайшего пути»

Диаграмма последовательностей для функции «Запрос в службу технической поддержки» представлена на рисунке 2.23. Пользователь отправляет запрос в сервер приложения, на уровне которого он проверяется и запрос отправляется в сервер БД приложения. Далее сервер БД приложения отправляет отчет об отправке запроса в сервер приложения и пользователь получает сообщение об успешной отправке запроса.

Рисунок 2.23. Диаграмма последовательности функции «Запрос в службу технической поддержки»

Диаграмма последовательностей для функции «Просмотр рекламы» представлена на рисунке 2.24. Пользователь отправляет в сервер приложения запрос о включении или отключении рекламы. В свою очередь, сервер рекламных объявлений отправляет содержимое рекламы в сервер приложения и реклама показывается пользователю.



Рисунок 2.24. Диаграмма последовательности функции «Просмотр рекламы»

Диаграмма последовательностей для функции «Определение текущего местоположения» представлена на рисунке 2.25. Пользователь деле запрос на поиск местоположения, через сервер отправляется запрос в сервер геолокации и результат, в виде текущей геопозиции отправляется на сервер и к пользователю.

Рисунок 2.25. Диаграмма последовательности функции «Определение текущего местоположения»

Далее было осуществлено моделирование классов, которые определяют сущность информационной системы. Диаграмма классов представлена на рисунке 2.26.

Рисунок 2.26. Диаграмма классов

Класс Users содержит информацию о пользователях системы, такую как: логин и пароль.

Класс Zapros содержит информацию о запросах: текст запроса, изображение - которые могут оставлять пользователи в службу технической поддержки.

Класс Otzivi содержит информацию об отзывах: текст запроса, изображение - которые могут оставлять пользователи о любой парковке.

Информация о парковках хранится в классе Parkovki, которые содержит: название парковки, стоимость часа, стоимость суток, количество мест, время начала работы, время окончания работы.

В классе Goroda хранится информация о городе: название города, число парковок. В нашем случае хранится информация об одном городе Пермь.

Для города доступна своя реклама - класс Reklama, который содержит: текст рекламы, изображение, дата публикации.

Диаграмма развертывания, представляющая графическое изображение процессов, устройств и связей между ними, представлена на рисунке 2.27.

Рисунок 2.27. Диаграмма развертывания

Далее было выполнено проектирование базы данных. При проектировании используется нормализация, которая подразумевает преобразование отношений базы к виду, который отвечает нормальным формам. На основе поставленной задачи и описания предметной области, выявлены атрибуты базы данных. Для того, чтобы привести базу к первой нормальной форме (1НФ) необходимо избавиться от неатомарных, неделимых, данных, выбрать первичный ключ, однозначно определяющего запись. База в первой нормальной форме представлена в таблице 2.6., а первичные ключевые поля выделены цветом.

Таблица 2.6 - Первая нормальная форма

Атрибут	Данные № 1	Данные №2
Код города	01	02
Название города	Пермь	Пермь
Код парковки	101	102
Число парковок	120	120
Название парковки	Автомобильная парковка №101	Автомобильная парковка №102
Адрес	Монастырская, 10	Екатерининская, 109а
Цена за час	15 руб	15 руб
Цена за сутки	90 руб	90 руб
Количество мест	300	250
Врем открытия	8:30	8:30
Время закрытия	19:30	19:30
Код отзыва	110	111
Описание отзыва	Много доступных мест.	Близко к дому, дружелюбный охранник.
Код пользователя	1	2
Логин	Артем	Юрий
Пароль	1111	1202
E-mail	hgf@mai.ru	hkdhfkj@mail.ru
Номер телефона	7912885353	79194513903
Код запроса	1000	1001
Текст запроса	Не правильно отображена информация о парковке.	Не могу проложить маршрут. Функция не работает.
Код рекламы	999	998
Название рекламы	Магазин посуды	Магазин строительных инструментов
Описание рекламы	Реклама столовых приборов.	Реклама новой техники
Дата публикации	11.06.2017	11.06.2017
Тип рекламы	Банерная реклама	Полноэкранная реклама
Длительность	1 день	3 часа
Количество просмотров	399	420
Количество кликов	33	101
Стоимость	3000	4000
Код рекламодателя	10001	10002
ФИО	Сергеев Сергей Сергеевич	Петров Петр Петрович
Название	«Кружки - ложки»	«Строим дом»
Организационная форма	ООО	ИП
Телефон	+79191919198	+793665389
E-mail	kruzhki@yandex.ru	Dom@mail.ru

Отношение находится во второй нормальной форме тогда, когда оно находится в 1НФ и все неключевые атрибуты функционально полно зависят от потенциального ключа. Таким образом, с помощью ключевых полей, можно разбить форму на 2 таблицы, которые определяют информацию о парковке и пользователе. Разбиение полей на таблицы представлено в таблице 2.7.

Таблица 2.7 - Вторая нормальная форма

Информация о парковке	Информация о пользователе
Код парковки *	Код пользователя*
Название парковки	Логин
Цена за час	Пароль
Цена за сутки	e-mail
Количество мест	Номер телефона
Время открытия	Код запроса
Время закрытия	Текст запроса
Код города
Название города
Число парковок
Код отзыва
Текст отзыва
Код рекламы
Название рекламы
Описание рекламы
Дата публикации
Тип рекламы
Длительность
Количество просмотров
Количество кликов
Стоимость
Код рекламодателя
ФИО
Название
Организационная форма
Телефон
E-mail

Отношение находится в третьей нормальной форме в случае, если оно находится в 2НФ и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых [7]. Далее, на рисунке 2.28. представлена приведенная к третьей нормальной форме схема базы данных в MS Access.

Рисунок 2.28. Схема базы данных

Для того, чтобы определить необходимое пространство для данных, произведем расчеты потенциального количества занятого пространства. Согласно проанализированным данным, приложение в первое время его реализации охватит минимум 220 парковок города Перми [2]. Данные для расчета потенциального необходимого пространства представлены в таблице 2.8.

Таблица 2.8 - Данные для расчета пространства на 1 парковку

Поле	Тип данных	Максимальный объем (байты)
Код парковки	Счетчик	4
Название парковки	Короткий текст	256
Цена за час	Денежный	8
Цена за сутки	Денежный	8
Количество мест	Числовой	2
Время открытия	Дата и время	8
Время закрытия	Дата и время	8
Код города	Числовой	2
Название города	Короткий текст	256

Общий максимальный объем на 1 парковку составляет 554 байта. Следовательно, количество байтов на 220 парковок равно 121 880 байтов, что составляет 0,00011 Гигабайтов (ГБ).

Как известно из п.2.1.5. количество потенциальных пользователей в первый месяц составит 700 человек. Посчитаем количество пространства, которое может занять данное количество пользователей в БД, информация для расчета представлены в таблице 2.9.

Таблица 2.9 - Данные для расчета пространства на 1 пользователя

Поле	Тип данных	Максимальный объем (байты)
Код пользователя	Счетчик	4
Логин	Короткий текст	256
Пароль	Короткий текст	256
e-mail	Короткий текст	256
Номер телефона	Числовой	2
Код запроса	Числовой	2
Текст запроса	Короткий текст	256
Код отзыва	Числовой	2
Текст отзыва	Короткий текст	256

Общий максимальный объем на 1 пользователя составляет 1290 байт. Следовательно, количество байтов на 700 пользователей равно 903 000 байтов, что составляет 0,00084 Гигабайтов (ГБ).

Следовательно, потенциальный необходимый объем БД при запуске мобильного приложения составляет 0,00095 ГБ. Стоит отметить, что количество занятого пространства будет увеличиваться по мере увеличения числа пользователей и количества информации о платных парковках.

2.2.3 Выбор инструментов для реализации мобильного приложения

Как уже было сказано, для того, чтобы реализовать данный стартап, необходимо разработать мобильное приложение «Агрегатор коммерческих парковок», используя различные программные и аппаратные средства. Стоит отметить, что данное приложение будет разрабатываться под управлением операционной системы (ОС) Android. Данный выбор обосновывается тем, что на январь 2017 года была определена следующая распространенность ОС в России:

Windows Phone - 2.54%.

iOS - 26.56%.

Android - 68.87% [31].

На сегодняшний день, на рынке мобильных телефонов наиболее популярной ОС является Android, что подтверждает данная статистика. Таким образом, далее были определены минимальные требования к ПО и, как результат, перечислены программные средства, необходимые для разработки мобильного приложения «Агрегатор коммерческих парковок».

Были определены следующие требования к мобильному приложению:

Поддержка мобильной платформы Android (версия 3.0. и выше)

Быстрая скорость работы пользовательского интерфейса.

Для того, чтобы написать Android-приложение, будет использован такой язык программирования, как Java.

Мобильное приложение базируется на клиент-серверной архитектуре, поскольку планируется большое количество пользователей, существует необходимость в централизованном управлении, безопасности и необходимость в специализированном сервере. Так, были выделены требования к программному обеспечению (ПО) и экспертным образом выбраны соответствующие программные ресурсы.

Требования к ПО клиентского приложения и сервера приложений:

- Android Studio. Среда разработки мобильного приложения - экранных форм, логики, запросов и так далее.

- GIMP. Графический редактор. Имеет широкий набор функций: полный набор инструментов рисования и преобразования, работа со слоями, поддержка широкого количества форматов файлов, большой набор фильтров, наличие дополнительных плагинов. Поскольку нет необходимости разрабатывать трудоемкий дизайн для данного приложения, то функций такого графического редактора будет достаточно.

Выбор ПО для сервера базы данных (БД):

База данных для серверной части выбирается исходя из следующих требований:

Возможность поддерживания большого набора типов данных.

Безопасность и целостность данных.

Возможность масштабирования.

Реализациях для UNIX-подобных платформ.

Сравнение свободно распространяемых СУБД представлено в Приложении Д. Таким образом, была выбрана PostgreSQL. Несмотря на то, что данная БД имеет некоторые недостатки, такие как: плохая многопоточность, инициация вех процессов снаружи базы и сложность в использовании, она является наиболее продвинутой СУБД и обладает механизмом высокой мощности для контроля целостности данных.

- Redis. Сетевое журналируемое хранилище, выбран исходя из следующих возможностей:

1. Возможность сохранять сессии и профили пользователей.

2. Возможность хранить промежуточные результаты вычислений при обработке больших объемов данных.

3. Возможность хранения больших объемов данных.

Требования к веб-серверу следующие:

Высокий уровень безопасности.

Надежность и удобство.

Поддерживаемая ОС - Linux.

Таким образом, был выбран такой веб-сервер, как Apache.

Для разработки приложения также будут использованы некоторые стандартные библиотеки: для поиска данных о парковках и основной информации - JSON или xml parser, для определения локации пользователя стандартная библиотека LocationManager.

Выбор хостинга основывается на следующих требованиях:

Круглосуточная и быстрая техническая поддержка.

Автоматическое создание резервных копий базы данных.

Быстродействие, следовательно, близкое территориальное расположение.

Поддержка выбранной СУБД.

Количество пространство для данных - 1 ГБ.

На сервере будет храниться 1 БД и осуществляться все транзакции по работе с ней.

На основе рейтинга хостинг-провайдеров, выделены самые популярные хостеры, предоставляющие виртуальный хостинг в России, а именно: Mchost, Аdminvps, Евробайт, HostMan и HandyHost. Данное сравнение представлено в приложении Д. Стоит отметить, что не все из них поддерживают PostgreSQL. Более того, были проанализированные различные рейтинги хостингов на таких сайтах, как: hosting101.ru, siterost.ru, zapili.net и так далее и выбран хостинг на adminvps.ru. Выбор обосновывается тем, что данный представитель входит в 10 лучших хостингов сразу на нескольких сайтах одновременно и наблюдается много положительных отзывов о нем, поддерживает PostgreSQL и имеет сравнительно невысокую цену за услуги.

Данный представитель предлагает услуги виртуального хостинга в Москве. Более того, имеется круглосуточная техническая поддержка, бесплатное администрирование, бесплатное еженедельное копирование и с учетом вышеописанных требований, предлагает тариф «Promo» 99 руб./мес. и дополнительно выделенный ip - 99 руб./мес. По мере развития проекта и увеличения количества пользователей возможен быстрый переход на другой тариф, но данного пространства для данных в размере 1 ГБ хватит минимум на 4000 пользователей и 1000 парковок, что возможно предположить, благодаря подсчету потенциального необходимого объема БД в п.2.2.2.

2.2.4 Оценка трудоемкости разработки программного обеспечения с помощью методики CETIN

Для того, чтобы вычислить трудоемкость разработки мобильного приложения, применяется методика СETIN, поскольку она позволяет оценить стоимость разработки на ранних стадиях проектирования. Согласно методологии разработки программного обеспечения RUP (Rational Unified Process), основные процессы разработки следующие:

Бизнес моделирование.

Управление требованиями.

Проектирование.

Реализация.

Тестирование.

Развертывание [15].

Базовая трудоемкость процесса (Sj) рассчитывается по следующей формуле:

где Sj -трудоемкость процесса разработки с номером j в [человеко-месяц].

j-номер процесса разработки.

Sj(C) - нормативные коэффициенты трудоемкости реализации одного варианта использования в процессе разработки. Значение выбирается из таблицы в приложении Б.

Sj(E)- нормативный коэффициент трудоемкости реализации одного типа объектов в процессе разработки. Значение выбирается из таблицы в приложении Б.

Sj(T) - нормативный коэффициент трудоемкости реализации одного свойства типа объекта в процессе разработки. Значение выбирается из таблицы в приложении Б.

Sj(I)- нормативный коэффициент трудоемкости реализации одного взаимодействия между типами объектов в процессе разработки. Значение выбирается из таблицы в приложении Б.

Sj(N) - нормативный коэффициент трудоемкости реализации одного типа узла в процессе разработки с номером. Значение выбирается из таблицы в приложении Б.

300 - количество человеко-часов в одном человеко-месяце.

Оценка функционального размера информационной системы зависит от набора из 5 элементов, каждый элемент которого представляет собой определенную функциональную единицу измерения, а именно:

Количество вариантов использования (C - case).

Количество типов объектов (E- entity).

Количество свойств типов объектов (T - tool).

Количество взаимодействий между типами объектов (I - interaction).

Количество типов узлов (N - node) [17].

Таким образом, необходимо применить модель информационной системы, реализованной на языке моделирования UML.

Таким образом, на основание построенных диаграмм, которые представлены в п.2.2.2., функциональный размер информационной системы следующий:

C - 9.

E - 6.

T - 28.

I - 21.

N - 5.

Следовательно, оцениваем трудоемкость каждого этапа разработки:

32,12 + 6*28,33 + 21*14,15) = 2,5

+ 6*28,04 + 21*20,32) = 3,7

+ 6*61,75 + 28*31,35+21* 37,52 + 5*24,02) = 8,6

31,57 + 6*81,51 + 28*50,72 + 21*36,11) = 9,8

88,96) = 2,66

) = 0,66

Методика CETIN не включает в себя технические требования к системе и требования качества пользователя. Методика отражает влияние данных требований через поправочные коэффициенты, представленные в приложении Б. Таким образом, будут использованы средние значения.

1 = 2,66

1 = 0,66

Далее приведены сроки для каждого этапа разработки мобильного приложения, которые представлены в таблице 2.10. Стоимость рассчитывается на основе данных о зарплате, прописанных в п. 3.4.

Таблица 2.10 - Сроки разработки мобильного приложения по методике CETIN

№	Название этапа	Длительность (дней)	Количество участников	Стоимость (руб.)
1	Бизнес моделирование	13	6 человек. (Проектировщик, разработчик, аналитик, специалист по БД, руководитель стартапа, дизайнер)	73 667
2	Управление требованиями	19	6 человек. (Проектировщик, разработчик, аналитик, специалист по БД, руководитель стартапа, дизайнер)	107 667
3	Проектирование	44	6 человек. (Проектировщик, разработчик, аналитик, специалист по БД, руководитель стартапа, дизайнер)	249 333
4	Реализация	50	6 человек. (Проектировщик, разработчик, аналитик, специалист по БД, руководитель стартапа, дизайнер)	283 333
5	Тестирование	14	6 человека. (Проектировщик, разработчик, аналитик, специалист по БД, руководитель стартапа, дизайнер)	79 333
6	Развертывание	4	6 человек. (Проектировщик, разработчик, аналитик, специалист по БД, руководитель стартапа, дизайнер)	22 667

Следовательно, общий срок создания мобильного приложения составляет 144 дня (4 месяца и 24 дня), что приблизительно составляет 5 месяцев, а общая стоимость разработки - 816 000 рублей.

Глава 3. Бизнес-план стартапа «Агрегатор коммерческих парковок»

3.1 Технологический план

Необходимые программные ресурсы были определены в п.2.2.3 и представлены в таблице 3.1.

Таблица 3.1 - Программные ресурсы

Ресурс	Назначение
Linux	Операционная система
Android Studio	Среда разработки
GIMP	Графический редактор
Apache	Веб-сервер
Redis	Сетевое журналируемое хранилище
PostgreSQL	СУБД

Данные ресурсы реализуются бесплатно и находятся в свободном доступе. Также, стоит отметить, что участники стартапа привлекаются на удаленную работу со своими ноутбуками. Следовательно, нет необходимости в покупке компьютеров.

3.2 Маркетинговый план

Как было описано в п. 2.1.5., был выбран такой способ рекламы мобильного приложения, как таргетинговая реклама в социальных сетях.

Существует два способа платы за рекламу:

За переходы по ссылкам.

За количество показов.

Средняя стоимость клика в таргетинговой рекламе составляет 10-25 рублей [45]. Рекомендуемая стоимость 1000 показов равна 84 рубля [45]. По опыту продвижения мобильных приложений через «Вконтакте», среднее значение CTR (показатель кликабельности) равно 0,7% [40]. Следовательно, затраты, связанные с рекламой, представлены в таблице 3.2.

Таблица 3.2 - Затраты на рекламу

	1 месяц	2 месяц	3 месяц
Необходимое количество человек (переходы)	700	500	500
CTR (Click Through Rate)	0,7%	0,7%	0,7%
Показы	100 000	71 428	71 428
Стоимость по переходам (руб.)	7000	5 000	5 000
Стоимость по просмотрам (руб.)	8400	6000	6000

В нашем случае будет использован первый вариант, поскольку он позволяет не тратить бюджет на нецелевую аудиторию и является наиболее выгодным, исходя из данных таблицы 3.2. Однако, стоимость за показ и перевод рассчитывается в каждом случае индивидуально, а дальнейшая стратегия продвижения будет основываться на эффективности данной рекламы, что будет составлять часть работы SEO-специалиста.

3.3 План производства

В п. 2.1.5. была определена целевая аудитория и потенциальное количество пользователей в первый месяц в размере не менее 700 человек, а в п.2.1.9. был выбран способ монетизации мобильного приложения- использование баннерной и полноэкранной рекламы.

Следовательно, предположительные доходы с рекламы:

1. Баннерная реклама.

Такой вид рекламы основан на том, что рекламируемая информация отображается на определенном пространстве в интерфейсе приложения и, как результат, доход рассчитывается на основании просмотров или переходов. Согласно компании AdWired Mobile, средняя стоимость одного показа - 0,75 рублей. [11].

2.Полноэкранная реклама.

Данный вид рекламы предполагает отображение рекламного баннера на весь экран мобильного приложения. Средняя стоимость просмотра составляет 0,95 рублей, согласно платформе Okeo [11].

Далее, рассчитывается потенциальный доход по трем вариантам: пессимистичный, реалистичный (усредненный) и оптимистичный, что представлено в таблице 3.3. Стоит отметить, что реалистичный вариант предусматривает использование приложения 3 раза в неделю, что соответствует дням повышенной загруженности бесплатных парковок в местах большого скопления людей, а именно: пятница, суббота, воскресение.

Таблица 3.3 - Расчет дохода с мобильного приложения

	Пессимистичный	Реалистичный	Оптимистичный
Количество пользователей	350	500	600
Частота использования приложения	2 раза в неделю	3 раза в неделю	4 раз в неделю
Продолжительность использования приложения (мин/день)	20	30	60
Количество баннеров	2	3	3
Количество полноэкранной рекламы	1	1	2
Доход (руб/мес)	6860	19 200	39 840

Как результат, при реалистичном варианте планируется получить доход в размере 19 200 рублей в первый месяц работы мобильного приложения. Доход в последующие месяцы рассчитывается с прогнозом на то, что количество уникальных посетителей каждый месяц увеличивается минимум на 500 пользователей, 300 из которых активно пользуются мобильным приложением при реалистичном варианте, 400 при оптимистичном и 250 при пессимистичном.

3.4 Организационный план

В п.2.1.4. были определены участники стартапа на разных этапах его разработки. Заработная плата вычисляется как среднее по Перми, с помощью Интернет- ресурса «Яндекс. Работа» [3]. Таким образом, средняя заработная плата участников представлена в таблице 3.4.

Таблица 3.4 - Средняя заработная плата сотрудников

Участник	Количество	Заработная плата (руб./мес.)
Проектировщик	1	30 000
Разработчик под Android	1	35 000
Специалист по БД	1	25 000
Менеджер проекта	1	30 000
Аналитик-тестировщик	1	25 000
Дизайнер	1	25 000
SEO-специалист	1	25 000
Администратор проекта	1	20 000

Следовательно, сумма, необходимая для выплаты заработной платы участником проекта на каждом этапе, представлена в таблице 3.5.

Таблица 3.5 - Затраты на сотрудников на каждом этапе деятельности

Участник	Заработная плата (руб./мес.)
Затраты на сотрудников на начальном этапе
Проектировщик	30 000
Разработчик под Android	35 000
Специалист по БД	25 000
Менеджер проекта	30 000
Аналитик-тестировщик	25 000
Дизайнер	25 000
Итого	170 000
Затраты на этапе сопровождения проекта
Проектировщик	30 000
Разработчик под Android	35 000
Специалист по БД	25 000
Менеджер проекта	30 000
Аналитик-тестировщик	25 000
Администратор проекта	20 000
Итого	160 000
Затраты на этапе полного сопровождения
Разработчик под Android	35 000
Менеджер проекта	30 000
Администратор проекта	20 000
SEO-специалист	25 000
Итого	110 000

3.5 Финансовый план

Финансовый раздел предполагает описание финансового обеспечения деятельности предприятия, а также расчет экономических показателей, с целью определения экономический выгодности ИТ-проекта.

Исходя из вышеописанных расчетов, для запуска проекта необходимо привлечь денежные средства, представленные в таблице 3.6.

Таблица 3.6 - Инвестиции на начальном этапе развития проекта

Статья расходов	Стоимость (руб.)
Разработка мобильного приложения	816 000
Первоначальные затраты на рекламу	7000
Размещение приложения	1424,5
Хостинг	198
Итого	824 622,5

Таким образом, затраты на стартап «Агрегатор коммерческих парковок» в период начальной реализации проекта составляют 824 622,5 руб.

Далее, необходимо посчитать экономику продукта, что позволит увидеть слабые места проекта и не допустить, чтобы доход привлеченного пользователя был ниже, чем стоимость привлечения пользователя. Для расчета экономики продукта необходимо знать:

Число привлеченных пользователей (User Acquisition - UA).

Стоимость привлечения пользователя (Cost Per Acquisition -CPA).

Доход на привлеченного пользователя (Average Revenue Per User - ARPU) [17].

Согласно п.2.1.8., число потенциальных пользователей - 700 человек, а согласно п. 3.3 при реалистичном варианте. доход составляет 19 200. Следовательно, на основе имеющихся данных мы можем вычислить ARPU и CPA по следующим формулам:

,

где Revenue - доход.

Таким образом:

Следовательно, доход на привлеченного пользователя составляет 27,4 рублей, при стоимости привлечения - 10 рублей.

На основе вышеописанных расчетов, возможно высчитать прибыль за первый месяц функционирования приложения по следующей формуле:

где Profit - прибыль.

Как результат, необходимо отметить что ARPU выше чем СPA, следовательно, наша бизнес-модель сходится, так как изначально зарабатываем больше, чем тратим на привлечение пользователей. Проект изначально является прибыльным и в дальнейшем, согласно росту количества пользователей, будет приносить большую прибыль. Более того, пользователь окупает себя в первый же месяц, что говорит об отсутствии риска кассового разрыва.

Далее, в таблице 3.7., представлен учет всех доходов и расходов для реалистичного варианта по следующей формуле:

где New users profit - прибыль со старых пользователей.

Old Users Profit - прибыль с новых пользователей.

Fixed Costs - фиксированные расходы в месяц, к примеру, на заработную плату.

Стоит отметить, что дальнейший расчет прибыли с новых пользователей, рассчитывался исходя из фиксированной суммы затрат на рекламу, указанной в п.3.8.

Таблица 3.7 - Расчет прибыли при реалистичном варианте

Месяц	Старые пользователи (чел.)	Новые пользователи	Прибыль со старых пользователей (руб.)	Прибыль с новых пользователей (руб.)	Фиксированные издержки (руб.) п.3.4.	Прибыль (руб.)
1	0	500	0	19 200	110 000	-90 800
2	500	300	19 200	11 520	110 000	-79 280
3	800	300	30 720	11 520	110 000	-67 760
4	1100	300	42 240	11 520	110 000	-56 240
5	1400	300	53 760	11 520	110 000	-44 720
6	1700	300	65 280	11 520	110 000	-33 200
7	2000	300	76 800	11 520	110 000	-21 680
8	2300	300	88 320	11 520	110 000	-10 160
9	2600	300	99 840	11 520	110 000	1 360

Таким образом, несмотря на то, что изначально данный проект находится в минусе, при реалистичном варианте, увеличение числа пользователей позволит получать прибыль на 9ый месяц функционирования проекта при общей посещаемости в 2600 человек и прибыль продолжит устойчиво расти.

Что касается пессимистичного (350 активных пользователей) и оптимистичного (600 активных пользователей) варианта при привлечении 700 человек (п.3.2.), то в первый месяц функционирования приложения стоимость привлеченного пользователя составляет 9,8 и 57 рублей, соответственно. Стоит отметить, при стоимости пользователя в 10 рублей, пессимистичный вариант является невыгодным, поскольку проект функционирует в убыток, что увеличивает срок получения положительной прибыли. Результаты расчета представлены в таблице.

Расчет прибыли для пессимистичного и оптимистичного вариантов представлен в таблице 3.8.

Таблица 3.8 - Расчет прибыли для пессимистичного и оптимистичного вариантов

Месяц	Старые пользователи (чел.)	Новые пользователи	Прибыль со старых пользователей (руб.)	Прибыль с новых пользователей (руб.)	Фиксированные издержки (руб.) п.3.4.	Прибыль (руб.)
Пессимистичный вариант
1	0	350	0	6860	110 000	-103 140
2	350	250	6860	4900	110 000	-98 241
3	600	250	11 760	4900	110 000	-93 342
4	850	250	16 660	4900	110 000	-88 503
5	1100	250	21 560	4900	110 000	-83 544
6	1350	250	26 460	4900	110 000	-78 645
7	1600	250	31 360	4900	110 000	-73 746
8	1850	250	36 260	4900	110 000	-68 847
9	2100	250	41 160	4900	110 000	-63 948
10	2350	250	46 060	4900	110 000	-59 049
11	2850	250	50 960	4900	110 000	-54 150
12	3100	250	55 860	4900	110 000	-49 251
13	3350	250	60 760	4900	110 000	-44 352
14	3600	250	65 660	4900	110 000	-39 453
15	3850	250	70 560	4900	110 000	-34 554
16	4100	250	75 460	4900	110 000	-29 655
17	4350	250	80 360	4900	110 000	-24 756
18	4600	250	85 260	4900	110 000	-19 857
19	4850	250	90 160	4900	110 000	-14 958
20	5100	250	95 060	4900	110 000	-10 059
21	5350	250	99 960	4900	110 000	-5 160
22	5600	250	104 860	4900	110 000	-261
23	5850	250	109 760	4900	110 000	4 638
Оптимистичный
1	0	600	0	39 840	110 000	-70 160
2	600	400	39 840	26 560	110 000	-43 600
3	1000	400	66 400	26 560	110 000	-17 040
4	1400	400	92 960	26 560	110 000	9 520

Подводя итог, необходимо отметить, что при пессимистичном варианте стартап начнет приносить прибыль через 23 месяца (1 год 11 месяцев) при количестве пользователей - 6100 человек, а при оптимистичном варианте через 4 месяца при количестве пользователей в 1400 человек, но существует риск перенасыщения рекламой приложения.

На основе расчетов прибыли можно сделать вывод, что дополнительный затраты на функционирование приложения составляют 403 840 рублей при реалистичном варианте, 1 137 471 рублей при пессимистичном и 130 800 при оптимистичном (согласно данным о прибыли в таблице 3.7. - 3.8).

Более того, с целью определить эффективны и целесообразны ли описанные выше вложения, необходимо спрогнозировать эффективность проекта, путем расчёта приведенного денежного потока. На сегодняшний день, данный метод оценки стартапа является одним из основных [16]. С помощью данного показателя представляется возможным, оценить стоимость через определенный период времени и рассчитать срок окупаемости инвестиций.

Приведенный денежный поток (DPV) - это приведение текущих денежных платежей к текущему моменту времени [41].



где CFk - чистый денежный поток,

i - ставка дисконтирования,

K - период.

Дисконтированный срок окупаемости (DPP) - показатель, который отражает, за какой период окупятся первоначальные затраты и вычисляется по формуле:

где IC - инвестиционный капитал.

Для расчета ставки дисконтирования был использован кумулятивный метод, поскольку, он учитывает поправки на риски, которые связанны с вложениями инвестиций и неэффективным управлением, а также является наиболее простым способом расчета и, как результат, не требует высокого уровня профессионализма и привлечения специалистов.

Ставка дисконтирования при использовании кумулятивного метода рассчитывается по следующей формуле:

где Emin - минимальная реальная ставка дисконтирования, I - уровень инфляции,

r - премия за риск.

Согласно статьи «Прогнозная оценка странового риска в России», Россия находится в относительно благоприятном инвестиционном климате и страновой риск составляет 5% [10].

Таким образом, премия за риск равна:

На февраль 2017 г. Emin=3,01% [8], I=4,59% [36]. Тогда номинальная ставка дисконтирования:

Вычислим реальную годовую ставку дисконтирования:

Тогда месячная ставка дисконтирования:

Произведенные расчеты в Приложении Д, позволяют сделать определенные выводы для каждого варианта получения дохода. Результаты, на основе которых формируются выводы, выделены серым цветом.

Так, при реалистичном варианте (рис.Е.1), срок окупаемости первоначальных инвестиций в размере 824 622,5 рублей составляет 30 месяцев (2 года 6 месяцев). Что касается общих инвестиций в размере 1 228 462,5 рублей, то они окупятся через 32 месяца (2 года 8 месяцев).

При пессимистичном варианте (рис.Е.2), срок окупаемости первоначальных инвестиций в размере 824 622,5 рублей составляет 93 месяца (7 лет 9 месяцев). Что касается общих инвестиций в размере 1 962 093,5 рублей, то срок их окупаемости составляет 124 месяца (10 лет 4 месяца).

Оптимистичный вариант (рис.Е.3) предполагает окупаемость всех необходимых инвестиций, общая сумма которых составляет 955 422,5 рублей за 17 месяцев (1 год 5 месяцев).

Таким образом, описание других показателей, необходимых для расчета приведенного денежного потока и расчет оценки проекта представлен в Приложении Д для трех вариантов: пессимистичного, реалистичного и оптимистичного. Исходя из полученных данных, можно сделать вывод, что стартап обладает потенциалом, поскольку денежный поток, при реалистичном варианте, на 25 месяце принимает положительное значение.

3.6 Оценка рисков

Оценка рисков представляет собой совокупность аналитических мероприятий, которые позволят спрогнозировать определенный масштаб ущерба от возникшей ситуации риска при несвоевременном принятии мер по его предотвращению. Оценка риска будет применена с помощью качественного анализа рисков, который включает в себя расстановку рангов для определенных рисков.

Оценка риска по его последствиям, классифицируется следующим образом:

Допустимый. Риск, который характеризуется таким размером потерь, что они не превышают размер прибыли и не перекрывают планируемых доход.

Критический. Риск, при котором возникает угроза не только потери прибыли, но и выручки.

Катастрофический. Риск, при котором возможна потеря капитала, всего имущества, что приведет к полному банкротству. В таблице 3.9. представлена шкала для оценки риска по его последствиям.



Таблица 3.9 - Шкала оценки риска по его последствиям

Последствия риска	Вес
Допустимый	1
Критический	2
Катастрофический	3

Классификация вероятности наступления риска следующая:

Маловероятно. Шансы наступления очень малы.

Возможно. Шансы наступления есть, но он малы.

Очень вероятно. Шансы наступления риска очень велики.

В таблице 3.10. представлена шкала для оценки риска по вероятности его наступления.

Таблица 3.10 - Шкала для оценки риска по вероятности его наступления

Вероятность наступления	Вес
Маловероятно	1
Возможно	2
Очень вероятно	3

Анализируя опыт создания проектов, связанных с разработкой мобильных приложений, можно выделить следующие риски:

Внешние риски:

Нестабильность экономической ситуации.

Изменения природно-климатических условий.

Внутренние риски:

Уменьшение уровня заинтересованности к проекту

Снижение конкурентоспособности.

Выход из строя техники.

Текучесть кадров.

Вероятность недофинансирования.

Недополучение планируемых объемов прибыли.

Таким образом, в таблице 3.11. отражена оценка рисков.

Таблица 3.11 - Оценка рисков

Название	Условие	Последствия	Ущерб	Вероятность	Последствия	Итог
Нестабильность экономической ситуации.	Экономический кризис	Сокращения, уменьшение заработных плат.	Сокращение числа пользователей приложения. Отсутствие интереса к платным парковкам.	2	2	4
Изменения природно-климатических условий.	Природные катаклизмы и бедствия.	Ухудшение устоявшейся деятельности предприятия.	Возможное прекращение функционирования приложения.	1	2	3
Уменьшение уровня заинтересованности к проекту	Наблюдается спад активности мобильным приложением и уменьшение количества скачиваний.	Уменьшение количества пользователей мобильного приложения.	Сокращение прибыли.	1	3	4
Снижение конкурентоспособности.	Низкий уровень качества предоставляемых услуг и появление новых игроков на рынке.	Уменьшение количества пользователей мобильного приложения.	Сокращение прибыли.	1	2	3
Выход из строя техники.	Поломка техники.	Низкая производительность, качество проекта.	Уменьшение лояльности клиента. Затраты на покупку или ремонт техники.	1	2	3
Текучесть кадров.	Частые увольнения и смена одних сотрудников другими.	Низкая производительность.	Привлечение дополнительных временных и материальных затрат на ввод нового сотрудника в процесс работы.	1	2	3
Вероятность недофинансирования.	Несвоевременная оценка ресурсов для выполнения проекта	Сбой в деятельности предприятия.	Уменьшение качества предоставляемых услуг и количества пользователей.	2	3	5
Недополучение планируемых объемов прибыли.	Расчет планируемого числа активных пользователей окажется неточным.	Сокращение прибыли.	Экономия на качестве предоставляемых услуг.	2	3	5

Таким образом, было выделена два наиболее опасных риска для деятельности предприятия, такие как: недостаток финансирования и недополучение планируемых объемов прибыли. Для того, что минимизировать наступление рисковых ситуаций, необходимо рассмотреть некоторые методы защиты. Так, в случае недостатка финансирования целесообразно продумать дополнительные источники возможного привлечения прибыли, которые могут быть использованы в случае непредвиденных ситуаций. В случае с недополучением планируемых объемов прибыли, возможно расширение функциональности приложения, а также введение партнерских программ с другими проектами, для привлечения пользователей и мотивации скачивания приложения.