terça-feira, 22 de maio de 2012

RUP para Concursos - Parte 2 - Metodologia e Conceitos Chave

Metodologia
É composta por um Processo de Desenvolvimento que é configurado especificamente para a sua organização. É composta por um conjunto de métodos e práticas bem definidos e que possuem responsáveis (papéis), entradas, saídas e ordem de precedência. Inclui ferramentas, tecnologias, pessoas, padrões e guias.

Ao instânciar um processo de desenvolvimento baseado no RUP, o que se está procurando é definir quem faz (papéis)o que é feito (produtos de trabalho) , como é feito (descrições das tarefas) e quando é feito (fluxos de trabalho). Nas disciplinas existem papéis que executam determinada tarefa ou atividade que resulta em um produto de trabalho ou artefato. Um exemplo seria a disciplina de Requisitos possui o papel Analista de Sistemas que deve executar a tarefa Estruturar Modelo de Caso de Uso e o produto de trabalho gerado será o Modelo de Caso de Uso.

Você terá uma metodologia baseada no RUP e não a metodologia RUP em sí. A organização deve pegar o RUP e adaptá-lo de acordo com as necessidades e assim, criar o seu próprio processo de desenvolvimento de software.

A metodologia conta com alguns componentes: Modelos, padrões, guias, equipes treinadas, linguagem padrão (UML) e ferramentas de automação.

Benefícios da Metodologia embasada no RUP:  

Qualidade de Software através da utilização das melhores práticas de mercado, que já foram testadas e comprovadas.

Maior produtividade e Previsibilidade porque as equipes seguem um processo definido, o que evita conflitos dentro do projeto. As pessoas já sabem quem faz qual atividade e quando fazer.

As características acima, o controle de riscos e a disciplina de gerência de projetos do RUP levam a um Maior controle sobre custos e prazos.

Conceitos Chave do RUP

As 4 Fases do RUP
São as etapas dos projeto de desenvolvimento com base no RUP. (1º eixo, Eixo Dinâmico do Gráfico das Baleias). Cada fase termina com um marco.

Concepção / Iniciação
Determinar o escopo do projeto para que seja possível estimar custos e riscos do projeto. É gerado um macro-planejamento. Estima-se o tamanho do projeto, os custos e os riscos. São definidos os objetivos que a organização pretende alcançar com o projeto. Todas as partes interessadas devem entender os objetivos a serem alcançados.

Elaboração
Assegura que os principais riscos foram diminuídos e uma arquitetura estável foi definida. Dentre os casos de uso, que foram definidos na fase anteior, aqueles mais arriscados, importantes e complexos são identificados e implementados para garantir que a arquitetura está adequada. Isso já reduz o risco do projeto. O marco é a aquitetura do projeto estabilizada.

Construção
Desenvolver o produto de forma iterativa e incremental para a Transição. 20% dos casos de uso foram detalhados e implementados até a fase de Elaboração. Aqui os outros casos de uso são implementados. Nessa fases as equipes trabalham muito em paralelo e com velocidade. O marco da fase é o build estabilizado do sistema ou a capacidade operacional inicial. O produto deve ser capaz de ser operado.

Transição
Disponibilizar o software para o usuário final. Assegurar que o sistema esteja disponível e funcionando corretamente. Inclui documentação do sistema, guias do usuário e etc. O marco é o lançamento do produto.

As fases não são idênticas em termos de esforço e tempo gasto. Abaixo estão alguns números mágicos da metodologia.

  Iniciação Elaboração Construção Transição
Esforço ~5 % 20 % 65 % 10%
Programação (Cronograma) 10 % 30 % 50 % 10%

É possível ver que a fase Construção é a que consome maior tempo (50%) e maior esforço (65%).

Uma passada pelas quatro fases é chamada de Ciclo de Desenvolvimento e gera uma primeira versão do seu software, o que seria a versão 1.0. Uma próxima versão, de evolução do software, seria a versão 2.0. Essa segunda parte é considerada um novo ciclo e é conhecida como Ciclo de Evolução.

