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

Рівень 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 підтримує багатопотокові і мультипроцесорні додатки, а також програми, виконувані на комп'ютерах із декількома процесорами.

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

Мета конфігураційного менеджменту - забезпечити управління версіями ПЗ. Це означає, що для кожної версії повинні окремо зберігатися вихідні тексти програм і здійсненні коди, комплекти документації, тестові дані і результати тестування, списки виявлених помилок і файли з виправленнями (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 сторінок тексту англійською мовою.