Mês agosto 2011

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

 

 

Porque o iBOLT é a melhor opção para o CIGAM?

Manoel Frederico

O iBOLT é a ferramenta ideal para conectar o CIGAM à nuvem. Temos abordado isso de forma repetida.

Mas quais seriam os motivos que fazem do iBOLT a melhor opção?

Vamos falar de alguns:

Baseado na plataforma uniPaaS

O iBOLT é construído sobre o uniPaaS, assim como o CIGAM. Nenhuma outra tecnologia ou ferramenta tem acesso tão fácil aos objetos de negócio do CIGAM.

Se você desejar (por exemplo) criar um WebService para cadastrar dados no CIGAM (respeitando todas as regras e validações), criar pedidos, notas fiscais, listar informações, o iBOLT tem componentes de acesso nativo à API do CIGAM para estas atividades. Veja o exemplo:

 

Nenhuma outra tecnologia/ferramenta tem acesso aos programas/rotinas/objetos do CIGAM, como o iBOLT tem.

 

Servidor Multi-Plataforma

O iBOLT está disponível em vários sistemas operacionais, acessa múltiplos bancos de dados, integra-se a diferentes webServers, diferentes sistemas de message queue e conecta-se às plataformas Java, .NET, COM, Win32, SOAPWS. Veja os detalhes aqui

 

Ambiente Gráfico e altamente produtivo

O IDE do iBOLT Studio é 100% gráfico, conferindo facilidade e extrema agilidade no desenvolvimento e manutenção de projetos de integração/automação (veja na imagem acima).

 

Ampla biblioteca de componentes

O iBOLT possui uma vasta biblioteca de componentes e serviços, cada um com um especialidade distinta e complexidade totalmente abstraída por assistentes fáceis e intuitivos. Os componentes (conectores/adaptadores) e serviços são objetos que permitem executar tarefas e conectar-se a outros sistemas. (veja na imagem mais acima).

Estes são alguns dos motivos que mostram porque a suíte iBOLT é a melhor opção de plataforma SOA, ESB, EAI ou BPM para o ERP CIGAM.

Manoel Frederico da Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

 

iBOLT na Vida Real de um Projeto CIGAM – Episódio 04: Posso ter monitoramento “real time” do meu estoque CIGAM?

Manoel Frederico

A resposta é SIM.

Ser parte da cadeia de suprimentos de seus clientes traz muitas responsabilidades à sua empresa. Não ser o elo fraco desta cadeia é primordial. Eles contam com você! Por isso, estar atento a tudo que ocorre em seus processos de produção, distribuição, logística e suprimentos é tarefa das mais importantes na preservação da sua empresa no marcado.

O CIGAM fornece informações ricas e detalhadas sobre todas as atividades, bem como agiliza todas as etapas operacionais. Mas dá para fazer mais.

Vejamos um exemplo a respeito de informações de estoque físico de um produto:

Através de várias opções de consulta e relatórios, você pode extrair toda a vida de um produto da sua carteira (compras, vendas, estoques, demandas, custos, lucratividade, etc)

Mas e se você puder “receber” as informações relevantes, sensíveis, ao invés de ter de ir atrás delas?

E se o CIGAM puder detectar o que é importante/urgente e chamar a sua atenção para isto?

E se o CIGAM for o seu “parceiro” ao invés de apenas o seu “sistema”?

Com o iBOLT, o módulo ESB/BPMS do CIGAM, esta e muitas outras possibilidades estão ao seu alcance.

Vamos voltar ao exemplo do estoque mencionado acima.

E se você (ou sua gerência) puder ser “alertado” quando o estoque físico de um material (ou grupo/subgrupo) se aproximar muito da quantidade de segurança? Ou o custo dele sofrer uma alta acentuada? Ou a demanda de saída estiver muito além da previsão de estoque físico? Ou um pedido em quantidade fora do habitual for registrado? Ou um pedido estiver pendente há muito tempo, sem produto para efetivá-lo? Ou a produção programada de um item não se efetivou?

Tanto faz. Não importa qual sejam as suas regras de negócio, ou o quanto elas sejam dinâmicas.

O servidor ESB/BPMS iBOLT pode monitorar seus dados  CIGAM em “real time”, pró-agindo em caso de qualquer desvio da normalidade:

Como estamos exemplificando a respeito de “notificações” ou “alertas”, qualquer uma destas anomalias detectadas podem ser avisadas pelo iBOLT:

No seu CIGAM:

