К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Інженерія вимірювання ПЗ проводиться з метою визначення окремих характеристик продуктів і процесів (наприклад, кількість рядків у продукті, помилок у специфікаціях і т.п.). Попередньо проводяться роботи з вибору метрик процесів і продуктів з урахуванням обставин, що впливають на вимірювання характеристик програмного продукту. Інженерії вимірювання – удосконалювання процесів керування проектом; оцінювання часових витрат і вартості ПЗ, їх регулювання; визначення категорій ризиків і відстеження чинників для регулярного розрахунку ймовірностей їх виникнення; перевірка заданих у вимогах показників якості окремих продуктів і проекту в цілому [9]. Проведення різного роду вимірювань – важливий принцип будь-якої інженерної діяльності. У програмному проекті результати вимірювань необхідні замовнику і споживачу для встановлення правильності реалізації проекта. Без вимірювань в інженерії ПЗ процес керування стає неефективним і перетворюється в самоціль. Розділ 1 41 1.2.8. Базовий процес программної інженерії Процес інженерії – є метарівнем, що визначає основні поняття, способи реалізації, оцінювання, вимірювання, дії з керування змінами й удосконалення самого процесу. Як уже згадувалася в п. 1.1.2., для оцінювання й удосконалення процесу програмної інженерії застосовується модель зрілості CMM [11], яку розроблено Інститутом програмної інженерії SEI (Software Engineering Institute) США. Ця модель встановлює рівні готовності організації-розробника ПЗ створювати задовільно, середньо, добре і дуже добре програмну продукцію. Поняття рівня готовності визначається наявністю в організації необхідних ресурсів (людських, програмних, технічних і фінансових), стандартів і методик, а також здатністю колективу створювати програмні продукти. Модель СММ має п'ять рівнів. Перший і другий рівні фіксують недостатню готовність виконувати розробку продукту. Третій – п'ятий рівні характеризують певний ступінь готовності, зрілості і здатності фахівців (а, значить, і організації) виготовляти, відповідно, середній, гарний і відмінний продукт. Чим вище рівень зрілості, тим більше вимог ставиться до процесу програмної інженерії, придатного для виконання цілей і задач утворення продукту, що задовольняє користувача. Існують різновиди цієї моделі: СММ – SW (Software) для оцінки зрілості ПЗ, CMMI (CMM Integrated) – для обліку потреб великих державних структур в ПЗ (США), а також інші моделі, наприклад, Bootstrap – для оцінки зрілості малих і середніх комерційних компаній, стандарт ISO 15504 (Software Process Improvement and Capability) – для удосконалення процесу (наприклад, удосконалювати процес на другому рівні, щоб одержати сертифікат на третій рівень зрілості). Концепція зрілості процесу програмної інженерії ґрунтується на процесі ПЗ (software process), широті його можливостей (software process capability), результативності (software process performance) і зрілості (software process maturity). Процес ПЗ у моделі СММ – це множина діяльностей (activities), методів (methods), практичних прийомів (practices), що використовують при розробки ПЗ шляхом планування робіт і оцінювання проміжних результатів, які приводять до кінцевого продукту високої якості. Область знань «Процес програмної інженерії (Software Engineering Process)» складається з таких розділів: – концепції процесу інженерії ПЗ (Software Engineering Process Concepts), – інфраструктура процесу (Process Infrastructure), – визначення процесу (Process Definition), – оцінки процесу (Process Assessments), – якісний аналіз процесу (Qualitative Process Analysis), – виконання і змінювання процесу (Process Implementation and Change). Концепції процесу інженерії ПЗ – задачі і дії, що зв'язані з керуванням, реалізацією, оцінкою, змінами й удосконаленням процесу і/або ПЗ. Ціль керування процесом – це створення інфраструктури процесу, виділення необхідних ресурсів, планування реалізації і зміни процесу з метою впровадження його у практику і, нарешті, оцінка переваг від його впровадження у практику проектування ПЗ. Інфраструктура процесу містить у собі ресурси (людські, технічні, інформаційні і програмні), стандарти, методики керування якістю, проектом і структуру колективу розробників ПЗ типу: команда, бригада, експериментальна фабрика (Experimental Factory), каркас виробництва на лінії продуктів (Framework 42 Розділ 1 for Product Line Practice) і ін. До основних задач інфраструктури належать керування і комунікації в колективі, інженерні методи виробництва програмного продукту й удосконалення процесу з накопиченим досвідом розробки ПЗ. Визначення процесу ґрунтується на: типах процесів і моделей (каскадна, спіральна, ітераційна й ін.); моделях ЖЦ процесів і засобів, стандартах ЖЦ ПЗ ISO/IEC 12207 і ISO/IEC 15504, IEEE std. 1074 і IEEE std. 1219; методах і нотаціях подання процесів і автоматизованих засобів їх підтримки. Основною метою процесу є підвищення якості одержуваного продукту, поліпшення різних аспектів програмної інженерії, автоматизація і удосконалення процесів. Оцінка процесу проводиться з використанням відповідних моделей і методів оцінки. Наприклад, оцінка потенційної здатності фахівця до розроблення і виконання відповідного процесу, а також оцінювання зрілості процесу, згідно за яким проводиться розроблення ПЗ. Оцінки стосуються також технічних робіт у сфері програмної інженерії, керування персоналом і якості ПЗ. Для цього проводяться експериментальні дослідження середовища, збирання інформації, моделювання, класифікація отриманих помилок і дефектів, а також статичний аналіз недоліків процесу порівняно з існуючими стандартами (наприклад, ISO/IEC 12207) і потенційних аспектів необхідності вдосконалювати процес. Якісний аналіз процесу полягає в ідентифікації і пошуку «слабких місць» у процесі створення ПЗ на початку його функціонування і після експлуатації. Розглядається такі техніки аналізу: огляд даних і порівняння процесу з основними положеннями стандарту ISO/IEC 12207, збирання даних про якість процесів; аналіз головних причин відмов у функціонуванні ПЗ, відкіт назад від точки виникнення відхилення до точки правильної роботи системи для з'ясування причин зміни процесу. На якість результатів проекту і процесу впливають застосовувані інструменти і досвід фахівців. Виконання і зміна процесу. Існує ряд фундаментальних аспектів вимірювань в програмній інженерії, що покладені в основу детальних вимірювань процесу. Оцінка вдосконалення процесу проводиться шляхом встановлення кількісних характеристик процесу і продуктів. Після процесу розгортання ПЗ виконуються обчислення функцій і аналіз отриманих результатів, які можуть застосовуватися при оцінюванні якості, продуктивності, трудовитрат та ін. Якщо результати не задовольняють користувача ПЗ, проводять обговорення і приймають рішення щодо необхідності виправлення ситуації шляхом або внесення зміни у процес, або вдосконалення процесу, а також організаційну структуру і деякі інструменти керування змінами. 1.2.9. Методи і інструменти програмної інженерії Методи забезпечують проектування, реалізацію і виконання ПЗ. Вони накладають деякі обмеження на інженерію ПЗ у зв'язку з особливостями застосування їхніх нотацій і процедур, а також забезпечують оцінку і перевірку процесів і продуктів. Інструменти забезпечують програмну підтримку окремих методів інженерії ПЗ для автоматизованого виконання задач процесів ЖЦ. Область знань «Методи та інструменти інженерії ПЗ (Software Engineering Tools and Methods)» складається з розділів: – інструменти інженерії ПЗ (Software Engineering Tools), Розділ 1 43 – методи інженерії ПЗ (Software Engineering Methods). Методи інженерії ПЗ – це евристичні методи (heuristic methods), формальні методи (formal methods) і методи прототипування (prototyping methods). Евристичні методи містять у собі: структурні методи, засновані на функціональній парадигмі; методи, орієнтовані на структури даних, якими маніпулює ПЗ; об’єктно-орієнтовані методи, що розглядають предметну область як колекцію об'єктів; методи, орієнтовані на конкретну область застосування, наприклад, на системи реального часу, безпеки та ін. Формальні методи засновані на формальних специфікаціях, аналізі, доведенні і верифікації програм. Специфікація записується мовою, синтаксис і семантика якої визначені формально і засновані на математичних концепціях (алгебрі, теорії множин, логіці). Розрізняються наступні категорії формальних методів: – мови і нотації специфікації (specification languages and notations), орієнтовані на модель, властивості і поведінку; – уточнення специфікації (refinement specification) шляхом трансформації в кінцевий результат, близький до кінцевого програмного продукту, що виконується; – методи верифікації/доведення (verification/proving properties), що використовують твердження (теореми), перед- і постумови, формально описуються і застосовуються для встановлення правильності специфікації програм. Методи доведення застосовувалися в основному в теоретичних експериментах. Понад 25 років їх застосування було обмежено через трудомісткість і економічну невигідність. У 2005 р. проблема верифікації знову набула актуальності у запропонованому новому міжнародному проекті «Цілісний автоматизований набір інструментів для перевірки коректності ПС» (Т. Хоар, «Открытые системы», 2006, № 6), який поставив наступні перспективні задачі: – розробка єдиної теорії побудови й аналізу програм; – побудова багатостороннього інтегрованого набору інструментів верифікації на усіх виробничих процесах – розроблення формальних специфікацій, їх доведення і перевірка правильності, генерація програм і тестових прикладів, уточнення, аналіз і оцінка; – створення репозитарію формальних специфікацій, верифікованих програмних об'єктів різних типів і видів. Формальні методи верифікації будуть охоплювати всі аспекти створення і перевірки правильності програм. Це приведе до створення потужної верифікованої виробничої основи і сприятиме значному зменшенню помилок у ПЗ (стосовно доведення і верифікації див. розділ 6). Методи прототипування (Prototyping Methods) засновані на використанні прототипу ПЗ для моделювання на ньому завдань нової системи і базуються на: – стилях прототипування, що уособлюють тривалість використання прототипів, наприклад, стиль створення тимчасово використовуваних прототипів (throw away), – моделях еволюційного прототипування – перетворення прототипу в кінцевий продукт і розроблення специфікацій, відповідно до якої він виконується; – техніках оцінки/дослідження (evaluation) результатів прототипування. 44 Розділ 1 Інструменти інженерії ПЗ забезпечують автоматизовану підтримку процесів розроблення ПЗ і містять у собі множину інструментів, що охоплюють усі процеси ЖЦ. Інструменти роботи з вимогами (Software Requirements Tools) – це: – інструменти розробки (Requirement Development) і керування вимогами (Requirement Management), орієнтовані на аналіз, збирання, специфікування і перевірку вимог; – інструменти трасування вимог (Requirement traceability tools) є невід'ємною частиною роботи з вимогами, їх функціональний зміст залежить від складності проектів і рівня зрілості процесів. Інструменти проектування (Software Design Tools) – це інструменти для створення ПЗ із застосуванням базових нотацій (структурної SADT/IDEF, моделювання UML і т.п.). Інструменти конструювання ПЗ (Software Construction Tools) – це інструменти для трансляції і об’єднання програм. До них належать: – редактори програм (program editors) і програми редагування загального призначення; – компілятори і генератори коду (compilers and code generators) як самостійні засоби об'єднання програмних компонентів в інтегрованому середовищі для одержання вихідного продукту з використанням препроцесорів, складальників, завантажників і ін.; – інтерпретатори (interpreters), які забезпечують контрольоване виконання програм за їх описом. Намітилася тенденція злиття інтерпретаторів і компіляторів (наприклад, Java, в .NET); – відлагоджувачі (debuggers), призначені для перевірки правильності опису вихідних програм і усунення помилок; – інтегроване середовище розробки (IDE – integrated development environment) та бібліотеки компонентів (libraries components), що є утворюють середовище виконання процесу розроблення ПС; – програмні платформи (Java, J2EE і Microsoft .NET) і платформи для розподілених обчислень (CORBA і WebServices, тощо). Інструменти тестування (Software Testing Tools) – це: – генератори тестів (test generators), що допомагають у розробці сценаріїв тестування; – засоби виконання тестів (test execution frameworks), які забезпечують виконання тестових сценаріїв і відслідковують поведінку об'єктів тестування; – інструменти оцінки тестів (test evaluation tools), які підтримують оцінювання результатів виконання тестів і ступеня відповідності поведінки тестованого об'єкта очікуваній поведінки; – засоби керування тестами (test management tools), які забезпечують інженерне керування процесом тестування ПЗ; – інструменти аналізу продуктивності (performance analysis tools), кількісної її оцінки та оцінки поводження програм у процесі виконання. Інструменти супроводу (Software Maintenance Tools) містять у собі: – інструменти полегшення розуміння (comprehension tools) програм, наприклад, різні засоби візуалізації; Розділ 1 45 – інструменти реінженерії (reengineering tools) підтримують діяльність з перетворення програм і зворотної інженерії (reverse engineering) для відновлення (артефактів, специфікації, архітектури) застарілого ПЗ або генерації нового продукту. Інструменти конфігураційного керування (Software Configuration Management Tools) – це: – інструменти відстеження (tracking) дефектів; – інструменти керування версіями; – інструменти керування складанням, випуском версії (конфігурації) продукту та його інсталяції. Інструменти керування інженерною діяльністю (Software Engineering Management Tools) підрозділяються на: – інструменти планування і відстеження ходу проектів, кількісної оцінки зусиль і вартості робіт у проекті (наприклад, Microsoft Project 2003); – інструменти керування ризиками, які використовуються для ідентифікації, моніторингу ризиків і оцінки нанесеного ушкодження; – інструменти кількісної оцінки властивостей ПЗ шляхом вимірювань і розрахунків остаточного значення надійності і якості. Інструменти підтримки процесів (Software Engineering Process Tools) розділені на: – інструменти моделювання та опису моделей ПЗ (наприклад, UML і його інструменти); – інструменти керування програмними проектами (наприклад, Microsoft Project); – інструменти керування конфігурацією для підтримки версій і всіх артефактів проекту. Інструменти забезпечення якості (Software Quality Tools) діляться на дві категорій: – інструменти інспектування для підтримки перегляду (review) і аудиту; – інструменти статичного аналізу артефактів, даних, потоків робіт і перевірки їх властивостей на відповідність показникам. Додаткові аспекти інструментального забезпечення (Miscellaneous Tool Issues) стосуються: – техніки інтеграції інструментів (платформ, представлень, процесів, даних) для їх природного сполучення в інтегрованому середовищі; – метаінструментів для генерації інших інструментів для ПЗ; – оцінки інструментів при їх еволюції. 1.2.10. Якість програмного забезпечення Якість ПЗ – набір властивостей продукту (сервісу або програм), що характеризують його здатність задовольнити встановлені або передбачувані потреби замовника. Поняття якості має різні інтерпретації залежно від конкретної програмної системи і вимог до неї. Крім того, у різних джерелах таксономія (класифікація) характеристик у моделі якості розрізняється. Моделі мають різну кількість рівнів і повністю або частково збігаються щодо набору характеристик якості. Наприклад, модель якості МакКолла на найвищому рівні має три характеристики: функціональність, модифікованість і переносність, а 46 Розділ 1 на нижчих рівнях моделі – 11 підхарактеристик якості і 18 критеріїв (атрибутів) якості. Стандарт ISO 9126:2001 регламентує зовнішні і внутрішні характеристики якості. Перші відображають вимоги до функціонування програмного продукту. Для кількісного встановлення критеріїв якості, за якими буде здійснюватися перевірка і підтвердження відповідності ПЗ заданим вимогам, визначаються відповідні зовнішні вимірювані властивості (зовнішні атрибути) ПЗ, метрики (наприклад, час виконання окремих компонентів), діапазони зміни значень і моделі їх оцінки. Метрики використовуються на стадії тестування або функціонування і називаються зовнішніми метриками. Вони являють собою моделі оцінки атрибутів. Внутрішні характеристики якості і внутрішні атрибути ПЗ використовуються для складання плану досягнення необхідних зовнішніх характеристик якості продукту. Для квантифікації внутрішніх характеристик якості застосовують внутрішні метрики, як інструмент перевірки відповідності проміжних продуктів внутрішнім вимогам до якості, які формулюються на процесах, що передують тестуванню. Зовнішні і внутрішні характеристики якості відображають властивості самого ПЗ (працюючого або не працюючого), а також погляд замовника і розробника на таке ПЗ. Безпосереднього кінцевого користувача ПЗ цікавить експлуатаційна якість ПЗ – сукупний ефект від досягнення характеристик якості, що виміряється строком результату, а не властивістю самого ПЗ. Це поняття ширше, ніж будь-яка окрема характеристика (наприклад, зручність використання або надійність). Остаточна оцінка якості проводиться відповідно до стандарту ISO/IEC 14598. Якість може підвищуватися за рахунок постійного поліпшення використовуваного продукту виявленням, усуненням дефектів у ПЗ і їх запобіганням. Область знань «Якість ПЗ (Software Quality)» складається з наступних розділів: – концепції якості ПЗ (Software Quality Concepts); – визначення і планування якості (Definition & Planning for Quality); – техніки й види діяльності, що забезпечують гарантію якості, валідацію і верифікацію (Activities and Techniques for Software Quality Assurance, Validation & Verification –V&V); – вимірювання при аналізі якості ПЗ (Measurement in Software Quality Analysis). |