Турбота про якість стає першочерговим завданням розробників, Комерція, Різне, статті

Не терміни випуску, а якість є найважливішим критерієм при розробці ПЗ. Корпорація Microsoft стала активно проповідувати такий підхід, оголосивши 29 листопада, що буде випускати попередні версії ОС Vista у міру досягнення певних якісних рубежів, а не за календарним графіком.

Однак філософія якості була сформульована за тиждень до цього під час організованої Лабораторією eWeek Labs дискусії за круглим столом, присвяченій забезпеченню якості додатків протягом усього їх життєвого циклу і способам його досягнення. В обговоренні взяли участь представники компаній – виробників засобів забезпечення якості, корпорації Microsoft – творця платформи та інструментів, а також клієнти цих компаній.

Масовий випуск продуктів з десятками функцій спонукає розробників задавати такі критерії готовності ПО, як “90-процентна завершеність”. Однак при більш коротких термінах розробки стає важко замаскувати дефект за допомогою списку нових можливостей. “Я вважаю ітерації завершеними, коли продукт досягає певного рівня якості. Це – ключовий елемент управління проектом”, – заявив під час організованої Лабораторією eWeek Labs дискусії Ян Мак-Ліод, старший віце-президент по продуктах компанії Segue Software (Лексінгтон, шт. Массачусетс).

Інші учасники круглого столу погодилися з Мак-Ліодом, що в списку цілей розробників якість займає верхній рядок, і підкреслили, що слово “якість” має на увазі не тільки повна відповідність специфікаціям, але і задоволення пропонованих реальними користувачами вимог, що набагато ширше.

Обсяг і характер гарантії якості (Quality Assurance, QA) ще більше розширюються, коли організації використовують придбане програмне забезпечення та мережеві сервіси як компоненти спеціалізованих бізнес-додатків. “Ми все ширше і ширше застосовуємо компонентну архітектуру. Це веде до підвищення рівня складності додатків у міру того, як вони стають все більш розподіленими, все менш жорстко пов’язаними і все більше схильними змін з боку творців цих компонентів “, – заявив Елдад Манів, віце-президент з управління продуктами компанії Identify Software (Нью-Йорк).





Створюючи екосистему якості  

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

“Ми керуємося концепцією, яку називаємо” повністю готовим інструментальним набором для повного життєвого циклу “(fully connected life-cycle tool bench)”, – заявив Кріс Мейстрік, директор з інжинірингу ПО компанії Jewelry Television (Ноксвіл, шт. Теннесі). Компанія займається розповсюдженням телепрограм для кінцевих користувачів по телевізійним каналам і через Інтернет. Перш, до повного оновлення в минулому році, вона називалася America’s Collectibles Network. “Ми зосередили свої зусилля на інтеграції, – сказав Мейстрік. – Інженер використовує набір інструментів. Ми не хочемо змушувати його протягом всього життєвого циклу ПО розшукувати необхідні інструменти десь ще, оскільки це відволікало б його від вирішення власних завдань і робило його працю неефективним “.

Вендори можуть не намагатися продати Мейстріку інструмент, який не має відкритого інтерфейсу API для доступу до його функцій. Дійсно, Мейстрік називає відкритий API абсолютно необхідним. При цьому він додає: “До тих пір, поки вендор не готовий надати нам його, ми не купуємо інструмент. В іншому випадку ми знайдемо інструмент з відкритим вихідним кодом, нехай навіть не володіє всією красою і прикрасами. Це те, на що ми завжди звертаємо увагу в першу чергу “.

Наприклад, розповів Мейстрік, “… ми використовуємо Microsoft Project. Але ми не вводимо в нього інформацію вручну, а примусово закладаємо в Project свої вимоги і автоматично отримуємо готову схему. У нас кожна підпрограма автоматично генерує повідомлення про необхідність внесення змін, які прив’язані до вихідного коду. Ось як у нас робиться “.

Результатом, говорить Мейстрік, є середа, де релевантна інформація може доставлятися його інженерам, які можуть швидко її використовувати. “Інженери працюють з Eclipse, – сказав він. – Їм необхідно знати, які вимоги пред’являються до цієї технології. Вони можуть захотіти познайомитися з результатами тестових випробувань, які не зміг пройти продукт. Але в будь-якому випадку вони хочуть, щоб все це надавалося їм в рамках використовуваної ними середовища “.

