RESUMO- PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE- ESTÁCIO

Prévia do material em texto

22/03/2018
1
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
22/03/2018
2
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
22/03/2018
3
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.
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
22/03/2018
4
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
22/03/2018
5
• Detalhamento do conceito de Requisito
• Análise de Viabilidade do Sistema
• Técnicas de Levantamento de 
Requisitos
25
22/03/2018
1
AULA 1 – Prof. MARCELO VASQUES
PROCESSO DE DESENVOLVIMENTO DE 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
22/03/2018
2
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
22/03/2018
3
• 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
22/03/2018
4
• 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
22/03/2018
1
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
22/03/2018
2
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 dizpara 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
1212
22/03/2018
3
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
1414
Atendente
Emprestar
FITA
Pesquisar
SÓCIO
Selecionar
FITA<Uses>
<Uses>
AULA 1 – Prof. MARCELO VASQUES
Especificação Casos de Uso
Definição do Caso de 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
22/03/2018
4
DIAGRAMA DE SEQUENCIA
19
TRIPÉ DA ANÁLISE
Diagrama de Casos de Uso Diagrama de Classe
Diagrama de Seqüência
20
22/03/2018
1
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
22/03/2018
2
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 aspartes de um sistema
3. Decomposição modular
Cada subsistema é divido emmó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
22/03/2018
3
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
22/03/2018
1
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 rel2gada 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
22/03/2018
2
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 oscomponentes do sistema.
– Validar se estão em conformidade com osrequisitos anteriormente definidos.
– Para uma melhor analise, o teste deve ser feitopor uma equipe independente, diferente daequipe 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
22/03/2018
3
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 deIntegração
 Verificar a compatibilidade da novaunidade com as demais, já prontas.
 Verificar se Juntas e integradas, asunidades funcionam e realizam otrabalho que o sistema precisa.
Cuidado: alteração de componentes.
Geralmente aplica-se estratégia dacaixa preta, testando as interfaces entreas 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óximoda realidade da operação).
Testar: integração com sistemas externos,dispositivos físicos (hw)
Dificuldade: vislumbrar os vários cenários deuso.
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
22/03/2018
1
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çõesgerados através de uma L.P., de forma lógicae estruturada (L.P de alto nível)
• Código Objeto: Resultado da compilação docódigo fonte
• Código de máquina: Sequência binária deinstruções, que são executadas diretamentepor um processador (conjunto específico deinstruções).
– Linguagem de baixo nível
– Utiliza a arquitetura do processador
22/03/2018
2
LINGUAGEM DE MÁQUINA
• O Hardware é composto de componenteseletrônicos, onde passa ou não corrente.
• A ausência ou não de corrente, cria para ohardware uma linguagem de apenas 2sí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 bitsde 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++,
22/03/2018
3
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 emontando uma tabela com estas informações.
• No segundo passo, a "tradução" do código emlinguagem de máquina. Entretanto, a compilaçãodifere da tradução porque ela faz alterações nocódigo, de forma a torná-lo otimizado.
• Enquanto uma linha é sempre uma instrução natradução, x linhas no código terão y linhas decomandos de máquina, de acordo com ocompilador.
• Compiladores modernos conseguem enormesotimizações em certos códigos.
COMPILADOR / HÍBRIDO
AMBIENTES 
DESENVOLVIMENTO
AMBIENTES 
DESENVOLVIMENTO
22/03/2018
4
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. 
22/03/2018
5
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.
22/03/2018
1
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 é instaladono 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
22/03/2018
2
• 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
22/03/2018
3
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.
22/03/2018
4
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
22/03/2018
1
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
22/03/2018
2
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
22/03/2018
3
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” quepermite a realimentação
• Modelo que permite a revisão defases anteriores e a superposiçãoentre as fases.
•Correções que surgirem duranteoutras fases do processo.
• Porem o custo dessa revisão pode seralto, dependendo da fase atual e doquanto 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
22/03/2018
4
• Desvantagem
–Dependendo da quantidade de
revisões e realimentações, o
processo pode se tornar difícil
de gerenciar.
1919
CASCATA 
C/RETROALIMENTAÇÃO
22/03/2018
1
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.
22/03/2018
2
PROCESSO INCREMENTAL
MODELO ITERATIVO E 
INCREMENTAL
• Processo de desenvolvimento de softwareque define:
– um subconjunto de requisitos e
– utiliza o modelo em cascata para suarealizaçã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
22/03/2018
3
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
22/03/2018
4
• 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.
22/03/2018
1
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
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 pessoase não em 
ferramentas
Mudanças nos valores;
6
22/03/2018
2
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
22/03/2018
3
AULA 1 – Prof. MARCELO VASQUES
PRÁTICAS DO MÉTODO XP
13
AULA 1 – Prof. MARCELO VASQUES
MÉTODO SCRUM
O Scrum é um processo dedesenvolvimento iterativo e incrementalpara gerenciamento de projetos edesenvolvimento ágil de software
Uso: trabalhos complexos, onde não háprevisão exata do que se pretendedesenvolver
O projeto é dividido em ciclos (sprints)
O sprint é a iteração, no caso doSCRUM
14
AULA 1 – Prof. MARCELO VASQUES
MÉTODO SCRUM
15
AULA 1 – Prof. MARCELO VASQUES
MODELO SCRUM
 Product Backlog
Lista com Funcionalidades a seremimplementadas.
 Sprint Backlog
Análise dos requisitos para informar equipecomo 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 osprint)
16
AULA 1 – Prof. MARCELO VASQUES
RUP - Rational Unified Process
Processo proprietário de desenvolvimento desoftware, criado pela Rational, que foi adquiridapela 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 econtratos)
Ambiente (servidores, ferramentas, Bds..)
18
22/03/2018
4
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 devida a medida que se desenvolve:FASES E ITERAÇÕES
 Eixo vertical
 Representa as DISCIPLINAS,que agrupam as atividades.
21
	Aula_01
	Aula_02
	Aula_03
	Aula_04
	Aula_05
	Aula_06
	Aula_07
	Aula_08
	Aula_09
	Aula_10