Aula 3.1 Introdução e Visão Geral do Processo Unificado

Transcrição

1 PDS Aula 3.1 Introdução e Visão Geral do Processo Unificado Prof. Bruno Moreno bruno.moreno@ifrn.edu.br

2 Definição O Processo Unificado (Unified Process, UP) é um tipo de processo de desenvolvimento de software; O Processo Unificado surgiu como um processo iterativo. O que é um processo iterativo? 2

3 Processo Iterativo É organizado em uma série de miniprojetos curtos, de duração fixa, chamadas iterações; O produto de cada iteração é um sistema parcial, executável, testável e integrável; Cada iteração inclui suas próprias atividades de (1) análise de requisitos, (2) projeto, (3) implementação e (4) teste; 3

4 Processo Iterativo O ciclo de vida iterativo é baseado em refinamentos e incrementos sucessivos com feedback e adaptações cíclicas; O sistema desenvolvido por meio de um processo iterativo cresce ao longo do tempo Por isso, esta abordagem também é conhecida como iterativa e incremental 4

5 Processo Unificado O processo unificado, assim como seu refinamento (o RUP, Rational Unified Process), são bastante utilizados; O livro de Craig Larman utiliza o PU (ou UP) para conduzir a análise e o projeto OO; O PU promove práticas amplamente conhecidas como as melhores; O PU auxilia estudantes no entendimento de atividades de desenvolvimento de SW. 5

6 Processo Unificado O PU é muito flexível e aberto; O PU incentiva a inclusão de práticas de outros métodos iterativos, como XP, Scrum e outros; Desenvolvimento guiado por testes (XP); Sala comum de projeto (Scrum); Como a cada iteração, o sistema evolui, o PU é conhecido, também, como um processo iterativo e evolutivo. 6

7 PU: iterativo e evolutivo Em processos iterativos e evolutivos, não há uma corrida para codificar Não existe, também, uma tentativa de resolver todos os detalhes antes da programação; Cada iteração resulta em um sistema executável, mas incompleto A saída de uma iteração não é um protótipo, mas sim uma parte do sistema final; 7

8 PU: iterativo e evolutivo Mudanças são fatores inevitáveis e essenciais Isso não significa que o processo é descontrolado ; 8

9 PU: iterativo e evolutivo Cada iteração exige a escolha de um pequeno número de requisitos, implementação e teste; As iterações iniciais podem definir requisitos que não estarão, exatamente, no produto final Como as iterações são curtas, existe uma realimentação rápida; 9

10 PU: iterativo e evolutivo A realimentação provida por processos iterativos e evolutivos são de suma importância Extingue qualquer tipo de especulação. Sim, foi isso que eu pedi, mas agora que o experimentei, o que eu quero realmente é algo ligeiramente diferente 10

11 PU: iterativo e evolutivo Realimentação e adaptação faz o sistema convergir para os requisitos e o projeto mais adequados; Iteração Nas últimas iterações, é rara uma mudança significativa de requisitos; A mudança tardia pode dar uma vantagem competitiva nos negócios da organização. 11

12 PU: iterativo e evolutivo Vantagens de processos iterativos e evolutivos: Menos erro de projeto; Maior produtividade; Mitigação precoce de altos riscos Técnicos, requisitos, objetivos, usabilidade, etc. Progresso visível desde o início; Realimentação; Amadurecimento iteração por iteração. 12

13 Motivação Em um processo em cascata, há sempre uma tentativa de definir todos os requisitos antes da programação; Em um processo em cascata, tenta-se definir um plano, ou cronograma, confiável no início; Na prática, o processo não é confiável. 13

14 Motivação Processos em cascata estão fortemente associados à produção de softwares com altas taxas de falhas e pouca produtividade; 45% dos requisitos definidos nunca são usados; Cronogramas e orçamentos variam em até 400%; 14

15 Motivação Na década de 60 e 70, a recomendação de se usar processos em cascata, era baseada em especulação e boato, em vez de práticas baseadas na evidência 15

16 Mesmo assim, é frequente que o pensamento em cascata ainda invada o processo iterativo e evolutivo. 16

17 Mas, por que o ciclo de vida em cascata é tão propenso a falhas? 17

18 Motivação Estudos mostram que um projeto sofre 25% de modificações nos requisitos Dependendo da complexidade do projeto, essa taxa pode chegar a 50% O desenvolvimento de SW é um domínio de alta modificação e instabilidade. 18

19 Além de iterativo e evolutivo, um método de desenvolvimento deve ser utilizado com espírito agil 19

20 Métodos Ágeis Métodos de desenvolvimento ágil aplicam desenvolvimento iterativo e evolutivo; Empregam planejamento adaptativo; Promovem entrega incremental; Encorajam valores e práticas relacionadas à agilidade. 20

21 O PU deve ser Ágil Em breve veremos que o PU é composto por artefatos, atividades, e etc; Ele foi criado para que fosse ágil; Apesar de possuir um grande conjunto de atividades e artefatos, todos são opcionais! Deve ser aplicado com espírito de adaptabilidade e leveza; 21

