A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Faculdade 7 de Setembro Metodologias de Desenvolvimento Paulo Benício.

Apresentações semelhantes


Apresentação em tema: "Faculdade 7 de Setembro Metodologias de Desenvolvimento Paulo Benício."— Transcrição da apresentação:

1 Faculdade 7 de Setembro Metodologias de Desenvolvimento Paulo Benício

2 Estágio II Sistemas de Informação Metodologias e Processo de Desenvolvimento Professor: Paulo Benício /msn:

3 Estágio II Sistemas de Informação Roteiro Introdução

4 Estágio II Sistemas de Informação Introdução Sistemas Computacionais: –Crescimento acelerado. –Empregados em vários setores. –Alguns mitos que se tornaram realidade: Caixas Eletrônicos Computação embarcada em automóveis. Computadores laptop. Projeto do Genoma Humano World Wide Web.

5 Estágio II Sistemas de Informação Modelo de Desenvolvimento

6 Estágio II Sistemas de Informação 6 Engenharia de Software Uma tecnologia em camadas Processos de engenharia devem se apoiar num compromisso organizacional com a qualidade –Cultura de um processo continuo de aperfeiçoamento –Desenvolvimento de abordagens cada vez mais amadurecidas para a engenharia de software A camada que dá apoio à engenharia de software é o enfoque na qualidade.

7 Estágio II Sistemas de Informação 7 Processos (procedimentos) A camada de processo é o fundamento da Engenharia de Software Os procedimentos constituem o elo de ligação que mantém juntos os métodos e as ferramentas Possibilitam o desenvolvimento racional e oportuno de software Definem áreas chave (key process areas – kpa) que estabelecem: –a seqüência em que os métodos serão aplicados –os produtos que deverão ser entregues –os controles que ajudam a assegurar a qualidade e a coordenar as mudanças –os marcos de referencia que possibilitam aos gerentes avaliar o progresso.

8 Estágio II Sistemas de Informação 8 Métodos Métodos proporcionam os detalhes de como fazer para construir o software. Envolvem tarefas como: –planejamento e estimativa de projeto –análise de requisitos –projeto de estrutura de dados –Algoritmos –Codificação –Teste –Manutenção Muitas vezes, introduzem uma notação gráfica ou orientada à linguagem e um conjunto de critérios para a qualidade do software

9 Estágio II Sistemas de Informação 9 Ferramentas As ferramentas proporcionam apoio automatizado ou semi automatizado para o processo e para os métodos Quando ferramentas são integradas de modo que a informação criada por uma ferramenta pode ser usada por outra, origina-se um sistema de apoio ao desenvolvimento chamado Engenharia de Software Apoiada por Computador (CASE – Computer Aided Software Engineering) –CASE combina software, hardware e uma base de dados de engenharia de software –semelhante ao CAD/CAM

10 Estágio II Sistemas de Informação 10 Desenvolvimento de software Engenheiros de software utilizam estes recursos para desenvolver software de alta qualidade –Um procedimento é um conjunto de ferramentas e técnicas que juntas geram um produto –Um método ou técnica é um procedimento formal para produzir algum resultado –Uma ferramenta é um instrumento ou sistema automatizado para resolver alguma coisa da melhor forma –Um paradigma representa uma abordagem ou filosofia para construir um software.

11 Estágio II Sistemas de Informação 11 Atores da Engenharia de Software

12 Estágio II Sistemas de Informação 12 Membros de uma equipe de desenvolvimento Analista Projetista Programador Responsável por testes Instrutor

13 Estágio II Sistemas de Informação 13 Engenharia Independente do elemento a ser tratado, um processo de engenharia deve tratar as seguintes questões: –Qual é o problema a ser resolvido? –Que características do elemento são usadas para resolver o problema? –Como o elemento (e a solução) serão realizados? –Como o elemento vai ser construído? –Que abordagem será usada para descobrir erros que foram cometidos no projeto e na construção do elemento? –Como o elemento será mantido a longo prazo, quando correções, adaptações e aperfeiçoamentos forem solicitados pelos usuários? ELEMENTO = SOFTWARE Na sua proposta de trabalho, responda a estas perguntas!!

14 Estágio II Sistemas de Informação 14 Engenharia de software Visão genérica Para realizar a engenharia de software adequadamente um processo (forma de trabalho) deve ser definido Um processo de ES pode ser categorizado, genericamente em 3 fases, que focalizam as questões feitas anteriormente: –Fase de definição –Fase de desenvolvimento –Fase de manutenção

15 Estágio II Sistemas de Informação 15 Engenharia de software Fase de Definição se concentra no quê –Que informação deve ser processada –Que função e desempenho são desejados –Que comportamento é esperado do sistema –Que interfaces devem ser estabelecidas –Que restrições de projeto existem –Que critérios de validação são necessários para definir um sistema bem sucedido Identificação dos requisitos chave do software Os métodos variam de acordo com o paradigma de Engenharia de Software escolhido, mas 3 tarefas principais ocorrerão: –Engenharia de sistema ou de informação –Planejamento do projeto de software –Análise de requisitos Considere também estas questões na sua proposta de trabalho!!

16 Estágio II Sistemas de Informação 16 Engenharia de Software Fase de desenvolvimento Focaliza o como –Como os dados serão estruturados –Como a função deve ser implementada –Como os detalhes procedimentais devem ser implementados –Como as interfaces devem ser caracterizadas –Como o projeto deve ser traduzido em linguagem de programação –Como o teste vai ser realizado Os métodos variam, mas 3 tarefas técnicas ocorrerão: –Projeto de software –Geração de código –Teste de software

17 Estágio II Sistemas de Informação 17 Engenharia de Software Fase de manutenção Focaliza nas modificações Aplica os passos das fases de definição e de desenvolvimento, mas no contexto do software já existente Quatro tipos de manutenção: –Manutenção corretiva – modifica o software para corrigir defeitos –Manutenção adaptativa – modifica o software para adaptá- lo a mudanças no ambiente externo –Manutenção perfectiva – aprimora o software além dos requisitos originais –Manutenção preventiva (reengenharia de software) – modifica o software para que possa ser mais facilmente corrigido, adaptado e melhorado Apoio contínuo ao usuário: assistência técnica e suporte

18 Estágio II Sistemas de Informação 18 Atividades guarda-chuva Atividades que devem ser aplicadas durante todas as etapas do processo de software –Assim chamadas porque são utilizadas a todo momento, encobrindo todas as atividades do processo Incluem atividades de: –Acompanhamento e controle de projeto de software –Revisões técnicas formais –Garantia de qualidade de software –Gestão de configuração de software –Preparação e produção de documentos –Gestão de reutilização –Gestão de risco

19 Estágio II Sistemas de Informação 19 Processo de Software

20 Estágio II Sistemas de Informação 20 Processo de Software Estrutura comum de processo de software –Define um pequeno número de atividades –Aplicáveis a todos os projetos de software Conjuntos de tarefas –Permite que as atividades da estrutura sejam adaptadas às características do projeto de software e às necessidades da equipe do projeto –Constituídos de Coleção de tarefas Marcos de projeto Produtos do trabalho Pontos de garantia de qualidade Atividades guarda-chuva ocorrem em todo o modelo de processo

21 Estágio II Sistemas de Informação 21 Processo de Software CMM (Capability Maturity Model) Estabelecidas pelo Software Engineering Institure (SEI) – Prescreve um conjunto de capacidades (i.e.,requisitos de qualidade) de Engenharia de Software presentes à medida que as empresas atingem níveis de maturidade de processo de software São 5 níveis que indicam uma medida da efetividade global das práticas de Engenharia de Software de uma empresa

22 Estágio II Sistemas de Informação 22 Modelos de Processo de Software A Engenharia de Software compreende um conjunto de etapas envolvendo métodos, ferramentas e procedimentos Estas etapas são chamadas de Modelos de Processo Estes modelos são escolhidos considerando: –domínio da aplicação –os métodos e as ferramentas a serem usadas –os controles e os produtos que precisam ser entregues –as características do grupo desenvolvedor –o grau de conhecimento sobre o problema

23 Estágio II Sistemas de Informação 23 Modelos de Processo de Software Caracterizado como um ciclo de solução de problema com 4 estágios: –Situação atual: Identificação do estado atual das coisas –Definição do problema: Identifica o problema a ser resolvido –Desenvolvimento técnico: Resolve o problema por meio de aplicação de uma tecnologia –Integração: Entrega os resultados (documentos, programas, dados, nova função de negócio, novo produto) Aplica-se ao trabalho de Engenharia de Software em diferentes níveis de detalhe: a aplicação como um todo ou um componente de programa, até o nível de linha de código Distinção nítida das etapas é difícil, num processo real –Conforme se desenvolve o trabalho rumo a um sistema completo, as etapas se aplicam recursivamente às necessidades do usuário e à especificação técnica do desenvolvedor do software.

24 Estágio II Sistemas de Informação Roteiro Processos de Desenvolvimento

25 Estágio II Sistemas de Informação Engenharia de Software Modelos de Ciclo de Vida ou Processos de Software

26 Estágio II Sistemas de Informação 26 Modelo X Processo Um modelo é algo teórico, um conjunto de possíveis ações. O processo deve determinar ações práticas a serem realizadas pela equipe, tais como prazos definidos e métricas para se avaliar como elas estão sendo realizadas Modelo + Planejamento = Processo

27 Estágio II Sistemas de Informação 27 Modelos de Processo Principais modelos: –Modelo Seqüencial Linear ou em Cascata (Waterfall) –Modelo de Prototipagem –Modelo RAD –Modelos Evolucionários: Incremental Espiral Espiral ganha-ganha Desenvolvimento concorrente –Desenvolvimento baseado em componentes –Modelo de Métodos Formais

28 Estágio II Sistemas de Informação 28 Modelo em Cascata (Waterfalls) Às vezes chamado de Modelo de Ciclo de Vida Clássico ou de Modelo Seqüencial Linear Abordagem sistemática seqüencial para o desenvolvimento do software, começando pelo nível de sistema e progride através da análise, codificação, teste e manutenção O paradigma desse ciclo de vida requer uma abordagem sistemática e seqüencial ao desenvolvimento. É o paradigma mais antigo e o mais usado

29 Estágio II Sistemas de Informação 29 Modelo em Cascata (Waterfalls) O processo Cascata está associado às metodologias propostas nas décadas de –Notadamente as metodologias Estruturadas Yourdon Constantine Chris Gane Page-Jones

