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.