Этапы и процессы, а также примерные результаты по каждому этапу определены в стандартах (международный – ISO 12207: 1995 “Information Technology – Software Life Cycle Process”; российский ГОСТ ЕСПД 19.001-77 — 19.604-78).
Этапы работ (ГОСТ 19.102-77)
| Стадии разработки | Этапы работ | Содержание работ |
| 1. Техническое задание | Обоснование необходимости разработки программы | Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ |
| Научно-исследовательские работы | Определение структуры входных и выходных данных. Предварительный выбор методоврешения задач. Обоснование целесообразности применения ранее разработанных программ. Определенже требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи | |
| Разработка и утверждение технического задания | Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания | |
| 2. Эскизный проект | Разработка эскизного проекта Утверждение эскизного проекта | Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования Разработка пояснительной записки. Согласование и утверждение эскизного проекта |
| 3. Технический проект | Разработка технического проекта Утверждение технического проекта | Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта |
| 4. Рабочий проект | Разработка программы Разработка программной документации Испытания.программы | Программирование и отладка программы. Разработка программных документов в соответствии с требованиями ГОСТ 19.101—77 Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний |
| 5. Внедрение | Подготовка и передача программы | Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ |
Техническое задание
44-ФЗ | Правила применения ПП 102. Ограничения и условия допуска при закупке Медицинских изделий.
1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях — вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
16.1.2 Техническое задание (ГОСТ 19.201-78)
Техническое задание должно содержать следующие разделы:
· основания для разработки;
· требования к программе или программному изделию;
· требования к программной документации;
· стадии и этапы разработки;
· порядок контроля и приемки;
· в техническое задание допускается включать приложения.
Содержание разделов
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
2.2. В разделе «Основания для разработки» должны быть указаны:
· документ (документы), на основании которых ведется разработка;
· организация, утвердившая этот документ, и дата его утверждения.
· наименование и (или) условное обозначение темы разработка.
2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
· требования к функциональным характеристикам;
· требования к надежности;
· требования к составу и параметрам технических средств;
· требования к информационной и программной совместимости;
· требования к маркировке и упаковке;
· требования к транспортированию и хранению;
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.).
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5. В подразделе «Требования к информационной и. программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой. При необходимости должна обеспечиваться защита информации и программ.
2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.
2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы,
2.8. В приложениях к техническому заданию, при необходимости, приводят:
· перечень научно-исследовательских и других работ, обосновывающих разработку;
· схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
· другие источники разработки.
Комментарий к ГОСТу
Во введении кратко описывают предметную область, задачи которой потребовали автоматизации. Например, на некотором предприятии выполняется учет материалов на складах, который выполняется таким-то и таким-то образом. Описывается то, что есть сейчас, а не то, что должно быть.
Раздел «Основания для разработки» мы пропускаем, а название и шифр темы (если такой есть) указываем в разделе «Назначение…». Там же кратко указывается, для чего выполняется проект, например: автоматизировать прием экзамена по технологии программирования, — двумя-тремя фразами.
Основным разделом ТЗ должен быть раздел изложения требований к программному продукту. Обязательно изложить в техническом задании следующие требования:
· требования к функциональным характеристикам;
· требования к надежности;
· требования к составу и параметрам технических средств;
· требования к информационной и программной совместимости;
· требования к хранению;
Требования к функциональным характеристикам – это достаточно подробное изложение того, что должен делать программный продукт (не описывая, как это будет реализовано).
Для задач АСУ чрезвычайно важным является раздел, в котором излагаются требования к надежности. Здесь должны быть указаны методы и средства, с помощью которых будет обеспечена защита ПО от сбоев и отказов, а также от несанкционированного доступа и преднамеренного искажения. Например, вход по имени и паролю, подсчет контрольных сумм и/или сумм CRC, отказ во вводе недопустимых символов, проверка введенной информации в справочнике, выбор из списка вместо ввода, сообщения и предупреждения для пользователя, система помощи и т.д.
Предполагаемый состав и параметры технических средств необходимо указывать в двух вариантах: в минимально необходимом и в нормально-рабочем.
В разделе о совместимости указывается операционная система, язык и инструмент реализации. Для программных продуктов, являющихся частью большой системы, указываются форматы и входных файлов данных, и какая задача системы их создает, форматы выходных файлов данных, и для каких задач эти данные предназначены.
Требования к хранению – это предполагаемый носитель готового программного продукта, с которого будет производиться установка.
16.1.2.3 Западные авторы о требованиях
Программные продукты делятся на 3 категории:
1. Независимый от пользователя проект – требования определяет разработчик; примеры – современные программные продукты, выпускаемые западными фирмами; из российских – система 1С.
2. Управляемый пользователем проект – требования формирует заказчик; примеры – правительственные заказы (космонавтика).
3. Контролируемый пользователем проект; требования формируются совместно; примеры – многочисленные АСУ.
Кроме требований обязательным условием успешного проекта является постановка целей. Практика показывает, что самой большой ошибкой проекта является отсутствие явной формулировки целей. При постановке целей работа обычно идет лучше. Цели – не требования. Цели — это явно сформулированное стремление обеспечить заданные качества программного продукта в процессе разработки.
Примером может служить цель обеспечить надежность и эффективность проектируемой системы. Цели часто противоречат друг другу. Майерс[28] определяет цели следующим образом: «Цели – это конкретные ориентиры для программного продукта. Процесс постановки целей – это процесс принятия компромиссных решений».
Следующая цитата из [28] поясняет эту мысль: «Программное обеспечение State Farm обслуживает порядка 15 000 000 владельцев полисов и обрабатывает страховые премии на сумму порядка 2.3 миллиарда долларов ежегодно. В условиях, когда от аккуратности системы зависит так много долларов и людей, надежность должна предшествовать эффективности. Кроме того, … модификации программы – постоянный процесс, образ жизни. Поэтому удобство сопровождения также более важно, чем эффективность».
Майерс[28] делит множество целей на несколько групп и соотносит с главной целью – обеспечение надежности. Эти цели должны быть сформулированы явно, и разработчик обычно должен отдавать себе отчет, что не все цели могут быть в равной мере достигнуты. Поэтому, как сказано выше, приходится принимать компромиссное решение. В том смысле, как понимает цели Майерс, многие (но не все!) из них можно сформулировать в виде требований. Рассмотрим некоторые из них.
Общность – это количество и мощность функций, предоставляемых системой пользователю. Более общую систему создать сложнее, чем специализированную, поскольку всегда трудно обобщить те конкретные операции и функции, которые должна исполнять проектируемая система. Поэтому общность обычно конфликтует с надежностью. Общность системы очень редко (практически никогда) формулируется как требование.
Адаптируемость – мера простоты расширения и модификации продукта. Как это ни удивительно, но свойство адаптируемости, по мнению Майерса, хорошо согласуется с надежностью. Очевидно, что адаптируемость может часто формулироваться как одно из требований к системе (если заказчик это понимает!).
Психологические факторы -это мера легкости её понимания и освоения, удобство использования, защищенность от неправильного употребления. Совершенно очевидно, что ставя такую цель – обеспечить защищеность системы от неправильного использования – разработчик тем самым повышает надежность системы. Если удобство использования или легкость освоения трудно сформулировать в виде требования, то защищенность довольно часто является одним из требований заказчика. Такое требование обычно выдвигается заказчиками в проектах, управляемых пользователем.
Удобство сопровождения – мера затрат времени и средств на исправление ошибки в работающей системе. Эта цель тесно связана с адаптируемостью и хорошо согласуется с надежностью.
Безопасность -это мера вероятности несанкционированного доступа к данным. Понятно, что обеспечение этой цели только повышает надежность системы. Кстати, эта цель тоже часто формулируется в виде явного требования.
Эффективность. По поводу эффективности сломано немало копий. Многие авторы под эффективностью понимают скорость выполнения программы. Однако это слишком упрощенный взгляд на вещи. Тем не менее, именно скорость выполнения программы часто воспринимается программистами как абсолютная ценность.
Как следствие, средний программист часто стремится создать максимально эффективную программу в ущерб всему остальному. Однако при промышленной разработке программных продуктов эффективность в смысле скорости должна рассматриваться только как одна из целей, которые требуется достичь в процессе разработки. Крайняя эффективность в смысле скорости обычно требуется в системах реального времени. И при разработке таких систем эта цель обычно явно формулируется в виде требования обеспечить обработку данных с заданной частотой, например, раз в секунду.
В остальных случаях к эффективности необходимо относиться разумно. Приведенная выше цитата демонстрирует правильный подход к проблеме эффективности. Требования к эффективности очень редко формулируются явно, если только разрабатываемая система не является системой реального времени. С точки зрения Майерса[28], «следует считать, что всякий разработчик программного обеспечения, жертвуя надежностью ради эффективности, поступает безответственно».
Майерс в качестве целей упоминает ещё стоимость продукта, календарный план и документирование. Поскольку ГОСТ ЕСПД явно задает стандарты для этих вещей, мы не будем рассматривать их в качестве целей.
Литература
Рейнгольд Э. и др. Комбинаторные алгоритмы: теория и практика.
Ахо А., Хопкрофт Дж., Ульман Дж. Построение и анализ вычислительных алгоритмов.
Гудман С., Хидетниеми С. Введение в разработку и анализ алгоритмов.
Вирт Н. Алгоритмы + структуры данных = программы.
Гэри М., Джонсон Д. Вычислительные машины и труднорешаемые задачи.
Сибуя М., Ямамото Е. Алгоритмы обработки данных.
Aho, Alfred V. and Jeffrey D. Ullman [1983]. Data Structures and Algorithms. Addison-Wesley, Reading, Massachusetts.
Cormen, Thomas H., Charles E. Leiserson and Ronald L. Rivest [1990]. Introduction to Algorithms. McGraw-Hill, New York.
Knuth, Donald E. [1998]. The Art of Computer Programming, Volume 3, Sorting and Searching. Addison-Wesley, Reading, Massachusetts.
Pearson, Peter K. [1990]. Fast Hashing of Variable-Length Text Strings. Communications of the ACM, 33(6):677-680, June 1990.
Pugh, William [1990]. Skip Lists: A Probabilistic Alternative to Balanced Trees. Communications of the ACM, 33(6):668-676, June 1990.
| Term | Термин |
| sort by insertion | сортировка вставками |
| replacement selection | выбор с замещением |
| polyphase merge sort | многофазное слияние |
| array | массив |
| linked list | линейный список |
| comparison | сравнение |
| in-place | на месте (без дополнительных массивов) |
| stable sort | устойчивая сортировка |
| external sort | внешняя сортировка |
| underflow | вырождение |
| overflow | переполнение |
| red-black tree | красно-черное дерево |
| B-tree | Б-дерево |
| skip list | слоёный список |
| rotation | вращение |
[1] Линус. Торвальдсен. в одиночку создал ядро операционной системы Linux.
Источник: cyberpedia.su
Разработка Тех задания. Лекция 8 Разработка технического задания Программный документ Техническое задание
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 49 Kb.
Лекция 8 Разработка технического задания
Программный документ «Техническое задание» разрабатывается в соответствии с ГОСТ 19.201 — 78. Техническое задание содержит совокупность требований к программному средству и может использоваться как критерий проверки и приемки разработанной программы, поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком техническое задание является одним из основополагающих документов проекта. Умение грамотно создавать техническое задание на разработку программного продукта определяет профессиональный уровень программиста и избавляет его от претензий со стороны заказчика.
Техническое задание представляет собой документ, в котором формулируются основные цели разработки, требования к программному продукту, определяются сроки и этапы разработки и регламентируется процесс приемно-сдаточных испытаний. В формулировании технического задания участвуют представители как заказчика, так и исполнителя. В основе этого документа лежат исходные требования, заказчика, результаты выполнения предпроектных исследований и т. п.
Разработка технического задания выполняется в такой последовательности:
1) устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных;
2) определяют перечень результатов, их характеристики и способы их представления,
3) уточняют среду функционирования программного обеспечения: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать будущему программному продукту.
В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы при сбое оборудования и энергоснабжения.
Основные факторы, определяющие характеристики разрабатываемого программного обеспечения:
• исходные данные и требуемые результаты, которые определяют функции программы или системы;
• среда (программная и аппаратная), в которой разрабатываемое программное обеспечение будет функционировать, может быть задана, а может выбираться для обеспечения параметров, указанных в техническом задании;
• возможное взаимодействие с другим программным обеспечением и (или) конкретными техническими средствами также может быть определено, а может выбираться исходя из набора выполняемых функций.
В соответствии с ГОСТ 19.201 — 78 программный документ «Техническое задание» содержит следующие разделы.
1. Основание для разработки.
2. Назначение разработки.
3. Требования к программе или программному изделию.
4. Требования к программной документации.
5. Технико-экономическое обоснование.
6. Стадии и этапы разработки.
7. Порядок контроля и приемки.
Во введении указываются цель разработки программного продукта, краткая характеристика области применения и описание объекта, в котором он используется, т.е. описание предметной области.
1. В разделе «Основание для разработки» должны быть указаны:
• документы, на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.
2. Раздел «Назначение разработки» содержит определение функциональных и эксплуатационных задач, которые должна решить разрабатываемая система для достижения поставленной цели. Назначением программы может быть управление техническим комплексом, различные калькуляции, совершенствование производства и т.д. При необходимости программного обеспечения информационных систем целью разработки может быть получение своевременной и точной информации для принятия обоснованных, объективных решений, избавление пользователя от рутинного труда в делопроизводстве и перевод учреждения на безбумажную технологию и т.д. В этом же разделе должна быть представлена начальная контекстная диаграмма задачи.
3. В раздел «Требования к программе или программному изделию» входят следующие подразделы:
• требования к функциональным характеристикам;
• требования к надежности и безопасности;
• требования к составу и параметрам технических средств;
• требования к информационной и программной совместимости;
• требования к маркировке и упаковке;
• требования к хранению и транспортированию;
- формирование требуемых форм отчетности на основе отобранных данных;
- необходимые калькуляции и расчеты с использованием баз данных;
- возможность предоставления существующей базы данных другим приложениям;
- возможность работы пользователя с системой через Интернет и т.д.
При описании требований к входным данным должны быть указаны их характер, организация и предварительная подготовка, формат, описание и способ кодирования. Входной информацией программы могут быть первичные документы (накладные, отчеты и т.д ), нормативно-справочная информация (справочники, классификаторы, кодификаторы и т.д.>, электронные документы, входные сигналы и т.п. Выходной информацией программы могут быть документы (электронные или бумажные), файлы данных, выходные сигналы и т.д. При описании требований к выходным данным указывается их характер, организация, формат, описание и способ кодирования.
Помимо основных функций в техническом задании описываются требования к сервисным функциям программы, такие как возможность корректировки настроек (конфигурирования) системы, возможность резервного сохранения данных,изменения пароля входа в систему,вызова без выхода из программы календаря,калькулятора, редактора и т.д. Если разработанное программное обеспечение не будет выполнять указанных в техническом задании функций, то оно считается не соответствующим техническому заданию, т.е. неправильным с точки зрения критериев качества. Универсальность будущего продукта также обычно специально не оговаривается, но подразумевается.
Требования к надежности и безопасности содержат описание требований к обеспечению надежного и устойчивого функционирования программного продукта, к контролю входной и выходной информации, ко времени восстановления после отказа и т.п. Надежность способность программы безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно болыпой вероятностью. Надежный программный продукт не исключает наличия в нем ошибок, но -, важно, чтобы ошибки при практическом применении в заданных ,. условиях проявлялись редко. Степень надежности характеризуется вероятностью работы программного продукта без отказа в течение определенного периода времени. Существует множество подходов к обеспечению надежности системы (предупреждение ошибок, исправление ошибок, самовосстановление системы после сбоев, проверка вводимых данных в рамках допустимых значений и т.д.).
Самый простой способ — ограничение доступа. Контроль доступа к программному продукту и базе данных строится путем парольной защиты программ при их запуске, использования ключевой дискеты для запуска программ, ограничения программ или данных. функции обработки, доступных пользователям и т.д.
Требования к составу и параметрам технических средств включают указания на состав технических средств и их основные характеристики, а именно: минимальные системные требования, необходимые для работы программы; указываются мощность процессора (Гц), на базе которого должен работать ПК, объем оперативной памяти (Мб), необходимый объем свободного дискового пространства, разрешение монитора, наличие устройства чтения компакт-дисков и т. п., а также возможность переноса программы с одной аппаратной платформы на другую.
- требования к операционным системам и средам, в которых может функционировать разрабатываемый программный продукт;
- возможность адаптации программы к различным операционным системам;
- необходимость установки на компьютер пакетов программ — средств разработки приложений (для доработки, модернизации или эксплуатации данного программного продукта);
- необходимость инсталляции различных графических компонентов и т. д.
Эффективность системы определяется удобством ее использования и экономической выгодой, полученной от внедрения программно-аппаратного комплекса.
5. В разделе «Технико-экономическое обоснование» представлены ориентировочная экономическая эффективность разрабатываемого программного продукта, экономические преимущества разработки по сравнению с имеющимися на предприятии образцами или аналогами (или в сравнении с ручными операциями).
6. Стадии и этапы разработки описаны в учебном пособии А.В.Рудакова «Технология разработки программных продуктов».
7. «Порядок контроля и приемки» предполагает указание на виды испытаний и общие требования к приему работы.
В программный документ «Техническое задание» допускается включать приложения, где при необходимости приводят:
• образцы входных и выходных документов и отчетов, описания файлов данных и т.д.
• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчеты и т,д.;
• другие источники разработки.
Источник: topuch.com
2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
(Измененная редакция, Изм. № 1)
2.2. В разделе «Основания для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
(Измененная редакция, Изм. № 1)
2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
(Измененная редакция, Изм. № 1)
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
(Измененная редакция, Изм. № 1)
2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.
(Введен дополнительно, Изм. № 1).
2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.
2.8. В приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.
Источник: www.tinlib.ru