aula23-infibianca/informatica1-20061/index_arquivos/aula23-i… · • linguagens de programação...
TRANSCRIPT
Aula 23 - 05/07/06 1
Informática I
Aula 23
http://www.ic.uff.br/~bianca/informatica1/
Aula 23 - 05/07/06 2
Ementa
• Histórico dos Computadores• Noções de Hardware e Software• Microprocessadores• Sistemas Numéricos e Representação de Dados• Estrutura e Organização da Informação• Linguagens de Programação• Sistemas Operacionais• Redes de Computadores e Internet• Engenharia de Software
• Softwares Aplicativos• Aspectos Legais do Software
Aula 23 - 05/07/06 3
Engenharia de Software
• Surgiu nos anos 1970 como uma tentativa de dar um tratamento mais sistemático e controlado ao desenvolvimento de software.– O desenvolvimento de software é uma tarefa
complexa e portanto precisa ser gerenciado.
• Envolve a especificação, desenvolvimento e manutenção de sistemas de software.– Tem como objetivo produzir softwares de qualidade,
confiáveis e eficientes.– Aplica técnicas de ciência da computação e de
gerência de projetos.
Aula 23 - 05/07/06 4
Processo de Software
• É um roteiro que determina quais são as tarefas necessárias e em que ordem elas devem ser executadas para construir softwares de alta qualidade.
• Ele organiza uma atividade que pode, sem controle, tornar-se caótica.
• O processo adotado deve ser adaptado ao tipode software que se está construindo.– Software para aeronave vs. Software para internet.
Aula 23 - 05/07/06 5
Processo de software é a mesma coisa que engenharia de software?
• Sim e não: a engenharia de software também inclui as tecnologias que são utilizadas no processo, como métodos técnicos e ferramentas automatizadas.
Processo
Métodos
Ferramentas
Foco na qualidade
Engenharia de Software em Camadas
Aula 23 - 05/07/06 6
Um arcabouço de processo
• É o alicerce ou esqueleto de um processo de software completo.
• Contém as atividades de arcabouço que são aplicáveis a todos os projetos de software.
• Engloba um conjunto de atividades guarda-chuvaque são exercidas durante todo o processo.
Processo de Software
Arcabouço de Processo
Atividades guarda-chuva
atividade de arcabouço 1
atividade de arcabouço 2
Ação 1.1..Ação 1.k
Ação 1.1..Ação 1.k
.
.
Aula 23 - 05/07/06 7
Um processo genérico• Atividades de arcabouço aplicáveis à maioria
dos projetos de software:1. Comunicação: levantamento de requisitos em
colaboração com o cliente.2. Planejamento: descreve as tarefas, os riscos, os
recursos, os produtos e um cronograma.3. Modelagem: criação de modelos que permitam ao
desenvolvedor entender melhor o projeto e seus requisitos. Ações:• Análise – modelos de especificação de requisitos.• Projeto – modelos de especificação de projeto.
4. Construção: geração de código e testes.5. Implantação: entrega do software ao cliente.
Aula 23 - 05/07/06 8
Um processo genérico
• Atividades guarda-chuva típicas que ocorrem ao longo de um processo:– Acompanhamento e controle do projeto de software.– Gestão de risco.– Garantia de qualidade de software.– Revisões técnicas formais.– Medição.– Gestão de configuração de software.– Gestão de reusabilidade.– Preparação e produção do produto de trabalho.
Aula 23 - 05/07/06 9
Modelos Prescritivos de Processo
• Um modelo prescritivo de processo preencheum arcabouço de processo com conjuntos explícitos de tarefas.
• Cada modelo prescritivo de processo também prescreve um fluxo de trabalho = maneiro como os elementos de inter-relacionam.
• Todos os modelos acomodam as atividades genéricas de arcabouço, mas diferem na ênfasee no fluxo.
Aula 23 - 05/07/06 10
Tipos de Modelo de Processo
• Modelo em Cascata• Modelo Incremental• Modelo RAD• Modelos Evolucionários
– Modelo de Prototipagem
– Modelo Espiral
• Modelo baseado em componentes
Aula 23 - 05/07/06 11
Modelo em Cascata
• Também chamado de ciclo de vida clássico.
• Sugere uma abordagem sistemática e seqüencial para o desenvolvimento de software.
Comunicação
Planejamento
Modelagem
Construção
Implantação
Aula 23 - 05/07/06 12
Modelo em Cascata
• É o paradigma mais antigo da Engenharia de Software.• Nas últimas décadas, têm surgido críticas quanto a sua
eficácia.– Projetos reais raramente seguem o fluxo seqüencial.– É difícil estabelecer todos os requisitos inicialmente.– Uma versão executável do software só fica disponível no final do
processo.– Estados de bloqueio: membros da equipe ficam esperando
outros membros terminarem a sua parte.
• É adequado quando os requisitos são bem entendidos, como em aperfeiçoamentos de um sistema existente.
Aula 23 - 05/07/06 13
Modelo Incremental
• Combina elementos do modelo em cascata aplicados de maneira iterativa.
Aula 23 - 05/07/06 14
Modelo Incremental
• Cada seqüência produz incrementos do software passíveis de serem entregues.– Fornecem progressivamente mais funcionalidade.
• O primeiro incremento é chamado de núcleo de produto.
• O modelo incremental é particularmente útil quando não há mão-de-obra/recursos disponíveis para uma implementação completa.
Aula 23 - 05/07/06 15
Modelo RAD(Rapid Application Development)
• Enfatiza um ciclo de desenvolvimento curto, com o uso de uma abordagem de construção baseada no uso de componentes.
• O planejamento é essencial, porque equipes trabalham em paralelo em diferentes funções do sistema.
Aula 23 - 05/07/06 16
Modelo RAD
Aula 23 - 05/07/06 17
Modelo RAD
• Recomendável quando uma aplicação pode ser modularizada.
• Desvantagens do modelo RAD:– Exige pessoal suficiente para criar várias equipes
RAD.– Desenvolvedores e clientes têm que estar
comprometidos com atividades rápidas.– Exige que o sistema seja modularizável.– Não é adequado quando os riscos técnicos são altos.
Aula 23 - 05/07/06 18
Modelos Evolucionários
• São explicitamente projetados para acomodar um produto que evolui com o tempo.
• A cada iteração, produzem uma versão melhor e mais completa do software.
• Exemplos:– Modelo de Prototipagem– Modelo Espiral– Modelo de Desenvolvimento Concorrente.
Aula 23 - 05/07/06 19
Modelo de Prototipagem
• Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos.
• Mais comumente usado como uma técnica que pode ser implementada dentro de qualquer modelo.
• Protótipo: versão preliminar do software– Pode ser um programa ou no papel– Concentra-se na representação dos aspectos do
software que são visíveis para o cliente.• Lay-out da interface• Entradas e saídas
Aula 23 - 05/07/06 20
Modelo de Prototipagem
Aula 23 - 05/07/06 21
Modelo de Prototipagem
• Problemas:– Pode haver pressão do cliente para transformar um
protótipo mal-feito em produto final resultando em baixa qualidade.
– Concessões na implementação podem fazer com que o desenvolvedor fique familiarizado com escolhas não ideais.
• O cliente tem que concordar que o protótipo será usado apenas para levantar requisitos.– O software real será desenvolvido com olho na
qualidade.
Aula 23 - 05/07/06 22
Modelo Espiral
• Combina a natureza interativa da prototipagem com os aspectos controlados do modelo em cascata.
• O software é produzido em uma série de versões evolucionárias.– Primeiras versões só no papel.
• É uma abordagem cíclica que aumenta incrementalmente o grau de definição, enquanto diminui o risco.
• O modelo pode ser aplicado ao longo de todo o ciclo de vida de uma aplicação.
Aula 23 - 05/07/06 23
Modelo Espiral
Aula 23 - 05/07/06 24
Modelo Espiral
• É uma abordagem realista do desenvolvimento de software
• Problemas:– Pode ser difícil convencer os clientes de que
a abordagem é controlável.– A gerência pode exigir orçamento fixo, o que
não é compátivel com o modelo espiral.
– Exige competência na avaliação de riscos.
Aula 23 - 05/07/06 25
Comparação
Modelo Incremental
• Atividades fixas do modelo em cascata são usadas em cada incremento.
• Objetiva a elaboração de um produto operacional a cada incremento, que pode ser testado.
Modelo Espiral
• As atividades não são fixas, cada “loop” se concentra mais em uma determinada atividade.
• A análise de riscos é uma atividade essencial no modelo.
Aula 23 - 05/07/06 26
Desenvolvimento Baseado em Componentes
• Compõe aplicações a partir de componentesde software previamente preparados.
• Segue os seguintes passos implantados com uma abordagem evolucionária:1. Pesquisa e avaliação de componentes disponíveis
para o domínio em questão.2. Considerações sobre a integração de componentes.3. Projeto de arquitetura de software.4. Integração dos componentes à arquitetura.5. Testes para garantir a funcionalidade adequada.
Aula 23 - 05/07/06 27
Vantagens do desenvolvimento baseado em componentes
• Leva ao reuso de software, que segundo estudos tem como consequências:– Redução significativa do prazo de desenvolvimento.– Redução significativa no custo do projeto.– Aumento do índice de produtividade.
• Em que situações o desenvolvimento baseado em componentes não é adequado?– Aquelas em que não existam componentes padrão
disponíveis ou em que não se queira pagar pelos componentes.