Durante o Ciclo de Evolução a ênfase nas fases não é a mesma do Ciclo de Desenvolvimento. Na maioria dos casos, os riscos já são conhecidos e arquitetura já está estabilizada, então, a fase de elaboração, por exemplo, será menor.

Iterações
"Uma sequência distinta de atividades que resulta em um release do seu produto". Uma iteração é uma passada pelas 6 disciplinas de ENGENHARIA do seu projeto. As iterações podem ser consideradas como mini-projetos em cascata.

As 6 disciplinas de engenharia são: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste e Implantação.



A cada iteração as atividades de cada disciplina são executadas e no final é gerado um produto de trabalho (release), que é um incremento no sistema. Pode ser um release interno (para a equipe ou usuários específicos) ou um release externo (para os clientes). Para que o release seja liberado, é perciso estar estabilizado de alguma forma. Para isso é criada uma baseline. A baseline é o estado estável e aprovado que libera o release.

Cada fase possui várias iterações. O que muda de uma fase/iteração para outra é a enfase que é dada nas disciplinas. Durante a passagem por uma disciplina pode não haver necessidade de executar nenhuma atividade de uma disciplina específica. Isso acontence principalmente no início e no fim do projeto.

Disciplinas
Conjunto de atividades (fluxo de trabalho) relacionadas a uma área de interesse do projeto para geração de resultados. As disciplinas do RUP lembram as fases do modelo em cascata, porque são as atividades técnicas que são executadas durante o projeto. Detalham como executar as atividades, quem executa e quais produtos de trabalho são gerados após a execução das atividades.

Algumas disciplinas estão associadas a conjuntos específicos de modelos e os modelos são conjuntos de artefados. Cada disciplina possui seu próprio fluxo de trabalho, que é um diagrama de atividades da linguagem UML.

Disciplinas de Engenharia
Modelagem de Negócios
Requisitos
Análise e Projeto
Implementação
Testes
Implantação

Disciplinas de Suporte
Gerenciamento de Projetos
Gerenciamento de Configuração e Mudanças
Ambiente

M-RAITIGGA

Papéis
Definem o comportamento e as responsabilidades em um processo. Dentro de uma disciplina, os responsáveis por executar as atividades são os papéis. Exemplos de papéis são: programador, testador, gerente de projeto, arquiteto e etc.

No final das contas, os papéis acabam associados a um ser humano, mas a definição de um papel trata de um comportamento e de um conjunto de responsabilidades. Uma pessoa pode executar um, nenhum ou vários papéis.

Tarefas ou Atividades
Uma unidade de trabalho desempenhada por um papel. Algo que um papel faz e produz um resultado dentro do contexto de uma disciplina. São compostas por: finalidade, passos, entradas e saídas, papel responsável, além de guias e padrões para auxiliar a execução. 

Produtos de Trabalho
São o resultado de um processo de trabalho utilizados como entradas e/ou saídas na execução das atividades. São divididos em artefatos (termo genérico), entregáveis (os que são entregados aos clientes) e os resultados (outcomes), que são produtos intangíveis, representam o alcance de algum objetivo. No geral, produtos de trabalho são chamados de artefatos.

Podem ser: modelos, documentos, código fonte, executáveis, etc

Resumindo: Papéis executam Tarefas que geram Artefatos.
Exemplo: O Especificados de Requisitos (papel) executa Atividade chamada Detalhar Caso de Uso e gera um artefato, que é o próprio Caso de Uso.

Um ciclo de vida de desenvolvimento no RUP é a passagem pelas quatros fases: Iniciação, Elaboração, Construção e Transição. Cada fase possui seus objetivos próprios e são delimitadas por marcos. Quando uma fase é executada e seus objetivos são alcançados, o marco é alcançado. Cada fase pode ter N iterações, que são as passadas sequenciais pelas 6 disciplinas de engenharia do projeto. Dentro das disciplinas existem os papéis que executam as atividades e geram artefatos.