Документирование

Содержание

Порядок и способы документирование информации | Защита информации

Документирование

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

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

Идентификация не лицензионными средствами электронно цифровой подписи создает проблемы защиты информации в сетях и угрозы информационной безопасности.

Информационные ресурсы могут быть государственными или негосударственными. Информационные процессы — это средства сбора, накопления, обработки, хранения распространения и поиска информации.

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

Все аспекты должны быть описаны в политике безопасности предприятия.

Юридические и физические лица есть собственниками тех документов, которые реализованы на их средства, получены по методу подарка или наследства.

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

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

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

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

Все аспекты использование должны быть прописаны в договорах или в соответствующих законах.

Способы документирования

Метод документирования — метод организации информации на определенном носителе, который разрешает со временем считать информацию.

Техническое документирование — еще называют запечатлением технической мысли.

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

Такие документы ведут записи процессов труда (чертежи, графики, расчеты и тд). Такая документация связанная также с картографией, геодезией, гидрометеослужбой.

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

Фотодокумент — вид документа, реализованный фотографическим методом. Особенность такого документа, они записывают момент события и имеют высокую точность. С помощью микрофотокопирования реализуют копии документов.

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

Фонодокумент — документ, который имеет звуковые данные, зафиксированные на протяжении некоторого времени.

Электронное документирование — на специальных материальных носителях, информация записывается специальным обозначениями, и такую форму чтения разбирают только машины. На сегодня материалами для документирования могут быть: бумага, диски, пленки, магнитные и электрические носители.

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

Порядок документирования

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

Документирование информации — это обязательная процедура включения информации в государственные информационные ресурсы. Физические и юридические лица обязаны в определенном порядке предоставить документированную информацию в определенные гос. органы для создания государственных информационных ресурсов.

Владельцы и собственники информационных ресурсам в пределах своих правовых рамках должны принимать нужные меры для защиты документированной информации.

Документированная информация с ограниченным доступом

Делится на информацию государственной тайны и конфиденциальной информации. Запрещено относить информацию с ограниченным доступом:

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

Источник: http://infoprotect.net/varia/dokumentirovanie_informacii

Документирование — отдельная статья доходов проекта

Документирование

В последние годы мне довелось поработать в нескольких довольно разных ИТ-компаниях, связанных с разработкой или интеграцией различных решений от госов до коммерции. Поучаствовал в и прокурировал немалое количество проектов. Но практически везде слабое место одно и то же – документирование разрабатываемых решений.

Оно суть головная боль и корм для корпоративной жабы компании-разработчика. С точки зрения «типового интегратора», это некий побочный процесс, результаты которого в основном нужны для закрытия официальных требований контрактов.

Не будь требований – сколько можно было бы высвободить ресурсов! Да еще и не отвлекать от работы истинных кормильцев компании: продавцов, менеджеров и в некоторой степени программистов. Картина комплектование и организации работы «мощностей» по разработке документации – отдельная грустная песня, не для этой статьи.

Есть ситуации, когда часть разработанной по контрактам документации полезна внутри компании. Я такое видел. Есть ситуации, когда проекты закрывались исключительно благодаря документации. И такое видел. Но в общей массе это всего лишь исключения. Мне, положа руку на сердце, такое положение вещей не нравится.

Я, периодически разрабатывая документацию, не согласен быть растратчиком корпоративных ресурсов. И я имею кое-что сказать по этому поводу.

Уважаемые сейлы, менеджеры продуктов и проектов – давайте активнее продвигать документацию. Давайте на ней зарабатывать!

Зачем заказчику документация?

Глобальный вопрос – зачем вообще заказчику нужна документация на конкретное решение? Не та «для галочки», которую с них спросит вышестоящее руководство, или которую требует нормативное регулирование отрасли. С ней все понятно, она просто нужна. Речь про документацию, которая реально применяется в дальнейшем и имеет прикладную ценность.

Универсального ответа на этот вопрос нет. В зависимости от обстоятельств, честный ответ будет варьироваться от «…й не нужна!» до «а как без нее?». Однако есть определенная зависимость. Чем продолжительнее предполагаемый период жизни и развития решения, тем важнее в нем роль документации.

Потому, что тем дольше понадобится:

