17.11.2014

Любая работа начинается с задания, а работа технического писателя должна начинаться с технического задания. Осталось только разобраться, что это такое и зачем оно нам нужно. Прочитайте статью Кимберли Чан, чтобы не попасть в такую же ситуацию, как разработчик из уже любимой нами серии комиксов.

Что такое техническое задание на разработку программного обеспечения?

Большинство разработчиков предпочитают работать с техническим заданием на разработку программного обеспечения, так как этот документ обычно содержит следующее:

• Полное описание целей и функциональности программного обеспечения;
• Детали того, как программа будет работать с точки зрения скорости, времени отклика, доступности, мобильности, надёжности, скорости восстановления и т.д.;
• Варианты того, как пользователи будут использовать программное обеспечение;
• Определение того, как приложение будет взаимодействовать с оборудованием или другими программами;
• Нефункциональные требования (например: требования к обеспечению эффективности, стандарты качества, или проектные ограничения)

Почему это важно ?

ТЗ позволяет разработчикам ясно понять цели программного обеспечения и то, на чём нужно фокусироваться. Кроме того, оно:

Как написать ТЗ на разработку программного обеспечения?

Нет стандартного метода написания ТЗ, но мы можем дать несколько советов:

Создайте схему

Если у вас ещё нет шаблона, их можно найти в Интернете. Используйте шаблон для создания плана документа. Измените его в соответствии с потребностями вашей организации.

Планы технических заданий различаются в зависимости от организации и её процессов. Некоторые из них могут быть простыми, другие являются более подробными и сложными.

Вот пример простого плана ТЗ на ПО:

1. Сфера применения
2. Обзор системы
3. Ссылки
4. Определения
5. Примеры использования
6. Функциональные требования
7. Нефункциональные требования

После создания плана можно писать спецификацию. Вот несколько советов:

Выберите для написания лучшего

Писатель должен иметь превосходные коммуникационные навыки. Цель спецификации в том, чтобы её мог понять каждый. Всё, что остается неясным или недопонятым, может привести к не особо приятным последствиям. Многие предполагают, что участие в процессе технического писателя помогает предотвратить непонимание. Есть писатели, более опытные, чем разработчики, с талантом вносить точность и ясность. Технические писатели знают, как собирать и обрабатывать нужную информацию; они также знают, как донести требования заказчика.

Сделайте информацию визуальной

Изображение может сэкономить 1000 слов. Включите визуальную информацию, например, таблицы и графики, чтобы лучше донести идеи.

Не документируйте слишком много

Старайтесь не включать в документ пункты, которые не нужно документировать. ТЗ может стать слишком длинным, поэтому избегайте лишней информации.

Создайте онлайн-версию ТЗ и постоянно обновляйте её

По мере выполнения задач или если произошли изменения в штате или процессах, ТЗ необходимо будет обновлять. По этой причине сохраняйте виртуальную версию­ – это поможет убедиться, что вся команда при любом изменении получит обновлённый документ.

1. Введение
1.1. Наименование программы
1.2. Назначение и область применения программы
2. Требования к программе
2.1. Требования к функциональным характеристикам программы
2.2. Требования к надежности программы
2.2.1. Требования к обеспечению надежного функционирования программы
2.2.2. Время восстановления программы после отказа
2.2.3. Отказы программы из-за некоректных действий оператора
3. Условия эксплуатации программы 3.1. Климатические условия эксплуатации программы
3.2. Требования к квалификации и численности персонала
3.3. Требования к составу и параметрам технических средств
3.4. Требования к информационной совместимости
3.4.1. Требования к информационным структурам и методам решения
3.4.2. Требования к исходным кодам и языкам программирования
3.4.3. Требования к программным средствам, используемым программой
3.4.4. Требования к защите информации и программ
3.5. Специальные требования
4. Требования к программной документации
4.1. Предварительный состав программной документации
5. Технико-экономические показатели
5.1. Экономические преимущества разработки программы
6. Стадии и этапы разработки программы
6.1. Стадии разработки программы
6.2. Этапы разработки программы
6.3. Содержание работ по этапам
7. Порядок контроля и приемки
7.1. Виды испытаний
7.2. Общие требования к приемке работы

1. Введение

1.1. Наименование программы

Наименование программы: "Тестовая программа"

1.2. Назначение и область применения

Программа предназначена для...

2. Требования к программе

