Совместное проектирование приложений

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

Идея Арни Линда заключалась в том, что вместо того, чтобы разработчики приложений узнавали о работе людей, можно было бы научить людей, выполняющих эту работу, писать приложения. Арни представил концепцию вице-президенту IBM Canada Карлу Коркорану (позднее президенту IBM Canada), и Карл одобрил пилотный проект. Арни и Карл вместе назвали методологию JAD, аббревиатурой от Joint Application Design, после того как Карл Коркоран отклонил аббревиатуру JAL, или Joint Application Logistics, поняв, что инициалы Арни Линда были 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 и его производных – Facilitated Application Specification Techniques (FAST) – в Computerworld. ^[1]

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

Исполнительный спонсор

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

Эксперты по предметной области

Это бизнес-пользователи, специалисты по ИС и внешние эксперты, которые понадобятся для успешного семинара. Эта группа является костяком встречи; они будут движущей силой изменений.

Ведущий/руководитель сессии

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

Писец/Моделист/Регистратор/Эксперт по документации

Записывает и публикует протоколы заседания и не предоставляет никакой информации для заседания.

Наблюдатели

Обычно это члены команды разработчиков приложений, назначенные на проект. Они должны сидеть позади участников и молча наблюдать за процессом.

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

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

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

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