Destaques Archives - Página 2 de 4 - Blog Magic CigamBlog Magic Cigam
Desenvolvimento e Gerenciamento de Requisitos no desenvolvimento do ERP CIGAM
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.
Porque o iBOLT é a melhor opção para o CIGAM?
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, SOAP–WS. 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.
iBOLT na Vida Real de um Projeto CIGAM – Episódio 03: Rastreando o Relacionamento com seus Clientes
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.
Integração CIGAM com Microsoft Excel utilizando o iBOLT
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.
Adaptação de Post de Glenn Johnson – Vice Presidente Senior na Magic Software Enterprises
in Destaques, Magic xpi, Negócios e Estratégia
O que é o iBOLT e qual é sua importância em um projeto CIGAM?
O iBOLT é o BPMS oficial da solução CIGAM, e pode ser facilmente implantado junto ao ERP. É um produto da Magic Software, que permite customizar e agilizar os processos empresariais, possibilitando a integração de processos entre o CIGAM e diversas aplicações, plataformas e bases de dados.
O iBOLT simplifica o processo de integração, separando a lógica de negócios da integração tecnológica. Você pode fazer alterações nos modelos de negócios, sem afetar o negócio real ou as camadas técnicas da empresa, ou seja, sem afetar a rotina normal do dia a dia da empresa.
Por que é tão importante ter uma suite de integração de negócios abrangente?
Os analistas do setor estimam que as empresas gastam entre 20 e 40% dos seus orçamentos de TI em projetos de integração de negócios. A complexidade da tarefa de integração de sistemas é grande e aumenta cada vez mais devido à tendência de ampliação da cadeia de valor das empresas, onde surgem vários novos pontos de integração, tanto internos como externos à organização.
Quais são os objetivos de um projeto de integração em um projeto com o CIGAM?
Os projetos de integração iBOLT, garantem que:
* O CIGAM pode conversar com sistemas de front-end, como um site de e-commerce, por exemplo;
* O CIGAM pode conversar com sistemas legados;
* Aplicações e processos já existentes podem ser melhorados, através da automação de processos, protegendo o investimento já efetuado no CIGAM e nas outras aplicações envolvidas;
* O CIGAM pode conversar com o próprio CIGAM, criando cenários de automação de processos;
* A conectividade está disponível de forma a superar barreiras técnicas, tais como aplicações e bancos de dados diferentes;
* O ambiente integrado opera de forma totalmente transparente.
O que as ferramentas do iBOLT incluem?
O iBOLT inclui mais de 60 conectores, adaptadores e serviços que simplificam os projetos de integração.
Que tipos de usuários trabalham com iBOLT?
O iBOLT foi criado tanto para usuários técnicos quanto para não técnicos, proporcionando-lhes um ambiente de integração completo que apóia toda a abrangência de projetos Business Process Management (BPM) e Enterprise Application Integration (EAI). O conjunto de ferramentas de configuração e interfaces exclusivas do iBOLT potencializa toda a empresa, permitindo a total participação e colaboração em todas as fases do processo de integração, tanto das equipes de negócios quanto das equipes de TI.
Que capacidades de mapeamento de dados o iBOLT inclui?
As capacidades de mapeamento de dados exclusivas do iBOLT permitem trabalhar com todas as fontes de dados e destinos, com uma visão totalmente gráfica. Além disso, o iBOLT provê um gateway nativo para MS-SQL, My-SQL, Oracle DB2/400 e ODBC que permite que os dados sejam facilmente manipulados, através de um Gerador SQL baseado em wizards.
O iBOLT tem suporte a SOA?
Totalmente. O conceito de design fundamental do iBOLT é baseado no estabelecimento de funções de negócios e na exposição de processos de negócios como Serviços.
O que é exatamente o SOA e por que ele é importante para o processo de integração?
Diferente de arquiteturas firmemente acopladas onde as alterações em qualquer componente podem levar a mudanças de muitos outros componentes, SOA (Service-Oriented Architecture) é uma arquitetura que permite um desacoplamento entre componentes. Em um projeto SOA, você pode fazer alterações em componentes individuais sem ter que fazer alterações de outros componentes da arquitetura, permitindo assim que a sua seja muito mais ágil nas respostas às necessidades de mudanças.
Como o iBOLT permite SOA?
O Editor de Fluxos do iBOLT permite que você mapeie fluxos de negócios individuais que compõem cada processo de negócios, definindo as mensagens e dados trocados entre os componentes, e também suas interações e regras.
O que são Aplicações Compostas?
As aplicações compostas são montadas utilizando tanto componentes de várias aplicações quanto funcionalidades adicionais desenvolvidas especificamente como serviços. Os componentes individuais de uma Aplicação Composta são criados de forma independente dos outros, mas podem ser chamados e reutilizados várias vezes em diferentes aplicações. Como resultado, sua empresa pode obter soluções mais rapidamente com menos recursos – e garantir a coerência em toda a empresa.
O que o iBOLT Business Integration Suite inclui?
O iBOLT consiste de três módulos principais:
• iBOLT Studio: componente base, ambiente de implantação de integração e processos de negócios de alto nível que inclui o Business Process Editor para a modelagem real de processos, o Topology Editor que fornece uma representação gráfica das conexões entre as aplicações e os servidores, o Flow Editor que define os processos que existem entre as aplicações e os conectores e adaptadores pré-configurados do iBOLT.
• iBOLT Server: conduz o projeto de integração e gerencia todos os aspectos da implantação incluindo a execução dos fluxos, o encaminhamento dos fluxos para diferentes servidores, e o acompanhamento de funcionalidades.
• iBOLT Monitor: oferece uma forma de visualizar a topologia de todos os servidores para monitorar atividades, ganhar visibilidade para o fluxo de negócios e processos, e obter em tempo real as informações de performance.
Como o iBOLT reduz custos e aumenta a eficiência?
Em um ambiente integrado, uma única alteração em uma aplicação, sistema, ou banco de dados pode gerar a necessidade de reformulação de muitos processos e conectores. O iBOLT Studio, com sua arquitetura portável e gateways e conectores embutidos, dá aos desenvolvedores uma forma de personalizar sistemas integrados rapidamente e, como resultado, os custos de manutenção são reduzidos.
Os diferenciais de cada negócio são mantidos com projetos de integração e automação personalizados para cada empresa, trazendo o conceito de "Empresa em Tempo Real", agregando valor e eficiência aos negócios e processos.
iBOLT+CIGAM = Empresa em Tempo Real
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.
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:
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
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"
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
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.