|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Кількісна оцінка якості ПЗПорівнювати якість програмних продуктів "на пальцях" не занадто зручно, тому доцільність застосування кількісних методів оцінки якості (метрик) очевидна. Дітер Ромбах (Dieter Rombach), співробітник американської організації Software Engineering Laboratory (SEL), у 1991 р. на паризькій конференції з питань комп'ютерних обчислень Euromantics заявив: "Ми більше не повинні задаватися питанням, потрібні чи комп'ютерні метрики. Проблема полягає в тому, як їх будувати". Історія програмних метрик нараховує чверть століття, а почалася вона з того моменту, коли вартість комерційних продуктів стала зростати і знадобилися наукові методи створення стандартів і аналізу процесів розробки ПО. Програмування з мистецтва поступово перетворювалося в інженерну дисципліну. Введення суворих кількісних метрик у програмування повинно було сприяти вирішенню ряду практичних задач: · прогнозувати ймовірне число помилок у системі від початку проектування; · на основі аналізу фази проектування системи пророкувати рівень складності наступного супроводу; · на основі аналізу вихідного коду програм прогнозувати рівень складності процесів тестування і відсоток помилок, що залишаються; · за оцінками складності фази проектування системи визначати кінцевий розмір коду; · визначати кореляцію окремих характеристик програмного коду з якістю готової системи; · контролювати стадії розвитку проекту; · аналізувати явні і приховані дефекти; · на основі експериментального порівняння виявляти кращі методи і технології. Із зростанням актуальності програмних метрик стали з'являтися різні "вимірювальні" програми. Одні з них досліджували характеристики проектів і ПЗ комплексно, інші орієнтувалися на цілком конкретні цілі: аналіз вихідного коду, розмірів і структури окремих модулів і т.д. Наприклад, відома програма Metricate виробництва Software Productivity Centre зондує практично всі аспекти діяльності софтверних компаній: ефективність технологічних процесів, якість програмного коду, рівень управління проектами, вартість виконання різних етапів, продуктивність одержуваної системи, продуктивність праці розроблювачів і якість готових виробів. Незважаючи на численні дослідження програмних метрик (біля 5 тис. статей), у цій області як і раніше залишається багато невирішених питань. По-перше, технологія виміру якості ще не досягла зрілості. По-друге, відсутні єдині стандарти на метрики. Найпопулярніший стандарт, що відноситься до виробництва надійного ПЗ (Standard Dictionary of Measures to Product Reliable Software інституту IEEE), так і не став загальноприйнятим. У результаті кожен постачальник "вимірювальної" системи пропонує свої власні способи оцінки якості і відповідно метрики. На сьогоднішній день відомо більш тисячі видів метрик. Проте теорія і практика програмних метрик продовжують розвиватися і є надія, що консенсус у цій області усе ж буде досягнутий. Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.002 сек.) |