ProcDesSoftware2Periodo

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

A02analiseRequisitos.PNG
A02analiseRequisitosROI.PNG
a02tecnicasElicita��o.PNG
A03AnaliseEstrutural.PNG
A03ObjetoeClasse.PNG
A04Desenho.PNG
A04ModelosDESENHO.PNG
A04ModelosDESENHO2.PNG
A04ProblemaXSolu��o.PNG
A04Reutiliza��o.PNG
A04Reutiliza��o2.PNG
A05Testes.PNG
A05Testes2.PNG
A05Testes3.PNG
A05Testes4.PNG
A06Classifica��odasLinguagens.PNG
A06Defini��es.PNG
A06ImplementacaoSistemadeSoftware.PNG
A07Documenta�aoPROCESSO.PNG
A07Documenta�aoPRODUTO1.PNG
A07Documenta�aoPRODUTO2.PNG
A07Documenta�aoPRODUTO3.PNG
A07Exercicio.PNG
A08Exercicios.PNG
A08modeloCascata1.PNG
A08modeloCascata2.PNG
A08modeloCascata3.PNG
A08modeloCascata4.PNG
A08modeloCascata5.PNG
A08modeloCascata6.PNG
A08modeloinicial.PNG
A09Exercicios.PNG
A09ModeloEspiral.PNG
A09ModeloEspiral2.PNG
A09ModeloEspiral3.PNG
A09ModeloIncremental.PNG
A09ModeloIterativoIncremental.PNG
A09ModeloIterativoIncremental2.PNG
A09ProcessoIterativo.PNG
A10Exercicios.PNG
A10ProcessoDesenvolvimentoAgil.PNG
A10ProcessoDesenvolvimentoAgil2.PNG
A10ProcessoDesenvolvimentoAgil2M�todoXP.PNG
A10ProcessoDesenvolvimentoAgil2M�todoXP2.PNG
A10ProcessoDesenvolvimentoAgilM�todoSCRUM.PNG
A10ProcessoDesenvolvimentoAgilM�todoSCRUM2.PNG
A10ProcessoUnificado.PNG
A10ProcessoUnificado2.PNG
A10ProcessoUnificadoRUP.PNG
A10ProcessoUnificadoRUP2.PNG
Aula Revis�o Av1 (aulas 1 a 5)2.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA Revisão AV1 – Aulas 1 a 5
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
*
*
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)
Estão corretas as assertivas I, II, III e IV
Estão corretas as assertivas II e III
Estão corretas I e II e III
Estão corretas I, III e IV
*
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
Os dados de compra e venda são informações.(F)
O saldo inicial é uma informação, não é um dado. (F)
O saldo atual (10) é obtido com saldo inicial + compras – vendas e é uma informação que pode ser obtida(V)
O saldo inicial(dado) e atual(informação) são as duas informações(erro) que podem ser obtidas do contexto apresentado (F)
*
AULA 1
*
*
3) Assinale a opção que não representa um sistema
Corpo humano
Chuveiro elétrico
Chave de porta
Sistema de numeração
4) Um conjunto de elementos, independentes que coleta, manipula e gera informações úteis é o conceito de:
Informação
Sistema
Sistema de informação
Sistema de Processamento de elementos
*
AULA 1
*
*
5) Com relação a Sistema de Informação, analise as assertivas
Só pode ser baseado em computador (F)
Pode ser manual e baseado em computador (V)
Hardware, software, bancos de dados, pessoas e procedimentos são elementos dos sistemas de informação baseados em computador(V)
O Valor de um SI depende apenas das pessoas(F)
Com base em sua análise, assinale a alternativa correta
Estão corretas as assertivas II e III 
Estão corretas as assertivas II, III e IV
Estão corretas as assertivas I, III e IV
Estão corretas as assertivas I e III
*
AULA 1
*
*
6) Assinale a opção que NÃO representa uma possível causa de problemas com sistema de informação.
Má qualificação das pessoas que operam o sistema
Processos da empresa mal definidos
Tecnologia inadequada
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
O processo do HW é manufaturado e do SW é fabricado em escala.
Os defeitos no HW acontecem no inicio e fim de suas vidas e o do SW na medida em que sofre alterações
O processo do SW e HW usam componentes padrões
Não há diferenças entre os processos de desenvolvimento do HW e do SW
*
AULA 1
*
*
8) Analise as assertivas abaixo e assinale a opção correta no que se refere ao processo de desenvolvimento de Software
O desenvolvimento de SW depende muito pouco do componente humano e muito da tecnologia.(F)
O processo de desenvolvimento de SW é muito pouco automatizado(V)
Existe forte pressão dos usuários para desenvolvimento rápido e de baixo custo.(V)
Os projetos de SW geralmente encerram no prazo e custo planejados(F)
Com base em sua análise, assinale a assertiva correta
Estão corretas as opções I, II e III
Estão corretas as opções II, III e IV
Estão corretas as opções II e III
Estão corretas as opções III e IV
*
AULA 1
*
*
9) Com relação ao ciclo de vida de um Sistema, assinale a opção incorreta:
Começa pela percepção de uma necessidade
Termina quando torna-se obsoleto, por exemplo
É desenvolvido e entra em operação
Inicia-se a manutenção “eterna”
10) Para cada assertiva abaixo, diga se V (verdade) ou F (falsa)
O processo de desenvolvimento é uma forma ordenada e sistemática de desenvolver software.(V)
O processo de desenvolvimento é divido em fases.(V)
Em cada fase do processo, se conhece mais do sistema(V)
Todas as empresas tem que ter as mesmas fases no processo de desenvolvimento de software(F)
Todo sistema é viável de ser desenvolvido(F)
*
AULA 1
*
*
9) Associe as 2 colunas
Escopo	(C) 			a. Necessidade do usuário
Requisito	 (a) 			b. Sistema atual
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)
*
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
*
AULA 1
*
*
13) Marque as opções que representam ações que incrementam qualidade no processo de desenvolvimento
Planejamento ( V )
Análise de riscos ( V )
Acompanhamento e controle do projeto ( V )
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.
*
AULA 1
*
*
15) Dentre as vantagens em se usar claros processos de desenvolvimento de sw,
destacam-se:
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.
Cria um padrão, para todos seguirem, na tentativa de redução a subjetividade no processo de desenvolvimento
Confere qualidade ao software
*
AULA 1
*
*
*
Aula 1
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
*
*
*
AULA 2
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
Análise de Viabilidade
Técnica
Operacional
Econômica
Cronograma
*
*
Com relação a fase de concepção, do processo de desenvolvimento de software, analise as assertivas abaixo
É a fase inicial, onde como diz o nome surge a idéia ou a necessidade para desenvolver o sistema.(V)
É a fase onde todos os requisitos são levantados (F)
É feito um estudo de viabilidade, pondendo o sistema nem ser desenvolvido (V)
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
*
AULA 2
*
*
Assinale a alternativa correta com relação Análise de Viabilidade			
Viabilidade operacional (d) 	a. Restrições de custo são atendias?	
Viabilidade econômica (a)	b. Restrições de prazo serão atendidas?
Viabilidade técnica 	(c) 	c. Existe tecnologia factível?
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
% que mede a relação entre o quanto vai ser lucrado (receita menos despesa) e quanto se investe (V)
Permite avaliar também o tempo de retorno do investimento (V)
Quanto maior o valor, menor o ROI
O conceito de investimento engloba tudo que será gasto para desenvolver o sistema (V)
*
AULA 2
*
*
*
AULA 3
Requisitos
Testes
Desenho
Implementaçã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
Refletem as necessidades de seus usuários.
Descrevem que funcionalidades o sistema terá
Revelam restrições e características das funcionalidades que o sistema fará.
Todos os requisitos são funcionais.
4) Classifique os requisitos abaixo em F (funcionais) e NF (não funcionais)
O sistema deve emitir o fluxo de caixa diariamente ( F )
O sistema deve permitir cadastrar todas as despesas. ( F )
O tempo de resposta da consulta deve ser inferior a 10s(NF)
O produto deve ter um código de barras EAN-13(NF)
*
AULA 3
*
*
4) Com relação aos chamados requisitos de usuários, diga se cada assertiva é V (verdadeira) ou F (falsa)
Descreve requisitos funcionais e não funcionais.(V)
Descreve os requisitos de forma detalhada (F)
Devem especificar o comportamento externo do sistema (V)
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)
São versões detalhadas dos requisitos de sistemas(usuário)(F)
Explicitam detalhes e mostram como os requisitos de sistema(usuário) devem ser atendidos pelo sistema.(F)
Escrito para clientes(a equipe de desenvolvimento)(F)
*
AULA 3
*
*
6) Com relação a técnica de entrevista analise as assertivas abaixo.
Deve ser usada na reuniões iniciais com o alto escalão (V)
Deve conter, preferencialmente, perguntas abertas(F)
É eficiente quando feita com maior número de pessoas.(F)
Uma desvantagem é a possibilidade do entrevistador se perder ou ser persuadido pelo entrevistado.(V)
Assinale a opção correta
Estão corretas as assertivas I , II e IV
Estão corretas as assertivas I, III e IV
Estão corretas as assertivas II, e IV
Estão corretas as assertivas I e IV
*
AULA 3
*
*
7) Com relação a técnica de questionário, assinale a opção INcorreta
Deve ser usada quando a quantidade de usuários for grande
Focar em perguntas fechadas
Usada quando os usuários estão geograficamente distantes.
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).
Prevalecem as decisões consenso no grupo (V) 	
Possibilita ouvir a todos, que devem se expressar.(V)
Possibilidade de identificar conflito entre as áreas;(V)
Poucos devem participar.(F)
*
AULA 3
*
*
9) Com relação ao caso de uso (diagrama e especificação), está incorreta a opção:
Útil para validar os requisitos junto aos usuários.
O diagrama de casos de uso mostra os requisitos de usuário
A especificação dos casos de uso explicitam os requisitos de sistema
É a mais eficiente das técnicas de levantamento de dados
10. Relacione as 2 colunas
Observação “in locco”		a. útil para discussão entre 					áreas	
JAD				b. Entender um relatório
Análise de documentos	c. Entender o dia a dia
*
AULA 3
*
*
9) Com relação ao caso de uso (diagrama e especificação), está incorreta a opção:
Útil para validar os requisitos junto aos usuários.
O diagrama de casos de uso mostra os requisitos de usuário
A especificação dos casos de uso explicitam os requisitos de sistema
É a mais eficiente das técnicas de levantamento de dados
10. Relacione as 2 colunas
Observação “in locco”	(C) 	a. útil para discussão entre 					áreas	
JAD		(A) 		b. Entender um relatório
Análise de documentos (b) 	c. Entender o dia a dia
*
AULA 2
*
*
*
AULA 4
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
Modelagem da solução
Modelagem dos processos
O que o sistema deve fazer
*
*
Com relação a fase de Análise, dentro do processo de desenvolvimento de software, analise as assertivas abaixo
Visa estudar e entender os requisitos do sistema.(V)
Usa modelos para mapear os requisitos, facilitando o entendimento.(V)
Depende da tecnologia(F)
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
*
AULA 4
*
*
2) Com relação a técnica de analise essencial, assinale a opção falsa
O sistema é visto sob 2 perspectivas isoladas: dados e controles
O foco principal é analise funcional
O sistema é dividido em módulos
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
Os dados e funções passam ser integrados num único elemento chamado de objeto.
Objeto é um conjunto de classes com as mesmas características. 
Os atributos encapsulam os métodos dos objetos
*
AULA 4
*
*
AULA 4
*
*
*
AULA 4
Diagrama de Casos de Uso
Diagrama de Classe
Diagrama de Seqüência
*
*
*
AULA 4
*
*
*
*
AULA 3
*
*
<Uses>
<Uses>
*
*
AULA 4
Definição do Caso de uso : Emprestar Fita
 
Roteiro do Caso – Fluxo Principal
Atendente informa identificação do Sócio ao Sistema
Executar caso de uso “Pesquisar Sócio”
Para cada fita a ser emprestada
Atendente informa fita
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
*
TIPOS
CONCEITUAL
ESPECIFICAÇÃO
IMPLEMENTAÃO
*
*
AULA 4
*
*
*
*
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
*
*
*
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
*
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ÓDIGO
TESTES DINÂMICOS
EXECUÇÃO 
*
1. Concepção 2. levantamento de requisitos 3.Análise(estudar o problema), 4. Desenho , 5. implementação, 6. testes, 7. implanto(treinar usuarios),_ciclo de desenvolvimento 8.manutenção_ciclo de vida
*
Tripé da análise
*
Diagrama de sequência
*
*
Modelo de componente
Arquitetura de divisão do sistema
*
*
Aula_01.ppt
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
*
*
*
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
*
*
*
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
*
*
*
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)
*
*
*
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.
*
*
*
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
*
*
*
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.
*
*
*
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
*
*
*
Processo de desenvolvimento do HW é um sucesso. O do SW não. Por que?
SOFTWARE
*
*
*
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
*
*
*
REALIDADE. CRISE DO SW
*
*
*
*
*
*
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.
*
*
*
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?
*
*
*
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.
*
*
*
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
*
*
*
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.
*
*
*
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 
*
*
*
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
*
*
*
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.
*
*
*
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.
*
*
*
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)
*
*
*
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)
*
*
*
 
