quinta-feira, 24 de maio de 2012

RUP para Concursos - Parte 3 - As 6 Melhores Práticas do RUP


Desenvolvimento Iterativo
É uma estratégia de resolução de problemas. Percorre-se várias vezes as disciplinas de engenharia durante o ciclo de vida do projeto. Cada iteração é uma passada pelas disciplinas e a cada uma delas a equipe aprende e ganha compreensão a respeito do projeto, dos requisitos e dos componentes. A arquitetura se torna mais robusta a cada incremento. É uma maneira mais flexível de desenvolvimento e impede que o risco seja acumulado para o final do projeto. O risco diminui com o tempo porque é percebido, avaliado e mitigado a cada iteração.

Lida com mudanças com mais facilidade. A cada incremento existe a chance de se verificar as mudanças nos requisitos e é possível se adaptar e replanejar o projeto. O replanejamento acontece a cada iteração.

Diminui os riscos porque são avaliados mais cedo. A cada iteração é possível integrar o código, verificar as interfaces e os usuário também poderão avaliar o que foi produzido para dizer se o caminho está correto.

Melhora a qualidade do software e a equipe aprende e melhora porque a cada iteração os usuários avaliam o que foi feito, passam o feedback e é possível corrigir os rumos do projeto. O conhecimento do negócio aumenta de forma mais precisa a cada interação com os usuários.

Aumenta o reuso porque é mais fácil pensar em reutilizar um componente que já está parcialmente ou totalmente implementado do que pensar em todos os componentes de forma antecipada. É quase impossível prever estes componentes apenas com os casos de uso especificados.

As iterações incorporam um conjunto quase sequencial das atividades. Só não é sequencial de fato porque algumas disciplinas podem não ser executadas em determinada fase.

Gerenciamento de Requisitos
Requisitos mal especificados, mal compreendidos e mal documentados geram problemas para TODO o projeto. Requisito é a necessidade e o propósito do seu cliente. É uma condição ou restrição com a qual o sistema deverá estar em conformidade. Não adianta implementar um requisito errado da melhor forma do mundo, porque isso não atende às necessidades do cliente. A forma como o requisito é entendido nem sempre é o que o cliente precisa e deseja.

Normalmente os requisitos se resumem a funcionais e não funcionais.

O RUP diz que o documento de requisitos deve ser feito de maneira clara. E o Gerenciamento de requisitos é uma abordagem sistemática para localizar, documentar, organizar e controlar os requisitos variáveis em um sistema. Além disso é preciso manter a integridade dos requisitos através da rastreabilidade.

Os requisitos possuem vários problemas: nem sempre são claros e podem vir de várias fontes diferentes. Cada fonte tem a sua visão e a sua prioridade. Duas fontes diferentes podem ter visões conflitantes. Além disso, existe uma interdependência entre requisitos diversos e os documentos devem tratar isso de forma consistente.

Cada requisito é diferente. A complexidade muda e a importância também. Alguns são simples e pouco importantes e outros podem trazer problemas para todo o projeto. É preciso identificar essa complexidade e tratá-los no momento certo do ciclo de vida do projeto.

Existem várias partes interessadas e pode haver conflito de interesses entre as essas partes. Além disso, o número de requisitos pode se tornar tão grande que fica impossível gerenciá-los.

Os requisitos são alterados a todo tempo.
Mudanças de requisitos identificadas tardiamente são as principais causas de insucesso nos projetos de desenvolvimento de software.

Como gerenciar essas dificuldades? Analisando o problema.
Entenda o "problema por trás do problema".
Estabeleça um vocabulário comum (UML e Glossário).
Proponha soluções em alto nível: nível de análise e não em nível de projeto.

Entenda a necessidade das partes interessadas e evite o desenvolvimento customizado
Todos querem algo. Determine qual é a melhor fonte dos requisitos, a fonte que realmente agrega valor. Utilize técnicas de elicitação de requisitos. Faça acordos, balancie prioridades, ou seja, negocie com as partes interessadas para saber o que é crítico, o que é importante, o que é desejável e dispensável. Alguns requisitos são fundamentais para entrada em produção. Outros não.

Defina o sistema.
Defina o que o sistema deve fazer, em termos gerais, utilizando linguagem natural e linguagem gráfica (UML).

Gerencie  o escopo do sistema
Tudo o que está no Modelo de Casos de Uso faz parte do escopo do sistema. O que está dentro? e fora? Estabeleça as prioridades para selecionar o que entra e o que sai.

