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

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

Archive for Декабрь 2018

Azure DevOps Services Rest Api. 10. Управление настройками команд

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

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

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

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

TeamContext teamContext = new TeamContext(TeamProjectName);

Итерации

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

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

Для добавления итерации в команду используется метод PostTeamIterationAsync, который принимает в качестве аргументов TeamSettingsIteration и контекст команды. Для объекта TeamSettingsIteration важен только уникальный идентификатор итерации, который можно получить через метод GetClassificationNodeAsync класса WorkItemTrackingHttpClient. Пример добавления итерации:

WorkItemClassificationNode projectIt = WitClient.GetClassificationNodeAsync(TeamProjectName, TreeStructureGroup.Iterations, iterationName).Result; // get iteration from project

TeamSettingsIteration teamIt = WorkClient.PostTeamIterationAsync(new TeamSettingsIteration { Id = projectIt.Identifier }, teamContext).Result; //add iteration to a team by guid

Console.WriteLine(«Added iteration « + teamIt.Name);

Удаление итерации из настроек команды выполняется подобным методом через метод DeleteTeamIterationAsync, при этом передаются контекст команды и идентификатор итерации:

WorkItemClassificationNode projectIt = WitClient.GetClassificationNodeAsync(TeamProjectName, TreeStructureGroup.Iterations, iterationNameToRemove).Result;

WorkClient.DeleteTeamIterationAsync(teamContext, projectIt.Identifier).SyncResult(); //delete iteration from team settings by guid

Console.WriteLine(«Removed iteration « + projectIt.Name);

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

TeamSettingsIteration currentiteration = (WorkClient.GetTeamIterationsAsync(teamContext, «Current»).Result).FirstOrDefault();

В результаты мы получаем объект TeamSettingsIteration, который включает:

  • Id – GUID итерации
  • Name – наименование итерации
  • Path – путь итерации
  • Attributes – дополнительные атрибуты итерации:
    • StartDate – дата начала итерации
    • FinishDate – дата окончания итерации
    • TimeFrame – фрейм итерации Past (прошедшая), Current (текущая), Future (будущая)

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

List<TeamSettingsIteration> teamIterations = WorkClient.GetTeamIterationsAsync(teamContext).Result; //get all iterations

Console.WriteLine(«Team Iterations: «);

foreach (TeamSettingsIteration teamIteration in teamIterations)

Console.WriteLine(«{0} : {1} : {2}-{3}», teamIteration.Attributes.TimeFrame, teamIteration.Name, teamIteration.Attributes.StartDate, teamIteration.Attributes.FinishDate);

Области

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

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

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

  • DefaultValue – строковое значение области по умолчанию.
  • Values – список областей TeamFieldValue, которые будет контролировать команда. TeamFieldValue включает наименование области Value и признак включения в контроль дочерних областей IncludeChildren.

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

TeamFieldValues teamAreas = WorkClient.GetTeamFieldValuesAsync(teamContext).Result; //Get All Areas

Console.WriteLine(«Default Area: « + teamAreas.DefaultValue);

Console.WriteLine(«Team Areas : «);

foreach (TeamFieldValue teamField in teamAreas.Values)

Console.WriteLine(«\t» + teamField.Value + ((teamField.IncludeChildren)? » (include sub-areas)» : «»));

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

string[] areas = { @»Application\WinClient», @»Application\WebClient» };

TeamFieldValues currentTeamAreas = WorkClient.GetTeamFieldValuesAsync(teamContext).Result; // get current areas

TeamFieldValuesPatch teamAreasPatch = new TeamFieldValuesPatch();

List<TeamFieldValue> newTeamAreas = new List<TeamFieldValue>(currentTeamAreas.Values); // just copy old areas. Here we may remove unneeded areas

foreach (string area in areas)

newTeamAreas.Add(new TeamFieldValue { Value = TeamProjectName + «\\» + area, IncludeChildren = false }); // add new areas

teamAreasPatch.DefaultValue = currentTeamAreas.DefaultValue;

teamAreasPatch.Values = newTeamAreas;

TeamFieldValues updatedTeamAreas = WorkClient.UpdateTeamFieldValuesAsync(teamAreasPatch, teamContext).Result;

Общие настройки

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

