РАСЧЕТ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ МОБИЛЬНОГО ПРИЛОЖЕНИЯ
Оценка рисков разработки мобильных приложений
Постановка задачи:
Требуется дать количественную оценку истинности экспертного заключения об оценки рисков мобильного приложения СКБ-банк.
Введем лингвистическую переменную g – ОЦЕНКА РИСКОВ РАЗРАБОТКИ МОБИЛЬНОГО ПРИЛОЖЕНИЯ.
G1 – предельно низкий уровень рисков при разработки мобильного приложения
…
G5 - очень высокий уровень рисков при разработки мобильного приложения
Вам потребуется:
| Терм Gk | Функция принадлежности нечеткого множества Gk |
| G5 –очень низкий уровень риска G5Î[0;0,25] | 
|
| G4 – низкий уровень риска G4Î[0,15;0,45] | 
|
| G3 – средний уровень риска G3Î[0,35;0,65] | 
|
| G2 –высокий уровень риска G2Î[0,55;0,85] | 
|
| G1 - предельно высокий уровень риска G1Î[0,75;1] | 
|
Полученное значение функции принадлежности – это значение функции истинности терма Gi.
Заключение о рисках при разработки мобильного приложения будем делать на основе показателей рисков. Это Х1 ……
Справка:
Любой проект, связанный с разработкой мобильных приложений имеет риски. Риски можно классифицировать на несколько категорий, в зависимости от характера проекта.
1) Кадры: нехватка или текучесть команды проекта. Этот риск может привести к задержке сроков.
2) Знания: команда может иметь лишь узконаправленные знания, или неверно передавать между собой информацию. В этом случае членам команды приходится переучиваться, что приводит к дополнительным тратам сил, времени и ресурсов.
|
|
|
3) Продуктивность: этот риск может негативным образом сказаться при долгосрочных проектах. Из-за большого промежутка времени жизненного цикла проекта, участники проекта могут непродуктивно проводить разработку.
4) Бюджет: различные несогласования могут привести к увеличению бюджета. Для устранения это проблемы следует проводить планирование методом «набегающей волны». Этот метод позволяет команде принимать решения по продукту по мере продвижения работы, вместо того, чтобы разрабатывать подробнейший план действий на самом старте проекта. Таким образом, проект разбивается на подэтапы – спринты, цель которых заключается в создании Демо-версии продукта в заданные сроки. Это придает разработчикам уверенность в правильности создания продукта, и позволяет придерживаться нужной скорости выполнения задачи.
Определим риски проекта.
1. Разработчик завершил серверную часть и отдал ее TeamLeadу на просмотр кода. Код был неудовлетворительного качества, поэтому TeamLead вернул его на доработку. Соответственно это приведет к расширению временных границ.
2. Могут обнаружить ошибку разработчики мобильных приложений. Произойдет расширение временных границ проекта.
|
|
|
3. UX продумана не до конца Дизайнер не учел те или иные бизнес-процессы. В последующем это приведет к тому, что срок выполнения задачи увеличится.
4. Аналитик когда писал техническое задание мобильному разработчику, не учел некоторые бизнес-процессы, вследствие чего возникает необходимость пересмотра структуры приложения и его необходимо доработки.
5. Неодновременное завершение задач разработчиками разных платформ. Прежде чем разместить задачу в релиз должен быть готов модуль для всех платформ. Разные сроки готовности приводят к простоям.
Рассмотрим, например, конкретный риск: – при разработке модуля «выписка по карте на ленте» произошла задержка сроком на неделю из-за неправильной структурированности бизнес-процессов дизайнером. Разработчикам программного обеспечения необходимо было переписывать код. Таким образом, стоимость от базового плана была увеличена на 34 844 рубля.
Таблица 1 – Стоимость проекта с учетом риска «Задержка сроков сдачи проекта»
| Участник проекта | Количество часов | сумма |
| UX–дизайнер и графический дизайнер | 16х600 | 9600 |
| Мобильный разработчик Junior | 16x165 | 2640 |
| Мобильный разработчик Middle | 16x326 | 5216 |
| Мобильный разработчик Seniore | 16x815 | 13040 |
| Аналитик | 4x272 | 1088 |
| Team Lead | 4x815 | 3260 |
| итого | 34 844 |
Для исправления ошибок в приложении потребовалось:
|
|
|
Два дня рабочего времени дизайнера + 2 дня рабочего времени программистов + 1 день рабочего времени аналитика и 1 день рабочего времени TeamLead).
Сведем оценки рисков проекта, данные аналитиками. Оценка дана по шкале от 0 до 1, где 0 – отсутствие риска, 1 – очень высокая доля риска.
| Риск (Х1 ….) | Причина | Оценка аналитиков |
| Неверная структурированность бизнес-процессов дизайнером | 0,3 | |
| Неодновременное завершение задач разработчиками разных платформ | разная продуктивность работы разработчиков | 0,5 |
| Увеличение требований со стороны заказчика в ходе реализации проекта | изменение и-за длительности выполнения заказа | 0,4 |
| Текучка кадров | большая загруженность, дискомфорт среды | 0,3 |
| Нарушение спецификаций | недостаточное согласование | 0,1 |
| Низкая производительность | отсутствие разбивки проекта на короткие этапы | 0,4 |
| Увеличение времени сдачи проекта | задержки релизов продукции | 0,2 |
Далее Вы составляете таблицу экспертных оценок термов Bij
|
|
|
Таблицу значений функции принадлежности µ.
Веса термов ri= примите равнозначным.
Создайте таблицу «Расчет веса терм-множества»
Проведите расчеты и найдите значения функции принадлежности µk(g).
Сделайте выводы.
Каждое вычисление должно сопровождаться описанием, которое Вы проводите в Worde.
Вариант 2
РАСЧЕТ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ МОБИЛЬНОГО ПРИЛОЖЕНИЯ
Постановка задачи:
Требуется дать количественную оценку истинности экспертного заключения об эффективности разработки мобильного приложения СКБ-банк.
Введем лингвистическую переменную g – ОЦЕНКА ЭФФЕКТИВНОСТИ РАЗРАБОТКИ МОБИЛЬНОГО ПРИЛОЖЕНИЯ.
G1 – предельно низкий уровень эффективности разработки мобильного приложения
…
G5 - очень высокий уровень эффективности разработки мобильного приложения
Вам потребуется:
| Терм Gk | Функция принадлежности нечеткого множества Gk |
| G5 –очень низкая эффективность G5Î[0;0,25] |
|
| G4 - низкая эффективность G4Î[0,15;0,45] |
|
| G3 – средняя эффективность G3Î[0,35;0,65] |
|
| G2 –высокая эффективность G2Î[0,55;0,85] |
|
| G1 - предельно высокая эффективность G1Î[0,75;1] |
|
Полученное значение функции принадлежности – это значение функции истинности терма Gi.
Заключение об эффективности разработки мобильного приложения будем делать на основе показателей рисков. Это метрики (Х1 ……)
Дата добавления: 2020-04-08; просмотров: 90; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!