FIP – SI – Sabrina de F. Souto.

� Processo� Processo de Software� Modelo Constrói e Conserta� Modelo Cascata� Modelo de PrototipaçãoModelo Espiral� Modelo Espiral

� IBM Rational Unified Process – RUP� eXtreme Programming� Teste de Software� Fluxo de Teste� Processo de Teste

2

� Um processo:

◦ é uma ação regular e contínua (ou sucessão de ações)realizada de forma bem definida, levando a um resultado[Oxford English Dictionary]

◦ é um conjunto parcialmente ordenado de atividades (ou◦ é um conjunto parcialmente ordenado de atividades (oupassos) para se atingir um objetivo [Feiler & Humphrey]

◦ define quem está fazendo o que, quando e como paraatingir um certo objetivo [Jacobson, Booch, Rumbaugh]

3

� Em engenharia de software, o objetivo é odesenvolvimento de um produto de software

� Em engenharia de processos, o objetivo édesenvolvimento de um (modelo de) processo

� O termo ciclo de vida evoluiu para processo◦ Exemplos de ciclos de vida de software: cascata, espiral,incremental

4

� Conjunto de atividadesatividadesatividadesatividades, métodosmétodosmétodosmétodos,práticaspráticaspráticaspráticas e tecnologiastecnologiastecnologiastecnologias que aspessoas utilizam para desenvolvere manter software e produtosrelacionados

O processo é a ponta do triângulo � O processo é a ponta do triângulo que unifica os outros aspectos

5

� Mesmo as melhores pessoas não conseguem trabalhar deforma eficiente se o processo é problemático ou malcompreendido

� Investimentos em tecnologia sem um guia que defina comoutilizá-la é um desperdício de recursos

� Sem processos claros e eficientes, uma empresa não éescalável

6

� O interesse do processo de software está baseado em duaspremissas:

1. A qualidade de um produto de software é fortementedependente da qualidade do processo pelo qual ele éconstruído e mantido

2. O processo de software pode ser definido, gerenciado, medidoe melhorado

7

Um processo definido deve estar descrito em detalhes Um processo definido deve estar descrito em detalhes Um processo definido deve estar descrito em detalhes Um processo definido deve estar descrito em detalhes de forma a poder ser usado de forma consistentede forma a poder ser usado de forma consistentede forma a poder ser usado de forma consistentede forma a poder ser usado de forma consistente

� O número de defeitos presentes no software quandoentregue para testes é função direta da qualidade doprocesso usado para a construção do software

o Testes só podem detectar 70% dos defeitos latentes no código

Inspeções podem detectar 80 a 90% dos erros antes dos testeso Inspeções podem detectar 80 a 90% dos erros antes dos testes

� Mas, um bom processo evita a presença de defeitos noproduto.

8

Precisamos aprender a atacar a doença e Precisamos aprender a atacar a doença e Precisamos aprender a atacar a doença e Precisamos aprender a atacar a doença e

9

Precisamos aprender a atacar a doença e Precisamos aprender a atacar a doença e Precisamos aprender a atacar a doença e Precisamos aprender a atacar a doença e não os sintomas: não os sintomas: não os sintomas: não os sintomas:

o processo e não os defeitos no softwareo processo e não os defeitos no softwareo processo e não os defeitos no softwareo processo e não os defeitos no software

� O produto é construído sem qualquer especificação ouprojeto;

� O produto é retrabalhado quantas vezes for necessário parasatisfazer o cliente;

� Este modelo pode funcionar razoavelmente para microprojetos (<400 pessoas/hora);

No entanto para projetos maiores ele é inadequado.� No entanto para projetos maiores ele é inadequado.

10

� É recomendado para sistemas onde a segurança e aconfiabilidade tem grande importância.

� Pontos forteso É uma abordagem disciplinadao Definição da documentação liberável em cada faseo Todos os produtos de cada fase tem que ser formalmenterevisadosrevisados

� Cada fase possui procedimentos de verificação e validação(incluindo testes)

� Uma vez definido o modelo de ciclo de desenvolvimento,existem três abordagens para implementá-lo:o Cascata Purao Incrementalo Evolucionária

11

� Todas as fases do ciclo de desenvolvimento são executadas em seqüência.

� Esta abordagem é adequada quando : o existe um conjunto de requisitos estável e de alta qualidadeo a duração do projeto é pequena(<2 anos)o o sistema completo deve estar disponível de um única vezo o sistema completo deve estar disponível de um única vez

12

RequisitosRequisitosRequisitosRequisitos

ProjetoProjetoProjetoProjeto

ImplementaçãoImplementaçãoImplementaçãoImplementação

TesteTesteTesteTeste

ManutençãoManutençãoManutençãoManutenção

� A abordagem incremental é adequada quando:o a liberação do software deve estar de acordo com um conjunto deprioridades definidas nos requisitos

o é necessário melhorar a eficiência da integração do software comoutra partes de um sistema maior

o é requerido antecipadamente evidências de que o produto será aceito

13

RequisitosRequisitosRequisitosRequisitos

ProjetoProjetoProjetoProjeto

ImplementaçãoImplementaçãoImplementaçãoImplementação

TesteTesteTesteTeste

ManutençãoManutençãoManutençãoManutenção

� Esta abordagem é adequada quando:o é necessário alguma experiência do usuário para refinar e completarrequisitos

o algumas partes da implementação podem depender da existência detecnologia ainda não disponível

o existem requisitos do usuário ainda não conhecidoso alguns requisitos são muito mais difíceis de serem implementados doo alguns requisitos são muito mais difíceis de serem implementados doque outros, decidindo-se não implementá-lo para não atrasar oprojeto

14

� O objetivo é entender os requisitos do usuário e, assim, obteruma melhor definição dos requisitos do sistema

� Possibilita que o desenvolvedor crie um modelo (protótipo) dosoftware que deve ser construído

� Apropriado quando o cliente não definiu detalhadamente osrequisitos

� Esse modelo pode assumir uma das três formas:� Esse modelo pode assumir uma das três formas:o Um protótipo em papel ou modelo baseado em PC que retrata ainteração homem-máquina de uma forma que capacita o usuário aentender quanto a interação ocorrerá

o Um protótipo de trabalho que implemente algum subconjunto dafunção exigida do software desejado, ou

o Um programa existente que executa toda a função desejada, masque tem outras características que serão melhoradas em um novoesforço de desenvolvimento

15

Obter Requisitos

Elaborar Projeto Rápido

16

Elaborar Projeto Rápido

Construir ProtótipoAvaliar Protótipo

CONSTRUÇÃO CONSTRUÇÃO DO PRODUTODO PRODUTO

Refinamento do Protótipo

� Foi originalmente proposto por Boehm em 1988

� Uma maneira simplista de analisar este modelo é considerá-lo como um modelo cascata onde cada fase é precedida poruma análise de risco e sua execução é feitaincrementalmenteincrementalmente

� A dimensão radial representa o custo acumulado atualizadoe a dimensão angular representa o progresso através daespiral

� Cada setor da espiral corresponde a uma tarefa (fase)dodesenvolvimento

17

18

� Um ciclo se inicia com a "Determinação de objetivos,alternativas e restrições "(primeira tarefa) onde ocorre ocomprometimento dos envolvidos e o estabelecimento deuma estratégia para alcançar os objetivos

� Na segunda tarefa: "Avaliação de alternativas, identificação esolução de riscos", executa-se uma análise de risco

� Prototipação é uma boa ferramenta para tratar riscos. Se orisco for considerado inaceitável, pode parar o projeto

� Na terceira tarefa ocorre o desenvolvimento do produto. Nestequadrante pode-se considerar o modelo cascata

� Na quarta tarefa o produto é avaliado e se prepara para iniciarum novo ciclo

19

20

� Variações do modelo espiral consideram entre três e seistarefas ou setores da espiral. Um exemplo são as regiões:

1. Comunicação com o cliente

2. Planejamento2. Planejamento

3. Análise de risco

4. Engenharia

5. Construção e liberação

6. Avaliação do cliente

21

� A manutenção de um software utilizando este modelo de ciclo de vida é tratado da mesma forma que o desenvolvimento

22

� O Rational Unified Process é um processo de engenharia desoftware, que procura disciplinar atribuições de tarefas eresponsabilidades dentro de uma estrutura dedesenvolvimento de software. Sua meta principal é garantir aprodução de software com alta qualidade satisfazendo asnecessidades dos seus usuários, dentro de um cronograma enecessidades dos seus usuários, dentro de um cronograma eorçamento previsível. (Rational Unified Process, 2008)

� O RUP é um processo configurável, ajustando-se tanto parapequenas equipes de desenvolvimento quanto para grandes

23

� Reúne muitas das melhores práticas em desenvolvimento desoftware:

o Desenvolvimento iterativo de software

o Gerenciamento de requisitos

o Arquitetura baseada em componentes

o Modelagem visual do software (protótipo)

o Verificação da qualidade do software (testes)

o Controle de mudanças no software

24

25

� De acordo com o RUP, as fases constituem os ciclos de vidado software, sendo cada ciclo responsável por uma versãonova do produto. Estas fases são:o Concepção (Inception)

o Elaboração (Elaboration)

o Construção (Construction)

Transição (Transition)o Transição (Transition)

� O RUP é representado usando quatro elementos paramodelagem:o Papéis/Equipe (quem está fazendo o que)

o Artefatos (o que é produzido)

o Atividades (como o trabalho é conduzido)

o Workflows (quando uma tarefa é conduzida)

26

� A Extreme Programming - XP - é uma metodologia ágilvoltada às equipes pequenas e médias que desenvolvemsoftware baseado em requisitos vagos e que se alteram comrapidez (Beck, 2004)

� O objetivo de XP é tornar o projeto flexível, diminuindo o� O objetivo de XP é tornar o projeto flexível, diminuindo ocusto a possíveis mudanças

� Por que o termo “extreme” no nome?

27

� XP leva ao extremo seus princípios e práticas:o Se revisar o código é bom, então vamos revisar o código durantetodo o tempo (programação em par)

o Se testar é bom, então todo mundo vai testar durante todo otempo (teste de unidade), até os clientes (teste funcional)

o Se design é bom, então vamos fazer com que isso seja parte dodia-a-dia da equipe (refatoração de código)dia-a-dia da equipe (refatoração de código)

o Se ter simplicidade é bom, então vamos deixar o sistema com odesign o mais simples possível

o Se arquitetura é importante, todo mundo irá definí-la e refiná-ladurante todo o tempo (metáfora)

o Se teste de integração é importante, então vamos integrar etestar várias vezes ao dia (integração contínua)

o Se ter iterações pequenas é legal, então vamos fazer iteraçõesmuito pequenas – segundos/minutos/hora (Planning Game)

28

� As práticas promovidas por XP se forem examinadasindividualmente apresentarão falhas, mas uma das forças daXP é que as práticas se combinam de um modo mútuoapoiando-se

� Fases de XP:� Fases de XP:o Exploração

o Planejamento

o Iterações para release

o Validação para produto

o Manutenção

o Morte

29

30

� Qual atende melhor?

31

32