Итеративный цикл автор/рецензент.

Опишем одну интересную и крайне полезную технику использования визуального моделирования при выявлении знаний о какой-либо предметной области через общение с экспертами (специалистами в этой предметной области). Эта техника называется цикл автор/рецензент (Reader/Author Cycle review process) и может применяться, например, при работе с диаграммами случаев использования. при работе как с UML, так и с любым другим языком визуального моделирования. Эта техника была определена в рамках методологии SADT.

Активный сотрудник — автор визуальных моделей (author), — изучает не вполне знакомую ему область знаний. При этом автору постоянно нужна обратная связь с экспертами в этой предметной области, чтобы он осознавал, насколько правильно он понял и адекватно формализовал тот или иной аспект изучаемых знаний.

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

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

· автор (author) модели — тот, кто ее создает;

· эксперт (commenter) — это специалист в той предметной области, для которой строится данная модель; автор интервьюирует эксперта, получая необходимую для моделирования информацию; эксперт просматривает и комментирует созданные автором диаграммы; важно, что эксперт выражает свои комментарии в письменном виде и разделяет с автором ответственность за качество создаваемых моделей; эксперт может быть также архитектором системы, который активно участвует в процессе разработки модели анализа — но не как автор моделей (у него хватает других забот), а как активный критик (при разработке архитектуры системы он будет активно использовать эту модель);

· читатель (reader) — во всем похож на эксперта, но не обязан давать письменные комментарии к моделям и не несет ответственности за качество моделирования.

Получив диаграммы автора, эксперт их тщательно просматривает и пишет свои комментарии (прямо на диаграмме, в виде примечаний, красной ручкой). Автор, получив назад свои диаграммы с комментариями, обязан отреагировать на каждое замечание — пометить синей ручкой на той же копии, принимает ли он замечание или нет. Принятые замечания он учитывает в следующей версии диаграмм, неприятые отсылает обратно эксперту с мотивировкой. В случае возникновения непонимания организуется встреча автора и эксперта, на которой они улаживают все рассогласования.

Кроме автора, эксперта и читателя в цикле "читатель/автор" имеются также следующие роли:

· библиотекарь (librarian) — это главный координатор процесса моделирования; он следит за тем, чтобы все участники процесса вовремя получали свежие копии моделей, чтобы эти копии не терялись и вовремя попадали в архив, а последний был бы доступен; в его компетенцию входит также отслеживать, что все замечания экспертов и читателей обработаны автором, не оставлены без внимания; раньше, когда метод SADT только появился, роль библиотекаря была велика — модели строились на бумаге; теперь же для этого используют разные графические пакеты, а для хранения разных версий модели — программные средства управления версиями;

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

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

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

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

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

На рис. 8.3 показана начальная диаграмма, которую нарисовал автор для первой встречи с экспертом. На ней присутствуют только интерфейсы с диаграмм компонент UML и комментарии к ним. На рис. 8.4 представлена заключительная диаграмма, получившаяся в итоге многочисленных итераций. На ней присутвуют мнгочисленные компоненты системы, сгруппированные по уровням.

Рис. 8.3.Пример исходной, первой диаграммы.

Карты памяти.

Карты памяти (Mind Maps) – техника работы с различными знаниями, предложенная и развитая английским психологом Тони Бьюзеном в конце 70-х годов прошлого века. Она очень простая и используется при работе с информацией любого вида, для ее структурирования, осмысления, лучшего усвоения и запоминания. На листе бумаги, в центре, рисуется объект, обозначающий ту тему или предмет, который мы рассматриваем. Далее рисуются вторичные объекты, которые поясняют и уточняют данный и соединяются с ним дугами. И так далее. Пример представлен на рис. 8.5.

Рис. 8.5.

Дизайн идей. Карты памяти позволяют выполнить "дизайн идей". Очень часто мы, как следует не подумав, начинаем что-то делать – писать большой текст, с кем-то встречаться, кем-то руководить и пр. И оказывается, что понимание по ходу дела возникает трудно и мучительно. Более того, мы вынуждены переделывать то, что уже сделали без этого понимания. Хорошая иллюстрация – работа над текстом (диплома, курсовой работы, статьи, книги и пр.). Кардинально переделывать текст очень тяжело. А если при этом соавторов несколько? Карты памяти здесь очень хорошо работают, так как позволяют в компактном виде делать пробы и ошибки, видя всю картину перед собой. Ее легко также обсуждать в таком виде с другими людьми. Но здесь не нужно фанатизма. Можно и написать текст, если он легко "выливается" из вас. И снова вернуться к схеме – многое на ней может проясниться.

Планирование детальной информации. Метод позволяет также выполнить детальное планирование большого объема информации, имеющей огромное количество важных деталей. Например, мы использовали карты памяти при проектировании анкеты - она содержала достаточное количество ветвлений, списки вопросов и пр. Все это в общем виде, сокращенно, было не представить, карты памяти, поддержанные программным инструментом Comapping¹ нам здесь очень помогли. Пример представлен на рис. 8.6.

