Заметки консультанта

Шамрай Александр Владимирович

Archive for Декабрь 2014

Практическое руководство по отчетности TFS. Приложение

Posted by Шамрай Александр на Декабрь 27, 2014

Шаблон отчета

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

Руководство для шаблона отчета

Форма

Шаблон отчета содержит все элементы формы стандартного отчета TFS:

  1. Описание отчета находится в верхней части и описывает цель отчета.
  2. Ссылки на другие связанные отчеты в правой части для других отчетов в этой категории.
  3. Вопросы, на которые этот отчет помогает ответить.
  4. Значения параметров, используемых для создания отчета. Это полезно, если вы хотите напечатать отчет.
  5. Время обновления данных для определения «свежести» данных в отчете.

Рисунок 9. Форма шаблона отчета

Параметры

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

Ключевые параметры

Это список ключевых параметров, которые необходимы для работы отчета. Их нельзя удалять.

Параметр Использование
ExplicitProject Используется для отладки/тестирования отчета
ReportPath Содержит путь к RDL файлу, что используется потом в dsProjectGuid для получения ProjectGuid
ProjectGuid Содержит Guid проекта
ProjectName Содержит имя проекта
IsDashboard Скрывает все стандартные элементы формы, если установлено как истина, как правило переопределено в URL

Таблица 14. Ключевые параметры

Необязательные параметры

Это список необязательных параметров для поддержки общих сценариев. Удалите их если не будете использовать.

Параметр Использование
IterationParam Содержит выбранную итерацию
AreaParam Содержит выбранную область

Таблица 15. Необязательные параметры

Источники данных

Отчет содержит только один источник данных TFSReports. TFSReports является источником данных для подключения к вашему реляционному TFS хранилищу. Дополнительные сведения о реляционном хранилище TFS и его схеме находятся по адресу http://msdn.microsoft.com/library/bb649552.aspx.

Наборы данных

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

Основные наборы данных

Это список основных наборов данных, необходимых для управления отчетом. Их нельзя удалять.

Набор данных Использование
dsProjectGuid Получает Guid проекта из текущего пути отчета
dsLastProcessedTime Получает время последнего обновления данных

Таблица 16. Ключевые наборы данных

Необязательные наборы данных

Это список необязательных наборов данных.

Набор данных Использование
dsIteration Получает все итерации для командного проекта
dsArea Получает все области для командного проекта

Таблица 17. Необязательные наборы данных

Начало работы

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

Следуйте этим шагам:

Шаг Инструкции
1. Создать новый проект отчета[ ] — Сделано
  • Запустить BIDS (SQL Server Business Intelligence Development Studio).
  • Создать новый Report Server Project с названием MyCustomReport
2. Добавить общий источник данных TfsReportDs[ ] — Сделано
  • В обозревателе решений выбрать правой кнопкой мыши DataSource, Add New Datasource.
  • Назвать его TfsReportDs.
  • Ввести строку подключения и учетные данные для чтения из реляционной базы данных TFS.
3. Добавить и переименовать шаблон[ ] — Сделано
  • В обозревателе решений выбрать правой кнопкой Report, Add existing report.
  • Скопировать и переименовать шаблон отчета ALM рейнджеров в каталог проекта.
  • Выбрать и добавить скопированный отчет.
4. Установить параметр отчета ExplicitProject[ ] — Сделано
  • В обозревателе данных отчета выбрать правой кнопкой мыши ExplicitProject, Parameter Properties.
  • Выбрать вкладку Default Values.
  • Установить в значение по умолчанию путь к существующему командному проекту: /TfsReports/DefaultCollection/TestProject
5. Установить отчет как стартовый для проекта[ ] — Сделано
  • Выбрать правой кнопкой мыши свойства проекта
  • Под элементом Debug/Start item выбрать отчет.
6. Протестировать отчет[ ] — Сделано
  • Нажать F5

Таблица 18. Шаблон отчета – начало работ

Настройка виртуальной машины для использования Analysis Services

Установка Analysis Services в табличном режиме на виртуальной машине Брайана Келлера

Установка SQL Server 2012 Analysis Services

  1. Запустите Виртуальную машину Брайана Келлера и войдите от учетной записи администратора.
  2. Смонтируйте установочный диск SQL Server 2012 или путь к папке с установочным носителем.
  3. Запустите установку.
  4. На странице Product Key нажмите кнопку Next.
  5. Примите условия лицензионного соглашения и нажмите кнопку Next.
  6. Нажмите кнопку Next на странице Product Updates.
    Игнорируйте предупреждение. Мы собираемся установить SP1 позже.
  7. После запуска правил поддержки программы установки, нажмите кнопку Next.
  8. На странице Setup Role выберите SQL Server Feature Installation и нажмите кнопку Next.
  9. На странице выбора компонентов выберите только Analysis Services, Client Tools Connectivity и Client Tools Backwards Compatibility, Management Tools – Basic and Complete и SQL Server Data Tools и нажмите кнопку Next.
    Обратите внимание, что в этом случае мы не будем пытаться устанавливать PowerView. Это более сложный процесс, так что давайте не будем беспокоиться об этом прямо сейчас.
  10. После запуска правил установки, нажмите кнопку Next.
  11. Instance Configuration должен быть именованный экземпляр, так что назовем его «Tabular» и нажмите кнопку Next.
  12. В disk space requirements нажмите кнопку Next.
  13. В разделе server configuration нажмите кнопку Next.
  14. На странице Analysis Services Configuration выберите Tabular Mode (по умолчанию используется Multidimensional and Data Mining Mode).
  15. Нажмите кнопку Add Current User и нажмите кнопку Next (можете добавить других пользователей, но не обязательно).
  16. На странице Error Reporting нажмите кнопку Next.
  17. После выполнения правил настройки установки, нажмите кнопку Next.
  18. На странице готовности для установки нажмите Install.
  19. После завершения установки нажмите кнопку Close.

