- •Поняття технології конструювання програмного забезпечення.
- •Класичний життєвий цикл.
- •Макетування.
- •Характеристика стратегій конструювання пз.
- •Інкрементна модель.
- •Спіральна модель.
- •Важковагові та полегшені процеси. 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.
Користувачі. Покупці. Інвестори.
Користувач — людина, що користується послугами обчислювальної техніки для отримання інформації чи розв'язування різноманітних задач.
Покупець — фізична або юридична особа, яка здійснює оплату грошима і є набувачем товару або послуги.
Інвестор — людина чи комерційна установа, яка вкладає гроші та/або інші активи з метою їхнього збереження та примноження. На відміну від споживання чи витрати, інвестування має на меті передусім віддачу. Вважається, що якщо людина відкладає понад 30% свого доходу, її можна розглядати як потенційного інвестора. В розмовній мові інвестором як правило називають людей чи підприємства, які здійснюють значні капіталовкладення.
Вимоги до пз кожної з сторін.
Вимоги до програмного забезпечення — набір вимог щодо властивостей, якості та функцій програмного забезпечення, що буде розроблено, або знаходиться у розробці. Вимоги визначаються в процесі аналізу вимог та фіксуються в специфікації вимог, діаграмах прецедентів та інших артефактах процесу аналізу та розробки вимог.
Розробка вимог до програмної системи може бути розділена на декілька етапів:
Знаходження вимог (збір, визначення потреб зацікавлених осіб та систем).
Аналіз вимог (перевірка цілісності та закінченості).
Специфікація (документування вимог).
Тестування вимог.
Атрибути якості пз: практичність, відмовостійкість, надійність, ремонтопридатність.
Практичність. Здатність ПЗ бути зручним у навчанні та використанні, а також привабливим для користувачів.
Зрозумілість (understandability). Показник, зворотний до зусиль, які затрачаються користувачами на сприйняття основних понять ПЗ та усвідомлення їх застосовності для розв'язання своїх задач.
Зручність навчання (learnability). Показник, зворотний зусиллям, затрачуваним користувачами на навчання роботі з ПЗ.
Зручність роботи (operability). Показник, зворотний зусиллям, що вживається користувачами для розв'язання своїх задач за допомогою ПЗ.
Привабливість (attractiveness). Здатність ПЗ бути привабливим для користувачів. Цей атрибут доданий в 2001 році.
Відповідність стандартам зручності використання (usability compliance). Цей атрибут доданий в 2001 році.
Надійність. Здатність ПЗ підтримувати визначену працездатність у заданих умовах.
Зрілість, завершеність (maturity). Величина, зворотна частоті відмов ПЗ. Звичайно виміряється середнім часом роботи без збоїв і величиною, зворотною імовірності виникнення відмови за даний період часу.
Стійкість до відмов (fault tolerance). Здатність підтримувати заданий рівень працездатності при відмовах і порушеннях правил взаємодії з середовищем.
Здатність до відновлення (recoverability). Здатність відновлювати визначений рівень працездатності та цілісність даних після відмови, необхідні для цього час і ресурси.
Відповідність стандартам надійності (reliability compliance). Цей атрибут доданий в 2001 році.
Визначення архітектури пз.
Архітектура програмного забезпечення — це структура програми або обчислювальної системи, яка містить програмні компоненти, видимі ззовні властивості цих компонентів, а також відносини між ними. Цей термін також відноситься до документування архітектури програмного забезпечення. Документування архітектури ПЗ спрощує процес комунікації між зацікавленими, дозволяє зафіксувати прийняті на ранніх етапах проектування рішення про високорівневий дизайн системи і дозволяє використовувати компоненти цього дизайну і шаблони проектування повторно в інших проектах.