30 Estágio II Sistemas de Informação 30 Modelo em Cascata (Waterfalls) Etapas Engenharia de Sistemas Análise de Requisitos Projeto Codificação Teste Manutenção

31 Estágio II Sistemas de Informação 31 Modelo em Cascata (Waterfalls) A tividades Análise e definição de requisitos –Objetivos, funções e restrições são definidos, com ajuda de clientes e usuários, e servem como uma especificação do sistema, indicando o que deve ser implementado. Design de sistemas e software –Envolve a descrição do sistema e do software em termos de unidades abstratas e de suas relações, indicando como o software deve ser implementado. Implementação e testes de unidade –As unidades do software devem ser codificadas e testadas individualmente. Integração e testes de sistema –A unidades são integradas e testadas Entrega, operação e manutenção –A manutenção envolve a correção de erros e evolução do sistema para atender a novos requisitos.

32 Estágio II Sistemas de Informação 32 Modelo em Cascata (Waterfalls) Características Oferece maior previsibilidade de prazos e custo: melhor planejamento e gerenciamento. Principais problemas –Projetos reais raramente seguem o fluxo seqüencial –Dificuldade em congelar os requisitos no início e em acomodar mudanças dinâmicas –O cliente precisa ter paciência Indicado somente quando os requisitos são bem conhecidos –Pode ser usado em trabalhos acadêmicos com etapas bem definidas de levantamento bibliográfico

33 Estágio II Sistemas de Informação Processo de Desenvolvimento –Arquitetura genérica de aplicativos Camada de Apresentação Interface Homem Máquina Rotinas de Apresentação Camada de Banco de Dados Rotinas de Acesso Banco de Dados Camada de Lógica da Aplicação Regras de Negócio (Métodos) Classes (Implementação) fig. 3 – A marco arquitetura base Aplicativo

34 Estágio II Sistemas de Informação Planejamento Insumos –Contrato e/ou Proposta Produtos –Plano de Desenvolvimento –Plano de Configuração –Plano de Garantia da Qualidade –Plano de Verificação e Validação Papéis –Gerente/Coordenador de Projeto –SQA –Gerente de Qualidade –Gerente de Configuração Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

35 Estágio II Sistemas de Informação Requisitos Insumos –Requisitos contidos na Proposta Produtos –Especificação de Requisitos –Especificação de Casos de Uso Papéis –Engenheiro de sistemas –Arquiteto –Analista de sistemas –Coordenador de projeto –Cliente Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

36 Estágio II Sistemas de Informação Análise e Projeto Insumos –Especificação de Casos de Uso, Interface, Núlceo e Base de Dados Produtos –Projeto de Interface, Núcleo e Base de Dados –Especificação de Teste de Integração –Especificação de Teste de Unidade Papéis –Analista de sistemas –Arquiteto –Coordenador de projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

37 Estágio II Sistemas de Informação Codificação Insumos –Projeto de Interface, Núcleo e Base de Dados Produtos –Guia de Implementação (Build) –Código Fonte Papéis –Analista de sistemas –Programador –Coordenador de projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

38 Estágio II Sistemas de Informação Teste de Unidade Insumos –Especificação de Teste de Unidade –Código do aplicativo Produtos –Relatório de Teste de Unidade –Código do aplicativo testado e corrigido Papéis –Analista de sistemas –Programador –Coordenador de projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

39 Estágio II Sistemas de Informação Integração ( Opcional ) Insumos –Especificação de Teste de Integração –Código do aplicativo Produtos –Relatório de Teste de Integração –Código do aplicativo testado e corrigido Papéis –Analista de sistemas –Programador –Coordenador de projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

40 Estágio II Sistemas de Informação Teste de Sistema Insumos –Especificação de Teste de Sistema –Código do aplicativo Produtos –Relatório de Teste de Sistema –Código do aplicativo testado e corrigido Papéis –Engenheiro de Sistemas –Programador –Coordenador de projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

41 Estágio II Sistemas de Informação Teste de Aceitação Insumos –Especificação de Teste de Aceitação –Código do aplicativo Produtos –Relatório de Teste de Aceitação –Código do aplicativo testado e corrigido Papéis –Engenheiro de Sistemas –Cliente Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

42 Estágio II Sistemas de Informação Empacotamento Insumos –Código do produto –Arquivos de execução –Guia de implementação Produtos –Pacote do produto Papéis –Analista de Sistemas –Coordenador de Projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

43 Estágio II Sistemas de Informação Consolidação Insumos –Histórico do projeto –Documentação do projeto Produtos –Relatório de Lições Aprendidas Papéis –Toda equipe do projeto Planejamento Requisitos Integração Teste de Aceite Análise e Projeto Codificação Teste de Unidade Empacotament o Teste de Sistema Consolidação

44 Estágio II Sistemas de Informação Responsabilidades Grupo de Engenharia Grupo de Desenvolvimento Grupo de Qualidade Planejamento Requisitos Integração Teste de Aceite Projeto Análise Codificação Teste Unitário Empacotament o Teste de Sistema Consolidação

45 Estágio II Sistemas de Informação Planos de Projeto Espec. de Requisitos Espec. de Sistema Proj. de Sistema Código fonte Relatório de Testes Pacote do Produto Relatório de Lições Resumo dos Produtos Planejamento Requisitos Projeto Análise Codificação Testes ( Unit/Integr/ Sist/Aceite ) Empacotamento Consolidação

46 Estágio II Sistemas de Informação 46 Modelo de Prototipação Abordagem interessante em situações em que a incerteza está presente na definição de requisitos, de objetivos e/ou de procedimentos Desenvolvimento Exploratório –A partir de requisitos iniciais, é elaborado um protótipo que permite, junto ao cliente, explorar novos requisitos. Permite a criação de um modelo do software que será desenvolvido, em uma das seguintes formas: –Um protótipo que retrata a interação homem-máquina de forma que o usuário entenda esta interação –Um protótipo de trabalho que implemente um subconjunto das funções do software –Um programa que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas em um novo esforço de desenvolvimento

47 Estágio II Sistemas de Informação 47 Modelo de Prototipação Protótipo de software é um sistema que... –funciona –não tem tempo de vida definido –pode servir a múltiplos propósitos –deve ser construído rapidamente e com baixo custo –é parte integrante de um design centrado no usuário, para avaliação e modificação Podem existir diferenças entre o protótipo e o sistema final. –O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente algumas facetas do sistema a desenvolver.

48 Estágio II Sistemas de Informação 48 Modelo de Prototipação Problemas –O cliente vê o protótipo como uma versão de trabalho do software e exige a sua adequação para o produto, pensando no prazo e não considerando as questões de qualidade e manutenibilidade –O desenvolvedor, muitas vezes, faz concessões de implementação e qualidade a fim de colocar um protótipo em funcionamento Definir as regras do jogo desde o início –cliente e desenvolvedor devem estar cientes e de acordo em que o protótipo serve como um mecanismo de definição dos requisitos

49 Estágio II Sistemas de Informação 49 Modelo de Desenvolvimento Rápido da Aplicações – RAD É um modelo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento extremamente curto É uma adaptação do modelo seqüencial linear, no qual o desenvolvimento rápido se utiliza da construção baseada em componentes. Se os requisitos são bem compreendidos e o objetivo do projeto é restrito, o processo RAD permite a uma equipe de desenvolvimento criar um sistema plenamente funcional, dentro de períodos muito curtos (e. 60 a 90 dias) Muito aplicado a sistemas de informação

50 Estágio II Sistemas de Informação Modelo de Desenvolvimento Rápido da Aplicações – RAD Fases –Modelagem do negócio o fluxo de informação entre as funções do negócio é modelado –Modelagem de dados o fluxo de informação é refinado num conjunto de objetos de dados necessários para dar suporte ao negócio. Os atributos e as relações são definidos –Modelagem do processo descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados –Geração da aplicação usa: técnicas de quarta geração; reuso e desenvolvimento de componentes; e ferramentas automatizadas para facilitar a construção –Teste e entrega reutiliza componentes o que reduz o tempo de teste, porém os novos componentes e as interfaces precisam ser testados

51 Estágio II Sistemas de Informação 51 Modelo de Desenvolvimento Rápido da Aplicações – RAD Desvantagens –Para projetos grandes exige RH suficiente para criar um número adequado de equipes RAD –Exige desenvolvedores e clientes comprometidos com atividades rápidas –Nem todos os tipos de aplicações são apropriadas. A abordagem RAD pode não funcionar se o software: não pode ser adequadamente modularizado exigir desempenho superior que deve ser conseguido através de ajustes das interfaces dos componentes –Quando riscos técnicos forem elevados, o RAD não é adequado (novas tecnologias, interoperabilidade com outros sistemas, etc)

52 Estágio II Sistemas de Informação 52 Modelo de Desenvolvimento Rápido da Aplicações – RAD Exemplo de RAD – metodologias ágeis –Extreme programing (XP) Valores definidos na metodologia –Comunicação: a comunicação da equipe deve ser eficaz –Simplicidade: a solução mais simples deve ser a selecionada para resolver o problema –Feedback: o trabalho da equipe deve ser orientado ao feedback do cliente e ao software funcionado –Coragem: as pessoas assumam responsabilidade sobre o trabalho a ser realizado

53 Estágio II Sistemas de Informação 53 Modelo de Desenvolvimento Rápido da Aplicações – RAD Extreme programing (XP) –Práticas: Planejamento do jogo Releases pequenos Uso de metáforas para o projeto de software Design simples Testes automáticos Refactoring Programação em pares Propriedade coletiva do código Integração contínua 40 horas semanais de trabalho Cliente no local Padrão de codificação

54 Estágio II Sistemas de Informação Modelos Evolucionários Modelo Incremental Modelo Espiral Modelo Espiral Ganha-Ganha Modelo Desenvolvimento Concorrente

55 Estágio II Sistemas de Informação 55 Modelos Evolucionários O software evolui durante um período de tempo Requisitos do negócio e do produto mudam freqüentemente, à medida que o desenvolvimento prossegue Prazos reduzidos de mercado exigem versão reduzida Os modelos evolucionários são iterativos e permitem o desenvolvimento de versões cada vez mais completas do software Objetiva a elaboração de um produto operacional a cada incremento

56 Estágio II Sistemas de Informação 56 Modelos Evolucionários Para a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema –Abordagem híbrida Iteração –repetir partes do processo à medida que os requisitos do sistema evoluem –Por exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitos –Cada ciclo desenvolve uma versão mais completa

57 Estágio II Sistemas de Informação 57 Desenvolvimento Evolucionário