Установка SQL Server 2012 x64 SP1

  1. Вставьте диск SQL Server 2012 в виртуальной машине и запустите установку x64 SP1.

Проверка установки

  1. Для проверки установки откройте SQL Server Management Server 2012, подключитесь к localhost\tabular и проверьте свойства.

Понимание модели реляционных данных хранилища рабочих элементов

Каждый новый экземпляр Team Foundation Server создает следующие базы данных на сервере данных:

  • Tfs_Configuration
  • Tfs_DefaultCollection (или Tfs_ <CollectionName> если ваша командная коллекция имеет другое имя)
  • Tfs_Warehouse
  • Tfs_Analysis

Первые три базы данных – это OLTP баз данных, созданные в службе баз данных SQL Server. Tfs_Analysis является OLAP базой данных, созданной службой анализа SQL Server. В следующей таблице приведено краткое описание каждой базы данных:

Имя базы данных Тип Описание
Tfs_Configuration Реляционная база данных Эта база данных хранит каталог ресурсов и конфигурации сервера Team Foundation Server. Каждая установка TFS имеет только одну базу данных Tfs_Configuration.
Tfs_<CollectionName> Реляционная база данных Для каждой новой командной коллекции создается новая базы данных Tfs_ <CollectionName>. Эта база данных содержит фактические данные командных проектов в командной коллекции. Это хранилище первичных данных, которые записываются при создании новых рабочих элементов или поставке под контроль файлов.
Tfs_Warehouse Реляционная база данных Tfs_Warehouse реляционная база данных хранилища TFS и предоставляет данные в формате, который упрощает отчетность.
Tfs_Analysis OLAP куб Базы данных Tfs_Analysis является многомерным кубом OLAP, который содержит агрегированные данные team foundation server.

Таблица 19. Базы данных сервера данных TFS

Майкрософт рекомендует использовать базы данных Tfs_Warehouse и Tfs_Analysis для отчетности. О структуре и схеме этих баз данных существует достаточно документации. Однако каналы данных Tfs_Warehouse обновляются каждые два часа и формат может быть нежелателен при определенных обстоятельствах. Все базы данных командных коллекций сходятся в эти базы данных (Tfs_Warehouse и Tfs_Analysis).

В этом разделе описывается схема Tfs_DefaultCollection для поддержки пользователей, которые хотят использовать данные из базы данных OLTP для отчетности.

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

  • Схема базы данных Tfs_DefaultCollection может изменяться в будущих версиях или при обновлении сервера TFS.
  • Запросы непосредственно к базе данных могут иметь неблагоприятное воздействие на производительность вашего сервера TFS. Поэтому рекомендуется использовать locking hint, чтобы ваши запросы не блокировали базу данных.
  • Любые случайные изменения в данных этой базы данных может повредить ваш сервер TSF. Данные в этой базе данных не должны изменяться. Всегда подключайтесь к этой базе данных пользователем, который имеет доступ только для чтения.

 

Чтобы обеспечить рекомендации от Microsoft, при создании нового командного проекта (значение по умолчанию — службы Reporting Services), мы должны подключаться только к источникам данных из баз данных Tfs_Warehouse (названный TFSReportsDS) и Tfs_Analysis (названный TFSOlapReportsDS). В этом документе мы подробно рассмотрим, как данные по рабочим элементам хранятся в базе данных Team Foundation Server.

Таблицы Tfs_DefaultCollection

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

[dbo].[WorkItemsAre]

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

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[Changed Date] Дата и время последнего изменения рабочего элемента
[PersonId] ID персоны, которая создала рабочий элемент
[AreaID] ID области, к которой принадлежит рабочий элемент. Это поле содержит внешний ключ к таблице [xxTree]
[Rev] Номер версии рабочего элемента. При каждом обновлении значение поля увеличивается на 1.
[State] Текстовое поле состояния рабочего элемента
[Reason] Текстовое поле причины рабочего элемента
[Assigned To] ID пользователя, на которого назначен рабочий элемент.
[Created By] ID пользователя, который создал рабочий элемент.
[ID] ID рабочего элемента.
[Changed Order] Поле отметки времени для записи
[Authorized Date] Дата и время последнего обновления рабочего элемента
[Created Date] Дата и время создания рабочего элемента
[IterationID] ID выбранной итерации рабочего элемента. Это поле содержит внешний ключ к таблице [xxTree]
[Title] Текстовое поле названия рабочего элемента
[Changed By] ID пользователя, который последним изменил рабочий элемент.
[Work Item Type] Текстовое поле типа рабочего элемента

Таблица 20. Таблица [dbo].[WorkItemsAre]

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

Например, следующая таблица возвращает имя и значение из поля fld10002 для всех рабочих элементов:

SELECT WorkItems.ID, Fields.Name as FieldName, WorkItems.Fld10002 as FieldValue FROM [WorkItemsAre] WorkItems LEFT JOIN [Fields] ON Fields.FldID = 10002

[dbo].[WorkItemsLatest]

Таблица [dbo].[WorkItemsLatest] имеет ту же схему, что и таблица [dbo].[WorkItemsAre], за исключением того, что он содержит дополнительное поле под названием «Revised Date». Эта таблица может использоваться взаимозаменяемо с таблицей [dbo].[WorkItemsAre].

