Как писать техническое задание на программу по ГОСТ 19.201-78?
Техническое задание
Примеры разработки программной документации
Как писать техническое задание на программный продукт или что значит фраза "по форме ГОСТ Рассмотрим, как правильно составить техническое задание на разработку программного продукта. Номера листов страниц проставляют в верхней части листа над текстом. Информационную часть аннотацию и содержание , лист регистрации изменений допускается в документ не включать. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания. Техническое задание должно содержать следующие разделы: В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. В разделе "Введение" указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие. В разделе "Основания для разработки" должны быть указаны: В разделе "Назначение разработки" должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Раздел "Требования к программе или программному изделию" должен содержать следующие подразделы: В подразделе "Требования к функциональным характеристикам" должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. В подразделе "Требования к надежности" должны быть указаны требования к обеспечению надежного функционирования обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. В подразделе "Условия эксплуатации" должны быть указаны условия эксплуатации температура окружающего воздуха, относительная влажность и т. В подразделе "Требования к составу и параметрам технических средств" указывают необходимый состав технических средств с указанием их основных технических характеристик. В подразделе "Требования к информационной и программной совместимости" должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования я программным средствам, используемым программой. При необходимости должна обеспечиваться защита информации и программ. В подразделе "Требования к маркировке и упаковке" в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки. В подразделе "Требования к транспортированию и хранению" должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях. В разделе "Требования к программной документации" должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней. В разделе "Технико-экономические показатели" должны быть указаны: В разделе "Стадии и этапы разработки" устанавливают необходимые стадии разработки, этапы и содержание работ перечень программных документов, которые должны быть разработаны, согласованы и утверждены , а также, как правило, сроки разработки я определяют исполнителей. В разделе "Порядок контроля и приемки" должны быть указаны виды испытаний и общие требования к приемке работы. В приложениях к техническому заданию, при необходимости, приводят: Модель предполагает дальнейшее развитие в программный комплекс, предназначенный для заочных и дистантных форм обучения высших и средних учебных заведений, учебных центров повышения квалификации и центров переподготовки сотрудников. Основанием для разработки является учебный план кафедры ИУ6 на й семестр, утвержденный заведующим кафедрой. Модель является первым этапом реализации сложного комплекса системы дистанционного обучения, предназначенного для внедрения и использования в учебных заведениях. Назначение системы — реализовать новый подход к обучению, позволяющий людям с периферии иметь возможность изучить учебные программы, подготовленные в крупных ВУЗах страны, а также позволяющий получать образование или повышать квалификацию дома или на рабочем месте без отрыва от производства. Требования к программе или программному изделию. Разрабатываемая модель должна обладать следующими функциями:. Серверная часть должна хранить базу данных пользователей, имеющих доступ к системе и обеспечивать аутентификацию пользователей согласно имеющихся записей. Серверная часть должна хранить базу данных учебных курсов, доступных для изучения пользователями. Серверная часть должна поддерживать соединение до пользователей одновременно. Клиентская часть должна хранить базу данных адресов серверов для подключения. Надежность системы в целом зависит от надежности используемой операционной системы. Серверная часть должна обслуживать без сбоев одновременное подключение и работу до пользователей. Обе части должны без потерь передавать информацию по каналу связи между клиентом и сервером. Стандартные условия эксплуатации программных продуктов. Необходимые сотрудники для обслуживания серверной части системы — системный администратор для обслуживания собственно сервера регистрация и удаление пользователей, добавление и настройка учебных материалов и группа разработчиков учебных курсов, численность и состав которой зависит от конкретной дисциплины курса. Для нормальной работы как серверной, так и клиентской частей необходимо:. Для хранения информации требуется использование баз данных формата MDB Microsoft Access. Для доступа к базам данных Microsoft Access 97 требуется наличие установленного ядра работы с БД Microsoft JET DAO версии 3. В качестве средства разработки требуется использовать интегрированную среду разработки Borland Delphi 5, включающую редактор исходных текстов, компилятор, компоновщик и отладчик. В качестве средства проектирования структуры базы данных и создания файла базы данных требуется использовать Microsoft Access Требования к программной документации. Программной документацией к разрабатываемой модели системы дистанционного обучения является рассчетно-пояснительная записка. Создание библиотеки классов, реализующей разработанный протокол. Принятие решения по разработке формата файлов для хранения учебных курсов. Разработка библиотеки классов для поддержки принятого формата. На основе созданной библиотеки классов для работы с файлом учебного курса создание средств просмотра курса. Испытание представленной модели и контроль качества ее работы провести на базе компьютерного класса кафедры ИУ6. Во время испытаний проверить работу системы по следующим позициям:. Соединение клиента -ов с сервером, проверка правильности обработки сервером соединения. Аутентификация пользователя на сервере. Проверка изменения состава зарегистрированных пользователей и групп. Подключение на сервере учебного курса с тем, чтобы он был доступен для просмотра. В 4 четверти ученики школы будут интенсивно готовиться к концерту, который состоится 8 декабря, в воскресенье, в Glen Eira Town Hall. Задача социального становления личности ребенка является важной для любого государства. Особенно это значимо для нашего общества в период переориентац Заседания Общественного Совета Объединения граждан и юридических лиц по оказанию помощи казакам, казачкам, вдовам казаков, казачьим семьям, попавшим в трудную с. Заседания Общественного Совета Объединения граждан и юридических лиц по оказанию помощи казакам, казачкам, вдовам казаков, казачьим семьям, попавшим в Напишите уравнения реакций, протекающих на катоде и аноде, и общее уравнение электролиза водного раствора хлорида кобальта II на инертных электродах Сохрани ссылку в одной из сетей: Информация о документе Дата добавления: Доступные форматы для скачивания: Основания для разработки Основанием для разработки является учебный план кафедры ИУ6 на й семестр, утвержденный заведующим кафедрой. Назначение разработки Модель является первым этапом реализации сложного комплекса системы дистанционного обучения, предназначенного для внедрения и использования в учебных заведениях. Разрабатываемая модель должна обладать следующими функциями: Иметь доступный и простой интерфейс пользователя. Иметь гибкую систему настроек. Для нормальной работы как серверной, так и клиентской частей необходимо: Оперативная память не менее 16 Мb. Жесткий диск объемом не менее 1 Gb. Наличие адаптера подключения к сети сетевой карты, модема и т. Стадии и этапы разработки. Порядок контроля и приемки. Во время испытаний проверить работу системы по следующим позициям: Запуск серверной и клиентской частей. Просмотр учебного курса с клиентского рабочего места. Так, предлагается быстро написать, что придет на ум по Ускорение научно- технического прогресса, развитие всех форм самоуправления в сфере производства Но технические взаимные услуги, раз на них пойдут Мною было дано задание на Исследование концепций дистанционного обучения и имеющихся на сегодняшний день решений. Объединение разработанных частей в единую модель. Сдача и защита курсового проекта.
Этого достаточно для разработки программы, проведения испытаний и сдачи ее заказчику. Наверное, в каждом втором-третьем из ваших технических заданий на программы, тем или иным образом оказавшихся в руках автора, содержатся аутентичные тексты из настоящей статьи. Это здорово и чертовски приятно, но следует учитывать тот факт, что прошло почти десятилетие с момента первой публикации статьи, а за это время многое изменилось, особенно в части нормативных документов. Из песни, конечно, слов не выкинешь, но настройтесь на креатив и выдумывайте какие-нибудь более современные ее аранжировки. Техническое задание оформляют в соответствии с ГОСТ Номера листов страниц проставляются в верхней части листа над текстом [из п. Лист утверждения и титульный лист Изменения и дополнения Состав разделов технического задания Содержание разделов Введение Основания для разработки Назначение разработки Требования к программе или программному изделию Требования к программной документации Технико-экономические показатели Экономические преимущества разработки Стадии и этапы разработки Порядок контроля и приемки Приложения Выводы. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ Информационную часть аннотацию и содержание , лист регистрации изменений допускается в документ не включать [из п. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. Учесть все детали на начальных стадиях разработки невозможно, поэтому на практике указанный подход применяется весьма часто. Техническое задание должно содержать следующие разделы:. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. Любые манипуляции с разделами - строго по согласованию с заказчиком. Отдельные подразделы технического задания могут подействовать на условного заказчика, как красная тряпка на быка. Заказчика, даже условного, раздражать не следует. В спорных подразделах будут рассмотрены пути поиска компромиссных решений. Ключевые позиции, в которых уступка заказчику равносильна затягиванию петли на шее исполнителя, будут также откомментированы с обоснованием жесткой позиции исполнителя. Чтобы излишне не отягощать ход повествования, в качестве учебно-тренировочной будем использовать реальную программу с графическим пользовательским интерфейсом , обеспечивающую возможность выполнения нескольких шаблонных функций. Пусть такой программой станет несложный текстовый редактор. Основное правило работы с текстом — детализация, дробление текста на структурные единицы, - разделы, подразделы, пункты и подпункты, см. Текст документа станет структурированным и удобным для чтения. Наименование программы Краткая характеристика области применения. Программа предназначена к применению в профильных подразделениях на объектах заказчика. Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. Скорректировать документ можно будет в ходе согласования технического задания с заказчиком. В подразделе следует привести сведения, содержащиеся в договоре между заказчиком и исполнителем. Основание для проведения разработки Наименование и условное обозначение темы разработки. Основанием для проведения разработки является Договор письмо и т. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании — зависит от конкретного случая. Функциональное назначение Эксплуатационное назначение. Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf. Детали — перечень функций и т. Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа? Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. По причине отсутствия размерной технической совместимости. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение. Программа должна эксплуатироваться в профильных подразделениях на объектах заказчика. Пользователями программы должны являться сотрудники профильных подразделений объектов заказчика. Два крайних предложения - не в тему. При проведении переговоров с реальным заказчиком подраздел будет откорректирован. Большая часть содержимого указанного стандарта просто переписывается в техническое задание. Требования к функциональным характеристикам Требования к надежности Условия эксплуатации Требования к составу и параметрам технических средств Требования к информационной и программной совместимости Требования к маркировке и упаковке Требования к транспортированию и хранению Специальные требования. Требования к составу выполняемых функций Требования к организации входных данных Требования к организации выходных данных Требования к временным характеристикам. Программа должна обеспечивать возможность выполнения перечисленных ниже функций:. Входные данные программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC Файлы указанного формата должны размещаться храниться на локальных или съемных носителях , отформатированных согласно требованиям операционной системы. Любой файл иного формата , но с расширением rtf, открываться не должен. Если файловая система отформатирована как FAT32, файлы с локального или съемного носителя , отформатированного, к примеру, в формате ext3, открываться не должны. Требования те же, что и к организации выходных данных. Тот самый случай, когда следует объединить оба пункта технического задания. Следует уточнить, предъявляет ли заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Правда, такую сумму придется обосновывать. Если временные характеристики для заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам, см. Надежность — штука тонкая и очень опасная. Но перечень функций и видов их отказов , согласно п. Скорее всего, дождаться от заказчика чего-либо вразумительного не удастся. Стоит разъяснить заказчику, что надежное функционирование программы зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы , а также предложить заказчику ряд жестких мер для повышения надежности и устойчивости функционирования программы. Требования к обеспечению надежного устойчивого функционирования программы Время восстановления после отказа Отказы из-за некорректных действий оператора. Надежное устойчивое функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:. К списку можно добавить еще несколько десятков нормативно-технических документов. В ходе первичного согласования технического задания заказчик, скорее всего, начнет проявлять склонность к компромиссу. Возможен более гуманный подход. Под надежностью правда, системы, по тому же ГОСТу можно считать безотказное выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: Если в указанном интервале времени программа не даст сбоев , требования по надежности считаются выполненными. Если заказчик, наконец, убедился, что надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой — в разделе обязательно следует написать такую фразу:. Требования к обеспечению надежного устойчивого функционирования программы не предъявляются. Время восстановления после отказа , вызванного сбоем электропитания технических средств иными внешними факторами , не фатальным сбоем не крахом операционной системы, не должно превышать стольких-то минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем крахом операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Перечень аварийных ситуаций ситуаций также составляет заказчик и согласовывает с исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств. Отказы программы возможны вследствие некорректных действий оператора пользователя при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу пользователя без предоставления ему административных привилегий. Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания. Климатические условия эксплуатации Требования к видам обслуживания Требования к численности и квалификации персонала. Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести климатические испытания в полном объеме за счет исполнителя. Не зря говорят, что история развивается по восходящей спирали Программа не требует проведения каких-либо видов обслуживания. Если заказчик в ходе согласования технического задания сошлется на отсутствие ресурсов или желание проводить все виды обслуживания собственными силами, имеет смысл предложить разработку технического задания на сопровождение программного изделия за отдельные деньги отдельным договором. Откажется — следует считать программу необслуживаемой. Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц — системный администратор и пользователь программы — оператор. Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:. Пользователь программы оператор должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы. Персонал должен быть аттестован на II квалификационную группу по электробезопасности для работы с конторским оборудованием. Персонал, не имеющий II квалификационной группы по электробезопасности, не имеет права даже близко подходить к ПЭВМ и конторскому оборудованию. Следует подбирать технику не хуже той, на которой будет производиться разработка. Логично затребовать, чтобы технику предоставил заказчик не позднее указанного срока. Речь идет, разумеется, о компьютере. В состав технических средств должен входить IBM-совместимый персональный компьютер ПЭВМ , включающий в себя:. При необходимости должна обеспечиваться защита информации и программ [из п. Требования к информационным структурам и методам решения Требования к исходным кодам и языкам программирования Требования к программным средствам, используемым программой Требования к защите информации и программ. Иформационная структура файла должна включать в себя текст, содержащий разметку , предусмотренную спецификацией формата rtf. Требования к информационным структурам файлов на входе и выходе, а также к методам решения не предъявляются. Системные программные средства , используемые программой, должны быть представлены лицензионной локализованной версией операционной системы такой-то. Допускается применение пакета обновления такого-то. Требования к защите информации и программ не предъявляются. Подобных требований следует избегать, если нет особого желания разработать что-то вроде концепции обеспечения информационной безопасности согласно ГТК РФ. Защита от несанкционированного доступа к информации. Термины и определения Обеспечить некоторый уровень защиты информации и программ возможно, обеспечить безопасность невозможно. Заказчик, скорее всего, это осознает и проявлять настойчивость не станет. Программа поставляется в виде программного изделия - на дистрибутивном внешнем оптическом носителе компакт-диске. Речь идет, разумеется, о маркировке и упаковке дистрибутивного носителя данных. Требование к маркировке Требования к упаковке. Программное изделие должно иметь маркировку с обозначением товарного знака компании-разработчика, типа наименования , номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России если таковой имеется. Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ Качество маркировки проверяется самыми изощренными способами — сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача исполнителя - прикрыться сертификатом соответствия затребовать сертификат у полиграфистов. Упаковка программного изделия должна осуществляться в упаковочную тару предприятия-изготовителя поставщика. Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель поставщик тары. Условия упаковывания Порядок упаковки. Заказчик получит программное изделие надлежащего внешнего вида. В случае возврата программного изделия по рекламации в ненадлежащем виде наличие царапин, трещин и прочих дефектов исполнитель сможет предъявить претензии в части нарушения заказчиком условий упаковывания и не принять программное изделие. Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного ГОСТ или ГОСТ 89 согласно чертежам предприятия-изготовителя тары. Программное изделие упаковывается с применением чехлов из водонепроницаемой пленки с обязательным наличием химически неагрессивных влагопоглотителей силикагеля. Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта. Эксплуатационная документация должна быть уложены в потребительскую тару вместе с программным изделием. На верхний слой прокладочного материала укладывается товаросопроводительная документация - упаковочный лист и ведомость упаковки. Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги. В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб, но требования есть и остаются требованиями. В подразделе приведены условия транспортирования и хранения из ранее разработанного документа на какие-то технические средства. Это касается и требований к порядку упаковки. Заказчик не вправе нарушать условий транспортирования и хранения. Исполнитель сможет отказать заказчику в возврате программного изделия, утверждая, что ненадлежащий внешний вид программного изделия является следствием несоблюдения условий транспортирования и хранения. Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний. При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный. При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания пыли и атмосферных осадков. Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже:. Программа должна обеспечивать взаимодействие с пользователем оператором посредством графического пользовательского интерфейса , разработанного согласно рекомендациям компании-производителя операционной системы. Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом. Программа и методика испытаний потребуется, чтобы показать заказчику, что разработанная исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных приемо-сдаточных испытаний заказчик и исполнитель подпишут акт завершения работы. И, тем самым, работа будет закрыта, условия договора выполнены. Допускается объединять отдельные виды эксплуатационных документов за исключением ведомости эксплуатационных документов и формуляра. Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год — сеансов работы на одном рабочем месте. Как рассчитать экономическую эффективность? Следовало бы получить от заказчика цифры. Заказчик, в свою очередь, вряд ли заинтересован раскрывать свои финансовые дела. Скорее всего, вопрос отпадет сам собой. Положим, заказчик оснащает программой десяток рабочих мест. Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:. Стадии разработки и этапы регламентированы ГОСТ Стадии разработки Этапы разработки Содержание работ по этапам. На этапе разработки программы должна быть выполнена работа по программированию кодированию и отладке программы. На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:. На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах заказчика. Виды испытаний Общие требования к приемке работы. Приемосдаточные испытания должны проводиться на объекте заказчика в сроки…. Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в протоколе испытаний. На основании протокола испытаний исполнитель совместно с заказчиком подписывают акт приемки-сдачи программы в эксплуатацию. Если есть, почему не привести. И обязательно выложить перечень ГОСТов, на основании которых должна проводиться разработка. Настоящий стандарт, несмотря на свой немалый возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма, заявки и т. Указанные сведения должны быть отражены в Договоре. Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Заимствуйте наши материалы с блеском! При цитировании на своих ресурсах наших материалов используйте активные ссылки на них. Перейти к основному содержанию. Главное меню Главная О компании Образец договора Вакансии Карта сайта Услуги и цены Разработка технической документации на заказ Изучение объекта предмета документирования Определение целей и задач документирования Выбор уточнение состава комплекта документов Уточнение требований к оформлению комплекта документов Сбор информации, консультации и поиск нормативов по предметной области Разработка документации, внесение изменений, согласование и передача ее заказчику Обратная разработка техдокументации реверс-инжиниринг Оценка качества технической документации Проверка структуры разделов документов Проверка содержимого разделов документов Проверка терминологии и обозначений физических величин Проверка оформления документов Подготовка экспертного заключения Консультации и сопровождение разработки техдокументации Семинары и консультации по техническому документированию Консультации в форуме проектировщиков и разработчиков технической документации О стоимости Часть II - практика Часть I - состав в картинках Часть II - состав технического обеспечения АС в картинках Часть III - состав программного обеспечения АС в картинках Часть IV - состав информационного обеспечения АС в картинках Часть V - совместимость АС без картинок Анкетирование и интервьюирование на предпроектных стадиях создания АС Интеграция автоматизированных систем АС на основе XML Как писать Часть I - обобщенная структура по ГОСТ 19 и сравнительный ее анализ с IEEE Std Часть II - обобщенная структура по ГОСТ 19, IEEE Std и пример содержимого Часть II - оценочные элементы надежности Часть III - оценочные элементы сопровождаемости Часть IV - оценочные элементы удобства применения Часть V - оценочные элементы эффективности Часть VI - оценочные элементы универсальности Работаем над ошибками Рерайтинг в техническом документировании, или делайте это с блеском! ГОСТы как инструмент самоубеждения оппонента Экспертиза техдокументации: Часть I - почему мы не любим ГОСТы и что нам за это будет? Часть II - Унификация в стандартах. Часть III - Унификация в стандартах. Упрощенный язык и технический перевод Быстрый доступ к технической терминологии на tdocs. Мультисайтинг на Drupal, или О командах проекта и проектных командах Контакты. Итак, Техническое задание оформляют в соответствии с ГОСТ Лист утверждения и титульный лист Изменения и дополнения Состав разделов технического задания Содержание разделов Введение Основания для разработки Назначение разработки Требования к программе или программному изделию Требования к программной документации Технико-экономические показатели Экономические преимущества разработки Стадии и этапы разработки Порядок контроля и приемки Приложения Выводы Лист утверждения и титульный лист Лист утверждения и титульный лист оформляют в соответствии с ГОСТ Меньше слов — меньше вопросов. Изменения и дополнения Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Состав разделов технического задания Техническое задание должно содержать следующие разделы: Содержание разделов Отдельные подразделы технического задания могут подействовать на условного заказчика, как красная тряпка на быка. Краткая характеристика области применения Программа предназначена к применению в профильных подразделениях на объектах заказчика. Основание для проведения разработки Наименование и условное обозначение темы разработки Основание для проведения разработки Основанием для проведения разработки является Договор письмо и т. Функциональное назначение Эксплуатационное назначение Функциональное назначение Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf. Эксплуатационное назначение Программа должна эксплуатироваться в профильных подразделениях на объектах заказчика. Требования к составу выполняемых функций Требования к организации входных данных Требования к организации выходных данных Требования к временным характеристикам Требования к составу выполняемых функций Программа должна обеспечивать возможность выполнения перечисленных ниже функций: Требования к организации входных данных Входные данные программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC Требования к организации выходных данных Требования те же, что и к организации выходных данных. Требования к временным характеристикам Требования к временным характеристикам программы не предъявляются. Требования к обеспечению надежного устойчивого функционирования программы Время восстановления после отказа Отказы из-за некорректных действий оператора Требования к обеспечению надежного устойчивого функционирования программы Надежное устойчивое функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже: Испытания пpогpаммных сpедств на наличие компьютеpных виpусов. Если заказчик, наконец, убедился, что надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой — в разделе обязательно следует написать такую фразу: Время восстановления после отказа Время восстановления после отказа , вызванного сбоем электропитания технических средств иными внешними факторами , не фатальным сбоем не крахом операционной системы, не должно превышать стольких-то минут при условии соблюдения условий эксплуатации технических и программных средств. Отказы из-за некорректных действий оператора Отказы программы возможны вследствие некорректных действий оператора пользователя при взаимодействии с операционной системой. Климатические условия эксплуатации Требования к видам обслуживания Требования к численности и квалификации персонала Климатические условия эксплуатации Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации. Требования к видам обслуживания Программа не требует проведения каких-либо видов обслуживания. Требования к численности и квалификации персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц — системный администратор и пользователь программы — оператор. В перечень задач, выполняемых системным администратором, должны входить: В состав технических средств должен входить IBM-совместимый персональный компьютер ПЭВМ , включающий в себя: Требования к информационным структурам и методам решения Требования к исходным кодам и языкам программирования Требования к программным средствам, используемым программой Требования к защите информации и программ Требования к информационным структурам и методам решения Иформационная структура файла должна включать в себя текст, содержащий разметку , предусмотренную спецификацией формата rtf. Требования к программным средствам, используемым программой Системные программные средства , используемые программой, должны быть представлены лицензионной локализованной версией операционной системы такой-то. Требования к защите информации и программ Требования к защите информации и программ не предъявляются. Требование к маркировке Требования к упаковке Требование к маркировке Программное изделие должно иметь маркировку с обозначением товарного знака компании-разработчика, типа наименования , номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России если таковой имеется. Требования к упаковке Упаковка программного изделия должна осуществляться в упаковочную тару предприятия-изготовителя поставщика. Порядок упаковки Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного ГОСТ или ГОСТ 89 согласно чертежам предприятия-изготовителя тары. Потребительская тара должна быть оклеена лентой клеевой по ГОСТ Масса НЕТТО - не более кг. Масса БРУТТО - не более кг. Условия транспортирования и хранения Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний. Климатические условия транспортирование приведены ниже: Специальные требования Программа должна обеспечивать взаимодействие с пользователем оператором посредством графического пользовательского интерфейса , разработанного согласно рекомендациям компании-производителя операционной системы. Экономические преимущества разработки Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит: Стадии разработки Этапы разработки Содержание работ по этапам Стадии разработки Разработка должна быть проведена в три стадии: Содержание работ по этапам На этапе разработки техзадания должны быть выполнены перечисленные ниже работы: На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ: Общие требования к приемке работы На основании протокола испытаний исполнитель совместно с заказчиком подписывают акт приемки-сдачи программы в эксплуатацию. Приложения В приложениях к техническому заданию, при необходимости, приводят: Техническое задание, требования к содержанию и оформлению; и так далее.. Выводы Настоящий стандарт, несмотря на свой немалый возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Требования к содержанию и оформлению. ГОСТ Задание Программа Технический. Вверх Как писать техническое задание на сайт? Новое Как писать технико-экономическое обоснование ТЭО? Что такое интуитивно-понятный интерфейс? О командах проекта и проектных командах. Анкетирование и интервьюирование на предпроектных стадиях создания АС. Как изготовители, поставщики и органы по сертификации дурят трудящихся. Что такое концепции и концептуальные документы? Интеграция автоматизированных систем АС на основе XML. Статьи по теме Техническое задание на программу ведения справочника написаний и произношений по ГОСТ Как писать техническое задание на сайт? Необходимость составления технических условий на этапе разработки и утверждения технического задания по ГОСТ
Схема женского лица
Зарипов данис контракт
Слушать музыку перевод на английский
Правила землепользования и застройки выборгский район
Оценка результатов огэ по английскому языку