Існує п'ять рівнів зрілості

Рівень 1. Характеризується хаотичністю. Якість продуктів низьке, терміни завершення проектів порушуються. Ризик високий.

Рівень 2. Повторюваний і орієнтований на процеси. Успіх проектів обумовлений упровадженням систем керування проектами, планування і менеджменту. Особлива увага приділяється виробленню вихідних вимог, конфігураційному менеджменту й оцінці якості готових систем. Ризик середній.

Рівень 3. Визначений і орієнтований на процеси. Всі виробничі процеси визначені (тобто зафіксовані) і використовуються в масштабі всієї компанії, хоча "підкрутка" окремих процесів із метою успішного виконання проектів допускається. Процеси повністю контролюються і постійно удосконалюються. Стандарти ISO 9001 впроваджені в частині навчання персоналу і внутрішнього аудиту. Ризик невисокий.

Рівень 4. Керований і інтегрований. Основним засобом підвищення якості процесів стають аналіз і інструментальна система. Функції відслідковування змін і профілактики помилок вбудовуються в процеси. Активно використовуються CASE-засоби. Ризик досить невеликий.

Рівень 5. Повністю інтегрований. Широко застосовуються формалізовані методології. Для збереження історії розробки застосовується репозиторій. Ризик мінімальний.

Технології

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

Методологія

Програми набувають високої якості не стільки в результаті комплексного тестування кінцевого продукту, скільки в процесі його розробки. Якщо методологія створення ПО така, що помилки "виловлюються" на регулярній основі і на всіх стадіях виконання проекту, то на виході "програмного конвеєра" постає продукт, у котрому практично немає помилок. Корпорація IBM пропонує методологію створення складних програмних комплексів, що одержала назву Cleanroom Software Engineering. Вона орієнтована на професіоналів, що бажають удосконалити свої методи розробки ПО, і охоплює такі сторони програмістської практики, як реалізація моделі CMM, планування і керування проектами, власне розробку програм (виробітку специфікацій, проектування, кодування), профілактику помилок, тестування і супровід. Cleanroom - це сукупність адміністративно-технологічних процесів, що дозволяють колективам розроблювачів планувати, вимірювати, специфікувати, проектувати, кодувати, тестувати і сертифікувати програмні продукти. Методологія Cleanroom побудована на трьох концепціях: модульному принципі специфікування і проектування, математичному доказі слушності застосовуваних алгоритмів і використанні статистики за результатами тестування як основи для оцінки надійності програм (сертифікації).

Метод покрокової деталізації

З адміністративної точки зору методологія Cleanroom представляється у вигляді циклу покрокової деталізації проекту, коли кінцева функціональність системи досягається ітераційно. На кожному етапі реалізується визначений рівень функціональних можливостей, що тестується і сертифікується автономно. Такий спосіб розробки має декілька плюсів. З одного боку, розроблювачі (і замовник!) бачать, як система зростає і розвивається, а з іншого боку - виникають гарні передумови для поліпшення не тільки самого продукту, але і процесів його виробництва - адже на кожному етапі програмісти аналізують джерела виникнення помилок і намагаються їх усунути. На етапі формування архітектури майбутньої системи процедури тестування проводяться більш ретельно, що дозволяє локалізувати помилки на ранніх стадіях.

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

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

Виробітку специфікацій

