Home / Orientação da decisão do projecto / não há código de documento antigo
PROJECT DECISION GUIDE

Como é que se assume códigos antigos sem documentos?

A ausência de documentação não significa que o projecto não possa assumir o controlo, mas não se comprometa directamente com o desenvolvimento contínuo. O primeiro passo deve ser preservar códigos, contas, dados e ambientes operacionais e depois determinar o estado real através de uma auditoria giratória.

Responde à pergunta.

Nenhum documento antigo de código assume

O antigo sistema é geralmente dividido em preservação de ativos, restauração de construção, validação de operação, código e auditoria de dados, classificação de risco, reparação de perdas e restauração de conhecimento.

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.

01

Primeiro, salvar ativos digitais.

Confirma o controle sobre o armazém de código, servidor, número de conta na nuvem, banco de dados, nome de domínio, certificado, chave de terceiros, pacote de lançamento e backup recente.

02

Ambiente recuperável

Gravação de versões e dependências em execução, e tentativa de completar a construção e implantação em isolamento do servidor original.

03

Reconciliação da conclusão operacional

O rácio de conclusão baseia-se em processos empresariais reais e em verificações de aceitação, em vez de extrapolar o número de documentos ou de registos de apresentação.

04

Auditoria de áreas de alto risco

Foco em pagamentos, autoridade, consistência de dados, interfaces externas, falhas de segurança, gargalos de desempenho e processos de distribuição inrolláveis.

05

Desenvolvimento de um programa de eliminação em camadas

Os riscos de segurança de dados e de interrupção de negócios são abordados antes de a capacidade de divulgação ser restaurada e as obrigações técnicas, atualizações de arquitetura e documentação são finalmente organizadas.

06

Estabelecimento da fronteira da responsabilidade pós-apropriação

Identificar deficiências residuais, sistemas de terceiros, dados históricos e necessidades não satisfeitas e evitar o infinito de novas equipas que assumem a responsabilidade por questões desconhecidas.

Preparação de recomendações antes da comunicação ou avaliação

Repositório de código e versão operacional recenteProdução e ensaio do acesso ao ambienteAutenticação de backup e restauração de banco de dadosCertificados de nome de domínio e privilégios de conta na nuvemInterface de terceiros e atribuição de chavesProcessos empresariais principais e deficiências conhecidasRegistros online recentes e requisitos de tarefasContratos, protótipos e comunicações originais

Caminho sugerido para a implementação

A forma mais prudente é começar com um diagnóstico técnico independente, com uma lista de activos entregues, um relatório de auditoria, uma priorização do risco e um programa de aquisição.

DECISION WORKSHEET

Transformar o código antigo sem documentos em 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.

O que deve conter um resumo comparável das avaliações?

Pelo menos o armazém de codificação e a versão operacional recentemente, o acesso ao ambiente de produção e teste, o backup e restauração de autenticação, certificados de nome de domínio e privilégios de conta na nuvem, juntamente com uma indicação do volume de negócios atual, tempo médio de processamento, anomalias principais, sistemas existentes, privilégios de dados, dependência de terceiros e janelas de acesso. A mesma versão é fornecida a diferentes fornecedores e solicita que os pressupostos, exclusões, questões de cooperação com o cliente, entrega e aceitação de evidências sejam especificados separadamente, de modo a evitar comparar o preço total de apenas 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.

Pode assumir o comando da equipa original sem qualquer contacto?+

Uma avaliação é possível desde que a empresa tenha um mandato legal para códigos, contas, dados e sistemas e seja capaz de adquirir os ativos necessários. Quanto mais falta, maior o custo de recuperação e maior o risco operacional.

Como podemos ser julgados como reescritos ou continuados?+

Há necessidade de comparar os valores de negócios existentes, manutenção de código, riscos de migração de dados, ciclos de reescrita e continuidade de negócios. Muitos projetos são mais adequados para substituição modular do que uma capotagem única.

Pode comprometer-se a fixar preços brutos antes de assumir o controlo?+

O risco de código desconhecido não pode ser calculado apenas por descrição oral, mas deve ser sujeito a uma auditoria limitada antes de a oferta de recuperação e construção ser decidida.

DECISION FAQ

Questões comuns relacionadas com os projectos em curso

Confira todas as 265 perguntas.
Applets, APPs, SaaS e sistemas antigos

O projeto de software de cauda ruim e o código antigo podem ser tomados após a equipe de desenvolvimento original perder o contato?

A maioria dos projetos pode ser avaliada primeiro, mas não pode ser diretamente comprometida com a reparação sem conhecer os ativos e códigos. O primeiro passo é preservar código, servidor, banco de dados, nome de domínio, certificado e contas de terceiros de acordo com a lei, e depois restaurar o repertório de repertório e operação.

Ver resposta completa
Desenvolvimento de software e terceirização de projetos

Quanto 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 completa
Programa de arranque e selecção de programas

Por que as empresas de software precisam estudar as necessidades antes de poderem oferecer?

As ofertas de software não são baseadas em tamanhos de página simples, e regras de negócios, privilégios de funções, interfaces, migração de dados, desempenho, segurança e acesso podem afetar significativamente a carga de trabalho. A pesquisa de demanda é projetada para identificar esses drivers de custos e distinguir entre intervalos definidos e riscos desconhecidos. Sem pesquisa, preços baixos são muitas vezes compensados por mudanças subsequentes, menor qualidade ou a eliminação da entrega.

Ver resposta completa
Contratos, pagamentos, alterações e entrega de projetos

Que riscos podem ser escondidos do baixo preço da terceirização de software?

Os preços baixos podem surgir da reutilização de modelos, de escopos em falta, de falta de pessoal ou de dependência posterior em taxas de mudança, o que não representa necessariamente maior eficiência. O preço de comparar ofertas é harmonizar a demanda, interface, dados, testes, implantação, código fonte e calibre de manutenção. Especialmente preços baixos requerem explicações sobre papéis de equipe, carga de trabalho e exclusão.

Ver resposta completa