[ Розробка бази даних для інформатизації діяльності підприємства малого бізнесу Delphi 70 ] | Площа приміщення | |
ВисотаСтен | Поле МЕМО | Висота стін |
Підлоги | Текстовий | Остаточна обробка підлоги |
Стіни | Текстовий | Остаточна обробка стін |
Стеля | Текстовий | Остаточна обробка стелі |
Двері | Числовий | Кількість дверей |
Перегородки | Поле МЕМО | Периметр перегородок |
Таблиця 2.3.
Таблиця «Роботи»
Ім'я поля | Тип даних | Опис |
КодРабот | Лічильник | Ідентифікатор |
КодТіпа | Числовий | Тип робіт |
Робота | Текстовий | Найменування роботи |
ЕдІзм | Текстовий | Одиниці виміру |
Ціна | Грошовий | Ціна одиниці роботи |
Таблиця 2.4.
Таблиця «Типи робіт»
Ім'я поля | Тип даних | Опис |
КодТіпа | Лічильник | Ідентифікатор |
Тип | Текстовий | Тип робіт |
Таблиця 2.5.
Таблиця «Одиниці виміру»
Ім'я поля | Тип даних | Опис |
КодЕдІзмеренія | Лічильник | Ідентифікатор |
ЕдІзмеренія | Текстовий | Одиниці виміру |
Таблиця 2.6.
Таблиця «Матеріали»
Ім'я поля | Тип даних | Опис |
КодМатеріала | Лічильник | Ідентифікатор |
Матеріал | Текстовий | Найменування матеріалу |
КодЕдІзмеренія | Числовий | Одиниці виміру |
Ціна | Грошовий | Ціна матеріалу |
Таблиця 2.7.
Таблиця «Норми витрати»
Ім'я поля | Тип даних | Опис |
КодНорми | Лічильник | Ідентифікатор |
КодРабот | Числовий | Найменування робіт |
КодМатеріала | Числовий | Найменування матеріалу |
Одиниці | Числовий | Одиниці виміру |
Кількість | Поле МЕМО | Кількість |
Таблиця 2.8.
Таблиця «Список робіт»
Ім'я поля | Тип даних | Опис | ||||||||||
КодОкончРаботи | Лічильник | Ідентифікатор | ||||||||||
ОкончатРабота | Текстовий | Остаточна робота | ||||||||||
КодРабот
Таблиця 2.9. Таблиця «ЗакзиРаботи»
Курсивом у таблицях виділений ключовий стовпець. Зв'язки між таблицями виглядають наступним чином: Рис. 2.2. Зв'язування таблиць На малюнку показана організація зв'язків між таблицями. Зв'язки між таблицями об'єднані загальною тематикою. Рис.2.3. Загальний алгоритм роботи програми. При проектуванні робочої моделі системи, з урахуванням інформаційних потреб користувача, був розроблений загальний алгоритм роботи програми, який зображений на рис.2.3. . З цього малюнка добре проглядаються функціональні можливості системи. Ці можливості реалізуються через окремі блоки підпрограм. При вході в головне меню системи, користувач вибирає один з пунктів меню, що і є в кінцевому підсумку вибором конкретної підпрограми. Функціональні особливості підпрограм полягають у наступному:
Рис. 2.4. Алгоритм роботи підпрограми редагування таблиць Глава 3. Організаційно - технологічна частина Розробив Солнцев М. А. Керівник Гагаріна Л. Г. 3.1. Загальна структура організації робіт з проектування ПП. 3.1.1. Постановка завдання. Завдання, яке належить вирішити програмісту на ЕОМ, формулюється ним самим або видається йому у вигляді спеціального завдання на розробку програми. Завдання містить формулювання завдання, необхідні характеристики, що розробляється, вимоги до взаємодії з нею. Видачі такого завдання для великих завдань може передувати велика робота науково-дослідного характеру. Завдання на розробку програми за формою і характером має бути аналогічним технічним завданням (ТЗ) на розробку якого-небудь технічного продукту (див., наприклад, ГОСТ 19.201-78 Єдиної системи програмної документації). Технічне завдання корисно і в тому випадку, коли замовник і виконавець працюють в одній і тій же кімнаті або навіть є одним і тим же особою. Наявність чіткої письмовій формулювання буде перешкоджати підміну або відходу в процесі розробки програми від сформульованих в ТЗ вимог на догоду якимось іншим побічним цілям. Крім того, письмово сформульоване завдання робить можливим обговорення, оцінку або узгоджену з замовниками (користувачами) коригування окремих вимог ТЗ під час розробки програми. ТЗ перешкоджає проникненню в програму таких помилок і протиріч, які можуть бути виявлені тільки після розробки більшої частини програми або вже на стадії аналізу отриманих результатів рахунки. Чим більше формалізованим за характером буде технічне завдання, тим більше шансів, що розробляється програма буде вирішувати саме те завдання, яке мав на увазі замовник. Технічне завдання повинно містити також вимоги чи вказівки, що стосуються принципів перевірки і випробувань готової програми. 3.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%
4 - 5. Препарації і перша трансляція 5% 6. Налагодження 40% 7. Оформлення програми 10% Наведені цифри відображають той факт, що в процесі розробки програми роботи з доведення (демонстрації) правильності програми, що розробляється рівнозначні робіт по її виготовленню (проектування, алгоритмізації та написання), що можна виразити наступною формулою: розробка програми = виготовлення + доказ. Звичайно, для простих завдань розподіл часу між етапами буде дещо іншим, за рахунок збільшення частки програмування по відношенню до алгоритмізації і налагодженні. Але, як правило, час, що витрачається на роботи, пов'язані з налагодженням, складає близько половини всього часу, необхідного на розробку програми. Тому питання мінімізації часу, необхідного на налагодження, має особливе значення. До його рішенню можна підійти з двох сторін: а) шляхом прискорення пошуку і виправлення помилок, що є в програмі; б) шляхом зменшення кількості помилок, які допускаються при розробці алгоритму і складанні програми. 3.3. Методи і засоби налагодження 3.3.1. Контроль програми Під етап контролю програми характеризується як етап вирішення завдання, метою якого є встановлення наявності помилок у складеній програмі або переконлива демонстрація їх відсутності. Якщо буде встановлено, що помилки в програмі є, то на наступному етапі (етап локалізації) буде проводитися їх пошук. Тому в завдання контролю входить також отримання ще й такої інформації про характер роботи програми, яка могла б допомогти в подальшому при пошуку помилок. Контроль тексту Контроль тексту програми можна робити як "вручну", так і з застосуванням ЕОМ. Спочатку розглянемо "ручні" методи контролю тексту програм (алгоритмів). Можна розрізняти три способів контролю тексту без застосування ЕОМ: перегляд, перевірка і прокрутка. Перегляд Текст складеної програми уважно проглядається на предмет виявлення помилок, описок і смислових розбіжностей з текстом алгоритму, за яким здійснювалось програмування. Крім суцільного перегляду застосовується ще і вибірковий перегляд деяких фрагментів програми. Перевірка При перевірці програми програміст по тексту програми подумки намагається відновити той обчислювальний процес, який визначає програма, після чого звіряє його з необхідним процесом, тобто ТЗ, визначеному в проекті. Прокрутка Іншим способом контролю програм та алгоритмів за столом є прокрутка (іноді її називають "сухою" прокручуванням - dry running - для відмінності від методу прокручування, застосовуваного на етапі локалізації та використовує ЕОМ). Основою прокручування є імітація програмістом виконання програми на машині, з метою більш конкретного і наочного уявлення про процес, який визначається текстом програми, що перевіряється. Прокрутка дає можливість наблизити послідовність перевірки програми до послідовності її виконання, що дозволяє перевіряти програму як би в динаміці її роботи, перевіряти елементи обчислювального процесу, що задається перевіряється програмою а не тільки статичний текст програми. Для виконання прокручування зазвичай доводиться задаватися якимись вихідними даними і робити над ними необхідні обчислення. Друк тексту Для перевірки правильності препарації програми (перенесення тексту на будь-які машинні носії) після введення в машину проводиться друк тексту програми для подальшої його звірки з вихідним текстом. 3.3.2. Контроль результатів Як би не була ретельно перевірена і прокручена програма за столом, вирішальним етапом, що встановлює її придатність для роботи, є контроль програми за результатами її виконання на ЕОМ. Найбільш універсальним методом перевірки для всіх класів задач є метод контрольних тестів або тестування. Тестом будемо називати інформацію, що складається з вихідних даних, спеціально підібраних для налагодженої програми, і з відповідних їм еталонних результатів (не тільки остаточних, але і проміжних), використовуваних в подальшому для контролю правильності роботи програми. Тестування Під тестуванням слід розуміти процес виконання програми з метою виявлення помилок, у якості яких приймається будь-яке відхилення від еталонів. Гарним вважається тест, який має високу ймовірність виявлення ще не виявлених помилок. Під налагодженням розуміється процес, що дозволяє отримати програму, яка функціонує з необхідними характеристиками в заданій області вхідних даних. Таким чином, в результаті налагодження програма повинна відповідати деякої фіксованої сукупності правил і показників якості, прийнятої за еталонну для даної програми. Існує 3 основних способи тестування: алгоритмічне, аналітичне, змістовне. Алгоритмічне тестування Алгоритмічне тестування застосовується програмістом для контролю етапів алгоритмізації та програмування. Програмісти проектують тести і починають готувати еталонні результати на етапі алгоритмізації, а використовують їх на етапі налагодження. Функціональне або аналітичне тестування Аналітичне тестування служить для контролю обраного методу розв'язання задачі, правильності його роботи в обраних режимах і з встановленими діапазонами даних. Тести проектують і починають готувати відразу після вибору методу, а використовують їх на останньому етапі налагодження або для аналізу результатів пробного рахунку; в ході тестування, поряд із звіркою на збіг, застосовуються і якісні оцінки результатів. Змістовне тестування Змістовне тестування служить для перевірки правильності постановки завдання. Для контролю при цьому використовуються, як правило, якісні оцінки та статистичні характеристики програми, фізичний зміст отриманих результатів і т.п. у проведенні змістовного тестування, принципи якого формулюються в технічному завданні, найактивнішу участь повинні брати замовники або йдуть користувачі програми. Змістовні та аналітичні тести перевіряють правильність роботи програми в цілому або великих її частин, у той час як алгоритмічні тести в першу чергу повинні перевіряти роботу окремих блоків або операторів програми. 3.3.3. Класифікація методів контролю КОНТРОЛЬ
2. За результатами.
3.3.4. Локалізація помилок. Способи локалізації Після того, як за допомогою контрольних тестів (або якимось іншим шляхом) встановлено, що в програмі або в конкретному її блоці є помилка, виникає завдання її локалізації, тобто встановлення точного місця в програмі, де знаходиться помилка. Процес локалізації помилок складається з наступних трьох компонент:
За принципами роботи засоби локалізації поділяються на 4тіпа:
АВАРІЙНА ДРУК здійснюється один раз при роботі налагоджують програму, в момент виникнення аварійної ситуації в програмі, що перешкоджає її нормальному виконанню. Тим самим, конкретне місце включення в роботу аварійної друку визначається автоматично без використання інформації від програміста, який повинен тільки визначити список видаються на друк змінних. ДРУК У ВУЗЛАХ включається в роботу у вибраних програмістом місцях програми; після здійснення друку значень даних змінних продовжується виконання відлагоджує програми. Слідкування проводиться або по всій програмі, або на заданому про грам истом ділянці. Причому стеження може здійснюватися як за змінними (арифметичне стеження), так і за операторами (логічне стеження). Якщо буде виявлено, що відбувається присвоювання заданої змінної або виконання оператора із заданою міткою, то проводиться друк імені змінної або мітки і виконання програми продовжується. Відмінністю від друку у вузлах є те, що місце друку може точно і не визначатися програмістом (для арифметичного стеження); відрізняється також і зміст друку. ПРОКРУЧУВАННЯ виробляється на заданих ділянках програми, і після виконання кожного оператора заданого типу (наприклад, присвоєння або поміченого) відбувається налагоджувальна друк. Класифікація засобів локалізації помилок Нижче наведена класифікація засобів локалізації. Засоби локалізації:
3.3.5. Технологія налагодження програми Розглянемо етапи створення даної програми, виходячи з наведених вище методах і прийомах. Зазвичай рано чи пізно настає такий момент, коли виникає питання про необхідність створення програми. Перед нами стояло саме таке завдання. Тобто нам необхідно було, створити програму, розраховану на не фахівців в області комп'ютерної техніки, тобто програму з відмінно пропрацював інтерфейсом для зручності та доступності користувачем. ТЗ видавалося поступово, уточнювалося і змінювалося. У залежності від цього програма розроблялася поетапно. Алгоритмізація в нашому випадку охоплює, як програму цілком, так і по блоках, для процедур і функцій. При налагодженні програми використовувалися такі методи контролю і локалізації помилок (огляд методів див. в теоретичній частині розділу):
Відомо, що існує проблема сприйняття інформації з екрана монітора. Щоб уникнути цього ми використовували роздруківки програми на різних етапах розробки і налагодження. У загальному випадку налагодження програми проводилася за наступним алгоритмом:
Вирішальним етапом, що встановлює придатність програми для роботи, є її контроль за результатами її виконання на ЕОМ. Найбільш універсальним методом перевірки для всіх класів задач є метод контрольних тестів або тестування. У процесі налагодження створеної програми, було виявлено ряд помилок. На підставі результатів аналізу виконаної роботи по їх усуненню була розроблена інструкція по користуванню створеної Автоматизованої системою та запропоновано методи усунення можливих помилок. Будь ласка, не зберігайте тестовий текст. |