RUP Pesquisa

Prévia do material em texto

Luiz Eduardo Ferreira - 1400797
Matheus Maxiliano do Prado – 140055x
Lucas Eduardo Alves – 1400843
Disciplina: Gestão de Qualidade de Software
Turma: 3º módulo – Web 
Professora: Milene Rigolin 
O Rational Unified Process - RUP.
Introdução:
Modelo moderno derivado da UML, modelo hibrido de processos. Mistura os modelos, aprova iteração e ilustra boas praticas de especificação e projeto.
Descrição do método:
É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.
Perspectivas: 
Dinâmica (mostra as fases do modelo).
Estática (atividades realizadas nos processos, desenvolvimento com nove workflows).
Pratica (boas praticas a serem usadas no processo).
OBS: Cada workflow é na verdade uma sequência de tarefas encadeadas e relacionadas a um aspecto importante do projeto, tal como análise do negócio, testes, etc.
Alguns workflows:
Fases:
Fases relacionadas a negócios, não assuntos técnicos.
Concepção ou iniciação: business case do sistema. Avaliar fatores externos e suas interações com o sistema. Usa essas informações para avaliar a contribuição do sistema com o negocio. Se a contribuição for de pouca importância cancela o projeto.
Elaboração: entender o problema, estabelecer um framework, identificar riscos. Ao concluir você terá um modelo de requisitos, uma descrição de arquitetura e um plano de desenvolvimento.
Construção: Ao concluir você terá sistema de software funcional e a documentação.
Transição: Ao concluir você terá um sistema documentado, funcional e em ambiente operacional.
Fases relacionadas com os workflows.
Práticas fundamentais:
Desenvolver o sistema iterativamente (incrementar e priorizar).
Gerenciar requisitos (manter acompanhado as mudanças dos requisitos).
Usar arquiteturas baseadas em componentes.
Modelar o software visualmente (UML para representar as visões estáticas e dinâmicas).
Verificar a qualidade do software (software atenda padrões).
Controlar as mudanças do software (usar sistema gerenciamento para controle).
OBS: RUP não é melhor para todos, porem apresenta uma nova geração de processos genéricos.
Definição de um conjunto de atividades: 
Normalmente os papéis são desempenhados por uma pessoa ou um grupo de pessoas que trabalham juntas em equipe. Um membro da equipe do projeto geralmente desempenha muitos papéis distintos.
Os papéis não são pessoas; pelo contrário, eles descrevem como as pessoas se comportam no negócio e quais são as responsabilidades que elas têm.
Apesar de a maioria dos papéis serem desempenhados por pessoas que fazem parte da organização, as pessoas de fora da organização têm um papel importante: por exemplo, o papel doenvolvido do projeto ou produto que está sendo desenvolvido. 
Papel, suas atividades e artefatos:
Os papéis têm um conjunto de atividades coerentes por eles executadas. Essas atividades são estreitamente relacionadas e combinadas em termos de funcionalidade, e é recomendável que elas sejam executadas pela mesma pessoa.
As atividades estão fortemente relacionadas aos artefatos. 
Os artefatos fornecem a entrada e a saída para as atividades e o mecanismo pelo qual as informações são transmitidas entre as atividades.
Tipos de papéis:
Os papéis do Analista organizam os papéis envolvidos principalmente na identificação e na investigação de requisitos.
Os papéis do Desenvolvedor organizam os papéis envolvidos principalmente no design e desenvolvimento de software
Os Papéis do Testador organizam os papéis que lidam com habilidades específicas exclusivas para teste. Observe que existem papéis adicionais envolvidos na disciplina Teste que juntos ampliam as habilidades básicas de outros papéis. Esses papéis adicionais podem ser encontrados nos demais papéis organizados pelas habilidades básicas que estendem (por exemplo, Gerente, Designer, Analista).
Os papéis do Gerente organizam os papéis envolvidos principalmente no gerenciamento e na configuração do processo de engenharia de software.
Todos os papéis identificados no Rational Unified Process (RUP) podem, de acordo com os privilégios de acesso, fazer o 'check-in' e 'check-out' de qualquer artefato relacionado ao produto para fins de manutenção no sistema de controle de configuração. Todos os papéis também podem enviar solicitações de mudança e fazer atualizações nas solicitações de mudança das quais são os proprietários.
Tipos de artefatos:
Obs: Os mais comuns.
	Artefato 
	Descrição 
	Formulário de Abertura de Projetos 
	Formulário de formalização de início de um projeto 
	Plano do Projeto 
	Documento com o planejamento do projeto, incluindo o processo de produção de software adotado, com suas fases, padrões e técnicas. Compreende também o planejamento de atividades, recursos alocados e teste. 
	Planilha de Gerência de Riscos 
	Compreende o plano de gerência dos riscos potenciais do projeto, incluindo análise de riscos, possíveis dependências e problemas e as ações de contingências a serem realizadas. 
	Relatório de Conclusão de Projetos 
	Relatório contendo os dados de conclusão de um projeto 
