Slides aula 6 a 10 + aula de revisao

Prévia do material em texto

AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 5
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
 Conhecer as atividades de Testes do 
processo de desenvolvimento
 Entender as necessidades da etapa de teste 
na melhoria da qualidade do sistema
 Analisar os diversos tipos de testes
OBJETIVOS DA AULA
2
AS FASES DO PROCESSO 
Requisitos
Testes Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
3
O CICLO DE VIDA
Requisitos
Testes
Desenho
Implementação
Análise 
Concepção
• Onde estão os erros?
Manutenção
Implantação
4
• A fase de teste tem como objetivo detectar 
possíveis defeitos ou erros que possam 
surgir NA da fase de implementação. 
• Nessa fase, DE TESTES deve-se coletar 
os resultados e analisá-los E 
CONSERTÁ-LOS antes de sua 
implantação. 
• Fase fundamental, muitas vezes rel2gada a 
segundo plano ou mesmo esquecida 
Incremento na QUALIDADE, na medida 
em que avaliamos sob várias óticas.
1ª. DEFINIÇÃO DE TESTE
5
1ª. DEFINIÇÃO DE TESTE
6
FASE: TESTES
• Objetivo: encontrar erros não descobertos
– Bem sucedido: Acha erro não previsto
– É preciso usar o produto
• Análise e verificação de todos os
componentes do sistema.
– Validar se estão em conformidade com os
requisitos anteriormente definidos.
– Para uma melhor analise, o teste deve ser feito
por uma equipe independente, diferente da
equipe desenvolvedora.
7
MODALIDADES DE TESTES
• Classificação quanto ao uso do código
– Testes estáticos ou Verificações
• ANTES da implementação
• Inspeções, revisões, auditorias
• Testes nas fases iniciais – qualidade
• Qualidade no processo
– Testes dinâmicos ou Validações
• DURANTE OU APÓS a implementação
• Precisa de parte ou todo sistema encarnado
• Qualidade no produto
8
MODALIDADES DE TESTES
Requisitos
Testes
Desenho
Implementação
Análise 
Concepção
• Onde estão os erros?
Manutenção Implantação
TESTES ESTÁTICOS
• REVISÕES
• AUDITORIAS
TESTES ESTÁTICOS
• REVISÃO DE CÓDIGOTESTES DINÂMICOS
• EXECUÇÃO 
9
MODALIDADES DE TESTES
• Classificação quanto objetivo
– Teste de Unidade (programação)
• Em Unidades de programas.
• Busca de Erros nos programas individuais
– Teste de Integração (prog / testes)
• Identificar erros na integração dos diversos 
módulos, já testados individualmente
– Teste de Validação (testes)
• Realizado após a integração de TODOS os 
módulos
• Antes de IMPLANTAR
10
ESTRATÉGIAS DE TESTES
• TESTE DA CAIXA PRETA (+ simples)
– Não considera a forma como esta
implementado – detalhes internos
– Objetivo:
• o sw produz os resultados esperados?
• Os requisitos estão sendo atendidos?
– Vantagem: não requer conhecimento
técnico da tecnologia empregada ou da
implementação aplicada  requer
profissional menos capacitado.
11
• TESTE DA CAIXA BRANCA (+ Complexos)
– Baseados na arquitetura interna do software.
• Verificação de código
– Objetivo: identificar defeitos nas estruturas
internas do sw, através da simulação que
“testem” toda a estrutura usada na codificação
– Desvantagem: requer conhecimento técnico da
tecnologia empregada pelo software e
arquitetura interna da solução  requer
profissional BEM capacitado.  Difíceis de
serem implementados.
– Vantagem: eficientes na detecção de erros.
• Casos de testes que cubram TODAS possibilidades
ESTRATÉGIAS DE TESTES
12
TESTE DE UNIDADE
1ª. Etapa do processo de validação.
Testa UMA unidade: modulo/classe
Objetivo: garantir a qualidade dos
componentes do software,
individualmente, avaliando:
Estrutura interna  usar estratégia de
caixa branca
Se a unidade atende aos requisitos –
usar testes da caixa preta
13
TESTE DE INTEGRAÇÃO
Natural continuidade dos testes de
Integração
 Verificar a compatibilidade da nova
unidade com as demais, já prontas.
 Verificar se Juntas e integradas, as
unidades funcionam e realizam o
trabalho que o sistema precisa.
Cuidado: alteração de componentes.
Geralmente aplica-se estratégia da
caixa preta, testando as interfaces entre
as unidades, que se integram
14
TESTES DE SISTEMAS 
(VALIDAÇÃO)
Estágio mais complexo da validação
Validam a solução como um todo.
Aqui: as falhas individuais já estão sanadas
(espera-se).
Ambiente (Hw, SO, rede e etc) bem próximo
da realidade da operação).
Testar: integração com sistemas externos,
dispositivos físicos (hw)
Dificuldade: vislumbrar os vários cenários de
uso.
Várias tipos: stress, volume, performance
15
TESTES DE ACEITE
Homologação: interna e externa
Último estágio do processo de
validação último processo formal de
detecção de erros no sistema.
Uso por clientes e usuários validarem
as funcionalidades
Usuários interagem com sistema
completo.
Reduz o risco da entrega
16
IMPORTANTE
Planejar os testes
Documentar os testes
Validar ao longo do processo.
Não “queimar” etapas de testes
Equipe especializada:
 Preferencialmente: não ser equipe de
desenvolvimento
17
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 6
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
OBJETIVOS DA AULA
 Conhecer as atividades de Implementação 
(codificação na linguagem de programação)
 Entender as necessidades da tecnologia 
para transição Projeto  Programa
 Algumas linguagens