Специфікації Cleanroom дають повний і точний опис функцій системи. Виробітку специфікацій сприяє більш глибокому розумінню вимог, запропонованих до кінцевого продукту, і його функцій, а самі специфікації є основою для тестування, сертифікації і подальшого розвитку системи. Відповідно до методології Cleanroom системи будуються по модульному принципі. При цьому розрізняють три категорії модулів: модуль типу "чорна шухляда" (black box), модуль-опис (state box) і "прозорий" модуль (clear box), що відбивають суть технології покрокової деталізації. "чорний шухляда" являє собою специфікацію всієї системи або її частини з погляду зовнішнього "користувача" (їм може бути звичайний користувач або об'єкт системи). "Користувач" впливає на "чорна шухляда", що певним чином відгукується (реагує) на ці впливи. Ціль уведення специфікацій "чорної шухляди" у тому і полягає, щоб описати коректне поводження системи у всіх ймовірних ситуаціях.

Проектування і верифікація

Процес проектування в методології Cleanroom зводиться до формального опису функцій, необхідних для реалізації поводження "чорної шухляди", тобто до створення модуля-опису. Даний процес нагадує проектування об'єктів в об'єктному програмуванні, коли дані і функції (методи) інкапсулюють в єдиній сутності. "Прозорий" модуль - це програмна реалізація функцій модуля-опису. При написанні програм повинні використовуватися тільки базові конструкції з технології структурного програмування (блоки, розгалуження, цикли). Процес програмування може приводити до народження нових "чорних шухляд", модулів-описів і т.д. Якість програмного коду (відповідність роботи програми закладеним специфікаціям) перевіряється в ході верифікації.

Тестування надійності

Інструментом автоматизованого тестування й оцінки надійності ПЗ в методології Cleanroom служить середовище Cleanroom Certification Assistant, в основі якої лежить ідея використання статистичних результатів тестування для підрахунку надійності ПО математичними методами. Спеціальний компонент Statistical Test Generation Facility (STGF) має власна мова опису тестових даних, що дозволяє запрограмувати сценарій тестування - характер розподілу даних, моменти виникнення критичних подій і т.д. У результаті STGF генерує код на мові C, що після компіляції і запуску подає на вхід тестує програми спробні дані. Другий компонент - Cleanroom Certification Model - фіксує результати тестування у вигляді показників MTTF (Mean Time To Failure - середній час наробітку на відмову), що і використовуються для обчислення метрик надійності.

Якось згенерована програма тестування може використовуватися повторно з метою порівняння надійності і продуктивності різних версій розроблювального ПО.

Інша відома програма виробництва IBM - Workstation Interactive Test Tool - у сполученні з STGF дозволяє створювати додатки, що самостійно тестуються.

Практичні результати

Практика використання методології Cleanroom у проектах, виконаних фахівцями IBM (табл. 2), виявила зниження числа помилок і дефектів у кінцевому коді в два - десять разів. Незалежність методології Cleanroom від конкретного типу апаратних і програмних платформ робить її придатної для розробки різного ПО - від розподілених додатків у середовищі клієнт/сервер до асемблерних програм. Багато відомих організацій, такі як AT&T, Chase Manhattan, Reuters, Merrill Linch, використовували Cleanroom у своїх проектах і також домоглися помітних успіхів у частині зменшення числа помилок, підвищення продуктивності праці і зниження вартості розробок.

Управління проектами

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

Система ProcessWeaver компанії Cap Gemini Innovation дозволяє автоматизувати процес розробки з використанням термінів взаємозалежних завдань і сукупності вхідних/вихідних даних, необхідних для реалізації конкретного завдання. Перед початком роботи керівник проекту дає опис технологічних процесів, що прийняті в даній компанії, визначає інформаційні потоки і стверджують списки розроблювачів (компонент Method and Activity). ProcessWeaver організує діяльність бригади розроблювачів у вигляді потоку завдань. Керівник проекту будує схему проекту у вигляді послідовності виконуваних завдань із указівкою виконавців і вхідних/вихідних даних для кожного завдання. Крім того, складається план-графік робіт.

За допомогою утиліти Agenda всі учасники проекту можуть переглянути перелік своїх завдань. Кожне завдання асоціюється з робочим контекстом - описом типу діяльності, необхідної вхідної інформації, одержуваними результатами і використовуваними інструментальними засобами (наприклад, у вигляді текстового редактора, CASE-засобів, компіляторів). Коли завдання завершене, його результати по ланцюжку передаються наступному виконавцю. За загальною схемою проекту завжди можна проаналізувати його поточний стан: які завдання уже виконані, а які - немає.

ProcessWeaver має інтерфейс до багатих інших пакетів керування проектами - St, Teamwork, Logiscope і Microsoft Project. Microsoft Project (MS-Project) - ще один засіб керування проектами, у якому акцент зроблений на проблемі керування ресурсами. Робоче поле MS-Project перебуває з трьох областей. У перший виводяться списки завдань і підзавдань із указівкою тимчасових рамок їхній виконання і задіяних виконавців. В другій області дані тимчасові діаграми процесів з оцінками критичних термінів. Нарешті, у третьому вікні зібрана інформація про поточне завантаження ресурсів. На відміну від ProcessWeaver продукт MS-Project оперує статичною інформацією. Щоб скорегувати тимчасовий графік, вихідні дані доводиться уводити вручну.

Однак пакети ProcessWeaver і MS-Project удало доповнюють один одного: перший сприймає файли MS-Project і на їхній основі здатний побудувати "кістяк" потоку завдань. У свою чергу, MS-Project може прочитати "живу" інформацію про стан завдань проекту і скорегувати свої діаграми автоматично, без ручного введення. Також корисним продуктом у руках менеджера проекту може стати програма AMItool, створена в European Laboratory for Particle Physics (CERN) і що дозволяє за допомогою метрики AMI (Application of Metrics in Industry) дати кількісну оцінку стану компанії, а також що пропонує план поліпшення технологічних процесів. Спочатку програма задає Оператору ряд питань (їхній список складений SEI), оцінює ступінь зрілості процесів по шкалі CMM і представляє результати оцінки у вигляді Kiviat-графа, гілки якого відповідають різним технологічним процесам (супровід, навчання, технічна підтримка і т.д.) і мають п'ять рівнів CMM. За результатами тестування складається список найбільше пріоритетних цілей, наприклад удосконалювання навчання персоналу або організація контролю помилок, що потім трансформується в дерево цілей і план дій. Важлива проблема, що доводиться вирішувати під час роботи над проектами, - це обмін інформацією. Особливої гостроти вона досягає, коли учасники проектів територіально роз'єднані. Очевидно, що саме просте її рішення лежить на поверхні і називається електронною поштою, однак, якщо в дискусії одночасно беруть участь більш двох людина, такий метод незручний. У подібній ситуації рекомендується використовувати систему WIT (World Wide Web Interactive Talk), що дозволяє організувати дискусію з множиною учасників по мережі Internet. Основним елементом системи WIT є "Дискусійне вікно" (Discussion Area), що відповідає предметної області, у рамках якої ведеться обговорення. Усередині дискусійного вікна має набір "Тим" (Topics), зв'язаних із визначеними аспектами даної дискусії. Учасники дискусії виражають свою точку зору у вигляді "Пропозицій" (Proposals), що передаються в WIT у формі повідомлень. Основна перевага WIT перед звичайним обміном повідомленнями через телеконференції полягає в тому, що інформація в цій системі добре структурована. У вікні Proposals відразу видно, які питання обговорюються, хто з ким згодний або не згодний. Крім того, є впевненість, що послане в WIT повідомлення не пропаде, а стане частиною інформаційної структури, що відноситься до теми дискусії. Аналогічні проблеми вирішує і комерційний пакет Lotus Notes у мережах на базі платформ Unix, PC і Macintosh. На всіх стадіях роботи над проектом народжуються численні документи (вихідні вимоги, системні специфікації, вихідні тексти програм, інструкції з експлуатації й ін.), створені різними фахівцями. У великих розподілених проектах, у яких задіяні великі колективи розроблювачів, а ПО і супровідна документація створюються в різних місцях, проблема ефективного використання інформаційних матеріалів тільки загострюється. Для її рішення була створена LIGHT (Life cycle Global HyperText - глобальна гіпертекстова система для підтримки життєвого циклу ПО), що, як і WIT, обпирається на технологію WWW.

Всі зареєстровані в системі документи (графічні матеріали, вихідні тексти програм, специфікації й ін.) відображаються на навігаційній карті (navigation map). Після вказівки мишею піктограми документа останній відчиняється і виводиться список інших документів, зв'язаних із вихідним перехресними посиланнями. На мал. 4 поданий принцип дії системи LIGHT. Вихідні документи спочатку проглядаються спеціальними програмами-сканерами, що формують LIGHT-словники всіляких гіпертекстових посилань між джерелами і приймачами. Після заповнення словників у справу вступає LIGHT-генератор, що перетворить вихідні документи в HTML-сторінки, добуваючи необхідну навігаційну інформацію зі словників і конфігураційного файлу. Доступ до Web-сторінок із Web-браузера здійснюється за допомогою запитів до диспетчерської програми LIGHT Solver, що на виході формує фізичний URL-покажчик.

Верифікація і тестування

Під верифікацією ПО розуміють перевірку готового продукту або його проміжних версій (як це прийнято, наприклад, у технології Cleanroom Software Engineering) на відповідність вихідним вимогам. При цьому мається на увазі не тільки тестування самої програми, але й аудит проекту, користувацької і технічної документації і т.д. На ринку існує множина продуктів, що дозволяють автоматизувати процес верифікації. Серед них Purify, TestCenter, Logiscope і ін. Пакет Logiscope компанії Verilog - це сімейство інструментальних програм (TestChecker, CodeChecker, RuleChecker, ImpactChecker і Viewer), об'єднаних загальною ціллю: допомогти користувачам поліпшити якість і провести всебічне тестування створюваного ПО. У основі продукту лежить ідея аналізу вихідного коду. Його остання версія здатна обробляти тексти програм, написані більш ніж на 80 мовах, включаючи C, C++, Pascal, Cobol, Fortran, PL1, ADA і навіть мови асемблера Intel і Motorola. Результати аналізу представляються у вигляді числових показників (метрик, що існує більш 50 типів), що дозволяють судити про якість вихідного коду програм. Компонент TestChecker спостерігає за поводженням тестує програми в ході її виконання й у процесі своєї роботи будує дерева викликів, профілі виконання, відзначає функції і процедури, що не використовуються. Logiscope підтримує функцію зворотного проектування, c допомогою якої можна відновити структуру програми по об'єктному коді, що корисно для розуміння логіки її роботи і характеру використовуваних даних. Спеціально для професійних програмістів на мовах C і С++ призначена програма TestCenter компанії CenterLine. З статистичних даних випливає, що при звичайному тестуванні перевіряється "виконуваність" тільки 40 - 50% загального коду програм. Пояснюється це тим, що при традиційному, "ручному", тестуванні неможливо перевірити роботу програми з усіма можливими комбінаціями вихідних даних або промоделювати помилки типу, що зустрічаються рідко, недостачі пам'яті (out of memory). При таких процедурах тестування важко говорити про високу якість готових програм. Пакет TestCenter дозволяє організувати глобальне тестування ПО на промисловому рівні, а саме тестування зробити природною частиною процесу розробки за рахунок його безпосередньої інтеграції з іншими відомими інструментальними оболонками (SPARCworks, SoftBench, ObjectCenter і ObjectCode).

У процесі налагодження/тестування програм TestCenter показує рядки вихідного коду, не виконувані під час проведення тест, неініціалізовані ділянки пам'яті, пам'ять, що резервувалася, але не використовувалася, використовувалася, але не звільнялася, випадки зрадливого застосування Операторів malloc/free і ін. Імітатор помилок (Error Simulator) може генерувати помилки, що рідко зустрічаються і важко налагоджуються, типу disk full (немає місця на диску) або згаданої out of memory, а імітатор API (Simulator API) - інтерфейсні помилки, наприклад неправильний порядок аргументів при виклику функцій або некоректний код повернення. При використанні TestCenter не виникає необхідність перекомпіляції програм, а для роботи Error Simulator не знадобиться навіть вихідного коду тестує програми. Компанія Pure Software, що веде виробник автоматизованих інструментальних засобів створення якісного ПЗ (ASQ, Automated Software Quality), пропонує розроблювачам Windows-додатків на мові C++ систему Purify, що дозволяє виявляти різноманітні помилки програм, включаючи помилки виконання (run-time errors) і "відпливи" пам'яті. Особливістю пакета є використання спеціально розробленої і запатентованої технології OCI (Object Code Insertion), відповідно до котрого Purify вставляє в об'єктний код тестує програми допоміжні об'єкти (перед і після Операторів "load" і "store"), що дозволяє детально контролювати доступ до пам'яті і виявляти такі помилки, як використання неініціалізованих змінних, некоректні операції malloc/free, виходи за межі масивів, неправильна робота з покажчиками, стекові помилки. При виявленні помилки Purify завантажує програму налагодження, щоб програміст по гарячих слідах міг її відшукати. До речі, Purify підтримують практично усі відомі текстові редактори й програми налагодження.

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

Робота над помилками може вестися або в інтерактивному, або в пакетному режимі, коли вся діагностика зберігається у вигляді звітів. При цьому Purify інформує Оператора про можливі наслідки виявленої помилки: проявляться вони негайно або надалі. Програма повністю підтримує технологію OLE на рівні клієнтів і серверів, що дозволяє розробляти й налагоджувати складної багатокомпонентної системи. Нарешті, Purify підтримує багатопотокові і мультипроцесорні додатки, а також програми, виконувані на комп'ютерах із декількома процесорами.

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