WikiDer > Совместное проектирование приложений - Википедия

Joint application design - Wikipedia

Совместное проектирование приложений (JAD) - это процесс, используемый в области жизненного цикла метод разработки динамических систем (DSDM) для сбора бизнес-требований при разработке новых информационные системы для компании. «Процесс JAD также включает в себя подходы для расширения участия пользователей, ускорения разработки и повышения качества спецификаций». Он состоит из мастерской, где "работники умственного труда и ИТ-специалисты встречаются, иногда на несколько дней, чтобы определить и проанализировать бизнес-требования к системе ».[1] Среди участников будут руководители высшего звена, которые обеспечат предоставление продукта необходимыми отчетами и информацией в конце. Это действует как «процесс управления, который позволяет отделам корпоративных информационных служб (ИС) более эффективно работать с пользователями в более короткие сроки».[2]

Посредством семинаров JAD специалисты по информационным технологиям и ИТ-специалисты могут разрешить любые трудности или разногласия между двумя сторонами в отношении новой информационной системы. Семинар следует подробному расписанию, чтобы гарантировать учет всех неопределенностей между сторонами и помочь предотвратить любые недопонимания. Непонимание может привести к гораздо более серьезным последствиям, если не будет решено на более позднем этапе процесса. (См. Ниже ключевые участники и ключевые шаги к эффективному JAD). В конце концов, этот процесс приведет к созданию новой информационной системы, которая станет доступной и привлекательной как для разработчиков, так и для конечных пользователей.

«Хотя дизайн JAD широко известен, на самом деле мало что известно о его эффективности на практике». Согласно Журнал систем и программного обеспечения, в трех организациях было проведено полевое исследование с использованием практик JAD, чтобы определить, как JAD влияет на результаты разработки системы. Результаты исследования показывают, что организации добились умеренного улучшения результатов разработки систем с помощью метода JAD. Использование JAD было наиболее эффективным в небольших, четко сфокусированных проектах и ​​менее эффективным в крупных сложных проектах. С 2010 года Международная ассоциация фасилитаторов (IAF) оценивает важность организованных семинаров, a la JAD, и обнаружила их значительную ценность.[3]

Источник

Совместное приложение - это термин, первоначально использовавшийся для описания процесса разработки программного обеспечения, впервые начатого и успешно развернутого в середине 1970-х годов. Нью-Йоркская телефонная компанияЦентр разработки систем под руководством Дэна Гилана. После серии замечательно успешных реализаций этой методологии, Гилан много читал на различных форумах о методологии, ее преимуществах и передовом опыте. Арни Линд, затем старший системный инженер в IBM Canada в Регина, Саскачеван создал и назвал совместный дизайн приложения в 1974 году. Это было усовершенствованием существующих методов, в результате которого разработчики приложений тратили месяцы на изучение специфики конкретного отдела или должностной функции, а затем разрабатывали приложение для этой функции или отдела. Помимо значительных задержек в разработке, этот процесс приводил к тому, что приложения разрабатывались годами и часто не были полностью приняты пользователями приложений.

Идея Арни Линда была проста: вместо того, чтобы заставлять разработчиков приложений узнавать о работе людей, почему бы не научить людей, выполняющих эту работу, как писать приложение? Арни представил концепцию вице-президенту IBM Canada Карлу Коркорану (впоследствии президент IBM Canada), и Карл одобрил пилотный проект. Арни и Карл вместе назвали методологию JAD, аббревиатурой от совместного проектирования приложений, после того, как Карл Коркоран отказался от аббревиатуры JAL, или совместной логистики приложений, после того, как понял, что инициалы Арни Линда были JAL (Джон Арнольд Линд).