Получить текущие настройки можно через метод GetTeamSettingsAsync, который возвращает TeamSetting с атрибутами:

  • DefaultIteration – итерация, которая автоматически подставляется при создании нового рабочего элемента в контексте команды.
  • BacklogIteration – в рамках какой итерации отображаются рабочие элементы журнала требований.
  • DefaultIterationMacro – подстановка для определения текущей итерации: https://docs.microsoft.com/ru-ru/azure/devops/boards/queries/query-by-date-or-current-iteration?view=vsts#query-for-items-based-on-belonging-to-a-teams-current-iteration
  • BacklogVisibilities – список всех журналов, которые используются в проекте, и их отображение в команде.
  • WorkingDays – список дней, которые учитываются как рабочие для команды.

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

TeamContext teamContext = new TeamContext(TeamProjectName, TeamName);

TeamSetting teamSetting = WorkClient.GetTeamSettingsAsync(teamContext).Result;

Console.WriteLine(«Settings for the team « + TeamName);

Console.WriteLine(«Backlog Iteration : « + teamSetting.BacklogIteration.Name);

Console.WriteLine(«Default Iteration : « + teamSetting.DefaultIteration.Name);

Console.WriteLine(«Macro of Iteration : « + teamSetting.DefaultIterationMacro);

Console.WriteLine(«Categories of backlog:»);

foreach(string bkey in teamSetting.BacklogVisibilities.Keys)


if (teamSetting.BacklogVisibilities[bkey]) Console.WriteLine(«\t» + bkey);

Console.WriteLine(«Working days :»);

foreach (var wday in teamSetting.WorkingDays) Console.WriteLine(«\t» + wday.ToString());

switch (teamSetting.BugsBehavior)

{

case BugsBehavior.AsRequirements:

Console.WriteLine(«Bugs Behavior: Bugs in a requirements backlog.»);

break;

case BugsBehavior.AsTasks:

Console.WriteLine(«Bugs Behavior: Bugs in a sprint backlog as tasks.»);

break;

case BugsBehavior.Off:

Console.WriteLine(«Bugs Behavior: Find bugs through queries.»);

break;

}

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

TeamSetting teamSetting = WorkClient.GetTeamSettingsAsync(teamContext).Result;

TeamSettingsPatch teamSettingsPatch = new TeamSettingsPatch();

teamSettingsPatch.BacklogVisibilities = teamSetting.BacklogVisibilities;

if (teamSettingsPatch.BacklogVisibilities.ContainsKey(«Microsoft.EpicCategory») && teamSettingsPatch.BacklogVisibilities[«Microsoft.EpicCategory»])

teamSettingsPatch.BacklogVisibilities[«Microsoft.EpicCategory»] = false;

if (teamSettingsPatch.BacklogVisibilities.ContainsKey(«Microsoft.FeatureCategory») && teamSettingsPatch.BacklogVisibilities[«Microsoft.FeatureCategory»])

teamSettingsPatch.BacklogVisibilities[«Microsoft.FeatureCategory»] = false;

teamSetting = WorkClient.UpdateTeamSettingsAsync(teamSettingsPatch, teamContext).Result;

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

https://github.com/ashamrai/TFRestApi/tree/master/10.TFRestApiAppManageTeamSettings

English version

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

Azure DevOps Services Rest Api. 9. Управление командами проекта

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

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

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

  • Id – идентификатор.
  • Name – наименование команды.
  • Description – описание команды.
  • ProjectName – наименование проекта, в которую входит команда.
  • ProjectId – идентификатор проекта, в которую входит команда.

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

List<WebApiTeam> teams = TeamClient.GetTeamsAsync(TeamProjectName).Result;

Console.WriteLine(«Project Teams:»);

foreach (WebApiTeam team in teams) Console.WriteLine(team.Name);

Если необходимо получить информацию об участниках команды, то можно выполнить метод GetTeamMembersWithExtendedPropertiesAsync, в который передаются все те же имя проекта и имя команды. Участник команды описывается классом TeamMember, который содержит два свойства:

  • IsTeamAdmin – является ли участник команды администратором.
  • Identity – информация об учетной записи пользователя.

Пример изучения состава команды:

List<TeamMember> teamMembers = TeamClient.GetTeamMembersWithExtendedPropertiesAsync(TeamProjectName, TeamName).Result;

string teamAdminName = (from tm in teamMembers where tm.IsTeamAdmin == true
select tm.Identity.DisplayName).FirstOrDefault();

if (teamAdminName != null) Console.WriteLine(«Team Administrator:» + teamAdminName);

Console.WriteLine(«Team members:»);

foreach (TeamMember teamMember in teamMembers)

if (!teamMember.IsTeamAdmin) Console.WriteLine(teamMember.Identity.DisplayName);

 