58 Estágio II Sistemas de Informação 58 Modelo Incremental Combina cascata com prototipagem Ao invés de entregar o sistema como um produto único, o desenvolvimento e entrega é quebrado em incrementos –Cada seqüência linear produz um incremento factível, operacional do software –Requisitos de usuário são priorizados e os de mais alta prioridade são desenvolvidos primeiro Uma vez que o desenvolvimento é iniciado, os requisitos são congelados, embora os requisitos para os demais incrementos continuem a evoluir É útil quando não há mão-de-obra disponível para uma implementação completa, dentro do prazo estabelecido

59 Estágio II Sistemas de Informação 59 Modelo Incremental Exemplo: Processador de Texto –1o release: gestão básica de arquivos, edição e produção de documentos (núcleo do produto) –2o: capacidades mais sofisticadas de edição –3o: verificação sintática e gramatical –4o: capacidade avançada de disposição de página

60 Estágio II Sistemas de Informação 60 Modelo Incremental

61 Estágio II Sistemas de Informação 61 Modelo Incremental Vantagens –Os clientes não precisam esperar até que todo o sistema seja entregue, para então tirarem proveito dele. O primeiro estágio deve satisfazer os requisitos mais importantes e, assim, o software pode ser imediatamente usado –Os clientes podem utilizar os primeiros incrementos como um protótipo e obter uma experiência que forneça os requisitos para estágios posteriores –Existe um risco menor de fracasso completo do sistema Problemas –– Pode ser difícil mapear os requisitos para incrementos específicos –– É difícil identificar facilidades comuns que todos os incrementos exijam

62 Estágio II Sistemas de Informação 62 Modelo em Espiral Proposto por Boehm, em 1988 O processo não é descrito como uma seqüência de atividades (com eventuais retornos) O processo é representado como uma espiral, onde cada loop representa uma fase do processo. Foi desenvolvido para abranger as melhores características, tanto do ciclo de vida clássico como do de prototipação, acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos

63 Estágio II Sistemas de Informação 63 Modelo em Espiral O Processo Espiral é similar ao Incremental mas –Cada ciclo produz algo a ser avaliado não necessariamente código –Gerência de Riscos embutida no processso Ao final de cada loop é perguntado Devemos continuar? As atividades do modelo em espiral formam uma estrutura chamada de regiões de tarefas

64 Estágio II Sistemas de Informação 64 Modelo em Espiral de Bohem O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Setores da Espiral: –Definição de objetivos, alternativas e restrições Especificação de objetivos para a fase –Identificação e Redução dos Riscos Riscos são identificados e as atividades são levantadas para tratá-los Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, o projeto pode ser cancelado –Desenvolvimento e Validação Um modelo de desenvolvimento para o sistema é escolhida Pode ser qualquer um dos modelos genéricos –Planejamento O projeto é revisado Se a decisão for continuar, um novo loop da espiral é planejado

65 Estágio II Sistemas de Informação Profª Fairus Manfroi65 Modelo em Espiral de Bohem

66 Estágio II Sistemas de Informação 66 Modelo em Espiral de Bohem

67 Estágio II Sistemas de Informação 67 Modelo em Espiral Variações do modelo espiral de Bohem Considera entre três e seis regiões de tarefas ou setores da espiral, que podem ser: –Comunicação com o cliente: Estabelecer efetiva comunicação entre desenvolvedor e cliente –Planejamento: Definir recursos, prazos, objetivos, alternativas, restrições e outras informações do projeto –Análise de risco: Avaliar os riscos técnicos e gerenciais, análise de alternativas –Engenharia: Construir uma ou mais representações da aplicação, desenvolvimento do produto. –Construção e liberação: Construir, testar, instalar e fornecer apoio ao usuário (documentação, treinamento,...) –Avaliação pelo cliente: Obter um feedback do cliente, realimentando o processo.

68 Estágio II Sistemas de Informação 68 Modelo em Espiral

69 Estágio II Sistemas de Informação 69 Modelo em Espiral Um projeto de desenvolvimento conceitual começa no centro da espiral e continua até que o desenvolvimento conceitual se complete Se o conceito tiver que ser transformado em um produto real, o processo prossegue através do próximo ponto de entrada, e um novo projeto de desenvolvimento é iniciado O novo produto evolui em torno da espiral, seguindo o caminho para fora A espiral, caracterizada desse modo, permanece operacional até que o software seja descontinuado

70 Estágio II Sistemas de Informação 70 Modelo em Espiral Cada interação ao redor da espiral possibilita a construção de versões progressivamente mais complexas. –Outros modelos de ciclo de vida podem ser usados para elucidar requisitos, tais como o de prototipagem. O paradigma do modelo espiral é, atualmente, a abordagem mais realística para o desenvolvimento de software de grande porte. Usa uma abordagem evolucionária, capacitando o desenvolvedor e o cliente a entenderem e reagirem aos riscos de cada etapa evolutiva. Usa prototipagem como mecanismo de redução de risco, mas permite aplicar prototipagem em qualquer etapa do processo.

71 Estágio II Sistemas de Informação 71 Modelo em Espiral Vantagens –O modelo em espiral permite que, ao longo de cada iteração, se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos. –Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.

72 Estágio II Sistemas de Informação 72 Modelo em Espiral No entanto... –A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e fia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas. –O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

73 Estágio II Sistemas de Informação 73 Modelo em Espiral ganha-ganha Define um conjunto de atividades de negociação no começo de cada passagem em torno da espiral Ao invés de só uma atividade de comunicação com o cliente, as seguintes atividades são definidas: –Identificação dos principais interessados (stakeholders) do sistema ou subsistema –Determinação das condições de lucro do interessado –Negociação das condições de ganho do interessado para reconciliá-lo no âmbito das condições ganha- ganha para todos os envolvidos

74 Estágio II Sistemas de Informação 74 Modelos Evolucionários – Modelo em Espiral ganha-ganha

75 Estágio II Sistemas de Informação 75 Desenvolvimento Baseado em Componentes Incorpora técnicas de orientação a objetos Incorpora as características do modelo espiral e compõe aplicações a partir de componentes de software previamente desenvolvidos ou desenvolvidos durante o processo. Enfatiza a reutilização, isto é desenvolve para e com reuso. Fases do processo –Análise do Componente; –Modificação dos requisitos; –Projeto do sistema com reuso; –Desenvolvimento e integração.

76 Estágio II Sistemas de Informação 76 Modelo de Métodos Formais Baseado na transformação de uma série de representações matemáticas da especificação em um programa executável. A especificação de requisitos, informal ou semi-formal, é redefinida em uma especificação formal detalhada, utilizando uma notação matemática: –VDM, Z, B, Larch e outras Baseado na transformação de uma especificação matemática através de refinamentos sucessivos até um programa executável –As atividades de design, implementação e testes são substituídas por um processo transformacional. –Transformações devem preservar a correção, isto é, permitem mostrar que o programa está de acordo com a sua especificação –Exemplo mais conhecido: Cleanroom (IBM) Incremental, onde para cada estágio é demonstrada a correção em relação ao anterior

77 Estágio II Sistemas de Informação 77 Modelo de Métodos Formais

78 Estágio II Sistemas de Informação 78 Modelo de Métodos Formais Problemas –Demanda pessoal especializado Como poucos desenvolvedores de software tem o preparo necessário para aplicar métodos formais, torna-se necessário treinamento extensivo –Dificuldade em especificar formalmente alguns aspectos de sistemas Interface com usuário –É difícil usar os modelos como um mecanismo de comunicação, com clientes despreparados tecnicamente Aplicação –Sistemas críticos onde segurança e/ou confiabilidade devem ser garantidas antes mesmo que o sistema entre em operação Eletrônica de aeronaves, dispositivos médicos,... Desenvolvedores que queiram evitar multas caso ocorram falhas (transações financeiras, etc)

79 Estágio II Sistemas de Informação 79 Desenvolvimento orientado ao reuso Baseia-se na reutilização sistemática onde sistemas são integrados a partir de –Componentes existentes (in-house) –Componentes de prateleira [COTS (Commercial- off-the-shelf)] Estágios do processo –Análise dos componentes –Projeto de sistema com reuso –Desenvolvimento e integração Processo promissor, mas existe pouca experiência

80 Estágio II Sistemas de Informação 80 Desenvolvimento orientado ao reuso

81 Estágio II Sistemas de Informação Roteiro Framework RUP

82 Estágio II Sistemas de Informação Rational Unified Process

83 Estágio II Sistemas de Informação 83 Rational Unified Process (RUP) Desenvolvimento do software iterativamente Gerenciamento dos requisitos Uso de arquiteturas baseadas em componentes Modelagem visual do software Verificação da qualidade do software Controle de mudanças do software

84 Estágio II Sistemas de Informação O Valor do Software O software é um parte indispensável no mundo modernoO software é um parte indispensável no mundo moderno –Faz com que as sociedades se conectem melhor –Nos ajuda a criar, acessar e visualizar informação em formas e modos não concebíveis anteriormente. Boa notíciaBoa notícia –A economia mundial depende cada vez mais de software. Notícia ruimNotícia ruim –O pessoal qualificado não consegue acompanhar o mesmo ritmo da demanda. –Softwares estão crescendo em importância, tamanho, complexidade e distribuição. ResultadoResultado –A construção e manutenção de software são difíceis.

85 Estágio II Sistemas de Informação Sintomas e Origem das Causas de Problemas de Desenvolvimento de Software Entendimento impreciso das necessidades dos usuáriosEntendimento impreciso das necessidades dos usuários Falta de habilidade de lidar com a necessidade de mudançasFalta de habilidade de lidar com a necessidade de mudanças Uma descoberta tardia de uma séria falha de projetoUma descoberta tardia de uma séria falha de projeto Software com baixa qualidadeSoftware com baixa qualidade Um processo não confiável de construçãoUm processo não confiável de construção Arquitetura frágilArquitetura frágil Testes insuficientesTestes insuficientes Falha no ataque aos riscosFalha no ataque aos riscos

86 Estágio II Sistemas de Informação Processo Define quem irá fazer o que, quando, e como será alcançado o objetivo.Define quem irá fazer o que, quando, e como será alcançado o objetivo. Requisitos novos ou alterados Sistema novo ou melhorado Processo de Engenharia de Software

87 Estágio II Sistemas de Informação Processo Regras –Prover um guia para as atividades –Especificar que artefatos e quando devem ser desenvolvidos –Direcionar as tarefas dos grupos e indivíduos –Oferecer um critério para monitorar e medir o processo

