- •I. Введення в розробку програмного забезпечення
- •1. Складність інформаційних систем
- •2. Розробка програмного забезпечення
- •4.Концептуальне моделювання
- •2. Модель водоспаду із зворотнім зв'язком
- •7.Модель спіралі
- •III. Етапи розробки програмного забезпечення
- •1. Стратегічний етап
- •2.2. Нефункціональні вимоги
- •4. Етап проектування
- •5. Етап реалізації
- •6. Етап тестування
- •7. Етап установки
- •8. Етап підтримки
- •IV. Стратегічний етап
- •1. Дії на стратегічному етапі
- •2. Співпраця з клієнтом
- •3. Область дії і контекст проекту
- •4. Стратегічні рішення
- •5. Оцінка різних варіантів рішеннь
- •6. Оцінка вартості рішень
- •7. Чинники успіху
- •8. Результати стратегічного етапу
- •9. Короткий звіт
- •V. Розпізнавання вимог і документація
- •1. Складнощі у формулюванні вимог
- •2. Методи ідентифікації вимог
- •3. Методи опису вимог
- •4. Типи вимог
- •5. Перевірка вимог
- •6. Документ з вимогами
- •7. Чинники успіху
- •8. Короткий звіт
- •VI. Розробка моделі
- •1. Потреба в розробці моделі
- •2. Аналітична модель
- •3. Дії на етапі аналізу
- •4. Функціональна декомпозиція
- •5. Методологія, що використовується в створенні аналітичної моделі
- •6. Документація вимог
- •7. Аналіз чинників успіху
- •8. Короткий звіт
- •VII. Етап проектування
- •1. Цілі проектування
- •Малюнок 7.2.1. Етап проектування.
- •2. Специфікація результатів аналізу
- •3. Дизайн інтерфейсу
- •4. Структуровані схеми/діаграми
- •5. Складова організації даних
- •6. Оптимізація проекту
- •7. Фізична структура системи
- •8. Правильність і якість проекту
- •9. Нефункціональні вимоги на етапі проектування
- •10. Результати етапу проектування
- •11. Детальний документ проекту
- •2. Стандарти, правила і порядок здійснення дій проекту:
- •12. Короткий звіт
- •VIII. Розробка інтернет-програм
- •1. Специфікація інтернет-програми
- •2. Методи розробки інтернет-програм
- •3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)
- •4. Метод розробки веб-сторінок (wsdm)
- •5. Мова веб-моделювання (WebMl)
- •6. Короткий звіт
- •IX. Бдб і бдс системи
- •1. Електронний бізнес
- •2. Інтернет-бізнес і електронний ринок.
- •3. Інтернет-магазин
- •4. Модель електронного бізнесу
- •1.Модель брокера
- •2.Модель, яка задовольняє індивідуальним потребам
- •3.Модель контактів
- •5. Платежі
- •6. Безпека
- •8. Моделювання систем бдб і бдс
- •9. Багатошарова архітектура програм
- •9. Cервіс-орієнтована архітектура (соа)
- •10. Короткий звіт
- •X. Реалізація
- •1. Характеристики етапу реалізації
- •2. Надійність програмного забезпечення
- •3. Похибка
- •4. Транзакції
- •5. Середовище реалізації
- •6. Чинники успіху і результати етапу реалізації
- •7. Короткий звіт
- •XI. Тестування
- •1. Етап тестування
- •2. Перевірка
- •Малюнок 11.3.1. Модель V-тестування.
- •3. Перегляди
- •4. Аудит
- •5. Інспекції
- •6. Види тестів
- •7. Процес тестування
- •8. Тестування надійності
- •9. Типи тестів на знаходження помилок
- •10. Програми-інструменти
- •11. Статичні тести
- •12. Підрахунок кількості помилок
- •13. Чинники успіху, успіх тестування
- •14. Короткий звіт
- •XII. Оцінка програмного забезпечення
- •1. Простановка розмірів проекту
- •2. Оцінка складності в проектах
- •3. Ефекти масштабування
- •4. Оцінка вартості програмного забезпечення
- •5. Конструктивна вартісна модель (cocomo)
- •6. Балова функціональна оцінка
- •7. Метод випадкового використання
- •8. Короткий звіт
- •XIII. Управління конфігурацією пз і версіями
- •1. Управління конфігурацією пз
- •2. Елементи конфігурації пз
- •3. Угода позначень
- •4. Зберігання елементів конфігурації
- •5. Перегляди
- •7. План управління конфігурації пз
- •I Вступ
- •II Управління
- •III Визначення конфігурації
- •IV Управління конфігурацією
- •V Реєстрація статусу конфігурації
- •4. Модель якості iso-9126
- •5. Управління якістю
- •6. Стандарти якості
- •7. Незрілість і зрілість виробництва
- •8. План гарантії якості пз (sqap)
- •9. Короткий звіт
- •XV. Управління проектом програмного забезпечення
- •1. Завдання управління проектом
- •2. Працівники виробництва програмного забезпечення
- •3. Характеристика хорошого розробника програмного забезпечення
- •4. Робота в команді
- •5. Управління підприємством по виробництву програмного забезпечення
- •6. Розвиток компанії по розробці програмного забезпечення
- •7. Документація проекту
- •8. Визначення продуктивності
- •9. Складання графіків проекту
- •10. Завдання управління проектом
- •11. Інтерфейс проекту
- •12. Планування проекту
- •13. Управління ризиком
- •14. Вимірювання процесів і продуктів
- •15. Короткий звіт
6. Балова функціональна оцінка
Метод під назвою FPA (Балова функціональна оцінка, Function Points Analysis) був розроблений Albrecht'ом в 1979-1983. Метод комбінує аналіз розміру проекту програмного забезпечення з аналізом програмного продукту. Кількість невиправлених функціональних оцінок обчислюється по формулах:
Ввід користувача: об'єкти, що вводяться, які впливають на системні дані,
Вивід користувача: об'єкти, що виводяться, пов'язані з системними даними,
Внутрішні набори даних: число внутрішніх файлів,
Зовнішні набори даних: число зовнішніх файлів, написаних процесами,
Зовнішні питання: інтерфейс з середовищем.
FPA - перший метод системного вимірювання з призначеної для користувача точки зору, яка ігнорує технічні подробиці. Оцінка ставиться на основі даних в початковому формулюванні вимог. Витрати на робоче навантаження, розробку і інсталяцію обчислюються з використанням даних.
Метод технологічно незалежний і через це практично може бути застосований до систем на різних платформах і на ранніх стадіях системної розробки.
У FPA одиниця вимірювання - значення функції. Це відноситься до функціональності системи, тобто до категорій продуктивності.
У FPA є п'ять абстрактних класів функціональності:
функціональність введення зовнішніх даних в систему - системний ввід,
функціональність отримання внутрішніх даних з системи - системний вивід,
функціональність внутрішніх структур даних,
функціональність комунікації із зовнішніми програмами і даними,
функціональність взаємодій, що не відносяться до потоку даних, - питання до системи.
Мал. 12.7.1. Ваги, привласнені в FPA проектам.
Будь-який компонент оціненого програмного забезпечення повинен бути класифікований відповідно до приведеної вище класифікації, а рівень його складності повинен бути визначений. Фіксовані маси були привласнені класам і рівням складності, грунтуючись на традиційному підході - єдине обгрунтування, яке Albrecht надає, - його затвердження: "Це дає добрі результати".
Повна складність обчислюється, грунтуючись на вагах в таблиці в кожному невідрегульованому значенні функції (UFP, Unadjusted Function Point). Для цього використовується наступна формула:
UFP - невідрегульоване значення функції, w – значення ваги, n – кількість елементів в проекті, i - порядковий номер оброблюваного елементу, j – рівень складності.
Підрахована сума перевіряється, грунтуючись на 14 змінних коефіцієнтах, які відображають умови розвитку системи:
Існування комунікаційної апаратури.
Розподіл обробки.
Час очікування відповіді.
Вихід з апаратного робочого навантаження.
Частота виконання великих транзакцій.
Прямий режим вхідних даних.
Продуктивність кінцевого користувача.
Пряме оновлення даних.
Складність обробки даних.
Можливість багатократного використання програми.
Інсталяційний пристрій.
Сервісний пристрій.
Розповсюдження фізичної пам'яті.
Пристрій підтримки.
Мал. 12.7.3. Оцінка коректування чинників FPA.
Кожен чинник оцінюється значенням від 0 до 5, де 0 означає нульовий вплив, а 5 - сильний. Оцінка виконується суб'єктивним чином - з використанням інтуїції і досвіду. Кінцева складність функції, тобто число скоректованих покажчиків, обчислюється з формули:
FP = (0,65 + 0,01 * VAF) * UFP FP = (0,65 ...1,35) * UFP
де:
VAF – комбінований настроювальний коефіцієнт,
FP – значення функції, K - К-те значення настроювального коефіцієнта.
Приклад обчислення значень функції
Послідовність підрахунку значень функції
Визначення системи.
Обчислення настроювального коефіцієнта.
Необхідні набори даних і визначення їх складності.
Функціональні елементи і визначення їх складності.
Обчислення.
Перевірка.
Звіти.
Мал. 12.7.5. містить приклад обчислення значення функції.
Мал. 12.7.5. Приклад обчислення значення функції.
Обчислення значення функції
Знаючи значення функції, ми можемо оцінити кількість рядків коду програми.
Приклади відповідних значень показані в таблиці:
Функція із значенням 1 дорівнює 125 командам на C
Значення функції |
Тип проекту |
10 |
типова маленька програма, написана клієнтом (1 місяць) |
100 |
найчастіші програми, що зустрічаються: типове значення для програми написаною клієнтом (6 місяців) |
1,000 |
комерційне застосування в MS Windows, маленький клієнт-сервер програм (10 програмістів, більше 12 місяців) |
10,000 |
системи (100 програмістів, більше 18 місяців) 100,000 - MS Windows’95, MVS, військові системи |
Таблиця 12.7.2. Значення функції порівняно з типом проекту.
Також ми можемо використовувати значення функції для оцінки трудового споживчого чинника проекту. Діаграма, показана нижче, ілюструє взаємозв'язок між трудовим споживанням і значенням функції.
Мал. 12.7.6. Функціональна залежність трудового споживання.
Інші застосування функціональних залежностей:
Оцінка складності системи
Перевірка проекту
Вибір інформаційної системи для перепроектування (вартість підтримки/значення функції)
Оцінка тестів
Оцінка якості командної роботи і продуктивності
Вартість підтримки і прогноз системного розвитку
Порівняння різних пропозицій провайдерів програмного забезпечення з точки зору вартості і заслуг
Значення функції і мови баз даних:
Тип мови або сама мова |
Рівень мови ac.SPR |
Ефективність.Loc.7FP |
Access |
8.5 |
38 |
ANS!SQL |
25.0 |
13 |
CLARION |
5.5 |
58 |
CA Clipper |
17.0 |
19 |
dBase III |
8.0 |
40 |
dBase IV |
9. U |
36 |
DELPHI |
11.0 |
29 |
FOXPRO 2.5 |
9.5 |
34 |
INFORMIX |
8.0 |
40 |
MAG1C |
15.0 |
21 |
ORACLE |
8.0 |
40 |
Oracle Developer 2000 |
14.0 |
23 |
PROGRESS v.4 |
9.0 |
36 |
SYBASE |
8.0 |
40 |
(з дослідження продуктивності програмного забезпечення)
Таблиця 12.7.7. Значення функції і бази даних.
Рівень мови ac.SPR |
Середня продуктивність (значення функції/працівники * місяц) |
1 - 3 |
5 - 10 |
4 - 8 |
10 - 20 |
9 - 15 |
16 - 23 |
16 - 23 |
15 - 30 |
24 - 55 |
30 - 50 |
> 55 |
40 - 100 |
(з дослідження продуктивності програмного забезпечення)
Таблиця 12.7.8. Значення функції і продуктивність.
Перевага FPA є мови програмування і його якість. Інші способи вимірювання програм не мають цих переваг. Недолік FPA - суб'єктивність методу в самому заданні значень функції. Ефективність методу може залежати від навиків і "відчуття" аналітика. Автоматичне призначення значень функції неможливе. Іноді суб'єктивність вважається перевагою, подібно до оцінки експертних методів.