Gestão de requisitos, uma disciplina ainda mal utilizada.

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

O gerenciamento de requisitos é uma disciplina extremamente necessária no processo de desenvolvimento de software porque ela desempenha um papel de interface entre a equipe de desenvolvimento, usuários e patrocinador do projeto. A correta identificação e descrição dos requisitos de software é um fator crítico para o sucesso do produto final de software.

Uma aplicação de software em uma empresa é idealizada para atender às necessidades do negócio. Não basta que ela possua belas interfaces gráficas atendendo a todos os requisitos de usabilidade. Se não atender às reais necessidades dos usuários, sempre haverá alguém para dizer “o sistema é muito bonito, mas....”. O problema está neste “mas...”. Com isso, o usuário está querendo dizer que a aplicação desenvolvida não resolve o problema dele. Isso não quer dizer que aplicações que atendem às necessidades dos usuários precisam ter interfaces ruins. O ideal é que o software tenha essas duas características, ou seja, tenha uma boa interface e atenda às reais necessidades do negócio.

Um problema comumente encontrado nas equipes de projeto de software é a utilização de arquitetos, projetistas e programadores para fazer a elicitação de requisitos do sistema. Este problema se reflete na baixa qualidade das descrições que frequentemente são imprecisas, inconsistentes, sem clareza, recheadas de soluções físicas e muito frequentemente ambíguas, gerando falhas na comunicação com a equipe de desenvolvimento, levando à produção de um sistema que não atende às reais necessidades dos usuários. O ideal seria a utilização de profissionais com o perfil adequado para a correta identificação, descrição e gerenciamento de todo o ciclo de vida dos requisitos.

Outro aspecto da gestão de requisitos frequentemente esquecido, é a visão corporativa que promove o alinhamento dos sistemas com a arquitetura de negócio da empresa, a qual reflete os conceitos, processos de negócio e estratégias, descritas do ponto de vista da alta administração. Infelizmente a grande maioria das empresas ainda não possui uma arquitetura de negócio bem definida e gerenciada com mecanismos que garantam que as aplicações de software implementem seus processos, estruturas e conceitos.

A disciplina de gestão de requisitos é riquíssima, mas ainda precariamente exercida nas empresas. O foco ainda está voltado somente para a descrição de casos de uso e assim mesmo não está boa, porque é feita por pessoas sem um adequado perfil. Ainda faltam muitas coisas para serem feitas, tais como obtenção da precisão na descrição dos requisitos, analise dos problemas e suas causas-raíz, definição das necessidades dos stakeholders a partir dos problemas identificados, alinhamento dos requisitos à Arquitetura de Negócio da empresa, gerenciamento da rastreabilidade e das mudanças desses requisitos ao longo do processo e, finalmente, o gerenciamento de todo o ciclo de vida de cada requisito através das disciplinas e atividades das iterações de cada fase dos ciclos de desenvolvimento e de evolução de um sistema.

Percebo claramente, nos projetos que gerencio ou que participo como mentor/coach, uma grande dificuldade dos nossos analistas em descrever conceitos e procedimentos. Estou me referindo à produção de um pequeno texto em português. É lamentável, pois percebo uma grande displicência ao escrever. Os textos não possuem precisão, clareza, objetividade e consistência. Numa rápida leitura dos requisitos de um sistema, freqüentemente encontramos inúmeras redundâncias e ambigüidades na descrição desses requisitos.

Isso tem trazido inúmeros problemas no relacionamento com fábricas de software usadas para projetar e implementar sistemas, pois criam a necessidade de reuniões complementares para clarificar, corrigir, completar, refazer e até criar novos requisitos. Isso traz problemas de prazos e conseqüentemente de custos.

Ainda temos muito que melhorar, tanto do ponto de vista técnico como do ponto de vista de redação. Lembro-me da minha professora de português no meu tempo de colégio, afirmando que para aprender a escrever, é necessária muita leitura e treino em redação. Hoje eu testifico que isso é verdade. Não estou afirmando que uma descrição de requisitos deve se comparar a uma obra literária, perfeita no conteúdo e na forma. Mas pelo menos um pouco de cuidado para não trazer problemas de entendimento.

