Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

гарну роботуна сайт">

Студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будуть вам дуже вдячні.

Розміщено на http://www.allbest.ru/

Моделі Cocomo, Cocomo II, метод функціональних точок. Їх порівняльний аналізта область застосування

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

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

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

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

Для прогнозування та планування будь-яких процесів або характеристик об'єктів (зокрема програмних засобів) використовуються вихідні дані двох типів:

· Функції та номенклатура характеристик самого прогнозованого об'єкта або процесу, для якого необхідно спланувати життєвий цикл;

· Характеристики прототипів і пілотних проектів, певною мірою, подібних до планованого об'єкта, про які відомі реалізовані плани та необхідні економічні характеристики вже завершених аналогічних процесів їх створення.

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

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

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

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

· Недосконалість вихідних даних при оцінюванні техніко-економічних показників спонукає керівника проекту переглядати оцінки, враховуючи нову інформаціющоб забезпечити більш реальну основу для подальшого управління проектом;

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

· Програмні проекти мають тенденцію до зміни характеристик та економічних факторів і керівнику проекту необхідно ідентифікувати ці зміни та виконувати реалістичне оновлення оцінок витрат.

Основними ресурсами у розробників під час створення складних комплексів програм є:

· Допустимі трудовитрати (вартість) на розробку ПЗ з необхідною якістю;

· Час - тривалість повного циклу створення програмного продукту;

· Необхідна та доступна кількість фахівців відповідної кваліфікації.

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

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

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

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

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

Недостатньо достовірні оцінки спричиняють проблеми взаємодії розробника із замовником та збільшують ступінь ризику проекту.

Оцінювання розміру ПЗ

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

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

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

В даний час при оцінці розміру ПЗ найчастіше користуються двома основними одиницями виміру - рядками програмного коду (Lines of code, LOC) та функціональними точками.

В якості одиниць вимірювання також можна використовувати точки властивостей, кількість жирних точок на діаграмі потоку даних (Data flow diagram, DFD), кількість сутностей на діаграмі сутностей, обсяг документації, кількість об'єктів, атрибутів і служб на об'єктній діаграмі. Незалежно від того, чи кінцевий продукт оцінюється, як у випадку використання LOC, або його деяка абстракція або модель, оцінці піддається те, чого ще немає в природі. Тому оцінювання розмірів становить значні труднощі.

Використання LOC як одиниця виміру розміру програмного продукту

LOC оцінка є найбільш універсальну метрику, оскільки може використовуватися при створенні будь-яких програмних продуктів. Вона простіша і зрозуміліша як для фахівців, так і для замовників та інвесторів. Наприклад, якщо стверджується, що один компонент програмної системи, що складається з n компонентів, що в середньому вимагатиме написання близько 1000 рядків програмного коду, то кожен може прикинути її загальний розмірі хоча б приблизно оцінити трудовитрати, потрібні для її створення, виходячи з припущення, що середня продуктивність одного програміста, як і раніше, становить близько 3000 рядків коду на рік.

Однак багато експертів у галузі розробки програмного забезпечення стверджують, що це погана одиниця виміру. Найбільш суттєве питання, яке виникає при використанні LOC оцінок, полягає в тому, що ж являє собою один рядок програмного коду? Крім того, при використанні LOC як одиниця виміру виникають сумніви в достовірності результатів, оскільки не враховується таке:

· Число рядків вихідного кодузалежить від рівня майстерності програміста. Фактично, що вище майстерність програміста, то меншою кількістю рядків коду йому вдасться обійтися для реалізації певної функціональної можливості (або функціональності) ПС;

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

· Фактичне число LOC залишається невідомим доти, поки проект не буде майже завершений. Тому LOC не можна використовувати для попередньої оцінки зусиль на розробку та побудову плану-графіка проекту;

· У програмістському співтоваристві не досягнуто угоди про метод підрахунку рядків коду. Мовні конструкції, використовувані, наприклад, у Visual C++, Асемблері, Кобол або SQL, абсолютно різні. Метод залишається спільним для будь-яких додатків, у тому числі тих, що використовують комбінацію різних мов;

