ТПСПП Конспект лекцій

Лекція 1-2. Вступ. Мета і завдання предмету. Структура систем обробки інформації.

Життєвий цикл програмних продуктів.

Каскадна модель, модель водоспаду, модель водоспаду із зворотнім зв’язком.

Сучасні технології програмування

Етапи розвитку мов програмування.

Розвиток мов програмування можна розглядати у вигляді етапів, кожний із яких характеризується певними ознаками. Початковий етап (1950-1960 р.) характеризується тим, що в основі засобів взаємодії людини й ЕОМ лежали мови, у яких програмування велося в термінах машинних кодів. Взаємодія програмістів з ЕОМ здійснювалося в діалоговому монопольному режимі. На цьому і наступних етапах (до появи інтелектуальних мов високого рівня) ЕОМ були доступні тільки професіоналам-програмістам. У ці роки почалося створення мов алгоритмічного типу.

Другий етап розвитку середовища програмування (I960 - 1970 роки) характеризувався створенням операційних систем, які дозволяли опрацьовувати декілька завдань, сформованих різними користувачами. Основна мета розробок на цьому етапі полягала в забезпеченні найбільшого завантаження машинних ресурсів. Почали використовувалися алгоритмічні мови, орієнтовані на ту або іншу предметну сферу.

Третій етап характерний якісною зміною критерію ефективності автоматизованого опрацювання даних. Якщо на перших етапах у якості такого критерію виступали (як видно, у силу обмеженої сфери використання ЕОМ) машинні ресурси, то далі основними стали людські ресурси, що здійснюють розробку і супровід програмного забезпечення. Сфера використання обчислювальної техніки до цього часу була вже достатньо велика і містила в собі ряд складних задач і проблем. Крім того, стали розроблятися і впроваджуватися в практику не тільки великі, але і дешевші міні ЕОМ, що дозволило в основному вирішити проблему необхідних обчислювальних ресурсів. З метою швидшої розробки програмного забезпечення на цьому етапі використовувався інтерактивний режим взаємодії декількох користувачів з ЕОМ, підтримуваний діалоговими операційними системами. Проте в цілому зростаючий рівень технології розробок програмного забезпечення ще не дозволив вирішити проблему людських ресурсів. Розрив між обсягами автоматизації і загальною кількості програмістів продовжував зростати.

Четвертий етап знаменує новий якісний стрибок у технології розробки програмного забезпечення, що відчиняє можливість рішення зазначеної проблеми. Його суть зводиться до того, що центр ваги технологічних рішень переноситься на створення засобів, що забезпечують взаємодію користувачів з ЕОМ на етапах створення програмного продукту. Ключовою ланкою нової інформаційної технології стає представлення та опрацювання знань. Розваються мови представлення знань, що дозволяє користувачам безпосередньо вносити свої знання в ЕОМ і надалі використовувати їх для вирішення конкретних задач. Індустрія знань стала широко впроваджуватися в різноманітні області створення прикладних інформаційних систем - створюються інтелектуальні пакети прикладних програм, бази даних, експертні системи. Цей етап характеризується також створенням і використанням персональних комп’ютерів. Створюються технічні передумови для застосування комп’ютера у широкому масштабі безпосередньо споживачами інформації - користувачами.

Можливості нової інформаційної технології “проникають“ у всі сфери інформаційної індустрії. Зараз широко використовуються мережі ЕОМ, що інтегрують розподілені бази знань. Їхнє створення забезпечує доступ до необхідної інформації в будь-якій точці Землі і дозволяє вирішити всі проблеми, починаючи від створення відповідних технічних засобів, що забезпечують передачу й опрацювання інформації, і закінчуючи мовними засобами взаємодії людини та ЕОМ.

Об’єктно-орієнтовані технології.

Суть об’єктно-орієнтованого програмування виражається формулою “об’єкт це дані плюс процедури“. Об’єкт інтегрує деякий стан (або структуру даних) і доступні тільки йому механізми керування ним. Багато об’єктно-орієнтованих мов мають засоби для об’єднання об’єктів у класи. Це дозволяє зберігати процедури (у термінах об’єктно-орієнтованого програмування - методи), застосовувані до всіх об’єктів цього класу, в єдиному примірнику, лише у відповідному класі. Засоби візуального програмування розширили поняття “об’єкт“. Об’єкт - це деяка річ, із якою можна щось робити, і яка може бути видимою або ж ні. Видимим об’єктом може бути рамка, кнопка, автономний модуль та інше. Завдяки засобам візуальної розробки можна працювати з видимим об’єктом, тримаючи його перед очима й одержуючи результати практично відразу.

Об’єкти можуть реагувати на події і мати властивості - атрибути, що детально описують його структуру. Наприклад, об’єкт типу “людина“ має властивості “вік“, “адреса“ та інші. Всі об’єкти, як правило, можуть реагувати на події, ініційовані користувачами або системою.

Поняття про CASE-технології.

CASE-технології – не революція в автоматизації проектування автоматизованих інформаційних систем, а результат природного еволюційного розвитку усієї галузі засобів, які раніше називалися інструментальними або технологічними. Однією з ключових ознак є підтримка методологій структурного системного аналізу і проектування.

Важливий напрям в розвитку технологій склали розробки інтегрованих інструментальних засобів, які базуються на концепціях життєвого циклу і управління якістю автоматизованих інформаційних технологій і систем, які являють собою комплексні технології, орієнтовані на створення складних автоматизованих управлінських систем і підтримку їх повного життєвого циклу або ряду його основних етапів. Подальший розвиток робіт в цьому напрямку привело до створення ряду концептуально цілісних, оснащених високошвидкісними засобами проектування і реалізації варіантів, доведених по якості і легкості тиражування до рівня програмних продуктів технологічних систем, які отримали назву CASE-систем або CASE-технологій (Computer-Aided Software/System Engeneering).

На даний час не існує загальноприйнятого визначення CASE-технологій. Зміст цього поняття здебільшого визначається переліком завдань, які вирішуються з допомогою CASE-технологій, а також сукупністю методів і засобів, які при цьому застосовуються. CASE-технологія охоплює сукупність методів аналізу, проектування, розробки і супроводження автоматизованої інформаційної системи, підтриманої комплексом взаємозв’язаних засобів автоматизації. CASE-технології - це інструментарій для системних аналітиків, розробників і програмістів, який дозволяє автоматизувати процес проектування і розробки автоматизованих інформаційних систем і який міцно ввійшов в практику їх створення і супроводу. При цьому CASE-технології використовуються не тільки, як комплексні технологічні конвеєри для виробництва автоматизованих інформаційних систем, але і, як потужний інструмент вирішення дослідницьких і проектних задач, таких, як структурний аналіз предметної області, специфікація проектів засобами мов програмування четвертого покоління, випуск проектної документації, тестування реалізацій проектів, планування і контроль розробок, моделювання ділових прикладних пакетів з метою розв’язку задач оперативного і стратегічного планування і управління ресурсами та інших. Основна мета CASE-технології полягає в тому, щоб відділити проектування автоматизованих інформаційних систем від її кодування і наступних етапів розробки, а також максимально автоматизувати процеси розробки і функціонування систем.

Сфера застосування CASE-технологій.

При використанні CASE-технологій змінюється технологія проведення робіт на всіх етапах життєвого циклу автоматизованих систем і технологій, при цьому найбільші зміни стосуються етапів аналізу і проектування. В більшості сучасних CASE-технологій застосовуються методології структурного аналізу і проектування, які базуються на наочних діаграмних технічних підходах, при цьому для опису моделі проектованої автоматизованої інформаційної системи використовуються графи, таблиці і схеми. Такі методології забезпечують строгий і наочний опис проектованої системи, який починається з її загального огляду і потім деталізується, набуваючи ієрархічної структури з все більшою кількістю рівнів.