[dbo].[WorkItemsWere]

Таблица [dbo].[WorkItemsWere] содержит исторические данные таблицы [dbo].[WorkItemsAre]. Она имеет ту же схему, что и таблица [dbo].[WorkItemsAre]. При каждом изменении рабочего элемента создается новая запись в этой таблице. Новая запись содержит состояние рабочего элемента до изменения.

[dbo].[WorkItemLongTexts]

Html поля рабочих элементов хранятся в отдельной таблице, называемой [dbo].[WorkItemLongTexts]. Каждый раз, когда обновляется поле html, создается новая запись в этой таблице. Однако эта таблица записывается только тогда, когда есть изменения в поле html. Это означает, что не все номера версии установленные в таблице [dbo].[WorkItemsWere] будут иметь соответствующую запись в этой таблице. Схема таблицы представлена подробно здесь:

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[AddedDate] Дата добавления значения html поля
[FldID] ID персоны, которая создала рабочий элемент
[ID] ID рабочего элемента для этого поля html.
[Words] Текст поля html.
[Changed Order] Поле отметки времени для записи
[Rev] Номер версии рабочего элемента, в которой было сделано изменение html поля.
[fHtml] Логическое поле, которое показывает, что данное поле html.
[IndexedWords] Бинарное поле, которое содержит хеш-код поля Words.
[WordsDocumentType] Текстовое поле, которое содержит тип данных хранящихся в поле. Возможные значения .txt, .html
[TextID] Это поле идентификационных данных и первичный ключ таблицы.
[EndDate] End Date заполняется только для записей, которые не являются в настоящее время активными. То есть поле было обновлено и создается новая запись с новыми значениями. Для каждого обновления поля для текущей записи заполняется поле EndDate и создается новая запись.

Таблица 21. Таблица [dbo].[WorkItemsLongTexts]

[dbo].[WorkItemFiles]

Таблица [dbo].[WorkItemFiles] содержит информацию о всех файлах, прикрепленных к рабочему элементу. В следующей таблице приведена схема таблицы [dbo].[WorkItemFiles]:

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[RemovedDate] Дата и время удаления вложения из рабочего элемента. Заполняется только для удаленных вложений.
[AddedDate] Дата и время добавления вложения к рабочему элементу
[FldID] ID поля рабочего элемента, которое хранит прикрепленный файл
[ID] ID рабочего элемента, к которому прикреплен файл.
[FilePath] Поле заполняется с GUID из поля FileGuid в таблице [dbo].[Attachment], где хранится содержимое файла.
[ExtID] Это поле идентификационных данных и первичный ключ таблицы.
[Comment] Текстовое поле, которое содержит комментарий, написанный пользователем при вложении файла.
[CreationDate] Дата и время создания файла во вложении.
[LastWriteDate] Дата и время последнего изменения файла во вложении.
[Length] Размер файла в байтах.
[Historical Added Date] Дата и время сохранения рабочего элемента, когда было давлено вложение.
[Historical Removed Date] Дата и время сохранения рабочего элемента, когда было удалено вложение.

Таблица 22. Таблица [dbo].[WorkItemsFiles]

[dbo].[LinksAre]

Таблица [dbo].[LinksAre] содержит информацию об одной или нескольких связей.

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[SourceID] ID рабочего элемента, из которого создана связь
[TargetID] ID рабочего элемента, к которому создана связь
[LinkType] Link Type ID для связи. Это поле является внешним ключом, ссылающимся на таблицу [dbo].[LinkTypes], которая содержит информацию о различных типах ссылок, которые могут быть созданы между двумя рабочими элементами.
[ReverseLinkType] Link Type ID для ссылки из целевого рабочего элемента на исходный рабочий элемент. Это поле является внешним ключом, ссылающимся на таблицу [dbo].[LinkTypes], которая содержит информацию о различных типах ссылок, которые могут быть созданы между двумя рабочими элементами.
[Created By] ID пользователя, который создал ссылку.
[Created Date] Дата и время создания ссылки.
[Comment] Текстовое поле, которое содержит комментарий, написанный пользователем при создании ссылки.
[Historical Added Date] Дата и время сохранения рабочего элемента, когда была давлена связь.

Таблица 23. Таблица [dbo].[LinksAre]

[dbo].[LinksWere]

Похоже на таблицу [dbo].[WorkItemsWere], [dbo].[LinksWere] содержит историческую информацию о связях между рабочими элементами. Когда связь между рабочими элементами отредактирована или удалена, создается новая строка в таблице [dbo].[LinksWere] считывая информацию неизмененной ссылки из таблицы [dbo].[LinksAre] перед записью в таблицу [dbo].[LinksAre] при редактировании или удалении.

[dbo].[WorkItemsDestroyed]

Таблица [dbo].[WorkItemsDestroyed] содержит список удаленных рабочих элементов. Когда рабочий элемент удаляется, его данные удаляются из таблиц [dbo].[WorkItemsAre] и [dbo].[WorkItemsWere] и создается новая запись в таблице [dbo].[WorkItemsDestroyed].

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[ID] ID удаленного рабочего элемента.
[Changed Order] Поле отметки времени для записи
[Changer ID] ID пользователя, который удалил рабочий элемент.

Таблица 24. Таблица [dbo].[WorkItemsDestroyed]

[dbo].[WorkItemLinksDestroyed]

