Совместная разработка приложения

Ион — это термин, первоначально использовавшийся для описания процесса разработки программного обеспечения, впервые использованного и внедренного в середине 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. ^[1]

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

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

Исполнительный спонсор: Руководитель, который создает проект, владелец системы. Они должны занимать достаточно высокое положение в организации, чтобы иметь возможность принимать решения и обеспечивать необходимую стратегию, планирование и руководство.
Эксперты в предметной области: Это бизнес-пользователи, специалисты по информационным технологиям и внешние эксперты, которые потребуются для успешного проведения семинара. Эта группа является основой собрания; они будут способствовать изменениям.
Фасилитатор/руководитель сессии: собрание и направляет трафик, сохраняя группу в повестке дня собрания. Фасилитатор несет ответственность за определение тех проблем, которые можно решить в рамках встречи, и тех, которые необходимо передать в конце встречи для последующего исследования и решения. Фасилитатор обслуживает участников и не предоставляет информацию на встречу.
Писец/Моделист/Рекордер/Эксперт по документации: Записывает и публикует ход собрания и не предоставляет информацию для собрания.
наблюдатели: Обычно над проектом работают члены группы разработки приложений. Они должны сидеть позади участников и молча наблюдать за происходящим.

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

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

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

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

Проблемы

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

Ссылки

^ «БЫСТРЫЙ способ определения системных требований», Гэри Раш, Computerworld, том 19, номер 40, подробно, страницы с ID/11 по ID/16 (страницы с 47 по 52), 7 октября 1985 г. Стенограмма здесь .
^ ДЖАД | БЫСТРО | Техника структурированной фасилитации FoCuSeD™ [1] .)

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

Ятко, Мэй К. (1999). «Совместное проектирование/разработка приложений» . Университет Миссури-Сент. Луи . Проверено 6 февраля 2009 г.
Солтыс, Роман; Энтони Кроуфорд (1999). «JAD для бизнес-планов и проектов» . Архивировано из оригинала 13 марта 2009 г. Проверено 6 февраля 2009 г.
Деннис, Алан Р.; Хейс, Гленда С.; Дэниелс, Роберт М. младший (весна 1999 г.). «Моделирование бизнес-процессов с помощью систем групповой поддержки» . Журнал информационных систем управления . 15 (4): 115–142. дои : 10.1080/07421222.1999.11518224 . Проверено 14 мая 2015 г.
Боткин, Джон К. «Участие клиентов как часть процесса разработки приложений» . Архивировано из оригинала 1 декабря 1998 г.
Мёллер, Уолтер Э. «Сессии по сбору информации: метод информационной инженерии» . Проверено 22 марта 2010 г.
Билл Дженнерих «Совместная разработка приложений — анализ бизнес-требований для успешного реинжиниринга». 18:50, 26 июня 2006 г. (UTC) [2] Время последнего обновления неизвестно. Доступ осуществлен 14 ноября 1999 г.
Гэри Раш «JAD - его история и эволюция - информационный бюллетень MGR Consulting». июль 2006 г. [3]
Гэри Раш, «JAD Project Aids Design», Computerworld, Volume 18 Number 52, страницы 31 и 38, 24 декабря 1984 г. [4]
Дэвидсон, Э.Дж. (1999). «Совместное проектирование приложений (JAD) на практике». Журнал систем и программного обеспечения . 45 (3). Эльзевир Б.В.: 215–223. дои : 10.1016/s0164-1212(98)10080-8 . ISSN 0164-1212 .
Готтесдинер, Эллен; Требования в результате сотрудничества: семинары по определению потребностей , Аддисон-Уэсли, 2002 г., ISBN 0-201-78606-0 .
Вуд, Джейн и Сильвер, Дениз; Совместная разработка приложений , John Wiley & Sons Inc., ISBN 0-471-04299-4

[1] «БЫСТРЫЙ способ определения системных требований», Гэри Раш, Computerworld, том 19, номер 40, подробно, страницы с ID/11 по ID/16 (страницы с 47 по 52), 7 октября 1985 г. Стенограмма здесь .

[2] ДЖАД | БЫСТРО | Техника структурированной фасилитации FoCuSeD™ [1] .)

[1]

[2]