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

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

USE-CASE 2.0. Неофициальный перевод

Posted by Shamrai Alexander на Декабрь 10, 2018

 

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

Содержимое

Об этом руководстве

Как читать это руководство

Что такое сценарий использования 2.0?

Базовые принципы

Принцип 1: Сохранять их простыми, рассказывая истории

Принцип 2: Понимать общую картину

Принцип 3: Сосредотачивать внимание на значении

Принцип 4: Строить систему слайсами

Принцип 5: Поставлять систему инкрементами

Принцип 6: Адаптировать под потребности команды

Сценарий использования 2.0 – содержимое

С чем работать

Рабочие продукты

Что делать

Использование Сценария Использования 2.0

Сценарий Использования 2.0: применим для всех типов систем

Сценарий Использования 2.0: обрабатывает все виды требований

Сценарий использования 2.0: применим для всех подходов разработки

Сценарий Использования 2.0: масштабирование под ваши потребности

Заключение

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

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

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

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

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

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

Глоссарий

Благодарности

Общие

Людям

Библиография

Об Авторах

Реклама

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

USE-CASE 2.0. Заключение

Posted by Shamrai Alexander на Декабрь 9, 2018

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

Сценарий использования 2.0:

  • Легкий – в его определении и применении.
  • Масштабируем – и подходит для команд и систем всех размеров.
  • Универсален – и подходит для всех типов систем и подходов разработки.
  • Прост в использовании – модели сценариев использования могут быть быстро сформированы и слайсы созданы для покрытия требований команды.

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

Это руководство намеренно представлено легким и может быть недостаточным для вас, чтобы адаптировать практику. Дополнительная информация доступна в виде полностью задокументированных практик и веб-публикаций на сайте http://www.ivarjacobson.com. Это предлагается как отдельный веб сайт или расширение для EssWork.

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

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

USE-CASE 2.0. Об Авторах

Posted by Shamrai Alexander на Декабрь 9, 2018

Ивар Якобсон

Доктор Ивар Якобсон — отец компонентов и архитектуры компонентов, сценариев использования, аспектно-ориентированной разработки программного обеспечения, современного бизнес инжиниринга, Unified Modeling Language и Rational Unified Process. Его последним вкладом в индустрию программного обеспечения является концепция формальной практики, которая продвигает практики как «объекты первого класса» в разработке программного обеспечения и рассматривает процесс просто как совокупность практик. Он является основным автором шести влиятельных и самых продаваемых книг. Он является основным спикером на многих крупных конференциях по всему миру и обучил несколько консультантов по улучшению процессов.

Айян Спенс

Айян является главным техническим директором в Ivar Jacobson International, где он специализируется на гибком применении Unified Process. Он является сертифицированным практиком RUP, ScrumMaster-ом и является опытным тренером, поработав в 100-е проектов внедрения итеративный и гибких методов. Он имеет более чем 20 лет опыта в индустрии программного обеспечения, который охватывает полный жизненный цикл разработки, включая определение требований, архитектуру, анализ, проектирование, разработку и управление проектами. Его вопросами специализации являются итеративные проекты, работа с гибкими командами и управление требованиями через сценарии использования. В роли технического директора Айян способствует техническому направлению Ivar Jacobson International и работает с технологическим офисом компании для определения следующего поколения современных, активных практик разработки программного обеспечения. Он является лидером проекта и процессным архитектором разработки Essential Unified Process и практик, которые он содержит. Когда он не работает над исследованиями, поиском и определением практик, он проводит свое время, оказывая помощь компаниям в создании и выполнении программ изменений для повышения потенциала разработки программного обеспечения. Он является соавтором книги Addison Wesley «Use Case Modeling» и «Managing Iterative Software Development Projects».

Биттнер Курт