· Замовнику складно зрозуміти, яке співвідношення зазначених їм функціональних та нефункціональних (технічних) вимог до ПС та обсягів програмістської роботи.

У той самий час підвищення достовірності оцінок є кілька досить простих рекомендацій:

· Переконайтеся, що кожен рядок вихідного коду містить лише один оператор. Якщо в одному рядку містяться два оператори, що виконуються, розділених точкою з комою, то вони повинні враховуватися як два рядки. Якщо один оператор розбитий на кілька «фізичних» рядків, він враховуватиметься як один рядок. У мовах програмування допускаються різні правила кодування, але зазвичай простіше визначати у рядку один оператор, оброблюваний компілятором чи інтерпретатором.

· Враховуйте всі оператори, що виконуються. Кінцевий користувач може не мати можливості практично використовувати кожен оператор, але всі оператори повинні підтримуватись цим продуктом, у тому числі й утилітами.

· Визначення даних враховуйте лише один раз.

· Не враховуйте рядки, які містять коментарі.

· Не враховуйте налагоджувальний код або інший часовий код (пробне програмне забезпечення, засоби тестування тощо).

· Враховуйте кожну ініціалізацію, виклик або включення макросу (директиви компілятора) як частину вихідного коду, в якій здійснюється будь-яка дія. Не враховуйте оператори, які повторно використовуються.

Насправді при оцінці розміру великих програмних систем частіше користуються показником тисяч рядків вихідного коду KSLOC. Ця метрика найчастіше використовується при оцінках продуктивності, яка розраховується як KSLOC/SM, де SM – staff-month (людини-місяці).

Оцінка показника LOC за допомогою експертних оцінок та висхідного підсумовування.

Якщо припустити, що структура WBS для розроблюваного програмного засобу розбита на кілька рівнів декомпозиції, які дозволяють виділити фактичні компоненти програмної системи, а також дають підстави для подальшої деталізації, можливо створення деякого «статистичного» показника розміру, який може бути отриманий з використанням процесів вимірювання і підсумовування.

Величина розміру кожного компонента може бути отримана шляхом опитування експертів, які розробляли такі системи, або опитування потенційних розробників подібних систем. В результаті стає можливо оцінити розмір кожного блоку на нижньому рівніструктури WBS Після складання передбачуваних оцінок з'являється уявлення розмір програмної системи загалом. Такий спосіб називається оцінкою розміру «знизу – вгору».

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

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

Наприклад, якщо деякий об'єкт, відображений на структурі WBS, може займати від 200 до 400 рядків коду і швидше за все його розмір ближче до 200, то використовуючи запропонований підхід можна отримати наступну оцінку: (200+(250*4)+400)/6 = 266 LOC.

Оцінка кількості LOC за аналогією

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

Наприклад, ми маємо вже готовий модуль А, розмір якого становить 2345 LOC. Ми хочемо створити новий модуль, який багато в чому схожий з модулем А, але до нього будуть додані деякі додаткові властивості. Крім того, ми придумали як зробити програмний код компактнішим. В результаті цього розмір модуля А може бути оцінений в 3000 LOC.

Звичайно даний метод не є дуже точним, так як при написанні модуля А могли використовуватися різні мови програмування, застосовуватись алгоритми з різними рівнями складності, використовуватись різний обсяг моделювання (моделювання, емуляція, реальний додаток), але така оцінка таки має під собою якесь кількісне обґрунтування.

Переваги використання LOC як одиниця виміру

· Ці одиниці поширені і можуть адаптуватися.

· Вони дозволяють проводити зіставлення методів вимірювання розміру та продуктивності в різних групахрозробників.

· Безпосередньо пов'язані з кінцевим продуктом.

· Одиниці LOC можуть бути оцінені ще до завершення проекту.

· Оцінка розмірів ПЗ проводиться з урахуванням точки зору розробників.

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

· Знання розміру програмного продукту в LOC - одиницях дозволяє застосовувати більшість існуючих методів оцінки техніко-економічних показників проекту (таких як трудовитрати, тривалість проекту, його вартість та ін.).

Недоліки, пов'язані із застосуванням LOC - оцінок

· Дані одиниці виміру складно застосовувати на ранніх стадіях життєвого циклу, коли високий рівень невизначеності.

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

· Застосування методів оцінки за допомогою рядків не регламентується промисловими стандартами, наприклад ISO.

· Розробка ПЗ може бути пов'язана з великими витратами, які безпосередньо не залежать від розмірів програмного коду. Це так звані фіксовані витрати, пов'язані з розробкою специфікації вимог, підготовкою документації користувача та ін., які не включені в прямі витрати на кодування.

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

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

· Показники LOC не можуть здійснюватись при нормалізації у разі, якщо використовувалися різні платформичи типи мов програмування.

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

· Генератори коду часто провокують надмірний його обсяг, що може призвести до значних похибок в оцінці розміру ПС.

Часто продуктивність праці програмістів оцінюється за кількістю вироблених рядків коду, але це завжди правильно. Якщо програміст замість 200 рядків на місяць напише 250, то це не означає, що він точно став краще працювати і заслуговує на заохочення. Правильніше було б враховувати як кількість написаного коду, а й його якість, що можна зробити з допомогою застосування наступної формулы:

Кількість дефектів / кількість рядків коду

Фаза кодування в більшості проектів займає від 7% до 20% трудовитрат, тому більш важливою є якість коду, а не його обсяг.

Використання функціональних точок як одиниці вимірювання розміру програм.

Першою і найбільш вдалою альтернативою методу підрахунку вихідних рядків коду стала розроблена в 1979 Алланом Альбрехтом з IBM методологія, названа «Аналіз показників функціональності» (FPA, від Function Points Analysis). В її основі лежить погляд на ПС ззовні, з позицій користувача системи, а не з боку її внутрішніх властивостей (таких, як LOC). В результаті аналізу вихідних вимогдо ПС та з'ясування реальних потребкористувачів визначається обсяг функціональних можливостейсистеми, показниками яких є функції обробки інформації настільки низького рівня, наскільки вони вкладаються у систему мислення користувачів, крім функцій - дані, які ці функції обробляють. Таким чином, методологія FPA базується на ідеї декомпозиції функцій та даних до максимально допустимого (з погляду користувача) рівня. Обсяг функціональних можливостей ПС (далі просто функціональний розмір) визначається так званих умовних одиницях функціональності FP - від Function Points.

Протягом п'яти років з моменту появи методологія FPA та метод розрахунку розміру відшліфовувалися А. Альбрехтом і проходили практичну апробацію, а в середині 80-х років була створена Міжнародна група користувачів показників функціональності (IFPUG, від International Function Points User Group), яка і підтримує подальшу еволюцію методу

Метод функціональних точок дозволяє вирішувати такі завдання:

· Вирішити проблему, пов'язану з труднощами отримання LOC - оцінок на ранніх стадіях життєвого циклу.

· Визначати кількість та складність вхідних та вихідних даних, їх структуру, а також зовнішні інтерфейси, пов'язані з програмною системою.

У методі функціональних точок використовується 5 інформаційних характеристик.

1. Кількість зовнішніх вводів. Підраховуються всі введення користувача, за якими надходять різні прикладні дані. Вводи мають бути відокремлені від запитів, які підраховуються окремо.

2. Кількість зовнішніх висновків. Підраховуються всі висновки, якими до користувача надходять результати, обчислені програмним додатком. У цьому контексті висновки означають звіти, екрани, роздруківки, повідомлення про помилки. Індивідуальні одиниці даних усередині звіту окремо не підраховуються.

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

4. Кількість внутрішніх логічних файлів. Підраховуються всі логічні файли (тобто логічні групи даних, які може бути частиною бази даних чи окремим файлом).

5. Кількість зовнішніх файлів. Підраховуються всі логічні файли з інших програм, на які посилається ця програма.

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

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

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

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

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

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

Для транзакцій ранжування ґрунтується на кількості посилань на файли та кількості типів елементів даних. Для файлів ранжування ґрунтується на кількості типів елементів-записів та типів елементів даних, що входять до файлу.

програмний трудомісткість життєвий цикл

Розміщено на Allbest.ru

...

Подібні документи

Доцільність застосування моделі життєвих циклів як інструмент управління змінами на підприємствах. Аналіз видів життєвих циклів, дослідження їхнього взаємозв'язку на відповідних рівнях управління економікою. Динаміка процесів змін.

контрольна робота , доданий 12.11.2008


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

презентація , додано 09.02.2015


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

курсова робота , доданий 28.12.2012


Життєвий цикл проекту та його фази. Оцінка стійкості проекту (ризиків та рівня беззбитковості). Чинники втрат часу під час його реалізації. Планування робіт із проекту створення більярдного клубу за 51 тиждень, із витратами трохи більше 3,5 млн. крб.

курсова робота , доданий 22.12.2011


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

презентація , доданий 28.11.2013


Поняття життєвого циклу організації, його різні моделіта основні етапи. Дії керівника різних стадіях розвитку організації, перспективні моделі її еволюції. Аналіз життєвих циклів, пройдених компанією з прикладу ТОВ " Лекрус Урал " .

курсова робота , доданий 28.02.2012


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

курсова робота , доданий 10.11.2010


Організація основного виробництва. Поняття та класифікація виробничих процесів. Технологічний ланцюжок виробництва виробів. Розрахунок тривалості виробничого циклу простого процесу. Шляхи скорочення тривалості виробничих циклів.

презентація , доданий 06.11.2012


Загальне поняттяпро життєвий цикл проекту. Основні процеси керування проектом. Аналіз життєвого циклу та процесів нафтогазового проекту на прикладі проекту діяльності ВАТ "ЛУКОЙЛ". Оцінка фази життєвого циклу проекту та рекомендації щодо управління ним.

курсова робота , доданий 13.01.2014


Організаційна структура управління проектом відкриття ресторану. Розбиття робіт із проекту. Матриця поділу адміністративних завдань управління. Визначення відносних показників внутрішньої трудомісткості. Порівняння трудомісткості та корисності.

Підрахунок функціональних точок, пов'язаних із транзакціями - це четвертий крок аналізу за методом функціональних точок.

Транзакція- це елементарний неподільний замкнутий процес, що представляє значення для користувача і продукт, що переводить з одного консистентного стану в інший.

У методі різняться наступні типитранзакцій (Таблиця 9):

• EI (external inputs) - зовнішні вхідні транзакції, елементарна операція з обробки даних або керуючої інформації, що надходять у систему з-за.
• EO (external outputs) – зовнішні вихідні транзакції, елементарна операція з генерації даних або керуючої інформації, що виходять за межі системи. Припускає певну логіку обробки чи обчислень інформації з одного або більше ILF.
• EQ (external inquiries) - зовнішні запити, елементарна операція, яка у відповідь зовнішній запит витягує дані або керуючу інформаціюз ILF чи EIF.

Таблиця 9. Основні відмінності між типами транзакцій. Легенда: Про - основна; Д – додаткова; NA - не застосовується.

Оцінка складності транзакції ґрунтується на наступних її характеристиках:

• FTR ( file type referenced) - дозволяє підрахувати кількість різних файлів(інформаційних об'єктів) типу ILF та/або EIF, що модифікуються або зчитуються в транзакції.
• DET (data element type) - унікальне унікальне поле даних. приклади. EI: поле введення, кнопка. EO: поле даних звіту, повідомлення про помилку. EQ: поле введення пошуку, поле виведення результату пошуку.

Для оцінки складності транзакцій служать матриці, які представлені в Таблиці 10 та Таблиці 11.

Таблиця 10. Матриця складності зовнішніх транзакцій вхідних (EI)

Оцінку транзакцій у не вирівняних функціональних точках (UFP) можна отримати з матриці (Таблиця 12)

Таблиця 12. Складність транзакцій у не вирівняних функціональних точках (UFP)

Як приклад розглянемо оцінку керуючої транзакції (EI) для діалогового вікна, що задає параметри перевірки орфографії в MS Office Outlook(Малюнок 40).

Рисунок 40. Діалогове вікно, що керує перевіркою орфографії у MS Office Outlook

Кожен "Check box" оцінюється як 1 DET. Список, що випадає - 1 DET. Кожна керуюча кнопкамає розглядатися як окрема транзакція. Наприклад, якщо оцінювати керуючу транзакцію за кнопкою «OK», то для даної транзакції ми маємо 1 FTR та 8 DET. Тому, згідно з матрицею (Таблиця 10), ми можемо оцінити складність транзакції, як Low. І, нарешті, у відповідність до матриці (Таблиця 12), дана транзакціямає бути оцінена у 3 не вирівняних функціональних точок (UFP).

Визначення сумарної кількості не вирівняних функціональних точок (UFP)

Загальний обсяг продукту в не вирівняних функціональних точках (UFP) визначається шляхом підсумовування інформаційним об'єктам(ILF, EIF) та елементарним операціям (транзакціям EI, EO, EQ).

Визначення значення фактора вирівнювання (FAV)

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

1. Обмін даними(0 - продукт являє собою автономний додаток; 5 - продукт обмінюється даними по більш ніж одному телекомунікаційному протоколу).

2. Розподілена обробка даних (0- продукт не переміщує дані; 5 – розподілена обробка даних виконується декількома компонентами системи).

3. Продуктивність (0- Користувацькі вимоги щодо продуктивності не встановлені; 5 - час відгуку дуже обмежено критично всім бізнес-операцій, задоволення вимогам необхідні спеціальні проектні рішеннята інструменти аналізу.

4. Обмеження з апаратних ресурсів (0- нема обмежень; 5 - продукт цілком повинен функціонувати певному процесорі і може бути розподілений).

- транзакцій небагато, без піків; 5 - число транзакцій велике і нерівномірне, потрібні спеціальні рішення та інструменти).

6. Інтенсивність взаємодії з користувачем (0- всі транзакції обробляються в пакетному режимі; 5 – понад 30% транзакцій – інтерактивні).

7. Ергономіка(Ефективність роботи кінцевих користувачів) (0 - немає спеціальних вимог; 5 - вимоги щодо ефективності дуже жорсткі).

8. Інтенсивність зміни даних(ILF) користувачами (0 - не потрібні; 5 - зміни інтенсивні, жорсткі вимоги щодо відновлення).

9. Складність обробки (0- Обробка мінімальна; 5 - вимоги безпеки, логічна та математична складність, багатопоточність).

10. Повторне використання(0 – не потрібно; 5 – продукт розробляється як стандартний багаторазовий компонент).

11. Зручність інсталяції (0- немає вимог; 5 - встановлення та оновлення ПЗ проводиться автоматично).

12. Зручність адміністрування(0 – не потрібно; 5 – система автоматично самовідновлюється).

13. Портованість(0 - продукт має лише 1 інсталяцію на єдиному процесорі; 5 - система є розподіленою і передбачає установку на різні «залізо» та ОС).

14. Гнучкість (0- не вимагається; 5 - гнучка системазапитів та побудова довільних звітів, модель даних змінюється користувачем у інтерактивному режимі).

14 системних параметрів(degree of influence, DI) оцінюються за шкалою від 0 до 5. Розрахунок сумарного ефекту 14 системних характеристик (total degree of influence, TDI) здійснюється простим підсумовуванням:

TDI = ∑DI

Розрахунок значення фактора вирівнювання провадиться за формулою

VAF = (TDI * 0.01) + 0.65

Наприклад, якщо кожен із 14 системних параметрів отримав оцінку 3, то їх сумарний ефект складе TDI = 3 * 14 = 42. У цьому випадку значення фактора вирівнювання буде: VAF = (42 * 0.01) + 0.65 = 1.07

Розрахунок кількості вирівняних функціональних точок (AFP)

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

AFP = UFP * VAF.

Вона враховує лише нову функціональність, що реалізується у продукті. Проект розробки продукту оцінюється в DFP (development functional point) за формулою:

DFP = (UFP + CFP) * VAF,

де CFP(conversion functional point) - функціональні точки, підраховані для додаткової функціональності, яка буде потрібна для встановлення продукту, наприклад, міграції даних.

Проект доопрацювання та вдосконалення продукту оцінюється в EFP (enhancement functional point) за формулою:

EFP = (ADD + CHGA + CFP) * VAFA + (DEL * VAFB),

• ADD- функціональні точки для доданої функціональності;
• CHGA- функціональні точки для змінених функцій, розраховані після модифікації;
• VAFA- величина фактора вирівнювання розрахованого після завершення проекту;
• DEL- Об'єм віддаленої функціональності;
• VAFB- величина фактора вирівнювання розрахованого на початок проекту.

Сумарний вплив процедури вирівнювання лежить у межах ±35% щодо обсягу розрахованого UFP.

Метод аналізу функціональних точок нічого не говорить про трудомісткість розробки оціненого продукту. Питання вирішується просто, якщо компанія розробник має власну статистику трудовитрат на реалізацію функціональних точок. Якщо такої статистики немає, то для оцінки трудомісткості та термінів проекту можна використати метод COCOMO II.

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

Інформаційні параметри визначаються так:

Число входів користувачів.Підраховується кожен вхід користувача, який дає від інших дані, орієнтовані на певний додаток. Входи мають відрізнятися від запитів користувачів, які підраховуються окремо.

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

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

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

Число зовнішніх інтерфейсів.Підраховуються всі інтерфейси машиночитання (наприклад, звернення до файлів даних на зовнішніх носіях, які використовуються для передачі інформації до інших систем).

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

Для остаточного підрахунку кількості функціональних точок, тобто заходи ФТ для всього програмного продукту, потрібно додатково врахувати 14 факторів, для яких встановлена ​​шкала вагових коефіцієнтів, що відображають ступінь впливу того чи іншого фактора під час функціонування програмного виробу. Шкала значень коефіцієнтів наступна:

Немає впливу – 0.

Випадковий вплив -1.

Помірний вплив – 2.

Середній вплив – 3.

Значний вплив – 4.

Істотний вплив – 5.

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

1. Чи вимагає система надійного резервування та подальшого відновлення після відмови?

2. Чи потрібна передача даних?

3. Чи є функції розподіленої обробки?

4. Чи критична продуктивність програмного продукту?

5. Чи функціонуватиме система в існуючій або в більш складній операційній обстановці?

6. Чи вимагає система онлайнового введення даних?

7. Чи потрібно онлайнове введення транзакцій, які б враховували можливість формування різних екранівстосовно багатьох операцій?

8. Чи здійснюється оновлення головного файлу в онлайновому режимі?

9. Чи є складними входи, виходи, файли чи запити?

10. Чи є складними алгоритмамиобробки даних

Вагові коефіцієнти наведені у табл.

Порядок розрахунку

1. Визначають параметри системи (входи/виходи)

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

3. Визначають загальний підсумок за всіма параметрами

4. Число ФТ визначають за формулою ФТ = загальний підсумок (0,65 + 0,01 суми коефіцієнтів)

ФТ можна використовуватиме визначення продуктивності праці, вартість розробки однієї точки, кількість сторінок документації однією точку тощо.

Цей метод використовується для вимірювання продуктивності замість застарілого лінійного підходу, де продуктивність вимірювалася кількістю рядків програмного коду. Вперше функціональні точки (function points) було запропоновано співробітником IBM Аланом Альбрехтом у 1979 р. .

Перевагою даного методує те, що оскільки застосування функціональних точок засноване на вивченні вимог, то оцінка необхідних трудовитрат може бути виконана на ранніх стадіях роботи над проектом. Для підтримки та розвитку даного методу у 1986 р. було створено Міжнародну групу користувачів функціонального виміру (IFPUG - International Function Point User Group).

Метод полягає у наступному.

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

Наступним кроком методу буде підрахунок кількості факторів, наведених нижче:

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

Далі отримані значення множаться на коефіцієнти складності для кожного фактора (за даними 1РР1Ю) та підсумовуються для отримання повного розміру програмного продукту. Значення цих коефіцієнтів наведено у табл. 9.1.

Таблиця 9.1.Значення коефіцієнтів складності

Для прикладу, що розглядається, візьмемо значення, наведені в табл. 9.2.

Розмір нашої функції становитиме:

ФР = 1хЗ + 1х4 + 1х5 + 1х7 + 1х7 = 26.

Це число є попередньою оцінкоюі потребує уточнення.

Таблиця 9.2.Приклад коефіцієнтів складності

Параметр
Зовнішні входи
Зовнішні виходи
Зовнішні запити
Внутрішні логічні файли
Зовнішні логічні файли

Наступним кроком визначення розміру програмного коду методом функціональних точок є присвоєння ваги (від 0 до 5) кожній характеристиці проекту. Перерахуємо ці характеристики:

• 1. Чи потрібно резервне копіюванняданих?
• 2. Потрібен обмін даними?
• 3. Чи використовуються розподілені обчислення?
• 4. Чи важлива продуктивність?
• 5. Програма виконується на завантаженому обладнанні?
• 6. Чи потрібно оперативне введення даних?
• 7. Чи використовується багато форм для введення даних?
• 8. Поля бази даних оновлюються оперативно?
• 9. Введення, висновок, запити є складними?
• 10. Внутрішні обчислення складні?
• 11. Чи код призначений для повторного використання?
• 12. Потрібне перетворення даних та встановлення програми?
• 13. Потрібно багато установок у різних організаціях?
• 14. Чи потрібно підтримувати можливість налаштування та простоту використання?

Значення даних характеристик визначаються так: 0 - ніколи; 1 – іноді; 2 – рідко; 3 – середньо; 4 – часто; 5 – завжди.

Ці показники для прикладу функції зведені в табл. 9.3.

Таблиця 9.3.Приклад характеристик проектів

Характеристика	Значення у прикладі	Характеристика	Значення у прикладі

Визначається 5 – сума всіх ваг.

І нарешті, уточнений функціональний розмір обчислюється за формулою

УФР = ФР X (0,65 + 0,01 X5). (9.3)

Уточнений функціональний розмір функції вибір методу буде таким:

УФР = 26 х (0,65 + 0,01 х 29) = 17,19.

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

В даний час існує кілька модифікацій методу функціональних точок.

Точки властивостей

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

Метод Mark II

Метод Mark II був представлений Чарльз Саймонс також в 1988 р. Цей метод більш придатний для оцінки складних систем, ніж класичний метод функціональних точок. Він дозволяє досягти одного і того ж результату як при оцінці системи в цілому, так і під час підсумовування оцінок, отриманих для складових її підсистем.

Тривимірні функціональні точки

У 1991 р. софтверним підрозділом корпорації Boeing було запропоновано ще одне рішення – метод тривимірних функціональних точок. Відмінністю класичного методу і те, що складність програмного продукту оцінюється у трьох напрямах - дані, функції і управління. Перевагою методу є його застосування не тільки до оцінки програмних проектів, але й до оцінки трудомісткості завдань в інших сферах діяльності.

Об'єктні точки

Метод об'єктних точок адаптує оригінальний метод функціональних точок до об'єктно-орієнтованої технології програмування.

Визначення меж програмного засобу

p align="justify"> Розроблюване програмний засіб є повністю локальним і не передбачає обміну даними з іншими програмними засобами через локальні або глобальні мережі.

Ідентифікація та оцінка функціональності даних (ILF, EIF)

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

Число типів елементів даних (DET) внутрішнього логічного файлу дорівнює шести:

1. n – кількість рядків у матриці. Кількість рядків дорівнює кількості стовпців, оскільки розрахунок ведеться для про квадратних матриць.

2. Mas – задана матриця.

3. – задана точність.

4. x 0 – початкове наближення.

5. - результат обчислень - максимальне власне число заданої матриці.

6. k - кількість ітерацій, необхідні обчислення максимального власного числа матриці із заданою точністю.

Число типів елементів записів (RET) для внутрішнього логічного файлу дорівнює чотирьом:

1. Mas – матриця.

2. x 0 – вектор.

3. n, k – цілі числа.

4. , - Речові числа.

Таким чином рівень складності внутрішнього логічного файлу визначений як низький.

Зовнішніх інтерфейсних файлів (ELF) цей програмний засіб не має.

Ідентифікація та оцінка функціональності транзакцій (EI, EO, EQ)

Цей програмний засіб передбачає два зовнішні введення (EI): введення даних з клавіатури та введення даних із файлу.

Для введення даних із клавіатури число типів елементів даних (DET) дорівнює п'яти: Mas, x 0 , n, і навіть кнопка «Ввести дані з клавіатури». Кількість типів, що використовуються (FTR) дорівнює п'яти.

Рівень складності для даного типувведення визначено як високий.

Для введення даних із файлу результати аналогічні результатам для введення з клавіатури, за винятком використання символьного рядказ ім'ям файлу та відповідної кнопки для завантаження даних. Тобто DET = 6, FTR = 5. Рівень складності для цього типу введення визначений як високий.

Цей програмний засіб має лише один зовнішній запит (EQ) – запит на коректність введених даних. Для цього потрібні змінні Mas, x 0 , n, їх значення перевіряються відповідно: для матриці - перевірка на занесення неприпустимих знаком - символів або літер, для початкового наближення - на рівність нулю, занесення неприпустимих знаків, для розміру матриці - приналежність до заданих меж, для точності – обмеження по порядку. Таким чином, DET = 4, FTR = 3. Інформація на виході цього запиту - "Введена інформація коректна" або "Введена інформація некоректна". Тобто DET=FTR=1. Таким чином, рівень складності зовнішнього запиту визначено середнім.

Цей програмний засіб передбачає два зовнішні висновки: виведення даних у файл і виведення даних на екран. Для виведення даних на екран число типів елементів даних DET дорівнює чотирьом: задана точність, отримана максимальна кількість матриці, кількість ітерацій, а також кнопка «Обчислити результати». Кількість типів FTR, що використовуються, дорівнює трьом. Таким чином рівень складності виведення на екран визначений як середній.

Для запису даних файл кількість типів елементів даних DET дорівнює п'яти: максимальне власне число, задана точність, кількість ітерацій, ім'я файлу, і навіть кнопка «Записати результати у файл». Кількість типів FTR, що використовуються, дорівнює чотирьом. Таким чином, рівень складності виведення файлу визначений як середній.

Визначення нормуючого фактора (VAF)

Розрахуємо ненормовану кількість функціональних точок.

Таблиця 1. Розрахунок UFPC

Основні характеристики системи:

· Програмний засіб реалізовано як єдиний пакет на автономному персональному комп'ютері - 0.

· Дані між компонентами програмного засобу та системи не передаються - 0.

· Вимоги до продуктивності та проектування програмного засобу були встановлені та розглянуті, але щоб задовольнити їх жодних спеціальних заходів не потрібно - 1.

· Явних чи неявних обмежень на використання ресурсів не встановлено – 0.

· Пікові періоди транзакцій не очікуються – 0.

· Складність діалогових транзакцій – понад 30% обробляються в інтерактивному режимі – 5.

· Ефективність програмного засобу для кінцевого користувача - 2.

· Оперативне оновленнявідсутня – 0.

· Складність обробки даних – 3.

· У програмному засобі немає коду, призначеного для повторного використання – 0.

· Ні особливих вимогкористувача, і не потрібно спеціальної програми встановлення - 0.

· Простота використання – 1.

· При проектуванні вимоги щодо встановлення програмного засобу були враховані, причому програмний засіб може виконуватися, тільки на схожому (сумісному) апаратному та/або програмне забезпечення - 2.

· Зміна програмного засобу не передбачена – 0.

Нормуючий фактор (VAF) обчислимо наступним чином:

VAF = 0,65 +0,01 * TDI = 0,65 +0,01 * (1 +5 +2 +3 +2) = 0,78

Підрахунок нормованої кількості функціональних точок

Нормована кількість функціональних точок визначається як:

APFC = UPFC * VAF = 35 * 0,78 = 26,3

Оцінка кількості рядків вихідного коду з використанням бекфайєр-методу

Програмний засіб розроблятиметься в середовищі MS Visual Studio 2008, тому значення мовного множника дорівнює 34. Таким чином, приблизна кількість рядків закінчена програми в середовищі MS Visual Studio 2008 буде рівна.