увеличить изображение
Рис. 8.6.

Реструктуризация. Карты памяти полезны при реструктуризации знаний. Например, при реструктуризации статьи. У нас был случай, когда результаты были получены, материал собран и изложен, но достаточно хаотично. Мы выполнили реструктуризацию статьи с помощью карт памяти (модель представлена на рис. 8.7) и по этой модели быстро переписали текст. Исправления прямо по тексту затянули бы весь процесс. Кроме того, карты памяти позволили разделить работу между соавторами – один создал новый план, а второй его реализовал в новой версии текста.

увеличить изображение
Рис. 8.7.

Метод реструктуризации широко используется при работе со знаниями, например, при выявлении и анализе требований. Построить представление той же информации, но с другой точки зрения – верный способ найти незамеченные ранее противоречия, "темные углы", углубить свое понимание.

Работа с краткосрочной памятью. Часто бывает, что прослушав лекцию, мы какое-то время помним ее содержание (обычно несколько дней), но по прошествии нескольких месяцев ее содержание начисто улетучивается из мозгов. Так вот, можно сразу, пока железо еще горячо, сделать себе набросок основных аспектов, и использованием карт памяти. Студенты говорят, что найдя потом такие конспекты-напоминалки, они быстро восстанавливают учебный материал в памяти. Это целесообразно делать после лекции, когда целостное впечатление от информации еще свежо.

Коллективная работа и продукт Comapping. Одно из главных достоинств диаграмм заключается в том, что их можно обсуждать с широким кругом людей. Тест, например, обсуждать труднее – его нужно сначала просчитать. А диаграмму можно тут же смотреть и обсуждать. И исправлять. Более того, с помощью диаграмм можно организовывать эффективные групповые территориально распределенные процессы работы с информацией: планирование, создание текстов, обмен результатами бесед, общение преподавателя и студента и пр.

Расскажем про один программный продукт, реализующий карты памяти и поддерживающий широкие возможности групповой работы….

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

Перечислим основные принципы MSF.

1. Единое видение проекта. Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения (shared vision), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта. Как проектная группа, так и заказчик изначально имеют собственные предположения о том, что должно быть достигнуто в ходе работы над проектом. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели. Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу – "Выработка концепции", которая заканчивается соответствующей вехой.

2. Гибкость – готовность к переменам. Традиционная дисциплина управления проектами и каскадная модель исходят из того, что все требования могут быть четко сформулированы в начале работы над проектом, и далее они не будут существенно изменяться. В противоположность этому MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности.

3. Концентрация на бизнес-приоритетах. Независимо от того, нацелен ли разрабатываемый продукт на организации или индивидуумов, он должен удовлетворить определенные нужды потребителей и принести в некоторой форме выгоду или отдачу. В отношении индивидуумов это может означать, например, эмоциональное удовлетворение – как в случае компьютерных игр. Что же касается организаций, то неизменным целевым фактором продукта является бизнес-отдача (business value). Обычно продукт не может приносить отдачу до того, как он полностью внедрен. Поэтому модель процессов MSF включает в свой жизненный цикл не только разработку продукта, но и его внедрение.

4. Поощрение свободного общения. Исторически многие организации строили свою деятельность на основе сведения информированности сотрудников к минимуму, необходимому для исполнения работы (need-to-know). Зачастую такой подход приводит к недоразумениям и снижает шансы команды на достижение успеха. Модель процессов MSF предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат, но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. По этой причине модель процессов MSF предлагает проведение анализа хода работы над проектом в определенных временных точках. Документирование результатов делает ясным прогресс, достигнутый в работе над проектом - как для проектной команды, так и для заказчика и других заинтересованных в проекте сторон.

Модель команды в MSF.

Основные принципы. Главная особенность модели команды в MSF является то, что она "плоская", то есть не имеет официального лидера. Все отвечают за проект в равной степени, уровень заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные. Конечно, далеко не каждая команда способна так работать – собственно, начальники для того и нужны, чтобы нести основной груз ответственности за проект и, во многом, освободить от него других. Демократия в команде возможна при высоком уровне осознанности и заинтересованности каждого, а также в ситуации равности в профессиональном уровне (пусть и в разных областях – см. различные ролевые кластеры в команде, о которых речь пойдет ниже). С другой стороны, в реальном проекте, в рамках данной модели команды, можно варьировать степень ответственности, в том числе вплоть до выделения, при необходимости, лидера.

Одной из особенностей отношений внутри команды является высокая культура дисциплины обязательств:

· готовность работников принимать на себя обязательства перед другими;

· четкое определение тех обязательств, которые они на себя берут;

· стремление прилагать должные усилия к выполнению своих обязательств;

· готовность честно и незамедлительно информировать об угрозах выполнению своих обязательств.