Курт – главный технический директор Ivar Jacobson International Северной и Южной Америки. Он проработал в индустрии программного обеспечения более чем 25 лет в различных ролях, включая разработчика, руководителя группы, архитектора, руководителя проекта и бизнес-лидера. Он вел гибкие проекты, запустил большой отдел разработки программного обеспечения для компании, спас и развил несколько стартапов, выполнял приобретения и работал с клиентами в различных отраслях промышленности, включая аэрокосмическую, финансы, энергетику и электронику. Он внес ключевой вклад в раннюю разработку Rational Unified Process, а также, совсем недавно, проект IBM Jazz. Его опыт включает в себя значительную работу в банковской сфере и финансов, проектирование и разработку архитектуры систем реляционных баз данных, консалтинг и наставничество широкого спектра клиентов по улучшении стратегии и подходов разработки программного обеспечения. Он является соавтором книг «Use Case Modeling», «Managing Iterative Software Development Projects» и «The Economics of Iterative Software Development».

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

USE-CASE 2.0. Библиография

Posted by Shamrai Alexander на Декабрь 9, 2018

Object Oriented Software Engineering: A Use Case Driven Approach

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Overgaard

Оригинальная книга, которая представила миру сценарии использования.

  • Publisher: Addison-Wesley Professional; Revised edition (July 10, 1992)
  • ISBN-10: 0201544350
  • ISBN-13: 978-0201544350

The Object Advantage: Business Process Reengineering With Object Technology

Ivar Jacobson, Maria Ericsson, Agneta Jacobson

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

  • Publisher: Addison-Wesley Professional (September 30, 1994)
  • ISBN-10: 0201422891
  • ISBN-13: 978-0201422894

Software Reuse: Architecture, Process and Organization for Business Success

Ivar Jacobson, Martin Griss, Patrik Jonsson

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

  • Publisher: Addison-Wesley Professional (June 1, 1997)
  • Language: English
  • ISBN-10: 0201924765
  • ISBN-13: 978-0201924763

Use-Case Modeling

Kurt Bittner and Ian Spence

Полное руководство для создания модели сценариев использования и написания хороших вариантов использования.

  • Publisher: Addison-Wesley Professional; 1 edition (August 30, 2002)
  • ISBN-10: 0201709139
  • ISBN-13: 978-0201709131

Aspect-Oriented Software Development with Use Cases

Ivar Jacobson and Pan-Wei Ng

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

  • Publisher: Addison-Wesley Professional; 1 edition (January 9, 2005)
  • ISBN-10: 0321268881
  • ISBN-13: 978-0321268884

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

USE-CASE 2.0. Благодарности

Posted by Shamrai Alexander на Декабрь 9, 2018

Общие

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

Людям

Мы также хотели бы поблагодарить всех, кто непосредственно способствовал созданию этой книги, включая, но без определенного порядка: Пол Мак-Магон, Ричард Скафф, Эрик Лопес Кардосо, Сванте Лидман, Крейг Люций, Тони Людвиг, Рон Гартон, Буркхард Перкинс-Голомб, Арран Хартгровес, Джеймс Гэмбл, Брайан Хупер, Стефан Байлунд и Пан Вэй Нг.

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

USE-CASE 2.0. Глоссарий

Posted by Shamrai Alexander на Декабрь 9, 2018

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

