View
6.167
Download
2
Category
Preview:
DESCRIPTION
Desenvolvimento rápido de software. Unidade de Engenharia do Software I para o curso de METI no ISCTE-IUL no 2.º semestre do ano lectivo de 2009/2010.
Citation preview
ENGENHARIA DO SOFTWARE I
Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
Manuel.Sequeira@iscte.pt, D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de
Sequeira.
Engenharia do Software I 2
Na aula anterior
Processos de softwareModelos de processos de softwareIteração de processosActividades de processoRUP (Rational Unified Process)CASE (Computer-Aided Software
Engineering)
2009/2010
Engenharia do Software I 3
Desenvolvimento Rápido de Software
2009/2010
Engenharia do Software I 4
Sumário
Desenvolvimento rápido de softwareMétodos ágeisXP (Extreme Programming)Desenvolvimento rápido de aplicações
(RAD)Prototipagem de software
2009/2010
Engenharia do Software I 5
Objectivos Explicar como processo de desenvolvimento iterativo
e incremental leva a entregas mais rápidas do software e a software mais útil
Discutir essência de métodos ágeis de desenvolvimento
Explicar princípios e práticas do Extreme Programming
Explicar papéis da prototipagem no processo de software
2009/2010
Engenharia do Software I 6
Desenvolvimento rápido de software Alterações rápidas do contexto dos negócios
obrigam empresas a responder a novas oportunidades e à competição
Necessário software e seu rápido desenvolvimento
Empresas podem estar dispostas a aceitar software de menor qualidade se isso tornar possível a entrega rápida de funcionalidades essenciais
2009/2010
Engenharia do Software I 7
Requisitos Contexto em alteração impossibilita
conjunto estável e consistente de requisitos de sistema
Modelo de desenvolvimento em cascata impraticável
Entrega rápida de software possível apenas com desenvolvimento baseado em especificação e entrega iterativas
2009/2010
Engenharia do Software I 8
Características de processos RAD Especificação, desenho e
implementação são processos concorrentes
Sem especificação pormenorizada
Documentação mínima
2009/2010
Engenharia do Software I 9
Características de processos RAD Sistema desenvolvido numa série de
incrementos
Utilizadores finais avaliam cada incremento e fazem propostas para incrementos posteriores
Interfaces de utilização usualmente desenvolvidas usando sistema de desenvolvimento iterativo
2009/2010
10Engenharia do Software I
Um processo de desenvolvimento iterativo
Definir entregáveis
Desenhar arquitectura
Especificar incremento
Construir incremento
Validar incremento
Integrar incremento
ValidarEntregar
sistema finalCompleto
?
não
sim
2009/2010
Engenharia do Software I 11
Vantagens do desenvolvimento incrementalEntrega acelerada de serviços ao cliente
Cada incremento entrega ao cliente a funcionalidade com maior prioridade.
Maior comprometimento dos utilizadores com o sistema
Os utilizadores têm de ser envolvidos no desenvolvimento, o que significa que é mais provável que o sistema cumpra os seus requisitos e que os utilizadores se comprometam mais com o sistema.
2009/2010
Engenharia do Software I 12
Problemas do desenvolvimento incrementalProblemas de gestão Progresso pode ser difícil de avaliar e
problemas podem ser difíceis de descobrir, uma vez que não há documentação que demonstre o que já foi realizado.
Problemas contratuais
O contrato normal pode incluir a especificação. Sem especificação, formas diferentes de contrato têm de ser usadas.
Problemas de validação
Sem uma especificação, em relação a quê se testa o sistema?
Problemas de manutenção
Mudanças contínuas tendem a corromper a estrutura do software, tornando-o mais oneroso de alterar e de fazer evoluir de modo a cumprir novos requisitos.
2009/2010
Engenharia do Software I 13
PrototipagemDesenvolvimento e entrega iterativos e incrementais
Pode ser impraticável para sistemas de grande dimensão, especialmente quando há múltiplas equipas trabalhando em múltiplos locais.
Prototipagem descartável
É uma possibilidade. Desenvolve-se um sistema experimental como base para formular os requisitos. Este sistema é descartado assim que a especificação do sistema tenha sido acordada.
2009/2010
14Engenharia do Software I
Desenvolvimento incremental e prototipagem
Visão geral dos requisitos
Desenvolvimento incremental
Prototipagem descartável
Sistema entregue
Protótipo executável e especificação do
sistema
2009/2010
Engenharia do Software I 15
Diferentes objectivosDesenvolvimento incremental
Entregar aos utilizadores finais um sistema funcional. Desenvolvimento começa pelos requisitos mais importantes.
Prototipagem descartável
Validar ou derivar os requisitos do sistema. Processo de prototipagem começa pelos requisitos pior compreendidos.
2009/2010
Engenharia do Software I 16
Métodos ágeis Insatisfação com custos fixos associados a
métodos de desenho levou a métodos ágeisFoco no código e não no desenhoCom abordagem iterativa ao desenvolvimentoCom objectivo de entregar e fazer evoluir
rapidamente o software
Provavelmente melhor adequados a sistemas empresariais de pequena e média dimensão ou a produtos para computador pessoal
2009/2010
Engenharia do Software I 17
Princípios dos métodos ágeis Envolvimento do cliente
Cliente envolvido ao longo do processo de desenvolvimento. Seu papel é disponibilizar e prioritizar novos requisitos do sistema e avaliar iterações do sistema.
Entrega incremental
Software desenvolvido em incrementos com o cliente a especificar que requisitos incluir em cada incremento.
Pessoas e não processos
Competências da equipa de desenvolvimento reconhecidas e exploradas. Equipa desenvolve as suas próprias formas de trabalho sem que se prescrevam processos.
Abrace a mudança
Devem esperar-se mudanças nos requisitos do sistema e deve desenhar-se sistema de modo a acomodar mudanças.
Mantenha a simplicidade
Enfoque na simplicidade, quer no software em desenvolvimento, quer no processo de desenvolvimento usado. Sempre que possível contribuir para eliminar complexidade do sistema.
2009/2010
Engenharia do Software I 18
Problemas dos métodos ágeis
Pode ser difícil manter interesse dos clientes envolvidos
Membros da equipa podem não ser adequados a envolvimento intenso de métodos ágeis
Prioritização de mudanças pode ser difícil com múltiplas partes interessadas
Manter simplicidade requer trabalho adicional
Contratos podem ser problemáticos, tal como noutras abordagens a desenvolvimento iterativo
2009/2010
Engenharia do Software I 19
XP (Extreme Programming) Método ágil mais conhecido e usado?
Abordagem “extrema” a desenvolvimento iterativoNovas versões podem ser construídas múltiplas
vezes por diaEntrega de incrementos a clientes cada duas
semanasTodos os testes executados em todas as
construções; construções aceites se testes executarem com sucesso
2009/2010
20Engenharia do Software I
Ciclo de entregas do XP
2009/2010
Seleccionar estórias do utilizador para
esta entrega
Dividir estórias em tarefas
Planear entrega
Entregar sistema
Avaliar sistemaDesenvolver,
integrar e testar software
Engenharia do Software I 21
Práticas do XPPlaneamento incremental
Registam-se requisitos em Cartões de Estórias e determinam-se estórias a incluir numa entrega segundo tempo disponível e prioridade relativa. Dividem-se estórias em tarefas de desenvolvimento.
Pequenas entregas
Desenvolve-se primeiro conjunto mínimo de funcionalidades que fornecem valor ao negócio. Entregas do sistema frequentes incrementam funcionalidades.
Desenho simples
Desenha-se apenas o necessário para cumprir requisitos correntes. Nada mais.
Testes primeiro Usa-se infra-estrutura de testes unitários para desenvolver testes para cada nova funcionalidade antes mesmo de a implementar.
Refactorização Espera-se que todos os desenvolvedores refactorizem o código sempre que depararem com possíveis melhorias, de modo a manter o código simples e mantenível.
2009/2010
Engenharia do Software I 22
Práticas do XPProgramação em pares
Desenvolvedores trabalham aos pares, verificando trabalho um do outro e suportando realização de um bom trabalho.
Propriedade colectiva
Pares trabalham em todos o sistema. Não há ilhas de perícia. Todos possuem todo o código que todos podem alterar.
Integração contínua
Logo que trabalho em tarefa termina, integra-se no sistema completo. Depois de qualquer integração, todos os testes unitários têm de executar com sucesso.
Ritmo sustentável
Não se aceita muito trabalho para além do tempo normal: reduz qualidade do código e produtividade a médio prazo.
Cliente in situ Representante do utilizador final do sistema (Cliente) disponível a tempo inteiro para equipa XP. Cliente é membro da equipa de desenvolvimento responsável por disponibilizar requisitos para equipa implementar.
2009/2010
Engenharia do Software I 23
Princípios XP e ágeis Entregas pequenas e frequentes suportam
desenvolvimento incremental
Cliente a tempo inteiro com equipa
Ênfase em pessoas e não processos Programação em pares Propriedade colectiva Processo que evita tempo excessivo de trabalho
Entregas regulares suportam mudança
Refactorização contínua sustenta simplicidade
2009/2010
Engenharia do Software I 24
Cenários de requisitos em XP Requisitos do utilizador expressos como
cenários ou estórias de utilizador
Estórias escritas em cartões e divididas em tarefas de implementação por equipa de desenvolvimento
Estórias usadas para estimar custos e esforço
Cliente escolhe estórias para entrega seguinte de acordo com prioridades e esforços estimados
2009/2010
Engenharia do Software I 25
Cartão de estória para descarregamento de documentoDescarregamento e impressão de um artigo
O utilizador selecciona o artigo desejado a partir da lista que lhe for mostrada. Depois diz ao sistema como deseja pagar: através de uma assinatura, de uma conta empresarial ou usando cartão de crédito.
De seguida, o sistema pede ao utilizador para preencher um formulário de direitos de autor. Depois de submetido o formulário, o artigo desejado é descarregado para o computador do utilizador.
O utilizador escolhe uma impressora e uma cópia do artigo é impressa. O utilizador informa o sistema acerca do sucesso da impressão.
Se o artigo estiver marcado apenas para impressão, o utilizador não poderá preservar a versão PDF, sendo ela removida automaticamente do seu computador.
2009/2010
Engenharia do Software I 26
XP e mudança “Desenhar para a mudança” é senso comum:
investir tempo e esforço antecipando alterações é proveitoso, pois reduzirá custos futuros no ciclo de vida do sistema
XP acha que não vale a pena: alterações não são antecipáveis com confiança
XP propõe melhoria contínua do código (refactorização): alterações mais fáceis quando implementadas
2009/2010
Engenharia do Software I 27
Testes em XP Desenvolvimento com testes primeiro
Desenvolvimento incremental de testes partindo de cenários
Envolvimento do utilizador no desenvolvimento e validação de testes
Sistemas de teste automático para executar todos testes de componentes sempre que nova entrega é construída
2009/2010
Engenharia do Software I 28
Cartões de tarefa para descarregamento de documentoTarefa 1: Implementar fluxo de trabalho principal
2009/2010
Tarefa 2: Implementar catálogo de artigos e selecção de artigo
Tarefa 3: Implementar recolha de pagamento
O pagamento pode ser realizado de três formas diferentes. O utilizador escolhe de que forma pretende pagar. Se o utilizador tiver uma assinatura, então pode introduzir a respectiva chave, que será verificada pelo sistema. Alternativamente, pode introduzir um número de conta organizacional. Se o número for válido, o preço do artigo será debitado nessa conta. Finalmente, pode introduzir o número do cartão de crédito, com 16 dígitos, e a sua data de validade. Estes dados serão validados e, se válidos, será enviado um débito para a conta do cartão de crédito.
Engenharia do Software I 29
Descrição de caso de testeTeste 4: Verificar validade do cartão de crédito
Entrada: Cadeia de caracteres representando o número do cartão de crédito e dois inteiros representando o mês e o ano limites da validade do cartão.
Testes:• Verificar que todos os caracteres da cadeia são dígitos.• Verificar que o mês tem valor entre 1 e 12 e que o mês e ano de validade são
posteriores ou iguais ao mês e ano correntes.• Usando apenas os primeiros quatro dígitos do número do cartão de crédito,
verificar, consultando a tabela de emissores de cartões, que a entidade emissora é válida.
• Verificar validade do cartão submetendo o seu número e data de validade à entidade emissora.
Saída:OK ou mensagem de erro indicando que o cartão é inválido.
2009/2010
Hmmmm….
Engenharia do Software I 30
Desenvolvimento com testes primeiro Escrever testes antes do código clarifica os
requisitos a implementar
Testes escritos de forma a se poderem executar automaticamente e não na forma de dados
Testes reportam seu resultado
Testes passados e novos testes executados quando se adiciona nova funcionalidade, verificando-se se se introduziu algum erro
2009/2010
Engenharia do Software I 31
Programação em pares Programadores aos pares, sentando-se juntos durante
desenvolvimento
Favorece sentimento de posse comum do código e dissemina conhecimento
Processo de revisão informal: código visto por mais que uma pessoa
Encoraja refactorização: equipa toda beneficia
Experiências sugerem que produtividade de desenvolvimento é semelhante a trabalho individual
2009/2010
Engenharia do Software I 32
Desenvolvimento rápido de aplicações Métodos ágeis têm recebido muita atenção,
mas há outras abordagens ao RAD em uso há muitos anos
Essas abordagens foram desenhadas para desenvolver aplicações empresariais data-intensive
Baseiam-se em programação e apresentação de informação a partir de uma base de dados
2009/2010
Engenharia do Software I 33
Ferramentas RAD
Linguagens de programação de bases de dados
Geradores de interfaces
Ligações a aplicações de escritório
Geradores de relatórios
2009/2010
Engenharia do Software I 34
Prototipagem de software Protótipo: versão inicial do sistema para
demonstrar conceitos e experimentar opções de desenho
Pode usar-seProcesso de engenharia de requisitos: ajuda
eliciação e validação de requisitosProcessos de desenho: ajuda explorar opções e
desenvolver design da interface com utilizadorProcesso de testes: executar testes
comparativos (back-to-back)
2009/2010
Engenharia do Software I 35
Benefícios da prototipagem Melhor usabilidade do sistema
Melhor correspondência com necessidades reais dos utilizadores
Melhor qualidade do desenho
Melhor manutenibilidade
Menor esforço de desenvolvimento
2009/2010
36Engenharia do Software I
Testes comparativosDados de teste
Protótipo do sistema
Sistema
Relatório das diferenças
2009/2010
Comparador de resultados
37Engenharia do Software I
Processo de prototipagem
2009/2010
Estabelecer objectivos
Definir funcionalidade
Desenvolver Avaliar
Plano de prototipagem
Definição da estrutura geral
Protótipo executável
Relatório de avaliação
Engenharia do Software I 38
Protótipos descartáveis
Protótipos descartados depois de desenvolvidos: não são boa base para sistema de produçãoPode ser impossível ajustar sistema para
cumprir requisitos não funcionaisProtótipos normalmente não documentadosEstrutura de protótipos usualmente
degradada devido a alterações rápidasProtótipo provavelmente não cumpre
normas de qualidade da organização
2009/2010
Engenharia do Software I 39
A reter Abordagem iterativa a desenvolvimento de software leva a
entregas mais rápidas
Métodos ágeis são métodos de desenvolvimento iterativo destinados a reduzir custos fixos de desenvolvimento e assim a produzir software mais rapidamente
XP inclui práticas como testes sistemáticos, melhoria contínua e envolvimento do cliente
A abordagem aos testes no XP é uma das suas forças; testes executáveis desenvolvidos antes da escrita do código
2009/2010
Engenharia do Software I 40
A reter Protótipos descartáveis usados para
explorar requisitos e opções de desenho
Ao implementar protótipo descartável, começar com requisitos menos compreendidos
No desenvolvimento incremental, começar com requisitos mais compreendidos
2009/2010
A ler
Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006
Capítulo 17
2009/2010 41Engenharia do Software I
Recommended