Для создания и обновления команды используются методы CreateTeamAsync и UpdateTeam соответственно. Основные параметры это:

  • team – объект WebApiTeam, в котором устанавливаются наименование и описание команды.
  • projectId – наименование проекта команды
  • teamId – идентификатор существующей команды, который используется только при обновлении наименования или описания.

Пример обновления команды:

WebApiTeam team = TeamClient.GetTeamAsync(TeamProjectName, TeamName).Result;

WebApiTeam updatedTeam = new WebApiTeam {

Name = team.Name + » updated»,

Description = team.Description.Replace(«Created», «Updated»)

};

updatedTeam = TeamClient.UpdateTeamAsync(updatedTeam, team.ProjectName, team.Name).Result;

Console.WriteLine(«The team ‘{0}’ has been updated in the team project ‘{1}'», updatedTeam.Name, updatedTeam.ProjectName);

 

Для удаления команды используется метод DeleteTeamAsync с наименованием проекта и удаляемой команды:

TeamClient.DeleteTeamAsync(TeamProjectName, TeamName).SyncResult();

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

https://github.com/ashamrai/TFRestApi/tree/master/09.TFRestApiAppManageTeams

English version

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

Azure DevOps Services Rest Api. 8. Управление областями и итерациями в командном проекте

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

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

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

  • Id – идентификатор области или итерации.
  • Name – наименование области или итерации.
  • StructureType – тип объекта: «TreeNodeStructureType.Area» и «TreeNodeStructureType.Iteration».
  • Attributes – содержит дату начала и окончания итерации, которые доступны через ключи startDate и finishDate.

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

  • postedNode – объект WorkItemClassificationNode, который содержит наименование и атрибуты.
  • project – имя командного проекта, в котором будет создана область или итерация.
  • structureGroup – тип объекта: TreeStructureGroup.Areas или TreeStructureGroup.Iterations
  • path – путь к родительской области или итерации, если она необходима.

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

WorkItemClassificationNode newArea = new WorkItemClassificationNode();

newArea.Name = AreaName;

WorkItemClassificationNode result = WitClient.CreateOrUpdateClassificationNodeAsync(newArea, TeamProjectName, TreeStructureGroup.Areas, ParentAreaPath).Result;

 

Пример для создания итерации. Итерация создается также, как и область, но кроме этого можно использовать дополнительные необязательные атрибуты startDate и finishDate.

WorkItemClassificationNode newIteration = new WorkItemClassificationNode();

newIteration.Name = IterationName;

newIteration.Attributes = new Dictionary<string, object>();

newIteration.Attributes.Add(«startDate», StartDate);

newIteration.Attributes.Add(«finishDate», FinishDate);

WorkItemClassificationNode result = WitClient.CreateOrUpdateClassificationNodeAsync(newIteration, TeamProjectName, TreeStructureGroup.Iterations, ParentIterationPath).Result;

 

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

Удаление области или итерации выполняется через DeleteClassificationNodeAsync с параметрами:

  • project – имя командного проекта, в котором находится область или итерация.
  • structureGroup – тип объекта: TreeStructureGroup.Areas или TreeStructureGroup.Iterations
  • path – путь удаляемой области или итерации.
  • reclassifyId – идентификатор новой области или итерации, в которую будут перемещены рабочие элементы, которые находятся в удаляемой области или итерации.

Пример удаления.

WorkItemClassificationNode newNode = WitClient.GetClassificationNodeAsync(

TeamProjectName,

treeStructureGroup,

NewNodePath, 4).Result;

WitClient.DeleteClassificationNodeAsync(TeamProjectName, treeStructureGroup, NodePath, newNode.Id).SyncResult();

 

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

https://github.com/ashamrai/TFRestApi/tree/master/08.TFRestApiAppAreasAndIterations

English version

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

Azure DevOps Services Rest Api. 7. Добавление и редактирование связей между рабочими элементами

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

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

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

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/relations/-«,

Value = new {

rel = RelName,

url = RelUrl,

attributes = new

{

comment = Comment,

isLocked = IsLocked // you must be an administrator to lock a link

}

}

});