IMPLEMENTAÇÃO
• A fase de implementação, ou codificação, 
tem como objetivo escrever o programa em 
uma linguagem de programação, seguindo 
normas e diretrizes da empresa à qual o 
desenvolvedor esteja ligado (metodologia = 
qualidade no processo)
• As empresas costumam definir padrões para 
o desenvolvimento.
IMPLEMENTAÇÃO
• Na fase da implementação, o 
programador:
– detalha e implementa o que foi definido 
na etapa de desenho, através de 
componentes de código de programa e 
documentação detalhada.
IMPLEMENTAÇÃO
IMPLEMENTAÇÃO DESENHO
Etapa do processo 
de desenvolvimento 
que realiza a 
transformação do 
desenho em diversos 
tipos de 
componentes de 
código de 
programação
Etapa do processo 
de desenvolvimento 
em que foi definida a 
arquitetura do 
sistema e definida a 
tecnologia usada na 
implementação
COMPONENTES DE CÓDIGO
• Código Fonte: Conjunto de instruções
gerados através de uma L.P., de forma lógica
e estruturada (L.P de alto nível)
• Código Objeto: Resultado da compilação do
código fonte
• Código de máquina: Sequência binária de
instruções, que são executadas diretamente
por um processador (conjunto específico de
instruções).
– Linguagem de baixo nível
– Utiliza a arquitetura do processador
LINGUAGEM DE MÁQUINA
• O Hardware é composto de componentes
eletrônicos, onde passa ou não corrente.
• A ausência ou não de corrente, cria para o
hardware uma linguagem de apenas 2
símbolos: 0 (zero) e 1 (um).
• É a chamada linguagem binária (Bi = dois)
ou linguagem de máquina.
• 0000011000100000 – seria um comando
(instrução) para um processador de 16 bits
de tamanho de palavra.
• Nos primórdios a linguagem era essa. Difícil
!!!!
LINGUAGEM ASSEMBLY
• Trocou-se 0 e 1, por mneumônicos
• Ao invés de endereçar posições físicas
de memória, usou Registradores
• ADD R1, R2, R3 ([R3]=[R1]+[R2])
• Surge o Montador
ADD R1, R2, R3 0001000100010001
Assembly Montador Máquina
LINGUAGEM DE ALTO NÍVEL
• Linguagem que se aproxima da linguagem humana
• Não leva em consideração a arquitetura do
computador, nem as características do processador
e seus registradores.
LINGUAGEM DE ALTO NÍVEL
Algoritmo
Leia (Av1, Av2)
Media (Av1+Av2)/2
Se Media >= 6.00
Então escreva (‘APR’)
Senão escreva (‘REP’)
C++ (Dev C++)
CódigoFonte
Cin>> Av1, Av2;
Media=(Av1+Av2)/2;
If (Media >=6,00)
cout<<“APR”;
else cout<< “REP”;
COMPARAÇÃO LINGUAGENS
COMO CONVERTER ?
• Homem (alto nível)  Máquina (baixo nivel)
• 2 processos fazem esse papel
– Interpretação (Interpretador)
• TRADUZ O CÓDIGO A MEDIDA QUE
EXECUTA
• Python, Pearl, PHP, Javascript, ASP
– Compilação (Compilador)
• TRADUZ E DEPOIS EXECUTA
• C++,
INTERPRETAÇÃO
• Interpretação é a "tradução" do código em
linguagem de máquina em tempo de
execução.
• É utilizada: PHP, ASP, Javascript.
• Uma característica marcante das
linguagens interpretadas são que elas
executam o código até o ponto em que há
um erro.
• Por acontecer em tempo de
execução,tipicamente tem um desempenho
um pouco menor.
INTERPRETAÇÃO
COMPILAÇÃO
• Primeiro, faz uma leitura completa do código,
identificando variáveis e outros elementos e
montando uma tabela com estas informações.
• No segundo passo, a "tradução" do código em
linguagem de máquina. Entretanto, a compilação
difere da tradução porque ela faz alterações no
código, de forma a torná-lo otimizado.
• Enquanto uma linha é sempre uma instrução na
tradução, x linhas no código terão y linhas de
comandos de máquina, de acordo com o
compilador.
• Compiladores modernos conseguem enormes
otimizações em certos códigos.
COMPILADOR / HÍBRIDO
AMBIENTES 
DESENVOLVIMENTO
AMBIENTES 
DESENVOLVIMENTO
JAVA
JAVA
BOA PRÁTICA-
PROGRAMAÇÃO
• Documentar com comentários o código
fonte
– // este procedimento visa calcular o
digito verificar com base no modulo 11
– // Data: Autor: Data alteração:
• Bons nomes – auto-explicativos e
padronizados
– variável: NA ??
– Variável: nome_aluno
PROG. BASEADA EM 
COMPONENTES
• Um componente é uma unidade reutilizável
de software, tipicamente, com fronteiras
bem definidas e encapsulado
– Independente
– Programação: componentes = classe
• Ganho de escala reaproveitamento
• Mais segurança
• Mais agilidade
• Sistema = conjunto de componentes
PROGRAMAÇÃO EM PAR
• Técnica usada nas metodologias ágeis
• 2 programadores trabalham juntos
• Ela sugere que todo e qualquer código
produzido no projeto seja sempre
implementado por duas pessoas juntas,
diante do mesmo computador, revezando-
se no teclado.
• 1 faz (executor) e outro verifica
(observador) / alternam-se nas tarefas
PROGRAMAÇÃO EM PAR
• A programação em par é uma forma eficaz de 
reduzir a incidência de bugs em um sistema.
• Isso se deve em grande parte às visões 
complementares que atuam durante o uso dessa 
prática. 
• Quando dois desenvolvedores estão programando 
em par, um deles está com as mãos no teclado e 
no mouse. O outro está sentado ao lado, olhando 
para a mesma tela e preocupado em resolver o 
mesmo problema. Ambos estão trabalhando juntos 
na solução, embora apenas um esteja com as 
mãos no teclado. Eles conversam o tempo todo e 
trocam idéias sobre a solução. 
PROGRAMAÇÃO EM PAR
• A programação em par explora a diversidade de 
idéias que é rara de ser observada quando se 
programa sozinho – troca de conhecimento
• A programação em par também é uma forma de 
fazer com que o desenvolvedor tenha mais 
confiança no código que produz, reduzindo seu 
stress
• Treinamento de programadores sem experiência.
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 7
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
OBJETIVOS DA AULA
Conhecer as atividades de:
 Suporte
 Manutenção
Entender a importância da 
documentação:
 do Processo
 do Produto
MANUTENÇÃO
 Fase que tem:
 Início: quando o sistema é instalado 
no ambiente do usuário, para uso.
 Fim: quando o sistema torna-se 
obsoleto e é substituído.
Motivos da obsolescência:
 Tecnologia ultrapassada
 Custo de manutenção supera 
benefícios
MANUTENÇÃO
Ciclo de Vida do Sistema = Ciclo de 
desenvolvimento + Manutenção
 Logo
