Категории

Cуществуют следующие способы оплаты за занятия:

  • Абонемент на 8 посещений (срок действия 1 месяц) - 300 грн.;
  • Абонемент на 4 посещения (срок действия 1 месяц) - 200 грн.;
  • Абонемент на 12 посещений(срок действия 1 месяц) - 400 грн.;
  • Разовое посещение - 60 грн.
(ДЛИТЕЛЬНОСТЬ ЗАНЯТИЙ ПО 1,5 ЧАСА)

Тестування ПЗ як один з елементів системи якості

  1. Проблема якості програмного забезпечення стає сьогодні все більш гострою, особливо в міру розширення...
  2. Мета і орієнтири
  3. Сходи, що ведуть до якості
  4. Фундамент якості і його складові
  5. Профілактика вигідніше лікування
  6. література
  7. система ПИР
Мета і орієнтири Сходи, що ведуть до якості Фундамент якості і його складові Профілактика вигідніше лікування система ПИР література

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

Наше деловое партнерство www.banwar.org

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

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

Мета і орієнтири

Найбільш прийнятним орієнтиром для корпорації є досвід компанії IBM - одного з провідних розробників програм для оборонних проектів США. Відомо, наприклад, що в три мільйони рядків коду бортового ПО "шатлів" міститься менше однієї помилки на десять тисяч рядків [1]. Ми активно впроваджуємо в свою практику організаційний і технологічний досвід IBM [2].

Іншим орієнтиром стали загальновизнані стандарти якості ISO 9000. Згідно з формулюванням ISO 8402, під якістю розуміється сукупність характеристик програмного продукту, що відносяться до його здатності задовольнити встановлені і передбачувані потреби клієнтів. Основними параметрами якості вважаються: функціональна повнота, відповідність вимогам законодавства країн СНД, безпеку інформації, простота експлуатації, не вимагає спеціальних знань в області інформаційних технологій, ергономічність користувальницького інтерфейсу, мінімізація витрат на експлуатацію, розвиток та модернізацію.

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

Якість і надійність в комплексі забезпечують високі споживчі властивості ПО. В процесі створення програмного продукту вони одночасно і безперервно контролюються і удосконалюються. Однак наскільки реально забезпечити якість і надійність складної багатофункціональної системи при обмежених термінах розробки? Для ілюстрації можна навести результати опитування більше тисячі великих компаній, проведеного міністерством торгівлі і промисловості Великобританії. Виявилося, що середня частота відмов інформаційних систем склала: 1 відмова в рік - 40% компаній, 1 відмова в місяць - 29%, 1 відмова в тиждень - 15% компаній, 1 відмова в день - 7% і 5% компаній спостерігали у себе більше одного відмови в день. При цьому частка відмов і збоїв програмного забезпечення в загальному списку причин непрацездатності (простоїв) інформаційних систем становила 24% [3].

Залежно від комплекту поставки, система "Галактика" може включати понад три тисячі взаємопов'язаних бізнес-функцій, результати виконання яких контролюються понад 300 параметрами налаштування. Очевидно, що домогтися необхідної якості і надійності можна, тільки позначивши їх як пріоритетну мету і постійно просуватися до неї за наступними напрямками:


Рис. 1. Структура системи якості Департаменту розробки ПО.

Сходи, що ведуть до якості

Один з ключових елементів забезпечення якості - це тестування. Багато відомих розробники ПЗ проводять тестування своїх продуктів в кілька етапів, які відрізняються видами виконуваних робіт і залучаються ресурсами. Корпорація "Галактика" в цьому сенсі не виняток.

Фактично, тестування починається ще в процесі кодування чергової версії. У складі груп фахівців, що працюють над певною частиною системи, є так звані "локальні" тестувальники. Їх завдання - оперативне тестування розроблених нових або змінених функцій системи. Подібна "конвеєрна" організація робіт дозволяє заощадити час і сили, оскільки значна частина помилок виявляється і усувається практично в момент виникнення. Робота тестувальників на цьому етапі як би локалізована в рамках частини системи, що розробляється даною групою, тому ми говоримо про "локальному" тестуванні.

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

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

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

Спочатку в роботу включаються тільки підрозділи Департаменту розробки ПО (відділ інтегрального тестування та ін.) - цей етап циклу розробки називається внутрішнім тестуванням. Перевіряється функціональна повнота системи, відповідність проектної документації, коректність проектних рішень. Контролюється відповідність законодавствам країн СНД: Росії, Білорусі, України і Казахстану.

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

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

І на внутрішньому, і на зовнішньому тестуванні постійно проводиться статистичний аналіз кількості виявлених і виправлених помилок, на основі результатів якого приймається рішення про перехід до наступного етапу (рис. 2).


Рис. 2. Мінімізація помилок на різних стадіях розробки ПЗ.

