1- Apresentacao Metodologia RCP

121 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
121
No SlideShare
0
A partir de incorporações
0
Número de incorporações
17
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

1- Apresentacao Metodologia RCP

  1. 1. Metodologias de Desenvolvimento de Software Integradas Frank Coelho Especialista em desenvolvimento de software. Solução organizacional para otimização de processos de desenvolvimento de software, visando o desenvolvimento com qualidade com foco na entrega.
  2. 2. Tecnologias • Linux • Apache • MySQL • PHP • C# • VB.NET • SharePoint • Project Server • Exchange Server • Windows Server • JBossApp Server • Oracle Weblogic • Hibernate • Spring Framework • Struts Framework • Oracle • PostgreSQL • IBM DB2 • MySQL Java DatabaseMicrosoft . NET LAMP
  3. 3. Tópicos abordados * Problemas comuns em projetos de desenvolvimento de software. * O que é uma metodologia? * Metodologias para desenvolvimento de software.
  4. 4. Problemas comuns em projetos de desenvolvimento de software.
  5. 5. Falhas de Comunicação
  6. 6. Estatísticas Motivos • Consomem mais recursos que o orçado; • Consomem mais tempo que o estimado; • Não entregam o que foi combinado; (+) 500 mil projetos (pequeno - grande porte) de software nos Brasil.
  7. 7. Para resolver esses problemas, seguimos uma metodologia.
  8. 8. O que é uma Metodologia? Padrões Comunicação Objetivo comum Aproveitamento recursos Metodologia Equipe
  9. 9. Metodologias para Desenvolvimento de Software • Metodologia tradicional: PDI-SW (Processo de Desenvolvimento Iterativo de Software) • Metodologia ágil: SCRUM
  10. 10. SCRUM • Metodologia de desenvolvimento ágil nascida em empresas de fabricação de carros em 1986 (Takeuchi e Nonaka). • Jeff Sutherland, John Scumniotales, e Jeff McKenna – documentaram e implementaram - Easel Corporation em 1993. • Tipo de formação do Rugby. • Passou a ser utilizado no mundo a partir de 1995. • Aborda uma filosofia de gerenciamento com foco no resultado.
  11. 11. Sprint •Cada sprint é uma iteração que segue um ciclo e entrega incremento de software pronto. •Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI “retorno sobre investimento” e por conhecer as necessidades do cliente); •Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints; •Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião). •Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos; •Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.
  12. 12. BACKLOG Planejamento de sprint (Sprint Planning): Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint. Product Backlog Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste. Sprint Backlog O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeja concluir na sprint corrente, e ele pertence unicamente ao Development Team. Burndown Chart O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.
  13. 13. Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum - são os que produzem o produto (objetivo do projeto). Product Owner (dono do produto) O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster. Equipe (Development Team) A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe. Scrum Master Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva. Papéis principais
  14. 14. Obrigado! Proposta. • Usar os pilares fundamentais do RUP e seus conceitos e métodos, unificado com as melhores praticas do CMMI. Definição de processo organizacional sobre a gestão do SCRUM. • Utilizar aspectos básicos definindo um mínimo de documentação inicial tanto quanto necessário. • Foco na entrega com garantia de qualidade. • Reuso de artefatos e funcionalidades (Frameworks) • Formar muito mais que um time, um grupo de pessoas com os mesmos objetivos e que acreditem no negocio.
  15. 15. Pilares do RUP
  16. 16. Gráfico de esforço nas fases
  17. 17. Concepção Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento. Elaboração Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa. Fase de Construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.
  18. 18. Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.
  19. 19. Fase de Concepção • Finalidade – Definir objetivos e viabilidade do projeto (o ideia do projeto) e o escopo de vários aspectos • Atividades – Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das principais etapas – Delimitar o escopo do projeto – Identificar os atores que interagem com o sistema – Identificar as interações dos atores com o sistema (casos de uso) • Resultados (artefatos) – Documento de visão: visão geral dos requisitos, características e restrições essenciais do projeto. – Modelo inicial de casos de uso (10%-20%). – Glossário do projeto (opcionalmente um modelo de domínio). – Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso e prognóstico financeiro. – Avaliação inicial de riscos. – Plano de projeto, com fases e interações. – Modelo de negócios, se necessário. – Um ou vários protótipos. • Critérios de Satisfação – Concordância quanto à definição de escopo e estimativas de custo e cronograma. – Compreensão dos requisitos funcionais. – Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento. – Profundidade e amplitude dos protótipos desenvolvidos. – Custos planejados versus realizados.
  20. 20. Fase de Elaboração • Finalidade – eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente e consistente da solução • Atividades – Construir protótipos executáveis, em uma ou mais interações – Atacar os casos de uso críticos, que expõe os maiores riscos técnicos – Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios, demonstrar para investidores, clientes e usuários • Resultados (artefatos) – Modelo de casos de uso (80% ou mais). – Requisitos não funcionais – Descrição da arquitetura do software – Protótipos arquiteturais executáveis – Revisão da visão de negócios e lista de riscos – Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação – Plano de processo de desenvolvimento – Manual de usuário preliminar • Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto) – A visão do produto é estável? – A arquitetura é estável? – A demonstração executável mostrou que os elementos de maior risco foram abordados satisfatoriamente? – O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e coerente? – Todos os interessados concordam quando à coerência entre visão, plano e arquitetura? – Os custos planejados e executados estão aceitáveis?
  21. 21. Fase de Construção • Finalidade – Desenvolver todos os componentes e características não resolvidas nas fases anteriores, testando-as e integrando-as na forma de um produto. • Atividades – Diversas • Resultados (artefatos) – O produto, descrito e integrado nas plataformas adequadas • Critérios de Satisfação – A release do produto é suficientemente estável e amadurecida para ser entregue ao usuário? – Todos os envolvidos e interessados estão preparados para a fase de transição? – O consumo de recursos é ainda aceitável?
  22. 22. Fase de Transição • Finalidade – Realizar a transição do produto para a comunidade de usuários • Atividades – “beta teste” – Operações paralelas com sistema legado – Conversão de bases de dados – Treinamento de usuários a mantenedores – Roll-out para setores de marketing, distribuição e vendas • Resultados (artefatos) – Em conformidade com atividades • Critérios de Satisfação – O usuário ainda está satisfeito? – Os custos de manutenção ainda são aceitáveis?
  23. 23. Ferramentas de gerenciamento do ciclo de vida e produção • Visual Studio • Arquitetura • Dados • Testes • TFS • Versionamento • Tarefas • Sprints • Backlogs • Project • Cronograma • Tarefas • Custos • Studio manager SQL • Modelo de dados
  24. 24. Perfil do time técnico • Gerente de Projetos • Arquiteto de Software • Analista de requisitos • Analista de sistema • Desenvolvedores • Analista de Testes • Documentador
  25. 25. Fluxo de trabalho
  26. 26. Descrição para as fases
  27. 27. CMMI • CMMI é uma família de conjuntos de melhores práticas para apoiar a melhoria de desenvolvimento, serviços e aquisição. • Implementar um modelo baseado nas melhores praticas, levando em conta o cenário especifico e atual da empresa, voltado para melhoria continua e crescimento do grau de maturidade do ciclo de vida da construção de software. • Processo continuo visando o alcance dos resultados esperados. • Trabalhar nos detalhes no intuito de evitar esforço desnecessário. • União das dimensões de construção do CMMI: • Pessoas • Ferramentas • Procedimentos
  28. 28. O que esperar. • Não existe retorno a curto prazo. • Certificação CMMI • Certificação ISO • Controle absoluto de projetos e custos • Baixo Custo de manutenção • Produtos robustos e escaláveis • Melhoria estratégica de posição no mercado • Gerencia de configuração consolidada • Lucros maiores • Ser um caso de sucesso • Atingir a EXCELENCIA Fazer a coisa certa é uma escolha que deve ser mantida, que exige esforço e comprometimento e o retorno só é visto depois. Obstáculos são apenas grandes oportunidades de sermos melhores... Homens comuns contam histórias, homens extraordinários fazem a história...
  29. 29. Referências • http://www.infoq.com/presentations/The-Roots-of-Scrum • http://pt.wikipedia.org/wiki/Scrum • http://www.agilealliance.org/system/article/file/888/file.pdf • http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fase _de_Concep.C3.A7.C3.A3o • http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI- DEV

×