Quanto maior o tempo da fase de 
manutenção, maior a vida útil do 
sistema
MANUTENÇÃO
A qualidade da manutenção vai 
depender da qualidade no processo de 
desenvolvimento
Documentação atualizada e 
adequada
Código eficiente e bem documentado
Desafio: manter documentação 
atualizada, na medida em que são 
feitas alterações no sistema.
ATIVIDADES DA 
MANUTENÇÃO
• Suporte ao uso do sistema
– Manuais, Help desk, visitas, 
treinamento
• Desenvolvimento
– Correção de erros (início) 
ausência ou má qualidade dos testes
– Melhorias nas funções existentes
– Implementação de novas funções
• Melhorias nas funções existentes
– Comum: efeito dominó  arquitetura 
inadequada
– Soluções
• Separação estática: identificar foco
• Refatoração: modificação da estrutura 
do software, sem alterar o 
comportamento.
ATIVIDADES DA 
MANUTENÇÃO
AFETAM O CUSTO DA 
MANUTENÇÃO
• Tipo de Aplicação
• Rotatividade e disponibilidade-Pessoal
• Duração da vida útil do sistema
• Ambiente (em que o sistema está 
inserido) que se modifica
• Características do hardware
• Qualidade do projeto, do código, da 
documentação e dos testes
• Caracteristicas das L.P. usadas
• O tempo da manutenção define o 
tempo de vida.
• Atentar para o custo.
• Elementos altamente coesos
• Elementos com baixo acoplamento
• Documentação completa e 
atualizada
AFETAM O TEMPO DA 
MANUTENÇÃO
MANUTENÇÃO COMO 
PROJETO
• Cuidado com as novas versões
– Causam instabilidade no ambiente
– Ideal: 
• menos intervenção possível
• acumular demandas que 
justifiquem a intervenção
• tratar as demandas como um 
projeto
–Dificuldade: controle das versões.
COMO ACUMULAR 
DEMANDAS
• Documento de demandas dos 
usuários
– Data, Pedido, Tipo
– Tipo
•emergencial (imediato)
•melhoria e nova função 
(analisar)
DOCUMENTAÇÃO PARA 
SUPORTE
• Manual do usuário
– Linguagem clara e adequado ao perfil 
– Mostrar como o usuário usa as 
funcionalidades
• Manual de Introdução
– Descreve as funcionalidades do sistema, 
sob a ótica do uso (uso)
– Os pré requisitos necessários para operar
DOCUMENTAÇÃO PARA 
SUPORTE
• Manual de Referência
– Descreve as facilidades do uso do 
sistema
– Informa os erros que podem ocorrer e 
como agir quando entregá-los.
• Documento de Instalação
– Descrição de como instalar o programa
– Plataforma de operação 
– Pré-requisitos necessários
DOCUMENTAÇÃO PARA 
SUPORTE
• Referência básica
– Documento com um resumo das 
funcionalidades, atalhos de procedimentos, 
principais funções utilizadas, e mensagens de 
erros mais comuns.
• Documentação do software
– Processo que descreve as partes do código 
fonte, requisitos necessários, arquitetura do 
sistema. Essa documentação é bastante útil 
para o desenvolvedor no processo de melhoria 
ou correção do produto.
DOCUMENTAÇÃO PARA 
SUPORTE
• Manual do Sistema
– Referência
• Facilidades do uso do sistema
• Erros que podem ocorrer e como agir 
– Instalação
• como instalar o sistema, plataformas 
de operação, pré-requisitos 
necessários.
DOCUMENTAÇÃO PARA 
MANUTENÇÃO
• Possibilitar que a equipe entenda o 
que foi pensado e as soluções dadas.
• Possibilitar que as alterações e novas 
funções possam ser documentadas.
• Tipo de documentação: textual e 
modelos (diagramas).
• Ferramenta CASE ajuda a manter a 
documentação VIVA e atualizada.
• Documentação do software
–Descreve as partes do código fonte, 
requisitos necessários, arquitetura 
do sistema. 
–Bastante útil para o desenvolvedor 
no processo de melhoria ou 
correção do produto.
DOCUMENTAÇÃO PARA 
MANUTENÇÃO
DOCUMENTAÇÃO DO 
PROCESSO
• Cronogramas
– Acompanhar o andamento
• Relatórios
– Documentar acompanhamento de 
recursos• Padronização de processos 
– Da empresa 
– Ou referencia nacional / internacional 
• Comunicação entre projetos.
DOCUMENTAÇÃO DO 
PROCESSO
• Documentos técnicos 
– Descreve estratégias de como chegar ao 
resultado final. 
– Registram erros, problemas e idéias que 
ocorrem durante o projeto
– As razões para tomar decisão
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 8
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
OBJETIVOS DA AULA
 Conhecer os processos em Cascata 
 Tradicional e 
 Com retroalimentação
 Entender as vantagens e limitações dos 
modelos
 Aplicar as fases do processo ao modelo.
2
CONTEXTO
Anos: 70/80
Antes: Não era usado processo de 
desenvolvimento.
 Programadores baseavam-se nas 
próprias experiências.
Não havia forma definida e 
estruturada
Não haviam testes e os erros eram 
corrigidos após implantação.
3
MODELOS INICIAIS
• Modelo Balburdia
– Base: experiência dos programadores
– 2 fases: Implementação & 
Correção
4
MODELOS INICIAIS
• Modelo Codifica-remenda
– Erros descobertos com o uso
• Ajustes em caráter de urgência
–Insatisfação e pressão dos usuários
– Surge a idéia de necessidades 
após implantação, pois os 
sistemas tornavam-se maiores.
– Confiabilidade e qualidade 
começam a ser contestadas.
5
MODELO CASCATA
• Ciclo de Vida do projeto
–Atividades ordenadas, com fluxo
contínuo para auxiliar o
acompanhamento do projeto.
• Atividades
• Fluxo de informações
• Relacionamento entre atividades
6
MODELO CASCATA
• 1º. Modelo em Engenharia de
Software
• Linear  a atividade é concluída
antes de iniciar a próxima.
–Sequencial e “para frente”
7
MODELO CASCATA
8
MODELO CASCATA
• Útil: pequenos projetos
–Sem padronização e documentação
–Ganho na fase de planejamento.
• Problema:
– Durante o projeto, a fase de
requisitos, está em constante
evolução e mudança
9
MODELO CASCATA
• Características
–base para outros modelos.
–usado até hoje.
• A questão:
–Se o processo somente pode ser
seguido após a finalização da etapa
anterior, este nunca irá se encerrar
10
MODELO CASCATA
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção Implantação
11
MODELO CASCATA
Requisitos
Testes
Desenho
Implementação
Análise 
D O C U M E N T A Ç Ã O 
12
MODELO CASCATA
• Vantagem
– Permite pontos de controle bem
definidos  facilita gestão do projeto
– Requer documentação todas as
fases.
– Em tese  só avança se cliente Valida
fase atual  Participação do usuário
(primeira tentativa de aproximar)
– Simples de implementar e gerir.
13
MODELO CASCATA - DESVANTAGENS
• Todos os requisitos devem ser descobertos
no início -- > não prevê alteração
• Não é possível corrigir erros em fases já
completas.
• Projeto raramente segue fluxo seqüencial 
iterações (vários ciclos) são necessárias.
• Não prevê manutenção.
• Usuário só vê os resultados ao final(péssimo)
• Dificulta visão de reutilização.
• Se ocorrer atraso , todo processo é afetado;
• Só gestor tem visão do todo.
14
MODELO CASCATA
• EXISTEM MUITAS VARIÁVEIS (FASES)
• AS PRINCIPAIS ATIVIDADES SÃO:
– estudo de viabilidade
– análise e especificação de requisitos
– design da arquitetura
– Design detalhado
– codificação e testes de unidades
– integração e teste do sistema
– Instalação, treinamento e entrega
15
CASCATA 
C/RETROALIMENTAÇÃO
• Variante “cascata tradicional” que
permite a realimentação
• Modelo que permite a revisão de
fases anteriores e a superposição
entre as fases.
• Correções que surgirem durante
outras fases do processo.
• Porem o custo dessa revisão pode ser
alto, dependendo da fase atual e do
quanto se precisa retroceder
16
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção Implantação
CASCATA 
C/RETROALIMENTAÇÃO
17
• Vantagem
–Possibilita a correção de erros
nas fase(s) anterior(es), durante o
processo de desenvolvimento.
–Prevê manutenção
CASCATA 
C/RETROALIMENTAÇÃO
18
• Desvantagem
–Dependendo da quantidade de
revisões e realimentações, o
processo pode se tornar difícil
de gerenciar.
19
CASCATA 
C/RETROALIMENTAÇÃO
19
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 9
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
OBJETIVOS DA AULA
 Conhecer os processos de 