CASE-технології успішно застосовуються для побудови практично усіх типів автоматизованих інформаційних систем, однак стійку позицію вони займають в галузі забезпечення розробки ділових і комерційних автоматизованих інформаційних систем. Широке застосування CASE-технологій обумовлено масовістю цієї прикладної області, в якій вони застосовуються не тільки для розробки автоматизованої інформаційної системи, але і для створення моделей систем, що допомагають комерційним структурам вирішувати задачі стратегічного планування, управління фінансами, визначення політики організацій, навчання персоналу та інші. Цей напрям отримав свою власну назву – бізнес-аналіз. Наприклад, для якнайшвидшої і ефективної розробки високоякісної банківської системи фінансисти все частіше звертаються до використання CASE-технології. Постачальники цієї технології, враховуючи зацікавлення фінансистів, швидко розширюють ринок засобів. Швидкому впровадженню CASE-технології сприяє також ускладнення банківських систем.

Переваги CASE-технологій.

З самого початку метою розвитку CASE-технологій було подолання обмежень при використанні структурних методологій проектування 1960 - 1970-х рр. (складності розуміння, великої трудомісткості і вартості використання, складності внесення змін в проектні специфікації і т.д.) за рахунок їх автоматизації і інтерпретації підтримуючих засобів. Таким чином, CASE-технології не можуть вважатися самостійними методологіями, вони тільки розвивають структурні методології і роблять ефективнішим їх застосування за рахунок автоматизації.

Крім автоматизації структурних методологій і, як наслідок, можливості застосування сучасних методів системної і програмної інженерії, CASE-технологіям притаманні такі переваги:

· покращують якість створюваних автоматизованих інформаційних систем за рахунок засобів автоматичного контролю (перш за все, контролю проекту);

· дозволяють за короткий час створювати прототип майбутньої автоматизованої інформаційної системи, що дає можливість на ранніх етапах оцінити очікуваний результат;

· прискорюють процес проектування і розробки системи;

· звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки;

· підтримують розвиток і супроводження розробки автоматизованої інформаційної системи;

· підтримують технології повторного використання компонентів розробки.

Більшість CASE-засобів грунтуються на науковому підході, який отримав назву “методологія - метод - нотація – засіб“. Методологія формулює керівні вказівки для оцінки і вибору проекту автоматизованої інформаційної системи, що розробляється, кроки роботи і їх послідовності, а також правила застосування і призначення методів.

На даний час CASE-технологія оформилася в самостійний наукомісткий напрям, що призвело до створення потужної CASE-індустрії, яка об’єднує сотні фірм і компаній різноманітної орієнтації. Серед них виділяються компанії - розробники засобів аналізу і проектування автоматизованих інформаційних систем з широкою мережею дистриб’юторських і дилерських фірм; фірми - розробники спеціальних засобів з орієнтацією на вузькі предметні ділянки або на окремі етапи життєвого циклу автоматизованої інформаційної системи; навчаючі фірми, які організовують семінари і курси підготовки спеціалістів; консалтингові фірми, які надають практичну допомогу при використанні CASE-пакетів для розробки конкретних автоматизованих інформаційних систем; фірми, що спеціалізуються на видавництві періодичних журналів і бюлетенів по CASE-технологіях. Практично жоден серйозний зарубіжний проект автоматизованої інформаційної системи не здійснюється в даний час без використання CASE-засобів.

У не професійних розробників програмних продуктів існує думка, що можна розробити якийсь один універсальний метод, який забезпечить розробку програмного забезпечення тривіально. Практики в області професійної розробки програмного забезпечення знають, що ніяких універсальних методів не існує.

З кожним роком програмне забезпечення стає все більш складним, об’ємним та вимагає більших капітальних затрат. Програмне забезпечення, як правило, створюється великими командами професіоналів, які представляють різні сфери інтересів часто далекі від комп’ютерних наук.

Під час розробки програмного забезпечення виникають наступні питання:

1. Складність програмного забезпечення

2. Як організувати командну роботу

3. Як оптимально організувати спілкування у групі професіоналів різних дисциплін

4. Які методи необхідно використовувати щоб виконати якісний і не дуже дорогий програмний продукт в необхідні терміни

Рішення всіх цих питань приводить до успішної розробки програмного забезпечення.

Складність інформаційних систем.

На сьогодні інформаційні системи, які мають практичний інтерес є складними, вимагають, в процесі розробки, багато часу, значних коштів і нажаль, у більшості випадків, вони є незадовільні. Аналіз ринку розробки програмного забезпечення показує, що зі всіх проектів, що розробляються, лише третина є успішною.

Причини складності програмного забезпечення:

1. Велика кількість напрямків в інформаційних технологіях

2. Складнощі спілкування членів однієї команди різних напрямків

3. Динамічні зміни в технологіях та доступних технічних і програмних засобах

4. Зміна вимог коритсувача і непевність в процесі формулювання вимог

Розробка програмного забезпечення

Розробка ПЗ не у всіз випадках є успішною, тому в процесі розробки виникають наступні питання:

1. Що необхідно зробити, щоб підвищити шанси успішності розробки ПЗ?

2. Як бути впевненим в тому, що результати роботи задовільнять користувача?

3. Як перевірити безпомилковість ПЗ?

4. Як сформулювати вимоги до продукту, щоб ці вимоги були зрозумілі для замовника, який не завжди має великий досвід роботи з ПЗ і з другої строни, щоб ці вимоги були чіткими, зрозумілими та досяжними в процесі моделювання та програмування?

На всі ці питання намагається знайти відповідь практична дисципліна «ТПСПП». ТПСПП охоплює всі етапи розробки системи.

ТПСПП включає в себе:

1. Методи управління під час розробки ПЗ

2. Технології планування розробки

3. Оцінки ціни або вартості розробки

4. Розклад проведення робіт

5. Та моніторинг процесу розробки ПЗ

6. Аналіз різних методів проектування системи

7. Технології підвищення надійності ПЗ

8. Методи підготовки технічної і користувацької документації

9. Аналіз процедур контролю якості

10. Різні методи зменшення витрат на підтримку, усунення неполадок, модифікацію ПЗ

11. Технології командної роботи та різні аспекти, які впливають на командну роботу

Останнім часом на розробку програмних продуктів спостерігають кризу пов’язану з розробкою ПЗ. До основних причин кризи відносять:

1. Постійно зростаюча складність ПЗ та складність процесу їх розробки

Якщо провести детальний аналіз причин кризи, то можна виділити наступні їх аспекти:

1. Невідповідність, а іноді суперечність між очікуваною ефективністю систем та її надійністю (причиною цього є складність розроблюваних систем та не ідеальність методів її створення)

2. Вартісна підтримка систем

3. Рідкісне повторне використання вже існуючих проектів і компонентів ПЗ в нових розробках (це пов’язане із специфікою розробки систем)

4. Тривалий і дорогий цикл розробки ПЗ (тому існують великі шанси, що проект буде незавершений)

5. Практична необхідність робити зміни та оновлювати систему

6. Велика кількість та специфіка мов програмування, які використовуються в процесі розробки

7. Велика залежність результатів роботи від зміни методів, пристроїв, та інших умов, які безпосередньо впливають на розробку

8. Проблеми, які пов’язані з інтеграцією готових компонентів розроблених різними командами

На практиці всі ці явища намагаються обмежити завдяки:

1. різних методів та інструментів, що полегшують роботу зі складними системами

2. використання методів аналізу нових проблем, які можуть виникнути в процесі розробки

На практиці намагаються процедури розробки ПЗ зробити систематизованими, спланованими та керованими.

Переконання як виробників так і покупців, що в розроблення сучасної, надійної, ефективної системи вимагає відповідних капіталовкладень.

Одним із методів подолання кризи є концептуальне моделювання.

Концептуальні процеси моделювання інформації, процеси обробки інформації, структуру даних та структуру програм. Зміст концептуального моделювання полягає в аналізі і представлення системи пов’язаної з розробкою ПЗ.

Процес побудови концептуальної моделі стосується:

1. сприйняття світу (як ми бачимо систему в використанні (цілі, задачі) )

2. аналітична модель реальної (що би мало входити в систему)

3. модель структури даних та процесів (те що треба виконати, реалізувати)

Життєві цикли ПЗ

На практиці існують дві базові моделі:

1. класична модель водоспаду (каскадна модель)

2. спіральна модель

На базі цих двох моделей розроблено цілий ряд інших, допоміжних моделей життєвого циклу. Розробка та експлуатація ПЗ – це процеси, які на практиці повинні бути систематизованими. Для цього використовують різні моделі життєвого циклу ПЗ. Ці моделі представляють етапи життя ПЗ, дії, які проводяться на кожному етапі, та визначають черговість виконання цих етапів.

Модель водоспаду (каскадна або лінійна модель) – є класичною моделлю життєвого циклу ПЗ. Ця модель була розроблена по аналогії з методами, які використовуються в інших технічних дисциплінах (при проектуванні будівель)

Каскадна модель передбачає наступні етапи розробки ПЗ:

1. Визначення вимог – на цьому етапі формулюються цілі майбутньої системи та основні її аспекти

2. Проектування – проводиться по всіх елементах системи аж до конкретних об’єктів або елементів, які можна реалізувати і основна мета цього етапу – спроектувати систему, яка б відповідала заданим вимогам

3. Реалізації – на даному етапі відбувається написання коду, реалізація дизайну системи та тестування модулів

4. Тестування – об’єднання системи в єдине ціле та загальне тестування системи

5. Підтримка – цей етап пов’язаний з періодом, коли замовник експлуатує програмний продукт, а виробник його підтримує (обслуговує). В процесі підтримки замовник може попросити внести зміни в систему або доповнити її.

На практиці також використовують інші розбиття циклів, але стосовно каскадної моделі найважливішим залишається лінійність процесу розробки (його послідовність).

В приведеній каскадній моделі крім вказаних етапів також можуть бути присутні інші етапи:

1. Стратегічний – цей етап виконується перед формальним ухваленням рішень про взяття системи на розробку. Він полягає в прийнятті певних стратегічних рішень про майбутню роботу над системою. Для виконання цього етапу необхідно мінімально сформулювати вимоги до майбутньої системи

2. Аналізу – на цьому етапі будується аналітична (логічна) модель системи

3. Документування – на цьому етапі відбувається виготовлення всієї документації призначеної для користувача

4. Установка – на цьому етапі система передається користувачу. Цей етап йде після тестування перед підтримкою

Переваги каскадної моделі:

Основна перевага каскадної моделі – керованість розробкою. Така модель значно полегшує планування розробки та її моніторинг.

Недоліки каскадної моделі:

1. Необхідність чіткого дотримання встановленого порядку проведення роботи

2. Підвищення ціни розробки в наслідок помилок зроблених на різних етапах розробки

3. Тривалий період, під час якого замовник немає контакту з розробником і навпаки. Оскільки при такій моделі розробки лише на стратегічному етапі, на етапі формулювання вимог і на етапі установки проходить безпосередня робота з замовником. За виконання всіх інших етапів несе відповідальність розробник

Модель водоспаду із зворотними зв’язками

Малюнок не повний – повинні бути зворотні зв’язки (стрілки) від поточного етапу до всіх попередніх.

Для зменшення ваги помилок на всіх етапах розробки системи на практиці використовують модель водоспаду із зворотними зв’язками. Ідея моделі полягає в тому, що існує можливість повернутись на будь-який попередній етап розробки системи. Недоліком такої системи є: зменшення прогнозованості розробки системи, тобто важче спланувати терміни та об’єми робіт на кожному етапі.

Документоване виконання

Була розроблена військовим відомством США. Під час військових розробок було оцінено, що ПЗ вимагає великих коштів, тривалих часів розробки і як результат мільйонів рядків коду. Тому виникла необхідність використовувати модель в розробці, яка забезпечить ефективну розробку саме таких проектів. Військові розробили певні стандарти та моделі розробки для забезпечення саме своїх потреб. Одним із них є метод документованого виконання. Життєвий цикл ПЗ детально описаний в документах – називається документованим виконанням.

По суті це каскадна модель розробки, яка складається з певної кількості етапів, кожен етап з яких завершується детальною документацією етапу. Вся ця документація використовується для виконання подальших етапів. Крім того, після виконання кожного етапу, замовник ознайомлюється з відповідними нормативними документами і лише після їх схвалення відбувається перехід до наступного етапу розробки.

Переваги і недоліки моделі документованого виконання

Переваги:

1. Перевага каскадної моделі, тобто можливість планування розробки системи

2. Можливість зупинити розробку на певний час з різних причин, а потім цю розробку продовжити (можливість зупинити розробку в одній компанії і передати на розробку іншій компанії).

Недоліки (подібні до недоліків каскадної моделі):

1. Складність переходу на попередній етап, крім того, під час такої розробки необхідно витрачати значні кошти на виготовлення документації (на практиці це більше 50% робочого часу)

2. Необхідні технічні зупинки під час розробки (коли клієнт вивчає документацію по попередньому етапу і приймає рішення)

Прототипування

Всі розглянути попередні методи розробки проекту мають суттєвий недолік: це висока вага помилок, які зроблені на етапі формулювання вимог.

Даний метод передбачає, що перед самою розробкою системи створюється її модель на основі спрощеного формулювання вимог. Після вдалого моделювання її розширюють, модифікують. Найбільш широко прототипування використовують під час розробки інформаційних систем. Прототипування в загальному – це моделювання системи, метою якого є: мінімізувати кількість та вагу помилок на етапі формулювання вимог.

Під час виконання прототипування здійснюють:

1. Загальне формулювання вимог

2. Розробляється прототип (на базі загального формулювання вимог)

3. Прототип перевіряється клієнтом, якщо клієнт схвалює отриманий прототип (якщо ні, то повертаємося назад)

4. Відбувається повне формулювання вимог

5. Проводиться реалізація системи з використанням каскадної моделі.

В процесі прототипування відбуваються:

1. Знаходження відмінностей в баченні системи клієнтом та розробником

2. Виявлення необхідних відсутніх функцій

3. Виявлення найбільш складних операцій системи

4. Відбувається формулювання вимог по деталізації системи

Переваги і недоліки:

• Переваги

  • Існує можливість швидкого представлення системи клієнту (демонстрація робочого варіанту)

  • Можливість тестування та використання системи до її повної розробки

• Недоліки

  • Додаткові витрати часу та коштів на розробку прототипу

На практиці діючий прототип – це, як правило, частина робочої системи. Існує декілька методів розробки прототипу:

1. Часткова реалізація (в прототипі реалізуються лише найважчі вимоги)

2. Використання для прототипування мов високого рівня, мов, які передбачають використання функціональних специфікацій

3. Використання для розробки прототипу готових функціональних компонентів

4. Генерування інтерфейсу користувача (На практиці у більшості випадків замовник висуває вимоги до інтерфейсів)

5. Швидке прототипування (тестування в процесі роботи)

6. Прототипування на папері

Покрокова розробка

Покрокова розробка розпочинається з формулювання вимог та розробки базового проекту всієї системи.

В наступних кроках вибираються важливі функції, відбувається їх реалізація на основі каскадної моделі, тестування та відправлення замовнику.

Структурна схема покрокової розробки програмного забезпечення

• Формулювання вимог

• Розробка базового проекту

• Вибір підмножини функцій

• Реалізація вибраних функцій

• Передача розробленої системи замовнику

• (Ітераційна схема)

Переваги і недоліки даного методу:

1. Переваги

   1. Менші часові розриви у взаємодії із замовником

   2. Існує можливість більш швидкого використання частини системи

   3. Гнучкість під час розробки системи:

   4. Якщо розробка певної частини системи затримується весь проект при цьому не зупиняється (замовник експлуатує, а розробники працюють над іншими елементами системи)

2. Недоліки

   1. Додаткова вартість, яка необхідна для незалежної реалізації частини системи (на практиці неможливо розділити всі функції у незалежний набір)

   2. Збірка з готових елементів

Метод збірки з готових елементів акцентує увагу на можливість зменшення коштів під час розробки шляхом подібності створення програмного забезпеченні із вже існуючим. В такий спосіб, існуючі працездатні компоненти різних систем можуть використовуватись для створення різних систем на різних етапах.

На практиці до таких систем в основному належать:

1. Електронні бібліотеки

2. Мови 4-го покоління, в яких інструкції опрацьовуються як посилання на вбудовані бібліотеки

Існує два методи збірки з готових компонентів:

1. Придбання компонентів у зовнішніх постачальників

2. Розробка біжучого проекту з розрахунком його багатократного використання в майбутніх системах

Переваги та недоліки:

1. Переваги

   1. Висока надійність системи (існуючі готові компоненти як правило уже перевірені на практиці)

   2. Зменшення ризиків (зменшується ризик не вдалості проекту)

   3. Ефективність використання робочого часу персоналу і відповідних експертів

   4. Стандартність вимог (готові компоненти, як правило, розроблені з певними стандартами)

   5. Суттєве зменшення вартості розробки

2. Недоліки

   1. Додаткова вартість розробки компонентів широкого використання

   2. Залежність розробки від окремих постачальників

   3. Недолік інструментів, які підтримують розробку (вузький спектр засобів, які використовуються для розробки системи)

Модель спіралі

На етапі планування формуються основні цілі системи. На етапі аналізу формулюються основні складові елементи нової системи. Вони аналізуються з точки зору врахування ризиків їх реалізації. Крім того цей етап може передбачати прототипування. На третьому етапі відбувається створення версії системи на основі каскадної моделі. На останньому етапі клієнт порівнює висувної вимоги до системи з отриманим результатом.

Етапи розробки ПЗ

Етап – це період між основними пунктами процесів розробки системи, в якому формуються чітко описані завдання, презентуються готові робочі продукти і приймають рішення про перехід на наступний рівень розробки.

Метою стратегічного етапу з точки зору клієнта на перший погляд всі цілі системи можуть здаватись очевидними. Проте спроба і необхідність їх до визначити дасть змогу уникнути в майбутньому непорозумінь між клієнтом і замовником. Крім того, навіть якщо цілі є очевидні для всіх людей задіяних на стратегічному етапі, вони можуть виявитись не зовсім зрозумілими для людей, які працюють на різних етапах розробки системи і не мають прямого контакту з клієнтом. Тому метою цього етапу повинен бути ретельний опис вимог на випадок, якщо в майбутньому на деяких етапах розробки будуть виникати деякі сумніви по системі.

Наступним завданням, яке необхідно виконати на цьому етапі є описати можливості проекту. Опис проекту необхідний для хорошої вартісної оцінки проекту. На цьому етапі, як правило клієнт ще не усвідомлює всіх можливостей проекту і для нього не зрозуміло, які функції буде здійснювати ПЗ, які функції будуть здійснені апаратними засобами та іншими дотичними системами.

Визначення можливостей проекту приводить до контекстного опису. Тобто, зовнішність систем, з якими буде взаємодіяти наша система. На практиці, в основному існують різні класи користувачів системи. Цих користувачів розглядають як зовнішні сутності.

Визначення мети, можливостей системи і контексту проекту не достатньо для оцінки вартості системи. Точна оцінка вартості можлива лише після того, коли всі етапи виконані. На практиці фінансові ресурси замовника на стратегічному етапі дуже обмежені. Тому на цьому етапі рекомендують проводити лише загальну попередню оцінку вартості проекту.

Стратегічний етап іноді називають етапом проектування. Тому що він виконується перше ніж ухвалюється остаточне рішення про розробку системи. У випадку компанії, яка виробляє ПЗ для безпосереднього клієнта – це етап ведення переговорів про продукт з клієнтом. У випадку, коли компанія розробляє ПЗ для ринку – це етап обговорення та планування продукту.

Стратегічний етап також іноді називають техніко-економічним вивченням продукту. На стратегічному етапі виконують наступні дії:

1. Відбувається обговорення проекту з представниками клієнта

2. Визначається мета проекту з точки зору клієнта

3. Визначаються можливості та контекст проекту

4. Відбувається приблизне формулювання вимог, проводиться поверхневий аналіз та загальний проект системи

5. Формулюються альтернативні рішення по системі

6. Проводиться аналіз цих рішень

7. Результати представляються представникам клієнта та здійснюється врахування зауважень

8. Відбувається попереднє планування розробки та вибір структури команд

9. Розробляється стандарт визначень

У випадку розробки ПЗ стосовно клієнта розрізняють:

1) людину-замовника (який оплачує проект)

2) людей, які будуть експлуатувати систему

У більшості випадків проект повинен відповідати вимогам замовника, оскільки остаточну оцінку дає він. При цьому необхідно пам’ятати, що замовник не є користувачем системи. На цьому етапі необхідно прийняти наступні стратегічні рішення для розробки системи:

1) вибрати модель проекту

2) вибрати методи, які будуть використовуватись під час аналізу та проектування системи

3) вибрати програмне середовище

4) вибрати кейс-інструмент

5) визначити можливу (необхідну) співпрацю з іншими командами або спеціалістами

Під час розробки ПЗ, варіанти рішень по системі підпорядковуються певним обмеженням, які можуть стосуватися:

1. максимальної допустимої вартості

2. обмеження в персоналі

3. обмеження в інструментах

4. обмеження в часі

Під час виконання стратегічного етапу розробляється поверхневий план проведення роботи. Під час виконання стратегічного етапу визначаються стандарти:

1. стандарти використання інструментів і понять

2. стандарти документування

Оцінка рішень по системі, як правило, заснована на наступних критеріях:

1. вартість проекту

2. затрати часу на проект

3. можливість повторного використання компонентів системи

4. мобільність системи

5. спосіб виконання

Дід час виконання стратегічного етапу, успіх оцінюється по наступних параметрах:

1. ефективність роботи команди (якщо ми працюємо для конкретного замовника, навіть не значні затримки в розробці можуть зменшити шанси для нового замовлення)

2. мінімальність коштів витрачених для виконання стратегічного етапу (незалежність від розмірів та складності системи на цьому етапі не можна витратити великих коштів оскільки всі ці роботи оплачуються розробником), тому цей етап повинен виконуватися невеликою групою людей в короткі терміни

3. нерозуміння ключових моментів клієнтом

4. осмислення всієї системи розробником

У більшості випадків невдачі викликані приділенням лише певним фрагментам систем і відсутнє розуміння, які елементи системи можуть виявитися найважчими в розробці.

Після виконання стратегічного етапу отримують наступні результати:

1. загальний звіт, який охоплює:

   1. визначення мети системи

   2. опис можливостей системи

   3. опис зовнішніх систем, з якими буде співпрацювати система

   4. загальний опис вимог

   5. загальна модель системи

   6. варіанти рішень по системі

   7. вартісна оцінка системи

   8. попереднє планування робіт

2. звіт про оцінку рішень

   1. всі варіанти рішень та обґрунтування прийнятого рішення

3. представлення необхідних ресурсів (штат працівників, апаратні засоби та ПЗ)

4. стандартні визначення

5. попереднє планування аналізу визначення

6. попереднє планування аналізу

Етап формулювання вимог

Метою цього етапу є детально описати вимоги клієнта до системи.

