Correspondência de Negócios
Use processos reais para verificar o quanto o núcleo precisa que o sistema de código aberto possa cobrir, não apenas a lista de funcionalidades e a página de apresentação.
Home / Orientação decisão do projeto / Desenvolvimento de personalização e adaptação de código aberto
PROJECT DECISION GUIDEDesenvolver a partir de zero adaptação personalizada ou de código aberto baseada no sistema
As modificações de código aberto podem não ser mais baratas ou mais gerenciáveis a partir de zero. A chave é julgar a correspondência entre as capacidades de código aberto existentes e as operações-alvo, bem como as futuras atualizações e custos de manutenção.
Responde à pergunta.
Desenvolvimento personalizado e adaptação de código aberto
Quando os processos principais são comuns, os projetos de código aberto são maduros e as licenças são compatíveis com modelos de negócios, adaptações baseadas em sistemas de código aberto podem encurtar o primeiro ciclo; quando as regras de negócio constituem competitividade central, as restrições de estrutura são claras ou a profundidade das adaptações pode ser prolongada longe das versões comunitárias, geralmente é mais apropriado personalizar a partir de zero.
DECISION FACTORS
Elementos-chave a controlar para a tomada de decisões
Em primeiro lugar, identificam-se os limites da contenção e da responsabilidade, depois comparam-se as vias técnicas e as modalidades de cooperação.
Licenciamento e modelo de negócio
Avaliando os limites permitidos de uso, modificação, distribuição, serviços SaaS, marcas comerciais e componentes de confiança, sujeitos a revisão por profissionais legais, conforme necessário.
Modificar profundidade
Interfaces, marcas e um pequeno número de extensões de processo são geralmente menos arriscadas; grandes mudanças nos modelos de dados principais e estruturas de fundo podem enfraquecer as vantagens do programa de código aberto.
Atualizar o Caminho
É preciso esclarecer quem é responsável pelas atualizações de versão comunitária, correções de segurança, consolidação de ramificação personalizada e testes de regressão automatizados.
Competências de equipa e tomada a cargo
Devem ser seleccionadas ou escolhidas qualquer rota, devendo ser obtidos códigos-fonte, instruções de implantação, migração de dados, interfaces e documentos de transporte.
Custo total de propriedade
Compare o desenvolvimento, licenciamento, recursos na nuvem, upgrades, mobilidade, segurança e custos de pessoal por pelo menos três anos, em vez de confiar na primeira oferta.
Preparação de recomendações antes da comunicação ou avaliação
Processos de negócio-alvo e funções diferenciaisActividade do projecto candidato de código abertoLicenças e componentes de baseEstrutura e combinação de âncora técnicaGanhos de segurança e mecanismos de actualizaçãoPontos de extensão do desenvolvimento secundárioAtualizar a versão e política de ramificaçãoCusto total de três anos de propriedade
Caminho sugerido para a implementação
Recomenda-se que seja efectuada uma ronda de selecção e análise das lacunas, com a procura de produção que abranja a matriz, o risco de licença, a lista de adaptação, a estratégia de actualização e a comparação dos custos das duas rotas, antes de ser tomada uma decisão sobre a criação de um projecto.
DECISION WORKSHEET
Desenvolvimento de personalização e adaptação de código aberto para tomada de decisão executória
As seguintes planilhas ajudam as empresas a organizarem conselhos vagos em insumos de fornecedores, de aprovação interna e de recebimento de projetos.
Correspondência de Negócios
Use processos reais para verificar o quanto o núcleo precisa que o sistema de código aberto possa cobrir, não apenas a lista de funcionalidades e a página de apresentação.
Se o factor se mantiver incerto, deve ser organizada uma validação diagnóstica ou em pequena escala e não é adequado incluir directamente a gama de preços fixa não variável.
Licenciamento e modelo de negócio
Avaliando os limites permitidos de uso, modificação, distribuição, serviços SaaS, marcas comerciais e componentes de confiança, sujeitos a revisão por profissionais legais, conforme necessário.
Se o factor se mantiver incerto, deve ser organizada uma validação diagnóstica ou em pequena escala e não é adequado incluir directamente a gama de preços fixa não variável.
Modificar profundidade
Interfaces, marcas e um pequeno número de extensões de processo são geralmente menos arriscadas; grandes mudanças nos modelos de dados principais e estruturas de fundo podem enfraquecer as vantagens do programa de código aberto.
Se o factor se mantiver incerto, deve ser organizada uma validação diagnóstica ou em pequena escala e não é adequado incluir directamente a gama de preços fixa não variável.
O que deve conter um resumo comparável das avaliações?
No mínimo, os processos de negócio-alvo e as funções de discrepância, a atividade de projetos de código aberto candidatos, licenças e dependência em componentes, arquitetura e tecnologia ancoram correspondência, descrevendo o volume atual de negócios, tempo médio de processamento, anomalias principais, sistemas em vigor, privilégios de dados, dependência de terceiros e janelas de acesso. A mesma versão de informação é fornecida a diferentes fornecedores e descrições separadas de pressupostos, exclusões, questões de cooperação com o cliente, entrega e aceitação de provas são necessárias para evitar comparar apenas o preço total de uma fronteira em falta.
Por exemplo, a empresa espera que o projeto economize 160 horas de trabalho por mês, mas este valor deve ser dividido em número de tarefas, economia de tempo única, taxas de adoção e razões de revisão manual. Se apenas 40% dos usuários usarem o primeiro período, ou se o novo processo aumentar o processo de revisão, os benefícios reais serão significativamente menores do que a estimativa aparente.
Quatro tipos de evidência recomendada para interrogatório durante a comunicação do fornecedor
A primeira é a evidência de escopo: consistência de versões de demanda, processos de negócios, protótipos, interfaces e exclusões; a segunda é a evidência de engenharia: se tecnologias semelhantes têm estruturas acessíveis, métodos de gerenciamento de código, testes, implantação e gerenciamento de problemas; a terceira é a evidência de pessoal: se os participantes reais, estágios de entrada, responsabilidades e mecanismos de substituição são claros; e a quarta é a evidência de entrega: como códigos fonte, dados, números de conta, documentos, treinamento, garantia de qualidade e transporte são entregues. É normal que os fornecedores não possam fornecer confidencialidade ao cliente na fase de licitação, mas devem ser capazes de explicar seus próprios métodos e as evidências que podem ser desenvolvidas no âmbito deste projeto.
Recomenda-se que a clareza do âmbito, a confiança crítica, a capacidade da equipa, a aplicabilidade da aceitação e a aquisição a longo prazo sejam avaliadas separadamente e que a base para cada pontuação seja registada. Se um programa for mais barato, a interface, migração, testes ou responsabilidade em linha é excluída, então deve ser convertido para o mesmo calibre de entrega antes da comparação.
O princípio do acórdão
Esta página fornece um quadro de tomada de decisão que não constitui uma oferta fixa ou compromisso de desempenho.
FAQ
FAQs
As questões mais comuns antes da cooperação são claramente indicadas com antecedência.
Um sistema de código aberto é igual a livre?+
Os custos da licença de código podem ser nulos, mas são necessários dados de engenharia para a seleção, implantação, adaptação, migração de dados, segurança, atualização e transporte.
Quanto mais sistemas de código aberto forem alterados, melhor?+
Não. A capacidade de alcançar diferenças através de plugins, configurações e extensões deve ser reduzida, reduzindo intrusões em códigos centrais para reduzir o custo de atualizações subsequentes.
Podes refazer primeiro e depois reescrever?+
Sim, mas desde o início, os dados, as interfaces e as fronteiras operacionais têm de ser planeados para evitar serem especificamente orientados para a migração futura.
DECISION FAQ
Confira todas as 265 perguntas.Questões comuns relacionadas com os projectos em curso
Applets, APPs, SaaS e sistemas antigos
Devem os sistemas empresariais ser desenvolvidos a partir de zero ou de sistemas de código aberto numa fase secundária?
Os processos são comuns, os produtos de código aberto maduros e as licenças permitem o desenvolvimento secundário. Quando as diferenças de negócio, as limitações de arquitetura de base ou os custos de atualização de longo prazo são elevados, pode ser mais apropriado desenvolver a partir de zero.
Ver resposta completaPrograma de arranque e selecção de programasComo devem ser selecionados sistemas de código baixo, código aberto e desenvolvimento personalizado?
O código baixo é adequado para processos que são claros, modificáveis e capazes de plataforma para cobrir aplicações internas mais elevadas; sistemas de código aberto são adequados para produtos de área madura, que podem atender à demanda através da configuração e desenvolvimento secundário; personalizar o desenvolvimento de projetos que são adequados para processos diferenciados, integração complexa, desempenho ou requisitos de controle de produtos mais elevados. A seleção é feita com uma comparação do custo total e capacidade de saída por três a cinco anos, em vez de apenas com o primeiro preço. As empresas também podem usar rotas de combinação, permitindo que diferentes tecnologias assumam o limite de negócios mais adequado.
Ver resposta completaDesenvolvimento de software e terceirização de projetosQuanto custa o desenvolvimento de software personalizado?
O software personalizado não tem um preço uniforme baseado no tamanho da página, e os custos são determinados principalmente pelo escopo, interface, dados, autoridade, desempenho e prestação de contas para entrega. O sistema de gestão com o mesmo nome pode ser uma ferramenta de um único setor ou uma conexão com ordens, inventário, finanças e autoridade multiorganizacional. Recomenda-se que o primeiro negócio fechado loop e recepção e inspeção limites de inspeção, e que o produto, design, desenvolvimento, testes, implantação e manutenção de carga de trabalho sejam estimados. Qualquer preço total preciso dado sem conhecimento da necessidade seja considerado apenas como uma referência de marketing.
Ver resposta completaPrograma de arranque e selecção de programasOs requisitos de software estão incompletos, então podemos ter uma empresa externa para avaliá-los?
É possível, e se a demanda estiver incompleta, fazer um diagnóstico de necessidades limitadas primeiro, em vez de exigir diretamente um preço total fixo. Uma empresa simplesmente precisa indicar seu background de negócios, usuários alvo, problemas atuais, tempo para ir on-line e orçamentos disponíveis.
Ver resposta completaRELATED
Apresentação da avaliação dos projectosMantenha o seu conhecimento dos serviços
Relevante
Comercialização de sistemas de código aberto
Compreender a seleção, implantação privada, desenvolvimento secundário e atualização a longo prazo
Para mais informações.RelevanteDesenvolvimento de Software de Negócios
Compreensão dos processos de negócio até a entrega completa da fonte
Para mais informações.RelevanteApresentação de informações de avaliação seleccionadas
Objectivos, estatuto e projectos candidatos de código aberto
Para mais informações.