Презентация Стандартизація та сертифікація інформаційних управляючих систем онлайн

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: ЖЦ ПЗ визначений стандартом ISO/IEC 12207:1995 – Information Technology – Software life cycle processes. ЖЦ ПЗ визначений стандартом ISO/IEC 12207:1995 – Information Technology – Software life cycle processes. Процеси ЖЦ діляться на 3 групи: головні; допоміжні; організаційні. Головні процеси: процес покупки (ініціація ЖЦ ПС і визначення організації, що ініціює розробку/покупку); процес розробки (дії організації розробника (ОР) – визначення та аналіз вимог, проектування ПС, реалізація ПС, тестування); процес постачання (передача ПС покупцеві); процес експлуатації; процес супроводження (керування модифікаціями ПС та інсталяція нових версій). Допоміжні процеси – процеси, які забезпечують якість ПС (шляхом приведення ПС у відповідність до вимог та рекомендацій стандартів). Організаційні процеси: менеджмент розробки; навчання персоналу; визначення обов’язків учасників процесів ЖЦ. Якість ПС – це сукупність властивостей ПС, які забезпечують її здатність задовольняти вимоги замовників та користувачів.

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: Після визначення всіх елементів моделі (1) можна перейти до випробувань, в ході яких обчислюються фактичні значення атрибутів підхарактеристик якості. Ці значення порівнюються із обмеженнями, заданими у вимогах. Після визначення всіх елементів моделі (1) можна перейти до випробувань, в ході яких обчислюються фактичні значення атрибутів підхарактеристик якості. Ці значення порівнюються із обмеженнями, заданими у вимогах. Якщо отримані фактичні значення показників якості відповідають вимогам, то подальшу оцінку можна провести, використовуючи інтегральний показник якості. Інтегральний показник якості (2) можна застосувати для вибору кращого ПЗ із декількох конкуруючих в даній області (галузі), при умові узгодження конфліктуючих атрибутів якості (у формулі (2) Qijk – відносний показник якості k-го атрибута, j-ї підхарактеристики i-ї характеристики моделі якості). Але, оскільки в моделі є показники з різними метриками (неперервні числові, бальні, номінальні та інші), необхідно попередньо провести узгодження та нормування метрик, що роблять шляхом уведення шкал для якісних та категорійних критеріїв і заданням вагових множників. Таким чином, враховуючи (1), інтегральний (узагальнений) рівень якості ПС Uq можна обчислити як середньозважений показник по формулі (2). Необхідно провести узгодження конфліктуючих атрибутів якості. Необхідно провести нормування метрик атрибутів якості.

Содержание слайда:

Содержание слайда:

Содержание слайда: Приклад для ПрО “Діяльність поліклініки” Приклад для ПрО “Діяльність поліклініки” Інтервали значення для метрики Fault density визначаємо на основі припущення, що максимальним допустимим значенням є 1 помилка на 100 рядків коду. Кількість в 100 рядків визначена на основі середнього розміру методу класу в вихідному коді ПС. Значення метрики Available co-existence оцінюємо, припускаючи, що максимальною допустимою кількістю помилок при використанні стороннього ПЗ може бути 1 помилка за всю тривалість робочого дня (8 годин). В кращому випадку можна розраховувати на 1 помилку за робочий тиждень(5 робочих днів). Метрику Help frequency унормовуємо виходячи з припущення, що в оптимальному випадку для використання невідомої функції системи користувачу достатньо 2 звернень до довідки, для ознайомлення та перевірки результатів, а відповідно трьохкратне перевищення даного значення є неприпустимим (6–“2”, 5 –“3”,4 –“3”,3 –“4”, 2–“5”). Відносний показник якості визначається зі співвідношення

Содержание слайда: - 2.Надійність. 2.1. Завершеність. - 2.Надійність. 2.1. Завершеність. - Fault density

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: M= n2*/6, (5.12) M= n2*/6, (5.12) де n2* – загальна кількість вхідних і вихідних змінних у програмі. З рівняння роботи отримаємо таке рівняння помилок: B=LE / E0, (5.13) де В – кількість помилок у програмі, Е0 – середня кількість елементарних відмінностей між помилками програмування. Використовуючи перетворене рівняння роботи: Е= (V*)3 / 2, (5.14) а також значення рівня англійської мови (=2,16), як аналог мови програмування, і гіпотезу про «шість об'єктів» ідеальної за витратами пам'яті програми (n1=n1*=2, n2=n2*=6), Холстед вивів таке рівняння для прогнозу кількості помилок у програмі: B= Е 2/3 /3000, (5.15) або B= V / 3000, (5.16) де V – обсяг програми (5.4). Якщо розрахунки довжини програми і довжини реалізації відрізняються більш ніж на десять відсотків, то це свідчить про можливу наявність у програмі таких 6 класів недосконалостей: 1). Наявність послідовності операторів, що доповнюють один одного до того ж самого операнда, наприклад, А+C–А. 2). Наявність неоднозначних операндів, наприклад, A=D і A=С. 3). Наявність операндів-синонімів, наприклад, А=В и Т=В. 4). Наявність загальних підвиразів: (А+B)C + D(А+B). 5). Непотрібне присвоювання, наприклад C=А+B, якщо змінна C використовується в програмі тільки один раз. 6). Наявність виразів, що не подані в згорнутому вигляді як добуток множників, наприклад XX+2XY+YY не подається як (X+Y)(X+Y). Добуток рівня програми на обсяг є постійною величиною, що дорівнює потенційному обсягу реалізації даного алгоритму: LV = V* = const. Якщо мова не змінюється, а змінюється тільки алгоритм, то для будь-якої мови добуток потенційного обсягу на рівень програми залишається сталою величиною і дорівнює рівню мови: LV* =  = const.

