Gerenciamento de projetos em rede

Gerenciamento de projetos em rede

A viabilidade de certos projetos depende de trabalho em equipe. Projetistas diferentes trabalham em partes diferentes de um projeto em paralelo. Cada projetista deve produzir resultados (memoriais de cálculo, desenhos de formas e armação entre outros). O trabalho de cada um não deve se sobrepor ao do outro. Algumas partes do projeto dependem uma da outra, assim deve haver uma sincronização. A distribuição e a sincronização destes trabalhos depende de um coordenador, ou mais de um dependendo do projeto.

Quais as soluções para gerenciamento de projetos com os softwares e hardwares em uso?

Centralização e processamento do projeto no servidor

O avanço no hardware e nos sistemas operacionais permitiu a popularização de redes. Para evitar a duplicação de arquivos, centraliza-se os arquivos de projeto em uma máquina da rede (que chamaremos de servidor, em contrapartida às máquinas cliente ou local, de cada usuário). O sistema operacional permite mais de um usuário acessando o mesmo edifício no servidor, com certas restrições. Mas o acesso ao servidor precisa ser feito com cuidado, pois existem problemas difíceis de contornar.

Tempo de processamento no servidor

Boa parte das redes instaladas trabalha com taxas de 100 Mbit/s, ou 12 Mb/s. Mas a informação que transita pela rede é quebrada em pacotes e cresce com dados adicionais relativos ao protocolo. Dependendo da configuração da rede, cada byte transferido para a máquina cliente passa por outras máquinas e/ou hubs, switches e roteadores. Estima-se uma capacidade de transferência efetiva de apenas 20% da nominal, o que nos levaria a 2 Mb/s. Isto seria no máximo 5% da transferência de dados de um disco local, trabalhando tipicamente com 40 Mb/s. Mas existem outras perdas - a leitura e gravação de dados dependerá da CPU e do disco do servidor, que pode estar sendo partilhado por outros usuários da rede.

As tecnologias de 1Gbit/s estão se tornando acessíveis e deverão diminuir este problema. Mas mesmo uma rede 10 vezes mais rápida ainda é lenta comparada a capacidade local de processamento.

Do ponto de vista prático, processar projetos diretamente no servidor é uma ordem de grandeza mais demorado que processar diretamente no cliente.

Interferência entre arquivos de um projeto

Tanto o sistema operacional quanto o sistema TQS impedem a gravação de desenhos e modelos estruturais por mais de um usuário simultaneamente. Entretanto não impedem um problema mais comum, que é a gravação não simultânea. Após o usuário A editar um desenho de vigas, o usuário B pode rodar um processamento global e regravar desenhos de vigas sem que A saiba. A coordenação do uso de pastas de projeto tem que ser manual e cuidadosa.

Processamento local e sincronização manual com o servidor

Uma alternativa é usar o servidor unicamente com o objetivo de armazenar arquivos. Com isto aproveita-se a capacidade de processamento local, e mantém-se os dados centralizados no servidor.

Um coordenador deve gerenciar a sincronização de arquivos entre os usuários e o servidor. Existe a possibilidade de um projetista estragar desenhos gravados por outro no servidor, assim como a de sobrepor desenhos editados localmente com outros não editados do servidor.

O Serviço de Compartilhamento de Projetos TQS (SCP)

Estamos desenvolvendo o SCP como uma ferramenta simples para auxiliar a coordenação de projetos em rede. É fácil entender o seu funcionamento, pois apenas quatro regras são definidas:

  • Um projeto é definido por um e somente um edifício, que fica no servidor.
  • Cada projetista trabalha com uma cópia local do edifício.
  • Cada projetista gerencia (ou possui) um conjunto de pastas convencionadas do edifício. Somente os arquivos nestas pastas podem ser alterados. Nenhum outro projetista gerencia as mesmas pastas.
  • Ao sincronizar um edifício com o servidor, as pastas gerenciadas pelo projetista vão para o servidor, e as não gerenciadas vem do servidor para o local.

Todo o funcionamento do sistema é decorrente das regras acima. O SCP permite trabalhar na velocidade do computador local, e ao mesmo tempo desenvolver projetos em equipe usando a rede sem interferência entre os projetistas.

Funcionamento do SCP com um exemplo

Vamos gerenciar um edifício qualquer, por exemplo o MODPLA, que foi criado localmente por João. No início do projeto, João entrará com dados do edifício e poderá fazer pré-lançamento da estrutura. Somente João tem o projeto por enquanto. João chamará o SCP pelo gerenciador:

13cd764f2521d51e28b2a4f8f674a75b.png

O SCP apresenta duas janelas. Na janela à esquerda está a árvore de edifícios local, e na direita a árvore do servidor. Vemos que dois edifícios já estão sob controle do SCP no servidor. Ao selecionar o edifício MODPLA à esquerda, o botão "Liberar" se acende. Este botão transfere o controle de um edifício inteiro ou de uma pasta para o servidor.

122bc068a0344194617a854639c96739.png

Apertando "Liberar", o controle do edifício passará para o servidor:

f9ee9eef586f89f702e216e7a108ac91.png

Os ícones na árvore à esquerda mostram agora a situação do edifício MODPLA: é um edifício gerenciado pelo SCP, mas com todas as pastas travadas localmente, pois João não gerencia nenhuma.

Supondo que João queira alterar formas e armações de vigas no 4PAV, ele selecionará as pastas correspondentes à direita no servidor e apertará o botão "Gerenciar":

9a11c5e1659473a7284b1eb3779b07ac.png

O SCP mostra agora na árvore local as pastas 4PAV e Vigas correspondente com chaves verdes, indicando que os arquivos nesta pasta podem ser manipulados. Na árvore do servidor estas pastas são mostradas bloqueadas, com o nome de quem está gerenciando (na verdade o nome da máquina na rede) e a data de bloqueio.

Ao voltar ao gerenciador, os ícones do edifício MODPLA refletirão esta situação:

b0abdb4253147fb6d78057673c3cbf6b.png

Ao entrar no Modelador do MODPLA, João receberá o seguinte aviso:

d97ea5c0d018ddb2c385fa5326db2996.png

Se tentar editar desenhos em pastas não gerenciadas, o editor gráfico não permitirá o seu salvamento:

b930fba84f9a25f806f7d3115e33dbfb.png

Maria, outra projetista, pode entrar na rede e gerenciar a pasta 3PAV.

940970cbbe401efbe28b774070a4ca7d.png

Esquematicamente teríamos:

9a315e6eaa6396e721fc0b0079348dbc.png

Qualquer projetista pode entrar na rede e tomar posse de pastas ainda não gerenciadas de um projeto. Um projeto só pode ser gerenciado globalmente por um único projetista se nenhuma pasta estiver gerenciada.

Operações que João pode fazer no SCP

João poderá agora:

  • Gerenciar mais pastas. No exemplo, são todas menos as já gerenciadas (4PAV, 4PAV\Vigas e 3PAV).
  • Liberar uma pasta gerenciada para a rede (a 4PAV ou a 4PAV\Vigas). Após a liberação, outro projetista pode gerenciar estas pasta.
  • Sincronizar os arquivos da rede com o servidor. Todas as pastas, menos as gerenciadas serão copiadas do servidor para o local.
  • Sincronizar arquivos do local para o servidor. Somente as pastas gerenciadas são copiadas para o servidor.

Na verdade as operações de gerenciamento e liberação também fazem sincronização de pastas. O SCP compara datas e tamanhos de arquivos na rede e no cliente e somente efetua a cópia de arquivos modificados, de maneira a não sobrecarregar a rede. Todos os arquivos copiados são mostrados em uma janela de mensagens.

Funcionamento de um edifício gerenciado

Foram implantadas travas nos edifícios gerenciados pelo SCP de modo a manter coerência com o trabalho na rede. As regras do SCP implicam nas operações:

  • Só é possível editar desenhos em pastas gerenciadas.
  • Só é possível editar critérios em pastas gerenciadas. Para editar critérios comuns do edifício, é necessário gerenciar todo o edifício.
  • Para editar os dados do edifício (modelo estrutural, lista de pavimentos, etc), é necessário gerenciar todo o edifício.
  • A edição de plantas só permite a inclusão de desenhos de pastas gerenciadas.
  • Só é possível editar o modelo estrutural do edifício das pastas gerenciadas.
  • Para editar pilares e elementos inclinados no Modelador, é necessário gerenciar também a pasta Espacial.
  • Para fazer processamento global, é necessário gerenciar todo o edifício.

Projetistas diferentes podem trabalhar em pavimentos diferentes no Modelador Estrutural, inclusive com pilares. Após a sincronização dos arquivos na rede, pode ser necessário acionar o comando "Refazer intersecções" para que os elementos na planta reinterceptem elementos espaciais modificados por outros projetistas.

Duplicando um edifício gerenciado

O SCP coloca limitações que as vezes podem atrapalhar o projetista. No meio do projeto ele pode decidir fazer novas simulações e alterar dimensões de elementos estruturais. Mas o projeto está em andamento e existem pastas gerenciadas e outros projetistas trabalhando. Como fazer?

Um edifício gerenciado pode ser duplicado pelo comando "Duplicar", dentro da Edição de Dados do Edifício. Os edifícios duplicados são completamente liberados para edição e processamento global. Entretanto, o SCP marca os edifícios duplicados, e não permite que sejam gerenciados no servidor. Isto evita a confusão que acontece em alguns escritórios de projeto, quando múltiplos modelos de um mesmo projeto são mantidos e partilhados, e em um dado momento não se conhece de qual modelo deve ser gerada uma planta para ser enviada à obra.

Como o projeto é um modelo de uma construção única, o projetista deve se disciplinar e gastar tempo, para manter um único modelo que oficialmente representa esta construção. Este modelo está no servidor e pode ser gerenciado pelo SCP.

Os eventos de sincronização

A partir do momento em que todos os projetistas de um projeto tem uma cópia do edifício, cada um começa a modificar a sua parte, e todos de certa forma começam a ficar com sua cópia desatualizada. É preciso de tempos em tempos sincronizar os arquivos para que todos tenham informação atualizada. A sincronização deve ser feita, manualmente, em duas etapas através do SCP:

  • Todos sincronizam suas pastas gerenciadas do local para o servidor. Neste momento o servidor fica atualizado.
  • Todos sincronizam do servidor para o local. Todos as cópias locais ficam atualizadas.

A decisão do momento de sincronização pode partir do coordenador de projeto, que marca os dias ou horas onde deve acontecer, ou de um projetista para outro, solicitando um desenho para ser usado como referência.

Mensageiro-TQS

Já que os projetistas precisam comunicar entre si inclusive para solicitar sincronização, disponibilizamos junto com o SCP um programa de comunicação em rede, chamado de "Mensageiro-TQS". Este programa permite comunicação instantânea entre um projetista e outro através dos computadores da rede, e é utilizado há vários anos dentro da TQS:

cf3b214427db224306e7a58cef0e4ed8.png

Histórico das operações

O SCP armazena por edifício o histórico de todas as operações realizadas, com data, hora, usuário e operação.

27bc9bbdea00a9350f46a675920b2a84.png

Consultando o histórico por exemplo, pode-se decidir se é possível fazer o backup do edifício ou se falta a sincronização de projetistas que tem pastas gerenciadas.

Controle de Emissão de Plantas (CEP)

Aproveitando a centralização de dados na rede, estamos agregando também ao SCP um sistema de Controle de Emissão de Plantas, o CEP. Após os eventos de edição de plantas e plotagem, o gerenciador chama automaticamente o CEP e inclui as plantas editadas e/ou plotadas.

23f817986d1d8b557af43c9e51dcdd21.png

Além dos dados das plantas emitidas como data e hora, são armazenadas informações de todos os desenhos nas plantas e respectivas datas de modificação. Outras informações podem ser definidas pelo projetista em cada planta, tais como quaisquer observações a respeito de revisões e outras.

e082da60df4b7000904955812afb63d6.png

Finalmente, o CEP emitirá um protocolo de entrega por planta, que poderá ser usado pelo projetista como um documento associado à entrega efetiva ao contratante. O CEP poderá ser acionado também a partir do SCP.

Resolvendo perdas de arquivos

O SCP não impede acesso à rede. Arquivos podem ser acidentalmente perdidos ou sobrepostos por outros através de manipulação direta com o Windows Explorer por exemplo. Discos podem ser destruídos por vírus. Mas existem meios de minimizar este tipo de problema.

Com os projetos centralizados no servidor, é obrigatório um bom esquema de backups diários. Preferencialmente estes backups devem ser permanentes e por projeto, de maneira que um projeto (ou mesmo um único desenho) possa ser restaurado em uma data específica em caso de erro.

Projetistas que trabalham em parte do projeto e não querem sincronizar arquivos para o servidor enquanto não terminarem, devem fazer backup local para não correrem riscos de perder o trabalho de um dia. Eles próprios devem ser responsáveis pelo seu trabalho.

Apesar de parecer paranóia, é conveniente que os backups sejam armazenados fora e longe da empresa.

Instalação e configuração

O SCP será instalado automaticamente junto com o TQS versão 13. Na primeira utilização, defina dentro do SCP a pasta do servidor onde os projetos TQS serão compartilhados.

Apesar do SCP tratar de um serviço, na primeira versão não será formalmente um serviço rodando no servidor, mas um sistema local que acessa o servidor. Com isto, teremos automaticamente compatibilidade tanto com servidores baseados em Windows quanto em Linux.

Discussão final

Com o SCP é possível utilizar toda a capacidade de processamento local sem carregar o servidor, que é solicitado apenas nos momentos de sincronização de arquivos.

O SCP não pretende resolver todas as necessidades de projeto em equipe, mas automatizar e controlar parte das tarefas em rede, minimizando as operações manuais e arriscadas. O bom uso do SCP depende principalmente de medidas de coordenação que devem ser previstas em qualquer projeto em equipe.

Abram Belk - TQS Informática