lec_m1

Т Е М А 1

ПРОГРАМНА ІНЖЕНЕРІЯ В ЖИТТЄВОМУ ЦИКЛІ ПРОГРАМНИХ ЗАСОБІВ

1.1. Основи життєвого циклу програмних засобів

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

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

знаступною адаптацією кожного з них в моделі життєвого циклу конкретної системи :

—визначення потреб;

—дослідження і опис основних концепцій;

—проектування і розробка;

—випробування системи;

—створення і виробництво;

—поширення і продаж;

—експлуатація;

—супровід і моніторинг;

—зняття з експлуатації (утилізація).

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

Перший клас складають відносно невеликі програми, що створюються одинаками або невеликими колективами (3-5) фахівців, які, :

—створюються переважно для отримання конкретних результатів автоматизації наукових досліджень або для аналізу відносно простих процесів самими розробниками програм;

—не призначені для масового тиражування і поширення як програмного продукту на ринку, їх оцінюють якісно і інтуїтивно переважно як "художні твори";

—не мають конкретного незалежного замовника-споживача, що визначає вимоги до програм і їх фінансування;

—не обмежуються замовником допустимою вартістю, трудомісткістю і термінами їх створення, вимогами заданої якості і документування;

—не підлягають незалежному тестуванню, гарантуванню якості і сертифікації.

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

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

1

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

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

—від замовника, що фінансує проект програмного засобу і бази даних, розробникам необхідно отримувати кваліфіковані конкретні вимоги до функцій і характеристик проекту і продукту, що відповідають виділеному фінансуванню і кваліфікації виконавців проекту;

—для організації і координації діяльності фахівців-розробників за наявності єдиного, великого цільового завдання, створення і вдосконалення програмного продукту потрібні кваліфіковані менеджери проектів;

—у проектах таких складних програмних засобів і баз даних з множиною різних функціональних компонентів беруть участь фахівці різної кваліфікації і спеціалізації, від яких потрібно висока відповідальність за якість результатів діяльності кожного з них;

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

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

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

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

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

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

2

Мал. 1.1

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

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

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

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

3

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

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

—розширення і вдосконалення функцій систем і компонентів із збереженням їх цілісності і первинних витрат;

—систематичне підвищення якості функціонування комплексів програм і баз даних для вирішення завдань користувачів в різному зовнішньому середовищі;

—поліпшення техніко-економічних характеристик застосування систем і програмних продуктів;

—вдосконалення технологій забезпечення життєвого циклу складних систем і комплексів програм.

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

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

—у структурі і компонентах ПЗ і системи слід передбачати забезпечення максимально можливого збереження інвестицій в апаратні і програмні засоби, а також в бази даних при тривалому розвитку, супроводі і модернізації системи;

—необхідно забезпечувати ефективне використання ресурсів в ЖЦ системи і мінімізувати інтегральні витрати на обробку даних в типових режимах її функціонування з урахуванням експлуатаційних витрат і капітальних вкладень в створення системи і програмного продукту;

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

—для забезпечення перспективи розвитку життєвого циклу системи і комплексу програм доцільно передбачати можливість інтеграції гетерогенних обчислювальних компонентів і можливість перенесення ПЗ і БД на різні апаратні і операційні платформи на основі концепції і стандартів відкритих систем;

—слід забезпечити комфортне навчання і максимально спрощений доступ кінцевих користувачів до управління і результатів функціонування системи і програмного продукту на основі сучасних графічних засобів і наочних призначених для користувача інтерфейсів.

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

4

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

1.2. Роль системотехніки в програмній інженерії

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

взаємодії з іншими підсистемами.

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

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

Інженери-системотехніки на основі специфікації вимог системи визначають її архітектуру і потім, зібравши разом її окремі частини, створюють закінчену систему.

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

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

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

5

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

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

робота.

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

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

