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

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

Archive for Ноябрь 2018

Azure DevOps Services Rest Api. 5. Создание рабочих элементов на основе шаблонов

Posted by Shamrai Alexander на Ноябрь 29, 2018

<< Перейти в радел «Azure DevOps Services (TFS/VSTS) Rest Api»

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

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

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

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

  • Получить информацию о проекте через клиента ProjectHttpClient.
  • Создать контекст команды TeamContext, в которой хранится шаблон рабочего элемента. В данном примере используется контекст команды по умолчанию.
  • Через контекст команды получить список всех шаблонов через метод GetTemplatesAsync, из которого уже можно получить идентификатор необходимого шаблона. Метод принимает только один параметр – контекст команды. Результат метода – список шаблонов WorkItemTemplateReference без набора полей.
  • Получить полную информацию о шаблоне и его полях через метод GetTemplateAsync. Данный метод требует использование контекста команды и идентификатора необходимого шаблона.

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

//получить проект

var project = ProjectClient.GetProject(projectName).Result;

//создать контекст команды

TeamContext tmcntx = new TeamContext(project.Id, project.DefaultTeam.Id);

//получить все шаблоны команды

var templates = WitClient.GetTemplatesAsync(tmcntx).Result;

//получить идентификатор шаблона через его имя

var id = (from tm in templates where tm.Name == templateName select tm.Id).FirstOrDefault();

if (id != null) return WitClient.GetTemplateAsync(tmcntx, id).Result;

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

  1. Id – идентификатор шаблона.
  2. Name – наименование шаблона.
  3. WorkItemTypeName – наименование типа рабочего элемента, к которому применяется шаблон.
  4. Fields – словарь с набором полей по умолчанию и их значениями.

Получив поля, уже можно создавать новый рабочий элемент:

Dictionary<string, object> fields = new Dictionary<string, object>();//поля пользователя

fields.Add(«System.Title», «New work item»);

JsonPatchDocument patchDocument = new JsonPatchDocument();

foreach (var templateKey in template.Fields.Keys) //применяем все поля из шаблона

if (!fields.ContainsKey(templateKey)) //исключаем поля, которые определяет пользователь

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/fields/» + templateKey,

Value = template.Fields[templateKey]

});

//добавляем поля пользователя

foreach (var key in fields.Keys)

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/fields/» + key,

Value = fields[key]

});

return WitClient.CreateWorkItemAsync(patchDocument, projectName, template.WorkItemTypeName).Result;

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/05.TFRestApiAppCreateWorkItemFromTemplate

English version

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

USE-CASE 2.0. Приложение 1. Рабочие продукты

Posted by Shamrai Alexander на Ноябрь 16, 2018

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

Это следующие рабочие продукты:

  • Вспомогательная информация
  • Тестовый сценарий
  • Модель сценариев использования
  • Повествование сценария использования
  • Реализация сценария использования

Вспомогательная информация

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

Вспомогательная информация:

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестовый сценарий

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

Тестовые сценарии:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель сценариев использования

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

Модель варианта использования:

  • Позволяет команде согласовать требуемую функциональность и характеристики системы.
  • Четко устанавливает границы системы, предоставляя полную картину своих субъектов (вне системы) и сценариев использования (внутри системы).
  • Обеспечивает гибкое управление требованиями.

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

Модели сценариев использования могут быть представлены на различных уровнях детализации:

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

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

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

Такой уровень детализации полезен при моделировании совершенно новых систем или новых поколений существующих систем. На этом уровне детализации все системные субъекты и сценарии использования определяются и моделируются.

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

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

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

Повествование сценария использования

Цель повествования сценария использования – рассказать историю о том, как система и ее субъекты работают вместе для достижения определенной цели.

Повествования сценария использования:

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

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

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

Кратко описаны: Легкий уровень детализации, который просто фиксирует цель сценария использования и какой субъект его запускает.

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

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

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

Существенно описаны: Иногда необходимо уточнить ответственности системы и ее субъектов во время определения сценария использования. Маркированные наброски фиксируют их обязанности, но четко не определяют за какие части сценария использования ответственна система, а за какие субъект(ы).

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

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

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

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

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

Реализация сценария использования

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

Реализация сценария использования:

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

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

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

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

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

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

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

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

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

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

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

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

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