Під час регулярної комунікації з клієнтом відбувається етап формулювання всіх деталей що стосуються системи. Прийняти щоб одна людина з боку замовника контактувала з розробником.

Причинами трудності з клієнтами є:

1. клієнт не знає, які цілі і в який спосіб можуть вони бути досягнуті

2. великі системи, як правило, використовуються великою кількістю користувачів, тому можливі протиріччя в самому середовищі користувачів по використанню системи

3. люди, які роблять замовлення і безпосередні користувачі – це різні люди, тому думка замовника на цьому етапі є важливою з позиції фінансування і замовлення проекту, але вони не можуть врахувати реальних потреб користувачів

Вимоги клієнтів до системи описуються на різних рівнях:

1. визначення вимог (це загальний опис вимог, який проводиться після обговорення з представниками питань замовлення)

2. специфікація вимог (це опис…)

3. …

1. Вступ (цілі, можливості в контексті системи)

2. Опис розвитку системи (можливі майбутні зміни)

3. Опис функціональних вимог

4. Опис не функціональних вимог

5. Модель системи

6. Словник термінів

Крім того, документ з опису вимог при потребі повинен містити додаткову інформацію:

1. специфікація функціональних вимог

2. специфікація нефункціональних вимог

3. вимоги до устаткування

4. вимоги до БД

5. план тестування

Функціональні вимоги

Функціональні вимоги описують функції, які повинні виконуватися системою. Іноді до цих вимог включають вимоги до зовнішніх систем, з якими буде співпрацювати система. У більшості випадків на практиці для опису функціональних вимог використовується не спеціалізована мова. При цьому можливі виникнення наступних незручностей:

1. двозначність неспеціалізованої мови робить опис вимог важким для сприйняття і може привести до різного його розуміння різними людьми

2. гнучкість неспеціалізованої мови (той самий зміст можна відображати в різних формах) може привести до опущення суперечливих вимог, які сформульовані в різних формах і по різному трактують ті самі функції

Для усунення таких незручностей використовують формальні примітки. Формальні примітки усувають двозначності і ускладнюють розуміння вимог клієнтом. Тому рекомендують формальні примітки використовувати в кінці не спеціалізованого опису. На практиці у більшості випадків функціональні вимоги подаються у формі очікуваного результату, а не алгоритму. Цей опис завжди є декларативним. І в деяких випадках виникає необхідність для специфічних функцій описувати і алгоритм. Як правило, функціональні вимоги формуються для визначення зовнішніх зв’язків, оскільки функції системи повинні бути відомі не тільки користувачам, а й іншим взаємодіючим системам, тому під функціями системи не повинно розуміти тільки функції програми.

Методика декомпозиції функцій передбачає, що найзагальніші функціональні вимоги формулюються і поділяються по назвах функцій, а потім проводиться їх декомпозиція.

На практиці у більшості випадків клієнт не завжди розуміє, а у більшості мало цікавиться загальними функціональними можливостями системи, а обговорює специфічні функції, які потім аналітик повинен об’єднати в загальні функції системи. Такий метод називається «знизу вверх».

На прктиці використовуються ці два методи опису функцій:

1. знизу вверх

2. зверху вниз

Не функціональні вимоги

Описуються основні функції системи.

Поділяються на:

1. вимоги до продукту (система повинна використовувати все що необхідне для системи…)

2. вимоги до процесу (система повинна підтримувати певний стандарт…)

3. зовнішні вимоги – це вимоги до роботи з зовнішніми системами.

Функціональні і не функціональні вимоги повинні бути зрозумілими і повинні бути методи перевірки виконання цих вимог. Таким чином у вимогах не можна вживати наступні терміни: зручний, надійний, ефективний, – бо це декларативні речі.

Для успішного виконання вимог необхідно:

1. постійна співпраця з відповідними представниками клієнта

2. повне розуміння вимог, усвідомлення спеціальних випадків та виключень у вимогах

3. перевірка завершеності і послідовності вимог

4. короткий опис нефункціональних вимог

Етап аналізу

Метою аналізу є визначити як система повинна працювати. В результаті виконання цього етапу будується логічна модель, яка показує як необхідно підійти до розробки системи. Деталі розробки системи на цьому етапі не розглядаються. Розпочинається етап з вибору моделі в області проблеми і передбачає визначитись, яка повинна бути система.

Для того щоб якісно виконати цей етап необхідно:

1. Залучати до виконання цього етапу відповідних професіоналів з проблемної області

2. Підтримання необхідних стандартів

3. Визначення правильності та перевірка концепцій

4. Прозорість

5. Логічність

6. Послідовність ведення документацій

7. Глобальне розуміння розробниками системи без деталізації особливості

За результатами виконання цього етапу отримаємо:

1. Покращений документ по вимогах

2. Словник даних по системі

3. Документ, що описує створену модель:

   1. Діаграма класів

   2. Діаграма випадків використання

   3. Діаграма дій

   4. Діаграма станів

   5. Звіт, який описує визначення класів, ознак відносин, методів і т.д., що використовуються в системі

4. Графік етапу проектування

5. Попереднє визначення людей та команд на розробку

Етап проектування

Цей етап передбачає детальний опис реалізації системи. Цей опис після проведення остаточних змін в наступних етапах (реалізації, тестування) стане частиною технічної документації по системі.

На відміну від етапу аналізу, на етапі проектування розробники повинні знати, яке програмне середовище мови програмування, бібліотеки та інші інструменти будуть застосовуватися на етапі реалізації.

На цьому етапі відбувається перетворення абстрактних понять етапу аналізу в конкретні деталі системи.

Під час виконання цього етапу розробки ПЗ, одна частина працівників працює над проблемами пов’язаними з основними функціями системи і опрацюванням необхідних даних, інша частина працює постійно з клієнтом, з визначенням способу зберігання даних, доступу до даних, управління пам’яттю і подібними питаннями.

На етапі проектування також відбувається оптимізація моделі. Програмні середовища, які розглядаються на цьому етапі використовують різні інструменти, які з однієї сторони обмежують раніше розроблену модель, але з іншої сторони вони забезпечують допоміжні засоби, які можуть спростити реалізацію системи. Таким чином на етапі проектування створюється модель в рамках обмежень та можливих удосконалень з позиції програмних середовищ. На цьому етапі визначається фізична структура моделі.

Виконують наступні завдання:

1. Формується специфікація результатів аналізу

2. Проводиться проектування компонентів системи, які не належать області проблем

3. Проводиться оптимізація системи

4. Відбувається підлаштування моделі системи до обмежень та варіантів програмного середовища

5. Відбувається фізичне визначення структури системи

Детальна модель системи відкриває можливість оцінки варіантів реалізації конструкції системи. Основні конструкції системи повинні підтримуватися допоміжними:

1. Інтерфейси роботи з користувачами

2. Компоненти управління даних при зберіганні даних

3. Компоненти управління пам’яттю

4. Компоненти управління завданнями системи

Цей етап (проектування):

1. Висока якість моделі системи

2. Хороше знання середовища розробки

3. Перевірка системи

4. Узгодженість зі стандартами

5. Необхідно здійснити проектну оптимізацію для основних компонентів системи

В результаті виконання цього етапу отримаємо:

1. Відкоригований документ формулювання вимог

2. Відкоригована модель, яка завершувалася детальною специфікацією

3. Документ, що описує проект:

   1. Діаграма класів

   2. Діаграма взаємодій

   3. Діаграма станів

   4. Діаграма діяльності

   5. Діаграма компонентів

   6. Визначення ознак класів, методів, даних і т.д.

4. Різні класи систем

5. Спроектована БД

6. Фізичний проект структури системи

7. Відкоригований тестовий проект

8. Планування виконання системи

Етап реалізації

Під час реалізації система реалізується в певному середовищі розробки та визначається надійність проекту. Надійність проекту полягає в максимальному уникненні помилок або можливості їх виправлення. Під час реалізації програмного продукту не всі помилки можуть бути виявлені та усунені. Але існує можливість зменшити ймовірність їх виникнення в наслідок:

