Informática I Aula 21 http://www.ic.uff.br/~bianca/informatica1/ Aula 21-29/11/06 1
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 2
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 3
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 4
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 5
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 6
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 ênfase e no fluxo. Aula 21-29/11/06 7
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 8
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 9
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 10
Modelo Incremental Combina elementos do modelo em cascata aplicados de maneira iterativa. Aula 21-29/11/06 11
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 12
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 13
Modelo RAD Aula 21-29/11/06 14
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 15
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 16
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 17
Modelo de Prototipagem Aula 21-29/11/06 18
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 19
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 20
Modelo Espiral Aula 21-29/11/06 21
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 22
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 23
Desenvolvimento Baseado em Componentes Compõe aplicações a partir de componentes de 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 24
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 25
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 26
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 27
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 28
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 29
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 30
XP - Planejamento Criação de um conjunto de histórias de usuário. Cada história é escrita em poucas linhas pelos clientes, que lhe atribuem 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 plano que 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 31
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 32
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 33
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. Aula 21-29/11/06 34