Ролевые кластеры. MSF основан на постулате о семи качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы и образуют ролевые кластеры (или просто роли ) в проекте. В каждом ролевом кластере может присутствовать по одному или несколько специалистов, некоторые роли можно соединять одному участнику проекта. Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. Для разрешения этой дилеммы команда соратников (команда равных, team of peers), работающая над проектом, должна иметь четкую форму отчетности перед заинтересованными сторонами (stakeholders) при распределенной ответственности за достижение общего успеха. В MSF следующие ролевые кластеры (часто их называют ролями) – см. рис. 9.1.

Рис. 9.1.

· Управление продуктом (product management). Основная задача этого ролевого кластера – обеспечить, чтобы заказчик остался довольным в результате выполнения проекта. Этот ролевой кластер действует по отношению к проектной группе как представитель заказчика и зачастую формируется из сотрудников организации-заказчика. Он представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика. В него же входит контроль за полным пониманием интересов бизнеса при принятии ключевых проектных решений.

· Управление программой (program management) обеспечивает управленческие функции – отслеживание планов и их выполнение, ответственность за бюджет, ресурсы проекта, разрешение проблем и трудностей процесса, создание условий, при которых команда может работать эффективно, испытывая минимум бюрократических преград.

· Разработка (development). Этот ролевой кластер занимается, собственно, программированием ПО.

· Тестирование (test) – отвечает за тестирование ПО.

· Удовлетворение потребителя (user experience). Дизайн удобного пользовательского интерфейса и обеспечение удобства эксплуатации ПО (эргономики), обучение пользователей работе с ПО, создание пользовательской документации.

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

· Архитектура (Architecture)¹. Организация и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.

Масштабирование команды MSF. Наличие 7 ролевых кластеров не означает, что команда должна состоять строго из 7 человек. Один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять. В таблице ниже представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды. "+" означает, что совмещение возможно, "+-" - что совмещение возможно, но нежелательно, "-" означает, что совмещение не рекомендуется.

	Управление продуктом	Управление программой	Разработка	Тестирование	Удовлетворение потребителя	Управление выпуском	Архитектура
Управление продуктом		–	–	+	+	+–	–
Управление программой	–		–	+–	+–	+	+
Разработка	–	–		–	–	–	+
Тестирование	+	+–	–		+	+	+–
Удовлетворение потребителя	+	+–	–	+		+–	+–
Управление выпуском	+–	+	–	+	+–		+
Архитектура	–	+	+	+–	+–	+

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

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия, каждая из которых устроена на основе модели кластеров. Это компактные мини-команды, образующие матричную организационную структуру. В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от проектирования и составления календарного графика. Например, может быть сформирована специальная группа проектирования и разработки сервисов печати.

Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы (functional teams), которые затем объединяются в ролевые кластеры. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Например, в Майкрософт группа управления продуктом обычно включает специалистов по планированию продукта и специалистов по маркетингу. Как первая, так и вторая сферы деятельности относятся к управлению продуктом: одна из них сосредотачивается на выявлении качеств продукта, действительно интересующих заказчика, а вторая – на информировании потенциальных потребителей о преимуществах продукта.

Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft Visual Basic.

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

Прочие особенности MSF.

Прочие особенности

Модель процесса

Водопадная модель – фазы работ и вехи

Рис. 9.2.

Спиральная модель – постоянное уточнение требований, активное взаимодействие с заказчиком.

Рис. 9.3.

В MSF объединяются водопадная и спиральная модели: сохраняются преимущества упорядоченности водопадной модели, не теряя при этом гибкости и творческой ориентации модели спиральной.

Рис. 9.4.

Итак, процесс MSF ориентирован на "вехи" (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: "Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?", "В достаточной ли степени готов план действий?", "Соответствует ли продукт утвержденной спецификации?", "Удовлетворяет ли решение нужды заказчика?" и т.д. А между вехами - итерации, итерации, итерации…..

Управление компромиссами. Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 9.5.

Рис. 9.5.

После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.

Рис. 9.6.

Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________.

Понятие CMMI

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

Следствие 1. CMMI допускает различные реализации и не является методологией разработки ПО, подобно MSF, Scrum, RUP и пр. Последние могут использоваться в его реализации. Так, существует, например, специальный шаблон процесса в VSTS для CMMI под названием MSF for CMMI.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов. Изначально, в конце 80-х начале 90-х годов, CMM (тогда еще не CMMI) создавался именно как средство сертификации федеральных субподрядчиков. И только позднее, получив широкое распространение в мире, он начал использоваться, а после и ориентироваться на совершенствование процессов.

Отметим еще одну важную характеристику CMMI. Он предназначен не только для разработки программных систем. Многие крупные компании выпускают не ПО, а целевые изделия, куда ПО входит как составная часть. Например, авиационная, аэрокосмическая индустрии. То есть разработка ПО происходит вместе с инженерными работами иных видов. И часто бывает, что в одном проекте участвует более двух различных видов инженерии. Задача CMMI – предоставить таким проектам и компаниям единую платформу организации процесса разработки.