11.1. Функціональність і надійність як обов'язкові критерії якості програмного засобу.
На попередніх лекція ми розглянули всі етапи розробки ПС, крім його атестації. При цьому ми не торкалися питань забезпечення якості ПС відповідно до його специфікацією якості (див. Лекцію 4). Правда, займаючись реалізацією функціональної специфікації ПС ми тим самим обговорили основні питання забезпечення критерію функціональності. Оголосивши надійність ПС основним його атрибутом (див. Лекцію 1), ми вибрали попередження помилок в якості основного підходу для забезпечення надійності ПС (див. Лекцію 3) і обговорили його втілення на різних етапах розробки ПС. Таким чином проявлявся тезу про обов'язковість функціональності і надійності ПС як критеріїв його якості.
Проте, в специфікації якості ПС можуть бути додаткові характеристики цих критеріїв, забезпечення яких вимагають спеціального обговорення. Цим питанням і присвячена ця лекція. Забезпечення інших критеріїв якості буде обговорюватися в наступній лекції.
Нижче обговорюються забезпечення примітивів якості ПС, що виражають критерії функціональності і надійності ПС.
11.2. Забезпечення завершеності програмного засобу.
Завершеність ПС є загальним примітивом якості ПС для вираження і функціональності і надійності ПС, причому для функціональності вона є єдиним примітивом (див. Лекцію 4).
Функціональність ПС визначається його функціональної специфікації. Завершеність ПС як примітив його якості є мірою того, наскільки ця специфікація реалізована в даному ПС. Забезпечення цього примітиву в повному обсязі означає реалізацію кожної з функцій, визначеної в функціональної специфікації, з усіма зазначеними там деталями і особливостями. Усі розглянуті раніше технологічні процеси показують, як це може бути зроблено.
Однак в специфікації якості ПС можуть бути визначені кілька рівнів реалізації функціональності ПС: може бути визначена деяка спрощена (початкова або стартова) версія, яка повинна бути реалізована в першу чергу, можуть бути також визначені і кілька проміжних версій. В цьому випадку виникає додаткова технологічна задача: організація нарощування функціональності ПС. Тут важливо відзначити, що розробка спрощеної версії ПС не їсти розробка його прототипу. Прототип розробляється для того, щоб краще зрозуміти умови застосування майбутнього ПС [11.1], уточнити його зовнішній опис. Він розрахований на обраних користувачів і тому може сильно відрізнятися від необхідного ПС не тільки виконуваними функціями, а й особливостями користувальницького інтерфейсу. Спрощена ж версія необхідного ПС повинна бути розрахована на практично корисне застосування будь-якими користувачами, для яких він призначений. Тому головний принцип забезпечення функціональності такого ПС полягає в тому, щоб з самого початку розробляти ПС таким чином, як ніби потрібно ПС в повному обсязі, до тих пір, поки розробники не матимуть справу з тими частинами або деталями ПС, реалізацію яких можна відкласти в відповідно до специфікації його якості. Тим самим, і зовнішній опис і опис архітектури ПС повинно бути розроблено в повному обсязі. Можна відкласти лише реалізацію тих програмних підсистем, визначених у архітектурі розроблюваного ПС, функціонування яких не потрібно в початковій версії цього ПС. Реалізацію ж самих програмних підсистем найкраще робити методом цілеспрямованої конструктивної реалізації, залишаючи в початковій версії ПС підходящі імітатори тих програмних модулів, функціонування яких в цій версії не потрібно. Допустима також спрощена реалізація деяких програмних модулів, що опускає реалізацію деяких деталей відповідних функцій. Однак такі модулі з технологічної точки зору краще розглядати як своєрідні їх імітатори (хоча і далеко просунуті).
В силу наявних в розробляється ПС помилок досягнута при забезпеченні його функціональності завершеність (відповідно до специфікації його якості) насправді може бути не такою, як очікувалося. Можна лише говорити, що ця завершеність досягнута з деякою ймовірністю, яка визначається обсягом і якістю проведеного тестування. Для того щоб підвищити цю ймовірність, необхідно продовжити тестування і налагодження ПС. Однак, оцінювання такої ймовірності є досить специфічною завданням (з урахуванням того, що прояв наявної в ПС помилки є функцією вихідних даних), яка поки ще чекає відповідних теоретичних досліджень.
11.3. Забезпечення точності програмного засобу.
Забезпечення цього примітиву пов'язано з діями над значеннями речових типів (точніше кажучи, зі значеннями, що подаються з деякою погрішністю). Забезпечити необхідну точність при обчисленні значення тієї чи іншої функції - значить отримати це значення з похибкою, що не виходить за рамки заданих меж. Видами похибки, методами їх оцінки та методами досягнення необхідної точності (так званими наближеними обчисленнями) займається обчислювальна математика [11.1, 11.2]. Тут ми лише звернемо увагу на деяку структуру похибки: похибка обчисленого значення (повна похибка) залежить
від похибки використовуваного методу обчислення (в яку ми включаємо і неточність використовуваної моделі),
від похибки подання використовуваних даних (від т.зв. непереборний похибки),
від похибки округлення (неточності виконання використовуваних в методі операцій).