Цей стандарт встановлює порядок побудови та оформлення технічного завдання на розробку програми або програмного виробу для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Стандарт повністю відповідає СТ РЕВ 1627-79.
Правила оформлення
Технічне завданняоформляють відповідно до ГОСТ 19.106-78 на аркушах формату 11 та 12 за ГОСТ 2.301-68, як правило, без заповнення полів аркуша. Номери аркушів (сторінок) проставляються у верхній частині аркуша над текстом.
Лист затвердження та титульний лист
Лист затвердження та титульний лист оформляють відповідно до ГОСТ 19.104-78.
Інформаційну частину (анотацію та зміст), лист реєстрації змін допускається до документа не включати.
Зміни та доповнення
Для внесення змін або доповнень до технічного завдання на наступних стадіях розробки програми або програмного виробу випускають доповнення до нього. Узгодження та затвердження доповнення до технічного завдання проводять у тому самому порядку, який встановлено для технічного завдання.
Врахувати всі деталі на початковому етапі розробки неможливо. Насправді зазначений підхід застосовується дуже часто. У розділі «Стадії та етапи розробки» слід явно вказати можливість внесення змін та доповнень до технічного завдання: «Вміст розділів цього технічного завдання може бути змінено та доповнено за погодженням із Замовником».
Склад розділів технічного завдання
Технічне завдання має містити такі розділи:
Вступ;
основи розробки;
призначення розробки;
вимоги до програми чи програмного виробу;
вимоги до програмної документації;
техніко-економічні показники;
стадії та етапи розробки;
порядок контролю та приймання;
до технічного завдання допускається включати додатки.
Залежно від особливостей програми чи програмного виробу допускається уточнювати зміст розділів, вводити нові розділи чи об'єднувати окремі. Строго за погодженням із Замовником. Згода Замовника обов'язково має бути відображена у тексті технічного завдання.
Як навчально-тренувальну будемо використовувати реальну програму з графічним інтерфейсом користувача, що забезпечує можливість виконання декількох шаблонних функцій (наприклад, нескладний текстовий редактор).
Вступ
У розділі вказують найменування, коротку характеристику області застосування програми чи програмного виробу та об'єкта, у якому використовують програму чи програмний виріб.
Основне правило роботи з текстом - деталізація, дроблення тексту на структурні одиниці, підрозділи, пункти та підпункти. Зміст тексту матиме чітку структуру, що сприятиме легкому пошуку необхідного матеріалу. Текст документа стане структурованим та зручним для читання. Створюємо підрозділи:
Найменування програми
Найменування – "Текстовий редактор для роботи з файлами формату rtf".
Коротка характеристика галузі застосування
Програма призначена для застосування в профільних підрозділах на об'єктах Замовника.
Вміст окремих пунктів який завжди очевидно. При труднощі слід підходити формально. Правку можна буде внести на етапі узгодження технічного завдання із Замовником.
Підстави для розробки
У розділі мають бути вказані:
документ (документи), виходячи з яких ведеться розробка;
організація, яка затвердила цей документ, та дата його затвердження;
найменування та (або) умовне позначенняРозробка теми.
У підрозділі слід навести відомості, що містяться у Договорі.
Підстава для проведення розробки
Підставою для проведення розробки є Договір (лист і т.д.) № 666 від 15 березня 2004 року (що входить до такого від такого). Договір узгоджений з Директором ДУП «Спецважмонтажбудсільгоспавтоматика» Івановим Петром Івановичем, який іменується в подальшому Замовником, і затверджений Генеральним директором ВАТ «Суперсофт» Блюмкінсом Іваном Ароновичем, який надалі називається Виконавцем, такого-то березня 2008 року.
Зручно скористатися розділом «Загальні відомості» ГОСТ 34.602-89, оскільки розробник має повне право доповнювати та видаляти розділи технічного завдання на власний розсуд. У той же час відомості, зазначені вище, містяться у Договорі. Чи слід наводити їх у технічному завданні – залежить від конкретного випадку.
Крамського Романа ІТ-09-2
Лабораторна робота №3
Формалізація вимог до програмної системи з використанням діаграми прецедентів (Use сase diagram)
Мета роботи : навчитися аналізувати та формалізувати вимоги замовника з використанням UML, виконувати планування робіт та складати технічне завдання на створення програмного продукту.
Хід виконання роботи
Вивчити теоретичні відомості.
Виконати аналіз та формалізацію вимог замовника на розробку програмного продукту відповідно до індивідуального завдання.
Розробити діаграму прецедентів використання та виконати опис прецедентів.
Виконати планування робіт із створення програмного продукту.
Розробити технічне завдання створення програмного продукту.
Зробити висновки щодо вибору моделі створення програмного продукту.
Вимоги до змісту роботи
Назва роботи.
Мета роботи.
Формулювання індивідуального завдання.
Діаграма прецедентів використання з її описом (особливу увагу приділити повноті опису прецедентів та ролей користувачів програмної системи).
Технічне завдання створення програмного продукту (особливу увагу приділити плануванню робіт зі створення програмного продукту, формулюванню етапів з використання термінів глосарію і предметної області загалом, і навіть опису ролей користувачів програмної системи).
Висновки щодо вибору моделі створення програмного продукту.
Технічне завданняна розробку«ПМК дляавтоматизації обробки та апроксимації експериментальних даних»
Підстави для розробки
Підставою для розробки є тема індивідуального завдання для дипломної роботи «ПМК для автоматизації обробки та апроксимації експериментальних даних» та дисципліни ПКС.
Спеціальна частина: Розробка ПЗ для розпізнавання ділильних сіток і апроксимації.
Призначення розробки
Програмний комплекс призначений для обробки та апроксимації експериментальних даних і повинен виконувати такі функції:
Розпізнавати зображення;
Виконувати згладжування зображення;
Виділяти ділильні вузли.
Вимоги до програмного виробу
При реалізації та використанні інформаційної системи мають бути враховані вимоги до функціональних характеристик, надійності проекту, параметрів технічних засобів, інформаційної та програмної сумісності.
Вимоги до функціональних характеристик
Програмний комплекс має виконувати такі функції:
Розпізнавання зображення (роздільна здатність не менше 600×300 DPI);
Виділення ділильних вузлів (не більше 1000 вузлів);
Обчислення координат ділових вузлів (з точністю 0,01 мм);
Формування масиву даних (трохи більше 30 секунд);
Згладжування зображення (2 і більше методу апроксимації залежно криві або поверхні);
Збереження результату (понад 3 формати).
Вимоги до надійності
Програмний продукт повинен стійко функціонувати та не призводити до збоїв операційної системи в аварійних ситуаціях. У разі виникнення збою повинні видаватися коректні повідомлення із зазначенням подальших дій. Для попередження виникнення помилок потрібна наявність посібника з експлуатації ПМК.
Програмний продукт повинен забезпечувати контроль вхідної та вихідної інформації на відповідність заданим форматам даних.
Програмний продукт повинен забезпечувати обробку помилкових дій користувача з видачею відповідних повідомлень.
Надійне функціонування ПМК, що розробляється, забезпечуватиметься при використанні сучасних ЕОМ, чіткому дотриманні рекомендацій. Забороняється видаляти будь-які файли проекту, доступ до них має бути обмеженим.
Повинне бути резервне копіювання таблиць для подальшого їх відновлення у разі потреби.
Умови експлуатації
Умови експлуатації повинні відповідати санітарним та технічним нормам експлуатації ЕОМ. Для роботи з ПК допускаються працівники, які мають достатній рівень знань у предметній галузі. Для обслуговування цього програмного комплексу потрібна 1 людина.
Вимоги до складу та параметрів технічних засобів
Мінімальні вимоги до програмних та апаратних засобів для нормального функціонування програми:
Процесор: AMD або Intel з частотою 1GHz і вище;
ОЗУ: 256 Mbі вище;
ОС: Windows XP і вище;
Монітор: SVGA монітор;
Місткість залізниці: вільного місця не менше 500 Mb;
Інші вимоги: мережна карта, клавіатура, маніпулятор миша.
Вимоги до інформаційної та програмної сумісності
Програмна система функціонує серед Windows XP і вище. Програмний продукт створюється за допомогою інструментального засобу розробки додатків С Sharp.
Вимоги до програми документації
Попередній склад програмної документації встановлений відповідно до ГОСТ 19.101-77. Нижче наведено список програмних документів та їх зміст.
Текст програми – запис програми з необхідними поясненнями та коментарями.
Опис програми – відомості про логічну структуру та функціонування програми.
Програма і методика випробувань – вимоги, підлягають перевірці під час випробування програми, і навіть порядок і способи контролю.
Технічне завдання – цей документ.
Пояснювальна записка – схема алгоритму, загальний опис алгоритму чи функціонування програми, і навіть обґрунтування прийнятих технічних і техніко-економічних рішень.
Експлуатаційні документи – опис застосування, посібник користувача.
Стадії та етапи розробки
Розробка ведеться у кілька етапів, відповідно до ГОСТ 19.101-77 та включає етапи, наведені в таблиці 1.5.
Таблиця - Етапи розробки
|
Термін виконання | ||
|
Технічне завдання |
Аналіз та формалізація вимоги до ПЗ, планування робіт |
|
|
Ескізний проект |
Попередня розробка проекту ПЗ з використанням UML: діаграми прецедентів використання, діаграми класів та послідовності |
|
|
Технічний проект |
Реалізація робочої версії програмного забезпечення з основною функціональністю; тестування |
|
|
Робочий проект |
Коригування та доопрацювання програмного забезпечення; розробка документації |
|
|
Впровадження |
Розробка заходів щодо впровадження та супроводу ПЗ |
Порядок контролю та приймання
ПМК автоматизації роботи обробки та апроксимації експериментальних даних повинен відповідати вимогам замовника та відповідати всім поставленим функціональним вимогам.
Контроль програмного продукту здійснюється у такому порядку.
-перевірка функціональності розробленого ПЗ;
-перевірка реакції програми на різні дії користувача;
-перевірка вихідних даних;
-Після виходу з програми операційна система повинна продовжувати працювати коректно.
p align="justify"> Прийняття створеної системи полягає в тестуванні його на робочих місцях після налаштування програмного продукту.
Про технічні завдання, про їхню важливість та про правильне складання доводиться чути постійно. Технічне завдання на створення сайтів, технічне завдання на дизайн-проекти, технічне завдання на розробку програм, технічне завдання на те, технічне завдання на це. А давайте розберемося!
Наприклад виділимо одне з найпоширеніших напрямів – складання технічного завдання розробку програм. І, мабуть, почнемо поступово відповідати на питання, що виникають.
Навіщо технічне завдання?
Відповідаючи питанням: «навіщо?» важливо розуміти, про що насправді йдеться. Як було зазначено вище, як приклад складання технічного завдання, було обрано розробка програм. І це означає, що з підприємства, фірми, організації виникли реально існуючі, поточні завдання, які можна і потрібно вирішувати ефективніше, ніж це робиться на даний момент. Іншими словами, необхідно замінити людську працю, дорогу та змінну якість, на ефективну, і набагато менш затратну роботу програмного забезпечення.
Справді, співробітникам потрібна відпустка, всі вони хочуть вчасно отримувати заробітну плату, періодично «ходять на лікарняні», і, як правило, не виявляють бажання працювати у вихідні дні. Розробка програм, навпаки, не тільки не приносить означених проблем, що із завидною регулярністю змінюють одна одну, а й навпаки, вирішує їх!
А ось на рішеннях зупинимося докладніше. Оскільки список поточних проблем, необхідних для усунення за допомогою програмного забезпечення, вже сформований, настав час подумати і про процес вирішення. Збираємось, засідаємо, сперечаємося, з'ясовуємо, і в результаті, ось вона, більш-менш загальна думка відповідальних осіб, про те, чого робитиме майбутня програма. Ось так і зароджується, передумова до складання технічного завдання на розробку програм, повільно, але правильно.
Звичайно, все може і зовсім інакше. Доручаємо складання технічного завдання спеціалістам фірми, що пропонує розробку програм. Пара-трійка зустрічей у діловій, але дружній обстановці, готові брифи, бланки, договори, форми. Усі заповнили, всі задоволені. Принаймні поки що.
Господар, як кажуть, пан, і завжди вільний вибирати оптимальний варіант, і за ціною, і за якістю. В ідеалі, звичайно, щоб і те, й інше порівнювалося, але завжди доводиться йти на компроміси. При надто низькій ціні, компроміс з розробки програм, природно зсувається у бік різкого погіршення якості програмного забезпечення. Однак, як не парадоксально, те саме відбувається і при неписьменному складанні технічного завдання на розробку програм. Гроші заплачені, продукт отримано, працює, та не так.
Ось, власне, відповідь на питання, навіщо потрібно складати грамотне технічне завдання на розробку програм, очевидна. Йдемо далі.
Для кого є технічне завдання?
Технічне завдання на розробку програм складається, перш за все, для тих людей, які здійснюватиму цю саму розробку. Відповідно, воно має бути зрозуміле тій людині, яка нічого не знає про клієнта, і тим більше, про його завдання та проблеми. Принаймні не знає поки що.
Отже, технічне завдання на розробку програм має розповісти виконавцю і про фірму, і про цілі, і завдання. При цьому чим конкретнішою буде розповідь, тим краще – і для оповідача, тобто Замовника розробки програм, і для слухача, тобто для виконавця проекту.
Загалом, технічне завдання переслідує кілька цілей, і хоча про це, можливо, треба було сказати на самому початку, виправляти недогляди не пізно ніколи. І так, цілі:
- Організація
- Інформація
- Комунікація
- юрисдикція.
Організація має бути спрямована на сам процес, інакше кажучи, упорядкувати творчість та творення програми, або програмного комплексу. Строго, структура технічного завдання на розробку програм має бути чіткою і в той же час лаконічною. Оскільки читати 120-150, а то й більше сторінок незручного технічного тексту, творча особистість програміста просто не зможе. Отже, стислість – сестра таланту.
Інформаційна складова ТЗ має бути повною, але стиснутою.
І знову ж таки просте правило, «необхідне і достатньо». Його, як водиться, потрібно дотримуватися завжди і скрізь, але при складанні технічного завдання з розробки програм це правило стає номер один. Грамотне технічне завдання – перший та останній документ, який розповість про всі бажання замовника у зручній для розуміння програміста формі. Бажаєте перевернути життєдіяльність Вашої фірми чи підприємства на принципово новий рівень? Тоді технічне завдання на розробку програм – та сама точка опори, за допомогою якої світ перевернеться у вказаному Вами напрямку. А цим, погодьтеся, нехтувати, ну ніяк не можна.
З комунікаціями дещо складніше. Чому? Та тому що комунікації, та ще й у процесі щодо творчого, складні завжди. Особливо, якщо говорити на різних мовах. А мов тут може бути кілька, точніше – за кількістю учасників проекту під кодовою назвою «розробка програм».
Простіше кажучи:
- Клієнт, він же Замовник
- Менеджер проекту
- Виконавці проекту, вони чи він: програміст(и)
- Інші можливі учасники, які мають думку: як зробити, як зробити краще і чим усе має закінчитися.
Звичайно, створюючи спільний проект, ці учасники змушені шукати мову, доступну для загального розуміння кожним. Такою мовою покликане стати технічне завдання на розробку програм. В ідеалі, головне – встановити канал зв'язку між першою та третьою ланкою, і чим менше перешкод при цьому вноситиме другу та четверту ланки, тим якіснішим буде результат, а розробка програм принесе бажаний результат при мінімальних нервовтратах.
От і дісталися юрисдикції, попутно торкнувшись питання про «втрату нервів». Завдяки технічному завданню, можна судити про відповідність результату розробки програм та заданих початкових умов. Треба сказати, що короткочасністю пам'яті страждають як Замовники проекту, так і розповсюджувачі. Перші забувають про обумовлену вартість, кількість правок, можливості впровадження та налагодження, а другі – у принципі про те, що і коли вони мали зробити. Щоб звести амнезію та її наслідки до мінімуму, необхідно знову ж таки, чітке та конкретне ТЗ на розробку програм!
Як складати технічне завдання?
Переконавшись про необхідність, і навіть безцінність технічного завдання розробки програм, можна продовжувати розмову далі. Тепер ми підійшли до найсерйознішого питання: як складати ТЗ, щоб воно було грамотним, чітким, лаконічним, але конкретним? Адже іншого нам і не треба.
Про це подбали ще в давнину СРСР, розробивши цілу концепцію стандартів, званих ГОСТами. Дивно, але розробка програм, цими стандартами також передбачена, що погодьтеся, не може не тішити.
Розробка програм та складання технічного завдання за цим напрямом регламентується ГОСТ 19.201-78 єдина системаПрограмної документації. Технічне завдання. Вимоги до змісту та оформлення.
Також не зайвими будуть ще два керівництва:
- ГОСТ 2.114-95 Єдина система конструкторської документації. Технічні умови;
- ДЕРЖСТАНДАРТ 34.602-89 інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи. Цю трійцю, безперечно, можна вважати «свята святих» при розробці та складанні технічного завдання практично будь-якої предметної галузі. Є, звичайно, й інші стандарти, керуватися якими можна і потрібно, але згадаємо про «необхідне та достатнє».
Що ми маємо у результаті?
Відповідь: загальну структуру технічного завдання, зокрема і розробку програм.
- Що потрібно зробити у рамках проекту;
- Навіщо це потрібно, і для яких саме цілей;
- Де буде використовуватися результат проекту (читай, розробка програм), у якій сфері діяльності та на якому рівні;
- Які вимоги має задовольняти розробка програм;
- Що потрібно зробити у процесі роботи над проектом;
- Як оцінюватиметься результат з боку Замовника;
- Якими документами встановлюється порядок взаємодії щодо проекту;
- На чому ґрунтується ініціація роботи над проектом з розробки програм.
Більш детально скласти технічне завдання на розробку програм допоможе друга частина вказаного ГОСТу 19.201-78, яка надає зміст розділів.
Окремим пунктом нашої специфіки – розробка програмного забезпечення, хотілося б виділити розділ вимог до програмного забезпечення. При складанні цього розділу до питання потрібно підходити формально. Інакше кажучи, «відкривати нове вікно», «редагувати поточний файл за допомогою команд з консолей користувача», і «зберігати зміни при закритті основного вікна програми» - це чіткий і формальний підхід.
Також розробка програм повинна задовольняти низку вимог, які необхідно викласти у технічному завданні. Ось перелік вимог:
- до набору виконуваних програмою функцій;
- з організації вхідних та вихідних даних;
- до швидкодії;
- до надійності функціонування;
- до тривалості відновлення за відмов;
- щодо відмови у зв'язку з некоректними діями користувача;
- до видів обслуговування;
- до кваліфікації персоналу, що взаємодіє з програмою;
- до параметрів технічних засобів, на яких забезпечуватиметься нормальна працездатність програми;
- до вихідних мов та кодів програмування, інформаційних структур та сторонніх програмних засобів;
- із захисту та інформаційної безпеки;
- до маркування та упаковки;
- до умов транспортування та зберігання.
Також перелік вимог на розробку програм може бути змінено: доповнено або скорочено залежно від конкретних умов проекту.
Хто складає технічне завдання?
Настав час підбивати підсумки. Хто ж має звалити на свої, напевно, тендітні плечі, такий тяжкий вантаж – складання технічного завдання на розробку програм. Звичайно, менеджер проектів!саме ця людина непосильною працею прокладає дорогу до спільного щастя, гармонії та взаєморозуміння Виконавця та Замовника.
Звичайно, робота менеджера не менш творча, ніж того ж програміста, і щоб уникнути креативного хаосу і безладдя, вона також потребує чіткого оформлення. Розставимо все, що стосується функцій менеджера проектів при розробці, на свої місця:
- Постановка задачі проекту;
- Формування та конкретизація вимог до технічної реалізації;
- Формулювання вимог до програми, що розробляється;
- Погодження етапів, їх тривалості та складання документації;
- Вказування мов та кодів програмування;
- Складання, коригування та затвердження у Замовника технічного завдання.
Незважаючи на простоту перелічених функцій, лише невеликий відсоток менеджерів здатний до їх якісного виконання. щоб не знайшлося винних, необхідно технічне завдання затверджувати підписами представників обох сторін, позначених умовами Договору на розробку програм.
Ну а цим сторонам, необхідно керуватися ГОСТ 19.201-78, якому ні багато, ні мало, а майже 30 років.
Related Posts
Поняття «зворотний інжиніринг» є сучасним формулюванням колишнього поняття – копіювання, удосконалення… З розвитком комп'ютерних технологій,…
По суті, з інформаційними технологіямилюдство стикалося і стикається на кожному кроці своєї життєдіяльності. Просто…
Поняття реінжинірингу народилося в 90-ті роки, як осмислена відповідь на проблеми, що виникли при масовій автоматизації.
МІНІСТЕРСТВО НАУКИ ТА ОСВІТИ
РОСІЙСЬКОЇ ФЕДЕРАЦІЇ
ГОУ ВПО «АДИГЕЙСЬКИЙ ДЕРЖАВНИЙ УНІВЕРСИТЕТ»
ФІЗИЧНИЙ ФАКУЛЬТЕТ
КАФЕДРА АСОІУ
ТЕХНІЧНЕ ЗАВДАННЯ НА СТВОРЕННЯ ПРОГРАМНОГО
ПРОДУКТУ
ВСТУП…………………………………………....…………………………. ... 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.