1. Відмова у використанні ризикованих методів (вказівників)

2. Обмеження принципу доступу (розподіл пам’яті і т.д.)

3. Використання під час реалізації типізованих мов і відповідних компіляторів

4. Використання мов високого рівня

5. Послідовність використання інтерфейсів модулів

6. Врахування надзвичайних ситуацій

7. Можливих невизначеностей

8. Дотримання мінімальних відмінностей між концептуальною моделлю і моделлю реалізації

Крім того на практиці не існує методів, які виключають можливість появи помилки. Але завжди існує можливість забезпечити виконання програми не дивлячись на помилку. Такий механізм називають перекриттям помилки. Він включає:

1. Виявлення помилок

2. Опрацювання помилок

3. Виправлення помилок

Використання такого механізму можливе, якщо передбачена відповідна діагностика системи на помилки.

Існує два методи опрацювання помилок:

1. Перевірка даних

2. Співставлення результатів різних версій модуля

Для успішного виконання цього етапу потрібно:

1. Високоякісна і детальна специфікація проекту

2. Хороше знання середовища розробки

3. Дотримання існуючих стандартів

4. Опрацювання помилок

В результаті виконання цього етапу отримають:

1. Покращений документ по вимогах

2. Покращену аналітичну модель

3. Покращений проект системи

4. Код з перевіреними модулями

5. Звіт про перевірені модулі

6. Розроблена БД

7. Планування етапу тестування

Етап тестування

Під тестуванням розуміють сертифікацію програмного продукту – це:

1. перевірка системи вимогам клієнта

2. перевірка системи (загальна)

Мета тестування полягає в тому: щоб виявити і виправити помилки. Тестування повинно виявляти як загальні помилки в системі так і помилки виконання. Під помилками розуміють: конструкції, які розроблені не правильно. Помилки у виконанні системи можуть бути наслідком інших попередніх помилок.

Тести можуть бути націлені на:

1. виявлення максимальної кількості помилок

2. виявлення статистики помилок (відповідно їх частоти виникнення та надійності обладнання)

Тести можуть бути статичні та динамічні.

Статичні базуються на основі аналізу коду.

Динамічні тести передбачають порівняння за відома правильних результатів і результатів роботи програми.

Фази тестування:

1. тестування модулів (відбувається після їх розробки та реалізації)

2. тестування системи (відбувається після інтегрування всіх модулів в єдину систему і передбачає як тестування системи загалом так і модулів в складі системи)

3. приймальне тестування (система передається клієнту і перевіряється ним же) – таке тестування називається альфа тестування

Для успішного виконання цього етапу:

1. вдала реалізація спеціальних вимог систем, що забезпечить надійність системи

2. мотивоване залучення людей для виконання тестів

Під час виконання цього етапу отримаємо:

1. покращені вимоги

2. покращена модель

3. покращений проект

4. покращений код

5. звіт про тести

6. оцінка надійності програмного продукту

Етап установки

На цьому етапі програмний продукт або система передається користувачеві і він стає власником програмного продукту. На цьому етапі виконуються наступні дії:

1. навчання користувачів та адміністратора

2. установка програмного та апаратного забезпечення

3. установка БД

4. контрольоване використання системи

5. передача системи клієнту

Для успішного виконання цього етапу потрібно:

1. спланувати розклад та графік установки щоб уникнути конфлікту із замовниками

2. позитивна оцінка проекту замовником

Результати:

1. покращені вимоги

2. - модель

3. - код

4. Програмний продукт встановлений у клієнта

Етап підтримки

Етап установки відбувається паралельно із початком експлуатації системи. Етап підтримки – більш довгий і триває під час експлуатації. Під час цього етапу можливі зміни в системі. Існує три основні класи модифікації системи.

1. Усунення помилок

2. Поліпшення якості ПЗ

3. Оновлення ПЗ, яке передбачає сумісність із всіма зовнішніми системами, які теж можуть модифікуватися.

Кожна зміна в системі на етапі підтримки повинна бути чітко проаналізована і повинне бути прийняте рішення чи має ця зміна сенс. Аналіз змін полягає в:

1. Як буде впливати зміна на експлуатацію системи

2. Яка вартість змін у системі

3. Як буде впливати зміна в системі на специфічні компоненти в системі

4. Як ця зміна може відобразитися в технічній документації по системі.

Тільки після такого аналізу на практиці проводять модифікацію системи.

Чинники успіху етапу підтримки:

1. Висока якість вимог до системи

2. Висока якість моделі

3. Висока якість системи

4. Грамотне використання середовищ розробки

5. Кваліфікована команда для виконання системи

6. Висока якість і вартість обслуговування системи

За результатами виконання цього етапу отримаємо:

1. Покращені вимоги

2. - модель

3. - проект

4. - код

Лекція 3. Специфікації програмного забезпечення.

Специфікація вимог до програмного забезпечення (англ. Software Requirements Specification (SRS)) - специфікація вимог для програмної системи - це повний опис поведінки системи що розробляється. Вона включає множину прецедентів які описують всі взаємодії, які користувачі мають з програмним забезпеченням. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів SRS також включає нефункціональні (чи додаткові) вимоги. Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).

Загальний план специфікації вимог до пз

Обкладинка

Сторінка змін

Зміст

1. ВСТУП

   1. Огляд продукту

   2. Мета

   3. Межі

   4. Посилання

   5. Означення та абревіатури

2. ЗАГАЛЬНИЙ ОПИС

   1. Перспективи продукту

   2. Функції продукту

   3. Характеристики корисувачів

   4. Загальні обмеження

   5. Припущення й залежності

3. КОНКРЕТНІ ВИМОГИ

   1. Вимоги до зовнішніх інтерфейсів

      1. Інтерфейс користувача

      2. Апаратний інтерфейс

      3. Програмний інтерфейс

      4. Комунікаційний протокол

      5. Обмеження пам'яті

      6. Операції

      7. Функції продукту

      8. Припущення й залежності

   2. Властивості програмного продукту

   3. Атрибути програмного продукту

      1. Надійність

      2. Доступність

      3. Безпека

      4. Cупроводжуваність

      5. Переносимість

      6. Продуктивність

   4. Вимоги бази даних

   5. Інші вимоги

4. ДОДАТКОВІ МАТЕРІАЛИ

Лекція 4. “Хаотичне” і структурне програмування. Теорія і методи структурного програмування.

1. Структурне програмування

За часів стихійного програмування хорошими програмістами вважали тих, хто створював досить хитромудрі програми, які займали мінімум часу та пам’яті при виконанні. Це було цілком природно, враховуючи тодішні можливості обчислювальної техніки. Результатом такого програмування виявлялись програми, які було важко (якщо взагалі можливо) зрозуміти іншим. Навіть автори таких програм з часом з трудом розуміли власне творіння. Внесення необхідних змін в таку програму робило ситуацію ще більш заплутаною. Подібні програми одержали назву BS-програм (це абревіатура від “bowl of spaghetti” – блюдо спагетті, бо саме так виглядала програма при спробі зобразити всі переходи між її операторами). Піонер структурного програмування Е. Дейкстра навіть проголосив, що “кваліфікація програміста обернено пропорційна кількості операторів безумовного переходу в його програмах”. Структурне програмування іноді називають “програмування без go to”, хоча це екстремальна точка зору. Насправді мова йде про те, щоб не використовувати оператори переходу без особливої необхідності. Перш за все структурне програмування мало своєю метою позбавитись від поганої структури в програмі. Ще однією метою було створення таких програм, які були б легко зрозумілими навіть без їх авторів, адже “програми пишуться для людей – комп’ютером вони лише обробляються”. Зміст цієї фрази полягає у тому, що трансляція і виконання програми будь-якої структури на комп’ютері дійсно не викликає ніяких труднощів. А от роботу з перевірки правильності програми, внесення виправлень і змін доводиться виконувати людині.

