Совместное проектирование приложений ( 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]
Ключевые участники
Исполнительный спонсор : руководитель, учредивший проект, владелец системы. Они должны быть достаточно высоки в организации, чтобы иметь возможность принимать решения и обеспечивать необходимую стратегию, планирование и направление.
Эксперты в предметной области : это бизнес-пользователи, специалисты по ИБ и внешние эксперты, которые потребуются для успешного семинара. Эта группа - костяк собрания; они будут управлять изменениями.
Фасилитатор / руководитель сессии : встречается и направляет движение, оставляя группу в повестке дня встречи. Фасилитатор отвечает за определение тех вопросов, которые могут быть решены в рамках встречи, и тех, которые необходимо назначить в конце встречи для последующего расследования и решения. Фасилитатор обслуживает участников и не передает информацию собранию.
Scribe / Modeller / Recorder / Documentation Expert : записывает и публикует протокол собрания и не предоставляет информацию для собрания.
Наблюдатели : обычно члены группы разработки приложений, назначенные для проекта. Они должны сидеть позади участников и молча наблюдать за происходящим.
9 ключевых шагов
- Определите цели и ограничения проекта : очень важно иметь четкие цели семинара и проекта в целом. Мероприятия перед семинаром, их планирование и анализ определяют ожидания спонсоров и участников семинара. Определение объема определяет бизнес-функции, которые входят в объем проекта. Он также пытается оценить как дизайн проекта, так и сложность его реализации. Следует оценить политическую чувствительность проекта. Пробовали ли это в прошлом? Сколько было фальстартов? Сколько было сбоев в реализации? Размер важен. Для достижения наилучших результатов системные проекты должны иметь такой размер, чтобы полный дизайн - вплоть до экранов и меню - можно было разработать за 8–10 рабочих дней.
- Определите критические факторы успеха : важно определить критические факторы успеха как для проекта разработки, так и для изучаемой бизнес-функции. Как мы узнаем, что запланированные изменения были эффективными? Как будет измеряться успех? Планирование оценки результатов помогает судить об эффективности и качестве внедренной системы на протяжении всего срока ее эксплуатации.
- Определите результаты проекта : как правило, результатами семинара являются документация и дизайн. Важно определить форму и уровень детализации документации семинара. Какие типы диаграмм будут предоставлены? Какой тип или форма повествования будет предоставлена? Рекомендуется с самого начала использовать инструмент CASE для создания диаграмм поддержки. Большинство доступных инструментов обладают хорошими или большими возможностями построения диаграмм, но их повествовательная поддержка, как правило, слабая. Повествование лучше всего составлять с помощью стандартного текстового редактора.
- Определите график работы семинара : Семинары различаются по продолжительности от одного до пяти дней. Начальный семинар по проекту должен длиться не менее трех дней. Большую часть первого дня участникам требуется, чтобы освоиться со своими ролями, друг с другом и с окружающей средой. Второй день посвящен тому, чтобы научиться понимать друг друга и выработать общий язык для обсуждения вопросов и проблем. К третьему дню все вместе работают над проблемой и достигают реальной продуктивности. После первого семинара был проведен тимбилдинг. Более короткие семинары могут быть запланированы для последующих этапов проекта, например, для проверки прототипа. Однако участникам потребуется от одного до трех часов, чтобы восстановить командную психологию первоначального семинара.
- Выберите участников : это бизнес-пользователи, ИТ-специалисты и внешние эксперты, которые потребуются для успешного семинара. Это настоящие «костяки» собрания, которые будут двигать изменения.
- Подготовьте материалы для семинара : перед семинаром менеджер проекта и фасилитатор проводят анализ и создают предварительный проект или соломенный человек, чтобы сосредоточить внимание на семинаре. Материал семинара состоит из документации, рабочих листов, диаграмм и даже реквизита, которые помогут участникам понять исследуемую бизнес-функцию.
- Организуйте мероприятия и упражнения семинара : фасилитатор должен разработать упражнения и мероприятия семинара, чтобы обеспечить промежуточные результаты, которые будут способствовать окончательному результату семинара. Действия перед семинаром помогают разработать эти упражнения. Например, что в нем содержится для анализа бизнес-сферы? Диаграмма разложения? Диаграмма отношения сущности высокого уровня? Нормализованная модель данных? Диаграмма перехода состояний? Диаграмма зависимости? Все вышеперечисленное? Ни один из вышеперечисленных? Важно определить уровень технических схем, соответствующий окружающей среде. Самое важное в диаграмме - это то, что пользователи должны ее понимать. После того, как выбор схемы сделан, фасилитатор вносит упражнения в программу семинара, чтобы группа разработала эти схемы. Семинар объединяет упражнения, которые последовательно ориентированы друг на друга, и параллельные упражнения, при этом каждая подгруппа работает над частью проблемы или над одним и тем же для другой функциональной области. Упражнения высокой интенсивности под руководством фасилитатора заряжают группу энергией и направляют ее на достижение конкретной цели. Упражнения низкой интенсивности позволяют детально обсудить ситуацию перед принятием решения. В обсуждениях может участвовать вся группа, или команды могут проработать проблемы и представить ограниченное количество предложений для рассмотрения всей группой. Для интеграции участников фасилитатор может подбирать людей с аналогичным опытом из разных отделов. Чтобы помочь участникам учиться друг у друга, фасилитатор может комбинировать опыт. Фасилитатор должен смешивать и подбирать членов подгруппы для достижения организационных, культурных и политических целей семинара. Мастерская работает как на техническом, так и на политическом уровне. Работа фасилитатора состоит в том, чтобы достичь консенсуса и коммуникации, чтобы устранить проблемы на ранних этапах процесса. Нет необходимости беспокоиться о технической реализации системы, если основные бизнес-проблемы не могут быть решены.
- Подготовьте, проинформируйте, обучите участников семинара : Все участники семинара должны быть осведомлены о целях и ограничениях проекта и ожидаемых результатах семинара. Инструктаж участников должен проводиться за 1–5 дней до семинара. Этот брифинг может проводиться в режиме телеконференции, если участники рассредоточены. Информационный документ может называться «Ознакомительное руководство», «Краткое руководство», «Определение содержания проекта» или «Руководство по определению руководства» или что-то еще, что кажется подходящим. Это документ объемом от восьми до двенадцати страниц, и он дает участникам четкое определение масштабов проекта. Сам брифинг длится от двух до четырех часов. Он обеспечивает психологическую подготовку, необходимую каждому для перехода на семинар.
- Координируйте логистику семинара: семинары следует проводить за пределами объекта, чтобы избежать перерывов. Необходимо подготовить проекторы, экраны, ПК, столы, маркеры, малярную ленту, стикеры и многое другое. Какие именно приспособления и реквизиты необходимы, зависит от фасилитатора. Они могут варьироваться от простых флипчартов до электронных досок. В любом случае планировка комнаты должна способствовать общению и взаимодействию участников.
Преимущества
- JAD сокращает время и затраты, связанные с процессом сбора требований. В течение 2-4 недель не только собирается информация, но и выявляются требования, согласованные различными пользователями системы. Опыт работы с JAD позволяет компаниям преобразовывать свои процессы системного анализа в еще более динамичные, такие как Double Helix , методология для критически важной работы.
- Сессии JAD помогают объединить экспертов, давая им возможность поделиться своими взглядами, понять взгляды других и развить чувство сопричастности к проекту.
- Методы реализации JAD хорошо известны, так как это «первая технология ускоренного проектирования, доступная на рынке и, вероятно, наиболее известная», и может легко применяться любой организацией.
- Простая интеграция инструментов CASE в семинары JAD повышает продуктивность сеансов и предоставляет системным аналитикам обсуждаемые и готовые к использованию модели.
Вызовы
- Без многогранной подготовки к сеансу JAD драгоценное время профессионалов может быть легко потрачено зря. Если организаторы сеанса JAD не изучают элементы оцениваемой системы, может быть решена некорректная проблема, могут быть приглашены неправильные люди и могут быть использованы неадекватные ресурсы для решения проблем.
- Среди участников семинара JAD должны быть сотрудники, способные внести свой вклад в большинство, если не все, относящиеся к делу области проблемы. Вот почему при отборе участников следует уделять особое внимание. Группа должна состоять не только из сотрудников разных отделов, которые будут взаимодействовать с новой системой, но и из разных иерархий организационной лестницы. У участников могут быть противоречивые точки зрения, но встреча позволит участникам увидеть проблемы с разных точек зрения. JAD позволяет лучше понять схему модели с лучшим пониманием основных процессов.
- Фасилитатор обязан обеспечить всем участникам - не только самым громким - возможность высказать свое мнение, идеи и мысли.
Рекомендации
- ^ Хааг, Стивен; Каммингс, Мейв; МакКаббри, Дональд Дж. (2006). «Фаза 2: Анализ». Системы управления информацией для информационного века . Макгроу-Хилл Райерсон. ISBN 978-0-07-281947-2.
- ^ Дженнерих, Билл (ноябрь 1990). «Совместное проектирование приложений: анализ бизнес-требований для успешной реинжиниринга» . Архивировано из оригинала на 2009-02-21 . Проверено 6 февраля 2009 . CS1 maint: обескураженный параметр ( ссылка )
- ^ Гэри Раш, 2013, «Насколько важна помощь?» [1]
- ^ "БЫСТРЫЙ способ определения системных требований", Гэри Раш, Computerworld, том 19 номер 40, подробные страницы с ID / 11 по ID / 16 (страницы с 47 по 52), 7 октября 1985 г. Стенограмма здесь .
- ^ JAD | БЫСТРО | Метод структурированной фасилитации FoCuSeD ™ [2] .)
Библиография
- Ятко, Мэй К. (1999). «Совместное проектирование / разработка приложений» . Университет Миссури-Св. Луи . Проверено 6 февраля 2009 . CS1 maint: обескураженный параметр ( ссылка )
- Солтыс, Роман; Энтони Кроуфорд (1999). «JAD для бизнес-планов и дизайнов» . Архивировано из оригинала на 2009-03-13 . Проверено 6 февраля 2009 . CS1 maint: обескураженный параметр ( ссылка )
- Деннис, Алан Р .; Hayes, Glenda S .; Дэниелс, Роберт М. младший (весна 1999 г.). «Моделирование бизнес-процессов с системами групповой поддержки» . Журнал информационных систем управления . 15 (4): 115–142. DOI : 10.1080 / 07421222.1999.11518224 . Проверено 14 мая 2015 . CS1 maint: обескураженный параметр ( ссылка )
- Боткин, Джон К. «Привлечение клиентов как часть процесса разработки приложений» . Архивировано из оригинала на 1998-12-01 . Проверено 9 ноября 1999 . Проверить значения даты в:
|accessdate=
( помощь )CS1 maint: обескураженный параметр ( ссылка ) - Мёллер, Уолтер Э. "Сессии по сбору информации: техника информационной инженерии" . Проверено 22 марта 2010 . CS1 maint: обескураженный параметр ( ссылка )
- Билл Дженнерих «Совместное проектирование приложений - анализ бизнес-требований для успешной реинжиниринга». 18:50, 26 июня 2006 г. (UTC) [3] Время последнего обновления неизвестно. Доступ 14 ноября 1999 г.
- Гэри Раш «JAD - Его история и эволюция - Информационный бюллетень MGR Consulting». Июль 2006 г. [4]
- Гэри Раш, "JAD Project Aids Design", Computerworld, том 18 номер 52, страницы 31 и 38, 24 декабря 1984 г. [5]
- Дэвидсон, EJ (1999). Совместное проектирование приложений (JAD) на практике. Журнал систем и программного обеспечения, 45 (3), 215-223. Получено из базы данных Science Direct. [6]
- Готтесдинер, Эллен; Требования к сотрудничеству: семинары по определению потребностей , Аддисон-Уэсли, 2002 г., ISBN 0-201-78606-0 .
- Вуд, Джейн и Сильвер, Дениз; Совместная разработка приложений , John Wiley & Sons Inc, ISBN 0-471-04299-4