Заказчику:

  • Адаптировать решение к изменяющимся реалиям в части функционала и покрытия задач. Причем быстро.
  • Расширять область автоматизации, в том числе, за счет интеграции с другими системами.
  • Учить сменяющийся (иногда – часто и много) персонал.
  • Актуализировать свою собственную нормативную базу, связанную с применением решения (регламенты, положения об отделах, технологические инструкции, должностные инструкции).
  • Вести учет, планирование и оптимизацию затрат на решение. Как минимум, чтобы знать, за что в нем уже оплачено и не попадаться ревизорам на повторной оплате того же самого с вытекающими обвинениями в двойном финансировании или отмывании.
  • Обеспечивать необходимый уровень безопасности предприятия – в том числе, посредством исключения зависимости от единственного поставщика/разработчика критично важного решения.

Исполнителю:

  • Передавать компетенции по разработке решения (за 2 года сменится половина команды «в теме», дальше – больше).
  • Передавать компетенции по обеспечению качества и сопровождению решения – тестировщики и персонал поддержки меняются еще быстрее.
  • Актуализировать информационное обеспечение для менеджера продукта.

Если заказчик не справится, его ждут весьма ощутимые финансовые и временнЫе потери с перспективой разбираться, разрабатывать и внедрять решение заново. Если не справится исполнитель, то он просто перестанет быть исполнителем. Сразу или спустя некоторое время. Выходит, что грамотный комплект документации (именно грамотный, а не большой) способен заметно продлить срок службы решения. Другой довольно весомый аргумент, связанный со сроком службы решения – его стоимость в расчете за определенный период времени. Учитывая, что стоимость решения для заказчика «в год» составляет сумму всех расходов, деленную на количество лет, его штатная жаба должна быть кровно заинтересована, чтобы знаменатель в этой формуле был как можно больше. Одно дело, если система за 6 млн. проработает 2 года, и совсем другое, если хотя бы 3. Это целый миллион экономии каждый год. Конечно, разработчики могут возразить «Ну и что? Мы просто наваяем через два года год еще одно решение за такие же деньги. Нам же лучше!». Но, во-первых, это не спортивно. А во-вторых, срабатывает ограниченное количество раз, после чего найти заказчика становится сложнее. В завершение разговора про значимость срока службы приведу следующую мысль-наблюдение. Вдруг пригодится как аргумент познания ценности в сравнении. В системе, эксплуатируемой 6-8 лет, программный код переживает несколько рефакторингов и раз-другой переписывается с нуля (причем нередко другим исполнителем и на других технологиях). А вот документы, описывающие потребности заказчика и основные способы их удовлетворения, разве что пару раз актуализируют. Слегка.

Что предложить Заказчику?

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

В большинстве случаев, включая проекты для коммерческих структур, при определении номенклатуры и содержания документации можно отталкиваться от связки ГОСТ 34.201-89 и РД 50-34.698-90.

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

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

1. Предпроектная. В нее войдут документы, которые предшествуют проектированию решения. В том числе:

  • отчеты об обследовании;
  • концепции;
  • технико-экономические обоснования;
  • технические задания и т.п.

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

2. Проектная. Все, что относится к проектируемому (но пока еще не реализованному) решению. Проектных документов может быть довольно много (см. например, тот же ГОСТ 34.201-89) и от проекта к проекту акценты полезности и привлекательности тех или иных документов для потенциального заказчика могут смещаться, однако наиболее востребованными обычно являются документы, содержащие описание:

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

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

3. Рабочая. Сюда относим сведения о том, как спроектированное решение должно быть размещено/настроено/снабжено первоначальной информацией во вполне конкретных условиях работы. В том числе:

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

Бесценно, если заказчик планирует эксплуатировать и сопровождать решение своими силами (как минимум, частично). 4. Эксплуатационная. Все, что объясняет, как работать с решением. В первую очередь, это различные руководства, инструкции и технические регламенты. В отличие от проектной и рабочей, в полезности эксплуатационной документации заказчика убеждать приходится редко. За исключением случаев, когда заказчик получил глубокую эмоциональную и душевную травму от предыдущего употребления результатов работы горе-писателей. 5. Административно-регулирующая. Если решение предполагает вмешательство в оргструктуру заказчика (от изменения отдельных функций и переподчинения отдельных сотрудников, до изменений на уровне иерархии организации), то такие события в солидных конторах сопровождаются документально. И редко когда Заказчик горит желанием выполнить эту работу сам. Это веский повод предложить облегчить его и без того тяжкую ношу (и бюджет, разумеется). К документации этой категории можно отнести:

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

6. Обучающая. Я умышленно отделяю ее от эксплуатационной. Сюда предлагаю относить материалы, организованно подготавливающие персонал заказчика к выполнению своих задач при помощи нашего решения. Особо важное значение эти материалы имеют в условиях высокой текучести персонала (колл-центры, кассы розницы и т.п.). К обучающим можно отнести:

  • программы обучения и контроля полученных «студентами» знаний;
  • методические материалы;
  • учебные курсы (в т.ч. аудио-видео).

7. «Разное». В зависимости от ситуации, может возникнуть потребность (или желание) разработать документы, которые сложно однозначно отнести к какой-либо из перечисленных выше категорий. Например, протоколы информационного взаимодействия между заказчиком и сторонней организацией обычно имеют признаки одновременно административной, проектной и рабочей документации. Особо хочу остановиться на двух документах. «Вырвать» их из контекста. Это:

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

Вот эти документы, по моему скромному мнению, нужно иметь в любом проекте в бумажном виде со всеми согласующими и утверждающими подписями.

Как предложить Заказчику?

На эту тему написано очень много и гораздо лучше, чем могу написать я.

Мой скромный опыт лишь подсказывает, что при наличии более-менее грамотного специалиста по документированию, ничто не мешает:

  1. Подготовить максимальную, оптимальную и минимальную комплектацию пакета документов, которую можно обоснованно предложить Заказчику в конкретной ситуации.

  2. Грамотно и системно обосновать достоинства каждого из предлагаемых пакетов и каждого из входящих в него документов. Составить сравнительную таблицу.
  3. Культурно оформить все это в разделе технико-коммерческого предложения.

Вместо заключения..

… поделюсь историей про номенклатуру документации и потребности заказчика. Как-то довелось участвовать в разработке серьезного решения для весьма серьезного заказчика. Когда увидел требования, немного удивился: в них была прописана разработка порядка 35+ документов технорабочего проекта.

То есть, практически весь 34-й ГОСТ. На осторожный вопрос «Зачем вам все это богатство?» заказчик ответил примерно так: «Конкурирующий отдел из соседнего Управления только что принял систему, которую укомплектовали 20-ю документами. Мы не можем допустить, чтобы в глазах генерала наша разработка выглядела менее солидно!».

А вы говорите – «не продается!»

  • документация
  • документирование
  • управление проектами
  • продажи

Источник: https://habr.com/post/221249/

12) Документирование — Технологии программирования

Документирование

Любой проект должен сопровождаться хоть какой-то документацией (прим. редактора = например readme файл с иноформацией о том как именно использовать «таблетку» — это,так сказать , минимальная документация)

Цели документирования

Документация, создаваемая при разработке программных средств необходима для =

  1. передачи информации между разработчиками ПС,
  2. управления разработкой ПС,
  3. передачи пользователям информации, необходимой для применения и сопровождения ПС

Классы документов

Эту документацию можно разбить на две группы: =

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

А именно =

ДОКУМЕНТАЦИЯ ПРОЕКТА =

  1. Описание проекта
  2. Планы
  3. Задания исполнителям (задание распределённое между конкретными людьми или группами, участвующими в реализации проекта)
  4. отчёт о ходе работ — создаются менеджерами для контролирующих органов
  5. Протоколы встреч и обсуждений
  6. Отчёты о результатах активности
  7. Журналы

ДОКУМЕНТАЦИЯ ПРОДУКТА =

  1. Технические требования
  2. Технические спецификации
  3. Сведения о выпуске (Release notes)
  4. Руководства (напр — по эксплуатации и настройки)

——————————————

Документирование процесса разработки (process documentation)

Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС
Они обеспечивают связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами, управляющими разработкой

———————

Типы документов управления

  1. Планы, оценки, расписания — Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения
  2. Отчеты об использовании ресурсов в процессе разработки — Также создаются менеджерами для контролирующих органов

Стандарты

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

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

Рабочие документы

Рабочие документы — это основные технические документы, обеспечивающие связь между разработчиками — актуальны в определённое время в рамках процесса разработки

Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС

Заметки и переписка

Заметки и переписка — Эти документы фиксируют различные детали взаимодействия между менеджерами («самой компании-разработчика» — со слов преподавателя) и разработчиками

—————————

Product documentation (ДОКУМЕНТАЦИЯ ПРОДУКТА)

Документы, входящие в состав ПС (product documentation), описывают ПС =

  1. с точки зрения его применения пользователями,
  2. с точки зрения его разработчиков и сопроводителей (в соответствии с назначением ПС)

Эти документы используются не только на стадии эксплуатации ПС, но и на стадии разработки для управления процессом его разработки

Типы документов продукта

Эти документы образуют два комплекта с разным назначением:

  1. пользовательская документация ПС (П-документация),
  2. документация по сопровождению ПС (С-документация)

Теперь подробнее =

Пользовательская документация


Пользовательская документация ПС
(user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС
К этому типу документации относятся документы, которыми руководствуется пользователь при:

  1. при инсталляции ПС,
  2. при применении ПС для решения своих задач,
  3. при управлении ПС (например, когда данное ПС взаимодействует с другими системами)

.

Категории пользователей

Следует различать две категории пользователей ПС:

  1. ординарных пользователей ПС (те , кто используют ПС для решения своих прикладных задач)
  2. и администраторов ПС

Ординарный пользователь ПС (end-user) использует ПС для решения задач в своей предметной области и может не знать многих деталей работы компьютера или принципов программирования

Администратор ПС
(system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ

Например, Администратор ПС может =

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

——————-

Состав документации

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

———————-

Режим использования документа

Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ

Обычно пользователю достаточно больших программных систем требуются =

  • либо документы для изучения ПС (использование в виде инструкции),
  • либо для уточнения некоторой информации (использование в виде справочника)

Состав пользовательской документации =

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

  2. Руководство по инсталляции ПС, предназначенное для системных администраторов. Оно должно детально описывать действия по установке системы и определять требования к конфигурации аппаратуры.
  3. Инструкция по применению ПС.

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

  4. Справочник по применению ПС.

    Предназначен для ординарных пользователей и содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска — (например в виде файла windows-спрпавки)

  5. Руководство по управлению ПС.

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

————-

Разработка пользовательской документации

Разработка пользовательской документации начинается сразу после создания внешнего описания и ее качество может существенно определять успех ПС.

Она должна быть достаточно проста и удобна для пользователя, поэтому к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели

Уже с начала выполнения целей проекта надо определиться с форматом документации ,с тем чтобы он соответствовал конечному варианту.

Не всегда получается изложить мысли разработчика в форме понятной для пользователя — но надо стараться или же привлекать так называемых «технических писателей»

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

  1. предписывается порядок разработки этой документации,
  2. формулируются требования к каждому виду пользовательских документов,
  3. определяются их структура и содержание

——————————-

Документация сопровождения

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки

Эта документация необходима, если предполагается изучение устройства ПС и модернизация его программ

То есть тексты пишутся для разработчиков , подобных исполнителям (исполнители — это те, кто изначально создали ПС)

В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей.

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

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

Документация по сопровождению ПС можно разбить на две группы: =

1) Документация, определяющая строение программ и структур данных ПС и технологию их разработки =содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы:

  1. внешнее описание ПС (Requirements document — то есть описание , с точки зрения зависимости от параметров среды , в которой будут выполняться коды ПС — например — зависимость от операционной системы);
  2. описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы;
  3. для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

И ещё =

  1. для каждого модуля — его спецификация и описание его строения (design description);
  2. тексты модулей на выбранном языке программирования (program source code listings);
  3. документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС

Документы установления достоверности ПС включают прежде всего документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ — то есть теоретическое обоснование «правильности».

2) Документацию, помогающую вносить изменения в ПС = содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает:

  1. известные проблемы, связанные с ПС,
  2. какие части системы являются аппаратно- и программно-зависимыми,
  3. возможности дальнейшего развития ПС

Общая проблема сопровождения ПС заключается в обеспечении согласованности всех его представлений при внесении в него любых изменений

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

———————————-

Автоматизация документирования

Ввиду ограниченности сроков изготовления программных продуктов, они обычно плохо документируются

Решению этой проблемы может помочь автоматизация этого вида деятельности
Для автоматического формирования документации к программному проекту используются специальные CASE-средства, называемые генераторами документации

Генератор документации

Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям, полученным на выходе компилятора

Принципы работы генератора документации

Генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам, процедурам/функциям и т. п.)

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

На основе всей собранной информации формируется готовая документация в одном из общепринятых форматов.

Источник: http://fkn.ktu10.com/?q=node/454

Поделиться:
Нет комментариев

Добавить комментарий

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.

×
Рекомендуем посмотреть