- •Вп нуБіП україни
- •Тема 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. Атестація програмних засобів.
11.3. Загальна характеристика стану в області документування програмних засобів.
Створення програмної документації - важливий етап, оскільки користувач починає своє знайомство з програмним продуктом саме з документації. Для чого призначений програмний продукт, як встановити програмний продукт, як почати з ним працювати - ось одні з перших питань, на які повинна відповідати програмна документація (Installation Guide, Getting Started). Складанням програмної документації зазвичай займаються спеціальні люди - технічні письменники (іноді програмну документацію пишуть самі програмісти або аналітики). Цей етап є найнеприємнішим і важчим в роботі програміста. На жаль, зазвичай цьому або не учать зовсім, або у кращому разі не обертають на якість отримуваних документів належної уваги. Проте володіння цим мистецтвом є одним з найважливіших чинників, що визначають якість програміста.
Уміння створювати програмну документацію визначає професійний рівень програміста. Замовник не вникатиме в тонкощі і особливості навіть найчудовішої програми. Замовник спочатку читатиме документацію. Велику роль грає в цьому і психологічний чинник.
Грамотно складений (точніше, створений) пакет програмної документації позбавить вас від багатьох прикростей. Зокрема, позбавитися від настирних питань і необгрунтованих претензій можна, просто відіславши користувача до документації. Це стосується раніше усього найважливішого документу - Технічного завдання. Можна нагадати про багатомільйонний позов до компанії IBM, який пред'явило одне велике видавництво, не задоволене якістю обчислювальної техніки і програмного забезпечення. IBM суд виграла тільки завдяки тому, що пред'явила підписане обома сторонами Технічне завдання. Було це давно, ще в 70-х роках 20 віків, проте суті справи це не міняє. На заході важливість програмної документації зрозуміли давно, разом з програмним забезпеченням поставляється цілий пакет документації.
Взагалі програмну документацію можна розділити по відношенню до користувача на внутрішню і зовнішню. Зовнішня - всіляке керівництво для користувачів, технічне завдання, довідники; внутрішня документація - та, яка використовується в процесі розробки програмного забезпечення і недоступна кінцевому користувачеві (різні внутрішні стандарти, коментарі початкового тексту, технології програмування і так далі).
Коли програміст-розробник отримує в тій або іншій формі завдання на програмування, перед ним, перед керівником проекту і перед усією проектною групою встають питання:
Що має бути зроблене, окрім власне програми?
Що і як повинно бути оформлено у вигляді документації?
Що передавати користувачам, а що - службі супроводу?
Як управляти усім цим процесом?
Що повинне входити в само завдання на програмування?
На ці і інші питання колись відповідали державні стандарти на програмну документацію - комплекс стандартів 19-ої серії ГОСТ ЕСПД. Але вже тоді у програмістів була маса претензій до цих стандартів. Щось вимагалося дублювати в документації багато разів (як виявився - невиправдано), а багато що не було передбачено, як, наприклад, віддзеркалення специфіки документування програм, що працюють з інтегрованою базою даних.
Пройшло багато років, програмування відбувається в середовищі абсолютно нових технологій, багато програмістів, працюючи в стилі drag - and - drop, можуть роками не бачити текстів своїх програм. Це не означає, що зникла необхідність в їх документуванні. Питання про наявність хоч якоїсь системи, що регламентує цю сторону створення програмних засобів, продовжують задавати постійно.
Загальна характеристика стану в області документування програмних засобів Основу вітчизняної нормативної бази в області документування ПС складає комплекс стандартів Єдиної системи програмної документації (ЕСПД). Основна і велика частина комплексу ЕСПД була розроблена в 70-і і 80-і роки 20 віків. Зараз цей комплекс є системою міждержавних стандартів країн СНД (ГОСТ), діючих на території Російської Федерації на основі міждержавної угоди по стандартизації.
Єдина система програмної документації - це комплекс державних стандартів, що встановлюють взаємопов'язані правила розробки, оформлення і звернення програм і програмної документації.
Стандарти ЕСПД в основному охоплюють ту частину документації, яка створюється в процесі розробки ПС, і пов'язані, здебільшого, з документуванням функціональних характеристик ПС. Слід зазначити, що стандарти ЕСПД (ГОСТ 19) носять рекомендаційний характер. Втім, це відноситься і до усіх інших стандартів в області ПС (ГОСТ 34, міжнародному стандарту IS0/ІЕС та ін.). Річ у тому, що відповідно до Закону РФ "Про стандартизацію" ці стандарти стають обов'язковими на контрактній основі, тобто при посиланні на них в договорі на розробку (постачання) ПС.
До складу ЕСПД входять:
засадничі і організаційно-методичні стандарти;
стандарти, що визначають форми і зміст програмних документів, вживаних при обробці даних;
стандарти, що забезпечують автоматизацію розробки програмних документів.
Говорячи про стан ЕСПД в цілому, можна констатувати, що велика частина стандартів ЕСПД морально застаріла.
До основних недоліків ЕСПД можна віднести:
орієнтацію на єдину "каскадну" модель життєвого циклу ПС;
відсутність чітких рекомендацій по документуванню характеристик якості ПС;
відсутність системної ув'язки з іншими діючими вітчизняними системами стандартів по ЖЦ і документуванню продукції в цілому, наприклад ЕСКД;
нечітко виражений підхід до документування ПС як товарної продукції;
відсутність рекомендацій по самодокументуванню ПС, наприклад, у вигляді екранних меню і засобів оперативної допомоги користувачеві (хелпов);
відсутність рекомендацій по складу, змісту і оформленню перспективних документів на ПС, узгоджених з рекомендаціями міжнародних і регіональних стандартів.
ЕСПД потребує повного перегляду на основі стандарту ИСО/МЭК 12207-95 на процеси життєвого циклу ПС.
Проте до перегляду усього комплексу багато стандартів можуть з користю застосовуватися в практику документування ПС. Ця позиція заснована на наступному:
стандарти ЕСПД вносять елемент впорядкування в процес документування ПС;
передбачений стандартами ЕСПД склад програмних документів зовсім не такий "жорсткий", як деяким здається: стандарти дозволяють вносити в комплект документацію на ПС додаткові види програмних документів (ПД), необхідних в конкретних проектах, і виключати багато ПД;
стандарти ЕСПД дозволяють на додаток мобільно змінювати структури і зміст встановлених видів ПД виходячи з вимог замовника і користувача.
При цьому стиль застосування стандартів може відповідати сучасному загальному стилю адаптації стандартів до специфіки проекту : замовник і керівник проекту вибирають доречну в проекті підмножину стандартів і ПД, доповнюють вибрані ПД потрібними розділами і виключають непотрібні, прив'язують створення цих документів до тієї схеми ЖЦ, яка використовується в проекті.
Слід сказати, що разом з комплексом ЕСПД офіційна нормативна база РФ в області документування ПС і в суміжних областях включає ряд перспективних стандартів (вітчизняного, міждержавного і міжнародного рівнів).
Міжнародний стандарт IS0/IЕС 12207:1995 на організацію ЖЦ продуктів програмного забезпечення (ПО), здавалося б, дуже неконкретний, але цілком новий і частково "модний" стандарт.
Стандарти комплексу ГОСТ. 34 на створення і розвиток автоматизованих систем - узагальнені, але сприймані як дуже жорсткі по структурі ЖЦ і проектній документації. Але ці стандарти багатьма вважаються бюрократичними до шкідливості і консервативними до застарівання.