создание объектного кода программы происходит на этапе
Этапы разработки программы – как создаются и проектируются программы?
Привет, сегодня мы с Вами поговорим о том, как создаются высококачественные программы, а точнее, я расскажу на какие этапы делится этот процесс, поэтому если Вы хотите создавать классные приложения, то Вам обязательно стоит соблюдать все эти этапы, ну или по крайней мере большую их часть.
Зачем нужно проектировать программу и соблюдать этапы разработки?
Вы можете спросить, зачем нужно соблюдать какие-то там этапы, ведь разработка программы — это просто сел и написал код. Однако это не так, с таким подходом создать нормальное приложение не получится.
В зависимости от размера программных проектов этапы разработки могут отличаться, в некоторых случаях это будут очень детализированные и бюрократичные этапы, а в некоторых — просто сформулированные в любом удобном для разработчиков виде.
Так, например, при строительстве сарая у себя на даче Вы не будете что-то там детально планировать, исследовать, инспектировать, но в случае, скажем, со строительством электростанции все будет очень детально спланировано, спроектировано, режим работы рабочих будет расписан поминутно, так как цена ошибки на любом этапе будет значительно выше, чем в случае со строительством простого сарая.
Точно так же происходит и при разработке ПО, если проект крупный и очень важный, который возможно будет влиять на жизни людей или связан с огромными финансовыми рисками, все этапы разработки ПО будут соблюдаться, т.е. детально проработаны и даже будут добавляться новые этапы, микроэтапы и так далее.
Все это делается для того, чтобы не допустить появления ошибок и реализовать тот продукт, который действительно нужен.
Чем раньше будут обнаружены ошибки или выявлен неправильных подход в реализации того или иного действия, тем цена этих ошибок будет меньше. Иными словами, в зависимости от этапа обнаружения ошибки ее цена может меняться от 10 до 100 раз. Например, если на самом начальном этапе цена исправления ошибки будет равняться 100 рублей, то на этапе тестирования она может вылиться в 10000. Поэтому этапы разработки ПО очень важны, и разработчик должен их соблюдать и попытаться донести это видение до менеджеров, которым всегда нужен только результат. Так как они или отводят на это слишком мало времени или и вовсе не считают это необходимым, например, зачем при программировании вырабатывать какие-то требования или что-то там проектировать.
Основные этапы разработки ПО
Вот этапы, которые в большинстве случаев должны соблюдаться при разработке программного обеспечения:
Некоторым может показаться, что это слишком сложный план, но если Вы будете работать над крупным проектом, то столкнётесь со всем этим, и даже более детализированным планом.
Сейчас давайте рассмотрим каждый этап, т.е. узнаем, какие действия необходимо выполнять на каждом этапе.
Этап 1 – Определение проблемы
Перед тем как приступать к кодированию, необходимо четко сформулировать проблему, которую Ваша будущая программа должна решать. Так как, не имея хорошего определения проблемы, Вы можете потратить много усилий и времени на решение не той проблемы, которую требуется решить.
На данном этапе проводится простая формулировка сути проблемы без каких-либо намеков на ее возможные решения, при этом формулировать ее следует на языке, понятном пользователю, т.е. она должна быть описана с пользовательской точки зрения.
Определение проблемы – это фундамент всего процесса программирования!
Этап 2 – Выработка требований
Что такое требования и зачем их нужно выработать?
Требования к программе – это подробное описание всех возможностей программы и действий, которые должна выполнять программа. Такие требования иногда также называют «Функциональной спецификацией» или просто «Спецификацией».
Требования вырабатывают для того, чтобы свести к минимуму изменения системы после начала непосредственной разработки. Такие требования должны быть обязательно официальными, т.е. документально оформлены. Так как это гарантирует то, что функциональность системы определяется заказчиком, а не программистом. Даже в случае с внутрикорпоративными разработками такие требования должны быть зафиксированы, например, в виде технического задания, подписанного всеми задействованными лицами, тем самым Вы избежите лишних разговоров и споров, например, о том, что реализованный функционал делает не все или не так.
Выработка требований очень важна, так как она позволяет определить функциональность программы до начала программирования.
Этап 3 – Создание плана разработки
На данном этапе Вы уже должны в формальном виде составить план разработки программного обеспечения с учётом существующей проблемы и выработанных требований. Иными словами, Вы должны составить план того, как Вы будете действовать дальше.
Этап 4 – Разработка архитектуры системы или высокоуровневое проектирование
Архитектура системы – это каркас программы, это высокоуровневое проектирование программы.
Данный этап также очень важный, так как, не имея хорошей архитектуры, Вы можете решать правильную проблему, но прийти к неправильному решению. Хорошая архитектура программы упрощает программирование, а плохая архитектура усложняет его.
Архитектура системы обычно включает:
Кроме того, в архитектуру необходимо включить подтверждение того, что при разработке этой архитектуры рассматривались альтернативные варианты в каждом из вышеперечисленных направлений, с обоснованием окончательного выбора и подхода.
Этап 5 – Детальное проектирование
На этом этапе проводится проектирование программы на низком уровне, иными словами, здесь проектируются классы и методы, рассматриваются, оцениваются и сравниваются различные варианты и причины выбора окончательных подходов и способов реализации.
При разработке небольших программ программисты обычно сами проектируют программу на таком уровне, это выглядит как написание псевдокода или рисование схем, поэтому часто этот этап рассматривается как часть непосредственного кодирования и в таких случаях итоговый документ (если того требует формальность) состоит преимущественно из различных набросков и заметок программистов.
Но при реализации крупных проектов данному процессу отводится отдельный этап и проектирование в этом случае проводится с очень высокой степенью детальности.
Этап 6 – Кодирование и отладка
Это как раз тот этап, который все знают и, наверное, думают, что это единственный этап в процессе разработке программного обеспечения – это непосредственное написание кода и его отладка. Но, как видите, это далеко не первый и не единственный этап разработки ПО.
Если все вышеперечисленные этапы выполнены, то данный этап подразумевает чисто механическую работу, т.е. кодинг. Программисту в этом случае не нужно что-то выдумывать и самостоятельно разрабатывать, ему нужно просто написать код, который реализует заданный, очень детально описанный в проекте, алгоритм.
После того как код написан, программисту необходимо отладить этот код, чтобы в нем не было никаких ошибок.
Этап 7 – Тестирование компонентов
После того, как код написан, и проведена отладка, необходимо провести тестирование реализованного функционала. Если программа состоит из нескольких компонентов, сначала тестируют каждый компонент в отдельности, так как очень крупные программы включают огромный функционал, который часто разделяют на отдельные компоненты, разработка которых осуществляется по отдельности. В менее крупных проектах этот этап может включать просто тестирование отдельных классов.
Этап 8 – Интеграция компонентов
Когда тестирование всех компонентов закончено, можно переходить к интеграции всех компонентов в единый программный комплекс, этот этап как раз и подразумевает процесс интеграции, т.е. слияния всех компонентов в единую систему.
В небольших проектах этот этап может заключаться в объединении нескольких классов, на что будет затрачено не больше одного дня, но в крупных проектах этот этап может длиться не один месяц.
Этап 9 – Тестирование всей системы
На данном этапе проводится тестирование всей системы, уже с учётом интеграции всех компонентов. На этом этапе можно выявить проблемы взаимодействия компонентов и устранить их. Также на этом этапе основным предметом тестирования является безопасность, производительность, утечка ресурсов и другие моменты, которые невозможно протестировать на более низких уровнях тестирования.
Этап 10 – Сопровождение, внесение изменений, оптимизация
После запуска программы в промышленную эксплуатацию осуществляется сопровождение этой программы, т.е. внесение изменений на основе выявленных недочетов в процессе эксплуатации системы, а также проводится оптимизация функционала или добавление нового.
Если Вы хотите погрузиться глубже в мир проектирования и конструирования программного обеспечения, то рекомендую почитать книгу Стива Макконнелла «Совершенный код», в которой очень детально рассказывается о том, как нужно разрабатывать программу, и как правильно писать код. С помощью нее Вы не научитесь какому-нибудь языку программирования, но Вы научитесь писать правильный код, иными словами, она для тех, кто уже владеет базовыми знаниями в программировании.
Если Вы еще не умеете программировать, и даже не знаете, с чего начать, то в этом случае я рекомендую Вам начать с книги «Как стать программистом? 14 советов по достижению поставленной цели», в ней приведены советы и рассмотрен конкретный план действий, которые помогут Вам стать программистом.
У меня на этом все, надеюсь, статья была Вам интересна. Пока!
Исходный текст и объектный код программ для ЭВМ как объекты правовой охраны
Автор: Гинодман Е.Н., кандидат юридических наук.
1. Правовая охрана программ для ЭВМ
В соответствии с действующим законодательством программа для ЭВМ является результатом интеллектуальной деятельности (п. 2 ч. 1 ст. 1225 ГК РФ) и объектом авторских прав (ст. 1259 ГК РФ). Авторские права на все виды программ для ЭВМ (в том числе на операционные системы и программные комплексы), которые могут быть выражены на любом языке и в любой форме, включая исходный текст и объектный код, охраняются так же, как авторские права на произведения литературы (ст. 1261 ГК РФ).
Согласно п. 1 ст. 1266 ГК РФ не допускается без согласия автора внесение в его произведение изменений, сокращений и дополнений. В пп. 9 п. 2 ст. 1270 ГК РФ закреплено право автора или иного правообладателя на переработку произведения, под которой понимается создание нового, производного произведения. В отношении программы для ЭВМ законодатель в данной норме употребляет наряду с переработкой понятие модификации.
Модификация программы для ЭВМ – это любые ее изменения, в том числе перевод такой программы с одного языка на другой язык, за исключением ее адаптации.
Адаптация программы для ЭВМ – это внесение изменений исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя.
Как следует из системного анализа пп. 9 п. 2 ст. 1270 и пп. 1 п. 1 ст. 1280 ГК РФ, адаптация программы для ЭВМ является частным случаем изменения программы для ЭВМ, но при этом изменения, не требующего разрешения правообладателя (то есть легального).
В соответствии с пп. 1 п. 1 ст. 1280 ГК РФ лицо, правомерно владеющее экземпляром программы для ЭВМ или экземпляром базы данных (пользователь), вправе без разрешения автора или иного правообладателя и без выплаты дополнительного вознаграждения осуществлять действия, необходимые для функционирования программы для ЭВМ или базы данных (в том числе в ходе использования в соответствии с их назначением), включая запись и хранение в памяти ЭВМ (одной ЭВМ или одного пользователя сети), внесение в программу для ЭВМ или базу данных изменений исключительно в целях их функционирования на технических средствах пользователя, исправление явных ошибок, если иное не предусмотрено договором с правообладателем.
Кроме того, п. 3 ст. 1280 ГК РФ предоставляет пользователю право без согласия правообладателя и без выплаты дополнительного вознаграждения воспроизвести и преобразовать объектный код в исходный текст (декомпилировать программу для ЭВМ) или поручить иным лицам осуществить эти действия, если они необходимы для достижения способности к взаимодействию независимо разработанной этим лицом программы для ЭВМ с другими программами, которые могут взаимодействовать с декомпилируемой программой, при соблюдении определенных условий.
Таким образом, из содержания ст. 1261 ГК РФ следует, что правовая охрана предоставляется как самой программе для ЭВМ, так и средствам ее выражения — исходному тексту и объектному коду.
Для определения правомерности действий лица, не являющегося правообладателем, при использовании программы для ЭВМ интересным представляется вопрос о том, что признается изменением программы для ЭВМ: изменение только исходного кода или также изменение объектного кода.
Чтобы ответить на этот вопрос, необходимо дать определение указанных понятий.
2. Исходный текст программы для ЭВМ
Гражданский кодекс РФ использует понятие «исходный текст», однако определения данного понятия не содержит.
При этом в ГОСТах можно встретить определение понятия «исходный код». Исходный код — это код, написанный на исходном языке программирования, таком как язык ассемблера и/или язык высокого уровня, в машиночитаемой форме, пригодной для ввода в ассемблер или компилятор (п. 3.19 ГОСТ Р 51904-2002 «Государственный стандарт Российской Федерации. Программное обеспечение встроенных систем. Общие требования к разработке и документированию», утв. и введен в действие Постановлением Госстандарта России от 25.06.2002 N 247-ст, далее — ГОСТ Р 51904-2002).
В другом ГОСТе дано более простое определение исходного кода – это компьютерная программа в текстовом виде на каком-либо языке программирования (п. 3.4 ГОСТ Р 54593-2011 «Национальный стандарт Российской Федерации. Информационные технологии. Свободное программное обеспечение. Общие положения», утв. и введен в действие Приказом Росстандарта от 06.12.2011 N 718-ст, далее — ГОСТ Р 54593-2011).
Из анализа указанных определений следует вывод о том, что, поскольку исходный код представляет собой текстовый вид программы для ЭВМ, понятия «исходный код» и «исходный текст» являются равнозначными.
В юридической литературе высказывалась точка зрения, согласно которой именно тот факт, что исходный код программы сохраняется в текстовом файле, доступном для прочтения человеком, послужил основанием для законодателя приравнять компьютерную программу к литературным произведениям [1].
Запись исходного кода представляет собой оригинал произведения. Код в виде текста может отображаться на экране монитора, а может быть написан от руки. Однако исходный код доступен для понимания людьми, но недоступен для понимания компьютером. Для того чтобы программа для ЭВМ заработала, исходный код необходимо превратить в исполняемый файл (объектный код) [2].
3. Объектный код программы для ЭВМ
Объектный код – это представление компьютерной программы на низком уровне, обычно не в форме, непосредственно пригодной для объектного компьютера, а в форме, включающей в себя, помимо информации о процессорных командах, информацию о размещении программы (п. 3.31 ГОСТ Р 51904-2002).
Есть и иное определение объектного кода – это код, который является непосредственно пригодным для использования центральным процессором объектного компьютера, и является, следовательно, загружаемым в аппаратные средства или систему ПО (п. 12.20 ГОСТ Р 51904-2002).
Таким образом, для того чтобы исходный код стал доступен для понимания конкретным устройством, он компилируется специальными программами (компиляторами), вследствие чего происходит его преобразование в форму, понятную компьютеру. Следовательно, объектный код — это результат компиляции исходного текста программы [3].
Объектный код также называют исполняемым кодом, так как в результате компиляции исходного кода получается файл, при запуске которого на компьютере начнут исполняться команды, заложенные в исходном коде, программа будет решать задачи, для которых она разработана. Так, при запуске исполняемого exe-файла для конкретной программы на экране компьютера появляется окно с этой программой, после чего пользователь может с ней работать: например, формулировать поисковые запросы в карточке поиска, просматривать результаты поиска, открывать документы, экспортировать файлы и так далее.
4. Этапы создания и изменения программы для ЭВМ
При анализе практики современного программирования выделяют несколько этапов создания и изменения программы для ЭВМ:
Вопрос о том, в какую часть программы для ЭВМ могут вноситься изменения для правильной квалификации их правомерности – только в исходный код, или также в исполняемый/объектный код, — обсуждается в юридической литературе.
5. Изменение исходного и объектного кодов программы для ЭВМ в свете правовой охраны авторских прав
К вопросу об изменении исходного и объектного кодов можно встретить два подхода.
Первый подход основывается на утверждении, что специфика программ для ЭВМ такова, что изменение программы — это изменение именно исходного кода. Если встроенными в программу инструментами, предусмотренными разработчиком для применения пользователем, изменяются только результирующие данные, которые выдает программа, то такие изменения нельзя назвать изменением самой программы. Когда создан объектный код (исполняемый файл), его нельзя изменить, декомпилировать и превратить обратно в исходный код. В теории и практике это возможно, но является хакерством (кроме случаев, перечисленных в п. 3 ст. 1280 ГК РФ). В обычной практике это невозможно. Когда речь идет об изменении программы, человек может изменять только исходный код. [5].
Второй подход основывается на мнениях о том, что изменения в программу для ЭВМ следует квалифицировать независимо от того, куда были внесены изменения: в исходный код/текст программы или в исполняемый/объектный код программы для ЭВМ [6].
Некоторые авторы отмечают, что в современном программировании одни и те же изменения в программу могут вноситься различными способами, на разных этапах и разными инструментами как в исходный код/текст, так и в исполняемый/объектный код программы для ЭВМ. И именно этот критерий — внесение изменений как в исходный код/текст, так и в исполняемый/объектный код — предлагается авторами брать за основу определения изменений в программу для ЭВМ [7].
Такая логика вполне закономерна: поскольку изменение исходного кода программы неизбежно ведет к изменению исполняемого/объектного кода, следовательно, с точки зрения правовой охраны изменением программы для ЭВМ признаются как изменения исходного кода, так и изменения исполняемого/объектного кода. Здесь представляет особый интерес квалификация изменений исполняемого/объектного кода пользователем, эксплуатирующим программный продукт на своем устройстве. Обычный пользователь не видит исходный код, но видит результат его преобразования в исполняемом коде – благодаря данному преобразованию или внесенным изменениям могут появиться новые возможности работы с программой.
В юридической литературе приводятся критерии разграничения оригинального и производного произведений на основании судебной практики зарубежных стран. Например, в США для сравнения компьютерных программ и объектов, от них образованных, на предмет выявления факта переработки используют специальный тест Abstraction-Filtration-Comparison test (AFC).
При применении данного теста сравниваются основные элементы программы: основное назначение, структура или архитектура программы, модули, алгоритмы и структуры данных, исходный код и объектный код. Затем происходит выделение неохраняемых элементов, которые есть в программе из-за использования открытой лицензии, и сравнение уже основных охраняемых элементов. Таким образом, не только исходный, но и объектный коды сравниваются на предмет внесения изменений в программу для ЭВМ [8].
Обратимся к российским нормативным документам и судебной практике
В соответствии с п. 3.11 ГОСТ Р 51904-2002 под изменением программного обеспечения понимаются модификация исходного кода, исполняемого объектного кода или сопутствующих документов относительно их базовой линии.
В соответствии с другим ГОСТом определенные языки программирования формально не проводят различия между исходным текстом программ и исполняемыми файлами, поскольку исполняемые файлы создаются в то время, когда они активированы (п. 12.4 ГОСТ Р ИСО/МЭК 27002-2012 «Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности», утв. и введен в действие Приказом Росстандарта от 24.09.2012 N 423-ст).
Признание в качестве объектов авторских прав исходного текста/кода и объектного/исполняемого кода и предоставление им правовой охраны (ст. 1261 ГК РФ) также свидетельствуют о том, что изменения могут вноситься как в исходный, так и в объектный код.
Кроме того, в п. 3 ст. 1280 ГК РФ закреплено право пользователя на декомпиляцию программы ЭВМ, если она необходима для достижения способности к взаимодействию независимо разработанной этим лицом программы для ЭВМ с другими программами, которые могут взаимодействовать с декомпилируемой программой, при соблюдении определенных условий.
Декомпиляция, как следует из п. 3 ст. 1280 ГК РФ, представляет собой воспроизведение и преобразование объектного кода в исходный текст.
В практике отечественных судов для определения, имела ли место переработка программы для ЭВМ, а значит – нарушение исключительных прав, также сравнивают не только исходные, но и объектные коды. Для этого обычно назначается компьютерно-техническая экспертиза, и на разрешение эксперта ставятся вопросы о том, является ли исходный текст и/или объектный код одной программы производным (созданным на основе) исходного текста и/или объектного кода другой программы, являются ли данные программы идентичными (см., например, Постановление Суда по интеллектуальным правам от 21.11.2016 N С01-328/2016 по делу N А56-21040/2015, Решение Арбитражного суда Архангельской области от 27.05.2020 по делу N А05-12896/2018 (Постановлением Четырнадцатого арбитражного апелляционного суда от 04.09.2020 N 14АП-5315/2020, 14АП-5658/2020 по делу N А05-12896/2018 данное решение оставлено без изменения)).
В случае если суд установит, что ни в исходный, ни в объектный код изменения не вносились, будет сделан вывод о том, что программа для ЭВМ не подверглась изменению.
Напротив, если в результате исследования установят изменение исходного и объектного кода, будет сделан вывод о переработке программы. Так, Суд по интеллектуальным правам удовлетворил исковые требования о признании исключительных прав на программы для ЭВМ, поскольку истцом было доказано, что в результате переработки исходный и объектные коды первоначальной программы существенным образом изменились, в результате чего у пользователя появилась возможность решать дополнительные задачи (Постановление Суда по интеллектуальным правам от 21.03.2017 N С01-1269/2016 по делу N А40-154016/2014).
Изложенное подтверждает высказанное в литературе мнение, согласно которому различия между изменениями в исходный код/текст и в исполняемый/объектный код программы для ЭВМ в настоящее время весьма условны и изменения в программу следует квалифицировать независимо от того, куда были внесены изменения: в исходный код/текст программы или в исполняемый/объектный код программы для ЭВМ [9].
Следовательно, и при разрешенной правообладателем (разработчиком) модификации либо легальной адаптации программы для ЭВМ, и при ее незаконной переработке оба ее элемента – исходный код/текст и исполняемый/объектный код — могут быть подвергнуты изменению.
Данный вывод имеет не только теоретическое, но и практическое значение для выбора варианта правомерного поведения при работе с программными продуктами. На практике регулярно возникают ситуации, когда лицу, использующему программу, требуется внести в нее изменения в той или иной форме.
В литературе приводится пример, когда программа для ЭВМ, переданная облачному провайдеру, технически не приспособлена к тому, чтобы пользователи работали с ней удаленно, и облачному провайдеру требуется внести в нее изменения. Для того чтобы данная программа приобрела новое существенное свойство – возможность предоставляться удаленно, – провайдеру необходимо изменить и исходный, и объектный коды. В соответствии с законом подобные изменения признаются модификацией. Такой переработанный программный продукт будет считаться самостоятельным объектом охраны (производным произведением), а облачный провайдер становится обладателем авторских прав на него. Для правомерного использования переработанной программы и распоряжения исключительным правом на нее облачному провайдеру необходимо получить разрешение правообладателя на переработку (модификацию) программы в соответствии с пп. 9 п. 1 ст. 1270 ГК РФ [10].
Таким образом, и простым пользователям, и специалистам IT-индустрии важно не допускать нарушений исключительных прав на программы для ЭВМ, поскольку данные нарушения влекут как гражданско-правовую, так и в предусмотренных законом случаях уголовную ответственность. Чтобы оставаться в рамках правового поля, необходимо четко следовать установленным законом правилам и при этом отдавать себе отчет в том, как именно могут квалифицироваться соответствующие действия и их результаты.
Примечания:
[1] Девлятшина М. Защита прав на компьютерную программу // ЭЖ-Юрист. 2017. N 25. С. 13.
[2] Саулин И.Н. Практика признания исключительных прав на производные программы для ЭВМ // ИС. Авторское право и смежные права. 2018. N 10. С. 43 — 56.
[3] Соколов Д.В., Шишенина И.В. К вопросу определения критериев изменений программы для ЭВМ // Ассоциация поставщиков программных продуктов: сайт. 2020. URL: http://www.appp.ru (дата обращения: 29.10.2020).
[4] Соколов Д.В., Шишенина И.В. К вопросу определения критериев изменений программы для ЭВМ // Ассоциация поставщиков программных продуктов: сайт. 2020. URL: http://www.appp.ru (дата обращения: 29.10.2020).
[5] Саулин И.Н. Практика признания исключительных прав на производные программы для ЭВМ // ИС. Авторское право и смежные права. 2018. N 10. С. 43 – 56.
[6] Дюков А.В. Проблема правомерной адаптации программы для ЭВМ // СПС КонсультантПлюс.
[7] Соколов Д.В., Шишенина И.В. К вопросу определения критериев изменений программы для ЭВМ // Ассоциация поставщиков программных продуктов: сайт. 2020. URL: http://www.appp.ru (дата обращения: 29.10.2020).
[8] Айрапетов Н.А. Критерии разграничения оригинального и производного произведения // ИС. Авторское право и смежные права. 2020. N 9. С. 52 — 58.
[9] Соколов Д.В., Шишенина И.В. К вопросу определения критериев изменений программы для ЭВМ // Ассоциация поставщиков программных продуктов: сайт. 2020. URL: http://www.appp.ru (дата обращения: 29.10.2020).
[10] Рагозина В.В. Правообладатель программы для ЭВМ и облачный провайдер: особенности соглашений в сфере облачных технологий // ИС. Авторское право и смежные права. 2019. N 6. С. 53 – 62.