Version 0 Revision History
 Скачать 54.73 Kb.
|
|
Додаток А Version 1.0 Revision History
Table of Contents 1.Introduction 3 1.1Purpose 3 1.2Scope 3 1.3Background and context 3 1.4Project objectives 4 1.5Architectural goals 4 1.6Technical limitations 4 1.7Project Management restrictions 4 1.8Requirements 5 2.Link to documents 5 3.Quality assurance strategy 5 IntroductionPurposeУ документі описані стандарти якості для програмної системи "MoneyHelper" та артефактів, що належать цьому проекту. Ці стандарти в основному походять від вимог програмного забезпечення, документів архітектури програмного забезпечення та відповідають вимогам зацікавлених сторін. ScopeАудиторією цього документа є команда проекту MoneyHelper. Команда відповідає за дотримання стандартів та вимог якості, викладених під час розробки заявки, документування результатів, моніторингу прогресу проекту та тестування якості проекту. Документ гарантії якості охоплює всі важливі аспекти розробки програмного забезпечення, такі як аналіз вимог, архітектура та дизайн, реалізація, тестування та перевірка та прийняття користувачами. Background and contextОсновною бізнес-метою даної роботи є реалізація веб-орієнтованого сервісу, який буде показувати статистику витраткористувача, щоб він був завжди проінформований на що і скільки витрачає грошей. Виконуючи щоденну перевірку своїх витрат, користувач буде тримати своїфінанси під контролем, навчиться збирати, підвищить фінансову грамотність.Це буде корисно всім, особливо в кризу. Project objectivesМетою роботи є створення програмного продукту, який буде корисним для користувачів віком від 15 років, котрі вже мають доходи та хочуть контролювати витрати. Також додаток буде агрегувати собі основні функціонали всіх продуктів, які на даний момент присутні на ринку і за рахунок цього давати користувачеві максимальний функціонал в одному додатку. Architectural goalsДля проектування даної програмної системи була задіяна трирівнева клієнт-серверна архітектура, яка передбачає відділення прикладного рівня від управління даними. Вимоги до трьохрівневої архітектурі: програма-клієнт реалізує інтерфейс користувача, що забезпечує зручний і зрозумілий доступ до функціоналу програмної системи, виконуючи запити і отримуючи відповіді від серверу логіки; сервер логіки реалізує бізнес-логіку і звертається із запитами до сервера «третього рівня» (наприклад, сервера бази даних за даними); сервер третього рівня обслуговує запити сервера застосувань. Technical limitationsПрограмна система матиме технічні обмеження, наприклад, необхідність розміщення сервісу бізнес-логіки на сервері, що підтримує серверний додаток IIS. Також у програмній системі на усіх слоях реалізовані обмеження доступу до сервісів та даних у залежності від ролі користувача у системі. Так, наприклад, користувач без авторизації не має доступу до системи з метою безпеки та збереження даних. Project Management restrictionsПроект MoneyHelper призначений для проектної роботи з навчальної дисципліни Проектний практикум. Тому виконання проекту обмежено за часом і має бути завершено приблизно за 5 місяців. Над проектом працює до п’яти людей. RequirementsВимоги до проекту MoneyHelper задокументовані та наведені у документі Software Requirements Specification, який детально описує передбачувані атрибути поведінки та якості розвитку системи. Link to documentsIEEE Std. 730-2002 IEEE Standard for Software Quality Assurance Plans. Цей документ визначає стандарти написання документа SQAP. Quality assurance strategyЩоб забезпечити якість програмних результатів на кожному етапі розробки програмного забезпечення, буде використовуватися «матриця етапу тестування». Матриця має два елементи. Це фактор випробування та фаза тестування. Ризики, пов'язані з розробкою програмного забезпечення, та процес зменшення ризиків слід вирішувати, використовуючи цю стратегію. Тестовий фактор - це ризик або проблема, яка вирішується, а етап тестування - фаза життєвого циклу розробки програмного забезпечення, в якій проводяться тести. Матрицю слід налаштовувати та розробляти для кожного проекту. Таким чином, адаптуємо стратегію до нашого проекту за чотири етапи: виділяються та класифікуються ризики та проблеми. Вибрані фактори тестування, такі як надійність, портативність тощо, будуть розміщені в матриці відповідно до їхніх пріоритетів; визначення етапів процесу розробки. Етап повинен бути записаний у матриці; визначення ділових ризиків програмного забезпечення. Ризики будуть розподілені за рівнями; вирішення, які ризики будуть покладені на кожному етапі розробки. Матриця є частиною стратегії забезпечення якості, і, як зазначалося вище, ця матриця буде використовуватися на кожному з етапів життєвого циклу проекту для виявлення ризиків, пов'язаних з кожною з фаз розробки, щодо факторів тестування. Ризики також супроводжуватимуться стратегіями пом'якшення наслідків, і у випадку, якщо ризик матеріалізується у проблему, застосовуватиметься відповідне пом'якшення. Саме з цих причин тут згадується про матрицю в окремому розділі документа і не змішується з іншими розділами документа, щоб уникнути повторення. 4. Documentation 4.1 Minimum documentation requirements Для відповідності програмного забезпечення технічним вимогам, необхідною є наступна документація. 4.1.1 Concept of operations Концепція операцій може бути написана постачальником (внутрішнім чи зовнішнім), замовником або обома. SRD повинен враховувати основні очікувані набори функцій та обмеження, накладені на роботу системи. Кожна вимога повинна бути однозначно визначена та визначена таким чином, щоб її досягнення можна було об'єктивно виміряти. Для забезпечення відповідності та повноти вимог користувача слід використовувати активний процес перевірки. 4.1.2 Software Requirements Specification Специфікація програмного забезпечення повинна використовуватися для перевірки адекватності та повноти документації проекту. Документ вимог до програмного забезпечення, який визначає всі функціональні вимоги, вимоги до атрибутів якості та обмеження щодо програмної системи MoneyHelper. 4.1.3 Software testing plans План тестування програмного забезпечення необхідний для документації результатів виконаних планів тестування. Конкретний звіт повинен містити інформацію щодо тестування системного аспекту, що тестується у даний момент. Звіти будуть перевірені на покрокових сесіях. 4.1.4 Software Testing report Використовується для перевірки проектної документації на повноту. В документації повинно бути описано, як побудувати програмне забезпечення відповідно до вимог SRD. Документ повинен описувати компоненти програмного забезпечення, включаючи бази даних та внутрішні інтерфейси. 4.1.5 User documentation Документація користувача повинна описувати ходи управління даними, послідовності введення, параметри, обмеження програми та всю іншу важливу інформацію для програмного продукту. Усі повідомлення про помилки слід визначити та описати. Повинні бути описані всі коригувальні дії для виправлення помилок, що спричиняють повідомлення про помилки. 5. Goals 5.1 Quality goals of each phase
6. Reviews and audits 6.1 Product reviews 6.1.1 Official reviews 1. До відправки документа клієнту команда SQA перегляне список документів, створений розробниками програмної системи. 2. Команда SQA забезпечує внесення необхідних змін до документів і що документ буде опублікований до зазначеної командою . У разі виявлення будь-яких недоліків документ буде передано на розгляд команді з управління програмним забезпеченням. 6.1.2 Informal reviews A. Оформлення покрокових інструкцій B. Покрокове оформлення коду C. Огляди базової якості Огляди базової якості забезпечують: • Тестування та перевірку модулів та коду перед випуском; • Документацію та список змін документу про програмний модуль; • Проведення перевірочного тестування; • Документацію функціональності; • Відповідність документації стандартам документу, як визначено в SPMP; • Інструменти та методи перевірки та перевірки компонентів підсистеми на місці. 6.1.3 Change request process Зміни, якщо такі є, до будь-якого з наведених нижче робочих продуктів, вивчаються, оцінюються їх наслідки, документуються, переглядаються та затверджуються до узгодження та включення їх у продукт.
6.2 Quality assurance reviews Для усунення недоліків та помилок, виконується така перевірка: 1. Згідно з планом якості проекту проводиться перевірка планів проекту та їх результатів. Команди проекту можуть обирати додаткові продукти для огляду та перевірки. 2. Відгуки, що формують оцінку того, чи відповідає продукт критеріям якості, зазначеним у документах. 3. Огляд проводить незалежний персонал, що не має відношення до команди розробки та/або розробників тестування. 4. Відгуки про якість програмного продукту не можуть слугувати свідоцтвом якості роботи розробника. 5. Виявлені в оглядах дефекти відстежуються до їх закриття. Якщо робочий виріб потрібно випустити без відстеження дефектів до закриття, проводиться аналіз ризику для оцінки ризику подальшого продовження. 7. Tools and methods Проект MoneyHelper використовує наступну стратегію для вибору інструменту в проекті: 1) Засіб тестування вибирається на основі основних функціональних можливостей проекту. 2) Відповідність критеріїв вибору інструменту досвіду команди з контролю якості. 3) Вибір інструменту залежить не тільки від доступності, але й від вимог стандарту якості проекту. 7.1 Tools and techniques for ensuring the quality of functional requirements Для забезпечення якості функціональних вимог розробникими MoneyHelper застосовуються наступні методики: 1. Експертна перевірка Усі артефакти (переважно документи, схеми) створюються та зберігаються у хмарних сховищах, що належать команді. Члени команди працюють над конкретними розділами артефактів, а потім обговорюють відповідні теми на зустрічі. Ця методика допомагає усунути будь-яку неясність у вимогах і гарантує, що всі розуміють, як повинна поводитися система після впровадження. 2. Огляд замовника Після експертної перевірки команда програмної системи MoneyHelper надсилає документацію, у тому числі і вимоги, наставнику проекту. Наставник проекту формує відгуки щодо документації. Відгуки наставника обговорюються та включаються в документ, а потім знову надсилаються на огляд, який, в залежності від необхідності змін, може бути остаточним. 3. Формування матриці простежуваності Матрицю простежуваності використовують для відстеження джерела (авторів) будь-якої вимоги, а також будь-яких змін вимог. Матриця відстеження також допоможе команді з контролю якості під час тестування системи додатків. 4. Регресійне тестування Після виправлення помилок тестування на регресію допоможе переконатися, що помилки правильно виправлені та що нові помилки не з’являються. Розробник MoneyHelper має намір використовувати наступні інструменти для перевірки та перевірки функціональних вимог: 1. Excel: Microsoft Excel буде використовуватися для управління матрицею відстеження вимог. 2. Redmine Collaboration Software буде використовуватися для визначення пріоритетів вимог та призначення завдань членам команди. 7.2 Tools and techniques to meet the quality attribute requirements Розробник програмної системи MoneyHelper має намір здійснити перевірку атрибутів якості, якими повинна володіти система. На етапі проектування команда розробляла сценарії атрибутів якості. Після етапу розробки та під час первинного впровадження системи команда використовуватиме спеціальні інструменти для вимірювання того, чи відповідає наша система якісним характеристикам чи ні. Ці атрибути якості отримані з документа специфікації вимог програмного забезпечення (SRS) Empruler.
8. Testing strategy Тестування має на меті досягнення двох основних цілей: 1) Виявити збої та дефекти в системі. 2) Виявити невідповідність між вимогами та реалізацією. Для досягнення цих цілей стратегія тестування системи MoneyHelper складатиметься з чотирьох рівнів тестування. Це модульне тестування, інтеграційне тестування, приймальне тестування та регресійне тестування. У наступних підрозділах викладено ці рівні тестування, в яких ролях команда розробників відповідає за їх розробку та виконання, а також критерії для визначення їх завершеності (відповідність фактичної якості проекту вимогам). 8.1 Unit testing Метою модульних тестів є тестування невеликого фрагменту вихідного коду. Модульні тести корисні для раннього виявлення помилок, а також для перевірки архітектури та дизайну системи. Ці тести виконуються по одній функції за раз і написані розробником. В ідеалі перевіряється кожен логічний шлях у компоненті та кожен рядок коду. Однак покриття кожного рядка коду модульними тестами в більшості випадків не є економічно ефективним ні за часом, ні за вартістю. Будуть визначені цілі охоплення коду, щоб гарантувати, що найважливіший код добре охоплений тестами, при цьому ефективно використовуючи час розробника. Модульне тестування розробники виконуватимуть на кожному з трьох етапів розробки, зазначених у Плані проекту. Усі модульні тести повинні бути виконані та передані перед кожною реєстрацією в систему управління. Блокові тести також будуть запускатися автоматично як частина безперервного процесу інтеграції. Результати цих тестових запусків будуть зберігатися системою безперервної інтеграції та надсилатись електронною поштою команді розробників. 8.2 Integration testing При інтеграційному тестуванні буде виконано кілька модулів разом, щоб оцінити, як функціонуватиме система в цілому. Інтеграційні тести будуть написані та виконані командою тестувальників. Інтеграційні тести будуть проводитися в певних точках, в ідеалі, коли один компонент взаємодіє з іншим через інтерфейс. Інтеграційні тести будуть зосереджені на цих конкретних точках взаємодії двох компонентів. Це тестування взаємодії двох модулів зрештою призводить до наскрізного тестування системи. Кожен тест написаний для перевірки однієї або декількох вимог, використовуючи сценарії або випадки використання, зазначених в документі вимог. Інтеграційні тести також включають стресове або об'ємне тестування для великої кількості користувачів. 8.3 Acceptance testing Приймальне тестування - це функціональне тестування, яке замовник використовує для оцінки якості системи та переконання, що вона відповідає їхнім вимогам. Тестові сценарії, як правило, менші, ніж в інтеграційному чи модульному тестуванні, через обмежені часові ресурси замовника. Приймальні випробування охоплюють систему в цілому і проводяться з реалістичними даними, використовуючи сценарії або випадки використання, зазначені у вимогах, як керівництво. 8.4 Regression testing Метою регресійного тестування є виявлення будь-яких нових помилок, введених у раніше працюючий код через модифікації. Таким чином, набір тестів на регресію буде запускатися щоразу, коли система змінюється. Регресійні тести створюватиме і проводитиме команда тестування. Регресійне тестування складатиметься з проведення раніше письмових автоматизованих тестів або перегляду раніше підготовленого мануального тестування. Виправлення помилок зазвичай представляє нові проблеми, і тому під час регресійного тестування буде заплановано та проведено декілька циклів «перевірка/виправлення». 8.5 Test completion criteria На кожному етапі розробки будуть проводитись тести, а їх повнота оцінюватиметься за такими критеріями: Модульне тестування завершити, коли: - Принаймні 80% рядків коду, що є самописним (не належить до сторонніх бібліотек) (включаючи всі критичні розділи) - Протестовано усі знайдені основні та незначні помилки були зареєстровані та виправлені. Регресійне тестування завершити, коли: - Принаймні 90% функцій модулів охоплено, включаючи всі модифіковані модулі. - Закінчено принаймні два цикли тестування / виправлення. - Усі проблеми/дефекти були зареєстровані та виправлені. Інтеграційне тестування завершити, коли: - 100% інтерфейсів модулів протестовано. Приймальне тестування завершити, коли: - Клієнт переконується, що продукт відповідає узгодженим критеріям вимог. 9. Organization 9.1 Available resources that the team intends to assign Впровадження заходів з контролю якості буде проходити за тією ж схемою, при цьому десять відсотків часу всієї команди буде відведено діяльності з контролю якості. Зазвичай, 4 години будуть розподілені між видами контролю якості на одну людину. Точні позначення будуть сильно залежати від наявності членів команди та їх сильних та слабких сторін у діяльності з контролю якості. 9.2 Quality assurance team Обговорення заходів з контролю якості може бути заплановано та проведено таким чином, щоб члени команди могли обговорювати ролі та обов'язки. Крім того, члени команди співпрацюватимуть для вибору ролей для огляду, щоб їх заповнили члени команди, які найкраще відповідають характеристикам ролі. Керівник SQA відповідатиме за управління командою SQA і буде контролювати та корегувати ситуацію, коли команда буде стикатися з перешкодами під час прийняття рішення. Для кожного виду діяльності члени команди матимуть визначені ролі. Можливі ролі визначені нижче.
Протягом процесу SQA кожен член команди відповідає за: • своєю роллю та обов'язками; • цілі кожної діяльності, з якою вони пов’язані; • процеси, які мають бути здійснені. 9.3 Artifact quality management Коли в систему вносяться зміни, будуть проведені огляди / тести на артефакти, на які вплинули ці зміни. Усі випробувальні та оглядові заходи повинні мати документацію із зазначенням: Процес - як слід проводити певний метод чи техніку. Цілі - це визначатиме цілі QA діяльності, пов’язаної з артефактами. Результати - результати методів і прийомів та аналіз та висновки, що формуються в результати. Рецензент - ролі та відповідальність членів команди SQA щодо артефактів. Примітки - будь-які коментарі стосовно артефакту, які будуть корисними для успішного використання артефакту. Повинна бути створена система управління версіями та документами, яка дозволяє команді легко повернутися до попередньої версії у випадку виявлення проблем у зв'язку із зазначеними змінами. 9.4 The process of assigning priority between quality assurance methods Цей розділ містить покрокову схему процесу, що використовується для визначення пріоритетів методів контролю якості, що використовуються для оцінки артефактів процесу. 1. Створити контрольний список характеристик системи, які необхідно підвергнути тестуванню; вони будуть створені відносно вимог та атрибутів якості. 2. Виберіть методи , які відповідають визначеним характеристикам. 3. Команда SQA повинна брати участь у діалозі та звертати увагу кожній техніці для кожного пункту контрольного списку з точки зору того, наскільки корисна кожна техніка для цілей тестування щодо критеріїв, які представляють інтерес; рейтинг буде 1-10 з 1 найслабшим і 10 найсильнішим. 4. Команда SQA проводить оцінку методів, які можуть бути корисними для тестування; 5. Команда повинна домовитись про конкретну техніку та вступити в діалог для вирішення будь-яких питань з певною технікою. 6. Вагомість та згода більшості команд повинні бути вирішальним фактором для технік. 9.5 The quality strategy is divided into tasks
9.6 Measures of the quality assurance process Вимірювання процесів SQA служить критерієм оцінки, який покаже, наскільки ці процеси корисні для підвищення якості системи, та дозволить сформувати шляхи покращення цих процесів. Ці вдосконалення можуть бути результатом розширення, виключення або модифікації поточного атрибута процесу. Процеси забезпечення якості оцінюватимуться на основі: • Швидкість пошуку дефектів • Швидкість виправлення дефектів • Щільність дефектів • Тип виявлених помилок (критичні, основні, незначні) Цілі цих показників для доброго та здорового процесу такі:
Подальші дії та відстеження: Після завершення огляду та тестування буде визначено міру успіху чи невдачі. У разі успіху процес забезпечить, щоб робочий продукт був реалізований до випуску. У разі виникнення помилки помилки будуть відстежуватися у трекінговій системі щодо відповідного артефакту. Будуть вжиті відповідні дії для забезпечення переоцінки та внесення виправлень. Критерії виходу: Критерії виходу, як визначено в плані, залежать від цілей, встановлених для конкретних розділів плану. Таким чином, щоразу, коли відбувається процес перегляду або тестування, мета, яка стосується продукту, що випускається, або робочого продукту, що тестується або перевіряється, буде служити критерієм виходу для цього розділу. 10. Dictionary 10.1 Acronyms FTR - Formal Technical Review SAD - Software Architecture Document SRS - Software Requirement Specification |