Gerencie os requisitos variáveis
Garanta que os requisitos tenham uma estrutura que os tornem facilmente atualizáveis (utilize referências em seus documentos de casos de uso). Rastreie as mudanças em seus requisitos. Toda vez que uma mudança afetar um requisito ela deve ser analisada, o impacto e os riscos devem ser considerados e só poderá ser executada se aprovada após a análise. Mudanças sem análise não devem ser implementadas.

Os Casos de Uso guiam o desenvolvimento
O RUP recomenda a utilização de Casos de Uso como método para a organização dos requisitos funcionais. Assim você consegue organizar uma visão de como o usuário enxerga o sistema.

Os casos de uso definem um conjunto de cenários e cada cenário descreve o comportamento do sistema em uma sequência de ações. Esses cenários devem produzir um resultado de sucesso ou de erro de valor observável para um ator.

Atores são entidades externas que se relacionam com o seu sistema. Podem ser pessoas, outros sistemas e etc.

Quem utiliza os casos de uso? Os clientes utilizam para compreenção do comportamente do sistema e para aprovação do funcionamento antes da implementação. Os arquitetos analisam os casos de uso para definir a arquitetura do sistema logo na fase de elaboração. Os analistas, projetistas e programadores para entender o comportamento do sistema, refinar e implementar. Os casos de testes também são gerados a partir dos casos de uso. O gerente utiliza para acompanhar o progresso do projeto e por aí vai. Por isso se diz que o RUP é guiado por Casos de Uso

Arquitetura de Componentes
A arquitetura é a estrutura organizacional do software. Segundo o RUP é "a sua organização ou estrutura de componentes significativos que interagem através de interfaces". A arquitetura de um sistema reflete as grandes decisões a respeito da implementação. Diz em quantas camadas o sistema é feito, quais frameworks são utilizados, quais padrões de projeto foram implementados e coisas do tipo. E o RUP dá grande ênfase à arquitetura.

Segundo o RUP a arquitetura do software inclui: As decisões significativas sobre a organização de um sistema. A seleção dos elementos estruturadores e suas intefaces, a especificação dos elementos do sistema e como eles colaboram entre si.

A arquitetura não se preocupa apenas com estrutura e comportamento, mas também com funcionlidades, desempenho, segurança, reuso, manutenibilidade, decisões técnológicas e econômicas. Por isso os requisitos não funcionais, podem influenciar fortemente na decisão da arquitetura.

O que é um Componente?
É uma parte independente do seu sistema. Grupos de código coesos com interfaces e comportamentos bem definidos. Possui forte encapsulamento de conteúdo. Pode ser substituído por outro. Os componentes se comunicam através de suas interfaces visíveis e um nunca conhece o comportamenteo interno do outro.

Vantagens
Permite reuso em grande escala. Por serem independentes e coesos, podem ser usados diversas vezes e em sistemas diferentes. O caso do Hibernate é clássico: um componente para mapeamento OO-Relacional que é utilizado em praticamente todos os sistemas de software web em java atualmente.

Bom gerenciamento da complexidade do projeto e mantém a integridade do sistema. A separação em componentes permite que os problemas sejam tratados de forma separada, já que eles são isolados. Isso identifica, isola, projeta, desenvolve e testa as partes bem formadas do sistema em separado.

É possível utilizar componentes de prateleiras disponíveis no mercado.

Visões Arquiteturais
No RUP a arquitetura é representada por uma série de visões de arquitetura diferentes. São perpectivas diferentes da arquitetura. Conhecido como modelo de visão 4 + 1 porque são 5 visões disponíveis. Seria como a construção de uma casa, ondem existem vários projetos diferentes. Um arquitetônico, um de instalações elétricas, um de hiráulica e etc.

Visão Lógica ou Visão de Projeto descreve as principais classes no projeto do sistema. Define as classes de projeto mais importantes, a organização em pacotes e subsistemas, e a organização destes pacotes em camadas. É uma das principais visões e é obrigatória. Os diagramas de classes, sequencia e pacotes aparecem muito nesta visão.

Visão de Implementação contém a organização em termos de módulos, pacotes e camadas. É uma visão opcional que entra nos detalhes da Visão Lógica. Descreve o código da sua aplicação. Tudo o que foi gerado a partir do projeto. Visão mais detalhada do projeto do sistema.

Visão de Processos descreve o ascpecto simultâneo do sistema. As tarefas (processos e threads) que são concorrentes devem ser definidas nessa visão. Só deve ser usado caso o sistema possua alto grau de paralelismo. Por isso é opcional.

