Aula 21 - 29/11/06 1

Informática I

Aula 21

http://www.ic.uff.br/~bianca/informatica1/

Aula 21 - 29/11/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 21 - 29/11/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 21 - 29/11/06 4

Engenharia de Software

• A engenharia de software abrange três elementos principais:– Processos: determinam quais são as tarefas

necessárias e em que ordem elas devem ser executadas.

– Métodos: fornecem detalhes fundamentais de como fazer para executar as tarefas necessárias.

• Métodos de planejamento, métodos de análise dos requisitos, métodos de projeto, métodos de codificação, etc.

– Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos processos e métodos.

• Chamadas de ferramentas CASE (computer-aided software engineering). Ex: Rational Rose

Aula 21 - 29/11/06 5

Um processo genérico• Atividades aplicáveis à maioria dos projetos

de software:1. Comunicação: levantamento de requisitos em

colaboração com o cliente.2. Planejamento: estabelece 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 21 - 29/11/06 6

Um processo genérico

• Atividades 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 21 - 29/11/06 7

Modelos Prescritivos de Processo

• Um modelo prescritivo de processo determina as atividades que serão realizadas durante o desenvolvimento de software.

• Cada modelo prescritivo de processo também prescreve um fluxo de trabalho = maneira como as atividades se inter-relacionam.

• Todos os modelos acomodam de alguma forma as atividades genéricas, mas diferem na ênfasee no fluxo.

Aula 21 - 29/11/06 8

Tipos de Modelo de Processo

• Modelo em Cascata• Modelo Incremental• Modelo RAD• Modelos Evolucionários

– Modelo de Prototipagem

– Modelo Espiral

• Modelo baseado em componentes• Desenvolvimento ágil

Aula 21 - 29/11/06 9

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 21 - 29/11/06 10

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 21 - 29/11/06 11

Modelo Incremental

• Combina elementos do modelo em cascata aplicados de maneira iterativa.

Aula 21 - 29/11/06 12

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 21 - 29/11/06 13

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 21 - 29/11/06 14

Modelo RAD

Aula 21 - 29/11/06 15

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 21 - 29/11/06 16

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 21 - 29/11/06 17

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 21 - 29/11/06 18

Modelo de Prototipagem

Aula 21 - 29/11/06 19

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 21 - 29/11/06 20

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 21 - 29/11/06 21

Modelo Espiral

Aula 21 - 29/11/06 22

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 21 - 29/11/06 23

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 21 - 29/11/06 24

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 21 - 29/11/06 25

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.

Aula 21 - 29/11/06 26

Desenvolvimento Ágil

• 2001: Manifesto para o Desenvolvimento Ágil de Software (http://www.agilemanifesto.org).– 17 figuras proeminentes na engenharia de software

(a Aliança Ágil) se reuniram e declararam importante a valorização de:

• Indivíduos e interações em vez de processos e ferramentas.

• Softwares funcionando em vez de documentação abrangente.

• Colaboração do cliente em vez de negociação de contratos.

• Resposta a modificações em vez de seguir um plano.

Aula 21 - 29/11/06 27

O que é o desenvolvimento ágil?

• É uma filosofia e um conjunto de diretrizes que encorajam: – A entrega incremental do software logo de

início.– Equipes de projeto pequenas e motivadas.– Métodos informais de comunicação ao invés

de documentos escritos.– Enfatizar a entrega em contraposição à

análise e ao projeto.– Adotar o cliente como parte da equipe.

Aula 21 - 29/11/06 28

Quando deve ser usado o desenvolvimento ágil?

• O desenvolvimento ágil é particularmente indicado em situações onde os requisitos são imprevísiveis ou mudam rapidamente.

• Ele funciona melhor para equipes pequenas (até 10 desenvolvedores) trabalhando no mesmo local.

Aula 21 - 29/11/06 29

Modelos ágeis de processo

• Extreme Programming (XP)• Desenvolvimento Adaptativo de Software

(DAS)• Método de Desenvolvimento Dinâmico de

Sistemas (DSDM)• Scrum• Crystal• Desenvolvimento Guiado por Características

(FDD)• Modelagem Ágil (AM)

Aula 21 - 29/11/06 30

Extreme Programming (XP)

• Trabalho pioneiro sobre o assunto escrito em 1999 por Kent Beck.

• Usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento.

• Inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades de arcabouço:– Planejamento– Projeto– Codificação– Teste

Aula 21 - 29/11/06 31

XP - Planejamento• Criação de um conjunto de histórias de usuário.

– Cada história é escrita em poucas linhas pelos clientes, que lheatribuem um valor, e deve poder ser implementadas em menos de três semanas.

– Exemplo: “Quando a aplicação começa, o último documento em que o cliente estava trabalhando deve ser aberto automaticamente.”

• A equipe XP e os clientes trabalham juntos para definir um planoque determina as histórias que serão desenvolvidas primeiro levando em consideração valores e riscos.

• Depois que o primeiro incremento é entregue, a equipe XP calcula a velocidade do projeto = número de histórias implementadas.

• Ao longo do tempo, o cliente pode adicionar histórias, mudar o valor de uma história, subdividir histórias ou eliminá-las,

Aula 21 - 29/11/06 32

XP - Projeto

• Segue o princípio KIS (keep it simple).– Se restringe a implementar as histórias de usuário.

• Usa cartões CRC (Class-Responsability-Colaborator) para identificar e organizar as classes que são relevantes para o incremento atual.

• Se um problema de projeto difícil é encontrado, o XP recomenda a criação de uma solução de ponta para diminuir o risco.– Solução de ponta = um protótipo operacional daquela parte do

projeto, que depois será descartado.• O XP encoraja a refabricação = modificar o sistema de tal

modo que o comportamento externo não seja alterado, mas aperfeiçoe a estrutura interna.– A refabricação ocorre durante a codificação, mas altera o projeto.

Aula 21 - 29/11/06 33

XP - Codificação

• Antes de partir para o código, a equipe deve desenvolver testes unitários para verificar a funcionalidade que será desenvolvida.

• A programação é feita em pares. – Isso fornece um mecanismo de solução de problemas e de

garantia de qualidade em tempo real.– Uma pessoa pensa nos detalhes do código enquanto a outra

garante as normas de codificação e que o código gerado vai se encaixar no resto do sistema.

• O código gerado vai sendo integrado imediatamente ao trabalho de outros, o que ajuda a evitar problemas de compatibiilidade e interface.

Aula 21 - 29/11/06 34

XP - Teste

• Os testes unitários são criados de tal forma que eles possam ser automatizados, e aplicados diariamente.

• O XP usa uma estratégia de teste de regressão: testes são aplicados de novo mesmo que anteriormente eles não tenham apresentado problema.– Isso permite a refabricação.

• Testes de aceitação são especificados pelo cliente (derivados das histórias do usuário) e focalizam nas características e funcionalidades do sistema global.– Devem ser automatizados e aplicados frequentemente.– O sistema só é considerado aceitável quando todos passar em

todos os testes de aceitação.