Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лабораторні роботи № 6,7,8 спрямовані на:
Усі роботи повинні бути виконані з використанням мови програмування C#.
Для виконання лабораторних робіт на робочу станцію студента повинно бути встановлено наступне програмне забезпечення:
Лабораторні роботи 6-8 містять наступні теми:
6. Вивчення системи контролю версій в Team Foundation Server.
7. Дослідження роботи з робочими елементами, сценаріями, задачами й помилками.
8. Робота із запитами до робочих елементів, створення збірки.
Перед виконання лабораторної роботи студент повинен продемонструвати викладачу рівень підготовки шляхом відповіді на запитання наведенні наприкінці кожної роботи.
Мета - отримати базові знання з систем контролю версій і отримати навички, що необхідні кожному розробнику програмного забезпечення у повсякденній роботі. Дізнатися, як за допомогою команд Team Foundation Server керувати версіями програмного продукту.
Задачі
Теорія
Система контролю версій (контролю ревізій) дозволяє відстежувати модифікації файлів з пливом часу.
Використання систем контролю версій важливе тому що дозволяє :
Більшість систем контролю версій використовують ці базові принципи, хоча терміни можуть бути різними.
Репозиторій– це база даних що містить файли та папки.
Сервер – це обчислювальна машина що містить репозиторій.
Клієнт – це обчислювальна машина що підключається до сервера.
Робочий набір– це ваша локальна папка де ви можете вносити свої зміни.
Транк (Trunk ) – первинне розташування коду в репозиторії.
Основні дії та атрибути систем контролю версій:
Додаткові дії:
Team Foundation Server (TFS) містить потужну корпоративну систему контролю версій. TFS використовує базу даних Microsoft SQL Server у якості репозиторія, вона тразакційна та атомарна.
Головні особливості системи контролю версій TFS:
Методічні вказівки
Запитання для самоконтролю
Посилання: [1], [5].
Мета - вивчити основи управління процесом розробки програмного забезпечення з використанням Team Foundation Server та Microsoft Solution Framework (MSF) для Scrum. Розглянути повсякденну роботу розробника програмного забезпечення з використанням робочих елементів, задач та сценаріїв. Вивчити різні підходи до оцінки обсягу робіт. Вивчити процеси управління помилками та іх виправлення.
Задачі
Теорія
Scrumє гнучким та легким процесом для керування процесом розробки програмного забезпечення.
Це оболонка для існуючих інженерних практик та є:
Scrum може бути розглянуто як паттерн.
Scrum найбільш адаптований для невеликих команд розробників (до 10 осіб), обмежений у часі та використовує спринти від одної до чотирьох неділь. Спринт це ітерація фіксованої довжини, результатом якої є видимий та корисний продукт (функціональність).
Правила спринта:
На початку спринта команда проводить нараду для планування робіт. На нараді команда обговорює вимоги (історії та сценарії), надає сценаріям пріоритет, оцінює їх та обирає ті що будуть реалізовані протягом спринта відповідно до ємності команди.
Протягом спринта команда працює так, щоб задовольнити наступним вимогам:
Перед началом спринта:
Вимоги
Хороший набір вимог має бути визначений з кількох точок зору. Існує декілька типів вимог: бізнес-вимоги, користувацькі вимоги, функціональні та вимоги по якості обслуговування.
Бізнес-вимоги визначають те що є важливим для успіху проекту. Як правили бізнес-вимоги представляють інтереси спонсорів проекту.
Вимоги користувачів описують завдання що вони повинні мати можливість зробити користуючись продуктом.
Функціональні вимоги або функціональні характеристики – це те що розробники повинні побудувати для того щоб задовольнити інші вимоги. Функціональні вимоги зазвичай визначаються дуже докладно, щоб допомогти розробникам зрозуміти що саме вони повинні розробляти.
Вимоги до якості обслуговування визначають договірні чи нефункціональні вимоги до системи. Зазвичай вони не представляють проблем конкретного користувача, скоріше це вимоги до продуктивності, масштабованості, безпеки системи та стандартів.
Сценарії використання та вимоги
Сценарії використання та вимоги це не одне й теж саме. Сценарії використання це UML (Unified Modeling Language) моделі, що описують набір кроків користувача для виконання конкретної задачі. Вимоги визначають що має бути розроблено для того щоб задовольнити користувача. Разом вони забезпечують якісну картину того як користувач бачить систему.
Для того щоб правильно та ефективно спланувати спринт всі сценарії використання повинні бути оцінені, щоб розподілити робоче навантаження між усіма членами команди. Оцінка визначає скільки приблизно зусиль треба витратити для того щоб задовольнити конкретним вимогам. Існує декілька заходів та методів оцінки. Послідовний підхід описує кількість рядків програмного коду, чи функцій. В гнучких методах розробки використовують бали сценаріїв (storypoint) та максимально продуктивні людино-дні (perfectmanday).
Оцінка в максимально продуктивних людино-днях визначає – як довго треба працювати якщо:
Бал сценарія це ‘розмір’ завдання, що формується під впливом того наскільки воно важке та трудоємне.
Відстеження та виправлення помилок це процес управління дефектами програмного забезпечення.
Дефекти можуть бути знайдені та зареєстровані в системі контролю любим із членів команди.
Дефект повинен бути якомога детально та повно описаний для того щоб команда могла зрозуміти його істочник, причини та вплив на систему.
Дефекти потім призначаються відповідному члену команди для виправлення. У рамках призначення розглядається також поточне навантаження на потенційного робітника. Коли призначення зроблено задача на виправлення дефекту додається в робочу чергу члена команди.
На наступному кроці дефект усувають (він може бути виправлений, відкладений або може бути обрано рішення не виправляти його взагалі) та закривають.
Розробка програмного забезпечення може бути більш легкою, команди можуть працювати більш ефективно якщо використовуються артифакти що запропоновано в шаблонах процесів Team Foundation Server. Team Foundation Server містить декілька шаблонів готових до використання в залежності від конфігурації процесів та потреб команди та проета.Ці шаблони: MSF for CMMI, MSF for Agile та MSF for Scrum.
Agile шаблони містять наступні артифакти: робочі елементи, звіти, робочі книги та приладні дошки. Команди можуть використовувати робочі елементи для відстеження робочої інформації, аналізу прогреса, та приймати відповідні рішення.
Шаблон Agile визначає наступні типи робочих елементів:
Користувацькі сценарії. Команда створює користувацькі сценарії для опису можливостей, функцій та вимог що треба реалізувати. Користувацький сценарій описує цілі замовника на загальному рівні та є фундаментальним елементом етапу планування, тому що він допомагає команді оцінювати, визначати пріорітет, визначати, планувати та верифікувати роботу що відноситься до кожного користувацького сценарію.
Задачі. Команда визначає задачі для відстеження роботи що потрібно виконати для реалізації користувацького сценарія, або інших напрямків роботи що визначені для проекту. Задача повинна представляти невеликий об’єм роботи що може бути виконано протягом одного-двух днів.Більш великі задачі можуть бути розділено на підзадачі. Шляхом відстеження робочого часу для кожної із задач, команда отримує чітку картину стану роботи та прогресу розробки.
Сценарії тестування. Використовуються командою для визначення тестів що потрібно виконати для підтримки користувацьких сценаріїв. Можна визначити тести що виконуються вручну, вказавши послідовність дій та перевірок, або реалізувати автоматичні тести.
Спільні етапи. Необхідні команді для впорядкування тестових сценаріїв та підвищення спроможності їх обслуговування. В спільних етапах можна визначити послідовність дій та перевірок для повторного використання в тестових сценаріях. Більшість тестів можуть містити туж саму послідовність дій, користуючись спільними етапами команда взмозі використовувати ії у множині тестових сценаріїв (наприклад аутентифікація користувача в системі може бути реалізована як спільній етап).
Дефекти. Команда відстежує помилки в програмному коді та може реєструвати їх як робочі елементи типу дефект. Реєструючи дефект ви взмозі точно звітувати о подробицях помилки та допомогти команді зрозуміти ії причини та вплив на систему. При реєстрації дефекту необхідно описати перелік дій що привели до небажаної поведінки системи, це допоможе іншим відтворити дефект пізніше. Результати тестування повинні чітко вказувати на проблему. Чіткість а повнота опису часто впливає на ймовірність того, що помилку буде виправлено.
Проблеми. Ви можете визначити відомі або потенційні проблеми, перешкоди чи ризики для вашого проекту реєструючи робочий елемент «Проблема» в Team Foundation Server. Якщо необхідні конкретні дії, проблема може транслюватись у одну чи декілька задач що потрібно виконати для іх усунення. Наприклад, технічна проблема чи невизначеність може транслюватись в задачі по створенню архітектурного прототипу. Команди повинні завжди закликати своїх членів до пошука потенційних проблем та переконатися що вони надають якомога більше інформації о проблемах що можуть затримати прогрес команди.
Методичні вказівки
Питання для самоконтролю
Посилання: [1]; [2]; [3]; [4].
Мета - дізнатися як працювати з запитами до бази робочих елементів, як створювати власні запити. Вивчити основи автоматизованих збірок та навчитись створювати та кофігурувати збіркі.
Задачі
Теорія
Робочий елемент – це запис у базі даних що створюються в Team Foundation Server для фіксації опису задачі, відповідальної особи, пріоритету та стану прогресу. За рахунок визначення індивідуальних робочих елементів та їх зберігання у загальній базі даних та складі метрик, команда має можливість відповісти на питання про стан проекту по мірі їх виникнення. Робочі елементи, зв’язки між ними та файли додатків зберігаються в базі даних для відстеження їх стану та змін що вносяться. (Рис 1).
Рис
Для відстеження статусу робочого елементу, прогресу ітерації чи реліза продукта, ви можете визначити та виконувати запити до робочих елементів. В Visual Studio Team Explorer ви можете знайти дві різні папки для зберігання запитів до бази даних робочих елементів: Командні Запити та Мої Запити. Папка Командні Запити містить набір заздалегідь визначених запитів що є спільними для всієї команди розробки. Створіть новий запит в папці Командні Запити якщо ви бажаєте щоб він був доступний для всієї команди. Папка Мої Запити призначена для зберігання ваших персональних запитів та не містить нічого за замовченням. Для того щоб створити спільний чи персональний запит ви можете використовувати наступний робочий процес(Рис 2).
Рис
Використовуйте запити для пошуку робочого елемента на основі інформації що зберігається в базі даних. Простий запит може шукати робочі елементи що містять певне значення в одному полі форми, наприклад усі робочі елементи що назначені вам на виконання. Більш складні запити можуть виконувати пошук по декільком полям форми робочого елемента. Для створення запиту необхідно користуватись умовами для поліпшення пошукових результатів.
Оператор запиту використовується в умові для створення запиту до бази робочих елементів. Кожна умова запиту складається з імені поля, оператору запита та значення.
Таблиця 1 містить перелік операторів запиту що доступні в системі відстеження робочих елементів Team Foundation Server.
Таблиця
|
Оператор запиту |
Опис |
Відповідні типи полей |
|
= |
Вертає робочий елемент якщо значення поля відповідає заданому. |
Число, Текст, Дата, Дерево |
|
<> |
Вертає робочий елемент якщо значення поля не відповідає заданому. |
Число, Текст, Дата, Дерево |
|
> |
Вертає робочий елемент якщо значення поля білше ніж задане. |
Число, Текст, Дата, Дерево |
|
< |
Вертає робочий елемент якщо значення поля менше ніж задане. |
Число, Текст, Дата, Дерево |
|
>= |
Вертає робочий елемент якщо значення поля більше чи равно заданому. |
Число, Текст, Дата, Дерево |
|
<= |
Вертає робочий елемент якщо значення поля меньше чи равно заданому |
Число, Текст, Дата, Дерево |
|
Contains |
Вертає робочий елемент якщо значення поля містить заданий текст |
Текст |
|
Does Not Contain |
Вертає робочий елемент якщо значення поля не містить заданий текст |
Текст |
|
In |
Вертає робочий елемент якщо значення поля містить будь-яке значення із заданого набору. Наприклад, порівняння поля ID з набором значень 100, 101, 102 поверне робочі елементи 100, 101, та 102. |
Число, Текст, Дата |
|
Was Ever |
Виконує пошук по історії поля. Вертає робочий елемент якщо будь-яке історичне значення поля співпадає із заданим значенням. |
Текст, Дата |
|
Under |
Виконує пошук по ієрархії та вертає робочі елементи що є наслідниками вузла зазначеного параметром. |
Дерево |
|
Not Under |
Виконує пошук по ієрархії та вертає робочі елементи що не є наслідниками вузла зазначеного параметром. |
Дерево |
Змінні дозволяють генерувати параметри, що дає змогу створювати динамічні запити, що виконують пошук по поточній даті, користувачу чи проекту.
Таблиця 2 містить перелік змінних запиту що досупні для використання в системі відстеження робочих елементів Team Foundation Server.
Таблиця
|
Змінна запиту |
Результат |
|
@Me |
Використовуйте змінну @Me для автоматичного пошуку для поточного користувача, якщо поле містить ім’я користувача. Наприклад, якщо ви хочете знайти усі робочі елементи що вами відкриті потрібно встановити поле Activated By, з оператором =, та значення @Me. |
|
@Project |
Використовуйте змінну @Project для будь-якого поля що має посилання на проект для пошуку по поточному проекту. Наприклад, якщо ви хочете знайти перелік усіх активних робочих елементів для обраного проекту необхідно обрати поле Team Project, оператор =, та значення @Project. |
|
@Today |
Використовуйте змінну @Today для будь якого поля типу Дата, для пошуку по поточній даті. Запит буде використовувати поточну дату в момент його виконання. Ви також можете модифікувати змінну @Today додаючи чи віднімаючи дні. Наприклад,для пошуку усіх робочих елементів що було активовано за останні 7 діб, потрібно встановити поле Activated Date, оператор>=, та значення @Today - 7. |
Збірка проектів з використанням Team Foundation Server
Організації та команди потребують повторюваний та надійний метод для створення збірок, доступних громадськості на регулярній основі. Процеси життєвого циклу розробки програмного забезпечення еволюціонують с плином часу. Команди розробки зрозуміли важливість наявності періодичних збірок продуктів. Спочатку усе починалося з недільних збірок. Потім графік став більш щільним коли було запропоновано практику нічних збірок та навіть більш щільним з введенням погодинних графіків збірки продуктів. Коли переваги частих збірок стали очевидними для організацій, вони захотіли робити це якомога частіше. Отже зараз ми маємо безперервну інтеграцію. Але нічні збірки все ще дуже популярні тому що команди покладаються на них для отримання формальних, надійних збірок.
Безперервна інтеграція – це процес генерації збірки в той самий момент як програміст реєструє зміни коду в системі контролю версій.
Team Foundation Build пропонує функціональність для створення лабораторії збірки, та є частиною Visual Studio Team Foundation Server. Користуючись Team Foundation Build, ви маєте можливість синхронізувати похідний код, компілювати застосування, виконувати необхідні юніт тести, аналіз коду та публікувати звіти про всі ці дії. Дані про збірку зберігаються в базі даних для історії та звітів. Team Foundation Build працює з іншими інструментами Team System протягом процесу збірки, в тому числі з системою контролю версій, базою даних робочих елементів, та інструментами тестування.
Team Foundation Build розроблено для використання с Team Foundation в розподіленому середовищі як показано на рис 3.
Рис
Team Foundation Build взаємодіє с Team Explorer. Team Foundation Build розглядає визначення збірок як частину командного проекту. Визначення збірок можна побачити користуючись Team Explorer в папці Team Builds. Такі операції як запуск збірки, створення нової збірки можна виконати користуючись панелью Team Explorer в Visual Studio. Різні визначення збірок можуть існувати в папці Team Builds для кожного командного проекту.
Для створення простішого визначення збірки користуйтесь наведеними нижче кроками:
Методичні вказівки
Питання для самоконтроля
Посилання: [1].