Categoria Boas Práticas

Vitalbyte investe na customização através do Magic xpa para expandir as capacidades do ERP Cigam

A Vitalbyte, desenvolvedora de soluções em TI de Porto Alegre, que integra a rede Cigam e parceira Magic Software, apostou na customização do ERP Cigam para entregar projetos cada vez mais alinhados às necessidades de seus clientes.
shutterstock_89970784[1]

Para atender cada uma das particularidades de sua carteira de clientes, que hoje engloba mais de 100 empresas de diversos segmentos, a Vitalbyte usa  a plataforma Magic xpa, que permite criar aplicações de negócios para todas as plataformas – desktop, mobile ou em nuvem – a partir de um único esforço de desenvolvimento, incluindo os dispositivos móveis iOS, Android, Blackberry e Windows Mobile. Alexandre Cunha, diretor da Vitalbyte revela que quando a empresa iniciou as suas atividades em consultoria e implantação do ERP Cigam, em 2005, as customizações não eram tão comuns, ” alterar uma tela do sistema era também bastante complicado”, explica o executivo, ” mas a evolução constante do Magic xpa vem facilitando este trabalho e as alterações que os clientes necessitam se tornaram mais rápidas”, complementa. “Passamos a oferecer as customizações e acabamos percebendo que os ajustes são necessários para garantir a total satisfação do cliente”.

Leia mais…

Universidade Corporativa CIGAM – Cinco anos qualificando e formando profissionais

A Universidade Corporativa CIGAM, iniciativa pioneira para o desenvolvimento e manutenção de equipes profissionais de qualidade na área de Tecnologia da Informação (TI), está completando cinco anos no dia 15 de agosto. Neste período, participaram da capacitação da UCC mais de 2 mil profissionais, entre colaboradores da rede, comunidade e clientes, em cerca de 320 mil horas de capacitações presenciais ou à distância. “Os números falam por si só, mas é preciso dizer que a UCC está para a CIGAM assim como o ensino fundamental está para um aluno que ingressa na escola. A UCC prepara as bases para o profissional e para os usuários CIGAM, garantindo atendimento qualificado e satisfação para os clientes, nosso permanente objetivo”, é o que declara Vanderlei A. Reinhart – Diretor de serviços e RH, responsável pela criação e desenvolvimento da UCC na rede CIGAM. “A UCC nasceu da necessidade de mão-de-obra qualificada na área de tecnologia, para a formação de profissionais, com base em um modelo sustentável: equipe qualificada representa mais clientes satisfeitos, mercado ampliado e geração de emprego e renda”, é o que disse Robinson Klein, Diretor de Mercado da Rede CIGAM, no dia do lançamento da UCC.

Preparar colaboradores eficientes para suprir as necessidades e demandas do mercado de TI sempre foi importante para a CIGAM. A empresa sempre investiu muito na preparação de seus funcionários e isso culminou com a criação da UCC. “A criação da Universidade ocorreu no mesmo período em que lançamos a 1ª edição do Programa de Qualificação Profissional CIGAM – PQPC. Este programa visava a qualificação de profissionais do mercado para atuarem na Rede. Através do PQPC formamos mais de 80 profissionais, sendo que 20% deles foram contratados. A criação da Universidade buscou a ampliação, fortalecimento e melhoria das soluções de educação da empresa, disseminando o conhecimento empresarial da CIGAM a todos os seus stakeholders” diz Raquel Engeroff, Coordenadora da Educação da CIGAM.

Leia mais…

Boas Práticas na Atualização de Versões do ERP Cigam

A rotina de atualização do Sistema ERP CIGAM é um procedimento em constante evolução. Melhoram-se as telas, agregam-se facilidades, mas a lógica permanece a mesma:

  • Criação de Nomes Lógicos;
  • Criação de tabelas;
  • Atualização das mensagens;
  • Atualização dos componentes;
  • Validação dos Componentes;
  • Execução dos scripts;
  • Execução do CHECK LIST;
  • Importação dos arquivos de apoio.

Atualmente, possuímos um assistente que nos apoia e conduz para que estas etapas sejam respeitadas. No entanto, ainda existem algumas dúvidas relacionadas ao procedimento de atualização. Neste artigo, gostaria de compartilhar com vocês algumas dicas que facilitarão este processo:

1 – Opte sempre por atualizações especificas, disponibilizando ao ambiente apenas o componente relacionado.

Ao importar o arquivo de validação compscig.xml, selecione apenas o componente em questão. O Sistema automaticamente apresentará todos os correlatos necessários, auxiliando e garantindo que toda a solução seja disponibilizada.

Leia mais…

O Controle da Qualidade no Desenvolvimento do ERP CIGAM

Danielle Both

Já faz muito tempo que, no âmbito das empresas de desenvolvimento de software, se vem falando em qualidade. Mas o que é qualidade? Segundo Pressman [1], a qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido. Esta definição enfatiza três pontos chave: os requisitos de software; padrões especificados; e um conjunto de requisitos implícitos.

A CIGAM ao longo destes 25 anos cresceu muito, soube aproveitar as oportunidades e se adaptar a todas as mudanças de mercado, ou seja, soube se reinventar. De melhoria em melhoria tornou-se uma empresa sólida, externa e internamente. A cada mudança, havia a preocupação com os processos, como adaptá-los às novas situações, buscando modelos de qualidade consagrados, não para conquistar a certificação, mas para garantir que se transformassem em vantagens para nossos clientes e parceiros da Rede CIGAM tornando, assim, a busca pela qualidade um processo contínuo e sustentável.

Seguindo estas premissas, podemos afirmar que ter qualidade é conseguir unir o know-how do cliente e da CIGAM no momento de especificar os requisitos de sistema e entregar ao cliente exatamente o que ele necessita, nem mais, nem menos. É este o conceito de qualidade aqui na CIGAM, mas quando amamos o que fazemos, não basta ter os conceitos, precisamos vivê-los. “Vivemos” a qualidade diariamente e entendemos que ela é mais que atender o que está detalhado no documento de levantamento de requisitos.

Para existir como Controle da Qualidade na CIGAM e agregar valor ao produto é necessário, além de atender os requisitos dos clientes, garantir a integridade do sistema como um todo e atender os objetivos e metas da empresa, ou seja, de forma alinhada com a missão, estratégia e políticas definidas por nosso planejamento estratégico.

Desta forma, uma das questões, intimamente ligada à qualidade, que norteia as ações da área de Produto e Tecnologia é a Política de Desenvolvimento CIGAM. Ela é definida anualmente e, para 2011, de acordo com a avaliação do mercado e indicadores de desempenho do produto e da empresa, os requisitos da política de desenvolvimento são: Integridade; Usabilidade; Desempenho; e Documentação. Abaixo uma imagem de divulgação da nossa política:

Garantir a integridade ganhou nova interpretação nos últimos anos, pois com as amarrações legais exigida pelos governos (municipais, estaduais e federal), a partir da centralização e digitalização de todas as informações é necessário que todas as operações da empresa estejam coesas, desde a entrada da matéria prima, até o controle de uma posição financeira e contábil, enfim, mais do que garantir a integridade dos dados, é necessário garantir a rastreabilidade de todas as operações da empresa. É esta a tônica que damos para o quesito INTEGRIDADE.

No entanto, precisamos criar rastreabilidade e manter a integridade do sistema de forma com que nosso segundo quesito da política, a USABILIDADE, não seja afetada. Isto nos faz trabalhar por soluções cuja interface seja agradável, bonita e amigável, garantindo o nosso lema “Sua vida mais fácil”. Ainda na operação do sistema, trabalhamos muito fortemente a questão DESEMPENHO, pois o que move o mundo hoje não é o fato de ser o maior, mas o de ser o mais ágil, então, é fundamental que o ERP CIGAM acompanhe isto, apresentando boa performance durante a execução de suas rotinas.

Por fim, como forma de garantir que a Rede CIGAM possa continuar crescendo e evoluindo de forma segura e sustentável, também trabalhamos o quesito DOCUMENTAÇÃO, para que o conhecimento das pessoas e as definições das funcionalidades do sistema fiquem registrados de forma adequada e possam ser consultadas quando necessário. Nos últimos anos temos evoluído muito a documentação técnica do sistema, principalmente, o manual do sistema, com destaque especial à sessão “Como fazer”, pois é com estas informações que os usuários conseguem, na prática, fazer o uso do sistema na sua plenitude, sem que para isto tenha que consultar o suporte técnico. É importante salientar que estas informações também são base para a construção dos EaDs, fornecidos para toda a Rede CIGAM a partir do Setor de Educação.

Contudo, como podemos avaliar, o primeiro desafio, e um dos maiores da equipe do Setor de Controle da Qualidade, é garantir que os requisitos definidos nesta política sejam cumpridos, pois além da responsabilidade pelo atendimento dos requisitos e pela qualidade geral do produto, o setor também é responsável pela comunicação das questões que envolvem as mudanças no ERP CIGAM, somos o elo entre todas as áreas e parceiros da Rede CIGAM.

Para não me alongar demais, falaremos sobre os processos e a Metodologia de Testes Cigam (MTC) no próximo artigo.

Até lá!

Danielle Glória Almeida Both
Coordenadora do Controle de Qualidade /Cigam Software Corporativo


Desenvolvimento e Gerenciamento de Requisitos no desenvolvimento do ERP CIGAM

Marcelo Petry

Continuando a falar sobre CMMI e as boas práticas de desenvolvimento e implementação, é importante registrar que os problemas na identificação e compreensão de requisitos, bem como na gestão das alterações de requisitos durante o ciclo de vida dos projetos, estão entre as principais causas para o insucesso dos projetos de software. Portanto, um bom levantamento e uma boa gestão de requisitos é fundamental para ter clientes satisfeitos, a partir de um bom andamento do projeto, dado que os requisitos são a base para a elaboração do plano de projeto. Normalmente as principais dificuldades são: garantir que os requisitos estejam completos; estimar de forma realista o esforço necessário para a implementação das funcionalidades; desenvolver produtos de acordo com os requisitos do cliente; determinar e controlar o escopo do projeto; manter-se flexível a alterações com um bom plano de comunicação, garantindo respostas rápidas e concisas ao cliente.

Então, conforme prometido no último artigo sobre este tema focado no ERP CIGAM, volto para discorrer um pouco sobre duas áreas de processos do modelo CMMI, intimamente ligadas e totalmente complementares, que são: “Gestão de Requisitos” e “Desenvolvimentos de Requisitos”. Em um primeiro momento até nos causa estranheza que sejam tratadas como duas áreas distintas e,  principalmente, que a Gestão de Requisitos (nível 2) seja tratada antes do Desenvolvimento de Requisitos (nível 3). Mas por que isto? O fato é que estas duas áreas de processos têm focos distintos, ou seja, primeiro é necessário saber o que deve ser feito, quando, qual o esforço e qual o custo para depois evoluir o como será feito. Com esta prática, as empresas que implementam este modelo constroem o como fazer a partir da prática da gestão em cases reais e aprendem com o uso do processo da gestão, gerando maturidade para a empresa, que é um dos pilares do CMMI (Modelo Integrado de Capacidade e Maturidade). A partir do entendimento do porque fica muito mais claro, simples e fácil definir o como. Dito isto, para fins didáticos e para o melhor entendimento da sequência das atividades destas áreas de processos, neste artigo seguirei uma ordem cronológica, ou seja, veremos o que são requisitos, como desenvolvê-los a partir do levantamento e análise e, por fim, como fazer a sua gestão.

 

Requisitos são as necessidades básicas do cliente, ligadas a seu produto e operações, onde são avaliadas questões como: materiais, serviços, mercado, clientes, logística, instalações, processos, pessoas, enfim, tudo aquilo que interfere no negócio. São premissas, restrições, expectativas e características, tais como especificações técnicas, prazos de entrega, garantias, tudo aquilo que o cliente “requer” do software, seja a partir de uma condição, capacidade ou necessidade indicada por um usuário ou, até, em função de um usuário com alguma ‘dEficiência’. Enfim, qualquer atributo para resolver um problema ou alcançar um objetivo, lembrando que os requisitos podem ser classificados como funcionais (funções diretas do sistema) ou não funcionais (performance, disponibilidade de recursos/estrutura, por exemplo). Para identificar estes requisitos, precisamos conhecer e entender a realidade do cliente  e isto é feito a partir da análise/levantamento de requisitos, que nada mais é que um conjunto de atividades que permitem a identificação das necessidades da empresa e dos usuários de modo a obter uma definição clara das características (requisitos) de um sistema. São essas características que descrevem o sistema em termos de funcionalidades, desempenho esperado, restrições de projeto, níveis de qualidade esperados, interface com outros elementos do sistema.

Desenvolvimento de Requisitos tem relação com PRODUZIR e ANALISAR informações. Esta área de processo descreve três tipos de requisitos: Requisitos de Cliente; Requisitos de Produto; e Requisitos de Componente de Produto. Esta combinação gera a lista de necessidades dos stackeholders relevantes, incluindo aquelas pertinentes às várias fases do ciclo de vida do produto (testes e critérios de aceitação, por exemplo) e atributos do produto (segurança, confiabilidade e manutenibilidade, por exemplo). Os requisitos também tratam as restrições causadas pela seleção de soluções de design (integração com soluções de terceiros, por exemplo). Veja abaixo um resumo da sequência de metas e práticas desta área de processos.

Estas etapas já são consideradas hoje no desenvolvimento do ERP CIGAM, onde a partir da constatação de uma demanda é necessário um contato com o cliente para que, a partir da avaliação do seu negócio e das entrevistas com os usuários e lideranças, se faça o levantamento e o detalhamento dos requisitos no documento nominado LRC (Levantamento de Requisitos do Cliente), vinculado à Ordem de Serviço (OS) da CIGAM que registra a necessidade do cliente, inclusive referenciando documentos de terceiros quando for o caso, como legislação e manuais de integração. Nos casos de projetos, são considerados também os objetivos, premissas, restrições e demais informações do Plano do Projeto. Com base nas informações destes documentos, de forma gradual e complementar, durante todo o ciclo de vida do desenvolvimento do software, o Analista de Negócios (AN) em conjunto com o Analista de Sistemas (AS) e Analista de Testes descrevem as funções do software, sendo o AN com uma visão mais funcional, o AT com um foco na definição do Roteiro de Testes e o AS com uma visão mais técnica, focando-se no ER, DFD, configurações, parametrizações, enfim, na estrutura dos programas e objetos envolvidos para facilitar e direcionar o desenvolvimento do software, bem como para garantir a manutenibilidade do software no futuro. É também na Função de Software que são identificadas as funções sucessoras e predecessoras, garantindo a rastreabilidade de todas as funções. O AS descreve, ainda, os detalhes de desenvolvimento na Solução da OS, sendo que estes detalhes são as dicas de programação, testes, pontos de maior atenção e cuidados necessários em cada etapa do desenvolvimento. É importante destacar que o padrão de interface gráfica e demais orientações quanto ao desenvolvimento estão detalhados no documento denominado Padrão de Desenvolvimento CIGAM (PDC), que orienta todos os desenvolvimentos no ERP CIGAM.

Gestão de Requisitos tem relação com GERENCIAR, ou seja, planejar, monitorar, controlar, organizar, decidir, realizar, atingir metas, enfim, garantir que os objetivos detalhados na etapa anterior (Desenvolvimento de Requisitos) sejam atingidos, conforme escopo, custo, prazo e qualidade determinados pelo projeto. Para isto, o projeto adota passos apropriados de forma a garantir que o conjunto acordado de requisitos seja gerenciado para dar suporte ao planejamento e execução das necessidades do projeto. É fundamental registrar que os projetos mudam, então, faz parte da gestão de requisitos documentar as mudanças de requisitos e seus fundamentos lógicos, mantendo rastreabilidade bidirecional entre os requisitos originais e todos os requisitos de produto e de componentes de produto. Abaixo um resumo das práticas desta área de processos.

Estas etapas também já são consideradas hoje no desenvolvimento do ERP CIGAM, mais fortemente quando as alterações estão submetidas a um PROJETO. É importante ressaltar que uma alteração se torna um projeto quando indicado pelo Analista de Negócios (AN) em função de uma alta implicação geral, ou seja, uma alteração que afete muitos clientes, uma alteração legal que afete a emissão da NF-e, por exemplo, ou, ainda, quando a estimativa de horas para o desenvolvimento ultrapassar 600 horas de trabalho. Nestes casos então, existe um plano de projeto que abrange: descrição do projeto, justificativas, objetivos; equipe de projeto; responsabilidades, expectativas (dos stakeholders); premissas; restrições; plano de riscos; plano de comunicação; cronograma; recursos; estimativas; e um plano integrado de controle de mudanças. Para certificar-se do entendimento e comprometimento da equipe do projeto com o plano do projeto, existe uma sessão específica para detalhar os critérios de aceite e, por fim, o documento é assinado por todos da equipe de projeto. Todo o controle de rastreabilidade é feito a partir dos documentos de solicitações de mudanças (vinculados ao projeto) e das versões (ativas/em estudo/obsoletas) das funções de software. No documento de Solicitação de Mudança são registradas as mudanças, o solicitante, o porquê, os benefícios, as implicações da mudança e, ainda, a análise de impacto no projeto como um todo. Se alguma mudança impactar em Escopo, Custo, Prazo ou Qualidade, será considerada uma mudança de projeto, disparando uma renegociação com o comitê de decisão e patrocinador do projeto, de acordo com o plano de comunicação. A partir da aprovação das mudanças, o processo é retomado, envolvendo novamente os Analistas de Negócios, Analistas de Sistemas e Analistas de Testes para ajustes e/ou mudanças de percursos.

A partir deste artigo foi possível ter uma ideia do que envolve o Desenvolvimento e o Gerenciamento de Requisitos, dentro da visão do modelo CMMI e, principalmente, de como isto afeta o desenvolvimento do ERP CIGAM. Todo o detalhamento do processo está descrito no manual de procedimentos da qualidade da MDC (Metodologia de Desenvolvimento CIGAM) disponível para as equipes de desenvolvimento e PMO (escritório de projetos). Em breve, publicaremos novos artigos tratando outras áreas de processos do CMMI que complementam o processo de desenvolvimento do ERP CIGAM.

Marcelo Eduardo Petry
Gerente de Produto e Tecnologia / Cigam Software Corporativo

 

 

Padrões de desenvolvimento do ERP CIGAM para Bancos de Dados

Leandro de Matos Machado

Em tempos como o de hoje, onde as aplicações em geral cada vez mais precisam ter o máximo de performance para executar suas tarefas, um grande vilão torna-se o processamento de informações contidas no banco de dados. De certa forma não se pode fugir dessa realidade, ou desse caminho obrigatório a ser percorrido, mas podemos encurtar esse trajeto mudando o local desse processamento dos dados.

Para isso, podemos utilizar o processamento pesado, ou seja, aquelas enormes regras de negócios das rotinas do ERP CIGAM diretamente no banco de dados. Podemos fazer isso sem qualquer problema através de stored-procedures, functions, triggers dentre outros objetos de bancos disponíveis em banco de dados como Oracle e SqlServer.

Nesse ponto existe um consenso quase geral, inclusive alavancado por grandes nomes e tecnologias, citando, como por exemplo, a Microsoft e o .Net Framework respectivamente. Não basta apenas escrever código para objetos de banco ou consultas, também é preciso manter uma padronização de maneira que facilite a manutenção, bem como as evoluções.

Seria uma maravilha se pudéssemos desenvolver o ERP CIGAM para apenas um banco de dados, e no momento da venda o cliente se disponibilizasse a utilizar esse banco de dados “obrigatório”. Infelizmente, isso não é possível nos dias de hoje, considerando que o cliente já pode estar utilizando um banco de dados para outros aplicativos ou até mesmo outros módulos e rotinas em que se deseja que o ERP CIGAM integre.

Neste artigo veremos algumas características dos padrões adotados para o desenvolvimento de objetos de banco de dados, considerando principalmente a realidade que o CIGAM roda em diferentes bancos de dados com a mesma aplicação e que existirão objetos de bancos equivalentes em ambos os bancos.

O padrão

Em breve iremos disponibilizar para toda a Rede CIGAM o Padrão de desenvolvimento CIGAM (PDC). O PDC irá agrupar todos os nossos documentos que falam sobre padronização (interface, banco de dados, regras de programação, etc). Especificamente sobre o padrão de desenvolvimento para bancos de dados, este capítulo tem por objetivo detalhar a forma de escrever o código do objeto ou da consulta SQL que é utilizada diretamente no ‘SQL-Command’ do uniPaaS.  Nesse capítulo encontram-se, ainda, as regras, desde a capitalização dos caracteres, indentação, como até mesmo recursos que não devem ser utilizados, servindo como base e referência para todos os programadores e, inclusive, testadores. Sempre que os padrões forem alterados, quase sempre por inclusões, todos os afetados serão notificados para que possam fazer a leitura de revisão e adequação.

Existem muitos tópicos considerados importantes, ou seja, itens que se não cumpridos tornam o objeto ou consulta totalmente incompatível com as definições propostas. Hoje, porém, vou destacar somente alguns deles para conhecermos um pouco melhor:

 

Nomes

Os nomes dos objetos obedecem a um padrão que identifica pelo prefixo o tipo do objeto. Isso identifica claramente o tipo do objeto além de facilitar a localização em caso de depurações ou manutenção das rotinas. Exemplos:

  • Stored-procedures devem ter o nome iniciando com “CGPR_”, como CGPR_CALCULA_PLANO
  • Triggers terão o nome iniciando com “CGTR_”, como CGTR_EXCLUI_PARADAS
  • Views com “CGVW_”, como CGVW_ALOCACOES_DIARIAS

Arquivos de scripts

Cada objeto será contido em um arquivo, como o mesmo nome do objeto nele contido e com a extensão de acordo com o tipo do objeto.

Além de identificar de maneira clara a rotina da aplicação de manutenção consegue identificar e seqüenciar adequadamente os objetos no momento da criação em lote. A extensão do arquivo também está padronizada de acordo com o tipo do objeto. Exemplos:

  • O script de criação da stored-procedure “CGPR_CALCULA_PLANO” será contido no arquivo “CGPR_CALCULA_PLANO.prc”
  • O script de criação da view “CGVW_ALOCACOES_DIARIAS” será contido no arquivo “CGVW_ALOCACOES_DIARIAS.vew”

SQL Ansi

Sempre optar pelo SQl Ansi, ou seja, o padrão de código que é comum entre todos os bancos de dados. Quando um recurso/função existe apenas em um banco de dados, não deverá ser utilizado, pois no momento da conversão isso fará que existam diferenças na estrutura do objeto ou mais (ou menos) objetos que na versão para outro banco. Sempre que criado um objeto para um banco, o mesmo deverá existir no outro banco também. Caso o recurso/função não comprometa a estrutura de objetos citada anteriormente, deve ser criado o equivalente no banco em que não existe. Exemplo:

  • No Oracle existe a função ‘LPad’, inexistente no SqlServer. Para utilização, foi criada a função “CGFC_LPAD” para SqlServer

Conversão

O desenvolvimento é feito para um banco de dados e apenas convertido para o outro. Não confunda conversão com reprogramação. A conversão consiste em apenas mudar a sintaxe dos objetos para o outro banco, mantendo a regra de negócio idêntica.  Isso facilita muito as manutenções, pois quando alterado em um banco pode-se identificar as mesmas variáveis, cursores, condições, blocos de repetições, etc, no objeto do outro banco.

Nomes-lógicos

Nem todos os clientes utilizam as mesmas traduções para os nomes-lógicos. Neste caso, o script de criação do objeto deve conter uma seqüência especial de caracteres para que a rotina de manutenção possa identificá-los e traduzi-los no momento da criação do objeto. Exemplo:

select cd_material

from /*nl<ESMATERIAL>*/ESMATERI

No momento da criação do objeto, a rotina de criação substituirá o texto “/*nl<ESMATERIAL>*/ESMATERI” pela tradução do nome-lógico %ESMATERIAL%.  Notamos também que em tempo de desenvolvimento a instrução acima é perfeitamente válida, tornando possível a codificação com os nomes de objetos existentes naquele ambiente.

Acabamos de conhecer um pouco dos padrões de desenvolvimento para objetos e consulta de bancos de dados adotados para o desenvolvimento do CIGAM.  Para maiores informações, verifiquem o documento na íntegra.

Até a próxima.

Leandro de Matos Machado
Programador de Sistemas / CIGAM Software Corporativo

 

 

CMMI – Boas práticas no desenvolvimento e implementação do ERP CIGAM

Marcelo Petry

Atualmente a CIGAM Corporativa mantém um projeto interno, nominado “CIGAM Rumo ao CMMI Nível 3”, em que foi instituído um grupo de trabalho onde cada integrante ficou responsável por alguns requisitos, escolhidos de forma integrada com a função que o integrante ocupa na empresa, com o intuito preparar-se para a certificação do nível 3 de maturidade do CMMI.

Os principais objetivos desta fase do projeto são: elevar o nível de maturidade das metodologias MDC (Metodologia de Desenvolvimento CIGAM) e MTC (Metodologia de Testes CIGAM), com base nas práticas do CMMI nível 3, trabalhando aspectos como a gestão do conhecimento e a gestão integrada de projetos com métodos ágeis, como forma de aumentar a satisfação da Rede CIGAM, lembrando que na fase anterior implementamos o escritório de projetos (PMO) para implementação do ERP CIGAM. Mas, afinal, o que é este tal de CMMI?

Capatibility Maturity Model Integration ou, em português, Modelo de Capacidade e Maturidade Integrada é o que conhecemos por CMMI. O CMMI é um modelo de referência que contém práticas (genéricas e específicas) para desenvolvimento, manutenção e implementação de software e tem, portanto, relação direta com os conceitos de qualidade nos processos de software, a partir da capacidade e maturidade que a empresa possui para desempenhar de forma eficiente e eficaz os processos para o desenvolvimento, manutenção e implementação de software. Foi desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon com base nas melhores práticas de trabalho, identificadas, estudadas e medidas a partir de longas pesquisas.

 

O CMMI tem 5 níveis que determinam a maturidade da empresa, sendo cada estágio uma base para o próximo. É como uma escada que deve ser subida degrau a degrau, conforme a capacidade e a maturidade da empresa. Abaixo podemos destacar os 5 níveis de maturidade do CMMI e o que, de forma sucinta, cada degrau representa, conforme imagem abaixo:

 

Nesta representação, a maturidade é medida por um conjunto de processos, sendo necessário que todos os processos até o nível requerido atinjam o nível de maturidade necessário para que a empresa seja certificada naquele nível do CMMI. São acumulativos e representam estágios que devem ser alcançados até o nível máximo de maturidade, onde o foco passa a ser a manutenção e melhoria contínua. Na imagem abaixo podemos verificar todas os processos de cada nível:

 

Algumas etapas compõem as exigências para este modelo. São elas: auto-conhecimento e capacitação, que consistem na compreensão da real situação atual e as melhorias necessárias, o  planejamento, que abrange a equipe de trabalho, execução, validação, disseminação,  momentos em que os processos recebem a implantação das práticas CMMI e, por fim, vêm as etapas de homologação e encerramento, que abrangem a validação das lições aprendidas. Na seqüência, segue o propósito de cada processo, segundo o manual do CMMI:

 

Ø  Nível 2 – Gerenciado: No nível 2 do CMMI, os processos são caracterizados por Projeto e as ações são freqüentemente reativas.

Gestão de Requisitos: O propósito da Gestão de Requisitos (REQM) é gerenciar os requisitos dos produtos e componentes de produto do projeto e identificar inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto.

Planejamento de Projeto: O propósito do Planejamento do Projeto (PP) é estabelecer e manter planos que definam as atividades de projeto.

Monitoramento e Controle de Projeto: O propósito do Monitoramento e Controle do Projeto (PMC) é proporcionar um entendimento do progresso do projeto, de forma que ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto desviar significativamente do plano.

Gestão de Acordo com Fornecedores: O propósito da Gestão de Acordo com Fornecedores (SAM) é gerenciar a aquisição de produtos de fornecedores.

Medição e Análise: O objetivo da medição e análise (MA) é desenvolver e sustentar a capacidade de medições utilizada para dar suporte às necessidades de gerenciamento de informações (indicadores).

Garantia da Qualidade de Processos e Produto: O propósito da Garantia da Qualidade de Processo e Produto (PPQA) é munir a equipe e a gerência com uma visão clara sobre os processos e seus produtos de trabalho associados.

Gestão da Configuração: O propósito da Gestão de Configuração (CM) é estabelecer e manter a integridade dos produtos de trabalho, utilizando identificação de configuração, controle de configuração, balanço de configuração e auditorias de configuração.

 

Ø  Nível 3 – Definido: No nível 3 do CMMI, os processos são caracterizados para Organização e são proativos.

Desenvolvimento de Requisitos: O propósito do Desenvolvimento de Requisitos (RD) é produzir e analisar os requisitos de cliente, de produto e de componente de produto.

Solução Técnica: O propósito da Solução Técnica (TS) é projetar, desenvolver e implementar soluções para requisitos. Soluções, designs e implementações englobam produtos, componentes de produto e processos de ciclo de vida relacionados ao produto isoladamente ou a combinações de produtos quando apropriado.

Integração de Produtos: O propósito da Integração de Produto (IP) é montar o produto a partir de componentes de produto, garantir que o produto integrado execute as funções de forma apropriada e entregar o produto.

Verificação: O propósito da Verificação (VER) é assegurar que os produtos de trabalho selecionados atendem aos seus requisitos especificados.

Validação: O propósito da Validação (VAL) é demonstrar que um produto ou componente de produto atende ao seu uso pretendido quando colocado em seu ambiente alvo.

Foco no Processo Organizacional: O propósito do Foco no Processo Organizacional (OPF) é planejar, implementar e implantar melhorias do processo organizacional com base na compreensão dos pontos fortes e pontos fracos atuais dos processos e dos ativos de processo da organização.

Definição do Processo Organizacional + IPPD: O propósito da Definição do Processo Organizacional (OPD) é estabelecer e manter um conjunto de ativos de processo da organização e padrões de ambiente de trabalho disponíveis para uso. Para IPPD, Definição do Processo Organizacional + IPPD cobre também o estabelecimento de regras e guias organizacionais que possibilitam a condução de trabalhos realizados por equipes integradas.

Treinamento Organizacional: O propósito do Treinamento Organizacional (OT) é desenvolver as habilidades e o conhecimento das pessoas para que elas possam desempenhar seus papéis de forma eficiente e eficaz.

Gestão Integrada de Projetos + IPPD: O propósito da Gestão Integrada de Projeto (OPD) é estabelecer e gerenciar o projeto e o ambiente dos stackeholders relevantes de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. Para IPPD, a Gestão Integrada de Projeto + IPPD cobre também o estabelecimento de uma visão compartilhada para o projeto e o estabelecimento de equipes integradas que irão cumprir os objetivos do projeto.

Gestão de Risco: O propósito da Gestão de Risco (RSKM) é identificar potenciais problemas antes que ocorram. Para isso, as atividades de tratamento de risco podem ser planejadas e colocadas em prática quando necessário, durante a vida do produto ou do projeto, para mitigar impactos indesejáveis na obtenção dos objetivos.

Análise de Decisão: O propósito da Análise de Decisão é analisar decisões possíveis usando um processo de avaliação formal que avalia alternativas identificadas com relação a critérios estabelecidos.

 

Espero que, a partir deste artigo, tenha ajudado no entendimento do que é o CMMI, enquanto modelo de referência com boas práticas no desenvolvimento e implementação de software. Fica a promessa de criação de novos artigos sobre o mesmo tema, onde então relacionarei cada processo do CMMI com as atividades práticas da CIGAM Corporativa no desenvolvimento e manutenção do ERP CIGAM.

 

Marcelo Eduardo Petry
Gerente de Produto e Tecnologia / Cigam Software Corporativo

 

Benefícios da unicidade e exclusividade no desenvolvimento de soluções no ERP CIGAM

Alex Nascimento

Atualmente a CIGAM está passando por uma mudança de paradigma com relação à sua tradicional metodologia de desenvolvimento. Começamos aplicando o SCRUM nas equipes trazendo uma estabilidade considerável para o nosso ERP. Agora temos pela frente um desafio maior ainda. Atender as necessidades particulares dos nossos clientes de forma única e exclusiva como os mesmos desejarem. Para isso nasceu a equipe de customizações e, fazer parte desta equipe me proporcionou perceber como a satisfação do cliente pode ser alcançada de forma simples e ágil. Nesse artigo, quero compartilhar com vocês uma ótima experiência que tive nos últimos tempos atuando na equipe de customizações.

 

Conforme publicado no artigo A Evolução do ERP CIGAM: Da nova funcionalidade à customização, por Marcelo E. Petry, quando desenvolvemos uma customização temos padrões e procedimentos a serem seguidos. Isso para que possamos atender a necessidade do cliente modificando o núcleo (kernel) do sistema o mínimo possível. Para isso, usando todo o tipo de recurso tecnológico possível, criamos aplicações de software customizadas (CAS – Custom Application Software),  que são basicamente pequenos projetos ativados apenas para determinado cliente. Explicarei detalhadamente, a seguir, usando como exemplo uma das customizações realizadas para o cliente Summit.

 

 

Caso do cliente

A necessidade que o cliente estava enfrentando é que ele utiliza controle de reserva futura com lote (funcionalidade padrão do sistema habilitada pela configuração ‘ES GE 2120 – Controlar Reserva Futura em múltiplas Unidades de Negócio’ e demais) e estava mudando o endereço físico da empresa. Com isso, havia milhares de pedidos de venda em sua base de dados que estavam reservando o estoque, impedindo que fosse possível criar as notas fiscais de transferência para o seu novo endereço. Bom, obviamente, a única solução seria desenvolver uma rotina que removesse as reservas de todos os itens de pedidos e que depois da mudança física de endereço realizada, o estoque estivesse ajustado, conseguisse retornar as reservas para os itens. Nesse caso, nada mais eficaz que customizar a solução apenas para esse cliente através de uma rotina. É a partir dessa necessidade que estarei detalhando um exemplo de customização.

 

 

Mapeando e entendendo a necessidade do cliente

Primeiramente, temos que entender claramente a necessidade do cliente. Ouvir dele o que está precisando, escutar suas ideias, discutir possíveis soluções, pensar nas consequências, acompanhar como ele opera o sistema, entre outros. Como essa troca de informações já é feita diretamente entre usuário e desenvolvedor, já começamos a agilizar o processo e trazer muita satisfação para o cliente. O fato de estar sendo ouvido por quem entende o que acontecerá por trás do sistema, passa-lhe segurança e confiança no que está sendo solicitado, além de diminuir a possibilidade de divergências nas informações. Nessa etapa, criamos o levantamento de requisitos. No meu caso, para atender a necessidade da Summit, que era bastante complexa, ficamos uma manhã discutindo e documentando o que seria realizado até obtermos o aceite.


 

Desenvolvimento da rotina

Depois de ter o levantamento de requisitos concluído, já tinha autorização prévia para o desenvolvimento da rotina que removeria as reservas e posteriormente as recolocaria. Então, por que esperar? Comecei a desenvolver no próprio cliente ao lado do usuário. Ele já dava suas opiniões sobre as telas, entendendo como funcionaria a rotina e percebendo a tamanha dificuldade para realização do processo.  Outro fator muito importante é que os testes já foram feitos e conferidos juntamente com quem utiliza o sistema. A facilidade de tratar as possíveis falhas diretamente no ambiente do cliente agregou uma rapidez no desenvolvimento impressionante.

 

 

Testes com o usuário final

Feita a rotina, bastava homologar na base de testes com o usuário. Este, por sua vez, avaliou criteriosamente cada detalhe que a rotina alterou nos itens de pedido, usou seus relatórios no CIGAM Report para conferir se realmente seus dados estavam sendo trabalhados como solicitou. O teste é uma das etapas mais difíceis e demoradas, pois estamos fazendo o “acabamento” do desenvolvimento. Após a conclusão dos testes, o cliente já sabia que tudo funcionava e sentiu segurança e confiança para permitir a execução em sua base de dados oficial.

 

 

Entregando a rotina/funcionalidade exclusiva

Essa era uma rotina chamada diretamente pelo menu CIGAM. Então para disponibilizá-la para os usuários, apenas criamos uma nova opção no menu.  Criamos essa opção usando a tecla fácil CIGAM <F10> e informando o nome público e diretório para acessar a aplicação exclusiva do cliente (ECF – uniPaaS Cabine File). 
Essa é uma prática comum para customizações que são chamadas diretamente através do menu.

 

Existem muitos casos onde a customização será ativada através de nomes lógicos. Um nome lógico apontará para o nome público, outro para a aplicação exclusiva, outro conterá o nome do botão e, assim por diante. Esses nomes lógicos ativam conectores (chamadas feitas através de Call By Name em programas do núcleo do CIGAM). Vejamos um exemplo prático abaixo:

 

Nessa imagem, mostramos um conector criado no task prefix da rotina de devoluções de saídas do CIGAM (programa CG03792). Para ativá-la, precisamos ter o nome lógico EX_CG03792TPI = S. Além disso, existe um nome lógico principal, que é comum a qualquer customização e é o EX_DISABLE_ALL, que sempre deve ser “N” (Não desabilitar) para que as customizações sejam ativadas. Se ele estiver diferente, nesse caso geralmente com “S” (Sim desabilitar), todas as customizações do ambiente serão desativadas.

No detalhe, podemos perceber a chamada do conector (linha 5 em letras azuis). Vejamos na imagem abaixo como ela é preparada. Como dito anteriormente, um nome lógico determinará o nome público (EX_CG03792TPICabPrg) e outro o caminho para aplicação exclusiva (EX_CG03792TPICab).

Na prática, esse conector estará chamando a aplicação exclusiva do cliente. Então a aplicação exclusiva estará dando o tratamento necessário para atender a necessidade do cliente, seja através de programas uniPaaS, chamadas de objetos de banco, entre outros.

 

 

Documentação

Após a conclusão da rotina, preparamos a documentação, que segue um padrão definido pela equipe de customizações em conjunto com as lideranças do desenvolvimento da CIGAM.  Nessa documentação, damos embasamento para que qualquer atendente do suporte consiga prestar auxílio  sobre alguma rotina/funcionalidade exclusiva no cliente. Explicamos os nomes lógicos que foram empregados, o nome do projeto, desenvolvedor responsável, nome públicos de programas e objetos de banco relacionados, o objetivo da customização, onde pode afetar e detalhamos como deve funcionar.

 

Por fim, o todo esse procedimento realizado no cliente levou um dia para ser concluído. O cliente esteve presente em todas as fases do desenvolvimento e pôde determinar como queria que fosse realizado. Isso trouxe um contentamento muito grande, pois o cliente sentiu-se peça fundamental do sistema. Ele determinou como tudo deveria funcionar já sabendo suas dificuldades e assim conseguiu aplicar o lema da CIGAM na prática:  Sua Vida Mais Fácil.

 

Alex Eduardo Nascimento
Desenvolvimento CIGAM / Cigam Software Corporativo

Road Map para Evolução do ERP CIGAM

Marcelo Petry

Conforme prometi no artigo onde falei sobre customização, este artigo tem por objetivo discorrer um pouco sobre o que é um Road Map e a sua relação com a evolução do ERP CIGAM. Conforme já registrado em outros artigos deste blog, já sabemos que o Road Map é o contraponto da customização e que é elaborado pelos Analistas de Negócios, porém, como é algo muito novo para todos da Rede CIGAM, vale a pena entender um pouco mais sobre o assunto.

Uma das definições para Road Map é que se trata de uma visão estendida do futuro de um campo escolhido de investigação composto de uma coletânea de conhecimento de pesquisadores nesse campo. Algumas palavras que também ajudam no entendimento são ‘guia’, ‘roteiro’ e ‘plano’. Enfim, Road Map é um plano com metas de médio e longo prazo com soluções específicas para ajudar a cumprir metas definidas na criação e/ou evolução de um produto e/ou processo, sendo que, o desenvolvimento deste plano tem pelo menos quatro finalidades:  ajudar no alinhamento dos stakeholders; ajudar na formatação da estratégia que será utilizada para que se atinja os objetivos estabelecidos;  ajudar no planejamento das atividades; e ajudar na coordenação da execução das atividades.

Enfim, a evolução do ERP CIGAM passa a acontecer com base em Road Maps, que definem quais funcionalidades o sistema deve passar a atender, por área de negócio e em dado período de tempo, que estamos definindo sempre como anual. Estes Road Maps são construídos pelos Analistas de Negócio em conjunto com a Área de Mercado, P,D&I e parceiros da Rede CIGAM. Neste momento, vale lembrar o que registrei no artigo sobre a função do Analista de Negócio, que é o profissional que “busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa, complementando funções como as de analistas de processos e analistas de sistemas, buscando unir o melhor de cada uma destas funções a partir da visão sistêmica e orientada ao negócio da empresa”.

A tarefa de montar um Road Map tem a finalidade de mantermos um alinhamento entre os objetivos estratégicos da Rede CIGAM com a equipe de desenvolvimento do ERP CIGAM. Para isto, os Analistas de Negócios avaliam pelo menos três níveis dos negócios: mercado, produtos e serviços, e tecnologia, estando sempre atentos para a evolução do mercado, analisando as oportunidades, principais ameaças e concorrentes, bem como, avaliando as customizações de forma a incorporar as melhores práticas ao produto. Desta forma, garantimos que o que oferecemos realmente é o que os clientes e o nosso mercado necessitam, e garantimos que estamos gerando valor de negócio para este público, cumprindo com a nossa missão que é de “Promover crescimento e maiores resultados a nossos clientes com nossas soluções de software e serviços”.

O planejamento do Road Map da CIGAM será anual, com revisões semestrais e entregas trimestrais, conforme liberações das versões oficiais do ERP CIGAM. Todo o controle se dará a partir do módulo de Gestão de Serviços do próprio ERP CIGAM, permitindo assim, que as OSs de sugestões aprovadas, de clientes, parceiros e internas, que se referem a uma funcionalidade do Road Map,estejam vinculadas ao Road Map, permitindo assim a gestão da evolução do produto e de como cada uma das sugestões realizadas pelos clientes e toda a Rede CIGAM estão sendo implementadas. Em breve estaremos disponibilizando para toda a rede o que irá compor o primeiro Road Map da CIGAM, com o grupo de funcionalidades que ainda pretendemos atender no ano de 2011.

Espero que a partir deste artigo tenha conseguido esclarecer sobre o que é um Road Map e sobre como usaremos esta ferramenta com o objetivo de gerir todo o processo, mas, principalmente, de evoluir o ERP CIGAM com soluções robustas de mercado de forma a impulsionar as vendas do ERP CIGAM, conforme estratégia de vendas vigente.

Marcelo Eduardo Petry
Gerente de Produto e Tecnologia / Cigam Software Corporativo

Os Analistas de Negócios na construção do ERP CIGAM e na potencialização de Projetos de Implementação

Marcelo Petry

Em tempos onde falamos de Road Maps criados pelos Analistas de Negócios CIGAM, é fundamental entender um pouco mais sobre esta função, suas habilidades e suas tarefas e o diferencial que temos ao explorar bem as suas potencialidades. É o que tentarei esclarecer neste artigo.

Na verdade, não existe uma definição única para a função de Analista de Negócios. Para os analistas da Forrester, poucas pessoas são capazes de oferecer uma definição padronizada (com conjuntos típicos de habilidades, métodos de treinamento apropriados e carreira profissional) para o cargo, pois suas funções podem variar de acordo com as necessidades e a realidade de cada empresa. No entanto, podemos destacar que, de forma mais ampla, estão entre as suas principais atribuições: o entendimento das necessidades dos stakeholders (partes interessadas), que muitas vezes têm dificuldades de externar suas necessidades; o entendimento dos requisitos de negócios; e a comunicação entre Negócio e TI. Para que consiga desempenhar estas funções, o Analista de Negócios deve entender: como a empresa trabalha; qual a razão de sua existência; seus objetivos e metas; e como a empresa busca os seus objetivos.

Segundo o IIBA (International Institute of Business Analysis), a análise de negócio possibilita entender a estrutura, as políticas e operações de uma organização e possibilita recomendar soluções para que esta organização atinja seus objetivos. O Analista de Negócios age como elo de ligação entre os integrantes de uma organização para obter, analisar, comunicar e validar necessidades de alterações em processos, políticas ou sistemas de informação. Ele entende os problemas e as oportunidades e recomenda soluções. O BABok  (Business Analysis Body of Knowledge) é um guia de referência da IIBA que resume o conhecimento dos profissionais que exercem a função de Analista de Negócios, bem como, também descreve as melhores práticas da função.

Enfim, o Analista de Negócios busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa, complementando funções como as de analistas de processos e analistas de sistemas, buscando unir o melhor de cada uma destas funções a partir da visão sistêmica e orientada ao negócio da empresa.

Na CIGAM Corporativa, as responsabilidades não são muito diferentes, porém com algumas adaptações à nossa realidade e ao nosso contexto. Para que consigam desempenhar suas funções, nossos Analistas de Negócios devem entender como os atuais e os potenciais clientes da Rede CIGAM trabalham, a razão de suas existências, seus principais objetivos e metas e como buscam estes objetivos, e identificar questões comuns de nosso mercado. A partir deste entendimento, os Analistas de Negócios devem encontrar soluções no ERP CIGAM, para que ele se torne, cada vez mais, atraente para as empresas que buscamos ter como clientes, e o diferencial em nosso mercado, de forma que possamos oferecer soluções já disponíveis no produto, evitando o custo e o tempo de espera de uma customização, potencializando o projeto de implementação. Ou então, criando um canal de comunicação para que as expectativas do cliente sejam plenamente atendidas a partir do desenvolvimento de novas funções, uma vez que o analista de negócio alinhe as expectativas dos stakeholders com a  equipe de TI (analistas de sistemas, programadores e consultores), garantindo a efetividade na entrega da solução.

Podemos registrar então que a função do Analista de Negócios é definir o futuro das evoluções do ERP CIGAM com base nas necessidades do mercado e clientes da base, analisando e detalhando as necessidades dos clientes, buscando soluções já existentes no sistema ou, a partir do levantamento de requisitos, determinando a solução funcional que deverá ser implementada pela equipe de customização ou equipe de desenvolvimento do produto. São os Analistas de Negócios os encarregados de fazer essa ligação ao elaborar a solução funcional para o desenvolvimento de novas funções de software e/ou criar facilitadores na utilização das funções do software já existentes, suavizando assim, as relações entre consultores de aplicação e clientes, impulsionando os projetos de implementação.

Ser um Analista de Negócios exige mais do que conhecimento. Exige muita capacidade de negociação, mesclando o temperamento e a habilidade de comunicação de um diplomata, com o talento analítico de um oficial do serviço secreto. Um Analista de Negócios é um elo, uma ponte, um diplomata que equilibra a freqüente discrepância entre a oferta de recursos e as demandas do negócio. Para reforçar esta afirmação, novamente trago registros da Forrester que, após uma pesquisa, descobriu que os Analistas de Negócios mais bem-sucedidos foram aqueles que conseguiram “comunicar, facilitar e analisar”.

Espero, com este artigo, ter esclarecido sobre a função do Analista de Negócios e, principalmente, sobre a importância de toda a Rede CIGAM fazer uso destes profissionais. Mais do que viabilizar negócios e garantir uma evolução efetiva do produto para atender o mercado de toda a Rede, os analistas ainda podem potencializar os projetos de implementação, ao serem envolvidos no momento certo, direcionando a implementação para uma melhor utilização de todos os recursos já disponíveis no ERP CIGAM.

Marcelo Eduardo Petry
Gerente de Produto e Tecnologia / Cigam Software Corporativo