Определение проблемы
1.1 Представить финальную формулировку проблемы (1 предложение) и
показать, как она соответствует необходимым характеристикам (Важность,
Общий интерес, Сложность, Ясность, Решаемость)
Проблема: Как повысить удовлетворенность и лояльность пользователей
мобильного приложения с помощью методологии дизайн-мышления?
Характеристики:
● Важность: Проблема важна для разработчиков мобильных приложений,
которые хотят улучшить свою конкурентоспособность и репутацию на
рынке, а также для заказчиков, которые хотят увеличить доходы и
удержание пользователей.
● Общий интерес: Проблема интересна не только для локальной, но и
для глобальной практики, так как дизайн-мышление является одной из
самых популярных и инновационных методологий разработки в
современном мире, а мобильные приложения — одной из самых
динамичных и конкурентных областей цифрового продуктового
дизайна12.
● Сложность: Проблема сложна, так как требует не только творческих, но
и аналитических знаний и навыков, а также умения учитывать множество
факторов, которые влияют на удовлетворенность и лояльность
пользователей, таких как функциональность, юзабилити, эстетика,
эмоции, ценность и т.д.
● Ясность: Проблема ясна, так как имеет четкую цель — повысить
удовлетворенность и лояльность пользователей мобильного приложения
с помощью методологии дизайн-мышления — и четкие объекты —
дизайн-мышление, мобильное приложение и пользовательский опыт.
Проблема также может быть проверена с помощью различных
инструментов, таких как тесты, опросы, аналитика, отзывы и т.д.
● Решаемость: Проблема решаема, так как существуют методы и техники,
которые помогают применять дизайн-мышление для повышения
удовлетворенности и лояльности пользователей, такие как сегментация,
персонификация, сценарии, карты путешествий, прототипирование,
тестирование и т.д. Проблема также может быть разбита на более
мелкие и конкретные подпроблемы, такие как определение целевых
групп пользователей, исследование их потребностей и ожиданий,
разработка идей и решений, прототипирование, тестирование и т.д.
1.2 Определите причины возникновения проблемы и взаимосвязи между ними.
Представьте результаты в виде диаграммы (диаграмма Исикавы или другая)
1.3 Определите класс проблемы (из списка или другой, но такого же уровня
абстракции), аргументируйте свой выбор
Переформулировка текста для вашей темы:
Наиболее подходящим классом проблемы из списка, сформированного в
ходе работы над проектом, является "Анализ проблем" или "Системный
анализ". Результатом такого анализа обычно являются алгоритмы принятия
решений или решения, основанные на системном подходе.
Этот выбор обуславливается тем, что целевой вариант решения
проблемы представляет собой алгоритм принятия решений. Используя
предиктивные (прогнозируемые) интенсивности эмоций, этот алгоритм будет
помогать стейкхолдерам (заинтересованным сторонам) делать выбор в пользу
той или иной стратегии.
Определить стратегии и методы исследования для Этапа Определение
проблемы
2.1 Укажите связки: Цель (какую информацию хотим получить) - Стратегия –
Метод сбора данных – Метод анализа данных (используйте изученные
стратегии и методы или укажите ссылку на источник). Поясните выбор.
2.1.1. Цель: Понять потребности и ожидания пользователей.
Стратегия: Провести интервью с пользователями.
Метод сбора данных: Глубинные интервью.
Метод анализа данных: Тематический анализ.
● Глубинные интервью позволяют получить подробную информацию о
потребностях и ожиданиях пользователей.
● Тематический анализ позволяет выявить основные темы и категории,
которые возникают в ответах пользователей.
2.1.2. Цель: Оценить эффективность прототипа приложения.
Стратегия: Провести A/B-тестирование.
Метод сбора данных: Аналитические инструменты.
Метод анализа данных: Сравнительный анализ.
● A/B-тестирование позволяет сравнить два варианта дизайна и
определить, какой из них более эффективен.
● Сравнительный анализ позволяет выявить statistically significant
differences между двумя вариантами дизайна.
2.1.3. Цель: Собрать отзывы пользователей о приложении.
Стратегия: Провести опрос пользователей.
Метод сбора данных: Анкетирование.
Метод анализа данных: Статистический анализ.
● Анкетирование позволяет собрать количественные данные о том, как
пользователи воспринимают приложение.
● Статистический анализ позволяет выявить закономерности и сделать
выводы о пользовательском опыте.
Анализ литературы (решений-аналогов): найти несколько статей,
проанализировать 3 или более (вес 4%)
3.1 Указать результаты анализа в виде таблицы рекомендованного формата со
ссылками на источники
Ссылки:
1) https://rugraphics.ru/blogs/dizajn-mobilnyh-prilozhenij
2) https://appmaster.io/ru/blog/rukovodstvo-po-proektirovaniiu-mobil-nykh-prilozhenii
3) https://www.andromo.com/ru/blog/how-to-prototype-mobile-apps/
3.2 Указать обнаруженные в ходе анализа литературы пробелы в
исследованиях (research gap)
● Отсутствие исследований по применению дизайн-мышления
● Недостаточная оценка этических аспектов. Я имею введу, что при
разработке приложения для определенной группы людей очень важно
учитывать и их особенности
3.4 Сделать краткий вывод о важности рассматриваемой проблемы для
глобальной практики (исходя из анализа литературы) - 3-5 кратких тезисов
1. Повышение доступности и инклюзивности:
● Дизайн-мышление позволит создавать приложения, удобные для людей
с инвалидностью, пожилых людей, детей Это увеличивает охват
аудитории и делает приложения более инклюзивными.
2. Улучшение user experience и engagement:
● Дизайн-мышление поможет создавать приложения, которые учитывают
культурные факторы, что делает их более удобными и понятными для
пользователей из разные культуры.
3. Повышение долгосрочной эффективности:
● Дизайн-мышление позволит создавать приложения, которые не только
решают сиюминутные задачи, но и учитывают долгосрочные цели.
4. Стимулирование инноваций:
● Дизайн-мышление позволит создавать новые, нестандартные решения,
которые могут изменить рынок мобильных приложений.
● Это приведет к появлению новых продуктов и услуг, которые улучшают
жизнь людей.
4. Сформулируйте 5 или более вопросов, которые вы понетциально
хотели бы задать стейкхолдерам (в рамках опроса или интервью) на
этапе Определение проблемы.
5. Оценить сложность решения, которое вы предлагаете (вес 4%)
5.1 Уровень результата/вклада в сообщество, аргументируйте свой
выбор
Сложность предлагаемого решения:
● Средняя (3 из 5)
Аргументы:
● Решение основано на общедоступных методах и инструментах:
дизайн-мышление, UX/UI дизайн, agile-разработка.
● Решение не требует разработки принципиально новых технологий:
используются уже существующие технологии.
● Решение может быть реализовано в рамках ограниченного бюджета:
разработка приложения может быть выполнена небольшой командой.
● Решение может быть реализовано в ограниченные сроки:
разработка приложения может быть выполнена в течение нескольких
месяцев.
Некоторые факторы, которые могут увеличить сложность:
● Необходимость учета конкретной целевой аудитории: приложение
должно быть удобным и понятным для людей с disabilities, пожилых
людей, детей, людей с особенностями
● Необходимость обеспечения долгосрочной эффективности:
приложение должно быть не только актуальным в краткосрочной
перспективе, но и сохранять свою актуальность в долгосрочной
перспективе.
● Необходимость этической оценки: необходимо провести этическую
оценку приложения, чтобы исключить его использование для плохих
целей как булинг
Уровень результата/вклада в сообщество:
● Средний (3 из 5)
Аргументы:
● Решение может улучшить качество жизни людей: приложение может
помочь людям с инвалидностью, пожилым людям, детям
● Решение может повысить уровень инклюзивности: приложение
может сделать мобильные приложения более доступными для людей из
разных культур
● Решение может стимулировать инновации: приложение может стать
стимулом для разработки новых мобильных приложений, решающих
социальные проблемы
Некоторые факторы, которые могут уменьшить уровень
результата/вклада:
● Необходимость дальнейших исследований: необходимо провести
будущую проверку, чтобы подтвердить эффективность предлагаемого
решения.
● Необходимость масштабирования: необходимо разработать план
масштабирования решения, чтобы оно могло быть применено к другим
приложениям.
5.2 Вид предполагаемого артефакта (с указанием источника, откуда была
взята классификации), аргументируйте свой выбор
Вид артефакта: модель
Вид предполагаемого артефакта: Модель
Обоснование:
1. Название: Название изображения - "The Design Thinking Process"
("Процесс дизайн-мышления"). Это говорит о том, что изображение
представляет собой модель, описывающую этапы и компоненты
дизайн-мышления.
2. Структура: Изображение содержит визуальную структуру, состоящую из
блоков, стрелок и текста. Эта структура отражает взаимосвязь между
этапами и компонентами дизайн-мышления.
3. Описание: Текст на изображении поясняет каждый этап и компонент
дизайн-мышления, предоставляя краткое описание их функций и целей.
4. Цель: Дизайн-мышление - это методология, направленная на решение
проблем. Изображение представляет собой модель, которая помогает
людям использовать эту методологию.
5.4 Почему и каким образом этот артефакт решит проблему? – дать
развернутый ответ
1. Эмпатия:
Понимание пользователей: Модель дизайн-мышления побуждает исследовать
потребности, желания и проблемы пользователей приложения
Сбор информации: может использовать различные методы, такие как опросы,
интервью, анализ данных, чтобы собрать информацию о пользователях.
Создание эмпатии: может создать персоны пользователей, чтобы лучше понять
их мотивацию, цели и трудности.
2. Определение:
Формулировка проблемы: Модель дизайн-мышления помогает четко
сформулировать проблему, которую хотите решить.
Анализ проблемы: может использовать методы, такие как "5 почему", чтобы
глубже понять причины проблемы.
3. Генерация идей:
Творческий подход: Модель дизайн-мышления побуждает думать творчески и
придумывать инновационные решения проблемы.
Мозговой штурм: может использовать различные методы генерации идей, такие
как мозговой штурм, эскизирование, SCAMPER.
Прототипирование: может создавать прототипы вашего веб-сайта, чтобы
быстро и дешево протестировать различные идеи.
4. Прототипирование:
Создание прототипа: Модель дизайн-мышления побуждает создавать прототип
вашего решения для тестирования его с пользователями.
Тестирование прототипа: может использовать различные методы тестирования,
такие как A/B-тестирование, чтобы получить обратную связь пользователей о
вашем прототипе.
5. Тестирование:
Получение обратной связи: Модель дизайн-мышления побуждает получать
обратную связь от пользователей по поводу вашего прототипа и вносить
изменения в свое решение.
Улучшение решения: может использовать полученную обратную связь для
улучшения своего прототипа и делать его более удобным для пользователей.
5 Какие из обнаруженных пробелов в исследованиях (пробелы в знаниях)
потенциально мог бы заполнить предлагаемый артефакт?
1. Недостаток информации о применении дизайн-мышления в
определенных целевых аудиториях:
● Люди с ограниченными возможностями: Модель дизайн-мышления
может быть адаптирована для использования людьми с ограниченными
возможностями, что позволит им участвовать в процессе разработки
продуктов и услуг.
● Пожилые люди: Модель дизайн-мышления может быть использована
для разработки продуктов и услуг, которые будут более удобными для
пожилых людей.
● Дети: Модель дизайн-мышления может быть использована для
разработки продуктов и услуг, которые будут более привлекательными и
интересными для детей.
● Люди с определенными медицинскими показаниями: Модель
дизайн-мышления может быть использована для разработки продуктов и
услуг, которые будут учитывать потребности людей с определенными
медицинскими показаниями.
2. Недостаток исследований о применении дизайн-мышления в
различных культурах:
● Модель дизайн-мышления может быть адаптирована к различным
культурам, что позволит ей быть более эффективной в разных
контекстах.
● Исследования могут показать, как дизайн-мышления может быть
использовано для решения проблем, специфичных для различных
культур.
3. Недостаток информации о долгосрочной эффективности
дизайн-мышления:
● Необходимы исследования, чтобы показать, как дизайн-мышления может
быть использовано для создания продуктов и услуг, которые будут иметь
долгосрочный эффект.
● Исследования могут показать, как дизайн-мышления может быть
использовано для создания устойчивых решений.
4. Необходимость этической оценки дизайн-мышления:
● Необходимы исследования, чтобы показать, как дизайн-мышления может
быть использовано этично.
● Исследования могут показать, как дизайн-мышления может быть
использовано для предотвращения вреда.
5. Необходимость разработки методологии оценки дизайн-мышления:
● Необходима методология для оценки эффективности дизайн-мышления.
● Методология должна быть разработана таким образом, чтобы она была
надежной и достоверной.
2. Определение задач решения / требований
1.1 Укажите связки: Цель (какую информацию хотим получить) - Стратегия
– Метод сбора данных – Метод анализа данных (используйте изученные
стратегии и методы или укажите ссылку на источник). Поясните выбор.
Цель: Определение функциональных и нефункциональных требований к
решению.
Стратегия: Анализ проблемной области.
Методы сбора данных:
● Обзор литературы: Изучение научных статей, книг, отчетов и других
источников информации, посвященных проблеме, которую необходимо
решить.
● Интервью с экспертами: Проведение интервью с людьми,
обладающими знаниями и опытом в области, релевантной к проблеме.
● Анализ существующих решений: Изучение существующих решений
подобных проблем, чтобы понять их сильные и слабые стороны .
Методы анализа данных:
● SWOT-анализ: Анализ сильных и слабых сторон, возможностей и
угроз (strengths, weaknesses, opportunities and threats), связанных с
решением проблемы.
● Составление карты требований: Определение функциональных и
нефункциональных требований к решению.
Пояснение:
● Анализ проблемной области: Это важный этап исследования, который
позволяет понять суть проблемы, ее причины и следствия.
● Обзор литературы: Эффективный способ получить информацию о
существующих методах решения проблемы.
● Интервью с экспертами: Возможность получить ценную информацию и
советы от людей, которые имеют опыт решения подобных проблем.
● Анализ существующих решений: Возможность избежать ошибок,
которые были допущены другими разработчиками.
● SWOT-анализ: Эффективный метод оценки сильных и слабых сторон,
возможностей и угроз , связанных с решением проблемы.
● Составление карты требований: Важный документ, который
определяет функциональные и нефункциональные требования к
решению.
Цель: Определение потребностей пользователей.
Стратегия: Изучение пользователей.
Методы сбора данных:
● Опросы: Проведение опросов пользователей, чтобы узнать их
потребности, желания и предпочтения.
● Интервью с пользователями: Проведение интервью с пользователями,
чтобы получить более подробную информацию о их потребностях и
проблемах.
● Анализ пользовательских сценариев: Изучение того, как пользователи
будут использовать решение.
Методы анализа данных:
● Анализ данных опросов: С помощью статистического анализа можно
сделать выводы о потребностях пользователей.
● Анализ результатов интервью: Интервью с пользователями
предоставляют качественные данные (provide qualitative data),
которые могут быть проанализированы с помощью таких методов, как
тематический анализ (thematic analysis).
● Создание user personas: Создание обобщенных образов
пользователей, которые помогут понять их потребности и мотивацию.
Пояснение:
● Изучение пользователей: Это важный этап исследования, который
позволяет понять потребности пользователей и разработать решение,
которое будет им максимально полезно.
● Опросы: Эффективный способ получить количественные данные
(quantitative data) о потребностях пользователей.
● Интервью с пользователями: Возможность получить качественные
данные (qualitative data) о потребностях пользователей.
● Анализ пользовательских сценариев: Возможность понять, как
пользователи будут использовать решение.
● Анализ данных опросов: Возможность сделать выводы о потребностях
пользователей.
● Анализ результатов интервью: Возможность понять потребности и
мотивацию пользователей.
● Создание user personas: Эффективный метод, который помогает
разработчикам понять потребности пользователей.
Цель: Определение ограничений и возможностей решения.
Стратегия: Анализ технических и экономических аспектов.
Методы сбора данных:
● Оценка технических возможностей: Оценка существующих
технологий и ресурсов , которые могут быть использованы для
разработки решения.
● Оценка экономических факторов: Оценка затрат и выгод
Проанализируйте требования артефактов-аналогов (на основе 2-3 источников),
представьте результаты в виде таблицы: (вес 2,5%)
Источни Артефакт
Вид
Требован Вид
Комментар
к
артефакт ие
требования
ий
а
Процесс
Тестирование Тестиров Приложен Нефункциона Этот
разработ производитель ание
ие должно льное
источник
ки
ности и
работать
требование
может быть
дизайна
безопасности
быстро и
полезен,
мобильно приложения
надежно,
чтобы
го
для
чтобы
понять, как
приложен онлайн-банкин
пользоват
тестироват
ия с нуля га
ели не
ь свой
испытывал
дизайн и
и
устранять
задержек
возможные
или сбоев
ошибки или
при
уязвимости
совершени
и
финансов
ых
операций
Дизайн
Анимация с
Анимаци Пользоват Пользователь Этот
мобильн переходами
я
ели
ское
источник
ых
между
должны
требование
может быть
приложен экранами для
чувствоват
полезен,
ий: как
приложения по
ь себя
чтобы
применят обмену
вовлеченн
понять, как
ь
фотографиями
ыми в
применять
методоло
процесс
методологи
гию
обмена
ю
дизайн-м
фотограф
дизайн-мы
ышления
иями, видя
шления на
плавные и
всех этапах
эстетичны
проектиров
е
ания
переходы
приложени
между
я
экранами
Как
Экран с
Поиск и
Пользоват Функциональ Этот
создать
выбором
фильтр
ели
ное
источник
прототип категории,
должны
требование
может быть
мобильно поиском и
иметь
полезен,
го
фильтрами
возможнос
чтобы
приложен для
ть легко
понять, как
ия:
приложения по
находить и
создавать
пошагово доставке еды
заказыват
прототипы
е
ь еду из
своих идей
разных
и получать
руководс
тво
ресторано
в,
используя
удобный
интерфейс
обратную
связь от
потенциаль
ных
пользовате
лей
3. Выделите требования и гипотезы на основе исследуемой проблемы,
представьте результаты в виде таблицы: (вес 2,5%)
4. Описать схему артефакта
4.1. Структура, функции, ожидаемые и побочные эффекты артефакта
Структура:
● Интерфейс: Пользовательский интерфейс для взаимодействия с
артефактом.
● Модуль обработки данных: Ответственный за сбор, обработку и
анализ данных.
● Модуль управления: Ответственный за управление артефактом и его
функциями.
● Модуль хранения данных: Хранилище для данных, собранных
артефактом.
● База знаний: Хранилище знаний о предметной области.
Функции:
● Сбор данных: Сбор данных из различных источников, таких как датчики,
базы данных и веб-сервисы.
● Обработка данных: Очистка, преобразование и анализ данных.
● Визуализация данных: Предоставление данных в удобном для
пользователя формате.
● Управление артефактом: Конфигурирование, мониторинг и обновление
артефакта.
Ожидаемые эффекты:
● Повышение эффективности: Автоматизация рутинных задач.
● Улучшение качества решений: Поддержка принятия решений на основе
данных.
● Снижение рисков: Выявление и предотвращение потенциальных
проблем.
● Повышение удовлетворенности пользователей: Предоставление
пользователям удобного и функционального инструмента.
Побочные эффекты:
● Повышение требований к безопасности: Необходимость защиты
данных от несанкционированного доступа.
● Увеличение нагрузки на инфраструктуру: Необходимость в
дополнительных ресурсах для хранения и обработки данных.
● Изменение бизнес-процессов: Необходимость адаптации
бизнес-процессов к работе с артефактом.
4.2. Взаимодействие с локальной практикой/целевой системой
Описание:
● Интерфейс: Пользователи локальной практики/целевой системы
взаимодействуют с артефактом через пользовательский интерфейс.
● Модуль обработки данных: Артефакт получает данные из локальной
практики/целевой системы через модуль обработки данных.
● Модуль управления: Артефакт управляет своими функциями и
взаимодействует с локальной практикой/целевой системой через модуль
управления.
● Модуль хранения данных: Артефакт хранит данные, полученные из
локальной практики/целевой системы, в модуле хранения данных.
● База знаний: Артефакт использует базу знаний для обработки данных и
предоставления информации локальной практике/целевой системе.
Связи:
● Интерфейс:
○ Локальная практика/целевая система: Предоставляет данные и
команды артефакту.
○ Артефакт: Предоставляет информацию и функции локальной
практике/целевой системе.
● Модуль обработки данных:
○ Локальная практика/целевая система: Получает данные из
локальной практики/целевой системы.
○ Артефакт: Предоставляет обработанные данные артефакту.
● Модуль управления:
○ Локальная практика/целевая система: Получает команды от
локальной практики/целевой системы.
○ Артефакт: Управляет функциями артефакта.
● Модуль хранения данных:
○ Локальная практика/целевая система: Предоставляет место для
хранения данных артефакту.
○ Артефакт: Хранит данные, полученные из локальной
практики/целевой системы.
● База знаний:
○ Локальная практика/целевая система: Предоставляет знания о
предметной области артефакту.
○ Артефакт: Использует знания о предметной области для
обработки данных и предоставления информации локальной
практике/целевой системе.
5. Укажите финальный список низкоуровневых требований – не менее 10
требований (как функциональные, так и нефункциональные) (вес 2,5%)
5.1 Укажите четкую формулировку, тип, обоснование и источник для
каждого требования (на источник всегда нужно указывать ссылку)
формулировка
Система должна
предоставлять
пользователям
возможность
авторизоваться в
системе.
Система должна
предоставлять
пользователям
тип
описание
Функциональное
Необходима возможность
разграничения доступа к
функциям системы.
Функциональное
Пользователи должны
иметь возможность
корректировать свою
возможность изменять
свой профиль.
Система должна
предоставлять
пользователям
возможность добавлять
новые элементы.
личную информацию.
Функциональное
Система должна
поддерживать
добавление новых
данных.
Функциональное
Пользователи должны
иметь возможность
корректировать
существующие данные.
Функциональное
Пользователи должны
иметь возможность
удалять ненужные
данные.
Функциональное
Пользователи должны
иметь возможность
быстро находить
необходимые данные.
Система должна
предоставлять
пользователям
возможность сортировки
элементов.
Функциональное
Пользователи должны
иметь возможность
упорядочивать данные
для удобства.
Система должна
предоставлять
пользователям
возможность фильтрации
элементов.
Функциональное
Пользователи должны
иметь возможность
отбирать данные по
заданным критериям.
Система должна быть
безопасной.
Нефункциональное, к
безопасности
Необходимо защитить
данные пользователей от
несанкционированного
доступа.
Система должна быть
производительной.
Нефункциональное, к
производительности
Система должна
работать быстро и без
Система должна
предоставлять
пользователям
возможность
редактировать
существующие
элементы.
Система должна
предоставлять
пользователям
возможность удалять
элементы.
Система должна
предоставлять
пользователям
возможность поиска по
элементам.
задержек.
Система должна быть
масштабируемой.
Система должна быть
удобной в
использовании.
Нефункциональное, к
масштабируемости
Система должна
поддерживать
увеличение количества
пользователей и данных.
Нефункциональное, к
удобству использования
Интерфейс системы
должен быть понятным и
простым для
пользователей.
5.2Покажите связь функциональных требований с описанными
функциями артефакта. Покажите связь нефункциональных требований со
структурой и ожидаемыми эффектами артефакта
Формулировка
Связанные функции артефакта
Система должна предоставлять
пользователям возможность
авторизоваться в системе.
Интерфейс, Модуль обработки данных
Система должна предоставлять
пользователям возможность изменять
свой профиль.
Интерфейс, Модуль хранения данных
Система должна предоставлять
пользователям возможность
добавлять новые элементы.
Интерфейс, Модуль обработки
данных, Модуль хранения данных
Система должна предоставлять
пользователям возможность
редактировать существующие
элементы.
Интерфейс, Модуль обработки
данных, Модуль хранения данных
Система должна предоставлять
пользователям возможность удалять
элементы.
Интерфейс, Модуль обработки
данных, Модуль хранения данных
Система должна предоставлять
пользователям возможность поиска по
элементам.
Интерфейс, Модуль обработки данных
Система должна предоставлять
пользователям возможность
сортировки элементов.
Интерфейс, Модуль обработки данных
Система должна предоставлять
пользователям возможность
фильтрации элементов.
Интерфейс, Модуль обработки данных
6.1 Целесообразность создания артефакта
Ответ: Создание артефакта, соответствующего заявленным требованиям,
целесообразно.
Обоснование:
● Анализ требований:
○ Функциональные требования: Артефакт способен выполнять
все заявленные функциональные требования, такие как
авторизация пользователей, управление профилями, добавление,
редактирование и удаление элементов, поиск, сортировка и
фильтрация.
○ Нефункциональные требования: Артефакт может быть
реализован с учетом требований к безопасности,
производительности, масштабируемости и удобству
использования.
● Оценка ожидаемых эффектов:
○ Повышение эффективности: Автоматизация рутинных задач
позволит повысить эффективность работы пользователей.
○ Улучшение качества решений: Артефакт будет предоставлять
пользователям доступ к информации и аналитике, что поможет им
принимать более обоснованные решения.
○ Снижение рисков: Артефакт поможет выявить и предотвратить
потенциальные проблемы.
○ Повышение удовлетворенности пользователей:
Предоставление удобного и функционального инструмента
повысит удовлетворенность пользователей.
● Оценка ресурсов:
○ Время: Разработка артефакта потребует значительных временных
затрат.
○ Стоимость: Разработка артефакта потребует значительных
финансовых затрат.
○ Персонал: Для разработки артефакта потребуется команда
qualified специалистов.
Вывод:
Несмотря на значительные временные, финансовые и кадровые затраты,
создание артефакта оправдано его потенциальными преимуществами.
Дополнительные соображения:
● Оценка рисков: Перед принятием окончательного решения о разработке
артефакта необходимо провести detailed оценку рисков, связанных с его
реализацией.
● Анализ альтернатив: Необходимо рассмотреть альтернативные
варианты решения проблемы, например, использование существующих
инструментов или разработка более простой версии артефакта.
3. Дизайн и Разработка
Генерация идей для дизайна и разработки артефакта
1.1 Определение цели и методов генерации идей
Цель:
● Сгенерировать идеи для дизайна и разработки артефакта, который будет
соответствовать заявленным требованиям.
Методы:
● Мозговой штурм: Групповая генерация идей без критики.
● Метод фокальных объектов: Присвоение случайных характеристик
объекту для генерации новых идей.
● Метод SCAMPER: Изменение объекта по семи параметрам (Subject,
Combine, Adapt, Modify, Put to another use, Eliminate, Reverse).
● Анализ аналогов: Изучение существующих решений для similar задач.
1.2 Описание процесса генерации идей
Блок-схема:
Изображение блок-схемы: [неправильный URL удален]
Описание:
1. Определение цели и методов.
2. Мозговой штурм: Группа специалистов генерирует идеи без критики.
3. Метод фокальных объектов: Выбирается случайный объект, его
характеристики переносятся на артефакт.
4. Метод SCAMPER: Изменение артефакта по семи параметрам.
5. Анализ аналогов: Изучение существующих решений.
6. Отбор и оценка идей: Выбор наиболее перспективных идей.
7. Доработка идей: Развитие и конкретизация выбранных идей.
1.3 Результаты генерации идей:
1. Дизайн:
● Модульный дизайн: Артефакт будет состоять из модулей, которые
можно будет легко добавлять, удалять и заменять.
● Интуитивно понятный интерфейс: Интерфейс артефакта будет
простым и понятным для пользователей.
● Адаптивный дизайн: Интерфейс артефакта будет адаптироваться к
различным устройствам.
2. Разработка:
● Использование open-source frameworks: Разработка артефакта будет
основана на open-source frameworks, что позволит ускорить процесс
разработки и снизить расходы.
● Agile-методология: Разработка артефакта будет вестись по
Agile-методологии, что позволит повысить гибкость и адаптивность к
изменениям.
● Тестирование: Артефакт будет тщательно тестироваться на всех этапах
разработки.
3. Дополнительные идеи:
● Использование искусственного интеллекта: Использование ИИ для
автоматизации некоторых функций артефакта.
● Интеграция с другими системами: Интеграция артефакта с другими
системами для повышения функциональности.
● Создание сообщества пользователей: Создание сообщества
пользователей для обмена опытом и идеями.
Оценка и выбор идей
2.1 Описание методов оценки и выбора идей
Методы:
● Метод балльной оценки: Каждой идее присваивается балл по
нескольким критериям.
● Метод SWOT-анализа: Анализ сильных и слабых сторон, возможностей
и угроз каждой идеи.
● Метод голосования: Идеи оцениваются и выбираются путем
голосования.
Критерии оценки:
● Соответствие требованиям: Насколько идея соответствует заявленным
требованиям.
● Оригинальность: Насколько идея нова и оригинальна.
● Реализуемость: Насколько легко и быстро можно реализовать идею.
● Эффективность: Насколько эффективной будет реализация идеи.
● Стоимость: Сколько будет стоить реализация идеи.
2.2 Описание процесса оценки и выбора идей
Описание:
1. Формирование списка идей: Список идей, полученных в результате
генерации.
2. Оценка идей: Оценка идей по выбранным критериям.
3. SWOT-анализ: Анализ сильных и слабых сторон, возможностей и угроз
каждой идеи.
4. Голосование: Голосование за наиболее перспективные идеи.
5. Выбор идей: Выбор 1-2 идей для реализации.
2.3 Результаты оценки и выбора идей:
В результате оценки и выбора идей были выбраны следующие идеи:
● Модульный дизайн: Артефакт будет состоять из модулей, которые
можно будет легко добавлять, удалять и заменять.
● Использование Agile-методологии: Разработка артефакта будет
вестись по Agile-методологии, что позволит повысить гибкость и
адаптивность к изменениям.
Эти идеи были выбраны, потому что:
● Они соответствуют всем заявленным требованиям.
● Они являются оригинальными и новыми.
● Они реализуемы и эффективны.
● Их реализация будет иметь приемлемую стоимость.
Функции и структура артефакта
3.1 Описание методов/подходов
Для описания функций и структуры артефакта будут использоваться
следующие методы:
● Декомпозиция: Разделение артефакта на подсистемы и компоненты.
● Моделирование: Использование UML-диаграмм для описания
структуры и поведения артефакта.
● Описание функциональности: Описание функций каждого компонента
артефакта.
3.2 Описание компонентов
Компонент
Цель
компонента
Функциональность
Структура
Интерфей
Обеспечить
Предоставление
- Графический
с
взаимодейств
пользователю
интерфейс
ие
возможности:
пользователя
пользователя
<br>-
(GUI). - Модуль
с артефактом.
Авторизоваться в
обработки
системе. <br>-
пользовательских
Изменять свой
действий.
профиль. <br>Добавлять,
редактировать и
удалять элементы.
<br>- Поиск,
сортировка и
фильтрация
элементов.
Модуль
Обработка и
- Сбор данных из
- Модуль сбора
обработк
анализ
различных
данных. - Модуль
и данных
данных.
источников. -
хранения
Хранение данных.
данных. - Модуль
- Обработка
обработки
данных. - Анализ
данных. - Модуль
данных. -
аналитики.
Предоставление
результатов
обработки и
анализа данных.
Модуль
Управление
- Контроль
- Модуль
управлен
артефактом и
доступа к
аутентификации
ия
его
функциям
и авторизации. -
функциями.
артефакта. -
Модуль
Настройка
конфигурировани
параметров
я. - Модуль
артефакта. -
обновления.
Обновление
артефакта.
Модуль
Хранение
- Хранение
- База данных. -
хранения
данных,
данных
Файловая
данных
используемых
пользователей. -
система.
артефактом.
Хранение
элементов. Хранение
результатов
обработки и
анализа данных.
Обоснование:
● Интерфейс: Необходим для взаимодействия пользователя с
артефактом.
● Модуль обработки данных: Необходим для сбора, хранения, обработки
и анализа данных.
● Модуль управления: Необходим для управления артефактом и его
функциями.
● Модуль хранения данных: Необходим для хранения данных,
используемых артефактом.
Использованные идеи:
● Модульный дизайн: Артефакт состоит из модулей, которые можно
легко добавлять, удалять и заменять.
● Использование Agile-методологии: Разработка артефакта будет
вестись по Agile-методологии, что позволит повысить гибкость и
адаптивность к изменениям.
План использования артефакта (User story)
Описание:
Пользователь: Менеджер проекта
Цель: Управлять проектами
Задача: Отслеживать ход выполнения задач, корректировать план проекта
Детали:
● Менеджер проекта авторизуется в системе.
● Менеджер проекта просматривает список задач.
● Менеджер проекта редактирует задачи: меняет статус, добавляет
комментарии, назначает исполнителей.
● Менеджер проекта просматривает аналитику по проекту: диаграммы
Ганта, отчеты о выполнении задач.
Использование идей:
● Модульный дизайн: Интерфейс артефакта состоит из модулей, что
позволяет легко добавлять новые функции.
● Использование Agile-методологии: Менеджер проекта может
корректировать план проекта в соответствии с текущими изменениями.
Преимущества:
● Повышение эффективности: Автоматизация рутинных задач.
● Улучшение качества решений: Поддержка принятия решений на основе
данных.
● Снижение рисков: Выявление и предотвращение потенциальных
проблем.
Описание предполагаемого процесса разработки артефакта
4.1 Инструменты/подходы/стратегии/методы:
● Agile-методология: Разработка артефакта будет вестись по
Agile-методологии, что позволит повысить гибкость и адаптивность к
изменениям.
● Scrum: Scrum будет использоваться для управления sprints, daily
meetings, sprint reviews и sprint retrospectives.
● Kanban: Kanban будет использоваться для визуализации задач и
управления workflow.
● Git: Git будет использоваться для управления версиями кода.
● GitHub: GitHub будет использоваться для совместной разработки и
публикации кода.
● Тестирование: Тестирование будет проводиться на всех этапах
разработки.
● CI/CD: CI/CD будет использоваться для автоматизации deployments.
4.2 Соответствие требованиям:
● Детальное описание требований: Требования будут подробно описаны
в виде user stories, use cases и acceptance criteria.
● Прозрачный процесс разработки: Процесс разработки будет
прозрачным, чтобы все заинтересованные стороны могли отслеживать
его ход.
● Регулярное тестирование: Регулярное тестирование будет
проводиться, чтобы гарантировать соответствие артефакта требованиям.
4.3 Уникальность артефакта:
● Использование новейших технологий: В артефакте будут
использоваться новейшие технологии, что позволит ему быть
конкурентоспособным.
● Оригинальный дизайн: Интерфейс и функциональность артефакта
будут оригинальными.
● Учет потребностей пользователей: Артефакт будет учитывать
потребности пользователей и их отзывы.
Кроме того, для обеспечения уникальности артефакта будут
использоваться следующие методы:
● Бенчмаркинг: Анализ существующих аналогов и выявление их слабых и
strong сторон.
● SWOT-анализ: Анализ сильных и слабых сторон, возможностей и угроз
артефакта.
● Позиционирование: Определение уникального selling proposition (USP)
артефакта.
Демонстрация и Оценка результата
Определение контекста оценки
1.1 Артефакт на момент начала оценки:
● Функциональность:
○ Авторизация пользователей
○ Управление профилями
○ Добавление, редактирование и удаление элементов
○ Поиск, сортировка и фильтрация
● Дизайн:
○ Модульный дизайн
○ Интуитивно понятный интерфейс
○ Адаптивный дизайн
● Технологии:
○ Open-source frameworks
○ Agile-методология
○ Тестирование
1.2 Условия и ограничения:
● Время: Оценка должна быть проведена в течение 2 недель.
● Ресурсы: Для оценки будут доступны 3 эксперта.
● Данные: Для оценки будут доступны тестовые данные.
● Методы: Для оценки будут использоваться следующие методы:
○ Экспертная оценка
○ Анализ документации
○ Тестирование
Ограничения:
● Оценка будет проводиться без учета реальных пользователей.
● Оценка будет проводиться без учета реальных условий эксплуатации.
Определение целей оценки артефакта ВКР (конкретизация)
2.1 Ответы на вопросы:
Оцениваемые требования:
Функциональные:
● Соответствие заявленным функциям:
○ Авторизация пользователей
○ Управление профилями
○ Добавление, редактирование и удаление элементов
○ Поиск, сортировка и фильтрация элементов
○
Нефункциональные:
● Производительность:
○ Время отклика
○ Нагрузка на сервер
○
● Безопасность:
○ Аутентификация и авторизация
○ Конфиденциальность данных
○
● Usability:
○ Простота использования
○ Интуитивно понятный интерфейс
○
● Надежность:
○ Устойчивость к ошибкам
○ Восстановление данных
○
● Масштабируемость:
○ Возможность расширения функциональности
○ Поддержка большого количества пользователей
○
Контекстное знание:
Да, важно исследовать знания об артефакте, чтобы:
● Понять его цели и задачи.
● Определить его целевую аудиторию.
● Узнать о его преимуществах и недостатках.
● Сравнить его с аналогами.
Сравнение с аналогами:
Да, важно сравнивать артефакт с аналогами, чтобы:
● Определить его конкурентные преимущества.
● Выявить его слабые стороны.
● Найти способы его улучшения.
Побочные эффекты:
Да, важно изучить побочные эффекты (особенно негативные), чтобы:
● Оценить его влияние на пользователей.
● Определить возможные риски.
● Найти способы их минимизации.
Список целей оценки и количество итераций
Цели оценки:
1. Оценка функциональности:
○ Цель: Проверить соответствие артефакта заявленным функциям.
○ Методы: Тестирование, анализ документации.
○ Итерации: 1.
2. Оценка производительности:
○ Цель: Измерить время отклика, нагрузку на сервер и другие
показатели производительности.
○ Методы: Нагрузочное тестирование, мониторинг
производительности.
○ Итерации: 2.
3. Оценка безопасности:
○ Цель: Проверить устойчивость артефакта к различным угрозам
безопасности.
○ Методы: Тестирование на проникновение, анализ кода.
○ Итерации: 3.
4. Оценка usability:
○ Цель: Оценить простоту использования и интуитивность
интерфейса артефакта.
○ Методы: Юзабилити-тестирование, экспертная оценка.
○ Итерации: 4.
5. Оценка надежности:
○ Цель: Определить устойчивость артефакта к ошибкам и сбоям.
○ Методы: Тестирование на отказоустойчивость, анализ кода.
○ Итерации: 5.
6. Оценка масштабируемости:
○ Цель: Определить, насколько легко артефакт можно
масштабировать для поддержки большего количества
пользователей и данных.
○ Методы: Нагрузочное тестирование, анализ архитектуры.
○ Итерации: 6.
7. Оценка контекстного знания:
○ Цель: Понять цели и задачи артефакта, его целевую аудиторию,
преимущества и недостатки.
○ Методы: Анализ документации, интервью с экспертами.
○ Итерации: 1.
8. Сравнение с аналогами:
○ Цель: Определить конкурентные преимущества артефакта и его
слабые стороны.
○ Методы: Анализ документации, тестирование.
○ Итерации: 7.
9. Изучение побочных эффектов:
○ Цель: Оценить влияние артефакта на пользователей и определить
возможные риски.
○ Методы: Анализ документации, интервью с пользователями.
○ Итерации: 8.
Общее количество итераций: 8
Сценарий оценки/демонстрации для итерации 1: Оценка
функциональности
5.1 Описание пользовательского сценария
Конечная цель: Пользователь успешно добавляет новый элемент в систему.
Последовательность шагов:
1. Пользователь авторизуется в системе.
2. Пользователь переходит на страницу добавления нового элемента.
3. Пользователь заполняет все необходимые поля формы.
4. Пользователь нажимает кнопку "Добавить".
5. Система добавляет новый элемент и отображает сообщение об
успешном выполнении операции.
Диаграмма:
Изображение диаграммы: [неправильный URL удален]
5.2 Тип сценария
Тип сценария: Комбинированный
Пояснение:
Сценарий основан на реальном сценарии использования системы, но
некоторые детали были добавлены или изменены для целей демонстрации.
5.3 Внешняя и внутренняя валидность
Внешняя валидность:
● Сценарий отражает типичный сценарий использования системы.
● Сценарий позволяет продемонстрировать основные функции
системы.
● Сценарий понятен и легко выполним.
Внутренняя валидность:
● Сценарий позволяет достоверно оценить функциональность
системы.
● Сценарий позволяет выявить возможные ошибки и проблемы в
работе системы.
● Сценарий позволяет собрать данные о производительности
системы.
Аргументация:
Сценарий был выбран на основе анализа требований к системе и
пользовательских сценариев. Сценарий позволяет продемонстрировать
основные функции системы, такие как авторизация, добавление элементов,
отображение сообщений об ошибках. Сценарий также позволяет оценить
производительность системы, например, время отклика при добавлении нового
элемента.
Определение типа оценки, стратегий и методов исследования для каждой
итерации
Итерация 1: Оценка функциональности
6.1 Тип оценки:
● Промежуточная:
○ Оценка проводится на раннем этапе разработки, чтобы выявить и
устранить ошибки на ранней стадии.
○ Оценка позволяет скорректировать курс разработки, если это
необходимо.
6.2 Ex ante/Ex post:
● Ex ante:
○ Оценка проводится до внедрения системы.
○ Оценка позволяет оценить потенциальные преимущества и риски
системы.
6.3 Искусственная или натуралистическая:
● Искусственная:
○ Оценка проводится в лабораторных условиях.
○ Оценка позволяет контролировать все факторы, влияющие на
процесс оценки.
Стратегии и методы исследования:
● Тестирование:
○ Юнит-тестирование
○ Интеграционное тестирование
○ Системное тестирование
● Анализ документации:
○ Техническое задание
○ Руководство пользователя
Итерация 2: Оценка производительности
6.1 Тип оценки:
● Промежуточная:
○ Оценка проводится на этапе разработки, когда система уже готова
к тестированию.
○ Оценка позволяет оптимизировать производительность системы.
6.2 Ex ante/Ex post:
● Ex post:
○ Оценка проводится после внедрения системы.
○ Оценка позволяет оценить реальную производительность
системы.
6.3 Искусственная или натуралистическая:
● Натуралистическая:
○ Оценка проводится в условиях, максимально приближенных к
реальным.
○ Оценка позволяет получить более точные результаты.
Стратегии и методы исследования:
● Нагрузочное тестирование:
○ Тестирование системы при пиковой нагрузке.
○ Определение узких мест системы.
● Мониторинг производительности:
○ Сбор данных о производительности системы.
○ Анализ данных для выявления проблем.
Итерация 3: Оценка безопасности
6.1 Тип оценки:
● Промежуточная:
○ Оценка проводится на этапе разработки, когда система уже готова
к тестированию.
○ Оценка позволяет выявить и устранить уязвимости системы.
6.2 Ex ante/Ex post:
● Ex ante:
○ Оценка проводится до внедрения системы.
○ Оценка позволяет оценить потенциальные риски безопасности.
6.3 Искусственная или натуралистическая:
● Искусственная:
○ Оценка проводится в лабораторных условиях.
○ Оценка позволяет контролировать все факторы, влияющие на
процесс оценки.
Стратегии и методы исследования:
● Тестирование на проникновение:
○ Попытка взлома системы хакерами.
○ Определение уязвимостей системы.
● Анализ кода:
○ Поиск уязвимостей в коде системы.
○ Оценка безопасности кода.
Итерации 4-8:
Тип оценки:
● Промежуточная:
○ Оценки проводятся на разных этапах разработки.
○ Оценки позволяют скорректировать курс разработки, если это
необходимо.
Ex ante/Ex post:
● Ex ante:
○ Оценки проводятся до внедрения системы.
○ Оценки позволяют оценить потенциальные преимущества и риски
системы.
Искусственная или натуралистическая:
● Комбинация:
○ Используются как искусственные, так и натуралистические методы.
○ Это позволяет получить более точные и достоверные результаты.
Стратегии и методы исследования:
● Тестирование:
○ Юзабилити-тестирование
○ Экспертная оценка
○ Интервью с пользователями
6.4 Связки Стратегия исследования- Метод(ы) сбора данных - Метод(ы)
анализа данных
Итерация 1: Оценка функциональности
Стратегия: Тестирование
Методы сбора данных:
● Тестовые сценарии
● Отчеты о тестировании
Методы анализа данных:
● Сравнение фактических и ожидаемых результатов
● Анализ ошибок
Итерация 2: Оценка производительности
Стратегия: Нагрузочное тестирование
Методы сбора данных:
● Инструменты мониторинга производительности
● Отчеты о нагрузочном тестировании
Методы анализа данных:
● Анализ времени отклика
● Анализ потребления ресурсов
Итерация 3: Оценка безопасности
Стратегия: Тестирование на проникновение
Методы сбора данных:
● Отчеты о тестировании на проникновение
● Инструменты сканирования уязвимостей
Методы анализа данных:
● Выявление уязвимостей
● Оценка рисков безопасности
Итерации 4-8:
Стратегия: Комбинация
Методы сбора данных:
● Юзабилити-тестирование
● Экспертная оценка
● Интервью с пользователями
Методы анализа данных:
● Анализ результатов тестирования
● Анализ экспертных оценок
● Анализ отзывов пользователей
Пояснение:
● Выбор стратегий, методов сбора и анализа данных основан на целях
каждой итерации оценки.
● Для оценки функциональности используются тестовые сценарии, отчеты
о тестировании, сравнение фактических и ожидаемых результатов,
анализ ошибок.
● Для оценки производительности используются инструменты мониторинга
производительности, отчеты о нагрузочном тестировании, анализ
времени отклика, анализ потребления ресурсов.
● Для оценки безопасности используются отчеты о тестировании на
проникновение, инструменты сканирования уязвимостей, выявление
уязвимостей, оценка рисков безопасности.
● Для юзабилити-тестирования, экспертной оценки и интервью с
пользователями используются методы, описанные в источниках:
7.1 Критерии/метрики для каждой итерации оценки
Итерация 1: Оценка функциональности
Критерии:
● Полнота: Все заявленные функции должны быть реализованы.
● Корректность: Все функции должны работать корректно.
● Соответствие требованиям: Все функции должны соответствовать
требованиям,
Итерация 2: Оценка производительности
Критерии:
● Время отклика: Время отклика системы должно быть within acceptable
limits.
● Потребление ресурсов: Система не должна excessively consume
resources.
● Масштабируемость: Система должна
Итерация 3: Оценка безопасности
Критерии:
● Отсутствие уязвимостей: В системе не должно быть critical
vulnerabilities.
● Конфиденциальность данных: Данные пользователей должны быть
● Целостность данных: Данные пользователей должны быть
Итерации 4-8:
Критерии:
● Простота использования: Интерфейс системы должен быть
● Удовлетворенность пользователей: Пользователи должны быть
● Эффективность: Система должна
7.2 Способ измерения каждой метрики
Итерация 1: Оценка функциональности
● Полнота: Проверка наличия всех заявленных функций.
● Корректность: Тестирование функций.
● Соответствие требованиям: Анализ документации.
Итерация 2: Оценка производительности
● Время отклика: Использование инструментов мониторинга.
● Потребление ресурсов: Использование инструментов мониторинга.
● Масштабируемость: Нагрузочное тестирование.
Итерация 3: Оценка безопасности
● Отсутствие уязвимостей: Тестирование на проникновение.
● Конфиденциальность данных: Анализ кода.
● Целостность данных: Тестирование