ДИПЛОМНА РОБОТА

ТЕМА: "Розробка бази даних для інформатизації діяльності підприємства малого бізнесу Delphi 7.0"

Зміст

Введение____________________________________________________3
Глава 1. Аналітична часть____________________________ _____5

1.1. Структура ремонтно-будівельної компаніі_________________6

1.2. Постановка задачи.________________________________________8

1.3. Аналіз необхідності впровадження автоматизованої

системы.___________________________________________________10

1.4. Технічне завдання на разработку.________________________15

Глава 2. Інформаційно-програмна часть.________ _________19

2.1 Функціональні можливості сістеми____________________20

2.2. Побудова моделі БД. __________________________________21

2.3. Инфологическая модель БД_______________________________22

2.4. Вибір СУБД.___________________________________________28

2.5. Побудова датологіческой моделі.________________________33

Глава 3.ОРГАНІЗАЦІЙНА - технологічна частина _____________43

3.1. Загальна структура організації робіт по

проектування ПП._________________________________________44

3.1.1. Постановка задачи.______________________________________44

3.1.2. Складання проекта.___________________________________45

3.1.3. Алгоритмізація. _______________________________________46

3.1.4. Програмування. _____________________________________49

3.1.5. Препарацuя ____________________________________________50

3.1.6. Трансляція. ___________________________________________50

3.1.7. Отладка._______________________________________________51

3.1.8. Оформлення программы.______________________________52

3.1.9. Перевірка правильності расчетов.______________________53

3.1.10. Звіт про роботу. __________________________________54

3.1.11. Модернізація. __________________________________54

3.2. Необхідність налагодження розробленого програмного продукта_______________________________________________55

3.3. Методи і засоби отладкі_________________________58

3.3.1 Контроль программи______________________________58

3.3.2. Контроль результатов_______________________________60

3.3.3. Класифікація методів контроля_____________________63

3.3.4. Локалізація ошібок.________________________________64

3.3.5. Технологія налагодження программи_______________________67

Введення.

Поступово з розвитком програмного забезпечення ЕОМ з'явилися ідеї створення управляючих систем, які дозволяли б накопичувати, зберігати і оновлювати взаємопов'язані дані з цілого комплексу розв'язуваних завдань. Ці ідеї знайшли своє втілення в системах управління базами даних (СКБД). СУБД взаємодіють не з локальними, а взаємопов'язаними за інформацією масивами, званими базами даних. З появою персональних комп'ютерів СУБД стають найбільш популярним засобом обробки табличної інформації. Вони є інструментальним засобом проектування банків даних при обробці великих обсягів інформації.
На сьогоднішній день обробка заявок в ремонтно-будівельної компанії (РСК) проводиться «вручну», що призводить до великих витрат часу, що в більшості випадків викликає невдоволення клієнтів.
Дана система управління заснована на взаємодії декількох баз даних, створених за допомогою середовища ACCESS. Вищевказана система стосується тієї частини роботи РСК, яка пов'язана з надходженням і обробкою заявки на ремонт. Описуваний програмний комплекс сприяє скороченню тимчасового інтервалу від звернення замовника в РСК до укладення договору про проведення робіт; знижує витрати на обробку первинної інформації про об'єкт; містить нормативно - довідкову інформацію; веде облік клієнтів.
Основна перевага системи полягає в обробці заявок за структурою: First Input First Output (FIFO), тому що при надходженні заявки, відбувається її обробка, і клієнт одразу ж отримує відповідь про вартість проведення ремонту і список матеріалів, необхідних для виконання ремонтних робіт. Таким чином створюється сприятливий психологічний клімат при роботі менеджера РСК з клієнтами.
Так само до достоїнств програми варто віднести те, що вона розроблена в рамках дипломного проекту, що значно знижує її собівартість.

Глава 1.

Аналітична частина.

Розробив Солнцев М. А.
Керівник Гагаріна Л. Г.

1.1. Структура ремонтно-будівельної компанії

