Дисципліни програмної інженерії

Змінні

У java кожна змінна має свій тип. При оголошенні змінної спочатку вказується її тип, а потім її значення.
double money;
int year;

В кінці кожного виразу необхідно ставити крапку з комою. Кожна змінна повинна починатися з букви і складатися з букв і цифр. Інші символи не можна використовувати.

Ініціалізація змінних

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

Константи

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

public class Constans {

       public static void main(String[] args) {

final double CM_PER_INCH = 2.54;
double paperWidth = 8.5;
       double paperHeight = 11;
System.out.println(“Розмір сторінки в см ” + paperWidth* CM_PER_INCH
 + ” на ” + paperWidth* CM_PER_INCH);

       }

}

У мові java також виникає потреба створення констант доступних в декількох методів констант класу, і оголошуються за допомогою ключових слів static final.

Операції.

Для позначення операцій + - * / використовуються звичайні арифметичні операції. Операція / означає цілочисельне ділення, якщо обидва його аргументи є цілими числами. В іншому випадку ця операція означає ділення чисел з плаваючою крапкою. Залишок від ділення цілих чисел позначається 15%7 = 2

Операція інкрементування і декрементування.

Існує два види операції інкрементування та декрементування: постфікстна форма (i++) та префіксна форма (++i). Різниця виявляється тільки тоді, коли це використовується у визарі. Префіксна спочатку змінює значення, та використовує нове значення для подальших обчислень, а постфіксна форма використовує старе значення і тільки потім використовує старе значення.

Операція відношення та логічні операції.

Мова java містить повний комплект операцій відношень. Щоб перевірити рівність використовується символи подвійного дорівнює “==”. Недорвінює “!=” .

&& - and
|| - or

Математичні функції та константи.

Клас Math містить набір математичних функцій, які необхідні для виконання математичних завдань.

Перетворення числових типів.

                   Char
                   |
                   \/
Byte → short → int → long
                   |\ :
                   | \ : :
                   | : \ :
                   float double

Перетворення чисел у мові java можливе, але при цьому відбувається втрата інформації. Таке перетворення називається переведення типів.

double x = 9.997;
int nx = (int)x; // 9
int nxr = (int)Math.round(x); // 10

Рядки.

Рядок java – це послідовність вимволів UNICODE. Кожен рядок поміщається в подвійні лапки і представляє собою екземпляр класу String.

Підрядки.

За допомогою методу subString() мона виділяти підрядок даного рядка.
String a = “Hello”;
String b = a.subString(0, 3);

Конкатенація (обєднання).

Мова java дає можливість використовувати знак “+” для обєднання двох рядків.
String c = “Hello ” + “world ” + 24;

Перевірка еквівалентності рядків.

Для перевірки використовуєтсья метод equals();
Для перевірки ігноруючи регістр equalsIgnoreCase();

Ввід і вивід.

Зчитувати вхідних даних. Для того, щоб організувати зчитування з консолі необхідно створити об'єкт Scanner і зв'язати його зі стандартним вхідним потоком System.in.

Scanner in = new Scanner(System.in);

Після цього можна отримати в своє розпорядження мтоди класу Scanner для зчитування.

System.out.println();

Scanner in = new Scanner(System.in);

String name = in.nextLine();

Форматування вихідних даних.

System.out.printf(“%8.2f”, x);

Файловий ввід – вивід.

Для того, щоб прочитати з файлу необхідно сконструювати об'єкт Scanner з об'єкту File.
Scanner in new Scanner(new File(“myдшау.txt”));
“C:\\Student\\mylife.txt”

Щоб виконати запис у вайл необхідно сконструювати об'єкт
PrintWritte out = new PrintWritter(“mylife.txt”);

Якщо конструюєься Scanner з файлу, якого не існує, або PrintWritter який не може бути створений виникає виключення. Компілятор java розглядає ці виключення як більш серйозні, ніж на виключення “Ділення на Нуль”. Для цього необхідно сказати компілятору, що вам відомо про можливість винекнення виключення типу “FileNotFoundException”. Це робиться до методу конструкції throws.
Public static void main(String[] args) throws FileNotFoundException {
}

Потік керування. У мові java є умовні оператори та цикли.

Блоки

Блок – це довільна кількістьт простих операторів мови java включених у фігурны дужки. Блоки визначають область видимості змінних. Блоки можуть бути вкладеними одна в одну.
{
       int k;
       …
       {
                   int n;
                    …
       }
}

Умовні вирази.

Умовний оператор у мові java має наступний вигляд.
if(<condition>) <operator>

Загальна форма умовного оператора у мові java.
if(serbal <= 2) {
       stip = “none”;
       suma 0;
} else if(serbal >2 && serbal < 5){
       stip = “avg”;
       suma = 400;
} else {
       //
}

Невизначений цикл

Забезпечує повторення операторів, які складають блок то дих пір, поки умова виконується.
while(<condition>) <operator>.
Тіло циклу while не буде виконано ніразу, якщо умова == фалсе. Умова перевіряється спочатку. Відповідно можлива ситуація, при якій код, який міститься у блоці не буде виконаний жодного разу. Якщо необхідно, щоб блок виконався лише один раз, то пеервірку умови необхідно перенести в кінець. Do <operator> while(<condition>);

Визначені цикли. Найпоширеніша мовна конструкція – цикл for(). В ній кількість повторень регулюється зміною, яка відіграє роль лічильника, і обновляється на кожній ітерації. Перший елемент оператора for зазвичай виконує ініціалізацію лічильника. Другий формує умову виконання тіла ціклу. А третій означає спосіб оновлення лічильника.

Конструкція if-else не зручна, якщо необхідно реалізувати вибір із багатьох варіантів. Є оператор switch, який еквівалентний оператору в “Сі”.

Switch(int choise = in,nextInt()) {
       case 1 : break;
       case 2 : break;
       default : break:
}

Масиви

Масиви – це структура даних, в якій зберігаються величини однакового типу. Доступ до окремого елементу масиву здійснюється за допомогою цілочисельного індексу. Масив оголошується наступним чином: Спочатку вказується тип масиву (тип елементів). А після них ім'я змінної.
int[] a;
int[] a = new int[100]; Для того, щоб підрахувати кількість елементів масиву використовується наступний вираз: a.length;

Ініціалізація масивів і анонімні масиви. У мові java присутня можливість для одночасного опису масиву та його ініціалізація.
Int[] a = {1,2,8,100,4}

Крім цього, у java можна ініціалізувати масив, який не має імені (анонімний масив).

New int[] {1,2,4,5,7};

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

b = new int{1,3,5}; // скорочений запис int [] c = {1,3,5}; b = c;

Копіювання масивів. При необхідності одну змінну масиву можна скопіювати в іншу. Але при цьому дві змінні будуть посилатися на один і той же масив. Якщо необхідно скопіювати всі елементи одного масиву в інший необхідно використати метод copyTo із класу Arrays.

Int copyed = Arrays.copyTo(d, d.length);

Параметри командного рядка.

В кожній розглянутій раніше програмі на мові java присутній метод main(String[] args). Цей паарметр означає, що метод main() одержує масив, елементи якого являються параметри, вказані в командному рядку.

Public class Message {
       public static void main(String[] args) {
                   if(args[0].equals(“-h”)) {
                              System.out.println(“Hello, ”);
                   } else if(args[0].equals(“-g”)) {
                              System.out.println(“Goodby, ”);
                   }
                   for (int 1 = 1; I < args.length; i++){
                              System.out.println(“ ” + args[i]);
                   }
                   System.out.println(“!”);
       }
}
java Message – g my world

Сортування масивів.

Якщо необхідно впорядкувати масив чисел то можна затсовувати метод sort() із класу масивів.

Int [] a = new int [100];
…
…
…
Arrays.sort(a);

Багатовимірні масиви.

Для доступу до елементів багатовимірних масивів застосовується декілька індексів. Такі масиви використовуються для зберігання таблиць, і більш складних упорядкованих структур даних. Наприклад, необхідно створити таблицю чисел, яка вказує як зросте інвестиція обємом у $10 000 при різних процентних ставках, якщо прибуток кожного року інвестується.. бла бла бла, якась економічна фігня.

Double [][] balance;
balance = new double [YEAR][RATE];

після ініціалізації до його елементів можна звертатися за допомогою двох пар квадратних дужок

balance[i][j];

Об'єкти і класи.

1) Вступ в ООП.

2) Використання готових класів.

3) Визначення власних класів.

4) Статичні поля і методи.

5) Параметри методів.

6) Конструювання об'єктів.

7) Пакети.

8) Коменти і документування.

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

Клас – це шаблон, або проект, по якому буде зроблений проект. Конструювання об'єкту на основі деякого класу називається створенням екземпляру цього класу.

Інкапсуляція – це ключове поняття при робозі із об'єктами. Формально інкапсуляцією вважається звичайне об'єднання даних і операцій над ними в одному пакеті і прихровування даних від інших об'єктів. Дані в об'єкті називаються полями екземпляру. А функції, і процедури, які виконують операції над даними – методами.

В ооп визначені наступні ключові властивості об'єктів:

1) поведінка об'єкта – те, що можна робити з обєктом, які методи можна до нього застосовувати.

2) Стан об'єктів – це те, як об'єкт реагує на застовування методів.

3) Сутність об'єкта – це те, чим даний об'єкт відрізняється від інших, які характеризуються такою ж поведінкою і станом.

Використання готових класів.

Об'єкти та об'єктні змінні.

Щоб працювати з об'єктами, їх необхідно спочатку створити і задати їх початковий стан. Після можна до цих об'єктів застосовувати методи.

У мові java для творення нового екземпляра використовується конструктор.

Конструктор – це спеціальний медод, призначений для створення та ініціалізації екзампляра класу. Ім'я конструктора завжди співпадає з іменем класу. На приклад, конструктор класу Date називається так само Date. Щоб створити об'єкт Date конструктор необхідно об'єднати з операцією new. Цей вираз створює новий об'єкт, який ініціалізується …

