• 6.1                    Рівні стандартизації
• 6.2                    Міжнародні стандарти
• 6.3                    Галузеві стандарти
  • 6.3.1                    Керівництво до зведення знань із програмної інженерії
• 6.4                    Державні стандарти
  • 6.4.1                    Державні стандарти України
  • 6.4.2                    Модель зрілості технологічних процесів організації (Capability Maturity Model)
• 6.5                    Методології програмування, що вплинули на галузеві стандарти

6.1                    Рівні стандартизації

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

Рисунок 6.1   — Стандарти ІТ-галузі

Одним із перших стандартів, що мав істотний вплив на розвиток теорії проектування та розроблення ІС, був стандарт BSP (Business System Planning). Даний стандарт був  розроблений компанією IBM у середині 70-х рр. ХХ ст.  Процес BSP передбачав виділення в ході розроблення ІС таких кроків: отримання підтримки керівництва, визначення процесів підприємства, визначення класів даних, проведення інтерв’ю, обробка та організація результатів інтерв’ю. Найважливіші кроки процесу BSP спостерігаються у більшості формальних методик.

 

6.2                    Міжнародні стандарти

На сьогодні галузь програмування є достатньорегульованою. 

Базовим стандартом розроблення ПЗ є ISO 12207. Systems and software engineering – Software Life Cycle Processes, в якому усі процеси ЖЦ ПЗ розподілені на три групи (рис.3.2).

 

Рисунок 6.2   – Процеси ЖЦ ІС відповідно до стандарту ISO 12207

У табл. 3.1 наведений опис основних процесів ЖЦ. 

Таблиця 6.1   - Зміст основних процесів ЖЦ ПЗ ІС відповідно до ISO 12207

Процес (виконавець)	Дії	Вхід	Результат
Купівля (замовник)	Ініціювання Підготовка вимог заявки Підготовка угоди Контроль діяльності постачальника Приймання ІС	Рішення про початок впровадження ІС Результати дослідження діяльності замовника Результати аналізу ринку ІС/ тендера План постачання/ розроблення Комплексний тест ІС	Техніко-економічне обгрунтування впровадження ІС Технічне завдання на ІС Угода на постачання/ розроблення Акти приймання етапів роботи Акт приймально-передавальних випробувань
Постачання (розробник ІС)	Ініціювання Відповідь на замовлення Підготовка угоди Планування виконання Постачання ІС	Технічне завдання на ІС Рішення про участь у розробленні Результати тендера Технічне завдання на ІС План керування проектом Створена ІС та документація	Рішення про участь в розробленні Комерційна пропозиція/ конкурсна заявка Угода про постачання/ розроблення План керування проектом Реалізація/ коригування Акт приймально-передавальних випробувань
Розроблення (розробник ІС)	Підготовка Аналіз вимог до ІС Проектування архітектури ІС Розроблення вимог до ІС Проектування архітектури ПЗ Детальне проектування ПЗ Кодування та тестування ПЗ Інтеграція ПЗ та кваліфікаційне тестування ПЗ Інтеграція ІС та кваліфікаційне тестування ІС	Технічне завдання на ІС Технічне завдання на ІС, модель ЖЦ Технічне завдання на ІС Підсистеми ІС Специфікації вимог до компонентів ПЗ Архітектура ПЗ Інформація про деталі проектування ПЗ План інтеграції ПЗ, тести Архітектура ІС, ПЗ, документація на ІС, тести	Модель ЖЦ, стандарти розроблення План робіт Склад підсистем, компоненти обладнання Специфікації вимог до компонентів ПЗ Склад компонентів ПЗ, інтерфейси з БД, план інтеграції ПЗ Проект БД, специфікації інтерфейсів між компонентами ПЗ, вимоги до тестів Тексти модулів ПЗ, акти автономного тестування Оцінка відповідності ПЗ вимогам ТЗ Оцінка відповідності ПЗ, БД, технічного комплексу та комплекту документації вимогам ТЗ

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

Для підтримки практичного використання стандарту ISO 12207 розроблені такі технологічні документи: Керівництво для ISO/IEC 12207 (ISO/IEC TR 24748-3:2011 Systems and software engineering - Life cycle management - Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes)) та Керівництво з використання ISO/IEC 12207 в керуванні проектами (ISO/IEC TR 16326:2009 Systems and software engineering - Life cycle processes - Project management).

У 2002 р. був опублікований стандарт на процеси життєвого циклу систем ISO/IEC 15288 Systems and software engineering - System life cycle processes [26], у розробленні якого брали участь фахівці різних галузей: системної інженерії, програмування, управління якістю, людськими ресурсами, безпекою та ін. Даний документ враховує практичний досвід створення систем в урядових, комерційних, військових та академічних організаціях і може бути застосований для широкого класу систем, але його основне призначення – підтримка створення комп'ютеризованих систем. На цей час діє версія стандарту 2008 р. У стандарті ISO/IEC 15288:2008 у структурі ЖЦ виділені групи процесів за видами діяльності (рис.3.3).

