0 COMPILADO Processo de Desenvolvimento de Software COMPLETO AULAS RESUMOS REVISAO PROVAS AV1 AV2 AV3 SaibaMais EXTRAS Graduacao Gestao Tecnologia da Informacao

Prévia do material em texto

AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 1
Prof. MARCELO VASQUES
mvasqueso@gmail.com
OBJETIVOS DA AULA
• Apresentar os conceitos de:
– Sistema de Informação.
– Software
– Processo de Desenvolvimento de SW
• Abordar os problemas do Software atual e 
origens no processo de desenvolvimento
2
BLIBLIOGRAFIA
• CAPÍTULO 1
• LIVRO: ENGANHARIA DE SOFTWARE –
Fundamentos, métodos e padrões
• 3ª. Edição / 2009 / editota LTC
• Wilson de Pádua Paula Filho
3
SISTEMA DE INFORMAÇÃO
• Sistema = Conjunto de partes, independentes, 
cada qual com seu objetivo e colaborando por um 
objetivo comum.
• Informação = Dados (fatos isolados) agrupados e 
relacionados (processados), com sentido lógico.
– Dados: chq 1235 de 1.250,00, chq 1236 de 
750,00
– Dado: saldo Anterior é 5.000,00
– Informação: Saldo Atual é 3.000,00
• Sistema de Informação = Conjunto de elementos 
inter-relacionados que coleta (entrada), manipula 
(processamento), armazena a dissemina (saída) 
informações
4
SISTEMA DE INFORMAÇÃO
• Manual
– Processa pouco volume de dados
• Baseado em computador (Usa TI)
– Hardware (componentes físicos – desgastes)
– Software (componentes lógicos)
– Banco de dados (armazenamento)
– Telecomunicações (rede, internet)
– Pessoas (mais importante. Fazem a diferença)
– Procedimentos e processos (organização)
5
SISTEMA DE INFORMAÇÃO
• O valor de um SI depende da qualidade de seus 
componentes. 
– Excelentes algoritmos codificados em seu 
software X péssimo desempenho por defeito na 
especificação do hardware, rede ou BD 
– Cada um de seus elementos pode por em 
cheque a confiabilidade e usabilidade do SI
• O engenheiro de software precisa saber a quem 
chamar quando o problema não for especificamente 
no software.
6
SISTEMA DE INFORMAÇÃO
• A Tecnologia não faz milagre !!!
• Os problemas com sistema de informática podem 
ter várias causas
– As pessoas que operam o sistema podem ser 
mal qualificadas. Investimento em 
treinamento
– Processos de negócios inadequados (no qual 
o sistema esta inserido)
– Deficiência do próprio sistema. Tecnologia 
inadequada
7
SOFTWARE
• Porção lógica de um SI, que comanda a 
operação do computador.
• Tipos de Software, quanto a natureza
– Software de Sistema: controlam as operações 
do computador: software da BIOS, S.O., L.P.
– Software aplicativo: interface direta com usuário
• Software hoje – Como administrar?
– Grandes e Complexos (envolvem toda 
organização)
– Demandam rápidas mudanças.
8
• Responsável por prover o produto mais importante 
de nossa sociedade: a informação.
• Melhorias nos últimos 50 anos: Hw, BD, Redes –
aumento capacidade de processamento + 
diminuição dos custos
• Por que SW não acompanhou?
– Por que levar tanto tempo para concluir o SW?
– Por que os custos do SW são tão elevados?
– Por que não achamos o erros antes da entrega?
– Por que os custos de manutenção são altos?
SOFTWARE
9
• Processo de desenvolvimento do HW é um 
sucesso. O do SW não. Por que?
Hardware Software
Fabricado Manufaturado
Falhas Inicio e fim Falhas ao ser alterado
Substitui peças Tem que ser alterado
Montagem: 
componentes padrões
Desenvolvido: difícil
padronizar para re-uso.
SOFTWARE
10
• O desenvolvimento do SW depende MUITO do 
componente humano. 
– Há pouca automação no desenvolvimento.
– Visão de projeto inadequada.
• Histórico: gestor de TI sem formação em 
ADM.
• Gestão (planejamento, organização e 
controle) de prazos e custos ineficiente
– Pressão dos usuários/clientes: rapidez.
• Daí os problemas
– Prazos, Custos, Comunicação
SOFTWARE
11
REALIDADE. CRISE DO SW
Fatos reais - Projetos de Software
+ 30% dos projetos – CANCELADOS
+ 70% dos projetos – FALHAM as funcionalidades
Orçamento e Custo EXTRAPOLAM
Custos – em mais de 180% a previsão
Prazos – em mais de 200% o cronograma
Custos do DESENVOLVIMENTO
80% - identificar e corrigir defeitos de programação
12
13
CICLO DE VIDA DO SW
• 1. Começo: percepção de necessidades.
• 2. Desenvolvido, transformado-se em um 
conjunto de itens a ser entregue ao usuário
• 3. Entra em operação, sendo usado dentro 
de um processo de negócio e sujeito a 
atividades de manutenção.
• 4. Fim: é retirado de operação ao final de 
sua vida útil.
14
COMO DESENVOLVER?
• Passado
– Necessidades → Programação (CAOS)
• Hoje
– Projeto e Processo de desenvolvimento
• Qual a finalidade do SW?
• Quais as funções o SW terá? 
• Como essas funções se integrarão?
• Como o SW se integrará ao contexto da 
empresa?
• Quanto tempo terei para construí-lo?
15
PROCESSO
Conceito de Processo
• Maneira pela qual se realiza uma operação, 
segundo determinadas normas
O método da engenharia se baseia em uma ação 
sistemática e não improvisada.
ATIVIDADES
 TAREFAS
 SUBPROCESSOS
 PROCESSO
