Модель прототипирования — позволяет создать прототип программного продукта до или в течение этапа составления требований к программному продукту. Потенциальные пользователи работают с этим прототипом, определяя его сильные и слабые стороны, о результатах сообщают разработчикам программного продукта. Таким образом, обеспечивается обратная связь между пользователями и разработчиками, которая используется для изменения или корректировки спецификации требований к программному продукту. В результате такой работы продукт будет отражать реальные потребности пользователей.
Жизненный цикл разработки программного продукта начинается с разработки плана проекта, затем выполняется быстрый анализ, после чего создаются база данных, пользовательский интерфейс и выполняется разработка необходимых функций. В результате этой работы получается документ, содержащий частичную спецификацию требований к программному продукту. Данный документ в дальнейшем является основой для итерационного цикла быстрого прототипирования.
Зачем делают прототипы
Главная цель прототипирования — сэкономить деньги и время. С первого раза сложно создать идеальный продукт, который понравится заказчику, а главное — будет удобен для пользователей.
Типы прототипов
По глубине проработки прототипы бывают с высокой и низкой детализацией. Все зависит от количества элементов в итоговом варианте.
По возможности взаимодействия с макетом прототипы делятся на статичные и интерактивные. Статичные можно изобразить на бумаге схематично, а для интерактивных стоит использовать графические редакторы, например, Figma.
Плюсы
- Быстрая демонстрация достигнутого, текущего результата. Прототипирование позволяет быстро получить промежуточный результат.
- Прототипирование повышает уверенность, поддерживая исследователя, определяя концепцию, позволяя решать неожиданные проблемы, получать актуальные и содержательные отзывы и лучше управлять своим временем и деньгами.
- Наличие демонстрации, увеличивает дополнительную оценку результата еще до его полного формирования, исследователи могут быть вовлечены в планирование, разработку и предоставление продукта или услуги.
- Понимание системы, исследователь получает лучшее представление об исследовании и начинает разрабатывать полную детализацию всего проекта исследования.
- Сокращает время и затраты на быстрое прототипирование,
- Идентификация функциональности. Все отклонения можно легче определить путем тестирования концепции или идеи.
- Больше надежных решений. Более быстрая обратная связь приводит к более глубоким решениям.
Минусы
- Денежные затраты. Нередко приходится делать не один прототип, а несколько. Всё это требует денег на материалы и производство.
- Время. Чтобы сделать прототип, в любом случае придётся потратить определённое количество времени.
- Путаница пользователя в отношении прототипа и результирующей системы: пользователи могут ошибочно полагать, что прототип, который следует отбросить, является ненастроенной целевой системой.
- Недостаточный анализ: концентрация на ограниченном прототипе может отвлечь разработчиков от правильного анализа всего проекта.
Гибкая методология разработки (agile) — система идей и принципов «гибкого» управления проектами, на основе которых разработаны популярные методы Scrum, Kanban и другие. Ключевой принцип — разработка через короткие итерации (циклы), в конце каждого из которых заказчик (пользователь) получает рабочий код или продукт.
История
В феврале 2001 года в штате Юта США был выпущен «Манифест гибкой разработки программного обеспечения». В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.
Основные идеи
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану.
Плюсы
- Минимизация рисков благодаря гибкой системе внесения изменений
- Высокая степень вовлечения исполнителей, организаторов и заказчиков проекта
- Короткие и понятные итерации — циклы разработки длятся от 2 недели до 2 месяцев, по окончанию которых заказчик получает рабочую версию продукта
- Популярность метода среди разработчиков программ для управления бизнеса
- Во главе угла стоит рабочий продукт как основной показатель прогресса — это можно рассматривать как плюс, так и минус, ведь в таком случае к команде проекта выдвигаются высокие требования по самоорганизации
Минусы
- Стимулирование постоянных изменений проекта: гибкость разработки продукта может привести к тому, что он никогда не дойдёт до финальной версии
- Повышенные требования к квалификации и опыту команды: помимо непосредственно создания продукта команда должна анализировать возможные способы улучшения эффективности собственной работы, беспрерывно обмениваться информацией по проекту, быть мотивированной и самоорганизованной.
- Команда не может механически применить механики «гибкой» разработки, нужно принять ключевые принципы системы
- Сложность подсчёта итоговой суммы работы: стимуляция изменений и усовершенствования конечного продукта приводит к плавающему значению стоимости проекта. Поэтому Agile не подойдет для управления проектами в строительстве, где составляется четкая смета под всю работу.
- Слабое внимание к документации. В случае возникновения претензий и конфликтных ситуаций аргументов в свою защиту у исполнителя просто не будет.
Модель прототипирования | Гибкая методология разработки |
| + Быстрая демонстрация достигнутого, текущего результата. Прототипирование позволяет быстро получить промежуточный результат. | + Минимизация рисков благодаря гибкой системе внесения изменений |
| + Прототипирование повышает уверенность, поддерживая исследователя, определяя концепцию, позволяя решать неожиданные проблемы, получать актуальные и содержательные отзывы и лучше управлять своим временем и деньгами. | + Высокая степень вовлечения исполнителей, организаторов и заказчиков проекта |
| + Наличие демонстрации, увеличивает дополнительную оценку результата еще до его полного формирования, исследователи могут быть вовлечены в планирование, разработку и предоставление продукта или услуги. | + Короткие и понятные итерации — циклы разработки длятся от 2 недели до 2 месяцев, по окончанию которых заказчик получает рабочую версию продукта |
| + Понимание системы, исследователь получает лучшее представление об исследовании и начинает разрабатывать полную детализацию всего проекта исследования. | + Популярность метода среди разработчиков программ для управления бизнеса |
| + Сокращает время и затраты на быстрое прототипирование | + Во главе угла стоит рабочий продукт как основной показатель прогресса — это можно рассматривать как плюс, так и минус, ведь в таком случае к команде проекта выдвигаются высокие требования по самоорганизации |
| + Идентификация функциональности. Все отклонения можно легче определить путем тестирования концепции или идеи. | |
| + Больше надежных решений. Более быстрая обратная связь приводит к более глубоким решениям. |
Модель прототипирования | Гибкая методология разработки |
| — Денежные затраты. Нередко приходится делать не один прототип, а несколько. Всё это требует денег на материалы и производство. | — Стимулирование постоянных изменений проекта: гибкость разработки продукта может привести к тому, что он никогда не дойдёт до финальной версии |
| — Время. Чтобы сделать прототип, в любом случае придётся потратить определённое количество времени. | — Повышенные требования к квалификации и опыту команды: помимо непосредственно создания продукта команда должна анализировать возможные способы улучшения эффективности собственной работы, беспрерывно обмениваться информацией по проекту, быть мотивированной и самоорганизованной. |
| — Путаница пользователя в отношении прототипа и результирующей системы: пользователи могут ошибочно полагать, что прототип, который следует отбросить, является ненастроенной целевой системой. | — Команда не может механически применить механики «гибкой» разработки, нужно принять ключевые принципы системы |
| — Недостаточный анализ: концентрация на ограниченном прототипе может отвлечь разработчиков от правильного анализа всего проекта. | — Сложность подсчёта итоговой суммы работы: стимуляция изменений и усовершенствования конечного продукта приводит к плавающему значению стоимости проекта. Поэтому Agile не подойдет для управления проектами в строительстве, где составляется четкая смета под всю работу. |
| — Слабое внимание к документации. В случае возникновения претензий и конфликтных ситуаций аргументов в свою защиту у исполнителя просто не будет. |
TEST!
