Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
vika / Лекція 11.doc
Скачиваний:
5
Добавлен:
07.02.2016
Размер:
81.41 Кб
Скачать

11

Погано не поклажі, злодія в гріх не вводь.

Народне прислів'я

Лекція 11. Забезпечення функціональності і надійності програмного засобу

Функціональність і надійність як обов'язкові критерії якості програмного засобу. Забезпечення завершеності програмного засобу. Захисне програмування і забезпечення стійкості програмного модуля. Види захисту і забезпечення захищеності програмного засобу.

11.1. Функціональність і надійність як обов'язкові критерії якості програмного засобу.

На попередніх лекціях ми розглянули всі етапи розробки ПС, окрім його атестації. При цьому ми не стосувалися питань забезпечення якості ПС відповідно до його специфікації якості (див. лекцію 4). Правда, займаючись реалізацією функціональної специфікації ПС, ми тим самим обговорили основні питання забезпечення критерію функціональності. Оголосивши надійність ПС основним його атрибутом (див. лекцію 1), ми вибрали попередження помилок як основний підхід для забезпечення надійності ПС (див. лекцію 3) і обговорили його втілення на різних етапах розробки ПС. Таким чином, виявлялася теза про обов'язковість функціональності і надійності ПС як критеріїв його якості.

Проте, в специфікації якості ПС можуть бути додаткові характеристики цих критеріїв, забезпечення яких вимагають спеціального обговорення. Цим питанням і присвячена справжня лекція. Забезпечення інших критеріїв якості обговорюватиметься в наступній лекції.

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

11.2. Забезпечення завершеності програмного засобу.

Завершеність ПС є загальним примітивом якості ПС для виразу і функціональності і надійності ПС, причому для функціональності вона є єдиним примітивом (див. лекцію 4).

Функціональність ПС визначається його функціональною специфікацією. Завершеність ПС як примітив його якості є мірою того, в якому ступені ця специфікація реалізована в ПС, що розробляється. Забезпечення цього примітиву в повному об'ємі означає реалізацію кожній з функцій, визначеною у функціональній специфікації, зі всіма вказаними там деталями і особливостями. Всі розглянуті раніше технологічні процеси показують, як це може бути зроблено.

Проте в специфікації якості ПС можуть бути визначені декілька рівнів реалізації функціональності ПС: може бути визначена деяка спрощена (початкова або стартова) версія, яка повинна бути реалізована в першу чергу; можуть бути також визначені і декілька проміжних версій. В цьому випадку виникає додаткове технологічне завдання: організація нарощування функціональності ПС. Тут важливо відзначити, що розробка спрощеної версії ПС немає розробка його прототипу. Прототип розробляється для того, щоб краще зрозуміти умови застосування майбутнього ПС [11.1], уточнити його зовнішній опис. Він розрахований на вибраних користувачів і тому може сильно відрізнятися від необхідного ПС не тільки виконуваними функціями, але і особливостями призначеного для користувача інтерфейсу. Спрощена ж версія ПС, що розробляється, повинна бути розрахована на практично корисне застосування будь-якими користувачами, для яких призначене це ПС. Тому головний принцип забезпечення функціональності такого ПС полягає в тому, щоб із самого початку розробляти ПС таким чином, неначе потрібний ПС в повному об'ємі, доти, коли розробники матимуть справу безпосередньо з тими частинами або деталями ПС, реалізацію яких можна відкласти відповідно до специфікації його якості. Тим самим, і зовнішній опис і опис архітектури ПС повинні бути розроблене в повному об'ємі. Можна відкласти лише реалізацію тих програмних підсистем (визначених в архітектурі ПС, що розробляється), функціонування яких не вимагається в початковій версії цього ПС. Реалізацію ж самих програмних підсистем краще всього проводити методом цілеспрямованої конструктивної реалізації, залишаючи в початковій версії ПС відповідні імітатори тих програмних модулів, функціонування яких в цій версії не потрібне. Допустима також спрощена реалізація деяких програмних модулів, що опускає реалізацію деяких деталей відповідних функцій. Проте такі модулі з технологічної точки зору краще розглядати як своеобразные їх імітатори (хоча і далеко просунуті).

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

Соседние файлы в папке vika