Engenharia de Software
Prof. Wilkerson de L. Andrade
Versão resumida e traduzida dos slides originais produzidos por Ian Sommerville, Software Engineering, 7th edition. Chapter 17.
Estes slides foram adaptados dos slides gentilmente cedidos pela professora Patrícia D. L. Machado (DSC/UFCG).
Desenvolvimento Rápido de
Software (RAD)
• Devido a ambientes de negócio sofrerem mudanças constantes, negócios precisam lidar efetivamente com novas oportunidades e competição.
• Neste sentido, desenvolvimento e entrega rápida são fatores críticos.
• Negócios podem aceitar software de baixa qualidade se entrega rápida de
funcionalidade essencial for possível e necessária.
RAD e Requisitos
• Devido às mudanças no ambiente, é
usualmente impossível atingir um nível alto de estabilidade em um conjunto consistente de requisitos.
• Desta forma, um modelo cascata é inadequado. Uma abordagem para o
desenvolvimento iterativo pode ser a única forma de entregar o software dentro das
Características de Processos de RAD
• Processos de especificação, design e
implementação são concorrentes. Não existe especificação detalhada e documentação de projeto é minimizada.
• O sistema é desenvolvido como uma série de incrementos. Usuários avaliam cada
incremento e propõem novos incrementos.
• Interfaces de usuário são usualmente desenvolvidas usando desenvolvimento interativo.
Problemas de RAD
• Problemas de Gerenciamento
▫ É difícil medir progresso e encontrar problemas, pois não
existe documentação para demonstrar o que tem sido feito.
• Problemas de Contrato
▫ Sem uma especificação, formas alternativas de contrato
precisam ser usadas.
• Problemas de Validação
▫ Sem uma especificação fica mais difícil testar o sistema.
• Problemas de Manutenção
▫ Modificações contínuas tendem a corromper a estrutura
do software, aumentando os custos para modificação e evolução.
Métodos Ágeis
• Motivados pelos custos associados a
aplicação de métodos convencionais de design:
▫ Enfoque em código ao invés de design;
▫ Abordagem iterativa para desenvolvimento de
software;
▫ Voltados a entrega e evolução rápida de software.
• Provavelmente mais adequados a sistemas de pequeno/médio porte.
Princípios de Métodos Ágeis
Princípio Descrição
Customer involvement Clientes devem ser profundamente envolvidos no processo de desenvolvimento. Seu papel é fornecer e priorizar novos
requisites do sistema e avaliar as iterações do sistema.
Incremental delivery O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento.
People not process As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar em processos prescritivos.
Embrace change Tenha em mente que os requisitos vão mudar, por isto projete o sistema para acomodar estas mudanças.
Maintain simplicity Concentre-se na simplicidade do software que está sendo desenvolvido e do processo de desenvolvimento. Sempre que possível, trabalhe ativamente para eliminar a complexidade do sistema.
Envolvimento do cliente
Entrega incremental
Pessoas, não processo
Expectativa de mudanças
Problemas com Métodos Ágeis
• Dificuldade em manter o interesse de clientes
envolvidos no processo.
• Membros da equipe podem não ter as
habilidades/motivações necessárias para o
envolvimento intenso que caracteriza métodos ágeis.
• Priorização de mudanças pode ser dificultada,
considerando vários stakeholders.
• Manter simplicidade requer trabalho extra.
Extreme Programming (XP)
• Método ágil mais conhecido e utilizado.
• Abordagem extrema de um processo iterativo:
▫ Novas versões podem ser construídas várias
vezes por dia;
▫ Incrementos são entregues a clientes a cada 2
semanas;
▫ Todos os testes precisam ser executados para
cada versão operacional do software (build) e apenas aceita se os testes passam.
Ciclo de Release de XP
Selecionar user
stories para esta
versão Quebrar as user stories em tarefas Planejar versão/release Desenvolver/ integrar/testar software Liberar software Avaliar o sistema
XP: Práticas 1
Planejamento Incremental
Os requisitos são registrados em cartões de histórias e as histórias a serem incluídas em um release são determinadas pelo tempo disponível e sua prioridade relativa.
Pequenos releases O conjunto mínimo útil de funcionalidades que agrega valor ao negócio é desenvolvido primeiro. Releases do sistema são
freqüentes e adicionam funcionalidade de forma incremental ao primeiro release.
Design simples É realizado um design suficiente para atender aos requisitos atuais e nada mais
Test first development Um framework automatizado de teste de unidade é usado para escrever os testes para uma nova parte da funcionalidade antes que esta seja implementada.
Refactoring Espera-se que todos os desenvolvedores recriem o código continuamente tão logo os aprimoramentos do código forem encontrados. Isso torna o código mais simples e fácil de manter.
XP: Práticas 2
Desenvolvedores trabalham em pares, um checando o trabalho do outro e possibilitando sempre um bom trabalho conjunto.
Os pares de desenvolvedores trabalham em todas as partes do sistema, de forma que todos os desenvolvedores conheçam e entendam todo o
código. Todos são capazes de modificar qualquer parte do sistema. Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo. Depois de qualquer integração, todos os testes
unitários devem ser realizados
Um representante do usuário final do sistema (cliente) deve estar disponível em tempo integral para apoiar a equipe de XP. No processo de XP, o cliente é um membro da equipe e é o responsável por levantar
os requisitos que serão implementados.
Programação em pares
Produção coletiva
Integração contínua
Ritmo sustentável
Cliente on-site
Grandes quantidades de horas extras não são consideradas aceitáveis, no médio prazo, há uma redução na qualidade do código e da
Cenários de Requisitos
• Em XP, requisitos são expressos por meio de cenários ou user stories.
• Usualmente escritos em cartões.
• User Stories são divididas em tarefas. Estas tarefas são a base para escalonamento e
estimativa de custos.
• O cliente escolhe as user stories para
inclusão na próxima release com base nas prioridades delas e em estimativas de custo.
Story card para Download de
Documentos
Downloading and printing an article
First, you select the article that you want from a displayed list. You then have to tell the system how you will pay for it - this can either be through a subscription, through a company account or by credit card.
After this, you get a copyright form from the system to fill in and, when you have submitted this, the article you want is downloaded onto your computer.
You then choose a printer and a copy of the article is printed. You tell the system if printing has been successful.
If the article is a print-only article, you canÕt keep the P DF version so it is automatically deleted from your computer.
Fazendo download e imprimindo um artigo
Primeiro, selecione o que você deseja de uma lista. Você então deve informar ao sistema como será feito o pagamento - pode ser através de uma
assinatura, através de empresas ou cartão de credito.
Após isso, preencha o formulário de licença e quando submetê-lo, o artigo selecionado por você será baixado em seu computador.
Você então escolhe uma impressora e uma cópia do artigo será impressa. Você informa ao sistema se a impressão foi bem sucedida.
Se o artigo é somente para impressão, você não pode ficar com a versão em PDF, daí ele será automaticamente deletado do seu computador.
XP e Mudanças
• Design que permita acomodar mudanças é importante no desenvolvimento de software. Em algumas situações, é altamente recomendável empregar tempo e esforço
investigando possibilidades de mudanças, visto que pode reduzir custos posteriores no ciclo de vida do software.
• Entretanto XP prega que isto não é importante já que mudanças não podem ser previstas de forma confiável.
• Como alternativa, XP propõe melhoria contínua de código (refactoring) para facilitar a acomodação de mudanças
quando precisarem ser implementadas.
• É importante observar que refactoring é caro e o nível de confiabilidade pode ser baixo, levando a introdução de defeitos. Depende da qualidade do código e dos testes.
Teste em XP
• Teste Primeiro – desenvolvimento
incremental de testes a partir de cenários.
• Envolvimento de usuários no
desenvolvimento e validação de testes.
• Testes automáticos são usados para
executar todos os componentes de teste cada vez que uma nova release é
Tarefas para Download de
Documentos
Task 1: Implement principal workf low
Task 2: Implement article catalog and selection Task 3: Implement payment collection
P ayment may be made in 3 different ways. The user selects which way they wish to pay. If the user
has a library subscription, then they can input the subscriber key which should be checked by the
system. Alternatively, they can input an organisational account number. If this is valid, a debit of the cost of the article is posted to this account. Finally, they may input a 16 digit credit card number and expiry date. This should be checked for validity and, if valid a debit is posted to that credit card account.
O Pagamento pode ser feito de três diferentes formas. O usuário escolherá em qual das formas deseja pagar. Se o
usuário tem assinatura do serviço, ele então entra com a chave de permissão que será, então, checada pelo sistema.
Por outro lado, ele também pode entrar com o número da conta de uma empresa. Se a conta é valida,
o débito do artigo será postado nessa conta. Finalmente, o usuário pode entrar com os 16 dígitos do número de um
cartão de credito, além de sua data de expiração. Caso a operação seja válida, o valor será debitado
na conta do cartão de crédito. Tarefa 1: Implementar o fluxo principal de trabalho
Tarefa 2: Implementar o catálogo de artigos e a seleção deles
Descrição de Casos de Teste
Test 4: Test credit card validity Input:
A string representing the credit card number and two integers representing the month and year when the card expires
Tests:
Check that all bytes in the string are digits
Check that the month lies between 1 and 12 and the year is greater than or equal to the current year.
Using the first 4 digits of the credit card number, check that the card issuer is valid by looking up the
card issuer table. Check credit card validity by submitting the card number and expiry date information to the card
issuer Output:
OK or error message indicating that the card is invalid
Teste 4: Testar a validade do cartão de credito
Uma “string” representando o número do cartão de credito e dois inteiros representando o mês e o ano de quando o cartão expira.
Checar se todos os bytes na “string” são dígitos.
Checar se o mês dado está entre 1 e 12 e se o ano dado é maior que o ano corrente.
Usando os 4 primeiros dígitos do número do cartão checar se o emissor do cartão é valido.
Checar a validade do cartão submetendo o número e a data de expiração para o emissor.
Teste Primeiro
• Escrever testes antes do código ajuda a
esclarecer requisitos antes de serem implementados.
• Testes são escritos como programas tal que
possam ser executados automaticamente. O teste possui uma checagem de que foi
executado corretamente.
• Testes novos e anteriores são automaticamente
executados quando novas funcionalidades são adicionadas a fim de checar se novas
Programação em Pares
• Em XP, programadores trabalham em pares,
sentam juntos para desenvolver código.
• Isto ajuda a desenvolver um senso comum para
o código e difundir conhecimento na equipe.
• Serve como um processo de revisão informal já
que cada linha de código é examinada por mais de 1 pessoa.
• Encoraja refactoring já que todo o time pode se
beneficiar com isto.
• Métricas sugerem que a produtividade é similar
a de 2 pessoas trabalhando independentemente.
RAD em Geral
• Métodos ágeis têm recebido bastante
atenção, mas outras abordagens têm sido usadas há muitos anos.
• Estas são projetadas para o
desenvolvimento de aplicações de negócio focadas em dados, programação e
apresentação de informações a partir de um banco de dados.
RAD: Ferramentas
• Linguagem de Programação de BD
• Gerador de Interface
• Sistemas de Escritório
Reuso de COTS
• Uma abordagem efetiva para o
desenvolvimento rápido é o uso, configuração e associação de sistemas de prateleira
off-the-shelf.
• Por exemplo, um sistema para gerenciamento
de requisitos poderia ser construído usando:
▫ Uma base de dados para armazenar requisitos;
▫ Um processador de textos para capturar requisitos e
formatar relatórios;
Prototipação de Software
• Um protótipo é uma versão inicial de um
sistema usado para demonstrar conceitos e experimentar opções de design.
• Um protótipo pode ser usado em:
▫ Processo de engenharia de requisitos para
ajudar na elucidação e validação de requisitos;
▫ Processo de design para explorar opções e
desenvolver a UI;
▫ Processo de teste para executar testes
Benefícios da Prototipação
• Melhora a usabilidade do sistema.• Ajuda a identificar as necessidades reais dos usuários
• Melhora a qualidade do projeto.
• Melhora a manutenibilidade.
Teste Back-to-Back
Dados de teste Protótipo do Sistema O Sistema sendo desenvolvido Comparador de resultados Relatório de diferençasO Processo de Prototipação
Estabelecer objetivos do Protótipo Plano da Prototipação Definir funcionalidades do Protótipo Definição Geral Desenvolver o Protótipo Protótipo executável Avaliar o Protótipo Relatório de avaliaçãoProtótipos Descartáveis
• Protótipos devem ser descartados após o desenvolvimento, pois não são uma boa base para um sistema de produção:
▫ Pode ser impossível ajustar o sistema para atender a requisitos não funcionais. Por quê?
▫ Protótipos normalmente não possuem
documentação;
▫ A estrutura do protótipo é usualmente degradada
pelas mudanças rápidas e constantes;
▫ Usualmente não vai atender a normas e padrões