22 O PU deve ser Ágil Aplique PU de acordo com os conselhos a seguir: Prefira um conjunto pequeno de atividades e artefatos do PU; Siga a regra: se o artefato/tarefa não adiciona valor ao projeto, evite criá-los; Não se preocupe em levantar todos os requisitos de uma vez: o PU é iterativo e evolutivo, os requisitos irão emergir de forma adaptativa; Aplique UML como rascunho. 22

23 Observações Gerais A finalidade principal da modelagem ágil é entender, não documentar... Entretanto, a adoção de um método ágil não significa não modelar Muitos métodos ágeis incluem significativas sessões de modelagem; Não modele ou aplique UML a todo ou à maioria do projeto de SW Adie problemas simples ou diretos de projetos até a programação resolva-os durante a programação e testes; 23

24 Observações Gerais O ideal é que se use UML nas partes incomuns, difíceis, de alta complexidade Geralmente, essas partes reresentam uma percentagem menor em relação ao projeto; Use uma ferramenta CASE simples Que incentivem a criatividade e apoiam a compreensão e a modificação rápida; Prefira quadros brancos e papéis de rascunhos a ferramentas CASE A regra é: facilidade e agilidade, qualquer que seja a tecnologia. 24

25 Observações Gerais Não modele sozinho, modele aos pares (ou trios), no quadro branco ou usando rascunhos Faça com que a caneta rode entre os membros de modo que todos participem; Crie modelos paralelos Por exemplo, crie ao mesmo tempo um modelo que represente a visão estática e outro que represente a visão dinâmica do SW; 25

26 Observações Gerais Lembre-se: a sintaxe UML é importante, mas mais importante ainda é o entendimento do modelo Ou seja, use uma notação simples e suficientemente boa para compreensão e agilidade; Ao final do projeto, os modelos sempre são imprecisos e diferentes do que o código, de fato, implementa. 26

27 Fases do PU O PU organiza o trabalho e as iterações em quatro fases principais: Concepção Elaboração Construção Transição 27

28 Fases do PU O PU organiza o trabalho e as iterações em quatro fases principais: Concepção Elaboração Construção Transição 28

29 Concepção Esta fase auxilia os projetistas a terem uma visão aproximada do projeto; São definidos os casos de negócio, o escopo e determinadas as estimativas Não é uma fase de requisitos Na verdade é uma de fase de estudo de viabilidade; Se executa um volume suficiente de investigação para fundamentar a decisão de continuar ou parar. 29

30 Fases do PU O PU organiza o trabalho e as iterações em quatro fases principais: Concepção Elaboração Construção Transição 30

31 Elaboração Aqui a visão de negócio é refinada; Inicia-se a implementação iterativa da arquitetura central; Ocorre a resolução de altos riscos; Identificação da maioria dos requisitos e do escopo; As estimativas acabam por se tornar mais realistas; Os riscos mais altos são mitigados; 31

32 Fases do PU O PU organiza o trabalho e as iterações em quatro fases principais: Concepção Elaboração Construção Transição 32

33 Construção Inicia-se a implementação iterativa dos elementos de menor risco; Inicia-se preparação para implantação; 33

34 Fases do PU O PU organiza o trabalho e as iterações em quatro fases principais: Concepção Elaboração Construção Transição 34

35 Transição Inicia-se os testes beta e a implantação do sistema; 35

36 Cronograma de um PU Ciclo de desenvolvimento Iteração Fase Concepção Elaboração Construção Transição Marco de referência Versão Entrega final Marco de referência: é o término de uma iteração caracterizado por ter uma decisão ou avaliação significativa; Versão: é um subconjunto executável do produto final; Entrega final: o sistema é entregue para uso em produção. 36

37 Conceitos Básicos do PU Atividades de trabalho São atividades a serem realizadas em determinadas fases do processo; Geram artefatos de software; Exemplo: redigir um caso de uso; Artefatos de SW Termo usado para qualquer produto de trabalho; Exemplo: código, gráfico, esquema de BD, documento texto, diagramas, modelos, etc; Disciplinas Conjunto de atividades (e artefatos relacionados) em uma área alvo; Exemplo: atividades dentro da análise de requisitos 37

38 Principais Disciplinas do PU Modelagem de Negócio; Requisitos; Projeto; Implementação; Teste; 38

39 Principais Disciplinas do PU Modelagem de Negócio; Requisitos; Projeto; Foco do nosso curso. Implementação; Teste; 39

40 Disciplinas X Fases Durante uma iteração, o trabalho prossegue na maioria ou em todas as disciplinas; Contudo, o esforço em cada disciplina pode mudar dependendo da fase de desenvolvimento; Nas iterações iniciais, o desenvolvimento foca em disciplinas relacionadas aos requisitos e ao projeto; Nas ultimas iterações, a ênfase são disciplinas relacionadas a validação do projeto. 40

41 Disciplinas X Fases O nível de esforço nas disciplinas pode ser relacionado de acordo com a figura a seguir: 41

42 Outras melhores práticas do PU Os problemas de alto riscos e alto valor devem ser envolvidos nas primeiras iterações; Os usuários devem ser envolvidos continuamente no projeto; Deve-se construir uma arquitetura central já nas iterações iniciais; A qualidade deve ser verificada continuamente, fazendose testes logo no início usando situações realísticas; Sempre que adequado, deve-se aplicar casos de uso; O software deve ser modelado visualmente com UML; Os requisitos devem ser gerenciados cuidadosamente 42