- •VIII. Розробка інтернет-програм
- •IX. БдБ і БдС системи
- •X. Реалізація
- •XI. Тестування
- •Введення в розробку програмного забезпечення
- •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. Документ з вимогами
- •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)
- •Формулювання вимог
- •Проект структури даних
- •Гіпертекстовий проект
- •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 Управління конфігурацією
- •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. Короткий звіт
2. Методи ідентифікації вимог
Найбільш важливі методи ідентифікації вимог:
-
Зустрічі і огляди (зустрічі повинні бути підготовлені у формі списку питань від різних сторін, що відносяться до даного проекти. Вони повинні проходити серед презентабельної групи користувачів, які прагнуть схвалення проекту).
-
Вивчення існуючого ПЗ (часто нове ПЗ замінює старе. Вивчення повинне визначати слабкі і сильні сторони старого ПЗ і погоджувати з ними нові вимоги, якщо система повинна бути частиною старої).
-
Вивчення досяжності (повинні бути визначені реалістичні цілі і методи).
-
Прототипування (проектування прототипів систем з меншим об'ємом і спрощеним інтерфейсом).
3. Методи опису вимог
Системні вимоги можуть бути документовані декількома способами.
Можливі методи:
-
Звичайна мова - найчастіше використовується. Незручності - в її невизначеності і гнучкості, що дає можливість описувати одне і те ж декількома шляхами. Зв'язки між різними вимогами не можуть бути визначені, і виникають суперечності.
-
Математичний формалізм – вживається рідше, ніж колись.
-
Структурована звичайна мова. Звичайна мова з обмеженим словником і семантикою. Предмети і проблеми описані в секціях і підсекціях.
-
Табліци, форми. Вимоги задані в таблицях (зазвичай двохрівневі), асоційовані різними зв'язками (наприклад, таблиця із зв'язками типів користувачів із сервісами).
-
Блоки і діаграми: графічні форми, що зображують процеси.
-
Контекстні діаграми: показують системи, оточення, входи і виходи.
-
Використання діаграм випадків: концептуальна презентація того, що відбувається, і функцій.
Використання діаграм випадків з асоціативними документами вважається одним з кращих методів документування вимог. Простота спілкування комбінується з точністю виразів, необхідною для майбутньої роботи над системою.
4. Типи вимог
Основні вимоги розділені на дві групи:
-
функціональні вимоги,
-
нефункціональні вимоги.
Функціональні вимоги
Описують функції (дії, операції) виконувані системою, що використовує зовнішні системи.
Функціональний опис вимог здійснює:
-
ідентифікація всіх типів користувачів системи,
-
ідентифікація всіх типів користувачів підтримки, таких як адміністратори, клерки,
-
визначення кожного типу користувачів всіх системних функцій і шляхів використання системи,
-
опис зовнішніх систем (бази даних, інтернету, мережі), що використовуються системою
-
визначення організаційних структур, законодавства, стратегій, і статусу, інструкцій, що прямо або непрямо описують функції.
Функціональні вимоги можуть бути сформульовані використовуючи шаблони вимог. Шаблон гарантує стандартне формулювання і полегшує підтвердження кінцевого результату.
Приклад формулювання вимог з використанням шаблону.
Назва функції |
Майстер обробки прибутку |
Опис |
Функція дозволяє редагувати прибуток платника податків заданого року |
Вхідні дані |
Дані про доходи, отримані з різних джерел, витрати на отриманий прибуток, податки на різні внески. Інформація про квитанції. Інформація та документи платника податків. |
Джерело вхідних даних |
Інформація податкової служби |
Результат |
|
Початкова умова |
Прибуток = весь прибуток - витрати на отриманий прибуток. Весь прибуток, прибуток і витрати на отримання прибутку - всі джерела прибутку. |
Кінцева умова |
Така ж, як зазначено вище |
Побічні ефекти |
Змінення бази оподаткування |
Причина |
Функція дозволяє робити розрахунки швидше і без помилок |
Таблиця 5.5.1.
Нефункціональні вимоги
Опис вимог вимагає від предмету, над яким будуть виконануватись певні функції:
-
вимога продуктів, наприклад, повинна бути доступна клавіатура,
-
вимога процесів, наприклад, процес планувальника повинен виконуватись за стандартом XXXA/06,
-
зовнішні вимоги, наприклад, система планування повинна використовувати маркетингове відділення баз даних описане в документі YYYB/95. Ніяких змін до бази даних не застосовано.
Хороша форма представлення нефункціональних вимог - це таблиця, наприклад:
№ |
Дата |
Автор |
Вимога |
Причина |
Примітки |
1 |
99/04/14 |
A.Nowak, J.Pietrjak |
Програма повинна видавати результат не більше, ніж через 5 секунд при роботі 100 користувачів одночасно |
Програма не буде конкурентоспроможною |
Може працювати нестабільно |
2 |
00/02/05 |
K.Lubicz |
Кожен клієнт повинен мати дуже коротку IP-адресу |
Інші ідентифікатори (SIN, Pesel) нестабільні, довгі, можуть повторюватися у різних користувачів |
|
3 |
... |
... |
... |
... |
... |
Малюнок 5.5.2.
Чинники нефункціональних вимог:
-
Системні функції: ієрархія функцій, що виконуються системою,
-
Об’єм: скільки користувачів працюватимуть одночасно? скільки терміналів буде встановлено? скільки сенсорів буде керовано? скільки інформації буде збережено?
-
Швидкість: час для виконання операції (або черги операцій), кількість операцій за одиницю часу, максимальний час виконання операції,
-
Точність: вимірювання масштабування і продуктивності, точність результату, заміна кількісних показників якісними,
-
обмеження: обмеження інтерфейсу, якості, блоку часу, устаткування, засобів програмування і т.п.,
-
Інтерфейс зв'язку: мережа, протоколи, представлення мережі, рівень абстракції, протоколів і т.п.,
-
Програмний інтерфейс: специфікація устаткування, фізичні обмеження, продуктивність (швидкість процесора, пам'ять), вимоги до офісу, вологість, температура, тиск
-
Програмний інтерфейс: сумісність з іншим ПЗ, ОС, мова програмування, компілятори, редактори, система управління базами даних (СУБД),
-
Взаємодія людини з системою: всі аспекти призначеного для користувача інтерфейсу, мова програмування, апаратне забезпечення (монітор, миша, клавіатура), формати (звіти, їх зміст), визначення повідомлень (мова, форма), допомога, повідомлення про помилки і т.п.,
-
Адаптивність: специфікація відповіді системи на зміни - нові команди, нове вікно і т.п.,
-
Безпека: конфіденційність, приватність, інтеграція, специфікація надійності і т.п.,
-
Гнучкість невдач: наслідки помилок ПЗ, помилка живлення, частота збережень, зміна розкладу і т.п.,
-
Стандарти: специфікація стандартів документів, форматів файлів, розміри шрифтів, стандарти процесів і продуктів і т.п.,
-
Ресурси: бюджет, людський ресурс і обмеження матеріальних ресурсів,
-
Час: необхідний час для створення системи, тренування і установки.