SEMINÁRIOS INTEGRADOS EM SISTEMAS DE INFORMAÇÃO. Unidade 6 Engenharia de Software. Luiz Leão

Transcrição

1 SEMINÁRIOS INTEGRADOS EM SISTEMAS DE INFORMAÇÃO Unidade 6 Engenharia de Software Luiz Leão luizleao@gmail.com

2 Conteúdo Programático Padrões de desenvolvimento Métricas de desenvolvimento Aspectos de qualidade de Software

3 Processos de Desenvolvimento

4 Ciclo de Vida do Software Foi proposto como uma resposta aos problemas encontrados no modelo em cascata. Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Essa característica contrasta com a abordagem clássica, na qual as fases de análise, projeto, implementação e testes são realizadas uma única vez.

5 Introdução Modelo Iterativo Incremental

6 Introdução Iterativo: Corresponde à ideia de melhorar pouco - a - pouco o sistema. Em cada iteração a equipe de desenvolvimento identifica e especifica os requisitos relevantes, cria um projeto utilizando a arquitetura escolhida, implementa o projeto em componentes, procurando sempre satisfazer os requisitos.

7 Introdução Iterativo: Se uma iteração atinge os seus objetivos, o desenvolvimento prossegue com a próxima iteração, caso contrário a equipe deve rever as suas decisões e tentar uma nova abordagem. O objetivo do sistema não é alterado, mas o seu detalhe vai aumentando em iterações sucessivas. Um excelente exemplo de aplicação do processo iterativo encontra-se no trabalho artístico, em que o resultado final de uma obra sofre inúmeras iterações.

8 Introdução Iterativo: Ciclo de Vida Iterativo

9 Introdução Incremental: Corresponde à ideia de aumentar pouco-a-pouco o sistema. Uma boa imagem para este atributo é a de uma mansão que foi construída por sucessivos incrementos a partir de uma primeira casa com apenas duas divisões.

10 Introdução Incremental: Um incremento não é necessariamente a adição do código executável correspondente aos casos de uso que pertencem à iteração em andamento. Especialmente nas primeiras fases do ciclo de desenvolvimento, os desenvolvedores podem substituir um projeto superficial por um mais detalhado ou sofisticado. Em fases avançadas os incrementos são tipicamente aditivos.

11 Introdução Incremental: Ciclo de Vida Incremental

12 Apresentação RUP (Rational Unified Process) Desenvolvido pela Rational Software Corporation em, adquirida pela IBM. Começou com o Rational Objectory Process (ROP). Projeto que foi liderado por Philippe Kruchten em Criado para conduzir o desenvolvimento de sistemas Orientado a Objetos.

13 Apresentação Define os princípios para o desenvolvimento de sistemas Feedback Transparência Comunicação. São consideradas práticas: Desenvolvimento em partes, Participação ativa dos usuários, Programação em pares, Ambiente único para equipe de desenvolvimento Etc.

14 Apresentação Para ordenar o desenvolvimento é proposto o ciclo de vida iterativo e incremental, onde cada parte do sistema é desenvolvida em uma iteração e implantada ao final do ciclo de vida. O ciclo gera benefícios como: Entrega antecipada de resultados; Antecipação de riscos; Facilidade para mudança de requisitos.

15 Etapas e Disciplina O ciclo de vida iterativo e incremental define 4 etapas para o desenvolvimento: Concepção (Iniciação) Elaboração Construção Transição. As etapas são executadas na totalidade para cada iteração.

16 Etapas e Disciplina

17 Concepção Estabelece o business case (prioridade de negócio) Envolve tanto a atividade de comunicação com o cliente como a de planejamento Delimita o escopo do sistema Determina arquitetura candidata (elementos novos, arriscados) Identifica riscos críticos Identifica potenciais usuários ou clientes do sistema

18 Elaboração Determina uma arquitetura estável Identificar e reduzir riscos de construção Especificar maioria dos Casos de Uso Fixar a arquitetura em proporções executáveis Preparar o plano de projeto (para a próxima fase) Estimar e justificar o orçamento Finalizar o business case