Пилотный проект был проектом отделения неотложной помощи для правительства Саскачевана. Арни разработал методологию JAD и провел недельный семинар, в котором участвовали в основном медсестры и администраторы из отделения неотложной помощи, а также некоторые специалисты по разработке приложений. Проект имел огромный успех, поскольку на недельном семинаре была разработана детальная структура приложения, которая затем была закодирована и реализована менее чем за месяц, по сравнению со средним сроком 18 месяцев для традиционной разработки приложений. А поскольку пользователи сами разработали систему, они сразу же приняли приложение и им понравилось. После пилотного проекта IBM очень поддержала методологию JAD, поскольку увидела в ней способ более быстрого внедрения вычислительных приложений, работающих на оборудовании IBM.

Арни Линд провел следующие 13 лет в IBM Canada, продолжая развивать методологию JAD и путешествуя по миру, проводя семинары по JAD и обучая сотрудников IBM методам и приемам JAD. JAD широко выполнялись по всей IBM Canada, и эта техника также распространилась на IBM в Соединенных Штатах. Арни Линд обучил нескольких человек в IBM Canada выполнять JAD, включая Тони Кроуфорда и Чака Морриса. Арни Линд ушел из IBM в 1987 году и продолжил обучать и выполнять JAD на консультационной основе по всей Канаде, США и Азии.

Процесс JAD был формализован Тони Кроуфордом и Чаком Моррисом из IBM в конце 1970-х годов. Затем он был развернут в Canadian International Paper. JAD некоторое время использовался в IBM Canada, прежде чем был возвращен в США. Первоначально IBM использовала JAD для продажи и реализации продаваемой ими программы под названием COPICS. Он был широко адаптирован для многих целей (системные требования, конструкция элеватора, решение проблем и т. Д.). Позже Тони Кроуфорд разработал JAD-Plan, а затем JAR (требования к совместным приложениям). В 1985 году Гэри Раш написал о JAD и его производных - методах упрощенной спецификации приложений (FAST) - в Computerworld.[4]

