- •Поняття технології конструювання програмного забезпечення.
- •Класичний життєвий цикл.
- •Макетування.
- •Характеристика стратегій конструювання пз.
- •Інкрементна модель.
- •Спіральна модель.
- •Важковагові та полегшені процеси. Xp – процес.
- •Швидка розробка додатків, rad.
- •Компонентно-орієнтована модель. Моделі якості процесів конструювання.
- •Сторони зацікавлені в продукції.
- •Користувачі. Покупці. Інвестори.
- •Вимоги до пз кожної з сторін.
- •Атрибути якості пз: практичність, відмовостійкість, надійність, ремонтопридатність.
- •Визначення архітектури пз.
- •Опис архітектури пз.
- •Універсальна мова моделювання (uml).
- •Інші базові засоби для створення архітектури.
- •Основні компоненти мови. Призначення мови. Термінологія uml.
- •Процес керування проектом. Планування.
- •Планування проектних задач.
- •Розмірно-орієнтовані метрики.
- •Функціонально-орієнтовані метрики.
- •Виконання оцінки проекту на основі loc- та fp-метрик.
- •Дослідження під моделей моделі cocomo, cocomo II.
- •Конструктивна модель вартості.
- •Модель композиції додатку.
- •Модель раннього етапу проектування.
- •Модель етапу пост архітектури.
- •Структурний аналіз.
- •Основи проектування програмних систем.
- •Класичні методи проектування.
- •Основні поняття та принципи тестування пз.
- •Особливості тестування «білого ящику».
- •Способи тестування базового шляху.
- •Способи тестування умов.
- •Спосіб тестування потоків даних.
- •Тестування циклів.
- •Особливості тестування «чорного ящику».
- •Спосіб розбиття по еквівалентності.
- •Спосіб аналізу граничних значень.
- •Спосіб діаграм причин-наслідків.
- •Дослідження способів структурного та функціонального тестування на прикладах.
- •Методика тестування програмних систем.
- •Тестування правильності.
- •Системне тестування .
- •Мистецтво налагоджування.
- •Основні принципи об’єктна-орієнтованої методології розробки програмної системи (оом пс).
- •Оо Аналіз.
- •Об’єкти та класи.
- •Діаграми в uml.
- •Механізми розширення в uml.
- •Діаграма варіантів використання.
- •Дослідження діаграми варіантів використання.
- •Діаграма класів.
- •2. Асоціації:
- •Дослідження діаграми класів.
- •Діаграма станів.
- •Дослідження діаграми станів.
- •Діаграма діяльності.
- •Дослідження діаграми діяльності.
- •Діаграма послідовності.
- •Дослідження діаграми послідовності.
- •Діаграма кооперації.
- •Дослідження діаграми кооперації.
- •Діаграма компонентів.
- •Дослідження діаграми компонентів.
- •Діаграма розгортування.
- •Дослідження діаграми розгортування.
- •Загальні відомості case-засобів.
- •Case-засоби. Класифікація case-засобів.
- •Порівняння життєвого циклу програмного забезпечення при традиційній розробці і розробці з використанням case-засобів.
- •Концептуальні основи case-технології.
- •Технологія впровадження –засобів.
- •Оцінка і вибір –засобів.
- •Засоби функціонального моделювання.
- •Характеристики case–засобів Silverrun.
- •Характеристики case–засобів jam.
- •Загальна характеристика case-системи Rational Rose.
- •Розробка діаграм у середовищі Rational Rose.
- •Початок роботи над проектом у середовищі Rational Rose.
Планування проектних задач.
Основне завдання у разі планування є визначення WBS -Work Breakdown Structure (структури розподілу робіт). Вона складається з допомогою утиліти планування проекту.
Першими виконуваними завданнями є системний аналіз стану і аналіз вимог. Вони закладають фундамент для наступних паралельних завдань.
Системний аналіз здійснюється з метою:
1. з'ясування потреб замовника;
2. оцінки здійсненності системи;
3. виконання економічного і технічного аналізу;
4. розподілу за елементами комп'ютерної системи (апаратурі, програмам, людям, баз даних, і т. буд.);
5. визначення вартості та планування;
6. створення системної специфікації.
У системної специфікації описуються функції, характеристики системи, обмеження розробки, вхідні і вихідна інформація.
Аналіз вимог дає можливість:
1. визначити функції і характеристики Програмної продукту;
2. позначити інтерфейс продукту коїться з іншими системними елементами;
3. визначити проектні обмеження програмного продукту;
4. побудувати моделі: процесу, даних, режимів функціонування продукту;
5. створити таких форм подання та зняття функцій системи, які можна залучити до ході проектування.
Розмірно-орієнтовані метрики.
Розмірно-орієнтовані метрики прямо вимірюють програмний продукт і процес його розробки. Грунтуються розмірно-орієнтовані метрики на LOC-оцінках (Lines Of Code). LOC-оцінка — це кількість рядків в програмному продукті.
Переваги розмірно-орієнтованих метрик:
широко поширені;
прості і легко обчислюються.
Недоліки:
залежні від мови програмування;
вимагають початкових даних, які важко отримати на початковій стадії проекту;
не пристосовані до не процедурних мов програмування.
Функціонально-орієнтовані метрики.
Функціонально-орієнтовані метрики побічно вимірюють програмний продукт і процес його розробки. Замість підрахунку LOC-оцінки при цьому розглядається не розмір, а функціональність або корисність продукту.
Використовується 5 інформаційних характеристик:
1. Кількість зовнішніх вводів. Підраховуються всі вводи користувача, за якими надходять різні прикладні дані. Уведення повинні бути відокремлені від запитів, які підраховуються окремо.
2. Кількість зовнішніх висновків. Підраховуються всі висновки, за якими до користувача надходять результати, обчислені програмним додатком. У цьому контексті висновки означають звіти, екрани, роздруківки, повідомлення про помилки. Індивідуальні одиниці даних усередині звіту окремо не підраховував.
3. Кількість зовнішніх запитів. Під запитом розуміється діалоговий введення, який призводить до негайного програмному відповіді в формі діалогового виведення. При цьому діалоговий введення в додатку не зберігається, а діалоговий висновок не вимагає виконання обчислень. Підраховуються всі запити - кожен враховується окремо.
4. Кількість внутрішніх логічних файлів. Підраховуються всі логічні файли (тобто логічні групи даних, які можуть бути частиною бази даних або окремим файлом).
5. Кількість зовнішніх інтерфейсних файлів. Підраховуються всі логічні файли з інших додатків, на які посилається даний додаток.
Кожній з виявлених характеристик ставиться у відповідність складність. Для цього характеристиці призначається низький, середній або високий ранг, а потім формується числова оцінка рангу.