Указываются следующие атрибуты:

  • Operation – операция со ссылкой, в основном Add и Remove для добавления и удаления.
  • Path – может иметь следующие значения:
    • «/relations/-» – добавляется новая связь между рабочими элементами
    • «/relations/[индекс ссылки]» – для редактирования свойств или удаление ссылки, где [индекс ссылки] – порядковый номер ссылки в списке WorkItem.Relations.
  • Value – детализация информации о ссылке, которая содержит:
    • rel – наименование типа ссылки, перечень можно посмотреть здесь: Link type reference.
    • url – прямой url адрес к необходимому рабочему элементу.
    • attributes – дополнительные необязательные атрибуты ссылки:
      • comment – комментарий для ссылки.
      • isLocked – блокировка ссылки. Если ссылка заблокирована, то ее можно удалить только через API.

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

JsonPatchDocument patchDocument = new JsonPatchDocument();

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/relations/-«,

Value = new {

rel = «System.LinkTypes.Related»,

url = RelUrl,

attributes = new

{

comment = «Comment for the link»

}

}

});

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

Обновление выполняется по следующему примеру:

JsonPatchDocument patchDocument = new JsonPatchDocument();

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/relations/0»,

Value = new {

rel = «System.LinkTypes.Related»,

url = RelUrl,

attributes = new

{

comment = «New comment for the link»

}

}

});

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

Удаление выполняется по следующему шаблону:

JsonPatchDocument patchDocument = new JsonPatchDocument();

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Remove,

Path = «/relations/0»

});

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

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

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

https://github.com/ashamrai/TFRestApi/tree/master/07.TFRestApiAppWorkItemLinks

English version

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

Azure DevOps Services Rest Api. 6. Загрузка и получение вложений для рабочих элементов

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

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

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

Пример для загрузки вложения включает шаги:

  1. Создание потока для чтения содержимого файла.
  2. Создание вложения на сервисе через метод CreateAttachmentAsync, который включает параметры поток и наименование вложения. Можно использовать создание вложения без файлового потока, а только с наименованием файла. Но этот подход нужно использовать, если файл для вложения находится в локальном каталоге. Иначе имя файла во вложении будет содержать путь к файлу, а не просто его наименование.
  3. Обновление рабочего элемента. Формируется JsonPatchDocument, который добавляет новую связь для рабочего элемента с типом AttachedFile. Также передается URL вложения, который будет получен на шаге 2.

AttachmentReference att;

using (FileStream attStream = new FileStream(FilePath, FileMode.Open, FileAccess.Read))

att = WitClient.CreateAttachmentAsync(attStream, filePathSplit[filePathSplit.Length — 1]).Result; // upload the file

JsonPatchDocument patchDocument = new JsonPatchDocument();

patchDocument.Add(new JsonPatchOperation()

{

Operation = Operation.Add,

Path = «/relations/-«,

Value = new

{

rel = «AttachedFile»,

url = att.Url,

attributes = new { comment = «Comments for the file « + filePathSplit[filePathSplit.Length — 1] }

}

});

WitClient.UpdateWorkItemAsync(patchDocument, WIId).Result;

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

  1. Получить рабочий элемент и его ссылки. Что получить ссылки, в метод GetWorkItemAsync передается параметр expand: WorkItemExpand.Relations.
  2. Ссылки, которые имеют вложения, имеют тип AttachedFile в свойстве Rel класса WorkItemRelation. Если нам нужен конкретный файл, то его наименование можно найти через атрибут name.
  3. Для того, чтобы получить вложение, нам необходимо получить его идентификатор. Идентификатор можно выделить из URL вложения.
  4. Далее выполняется получение потока через метод GetAttachmentContentAsync и сохранение его в необходимом файле.

WorkItem workItem = WitClient.GetWorkItemAsync(WIId, expand: WorkItemExpand.Relations).Result;

foreach(var rf in workItem.Relations)

{


if (rf.Rel == «AttachedFile»)

{


string[] urlSplit = rf.Url.ToString().Split(new
char[] { ‘/’ }, StringSplitOptions.RemoveEmptyEntries);


using (Stream attStream = WitClient.GetAttachmentContentAsync(new Guid(urlSplit[urlSplit.Length — 1])).Result) // get an attachment stream


using (FileStream destFile = new FileStream(DestFolder + «\\» + rf.Attributes[«name»], FileMode.Create, FileAccess.Write)) // create new file

attStream.CopyTo(destFile); //copy content to the file

}

}

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

https://github.com/ashamrai/TFRestApi/tree/master/06.TFRestApiAppWorkItemAttachments

English version

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

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.

Это руководство намеренно представлено легким и может быть недостаточным для вас, чтобы адаптировать практику. Дополнительная информация доступна в виде полностью задокументированных практик и веб-публикаций на сайте 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 »

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