У даному дипломному проекті зачіпається діяльність фірми, яка надає послуги в галузі ремонту та будівництва житлових будинків і громадських споруд.
На сьогоднішній день, для нормального функціонування, будь-яка ремонтно-будівельна компанія (РСК) обов'язково повинна мати у своєму складі хоча б наступні підрозділи:
1. Адміністративний відділ;
2. Розрахунково-економічний відділ;
3. Відділ маркетингу;
4. Відділ по роботі з клієнтами;
5. Відділ постачання;
6. Виробничий відділ.
Адміністративний відділ, в особі директора, забезпечує загальне керівництво колективом і вирішення принципових технічних завдань, пов'язаних з вибором портфеля замовлень, забезпеченням конструкторської та технологічної документації, закупівлею обладнання і стандартною оснащення і т.п.
Він же веде оперативне управління справами підприємства. При вирішенні цих завдань керівник при необхідності залучає інших фахівців, доручаючи їм виконання конкретних завдань.
Розрахунково-економічний відділ здійснює бухгалтерську звітність та техніко-економічне планування. Бухгалтер виконує розрахункові роботи, оформляє необхідну документацію. Стежить за точністю і своєчасністю розрахунків з споживачами, постачальниками та органами податкового контролю. Складає підсумкові бюджетні звіти для надання в податкові органи. Бере активну участь в плануванні в області податкової і цінової політики підприємства.
Основним завданням відділу маркетингу є ефективне управління рекламною компанією фірми. Сюди можна віднести аналіз рекламних видань і розміщення реклами в найбільш популярних з них, розповсюдження листівок, участь у спеціалізованих виставках і т.п.
Відділ по роботі з клієнтами займається прийомом і обробкою заявок громадян і організацій в РСК на проведення ремонтно-будівельних робіт. Потім первинна інформація передається виконробу фірми (особі, що займається проведенням робіт на об'єктах і складанням кошторисної документації), який зустрічається з потенційним замовником, робить необхідні заміри об'єкта, після чого проводить розрахунок вартості послуг на проведення робіт. На підставі цього розрахунку замовник приймає рішення про укладення договору з даною компанією.
Відділ постачання займається закупівлею і доставкою матеріалів, необхідного інвентарю та інструменту на об'єкти під час проведення робіт. Тут так само виробляють підбір матеріалу за якісними і вартісними характеристиками. Постачання комплектуючих здійснюється відповідно до складеного виконробом графіку проведення робіт на об'єкті.
Виробничий відділ займається безпосередньо проведенням робіт на об'єктах, з якими укладено договори підряду. За кожним об'єктом закріплюється особа відповідальна за проведення робіт на даному об'єкті (виконроб). Виконроб займається розрахунком і підбором необхідної кількості фахівців для проведення ремонту, складає докладний поетапний графік проведення робіт. Під час ремонту суворо контролюється дотримання графіка, технології та якості робіт.

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

Вище були розглянуті функції різних підрозділів РСК. Безсумнівно, робота кожного з них дуже важлива, але хотілося б приділити особливу увагу відділу по роботі з клієнтами, від ефективності роботи якого багато в чому залежить фінансовий стан всього підприємства в цілому.
У даній дипломній роботі була поставлена ​​задача по розробці програмного продукту (ПП), який дозволить ремонтно-будівельної компанії (РСК) значно скоротити проміжок часу від звернення потенційного клієнта фірми до укладення договору про проведення робіт. У той же час розробляється ПП дозволить скоротити роботу персоналу компанії по обробці «порожніх», тобто не проходять замовлень. Це, у свою чергу, веде до значної економії коштів, тому що обробка одного замовлення займає не менше восьми годин висококваліфікованого фахівця. Відзначу також, що програма дозволяє фахівцеві Відділу по роботі з клієнтами проводити облік звернень і кваліфіковано вести діалог із замовниками, представляючи досить складну спеціальну інформацію.

1.3. Аналіз необхідності впровадження автоматизованої системи.

В даний час в РСК обробка звернень громадян і організацій, з приводу проведення ремонтно-будівельних робіт, відбувається «вручну», що відображує на рис.1.

Замовник

Менеджер по роботі з клієнтами

Виконроб

Директор

Відомості про замовлення

Довідкова інформація

Надання кошторисної документації

		Укладення договору

 

Рис.1 Структурна схема неавтоматизованої системи обробки заявок
На вищенаведеною схемою простежується кілька етапів передачі інформації:
1. Замовник звертається на фірму до менеджера по роботі з клієнтами, для подачі заявки на проведення ремонтно-будівельних робіт.
2. Менеджер по роботі з клієнтами відправляє відомості про замовлення виконробу.
3. Виконроб виїжджає на об'єкт, для уточнення відомостей про ремонтні роботи, проводить необхідні виміри. Після цього складається кошторисна документація.
4. Складені документи передаються менеджеру по роботі з клієнтами.
5. Менеджер представляє кошторисну документацію замовнику.
6. Замовник, на підставі наданого пропозиції, приймає рішення про подальшу співпрацю з РСК.
7. Результати прийнятого рішення менеджер надає директору фірми.
8. При обопільній згоді укладається договір між фірмою і замовником.
При такому положенні справ на обробку однієї заявки витрачається кілька днів. Крім того, менеджер вищевказаного відділу повинен володіти досить великим обсягом спеціальної інформації. Так само не можна забувати, що в такій схемі обробки інформації бере участь ще одна особа - виконроб. Від нього залежить, наскільки швидко він зможе зв'язатися з замовником, провести розрахунки і скласти необхідну документацію. При цьому не слід забувати, що виконроб так само буває зайнятий виробництвом робіт на інших об'єктах. Пропонований ПП «Автоматизована інформаційна система ремонтно-будівельного підприємства (АІС РСК)» передбачає зовсім інший підхід до обробки заявок. Це можна побачити на рис. 2:

Замовник

АІС

Менеджер по роботі з клієнтами

Укладення договору

Довідкова інформація

Надання кошторисної документації

			Директор

Рис.2. Структурна схема автоматизованої системи обробки заявок
На цій схемі проходження інформації здійснюється наступним чином:
1. Замовник звертається на фірму до менеджера по роботі з клієнтами для подачі заявки на проведення ремонтно-будівельних робіт.
2. Менеджер по роботі з клієнтами звертається до АІС РСК. Він заповнює картку клієнта, і система видає всі необхідні розрахунки та інформацію згідно запитів.
3. На підставі отриманої інформації замовник приймає рішення про подальшу співпрацю з РСК
4. Результати прийнятого рішення менеджер надає директору фірми.
5. При обопільній згоді укладається договір між фірмою і замовником.
На підставі поданої схеми та описи можна побачити, що процес обробки заявок значно спрощується. Завдяки АІС необхідну інформацію про вартість робіт на об'єкті клієнт отримує протягом декількох хвилин. Так само ми бачимо, що на цьому етапі роботи підприємства зникає необхідність в яких-небудь дії з боку виконроба. Обсяг інформації, якою повинен володіти менеджер по роботі з клієнтами значно зменшується, тому що всю необхідну спеціальну інформацію містить АІС.
Виходячи з усього вище сказаного, користь від пропонованої програми безсумнівна.

1.4. Технічне завдання на розробку.

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

1. Введення.

1.1. Найменування

Автоматизована інформаційна система ремонтно-будівельної компанії (АІС РСК) по обліку і опрацювання заявок громадян.
1.2. Коротка характеристика і області застосування.
АІС РСК являє собою інформаційну систему для автоматизації введення, реєстрацію та видачу інформації про вартість проведення робіт. АІС призначена в основному, для використання в малих і середніх РСК.
2. Підстава для розроблення:
Завдання на дипломний проект.
3. Призначення та мета створення системи
3.1. Призначення розробки:
Програмний продукт (ПП) призначений для обліку та обробки заявок громадян і організацій в РСК, та подання звітів у вигляді калькуляційних відомостей.
3.2.Целі створення:
· Автоматизація обліку та обробки заявок громадян в РСК;
· Скорочення тимчасового інтервалу від звернення замовника в РСК до укладення договору про проведення робіт;
· Зниження витрат на обробку первинної інформації про об'єкт;
· Створення сприятливого психологічного клімату при роботі з клієнтами.
4. Технічні вимоги
4.1. Вимоги до функціональних характеристик
4.1.1. Склад виконуваних функцій:
· Надання готових форм для введення вихідних даних;
· Оброблення вихідних даних та складання кошторисів;
· Складання спеціальних форм звітів.
4.1.2. Організація вхідних і вихідних даних:

3.1.3. Алгоритмізація.

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

3.1.4. Програмування.

У випадку, коли на попередньому етапі був отриманий детально розроблений алгоритм, складання програми на обраному для програмування мовою зводиться до перекладу цього алгоритму на мову програмування.
Основні труднощі і, отже, причини помилок на цьому етапі полягають, по-перше, у необхідності знання всіх вимог і обмежень вибраної мови програмування і, по-друге, у необхідності постійної уваги до багатьох деталей мови, які доводиться враховувати в ході написання програми. Якщо етап 3 був виконаний неякісно і алгоритм представлений недостатньо детально, то його доведення доведеться виконувати «на ходу», під час програмування. Це утруднить процес програмування-перекладу і поведе до виникнення додаткових помилок в програмі. Чим більше процес програмування буде походити на переказ, чим більш механічним буде такий переклад, тим більш легким буде складання програми і тим менше виникне помилок на цьому етапі, самому щедрому на помилки.
Після складання програми проводиться її перевірка для виявлення та виправлення помилок, внесених на цьому етапі. Якщо при перевірці виявляються помилки, допущені на попередньому етапі (3), то відповідні виправлення вносяться і до алгоритму, оскільки до нього ще доведеться звертатися на наступних етапах, і тексти алгоритму і програми повинні відповідати один одному.

3.1.5. Препарації

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

3.1.6. Трансляція.

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

3.1.7. Налагодження.

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

3.1.8. Оформлення програми

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

3.1.9. Перевірка правильності розрахунків.

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

3.1.10. Звіт про роботу.

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

3.1.11. Модернізація.

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

3.2. Необхідність налагодження розробленого програмного продукту

Виявляється, практично неможливо скласти реальну програму без помилок, і майже неможливо для досить складної програми швидко знайти і усунути всі наявні в ній помилки.
При розробці алгоритму програми вирішуються тактичні питання проведення налагодження, намічаються способи контролю окремих блоків і прийоми майбутньої локалізації помилок у них. Для цього проектуються контрольні приклади, за алгоритмами (блок-схемами) намічаються місця і моменти необхідної налагоджувальної друку і вибираються виводяться на друк дані, які повинні забезпечити можливість швидкої локалізації помилок при налагодженні (на етапі (ЛВ)). Розробляючи алгоритм, слід, таким чином, враховувати, чи можна буде досить просто проконтролювати програму, складену за обраним алгоритмом, і у випадку, коли передбачаються великі труднощі, потрібно віддати перевагу іншому, більш вигідному для етапу налагодження, алгоритмом. Потрібно завжди пам'ятати, що головним критерієм цінності програми є її правильність, і для гарантування такої властивості про грами слід жертвувати іншими показниками, такими, наприклад, як швидкість роботи або необхідний обсяг пам'яті. Давно пішли в минуле ті часи, коли програму оцінювали лише за кількістю команд в ній.
У початківців програмістів викладений плановий підхід до проведення налагодження викликає спочатку труднощі, оскільки їм доводиться розробляти план налагодження для неіснуючої поки програми. Але немає іншого шляху освоєння цього ефективного способу, окрім як розвивати в собі навички планування своєї роботи і передбачення особливостей майбутньої налагодження програми з її проектом і загальним алгоритмам. Чим на більш ранній стадії розробки програміст починає займатися питаннями налагодження програми, тим менше неприємних несподіванок чекає його в майбутньому. Надії на те, що усунення помилок з програми і отримання правильних результатів відбудеться якось само собою, без витрати особливих зусиль, ніколи не виправдовуються. Взагалі, оптимізм і самовпевненість для програміста на стадії розробки протипоказані; вони можуть бути корисними лише на стадії налагодження при затяжній боротьбі з дуже глибоко прихованими помилками.
Приблизне розподілення між етапами загального часу, необхідного для розробки досить складних програм, виглядає наступним чином:
1. Отримання завдання, складання проекту програми і загального плану налагодження 10%
2 Розробка алгоритму (1.5%) і детального плану налагодження 20%
3Программірованіе (5%) та виготовлення тестів 5%
4 - 5. Препарації і перша трансляція 5%
6. Налагодження 40%
7. Оформлення програми 10%
Наведені цифри відображають той факт, що в процесі розробки програми роботи з доведення (демонстрації) правильності програми, що розробляється рівнозначні робіт по її виготовленню (проектування, алгоритмізації та написання), що можна виразити наступною формулою:
розробка програми = виготовлення + доказ.
Звичайно, для простих завдань розподіл часу між етапами буде дещо іншим, за рахунок збільшення частки програмування по відношенню до алгоритмізації і налагодженні. Але, як правило, час, що витрачається на роботи, пов'язані з налагодженням, складає близько половини всього часу, необхідного на розробку програми. Тому питання мінімізації часу, необхідного на налагодження, має особливе значення. До його рішенню можна підійти з двох сторін:
а) шляхом прискорення пошуку і виправлення помилок, що є в програмі;
б) шляхом зменшення кількості помилок, які допускаються при розробці алгоритму і складанні програми.

3.3. Методи і засоби налагодження

3.3.1. Контроль програми

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

3.3.2. Контроль результатів

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

3.3.3. Класифікація методів контролю

КОНТРОЛЬ
1. По тексту.
1.1. Без ЕОМ.
1.1.1. Перегляд.
1.1.2. Перевірка.
1.1.3. Прокрутка.
1.2. З ЕОМ.
1.2.1. Друк.
1.2.2. Трансляція (синтаксичний контроль).
1.2.3. Статичний аналіз.
2. За результатами.
3.1. Тестування.
3.1.1. Алгоритмічне.
3.1.2. Функціональне.
3.1.3. Змістовне.
3.2. Спеціальні методи.

3.3.4. Локалізація помилок.

Способи локалізації
Після того, як за допомогою контрольних тестів (або якимось іншим шляхом) встановлено, що в програмі або в конкретному її блоці є помилка, виникає завдання її локалізації, тобто встановлення точного місця в програмі, де знаходиться помилка.
Процес локалізації помилок складається з наступних трьох компонент:
1. Одержання на машині тестових результатів.
2.. Аналіз тестових результатів і звірка їх з еталонними.
3.. Виявлення помилки або формулювання припущення про характер і місце помилки в програмі.
За принципами роботи засоби локалізації поділяються на 4тіпа:
1. Аварійна друк.
2. Друк у вузлах.
3. Слідкування.
4. Прокрутка.
АВАРІЙНА ДРУК здійснюється один раз при роботі налагоджують програму, в момент виникнення аварійної ситуації в програмі, що перешкоджає її нормальному виконанню. Тим самим, конкретне місце включення в роботу аварійної друку визначається автоматично без використання інформації від програміста, який повинен тільки визначити список видаються на друк змінних.
ДРУК У ВУЗЛАХ включається в роботу у вибраних програмістом місцях програми; після здійснення друку значень даних змінних продовжується виконання відлагоджує програми.
Слідкування проводиться або по всій програмі, або на заданому про грам истом ділянці. Причому стеження може здійснюватися як за змінними (арифметичне стеження), так і за операторами (логічне стеження). Якщо буде виявлено, що відбувається присвоювання заданої змінної або виконання оператора із заданою міткою, то проводиться друк імені змінної або мітки і виконання програми продовжується. Відмінністю від друку у вузлах є те, що місце друку може точно і не визначатися програмістом (для арифметичного стеження); відрізняється також і зміст друку.
ПРОКРУЧУВАННЯ виробляється на заданих ділянках програми, і після виконання кожного оператора заданого типу (наприклад, присвоєння або поміченого) відбувається налагоджувальна друк.
Класифікація засобів локалізації помилок
Нижче наведена класифікація засобів локалізації.
Засоби локалізації:
1. Аварійна друк (арифметична).
1.1. Спеціальні засоби мови.
1.2. Системні засоби.
2. Друк у вузлах (арифметична).
2.1. Звичайні засоби мови.
2.2. Спеціальні засоби мови.
3. Слідкування (спеціальні кошти).
3.1. Арифметичне.
3.2. Логічне.
4. Прокрутка (спеціальні кошти).
4.1. Арифметична.
4.2. Логічна.