Когда рабочий элемент связан с другими рабочими элементами и источник или целевой объект удаляется, создается запись в таблице [dbo].[WorkItemLinksDestroyed]. Таблица имеет следующую схему.

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[SourceID] ID рабочего элемента, из которого создана связь
[TargetID] ID рабочего элемента, к которому создана связь
[LinkType] Текстовое поле, которое содержит описание типа ссылки, которая была удалена.
[ChangeDate] Дата, когда ссылка была удалена
[DeletedTimeStamp] Отметка времени записи оригинальной ссылки, которая была удалена.
[TimeStamp] Отметка времени записи.

Таблица 25. Таблица [dbo].[WorkItemLinksDestroyed]

Posted in Microsoft, Team Foundation Server, TFS Practical Reporting Guide, Visual Studio | Отмечено: , , | Leave a Comment »

Практическое руководство по отчетности TFS. Адаптеры данных и Хранилище TFS

Posted by Шамрай Александр на Декабрь 27, 2014

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

 

Майкрософт использует адаптеры хранилища для добавления данных в хранилище данных TFS. Эти адаптеры используются данные из операционных (транзакционных) таблиц и форматируют их в виде таблиц измерений и фактов. Можно создать собственный адаптер для увеличения данных в хранилище.

Рисунок 9. Архитектура Хранилища данных

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

Основы разработки адаптеров хранилища TFS

Реализация адаптера

Реализуются два интерфейса, когда вы получаете данные из операционных таблиц и вставляете их в хранилище данных TFS: IWarehouseAdapter и IDataStore. Интерфейс IWarehouse используется службой хранилища данных TFS для вызова пяти основных адаптеров по определенному графику для изменения данных. Интерфейс IDataStore используется службой хранилища данных TFS для взаимодействия в хранилище данных TFS.

IWarehouseAdapter имеет четыре метода:

  • Initialize: создает объекты, которые взаимодействуют с операционным хранилищем и хранилищем данных.
  • MakeSchemaChanges: создает новый атрибут измерения в хранилище. Этот атрибут содержит описание политики переопределения.
  • MakeDataChanges: вызывается каждый раз, когда вы обновляете хранилище. В этом адаптере метод проверяет все наборы изменений, сделанные с времени последнего обновления хранилища. Если набор изменений содержит описание переопределения политики, он вызывает метод SavePolicyOverrideCommentDimAttribute, который сохраняет описание в хранилище.
  • Cancel: когда вы хотите остановить адаптер.

Используя пример CSharp Assembly Churn, который предоставляется Microsoft, вы увидите лучшие практики создания отдельного таблицы измерения для данных, которые требуется добавить в хранилище данных TFS. Вам нужно иметь в виду, что версии TFS разные и вам не нужно быть привязанным к их таблицам, так как нет никакой гарантии, что они будут такими же после применения накопительного обновления или обновления версии.

Этот пример содержит SQL и классы, используемые при создании таблиц измерений, фактов и хранимых процедур, используемых в хранилище данных TFS и SQL.

Реализация с использованием адаптера для внесения данных изменений находится в классе CSharpAssemblyCodeChurnSampleAdapter. Этот класс содержит метод ProcessChangesets, который используется для получения сведений о сборке для файлов и их добавления в хранилище данных TFS.

Развертывание адаптера

Хорошим подходом является тестирование развертывания в непроизводственной среде. Можно рассмотреть использование виртуальной машины Брайана Келлера, если у вас только одна среда.

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

  • Скопируйте сборку в папку plugins хранилища
    • «C:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\bin\Plugins» для TFS 2012
    • «C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\bin\Plugins» для TFS 2013
  • Перезапустите IIS.
  • Откройте браузер и перейдите по адресу https://localhost/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx?op=GetProcessingStatus и нажмите кнопку Invoke.
  • Продолжайте делать это до тех пор, пока статус возвращается как Idle.
  • Убедитесь, что это не вызвало никаких проблем, проверив журнал событий приложений Windows на отсутствие каких-либо ошибок.

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

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

Важная информация

Элементы, на которые стоит обратить внимание:

  • Важные изменения схемы в структуре таблицы хранилища:
    • TFS 2010: до сих пор используется много внешних ключей каскадного удаления, что убивает производительности
    • TFS 2010 SP1: удалено большинство связей с внешними ключами, адаптерам необходимо «очищать после себя»
    • TFS 2012/2013: едва ли были какие-либо изменения в хранилище данных, но схема операционного хранилища была значительно изменена, особенно в области сборок
  • Версии платформы .NET framework, параметры ЦП для адаптеров
    • TFS 2010: .NET 4, AnyCPU, с ожидаемой загрузкой в среде x64
    • TFS 2012: .NET 4.5, AnyCPU, с ожидаемой загрузкой в среде x64
    • TFS 2013: .NET 4.5.1, AnyCPU, с ожидаемой загрузкой в среде x64
  • Минимальные требования SQL Server
    • TFS 2010 (SQL Server 2008)
    • TFS 2012 (SQL Server 2008 R2)
    • TFS 2013 (SQL Server 2012)
    • SQL 2014 не был проверен
  • Сборки для ссылки и где их найти
    • Описания SK/BK для существующих измерений и фактов
    • Отладка адаптера (присоединить Visual Studio к службе TFS Job)
    • Срабатывание адаптера (вызов веб-службы хранилища)

Posted in Microsoft, Team Foundation Server, TFS Practical Reporting Guide, Visual Studio | Отмечено: , , | Leave a Comment »

Рабочий элемент TFS с системными полями

Posted by Шамрай Александр на Декабрь 23, 2014

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

Такой шаблон типа рабочего элемента есть и его можно скачать по этой ссылке.

