Idea Transcript
More Next Blog»
Create Blog Sign In
Blog do Walter Comentários sobre desenvolvimento de software envolvendo Melhoria de Processos, MDA, Andromda, JavaEE e tecnologias relacionadas.
domingo, 5 de novembro de 2017
Sobre o blog
Diminuindo a Complexidade da Automatização de Testes Os testes funcionais são os mais importantes e também os mais difíceis de se automatizar Em tese basta adotar uma ferramenta de automatização, escrever os scripts e colocar para rodar periodicamente para se ter testes funcionais automatizados. Na prática é necessário que o teste seja escrito por um analista, executado pelo testador e automatizado pelo programador. Além de ocupar 3 funções, a programação é complexa. As ferramentas de automatização são genéricas, atendendo a vários tipos de aplicações, a sintaxe dos scripts é vasta, genérica e mesmo com o uso de gravadores (registram as atividades enquanto um humano executa o teste) a programação é difícil e lenta. Outro agravante é a necessidade constante de alterações dos casos de testes existentes e da criação dos novos casos pois, é necessário que as manutenções, novas funcionalidades e situações de uso da aplicação sejam refletidos nos testes funcionais automatizados. Ainda um outro aspecto relevante é a utilização de vários conjuntos de dados para o mesmo caso de teste. Em aplicações com muitas possibilidades de parametrização e perfis de usuários é importante que o mesmo teste seja aplicado usando vários conjuntos de dados e perfis de usuários com seus respectivos e específicos conjuntos de resultados.
Buscando a simplificação. Desde uns 6 anos atrás temos, na Log.One, buscado formas de simplificar a automatização dos testes tirando um pouco o caráter puramente técnico do processo. Num primeiro momento o foco foi na simplificação dos conjuntos de dados associados a padrões de telas e não no script em si para que pelo menos os conjuntos de dados e testes de telas pudessem ser escritos por não programadores. O processo em si continuou dependendo de programação. Essa decisão foi acertada e tem sido usada na Log.One desde então: o caso de teste é definido pelo analista, programado por um programador e o conjuntos de dados/resultado é escrito diretamente pelo analista e/ou testador e sofre somente retoques antes de ser colocado para execução.
Exemplo de caso de teste programado em Java
Exemplo de planilha de testes automatizados
A decisão de se colocar os conjuntos de testes em planilhas foi meio natural e muito acertada. Chegamos a considerar o uso de um wiki, inspirados pelo Fitnesse, para a colocação dos dados em tabelas mas optei pelo uso de planilha em função da sua característica 'não técnica' de edição. Meio que por coincidência, em paralelo com a adoção das planilhas para os conjuntos de dados automatizados, trocamos o uso de uma ferramenta específica, o Testlink, pelo uso de planilhas também na escrita de casos de testes manuais... Acontece que já não fazíamos uso da parte do Testlink referente aos processos de aplicação dos testes (já estava nas tarefas do OpenProject) e o Testlink não é amigável na escrita dos casos de teste.
Exemplo de planilha de teste manual
Sendo o uso das planilhas bem sucedido na edição dos conjuntos de dados e na edição dos testes manuais, foi natural considerar a planilha também no processo de simplificação da escrita dos casos de testes.
Foco no contexto Uma vez que as planilhas de dados para testes automatizados estavam atendendo perfeitamente, parti para a avaliação de como simplificar a escrita do caso em si, ou, em última instância: como não precisar do programador para automatizar o teste? como fazer o criador do caso de teste escrever o script do teste automatizado que refletisse o processo e não somente a tela? Um programa de computador representa um contexto de trabalho. Eventualmente aplicações grandes são compostas por módulos onde cada módulo representa um sub-contexto da aplicação. Pensando dessa forma percebi que o conjunto de comandos necessários para se testar as funções poderia ser resolvido em um número menor, e bem definido, de ações automatizadas, ou seja: a solução natural foi criar uma linguagem específica para o domínio "Testes no Log.One". Em resumo: foi criado uma DSL, e seu interpretador, para testar o Log.One.
Exemplo de teste automatizado
É fácil observar a semelhança semântica entre o exemplo acima automatizado e o caso de teste manual (mais acima). De fato existe até mesmo semelhança de sintaxe com o objetivo de manter a familiaridade 'humana' das escritas. Esse mecanismo está em fase experimental e com resultados promissores, sendo que a intenção final é que uma situação (teste de funcionalidade ou reprodução de bug) possa ser escrito nessa linguagem sem a necessidade anterior de execução na aplicação. Por exemplo: no processo de correções de bugs do Log.One, é necessário que o bug seja reproduzido e seu caso de teste seja escrito antes de delegar a tarefa ao programador. Quero que esses dois passos sejam um só, onde o analista escreve o caso de teste que reproduz o bug sem sequer precisar abrir a aplicação.
Trexho do fluxo de correção de bug
O próximo passo, considerando a adoção integral e bem sucedida dessa DSL, seria o uso de processamento de linguagem natural para diminuir a necessidade de sintaxe rígida na escrita dos casos e o aumento da amplitude dos comandos. Com a popularização das ferramentas de inteligência artificial e a evolução nos processos de aprendizagem, aliado ao fato de estarmos falando de contextos bem demarcados, essa não me parece uma meta muito longínqua, apesar de não ter certeza do real valor que seria agregado ;-)
Postado por Walter Mourão às 15:35
Um comentário
quinta-feira, 1 de setembro de 2016
Gerenciamento de Parâmetros em Múltiplos Ambientes Sistemas corporativos geralmente são instalados simultaneamente em múltiplos ambientes, sendo que os clientes Log.One o tem instalado nos ambientes de homologação e produção. Os dados do ambiente de produção são periodicamente copiados para o banco de dados de homologação de modo que os testes feitos no ambiente de homologação se aproximem da operação real do sistema. Como o Log.One tem muitos parâmetros que regem sua operação, e vários desses parâmetros dizem respeito à sua interação com sistemas externos tais como ERPs e LIMS, e com equipamentos tipo balanças, OCR, cancelas e outros, é importante que os parâmetros da homologação sejam distintos daqueles da produção no que diz respeito à comunicação com esses elementos externos. Isso é necessário para evitar problemas graves do tipo: Faz-se um embarque de navio no Log.One da homologação e os dados desse embarque são enviados erroneamente para o ERP da produção, culminando na emissão de uma nota fiscal de exportação, faturamento, etc. Recebe-se um caminhão na homologação e erroneamente abre-se uma cancela do terminal, permitindo a entrada de um caminhão que ainda não tinha permissão no Log.One da produção para entrar no terminal. Como os parâmetros do Log.One ficam em uma tabela no banco de dados, num primeiro momento criamos procedimentos de alteração desses parâmetros para serem executados quando fosse feita a cópia dos dados da produção para a homologação, mas isso rapidamente se mostrou inviável devido a falhas nos procedimentos operacionais (leia-se 'o procedimento não era executado') e optamos por uma solução sistêmica e definitiva que não dependesse de procedimentos. Implementamos então a estrutura de classes do Log.One no seguinte formato:
A chave para a questão dos múltiplos ambiente é o campo situacaoExecucao da classe ValorParametro. O enumerado TipoSituacaoExecucao contém as três possibilidades de ambientes. A tela de configuração de parâmetros é assim:
Dessa forma ao fazer a configuração do sistema o analista registra os valores conforme eles devem ser, de modo distinto para os ambientes e o mecanismo interno de obtenção dos valores obtém o valor correto conforme o ambiente no qual o Log.One esteja sendo executado de forma transparente para o restante do sistema.
Postado por Walter Mourão às 12:51
2 comentários
quinta-feira, 26 de novembro de 2015
Controle de Versões em Pacotes Específicos de Software Eu sempre digo que controle de versões de produtos não é um problema pois problemas tem soluções. De forma rápida enxergo três níveis de dificuldades em relação a controle de versões: Aplicativos internos Aplicativos genéricos Pacotes específicos Quando falamos em aplicativos internos, ou seja: programas que são usados internamente em uma empresa e foram criados e são mantidos exclusivamente para uso dessa empresa, o controle de versões é muito simples. Têm-se um único fonte e todas as correções e novidades a serem agregadas são adicionadas a esse fonte. Os problemas se resumem à definição de um processo de liberação de correções e novidades e à garantia de execução desse processo. Atualmente o GitFlow está fazendo sucesso e de fato é um bom começo para se definir o fluxo do ambiente de desenvolvimento, mesmo que não se esteja usando o Git. Aplicativos genéricos são os programas 'de prateleira' (expressão dinossáurica) tais como pacotes tipo office e apps para celulares. Nesses casos a complexidade aumenta um pouco, pois além de se ter uma linha de trabalho onde se agregam as correções e novidades, deve-se ter também as linhas referentes a uma ou mais versões passadas onde são corrigidos bugs críticos. Por exemplo: um usuário do Office precisa receber atualizações críticas e de segurança sem ser obrigado a atualizar a versão completa do produto, então os desenvolvedores do Office devem manter versões passadas de modo a aplicar essas correções. Em produtos mais simples como aplicativos de dispositivos móveis, também vale a visão do aplicativo interno, onde basta uma única linha de desenvolvimento, pois a atualização é praticamente obrigatória quando uma nova versão é publicada na loja. Chamo de pacotes específicos aqueles pacotes de software de uso mais específico e crítico, tais como ERPs e sistemas de gestão operacional, como o LogOne. Nesses casos, além da manutenção da linha de desenvolvimento principal, mantêm-se versões passadas também, tanto para correções críticas e de segurança quanto para correções triviais e eventualmente novidades. Isso ocorre porque quanto mais específico o produto, maior é o tempo entre as atualizações de versão. Quanto mais específico o produto, maior é a necessidade de treinamento, adequação de processos, desenvolvimento de integrações e preparação de infraestrutura, causando uma inércia natural no que diz respeito à dinâmica de atualizações. Em pacotes específicos, além da linha de desenvolvimento principal, têm-se linhas de desenvolvimento focadas em versões passadas e eventualmente até com códigos específicos para um determinado cliente. Um exemplo de especificidade são as interfaces do LogOne. No LogOne as interfaces são desenvolvidas durante a implantação, levando em conta as características específicas de cada ambiente (tipo de automação, de ERP, de sistema de laboratório, etc.) então cada cliente do LogOne tem seu conjunto de códigos fonte de interfaces mantido (quase) junto ao código geral do LogOne. Tanto as correções e novidades gerais do LogOne devem se manter compatíveis com esses códigos específicos quanto o contrário: as atualizações feitas nos códigos de interfaces devem se manter compatíveis com o código geral e o atual do LogOne. A principal ferramenta para se lidar com esse tipo de problema é o processo e a garantia que esse processo está sendo seguido. Ferramentas adicionais como a automatização de testes funcionais com grande amplitude também colaboram. Enfim, como eu disse, não é um problema que tenha uma solução e sim uma questão que tem especificidades conforme o produto e ambiente de desenvolvimento. Postado por Walter Mourão às 10:08
Um comentário
quinta-feira, 10 de setembro de 2015
Gestão de Tarefas em Equipes Dispersas Para ser bem sucedida a gestão de tarefas em equipes dispersas demanda atenção em alguma ações específicas quando comparado com a gestão em equipes locais. Até penso que essas ações são válidas em qualquer caso particularmente quando a equipe local tem o benefício do home office, ou seja: na prática a equipe é local mas eventualmente tem membros que trabalham remotamente, fazendo home office. Uma vez que essa prática se torna mais e mais comum as necessidades percebidas nas equipes locais se aproximam daquelas percebidas nas equipes dispersas.
Comunicação Constante O gestor de equipes dispersas deve estar constantemente disponível na ferramenta de chat e exigir essa mesma disponibilidade, conforme os horários acordados. As ausências por mais de 15 minutos (ou outra margem combinada) devem ser notificadas ao gestor para evitar qualquer mal estar. Na Arcadian usamos extensivamente o Skype tanto para chat escrito quanto para conferências por voz/vídeo, dando preferência para o chat escrito em função do registro que acontece nesses casos, possibilitando consultas e repasses posteriores. A indisponibilidade de um membro da equipe não deve ser motivo para a interrupção da comunicação e o telefone ou e-mail devem ser usados normalmente. Reforço essa obviedade por perceber na prática que existe uma tendência nas pessoas a seguir um único caminho e facilmente interromper uma tarefa em função de um pequeno obstáculo, nesse caso aqui a indisponibilidade no chat. Já presenciei (muitas) situações assim: - Fulano, como está a tarefa X ? - Tive que parar porque não sei a senha do servidor e o Beltrano não está no Skype. - Já ligou para o celular dele ? - Não...
Formalização A comunicação citada acima é aquela comunicação do dia a dia, a comunicação que se tem quando as pessoas estão fisicamente próximas. É interessante observar que mesmo para essa comunicação o uso do chat traz um benefício colateral que é o registro permanente do que foi escrito, "formalizando" uma comunicação tipicamente informal, ou seja: quando houver dúvida em relação a uma conversa, basta consultar a ferramenta de chat pois na verdade a conversa foi escrita e está registrada, permitindo não só a consulta, mas também o repasse daquela informação na forma original, via o tradicional copiar e colar. A despeito dessa formalização que ocorre de forma periférica, tudo em relação a uma tarefa deve ser formalmente registrado. O que fazer, quando fazer, quem deve fazer, assim como o registro do que foi feito, por quem e quando foi feito e quaisquer situações adversas devem ser registrados. A gestão tanto da delegação quanto do histórico das tarefas demanda uma ferramenta especializada. Utilizar planilhas ou ferramentas de outros domínios (gerenciamento de projetos) é, no mínimo, amador. Não funciona em equipes locais e muito menos em equipes dispersas. Um outro aspecto a se comentar é o legal/trabalhista. A formalização da delegação e da execução da tarefa são importantes do ponto de vista legal, quando o colaborador em regime CLT trabalha em regime home office.
Apontamento de tempo O apontamento do tempo despendido em cada tarefa tem várias funções, incluindo a avaliação de performance individual ou da equipe, melhoria no processo de estimativa e faturamento pelo trabalho executado. É essencial que a cultura da equipe adote e pratique um apontamento de tempo consciente. Não se pode permitir o apontamento vago de 8 horas com a observação "Trabalhando na tarefa X" e nem o excesso de detalhe do apontamento de 5 minutos "Fazendo o commit dos fontes". A adoção de padrões de descrição e unidades de tempo e sua incorporação na cultura da equipe são tarefas árduas mas que trazem resultados valiosos.
Disponibilidade das Informações Outro aspecto que deve ser valorizado em equipes locais e mais ainda em equipes remotas é a disponibilidade das informações. Independente do tamanho da equipe, não é bom que as informações estejam na cabeça das pessoas, ou na gaveta do gestor. É essencial que existam locais definidos onde informações sobre processos, documentos, procedimentos, recursos computacionais e etc. estejam claramente descridos e facilmente disponíveis. Observe que não estou falando de informações estáticas somente. Informações dinâmicas tais como novos endereços de servidores, alterações no ambiente e etc. devem ser disponibilizados imediatamente, ou seja: tanto o ato de se buscar a informação antes de perguntar informalmente, quando o ato de se disponibilizar a informação em local conhecido devem ser incorporados ao dia a dia.
Ferramenta Já citei antes que considero essencial que se use uma ferramenta específica de gestão de tarefas, de preferência que agregue o máximo possível das necessidades que comentei acima. Tive a oportunidade de trabalhar com muitas ferramentas de gestão de tarefas, incluindo as mais famosas (Bugzilla, Mantis, Jira) e atualmente uso o OpenProject. Considero o OpenProject a melhor que já trabalhei, principalmente em função do equilibrio entre gestão de tarefas e gerenciamento de projetos, permitindo uma transição suave da visão de alto nível do projeto como um todo para a visão detalhada das tarefas a serem efetivamente executadas. No futuro (próximo, eu espero) vou entrar mais em detalhes sobre o OpenProject e suas características. Postado por Walter Mourão às 10:57
3 comentários
quinta-feira, 4 de junho de 2015
O Fim do 'Agil' Alguns dias atrás li um artigo muito interessante, "The Failure of Agile", onde o autor, Andy Hunt, decreta o fim da era das metodologias 'ágeis'. Não é o primeiro a criticar o modismo autoproclamado como 'ágil', mas pelo que sei é o primeiro dos autores do manifesto ágil a fazer isso de forma explícita. Quando o manifesto ágil foi lançado, a 14 anos, eu já programava profissionalmente a 16 anos e, pragmático, não dei muita atenção. Com o aumento da repercussão do manifesto, da criação da extreme programming e da cobrança entre meus pares me senti na obrigação de estudar o assunto mais a fundo. Li, assisti e ouvi um emaranhado de bobagens sob a nomenclatura de técnicas e metodologias ágeis. Algumas eram experimentos acadêmicos sem nenhum embasamento prático real, outros eram técnicas efetivas que já eram conhecidas e usadas desde muito antes do manifesto com uma roupagem diferente. Tinha alguma coisa de novidade boa realmente, fruto da experiência e bom senso, mas que por si só não merecia ser definido como metodologia. Quando li o livro "Scrum and XP from the Trenches" eu realmente desisti de aplicar de forma sistemática essas técnicas em minha equipe pois reforçou minha percepção de que a aplicação dessas técnicas exigiria ambientes bem especializados e um nível de experiência muito alto entre todos os desenvolvedores. Ou seja: não é que não funcionasse, mas para funcionar sairia muito caro, talvez mais caro do que uma abordagem mais tradicional. Achei inviável.
Delegação de tarefas e documentação Uma equipe bem equilibrada deve ter desenvolvedores experientes, pouco experientes e inexperientes e a distribuição de tarefas deve seguir algumas regras bem definidas e claras para todos, de modo a ponderar tanto as competências quanto o conforto e o custo. Por exemplo: delegar tarefas básicas ou enfadonhas para desenvolvedores experiência é um convite ao desestímulo. Delegar tarefas complexas a desenvolvedores inexperientes é um convite ao desastre. A busca pelo graal da agilidade fez outra baixa importante: a documentação. Sob a égide de ser ágil, decretouse a morte da documentação. Tarefas passaram a ser delegadas 'de boca' e executadas sem nenhuma documentação. Ok, ok... metodologias formais demais, derivadas de ambientes paquidérmicos pregavam uma formalização absolutamente desnecessária no processo de desenvolvimento. De fato, nos primórdios :-), a delegação de tarefas, especificações funcionais e técnicas que nunca mais seriam lidas eram realmente criadas com um rigor e formalização absurdos e isso criou uma certa repulsa, revolta, que acabou criando a cultura do protótipo no guardanapo.
Testes e Integração Contínua Apesar de desprezar a aplicação de testes unitários demais em sistemas de uso geral, penso que a visão inicial de automação dos testes unitários foi o que deu origem à visão mais pragmática e realista dos testes funcionais automatizados. A integração contínua foi uma grande ideia. Não necessariamente, mas preferencialmente, conectados, a integração contínua e os testes automatizados criam um ambiente de relativa 'tranquilidade' no dia a dia do desenvolvimento. Talvez esses tenham sido os grandes legados da era 'ágil'.
Bala de prata Como todo modismo passa, não me surpreendeu que esse também definhasse. No que diz respeito ao Andy Hunt, aparentemente ele está em busca de algo mais pé no chão através da defesa de uma visão mais focada em cada ambiente, ao invés de vender uma bala de prata, como faz a maioria dos especialistas da área. Postado por Walter Mourão às 08:55
3 comentários
domingo, 5 de janeiro de 2014
Equipes Dispersas de Desenvolvimento de Software Especialização X Multidisciplinaridade Sou partidário da especialização, mas sem radicalismos... é importante que o profissional desenvolvedor de software especialista em algum assunto, tenha também uma visão cuja amplitude lhe permita executar o seu trabalho sem dependência extrema dos colegas. Por exemplo, é essencial que o programador saiba testar... e para testar ele precisa conhecer um mínimo do ambiente operacional onde o programa vai ser executado. Por outro lado... não me agrada a ideia de equipes multidisciplinares onde todo mundo faz tudo, ou faz de tudo. Menos ainda me agrada a ideia de um único desenvolvedor executar toda a linha de desenvolvimento de um caso de uso. Salvo exceções muito específicas, duvido que a qualidade sobreviva a um único desenvolvedor levantando requisitos, documentando/especificando, programando scripts, serviços e telas e testando. Duvido também que ele documente adequadamente o que deve ser feito e o que foi feito para quando outro desenvolvedor for substitui-lo. Estou ciente que essa visão vai contra a proposta corrente dos métodos ditos 'ágeis', mas acho que é isso mesmo: para funcionar esse métodos dependem de programadores 'estrelas' e as equipes são sempre de custo alto e dependentes da capacidades de um ou outro. O conceito comum de fábrica de software peca pelo alto custo de implementação e excesso de burocracia. Fábricas de software que não tenham um nível altíssimo de documentação (leia-se custo e burocracia) e recurso dedicado (leia-se custo), simplesmente não funcionam, ou funcionam transferindo o custo para algum cliente (geralmente governo) que esteja disposto a pagar sem questionar os excessos. A alternativa é o modelo onde existe método e documentação plena e suficiente para o desenvolvimento (e manutenção !), sem excessos, onde a ausência de um desenvolvedor não implique que o substituto tenha que ler fontes de programa só para entender o que o caso de uso faz e quais as regras envolvidas. Óbvio não é ? é... mas como definir o que é documentação plena e suficiente sem excessos ?
A Documentação Avaliada Como Insumo Se por um lado considero que é essencial documentar tecnicamente o sistema, por outro lado desprezo qualquer documentação que não seja insumo de alguma atividade. Esse negócio de documentar só porque é regra da empresa não funciona. O que não faltam são templates de documentos para que se tenha uma boa referência de como documentar um sistema. Uma boa medida para saber se a documentação está em nível suficiente é avaliar se ela está cumprindo bem seu papel como insumo. O processo que delimita as atividades de cada desenvolvedor e define bem os artefatos e insumos de cada tarefa está criando, por consequência, uma boa medida de avaliação da documentação, pois basta verificar o nível de entendimento do desenvolvedor seguinte no fluxo do processo para avaliar se a documentação (insumo) que ele recebeu estava suficiente. Por exemplo: o programador entendeu bem as especificações do analista ou teve muitas dúvidas em relação ao que devia ser feito ? se o programador entendeu bem, esse é um bom indicativo de que a documentação recebida pelo programador está suficiente. Claro que existem ruídos e o coordenador da equipe deve avaliar quando o problema é na documentação e quando é no programador.
Equipes Dispersas Tenho trabalhado com equipes dispersas há muito tempo de forma ocasional. De um ano e meio para cá tenho trabalhado de forma sistemática com 4 desenvolvedores distantes (em uma equipe 8), sendo estes com foco em programação e automatização de teste enquanto os internos tem foco em disciplinas relacionadas ao conhecimento do negócio e qualidade em geral (análise, modelagem, planos de teste, etc.). Tive a possibilidade de confirmar e evoluir várias ideias a respeito de um processo de desenvolvimento pragmático baseado na especialização de atividades, foco na documentação como insumo e delimitação de comunicação. De forma geral cheguei à conclusão de que a correta adequação desses dois "problemas" (manutenção de documentação + equipe dispersa) pode se tornar uma vantagem competitiva na medida em que a equipe esteja devidamente alocada em suas áreas de competência (especializada).
Postado por Walter Mourão às 11:16
Nenhum comentário
domingo, 1 de setembro de 2013
Portus -> LogOne: Planejamento & Performance na Operação Portuária Entregamos os módulos 9 e 10 do LogOne. Esses módulos se referem respectivamente a planejamento e performance da operação. De fato já tem um tempinho isso, mas não pude escrever antes.
Planejamento O LogOne suporta dois tipos de planejamento: operacional e estratégico. O planejamento operacional diz respeito àquele planejamento de curto prazo, em geral referente aos próximos dez ou quinze dias da operação. Por outro lado, o planejamento estratégico é aquele feito com vistas ao longo prazo, contemplando geralmente o ano inteiro. Esse planejamento de longo prazo deve levar em conta todas as grandes variáveis que influenciam na operação: estoque inicial, previsões de descarga e embarque, grande paradas para manutenção de equipamentos, etc.
Indicadores de Performance Além do planejamento, toda operação logística precisa de indicadores de performance. No caso do LogOne, existem vários indicadores 'nativos' e um mecanismos de fórmulas (usando o Rhino) permite que o usuário crie novos indicadores usando os indicadores nativos ou indicadores que ele mesmo tenha criado. Para deixar o ambiente mais completo ainda, criamos suporte para a importação de indicadores externos, permitindo que outros sistemas (ERP, por exemplo) possam enviar dados de indicadores que não são suportados nativamente pelo LogOne, tais como indicadores de custo financeiro de insumos por fase de produção (água, energia elétrica, terceiros, etc.).
Fim da migração Quando comecei a escrever sobre a migração do Portus para o LogOne, um ano atrás, tínhamos a previsão de uma implantação até o fim de 2013. As coisas esquentaram um bocado e atualmente estamos com quatro implantações em andamento, sendo que em uma delas já ocorreu inclusive a homologação pré-produção. Atualmente o LogOne suporta terminais portuários e intermodais com operações de carga/descarga alfandegada (ou não) via rodovia, ferrovia, mineroduto e marítima, e considero que a migração está completa. Alguns desafios ainda virão e pretendo escrever sobre eles, mas não no contexto de migração do Portus. Aproveito o momento para agradecer a todos que participaram e contribuíram de alguma forma para o crescimento do Portus nesses quinze belos anos... :-)
Postado por Walter Mourão às 15:24
Nenhum comentário
Página inicial
Postagens mais antigas
Assinar: Postagens (Atom)
Tema Viagem. Imagens de tema por mattjeacock. Tecnologia do Blogger.
A maioria dos textos desse blog deve tratar de: Qualidade de softwareMelhoria de Processos MDA Angular/Java/JavaEE
Sobre mim Nome: Walter Mourão Localização: Belo Horizonte, MG Perfil Linkedin
Links relacionados Log.One OpenProject