Tomo a liberdade de aconselhar, que devemos desenvolver constantemente o bom hábito de escrever bem. Podemos fazer isso nos nossos e-mails que redigimos diariamente evitando excessos de informalidades tão populares nas trocas de mensagens em sites de relacionamento online.

Concluindo, minha sugestão é que os tomadores de decisões em um ambiente corporativo de desenvolvimento de sistemas, devem escolher analistas de negócio/requisitos que possuem perfil adequado para se especializarem no gerenciamento de requisitos nos âmbitos de projeto e corporativo. Esses analistas formarão uma equipe altamente especializada, com uma visão corporativa dos requisitos, buscando reutilização de requisitos já implementados e testados, tranzendo eficácia e eficiência aos projetos. Com esta visão corporativa, essa equipe buscará o alinhamento das Aplicações de Software com a Arquitetura de Negócio da empresa, alinhando os projetos de software ao Plano Estratégico.

Este grupo pode ser formado de diversas maneiras, variando desde uma simples célula informal, até uma unidade organizacional formalmente inserida no organograma da empresa. O que quero salientar, é que a gestão de requisitos é uma disciplina de importância estratégica, que deve receber uma especial atenção pelos tomadores de decisão em governança de TI.

São Paulo, 22 de fevereiro de 2008.

O RUP não é uma metodologia.

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

O assunto metodologia ágil tem sido foco de vários whitepapers e comentários em blogs, sites e revistas especializadas. Sempre que leio algo sobre isso, faz-me lembrar da antiga forma de desenvolver sistemas nas décadas de 70 e 80, época em que os sistemas eram mais simples, as equipes eram menores, a subcontratação de serviços de desenvolvimento ainda não era uma realidade, a preocupação com reutilização era ainda embrionária, a quantidade de sistemas em uma empresa era pequena e as mudanças de requisitos eram bem menores que as atuais.

Os aspectos relacionados à modelagem de software sempre foram foco de estudo e de incansável busca por melhoramentos. A prova disso se encontra na proliferação de novos paradigmas, técnicas de modelagem, padrões de arquitetura e de projeto, notações e ferramentas de suporte ao desenvolvimento. A UML tem se mostrado eficiente como uma notação em modelagem de software no mundo inteiro, porque oferece suporte a todo o ciclo de vida de um projeto, diferente dos antigos fluxogramas, DFD, DER, DHF e outros, que cobriam somente alguns trechos do processo deixando “vácuos” entre eles.

Os processos de software, popularmente conhecidos como metodologias de desenvolvimento de sistemas, também têm experimentado grandes evoluções. O modelo de processo seqüencial clássico, também chamado de “cascata” ou waterfall, não mais atende às exigências dos novos projetos de sistemas de software de grande porte e de elevado grau de complexidade. Esses sistemas são desenvolvidos para dar suporte a processos de negócio que são constantemente criados e modificados em busca da satisfação dos clientes, colocação de novos produtos e serviços no mercado, eficiência, agilidade e redução de custos buscando a obtenção de melhores resultados financeiros para os investidores. Tudo isso causa freqüentes modificações dos requisitos de software ainda durante o desenvolvimento do sistema, bem como a redução dos prazos para a entrega do produto final de software aos seus usuários. Por isso existe uma enorme necessidade de um processo de software que dê suporte às mudanças de requisitos e que agilize a produção e a entrega do software aos seus usuários.

O RUP se apresenta como uma proposta de solução para resolver esse problema. Contudo, devido às suas características bidimensionais além de ser incremental, iterativo, dirigido por casos de uso e centrado em arquitetura, ele tem sido muito mal interpretado pelos gerentes de projeto, analistas de sistemas, projetistas, arquitetos e implementadores de software. Sua imagem é de uma enorme e complexa metodologia, extremamente burocrática e, por isso, sem condições de solucionar o problema acima comentado. Essa imagem é uma conseqüência de interpretações equivocadas dos conceitos que suportam o RUP.