Список полей рабочего элемента:

Name Reference Name Type Reportable Help Text
Iteration Path System.IterationPath TreePath dimension The iteration within which this task will be completed
Iteration ID System.IterationId Integer
External Link Count System.ExternalLinkCount Integer
Team Project System.TeamProject String dimension
Hyperlink Count System.HyperLinkCount Integer
Attached File Count System.AttachedFileCount Integer
Node Name System.NodeName String
Area Path System.AreaPath TreePath dimension The area of the product to which this task contributes
Revised Date System.RevisedDate DateTime detail
Changed Date System.ChangedDate DateTime dimension
ID System.Id Integer dimension
Area ID System.AreaId Integer
Authorized As System.AuthorizedAs String
Title System.Title String dimension Work required and how this will implement a User Story
State System.State String dimension Active = work remains to be done. Closed = tested and checked in.
Authorized Date System.AuthorizedDate DateTime
Watermark System.Watermark Integer
Rev System.Rev Integer dimension
Changed By System.ChangedBy String dimension
Reason System.Reason String dimension The reason why the task is in its current state
Assigned To System.AssignedTo String dimension The person currently working on this task
Work Item Type System.WorkItemType String dimension
Created Date System.CreatedDate DateTime dimension
Created By System.CreatedBy String dimension
Description System.Description HTML What to do, pointers to resources and inputs, design notes, exit criteria
History System.History History Discussion thread plus automatic record of changes
Related Link Count System.RelatedLinkCount Integer
Tags System.Tags PlainText

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

Практическое руководство по отчетности TFS. Дополнительный Сервис Отчетности

Posted by Шамрай Александр на Декабрь 6, 2014

Для каждой коллекции проектов Team Foundation Server создает базу данных OLTP. База данных для коллекции командных проектов по умолчанию называется Tfs_DefaultCollection. Здесь TFS хранит все «активные» данные. Данные из этой базы данных подаются сначала в базу данных звездообразной схемы Tfs_Warehouse, а затем к OLAP кубу Tfs_Analysis.

Т.к. создание отчетов поддерживается из баз данных Tfs_Warehouse и Tfs_Analysis, Microsoft не рекомендует создавать отчеты напрямую из базы данных Tfs_DefaultCollection. Причина этого в том, что схема база данных OLTP часто меняется новыми TFS релизами и обновлениями.

Однако TFS API предоставляет альтернативный способ выборки данных из базы данных Tfs_DefaultCollection. Вы можете написать собственные службы, которые используют TFS API и обеспечивают альтернативный способ получения данных.

Это руководство поставляется с примером службы WCF. Служба использует TFS API для получения информации о сборках и шагах сборки из базы данных OLTP.

Предварительные требования

Чтобы настроить дополнительный сервис отчетности, вам понадобится машина со следующими возможности Microsoft Windows:

  • Microsoft Internet Information Server (IIS) v 7.0 or v. 8.0.
  • Microsoft .NET Framework 4.

Требования к безопасности

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

Пошаговое руководство

Шаг Инструкции
1 Установка

[ ] — Сделано

  • Скопируйте папку Teamreports\TeamReportService из кода примера на веб-сервер, где вы будете развертывать дополнительную службу TFS. Вы можете использовать сервер приложений TFS или какую-то другую машину, которая может вызывать TFS API.
  • Откройте службы IIS и создайте пул приложений, который называется TFSReports.
  • Выберите .Net Framework v4.0.30319 для версии .NET Framework и Integrated для режима управляемого конвейера.
  • Нажмите кнопку ОК, чтобы создать пул приложений. Щелкните на нем правой кнопкой мыши и выберите пункт Advanced Settings.
  • Нажмите Identity и задайте учетную запись для службы, как указано в требовании безопасности выше.
  • Создайте новый веб-сайт с называнием TfsReports. Выберите свой недавно созданный пул приложений TFSReports как пул приложений и установите сайт на скопированный каталог TeamReportsService.
  • Для привязки созданного веб-сайта задайте ему уникальное имя DNS или назначьте уникальный порт на сервере. Нажмите кнопку ОК. Служба в настоящее время развернута и готова к вызову.
2. Понимание Сигнатуры

[ ] — Сделано

  • Ваша дополнительная служба отчетов TFS теперь может вызываться из любого клиента, который может делать запросы SOAP. Пример службы содержит один сервис, который называется BuildService, с одной операцией GetBuildStepDurationReport. Сигнатура операции следующая:

/// <summary>

///
Returns the Build Step Duration report for a given build

/// </summary>

/// <param name=»projectCollectionUri»>The Project collection Uri</param>

/// <param name=»teamProjectName»>The Team Project Name</param>

/// <param name=»buildDefinitionName»>The build definition name for the build for which the report should return the build duration. Only the latest build is extracted.</param>

///<param name=»reportOption»>An enumeration that determines which steps should be returned</param>

/// <returns>A list of build steps with their respective duration</returns>

[OperationContract]

IEnumerable<BuildStep> GetBuildStepDurationReport(string projectCollectionUri, string teamProjectName, string buildDefinitionName, BuildStepDurationReportOption reportOption);

  • Он принимает идентификатор сборки в качестве параметра и возвращает список всех сборок.
3. Понимание Операций

[ ] — Сделано

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

/// <summary>

/// The BuildStep class encapsulates a single Build Step in a build report

/// </summary>

[DataContract]

public class BuildStep