Detalhamento do conceito de Requisito
Análise de Viabilidade do Sistema
Técnicas de Levantamento de Requisitos
*
*
Aula_02.ppt
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
*
*
*
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
*
*
*
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
*
*
*
ANÁLISE 
DE
VIABILIDADE
Entrada:
Conjunto preliminar de requisitos de negócio
Esboço da Descrição do Software
Como apóia a área de negócios
Saída:
Viável? (técnica, operacional e financeiramente)
ESTUDO DE VIABILIDADE
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
É 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)
*
*
*
*
*
*
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
*
*
*
*
*
Aula_03.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 3
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
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
*
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
*
*
*
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.
*
MUDANÇA DE ENFOQUE
*
*
*
MUDANÇA DE ENFOQUE
*
*
Atributos
Método
Método
Método
Método
*
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.
*
*
*
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.
*
*
*
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
*
*
*
DIAGRAMAS UML
*
*
*
Diagrama de Casos de Uso
*
*
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
*
*
<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
Atendente informa identificação do Sócio ao Sistema
Executar caso de uso “Pesquisar Sócio”
Para cada fita a ser emprestada
Atendente informa fita
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
*
*
*
DIAG CLASSES-Especificação
*
*
*
DIAG CLASSES-Implementação
*
*
*
DIAGRAMA DE SEQUENCIA
*
*
*
TRIPÉ DA ANÁLISE
Diagrama de Casos de Uso
Diagrama de Classe
Diagrama de Seqüência
*
*
*
*
*
Aula_04.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 4
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
*
*
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
*
Modelar o Sistema
*
Através das tecnologias 
*
*
*
*
SGBD - Sistema gerenciador de banco de dados ( já existem orientados a objetos)
*
Aula_05.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 5
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
*
*
*
AS FASES DO PROCESSO 
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção
Implantação
Concepção
*
*
*
O CICLO DE VIDA
*
*
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.
*
1ª. DEFINIÇÃO DE TESTE
*
*
*
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.
*
*
*
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”
*
*
*
MODALIDADES DE TESTES
*
Requisitos
Testes
Desenho
Implementação
Análise
Concepção
Onde estão os erros?
Manutenção
Implantação
TESTES ESTÁTICOS
REVISÕES
AUDITORIAS
TESTES ESTÁTICOS
REVISÃO DE CÓDIGO
TESTES 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
*
*
*
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.
*
*
*
TESTE DA CAIXA BRANCA (+ Complexos)
Baseados na arquitetura interna do software.
Verificação de código 
Objetivo: identificar defeitos nas estruturas internas do sw, através da simulação que “testem” toda a estrutura usada na codificação
Desvantagem: requer conhecimento técnico da tecnologia empregada pelo software e arquitetura interna da solução  requer profissional BEM capacitado.  Difíceis de serem implementados.
Vantagem: eficientes na detecção de erros.
Casos de testes que cubram TODAS possibilidades
*
ESTRATÉGIAS DE TESTES
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
*
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
*
*
Conjunto de FASES que se relacionam
Cada uma no seu contexto
Processo de Movimento 
*
Descobrir erros de programas, antes de implementar o sistema
Testes, avaliações ao longo do processo
*
Sistemas, conjuntos de partes que se relacionam 
Testes de regressão são fundamentais
 
*
Teste = processo definido = organização, disciplina e método 
Teste bom é o que descobriu novos erros
Todos os caminhos(possibilidades) precisam ser testados
*
*
Teste estático, não tem software rodando, é feito na documentação, na modelagem. Comparar as funções no diagrama com o desejo do usuário.
Fazer verificações de consistências 
*
*
Teste de unidade, durante o processo de programação(geralmente é o próprio programador)
*
Caixa preta = só se preocupa com a saída , se gera resultado certo.
*
Analisa o que tem dentro. Testa todas as possibilidades
*
Sempre que alterar um componente testá-lo imediatamente
*
Aula_06.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 6
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
*
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.
*
Na linguagem selecionada pela equipe de programação
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Aula_07.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 7
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
Manutenção não é apenas resolver problemas, 
Fazer bem feito, com agilidade
*
*
*
*
*
*
*
Apóia usabilidade do sistema
*
*
*
A documentação orienta o desenvolvedor
*
*
Toda ajuda no processo acarreta ajuda no programa
*
*
Aula_08.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 8
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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.
*
*
*
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.
*
*
*
MODELOS INICIAIS
Modelo Balburdia
 Base: experiência dos programadores
 2 fases: Implementação & Correção
*
*
*
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.
*
*
*
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
*
*
*
MODELO CASCATA
1º. Modelo em Engenharia de Software
Linear  a atividade é concluída antes de iniciar a próxima.
Sequencial e “para frente”
*
*
*
MODELO CASCATA
*
*
*
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
*
*
*
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
*
*
*
MODELO CASCATA
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção
Implantação
*
*
*
MODELO CASCATA
Requisitos
Testes
Desenho
Implementação
Análise 
 D O C U M E N T A Ç Ã O 
*
*
*
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.
*
*
*
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.
*
*
*
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
*
*
*
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
*
*
*
Requisitos
Testes
Desenho
Implementação
Análise 
Manutenção
Implantação
*
CASCATA C/RETROALIMENTAÇÃO
*
*
Vantagem
Possibilita a correção de erros nas fase(s) anterior(es), durante o processo de desenvolvimento.
Prevê manutenção
*
CASCATA C/RETROALIMENTAÇÃO
*
*
Desvantagem
Dependendo da quantidade de revisões e realimentações, o processo pode se tornar difícil de gerenciar.
*
*
CASCATA C/RETROALIMENTAÇÃO
*
*
Sempre tratar o usuário com muita atenção 
*
*
*
*
*
*
Análise = o Que?; Desenho= como? 
Implantação = Treinamento do usuário
*
Documentação = Alicerce de todo o Processo – Base – Fundamental 
*
*
*
*
*
Quanto antes descobrir um erro mais barato é para reparar
*
*
*
Aula_09.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 9
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
*
*
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
*
*
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
*
*
Iteração=repetição
*
*
*
*
*
*
Cada linha é uma porção – iteração
Iterativo – várias porções 
*
*
*
As coisas vão sendo descobertas
*
*
*
*
O mais grave no sistema são as alterações que ocorrem ao longo
Identificar os riscos que podem ocorrer
*
*
*
*
*
*
Aula_10.ppt
AULA 1 – Prof. MARCELO VASQUES
*
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 10
Prof. MARCELO VASQUES
mvasqueso@gmail.com
*
AULA 1 – Prof. MARCELO VASQUES
*
OBJETIVOS DA AULA
Conhecer os processos de desenvolvimento:
Ágeis – XP e SCRUM
RUP – Processo Unificado(formal) baseado em UML
*
AULA 1 – Prof. MARCELO VASQUES
*
CONTEXTO:ESTADO DA ARTE
*
 Engenharias Tradicionais valorizam o 
Projetar ANTES de Construir
Engenharias Tradicionais não exergam 
o processo de desenvolvimento de SW 
como ele é: Com mudanças sempre
Necessidade: Metodologia que permita
alteração frequente do SW sem afetar sua
qualidade.
Um grupo de desenvolvedores QUER
processo menos burocrático e + prático
AULA 1 – Prof. MARCELO VASQUES
*
ENGENHARIA DE SOFTWARE
*
AULA 1 – Prof. MARCELO VASQUES
*
DESEJO DAS METOD. ÁGEIS
*
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;
*
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 
*
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. 
*
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
*
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
*
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
*
AULA 1 – Prof. MARCELO VASQUES
*
PRÁTICAS DO MÉTODO XP
*
AULA 1 – Prof. MARCELO VASQUES
*
PRÁTICAS DO MÉTODO XP
*
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
*
AULA 1 – Prof. MARCELO VASQUES
*
MÉTODO SCRUM
*
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)
*
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
*
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..)
*
AULA 1 – Prof. MARCELO VASQUES
*
As FASES do RUP
*
AULA 1 – Prof. MARCELO VASQUES
*
RUP
*
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. 
*
*
*
*
*
*
*
*
OO sistemas orientados para objeto
Reutilizar o que já existe pronto
*
Entender o negócio da empresa
*
*
Fases
*
*
ciclosDesenvolvimento.pdf
Prof. Edson dos Santos Cordeiro 1
Tópico: Introdução a Ciclo de Vida do Software 
Objetivo: Conhecer os principais conceitos relacionados a ciclo de vida do software. 
Bibliog. Base: McCONNEL, Steve. Rapid development. Redmond, WA: Microsoft Press, 1996. 
Bibliog. Compl.: Engenharia
de Software. Ian Summerville. Addison- Wesley, 2003. Engenharia de Software. Roger S. Pressman. Makron Books. 
Internet: » http://www.software-engineer.org (Engenharia de Software) » Software Engine Institute (Instituto de Engenharia de Software) 
 
INTRODUÇÃO 
 
 Ciclos de vida do software descrevem como um software deve ser desenvolvido. Basicamente 
definem a ordem global das atividades envolvidas em um contexto de projeto de software e propõe uma 
estratégia de desenvolvimento que pode ser aplicada a um determinado contexto de projeto de software. 
Ciclos de vida normalmente são vagos nas descrições de detalhes das condições de início e término de uma 
atividade, recursos utilizados, artefatos consumidos ou produzidos, papéis desempenhados etc. Dentre os 
diversos ciclos de vida de software, pode-se citar: Code-and-Fix, Cascata, Espiral, Prototipação Evolutiva, 
Prototipação Incremental, Prototipação Descartável, Refinamento Iterativo, Ciclo de Vida Progressivo, 
Desenvolvimento Incremental, Sashimi. 
 
Diferenças entre modelos de ciclo de vida 
 
 Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem 
alguns aspectos que os diferenciam: 
 
• Enfoque dado pelo modelo. Por exemplo, no Modelo Cascata o enfoque é dado na 
documentação e no Modelo Espiral o enfoque é dado nos riscos; 
• Estratégia de desenvolvimento. Define a disposição das atividades que deverão ser 
executadas para atingir um objetivo em um contexto de projeto de desenvolvimento de 
software. A disposição das atividades pode ser, por exemplo, linear (uma atividade após a 
outra) como no ciclo de vida Cascata puro ou iterativa (um conjunto de atividades é 
repetida várias vezes até atingir o seu objetivo) como nos modelos incrementais. Outras 
estratégias podem envolver a disposição das atividades em paralelo, a prototipação ou 
reunir as características de modelos de ciclo de vida lineares e iterativos. 
 
Modelo Cascata Puro 
 
 A proposta do modelo Cascata Puro (Figura 1) consiste na execução das atividades de 
desenvolvimento de software em uma seqüência ordenada. Desta forma, a passagem para determinada 
atividade exige como critério a finalização da atividade imediatamente anterior. As principais atividades 
do modelo são: requisitos de sistema, requisitos de software, análise, projeto de programa, codificação, 
teste e operação. 
 
Requisitos
de sistema
Requisitos
de software
Análise
Projeto do
programa
Implemen-
tação
Teste
Operação
 
Figura 1: Modelo de ciclo de vida Cascata 
Ciclo de Vida do Desenvolvimento de Software 
Prof. Edson dos Santos Cordeiro 2
O modelo Cascata é recomendado para projetos nos quais há domínio dos requisitos do 
sistema que será desenvolvido e quando o pessoal envolvido no projeto é fraco tecnicamente devido a 
baixa complexidade do modelo. Além disso, pode ser empregado para situações nas quais há um bom 
conhecimento do domínio (por exemplo, um bom conhecimento sobre o tipo de software que será 
desenvolvido) e das tecnologias que serão utilizadas para desenvolver o software (por exemplo, métodos, 
técnicas e ferramentas). No entanto, o modelo apresenta algumas desvantagens: 
 
1. Propõe uma seqüência entre etapas que não representa adequadamente um processo de 
desenvolvimento de software; 
2. Não oferece suporte adequado para mudanças que são percebidas durante o processo e 
que requerem modificações em etapas anteriores (flexibilidade); 
3. Não oferece facilidades para acomodar tecnologias recentes como prototipação rápida e, 
4. Fornece poucos recursos para otimização de processo (detalhamento); 
 
Devido a essas desvantagens, a utilização do modelo depende do contexto e pode resultar nas 
seguintes conseqüências: 
 
1. Pode não permitir a visão real do processo em andamento; 
2. O modelo cascata, analogamente, cria dois universos, um universo se refere ao processo 
em andamento e o outro universo se refere às mudanças que deveriam ser aplicadas ao 
produto, mas não as são pelo fato do modelo não incorporar em sua dinâmica a revisão de 
etapas já concluídas durante o seu andamento; 
3. Não é possível mensurar. O fato de normalmente não permitir uma visão real do processo 
também implica em uma visão irreal para a aplicação de métricas. Atividades não 
concluídas são rotuladas como concluídas. 
 
Modelo Espiral 
 
