Использование html-прототипов для реверсивного анализа требований: ЗА и ПРОТИВ
Download as PPTX, PDF2 likes1,037 views
Документ обсуждает использование HTML-прототипов для реверсивного анализа требований, аргументируя, что функциональные спецификации часто не соответствуют реальности и являются ненадёжными инструментами для разработки. Приводятся причины, почему использование прототипов может быть более эффективным методом, включая возможность тестирования и внесения изменений в процессе разработки. Также рассматриваются основные этапы процесса прототипирования и его преимущества и недостатки по сравнению с традиционными методами.
![Линус Торвальдс о
функциональных спецификациях:
«… Они практически бесполезны. Я не
видел ни одного крупного проекта, в
котором спецификации полностью
соответствовали реальности и при
этом действительно помогали
разработчикам.
Поверьте мне: разработка по спецификации — худший
способ создания приложений, так как он подразумевает,
что ваш проект будет делаться только по теории, без
оглядки на реальность.» [1]
Зато я видел множество неудавшихся
проектов, которые слепо полагались на
спецификации.](https://image.slidesharecdn.com/prototypingvssrs-150419043642-conversion-gate01/85/html-3-320.jpg)
![6 причин по которым
не стоит писать
функциональные спецификации:
1. Спецификация — это фикция. Она не имеет никакого отношения к
реальности… Спецификация никак не приближает проект к завершению —
ведь это не более чем слова на бумаге.
Эссе из книги «Getting Real», написанной в компании 37signals. [2]
2. Задача спецификации — угодить всем. В спецификации никогда
не идет речь о нахождении сложных компромиссов и выборе оптимальных
вариантов, а при разработке приложений без этого не обойтись.
3. Спецификация — лишь иллюзия соглашения. Множество
заверяющих подписей под несколькими страницами спецификации — это не
соглашение.](https://image.slidesharecdn.com/prototypingvssrs-150419043642-conversion-gate01/85/html-4-320.jpg)
![Уровни видимости
функциональных
требований [4]](https://image.slidesharecdn.com/prototypingvssrs-150419043642-conversion-gate01/85/html-7-320.jpg)
![Может лучше
сразу писать
код, чем
«жевать»
требования?
Пишем и…
переписываем,
снова, снова и
снова…
Манифест «крутых»
программеров от
Зеда Шоу [3]](https://image.slidesharecdn.com/prototypingvssrs-150419043642-conversion-gate01/85/html-8-320.jpg)
Использование html-прототипов для реверсивного анализа требований: ЗА и ПРОТИВ
- 1. ИСПОЛЬЗОВАНИЕ HTML- ПРОТОТИПОВ ДЛЯ РЕВЕРСИВНОГО АНАЛИЗА ТРЕБОВАНИЙ: ЗА И ПРОТИВ Николай Киреев Студия WebMax.BY www.webmax.by
- 2. Что выбрать?
- 3. Линус Торвальдс о функциональных спецификациях: «… Они практически бесполезны. Я не видел ни одного крупного проекта, в котором спецификации полностью соответствовали реальности и при этом действительно помогали разработчикам. Поверьте мне: разработка по спецификации — худший способ создания приложений, так как он подразумевает, что ваш проект будет делаться только по теории, без оглядки на реальность.» [1] Зато я видел множество неудавшихся проектов, которые слепо полагались на спецификации.
- 4. 6 причин по которым не стоит писать функциональные спецификации: 1. Спецификация — это фикция. Она не имеет никакого отношения к реальности… Спецификация никак не приближает проект к завершению — ведь это не более чем слова на бумаге. Эссе из книги «Getting Real», написанной в компании 37signals. [2] 2. Задача спецификации — угодить всем. В спецификации никогда не идет речь о нахождении сложных компромиссов и выборе оптимальных вариантов, а при разработке приложений без этого не обойтись. 3. Спецификация — лишь иллюзия соглашения. Множество заверяющих подписей под несколькими страницами спецификации — это не соглашение.
- 5. 6 причин по которым не стоит писать функциональные спецификации: 4. Спецификация заставляет вас принимать самые важные решения тогда, когда вы меньше всего знаете о проекте. Меньше всего о проекте известно в самом начале работы. Так почему вы должны принимать самые важные решения, даже не приступив к работе? Эссе из книги «Getting Real», написанной в компании 37signals. 5. Использование спецификаций приводит к обрастанию ненужной функциональностью. На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии. Нет ничего легче, чем дописать абзац текста или добавить еще один пункт в список. 6. Спецификация не позволяет вам развиваться, меняться и оценивать пройденный путь. Само существование фиксированной спецификации противоречит тому факту, что требования могут меняться в процессе создания приложения.
- 6. Функциональные спецификации «без фанатизма»: являются: и НЕ являются: основой для приблизительной оценки трудоёмкости и стоимости проекта; промежуточным результатом в процессе разработки ПО; архитектуро-определяющими и служат источником для проектирования архитектуры ПО; источником для внесения изменений в архитектуру ПО в процессе эксплуатации. продуктом, в котором заинтересованы заказчики и пользователи; основной целью аналитиков и проектировщиков; основной целью процесса разработки; полной и достаточной информацией о программном продукте; стабильными и очевидными как в процессе разработки, так и в дальнейшей эксплуатации.
- 8. Может лучше сразу писать код, чем «жевать» требования? Пишем и… переписываем, снова, снова и снова… Манифест «крутых» программеров от Зеда Шоу [3]
- 9. Разработка динамических прототипов вместо функциональных спецификаций и кодирования Ты сначала требования согласуй!
- 10. Процесс разработки требований прототипированием • Определяем пользователей (роли, включая абстрактные) и основные функциональные сервисы (Use Cases), которые должна им предоставить система. • Расставляем приоритеты и составляем список последовательности разработки итераций • Согласуем краткие описания, по необходимости наброски интерфейсов (wireframe) для уникальных (не имеющих близких аналогов) сервисов. 1. ИНИЦИАЦИЯ
- 11. Процесс разработки требований прототипированием • Реализуем действующий html-прототип очередного подлежащего разработке сервиса, добиваясь (по возможности) полной имитации его функционирования. • Тестируя, отрабатываем основной и альтернативные потоки, а также меры по исключению ошибок пользователей. • Каждый разрабатываемый html-прототип размещается в облаке и представляется для тестирования заказчику • Внесение изменений (по результатам тестирования) в прототип и окончательное согласование функциональности. Завершение цикла. 2. РЕАЛИЗАЦИЯ ПРОТОТИПА (ИТЕРАЦИЯ)
- 12. Процесс разработки требований прототипированием • По завершению последней итерации, по необходимости, создаются детальные UML-модели, пишутся сценарии, спецификации требований • Отдельные сервисы интегрируются в общую оболочку • Последующая разработка приложения производится в рамках стандартных моделей 3. ЗАВЕРШЕНИЕ ПРОТОТИПИРОВАНИЯ
- 14. Области применения методики 1. Для приложений с высоконагруженными графическими интерфейсами 2. Для инновационных разработок, не имеющих близких аналогов 3. Для приложений в которых следует исключать риски ошибочных действий пользователей 4. При неясных, нестабильных и изменяющихся требованиях
- 15. ЗА & ПРОТИВ ПРЕИМУЩЕСТВА ПРОТОТИПИРОВАНИЯ НЕДОСТАТКИ vs Спецификация + Wireframes НЕДОСТАТКИ vs AGILE 1. Функционал определятся не «на бумаге», а тестированием действующего прототипа 1. Требует затрат времени 1. Требует затрат времени на прототип, а не на приложение 2. Определяются функции бизнес-логики и UX, уменьшающие ошибки пользователей 2. Требует высокой квалификации 2. Код прототипа не используется в последующей разработке 3. Лёгкость внесения изменений 3. Относительно узкая область применения 3. Усложняется процесс управления проектом 4. Интегрируется в различных моделях разработки 5. Возможность распараллеливания работ
- 17. Список используемой литературы 1. Линус Торвальдс http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_ a_Functional_Spec.php 2. Эссе из книги «Getting Real» ( http://gettingreal.37signals.com/ ), перевод ресурс «Хорошие IT-статьи» http://factorized.tumblr.com/ 3. Зед А. Шоу (Zed A. Shaw) Manifesto http://programming- motherfucker.com/ 4. Н. Киреев Что делать, когда даже Agile «не рулит?» http://analyst.by/articles/chto-delat-kogda-dazhe-agile-ne-rulit
- 18. Спасибо за внимание! Николай Киреев студия WebMax.BY info@webmax.by www.webmax.by Вебинары-тренинги аналитиков WebMax.BY