Continuando meu relato sobre a evolução das Metodologias de desenvolvimento de Software (que teve início com o post sobre modelo cascata e depois com o modelo espiral), este post de hoje trata do primeiro grande salto feito nessa área da TI, o surgimento do RUP.
Antes do surgimento do RUP, o desenvolvimento de software era baseado em processos como: cascata e espiral, que encareciam o produto pois não previam alterações de requisitos e dificultavam a comunicação da equipe.
O RUP surgiu em 1996 visando fortalecer a comunicação entre os envolvidos no projeto e organizar o desenvolvimento de software. Trazendo as características consideradas aproveitáveis dos modelos anteriores, mas agregando um conjunto de boas práticas e a modelagem do sistema.
Três termos chaves do RUP são Artefatos, Iteração e Modelagem, a seguir falamos um pouco mais sobre esses pontos principais.
Artefatos:
Antes de criticarmos, vamos entender o por que de tanta papelada no processo Unificado.
Dentro de uma equipe de desenvolvimento de software RUPiana nos deparamos com muitos papéis, há uma EQUIPE de Modelagem de Negócio, Requisitos, Análise e Design, Implantação, Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e uma equipe de Ambiente. Cada uma dessas equipes é composta de 3 a 10, 20 pessoas.
Como o RUP trabalha com Iterações, a troca de informação entre essas equipes passa a ser mais constante (se comparada com a comunicação dessas equipes no modelo Espiral e até mesmo Cascata), para organizar e assegurar o trabalho e as informações trocadas entre essas equipes há a necessidade de se documentar praticamente tudo o que é feito, surgiram assim os inúmeros artefatos que foram criados com a melhor das intenções, mas se tornaram o grande ponto fraco do RUP.
Gerênciar e controlar as mudanças de todos esses documentos passa a ser algo mais trabalhoso do que o próprio desenvolvimento do software. E passou a ser cada vez mais difícil encontrar artefatos que estavam atualizados com as mudanças ocorridas no sistema.
Iteração:
O RUP introduziu o conceito de Iterações, e sempre que vejo alguém dizer ERRONEAMENTE que as Metodologias Ágeis se diferenciam do RUP por utilizarem Iterações, me irrita e preocupa. Será que aquela pessoa estudou para perceber quais pontos REALMETE tornam o desenvolvimento ágil melhor que o RUP, ou só ta curtindo a moda?
Conforme vemos na imagem acima, o RUP possui uma divisão entre as atividade estáticas (Iniciação, Elaboração, Construção e Transição) dentre as quais pode ocorrer uma ou mais ITERAÇÕES das atividades dinâmicas (Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto, Ambiente). Evidente que nas primeiras fases a maioria do tempo é focado em Modelagem de Negócio e Requisitos, que vai reduzindo com o passar das fases e ao mesmo tempo, aumenta a execução das últimas disciplinas nas últimas fases.
Ao fim de cada iteração, assim como veremos em metodologias ágeis, o que se deve ter é uma nova característica funcional finalizada, mesmo que ela não seja entregue ao cliente. Mas isso ajuda a mensurar o desenvolvimento e controlar custos, prazos e qualidade.
Modelagem:
A UML surge para favorecer a comunicação. Os diagramas UML pretendem com representação gráfica permitir a todos os envolvidos no desenvolvimento do software possam visualizar, projetar e construir.
Através da modelagem UML pode-se fazer uma interface amigável que consiga comunicar as regras de negócio e as a linguagens de programação.
Na versão 2.0 da UML, temos os seguintes diagramas:
- Diagrama de Classe – apresentam uma visualização das classes, com atributos, métodos, generalizações e associações, existentes no sistema.
- Diagrama de Caso de Uso – representam as interações do software com os usuários ou sistemas externos necessárias para se obter um resultado.
- Diagrama de Atividade – descreve as atividades e ações executadas em cada funcionalidade do sistema.
- Diagrama de Seqüência – esse diagrama apresenta a seqüência da comunicação realizadas entre os sujeitos numa determinada interação.
- Diagrama de Comunicação – nas versões 1.x da UML eram denominados diagramas de colaboração. Esses diagramas são uma alternativa ao diagrama de seqüência, mudando-se um pouco a representação, mas com o mesmo objetivo.
- Diagrama de Visão Geral de Interação – combina os elementos dos diagramas de atividades e seqüência, permitindo visualizar o trabalho em conjunto de interações complexas.
- Diagrama de Estado – apresenta os possíveis estados que um objeto pode possuir durante a execução do software e quais atividades realizam a transição desses estados.
- Diagrama Temporal – complementa as informações dos diagramas de classe e de estados. Com esse diagrama podemos visualizar o que desencadeia uma mudança de estado e as conseqüências dessa mudança.
- Diagrama de Componente – modela como os componentes estão organizados numa execução e suas dependências. Pode representar tanto componentes lógicos, quanto físicos.
- Diagrama de Estrutura Composta – descreve as colaborações entre as classes do sistema e suas interações. Isso permite visualizar quais os aspectos essenciais para tarefas específicas.
SOMMERVILLE, I. (2007). Software Engineering. 8th ed.
PRESSMAN, R. (2006). Engenharia de Software. 6ª ed.
KRUCHTEN, P. (2003). Introdução ao RUP - Rational Unified Process. 2ª ed.
TRISTACCI, C. (2010). Rational Unified Process – RUP. Acesso em 30 de outubro de 2010.
TRAA, J. Rationa Unified Process VS Microsoft Solutions Framework: A comparative study. (s.d). Netherlands. Dissertação (mestrado) - Erasmus University Rotterdam.
KIMMEL, P. (2005). UML Demystified. Única ed.
CASAGRANDE, C. C. (2007). Minimizando dúvidas de análise no desenvolvimento de softwares, aplicado a metodologia. Trabalho de Conclusão de Curso (Graduação) – Departamento de Informática e Estatística, Universidade Federal de Santa Catarina, Florianópolis - SC.
ERIKSSON, H; PENKER, M. LYONS, B. (2004). UML 2 Toolkit. Única ed.
IBM. Understanding RUP roles. Acesso em 02 de setembro de 2010.
Nenhum comentário:
Postar um comentário