Первоначально JAD был разработан, чтобы объединить разработчиков систем и пользователей с разным опытом и мнениями в продуктивной, а также творческой среде. Встречи были способом получения требований к качеству и спецификаций. Структурированный подход представляет собой хорошую альтернативу традиционным серийным интервью системным аналитикам. С тех пор JAD расширился, чтобы охватить более широкую ИТ-работу, а также не-ИТ-работу (прочтите об упрощенных методах спецификации приложений - FAST, созданных Гэри Рашем в 1985 году для расширения применимости JAD.[5]

Ключевые участники

Исполнительный спонсор: Руководитель, учредивший проект, владелец системы. Они должны быть достаточно высоки в организации, чтобы иметь возможность принимать решения и обеспечивать необходимую стратегию, планирование и направление.

Эксперты в предметной области: Это бизнес-пользователи, профессионалы в области ИБ и внешние эксперты, которые потребуются для успешного семинара. Эта группа - костяк собрания; они будут способствовать изменениям.

Фасилитатор / руководитель сессии: встречается и направляет движение, оставляя группу в повестке дня собрания. Фасилитатор отвечает за определение тех вопросов, которые могут быть решены в рамках встречи, и тех, которые необходимо назначить в конце встречи для последующего расследования и решения. Фасилитатор обслуживает участников и не передает информацию собранию.

Писец / моделист / регистратор / эксперт по документации: Записывает и публикует протокол собрания и не предоставляет информацию для собрания.

Наблюдатели: Обычно члены группы разработки приложений, назначенные для проекта. Они должны сидеть позади участников и молча наблюдать за происходящим.

9 ключевых шагов

  1. Определите цели и ограничения проекта: Очень важно иметь четкие цели для семинара и для проекта в целом. Мероприятия перед семинаром, планирование и определение объема работ определяют ожидания спонсоров и участников семинара. Определение объема определяет бизнес-функции, которые находятся в рамках проекта. Он также пытается оценить как дизайн проекта, так и сложность реализации. Следует оценить политическую чувствительность проекта. Пробовали ли это в прошлом? Сколько было фальстартов? Сколько было сбоев в реализации? Размер важен. Для достижения наилучших результатов системные проекты должны иметь такой размер, чтобы полный дизайн - вплоть до экранов и меню - можно было разработать за 8–10 рабочих дней.
  2. Определите важнейшие факторы успеха: Важно определить критические факторы успеха как для проекта развития, так и для изучаемой бизнес-функции. Как мы узнаем, что запланированные изменения были эффективными? Как будет измеряться успех? Планирование оценки результатов помогает судить об эффективности и качестве внедренной системы на протяжении всего срока ее эксплуатации.
  3. Определите результаты проекта: В общем, результаты семинара - это документация и дизайн. Важно определить форму и уровень детализации документации семинара. Какие типы диаграмм будут предоставлены? Какой тип или форма повествования будет предоставлена? Хорошая идея начать использовать ДЕЛО инструмент для создания диаграмм поддержки с самого начала. Большинство доступных инструментов имеют хорошие или большие возможности построения диаграмм, но их повествовательная поддержка, как правило, слабая. Повествование лучше всего создавать с помощью стандартного программного обеспечения для обработки текстов.
  4. Определите график работы семинара: Семинары различаются по продолжительности от одного до пяти дней. Начальный семинар по проекту должен длиться не менее трех дней. Большую часть первого дня участникам требуется, чтобы освоиться со своими ролями, друг с другом и с окружающей средой. Второй день посвящен тому, чтобы научиться понимать друг друга и выработать общий язык для обсуждения вопросов и проблем. К третьему дню все вместе работают над проблемой и достигают реальной продуктивности. После первого семинара был проведен тимбилдинг. Более короткие семинары могут быть запланированы для последующих этапов проекта, например, для проверки прототипа. Тем не менее, участникам потребуется от одного до трех часов, чтобы восстановить командную психологию первоначального семинара.
  5. Выберите участников: Это бизнес-пользователи, ИТ-специалисты и внешние эксперты, которые потребуются для успешного семинара. Это настоящие «костяки» собрания, которые будут двигать изменения.
  6. Подготовьте материал для семинара: Перед семинаром менеджер проекта и фасилитатор проводят анализ и создают предварительный проект или соломенный человек, чтобы сфокусировать семинар. Материал семинара состоит из документации, рабочих листов, диаграмм и даже реквизита, которые помогут участникам понять исследуемую бизнес-функцию.
  7. Организуйте семинары и упражнения: Фасилитатор должен разработать упражнения и мероприятия семинара, чтобы обеспечить промежуточные результаты, которые будут способствовать окончательному результату семинара. Действия перед семинаром помогают разработать эти упражнения. Например, что в нем содержится для анализа бизнес-сферы? Диаграмма разложения? Диаграмма отношения сущностей высокого уровня? Нормализованная модель данных? Диаграмма перехода состояний? Диаграмма зависимости? Все вышеперечисленное? Ни один из вышеперечисленных? Важно определить уровень технических схем, соответствующий окружающей среде. Самое важное в диаграмме - это то, что пользователи должны ее понимать. После того, как выбор схемы сделан, фасилитатор вносит упражнения в программу семинара, чтобы группа разработала эти схемы. Семинар сочетает в себе упражнения, которые последовательно ориентированы друг на друга, и параллельные упражнения, при этом каждая подгруппа работает над частью проблемы или над одним и тем же для другой функциональной области. Упражнения высокой интенсивности под руководством фасилитатора заряжают группу энергией и направляют ее на достижение конкретной цели. Упражнения низкой интенсивности позволяют детально обсудить ситуацию до принятия решения. В обсуждениях может участвовать вся группа, или команды могут проработать проблемы и представить ограниченное количество предложений для рассмотрения всей группой. Для интеграции участников фасилитатор может подбирать людей с аналогичным опытом из разных отделов. Чтобы помочь участникам учиться друг у друга, фасилитатор может комбинировать опыт. Фасилитатор должен смешивать и подбирать членов подгруппы для достижения организационных, культурных и политических целей семинара. Мастерская работает как на техническом, так и на политическом уровне. Работа фасилитатора заключается в достижении консенсуса и общении, чтобы устранить проблемы на ранних этапах процесса. Нет необходимости беспокоиться о технической реализации системы, если основные бизнес-проблемы не могут быть решены.
  8. Подготовить, проинформировать, обучить участников семинара: Все участники семинара должны быть осведомлены о целях и ограничениях проекта, а также ожидаемых результатах семинара. Инструктаж участников должен быть проведен за 1–5 дней до семинара. Этот брифинг может проводиться в режиме телеконференции, если участники рассредоточены. Информационный документ может называться «Ознакомительное руководство», «Информационное руководство», «Определение содержания проекта» или «Руководство по определению руководства» или что-то еще, что кажется подходящим. Это документ объемом от восьми до двенадцати страниц, и он дает участникам четкое определение масштабов проекта. Сам брифинг длится от двух до четырех часов. Он обеспечивает психологическую подготовку, необходимую каждому для перехода на семинар.
  9. Координировать логистику мастерской: Семинары должны проводиться за пределами объекта, чтобы избежать перерывов. Необходимо подготовить проекторы, экраны, ПК, столы, маркеры, малярную ленту, стикеры и многое другое. Какие именно средства и реквизиты необходимы, зависит от фасилитатора. Они могут варьироваться от простых флипчартов до электронных досок. В любом случае планировка комнаты должна способствовать общению и взаимодействию участников.

Преимущества

  • JAD сокращает время и затраты, связанные с процессом сбора требований. В течение 2-4 недель не только собирается информация, но и выявляются требования, согласованные различными пользователями системы. Опыт работы с JAD позволяет компаниям преобразовывать свой процесс системного анализа в еще более динамичные процессы, например Двойная спираль, методика для критически важной работы.
  • Сессии JAD помогают объединить экспертов, давая им возможность поделиться своими взглядами, понять взгляды других и развить чувство сопричастности к проекту.
  • Методы реализации JAD хорошо известны, так как это «первая технология ускоренного проектирования, доступная на рынке и, вероятно, наиболее известная», и ее может легко применить любая организация.
  • Простая интеграция инструментов CASE в семинары JAD повышает продуктивность сеансов и предоставляет системным аналитикам обсуждаемые и готовые к использованию модели.

Вызовы

  • Без многогранной подготовки к сеансу JAD драгоценное время профессионалов может быть легко потрачено зря. Если организаторы сеанса JAD не изучают элементы оцениваемой системы, может быть решена некорректная проблема, могут быть приглашены неправильные люди и могут быть использованы неадекватные ресурсы для решения проблем.
  • Среди участников семинара JAD должны быть сотрудники, способные внести свой вклад в большинство, если не все, относящиеся к проблеме области. Вот почему при отборе участников следует уделять особое внимание. Группа должна состоять не только из сотрудников разных отделов, которые будут взаимодействовать с новой системой, но и из разных иерархий организационной лестницы. У участников могут быть противоречивые точки зрения, но встреча позволит участникам увидеть проблемы с разных точек зрения. JAD позволяет лучше понять схему модели с лучшим пониманием основных процессов.
  • Фасилитатор обязан обеспечить всем участникам - не только самым громким - возможность высказать свое мнение, идеи и мысли.

Рекомендации

  1. ^ Хааг, Стивен; Каммингс, Мейв; Маккаббри, Дональд Дж. (2006). «Фаза 2: Анализ». Системы управления информацией для информационного века. Макгроу-Хилл Райерсон. ISBN 978-0-07-281947-2.
  2. ^ Дженнерих, Билл (ноябрь 1990). «Совместное проектирование приложений: анализ бизнес-требований для успешной реинжиниринга». Архивировано из оригинал 21 февраля 2009 г.. Получено 2009-02-06.
  3. ^ Гэри Раш, 2013 г., «Насколько важна упрощение формальностей?»[1]
  4. ^ «БЫСТРЫЙ способ определения системных требований», Гэри Раш, Computerworld, том 19 номер 40, подробные страницы с ID / 11 по ID / 16 (страницы с 47 по 52), 7 октября 1985 г. Стенограмма здесь.
  5. ^ JAD | БЫСТРО | Метод структурированной фасилитации FoCuSeD ™[2].)

Библиография