Outros tipos de artefatos:
Para o Plano de Desenvolvimento de Software, a lista de artefatos mencionados inclui para sua respectivas fases: 
Planos de Iteração - Todas as fases
Plano de Gerenciamento de Requisitos - Concepção
Plano de Medidas - Elaboração
Plano de Gerenciamento de Riscos - Concepção
Caso de Desenvolvimento - Construção
Orientações de Modelagem de Negócios - Construção
Orientações de Interfaces com o Usuário - Elaboração
Diretrizes de Modelagem de Caso de Uso - Elaboração
Diretrizes de Design – Concepção
Diretrizes de Programação - Concepção
Diretrizes de Teste - Concepção
Guia de Estilo Manual - Elaboração
Plano de Infra-estrutura - Elaboração
Plano de Aceitação do Produto - Elaboração
Plano de Gerenciamento de Configuração - Elaboração
Plano de Avaliação - Elaboração
Plano de Documentação - Elaboração
Plano de Garantia de Qualidade - Elaboração
Plano de Resolução de Problemas – Elaboração.
Plano de Gerenciamento de Subfornecedores - Elaboração
Plano de Aprimoramento do Processo - Elaboração
Tipos de ferramentas:
Obrigatórias:
	Ferramentas 
	Descrição 
	Planilha de Estimativa e Acompanhamento de Custos 
	Planilha para cálculo de estimativas de tamanho e esforço para desenvolvimento de software baseado na técnica de pontos por caso de uso. 
	Cronograma 
	Modelo de cronograma para definição de prazos e tamanho da equipe para projetos de desenvolvimento de software 
	Lista de e-mail do projeto 
	Lista de e-mail contendo todos os integrantes do projeto. 
	Site do Projeto 
	Site com todas as informações importantes do projeto: cronogramas, reuniões, equipe, artefatos gerados, referências importantes, etc. Pode ser só interno à equipe de desenvolvimento ou pode ser disponibilizado para o cliente também. 
Opcionais:
	Ferramentas 
	Descrição 
	dotProject 
	Ferramenta free para gerenciamento de projetos. O uso desse tipo de ferramenta substitui a criação de um site para o projeto. 
Documentos relacionados:
Para facilitar a realização das atividades acima listadas, como também a confecção dos artefatos obrigatórios, alguns documentos que servem de referência estão abaixo listados: 
	Documentos Relacionados 
	Descrição 
	Treinamento do Timesheet 
	Apresenta o treinamento na nova padronização das reportagens no Timesheet 
	Resumo sobre a técnica de estimativa por pontos de caso de uso 
	Project Estimation with UCP: Artigo pequeno em inglês sobre o uso da técnica de pontos por caso de uso. 
	Resource Estimation For Objectory Projects 
	Artigo em inglês sobre o uso da técnica de pontos por casode uso. 
	Manual do dotProject 
	Documento explicando o uso da ferramenta dotProject. 
Testes RUP:
Uma diferença interessante entre o Teste e as outras disciplinas do RUP é que a principal finalidade do Teste é localizar e expor os pontos fracos do software. O interessante é que, para obter o máximo benefício, ele precisa de uma filosofia geral diferente da usada nas disciplinas Requisitos, Análise e Design, e Implementação. A diferença sutil é que enquanto as outras disciplinas enfatizam a abrangência, o Teste enfatiza a deficiência. Um bom esforço de teste é direcionado por perguntas do tipo "Como esse software pode ser dividido?" e "Em que situações este software pode deixar de funcionar da maneira prevista?". O teste desafia as suposições, os riscos e as incertezas inerentes ao trabalho de outras disciplinas, tratando essas questões por meio de uma demonstração concreta e uma avaliação imparcial. O desafio é evitar dois extremos potenciais: uma abordagem que não avalie o software de forma adequada e efetiva, expondo seus problemas e pontos fracos, e uma abordagem que seja inapropriadamente negativa ou destrutiva. Com a adoção de uma abordagem tão negativa, talvez você nunca considere aceitável a qualidade do software, e provavelmente alienará o esforço de Teste de outras disciplinas.
Qualidade de software:
Qualidade é o sucesso para o negócio de software, como em qualquer outro;
A maneira mais barata de aumentar a produtividade de software é aumentando sua qualidade; 
A qualidade ao suporte do produto é tão importante quanto a qualidade do próprio software, o ambiente de suporte deve ter engenharia tanto quanto o ambiente de desenvolvimento; 
Para alcançar a qualidade de software, as pessoas e a cultura são tão importantes quanto à tecnologia;
O único caminho seguro para aumentar a qualidade do software, é melhorar os processos;
Aumento de processos é normalmente desnecessário a menos que o gerente demonstre compromisso e liderança; 
Qualidade e melhoramento dos processos não é nada fácil de ser implementado: sempre é possível realizar algo um pouco melhor, um pouco mais barato e um pouco mais rápido; 
Um sistema de qualidade compatível com ISO9000 é um bom parâmetro para a maioria das organizações, porém não para todas;
Um sistema de qualidade para uma organização deve ser medido de acordo com suas necessidades e circunstâncias ou não será eficiente; 
Um sistema de qualidade de software eficiente utiliza de boas práticas da engenharia de software baseado nos seguintes princípios: prevenir defeitos ao invés de consertá-los; ter certeza dos defeitos que forem encontrados, serem corrigidos rapidamente; estabelecer e eliminar as causas, bem como os sintomas dos defeitos e auditar o trabalho de acordo com padrões e procedimentos previamente estabelecidos.
23/02/2015