Мегаобучалка Главная | О нас | Обратная связь


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



2018-07-06 460 Обсуждений (0)
Итеративный цикл автор/рецензент 0.00 из 5.00 0 оценок




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

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

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

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

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

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

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

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

В случае возникновения непонимания организуется встреча автора и эксперта, на которой они улаживают все рассогласования.

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

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

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

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

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

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

Карты памяти

Карты памяти (MindMaps) – техника работы с различными знаниями, предложенная и развитая английским психологом Тони Бьюзеном в конце 70-х годов прошлого века.

Она очень простая и используется при работе с информацией любого вида, для ее структурирования, осмысления, лучшего усвоения и запоминания. На листе бумаги, в центре, рисуется объект, обозначающий ту тему или предмет, который мы рассматриваем. Далее рисуются вторичные объекты, которые поясняют и уточняют данный и соединяются с ним дугами. И так далее.

Дизайн идей. Карты памяти позволяют выполнить "дизайн идей".

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

Реструктуризация. Карты памяти полезны при реструктуризации знаний.

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

Работа с краткосрочной памятью.

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


 

Лекция 9: MSF

В 90-х годах компания Microsoft, стремясь достичь максимальной отдачи от реализации заказных IT-решений и в целях улучшения работы с субподрядчиками обобщила свой опытпо разработке, внедрению, сопровождению и консалтингу ПО, создав методологию MSF. В 2002 году вышла версия MSF 3.1, состоявшая из пяти документов-руководств:

- модель процессов (processmodel),

- модель команды (teammodel),

- модель управления проектами (projectmanagement),

- дисциплина управления рисками (riskmanagement),

- управление подготовкой (readinessmanagement).

IT решение – понимается как скоординированная поставка набора элементов (таких как программные средства, документация, обучение и сопровождение), необходимых для удовлетворения бизнес-потребности конкретного заказчика.

Причем под его разработкой понималась создание ПО, обучение пользователей и полная передача продукта команде сопровождения.

Задача наладки полноценного сопровождения IT-решения - важная составляющая успешности проекта.

Основными новшествами MSF является следующее.

- Акцент на внедрении IT-решения.

- Модель процесса, объединяющая спиральную и водопадную модели.

- Особая организация команды – не иерархическая, а как группа равных, но выполняющих разные функции (роли) работников.

- Техника управления компромиссами.

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

1. Единое видение проекта.

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

2. Гибкость – готовность к переменам.

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

3. Концентрация на бизнес-приоритетах.

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

4. Поощрение свободного общения.

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

Модель команды

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

- Главная особенность модели команды в MSF является то, что она "плоская", то есть не имеет официального лидера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Масштабирование команды MSF. Наличие 7 ролевых кластеров не означает, что команда должна состоять строго из 7 человек. Один сотрудник может объединять несколько ролей.

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

Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы (functionalteams), которые затем объединяются в ролевые кластеры. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. В команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения.

Часто функциональные группы имеют внутреннюю иерархическую структуру. Иерархии не должны затенять модель команды MSF на уровне проекта в целом.

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

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

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

Итак, процесс MSF ориентирован на "вехи" (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата.


 

Лекция 10: CMMI

Что такое CMMI?

CMMI является некоторым описанием идеального процесса разработки ПО, предлагает некоторую модель процесса. То есть в процессе выделяются и тщательно описываются некоторые составные части, ключевые с точки зрения CMMI.

Эта точка зрения CMMI – совершенствование процессов разработки. То есть эти значимые части процесса – области усовершенствования.

В CMMI различаются следующие группы областей усовершенствования:

- управление процессами,

- управление проектами,

- инженерные области,

- служебные области.

При этом все области задаются в виде требований, определяющих не то, как они реализованы, а интерфейсные требования. Из этого имеется два следствия.

Следствие 1. CMMI допускает различные реализации и не является методологией разработкиПО, подобно MSF и пр.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов.

CMMIпредназначен не только для разработки программных систем.

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



2018-07-06 460 Обсуждений (0)
Итеративный цикл автор/рецензент 0.00 из 5.00 0 оценок









Обсуждение в статье: Итеративный цикл автор/рецензент

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

Популярное:



©2015-2020 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (460)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.012 сек.)