Три джерела і три складові частини процесу створення якісного ПЗ

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

Очевидно, що якість одержуваного ПЗ залежить від кваліфікації розроблювачів, склад яких неоднорідний у силу яскраво вираженої спеціалізації. У кожному великому проекті є аналітики, що ставлять задачі, системні програмісти, що підготовляють інструментарій для програмістів прикладних, група тестування ПЗ, технічні письменники і фахівці з установки і супроводу готових систем. Професійні виробники програмних продуктів давно вже змогли переконатися, що самий вірний спосіб поліпшити програми - це удосконалити процеси їхній створення. За останні десять років розроблене (і реалізоване) множина концепцій удосконалювання зазначених процесів. Всі вони, хоча і носили різні назви, переслідували загальну ціль. Наприклад, американський Software Engineering Institute (SEI) запропонував концепцію "Поліпшення процесів створення ПЗ" (Software Process Improvement, SPI), що обпиралася на статистичні методи контролю технологічних процесів, розроблені в Японії наприкінці 30-х рр. Пізніше з'явилися й інші концепції: "Наскрізний контроль якості" (Total Quality Management, TQM), "Реінженірінг ділових процесів" (Business Process Reengineering, BPR), що припускає модернізацію базових бізнес-процесів організації, "Поступове удосконалювання ділових процесів" (Business Process Improvement, BPI).

У основі всіх цих концепцій лежить загальне розуміння життєвого циклу ПЗ як сукупності фаз, що проходить програмний продукт у процесі свого розвитку.Це:

• розробка вихідних вимог до ПЗ з боку користувача;
• формулювання загальних вимог до ПЗ з боку розроблювача (системні вимоги);
• проектування архітектури;
• детальна реалізація ПЗ;
• інсталяція ПЗ в організації замовника;
• експлуатація.

Фази можуть перекриватися за часом, а деякі процеси вестися паралельно. Умовно говорячи, третя версія програми може знаходитися на етапі проектування, тоді як друга - на стадії інсталяції. Для підтримки життєвого циклу ПЗ фірми-розроблювачі організують свою діяльність у кількох ключових напрямках:

• управління проектом (планування, розподіл ресурсів, контроль виконання і термінів);
• тестування (перевірка відповідності якості готового продукту вихідним вимогам і перевірка функціонування);
• конфігураційний менеджмент (підтримка версій, редакцій, варіантів ПО на рівні вихідного коду, дистрибутивів, документації);
• супровід (установка продукту, навчання користувачів, усунення помилок, розвиток функціональних можливостей, постачання upgrade-версій, технічна підтримка).

Виникає питання: у якому ступені "кухня" виробника, що начебто б залишається його особистою справою, може торкати інтересів потенційних покупців?

Досягнення зрілості

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

Для визначення загального рівня розвитку технологічних процесів у програмних організаціях SEI і Університет Карнегі - Меллона розробили спеціальну систему оцінки зрілості технологічних процесів в організаціях, що спеціалізуються на випуску ПЗ (див. урізання "Модель оцінки зрілості..."). Запропонована ними модель Capability Maturity Model (CMM) заснована на так називаних рівнях зрілості (maturity levels). Усього їх п'ять, і кожен із них характеризує деякий ступінь якості виробів, що випускаються. Таким чином, чим вище рівень зрілості компанії, тим вище її статус і авторитет у комп'ютерних колах і в очах користувачів.

Рівень 1. Початковий (initial).

Звичайно з цього рівня починає свою діяльність більшість організацій. На даному етапі процес розробки носить неструктурований і випадковий характер. Комерційний успіх, якщо і супроводжує проекту, визначається скоріше видатними спроможностями якого-небудь талановитого розроблювача або менеджера, ніж організаційною інфраструктурою компанії. У організації відсутнє стабільне середовище розробки і супроводи. Термінів випуску продуктів, як правило, не дотримуються. У кризовій ситуації фірма "забуває" про попередньо складені плани і всі сили кидає на кодування і тестування програми. За оцінками SEI, у даний час біля 75% софтверних фірм перебувають на початковому рівні.

Рівень 2. Повторюваний (repeatable).

Успішна реалізація проектів стає можливої завдяки жорсткому керуванню, плануванню і контролю. Акцент у даному випадку робиться на виробітку вихідних вимог, методи оцінки і конфігураційний менеджмент. Розробка нових проектів ведеться на основі раніше накопиченого досвіду і відповідно до визначених стандартів на розробку ПО. Даний рівень може забезпечити біля 15% організацій. Як показує практика, перехід із першого рівня на другий найбільше складний, оскільки вимагає комплексного впровадження основних технологічних процедур.