Оголошення класу

class Name{
конструктори
методи
моля
}

class Employee {
 public Employee(String n, double s, int year, int month, int day){
   name = n;
salary = s;
GregorianCalendar calendar = new GregorianCalendar(year, month-1, day);
hireday =calendar.getTime();
}
public String getName(){
return name;
}
private String name;
}

Конструктор виконується при створення об’єкта Employee заповнюючи його поля заданими значеннями. New Employee(“Ivan”, 100, 1999, 1, 1);

Між конструкторами і іншими методами є велика різниця: конструктор можна викликати лише в поєднанні з операцією “new”. Основні властивості, на які треба вважати при створення конструктора:

1) Імя конструктора повинно співпадати з назвою класу.

2) Клас може мати декілька конструкторів.

3) Конструктор може мати фіг зна скільки параметрів.

4) Конструктор не повертає жодного значення.

5) Конструктор завжди викликається разом з операцією New

Class Box {
double width;
double height;
double depth;
}

Даний клас є шаблоном або типом даних. Щоб створити об’єкт Box треба використати операцію new.
Box mybox = new Box();

Після виконання цього виразу змінна mybox стає екземпляром класу box. Кожного разу, коли ви створюєте екземпляр класу створюється об’єкт, який містить свою власну копію кожної екземплярної змінної, визначеної в класі.

Для доступу до змінних необхідно використовувати операцію «крапка». Вона повязує імя об’єкту з іменем змінної екземпляру. Цей оператор просить компілятора присвоїти копії змінної width, яка міститься в об’єкті mybox значення 100.

Програма яка використовує клас Box.

