
- •Лекція 1. Тема: ядра знань swebok
- •1.1. Аналіз і характеристика областей знань swebok
- •1.1.1 Основи програмних вимог (Software Requirements)
- •1.1.2. Проектування пз (Software design)
- •1.1.3. Конструювання пз (Software Construction)
- •1.1.4 Тестування пз (Software Testing)
- •1.1.5 Супровід пз (Software maintenance)
- •1.1.6. Управління конфігурацією пз (Software Configuration Management– scm)
- •1.1.7. Управління інженерією пз (Software Engineering Management)
- •1.1.8. Процес інженерії пз (Software Engineering Process)
- •1.1.9. Методи і засоби інженерії пз (Software Engineering Tools and Methods)
- •Лекція 2. Тема: життєвий цикл і етапи розробки програмного забезпечення
- •Лекція 3. Тема: еволюція моделей життєвого циклу програмного забезпечення
- •1.6. Прискорення розробки пз.
- •Лекція 4. Тема: оцінка якості процесів створення програмного забезпечення
- •Лекція 5. Тема: визначення вихідних даних для проектування програмного забезпечення
- •5.1 Визначення вимог до пз
- •5.2 Формування і аналіз вимог
- •5.2.1 Опорні точки зору
- •5.2.2 Сценарії
- •5.2.3 Етнографічний метод
- •5.3 Специфікація вимог
- •5.4 Атестація вимог
- •5.5 Класифікація програмних продуктів за функціональною ознакою
- •5.6 Основні експлуатаційні вимоги до програмних продуктів
- •5.7 Передпроектні дослідження предметної області
- •Лекція 6. Тема: розробка технічного завдання
- •2. Підстави для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •5. Вимоги до програмної документації
- •1. Вступ
- •2. Підстава для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •4.1. Вимоги до функціональних характеристик
- •Лекція 7. Тема: принципові рішення початкових етапів проектування
- •Контрольні питання і завдання
- •Аналіз вимог і визначення специфікацій програмного забезпечення при структурному підході
- •Лекція 8. Тема: Специфікації програмного забезпечення при структурному підході
- •Flow-форми
- •Діаграми Насси-Шнейдермана
- •Контрольні питання та завдання:
- •Лекція 9. Тема: діаграми потоків даних
- •Словник даних
- •Вміст словника даних
- •Лекція 10. Тема: діаграми «сутність-зв’язок»
- •Лекція 11. Тема: приклади побудови діаграм та специфікації процесів
- •Лекція 12 Тема: діаграми переходів станів
- •13.1. Структурна схема майбутнього програмного забезпечення
- •13.2 Використання методу покрокової деталізації для проектування структури програмного забезпечення
- •13.3 Структурні карти Константайна
- •13.4.Структурні карти Джексона
- •13.5 Характеристики хорошої моделі реалізації
- •Зчеплення
- •Зв’язаність
- •13.6 Функціональна схема
- •Лекція 14. Тема: методології структурного аналізу і проектування
- •Контрольні питання та завдання
- •Лекція 15. Тема: синтаксис діаграм
- •Контрольні питання та завдання
- •Лекція 16. Тема: Синтаксис діаграм
- •Збір інформації
- •Контрольні питання та завдання:
- •Лекція 17. Тема: побудова sadt-діаграм
- •17.2. Побудова sadt-діаграми для процесу “Побудова таблиць/графіків функцій однієї змінної”
- •Типи зв'язків між функціями
- •Лекція 18. Тема: доповнення до діаграм і моделей
- •Критерії оцінки і вибору
- •Функціональні характеристики
- •3. Загальні функції:
5.6 Основні експлуатаційні вимоги до програмних продуктів
Експлуатаційні вимоги визначають деякі характеристики розроблюваного програмного забезпечення, що виявляються в процесі його функціонування. До таких характеристик відносять:
• правильність - функціонування відповідно до технічного завдання;
• універсальність - забезпечення правильної роботи за будь-яких допустимих даних та захисту від неправильних даних;
• надійність (перешкодозахищеність) - забезпечення повної повторюваності результатів, т. е. забезпечення їх правильності при наявності різного роду збоїв;
• перевіряння - можливість перевірки отриманих результатів;
• точність результатів - забезпечення похибки результатів не вище заданої;
• захищеність - забезпечення конфіденційності інформації;
• програмна сумісність - можливість спільного функціонування з іншим програмним забезпеченням;
• апаратна сумісність - можливість спільного функціонування з деяким Прослухати
обладнанням;
• ефективність - використання мінімально можливої кількості ресурсів технічних засобів, наприклад, часу мікропроцесора або обсягу оперативної пам'яті;
• здатність до адаптації - можливість швидкої модифікації з метою пристосування до мінливих умов функціонування;
• повторна входимість - можливість повторного виконання без перезавантаження з диска;
• реєнтерабельність - можливість «паралельного» використання декількома процесами.
Правильність є обов'язковою вимогою для будь-якого програмного забезпечення: все, що зазначено в технічному завданні, неодмінно має бути реалізовано. Проте слід розуміти, що ні тестування, ні верифікація не доводять правильності створеного програмного продукту. У цьому зв'язку звичайно говорять про певну ймовірність наявності помилок. Природно, чим більша відповідальність перекладається на комп'ютерну систему, тим менше повинна бути ймовірність як програмного, так і апаратного збою. Наприклад, очевидно, що ймовірність неправильної роботи для системи управління атомною електростанцією повинна бути близька до нуля.
Вимога універсальності також зазвичай входить до групи обов'язкових. Нічого хорошого немає в тому, що розроблена система видає результат для некоректних даних або аварійно завершує свою роботу на деяких наборах даних. Однак, як уже згадувалося вище, довести універсальність порівняно складної програми, так само, як її правильність, неможливо, тому має сенс говорити про ступінь універсальності програми.
Практично, чим вище вимоги до правильності та універсальності програмного забезпечення, тим вище і вимоги до його надійності. Джерелами перешкод можуть бути всі учасники обчислювального процесу: технічні засоби, програмні засоби та люди. Технічні засоби схильні до збоїв, наприклад, із-за різких стрибків напруги живлення або перешкод при передачі інформації по мережах. Програмне забезпечення може містити помилки. А люди можуть помилятися при введенні вихідних даних.
Сучасні обчислювальні пристрої вже досить надійні. Збої технічних засобів, як правило, реєструються апаратно, відповідно результати обчислень у цьому випадку відновлюються. У разі тривалих обчислень, як правило, проміжні результати зберігають (прийом отримав назву «створення контрольних точок»), що дозволяє при виникненні збою продовжити обчислення з даними, записаними в останній контрольній точці.
Передача інформації по мережах також апаратно контролюється, крім того, зазвичай застосовується спеціальне завадозахищене кодування, яке дозволяє знаходити і виправляти помилки передачі даних. Однак повністю виключити помилки технічних засобів неможливо, тому в тих випадках, коли вимоги до надійності високі, зазвичай використовують дублювання систем, при якому дві системи вирішують одну і ту ж задачу паралельно, періодично звіряючи отримані результати.
Часто самим «ненадійним елементом» сучасних систем є люди. Вже добре відомо, що в умовах монотонної роботи за пультом обчислювальної установки оператори допускають велику кількість помилок. Відомі й засоби, що дозволяють знизити кількість помилок в конкретних ситуаціях. Так, там, де це можливо, використовують введення надлишкової інформації, що дозволяє виконувати перевірки правильності даних, що вводяться. Крім цього, широко використовують всякого роду підказки, коли інформацію необхідно не вводити, а вибирати з деякого списку і т. п.
Підвищені вимоги до надійності пред'являють при розробці систем управління, які функціонують в режимі реального часу, коли обчислення виконуються паралельно з технологічними процесами. Суттєва ця вимога і для науково-технічних систем і баз даних.
Для забезпечення перевіряємості слід документально фіксувати вихідні дані, встановлені режими та іншу інформацію, яка впливає на отримувані результати. Особливо це суттєво у випадках, коли дані надходять безпосередньо від давачів. Якщо такі дані не виводити разом з результатами, то останні не можна буде перевірити.
Точність або величина похибки результатів залежить від точності вихідних даних, ступеня адекватності використовуваної моделі, точності обраного методу і похибки виконання операцій у комп'ютері. Вимоги до точності результатів зазвичай найбільш жорсткі для систем управління технологічними процесами (наприклад, хімічними) і систем навігації (наприклад, система управління стиковкою космічних апаратів).
Забезпечення захищеності (конфіденційності) інформації, що використовується проектованою системою, окрема і в умовах наявності мереж досить складне завдання. Крім чисто програмних засобів захисту, таких як кодування інформації і ідентифікація користувача, для забезпечення захищеності використовують також спеціальні організаційні прийоми. Найбільш жорсткі вимоги пред'являються до систем, в яких зберігається інформація, пов'язана з державною і комерційною таємницею.
Вимога програмної сумісності може варіюватися від можливості спільної установки з зазначеним програмним забезпеченням до забезпечення взаємодії з ним, наприклад обміну даними і т. п. Найчастіше доводиться забезпечувати функціонування програмного забезпечення під керуванням заданої операційної системи. Однак може знадобитися передбачити отримання даних з якоїсь програми або передачі деяких даних їй. У цьому випадку необхідно точно обумовити формати переданих даних.
Вимогу апаратної сумісності в основному формулюють у вигляді мінімально можливої конфігурації обладнання, на якому буде працювати програмне забезпечення.
Якщо передбачається використання нестандартного обладнання, то для нього повинні бути вказані інтерфейси або протоколи обміну інформацією. При цьому для операційних систем класу Windows нестандартними вважають пристрої, для яких в системі відсутні драйвери - програми, що забезпечують взаємодію пристрої з операційною системою.
Ефективність системи зазвичай оцінюється окремо по кожному ресурсу обчислювальної установки. Часто використовують наступні критерії:
• час відповіді системи (зазвичай віднесене до швидкодії використовуваного обладнання) - для систем, що взаємодіють з користувачем в інтерактивному режимі, і систем реального часу;
• обсяг оперативної пам'яті - для продуктів, що працюють в системах з обмеженим об'ємом оперативної пам'яті, наприклад MS DOS;
• обсяг зовнішньої пам'яті - для продуктів, що інтенсивно використовують зовнішню пам'ять, наприклад баз даних;
• кількість обслуговуваних зовнішніх пристроїв - для продуктів, які здійснюють інтенсивну взаємодію із зовнішніми пристроями, наприклад давачами.
Вимоги ефективності можуть суперечити один одному. Наприклад, щоб зменшити час виконання деякого фрагмента програми, може знадобитися додатковий обсяг оперативної пам'яті.
Адаптованість, по суті справи, оцінює технологічну якість програмного забезпечення, тому оцінити цю характеристику кількісно практично неможливо. Можна тільки констатувати, що при створенні продукту використані технології та спеціальні прийоми, які полегшують його модернізацію.
Вимога повторної входимості зазвичай пред'являється до програмного забезпечення, резидентно завантаженого в оперативну пам'ять, наприклад драйверів. Для забезпечення даної вимоги необхідно так організувати програму, щоб ніякі її вихідні дані не затиралися в процесі виконання або відновлювалися на початку або при завершенні кожного виклику.
Вимога реєнтерабельності є більш жорсткою, ніж повторна входимість, так як в цьому випадку всі дані, що змінюються програмою в процесі виконання, повинні бути виділені в спеціальний блок, копія якого створюється для кожного процесу при виклику програми.
Складність багатьох програмних систем не дозволяє відразу сформулювати чіткі вимоги до них. Зазвичай для переходу від ідеї створення деякого програмного забезпечення до чіткого формулювання вимог, які можуть бути занесені до технічного завдання, необхідно виконати передпроектні дослідження в області розробки.