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.
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.
3 comentários:
evandro por gentileza,sera q vc poderia me ajudar... eu comecei faculdade agora na area de sistema e o professor pediu um trabalho sobre mds.... ele quer q inventemos um caso de mds... e junto quer um dfd.. sera q vc pode me ajudar... eu nao sei fazer ja tentei de tudo...eu preciso do trabahlo urgentemente... antes de segunda feira.. meu email é nico82@bol.com.br.. se vc puder me ajudar agradeço
Bem, a impressão que dá é que tudo passa, tudo passará, como foram,
Yordon, Jackson, Tomm Demarco, Martin, Chris Gane, HIPO (IBM), BSP et...
Um grande abraço e sucesso!
Ppompeu
Muitos profissionais confundem Waterfall com RUP, pela simples conclusão de que as iterações "não são necessárias" e que manutenções evolutivas fazem parte de processos e não projetos.
Gerentes de projeto entendem que é necessária apenas uma iteração e que qualquer manutenção evolutiva é um novo projeto. Eu não sei até onde isso tá certo. Mas vou me aprofundar no assunto.
Postar um comentário