Фахівець з програмної інженерії повинен знати системотехніку обчислювальних систем, оскільки тут програмний компонент грає визначальну роль. Таким чином, технології програмної інженерії часто є критичним чинником при розробці складних обчислювальних систем. Інтеграційні властивості систем проявляються тільки тоді, коли система розглядається як єдине ціле. У цьому полягає складність прогнозування і оцінки її властивостей, оскільки іноді можна виміряти характеристики тільки підсистем, з яких складається комплексна система. Високі темпи зростання основних ресурсів апаратних засобів (приблизно на порядок кожні п'ять років) і потреба, що зберігається, в збільшенні їх використання з боку різних користувачів і сфер застосування призводять до необхідності адекватного вдосконалення технологій створення програмних засобів і баз даних.

1.3. Системні основи сучасних технологій програмної інженерії

Основна мета сучасних технологій програмної інженерії

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

6

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

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

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

технологічних і людських чинників.

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

Досягнення високих значень якості комплексів програм істотно залежить від якості технології і інструментальних засобів, використовуваних розробниками для забезпечення ЖЦ ПЗ. Рівень автоматизації, якість технології і засобів, які використовуються для підтримки процесів життєвого циклу ПЗ, зазвичай сильно корельовані з якістю створюваних комплексів програм, а також з якістю засобів автоматизації для їх оцінювання. Оцінювання переваг технологічної бази ЖЦ дозволяє прогнозувати можливу якість ПЗ і орієнтувати замовника і користувачів при виборі розробника і постачальника для певного проекту з необхідними характеристиками. Тому визначення рівня технологічної підтримки процесів життєвого циклу, організаційного і інструментального забезпечення ПЗ безпосередньо пов'язано з оцінюванням реальних або можливих характеристик якості конкретного комплексу програм.

Значні досягнення в розвитку і застосуванні сучасних методів і технології забезпечення великомасштабних проектів ПЗ зосереджені в методології СММ (Capability Maturity Model - система і модель для оцінки зрілості) комплексу технологічних процесів життєвого циклу ПЗ, а також в її наступному розвитку в СММ1:2003 (див. лекцію 3). Вона заснована на формалізації і використанні п'яти рівнів зрілості технологій підтримка ЖЦ ПЗ, яка також визначає потенційно можливу якість створюваних на підприємстві комплексів програм. Чим вище рівень зрілості, тим вище статус підприємства серед постачальників, довіра до його продукції, його конкурентоспроможність, а також можлива якість програмних продуктів. Тим самим при виборі значень характеристик якості ПЗ можна у відповідній мірі довіряти постачальникові і підприємству розробника, що вони зможуть повністю реалізувати вимоги замовника. Ці рівні зрілості характеризуються мірою формалізації, адекватністю виміру і документування процесів і продуктів в ЖЦ ПЗ, повнотою застосування стандартів і інструментальних засобів автоматизації робіт, наявністю і глибиною реалізації функцій, системою якості технологічних процесів і їх результатів.

Методологія забезпечення якості ПЗ в програмній інженерії підтримана рядом методичних документів і інструментальних засобів, а також формалізована комплексом міжнародних стандартів (див. Застосування 1). Впровадження комплексу вимагає великих зусиль і витрат, що обмежило його масове використання для відносно простих і середніх по складності проектів. Концептуальні і організаційні основи адміністративного управління життєвим циклом і якістю ПЗ в системі СММ, а також СММ1:2003, визначені у восьми базових принципах, які декларують в стандартах ISO 9000:2000 і ISO 15504:1-9.

Принцип 1 - Орієнтація підприємства-розробника на замовника-користувача. "Підприємства залежать від своїх споживачів і, таким чином, повинні розуміти поточні і

7

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

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

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

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

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

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

Принцип 7 - Підхід до ухвалення рішень, заснований на фактах. "Ефективні рішення повинні базуватися на аналізі тільки реальних даних і достовірної інформації".

Принцип 8 - Взаємовигідні стосунки з постачальниками. "Підприємство-користувач і його постачальники-розробники взаємозалежні, і взаємовигідні стосунки між ними

підвищують здатність обох проводити якісну продукцію".

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

—формулюванню політики і стратегії забезпечення усього ЖЦ ПЗ;

—виборі цілей проекту, вимог і характеристик якості ПЗ, безпосередньо пов'язаних з потребами і очікуваннями замовників і споживачів;

—управлінні операціями в процесі реалізації проекту і для задоволення вимог замовника і споживачів;

—управлінні людськими ресурсами підприємства для забезпечення ЖЦ ПЗ і його

якості.

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

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

—створювати програмні модулі і функціональні компоненти високої, гарантованої якості;

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

—виявляти і усувати різні дефекти і помилки проектування, розробки і супроводу

8

програм шляхом верифікації і систематичного тестування на усіх етапах життєвого циклу ПЗ;

— засвідчувати досягнуті значення якості функціонування програмних продуктів в процесі їх випробувань і сертифікації перед передачею в регулярну експлуатацію

користувачам.

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

—на придбання або створення технології і інструментальних засобів, вживаних для забезпечення необхідної якості усього життєвого циклу ПЗ;

—на експлуатацію і безпосереднє застосування технології в процесі забезпечення ЖЦ

ПЗ;

—на створення технології і інструментальних засобів для випробувань і оцінювання характеристик якості програмного засобу;

—на виконання вимірів досягнутих значень характеристик якості ПЗ.

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

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

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

9

надійності і безпеки при проектуванні і експлуатації.

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

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

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

Основою сертифікації мають бути детальні і ефективні Програми і методики випробувань комплексів програм на відповідність вимогам замовників, спеціально розроблені тестові завдання і генератори для їх формування, а також висока кваліфікація і авторитет випробувачів. Застосування на підприємствах-розробниках програмних продуктів, сертифікованих систем якості і профілів міжнародних стандартів на базі вимог ISO 9001:2000 і СММ1:2003 гарантує високе, стійке управління якістю процесів і продуктів їх життєвого циклу, а також дозволяє у багатьох випадках полегшувати сертифікацію кінцевого програмного продукту. Тому замовники складних програмних проектів повинні вибирати підрядчиків-виконавців, що мають сертифікати, що засвідчують застосування ними систем гарантування якості на основі адаптованих профілів міжнародних стандартів.

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

характеристик якості програмних продуктів.

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

10