88 Estágio II Sistemas de Informação Melhores Práticas Desenvolver software iterativamenteDesenvolver software iterativamente Gerenciar requisitosGerenciar requisitos Usar arquiteturas baseadas em componentesUsar arquiteturas baseadas em componentes Modelar o software visualmenteModelar o software visualmente Verificar continuamente a qualidade do softwareVerificar continuamente a qualidade do software Controlar as alterações no softwareControlar as alterações no software

89 Estágio II Sistemas de Informação Best Practices

90 Estágio II Sistemas de Informação 90 Rational Unified Process (RUP) Um modelo de processo derivado do trabalho com UML e processos associados. Normalmente descrito sob 3 perspectivas –Dinâmica: mostra as fases ao longo do tempo; –Estática: mostra as atividades do processo; –Prática: sugere boas práticas.

91 Estágio II Sistemas de Informação RUP –Um processo de engenharia de software –Um framework para outros processos –Utiliza as 6 melhores práticas de desenvolvimento de software

92 Estágio II Sistemas de Informação RUP RUP é uma abordagem dirigida por caso de uso (use-case driven)RUP é uma abordagem dirigida por caso de uso (use-case driven) Casos de uso dirigem inumerosas atividadesCasos de uso dirigem inumerosas atividades –Criação e validação dos modelos de projeto –Definição dos casos de teste no modelo de teste –Planejamento de iterações –Criação do manual do usuário Processo centrado na arquiteturaProcesso centrado na arquitetura

93 Estágio II Sistemas de Informação Histórico Rational Approach Rational Objectory Process 4.0 Objectory Process 3.8 Rational Objectory Process 4.1 Rational Unified Process 5.0 Rational Unified Process 5.5 Rational Unified Process UML 0.8 UML 1.1 UML 1.2 UML 1.3

94 Estágio II Sistemas de Informação RUP Logical View Implemation View Process View Deployment View Use-Case View End_user Functionality Analysts/Tester Behavior System Integrator Performance Scalability Throughput Programmers Software Management System Engineering System Topology Delivery, Installation Communication

95 Estágio II Sistemas de Informação RUP

96 Estágio II Sistemas de Informação Visão Geral Concepção – onde são estabelecidos lógica do domínio da aplicação e escopo do projeto Elaboração – coleta de requisitos mais detalhados, análise e plano para construção do sistema Construção – consiste de várias iterações Transição – teste, ajuste de performance e treinamento de usuário

97 Estágio II Sistemas de Informação Profª Fairus Manfroi97 Rational Unified Process (RUP) Ciclo de vida de desenvolvimento

98 Estágio II Sistemas de Informação RUP - Melhores Práticas Desenvolvimento IterativoDesenvolvimento Iterativo Gerência de RequisitosGerência de Requisitos Arquitetura Baseada em ComponentesArquitetura Baseada em Componentes Modelagem VisualModelagem Visual Verificação Contínua da QualidadeVerificação Contínua da Qualidade Gerência de MudançasGerência de Mudanças

99 Estágio II Sistemas de Informação Desenvolvimento Iterativo O que é desenvolvimento iterativo Desenvolvimento em Cascata Desenvolvimento Iterativo

100 Estágio II Sistemas de Informação Desenvolvimento Iterativo Teste Modelagem de Negócio Requisitos Análise & Projeto Deployment Avaliação Teste Implementação

101 Estágio II Sistemas de Informação Desenvolvimento Iterativo Vantagens –Os riscos são atacados mais cedo –Mudanças nos requisitos –Refinamento de arquitetura –Aprendizado e aprimoramento –Aumento do reuso

102 Estágio II Sistemas de Informação Gerência de Requisitos Dificuldades –Requisitos não são óbvios –Requisitos não são sempre facilmente epresso em palavras –Existem vários tipos de requisitos em diferentes níveis de detalhes –O número de requisitos pode explodir –Requisitos estão interligados –Existem várias pessoas interessadas nos requisitos –Requisitos mudam.

103 Estágio II Sistemas de Informação Gerência de Requisitos Atacando –Analisando o problema –Entendendo as necessidades dos stakeholders –Definindo o sistema –Gerenciando o escopo do projeto –Refinando a definição do sistema –Gerenciando mudança de requisitos

104 Estágio II Sistemas de Informação Arquitetura Baseada em Componentes Desenvolvimento Baseado em Componentes –Definem uma arquitetura modular –Desenvolvidos para reuso –Arquiteturas e componentes prontos

105 Estágio II Sistemas de Informação Arquitetura Baseada em Componentes Suporte ao Desenvolvimento Baseado em Componentes –Com o processo itrativo –Baseado na arquitetura –Através da UML - com pacotes, camadas e subsistemas –Testes graduais

106 Estágio II Sistemas de Informação Arquitetura Baseada em Componentes

107 Estágio II Sistemas de Informação Modelagem Visual

108 Estágio II Sistemas de Informação Modelagem Visual

109 Estágio II Sistemas de Informação Modelagem Visual

110 Estágio II Sistemas de Informação Modelagem Visual Ajuda a entender sistemas complexos Explora e compara alterntivas a um preço baixo Forma uma base para a implementação Facilita a captura dos requisitos Comunica as decisões sem ambiguidades

111 Estágio II Sistemas de Informação Verificação Contínua da Qualidade

112 Estágio II Sistemas de Informação Verificação Contínua da Qualidade O que é qualidade? "...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements as measured by agreed-on measures and criteriaand that is produced by an agreed-on process."

113 Estágio II Sistemas de Informação Verificação Contínua da Qualidade O que é qualidade? Onde está a qualidade? Gerência da qualidade no RUP –Identificar metricas –Identificar medidas –Identificar os pontos que afetam a qualidade o quanto antes

114 Estágio II Sistemas de Informação Gerência de Mudanças

115 Estágio II Sistemas de Informação Gerência de Mudanças Coordenação das Atividades e Artefatos Coordenação das Iterações e Releases Controlando Mudanças de Software –Workspaces isolados reduzem interferências –Estatísticas provêem boas métricas –Mudanças podem ser confinadas e as propagações medidas

116 Estágio II Sistemas de Informação Conceitos Chave

117 Estágio II Sistemas de Informação Elementos do RUP WorkflowWorkflow Workers ou PapelWorkers ou Papel AtividadesAtividades ArtefatosArtefatos

118 Estágio II Sistemas de Informação Elementos do RUP Descrever um Caso de Uso Pacote de Caso de Uso Caso de Uso Responsável por Analista Artefato Informação que é produzida, modificada, ou usada pelo processo Worker Papel desempenhado por um indivíduo ou grupo Atividade Unidade de trabalho

119 Estágio II Sistemas de Informação Disciplina Workflow de atividades correlatas Alguns elementos, como risco e testes, são introduzidos em diferentes disciplinas Relação entre disciplina e modelos

120 Estágio II Sistemas de Informação Disciplina

121 Estágio II Sistemas de Informação Workflow Sequência de atividades que produzem um resultado de valor observável Geralmente expresso em um diagrama de atividade Organização –Disciplinas –Detalhes do Workflow

122 Estágio II Sistemas de Informação Workflow Workflows essenciais (Core Workflows): Engenharia: –Modelagem de Negócio –Requisitos –Análise & Projeto –Implementação –Teste –Deployment Suporte: –Gerência do Projeto –Gerência de Configuração –Ambiente

123 Estágio II Sistemas de Informação Workflow Modelo de Projeto Modelo de Implementação Modelo de Teste realizado pelo implementado pelo Requisitos Implementação Teste Modelo de Caso de Uso Modelagem de Negócio verificado pelo Modelo de Negócio Análise & Projeto

124 Estágio II Sistemas de Informação Workflow

125 Estágio II Sistemas de Informação Workflow Details As atividades não são feitas em sequência Mostra os artefatos necessários e os gerados Agrupa atividades relacionadas de outras disciplinas

126 Estágio II Sistemas de Informação Workflow Details

127 Estágio II Sistemas de Informação Workflow Details

128 Estágio II Sistemas de Informação Workers - Papel Define o comportamento e as responsabilidades de um indivíduo um uma equipe Exercidos por pessoal interno ou externo à equipe de desenvolvimento

129 Estágio II Sistemas de Informação Workers - Papel Exemplos:Exemplos: –Analista de Sistemas –Revisor de Projeto –Testador de desempenho

130 Estágio II Sistemas de Informação Workers - Papel

131 Estágio II Sistemas de Informação Workers - Papel

132 Estágio II Sistemas de Informação Atividade Unidade de trabalho com um propósito claro Utilizado para planejamento e verificação de progresso Passos –Planejando –Executando –Revisando

133 Estágio II Sistemas de Informação Atividade Exemplos:Exemplos: –Identificar casos de uso e atores Worker: Analista de Sistemas –Revisar o projeto Worker: Revisor de Projeto –Executar teste de desempenho Worker: Testador de desempenho

134 Estágio II Sistemas de Informação Atividade

135 Estágio II Sistemas de Informação Atividade A atividade Find use case and actors se decompõe nos passos: –Identificar os atores –Identificar os casos de uso –Descrever a interação entre os atores e uc –Organizar em pacotes –Apresentar o modelo em um diagrama –Avaliar os resultados

136 Estágio II Sistemas de Informação Artefatos Unidade produzida por um atividade Pode assumir as formas: –Modelo (UC Model) –Elemento de Modelo (Ator) –Documento (Visão) –Código (Componente)

137 Estágio II Sistemas de Informação Artefatos

138 Estágio II Sistemas de Informação Artefatos Mantidos por controle de versão Artefatos geralmente não estão na forma de documentos –O artefato esta sempre atualizado Guias e checkpoints –Fornecem uma referência de como fazer –Permitem verificar a qualidade do artefato

139 Estágio II Sistemas de Informação Artefatos Templates –Documento de visão (MS Word)Documento de visão Exemplos –Modelo (Modelo de Caso de Uso, de Projeto, etc) –Documento (Documento da Arquitetura do Software) –Código-Fonte –Executáveis

140 Estágio II Sistemas de Informação Documentos Documentos de Visão Documentos de Risco Documentos de Análise de Negócio (Processo)

141 Estágio II Sistemas de Informação Tool Mentors Guiam a execução das atividades em uma ferramenta –Ex: Documenting the Deployment Model Using Rational Rose

142 Estágio II Sistemas de Informação Fundamentos

