Лекція 2. Елементи програмної інженерії.

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

2.2.Створення ПЗ повинно вкладатися до бюджету

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

зчого найчастіше складаються витрати на створення ПЗ:

•60% - розробка;

•40% - тестування.

Думаючи про те, скільки грошей витратити розробку, не забувайте, що подальші етапи віднімуть не менше засобів.

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

2.3.Створення ПЗ повинно вкладатися в терміни

Запорука успіху - строге дотримання наступних принципів:

•Грамотне планування.

•Аналіз можливих рисок і способи реагування.

•Боротьба за чіткі межі проекту.

•Мотивування співробітників.

3. Забезпечення надійності розробки ПЗ

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

o попередження помилок; o автовизначення помилок; o автовиправлення помилок; o стійкість до помилок.

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

o боротьба зi складністю

o забезпеченняі точності інтерпретації

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

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

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

16

Лекція 2. Елементи програмної інженерії.

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

3.1.Забезпечення точності інтерпретації

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

1.Зрозуміти завдання;

2.Скласти план (включаючи цілі і методи рішення);

3.Виконати план (перевіряючи правильність кожного кроку);

4.Проаналізувати отримане рішення.

3.2.Подолання бар'єру між користувачем і розробником

Як забезпечити, щоб ПЗ виконувала те, що користувачеві розумно чекати від неї? Для цього необхідно правильно зрозуміти, по-перше, чого хоче користувач, і, по-друге, його рівень підготовки і навколишнє його оточення. Тому слідує - привертати користувача в процеси ухвалення рішень при розробці ПЗ, - ретельно освоїти особливості його роботи (краще всього - побувати в його "шкурі").

3.3.Контроль ухвалюваних рішень

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

З урахуванням специфіки розробки ПЗ необхідно застосовувати скрізь, де це можливо o суміжний контроль

o поєднання як статичних, так і динамічних методів контролю.

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

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

3.4.Програмні інженери і наукове середовище

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

o Нові технології.

o Нові методи, алгоритми.

o Аналіз нових перспективних розробок.

o Дослідницька робота в суміжних областях.

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

o • Там, де є фахівці, але немає часу і ресурсів для досліджень.

Цей підхід широко застосовується сучасними IT-компаниями: Intel, Microsoft, IBM та ін.

17