19 Construção Determina capacidades operacionais iniciais Estender o modelo de Casos de Uso para toda a aplicação Finalizar a análise, projeto, implementação e testes Checar integridade da arquitetura (com possíveis alterações) Monitorar riscos críticos

20 Transição Valida e autoriza a implantação do projeto. Transforma versão beta em um sistema em produção Preparar atividades de transição Avisar clientes sobre mudanças no ambiente (hardware, software, distribuição,..) Preparar documentação final Corrigir possíveis defeitos detectados no beta-teste

21 Os 4 P s do RUP Pessoas: Financiam, escolhem, desenvolvem, gerenciam, testam, usam e são beneficiadas por produtos Projeto: Sofre alterações. Determina as pessoas que irão trabalhar no projeto e os artefatos que serão usados. Produto: Código fonte, código de máquina, subsistemas, classes, diagramas: interação, de estados e outros artefatos. Processo: Define quem faz o que, quando e como.

22 Os 4 P s do RUP

23 Técnicas e Modelos Aplicados A cada etapa do ciclo de vida são aplicadas técnicas e modelos, como: Técnicas de Entrevista Questionário Cronograma Modelos da UML.

24 Definição de Iterações A Técnica de definição de iterações é a técnica aplicada nos diagrama de caso de uso para sugerir a ordem de desenvolvimento de software sob a análise de três critérios: Risco Precedência Criticalidade.

25 Metodologias Ágeis

26 Metodologias Ágeis O desenvolvimento ágil de software defende alguns pontos de vista em detrimentos de outros: Manifesto Ágil: Indivíduos e interações entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano.

27 Feedback Processos ágeis usam feedback, ao invés do planejamento como seu mecanismo de controle primário. O feedback é orientado por testes e releases periódicos do software envolvido.

28 Exemplos Scrum extreme Programming (XP) Lean Etc.

29 SCRUM Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Os projetos são divididos em ciclos (mensais, semanais, etc.) chamados de Sprints. O Sprint representa um Time Box (intervalo de tempo) dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que no caso do Scrum, são as Sprints.

30 SCRUM As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

31 SCRUM Alguns termos serão comumente vistos ao utilizar essa metodologia: Produt Backlog Sprint Planning Meeting Sprint Backlog Daily Scrum Release Burndown Sprint Review Sprint Retrospective

32 Product Backlog É uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, a lista cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

33 SCRUM Sprint Planning Meeting É uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo a equipe, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

34 SCRUM Sprint Backlog É uma lista de tarefas que a equipe se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

35 SCRUM Daily Scrum A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. É composta pelo Scrum Master e a equipe de desenvolvimento.

36 SCRUM Release Burndown Em um projeto Scrum, a equipe monitora seu progresso em relação ao projeto, atualizando um gráfico chamado Release Burndown ao final de cada Sprint (iteração). O eixo horizontal de um Release Burndown Chart mostra os Sprints; O eixo vertical mostra a quantidade de trabalho que ainda precisa ser feita no início de cada Sprint. O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe: Pontos de função, dias de trabalho e assim por diante.

37 SCRUM Release Burndown

38 SCRUM Sprint Review Meeting É feito ao final de cada Sprint. Durante esta reunião, a equipe mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades. Os participantes do Sprint Review tipicamente incluem o Product Owner, a equipe, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

39 SCRUM Sprint Retrospective Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. Pode servir também para iniciar o planejamento da nova Sprint. Conta com a participação do Scrum Master e com a equipe de desenvolvimento.

40 SCRUM

41 extreme Programming (XP) É uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

42 extreme Programming (XP) Princípios Comunicação Coragem Feedback Respeito Simplicidade

43 Comunicação Estreitar as barreiras existente entre o cliente e o analista é fundamental para o entendimento da tarefa. Priorizar o diálogo presencial, por exemplo, tem como objetivo garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível.

44 Comunicação

45 Coragem Única constância nos projetos de software é a mudança A confiança nas ferramentas e nas metodologias adotadas ajudam em tomadas de decisões corajosas, para o bem do projeto