16
PROCESSO DE DESENVOLVIMENTO
Concepção Requisitos Análise Projeto
Codificação Testes Homologação Implantação
Manutenção
Organização das fases, estabelecendo:
• Quais são elas?
• Finalidade de cada uma?
• Ordem e ligação entre elas?
• Funcionamento do processo
• Documentação e modelos de cada fase
17
CONCEITOS FUNDAMENTAIS
• Escopo – Abrangência
– Compreende o que será considerado para o 
desenvolvimento.
– Quanto maior o escopo, maior é a 
complexidade e dificuldade de gerenciar o 
desenvolvimento.
• Requisito = Necessidades do usuário
– Compreende as funcionalidades que o sistema 
deve possuir.
• Fundamental – Definir os requisitos que farão 
parte do escopo.
18
CONCEITOS FUNDAMENTAIS
• Problemas e erros de requisitos são os 
mais caros de resolver.
– Quanto mais o tempo passa, pior
• Problemas 
– Má definição do escopo do sistema (má 
atuação profissional).
– Rápida mudança de escopo (atualidade)
• Ou seja Atenção TOTAL aos Requisitos 
19
ENGENHARIA DE REQUISITOS
• Problema – levantamento e documentação de 
requisitos
– Boa documentação – boas chances de atender 
aos requisitos
– Boa especificação de requisitos - fundamental 
• Engenharia de Requisitos
– Técnicas de levantamento de requisitos
– Documentação.
– Análise de Requisitos
20
GESTÃO DOS REQUISITOS
• Problema: Instabilidade nos Requisitos
– Novos requisitos e Alterações de requisitos 
com o desenvolvimento já adiantado.
– Alto custo, Re-trabalho, perda de trabalho feito
– O mesmo que alterar a planta estrutural de 
uma casa, após iniciada a construção.
• A boa engenharia de requisitos tende a 
reduzir a instabilidade, obtendo os 
requisitos no momento oportuno.
21
PRAZOS E CUSTOS
• Requisitos → Prazos e custos
– A quantidade e complexidade dos requisitos 
mandam na relação de causa e efeito sobre 
prazos e custos.
– Ouve-se muito: “não me interessa o que você 
vai dizer ! Preciso disso em 1 mês”. 
• A questão: No início só temos requisitos.
– É difícil medir os programas necessários com 
base me requisitos.
– Após projeto detalhado se conhece melhor os 
detalhes. Mas usuário não espera.
22
PRAZOS E CUSTOS
• É preciso
– Planejamento e controle de projetos
• Análise dos riscos (probabilidade de sua ocorrência 
e ações corretivas, caso aconteçam)
• Acompanhar o progresso do projeto
– Renegociação dos prazos e custos
– Garantir a qualidade do processo
• Garantia = conformidade com requisitos
• Qualidade do produto é influencia da pela qualidade 
no processo
• Quanto ANTES um problema for identificado e 
resolvido, melhor (menos custo)
23
PROBLEMAS NO PROCESSO
• Software atual é: complexo, grande e com 
interface com demais sistemas.
• Necessidade de equipe grande, competente 
e interdisciplinar.
• O tempo geralmente é grande.
• Ou seja a gestão do processo de 
desenvolvimento está mais complexa
• Facilitador: Ferramentas de automação 
(case)
24
• Detalhamento do conceito de Requisito
• Análise de Viabilidade do Sistema
• Técnicas de Levantamento de 
Requisitos
25
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTODE SOFTWARE 
AULA 2
Prof. MARCELO VASQUES
mvasqueso@gmail.com
OBJETIVOS DA AULA
• Apresentar Estudo de Viabilidade
• Definir conceito e tipos de Requisitos
• Descrever atividades para análise de 
requisitos
• Apresentar técnicas para elicitar e analisar 
Requisitos
2
REVISÃO
• Processo de desenvolvimento
• Conjunto de fases, cada qual com 
uma finalidade, que descrevem 
passo a passo, formalmente, o que 
devem ser feito para desenvolver 
um sistema.
• Cria um padrão, para todos 
seguirem
• Confere qualidade ao software
3
ESTUDO DE VIABILIDADE
• Concepção
✓ Semente → Necessidade, idéia
✓ O que é o sistema? – definições 
iniciais
✓ É viável? → Vale a pena?
• Estudo ou Análise de Viabilidade
✓ Benefício deve superar o Custo?
➢ Empresa
➢ Negócio a que se destina
4
ANÁLISE 
DE
VIABILIDADE
Entrada:
1.Conjunto preliminar de requisitos de negócio
2.Esboço da Descrição do Software
3.Como apóia a área de negócios
Saída:
1.Viável? (técnica, operacional e financeiramente)
ESTUDO DE VIABILIDADE
5
• O SW contribui para os objetivos da 
organização? Beneficia os interessados?
– Viabilidade Operacional
• O SW pode ser implementado com TI atual?
– Viabilidade Técnica
• Restrições de custo serão atendidas?
– Viabilidade econômica
• Restrições de prazo serão atendidas?
– Cronograma
ANÁLISE DE VIABILIDADE
6
VIABILIDADE ECONÔMICA
• Apurar o retorno sobre o investimento (ROI)
– % que mede a relação entre o quanto se 
ganha (pretende ganhar) e quanto se investe.
• ROI=(Lucro Liquido)/Investimento
– Lucro Liquido = receitas – despesas (todas)
– Investimento = Tudo que será investido para o 
sistema: Softwares, Hardware, Redes, obras 
e etc.
– Quanto MAIOR O VALOR, melhor o ROI
7
▪Investimento = R$ 40.000,00
▪Desenvolvimento: 20.000
▪Softwares: 5.000
▪Hardware + rede + Internet: 10.000
▪Mobiliário: 5.000
▪Receitas (Vantagens) com sistema: R$ 15.000,00
▪Despesas com sistema = R$ 5.000,00
▪Lucro Líquido com sistema = R$ 10.000,00
▪ROI = 10.000,00 / 40.000,00 = ¼ = 0,25
▪Conclusão: O investimento se paga em 4 anos.
VIABILIDADE ECONÔMICA
8
• Elicitação → Elicitar = descobrir, tornar 
explícito.
– Expliciar o que? Resposta: Requisitos
• Requisitos (necessidade do usuário)
– Descrições dos serviços fornecidos pelo 
sistema.
– Restrições e características desses 
serviços
Refletem a necessidades dos seus 
usuários
ENGENHARIA DE REQUISITOS
9
• Requisito de usuário (abstratos- nível alto)
– Descrição dos serviços esperados do sistema 
e restrições sobre as quais ele deve operar
– “O sistema deve controlar o bloqueio de 
exemplares pelo professor”
• Requisito de Sistema (detalhado)
– Definição estruturada e detalhada dos 
serviços e restrições operacionais
– Detalhar as funções de Bloqueio de 
exemplares
CLASSIFICAÇÃO:REQUISITOS
• Funcionais
– Declarações de serviços que o sistema 
deve fornecer e como deve se comportar.
– Pode estabelecer o que o sistema NÃO 
deve fazer
• Não Funcionais
– Restrições sobre os serviços ou funções 
oferecidos pelo sistema
– Características ou qualidades
REQUISITOS DE SISTEMAS
• Funcionais
– RF: Sistema deve informar melhor aluno
– RF: Sistema deve permitir incluir e excluir 
fornecedores
• Não Funcionais
– RNF: A impressão do boleto deve ser em no 
máximo 10 segundos
– RNF: as dimensões dos relatórios devem ser 
configuráveis
– Restrições de hardware, ambiente e etc
EXEMPLOS DE REQUISITOS
• Exemplo: Sistema de Caixa Eletrônico
– Tipos de transações suportadas na Conta
• Funcional
– Tempo de resposta, facilidade de uso e 
tempo médio entre as falhas
• NÃO Funcional
EXEMPLOS DE REQUISITOS
13
• Quando usar?
– Primeira técnica a ser usada com alto escalão
para entendimento da organização
(organograma).
• Fechadas (questionário) ou abertas (roteiro)
• Individual ou pequeno grupo
• V - Eficiente
• D - Cara (falta de tempo das pessoas).
• V- Permite observar postura corporal. “Olhar nos
olhos”.
• D - Cuidado: não se perder (roteiro)
ENTREVISTA
14
• Quando usar?
– Muitos usuários e há necessidade de uma análise
estatística.
– Falta de tempo dos envolvidos para entrevistas.
– Usuários estão geograficamente distantes (pesquisa de
satisfação na Estácio)
• Evitar: perguntas abertas.
– O que você do procedimento atual... ?
• Focar: perguntas direcionadas ao que se deseja
saber. Exp: Considera o procedimento atual
– ( ) Ruim ( ) Satisfatório ( ) Ótimo
QUESTIONÁRIO
15
• Reuniões onde participam todos os
envolvidos
• Objetivo: permitir que todos expressem
suas idéias de forma a obter o consenso.
• Todos expressão de forma desorganizada
mesmo
• Organizam-se as idéias
• Identifica-se conflitos entre áreas
• Visões diferentes do requisito nas
empresas.
BRAINSTORM
16
• É na verdade um modelo da UML, usado
para: definir o escopo do sistema, identificar
quem interage com o sistema (atores)
identificar os requisitos (casos de uso),
validar os requisitos com os usuários
• Não é em si uma técnica de levantamento
de dados, mas o resultado produzido após.
• E esse resultado, que é o modelo
(desenho) pode ser usado para validar os
requisitos com os usuários.
CASO DE USO (CUIDADO)
17
18
• Observação “in locco” – analista se insere
no dia a dia da empresa. Constatar o que
foi levantado e entender funcionamento na
prática.
• Análise de documentos
• JAD – excelente para projetos que
necessitam discussão de várias áreas da
empresa.
OUTRAS TÉCNICAS
19
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 3
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
▪ Conhecer as atividades de análise do
processo de desenvolvimento
▪ Entender as técnicas de modelagem OO
(Análise)
▪ Conhecer os fundamentos essenciais da UML
2
OBJETIVOS DA AULA
• Estudar, entender e modelar o problema
• Modelar = criar modelos para apresentar 
os requisitos
–Modelos= abstração da realidade
–Exemplos: maquetes, protótipos
• Independe de tecnologia
• Estrutural
• Comportamental
3
FASE: ANÁLISE
TÉCNICAS DE ANÁLISE
• Estruturada / Essencial (obsoleta)
–Eventos que afeta o sistema → funções
–Foco: funcional
–3 visões: funções, dados e controle
–Sistema = conjunto de processos
• Orientada a objeto (atual)
–O mundo é composto por objetos
4
• ESTRUTURADO / ESSENCIAL
–Sistema = Módulos que interagem
–2 perspectivas isoladas: dados e funções
• ORIENTADO A OBJETO
–Sistema = objetos que interagem
–Única perspectiva integrada: atributos e
métodos
• MOTIVAÇÃO
–Objetos existem antes de existir
aplicações dele no negócio.
5
MUDANÇA DE ENFOQUE
Sistema
Módulo Módulo Módulo
Objeto
Objeto
Objeto
Objeto
Módulo Classe
Procedimento
Dados
Atributos
Métodos
6
MUDANÇA DE ENFOQUE
Atributos
Método Método
Método Método
7
ENCAPSULAR = ESCONDER
OBJETOS E CLASSES 
▪Objeto: Dados + Funções
▪Encapsulamento
▪Classe = Objetos com as mesmas
características
▪Análise O.O = modelar o problema
usando o conceito de objeto/classe.
8
FUNCIONAMENTO O.O
▪Objetos trocam mensagens
▪Métodos=serviços que a classe
presta
▪ Interação = como as mensagens
trafegarão para a execução de uma
tarefa.
9
UML
▪Unified Modeling Language
▪Linguagem de modelagem unificada,
utilizada em engenharia de software
▪Não é uma metodologia.
▪NÃO diz para você o que fazer
primeiro e em seguida ou como
projetar seu sistema
▪Compreende uma série de diagramas
10
DIAGRAMAS UML
11
Diagrama de Casos de Uso
12
12
AULA 1 – Prof. MARCELO VASQUES
• Declaração textual do procedimento 
correspondente ao caso de uso.
• Passo a passo para realização do caso de 
uso
• Mostra a interação do usuário com o 
sistema.
• Detalha o requisito
• Complementa o diagrama.
• FUNDAMENTAL.
Especificação Casos de Uso
Diagrama de Casos de Uso
14
14
Atendente
Emprestar
FITA
Pesquisar
SÓCIO
Selecionar
FITA
<Uses>
<Uses>
AULA 1 – Prof. MARCELO VASQUES
Especificação Casos de Uso
Definição do Casode uso : Emprestar Fita
Roteiro do Caso – Fluxo Principal
1. Atendente informa identificação do Sócio ao Sistema
2. Executar caso de uso “Pesquisar Sócio”
3. Para cada fita a ser emprestada
1. Atendente informa fita
2. Executar caso de uso “Pesquisar Fita”
4. Atendente confirma os dados 
5. sistema registra os empréstimos.
Fluxos Alternativos
2a. – Cliente não cadastrado. Sistema exibe esta msg e encerra o caso
2b. - Cliente está em Débito. Sistema exibe esta mensagem e encerra
caso.
3a. Fita não está cadastrada. Sistema exibe msg e encerra o caso
DIAG CLASSES-Conceitual
16
DIAG CLASSES-Especificação
17
DIAG CLASSES-Implementação
18
DIAGRAMA DE SEQUENCIA
: TelaSaque
Correntista
senha
C1: ContaCorrente
validarSenha(senha)
saque
verificarSaldo()
bloquearValor(saque)
debitarValor(saque)
aviso de liberação
L1: Lancamento
efetuarLancamento(C1)
efetuarLancamento(C1)
19
TRIPÉ DA ANÁLISE
Diagrama de Casos de Uso Diagrama de Classe
Diagrama de Seqüência
20
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
AULA 4
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
OBJETIVOS DA AULA
▪ Conhecer as atividades de desenho ou 
arquitetura do sotfware dentro do processo 
de desenvolvimento
▪ Entender a necessidade de desenhar a 
solução analisando os requisitos e soluções 
da fase de Análise
▪ Apresentar as diferentes visões a serem 
consideradas na fase de desenho ou projeto 
do software
• Fase: Desenho ou Design ou Projeto
– Atenção aos requisitos → via modelos de 
análise
– COMO a solução deve ser implementada
– COMO FAZER – detalhes de funcionamento 
interno. 
• Fase que antecedeu o Projeto
– Análise (O QUE Fazer)
– Usar os modelos da analise (casos de uso, 
classe e sequência, no caso de análise OO 
usando UML)
DESENHO DO SOFTWARE
CONTEXTO
• Aumento do tamanho e da
complexidade do software
• Pressão para: Redução do tempo e
custo
–Desenvolvimento
–Manutenção
• Apelo ao Software green – TI verde
VISÕES DO PROJETO
• EXTERNA
–Visão do usuário
–Modelo de interação → interface
• INTERNA
–Componentes do sistema
–Relação entre os componentes
(acoplamento)
–Funcionamento do componente
– Interconexões com outros sistemas
NÍVEIS DE DESENHO
• ESTRATÉGICO
–Modelo da Arquitetura. Forma do sistema.
Partes e relacionamentos. Sistemas e
sub-sistemas.
• TÁTICO OU DESENHO LÓGICO
–Decisões tomadas no nível estratégico
–Reutilização ou não de componentes
• OPERACIONAL OU DESENHO
DETALHADO
• Comportamento do componente
ARQUITETURA do SW
▪1. Estruturação do sistema
▪Estruturado em subsistemas
▪Subsistema=unidade independente
▪Comunicação entre subsistemas
▪2. Modelagem de controle
▪Modelo de relacionamento entre as
partes de um sistema
▪3. Decomposição modular
▪Cada subsistema é divido em
módulos
DECOMPOSIÇÃO EM MÓDULOS
▪Modelo orientado a objetos
▪Diagrama de classes
▪Diagrama de componente
▪Interação
▪Diagrama de sequencia.
▪Diagrama de Atividade
DIAG CLASSES-Implementação
9
DIAGRAMA DE 
COMPONENTES
▪Mostra os módulos do sistema
▪Esta relacionado a LP a usar
▪Determina como os componentes
irão interagir.
▪Um componente representa um
empacotamento físico de elementos
relacionados logicamente
(normalmente classes
DIAGRAMA DE 
COMPONENTES
DIAGRAMA DE 
COMPONENTES
META: REUTILIZAÇÃO
▪Idéia: usar o que já existe
▪Visa redução de tempo e R$
▪Garante a segurança: componente
usado e testado
NÍVEIS DE REUTILIZAÇÃO 
DEMAIS ATIVIDADES
▪Definições
▪Interface com usuário
▪Arquitetura de hardware e SO.
▪Linguagem de programação
▪Estrutura de rede e comunicações
▪SGBD – banco de dados
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
3
AS FASES DO PROCESSO 
Requisitos
Testes Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
4
O CICLO DE VIDA
Requisitos
Testes
Desenho
Implementação
Análise 
Concepção
• Onde estão os erros?
Manutenção
Implantação
• 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 relegada a 
segundo plano ou mesmo esquecida →
Incremento na QUALIDADE, na medida 
em que avaliamos sob várias óticas.
5
1ª. DEFINIÇÃO DE TESTE
6
1ª. DEFINIÇÃO DE TESTE
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
9
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 
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
12
ESTRATÉGIAS DE TESTES
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ódigo Fonte
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(até o final), 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
17
CASCATA 
C/RETROALIMENTAÇÃO
• Vantagem
–Possibilita a correção de erros
nas fase(s) anterior(es), durante o
processo de desenvolvimento.
–Prevê manutenção
18
CASCATA 
C/RETROALIMENTAÇÃO
• Desvantagem
–Dependendo da quantidade de
revisões e realimentações, o
processo pode se tornar difícil
de gerenciar.
19
19
CASCATA 
C/RETROALIMENTAÇÃO
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(em cada porçã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(porção) forem 
completos, o desenvolvimento segue para a 
próxima iteração(próximo pedaç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
http://wapedia.mobi/pt/Requisitos_de_Software
http://wapedia.mobi/pt/Vers%C3%A3o
http://wapedia.mobi/pt/Funcionalidade
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 um processo 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(formal) 
baseado em UML
2
AULA 1 – Prof. MARCELO VASQUES
CONTEXTO:ESTADO DA ARTE
3
❑ 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
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
◼ (auto-regulamentação da equipe)
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
http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental
http://pt.wikipedia.org/wiki/Gerenciamento_de_projetos
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
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(grandes empresas)
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 - PMBok PMI - (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 AV1 – Aulas 1 a 5
Prof. MARCELO VASQUES
mvasqueso@gmail.com
1
▪ Revisar os conceitos das aulas
▪ 1: Conceitos, Ciclo de Vida e Processo de 
desenvolvimento de SW
▪ 2: Viabilidade, Levantamento de Requisitos
▪ 3: Fase de Análise: conceitos e modelos
▪ 4. Fase de Desenho (projeto): conceitos e 
modelos
▪ 5. Fase de Testes: conceitos e tipos
OBJETIVOS DA AULA
2
1) Analise as assertivas abaixo
I – Dados são um fato isolado, sem significado em si (V)
II – Informação é o resultado do processamento de dados (V)
III – Dado e informação são conceitos distintos e 
relacionados(V) 
IV – Pode-se ter informação de um e apenas um dado(F)
a. Estão corretas as assertivas I, II, III e IV
b. Estão corretas as assertivas II e III
c. Estão corretas I e II e III
d. Estão corretas I, III e IV
3
AULA 1
2) Considere o seguinte contexto. Num sistema de controle de 
estoque, tem-se as seguintes movimentações de um produto:
• Saldo inicial: 20 unidades
• Vendas de 30 unidades
• Compra de 20 unidades
Assinale a opção correta
a. Os dados de compra e venda são informações.(F)
b. O saldo inicial é uma informação, não é um dado. (F)
c. O saldo atual (10) é obtido com saldo inicial + compras –
vendas e é uma informação que pode ser obtida(V)
d. O saldo inicial(dado) e atual(informação) são as duas 
informações(erro) que podem ser obtidas do contexto 
apresentado (F)
4
AULA 1
3) Assinale a opção que não representa um sistema
a. Corpo humano
b. Chuveiro elétrico
c. Chave de porta
d. Sistema de numeração
4) Um conjunto de elementos, independentes que coleta, 
manipula e gera informações úteis é o conceito de:
a) Informação
b) Sistema
c) Sistema de informação
d) Sistema de Processamento de elementos
5
AULA 1
5) Com relação a Sistema de Informação, analise as assertivas
I. Só pode ser baseado em computador (F)
II. Pode ser manual e baseado em computador (V)
III. Hardware, software, bancos de dados, pessoas e 
procedimentos são elementos dos sistemas de informação 
baseados em computador(V)
IV. O Valor de um SI depende apenas das pessoas(F)
Com base em sua análise, assinale a alternativa correta
a. Estão corretas as assertivas II e III 
b. Estão corretas as assertivas II, III e IV
c. Estão corretas as assertivas I, III e IV
d. Estão corretas as assertivas I e III
6
AULA 1
6) Assinale a opção que NÃO representa uma possível causa 
de problemas com sistema de informação.
a) Má qualificação das pessoas que operam o sistema
b) Processos da empresa mal definidos
c) Tecnologia inadequada
d) Simplicidade dos sistemas nos dias de hoje.
7) Com relação aos processos de fabricação do HW (hardware) 
e do SW (software), assinale a opção correta
a) O processo do HW é manufaturado e do SW é fabricado em 
escala.
b) Os defeitos no HW acontecem no inicio e fim de suas vidas 
e o do SW na medida em que sofre alterações
c) O processo do SW e HW usam componentes padrões
d) Não há diferenças entre os processos de desenvolvimento 
do HW e do SW 7
AULA 1
8) Analise as assertivas abaixo e assinale a opção correta no 
que se refere ao processo de desenvolvimento de Software
I. O desenvolvimento de SW depende muito pouco do 
componente humano e muito da tecnologia.(F)
II. O processo de desenvolvimento de SW é muito pouco 
automatizado(V)
III. Existe forte pressão dos usuários para desenvolvimento 
rápido e de baixo custo.(V)
IV. Os projetos de SW geralmente encerram no prazo e custo 
planejados(F)
Com base em sua análise, assinale a assertiva correta
a. Estão corretas as opções I, II e III
b. Estão corretas as opções II, III e IV
c. Estão corretas as opções II e III
d. Estão corretas as opções III e IV
8
AULA 1
9) Com relação ao ciclo de vida de um Sistema, assinale a 
opção incorreta:
a. Começa pela percepção de uma necessidade
b. Termina quando torna-se obsoleto, por exemplo
c. É desenvolvido e entra em operação
d. Inicia-se a manutenção “eterna”
10) Para cada assertiva abaixo, diga se V (verdade) ou F (falsa)
a. O processo de desenvolvimento é uma forma ordenada e 
sistemática de desenvolver software.(V)
b. O processo de desenvolvimento é divido em fases.(V)
c. Em cada fase do processo, se conhece mais do sistema(V)
d. Todas as empresas tem que ter as mesmas fases no 
processo de desenvolvimento de software(F)
e. Todo sistema é viável de ser desenvolvido(F)
9
AULA 1
9) Associe as 2 colunas
I. Escopo (C) a. Necessidade do usuário
II. Requisito (a) b. Sistema atual
III. Técnica de levantamento c. Abrangência do sistema
de requisitos (d) d. Entrevista
IV Alta complexidade
I – c; II – a; III – d; IV – b
10) Por que a fase de levantamento de requisitos é fundamental 
para o processo como um todo?
Resp: porque é nessa fase que vamos conhecer as 
necessidades dos usuários e consequentemente o que o 
sistema precisa fazer (requisitos)
10
AULA 1
11) Cite consequências de um levantamento de dados mal feito.
Resp: a) Má definição do escopo, ou seja sistema não fará o 
que se deseja que ele faça
b) Haverá mudança nos requisitos incialmente identificados, 
gerando retrabalho, alteração de cronograma e orçamento
c) A equipe fica desmotivada com o retrabalho e cai a 
produtividade
d) O cliente fica insatisfeito
e) O sistema não terá qualidade, pois atender ao que os 
usuários desejam é o primeiro critério de qualidade.
12) Por que o processo de desenvolvimento de software deve 
ter qualidade?
Resp: por que a qualidade do software é influenciada pela 
qualidade no processo de desenvolvimento do software
11
AULA 1
13) Marque as opções que representam ações que 
incrementam qualidadeno processo de desenvolvimento
a. Planejamento ( V )
b. Análise de riscos ( V )
c. Acompanhamento e controle do projeto ( V )
d. Correção rápida de problemas ( V )
14) Explique a dificuldade em desenvolver software hoje.
Resp: O software atual é complexo e grande, demandando 
muito tempo e grandes e especializadas equipes de 
profissionais, o que é difícil de administrar e bastante caro. Ou 
seja a gestão fica mais complexa. Não existe ferramenta única 
de automação total do processo de desenvolvimento.
12
AULA 1
15) Dentre as vantagens em se usar claros processos de 
desenvolvimento de sw, destacam-se:
a. Facilitam o processo de desenvolvimento na medida em que 
mais detalhes do sistema são conhecidos a medida em que 
se avança no trabalho.
b. Cria um padrão, para todos seguirem, na tentativa de 
redução a subjetividade no processo de desenvolvimento
c. Confere qualidade ao software
13
AULA 1
14
Aula 1
Requisitos
Testes Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
15
AULA 2
Requisitos
Testes
DesenhoImplementação
Análise 
Manutenção
Implantação
Concepção
• Análise de Viabilidade
• Técnica
• Operacional
• Econômica
• Cronograma
1) Com relação a fase de concepção, do processo de 
desenvolvimento de software, analise as assertivas abaixo
I. É a fase inicial, onde como diz o nome surge a idéia ou a 
necessidade para desenvolver o sistema.(V)
II. É a fase onde todos os requisitos são levantados (F)
III. É feito um estudo de viabilidade, pondendo o sistema nem 
ser desenvolvido (V)
IV. Poderia não existir e passar direto a fase de análise.(F)
Com base nas análise das assertivas assinale a opção correta.
a. Estão corretas as assertivas I e II
b. Estão corretas as assertivas II e III
c. Estão corretas as assertivas I e III
D Estão corretas as assertivas I, II e III
16
AULA 2
1) Assinale a alternativa correta com relação Análise de 
Viabilidade
I. Viabilidade operacional (d) a. Restrições de custo são atendias?
II. Viabilidade econômica (a) b. Restrições de prazo serão atendidas?
III. Viabilidade técnica (c) c. Existe tecnologia factível?
IV. Cronograma (b) d. Beneficia os interessados?
I – d; II – a; III – c; IV – b
2) Com relação ao ROI (Retorno sobre o investimento), assinale 
a alternativa Incorreta
a. % que mede a relação entre o quanto vai ser lucrado 
(receita menos despesa) e quanto se investe (V)
b. Permite avaliar também o tempo de retorno do investimento 
(V)
c. Quanto maior o valor, menor o ROI
d. O conceito de investimento engloba tudo que será gasto 
para desenvolver o sistema (V) 17
AULA 2
18
AULA 3
Requisitos
Testes
DesenhoImplementação
Análise 
Manutenção
Implantação
Concepção
• Necessidades dos usuários
• Restrições
• Funcionamento dos processos
3) Com relação aos conceitos de requisitos, assinale a 
alternativa incorreta
a. Refletem as necessidades de seus usuários.
b. Descrevem que funcionalidades o sistema terá
c. Revelam restrições e características das funcionalidades 
que o sistema fará.
d. Todos os requisitos são funcionais.
4) Classifique os requisitos abaixo em F (funcionais) e NF (não 
funcionais)
a. O sistema deve emitir o fluxo de caixa diariamente ( F )
b. O sistema deve permitir cadastrar todas as despesas. ( F )
c. O tempo de resposta da consulta deve ser inferior a 10s(NF)
d. O produto deve ter um código de barras EAN-13(NF)
19
AULA 3
4) Com relação aos chamados requisitos de usuários, diga se 
cada assertiva é V (verdadeira) ou F (falsa)
a. Descreve requisitos funcionais e não funcionais.(V)
b. Descreve os requisitos de forma detalhada (F)
c. Devem especificar o comportamento externo do sistema (V)
d. Exemplo: O sistema devem manter registro de todos os 
pagamentos.(V)
5) Com relação aos chamados requisitos de sistema, diga se 
cada assertiva é V (verdadeira) ou F (falsa)
a. São versões detalhadas dos requisitos de 
sistemas(usuário)(F)
b. Explicitam detalhes e mostram como os requisitos de 
sistema(usuário) devem ser atendidos pelo sistema.(F)
c. Escrito para clientes(a equipe de desenvolvimento)(F)
20
AULA 3
6) Com relação a técnica de entrevista analise as assertivas 
abaixo.
I. Deve ser usada na reuniões iniciais com o alto escalão (V)
II. Deve conter, preferencialmente, perguntas abertas(F)
III. É eficiente quando feita com maior número de pessoas.(F)
IV. Uma desvantagem é a possibilidade do entrevistador se 
perder ou ser persuadido pelo entrevistado.(V)
Assinale a opção correta
a. Estão corretas as assertivas I , II e IV
b. Estão corretas as assertivas I, III e IV
c. Estão corretas as assertivas II, e IV
d. Estão corretas as assertivas I e IV
21
AULA 3
7) Com relação a técnica de questionário, assinale a opção 
INcorreta
a. Deve ser usada quando a quantidade de usuários for grande
b. Focar em perguntas fechadas
c. Usada quando os usuários estão geograficamente distantes.
d. A vantagem é que o entrevistado tem todo o tempo que 
desejar (nunca deixar o usuario livre com tempo)
8) Com relação a técnica de Brainstorm, assinale cada opção 
como V (verdade) ou F (falsa).
a. Prevalecem as decisões consenso no grupo (V) 
b. Possibilita ouvir a todos, que devem se expressar.(V)
c. Possibilidade de identificar conflito entre as áreas;(V)
d. Poucos devem participar.(F)
22
AULA 3
9) Com relação ao caso de uso (diagrama e especificação), 
está incorreta a opção:
a. Útil para validar os requisitos junto aos usuários.
b. O diagrama de casos de uso mostra os requisitos de usuário
c. A especificação dos casos de uso explicitam os requisitos de 
sistema
d. É a mais eficiente das técnicas de levantamento de dados
10. Relacione as 2 colunas
I. Observação “in locco” a. útil para discussão entre 
áreas
II. JAD b. Entender um relatório
III. Análise de documentos c. Entender o dia a dia
23
AULA 3
9) Com relação ao caso de uso (diagrama e especificação), 
está incorreta a opção:
a. Útil para validar os requisitos junto aos usuários.
b. O diagrama de casos de uso mostra os requisitos de usuário
c. A especificação dos casos de uso explicitam os requisitos de 
sistema
d. É a mais eficiente das técnicas de levantamento de dados
10. Relacione as 2 colunas
I. Observação “in locco” (C) a. útil para discussão entre 
áreas
II. JAD (A) b. Entender um relatório
III. Análise de documentos (b) c. Entender o dia a dia
24
AULA 2
25
AULA 4
Requisitos
Testes
DesenhoImplementação
Análise 
Manutenção
Implantação
Concepção
• Modelagem da solução
• Modelagem dos processos
• O que o sistema deve fazer
1) Com relação a fase de Análise, dentro do processo de 
desenvolvimento de software, analise as assertivas abaixo
I. Visa estudar e entender os requisitos do sistema.(V)
II. Usa modelos para mapear os requisitos, facilitando o 
entendimento.(V)
III. Depende da tecnologia(F)
IV. Mostra apenas a estrutura do sistema(F)
Analise as alternativas e assinale a resposta correta
a. Estão corretas as assertivas I e III
b. Estão corretas as assertivas II e III
c,. Estão corretas as assertivas II e IV
d. Estão corretas as assertivas I e II
26
AULA 4
2) Com relação a técnica de analise essencial, assinale a opção 
falsa
a. O sistema é visto sob 2 perspectivas isoladas: dados e 
controles
b. O foco principal é analise funcional
c. O sistema é dividido em módulos
d. As funções são descobertas ao identificarmos os eventos 
que afetam o sistema
3) Com relação a técnica OO de análise, assinale a alternativa 
correta
a. Os dados e funções passam ser integrados num único 
elemento chamado de objeto.
b. Objeto é um conjunto de classes com as mesmas 
características. 
c. Os atributos encapsulam os métodos dos objetos
27
AULA 4
AULA 4
28
AULA 4
Diagrama de Casos de Uso Diagrama de Classe
Diagrama de Seqüência
29
AULA 4
30
30
AULA 3
31
31
Atendente
Emprestar
FITA
Pesquisar
SÓCIO
Selecionar
FITA
<Uses>
<Uses>
AULA 4
Definição do Casode uso : Emprestar Fita
Roteiro do Caso – Fluxo Principal
1. Atendente informa identificação do Sócio ao Sistema
2. Executar caso de uso “Pesquisar Sócio”
3. Para cada fita a ser emprestada
1. Atendente informa fita
2. Executar caso de uso “Pesquisar Fita”
4. Atendente confirma os dados 
5. sistema registra os empréstimos.
Fluxos Alternativos
2a. – Cliente não cadastrado. Sistema exibe esta msg e encerra o caso
2b. - Cliente está em Débito. Sistema exibe esta mensagem e encerra
caso.
3a. Fita não está cadastrada. Sistema exibe msg e encerra o caso
AULA 4
33
TIPOS
• CONCEITUAL
• ESPECIFICAÇÃO
• IMPLEMENTAÃO
AULA 4
: TelaSaque
Correntista
senha
C1: ContaCorrente
validarSenha(senha)
saque
verificarSaldo()
bloquearValor(saque)
debitarValor(saque)
aviso de liberação
L1: Lancamento
efetuarLancamento(C1)
efetuarLancamento(C1)
34
35
AULA 5
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção Implantação
Concepção
• Tecnologia
• Arquitetura do SW
• COMO o sistema deve fazer
AULA 5
• EXTERNA
– Visão do usuário
– Modelo de interação → interface
• INTERNA
– Componentes do sistema
– Relação entre os componentes
(acoplamento)
– Funcionamento do componente
– Interconexões com outros sistemas
AULA 5
AULA 4
▪REUTILIZAÇÃO
▪Idéia: usar o que já existe
▪Visa redução de tempo e R$
▪Garante a segurança: componente
usado e testado
▪Desenho
▪Classe
▪Código
39
AULA 5
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção Implantação
Concepção
• Unidade 
• Integração
• Validação
• Homologação
MODALIDADES DE TESTES
40
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 
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 não
II. As empresas precisam seguir padrões para programar sim
III. As instruções do programa na LP constituem o código fonte 
sim
IV. O Código de maquina resulta da compilação do código fonte 
não
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 4
AULA 6
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 falso.
II. A linguagem assembly dificultou a vida do programador, 
pois é mais complexa que a linguagem de máquina falso
III. Um programa em linguagem de alto nível tem menos 
instruções que o mesmo programa em linguagem de 
máquina certo
IV. O Montador converte linguagem assembly em linguagem de 
máquina certo
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
5
AULA 6
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(elemento transforma assembler em 
maquina)
b) Montador e tradutor
c) Compilador e interpretador
d) Interpretador e link-editor
6
AULA 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 ___I___
b) Traduz o código e depois o executa ____C___
c) Param quando encontram um erro, na execução ___I___
d) Tem desempenho menor que o outro processo ___I___
e) Faz otimização no código fonte ___C___
5) Como se chama o programa que converte código assembly
em código de máquina R: __MONTADOR______________
6) Como se chama o programa que converte vários códigos 
objetos (maquina) em um executável: R: __LINK EDITOR___
7
AULA 6
8
AULA 6
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.
9
AULA 6
10
AULA 6
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 (V)
b) Ganha-se em agilidade com uso de componentes(V)
c) O custo aumenta com uso de componentes(F)
d) Aumenta a segurança com o uso de componentes.(V)
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.
11
AULA 6
Aula 7: Suporte e 
Manutenção
12
AULA 7
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.(V)
b) Termina quando instala-se a 1ª. Versão de correção 
c) O custo da manutenção historicamente tem sido alto(V)
d) O Ciclo de vida do sistema inclui a manutenção, além do 
seu ciclo de desenvolvimento (V) 
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..(F)
b) Quanto mais qualidade houver no desenvolvimento, mais 
qualidade tende a ter a manutenção(V)
c) O grande desafio da manutenção é manter a documentação 
atualizada(V)
13
AULA 7
3) Com relação a fase de manutenção, analise as assertivas
I. A fase de manutenção só cuida de erros (F)
II. O sistema so possui a fase de manutenção quando tiver 
novas implementações a serem desenvolvidas (F)
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.
14
AULA 7
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ó (F)(alterar parte do sistema e mexe em outra)
b) Arquitetura flexível. 
c) Comportamento linear
d) Refatoração (V)
5) Dentre as opções abaixo, qual não afeta o custo de 
manutenção de um sistema
a) Rotatividade e disponibilidade de pessoal. (afeta o custo) 
b) Linguagem de programação que poucos conhecem (afeta)
c) Qualidade do projeto e de sua documentação (afeta)
d) Ambiente do sistema, que não se modifica. Não afeta o 
custo
15
AULA7
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
O bom é baixo acoplamento e alta coesão
7) Como as demandas de manutenção devem ser tratadas?
a) Tratar cada demanda imediatamente após seu relato (F)
b) Tratar as demandas como um projeto 
c) Tratar as demandas sempre uma vez ao mês (F)
d) Tratar apenas as demandas de novas implementações.(F)
16
AULA 7
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 (F)
II. Intervenções causam instabilidade no ambiente (V)
III. Intervenções devem acontecer de forma controlada (V)
IV. As demandas de manutenção devem ser acumuladas até 
que justifiquem uma intervenção (V)
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
17
AULA 7
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. (V)
b) Partia-se direto para desenvolver o código em linguagem de 
programação (V)
c) Haviam testes de qualidade desde sempre(F)
d) Não havia procedimento claramente definido.(V)
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(F) é desenvolvimento + 
manutenção.
b) É o período que vai da concepção a “morte” do sistema(F) é 
o ciclo de vida
c) É o período que inicia com a concepção e termina com a 
implantação do sistema (V)
d) Inclui a fase de manutenção(F) não inclui a fase de 
18
AULA 8
11) Com relação ao modelo em Cascata Clássico, analise as 
assertivas abaixo
I. Tipicamente linear, ou seja sequencial e para frente. (V)
II. Demandava “congelamento” dos requisitos levantados, sem 
possibilitar novos ou alterações dos iniciais. (V)
III. Sem padronização e documentação eficiente (V)
IV. Usuário recebe parte do sistema, de tempos em tempos (F) 
recebia o sistema todo no final
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
19
AULA 8
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.(V)
II. O retrocesso no processo com retroalimentação só 
acontecia até a fase anterior. (F)
III. Não prevê manutenção(F)
IV. Facilmente gerenciável, mesmo com os retrocessos a fases 
anteriores.(F)
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
20
AULA 8
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) (V)
b) Os modelos de processo em cascata não pressupõem o 
desenvolvimento de todo o sistema, em cada fase. (F)
c) No processo iterativo o sistema é dividido em várias 
porções (iterações) (V)
d) No processo incremental a cada iteração o sistema sofre 
acréscimo de tamanho , até que fique pronto.(V)
21
AULA 9
14) Sobre o modelo iterativo-incremental, diga se V ou F
a) Usa o modelo em cascata para desenvolver cada iteração. 
(V)
b) Uma iteração deve começar definindo um conjunto de 
requisitos do software e termina com sua implantação(V)
c) O usuário só faz contato com o sistema após a última 
iteração estar pronta(F)faz contato a cada iteração
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.(F)
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 22
AULA 9
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
23
AULA 9
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. (V)
b) O produto final é ultimo protótipo gerado. (F)
c) Pode-se usar protótipos em papel, para que aconteça o 
mais cedo possível.(V)
d) É do tipo iterativo-incremental.(V)
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.
24
AULA 9
25
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.
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(V)
b) Menos documentação abrangente e mais software em 
funcionamento(V)
c) Mais colaboração com cliente do que negociação de 
contratos.(V)
d) Mais seguir um plano do que responder a mudanças (F)
26
AULA 10
20) Com relação aos métodos XP e Scrum, representantes dos 
processos de desenvolvimento ágeis, associe as 2 colunas.
I. ( d) Iteração no Scrum a. Feedback
II ( c) Sprint backlog b. Dividem o código a 
implementar
III ( a) Um dos valores do XP c. Requisitos a serem 
implementados no Scrum
IV ( b) Programação em par d. Sprint
I-d; II-c; III-a IV-b 
27
AULA 10
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.
28
AULA 10
03/10/12 Visualização de Prov a
1/4https://sia.estacio.br/portal/prt0010a.asp?p1=4262224&p2=12200&p3=1382471
Avaliação On-Line
Avaliação: AV1.2012.3EAD-PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE-CCT0194
Disciplina: CCT0194 - PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Tipo de Avaliação: AV1
Aluno: 201201170541 - MARCO ANTONIO SILVA JORGE
Nota da Prova: 3.5 Nota do Trabalho: 0 Nota da Participação: 1 Total: 4,5
Prova On-Line
Questão: 1 (123006) 
Com relação ao nível de abstração e agregação dos elementos dos sistemas o nível estratégico
é: Pontos