27. Якість програмного забезпечення.

Якість програмного забезпечення — характеристика програмного забезпечення, ступінь відповідності ПЗ до вимог. При цьому вимоги можуть трактуватись по-різному, що породжує декілька незалежних визначень терміну. Частіше за все, використовують визначення ISO 9001, згідно з яким якість — це «ступінь відповідності наявних характеристик вимогам».

Якість коду

Якість коду може визначатись різними критеріями. Деякі з них мають значення тільки з точки зору людини. Наприклад, форматування тексту програми — неважливо для комп'ютеру, але може мати велике значення для супроводу. Багато з існуючих стандартів кодування, що визначають специфічні для мови програмування угоди та задають низку правил, мають на меті полегшити супровід ПЗ в майбутньому. Також існують інші критерії, що визначають чи «гарно» написаний код, наприклад, такі, як структурованість — ступінь логічного розділення коду на блоки.

Деякі фактори:

· Читабельність коду

· Легкість підтримки, тестування, відлагодження, виправляння помилок, рефакторингу та портування

· Низька складність коду

· Коректність обробки винятків

· Методи покращення якості коду: рефакторинг.

Фактори якості

Фактори якості — це нефункціональні вимоги до ПЗ, що відносяться до, наприклад, надійності та продуктивності програм.

Деякі з факторів якості:

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

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

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

· Можливість портування. Легкість в адаптації програми до інших умов: архітектури, платформі, операційній системі тощо.

· Узгодженість. Вся документація та код повинні виконуватися за єдиними угодами, використовувати єдині формати та позначення

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

· Зручність використання.

· Надійність.

· Безпечність.

Точка зору користувача

Окрім технічної точки зору на якість ПЗ, є також оцінка якості з позиції звичайного користувача. Для цього аспекту якості використовують термін «англ. usability». Для оцінки цього аспекту якості, відповідають на наступні питання:

· Чи є інтерфейс користувача інтуїтивно зрозумілим?

· Наскільки легко виконувати прості, часті операції?

· Наскільки легко виконувати складні операції?

· Чи зрозумілі повідомлення про помилки?

· Чи завжди програма поводить себе відповідно до очікувань користувача?

· Чи є документація до ПЗ, наскільки вона повна?

· Чи є інтерфейс користувача само-документуючим?

· Чи завжди затримки відповіді від програми є прийнятними?

28. Рефакторинг.

Рефакторинг или реорганизация – это полное или частичное изменение структуры кода программы с помощью ряда преобразований без изменения функциональности программы.

Цель рефакторинга — сделать код программы легче для понимания; без этого рефакторинг нельзя считать успешным.

Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет ее работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу.

ВИДЫ РЕФАКТОРИНГА

• составление методов (Extract Method, Inline Method, Introduce Explaining Variable, Substitute Algorithm)

• перемещение функций между объектами (Move Method, Move Field, Inline Class, Extract Class)

• организация данных ( Replace Data Value with Object, Replace Array with Object, Encapsulate Field)

• упрощение условных выражений (Replace Conditional with Polymorphism, Consolidate Duplicate Conditional Fragments, Remove Control Flag), упрощение вызовов методов (Rename Method, Add Parameter, Hide Method, Replace Exception with Test)

• решение задач обобщения (Pull Up Field/Method, Push Down Field/Method, Extract Interface)

• крупные рефакторинги (Trease Apart Inheritance, Convert Procedural Design to Object).

Причины применения рефакторинга

Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:

- необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;

- необходимо исправить ошибку, причины возникновения которой сразу не ясны;

- преодоление трудности в командной разработке, которые обусловлены сложной логикой программы.

29. Задачі етапу тестування програмного забезпечення(Нужно дополнить).

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

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

1980 - Процесс выполнения программы с намерением найти ошибки.

1987 - Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов.

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

1999 - Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц.

2004 - Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом.

На даний момент основними задачами тестування є:

• поиск и документирование дефектов качества;

• общие рекомендации относительно качества;

• проверка выполнения основных предположений и требований на конкретных примерах;

• проверка, что продукт функционирует так, как было запроектировано;

проверка, что требования выполнены соответствующим образом.

Тест — это набор контрольных входных данных совместно с ожидаемыми результатами.

Виды программных ошибок:

• Синтаксические

• Ошибки выполнения, выявляемые автоматически (переполнение, защита памяти; несоответствие типов; зацикливание)

• Программа не соответствует спецификации

• Спецификация не соответствует требованиям

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