🗊Презентация Етапи розроблення програмного забезпечення

Лекція 3.2. Етапи розроблення програмного забезпечення Лекція 3.2. Етапи розроблення програмного забезпечення Відомо, що технологічний цикл конструювання ПЗ містить три процеси: 1) аналіз; 2) синтез; 3) супроводження. Протягом аналізу виявляються цілі створюваної системи, тобто вказуються функції та зміни стану системи залежно від оточення та керованих параметрів. У процесі синтезу вказуються способи реалізації запропонованих на першому етапі функцій системи, тобто виконується програмна реалізація системи. Виокремлюють три етапи синтезу: 1) проектування ПЗ; 2) кодування ПЗ; 3) тестування ПЗ (рис. 3.4).

Етап проектування доповнює вимоги до ПЗ, які подані моделями аналізу: інформаційною, функціональною моделями та моделлю поведінки. Інформаційна модель описує інформацію, яку, за задумом, має обробляти ПЗ. Функціональна модель визначає перелік функцій оброблення. Модель поведінки фіксує бажану динаміку системи (режими її роботи). На виході з етапу проектування виконується розроблення даних, архітектури та процедурне розроблення ПЗ. Етап проектування доповнює вимоги до ПЗ, які подані моделями аналізу: інформаційною, функціональною моделями та моделлю поведінки. Інформаційна модель описує інформацію, яку, за задумом, має обробляти ПЗ. Функціональна модель визначає перелік функцій оброблення. Модель поведінки фіксує бажану динаміку системи (режими її роботи). На виході з етапу проектування виконується розроблення даних, архітектури та процедурне розроблення ПЗ. Розроблення даних – це результат перетворення інформаційної моделі аналізу в структури даних для реалізації програмної системи. Розроблення архітектури – виокремлення основних структурних компонентів та фіксація зв’язків між ними. Процедурне розроблення – опис послідовності дій у структурних компонентах, тобто визначення їх умісту.

Далі створюють тести програмних модулів, виконують тестування та перевірку системи програмування. На проектування, кодування і тестування відводиться 75 % вартості конструювання системи програмування. Далі створюють тести програмних модулів, виконують тестування та перевірку системи програмування. На проектування, кодування і тестування відводиться 75 % вартості конструювання системи програмування. Рішення, які приймаються протягом проектування, роблять цей процес провідним етапом процесу синтезу. Важливість проектування визначається ще і якістю. Проектування – етап, на якому «вирощують» якість розроблення системи програмування, це єдиний шлях, який забезпечує правильну трансляцію вимог замовника в кінцевий програмний продукт. 3.1.7. Розроблення програмних модулів Методології розроблення ПЗ корисні для розроблення великих складних продуктів або розподілених інформаційних систем.

Розробляючи відносно невеликі програми або реалізуючи конкретний програмний модуль, достатньо притримуватися такої послідовності кроків: Розробляючи відносно невеликі програми або реалізуючи конкретний програмний модуль, достатньо притримуватися такої послідовності кроків: 1. Постановка завдання. 2. Обґрунтований вибір засобів розроблення (програмування). 3. Вибір методу розв’язання завдання. 4. Розроблення алгоритму рішення завдання. 5. Кодування засобами обраної мови програмування. 6. Верифікація й перевірка коректності. 7. Тестування програми. 8. Налагодження програми у випадку виявлення помилок. 9. Розроблення документації. 10. Експериментальна експлуатація. 11. Промислова експлуатація.

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

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

На сьогодні діють такі стандарти, які регламентують процес розроблення ПЗ: На сьогодні діють такі стандарти, які регламентують процес розроблення ПЗ: • ГОСТ 34.601-90 [7] – державний стандарт, що поширюється на автоматизовані системи і встановлює стадії та етапи їх 62 створення. У стандарті міститься опис змісту робіт на кожному етапі. • ISO/IEC 12207. Systems and software engineering – Software Life Cycle Processes [3] – міжнародний стандарт на процеси розроблення та організацію життєвого циклу ПЗ. Поширюється на всі види замовленого ПЗ. Стандарт не містить опису фаз, стадій та етапів. • Guide to the Software Engineering Body of Knowledge (SWEBOK) [25] – Керівництво до зведення знань з програмної інженерії – галузевий стандарт Інституту інженерів з радіоелектроніки та електротехніки (IEEE), що систематизує основні види діяльності з програмної інженерії.

Міжнародні стандарти ISO Міжнародні стандарти ISO Базовим стандартом розроблення ПЗ є ISO 12207. Systems and software engineering – Software Life Cycle Processes, в якому усі процеси ЖЦ ПЗ розподілені на три групи (рис. 3.5). Рисунок 3.5 – Процеси ЖЦ ІС відповідно до стандарту 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.6). У 2002 р. був опублікований стандарт на процеси життєвого циклу систем ISO/IEC 15288 Systems and software engineering - System life cycle processes [26], у розробленні якого брали участь фахівці різних галузей: системної інженерії, програмування, управління якістю, людськими ресурсами, безпекою та ін. Даний документ враховує практичний досвід створення систем в урядових, комерційних, військових та академічних організаціях і може бути застосований для широкого класу систем, але його основне призначення – підтримка створення комп'ютеризованих систем. На цей час діє версія стандарту 2008 р. У стандарті ISO/IEC 15288:2008 у структурі ЖЦ виділені групи процесів за видами діяльності (рис. 3.6).

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

Також потрібно відмітити, що у процесі промисло-вого розроблення ПЗ обов’язково використовуються стандарти якості серії ISO 9000. Серія ISO 9000 (управлі-ння якістю) містить у собі такі стандарти: Також потрібно відмітити, що у процесі промисло-вого розроблення ПЗ обов’язково використовуються стандарти якості серії ISO 9000. Серія ISO 9000 (управлі-ння якістю) містить у собі такі стандарти: • 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 задає модель системи якості для процесів проектування, розробле-ння, виробництва, установки й обслуговування (продук-ту, системи, послуги).

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

Керівництво до зведення знань із програмної інженерії (SWEBOK, 2004) містить опис 10 галузей знань: Керівництво до зведення знань із програмної інженерії (SWEBOK, 2004) містить опис 10 галузей знань: •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 – якість ПЗ. Для кожної галузі SWEBOK містить опис ключових елементів у вигляді підобластей (subareas). Для кожної підобласті наведена декомпозиція у вигляді списку тем (topics) із їх описом.

Стандарт зрілості компанії-розробника ПЗ CMM Стандарт зрілості компанії-розробника ПЗ CMM Говорячи про стандартизацію процесів підприємс-тва потрібно розглянути модель зрілості технологічних процесів організації Capability Maturity Model (CMM), розроблену Інститутом інженерів ПЗ (Software Enginee-ring Institute, SEI) та корпорацією Mitre під керівництвом Уоттса Хамфри (Watts Humphrey). Методологія CMM розроблялася й розвивалася в США як засіб, що дозволяє вибирати кращих виробни-ків ПЗ для виконання держзамовлень у першу чергу мі-ністерства оборони. Для цього були розроблені крите-рії оцінки зрілості ключових процесів компанії та визна-чений набір дій, необхідних для їхнього подальшого вдо-сконалювання. У підсумку методологія виявилася над-звичайно корисною для більшості компаній, що праг-нуть якісно поліпшити існуючі процеси проектування, розроблення, тестування програмних засобів і звести керування ними до зрозумілих і легко реалізованих алгоритмів і технологій, описаних у єдиному стандарті.

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

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

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

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

Рисунок 3.7 – Рівні зрілості компанії за СММ

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

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

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