Мак-Ліод з компанії Segue сказав, що сподівається дочекатися більш повної інтеграції інструментів, що застосовуються в галузі. “Якість пронизує всі елементи екосистеми – формулювання вимог, розробку і керування тестуванням, виправлення дефектів, моніторинг та діагностику в процесі розгортання і роботи. Зазвичай ви стикаєтеся з інтеграцією типу “точка – точка”, що володіє відомими проблемами контролю за конфігурацією інтерфейсів, узгодження формату даних, угоди про спільне репозиторії, – відзначає він. – Є декілька ініціатив, таких як схема життєвого циклу програми (application life-cycle framework project). Це порівняно новий проект в рамках Eclipse, що представляє собою спробу стандартизувати інтеграцію “.

Мейстрік з Jewelry Television впевнений, що його зусилля принесуть плоди: “Вирішення проблем якості ПО являє собою значні інвестиції стратегічного характеру для нашої компанії. Воно диктується потребами бізнесу і повернення вкладених коштів. Протягом минулого року ми переконалися, що реалізація подібних ідей і концепцій дає безпосередній результат. У компанії цьому приділяється увага на найвищому рівні “.

Небагато галузі змогли продемонструвати настільки ж швидкий зліт, як телевізійний і онлайновий бізнес компанії Мейстріка. Серед них – гральний бізнес в Лас-Вегасі. Компанія Station Casinos (Лас-Вегас) є одним з головних гравців у цій області, де керує десятком гральних закладів і готелів.

Гральному бізнесу потрібно безперервно створювати нові відчуття у клієнтів. При цьому він приділяє неослабну увагу до забезпечення максимального часу роботи при мінімальних витратах. “Все, що ми робимо для збільшення доходів, в основному пов’язано з ІТ, – говорить віце-президент і CIO компанії Station Casinos Маршал Ендрю. – Ми прагнемо скоротити життєвий цикл, пройти процес QA, застосовувати продукти там, де вони допоможуть нам отримувати прибуток. Ми підшукуємо продукти, послуги та комплексні навички, які дозволяють нам своєчасно реагувати на вимоги ринку “.

Ендрю прекрасно знає про ситуацію, сьогодні високій частці витрат часу на QA. “Якщо створення програми займає, наприклад, шість місяців, то на QA зазвичай потрібно три місяці. На QA припадає 50% часу, необхідного для програмування. Ми прагнемо скоротити період QA, не жертвуючи якістю, застосовуючи інструменти, які зменшують час QA, а в процесі QA виявляють дефектні фрагменти, які ми можемо повернути програмістам. Таким чином, їм не доводиться витрачати дні або годинник на виявлення проблеми “, – сказав він.

Ендрю навів приклад з недавнього минулого, коли система, з якою працюють користувачі, валилася кожен день, що істотно впливало на прибуток. Застосувавши технологію AppSight Black Box компанії Identify Software і попрацювавши з технічним персоналом Microsoft, розповів він, “… ми виявили кілька сценаріїв. Без цих інструментів ми шукали б їх багато тижнів. Я був налаштований дещо скептично, але тепер я твердо в них вірю “.

Корпорація Microsoft (Редмонд, шт. Вашингтон) була представлена ​​на конференції Семом Гакенхеймером, що відповідає за планування груп продуктів Microsoft Visual Studio Team System і Microsoft Solutions Framework. Гакенхеймер підкреслив, що для забезпечення якості додатку необхідно бачити весь процес від початку до кінця. За його словами, все починається з дизайну: “Ми питаємо, що повинен зробити архітектор в період роботи над дизайном, щоб побачити, чи правильно визначений дизайн програми та враховує воно такі можливості, як порушення безпеки “.

Менеджери, що управляють процесом розробки, вважає Гакенхеймер, повинні зрозуміти, що більшість програмістів не є і ніколи не стануть експертами з безпеки і що тому автоматичний аналіз потенційних проблем безпеки повинен включатися в усі інструменти і процеси і бути присутнім в них повсюдно. “Ми прагнемо автоматично перевіряти код на предмет безпеки. Ми включили до складу Visual Studio Team System наші інструменти, розроблені для внутрішнього використання, щоб продемонструвати прийоми програмування, які дозволяють скоротити кількість проблем “, – сказав він.

