Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
Um Acordo de Desenvolvimento de Software e Licença é um contrato formal entre uma empresa desenvolvedora e um cliente para a criação, entrega e licenciamento de software customizado. O modelo estrutura todo o processo de desenvolvimento — desde aprovação de especificações funcionais até testes de aceitação, cronogramas de implementação e transferência de documentação técnica. Inclui definições claras de responsabilidades, prazos, encargos, despesas reembolsáveis e direitos de propriedade intelectual. Disponível para download em Word gratuito e totalmente editável, permitindo que você customize datas, valores, especificações e prazos para seu projeto específico.
Projetos de desenvolvimento de software exigem clareza absoluta sobre o que será entregue, quando, por quanto e quem é responsável por quê. Sem um acordo formal, empresa e cliente frequentemente discordam sobre escopo, qualidade ou aceitação do software — resultando em atrasos, custos adicionais, litígios ou rejeição do produto no final. Este modelo protege ambas as partes ao estabelecer: especificações funcionais aprovadas por escrito, cronogramas realistas com marcos definidos, critérios de aceitação objetivos e mensuráveis, estrutura clara de encargos e despesas, e direitos de licença bem definidos. Particularmente crítico em projetos de médio a alto investimento, software regulado (finança, saúde) ou quando múltiplas jurisdições estão envolvidas, este acordo reduz risco de mal-entendidos e fornece base legal sólida para resolução de conflitos.
| Se sua situação é… | Use este modelo |
|---|---|
| Projeto pequeno ou prototipagem com menos complexidade técnica | Acordo básico — desenvolvimento simples |
| Software crítico que exige manutenção e atualizações continuadas | Acordo com suporte pós-lançamento |
| Cliente que deseja propriedade total do código e documentação | Acordo com transferência de propriedade intelectual |
| Software que será utilizado indefinidamente sem renovação | Acordo de licença perpétua |
| Projeto regulado ou crítico com múltiplas fases de validação | Acordo com testes de aceitação rigorosos |
| Desenvolvimento iterativo com entregas parciais e aprovações incrementais | Acordo modular — funcionalidades em fases |
Por que importa: Quando o software é entregue, cliente e empresa discutem se atende aos requisitos; risco de rejeição e litígio.
Fix: Anexe documento detalhado descrevendo cada função, botão, relatório e fluxo do sistema com exemplos.
Por que importa: Sem testes claros, é impossível determinar quando o projeto está 'pronto'; atrasos e custos crescem.
Fix: Especifique testes automatizados, casos de teste, limites de performance e requisitos de segurança que o software deve passar.
Por que importa: Empresa e cliente discordam sobre quem é responsável por atrasos; projetos desviam indefinidamente.
Fix: Indique datas-alvo de entrega para cada fase (especificações, codificação, teste, implementação) e consequências de atrasos.
Por que importa: Após investimento, cliente quer usar o software livremente, mas empresa acredita reter direitos; causa bloqueio.
Fix: Estabeleça explicitamente: cliente recebe licença perpétua não-exclusiva, licença exclusiva, ou propriedade total do código-fonte.
Por que importa: Empresa apresenta faturas por despesas não mencionadas no contrato; cliente recusa pagamento e projeto paralisa.
Fix: Detalhe valor fixo, despesas reembolsáveis, limite de reembolsos e como são documentadas (recibos, notas fiscais).
Por que importa: Especificações, código-fonte ou dados do cliente podem ser expostos a terceiros; risco legal e reputacional.
Fix: Adicione cláusula proibindo divulgação de informações confidenciais a terceiros sem consentimento escrito.
Em linguagem simples: Identifica a empresa desenvolvedora, o cliente (consumidor), a data de início e o local de execução do acordo.
Este Acordo está efetivo [DATA], entre [NOME DA EMPRESA] (a 'Companhia') e [NOME DO CLIENTE] (o 'Consumidor'), com escritório sede em [ENDEREÇO COMPLETO].
Erro comum: Deixar campos de data, nomes ou endereços em branco ou incompletos.
Em linguagem simples: Contexto e objetivos do acordo — que a empresa oferece desenvolvimento de software e o cliente solicitou desenvolvimento com funções específicas.
A Companhia está empenhada em desenvolvimento de software; o Consumidor solicitou o desenvolvimento de software com capacidades descritas na Tabela [ESPECIFICAR].
Erro comum: Não referenciar anexos que detalham as especificações funcionais solicitadas.
Em linguagem simples: Esclarece o significado de termos como 'Data de Aceitação', 'Especificações Funcionais', 'Hardware', 'Cronograma de Implementação' e 'Documentação de Sistema'.
Data de Aceitação significa a data em que o Software passou por todos os testes de aceitação conforme [ESPECIFICAR]. Hardware significa o processador e sistema operacional constante no Anexo [ESPECIFICAR].
Erro comum: Omitir definições de termos técnicos, causando ambiguidade sobre responsabilidades.
Em linguagem simples: A empresa preparará especificações detalhadas do projeto dentro de um prazo (ex.: 10 dias úteis), que o cliente aprovará, rejeitará ou solicitará alterações.
As especificações detalhadas serão entregues ao Consumidor para aprovação dentro de [NÚMERO] dias úteis da Data de Início. O Cliente tem [NÚMERO] dias para aprovar, rejeitar ou solicitar esclarecimentos por escrito.
Erro comum: Não estabelecer prazos claros ou ciclos de revisão, resultando em atrasos e confusão.
Em linguagem simples: Define que a aprovação tácita (silêncio) conta como aceitação; especificações detalhadas aprovadas incorporam e prevalecem sobre especificações funcionais.
Se não for rejeitado por escrito no prazo, o Cliente é considerado como tendo aceitado. As especificações detalhadas aprovadas devem fazer parte das especificações funcionais.
Erro comum: Não deixar claro que falta de resposta no prazo equivale a aceitação, causando dúvidas sobre o status.
Em linguagem simples: Se o cliente rejeita a parte de critérios de aceitação das especificações detalhadas, assume a responsabilidade (e custo) de desenvolver os testes.
Se o Cliente rejeita a parte que refere-se aos critérios de teste de aceitação, o Cliente será o único responsável, por sua própria conta, pelo desenvolvimento dos critérios.
Erro comum: Deixar ambíguo quem desenvolve e paga pelos testes, causando conflito sobre custos.
Em linguagem simples: Após aprovação das especificações, a empresa realiza codificação, depuração e desenvolvimento de documentação conforme o cronograma de implementação.
Após aceitação das especificações detalhadas, a Companhia deverá realizar a codificação e depuração do Software e desenvolvimento da documentação, em conformidade com a Tabela de Implementação.
Erro comum: Não vincular início do desenvolvimento a aprovação formal das especificações.
Em linguagem simples: O cliente pagará honorários de licença conforme Tabela 'B', mais reembolso de despesas (viagens, hospedagem, comunicação, impostos).
Encargos significam a licença a ser paga pelo Consumidor, conforme Tabela 'B', juntamente com reembolso de despesas da Companhia (viagens, alojamento, comunicação) e impostos federais, estaduais e municipais.
Erro comum: Não especificar quais despesas são reembolsáveis ou deixar categorias ambíguas.
Em linguagem simples: A empresa entrega manuais, fluxogramas, especificações de saída, dicionários de dados, layouts de tela e código-fonte comentado.
Sistema de Documentação significa manuais, fluxogramas, especificações de impressão, dicionários de dados, layouts de tela, códigos-fonte operacionais e manuais técnicos que descrevem o funcionamento e administração do Software.
Erro comum: Não detalhar que documentação é necessária, resultando em software sem manuais adequados.
Insira o nome completo, tipo de entidade (companhia, pessoa jurídica), estado/província de constituição e endereço completo de ambas as empresas (desenvolvedora e cliente).
💡 Use informações exatas do registro comercial ou contrato social.
Anexe ou crie a Tabela de Especificações Funcionais (funções do software) e a Tabela B (encargos e despesas). Indique o cronograma estimado de implementação.
💡 Quanto mais detalhadas as especificações funcionais, menos conflitos futuros. Seja específico sobre hardware, sistema operacional e requisitos.
Insira o número de dias úteis para entrega das especificações detalhadas (ex.: 10 dias) e quantos dias o cliente tem para aprovação ou rejeição (ex.: 5 dias).
💡 Use 'dias úteis' para evitar contar feriados. Deixe prazos realistas para análise.
Defina como o software será testado, quais condições devem atender e quem é responsável por cada teste (empresa ou cliente).
💡 Testes bem definidos evitam discussões sobre se o software foi 'aceito' ou não.
Indique o valor total de honorários de licença na Tabela B e liste categorias de despesas reembolsáveis (viagem, hospedagem, comunicação, impostos).
💡 Seja explícito sobre moeda, forma de pagamento e calendário de pagamentos.
Liste todos os documentos que serão entregues: manuais do usuário, manuais técnicos, código-fonte comentado, fluxogramas, dicionários de dados.
💡 Quanto maior o detalhe, menos ambiguidade sobre 'o que está incluído'.
Determine qual lei rege o acordo (Brasil ou Portugal) e clarifique se o cliente recebe propriedade total, licença perpétua ou licença com renovação.
💡 Propriedade intelectual é crítica — deixe explícito se o cliente possui o código-fonte ou apenas licença de uso.
A Data de Aceitação é o dia em que o software passa em todos os testes de aceitação e é formalmente aceito pelo cliente. Importa porque marca o fim da responsabilidade de desenvolvimento e o início do período de licença e suporte. Sem uma data clara, é impossível saber quando a empresa cumpriu suas obrigações ou quando o cliente pode começar a usar o software em produção. O acordo define que a Data de Aceitação ocorre após testes bem-sucedidos conforme especificações detalhadas aprovadas.
Sim, mas com cuidado. O acordo permite que o cliente solicite alterações às especificações detalhadas durante a fase de revisão inicial (antes da aprovação final). Após aprovação, alterações podem ser possíveis, mas exigem acordo escrito de ambas as partes e podem afetar prazos e custos. Mudanças significativas após desenvolvimento avançado costumam aumentar o cronograma e os encargos. Para evitar problemas, quanto mais detalhadas as especificações iniciais, menor a necessidade de mudanças.
Depende do que foi rejeitado. Se o cliente rejeitou apenas a parte dos 'critérios de teste de aceitação' nas especificações detalhadas, o cliente assume responsabilidade e custo de desenvolver os testes. Se o software falha em testes definidos pela empresa, a empresa é responsável por corrigir. O acordo deixa claro que se o cliente rejeitar a metodologia de teste, o cliente arca com desenvolvimento dos testes alternativos.
O acordo estabelece um cronograma de implementação, mas não detalha penalidades explícitas por atraso neste modelo. Recomenda-se adicionar cláusula de atraso que especifique: multa diária, extensão automática do prazo, ou direito de cancelamento após [X] dias de atraso. Sem isso, o cliente pode ter dificuldade em exigir cumprimento. Consulte um advogado sobre penalidades de atraso adequadas à sua situação.
O acordo menciona código-fonte comentado na documentação de sistema, mas não é explícito se o cliente recebe cópia do código-fonte ou apenas acesso durante suporte. Recomenda-se clarificar: se cliente recebe código-fonte completo sob propriedade total, ou se apenas a empresa pode modificar o código. Isso afeta renovações de licença, suporte futuro e propriedade intelectual. Adicione anexo sobre direitos de código-fonte.
Este modelo é flexível e funciona para Brasil, Portugal e outros países lusófonos. Porém, você deve especificar claramente em qual jurisdição o acordo é regido (lei brasileira, portuguesa, etc.). Diferentes jurisdições têm regras distintas sobre propriedade intelectual, impostos e direitos de licença. Adicione cláusula de lei aplicável (ex.: 'Este Acordo será regido pelas leis da República Federativa do Brasil') e considere consultar advogado na jurisdição relevante.
Sim. O acordo estabelece que o cliente tem um número específico de dias úteis para aprovar, rejeitar ou pedir esclarecimentos. Se não houver resposta dentro do prazo, o cliente é considerado como tendo aceito tacitamente. Você deve preencher este número de dias (ex.: 5 dias úteis). Falta de resposta por escrito conta como aceitação, evitando que o projeto fique parado indefinidamente.
O acordo prevê que a Tabela 'B' detalha encargos (honorários de licença) e despesas reembolsáveis. Você pode estruturar como: pagamento único no lançamento, parcelas mensais durante desenvolvimento, ou 50% no início e 50% na data de aceitação. Inclua disposições sobre quando faturas são emitidas, prazo para pagamento (ex.: 30 dias) e que despesas reembolsáveis devem ser documentadas com recibos.
Um acordo simples de consultoria cobre apenas horas de trabalho e serviços genéricos. Este acordo é específico para desenvolvimento de software com especificações funcionais detalhadas, testes de aceitação objetivos, entrega de documentação técnica e transferência de direitos de licença. Use o acordo simples para consultoria genérica; use este para projetos de desenvolvimento com entregáveis claros e cronogramas estruturados.
Um acordo de SaaS ou licença de software pronto cobre uso de software já construído, com poucos direitos de customização. Este acordo aborda desenvolvimento de software inteiramente novo e customizado. Use SaaS para software genérico; use este para desenvolvimento de aplicação exclusiva.
Um contrato de trabalho por projeto é simples e informal, focado em entrega de código. Este acordo é formal e estruturado, com especificações aprovadas, critérios de aceitação, documentação obrigatória, e direitos de propriedade intelectual definidos. Use contrato simples para projetos pequenos; use este para investimentos corporativos significativos.
Um contrato de suporte cobre correção de bugs e atualizações para software existente. Este acordo cobre desenvolvimento inicial, testes, aceitação e entrega. Use contrato de suporte após software estar aceito e em uso; use este para fase de desenvolvimento e lançamento.
Fornecedores de software e startups usam este acordo para formalizar projetos de desenvolvimento customizado com clientes corporativos.
Bancos e fintech encomendam desenvolvimento de plataformas de trading, gestão de riscos ou processamento de pagamentos sob contrato estruturado.
Empresas de e-commerce contratam desenvolvimento de sistemas de gestão de estoque, CRM ou integrações de pagamento com cronogramas rigorosos.
Hospitais e seguradoras encomendam sistemas de gestão de pacientes ou sinistros, exigindo segurança, conformidade regulatória e testes rigorosos.
Empresas industriais desenvolvem sistemas de manufatura, rastreamento de supply chain ou controle de produção com especificações técnicas complexas.
Universidades e agências governamentais encomendam plataformas de aprendizado, gestão administrativa ou portais de serviço público.
No Brasil, este acordo é regido pela Lei 9.610/1998 (direitos autorais de software) e Lei de Propriedade Intelectual. Certifique-se de que a cláusula de propriedade intelectual especifica se o cliente recebe propriedade total do código-fonte ou apenas licença de uso, conforme a lei brasileira. Impostos estaduais (ICMS, PIS, COFINS) sobre software podem ser reembolsáveis; detalhe na Tabela de Encargos.
Em Portugal, o acordo segue o Código do Direito de Autor e Direitos Conexos e Lei de Propriedade Industrial. Software desenvolvido sob contrato pode ser considerado obra por encomenda; deixe claro na cláusula de propriedade intelectual se transferência de direitos é total ou licença. IVA português é reembolsável conforme categoria de serviço; indique na Tabela B.
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Projeto de desenvolvimento com cronograma ajustado, orçamento limitado, sem questões incomuns de propriedade intelectual. | Gratuito ou baixo custo (apenas preço do modelo). | 1–2 horas para customização (nomes, prazos, valores, especificações). |
| Modelo + revisão jurídica | Projeto de médio a alto valor, transferência de propriedade intelectual crítica, jurisdição complexa ou entre países. | €200–€500 de revisão jurídica (pode poupar riscos muito maiores). | 2–3 dias para advogado revisar e sugerir ajustes específicos à sua situação. |
| Redigido sob medida | Projeto de alto valor (>€100k), software regulado (finança, saúde), direitos intelectuais únicos ou negociação complexa multi-jurisdição. | €1.500–€5.000+ de redação jurídica customizada. | 1–2 semanas para advogado redactar acordo completamente novo. |
Este documento é um dos 3,000+ modelos comerciais e jurídicos incluídos no Business in a Box.
Acesse mais de 3,000+ modelos empresariais e jurídicos para qualquer tarefa, projeto ou iniciativa.
Personalize seu modelo de documento empresarial pronto para uso e salve-o na nuvem.
Compartilhe seus arquivos e pastas com sua equipe. Crie um espaço de colaboração contínua.
"De um valor fantástico! Não sei o que faria sem essa plataforma. Vale cada centavo e valeu o investimento diversas vezes."
"Eu uso o Business in a Box há 4 anos. Tem sido a fonte mais útil de documentos que encontrei. Recomendo a todos."
"Salvou minha vida tantas vezes que eu perdi a conta. O Business in a Box me poupou muito tempo e, como você sabe, tempo é dinheiro."
Pare de baixar documentos. Comece a operar com clareza. Business in a Box fornece o sistema operacional usado por mais de 250.000 empresas no mundo para estruturar, gerenciar e expandir seu negócio.
Plano gratuito para sempre · Não exige cartão de crédito
