sábado, 7 de março de 2009

Desmistificando o MPS.BR – Gerência de Requisitos (GRE)

Nos dois últimos artigos desta série, vimos alguns pontos chaves sobre esse modelo de melhoria de processo, o MPS.BR. Tentei mostrar que um processo realmente maduro é aquele que consegue os melhores resultados ao menor custo possível. Alguns talvez digam que essa é a definição de um processo apenas eficiente e não necessariamente maduro. Entretanto, qualquer madureza que venhamos a desejar com o desenvolvimento de software tem exclusivamente um único objetivo: lucro. Mas vale ressaltar que, quando digo “lucro”, estou pensando em algo que seja sustentável. Assim, um processo maduro é aquele que consegue os melhores resultados de forma sustentável ao menor custo possível. O MPS.BR se propõe a ajudar nisso de forma gradual, por meio de sucessivos níveis de amadurecimento. A intenção é tornar o processo de desenvolvimento como um todo mais transparente, gerenciável e menos arriscado para a organização.
Diferentes tipos de processos
Cada nível de amadurecimento implica na implementação de alguns processos (ou, podemos dizer, subprocessos) relacionados com o desenvolvimento de software. Alguns estão diretamente relacionados com o desenvolvimento. Já outros afetam mais a gestão dos demais processos do que o desenvolvimento propriamente dito. Ou seja, alguns processos são inseridos no desenvolvimento para dar-lhes transparência. Enquanto outros permeiam o desenvolvimento como um todo para garantir a sua gerenciabilidade. A redução de riscos é praticamente uma conseqüência disso tudo. E a produtividade também.
Esses diferentes tipos de processos ficam bem claros quando estudamos o CMMI, pois ele até mesmo os classifica.
Os resultados indicam a maturidade do processo
Os processos implementados em cada nível também vão amadurecendo ao passo que outros níveis de maturidade são alcançados. Esse amadurecimento é medido por meio de atributos do processo (AP). Em outras palavras, um processo no Nível A possui mais atributos que o mesmo processo no Nível F por exemplo. O quê esses atributos representam vai ficar mais claro quando analisarmos cada um dos processos separadamente. Mas ainda surge outra pergunta: Como saber se um processo está, ou não, apresentando certos atributos? Uma forma de saber isso é por observar a execução do processo e avaliá-lo. Mas fazer essa avaliação seria algo muito subjetivo. Sem falar que seria algo muito caro de se fazer. Para mitigar essa subjetividade e tornar o processo de avaliação mais barato, o MPS.BR estabelece alguns resultados esperados (RAP) para cada atributo. Isso facilita a avaliação de cada processo, pois agora não precisamos mais observar a sua execução – é necessário apenas verificar os seus resultados. E esses resultados se traduzem basicamente em duas coisas: normas e registros. A relação é mais ou menos assim: a área de TI define, através de normas, atividades para a realização de registros. Os registros são verificados por atividades também definidas em normas. Simples assim.
O Nível G
Dito isso, vamos agora prosseguir com a nossa análise dos níveis de amadurecimento. Neste artigo vou introduzir o Nível G e tentar desmistificar um de seus processos: Gerência de Requisitos (GRE). No próximo artigo, abordarei a gerência de projetos (GPR) e como ela se integra com a GRE.
O Nível G é o primeiro passo para iniciar o amadurecimento dos processos de desenvolvimento de software. Apesar de ser o primeiro passo, não é o mais difícil. Mesmo assim, talvez envolva alguma mudança organizacional que muito depende da forma como a área de desenvolvimento de software já trabalha. Para algumas empresas, vai ser mais fácil. Para outras, mais difícil.
Nesse nível, ainda não se exige muita maturidade dos processos – até por que, em muitos casos, eles terão acabado de nascer. Essa maturidade inicial é representada por dois APs.
O primeiro deles é o AP 1.1, o processo é executado. A verificação desse AP se dá por meio de apenas um RAP: o processo atinge seus resultados definidos. Em outras palavras, esse RAP diz que os resultados de um dado processo precisam ser previamente definidos e observados. Um processo terá o AP 1.1 se esses resultados forem observados durante ou após a sua execução. Aí vem a pergunta: Definidos de que forma? Obviamente em uma norma que descreva as atividades do processo. Mais quais resultados devem ser definidos? O MPS.BR também sugere. Além dos RAPs, o modelo define resultados esperados específicos para cada processo. Se esses resultados forem atingidos, podemos dizer que o processo apresenta o AP 1.1.
O segundo AP exigido pelo Nível G é o AP 2.1, o processo é gerenciado. Esse atributo é um pouco mais complexo que o AP 1.1. Esse atributo possui nove RAPs. Eu poderia listar aqui todos eles e explicar o que cada um significa. Mas prefiro resumir tudo em uma única frase: O AP 2.1 exige que sejam definidas atividades de gerenciamento para cada processo. Que atividades são essas? Ora, aquelas que são ensinadas em todo curso de administração. Lembra do “planejar-organizar-executar-controlar”? Pois é. Pegue isso e coloque uma boa pitada de comunicação e padronização. Pronto! Eis o AP 2.1.
Gerência de Requisitos (GRE)
Vamos agora olhar mais de perto um dos processos exigidos pelo Nível G. Como o nome já indica, trata-se de um processo diretamente relacionado com o desenvolvimento de software – afinal de contas, tem a ver com uma das disciplinas mais importantes da engenharia de software: requisitos.
É bem provável que sua empresa já possua diversas atividades relacionadas com requisitos. Mas será que vocês possuem um processo para gerenciar os requisitos? Que importância a sua empresa dá aos requisitos de um projeto? As estatísticas mostram que a maioria dos projetos que fracassam é devido a problemas de gerenciamento de requisitos. O MPS.BR tenta corrigir essa falha básica por exigir isso logo no primeiro nível de amadurecimento.
Para atender ao AP 1.1, esse processo precisa ser executado. Sabemos se ele está sendo executado através da observação de quatro resultados esperados.
O primeiro resultado esperado é um entendimento dos requisitos junto aos fornecedores de requisitos. O que é esse entendimento? Simples, um documento onde os requisitos devem estar registrados. E que são os fornecedores? Aqueles que estão te contratando ou, se for o caso de um projeto interno, aqueles que estão demandando o software.
O segundo resultado diz respeito à aprovação dos requisitos com o uso de critérios objetivos. Essa aprovação pode tão simplesmente ser uma assinatura no documento de registro dos requisitos. E que dizer dos critérios de aprovação? Bom, alguém precisa dizer que os requisitos foram registrados de tal forma que seja possível desenvolver o software. Estou me referindo a coisas como clareza, viabilidade, completude e assim por diante. Em suma, alguém precisa dizer que os requisitos estão ok. Pronto.
A rastreabilidade dos requisitos é o terceiro resultado esperado da GRE. Em outras palavras, a partir de um caso de uso, por exemplo, deve ser possível identificar os componentes que foram produzidos para atender a ele. Ah, a rastreabilidade deve ser bidirecional, ou seja, a partir de um componente, deve ser possível identificar os requisitos. O MPS.BR exige que essa rastreabilidade seja mantida. Na prática isso envolve manter algum registro de componentes e requisitos ou adquirir uma ferramenta que gere automaticamente esses registros para você – ferramentas de referência cruzada, por exemplo.
O quarto resultado esperado da GRE é a revisão dos produtos de trabalho para identificar e corrigir desvios em relação ao que foi requisitado. Essa revisão pode muito bem ser um teste do tipo caixa branca para verificar o atendimento dos requisitos. Outros requisitos não funcionais talvez precisem de verificações mais técnicas, como revisão de código, de arquitetura e de infraestrutura.
Por fim, temos o quinto e último resultado esperado. O MPS.BR define que qualquer mudança dos requisitos seja gerenciada ao longo do processo. O que isso significa? Significa que para qualquer mudança nos requisitos, você terá que verificar os resultados esperados 2, 3 e 4 descritos acima. Ou seja, toda mudança precisará de uma nova aprovação, que por sua vez vai gerar um requisito rastreável e que por sua vez vai precisar de revisões para verificar o seu atendimento.
Conclusão
Essa primeira olhada no Nível G pode parecer um pouco enfadonha. Mas prometo que alguns conceitos vão ficar mais claros quando analisarmos outros processos. Uma coisa que você não pode esquecer é que boa parte do MPS.BR vai se traduzir, no momento da sua implementação, em normas e registros. Normas e registros. Lembre-se disso. Essa é a parte concreta de tudo que é implementado. A parte abstrata são as atividades para fazer tudo isso acontecer.
No próximo artigo vou responder algumas perguntas que restaram sobre a GRE (e que você já deve estar se fazendo neste momento) e introduzir a Gerência de Projetos.
Um abraço e até o próximo artigo.

