Платформа P-моделирования

P-Modeling Framework — это пакет рекомендаций, методов, инструментов и шаблонов для улучшения процесса разработки . P-Modeling Платформа может быть интегрирована в любой другой SDLC используемый , например, MSF Agile , MSF CMMI , RUP и т. д.

История

Истоки P-Modeling Framework берут свое начало из «Вавилонского эксперимента», разработанного Владимиром Павловым в 2001 году как учебная программа для студентов- разработчиков программного обеспечения , целью которой было заставить студентов пройти «сокращенную» версию коммуникационных проблем, типичных для разработки программного обеспечения. и получить опыт применения UML для решения этих проблем.

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

Чуть позже, во время сеанса проектирования, над одной и той же задачей работали две независимые команды. Средства общения первой команды были ограничены UML, как описано выше, тогда как другой команде было разрешено общаться устно, используя естественный язык. Оказалось, что первая, более ограниченная команда, справилась с задачей эффективнее другой. , UML-диаграммы созданные первой командой, были более надежными, подробными, читабельными и проработанными.

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

Некоторые интерпретации этих результатов следующие:

Ограничение на использование естественного языка может стимулировать творческие способности дизайнеров, а также заставлять их сосредоточиться на своей работе;
Работа в безмолвном режиме может заставить дизайнеров явно раскрыть все основные предположения на самых ранних стадиях процесса проектирования;
UML не рассматривается как лишнее бремя, не имеющее отношения к реальным потребностям (как язык «только для записи») — вместо этого дизайнеры могут начать демонстрировать большую заботу о качестве и читаемости своих моделей.

После этого были выработаны идеи проведения дополнительных новых экспериментов с целью найти метод сравнения UML с естественными языками. Предпосылкой этих экспериментов была постановка задач прямого (с естественного языка на UML) и обратного (с UML на естественный язык) задач «перевода» для двух команд профессиональных разработчиков программного обеспечения. Это будет сделано, когда одна команда будет выполнять прямой перевод, а другая — обратный перевод. Намерение состояло в том, чтобы наблюдать, насколько близко результат обратного перевода напоминает исходный текст, обеспечивая тем самым проверку правильности модели UML.

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

Эксперименты показали, что модель всего цикла разработки программного обеспечения существует как серия переводов. В последующих экспериментах проверка обратного перевода была продемонстрирована как метод, помогающий гарантировать, что результаты каждого этапа разработки не потеряют и не неверно истолкуют все, что было создано на предыдущем этапе. Этот метод получил название «Обратная семантическая прослеживаемость». Это оказалось надежным завершением второй части P-Modeling Framework.

Основные принципы

Обратная семантическая прослеживаемость

Обратная семантическая прослеживаемость — это метод контроля качества , который позволяет тестировать результаты каждого этапа перевода. Прежде чем перейти к следующему этапу, текущие артефакты подвергаются « обратному проектированию », а восстановленный текст сравнивается с оригиналом. Если между этими двумя текстами есть разница — тестируемые артефакты исправляются для устранения проблемы (или исправляется исходный текст). Следовательно, каждый шаг подтверждается отступлением и уверенностью, что разработка идет по правильному пути. Таким образом, проблемы могут быть обнаружены и устранены без задержек, поэтому они не накапливаются и не переходят на последующие этапы цикла разработки.
Ключевое слово в названии этого метода — « Семантический ». Он основан на том, что исходный и восстановленный варианты текста необходимо сравнивать семантически, ориентируясь на «смысл» текста, а не на отдельные «слова», использованные в нем.

Самые распространенные сценарии использования, о которых сообщили первые пользователи метода обратной семантической прослеживаемости:

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

Безмолвное моделирование

Изначально разработанное как курс повышения квалификации для обучения студентов объектно-ориентированному анализу и проектированию с использованием UML, «Безмолвное моделирование», по сути, представляет собой ограничение на использование средств коммуникации, прямо или косвенно связанных с естественным языком. Таким образом, команда дизайнеров вынуждена использовать язык моделирования как единственный язык, доступный для общения во время сеанса проектирования.

Включение платформы P-Modeling Framework в жизненный цикл разработки программного обеспечения (SDLC)

Независимо от того, какой тип процесса разработки используется в организации; водопад , спираль , различные итеративно-инкрементальные или некоторые другие, существуют определенные процессы, такие как проектирование программного обеспечения , контроль качества , управление человеческими ресурсами , управление рисками , управление коммуникациями и т. д., к которым могут быть применены принципы P-Modeling Framework, особенно на ранних стадиях проекта , когда мероприятия по контролю качества либо незначительны, либо (практически) отсутствуют.

Требования и ограничения

Все участники сессии P-Modeling должны свободно говорить на каком-либо языке графического моделирования .
Для полноценного сеанса P-моделирования требуется минимум 8 квалифицированных специалистов.
Для эффективной сессии RST требуется минимум 3 квалифицированных человека.
P-modeling Framework не предоставляет возможности обнаружить неоднозначные, противоречивые и неполные аспекты в требованиях или запросах клиентов.
Сессия безмолвного моделирования требует от участников большого количества энергии и усилий.

Критика

Очевидно, что P-Modeling Framework имеет возможности для дальнейшего совершенствования. Например:

Сеансы P-моделирования требуют дополнительных ресурсов без знания исходного артефакта и добавляют дополнительную нагрузку на программистов .
При выполнении RST тексты приходится сравнивать вручную, а это означает, что в фреймворке отсутствует автоматизация.
Одним из возможных результатов RST является ситуация, когда люди «проектируют для RST» — они создают артефакты таким образом, чтобы их можно было легко реконструировать, не добавляя новой ценности.
Надежных статистических данных об эффективности P-Modeling Framework нет.
«Сеансы тихого проектирования» имеют довольно узкую применимость: только для систем и организаций, которые могут и должны документировать систему на языке графического моделирования. Это не тот случай, когда:
- В компании не хватает разработчиков, «свободно владеющих любым языком графического моделирования» и знающих, когда и как его применять, а значит очень высокой квалификации.
- Компания не использует широко языки графического моделирования.
Сеансы P-моделирования не помогут отличить хороший дизайн от плохого.

Ссылки

Владимир Павлов, Антон Яценко. Использование пантомимы в обучении OOA&OOD с помощью UML . 18-я конференция IEEE по образованию и обучению программной инженерии (CSEE&T) , Оттава, Канада.
Владимир Павлов, Антон Яценко. Вавилонский эксперимент: расширенное обучение ООА и ООД на основе пантомимы с помощью UML . 36-й Технический симпозиум ACM по образованию в области компьютерных наук (SIG CSE 2005) , Сент-Луис, Миссури, США.

Внешние ссылки