Етапи розробки програм Тестування та налагодження Документування програм

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

МІНІСТЕРСТВО ОСВІТИ І НАУКИ

РОСІЙСЬКОЇ ФЕДЕРАЦІЇ

МІНІСТЕРСТВО ОСВІТИ

Державні освітні установи
ВИЩОЇ ОСВІТИ

Тюменського державного УНІВЕРСИТЕТ

Інститут математики та комп'ютерних наук

Кафедра математики та інформатики

Курсова робота

З дисципліни: «Основи програмування»

На тему:

Етапи розробки програм. Тестування та налагодження. Документування програм

Тюмень, 2010

Зміст

Введення

Глава 1. Етапи розробки програм

1.1 Постановка завдання

1.1.1 Формулювання та аналіз фізичної задачі

1.1.2. Складання математичної моделі

1.1.3 Складання алгоритму задачі

1.2 Створення програми

1.2.1 Складання тексту програми

1.2.2 Синтаксична налагодження програми

1.2.3 Тестування і семантична налагодження

1.3 Документування програми

1.3.1 Користувацька документація програми

1.3.2 Документація із супроводу програми

1.4 Запуск готової програми та аналіз отриманих результатів

Введення

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

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

Метою даної курсової роботи є розгляд не маловажной, для початківців програмістів, теми - «Етапи створення програми». Практичне застосування теоретичних навичок було випробувано в процесі написання програмного забезпечення - гра «Шибениця». Що також стало метою даної курсової.

Глава 1. Етапи розробки програм

Розробка програми - це не лише написання програми. Написання програми є одним з етапів. Спершу перерахуємо всі етапи розробки програм, а потім докладно розповімо про них.

Етапи розробки програм:

  1. Постановка завдання

    1. Формулювання та аналіз фізичної задачі

    2. Складання математичної моделі

    3. Складання алгоритму задачі

  2. Створення програми

    1. Складання тексту програми

    2. Введення тексту програми в комп'ютер

    3. Синтаксична налагодження програми

    4. Тестування і семантична налагодження

    5. Документування програми

  3. Запуск готової програми та аналіз отриманих результатів

Розглянемо докладно кожний етап.

1.1 Постановка завдання



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

1.1.1Формуліровка і аналіз фізичної задачі

Формулювання завдання - це саме її оголошення, її постановка.

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

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

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

1.1.2 Складання математичної моделі

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

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

«Математична модель - це спрощений опис реальності за допомогою математичних понять. Існує два основні класи завдань, пов'язаних з математичними моделями: прямі і зворотні. У першому випадку всі параметри моделі вважаються відомими, і нам залишається тільки дослідити її поведінку. А в другому якісь параметри моделі невідомі, і потрібно їх знайти, зіставляючи поведінку реальної системи з її моделлю. "- Це визначення використовується в основному в економіці.

«Математична модель - це математичне представлення реальності» - це визначення створене математиками.

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

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

1.1.3 Складання алгоритму задачі

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

У алгоритму є 2 обов'язкові умови:

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

  • Алгоритм повинен бути представлений у формі, зрозумілою тому об'єкту (в тому числі і людині), який буде виконувати описані в алгоритмі дії.

Так само у алгоритмів є властивості:

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

  2. Детермінованість, тобто будь-яка дія має бути строго і недвозначно визначено у кожному випадку.

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

  4. Масовість, тобто один і той же алгоритм можна використовувати з різними вихідними даними.

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

У світі існує кілька видів алгоритмів:

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

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

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

1.2 Створення програми



Процес створення програми, а точніше розробка програмного забезпечення - це другий етап створення програми.

1.2.1 Складання тексту програми

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

1.2.2 Синтаксична налагодження програми

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

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

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

1.2.3 Тестування і семантична налагодження

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

Кожному програмісту відомо, скільки часу і сил йде на відладку і тестування програм. На цей етап доводиться біля 50% загальної вартості розробки програмного забезпечення. Але не кожний з розробників програмних засобів може вірно, визначити мету тестування. Нерідко можна почути, що тестування - це процес виконання програми з метою виявлення в ній помилок. Але ця мета недосяжна: ні яке саме ретельне тестування не дає гарантії, що програма не містить помилок. Інше визначення: це процес виконання програми з метою виявлення в ній помилок. Звідси ясно, що "вдалим" тестом є такою, на якому виконання програми завершилося з помилкою. Навпаки, "невдалим" можна назвати тест, що не дозволив виявити помилку в програмі. Визначення також вказує на об'єктивну трудність тестування: це деструктивний (тобто зворотний творчому) процес. Оскільки програмування - процес конструктивний, ясно, що більшості розробників програмних засобів складно "перемкнутися" при тестуванні створеної ними продукції. Основні принципи організації тестування:

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

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

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

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

      5. необхідно ретельно підбирати тест не тільки для правильних (передбачених) вхідних даних, але і для неправильних (непередбачених);

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

      7. потрібно зберігати використані тести (для підвищення ефективності повторного тестування програми після її модифікації або установки у замовника);

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

      9. слід враховувати так званий "принцип скупчення помилок": імовірність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;

      10. слід завжди пам'ятати, що тестування - творчий процес, а не ставитися до нього як до рутинного заняття.

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

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

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

      1. тестування окремих модулів;

      2. спільне тестування модулів;

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

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

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

1.2.3.1 Структурний тестування

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

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

Використання критерію покриття умов може викликати підбір тестів, що забезпечують перехід в програмі, який пропускається при використанні критерію С1 (наприклад, в програмі на мові Паскаль, що використовує конструкцію циклу WHILE х AND y DO ..., застосування критерію покриття умов вимагає перевірки обох варіантів виходу з циклу: NOT x і NOT y). З іншого боку покриття умов може не забезпечувати покриття всіх переходів.

Наприклад, конструкція IF A AND B THEN ... вимагає по критерію покриття умов двох тестів (наприклад, A = true, B = false і A = false, B = true), при яких може не виконуватися оператор, розташований в then - гілки оператора if. Практично єдиним засобом, що надається сучасними системами програмування, є можливість визначення частоти виконання різних операторів програми. Але за допомогою цього інструмента підтримки тестування можна перевірити виконання тільки найслабшого з критеріїв повноти - покриття всіх операторів. Правда, за допомогою цього ж інструмента можна перевірити і виконання критерію С1. Але для цього заздалегідь текст програми повинен бути перетворений таким чином, щоб всі конструкції умовного вибору (IF, CASE або SWITCH) містили гілки ELSE або DEFAULT, хоч би і пусті. У цьому випадку всі гілки алгоритму, що не виконувалися на даному тесті, будуть "видимі" з таблиці частоти виконання операторів перетвореної програми.

Актуальною залишається задача створення інструментальних засобів, що дозволяють:

      • нагромаджувати інформації про покриті і непокриті гілки для всіх використаних тестів;

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

      • підтримувати більш могутні критерії повноти структурного тестування.

1.2.3.2 Сумісне тестування модулів

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

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

  • менша трудомісткість (при монолітному тестуванні потрібно 5 драйверів і 5 заглушок; при покроковому тестуванні потрібні або тільки 5 драйверів - якщо модулі підключаються "знизу вгору", - або тільки 5 заглушок - якщо модулі підключаються "зверху вниз");

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

  • легше відладка, тобто локалізація помилок (вони в основному пов'язані з останнім з підключених модулів);

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

При використанні покрокового тестування можливі дві стратегії підключення модулів: низхідна і висхідна.

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

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

  1. модулі, що містять операції введення-висновку, повинні підключатися до тестування як можна раніше;

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

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

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

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

Інші достоїнства висхідного тестування: оскільки немає проміжних модулів (модуль, що тестується є для робочого варіанту програми модулем самого верхнього рівня), немає проблем, пов'язаних з можливістю або труднощами завдання тестів; немає можливості поєднання проектування з тестуванням; немає труднощів, що спричиняють бажання перейти до тестування наступного модуля, не завершивши перевірки попереднього. Основними недоліком висхідного тестування є те, що перевірка всієї структури програмного комплексу можлива тільки на завершальній стадії тестування. Хоч однозначного висновку про переваги тієї чи іншої стратегії покрокового тестування зробити не можна (треба враховувати конкретні характеристики програми, що тестується), в більшості випадків більш переважним є висхідне тестування.

1.2.3.3 Семантична налагодження

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

Семантична налагодження - це процес знаходження і виправлення помилок, пов'язаних з неправильним зазначенням логічних сторінок даних.

Існує 3 способи налагодження програми:

  1. Покрокова налагодження програм із заходом в підпрограми;

  2. Покрокова налагодження програм з виконанням підпрограми як одного оператора;

  3. Виконання програми до точки зупинки.

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

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

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

1.3 Документування програми



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

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

1.3.1 Користувацька документація програми

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

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

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

1.3.2 Документація із супроводу програми

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

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

Документація із супроводу програми можна розбити на дві групи:

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

2. документацію, що допомагає вносити зміни в програму.

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

  • Зовнішнє опис;

  • Опис архітектури програми, включаючи зовнішню специфікацію;

  • Опис модульної системи, включаючи зовнішню специфікацію кожного включеного модуля;

  • Для кожного модуля - його специфікація і опис його будови;

  • Тексти модулів вибраною мовою програмування;

Документи другої групи містять:

  • Керівництво по супроводу програми, яке описує відомі проблеми разом з програмою, описує, які частини програми є апаратно та програмно залежними.

1.4 Запуск готової програми та аналіз отриманих результатів



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

22


Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
73.3кб. | скачати


Схожі роботи:
Паскаль Налагодження програм
Налагодження програм і програмних комплексів
Налагодження програм користувача в Tubro Pascal
Редагування та налагодження програм за допомогою Pascal
Принципи розробки алгоритмів і програм для вирішення прикладних завдань
Різні підходи до розробки культурно-ділових програм на базі готельного комплексу
Алгоритм розробки та реалізації федеральних цільових програм з розвитку проблемних регіонів Росії
Складання програм в PR
Методи структурування програм
© Усі права захищені
написати до нас