2.1. Требования к функциональным характеристикам

Программа должна обеспечивать возможность выполнения перечисленных ниже функций:

2.2. Требования к надежности

2.2.1 Требования к обеспечению надежного функционирования программы

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
а) организацией бесперебойного питания технических средств;
б) использованием лицензионного программного обеспечения;
в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г.
Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы,
не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств.
Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.

2.2.3. Отказы из-за некоректных действий оператора

Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой.
Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу конечного пользователя без предоставления ему административных привилегий

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям,
предъявляемым к техническим средствам в части условий их эксплуатации

3.2. Требования к квалификации и численности персонала

Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц — системный администратор и конечный пользователь программы — оператор.
Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:
а) задача поддержания работоспособности технических средств;
б) задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы;
в) задача установки (инсталляции) программы.
г) задача создания резервных копий базы данных.

3.3. Требования к составу и параметрам технических средств

3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:
3.3.1.1. процессор Pentium-2.0Hz, не менее;
3.3.1.2. оперативную память объемом, 1Гигабайт, не менее;
3.3.1.3. оперативную память объемом, 1Гигабайт, не менее;
3.3.1.4. операционную систему Windows 2000 Server или Windows 2003;
3.3.1.5. операционную систему Windows 2000 Server или Windows 2003;
3.3.1.6. Microsoft SQL Server 2000

3.4. Требования к информационной и программной совместимости

3.4.1. Требования к информационным структурам и методам решения

База данных работает под управлением Microsoft SQL Server. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой данной модулей экспорта внешних данных.

3.4.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются

3.4.3. Требования к программным средствам, используемым программой

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2000 Server или Windows 2003 и Microsoft SQL Server 2000

3.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются

3.5. Специальные требования

Специальные требования к данной программе не предьявляются

4. Требования к программной документации

4.1. Предварительный состав программной документации

Состав программной документации должен включать в себя:
4.1.1. техническое задание;
4.1.2. программу и методики испытаний;
4.1.3. руководство оператора;

5. Технико-экономические показатели

5.1. Экономические преимущества разработки

Ориентировочная экономическая эффективность не рассчитываются. Аналогия не проводится ввиду уникальности предъявляемых требований к разработке.

6. Стадии и этапы разработки

6.1. Стадии разработки

Разработка должна быть проведена в три стадии:
1. разработка технического задания;
2. рабочее проектирование;
3. внедрение.

6.2. Этапы разработки

На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
1. разработка программы;
2. разработка программной документации;
3. испытания программы.
На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1. постановка задачи;
2. определение и уточнение требований к техническим средствам;
3. определение требований к программе;
4. определение стадий, этапов и сроков разработки программы и документации на неё;
5. согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации.
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
1. разработка, согласование и утверждение и методики испытаний;
2. проведение приемо-сдаточных испытаний;
3. корректировка программы и программной документации по результатам испытаний.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика.

7. Порядок контроля и приемки

7.1. Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки.
Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

7.2. Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

О технических заданиях, об их важности и о правильном составлении приходится слышать постоянно. Техническое задание на создание сайтов, техническое задание на дизайн-проекты, техническое задание на разработку программ, техническое задание на то, техническое задание на это… Так ли важно это самое, техническое задание, панибратски именуемое, ТЗ? А давайте разберемся!

Для примера выделим одно из самых распространенных направлений – составление технического задания на разработку программ. И, пожалуй, начнем постепенно отвечать на возникающие вопросы.

Зачем техническое задание?

Отвечая на вопрос: «зачем?» важно понимать, о чем в действительности идет речь. Как уже было обозначено выше, в качестве примера составления технического задания, была выбрана разработка программ. А это означает, что у предприятия, фирмы, организации возникли реально существующие, текущие задачи, которые можно и нужно решать эффективнее, чем это делается на данный момент. Другими словами, необходимо заменить человеческий труд, дорогостоящий и переменного качества, на эффективную, и гораздо менее затратную работу программного обеспечения.

Действительно, сотрудникам нужен отпуск, все они хотят вовремя получать заработную плату, периодически «ходят на больничные», и, как правило, не изъявляют желания работать в выходные дни. Разработка программ, напротив, не только не приносит обозначенных проблем, с завидной регулярностью сменяющих одна другую, но и наоборот, решает их!

