Что такое программа как вид документа

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

· что должно быть сделано, кроме собственно программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям, а что службе сопровождения?

· как управлять всем этим процессом?

· что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

На эти и массу других вопросов когда-то отвечали государственные стандарты на программную документацию комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как, казалось — неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных.

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

8. Виды конструкторских документов

Обзор отечественных стандартов по составлению документации на ПО

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ 34, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ «О стандартизации» эти стандарты становятся обязательными на контрактной основе — то есть при ссылке на них в договоре на разработку (поставку) ПС.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести:

• ориентацию на единственную, «каскадную» модель жизненного цикла (ЖЦ) ПС;
• отсутствие четких рекомендаций по документированию характеристик качества ПС;
• отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД;
• нечетко выраженный подход к документированию ПС как товарной продукции;
• отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю («хелпов»);
• отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.

Ниже рассмотрены наиболее используемые стандарты в практике:

Перевод бумажных документов в электронный вид

1) ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД. Техническое задание. Требование к содержанию и оформлению.

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

Техническое задание должно содержать следующие разделы:

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

ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов.

Устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Рассматривает такие группы, как:

· Виды программных документов

· Виды эксплуатационных документов

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

3) ГОСТ 19.102-77. ЕСПД. Стадии разработки.

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

· Техническое задание: постановка задачи, сбор материалов

· Эскизный проект: уточнение методов решения

· Технический проект: разработка алгоритма, структуры программы

· Рабочий проект программирование, разработка документации, тестирование

· Внедрение: передача программы для изготовления и/или сопровождения

Источник: cyberpedia.su

Научная электронная библиотека

Документирование программных изделийПри разработке программных средств (ПС) создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС, и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

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

 документы управления разработкой ПС.

 документы, входящие в состав ПС.

Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) — лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов:

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

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

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

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

 заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

Документы, входящие в состав ПС (software product documen­ta­tion), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами). Во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС.

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

 пользовательская документация ПС (П-документация).

 документация по сопровождению ПС (С-документация).

Пользовательская документация программных средств

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ.

В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Он может не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.

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

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

Можно считать типовым составом следующий состав пользовательской документации для достаточно больших ПС:

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

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

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

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

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

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

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроено (сконструировано), и модернизацию его программ. Сопровождение — это продолжающаяся разработка.

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

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

 документацию, определяющую строение программ и структур данных ПС и технологию их разработки;

 документацию, помогающую вносить изменения в ПС.

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

 внешнее описание ПС (Requirements document);

 описание архитектуры ПС (description of the system architect­ture), включая внешнюю спецификацию каждой ее программы (подсистемы).

 для каждой программы ПС описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

 для каждого модуля спецификацию и описание его строения (design description);

 тексты модулей на выбранном языке программирования (program source code listings);

 документы установления достоверности ПС (validation docu­ments), описывающие, как устанавливалась достоверность каждой программы ПС, и как информация об установлении достоверности связывалась с требованиями к ПС.

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

Документация второй группы содержит руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми.

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

Создание и использование пакета прикладных программ (ППП) от формирования концепции и требований к первой версии до изъятия его из эксплуатации со­провождается документированием объектов и процессов жизненно­го цикла ППП.

По своему назначению документацию ППП можно классифицировать как:

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

 эксплуатационную (пользовательскую) документацию программного продукта, создаваемую для конечных пользователей пакета и позволяющую им осваивать и квалифицированно применять его для решения конкретных прикладных задач.Технологическая документация включает:

 документацию тестирования компонентов и комплексов про­грамм;

 документацию испытаний ППП;

 документацию сопровождения и управления конфигурацией ППП.В состав проектной документации входят:

 отчет по обследованию предметной области, для которой предназначен разрабатываемый ППП, с описанием комплекса за­дач;

 описание концепции проектирования;

 техническое задание на проектирование;

 спецификации эскизного и технического проекта;

 документация на разработанные программные модули пакета;

 общее описание программного обеспечения, используемого при разработке и функционировании пакета (описание выбранной технологии автоматизированного проектирования ППП, операцион­ной системы, других программных средств).

В состав документации тестирования входят:

 исходные данные для проведения тестирования (методы тестирования, тестовые наборы, эталонные значения, реальные ресурсы тестирования — временные, аппаратно-программные, люд­ские, критерии полноты и качества тестирования);

 программа (сценарии) тестирования;

 итоговый отчет о результатах тестирования.В состав документации испытаний входят:

 описание методов и методик испытаний;

 акт завершения работ;

 акт приемки ППП в эксплуатацию.В состав документации сопровождения управления конфигу­рацией входят:

 отчеты пользователей о выявленных дефектах и предло­жения по корректировке программ;

 журнал выявленных дефектов и предложений по совершенствованию и развитию версии ППП;

 журнал подготовленных и утвержденных корректировок, а также реализованных изменений в новой версии пакета;

 отчет о результатах эксплуатации снятой с сопровождения версии пакета;

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

 паспорт на программное средство, где содержатся общие сведения о ППП, его основные характеристики, комплектность, акт о приемке, гарантии изготовителя (поставщика);

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

 руководство администратора программного средства, кото­рое регламентирует функции администрирования, процедуры по инсталляции и подготовке ППП к эксплуатации, порядок и средства ведения базы данных и восстановления ин­формации при сбоях;

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

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

В процессе сопровождения в програм­мы вносятся различные изменения:

 исправление ошибок — корректировка программ, выдаю­щих неправильные результаты в условиях, ограниченных техниче­ским заданием и документацией;

 модернизация — расширение функциональных возможно­стей или улучшение качества решения отдельных задач в соответ­ствии с новым или дополнительным техническим заданием на ППП;

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

Выход коммерческого программного продукта на рынок про­граммных средств связан с организацией продаж массовому поль­зователю. Как правило, для каждого программного продукта существует своя форма кривой продаж, которая отражает спрос V во времени t (рис. 11).

Вначале продажа программного продукта идет вверх — возрас­тающий участок кривой. Затем наступает стабилизация. Далее происходит падение объема продаж, что является сигналом к изменению маркетинговой политики фирмы в отноше­нии данного программного продукта, требуется модификация продукта, изменение цены или снятие с продажи.

Эксплуатация программного продукта идет параллельно с его сопровождением, при этом эксплуатация программ может начи­наться и в случае отсутствия сопровождения, или продолжаться в случае завершения сопровождения еще какое-то время. После сня­тия программного продукта с продажи его сопровождение может выполняться определенное время.

Рис. 11. Кривая продаж программного продукта

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

В про­цессе эксплуатации фирма-разработчик предлагает пользователям приобрести новые версии программного продукта. Сопровождение также осуществляется специализированными фирмами-распро­странителями программного продукта (дистрибьюторами).

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

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программ­ных продуктов длительность жизненного цикла измеряется двумя-тремя годами. Хотя достаточно часто встречаются и давно снятые с производства программные продукты.

Существуют другие варианты легального распространения программного продукта, кроме коммерческого, которые появились с использованием глобальных или региональных сетей:freeware — бесплатно распространяемые и поддерживаемые самим пользователем программы;shareware — условно-бесплатные программы. Ими можно поль­зоваться бесплатно некоторое время, а при условиях регулярного использования требуется внести определен­ную сумму разработчику программы;demo-версии (демонстрационная и пробная програм­мы).

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

Пробная версия обычно полнофункциональна, но остается работоспособной лишь в течение небольшого промежутка времени, достаточного для ознакомления с ней (несколько дней или недель, либо определенное количество запусков). После этого работоспособность программы блокируется или же она превраща­ется в демонстрационную версию;ad ware — программа, показывающая рекламу. Бесплатная про­грамма такого типа, как правило, сохраняет все функции коммерче­ской версии и остается работоспособной в течение неограниченно­го времени, однако она постоянно показывает пользователю рекламные окна — баннеры. Чтобы «отключить» назойливую рек­ламу, необходимо оплатить коммерческую версию;OEM (Original Equipment Manufacturer) — программы, постав­ляемые с купленной компьютерной техникой по OEM-контракту ме­жду фирмой-разработчиком и продавцом ПК (или другого hardware). Их стоимость меньше, чем стоимость retail-программ, поставляе­мых в розницу в «коробочном» исполнении.

Источник: monographies.ru

Электронные документы: виды, требования и особенности документооборота

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

Елена Ефимова
02 Июля 2019
Подключиться

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

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

Документ бумажный, электронный образ и электронный документ

Федеральный закон от 29.12.1994 № 77-ФЗ (редакция от 03.07.2016) «Об обязательном экземпляре документов» определяет документ как «Материальный носитель с зафиксированной на нём в любой форме информацией в виде текста, звукозаписи, изображения и (или) их сочетания, который имеет реквизиты, позволяющие его идентифицировать, и предназначен для передачи во времени и в пространстве в целях общественного использования и хранения».

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

Понятие электронного документа закреплено Федеральным законом от 27.07.2006 № 149-ФЗ (редакция от 18.03.2019) «Об информации, информационных технологиях и о защите информации» и звучит так:

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

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

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

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

Требования к документам в электронном виде

Требования к документам в электронном виде делятся на три категории и соблюдаются в порядке приоритетности:

1. Общие требования. Не отличаются от требований к документам в бумажном виде и в основном касаются формы и содержания.
2. Требования, предъявляемые к конкретному виду документов в электронном виде, в том числе электронным документам. Ключевые в этой категории — требования к электронной подписи. Именно она и соблюдение условий её применения делают документ юридически значимым.
3. Особые требования к конкретным документам в электронном виде, предъявляемые исходя из их назначения, условий создания, обработки, передачи и хранения. Эти требования всегда индивидуальны по отношению к категориям или видам документов. Они отражены в специальных нормативных актах или инструкциях.

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

Виды и применение электронных документов

Рассмотрим самые распространённые документы в практике документооборота компаний и индивидуальных предпринимателей.

Договоры, контракты, соглашения

Часть 2 статьи 434 ГК РФ разрешает заключение письменных договоров путём обмена электронными документами, в том числе с использованием сторонами сделки электронной почты. Обязательное требование — возможность достоверно установить, что документ, например экземпляр договора, исходит от стороны сделки.

Выполнить условие легко: договоритесь с контрагентом о заключении договора таким способом, составьте и подпишите договор с использованием электронной подписи. Аналогичным способом можно обмениваться протоколами разногласий и дополнительными соглашениями, вносить изменения в договоры и направлять претензии.

Первичные учётные документы

Требования к ним изложены в статье 9 Федерального закона от 06.12.2011 № 402-ФЗ (редакция от 28.11.2018) «О бухгалтерском учёте». Специальные требования к счетам-фактурам — в статье 169 НК РФ.

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

Если бумажного документа нет, придётся его создать — распечатать соответствующий электронный документ. Это условие пока препятствует полному переходу на электронный документооборот: многие компании вынуждены дублировать документы полностью либо частично. Для обмена электронными счетами-фактурами и УПД, например, необходимо, обращаться к услугам оператора электронного документооборота. Также вести документооборот через оператора ЭДО целесообразно при больших объёмах документооборота — налаженная система сбережёт ваше время.

Отчётность

Всю налоговую и бухгалтерскую отчётность можно представлять в электронной форме. Обязательное условие для сдачи электронной отчетности — подписание документов усиленной квалифицированной электронной подписью. Передавать отчётность в электронном виде можно через оператора ЭДО или через официальный сайт ФНС.

Документы для подачи в суд

Любые процессуальные документы можно подавать в суд в электронном виде, в том числе в форме электронного документа. Для электронной подачи документов в арбитражные суды используется сервис «Мой арбитр», в суды общей юрисдикции — личный кабинет пользователя в разделе «Подача процессуальных документов в электронном виде» официального сайта суда на портале ГАС «Правосудие». Электронный образ документа можно заверить простой электронной подписью, электронный документ подписывается только усиленной квалифицированной электронной подписью.

Обращения в государственные органы

Большинство ведомств уже поддерживают онлайн-обмен документами и обращениями через сайты и личные кабинеты пользователей. Чтобы обратиться в государственный орган через интернет или направить электронный документ, зайдите на официальный сайт нужного ведомства, найдите раздел для обращений или направления отчётности в электронном виде и воспользуйтесь указанной информацией.

Юридическая значимость электронной переписки

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

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

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

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

Дать ответы на эти вопросы и подтвердить их доказательствами бывает непросто.

Если адреса электронной почты указаны в договоре с контрагентом и при этом чётко определён порядок обмена документами, проблем обычно не возникает. Идентифицировать СМС-отправления можно посредством сотового оператора. Сообщения в чатах и мессенджерах — через техподдержку соответствующей платформы. Но проблемы могут возникнуть, если придется оспаривать факт личного отправления. Ведь не исключено, что доступ к логину, паролю, устройству и сим-карте может получить третье лицо.

В 2016 году арбитражный суд Санкт-Петербурга и Ленинградской области рассматривал дело №А56-95953/2015, где фигурировали СМС-уведомления. Истец судился со Сбербанком относительно несанкционированного вывода со счёта истца денежных средств на сумму более 6 миллионов рублей. Для операций использовались платёжные поручения, подготовленные в информационной системе банка и подписанные сгенерированными одноразовыми кодами (паролями), которые направлялись на телефон истца и при вводе в подтверждение операции означали подписание документа простой ЭП. Суд отказал в удовлетворении исковых требований, сославшись на то, что истец, хотя, возможно, и не был причастен к операциям, не обеспечил недоступность средств идентификации.

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

Подведём итог

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

Второй момент — целесообразность перехода на ЭДО, станет ли документооборот проще, быстрее, надёжнее и экономичнее. Ради передачи нескольких документов в год нет смысла тратиться на организацию электронного документооборота. Но если объём документооборота большой, расходы на печать и доставку бумажных документов превышают потенциальные затраты на электронный документооборот, выгоднее перейти на ЭДО. Использование системы электронного документооборота поможет существенно сэкономить и упростить работу.

Источник: iitrust.ru