7 comentários:

Bruno Henrique disse...

Cara...estou achando muito bom esses artigos!

beto disse...

, o que se entendo por equilíbrio de requisitos?

beto disse...

Perdão!
O que quer dizer "equilíbrio de requisitos"?

Samuel Diniz Casimiro disse...

@beto Você leu isso no meu artigo? Se não, onde?

Monica disse...

Bom dia, espero que ainda veja esse comentário, já que artigo é de 2009. Mas enfim, primeiro obrigada pela iniciativa. Esses artigos me ajudaram bastante. E agora vem a minha dúvida: não ficou claro pra mim onde entram os RAPs já que para cada processo vc utiliza os resultados esperados para a implementação do processo (GPR1, GPR2, etc..) Seria na verificação? Uma avaliação posterior para ver se o processo antede ao AP?

Samuel Diniz Casimiro disse...

Oi Mónica,

Obrigado pelo seu comentário.

Os RAPs, falando de forma simples, são a consequência do processo já implementado. Na implementação o ideal seria focar nos APs e não nos RAPs. Em um projeto de implementação típico, os RAPs deveriam ser verificados apenas ao final da implementação. Focar primeiramente nos APs vai resultar em um processo mais sólido, ao invés de um processo apenas para "inglês ver". Ou seja, na implementação, não é bom focar nem nos RAPs nem nos resultados específicos - é melhor focar nos atributos propostos pelo modelo.

Espero ter ajudado.

Monica disse...

Muito obrigada. Ajudou sim. E obrigada por responder tão rápido.