Qual a diferença entre Equipe e Time?

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

Dentro do domínio da gestão de projetos, é muito comum a utilização dos termos “time” e “equipe”. Alguns, quando querem demonstrar que suas equipes são altamente coesas e costumam atingir os objetivos do projeto, escolhem o termo “time”. Será que o termo “equipe” significa um conjunto de profissionais incompetentes que não costumam atingir seus objetivos? Claro que não! Qual será a diferença entre os termos “time” e “equipe”?

O Wikcionário (http://pt.wiktionary.org) descreve “time” como um grupo de pessoas envolvidas em atividades semelhantes e descreve “equipe” como um conjunto de pessoas encarregadas de qualquer tarefa em comum. A diferença parece existir, mas não ficou clara.

A Wikipédia (http://pt.wikipedia.org), na ocasião em que consultei, descreve “equipe” como um grupo de pessoas com habilidades complementares que trabalham juntas com o fim de atingir um propósito comum. Faz ainda uma associação a uma agremiação esportiva, tal como um time de futebol.

A minha interpretação é que o termo “time” leva a entender que é um tipo especial de equipe, porque reúne pessoas com habilidades complementares. Por exemplo, um time de futebol é formado por onze jogadores onde cada um desempenha um papel diferente de tal forma que um complementa o papel do outro.

Com isso, chego à conclusão que o termo “equipe” tem um conceito mais genérico, ou seja, reúne pessoas que trabalham para atingir um determinado objetivo. Um time de futebol, neste sentido, pode ser considerado uma equipe, porque todos têm o mesmo objetivo, o qual é ganhar o jogo. Em contrapartida, podemos também ter uma equipe onde cada membro faz exatamente a mesma coisa, ou seja, possuem o mesmo papel.

No contexto da Engenharia de Software, o termo “time” poderia ser aplicado para uma equipe onde cada membro possui um papel diferente (complementar), tais como gerente do projeto, arquiteto de software, analista de negócio, projetista, programador (popularmente chamado de desenvolvedor), testador, etc. Como se vê, temos um grupo de pessoas com papeis diferentes e complementares. Creio que podemos chamar esse grupo de “time”.

Entretanto, se tivermos um grupo de programadores fazendo exatamente a mesma coisa, ou seja, programando, entendo que temos aí, uma equipe de programadores. É possível que alguém possa argumentar que não, ou seja, temos um time de programadores porque cada um está fazendo um programa (método de uma classe, stored procedure, etc.) diferente. Insisto ainda dizer que se trata de uma equipe, porque cada programador com seu respectivo programa em desenvolvimento, corresponde à uma instância de um mesmo papel.

Este é um excelente tema para uma discussão acadêmica. Para que serve? Talvez para nada... mas poderá servir como um exercício mental para desenvolvermos nossa capacidade de descrever corretamente elementos abstratos que nos cerca no nosso dia-a-dia, muito útil para Analistas de Negócio e Analistas de Requisitos.

Convido a todos a fazerem seus comentários sobre este tema. Quem sabe poderemos chegar a uma descrição consistente. Se chagarmos, poderemos colaborar com o Wikcionário e com a Wikipédia.

Bibliografia sobre BPM, Requisitos, UML, OOAD, Metodologias, etc

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

Este é o primeiro post que estou disponibilizando sobre o tema “Bibliografia”. Meu objetivo é apresentar o maior número possível de referências bibliográficas para ajudar aos profissionais em seus estudos como autodidata, bem como aos alunos de graduação e pós-graduação (lato e stricto sensu).

Posteriormente, em post futuros, irei comentar o conteúdo de cada uma dessas referências para facilitar a tão difícil tarefa de pesquisa bibliográfica necessária para a elaboração TCC (Trabalho de Conclusão de Cursos), dissertação de mestrado e doutorado.

Convido aos leitores deste blog a colaborarem conosco enviando-nos suas referências bibliográficas. O nome do colaborador irá constar junto às referências cedidas.

Segue abaixo a primeira versão das referências bibliográficas:

Bibliografia sobre processos de software (metodologias).
• KRUCHTEN, Philippe; Introdução ao RUP Rational Unified Process; Editora Ciência Moderna.
• JACOBSON, I.; BOOCH, G.; RUNBAUGH, J.; The Unified Software Development Process; Addison Wesley.

Bibliografia sobre UML (Unified Modeling Language).
• Fowler, M.; “UML Essencial – Um breve guia para a linguagem padrão de modelagem de objetos”; Bookman; 2000.
• Booch, G.; Rumbaugh J.; Jacobson I.; “UML Guia do Usuário”; Ed. Campus; 2006.
• OMG; Unified Modeling Language: Superstructure; Versão 2.1; ptc/2006-04-02.
• Larman, Craig; Utilizando UML e Padrões; 2ª Edição; Bookman, 2002.
• Pender, Tom; UML a Bíblia; Editora Campus; 2004.
• Borges, C.C.P.; Sistema de Controle de Eventos Utilizando Metodologia ICONIX; Dissertação de Mestrado; UFJP; 2005.

Bibliografia sobre Gestão de Requisitos.
• Bittner, K; Spence, I; Use Case Modeling; Addison Wesley;
• Cockburn, Alistair; Escrevendo Casos de Uso Eficazes; Bookman; 2007.
• LEFFINGWELL, D; WIDRIG, D.; Managing Software Requirements – A Unified Process; Addison Wesley.

Bibliografia sobre Análise-Design Orientado a Objetos
• Jones, M.P; Fundamentos do Desenho Orientado a Objetos com UML; Makron Books; 2001.
• Fowler, M.; “Analysis Patterns: Reusable Object Models, MA.; Addison-Wesley; 1996.

Bibliografia sobre Engenharia de Software.
• SWEBOK – Software Engineering Body of Knowledge; Versão 2004; IEEE.
• OMG – Object Management Group; UML Superstructure Specification, v2.1; ptc/2006-04-02; April/2006.

Uso de Templates

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

Template é um formulário que é usado para facilitar a criação padronizada de um documento ou artefato. Deveria ser um instrumento de trabalho que levasse o analista a realizar o seu trabalho com sucesso.

Tenho percebido que os templates, algumas vezes, se transformam em um problema para o sucesso de um projeto. Vou explicar relatando um episódio que ocorreu comigo, na ocasião em que eu estava aplicando um processo de coaching em um projeto.

Um analista estava tendo alguns problemas na descrição de um caso de uso, porque era grande e complexo, com muitos fluxos alternativos, fluxos de exceção e regras de negócio. Percebia claramente que o analista não conseguia definir corretamente os fluxos alternativos e de exceção. Para resolver o problema sugeri que ele elaborasse um diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso e, a partir desta visão pudesse definir corretamente os fluxos de eventos.

Surpreendi-me quando ele disse-me que não iria fazer o diagrama porque não era obrigatório e também não estava elencado como um produto contratado. Argumentei que embora não fosse um entregável, era importante para que ele produzisse uma descrição do caso de uso com precisão e qualidade.

Posteriormente o gerente entrou na discussão alegando que a elaboração deste diagrama não estava previsto no cronograma e que a sua elaboração iria consumir um tempo que não tinha sido planejado e pediu-me, portanto, que eu não insistisse sobre o diagrama de atividades.

A conclusão dessa história é que o caso de uso foi descrito de uma forma altamente imprecisa, incompleta, não retratando o comportamento esperado. O tempo que aquele analista gastou para descrever aquele caso de uso foi, no mínimo, três vezes maior do que ele gastaria se estivesse elaborado o tão popular diagrama de atividades.

Para concluir a história, quando a equipe de design foi realizar aquele caso de uso, criando o modelo de design com o diagrama de classes e diagrama de sequência, não conseguiram concluir o trabalho, porque o caso de uso não estava claro, era impreciso e muitas coisas não faziam sentido. Com isso, aquele analista teve que fazer vários ciclos de alterações na descrição até que tivesse totalmente pronto para atender aos rigores da equipe de desenvolvimento.

É interessante notar que além do tempo excessivo que o analista gastou na descrição inicial do caso de uso, gastou ainda muito mais tempo para fazer as correções exigidas pelos desenvolvedores, além do tempo que a equipe de desenvolvimento gastou para entender e sugerir correções para o analista.

Lembra-se do gerente do projeto? Aquele que disse que não havia tempo para gastar com o diagrama de atividades? Coitado, passa maior parte do tempo atualizando cronogramas e levando pancada do cliente, que reclama que ele não consegue cumprir o planejamento inicial.

Porque tudo isso aconteceu? Porque tanto o gerente do projeto quanto o analista de negócio/requisitos, trabalham orientados à template. Para eles, o importante é preencher os campos do template. Esquecem-se de que os diagramas da UML poderiam ser de grande ajuda para se obter o entendimento do problema e para a definição adequada de uma solução. Esses diagramas possuem a excelente propriedade de oferecer múltiplas visões da solução idealizada. Essas visões irão colaborar para uma descrição clara, precisa, consistente e não ambígua dos casos de uso.

Não tenham medo de gastar tempo na elaboração do diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso. Certamente você irá ganhar tempo no cômputo geral do projeto. Além do que você irá evitar perda de tempo da equipe de design e de implementação.

Template é um excelente instrumento de trabalho, mas antes de preenchê-lo, pense, mas pense usando os excelentes diagramas da UML.

Treinamento em Gestão de Requisitos com Casos de Uso

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


Este curso objetiva preparar profissionais especializados no gerenciamento de requisitos com casos de uso. Foi totalmente idealizado para analistas, gerentes e líderes de projetos que fazem levantamento de requisitos junto aos clientes (internos e/ou externos) e que elaboram toda a documentação necessária para o design e construção do sistema.

Não é um curso de informação. Trata-se de um curso de formação, com uma abordagem gerencial e operacional para que o aluno conclua o curso com capacidade de gerenciar e produzir requisitos especificados de forma a fazer sentido para a equipe de desenvolvimento, que tanto sofre com documentação incompleta, imprecisa, inconsistente e ambígua.

O curso faz uma abordagem gerencial ensinando técnicas de planejamento da gestão de requisitos, gerenciamento de escopo, gerenciamento de mudanças e análise de riscos dos requisitos de software. Apresenta o processo operacional da gestão dos requisitos de um projeto de software. Define uma matriz de perfis e responsabilidades dos profissionais que devem ser envolvidos e mostra a importância estratégica do gerenciamento dos requisitos no sucesso de um projeto. Para aqueles que usam metodologias baseadas no modelo de processo incremental e iterativo, o curso ensina como fazer o planejamento de iterações do projeto.

Do ponto de vista operacional, serão ensinadas técnicas de elicitação (identificação) de requisitos junto a clientes de nível estratégico, operacional e tático da empresa, fazendo análise de problemas de negócio e definindo soluções específicas para as causas-raiz dos problemas identificados. A partir do problema analisado, o curso ensina a modelar processos de negócio, regras de negócio, requisitos do cliente (features), casos de uso, requisitos não funcionais com uso na norma ISO-9126.

Programa

• Conceitos introdutórios de gestão de requisitos com casos de uso em um processo incremental e iterativo.
• Análise do problema de negócio.
• Definição das necessidades dos stakeholders a partir da análise do problema.
• Modelagem de processos de negócio como fonte de requisitos funcionais.
• A ISO-9126 como fonte de requisitos não-funcionais.
• Descrição detalhada de requisitos não-funcionais. 
• Planejamento de Gestão de Requisitos.
• Documento de Visão.
• Definição de atributos de requisitos.
• Gestão do escopo do projeto.
• Gestão de mudança de requisitos.
• Análise de riscos dos requisitos.
• Elicitação (identificação) de atores e casos de uso.
• Modelagem de casos de uso.
• Descrição detalhada de casos de uso (fluxos de eventos, pré e pós-condições, restrições, requisitos especiais, realização de regras de negócio e definição de atributos de casos de uso).
• Estruturação de modelos de casos de uso (include, extend).
• Regras de negócio.
• Glossário.
• Gestão da rastreabilidade.
• Empacotamento dos casos de uso.
• Processo de gestão de requisitos.
• Planejamento de Iterações.

Carga horária.

32 horas, distribuídas em 4 (quatro) sábados, de 9:00 até 18:00 horas com uma hora de almoço e dois coffee-breaks.

Local:

Veris – IBTA

Av. Paulista, 302, em frente a estação do metrô Brigadeiro.
São Paulo - SP. 

Data PREVISTA: 
Previsão para a primeira quinzena de Setembro/2011. 
Por ser um curso sob demanda, a data exata só será divulgada quando o número mínimo de alunos for alcançado. 
O curso será realizado em 4 (quatro) sábados. Horário: de 09:00 às 18:00 horas com intervalo de uma hora para almoço. 

Faça sua inscrição 

Fone:  (11) 9631-1247 begin_of_the_skype_highlighting            (11) 9631-1247      end_of_the_skype_highlighting;  
E-mail:  evandro@wm2info.com.br 

Regra de Negócio Não é Requisito de Software

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

Um dos problemas mais comuns que encontro no gerenciamento de requisitos é a dificuldade que os analistas de negócio (analistas de requisitos ou de sistemas) têm em diferenciar requisitos funcionais de regras de negócio.

Segundo Leffingwell, “requisito de software é uma condição ou capacidade que deve ser atendida pelo sistema”. O IEEE estende um pouco mais essa descrição: “É uma condição ou capacidade que deve ser atendida pelo software, necessária a um usuário para solucionar um problema ou atender a um objetivo”.

O RUP define Regra de Negócio como “declarações sobre políticas ou condições que devem ser satisfeitas”. Note que, ao contrário do requisito, a descrição de regra de negócio não afirma que deve ser satisfeita pelo sistema (software). Regra de negócio é uma restrição imposta pelo negócio que regulamenta o comportamento de um procedimento operacional do negócio. São políticas definidas pela administração da empresa. São originárias das leis, portarias e normas definidas por órgãos governamentais.

Regras de negócio têm vida totalmente independente de sistemas. Podem ser criadas e obedecidas sem uso de sistemas. Como exemplo, podemos citar uma microempresa totalmente desprovida de computadores ou qualquer tipo de automação de processos de negócio. A administração da empresa definiu como política, que a venda a prazo só poderá ser feita para clientes adimplentes. Note que essa política restringe as operações de venda da empresa e não precisa de sistema para ser atendida.

Como se vê, uma regra de negócio pertence somente ao domínio do negócio. Entretanto, nada impede que regras de negócio venham a ser automatizadas, isto é, seja realizada por um sistema. Neste caso deverá haver alguma funcionalidade, ou seja, algum requisito funcional que realizará a regra de negócio.

Vamos supor que a administração da empresa (do nosso exemplo) resolva automatizar o processo de vendas. Assim, o sistema deverá possuir uma funcionalidade que conterá uma condição (“IF THEN ESE”) a qual irá verificar se o cliente é adimplente. Se for adimplente, então o sistema permitirá a venda. Caso contrário o sistema irá bloquear a venda para o cliente em foco.

Portanto, uma regra de negócio pode ser expressa no formato “IF THEN ELSE”. Isso não quer dizer, também, que todo IF THEN ELSE implícito em um fluxo de eventos dentro de um caso de uso represente uma regra de negócio. Um caso de uso pode ter implicitamente um ou mais IF THEN ELSE que não corresponda a regras de negócio, mas que conduzam a variações de comportamento do caso de uso.

Como exemplo, podemos citar um caso de uso de cadastramento de cliente, onde um evento do fluxo básico verifica que o cliente já está cadastrado. O analista de requisitos define um fluxo alternativo para descrever o comportamento adequado que impeça o cadastramento redundante do cliente. Note que existe, implicitamente, um IF THEN ELSE, o qual não corresponde a uma regra de negócio. Corresponde a uma restrição de integridade de banco de dados que impede redundância de clientes. Como se vê, nem todo IF THEN ELSE corresponde a uma regra de negócio, Contudo, toda regra de negócio pode ser descrita na forma na forma de IF THEN ELSE.

Em resumo, podemos caracterizar uma regra de negócio da seguinte forma:
• A sentença que descreve uma regra de negócio não possui um caráter verbal. Sua abordagem é restritiva. Sempre possui termos tais como, “se”, “sempre que”, “somente”, “só” ou “quando”.
• Restringe o processo operacional da empresa.
• É percebida pela administração da empresa.
• Não descreve como a regra será verificada nem como as operações deverão ser realizadas. Descreve somente o que o processo irá executar em função da regra.
• Sua descrição não pode conter elementos de soluções de tecnologia. Se você estiver descrevendo uma regra de negócio e sentir a necessidade de referenciar uma solução de sistema, com certeza se trata de um requisito de software e não de uma regra de negócio.
• Tem vida própria. Poderia ser atendida sem uso de sistema.
• Pertence ao domínio do negócio e não do sistema.
• Pode ser descrito no formato “IF THEN ELSE”.

Para concluir gostaria de salientar que uma regra de negócio não é um requisito funcional, mas um requisito funcional pode realizar uma regra de negócio.

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


Proposta de um processo de gerenciamento das interações de uma organização de desenvolvimento de software com uma ou mais fábricas de software em projetos que utilizam o RUP como modelo de processo

Dissertação apresentada ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo – IPT como requisito para a obtenção do Título de Mestre em Engenharia da Computação com área de concentração em Engenharia de Software

Evandro Moreira Pinto

Resumo

O gerenciamento de projetos em organizações de desenvolvimento de software com uso do modelo de processo seqüencial clássico e com subcontratação de fábrica de software, tem sido assunto de estudos acadêmicos e largamente praticado no mercado brasileiro e internacional. No que se refere ao uso do Rational Unified Process (RUP) como modelo de processo, a literatura também tem uma boa cobertura, mas unicamente do ponto de vista da fábrica de software. No que se refere ao uso do RUP em organizações de desenvolvimento de sistemas subcontratantes de fábricas de software, a literatura é bastante escassa.

Este trabalho tem por objetivo propor mecanismos de controle das interações entre uma organização de desenvolvimento de sistemas com uma ou mais fábricas de software subcontratadas para participar da produção de um sistema desenvolvido de forma incremental e iterativa, usando o RUP como modelo de processo de software e a Unified Modeling Language (UML) como linguagem de notação. Responde perguntas tais como: Como definir os escopos de atuação da organização subcontratante e da fábrica de software subcontratada? Como controlar as interações entre essas duas organizações usando processo incremental e iterativo? A UML resolve problemas de comunicação entre equipes que trabalham de forma complementar, mas separadas geograficamente?

O resultado obtido na pesquisa foi o desacoplamento da fábrica de software em relação à organização subcontratante, eliminando a necessidade de reuniões entre as duas organizações para esclarecer ambigüidades, inconsistências, falta de clareza e completeza das especificações entregues como insumos para a fábrica de software. Com isso, passa a ser possível uma organização de desenvolvimento de software subcontratar fábricas de software geograficamente distantes em busca de qualidade, produtividade e menores custos.

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.