Problemas legais associados à transição de sistemas antigos em desenvolvimento de sistemas

Criar um novo sistema de TI para uso empresarial é uma tarefa típica de um engenheiro de TI. No entanto, quando falamos em “criar um novo sistema”, muitas vezes isso também implica “abolir o sistema que estava a ser usado até agora”. Neste artigo, vamos abordar o projeto de desenvolvimento de um novo sistema a partir da perspetiva da “abolição do sistema antigo” e discutir as várias questões legais associadas a este processo.

O que significa a transição para um novo sistema

A vida útil de um sistema de TI não é eterna

Um sistema de TI usado numa empresa não é algo que, uma vez criado, possa ser usado continuamente para sempre. Além disso, não é necessariamente bom continuar a usar algo antigo indefinidamente. Embora haja variações dependendo da empresa e do uso do sistema, como uma regra geral, existe uma tendência para a decisão de gestão de que é melhor renovar para algo novo depois de usar um sistema por cerca de 10 anos.

Em 10 anos, o desempenho dos computadores disponíveis no mercado muda drasticamente. Por exemplo, um programa que não era viável de implementar devido a restrições como a velocidade de processamento do computador há 10 anos (embora seja um design simples e excelente do ponto de vista humano) pode agora ser implementado. Além disso, se você tem usado algo continuamente por 10 anos desde que foi criado, o fluxo de trabalho do negócio da empresa e as regras internas podem ter mudado bastante durante esse tempo. O código que foi implementado posteriormente para responder às mudanças no ambiente de gestão interno e externo da empresa pode ter se tornado tão complexo e intrincado que não pode ser reconhecido a partir do lado da tela. Neste ponto, mesmo que os usuários queiram adicionar funções, pode chegar a um ponto onde a implementação adicional é impossível do ponto de vista do desenvolvedor.

Os sistemas antigos podem gradualmente gerar muito “trabalho manual” para os engenheiros de TI (como a emissão de consultas para extrair dados individualmente). Ironicamente, o próprio sistema, à medida que envelhece, começa a “personalizar” o trabalho. Quando se tenta implementar medidas de “sistematização” para tarefas relacionadas ao sistema que se tornaram muito personalizadas devido ao envelhecimento, surge um projeto para o desenvolvimento de um “novo sistema para a transição do sistema antigo”.

O desenvolvimento do novo sistema avança juntamente com a abolição do sistema antigo

Como mencionado anteriormente, muitos projetos de desenvolvimento de sistemas (embora nem todos) envolvem a transição do sistema antigo para o novo. Muitas vezes, o próprio sistema muda de forma descontínua num determinado dia.

Contudo, o progresso do trabalho diário deve ser contínuo, do passado para o presente e do presente para o futuro. Enquanto se armazena os dados necessários do passado, o progresso do trabalho atual não deve ser interrompido, e muitas vezes existem vários desafios associados à transição para um novo sistema, como a apresentação de um conceito superior de “sistematização” para o futuro. Devido à combinação destas circunstâncias, o desenvolvimento de novos sistemas e as operações e manutenção de sistemas existentes estão complexamente interligados, e podem surgir situações em que se tornam inseparáveis.

Quais são os passos para a transição para um novo sistema?

Ao fazer a transição de um sistema antigo para um novo, é especialmente importante garantir que os dados sejam transferidos corretamente. Os passos para a transferência de dados geralmente seguem o seguinte procedimento:

1. Identificar quais dados armazenados no sistema antigo devem ser transferidos para o novo sistema → Deve-se esclarecer quais dados devem ser facilmente pesquisáveis a partir do ecrã do novo sistema, e quais dados, embora não precisem ser pesquisáveis a partir do ecrã, devem ser recuperáveis conforme necessário (por exemplo, para auditorias).
2. Exportar os dados identificados no passo 1 que devem ser importados para o novo sistema, em formatos como CSV.
3. Importar os dados extraídos no passo 2 para o novo sistema.
4. Verificar se os dados importados no passo 3 estão a ser refletidos no novo sistema e confirmar se a transferência foi realizada corretamente. → Os resultados da verificação da transferência correta são normalmente documentados através de ecrãs de exibição ou impressões de relatórios (o chamado processo de teste).

A transição para um novo sistema é difícil devido à necessidade de clarificar os papéis dos utilizadores e fornecedores

Numa das etapas da migração de dados mencionada anteriormente, um problema comum é determinar até que ponto o lado do utilizador deve considerar isso como um problema interno e mantê-lo sob controlo. Além disso, para uma visão geral das “obrigações de cooperação do utilizador” em projetos de desenvolvimento de sistemas em geral, não apenas na migração de dados, consulte o artigo abaixo.

https://monolith.law/corporate/user-obligatory-cooperation[ja]

Em termos gerais, num projeto de desenvolvimento de sistemas, é verdade que o fornecedor muitas vezes tem uma vantagem sobre o utilizador em termos de conhecimento especializado para o desenvolvimento do sistema (ou, mais precisamente, muitas vezes é por isso que lhe é atribuída a tarefa). No entanto, por outro lado, muitas vezes só o lado do utilizador pode discutir como deve ser o “estado ideal” do seu sistema.

Com isso em mente, pode-se considerar que os passos 1 e 4 mencionados anteriormente são realizados pelo utilizador. Para colocar de outra forma, durante a migração de dados, a “definição de requisitos” dos dados a serem migrados e a “aceitação” de se os dados foram migrados de acordo com os requisitos podem ser organizados como obrigações de cooperação do utilizador. Ou, como outra forma de organização, se houver alguém no lado do utilizador com um conhecimento profundo do antigo sistema, pode-se considerar que o passo 2 também é da responsabilidade do utilizador.

Se for possível lidar com o antigo sistema internamente sem ter que recorrer à subcontratação, pode-se considerar a possibilidade de encomendar apenas o novo sistema ao fornecedor. Neste formato, na migração de dados, os papéis dos utilizadores e fornecedores podem por vezes tornar-se ambíguos. Além disso, quando o utilizador subcontrata tarefas relacionadas ao desenvolvimento de sistemas ao fornecedor, para uma explicação geral sobre que tipo de papel é esperado do fornecedor e que tipo de obrigações legais são atribuídas, consulte também o artigo abaixo.

https://monolith.law/corporate/project-management-duties[ja]

Precedentes judiciais relacionados com a transição para novos sistemas

Existem casos reais em que problemas surgiram em projetos de desenvolvimento de sistemas com o objetivo de transição para um novo sistema, levando a processos judiciais. O caso citado na sentença abaixo envolveu falhas no trabalho de transição de dados, resultando em inconsistências e bugs em vários dados no novo sistema, bem como atrasos na entrega. A questão em disputa era quais obrigações o fornecedor e o usuário tinham em relação ao projeto. Em conclusão, o tribunal determinou que o fornecedor tinha a obrigação de cuidado, conforme descrito abaixo, e reconheceu a violação dessa obrigação por parte do fornecedor.

O réu, no âmbito do contrato de empreitada para a transição de dados, tinha a obrigação de não apenas transferir os dados do antigo sistema para o novo sistema, mas também de operar o novo sistema com os dados transferidos. Em particular, antes de iniciar o trabalho de transição de dados, deveria ter investigado e analisado os dados que seriam transferidos do antigo sistema, compreendido a natureza e o estado dos dados, considerado se esses dados poderiam impedir a operação do novo sistema após a transferência, e, se fosse o caso, decidido quando e como corrigir esses dados. Finalmente, tinha a obrigação de operar o novo sistema com os dados transferidos do antigo sistema.

É apropriado reconhecer que, neste caso, tinha a obrigação de corrigir e resolver inconsistências de dados durante a transição de dados.

Decisão do Tribunal Distrital de Tóquio, 30 de novembro de 2016 (Ano 28 da era Heisei)

Este caso envolveu uma divisão de papéis em que o usuário assumiu as etapas 1 e 4, e o fornecedor assumiu as etapas 2 e 3. Ou seja, o fornecedor assumiu a extração de dados do antigo sistema. Portanto, o tribunal decidiu que, se o fornecedor, como especialista em desenvolvimento de sistemas, assumiu a extração de dados, deveria ter considerado antecipadamente se o trabalho de extração de dados poderia ser realizado sem problemas.

No entanto, o que teria acontecido se a etapa 2 (ou seja, a extração de dados) tivesse sido atribuída ao usuário e a extração de dados tivesse falhado? Neste caso, é possível que o usuário pudesse ser acusado de violar a obrigação de cooperação por negligenciar a investigação preliminar sobre se a extração de dados poderia ser realizada sem problemas, resultando em atrasos na entrega.

Além disso, tais decisões são baseadas não apenas em contratos, mas também em atas de reuniões que acompanham o progresso do desenvolvimento do sistema. A importância das atas de reuniões é explicada em detalhes no artigo abaixo.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Resumo

Um projeto de desenvolvimento de sistema implica que tanto o lado do usuário quanto o do fornecedor assumam muitas obrigações, avançando enquanto mantêm uma comunicação cuidadosa. Portanto, mesmo nos casos judiciais mencionados anteriormente, apenas uma pequena mudança nas condições prévias pode facilmente reverter a responsabilidade para qualquer lado, seja o usuário ou o fornecedor.

Considerando a possibilidade de um sistema conter uma quantidade enorme de dados e mecanismos complexos, que não podem ser imaginados a partir da aparência da interface, e a possibilidade de uma pequena diferença nas premissas alterar significativamente o resultado do julgamento judicial, pode-se dizer que é importante gerir de forma abrangente os riscos do projeto de desenvolvimento do novo sistema, juntamente com a eliminação do sistema antigo.