- •Вп нуБіП україни
- •Тема 1. Життєвий цикл програмних продуктів та архітектура, теорія і методи програмування. 7
- •Тема 7. Corba - технологія . 70
- •Тема 12. Тестування та налагодження програмних застосувань. 120
- •Поняття життєвого циклу програмного продукту.
- •Основні процеси життєвого циклу програмного продукту.
- •1.3. Допоміжні основні процеси (що підтримують) процеси життєвого циклу програмного продукту
- •1.4. Організаційні процеси життєвого циклу програмного продукту
- •1.5. Взаємозв'язок між процесами життєвого циклу програмного продукту
- •Лекція № 2
- •2.2. Визначення вимог до програмних продуктів.
- •2.3. Функціональні вимоги. Експлуатаційні вимоги.
- •2.3. Функціональна специфікація програмного засобу.
- •2.4. Вибір архітектури програмного забезпечення. Структура і формат даних.
- •2.5. Вертифікація -статичні, напівстатичні і динамічні структури. Класифікація структур даних.
- •2.6. Прості структури даних.
- •2.7. Статичні структури даних. Напівстатичні структури даних.
- •2.8. Динамічні структури даних
- •Лекція № 3
- •3.1. Загальна характеристика і компоненти проектування.
- •3.2. Еволюція розробки програмного продукту.
- •3.3. Структурне програмування. Об'єктно-орієнтоване проектування.
- •3.4. Збирані метрики, використовувані методи, стандарти і шаблони.
- •Лекція № 4
- •Зародження об' єктної моделі.
- •4.2. Об' єктно - орієнтований аналіз, дизайн і проектування.
- •4.3. Парадигми програмування.
- •4.4. Нові концепції програмування.
- •4.5. Об'єктно-орієнтоване програмування.
- •4.6. Уніфікована мова моделювання. Мови і платформи розробки.
- •4.7. Засоби розробки програмного забезпечення. Оптимальний порядок вивчення топ.
- •4.8. Об'єктно-орієнтований підхід. Характеристики об'єктно-орієнтованих мов
- •Лекція № 5
- •5.1. Особливості моделі клієнт сервер в sql Server.
- •5.2. Архітектура sql Server. Огляд компонентів і можливостей sql Server 7.0
- •5.3. Transact - sql. Додатки командного рядка. Додатки з графічним інтерфейсом
- •5.4. Архітектура баз даних. Реляційні особливості sql Server
- •Лекція № 6
- •План лекції
- •Самостійна робота
- •Зміст лекції
- •6.1. Вступ до компонентного програмування.
- •6.2. Основні поняття com технологій.
- •6.3. Інтерфейс com - об' єктів.
- •6.4. Ідентифікатори, використовувані в сом технології
- •Лекція № 7
- •7.1. Технологія corba.
- •7.2. Середовище Delphi. (смирнов 67)
- •7.3. Corba технології при програмуванні в середовищі Delphi.
- •7.4. Елементи ActiveX, що управляють.
- •Лекція № 8
- •8.1. Деякі теоретичні відомості про uml - уніфіковану мову моделювання.
- •8.2. Призначення мови uml.
- •8.3. Загальна структура мови uml.
- •8.4. Загальні відомості про пакети в мові uml. Основні пакети метамоделі мови uml.
- •8.5. Специфіка опису метамоделі мови uml.
- •8.6. Особливості зображення діаграм мови uml
- •Лекція № 9
- •9.1. Саsе - технології та саsе -засоби проектування.
- •9.2.Класифікація case -засобів.
- •9.3.Етапи створення інформаційних систем.
- •9.4.Моделі життєвого циклу програмного забезпечення іс
- •9.5.Особливості проектування інформаційних систем
- •Лекція № 10
- •10.1.Основні поняття про надійність програмних продуктів і методи її забезпечення.
- •10.2. Методи забезпечення надійності на різних етапах життєвого циклу розробки програмного продукту.
- •10.3. Інструменти, що забезпечують надійність програмних продуктів. План забезпечення надійності.
- •10.4. Основні поняття і показники надійності програмних засобів.
- •10.5. Дестабілізуючі чинники і методи забезпечення надійності функціонування програмних засобів.
- •Лекція № 11
- •11.1. Нормативні документи по стандартизації і відіа стандартів.
- •11.2. Стандарти в області програмного забезпечення.
- •11.3. Загальна характеристика стану в області документування програмних засобів.
- •11.4. Єдина система програмної документації гост 19.101-77 еспд.
- •11.5. Види програм і програмних документів.
- •11.6.Стадії розробки. Загальні вимоги до програмних документів. Технічне завдання.
- •11.7.Опис програми. Записка пояснення.
- •11.8.Керівництво системного програміста. Вимоги до змісту і оформлення.
- •11.9.Керівництво програміста. Керівництво оператора. Опис мови.
- •Лекція № 12
- •12.1. Основні визначення. Економіка тестування.
- •12.2. Тестування програми як "чорного ящика". Тестування програми як "білого ящика".
- •12.3. Аксіоми (принципи) тестування.
- •12.4. Філософія тестування.
- •12.5. Тестування модулів.
- •12.6.Покрокове тестування. Висхідне тестування. Низхідне тестування.
- •12.7.Метод "великого стрибка". Метод сандвіча. Модифікований метод сандвіча.
- •12.8.Комплексне тестування. Проектування комплексного тіста. Виконання комплексного тіста.
- •Лекція № 13
- •13.2. Серия стандартов isо 9000
- •13.4. Процес сертифікації програм на базі інформації про їх використання.
- •13.5. Супровід програм.
- •13.6.Види програмних документів. Записка пояснення.
- •13.7.Посібник користувача.
- •13.8.Керівництво системного програміста.
- •13.9. Атестація програмних засобів.
Лекція № 2
Тема 2. Архітектури програмних застосувань .
План лекції
1. Аналіз вимог і визначення специфікацій програмного забезпечення.
2. Визначення вимог до програмних продуктів.
3. Функціональні вимоги. Експлуатаційні вимоги.
Самостійна робота
4. Вибір архітектури програмного забезпечення. Структура і формат даних.
5. Статичні, напівстатичні і динамічні структури. Класифікація структур даних.
6. Прості структури даних.
7. Статичні структури даних. Напівстатичні структури даних.
8. Динамічні структури даних
Зміст лекції
2.1. Аналіз вимог і визначення специфікацій програмного забезпечення.
Архітектура ПС - це його будова як воно видно (чи повинно бути видно) из-вне його, тобто представлення ПС як системи, що складається з деякої сукупності взаємодіючих підсистем. Як такі підсистеми виступають зазвичай окремі програми. Розробка архітектури є першим етапом боротьби із складністю ПС, на якому реалізується принцип виділення відносно незалежних компонент.
Основні завдання розробки архітектури ПС :
виділення програмних підсистем і відображення на них зовнішніх функцій (заданих в зовнішньому описі) ПС;
визначення способів взаємодії між виділеними програмними підсистемами.
З урахуванням рішень, що приймаються на цьому етапі, виробляється подальша конкретизація і функціональних специфікацій.
2.2. Визначення вимог до програмних продуктів.
Для контролю архітектури ПС використовується суміжний контроль иручная імітація.
Суміжний контроль архітектури ПС згори - це її контроль розробниками зовнішнього опису : розробниками специфікації якості і розробниками функціональної специфікації. Суміжний контроль архітектури ПС знизу - це її контроль потенційними розробниками програмних підсистем, що входять до складу ПС відповідно до розробленої архітектури.
Ручна імітація архітектури ПС виробляється аналогічно ручній імітації функціональної специфікації, тільки метою цього контролю є перевірка взаємодії між програмними підсистемами. Так само як і у разі ручної імітації функціональної специфікації ПС мають бути спочатку підготовлені тести. Потім група розробників повинна для кожного такого тіста імітувати роботу кожної програмної підсистеми, що входить до складу ПС. При цьому роботу кожної підсистеми імітує один який-небудь розробник (не автор архітектури), ретельно виконуючи усі взаємодії цієї підсистеми з іншими підсистемами (точніше, з розробниками, що їх імітують) відповідно до розробленої архітектури ПС. Тим самим забезпечується імітаційне функціонування ПС в цілому у рамках архітектури, що перевіряється.
Визначення вимог до програмного засобу.
Визначення вимоги до ПС є початковим документом розробки ПС - завданням, що виражає в абстрактній формі потреби користувача. Вони у загальних рисах визначають задум ПС, характеризують умови його використання. Неправильне розуміння потреб користувача трансформуються в помилки зовнішнього опису. Тому розробка ПС починається із створення документу, достатній повно користувача, що характеризує потреби, і що дозволяє розробникові адекватно сприймати ці потреби.
Визначення вимог є сумішшю фрагментів на природній мові, різних таблиць і діаграм. Така суміш, має бути зрозумілою користувачеві, що не знає спеціальних позначень програмістів. Зазвичай у визначенні вимог не міститься формалізовані фрагменти, окрім випадків досить для цього підготовлених користувачів (наприклад, математично) - формалізація цих вимог складає зміст подальшої роботи колективу розробників.
Неправильне розуміння вимог замовником, користувачами і розробниками пов'язане зазвичай з різними поглядами на роль необхідного ПС в середовищі його використання. Тому важливим завданням при створенні визначення вимог є встановлення контексту використання ПС, що включає зв'язки між цим ПС, апаратурою і людьми. Краще всього цей контекст у визначенні вимог представити в графічній формі (у вигляді діаграм) з додаванням описів сутей використовуваних об'єктів (блоків ПС, компонент апаратури, персоналу і тому подібне) і характеристики зв'язків між ними.
Відомі три способи визначення вимог до ПС:
керований користувачем
контрольований користувачем
незалежний від користувача.
У керованій користувачем розробці визначення вимог до ПС визначаються замовником, що представляє організацію користувачів. Це відбувається зазвичай в тих випадках, коли організація користувачів (замовник) укладає договір на розробку необхідного ПС з колективом розробників і вимоги до ПС є частиною цього договору. Роль розробника ПС в створенні цих вимог зводиться, в основному, в з'ясуванні того, наскільки зрозумілі йому ці вимоги з відповідною критикою даного документу. Це може призводити до створення декількох редакцій цього документу в процесі укладення вказаного договору.
У контрольованій користувачем розробці вимоги до ПС формулюються розробником за участю представника користувачів. Роль користувача в цьому випадку зводиться до інформування розробника про свої потреби в ПС і контролю за тим, щоб формульовані вимоги дійсно виражали його потреби в ПС. Кінець кінцем розроблені вимоги, як правило, затверджуються представником користувача.
У незалежній від користувача розробці вимоги до ПС визначаються без якої-небудь участі користувача (на повну відповідальність розробника). Це відбувається зазвичай тоді, коли розробник вирішує створити ПС широкого застосування з розрахунку на те, розроблене їм ПС знайде попит на ринку програмних засобів.
З точки зору забезпечення надійності ПС найбільш прийнятною є контрольована користувачем розробка.