Jonas de Souza H2W SYSTEMS

Transcrição

1 Jonas de Souza H2W SYSTEMS 1

2 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição de software Professor Centro Paula Souza CEO H2W SYSTEMS 2

3 Desenvolvimento de sistemas sob medida Foco em industrias Automação Industrial a partir de anos 3

4 4

5 5

6 Mercado Usuário 70% Industria, Finanças e Serviços e Telecom 6

7 Predominância em serviços contratados ao invés de software replicáveis Grande parcela da receita baseada em projetos Dificulta exportações Maior necessidade de mão de obra Déficit de profissionais: mil técnicos mil técnicos 7

8 EUA U$ 250 bilhões anuais para desenvolver 175 mil projetos de software Na média, um projeto em uma grande empresa é de U$ 2,3 milhão A grande maioria dos projetos FALHA 24% - fracassam 44% - sucesso parcial 32% - sucesso total 8

9 9

10 Na média, os projetos de desenvolvimento de software: Custam 45% mais do que o previsto Gastam 63% mais tempo do que o previsto Entregam somente 67% das funcionalidades previstas 10

11 Estratégia Projetos Resultados 11

12 Empreendimento temporário Com início e fim bem definidos Se destina a atingir um objetivo claro e definido Dentro de parâmetros de tempo, custo, recursos e qualidade 12

13 Um projeto bem-sucedido é aquele realizado conforme o planejado 13

14 14

15 Surgiu em em reunião da OTAN O termo veio do nome da conferência Motivação: Dificuldade da indústria em produzir software grande e complexo Participantes: Manufatura de computadores, usuários, software houses, academia 15

16 Conjunto de metodologias, métodos e ferramentas que auxiliam na produção de software de alta qualidade dentro dos prazos e custos esperados. [B.Brügge 97, Notas de curso TUM] 16

17 Sw não se desgasta com o uso, degrada com modificações 17

18 Modelo genérico: 18

19 Modelo genérico: O quê deve ser feito: que dados serão usados? que funções serão realizadas? quais as restrições? quais os custos? quais os riscos? quais os prazos? 19

20 Modelo genérico: Como deve ser feito: como estruturar o sw? como implementar os dados? como implementar as funções? como implementar as restrições? como verificar se o sw está sendo desenvolvido corretamente? como validar o produto desenvolvido? 20

21 Modelo genérico: Alterações: corrigir bugs ; adaptar a novos ambientes; acrescentar novos requisitos; melhorar a manutenção; determinar se modificações não fizeram o sw regredir; 21

22 Análise Design Implementação Teste Implantação Manutenção 22

23 23

24 24

25 25

26 Manifesto Ágil de Software 2001 Objetivo de descobrir maneiras melhores de desenvolver software Evolucionários Prometem: Velocidade flexibilidade de resposta às mudanças Comunicação aberta 26

27 Em 2011 PMI reconhece importância das práticas ágeis para GP em vários setores e organizações Entregam projetos mais rapidamente, com menos desperdício causados por exigências mal compreendidas PMI cria a certificação Agile PMP 27

28 O que está errado no gráfico de Gantt? Regras de negócio mudam, equipes de desenvolvimento variam, tecnologia modificam, etc. A única certeza é que terá mudanças!!! 28

29 29

30 30

31 Surgiu em 1999 com o livro Extreme Programming Explained de Kent Beck Indicada para projetos com escopo variável. Cliente aprende com suas necessidades e consegue obter um produto de maior valor 31

32 Feedback Comunicação Simplicidade Coragem 32

33 33

34 34

35 35

36 Jogo de planejamento Projeto é dividido em iterações e releases Cliente faz solicitações a partir de fichas (estórias) Fichas são estimadas pela equipe Estimativas são passadas para o cliente Cliente aprova fichas e prioriza Equipe acumula uma quantidade de fichas para serem desenvolvidas e incrementadas ao sistema Cerca de 2 semanas de trabalho Cliente testa processo reinicia 36