{

/// <summary>

/// Gets or sets the name of the Build Step

/// </summary>

[DataMember]

public string Name { get; set; }

/// <summary>

///
Gets or sets the Start Time of the Build Step

/// </summary>

[DataMember]

public DateTime StartTime { get; set; }

/// <summary>

///
Gets or sets the End Time of the Build Step

/// </summary>

[DataMember]

public DateTime? EndTime { get; set; }

/// <summary>

///
Gets or sets the Duration of the build Step

/// </summary>

[DataMember]

public TimeSpan? Duration { get; set; }

}

  • Операция возвращает список шагов с их продолжительность выполнения в последней сборке…
  • Отчет полезен для менеджеров сборки, которые хотят диагностировать, какие наиболее медленные части.
4. Создание Клиентского Прокси-приложения

[ ] — Сделано

  • Использование службы можно продемонстрировать с помощью приложения WcfTestClient.exe, которое входит в состав Visual Studio. Для создания клиента выполните следующие действия:
  • Создайте новое консольное приложение Windows в Visual Studio.
  • Щелкните правой кнопкой мыши на ссылки служб и нажмите Add Service Reference.
  • В URL-адрес службы введите http://TFSCustomReports/BuildService.svc и нажмите кнопку Go. Выберите BuildReports, введите название подходящего пространства имен и нажмите кнопку ОК.

  • Нажмите кнопку ОК. Это сгенерирует прокси-класс для службы.
5. Клиентский Код

[ ] — Сделано

  • Теперь создайте экземпляр прокси-класса и выполните его вызов.
  • Окончательный код выглядит так:

    using (var client = new BuildReportsClient())

    {


    var buildSteps = client.GetBuildStepDurationReport( «*TeamProjectCollectionUri», «TeamProjectName», «BuildDefinitionName», BuildStepDurationReportOption.All);


    foreach (var step in buildSteps)

    {

    Console.WriteLine(«Build Step {0} — Duration {1}», step.Name, step.Duration);

    }

    }

6. Запуск Клиента

[ ] — Сделано

  • Перестройте и запустите клиентское приложение, нажав клавишу F5.

Таблица 13. Пошаговое руководство для дополнительного сервиса отчетности

Примечание Пример службы и клиента включен в код этого руководства.https://vsarreportguide.codeplex.com/releases/view/115743

Posted in TFS Practical Reporting Guide | Отмечено: , , | Leave a Comment »

CMMI DEV v1.3 – Управление Организационными Показателями

Posted by Шамрай Александр на Декабрь 5, 2014

Перевод Шамрай А.В.

Процессная область Управления Процессами уровня зрелости 5

Назначение

Назначением Управление Организационными Показателями (ОУП) является активный контроль эффективности деятельности Организации для удовлетворения своих бизнес-целей.

Вступительный комментарий

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

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

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

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

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

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

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

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

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

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

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

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

Связанные процессные области

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации о выявлении причин выбранных результатов и принятии мер для улучшения показателей процесса.

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

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставления результатов измерений.

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

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

См. процессную область Организационное Обучение для получения дополнительной информации об обеспечении обучения.

Перечень специфических целей и практик

  • СЦ 1 Управлять Бизнес Показателями
    • СП 1.1 Поддерживайте Бизнес Цели
    • СП 1.2 Анализируйте Данные Показателей Процессов
    • СП 1.3 Выявляйте Потенциальные Области для Улучшения
  • СЦ 2 Выбрать Улучшения
    • СП 2.1 Выявляйте Предложения по Улучшению
    • СП 2.2 Анализируйте Предложения по Улучшению
    • СП 2.3 Выполняйте Валидацию Улучшений
    • СП 2.4 Выбирайте и Реализуйте Улучшения для Внедрения
  • СЦ 3 Внедрить Улучшения
    • Планируйте Внедрение
    • Управляйте Внедрением
    • Оценивайте Эффекты от Улучшений

Специфические практики по целям

СЦ 1 Управлять Бизнес Показателями

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

Управление бизнес показателями требует следующее:

  • Поддержки бизнес целей организации
  • Понимания способностей организации для достижения бизнес целей
  • Постоянного улучшения процессов, относящихся к достижению бизнес-целей

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

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

По мере улучшения организацией ее показателей процесса или изменения бизнес-стратегий, определяются новые бизнес-цели и связанные цели качества и показатели процесса, которые являются производными.

Специфическая цель 2 направлена на выявление и анализ предложений для устранения недостатков в достижении целей качества и показателей процесса.

СП 1.1 Поддерживайте Бизнес Цели

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

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

Пример рабочих продуктов

1. Пересмотренные бизнес-цели

2. Пересмотренные цели качества и показателей процессов

3. Утверждение руководством пересмотренные бизнес цели и цели качества и показателей процессов

4. Информирование о всех пересмотренных целях

5. Обновленные меры показателей процесса

Подпрактики

1. Периодически оценивайте бизнес-цели, чтобы убедиться, что они соответствуют бизнес-стратегии.

Руководство отвечает за понимание рынка, создание бизнес-стратегии и бизнес целей.

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

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

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

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

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

4. Поддерживайте цели качества и показателей процесса для обеспечения изменений в бизнес-целей.

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

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

5. Пересматривайте меры процесса для их соответствия целям качества и целям показателей процесса.

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

СП 1.2 Анализируйте Данные Показателей Процесса

Анализируйте данные показателей процесса для определения способности организации достичь установленные бизнес-цели.

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

Пример рабочих продуктов

1. Анализ текущих возможностей на основе бизнес-целей

2. Недостатки показателей процесса

3. Риски, связанные с достижением бизнес целей

Подпрактики