O modelo Espiral (Figura 2), proposto por Barry Boehm, reúne características dos modelos 
Cascata e Prototipação acrescentando ainda em sua base a análise de riscos. Cada giro na espiral 
(iniciando a partir do centro e avançando para fora) representa uma nova fase do processo. Esse processo 
evolutivo permite que novas versões possam ser construídas progressivamente. Tipicamente, o modelo 
pode ser dividido em 3 ou 6 regiões. PRESSMAN (vide referências) apresenta o modelo divido em 6 regiões: 
comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e evolução e, 
avaliação do cliente. O número de tarefas por regiões pode variar conforme o tamanho e complexidade do 
projeto. Desta forma, o modelo pode ser adaptado conforme as características do projeto. 
 
 
Figura 2: Ciclo de Vida Espiral 
Ciclo de Vida do Desenvolvimento de Software 
Prof. Edson dos Santos Cordeiro 3
A adoção do modelo Espiral proporciona algumas vantagens. Teoricamente, quanto mais 
tempo e recursos forem destinados, ou seja, quanto mais iterações na espiral, menor serão os riscos sobre 
o projeto. Outra vantagem em relação a modelos seqüenciais como o modelo Cascata, é a execução de 
atividades de verificação presentes ao final de cada iteração que permitem um melhor controle gerencial 
sobre o projeto. Uma desvantagem do modelo refere-se a situações em que o projeto é considerado 
simples e os riscos são modestos. Nesse contexto, muitos projetos não precisam da flexibilidade e 
gerenciamento de riscos proporcionados pelo modelo. 
 
Prototipação 
 
Organizações de desenvolvimento de software utilizam protótipos na construção de software 
com diferentes propósitos: na construção de modelos, simulações, implementações parciais ou ainda para 
testar aspectos técnicos de um sistema. A prototipação pode ser adotada como uma abordagem que 
compreenda todo o ciclo de vida de desenvolvimento de um software ou como um processo incorporado a 
um ciclo de vida (por exemplo, Modelo Espiral). O processo de prototipação (Figura 3) consiste 
basicamente em diversos ciclos iterativos. Um protótipo é construído a partir de requisitos iniciais. É 
realizada uma avaliação crítica do protótipo a qual considera os requisitos iniciais e requisitos que não 
foram mencionados inicialmente. Caso o protótipo não atenda aos requisitos pretendidos, novas iterações 
são realizadas produzindo novos protótipos. As iterações são finalizadas quando os requisitos forem 
atendidos. 
 
Protótipo inicial
Revisão/refinamento
do protótipo
Revisão do
protótipo
Atendido?Não Sim Objetivosatendidos
 
Figura 3: Processo de Prototipação 
 
Existem diversos modelos de processo de desenvolvimento de software que empregam a 
prototipação em seus processos: Incremental Iterativo, Prototipação Rápida Descartável, Prototipação 
Evolutiva e Espiral. 
 
Prototipação Incremental 
 
A Prototipação Incremental (Figura 4) também conhecida como Entrega por Estágio adota 
como estratégia o desenvolvimento por estágios. Normalmente os requisitos mais importantes são 
implementados primeiro e os demais são acrescentados em novas versões. O desenvolvimento ocorre 
gradualmente e, ao final de cada estágio, uma versão operável é produzida e incrementada nos demais 
estágios até a sua conclusão final. A Prototipação Incremental pode oferecer diversas vantagens: redução 
de riscos, maior visibilidade
sobre o processo, problemas podem ser descobertos logo no início, auxilia na 
estimativa de tempo do projeto entre outras. No entanto, o emprego desse modelo exige grande esforço 
na atualização da documentação do usuário. Além disso, o desenvolvimento por estágio requer que as 
dependências entre os estágios sejam bem planejadas, pois um dos problemas comuns é descobrir que o 
estágio 2 depende de componentes do estágio 4, por exemplo. 
 
Ciclo de Vida do Desenvolvimento de Software 
Prof. Edson dos Santos Cordeiro 4
Concepção do
software
Análise de
requisitos
Projeto
arquitetural
Estágio 1: Projeto detalhado, implementação,
depuração, teste e entrega
Estágio 2: Projeto detalhado, implementação,
depuração, teste e entrega
Estágio 3: Projeto detalhado, implementação,
depuração, teste e entrega 
Figura 4: Modelo Prototipação Incremental 
 
Prototipação Evolutiva 
 
A Prototipação Evolutiva (Figura 5) basicamente inicia com a concepção do sistema e emprega 
diversos ciclos de “re-projeto”, “re-implementação” e “re-avaliação” até a aceitação final do software. 
Cada novo protótipo confirma, refina ou adiciona novos requisitos até atingir a totalidade de requisitos do 
sistema. 
 
Concepção do
software
Projeto e
implementação do
protótipo inicial
Refinamento do
protótipo até sua
aceitação
Conclusão e
entrega do
protótipo
 
Figura 5: Modelo Prototipação Evolutiva 
 
O modelo pode ser adotado em contextos nos quais os requisitos são instáveis ou 
desconhecidos ou, ainda, quando há a necessidade de se testar um algoritmo antes de sua adoção. Dentre 
as vantagens proporcionadas pelo modelo Prototipação Evolutiva, destaca-se menor taxa de defeitos pela 
melhor definição das especificações do sistema, promove maior participação do cliente, permite maior 
visibilidade do progresso de desenvolvimento e é possível verificar a aceitação do sistema nos primeiros 
estágios do desenvolvimento. Por outro lado, o modelo pode agregar algumas desvantagens: pobre 
manutenibilidade provocada pela rapidez no desenvolvimento e/ou constantes mudanças na estrutura do 
protótipo, acréscimo de novas funcionalidades devido ao constante contato do cliente com o protótipo e, 
uso ineficiente do tempo destinado à construção do protótipo. 
Diferentemente da Prototipação Incremental, o protótipo é entregue ao finalizar o 
desenvolvimento. Além disso, a Prototipação Incremental desenvolve partes do software que serão 
entregues à medida que são finalizadas, não ocorrendo mudanças nas especificações do projeto e, a maior 
parte dos requisitos deve ser conhecida logo no início do projeto. 
 
Prototipação Rápida Descartável 
 
O modelo Prototipação Rápida Descartável (Figura 6Figura ) difere dos modelos Incremental e 
Evolutivo pelo fato de descartar o protótipo. No entanto, assemelha-se em alguns aspectos quanto a sua 
estratégia. O modelo inicia com a especificação de requisitos os quais subsidiam a construção de um 
protótipo. O protótipo é avaliado pelo cliente e novas iterações ocorrem até sua aceitação. Antes de ser 
descartado, o protótipo aprovado é utilizado na especificação do sistema e alguns componentes podem ser 
utilizados na “re-implementação” da nova versão final. Após a validação, o software é entregue ao 
cliente. 
Ciclo de Vida do Desenvolvimento de Software 
Prof. Edson dos Santos Cordeiro 5
Especificação
inicial
Construção
protótipo
Avaliação do
protótipo
Desenvolvimento
do software
Entrega do
software
Validação do
sistema
Especificação do
sistema
Componentes
reutilizáveis
 
Figura 6: Modelo Prototipação Rápida Descartável 
 
Dentre os diversos domínios de software, o Modelo Prototipação Rápida Descartável pode ser 
aplicado em: domínios nos quais os requisitos de software são instáveis ou existe a necessidade de 
certificar um conjunto de requisitos ou, ainda, em domínios nos quais os riscos podem prejudicar ou 
inviabilizar o projeto. Redução de riscos, melhor compreensão dos requisitos do sistema e maior 
participação do cliente são algumas das vantagens que podem ser proporcionadas pelo modelo. Porém, 
existem alguns problemas que podem advir da utilização desse modelo: testes insuficientes em requisitos 
importantes (por exemplo, relacionados a segurança e robustez); não implementação de requisitos 
importantes devido à necessidade de implementar rapidamente um protótipo e, utilização do protótipo 
como versão final. 
 
Seleção de modelos de ciclo de vida 
 
A escolha de um modelo de ciclo de vida deve considerar as características do contexto de 
projeto ao qual será aplicado. Diferentes projetos de desenvolvimento possuem diferentes necessidades 
que devem orientar a seleção do ciclo de vida mais adequado. McCONNEL (1996, p. 154), considerando as 
diferenças entre projetos de desenvolvimento, apresenta diversas questões que devem ser respondidas ao 
selecionar um modelo de ciclo de vida: 
 
1. Qual o nível de compreensão do usuário e desenvolvedores em relação aos requisitos no 
início do projeto? É provável que a compreensão mude significativamente durante o 
desenvolvimento do projeto? 
2. Qual o nível de compreensão dos desenvolvedores em relação a arquitetura do sistema? É 
provável que mudanças na arquitetura do sistema ocorram no meio do caminho? 
3. Qual nível de confiança é necessário? 
4. O quanto é necessário planejar e projetar durante o projeto prevendo mudanças em 
versões futuras? 
5. Qual o nível de riscos implícitos no projeto? 
6. Pode ser limitado em um cronograma? 
7. É necessário habilidade para realizar correções no meio do projeto? 
8. É necessário mostrar ao cliente o progresso durante o projeto? 
9. É necessário demonstrar ao usuário aspetos gerenciais durante o projeto? 
 
Para auxiliar na resposta a essas questões, McConnel apresenta uma tabela na qual são 
apresentadas as vantagens e desvantagens de diversos modelos de ciclo de vida em relação às questões 
apresentadas acima. Outras questões foram incluídas e possuem igual importância na escolha de um 
modelo de ciclo de vida para o projeto. O Quadro 1 apresentado nesse material não inclui todos os 
modelos de ciclo de vida abordados por McConnel. McConnel utiliza uma escala para classificar os modelos 
que varia entre “deficiente”, “bom” e “excelente”. Em alguns casos, o autor refina a classificação 
utilizando mais de um valor, por exemplo “bom para excelente”. Deve-se ressaltar ainda que, a seleção 
não se restringe somente pela consideração das vantagens oferecidas pelo modelo de ciclo de vida frente 
a um contexto de projeto de software, devem ser considerados outros aspectos como, por exemplo, a 
maneira como o ciclo de vida será aplicado. 
 
 
 
 
 
 
 
 
Ciclo de Vida do Desenvolvimento de Software 
Prof. Edson dos Santos Cordeiro 6
Quadro 1: Modelos de ciclo de vida (vantagens e desvantagens) 
Capacidade do modelo Cascata Puro Espiral Prototipação Evolutiva 
Prototipação 
Incremental 
Trabalha com a compreensão deficiente dos 
requisitos Deficiente Excelente Excelente Deficiente 
Trabalha com a compreensão deficiente da 
arquitetura Deficiente Excelente 
Deficiente para 
bom Deficiente 
Produz sistemas de alta confiança Excelente Excelente Bom Excelente 
É fácil modificar o sistema em versões futuras Excelente Excelente Excelente Excelente 
Gerencia riscos Deficiente Excelente Bom Bom 
Pode ser limitado em um cronograma 
predefinido Bom Deficiente Deficiente Bom 
Permite correções no meio do projeto Deficiente Bom Excelente Deficiente 
Possibilita ao cliente visibilidade do progresso Deficiente Excelente Excelente Bom 
Possibilita ao cliente visibilidade do progresso 
do gerenciamento Bom Excelente Bom
Excelente 
Requer pouca gerência ou experiência para usá-
lo Bom Bom Deficiente Bom 
 