Стадії створення системи, передбачені у стандарті ISO/IEC 15288:2008, та основні результати, які повинні бути досягнуті до моменту їх завершення, наведені в таблиці 3.2.

Стандарти ISO/IEC 12207 та ISO/IEC 15288 мають єдину термінологію і розроблені таким чином, щоб могли використовуватись одночасно у проекті. 

Таблиця 6.2   – Стадії створення систем (ISO/IEC 15288)

Ном. поряд.	Стадія	Опис
1	Формування концепції	Аналіз потреб, вибір концепції та проектних рішень
2	Розроблення	Проектування системи
3	Реалізація	Створення системи
4	Експлуатація	Введення в експлуатацію та використання системи
5	Підтримка	Забезпечення функціонування системи
6	Зняття з експлуатації	Зупинення використання, демонтаж, архівування системи

 

Рисунок 6.3   – Процеси ЖЦ систем відповідно до стандарту ISO/IEC 15288

 

Також потрібно відмітити, що у процесі промислового розроблення ПЗ обов’язково використовуються стандарти якості серії ISO 9000. Серія ISO 9000 [19] (управління якістю) містить у собі такі стандарти:

• ISO 9000-1. Керування якістю і гарантії якості. Частина 1. Посібник з вибору й використання.
• ISO 9000-2. Керування якістю й гарантії якості. Частина 2. Загальний посібник із застосування стандартів ISO 9001, ISO 9002 і ISO 9003.
• ISO 9000-3. Керування якістю й гарантії якості. Частина 3. Посібник із застосування стандарту ISO 9001 при розробленні, установці й супроводі ПЗ.
• ISO 9000-4. Керування якістю й гарантії якості. Частина 4. Посібник з керування надійністю програм.

Основний стандарт ISO 9001:2009 [26] задає модель системи якості для процесів проектування, розроблення, виробництва, установки й обслуговування (продукту, системи, послуги). У моделі ISO 9000 лише згадуються вимоги, які повинні бути реалізовані, але не говориться, як це можна зробити. Тому для побудови повноцінної системи якості за ISO, крім основної моделі ISO 9001, необхідно використовувати допоміжні галузеві та рекомендаційні стандарти.

6.3                    Галузеві стандарти

У 1963 р. у результаті злиття Інституту радіотехніків (Institute of Radio Engineers, IRE) і Американського інституту інженерів-електриків (American Institute of Electrical Engineers, AIEE) була створена міжнародна некомерційна асоціація технічних фахівців, світовий лідер у галузі розроблення стандартів з радіоелектроніки та електротехніки Інститут інженерів з радіоелектроніки та електротехніки IEEE (Institute of Electrical and Electronics Engineers). Дана міжнародна організація об’єднує понад 400 тис. фахівців із 170 країн. IEEE  здійснює інформаційну і матеріальну підтримку фахівців для організації та розвитку наукової діяльності в електротехніці, електроніці, комп'ютерній техніці та інформатиці.

Наприкінці 1990 рр. комп’ютерне товариство IEEE (IEEE Computer Society, IEEE-CS) разом із дуже впливовою в комп'ютерній галузі організацією – Асоціація обчислювальної техніки (Association for Computing Machinery, ACM) – розпочало розробку стандартів у галузі програмної інженерії, які оформились у три документи:

1. Software Engineering Body of Knowledge, SWEBOK – збірка необхідних у програмній інженерії знань та рекомендованих технік. Документ розроблений у 2004 р., у 2005 р. він визнаний міжнародним стандартом ISO/IEC TR 19759:2005, у 2008 р. документ змінений у відповідності до навчального плану Computer Science Curriculum 2008. На цей час діє версія 3, затверджена IEEE-CS у 2013 р.
2. Software Engineering Code of Ethics and Professional Practice, SECEPP – збірка професійних та етичних норм. Вперше опублікована у 1998 р., на цей час діє версія 5.2 .
3. Computer Science Curricula (SE2013) – документ, присвячений навчальному плану в галузі комп’ютерних наук, найновіша версія складена у 2013 р.

6.3.1                    Керівництво до зведення знань із програмної інженерії

Керівництво до зведення знань із програмної інженерії (SWEBOK, 2013)  містить опис 15 галузей знань [25]:

• Software requirements – програмні вимоги;
• Software design – дизайн (архітектура);
• Software construction – конструювання програмного забезпечення;
• Software testing – тестування;
• Software maintenance – експлуатація (підтримка) програмного забезпечення;
• Software configuration management – управління конфігураціями;
• Software engineering management – управління у програмній інженерії;
• Software engineering process – процеси програмної інженерії;
• Software engineering tools and methods – інструменти та методи;
• Software quality – якість програмного забезпечення;
• Software engineering professional practice (Software engineering professionalism) - професійні вимоги;
• Software engineering economics - економіка програмної інженерії;
• Computing foundations - основи обчислень;
• Mathematical foundations - математичні основи;
• Engineering foundations - основи інженерних знань.

Для кожної галузі  SWEBOK містить опис ключових елементів у вигляді підобластей (subareas). Для кожної підобласті наведена декомпозиція у вигляді списку тем (topics) із їх описом. 

6.4                    Державні стандарти

 

6.4.1                    Державні стандарти України

В Україні у ІТ- галузі діють як стандарти, розроблені органами стандартизації СРСР, частково перезатвердженні за часів незалежності:

• ЕСПД 19.ххх – Єдина система програмної документації (діють до 01.01.2019р., http://csm.kiev.ua);
• ГОСТ 34.ххх – Нормативні вимоги до автоматизованих систем (частково діють до 01.01.2019р.).

Єдина система програмної документації (ЄСПД) – комплекс стандартів, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм і програмної документації.

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

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

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

Перелік найбільш вживаних документів, що входять до ЄСПД наведений у табл. 4.3., назви подані на мові оригіналу. У сиску виділені стандарти, які розглдаються в даному курсі.

 

Таблиця6.3   – Перелік стандартів ЄСПД, які найчастіше вживаються у програмній інженерії (діють до 01.01.2019р, http://csm.kiev.ua)

Позначення	Назва
ГОСТ 19.001-77	Общие положения
ГОСТ 19.002-80	Схемы алгоритмов и программ. Правила выполнения
ГОСТ 19.004-80	Термины и определения
ГОСТ 19.005-85	Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения
ГОСТ 19.101-77	Виды программ и программных документов
ГОСТ 19.102-77	Стадии разработки
ГОСТ 19.103-77	Обозначение программ и программных документов
ГОСТ 19 105-78	Общие требования к программным документам
ГОСТ 19.106-78	Требования к программным документам, выполненным печатным способом
ГОСТ 19.201-78	Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.202-78	Спецификация. Требования к содержанию и оформлению
ГОСТ 19.301-79	Программа и методика испытаний. Требования к содержанию и оформлению
ГОСТ 19.401-78	Текст программы. Требования к содержанию и оформлению
ГОСТ 19.402-78	Описание программы
ГОСТ 19.404-79	Пояснительная записка. Требования к содержанию и оформлению
ГОСТ 19.502-78	Описание применения. Требования к содержанию и оформлению
ГОСТ 19.503-79	Руководство системного программиста. Требования к содержанию и оформлению
ГОСТ 19.504-79	Руководство программиста. Требования к содержанию и оформлению
ГОСТ 19.505-79	Руководство оператора. Требования к содержанию и оформлению
ГОСТ 19.507-79	Ведомость эксплуатационных документов

 

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

На цей час для формування технічного завдання на створення ПЗ використовуються два стандарти(діють в Україні до 01.01.2019р.):

• ГОСТ 19.201-78 - Техническое задание, требования к содержанию и оформлению;
• ГОСТ 34.602-89 - Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Техническое задание на создание автоматизированной системы.

Відповідно до ГОСТ 19.201-78 технічне завдання повинне складатись із таких розділів:

• Вступ;
• Підстави для розробки;
• Призначення розробки;
• Вимоги до програми;
• Вимоги до програмної документації;
• Техніко-економічні показники;
• Стадії та етапи розробки;
• Порядок контролю та приймання;
• Додатки.

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

Кожна програма, орієнтована на тривалий ЖЦ та розвиток функціоналу, повинна супроводжуватись такими документами:

• Керівництво системного програміста (керівництво з інсталяції) – порядок інсталяції, перевірки правильності роботи  та методи внесення змін до ПЗ;
• Керівництво оператора (користувача) – повна інформація про користування системою.

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

• Керівництво програміста (Software Development Kit) – повна інформація про внутрішню організацію програми.

6.4.2                    Модель зрілості технологічних процесів організації (Capability Maturity Model)

Говорячи про стандартизацію процесів потрібно розглянути модель зрілості технологічних процесів організації Capability Maturity Model (CMM) [28], розроблену Інститутом інженерів програмного забезпечення (Software Engineering Institute, SEI) та корпорацією Mitre під керівництвом Уоттса Хамфри (Watts Humphrey), яка переросла в державний стандарт, який використовують США для визначення підрядника, здатного виконати замовлення.

Методологія CMM розроблялася й розвивалася в США як засіб, що дозволяє вибирати кращих виробників ПЗ для виконання держзамовлень у першу чергу міністерства оборони. Для цього були розроблені критерії оцінки зрілості ключових процесів компанії та визначений набір дій, необхідних для їхнього подальшого вдосконалювання. У підсумку методологія виявилася надзвичайно корисною для більшості компаній, що прагнуть якісно поліпшити існуючі процеси проектування, розроблення, тестування програмних засобів і звести керування ними до зрозумілих і легко реалізованих алгоритмів і технологій, описаних у єдиному стандарті. У подальшому ця модель переросла у методологію підвищення якості процесів підприємства Capability Maturity Model Integration (CMMI). Застосування CMMI дозволяє поставити розроблення ПЗ на промислову основу, підвищити керованість ключових процесів і виробничу культуру в цілому, гарантувати якісну роботу й виконання проектів у строк.

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

Для оцінки ступеня готовності підприємства розробляти якісний програмний продукт СММ використовує ключове поняттязрілість організації (Maturity). Незрілою вважається організація, у якій:

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

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

Основні ознаки зрілої організації:

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

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

Кожний із рівнів, крім першого, складається з декількох ключових областей процесу (Key Process Area), що містять цілі (Goal), зобов'язання щодо виконання (Commitment to Perform), можливість виконання (Ability to Perform), виконувані дії (Activity Performed), їхній вимір і аналіз (Measurement and Analysis) та перевірку впровадження (Verifying Implementation). Таким чином, СММ фактично є комплексом вимог до ключових параметрів ефективного стандартного процесу розроблення ПЗ та засобом його постійного поліпшення. Виконання цих вимог збільшує ймовірність досягнення підприємством поставлених цілей у сфері якості.

Початковий рівень (Initial Level – Level 1).

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

Ключові області процесу цього рівня не зафіксовані.

Повторюваний рівень (Repeatable Level – Level 2).

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

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

Ключові області процесу розроблення ПЗ цього рівня наведені на рис.4.2.

Визначений рівень (Defined Level – Level 3).

Рівень характеризується деталізованим методологічним підходом до керування (описані й закріплені у документованій політиці типові дії, необхідні для багаторазового повторення: ролі й відповідальність учасників, стандартні процедури й операції, порядок дій, кількісні показники й метрики процесів, формати документів та ін.).

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

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

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

Ключові області процесу розроблення ПЗ цього рівня наведені на рис.4.2.

Керований рівень (Managed Level – Level 4).

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

Ключові області процесу розроблення ПЗ цього рівня  наведені на рис.4.3.

Рівень оптимізації (Optimizing Level – Level 5).

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

Ключові області процесу розроблення ПЗ цього рівня наведені на рис.4.3.

СММ визначає такий мінімальний набір вимог: реалізувати 18 ключових областей процесу розроблення ПЗ, що містять 52 цілі, 28 зобов'язань компанії, 70 можливостей виконання (гарантій компанії) і 150 ключових практик.

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

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

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

6.5                    Методології програмування, що вплинули на галузеві стандарти

Галузеві стандарти частково закріплюють найчастіше використовувані методології розроблення ПЗ. Найбільш впливовими середних можна назвати наступні:

• Rational Unified Process (RUP), що пропонує ітеративну модель розроблення, що включає чотири фази: початок, дослідження, побудову та впровадження [33]. Проходження через чотири основні фази називається циклом розроблення, кожен цикл завершується генерацією працездатної версії системи. У ході супроводу продукт продовжує розвиватися і знову проходить ті самі фази. Розроблення ПЗ на базі RUP базується на створенні та супроводі моделей на базі UML.
• Microsoft Solution Framework (MSF) – методологія, що розроблялася для підвищення керованості процесів розроблення окремого підприємства (Microsoft), а потім стала застосовуватися розробниками, які використовують продукти Microsoft.  Методологія, подібна до RUP, також включає чотири фази: аналіз, проектування, розроблення, стабілізацію, є ітераційною, припускає використання об'єктно-орієнтованого моделювання. MSF порівняно з RUP здебільшого орієнтована на розроблення бізнес-додатків [34].
• eXtreme Programming (XP) – методологія, що приділяє основну увагу ефективній комунікації між замовником і виконавцем упроовж усього проекту з розроблення ІС для відслідковування зміни вимог [19]. В основу підходу покладена командна робота та постійне тестування прототипів.
• Гнучке розроблення ПЗ (Agile) – клас методологій розроблення програмного забезпечення на основі ітеративної моделі ЖЦ, в якій вимоги та рішення еволюціонують через співпрацю між самоорганізовуваними командами [35].