desenvolvimento:
 Iterativo e Incremental
Prototipação
Espiral
CONTEXTO
Modelo Cascata
 Os projetos não tem características 
sequenciais  várias iterações
 Desenvolvimento de todo sistema
Modelo Iterativo-incremental
 Os projetos são desenvolvidos em 
porções (incremental), em várias 
iterações.
Ideia de melhoramento ou 
refinamentos sucessivos (aos poucos)
PROCESSO ITERATIVO
• Seleção de uma parte do projeto
– Identifica, especifica, implementa, 
testa e implanta a iteração
– Se atender as especificações, 
passa-se a próxima iteração.
PROCESSO ITERATIVO
PROCESSO INCREMENTAL
• Modelo que se baseia na idéia de
aumento do âmbito do sistema.
• Desenvolvimento em partes
–Ou seja, na criação de novas
versões para o modelo proposto.
• As partes podem ser
desenvolvidas em paralelo e
integradas quando completas.
PROCESSO INCREMENTAL
MODELO ITERATIVO E 
INCREMENTAL
• Processo de desenvolvimento de software
que define:
– um subconjunto de requisitos e
– utiliza o modelo em cascata para sua
realização.
• Cada porção do ciclo segue o projeto de 
arquitetura inicial como guia, mas com uma 
abordagem bem menor. 
• Uma vez satisfeitos os requisitos e os 
objetivos da iteração forem completos, o 
desenvolvimento segue para a próxima 
iteração.
MODELO ITERATIVO E 
INCREMENTAL
• Os passos fundamentais são:
– iniciar o desenvolvimento com um 
subconjunto simples de Requisitos de 
Software e 
– iterativamente alcançar evoluções 
subseqüentes das versões até o 
sistema todo estar implementado. 
–A cada iteração, as modificações de 
projeto são feitas e novas 
funcionalidades são adicionadas.
MODELO ITERATIVO E 
INCREMENTAL
MODELO: PROTOTIPAÇÃO
• Criação de um modelo para ser 
analisado e desenvolvido a partir do 
protótipo
• O Analista coletará informações para 
um mini projeto, concentrando-se nas 
entradas e saídas do software.
• Após a criação e aceitação do 
protótipo, o produto final será 
desenvolvido.
• O protótipo serve como mecanismo 
para identificar os requisitos
• Tipos de protótipo:
– em papel ou sistema: retratam a interface e 
interação
– em sistema, implementando algumas funções
• Quando usar?
– O cliente definiu um conjunto de objetivos gerais 
para o software, mas não identificou requisitos 
de entrada, processamento e saída com 
detalhes 
– O desenvolvedor não tem certeza da eficiência 
de um algoritmo ou forma da interação. 
MODELO: PROTOTIPAÇÃO
MODELO: PROTOTIPAÇÃO
• 1- OBTENÇÃO DOS REQUISITOS 
– O desenvolvedor e o cliente definem os 
objetivos gerais do software, identificam quais 
requisitos são conhecidos e as áreas que 
necessitam de definições adicionais. 
• 2- PROJETO RÁPIDO 
– É a representação dos aspectos do software 
que são visíveis ao usuário (entrada e formatos 
de saída). 
• 3- CONSTRUÇÃO PROTÓTIPO 
– É a implementação do projeto rápido. Serve 
como o “primeiro sistema” - recomendado que 
não seja usado como produto final.
MODELO: PROTOTIPAÇÃO
• 4- AVALIAÇÃO DO PROTÓTIPO 
– Cliente e desenvolvedor avaliam o protótipo. 
• 5- REFINAMENTO DOS REQUISITOS: 
– Com base na avaliação, refinam o produto
– Ocorre neste ponto umprocesso de iteração 
que pode conduzir à atividade 1 até que as 
necessidades do cliente sejam satisfeitas e o 
desenvolvedor compreenda o que precisa ser 
feito. 
• 6- CONSTRUÇÃO PRODUTO: 
– A versão de produção deve ser construída 
considerando os critérios de qualidade. 
– Protótipo deve ser descartado
MODELO: PROTOTIPAÇÃO
MODELO: ESPIRAL
• O Modelo espiral se assemelha 
com o propotipação, mas inclui um 
fator: a análise de risco. 
• Funciona de forma iterativa, 
incremental, mas com uma etapa 
onde pode ser tomada a decisão de 
se interromper ou não o processo.
MODELO: ESPIRAL
• Cada volta da espiral representa uma 
fase do processo: 
• Planejamento: Definição os objetivos, 
alternativas e restrições
• Análise de Riscos: Análise de alternativas e 
identificação dos riscos sob o ponto de vista 
técnico e de gerência
• Engenharia: Desenvolvimento do produto
• Avaliação do cliente: Avaliação dos 
resultados
MODELO: ESPIRAL
• Não há fases fixas como especificação e 
desenho - as voltas na espiral são 
determinadas pelo que é requerido. 
• Riscos são explicitamente avaliados e 
resolvidos no processo 
• Engloba as melhores características do ciclo 
de vida Clássico e da Prototipação, 
adicionando um novo elemento: a ANÁLISE 
DOS RISCOS. 
• Usa a Prototipação, em qualquer etapa da 
evolução do produto, como mecanismo de 
redução de riscos. 
MODELO: ESPIRAL
• Vantagens
– Modelo evolutivo, possibilita uma maior 
integração entre as fases e facilita a depuração 
e a manutenção do sistema.
– Permite que o projetista e cliente possam 
entender e reagir aos riscos em cada etapa 
evolutiva.
• Desvantagens
– Avaliação dos riscos exige muita experiência.
– O modelo é relativamente novo e não tem sido 
amplamente utilizado.
MODELO: ESPIRAL
COMPARATIVO
MODELO VANTAGENS DESVANTAGENS
CASCATA • MINIMIZA O TEMPO DE 
PLANEJAMENTO
• FUNCIONA COM EQUIPES 
TECNICAMENTE FRACAS
• INFLEXÍVEL
• DOCUMENTAÇÃO É 
FUNDAMENTAL
• DIFÍCIL VOLTAR ATRAS PARA 
CORREÇÃO DE ERROS
ESPIRAL • AS INTERAÇÕES INICIAS DO 
PROJETO SÃO AS MAIS 
BARATAS, PERMITINDO QUE AS 
TAREFAS DE MAIOR RISCO 
TENHAM CUSTO BAIXO.
• CADA ITERAÇÃO DA ESPIRAL 
PODE SER CUSTOMIZADA PARA 
AS NECESSIDADES ESPECÍFICAS 
DE CADA PROJECTO.
• É COMPLEXO E REQUER 
ATENÇÃO E CONHECIMENTO 
ESPECIAIS PARA SUA
IMPLEMENTAÇÃO
PROTOTIPAÇÃO • OS CLIENTES CONSEGUEM VER 
OS PROGRESSOS.
• É ÚTIL QUANDO OS REQUISITOS 
MUDAM RAPIDAMENTE E O 
CLIENTE ESTÁ RELUTANTE EM 
ACEITAR UM CONJUNTO DE 
REQUISITOS.
• É IMPOSSÍVEL DETERMINAR 
COM EXATIDÃO O TEMPO QUE 
O PROJETO VAI DEMORAR.
• NÃO HÁ FORMA DE SABER O 
NÚMERO DE ITERAÇÕES QUE 
SERÃO NECESSÁRIAS.
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 10
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
AULA 1 – Prof. MARCELO VASQUES
OBJETIVOS DA AULA
 Conhecer os processos de 