1. Периодически сравнивайте цели качества и показателей процесса с текущими базовыми показателями процесса для оценки способности организации достичь ее бизнес-цели.

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

2. Выявляйте недостатки, где фактические показатели процесса не отвечают бизнес-целям.

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

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

СП 1.3 Выявляйте Потенциальные Области для Улучшения

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

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

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

Пример рабочих продуктов

1. Потенциальные области для улучшения

Подпрактики

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

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

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

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

4. Предоставьте всем заинтересованным лицам набор потенциальных областей для улучшения для дальнейшей оценки, определения приоритетов и использования.

СЦ 2 Выбрать Улучшения

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

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

Оценки предложений основаны на следующем:

  • Количественное понимание текущего качества и показателей процесса организации
  • Удовлетворение целями качества и показателей выполнения процесса организации
  • По оценкам затрат и влияния разработки и внедрения улучшений, ресурсов и финансовых средств для внедрения
  • По оценкам выгод для качества и показателей процесса, вызванных внедрением улучшения

СП 2.1 Выявляйте улучшения

Выявить и классифицировать предлагаемые улучшения.

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

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

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

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

Примеры инкрементальных улучшений включают следующие:

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

Примеры инновационных улучшений обычно включают дополнительные или крупные обновления к следующему:

  • Компьютерные и соответствующие аппаратные продукты
  • Трансформационные инструменты поддержки
  • Новые или обновленные рабочие процессы
  • Модели процессов или жизненных циклов
  • Стандарты интерфейса
  • Повторно используемые компоненты
  • Методы и методологии управления
  • Методы и методологии улучшения качества
  • Методы и методологии разработки

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

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

Пример рабочих продуктов

1. Предлагаемые инкрементальные улучшения

2. Предлагаемые инновационные улучшения

Подпрактики

1. Выявляйте предлагаемые улучшения.

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

Примеры источников для улучшения включают следующее:

  • Выводы и рекомендации из оценки процесса
  • Цели качества и цели показателей процесса организации
  • Анализ данных о проблемах клиентов и конечных пользователей, а также удовлетворенности клиентов и конечных пользователей
  • Результаты оценки производительности процесса и продукта
  • Измерения эффективности деятельностей процесса
  • Измерения эффективности проектных рабочих сред
  • Примеры улучшений, которые были успешно приняты в других местах
  • Отзывы о предыдущих улучшениях
  • Спонтанные идеи от руководителей и сотрудников
  • Предложения об улучшениях из процессов Анализ Причин и Принятие Решений, которые являются результатом выполненных действий с доказанной эффективностью
  • Анализ мер технических показателей
  • Анализ данных о причинах дефектов
  • Анализ показателей проекта и организации по сравнению с целями качества и продуктивности

<См. процессную область Фокусирование на Организационных Процессах для получения дополнительной информации о реализации активов организационного процесса и учета опыта.

 

2. Определяйте предлагаемые улучшения как инкрементальные или инновационные.

3. Исследуйте инновационные улучшения, которые могут улучшить процессы и технологии организации.

Обычно исследование инновационных улучшений включает в себя следующее:

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

СП 2.2 Анализируйте Предложения по Улучшению

Анализируйте предлагаемые улучшения на предмет их возможного воздействия на достижение целей качества и показателей процесса организации.

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

Пример рабочих продуктов

1. Предлагаемые предложения по улучшению

2. Отобранные улучшения для проверки

Подпрактики

1. Анализируйте затраты и выгоды предлагаемых улучшений.

Модели показателей выполнения процесса обеспечат понимание влияния изменений процесса на возможности процесса и его показатели.

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

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

Критерии для оценки затрат и выгод, включают следующее:

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

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

Примеры барьеров внедрения улучшения включают следующее:

  • Перспективы относятся к слишком узкой области
  • Непрозрачное или слабое бизнес обоснование
  • Отсутствие краткосрочных выгод и видимых успехов
  • Непрозрачное отражение того, что ожидается от каждого
  • Слишком много изменений в один момент времени
  • Отсутствие участия и поддержки со стороны соответствующих заинтересованных сторон

<Примеры факторов риска, которые влияют на внедрение улучшений, включают следующее:

  • Совместимость улучшений с существующими процессами, результатами и навыками потенциальных конечных пользователей
  • Сложность улучшений
  • Сложность реализации улучшения
  • Возможность продемонстрировать важное значение улучшения перед широким внедрением
  • Обоснование для больших первоначальных инвестиций в таких областях, как инструменты и обучение
  • Неспособность преодолеть «технологические смещения», где текущая реализация успешно используется большой и высокого уровня зрелости базой конечных пользователей

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

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

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

5. Документируйте результаты оценки каждого выбранного предложения улучшения в предложении по улучшению.

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

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

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

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

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

8. Документируйте результаты процесса отбора.

Результаты процесса отбора, как правило, включают следующее:

  • Распоряжение для каждого предложения по улучшению
  • Обоснование распоряжения для каждого предложения по улучшению

СП 2.3 Выполняйте Валидацию Улучшений

Выполняйте валидацию выбранных улучшений.

Выбранные улучшения, проверяются в соответствии с их предложениями по улучшению.

Примеры методов валидации включают в себя следующее:

  • Обсуждение с заинтересованными сторонами, возможно, в рамках официальной оценки
  • Демонстрации прототипа
  • Пилотная эксплуатация для предлагаемых улучшений
  • Моделирование и симулирование

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

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

Пример рабочих продуктов

1. План валидации

2. Отчеты для оценки валидации

3. Задокументированные уроки, извлеченные из проведения валидации

