ВАРІАНТ № 1
Що таке статичний аналіз? Коли він важливий, і чому?
Як перетворити породжуючи граматику в транслюючи граматику?
Сценарії створення збірок.
Підрахуйте кількість спожитої електроенергії та шкідливих викидів на конкретному прикладі, створивши віртуальний персональний комп’ютер.
Підготовте приклад в якому визначаються основні ролі у впровадженні програмного забезпечення та дайте характеристику основних функцій.
+1.1. Що таке статичний аналіз? Коли він важливий, і чому?
Виділяють два підходи дослідження програмного забезпечення: статичний і динамічний.
Статичний аналіз коду - аналіз програмного забезпечення, вироблений без реального виконання досліджуваних програм (аналіз, вироблений з виконанням програм, називається динамічний аналіз коду).
Мета статичного тестування – оцінити безвідмовність системи.
Статичний - статичне тестування, що виявляє невірні конструкції або невірні відношення об’єктів програми (помилки формального завдання) формальними методами аналізу без виконання програми, що тестується:
За допомогою спеціальних інструментів контролю кода;
Оглядів (Reviews);
Інспекції (Inspections);
Наскрізних переглядів (Walkthroughs);
Аудитів (Audits);
Тестування вимог, специфікацій, документації.
Техніка статичного аналізу полягає в методичному перегляді (огляді) й аналізі структури програм, а також у доведенні правильності формальними методами. Статичний аналіз спрямований на аналіз документів, створених на всіх етапах ЖЦ, і полягає в інспекції вихідного коду та наскрізного контролю програми.
Статичний аналіз програмного забезпечення виконується (на відміну від динамічного аналізу) без реального виконання досліджуваних програм. Обычно при этом строится абстрактная модель программы, которая, собственно, и является объектом анализа.
При этом следует подчеркнуть следующие характерные особенности статического анализа:
Возможен раздельный анализ отдельно взятых фрагментов программы (обычно отдельных функций или процедур), что дает достаточно эффективный способ борьбы с нелинейным ростом сложности анализа.
Возможны ложные срабатывания, обусловленные либо тем, что при построении абстрактной модели некоторые детали игнорируются, либо тем, что анализ модели не является исчерпывающим.
При обнаружении дефекта возникают, во-первых, проблема проверки истинности обнаруженного дефекта (false positive) и, во-вторых, проблема воспроизведения найденного дефекта при запуске программы на определенных входных данных.
Статичні аналізатори програм – це інструментальні програмні засоби, які сканують вихідний текст програми і виявляють можливі помилки і протиріччя. Для аналізаторів не потрібна виконувана програма. Вони виконують синтаксичний розбір тексту програми і розпізнають різноманітні типи операторів. Таким чином, за допомогою аналізаторів можна перевірити, чи правильно складені оператори, зробити висновки відносно потоку управління в програмі і в багатьох випадках обчислити множину значень даних, що використовуються програмою. Аналізатори доповнюють засоби виявлення помилок, що надаються компілятором мови.
Основна перевага використання статичних аналізаторів коду полягає в можливості істотного зниженні вартості усунення дефектів в програмі. Чим раніше помилка буде виявленою, тим менша буде вартість її виправлення - виправлення помилки на етапі тестування обійдеться вдесятеро дорожче, ніж на етапі конструювання. Інструменти статичного аналізу дозволяють виявити велику кількість помилок на етапі конструювання, що істотно знижує вартість розробки всього проекту.
Мета автоматичного статичного аналізу – привернути увагу перевіряючого до аномалій в програмі, наприклад до змінних, які використовуються без ініціалізації або зовсім не використовуються, або до даних, значення яких перевищують задані.
Статичний аналіз складається із декількох етапів:
Аналіз потоку управління. На цьому етапі ідентифікуються і виділяються цикли, їх точки входу і виходу, а також код, що не використовується (це код, що оточений безумовними операторами переходу, або код однієї із гілок умовного оператора, умова переходу до якої ніколи не буде істинною).
Аналіз використання даних. На цьому етапі перевіряються використання змінних в програмі. Аналіз дозволяє виявити змінні, які використовуються без попередньої ініціалізації; змінні, які описані двічі без проміжкового присвоєння та інші.
Аналіз інтерфейсу. На цьому етапі перевіряється погодженість різноманітних частин програми, правильність оголошення процедур і їх використання. В процесі аналізу інтерфейсу можна також виявити оголошення функції і процедури, які ніде не викликаються, і функції, результати яких не використовуються.
Аналіз потоків даних. На цьому етапі аналізу визначаються залежності між початковими (вхідними) і результуючими (вихідними) змінними. Хоча такий аналіз не виявляє конкретних помилок, він дає повний список значень, що використовуються в програмі, дякуючи чому легше виявити помилковий вивід даних. На цьому етапі також можна виявити умови, які впливають на значення змінних.
Аналіз гілок програми. На цьому етапі семантичного аналізу визначаються всі гілки програми і виділяються оператори, що виконуються в кожній гілці. Аналіз гілок програми суттєво допомагає розібратися в управління програмою і дозволяє проаналізувати кожну гілку окремо.
Помилки, що виявляються статичним аналізом:
Помилки даних (змінні визначені, але ніде не використовуються, змінні використовуються до їх ініціалізації)
Помилки управління (код, що не використовується; безумовні переходи в циклах )
Помилки введення/виведення (змінні виводять двічі без проміжкового присвоєння)
Помилки інтерфейсу (неправильний тип параметру; неправильна кількість параметрів, результати функцій не використовуються)
Помилки управління пам’яттю (помилки у використанні покажчиків).
Статичні аналізатори можуть бути як загального призначення (наприклад, Microsoft PREFast, Gimpel PC-Lint, Parasoft C++Test), так і спеціалізованими для пошуку певних класів помилок (наприклад, Chord для верифікації паралельних програм Java).
-1.2. Як перетворити породжуючи граматику в транслюючи граматику?
---------
Формальная грамматика - система правил, описывающая множество конечных последовательностей символов формального алфавита.
Конечные цепочки символов называются предложениями формального языка,а само множество цепочек - языком,описываемым данной грамматикой.
Набор синтаксических правил формального языка аналогичен системе подстановок, используемых в нормальных алгоритмах Маркова. Вывод в данной порождающей грамматике есть последовательность цепочек, в которой любая, начиная со второй, получается из предыдущей применением какого-либо правила вывода.
Формальная грамматика задается упорядоченной четверкой {T, N, S, Р}, где Т и N - непересекающиеся конечные множества, образующие алфавит или словарь порождаемого формального языка; Т называется множеством (словарем) терминальных символов; N - множеством (словарем) нетерминальных (вспомогательных)символов. S - начальный (выделенный) вспомогательный символ из множества N. Р - набор правил вывода конструкций языка (подстановок) из выделенного вспомогательного символа, имеющие вид g→ h, где g и h - цепочки, состоящие как из терминальных, так и нетерминальных символов.
Подстановки работают следующим образом: если в преобразуемой цепочке есть слово g, то оно заменяется словом h. Единственное ограничение на вид подстановок состоит в том, что слово g не может состоять только из терминальных символов. Это означает, что получение на некотором шаге цепочки, состоящей только из терминальных символов, свидетельствует о прекращении процесса порождения - эта цепочка является правильной, завершенной конструкцией порождаемого языка. Подстановки Р могут применяться к трансформируемой цепочке в произвольном порядке.
-------------------------------
Транслирующие грамматики
Позволяют решать задачу перевода в более сложных случаях, чем СУ-схемы. ТГ это разновидность КС-грамматик, где символы (терминалы) разделены на два множества, Σi и Σa (a от action), называемые "входными" и "операционными" соответственно. При использовании ТГ, чтобы различать элементы Σi и Σa, будем заключать последние в фигурные скобки, '{', '}', считая получившиеся на письме три символа одним символом алфавита.
Пример. Перевод простого алгебраического выражения в ПОЛИЗ ...
Определение.
активная цепочка - Пусть α ∊ (Σi ∪ Σa)*. Тогда α называется активной цепочкой. Входные (операционные) символы активной цепочки, записанные отдельно в том же порядке, как они встречались в ней, образуют входную (операционную) цепочку.
Операционные символы можно трактовать как имена процедур, выполняющих определённые действия. Пока - процедур без параметров. Операционные символы также могут использоваться для интерпретации кода. Операционные символы могут находиться в любой части результата продукции, не только в суффиксе, но это может сильно усложнить парсер (иногда придётся откатываться).
Порождающая грамматика - система правил, позволяющая строить конечные последовательности символов.
Порождающая грамматика G - это четверка (VT, VN, P, S), где
VT - алфавит терминальных символов (терминалов),
VN - алфавит нетерминальных символов (нетерминалов), не пересекающийся с VT,
P - конечное подмножество множества (VT VN)+ (VT VN)*; элемент (, ) множества P называется правилом вывода и записывается в виде ,
S - начальный символ (цель) грамматики, S VN.
Контекстно-свободная грамматика называется q-грамматикой тогда и только тогда, когда выполняются два условия:
1. Правая часть каждого правила либо представляет собой пустую цепочку e, либо начинается с терминального символа.
2. Множество выбора правил с одной и той же левой частью не пересекаются.
Транслирующей грамматикой (Т-грамматикой) называется КС-грамматика, множество терминальных символов которой разбито на множество входных символов и множество выходных символов, которые называются также символами действия.
Построение транслирующих грамматик предусматривает использование одной грамматики и разрешает включение как входных, так и выходных символов в каждое правило такой грамматики.
Примером Т- грамматики может служить следующая грамматика:
V
твх
= {a, b,с},
//входные символы
Vтвых = {x, y, z}, //символы действия
VA = { <А>, <В>} //нетерминальные символы
<A> // начальный терминал
R = {<А> → a<А>x<В>, //правила
<А> → z,
<A> → <В>c,
<В> → by }.
Для удобства выходные символы окружают фигурными скобками.
R = {<А> →a<А>{x}<В>,
<А> →{z},
<В> →<В>c,
<В> →b{y} }.
Вывод в транслирующих грамматиках выполняется по тем же правилам, что и в обычных КС- грамматиках.
Например, в рассматриваемой грамматике из начального символа может быть выведена следующая цепочка:
<
I>
⇒a<I>{x}<A>
⇒a{z}{x}<A>
⇒a{z}{x}b{y}
Каждый символ или цепочка символов, заключенные в фигурные скобки, должны рассматриваться как единый символ, называемый символом действия. Цепочки символов, заключенные в фигурные скобки, можно интерпретировать как имена процедур, выпол-нение которых производит требуемый эффект на выходе. При описании перевода обыч-но считают, что каждый символ действия представляет собой процедуру, осуществляю-щую передачу символа, заключенного в фигурные скобки, на выход. Когда нужно под-черкнуть, что используется такая интерпретация символов действия, то Т- грамматику называют грамматикой цепочного перевода.
---
Транслирующей грамматикой или грамматикой перевода называется контекстно-свободная грамматика, множество-терминальных символов которой разбито на множество входных символов и множество символов действия. Цепочки языка, определяемого транслирующей грамматикой, называются последовательностями актов.
Пример транслирующей грамматики:
Для того чтобы символы действия при чтении отличались от нетерминальных и входных символов, мы примем соглашение заключать их в фигурные скобки. При таком соглашении, взглянув на любую цепочку символов, можно сразу увидеть, какие из символов являются нетерминалами, какие — входными символами и какие — символами действий. Например, если только что приведенная грамматика была бы построена с символами действий {x}, {у}и {z} вместо x, у и z, то множество правил имело бы вид:
+1.3. Сценарії створення збірок.
Самые распространенные сценарии Team Build:
Однократная ежедневная сборка. Большинство групп используют плановые сборки, чтобы регулярно обеспечивать двоичными файлами группу тестирования и других пользователей.
Ежедневные сборки и сборки в процессе непрерывной интеграции.Некоторые группы предпочитают использовать процесс непрерывной интеграции, чтобы обеспечить своим разработчикам быструю обратную связь при каждом событии регистрации изменений. Непрерывная интеграция хороша для небольших групп, а вот сервер сборки большой группы, вероятнее всего, будет перегружен из-за высокой частоты формирования событий регистрации изменений и более длительного времени сборки. Когда такое происходит, можно использовать скользящую сборку, которая позволяет выполнять сборку не так часто, но при этом не делая больших перерывов между событием регистрации изменений и получением результатов сборки.
Несколько лабораторий сборки, каждая из которых создает ежедневную сборку и сборки в процессе непрерывной интеграции. Очень большим группам для улучшения качества сборок и своевременного их выполнения, скорее всего, потребуются более сложные решения. Используя регистрацию изменений с порогом качества и отклоняя дефектные изменения прежде, чем они будут зарегистрированы в системе контроля версий, можно сократить сбои при сборках. Группы, использующие ветвление, могут использовать несколько серверов сборки, по одному на каждую ветвь, чтобы каждая сборка была ориентирована на цели своей ветви. Например, ветви интеграции создают сборки для целей интеграции, тогда как ветви разработки создают сборки для целей разработки.
+1.4. Підрахуйте кількість спожитої електроенергії та шкідливих викидів на конкретному прикладі, створивши віртуальний персональний комп’ютер.
Для того щоб підрахувати загальну кількість споживання електроенергії необхідно підсумувати витрати енергоспоживання всіх вузлів комп’ютера:
процесор AMD Athlon II x3 425e – 45 Вт;
материнська плата MSI 990XA-GD55 –75 Вт;
оперативна пам'ять - DDR3- 2000МГц -2 Вт;
жорсткий диск - HDD SATA II GREEN – 5400-7200 об/хв – 7 Вт;
DVD-RW привід - 27 Вт;
звукова карта ASUS D2 - 30 Вт;
відеокарта Radeon HD 5450 – 18 Вт;
монітор: Samsung S23B350TS - 30 Вт.
Підрахуємо величину використання електроенергії всіх вузлів загалом:
ВЕ = 45 + 75 + 2 + 7 + 27 + 30 + 18 + 30= 234 (Вт).
Підрахуємо енергоспоживання за рік за наступною формулою:
ВЕз = ВЕ * 24 * 365,
Тобто, підставивши розраховане значення, отримаємо:
ВЕз = 234 * 24 * 365 = 2049840 (Вт) = 2049,84 кВт.
Отже, дане обладнання при максимальному навантаженні за рік споживає 2049,84 кВт електроенергії.
За розрахунками, середні викиди шкідливих речовин при виробленні 1 кВт/год електроенергії -17 г, в тому числі: S - 9,9 г; CO - 0,5 г; NOx - 2,2 г; твердих частин - 4,4 г.
Отже, при максимальному навантаженні за рік даний комп’ютер створює таку кількість шкідливих речовин:
Шк.р. = 2049,84 * 17 = 34847,28 (г);
у тому числі:
S = 2049,84 * 9,9 = 20293,42 (г);
CO = 2049,84 * 0,5 = 1024,92 (г);
NOx = 2049,84 * 2,2 = 4509,65 (г);
Тв.ч. = 2049,84 * 4,4 = 9019,29 (г).
+***1.5. Підготовте приклад, в якому визначаються основні ролі у впровадженні програмного забезпечення та дайте характеристику основних функцій.
Ролі
в дослідних умовах:
application developers(розробники додатків)
build and release engineers(інженери які роблять білди та релізи?!)
release managers(реліз менеджери)
deployment coordinators(координатори впровадження)
у виробничому середовищі:
system administrator(системний адмін)
database administrator(адмін БД)
release coordinators(координатори релізу?)
operations project managers(хз як правильно перевести)
Основні функції
Випуск
Установка та активація
Відключення(деактивація)
Адаптація
Оновлення
Відстеження версій
Видалення
поперешняк======
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения:
Ролевой кластер |
Фокус |
Управление продуктом (роль: бизнес-аналитик) |
Получение отзывов и оценок заказчика; акт о приеме выполненной работы. |
Удовлетворение потребителя (роль: бизнес-аналитик) |
Обучение; управление календарным графиком обучения. |
Управление программой (роль: менеджер проекта) |
Сопоставление рамок проекта с поставленным решением; управление стабилизацией. |
Разработка (роль: разработчик) |
Разрешение проблем; поддержка эскалации. |
Тестирование (роль: тестер) |
Тестирование производительности. |
Управление выпуском (роль: релиз-менеджер) |
Управление внедрением; одобрение изменений. |
Розглянемо на прикладі впровадження «Автоматизованої системи побудови файлів телепрограми для верстки в Adobe InDesign», розроблюваного за методолгією MSF, основні ролі та їх функції.
Основні завдання фази:
• Впровадження технологій і компонент рішення.
• Стабілізація впровадженого рішення.
• Передача робіт персоналу підтримки і супроводу.
• Отримання з боку замовника остаточного схвалення результатами проекту.
• Аналіз виконаної роботи і задоволеності замовника.
У процесі впровадження даного ПЗ беруть участь такі учасники:
бізнес-аналітик, який об’єднує виконання задач двох рольових кластерів: «Управління продуктом» (отримання відгуків і оцінок замовника, оформлення акту про прийом виконаної роботи) і «Задоволення споживача» (навчання персоналу, управління календарним графіком навчання).
Тобто, бізнис-аналітик беспосередньо спілкується із представниками замовника, здійснює згідно із затвердженим графіком навчання дизайнерів, які будуть працювати із системою, після чого проводить тести, оцінюючі рівень освоєння системи користувачами. Також він здійснює анкетування дизайнерів, які оцінюють різні аспекти системи, наприклад, зручність використання, зрозумілість інтерфейсу тощо, а також виявляє зауваження і пропозиції щодо змін.
менеджер проекту (рольовий кластер «Управління програмою») у фазі впровадження ПЗ здійснює зіставлення рамок проекту з поставленим рішенням і управління стабілізацією впровадженного рішення.
тестери (рольовий кластер «Тестування») – виконуються тестування продуктивності, перевіряють, чи вкладається виконання побудови файлів телепрограми у визначений у вимогах час – 6 хвилин, а також, чи не перевищує кількість помилок у готових файлах затверджену кількість (не більше двох на 7 файлів поточного випуску).
розробники (рольовий кластер «Розробка») займаються розв’язанням проблем у разі їх виявлення тестувальниками, а також підтримкою ескалації.
реліз-менеджер (рольовий кластер «Управління випуском») здійснює управління впровадженням системи на обладнанні замовника і схвалює зміни в системі (наприклад, під час анкетування дизайнери висловили пропоцизію поміняти місцями розташування кнопок «Обрати каталог» та «Встановити каталог за замовчюванням» у головному вікні інтерфейсу ПЗ). Зміни, які суттєво змініються функціональність системи плануються на реалізацю наступної версії ПЗ, зокрема:
а)заміна вставки спецсимволів у рядки телепрограми. на які реагують стилі в програмі Adobe InDesign, що вимагають налаштування стилів, вставкою тегів, які автоматично присвоюються стиль рядку без поперного налаштування,
б) додавання функції видалення поточних стартових файлів із проміжного каталогу, після створення архіву, задля уникнення їх помилкового повторного використання наступного номеру.
Отже, у ході впровадження отримано такі результати: інформаційні системи експлуатації та підтримки; бази знань, звіти, журнали протоколів; версії проектних документів, масиви даних та програмний код, розроблені під час проекту; остаточні версії всіх проектних документів; показники задоволеності замовника та дизайнерів,
Також оформлено звіт про завершення проекту і опис наступних кроків (зкорема, плани реалізації змін у наступній версії, зокрема, )
ВАРІАНТ № 2
Методи граматичного розбору.
П`ять головних принципів концепції сталого розвитку.
Верифікація в процесі дослідження програмного забезпечення.
На прикладі програмного забезпечення підготовленого до експлуатації перерахуйте та розкрийте зміст основних дій пов’язаних з впровадженням і експлуатацією програмного забезпечення.
Описати послідовність дій для налаштування планової збірки у TFS.
+2.1. Методи граматичного розбору.
Выделяются два основных метода синтаксического разбора:
нисходящий разбор;
восходящий разбор.
комбинированный разбор, сочетающий особенности двух предыдущих.
Нисходящий разбор (укр. спадний розбір) заключается в построении дерева разбора, начиная от корневой вершины. Разбор заключается в заполнении промежутка между начальным нетерминалом и символами входной цепочки правилами, выводимыми из начального нетерминала. Подстановка основывается на том факторе, что корневая вершина является узлом, состоящим из листьев, являющихся цепочкой терминалов и нетерминалов одного из альтернативных правил, порождаемых начальным нетерминалом. Подставляемое правило в общем случае выбирается произвольно. Вместо новых нетерминальных вершин осуществляется подстановка выводимых из них правил. Процесс протекает до тех пор, пока не будут установлены все связи дерева, соединяющие корневую вершину и символы входной цепочки, или пока не будут перебраны все возможные комбинации правил.
При восходящем разборе (укр. висхідному розборі) дерево начинает строиться от терминальных листьев путем подстановки правил, применимых к входной цепочке, опять таки, в общем случае, в произвольном порядке. На следующем шаге новые узлы полученных поддеревьев используются как листья во вновь применяемых правилах. Процесс построения дерева разбора завершается, когда все символы входной цепочки будут являться листьями дерева, корнем которого окажется начальный нетерминал. Если, в результате полного перебора всех возможных правил, мы не сможем построить требуемое дерево разбора, то рассматриваемая входная цепочка не принадлежит данному языку.
+2.2.П`ять головних принципів концепції сталого розвитку.
Концепція сталого розвитку ґрунтується на п'яти головних принципах:
Людство дійсно може надати розвитку сталого і довготривалого характеру, для того щоб він відповідав потребам людей, що живуть зараз, не втрачаючи при цьому можливості майбутнім поколінням задовольняти свої потреби.
Обмеження, які існують в галузі експлуатації природних ресурсів, відносні. Вони пов'язані з сучасним рівнем техніки і соціальної організації, а також із здатністю біосфери до самовідновлення.
Необхідно задовольнити елементарні потреби всіх людей і всім надати можливість реалізувати свої надії на благополучніше життя. Без цього сталий і довготривалий розвиток просто неможливий. Одна з головних причин виникнення екологічних та інших катастроф — злидні, які стали у світі звичайним явищем.
Необхідно налагодити стан життя тих, хто користується надмірними засобами (грошовими і матеріальними), з екологічними можливостями планети, зокрема відносно використання енергії.
Розміри і темпи росту населення повинні бути погоджені з виробничим потенціалом глобальної екосистеми Землі, що змінюється.
+2.3.Верифікація в процесі дослідження програмного забезпечення.---
Види діяльності і техніки гарантії якості містять у собі, зокрема: інспекцію, верифікацію і валідацію ПЗ.
Верифікація ПЗ – процес забезпечення правильної реалізації ПЗ відповідно до специфікацій, виконується протягом усього життєвого циклу. Верифікація дає відповідь на питання, чи правильно створюється система.
Мета – переконатися, що кожен програмний продукт проекту відбиває погоджені вимоги до їхньої реалізації. Додатковою метою є виявлення та реєстрація дефектів і помилок, які внесені під час розробки або модифікації програми.
Верифікація ґрунтується:
на стратегії і критеріях верифікації всіх робочих програмних продуктів на ЖЦ;
на виконанні дій з верифікації відповідно до стандарту;
на усуненні недоліків, виявлених у програмних (робочих, проміжних і кінцевих) продуктах;
на узгодженні результатів верифікації з замовником.
Впровадження процесу полягає у визначенні критичних елементів (процесів і програмних продуктів), що повинні піддаватися верифікації, у виборі виконавця верифікації, інструментальних засобів підтримки процесу верифікації, у складанні плану верифікації і його затвердження. У процесі верифікації виконуються задачі перевірки умов: контракту, процесу, вимог, інтеграції, коду і документації.
Відповідно до плану і вимог замовника перевіряється правильність виконання функцій системи, інтерфейсів і взаємозв'язків компонентів, а також доступ до даних і до засобів захисту.
Додатковою метою є виявлення та реєстрація дефектів і помилок, які внесені під час розробки або модифікації програми.і валідація (V&V) можуть виконуватися, починаючи з ранніх стадій ЖЦ.
Вони орієнтовані на отримання правильних функцій ПЗ, плануються і забезпечуються визначеними ресурсами з чітким розподілом ролей. Перевірка ґрунтується на використанні відповідних технік тестування для виявлення тих або інших дефектів і збирання статистики. Після зібрання даних оцінюється правильність реалізації вимог і роботи ПЗ у заданих умовах
+***2.4.На прикладі програмного забезпечення, підготовленого до експлуатації перерахуйте та розкрийте зміст основних дій, пов’язаних з впровадженням і експлуатацією програмного забезпечення.
Основні дії для експлуатації пз:
1)Підготовка процесу
Оператор повинен розробити план експлуатації і визначити набір стандартів по експлуатації для виконання робіт та задач даного процесу. Оператор повинен встановити процедури для отримання і документування фактів про виниклі проблеми. Оператор повинен встановити процедури для тестування пз в експлуатаційному середовищі .
2)Експлуатаційні вимоги
Для кожного введеного в експлуатацію пз оператор повинен провести експлуатаційне випробування і якщо тестування вдале то перевести продукт в промислову експлуатацію. Оператор повинен забезпечити чтоб пз и бд установлювались в вихідне положення, виконувались і завершались так як це прописано в плані по експлуатації.
3)Експлуатація системи
Система повинна експлуатуватися в установленому для неї експлуатаційному середовищі відносно з документацією.
4)Підтримка користувача
Оператор повинен забезпечити допомогу та консультацію користувачам. Оператор повинен направляти запити користувачів(при необходності) для аналізу і відповіді в процесі супроводження. Якщо поставлена проблема має тимчасове вирішення то оператор повинен представити користувачеві-ініціатору це вирішення проблеми
Внедрение программного продукта
содержит ряд различных шагов. Как правило, необходимы следующие виды деятельности:
Развертывание программного продукта, т. е. инсталлирование (установка) на «железо». Для более сложных, распределенных систем полезны UML-схемы развертывания, которые описывают локализацию программного обеспечения на различные аппаратные узлы, в том числе:
Выпуск (release). Выпуск следует за процессом разработки. Он включает в себя все виды деятельности, подготавливающие систему для ассемблирования (перевод в машинный код) и передачу клиенту. В ходе этой деятельности определяют также ресурсы, необходимые для работы у клиента.
Установка (инсталлирование) и активизация программного обеспечения - запущенные компоненты устанавливают на компьютеры-серверы, где они должны впредь работать. Более сложные системы также нуждаются в инсталлировании прочего поддерживающего программного обеспечения (например, новая версия процессора баз данных, и т.д.). Часто большую систему устанавливают в нескольких средах - например, в дополнение к тестовому серверу, который может быть впоследствии использован для обучения пользователей и для других целей.
Адаптация и обновление - в процессе обновления устанавливают новую версию системы, адаптации - это также изменение системы, но ее основанием является, главным образом, изменение в клиентской среде.
Перенос данных из старой системы - в используемой ранее системе имеются, как правило, данные, которые следует использовать и в дальнейшем. Желательно создание инструмента автоматического переноса данных, который запускают однократно при переносе данных из старой системы к новую. Механизм переноса может быть довольно сложным, особенно если структуры данных старой системы и новой системы существенно различаются. Если совокупность данных - небольшая и / или выработка алгоритма автоматического преобразования чрезмерно сложна, можно данные переносить вручную. В этом случае может понадобиться создать рапорты для извлечения данных из старой системы и формы (средства) для ввода данных вручную во внедряемую систему;
Внесение изменений в другие приложения, которые должны работать совместно и / или которых используют вместе развертываемым с программным продуктом;
Подготовка и проведение обучения людей, соприкасающихся с программным продуктом, согласно следующим ролям:
обычные пользователи
администраторы
поставщики услуг сопровождения
Обучение должно охватывать как теоретическую, так и практическую части. Практическую часть желательно проводить в созданной среде (как программное обеспечение, так и данные), созданной для тестирования и / или обучения, прежде всего для предотвращения рисков в интересах конфиденциальности, доступности и целостности реальных данных;
Создание состояния готовности при управлении кризисной ситуацией и для поведения в кризисных ситуациях. Возможные кризисы при внедрении программного продукта:
отказ программы в рабочей среде
обнаружение в программе ошибок
потери данных.
После этапа внедрения следует фаза сопровождения (поддержки), которая по существу продолжается до тех, пока программное обеспечение остается в эксплуатации.
+2.5. Описати послідовність дій для налаштування планової збірки у TFS.
Порядок операций
Шаг 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.
б. Просмотрите список сборок и проверьте, соответствует ли время их выполнения заданному графику.
ВАРІАНТ № 3
Визначте основні ролі у впровадженні програмного забезпечення та дайте характеристику основних функцій.
У чому відмінність автоматичних і автоматизованих систем? Наведіть приклади.
Тестування програмного забезпечення.
Описати послідовність дій для структурування додатку ASP.NET у TFS
Наведіть приклад, та поясніть, конструкції програмного забезпечення, яка використовується в безвідходному та ресурсозберігаючому виробництві програмного забезпечення.
+***3.1. Визначте основні ролі у впровадженні програмного забезпечення та дайте характеристику основних функцій.
Ролі
в дослідних умовах:
application developers(розробники додатків)
build and release engineers(інженери які роблять білди та релізи?!)
release managers(реліз менеджери)
deployment coordinators(координатори впровадження)
у виробничому середовищі:
system administrator(системний адмін)
database administrator(адмін БД)
release coordinators(координатори релізу?)
operations project managers(хз як правильно перевести)
Основні функції
Випуск
Установка та активація
Відключення(деактивація)
Адаптація
Оновлення
Відстеження версій
Видалення
поперешняк======
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения:
Ролевой кластер |
Фокус |
Управление продуктом (роль: бизнес-аналитик) |
Получение отзывов и оценок заказчика; акт о приеме выполненной работы. |
Удовлетворение потребителя (роль: бизнес-аналитик) |
Обучение; управление календарным графиком обучения. |
Управление программой (роль: менеджер проекта) |
Сопоставление рамок проекта с поставленным решением; управление стабилизацией. |
Разработка (роль: разработчик) |
Разрешение проблем; поддержка эскалации. |
Тестирование (роль: тестер) |
Тестирование производительности. |
Управление выпуском (роль: релиз-менеджер) |
Управление внедрением; одобрение изменений. |
+3.2.У чому відмінність автоматичних і автоматизованих систем? Наведіть приклади.
АВТОМАТИЧЕСКАЯ СИСТЕМА - совокупность управляемого объекта и автоматических управляющих устройств, функционирующая самостоятельно, без участия человека.
Например, автоматические системы регулирования может быть регулирования уровня воды в котле паровой машины, система регулирования температуры в печи.
АВТОМАТИЗИРОВАННАЯ СИСТЕМА (AC) - совокупность управляемого объекта и автоматических управляющих устройств, в которых часть функций управления выполняет человек-оператор. Комплекс технических, программных, других средств и персонала, предназначенный для автоматизации различных процессов. В отличие автоматической системы не может функционировать без участия человека.
Автоматизированные системы управления, в отличие от автоматических систем управления, предполагают обязательным компонентом системы человека-оператора. Эти системы применяются для автоматизации как технологических процессов на производстве, так и для автоматизации умственного труда человека.
Примерами таких систем служат системы «1С-Предприятие 7.7 или 8.0», «Парус», «ИнФин», базы данных налоговой службы и пенсионного фонда, паспортного учета граждан, учета транспортных средств, системы абонентского учета и др. Есть еще один особый класс автоматизированных систем – экспертные системы. Это программы с базой данных, в какой либо профессиональной области, например, в медицине. Врач вводит симптомы болезни и результаты анализов. Система, выполняя программу, сравнивает полученную информацию со своей базой данных, формирует экспертное заключение и выдает диагноз и советы по лечению.
+3.3.Тестування програмного забезпечення.
Тестування - це перевірка відповідності ПЗ вимогам, здійснювана за допомогою спостереження за його роботою в спеціальних, штучно побудованих ситуаціях. Такого роду ситуації називають тестовими або просто тестами.
Тобто, тестування програмного забезпечення — це техніка контролю якості, що перевіряє відповідність між реальною і очікуваною поведінкою програми завдяки кінцевому набору тестів, які обираються певним чином. Це найбільш широко застосовуваний метод контролю якості.
Тестування може використовуватися для досить упевненого винесення оцінок про якості ПЗ. Для цього необхідно мати критерії повноти тестування, що описують важливість різних ситуацій для оцінки якості, а також еквівалентності й залежності між ними. Часто критерій повноти тестування задається за допомогою визначення еквівалентності ситуацій, що дає кінцевий набір класів ситуацій. Такий критерій називають критерієм тестового покриття, а відсоток класів еквівалентності ситуацій, що трапились під час тестування, - досягнутим тестовим покриттям.
Методи тестування:
-статичне тестування (пов'язане з аналізом результатів розробки програмного забезпечення - перевіряється вся документація, чи програма відповідає заданим критеріям та вимогам замовника.)
-динамічне тестування (передбачає експлуатацію програмного продукту - застосовується в процесі безпосереднього виконання программ - збираються та аналізуються дані про відмови та збої в роботі програми )
Техніки тестування (поділ за знанням системи:):
тестування «білої скриньки» (досліджуються внутрішні елементи програми і зв'язки між ними.)
тестування «чорної скриньки» (досліджується робота кожної функції на всій області визначення - основне місце програми тестів «чорної скриньки» — інтерфейс ПЗ);
тестування «сірої скриньки»
Рівні тестування (поділ за ступенем ізольованості компонентів):
блокове тестуванням (тестування повного класу, методу або невеликого програми, написаної одним програмістом або групою, що виконується окремо від інших частин системи).
модульне тестування (призначене для перевірки правильності окремих модулів, поза залежності від їх оточення)
Інтеграційне тестування (призначене для перевірки правильності взаємодії модулів деякого набору один з одним)
системне тестування (призначене для перевірки правильності роботи системи в цілому, її здатності правильно вирішувати поставлені користувачами задачі в різних ситуаціях)
Типи тестуваня (поділ видів тестування в залежності від мети):
функціональне;
нефункціональне
пов'язане зі змінами
За ступенем автоматизації тестування буває:
ручне
автоматизоване
напівавтоматизоване
За об'єктом тестування:
функціональне тестування
тестування продуктивності :
-навантажувальне тестування;
-стрес-тестування
-тестування стабільності;
тестування зручності використання
тестування інтерфейсу користувача
тестування безпеки
тестування локалізації
тестування сумісності
Типовий процес тестування:
Фази тестування. Реалізація тестування ділиться на три етапи:
Створення тестового набору
Прогін програми на тестах
Оцінка результатів виконання програми на наборі тестів
Методологія Rational Unified Process виділяє досить великий набір видів тестування. Їх можна з певною часткою умовності розділити таким чином:
Функціональне тестування (Function testing):
тестування цілісності даних (Data integrity testing);
тестування на різних платформах (Configuration testing);
тестування відмовостійкості (Failover & recovery testing);
тестування доступу (Security testing);
інсталяційне тестування (Installation testing);
тестування користувальницького інтерфейсу (User interface testing).
+3.4.Описати послідовність дій для структурування додатку ASP.NET у TFS
Последовательность операций
Шаг 1 – Создание локальных папок Веб-проекта
Шаг 2 – Создание пустого решения
Шаг 3 – Добавление Веб-сайта в решение
Шаг 4 – Добавление библиотеки классов (не обязательно)
Шаг 5 – Проверка структуры своего решения
Шаг 6 – Проверка локальной структуры каталогов
Шаг 7 – Добавление своего решения в систему контроля версий
Шаг 1 – Создание локальных папок Веб-проекта
На данном этапе вы создаете на своем компьютере соответствующую локальную структуру каталогов для своего Веб-проекта. Чтобы обеспечить единый подход для коллективной разработки и хорошую организацию проектов на своем компьютере, сгруппируйте весь разрабатываемый исходный код всех групповых проектов, над которыми вы работаете, в одну корневую папку, например, C:\DevProjects.
1.Создайте папку верхнего уровня, например, C:\DevProjects.
Шаг 2 – Создание пустого решения
Чтобы создать Веб-приложение ASP.NET, начните с явного создания файла решения Visual Studio (.sln) и затем добавьте в него свой Веб-сайт и все необходимые дополнительные проекты, например, библиотеки классов. Вот как создается решение в папке верхнего уровня C:\DevProjects по шагам.
1. В меню File выберите опцию New и щелкните Project.
2. Разверните Other Project Types (Другие типы проектов) и выберите Visual Studio Solutions.
3. Выберите Blank Solution.
4. Назовите свое решение MyWebAppSln.
5. Задайте свойству Location (Местоположение) значение C:\DevProjects и щелкните OK.
Таким образом, будет создана папка C:\DevProjects\MyWebAppSln. Visual Studio добавляет в эту папку файл решения (.sln) и файл пользовательских параметров решения (.suo). Обратите внимание, что впоследствии в Шаге 7 в систему контроля версий добавляется только файл .sln.
Шаг 3 – Добавление Веб-сайта в решение
На данном этапе вы добавляете Веб-сайт ASP.NET в свое решение. Эта процедура немного варьируется в зависимости от типа Веб-сайта, т.е. от того создается ли Веб-сайт, располагающийся в локальной файловой системе и использующий Веб-сервер разработки Visual Studio, или Веб-сайт на Web-сервере, использующий Internet Information Services (IIS).
Файловая система
Чтобы добавить в свое решение Веб-проект, располагающийся в локальной файловой системе:
1. В Solution Explorer щелкните правой кнопкой мыши Solution MyWebAppSln, выберите Add и щелкните New Web Site.
2. В диалоговом окне Add New Web Site (Добавить новый Веб-сайт) не меняйте значения Location (по умолчанию задана File System) и Language (по умолчанию задан Visual C#).
3. Задайте для Location каталог
C:\DevProjects\MyWebAppSln\Source\MyWebAppWeb.
4. Щелкните OK, чтобы закрыть диалоговое окно Add New Web Site.
Обратите внимание, что суффикс «Web» в этом примере используется для четкого обозначения папки как корневой папки Веб-сайта.Web-сервер
Создание Веб-сайта ASP.NET на базе Web-сервера IIS, доступ к которому при разработке будет осуществляться по протоколу HTTP, начните с явного создания виртуального каталога, чтобы каталог Веб-сайта располагался в заданном местополжении, а не в папке \inetpub\wwwroot.
Чтобы создать виртуальный каталог своего Веб-сайта:
1. В Windows Explorer перейдите к C:\DevProjects\MyWebAppSln\Source.
2. Создайте в этом каталоге новую папку MyWebAppWeb.
3. Щелкните правой кнопкой мыши MyWebAppWeb и выберите Sharing and Security (Совместное использование и безопасность).
4. Выберите вкладку Web Sharing (Доступ через Веб).
5. Щелкните Share this folder (Открыть общий доступ к папке).
6. Не меняйте для свойства Alias (Псевдоним) значение MyWebAppWeb, оставьте заданные по умолчанию Access permissions (Права доступа) и Application permissions (Права приложения) и щелкните OK.
7. Дважды щелкните OK.
Чтобы добавить Веб-сайт в свое решение:
1. В Solution Explorer щелкните правой кнопкой мыши Solution MyWebAppSln, выберите Add и щелкните New Web Site.
2. В диалоговом окне Add New Web Site задайте Location значение HTTP и не меняйте для Language значение по умолчанию Visual C#.
3. Задайте для Location URL http://localhost/MyWebAppWeb.
4. Щелкните OK, чтобы закрыть диалоговое окно Add New Web Site.
Visual Studio добавляет ваши файлы Default.aspx и Default.aspx.cs в папку
C:\DevProjects\MyWebAppSln\Source\MyWebAppWeb и создает дочерние папки Bin и App_Data.
Шаг 4 – Добавление библиотеки классов (не обязательно)
Если в Веб-приложении используются дополнительные библиотеки классов,
добавьте их следующим образом:
1. В Solution Explorer щелкните правой кнопкой мыши свое решение MyWebAppSln, выберите Add
и щелкните New Project.
2. Выберите тип проекта Visual C# и шаблон Class Library.
3. Введите имя ClassLibrary, в качестве Location задайте
C:\DevProjects\MyWebAppSln\Source и щелкните OK.
Все новые проекты будут добавляться в папку Source.
Шаг 5 – Проверка структуры своего решения
В Solution Explorer проверьте структуру своего решения.
Шаг 6 – Проверка локальной структуры каталогов
В Windows Explorer проверьте свою локальную структуру каталогов.
Шаг 7 – Добавление своего решения в систему контроля версий
На данном этапе вы добавляете свое решение в систему контроля версий TFS.
1. Щелкните правой кнопкой мыши свое решение и выберите Add Solution to Source Control.
2. В диалоговом окне Add Solution MyWebAppSln to Source Control выберите свой групповой проект.
3. В диалоговом окне щелкните Make New Folder (Создать новую папку) и назовите новую папку Main.
4. Выберите только что созданную папку Main и щелкните Make New Folder,
назовите новую папку Source.
5. Выберите только что созданную папку Source и щелкните OK.
6. Проверьте структуру своей папки в системе контроля версий, дважды щелкнув
Source Control в Team Explorer.
7. Здесь вы можете просматривать ожидающие регистрации изменения и регистрировать исходные файлы решения на сервере. Для этого в меню View Menu (Меню просмотра) выберите Other Windows (Другие окна) и щелкните Pending Changes. Выберите свой проект и исходные файлы, которые необходимо зарегистрировать, введите комментарий к регистрации изменений и щелкните Check In.
+3.5.Наведіть приклад, та поясніть, конструкції програмного забезпечення, яка використовується в безвідходному та ресурсозберігаючому виробництві програмного забезпечення.
Ресурсозберігаюче виробництво – це виробництво і реалізація продуктів з мінімальною витратою речовини та енергії на всіх етапах виробничого циклу і з найменшою дією на людину та природні системи.
Основою ресурсозберігаючого виробництва є ресурсозберігаючі технології.
Існуючі ресурси інженерії програмного забезпечення (принципи, процеси, конструкції) відіграють важливу роль і можуть використовуватися як основа для побудови ресурсозберігаючих і безвідходних технологій розробки і супроводу програмного забезпечення.
Першою такою конструкцією була підпрограма, яку розглядали як засіб скорочення тексту програми. Гнучкість конструкції забезпечувала параметризація. Незабаром погляд на підпрограму почав змінюватися, і її стали розглядати, як засіб структурної організації програм.
Пристосування програми до очікуваних змін постановки завдання або супроводження зводилась до заміни тіла підпрограм або до зміни значень деяких фактичних параметрів у зверненні до подпрограммам. Тому, підпрограми застосовувалися як процедурні абстракції, абстракції виконання (закриті підпрограми) або шаблони (відкриті підпрограми).
В якості застосування методу підпрограми використовувалося підпрограмне (процедурне) програмування.
З метою поліпшення конструкцій для реалізації абстрактних типів даних були створені модуль і клас (модульне та об’єктно-орієнтоване програмування відповідно).
Методи, принципи, конструкції екологічного ПЗ
№ з/п |
Методи/ ресурси |
Програмне (процедурне) програмування |
Об’єктно-орієнтоване програмування |
Модульне програмування |
1 |
Конструкції |
Підпрограма (закрита, відкрита), шаблон |
Клас (С, С++) |
Модуль (Модула 2,3), пакет (Ada) |
2 |
Принципи реалізації конструкцій |
Параметризація |
Поліморфізм, наслідування, класифікація |
Роздільна компіляція |
3 |
Принципи використання конструкцій |
Процедурна абстракція, абстракція виконання, шаблонування |
Класифікація |
Композиція |
4 |
Фундаментальна абстракція |
Абстрактний тип даних |
||
ВАРІАНТ № 4
Концепція ноосфери.
Виявлення недоліків та помилок у паралельному програмному коді.
Управління проектами в TFS: шаблон процесу, складові шаблону.
Побудувати графи арифметичних виразів. Перетворити арифметичні вирази в зворотний польський запис
18 – 6 / 3 + 1 (18 – 6) / 3 + 1 (18– 6) / (3 + 1)
Підготовте приклад в якому визначаються основні етапи життєвих циклів програмного забезпечення яке підлягає розробці та дайте їх характеристику.
+4.1.Концепція ноосфери.
Ноосфера — імовірно нова, вища стадія еволюції біосфери, становлення якої пов'язано з розвитком суспільства, надає глибоке вплив на природні процеси.
Это биосфера, разумно управляемая человеком.
Ноосфера является высшей стадией развития биосферы, связанной с возникновением и становлением в ней цивилизованного общества, с периодом, когда разумная деятельность человека становится главным фактором развития на Земле.
Поняття «ноосфера» походить від грецьких слів «ноос» (розум) і «сфера» (куля) й означає якісно новий стан біосфери Землі (її перебудови) та навколишнього простору (а отже, нової оболонки Землі), що формується під впливом розумової та фізичної діяльності людства, яку можна порівняти з могутніми геологічними процесами.
По мнению Вернадского, основными предпосылками создания ноосферы являются:
1) Человечество стало единым целым. Мировая история охватила как единое целое весь земной шар, совершенно покончила с уединенными, мало зависимыми друг от друга культурными историческими областями прошлого. Сейчас «нет ни одного клочка Земли, где бы человек не мог прожить, если б это было ему нужно».
2) Преобразование средств связи и обмена. Ноосфера - это единое организованное целое, все части которого на самых различных уровнях гармонично связаны и действуют согласованно друг с другом. Необходимым условием этого является быстрая, надежная, преодолевающая самые большие расстояния связь между этими частями, постоянно идущий материальный обмен между ними, всесторонний обмен информацией.
3) Открытие новых источников энергии. Создание ноосферы предполагает столь коренное преобразование человеком окружающей его природы, что ему никак не обойтись без колоссальных количеств энергии.
4) Подъем благосостояния трудящихся. Ноосфера создается разумом и трудом народных масс.
5) Равенство всех людей. Охватывая всю планету как целое, ноосфера по самому своему существу не может быть привилегией какой-либо одной нации или расы. Она дело рук и разума всех народов без исключения.
6) Исключение войн из жизни общества. В наше время война, угрожая самому существованию человечества, встала как самое большое препятствие на пути к ноосфере. Отсюда следует, сто без устранения этой преграды достижение ноосферы практически невозможно и, напротив, уничтожение угрозы войны будет означать, что человечество сделало крупный шаг к созданию ноосферы.
Ноосфера, по мнению Вернадского, - это новая геологическая оболочка Земли, создаваемая на научных основаниях. Академик утверждал, что эти социальные реформы и катаклизмы сделают «переход к ноосфере» необратимым.
Водночас поняття ноосфери нерозривно пов’язане з поняттям «жива речовина», яке, за Вернадським, позначає сукупність усіх живих організмів біосфери (кількісно вираженої в хімічному складі, масі й енергії), що переробляють і переміщують різні види речовин (тверду, рідинну й газоподібну), акумулюють і перетворюють космічне випромінювання. Складовими елементами живої речовини вчений називає всю водну оболонку Землі, нижню частину атмосфери (в якій існують люди, птахи, комахи, звірі), а також літосферу (верхню частину твердої оболонки Землі, в якій живуть бактерії).
В структурі ноосфери і биосфери Вернадський виділяв «сім видів речовин»:
живе,
біогенне (те, що виникло із живого),
косне (возникшее из неживого),
біокосне (частково живе, частково неживе),
радіоактивне,
атомарно-розсіяне,
космічне.
Проте західними вченими «теорія семи видів речовин» не була принята, хоча і знайшла своє продовження у трудах радянських вчених.
+4.2.Виявлення недоліків та помилок у паралельному програмному коді.
Методики пошуку помилок у паралельних програмах, як і в послідовних можна розділити на динамічний аналіз, статичний аналіз, перевірку на основі моделей і доказ коректності програми.
Найбільший практичний результат представляють лише два перших методу.
За допомогою статичного аналізатору коду PVS-Studio провести статистичне дослідження проекту, розробленого на С++ (обрати проект в мережі Інтернет з відкритим кодом), обґрунтувати отримані результати та оволодіти теоретичними знаннями.
PVS-Studio - статичний аналізатор коду, призначений для розробників сучасних ресурсоємних застосувань. Об'єднуючи в собі можливості аналізу 64-бітової коду з модуля Viva64, паралельної коду з модуля VIVAMP і аналізу загального призначення. PVS-Studio дозволяє розробляти, тестувати, виконувати міграцію і верифікацію, і, звичайно ж, створювати додатки на C/C++/C++0x з високим рівнем надійності.
PVS-Studio дозволяє виявляти в початковому коді програм на C/C++/C++0x наступні типи дефектів:
помилки міграції 32-бітових застосувань на 64-бітові системи;
помилки, що виникають при розробці нових 64-бітових застосувань;
неоптимальне використання пам'яті в 64-бітових програмах унаслідок особливостей вирівнювання;
помилки в паралельних програмах, пов'язані з незнанням синтаксису технології OPENMP;
помилки в паралельних програмах, пов'язані з недостатнім знанням принципів розпаралелювання коду з використанням OPENMP;
помилки із-за некоректної роботи з пам'яттю в паралельному коді (незахищений доступ до загальної пам'яті, відсутність синхронізації, неправильний режим доступу до змінних, і т. п.).
Всі ці групи дефектів виникають як в нових застосуваннях, так і в старих при спробі або перенести їх на 64-бітову платформу, або під час розпаралелювання коду.
Використовуючи аналізатор PVS-Studio можна підвищити якість програмного продукту, скоротити час на розробку і тестування рішення, а також забезпечити безпеку коду.
Пошук дефектів проводиться за допомогою технології статичного аналізу, що дозволяє виявляти проблеми без запуску додатку і незалежно від робочого оточення. Це особливо важливо для діагностики помилок в паралельних програмах.
Також для верифікації паралельних програм Java використовують статичний аналізатор Chord.
Також для виявлення помилок у паралельному коді використовують OpenMP - набір директив компілятора, бібліотечних процедур і змінних оточення, які призначені для програмування багатопоточних додатків на багатопроцесорних/багатоядерних системах із загальною пам'яттю.
+4.3.Управління проектами в TFS: шаблон процесу, складові шаблону.+
Шаблон процесса — это независимый набор инструкций, описывающих методологию разработки ПО для команд разработчиков.
В шаблон процесса включаются следующие элементы:
- Руководство по процессу Предоставляется для каждого шаблона и со-держит контекстно-зависимую информацию, справку и указания членам команды, нуждающимся в помощи и понимании определенной деятель-ности. Руководство по выполнению процесса интегрировано в Visual Studio Help System.
- Шаблоны документов. Позволяют членам команды единообразно создавать новые документы (спецификации, оценки рисков и планы проектов).
- Рабочие элементы и последовательность операций. У рабочих элементов имеется собственный набор полей и правил, определяющих последовательность операций рабочего элемента и распределение работ между членами команды.
- Группы безопасности. Используются для определения прав по управлению и изменению отчетов, результатов работы, например, исходного кода и документации, и рабочих элементов. Администрировать группы безопасности проекта может его руководитель, для этого ему не обязательно быть администратором Windows.
- Политики возврата после правки. Используются для применения правил и порогов качества ко всему коду, возвращаемому в систему управления исходным кодом. Например, можно поставить условие, что весь возвращаемый код должен отвечать определенному критерию, скажем, соответствовать корпоративным стандартам написания кода, или должен подвергаться модульному тестированию.
- Отчеты. Используются для мониторинга исполнения процессов и текущего состояния проекта. В VSTS встроено множеством отчетов, включая отчеты о качестве кода, о соблюдении графика работ, об эффективности тестирования и др. Можно создавать собственные отчеты и настраивать существующие.
+4.4.Побудувати графи арифметичних виразів. Перетворити арифметичні вирази в зворотний польський запис 18 – 6 / 3 + 1 (18 – 6) / 3 + 1 (18– 6) / (3 + 1)
оригінал: 18-6/3+1
зворотний польський запис 18 6 3 / - 1 +
оригінал: (18 – 6) / 3 + 1
зворотний польський запис 18 6 – 3 / 1 +
оригінал: (18– 6) / (3 + 1)
зворотний польський запис 18 6 – 3 1 + /
+***4.5.Підготовте приклад, в якому визначаються основні етапи життєвих цикл в програмного забезпечення, яке підлягає розробці та дайте їх характеристику.
Процесс разработки web-сайта. Стадии жизненного цикла и их особенности
Как и традиционная разработка программного обеспечения, процесс разработки web-сайтов делится на различные стадии жизненного цикла, что позволяет команде действовать более эффективно, придерживаться стандартов и процедур, которые помогут в свою очередь достичь лучшего качества финального продукта.