Por e-mail:

Por SMS:

Aproveite tudo que o CIGAM pode lhe dar, e surpreenda-se com as possibilidades ao seu alcance.

 

Manoel Frederico da Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

iBOLT na Vida Real de um Projeto CIGAM – Episódio 03: Rastreando o Relacionamento com seus Clientes

Manoel Frederico

Em tempos em que o atendimento e o serviço são os diferenciais no mercado, toda atenção e cuidado no relacionamento com os clientes são necessários.

E ter um registro preciso de todos os eventos sobre qualquer assunto encaminhado com o cliente, é primordial.

Vamos tomar como exemplo o módulo “Gestão de Serviços” do CIGAM.

Você utiliza todos os recursos deste versátil módulo para registrar e gerenciar as pendências, atendimentos e serviços prestados aos seus clientes.

E vai registrando a “vida” de cada atendimento através dos acompanhamentos do ‘GS’:

Um dos recursos dos acompanhamentos é o envio de e-mail ao cliente.

Então está tudo certo: você registra os eventos do atendimento, e notifica (formalmente) seu cliente através de e-mail.

Dize-nos a lógica, que o cliente após receber a mensagem deverá respondê-la (especialmente quando o assunto ainda não foi concluído). E provavelmente fará isso da forma mais normal possível: dando um “reply” no e-mail recebido:

Fica então a questão: onde vai parar a resposta do cliente?

A prática mostra que ela ficará na “Caixa de Entrada” de algum colaborador, provavelmente alguém encarregado de cuidar dos e-mails recebidos (neste exemplo, da conta sac@suaempresa.com.br).

E isso provoca uma ruptura nos rastreamento dos “acontecimentos” relacionados ao atendimento, sem falar de atrasos ou não encaminhamentos devido a alguma mensagem que ainda não foi “vista”.

Esta é mais uma situação que o iBOLT pode resolver para você.

Um projeto iBOLT pode ficar monitoramento a conta de e-mail que você definir como sendo seu endereço a atendimento (ex: SAC), registrando as respostas dos clientes como “acompanhamentos” das respectivas OS:

Além do registro, você pode criar qualquer outra regra de negócio que seja conveniente, como abrir um pendência WorkFlow, ou avisar o cliente de que sua resposta foi recebida e encaminhada. Tudo automaticamente:

E tudo fica registrado no CIGAM, sem perda de informações ou rastreabilidade:

Entre em contato com seu canal de relacionamento CIGAM e veja como o iBOLT pode lhe auxiliar a dar um passo adiante em direção a excelência.

Manoel Frederico da Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

Integração CIGAM com Microsoft Excel utilizando o iBOLT

Adriana Mota

Não há dúvidas de que o Microsoft Excel é uma ferramenta bastante útil aos negócios, e que ele é utilizado em muitas empresas para apoiar suas operações e muitos clientes CIGAM utilizam no dia a dia. Mas também devemos reconhecer que o MS Excel expõe as empresas a um risco considerável. A utilização de  planilhas Excel pode trazer várias vulnerabilidades às empresas:

  • Dados Descentralizados. Como os colaboradores incluem dados em suas planilhas MS-Excel, a localização de informações críticas da empresa fica descentralizada e, muitas vezes, desconhecida para o departamento de TI e executivos de outros níveis.
  • Incompatibilidade de formatos de dados. Enquanto as planilhas podem começar a partir do mesmo conjunto de dados, a formatação personalizada de planilhas Excel, muitas vezes, leva a problemas de incompatibilidade. O Excel não possui a capacidade de impor um dicionário de dados comum, por exemplo.
  • Insegurança nos Dados. Depois que os dados entram em uma planilha do Excel, muitas vezes ficam disponíveis de forma desprotegida e insegura. A falta de processos automatizados para proteger as informações em planilhas, muitas vezes constitui um risco grave de segurança.
  • Trilhas fracas de auditoria. Os auditores acham muito difícil, e às vezes impossível, rastrear a origem e a modificação de dados em planilhas Excel.

A Suite de integração iBOLT da Magic Software pode ajudar a trazer ordem ao caos que envolve o uso do Microsoft Excel na maioria das empresas que utilizam este recurso. A dependência da exportação manual de dados de sistemas e a importação de dados do Excel orientada ao usuário tende a despadronizar os dados e sistemas de informação. Nas empresas que precisam confiar no Excel, o iBOLT pode ajudar a organizar os seus processos.

Com o iBOLT, um departamento de TI ou um consultor CIGAM pode configurar uma rotina de processos de negócios para lidar com planilhas importantes da empresa. Estes processos podem beneficiar a empresa com:

  • Proteção de Dados. As empresas podem criar um conjunto padrão de planilhas aprovadas que se alimentam de dados provenientes de sistemas chave como o ERP CIGAM, e outros sistemas corporativos como CRM, SCM, WMS, RH e outros. Os dados e/ou fórmulas podem ser bloqueados e a planilha em si pode ser protegida.
  • Formatos Excel Padronizados. Ao gerar uma planilha a partir de um conjunto de dados, um formato Excel  padronizado da empresa pode ser aplicado. Neste sentido, não estamos simplesmente nos referindo à formatação da célula, mas às questões mais amplas de nomes de campos, nomes de intervalos, listas, tipos de dados, nomes de planilhas, etc.
  • Centralização de Armazenamento de Dados. Um processo iBOLT pode criar triggers ou disparos que desencadeiam mudanças nas planilhas padronizadas. Assim que novos dados são inseridos , o iBOLT pode alimentar um banco de dados centralizado, gerando e-mails baseados nos novos dados, disparos de Web Services, ou qualquer uma das dezenas de outras armazenagens ou atividades relacionados ao processo.
  • Proporcionar uma trilha de auditoria. Em última instância, os processos de negócio que você projeta em torno de planilhas chave, podem fornecer uma trilha de auditoria que permite que você veja quando e como os dados da planilha entraram em outros sistemas de TI, etc. Isso também permite que você saiba quem alterou os dados e quando.

Como iBOLT facilita os processos de planilha Excel. Começando com o básico, o processo iBOLT pode ler, escrever e apagar valores e fórmulas de qualquer célula em uma planilha. Além disso, o iBOLT pode controlar a formatação de células. O iBOLT também pode gerar gráficos. Você já pode começar a ver como relatórios padronizados do Excel a partir de dados do ERP e de outros sistemas de TI são habilitados por um fluxo de processos de negócios iBOLT. Mas o componente Excel do iBOLT vai além desses conceitos básicos para permitir o controle de macros, listas, faixas, vetores e operações de planilha. Além disso, tem capacidades fundamentais para coisas como imprimir, abrir, salvar e proteger arquivos ou planilhas, e fechar o Excel.

Integração com Aplicações de Terceiros. O CIGAM podem ser incluído nos fluxos de integração de negócios para conectá-lo com o Microsoft Excel juntamente com outras aplicações, tais como Lotus Notes, Microsoft SharePoint e, outras aplicações do Microsoft Office, como o MS-Word, MS-PowerPoint, MS-Access e MS Publisher.  Além disso, portais, sistemas de entrada de pedidos, aplicações legadas, entre outras aplicações de software podem ser integradas com o Excel.

Informações adicionais. Para mais detalhes sobre os procedimentos de integração automatizada com o Excel consulte a documentação do iBOLT disponível no DevNet, ou diretamente com a Magic Software Brasil.

Adriana Mota
Comercial / Magic Software Brasil

Adaptação de Post de Glenn Johnson – Vice Presidente Senior na Magic Software Enterprises

 

Fábrica de projetos iBOLT, uniPaaS e Banco de Dados CIGAM

Magic Software Brasil

Em linha com a estratégia de customização do ERP CIGAM, os parceiros e clientes CIGAM agora podem contar com a fábrica de projetos da CIGAM Vitalbyte, de Porto Alegre, que está investindo em uma equipe de desenvolvedores.

Além de longa experiência com o ERP CIGAM, a Vitalbyte, ou Cigam Porto Alegre, como é conhecida, tem também experiência em Banco de Dados, iBOLT e uniPaaS e, com o apoio da CIGAM Corporativa, está colocando seus serviços à disposição de toda a Rede CIGAM.

Aproveitem esta nova opção para trazer ainda mais o conceito de Empresa em Tempo Real com o CIGAM, através da criação de projetos específicos de integração com iBOLT, customização e desenvolvimento com uniPaaS, e Banco de Dados.

Parabéns à Vitalbyte pela iniciativa!

Para orçamentos e maiores informações, entre em contato com:

Otávio Düvelius Ott
Cigam Porto Alegre – Vitalbyte
www.vitalbyte.com.br

Fone: (51) 3019-0333
Ou envie um e-mail para: otavio@vitalbyte.com.br

 

Equipe de Marketing da Magic Software Brasil