Подпрактики

1. Планируйте валидацию.

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

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

2. Выполните оценку и получите согласие соответствующих заинтересованных сторон для планов валидации.

3. Проконсультируйтесь и получите поддержку от тех, кто выполняет проверку.

4. Выполните пробное внедрение в соответствии с планом валидации для выбранных улучшений пилотной эксплуатации.

5. Каждую валидацию выполняйте в среде, которая похожа на среду для широко масштабного внедрения.

6. Отслеживание ход валидации на основе их планов.

7. Выполняйте оценку и документирование результатов валидации.

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

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

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

СП 2.4 Выбирайте и Реализуйте Улучшения для Внедрения

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

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

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

Пример рабочих продуктов

1. Улучшения, выбранные для внедрения

2. Обновленные процессная документация и материалы для обучения

Подпрактики

1. Устанавливайте приоритеты для внедрения.

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

2. Выбирайте улучшения для внедрения.

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

3. Определяйте, как внедрять каждое улучшение.

Примеры, где улучшения могут быть внедрены, следующие:

  • Среды определенных проектов или общие рабочие среды
  • Семейства продуктов
  • Проекты организации
  • Организационные группы

4. Документируйте результаты процесса отбора.

Результаты процесса отбора, как правило, включают следующее:

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

5. Оценивайте любые изменения, которые необходимы для реализации улучшений.

Примеры изменений, необходимых для внедрения улучшения, включают следующее:

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

6. Обновляйте активы организационного процесса.

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

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

СЦ 3 Внедрить Улучшения

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

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

СП 3.1 Запланируйте внедрение

Устанавливайте и поддерживайте планы внедрения выбранных улучшений.

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

Эта конкретная практика дополняет специфическую практику Внедряйте Активы Организационных Процессов в процессной области Фокусирование на Организационных Процессах и добавляет использование количественных данных для внедрения и определения значимости улучшений.

См. процессную область Фокусирование на Организационных Процессах
для получения дополнительной информации о внедрении активов организационных процессов и включении полученного опыта.

Пример рабочих продуктов

1.Планы внедрений для выбранных улучшений

Подпрактики

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

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

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

3. Определите целевой набор проектов для внедрения улучшения.

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

4. Устанавливайте меры и цели для определения значения каждого улучшения в отношении целей качества и целей показателей процесса организации.

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

Примеры мер для определения значимости улучшения включают следующее:

  • Измеренные улучшения выполнения проекта или процесса организации
  • Время на возврат затрат по улучшению
  • Количество и типы проектных и организационных рисков, сниженных путем улучшения процесса или технологии
  • Среднее время, необходимое для реагирования на изменения в требованиях проекта, рыночной ситуации и бизнес-среде

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

5. Документируйте планы внедрения выбранных улучшений.

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

6. Выполняйте оценку и получите одобрение соответствующих заинтересованных сторон для планов внедрения выбранных улучшений.

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

7. Пересматривайте планы по внедрению выбранных улучшений по мере необходимости.

СП 3.2 Управляйте Внедрением

Управляйте внедрением выбранных улучшений.

Эта конкретная практика может пересекаться с конкретной практикой Реализовывайте Предложения Мероприятий в процессной области Анализ Причин и Принятие Решений (например, когда анализ причин и принятие решений используется организационно или в нескольких проектах).

Пример рабочих продуктов

1. Обновленные учебные материалы (с учетом внедренных улучшений)

2. Документально подтвержденные результаты мероприятий внедрения улучшения

3. Пересмотренные меры улучшений, цели, приоритеты и планы внедрения

Подпрактики

1. Отслеживайте внедрение улучшений с помощью планов внедрения.

2. Координируйте внедрение улучшений во всей организации.

Координация внедрения включает в себя следующие мероприятия:

  • Координация мероприятий проектов, групп поддержки и организационных групп для каждого улучшения
  • Координация мероприятий по внедрению связанных улучшений

3. Внедряйте улучшения в контролируемой и дисциплинированной манере.

Примеры методов для внедрения улучшений включают следующее:

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

4. Координируйте внедрение улучшений в процессы определенных для проектов в соответствующих случаях.

См. процессную область Фокусирование на Организационных Процессах
для получения дополнительной информации о внедрении активов организационных процессов и включении полученного опыта.

5. Предоставляйте консультации в случае необходимости для поддержки внедрения улучшений.

6. Обеспечивайте обновленные учебные материалы или разрабатывайте пакеты для распространения с учетом улучшения активов организационного процесса.

См. процессную область Организационное Обучение для получения дополнительной информации об обеспечении обучения.

7. Подтвердите, что внедрения всех улучшений завершены в соответствии с планом внедрения.

8. Задокументируйте и оцените результаты внедрения улучшений.

Документирование и анализ результатов включает в себя следующее:

  • Выявление и документирование накопленного опыта
  • Пересмотр мер улучшений, целей, приоритетов и планов развертывания

СП 3.3 Оценивайте Эффекты от Улучшения

Оценивайте эффекты от внедренных улучшений на качество и показатели процессов с использованием статистических и других количественных методов.

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

Эта конкретная практика может пересекаться со специфической практикой Оценивайте Эффект Реализованных Мероприятий в процессной области Анализ Причин и Принятие Решений (например, когда анализ причин и принятие решений применяется организационно или в нескольких проектах).

Пример рабочих продуктов

1. Документально подтвержденные меры эффектов, вызванные внедренными улучшениями

Подпрактики

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

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

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , | Leave a Comment »

 
%d такие блоггеры, как: