Итеративный дизайн
Эта статья нуждается в дополнительных цитатах для проверки . ( январь 2011 г. ) |
Итеративный дизайн — это методология проектирования, основанная на циклическом процессе создания прототипа , тестирования , анализа и усовершенствования продукта или процесса. По результатам тестирования последней итерации конструкции вносятся изменения и доработки. Этот процесс призван в конечном итоге улучшить качество и функциональность дизайна. В итеративном проектировании взаимодействие с спроектированной системой используется как форма исследования для информирования и развития проекта по мере реализации последовательных версий или итераций проекта.
История [ править ]
Итеративное проектирование уже давно используется в инженерных областях. Одним из примеров является цикл «планируй-делай-проверяй-действуй», реализованный в 1960-х годах. Большинство программ разработки новых продуктов или существующих программ улучшения продуктов имеют цикл проверки, который используется для итеративных целей. DMAIC использует структуру «Шесть сигм» и имеет такую функцию проверки.
Объектно-ориентированное программирование [ править ]
Итеративное проектирование связано с практикой объектно-ориентированного программирования , и эта фраза появилась в литературе по информатике еще в 1990 году. [1] Идея имеет свои корни в спиральном развитии , задуманном Барри Бёмом . [2]
процесс Итеративный проектирования
Итеративный процесс проектирования может применяться на протяжении всего процесса разработки нового продукта . Однако изменения проще и дешевле реализовать на самых ранних стадиях разработки. Первым шагом в процессе итеративного проектирования является разработка прототипа . Прототип должен быть оценен фокус-группой или группой, не связанной с продуктом, чтобы высказать непредвзятое мнение. Информация, полученная от фокус-группы, должна быть обобщена и включена в следующую итерацию проекта. Этот процесс следует повторять до тех пор, пока проблемы пользователей не будут уменьшены до приемлемого уровня.
: Человеко- компьютерные Применение интерфейсы
Итеративное проектирование обычно используется при разработке человеко-компьютерных интерфейсов. Это позволяет дизайнерам выявлять любые проблемы с удобством использования, которые могут возникнуть в пользовательском интерфейсе, прежде чем он будет введен в широкое использование. Даже лучшие эксперты по юзабилити не могут спроектировать идеальные пользовательские интерфейсы за одну попытку, поэтому жизненный цикл разработки юзабилити должен строиться вокруг концепции итерации. [3]
Типичные этапы итеративного проектирования пользовательских интерфейсов следующие:
- Завершить первоначальный дизайн интерфейса
- Представьте дизайн нескольким тестируемым пользователям.
- Обратите внимание на любые проблемы, возникшие у тестового пользователя.
- Уточните интерфейс для учета/устранения проблем.
- Повторяйте шаги 2–4, пока проблемы с пользовательским интерфейсом не будут устранены.
Итеративный дизайн пользовательских интерфейсов можно реализовать разными способами. Одним из распространенных методов использования итеративного проектирования в компьютерном программном обеспечении является тестирование программного обеспечения . Хотя это включает в себя тестирование функциональности продукта за пределами пользовательского интерфейса, важные отзывы об интерфейсе можно получить в ходе предметного тестирования ранних версий программы. Это позволяет компаниям-разработчикам программного обеспечения выпускать для широкой публики продукт более высокого качества и предотвращает необходимость модификации продукта после его выпуска.
Итеративное проектирование онлайн-интерфейсов (веб-сайтов) представляет собой более непрерывный процесс, поскольку модификация веб-сайта после его предоставления пользователю гораздо более жизнеспособна, чем при проектировании программного обеспечения. Часто веб-сайты используют своих пользователей в качестве испытуемых при проектировании интерфейса, внося изменения на основе рекомендаций посетителей своих сайтов.
Использование итеративного дизайна
Итеративный дизайн — это способ противостоять реальности непредсказуемых потребностей и поведения пользователей, которые могут привести к радикальным и фундаментальным изменениям в дизайне. Пользовательское тестирование часто показывает, что даже тщательно оцененные идеи окажутся неадекватными при столкновении с пользовательским тестом. Таким образом, важно, чтобы гибкость подхода к реализации итеративного проектирования распространялась как можно глубже на систему. Дизайнеры должны также осознавать, что результаты пользовательского тестирования могут указывать на радикальные изменения, которые потребуют от дизайнеров быть готовыми полностью отказаться от старых идей в пользу новых идей, которые больше подходят для удовлетворения потребностей пользователей. Итеративный дизайн применяется во многих областях: от изготовления ножей до ракет. В качестве примера рассмотрим проектирование электронной схемы , которая должна выполнять определенную задачу и в конечном итоге должна помещаться на небольшом пространстве на печатной плате . Полезно разделить эти независимые задачи на две меньшие и простые задачи: задачу функциональности и задачу пространства и веса. А Макет — это полезный способ временной реализации электронной схемы, не беспокоясь о пространстве и весе.
Как только схема заработает, к макетной плате можно будет внести улучшения или дополнительные изменения, чтобы увеличить или улучшить функциональность по сравнению с исходной конструкцией. Когда проект будет завершен, можно приступить к разработке подходящей печатной платы, соответствующей критериям размера и веса. Уплотнение схемы на плате требует манипулирования проводами и компонентами без изменения их электрических характеристик. Это жонглирование следует более простым правилам, чем проектирование самой схемы, и часто автоматизировано . Насколько это возможно, готовые используются компоненты, но, если это необходимо по соображениям пространства или производительности, могут быть разработаны компоненты, изготовленные по индивидуальному заказу.
Вот несколько примеров итеративного проектирования:
- Wiki : Wiki — это естественный репозиторий для итеративного проектирования. Функция «История страниц» позволяет отслеживать предыдущие версии. Изменения в основном носят поэтапный характер и оставляют существенные части текста без изменений.
- Общее право : Принцип юридического прецедента основан на прошлом опыте. Это делает право формой итеративного проектирования, где должен быть четкий контрольный след развития юридической мысли.
- Эволюция : Существует параллель между итеративностью и теорией естественного отбора . Оба метода включают в себя процесс проб и ошибок, в ходе которого наиболее подходящая конструкция переходит в следующее поколение, а менее подходящие конструкции остаются на обочине. Последующие версии продукта также должны становиться все лучше и лучше по мере того, как его производители узнают, что работает, а что нет, в процессе совершенствования и постоянного улучшения .
Инструменты быстрого прототипирования [ править ]
Один из подходов к итеративному проектированию — использовать самый высокий уровень абстракции для разработки продукта раннего поколения. Принцип здесь заключается в том, что быстрая разработка может не привести к созданию эффективного кода, но получение обратной связи важнее оптимизации технологии. Примеры этого подхода включают использование нефункционального кода, объектных баз данных или платформ с низким уровнем кода — они позволяют быстро тестировать проекты до того, как будут решены вопросы оптимизации.
Преимущества [ править ]
При правильном применении итеративный дизайн гарантирует, что продукт или процесс являются лучшим возможным решением. При применении на ранней стадии разработки возможна значительная экономия средств. [4]
Другие преимущества итеративного проектирования включают в себя:
- Серьезные недоразумения становятся очевидными на ранних этапах жизненного цикла, когда на них можно отреагировать.
- Это позволяет и поощряет обратную связь с пользователем, чтобы выявить реальные требования системы.
- Если работа ведется по контракту, итеративное проектирование предоставляет поэтапный метод более эффективного вовлечения клиента в сложности, которые часто окружают процесс проектирования.
- Команда разработчиков вынуждена сосредоточиться на тех проблемах, которые наиболее важны для проекта, а члены команды ограждены от тех проблем, которые отвлекают их от реальных рисков проекта.
- Постоянное тестирование позволяет объективно оценить состояние проекта.
- Несоответствия между требованиями, проектами и реализациями выявляются на ранней стадии.
- Рабочая нагрузка команды, особенно команды тестирования, распределяется более равномерно на протяжении всего жизненного цикла.
- Такой подход позволяет команде использовать извлеченные уроки и, следовательно, постоянно совершенствовать процесс.
- Заинтересованным сторонам проекта могут быть предоставлены конкретные доказательства статуса проекта на протяжении всего жизненного цикла.
вызов Зефирный