Заключне тестування проводить відділ інтегрального тестування Департаменту розробки ПО. Його завдання - ще раз перевірити реалізацію максимальної кількості бізнес-процесів і переконатися, що виправлення помилок на попередніх етапах не викликало нових помилок. Фактично це "прогін" системи, на який відводиться 10 робочих днів. Для порівняння - під час приймання систем військового призначення на аналогічну процедуру виділялося максимум 4 дні. Ми відводимо на це більше часу і ресурсів, щоб гарантувати високу надійність за рахунок повного охоплення типових бізнес-процесів.

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

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

Фундамент якості і його складові

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

Дотримуючись досвіду IBM і рекомендацій ISO 9000-3 [2,4], в штатну структуру Департаменту розробки ПО була введена посада фахівця з якості, якому функціонально підкоряються локальні тестувальники груп і відділ інтегрального тестування. Головне завдання цього фахівця - забезпечити необхідний рівень якості і надійності програмного продукту (версії, релізу).

Що стосується технічного забезпечення, то тут, перш за все, слід відзначити систему автоматизованого тестування AQA, що дозволяє нам вирішувати цілий ряд питань.

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

Система автоматизованого тестування теоретично дозволяє гарантувати стовідсоткове якість системи, необхідно лише скласти вичерпну бібліотеку сценаріїв. Традиційно вважається, що якість програми є функцією від кількості тестів [5]. Але для складного багатофункціонального програмного продукту, такого як "Галактика", створення подібної бібліотеки - вкрай складне завдання, що вимагає колосальних ресурсів. Тому ми дотримуємося іншого підходу: більшість помилок виявляються і усуваються на ранніх стадіях розробки, а під час інтегрального тестування пріоритетна роль відводиться комплексним тестів, які перевіряють реалізацію бізнес-процесів в цілому, а також взаємодія різних модулів системи. Розробкою таких сценаріїв займаються тестувальники, що мають багатий досвід автоматизації великих підприємств різних галузей і форм власності.

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

Автоматизована система "Проблеми і рішення" (ПІР) являє собою засіб оперативного контролю якості і надійності, яке активно використовується під час тестування для реєстрації та статистичної обробки інформації про знайдені і виправлені помилки. У той же час ПІР - це система оперативного зворотного зв'язку зі споживачами. Де б не виникла проблема: в Москві, Мінську, Владивостоці, вона дуже швидко потрапляє в Центр розробки. Швидкість надходження фактично визначається швидкістю передачі інформації по лініях зв'язку, при цьому відразу відомо особа, відповідальна за вирішення проблеми, і контролюються терміни.

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

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

Технологія тестування залежить, зокрема, від обсягу інформації, що зберігається в тестовій базі даних (БД). Неодмінним елементом тестування є перевірка працездатності системи на порожній базі, що фактично являє собою модель діяльності нового клієнта: систему треба налаштувати, заповнити основні довідники, ввести початкові дані. Для детальної перевірки складних бізнес-процесів, що вимагають настройки на регіональну або галузеву специфіку, використовуються бази з об'ємом даних до 1 Гбайт). На всіх рівнях інтегрального тестування виконується ряд еталонних і специфічних тестів для набору баз даних. Таким чином, до графіку (рис. 2) додається ще один вимір (БД). В результаті тестування стає "тривимірним".

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

Профілактика вигідніше лікування

Ретельне тестування програмного забезпечення - найбільш очевидний спосіб забезпечення його надійності. Дійсно, тестування - це діагностика хвороби, аналіз симптомів, виявлення джерела і визначення найкращої методики лікування. Однак не менш важливі профілактичні заходи [4, 5].

Система попередження "хвороби" включає ряд організаційних заходів, суть яких зводиться до забезпечення надійності та якості на всіх стадіях розробки, починаючи від проектування. На сьогодні співвідношення часу, витраченого на проектування, кодування і тестування становить 40%, 20% і 40% відповідно. Проектування розбивається на кілька етапів: розробка технічного завдання, його аналіз, створення макета системи. Результати кожного етапу піддаються експертизі, перехресній перевірці та взаємоузгодження. Наявність детально відпрацьованої проектної документації суттєво знижує ймовірність виникнення помилок і є додатковою гарантією надійності продукту.

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

література

  1. A.Davis. "Fifteen Principles of Software Engineering" // IEEE Software, Vol.11, №6, 1994, pp.94-101.
  2. K.Rubin. Developing object-oriented software / IBM Object-Oriented Technology Center, Prentis Hall Inc, 1997.
  3. В.Шніман. Відмовостійкі комп'ютери компанії Stratus. // Відкриті системи, №1, 1998, с.13-22.
  4. Загальне керівництво якістю і стандарти по забезпеченню якості (ISO 9000-1). Настанови щодо застосування стандарту ISO 9001, при розробці, поставці і обслуговуванні програмного забезпечення ((ISO 9000-3).
  5. Д.Коул, Т. Горем, М. МакДональд, Р. Спарджеон. Принципи тестування ПО. // Відкриті системи, №2, 1998. с. 60-63.

система ПИР

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

Тестування ПЗ як один з елементів системи якості

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