В реальной жизни вы не хотите искать «идеальный» способ делать вещи. Вместо этого используйте то, что вы понимаете, для ясных и конкретных целей.
Макеты могут сэкономить ТОННЫ времени и усилий. Так как они могут быть просто дополнительным временем, которое вы потратили на их создание и обслуживание.
Пример из реальной жизни # 1: Макеты спасли день. Большая система для правительства, крайний срок смешной.
Причина: прошли месяцы в создании всех видов архитектурных документов, которые фактически совершенно не нужны, потому что архитектура HW и SW фиксирована в камне до мельчайших деталей и фактически уже существует.
Решение: 20 безумных дней создания макетов вместе с заказчиком, пока мы просто не передадим экраны с нашими заметками разработчикам. Разработчики должны были попросить некоторые разъяснения, но с фиксированной архитектурой и четкими и визуализированными требованиями они смогли в кратчайшие сроки получить необходимые тонны функций.
Пример из реальной жизни № 2: Макеты разрушили день. Большая государственная система, которая «признала» необходимость макетов.
Это показывает человеческую (или корпоративную?) Способность превращать лучшее в мире в кошмар.
Большое правительственное агентство попросило крупную компанию-консультанта возглавить крупную ИТ-компанию для решения проблемы. Правительственное учреждение также создало большой специальный комитет правительственных экспертов, чтобы помочь и ускорить процесс.
Прошли месяцы громкими словами и при выборе подходящих методологий и подходящих способов их использования. Разумеется, были достигнуты все виды компромиссов, чтобы не задеть чьи-либо чувства или важность.
Результат: архитектура Sw должна была быть источником всего, включая макеты. Которые должны были быть спроектированы первыми, а нарисованы вторыми. Сопоставляя действия из OOAD и диаграмм последовательности, создавались диаграммы UX, затем распознавались логические объекты пользовательского интерфейса и комплекты контента, создавались реальные экраны и включались в формальные сценарии использования, UC представлялись пользователям на официальных семинарах раз в месяц, эти семинары удвоились как встречи принятия требований, так как кто-то понял, что время ускользает.
На этих семинарах даже насильственно нельзя было заставить клиентов понять (очень формально, с множеством таблиц, описывающих атрибуты данных и тому подобное) UC, каждый примерно по 30 страниц. Когда у клиентов были какие-то отзывы, это было на макетах. Но обратная связь не приветствовалась, потому что любое изменение в макете приводило к изменению диаграмм последовательности, диаграмм компонентов, операционной модели, диаграмм UX, проверке матриц трассируемости, обновлению текстов UC и т. Д. И т. Д. И только для получения большей обратной связи. («Будь прокляты клиенты, они никогда не останавливаются». Это был девиз). После выпуска v1.0 с ограниченной функциональностью никто больше не интересовался документацией, ее было так много. Разработчики боролись за свою жизнь, ежедневно внося несметное количество мелких изменений, просто чтобы запустить систему и запустить ее (после вчерашнего пакета изменений что-то сломалось).
Это НЕ способ использовать макеты. Проект длился почти на 2 года дольше, чем планировалось.
Другими словами, не ищите идеальную методологию. Или любую методологию, которую вы не понимаете. Какова ваша цель на данный момент? Какой самый быстрый способ, которым вы знаете (другие способы не учитываются) для достижения этой цели? Действуй.