O documento discute metodologias integradas de desenvolvimento de software, abordando: 1) As fases do RUP - Concepção, Elaboração, Construção e Transição; 2) O framework Scrum, com ênfase nas cerimônias como Sprints e Daily Meetings; 3) A importância de seguir as melhores práticas do CMMI para melhoria contínua.

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.

3. 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

4. Tópicos abordados
* Problemas comuns em projetos de desenvolvimento de
software.
* O que é uma metodologia?
* Metodologias para desenvolvimento de software.

5. Problemas comuns em projetos de
desenvolvimento de software.

6. Falhas de Comunicação

7. 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.

8. Para resolver esses problemas, seguimos uma
metodologia.

9. O que é uma Metodologia?
Padrões
Comunicação
Objetivo comum
Aproveitamento recursos
Metodologia
Equipe

10. Metodologias para Desenvolvimento
de Software
• Metodologia tradicional: PDI-SW (Processo de
Desenvolvimento Iterativo de Software)
• Metodologia ágil: SCRUM

11. 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.

13. 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.

14. 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.

15. 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

16. 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.

17. Pilares do RUP

18. Gráfico de esforço nas fases

19. 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.

20. 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.

21. 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.

22. 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?

23. 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?

24. 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?

25. 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

26. Perfil do time técnico
• Gerente de Projetos
• Arquiteto de Software
• Analista de requisitos
• Analista de sistema
• Desenvolvedores
• Analista de Testes
• Documentador

27. Fluxo de trabalho

28. Descrição para as fases

29. 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

31. 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...

32. 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