Документация как код: шесть принципов программирования, которые помогут создавать документы, понятные каждому
Авторизуйтесь
Документация как код: шесть принципов программирования, которые помогут создавать документы, понятные каждому
Рассказывает Дмитрий Толоконников, бизнес-аналитик департамента ИТ-аутсорсинга ALP Group
Больше пяти лет я занимаюсь бизнес-процессами. В особенности процессами технической поддержки, которую мы оказываем коммерческим и государственным компаниям. Например, я слежу, чтобы уровень качества IT-обслуживания соответствовал международным стандартам. Я программирую и работаю с документацией — пишу регламенты и процедуры, описываю процессы, выпускаю инструкции.
Всё это время я неосознанно «перетаскиваю» общие принципы программирования в работу с документами. Это помогает мне не делать бесполезные «спагетти-простыни» и писать внятные рабочие документы с ясной структурой, даже если документация очень объёмная и должна часто меняться в соответствии с изменениями в компании и все её части должны быть связаны воедино, чётко объяснять, как что-то работает. Возможно, мои приёмы помогут и вам.
Принципы работы с текстом
DRY — Don’t repeat yourself. Не повторяйся
Если вы вставили один и тот же блок в 10 разных регламентов и что-то меняете в нём, то у вас образуется 10 одинаковых мест, куда нужно внести одинаковые изменения. Вероятность забыть об этом тоже растёт, даже если вы пользуетесь бессмертным «Ctrl+C» — «Ctrl+V». Особенно в последней паре документов.
В программировании такие блоки выделяют в отдельные функции, классы, а в работе с документами повторяющиеся элементы нужно выносить в отдельные разделы или документы и давать ссылки на них.
KISS — Keep it simple, stupid. Не усложняй
Посмотрите вокруг: люди привыкли к простоте. Интуитивно понятные интерфейсы и всплывающие подсказки в приложениях. Принцип одного окна в IT-обслуживании. Засилье коротких статей и обучающих видео в Интернете. Той же простоты они ждут и от рабочих документов.
4 декабря, Онлайн, Беcплатно
Этот принцип я обычно использую как маркер. Если описание процесса слишком сложное — нужно упростить процесс. Если инструкция к приложению слишком замысловатая — надо доработать приложение.
Обычно это проще и дешевле, чем писать сложную документацию, заставлять каждого нового сотрудника её читать, понимать и учиться действовать по ней. А ведь потом ещё нужно будет вносить изменения в документацию.
YAGNI — You ain’t gonna need it. Тебе это не понадобится
Это продолжение принципа KISS. Обычно я применяю его, когда собираюсь создать универсальное решение с заделом на будущее. Проблема в том, что такое решение — само по себе усложнение. Не факт, что в будущем оно понадобится. Обычно нет смысла создавать всеобъемлющее описание бизнес-процессов направления, которое только сформировалось и активно развивается. Практика показывает, что будущее внесёт серьёзные коррективы.
Но здесь важно разумно подходить к вопросу. Есть вещи, изменение которых дорого обходится. Их как раз нужно готовить с заделом на будущее. В программировании эту работу относят к архитектуре приложения, а в документации просто сразу говорят: «Это нам не понадобится». И в будущем с трудом навёрстывают упущенное.
Принципы работы со структурой
Чем объёмнее становится документация, тем сложнее поддерживать её актуальность. Изменение одного документа влечёт за собой каскадное изменение остальных, логическая целостность ломается, структура требует очередной переработки. К счастью, для программирования это стандартная проблема, и за прошедшие десятилетия выработались общие принципы написания легко поддерживаемого кода. Часть из них можно применять и к документам.
SRP — Single Responsibility Principle. Принцип единственной ответственности
Яркий маркер нарушения принципа — наличие побочных действий. Например, метод класса отвечает за отправку клиенту уведомления о новом заказе в интернет-магазине, но при этом ещё и обновляет текущий баланс клиента.
То же самое справедливо и для документации. Например, в регламент регистрации обращения клиента не нужно впихивать что-то «заодно»: принципы вежливого общения с клиентами, краткое описание self-service портала и т. д.
Нельзя рассчитывать, что такая информация будет усвоена или сотрудники запомнят, к какому документу нужно обращаться, чтобы её получить. Зато это запутывает документ, лишает структуру чёткости и требует дополнительного времени для актуализации. Если вы действительно хотите напомнить о вежливости при общении с клиентом, вставьте в регламент ссылку на соответствующий документ (вспомните о DRY).
Соблюдение принципа позволяет делать документы короче. Их название соответствует назначению, а чтение не вызывает неприятных сюрпризов. Их проще прочитать за раз. И не забыть, с чего документ начинался.
SLAP — Single Level of Abstraction Principle. Принцип единого уровня абстракции
Является логичным продолжением принципа единственной ответственности (SRP).
Применение принципов KISS и SRP побуждает писать небольшие, простые и понятные документы. Но эти документы нужно собрать в такую же простую и понятную структуру. Здесь помогает выделение и соблюдение уровней абстракций.
Например, очевидно, что нет смысла пытаться поместить в один огромный документ объёмную документацию вроде описания системы менеджмента качества. Намного логичнее разбить его на уровни абстракций и сделать для каждого уровня разные документы — верхнеуровневое описание системы, описание каждого процесса и т. д.
При этом важно соблюдать принцип единого уровня абстракций и относить информацию только к нужному уровню. Если вы пишете верхнеуровневое описание, не надо вдаваться в детали работы конкретного процесса. Не тот уровень абстракции! Оставьте эту информацию для описания процесса. Этот принцип дополняет SRP, заставляя автора контролировать не только то, за что отвечает документ, но и на каком уровне в иерархии он находится.
LoD — Law of Demeter (Don’t talk to strangers). Закон Деметры (Не разговаривай с незнакомцами)
Если применить закон к документации, то каждый документ:
Например, процесс управления IT-инцидентами взаимодействует с процессом управления проблемами напрямую, а с процессом управления изменениями — только через управление проблемами. Тогда в описании управления инцидентами можно ссылаться на описание управления проблемами. А вот ссылаться на описание управления изменениями не надо.
Итого
Указанные выше принципы сильно помогают мне при написании документации по процессам, в создании регламентов, процедур и инструкций. К сожалению, это лишь небольшая часть рекомендаций по управлению качеством кода, поэтому заинтересовавшимся рекомендую самостоятельно углубиться в тему. Из неё можно извлечь много полезного. При этом важно помнить, что эти принципы не являются законами. В Интернете много спорят об их правильном использовании и часто злоупотребляют ими. Поэтому, пожалуйста, не впадайте в крайности. И не забывайте о здравом смысле.
СОДЕРЖАНИЕ
Документация по требованиям
Необходимость в документации требований обычно связана со сложностью продукта, воздействием продукта и ожидаемым сроком службы программного обеспечения. Если программное обеспечение очень сложное или разработано многими людьми (например, программное обеспечение для мобильных телефонов), требования могут помочь лучше понять, чего следует достичь. Если программное обеспечение критично для безопасности и может оказать негативное влияние на жизнь человека (например, ядерные энергетические системы, медицинское оборудование, механическое оборудование), часто требуется более формальная документация требований. Если ожидается, что программное обеспечение будет работать всего месяц или два (например, очень маленькие приложения для мобильных телефонов, разработанные специально для определенной кампании), может потребоваться очень небольшая документация по требованиям. Если программное обеспечение является первым выпуском, который позже создается, документация по требованиям очень полезна при управлении изменениями программного обеспечения и проверке того, что при изменении программного обеспечения ничего не было нарушено.
Архитектурно-конструкторская документация
Очень важно включить всю информацию, которая будет использоваться всеми актерами в сцене. Также очень важно обновлять документы, так как любые изменения происходят и в базе данных.
Техническая документация
Техническая документация, встроенная в исходный код
Идея автогенерации документации привлекательна для программистов по разным причинам. Например, поскольку он извлекается из самого исходного кода (например, через комментарии ), программист может писать его, ссылаясь на код, и использовать те же инструменты, которые использовались для создания исходного кода для создания документации. Это значительно упрощает поддержание документации в актуальном состоянии.
Конечно, недостатком является то, что только программисты могут редактировать такую документацию, и от них зависит обновление вывода (например, путем запуска задания cron для обновления документов каждую ночь). Некоторые охарактеризовали бы это как за, а не как против.
Грамотное программирование
Разъяснительное программирование
Часто разработчикам программного обеспечения необходимо иметь возможность создавать и получать доступ к информации, которая не будет частью самого исходного файла. Такие аннотации обычно являются частью нескольких действий по разработке программного обеспечения, таких как обход кода и перенос, где сторонний исходный код анализируется функциональным образом. Таким образом, аннотации могут помочь разработчику на любом этапе разработки программного обеспечения, когда формальная система документации будет препятствовать прогрессу.
Документация пользователя
В отличие от кодовых документов, пользовательские документы просто описывают, как используется программа.
В случае программной библиотеки документы кода и пользовательские документы в некоторых случаях могут быть фактически эквивалентными и заслуживающими объединения, но для общего приложения это не всегда верно.
Пользовательская документация может быть представлена в различных онлайн-и печатных форматах. Однако существует три основных способа организации пользовательской документации.
Составление пользовательской документации
Как и другие формы технической документации, хорошая пользовательская документация выигрывает от организованного процесса разработки. В случае с пользовательской документацией процесс, как это обычно происходит в промышленности, состоит из пяти этапов:
Документация и полемика по гибкой разработке
«Сопротивление документации среди разработчиков хорошо известно и не требует особого внимания». Эта ситуация особенно распространена при гибкой разработке программного обеспечения, потому что эти методологии пытаются избежать любых ненужных действий, которые напрямую не приносят пользы. В частности, Agile Manifesto рекомендует ставить «работающее программное обеспечение выше исчерпывающей документации», что можно цинично интерпретировать как «Мы хотим тратить все свое время на кодирование. Помните, настоящие программисты не пишут документацию».
Однако опрос экспертов по программной инженерии показал, что документация ни в коем случае не считается ненужной для гибкой разработки. Тем не менее, признается, что в разработке есть проблемы с мотивацией, и что могут потребоваться методы документации, адаптированные для гибкой разработки (например, с помощью систем репутации и геймификации ).
Маркетинговая документация
Для многих приложений необходимо иметь рекламные материалы, чтобы побудить случайных наблюдателей уделять больше времени изучению продукта. Эта форма документации преследует три цели:
Программная документация и ее разновидности
Ниже мы рассмотрим понятие программной документации и ее разновидности.
Под программной документацией понимают различные виды документов в печатном и электронном виде, содержащих информацию о разработке, изготовлении, испытаниях, эксплуатации и сопровождении программных изделий.
В России разработку программной документации принято проводить в соответствии с требованиями ЕСПД – единой системы программной документации.
С точки зрения ЕСПД программы разделают на следующие виды (ГОСТ 19.101):
Компонент – программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса
Комплекс – программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса
Также в ГОСТ 19.101 упоминается и такое важное понятие как «программное изделие», в п. 1.3 данного стандарта указано следующее: «документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия». А в соответствии с ГОСТ 19.004 программное изделие – это «Программа на носителе данных, являющаяся продуктом промышленного производства».
Отдельно необходимо сказать несколько слов о разработке технических условий на программу (а если точнее на программное изделие, этот термин мы поясняли немного выше). В том же ГОСТ 19-101 достаточно немного про них написано, а именно «2.7. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы. Технические условия разрабатывают на стадии «Рабочий проект».
Т.е. получается, что если в техническом задании нет требований по разработке ТУ на программу, то вроде бы можно и не разрабатывать. Однако довольно часто этот документ все же разрабатывают т.к. он достаточно полезен при изготовлении, контроле, приемке, а также и при сертификации программных изделий, особенно актуальна разработка технических условий на программу при работах в интересах государственного Заказчика (МО РФ и др.). Необходимо упомянуть и следующую особенность – в системе ЕСПД не существует стандарта, предъявляющего требования к разделам и содержанию ТУ на программное изделие. Обычно при разработке ТУ руководствуются требованиями «конструкторского» ГОСТ 2.114, применяя его основные требования, оформление же делают в соответствии с ГОСТ 19-106 (т.е. без рамки как в КД).
Также необходимо упомянуть о том, что в зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102), предназначенные для разработки, сопровождения и эксплуатации программы.
Документация на программное обеспечение
Содержание
Типы документации
Существует четыре основных типа документации на ПО:
Архитектурная/проектная документация
Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос «почему именно так?» Например, в проектном документе программист может описать обоснование того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи как можно будет выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или пользовательскую документацию, но всё это действительно важно для проекта.
Техническая документация
При создании программы, одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый текст, описывающий различные аспекты того, что именно делает код. Такая документация часто включается непосредственно в исходный код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технический характер и в основном используется для определения и описания API, структур данных и алгоритмов.
Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML.
Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.
Пользовательская документация
В отличие от технической документации, сфокусированной на коде и том, как он работает, пользовательская документация описывает лишь то, как использовать программу.
В случае если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.
Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.
Существует три подхода к организации пользовательской документации. Вводное руководство (англ. tutorial ), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач. Тематический подход, при котором каждая глава руководства посвящена какой-то отдельной теме, больше подходит для совершенствующихся пользователей. В последнем, третьем подходе, команды или задачи организованы в виде алфавитного справочника — часто это хорошо воспринимается продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы пользователей обычно относятся к тому, что документация охватывает только один из этих подходов, и поэтому хорошо подходит лишь для одного класса пользователей.
Во многих случаях разработчики программного продукта ограничивают набор пользовательской документации лишь встроенной системой помощи (англ. online help ), содержащей справочную информацию о командах или пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей, часто оказывающих значительную помощь разработчикам.
Маркетинговая документация
Для многих приложений необходимо располагать рядом рекламные материалы, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая форма документации имеет целью:
Одна из хороших маркетинговых практик — предоставление слогана — простой запоминающейся фразы, иллюстрирующей то, что мы хотим донести до пользователя, а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы дают более ясную картину о возможностях и способах использования программы, чем всё остальное.
Примечания
См. также
Ссылки
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Полезное
Смотреть что такое «Документация на программное обеспечение» в других словарях:
Программное обеспечение — Запрос «Software» перенаправляется сюда; см. также другие значения … Википедия
программное обеспечение — 01.01.80 программное обеспечение (в области электросвязи) [software ]: Программы ЭВМ, процедуры, правила и любая сопутствующая документация, имеющие отношение к работе аппаратуры, сети электросвязи или другого… … Словарь-справочник терминов нормативно-технической документации
программное обеспечение (ПО) — 3.34 программное обеспечение (ПО) (software): Программы (т.е. набор упорядоченных команд), данные, правила и любая связанная с этим документация, имеющая отношение к работе компьютеризированной системы контроля и управления. [МЭК 62138, пункт… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р МЭК 60880-2010: Атомные электростанции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А — Терминология ГОСТ Р МЭК 60880 2010: Атомные электростанции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А оригинал документа: 3.25 N версионное программное… … Словарь-справочник терминов нормативно-технической документации
Документация — Документация это совокупность данных и документов. В узко профессиональном значении Документация (документирование) процесс отбора, классификации, использования и распространения документов. Работа специалиста по подбору документации… … Википедия
ПРОГРАММНОЕ СРЕДСТВО — 6. ПРОГРАММНОЕ СРЕДСТВО по ГОСТ 28806 90. Источник: РБ 004 98: Требования к сертификации управляющих систем, важных для безопасности атомных станций … Словарь-справочник терминов нормативно-технической документации
обеспечение — Процесс скоординированного управления по обеспечению всех материалов и ресурсов, требуемых для эксплуатации изделия. Источник: ГОСТ Р 53480 2009: Надежность в технике. Термины и определения оригинал документа … Словарь-справочник терминов нормативно-технической документации
Стадия «Рабочая документация» — 2.6. Стадия «Рабочая документация» 2.6.1. Задачей стадии является разработка технической рабочей документации, обеспечивающей выполнение работ по вводу АС в действие. На данном этапе должны быть также все документы, необходимые при эксплуатации… … Словарь-справочник терминов нормативно-технической документации
Canon EOS 30D — Тип цифровой зеркальный фотоаппарат Матрица КМОП 22,5 × 15,0 мм (Kf = 1,6) … Википедия
Canon EOS 600D — Canon EOS Digital Rebel T3i Canon EOS Kiss X5 Тип DSLR … Википедия
Разработка технической документации для программного обеспечения
 |
 |
|
Документация для программного обеспечения – это справочный текст и визуальная информация, описывающие и отображающие процесс разработки, производства, эксплуатации и сопровождения программного продукта, его потребительские свойства и технические характеристики.
Виды документации для программного обеспечения
В соответствии с таким определением, техническая документация по ПО состоит из четырёх основных типов:
• Проектная – включает описание основных положений, используемых при создании ПО и рабочей среды.
• Техническая – алгоритмы, код, интерфейсы, АРI.
• Пользовательская – руководства для пользователей программы.
• Маркетинговая – содержащая рекламную информацию о продукте.
Проектная документация, как правило, программный продукт описывает в общих чертах. Например, программист в проекте может обосновать, почему структуры данных именно таким (а не иным) образом организованы. Почему именно таким образом сконструирован тот или иной класс. В проекте выделяются паттерны. Часто даются указания, как выполнять модернизацию программы.
Техническая документация (все указанные виды которой можно заказать в компании «ТехРайтКонсалт»). не только указывает конкретные коды. Она, как правило, также описывает различные аспекты того, что этот код делает. Она имеет явно выраженный технический характер и используется в основном для описания и определения API, алгоритмов и структур данных. При её составлении возможно использование генераторов документации (Doxygen, NDoc, javadoc и др.), что даёт возможность постоянно поддерживать такую документацию в актуальном состоянии. В последнем случае техническая документация является частью исходного кода. Тогда одни и те же инструменты можно использовать как для сборки программы, так и для сборки в то же время документации к ней.
Хорошая пользовательская документация состоит из:
• вводного руководства, где рассматриваются общие вопросы выполнения типичных задач;
• тематического, где каждая глава посвящена разъяснению какого-либо раздела эксплуатации программы;
• алфавитного справочника, для опытных пользователей, хорошо знающих, что нужно искать.
Маркетинговая документация используется для рекламы как самого программного продукта и его составляющих, так и других программных продуктов компании. Она часто информирует покупателя о свойствах продукта, объясняет его преимущества перед конкурирующими решениями. Часто бывает так, что именно коробка продукта и другая маркетинговая информация дают самое чёткое и простое представление о способах использования и возможностях программы.
Стандарты для разработки ПО
Основой для создания любой документации на программные продукты служат стандарты.
Современных стандартов по разработке технической документации для программного обеспечения в Российской Федерации до сих пор нету ещё со времён СССР. Хотя стандарты и модернизируются. Последнее обновление ГОСТ 2.015-2013.
В таких условиях IT-компании вопрос разработки документации для программного обеспечения решают по-разному. Одни пытаются копировать и внедрять западные стандарты. Другие – использовать отечественные. Третьи – создают свои собственные.
Актуальные вопросы при разработке документации ПО
В любом случае актуальными при разработке технической документации для программного обеспечения будут такие основные вопросы:
• Какова нормативная база и как её следует применять?
• Какая именно документация нужна среди огромного количества документов?
Остановимся на этих вопросах подробнее.
В настоящее время действуют следующие стандарты документирования:
ГОСТ 19.201 ( Единая система программной документации (ЕСПД);
ГОСТ 2.015-2013 (Единая система конструкторской документации (ЕСКД);
ГОСТ 34.602 (Комплекс стандартов на автоматизированные системы (КСАС).
Указанные стандарты с 2006 года применять не обязательно. В соответствии с нормами Федерального закона № 184-ФЗ «О техническом регулировании» вместо стандартов применяются специально разработанные технические регламенты. Но ГОСТы по-прежнему нужно применять при разработке документации для государственных заказчиков, а также для крупных организаций (особенно с государственным участием). Последние, как правило, разрабатывают собственные стандарты на основе указанных ГОСТов.
Следует также помнить, что в соответствии с ФЗ «О техническом регулировании» национальные стандарты имеют всегда приоритет над международными. То есть, использовать международные стандарты можно лишь в случаях, если последние не противоречат национальным! Благо, свободы действий отечественные стандарты предоставляют намного больше зарубежных. Последние пересматриваются каждые 5-7 лет и характеризуются большей конкретизацией, но отображают весь актуальный опыт за указанный период времени. Отечественные же (не имея столь разработанной конкретики) характеризуются глубокой разработкой концептуальных моментов. Это позволяет создавать на их основе неплохие стандарты в соответствии с требованиями времени.
Техническое задание
Основным документом на создание программного продукта является технические задание, которое используется для разработки (проектирования) программы и её испытания.
В ТЗ устанавливается назначение программного продукта, что разрабатывается, его технические характеристики, качество и технико-экономические показатели, а также указания по выполнению стадий документации (конструкторской, программной, технологической и т.п.), её состав и другие специальные требования.
Техническое задание – это юридический документ, который в качестве приложения включается в договор на выполнение проектных работ по созданию программы и является основой такого договора.
ТЗ может быть выполнено как в качестве эскизного проекта (описываются структура системы и её функции без технологий реализации решения); так и в форме технического проекта (детальное описание выбранной технологии реализации проекта). ТЗ может составляться также в общих чертах (для инвесторов, к примеру) и с самой подробной детализацией (для программистов и в иных случаях).
Часто ТЗ является единственным документом для описания разрабатываемого программного продукта. В таких случаях особо важно, чтобы оно разрабатывалось и изготовлялось профессионалами.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 |
 |
 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
Современная техника для древоводства в работе