Отже, структурне програмування є технологією програмування, яка об’єднує способи складання добре структурованих надійних програм, зручних для читання і розуміння їх людиною, слідкування за логікою їх роботи, внесення до них виправлень та інших змін. Згідно з думкою Н.Вірта “структурізація є принциповим інструментом, яке допомагає програмісту систематично синтезувати складні програми, зберігаючи про них повне уявлення”.

Реалізація цих ідей заснована на таких принципах:

аналітичне (згори донизу) програмування;

структурне кодування , тобто використання лише базових елементів програми;

принцип модульності.

З точки зору структурного програмування, правильна програма – це програма, структура якої включає тільки базові елементи, і жоден з цих базових елементів не є недоступним і не допускає зациклювання. Правильна програма має тільки один вхід і тільки один вихід. В правильній програмі не повинно бути таких частин, які ніколи не виконуються.

1.1. Принцип модульності

Принцип модульності полягає у тому, що програма розбивається на логічно незалежні частини (модулі), які дотримуються зв’язків. Історично поняття модульної програми виникло раніше, ніж були сформульовані принципи структурного програмування, проте ця ідея виявилася просто необхідною складовою нової технології програмування разом з аналітичним проектуванням.

Поняття модуля цілком логічно з’являється на відповідному етапі аналітичного програмування: модуль – це частина програми, яка розв’язує порівняно нескладну задачу, логічно незалежну від інших задач.

Зовсім просто: модулі – це підпрограми (процедури або функції), які мають певні властивості.

Деякі необхідні властивості модуля:

єдиний вхід, єдиний вихід (деякі мови дозволяють існування декількох входів або виходів);

окрема компіляція;

кожний модуль доступний за своїм ідентифікатором;

модуль може викликати інший модуль;

модуль не повинен зберігати історію своїх викликів (інакше може виникати так званий побічний ефект);

модуль порівняно невеликий;

кожен модуль відповідає лише одній задачі;

незалежність функціонування (заміна модуля на аналогічний не впливає на всю програму).

З часом, коли принцип модульності став підтримуватись мовами програмування, на перший план висунулась вимога логічної та програмної незалежності модуля.

Слід зауважити, що повної незалежності між модулями бути не може. Залежність між модулями існує:

через списки параметрів;

тоді, коли вони користуються спільними (глобальними) змінними;

всі модулі програми залежать від структури даних цієї програми;

модулі залежать від логіки функціонування програми (від того фактору, що модуль може викликатися іншими модулями).

Отже, модулі повинні бути незалежні в межах інтерфейсу програми і структури даних. Практика показала, що чим вищий степінь незалежності модулів, тим простіше розібратись в окремих модулях і в програмі в цілому; тим менша ймовірність з’явлення нових помилок при виправленні старих, або внесенні змін в програму, тобто менша ймовірність так званого хвильового ефекту.

Із сказаного вище випливає, що не слід без крайньої необхідності використовувати в модулях глобальні змінні. Всі зв’язки між модулями повинні підтримуватися через списки параметрів.

1.2. Процедурна абстракція. Модулі в Turbo Pascal.

Процедурна абстракція – це філософія, яка полягає у тому, що при розробці підпрограм піклування про те, що повинна виконувати процедура або функція, відокремлюється від того, як це виконується.

Потенціал процедурної абстракції більш повно можна реалізувати не у стандартній реалізації мови Паскаль, а у Turbo Pascal (TP).

Після утворення якоїсь процедури, яка має універсальне значення, TP надає вам можливість помістити її у свою особисту бібліотеку підпрограм, або модуль (unit). Потім цей модуль можна використати (імпортувати цю процедуру) в іншій програмі. При цьому ви дійсно відокремлююте що від як. Знаючи, що робить дана процедура і як її викликати, ви можете без обмежень її використовувати, не маючи при цьому жодного уявлення, як саме вона реалізована.

Модулі TP знаходяться в окремих файлах на диску. Вони можуть містити описи констант, типів даних, змінних, процедур і функцій. Компілювати модуль і виправляти у ньому знайдені помилки можна окремо від програм, у яких цей модуль використовується.

Виклик: uses MyUnit;

Структура модуля аналогічна до структури Паскаль-програми:

unit <ім’я модуля>;

interface

загальнодоступні описи

implementation

приховані описи (змінні, вкладені процедури і т.д.)

описи загальнодоступних процедур і функцій

[розділ ініціалізації]

end.

Розділ interface містить всю інформацію, яку необхідно знати програмісту, щоб користуватися цим модулем. Тут є заголовки і документація (коментарі) всіх підпрограм модуля.

Тіла підпрограм міститься в розділі implementation. Кінець модуля позначається словом end. Для нього не існує відповідного begin, якщо у розділі не існує розділа ініціалізації, у якому змінним, що використовуються всередині модуля, надаються початкові значення. Розділ ініціалізації виконується до виконання будь-якого клієнта модуля (програми або модуля, який використовує наш модуль).

Лекція 5, 6, 7. Тестування і відлагодження програм. Стратегії і методи тестування.

Тестування програмного забезпечення охоплює цілий ряд видів діяльності, аналогічно послідовності процесів розробки програмного забезпечення. У нього входять /1/:

а) постановка завдання для тесту,

б) проектування тесту,

в) написання тестів,

г) тестування тестів,

д) виконання тестів,

е) вивчення результатів тестування.

Вирішальну роль відіграє проектування тестів. Можливі різні підходи до проектування тестів. Перший полягає в тому, що тести проектуються на основі зовнішніх специфікацій програм і модулів, або специфікацій сполучення програми або модуля. Програма при цьому розглядається як чорний ящик (стратегія 'чорного ящика'). Суть такого підходу - перевірити чи відповідає програма зовнішнім специфікаціям. При цьому логіка модуля зовсім не приймається до уваги.

Другий підхід заснований на аналізі логіки програми (стратегія 'білого ящика'). Суть підходу - у перевірці кожного шляху, кожної гілки алгоритму. При цьому зовнішня специфікація до уваги не береться.

Жоден із цих підходів не є оптимальним. З аналізу першого підходу ясно, що його реалізація зводиться до перевірки всіх можливих комбінацій значень на вході програми. Тестування будь-якої програми для всіх значень вхідних даних неможливе, тому що їх безліч, тому обмежуються меншою кількістю. При цьому виходять із максимальної віддачі тесту в порівнянні з витратами на його створення. Вона виміряється ймовірністю того, що тест виявить помилки, якщо вони є в програмі. Витрати вимірюються часом і вартістю підготовки, виконання й перевірки результатів тесту.

Проаналізуємо тепер другий підхід до тестування. Навіть якщо припустити, що виконано тести для всіх шляхів програми, не можна з повною впевненістю стверджувати, що модуль не містить помилок.

Очевидна основа цього твердження полягає в тому, що виконання всіх шляхів не гарантує відповідності програми її специфікаціям. Допустимо, якщо було потрібно написати програму для обчислення кубічного кореня, а програма фактично обчислює корінь квадратний, то програма буде зовсім неправильною, навіть якщо перевірити всі шляхи. Друга проблема - відсутні шляхи. Якщо програма реалізує специфікації не повністю (наприклад, відсутня така спеціалізована функція, як перевіряє на негативне значення вхідних дані програми обчислення квадратного кореня), ніяке тестування існуючих шляхів не виявить такої помилки. І, нарешті, проблема залежності результатів тестування від вхідних даних. Шлях може правильно виконуватися для одних даних і неправильно для інших. Наприклад, якщо для визначення рівності 3 чисел програмується вираз виду:

IF (A+B+C)/3=A,