Рівень 3. Фіксований (defined).

Процеси, що відносяться до сфери керування й інженерної діяльності, повністю документовані, стандартизовані й інтегровані в єдиний технологічний потік, контрольований керівним персоналом. Цей рівень у стані підтримувати 8% софтверних компаній.

Рівень 4. Керований (managed).

Організації намагаються оцінити якість процесів і готового продукту кількісно. Для контролю над процесами використовуються кількісні показники (метрики). Всі процеси передбачені й укладаються в заздалегідь визначені рамки. Даного рівня досягло біля 1,5% організацій.

Рівень 5. що оптимізується (optimizable).

Компанії прагнуть поліпшити свою роботу, керуючись кількісними критеріями якості. Мають засоби локалізації вузьких місць у виробничих процесах. Основна ціль - випуск бездефектних продуктів, у яких усі помилки усунуті ще на стадії внутрішнього тестування.

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

Тільки 0,5% компаній можуть підтримувати настільки високий рівень технологічної зрілості.

Щоб допомогти потенційним прихильникам методології CMM розібратися в тонкощах моделі, фірма Process Focus Software пропонує програму CMM Live, що представляє собою своєрідний електронний довідник, самовчитель і експерт-радник по технологіях CMM. З його допомогою користувачі зможуть легко розібратися в термінології CMM, оцінити власний рівень по шкалі CMM і зрозуміти, що треба робити для підвищення свого статусу.

Аналогічні цілі переслідує і пакет SoftGuide від Software Productivity Centre, орієнтований на розроблювачів ПО, що прагнуть поліпшити якість своїх процесів. SoftGuide задає множина питань і по отриманих відповідях судить про стан справ у тестує організації. Після ідентифікації існуючих проблем для їхнього рішення пропонуються конкретні міри. Процедура виконує в чотирьох етапу: діагностика проблем, розставляння пріоритетів у їхньому рішенні, упорядкування підготовчого плану і виробітку плану конкретних дій. Інші моделі якості CMM і стандарти ISO сприяли появі аналогічних моделей і стандартів якості в деяких розвитих країнах. На думку їхніх авторів, запропоновані варіанти в більшій мірі відповідають внутрішнім вимогам конкретних країн.

В даний час Німецький національний дослідницький центр по інформаційних технологіях (GMD) завершує роботу над проектом SCOPE*PROCEPT, що охоплює інформаційні моделі процесів створення ПО, включаючи методи оцінки якості на основі метрик. Вже зараз модель SCOPE*PROCEPT випробувана в 20 великих промислових проектах і внесена на обговорення в ISO.

До складу SCOPE*PROCEPT входить декілька компонентів, що відповідають різним сторонам діяльності по створенню програм:

- специфікування процесів програмування і тестування (ProcePT). Даний компонент призначений для виробітки специфікацій і тестування використовуваних у проектах технологічних процесів. Розробка процесів ведеться по спадній схемі (мал. 3), починаючи з рівня загальної моделі процесу. Далі шляхом ітераційних уточнень автоматично створюється комплект необхідних документів: різноманітні довідники по проекті, описи типів діяльності, переліки продуктів, що будуть випущені в ході роботи над проектом, що відповідають діаграми і схеми;

- інжиніринг моделей якості (Model Y7). Суть його у визначенні моделі якості для даного проекту з використанням методів оцінки якості; припускає вбудовування цієї моделі в існуючі технологічні і бізнес-процеси;

- вимір характеристик (метрик) ПО (SMV). Можна представити у вигляді своєрідного іспитового стенда, на якому проводяться кількісні дослідження характеристик програм; - інтегроване середовище для виміру характеристик компіляторів (CISM);

- моделювання процесів виробництва ПО (SPM). Даний компонент призначений для оцінки якості процесів розробки, причому на основі кількісних показників.

Модель Trillium, створена в 1994 р. фірмами Bell Canada, Nothern Telecom і Bell-Nothern Research, пропонує ще один спосіб оцінки процесів випуску продуктів у телекомунікаційній і інформаційній областях і охоплює всі аспекти життєвого циклу ПО. Хоча в її основі і лежить уже розглянута Capability Maturity Model, ці моделі істотно відрізняються друг від друга. Крім CMM, Trillium обпирається на ряд інших регламентуючих документів і стандартів: ISO 9001 і ISO 9000-3, стандарти Bellcore TR-NWT, значну частину стандартів Malcolm Baldrige National Quality Award, стандарти IEEE і IEC.

Моделлю Trillium охоплені наступні види діяльності:

Поиск по сайту: