Quais são os problemas legais relacionados com o servidor e infraestrutura do desenvolvimento de sistemas?

Os sistemas de TI utilizados nas empresas são, de certa forma, criados através da elaboração de especificações e desenhos, e da escrita do código-fonte correspondente a esses conteúdos. No entanto, não é apenas este aspecto “soft” que importa, mas também a infraestrutura física, ou seja, os computadores, que permitem que o sistema funcione efetivamente. Neste artigo, vamos discutir questões legais profundamente relacionadas com a área de infraestrutura em projetos de desenvolvimento de sistemas.

O que é a infraestrutura em sistemas de TI

Os técnicos que desenvolvem sistemas são chamados de engenheiros de sistemas (SE). E um projeto de desenvolvimento começa com processos a montante, como a criação de especificações e documentos de design, e segue com a implementação do programa e a realização dos seus testes. No entanto, um engenheiro de sistemas (SE) no sentido mais amplo pode ser descrito como um técnico que assume todas as tarefas necessárias para isso, embora em algumas empresas e locais de trabalho, os nomes possam ser diferenciados de acordo com as tarefas e áreas de responsabilidade. O termo engenheiro de infraestrutura refere-se a técnicos que, como parte do trabalho de desenvolvimento e operação de sistemas de TI, estão particularmente envolvidos na configuração do ambiente operacional físico do computador. Os sistemas de TI usados em empresas e locais de trabalho são, de certa forma, construções abstratas formadas pela combinação de códigos-fonte. No entanto, para que esses sistemas desempenhem o papel esperado, é essencial a construção do ambiente em torno da infraestrutura, incluindo servidores e redes. A prática de desenvolvimento de sistemas avança com a implementação do código-fonte do programa e a configuração do ambiente em torno da infraestrutura que suporta o ambiente operacional. Esta perspectiva é considerada importante para prevenir a ocorrência de problemas imprevistos.

Quais são as situações concretas em que problemas de infraestrutura podem incendiar um projeto?

Na realidade, pode acontecer que, num projeto de desenvolvimento de sistemas, se concentre apenas no design abstrato de programas e códigos-fonte, negligenciando a perspectiva da manutenção da infraestrutura. No entanto, se os dois não estiverem alinhados, isso pode representar um risco de incêndio para o projeto.

Quais são os casos em que erros de dimensionamento do servidor causam conflitos?

Por exemplo, pode acontecer que, após a implementação e teste de todos os programas, se descubra que a capacidade de processamento do servidor é insuficiente e o sistema não é prático. Além disso, a manutenção da infraestrutura de acordo com a escala do sistema, prevendo o quanto de carga o sistema pode suportar na fase de operação, é chamada de “dimensionamento”. Há casos reais em que erros de dimensionamento do servidor causaram problemas. (Embora tenha sido resolvido por meio de um acordo, este caso pode ser usado como referência.) Além disso, para os conflitos entre as duas partes, explicamos em detalhe o método de resolução chamado “acordo” no seguinte artigo.

O fato de o conflito ter sido resolvido por meio de um acordo significa, em termos simples, que o conflito foi resolvido por meio de uma “discussão” entre as duas partes. Portanto, ao contrário de quando uma sentença é proferida por um tribunal, o conteúdo do acordo não é acumulado como precedente, mas geralmente é altamente individual.

A essência do caso é o escopo da obrigação do fornecedor de responder a especificações não claras

No entanto, a essência desses conflitos pode ser considerada como “até que ponto o fornecedor deve assumir a responsabilidade por questões que não são explicitamente especificadas”. Considerando este ponto, você pode obter muitas dicas do conteúdo do seguinte artigo.

https://monolith.law/corporate/system-development-specs-function[ja]

No artigo acima, explicamos até que ponto o fornecedor deve exercer discrição e assumir a obrigação de implementação para coisas que não estão escritas na especificação. Aqui, explicamos que a história é muito diferente entre os itens “lado da tela” que podem ser facilmente visualizados em documentos de definição de requisitos e documentos de design básico (a chamada área “front-end”) e o “lado da lógica” como migração de dados (a chamada área “back-end”, “banco de dados”). Em outras palavras, é provável que a área “lado da tela”, onde os problemas de especificação podem ser facilmente verificados pelo cliente/usuário (que geralmente não tem conhecimento especializado em projetos de desenvolvimento de sistemas), seja mais propensa a ser atribuída ao cliente/usuário. Por outro lado, é provável que os problemas do “lado da lógica” sejam mais propensos a serem atribuídos ao fornecedor. Considerando esses pontos, é provável que os problemas de dimensionamento do servidor, que são difíceis de reconhecer a menos que se seja um especialista em tecnologia, sejam mais propensos a serem atribuídos ao fornecedor. Portanto, a menos que haja circunstâncias ativas para isentar o fornecedor de responsabilidade, se este ponto for seriamente contestado em tribunal, é provável que a decisão seja desfavorável ao fornecedor.

Medidas para prevenir problemas devido a erros no dimensionamento do servidor

Para prevenir problemas como os mencionados anteriormente, é importante alinhar as tarefas de implementação do programa e descrição do código-fonte com a preparação do ambiente em torno da infraestrutura. As medidas que podem ser consideradas incluem as seguintes:

Clarificar a responsabilidade do dimensionamento do servidor no contrato

Não apenas nestes casos, mas muitos dos conflitos relacionados a projetos de desenvolvimento de sistemas surgem quando as responsabilidades não estão claramente definidas entre o fornecedor, que é o especialista em desenvolvimento de sistemas, e o usuário, que está familiarizado com a situação interna da empresa. Embora seja desnecessário dizer que a estreita colaboração entre as duas partes é necessária para o progresso suave do projeto, seria desejável esclarecer o máximo possível as responsabilidades e o âmbito de responsabilidade no contrato antecipadamente.

Concretizar os requisitos de desenvolvimento e gerir completamente as alterações

Além disso, se os requisitos funcionais a serem realizados forem vagos, o risco de conflitos aumenta. Isso envolve tanto a clarificação das especificações na fase de definição de requisitos iniciais quanto a gestão de alterações durante o projeto. Quanto à forma de lidar com as alterações de especificações durante o projeto, explicamos em detalhe no seguinte artigo.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Escolher um modelo de desenvolvimento adequado à natureza do projeto

Além disso, relacionado profundamente com as duas medidas acima, é importante escolher o modelo de desenvolvimento adequado para a natureza e escala do projeto de desenvolvimento do sistema. Em geral, para o desenvolvimento de sistemas de uma certa escala, onde o dimensionamento do servidor pode ser importante, os benefícios de adotar o modelo waterfall, que é adequado para a clarificação de especificações e âmbito de responsabilidade, aumentam. Quanto à escolha do modelo de desenvolvimento adequado, tendo em conta a natureza do projeto, explicamos em detalhe no seguinte artigo.

Resumo

Para o progresso suave de um projeto de desenvolvimento de sistema, os problemas que surgem na preparação do ambiente em torno da infraestrutura são pontos que facilmente podem ser negligenciados. É considerado que não é uma tarefa pequena para quem não é um especialista em tecnologia prestar atenção até aos problemas da infraestrutura. No entanto, as medidas preventivas para tais problemas podem ser consideradas como uma extensão de medidas muito básicas, como “esclarecimento das especificações / gestão rigorosa das alterações”, “esclarecimento das funções / âmbito de responsabilidade”, e “seleção de um modelo de desenvolvimento adequado ao tamanho e orçamento do projeto”. O ponto que as pessoas envolvidas nos assuntos jurídicos da empresa devem entender primeiro é que os fundamentos da prevenção jurídica podem ser suficientemente aplicados aos problemas da infraestrutura. Além disso, para os engenheiros de TI, é importante entender que os problemas da infraestrutura podem se tornar um risco sério para o projeto e gerir eficientemente o trabalho.