46 Feedback Projetos de software requerem alto investimento por parte do cliente. É preciso que o cliente tenha conhecimento do status do seu investimento, a cada instante. Para isso, a comunicação e o respeito devem esta presente na relação Equipe x Cliente.

47 Respeito Membros de uma equipe só irão se preocupar em comunicarse melhor, por exemplo, se houver respeito uns com os outros.

48 Simplicidade Pesquisa sobre as funcionalidades desenvolvidas para um software Muito esforço é, geralmente, empregado na produção do software, sem que haja agregação de valor no produto final Fonte: Standish Group The Chaos Report (2000)

49 extreme Programming (XP)

50 extreme Programming (XP) Práticas Organizacionais: Jogo de Planejamento Pequenas Versões (Releases) Teste de Aceitação Time Coeso Equipe: Propriedade Coletiva Padronização de Código Ritmo Sustentável Integração Contínua Metáforas Pares: Programação em Par Refatoração Projeto Simples Desenvolvimento Orientado a Teste (TDD)

51 Jogo de Planejamento É a reunião feita no início da iteração, entre desenvolvedores e cliente, cuja finalidade é identificar as prioridades do projeto para que os desenvolvedores estimem o esforço das tarefas. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto.

52 Jogo de Planejamento Como o escopo é reavaliado a cada ciclo, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada ciclo, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.

53 Pequenas Versões (Releases) A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.

54 Teste de Aceitação São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema. Descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história está completa (aceita).

55 Time Coeso Deve ser formado pelo cliente, desenvolvedores e por profissionais que contribuam para o desenvolvimento do projeto, como consultores, por exemplo. A equipe de desenvolvimento é formada por pessoas engajadas e de perfis multidisciplinares, com o objetivo de termos um vasto conjunto de habilidades necessárias para o projeto. Um projeto bem sucedido precisa levar em conta a opinião de diversas partes, bem como incorporar diferentes pontos de vista.

56 Propriedade Coletiva O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificá-lo ou usá-lo. O objetivo é fazer a equipe conhecer todas as partes do sistema.

57 Padronização de Código A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. IDEs e Frameworks contribuem de forma significativa para implantar essa prática.

58 Ritmo Sustentável Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

59 Integração Contínua Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

60 Metáforas Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

61 Programação em Par (Pair Programming) É a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades.

62 Programação em Par (Pair Programming) Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

63 Refatoração É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refatorar (ou refabricar) melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte

64 Projeto Simples Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso.

65 Projeto Simples Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.

