Внимание ! Вопросы к тесту выложены исключительно в ознакомительных целях: количество вопросов может не совпадать с действительным, актуальность не поддерживается,- за решением теста Welcome to the cashier! Группа испытателей – это:
группа, отвечающая за своевременное создание сборок группа, тестирующая программные модули группа, которой передаются сборки для тестирования.
Тестирование сборок проекта осуществляется:
группой разработки группой испытателей всей командой разработчиков
К функциям, выполняемым TFS относятся:
обеспечение связей между командами разработчиков и тестировщиков централизованное хранение кода обеспечение группы испытателей инструментарием для создания тестов
Тестирование программных модулей осуществляется:
группой испытателей группой разработчиков всей командой разработчиков
К функциям группы разработки относятся:
реализация программных модулей тестирование программных модулей создание сборок проекта
Хранилище исходных кодов является частью:
среды разработки среды тестирования Team Foundation Server
Регистрацией ошибок занимается:
группа разработчиков группа тестирования руководитель проекта
Рабочий элемент «ошибка» создается:
группой разработчиков, с целью маркировки проблемного участка кода и дальнейшего исправления группой тестирования, с целью привлечения внимания разработчиков к выявленной в процессе тестирования сборки неисправности
Рабочий элемент ошибка:
позволяет группе тестирования отслеживать работу группы разработчиков служит для организации обратной связи по результатам тестирования является критерием оценки качества сборки
Обозреватель исходного кода используется:
группой тестирования для доступа к исходному коду проекта с целью контроля его качества группой разработки с целью загрузки исходного кода для локальной работы
Разработчик, взаимодействуя с TFS:
получает доступ к рабочим элементам «ошибка» получает возможность использовать обозреватель исходного кода разрешает существующие ошибки
Тестировщик, взаимодействуя с TFS:
регистрирует ошибки разрешает существующие ошибки извлекает результаты плановой сборки
К среде тестирования относятся:
TFS Visual Studio Team Edition for Software Testers сервер сборок
Сервер сборок является частью:
среды разработчиков среды тестирования TFS
К среде разработки относятся:
сервер сборки хранилище исходных кодов Visual Studio Team Test Load
Максимальное число пользователей, поддерживаемое топологиями разработки:
500 1000 2000
Многосерверная топология разработки поддерживает:
до 2500 пользователей до 2000 пользователей до 1500 пользователей
Односерверная топология разработки поддерживает:
50 пользователей от 50 до 200 пользователей до 400 пользователей
ASP.Net веб – службы связывают:
клиентский уровень и уровень приложений клиентский уровень и уровень данных уровень приложений и уровень данных
Уровень приложений взаимодействует с уровнем данных:
через веб – службы на уровне данных через Windows - службы
Взаимодействие клиентов с уровнем приложений осуществляется:
на уровне данных через windows – службы посредством веб – служб
Службы сборки данных являются частью:
клиентского уровня уровня приложений уровня данных
Службы отчетов SQL Server относятся к:
клиентскому уровню уровню данных уровню приложений
Портал проекта является частью:
клиентского уровня уровня приложений уровня данных
Team Foundation Build относится:
к уровню приложений, как служба Team Foundation к уровню данных, как хранилище данных о сборках к уровню данных, как служба Team Foundation
Отслеживание рабочих элементов осуществляется:
на клиентском уровне на уровне приложений на уровне данных
Службы данных Team Foundation являются частью:
клиентского уровня уровня приложений уровня данных
Можно ли установить TFS на контроллер домена?
да нет зависит от вида топологии разработки
БД TFS должна быть распределена между несколькими серверами:
да нет зависит от вида топологии разработки
Должны ли веб – службы уровня приложений быть распределены между серверами?
да нет зависит от вида топологии разработки
В многосерверной топологии
уровень приложений ставится отдельно от уровня данных взаимодействие клиентского уровня с уровнем данных осуществляется посредством HTTP(s) SQL Server является частью сервера приложений
В односерверной топологии:
уровень приложений ставится отдельно от уровня данных взаимодействие клиентского уровня с уровнем данных осуществляется посредством HTTP(s) SQL Server является частью сервера приложений
Службы Team Foundation Build Services могут быть установлены:
на уровне приложений на специальный сервер на несколько специальных серверов
На уровне приложений находятся:
службы управления версиями службы сборки службы отслеживания рабочих элементов
На клиентском уровне находятся:
Visual Studio Team Explorer MS SQL Server
На уровне данных находятся:
MS SQL Server службы сборки БД рабочих элементов
Файл с расширением .csproj - это:
файл решения файл с# проекта файл проекта visual basic
Файл с расширением .sln - это:
файл решения файл с# проекта файл проекта visual basic
Файл с расширением .vbproj - это:
файл решения файл с# проекта файл проекта visual basic
Размещение всех проектов в одиночном решении - это стратегия:
одиночное решение решение с разделами несколько решений
Группировка связанных проектов несколькими решениями и создание глобального решения - это стратегия:
одиночное решение решение с разделами несколько решений
Создание самостоятельных решений для каждой из проектируемых подсистем при отсутствии глобального решения - это стратегия:
одиночное решение решение с разделами несколько решений
Стратегия одиночного решения:
используется даже если получившееся решение слишком велико для загрузки в Visual Studio позволяет легко составить карту зависимостей между проектами допускает использование файловых ссылок
Стратегия одиночного решения:
используется даже если получившееся решение слишком велико для загрузки в Visual Studio дает возможность отдельно рассматривать подсистемы разрабатываемого приложения позволяет обойтись без файловых ссылок
Стратегия решения с разделами
дает возможность отдельно рассматривать подсистемы разрабатываемого приложения позволяет использовать главное решение для сборки всего приложения упрощает разработку, поскольку при открытии решения сразу становится доступным весь код
Стратегия решения с разделами
позволяет использовать главное решение для сборки всего приложения упрощает разработку, поскольку при открытии решения сразу становится доступным весь код способствует уменьшению общей сложность работы с учетом логического разделения решений
Стратегия решения с разделами
дает возможность отдельно рассматривать подсистемы разрабатываемого приложения сокращает время, необходимое для загрузки и сборки всего приложения упрощает разработку, поскольку при открытии решения сразу становится доступным весь код
Стратегия нескольких решений:
позволяет собрать приложение средствами Visual Studio используется для преодоления ограничения масштабируемости требует наличия главного решения для сборки всего приложения
Стратегия нескольких решений:
позволяет избежать проблем с производительностью используется для преодоления ограничения масштабируемости позволяет обойтись без главного решения
Рабочая область:
является клиентской копией файлов и папок системы управления исходным кодом не может содержать ссылки на несколько проектов назначается только учетным записям пользователей
Рабочая область:
является клиентской копией файлов и папок системы управления исходным кодом может содержать ссылки на несколько проектов назначается только учетным записям пользователей
Рабочая область:
является клиентской копией файлов и папок системы управления исходным кодом может содержать ссылки на несколько проектов назначается только компьютерам
В систему управления версиями следует включать:
файлы решений метаданные проекта Visual Studio Source Control файлы проекта
В систему управления версиями не следует включать:
файлы решений метаданные проекта Visual Studio Source Control результаты сборки
В систему управления версиями следует включать:
файлы решений метаданные проекта Visual Studio Source Control результаты сборки
Ветвление проектов оправдано в случае:
наличия проблемы сломанных сборок если команда разработчиков работает по короткому циклу выпуска наличия изолированных групп разработки
Для ветвления проекта характерно:
увеличение общего числа работ уменьшение числа сломанных сборок маркировка сборок
Сценарий ветвления "без ветвей" оправдывает себя в случае:
наличия проблемы сломанных сборок если команда разработчиков работает по короткому циклу выпуска если команда разработчиков работает по продолжительному циклу выпуска
При организации ветвления не следует:
организовывать ветвление так, чтобы слияние выполнялось только поперек иерархии учитывать потребность разработчиков в одновременной работе над одними и теми же файлами включать в ветвление файлы конфигурации и исходного кода
Логическая структура ветвлений и слияний:
является отражением физической структуры, используемым при изоляции выпуска выражает для каждой ветви отражение "родитель - потомок" может отличаться от структуры, отображаемой в обозревателе решений
При организации ветвления необходимо:
организовывать ветвление так, чтобы слияние выполнялось только поперек иерархии учитывать потребность разработчиков в одновременной работе над одними и теми же файлами включать в ветвление файлы конфигурации и исходного кода
Возможны следующие варианты сценариев управления зависимостями:
ссылка на файл сборки другого проекта в том же решении ссылка на файл сборки проекта в другом решении ссылка на файл сборки из другого командного проекта
Ссылка на проект Visual Studio позволит автоматизировать:
конфигурация объединения исходного кода создается на стороне сервера конфигурация объединения исходного кода создается на стороне клиента изменения в общем проекте учитываются при копировании последней версии исходного кода в рабочую область
Синхронизация изменений исходного кода при ветвлении осуществляется:
при слиянии ветвей проекта вручную, средствами обозревателя исходного кода автоматически, при изменении общего кода в одной из ветвей
При сопоставлении рабочей области:
конфигурация объединения исходного кода создается на стороне сервера конфигурация объединения исходного кода создается на стороне клиента изменения в общем проекте не учитываются при копировании последней версии исходного кода в рабочую область
При сохранении строки подключения в пользовательском файле конфигурации не следует:
разворачивать user.config отдельно от кода приложения добавлять user.config в систему управления исходным кодом создавать user.config в папке с файлом конфигурации приложения, чтобы перекрыть его настройки
При сохранении строки подключения в пользовательском файле конфигурации необходимо:
развернуть user.config отдельно от кода приложения добавить user.config в систему управления исходным кодом создать user.config в папке с файлом конфигурации приложения, чтобы перекрыть его настройки
При сохранении строки подключения в пользовательском файле конфигурации необходимо:
развернуть user.config отдельно вместе с кодом приложения добавить user.config в систему управления исходным кодом создать user.config в папке с файлом конфигурации приложения, чтобы перекрыть его настройки
Логическое место накопления результатов сборки:
находится на уровне данных входит в состав сервера сборки не входит с состав сервера сборки и уровней клиентов, приложений и данных
TFS интегрирован с Team Build:
на уровне данных на уровне служб на уровне приложений
Файл TFSBuild.proj
создается автоматически при создании сборки нельзя редактировать вручную определяет выполняемые во время сборки тесты
Какое из перечисленных утверждений неверно?
Team Foundation Build не зависит от MSBuild TeamBuild поддерживает интеграцию с рабочими элементами генерацию уведомлений о состояниях сборки можно организовать с помощью TeamBuild
Справедливы следующие утверждения:
Team Foundation Build зависит MSBuild TeamBuild не поддерживает интеграцию с рабочими элементами генерацию уведомлений о состояниях сборки можно организовать с помощью TeamBuild
Справедливы следующие утверждения:
Team Foundation Build не зависит от MSBuild TeamBuild поддерживает интеграцию с рабочими элементами генерацию уведомлений о состояниях сборки можно организовать с помощью TeamBuild
Необязательными этапами сборки являются:
создание рабочего элемента, при возникновении ошибки оценка покрытия кода тестами Копирование сборки в место накопления
Обязательными этапами сборки являются:
создание рабочего элемента, при возникновении ошибки оценка покрытия кода тестами выполнение тестов
Необязательными этапами сборки являются:
создание рабочего элемента, при возникновении ошибки оценка покрытия кода тестами анализ кода
По умолчанию Team Build:
поддерживает проекты установки поддерживает приложения VB6.0 не поддерживает приложения .Net 1.1
По умолчанию Team Build:
поддерживает проекты установки не поддерживает приложения VB6.0 не поддерживает приложения .Net 1.1
По умолчанию Team Build:
не поддерживает проекты установки поддерживает приложения VB6.0 не поддерживает приложения .Net 1.1
Сборка с непрерывной интеграцией - это:
ежедневно осуществляющаяся сборка сборка, осуществляющаяся по истечению определенного времени сборка пир каждом возврате исходного кода
Сборка при каждом возврате исходного кода - это:
скользящая сборка сборка интеграции сборка разработки
Сборка при каждом возврате исходного кода может использоваться в следующих сценариях:
ежедневная сборка сборка с непрерывной интеграцией несколько лабораторий сборки
Потребителями плановых сборок чаще всего являются:
заказчики внешние контролеры тестировщики
Потребителями непрерывной интеграции чаще всего являются
команды разработчиков внешние контролеры команды тестирования
Потребителями плановых сборок чаще всего являются:
заказчики внешние контролеры команды разработчиков
По - умолчанию Team Foundation Server не поддерживает:
плановые сборки непрерывную интеграцию возврат кода с контролем качества
Непрерывная интеграция:
это стратегия сборки при каждом возврате исходного кода поддерживается TFS по умолчанию не поддерживает оперативное исправление кода
Непрерывная интеграция:
не поддерживается по - умолчанию Team Foundation Server поставляет оперативную информацию о качестве сборки не поддерживает оперативное исправление кода
Простейшим сценарием скользящей сборки является сборка:
после определенного числа возвратов по истечении заданного промежутка времени после определенного числа возвратов и по истечении определенного промежутка времени
Сценарий сборки, при котором последний возврат кода в течении рабочего дня почти гарантировано не инициирует сбоку, называется сборкой:
после определенного числа возвратов по истечении заданного промежутка времени после определенного числа возвратов и по истечении определенного промежутка времени
Недостатком какого сценария сборки является задержка информации о качестве кода, при последнем возврате рабочего дня:
после определенного числа возвратов по истечении заданного промежутка времени после определенного числа возвратов и по истечении определенного промежутка времени
Недостатком какого сценария скользящей сборки является сложность определения возврата, вызвавшего сбой:
сборка после определенного числа возвратов сборка по истечении заданного промежутка времени сборка после определенного числа возвратов и по истечении определенного промежутка времени
Сценарий скользящей сборки, позволяющий гарантированно получить сборку через некоторый промежуток времени после отправки кода:
сборка после определенного числа возвратов сборка по истечении заданного промежутка времени сборка после определенного числа возвратов и по истечении определенного промежутка времени
Сценарий сборки, при котором на момент начала сборки число возвратов кода может варьироваться от одного до нескольких:
сборка после определенного числа возвратов сборка по истечении заданного промежутка времени сборка после определенного числа возвратов и по истечении определенного промежутка времени
Для определения оптимального интервала осуществления сборки ключевым параметром является:
среднее время между возвратами кода интервал времени, в котором возвраты осуществляются особенно часто отношение среднего времени между возвратами к длительности процесса сборки
Допустим сборка занимает 20 минут, а среднее время между возвратами сборки составляет 4 минуты, согласно сценарию сборки по обоим условиям:
таймаут должен быть равен 20 минутам сборка должна осуществляться после 5 возвратов таймаут должен быть равен 5 минутам
Допустим сборка занимает 15 минут, а среднее время между возвратами сборки составляет 5 минут, согласно сценарию сборки по обоим условиям:
таймаут должен быть равен 15 минутам сборка должна осуществляться после 5 возвратов таймаут должен быть равен 3 минутам
Частота сборки, позволяющая разработчикам максимально быстро получать информацию о качестве кода:
Еженедельная частота сборок оправдывает себя в случае:
длительного времени сборки (несколько дней) при наличии значительных изменений в течении часа в случае малого числа возвратов в течении недели
Для создания плановой сборки на сервере TFS необходимо
создать командную строку TFSBuild: TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> создать запланированную задачу Windows создать командную строку TFSBuild: TfsBuild create <<BuildTypeName>> <<TeamProject>> <<TeamFoundationServer>>
Для создания плановой сборки на сервере TFS необходимо
ввести сроку в пакетный файл вида: TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> создать запланированную задачу Windows ввести сроку в пакетный файл вида: TfsBuild create <<BuildTypeName>> <<<<TeamProject>> <<TeamFoundationServer>>
В качестве параметров командной строки TFSBuild для создания плановой сборки на сервере TFS необходимо указать:
имя проекта имя TFS сервера время частоты плановой сборки
Согласно сценарию работы с большими проектами:
группы разработки приложений включают в свои сборки предоставляемые группами разработки компонентов сборки группы разработки компонентов включают в свои сборки предоставляемые группами разработки приложений сборки интеграционное тестирование выполняется только для комплексной сборки всего проекта
Согласно сценарию работы с большими проектами:
группы разработки приложений включают в свои сборки предоставляемые группами разработки компонентов сборки группы разработки компонентов включают в свои сборки предоставляемые группами разработки приложений сборки тестирование компонентов выполняется для каждой сборки
Внимание ! Вопросы к тесту выложены исключительно в ознакомительных целях: количество вопросов может не совпадать с действительным, актуальность не поддерживается,- за решением теста Welcome to the cashier! При работе над большим решением, в случае возникновения проблемы с масштабируемостью решения следует:
создать главное решение для всего приложения использовать несколько файлов решений без создания главного решения распределить управление версиями по подсистемам и не создавать главного решения
При работе над большим решением, в случае возникновения проблемы с масштабируемостью решения следует:
создать главное решение для всего приложения кроме создания главного решения использовать несколько файлов решений распределить управление версиями по подсистемам и не создавать главного решения
Проблема с масштабируемостью решения проекта , включающего в себя десятки проектов решается:
распределением управления версиями по подсистемам созданием главного решения наряду с использованием нескольких файлов решений использованием нескольких файлов решений без создания главного решения
При использовании нескольких решений наличие файловых ссылок на проекты вне решений говорит:
о необходимости использования главного решения о необходимости использования сценария "понимающего" порядок сборки решений что логически компоненты независимых производителей находятся вне внутренних границ системы
При использовании нескольких решений наличие файловых ссылок на проекты вне решений означает:
что можно обойтись без главного решения что логически компоненты независимых производителей находятся во внутренних границах системы что логически компоненты независимых производителей находятся вне внутренних границ системы
При использовании нескольких решений наличие файловых ссылок на проекты вне решений означает:
что можно обойтись без главного решения что необходимо использовать сценарий "понимающий" порядок сборки решений что логически компоненты независимых производителей находятся во внутренних границах системы
Более глубокая структура ветвления:
не влияет на время переноса изменений в главную ветвь увеличивает время переноса изменений в главную ветвь сокращает время переноса изменений в главную ветвь
Для больших групп разработки характерно:
ветвление по группам ветвление по компонентам ветвление как по группам так и по компонентам
Напрямую на время переноса изменений из ветки разработки в главную ветвь проекта влияют:
стратегия слияния глубина ветвления частота внесения изменений
Перенос изменений из главной ветви в ветвь разработки и перенос изменений по расписанию характерны:
для обратной интеграции для прямой интеграции как для прямой так и для обратной интеграции ни один из вышеперечисленных вариантов
Для прямой интеграции справедливы следующие утверждения:
это перенос изменений из ветки разработки в главную ветвь это перенос изменений из главной ветви в ветвь разработки как правило перенос изменений выполняется по расписанию как правило перенос изменений инициируется событием
Для обратной интеграции справедливы следующие утверждения:
это перенос изменений из ветки разработки в главную ветвь это перенос изменений из главной ветви в ветвь разработки как правило перенос изменений выполняется по расписанию как правило перенос изменений инициируется событием
Для систем сборки в больших группах характерно:
определение периодичности слияний до определения периодичности сборки связывание с каждой ветвью своего сервера сборки в ветвях разработки используется сочетание непрерывной интеграции и плановых сборок
Для систем сборки в больших группах характерно:
определение периодичности слияний до определения периодичности сборки связывание с каждой ветвью своего сервера сборки плановые сборки используются в ветвях интеграции
Для систем сборки в больших группах характерно:
определение периодичности сборки до определения периодичности слияний связывание с каждой ветвью своего сервера сборки для ветвей интеграции не характерно использование плановых сборок
Планирование проектов осуществляется по схеме:
концептуальное описание проекта-Формулирование сценариев-Формирование набора функциональных возможностей для реализации выбранных сценариев-Формирование набора рабочих элементов-Распределение задач по областям- Создание плана работ концептуальное описание проекта-Формулирование сценариев-Формирование набора функциональных возможностей для реализации выбранных сценариев-Формирование набора рабочих элементов- Создание плана работ-Распределение задач по областям концептуальное описание проекта- Формирование набора функциональных возможностей для реализации выбранных сценариев - Формулирование сценариев -Формирование набора рабочих элементов- Создание плана работ-Распределение задач по областям
Планирование проектов осуществляется по схеме:
концептуальное описание проекта-Формулирование сценариев-Формирование набора функциональных возможностей для реализации выбранных сценариев-Формирование набора рабочих элементов- Создание плана работ-Распределение задач по областям концептуальное описание проекта-Формулирование сценариев-Формирование набора функциональных возможностей для реализации выбранных сценариев-Формирование набора рабочих элементов-Распределение задач по областям- Создание плана работ концептуальное описание проекта- Формирование набора функциональных возможностей для реализации выбранных сценариев - Формулирование сценариев -Формирование набора рабочих элементов -Распределение задач по областям- Создание плана работ
В Team Foundation Server отсутствует:
интеграция с MS Office Project интеграция с MS Office Visio ассоциированный портал проекта на основе MS Share Point
В Team Foundation Server обеспечивает:
создание ассоциированного портал проекта на основе MS Share Point интеграцию с MS Office Visio интеграцию c MS Office Excel
В шаблон MSF Agile входят следующие типы рабочих элементов:
задача рецензия требование QoS запрос на изменение
В шаблон MSF Agile входят следующие типы рабочих элементов:
задача рецензия ошибка риск
В шаблон MSF Agile входят следующие типы рабочих элементов:
риск проблема ошибка запрос на изменение
В шаблон MSF CMMI входят следующие рабочие элементы:
требование QoS проблема сценарий запрос на изменение
В шаблон MSF CMMI входят следующие рабочие элементы:
требование QoS рецензия сценарий требование
В шаблон MSF CMMI входят следующие рабочие элементы:
задача рецензия сценарий запрос на изменение
Целями использования рабочих элементов являются:
отслеживание степени удовлетворенности заказчика конечным продуктом оценка темпов продвижения к завершению кода формирование требований пользователей к приложению
Целями использования рабочих элементов являются:
отслеживание степени удовлетворенности заказчика конечным продуктом оценка темпов продвижения к завершению кода выявление дефектов в реализации функционала приложения
Целями использования рабочих элементов являются:
приоритезация задач, стоящих перед командой разработчиков оценка темпов продвижения к завершению кода выявление дефектов в реализации функционала приложения
У рабочего элемента MSF CMMI есть состояние, отсутствующее у рабочих элементов MSF Agile. Это состояние:
closed resolved proposed
В рабочем элементе MSF Agile отсутствует состояние:
active resolved proposed
К основным компонентам архитектуры шаблона процесса относятся:
Work Item Tracking надстройка шаблона процесса мастер New Team Project
К основным компонентам архитектуры шаблона процесса относятся:
Work Item Tracking надстройка шаблона процесса Groups and Permissions
К основным компонентам архитектуры шаблона процесса относятся:
Work Item Tracking Reports XML - файлы определения процессов
Компоненты, запускаемые при создании нового проекта команды являются частью:
надстройки шаблона процесса XML - файлов определения процессов мастера New Team Project
Частью какого компонента архитектуры шаблона процесса являются Reports и Groups and Permissions:
надстройки шаблона процесса XML - файлов определения процессов мастера New Team Project
Компонент архитектуры шаблона процесса, отвечающий за конфигурацию данных в определенной области шаблона:
надстройки шаблона процесса XML - файлов определения процессов мастера New Team Project
Укажите надстройки шаблона процессов:
Version Control Work Item Queries Work Item Tracking
Укажите надстройки шаблона процессов:
Classification Work Item Types Work Item Tracking
Укажите надстройки шаблона процессов:
Classification Work Item Types Reports
В стандартных шаблонах процесса не содержится:
набор типов рабочих элементов структуры классификации областей и итераций набор отчетов по - умолчанию
В стандартных шаблонах процесса не содержится:
набор групп и разрешений по - умолчанию структуры классификации областей портал команды по - умолчанию
В стандартных шаблонах процесса не содержится:
набор отчетов по - умолчанию набор групп и разрешений по - умолчанию структуры классификации итераций
Процедура настройки шаблона не включает в себя:
задание имени проекта и шаблона для его создания задание сведений о типах рабочих элементов ввод информации о портале проекта (в зависимости от включенных в шаблон надстроек)
Процедура настройки шаблона включает в себя, вне зависимоти от включенных надстроек:
задание имени проекта и шаблона для его создания задание сведений о типах рабочих элементов ввод информации о портале проекта
Для усовершенствования существующих процессов разработки больше подходит шаблон:
MSF Agile MSF CMMI
Процесс MSF Agile основан на:
методологии MSF методологии Capability Maturity Model® Integration идеях быстрой разработки
Для быстрой разработки приложения больше подходит шаблон процесса:
MSF Agile MSF CMMI
К рабочим элементам MSF Agile по - умолчанию относятся:
Report Risk Task Query
К рабочим элементам MSF Agile по - умолчанию относятся:
Bug Report Task Query
К рабочим элементам MSF Agile по - умолчанию относятся:
Bug Scenario Task Query
По умолчанию в шаблоне MSF Agile доступны следующие группы:
HelpServicesGroup Guests Project Administrators
По умолчанию в шаблоне MSF Agile доступны следующие группы:
Readers Guests Project Administrators
По умолчанию в шаблоне MSF Agile доступны следующие группы:
Readers Guests WINS Users
Оценка текущего состояния проекта и его продвижения осуществляется на основе отчетов:
о тестировании об управлении выпусками об ошибках о рабочих элементах
Оценка готовности программного обеспечения к выпуску осуществляется на основе отчетов:
о тестировании об управлении выпусками об ошибках о рабочих элементах
Оценка эффективности испытаний осуществляется на основе отчетов:
о тестировании об управлении выпусками об ошибках о рабочих элементах
Для сбора данных и составления отчетов используется:
MS Excel SQL Server Analysis Studio Team Explorer
Для создания новых отчетов используются:
MS Excel SQL Server Analysis Studio Team Explorer
Для размещения новых отчетов в SQL используются:
MS Excel Visual Studio 2005 Report Designer SQL Server 2005 Reporting Services
К серверным компонентам системы подготовки отчетов относятся:
веб - служба серверов отчетов веб - обозреватель служба Windows
К клиентским компонентам системы подготовки отчетов относятся:
БД серверов отчетов веб - обозреватель Team Explorer
К клиентским компонентам системы подготовки отчетов относятся:
веб - служба серверов отчетов Team Explorer веб - сайт диспетчера отчетов
К клиентским компонентам системы подготовки отчетов относятся:
веб - служба серверов отчетов веб - обозреватель служба Windows
К клиентским компонентам системы подготовки отчетов относятся:
БД серверов отчетов Team Explorer служба Windows
К клиентским компонентам системы подготовки отчетов относятся:
веб - сайт диспетчера отчетов веб - обозреватель Team Explorer
На уровне данных TFS:
находятся сервера сборки и прокси сервера находится Team Explorer устанавливается ряд БД для хранения рабочих элементов, версий, результатов сборок
Разделение архитектуры TFS на три уровня:
физическое логическое, все три уровня должны быть установлены отдельно логическое, все три уровня могут быть установлены на одном компьютере
На уровне приложений TFS:
находятся сервера сборки и прокси сервера находится Team Explorer станавливается ряд БД для хранения рабочих элементов, версий, результатов сборок
Сценарий развертывания, при котором для подключения к серверу каждому пользователю необходима доменная учетная запись:
односерверное развертывание в рабочей группа односерверное развертывание в Active Directory развертывание с несколькими серверами
Сценарий развертывания, поддерживающий обслуживание более 400 пользователей:
односерверное развертывание в рабочей группа односерверное развертывание в Active Directory развертывание с несколькими серверами
Сценарий развертывания, при котором для подключения к серверу каждому пользователю необходима локальная учетная запись на нём:
односерверное развертывание в рабочей группа односерверное развертывание в Active Directory развертывание с несколькими серверами
Службы Team Foundation Build Services могут быть установлены:
на уровне приложений на специальный сервер на несколько специальных серверов
При раздельном развертываниии:
уровень приложений ставится отдельно от уровня данных взаимодействие клиентского уровня с уровнем данных осуществляется посредством HTTP(s) SQL Server является частью сервера приложений
При односерверном развертывании:
уровень приложений ставится отдельно от уровня данных взаимодействие клиентского уровня с уровнем данных осуществляется посредством HTTP(s) SQL Server является частью сервера приложений
Наличие компонентов отказоустойчивости характерно для:
простой топологии TFS топологии умеренной сложности сложной топологии TFS
Топология, обеспечивающая поддержку до 400 пользователей:
простая умеренной сложности сложная
Топология, обеспечивающая поддержку от 400 до 2000 пользователей:
простая умеренной сложности сложная
Реализация стратегии восстановления на уровне данных включает в себя:
кластеризацию серверов уровня зеркалирование серверов уровня резервное оборудование и ПО
Восстановление TFS из архивов осуществляется согласно следующим сценариям:
восстановление данных односерверной установки восстановление данных раздельной установки полное восстановление односерверной архитектуры
Реализация стратегии восстановления на уровне приложений включает в себя:
переключение сервера уровня зеркалирование серверов уровня резервное оборудование и ПО
Преимущества размещения TFS в экстрасети:
поддержка встроенной аутентификации Windows удаленным пользователям не нужен доступ к домену пользователи TFS отделены от внутренней сети
Преимущества удаленного VPN подключения к TFS:
поддержка встроенной аутентификации Windows удаленным пользователям не нужен доступ к домену пользователи TFS отделены от внутренней сети
Преимущества публикации TFS посредством обратного прокси с контроллером домена в периметре:
поддержка встроенной аутентификации Windows удаленным пользователям не нужен доступ к домену пользователи TFS отделены от внутренней сети
Недостатки размещения TFS в экстрасети:
может быть недоступно для удаленных пользователей нельзя использовать TFS прокси отсутствие возможности запуска и управления сборки
Недостатки публикации TFS посредством обратного прокси:
может быть недоступно для удаленных пользователей нельзя использовать TFS прокси отсутствие возможности запуска и управления сборки
Недостатки удаленного VPN подключения к TFS
может быть недоступно для удаленных пользователей нельзя использовать TFS прокси отсутствие возможности запуска и управления сборки
TFS прокси:
необходим для обеспечения удаленного доступа позволяет сократить сетевой трафик может использоваться в качестве кэша для системы управления исходным кодом
TFS прокси:
необходим для повышения производительности удаленного филиала не требуется для обеспечения удаленного доступа может используется в качестве кэша для системы управления исходным кодом необходим
TFS прокси:
необходим для повышения производительности удаленного филиала необходим для обеспечения удаленного доступа может использоваться в качестве кэша для системы управления исходным кодом
Удаленный сервер сборки:
не должен заменять внутренний сервер сборки позволяет повысить эффективность удаленной команды увеличивает нагрузку на внутренний сервер сборки/
Удаленный сервер сборки:
не должен заменять внутренний сервер сборки увеличивает потребность в передаче по сети двоичных файлов снижает нагрузку на внутренний сервер сборки
Удаленный сервер сборки:
может заменить внутренний сервер сборки позволяет повысить эффективность удаленной команды снижает нагрузку на внутренний сервер сборки
TFS 2008:
поддерживает именованные экземпляры SQL не поддерживает SharePoint 2007 поддерживает клиентские Windows 2008
TFS 2008:
не поддерживает именованные экземпляры SQL не поддерживает SharePoint 2007 поддерживает клиентские сертификаты X.509
TFS 2008:
поддерживает клиентские Windows 2008 поддерживает SharePoint 2007 не поддерживает клиентские сертификаты X.509
TFS 2008:
поддерживает управление очередями сборок позволяет создавать триггеры для осуществления непрерывной сборки не поддерживает сборку по расписанию
TFS 2008:
позволяет создавать триггеры для осуществления непрерывной сборки упрощает процесс задания тестов, выполняемых в процессе сборки не поддерживает сборку по расписанию
TFS 2008:
не поддерживает управление очередями сборок упрощает процесс задания тестов, выполняемых в процессе сборки не поддерживает непрерывную сборку
При совместном использовании клиента TFS 2005 с TFS 2008:
невозможно поставить созданную сборку в очередь требуется повторная компиляция клиентских настроек Visual Studio tfsbuild.proj перестанет синхронизироваться
При совместном использовании клиента TFS 2008 с TFS 2005:
невозможно поставить созданную сборку в очередь требуется повторная компиляция клиентских настроек Visual Studio нельзя изменить параметры сборки
При совместном использовании клиента TFS 2008 с TFS 2005:
нельзя создать новый тип сборки не требуется повторная компиляция клиентских настроек Visual Studio нельзя изменить параметры сборки
Вы можете обратится к нам напрямую, через:
По Skype: molodoyberkut По Telegram: @MolodoyBerkut По ICQ: 657089516