Тема 2. Лекція 3. Система менеджменту якості програмної продукції. Основі рекомендації щодо вибору моделі системи якості.

Тема 2. Лекція 3. Система менеджменту якості програмної продукції. Основі рекомендації щодо вибору моделі системи якості.

Основні поняття якості програмної продукції

З точки зору споживачів цінність продуктів людської праці багато в чому визначається їхніми експлуатаційними властивостями. Кожен об’єкт відрізняється від іншого кількісно й якісно. Якісна визначеність об’єкта — це безпосередньо внутрішня його визначеність, що характеризує притаманні тільки йому властивості. На різних етапах ЖЦ ПВ (життєвого циклу програмні вироби) мають прояв різні властивості ПВ, сукупність яких формує поняття якості (рис. 1).

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

Властивості програмного продукту, що виявляються при його створенні (етап розробки у ЖЦ ПВ), для користувача проявляються у повноті реалізованих функцій та вартості продукції, що обумовлює коло потенційних споживачів. Властивості програмного продукту, що виявляються при його використанні (етап експлуатації у ЖЦ ПВ), — це властивості, що забезпечують ефективне використання систем обробки даних у конкретних сферах застосування ЕОМ і визначають рівень конкурентоспроможності ПВ.

Рис. 1. Загальна схема формування якості

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

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

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

Метою оцінки якості ПВ може бути:

1.прийняття рішення про ступінь відповідності рівня якості ПВ, досягнутого при розробці, потрібному (заданому) рівню;

2.опис ознак і властивостей виготовлених і поставлених ПВ (наприклад, в документації на ПВ, каталогах);

3.оцінка конкурентоспроможності ПВ;

4.атестація і сертифікація ПВ.

Технології оцінки якості програмних продуктів

Кількісна оцінка якості ПЗ

Порівнювати якість програмних продуктів "на пальцях" не занадто зручно, тому доцільність застосування кількісних методів оцінки якості (метрик) очевидна. Дітер Ромбах (Dieter Rombach), співробітник американської організації Software Engineering Laboratory (SEL), у 1991 р. на паризькій конференції з питань комп'ютерних обчислень Euromantics заявив: "Ми більше не повинні задаватися питанням, потрібні чи комп'ютерні метрики. Проблема полягає в тому, як їх будувати". Історія програмних метрик нараховує чверть століття, а почалася вона з того моменту, коли вартість комерційних продуктів стала зростати і знадобилися наукові методи створення стандартів і аналізу процесів розробки ПО. Програмування з мистецтва поступово перетворювалося в інженерну дисципліну.

Введення суворих кількісних метрик у програмування повинно було сприяти вирішенню ряду практичних задач:

· прогнозувати ймовірне число помилок у системі від початку проектування;

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

· на основі аналізу вихідного коду програм прогнозувати рівень складності процесів тестування і відсоток помилок, що залишаються;

· за оцінками складності фази проектування системи визначати кінцевий розмір коду;

· визначати кореляцію окремих характеристик програмного коду з якістю готової системи;

· контролювати стадії розвитку проекту;

· аналізувати явні і приховані дефекти;

· на основі експериментального порівняння виявляти кращі методи і технології.

Із зростанням актуальності програмних метрик стали з'являтися різні "вимірювальні" програми. Одні з них досліджували характеристики проектів і ПЗ комплексно, інші орієнтувалися на цілком конкретні цілі: аналіз вихідного коду, розмірів і структури окремих модулів і т.д.

Наприклад, відома програма Metricate виробництва Software Productivity Centre зондує практично всі аспекти діяльності софтверних компаній: ефективність технологічних процесів, якість програмного коду, рівень управління проектами, вартість виконання різних етапів, продуктивність одержуваної системи, продуктивність праці розроблювачів і якість готових виробів. Незважаючи на численні дослідження програмних метрик (біля 5 тис. статей), у цій області як і раніше залишається багато невирішених питань. По-перше, технологія виміру якості ще не досягла зрілості. По-друге, відсутні єдині стандарти на метрики. Найпопулярніший стандарт, що відноситься до виробництва надійного ПЗ (Standard Dictionary of Measures to Product Reliable Software інституту IEEE), так і не став загальноприйнятим. У результаті кожен постачальник "вимірювальної" системи пропонує свої власні способи оцінки якості і відповідно метрики. На сьогоднішній день відомо більш тисячі видів метрик. Проте теорія і практика програмних метрик продовжують розвиватися і є надія, що консенсус у цій області усе ж буде досягнутий.

