- •Вп нуБіП україни
- •Тема 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. Атестація програмних засобів.
13.7.Посібник користувача.
Призначена для користувача документація програмних засобів.
Призначена для користувача документація ПС (user documentation) пояснює користувачам, як вони повинні діяти, щоб застосувати це ПС. Вона потрібна, якщо ПС припускає яку-небудь взаємодію з користувачами. До такої документації відносяться документи, якими керується користувач при инсталяции ПС (при установці ПС з відповідним налаштуванням на середовище застосування ПС), при застосуванні ПС для вирішення своїх завдань і при управлінні ПС (наприклад, коли це ПС взаємодіє з іншими системами). Ці документи частково порушують питання супроводу ПС, але не торкаються питань, пов'язаних з модифікацією програм.
У зв'язку з цим слід розрізняти дві категорії користувачів ПС : ординарних користувачів ПС і адміністраторів ПС. Ординарний користувач ПС (end - user) використовує ПС для вирішення своїх завдань (у своїй предметній області). Це може бути інженер, що проектує технічний пристрій, або касир, що продає залізничні квитки за допомогою ПС. Він може і не знати багатьох деталей роботи комп'ютера або принципів програмування. Адміністратор ПС (system administrator) управляє використанням ПС ординарними користувачами і здійснює супровід ПС, не пов'язаний з модифікацією програм. Наприклад, він може регулювати права доступу до ПС між ординарними користувачами, підтримувати зв'язок з постачальниками ПС або виконувати певні дії, щоб підтримувати ПС в робочому стані, якщо воно включене як частина в іншу систему.
Склад призначеної для користувача документації залежить від аудиторій користувачів, на які орієнтоване це ПС, і від режиму використання документів. Під аудиторією тут розуміється контингент користувачів ПС, у якого є необхідність в певній призначеній для користувача документації ПС [13.2]. Вдалий призначений для користувача документ істотно залежить від точного визначення аудиторії, для якої він призначений. Призначена для користувача документація повинна містити інформацію, необхідну для кожної аудиторії. Під режимом використання документу розуміється спосіб, що визначає, яким чином використовується цей документ. Зазвичай користувачеві досить великих програмних систем потрібно або документи для вивчення ПС (використання у вигляді інструкції), або для уточнення деякої інформації (використання у вигляді довідника).
Відповідно до робіт [13.1, 13.2] можна вважати типовим наступний склад призначеної для користувача документації досить великих ПС:
Загальний функціональний опис ПС. Дає коротку характеристику функціональних можливостей ПС. Призначено для користувачів, які повинні вирішити, наскільки необхідно їм це ПС.
Керівництво по инсталяции ПС. Призначено для системних адміністраторів. Він повинен детально наказувати, як встановлювати системи в конкретному середовищі. Він повинен містити опис машинно-прочитуваного носія, на якому поставляється ПС, файли, представляючі ПС, і вимоги до мінімальної конфігурації апаратури.
Інструкція по застосуванню ПС. Призначена для ординарних користувачів. Містить необхідну інформацію по застосуванню ПС, організовану у формі зручної для її вивчення.
Довідник по застосуванню ПС. Призначений для ординарних користувачів. Містить необхідну інформацію по застосуванню ПС, організовану у формі зручної для виборчого пошуку окремих деталей.
Керівництво по управлінню ПС. Призначено для системних адміністраторів. Воно повинне описувати повідомлення, генеровані, коли ПС взаємодіє з іншими системами, і як реагувати на ці повідомлення. Крім того, якщо ПС використовує системну апаратуру, цей документ може пояснювати, як супроводжувати цю апаратуру.
Як вже говорилося раніше (див. лекцію 4), розробка призначеної для користувача документації починається відразу після створення зовнішнього опису. Якість цієї документації може істотно визначати успіх ПС. Вона має бути досить проста і зручна для користувача (інакше це ПС, взагалі, не варто було створювати). Тому, хоча чорнові варіанти (нариси) призначених для користувача документів створюються основними розробниками ПС, до створення їх остаточних варіантів часто притягуються професійні технічні письменники. Крім того, для забезпечення якості призначеної для користувача документації розроблений ряд стандартів, в яких наказує порядок розробки цієї документації, формулюються вимоги до кожного виду призначених для користувача документів і визначаються їх структура і зміст.