16. Проектування систем реального часу: поняття класифікація систем реального часу

Система реального часу – це програмна система, правильне функціонування якої залежить від результатів її роботи та від відрізка часу, за який отримано результат. М’яка система реального часу – це система, в якій операції видаляються, якщо протягом певного відрізка часу не виданий результат. Жорстка – це система, операції якої стаються некоректними, тобто виробляється сигнал про помилку, якщо протягом певного інтервалу часу результат не виданий. Процес проектування систем реального часу включає в себе проектування обладнання (апаратури) спеціального призначення та проектування ПЗ. Апаратні компоненти забезпечують більш високу продуктивність, ніж еквівалентне їм (по виконуваним функціям) ПЗ. Етапи проектування систем реального часу:

1. Визначення багатьох вхідних сигналів, які будуть оброблятися системою та відповідних їм системних реакцій, тобто сигналів у відповідь.

2. Для кожного вхідного сигналу та відповідного йому сигналу у відповідь обчислюються часові межі.

3. Обєднання процесів обробки вхідних сигналів та сигналів у відповідь у вигляді сукупності паралельних процесів.

4. Розробка алгоритмів, які виконують необхідні обчислення для всіх сигналів

5. Розробка часового графіка роботи системи.

6. Збірка системи, яка працює під керуванням диспетчера.

16. Метод покомпонентної розробки з повторним використанням компонентів

Метод проектування ПЗ, оснований на повторному використанні, передбачає максимальне використання вже наявних програмних об’єктів. Переваги: підвищення надійності, зменшення проектних ризиків, ефективне використання спеціалістів, дотримання стандартів, прискорення розробки. Недоліки: підвищення вартості супроводження системи, недостатня інструментальна підтримка, синдром «винайдення «велосипеду», пошук та адаптація компонентів.

16. Проектування інтерфейсу користувача: принципи, взаємодія з користувачем, представлення інформації

Принципи: врахування знань користувача; узгодженість; мінімум несподіваного; здатність до відновлення; довідка. Взаємодія з користувачем – це забезпечення введення команди в програму. Стилі взаємодії: безпосереднє маніпулювання; вибір з меню; заповнення форм; командна мова; природна мова. Представлення інформації. Дані в системі можуть представлятися: у вигляду тексту; таблиць; діаграм тощо.

16. Проектування інтерфейсу користувача: засоби підтримки користувача, оцінювання інтерфейсу

Засоби підтримки користувача складають: повідомлення системи; діалогова довідка системи; документацій на система. Повідомлення про помилку повинне бути коротким, ввічливим и конструктивним. Не слід використовувати звукові сигнали. Довідкова система повинна забезпечувати користувачу декілька різних точок входу: на верхньому рівні її структури; за допомогою вікон-повідомлень; через опис конкретної команди. Зручність використання інтерфейсу може оцінюватись кількісно, через числові показники і якісно. Методи оцінювання інтерфейсу користувача: анкети користувача; нагляд за роботою користувача з наступним обговоренням; відео нагляд; додавання в систему програмного коду, що збирає інформацію про помилки.

16. Складові функціональної надійності програмних систем: працездатність, безвідмовність

Функціональну надійність комп’ютерних систем можна визначити ступенем довіри до них, тобто впевненістю, що система буде працювати так, як передбачається, і що збоїв не буде. Працездатність – властивість системи виконувати свої функції в будь-який час експлуатації. Безвідмовність – властивість системи коректно працювати увесь заданий період експлуатації.

16. Складові функціональної надійності програмних систем: безпечність і захищеність

Безпечність – властивість системи, яка гарантує, що вона безпечна для людей та навколишньої середи. Захищеність – властивість системи протидіяти випадковим або навмисним вторгненням в неї.

16. Поняття і особливості розробки критичних систем

Критичні системи – це системи, відмови яких можуть призвести до значних економічних втрат, фізичних пошкоджень чи створенню загрози людському життю. Функціональна надійність – це необхідна вимога до критичних систем. Типи критичних систем:

1. Системи, критичні щодо забезпечення безпеки (відмова призводить до руйнацій, загрози життю людини тощо).

2. Системи, критичні для цільового призначення (відмова призведе до помилки в діях, направлених на забезпечення певної цілі).

3. Системи, критичні для бізнесу.

16. Поняття верифікації і атестації програмних систем. Основні методики

Верифікація та атестація – це процеси перевірки і аналізу в ході яких перевіряється відповідність ПЗ своїй специфікації і вимогам замовника. Верифікація відповідає на питання чи правильно створена система. Атестація – чи правильно працює система. При верифікації та атестації використовуються 2 основні методики перевірки: статичні методи – це методи, яким не потрібно виконувана програма і які перевіряються документацію, схеми і програмний код; динамічні методи – застосовуються тільки до виконуваної програми.

16. Планування верифікації (В) і атестації (А) програмного забезпечення. Інспектування програмних систем

Через велику вартість А та В необхідне їх планування. В процесі планування необхідні: співвідношення між статичним і динамічним методами перевірки програм; стандартні процедури інспекції і тестування ПЗ; затвердження технологій перевірки програми; скласти план тестування програми. За 1 сеанс інспектування виявляють цілу множину дефектів. Основна мета інспекції – виявлення дефектів програми, а не дослідження загальних проблем проекту. Процес інспекції – це формалізація програми, що виконується невеликою групою фахівців: автор програми; інспектор; координатор; керівник групи. Процес інспекції включає: планування; попередній перегляд; індивідуальна підготовка; збори інспекційної групи; виправлення помилок; доробка.