Конфігураційний менеджмент

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

Мабуть, найвідомішим виробником інструментарію в області конфігураційного менеджменту є компанія Intersolv, що випускає сімейство добре інтегрованих між собою продуктів (PVCS Version Manager, PVCS Tracker, PVCS Notify, PVCS Configuration Builder, PVCS Reporter, PVCS Production Gateway, PVCS Developer's Toolkit, PVCS Version Manager Interface for Visual Basic). "Глава" сімейства - PVCS Version Manager - має наступний необхідний набір характеристик, що дозволяють автоматизувати керування складними проектами, у яких задіяне велике число розроблювачів: - розвитим графічним інтерфейсом (підтримка функції буксирування при додаванні файлових у проект, тригерів, що запускають спеціальні функції при настанні визначених подій, і ін.); - зручними засобами роботи з архівними файлами проектів; - підтримкою довгих імен файлів, прийнятих у Unix, HPFS і NTFS; - розширеними функціями захисту (надання прав доступу до ресурсів проекту для індивідуальних користувачів або груп). Іншим потужним засобом контролю версій вихідних текстів програм є пакет Microsoft Visual SourceSafe. Подібно більшості продуктів цього класу SourceSafe підтримує функції збереження й організації вихідного коду, забезпечує взаємодія між розроблювачами, відслідковує розходження між версіями файлів. У той же час, на відміну від програм-аналогів, SourceSafe виконує свої функції з погляду управління проектом, звільняючи розроблювачів від необхідності відслідковувати зв'язку між файлами. До числа найбільше корисних властивостей цього пакета можна віднести: - підтримку різних типів файлів (текст, графіка, аудіо, відео, двійкові й ін.); - можливість використання файлів у що розділяється режимі на кількох платформах (Windows 95, Windows 3.1, Windows NT Workstation і Unix); - засоби спільної роботи з файлами; - можливість повторного використання коду в кількох проектах; - ієрархічну організацію файлів проекту; - відслідковування змін для кожної версії файлу (при цьому фізично зберігається тільки остання версія); - управління правами доступу користувачів до файлів проекту; - убудований генератор звітів; - можливість відкоту версій.

Компанія Hewlett-Packard розробила власну програму конфігураційного менеджменту SoftBench CM, орієнтовану на робітники групи, у тому числі що мають територіально віддалених співробітників. Система реалізована в архітектурі клієнт/сервер і забезпечує доступ до віддалених і локальних серверів. Крім того, SoftBench допускає спільне використання тих самих файлів із різних ЛС. До основних функцій продукту відносяться підтримка текстових і двійкових файлів, розширена система нумерації версій, вхідної/вихідний контроль, стиск даних, моніторинг історії редагування файлів, паралельна робота з файлами, внутрішній аудит. Пакет SoftBench CM сумісний з іншими інструментальними засобами, що випускаються Hewlett-Packard, - SoftEdit, SoftBuild, SoftStatic і Development Manager.

Особливе місце в конфігураційному менеджменті займає процес переходу з однієї версії ПО на іншу. Якщо розміри програмних продуктів досягають кількох десятків мегабайт, то постачання клієнтам upgrade-версій перетворюється в проблему, що, утім, досить просто вирішити за допомогою пакета.RTPatch Professional компанії PocketSoft. Алгоритм його роботи простий: після порівняння двох файлів виявлені розбіжності фіксуються у відносно невеликому файлі виправлень (patch). Далі, використовуючи цей файл і спеціальну утиліту, можна зі старого файлу одержати новий. Саме в такий спосіб і відбувається установка upgrade-версій у клієнта, котрому досить вислати не цілком нову версію системи, а тільки patch-файл. У табл. 3 приведені реальні дані про співвідношення розмірів готових систем і відповідних файлів виправлень.

Технологія, запропонована PocketSoft, багатьом сподобалась: її прихильниками стали більш чотирьох тисяч компаній, у тому числі Microsoft, Borland, IBM, Novell, Symantec, Autodesk, Software AG й ін. Ми розглянули основні, хоча і далеко не усі, технологічні процеси і підтримуючі їхні інструментальні засоби. Що стосується що залишилися процесів, то питання з їхньою автоматизацією також успішно вирішений. На ринку програмних засобів сьогодні має широкий спектр програм, призначених для автоматизації усіляких видів діяльності, будь те високорівневе проектування бізнес-процесів або автоматизоване створення користувацької документації. Як говориться, було б бажання автоматизувати. Отже, якість програмного забезпечення, технологічна зрілість компанії і стандарти повинні бути поставлені розроблювачем у главу кута. Але чи коштує гра свіч і потрібно чи взагалі прагнути до чергового щабля досконалості? За даними SEI, практичні результати свідчать про реальний економічний ефект від проведення заходів щодо удосконалення процесів розробки програмного забезпечення. Наприклад, витрати в розмірі 1500 євро на рік на одного інженера-програміста обертаються збільшенням продуктивності його праці на 10 - 70%. На думку всіх учасників конкурсу Baldrige Award, будь-які інвестиції в якість обертаються багаторазовою вигодою як для окремих компаній, так і для комп'ютерної індустрії в цілому. Стандарти ISO Як усі починалося У 1947 р. у Лондоні представники 25 країн вирішили створити міжнародну організацію, основною задачею якої стала б координація розробок і уніфікація міжнародних стандартів. Нова організація одержала назву International Organization for Standardization (ISO). В даний час її членами є біля 100 країн. Впадає в око невідповідність повного найменування організації і використовуваної абревіатури. "ISO" - це грецький префікс, що означає "рівний". У нашому контексті "ISO" можна перевести як "стандарти, рівні для всіх". Головною причиною народження стандартів ISO з'явилося бажання ініціаторів створення цієї організації усунути технічні бар'єри в торгівлі, що виникнули внаслідок того, що в різних країнах для тих самих технологій і товарів діяли різнорідні стандарти. Сьогодні стандартами "перекриті" багато технологічних галузей - від програмування і телекомунікацій до банківської і фінансової сфери. На думку експертів, у найближчі роки стандарти ISO як і раніше будуть поширюватися ударними темпами, що обумовлено цілим поруч чинників: - бурхливим прогресом в області інтеграції світової торгівлі і промисловості, взаємопроникненням ринків. З технологічної точки зору вільна конкуренція немислима без чітко сформульованих, зрозумілих і загальноприйнятих стандартів. З'явився розхожий штамп: "Стандарти - мова торгівлі". У сучасних умовах жодний ринок не може обійтися без компонентів, вироблених на інших ринках, а цифрове опрацювання даних потрібно повсюдно; - глобальним поширенням комп'ютерних комунікаційних засобів. Обчислювальна індустрія - яскравий приклад технології, існування котрої абсолютно немислимо без загальноприйнятих стандартів. Повна сумісність відкритих систем сприяє розвитку здорової конкуренції серед виробників; - потребою в наявності загальних стандартів у процесі становлення новітніх технологій. На ранніх етапах їхнього розвитку виникає необхідність у стандартизації термінології і способах уявлення і збереження кількісної інформації. Хто входить до складу організації і розробляє стандарти За статутом членом ISO може стати "сама авторитетна в країні організація, що займається виробленням стандартів". Таким чином, інтереси якийсь країни в ISO може представляти тільки одна організація. Крім основних членів, у ISO входять так називані члени-кореспонденти (як правило, ними стають відносно великі "стандартообразующие" організації окремих країн, однак ще недостатньо потужні, щоб поширити свій вплив на стандартизацію технологій по всій країні). Член-кореспонденти не беруть активної участі у розробці міжнародних стандартів, але мають повний доступ до інформації, що їх цікавить. Нарешті, є ще і члени-передплатники - вони подані організаціями країн, що розвиваються. Виконання технічної роботи в ISO покладено на 2700 технічних комітетів, підкомітетів і робочих груп, до складу яких входять представники урядових, промислових і науково-дослідних кіл (на сьогоднішній день - біля 500 організацій). Кожна організація - член ISO - має право включити свого представника в будь-який комітет, якщо вона особо зацікавлена в діяльності останнього.

Роботу комітетів курують найбільші організації - члени ISO: AFNOR, ANSI, BSI, CSBTS, DIN, SIS і ін. Прийняття стандарту можливо тільки після досягнення консенсусу між кваліфікованою більшістю членів комітету.

Центральний секретаріат ISO, штаб-квартира якого знаходиться в Женеві, публікує вихідні версії стандартів, підготовлені комітетами, і розсилає їхнім членам ISO для ознайомлення і голосування. Що регулярно видається бюлетень "ISO Momento" містить докладну інформацію про структуру і діяльність усіх технічних комітетів.

Коло інтересів ISO

Сфера діяльності ISO не обмежується якийсь конкретною технологічною областю. Організацію цікавить усі і вся, за винятком електротехніки й електроніки (ці напрямки контролює International Electrotechnical Commission - IEC). Роботи в області інформаційних технологій ведуться ISO і IEC (Робочий комітет JTC 1) спільно.

Як розробляються стандарти

Нові стандарти народжуються відповідно до трьома принципів. По-перше, вони є результатом консенсусу всіх зацікавлених сторін - виробників, постачальників, споживачів, професійних розроблювачів, урядових і дослідницьких організацій. По-друге, стандарти мають дійсно світове поширення і задовольняють як виробників, так і споживачів. По-третє, поява нових стандартів диктується винятково вимогами вільного ринку, а не чиєюсь злою або доброю волею. Якщо ринок дозрів для нового стандарту, то такий стандарт з'являється. Процес створення нового стандарту включає три етапи. Звичайно ініціатива його розробки виходить від виробників, що доводять базові пропозиції стандарту до свого представника в ISO. Якщо ця організація визнає доцільність появи нового стандарту, то відповідна робоча група визначає технічну область, на якій передбачуваний стандарт буде поширюватися. На другому етапі йде виробітку технічних специфікацій, у ході якої представники різних країн прагнуть до досягнення консенсусу. На заключному етапі перша версія стандарту затверджується (за стандарт повинно проголосувати 75% кворуму) і публікується. З цього моменту стандарт стає офіційним (ISO International Standard). В міру удосконалювання технологій, появи нових матеріалів, методів опрацювання, підвищення вимог до якості і надійності виробів виникає необхідність у перегляді стандартів. У ISO існує правило: усі стандарти повинні переглядатися не рідше одного разу в п'ять років. Сьогодні ISO належить 9300 різних стандартів, опис яких займає 170700 сторінок тексту англійською мовою.

Коротка версія лекції

Впровадження СМЯ в Європі

 

Важливість впровадження високоефективної СМЯ вже давно усвідомлена в усьому світі. Кількість СМЯ-компаній, що відповідають міжнародним стандартам, уже зараз досягає кількох десятків тисяч. Головну роль у цьому русі відіграють країни Європейського економічного співтовариства. Насиченість Європейського ринку призвела до структуризації компаній за рівнем і стабільністю якості. Цивілізованість ринкових відносин у Західній Європі визначається наявністю найкращих договірних правил визначення рівня і стабільності якості. Міжнародні стандарти якості втілили у собі весь накопичений міжнародним співтовариством досвід у галузі управління якістю. Крім того, існує і чисто економічний інтерес у створенні СМЯ. У більшості випадків значні єдиноразові витрати на створення і сертифікацію СМЯ вигідніші, ніж менше, але багаторазово, сплачувати за сертифікацію нових продуктів чи версій. Зараз із впевненістю можна сказати, що ті компанії, яким не вдається створити сучасні високоефективні СМЯ, не зможуть досягти першості в конкурентній боротьбі, а відсутність останніх і надалі зовсім може привести до їхнього економічного краху.

Отриманий міжнародним співтовариством досвід у галузі якості дозволив визначити вимоги і рекомендації до структури й організації СМЯ-компанії. Своє конкрентне відображення вони знайшли у вигляді основних міжнародних стандартів серії ІSO 9000, що діють із 1987 р., перевидані в 2000 р. і з 2001 р. введені як державні стандарти України ДСТУ ISO 9000, ДСТУ ISO 9001, ДСТУ ISO 9004, а також у вигляді державних стандартів ДСТУ ISO серії 10000, спрямованих на підтримуючі технології забезпечення й оцінки СМЯ. Альтернативи цим стандартам немає. У питаннях визнання їх доцільності існує повна згода в тому, що СМЯ забезпечують:

· своєчасне запобігання й усунення невідповідностей у процесі розробки, впровадження та супроводження програмних засобів;

· довіру між замовником і клієнтом;

· підвищення ефективності виробництва;

· конкурентоспроможність програмної продукції;

· зростання професіоналізму і зацікавленості співробітників компаній-виробників програмної продукції.

 

Чи можна очікувати конкурентноспроможний багатофункціональний програмний засіб, наділений необхідними споживчими властивостями, якщо на самому початку його розробки не встановлені:

· повні, однозначні та верифіковані вимоги до програмного засобу, що відображають його споживчі властивості;

· план забезпечення якості програмного засобу, включаючи методи та критерії контролю якості продуктів на всіх етапах розробки;

· тимчасові та інші ресурси для підготовки та проведення випробувань остаточного продукту та його компонентів.

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

 

Документована система WIDIS

 

Матеріали WIDIS - це нормативні документи, що визначають вимоги до розробки документів двох верхніх рівнів СМЯ і широко використовуються в Німеччині для розробки документованих СМЯ компанії, що займаються розробкою програмних засобів і послуг у галузі інформатики і системотехніки, із наступною сертифікацією в організації СЕТЕСОМ. Ці документи також пройшли апробацію в Україні при створенні документованих систем якості окремих компаній, що займаються розробкою, постачанням і супроводом програмних засобів. СМЯ, що розробляються за нормативними документами WIDIS, забезпечують:

· системність управління, спроможність охопити всі підрозділи компанії й організацію їхньої ефективної взаємодії з питань якості;

· комплексність, тобто забезпечення якості у всіх галузях діяльності, що визначають якість, на всіх етапах життєвого циклу програмної продукції;

· спрямованість коригувальних впливів на причини дефектів і їхнє усунення;

· роботу на споживача, прагнення до завоювання довіри споживачів, що використовують або хочуть використовувати програмні продукти компанії;

· створення в компанії духу новаторства, тобто умов, що стимулюють пошук і практичне використання для досягнення цілей компанії, нових технологій у всіх сферах діяльності;

· спільність цілей і зусиль усіх працівників компанії на основі балансу їхніх особистих інтересів, загальну участь у забезпеченні якості;

· керованість, тобто ефективність діяльності вищого керівництва компанії.

Інформація в СМЯ WIDIS наступного змісту:

· описи того, яка СМЯ повинна бути, що викладається в нормативних документах компанії (перші два рівні документів СМЯ) і відповідним вимогам міжнародному стандарту ISO серії 9001:2000;

· даних про те, що відбувається, і коригувальних вказівок.

Система документів СМЯ WIDIS має трьохрівневу структуру.

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

На другому рівні - рівні процесу (відділу, проекту) - інструкції, настанови, стандарти, що регламентують сукупність процедур із забезпечення якості з вказівкою, яким шляхом, яким персоналом і за допомогою яких засобів досягаються необхідні характеристики якості. Кількість процедур змінюється від 15 до 73 у залежності від складності виробництва програмної продукції і розвиненості СМЯ. Як правило, одним документом охоплюється одна функція для одного або декількох підрозділів. На цьому рівні виявляються комерційні таємниці компанії в галузі організації управління якістю.

Нижній рівень - рівень робочих інструкцій, де деталізуються фрагменти процедур і розкриваються деталі технологічних процесів. Як правило, один документ - на один вид діяльності.

 

Пропозиції УкрНЦ РІТ

Пропонується наступний оптимальний план створення, впровадження, підготовки до сертифікації та сертифікації СМЯ:

· прийняття керівництвом компанії зобов’язань щодо створення та впровадження СМЯ і упорядкування плану робіт;

· попередня аудиторська перевірка наявної СМЯ (за необхідності);

· визначення складу СМЯ та її документації;

· підготовка виконавців і документування змін;

· розробка процедур і документації;

· попередня експертиза проектів документів;

· вибір органу із сертифікації СМЯ;

· впровадження СМЯ і документування;

· сертифікація СМЯ.

УкрНЦ РІТ забезпечує консультації та супровід СМЯ та її документації та усунення недоліків, виявлених на всіх етапах розробки, впровадження, попередніх аудиторських перевірках СМЯ та під час їх сертифікації.

 

Тема 2. Лекція 3. Система менеджменту якості програмної продукції. Основі рекомендації щодо вибору моделі системи якості.