37 Cliente Presente Presente em todo o processo de desenvolvimento do sistema Evita especulação Proporciona rápido feedback ao pedido do cliente Porém: usuários-chave são muito valiosos, dificilmente estão disponíveis por muito tempo 37

38 Realizadas em grupo, por comparação Fichas não devem ser nem muito pequenas, nem muito grandes 38

39 Realizada por toda a equipe Na primeira hora do dia 15 minutos Avaliar dia anterior Planejar o que será feito neste dia Questões detalhadas devem ser resolvidas depois 39

40 Uma das práticas mais importantes e polêmicas do XP 2 desenvolvedores no mesmo computador Benefícios: Código constantemente revisado Maior parte do tempo é pensando Um pensa em como implementar o método, o outro pensa estrategicamente Desenvolvedores novos aprendem muito mais rapidamente Atenção é mantida Compensa? Produtividade a curto prazo é igual A longo prazo, código da dupla é muito melhor 40

41 Primeiro são feitos os testes, depois o código Quando o código passar em todos os testes, estará pronto Proporciona sistemas de alta qualidade Mantém código simples Rápido feedback ao desenvolvedor 41

42 XP recomenda pelo menos 2 tipos: Unidade Automatizados, testa classes do sistema Rodados antes e depois de qualquer alteração Aceitação Teste final da funcionalidade Criado e testado pelo cliente 42

43 Código não pode ser segmentado em partes Todos os desenvolvedores devem trabalhar em todo o código Evita ilhas de conhecimento 43

44 Padrões de codificação para itens como: Nomenclatura Indentação Lógica Comentários Documentação Torna sistema simples Colabora na manutenção do sistema 44

45 Só deve ser desenvolvido o que realmente será utilizado Não deve ser feito nada, imaginando que o cliente pode querer isto no futuro Não devem ser criadas generalizações Código deve apenas atender necessidades do cliente e nada a mais 45

46 Em projetos de software, é comum fazer com que toda a equipe trabalhe até mais tarde para tirar atrasos Muitas empresas entendem isto como comprometimento XP é totalmente contra Causa grande perda de produtividade Desmotiva a equipe Equipe deve trabalhar apenas 8 horas por dia O trabalho é mental, não braçal 46

47 47

48 Relacionamento entre equipe e cliente Reporta andamento do projeto, problemas e riscos Tem visão do todo Cuida dos aspectos administrativos e burocráticos 48

49 Responsável técnico pelo sistema Responsável por manter valores e práticas XP Profundo conhecimento no processo de desenvolvimento Normalmente é um dos desenvolvedores 49

50 Realiza os testes do sistema Importante que não esteja envolvido na codificação Mantém documentações atualizadas Retira parte do peso das documentações dos desenvolvedores 50

51 Analisa Projeta Codifica 51

52 52

53 XP não recomenda uma grande quantidade de documentos antes do desenvolvimento Documentos são investimentos para o futuro Alguns projetos sofrem com ausência de documentos, outros com excesso 53

54 Estórias Testes de aceitação Testes de unidade Javadoc Modelo de Classes Modelo de Dados Processos de Negócio Manual do usuário Acompanhamento diário Acompanhamento do projeto Fotos 54

55 55

56 Desenvolvimento de sw: diferente de outros produtos da Engenharia muitos dos modelos de desenvolvimento existentes não se aplicam; por exemplo, não existe uma etapa de fabricação o comportamento do sw não é completamente conhecido Modelos de desenvolvimento de sw: permite identificar áreas problemáticas permite sintetizar as diferentes alternativas para a solução de dificuldades dá suporte ao gerenciamento existem várias visões: cascata, em fases,... nenhum modelo é perfeito 56

57 Escolha do modelo depende: da natureza do Projeto da equipe de desenvolvimento e do estilo de gerenciamento do grau de sofisticação do cliente/usuário do ambiente de desenvolvimento Atividades essenciais de um bom processo: descrição do problema (o quê deve ser feito?) descrição da solução (como deve ser feito?) verificação (a solução adotada responde ao problema descrito?) validação (o problema correto foi resolvido?) 57

58 58

59 59