Class BoxDemo {
public static void main(String[] args) {
Box mybox = new Box();
double vol;
mybox.width = 10;
mybox.height = 20;
mybox.depth = 15;
vol = mybox.width * mybox.height * mybox.depth;
System.out.println(“Об'єм ” + vol);
}
}

Оголошення об’єктів. Коли створюється клас то створюється новий тип даних. Цей тип можна використовувати для оголошення відповідних об’єктів. Одержання об’єктів класу це двохкроковий процес.

Box mybox;
mybox = new Box();

Операція new динамічно розподіляє пам'ять для об’єкта.

class-var = new ClassName();

<type> <name>(<parameters>) {
// method body
}

<Type> – визначає тип даних, який буде повертати цей метод. Якщо метод нічого не повертає, то його тип повинен бути void.

<parameters> - послідовність пар тип – ідентифікатор, розділених комою. Параметр – це змінні, яки приймають значення аргументів, які посилаються методу під час його виклику. Методи, в яких тип повертального значення відмінний від void повертає значення викликаючій підпрограмі використовуючи наступну форму оператора return:

Return value;

Class Box {
double width;
double height;
double depth;
void volume() {
System.out.println(“Obyem = ” + width*height*depth);

}
}
class BoxDemo {
public static void main (String [] args) {
Box mybox = new Box();
mybox.width = 100;
….
mybox.volume();
}
}

Class Box {
double width;
double height;
double depth;
double volume() {
return width*height*depth;
}
}
class BoxDemo {
public static void main (String [] args) {
Box mybox = new Box();
mybox.width = 100;
….
System.out.println(“jGurda = ” + mybox.volume());
}
}

Додавання методів з параметрами.

Хоч деякі методи не являють потреби у параметра, однак більшість з них параметрами все-таки користується.

Int square(int i){
return i*I;
}

Параметр – це змінна, яка визначається методом, і яка приймаж значення під час виклику метода.

Аргумент – це значення, яке передається методу, коли він викливається.

Class Box {
double width;
double height;
double depth;
double volume() {
return width*height*depth;
}
void setDim(double w, double h, double d){
width = w;
height = h;
depth = d;
}
}
class BoxDemo {
public static void main (String [] args) {
Box mybox = new Box();
mybox.setDim(100, 300, 10);
…
System.out.println(“jGurda = ” + mybox.volume());
}
}

Наслідування дозволяє створювати ієрархічні класифікації. Використовуючи наслідування можна створити головний клас, який визначає властивості, для набору зв’язаних елементів. Потім цей клас може бути унаслідуваний іншими більш специфічними класами, кожен з яких додає ті властивості, які є унікальними для нього. В java клас, який унаслідується називається супер класом, а клас який виконує наслідування називається підкласом. Підклас наслідує всі змінні екземпляру і методи, визначені супекласом і додає свої власні унікальні елементи. Щоб наслідувати клас необхідно просто включити визначення одного класу в інший використовуючи ключове слово extends. Простий приклад наслідування. Програма яка створює супер клас з іменем A і підклас з іменем B.

Class A{
int I, j;
void showij(){
System.out.println(I + “ - ” + j);
}
}

class B extends A{
int k;
void showk(){
System.out.println(“k = ” + k);
}
void sum(){
System.out.println(“ I + j + k”, (i + j + k));
}
}

Class SubClassName extends SuperClassName{

}

Доступ до елементів і наслідування

Хоч підклас включає всі елементи свого супер класу, він не може звертатися до всіх елементів суперкласу, які були оголошені як private.

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

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

Super(<parameter-list>);

<parameter-list> - список парметрів, який визначає будь-який параметр, які необхідні конструктору в суперкласі.

Class BoxWeight extends Box {
double weight;
BoxWeight(d.. w, d..h, d.. d, d..m);
super(w,h,d);
weight=m;
}

Super.member – загальна форма використання супер в другому вигляді, де member може бути будь-яким методом або полем екземпляра.

Друга форма super найбільше використовується у ситуаціях, коли імена елементів в підкласах приховують елементи з тим самим іменем в суперкласі.

Пакети та інтерфейси.

Пакети (Контейнер класів), які використовуються для зберігання простір імен класів, розділених на іменовані області. Пакети зберігається ієрархічним способом, і імпортуються у визначеннях нових класів.

Використовуючи інтерфейс можна визначити набір методів, які будуть реалізовані одним або декількома класами.

Пакети та інтерфейси це два основних компоненти java програм. В загальному випадку програмний файл java може містити будь-яку (або всі) із наступних 4-х внутрішніх частин:

· Одиночний package оператор (не обов’язковий)

· Будь-яке число import операторів (не обов'язково)

· Одиночне оголошення загального класу (обов’язково)

· Будь-яке число приватних класів пакету (не обов’язково).

Для створення пакету необхідно включити оператор package в початок програмного файлу java. Будь-які класи оголошені в межах цього файлу будуть належати вказаному пакету. Оператор package визначає простір імен, в якому зберігається класи. Якщо опустити інструкцію package імена поміщаються в пакет по замовчуванню.

Загальна форма інструкції package:

package pkg;

Одну і ту ж інструкцію пакетів можна вміщати в декілька файлів одночасно. Вона просто вказує якому пакету належать класи, визначені у файлі. Можна створювати ієрархію пакетів. Для цього необхідно визначити просто відділити кожне ім’я  пакету від попереднього операцією «крапочка».

Захист доступу.

Класи і пакети з однієї сторони забезпечують інкапсуляцію, а з іншої підтримують простір імен в області видимості змінних і методів. Паке діють як контейнери для класів та інших залежних пакетів. Класи діють як контейнери для даних і коду. Клас – це найменший модуль мови java. Через взаємодію між класами і пакетами java адресує 4 категорії видимості для елементів класу:

· Підкласи в тому ж пакеті.

· Не підкласи в тому пакеті.

· Підкласи в різних пакетах.

· Класи, які не знаходяться в тому ж пакеті і не являються підкласами.

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

· Private

· Protected

· Public

· <not>

Все оголошене як public може бути доступне відусюди.

Все оголошене як private не може бути видимим ззовні свого свого класу.

Коли елемент не має явних специфікацій доступу, то він видимий у підкласах, а також в інших класів в тому самому пакеті (доступ, заданий по замовчуванню).

Якщо ви хочете дозволити елементу бути видимим ззовні вашого поточного пакету, але тільки у класах, які є прямими підкласами вашого класу, то необхідно оголосити цей елемент як protected.

Імпорт пакетів.

Щоб забезпечити видимість деяких класів а також пакетів java то використовується оператор import. Після імпортування на клас можна посилатись прямо, використовуючи тільки його ім’я.

Import java.io.*;
import java.Math.*;
import java.util.Date;

Використовуючи інтерфейс ви можете вказати: що клас повинен робити, але не як він повинен це робити.

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

Дисципліни програмної інженерії

1) Загальне визначення дисциплін програмної інженерії

2) Програмна інженерія як наукова дисципліна

3) Програмна інженерія як інженерна дисципліна

4) Програмна інженерія як виробнича дисципліна

5) Дисципліна керування

6) Економічна дисципліна

Термін «програмна інженерія» був згаданий у 1968. Спеціально створений комітет фахівці з інформатики сформував базове ядро знань SWETBOK (Software Engineering Body of Knowledge), у якому в концентрованому вигляді подав концептуальний зміст 10-х базових областей та визначення програмної інженерії. У ядрі знань SWEBOK наведено таке визначення програмної інженерії:

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

2. Програмна інженерія – це навчальна дисципліна що вивчає вказані вище підходи.

Програмна інженерія інтегрує в собі принципи математики, та головні положення фундаментальних наук:

1. Теорія алгоритмів

2. Математична логіка

3. Теорія керування

4. Теорія множин

5. Теорія доведення

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

- У теорії алгоритмів – нормальні алгоритми, обчислювальні функції, машина Тюрінга, алгоритмічній алгебрі, блок-схеми або графи, моделі алгоритмів і програм.

- У математичній логіці – логічні числення і логіко-алгебраїчний апарат, специфікації програм.

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

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

Тема: стандарт життєвого циклу.