Содержание слайда:

Содержание слайда: Метрика Маккейба Метрика Маккейба Метрика Маккейба ґрунтується на аналізі потоку передавання керування від одного оператора до іншого. Це дозволяє, на відміну від метрик Холстеда, врахувати логіку програми при оцінюванні її складності. Програма (алгоритм, специфікація) має бути подана у вигляді управляючого орієнтованого графу G = (V, Е) із V вершинами і E дугами, де вершини відповідають операторам, а дуги – переходам від одного оператора до іншого. Граф, що описує програму у вигляді вершин-операторів і дуг-переходів, називають графом керування або управляючим графом програми. Приклад. main() { int zeich = 'x'; while(zeich != '#') { printf(" Продовжити введення "); zeich = getchar(); } printf("Введення завершене "); }

Содержание слайда: Метрика Маккейба є цикломатичним числом графу передач керування програми і визначається виразом: M = m – n + 2 , (5.17) де m – кількість ребер графу; n – кількість вершин графу. Величину М, розраховану за формулою (5.17), називають цикломатичним числом Маккейба. Теоретичною базою визначення цикломатичного числа Маккейба є теорія графів. У теорії графів цикломатичне число орієнтованого графа визначається виразом: M = m – n + 2p (5.18) де m – кількість ребер; n – кількість вершин; p – кількість компонентів зв'язності графу. Кількість компонентів зв'язності p можна розглядати як мінімально необхідну кількість ребер, які потрібно додати до графу, щоб зробити його повнозв'язним. Повнозв'язним вважають граф, у якого існує шлях з будь-якої вершини графу в будь-яку іншу вершину графу. Для графів керування програм повнозв'язність забезпечується додаванням однієї фіктивної дуги з кінцевої вершини в початкову, тобто у розглядуваному прикладі із вершини u у вершину v. Тому вважаємо, що для будь-якого графу керування програми кількість компонентів зв'язності дорівнює одиниці. Підстановка p=1 у формулу (5.18) дає цикломатичне число Маккейба (5.17). Визначимо цикломатичне число Маккейба для графу керування програми, зображеного на рисунку. Кількість ребер графу дорівнює п'яти, кількість вершин теж дорівнює п'яти, тому цикломатичне число дорівнює: M = 5 – 5 + 2 = 2. Фізичний зміст цикломатического числа. Контур – це площина, обмежена циклічним шляхом, у якій початкова і кінцева вершина графу збігаються. Кожному контуру відповідає шлях, що обмежує його, який веде з початкової вершини графа в кінцеву. Цикломатичне число визначає кількість незалежних контурів у повнозв'язному графі і, як наслідок, кількість різних шляхів, що ведуть з початкової вершини в кінцеву. У практичному аспекті цикломатичне число є мірою складності програми і визначає кількість тестів, достатніх для тестування за критерієм покриття всіх гілок програми.

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: Міжнародні стандарти в області інформаційних технологій (IT) розробляються об’єднаним технічним комітетом JTC1 (Joint Тechnical Committee №1) “Information Technology”, заснованим ISO та IEC. Він включає 36 підкомітетів SC (SubCommittie), а за розробку міжнародних стандартів по програмній інженерії (Software Engineering – SE) відповідає робочий підкомітет ISO/IEC SC7 “Software and System Engineering”. Для роботи над проектами стандартів у підкомітеті SC7 створені робочі групи (WG, Working Group). Базовими стандартами по керуванню якістю продукту і системах управління якістю ОР є міжнародні стандарти серії ISO 9000. Стандарт ISO 9000-3 регламентує управління якістю під час розробки, поставки та супроводу ПЗ. Базові стандарти по керуванню якістю ПЗ ДСТУ ISO 9000-3 – Стандарти з управління якістю та забезпечення якості. Частина 3. Настанови щодо застосування ДСТУ ISO 9001-95 під час розроблення, постачання та супроводження програмних засобів. Основні діючі стандарти в області інженерії якості ДСТУ ISO 9000-2001. Системи управління якістю. Основні положення та словник. ДСТУ ISO 9001-2001. Системи управління якістю. Вимоги. ДСТУ ISO 9004-2001. Системи управління якістю. Настанови щодо поліпшення діяльності. ГОСТ 34.602-89. Информационная технология – Комплекс стандартов на АС. Техническое задание на создание автоматизированой системы. ГОСТ РФ 28195-89. Оценка качества программных средств. Общие положения.

Содержание слайда:

Содержание слайда: Група стандартів SPICE - Software Process Improvement and Capability dEtermination – WG10 “Оцінювання процесу” – “Process Assessment” ДСТУ ISO/IEC 15504-1:2002. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 1. Концепції та вступна настанова. ДСТУ ISO/IEC 15504-2:2002. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 2. Еталонна модель процесів та потужності процесу. ДСТУ ISO/IEC 15504-3:2002. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 3. Виконання оцінювання. ДСТУ ISO/IEC 15504-4:2002. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 4. Настанови з виконання оцінювання. ДСТУ ISO/IEC 15504-5:2002. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 5. Модель оцінювання та настанови щодо показників. ДСТУ ISO/IEC 15504-6:2003. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 6. Настанови з визначення компетенції оцінювачів. ДСТУ ISO/IEC 15504-7:2003. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 7. Настанови з удосконалення процесу. ДСТУ ISO/IEC 15504-8:2003. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 8. Настанови з визначання потужності процесу постачальника. ДСТУ ISO/IEC 15504-9:2003. Інформаційні технології – Оцінювання процесів життєвого циклу програмних засобів. Частина 9. Словник термінів.

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: