Договоры на разработку программного обеспечения. Неочевидные риски и способы их избежать

Догоовр на разработку программного обеспеченпия

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

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

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

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

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

Риск возникновения исключительного права у третьих лиц.

Как выбрать договор на разработку ПО

Таким образом, при выборе конструкции договора необходимо обращать внимание на следующие моменты: 1) что является непосредственным предметом заказа, и 2) кто выступает на стороне исполнителя. Если предмет заказа – конкретное программное обеспечение, договор на услуги не подходит, т.к.

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

Какие риски несут стороны в случае ошибки при заключении договора?

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

Договор разработки программного обеспечения

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

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

Договор на разработку программы по свое правовой природе является взаимным, консенсуальным, возмездным. Договор на разработку программного обеспечения является одним из видов договора подряда и к нему применяют общие нормы главы 37 Гражданского Кодекса РФ.

Заказчиком может стать любое физическое лицо, индивидуальный предприниматель, юридическое лицо. Исполнителем может выступать какие-либо индивидуальный предприниматель, физическое лицо, юридическое лицо. В согласии с пунктом 1 статьи 1228 Гражданского Кодекса РФ изначально исключительное право на программный продукт принадлежит автору, которым может стать лишь физическое лицо.

Однако исключительное право на программное обеспечение можно передать другим лицам (индивидуальному предпринимателю, юридическому лицу) по основаниям, которые установлены законом РФ (пункт 3 статьи 1228), а именно лицензионным договором и договором об отчуждении исключительного права (статья 1233 Гражданского Кодекса РФ). Согласно статьи 1297 Гражданского Кодекса РФ, когда по соглашению сторон исключительное право на программное обеспечение принадлежит:

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

Договор на программное обеспечение имеет такие существенные условия: 1. Предметом является список работ по разработке программного обеспечения на основании технического задания.

Еще в образце договора на создание программного обеспечения можно указать другие условия – ответственность сторон, срок действия соглашения, порядок расторжения и изменения договора, форс-мажор и так далее.

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

Источник: http://ros-trud.ru/dogoovr-na-razrabotku-programmnogo-obespechenpija-67493/

Основные риски, связанные с внедрением автоматизированной системы

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

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

Статья посвящена рассмотрению этих причин и возможных способах их предупреждения.

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

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

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

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

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

Это, конечно же, влечет за собой срыв сроков проекта.

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

Задача компании, внедряемой решение, состоит в том, чтобы до начала проекта снять с заказчиком все вопросы, связанные с руководством проекта.

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

Рассмотрим это на примере проекта автоматизации крупной промышленной компании.

Переговоры о начале работ давали основание полагать, что проект будет успешным. Острую заинтересованность в успешности работ показал генеральный директор, а также основной заказчик системы – финансовый директор. Перед началом работ были оговорены с заказчиком возможные риски.

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

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

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

Результатом такой предпроектной работы стало превышение в 2 раза срока сдачи этапа и как следствие финансовые потери для внедряющей компании.

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

Отсутствие у Заказчика методологии для автоматизируемых участков

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

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

Можно участвовать в проектах и когда нет формального документа, например, «методология управленческого учета», но главное – чтобы были люди в команде заказчика, которые понимают, как они должны работать (с точки зрения методологии).

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

Рассмотрим это на примере проекта автоматизации сети торговых предприятий.

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

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

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

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

Работа по проекту в целом была доведена до конца, проект был выполнен, но с существенным (на несколько месяцев) сдвигом сроков.

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

Существуют и другие риски, не менее важные при выполнении проектов внедрения автоматизированных решений. К ним отнесем:

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

Согласование проектной документации

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

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

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

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

В разделе подписей проектной документации вставляется формулировка «Подтверждаю корректность и полноту …» – для того, чтобы исполнители еще раз обратили на это внимание.

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

Наличие работающей схемы управления изменениями

Источник: https://rarus.ru/press/publications/56844/

Основные пять рисков проектов разработки программного обеспечения

Управление рисками (точнее, избегание рисков) является критической темой, но зачастую ею пренебрегают и опускают.

Одной из немногих полезных и интересных книг на данную тему является книга «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения», написанная Томом ДеМарко и Тимоти Листером.

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

Притом , что книга не фокусируется на гибкой методологии разработки (Agile), стоит отметить, что основные пять определенных рисков, сопровождающих проекты по разработке ПО, в данной  книге имеют решения, корни которых находятся именно в гибкой методологии. ДеМарко и Листер описывают следующие пять основных рисков и стратегий, позволяющих их избежать:

Риск 1: ошибки, присущие расписанию  

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

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

Гибкий метод: в проектах, использующих гибкую методологию, команда активно вовлечена в планирование  и оценку посредством таких действий, как  экстремальное программирование (Extreme Programming, XP) и семинары Wideband Delphi. Работая в коротких этапах, скорость работы команды резко увеличивается, и это явно видно всем участникам проекта, кто  на данный момент более вовлечен в проект. Вкратце, настоящий прогресс сложно скрыть от владельцев.

Риск 2: появление новых требований

Описание: по ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки.

Решение из книги: постоянное вовлечение клиентов и разработчиков.

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

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

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

Риск 3: смена сотрудников

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

Решение из книги: высокий уровень сотрудничества и обмена информацией в команде.

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

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

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

Риск 4: декомпозиция спецификации

Описание: при старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования.

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

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

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

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

Риск 5: низкая продуктивность

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

Решение из книги : короткие итерации, нужные люди в команде, лидерство и развитие команды.

Гибкий метод:гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах.

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

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

Заметка по гибкой методологии

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

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

Mike Griffiths

Newer news items:

Older news items:

Источник: http://www.pmtoday.ru/project-management/risks/top-five-risks.html

Договор на разработку программного обеспечения: вариант

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

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

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

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

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

город Минск «__»_________201_ года

____________________________________________, именуемое в дальнейшем «Заказчик», в лице директора ______________________________, действующего на основании Устава, и __________________________, именуемый в дальнейшем «Исполнитель», в дальнейшем совместно именуемые «Стороны», а по отдельности — «Сторона», заключили настоящий Договор на разработку программного обеспечения о нижеследующем:

1. ПРЕДМЕТ ДОГОВОРА

1.1.

Исполнитель обязуется разработать программное обеспечение в виде мобильного приложения для Интернет-ресурса «____________________________________» (далее — программное обеспечением) и передать все исключительные права на программное обеспечение Заказчику, а Заказчик обязуется оплатить услуги Заказчика в соответствии с настоящим Договором.1.2. Под мобильным приложением для целей настоящего Договора понимается компьютерная программа, которая бы позволяла при установке на мобильные устройства, приспособленные для выхода в сеть Интернет, предоставлять пользователю мобильного устройства эксклюзивный формат просмотра Интернет-ресурса «_______________».

1.3. Исполнитель обязуется разработать мобильное приложение, которое бы позволяло установку на следующие типы устройств ______________________________________________________.

2. ПРАВА И ОБЯЗАННОСТИ ИСПОЛНИТЕЛЯ

2.1. Исполнитель обязуется:2.1.1. разработать программное обеспечение в течение __________ в соответствии с настоящим Договором;2.1.2. протестировать программное обеспечение;2.1.3. разработать инструкцию по установке программного обеспечения и руководство пользователя;2.1.4.

осуществить сдачу Заказчику разработанного программного обеспечения (в том числе исходный код), путем подписания акта приема – передачи выполненных работ;2.1.5.

по окончании работ продемонстрировать работу программного обеспечения на мобильном устройстве, передать установочную версию программного обеспечения, к которой прилагаются инструкция по установке программного обеспечения и руководство пользователя;2.1.6. обучить специалистов Заказчика работе с программным обеспечением;2.1.7. установить испытательный срок в течение _____ месяцев.

В период испытательного срока Исполнитель бесплатно устраняет дефекты и учитывает замечания Заказчика, связанные с проведенными Исполнителем работами.2.1.8. выполнять работы, являющиеся предметом настоящего Договора, качественно и в установленные сроки.2.1.9.

не разглашать третьим лицам коммерческую, финансовую, техническую и иную информацию, ставшую известной в ходе реализации настоящего Договора.2.1.10. передать Заказчику все исключительные права на программное обеспечение.2.2. Исполнитель имеет право:2.2.1. досрочно выполнить работы по настоящему Договору;

2.2.2. требовать от Заказчика своевременной оплаты разработанного программного обеспечения в соответствии с настоящим Договором.

3. ПРАВА И ОБЯЗАННОСТИ ЗАКАЗЧИКА

3.1. Заказчик обязуется:3.1.1. своевременно и в полном объеме оплатить стоимость разработки программного обеспечения Исполнителем на условиях настоящего Договора;3.1.2. предоставить Исполнителю всю необходимую для разработки программного обеспечения информацию;3.1.3.

определить ответственное лицо для взаимодействия с Исполнителем по вопросам, касающимся разработки программного обеспечения;3.1.4.

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

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

С момента получения Исполнителем уведомления о расторжении исполнение настоящего Договора приостанавливается.В случае досрочного расторжения Заказчиком настоящего Договора, Исполнитель имеет право на получение от Заказчика стоимость фактически выполненных работ, а Заказчик обязан оплатить Исполнителю стоимость фактически выполненных работ по Разработке программного обеспечения.

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

4. СТОИМОСТЬ РАБОТ И ПОРЯДОК РАСЧЕТОВ

4.1. Стоимость разработки программного обеспечения составляет ________________________.4.2.

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

4.3.

Расчет Заказчика с Исполнителем производится в срок не позднее 10 (десяти) банковских дней после подписания Сторонами акта приема — передачи выполненных работ.

5. ОТВЕТСТВЕННОСТЬ СТОРОН

5.1. Споры и разногласия, возникшие в процессе исполнения настоящего Договора, Стороны разрешают будут стремиться разрешать путем переговоров.

При невозможности урегулирования споров путем переговоров, споры подлежат разрешению в компетентном суде по месту нахождения Заказчика.
5.2.

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

6. ИНТЕЛЛЕКТУАЛЬНАЯ СОБСТВЕННОСТЬ

6.1. Исключительные имущественные права на программное обеспечение переходят к Заказчику после подписания акта приема-передачи выполненных работ по настоящему Договору.6.2.

Заказчик имеет право сдавать в аренду, продавать, передавать в использование, изменять, создавать новые версии программного обеспечения, декомпилировать программное обеспечение полностью или в части.6.3.

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

6.4. Исполнитель не имеет право использовать программное обеспечение в коммерческих целях.

7. ОБСТОЯТЕЛЬСТВА НЕПРЕОДОЛИМОЙ СИЛЫ

7.1.

Стороны освобождаются от ответственности за неисполнение либо ненадлежащее исполнение обязательств по настоящему Договору, если оно явилось следствием обстоятельств непреодолимой силы, то есть чрезвычайных и непредотвратимых при данных условиях обстоятельств (обстоятельства непреодолимой силы), возникших после заключения настоящего договора. К обстоятельствам непреодолимой силы относятся события, на которые не могут оказывать влияние и за возникновение которых ответственности не несут, а именно: землетрясения, наводнения, пожары и т.д.7.2. Сторона, ссылающаяся на обстоятельства непреодолимой силы, обязана немедленно известить в письменной форме другую сторону об их возникновении.7.3. Срок выполнения обязательств по настоящему договору отодвигается соразмерно времени, в течение которого действуют обстоятельства непреодолимой силы и их последствия.

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

8. ПРОЧИЕ УСЛОВИЯ

8.1. Все изменения и дополнения к настоящему договору должны быть составлены в письменной форме и подписаны Сторонами.8.2. К настоящему Договору применимым является право Республики Беларусь.8.3.

Настоящий договор вступает в силу с момента подписания его Сторонами и действует до полного исполнения Сторонами своих обязательств.

8.4.

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

9. РЕКВИЗИТЫ СТОРОН

Источник: https://legaltime.by/development-contract/

Договор на разработку программного обеспечения

5. Порядок сдачи-приемки Программного обеспечения 5.1.

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

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

6. Ответственность Сторон 6.1. Стороны несут ответственность за неисполнение ли ненадлежащее исполнение своих обязательств по настоящему Договору в установленном законом порядке.

Как составить договор на разработку программного обеспечения?

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

https://www.youtube.com/watch?v=0mSBq3rx_Uc

Как это происходит на практике?

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

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

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

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

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

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

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

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

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

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

Договор на оказание услуг по разработке программного обеспечения

не разглашать третьим лицам коммерческую, финансовую, техническую и иную информацию, ставшую известной в ходе реализации настоящего договора;3.2. Заказчик имеет право: 3.2.1. получать информацию о ходе работ по Разработке Программы в рабочие дни с до лично и по телефону: .3.2.2.

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

В случае досрочного расторжения Заказчиком настоящего договора, Исполнитель имеет право на получение от Заказчика стоимость фактически выполненных работ, а Заказчик обязан оплатить Исполнителю стоимость фактически выполненных работ по Разработке Программы.4.1.

Стд смк 277-2010 договор разработки программного обеспечения

1.11. На разработанное ПО устанавливается гарантийный срок 1 (один) год со дня подписания Акта сдачи-приемки услуг (работ) по разработке ПО. В период гарантийного срока Исполнитель обязуется за свой счет обеспечивать техническую поддержку ПО в виде устранения, выявленные в процессе эксплуатации ПО проблемы (недостатков), если они противоречат условиям Технического задания.

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

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

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

пункт выше). Далее в разделе необходимо решить вопрос о правах на промежуточные и окончательные результаты разработок.

Если не согласовать иное, Разработчик может создать массу промежуточных версий ПО с приоритетом по дате создания, воспользовавшись финансированием Заказчика.

В таком случае Заказчик получит исключительное право только на окончательный результат, а за Разработчиком сохранятся права на массу клонов.

Договорное оформление прав на программное обеспечение

При выполнении работ по созданию ПО непосредственно физическим лицом (автором) заключается (ст.1288 ГК РФ).

Аналогично решается вопрос при создании ПО коллективом авторов.

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

Источник: http://civilyur.ru/dogovor-na-razrabotku-programmnogo-obespechenija-92947/