- •Модель «кодування-усунення помилок»
- •Каскадна модель
- •Моделі на основі інженерного підходу
- •Об’єктно-орієнтована модель
- •Ітеративна модель (Rational Unified Process)
- •22. Системи керування версіями (локальні системи, централізовані, розподілені).
- •23. Моделі версіювання (блокування-модифікація-розблокування, копіювання-модифікація-об’єдання).
- •Проблема совместного использования файлов
- •Модель Блокирование-Изменение-Разблокирование
- •Модель Копирование-Изменение-Слияние
- •12. Класифікація вимог (нефункціональні, функціональні, системні, вимоги користувачів).
- •18. Структура пз (прикладний, службовий, системний, базовий рівень)
- •20. Формальні методології розробки пз(rup, Scrum, msf, xp, OpenUp, tdd).
- •6.(Корот ко)Классификация по
- •6.Классификация по
- •8.Вимоги
- •27. Якість програмного забезпечення.
- •9. Процес аналізу вимог
- •10. Основні етапи роботи з вимогами до пз. Опис завдань кожного етапу.
- •7. Етапи розробки пз
- •11. Інженерія вимог.
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 - Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом.
На даний момент основними задачами тестування є:
поиск и документирование дефектов качества;
общие рекомендации относительно качества;
проверка выполнения основных предположений и требований на конкретных примерах;
проверка, что продукт функционирует так, как было запроектировано;
проверка, что требования выполнены соответствующим образом.
Тест — это набор контрольных входных данных совместно с ожидаемыми результатами.
Виды программных ошибок:
• Синтаксические
• Ошибки выполнения, выявляемые автоматически (переполнение, защита памяти; несоответствие типов; зацикливание)
• Программа не соответствует спецификации
• Спецификация не соответствует требованиям
Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.