Гакенхеймер та інші відразу ж відзначили, що процес забезпечення якості вимагає зворотного зв’язку незалежно від того, які кошти були витрачені на придбання хороших інструментів, а також досвіду до початку розгортання програми. Деякі проблеми проявляться лише в робочому середовищі. Однак віце-президент Identify Software Лорі Уїздом висловила заклопотаність у зв’язку з тим, що клієнти можуть помилково визначати якість як щось створене розробниками, а не те, з чим мають справу користувачі.

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

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

Гакенхеймер висловив також сподівання, що розробники будуть застосовувати технологію віртуалізації для скорочення розриву між лабораторними умовами і виробничим середовищем. “Ми даємо вам можливість тримати тестову лабораторію у вигляді віртуальних машин. В результаті ви можете зберігати де-небудь на диску сервера файл з образом віртуальної машини, що відповідає виробничим умовам. Це позбавить вас від проблеми «на моїй машині цього немає» “.

Можна значно скоротити затримки і в процесі розробки, вважає Гакенхеймер. “На етапі визначення дизайну ви отримуєте можливість відразу перевірити, чи буде працездатний обраний вами спосіб створення розподіленої системи. Це економить масу часу в поетапному процесі пошуку відповідей на питання на зразок “Який порт мені потрібно відкрити?”, “Чи слід нам змінити процедуру аутентифікації на цьому сервері?”. Такі проблеми не відносяться власне до програмування. Але тут кожен сліпий уявляє собі ногу слона по-своєму “, – сказав він.

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

Колега Піно з Segue Software, Макліод, згоден з цим. Він сказав: “Оскільки розробники проводять все більше тестів, тестувальникам, можливо, слід приділяти більше уваги користувачам замість того, щоб просто перевіряти відповідність вимогам “.

Оскільки продуктивність праці розробника зростає завдяки вкладенню коштів у підвищення якості, менеджерам підприємств слід витратити частину зекономлених коштів на те, щоб краще розуміти і задовольняти потреби користувачів. Інструменти підвищення якості повинні в певному сенсі розглядатися як мають можливість такого більш широкого підходу, а не як кінцевий пункт погоні за якістю: “Я не бачив жодного інструменту, який дозволив би мені дізнатися, що в моїх вимогах до програми міститься помилка. Я не бачив інструмента, який підказав би мені, яким чином необхідно змінити мої вимоги “, – сказав Даліміла Хандейкер, менеджер розташованих в Торонто офісів компанії CGI Group по продуктивності та налаштування програм для підприємств. CGI надає своїм клієнтам кваліфіковані послуги.

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

Учасники дискусії погодилися, що економічні питання якості додатків не врегульовані.

“Кілька років тому було випущено дуже цікаве дослідження Національного інституту стандартів і технологій (National Institute of Standards and Technology), в якому вивчався загальний економічний ефект якості ПЗ, – повідомила Уїздом з Identify Software. – В цій доповіді стверджувалося, що цілих 80% витрат на розробку ПО пов’язане з виправленням дефектів. Рішення даної проблеми має принципове значення “.

Підвищення продуктивності праці розробника замість простого нарощування людино-годин – це принциповий висновок, якого дійшов Ендрю з Station Casinos: “Ми виявили, що дуже важко знайти досвідчених технічних спеціалістів навіть за межами штату. Тому ми прагнемо підвищувати ефективність за допомогою досконаліших інструментів і більш якісного навчання “, – сказав він. Крім того, повідомив він, інвестиції з часом амортизуються, а зарплати щомісяця відображаються у вашій декларації про доходи.

Говорити одночасно про технологію процесу і корпоративних фінансах значить зачіпати ще один ключовий момент: дотримання вимог закону Сарбейнса – Окслі. “Необхідність послідовно забезпечувати якість і зробити процес розробки прозорим і піддається контролю створює помилкове уявлення, ніби спочатку ми все робили неправильно, – заявив Мейстрік з Jewelry Television. – А тепер нам кажуть, що надалі ми повинні робити все по-хорошому. Але нам і самим це необхідно “.

“Платформа, що складається з продуктів декількох виробників і багатьох версій продуктів, створює безліч труднощів”, ​​- поділився спостереженням Хандейкер з CGI.

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

Такі умови, в яких повинні конкурувати виробники інструментів забезпечення якості, – чи їх будуть ігнорувати.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*