
- •Лекція 1. Тема: ядра знань swebok
- •1.1. Аналіз і характеристика областей знань swebok
- •1.1.1 Основи програмних вимог (Software Requirements)
- •1.1.2. Проектування пз (Software design)
- •1.1.3. Конструювання пз (Software Construction)
- •1.1.4 Тестування пз (Software Testing)
- •1.1.5 Супровід пз (Software maintenance)
- •1.1.6. Управління конфігурацією пз (Software Configuration Management– scm)
- •1.1.7. Управління інженерією пз (Software Engineering Management)
- •1.1.8. Процес інженерії пз (Software Engineering Process)
- •1.1.9. Методи і засоби інженерії пз (Software Engineering Tools and Methods)
- •Лекція 2. Тема: життєвий цикл і етапи розробки програмного забезпечення
- •Лекція 3. Тема: еволюція моделей життєвого циклу програмного забезпечення
- •1.6. Прискорення розробки пз.
- •Лекція 4. Тема: оцінка якості процесів створення програмного забезпечення
- •Лекція 5. Тема: визначення вихідних даних для проектування програмного забезпечення
- •5.1 Визначення вимог до пз
- •5.2 Формування і аналіз вимог
- •5.2.1 Опорні точки зору
- •5.2.2 Сценарії
- •5.2.3 Етнографічний метод
- •5.3 Специфікація вимог
- •5.4 Атестація вимог
- •5.5 Класифікація програмних продуктів за функціональною ознакою
- •5.6 Основні експлуатаційні вимоги до програмних продуктів
- •5.7 Передпроектні дослідження предметної області
- •Лекція 6. Тема: розробка технічного завдання
- •2. Підстави для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •5. Вимоги до програмної документації
- •1. Вступ
- •2. Підстава для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •4.1. Вимоги до функціональних характеристик
- •Лекція 7. Тема: принципові рішення початкових етапів проектування
- •Контрольні питання і завдання
- •Аналіз вимог і визначення специфікацій програмного забезпечення при структурному підході
- •Лекція 8. Тема: Специфікації програмного забезпечення при структурному підході
- •Flow-форми
- •Діаграми Насси-Шнейдермана
- •Контрольні питання та завдання:
- •Лекція 9. Тема: діаграми потоків даних
- •Словник даних
- •Вміст словника даних
- •Лекція 10. Тема: діаграми «сутність-зв’язок»
- •Лекція 11. Тема: приклади побудови діаграм та специфікації процесів
- •Лекція 12 Тема: діаграми переходів станів
- •13.1. Структурна схема майбутнього програмного забезпечення
- •13.2 Використання методу покрокової деталізації для проектування структури програмного забезпечення
- •13.3 Структурні карти Константайна
- •13.4.Структурні карти Джексона
- •13.5 Характеристики хорошої моделі реалізації
- •Зчеплення
- •Зв’язаність
- •13.6 Функціональна схема
- •Лекція 14. Тема: методології структурного аналізу і проектування
- •Контрольні питання та завдання
- •Лекція 15. Тема: синтаксис діаграм
- •Контрольні питання та завдання
- •Лекція 16. Тема: Синтаксис діаграм
- •Збір інформації
- •Контрольні питання та завдання:
- •Лекція 17. Тема: побудова sadt-діаграм
- •17.2. Побудова sadt-діаграми для процесу “Побудова таблиць/графіків функцій однієї змінної”
- •Типи зв'язків між функціями
- •Лекція 18. Тема: доповнення до діаграм і моделей
- •Критерії оцінки і вибору
- •Функціональні характеристики
- •3. Загальні функції:
Контрольні питання і завдання
Які типи програмних продуктів можна виділити? Чим вони розрізняються?
Назвіть основні експлуатаційні вимоги до програмних продуктів. Якими засобами і прийомами забезпечується кожен з них? Для яких типів програмних систем доцільно вказувати кожен з них?
У яких ситуаціях необхідні передпроектні дослідження? Які питання при цьому вирішують? Що отримують в результаті таких досліджень?
Назвіть, який розділ технічного завдання можна вважати основним і чому? Яку інформацію повинна містити решта розділів? У чому основна складність розробки технічного завдання?
Складіть технічне завдання на розробку «калькулятора» за типом, пропонованого Windows. Проаналізуйте, які програми або програмні системи могли б відповідати вказаним вами вимогам. Спробуйте обмежити їх кількість, уточнивши технічне завдання.
Які вирішення ранніх етапів проектування вважають основними і чому?
Аналіз вимог і визначення специфікацій програмного забезпечення при структурному підході
Наступним етапом розробки ПЗ є стадія «Ескізного проекту», тобто етапу аналізу вимог до майбутнього програмного продукту і розробка специфікацій.
У цілому в процесі визначення специфікацій будують загальну модель наочної області, як деякої частини реального світу, з якою буде тим або іншим чином взаємодіяти майбутнє програмне забезпечення і конкретизують його основні функції.
В сучасній практиці проектування ПЗ широко використовуються візуальні моделі, вони являють собою засоби для опису, проектування і документації архітектури системи. Один із авторитетніших спеціалістів в галузі об’єктно-орієнтованого підходу Граді Буч стверджував, що моделювання є центральною ланкою всієї діяльності по створенню якісного ПЗ. Моделі будуються для того, щоб зрозуміти й осмислити структуру та поведінку майбутньої системи, полегшити управління процесом її створення і зменшити ризик, а також задокументовувати прийняті проектні рішення. Хороші моделі служать основою взаємодії учасників проекту і гарантують коректність архітектури [29]. Розглянемо побудову таких моделей при структурному підході.
Ідеї, які лежать в основі структурного підходу
Методи структурного аналізу і проектування прагнуть подолати складність великих систем шляхом розчленовування їх на частини ("чорні ящики") і ієрархічній організації цих чорних ящиків. Перевага у використанні чорних ящиків полягає в тому, що їх користувачеві не потрібно знати, як вони працюють, необхідно знати лише його входи і виходи, а також його призначення (тобто функцію, яку він виконує).
На навколишньому світі чорні ящики зустрічаються у великій кількості. Проілюструємо переваги систем, складених з них, на прикладі музичного центру:
• Конструювання системи чорних ящиків істотно спрощується. Набагато легше розробити магнітофон або програвач, якщо не турбуватися про створення вбудованого підсилювального блоку.
• Полегшується тестування таких систем. Якщо з'являється поганий звук однієї з колонок, можна поміняти колонки місцями. Якщо несправність перемістилася з колонкою, то саме вона підлягає ремонту; якщо немає, тоді проблема в підсилювачі, магнітофоні або місцях їх з'єднання.
• Є можливість простої ре-конфігурації системи чорних ящиків. Якщо колонка несправна, то Ви можете відправити її до ремонтної майстерні, а самі поки продовжувати слухати свої записи в моно-режимі.
• Полегшується доступність для розуміння і освоєння. Можна стати фахівцем з магнітофонів без поглиблених знань про колонки.
• Збільшується зручність при модифікації. Ви можете придбати колонки вищої якості і могутніший підсилювач, але це зовсім не означає, що Вам необхідний великих розмірів програвач.
Таким чином, першим кроком спрощення складної системи є її розбиття на чорні ящики, при цьому таке розбиття повинне задовольняти наступним критеріям:
• кожен чорний ящик повинен реалізовувати єдину функцію системи;
• функція кожного чорного ящика повинна бути легко приємлива незалежно від складності її реалізації (наприклад, в системі управління ракетою може бути чорний ящик для розрахунку місця її приземлення: не дивлячись на складність алгоритму, функція чорного ящика очевидна - "розрахунок точки приземлення");
• зв'язок між чорними ящиками повинен вводитися тільки за наявності зв'язку між відповідними функціями системи (наприклад, в бухгалтерії один чорний ящик необхідний для розрахунку загальної заробітної плати службовця, а інший для розрахунку податків - необхідний зв'язок між цими чорними ящиками: розмір заробленої плати потрібний для розрахунку податків);
• зв'язки між чорними ящиками повинні бути простими, наскільки це можливо, для забезпечення незалежності між ними.
Другою важливою ідеєю, що лежить в основі структурних методів, є ідея ієрархії. Для того, щоб зрозуміти складну систему недостатньо розбити її на частини, необхідно ці частини організувати певним чином, а саме у вигляді ієрархічних структур. Всі складні системи Всесвіту організовані в ієрархії. Та і сама вона включає галактики, зоряні системи, планети ..., молекули, атоми, елементарні частинки. Людина при створенні складних систем також наслідує природі. Будь-яка організація має директора, заступників по напрямах, ієрархію керівників підрозділів, рядових службовців.
Третій момент: структурні методі широко використовують графічні нотації, які служать для полегшення поняття суті складних систем. Відомо, що "одна картинка вартує тисячі слів".