143 Estágio II Sistemas de Informação Visão Concordar com o problema a ser resolvido Identificar os stakeholders Definir os limites do sistema Identificar as restrições –Políticas –Econômicas –Ambientais –Praticabilidade –Sistema

144 Estágio II Sistemas de Informação Visão Formular a expressão do problema –O problema –Afeta –O impacto deste é –Uma solução adequada poderia

145 Estágio II Sistemas de Informação Planejamento Software development plan –Bom entendimento do que vai ser criado –Plano da Fase: granularidade alta –Plano de Iteração: granularidade baixa The product is only as good as the plan for the product Charles Fishman The plan is nothing; the planning is everything. Dwight D. Eisenhowe

146 Estágio II Sistemas de Informação Riscos Definição: é uma variavel que pode obter um valor que dificulte ou até mesmo torne o desenv. inviável Tipos –Risco direto –Risco indireto Atributos –Probabilidade de ocorrência –Impacto no projeto

147 Estágio II Sistemas de Informação Riscos Investigando e avaliando riscos –Identificar os riscos –Analisar e priorizar os riscos –Definir estratégias de evasão –Definir estratégias de ataque –Definir estratégias de contingência Indicadores Plano B –Rever os ricos durante a iteração –Rever os riscos no final da iteração

148 Estágio II Sistemas de Informação Tipos de Riscos Riscos de Requisitos Riscos Tecnológicos Riscos de Habilidades Riscos Políticos

149 Estágio II Sistemas de Informação Riscos de Requisitos Ponto inicial do processo de desenvolvimento: Casos de Uso (interação típica que o usuário tem com o sistema) Esboçar esqueleto do modelo conceitual do domínio – Modelo de domínio. Fornece muita compreensão. Ponto inicial para construção de classes Encontrar detalhes importantes e se concentrar neles Construção de Protótipo

150 Estágio II Sistemas de Informação Riscos Tecnológicos Construir um protótipo que experimente as partes da tecnologia que você está pensando em utilizar Como os componentes do projeto se encaixam Dificuldade de serem modificados

151 Estágio II Sistemas de Informação Riscos de Habilidades Treinamento é um bom modo de evitar erros Bom instrutor Treinamento em pequenas porções Se não puder ter consultores, faça revisões de tempo em tempo Leitura e grupos de estudo

152 Estágio II Sistemas de Informação Riscos Políticos Política Corporativa Planos de governo

153 Estágio II Sistemas de Informação Riscos Quem estiver primeiro no campo de batalha e esperar a aparição do inimigo estará descansado para o combate; quem vier depois e tiver de apressar-se, chegará exausto. Sun Tzu

154 Estágio II Sistemas de Informação Business Case Plano econômico para realizar a Visão, isto é, saber se o projeto vale a pena. Avaliação do ROI (Return On Investment) Template

155 Estágio II Sistemas de Informação Arquitetura Artefato: Software Architecture Document Quais são os componentes? Como os componentes se encaixam? Existe algum framework? Visões arquiteturais

156 Estágio II Sistemas de Informação Arquitetura Visão Lógica Usuário final Funcionalidade Visão de Processo Visão de Implementação Visão de Deployment Visão de Casos de Uso Integradores Performance Escalabilidade Engenharia Topologia Instalação Programadores Gerenciamento de Software

157 Estágio II Sistemas de Informação Prototipagem Iterativamente e incrementalmente criar versões do sistema. Verificação dos requisitos Redução de riscos

158 Estágio II Sistemas de Informação Avaliação Regular Foco nos problemas no processo e os problemas no produto

159 Estágio II Sistemas de Informação Mudanças Artefato: Change Request –Provê um histórico das mudanças e das decisões tomadas –Gerenciar o escopo do projeto –Avaliar o impacto das decisões

160 Estágio II Sistemas de Informação Suporte do Usuário Criar um produto utilizável Manuais, ajuda e treinamento

161 Estágio II Sistemas de Informação Processo Adotar um processo que se encaixa ao projeto A produção de artefatos varia de projeto a projeto

162 Estágio II Sistemas de Informação Conclusões Sem visão? –O projeto pode perder escopo ou desviar do propósito Sem processo? –A equipe pode perder a visão de quem esta fazendo o que e quando Sem planejamento? –Você perde a capacidade de rastrear o progresso

163 Estágio II Sistemas de Informação Conclusões Sem controle de riscos? –Você pode focar no ponto errado e pisar em minas Sem Business Case? –Você corre-se o risco de jogar tempo e investimento fora Sem arquitetura? –Podem ocorrer problemas com escalabilidade, falso reuso e performance

164 Estágio II Sistemas de Informação Conclusões Sem prototipagem? –Como você e o usuário saberão que o sistema funciona? Sem avaliação? –Tenha coragem e enfrente a verdade! Sem Change Request? –Como rastrear, priorizar os pedidos do cliente Sem suporte do usuário? –Como o usuário vai obter informação sobre o sistema?

165 Estágio II Sistemas de Informação Concepção Estabelecer o escopo e os limites, com critérios de aceitação bem definidos Discriminar os casos de usos críticos Exibir uma arquitetura candidata Adivinhar o custo e o calendário Preparar o ambiente do projeto

166 Estágio II Sistemas de Informação Concepção - Milestone Examina os objetivos e decide seguir ou cancelar o projeto - Viabilidade Critério de avaliação –Entendimento e acordo com os requisitos –Credibilidade do custo/tempo –Acerto das prioridades

167 Estágio II Sistemas de Informação Concepção - Milestone Produtos:Produtos: –Visão geral dos requisitos do projeto: Modelo de Caso de Uso inicial (10-20%) –Estimativa dos recursos necessários –Mini Mundo

168 Estágio II Sistemas de Informação Elaboração Assegurar que os requisitos e planos estão estáveis Estabelecer uma arquitetura Provar que a arquitetura funciona Produzir um protótipo evolucionário Estabelecer um ambiente

169 Estágio II Sistemas de Informação Elaboração Deve terminar em torno de um quinto do tempo do projeto Desenvolvedores já sentem a vontade para dar estimativas de tempo Todos os riscos significativos foram identificados

170 Estágio II Sistemas de Informação Elaboração - Milestone Examina os objetivos, arquitetura e riscos do projeto Critério de avaliação –Requisitos, visão e arquitetura estáveis –Verificar que, com os protótipos, todos os riscos foram atacados –Planos de Iteração da fase de construção –Despesas atuais batem com estimadas

171 Estágio II Sistemas de Informação Elaboração - Milestone Todos o Stakeholders concordam que a visão atual pode ser alcançada se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual ? Produtos: –Modelo de Caso de Uso (80%) –Plano de desenvolvimento –Avaliação revisada dos riscos –Protótipo da arquitetura

172 Estágio II Sistemas de Informação Construção Atingir qualidade o mais breve possível Desenvolver incrementalmente e lançar as versões de teste (alpha, beta) Completar o desenvolvimento de todos os Casos de Uso

173 Estágio II Sistemas de Informação Construção Estabelecer(detalhar) as iterações e definir que funcionalidades entregar em cada uma delas Casos de Uso com maior prioridade e/ou risco de desenvolvimento primeiro Cada iteração é um mini-projeto: Análise, projeto,codificação, teste e integração As iterações são incrementais na função Integração contínua

174 Estágio II Sistemas de Informação Construção - Milestone Sistema e manual Critério de avaliação –O sistema já esta maduro o suficiente pra ser entregue? –Os stakeholders estão prontos para usá-lo? –Despesas reais versus planejadas continuam aceitaveis?

175 Estágio II Sistemas de Informação Construção - Milestone Produtos: –Modelo de Caso de Uso e de Projeto completos –Manual do usuário –O software integrado e pronto para a utilização dos usuários

176 Estágio II Sistemas de Informação Transição Teste de validação Conversão do ambiente para produção Treinamento de usuários e manutenção Otimização Alcançando auto-suporte do usuário

177 Estágio II Sistemas de Informação Transição - Milestone Os objetivos foram cumpridos Coincide com o fim da fase de concepção de outro ciclo Critério de avaliação –O usuário está satisfeito –Despesas reais versus planejadas continuam aceitaveis?

178 Estágio II Sistemas de Informação Transição - Milestone Produtos: –Versão final do produto –Manual do usuário atualizado –Modelos atualizados

179 Estágio II Sistemas de Informação RUP Gerência do Projeto Ambiente Modelagem do Negócio Implementação Teste Análise & Projeto Preliminary Iteration(s) Iter. #1 Fases Core Workflows Iterações Workflows de Suporte Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Ger. de Configuração Requisitos ElaborationTransitionInceptionConstruction Tempo Workflows de Engenharia

180 Estágio II Sistemas de Informação 180 Rational Unified Process (RUP) Fases 1: Concepção (Inception) Definição do escopo e do business case (caso de negócio) que inclui critérios de sucesso, avaliação de riscos, recursos necessários Plano p/ as fases seguintes incluindo escalonamento Ao fim desta fase os objetivos do projecto são examinados e decisões devem ser tomadas Documentos: overview do problema, use cases principais, glossário inicial, relatório inicial de avaliação de riscos, business case, plano de projeto, protótipos iniciais

181 Estágio II Sistemas de Informação 181 Rational Unified Process (RUP) Fases 2: Elaboração (Elaboration) Analisar o domínio do problema em detalhe Definir uma arquitetura Detalhar o plano de projecto Eliminar os riscos elevados Resultados: requisitos funcionais do sistema (através de use cases) e não funcionais, descrição da arquitetura, resolução dos principais riscos, decisão p/ proceder c/ a construção

182 Estágio II Sistemas de Informação 182 Rational Unified Process (RUP) Fases 3: Construção (Construction) Desenvolvimento detalhado do desenho, implementação, integração dos componentes, e testes exaustivos É prestada atenção ao controlo de custos, prazos e qualidade do produto

183 Estágio II Sistemas de Informação 183 Rational Unified Process (RUP) Fases 4: Transição (Transition) O software (versão beta) é entregue aos utilizadores Substituído posteriormente pelo sistema de produção

184 Estágio II Sistemas de Informação 184 Rational Unified Process (RUP) Artefatos Modelo do negócio (da organização) Modelo do domínio (contexto) Modelo de use case (requisitos funcionais) Modelo de análise Modelo de desenho Modelo de processo (concorrência e sincronização) Modelo de instalação (topologia do HW) Modelo de implementação Modelo de teste

