Порядок розробки програмного модуля. Атестація програмних засобів (стр. 2 из 3)

завжди варто використовувати рутинний модуль, якщо це не приводить до поганого зчеплення модулів;

залежні від передісторії модулі варто використовувати тільки у випадку, коли це необхідно для забезпечення параметричного зчеплення;

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

При розробці програмного модуля доцільно дотримувати наступного порядку:

вивчення і перевірка специфікації модуля, вибір мови програмування;

вибір алгоритму і структури даних;

програмування (кодування) модуля;

перевірка і редагування модуля;

компіляція модуля.

Перший крок розробки програмного модуля в значній мірі являє собою суміжний контроль структури програми знизу: вивчаючи специфікацію модуля, розроблювач повинний переконатися, що вона йому зрозуміла і достатня для розробки цього модуля. У завершенні цього кроку вибирається мова програмування: хоча мова програмування може бути уже визначеною для усього ПЗ, все-таки в ряді випадків може бути обрана інша мова, більш придатна для реалізації даного модуля (наприклад, мова асемблера). На другому кроці розробки програмного модуля необхідно з'ясувати, чи не відомі вже які-небудь алгоритми для рішення поставленої і чи близької до неї задачі. І якщо знайдеться придатний алгоритм, то доцільно їм скористатися. Вибір придатних структур даних, що будуть використовуватися при виконанні модулем своїх функцій, у значній мірі визначає логіку і якісні показники розроблювального модуля, тому його варто розглядати як дуже відповідальне рішення. На третьому кроці здійснюється побудова тексту модуля обраною мовою програмування. Велика кількість усіляких деталей, що повинні бути враховані при реалізації функцій, зазначених у специфікації модуля, легко можуть привести до створення дуже заплутаного тексту, що містить масу помилок і неточностей. Шукати помилки в такому модулі і вносити в нього необхідні зміни може виявитися дуже трудомісткою задачею. Тому дуже важливо для побудови тексту модуля користатися технологічно обґрунтованою і практично перевіреними принципами програмування. Найбільш розповсюдженими є принципи покрокової деталізації. Наступний крок розробки модуля зв'язаний із приведенням тексту модуля до завершеного виду у відповідності зі специфікацією якості ПЗ. При програмуванні модуля розроблювач основну увагу приділяє правильності реалізації функцій модуля, залишаючи недопрацьованими коментарі і допускаючи деякі порушення вимог до стилю програми. При шліфуванні тексту модуля він повинний відредагувати наявні в тексті коментарі і, можливо, включити в нього додаткові коментарі з метою забезпечити необхідні примітиви якості. З цією же метою виконується редагування тексту програми для забезпечення стилістичних вимог. Перевірка модуля являє собою ручну перевірку внутрішньої логіки модуля до початку його налагодження на комп'ютері, реалізує загальний принцип, сформульований для обговорюваної технології програмування. І, нарешті, останній крок розробки модуля означає завершення перевірки модуля (за допомогою компілятора) і перехід до процесу налагодження модуля.

3. Атестація програмних засобів

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

безпосередній вимір показників примітива якості;

тестування програм ПЗ;

експертна оцінка на підставі вивчення програм і документації ПЗ.

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

4. Практичне завдання

З використанням засобів візуального програмування розробити програму для автоматичного розрахунку значень складної функції:

Приклад файлу форми Delphi6 для табулювання функції:

unit Func_tab;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Buttons, Grids, Menus;

type

TForm1 = class (TForm)

Label1: TLabel;

Edit1: TEdit;

Label2: TLabel;

Edit2: TEdit;

Label3: TLabel;

Edit3: TEdit;

StringGrid1: TStringGrid;

BitBtn1: TBitBtn;

Label4: TLabel;

ListBox1: TListBox;

Memo1: TMemo;

BitBtn2: TBitBtn;

Label5: TLabel;

Label6: TLabel;

Label7: TLabel;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N3: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

BitBtn3: TBitBtn;

procedure BitBtn1Click (Sender: TObject);

procedure Edit1KeyPress (Sender: TObject; var Key: Char);

procedure Edit2KeyPress (Sender: TObject; var Key: Char);

procedure Edit3KeyPress (Sender: TObject; var Key: Char);

procedure Edit1Exit (Sender: TObject);

procedure Edit2Exit (Sender: TObject);

procedure Edit3Exit (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure N4Click (Sender: TObject);

procedure N3Click (Sender: TObject);

procedure FormActivate (Sender: TObject);

procedure BitBtn3Click (Sender: TObject);

procedure N5Click (Sender: TObject);

procedure N7Click (Sender: TObject);

procedure N8Click (Sender: TObject);

procedure N9Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

X,Xn,Xk,H: real; // Параметри табулювання

fname: String [25] ; //

f: textfile;

implementation

{$R *. dfm}

// Повідомлення про помилку у завданні інтервалів табулювання

procedure P1;

begin

MessageDlg ('"Xп" не може бути більшим ніж "Хк". ' +#13

+'Введіть значення правильно. ', mtWarning, [mbCancel], 0);

Form1. Edit1. Text: ='';

Form1. Edit2. Text: ='';

end;

// Повідомлення про помилку у значенні кроку табулювання по відношенню до