Visão de Implantação descreve como serão as configurações das instalações físicas do sistema. Contém a descrição dos vários nós físicos do sistema e a aloção de taréfas atribuídas a eles. É uma visão opcional, que pode ser usada quando o sistema for distriuído.

Visão de Caso de Uso é uma visão externa, o ponto de vista do cliente a respeito da perspectiva funcional. Contém os casos de uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes, ou riscos. É uma visão obrigatória do documento de arquitetura.

Modelagem Visual (UML)
Fazer uso de notação gráfica para exibir o projeto do software. A linguagem gráfica permite que o nível de abstração seja aumentando, escondendo detalhes e faciliando a comunicação com os clientes. Um usuário não consegue entender o código e a linguagem escrita é muito ambígua para isso. Essa notação visual também adiciona precisão à captura dos requisitos. Como a ambiguidade é reduzida, acontece uma melhora na comunicação da equipe.

O RUP determina o uso da UML (Unified Modeling Language)
UML é uma notação padrão para modelagem de software. Oferece diferentes perspectivas de um problema: estática, dinânima, colaborativa e etc. Ajuda a manter o projeto (os diagramas) e o código consistentes.

Os artefatos UML possuem suporte das ferramentas automatizadas recomendadas pelo RUP para ajuda na produtividade da equipe.

Verificação da Qualidade
Qualidade não é algo pontual, não deve ser verificada apenas no fim ou em pontos específicos, mas em todo o seu projeto de forma contínua. "A característica de ter demonstrado a realização de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados".

Você deve estabelecer os critérios de qualidade anteriormente, já com critérios de medida. Para ter qualidade, o produto precisa, no mínimo, atender esses critérios que foram estabelecidos.

O RUP prevê duas atividades para assegurar a qualidade do produto.

Controle de Qualidade
Tem foco no produto e encontra defeitos específicos. Faz o teste no que foi gerado, no final. Verifica se existe um defeito naquilo que foi produzido.

Garantia da Qualidade
O foco fica nos processos e na execução deles. Garante que você está fazendo as coisas de maneira certa. Pode ser alcançado com utilização de boas práticas de mercado e etc.

Qualidade é multidimensional e possui vários critérios ou dimensões.
Andamento: o progresso do projeto.
Variação:  diferença entre planejado e executado.
Confiabilidade: o quanto seu produto é confiável?
Funcionalidade: os casos de uso foram implementados corretamente?

Desempenho: o desempenho está adequado às necessidades.

Muitos outros critérios podem ser utilizados para medir a qualidade, mas o importante é que esses critérios sejam definidos antes da execução do projeto, para que não sejam adaptados para dar uma falsa ideia de qualidade no final de tudo.

A verificação da qualidade é importante porque o custo de uma correção sobe exponencialmente com o passar do tempo. Os defeitos corrigidos após implantação custam muito mais caro do que a correção durante o desenvolvimento. A verificação da qualidade diminui os custos e os riscos.

Gerenciamento de Mudanças
Sempre que existe muito paralelismo no projeto, é preciso controlar o ambiente. Quando existem vários desenvolvedores e equipes, diferentes locais de desenvolvimento, muitas iterações, releases, produtos e plataformas heterogêneas, se não existir um controle disciplindo do processo de desenvolvimento, o projeto tende ao caos rapidamente.

Item de Configuração
Uma entidade que satisfaz algum propósito para o usuário final e que pode ser unicamente identificado. Podem ser código-fonte, especificações, modelos, artefatos e etc.

Primeiro é preciso identificar quais são esses itens que necessitam estar sob a Gestão de Configuração.

Gerenciar Mudanças é utilizar uma abordagem sistemática para avaliar, decidir sobre as mudanças e coordená-las. É o processo de coordenar, avaliar e decidir sobre a realização de mudanças propostas naqueles itens que estão sendo gerenciados.

Apenas as mudanças aprovadas são implementadas nos itens de configuração, nos dados e documentos relacionados. É preciso avaliar o impacto, pertinência e o custo-benefício antes de aprovar.

No RUP existem as atividades de :
Coordenação de atividades e artefatos: procedimento repetíveis para gerenciar as mudanças nos artefatos.

Coordenação de iterações e releases: controle sobre os releases ao final das iterações. (baseline)

Controle de mudanças no software: mantém uma estrutura bem definida para grenciar mudanças no software.