Кожна програмна система протягом свого існування проходить з певною послідовністю фази або стадії від задуму до йог о втілення в програми, експлуатацію та вилучення. Така послідовність фаз називається життєвим циклом розробки програмного забезпечення. На кожній фазі відбувається певна сукупність процесів, кожний з яких породжує певний продукт, використовуючи певні ресурси. Усі продукти всіх процесів програмної інженерії являють собою певні описи – тексти вимог до розробки, погодження домовленостей, документацію, тексти програм, інструкції з експлуатації, тощо. Головними ресурсами програмної інженерії, які визначають ефективність її розробок є час і вартість.

Різновид діяльності, які становлять процеси життєвого циклу програмної системи в зафіксованому міжнародному стандарті ISO/IEC 12207:2002. Згідно з наведеним стандартом всі процеси поділено на 3 групи:

· Головні процеси

· Процеси підтримки

· Організаційні процеси.

До основних процесів належать:

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

- Процес постачання, який визначає дії з передачі покупцю програмного продукту, або сервісу, і містить у собі такі види діяльності: підготовку пропозицій (відповідь на запиту); оформлення контракту; планування, виконання і контроль продукту, що постачається; аналіз і оцінку продукту; постачання і завершення робіт з постачання.

- Процес розроблення, який визначає дії підприємства розробника програмного продукту (ПП): аналіз вимог до системи; проектування архітектури системи; кодування і тестування програмної системи; інтеграція системи; кваліфікаційне тестування; установку програмної системи.

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

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

До процесів підтримки розробки програмних систем належать:

· Документування

· Керування версіями

· Верифікація та валідація

· Перегляди

· Аудити

· Оцінювання продукту та ін.

До організаційних процесів належать:

· Керування проектом (менеджмент розробки)

· Керування якістю

· Керування ризиками

Допоміжні процеси ЖЦПС:

· Процеси підтримки розробки

o Документування

o Керування конфігурацією

o Гарантія якості ПС

o Верифікація

o Валідація

o Загальний перегляд

o Аудит

o Оцінювання продукту

o Розвязок проблем

· Організаційні процеси розробки ПС

o Процес керування

§ Керування на рівні організації

§ Керування проектом

§ Керування якістю

§ Керування ризиком

§ Організаційне забезпечення

§ Вимірювання

§ Керування знаннями

o Процес вдосконалення

§ Впровадження процесів

§ Оцінювання процесів

§ Вдосконалення процесів

Типи моделей життєвого циклу.

План:

1) Каскадна модель

2) Інкрементна

3) Спіральна модель

4) Еволюційна модель

1) Каскадна модель життєвого циклу

- [визначення завдання]

o [проектування системи]

§ [реалізація системи]

· [тестування системи на перевірку правильності (верифікація)]

o [тестування системи на відповідність завданню (валідація)]

§ [супровід]

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

Недоліки моделі:

1. процес створення програмних систем не завжди вкладається в таку жорстку форму і послідовність дій.

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

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

Переваги:

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

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

Інкрементна модель життєвого циклу програмної системи

Аналіз вимог і попереднє тестування

- Проект

o Реалізація

§ Тестування

· Випуск 1

- ПроектІ

o Реалізація

§ Тестування

· Випуск 2

- проект

o реалізація

§ тестування

· Випуск 3

Суть інкрементної моделі полягає у розробці продукту ітераціями, і кожна ітерація закінчується випуском працездатної версії. У кожній новій версії додаються деякі функціональні можливості. Розробка системи починається з визначення набору всіх вимог до програмної системи, і ділення процесу розробки на ітерації. Кожна ітерація реалізується послідовно. З використанням процесів життєвого циклу і фіксація робочої версії системи, яка поступово наближається до остаточної версії. Перша проміжна версія, системи що створюється (випуск 1) реалізує частину вимог, у подальшу версію (випуск 2) додаються додаткові вимоги додаються до тих пір, поки не будуть остаточно виконані всі вимоги і розв’язані задачі розробки системи.

Дану модель життєвого циклу доцільно використовувати у випадках:

§ Бажано реалізувати деякі можливості системи швидко за рахунок створення проміжної версії продукту.

§ Система декомпозується на окремі складові частини, які можна реалізувати як деякі самостійні проміжні або готові продукти.

§ Можливість збільшення фінансування на розробку окремих частин системи.

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

Згідно з еволюційною моделлю система послідовно розробляється з блоків-конструкцій. На відміну від інкрементної моделі у еволюційній моделі вимоги встановлюються частково і уточнюються в кожному наступному проміжному блоці структури системи. Використання еволюційної моделі припускає проведення дослідження предметної області, для вивчення потреб її замовника і аналізу можливості застосування цієї моделі для реалізації. Модель використовується для розробки не складних систем, де головною вимогою є реалізація функцій системи (Repeat Aplication Development).

Тема: Визначення вимог до програмних систем.

План:

1) Загальні підходи до визначення вимог.

2) Класифікація вимог.

3) Аналіз і збирання вимог.

