Шляхом побудови дерева виводу.
19.5.Створіть систему показників оцінки «зеленості» інформаційних технологій.
+19.1.Що таке дослідження програмного забезпечення? Основні типи і відмінності.
Дослідження програмного забезпечення – діяльність, скерована на вивчення, тестування та аналіз програмного забезпечення.
Головним методом досліджень програмного забезпечення є вимірювання.
Виділяють два підходи дослідження програмного забезпечення: статичний і динамічний.
Динамічне тестування здійснює виявлення помилок в програмі, що виконується. Тестування закінчується, коли виконалася або "пройшла" (pass) успішно достатня кількість тестів у відповідності з обраним критерієм тестування.
Статичний виявляє невірні конструкції або невірні відношення об’єктів програми (помилки формального завдання) формальними методами аналізу без виконання програми, що тестується:
За допомогою спеціальних інструментів контролю кода;
Оглядів (Reviews);
Інспекції (Inspections);
Наскрізних переглядів (Walkthroughs);
Аудитів (Audits);
Тестування вимог, специфікацій, документації.
Мета статичного тестування – оцінити безвідмовність системи.
Техніка статичного аналізу полягає в методичному перегляді (огляді) й аналізі структури програм, а також у доведенні правильності формальними методами. Статичний аналіз спрямований на аналіз документів, створених на всіх етапах ЖЦ, і полягає в інспекції вихідного коду та наскрізного контролю програми.
Процес інспектування – формалізований процес, що виконується невеликою групою спеціалістів (не більше чотирьох чоловік).
Для початку процесу інспектування програми необхідні наступні умови:
Наявність точної специфікації коду, призначеного для інспектування.
Члени інспекційної групи повинні добре знати стандарти розробки.
В розпорядженні групи повинна бути синтаксично коректна остання версія програми.
Помилки, що виявляються при інспектуванні
Помилки даних
Помилки управління
Помилки введення/виведення
Помилки інтерфейсу
Помилки управління пам’яттю
Помилки управління виключеннями
Коли проводиться наскрізний контроль, то експерти сприймають ще й словесне пояснення розв’язаної задачі і засобів її проектування. Це та безпосередній перегляд коду дозволяють виявити помилки в логіці та в описі алгоритму. Наскрізний контроль полягає в ручній імітації виконання програми.
Серед основних методів виділяють:
Метод простого структурного аналізу
Методи доведення коректності програм
Метод аналізу інтерфейсів
Метод перевірки несуперечності
Статичні аналізатори програм – це інструментальні програмні засоби, які сканують вихідний текст програми і виявляють можливі помилки і протиріччя. Для аналізаторів не потрібна виконувана програма. Вони виконують синтаксичний розбір тексту програми і розпізнають різноманітні типи операторів. Таким чином, за допомогою аналізаторів можна перевірити, чи правильно складені оператори, зробити висновки відносно потоку управління в програмі і в багатьох випадках обчислити множину значень даних, що використовуються програмою. Аналізатори доповнюють засоби виявлення помилок, що надаються компілятором мови. Мета автоматичного статичного аналізу – привернути увагу перевіряючого до аномалій в програмі, наприклад до змінних, які використовуються без ініціалізації або зовсім не використовуються, або до даних, значення яких перевищують задані. Помилки, що виявляються статичним аналізом:
Помилки даних (змінні визначені, але ніде не використовуються, змінні використовуються до їх ініціалізації)
Помилки управління (код, що не використовується; безумовні переходи в циклах )
Помилки введення/виведення (змінні виводять двічі без проміжкового присвоєння)
Помилки інтерфейсу (неправильний тип параметру; неправильна кількість параметрів, результати функцій не використовуються)
Помилки управління пам’яттю (помилки у використанні покажчиків).
Статичний аналіз складається із декількох етапів:
Аналіз потоку управління.
Аналіз використання даних.
Аналіз інтерфейсу.
Аналіз потоків даних.
Аналіз гілок програми.
Основна перевага використання статичних аналізаторів коду полягає в можливості істотного зниженні вартості усунення дефектів в програмі.
************************************************
Техніки тестування (поділ за знанням системи:):
тестування «білої скриньки» (досліджуються внутрішні елементи програми і зв'язки між ними.)
тестування «чорної скриньки» (досліджується робота кожної функції на всій області визначення - основне місце програми тестів «чорної скриньки» — інтерфейс ПЗ);
тестування «сірої скриньки»
Рівні тестування (поділ за ступенем ізольованості компонентів):
блокове тестуванням (тестування повного класу, методу або невеликого програми, написаної одним програмістом або групою, що виконується окремо від інших частин системи).
модульне тестування (призначене для перевірки правильності окремих модулів, поза залежності від їх оточення)
Інтеграційне тестування (призначене для перевірки правильності взаємодії модулів деякого набору один з одним)
системне тестування (призначене для перевірки правильності роботи системи в цілому, її здатності правильно вирішувати поставлені користувачами задачі в різних ситуаціях)
Типи тестуваня (поділ видів тестування в залежності від мети):
функціональне;
нефункціональне
пов'язане зі змінами
За ступенем автоматизації тестування буває:
ручне
автоматизоване
напівавтоматизоване
За об'єктом тестування:
функціональне тестування
тестування продуктивності :
-навантажувальне тестування;
-стрес-тестування
-тестування стабільності;
тестування зручності використання
тестування інтерфейсу користувача
тестування безпеки
тестування локалізації
+19.2.Робочий елемент шаблону процесу, призначення та структура.
+***19.3.Розкрийте місце впровадження програмного забезпечення в управлінні конфігураціями програмного забезпечення.
Управління конфігурацією програмного забезпечення, або конфігураційне управління, розглядається як діяльність, яка виконується на протязі всіх етапів ЖЦПЗ і здійснює ідентифікацію, опис (документування) і контроль всіх елементів програмного виробу і всіх модифікацій, що появлятися в процесі його експлуатації.
Управління конфігурацією – одночасно і технічна, і управлінська діяльність, направлена на підтримку високої якості виробу і ретельний контроль всіх вироблюваних змін. Конфігураційне управління грає особливу роль в організації супроводу програмної продукції.
Зміни відбуваються як під час розробки програмної продукції, так і під час її експлуатації. Якщо ці зміни не аналізувати всебічно до їх реалізації, виникне плутанина, для мінімізації якій і було призначено конфігураційне управління.
Конфігурація програмного виробу утворюється з сукупності взаємозв’язаних об’єктів, які називають елементами конфігурації. До елементів конфігурації відносяться:
Комп’ютерні програми (у формі вихідного або виконуваного коду);
Документи, які описують програми (з орієнтацією або на користувача, або на обслуговуючий персонал);
Структури даних, що містяться або в програмах, або зовні них.
Можливий набір основних елементів, що включаються в сферу конфігураційного управління і визначаючих конфігурацію програмного виробу, охоплює:
Вимоги користувача.
Специфікацію вимог до програмного виробу.
Технічне завдання на розробку програмного виробу.
План проектування програмного виробу.
Попереднє керівництво користувача.
Специфікацію проекту (опис архітектурного проекту, проекту даних, проектів окремих модулів).
Документовані лістингу вихідних кодів.
Матеріали тестування: (план і процедура тестування, тестові набори і результати тестування).
Операційне керівництво і керівництво по введенню в дію.
Робочі програми (виконувані модулі і модулі зв’язків).
Опис бази даних: (схема бази і структури файлів, первинне наповнення).
Документи по супроводу програмного виробу.
Стандарти і процедури, що визначають порядок виконання робіт.
Під конфігураційний контроль поміщають програмні засоби, що також додатково використовуються: конкретні версії редакторів, компіляторів, CASE-засобу і т.п. Оскільки ці засоби використовуються для створення різної документації і вихідного кодів, тому вони повинні бути доступними, коли з’являється необхідність внесення змін. На практиці конфігураційні елементи каталогізуються в базі даних проекту.
У міру просування розробки програмного виробу росте число елементів конфігурації, оскільки кожний елемент у свою чергу породжує інші елементи.
При створенні виробу зміни відбуваються в процесі роботи постійно, у міру накопичення розробниками досвіду і інформації.
Управління конфігурацією програмного виробу, таким чином, дисципліна використання адміністративного і технічного керівництва і нагляду з метою:
Ідентифікації і документування фізичних і функціональних характеристик елементів конфігурації;
Контролю за зміною цих характеристик;
Реєстрації, обробки і документування змін і встановлення статусу реалізації;
Перевірки узгодженості проведених дій зі встановленими вимогами.
Особливу трудність для супроводу представляють програмні вироби складної структури, що мають численних користувачів. Для оптимальної організації робіт по внесенню змін застосовується конфігураційне управління, що базується на:
Ревізійному контролі;
Ідентифікаційному контролі;
Управлінні розповсюдженням.
Ревізійний контроль пов’язаний з чіткою класифікацією всіх компонентів програмного виробу і з контролем за їх змінами. Класифікація використовує для програмного виробу такі поняття, як виріб, варіант, версія, редакція.
Вироби використовуються для отримання можливостей, що різняться між собою, варіанти допускають різні умови роботи, версії забезпечують різні властивості, а редакції забезпечують різну міру коректності. Таким чином, версії, відрізняючись деякими властивостями, зберігають всі основні функції виробу і сумісні з попередніми версіями цього виробу. Нова редакція частіше за все пов'язана з усуненням знайдених помилок або покращенням експлуатаційних характеристик. По кожній зміні, що вноситься, необхідно приймати рішення про те, до якого результату приведе дана зміна, для чого заздалегідь проводиться оцінка того, які зміни і в яких компонентах повинні бути проведені. Прийняття рішення базується на заздалегідь складених матрицях впливів і таблицях прийняття рішень, що дозволяють достатньо надійно визначати міру впливу можливих змін, що вносяться у виріб. Зміни, пов'язані із створенням нового виробу або варіанту, вимагають нового проектування. Нові вироби і варіанти не замінюють старі; нові версії і редакції використовуються замість колишніх.
Друга функція ревізійного контролю – контроль за змінами. Кожна зміна породжує послідовність змін, які повинні бути внесені в інші компоненти і документацію. З цією метою складаються матриці впливу, де вказується, які компоненти виробу вимагають перегляду при створенні нової редакції, версії і т.д. Так для створення нового виробу потрібна розробка нових документів і нового керівництва, а для нової версії – лише перегляд деяких документів.
В складних виробах, побудованих за модульним принципом, звичайно створюється база даних програмного виробу, в якій кожний компонент виробу повинен мати унікальний ідентифікатор. Ідентифікаційний контроль служить для присвоєння всім компонентам ідентифікаційних кодів. Оскільки система компонентів утворює ієрархічну багаторівневу систему, ідентифікація будується на основі послідовного коду. Окрім ідентифікаційного коду, кожний компонент забезпечується набором кодів, що характеризують номер варіанту, версії, редакції.
Третя складова конфігураційного управління – управління розповсюдженням, яке гарантує виборчий розподіл матеріалів – повідомлень про внесені зміни користувачів. При цьому ведеться облік користувачів, списки розсилки матеріалів. Наявність стрункої і чіткої системи ідентифікації спрощує роботу і дозволяє автоматизувати процеси інформаційного обслуговування користувачів.
+19.4. Показати, що ланцюг –123 належить мові, що задається граматикою G2={T,N, P, I}:
T={0, .., 9, +, –} N={I, P, ЦИФРА} Правила P I ::= P | +P | –P P ::= ЦИФРА | ЦИФРА P ЦИФРА ::= 0 | 1 . . . | 9
шляхом побудови дерева виводу.
-19.5.Створіть систему показників оцінки «зеленості» інформаційних технологій.
При создании и использовании зеленых информационных систем и технологий следует руководствоваться тремя принципами устойчивого развития: экологическая эффективность, экологическая справедливость, экологическая результативность.
Эко-эффективность (eco-efficiency) следуя принципу нужно в деятельности (системах и технологиях) применять меньше методов и средств, которые вредят природе и неэффективно используют невосстанавливаемые ресурсы. В аспекте эффективности по отношению к информационным системам и технологиям решаются задачи: "какими они должны быть". В аспекте эко-эффективности формулируется задача: "где они должны быть и что они должны там делать".
Эко-справедливость (eco-equity) следуя принципу нужно равно распределять ресурсы между живущим и следующими поколениями.
Ведущую роль в реализации принципа играет информирование. Люди не понимают:
преимущества, которые дает здоровая и разнообразная экосистема;
важность зеленых проблем, которые встают перед предприятиями;
что надо делать для обеспечения экологической стабильности.
Информирование наверх обеспечивает менеджеров, руководство, государственных деятелей информацией о состоянии экологии на местах. Это позволяет лучше понимать то, какие нужны законодательные и регуляторные процессы и как эффективнее на них влиять. Принятие экологически справедливого распределения деятельности выполняется главным образом за счет нормативно-принудительных влияний.
Эко-результативность (eco-effective) следуя принципу надо полностью прекращать негативное влияние на окружающую среду.
Если лозунгом эко-эффективности является "Делать вещи правильно!", то лозунгом эко-результативности является "Делать правильные вещи!". С помощью принудительных, нормативных и мимикрирующих влияний происходит преобразование отдельных организаций и
Зеленые информационные технологии. Практическая реализация концепции устойчивого развития средствами информатики в различных доменах осуществляется с помощью информационных технологий. Роли информационных технологий, при этом делят на три типа – информировать, автоматизировать и превращать. Требования устойчивого развития предприятия содержат выполнение следующих условий:
выпуск качественной продукции, которая отвечает потребностям целевой группы населения и не влияет вредно на окружающую среду;
создание благоприятного зеленого имиджа предприятия в глазах населения и деловых партнеров;
создание благоприятной социально-психологической атмосферы в коллективе и условий для творческой самореализации работников в направлении устойчивого развития;
выполнение требований экологической безопасности производственного процесса в зависимости от специфики предприятия (потребление природных ресурсов и загрязнение окружающей среды).
Зеленые технологии состоят из следующих элементов: зеленый бизнес, зеленые информационные технологии и зеленая энергия. Можно сформулировать рекомендации для разработчиков программного обеспечения зеленых информационных технологий:
организовывать эффективное потребление электроэнергии, используя интерфейс ACPI и виртуализацию;
переводить компьютер в режимы пониженного энергопотребления в промежутки времени, когда информационные технологии не обрабатывают данные;
использовать в программном обеспечении многопоточную обработку данных;
использовать специализированные алгоритмы и структуры данных;
следить за распределением динамической памяти.
Чтобы озеленять информационные технологии можно использовать следующие подходы:
тактический, инкрементный – ставятся отдельные цели, проводятся простые измерения, реализуются отдельные операции по озеленению не требующие больших затрат, например, уменьшение потребления энергии информационной системой и офисом в целом;
стратегический – выполняется аудит организации и разрабатывается план, охватывающий разные аспекты озеленения, включая бизнес, информационную технологию, маркетинг, имидж;
глубокий зеленый – дополняя стратегический подход измерениями, например, количество углекислого газа, и проводя широкие и систематические мероприятия, достигают комплексного озеленения всей организации.
ВАРІАНТ № 20
20.1.Перерахуйте засоби, які застосовуються при впровадженні програмного забезпечення.
20.2.Зелені центри обробки даних.
20.3.Три форми записи арифметичних виразів. Переваги зворотної польської записи.
20.4.Розгляньте наступну ситуацію: Вам потрібно розробити мультиплатформну комп’ютерну гру, яка використовує можливості апаратного прискорення відео та звуку. Яка архітектура програмного забезпечення забезпечить найкращі можливості для перенесення на інші платформи? Намалюйте схематично таку архітектуру та поясніть її.
20.5.Описати послідовність дій для структурування додатку Windows Forms у TFS.
-20.1.Перерахуйте засоби, які застосовуються при впровадженні програмного забезпечення.
+20.2.Зелені центри обробки даних.
Зеленый центр данных — место для хранения, обработки, управления и распространения данных, где механические, световые, электрические и компьютерные системы максимально эффективно используют энергетические ресурсы и минимально влияют на окружающую среду. Строительство и эксплуатация зеленого ЦОД включает в себя использование передовых стратегий управления и новейших технологий.
Энергоэффективный зеленый ЦОД определяется множеством факторов, например:
Минимизация следов строительства и самих зданий;
• Использование материалов с минимальным уровнем воздействия на окружающую среду;
• Проведение озеленения и дальнейшая поддержка;
• Утилизация отходов;
• Установка на резервных генераторах каталитических конвертеров-нейтрализаторов (устройств, обеспечивающих снижение токсичности отработанных газов);
• Использование альтернативных источников энергии (солнечная энергия, тепловые насосы, испарительное охлаждение);
• Использование компанией гибридного или электрического транспорта.
Чтобы добиться чего-то большего, необходимы организационные и технологические изменения. Курс на экологическую эффективность как при переоснащении существующих, так и при строительстве новых ЦОДов требует фундаментальной переориентации корпоративного управления.
Принципы работы ЦОД:
- Виртуализация. Отличное решение при недостатке площадей и мощностей. С ее помощью можно сократить количество единиц оборудования в ЦОД. Эта технология дает возможность экономить время на установку новых программ в ЦОД, позволяет изолировать потенциально опасные окружения и создавать необходимые аппаратные конфигурации. За счет виртуализации достигается представление устройств, которых нет в ЦОД, а также проводится обучение работе с операционными системами. Виртуальные машины могут быть объединены в сеть.
-Кластеризация. Необходимая основа для бесперебойной деятельности бизнес процессов. Она обеспечивает объединение нескольких серверов в единую систему, путем установки программных связей между ними, координирует их работу, выполняет перераспределение нагрузки в случае сбоя в одном из серверов.
- Масштабирование. При создании ЦОД необходимо учесть изменяющиеся со временем потребности в ресурсах. Поэтому либо используют максимальную мощность устройств, либо модульную систему. Это значит, что в процессе развития есть возможность добавлять требуемые модули без замены существующего оборудования. Такая система более экономически целесообразна, поскольку, как известно, нет предела совершенству.
- Резервирование. Залог того, что при выходе из строя одной подсистемы центра, функцию ее возьмет на себя другая, резервная. Есть также понятие резервный ЦОД. Он начинает работать тогда, когда основной ЦОД полностью прекратил работу.
Состав ЦОД
Обязательные компоненты, входящие в состав ЦОД, можно разделить на три основные группы:
Технические компоненты. Они создают условия для эффективной работы центра.
2. Программное обеспечение. Это фактически сервисы инфраструктуры ЦОД и ПО для корректной работы бизнес-процессов, необходимых для конкретной организации.
3. Организационная среда - решает вопросы, связанные с предоставлением IT-услуг. Она должна соответствовать требованиям по оказанию IT-услуг, таким как ISO/IEC 20000.
Этапы создания ЦОД
Процесс создания центра обработки данных многоступенчатый. Он включает 5 основных этапов:
Планирование
Конструирование
Реализация
Эксплуатация
Модернизация .
.
+20.3.Три форми записи арифметичних виразів. Переваги зворотної польської записи.
ІНФИКСНА, ПРЕФІКСНА, ПОСТФІКСНА
РОЗГЛЯНЕМО 2+3 в різних формах запису:
ІНФИКСНА 2+3
ПРЕФІКСНА, +23
ПОСТФІКСНА (зворотна польська нотація) 32+
Особенности обратной польской записи следующие:
Порядок выполнения операций однозначно задаётся порядком следования знаков операций в выражении, поэтому отпадает необходимость использования скобок и введения приоритетов и ассоциативности операций.
В отличие от инфиксной записи, невозможно использовать одни и те же знаки для записи унарных и бинарных операций. Так, в инфиксной записи выражение 5 * (-3 + 8) использует знак «минус» как символ унарной операции (изменение знака числа), а выражение (10 - 15) * 3 применяет этот же знак для обозначения бинарной операции (вычитание). Конкретная операция определяется тем, в какой позиции находится знак. Обратная польская запись не позволяет этого: запись 5 3 - 8 + * (условный аналог первого выражения) будет интерпретирована как ошибочная, поскольку невозможно определить, что «минус» после 5 и 3 обозначает не вычитание; в результате будет сделана попытка вычислить сначала 5 - 3, затем 2 + 8, после чего выяснится, что для операции умножения не хватает операндов. Чтобы всё же записать это выражение, придётся либо переформулировать его, либо ввести для операции изменения знака отдельное обозначение, например, «±»: 5 3 ± 8 + *.
Так же, как и в инфиксной нотации, в ОПН одно и то же вычисление может быть записано в нескольких разных вариантах. Например, выражение (10 - 15) * 3 в ОПН можно записать как 10 15 - 3 *, а можно — как 3 10 15 - *
Из-за отсутствия скобок обратная польская запись короче инфиксной. За этот счёт при вычислениях на калькуляторах повышается скорость работы оператора (уменьшается количество нажимаемых клавиш), а в программируемых устройствах сокращается объём тех частей программы, которые описывают вычисления. Последнее может быть немаловажно для портативных и встроенных вычислительных устройств, имеющих жёсткие ограничения на объём памяти.
+***20.4.Розгляньте наступну ситуацію: Вам потрібно розробити мультиплатформну комп’ютерну гру, яка використовує можливості апаратного прискорення відео та звуку. Яка архітектура програмного забезпечення забезпечить найкращі можливості для перенесення на інші платформи? Намалюйте схематично таку архітектуру та поясніть її.
Изменение документации, в зависимости от исходного состояния проекта и новых требований к документированию, может затрагивать разные виды спецификаций проекта. На рис. 3 показана модель восстановления и переработки спецификаций проекта, в которой можно выделить процессы двух основных видов: редокументирование и обратная инженерия [2]. Редокументирование реализует изменения формы представления спецификаций определенного этапа разработки, без использования спецификаций других этапов. Обратная инженерия реализует восстановление или изменение (путем реализации процессов прямой инженерии) спецификаций определенного этапа разработки на основе спецификаций других этапов.
Артефакты, получаемые в результате проектирования ПО, создаются в рамках определенной системы (модели) проектирования. В ней можно выделить следующие основные элементы: парадигму проектирования, языки специфицирования, инструментальные средства проектирования и документирования. Сейчас одним из наиболее совершенных и перспективных процессов разработки ПО-унифицированный процесс разработки (Rational Unified Process - RUP) [5]. В RUP проектирование основано на объектно-ориентированной парадигме, а для специфицирования проекта и его результатов используется язык Unified Modeling Language (UML) [6]. В настоящее время RUP поддерживается семейством продуктов IBM Rational [7]. В рамках RUP, при выполнении рабочих процессов разрабатывается ряд моделей, которые представляются с использованием языка UML. К основным относят следующие модели [5, 7]: требований; анализа, проектирования, развертывания, реализации, тестирования. Основываясь на анализе фаз и рабочих процессов RUP можно распределить эти модели по видам спецификаций (рис.1) следующим образом [5]:
− требований – модель требований;
− проектные – модели анализа и проектирования;
− реализации – модели развертывания, реализации и тестирования.
Очевидно, что для эффективной переработки исходной документации проекта на соответствие моделям RUP необходимо провести предварительное сопоставление их содержания. В таблице приведено сопоставление моделей и артефактов RUP [5, 9] c видами исходных документов проектов ПО, определяемых стандартом [8]. Сопоставление проведено на основе анализа их назначения, семантики и содержания. Кроме того, в таблице приведены типы процессов, обеспечивающие переработку содержимого исходных документов, и исполнители, в качестве которых могут выступать эксперты или соответствующие CASE-инструменты [10]. Сопоставление моделей и артефактов RUP документам стандарта.
1. Начать нужно с определения того, что у нас есть по программе, исходные тесты, БД. Зафиксировать текущее состояние системы для сверения с результатами последующих изменений.
2. Работы по описанию архитектур начинаются фактически на начальном этапе, когда определяется состав оборудования и стандартное программное обеспечение (ПО), необходимые для инсталляции и запуска существующей зафиксированной системы. Тем самым фактически определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры представляются в нотации UML и при необходимости дополняются текстовыми описаниями. Поостренные архитектурные модели в процессе реинжиниринга будут уточняться и дополняться.
3. Построение функциональной модели, диаграммы вариантов использования
4. Анализ требований к системе (функциональных и нефункциональных)
5. На основе полученных спецификаций провести проектирование системы.
6. Провести реализацию системы
7. Провести тестирование системы методами белого ящика и черного ящика, для проверки связей между компонентами и правильности интеграции компонентов, провести модульное тестирование, сверяя результаты с прошлой системой
==============
Архитектура, управляемая событиями (Event-driven architecture — EDA) является шаблоном архитектуры программного обеспечения, позволяющим создание, определение, потребление и реакцию на события.
Событие можно определить как «существенное изменение состояния». Например, когда покупатель приобретает автомобиль, состояние автомобиля изменяется с «продаваемого» на «проданный». Системная архитектура продавца автомобилей может рассматривать это изменение состояния как событие, создаваемое, публикуемое, определяемое и потребляемое различными приложениями в составе архитектуры.
+20.5.Описати послідовність дій для структурування додатку Windows Forms у TFS.
ВАРІАНТ № 21
21.1.Екологічні принципи.
21.2.Шаблон процесу MSFAgile
21.3.Що таке динамічний аналіз? Коли він важливий, і чому?