Certificações para profissionais de Processos de Negócio

Crédito da foto: albertogp123 - via photopin.com (cc)O mercado de profissionais para atuar em iniciativas de Gestão por Processos está bastante aquecido. Não há uma pesquisa formal, mas uma percepção geral de que bons profissionais que atuem em iniciativas de processos estão fazendo falta no mercado.

Esta área de atuação ainda está se consolidando em muitas organizações, e o grupo de profissionais que se envolvem nestas iniciativas variam bastante não apenas de acordo com o porte da empresa, mas também com o nível de maturidade da organização das práticas de gestão de processos.

Por isto mesmo, as certificações para validar conhecimentos e experiência de profissionais da área têm ganhado grande importância.

Certified Business Process Professional (CBPP)

A certificação CBPP é uma das que mais vem crescendo no Brasil, impulsionada principalmente pela forte presença do capítulo brasileiro da Association of Business Process Management Professionals – ABPMP (www.abpmp-br.org), a instituição certificadora. A certificação CBPP está para o profissional de processos assim como o PMP (e respectivamente o PMI) está para profissionais de projetos.

O objetivo desta certificação é validar o conhecimento e experiência do profissional em iniciativas relacionadas à gestão de processos. Por este motivo, para realizar o exame do CBPP existem pré-requisitos que precisam ser atendidos, como ter experiência comprovada em iniciativas de gerenciamento de processos. Ao se inscrever para o exame, o profissional recebe uma cópia impressa do Corpo Comum de Conhecimento em BPM (o BPM CBOK), que encontra-se na versão 3 e já está traduzido para o português.

O exame é baseado principalmente no conteúdo desta obra, mas requer também realizar algumas análises sobre as questões que em geral são obtidas com base na vivência. Para fazer o exame precisa também participar do evento BPM Boot Camp, que são 3 dias de discussão sobre os temas do CBOK (o que também ajuda a fazer uma revisão geral do conteúdo). O exame costuma ser na manhã do quarto dia. A prova é em português e sua realização é presencial mas o profissional responde no próprio computador e o resultado sai na hora.

A CBPP é uma certificação única e renovável a cada três anos; uma forma da ABPMP garantir que o profissional certificado está se atualizando e continua exercendo as práticas de BPM. Embora o exame seja realizado pela ABPMP do Brasil, a certificação tem valor internacional.

Informações sobre a certificação:
http://www.abpmp-br.org/certificacao-cbpp/
Informações sobre a entidade certificadora:
http://abpmp-br.org/
Lista de profissionais certificados (no Brasil):
http://www.abpmp-br.org/profissionais-certificados/

 * Atualização: links para o site da abpmp-br atualizados em junho/2016.

OMG Certified Expert in BPM (OCEB 2)

A certificação OCEB é uma certificação concedida pela Object Management Group, a OMG (www.omg.org). A OMG é uma entidade padronizadora, responsável por diversos padrões técnicos. Os mais conhecidos pela área de tecnologia são o UML e CORBA, mas esta organização mantém centenas de especificações técnicas de linguagens, notações e padrões para diversas aplicações.

O foco da certificação OCEB portanto não está na experiência do profissional em processos, mas a verificação do seu conhecimento e domínio sobre conceitos e padrões, em especial os mantidos pela OMG para processos de negócio, como: Business Motivation Model (BMM),  Process Model and Notation – BPMN, Business Process Definition Metamodel (BPDM), Case Management Model and Notation (CMMN) entre outros. Também são tratados frameworks de qualidade e governança como SOX, COBIT, ITIL, Six Sigma e Lean.

A certificação OCEB é na verdade dividida em cinco titulações distribuídas em três níveis. A certificação básica é a OCEB Fundamental. Os dois níveis seguintes são segmentados em conhecimentos técnicos ou de negócio: Business Intermediate e Technical Intermediate, e então Business Advanced e Technical Advanced. Assim, para o profissional poder confirmar domínio e conhecimento sobre todos os aspectos de BPM, sob a perspectiva da OMG, precisará passar por cinco exames, ou então poderá escolher uma linha específica (negócio ou técnico) e realizar três exames até obter o nível avançado.

Para fazer o exame não há pré-requisitos. Basta estudar a bibliografia relacionada ao respectivo exame, realizar a aquisição do voucher e na data marcada vai ao local fazer o exame. A prova é em inglês.

Recentemente a OMG anunicou a OCEB 2. Isto porque até agosto de 2013 o exame ainda era baseado na especificação da notação BPMN v1.1. Assim, a OCEB 2 é, na verdade, a atualização da certificação para verificar conhecimentos sobre a BPMN 2.0, que é a sua especificação mais recente (veja neste vídeo em nosso canal do youtube o que mudou com a nova versão de BPMN).

Informações sobre a certificação:
http://www.omg.org/oceb-2/
Informações sobre a entidade certificadora:
http://www.omg.org/
Lista de profissionais certificados:
http://www.omg.org/cgi-bin/searchcert.cgi

 

Outras certificações para profissionais em BPM

Embora CBPP e OCEB sejam as principais certificações conhecidas no mercado, existem outras entidades internacionais que oferecem certificação para profissionais de processos, em geral concedidos por entidades educacionais.

Estas certificações tem se apresentado pouco expressivas na comunidade de BPM, sobretudo no Brasil. Algumas delas são:

  • Certified BPM Professional (CBPMPSM), concedida pelo BPMInstute.org, é baseada em literatura indicada no site. Os exames são presenciais e acontecem nos eventos realizados pela organização na Austrália, Europa e Estados Unidos (http://www.bpminstitute.org/certification).
  • Certified Professional in Business Process Management (CPBPM), titulação obtida através do programa educacional em gestão de processos de negócio da Villanova University (http://www.villanovau.com/online-certificates/bpm-certificate.aspx).
  • Certification in Business Process Management (P.BPM), certificação concedida pela instituição educacional BPM Council e International BPM Institute (http://www.bpmcouncil.org/).

 

Certificações profissionais em soluções de BPM (BPMS)

Com a expansão da utilização das soluções para automatização e gerenciamento de processos de negócio, os fornecedores de produtos perceberam a necessidade de formar e certificar profissionais que demonstrem conhecimento profundo e domínio das ferramentas que compoem o produto.

Estas certificações também são bastante valorosas, sobretudo para os profissionais envolvidos no desenvolvimento das soluções com um produto específico. Em geral são certificações bastante técnicas, muito mais focadas em como o profissional interpreta uma situação de negócio e identifica, dentro das capacidades do produto, a melhor forma de implementá-la. Dependendo do fornecedor, a verificação deste conhecimento pode ser realizado através da comprovação de implementação de processos, desenvolvimento de um case enviado pelo fornecedor, exame de conhecimentos teóricos e arquiteturais e até mesmo apresentação de atestados da empresa que teve soluções implementadas pelo profissional.

Conhece outras certificações que não foram citadas? Ajude-nos a manter esta postagem atualizada enviando links para as certificações que você conhece através dos comentários deste artigo.

 


Você sabia que a iProcess conta com uma equipe especializada e certificada internacionalmente?
Confira nossas certificações corporativas e profissionais no site:
www.iprocess.com.br/quem-somos/certificacoes/

Particularidades na execução de projetos com integrações – Parte Final

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

Particularidades na execução de projetos com integrações – Parte 2

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!

Os desafios da homologação de Processos Automatizados

O avanço do BPM trouxe muitos benefícios para as organizações, porém trouxe também alguns novos desafios. Para os usuários finais, isso gerou uma grande mudança cultural que, se não for corretamente encaminhada, pode colocar em risco toda a iniciativa BPM. Engana-se, porém, quem pensa que os usuários finais são os únicos que se depararam com mudanças importantes na adoção de BPM. Também a equipe de TI passou a ter novos desafios, e hoje iremos falar de um destes: a homologação da automação de processos.

A homologação de sistemas tradicionais de TI é um processo bem conhecido que envolve, em linhas gerais, a criação e a execução de roteiros de testes pelos testadores e usuários de negócio. Ao longo do tempo, uma série de ferramentas e metodologias surgiram para facilitar este processo, envolvendo desde a automação dos testes através de ferramentas específicas para este fim, até metodologias como Test Driven Development (TDD), que modificam significativamente o processo de desenvolvimento convencional.

Grande parte das homologações dos sistemas convencionais possuem em comum a existência de uma tela que deve ser homologada, ou seja, uma interface que é a “cara” do sistema para os usuários finais. Estas telas podem eventualmente ter grande complexidade, envolver múltiplos passos para execução e outros complicadores, mas o processo de homologação de um sistema convencional é normalmente bem direto: devem ser testadas todas as interações do usuário com as telas, e se certificar que o sistema está respondendo da forma esperada.

Esta forma de realizar os testes ainda continua válida no caso de homologação de automação de processos, e ainda existirão telas que deverão ser homologadas (nos casos em que usuários interagem com o processo), mas existem diferenças importantes. A principal delas diz respeito ao “coração” da automação de processos, que é o fluxo automatizado que deve ser testado. No lugar de ter apenas uma ou mais telas que precisam ser testadas, agora o principal foco dos testes passa a ser o processo automatizado em si, ou seja, a execução das tarefas seguindo o fluxo desenhado. Isto traz uma série de dificuldades bem específicas, e abaixo listamos algumas das mais importantes:

  • Um processo automatizado, muitas vezes, é iniciado por outro sistema. Nestes casos é preciso simular o disparo do processo manualmente, utilizando por exemplo ferramentas de testes de serviços (ex: SoapUI), que não são muito amigáveis para usuários finais. Nestes casos, também é preciso montar manualmente diferentes versões do que costumamos chamar de dados de entrada do processo, ou seja, os dados que serão exibidos e manipulados durante a execução do processo. Cada uma destas versões tratará de um diferente cenário previsto nos roteiros de testes.
  • Diferente de uma tela de sistema convencional, que via de regra pode ser homologada por um único usuário, um processo automatizado é composto de atividades enviadas para usuários diferentes, muitas vezes pertencentes a diferentes setores da organização. Desta forma, diversos usuários de negócio precisarão ser envolvidos no processo de homologação, cada um testando as atividades que lhe competem. Isto gera uma série de questões adicionais que precisam ser previstas em tempo de planejamento, como por exemplo, os tempos de espera que um determinado usuário poderá ter durante o dia, enquanto aguarda que os fluxos em execução atinjam o estágio em que este usuário participa do processo.
  • Embora sejam executados por diferentes papéis e eventualmente setores da organização, deve-se garantir a integridade e a perfeita execução do processo automatizado como um todo: isso exige um perfil que precisará acompanhar a execução do processo entre os diversos papéis/setores, e garantir a correta execução de todos os caminhos previstos. Envolve ações como, por exemplo, garantir a integridade dos dados sendo manipulados de uma atividade para outra, e garantir que o encaminhamento feito na atividade anterior executou o andamento correto no processo.
  • Muitas vezes, durante a execução do processo automatizado, existem integrações automáticas que não tem uma “interface” visível para os usuários. Por exemplo, são integrações que gravam e/ou obtêm informações em banco de dados e sistemas legados, usualmente via invocação de serviços. Nestes casos é preciso testar estas integrações manualmente durante a execução do processo, utilizando ferramentas mais técnicas (ex: a própria ferramenta de administração do BPMS), que no geral são pouco amigáveis para usuários finais. Nestes casos a homologação destas integrações tende a ser “delegada” para perfis mais técnicos do projeto, como analistas e testadores, visto que dificilmente um usuário de negócio terá o conhecimento ou perfil necessário para fazer estas verificações.
  • Em muitos casos, as aplicações acessadas para apoiar a realização das atividades foram construídas especificamente para serem invocadas através do processo. Logo, nestes casos é necessário ter preocupações adicionais de testes de segurança destas aplicações, como por exemplo:
    • Garantir que uma determinada aplicação só conseguirá ser acessada através da atividade específica que a invoca, e que não poderá ser acessada através de artifícios como, por exemplo, colar a url no navegador;
    • Garantir que somente os usuários dos papéis que estão atribuídos à atividade terão acesso aquela determinada instância de processo.

Como vimos, a homologação de automação de processos traz novos desafios em relação à homologação de sistemas convencionais, e precisa desta forma ser adequadamente planejada e estimada no cronograma do projeto.

Configurando um ambiente de desenvolvimento mais produtivo

Quando planejamos a implantação de uma nova tecnologia, de um novo sistema, é comum nos preocuparmos diretamente com os recursos de hardware e software que serão requeridos nos computadores servidores envolvidos. Porém, um ponto que poucos lembram-se de planejar previamente diz respeito aos recursos que as equipes de desenvolvimento e manutenção irão demandar.

Para além dos produtos diretamente relacionados ao sistema implantado, que outros aplicativos podem ajudar um técnico a ser mais produtivo em suas tarefas? Nesta hora, nada melhor do que trocar experiências, conversar com quem vive essa realidade no dia-a-dia.

Este é o motivador deste post: trocar experiências!

Não temos porém a pretenção de determinar quais são os melhores softwares, tampouco, ao citarmos um aplicativo específico, não queremos dizer que seus concorrentes são menos qualificados. O que estamos nos propondo a fazer é, na verdade, apresentar uma coleção que acreditamos atender adequadamente a maioria das necessidades de trabalho dos técnicos envolvidos com automação de processos e com desenvolvimento de sistemas de um modo geral.

Nota: é importante atentar para as políticas de licenciamento de cada software! Nem todo programa que pode ser instalado gratuitamente permite o seu uso para fins comerciais. Não nos responsabilizamos e tampouco estimulamos usos indevidos. Tampouco temos qualquer relação comercial com os fabricantes e distribuidores dos aplicativos citados.

 

Bom, vamos ao que interessa!

Confira a lista de aplicativos que sugerimos, considerando as plataformas Windows e Linux. Aguardamos contribuições e outras sugestões nos comentários.

Para facilitar, vamos agrupar as sugestões em aplicativos básicos, técnicos, segurança e desenvolvimento.

Aplicativos básicos:

  • Primeiramente é importante definir o sistema operacional a ser utilizado. O Windows 7 Professional é uma ótima opção nessa plataforma e, em Linux, as distribuições Fedora e Ubuntu são recomendadas (mas muitas outras também são adequadas).

** Adicionalmente, o Firefox mostra-se como uma opção bastante interessante para desenvolvedores pela grande quantidade de plugins disponíveis para estender suas funcionalidades. Dentre esses, podemos destacar o Webdeveloper e o Firebug, especialmente úteis para depurar os componentes Javascript das suas páginas.

  • Compactador de arquivos 7-zip, para Windows.
  • PDF XChange é um bom leitor deste tipo de arquivo, pois é leve e permite a inclusão de comentários e marcações. No Linux, ele pode ser instalado utilizando o Wine, citado mais adiante (Okular e Evince são bons leitores também para Linux). Claro, há também a opção de utilizar o Adobe Reader (para Windows e Linux), mas este é bastante “pesado”. Já para geração de PDFs, o pdfCreator é uma ótima opção para Windows, e o Cups-PDF para Linux atende a necessidade.
  • Para edições simples de imagens, recomendamos o Paint.net para Windows ou o Gimp (Windows e Linux), e o Gadwin Printscreen (Windows) para produzir cópias de telas (a maioria dos ambientes Linux possui opção nativa para tal).
  • Para comunicação, Skype para videoconferências e para chat o Pidgin (Windows e Linux), que suporta em um só aplicativo contas do MSN, GTalk e de outros serviços.
  • Instale o cliente do Dropbox para compartilhar facilmente arquivos entre diferentes computadores, ou mesmo entre toda a equipe de desenvolvimento.

Aplicativos técnicos:

  • Para Linux, há muitos pequenos programas de linha de comando úteis para diversas tarefas. Em ambiente Windows, podemos utilizar boa partes desses comandos utilizando o Cygwin! Por exemplo, nada como poder utilizar o comando tail para acompanhar um arquivo de log e, com o Cygwin, isso é possível mesmo em Windows.
  • No Windows, podemos conectar em um ambiente Linux remoto utilizando o Putty ou XShell, e podemos até mesmo executar localmente programas gráficos que estão instalados em um ambiente Linux remoto se utilizarmos o XMing. E o contrário também é verdadeiro: podemos instalar e executar alguns aplicativos Windows em ambiente Linux, instalando o Wine. Se o aplicativo não for dependente de bibliotecas muito específicas, tem uma boa chance de funcionar muito bem! E, para conectar remotamente em uma máquina Windows a partir do Linux, utilize o Vinagre, um cliente Remote Desktop e VNC leve e adequado.
  • Para controle de versões SVN, instale no Windows o Tortoise SVN, que integra-se muito bem ao Windows Explorer. Existe também o projeto Tortoise GIT para este outro controle de versões. Bem menos explorado e conhecido, o sistema de controle de versões Bazaar é uma opção bastante interessante para manter versionados arquivos locais sem depender de um servidor específico para tal. Pode ser utilizado, por exemplo, para manter versões locais mais frequentes, sem, no entanto, submeter versões para o sistema centralizado da empresa, onde espera-se que sejam entregues apenas versões estáveis dos códigos-fonte.
  • Para comparação de arquivos, recomendamos WinMerge para Windows e Meld para Linux.
  • Para editar arquivos texto no Windows, esqueça o Notepad! Instale o Notepad++, que possui diversos recursos e plugins disponíveis.
  • Instale o Wireshark (Windows e Linux) para interceptar e monitorar o tráfego de rede.

Segurança:

  • Utilize o TrueCrypt principalmente para proteger pendrives e HDs externos, mas o mesmo pode ser utilizado também para criptografar discos rígidos dos seus computadores. ** Adicionalmente, em Linux, é possível criptografar o disco rígido facilmente utilizando LVM.
  • Especialmente em ambiente Windows, tenha um bom antivirus instalado! O McAfee é bastante eficiente, mas tem custo de licença e consome bastante recursos do computador. Já o Comodo tem a vantagem de ser uma suite com antivirus, antimalware e firewall, e gratuita. Para Linux, o Avast é uma boa opção de antivirus para uso pessoal, enquanto que o Clamav é o mais famoso e de uso gratuito. Já o ipTables é o firewall padrão (boa parte das distribuições geralmente contam com um aplicativo gráfico de firewall baseado em iptables). Ainda para Windows, pode-se também fazer uso das próprias ferramentas da Microsoft: Windows Firewall e o Security Essentials como antivirus.
  • Também não esqueça de ter uma opção de software para backup, especialmente se trabalhar em home-office ou se viaja muito com notebook. A maioria desses serviços é pago, mas seu custo caiu muito nos últimos anos. Algumas opções de empresas que disponibilizam serviço de backup remoto são: CrashPlan, Carbonite e Mozzy – estes dois últimos somente para Windows, o primeiro para múltiplas plataformas.

Desenvolvimento:

  • Para acesso e programação em banco de dados Oracle, utilize o Oracle Sqldeveloper. Para banco de dados SQL Server, utilize as próprias ferramentas  Microsoft.
  • Para desenvolvimento, depende muito do gosto do programador, mas Eclipse e Netbeans são ótimas IDEs.
  • Para teste e simulação de webservices, o SoapUI é uma excelente ferramenta.
  • Para automação de build e deploy, principalmente em Java mas também em outras linguagens e plataformas, utilize Ant e Maven.
  • Para virtualização de servidores, o VirtualBox é uma ótima opção, pois permite inclusive criar snapshots. Mais limitado, o VMware Player também serve para executar máquinas virtuais facilmente.

Bom, ficamos por aqui. Compartilhando esta lista de aplicativos, esperamos ajudar a facilitar o processo de escolha de ferramentas para as diversas necessidades e demandas de software que surgem em um ambiente de desenvolvimento.

Aguardamos comentários e sugestões de outros aplicativos que podem ajudar a tornar o nosso dia-a-dia mais produtivo ;-)

Particularidades na execução de projetos com integrações – Parte 1

Projetos envolvendo integrações, sejam elas o escopo completo ou apenas parte dele, possuem uma série de particularidades, do planejamento e gestão às mais específicas decisões técnicas.

Integrações são, em muitos casos, o calcanhar de aquiles dos projetos. Não apenas quando falamos dos pontos de contato entre dois ou mais sistemas, ou em projetos de orquestração de serviços (SOA), mas também quando temos equipes com entregas específicas, eventualmente falando idiomas diferentes, em locais distantes, com culturas distintas… mas que em determinado momento precisam literalmente juntar todo o código-fonte do projeto e fazê-lo “conversar” harmoniosamente. Dados devem ser transportados e transformados de acordo com as regras, formatos e tipos especificados. Um sistema deve entender o outro como se tivessem nascido juntos, filhos do mesmo pai. E o mais importante: os usuários devem ter a segurança de que as informações que compartilharam estão íntegras e disponíveis a todos os interessados, no tempo certo, no formato esperado.

Diante de tudo isto, gostaria de compartilhar, nesta série de artigos, idéias sobre gestão e execução de projetos com integrações. Na verdade, o principal objetivo aqui é levantar dúvidas. Sim, isto mesmo. Estes projetos em especial possuem, é claro, premissas, características, desafios e problemas comuns. Entretanto, cada um possui variáveis internas e de ambiente que tornam a avaliação e solução destes itens particular para cada caso. A simples discussão sobre estes pontos, bem como a citação de exemplos e experiências, faz com que nos forcemos a perguntar no início e no decorrer do projeto:

– Estou controlando adequadamente minhas dependências?

– Onde está o contrato das entradas e saídas dos dados deste sistema?

– Estou realmente comunicando a todos os interessados as informações necessárias?

Nesta primeira parte será abordado um tema que não inicia nem termina o projeto, mas que é crítico para sua execução: o controle de dependências técnicas e gerenciais.

Quando falamos de dependências, nos referimos a qualquer item, seja técnico, metodológico ou gerencial, que é gerado por um participante do projeto e que é insumo ou referência para outro. Exemplos? Temos vários:

  • Serviços ou APIs que precisam ser implementados (às vezes, eles até existem, mas precisam ser encontrados!).
  • Informações que devem ser buscadas com algum usuário e que será base para análise de negócio de algum ponto do sistema.
  • Documentações de produto que precisam ser repassadas, para viabilizar o desenvolvimento.
  • Profissionais com conhecimento em sistemas que devem ser integrados.
  • Disponibilidade do fabricante de produtos para repasse de conhecimento.

E assim por diante…

Integrações possuem um cenário padrão: temos uma origem, um destino e a integração em si, que pode ser implementada em inúmeros níveis de complexidade. Mas é nas duas “pontas” que residem os principais problemas com dependências.

Apesar de óbvia, a primeira preocupação nem sempre é lembrada: as dependências devem ser PLANEJADAS. Nesta etapa, alguns pontos parecem particularmente críticos:

  • Disponibilidade de recursos – Os responsáveis por fornecer as informações referentes a cada origem e destino de dados devem estar disponíveis no momento planejado para suas participações. Porém, geralmente são profissionais que não estarão disponíveis em tempo integral, provavelmente dividindo seu tempo de trabalho com as demandas de projeto. Assim, é importante antecipar suas necessidades.
  • Documentações de sistemas – Muitas vezes a análise pode ser muito facilitada a partir da disponibilização antecipada de documentações de sistemas ou suas camadas de integração já desenvolvidas. Com isto, diminuem-se também os riscos do projeto associados ao entendimento das origens e destinos de dados envolvidos nas integrações.
  • Participação de fabricantes de produtos – É comum a implementação integrações entre sistemas com fornecedores localizados fisicamente em regiões distantes da sede do projeto. Por vezes, o fabricante nem existe mais! Desta forma, é fundamental antecipar a participação deste stakeholder, a qual possivelmente envolverá custo e pode impactar significativamente o planejamento do projeto.
  • Definição clara de metodologia, formato de documentação e estrutura de informações da análise das interfaces – A definição de um procedimento e linguagem comuns entre as equipes e envolvidos no projeto auxilia muito a evitar ruídos de comunicação e perda de informações durante a análise das integrações.

Com as dependências identificadas e com planos de ação definidos, começa a execução. Porém, o planejamento em si não garante de forma alguma o sucesso na administração das dependências. Agora, elas precisam ser CONTROLADAS. Isto requer, dentre outras necessidades:

  • Um mecanismo comum de controle – Deve ser possível, mas é muito mais difícil controlar as dependências entre equipes e sistemas através de meios próprios de cada participante do projeto. Um sistema para isto auxilia de maneira bastante prática (um software de controle de issues é uma boa alternativa), mas uma planilha compartilhada e bem organizada já pode, dependendo do caso, resolver. A questão é: é fundamental ter algum mecanismo.
  • Comunicação centralizada, atualizada e disponível a todos – A situação, pendências e problemas de cada dependência deve ser controlada rigidamente, evitando assim complicações posteriores e agilizando a resolução de eventuais problemas.
  • Definição clara e compartilhada de responsabilidades – Um desafio clássico em projetos com integrações é definir de quem é a responsabilidade por levantar uma informação, entregar um artefato, dar um parecer técnico. Parece simples, mas definitivamente não é. E, é claro, não basta definir, tem que compartilhar. Não adianta termos o responsável, se quem precisa dele não o conhece.

Mesmo com todas as preocupações acima, controlar dependências sempre é delicado e trabalhoso. E é muito difícil, senão impossível, definir um processo isento de falhas. Assim, uma outra diretriz pode ser usada em projetos: buscar que as dependências sejam ELIMINADAS – ao menos o maior número possível delas.

Olhando para o desenvolvimento, um exemplo clássico é a utilização de componentes mock (ou fake) para simular o comportamento dos componentes definitivos que serão entregues posteriormente. Com isto, a implementação da integração em si e suas regras de negócio independem das entregas da origem e destino, com um custo geralmente baixo. Estes componentes podem ser implementados com diferentes níveis de simulação das regras de negócios. Podem tanto simular a simples troca de dados quanto ter diferentes retornos e emular as regras reais, dependendo da necessidade de implementação, testes e avaliação de qualidade em cada etapa do projeto.

No aspecto técnico, é claro que isto acarreta a necessidade de controle do “contrato” ou especificação dos componentes que se comunicam com as integrações – mas isto é assunto para mais adiante.

No próximo artigo, abordaremos algumas questões metodológicas que podem ajudar na execução de projetos com integrações, buscando eliminar riscos e controlar o andamento do trabalho. Até lá!