Marshmallow Challenge — это поучительный дизайнерский вызов. Он включает в себя задачу построить как можно более высокую отдельно стоящую конструкцию с зефиром наверху. Конструкцию необходимо собрать за 18 минут, используя всего 20 палочек спагетти, один ярд ленты и один ярд веревки. [5] [6]
Наблюдения и исследования участников показывают, что детсадовцы регулярно способны строить более высокие конструкции по сравнению с группами выпускников бизнес-школ. Это объясняется тенденцией детей сразу же наклеивать зефир на простую конструкцию, тестировать прототип и продолжать его совершенствовать. В то время как студенты бизнес-школ склонны тратить время на борьбу за власть, планирование и, наконец, на создание структуры, к которой добавляется зефир. [7] Задача помогает создавать и развивать навыки прототипирования, командной работы, лидерства и инноваций и является популярным занятием STEM . Задача была придумана Питером Скиллманом из Palm, Inc. и популяризирована Томом Вуджеком из Autodesk . [8] [9] [10] [11] [12]
См. также [ править ]
- Подрывные инновации
- Экстремальное программирование
- Спиральная модель
- Дизайн сверху вниз и снизу вверх
- Бумажное прототипирование
- Скрам (разработка программного обеспечения)
Ссылки [ править ]
- ^ Госсейн, Санджив; Андерсон, Брюс (1990). «Модель итеративного проектирования объектно-ориентированного программного обеспечения многократного использования». Материалы Европейской конференции по объектно-ориентированному программированию по системам, языкам и приложениям объектно-ориентированного программирования - OOPSLA/ECOOP '90 . стр. 12–27. дои : 10.1145/97945.97949 . ISBN 0-89791-411-2 . S2CID 551413 .
- ^ «Краткое описание спиральной модели» (PDF) .
- ^ Нильсен, Дж. (1993). «Итеративный дизайн пользовательского интерфейса». IEEE-компьютер . 26 (11): 32–41. дои : 10.1109/2.241424 . S2CID 17748574 .
- ^ Мантей, Мэрилин М.; Теори, Тоби Дж. (1988). «Анализ затрат и выгод для включения человеческого фактора в жизненный цикл программного обеспечения» . Коммуникации АКМ . 31 (4): 428–439. дои : 10.1145/42404.42408 . S2CID 2031965 .
- ^ «Зефирный вызов» . Зефирный вызов . Проверено 10 августа 2010 г.
- ^ «Зефирный вызов» . КА: BPWrap. 22 апреля 2010 г. Проверено 10 августа 2010 г.
- ^ Йерц, Деннис Г. (10 мая 2010 г.). «Зефирный вызов — блог Джерца о грамотности» . Jerz.setonhill.edu . Проверено 10 августа 2010 г.
- ^ Кэмерон, Крис (23 апреля 2010 г.). «Зефир и спагетти: как детсадовцы думают, как бережливые стартапы» . Прочтите сайт writeweb.com. Архивировано из оригинала 21 августа 2010 г. Проверено 10 августа 2010 г.
- ^ «Зефирный вызов» . Engineeringrevision.com. 02 мая 2010 г. Проверено 10 августа 2013 г.
- ^ «Зефирный вызов» . Эгоистичное программирование . Проверено 10 августа 2013 г.
- ^ «Зефирный вызов | Факультет естественных наук | Университет Калгари» . Укалгари.ca. 13 декабря 2010 г. Проверено 10 августа 2013 г.
- ^ Original Design Challenge (27 января 2014 г.), Peter Skillman Marshmallow Design Challenge , заархивировано из оригинала 13 декабря 2021 г. , получено 12 сентября 2017 г.
- Бём, Барри В. (май 1988 г.) «Спиральная модель разработки и улучшения программного обеспечения», Компьютер, IEEE, стр. 61–72.
- Гулд, Дж. Д. и Льюис, К. (1985). Проектирование для удобства использования: ключевые принципы и что думают дизайнеры, Сообщения ACM, 28 (3) марта, 300–311.
- Крухтен, Филипп. Rational Unified Process — Введение,
- Крухтен, П. (2000). «От водопада к итеративной разработке – сложный переход для менеджеров проектов» (PDF) (Белая книга). Корпорация Рациональное программное обеспечение . Проверено 17 августа 2019 г.