Entendo que a culpa desse equivoco de entendimento tem sido da própria Rational, atualmente da IBM, e de grande parte dos articulistas que escrevem sobre o RUP. Ele tem sido vendido e noticiado como um processo de software, ou seja, uma metodologia que as empresas devem usar em seus projetos de software. A verdade é que o RUP não é uma metodologia nem um processo de software. O RUP é um modelo de processo, ou seja, um framework (arcabouço) de boas práticas que podem ser adaptadas para uso em projetos de software.

A Object Management Group (OMG) desenvolveu uma arquitetura de processos formada por quatro níveis de abstrações, onde o nível mais alto é representado pelo Meta-Object Facility (MOF). O segundo nível, que é uma instância do MOF, referencia o Software Process Engineering Metamodel (SPEM), um metamodelo de processos de software incremental e iterativo. O terceiro nível trata de modelos de processos incrementais e iterativos instanciados a partir do SPEM, onde o RUP é um deles. Por isso os processos, atividades, artefatos, diretrizes e conceitos do RUP devem ser considerados como modelos a serem adaptados para a realidade de uma empresa ou especificamente para um projeto de software. Essa adaptação leva à criação do quarto e último nível de abstração, que trata do processo de software especificamente definido para um determinado projeto.

Conclui-se assim, que cada projeto deve ter seu próprio processo de software instanciado a partir do RUP. O próprio RUP, na disciplina Ambiente, sugere a elaboração um artefato chamado Caso de Desenvolvimento, ocasião em que o engenheiro de processo tem toda liberdade para definir o processo a ser seguido no projeto que ele irá gerenciar, ou seja, definir quais os artefatos que deverão ser produzidos no projeto.

Diante disso, a fama do RUP em ser uma metodologia burocrática é inadequada e injusta. Inadequada porque o RUP não é uma metodologia e, injusta, porque ele foi idealizado para ser customizado para projetos específicos, fato que demonstra sua elevada flexibilidade. É essa flexibilização que permite a configuração de um processo simples e ágil que dê suporte a projetos que necessitam de uma resposta mais rápida. Mas cuidado, essa configuração requer um profissional com senioridade em Engenharia de Software.

Entendo que um dos fatores que contribuem para essa fama é a sua interface com o usuário. O RUP é um sistema web que deve ser instalado na intranet da empresa. A elevadíssima quantidade de páginas cheias de hiperlinks oferece uma enorme quantidade de alternativas de navegação permitindo que usuários iniciantes venham a se perder. Em minhas palestras sobre o RUP, costumo dizer que ele deveria ter como símbolo uma bola, porque não tem começo nem fim. É como fazer compras em um supermercado. Você pode iniciar suas compras em qualquer lugar e tomar qualquer direcionamento. É totalmente ad hoc, permitindo que você possa iniciar sua leitura em qualquer ponto e tomar o caminho que desejar. Por isso, recomendo que as empresas que pretendem usar o RUP como modelo de processo devem ter engenheiros de software com total fluência no RUP para dar suporte aos gerentes no planejamento de seus projetos de software.

Algumas empresas procuram implantar modelos de processos derivados do RUP para serem usados em seus projetos. Isso é muito bom, porém perigoso. É bom porque permite tirar os excessos do RUP e propor cenários de desenvolvimento previamente configurados, constituídos por modelos de processos simplificados e customizados às idiossincrasias do ambiente de desenvolvimento da empresa. Cada cenário oferecerá uma alternativa de processo de software que deverá ser usado em uma determinada categoria de projetos. Depois da categorização do projeto o gerente terá um modelo de processo adequado para ser usado em seu projeto. Mas cuidado porque aí reside um perigo. A definição dos critérios de categorização poderá, sem querer, causar um retorno ao problema de burocratização do seu processo. E aí, não vale jogar a culpa no RUP. A culpa será sua.

Para concluir podemos dizer que o RUP não é uma metodologia. É um arcabouço de boas práticas que devem ser customizadas para aplicação específica em projetos de software, inclusive projetos ágeis, que possuem reduzidos prazos de entrega.

São Paulo, 15 de fevereiro de 2008.