39. Метрики якості програмного забезпечення

Метрика якості ПЗ – кількісний масштаб і метод, які можуть бути використані для визначення значення ознаки, прийнятої для конкретної програмної продукції. Метрика визначається як міра ступеня володіння властивістю, яка має числове значення. Взагалі, метрика ПЗ – це міра, яка дозволяє одержати числове значення деякої властивості ПЗ або його специфікацій. Основним стандартом якості в області інженерії ПЗ є стандарт, який визначає номенклатуру, атрибути і метрики вимог якості ПЗ. Цей стандарт є одним з визначальних факторів при моделюванні якості ПЗ. Спочатку оцінюються атрибути ПЗ; обирається метрика, градуюється шкала оцінки залежно від можливих ступенів відповідності атрибуту накладеним обмеженням. Набір "виміряних" атрибутів представляє собою критерій для оцінки підхарактеристики та характеристик. Для визначення загального рівня розвитку технологічних процесів в програмних організаціях розробили спеціальну систему оцінки зрілості технологічних процесів в софтверних організаціях – модель Capability Maturity Model (CMM), засновану на так званих рівнях зрілості (maturity levels). Таких рівнів зрілості в СММ п’ять, і кожен з них характеризує певний ступінь якості програмних продуктів: 1) початковий (initial) – відсутнє стабільне середовище розробки і супроводження; не витримуються терміни випуску продуктів; всі сили спрямовано на кодування і тестування програми (75 % софтверних організацій); 2) повторюваний (repeatable) – жорстке керування, планування і контроль; акцент робиться на початкові вимоги, методи оцінки і конфігураційний менеджмент (15 % софтверних організацій); 3) фіксований (defined) – процеси повністю документовані, стандартизовані та інтегровані в єдиний технологічний потік (8 % софтверних організацій); 4) керований (managed) – намагання оцінити якість процесів і готового продукту кількісно; для контролю над процесами використовуються метрики (1.5 % софтверних організацій); 5) оптимізований (optimizable) – намагання покращення роботи, керуючись кількісними критеріями якості; основна мета – випуск бездефектних продуктів, в яких помилки усунені ще на стадії внутрішнього тестування (0.5 % софтверних організацій). 6) 5-й рівень СММ вимагає постійного самостійного покращення процесу. Для покращення процессу керування проектом його ефективність вимірюється за допомогою метрик процесу. Ці метрики дозволяють

виміряти ефективність організації процесу, а також аналізу вимог, проектування, програмування і тестування.

40. Планування і контроль якості

Процес планування є ітеративним і базується на змісті, вимогах і оцінціздійсненності проекту. З точки зору автора, тут варто нагадати, що різні фазипроекту перекриваються і разом з визначеннямзмісту, деталізацією вимог і проведенням аналізу здійсненності, паралельно зцим сам розроблюваний план проекту в тій чи іншій мірі деталізується, і формуєтьсяпевний комплекс робіт, оцінюються необхідні ресурси і часові межі робіт, іт.д. При плануванні також оцінюються івідбираються відповідні процеси життєвого циклу. Там де це доречно, проектдеталізується у вигляді структурної декомпозиції робіт, для яких відзначені асоційовані з їхзавершенням результати та їх характеристики. Такі характеристики, зазвичай, пов'язані з питаннямиякості та іншими встановленими атрибутами вимог, дотриманням термінів виконанняробіт, зусиллями, вартістю і т.д. Ресурси розподіляються по задачах таким чином, щоб забезпечити оптимальну продуктивність (на персональному, командному та організаційному рівні),використання засобів (інфраструктури, інструментів, ...) та обладнання, а також суворедотримання проектного розкладу. Також має проводитися управління ризиками і, зокрема,необхідно визначити "профіль ризиків", прийнятий відповідними зацікавленимиособами. Як складова частина планування, необхідно визначити необхідні процесизабезпечення якості у формі відповідних процедур та обов'язків заоцінці, перевірці, атестації та аудиту якості. Безумовно, що мають бути визначені процеси та обов'язкив частини управління планом проекту, його оцінка та порядок перегляду різних аспектів проекту. Нарівні з іншими аспектами ведення проекту, має бути визначено як проект буде управлятися і як буде управлятися план проекту. Звітність, моніторинг і контроль проекту повинні відповідати обраному процесу програмної інженерії та сутності проекту, відображаючи також у вигляді різних артефактів саме те, що буде використовуватися в процесі управління. При цьому, в оточенні, яке змінюється, принципово важливо, щоб і сам план проекту був керований. Це вимагає суворого дотримання планів, які повинні бути систематично направляємi, контрольовані, оценіваємi, за якими буде вестися звітність. Плани, асоційовані з іншими процесами підтримки, орієнтованими на управління, також повинні бути керовані відповідним чином

(наприклад, це стосується питань документування, конфігураційного управління і вирішення проблем).

Якість визначається в термінах атрибутів, значущих для даного конкретного проекту та / або асоційованого з ним продукту. Атрибути можуть виражатися як якісно, так і кількісно. Ці характеристики якості визначаються в специфікації вимог до програмного забезпеченню Відправною точкою для дотримання якості є набір індикаторів, відповідних очікуванням зацікавлених осіб. На цій стадії також специфікуються процедури, пов'язані з проведенням діяльності щодо забезпечення якості протягом всіх процесів життєвого циклу і для перевірки та атестації (V & V - verification and validation) для одержуваного продукту і всіх активів (артефактів) проекту.