185 Estágio II Sistemas de Informação 185 Abordagens para nortear o desenvolvimento de software Desenvolvimento Orientado a Função: –O sistema é visto como um conjunto de funções; –O sistema consiste em uma decomposição progressiva de funções de sua funcionalidade; –As funções cada vez mais simples, resultantes da decomposição, são implementadas. Desenvolvimento Orientado a Evento: –O sistema é particionado de acordo com os evento que ocorrem no seu ambiente, os quais devem ser adequadamente respondidos. Desenvolvimento Orientado a Dados: –A atenção é voltada à definição de uma estrutura de dados; –As funções são construídas em torno das abstrações de dados.

186 Estágio II Sistemas de Informação 186 Abordagens para nortear o desenvolvimento de software Desenvolvimento Orientado a Objetos (DOO): –Na abordagem orientada a objetos um sistema é construído como um conjunto de Objetos (entidades) interativos que encapsulam dados e operações que atuam sobre estes dados. –A orientação a objetos baseia-se na abstração dos dados e ocultamento da informação. Desenvolvimento Orientado a Aspectos (DSOA ) –o pensamento inteligente é capaz de estudar um aspecto de determinado problema isoladamente, mas sabendo o tempo todo que outros aspectos estão esperando sua vez. –DSOA é uma técnica para melhorar a separação de concerns na construção de software e apoiar ao aumento da reusabilidade e facilidade de evolução. –Apóia a modularização de crosscutting concerns por meio de abstrações que possibilitam a sua separação e composição para produzir o sistema. –Nova forma de abstração e novo mecanismo para compor aspectos e classes.

187 Estágio II Sistemas de Informação Roteiro Métodos Ágeis

188 Estágio II Sistemas de Informação Copyleft Fabio Kon188 / 47 Novos ventos no mundo do Desenvolvimento de Software Sociedade demanda –grande quantidade de sistemas/aplicações –software complexo, sistemas distribuídos, heterogêneos –requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, –não há gente suficiente para desenvolver tanto software com qualidade.

189 Estágio II Sistemas de Informação Copyleft Fabio Kon189 / 47 Problemas Com metodologias de desenvolvimento –Supõem que é possível prever o futuro –Pouca interação com os clientes –Ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.) –Avaliação do progresso baseado na evolução da burocracia e não do código Com software –Grande quantidade de erros –Falta de flexibilidade

190 Estágio II Sistemas de Informação Copyleft Fabio Kon190 / 47 Como resolver esse impasse? Melhores Tecnologias –Padrões de Projeto (reutilização de idéias) –Componentes (reutilização de código) –Middleware (aumenta a abstração) Melhores Metodologias –Métodos Ágeis (o foco nesta disciplina) –outras... (abordadas, p.ex., na disciplina ES)

191 Estágio II Sistemas de Informação Copyleft Fabio Kon191 / 47 Metodologias de Desenvolvimento de Software OO Tradicionais –Comunidade de Engenharia de Software –IEEE/ACM ICSE –p.ex. Carnegie-Mellon SEI –RUP, CMM, etc. Ágeis –Comunidade de POO –ACM OOPSLA –p.ex. Illinois, Beck, Cockburn, Jeffries, Cunningham… –XP, Crystal, Scrum, etc.

192 Estágio II Sistemas de Informação Copyleft Fabio Kon192 / 47 Métodos Ágeis de Desenvolvimento de Software Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Questionam e se opõe a uma série de mitos/práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos. Manifesto Ágil: Assinado por 17 desenvolvedores em Utah em fevereiro/2001.

193 Estágio II Sistemas de Informação Copyleft Fabio Kon193 / 47 O Manifesto do Desenvolvimento Ágil de Software 1.Indivíduos e interações são mais importantes que processos e ferramentas. 2.Software funcionando é mais importante do que documentação completa e detalhada. 3.Colaboração com o cliente é mais importante do que negociação de contratos. 4.Adaptação a mudanças é mais importante do que seguir o plano inicial.

194 Estágio II Sistemas de Informação Copyleft Fabio Kon194 / 47 Princípios do Manifesto Ágil Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor. –Entregar versões funcionais em prazos curtos. –Estar preparado para requisitos mutantes. –Pessoal de negócios e desenvolvedores juntos. –Troca de informações através de conversas diretas.

195 Estágio II Sistemas de Informação Copyleft Fabio Kon195 / 47 Principais Métodos Ágeis Nesta disciplina veremos: –Programação eXtrema (XP) Outros métodos ágeis interessantes: –Crystal (uma família de métodos) –Scrum –Adaptive Software Development –Feature Driven Development –etc.

196 Estágio II Sistemas de Informação Gerência de Projetos com Metodologias Ágeis e Scrum

197 Estágio II Sistemas de Informação Gerência de Projetos com Metodologias Ágeis e Scrum Introdução Por que métodos ágeis? Controle Empírico de Processos Scrum –Artefatos do Scrum –Papéis do Scrum –Regras do Scrum Métodos Tradicionais versus Métodos Ágeis Conclusão

198 Estágio II Sistemas de Informação Introdução Controle empírico para projetos complexos Projetos não completamente definidos e que precisam ser executados com urgência Scrum: uma metodologia ágil –Projetos complexos e variáveis no tempo –Descentralização do controle –Igualdade de responsabilidade

199 Estágio II Sistemas de Informação Por que métodos ágeis? Urgência e alta complexidade Métodos tradicionais –Refletem a complexidade do problema na sua gerência –Falham na gerência de projetos que não podem ser totalmente especificados –Gerente de Projetos: ponto único de falhas –Analogia ao desenvolvimento de softwares de forma estática e monolítica

200 Estágio II Sistemas de Informação Por que métodos ágeis? Métodos ágeis –Valiosos no tratamento de projetos parcialmente definidos –Resultado incremental aumenta ROI (return on investiment) Stakeholders podem visualizar/utilizar os resultados Tem maior poder de escolha dos caminhos do projeto –Decisões baseadas em fatos Melhor do que qualquer previsão Decisão distribuída entre os envolvidos no projeto (não apenas o gerente)

201 Estágio II Sistemas de Informação Controle Empírico de Processo Problemas complexos são aqueles imprevisíveis –Gerenciá-los através de métodos tradicionais e modelos probabilísticos seria muito complexo Sociedade é baseada em processos que funcionam porque há um grau de imprecisão aceitável

202 Estágio II Sistemas de Informação Controle Empírico de Processo Para produtos que precisam uma precisão maior do que a média –É preciso se certificar a cada passo se o processo está convergindo –Projetar um processo que repetidamente produz um produto de qualidade aceitável é chamado de controle definido de processo –Utiliza-se controle definido sempre que os mecanismos pelos quais os processos operam são bem entendidos –Analogia a commodities: processo bem definido e imutável Quando um controle definido não pode ser aplicado devido à sua complexidade, algo como controle empírico de processos deverá ser aplicado

203 Estágio II Sistemas de Informação Bases do Controle Empírico de Processo Visibilidade –Aspectos do projeto que afetam a sua execução precisam ser visíveis e verdadeiros –Permite o controle do processo Inspeção –Diversos aspectos do projeto precisam ser inspecionados em uma freqüência suficiente –Variações não aceitáveis devem ser detectadas Adaptação –Se determinado que algum aspecto está fora dos limites aceitáveis, deve-se adaptá-lo rapidamente para minimizar desvios futuros

204 Estágio II Sistemas de Informação Scrum Uma alternativa de utilizar métodos ágeis na gerência de projetos Aplicável especificamente a projetos de softwares É um processo simples –Processo, artefatos e regras são poucas e fáceis de entender Simplicidade deste pode ser decepcionante aos acostumados com metodologias tradicionais –As vezes é difícil fazer com que as simples regras sejam corretamente aplicadas

205 Estágio II Sistemas de Informação Scrum Não é um método prescritivo –Não define previamente o que deve ser feito em cada situação –Projetos complexos não permitem prever todos os eventos Define um framework e um conjunto de práticas que permitem as bases do controle empírico Aplica o senso comum –Combinação de experiência, treinamento, confiança e inteligência de toda a equipe –Senso comum em vez do senso de uma única pessoa é uma das razões do sucesso do Scrum

206 Estágio II Sistemas de Informação Esqueleto e Coração do Scrum

207 Estágio II Sistemas de Informação Artefatos do Scrum: Product Backlog Lista priorizada dos requisitos do projeto com o tempo estimado para torná-los em funcionalidade Estimativas em dias, sendo mais precisas para itens mais prioritários Mudanças podem ser feitas de acordo com as necessidades que aparecem Nunca está completo, sendo que o utilizado no plano de projeto é meramente uma estimativa inicial dos requisitos O responsável é o Product Owner

208 Estágio II Sistemas de Informação Artefatos do Scrum: Product Backlog Qualquer membro do time pode adicionar ou remover itens –Com consentimento do Product Owner São requisitos funcionais ou não-funcionais, ou qualquer tópico de discussão Os itens com maior prioridade serão selecionados para o próximo Sprint Quanto menos prioritários, mais abstratos são os itens Podem existir muito mais requisitos que não foram ainda listados ou nem pensados É atualizado pelo Product Owner sempre que necessário –Permite a adaptabilidade do processo

209 Estágio II Sistemas de Informação Artefatos do Scrum: Product Backlog

210 Estágio II Sistemas de Informação Artefatos do Scrum: Sprint Backlog Lista de tarefas que define o trabalho do time durante o Sprint Cada tarefa identifica o responsável que irá trabalhar sobre ela e o restante do tempo estimado para terminá-la em dias Tarefas devem estar organizadas para que estejam em 4 a 16 horas de trabalho Tarefas maiores são consideradas placeholders –Substituições de tarefas que não foram propriamente definidas Apenas o time pode modificá-lo É como uma fotografia do trabalho do Sprint

211 Estágio II Sistemas de Informação Artefatos do Scrum: Sprint Backlog

212 Estágio II Sistemas de Informação Artefatos do Scrum: Gráfico de Burndown Representa o trabalho total restante dentro de um Sprint, de um release ou produto A origem dos dados para criar este gráfico é o Sprint Backlog ou o Product Backlog

213 Estágio II Sistemas de Informação Artefatos do Scrum: Potentially Shippable Increment Um incremento é uma funcionalidade do produto desenvolvida pelo time durante o Sprint Deve ser um incremento completamente desenvolvido, que contenha as características de um produto finalizado Product Owner pode escolher implementar imediatamente a funcionalidade desenvolvida –Cada incremento deve ter sido bem codificado, testado e documentado