то воно буде вірним не для всіх значень A, B і C (помилка виникає в тому випадку, коли із двох значень В або С одне більше, а інше на стільки ж менше від А). Якщо концентрувати увагу тільки на тестуванні шляхів, немає гарантії, що ця помилка буде виявлена.

Таким чином, повне тестування програми неможливе. Тест для будь-якої програми буде обов'язково неповним, тобто тестування не гарантує повну відсутність помилок у програмі. Стратегія проектування тестів полягає в тім, щоб спробувати зменшити цю неповноту наскільки це можливо.

1. Методи стратегії 'білого ящика'

Тестування за принципом білого ящика характеризується ступенем, який тести виконують або покривають логіку (вихідний текст програми).

2.1.1 Метод покриття операторів

Метою цього методу тестування є виконання кожного оператора програми хоча б один раз.

Приклад:

Малюнок 2.1 Малюнок 2.2

У цій програмі можна виконати кожний оператор, записавши один єдиний тест, що реалізував би шлях ace. Тобто, якби на вході було: А=2, В=0, Х=3, кожний оператор виконався б один раз. Але цей критерій насправді гірший, ніж він здається на перший погляд. Нехай у першій умові замість “and”“or” і в другому замість “x>1”“x<1” (блок-схема правильної програми наведена на малюнку 2.1, а неправильної - на малюнку 2.2). Результати тестування наведені в таблиці 2.1. Зверніть увагу: очікуваний результат визначається по алгоритму на малюнку 2.1, а фактичний - по алгоритму малюнка 2.2, оскільки визначається чутливість методу тестування до помилок програмування. Як видно із цієї таблиці, жодна із внесених в алгоритм помилок не буде виявлена .

Таблиця 2.1 - Результат тестування методом покриття операторів

Тест	Очікуваний результат	Фактичний результат	Результат тестування
A=2, B=0, X=3	X=2,5	X=2,5	неуспішно

2.2 Метод покриття рішень (покриття переходів)

Більш сильний метод тестування відомий як покриття рішень (покриття переходів). Відповідно до даного методу кожний напрямок переходу повинен бути реалізованим принаймні один раз.

Покриття рішень звичайно задовольняє критерію покриття операторів. Оскільки кожний оператор лежить на деякому шляху, що виходить або з оператора переходу, або із точки входу програми, при виконанні кожного напрямку переходу кожний оператор повинен бути виконаний.

Для програми наведеної на малюнку 2.2 покриття рішень може бути виконано двома тестами, що покривають шляхи {ace, abd}, або {aсd, abe}. Шляхи {aсd, abe} покриємо, вибравши наступні вихідні дані: {A=3, B=0, X=3} і {A=2, B=1, X=1} (результати тестування - у таблиці 2.2).

Таблиця 2.2 - Результат тестування методом покриття рішень

Тест	Очікуваний результат	Фактичний результат	Результат тестування
A=3, B=0, X=3	X=1	X=1	неуспішно
А=2, В=1, Х=1	Х=2	Х=1,5	успішно

2.3 Метод покриття умов

Кращі результати в порівнянні з попередніми може дати метод покриття умов. У цьому випадку записується число тестів, достатнє для того, щоб всі можливі результати кожної умови в рішенні виконувалися принаймні один раз.

У попередньому прикладі маємо чотири умови: {A>1, B=0}, {A=2, X>1}. Отже, потрібне достатнє число тестів, таке, щоб реалізувати ситуації, де A>1, A1, B=0 і B0 у точці а й A=2, A2, X>1 і X1 у точці В. Тести, що задовольняють критерію покриття умов і відповідні до них шляхи:

а) A=2, B=0, X=4 ace

б) A=1, B=1, X=0 abd

Таблиця 2.3 - Результати тестування методом покриття умов

Тест	Очікуваний результат	Фактичний результат	Результат тестування
A=2, B=0, X=4	X=3	X=3	неуспішно
A=1, B=1, X=0	X=0	X=1	успішно

2.4 Критерій рішень (умов)

Критерій покриття рішень/умов вимагає такого достатнього набору тестів, щоб всі можливі результати кожної умови в рішенні виконувалися принаймні один раз, всі результати кожного рішення виконувалися принаймні один раз і, крім того, кожній крапці входу передавалося керування принаймні один раз.

Два тести методу покриття умов

а) A=2, B=0, X=4 ace

б) A=1, B=1, X=0 abd відповідають і критерію покриття рішень/умов. Це є наслідком того, що одні умови наведених рішень приховують інші умови в цих рішеннях. Так, якщо умова А>1 буде хибною, транслятор може не перевіряти умови В=0, оскільки при будь-якому результаті умови В=0, результат рішення ((А>1)&(В=0)) матиме значення неправда. Отже, недоліком критерію покриття рішень/умов є неможливість його застосування для виконання всіх результатів всіх умов.

Інша реалізація розглянутого прикладу наведена на малюнку 2.3. Рішення вихідної програми, що залежать від багатьох умов, розбиті на окремі рішення й переходи. Найбільш повне покриття тестами в цьому випадку виконується так, щоб виконувалися всі можливі результати кожного простого рішення. Для цього потрібно покрити шляхи HILP (тест А=2,В=0,Х=4), HIMKT (тест А=3, В=1, Х=0), HJKT (тест А=0, В=0, Х=0), HJKR (тест А=0, В=0, Х=2)..

Протестувавши алгоритм на малюнку 2.3, неважко переконатися в тім, що критерії покриття умов і критерії покриття рішень/умов недостатньо чутливі до помилок у логічних виразах.

Малюнок 2.3

2.5 Метод комбінаторного покриття умов.

Критерієм, що вирішує ці й деякі інші проблеми, є комбінаторне покриття умов. Він вимагає створення такого числа тестів, щоб всі можливі комбінації результатів умови в кожному рішенні виконувалися принаймні один раз. Набір тестів, що задовольняють критерію комбінаторного покриття умов, задовольняє також і критеріям покриття рішень, покриття умов і покриття рішень/умов.

За цим критерієм у розглянутому прикладі повинні бути покриті тестами наступні вісім комбінацій:

а) A>1, B=0;

б)A>1, B0;

в) A1, B=0;

г) А1, B0;

д) A=2, X>1;

е) A=2, X1;

ж) А2, X>1;

з) А2, X1;

Для того щоб протестувати ці комбінації, необов'язково використати всі 8 тестів. Фактично вони можуть бути покриті чотирма тестами:

- A=2, B=0, X=4 {покриває а, д};

- A=2, B=1, X=1 {покриває б, е};

- A=0,5, B=0, X=2 {покриває в, ж};

- A=1, B=0, X=1 {покриває г, з}.

Таблиця 2.4 - Результати тестування методом комбінаторного покриття умов

Тест	Очікуваний результат	Фактичний результат	Результат тестування
A=2, B=0, X=4	X=3	X=3	неуспішно
A=2, B=1, X=1	X=2	X=1,5	успішно
A=0,5 B=0, X=2	X=3	X=4	успішно
A=1, B=0, X=1	X=1	X=1	неуспішно

Як і тестування, відлагодження програм – це спосіб покращення якості продукту. По своїй суті відлагодження – це спосіб виявлення дефектів у програмі. Важливо пам’ятати, що якість продукту повинна бути закладена від початку розробки: найкращий спосіб створити хороший, якісний продукт – це добре проаналізувати вимоги, вдало продумати архітектуру і застосувати дієву практику написання програмного коду. В цьому випадку відлагодження є останнім виходом.

З іншого боку, відлагодження є корисним для програміста з кількох причин:

1. Дає кращу змогу спеціалісту зрозуміти принцип роботи продукту, над яким він працює.

2. Можливість визначити вид помилок, які найчастіше допускаються програмістом.

3. Дає змогу оцінити власний код з точки зору того, хто його читає.

4. Можливість зрозуміти власну методику виправлення помилок та вирішення проблем.