Aula03 - Metodologias tradicionais

Prévia do material em texto

1
Qualidade de Software
Ementa
1
METODOLOGIAS DE 
PROCESSOS TRADICIONAIS
Prof.ª Poliana Corrêa - poliana.correa@sga.pucminas.br
Pontifícia Universidade Católica de Minas Gerais (PUC Minas)
Qualidade de Software
Ementa
2
METODOLOGIAS DE PROCESSOS
TRADICIONAIS
ÁGEIS
Qualidade de Software
Ementa
3
METODOLOGIAS TRADICIONAIS
� Também chamadas de pesadas ou orientadas a documentação
� Apresenta natureza iterativa e incremental
� Abordagens mais modernas
� Porém, o foco para controlar o processo de desenvolvimento de
software ainda é o planejamento muito bem documentado
� Metodologias tradicionais mais conhecidas
� UP (Unified Process, Processo unificado)
� RUP (Rational Unified Process)
Qualidade de Software
Ementa
4
BREVE HISTÓRICO
� Década de 80 e início da década de 90: grande crescimento das
linguagens de programação orientadas a objetos
� No início da década de 90, James Rumbaug, Grady Booch e Ivar
Jacobson começaram a trabalhar em um “método unificado”
� O resultado foi a UML – uma linhagem unificada de modelagem que contém
uma notação robusta para a modelagem e desenvolvimento de softwares
orientados a objetos
� Ao mesmo tempo, a Rational Corporation e outros vendedores
desenvolveram ferramentas automatizadas para apoiar os
métodos da UML
Qualidade de Software
Ementa
5
BREVE HISTÓRICO
� Embora a UML forneça tecnologia necessária para apoiar práticas
orientadas a objetos, ela não fornece um arcabouço de processo
para guiar as equipes de projeto na aplicação da tecnologia
� Nos cinco anos seguintes, Jacobson, Rumbaugh e Booch
desenvolveram o Processo Unificado
� Trata-se de um arcabouço de processo de desenvolvimento de
software para a engenharia orientada a objetos usando a UML
Qualidade de Software
Ementa
6
PROCESSO UNIFICADO - UP
� Primeiro modelo de processo inteiramente adaptado ao uso com a
UML, concebido com base nas práticas de maior retorno de
investimento no mercado
� Tentativa de apoiar-se nos melhores recursos e características dos
modelos convencionais de processo de software, mas caracterizá-
los de um modo iterativo e incremental
� Reconhece a importância da comunicação com o cliente e dos métodos
para descrever a visão do cliente (caso de uso)
� Enfatiza o papel da arquitetura de software e ajuda o arquiteto a se
concentrar nas metas corretas, tais como compreensibilidade, abertura e
modificações futuras e reuso
2
Qualidade de Software
Ementa
7
PROCESSO UNIFICADO - UP
� As atividades do UP são bem definidas
� Descrição clara e precisa
� Apresenta responsáveis para cada uma
� Artefatos de entrada e saída são determinados
� As dependências entre as atividades são estabelecidas
� Modelo de ciclo de vida bem definido
� Descrição sistemática de como podem ser executadas com ferramentas
disponibilizadas (procedimentos)
� Preconiza o uso da linguagem UML
� Incluem workflows (fluxos de trabalho)
� Grafos que descrevem as dependências entre as atividades
� Associados às disciplinas do Processo Unificado (podem variar de
implementação para implementação)
Qualidade de Software
Ementa
8
PRINCÍPIOS DO UP
� Iterativo e incremental
� O desenvolvimento é organizado em “mini-projetos”
� Cada iteração é um “mini-projeto” tem atividades de análise, projeto,
implementação e testes e resulta em um incremento na versão atual do
sistema
� Há refinamentos e incrementos sucessos até formar o software completo
� Em cada iteração, o engenheiro de software seleciona os casos de uso mais
relevantes para serem integrados à arquitetura
� O resultado de cada iteração é um sistema executável, porém incompleto
• Pode ser necessário executar diversas iterações até o software ser concluído
Qualidade de Software
Ementa
9
PRINCÍPIOS DO UP
� Iterativo e incremental
FONTE: http://www.devmedia.com.br/introducao-ao-processo-unificado/3931
Qualidade de Software
Ementa
10
PRINCÍPIOS DO UP
� Orientado a casos de uso
� Entrada para a maioria das atividades do processo
� Caso de uso: descreve uma sequência de ações que são realizadas por um
ator à medida que o ator interage com o software
� Ajudam a identificar o escopo do projeto e fornece a base para o
planejamento do projeto
� Cada iteração tem um conjunto de casos de uso ou de cenários de
requisitos durante todo o tempo de implementação e teste
Qualidade de Software
Ementa
11
PRINCÍPIOS S DO UP
� Orientado a casos de uso
FONTE: http://www.dimap.ufrn.br/~jair/ES/exemplos/casosdeuso.html
Qualidade de Software
Ementa
12
PRINCÍPIOS DO UP
� Centrado na arquitetura do sistema
� Visão de como o sistema pode ser construído
� A arquitetura ajuda a dar forma ao sistema da mesma forma que os casos
de uso sustentam as funcionalidades
� Pelo menos, entre 5 e 10% dos casos de uso devem ser implementados na
arquitetura inicial
� Envolve questões de desempenho, escalabilidade, reuso, restrições
� Deve ser robusta, flexível, expansível e de custo viável
3
Qualidade de Software
Ementa
13
PRINCÍPIOS DO UP
� Exemplo: arquitetura em camadas
Fonte: http://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula2.pdf
Qualidade de Software
Ementa
14
PRINCÍPIOS DO UP
� Focado em riscos
� Priorização dos casos de uso mais críticos nos primeiros ciclos iterativos
� Os riscos devem ser tratados o quanto antes para que esse risco seja
resolvido enquanto o custo de tratá-lo ainda é baixo e o tempo disponível
para lidar com “surpresas” é relativamente grande
� Garante o maior aprendizado sobre o sistema e decisões arquiteturais mais
importantes
Qualidade de Software
Ementa
15
FASES DO PROCESSO UNIFICADO
Fase Descrição
Concepção
Abrange atividades de comunicação com o cliente e de
planejamento, trata-se de uma visão em abrangência do sistema. Um
modelo conceitual preliminar é construído.
Elaboração
Inclui a comunicação com o cliente e atividades de modelagem do
modelo genérico de processo. O objetivo é o detalhamento e análise
expandida dos casos de uso.
Construção
Usando o modelo arquitetural como entrada visa desenvolver os
componentes de software que vão os casos de uso operacionais.
Consiste na geração de código e testes do sistema.
Transição
O software é entregue aos usuários para testes finais e relatórios de
feedback sobre defeitos e modificações. Abrange a implantação do
sistema no ambiente final.
� Fases do UP
Qualidade de Software
Ementa
16
MARCOS DO PROCESSO UNIFICADO
Fase Marco/Milestone
Concepção LCO (Lifecycle Objective Milestone) ou marco do ciclo de vida
Elaboração LCA (Lifecycle Architecture Milestone) ou marco da arquiteura
Construção
IOC (Initial Operational Capability Milestone) ou marco da capacidade 
operacional inicial
Transição PR (Product Release Milestone), ou marco de entrega de produto
� Ao final de cada fase um macro-objetivo (milestone) é alcançado
Qualidade de Software
Ementa
17
FLUXOS DE TRABALHO DO 
PROCESSO UNIFICADO
Fase Descrição
Requisitos
Obtenção de um conjunto de requisitos do produto, acordado entre 
cliente e fornecedor.
Análise Detalhamento, estruturação e validação dos requisitos.
Desenho
Formulação de um modelo estruturado do produto que sirva de 
base para a implementação.
Implementação Confecção de desenhos em termos de componentes do software.
Testes Verificação dos resultados implementados.
� Presentes em todas as fases do UP, cada fluxo de trabalho inclui
um conjunto de atividades técnicas executadas por um ou vários
membros da equipe
Qualidade de Software
Ementa
18
PROCESSO UNIFICADO
� Também conhecido como “Gráfico das Baleias”
4
Qualidade de Software
Ementa
19
PROCESSO UNIFICADO
� As iterações do início do processo normalmente se concentramnos fluxos de requisitos e análise
� Estas iterações podem chegar ao fluxo de projeto, mas raramente
ao fluxo de implementação e teste
� As iterações do final do processo de desenvolvimento
normalmente executam os fluxos de implementação e teste
� O desenvolvimento é baseado na integração de componentes de
software
Qualidade de Software
Ementa
20
PROCESSO UNIFICADO
� Cada iteração consiste em
� Planejar a iteração
� Executar os fluxos de trabalho
� Fazer análise ao término da iteração
� Descartar os riscos que o incremento tratou
� Revisar o plano do projeto
� Ir para a próxima iteração, se existir
Qualidade de Software
Ementa
21
RUP (RATIONAL UNIFIED PROCESS)
� Processo proprietário criado pela Rational Software Corporation
� Mais antiga e detalhada implementação do UP
� Também foca na orientação a objetos e documentos com notação UML
� Após a venda da empresa para IBM (2003) vem ganhando o nome IRUP
� Mais completo do que o UP, inclui aspectos gerenciais do projeto
(atribuição de tarefas e responsabilidades, por exemplo)
� Objetivo: Garantir a produção de software de alta qualidade dentro de
cronogramas e orçamentos previstos
� É um produto de software, modular e automatizado composto por
várias ferramentas vendidas pela IBM como “Rational Suites”
� Inclui uma base de dados com hiperlinks com vários artefatos e templates
necessários para usar bem o modelo
Qualidade de Software
Ementa
22
RUP (RATIONAL UNIFIED PROCESS)
� Antes de pertencer à IBM, a Rational adquiriu várias empresas
(Verdix, Objectory, Requisite, SQA, Performance Awareness e
Pure-Atria) o que resultou no estabelecimento de algumas práticas
� Principais práticas do novo modelo de processo (a partir de 2003)
� Desenvolver iterativamente tendo o risco como principal fator de
determinação de iterações
� Gerenciar requisitos
� Empregar uma arquitetura baseada em componentes
� Modelar software de forma visual com diagramas
� Verificar a qualidade de forma contínua
� Controlar as mudanças
Qualidade de Software
Ementa
23
RUP (RATIONAL UNIFIED PROCESS)
� Comparativo RUP x UP
Características UP RUP
Tipo de 
produto 
Acesso público Produto comercial
Material Um livro
3200 arquivos em 
mídia digital (RUP 2001) 
Fases 4 4
Disciplinas (ou fluxos 
de trabalho)
5 9
Qualidade de Software
Ementa
24
RUP (RATIONAL UNIFIED PROCESS)
Embora os nomes das fases lembrem os nomes das fases do Modelo Cascata, elas não são 
executadas de forma sequencial, visto que o RUP é um processo iterativo
5
Qualidade de Software
Ementa
25
RUP (RATIONAL UNIFIED PROCESS)
� Princípios
� Desenvolvimento iterativo
� Gerência de requisitos
� Componentes arquiteturais
� Modelos baseados em UML
� Verificação contínua da qualidade
� Gerência de mudanças
� Atacar os riscos principais primeiro
� Acomodar mudanças no início do projeto
� Fornecer um software executável o quanto antes
� Construção em componentes
� Trabalho em equipe
Qualidade de Software
Ementa
26
RUP (RATIONAL UNIFIED PROCESS)
� Fases: igual ao UP
� Disciplinas englobam diferentes atividades re papéis relacionados
por áreas de especialidade
� Disciplinas de Projeto
� Modelagem de negócio
� Requisitos
� Análise e design
� Implementação
� Teste
� Implantação
� Disciplinas de Suporte
� Gerenciamento de mudança e
configuração
� Gerenciamento de projeto
� Ambiente
Qualidade de Software
Ementa
27
RUP (RATIONAL UNIFIED PROCESS)
� Baseado em um conjunto de elementos básicos
� QUEM: Papel
• Um papel (ou perfil) define o comportamento e as responsabilidades de um determinado 
indivíduo ou grupo de indivíduos trabalhando como uma equipe
� O QUE: Produto de trabalho
• Define algo produzido por alguma atividade (diagramas, relatórios, código funcionando,
ou seja, os artefatos)
� COMO: Atividade
• Descreve uma unidade de trabalho atribuída a um papel que produz determinado
conjunto de artefatos
� QUANDO: Fluxo de trabalho
• Um fluxo de trabalho é uma sequência de atividades que são executadas para a produção
de um resultado valioso para o projeto
Qualidade de Software
Ementa
28
RUP (RATIONAL UNIFIED PROCESS)
� Outros elementos
� Disciplinas
• Uma disciplina é uma coleção de atividades relacionadas que fazem parte de um contexto 
comum em um projeto
� Procedimentos (guidelines)
• Regras, recomendações e heurísticas sobre como executar a atividade
� Templates
• Modelos ou protótipos de artefatos e podem ser usados para criar os respectivos
artefatos
� Mentores de ferramenta
• Descrição detalhada de como executar uma atividade em uma ferramenta específica
Qualidade de Software
Ementa
29
BIBLIOGRAFIA
� KOSCIANSKI, André. Qualidade de software. 2ª edição. Novatec. 2007.
� WAZLAWICK, Raul Sidnei. Engenharia de software: conceitos e práticas. Rio de
Janeiro, RJ: Elsevier, Campus, c2013. xxii, 343 p.
� PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional.
Porto Alegre: AMGH, 2011. XXVIII, 780 p.
� SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011. xiii, 529 p.
Qualidade de Software
Ementa
30
DÚVIDAS