30. Область дії і контекст проекту

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

31.На цьому етапі існує декілька стратегічних рішень, які повинні бути прийняті:

• вибір моделі проекту

• вибір методів, що будуть використовуютися для аналізу і проектування

• вибір програмного середовища

• вибір CASE-інструментів

• рішення про використання наборів інструментів

• рішення про можливу співпрацю

32. Як правило, існують декілька можливих рішень по системі і ці варіанти рішень підпорядковані певним обмеженням. Обмеження можуть стосуватись:

• максимальна допустима вартість

• доступні професіонали і персонал

• доступні інструменти

• обмеження в часі

33. Під вивченням досяжності розробки розуміють:

• порівняння розмірів проекту, проектної команди і необхідного часу

• наявність ресурсів (бюджет, штат, менеджери),

• обмеження в часі,

• початкові умови, потрібні для реалізації,

• наявність ПЗ і інструментів,

• наявність апаратури і мережі,

• наявність технологій і ноу-хау,

• наявність експертів,

• наявність послуг, співробітників і постачальників,

• наявність офісів і транспорту.

34

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

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

• використання інструментів і понять

• методи документування

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

35.

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

Вірогідність переходів вказується на краях вузлів. Кожне правило, що веде до рішення, має вагу.

Приклад.

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

Приклад дерева ризику має вигляд:

Приклад дерева ризику.

36. Оцінка вартості рішень

Оцінка вартості визначається для кожного з варіантів рішень.

Вартість складають наступні аспекти:

• вартість апаратури,

• вартість навчання професіоналів,

• вартість придбання інструментів,

• робоче навантаження.

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

37. Алгоритмічні методи. Вони вимагають атрибути даних у формі номерів або описів. Відповідна математична формула видає результат.

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

Метод COCOMO(Constructive Cost Model). Метод заснований на декількох формулах, які дають змогу зробити оцінку повної вартості, якщо відома кількість рядків коду. Це є слабким місцем методу. Функціональний метод. Метод оцінює вартість, базуючись на функціях, які повинні бути реалізовані. Метод Delphi. Цей метод заснований декількома експертами, які не мають зв'язку між собою.

Аналіз активних дій. Проект ділиться на дії, відомі з попередніх проектів.

38. Метод COCOMO(Constructive Cost Model). Метод заснований на декількох формулах, які дають змогу зробити оцінку повної вартості, якщо відома кількість рядків коду. Це є слабким місцем методу. Число рядків може бути відоме тільки коли розробка архітектури системи завершена, що зазвичай надто пізно. Поняття "рядок коду" залежить від мови програмування. COCOMO пропонує декілька рішень: просте, середньої складності і складне (детальне). Простий метод обчислює вартість, застосовуючи просту формулу для оцінки числа людей і місяців, потрібних для завершення проекту. Метод середньої складності змінює результати простого методу, враховуючи нові чинники, які залежать від складності проекту. Складний метод враховує нові чинники і вплив інших факторів на систему, але це не призводить до збільшення точності оцінок.

39. Функціональний метод. Метод оцінює вартість, базуючись на функціях, які повинні бути реалізовані. Тому метод може бути застосований тільки після того, як функції стануть хоча б приблизно відомі. Метод включає кількість введень, виводів, необхідний розмір пам'яті і інші критерії. Компоненти множаться на вагу, після чого підводяться підсумки. Результат представляється як точка функції. Вартість може змінюватися, якщо з'являться складніші умови програмування. Існує спосіб перетворення цієї суми у вартість рядків коду (COCOMO). Метод широко використовується і має лише невеликі недоліки.

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

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