214 Estágio II Sistemas de Informação Papéis no Scrum: Product Owner Responsável por apresentar os interesses de todos os stakeholders Define fundamentos iniciais do projeto, objetivos com relação ao ROI e planos de release A lista de requerimentos é o Product Backlog Certifica se as atividades com maior valor para o negócio são criadas primeiro –Priorização freqüente das funcionalidades antes de cada iteração

215 Estágio II Sistemas de Informação Papéis no Scrum: Time Responsável por escolher as funcionalidades a serem desenvolvidas e cada interação e desenvolvê-las O time se auto-gerencia, se auto-organiza Todos os membros do time são coletivamente responsáveis pelo sucesso de cada iteração

216 Estágio II Sistemas de Informação Papéis no Scrum: ScrumMaster Responsável pelo sucesso do Scrum Ensina o Scrum para os envolvidos com o projeto Implementa o Scrum na empresa de forma adaptada a sua cultura, para continuamente gerar benefícios Certifica se cada pessoa envolvida está seguindo seus papéis e as regras do Scrum Certifica que pessoas não responsáveis não interfiram no processo

217 Estágio II Sistemas de Informação Papéis no Scrum Todas as responsabilidades de gerenciamento são divididas entre estes três papéis Para o bom funcionamento do Scrum as pessoas responsáveis pelo projeto devem ter autoridade para fazer o que for necessário pelo sucesso desse Pessoas não responsáveis não podem interferir no projeto –Gera aumento de produtividade –Propicia o momentum (cada interferência tem o tempo certo para ser feita) –Evita situações constrangedoras para os envolvidos

218 Estágio II Sistemas de Informação Regras do Scrum ScrumMaster deve se certificar de que cada envolvido no projeto siga suas regras As regras permitem a execução correta do Scrum Mudanças das regras devem originar do time –ScrumMaster deve ser convencido de que todos envolvidos entenderam suficientemente as regras do Scrum para o correto discernimento –Discussões desnecessárias são perdas de tempo de produção da equipe

219 Estágio II Sistemas de Informação Regras do Scrum: Sprint Planning Meeting A reunião de planejamento do Sprint deve ocorrer dentro de 8 horas com duas partes de 4 horas Primeiro seguimento: –Product Owner deve preparar o Product Backlog antes da reunião –Seleção dos itens do Product Backlog que o time se compromete em torná-los incrementos potencialmente implementáveis –Decisão final é do Product Owner –Stakeholders não devem participar

220 Estágio II Sistemas de Informação Regras do Scrum: Sprint Planning Meeting Segundo seguimento: –Ocorre imediatamente após o primeiro –Product Owner deve estar disponível para o que o time faça perguntas sobre o Product Backlog –O time deve decidir sozinho como os itens selecionados serão implementados –Nenhum outro participante pode fazer perguntas ou observações nesta parte –Resultado deste seguimento é o Sprint Backlog

221 Estágio II Sistemas de Informação Regras do Scrum: Reunião Diária do Scrum Reunião de no máximo 15 minutos, a menos que o time seja grande o suficiente para precisar de mais tempo Deve ser feita no mesmo lugar onde o time trabalha Resulta em melhores resultados se realizada no inicio do dia de trabalho Todos os membros do time devem participar desta reunião

222 Estágio II Sistemas de Informação Regras do Scrum: Reunião Diária do Scrum ScrumMaster faz as seguintes perguntas para cada membro do time: –O que você fez desde a última reunião diária do Scrum relacionada a este projeto? –O que você irá fazer desde agora até a próxima reunião diária do Scrum relacionada a este projeto? –O que está impedindo você de realizar o seu trabalho o mais efetivamente possível? Os membros devem responder apenas a estas perguntas para não estender a reunião

223 Estágio II Sistemas de Informação Regras do Scrum: Sprint Não deve ser maior do que 30 dias consecutivos Sem considerar outros fatores, este é o tempo necessário para produzir algo de interesse para o Product Owner e os stakeholders O time pode pesquisar e requisitar ajuda externa Ninguém deve prover conselhos, comentários ou direções ao time durante o Sprint –O time se auto-gerencia O time se compromete com o Product Backlog –Não é permitida modificações nele durante o Sprint

224 Estágio II Sistemas de Informação Regras do Scrum: Sprint Responsabilidades do time durante o Sprint: –Participar das reuniões diárias do Scrum –Manter o Sprint Backlog atualizado –Disponibilizar o Sprint Backlog publicamente O time tem o compromisso de implementar todos os itens selecionados

225 Estágio II Sistemas de Informação Regras do Scrum: Reunião de Revisão do Sprint Reunião de no máximo 4 horas sob responsabilidade do ScrumMaster O time não deve gastar mais de 1 hora na preparação desta reunião Objetivo: mostrar o Product Owner e stakeholders as funcionalidades que foram feitas Artefatos não devem ser apresentados, pois não são funcionalidades No final da reunião –Cada stakeholder fala suas impressões e sugere mudanças com suas respectivas prioridades –Possíveis modificações no Product Backlog são discutidas entre o Product Owner e o time –ScrumMaster anuncia a data e o local da próxima reunião de revisão do Sprint ao Product Owner e a todos stakeholders

226 Estágio II Sistemas de Informação Regras do Scrum: Reunião Retrospectiva do Sprint Não deve ser maior do que 3 horas. Participam desta reunião: time, o ScrumMaster e, opcionalmente, o Product Owner Os membros do time devem responder a duas questões: –O que aconteceu de bom durante o último Sprint? –O que pode ser melhorado para o próximo Sprint? ScrumMaster escreve as respostas e prioriza na ordem que deseja discutir as potenciais melhorias ScrumMaster neste reunião tem o papel de facilitar que o time encontre melhores formas de aplicar o Scrum

227 Estágio II Sistemas de Informação Métodos Tradicionais versus Métodos Ágeis Métodos Tradicionais –Gerente de projetos controla cada atividade –Pré-definição de cada solução e atividade –Antecipação de situações de risco, permitindo bem tratá- las –Documentação extensa –Projetos que podem ser totalmente previstos Métodos Ágeis –Descentralização do controle –Definição incremental de soluções e atividades –Situações de risco são percebidas no inicio de cada ciclo –Documentação reduzida –Projetos parcialmente definidos (definição tardia)

228 Estágio II Sistemas de Informação Métodos Tradicionais versus Métodos Ágeis Situações em que Métodos Ágeis e Scrum não podem ser aplicados: –Projetos críticos que exigem alto grau de confiabilidade e qualidade (ex: projeto de um software controlador de vôos) –Quando se deseja terceirização da mão-de-obra de programação, há a necessidade de uma documentação bem definida –Equipes com membros dispersos pelo mundo não podem realizar o Daily Scrum Meeting, não sendo possível aplicá-lo (equipes muito grandes também problemas) –Quando o Product Owner não pode estar tão presente freqüentemente, o Scrum também é inviabilizado

229 Estágio II Sistemas de Informação Métodos Tradicionais versus Métodos Ágeis Métodos Ágeis geram bons resultados em: –Equipes pequenas de desenvolvimento (até 15 membros) Pode-se aplicar Meta-Scrum para equipes maiores –Equipes competentes Capacidade de auto-gerenciamento não é uma virtude tão comum –Projetos complexos porém que se possa consultar os interessados sempre que necessário

230 Estágio II Sistemas de Informação Conclusão Projetos complexos e urgentes necessitam de uma nova abordagem Scrum é uma boa solução de controle empírico –É eficiente quando as regras e os papéis são bem seguidos –Apesar da sua simplicidade, as pessoas costumam não aceitar facilmente a nova abordagem –Há diversos casos de sucesso Deve-se considerar as condições da equipe e a características dos projetos antes de uma migração –Sistemas operacionais e controles de automóveis continuaram seguindo a abordagem tradicional

231 Estágio II Sistemas de Informação Bibliografia SCHWABER, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, MOUNTAIN GOAT SOFTWARE. The Scrum Process Development. Disponível em:. Acesso em: Setembro, SUTHERLAND, Jeff. ScrumWeb Home Page: A Guide to the SCRUM Development Process. Jeff Sutherlands Object Technology Web Page. Disponível em:. Acesso em: Setembro, 2006.

232 Estágio II Sistemas de Informação Copyleft Fabio Kon232 / 47 Scrum Jeff Suttherland –http://jeffsutherland.com Ken Schwaber –http://www.controlchaos.com Conferências –OOPSLA 96, PLoP 98 Inspiração –Desenvolvimento Iterativo e Incremental em empresas (DuPont, Honda, etc) nos anos 80

233 Estágio II Sistemas de Informação Copyleft Fabio Kon233 / 47 Programação eXtrema XP Metodologia de desenvolvimento de software aperfeiçoada nos últimos 5 anos. Ganhou notoriedade a partir da OOPSLA2000. Nome principal: Kent Beck.

234 Estágio II Sistemas de Informação XP – Princípios e técnicas Teste automatizado contínuo Integração contínua Alto envolvimento do usuário Programação por times Atenção específica às limitações e interações humanas

235 Estágio II Sistemas de Informação Abordagem no desenvolvimento com Extreme Programming

236 Estágio II Sistemas de Informação Comparação de Ciclos de Vida Desenvolvimento Tradicional, Espiral, e XP

237 Estágio II Sistemas de Informação Copyleft Fabio Kon237 / 47 Reações a XP Alguns odeiam, outros amam. Quem gosta de programar ama! Deixa o bom programador livre para fazer o que ele faria se não houvesse regras. Força o [mau] programador a se comportar de uma forma similar ao bom programador.

238 Estágio II Sistemas de Informação 238 / 47 Premissas Básicas do Modelo Tradicional É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

239 Estágio II Sistemas de Informação 239 / 47 O que está por trás deste modelo? Custo de mudanças requisitos desenho testes análise implementação produção

240 Estágio II Sistemas de Informação 240 / 47 E se a realidade hoje em dia fosse outra? Custo de mudanças tempo

241 Estágio II Sistemas de Informação 241 / 47 E se essa fosse a realidade? A atitude dos desenvolvedores de software seria completamente diferente: –Tomaríamos as grandes decisões o mais tarde possível. –Implementaríamos agora somente o que precisamos agora. –Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

242 Estágio II Sistemas de Informação 242 / 47 E essa é a nova realidade ! (pelo menos em muitos casos) Orientação a Objetos: facilita e cria oportunidades para mudanças. Técnicas de Refatoração. Testes automatizados: nos dão segurança quando fazemos mudanças. Prática / cultura de mudanças: aprendemos técnicas e adquirimos experiência em lidar com código mutante.