А вот на решениях остановимся более подробно. Поскольку список текущих проблем, необходимых для устранения посредством программного обеспечения, уже сформирован, настало время подумать и о самом процессе решения. Собираемся, заседаем, спорим, выясняем, и в итоге, вот оно, более-менее общее мнение ответственных лиц, о том, чего же будет делать будущая программа. Вот так и зарождается, предпосылка к составлению технического задания на разработку программ, медленно, но верно.

Конечно, всё может обстоять и совсем иначе. Поручаем составление технического задания специалистам фирмы, предлагающей разработку программ. Пара-тройка встреч в деловой, но дружеской обстановке, готовые брифы, бланки, договора, формы. Всё заполнили, все довольны. По крайней мере, пока.

Хозяин, как говориться, барин, и всегда волен выбирать оптимальный вариант, и по цене, и по качеству. В идеале, конечно, чтобы и то, и другое соизмерялось, но всегда приходится идти на компромиссы. При слишком низкой цене, компромисс по разработке программ, естественно сдвигается в сторону резкого ухудшения качества программного обеспечения. Однако, как ни парадоксально, то же самое происходит и при неграмотном составлении технического задания на разработку программ. Деньги заплачены, продукт получен, работает, да не так.

Вот, собственно, ответ на вопрос, зачем нужно составлять грамотное техническое задание на разработку программ, очевиден. Идем дальше.

Для кого техническое задание?

Техническое задание на разработку программ составляется, прежде всего, для тех людей, которые буду осуществлять эту самую разработку. Соответственно, оно должно быть понятно тому человеку, который ничего не знает о клиенте, и уж тем более, о его задачах и проблемах. По крайней мере, не знает пока.

Следовательно, техническое задание на разработку программ должно рассказать исполнителю и о фирме, и о целях, и о задачах. При этом чем конкретнее будет рассказ, тем лучше – и для повествователя, то бишь Заказчика разработки программ, и для слушателя, то есть для исполнителя проекта.

В общем виде, техническое задание преследует несколько целей, и хотя об этом, возможно надо было сказать в самом начале, исправлять упущения не поздно никогда. И так, цели:

• Организация
• Информация
• Коммуникация
• Юрисдикция.

Организация должна быть направлена на сам процесс, иначе говоря, упорядочить творчество и созидание программы, или программного комплекса. Строго, структура технического задания на разработку программ должна быть четкой и в тоже время лаконичной. Поскольку читать 120-150, а то и более, страниц неудобоваримого технического текста, творческая личность программиста попросту не сможет. А значит, краткость – сестра таланта.

Информационная составляющая ТЗ должна быть полной, но сжатой.

И опять же простое правило, «необходимо и достаточно». Его, как водится, нужно придерживаться всегда и везде, но при составлении технического задания по разработке программ, это правило становится номер один. Грамотное техническое задание – первый и последний документ, который расскажет обо всех желаниях заказчика в удобной для понимания программиста форме. Хотите перевернуть жизнедеятельность Вашей фирмы или предприятия на принципиально новый уровень? Тогда, техническое задание на разработку программ – та самая точка опоры, с помощью которой мир перевернется в указанном Вами направлении. А этим, согласитесь, пренебрегать, ну никак нельзя.

С коммуникациями несколько сложнее. Почему? Да потому что коммуникации, да ещё и в процессе относительно творческом, сложны всегда. Особенно, если говорить на разных языках. А языков тут может быть несколько, более точно – по числу участников проекта под кодовым названием «разработка программ».

Проще говоря:

• Клиент, он же Заказчик
• Менеджер проекта
• Исполнители проекта, они или он: программист(ы)
• Другие возможные участники, имеющие мнение: как сделать, как сделать лучше, и чем всё должно закончиться.

Естественно, создавая общий проект, эти участники вынуждены искать язык, доступный для общего понимания каждым. Таким языком и призвано стать техническое задание на разработку программ. В идеале, главное – установить канал связи между первым и третьим звеном, и чем меньше помех при этом будет вносить второе и четвертое звенья, тем качественнее будет результат, а разработка программ принесет желаемый результат при минимальных нервопотерях.

Вот и добрались до юрисдикции, попутно затронув вопрос о «потере нервов». Благодаря техническому заданию, можно судить о соответствии результата разработки программ и заданных начальных условий. Надо сказать, что кратковременностью памяти, страдают как Заказчики проекта, так и псполнители. Первые забывают об оговоренной стоимости, количестве правок, возможностях внедрения и отладки, а вторые – в принципе о том, что и когда они должны были сделать. Дабы свести амнезию и её последствия к минимуму, необходимо опять же, четкое и конкретное ТЗ на разработку программ!