3.3.5. Технологія налагодження програми

Розглянемо етапи створення даної програми, виходячи з наведених вище методах і прийомах.
Зазвичай рано чи пізно настає такий момент, коли виникає питання про необхідність створення програми. Перед нами стояло саме таке завдання. Тобто нам необхідно було, створити програму, розраховану на не фахівців в області комп'ютерної техніки, тобто програму з відмінно пропрацював інтерфейсом для зручності та доступності користувачем. ТЗ видавалося поступово, уточнювалося і змінювалося. У залежності від цього програма розроблялася поетапно. Алгоритмізація в нашому випадку охоплює, як програму цілком, так і по блоках, для процедур і функцій.
При налагодженні програми використовувалися такі методи контролю і локалізації помилок (огляд методів див. в теоретичній частині розділу):
1. Перегляд тексту програми і прокрутка з метою виявлення явних синтаксичних і логічних помилок.
2. Трансляція програми (транслятор видає повідомлення про виявлені ним помилки в тексті програми).
3. При локалізації помилок переважно використовувалася друк у вузлах, якими були в основному глобальні змінні, змінні, використовувані при обміні даними основний про грами з підпрограмами стеження. Також звірялися типи одержуваних даних, що дозволяє виявити помилки розбіжності типів, які не видно при компіляції.
Відомо, що існує проблема сприйняття інформації з екрана монітора. Щоб уникнути цього ми використовували роздруківки програми на різних етапах розробки і налагодження.
У загальному випадку налагодження програми проводилася за наступним алгоритмом:
1. Прогонка програми з набором тестових вхідних даних і наявності помилок.
2. Виділення області програми, в якій може перебувати помилка. Перегляд лістингу програми з метою можливого виявлення помилок. В іншому випадку - установка контрольної точки приблизно в середині виділеної області.
3. Нова прогонка програми. Якщо робота програми перервалася до обробки контрольної точки, значить, помилка сталася раніше. Контрольна точка переноситься, і процес налагодження повертається до кроку 2.
4. Якщо контрольна точка програми була оброблена, то далі йде вивчення значень регістрів, змінних і параметрів програми з тим, щоб переконатися в їх правильності. При появі помилки - нове перенесення контрольної точки і повернення до кроку 2
5. У разі не виявлення помилки продовження виконання програми покомандно, з контролем правильності виконання переходів та вмісту регістрів і пам'яті у контрольних точках. При локалізації помилки вона виправляється, і процес повертається до кроку 1.
Вирішальним етапом, що встановлює придатність програми для роботи, є її контроль за результатами її виконання на ЕОМ. Найбільш універсальним методом перевірки для всіх класів задач є метод контрольних тестів або тестування.
У процесі налагодження створеної програми, було виявлено ряд помилок. На підставі результатів аналізу виконаної роботи по їх усуненню була розроблена інструкція по користуванню створеної Автоматизованої системою та запропоновано методи усунення можливих помилок.