Шляхом побудови дерева виводу.
+23.5.Розгляньте наступні рядки паралельного програмного коду, знайдіть та поясніть помилку, перепишіть код для виправлення помилки:
int a = 0;
#pragma omp parallel for num_threads(4)
for (int i = 0; i < 100000; i++) {
a++;}
--------
Оскільки всі потоки пишуть в одну і ту ж область пам'яті і читають з неї одночасно, значення змінної після цього циклу є непередбачуваним. Щоб убезпечити цю операцію, її потрібно помістити в критичну секцію, або (оскільки в даному прикладі операція є елементарною) використовувати директиву "#pragma omp atomic". Другий варіант є кращим, оскільки призводить до більш швидкого коду:
int a = 0;
#pragma omp parallel for num_threads(4)
for (int i = 0; i < 100000; i++)
{
#pragma omp atomic
a++;
}
Якщо ж тип операції не дозволяє використовувати директиву "#pragma omp atomic", можна скористатися критичними секціями або блокуваннями. Критичні секції є більш кращим рішенням, так як вони працюють швидше:
int a = 0;
#pragma omp parallel for num_threads(4)
for (int i = 0; i < 100000; i++)
{
#pragma omp critical
{
...
}
}
ВАРІАНТ № 24
24.1.Інтеграційне і системне тестування програмного забезпечення.
24.2.Процеси утилізації програмного забезпечення.
24.3.Класифікація граматик по виду правил. КС - граматики та їх властивості.
24.4.Підготовте приклад в якому розкривається місце впровадження програмного забезпечення в управлінні конфігураціями програмного забезпечення.
+24.5.Описати послідовність дій для налаштування планової збірки у TFS
+24.1.Інтеграційне і системне тестування програмного забезпечення.
Інтеграційне тестування (integration testing) призначено для перевірки правильності взаємодії модулів деякого набору один з одним. При цьому перевіряється, що в ході спільної роботи модулі обмінюються даними й викликами операцій, не порушуючи взаємних обмежень на таку взаємодію, наприклад, предумов викликуваних операцій. Інтеграційне тестування також використовується при налагодженні, але на більше пізньому етапі розробки
Системне тестування (system testing) призначено для перевірки правильності роботи системи в цілому, її здатності правильно вирішувати поставлені користувачами задачі в різних ситуаціях.
Системне тестування виконується через зовнішні інтерфейси ПЗ та тісно пов'язане з тестуванням користувацького інтерфейсу (або через користувацький інтерфейс), проведеним за допомогою імітації дій користувачів над елементами цього інтерфейсу. Окремими випадками цього виду тестування є тестування графічного користувацького інтерфейсу (Graphical User Interface, GUI) і користувацького інтерфейсу Web-додатків (WebUI).
Якщо інтеграційне та модульне тестування найчастіше проводять, впливаючи на компоненти системи за допомогою операцій надаваного ними програмного інтерфейсу (API), то на системному рівні без використання користувацького інтерфейсу не обійтися, хоча тестування через API у цьому випадку також цілком можливо.
Основний недолік тестування полягає в тому, що проводити його можна, тільки коли елемент програми, що перевіряється вже розроблений. Знизити вплив цього обмеження можна, підготовляючи тести (а це - найбільш трудомістка частина тестування) на основі вимог заздалегідь, коли вихідного коду ще немає. Підхід випереджальної розробки тестів з успіхом використовується, наприклад, у рамках XP.
+24.2.Процеси утилізації програмного забезпечення.
У життєвому циклі ПЗ процеси, які пов'язані з утилізацією програмного забезпечення введені у фазу ліквідації (рис. 2):
Рис. 2. Склад фази ліквідації
Утилізація включає три процеси - повторне використання, відновлення та переробку успадкованого програмного забезпечення.
Всі неутилізовані компоненти знищуються.
Процеси утилізації |
Характеристика процесів |
Методи інженерії пз |
Засоби інженерії пз |
Повторне використання |
Створення компонентів, зберігання і застосування компонентів |
Класифікація, зберігання, пошук |
Середовище програмування, моніторингові системи, експертні системи |
Відновлення |
Аналіз програмного забезпечення, перетворення програмного забезпечення на одному рівні |
Синтаксичний, семантичний аналіз, методи прямого і зворотного інженерії |
Аналізатори перетворювачі абстракторі екстрактори |
Переробка |
Перетворення програмного забезпечення на різних рівнях подання. Аналіз програмного забезпечення |
Синтаксичний і семантичний аналіз, методи реверсивної інженерії |
CASE, перетворювачі, абстрактор, екстрактор. |
Реалізація процесів утилізації призвела до появи зворотного (реверсивної) інженерії програмного забезпечення, з'єднання якої з прямою інженерією дало реінженерію і дозволило в екологічному аспекті розглядати розробку і супровід програмного забезпечення як його кругообіг.
Рис. 3. Кругообіг ПЗ
+---24.3.Класифікація граматик по виду правил. КС - граматики та їх властивості. ВЛАААААААСТИВООООСТИ!!!!
Типы грамматик
По иерархии Хомского, грамматики делятся на 4 типа, каждый последующий является более ограниченным подмножеством предыдущего (но и легче поддающимся анализу):
тип 0. неограниченные грамматики — возможны любые правила ( типу 0 по классификации Хомского относятся неограниченные грамматики (также известные как грамматики с фразовой структурой). Это — все без исключения формальные грамматики. Практического применения в силу своей сложности такие грамматики не имеют)
тип 1. контекстно-зависимые грамматики — левая часть может содержать один нетерминал, окруженный «контекстом» (последовательности символов, в том же виде присутствующие в правой части); сам нетерминал заменяется непустой последовательностью символов в правой части. (К этому типу относятся неукорачивающие грамматики и контекстно-зависимые грамматики — левая часть может содержать один нетерминал, окруженный «контекстом» (последовательности символов, в том же виде присутствующие в правой части); сам нетерминал заменяется непустой последовательностью символов в правой части. Могут использоваться при анализе текстов на естественных языках, однако при построении компиляторов практически не используются в силу своей сложности)
тип 2. контекстно-свободные грамматики — левая часть состоит из одного нетерминала. К этому типу относятся контекстно-свободные грамматики. То есть грамматика допускает появление в левой части правила только нетерминального символа.
КС-грамматики широко применяются для описания синтаксиса компьютерных языков.
тип 3. регулярные грамматики — более простые, эквивалентны конечным автоматам.
(К третьему типу относятся регулярные грамматики — самые простые из формальных грамматик. Регулярные грамматики применяются для описания простейших конструкций: идентификаторов, строк, констант, а также языков ассемблера, командных процессоров и др.)
Кроме того, выделяют:
Неукорачивающиеся грамматики.
Линейные грамматики.
Контекстно-свободная грамматика (КС-грамматика, бесконтекстная грамматика) — частный случай формальной грамматики (тип 2 по иерархии Хомского), у которой левые части всех продукций являются одиночными нетерминалами (объектами, обозначающими какую-либо сущность языка (например: формула, арифметическое выражение, команда) и не имеющими конкретного символьного значения). Смысл термина «контекстно-свободная» заключается в том, что возможность применить продукцию к нетерминалу, в отличие от общего случая неограниченной грамматики Хомского, не зависит от контекста этого нетерминала.
Язык, который может быть задан КС-грамматикой, называется контекстно-свободным языком или КС-языком.
Следует заметить, что по сути КС-грамматика — другая форма БНФ.
Типы КС грамматик:
LL-грамматика
LALR-грамматика
LR-грамматика
SLR-грамматика
+***24.4.Підготовте приклад в якому розкривається місце впровадження програмного забезпечення в управлінні конфігураціями програмного забезпечення.
Управління конфігурацією програмного забезпечення, або конфігураційне управління, розглядається як діяльність, яка виконується на протязі всіх етапів ЖЦПЗ і здійснює ідентифікацію, опис (документування) і контроль всіх елементів програмного виробу і всіх модифікацій, що появлятися в процесі його експлуатації.
Управління конфігурацією – одночасно і технічна, і управлінська діяльність, направлена на підтримку високої якості виробу і ретельний контроль всіх вироблюваних змін. Конфігураційне управління грає особливу роль в організації супроводу програмної продукції.
Зміни відбуваються як під час розробки програмної продукції, так і під час її експлуатації. Якщо ці зміни не аналізувати всебічно до їх реалізації, виникне плутанина, для мінімізації якій і було призначено конфігураційне управління.
Конфігурація програмного виробу утворюється з сукупності взаємозв’язаних об’єктів, які називають елементами конфігурації. До елементів конфігурації відносяться:
Комп’ютерні програми (у формі вихідного або виконуваного коду);
Документи, які описують програми (з орієнтацією або на користувача, або на обслуговуючий персонал);
Структури даних, що містяться або в програмах, або зовні них.
Можливий набір основних елементів, що включаються в сферу конфігураційного управління і визначаючих конфігурацію програмного виробу, охоплює:
Вимоги користувача.
Специфікацію вимог до програмного виробу.
Технічне завдання на розробку програмного виробу.
План проектування програмного виробу.
Попереднє керівництво користувача.
Специфікацію проекту (опис архітектурного проекту, проекту даних, проектів окремих модулів).
Документовані лістингу вихідних кодів.
Матеріали тестування: (план і процедура тестування, тестові набори і результати тестування).
Операційне керівництво і керівництво по введенню в дію.
Робочі програми (виконувані модулі і модулі зв’язків).
Опис бази даних: (схема бази і структури файлів, первинне наповнення).
Документи по супроводу програмного виробу.
Стандарти і процедури, що визначають порядок виконання робіт.
Під конфігураційний контроль поміщають програмні засоби, що також додатково використовуються: конкретні версії редакторів, компіляторів, CASE-засобу і т.п. Оскільки ці засоби використовуються для створення різної документації і вихідного кодів, тому вони повинні бути доступними, коли з’являється необхідність внесення змін. На практиці конфігураційні елементи каталогізуються в базі даних проекту.
У міру просування розробки програмного виробу росте число елементів конфігурації, оскільки кожний елемент у свою чергу породжує інші елементи.
При створенні виробу зміни відбуваються в процесі роботи постійно, у міру накопичення розробниками досвіду і інформації.
Управління конфігурацією програмного виробу, таким чином, дисципліна використання адміністративного і технічного керівництва і нагляду з метою:
Ідентифікації і документування фізичних і функціональних характеристик елементів конфігурації;
Контролю за зміною цих характеристик;
Реєстрації, обробки і документування змін і встановлення статусу реалізації;
Перевірки узгодженості проведених дій зі встановленими вимогами.
Особливу трудність для супроводу представляють програмні вироби складної структури, що мають численних користувачів. Для оптимальної організації робіт по внесенню змін застосовується конфігураційне управління, що базується на:
Ревізійному контролі;
Ідентифікаційному контролі;
Управлінні розповсюдженням.
Ревізійний контроль пов’язаний з чіткою класифікацією всіх компонентів програмного виробу і з контролем за їх змінами. Класифікація використовує для програмного виробу такі поняття, як виріб, варіант, версія, редакція.
Вироби використовуються для отримання можливостей, що різняться між собою, варіанти допускають різні умови роботи, версії забезпечують різні властивості, а редакції забезпечують різну міру коректності. Таким чином, версії, відрізняючись деякими властивостями, зберігають всі основні функції виробу і сумісні з попередніми версіями цього виробу. Нова редакція частіше за все пов'язана з усуненням знайдених помилок або покращенням експлуатаційних характеристик. По кожній зміні, що вноситься, необхідно приймати рішення про те, до якого результату приведе дана зміна, для чого заздалегідь проводиться оцінка того, які зміни і в яких компонентах повинні бути проведені. Прийняття рішення базується на заздалегідь складених матрицях впливів і таблицях прийняття рішень, що дозволяють достатньо надійно визначати міру впливу можливих змін, що вносяться у виріб. Зміни, пов'язані із створенням нового виробу або варіанту, вимагають нового проектування. Нові вироби і варіанти не замінюють старі; нові версії і редакції використовуються замість колишніх.
Друга функція ревізійного контролю – контроль за змінами. Кожна зміна породжує послідовність змін, які повинні бути внесені в інші компоненти і документацію. З цією метою складаються матриці впливу, де вказується, які компоненти виробу вимагають перегляду при створенні нової редакції, версії і т.д. Так для створення нового виробу потрібна розробка нових документів і нового керівництва, а для нової версії – лише перегляд деяких документів.
В складних виробах, побудованих за модульним принципом, звичайно створюється база даних програмного виробу, в якій кожний компонент виробу повинен мати унікальний ідентифікатор. Ідентифікаційний контроль служить для присвоєння всім компонентам ідентифікаційних кодів. Оскільки система компонентів утворює ієрархічну багаторівневу систему, ідентифікація будується на основі послідовного коду. Окрім ідентифікаційного коду, кожний компонент забезпечується набором кодів, що характеризують номер варіанту, версії, редакції.
Третя складова конфігураційного управління – управління розповсюдженням, яке гарантує виборчий розподіл матеріалів – повідомлень про внесені зміни користувачів. При цьому ведеться облік користувачів, списки розсилки матеріалів. Наявність стрункої і чіткої системи ідентифікації спрощує роботу і дозволяє автоматизувати процеси інформаційного обслуговування користувачів.
+24.5.Описати послідовність дій для налаштування планової збірки у TFS
Крок 1 - створення і тестування збірки.
Крок 2 - створення команди для запуску TFSBuild.
Крок 3 - тестування команди для запуску TFSBuild.
Крок 4 - створення пакетного файлу.
Крок 5 - тестування пакетного файлу.
Крок 6 - додавання планової задачі.
Крок 7 - тестування планової задачі.
---------------------- рус.
Порядок операций
Шаг 1 — создание и тестирование сборки.
Шаг 2 — создание команды для запуска TFSBuild.
Шаг 3 — тестирование команды для запуска TFSBuild.
Шаг 4 — создание пакетного файла.
Шаг 5 — тестирование пакетного файла.
Шаг 6 — добавление плановой задачи.
Шаг 7 — тестирование плановой задачи.
.
Шаг 1 — создание и тестирование сборки
На начальном этапе мы создадим тестовую сборку и проверим возможность ее выполнения из Visual Studio. Если сборку выполнить не удается, перед переходом к следующему этапу необходимо исправить в ней ошибки.
Создайте для тестирования сценария сборки
проект Microsoft Windows Forms.
2. Убедитесь, что сборка проекта выполняется правильно.
3. Верните проект в систему управления исходным кодом.
4. Создайте сценарий командной сборки:
а. В Team Explorer щелкните правой кнопкой Team Builds и выберите New Team Build Type.
б. Заполните страницы мастера Team Build Type Creation Wizard.
5. Проверьте работоспособность сценария командной сборки:
а. В Team Explorer щелкните правой кнопкой созданный тип сценария командной сборки.
б. В контекстном меню выберите команду Build Team Project <Имя ва-шего сценария сборки>.в. Убедитесь, что тип выбран правильно, и щелкните Build.
6. Просмотрите результаты сборки и убедитесь, что в процессе
сборки не возникло ошибок.
Шаг 2 — создание команды для запуска TFSBuild
Сформируем команду для утилиты TFSBuild, по которой будет запускаться сборка.
1. Чтобы начать сборку, в утилиту командной строки TFSBuild необходимо
передать ряд параметров:
Team Foundation Server— URL сервера TFS, куда возвращаются из-менения в собираемых решениях.
Team Project — имя командного проекта, сборка которого выполняется.
Build Type — тип сборки, созданный на шаге 1.
Build Machine — имя сервера, который будет использоваться для сбор-ки проекта. Это необязательный параметр; по умолчанию использует ся сервер, заданный в типе сборки.
Build Directory — путь к папке, в которой выполняется сборка. Это необязательный параметр; по умолчанию используется путь, задан-ный в типе сборки.
2. Создайте следующую команду для выполнения сборки:
TfsBuild start <TFS-сервер> <КомандныйПроект> <ИмяТипаСборки>
Шаг 3 — тестирование команды для запуска TFSBuild
Проверим правильность выполнения команды TFSBuild.
1. Откройте окно командной строки Visual Studio.
2. Введите команду, созданную на шаге 2.
3. Просмотрите полученный результат, чтобы убедиться в отсутствии ошибок и успешности выполнения сборки.
Шаг 4 — создание пакетного файла
Для планирования сборок удобно использовать пакетный файл.
1. Откройте Блокнот (Notepad) и введите следующую команду:
“C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild”
start <TFS-сервер> <КомандныйПроект> <ИмяТипаСборки>
2. Сохраните файл с расширением .bat, например, batchbuild.bat.
3. Поместите файл в папку сборки в системе управления исходным кодом TFS, например, Main\Scripts.
Шаг 5 — тестирование пакетного файла
Проверим работу пакетного файла.
1. Откройте окно командной строки Windows.
2. Введите имя пакетного файла.
3. Убедитесь, что сборка выполняется без ошибок.
Шаг 6 — добавление плановой задачи
На данном этапе вы добавите задачу для регулярного запуска сборки.
1. Откройте панель управления.
2. Щелкните дважды значок Назначенные задания (Scheduled Tasks), за-тем щелкните Добавить задание (Add Scheduled Tasks).
3. На первой странице Мастера планирования заданий (Scheduled Task Wizard) щелкните Далее (Next).
4. Щелкните Обзор (Browse) и выберите пакетный файл, созданный на шаге 4. Затем щелкните Далее (Next).
5. Введите имя задачи и выберите частоту сборки, например, Ежедневно (Daily). Затем щелкните Далее (Next).
6. Задайте Время начала (Start time) и Дату начала (Start date). Щелкните Далее (Next).
7. введите имя и пароль учетной записи с разрешением Start a buildи щелкните Далее (Next).
8. Щелкните Готово (Finish).
Шаг 7 — тестирование плановой задачи
Убедитесь, что сборка выполняется правильно и в заданное время.
1. Дождитесь момента, когда должна быть выполнена плановая задача, или откройте панель управления, дважды щелкните значок Назначенные за-дания (Scheduled Tasks), щелкните правой кнопкой свою плановую задачу и выберите команду Запустить (Run).
2. Откроется окно командной строки, и начнется выполнение сборки.
3. Если вы в момент выполнения задачи не имеете доступа к компьютеру, на котором выполняется сборка, ее результаты можно проверить позже:
а. В Team Explorer щелкните дважды All Build Types.
б. Просмотрите список сборок и проверьте, соответствует ли время их выполнения заданному графику.
ВАРІАНТ № 25
Шаблон процесу MSF Agile
Які нормативно-технічні документи застосовуються при регламентуванні дій, які пов’язані з впровадженням і експлуатацією програмного забезпечення.
Сценарії випуску. Призначення
Побудувати графи арифметичних виразів. Перетворити арифметичні вирази в зворотний польський запис
a + b / c – d (a + b) / c – d (a + b) / (c – d)
Наведіть приклад, та поясніть, конструкції програмного забезпечення, яка використовується в безвідходному та ресурсозберігаючому виробництві програмного забезпечення.
+25.1.Шаблон процесу MSF Agile
MSF for Agile Software Development - простий шаблон для невеликих або неформальних проектів з розробки ПЗ. Він грунтується на сце-наріях і діях за обставинами. Орієнтований на конкретний проект і його виконавців. У шаблоні MSF Agile передбачений стандартний набір робочих елементів з завданнями, достатніми для початку процесу розробки-ки ПЗ. В цьому шаблоні є такі типи робочих елементів:
Сценарій (scenario) Використовується для представлення взаємодії користувача з додатком. Описує конкретні кроки, необхід-мі для досягнення мети. Сценарії мають бути конкретними, пос-Кольку можливих способів дії може бути декілька.
Задача (task) Використовується для представлення блоку роботи. У каж-дой ролі свої вимоги до завдань. Наприклад, розробник використовує для розподілу робіт завдання розробки.
Вимога QoS (Quality of Service requirement) документуються є характеристики системи, наприклад, продуктивність, навантаження, доступ-ність, стійкість до нештатних умовам експлуатації, спеціальні можливості і зручність обслуговування.
Помилка (bug) Використовується для інформування про потенційну проблему в системі.
Ризик (risk) Використовується для виявлення та управління ризиками в проекті.
-25.2.Які нормативно-технічні документи застосовуються при регламентуванні дій, які пов’язані з впровадженням і експлуатацією програмного забезпечення.
+25.3.Сценарії випуску. Призначення
Вибирайте сценарії рішення, спираючись на ступінь їх відповідності конк-ретних ситуації. Якщо ви сумніваєтеся, використовуйте найпростіший з воз-мужніх сценаріїв - планову збірку - і ускладнюйте його тільки при необ-хідності. Нижче наведено кілька типових сценарії ко-мандного зборок:
Щоденна збірка Використовується в більшості команд для переді-ставления тестувальникам та іншим споживачам узгоджених двоіч-них файлів.
Щоденна збірка і безперервна інтеграція У деяких командах для оперативного надання розробникам інформації про качест-ве коду використовуються збірки з безперервною інтеграцією - при кожному поверненні вихідного коду. Система безперервної інтеграції в чистому вигляді цілком підходить для невеликих команд розробників, а ось круп-ниє команди з частим поверненням вихідного коду і тривалої складанням ризикують перевантажити сервер збірки. Якщо це трапилося, попро-буйте використовувати ковзаючу збірку (rolling build). Зборки при цьому створюються не так часто, але і час між поверненням коду та отриманням результату зростає незначно.
Кілька лабораторій збірки, в кожній з яких використовуються щоденні збірки і безперервна інтеграція У дуже великих командах для підвищення якості та своєчасності складання необхідні більш складні рішення. Для скорочення кількості збоїв можна ис-користувати повернення коду з контролем якості, відхиляючи ненадійний код, перш ніж він потрапить в дерево. Команди з підрозділами можуть використовувати кілька серверів збірки (по одному для кожного подрузі-ділення), щоб забезпечити концентрацію кожної групи на виконан-ванні певного завдання. Наприклад, один підрозділ створює збірки інтеграції, інше - збірки розробки.
+25.4.Побудувати графи арифметичних виразів. Перетворити арифметичні вирази в зворотний польський запис
a + b / c – d (a + b) / c – d (a + b) / (c – d)
оригінал: a + b / c – d зворотній польський запис: a b c/ + d-
оригінал: (a + b) / c – d зворотній польський запис: a b + c/ d-
оригінал: (a + b) / (c – d) зворотній польський запис: a b + cd- /
+25.5. Наведіть приклад, та поясніть, конструкції програмного забезпечення, яка використовується в безвідходному та ресурсозберігаючому виробництві програмного забезпечення.
Першою конструкцією була підпрограма, яку розглядали як засіб скорочення тексту програми. Гнучкість конструкції забезпечувала параметризація. Незабаром погляд на підпрограму почав змінюватися, і її стали розглядати, як засіб структурної організації програм. Пристосування програми до очікуваних змін постановки задачі або супроводу зводилося до заміни тіла підпрограм або до зміни значень деяких фактичних параметрів у зверненні до підпрограм.
Пізніше, слідуючи прагненню поліпшити конструкцію для реалізації абстрактних типів даних були створені модуль і клас.
ВАРІАНТ № 26
26.1.Синтаксичний блок. Призначення. Методи синтаксичного аналізу.
26.2.Завдання управління проектами по розробці ПЗ
26.3.Моделювання екосистем програмного забезпечення.
26.4.Підготовте приклад програмного забезпечення на основі котрого можливо перерахувати та розкрити призначення моделей, які застосуються при впровадженні програмного забезпечення.
26.5.Розгляньте наступні рядки 64-бітного програмного коду, знайдіть та поясніть помилку, перепишіть код для виправлення помилки:
size_t Count = BigValue;
for (unsigned Index = 0; Index != Count; Index++)
{ ... }
+26.1.Синтаксичний блок. Призначення. Методи синтаксичного аналізу.
Блок синтаксичного контролю за допомогою синтаксичних таблиць перевіряє коректність синтаксису Алгол-програми. Інформація про виявлені помилки видається на друк. Блок виділення понять переводить програму з внутрішнього мови на проміжний, в якому немає рекурсивно-сті, властивої мови Алгол-60. Переклад виконується за допомогою таблиць. У процесі перекладу з окремих букв і цифр збираються ідентифікатори, а числа переводяться в двійкову систему.Інформація про неописаних ідентифікаторах видається на друк.
Синтаксичний розбір (розпізнавання) є початковим етапом синтаксичного аналізу. Саме при його виконанні здійснюється підтвердження того, що вхідний ланцюжок символів є програмою, а окремі підланцюжки складають синтаксично правильні конструкції у цій програмі. Слідом за розпізнаванням окремих підланцюжків здійснюється аналіз їх семантичної коректності на основі накопиченої інформації. Далі проводиться додавання нових елементів у проміжне представлення програми.
Виділяються два основних методи синтаксичного розбору:
спадний розбір;
висхідний розбір
Крім цього можна використовувати комбінований розбір, що сполучає особливості двох попередніх.
Спадні і висхідні підходи широко використовуються в різних областях людської діяльності, особливо в тих із них, що пов'язані з аналізом і синтезом штучних систем. Зокрема, можна відзначити методи розробки програмного забезпечення зверху вниз (спадний) і знизу нагору (висхідний).
+26.2.Завдання управління проектами по розробці ПЗ
В Visual Studio Team System и Team Foundation Server (TFS) включены инструменты, шаблоны и отчеты, помогающие отслеживать и поддерживать процессы разработки ПО. Они упрощают обмен информацией в рамках ко-манды, автоматизируют передачу необходимых данных различным членам команды, упрощают распределение и отслеживание рабочих элементов, на-пример, задач, облегчают контроль за показателями состояния проекта.
Планирование проектов обычно выполняется по следующей схеме:
1. Концептуальное описание проекта
2. Формулирование
3. Формирование набора функциональных возможностей для реализации выбранных сценариев
4. Формирование набора рабочих элементов
5. Распределение задач по областям
6. Создание плана работ
Основные функции Visual Studio Team System по управлению проектами таковы:
Управление процессами (Система управления процессами Team Foundation Server включает руководство по процессу Microsoft Solution Framework (MSF), а также шаблоны процессов, благодаря которым но-вые командные проекты обеспечены типами рабочих элементов, отчета-ми, порталом проекта SharePoint и настройками системы управления ис-ходным кодом.)
Безопасность и разрешения
Централизованное управление рабочими элементами
Интеграция с Microsoft Office Excel и Microsoft Office Project
Показатели и составление отчетов
Порталы проекта
Управление проектами из TFS имеет такие преимущества:
централизованное управление;
возможность отслеживать взаимосвязи рабочих элементов;
интегрированное планирование и составление графика проекта;
расширенные возможности управления процессами;
расширенные возможности обмена информацией и взаимодействия
внутри команды;
подробные отчеты о ходе выполнения работ.
Этапы создания проектов и управление ими в Team Foundation Server
1.Выбор шаблона процесса
2.Создание командного проекта
3.Добавление в командный проект групп и членов
4.Разработка итерационного цикла проекта
5.Преобразование сценариев в рабочие элементы TFS.
6.Выбор сценариев, которые должны быть завершены в каждой итерации.
7. Определение требований QoS (Связывание требований со сценариям).
8. Разбиение сценариев с целью обеспечить разработчиков управляемыми рабочими элементами
9. Создание графика проекта (создается в Microsoft Project и добавляется в Team Project).
10. Определение критериев приемки (Критерии завершенности рабочих элементов согласовываются с требованиями QoS).
11. Определение требований к отчетам
+26.3.Моделювання екосистем програмного забезпечення.
Існує чотири типи засобів моделювання екосистем програмного забезпечення: