Технічне завдання (ТЗ) - вихідний документ, який є основою для розробки та випробування програми або автоматизованої системи. Технічне завдання на програму та програмне забезпечення розробляється відповідно до вимог. Підставою розробки ТЗ найчастіше є договір.
ТЗ на програму розробляється, перш за все, для тих людей, які надалі розроблятимуть програмний продукт. Як і будь-яке інше ТЗ на програму має бути гранично ясно і не містити двозначні формулювання і має максимально повно описувати всі вимоги та побажання Замовника до створюваної програми, але при цьому не варто забувати, що програмісти люди творчі та освоїти 150 аркушів технічного тексту їм не завжди під силу.
Кому доручити написання ТЗ на програму
Хочеться акцентувати увагу на помилці – доручити написання технічного завдання на програмний продукт програмісту, обгрунтовуючи тим, що програмісту буде простіше потім реалізовувати власне техзавдання.
Технічне завдання на програму має розроблятись технічним письменником! По-перше, крім знання ГОСТ 19.201-78, необхідне знання та інших стандартів (наприклад, ГОСТ 19.106-78, ГОСТ 19.104 – 78 та ін.), не багато програмістів знають ці ГОСТи, а ще менше погодяться їх вивчити. По-друге, необхідні знання та досвід володіння технічною письмовою мовою (не плутати з написанням коду програмного забезпечення). По-третє, тільки команда, що спільно працює (технічний письменник, програміст, менеджер проекту) зможуть разом розробити повноцінне технічне завданняна програму та програмне забезпечення.
Структура технічного завдання
МІНІСТЕРСТВО НАУКИ ТА ОСВІТИ
РОСІЙСЬКОЇ ФЕДЕРАЦІЇ
ГОУ ВПО «АДИГЕЙСЬКИЙ ДЕРЖАВНИЙ УНІВЕРСИТЕТ»
ФІЗИЧНИЙ ФАКУЛЬТЕТ
КАФЕДРА АСОІУ
ТЕХНІЧНЕ ЗАВДАННЯ НА СТВОРЕННЯ ПРОГРАМНОГО
ПРОДУКТУ
ВСТУП…………………………………………....…………………………. ... 3
1. ПІДСТАВИ ДЛЯ РОЗРОБКИ……………………………………….. ...…4
1.1. Документ, виходячи з якого ведеться разработка……………………....4
1.2. Організація, яка затвердила основу розробки, та дата його затвердження4
1.3. Найменування теми разработки…………....………………………………….4
2. ПРИЗНАЧЕННЯ РОЗРОБКИ……………....…………………………………..5
2.1 Критерії ефективності та якості програми…….………………………..5
2.2 Цілі розробки програми…………………………....………………………5
3. ВИМОГИ ДО ПРОГРАМИ…………………………....…………………...6
3.1 Вимоги до функціональних характеристик………....………………….6
3.1.1 Склад виконуваних функций…………………………….....……………….6
3.1.2 Організація вхідних та вихідних даних…………………....…………….6
3.1.3 Тимчасові показники і обсяг займаної пам'яті….....…………...6
3.2 Вимоги до надійності…………………………………………....……….…6
3.2.1 Вимоги до надійного функціонування……………………....………6
3.2.2 Контроль вхідної та вихідної інформації………………………….....…..7
3.2.3 Час відновлення після відмови……………………………………....….7
3.3 Умови експлуатації………………………………………………………......7
3.4 Вимоги до складу та параметрів технічних засобів…………………...7
3.5 Вимоги до мов програмування………………………………….......8
3.6 Вимоги до програмних засобів, використовуваних програмою……......8
3.7 Вимоги до програмної документації………………………………….....8
4. ТЕХНІКО-ЕКОНОМІЧНІ ПОКАЗНИКИ………………………… ..... 9
5. СТАДІЇ І ЕТАПИ РОЗРОБКИ……………………………………….........9
6. ПОРЯДОК КОНТРОЛЮ І ПРИЙМАННЯ…………………………………….........9
6.1 Види випробувань……………………………………………………………........9
6.2 Загальні вимогидо приймання……………………………………………….....10
7. ЕТАПИ ВПРОВАДЖЕННЯ………………………………………………………......10
ВСТУП
Повне найменування програмної розробки: " Програма К " , надалі іменована як " програма " . Коротка назва програми - "ПК".
На даний момент аналогічних програмних продуктів немає.
Програма, що розробляється, застосовується на будь-якому підприємстві, де є робочий персонал.
Розробник даного програмного продукту – студент групи 4А1 Іванов А.В. надалі іменований як "розробник".
Замовник програмного продукту – ВАТ «РТС», від імені директора А.М. Гутенко.
1 ПІДСТАВА ДЛЯ РОЗРОБКИ
1.1 Документ, на підставі якого ведеться розробка
Робота ведеться на підставі завдання з дисципліни. Теоретичні основи автоматизованого управління»
1.2 Організація, яка затвердила цей документ, та дата його затвердження
Завдання затверджено та видано начальником технічного відділу ВАТ «РТС» Козаковим А.В.
Козаков О.В.
1.3 Найменування теми розробки
Найменування теми розробки – «Облік робочого дня».
2 ПРИЗНАЧЕННЯ РОЗРОБКИ
Ця розробка є семестровою роботою з дисципліни «Теоретичні засади автоматизованого управління»
2.1 Критерії ефективності та якості програми
Соціальний чинник.Ця програмна технологія дуже проста в освоєнні і розрахована не тільки на професіоналів, але і на рядових користувачів, що працюють в Windows. Зручний, інтуїтивно зрозумілий інтерфейс у поєднанні з потужною системою допоміжних малюнків та підказок дозволяють працювати з програмою без попередньої підготовки.
Відповідність поточному стану ринку ПЗ даного профілю.На відміну від дорогих та складних програм «ПК» ідеально підходить для представників бізнесу, оскільки містить все, що їм необхідно, але не перевантажене марними та непотрібними можливостями. Технологія створення програми у візуальних середовищах програмування робить її інтерфейс універсальним та сумісним з операційними системами Windows 95/98/2000/XP.
Економічні чинники.Програма представляє найкраще співвідношення ціни і можливостей, що їй надаються, і безсумнівно займе свою нішу на ринку дешевих програм. Основними користувачами стануть представники бізнесу, які просто не можуть заплатити за дорогі програми фірми 1С та подібних до неї.
2.2 Цілі розробки програми
Створення цієї програми має низку техніко-економічних цілей:
Створення програмного продукту, який буде необхідний обліку робочого дня.
Створення дешевої альтернативи існуючим нині дорогим програмам.
Створення інтуїтивно зрозумілої програми зі зручним та універсальним Windows.
Про технічні завдання, про їхню важливість та про правильне складання доводиться чути постійно. Технічне завдання на створення сайтів, технічне завдання на дизайн-проекти, технічне завдання на розробку програм, технічне завдання на те, технічне завдання на це. А давайте розберемося!
Наприклад виділимо одне з найпоширеніших напрямів – складання технічного завдання розробку програм. І, мабуть, почнемо поступово відповідати на питання, що виникають.
Навіщо технічне завдання?
Відповідаючи питанням: «навіщо?» важливо розуміти, про що насправді йдеться. Як було зазначено вище, як приклад складання технічного завдання, було обрано розробка програм. І це означає, що з підприємства, фірми, організації виникли реально існуючі, поточні завдання, які можна і потрібно вирішувати ефективніше, ніж це робиться на даний момент. Іншими словами, необхідно замінити людську працю, дорогу та змінну якість, на ефективну, і набагато менш затратну роботу програмного забезпечення.
Справді, співробітникам потрібна відпустка, всі вони хочуть вчасно отримувати заробітну плату, періодично «ходять на лікарняні», і, як правило, не виявляють бажання працювати у вихідні дні. Розробка програм, навпаки, не тільки не приносить означених проблем, що із завидною регулярністю змінюють одна одну, а й навпаки, вирішує їх!
А ось на рішеннях зупинимося докладніше. Оскільки список поточних проблем, необхідних для усунення за допомогою програмного забезпечення, вже сформований, настав час подумати і про процес вирішення. Збираємось, засідаємо, сперечаємося, з'ясовуємо, і в результаті, ось вона, більш-менш загальна думка відповідальних осіб, про те, чого робитиме майбутня програма. Ось так і зароджується, передумова до складання технічного завдання на розробку програм, повільно, але правильно.
Звичайно, все може і зовсім інакше. Доручаємо складання технічного завдання спеціалістам фірми, що пропонує розробку програм. Пара-трійка зустрічей у діловій, але дружній обстановці, готові брифи, бланки, договори, форми. Усі заповнили, всі задоволені. Принаймні поки що.
Господар, як кажуть, пан, і завжди вільний вибирати оптимальний варіант, і за ціною, і за якістю. В ідеалі, звичайно, щоб і те, й інше порівнювалося, але завжди доводиться йти на компроміси. При надто низькій ціні, компроміс з розробки програм, природно зсувається у бік різкого погіршення якості програмного забезпечення. Однак, як не парадоксально, те саме відбувається і при неписьменному складанні технічного завдання на розробку програм. Гроші заплачені, продукт отримано, працює, та не так.
Ось, власне, відповідь на питання, навіщо потрібно складати грамотне технічне завдання на розробку програм, очевидна. Йдемо далі.
Для кого є технічне завдання?
Технічне завдання на розробку програм складається, перш за все, для тих людей, які здійснюватиму цю саму розробку. Відповідно, воно має бути зрозуміле тій людині, яка нічого не знає про клієнта, і тим більше, про його завдання та проблеми. Принаймні не знає поки що.
Отже, технічне завдання на розробку програм має розповісти виконавцю і про фірму, і про цілі, і завдання. При цьому чим конкретнішою буде розповідь, тим краще – і для оповідача, тобто Замовника розробки програм, і для слухача, тобто для виконавця проекту.
Загалом, технічне завдання переслідує кілька цілей, і хоча про це, можливо, треба було сказати на самому початку, виправляти недогляди не пізно ніколи. І так, цілі:
- Організація
- Інформація
- Комунікація
- юрисдикція.
Організація має бути спрямована на сам процес, інакше кажучи, упорядкувати творчість та творення програми, або програмного комплексу. Строго, структура технічного завдання на розробку програм має бути чіткою і в той же час лаконічною. Оскільки читати 120-150, а то й більше сторінок незручного технічного тексту, творча особистість програміста просто не зможе. Отже, стислість – сестра таланту.
Інформаційна складова ТЗ має бути повною, але стиснутою.
І знову ж таки просте правило, «необхідне і достатньо». Його, як водиться, потрібно дотримуватися завжди і скрізь, але при складанні технічного завдання з розробки програм це правило стає номер один. Грамотне технічне завдання – перший та останній документ, який розповість про всі бажання замовника у зручній для розуміння програміста формі. Бажаєте перевернути життєдіяльність Вашої фірми чи підприємства на принципово новий рівень? Тоді технічне завдання на розробку програм – та сама точка опори, за допомогою якої світ перевернеться у вказаному Вами напрямку. А цим, погодьтеся, нехтувати, ну ніяк не можна.
З комунікаціями дещо складніше. Чому? Та тому що комунікації, та ще й у процесі щодо творчого, складні завжди. Особливо, якщо говорити на різних мовах. А мов тут може бути кілька, точніше – за кількістю учасників проекту під кодовою назвою «розробка програм».
Простіше кажучи:
- Клієнт, він же Замовник
- Менеджер проекту
- Виконавці проекту, вони чи він: програміст(и)
- Інші можливі учасники, які мають думку: як зробити, як зробити краще і чим усе має закінчитися.
Звичайно, створюючи спільний проект, ці учасники змушені шукати мову, доступну для загального розуміння кожним. Такою мовою покликане стати технічне завдання на розробку програм. В ідеалі, головне – встановити канал зв'язку між першою та третьою ланкою, і чим менше перешкод при цьому вноситиме другу та четверту ланки, тим якіснішим буде результат, а розробка програм принесе бажаний результат при мінімальних нервовтратах.
От і дісталися юрисдикції, попутно торкнувшись питання про «втрату нервів». Завдяки технічному завданню, можна судити про відповідність результату розробки програм та заданих початкових умов. Треба сказати, що короткочасністю пам'яті страждають як Замовники проекту, так і розповсюджувачі. Перші забувають про обумовлену вартість, кількість правок, можливості впровадження та налагодження, а другі – у принципі про те, що і коли вони мали зробити. Щоб звести амнезію та її наслідки до мінімуму, необхідно знову ж таки, чітке та конкретне ТЗ на розробку програм!
Як складати технічне завдання?
Переконавшись про необхідність, і навіть безцінність технічного завдання розробки програм, можна продовжувати розмову далі. Тепер ми підійшли до найсерйознішого питання: як складати ТЗ, щоб воно було грамотним, чітким, лаконічним, але конкретним? Адже іншого нам і не треба.
Про це подбали ще в давнину СРСР, розробивши цілу концепцію стандартів, званих ГОСТами. Дивно, але розробка програм, цими стандартами також передбачена, що погодьтеся, не може не тішити.
Розробка програм та складання технічного завдання за цим напрямом регламентується ГОСТ 19.201-78 єдина системаПрограмної документації. Технічне завдання. Вимоги до змісту та оформлення.
Також не зайвими будуть ще два керівництва:
- ГОСТ 2.114-95 Єдина система конструкторської документації. Технічні умови;
- ДЕРЖСТАНДАРТ 34.602-89 інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи. Цю трійцю, безперечно, можна вважати «свята святих» при розробці та складанні технічного завдання практично будь-якої предметної галузі. Є, звичайно, й інші стандарти, керуватися якими можна і потрібно, але згадаємо про «необхідне та достатнє».
Що ми маємо у результаті?
Відповідь: загальну структуру технічного завдання, зокрема і розробку програм.
- Що потрібно зробити у рамках проекту;
- Навіщо це потрібно, і для яких саме цілей;
- Де буде використовуватися результат проекту (читай, розробка програм), у якій сфері діяльності та на якому рівні;
- Які вимоги має задовольняти розробка програм;
- Що потрібно зробити у процесі роботи над проектом;
- Як оцінюватиметься результат з боку Замовника;
- Якими документами встановлюється порядок взаємодії щодо проекту;
- На чому ґрунтується ініціація роботи над проектом з розробки програм.
Більш детально скласти технічне завдання на розробку програм допоможе друга частина вказаного ГОСТу 19.201-78, яка надає зміст розділів.
Окремим пунктом нашої специфіки – розробка програмного забезпечення, хотілося б виділити розділ вимог до програмного забезпечення. При складанні цього розділу до питання потрібно підходити формально. Інакше кажучи, «відкривати нове вікно», «редагувати поточний файл за допомогою команд з консолей користувача», і «зберігати зміни при закритті основного вікна програми» - це чіткий і формальний підхід.
Також розробка програм повинна задовольняти низку вимог, які необхідно викласти у технічному завданні. Ось перелік вимог:
- до набору виконуваних програмою функцій;
- з організації вхідних та вихідних даних;
- до швидкодії;
- до надійності функціонування;
- до тривалості відновлення за відмов;
- щодо відмови у зв'язку з некоректними діями користувача;
- до видів обслуговування;
- до кваліфікації персоналу, що взаємодіє з програмою;
- до параметрів технічних засобів, на яких забезпечуватиметься нормальна працездатність програми;
- до вихідних мов та кодів програмування, інформаційних структур та сторонніх програмних засобів;
- із захисту та інформаційної безпеки;
- до маркування та упаковки;
- до умов транспортування та зберігання.
Також перелік вимог на розробку програм може бути змінено: доповнено або скорочено залежно від конкретних умов проекту.
Хто складає технічне завдання?
Настав час підбивати підсумки. Хто ж має звалити на свої, напевно, тендітні плечі, такий тяжкий вантаж – складання технічного завдання на розробку програм. Звичайно, менеджер проектів!саме ця людина непосильною працею прокладає дорогу до спільного щастя, гармонії та взаєморозуміння Виконавця та Замовника.
Звичайно, робота менеджера не менш творча, ніж того ж програміста, і щоб уникнути креативного хаосу і безладдя, вона також потребує чіткого оформлення. Розставимо все, що стосується функцій менеджера проектів при розробці, на свої місця:
- Постановка задачі проекту;
- Формування та конкретизація вимог до технічної реалізації;
- Формулювання вимог до програми, що розробляється;
- Погодження етапів, їх тривалості та складання документації;
- Вказування мов та кодів програмування;
- Складання, коригування та затвердження у Замовника технічного завдання.
Незважаючи на простоту перелічених функцій, лише невеликий відсоток менеджерів здатний до їх якісного виконання. щоб не знайшлося винних, необхідно технічне завдання затверджувати підписами представників обох сторін, позначених умовами Договору на розробку програм.
Ну а цим сторонам, необхідно керуватися ГОСТ 19.201-78, якому ні багато, ні мало, а майже 30 років.
Related Posts
Поняття «зворотний інжиніринг» є сучасним формулюванням колишнього поняття – копіювання, удосконалення… З розвитком комп'ютерних технологій,…
По суті, з інформаційними технологіямилюдство стикалося і стикається на кожному кроці своєї життєдіяльності. Просто…
Поняття реінжинірингу народилося в 90-ті роки, як осмислена відповідь на проблеми, що виникли при масовій автоматизації.
17.11.2014
Будь-яка робота починається із завдання, а робота технічного письменника має починатися з технічного завдання. Залишилося тільки розібратися, що це таке і навіщо воно нам потрібне. Прочитайте статтю Кімберлі Чан, щоб не потрапити в таку саму ситуацію, як розробник із вже улюбленої серії коміксів.
Що таке технічне завдання для розробки програмного забезпечення?
Більшість розробників вважають за краще працювати з технічним завданням на розробку програмного забезпечення, оскільки цей документ зазвичай містить таке:
- Повний опис цілей та функціональності програмного забезпечення;
- Деталі того, як програма працюватиме з точки зору швидкості, часу відгуку, доступності, мобільності, надійності, швидкості відновлення тощо;
- Варіанти того, як користувачі використовуватимуть програмне забезпечення;
- Визначення того, як програма буде взаємодіяти з обладнанням або іншими програмами;
- Нефункціональні вимоги (наприклад: вимоги до забезпечення ефективності, стандарти якості або проектні обмеження)
Чому це важливо?
ТЗ дозволяє розробникам ясно зрозуміти цілі програмного забезпечення та те, на чому потрібно фокусуватися. Крім того, воно:
Як написати ТЗ на розробку програмного забезпечення?
Немає стандартного методу написання ТЗ, але ми можемо дати кілька порад:
Створіть схему
Якщо у вас немає шаблону, їх можна знайти в Інтернеті. Використовуйте шаблон для створення плану документа. Змініть його відповідно до потреб вашої організації.
Плани технічних завдань різняться залежно від організації та її процесів. Деякі з них можуть бути простими, інші є більш докладними та складними.
Ось приклад простого плану ТЗ на ПЗ:
- Сфера використання
- Огляд системи
- Посилання
- Визначення
- Приклади використання
- Функціональні вимоги
- Нефункціональні вимоги
Після створення плану можна написати специфікацію. Ось кілька порад:
Виберіть для написання кращого
Письменник повинен мати чудові комунікаційні навички. Мета специфікації у тому, щоб її міг зрозуміти кожен. Все, що залишається незрозумілим чи недозрозумілим, може призвести до не дуже приємних наслідків. Багато хто припускає, що участь у процесі технічного письменника допомагає запобігти нерозумінню. Є письменники, досвідченіші, ніж розробники, з талантом вносити точність та ясність. Технічні письменники знають, як збирати та обробляти потрібну інформацію; вони також знають, як донести вимоги замовника.
Зробіть інформацію візуальною
Зображення може заощадити 1000 слів. Увімкніть візуальну інформацію, наприклад, таблиці та графіки, щоб краще донести ідеї.
Не документуйте занадто багато
Намагайтеся не включати до документа пункти, які не потрібно документувати. ТЗ може стати надто довгим, тому уникайте зайвої інформації.
Створіть онлайн-версію ТЗ та постійно оновлюйте її
У міру виконання завдань або якщо відбулися зміни у штаті чи процесах, ТЗ необхідно буде оновлювати. З цієї причини зберігайте віртуальну версію – це допоможе переконатися, що вся команда за будь-якої зміни отримає оновлений документ.
Цей стандарт встановлює порядок побудови та оформлення технічного завдання на розробку програми або програмного виробу для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Стандарт повністю відповідає СТ РЕВ 1627-79.
Правила оформлення
Технічне завдання оформляють відповідно до ГОСТ 19.106-78 на аркушах формату 11 і 12 за ГОСТ 2.301-68, як правило, без заповнення полів аркуша. Номери аркушів (сторінок) проставляються у верхній частині аркуша над текстом.
Лист затвердження та титульний лист
Лист затвердження та титульний лист оформляють відповідно до ГОСТ 19.104-78.
Інформаційну частину (анотацію та зміст), лист реєстрації змін допускається до документа не включати.
Зміни та доповнення
Для внесення змін або доповнень до технічного завдання на наступних стадіях розробки програми або програмного виробу випускають доповнення до нього. Узгодження та затвердження доповнення до технічного завдання проводять у тому самому порядку, який встановлено для технічного завдання.
Врахувати всі деталі на початковому етапі розробки неможливо. Насправді зазначений підхід застосовується дуже часто. У розділі «Стадії та етапи розробки» слід явно вказати можливість внесення змін та доповнень до технічного завдання: «Вміст розділів цього технічного завдання може бути змінено та доповнено за погодженням із Замовником».
Склад розділів технічного завдання
Технічне завдання має містити такі розділи:
Вступ;
основи розробки;
призначення розробки;
вимоги до програми чи програмного виробу;
вимоги до програмної документації;
техніко-економічні показники;
стадії та етапи розробки;
порядок контролю та приймання;
до технічного завдання допускається включати додатки.
Залежно від особливостей програми чи програмного виробу допускається уточнювати зміст розділів, вводити нові розділи чи об'єднувати окремі. Строго за погодженням із Замовником. Згода Замовника обов'язково має бути відображена у тексті технічного завдання.
Як навчально-тренувальну будемо використовувати реальну програму з графічним інтерфейсом користувача, що забезпечує можливість виконання декількох шаблонних функцій (наприклад, нескладний текстовий редактор).
Вступ
У розділі вказують найменування, коротку характеристику області застосування програми чи програмного виробу та об'єкта, у якому використовують програму чи програмний виріб.
Основне правило роботи з текстом - деталізація, дроблення тексту на структурні одиниці, підрозділи, пункти та підпункти. Зміст тексту матиме чітку структуру, що сприятиме легкому пошуку необхідного матеріалу. Текст документа стане структурованим та зручним для читання. Створюємо підрозділи:
Найменування програми
Найменування – "Текстовий редактор для роботи з файлами формату rtf".
Коротка характеристика галузі застосування
Програма призначена для застосування в профільних підрозділах на об'єктах Замовника.
Вміст окремих пунктів який завжди очевидно. При труднощі слід підходити формально. Правку можна буде внести на етапі узгодження технічного завдання із Замовником.
Підстави для розробки
У розділі мають бути вказані:
документ (документи), виходячи з яких ведеться розробка;
організація, яка затвердила цей документ, та дата його затвердження;
найменування та (або) умовне позначенняРозробка теми.
У підрозділі слід навести відомості, що містяться у Договорі.
Підстава для проведення розробки
Підставою для проведення розробки є Договір (лист і т.д.) № 666 від 15 березня 2004 року (що входить до такого від такого). Договір узгоджений з Директором ДУП «Спецважмонтажбудсільгоспавтоматика» Івановим Петром Івановичем, який іменується в подальшому Замовником, і затверджений Генеральним директором ВАТ «Суперсофт» Блюмкінсом Іваном Ароновичем, який надалі називається Виконавцем, такого-то березня 2008 року.
Зручно скористатися розділом «Загальні відомості» ГОСТ 34.602-89, оскільки розробник має повне право доповнювати та видаляти розділи технічного завдання на власний розсуд. У той же час відомості, зазначені вище, містяться у Договорі. Чи слід наводити їх у технічному завданні – залежить від конкретного випадку.