Ciclo de Vida do Desenvolvimento de Software 
Compilador – Wikipédia, a enciclopédia livre.pdf
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
1/8pt.wikipedia.org/wiki/Compilador
Uma captura de tela do compilador GCC versão
4.0.2 rodando em uma janela xterm. Um programa
simples está sendo compilado e então executado
Compilador
Origem: Wikipédia, a enciclopédia livre.
Um compilador é um programa de computador (ou um
grupo de programas) que, a partir de um código fonte
escrito em uma linguagem compilada, cria um programa
semanticamente equivalente, porém escrito em outra
linguagem, código objeto. Ele é chamado compilador
por razões históricas; nos primeiros anos da
programação automática, existiam programas que
percorriam bibliotecas de subrotinas e as reunia juntas,
ou compilava, as subrotinas necessárias para
executar uma determinada tarefa.
O nome "compilador" é usado principalmente para os
programas que traduzem o código fonte de uma
linguagem de programação de alto nível para uma
linguagem de programação de baixo nível (por exemplo, Assembly ou código de máquina). Contudo alguns
autores citam exemplos de compiladores que traduzem para linguagens de alto nível como C. Para alguns
autores um programa que faz uma tradução entre linguagens de alto nível é normalmente chamado um tradutor,
filtro ou conversor de linguagem. Um programa que traduz uma linguagem de programação de baixo nível
para uma linguagem de programação de alto nível é um descompilador. Um programa que faz uma tradução
entre uma linguagem de montagem e o código de máquina é denominado montador (assembler). Um
programa que faz uma tradução entre o código de máquina e uma linguagem de montagem é denominado
desmontador (disassembler). Se o programa compilado pode ser executado em um computador cuja CPU
ou sistema operacional é diferente daquele em que o compilador é executado, o compilador é conhecido como
um compilador cruzado.
Índice
1 História
2 Características
3 Fases da compilação
3.1 Análise léxica
3.2 Análise sintática
3.3 Análise semântica
3.4 Geração de código intermediário
3.5 Optimização de código
3.6 Geração de código final
4 Tratamento de erros
5 Ver também
6 Notas
7 Referências
8 Bibliografia
9 Ligações externas
[1]
[Nota 1]
[2][3]
[4]
[5]
[6]
[5]
[6]
[7]
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
2/8pt.wikipedia.org/wiki/Compilador
Grace Hopper em 1984
História
Os softwares para os primeiros computadores foram escritos
principalmente em linguagem assembly por muitos anos. As linguagens de
alto nível de programação não foram inventadas até que os benefícios de
ser capaz de reutilizar software em diferentes tipos de CPUs passassem
a ser significativamente maiores do que o custo de se escrever um
compilador. A capacidade de memória muito limitada capacidade dos
primeiros computadores também criava muitos problemas técnicos na
implementação de um compilador.
No final da década de 1950, as linguagens de programação
independentes de máquina foram propostas. Posteriormente, vários
compiladores experimentais foram desenvolvidos. O primeiro
compilador foi escrito por Grace Hopper, em 1952, para a linguagem
de programação A-0. Antes de 1957, foram desenvolvidos esforços e
várias contribuições ao desenvolvimento de linguagens de alto nível
foram feitas. Entre estes, o desenvolvimento da Short Code (UNIVAC),
Speedcoding no IBM 701, o Whirlwind, o BACAIC e o PRINT. A equipe de desenvolvimento do
FORTRAN liderada por John Backus na IBM é geralmente creditada como tendo introduzido o primeiro
compilador completo em 1957 (embora tenha ocorrido simultaneamente o desenvolvimento do algebraic
translator de Laning e Zierler ). O COBOL é um exemplo de uma linguagem da primeira geração que
compilava em múltiplas arquiteturas, em 1960.
Em muitos domínios de aplicação a idéia de usar uma linguagem de alto nível rapidamente ganhou força. Por
causa da funcionalidade de expansão apoiada por linguagens de programação recentes e a complexidade
crescente de arquiteturas de computadores, os compiladores tornaram-se mais e mais complexos.
Os primeiros compiladores foram escritos em linguagem assembly. O primeiro compilador de auto-
hospedagem - capaz de compilar seu próprio código-fonte em uma linguagem de alto nível - foi criado para o
Lisp por Tim Hart e Levin Mike no MIT em 1962.
Características
Normalmente, o código fonte é escrito em uma linguagem de programação de alto nível, com grande
capacidade de abstração, e o código objeto é escrito em uma linguagem de baixo nível, como uma
sequência de instruções a ser executada pelo microprocessador.
O processo de compilação é composto de análise e síntese. A análise tem como objetivo entender o código
fonte e representá-lo em uma estrutura intermediária. A síntese constrói o código objecto a partir desta
representação intermediária.
A análise pode ser subdividida ainda em análise léxica, análise sintática, análise semântica e geração de código
intermediário. É também conhecida como front end. A síntese pode ter mais variações de um compilador a
outro, podendo ser composta pelas etapas de optimização de código e geração de código final (ou código de
máquina), sendo somente esta última etapa é obrigatória. É também conhecida como back end.
Classicamente, um compilador traduz um programa de uma linguagem textual facilmente entendida por um ser
humano para uma linguagem de máquina, específica para um processador e sistema operacional. Atualmente,
porém, são comuns compiladores que geram código para uma máquina virtual que é, depois, interpretada por
[8]
[9]
[10][11] [12]
[9]
[13]
[14]
[15]
[16]
[16]
[16]
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
3/8pt.wikipedia.org/wiki/Compilador
O processo da
compilação
um interpretador.
Em linguagens híbridas, o compilador tem o papel de converter o código fonte em um código chamado de byte
code, que é uma linguagem de baixo nível. Um exemplo deste comportamento é o do compilador da linguagem
Java que, em vez de gerar código da máquina hospedeira (onde se está executando o compilador), gera código
chamado Java Bytecode.
Um compilador é chamado de Just-in-time compiler (JIT) quando seu processo de compilação acontece
apenas quando o código é chamado. Um JIT pode fazer otimizações às instruções a medida que as
compila.
Muitos compiladores incluem um pré-processador. Um pré-processador é um programa separado, ativado
pelo compilador antes do início do processo de tradução. Normalmente é responsável por mudanças no
código fonte destinadas de acordo com decisões tomadas em tempo de compilação. Por exemplo, um
programa em C permite instruções condicionais para o pré-processador que podem incluir ou não parte do
código caso uma assertiva lógica seja verdadeira ou falsa, ou simplesmente um termo
esteja definido ou não. Tecnicamente, pré-processadores são muito mais simples que
compiladores e são vistos, pelos desenvolvedores, como programas à parte, apesar
dessa visão não ser necessariamente compartilhada pelo usuário.
Outra parte separada do compilador que muitos usuários vêem como integrada é o
linker, cuja função é unir vários programas já compilados de uma forma independente
e unificá-los
em um programa executável. Isso inclui colocar o programa final em
um formato compatível com as necessidades do sistema operacional para carregá-lo
em memória e colocá-lo em execução.
Fases da compilação
Análise léxica
A análise léxica é a primeira fase do compilador. A função do analisador léxico,
também denominado scanner, é ler o código fonte, caracter a caracter, buscando a
separação e identificação dos elementos componentes do programa fonte,
denominados símbolos léxicos ou tokens. É também de responsabilidade desta
fase a eliminação de elementos "decorativos" do programa, tais como espaços em
branco, marcas de formatação de texto e comentários. Existem disponíveis uma
série de geradores automáticos de analisadores léxicos, como por exemplo, o lex. O
objetivo dos geradores automáticos é limitar o esforço de programação de um
analisador léxico especificando-se apenas os tokens a ser reconhecidos.
Análise sintática
A análise sintática, ou análise gramatical é o processo de se determinar se uma cadeia de símbolos léxicos pode
ser gerada por uma gramática. O analisador sintático é o cerne do compilador, responsável por verificar se
os símbolos contidos no programa fonte formam um programa válido, ou não. No caso de analisadores
sintáticos top-down, temos a opção de escrevê-los à mão ou gerá-los de forma automática, mas os
analisadores bottom-up só podem ser gerados automaticamente. A maioria dos métodos de análise
sintática, cai em uma dessas duas classes denominadas top-down e bottom-up. Entre os métodos top-
down os mais importantes são a análise sintática descendente recursiva e a análise sintática preditiva não-
recursiva. Entre os métodos de análise sintática bottom-up os mais importantes são a análise sintática de
precedência de operadores, análise sintática LR canônico, análise sintática LALR e análise sintática SLR.
[17]
[18]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[25]
[29]
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
4/8pt.wikipedia.org/wiki/Compilador
Exemplo de código de três
endereços e um DAG
correspondente para uma
expressão aritimética
Existem disponíveis uma série de geradores automáticos de analisadores sintáticos, como por exemplo, o
Yacc, o Bison e o JavaCC.
Análise semântica
As análises léxica e sintática não estão preocupadas com o significado ou semântica dos programas que elas
processam. O papel do analisador semântico é prover métodos pelos quais as estruturas construídas pelo
analisador sintático possam ser avaliadas ou executadas. As gramáticas livres de contexto não são
suficientemente poderosas para descrever uma série de construções das linguagens de programação, como por
exemplo regras de escopo, regras de visibilidade e consistência de tipos. É papel do analisador semântico
assegurar que todas as regras sensíveis ao contexto da linguagem estejam analisadas e verificadas quanto à sua
validade. Um exemplo de tarefa própria do analisador semântico é a checagem de tipos de variáveis em
expressões. Um dos mecanismos comumente utilizados por implementadores de compiladores é a
Gramática de Atributos, que consiste em uma gramática livre de contexto acrescentada de um conjunto finito de
atributos e um conjunto finito de predicados sobre estes atributos.
Geração de código intermediário
Na fase de geração de código intermediário, ocorre a transformação da
árvore sintática em uma representação intermediária do código fonte.
Esta linguagem intermediária é mais próxima da linguagem objeto do que
o código fonte, mas ainda permite uma manipulação mais fácil do que se
código assembly ou código de máquina fosse utilizado. Um tipo
popular de linguagem intermediária é conhecido como código de três
endereços. Neste tipo de código uma sentença típica tem a forma
X := A op B, onde X, A e B são operandos e op uma operação
qualquer. Uma forma prática de representar sentenças de três endereços
é através do uso de quádruplas (operador, argumento 1, argumento 2 e,
resultado). Este esquema de representação de código intermediário é
preferido por diversos compiladores, principalmente aqueles que
executam extensivas otimizações de código, uma vez que o código
intermediário pode ser rearranjado de uma maneira conveniente com
facilidade. Outras representações de código intermediário comumente usadas são as triplas, (similares as
quádruplas exceto pelo fato de que os resultados não são nomeados explicitamente) as árvores, os grafos
acíclicos dirigidos(DAG) e a notação polonesa.
Optimização de código
A Otimização de código é a estratégia de examinar o código intermediário, produzido durante a fase de
geração de código com objetivo de produzir, através de algumas técnicas, um código que execute com bastante
eficiência. O nome optimizador deve sempre ser encarado com cuidado, pois não se pode criar um
programa que leia um programa P e gere um programa P´ equivalente sendo melhor possível segundo o critério
adotado. Várias técnicas e várias tarefas se reúnem sob o nome de Optimização. Estas técnicas consistem
em detectar padrões dentro do código produzido e substituí-los por códigos mais eficientes. Entre as
técnicas usadas estão a substituição de expressões que podem ser avaliadas durante o tempo de compilação
pelos seus valores calculados, eliminação de sub-expressões redundantes, desmembramento de laços,
substituição de operações (multiplicação por shifts), entre outras. Uma das técnicas de optimização mais
eficazes e independente de máquina é a otimização de laços, pois laços internos são bons candidatos para
melhorias. Por exemplo, em caso de computações fixas dentro de laços, é possível mover estas computações
para fora dos mesmos reduzindo processamento.
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[32]
[23]
[36]
[32]
[38]
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
5/8pt.wikipedia.org/wiki/Compilador
Tratamento de erro de execução em uma aplicação
Java no Eclipse
Geração de código final
A fase de geração de código final é a última fase da compilação. A geração de um bom código objeto é difícil
devido aos detalhes particulares das máquinas para os quais o código é gerado. Contudo, é uma fase
importante, pois uma boa geração de código pode ser, por exemplo, duas vezes mais rápida que um algoritmo
de geração de código ineficiente. Nem todas as técnicas de optimização são independentes da arquitetura
da máquina-alvo. Optimizações dependentes da máquina necessitam de informações tais como os limites e os
recursos especiais da máquina-alvo a fim de produzir um código mais compacto e eficiente. O código
produzido pelo compilador deve se aproveitar dos recursos especiais de cada máquina-alvo. Segundo Aho,
o código objeto pode ser uma sequência de instruções absolutas de máquina, uma sequência de instruções de
máquina relocáveis, um programa em linguagem assembly ou um programa em outra linguagem.
Tratamento de erros
O tratamento de erros está voltado a falhas devido a
muitas causas: erros no compilador, erros na elaboração
do programa a ser compilado, erros no ambiente
(hardware, sistema operacional), dados incorretos, etc.
As tarefas relacionadas ao tratamento de erros consitem
em detectar cada erro, reportá-lo ao usuário e
possivelmente fazer algum reparo para que o
processamento possa continuar.
Os erros podem ser classificados em erros léxicos,
erros sintáticos, erros não independentes de contexto
(semânticos), erros de execução e erros de limite.
Os erros léxicos ocorrem quando
um token identificado
não pertence a gramática da linguagem fonte. Os erros
sintáticos ocorrem quando alguma estrutura de frase não está de acordo com a gramática, como por exemplo
parênteses sem correspondência. Os erros não independentes de contexto em geral são associados a não
declaração de objetos como variáveis e erros de tipos. Os erros de execução ocorrem após a compilação,
quando o programa já está sendo executado. Um exemplo típico é o da divisão por zero. Os erros de limite,
ocorrem durante a execução e estão relacionados as características da máquina na qual o programa está sendo
executado, como por exemplo, estouro de pilha.
Alguns compiladores encerram o processo de tradução logo ao encontrar o primeiro erro do programa-fonte.
Esta é uma política de fácil implementação. Compiladores mais sofisticados, porém, detectam o maior número
possível de erros visando diminuir o número de compilações.
A recuperação de erros em analisadores sintáticos top-down é mais fácil de implementar do que em
analisadores bottom-up. O problema é que diferente de um analisador top-down, este último não sabe
quais símbolos são esperados na entrada, somente os que já foram processados. Pode-se usar neste caso
técnicas como, por exemplo, a técnica de panic-mode que procura em tabelas sintáticas em busca de símbolos
válidos na entrada. Nesta técnica se descartam símbolos da entrada até que um delimitador (como um ponto
e vírgula, por exemplo) seja encontrado. O analisador apaga as entradas da pilha até que encontre uma entrada
que permita que o processo de análise prossiga em diante.
Ver também
Ciência da computação
[36]
[32]
[39]
[40]
[41]
[41]
[42]
[43]
[43]
[44]
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
6/8pt.wikipedia.org/wiki/Compilador
Compilador Just in Time (JIT)
Linguagens formais
Linguagem de programação
Interpretador
Linker
Notas
1. ↑ Em português, "compilar" significa, por exemplo: reunir obras literárias, documentos, escritos de vários
autores, entre outros, compondo uma obra com esse material. Larousse. Dicionário da Língua
Portuguesa (em inglês). [S.l.]: Nova Cultural, 1992. ISBN 85-85222-23-9
Referências
1. ↑ AHO, Alfred V.; Ullman, Jeffrey D.. Principles of Compiler Design (em inglês). Reading, Massachusetts,
EUA: Addison-Wesley, 1977. 604 p. p. 1. ISBN 0-201-00022-9
2. ↑ PARSONS, Thomas W.. Introduction to Compiler Construction (em inglês). Nova Iorque, EUA: Computer
Science Press, 1992. 359 p. p. 1. ISBN 0-7167-8261-8
3. ↑ APPEL, Andrew W.. Modern Compiler Implementation in Java
(http://www.cs.princeton.edu/~appel/modern/java/) (em inglês). Cambridge: Cambridge University Press,
1998. 548 p. p. 3. ISBN 0-521-58388-8
4. ↑ COOPER, Torczon. Engineering a Compiler (em inglês). San Francisco: Morgan Kaufmann, 2003. p. 2. ISBN
1-55860-698-X
5. ↑ NETO, João José. Introdução à Compilação (em português). Rio de Janeiro: LTC, 1987. 222 p. ISBN 978-
85-216-0483-9
6. ↑ WATT, David A.; Brown, Deryck F.. Programming Language Processors in Java (em inglês). Harlow,
England: Prentice Hall, 2000. 436 p. p. 27. ISBN 0-130-25786-9
7. ↑ ELDER, John. Compiler Conctruction: A Recursive Descent Model (em inglês). Englewood Cliffs, Nova
Jersey, EUA: Prentice Hall, 1994. 437 p. p. 7-8. vol. 1. ISBN 0-13-291139-6
8. ↑ LEMONE, Karen A.. Fundamentals of Compilers: An Introduction to Computer Language Translation (em
inglês). Boca Raton: CRC, 1992. 184 p. ISBN 0-8493-7341-7
9. ↑ Wexelblat, Richard L.(Editor). History of Programming Languages. New York: Academic Press,
1981. 758 p. p. 6-15. ISBN 0-12-745040-8
10. ↑ Bashe, Charles J.; Johnson, Lyle R.; Palmer, John H.; Pugh, Emerson W.. IBM´s Early Computers.
Cambridge: MIT Press, 1986. 716 p. p. 333. ISBN 0-262-02225-7
11. ↑ MCCLELLAND, William F. (abril 1983). "Programming" (em ingles). Annals of The History of Computing 5 (2):
135-139. Arlington, VA: American Federation of Information Processing Societies. ISSN 1058-6180
(http://worldcat.org/issn/1058-6180) .
12. ↑ Sammet, Jean E. Programming Languages: History and Fundamentals. Englewood Cliffs, New
Jersey: Prentice Hall, 1969. 785 p. p. 5. ISBN 0-13-729988-5
13. ↑ IP: Os primeiros compiladores COBOL do mundo (http://www.interesting-people.org/archives/interesting-
people/199706/msg00011.html) . interesting-people.org (12 de Junho de 1997).
14. ↑ T. Hart and M. Levin. O novo compilador, AIM-39 - CSAIL Digital Archive - Artificial Intelligence
Laboratory Series (ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-039.pdf) . publications.ai.mit.edu.
15. ↑ MAK, Ronald. Writing Compilers and Interpreters: An Applied Approach Using C++ (em inglês). Nova
Iorque: John Wiley and Sons, 1996. 838 p. p. 1. ISBN 0-471-11353-0
16. ↑ HOLMES, Jim. Object-Oriented Compiler Construction (em inglês). Englewood Cliffs, Nova
Jersey: Prentice Hall, 1995. 483 p. p. 2-3. ISBN 0-13-630740-X
17. ↑ SEBESTA, Robert. Conceitos de Linguagens de Programação (em português). 9ª ed. Porto Alegre: Bookman,
2010. 792 p. p. 49-50. ISBN 978-85-7780-791-8
18. ↑ ENGEL, Joshua. Programming for the Java Virtual Machine (em inglês). Reading, Massachusetts: Addison
& Wesley, 1999. 488 p. p. 355. ISBN 0-201-30972-6
19. ↑ LOUDEN, Kenneth C.. Compiladores: Princípios e Práticas (em português). São Paulo: Pioneira Thompson
Learning, 2004. 569 p. p. 5. ISBN 85-221-0422-0
a b
a b
a b
a b c
a b
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
7/8pt.wikipedia.org/wiki/Compilador
Learning, 2004. 569 p. p. 5. ISBN 85-221-0422-0
20. ↑ LEVINE, John R.. Linkers & Loaders (em inglês). San Francisco: Morgan Kaufmann Publishers, 2000. 256 p.
p. 1-3. ISBN 1-55860-496-0
21. ↑ AHO, Alfred V.; Ullman, Jeffrey D.. The Theory of Parsing, Translation, and Compiling, Vol. 1, Parsing (em
inglês). Englewood Cliffs, Nova Jersey, EUA: Prentice Hall, 1972. 542 p. p. 59. 2 vol. vol. 1. ISBN 0-13-914556-7
22. ↑ Price, Ana M. A.; Toscano, Simão Sirineo. Implementação de Linguagens de Programação: Compiladores:
Série de Livros Didáticos Número 9 (em português). Porto Alegre: Sagra Luzzatto, 2000. 195 p. ISBN 978-85-
241-0639-2
23. ↑ Compiladores - Página de José Lucas Mourão Rangel Netto (http://www-di.inf.puc-
rio.br/~rangel/comp.html) (em português). PUC-Rio. Página visitada em 21 de junho de 2009.
24. ↑ FISCHER, Charles N.; LeBlanc, Jr, Richard J.. Crafting a Compiler with C (em inglês). Redwood City,
California: Benjamin Cummings Publishing, 1991. 812 p. p. 50. ISBN 0-8053-2166-7
25. ↑ Aho, Alfred V.; Sethi, Ravi; Ullman, Jeffrey D.. Compilers: Principles, Techniques and Tools (em inglês).
Reading, Massachusetts, EUA: Addison-Wesley, 1986. 796 p. ISBN 978-0-201-10088-4
26. ↑ DELAMARO, Marcio. Como Construir um Compilador Utilizando Ferramentas Java
(http://www.novateceditora.com.br/livros/compilador/) (em português). São Paulo: Novatec, 2004. 308 p. p. 4.
ISBN 85-7522-055-1
27. ↑ GRUNE, Dick; Bal, Henri E.; Jacobs, Ceriel J. H.; Langendoen, Koen G. Projeto Moderno de Compiladores
(em português). Rio de Janeiro: Campus, 2001. ISBN 978-85-352-0876-4
28. ↑ LEWIS II, P. M.; Rosenkrantz, D,J.; Stearns, R.E.. Compiler Design Theory (em inglês). Reading,
Massachusetts: Addison-Wesley, 1978. 647 p. p. 227. ISBN 0-201-14455-7
29. ↑ ALBLAS, Henk; Nymeyer, Albert. Practice and Principles of Compiler Building with C (em inglês).
London: Prentice Hall, 1996. 427 p. p. 30. ISBN 0-13-349267-2
30. ↑ WATSON, Des. High-Level
Languages and Their Compilers (em inglês). Wokingham, Reino Unido: Addison-
Wesley, 1989. 337 p. ISBN 0-201-18489-3
31. ↑ Wilhelm, Reinhard; Maurer, Dieter. Compiler Design (em inglês). Harlow, England: Addison-Wesley,
1995. 606 p. ISBN 0-201-42290-5
32. ↑ Tremblay, Jean-Paul; Sorenson, Paul G.. The Theory and Practice of Compiler Writing (em inglês).
Nova Iorque: McGraw-Hill, 1989. 796 p. ISBN 0-07-065161-2
33. ↑ Pittman, Thomas; Peters, James. The Art of Compiler Design: Theory and Practice (em inglês). Englewood
Cliffs, Nova Jersey, EUA: Prentice Hall, 1992. 419 p. ISBN 0-13-048190-4
34. ↑ PYSTER, Arthur B.. Compiler Design and Construction: Tools and Techniques (em inglês). Nova Iorque,
EUA: Van Nostrand Reinhold Company, 1988. 267 p. p. 8. ISBN 0-442-27536-6
35. ↑ CRESPO, Rui Gustavo. Processadores de Linguagens: da Concepção à Implementação (em português). Lisboa,
Portugal: IST Press, 1998. 435 p. p. 247. ISBN 972-8469-01-2
36. ↑ Aho, Alfred V.; Ullman, Jeffrey D.. Principles of Compiler Design (em inglês). Reading, Massachusetts,
EUA: Addison-Wesley, 1977. 604 p. ISBN 0-201-00022-9
37. ↑ MUCHNICK, Steven S.. Advanced Compiler Design Implementation (em inglês). San Francisco,
California: Morgan Kaufmann Publishers, 1997. 856 p. p. 96. ISBN 1-55860-320-4
38. ↑ KAKDE, O. G.. Algorithms for Compiler Design (em inglês). Hingham: Charles River media, 2003. 334 p. ISBN
81-7008-100-6
39. ↑ Aho, Alfred V.; Ullman, Jeffrey D.. The Theory of Parsing, Translation, and Compiling, Vol. 2, Compiling
(em inglês). Englewood Cliffs, Nova Jersey, EUA: Prentice Hall, 1972. p. 720. 2 vol. vol. 2. ISBN 0-201-914564-8
40. ↑ WAITE, William M.; Goos, Gerhard. Compiler Construction (em português). Nova Iorque: Springer-Verlag,
1984. 446 p. p. 302. ISBN 0-387-90821-8
41. ↑ HUNTER, Robin. Compiladores: Sua Concepção e Programação em Pascal (em português).
Lisboa: Presença, 1987. 323 p. p. 259-275. Depósito legal nº 16057/87
42. ↑ KOWALTOWSKI, Tomasz. Implementação de Linguagens de Programação (em português). Rio de
Janeiro: Guanabara Dois, 1983. 189 p. p. 170-171. ISBN 85-7030-009-3
43. ↑ HOLUB, Allen I.. Compiler Design in C (em inglês). Englewood Cliffs, Nova Jersey: Prentice Hall,
1990. 924 p. p. 201;348. ISBN 0-13-155045-4
44. ↑ KAKDE, O. G.. Algorithms for Compiler Design (em inglês). Hingham: Charles River media, 2003. 334 p.
p. 261. ISBN 81-7008-100-6
Bibliografia
a b
a b
a b c d
a b c
a b
a b
27/09/12 Compilador – Wikipédia, a enciclopédia liv re
8/8pt.wikipedia.org/wiki/Compilador
APPEL, Andrew W.. Modern Compiler Implementation in C: Basic Techiques (em inglês).
[S.l.]: Cambridge University Press, 1997. 398 p. ISBN 0-521-58653-4
BROWN, P. J.. Writing Interactive Compilers and Interpreters (em inglês). Chichester: John Wiley &
Sons, 1979. 265 p. ISBN 0-471-27609-X
KAPLAN, Randy M.. Constructing Language Processors for Little Languages (em inglês). Nova
Iorque: John Wiley & Sons, 1994. 452 p. ISBN 0-471-59754-6
LEE, John A. N.. The Anatomy of a Compiler (em inglês). Nova Iorque: Reinhold Publishing Company,
1967. 275 p. Library of Congress Catalog Card Number: 67-29207
METSKER, Steven John. Building Parsers with Java (em inglês). Boston: Addison-Wesley, 2001. 371
p. ISBN 0-201-71962-2
RICARTE, Ivan. Introdução à Compilação (em português). Rio de Janeiro: Campus, Elsevier, 2008. 264
p. ISBN 978-85-352-3067-3
TERRY, Patrick D.. Programming Language Translation: A Practical Approach (em inglês).
Wokingham: Addison-Wesley, 1986. 443 p. ISBN 0-201-18040-5
WIRTH, Niklaus. Compiler Construction
(http://www.cs.inf.ethz.ch/~wirth/books/CompilerConstruction) (em inglês). [S.l.]: Addison-Wesley,
1996. ISBN 0-201-40353-6
Ligações externas
Página com material de compiladores (http://www-di.inf.puc-rio.br/~rangel/comp.html) (em português)
Compilador Educativo Verto (http://verto.sf.net) (em português)
Compiladores livres (http://www.thefreecountry.com/compilers/index.shtml) (em inglês)
Obtida de "http://pt.wikipedia.org/w/index.php?title=Compilador&oldid=32100349"
Categorias: Compiladores Programação
Esta página foi modificada pela última vez à(s) 11h43min de 4 de setembro de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.
Fluxo.PNG
Interpretador – Wikipédia, a enciclopédia livre.pdf
27/09/12 Interpretador – Wikipédia, a enciclopédia liv re
1/1
Interpretador
Origem: Wikipédia, a enciclopédia livre.
Interpretadores são programas de computador que leem um código fonte de uma linguagem de programação
interpretada e o converte em código executável. Seu funcionamento pode variar de acordo com a
implementação. Em alguns casos, o interpretador lê linha-por-linha e converte em código objeto (ou bytecode)
à medida que vai executando o programa e, em outros casos, converte o código fonte por inteiro e depois o
executa.
Na verdade, em princípio, pode-se implementar compiladores e interpretadores para qualquer linguagem de
programação. Mas, dependendo da necessidade, pode ser melhor criar um interpretador ou um compilador.
Exemplo de linguagens interpretadas
BASIC
Bash
Perl
PHP
Python
Euphoria
Forth
JavaScript
Logo
Lisp
Lua
MUMPS
Ruby
Haskell
Ver também
Análise léxica
Análise sintática
Compilador
Linguagem interpretada
Linguagem de script
Tradutor (computação)
Obtida de "http://pt.wikipedia.org/w/index.php?title=Interpretador&oldid=32099687"
Categorias: Linguagens interpretadas Programas de computador por finalidade
Esta página foi modificada pela última vez à(s) 08h45min de 4 de setembro de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.
Manutenção de software – Wikipédia, a enciclopédia livre.pdf
Manutenção de software – Wikipédia, a enciclopédia livre
1/2pt.wikipedia.org/wiki/Manutenção_de_software
Manutenção de software
Origem: Wikipédia, a enciclopédia livre.
Em engenharia de software, manutenção de software é o processo de melhoria e otimização de um software já
desenvolvido (versão de produção), como também reparo de defeitos. A manutenção do software é uma das
fases do processo de desenvolvimento de software, e ocorre a seguir a entrada do software em produção.
Esta fase envolve:
mudanças no software para corrigir defeitos e deficiências que foram encontrados durante a utilização pelo
usuário
novas funcionalidades para melhorar a aplicabilidade e usabilidade do software.
A manutenção do software envolve inúmeras técnicas específicas. Uma das técnicas é separação estática, a qual
é usada para identificar todos os códigos de programa que são afetados por alguma variável. Isto é geralmente
útil em programas de refatoração de código que foram especialmente útil em assegurar preparação para bug do
milênio.
A fase de manutenção de software é uma parte explicita do modelo em cascata do processo de desenvolvimento
de
software a qual foi criada durante a fase de programação estruturada da ciência da computação. O outro
modelo principal, o modelo em espiral, foi desenvolvido durante a fase de orientação ao objeto da engenharia de
software, não faz nenhuma menção explicita a fase de manutenção. Independentemente disto, esta atividade é
importante, considerando o fato que dois terços do custo do tempo de vista do sistema de software envolve
manutenções.
No ambiente de desenvolvimento de software formal, a equipe ou organização de desenvolvimento deverá ter
algum mecanismo para documentar e rastrear os defeitos e deficiências. O software é disponibilizado com
problemas porque a organização decide a utilidade e valor do software a um nível de qualidade particular
pesando o impacto de deficiências ou defeitos desconhecidos.
Os problemas conhecidos são normalmente registrados em um documento de considerações operacionais ou
notas de implantação de forma que os usuários do software são capazes de contornar os problemas conhecidos e
que irão ser descobertos quando o uso do software incapacitar tarefas particulares.
Com a implantação do software, outros defeitos e deficiências não documentadas serão descobertos pelos
usuários de software, Tão logo tais problemas sejam reportados para a organização de desenvolvimento, eles
passaram a fazer parte do rastreamento de defeitos do sistema.
As pessoas envolvidas na fase de manutenção de software irão trabalhar no problemas conhecidos, localizá-los, e
preparar novas versões do software, conhecidas como versões de manutenção, a qual ira atualizar a
documentação de problemas.
Ver também
Montando e Gerenciando Equipe para manutenção de software.
(http://tecnologoanalisedesistema.blogspot.com/2010/12/montando-e-gerenciando-equipe-para.html)
Software
Gerenciamento de Projeto
Fragilidade do software
28/09/12 Manutenção de software – Wikipédia, a enciclopédia livre
2/2pt.wikipedia.org/wiki/Manutenção_de_software
Ligações externas
Paper on Software Maintenance Maturity Model
(http://selab.netlab.uky.edu/homepage/April%20Huffman%20Abran%20Dumke%20Journal%202005.pdf)
(from University of Kentuky)
software manutenção Maturity Model (http://www.s3m.ca)
Paper on Software Maintenance as Part of the Software Life Cycle
(http://hepguru.com/maintenance/Final_121603_v6.pdf) (da Universidade de Tufts)
Journal of Software Maintenance (http://www3.interscience.wiley.com/cgi-bin/jhome/5391/)
Software entropy (http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html)
Obtida de "http://pt.wikipedia.org/w/index.php?title=Manutenção_de_software&oldid=30562271"
Categoria: Engenharia de software
Esta página foi modificada pela última vez à(s) 03h53min de 6 de junho de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso para
mais detalhes.
mapa_conceitual.pdf
Mapa Conceitual
Processo de Desenvolvimento de Software
		Page 1 (untitled)
Modelo em cascata – Wikipédia, a enciclopédia livre.pdf
07/10/12
1/2
Modelo em cascata
Origem: Wikipédia, a enciclopédia livre.
O modelo em cascata é um modelo de desenvolvimento de software seqüencial no qual o desenvolvimento é
visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos,
projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo cascata
é frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, Royce
defendia um abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata.
Royce originalmente descreve o que é hoje conhecido como o modelo em cascata como um exemplo de um
método que ele argumentava ser um risco e um convite para falhas.
História do modelo em cascata
Em 1970 Royce propôs o que é agora popularmente designado no modelo em cascata como um conceito
inicial, um modelo no qual ele argumentava ser defeituoso. Seu trabalho então explorou como o modelo inicial
poderia ser desenvolvido em um modelo iterativo, com feedback de cada fase influenciando as próximas, de
modo similar a muitos métodos amplamente utilizados hoje. Ironicamente, foi somente o modelo inicial que
mereceu destaque; e sua crítica ao modelo inicial sendo amplamente ignorada. O modelo em cascata
rapidamente não se tornou o que Royce pretendia, um projeto iterativo, mas ao invés disto um modelo
puramente sequencialmente ordenado. Este artigo ira tratar o significado popular para o modelo em
cascata. Para um modelo iterativo similar a versão final de Royce, ver o modelo em espiral.
A despeito das intenções de Royce para o modelo em cascata ser modificado para um modelo iterativo, o uso
do modelo em cascata como um processo puramente sequencial é ainda popular, e, para alguns, o termo
modelo em cascata veio se referir a uma abordagem para criação de software a qual é vista como inflexível e
não iterativa. Aqueles que usam o termo modelo em cascata de forma pejorativa para modelos não iterativos
aos quais não apreciam usualmente veem o modelo em cascata em si como ingênuo e inadequado para um
processo do mundo real
Uso do modelo cascata
No modelo em cascata original de Royce, as seguintes fases são seguidas em perfeita ordem:
1. Elicitação de requisitos
2. Projeto
3. Construção (implementação ou codificação)
4. Integração
5. Teste e depuração
6. Instalação
7. Manutenção de software
Para seguir um modelo em cascata, o progresso de uma fase para a próxima se dá de uma forma puramente
sequencial. Por exemplo, inicialmente completa-se a especificação de requisitos — elaborando um conjunto
rígido de requisitos do software (Por exemplo, os requisitos para Wikipédia devem permitir edições anônimas
de artigos; Wikipédia deve permitir às pessoas procurar pelas informações), embora as especificações dos
requisitos reais sejam mais detalhados, em um procedimento para projeto. O software em questão é
projetado e um blueprint é desenhado para implementadores seguirem — este projeto deve ser um plano
07/10/12 Modelo em cascata – Wikipédia, a enciclopédia liv re
2/2pt.wikipedia.org/wiki/Modelo_em_cascata
O Modelo em cascata estático. O andamento do processo
flui de cima para baixo, como uma cascata.
para implementação dos requisitos dados.
Quando e somente quando o projeto está
terminado, uma implementação para este
projeto é feita pelos codificadores.
Encaminhando-se para o próximo estágio da
fase de implementação, inicia-se a
integração dos componentes de software
construídos por diferentes times de projeto.
(Por exemplo, um grupo pode estar
trabalhando no componente de página web
da Wikipedia e outros grupos pode estar
trabalhando no componente servidor da
Wikipedia. Estes componentes devem ser
integrados para juntos produzirem um
sistema como um todo). Após as fases de
implementação e integração estarem
completas, o produto de software é testado e
qualquer problema introduzido nas fases
anteriores é removida aqui. Com isto o
produto de software é instalado, e mais tarde mantido pela introdução de novas funcionalidades e
remoção de defeitos.
Portanto o modelo em cascata move-se para a próxima fase somente quando a fase anterior está completa e
perfeita. Desenvolvimento de fases no modelo em cascata são discretas, e não há pulo para frente, para trás ou
sobreposição entre elas.
Contudo, há vários modelos em cascata modificados (incluindo o
modelo final de Royce) que podem ser
incluídos como variações maiores ou menores deste processo.
Obtida de "http://pt.wikipedia.org/w/index.php?title=Modelo_em_cascata&oldid=29964006"
Categoria: Engenharia de software
Esta página foi modificada pela última vez à(s) 17h04min de 5 de maio de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.
Modelos ciclo de vida.pdf
07/10/12 Modelos ciclo de v ida – Wikipédia, a enciclopédia liv re
1/6pt.wikipedia.org/wiki/Modelos_ciclo_de_v ida
Modelos ciclo de vida
Origem: Wikipédia, a enciclopédia livre.
Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para o
concretizar, mas é também importante perceber como as actividades do processo se relacionam umas com as
outras para que se torne visível todo o processo de desenvolvimento. O termo modelo do ciclo de vida é
utilizado para descrever um modelo que visa descrever um grupo de actividades e a forma como elas se
relacionam. Os modelos mais sofisticados incluem ainda uma descrição de quando e como se deve mover de
uma actividade para a próxima e os deliverables que devem ser produzidos em cada etapa. A razão pela qual
estes modelos são tão conhecidos é o fato de ajudarem as equipes de desenvolvimento, e em particular os
gestores, a obter uma visão geral do projecto de forma a ser possível segui-lo passo a passo, saber que
deliverables foram especificados, o alocamento de recursos e os objectivos propostos. Estes "modelos de ciclo
de vida" ou "modelos de processos" são tipicamente produzidos a partir de uma perspectiva de que poderão
existir vários modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão completa de um
determinado processo.
Índice
1 Modelos de Processos
1.1 Modelos de Atividade
1.2 Modelos de Atividade de Granularidade Fina
1.3 Modelos Papel-Ação
1.4 Modelos Entidade-Relação
2 Atividades do Processo de Engenharia de Requisitos
2.1 Levantamento de Requisitos
2.2 Análise e Negociação de Requisitos
2.3 Documentação de Requisitos
2.4 Validação de Requisitos
3 Modelos de Ciclo de Vida
4 Modelos em Engenharia de Software e Requisitos
4.1 Modelo em Cascata
4.2 Modelo em Espiral
4.3 Características de Vários Modelos
5 Bibliografia
6 Ver também
7 Ligações externas
Modelos de Processos
Embora este artigo seja mais focado aos modelos de ciclo de vida na engenharia de software, é importante ter
uma ideia dos vários tipos de modelos de processos existentes. Os tipos de modelos de processos que podem
ser produzidos dependem do uso que lhes será dado. Poderá ser necessário um modelo para explicar como
está organizada a informação de processos, um modelo que ajude a compreender e permita melhorar
07/10/12 Modelos ciclo de v ida – Wikipédia, a enciclopédia liv re
2/6pt.wikipedia.org/wiki/Modelos_ciclo_de_v ida
Modelo de atividades.
processos, um modelo para satisfazer certos requisitos de qualidade, etc. Alguns exemplos de modelos que
descrevem processos são:
Modelos de Atividade
A figura seguinte é um exemplo deste tipo de modelo. Estes modelos
mostram os principais processos e atividades de engenharia de requisitos
e o seu sequenciamento (aproximado). Este tipo de modelos não permite
forçar um processo mas dá uma visão geral do mesmo e são tipicamente
construídos como ponto de partida para a descrição de um processo
com secções separadas dando cobertura a cada caixa no modelo. Os
modelos descrevem o contexto das diferentes atividades de um processo, mostrando outros processos que
consomem ou produzem input de um outro..
Modelos de Atividade de Granularidade Fina
Estes são modelos mais detalhados para um processo específico. Podem ser utilizados para perceber e
melhorar processos existentes.
Modelos Papel-Ação
Estes são modelos que mostram o papel de diferentes pessoas envolvidas num processo e as ações que podem
tomar. Estes modelos, que não são tratados mais a fundo neste artigo, podem ajudar a perceber e automatizar
processos.
Modelos Entidade-Relação
Estes modelos mostram as entradas, saídas e resultados intermédios dos processos e relações entre eles.
Podem ser utilizados num sistema de gestão de qualidade e como modelos complementares das actividades de
processo.
Atividades do Processo de Engenharia de Requisitos
Diferentes tipos de organizações abordam a engenharia de requisitos de formas radicalmente diferentes. Uma
companhia aeroespacial que se encontre a especificar sistemas de software e hardware muito complexos não
utiliza o mesmo processo de engenharia de requisitos que uma outra companhia que desenvolve produtos de
consumo para computadores pessoais. No entanto, as diferenças entre estes processos encontram-se
geralmente no nível de detalhe dos processos. Num nível abstracto, todos os processos de engenharia de
requisitos podem ser descritos pelo modelo mostrado na figura anterior. Antes de apresentar os modelos de
ciclo de vida para o processo de engenharia de requisitos, torna-se necessário compreender melhor as
actividades nele envolvidas. As actividades do processo de engenharia de requisitos são as seguintes:
Levantamento de Requisitos
Os requisitos do sistema são obtidos através de consultas aos stakeholders, documentação do sistema,
conhecimento do domínio e estudos de mercado. Este processo é também conhecido como aquisição de
requisitos ou descoberta de requisitos.
Análise e Negociação de Requisitos
07/10/12 Modelos ciclo de v ida – Wikipédia, a enciclopédia liv re
3/6pt.wikipedia.org/wiki/Modelos_ciclo_de_v ida
Os requisitos são analisados em detalhe e os diferentes stakeholders negociam para decidirem que requisitos
serão aceitos. Este processo é necessário visto que é inevitável o aparecimento de conflitos entre requisitos de
diferentes fontes, existência de informação incompleta ou então os requisitos podem ser incompatíveis com o
orçamento disponível para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade na
negociação dos requisitos para que seja possível concordar acerca de conjunto de requisitos para o sistema.
Documentação de Requisitos
Os requisitos acordados durante o processo de negociação são documentados com um nível de detalhe
apropriado. Em geral, é necessário existir um documento de especificação de requisitos que seja compreendido
por todos os stakeholders. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e
diagramas. Podem também ser produzidos documentos de sistema mais detalhados tais como modelos de
sistema.
Validação de Requisitos
Todos os requisitos obtidos nas actividades anteriores devem ser cuidadosamente verificados para apurar se
estão completos e são consistentes. Este processo tem como finalidade detectar potenciais problemas no
documento de especificação de requisitos antes que este seja utilizado como base para o desenvolvimento do
sistema.
Modelos de Ciclo de Vida
Os modelos existentes possuem diferentes graus de sofisticação e complexidade. Para projetos que envolvem
uma equipe de desenvolvimento pouco numerosa e experiente, o mais adequado será provavelmente um
processo simples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de
elementos e milhares de utilizadores, um processo simples não é suficiente para oferecer a estrutura de gestão e
disciplina necessárias à engenharia de um bom produto de software. Desta forma, é necessário algo mais formal
e disciplinado. É importante fazer notar
que isto não significa que se perca em inovação ou que se põe entraves
à criatividade. Significa apenas que é utilizado um processo bem estruturado para permitir a criação de uma
base estável para a criatividade.
Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto é, de facto, uma
versão simplificada da realidade. É suposto ser uma abstracção e, tal como todas as boas abstracções, apenas
a quantidade de detalhe necessária ao trabalho em mãos deve ser incluída. Qualquer organização que deseje
por um modelo de ciclo de vida em prática irá necessitar de adicionar detalhes específicos para dadas
circunstâncias e diferentes culturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipa e ao
mesmo tempo tornar possível o desenvolvimento de grandes e complexos produtos de software.
Na próxima secção, é introduzido uma interpretação do aspecto que um modelo de ciclo de vida deve ter em
termos de engenharia de requisitos para projectos de software. Dependendo do tipo de sistema em
desenvolvimento pode não ser completamente possível ou até apropriado seguir os modelos rigorosamente. É
de notar também que para por em prática um destes modelos e aplica-lo a um projecto real seria necessário
adicionar mais detalhe.
Modelos em Engenharia de Software e Requisitos
A engenharia de software tem produzido inúmeros modelos de ciclo de vida, incluindo os modelos de cascata,
espiral e desenvolvimento rápido de aplicações (RAD). Antes do modelo de cascata ser proposto em 1970,
não havia concordância em termos dos métodos a levar a cabo no desenvolvimento de software. Desde então
07/10/12 Modelos ciclo de v ida – Wikipédia, a enciclopédia liv re
4/6pt.wikipedia.org/wiki/Modelos_ciclo_de_v ida
Modelo em Cascata.
ao longo dos anos muitos modelos têm sido propostos refletindo assim a grande variedade de interpretações e
caminhos que podem ser tomados no desenvolvimento de software. Neste artigo, foi decidida a inclusão destes
modelos por duas razões: primeiro porque são representativos dos modelos utilizados na indústria e foi já
provado o seu sucesso, e segundo porque mostram como a ênfase no desenvolvimento de software mudou
gradualmente de forma a incluir uma visão mais interativa e centrada no utilizador.
Modelo em Cascata
O modelo de ciclo de vida em cascata foi o primeiro
modelo a ser conhecido em engenharia de software e
está na base de muitos ciclos de vida utilizados hoje em
dia. Este consiste basicamente num modelo linear em
que cada passo deve ser completado antes que o
próximo passo possa ser iniciado. Por exemplo, a
análise de requisitos deve ser completada antes que o
desenho do sistema possa ser iniciado. Os nomes dados
a cada passo variam, assim como varia a definição exata
de cada um deles, mas basicamente o ciclo de vida
começa com a análise de requisitos movendo-se de seguida para a fase de desenho, codificação,
implementação, teste e finalmente manutenção do sistema. Uma das grandes falhas deste modelo é o fato de os
requisitos estarem constantemente a mudar já que os negócios e ambiente em que se inserem mudam
rapidamente. Isto significa que não faz sentido parar os requisitos durante muito tempo, enquanto o desenho e
implementação do sistema são completados. Foi então reconhecido que seria necessário dar feedback às
atividades iniciais a partir do momento em que este modelo começou a ser usado em grande escala. A ideia de
interacção não foi incorporada na filosofia do modelo de cascata. Neste momento, é incluído algum nível de
interação na maior parte das versões deste modelo e são comuns sessões de revisão entre os elementos
responsáveis pelo desenvolvimento do sistema. No entanto, a possibilidade de revisão e avaliação com os
utilizadores do sistema não está contemplada neste modelo.
Modelo em Espiral
Durante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software,
mas em 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiral para desenvolvimento de
software saltam a vista dois aspectos: a análise de risco e prototipagem. O modelo espiral incorpora-os de uma
forma interativa permitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada
interação à volta da espiral pode ser baseada num modelo diferente e pode ter diferentes atividades. No caso
da espiral, não foi a necessidade do envolvimento dos utilizadores que inspirou a introdução de interação mas
sim a necessidade de identificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se
que as diferentes atividades são repetidas até uma decisão ser tomada e o documento de especificação de
requisitos ser aceito. Se forem encontrados problemas numa versão inicial do documento, reentra-se nas fases
de levantamento, análise, documentação e validação. Isto repete-se até que seja produzido um documento
aceitável ou até que fatores externos, tais como prazos e falta de recursos ditem o final do processo de
engenharia de requisitos.
Características de Vários Modelos
Na tabela seguinte estão sumariadas algumas vantagens e desvantagens de vários modelos de ciclo de vida
utilizados em engenharia de requisitos para projectos de software:
07/10/12 Modelos ciclo de v ida – Wikipédia, a enciclopédia liv re
5/6pt.wikipedia.org/wiki/Modelos_ciclo_de_v ida
Modelo Vantagens Desvantagens
Cascata
Minimiza o tempo de planejamento.
Funciona bem para equipes tecnicamente mais fracas.
Inflexível.
Apenas a fase final produz um
deliverable que não é um
documento.
Torna-se difícil voltar atrás para
corrigir erros.
Espiral
As interações inicias do projecto são as mais baratas,
permitindo que as tarefas de maior risco sejam levadas
com o mínimo de custos.
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 o levar
a cabo.
Prototipagem
Evolucionária
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
exactidão o tempo que o projecto
vai demorar.
Não há forma de saber o número de
iterações que serão necessárias.
Codificação e
Correcção
Não há tempo gasto em planejamento, documentação,
gestão de qualidade e cumprimento de standards.
Requer pouca experiência.
Perigoso.
Não há forma de assegurar
qualidade e identificar riscos.
Falhas fundamentais não percebidas
imediatamente resultando em
trabalho deitado fora.
Entre outros modelos utilizados estão: Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-
Tools e Off-the-Shelf.
Bibliografia
Gerald Kotonya ; Ian Sommerville. Requirements Engineering: Processes and Techniques (em Inglês).
[S.l.]: John Wiley & Sons, 1998. 294 p. ISBN 0471972088
Ian Sommerville ; Pete Sawyer. Requirements Engineering: A good practice guide (em Inglês). 1 ed.
[S.l.]: John Wiley & Sons, 1997. 404 p. ISBN 0471974447
Helen Sharp ; Yvonne Rogers ; Jenny Preece. Interaction Design: Beyond Human-computer Interaction
(em Inglês). 2 ed. [S.l.]: John Wiley & Sons, 2002. 519 p. ISBN 0471492787
Ver também
en:Requirements engineering
en:Process Modeling
07/10/12
6/6
en:Data modeling
Ligações externas
Project Lifecycle Models (http://www.business-esolutions.com/islm.htm) : How They Differ and When
to Use Them.
Obtida de "http://pt.wikipedia.org/w/index.php?title=Modelos_ciclo_de_vida&oldid=30168217"
Categoria: Engenharia de software
Esta página foi modificada pela última vez à(s) 17h19min de 14 de maio de 2012.
Este texto é disponibilizado
nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.
plano_de_ensino.pdf
 
 
Disciplina: Processo de Desenvolvimento de Software 
Plano de Ensino 
 
 
Contextualização A área de tecnologia da informação e comunicação traz, a todo o 
momento, modificações, inovações, adequações, enfim, se 
apresenta de forma cada vez mais interessante para o usuário e 
desafiadora para profissional que a constrói. Assim, preparar 
equipes capazes de conceber, planejar e desenvolver soluções que 
funcionarão nas futuras gerações das TICs se apresenta como 
demanda urgente aos cursos da área de tecnologia da informação e 
um desafio às práticas pedagógicas do professor para o ensino da 
computação. 
As notícias veiculadas às mídias brasileiras relatam que o mercado 
de software está em constante mudança, buscando qualidade do 
produto. Dentro desse contexto, entender as etapas do processo de 
desenvolvimento de software, qualificará o profissional para atender 
essa crescente demanda, reduzindo as perdas e dimuindo os custos 
Essa realidade aumenta a importância da disciplina de processo de 
desenvolvimento de software na matriz curricular dos cursos de 
tecnologia da informação. Por essa razão, preparamos o caminho da 
aprendizagem por meio de um conjunto de aulas que priorizarão a 
didática focada na motivação, nas práticas lúdicas, nos exercícios de 
fixação e no material impresso de apoio ao conteúdo de sala de 
aula. Tais cuidados foram tomados para que todos os alunos 
tenham condições de superar suas dificuldade e concluir com 
sucesso a disciplina de processo de desenvolvimento de software. 
 
Ementa Processo de Desenvolvimento de Software: Analises iniciais, ciclo de 
vida de um processo, modelos de processos de desenvolvimento, 
padrões de processos, processo unificado; Ferramentas: RUP, 
PRAXIS. 
Objetivos gerais Conhecer e utilizar ferramentas que auxiliem no desenvolvimento 
de um softtware com base nas metodologias e padrões vigentes. 
Objetivos específicos 1. Conhecer a necessidade de se adotar um processo de 
desenvolvimento de software. 
2. Identificar qual modelo se adapta para cada tipo de 
software. 
 
3. Descrever as fases do processo de desenvolvimento. 
4. Conhecer os principais modelos de qualidade de 
software. 
5. Conhecer as ferramentas mais utilizadas no mercado. 
Conteúdos 
Unidade I – Conceitos Gerais de Processo de 
Desenvolvimento de Software (PDS). 
1. O que é? Para que serve? 
2. Problemas mais comuns. 
 
Unidade II – Atividades em PDS 
1. Análise economica e de requisitos. 
2. Especificação do Software. 
3. Desenho ou Arquitetura do Sistema de Software 
4. Codificação (Implementação) 
5. Teste do Produto 
 
Unidade III – Suporte e Manutenção do Software 
1. Documentação. 
2. Suporte e Treinamento 
3. Melhoria Continua. 
 
Unidade IV – Introdução aos padrões de PDS 
1. CMM / CMMI. 
2. SPICE. 
3. ISO 12207. 
4. MPS/BR. 
 
Unidade V – Modelagem de PDS 
1. Processo Cascata (Water Fall) ou TOP DOWN. 
2. Processo Iterativo. 
3. Processo Ágil. 
 
Unidade VI – Processo Unificado 
1. Fases do Processo. 
2. Ciclo de vida do processo. 
 
 Unidade VII – Ferramentas de PDS 
1. RUP (Rational Unified Process) 
2. PRAXIS 
 
 
Programação extrema – Wikipédia, a enciclopédia livre.pdf
28/10/12 Programação extrema – Wikipédia, a enciclopédia liv re
1/3
Programação extrema
Origem: Wikipédia, a enciclopédia livre.
Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil
para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante
mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes
durante o desenvolvimento de software.
Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e
respeito. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade,
mudanças incrementais, abraçar mudanças e trabalho de qualidade.
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em
escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o
negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão
adiadas ou canceladas.
A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na
produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo
prazo.
Índice
1 Valores
2 Princípios básicos
3 Práticas
4 Livros
Valores
Comunicação
Simplicidade
Feedback
Coragem
Respeito
Princípios básicos
Feedback rápido
Presumir simplicidade
Mudanças incrementais
Abraçar mudanças
Trabalho de alta qualidade.
28/10/12 Programação extrema – Wikipédia, a enciclopédia liv re
2/3pt.wikipedia.org/wiki/Programação_extrema
Práticas
Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas.
Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos
pontos fortes de outras.
Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início
da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o
nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam.
O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai
acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato
de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos
de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e
prontas para serem postas em produção.
Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia
muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está
comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias
incrementais, como o RUP.
Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O
conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente
em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso
traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer
que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema
com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta
funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de
acesso. Um erro comum ao adotar essa
prática é a confusão por parte dos programadores de código
simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais
simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código
fácil deve ser identificado e substituído por código simples.
Time Coeso (Whole Team): A equipe de desenvolvimento é formada por pessoas engajadas e de
forma multidisclipinar (no sentido de incluir pessoas com cada uma das habilidades necessárias para o
projeto).
Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e
testadores, para aceitar um determinado requisito do sistema.
Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho
saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando
trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a
prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de
trabalho e a motivação da equipe devem estar sempre em harmonia.
Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos,
produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar
permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes
do sistema.
Programação em Pares (Pair Programming): é a programação em par/dupla num único computador.
Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um
instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o
instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto
Programação extrema – Wikipédia, a enciclopédia liv re
3/3pt.wikipedia.org/wiki/Programação_extrema
por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a
evolução da equipe, melhorando a qualidade do código fonte gerado.
Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras
para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi
editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários
(unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início,
pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais
para que a qualidade do projeto seja mantida.
Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o
mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar
melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento,
evitando a duplicação de código-fonte;
Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca
esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos
e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da
programação.
Livros
Extreme Programming Explained: Embrace Change (2nd Edition) (ISBN 0321278658)
Planning Extreme Programming (ISBN 0201710919)
Extreme Programming Installed (ISBN 0201708426)
Agile Software Development, Principles, Patterns, and Practices (ISBN 0135974445)
Obtida de "http://pt.wikipedia.org/w/index.php?title=Programação_extrema&oldid=31918373"
Categoria: Desenvolvimento de software
Esta página foi modificada pela última vez à(s) 16h32min de 22 de agosto de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.
Refatoração – Wikipédia, a enciclopédia livre.pdf
28/09/12 Ref atoração – Wikipédia, a enciclopédia liv re
1/3pt.wikipedia.org/wiki/Ref atoração
Refatoração
Origem: Wikipédia, a enciclopédia livre.
Refatoração (do inglês Refactoring) é o processo de modificar um sistema de software para melhorar a
estrutura interna do código sem alterar seu comportamento externo.
O uso desta técnica aprimora a concepção (design) de um software e evita a deterioração tão comum durante
o ciclo de vida de um código. Esta deterioração é geralmente causada por mudanças com objetivos de curto
prazo ou por alterações realizadas sem a clara compreensão da concepção do sistema.
Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de
defeitos. Esta melhora no entendimento vem da constante alteração do código com objetivo de facilitar a
comunicação de motivações, intenções e objetivos por parte do programador.
É fundamental que o sistema de software possua testes automatizados para realizar refatoração. Desta forma,
será possível garantir a que o comportamento externo não foi alterado.
O livro mais importante sobre refatoração é Refactoring: Improving the Design of Existing Code (ISBN 0-
201-48567-2) de Martin Fowler, onde são explicados os conceitos, motivações e uma série de refatorações
descritas passo a passo.
Programação extrema tem refatoração como uma de suas práticas.
Índice
1 Exemplo
2 Utilização
3 Refatorações
4 Ligações externas
Exemplo
O código Java abaixo demonstra a aplicação da refatoração para extrair método (Extract Method).
Antes
 /** Salva o produto no banco de dados. */
 public void save()
 {
 // Verifica propriedades
 if (this.getName() == null)
 {
 throw new Exception("Falta nome");
 }
 else if (this.getDescription() == null)
 {
28/09/12 Ref atoração – Wikipédia, a enciclopédia liv re
2/3pt.wikipedia.org/wiki/Ref atoração
 throw new Exception("Falta a descrição");
 }
 
 this.getDatabase().save(this);
 }
Depois
 /** Salva o produto no banco de dados. */
 public void save()
 {
 this.checkProperties();
 this.getDatabase().save(this);
 }
 
 /** Verifica as propriedades do produto. */
 private void checkProperties()
 {
 if (this.getName() == null)
 {
 throw new Exception("Falta nome do produto.");
 }
 else if (this.getDescription() == null)
 {
 throw new Exception("Falta a descrição do produto.");
 }
 }
Outro exemplo de refatoração, que também utiliza a prática de Desenvolvimento Orientado a Testes
(http://www.improveit.com.br/xp/praticas/tdd) pode ser encontrado no link
http://www.improveit.com.br/xp/praticas/tdd.
Utilização
Kent Beck, um dos criadores da Programação Extrema, afirma que refatoração deve ser utilizada quando o
"código cheirar mal" (do inglês bad smells in code). Este conselho bem humorado indica uma confiança na
experiência de programadores e também ressalta o valor estético do código, que deve valorizar a clareza e
comunicação.
Alguns indícios já possuem uma aceitação ampla para promover refatoração:
Código duplicado (duplicated code)
Método longo (long method)
Classe grande (large class)
Lista de parâmetros longa (long parameter list)
Má indentação(Bad Indentation)
Refatorações
As refatorações descritas no livro de Martin Fowler utilizam fortemente conceitos de orientação a objeto. Basta
observar algumas:
Extrair Método (Extract Method)
Mover Método (Move Method)
Mover Atributo (Move Field')
28/09/12 Ref atoração – Wikipédia, a enciclopédia liv re
3/3pt.wikipedia.org/wiki/Ref atoração
Extrair Classe (Extract Class)
Encapsular Atributo (Encapsulate Field)
Renomear Método (Rename Method)
Subir Método (Pull Up Method)
Subir Atributo (Pull Up Field)
Descer Método (Push Down Method)
Descer Atributo (Push Down Field)
Extrair Sub-classe (Extract Subclass)
Extrair Super-classe (Extract Superclass)
Ligações externas
Refactoring Home (http://www.refactoring.com) mantido pelo próprio Martin Fowler.
Obtida de "http://pt.wikipedia.org/w/index.php?title=Refatoração&oldid=31680365"
Categorias: Engenharia de software Programação orientada a objetos Programação Computação
Esta página foi modificada pela última vez à(s) 03h06min de 4 de agosto de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.
revisaoav2.ppt
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: 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
*
*
*
Aula 6: Implementação
As Aulas
*
*
*
Com relação a fase de implementação, analise as assertivas
Na fase de programação é feito projeto da arquitetura do SW não
As empresas precisam seguir padrões para programar sim
As instruções do programa na LP constituem o código fonte sim
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
Estão corretas as opções I, II e III
Estão corretas as opções II e III
Estão corretas as opções II e IV
Estão corretas as opções I, II e III
Estão corretas as opções III e IV
*
AULA 6
*
*
2. Com relação as linguagens de programação, analise
A linguagem de máquina é uma e linguagem binária é outra, porém há uma relação entre elas falso.
A linguagem assembly dificultou a vida do programador, pois é mais complexa que a linguagem de máquina falso
Um programa em linguagem de alto nível tem menos instruções que o mesmo programa em linguagem de máquina certo
O Montador converte linguagem assembly em linguagem de máquina certo
Com base em sua análise, assinale a opção correta
Estão corretas as opções I, II e III
Estão corretas as opções II e III
Estão corretas as opções III e IV
Estão corretas as opções I e II
*
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
Compilador e montador(elemento transforma assembler em maquina)
Montador e tradutor
Compilador e interpretador
Interpretador e link-editor
*
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
Traduz o código a medida em que o executa ___I___
Traduz o código e depois o executa ____C___
Param quando encontram um erro, na execução ___I___
Tem desempenho menor que o outro processo ___I___
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___
*
AULA 6
*
*
*
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.
*
AULA 6
*
*
*
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
O componente deve ser o mais independente possível (V)
Ganha-se em agilidade com uso de componentes(V)
O custo aumenta com uso de componentes(F)
Aumenta a segurança com o uso de componentes.(V)
9) Sobre a programação em PAR assinale a assertiva Correta:
Dois ou mais programadores trabalham juntos
Um programador é o líder e os demais submissos
Tende a aumentar a incidência de bugs em sistemas
Explora a diversidade de idéias e é útil para treinamento de programadores inexperientes.
*
AULA 6
*
*
Aula 7: Suporte e Manutenção
*
AULA 7
*
*
Com relação a fase de manutenção, assinale a ÚNICA resposta INCORRETA
Inicia quando o usuário começa a usar o sistema.(V)
Termina quando instala-se a 1ª. Versão de correção 
O custo da manutenção historicamente tem sido alto(V)
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
Quanto maior o tempo da fase de manutenção de um sistema, maior será sua vida útil..(F)
Quanto mais qualidade houver no desenvolvimento, mais qualidade tende a ter a manutenção(V)
O grande desafio da manutenção é manter a documentação atualizada(V)
 
*
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 
Estão corretas as opções I, II e III
Estão corretas as opções I e II
Apenas opção II está correta
Apenas opção III está correta.
 
*
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
Efeito dominó (F)(alterar parte do sistema e mexe em outra)
Arquitetura flexível. 
Comportamento linear
Refatoração (V)
5) Dentre as opções abaixo, qual não afeta o custo de manutenção de um sistema
Rotatividade e disponibilidade de pessoal. (afeta o custo) 
Linguagem de programação que poucos conhecem (afeta)
Qualidade do projeto e de sua documentação (afeta)
Ambiente do sistema, que não se modifica. Não afeta o custo
*
AULA 7
*
*
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:
O sistema tem alto acoplamento e coesão
O sistema tem alto acoplamento
e alta coesão
O sistema tem baixo acoplamento e alta coesão
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?
Tratar cada demanda imediatamente após seu relato (F)
Tratar as demandas como um projeto 
Tratar as demandas sempre uma vez ao mês (F)
Tratar apenas as demandas de novas implementações.(F)
*
AULA 7
*
*
8) Com relação as intervenções para atender demandas da fase de manutenção, analise as assertivas abaixo:
Intervenções podem e devem acontecer sempre que necessário (F)
Intervenções causam instabilidade no ambiente (V)
Intervenções devem acontecer de forma controlada (V)
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
Estão corretas apenas I, II e III
Estão corretas apenas II e III
Estão corretas apenas II, III e IV
Estão corretas I e II
*
AULA 7
*
*
9) Com relação ao período que antecedeu o processo de desenvolvimento clássico, NÃO podemos afirmar
Os programadores baseavam-se praticamente em suas experiências, apenas. (V)
Partia-se direto para desenvolver o código em linguagem de programação (V)
Haviam testes de qualidade desde sempre(F)
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
É o mesmo que ciclo de vida(F) é desenvolvimento + manutenção.
É o período que vai da concepção a “morte” do sistema(F) é o ciclo de vida
É o período que inicia com a concepção e termina com a implantação do sistema (V)
Inclui a fase de manutenção(F) não inclui a fase de manutenção
*
AULA 8
*
*
11) Com relação ao modelo em Cascata Clássico, analise as assertivas abaixo
Tipicamente linear, ou seja sequencial e para frente. (V)
Demandava “congelamento” dos requisitos levantados, sem possibilitar novos ou alterações dos iniciais. (V)
Sem padronização e documentação eficiente (V)
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
Estão corretas apenas as opções II e III
Estão corretas apenas as opções I e III
Estão corretas apenas as opções I e II
Estão corretas apenas as opções I, II e III
Estão corretas apenas as opções I, II e IV
*
AULA 8
*
*
12) Analise cada assertiva quanto a ser V ou F
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)
O retrocesso no processo com retroalimentação só acontecia até a fase anterior. (F)
Não prevê manutenção(F)
Facilmente gerenciável, mesmo com os retrocessos a fases anteriores.(F)
Com base em sua análise, marque a correta sequencia de V/ F
V, F, F, F
F,F,F.F,F
V,V,V,F
V,V,F,V
*
AULA 8
*
*
13) Com relação aos processos de desenvolvimento de SW, analise a assertiva falsa
Os projetos não tem características sequencias, como requerido pelos processos em cascata (clássico e com retroalimentação) (V)
Os modelos de processo em cascata não pressupõem o desenvolvimento de todo o sistema, em cada fase. (F)
No processo iterativo o sistema é dividido em várias porções (iterações) (V)
No processo incremental a cada iteração o sistema sofre acréscimo de tamanho , até que fique pronto.(V)
*
AULA 9
*
*
14) Sobre o modelo iterativo-incremental, diga se V ou F
Usa o modelo em cascata para desenvolver cada iteração. (V)
Uma iteração deve começar definindo um conjunto de requisitos do software e termina com sua implantação(V)
O usuário só faz contato com o sistema após a última iteração estar pronta(F)faz contato a cada iteração
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
V,V.V,V
V,V,F,F
V,V,V,F
F,F,V,F
*
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
 
*
AULA 9
*
*
16) Com relação a prototipação, assinale a opção INCORRETA
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)
O produto final é ultimo protótipo gerado. (F)
Pode-se usar protótipos em papel, para que aconteça o mais cedo possível.(V)
É 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.
*
AULA 9
*
*
*
AULA 9
*
*
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)
*
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 
*
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.
*
AULA 10
*
*
Uma instrução da linguagem de alto nível corresponde a várias instruções em linguagem de máquina.
*
LINGUAGEM C – ALTO NÍVEL 
SEMPRE PRECISA DO COMPILADOR OU INTERPRETADOR
PARA PASSAR O MONTADOR PARA A LINGUAGEM DE MONTAGEM (colocar OBJETOS)
LINK EDITOR JUNTA OS OBJETOS NO EXECUTÁVEL
E o loader carregar os executáveis e coloca na memória
*
O compilador gera o código de máquina
*
Acoplamento = dependência entre módulos
É bom que o acoplamento seja menor
*
Intervenção custa dinheiro
*
Slide_111013_081449_62.jpg
Slide_111013_081712_906.jpg
Slide_111013_090830_828.jpg
Slide_111013_090924_546.jpg
Slide_111013_092106_250.jpg