modelos de processo

Prévia do material em texto

11/08/2016
1
Curso – Análise e Desenvolvimento de Sistemas
Disciplina – Teste de Software
1 – Modelos de Processos de Desenvolvimento de 
Software
Prof. Edson Saraiva de Almeida
Agosto/2016
Fatec
Apresentação
• Nome
• Realizando estágio?
• Familiaridade com a IDE Eclipse
• Familiaridade com a programação Java
• Quais livros, jornais, revistas ou artigos você leu recentemente 
relacionado a práticas de desenvolvimento de software?
2
11/08/2016
2
Bibliografia
• Delamaro, M.E. et al., Introdução ao Teste de Software, Rio de Janeiro: 
Elsevier, 2007
• PRESSMAN, R.S., Engenharia de Software, 6ed., São Paulo:McGraw-Hill, 
2006
• SOMMERVILLE, I., Engenharia de Software, 8ª ed., São Paulo: Pearson 
Addison Wesley, 2007 
• Beck, K. Test-driven development by example. EUA:Addison Wesley, 2002
• Crispin, L., Gregory, J., Agile Testing, Boston: Addison Wesley, 2009
• Grahan, D. et al., Foundations of Software Testing, Thomson Learning, 2007
3
Plano de Ensino
• Qualidade de Software
• Princípios de teste de software
�Fases de teste - Teste de Unidade, Teste de Integração, Teste de Sistemas
�Teste Funcional, Teste Estrutural, Teste de Regressão
�Teste alfa, beta e de aceitação
• Desenvolvimento Orientado a Testes
�Automação da atividade de teste
�Teste de aplicações Web
• Governança de Teste – planejamento, registro e acompanhamento 
de problemas
4
11/08/2016
3
Avaliação
• Formula de Calculo
�MAX(MAX(N1+N2, N1+N3), N2+N3)/2
• Prova P1 – 0 a 7
• Participação e experimentação – 0 a 3 
• Prova P2 – 0 a 10 
• Participação e experimentação 
�Participação não significa a simples publicação dos exercícios envolve a discussão em 
aula e experimentação 
�Falta de atenção, realização de atividades não pertinentes a disciplina, falta na aula 
penalizam a participação
• Média >= 6 aprovado
• Exame – toda a matéria 
5
Participação e Experimentação
• Repositório para entrega de exercícios
1. Criar uma pasta no google drive, na pasta compartilhada pelo professor, indicando 
nome completo e ra (tudo em minúscula) exemplo - jose da silva xavier - 12121212 
2. A pasta criada também deve ser compartilhada com o professor -
prof.edsonalmeida@fatec.sp.gov.br
3. No semestre são solicitadas 6 tarefas: lab01, lab02, lab03, lab04, lab05, Lab06
4. De acordo com o prazo estabelecido previamente na data esperada o aluno deve 
concluir a tarefa e publicar na sua pasta compartilhada com o professor.
5. O mecanismo de organização por pastas permite rapidamente ao professor 
verificar quais as tarefas que foram entregues pelo aluno e realizar uma revisão do 
conteúdo.
6. As notas de aula são disponibilizadas pelo professor no laboratório
7. Por favor, mantenham-me informado de qualquer erro ou falta de esclarecimento 
ou locais onde mais explicações sejam necessárias
6
11/08/2016
4
Participação e Experimentação
• Repositório para entrega de exercícios
1. Os trabalhos podem ser realizados em duplas
2. Cada aluno publica sua atividade individualmente
3. Um aluno do grupo deve ser responsável pela edição, demais alunos 
inclusive o professor (prof.edsonalmeida@fatec.sp.gov.br) devem ter direito 
de leitura
4. Documentos devem ser enviados em formato pdf.
5. Manter o histórico do documento
7
Modelos de Processo de Desenvolvimento de 
Software
• Objetivos
�Qual a importância dos modelos de processos no processo de 
desenvolvimento de software?
�Como as atividades de Teste de Software influenciam os modelos de processo 
de desenvolvimento?
8
11/08/2016
5
Modelos de Processos de Desenvolvimento 
de Software
• Modelos de processo foram originalmente 
propostos para colocar ordem no caos 
estabelecido pelo processo de desenvolvimento 
de software.
Modelos de 
Processo
• Servem como um guia, mas não respondem a 
todos os problemas encontrados no processo 
de desenvolvimento. 
Guia
9
Modelos de Processos de Desenvolvimento 
de Software
• Definem um conjunto de atividades, marcos 
e produtos de trabalho para permitir a 
entrega de software com qualidade.
São 
prescritivos
• Para atender as necessidades da equipe em 
projetos específicos.
Podem ser 
adaptados
10
11/08/2016
6
Modelos de processo de desenvolvimento
• Existe um grande debate na utilização de modelos de processo em cascata 
e estilos iterativos.
• O modelo iterativo é visto como moda, enquanto o processo em cascata 
parece uma abordagem ultrapassada. A consequência é que muitos 
projetos que pretendem utilizar o modelo iterativo, estão na realidade 
utilizando o modelo cascata. 
• A diferença essencial entre os dois esta relacionada a estratégia de como 
dividir o projeto em partes menores.
• Em um projeto com uma estimativa de conclusão de 12 meses, é difícil 
para o cliente ficar confortável em solicitar o projeto e retornar depois de 
uma ano quando terminar. Alguma quebra é necessária para que as 
pessoas possam abordar o problema e acompanhar o progresso.
11
FOWLER, Martin. UML distilled: a brief guide to the standard object modeling language.
Addison-Wesley Professional, 2004.
Modelo Cascata
• Devido ao encadeamento de uma fase em outra esse modelo é 
conhecido como modelo cascata, a próxima fase só é iniciada quando a 
fase anterior estiver concluída e aprovada.
O resultado de cada fase consiste 
em um ou mais documentos 
assinados e aprovados
12
Análise de 
Requisitos
Projeto
Codificação
Teste
11/08/2016
7
Modelo Cascata
• Devido ao encadeamento de uma fase em outra esse modelo é 
conhecido como modelo cascata, a próxima fase só é iniciada quando a 
fase anterior estiver concluída e aprovada.
O resultado de cada fase consiste 
em um ou mais documentos 
assinados e aprovados
13
Análise de 
Requisitos
Projeto
Codificação
Teste
2 Meses
4 Meses
3 Meses
3 Meses
Plano de 
projeto
Como as atividades de teste de software influenciam 
o modelo de processo de desenvolvimento
• Taxonomia de defeitos
Técnicas utilizadas no controle 
de processos visando sua 
melhoria
14
Análise de 
Requisitos
Projeto
Codificação
Teste
2 Meses
4 Meses
3 Meses
3 Meses
Plano de 
projeto
11/08/2016
8
Modelo Cascata - vantagens
•Apresenta uma visão de alto nível e sugere aos desenvolvedores a sequencia de 
eventos esperada para a entrega do software.Visão de alto nível
•O desenvolvimento de um estágio deve terminar antes do próximo começar
Desenvolvimento em 
estágios
•Explicita os produtos intermediários necessários para começar o próximo estágio 
de desenvolvimento.
Produtos 
intermediários
•Associados a cada atividade do processo existem marcos e produtos.
•Os gerentes do projeto podem utilizar o modelo para estimar o término do projetoMarcos
15
Modelo Cascata - desvantagens
• Projetos reais raramente seguem o fluxo sequencial que o 
modelo propõeFluxo sequencial
• O modelo tem dificuldades para acomodar as incertezas naturais 
que existem no começo do projetoMudanças
• Uma versão executável do programa não vai ficar disponível até 
o projeto terminar – um erro grosseiro pode ser desastroso. Risco
• Estados de bloqueio – alguns membros da equipe precisam 
esperar que outros membros completem tarefas dependentes.Estados de bloqueio
16
11/08/2016
9
Modelo Cascata – critérios de seleção
• Deve ser utilizado quando os requisitos forem bem compreendidos e houver 
pouca probabilidade de mudanças radicais durante o desenvolvimento do 
sistema (SOMMERVILLE, 2007 – pag 45). 
Requisitos estáveis
• As bases para competição são entendidasMercado bem definido
• São conhecidosClientes
• É realizado na fase final do projetoControle da qualidade
17
Modelo V18
Codificação
Execução do Teste 
de Unidade
Preparação dos testes de aceitação
Preparação dos testes de sistema
Preparação dos Testes
de Integração
Requisitos de 
Sistema
Projeto detalhado
Executa o Teste de 
Integração
Requisitos de 
usuário
Executa o Teste de 
Sistema
Executa os Testes 
de Aceitação
CRAIG, Rick David; JASKIEL, Stefan P.; JASKIEL, Stefan P. Systematic software testing. Boston: Artech House, 2002.
11/08/2016
10
Modelo V
• Destina-se a mostrar que um sistema esta em 
conformidade com sua especificação e que 
atende as expectativas do cliente que esta 
adquirindo o software
Conformidade 
com a 
especificação
• Utilizando atividades de teste associadas a cada 
estágio do processo de software (teste de 
sistema/aceitação, teste de integração, teste de 
unidade)
Controle da 
Qualidade
19
Modelo V – critérios de seleção
• É utilizado com objetivo de se detectar erros nas fases 
intermediarias do processo de desenvolvimento de software 
ou seja atividades de controle da qualidade são realizadas 
em todas as fases do processo de desenvolvimento.
Melhoria de 
processo
• O cliente pode exigir evidencias das atividades de teste
Oferecer evidencias 
da realização das 
atividades de teste
20
11/08/2016
11
Desenvolvimento Iterativo e Incremental
• Atualmente o trabalho de software é executado em ritmo 
rápido.Agilidade
• Sujeito a um volume sem fim de modificações.
• O modelo cascata é frequentemente inadequado para 
este tipo de trabalho
Mudanças 
frequentes
• O aumento da demanda e a pressão por prazos exigiu 
novos modelos de processo para ajudar a reduzir o tempo 
de desenvolvimento
Pressão por 
prazos
21
Desenvolvimento Iterativo e Incremental
• No desenvolvimento iterativo incremental, o 
sistema, como está especificado na 
documentação de requisitos é dividido em 
subsistemas por funcionalidades. 
Iterações
• As versões são definidas, começando por um 
pequeno subsistema funcional e mais 
funcionalidades são adicionadas a cada versão. 
Feedback 
frequente
22
11/08/2016
12
Desenvolvimento Iterativo e Incremental
• Combina elementos do modelo 
cascata aplicado de maneira iterativaAbordagem
23
Desenvolvimento Iterativo e Incremental
• Produz software funcional 
diferentemente do modelo tradicionalIteração
• Obter confirmação do cliente
Verificação a 
cada etapa
• Cada iteração é um mini-projetoMini-projeto
24
11/08/2016
13
Desenvolvimento Iterativo e Incremental
• O Desenvolvimento Iterativo e Incremental é um dos clássicos modelos de processo de 
desenvolvimento de software criado em resposta às fraquezas do modelo em cascata, o 
mais tradicional. Os dois padrões mais conhecidos de sistemas iterativos de 
desenvolvimento são o RUP (Processo Unificado da Rational) e o Scrum.
Criado em respostas as 
fraquezas do modelo 
cascata
• RUP - Infra-estrutura genérica de processo que pode ser especializada para uma ampla 
classe de sistemas de softwareRational Unified Process
• É uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, 
os projetos são divididos em ciclos chamados de Sprints. O Sprint representa um Time 
Box dentro do qual um conjunto de atividades deve ser executado. 
Scrum
25
RUP – visão geral
• O RUP está fundamentado em três princípios básicos: dirigido por casos 
de uso, centrado na arquitetura, iterativo e incremental. Princípios
• Com base no modelo de casos de uso, são criados uma série de modelos 
de análise, projeto e implementação, que realizam estes casos de uso. 
Dirigido por 
casos de uso
• É centrado na arquitetura, pois defende a definição de um esqueleto da 
arquitetura para a aplicação nas fases iniciais do ciclo de 
desenvolvimento refinado gradualmente ao longo do desenvolvimento. 
Centrado na 
Arquitetura
26
11/08/2016
14
RUP – visão geral
27
• Variação do esforço no tempo
• O eixo horizontal representa o 
tempo e mostra os aspectos do 
ciclo de vida do processo à medida 
que se desenvolve
• O eixo vertical representa as 
disciplinas, que agrupam as 
atividades de maneira lógica, por 
natureza
Scrum – visão geral
28
• As funcionalidades a serem implementadas 
em um projeto são mantidas em uma lista 
que é conhecida como Product Backlog. 
• No início de cada Sprint, faz-se um Sprint 
Planning Meeting, ou seja, uma reunião de 
planejamento na qual o Product Owner
prioriza os itens do Product Backlog e a 
equipe seleciona as atividades que ela será 
capaz de implementar durante o Sprint que 
se inicia. 
• As tarefas alocadas em um Sprint são 
transferidas do Product Backlog para o 
Sprint Backlog.
11/08/2016
15
Desenvolvimento Iterativo e Incremental –
critérios de seleção
• Resolver os principais riscos antes que se faça muitos 
investimentos no projetoDiminuir os Riscos
• Disponibilizar um retorno mais rápido para o cliente, 
software integrado e testado - que pode ser instalado 
no ambiente do produção 
Necessidades de 
entregas parciais
• Quando não é possível concluir o escopo previsto 
dentro deste período deve-se retirar alguma das 
funções que seriam entregues e manter a data 
Foco na Qualidade 
não no Escopo
29
ESBC
• Processo que enfatiza o projeto e construção de sistemas baseados em 
componentes de software reutilizáveis.
Engenharia de Software 
Baseada em Componentes
• Na maioria dos projetos de software, existe algum reuso de software. Isso 
ocorre geralmente de maneira informal.Reuso
• Supõe que partes do sistema já existem e podem ser reutilizadas. O processo 
de desenvolvimento concentra-se na integração dessas partes.Critérios de seleção
• É um principio que define o estilo da arquitetura de software considerando 
que as funções implementadas pelas aplicações devem ser disponibilizadas 
na forma de serviços
Arquitetura Orientada a 
Serviços
30
11/08/2016
16
Modelos de Processo de Desenvolvimento de 
Software
• Modelos de processo definem um conjunto de atividades, ações, 
tarefas, marcos e produtos de trabalho que são necessários para fazer 
engenharia de software com alta qualidade. 
• Fornecem estabilidade, controle e organização a uma atividade que 
pode, se deixada sem controle, tornar-se bastante caótica. 
• Cada modelo de processo deve ser adaptado para que seja usado 
efetivamente em um projeto de software especifico.
• Esses modelos de processo não são perfeitos, mas efetivamente 
fornecem um roteiro útil para o trabalho de engenharia de software.
31
Modelos de Processo de Desenvolvimento de 
Software
• Qual a importância dos modelos de processos nas atividades de Teste 
de Software?
• Como as atividades de Teste de Software influenciam os modelos de 
processo de desenvolvimento?
32
11/08/2016
17
Atividades
• Entregar na próxima aula o lab01 – modelo de processos.
33
Bibliografia
• PRESSMAN, R.S., Engenharia de Software, 6ed., São Paulo:McGraw
Hill, 2006 (cap. 3)
• SOMMERVILLE, Ian. Engenharia de software. 8a. ed Addison Wesley, 
2007 (cap. 4)
34