- •Вп нуБіП україни
- •Тема 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. Атестація програмних засобів.
10.4. Основні поняття і показники надійності програмних засобів.
Основні поняття надійності систем. За визначенням, встановленим в ГОСТ 13377-75, надійність - властивість об'єкту виконувати задані функції, зберігаючи в часі значення встановлених експлуатаційних показників в заданих межах, відповідних заданим режимам і умовам використання, технічного обслуговування, ремонту, зберігання і транспортування. Таким чином, надійність є внутрішньою властивістю системи, що закладеною при її створенні і проявляється в часі при функціонуванні і експлуатації.
Р. Гласс надійність визначає як рівень, при якому система програм задовольняє поставленим вимогам і придатна для експлуатації. При цьому слід відрізняти надійність від коректності, яка визначається як міра задоволення вимогам. Надійність є складовою частиною загальнішого поняття - якості. Якісна програма не лише надійна, але і компактна, сумісна з іншими програмами, ефективна, зручна в супроводі, портативна і цілком зрозуміла [46].
Властивості надійності виробів вивчаються теорією надежное- ти, яка є системою певних ідей, математичних моделей і методів, спрямованих на рішення проблем пророцтва, оцінки і оптимізації різних показників надійності. Надійність технічних систем визначається в основному двома чинниками: надійністю компонентів і дефектами в кон- струкции, допущеними при проектуванні йди виготовленні. Відносно невисока фізична надійність компонентів, їх здатність до руйнування, старіння або зниження надійності в процесі експлуатації привели до того, що цей чинник виявився домінуючим для більшості комплексів апаратури. Цьому сприяла також невисока складність багатьох технічних систем, внаслідок чого дефекти проектування проявлялися відносно рідко.
Надійність складних програмних засобів визначається цими ж чинниками, проте домінуючими є дефекти і помилки проектування, оскільки фізичне зберігання програм на магнітних носіях характеризується дуже високою надійністю. Програма будь-якої складності і призначення при строго фіксованих початкових даних і абсолютно надійній апаратурі виконується по однозначно певному маршруту і дає на виході строго певний результат. Проте випадкова зміна початкових даних і накопиченої при обробці інформації, а також безліч умовних переходів в програмі створюють величезне число різних маршрутів виконання кожного складного ПС. Джерелами ненадійності є неперевірені поєднання початкових даних, при яких функціонуюче ПС дає невірні результати або відмови. В результаті комплекс програм не відповідає вимогам функціональної придатності і працездатності.
Наведемо приклад, який опублікований в статті Юрія Батурина в журналі "Новий час" [57]. Автор приводить декілька чинників, які описують проблеми функціонування складних програмних засобів. Так, одним з чинників виступає чинник складності. "Існують фундаментальні причини, чому програмне забезпечення неможливо зробити досить надійним, щоб можна було не сумніватися в тому, що система "Зоряних воєн" дійсно спрацює", -г рахує Д. Парнас, найбільший авторитет по великомасштабному програмуванню. Він був призначений Організацією по здійсненню Стратегічної Оборонної Ініціативи (СОЇ) членом консультативного комітету з програмування управління бойовими операціями. "Мені обіцяли 1000 доларів в день плюс накладні витрати". Але, ознайомившись детальніше з тим, чого від нього чекають, Д. Парнас відхилив зроблену йому пропозицію, одночасно представивши вісім технічних документів, які пояснювали, чому програма не зможе працювати так, як вимагається. Як приклад приведемо ще один з чинників - чинник надійності. Про те, наскільки уразливе математичне забезпечення, можна судити по наступному прикладу. Коли в 1979 р. американський космічний зонд, запущений на Венеру, не досяг своєї мети, в космос вилетіло майже півмільярда доларів. Причина в тому, що в програмі корекції курсу зонду кома була сплутана з двокрапкою.
При застосуванні понять надійності до програмних засобів слід враховувати особливості і відмінності цих об'єктів від традиційних технічних систем, для яких спочатку розроблялася теорія надійності, :
не для усіх видів програм застосовні поняття і методи теорії надійності - їх можна використовувати тільки до програмних засобів, що функціонують в реальному часі і що безпосередньо взаємодіє із зовнішнім середовищем;
при оцінці якості програмних компонентів до них непридатні поняття надійності функціонування, якщо при обробці інформації вони не використовують значення реального часу і не взаємодіють безпосередньо із зовнішнім середовищем;
домінуючими чинниками, що визначають надійність програм, являються дефекти і помилки проектування і розробки, і другорядне значення має фізичне руйнування програмних компонентів при зовнішніх діях;
відносне рідкісне руйнування програмних компонентів і необхідність їх фізичної заміни призводять до принципової зміни понять збою і відмови програм і до розподілу їх по тривалості відновлення відносно деякого допустимого часу простою для функціонування інформаційної системи;
для підвищення надійності комплексів програм особливе значення мають методи автоматичного скорочення тривалості відновлення і перетворення відмов в короткочасні збої шляхом введення в програмні засоби тимчасової, програмної і інформаційної надмірності;
непередбачуваність місця, часу і вірогідності прояву дефектів і помилок, а також їх рідкісне виявлення при реальній експлуатації досить надійних програмних засобів, не дозволяють ефективно використовувати традиційні методи апріорного розрахунку показників надійності складних систем, орієнтовані на стабільні, вимірювані значення надійності складових компонентів;
традиційні методи форсованих випробувань надійності систем шляхом фізичної дії на їх компоненти непридатні для програмних засобів, і їх слід замінювати на методи форсованої дії інформаційних потоків зовнішнього середовища.