243 Estágio II Sistemas de Informação 243 / 47 A Quem se Destina XP? Grupos de 2 a 10 programadores Projetos de 1 a 36 meses (calendário) De 1000 a linhas de código Papéis: –Programadores (foco central)(sem hierarquia) –Treinador ou Técnico (coach) –Acompanhador (tracker) –Cliente

244 Estágio II Sistemas de Informação 244 / 47 E Se Eu Não Me Encaixo Nesses Casos? Você ainda pode aprender muito sobre desenvolvimento de software. Terá elementos para repensar as suas práticas. No início se dizia: –Ou você é 100% eXtremo ou não é eXtremo. Não dá prá ser 80% XP. –XP is like teenage sex. Hoje não é mais necessariamente assim.

245 Estágio II Sistemas de Informação 245 / 47 As 12 Práticas de XP (versão 2000) 1.Planejamento 2.Fases Pequenas 3.Metáfora 4.Design Simples 5.Testes 6.Refatoração 7.Programação Pareada 8.Propriedade Coletiva 9.Integração Contínua 10.Semana de 40 horas 11.Cliente junto aos desenvolvedores 12.Padronização do código

246 Estágio II Sistemas de Informação 246 / 47 Princípios Básicos de XP Feedback rápido Simplicidade é o melhor negócio Mudanças incrementais Carregue a bandeira das mudanças / não valorize o medo (Embrace change) Alta qualidade do código

247 Estágio II Sistemas de Informação 247 / 47 As 4 Variáveis do Desenvolvimento de Software Tempo Custo Qualidade Escopo (foco principal de XP)

248 Estágio II Sistemas de Informação 248 / 47 Um Projeto XP Fase de Exploração –duração: 2 a 6 meses. –termina quando a primeira versão do software é enviada ao cliente. –clientes escrevem historias (story cards). –programadores interagem com clientes e discutem tecnologias. –Não só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. –Planejamento: 1 a 2 dias.

249 Estágio II Sistemas de Informação 249 / 47 Um Dia na Vida de um Programador XP Escolhe uma história do cliente. Procura um par livre. Escolhe um computador para programação pareada. Seleciona um cartão de história contendo uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

250 Estágio II Sistemas de Informação 250 / 47 Um Dia na Vida de um Programador XP Discute modificações recentes no sistema Discute história do cliente Testes Implementação Projeto (design) Integração

251 Estágio II Sistemas de Informação 251 / 47 Um Dia na Vida de um Programador XP Atos constantes no desenvolvimento: –Executa testes antigos. –Busca oportunidades para simplificação. –Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no momento. –Escreve novos testes. –Enquanto todos os testes não rodam a 100%, o trabalho não está terminado. –Integra novo código ao repositório.

252 Estágio II Sistemas de Informação 252 / 47 Testes Fundamento mais importante de XP. É o que dá segurança e coragem ao grupo. Testes de unidades (Unit tests) –escritos pelos programadores para testar cada elemento do sistema (e.g., cada método em cada caso). Testes de funcionalidades (Functional tests) –escritos pelos clientes para testar a funcionalidade do sistema.

253 Estágio II Sistemas de Informação 253 / 47 Testes Testes das unidades do sistema –Tem que estar sempre funcionando a 100%. –São executados várias vezes por dia. –Executados à noite automaticamente. Testes das funcionalidades –Vão crescendo de 0% a 100%. –Quando chegam a 100% acabou o projeto.

254 Estágio II Sistemas de Informação 254 / 47 O Código Padrões de estilo adotados pelo grupo inteiro. O mais claro possível. –XP não se baseia em documentações detalhadas e extensas (perde-se sincronia). Comentários sempre que necessários. Comentários padronizados. Programação Pareada ajuda muito!

255 Estágio II Sistemas de Informação 255 / 47 Programação Pareada Erro de um detectado imediatamente pelo outro (grande economia de tempo). Maior diversidade de idéias, técnicas, algoritmos. Enquanto um escreve, o outro pensa em contra-exemplos, problemas de eficiência, etc. Vergonha de escrever código feio (gambiarras) na frente do seu par. Pareamento de acordo com especialidades. Ex.: Sistema Multimídia Orientado a Objetos

256 Estágio II Sistemas de Informação 256 / 47 Propriedade Coletiva do Código Modelo tradicional: só autor de uma função pode modificá-la. XP: o código pertence a todos. Se alguém identifica uma oportunidade para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça. Mas rode os testes!

257 Estágio II Sistemas de Informação 257 / 47 Refatoração (Refactoring) Uma [pequena] modificação no sistema que não altera o seu comportamento funcional mas que melhora alguma qualidade não- funcional: –simplicidade –flexibilidade –clareza –desempenho

258 Estágio II Sistemas de Informação 258 / 47 Exemplos de Refatoração Mudança do nome de variáveis Mudanças nas interfaces dos objetos Pequenas mudanças arquiteturais Encapsular código repetido em um novo método Generalização de métodos raizQuadrada(float x) raiz(float x, int n)

259 Estágio II Sistemas de Informação 259 / 47 Cliente Responsável por escrever histórias. Muitas vezes é um programador ou é representado por um programador do grupo. Trabalha no mesmo espaço físico do grupo. Novas versões são enviadas para produção todo mês (ou toda semana). Feedback do cliente é essencial. Requisitos mudam (e isso não é mau).

260 Estágio II Sistemas de Informação 260 / 47 Coach (treinador) Em geral, o mais experiente do grupo. Identifica quem é bom no que. Lembra a todos as regras do jogo (XP). Eventualmente faz programação pareada. Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias. Seu papel diminui à medida em que o time fica mais maduro.

261 Estágio II Sistemas de Informação 261 / 47 Tracker (Acompanhador) A consciência do time. Coleta estatísticas sobre o andamento do projeto. Alguns exemplos: Número de histórias definidas e implementadas. Número de unit tests. Número de testes funcionais definidos e funcionando. Número de classes, métodos, linhas de código Mantém histórico do progresso. Faz estimativas para o futuro.

262 Estágio II Sistemas de Informação Quando usar XP Equipes de projeto pequenas (12 ou menos) Pessoal de desenvolvimento bem treinado e talentoso Escopo limitado nos projetos –Aplicatipos que rodarão sózinhos –Novos sistemas –Interface mínimo com sistemas legados Uso extensivo de ferramentas de desenvolvimento e de testes orientadas a objeto.

263 Estágio II Sistemas de Informação Copyleft Fabio Kon263 / 47 Quando XP Não Deve Ser Experimentada? Quando o cliente não aceita as regras do jogo. Quando o cliente quer uma especificação detalhada do sistema antes de começar. Quando os programadores não estão dispostos a seguir (todas) as regras. Se (quase) todos os programadores do time são medíocres.

264 Estágio II Sistemas de Informação Copyleft Fabio Kon264 / 47 Quando XP Não Deve Ser Experimentada? Grupos grandes (>10 programadores). Quando feedback rápido não é possível: –sistema demora 6h para compilar. –testes demoram 12h para rodar. –exigência de certificação que demora meses. Quando o custo de mudanças é essencialmente exponencial. Quando não é possível realizar testes (muito raro).

265 Estágio II Sistemas de Informação Copyleft Fabio Kon265 / 47 Conclusão Vencendo os Medos Escrever código. Mudar de idéia. Ir em frente sem saber tudo sobre o futuro. Confiar em outras pessoas. Mudar a arquitetura de um sistema em funcionamento. Escrever testes.

266 Estágio II Sistemas de Informação Copyleft Fabio Kon266 / 47 As 12 Práticas de XP (versão 2000) 1.Planejamento 2.Fases Pequenas 3.Metáfora 4.Design Simples 5.Testes 6.Refatoramento 7.Programação Pareada 8.Propriedade Coletiva 9.Integração Contínua 10.Semana de 40 horas 11.Cliente junto aos desenvolvedores 12.Padronização do código

267 Estágio II Sistemas de Informação Copyleft Fabio Kon267 / 47 Práticas de XP As práticas foram refatoradas (veja Mas a idéia é exatamente a mesma Novas práticas interessantes: Conserte XP quando a metodologia quebrar. Mova as pessoas. Client Proxy (by Klaus)

268 Estágio II Sistemas de Informação Copyleft Fabio Kon268 / 47 Conclusão XP não é para todo mundo. Mas todo mundo pode aprender com ela.

269 Estágio II Sistemas de Informação Copyleft Fabio Kon269 / 47 Características Comuns dos Métodos Ágeis Coloca o foco –Na entrega freqüente de sub-versões do software [funcionando] para o cliente. –Nos seres humanos que desenvolvem o software. Retira o foco de –Processos rígidos e burocratizados. –Documentações e contratos detalhados. –Ferramentas que são usadas pelos seres humanos.

270 Estágio II Sistemas de Informação Copyleft Fabio Kon270 / 47 Maiores Informações

271 Estágio II Sistemas de Informação Roteiro Trabalhos

272 Estágio II Sistemas de Informação Exercícios em Sala Arquitetura de Computadores

273 EXERCÍCIO 1: Aula 1 (1 ponto) Questões: 1.Monte uma tabela comparativa (+/-) entre os diferentes processos de desenvolvimento: –Cascata, Incremental / RUP, XP, Scrum 2.Ilustre situações em que cada um dos processos de desenvolvimento seria melhor indicado. Detalhamento Detalhamento: Trabalho a ser desenvolvido em equipes de até 4 pessoas; Pontuação: relevância e aderência ao tema, criatividade, capacidade de raciocínio e visão de mercado / pesquisa; Forma de trabalho: Folha avulsa; Data de entrega: Diária. Sugestão: ilustrar com exemplos.

274 Exercícios em Casa Estágio II

275 TRABALHO 1: Aula 1 (1 ponto) Descrição: 1.Monte um Documento de Visão Técnica para um sistema escolhido. –O sistema deve ter funcionalidades como acessibilidade Web, arquitetura em camadas, múltiplos perfis de usuário. –Apresente igualmente a WBS do sistema. Detalhamento Detalhamento: Trabalho a ser desenvolvido em equipes de até 4 pessoas; Pontuação: relevância e aderência ao tema, criatividade, capacidade de raciocínio e visão de mercado / pesquisa; Forma de trabalho: Folha avulsa; Data de entrega: Diária. Sugestão: ilustrar com exemplos.

276 Estágio II Sistemas de Informação Grato pela Atenção FA7– Fortaleza, 02/01/10


Carregar ppt "Faculdade 7 de Setembro Metodologias de Desenvolvimento Paulo Benício."

Apresentações semelhantes


Anúncios Google