Цей стандарт встановлює порядок побудови та оформлення технічного завдання на розробку програми або програмного виробу для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Стандарт повністю відповідає СТ РЕВ 1627-79.
Правила оформлення
Технічне завданняоформляють відповідно до ГОСТ 19.106-78 на аркушах формату 11 та 12 за ГОСТ 2.301-68, як правило, без заповнення полів аркуша. Номери аркушів (сторінок) проставляються у верхній частині аркуша над текстом.
Лист затвердження та титульний лист
Лист затвердження та титульний лист оформляють відповідно до ГОСТ 19.104-78.
Інформаційну частину (анотацію та зміст), лист реєстрації змін допускається до документа не включати.
Зміни та доповнення
Для внесення змін або доповнень до технічного завдання на наступних стадіях розробки програми або програмного виробу випускають доповнення до нього. Узгодження та затвердження доповнення до технічного завдання проводять у тому самому порядку, який встановлено для технічного завдання.
Врахувати всі деталі на початковому етапірозробки неможливо. Насправді зазначений підхід застосовується дуже часто. У розділі «Стадії та етапи розробки» слід явно вказати можливість внесення змін та доповнень до технічного завдання: «Вміст розділів цього технічного завдання може бути змінено та доповнено за погодженням із Замовником».
Склад розділів технічного завдання
Технічне завдання має містити такі розділи:
- Вступ; основи розробки; призначення розробки; вимоги до програми чи програмного виробу; вимоги до програмної документації; техніко-економічні показники; стадії та етапи розробки; порядок контролю та приймання; до технічного завдання допускається включати додатки.
Залежно від особливостей програми чи програмного виробу допускається уточнювати зміст розділів, вводити нові розділи чи об'єднувати окремі. Строго за погодженням із Замовником. Згода Замовника обов'язково має бути відображена у тексті технічного завдання.
Як навчально-тренувальну будемо використовувати реальну програму з графічним інтерфейсом користувача, що забезпечує можливість виконання декількох шаблонних функцій (наприклад, нескладний текстовий редактор).
Вступ
У розділі вказують найменування, коротку характеристику області застосування програми чи програмного виробу та об'єкта, у якому використовують програму чи програмний виріб.
Основне правило роботи з текстом - деталізація, дроблення тексту на структурні одиниці, підрозділи, пункти та підпункти. Зміст тексту матиме чітку структуру, що сприятиме легкому пошуку необхідного матеріалу. Текст документа стане структурованим та зручним для читання. Створюємо підрозділи:
Найменування програми
Найменування – "Текстовий редактор для роботи з файлами формату rtf".
Коротка характеристика галузі застосування
Програма призначена для застосування в профільних підрозділах на об'єктах Замовника.
Вміст окремих пунктів який завжди очевидно. При труднощі слід підходити формально. Правку можна буде внести на етапі узгодження технічного завдання із Замовником.
Підстави для розробки
У розділі мають бути вказані:
Документ (документи), виходячи з яких ведеться розробка; організація, яка затвердила цей документ, та дата його затвердження; найменування та (або) умовне позначенняРозробка теми.
У підрозділі слід навести відомості, що містяться у Договорі.
Підстава для проведення розробки
Підставою для проведення розробки є Договір (лист і т. д.) № 000 від 01.01.01 року (що входить до такого від такого). Договір узгоджений з Директором ДУП «Спецважмонтажбудсільгоспавтоматика» Івановим Петром Івановичем, який іменується надалі Замовником, і затверджений Генеральним директором Блюмкінсом Іваном Ароновичем, який іменується надалі Виконавцем, такого-то березня 2008 року.
Зручно скористатися розділом « Загальні відомості» ГОСТ 34.602-89, оскільки розробник має повне право доповнювати та видаляти розділи технічного завдання на власний розсуд. У той же час відомості, зазначені вище, містяться у Договорі. Чи слід наводити їх у технічному завданні – залежить від конкретного випадку.
Найменування та умовне позначення теми розробки
Назва теми розробки – «Розробка текстового редактора для роботи з файлами формату rtf».
Умовне позначення теми розробки (шифр теми) - "РТФ-007".
Призначення розробки
У розділі має бути зазначено функціональне та експлуатаційне призначення програми чи програмного виробу.
Функціональне призначення
Функціональним призначенням програми є надання користувачеві можливості роботи з текстовими документами у форматі rtf.
У підрозділі має бути зазначено «укрупнене» функціональне призначення програми. Деталі – перелік функцій тощо – будуть наведені нижче, у відповідних розділах.
Отримати повний текстЕксплуатаційне призначення може трактуватись досить широко. Де, як, ким, із чим має експлуатуватися програма?
Гума одного типорозміру може успішно експлуатуватися на Жигулях та Волгах, але не на КамАЗі. І навпаки. Для кожного конкретного типорозміру гуми можна визначити її експлуатаційне призначення.
Застосуємо формальний підхід:
Експлуатаційне призначення
Програма має експлуатуватися у профільних підрозділах на об'єктах Замовника.
Кінцевими користувачами програми повинні бути співробітники профільних підрозділів об'єктів Замовника.
Вимоги до програми чи програмного виробу
Розділ повинен містити такі підрозділи:
Вимоги до функціональних характеристик; вимоги до надійності; умови експлуатації; вимоги до складу та параметрів технічних засобів; вимоги до інформаційної та програмної сумісності; вимоги до маркування та упаковки; вимоги до транспортування та зберігання; спеціальні вимоги.
Якщо є стандарти, що містять загальні (технічні) вимоги до програми, системи або виробу, наприклад, «ГОСТ. Автоматизовані інформаційно-вимірювальні системи. Загальні (технічні) вимоги», розробка технічного завдання значно спрощується. Більшість вмісту зазначеного стандарту просто переписується в технічне завдання.
Вимоги до функціональних характеристик
У підрозділі мають бути зазначені вимоги до складу виконуваних функцій, організації вхідних та вихідних даних, тимчасових характеристик тощо.
Вимоги до складу виконуваних функцій
Програма повинна забезпечувати можливість виконання наведених нижче функцій:
1. Функції створення нового (порожнього) файлу.
2. функції відкриття (завантаження) існуючого файла.
4. функції редагування поточного файлу із застосуванням буфера обміну операційної системи.
5. Функції збереження файлу з вихідним ім'ям.
6. функції збереження файлу з ім'ям, відмінним від вихідного.
7. функції надсилання вмісту поточного файлу електронною поштою за допомогою зовнішньої клієнтської поштової програми.
8. функції виведення оперативних довідок у рядковому форматі (підказок).
9. Функції інтерактивної довідкової системи.
10. функції відображення назви програми, версії програми, копірайту та коментарів розробника.
Кліше «забезпечувати можливість виконання» застосовно до сучасних програмних засобів, розроблених з використанням графічного інтерфейсу користувача. Зазначені програмні засоби здебільшого"Простоюють" (idle), чекаючи дій оператора.
Вимоги до організації вхідних даних
Вхідні дані програми мають бути організовані як окремих файлів формату rtf, відповідних специфікації.
Файли зазначеного формату повинні розміщуватись (зберігатися) на локальних або знімних носіях, відформатованих відповідно до вимог операційної системи.
Будь-який файл іншого формату, але з розширенням rtf відкриватися не повинен.
Файли http:///file. rtf чи ftp:///file. rtf відкриватися не повинні. Якщо файлова система відформатована як FAT32, файли з локального або знімного носія, відформатованого, наприклад, у форматі ext3, не повинні відкриватися.
Вимоги до організації вихідних даних
Див. Вимоги до організації вхідних даних.
Вимоги самі, як і до організації вихідних даних. Той самий випадок, коли слід об'єднати обидва пункти технічного завдання.
Вимоги до тимчасових характеристик
Вимоги до тимчасових характеристик програми не висуваються.
Слід уточнити, чи Замовник пред'являє вимоги до швидкодії програми, наприклад, за який час програма повинна стартувати, відкривати та закривати файли заданого обсягу. Якщо Замовник вкаже конкретні цифри, слід підстрахуватися та закласти у вимогах до складу та параметрів технічних засобів суперкомп'ютер вартістю від $2500. Щоправда, таку суму доведеться доводити. Якщо тимчасові характеристики для Замовника не є принциповими, слід обов'язково написати про відмову від вимог до тимчасових характеристик (див. формулювання вище).
Вимоги до надійності
У підрозділі мають бути зазначені вимоги щодо забезпечення надійного функціонування (забезпечення сталого функціонування, контроль вхідної та вихідної інформації, час відновлення після відмови тощо).
Надійність – річ тонка та дуже небезпечна. Але перелік функцій та видів їх відмов, згідно з п. 1.3.2. ГОСТ 24.701-86, зобов'язаний скласти Замовник та погодити з Виконавцем. Швидше за все, дочекатися від Замовника чогось зрозумілого не вдасться. Варто роз'яснити Замовнику, що надійне функціонування програми залежить не так від Виконавця, як від надійності технічних засобів та операційної системи, а також запропонувати Замовнику низку жорстких заходів для підвищення надійності та стійкості функціонування програми.
Отримати повний текстВимоги щодо забезпечення надійного (стійкого) функціонування програми
Надійне (стійке) функціонування програми має бути забезпечене виконанням Замовником сукупності організаційно-технічних заходів, перелік яких наведено нижче:
Організацією безперебійного живленнятехнічних засобів; використанням ліцензійного програмного забезпечення; регулярним виконанням рекомендацій Міністерства праці та соціального розвитку РФ, викладених у Постанові від 01.01.01 р. «Про затвердження міжгалузевих типових норм часу на роботи з сервісного обслуговування ПЕОМ та оргтехніки та супроводу програмних засобів»; регулярним виконанням вимог ГОСТ. Захист інформації. Випробування програмних засобів на наявність комп'ютерних вірусів.
До списку можна додати ще десяток нормативних документів. У ході первинного узгодження технічного завдання Замовник, швидше за все, почне виявляти схильність до компромісу.
Можливий більш гуманний підхід. Під надійністю (щоправда, системи, за тим самим ГОСТ) вважатимуться безвідмовне виконання певної i-той функції протягом певного інтервалу часу. Запропонуємо Замовнику вважати критерієм надійної роботи програми наступний показник: Замовник протягом години 100 разів відкриває та закриває файл. Якщо у зазначеному інтервалі часу програма не дасть збоїв, вимоги щодо надійності вважаються виконаними.
Якщо Замовник нарешті переконався, що надійність залежить не так від Виконавця, як від надійності технічних засобів та операційної системи, і махнув рукою – у розділі обов'язково слід написати таку фразу:
Вимоги забезпечення надійного (стійкого) функціонування програми пред'являються.
Час відновлення після відмови
Час відновлення після відмови, викликаного збоєм електроживлення технічних засобів (іншими зовнішніми факторами), не фатальним збоєм (не крахом) операційної системи, не повинен перевищувати стільки хвилин за умови дотримання умов експлуатації технічних та програмних засобів.
Час відновлення після відмови, спричиненої несправністю технічних засобів, фатальним збоєм (крахом) операційної системи, не повинен перевищувати часу, необхідного на усунення несправностей технічних засобів та перевстановлення програмних засобів.
Перелік аварійних ситуацій складає Замовник і погоджує з Виконавцем. Фактично, цей час на перезавантаження операційної системи, якщо відмова не фатальна, не викликана крахом операційної системи або виходом з ладу технічних засобів.
Відмовлення через некоректні дії оператора
Відмовлення програми можливі через некоректні дії оператора (користувача) при взаємодії з операційною системою. Щоб уникнути відмов програми з зазначеної вище причини, слід забезпечити роботу кінцевого користувача без надання йому адміністративних привілеїв.
Умови експлуатації
У підрозділі мають бути зазначені умови експлуатації (температура навколишнього повітря, відносна вологість тощо для обраних типів носіїв даних), за яких повинні забезпечуватися задані характеристики, а також вид обслуговування, необхідна кількість та кваліфікація персоналу.
Кліматичні умови експлуатації
Кліматичні умовиЕксплутатації, при яких повинні забезпечуватися задані характеристики, повинні задовольняти вимоги до технічних засобів в частині умов їх експлуатації.
Програма буде чудово працювати від плюс 5 до плюс 35 ° C при відносній вологості 90% та атмосферному тиску 462 мм. рт. ст., оскільки такі умови приблизно відповідають умовам експлуатації сучасних комп'ютерів непромисловоговиконання. Але як тільки в технічному завданні виявиться конкретика і завдання буде затверджено, Замовник отримує відмінний шанс змусити Виконавця провести кліматичні випробування в повному обсязі за рахунок Виконавця.
Вимоги до видів обслуговування
Див. Вимоги щодо забезпечення надійного (стійкого) функціонування програми.
Програма не потребує проведення будь-яких видів обслуговування.
Види обслуговування слід запозичити з підрозділу «Вимоги забезпечення надійного (стійкого) функціонування».
Якщо Замовник під час узгодження технічного завдання пошлеться відсутність ресурсів чи бажання проводити всі види обслуговування власними силами, є сенс запропонувати розробку технічного завдання на супровід програмного засобу окремими договором. Відмовиться – слід вважати програму необслуговуваною.
Вимоги до чисельності та кваліфікації персоналу
Мінімальна кількість персоналу, необхідного для роботи програми, повинна становити не менше 2 штатних одиниць – системний адміністратор та кінцевий користувач програми – оператор.
Системний адміністратор повинен мати вищу профільна освітата сертифікати компанії-виробника операційної системи. До переліку завдань, що виконуються системним адміністратором, повинні входити:
отримати повний текст завдання підтримки працездатності технічних засобів; завдання встановлення (інсталяції) та підтримки працездатності системних програмних засобів – операційної системи; завдання встановлення (інсталяції) програми.Кінцевий користувач програми (оператор) повинен мати практичні навички роботи з графічним інтерфейсом операційної системи.
Персонал повинен бути атестований на ІІ кваліфікаційну групу з електробезпеки (для роботи з конторським обладнанням).
За відсутності самої ключової (жирної) фрази у затвердженому технічному завданні Замовник має право вимагати від Виконавця розробку посібника з експлуатації графічного інтерфейсу операційної системи, мотивуючи тим, що оператор «не справляється» з програмою.
Персонал, який не має ІІ кваліфікаційної групи з електробезпеки, не має права навіть близько підходити до ПЕОМ та конторського обладнання.
Вимоги до складу та параметрів технічних засобів
У підрозділі вказують необхідний склад технічних засобів із зазначенням їх основних технічних характеристик.
Слід підбирати техніку не гірше за ту, на якій проводитиметься розробка. Логічно зажадати, щоб техніку надав Замовник не пізніше зазначеного терміну. Йдеться, зрозуміло, про комп'ютер.
До складу технічних засобів повинен входити IBM-сумісний персональний комп'ютер (ПЕОМ), що включає:
Процесор Pentium-1000 з тактовою частотою, ГГц – 10, не менше; материнську плату з FSB, ГГц – 5, не менше; оперативну пам'ятьобсягом, Тб – 10, не менше; і так далі…
Вимоги до інформаційної та програмної сумісності
У підрозділі мають бути зазначені вимоги до інформаційних структур на вході та виході та методів рішення, вихідних кодів, мов програмування та програмних засобів, що використовуються програмою.
За потреби повинен забезпечуватися захист інформації та програм.
Вимоги до інформаційних структур та методів вирішення
Інформаційна структура файлу повинна включати текст, що містить розмітку, передбачену специфікацією формату rtf.
Вимоги до інформаційних структур (файлів) на вході та виході, а також до методів рішення не пред'являються.
Вимоги до вихідних кодів та мов програмування
Вихідні коди програми мають бути реалізовані мовою C++. Як інтегроване середовище розробки програми має бути використане середовище Borland C++ Buider.
Вимоги до програмних засобів, що використовуються програмою
Системні програмні засоби, що використовуються програмою, мають бути представлені ліцензійною локалізованою версією операційної системи. Допускається використання пакета оновлення такого.
Вимоги до захисту інформації та програм
Вимоги до захисту інформації та програм не висуваються.
Подібних вимог слід уникати. Забезпечити певний рівень захисту інформації та програм можливо, забезпечити безпеку неможливо. Замовник, швидше за все, це усвідомлює і виявляти наполегливість не стане.
Вимоги до маркування та упаковки
Програма постачається у вигляді програмного виробу – на дистрибутивному (зовнішньому оптичному) носії (компакт-диску).
Йдеться про маркування та пакування дистрибутивного носія - програмного виробу (див. ГОСТ 19.004-80).
Вимога до маркування
Програмний виріб повинен мати маркування з позначенням товарного знаку компанії-розробника, типу (найменування), номера версії, порядкового номера, дати виготовлення та номери сертифіката відповідності Держстандарту Росії (якщо є).
Маркування має бути нанесене на програмний виріб у вигляді наклейки, виконаної поліграфічним способом з урахуванням вимог ГОСТ 9181-74.
Якість маркування перевіряється найвитонченішими способами – спочатку намагаються змити маркування водою, потім бензином та іншими органічними розчинниками. Нехай поліграфічне підприємство відповідає за неякісне маркування. Завдання Виконавця – прикритися сертифікатом відповідності (вимагати сертифікат у поліграфістів).
Вимоги до упаковки
Упаковка програмного виробу має здійснюватися в пакувальну тару підприємства-виробника.
Саме підприємства-виробника. Виконавець не може і не повинен нести більшу відповідальність, ніж підприємство-виробник тари.
Умови пакування
Упаковка програмного виробу повинна проводитись у закритих вентильованих приміщеннях при температурі від плюс 15 до плюс 40 °С та відносній вологості не більше 80 % за відсутності агресивних домішок у навколишньому середовищі.
Замовник отримає програмний виріб належного вигляду. У разі повернення програмного виробу в неналежному вигляді (наявність подряпин, тріщин та інших дефектів) Виконавець зможе пред'явити претензії щодо порушення Замовником умов пакування та не прийняти програмний виріб.
Порядок упаковки
Підготовлені до упаковки програмні вироби укладають у тару, що представляє собою коробки з гофрованого картону (ГОСТ 7376-89 або ГОСТ 79 відповідно до креслень підприємства-виробника тари.
Отримати повний текстПрограмний виріб упаковується із застосуванням чохлів із водонепроникної плівки з обов'язковою наявністю хімічно неагресивних вологопоглиначів (силікагелю).
Для заповнення вільного місця в пакувальну тару укладаються прокладки з гофрованого картону або пінопласту.
Експлуатаційна документація має бути укладена в споживчу тару разом із програмним виробом.
На верхній шар матеріалу прокладки укладається товаросупровідна документація - пакувальний лист і відомість упаковки.
Споживча тара повинна бути обклеєна клейовою стрічкою 6-70 за ГОСТ.
Упаковані в споживчу тару програмні вироби повинні бути укладені на піддон, стягнуті стрічкою для запобігання втраті форми вантажу та упаковані в поліетиленову плівку М 0,2 для захисту від вологи.
У коробку піддону має бути вкладена товаросупровідна документація, у тому числі пакувальний лист згідно з ГОСТом.
Габарити вантажного місця мають бути не більше 1250 x 820 x 1180 мм.
Маса НЕТТО – не більше 200 кг.
Маса БРУТТО – не більше 220 кг.
У підрозділі наведено порядок упаковки із раніше розробленого документа на якісь технічні кошти. Виглядає дещо незвичайно у контексті програмного виробу. Говорячи простою російською мовою - цілковитий стіб.
Вимоги до транспортування та зберігання
У підрозділі мають бути зазначені для програмного виробу умови транспортування, місця зберігання, умови зберігання, умови складування, термін зберігання у різних умовах.
У підрозділі наведено умови транспортування та зберігання з раніше розробленого документа на якісь технічні засоби. Це стосується вимог до порядку упаковки. Виглядає дещо незвичайно у контексті програмного виробу.
Замовник немає права порушувати умов транспортування та зберігання. Виконавець зможе відмовити Замовнику у поверненні програмного виробу, стверджуючи, що неналежний зовнішній вигляд програмного виробу є наслідком недотримання умов транспортування та зберігання.
Умови транспортування та зберігання
Допускається транспортування програмного виробу в транспортній тарі всіма видами транспорту (у тому числі в герметизованих відсіках літаків, що опалюються, без обмеження відстаней). При перевезенні у залізничних вагонах вид відправлення – дрібний малотоннажний.
При транспортуванні та зберіганні програмного виробу повинен бути передбачений захист від попадання пилу та атмосферних опадів. Забороняється кантування програмного виробу. Кліматичні умови транспортування наведені нижче:
- температура навколишнього повітря, °З - від плюс 5 до плюс 50; атмосферний тиск, кПа - таке-то; відносна вологість повітря при 25 ° С - така.
Спеціальні вимоги
Програма повинна забезпечувати взаємодію з користувачем (оператором) за допомогою графічного інтерфейсу користувача, розробленого згідно з рекомендаціями компанії-виробника операційної системи.
Розробники цього стандарту дивилися у майбутнє. Не існувало в ті роки програм з графічним інтерфейсом користувача.
Вимоги до програмної документації
У розділі має бути зазначений попередній склад програмної документації та, при необхідності, спеціальні вимоги до неї.
Склад програмної документації передбачено ГОСТ 19.101-77.
Попередній склад програмної документації
Склад програмної документації повинен включати:
Технічне завдання; програму та методики випробувань; керівництво системного програміста; керівництво оператора; відомість експлуатаційних документів.
Програма та методики випробувань будуть потрібні, щоб показати Замовнику, що розроблена Виконавцем програма відповідає вимогам узгодженого та затвердженого технічного завдання. Після проведення спільних (приймально-здавальних) випробувань Замовник та Виконавець підпишуть Акт приймання (здавання) роботи. І тим самим робота буде закрита, умови Договору виконані.
Відповідно до п. 2.6. ГОСТ 19.101-77 «Допускається поєднувати окремі види експлуатаційних документів (за винятком відомості експлуатаційних документів та формуляра). Необхідність об'єднання цих документів зазначається у технічному завданні. Об'єднаному документу надають найменування та позначення одного з документів, що об'єднуються».
Програмна документація, що входить до попереднього переліку, має бути оформлена згідно з вимогами ГОСТ 19.106-78.
Техніко-економічні показники
Орієнтовна економічна ефективність не розраховується.
Очікувана кількість використання програми на рік – 365 сеансів роботи на одному робочому місці.
У розділі мають бути зазначені: орієнтовна економічна ефективність, передбачувана річна потреба, економічні переваги розробки порівняно з найкращими вітчизняними та зарубіжними зразками чи аналогами.
Отримати повний текстПрипустимо, Замовник оснащує програмою десяток робочих місць. Виконавець вимагав за розробку $1000. Замовник міг би встановити на робочі місця програмний продукт третьої фірми вартістю $500 за дистрибутив і по $100 за ліцензію на кожне робоче місце.
Економічні переваги розробки
Економічні переваги розробки в порівнянні з кращими вітчизняними та зарубіжними аналогами становитимуть:
кількість робочих місць
розробка
економічні переваги
Стадії та етапи розробки
У розділі встановлюють необхідні стадії розробки, етапи та зміст робіт (перелік програмних документів, які мають бути розроблені, узгоджені та затверджені), а також, як правило, терміни розробки та визначають виконавців.
Стадії розробки та етапи регламентовані ГОСТ 19.102-77. ГОСТ 19.102-77 не перешкоджає виключенню окремих стадій робіт, і навіть об'єднанню окремих етапів робіт.
Стадії розробки
Розробка має бути проведена у три стадії:
Розробка технічного завдання; робоче проектування; Використання.
Етапи розробки
На стадії розробки технічного завдання має бути виконаний етап розробки, погодження та затвердження справжнього технічного завдання.
На стадії робочого проектування мають бути виконані наведені нижче етапи робіт:
Розробка програми; розробка програмної документації; випробування програми.
На стадії впровадження має бути виконаний етап розробки – підготовка та передача програми.
На етапі розробки технічного завдання мають бути виконані наведені нижче роботи:
Постановка задачі; визначення та уточнення вимог до технічних засобів; визначення вимог до програми; визначення стадій, етапів та термінів розробки програми та документації на неї; вибір мов програмування; узгодження та затвердження технічного завдання.
На етапі розробки програми має бути виконана робота з програмування (кодування) та налагодження програми.
На етапі розробки програмної документації має бути виконано розробку програмних документів відповідно до вимог ГОСТ 19.101-77 з вимогою п. Попередній склад програмної документації цього технічного завдання.
На етапі випробувань програми повинні бути виконані такі види робіт:
Розробка, погодження та затвердження програми (у ГОСТ, схоже, друкарська помилка – «порядку») та методики випробувань; проведення приймально-здавальних випробувань; коригування програми та програмної документації за результатами випробувань.
На етапі підготовки та передачі програми має бути виконано роботу з підготовки та передачі програми та програмної документації в експлуатацію на об'єктах Замовника.
Порядок контролю та приймання
У розділі мають бути зазначені види випробувань та Загальні вимогидо приймання роботи.
Види випробувань
Приймальні випробування повинні проводитися на об'єкті Замовника в терміни…
Прийомо-здатні випробування програми повинні проводитися згідно з розробленою (не пізніше такого терміну) Виконавцем та погодженою Замовником Програми та методик випробувань.
Хід проведення приймально-здавальних випробувань Замовник та Виконавець документують у Протоколі проведення випробувань.
Загальні вимоги до приймання
На підставі Протоколу проведення випробувань Виконавець спільно із Замовником підписує Акт приймання-здачі програми в експлуатацію.
Програми
У додатках до технічного завдання, за потреби, наводять:
- перелік науково-дослідних та інших робіт, що обґрунтовують розробку; схеми алгоритмів, таблиці, описи, обґрунтування, розрахунки та інші документи, які можуть бути використані для розробки; інші джерела розробки.
Якщо є, то чому не привести. І обов'язково викласти перелік ГОСТ, на підставі яких має проводитись розробка. Наприклад:
- ГОСТ 19.201–78. Технічне завдання, вимоги до змісту та оформлення; і так далі...
Ефективним інструментом проектування та раціоналізації організаційних структур управління є моделювання, що дозволяє знаходити оптимальні варіанти їх побудови, прогнозувати їх розвиток, проводити оперативну діагностику стану діючої структури та встановлювати її відповідність реальним виробничо-технологічним умовам, оцінювати різні варіанти побудови організаційної структури, коли прямі експерименти неможливі скрутні, а також економічно невигідні, а іноді неможливі.
На етапі загальносистемного проектування одним із найголовніших завдань є завдання проектування структури. Стосовно людино-машинних систем найбільш поширеним є випадок, коли принципи побудови системи, функції та компоненти системи, що виконуються, виявляються заданими. Тоді завдання синтезу оптимальної структури полягає у визначенні оптимального відображення безлічі виконуваних функцій АС на множину взаємопов'язаних елементів.
Програма, за допомогою якої реалізовано цей курсовий проект, призначена для вирішення завдань наступних видів. Нехай в АС має вирішуватись iЗавдання (залежно від призначення АС це можуть бути завдання планування, обліку, підготовки документів і т.д.). До складу АС входять j елементів (вузлів): це може бути підрозділи підприємства, вузли обчислювальної мережі тощо. Потрібно розподілити завдання АС за її елементами відповідно до вибраних критеріїв та обмежень.
При розподілі завдань АС за її елементами зазвичай використовуються такі критерії оптимізації (цільові функції):
Мінімізація загальних витрат на вирішення всіх завдань;
Мінімізація загального часу вирішення всіх завдань;
Мінімізація максимального часу вирішення завдань (мінімізація часу, до якого буде вирішено останнє завдання);
Максимізація загального прибутку від вирішення всіх завдань.
При виборі оптимального варіанта розподілу завдань АС за її елементами зазвичай враховуються такі обмеження:
на витрати ресурсів (грошових чи будь-яких інших), пов'язані з вирішенням усіх завдань;
на загальний час вирішення всіх завдань АС;
На завантаження окремих елементів АС.
Можуть використовуватися й інші обмеження (наприклад, витрати ресурсів в окремих елементах АС, на час вирішення конкретних завдань і т.д.).
1.3 Опис логічної структури програми
Програма складається з процедур та функцій, які зчитують вихідні дані, прораховують можливі варіанти розподілу завдань між вузлами відповідно до обмеження та знаходять оптимальний варіант. Алгоритм програми показаний у вигляді блок-схеми у додатку 1.
Програма працює в такий спосіб. Після завантаження та запуску програми за допомогою файлу Project1. exe, на екрані з'являється вікно «Перша приватна задача синтезу оптимальної структури», яке містить три однорядкові редактори тексту для зміни кількості вузлів і завдань, для введення кількості завдань і кількості вузлів, що вирішуються, таблиці для введення значень витрат часу і грошей при вирішенні завдань у відповідних вузлах , текстові кнопки для редагування умови завдання та пошуку рішення, основне меню.
Розглянемо вміст основного меню, що складається із трьох пунктів:
До пункту меню Файлвключено 4 команди:
Новий -- Вибір цього пункту очищає основне вікно програми для введення нової умови.
Відкрити - Вибір цього пункту дозволяє відкрити файл звіту з раніше знайденими рішеннями;
Вихід - вибір цього пункту здійснює вихід із програми.
До пункту меню Командивключено 4 команди:
Змінити розмірність - Змінює розмірність масиву відповідно до кількості завдань і вузлів, введених користувачем;
Матриця рішення - відкриває форму із загальним рішенням;
Оптимальне рішення - Виконує пошук оптимального рішення поставленої задачі, виводячи результати в нижню частину основної форми (тільки у разі повного введення всіх значень за заданою умовою);
Критерій ефективності - Виконує пошук критерію ефективності, виводячи його в основному вікні програми.
До пункту меню HELPвключено дві команди:
Співчуття – відкриває вікно з посібником з використання програми та методом розв'язання задачі;
Про програму – відкриває вікно із загальною інформацією про програму та її розробників.
Кнопки керування, розташовані у головному вікні, виконують самі дії, як і відповідні команди основного меню.
У вікні «Перша приватна задача синтезу оптимальної структури» на вкладці «Постановка задачі» користувач має ввести такі вихідні дані:
кількість завдань, які потрібно розподілити між вузлами;
кількість вузлів, між якими розподілятимуться завдання;
значення елементів матриці витрат часу (витрати грошей);
значення елементів матриці витрат грошей (витрат часу);
Після введення всіх вихідних даних та натискання кнопки Матриця рішеньабо відповідного пункту меню, на екрані з'явиться друге вікно, яке містить одну кнопку керування: Ok, при натисканні на яке вікно відповіді буде закрито.
При натисканні кнопки Оптимальне рішенняу нижній частині форми виводиться оптимальне рішення.
При натисканні кнопки Критерій ефективностіу формі виводиться значення критерію ефективності.
При натисканні кнопки Вихід, здійснюється вихід із програми.
Після завершення проектування необхідно простежити за роботою користувача при керуванні RAID-системою.
ВстановленняRAID. При підключенні RAID-системи до комп'ютера та після налаштування необхідних драйверів, користувачеві необхідно налаштувати роботу RAID на потрібний режим (RAID0, RAID1, RAID3 та ін.). Після цього готове для роботи дискове місце необхідно розбити на потрібні томи (розділи). Після завершення налаштування необхідно протестувати роботу всієї системи.
Управління/ДіагностикаRAID. Якщо користувачеві захотілося подивитися на стан роботи системи або змінити будь-які параметри, програмне забезпечення має інформативно показати стан роботи системи та надати зручний інтерфейс для зміни налаштувань системи. При цьому як часто буває, адміністратор працює з комп'ютером, на якому встановлено RAID, віддалено (наприклад, з дому), тому програмне забезпечення має забезпечувати авторизований (захищений) доступ для керування системою по мережі.
Обробка помилок.Система повинна негайно повідомити адміністратора про помилки, що виникли в роботі RAID. Оскільки сам по собі RAID-контролер не може подати сигналу про несправність, ПЗ повинно забезпечувати безперебійний моніторинг RAID на предмет помилок.
Документація ПЗ.Система має бути повністю зрозуміла користувачеві. Але незважаючи на це, при виниклих труднощах користувач повинен швидко знайти необхідну документацію як про роботу ПЗ, так і про пристрій RAID і режими його роботи.
Конструкторська частина
Вимоги до системи
Виходячи з поставленого завдання та проведених попередніх НДР були сформульовані вимоги до системи, що розробляється.
Склад виконуваних функцій
Програмний продукт, що створюється, повинен забезпечити виконання наступних функціональних дій:
Початкова установка щойно придбаної RAID-системи;
Щоденний моніторинг стану RAID-системи;
Зміна конфігурації існуючої системи (менеджер дисків, керування дисковим простором, налаштування RAID-контролера);
Можливість віддалено з іншого комп'ютера здійснювати керування системою;
Нотифікація адміністратора про несправності та збої в роботі RAID-системи.
Вимоги до надійності
Оскільки система має працювати віддалено, має бути реалізована система авторизації та захист від несанкціонованого використання системи. Для запобігання перехопленню пароля, що передається по мережі, усі паролі зберігатимуться у зашифрованому вигляді.
Умови експлуатації та вимоги до складу та параметрів технічних засобів
При віддаленому адмініструванні RIAD-системою потрібно запускати два програмні модулі - один на комп'ютері з RAIDсистемою, інший на комп'ютері адміністратора.
Основною вимогою для використання системи є необхідність постійної роботи програмного модуля, що запускається на комп'ютері з RAID-системою. Якщо цей модуль буде зупинено, то без нього не можна буде з'єднатися з RAID-системою і буде неможливим стежити за роботою RAID (відсилати нотифікацію про несправності та вести файли історії роботи RAID).
Для зв'язку обох програмних модулів використовується протокол TCP/IP. Тому для можливості віддалено працювати з RAID-системою, потрібна налаштована мережа для обох комп'ютерів. При адмініструванні RAID-системи з локального комп'ютера підключення до мережі не потрібне.
У підрозділі «Вимоги до функціональних характеристик» мають бути зазначені вимоги до складу виконуваних функцій, організації вхідних та вихідних даних, тимчасових характеристик тощо.
1. Редактор повинен працювати у багатовіконному графічному режимі та підтримувати роботу як клавіатури, так і маніпулятора типу «миша».
2. Користувач, за своїм бажанням, повинен мати можливість встановити масштабне поле для кожного вікна.
3. Мінімізатор повинен забезпечувати знаходження мінімального шляху з проходом лише один раз через кожне ребро кожного багатокутного контуру деталі в області розміщення.
4. Знайдений шлях має демонструватися на екрані у різних режимах.
5. Інформація про розміщення контурів та сформований маршрут може бути збережена в локальній базі даних мінімізатора.
6. Має бути забезпечено графічний перегляд бази даних із можливістю видалення з неї чи копіювання в активне вікно зазначеного розміщення з наявним маршрутом.
7. Інформація про розміщення та сформований маршрут може бути виведена у формі файлу геометричної інформації наступної структури: …
8. Перерахування вершин контурів деталей у відповідному дескрипторі вихідного файлу має відповідати сформованому маршруту різання.
9. Програма повинна використовувати як вхідну інформацію файл геометричної інформації, першою деталлю якого буде прямокутник області розміщення.
10. Програма має забезпечувати перегляд вихідного файлу.
Кінець роботи -
Ця тема належить розділу:
Технологія розробки програмного забезпечення
На сайті сайт читайте: "Технологія розробки програмного забезпечення"...
Якщо Вам потрібний додатковий матеріал на цю тему, або Ви не знайшли те, що шукали, рекомендуємо скористатися пошуком по нашій базі робіт:
Що робитимемо з отриманим матеріалом:
Якщо цей матеріал виявився корисним для Вас, Ви можете зберегти його на свою сторінку в соціальних мережах:
| Твітнути |
Всі теми цього розділу:
Вимоги до інформаційної та програмної сумісності
У підрозділі «Вимоги до інформаційної та програмної сумісності» мають бути зазначені вимоги до інформаційних структур на вході та виході та методів рішення, вихідних кодів
Угода про вимоги
Укладання угоди про вимоги – мета другої частини першої лабораторної роботи. Також, угода про вимоги є другим розділом курсової роботи. Нижче дається оп
Короткий опис виробу
Описуються коротко і в загальних поняттяхосновні функціональні властивості виробу Якщо програмний виріб є розширенням вже існуючого, характеризуються тільки його нові
Результуючі компоненти виробу
У даному розділінаводиться таблиця, подібна чи еквівалентна таблиці 2.1. В даному випадку використана заздалегідь підготовлена друкована форма, що зменшує час підготовки інформації.
Відхилені заявки
Якщо метою є переробка або розширення виробу або заміна виробу з певними помилками, слід планувати виправлення помилок, виявлених на даний момент часу. Тому в цьому пункт
Виключені пункти плану
Якщо є якісь планові вказівки, які вимагають особливих властивостейта можливостей програмних засобів, які не можуть бути забезпечені, якщо виріб розробляється відповідно до інших вимог
Включені пункти плану
Якщо необхідність створення виробу обґрунтована таким документом, як план випуску виробу, план випуску серії або опис завдання, то цитується певне місце з кожного документа або п
Перелік вимог користувача
Вказуються замовники виробу і пояснюється, чому він необхідний. У цьому розділі вказується також передбачуваний термін використання виробу. Зазвичай це буде термін служби обладнання
Розглянуті альтернативи
Коротко описуються альтернативи даної розробки, які були розглянуті та відхилені, а також причини відхилення. Якщо програми мають бути закуплені, пояснюється, чому вони не
Окупність капіталовкладень
Визначається прибуток, який дасть виробництво виробу, у поняттях, що відповідають цільовому призначенню організації. приклад. Фірма ABC Services очікує, що обсяг збуту у фіналі
Системне програмне забезпечення
Системне програмне забезпечення - це все інше програмне забезпечення, що включає операційні системи, компілятори, утиліти, пакети прикладних програм та ін.
Загальні характеристики функцій
Необхідно розглядати весь виріб як один функціональний модуль, щоб кількість підрозділів була невеликою. Якщо неможливо адекватно описати виріб без розбиття його на окремі функціональні
Зовнішні обмеження
Перераховуються всі обмеження, сфера дії яких ширша, ніж сфера дії СТ; сюди входять, наприклад, промислові обмеження чи обмеження щодо серії виробів. Може бути дозволено
Обмеження на сумісність
Завжди має розглядатися кілька аспектів сумісності: вихідна мова, машинна мова, формати даних та повідомлень, формати звітів, формати лістингів та формати мови керування завданнями (уп.
Програмні обмеження
Вказується, якщо це необхідно, операційна система, з якою має працювати запропонований програмний виріб, а також інші програмні засоби, з якими він має стикуватися у процесі
Апаратні обмеження
Наводиться таблиця пристроїв, які використовуються під час роботи програмного виробу. Для кожного пристрою вказується мінімальне, номінальне та максимальне потрібне число. Номінальним є оптимальність
Результати роботи
Описуються всі вихідні дані програмного виробу чи функціонального модуля з погляду їхнього змісту та призначення - звіти, файли, записи, поля даних, повідомлення, таблиці, прапорці. Повинні б
Процеси обробки
Описуються операції, що виконуються програмним виробом, яке при цьому розглядається в цілому або за функціональними модулями як чорна скринька (або сукупність чорних ящиків). Як мінімум, втомившись
Надійність
Під надійністю програмних засобів розуміється здатність до відновлення нормальної роботи при помилках та збоях у роботі обладнання. Першорядну важливість має захист даних користувача. Сл
Рестарт
Вказуються можливості, що забезпечують збереження та використання даних при відновленні роботи після аварійного переривання, наприклад, при рестарті з контрольної точки. Приклад 1. Програ
Відповідність вимогам замовника
Вказуються властивості, які дозволяють програмному виробу або його вихідним даним задовольняти конкретним вимогам. Перераховуються, якщо це можливо, модулі, які можуть не задовольняти т
Робочі характеристики
Наводиться основна змінна чи основний принцип, яким повинна вимірюватися ефективність роботи програми; вказується відповідне значення або діапазон значень цієї змінної. Гол
Зручність експлуатації
Описуються властивості, які роблять взаємодію «людина – машина» зручною для людини. Прикладами є вільний формат вхідних даних, діалоговий режим, синтаксична сумісність, можл.
Зручність супроводу
Описуються заходи, що гарантують ідентифікацію модулів, якщо це питання не вирішено за допомогою стандарту. Приклад 1. Кожен вихідний та об'єктний модуль постачатиметься шифром програмного
Рестарт інтерфейсу користувача
приклад. Стан системи для всіх активних користувачів (у тому числі вимкнених, але обслуговуваних) періодично запам'ятовується на диску (з інтервалом, що обумовлюється в рамках визначення часів
Характеристики інтерфейсу користувача
приклад. При допущенні, що на обчислювальній машині виконується тільки ASK і що параметр відновлення характеризується однією контрольною точкою в 1 хвилину, кожна команда повинна виконуватись або п
Область застосування інтерфейсу користувача
приклад. У типовому сеансі з ASK користувач, який не має досвіду програмування, підключається до системи за допомогою терміналу і вступає в діалог, в якому він визначає: - його цікавлять
Алгоритм інтерфейсу користувача
приклад. ASK виконує кожну команду в інтерпретації і негайно; таким чином, накопичення команд не дозволяється (за винятком команд запам'ятовування, які будуть розглянуті нижче).
Апаратні обмеження
приклад. Крім пристроїв, необхідних VSOS ILSAM (див. п. 2.4.1, б і в), процесору коригувань потрібні пристрої, перелічені у таблиці 2.3. Таблиця 2.3 - Пристроїв
Внутрішні обмеження
Важливо визначити не тільки те, яким буде виріб, але також яким він не буде. Обмеження - це властивість (або можливість), яке користувачеві логічно очікувати, але яке за
Довідкові документи
Окремо вказується кожен плановий чи технічний документ, який є посилання в СТ. Кожен такий документ повинен реально існувати (а не матися на увазі в майбутньому) та ін
Ресурси, що забезпечують введення в дію
Визначаються ресурси, необхідні для встановлення системи, поряд з ресурсами, описаними в розділі 2.5.3 (тут маються на увазі машинний час, трудовитрати та необхідна кваліфікація
Носії інформації
Визначається тип пристроїв для всіх поширених компонентів програмного виробу (наприклад, магнітна стрічка, що характеризується кількістю доріжок і щільністю запис
Необхідні взаємозв'язки
Визначаються вимоги, що висуваються цим програмним виробом до інших проектів чи функцій. Дається коротка характеристикакожної вимоги та вказується етап, на якому може бути встановлено
Забезпечувані взаємозв'язки
За структурою цей розділ аналогічний попередньому, але містить вимоги, які інші вироби накладають на даний виріб. Кожна вимога в розділі 2.6.1.2 повинна відповідати вимогам у раз
Технічна ревізійна комісія
У кожному СТ слід рекомендувати створення технічної ревізійної комісії (ТРК) із зазначенням місця роботи кожного члена комісії та його прізвища, якщо це можливо, а також призначення
Рівні випробувань
Випробування програм можуть бути організовані у три етапи, проводитись у трьох режимах та налічувати десять категорій (див. розділ 5 «Тестування»). Ця інформація подається у вигляді таблиці. Для як
Еталони для порівняння
Визначаються еталонні системи, щодо яких має виконуватись порівняння. Зазначаються показники цієї системи у відносних одиницях. Якщо зразка для порівняння немає
Повідомлення про зміну календарних термінів
приклад. Назва проекту: Розробка виробу ASK Шифр проекту: C013. Шифр продукту: L301A. Назва виробу: ASK
Написання специфікацій
Написання специфікацій – мета першої частини другої лабораторної роботи. p align="justify"> Також специфікації є третім розділом курсової роботи. На етапі визначення специфікацій здійснюється
Загальні засади тестування
Етап тестування зазвичай, у фінансових витратах становить половину витрат за створення системы. Погано сплановане тестування призводить до істотного збільшення термінів розробки
Організація випробувань програмних виробів
Під випробуваннями розуміють не налагодження, покликане визначити, чому у програмі виникає та чи інша помилка та усунути її причини, а процес встановлення самого факту наявності дефек
Види випробувань програмного виробу. Стадії випробувань
У випадку, випробування проводяться у кілька стадій, розділених за часом. До першої стадії відносяться випробування класу A, які проводяться в кінці фази програмування.
Режими випробувань програм
Випробування різняться залежно від цього, хто їх проводить. Основна ідея – незалежність функції випробувань від функції розробки. Режим I випробувань має на увазі повний
Категорії випробування програмного виробу
Стадії випробування вказують тимчасово проведення перевірок, а режими визначають тих, хто проводить. Категорії випробувань встановлюють характер та призначення тестів. Продуманий поділ та
Технологія тестування, класи еквівалентності
Одним із способів вивчення поставленого питання є дослідження стратегії тестування, званої стратегією чорної скриньки, тестуванням з управлінням за даними або тестування
Побудова тестів
Процес побудови тестів включає: 1) призначення кожному класу еквівалентності унікального номера; 2) проектування нових тестів, кожен з яких покриває
загальні положення
1.1. Структуру та оформлення документа встановлюють відповідно до ГОСТ 19.105-78. 1.2. Керівництво системного програміста має містити такі розділи: –
Структура програми
Програма «Автоматизоване робоче місце читача» складається з наступних компонентів: 1) zcon – додаток, що реалізує функції Z39.50-клієнта; 2) zgate - CGI-
Встановлення програми
У цьому документі для імені файлів використовується синтаксис, визначений ISO/IEC 9945-1. У тих операційні системи, які не підтримують вказаний спосіб іменування файлів у програмі
Перевірка програми
Перевірка програми здійснюється шляхом її виконання. У зв'язку з тим, що конкретні умови застосування програми (адреси Z39.50-серверів, назви баз даних, підтримувані точки
Додаткові можливості
Додатковою можливістю програми є можливість динамічного керування формою подання записів під час перегляду їх у повному форматі («Детальна інформація») за допомогою
Повідомлення системному програмісту
У таблиці 5.1 представлені повідомлення, які можуть одержати системний програміст під час виконання налаштування, перевірки програми, а також користувач під час виконання програми.
МІНІСТЕРСТВО ОСВІТИ І НАУКИ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ
СЕРДОБСЬКА ФІЛІЯ ФЕДЕРАЛЬНОЇ ДЕРЖАВНОЇ БЮДЖЕТНОЇ ОСВІТНОЇ УСТАНОВИ ВИЩОЇ ОСВІТИ
«ПЕНЗЕНСЬКИЙ ДЕРЖАВНИЙ УНІВЕРСИТЕТ»
"Розробка програми для вирішення гіперболічних рівнянь методом сітки в середовищі Microsoft Visual Studio 2013"
ПОЯСНЮВАЛЬНА ЗАПИСКА
До курсової роботиз дисципліни "Технології розробки програмного забезпечення"
Виконала: студентка гр.13ПКС1
Драніцин Є.А.
Прийняв: викладач
Ю.С.Кисельова
Реферат
Пояснювальна записка: 22 листи, 7 малюнків, 4 джерела, 2 додатки.
Об'єктом дослідження є розв'язання гіперболічних рівнянь.
Мета роботи – розробити програму, яка здійснюватиме вирішення гіперболічних рівнянь методом сітки.
В результаті виконаної роботи розроблено програму, що дозволяє обчислювати рішення гіперболічних рівнянь.
Під час написання програми використовувалося середовище програмування Microsoft Visual Studio 2013.
Вступ. 5
1 Аналіз предметної області. 6
2 Технічне завдання. 7
2.1 Підстава розробки. 7
2.2 Призначення розробки. 7
2.3 Вимоги до програми. 7
2.3.1 Вимоги до функціональних характеристик.. 7
2.3.2 Вимоги до складу та параметрів технічних засобів. 7
2.3.3 Вимоги до інформаційної та програмної сумісності. 7
2.4 Вимоги до програмної документації. 7
2.5 Стадії та етапи розробки. 8
2.6 Порядок контролю та приймання. 8
3 Опис програми.. 9
3.1 Загальні відомості. 9
3.2 Функціональне призначення. 9
3.3 Опис логічної структури.. 9
3.4 Використані технічні засоби. 10
4.1 Об'єкт випробувань. 11
4.2 Мета випробувань. 11
4.3 Вимоги до програми. 11
4.4 Вимоги до програмної документації. 11
4.5Кошти та порядок випробувань. 12
4.6 Методи випробувань. 12
5 Опис застосування. 13
Висновок. 14
Список використаних джерел. 15
ТЕКСТ ПРОГРАМИ... 16
РЕЗУЛЬТАТИ ВИПРОБОВУВАНЬ.. 21
Вступ
Гіперболічне рівняння – клас диференціальних рівняньу приватних похідних. Характеризуються тим, що завдання Коші з початковими даними, заданими на нехарактерній поверхні, однозначно можна розв'язати. Найбільш відомим прикладом є хвильове рівняння. Будь-яке рівняння першого порядку у приватних похідних також є гіперболічним.
Microsoft Visual Studio - це нова розробка компанії Microsoft, що дозволяє створювати програми, що працюють на платформі. Особливість цієї платформи полягає у широкому наборі сервісів, які доступні у різних мовах програмування. У цьому послуги реалізуються як проміжного коду, який залежить від базової архітектури. Чи не головною метою створення такої платформи було оснащення розробників спеціальними сервісно-орієнтованими програмами, які могли б працювати на будь-якій платформі, починаючи від персонального комп'ютерата закінчуючи мобільним пристроєм.
Microsoft Visual Studio поєднує в собі величезну кількість функцій, що дозволяють здійснювати розробки для Windows усіх версій, у тому числі 8, Інтернету, SharePoint, різних мобільних пристроїв та хмарних технологій. У Visual Studio реалізується нове середовище розробника, завдяки якому створювати програми стало простіше. Microsoft Visual Studio - це оновлене та спрощене програмне середовище, для якого характерна висока продуктивність, причому воно не залежить від особливостей обладнання. І ця студія напевно непогано підійде для розробки програми.
Аналіз предметної галузі
Предметною областю для даної розробки є розв'язання гіперболічних рівнянь, а саме рішення методом сіток.
Методи розв'язання Гіперболічних рівнянь, що застосовуються на практиці, діляться на дві групи - хвильові рівняння і різні рівняння, що отримуються з рівнянь Максвелла. Хвильові рівняння – це рівняння, що описують коливання струн, мембран і так далі. Різні рівняння, одержувані з рівнянь Максвелла, що описують електромагнітне поле. Це може бути постановка щодо одного із векторів , вважаючи не нульовою лише одну з компонентів вектора (тобто коли рівняння стає скалярним).
Опис рішення гіперболічного рівняння методом сіток: завдання полягає у відшуканні функції u(x,t), що задовольняє даному рівнянню (d^2*u/d*t^2)=c^2*(d^2*u/d*x^ 2) при x1< x < x2, t1 < t <= t2, начальным условиям u(x,0) = f(x), d u(x,0)/ d t = g(x) , x1<= x <= x2 и нулевыми краевыми условиями u(0,t) = u(1,t)=0. Так как замена переменных t ->ct наводить рівняння (1) до виду (d^2*u/d*t^2)=(d^2*u/d*x^2), то надалі вважатимемо с = 1. Для побудови різницевої схеми розв'язання Завдання будуємо в області D = ((x, t) | x1<=x<=x2, t1<=t<=t2}, сетку xi = ih, i=0,1... n , a = h * n, tj = j*t t t , j = 0,1 ... , m, t m = T и аппроксимируем уравнение (1) в каждом внутреннем узле сетки.
Технічне завдання
Підстава для розробки
Програма розробляється виходячи з завдання на курсову роботу, виданого викладачем Кисельової Ю.С. та затвердженого завідувачем навчальної частини Золотової Т.А.
Призначення розробки
Програма, що розробляється, призначена для вирішення гіперболічних рівнянь методом сітки.
Вимоги до програми
Вимоги до функціональних характеристик
Готова програма має забезпечити вирішення гіперболічних рівнянь методом сітки.
Необхідно організувати зручний інтерфейс користувача, що включає довідку щодо використання та застосовуваного методу.