Аспектно-ориентированное программирование: Технология программирования, которая стремится повысить модульность через обеспечение разделения сквозных ответственностей (см. http://en.wikipedia.org/wiki/Aspect-oriented_programming).

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

Заинтересованное лицо: Лицо, группы или организация, которая затрагивает или затрагивается программной системой.

Заказчик: Заинтересованная сторона, которая оплачивает развитие системы или которая, как ожидается, купит систему после ее завершения.

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

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

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

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

Пользователь: Заинтересованное лицо, которое взаимодействует с системой для достижения своей цели.

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

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

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

Разделение ответственности: Процесс расщепления системы для сведения к минимуму дублирования функциональности (см. http://en.wikipedia.org/wiki/Separation_of_concerns).

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

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

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

Сценарий использования: сценарий использования – это все пути использования системы для достижения определенной цели для определенного пользователя.

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

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

Требования: Что программная система должны делать для удовлетворения заинтересованных сторон.

Элемент системы: Единица набора элементов, который представляет собой систему (ISO/IEC 15288:2008).

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

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

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

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

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

Эти же шаблоны можно применять при создании рабочих элементов на основе 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 »

Azure DevOps Services Rest Api. 4. Выполнение запросов по рабочим элементам

Posted by Shamrai Alexander на Октябрь 17, 2018

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

  • GetQueryAsync – информация о запросе по рабочим элементам.
  • QueryByWiqlAsync – выполнение запроса WIQL.
  • CreateQueryAsync – создание нового запроса по рабочим элементам.
  • UpdateQueryAsync – обновление существующего запроса.
  • DeleteQueryAsync – удаление существующего запроса.

Получить детальную информацию об известном запросе по рабочим элементам можно через метод GetQueryAsync со следующими основными параметрами:

  1. project – имя командного проекта, в котором находится запрос.
  2. query – путь к запросу, детализацию которого нужно получить.
  3. expand – уровень детализации информации о запросе.
  4. depth – количество уровней дочерних запросов и каталогов, который будет загружен в ответ метода

Пример выполнения метода:

QueryHierarchyItem detiledQuery = WitClient.GetQueryAsync(project, query.Path, QueryExpand.All, 1).Result;

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

  1. Name – наименование запроса
  2. Path – полный путь к запросу.
  3. IsFolder – признак, что это каталог.
  4. Wiql – Wiql текст запроса
  5. HasChildren – признак, что существуют дочерние экземпляры.
  6. Children – список дочерних экземпляров.

Для получения информации о корневых запросах (обычно это «Мои запросы» и «Общие запросы») можно использовать метод GetQueriesAsync, который имеет почти такие же параметры, как и в GetQueryAsync. Отличается только отсутствием параметра query, т.к. выполняется получение информации из корня дерева запросов.

List<QueryHierarchyItem>
rootQueries = WitClient.GetQueriesAsync(project, QueryExpand.All).Result;

Выполнить запрос можно через метод QueryByWiqlAsync со следующими параметрами:

  1. wiql – текст запроса на основе синтаксиса WIQL.
  2. project – наименование командного проекта, если используется макрос @project в теле запроса.

Пример выполнения метода:

WorkItemQueryResult result = WitClient.QueryByWiqlAsync(wiql, teamProject).Result;

Результат WorkItemQueryResult может быть обработан двумя методами:

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

foreach (var wiRef in result.WorkItems)

{

var wi = GetWorkItem(wiRef.Id);

Console.WriteLine(String.Format(«{0} — {1}», wi.Id, wi.Fields[«System.Title»].ToString()));

}

2. Если запрос включает ссылки, то результат можно получить из атрибута WorkItemRelations, который представляет собой список экземпляров WorkItemLink. WorkItemLink включает атрибуты:

  1. Rel – системное наименование ссылки. Наименование будет пустым, если это элемент верхнего уровня.
  2. Source – экземпляр WorkItemReference, который определяет рабочий элемент источник ссылки. Будет равным null, если это элемент верхнего уровня.
  3. Target – экземпляр WorkItemReference, который определяет рабочий элемент, на который ссылаются.

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

foreach (var wiRel in result.WorkItemRelations)

{

if (wiRel.Source == null)

{

var wi = GetWorkItem(wiRel.Target.Id);

Console.WriteLine(String.Format(«Top Level: {0} — {1}», wi.Id, wi.Fields[«System.Title»].ToString()));

}

else

{

var wiParent = GetWorkItem(wiRel.Source.Id);

var wiChild = GetWorkItem(wiRel.Target.Id);

Console.WriteLine(String.Format(«{0} —> {1} — {2}», wiParent.Id, wiChild.Id, wiChild.Fields[«System.Title»].ToString()));

}

}

Запрос по рабочим элементам можно сконструировать с помощью синтаксиса WIQL: Syntax for the Work Item Query Language (WIQL). Однако можно пойти простым путем:

  1. В Visual Studio создать запрос и сохранить его на локальный диск:

  1. Сам текст WIQL можно просмотреть в теле запроса с помощью блокнота:

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

  1. Получить WIQL текст запроса через метод GetQueryAsync
  2. Выполнить запрос через метод QueryByWiqlAsync

Пример выполнения сохраненного запроса:

QueryHierarchyItem query = WitClient.GetQueryAsync(teamProject, queryPath, QueryExpand.Wiql).Result;

WorkItemQueryResult result = WitClient.QueryByWiqlAsync(query.Wiql, teamProject).Result;

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

https://github.com/ashamrai/TFRestApi/blob/master/04.TFRestApiAppWorkItemQueries

English version

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

(VSTS) Azure DevOps Services Rest Api. 3. Создание и редактирование рабочих элементов

Posted by Shamrai Alexander на Сентябрь 20, 2018

Для создания и редактирования рабочих элементов используется клиент WorkItemTrackingHttpClient с методами CreateWorkItemAsync и UpdateWorkItemAsync. Основным параметром, который используется для создания и обновления рабочих элементов, является JsonPatchDocument, который содержит информацию о полях в виде списка JsonPatchOperation.

JsonPatchOperation включает в себя следующие поля:

  • Operation – операция, выполняемая с полем:
    • Add – вставить новое значение.
    • Remove – удалить значение из поля.
    • Replace – заменить значение в поле.
    • Test – проверить значение в поле перед обновлением рабочего элемента.
  • Path – путь к полю, значение которого обновляется. Путь поля выглядит как «/fields/{Имя_поля}» или «/fields/{Ссылочное_имя_поля}»
  • Value – значение поля.

Создание выполняется через CreateWorkItemAsync с параметрами JsonPatchDocument, имя проекта и название типа рабочего элемента:

Dictionary<string, object> fields = new Dictionary<string, object>();
fields.Add(«Title», «Bug from app»);
fields.Add(«Repro Steps», «<ol><li>Run app</li><li>Crash</li></ol>»);
fields.Add(«Priority», 1);

var newBug = CreateWorkItem(«TFSAgile», «Bug», fields);

static WorkItem CreateWorkItem(string ProjectName, string WorkItemTypeName, Dictionary<string, object> Fields)
{

JsonPatchDocument patchDocument = new JsonPatchDocument();

foreach (var key in Fields.Keys)

patchDocument.Add(new JsonPatchOperation() {

Operation = Operation.Add,
Path = «/fields/» + key,
Value = Fields[key]

});

return WitClient.CreateWorkItemAsync(patchDocument, ProjectName, WorkItemTypeName).Result;

}

Обновление выполняется через UpdateWorkItemAsync с параметрами JsonPatchDocument и идентификатор рабочего элемента:

Dictionary<string, object> fields = new Dictionary<string, object>();
fields.Add(«Title», «Bug from app updated»);
fields.Add(«Repro Steps», «<ol><li>Run app</li><li>Crash</li><li>Updated step</li></ol>»);
fields.Add(«History», «Comment from app»);
var editedBug = UpdateWorkItem(WIId, fields);

static WorkItem UpdateWorkItem(int WIId, Dictionary<string, object> Fields)
{

JsonPatchDocument patchDocument = new JsonPatchDocument();

foreach (var key in Fields.Keys)

patchDocument.Add(new JsonPatchOperation()
{

Operation = Operation.Add,
Path = «/fields/» + key,
Value = Fields[key]

});

return WitClient.UpdateWorkItemAsync(patchDocument, WIId).Result;

}

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

https://github.com/ashamrai/TFRestApi/tree/master/03.TFRestApiAppCreateEditWorkItems

English version

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

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