desenvolvimento:
Ágeis – XP e SCRUM
RUP – Processo Unificado
2
AULA 1 – Prof. MARCELO VASQUES
CONTEXTO:ESTADO DA ARTE
 Engenharias Tradicionais valorizam o 
Projetar ANTES de Construir
 Engenharias Tradicionais não exergam
o processo de desenvolvimento de SW 
como ele é: Com mudanças sempre
 Necessidade: Metodologia que permita
alteração frequente do SW sem afetar sua
qualidade.
 Um grupo de desenvolvedores QUER
processo menos burocrático e + prático
3
AULA 1 – Prof. MARCELO VASQUES
ENGENHARIA DE SOFTWARE
4
AULA 1 – Prof. MARCELO VASQUES
DESEJO DAS METOD. ÁGEIS
5
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENV. ÁGIL
Baseado em um MANIFESTO, criado 
por desenvolvedores experientes
Estamos descobrindo maneiras 
melhores de desenvolver software, 
fazendo-o nós mesmos e ajudando 
outros a fazerem o mesmo. 
 Foco em pessoas e não em 
ferramentas
Mudanças nos valores;
6
AULA 1 – Prof. MARCELO VASQUES
MANIFESTO ÁGIL
Valoriza-se:
Indivíduos e interações mais que 
processos e ferramentas
Software em funcionamento mais 
que documentação abrangente
Colaboração com o cliente mais 
que negociação de contratos
Responder a mudanças mais que 
seguir um plano 
7
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENV. ÁGIL
 Nossa maior prioridade é satisfazer o cliente 
 Mudanças nos requisitos são bem-vindas, 
mesmo tardiamente no desenvolvimento 
 Entregar frequentemente software 
funcionando – na menor escala de tempo 
possível.
 Pessoas de negócio e desenvolvedores 
devem trabalhar diariamente em conjunto 
por todo o projeto. 
8
AULA 1 – Prof. MARCELO VASQUES
 Construa projetos em torno de indivíduos 
motivados. Dê a eles o ambiente e o suporte 
necessário 
 O método mais eficiente e eficaz de 
transmitir informações para e entre uma 
equipe de desenvolvimento é através de 
conversa
 Software funcionando é a medida primária de 
progresso 
PROCESSO DE DESENV. ÁGIL
9
AULA 1 – Prof. MARCELO VASQUES
Em intervalos regulares, a equipe 
reflete sobre como se tornar mais 
eficaz e então refina e ajusta seu 
comportamento
PROCESSO DE DESENV. ÁGIL
10
AULA 1 – Prof. MARCELO VASQUES
• XP= eXtreme Programming.
• Baseado em 5 valores
– Comunicação, 
– Coragem (para lidar c/ mudança 
requisito) 
– Feedback, 
– Respeito (entre membros da equipe) 
– Simplicidade (fazer o necessário).
MÉTODO XP
11
AULA 1 – Prof. MARCELO VASQUES
PRÁTICAS DO MÉTODO XP
12
AULA 1 – Prof. MARCELO VASQUES
PRÁTICAS DO MÉTODO XP
13
AULA 1 – Prof. MARCELO VASQUES
MÉTODO SCRUM
O Scrum é um processo de
desenvolvimento iterativo e incremental
para gerenciamento de projetos e
desenvolvimento ágil de software
Uso: trabalhos complexos, onde não há
previsão exata do que se pretende
desenvolver
O projeto é dividido em ciclos (sprints)
O sprint é a iteração, no caso do
SCRUM
14
AULA 1 – Prof. MARCELO VASQUES
MÉTODO SCRUM
15
AULA 1 – Prof. MARCELO VASQUES
MODELO SCRUM
 Product Backlog
Lista com Funcionalidades a serem
implementadas.
 Sprint Backlog
Análise dos requisitos para informar equipe
como será implementado.
 Sprint
Período para finalização de cada requisito
 Scrum
Reunião diária para análise de andamento
 Scrum Master coordenador (não estourar o
sprint)
16
AULA 1 – Prof. MARCELO VASQUES
RUP - Rational Unified Process
Processo proprietário de desenvolvimento de
software, criado pela Rational, que foi adquirida
pela IBM.
Baseado em OO.
Processo pesado
Uso em grandes projetos
Desenvolver iterativamente
Gerenciar requerimentos  uso de casos de uso
Foca arquitetura baseada em componentes
Utiliza UML modelagem visual
Qualidade durante todo o processo
Gestão e controle de mudanças
17
AULA 1 – Prof. MARCELO VASQUES
RUP - Rational Unified Process
 Disciplinas + fases + iterações.
 Disciplinas
Modelagem de negócios
Requisitos
Análise e design
 Implementação
Teste
 Implantação
