03 metodologias tracidionais

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
RELEMBRANDO
� Modelos de ciclo de vida de software
� Determina marcos temporais no desenvolvimento do software
Qualidade de Software
Ementa
3
RELEMBRANDO
� Processo = receita seguida por um projeto
� Projeto (abstrato) -> Processo (receita) -> Produto
Qualidade de Software
Ementa
4
RELEMBRANDO
� Processo de software é um conjunto de atividades que levam à
produção de um produto de software
� Processos reais de software são intercalados com sequências de
atividades técnicas, de colaboração e de gerência
� Objetivo: especificar, projetar, implementar e testar
Faz uso de uma variedade de diferentes
ferramentas de software (para apoiar desde uma
simples edição de documentos até o
gerenciamento de um projeto de grande porte)
Qualidade de Software
Ementa
5
PERSONALIZAÇÃO DE PROCESSOS
� Os modelos de processo definem aspectos principais
� Ponto de partida ☺
� A maioria das configurações de processo também podem ser
personalizados de acordo com a organização, objetivos,
características da equipe, critérios exigidos pelos clientes, etc.
Qualidade de Software
Ementa
6
MODELO DE PROCESSO PESSOAL
� Todo desenvolvedor usa algum processo para construir softwares
� O processo pode ser aleatório, pode
modificar-se diariamente, pode não ser
eficiente ou efetivo, mas existe um processo
� O melhor processo de software é aquele que
se aproxima do pessoal que fará o serviço
� “Uma pessoa que é bem-sucedida
simplesmente criou o hábito de fazer coisas
que as pessoas malsucedidas não vão fazer”
(Dexter Yager)
2
Qualidade de Software
Ementa
7
MODELO DE PROCESSO PESSOAL
� PSP (Processo Pessoal de Software, do inglês Personal Software
Process), proposto por Watts Humphrey
� Enfatiza a medição pessoal em termos do produto de trabalho que é
produzido e da qualidade resultante do mesmo
� Torna o profissional responsável pelo planejamento do projeto (por
exemplo, fazer orçamentos e cronogramas) e controlar a qualidade de todos
os produtos de trabalho de software desenvolvidos
� Ressalta a necessidade de cada engenheiro de software identificar logo os
erros e entender os tipos de erros que ele tende a fazer
� Avaliação de rigorosa de tudo que é feito
Qualidade de Software
Ementa
8
MODELO DE PROCESSO PESSOAL
� Atividades do PSP
� Planejamento: desenvolve estimativas de tamanho, recursos e de defeitos,
só então identifica as tarefas e cria-se um cronograma
� Projeto de alto nível: projeto de componentes e protótipos são construídos
(se houver incerteza)
� Revisão do projeto de alto nível: métodos de verificação formal são
aplicados para descoberta de erros
� Desenvolvimento: refinamento do projeto em nível de componente, o
código gerado é revisado, compilado e testado
� Pós-conclusão: efetividade do processo é determinada com base nas
medidas e métricas coletadas
Estimula o aperfeiçoamento da efetividade pessoal ☺☺☺☺
Qualidade de Software
Ementa
9
MODELO DE PROCESSO PESSOAL
� PSP na indústria de software
� Abordagem disciplinada, baseada na métrica, quando empregado
adequadamente aumenta de forma significativa o aperfeiçoamento
resultante na produtividade e qualidade do software
� Porém, pode levar a um choque de culturas em muitos profissionais
� É desafiador e exige um bom nível de comprometimento das pessoas
� Treinamento é demorado e os custos são altos, nível de medição difícil
� PSP não tem sido amplamente adotado pela indústria �
Qualidade de Software
Ementa
10
MODELO DE PROCESSO EM EQUIPE
� TSP (Processo de Equipe de Software, do inglês Team Software
Process) também proposto por Watts Humphrey
� Projetos de software a nível industrial são desenvolvidos por uma
equipe de profissionais
� Objetivo: equipe “autodirigida” que se organize para produzir softwares de
alta qualidade
“Encontrar bons jogadores é fácil.
Conseguir que eles joguem como
uma equipe é outra história”
(Casey Stengel)
Qualidade de Software
Ementa
11
MODELO DE PROCESSO EM EQUIPE
� Uma equipe “autodirigida” tem um entendimento consistente de
suas metas, define papéis e responsabilidades para cada membro,
define normas, avalia continuamente além de monitorar, gerenciar
e relatar o estado do projeto
� Atividades: lançamento, projeto de alto nível, implementação,
integração e teste, e pós-conclusão
� Essas atividades permitem que a equipe planeje, projete e
construa softwares de modo disciplinado, e ao menos tempo,
meça quantitativamente o processo e o produto, preparando o
para aperfeiçoamento do processo (no pós-conclusão)
Qualidade de Software
Ementa
12
MODELO DE PROCESSO EM EQUIPE
� TSP usa uma grande variedade de documentos, formulários e
normas para guiar os membros da equipe no trabalho deles
� Documentos contém uma sequência de tarefas recomendáveis
� Reconhece que as melhores equipes são autodirigidas
� É uma abordagem rigorosa que fornece benefícios em
produtividade e qualidade
� Porém, a equipe deve estabelecer um total comprometimento
com o processo e deve passar por treinamento para que a
abordagem seja propriamente aplicada
3
Qualidade de Software
Ementa
13
METODOLOGIAS DE PROCESSOS
“Já faz alguns anos que o 
desenvolvimento de software deixou de 
ser sinônimo apenas de código. Hoje em 
dia, sabe-se que é necessária a utilização 
de uma metodologia de trabalho”
Qualidade de Software
Ementa
14
METODOLOGIAS DE PROCESSOS
“Os modelos de processos discutidos devem ser adaptados para o uso de uma equipe 
de projeto de software. Para conseguir isso, foram desenvolvidas ferramentas de 
tecnologia de processo a fim de ajudar as organizações a analisar seu processo atual, 
organizar tarefas de trabalho, controlar e monitorar o progresso e gerenciar a 
qualidade técnica”
Qualidade de Software
Ementa
15
METODOLOGIAS DE PROCESSOS
� Todos os processos devem incluir quatro atividades fundamentais
Especificação 
de software
Estudo de 
viabilidade
Elicitação e 
análise de 
requisitos
Especificação de 
requisitos
Validação de 
requisitos
Projeto e 
implementação 
de software
Projeto de 
arquitetura
Projeto de 
interface
Projeto de 
componente
Projeto de banco 
de dados
Validação de 
software
Testes de 
desenvolvimento
Testes de 
sistema
Testes de 
aceitação
Evolução do 
software
Processo 
contínuo de 
manutenção
Qualidade de Software
Ementa
16
METODOLOGIAS DE PROCESSOS
� Metodologias de processos (ou modelos de processos ou
paradigmas de processos) são modelos genéricos de processos
� Não são descrições definitivas dos processos de software
� São abstrações que podem ser usadas para explicar diferentes abordagens
de desenvolvimento de software
� Cada modelo define um fluxo de trabalho e dita a ordem em que as
atividades devem ser executadas
� Podem ser vistos como frameworks de processos que podem ser
ampliados e adaptados para criar processos de engenharia de
software mais específicos
Qualidade de Software
Ementa
17
METODOLOGIAS DE PROCESSOS
TRADICIONAIS
ÁGEIS
Qualidade de Software
Ementa
18
METODOLOGIAS TRADICIONAIS
� Também chamadas de metodologias prescritivas ou pesadas ou
orientadas a documentação
� Criadas para colocar ordem no “caos” do desenvolvimento de software
� Apresenta natureza iterativa e incremental
� Abordagens mais modernas
� Foco para controlar o processo de desenvolvimento de software 
ainda é o planejamento muito bem documentado
� Compreender o domínio do problema antes de iniciar a codificação
�Mudanças controladas
4
Qualidade de Software
Ementa
19
METODOLOGIAS TRADICIONAIS
� Metodologias tradicionais mais conhecidas
� UP (Unified Process, Processo unificado)
� RUP (Rational Unified Process)
Qualidade de Software
Ementa
20
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
21
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
22
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
Qualidade de Software
Ementa
23
PROCESSO UNIFICADO - UP
� As atividades do UP são bem definidas
� Descrição clara e precisa
� Apresenta responsáveis para cada atividade
� 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
24
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
5
Qualidade de Software
Ementa
25
PRINCÍPIOS DO UP
� Iterativo e incremental
FONTE: http://www.devmedia.com.br/introducao-ao-processo-unificado/3931
Qualidade de Software
Ementa
26
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
27
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
28
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
Qualidade de Software
Ementa
29
PRINCÍPIOS DO UP
� Exemplo: arquitetura em camadas
Fonte: http://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula2.pdf
Qualidade de Software
Ementa
30
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
6
Qualidade de Software
Ementa
31
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
32
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 arquitetura
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
33
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
34
PROCESSO UNIFICADO
� Também conhecido como “Gráfico das Baleias”
Qualidade de Software
Ementa
35
PROCESSO UNIFICADO
� As iterações do início do processo normalmente se concentram
nos 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
36
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
7
Qualidade de Software
Ementa
37
METODOLOGIAS TRADICIONAIS
� Metodologias tradicionais mais conhecidas
� UP (Unified Process, Processo unificado)
� RUP (Rational Unified Process)
Qualidade de Software
Ementa
38
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
39
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
40
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
41
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
Qualidade de Software
Ementa
42
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
8
Qualidade de Software
Ementa
43
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
44
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
45
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
46
RUP (RATIONAL UNIFIED PROCESS)
Qualidade de Software
Ementa
47
RUP (RATIONAL UNIFIED PROCESS)
� Concluindo...
� RUP não é um processo adequado para todos os tipos de
desenvolvimento
� Software embutido, por exemplo, não se enquadra
� É um moderno modelo genérico de processo, organizado em
fases, mas que separa as atividades dessas fases
Qualidade de Software
Ementa
48
BIBLIOGRAFIA
� 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.
� WAZLAWICK, Raul Sidnei. Engenharia de software: conceitos e práticas. Rio de
Janeiro, RJ: Elsevier, Campus, c2013. xxii, 343 p.
� KOSCIANSKI, André. Qualidade de software. 2ª edição. Novatec. 2007.
9
Qualidade de Software
Ementa
49
DÚVIDAS