- •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.6.1. Покрокова розробка.
Переваги і недоліки моделі
Переваги:
-
менші часові розриви у взаємодії із замовником
-
можливість більш швидкого використання частин системи
-
гнучкість при затримках в роботі
-
якщо реалізація однієї частини затримується, це не зупиняє весь проект, це мотивує розробника працювати над іншими частинами швидше.
Недолік моделі - додаткова вартість, необхідна для незалежної реалізації частин системи. Практично неможливо зробити повністю незалежний набір функцій. При цьому може виникнути необхідність реалізувати скелети модулів, тобто моделі з інтерфейсами, що узгоджені зі всім системним інтерфейсом але не реалізовують їх функції до кінця. Реалізація цих модулів вимагає додаткового робочого навантаження і збільшує вірогідність помилок.
6. Збірка готових елементів
Модель збірки готових елементів акцентує увагу на можливості зменшити капітал, що витрачається на розробку шляхом максимізації схожості створеного ПЗ із вже існуючим.
Вже існуючі елементи можуть використовуватися на різних стадіях розробки. Зазвичай це етап реалізації.
Приклади використовуваних елементів:
-
бібліотеки
-
мови четвертого покоління, в яких інструкції обробляються як посилання на вбудовані бібліотеки
-
повні програми, наприклад браузер допомоги в MS Windows
Останнім часом підвищився інтерес до використання готових елементів на етапах аналізу і дизайну. CASE -Інструменти полегшують використання елементів, створених в інших проектах. Деякі компанії стверджують, що вони можуть використовувати до 90% готових продуктів. Очевидно, що можливість повторного використання залежить від схожості системних компонентів. Деякі компанії пропонують так званий інструментарій дизайну. Це вже готові методи для банків, страхових компаній і інших підприємств. Моделі реалізовуються у вигляді CASE -інструментарію.
Є два методи збірки готових компонентів:
-
придбання у зовнішніх постачальників
-
розробка біжучого проекту з розрахунком на його багатократне використання в наступних проектах
Переваги і недоліки моделі
Переваги використання готових компонентів:
-
висока надійність, - готові компоненти добре перевірені на практиці
-
зменшення ризику
-
ефективне використання експертів
-
стандартні вимоги. Готові компоненти реалізовувалися відповідно до деяких стандартів, які повинні бути задоволені в поточному проекті.
-
можливість зменшення ціни. Вартість нових компонентів зазвичай менша, ніж вартість розробки "з нуля".
Недоліками моделі є:
-
додаткова вартість створення компонентів для подальшого використання ( компоненти системи повинні бути розроблені для користування . Вартість інвестицій може не відшкодуватися в майбутньому).
-
Залежність від одного постачальника ( постачальник може перестати розробляти бібліотеку або не модифікувати її під нові вимоги ПЗ чи нову апаратуру).
-
Недолік інструментів, що підтримують роботу ( у разі CAD/CAM, які, як було згадано вище, служать в інших дисциплінах тієї ж мети, що і CASE, мають можливість використання бібліотек готових компонентів. Інструменти CASE підтримували в обмеженому об'ємі цей вид роботи до останнього часу. Сучасні інструменти кращі, але розробка нових все ще необхідна).