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

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

Archive for Сентябрь 2018

(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 »

VSTS Rest Api. 2. Получение рабочих элементов

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

Список примеров: Microsoft Visual Studio Team Services Rest Api

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

  • Для получения одного рабочего элемента GetWorkItemAsync или нескольких GetWorkItemsAsync со следующими основными параметрами:
    • Id – идентификатор рабочего элемента, который необходимо получить. Для GetWorkItemsAsync используется список идентификаторов.
    • fields – список полей, которые необходимо получить в рабочем элементе
    • asOf – строка, которая содержит дату, которой должно соответствовать содержание рабочего элемента.
    • expand – получить расширенные свойства рабочего элемента. Возможные варианты (на практике используются обычно all и relations):
      • all – получить все свойства.
      • fields – получить только поля.
      • links – получить дополнительно справочные ссылки.
      • none – без дополнительных свойств.
      • relations – получить дополнительно информацию о связях.
  • Для типов рабочих элементов GetWorkItemTypeAsync со следующими параметрами:
    • project – имя проекта
    • type – имя типа рабочего элемента

Класс рабочего элемента можно представить в следующем виде:

public class
WorkItem

{

public int? Id { get; set; }

public int? Rev { get; set; }

public
IDictionary<string, object> Fields { get; set; }

public
IList<WorkItemRelation> Relations { get; set; }

public
ReferenceLinks Links { get; set;
}

}

Поля класса:

  • Id – идентификатор рабочего элемента.
  • Rev – номер версии рабочего элемента.
  • Fields – словарь в виде «имя поля» — «его значение». Этот список содержит только поля, которые имеют установленные значения. Если нужно знать наличие поля в типе рабочего элемента, то его можно получить через GetWorkItemTypeAsync, как указано в примере.
  • Relations – список связей рабочего элемента.
  • Links – класс с дополнительными вспомогательными ссылками на сам рабочий элемент, его тип, поля, истории и т.д.

Пример вызовов методов для получения рабочих элементов:

  • Получить один рабочий элемент:


static WorkItem GetWorkItem(int Id)

{

return WitClient.GetWorkItemAsync(Id).Result;

}

  • Получить рабочий элемент и его связи:


static WorkItem GetWorkItemWithRelations(int Id)

{

return WitClient.GetWorkItemAsync(Id, expand: WorkItemExpand.Relations).Result;

}

  • Получить тип рабочего элемента:


static WorkItemType GetWorkItemType(WorkItem WI)

{

return WitClient.GetWorkItemTypeAsync((string)WI.Fields[«System.TeamProject»], (string)WI.Fields[«System.WorkItemType»]).Result;

}

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

https://github.com/ashamrai/TFRestApi/tree/master/02.TFRestApiAppGetWorkItems

English version

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Итеративные подходы на основе журналов, такие как Scrum, EssUP и OpenUP
  • На основе потока целых частей, такие как Kanban
  • Подход все-в-одном, такие как традиционный водопад

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

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

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

Рисунок 1. Концепция журнала

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

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

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

Рисунок 2. Активности для итеративных подходов на основе журналов

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

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

Хоть разработка является постоянной, команда также использует «Изучать и адаптировать сценарии использования», «Разделить сценарии использования» и «Подготовить слайс сценария использования» для поддержки журнала, обработки изменений и обеспечения уверенности в том, что есть достаточно элементов журнала, готовых для следующей итерации. Команде может даже понадобиться использовать «Найти субъекты и сценарии использования» для обработки крупных изменений или поиска большего количества сценариев использования для команды. В Scrum команде рекомендуется тратить 5-10 процентов от их времени для поддержки их журнала. Это незначительные дополнительные расходы для команды, и Сценарий Использования 2.0 обеспечивает рабочие продукты и активности, необходимые для простого и эффективного выполнения этой деятельности.

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

Сценарий использования 2.0 и поток целых частей

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

Рисунок 3. Концепция потока целых частей

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

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

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

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

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

Рисунок 5. Слайсы сценариев использования на Kanban доске

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

Слайсы берутся из входной очереди в область подготовки, где проводится анализ влияния, истории уточняются и финализируются тестовые сценарии. Здесь лимит выполняемой работы равен 3 пунктам. Элементы, которые находятся в столбце «on-going», в текущее время обрабатываются. Элементы в столбце «Done» завершены и ждут их принятия разработчиком. Таким же образом, слайсы проходят через команду разработки и, после успешного прохождения независимого тестирования системы, переходят в эксплуатацию. Лимит выполняемой работы покрывает всю работу на станции, включая текущие и выполненные элементы. Лимит выполняемой работы на выходе или ограничение на количество элементов, которые будут выпущены, не устанавливается.

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

Рисунок 6. Выравнивание состояний слайсов сценариев использования к Канбан доске

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

Рисунок 7. Активности для подхода потока целых частей

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

Рисунок 8. Kanban доска команды, отражающая завершающие состояния

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

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

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

Рисунок 9. Активности для подхода водопад

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

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

Рисунок 10. Уровни детализации для рабочих продуктов в подходе водопад

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

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

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

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

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

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

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

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

  1. Сценарии использования масштабируются для предоставления более подробных руководств для менее опытных специалистов (разработчиков, тестировщиков, аналитиков и т.д.) или для практиков, которые хотят или нуждаются в более подробных руководствах.
  2. Они масштабируются, чтобы покрыть весь жизненный цикл, охватывающий не только анализ, проектирование, кодирование и тестирование, но также эксплуатацию и поддержку.
  3. Они масштабируются для поддержки крупных и очень крупных систем, например, системы систем: корпоративные системы, производственные линии и многослойные системы. Такие системы являются сложными и обычно разрабатываются множеством команд, работающими параллельно, на различных локациях, возможно, для разных компаний, и повторно используя много старых систем или пакетных решений.

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

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

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