Configuração e mudanças
Projeto (gestão de pessoas, orçamento e
contratos)
Ambiente (servidores, ferramentas, Bds..)
18
AULA 1 – Prof. MARCELO VASQUES
As FASES do RUP
19
AULA 1 – Prof. MARCELO VASQUES
RUP
20
AULA 1 – Prof. MARCELO VASQUES
RUP - Rational Unified Process
2 dimensões
 Eixo horizontal
 Representa o TEMPO
 Mostra os aspectos do ciclo de
vida a medida que se desenvolve:
FASES E ITERAÇÕES
 Eixo vertical
 Representa as DISCIPLINAS,
que agrupam as atividades.
21
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA Revisão AV2 – Aulas 1 a 10
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
 1: Ciclo de Vida e Processo de SW
 2: Viabilidade, Levantamento de Requisitos 3: Fase de Análise: conceitos e modelos
 4. Fase de Desenho: conceitos e modelos
 5. Fase de Testes: conceitos e tipos
 6. Implementação
 7. Suporte e Manutenção
 8. Processos Clássicos (todo sistema)
 9. Processos Iterativo incremental
 10. Processos Ágeis e RUP
As Aulas
2
•Aula 6: Implementação
As Aulas
3
1. Com relação a fase de implementação, analise as assertivas
I. Na fase de programação é feito projeto da arquitetura do 
SW
II. As empresas precisam seguir padrões para programar
III. As instruções do programa na LP constituem o código fonte
IV. O Código de maquina resulta da compilação do código fonte
Com base em sua análise, assinale a opção correta
a) Estão corretas as opções I, II e III
b) Estão corretas as opções II e III
c) Estão corretas as opções II e IV
d) Estão corretas as opções I, II e III
e) Estão corretas as opções III e IV
AULA 6
4
2. Com relação as linguagens de programação, analise
I. A linguagem de máquina é uma e linguagem binária é outra, 
porém há uma relação entre elas.
II. A linguagem assembly dificultou a vida do programador, 
pois é mais complexa que a linguagem de máquina
III. Um programa em linguagem de alto nível tem menos 
instruções que o mesmo programa em linguagem de 
máquina
IV. O Montador converte linguagem assembly em linguagem de 
máquina
Com base em sua análise, assinale a opção correta
a) Estão corretas as opções I, II e III
b) Estão corretas as opções II e III
c) Estão corretas as opções III e IV
d) Estão corretas as opções I e II
AULA 6
5
3. A conversão da linguagem de alto nível em linguagem de 
baixo nível (máquina) pode ser realizada por 2 processos 
distintos. Assinale a opção que contém esses processos
a) Compilador e montador
b) Montador e tradutor
c) Compilador e interpretador
d) Interpretador e link-editor
AULA 6
6
4. Um dos processos de conversão de linguagens de alto nível 
em linguagem de máquina chama-se interpretação e o outro 
compilação. Marque C a descrição do processo de compilação 
e I na descrição do processo de Interpretação
a) Traduz o código a medida em que o executa _______
b) Traduz o código e depois o executa _______
c) Param quando encontram um erro, na execução ______
d) Tem desempenho menor que o outro processo _______
e) Faz otimização no código fonte _______
5) Como se chama o programa que converte código assembly
em código de máquina R: __________________________
6) Como se chama o programa que converte vários códigos 
objetos (maquina) em um executável: R: _______________
AULA 6
7
AULA 6
8
6) Um único compilador poder gerar código de máquina para 
diferentes sistemas operacionais? E para diferentes 
processadores?
Resp: Não. O compilador é dependente do hardware e do SO, 
ou seja para a linguagem X, existira um compilador Y para 
Windows e um compilador Z para MAC 
7) E como então a linguagem JAVA é dita portável (entre 
sistemas operacionais, por exemplo)?
Resp: Ela tem um único compilador, lê o código fonte em 
linguagem de alto nível que gera um código intermediário 
chamado BYTECODE e para cada plataforma existirá um 
interpretador JAVA, que transforma o bytecode em linguagem 
de máquina para cada plataforma.
- Esse interpretador é a chamada máquina virtual em JAVA.
AULA 6
9
AULA 6
10
8) Um componente á a menor unidade de software, que pode e 
deve ser reaproveitada. Sobre o conceito de componente e 
programação baseada em componentes, assinale a opção 
INCORRETA
a) O componente deve ser o mais independente possível
b) Ganha-se em agilidade com uso de componentes
c) O custo aumenta com uso de componentes
d) Aumenta a segurança com o uso de componentes.
9) Sobre a programação em PAR assinale a assertiva Correta:
a) Dois ou mais programadores trabalham juntos
b) Um programador é o líder e os demais submissos
c) Tende a aumentar a incidência de bugs em sistemas
d) Explora a diversidade de idéias e é útil para treinamento de 
programadores inexperientes.
AULA 6
11
Aula 7: Suporte e 
Manutenção
AULA 7
12
1) Com relação a fase de manutenção, assinale a ÚNICA 
resposta INCORRETA
a) Inicia quando o usuário começa a usar o sistema.
b) Termina quando instala-se a 1ª. Versão de correção 
c) O custo da manutenção historicamente tem sido alto
d) O Ciclo de vida do sistema inclui a manutenção, além do 
seu ciclo de desenvolvimento 
2) Analise cada assertiva e diga se V ou F
a) Quanto maior o tempo da fase de manutenção de um 
sistema, maior será sua vida útil..
b) Quanto mais qualidade houver no desenvolvimento, mais 
qualidade tende a ter a manutenção
c) O grande desafio da manutenção é manter a documentação 
atualizada
AULA 7
13
3) Com relação a fase de manutenção, analise as assertivas
I. A fase de manutenção só cuida de erros
II. O sistema so possui a fase de manutenção quando ter novas 
implementações a serem desenvolvidas
III. A manutenção envolve ajustes de erros, melhorias das 
funções existentes, e implementação de novas funções 
a) Estão corretas as opções I, II e III
b) Estão corretas as opções I e II
c) Apenas opção II está correta
d) Apenas opção III está correta.
AULA 7
14
4) Assinale a opção que expressa o nome da técnica que 
permite alterar a estrutura de um software, sem alterar o seu 
comportamento
a) Efeito dominó
b) Arquitetura flexível.
c) Comportamento linear
d) Refatoração
5) Dentre as opções abaixo, qual não afeta o custo de 
manutenção de um sistema
a) Rotatividade e disponibilidade de pessoal.
b) Linguagem de programação que poucos conhecem
c) Qualidade do projeto e de sua documentação
d) Ambiente do sistema, que não se modifica.
AULA 7
15
6) O efeito dominó é um problema que ocorre quando se altera 
um programa em que a mudança em uma parte do sistema 
reflete no comportamento de outras partes, aparentemente sem 
relação entre si. Esse problema acontece quando:
a) O sistema tem alto acoplamento e coesão
b) O sistema tem alto acoplamento e alta coesão
c) O sistema tem baixo acoplamento e alta coesão
d) O sistema tem alto acoplamento e baixa coesão
7) Como as demandas de manutenção devem ser tratadas?
a) Tratar cada demanda imediatamente após seu relato 
b) Tratar as demandas como um projeto
c) Tratar as demandas sempre uma vez ao mês
d) Tratar apenas as demandas de novas implementações.
AULA 7
16
8) Com relação as intervenções para atender demandas da 
fase de manutenção, analise as assertivas abaixo:
I. Intervenções podem e devem acontecer sempre que 
necessário
II. Intervenções causam instabilidade no ambiente
III. Intervenções devem acontecer de forma controlada
IV. As demandas de manutenção devem ser acumuladas até 
que justifiquem uma intervenção
Com base em sua análise, assinale apção correta
a) Estão corretas apenas I, II e III
b) Estão corretas apenas II e III
c) Estão corretas apenas II, III e IV
d) Estão corretas I e II
AULA 7
17
9) Com relação ao período que antecedeu o processo de 
desenvolvimento clássico, NÃO podemos afirmar
a) Os programadores baseavam-se praticamente em suas 
experiências, apenas.
b) Partia-se direto para desenvolver o código em linguagem de 
programação
c) Haviam testes de qualidade desde sempre
d) Não havia procedimento claramente definido.
10) Com relação ao ciclo de desenvolvimento (ou de projeto) de 
um sistema, assinale a opção correta
a) É o mesmo que ciclo de vida
b) É o período que vai da concepção a “morte” do sistema
c) É o período que inicia com a concepção e termina com a 
implantação do sistema
d) Inclui a fase de manutenção
AULA 8
18
11) Com relação ao modelo em Cascata Clássico, analise as 
assertivas abaixo
I. Tipicamente linear, ou seja sequencial e para frente.
II. Demandava “congelamento” dos requisitos levantados, sempossibilitar novos ou alterações dos iniciais.
III. Sem padronização e documentação eficiente
IV. Usuário recebe parte do sistema, de tempos em tempos
Assinale a assertiva correta com base em sua análise
a) Estão corretas apenas as opções II e III
b) Estão corretas apenas as opções I e III
c) Estão corretas apenas as opções I e II
d) Estão corretas apenas as opções I, II e III
e) Estão corretas apenas as opções I, II e IV
AULA 8
19
12) Analise cada assertiva quanto a ser V ou F
I. O processo Em cascata com retroalimentação ajusta o 
principal problema do processo Em cascata Clássico, que 
era a aceitação de mudanças nos requisitos.
II. O retrocesso no processo com retroalimentação só 
acontecia até a fase anterior.
III. Não prevê manutenção
IV. Facilmente gerenciável, mesmo com os retrocessos a fases 
anteriores.
Com base em sua análise, marque a correta sequencia de V/ F
a) V, F, F, F
b) F,F,F.F,F
c) V,V,V,F
d) V,V,F,V
AULA 8
20
13) Com relação aos processos de desenvolvimento de SW, 
analise a assertiva falsa
a) Os projetos não tem características sequencias, como 
requerido pelos processos em cascata (clássico e com 
retroalimentação)
b) Os modelos de processo em cascata não pressupõem o 
desenvolvimento de todo o sistema, em cada fase.
c) No processo iterativo o sistema é dividido em várias 
porções (interações)
d) No processo incremental a cada iteração o sistema sofre 
acréscimo de tamanho , até que fique pronto.
AULA 9
21
14) Sobre o modelo iterativo-incremental, diga se V ou F
a) Usa o modelo em cascata para desenvolver cada iteração.
b) Uma iteração deve começar definindo um conjunto de 
requisitos do software e termina com sua implantação
c) O usuário só faz contato com o sistema após a última 
iteração estar pronta
d) As modificações do projeto não podem ocorrer a cada 
iteração e sim apenas ao final de todas as iterações prontas.
Assinale a correta sequencia de V e F
a) V,V.V,V
b) V,V,F,F
c) V,V,V,F
d) F,F,V,F
AULA 9
22
15) Assinale a opção que representa a correta divisão de 
TODAS as fases do modelo de prototipação.
a) Obtenção de requisitos, projeto rápido, construção do 
protótipo, refinamento de requisitos, Construção do produto **
b) Obtenção de requisitos, projeto rápido, construção do 
protótipo, refinamento de requisitos
c) Obtenção de requisitos, construção do protótipo, 
Refinamento de requisitos, construção do produto
d) Obtenção de requisitos, projeto rápido, construção do 
protótipo, construção do produto
AULA 9
23
16) Com relação a prototipação, assinale a opção INCORRETA
a) O protótipo é um meio para que sejam definidos os 
requisitos, em tipos de projetos onde esses não são claros 
desde o inicio.
b) O produto final é ultimo protótipo gerado.
c) Pode-se usar protótipos em papel, para que aconteça o 
mais cedo possível.
d) É do tipo iterativo-incremental.
17) O que de melhor trás de novidade o processo espiral
R: a análise de riscos
18) O processo espiral usa a prototipação.
AULA 9
24
AULA 9
MODELO VANTAGENS DESVANTAGENS
CASCATA • MINIMIZA O TEMPO DE 
PLANEJAMENTO
• FUNCIONA COM EQUIPES 
TECNICAMENTE FRACAS
• INFLEXÍVEL
• DOCUMENTAÇÃO É 
FUNDAMENTAL
• DIFÍCIL VOLTAR ATRAS PARA 
CORREÇÃO DE ERROS
ESPIRAL • AS INTERAÇÕES INICIAS DO 
PROJETO SÃO AS MAIS 
BARATAS, PERMITINDO QUE AS 
TAREFAS DE MAIOR RISCO 
TENHAM CUSTO BAIXO.
• CADA ITERAÇÃO DA ESPIRAL 
PODE SER CUSTOMIZADA PARA 
AS NECESSIDADES ESPECÍFICAS 
DE CADA PROJECTO.
• É COMPLEXO E REQUER 
ATENÇÃO E CONHECIMENTO 
ESPECIAIS PARA SUA
IMPLEMENTAÇÃO
PROTOTIPAÇÃO • OS CLIENTES CONSEGUEM VER 
OS PROGRESSOS.
• É ÚTIL QUANDO OS REQUISITOS 
MUDAM RAPIDAMENTE E O 
CLIENTE ESTÁ RELUTANTE EM 
ACEITAR UM CONJUNTO DE 
REQUISITOS.
• É IMPOSSÍVEL DETERMINAR 
COM EXATIDÃO O TEMPO QUE 
O PROJETO VAI DEMORAR.
• NÃO HÁ FORMA DE SABER O 
NÚMERO DE ITERAÇÕES QUE 
SERÃO NECESSÁRIAS.
25
19) Marque a opção que NÃO representa uma característica 
dos processos de desenvolvimento ágeis, onde valoriza-se
a) Mais indivíduos e interações do que processos e ferramentas
b) Menos documentação abrangente e mais software em 
funcionamento
c) Mais colaboração com cliente do que negociação de 
contratos.
d) Mais seguir um plano do que responder a mudanças **
AULA 10
26
20) Com relação aos métodos XP e Scrum, representantes dos 
processos de desenvolvimento ágeis, associe as 2 colunas.
I. ( ) Iteração no Scrum a. Feedback
II ( ) Sprint backlog b. Dividem o código a 
implementar
III ( ) Um dos valores do XP c. Requisitos a serem 
implementados no Scrum
IV ( ) Programação em par d. Sprint
I-d; II-c; III-a IV-b 
AULA 10
27
21) 0) Como funciona a programação em par, proposta 
pelo método ágil, de nome XP (extremme 
programming).
resp: Formada por uma dupla no papel de iniciante e 
de instrutor. Como utilizam um único computador, o 
código passa 
automaticamente pelo crivo de duas pessoas, 
enriquecendo o código.
AULA 10
28
	Aula_05
	Número do slide 1
	Número do slide 2
	AS FASES DO PROCESSO 
	O CICLO DE VIDA
	1ª. DEFINIÇÃO DE TESTE
	1ª. DEFINIÇÃO DE TESTE
	FASE: TESTES
	MODALIDADES DE TESTES
	MODALIDADES DE TESTES
	MODALIDADES DE TESTES
	ESTRATÉGIAS DE TESTES
	Número do slide 12
	TESTE DE UNIDADE
	TESTE DE INTEGRAÇÃO
	TESTES DE SISTEMAS (VALIDAÇÃO)
	TESTES DE ACEITE
	IMPORTANTE
	Aula_06
	Número do slide 1
	OBJETIVOS DA AULA
	IMPLEMENTAÇÃO
	IMPLEMENTAÇÃO
	IMPLEMENTAÇÃO
	COMPONENTES DE CÓDIGO
	LINGUAGEM DE MÁQUINA
	LINGUAGEM ASSEMBLY
	LINGUAGEM DE ALTO NÍVEL
	LINGUAGEM DE ALTO NÍVEL
	COMPARAÇÃO LINGUAGENS
	COMO CONVERTER ?
	INTERPRETAÇÃO
	INTERPRETAÇÃO
	COMPILAÇÃO
	COMPILADOR / HÍBRIDO
	AMBIENTES DESENVOLVIMENTO
	AMBIENTES DESENVOLVIMENTO
	JAVA
	JAVA
	BOA PRÁTICA- PROGRAMAÇÃO
	PROG. BASEADA EM COMPONENTES
	PROGRAMAÇÃO EM PAR
	PROGRAMAÇÃO EM PAR
	PROGRAMAÇÃO EM PAR
	Aula_07
	Número do slide 1
	OBJETIVOS DA AULA
	MANUTENÇÃO
	MANUTENÇÃO
	MANUTENÇÃO
	ATIVIDADES DA MANUTENÇÃO
	ATIVIDADES DA MANUTENÇÃO
	AFETAM O CUSTO DA MANUTENÇÃO
	AFETAM O TEMPO DA MANUTENÇÃO
	MANUTENÇÃO COMO PROJETO
	COMO ACUMULAR DEMANDAS
	DOCUMENTAÇÃO PARA SUPORTE
	DOCUMENTAÇÃO PARA SUPORTE
	DOCUMENTAÇÃO PARA SUPORTE
	DOCUMENTAÇÃO PARA SUPORTE
	DOCUMENTAÇÃO PARA MANUTENÇÃO
	DOCUMENTAÇÃO PARA MANUTENÇÃO
	DOCUMENTAÇÃO DO PROCESSO
	DOCUMENTAÇÃO DO PROCESSO
	Aula_08
	Número do slide 1
	OBJETIVOS DA AULA
	CONTEXTO
	MODELOS INICIAIS
	MODELOS INICIAIS
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA
	MODELO CASCATA - DESVANTAGENS
	MODELO CASCATA
	CASCATA C/RETROALIMENTAÇÃO
	CASCATA C/RETROALIMENTAÇÃO
	CASCATA C/RETROALIMENTAÇÃO
	CASCATA C/RETROALIMENTAÇÃO
	Aula_09
	Número do slide 1
	OBJETIVOS DA AULA
	CONTEXTO
	PROCESSO ITERATIVO
	Número do slide 5
	PROCESSO INCREMENTAL
	PROCESSO INCREMENTAL
	MODELO ITERATIVO E INCREMENTAL
	MODELO ITERATIVO E INCREMENTAL
	MODELO ITERATIVO E INCREMENTAL
	MODELO: PROTOTIPAÇÃO
	MODELO: PROTOTIPAÇÃO
	MODELO: PROTOTIPAÇÃO
	MODELO: PROTOTIPAÇÃO
	MODELO: PROTOTIPAÇÃO
	MODELO: ESPIRAL
	MODELO: ESPIRAL
	MODELO: ESPIRAL
	MODELO: ESPIRAL
	MODELO: ESPIRAL
	COMPARATIVO
	Aula_10
	Número do slide 1
	OBJETIVOS DA AULA
	CONTEXTO:ESTADO DA ARTE
	ENGENHARIA DE SOFTWARE
	DESEJO DAS METOD. ÁGEIS
		PROCESSO DE DESENV. ÁGIL
	MANIFESTO ÁGIL
	PROCESSO DE DESENV. ÁGIL
	PROCESSO DE DESENV. ÁGIL
	PROCESSO DE DESENV. ÁGIL
	MÉTODO XP
	PRÁTICAS DO MÉTODO XP
	PRÁTICAS DO MÉTODO XP
	MÉTODO SCRUM
	MÉTODO SCRUM
	MODELO SCRUM
	RUP - Rational Unified Process
	RUP - Rational Unified Process
	As FASES do RUP
	RUP
	RUP - Rational Unified Process
	revisaoav2
	Número do slide 1
	Número do slide 2
	Número do slide 3
	AULA 6
	AULA 6
	AULA 6
	AULA 6
	AULA 6
	AULA 6AULA 6
	AULA 6
	AULA 7
	AULA 7
	AULA 7
	AULA 7
	AULA 7
	AULA 7
	AULA 8
	AULA 8
	AULA 8
	AULA 9
	AULA 9
	AULA 9
	AULA 9
	AULA 9
	AULA 10
	AULA 10
	AULA 10