Згідно з ГОСТом, цей стандарт (перевиданий у листопаді 1987 р.) встановлює порядок побудови та оформлення технічного завдання на розробку програми або програмного виробу для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Треба бути дуже уважним і обережним, створюючи його, т.к. найчастіше вміло (і грамотно) складене ТЗ визначає успіх усієї роботи. Саме ТЗ узгоджується із Замовником, який зазвичай прагне внести якнайбільше суперечливих та завищених вимог. Завдання Виконавця – навпаки, полегшити собі життя. Але після того, як підписи з обох сторін поставлено, перегравати щось пізно.
загальні положення
Технічне завдання оформляють на аркушах формату А4 та/або А3, як правило, без заповнення полів аркуша. Номери аркушів (сторінок) проставляють у верхній частині аркуша над текстом.Для внесення змін та доповнень до технічних задні на наступних стадіях розробки програми або програмного виробу випускають додаток до нього. Узгодження та затвердження доповнення до технічного завдання проводять у тому самому порядку, який встановлено для технічного завдання.
Технічне завдання має містити такі розділи:
- найменування та сфера застосування;
- основу розробки;
- призначення розробки;
- технічні вимоги до програми чи програмного виробу;
- техніко-економічні показники;
- стадії та етапи розробки;
- порядок контролю та приймання;
- програми.
Розділ: Найменування та сфера застосування
В розділі Найменування та сфера застосуваннявказують найменування, коротку характеристику сфери застосування програми або програмного виробу та об'єкта, в якому використовують програму або програмний виріб.У розділі Основа для розробки повинні бути вказані:
- документ (документи), виходячи з яких ведеться розробка;
- організація, яка затвердила цей документ, та дата його затвердження;
- найменування та (або) умовне позначенняРозробка теми.
Розділ: Призначення розробки
В розділі Призначення розробкимає бути зазначено функціональне та експлуатаційне призначення програми чи програмного виробу. Обмежитися тут можна однією-двома фразами. Головне – чітко визначити, навіщо потрібна ця програма.Наприклад: Програма є ядро автоматизованого робочого місця (АРМ) розробника безперервних лінійних системавтоматичного керування (САУ), що дозволяє користувачеві вирішувати завдання аналізу простих моделей.
Розділ: Технічні вимоги до програми чи програмного виробу
У цьому розділі мають бути такі підрозділи: - вимоги до функціональних характеристик;
- вимоги до надійності;
- умови експлуатації;
- вимоги до складу та параметрів технічних засобів;
- вимоги до інформаційної та програмної сумісності;
- вимоги до маркування та упаковки;
- вимоги до транспортування та зберігання;
- спеціальні вимоги.
Розділ: Вимоги до функціональних характеристик.
Тут мають бути зазначені вимоги до складу виконуваних функцій, організації вхідних та вихідних даних, тимчасових характеристик тощо.Наприклад : Програма повинна дозволяти … обчислювати … будувати … створювати …
Вихідні дані: текстовий файл із заданою …
Вихідні дані: графічна та текстова інформація - результати аналізу системи…; текстові файли - звіти про … діагностика стану системи та повідомлення про всі помилки.
Вимоги до надійності. Повинні бути зазначені вимоги щодо забезпечення надійного функціонування (забезпечення сталого функціонування, контроль вхідної та вихідної інформації, час відновлення після відмови тощо).
Тут "вигадати" щось складно. У кращому випадку може пройти варіант, коли ваша програма працює тільки з абсолютно коректними даними. Зазвичай Замовник цього не йде, але спробувати можна.
Наприклад: Програма повинна працювати із заданою розширеною матрицею інцидентів досліджуваного графа відповідно до алгоритму функціонування, видавати повідомлення про помилки при невірно заданих вихідних даних, підтримувати діалоговий режим у межах можливостей, що надаються користувачеві.
Умови експлуатації. Повинні бути зазначені умови експлуатації (температура навколишнього повітря, відносна вологість тощо для обраних типів носіїв даних), за яких повинні забезпечуватися задані характеристики, а також вид обслуговування, необхідна кількість та кваліфікація персоналу.
Із цим пунктом складнощів зазвичай не виникає. На жаль, пункт про професійність користувача Замовником мається на увазі обов'язково. Це, звичайно, зайва нагода причепитися до вашої програми. Втім, тут можна обмежитися фразами виду "Умови експлуатації програми збігаються з умовами експлуатації ПЕОМ IBM PC та сумісних з ними ПК", "Програма повинна бути розрахована на непрофесійного користувача." і т.п.
Вимоги до складу та параметрів технічних засобів. Вказують необхідний склад технічних засобів із зазначенням їх технічних характеристик.
Тут головне – нічого не забути і все передбачити, з одного боку (а то підсунуть якийсь IBM PC/XT з монохромним дисплеєм і без миші), а з іншого – не переборщити з підвищеними вимогами, інакше Замовник знайде більш поступливого Виконавця.
Наприклад: Необхідна наявність IBM PC - сумісного ПК з графічним адаптером EGA (VGA). Необхідний дисковий простір – не менше 600 Кб, обсяг вільної оперативної пам'яті- Не менше 400 Кб. Бажана наявність драйвера EMS та маніпулятора типу "миша".
Вимоги до інформаційної та програмної сумісності. Особливості ті самі, що й у попередньому пункті. Тут мають бути зазначені вимоги до інформаційних структур на вході та виході та методів рішення, вихідних кодів, мов програмування. За потреби повинен забезпечуватися захист інформації та програм.
Наприклад: Програма має працювати автономно під керуванням ОС MS DOS версії не нижче 3.3. Базова мова програмування – Turbo Pascal 6.0.
Вимоги до маркування та упаковки та вимоги до транспортування та зберігання є досить екзотичними. У загальному випадку тут вказують вимоги до маркування програмного виробу, варіанти та способи пакування. А у вимогах до транспортування та зберігання повинні бути зазначені для програмного виробу умови транспортування, місця зберігання, умови зберігання, умови складування, термін зберігання у різних умовах.
Спеціальні вимоги – це відповідальна річ. Їх краще, по можливості, всіляко уникати. І заявити про це одразу.
Наприклад: Спеціальних вимог до тимчасових характеристик програми не висувається. Спеціальних вимог до ємнісних характеристик програми не висувається.
Техніко-економічні показники. Цей найскладніший для програміста пункт є далеко не завжди. Він потрібен насамперед тоді, коли вашою метою є обґрунтування величезної ефективності та важливості виконуваної роботи. На Замовника цей пункт діє зазвичай дуже добре. Принаймні, це найкраще обґрунтування термінів та грошових сум розробки.
У цьому розділі мають бути зазначені: орієнтовна економічна ефективність, передбачувана річна потреба (наприклад: передбачувана кількість звернень до комплексу загалом на рік – 365 сеансів роботи), економічні переваги розробки порівняно з найкращими вітчизняними та зарубіжними зразками чи аналогами.
Крім цього, бажано навести визначення кошторисної вартості розробки програми, так і визначення трудомісткості програмування.
Стадії та етапи розробки (про це докладніше буде сказано нижче) встановлюють необхідні стадії розробки, етапи та зміст робіт (перелік програмних документів, які мають бути розроблені, узгоджені та затверджені), а також, як правило, терміни розробки та визначають виконавців.
Тут описуються стандартні етапи. Головне – грамотно визначитись із термінами. По можливості намагайтеся рівномірно розподілити етапи за термінами (і сумами). Пам'ятайте, що не всі проекти доживають до останній стадії. А звіти мають бути за кожним етапом. Пам'ятайте, що найбільше часу займе робочий проект. Якщо ви не встигнете зробити вчасно документацію, то Замовник має повне право взагалі не прийняти роботу з усіма наслідками, що випливають.
Основними та неодмінними стадіями та етапами є саме технічне завдання, ескізний проект, технічний та робочий проекти.
Ескізний проект. На цій стадії детально розробляються структури вхідних та вихідних даних, визначається форма їх подання. Розробляється Загальний описалгоритм, сам алгоритм, структура програми. Розробляються план заходів щодо розробки та впровадження програми.
Технічний проект Містить розроблений алгоритм розв'язання задачі та методи контролю вихідної інформації. Тут же розробляються засоби обробки помилок та видачі діагностичних повідомлень, визначаються форми подання вихідних даних та конфігурація технічних засобів.
Робочий проект. На цій стадії здійснюється програмування та налагодження програми, розробка програмних документів, програми та методики випробувань. Готуються контрольно-налагоджувальні приклади. Остаточно оформлюються документація та графічний матеріал. Зазвичай вказується, що під час розробки програми має бути підготовлено таку документацію:
Oтекст програми;
Опис програми;
Oпрограма та методика випробувань;
Опис застосування;
Посібник користувача.
Це – стандартні вимоги. Якщо Замовник погоджується з тим, що можна представити не весь цей список, це означає несерйозність його намірів щодо вас та вашого продукту.
Графічного матеріалу може бути. Особливо тоді, коли ви не збираєтеся повідомляти про результати своєї роботи. Але для серйозних проектів цей пункт є обов'язковим.
Наприклад: Під час розробки програми має бути підготовлений наступний графічний матеріал:
Oтехніко-економічні показники;
Oструктура програми;
Oформат подання вхідних даних програми;
Загальна схема алгоритму (2 листи);
oосновні обчислювальні алгоритми;
oприклад роботи програми.
У розділі Порядок контролю та приймання повинні бути зазначені види випробувань та Загальні вимогидо приймання роботи. Якщо можливо, то в цьому пункті вкажіть, що "контроль і приймання розробки здійснюються на техніці, що надається Замовником", інакше вас можуть зобов'язати принести техніку з собою.
Наприклад: Контроль та приймання розробки здійснюються на основі випробувань контрольно-налагоджувальних прикладів. У цьому перевіряється виконання всіх функцій програми.
У Додатках до технічного завдання, за потреби, наводять:
перелік науково-дослідних та інших робіт, що обґрунтовують розробку;
Схеми алгоритмів, таблиці, описи, обґрунтування, розрахунки та інші документи, які можуть бути використані для розробки;
Інші джерела розробки.
У програмній системі необхідно передбачити захист даних від випадкового видалення та зміни. Тільки адміністратор бази даних або викладач, наділений відповідними правами, які зареєстровані на сервері бази даних та мають відповідні ролі, повинні мати доступ до даних.
З метою надійності навчальної системи вона повинна задовольняти такі вимоги:
розроблена програма повинна мати засоби захисту від помилкових дій користувачів;
всі помилки повинні відображатися з коментарями або підказками щодо їх усунення;
гарантувати збереження даних при збоях у роботі зовнішніх пристроїв.
Для підвищення надійності необхідно вжити таких заходів:
конфігурувати апаратні та програмні засоби відповідно до технічних вимог;
періодично здійснювати резервне копіювання інформації;
регулярно перевіряти цілісність бази даних;
- підтримувати справність мережного обладнання.
Вимоги до складу та параметрів технічних засобів
Мінімальна апаратна конфігурація системи, що забезпечує нормальне функціонування навчальної системи, повинна бути не нижче наступної:
Оперативна пам'ять 128 Мбайт та вище.
Вільного місця на жорсткому диску щонайменше 150 Мб.
Вимоги до комп'ютера, який використовується для розробки конфігурацій:
Процесор AMD Athlon 900 МГц та вище.
Оперативна пам'ять 256 Мбайт та вище.
Вільного місця на жорсткому диску щонайменше 250 Мб.
При використанні автоматизованої системи в локальній мережі, на одному з комп'ютерів має бути встановлений та запущений сервер Firebird1.5.3 із попередньо встановленою на ньому базою даних. На решті машин необхідно встановити клієнтський додаток системи обліку техніки.
Вимоги до інформаційної та програмної сумісності
Для використання програмного продукту потрібна наявність наступних компонентів:
Операційна система сімейства Microsoft Windows (не нижче 2000).
Встановлені та налаштовані програмні продукти MicrosoftSQLServer, IBExpert2004,Borland®C++Builder™ 6.0,Microsoft.NETFrameworkSDKv2.0.
Умови експлуатації
Програма має виконуватися на справному обладнанні. Вимоги до умов експлуатації ПК та іншого обладнання, що використовується в комплексі, викладено у технічних документах, що входять до комплекту постачання пристроїв.
Вимоги до програмної документації
До складу програмної документації мають входити такі документи.
Керівництво системного адміністратора.
Керівництво викладача.
Керівництво учня.
Посібник системного адміністратора повинен включати описи особливостей конфігурування системи.
Програмна система має містити повне керівництво викладача з описом сценаріїв роботи викладача.
Програмна система повинна включати повне керівництво учня з описом сценаріїв роботи учня.
Етапи розробки програмної системи
Розробка програмної системи має бути організована у межах наступних етапів.
розробка плану реалізації;
розробка плану тестування;
розробка плану застосування.
Проектування:
логічне проектування архітектури програмної системи;
розробка структури БД;
проектування інтерфейсу користувача.
Реалізація:
реалізація розробленого інтерфейсу користувача;
реалізація основних функцій програмної системи
Тестування системи:
структурне тестування;
функціональне тестування;
виправлення помилок та доопрацювання.
Впровадження системи:
перевірка наявності необхідного обладнання;
встановлення системи;
навчання персоналу.
Супровід системи.
На вимогу замовника це програмне забезпечення розробляється під платформу Windows. Програма має працювати під основними версіями цієї платформи: Windows98, Windows2000, Windows XP. Причому серверна частина програми для версій WinNT повинна працювати як сервіс (працювати у фоновому режимі).
Потрібно забезпечити можливість подальшого нарощування функцій системи (відкритість для розвитку та методика підключення нових завдань).
Вимоги до транспортування та зберігання
Система управління буде поставлятися в комплекті при продажі RAID-контролера. Вона повинна бути записана на окремий CD-диск, на якому будуть знаходитися драйвери системи і необхідна документація до контролера, що продається. Для цього слід врахувати, щоб обсяг файлів інсталяції був не більше приблизно 2/3 стандартного CD-диска (700 Мб).
Спеціальні вимоги
Серверна частина програми, яка займається аналізом роботи RAID, повинна бути запущена на комп'ютері з RAID-системою. Якщо цей модуль буде зупинено, то без нього не можна буде з'єднатися з RAID-системою і буде неможливим стежити за роботою RAID (відсилати нотифікацію про несправності та вести файли історії роботи RAID).
Структурна схема роботи програми
Весь програмний проект ґрунтується на двох незалежних модулях. Як уже згадувалося, один із них запускається окремо на комп'ютері з RAID-системою, а другий на комп'ютері адміністратора. Для скорочення називатимемо перший модуль Агентом, а другий - Менеджером.
Менеджер– користувальницька сторона програми, що містить інтерфейс програми, майстер початкової установки, розділ довідки. Менеджеркеруватиме RAID-системою за допомогою Агента.
Агентв основному служить для передачі команд від Менеджера RAID-системі та назад. Також Агентбуде займатися моніторингом RAID (ведення log-файлу) та нотифікацією адміністратора при помилках.
Мережа
Рис. 1.2. Основна структура роботи програми GUIRAIDManager
Основна структура роботи всієї роботи загалом представлена на рис. 1.2. На ньому показано різні варіанти роботи двох модулів. Агенті Менеджер:
Агент(C3 ) запущений на комп'ютері та аналізує роботу RAID-масиву R2 ;
Менеджерз віддаленого комп'ютера ( С2або С4) може з'єднуватися по мережі з А гентом(С3) для управління роботою RAID-масиву R2 ;
Менеджері Агентзапущені на одному комп'ютері С1 для управління роботою RAID-масиву R2 . При такому варіанті підключення до мережі не потрібне.
Структура вхідних та вихідних даних
Основний обмін даними в системі в цілому відбувається двома каналами:
між Менеджеромі Агентомпо мережі за протоколом TCP/IP (команди Менеджерата відповіді Агента);
між Агентомі RAID-контролером через інтерфейс RS-232 (опитування контролера та відповіді від нього).
Загальну схему обміну даними у проекті проілюстровано на рис. 1.3.
Рис. 1.3. Обмін даними у програмі GUIRAIDManager
Формат даних між Менеджеромі Агентом, а також між Агентомі RAID-контролером описаний у параграфі «Формат даних модуля Агент» цього розділу.
Моїм завданням у цьому проекті є розробка модуля Агент. Тому розглянемо детальніше обмін даних у модулі Агентміж Менеджеромі RAID-контролером. Розбита на модулі структура Агентапоказано на рис. 1.4
Рис. 1.4. Обмін даними в модулі Агент
На даній схемі показано, що дані між Менеджеромі Агентомпроходять через модуль прийому та передачі даних по мережі. Для перевірки підключення МенеджераЦей модуль використовує блок авторизації. Усі дані аналізуються в блоці оброблювача команд Менеджера. Залежно від типу команди інформація надходить або в блок налаштувань, або в блок файлу історії або модуль опитування стану RAID. Останній служить для того, щоб посилати команди RAID-контролеру та отримувати від нього відповіді. Якщо під час запиту виникає помилка чи відповідь контролера містить критичне повідомлення, модуль нотифікації сповістить адміністратора про помилку.
У підрозділі «Вимоги до інформаційної та програмної сумісності» мають бути зазначені вимоги до інформаційних структур на вході та виході та методів рішення, вихідних кодів, мов програмування та програмних засобів, що використовуються програмою. За потреби повинен забезпечуватися захист інформації та програм.
приклад. ЕОМ має працювати під керуванням операційної системи не нижче, ніж Windows 98/NT 4.0. Вимога інформаційної сумісності має бути забезпечено роботою з файлами геометричної інформації певної структури як вхідну та вихідну інформацію.
Кінець роботи -
Ця тема належить розділу:
Технологія розробки програмного забезпечення
На сайті сайт читайте: "Технологія розробки програмного забезпечення"...
Якщо Вам потрібний додатковий матеріал на цю тему, або Ви не знайшли те, що шукали, рекомендуємо скористатися пошуком по нашій базі робіт:
Що робитимемо з отриманим матеріалом:
Якщо цей матеріал виявився корисним для Вас, Ви можете зберегти його на свою сторінку в соціальних мережах:
| Твітнути |
Всі теми цього розділу:
Вимоги до функціональних характеристик
У підрозділі «Вимоги до функціональних характеристик» повинні бути зазначені вимоги до складу виконуваних функцій, організації вхідних та вихідних даних, тимчасових характеристик
Угода про вимоги
Укладання угоди про вимоги – мета другої частини першої лабораторної роботи. Також, угода про вимоги є другим розділом курсової роботи. Нижче дається оп
Короткий опис виробу
Описуються коротко і в загальних поняттяхосновні функціональні властивості виробу Якщо програмний виріб є розширенням вже існуючого, характеризуються тільки його нові
Результуючі компоненти виробу
У даному розділінаводиться таблиця, подібна чи еквівалентна таблиці 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 представлені повідомлення, які можуть одержати системний програміст під час виконання налаштування, перевірки програми, а також користувач під час виконання програми.