Как составлять техническое задание?

Убедившись о необходимости, и даже бесценности технического задания при разработке программ, можно продолжать разговор дальше. Теперь мы подошли к самому серьезному вопросу: как составлять ТЗ, чтобы оно было грамотным, четким, лаконичным, но конкретным?! А ведь другого нам и не надо.

Об этом позаботились ещё в стародавние времена СССР, разработав целую концепцию стандартов, называемых ГОСТами. Удивительно, но разработка программ, этими стандартами также предусмотрена, что согласитесь, не может не радовать.

Разработка программ и составление технического задания по этому направлению регламентируется ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Также не лишними будут ещё два руководства:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 34.602-89 информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Эту троицу, несомненно, можно считать «святая святых» при разработке и составлении технического задания практически любой предметной области. Есть, конечно, и другие стандарты, руководствоваться которыми можно и нужно, но вспомним о «необходимом и достаточном».

Что мы имеем в итоге?

Ответ: общую структуру технического задания, в том числе и на разработку программ.

• Что нужно сделать в рамках проекта;
• Зачем это нужно, и для каких конкретно целей;
• Где будет использоваться результат проекта (читай, разработка программ), в какой сфере деятельности, и на каком уровне;
• Какие требования должна удовлетворять разработка программ;
• Что нужно сделать в процессе работы над проектом;
• Как будет оцениваться результат со стороны Заказчика;
• Какими документами устанавливается порядок взаимодействия по проекту;
• На чем основана инициация работы над проектом по разработке программ.

Более детально составить техническое задание на разработку программ поможет вторая часть указанного ГОСТа 19.201-78, предписывающая содержание разделов.

Отдельным пунктом нашей специфики – разработка программного обеспечения, хотелось бы выделить раздел требований к программному обеспечению. При составлении этого раздела, к вопросу нужно подходить формально. Иначе говоря, «открывать новое окно», «редактировать текущий файл посредством команд с пользовательских консолей», и «сохранять изменения при закрытии основного окна программы» — это четкий и формальный подход.

Также, разработка программ должна удовлетворять ряду требований, которые необходимо изложить в техническом задании. Вот список требований:

• к набору выполняемых программой функций;
• по организации входных и выходных данных;
• к быстродействию;
• к надежности функционирования;
• к длительности восстановления при отказах;
• по отказам в связи с некорректными действиями пользователя;
• к видам обслуживания;
• к числу и квалификации персонала, взаимодействующего с программой;
• к параметрам технических средств, на которых будет обеспечиваться нормальная работоспособность программы;
• к исходным языкам и кодам программирования, информационным структурам и сторонним программным средствам;
• по защите и информационной безопасности;
• к маркировке и упаковке;
• к условиям транспортировки и хранения.

Также список требований на разработку программ может быть изменен: дополнен или сокращен в зависимости от конкретных условий проекта.

Кто составляет техническое задание?

Пришла пора подводить итоги. Кто же должен взвалить на свои, наверняка, хрупкие плечи, столь тяжкий груз – составление технического задания на разработку программ. Естественно, менеджер проектов! именно этот человек непосильным трудом прокладывает дорогу к совместному счастью, гармонии и взаимопониманию Исполнителя и Заказчика.

Естественно, работа менеджера не менее творческая, чем того же программиста, и дабы избежать креативного хаоса и беспорядка, она также нуждается в четком оформлении. Расставим всё, что касается функций менеджера проектов при разработке, по своим местам:

1. Постановка задачи проекта;
2. Формирование и конкретизация требований к технической реализации;
3. Формулировка требований к разрабатываемой программе;
4. Согласование этапов, их длительности, и составление документации;
5. Указание языков и кодов программирования;
6. Составление, корректировка и утверждение у Заказчика технического задания.

Несмотря на кажущуюся простоту перечисленных функций, лишь небольшой процент менеджеров способен к их качественному выполнению. п чтобы не нашлось виноватых, необходимо техническое задание утверждать подписями представителей обоих сторон, обозначенных условиями Договора на разработку программ.

Ну а сторонам этим, необходимо руководствоваться ГОСТ 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.