66 Desenvolvimento Orientado a Teste (TDD) Testing Driven Development Primeiro crie os testes unitários (Unit Tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

67 Variação entre os modelos Como o processo de desenvolvimento de software se distribui/concentra no tempo dentro de um projeto?

68 Conclusão Cada modelo tem suas vantagens e desvantagens Cabe aos gerentes e analistas escolherem a melhor abordagem para o projeto a ser desenvolvido

69 Padrões de Projeto

70 Introdução Projetar software orientado a objetos é difícil Projetar software orientado a objetos e reutilizável é muito difícil O projeto deve ser específico ao problema, porém genérico o suficiente para acomodar futuras mudanças É difícil obter um projeto flexível e reutilizável na primeira tentativa Projetistas novatos levam um tempo para entender o que é um bom projeto orientado a objetos

71 Introdução O que os projetistas experientes fazem: Reutilizam soluções que funcionaram no passado Muitos sistemas orientados a objetos compartilham padrões de funcionamento das classes e da comunicação entre objetos Estes padrões tornam o projeto mais flexível, elegante e reutilizável O projetista aplica o padrão de projeto sem ter que o re-descobrir Novelistas e dramaturgos aplicam padrões constantemente O mesmo vale para software

72 Introdução Exemplos: "Represente o estado como um objeto" "Decore os objetos de modo que funcionalidades possam ser facilmente adicionadas ou removidas" Se você conhece o padrão, uma série de decisões de projeto surgem automaticamente Um padrão de projeto registra uma determinada experiência bem sucedida em projeto de software Cada padrão sistematicamente nomeia, explica e avalia um projeto importante e recorrente

73 Introdução Os padrões de projeto facilitam a definição de um projeto "correto" em um tempo reduzido A idéia de padrões foi apresentada por Christopher Alexander em 1977 no contexto de Arquitetura (de prédios e cidades): Cada padrão descreve um problema que ocorre frequentemente em nosso ambiente e descreve o núcleo da solução para o problema, de uma forma que ela possa ser utilizada inúmeras vezes (Christopher Alexander, 1977)

74 Introdução Um padrão possui quatro elementos essenciais: 1. Nome: Identificador utilizado para descrever, com uma ou duas palavras, o problema, sua solução e consequências 2. Problema: Descreve quando aplicar o padrão e o contexto do problema 3. Solução: Descreve os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações. Não descreve uma implementação ou projeto concreto em particular 4. Consequências: Resultados das vantagens e desvantagens ( trade-offs) da aplicação do padrão.

75 Introdução Os padrões apresentados são descrições de classes e objetos inter-relacionados que solucionam um problema de projeto em um contexto particular Outros padrões estão disponíveis para solucionar problemas de concorrência, computação distribuída, tempo-real e aspectos específicos de domínio

76 Padrões de Desenvolvimento Padrões GoF Padrões de Criação ou de Construção: Abstract Factory, Builder, Factory Method, Prototype e Singleton. Padrões Estruturais: Adapter, Bridge, Composite, Decorator, Facade, Flyweight e Proxy. Padrões Comportamentais: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor. Padrões Grasp Especialista na informação, Criador, coesão alta, acoplamento fraco, Controlador e Polimorfismo Invenção Pura e Indireção, Variações Protegidas.

77 Métricas de Desenvolvimento

78 Métricas de Desenvolvimento Qualidade de Software Conceitos Contextualizar a importância da busca pela qualidade Revisões Métricas Conceitos de métricas técnicas de software Tipos de Métricas Complexidade Ciclomática Determinação da complexidade ciclomática Caminhos Independentes

79 Qualidade de Software Conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) (1968) Crise de Software Problemas detectados: Cronogramas não observados. Projetos abandonados. Módulos que não operam corretamente quando combinados. Programas que não fazem exatamente o que era esperado. Sistemas tão difíceis de usar que são descartados. Sistemas que simplesmente param de funcionar. Passados quase 40 anos, o que mudou?

80 Qualidade de Software Qualidade em geral: É um conceito relativo. Está fortemente relacionada à conformidade com requisitos. Diz respeito à satisfação do cliente. Como isso se manifesta em software?

81 Qualidade de Software O aspecto não repetitivo do desenvolvimento de software torna essa atividade difícil e em boa medida imprevisível. Delimitar o escopo de um sistema não é trivial. A volatilidade dos requisitos é lugar comum no desenvolvimento de software.

82 Qualidade de Software Fatores que afetam o desenvolvimento e que influenciam no julgamento dos usuários: Tamanho e complexidade do software; Número de pessoas envolvidas no projeto; Métodos, técnicas e ferramentas utilizadas; Custo x benefício do sistema; Custos associados à existência de erros; Custos associados à detecção e remoção de erros; Etc.

83 Qualidade de Software Conjunto de características a serem satisfeitas em um determinado grau, de modo que o software satisfaça às necessidades de seus usuários

84 Qualidade de Software

85 Qualidade do Produto x Qualidade do Processo de Software Qualidade do produto de software não se atinge de forma espontânea. A qualidade do produto depende fortemente da qualidade do processo de desenvolvimento.

86 Qualidade do Processo de Software Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos.

87 Qualidade do Processo de Software Motivação para a busca da Qualidade do Processo de Software: Aumento da qualidade do produto. Diminuição do retrabalho. Maior produtividade. Redução do tempo para atender o mercado (time to market). Maior competitividade. Maior precisão nas estimativas.

88 Qualidade do Processo de Software A implantação de um Programa de Qualidade começa pela definição e implantação de um processo de software. O processo de software deve estar documentado, ser compreendido e seguido.

89 Aspectos de Qualidade de Software Normas NBR ISO/IEC12207 Software e Norma ISO 9000 SPICE CMM CMMI MPS-BR Áreas-chave do processo (KPA s)