Кейб представив циклічне число як мінімальна кількість колій у графі потоку управління (flowgraph). Він обоснавать, що мінімальне число шляхів визначає складність програми (циклічну складність (cyclomatic complexity)):
Загальна стратегія - виміряти складність програми підрахунком числа лінійно незалежних шляхів v (G), контролюючи розмір програми шляхом встановлення верхньої межі для v (G) і використовувати циклічну складність, як основу для перевіряючої методології.
Модель вимірювань Халстеда заснована на вихідному коді програм. Халстед показав, що час витрачається програмою може бути виражене як функція від числа операндів і операторів. Модель Халстеда використовується такими організаціями як IBM, General Electrics і General Motors Corporation. Найбільш використовувані заходи Халстеда сьогодні -
міра довжини, обсягу та складності. p> У 1979 Албрехт (Albrecht) запропонував метод показника функціональності (function point method), з метою розробки механізму передбачення зусиль, сполучених з розробкою програмних систем. Метод був вперше опублікований в 1979 році. У 1984 році Альбрехт удосконалив свій метод і з 1986 року, в якому була сформована Міжнародна Асоціація користувачів показників функціональностей (International Function Point User Group - IFPUG), було опубліковано кілька ревізій методу. p> Чарльз Саймон (Charles Symon) розробив інший, аналогічний, але трохи більш логічний і використовує більш сучасну термінологію, метод показника функціональності Mark II. На відміну від FPA IFPUG, MK II FPA використовує єдине поняття транзакції, що має вхід, обробку та вихід. MK II FPA прийнятий в якості національного стандарту Великобританії. p> Ймовірно, одним з найбільш відомих моделей даного роду є конструктивна модель вартості (Constructive Cost Model - COCOMO), розроблена наприкінці 70х років Баррі Боем, побудована на основі аналізу низки проектів, виконаних в основному в інтересах Міністерства Оборони США, вона встановлює відповідність між розміром системи в тисячах умовних рядків коду і класом проекту, з одного боку, і трудомісткістю розробки системи, з іншого боку. br/>
.3 Навіщо потрібні моделі і методи оцінки витрат на розробку програмного забезпечення?
Кожен, хто брав участь у проектах з розробки інформаційних систем, стикався з проектами, що не завершувалися в строк, перевищували бюджету або були здані з недостатньою функціональністю для того, щоб системою можна було користуватися. Основними джерелами цих сумних результатів є: погане управління проектом, що пливуть вимоги, неправильна оцінка проекту
Ми зосередимося на двох останніх проблемах, що зводяться до адекватної оцінки вартості проекту. Адекватна оцінка вартості проекту важлива як для замовника, так і для виконавця проекту. p> Що пливуть вимоги виникали і будуть виникати завжди, оскільки програмний продукт повинен відповідати потребам замовника. Причини зміни вимог досить зрозумілі: поступове розуміння клієнтом того...
