
- •Короткий конспект для підготовки до іспиту з предмета"Конструювання програмних засобів"
- •1. Цілі і завдання конструювання пз. Особливості сучасних великих проектів іс
- •2. Основні визначення. Програмні засоби. Програмне забезпечення (пз). Програмний продукт. Проектування пз. Програмування.
- •3. Класифікація типів програмного забезпечення.
- •4. Життєвий цикл (жц) пз. Процеси жц пз.
- •5. Моделі жц пз. Каскадна модель. Зміст етапів створення пз.
- •6. Моделі жц пз. Спіральна модель. Зміст етапів створення пз.
- •7. Моделі жц пз. Інкрементальная модель. Зміст етапів створення пз.
- •8. Розвиток інкрементального підходу. Xp-процессы.
- •9. Міжнародні стандарти проектування, розробки, оформлення документації, призначеного для користувача інтерфейсу пз.
- •10. Вимірювання, заходи і метрики. Розмірно-орієнтовані метрики. Функціонально-орієнтовані метрики.
- •11. Виконання оцінки проекту на основі loc- і fp-метрик
- •12. Проект. Склад і структура колективу розробників, їх функції.
- •13. Структурний підхід до проектування іс. Суть структурного підходу
- •14. Структурний підхід до проектування іс. Case - засоби розробки пз.
- •15. Методологія функціонального моделювання sadt. Склад функціональної моделі. Ієрархія діаграм. Типи зв'язків між функціями. Приклади функціональних моделей в стандарті Idef0.
- •16. Моделювання потоків даних (процесів). Зовнішня суть. Системи і підсистеми. Процеси. Накопичувачі даних. Потоки даних. Побудова ієрархії діаграм потоків даних.
- •17. Моделювання даних. Case-метод Баркера. Методологія Idef1.
- •18. Проектування іс на основі об'єктно-орієнтованого підходу. Зіставлення і взаємозв'язок структурного і об'єктно-орієнтованого підходів.
- •20. Раціональний Уніфікований Процес. Динамічні аспекти процесів: структура жц, стадії, ітерації і контрольні крапки.
- •21. Раціональний Уніфікований Процес. Статичний зміст процесу: види діяльності (технологічні операції), робочі продукти, виконавці і дисципліни (технологічні процеси).
- •22. Якість програмного продукту. Критерії якості пз.
- •1. Зовнішні
- •2. Внутрішні
- •23. Сертифікація фірм розробників по моделі якості смм.
- •24. Документація, що створюється в процесі розробки програмних засобів. Документи управління розробкою пз. Документи, що входять до складу пз.
- •25. Призначена для користувача документація.
- •26. Документація по супроводу програмних засобів.
- •27. Людський чинник в управлінні проектами. Завдання n-личностей. Закон Брукса. Підходи до управління групами і керівництва ними.
11. Виконання оцінки проекту на основі loc- і fp-метрик
Мета цієї діяльності - сформувати попередні оцінки, які дозволять:
- пред'явити замовникові коректні вимоги за вартістю і витратами на розробку програмного продукту;
- скласти план програмного проекту.
При виконанні оцінки можливі два варіанти використання LOC- і FP-данных:
- як оцінні змінні, що визначають розмір кожного елементу продукту;
- як метрики, що зібраних за минулі проекти і входять в метричний базис фірми.
Порядок проведення процедури оцінки.
1. Область призначення проектованого продукту розбивається на ряд функцій, кожну з яких можна оцінити індивідуально: f1, f2..., fn.
2. Для кожної функції fi планувальник формує кращу Locлучшi(Fpлучшi), гіршу Locхудшi(Fpхудшi) і вірогідну оцінку Locвер i(Fpвер i). Використовуються досвідчені дані (з метричного базису) або інтуїція. Діапазон значення оцінок відповідає ступеню передбаченої невизначеності.
3. Для кожної функції fi відповідно до розподілу обчислюється очікуване значення LOC- (або FP-) оцінки:
4. Визначається значення LOC- або FP-производительности розробки функції. Використовується один з трьох підходів:
а) для всіх функції приймається одна і та ж метрика середньої продуктивності Проїзвср, узята з метричного базису;
б) для i-й функції на основі метрики середньої продуктивності обчислюється величина продуктивності, що настроюється:
,где Loccp - середня LOC-оценка, узята з метричного базису (відповідає середній продуктивності);
в) для i-й функції величина продуктивності, що настроюється, обчислюється по аналогу, узятому з метричного базису:,
Перший підхід забезпечує мінімальну точність (при максимальній простоті обчислень), а третій підхід - максимальну точність (при максимальній складності обчислень).
5. Обчислюється загальна оцінка витрат на проект
12. Проект. Склад і структура колективу розробників, їх функції.
Сучасні крупні проекти ІС характеризуються, як правило, наступними особливостями:
- складність опису (достатньо велика кількість функцій, процесів, елементів даних і складні взаємозв'язки між ними), що вимагає ретельного моделювання і аналізу даних і процесів;
- наявність сукупності тісно взаємодіючих компонентів (підсистем), що мають свої локальні завдання і цілі функціонування (наприклад, традиційних застосувань, пов'язаних з обробкою транзакцій і вирішенням регламентних завдань, і додатків аналітичної обробки (підтримка ухвалення рішень), що використовують нерегламентовані запити до даних великого об'єму);
- відсутність прямих аналогів, що обмежує можливість використання яких-небудь типових проектних рішень і прикладних систем;
- необхідність інтеграції що існують і знов розробляються додатків;
- функціонування в неоднорідному середовищі на декількох апаратних платформах;
- роз'єднаність і різнорідність окремих груп розробників по рівню кваліфікації і традиціям використання тих або інших інструментальних засобів, що склалися;
- істотна тимчасова протяжність проекту, обумовлена, з одного боку, обмеженими можливостями колективу розробників, і, з іншого боку, масштабами організації-замовника і різним ступенем готовності окремих її підрозділів до впровадження ІС.
Для успішної реалізації проекту об'єкт проектування (ІС) має бути перш за все адекватно описаний, мають бути побудовані повні і несуперечливі функціональні і інформаційні моделі ІС. Накопичений до теперішнього часу досвід проектування ІС показує, що це логічно складна, трудомістка і тривала за часом робота, що вимагає високої кваліфікації фахівців, що беруть участь в ній. Проте до недавнього часу проектування ІС виконувалося в основному на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ІС. Крім того, в процесі створення і функціонування ІС інформаційні потреби користувачів можуть змінюватися або уточнюватися, що ще більш ускладнює розробку і супровід таких систем.
Перераховані чинники сприяли розвитку досліджень в області методології програмування. Програмування знайшло риси системного підходу з розробкою і впровадженням мов високого рівня, методів структурного і модульного програмування, мов проектування і засобів їх підтримки, формальних і неформальних мов описів системних вимог і специфікацій і так далі
Для цілеспрямованого виконання проекту має бути виконаний ряд робіт, різних як по своєму призначенню, так і по кваліфікаційних вимогах, що пред'являються до розробників. Іншими словами, в ході розвитку проекту командою розробників виконуються ті або інші функції.
Функції, що виконуються розробниками, - поняття неформалізоване. У різних проектах воно може знаходити свій зміст. Проте типові функції, які припускають практично всі програмні проекти, можна перерахувати. Так, в будь-якому програмному проекті є функції кодування, тобто записи програми на алгоритмічній мові по наявних специфікаціях, аналізу вимог, тобто виявлення дійсної потреби в створюваній програмі, тестування і відладки. Далі ми розглянемо ці і інші функції розробників, пов'язані з проектом, а поки лише відмітимо, що в рамках діяльності менеджера будь-якого проекту необхідно організувати розподіл функцій проекту між виконавцями. Цілком природно рахувати ці дії однієї з функцій менеджера. В результаті її виконання члени команди, що виконує проект, починають грати відповідні ролі.
Зрозуміло, що як склад, так і значущість ролей розробників і тих, хто з ними пов'язаний, розрізняються залежно від виконуваного проекту, від колективу виконавців, прийнятої технології, від інших чинників. Неоднозначність вибору ролей приводить до того, що їх список часто стає непомірно великий (ілюстрацією тому може служити перша редакція документації по Rational Unified Processing (RUP), в якій визначено понад 20 ролей; у подальших версіях документа це число скорочене до осяжного рівня [30]). Надмірне збільшення числа є наслідок ототожнення ролі і функції і, відповідно, ігнорування поняття спорідненості функцій. В той же час, якщо ролей вибрано недостатньо, є небезпека, що не всі потрібні в проекті функції будуть охоплені плануванням і управлінням.