Презентация, доклад по информатике на тему Техническое задание на разработку программного обеспечения

должно выглядеть?

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

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

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

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

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

исполнителю однозначно определить границу конкретного этапа выполнения. То есть, такие фразы, как «сделать так, чтобы было удобно и быстро» категорически не допускаются, так как у каждого отдельного заказчика свои собственные понятия удобства и скорости. Удобство, по сути своей, является вполне субъективным фактором, поэтому вышеприведенная фраза может привести к вечно длящимся переделкам и доработкам. Чтобы этого не было, стоит определять конкретные шаги: «меню должно состоять из следующих пунктов…», «Кнопка «Сохранить» должна располагаться в правом нижнем углу» и т. д.

продолжать разговор дальше. Теперь мы подошли к самому серьезному вопросу: как составлять ТЗ, чтобы оно было грамотным, четким, лаконичным, но конкретным.
Об этом позаботились ещё во времена СССР, разработав целую концепцию стандартов, называемых ГОСТами. Так, разработка программ, данными стандартами предусмотрена.
Разработка программ и составление технического задания по данному направлению регламентируется ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
Также не лишними будут ещё два руководства:
ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
В свою очередь, мы, как непосредственный разработчик программного обеспечения, можем предоставить рекомендации по созданию технического задания (ТЗ) на разработку программного обеспечения (ПО). Данные рекомендации помогут вам, как заказчику программы при составлении ТЗ.

(отдельная программа, отдельная БД, программный комплекс);
(2) цель разработки (для чего разрабатывается продукт);
(3) задачи разработки (какие именно задачи должны решаться при помощи данного ПО. Перечислить);
(4) заказчик (краткое описание заказчика — наименование, сфера деятельности).

БП (весь БП), которая касается разрабатываемого программного обеспечения. Такое описание может включать в себя:
(1) описание предоставляемых услуг (производимых товаров);
(2) взаимодействие с контрагентами (поставщиками, дилерами);
(3) внутренние процессы и устройство компании (организации) Заказчика (иерархия и количество отделов и подразделений, личный состав, описание взаимодействия между сотрудниками и отделами, отделов между собой). Документооборот;
(4) внешний документооборот;
(5) особенности БП (производства).

внешнему виду программы (логотипы, цвета, расположение элементов управления);
(2) описание форм ввода информации (окошки, ячейки, списки, указать какие именно пользователи, какую именно информацию вводят);
(3) справочники (списки постоянных данных, регулярно используемых в формах —наименования, адреса и т. д.);
(4) отчетные формы (типы отчетных форм, какие отчетные формы существуют и для каких пользователей);
(5) разделение прав доступа к информации и функциям системы (какие пользователи могут просматривать инфу, какие редактировать, каким пользователям доступны те или иные функции);
(6) требования к взаимодействию с другими системами (экспорт и импорт информации и т. д.).

ее настройки, администрирования в процессе разработки (редактирование служебной информации, создание пользователей и другие служебные функции).
5. Перспективы развития
Здесь следует указать перспективы развития программы после выполнения основного ТЗ: расширение функционала, создание дополнительных отчетов, переход на другие платформы и т. д. Данная информация необходима для предусмотрения в программе таких возможностей изначально.

разработки;
(2) используемые СУБД;
(3) количество пользователей системы;
(4) количество одновременно работающих пользователей;
(5) типы и качество каналов связи;
(6) технические характеристики работающих станций;
(7) технические характеристики серверов;
(8) требование к скорости отклика на запросы;
(9) требования к используемому оборудованию.