4) Інженерія вимог.

5) Фіксація вимог.

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

1. Вимоги до продукту - охоплюють умови користувачів щодо зовнішнього поводження системи і погляди розробника на деякі параметри системи.

2. Вимоги до ПЗ: системні, функціональні і не функціональні вимоги.

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

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

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

6. Функціональні вимоги – перелік функцій або сервісів, які повинна надавати система, а також обмеження на дані та поводження системи при їхньому виконанні.

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

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

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

· Спектр проблем ПО, при вирішенні яких будуть визначатися послуги системи.

· Функціонального змісту послуг.

· Регламент до операційного обслуговування системи.

В обговоренні вимог до системи беруть участь:

· Представники замовника з декількох професійних груп.

· Оператори, що обслуговують систему.

· Аналітики і розробники наступної системи.

Підсумком обговорення проекту можуть бути: рішення про розгортання реалізаційних робіт на проекті або відмова від нього.

Аналіз вимог починається після обговорення проблематики проекту. Серед обговорюваних вимог можуть виявитись:

· Неочевидні або не однаково важливі, які були взяті зі застарілих джерел і документів замовника.

· Різні типи умов, що відповідають різним рівням деталізації проекту і потребують застосування методів керування ними.

· Постійно змінювані або уточнювальні залежні від унікальних властивостей або значень.

· Складні за формою або змістом, тяжкі для узгодження їх із замовником.

Джерелами відомостей для збирання вимог є:

· Мета і задачі проекту, що формулює замовник майбутньої системи, які повинні осмислюватись замовником.

· Колектив, який виконує реалізацію функцій системи (юзери).

Методи збирання вимог:

· інтерв’ю з представниками замовників системи.

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

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

Остаточно сформульовані вимоги – основа для підпису контракту між розробником і замовником системи.

Інженерія вимог.

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

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

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

Проектування архітектури програмної системи.

План:

1) Загальні підходи до проектування програмних систем.

2) Проектування різних видів архітектури програмних систем.

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

Архітектура системи це - структурна схема компонентів системи, взаємодіючих між собою через інтерфейси. Компоненти можуть складатися з послідовності більш дрібних компонентів та інтерфейсів. Побудова архітектури системи здійснюється шляхом визначення цілої системи, її вхідних і вихідних даних, декомпозицій системи на підсистеми, компоненти або модулі. Та розроблення їхньої загальної структури. Проектування архітектури системи може проводитися різними методами (стандартизованим, об’єктно-орієнтованим, компонентним на іншим), кожен з яких пропонує свій шлях побудови архітектури, а саме визначення концептуальної, об’єктної на інших моделей, за допомогою відповідних конструктивних елементів (блок-схем, графів, структурних діаграм).

Стандартизований підхід визначається державним стандартом ГОСТ 34.601-90. Згідно з цим стандартом процес розроблення поділяється на такі етапи:

· Формування вимог

· Розроблення концепці ї системи

· ескізного

· робочого проекту

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

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

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

Даний стандарт регламентує:

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

· Архітектурне проектування – визначення головних структурних компонентів та особливостей системи.

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

· Детальне робоче проектування – специфікація алгоритмів розв’язків задач, побудова бази даних, і проектування архітектури програмного забезпечення системи.

Проектування системи може здійснюватися на основі об’єктна орієнтованого предметної області засобами UML, який дозволяэ враховувати аспекти властиві діючим особам (акторам) системи, створювати сценарій виконання системи і так далі.

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

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

· Перший рівень – системні компоненти. Здійснюють взаємодію з периферійними пристроями комп’ютерів, використовується при побудові операційних систем.

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

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

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

Трансформація проекту в програму.

Процес трансформації проекту в програму має декілька поширених назв:

· Конструювання

· Кодування

· Програмування

· Реалізація

Реалізація є одним з визначальних етапів розробки. Процес потребує професіоналізму, наслідком яких можуть бути істотні зміни в проекті. Реалізація є першою стадією життєвого циклу, внаслідок якого артефакти створені людиною на попередних стадіях трансформуються у артефакти, які буде передано комп’ютеру, і тому мають бути для нього однозначно зрозумілими. Така трансформація потребує активного діалогу між особою, яка розуміє проект, і комп’ютером, який має трактувати відповідно до проекту реалізацію. Одна із сторін діалогу є людина з непередбачуваною поведінкою, прихильністю до того, що вона має загально відому схильність до забудькуватості та нечіткого формулювання, інша є абсолютно педантичним комп’ютером виконавцем.

Артефакт – це будь який продукт діяльності фахівців з розробки програмного забезпечення.

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

Обрання певного інструментального інструментального засобу визначає стилістичний напрям реалізації. Можна назвати три поширені стилістичні напрямки:

· Лінгвісти – коли програма має вигляд текстів, наближених до натуральних мов, і тому звична для більшості користувачів.

· Математичний стиль – коли шляхом математичного чи логічного розмірковування можна досить точно виразити свої потреби, оскільки семантику математичних чи логічних виразів точно встановлено. Володіння таким стилем доступно тільки вузькому колу фахівців.

