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

 

 

Título2 Comments

  1. “é 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.”

    sabe dizer se têm havido uma mudança no perfil dos profissionais que são designados à estas tarefas? para estas tarefas é melhor a multidisciplinaridade ou a especialização? me parece que as empresas ainda se preocupam mais com as competências técnicas de seus funcionários e esquecem um pouco que nesta interação com clientes principalmente, as competências humanas tão ou mais relevantes. A compreensão do que se quer não envolve, principalmente, a capacidade de ouvir, de se colocar no lugar do cliente, etc.

    • Tudo bem Bira?

      Levantaste uma boa questão… e no meu entendimento, o grande segredo está na comunicação entre pessoas que tem realidades muito distintas… não é má vontade, mas pura e simples falta de contextualização e condição de conhecimento daquilo que é obvio para um e não para o outro… e não é novidade que a comunicação, ou a falta dela, seja o grande problema da humanidade na atualidade… conseguir ações que consigam dirimir as falhas na comunicação é o grande desafio de todas as empresas.

      Aqui na CIGAM pensamos em duas estratégias para diminuir estas ocorrências de falhas na comunicação… Primeiramente criamos um novo setor na empresa que é desempenhada por Analistas de Negócios, formada por profissionais experientes (em CIGAM, gestão e em negócio), sendo alguns oriundos da implementação (consultores de aplicação) e outros do desenvolvimento (analistas de sistemas). Estes profissionais interagem entre si, compartilhando conhecimentos e experiências passadas, pois conhecem muito das regras de negócios, de gestão de uma empresa e do nosso produto (ERP CIGAM), sendo eles, então, os responsáveis pela comunicação entre o cliente e a nossa equipe mais técnica, seja a de implementação, seja a de desenvolvimento. A segunda ação foi a criação do setor de customização, onde temos desenvolvedores especialistas para trabalhar diretamente nos clientes desenvolvendo juntamente com os usuários chaves, as customizações mais específicas, oferecendo para o cliente soluções mais rápidas e direcionadas para a realidade dele.

      Bira, a resposta para a tua pergunta, na minha opinião, é que precisamos ter mais pessoas fazendo a tradução/decodificação da informação que trafega entre as empresas e o cliente final… Precisamos dos dois tipos de profissionais… do generalista e do especialista… e quanto mais um conseguir avançar em mais esferas do outro, melhor a qualidade da comunicação e menos chances de falhas teremos. Fica a sugestão de alguns artigos publicados anteriormente neste mesmo blog sobre estes assuntos (Função do Analista de Negócios e Customização):

      – A Evolução do ERP CIGAM: Da nova funcionalidade à customização
      – Os Analistas de Negócios na construção do ERP CIGAM e na potencialização de Projetos de Implementação
      – Road Map para Evolução do ERP CIGAM

      Espero que tenha ajudado… e continuo a disposição.

      Atenciosamente,

      Marcelo Eduardo Petry | Gerente de Produto e Tecnologia | CIGAM Corporativa

Novo Comentário