· Візуальний стиль – коли для наочного представлення взаємодії об’єктів системи активно використовуються зорові образи.

Тенденції розвитку інструментальних засобів розробки програм є такими, щоб інтегрувати всі три стилі в одній розробці. Зокрема це стосується візуальних мов програмування (Delphi, C#).

Тестування програм та систем.

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

Тестування охоплює такі основні види робіт:

· Розробку програмного продукту на етапах життєвого циклу та верифікацію результатів на кожному з етапів.

· Упорядкування плану тестування і підготовка тестів для перевірки окремих елементів розробленої програми та програми в цілому.

· Керування виконанням тестів та аналіз результатів тестування.

· Повторне тестування.

Тестування, як правило, починається з останнього етапу проектування і включає розробку планів і перевірки правильності функціонування вихідного коду. Кінцевого метою тестування є сертифікат на розроблений програмний продукт. Тестування становить 30-50% трудомісткості робіт зі створення коду. Налагодження означає перевірку програмного об’єкту на наявність у ньому помилок, і наступне усунення їх. При цьому можуть вноситись нові помилки. Як правило, налагодження повинно проводитися в тому випадку, якщо під час розробки програмного продукту використовуються об’єкти-компоненти, які описуються мовами-програмування і пропускаються через компілятори для перевірки переважно синтаксичної правильності.

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

Динамічні методи застосовуються у процесі виконання програм. Вони базуються на побудові графу які пов’язують причини помилок з очікуваним реакціями на ці помилки. У процесі тестування накопичується інформація про помилки, яка використовується для визначення надійності програм.

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

Ефективність перевірки шляхом інспекції досягається тим, що залучені експерти намагаються глянути на проблему «з боку» і піддають її всебічному критичному аналізу. Коли проводиться наскрізний контроль то експерти сприймають також і словесне пояснення розв’язуваної задачі і засобів її проектування. Це та безпосередній перегляд коду дозволяють виявити помилки у логіці та описі алгоритмів.

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

Під динамічним тестуванням розуміють перевірку коректності і надійності розроблюваного програмного забезпечення за допомогою його виконання на ПК. Динамічне тестування ґрунтується на систематичних, статистичних та імітаційних методах. Систематичні методи тестування поділяються на методи в яких програма розглядається як «чорна скринька» та методи, в яких програма розглядається як «біла скринька». Тестування програми за принципом чорної скриньки називається тестування за даними шляхом керування за входами виходами. Мета такого тестування зясувати обставини при якій поведінка програми не відповідає її специфікації. При цьому кількість виявлених помилок у програмі є критерієм якості вхідного тестування. Цього можна досягнути якщо в ролі тестових наборі буде використано всі можливі набори вхідних даних, що неможливо через велику кількість варіантів вхідних даних. Метою динамічного тестування програм за принципом «чорної скриньки» стає виявлення одним тестом максимального числа помилок, а тестування програми обмежується використанням невеликої підмножини всіх можливих вхідних даних. Розрізняють такі види динамічного тестування за принципом чорної скриньки:

· Еквівалентна розбивка – полягає у розбивці вхідної області даних програми на скінченне число класів еквівалентності так, що кожний тест, який є представником певного класу буде еквівалентний будь-якому іншому тесту цього класу. Розрізняють два типи класів еквівалентності:

o Правильні, що подають вхідні дані програми

o Неправильні, що подають помилкові вхідні значення.

· Аналіз граничних значень

· Застосування функціональних діаграм.

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

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

1. Критерій покриття операторів – це набір тестів, у сукупності має забезпечувати проходження кожного оператора не менше одного разу.

2. Критерій тестування гілок (відомий як критерій покриття рішень, критерій покриття переходів) – набір тестів у сукупності має забезпечити проходження кожної гілки принаймні один раз. Відповідає простому структурному тесту, і на практиці поширений більше. Щоб задовольнити цей критерій необхідно побудувати систему шляхів, яка мсчтить усі гілки програми.

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

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

Верифікація відповідає на запитання: «чи коректно реалізовано проект?». Метою процесу верифікації єперевірка відповідності реалізації системи до специфікацій результатів проектування і опису компонентів. Областю застосування верифікації є життєвий цикл програмного забезпечення. Вона дозволяє відповісти на запитання коректно реалізовано проект чи ні.

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

· Планування процедур перевірки і контролю за методиками інспекцій проектних рішень та нагляду за ходом розробки.

· Підвищення рівня автоматизації проектування програм з використанням case систем.

· Перевірка правильності функціонування програм за методами тестування на наборах цільових тестів.

· Структурування системи на модулі, їхні окремі специфікації проектування, реалізація і використання як повторних компонентів.

· Адаптація продукту до умов використання

· Керування проектами.

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

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

Елементи для перевірки

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

· Інтерфейс ний компонент системи та взаємодія об’єктів для функціонування в сучасних розподілених середовищах.

· Засоби доступу до баз даних і файлів, що забезпечують захист від несанкціонованого доступу до них користувачів.

· Документація до програмного забезпечення та системи в цілому.

· Проекти тестів, тестові процедури та вхідні дані.

· Загальні та спеціальні засоби захисту інформації в системі.

Добре організовані способи перевірки на відповідність прийнятим вимогам на етапах проектування життєвого циклу і надання замовникові звітів про перевірку значною мірою впливають на коректність створюваного проекту системи. По закінченню проектування для зазначених елементів відповідно проводиться:

· Перевірка правильності переведення проектів окремих компонентів у вихідний код а також опис їхніх інтерфейсів трасування цих компонентів і відповідних їм інтерфейсів звязку у зіставленні з вимогами замовника до взаємних связків між функціями системи.

· Аналіз спроектованих засобів доступу до файлів або до баз даних на відповідність принципам передачі даних прийнятим у використовуваних системних засобах (СКБД чи ФС)процедура маніпулювання даними і передача результатів перевірки компонент.

· Перевірка спроектованих засобів захисту, використовуваних відповідними компонентами для задоволення вимог замовника.

Після перевірки всіх елементів системи проводяться комплексні роботи з обєднання і валідації всієї системи в цілому. На цьому етапі спочатку тестують систему на множині підготовлених наборів тестів для визначення адекватності і достатності наборів даних для завершеності тестування.

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

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

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

· На збір даних і формування вимог на систему

· На специфікацію елементів проекту

· На інспекцію програм

· На тестування на завершальному етапі.

· На випробуванні системи.

Супровід програмних систем.

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

Серед причин, які можуть зумовити потребу змін можна назвати наступні:

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

· З’ясування під час експлуатації, виконаної замовником, що він не достатньо або не повно висловив свої вимоги, завдяки чому система не відповідає окремим потребам замовника (зміни, за які несе відповідальність постановник проблеми – аналітик предметної області).

· Зміни умов діяльності замовника, які тепер не відповідають раніше поставленим вимогам.

Процес внесення змін є достатньо дорогим – оцінки його вартості сягають 60%-80% від загальної вартості розробки.

Серед видів діяльності і здійснення супроводження розрізняють наступне:

1. Корегуюче супроводження – внесення коректив для усунення похибок, які було знайдено після передачі системи до експлуатації (до 25% зусиль від усього супроводження).

2. Адаптивне супроводження – адаптація продукту до змінених обставин використання після передачі системи до експлуатації (до 25% зусиль від супроводження).

3. Попереджувальне супроводження – це діяльність із забезпечення адаптивного супроводження на стадії розробки.

4. Вдосконалюване супроводження – вдосконалення продукту відповідно до нових вимог, після передачі системи до експлуатації (до 50% зусиль).

5. Запобіжне – запобігання дефектам та перешкодам використання після передачі системи до експлуатації (до 4% зусиль).

Проблеми супроводження.

Найперша проблема супроводження – проблема персоналу. Внесення змін можливе тільки за умови розуміння сенсу того продукту, який потребує змін, та в чому полягають зміни.

Другою проблемою супроводження можна вважати використання формалізованих моделей (згідно певного стандарту), документування на всіх стадіях життєвого циклу розробки.

Третя проблема супроводження – при внесенні змін адекватно коригувати всі використовувані моделі на всіх рівнях прийняття проектних рішень.

Четверта проблема супроводження - це забезпечування трасування (виконання) вимог для всіх моделей подальших етапів життєвого циклу розробки, включно з інструкціями та навчальними засобами для кінцевого користувача. Вони дозволяють уникнути недостатнього розуміння користувачем правил використання системи через недоліки документації.

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

Шоста проблема є проблемою тестування. Внесення змін потребує ретестування системи, бо зміни можуть порушити правильність роботи системи. По-друге – ретестування діючої системи вимагає її призупинення, що для систем керування реальними об’єктами може виявитись небажаним. У цьому разі потрібно створювати дублікат або спеціальний проект системи.

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

Аналіз і досягнення якості програмного забезпечення.

Терміном «якість програмного забезпечення» позначається сукупність властивостей, що визначають спроможність забезпечення задовольнити потреби і запити замовника, які він висловив як вимоги до розробки. Аналіз якостей у програмній інженерії орієнтований на:

· Досягнення необхідної якості програмного забезпечення відповідно до встановлених критеріїв.

· Верифікацію та валідацію на етапах життєвого циклу та оцінку якості виробленого програмного забезпечення (продукту).

· Забезпечення надійності, як основної характеристики гарантії якості програмного забезпечення.

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

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

Для проведення аналізу якості, а також верифікації та валідації програмного забезпечення потрібні знання про організацію управління якістю, про процеси аналізу якості, метою яких є забезпечення додаткових гарантій досягнення заданої якості та її поліпшення. Аналіз якості включає початкову оцінку, яка відповідає процесам виробництва якісного програмного забезпечення: моніторингу, планування, виконання, зміні або підтримці.