UNIVERSIDADE SALGADO DE OLIVEIRA
CAMPUS GOIÂNIA
SISTEMAS DE INFORMAÇÃO
DESENVOLVIMENTO DE PROJETO PARA
IMPLANTAÇÃO DO CMMI...
UNIVERSIDADE SALGADO DE OLIVEIRA
CAMPUS GOIÂNIA
SISTEMAS DE INFORMAÇÃO
DESENVOLVIMENTO DE PROJETO PARA
IMPLANTAÇÃO DO CMMI...
A Deus por todas as bênçãos, e pela sua
graça e misericórdia sem fim. À minha
mãe pelo apoio, paciência e pelo seu
grande ...
Agradecimentos
Diogo Rocha:
 Aos meus pais, pela confiança, amor e apoio;
 A todos meus amigos e professores que fizeram...
Resumo
O presente trabalho tem por objetivo analisar as pequenas e médias empresas
desenvolvedoras de software que hoje em...
LISTA DE ABREVIATURAS E SIGLAS
CASE – Computer – Aided Software Engineering
CCB - Comitê de Controle de Configuração
CM - ...
PP - Project Planning
PPQA - Process and Product Quality Assurance
REQM - Requirements Management
RUP - Rational Unified P...
Sumário
1. INTRODUÇÃO........................................................................................................
2.3.6 METAS ESPECÍFICAS................................................................................................36
...
REFERÊNCIAS..................................................................................................................
Lista de Figuras
Capítulo 2
Figura 1: Ciclo do Scrum [8] ....................................................................
Lista de Tabelas
Capítulo 2
Tabela 1: Comparação Entre Níveis de Capacidade e Maturidade [12] ............ 28
Tabela 2 Nív...
12
1. Introdução
Com o grande avanço da tecnologia o mundo se torna cada vez mais
informatizado e interligado. Diante diss...
13
estouro em prazos, entrega de produtos incompletos, entre outros fatores prejudiciais
para a empresa. No entanto, com o...
14
Existem também diversos modelos de processo, no qual fornece técnicas a serem
seguidas pelos membros de desenvolvimento...
15
Com o desenvolvimento deste projeto haverá um ganho significativo para a
empresa Realize-se, pois, com um processo gere...
16
requisitos para entrega do orçamento, melhor comunicação em planejamento de
projetos, realizar com grande precisão medi...
17
do nível gerenciado, desenvolvendo um projeto para implantação do CMMI nível de
maturidade 2 e Scrum na empresa Realize...
18
A primeira parte mostrará os processos de desenvolvimento de software. Nele
será abordado os processos ágeis, que estão...
19
2. Referencial Teórico
2.1 Processos de desenvolvimento de software
Esse tópico abordará conceitos sobre processos de d...
20
Os processos como já foram ditos fornecem um “padrão de atividades” para o
desenvolvimento de um sistema, porém, tais p...
21
O Scrum é uma das metodologias mais dinâmicas em gerência de projetos é um
processo iterativo e incremental para o dese...
22
Figura 1 – Ciclo do Scrum [8].
 Product Backlog: É uma lista contendo todas as funcionalidades desejadas para
um produ...
23
Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente
ficam em pé para não prolongar a reunião);
 R...
24
2.2.1.1 CMMI
Um modelo de referência utilizado para garantir a qualidade no desenvolvimento
de softwares é o CMMI. O mo...
25
Aquisição e Suporte, dando uma visão estruturada da melhoria da visão de processos de
uma organização.
Através de pesqu...
26
Figura 2 - História dos CMM's [12].
Desde 1991 foram desenvolvidos CMM's para várias disciplinas, dentre elas as
mais c...
27
de processo na organização. O objetivo era desenvolver um framework em que as
organizações poderiam se apoiar para busc...
28
Figura 3 - Estrutura da Representação: Contínua e por Estágios [12].
Mas também há semelhanças entre elas, ambas têm os...
29
Níveis de maturidade, associados à representação por estágios, aplicam-se à
melhoria de processo da organização em um c...
30
incompleto. Portanto, o ponto de partida da representação por estágios é chamado de
“inicial”.
2.3.2 Níveis de Maturida...
31
5. Em Otimização.
Nível de Maturidade 1 - Inicial:
No nível de maturidade 1, geralmente os processos são ad hoc (expres...
32
Nível de Maturidade 3 – Definido:
No nível de maturidade 3, os processos são caracterizados e definidos, são
descritos ...
33
No nível de maturidade 5, uma organização melhora continuamente seus
processos com base no entendimento quantitativo da...
34
Figura 4 - Estruturas da área de processo [13].
2.3.3.1 Componentes Requeridos
Os componentes requeridos descrevem o qu...
35
e as práticas genéricas. Para que as metas sejam consideradas satisfeitas, as práticas
devem estar presentes nos proces...
36
é: “fornecer subsídios para estabelecer e manter um conjunto utilizável de ativos de
processo da organização e de padrõ...
37
Por exemplo, uma subprática para a prática específica “Implementações
corretivas para tratar as questões críticas ident...
38
(CMUSEI) "descrevem uma atividade considerada importante para a satisfação da meta
genérica associada" [3].
Por exemplo...
39
Todas as áreas de processos possuem seus objetivos específicos (SG – specific
goal), e cada um desses são subdivididos ...
40
GP 2.5 – Treinar Pessoas:
5) Treinar pessoas para executar ou apoiar o processo de
desenvolvimento de requisitos confor...
41
2.4.1 Gestão de Requisitos (REQM)
O objetivo desta área de processo é gerenciar os requisitos técnicos e não
técnicos a...
42
[10]. Alguns exemplos na prática em que não se aplica PP em CMMI nas organizações
são:
 O planejamento do projeto não ...
43
SP 3.1 – Revisar Planos que Afetam o Projeto;
SP 3.2 – Conciliar Carga de Trabalho e Recursos;
SP 3.3 – Obter Compromet...
44
2.4.4 Gestão de Contrato com Fornecedores (SAM)
O objetivo desta área de processo é gerenciar a aquisição de produtos d...
45
2.4.5 Medição e Análise (MA)
"O objetivo desta área de processo é desenvolver e manter uma capacitação de
medição para ...
46
As metas e práticas específicas da área Garantia de Qualidade de Processo e
Produto são [3]:
SG 1 – Avaliar Objetivamen...
47
SG 3 – Estabelecer Integridade:
SP 3.1 – Estabelecer Registros de Gestão de Configuração;
SP 3.2 – Executar Auditorias ...
48
3. PROJETO PARA IMPLANTAÇÃO DO CMMI DE
NIVEL DE MATURIDADE DOIS E SCRUM NA
EMPRESA REALIZE-SE
Após compreender a estrut...
49
entre os noivos, os convidados e fornecedores de produto ou serviços para este
nicho, atuando em todo processo que envo...
50
 Falta de competência para gerenciar projetos;
 Falta de definição de responsabilidades;
 Falta de uma ferramenta de...
51
Os requisitos são levantados entre a equipe. Não existe uma gerência de
requisitos gerando: retrabalho, desperdício de ...
52
 Nessas reuniões devem ser discutidas mudanças de requisitos ou
inconsistências. O Scrum Master deve intermediar a reu...
53
riscos e suas tarefas de mitigação (eliminar riscos), tarefas relacionadas a entregáveis e a
atividades de apoio, taref...
54
O orçamento e o cronograma do projeto são obtidos a partir do Product Backlog.
Ele é dividido em Sprints alocando a equ...
55
É importante que a equipe da empresa Realize-se tenhas habilidades e
conhecimentos necessários para executar sua parte ...
56
averiguar se estará pronto no tempo estipulado. O grande problema é a comunicação
falha, e a falta de monitoramento for...
57
O Scrum não trata da aquisição de produtos. Entretanto o CMMI orienta as
organizações a determinar que tipos de aquisiç...
58
permitir aos envolvidos conhecer o processo e melhorá-lo de forma contínua. Como um
dos princípios do Scrum são transpa...
59
Assim, é possível aplicar o GQM no planejamento de processo e medição, isto
ocorre definindo:
 O objetivo da medição (...
60
buscar atributos que evidenciem, em uma auditoria, sinais de integridade e qualidade
perceptíveis por um auditor leigo ...
61
Tabela 3 - Relação entre Criticidade e Complexidade.
Os prazos são válidos para itens de auditoria de Pregame, Pre-Spri...
62
Subversion, CVS, Trac, Scon, Bitten e várias outras. Existem dois tipos de baselines,
são elas:
 Baseline interna: ite...
63
Considerações finais
O presente trabalho faz uma abordagem sobre o cenário atual das pequenas e
médias empresas de tecn...
64
De acordo com o CMMI Institute, “a IBM da Austrália na área de Serviços de
gerenciamento de aplicativos fechou 95% dos ...
65
Referências
[1] OLIVEIRA, F. B. Tecnologia da informação e da comunicação: desafios e
propostas estratégicas para o des...
66
[13] ALMEIDA, Alessandro, Conhecendo o CMMI. In: WORKSHOP QUALITY
PROCCESS, Workshop.ConhecendoCMMI-2oEdicao-DIS. 2005,...
Upcoming SlideShare
Loading in...5
×

DESENVOLVIMENTO DE PROJETO PARA IMPLANTAÇÃO DO CMMI NIVEL DOIS DE MATURIDADE E SCRUM NA EMPRESA REALIZE-SE

572

Published on

Pesquisar e analisar as características do CMMI um acrônimo de Capability Model Integration (Modelo de Maturidade e Capacidade Integrado) e SCRUM uma gestão baseada em metodologia ágil.
Caracterizar o modelo integrado de maturidade de capacitação, comentando sobre sua estrutura, sua evolução e sua história. E por fim focar nas áreas de processos
17
do nível gerenciado, desenvolvendo um projeto para implantação do CMMI nível de maturidade 2 e Scrum na empresa Realize-se.

Published in: Software
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
572
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

DESENVOLVIMENTO DE PROJETO PARA IMPLANTAÇÃO DO CMMI NIVEL DOIS DE MATURIDADE E SCRUM NA EMPRESA REALIZE-SE

  1. 1. UNIVERSIDADE SALGADO DE OLIVEIRA CAMPUS GOIÂNIA SISTEMAS DE INFORMAÇÃO DESENVOLVIMENTO DE PROJETO PARA IMPLANTAÇÃO DO CMMI NIVEL DOIS DE MATURIDADE E SCRUM NA EMPRESA REALIZE-SE por BRUNA MARTINS DE ALMEIDA DIOGO ROCHA FERREIRA DE MENEZES PAULO ROBERTO VASCONCELOS Goiânia, Junho de 2014
  2. 2. UNIVERSIDADE SALGADO DE OLIVEIRA CAMPUS GOIÂNIA SISTEMAS DE INFORMAÇÃO DESENVOLVIMENTO DE PROJETO PARA IMPLANTAÇÃO DO CMMI NIVEL DOIS DE MATURIDADE E SCRUM NA EMPRESA REALIZE-SE por BRUNA MARTINS DE ALMEIDA DIOGO ROCHA FERREIRA DE MENEZES PAULO ROBERTO VASCONCELOS Relatório final submetido a avaliação, como requisito parcial para obtenção da aprovação na disciplina Estágio Supervisionado Orientador: Prof.ª Ana Carolina Prado, MSc Goiânia, Junho de 2014
  3. 3. A Deus por todas as bênçãos, e pela sua graça e misericórdia sem fim. À minha mãe pelo apoio, paciência e pelo seu grande amor. Ao meu pai por sempre acreditar no meu potencial. Á minha irmã pelo companheirismo e preocupação. Bruna Martins de Almeida. A Deus primeiramente, por me fortalecer e capacitar a mais este desafio lançado em minha vida e pela certeza de que minha missão mal começou. Diogo Rocha Ferreira de Menezes. Agradeço minha mãe e meu pai pelo apoio e pelo amor, aos professores pela ajuda e por nós guiar nesse trabalho. Aos meus amigos muito obrigados pelo companheirismo e ajuda. Paulo Roberto Vasconcelos Filho.
  4. 4. Agradecimentos Diogo Rocha:  Aos meus pais, pela confiança, amor e apoio;  A todos meus amigos e professores que fizeram parte da minha formação, o meu muito obrigado. Paulo Roberto Vasconcelos Filho:  Aos Meus pais, pela vida e ensinamentos;  Aos meus amigos e professores por me ajudarem a superar obstáculos, obrigado por tudo.
  5. 5. Resumo O presente trabalho tem por objetivo analisar as pequenas e médias empresas desenvolvedoras de software que hoje em dia preocupam cada vez mais em desenvolver um diferencial competitivo para o mercado, o que muitas vezes não acontece por conta de problemas financeiros. Nesse trabalho é tratado o contexto das pessoas que desenvolvem um sistema de software, a tecnologia que é empregada por eles, e a organização do processo de desenvolvimento. Para o desenvolvimento da pesquisa utilizou-se da aplicação do CMMI nível de maturidade dois e o Scrum. Foi percebida uma grande vantagem a ser alcançada decorrente da implantação da pesquisa, o qual foi confirmado redução de gastos e maior satisfação do usuário final, entre outros benefícios. Dessa forma, essa pesquisa pôde comprovar a importância dos processos e qualidade em desenvolvimento de software, no qual irá ser apresentado um projeto para implantação do CMMI de maturidade dois e Scrum na empresa Realize. Palavras chaves: 1. CMMI. 2. Scrum. 3. processos e qualidade em desenvolvimento de software.
  6. 6. LISTA DE ABREVIATURAS E SIGLAS CASE – Computer – Aided Software Engineering CCB - Comitê de Controle de Configuração CM - Configuration Management CMM - Capability Maturity Model CMMI - Capability Maturity Model Integration CMMI – ACQ- CMMI for Acquisition CMMI – DEV - CMMI for Development CMMI – SVC - CMMI for Services CMU - Carnegie Mellon University DOD - Departament of Defense EIA - Electronics Industry Alliance EUA - Estados Unidos da América GG - Generic Goal GP - Generic Practices GQM - Goal Question Metric IBM - International Business Machines INCOSE - International Council on Systems Engineering IPD - CMM - Integrated Product Development Capability Maturity Model MA - Measurement and Analysis MPS.BR - Melhoria de Processo do Software Brasileiro OPD - Organizational Process Definition PMC - Project Monitoring and Control PO Team – Product Owner Team
  7. 7. PP - Project Planning PPQA - Process and Product Quality Assurance REQM - Requirements Management RUP - Rational Unified Process SAM - Supplier Agreement Management SECAM - Systems Engineering Capability Assessment Model SECM - Systems Engineering Capability Model SEI - Systems Engineerig Institute SG - Specific Goal SP - Specific Practice SW - CMM - Capability Maturity Model for Software TI - Tecnologia da Informação TCC - Trabalho de Conclusão de Curso WBS - Work Breakdown Structur
  8. 8. Sumário 1. INTRODUÇÃO........................................................................................................12 1.1 MOTIVAÇÃO................................................................................................................15 1.2 OBJETIVOS GERAIS .....................................................................................................16 1.3 OBJETIVOS ESPECÍFICOS .............................................................................................17 1.4 ESTRUTURA DO TRABALHO.........................................................................................17 2. REFERENCIAL TEÓRICO ..................................................................................................19 2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE .....................................................19 2.1.1 DEFINIÇÃO ..............................................................................................................19 2.1.2 PROCESSOS ÁGEIS ....................................................................................................20 2.1.2.1 SCRUM ..............................................................................................................20 2.2 QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE....................................................23 2.2.1 QUALIDADE.............................................................................................................23 2.2.1.1 CMMI .................................................................................................................24 2.3 ESTRUTURA DO CMMI ...............................................................................................27 2.3.1 REPRESENTAÇÕES ...................................................................................................27 2.3.1.1 REPRESENTAÇÃO CONTÍNUA E POR ESTÁGIOS ......................................................27 2.3.2 NÍVEIS DE MATURIDADE .........................................................................................30 2.3.3 COMPONENTES ........................................................................................................33 2.3.3.1 COMPONENTES REQUERIDOS...............................................................................34 2.3.3.2 COMPONENTES ESPERADOS.................................................................................34 2.3.3.3 COMPONENTES INFORMATIVOS ...........................................................................35 2.3.4 ÁREAS DE PROCESSOS .............................................................................................35 2.3.5 NOTAS INTRODUTÓRIAS ..........................................................................................36
  9. 9. 2.3.6 METAS ESPECÍFICAS................................................................................................36 2.3.7 SUBPRÁTICAS ..........................................................................................................36 2.3.8 PRÁTICAS ESPECÍFICAS............................................................................................37 2.3.9 METAS GENÉRICAS .................................................................................................37 2.3.10 PRÁTICAS GENÉRICAS.............................................................................................37 2.4 ÁREAS DE PROCESSO DO NÍVEL DE MATURIDADE 2 ...................................................38 2.4.1 GESTÃO DE REQUISITOS (REQM) ...........................................................................41 2.4.2 PLANEJAMENTO DE PROJETO (PP)...........................................................................41 2.4.3 MONITORAMENTO E CONTROLE DO PROJETO (PMC)..............................................43 2.4.4 GESTÃO DE CONTRATO COM FORNECEDORES (SAM) .............................................44 2.4.5 MEDIÇÃO E ANÁLISE (MA) .....................................................................................45 2.4.6 GARANTIA DE QUALIDADE DE PROCESSO E PRODUTO (PPQA)...............................45 2.4.7 GESTÃO DE CONFIGURAÇÃO (CM)..........................................................................46 3. PROJETO PARA IMPLANTAÇÃO DO CMMI DE NIVEL DE MATURIDADE DOIS ESCRUM NA EMPRESA REALIZE-SE............................................................................48 3.1 A EMPRESA.................................................................................................................48 3.2 RELATÓRIO .................................................................................................................49 3.2.1 REQUISITOS .............................................................................................................50 3.2.2 PLANEJAMENTO.......................................................................................................52 3.2.3 MONITORAMENTO E CONTROLE ..............................................................................55 3.2.4 FORNECEDORES .......................................................................................................56 3.2.5 MEDIÇÃO E ANÁLISE...............................................................................................57 3.2.6 GARANTIA DE QUALIDADE DE PROCESSO E PRODUTO.............................................59 3.2.7 GESTÃO DE CONFIGURAÇÃO ...................................................................................61 CONSIDERAÇÕES FINAIS ..............................................................................................63
  10. 10. REFERÊNCIAS......................................................................................................................65
  11. 11. Lista de Figuras Capítulo 2 Figura 1: Ciclo do Scrum [8] ............................................................................ 21 Figura 2 História dos CMM's [12] ................................................................... 25 Figura 3 Estrutura da Representação: Contínua e por Estágios [12] ............... 27 Figura 4 Estruturas da área de processo [13] ................................................... 32 Capítulo 3 Figura 5: Logo da Empresa Realize-se [15] ..................................................... 44
  12. 12. Lista de Tabelas Capítulo 2 Tabela 1: Comparação Entre Níveis de Capacidade e Maturidade [12] ............ 28 Tabela 2 Níveis de Maturidade x Categorias x Áreas de Processos [12] ......... 33 Capítulo 3 Tabela 3 Relação entre Criticidade e Complexidade ....................................... 56
  13. 13. 12 1. Introdução Com o grande avanço da tecnologia o mundo se torna cada vez mais informatizado e interligado. Diante disso, conhecer sistemas de informação é essencial para os administradores, porque a maioria das organizações precisa deles para sobreviver e prosperar. Esses sistemas podem auxiliar as empresas a estender seu alcance a locais distantes, oferecer novos produtos e serviços, reorganizar fluxos de tarefas e trabalho e, talvez, transformar radicalmente o modo como conduzem os negócios. Nesse sentido em desenvolvimento de software, no entender de Oliveira (2006), “três componentes principais determinam a qualidade de um produto: as pessoas que desenvolvem um sistema de software, a tecnologia que é empregada por eles, e a organização do processo de desenvolvimento” [1]. Diante desse cenário, uma grande questão se envolve na qualidade do pessoal atribuído às atividades no desenvolvimento de software, muitos gerentes de projetos não compreendem o que realmente os clientes buscam e na primeira conversa, antes de realizarem o detalhamento de todos os requisitos explícitos e implícitos, propõem aos seus clientes o que eles precisam e ainda estimam curtos prazos de entrega, sem mesmo antes verificar projetos que se encontram em andamento. Logo, vão à busca de profissionais que já entrem com boa produtividade de desenvolvimento, muitas vezes o novo colaborador não sabe sobre a linguagem que se usa na empresa e terá que aprender, diante disso, se percebe tal necessidade de experiência de mercado para contratações. As equipes possuem uma falta de controle do andamento do projeto, muitas vezes procuram soluções em terceirizar o trabalho visando entrega rápida, mas pela falta de acompanhamento na empresa prestadora, caem em um maior atraso, o que gera
  14. 14. 13 estouro em prazos, entrega de produtos incompletos, entre outros fatores prejudiciais para a empresa. No entanto, com o aumento do número de empresas no mercado e grande concorrência, cada vez mais organizações reconhecem a necessidade de gestão de processos e começam a empregar modelos de processos. Ainda no contexto de qualidade de desenvolvimento e processos de software, diversos padrões, metodologias e guias de qualidade foram desenvolvidos para atender as necessidades de processos consistentes. No Brasil uma metodologia nacional conceituada é o (MPS.BR – Melhoria de Processo do Software Brasileiro) um “modelo” utilizado para garantir que haja melhorias na qualidade do processo de desenvolvimento de softwares para a realidade do mercado de pequenas e médias empresas que atuam nessa área no Brasil [2]. Uma metodologia americana conceituada internacionalmente é o (CMMI - Capability Maturity Model Integration) uma abordagem de melhoria de processo que ajuda as organizações a melhorar o seu desempenho. CMMI pode ser usado para orientar a melhoria do processo através de um projeto, uma divisão ou uma organização inteira. CMMI em engenharia de software e desenvolvimento organizacional é uma abordagem de melhoria de processo que fornece às organizações os elementos essenciais para a melhoria do processo eficaz. CMMI é uma marca de propriedade do Software Engineering Institute da Carnegie Mellon University [3]. De acordo com o Instituto de Engenharia de Software (2006), CMMI ajuda a "integrar funções organizacionais tradicionalmente separadas, as metas de melhoria de processos definidos e prioridades, fornece orientações para processos de qualidade, e fornece um ponto de referência para a avaliação de processos em curso" [3].
  15. 15. 14 Existem também diversos modelos de processo, no qual fornece técnicas a serem seguidas pelos membros de desenvolvimento de software, como exemplo o SCRUM, seu nome foi inspirado em uma jogada do esporte Rugby um esporte coletivo de intenso contato físico originário da Inglaterra, na prática SCRUM é uma gestão baseada em metodologia ágil [4]. Um exemplo de empresa que busca melhoria de processos é o empreendimento Realize-se do estado de Goiás, Município de Goiânia o qual foi criada em 2011 e registrada em 28 de junho de 2013. Sendo que atualmente trata-se de uma pequena empresa que surgiu a partir de uma necessidade identificada onde o mercado busca cada vez mais por serviços facilitadores que sejam intermediadores entre os noivos, os convidados e fornecedores de produto ou serviços para este nicho, atuando em todo processo que envolve um casamento. Diante desse cenário, o objetivo deste trabalho de conclusão de curso é o desenvolvimento de projeto de melhoria de processos, com base em CMMI nível de maturidade 2, utilizando metodologia SCRUM para gerenciamento de projetos, na empresa Realize-se. Nesse sentido, para o desenvolvimento a equipe do presente trabalho propõe para a empresa alcançar uma área altamente competitiva, onde as exigências do mercado para produtos de software é muito alta e exige ciclos rápidos de desenvolvimento com resultados imediatos e adaptabilidade rápida de acordo com as constantes mudanças de requisitos, mas sem deixar de lado a garantia de qualidade. A metodologia ágil SCRUM descreve “o como fazer” e o modelo CMMI descreve “o que fazer” Alta flexibilidade é fornecida pela metodologia ágil SCRUM, e CMMI foi escolhido como o modelo para proporcionar e avaliar a qualidade do produto desenvolvido e os processos envolvidos no seu desenvolvimento.
  16. 16. 15 Com o desenvolvimento deste projeto haverá um ganho significativo para a empresa Realize-se, pois, com um processo gerenciado se ganha em redução de custos, o vendedor poderá usar como argumento de venda a qualidade assegurada do produto que está vendendo, melhoria da qualidade e maior satisfação do cliente, melhoria na entrega em cumprimento de prazos. Diante desse contexto, dos benefícios para as empresas do mundo real que o CMMI proporciona, de acordo com o Instituto CMMI em melhoria da qualidade “a IBM da Austrália na área de Serviços de gerenciamento de aplicativos fechou 95% dos problemas dentro do prazo especificado pelo cliente” [5]. Nos tópicos posteriores é apresentado o que foi motivado para a escolha do tema, os objetivos do trabalho e a fundamentação teórica que faz parte do contexto da proposta do projeto além da apresentação, da descrição/caracterização do mesmo e apresentação da proposta para implantação. 1.1 Motivação A fonte de inspiração à escolha deste tema é encontrada no fator do grande aumento de empresas no ramo de TI que trabalham no desenvolvimento de software. Tecnologia, desenvolvimento, rapidez, robustez, segurança, enfim, palavras que representam um pouco da realidade de uma das áreas que move o mundo atualmente, a área de TI, no qual as organizações dessa área encontram a necessidade de serem cada vez mais competitivas, e maduras organizacionalmente. Diante disso, justifica-se à importância desse trabalho como uma forma de descrever CMMI, focando nas áreas de processos do nível 2 de maturidade para empresas que desejam se adequar. Este modelo é um dos mais conhecidos, inclusive em nível mundial. Optando pela implantação do modelo a empresa terá mais facilidade para entregar o que realmente o cliente necessita, no prazo estimado, com aprovação de
  17. 17. 16 requisitos para entrega do orçamento, melhor comunicação em planejamento de projetos, realizar com grande precisão medição e análise afim de evitar perdas de capital, maior precisão ao utilizar versões com o gerenciamento de configuração, maior monitoramento com os fornecedores, realizar garantia de qualidade, elevar o desempenho organizacional, além de melhorar a qualidade de seus produtos. Ainda no contexto de maturidade devido as necessidades do mercado em que necessitam que os projetos sejam realizados em uma menor quantidade de tempo, com recursos limitados e, mesmo com todas essas restrições, é exigido que o projeto possua um nível de qualidade cada vez maior, optamos pela utilização do processo ágil Scrum, no qual realiza o gerenciamento de projetos de desenvolvimento de software. Essa pesquisa conterá informações importantes comentando sobre toda a estrutura do CMMI e Scrum. Estamos detalhando o nível gerenciado do CMMI, comentando suas áreas de processos, propondo medidas para que empresas consigam satisfazer cada área a fim de se adequar ao modelo nível 2 de maturidade. Optamos por desenvolver esta pesquisa pelo interesse de todos da equipe no assunto, que nos foi apresentado na disciplina do 5º período, Qualidade de Software ministrada pelo professor, Roberto Couto Lima, no curso Sistemas de Informação, do segundo semestre do ano de 2013. 1.2 Objetivos Gerais Pesquisar e analisar as características do CMMI um acrônimo de Capability Model Integration (Modelo de Maturidade e Capacidade Integrado) e SCRUM uma gestão baseada em metodologia ágil. Caracterizar o modelo integrado de maturidade de capacitação, comentando sobre sua estrutura, sua evolução e sua história. E por fim focar nas áreas de processos
  18. 18. 17 do nível gerenciado, desenvolvendo um projeto para implantação do CMMI nível de maturidade 2 e Scrum na empresa Realize-se. 1.3 Objetivos Específicos  Definir processo e qualidade no desenvolvimento de software;  Descrever o histórico do SCRUM;  Descrever o histórico do CMMI;  Indicar medidas a empresas que satisfaça as áreas de processos do nível de maturidade 2 do modelo integrado de maturidade de capacitação;  Explicar sobre os níveis de capacidade e maturidade do CMMI;  Evidenciar os componentes associados que o CMMI possui;  Elaborar um guia para implantação do modelo CMMI e Scrum na empresa Realize-se. 1.4 Estrutura do Trabalho Este documento tem a seguinte estrutura:  Capítulo 1 - Apresentação do projeto, expondo o objetivo do trabalho;  Capítulo 2 - Contém as referências, apresentando conceitos de termos que foram utilizados no documento;  Capítulo 3 - Apresenta a proposta destinada a empresa. O primeiro capítulo abordará a necessidade atual do mercado de software, os problemas encontrados pela nossa equipe para essa área, a solução proposta por institutos especializados em qualidade de software, a base escolhida pela nossa equipe para implantação na empresa Realize-se, a descrição da empresa, o objetivo da implantação e seus benefícios. O segundo capítulo será dividido em quatro partes:
  19. 19. 18 A primeira parte mostrará os processos de desenvolvimento de software. Nele será abordado os processos ágeis, que estão sendo cada vez mais utilizados devido à sua flexibilidade. A segunda parte do segundo capitulo irá falar sobre a qualidade no processo de desenvolvimento de software, apresentando características de um dos mais utilizados modelos de maturidade de processo, o CMMI. A terceira parte irá estar apresentando a estrutura do CMMI: as representações, os componentes, as áreas, notas, metas e as práticas e subpráticas. A quarta parte deste capitulo irá abordar as áreas de processos do CMMI nível 2, dando suas definições e suas metas a serem cumpridas. O capítulo final irá falar sobre a empresa e a proposta destinada a empresa. Nesse capitulo do trabalho serão apresentados as 7 áreas de processos que a empresa necessita atender para conseguir alcançar no nível 2 gerenciado do CMMI e Scrum.
  20. 20. 19 2. Referencial Teórico 2.1 Processos de desenvolvimento de software Esse tópico abordará conceitos sobre processos de desenvolvimento de software, apresentando um processo de desenvolvimento muito utilizado atualmente, e descrevendo os modelos de maturidade ou qualidade no processo de desenvolvimento de acordo com as suas características. 2.1.1 Definição Um processo de desenvolvimento pode ser definido como um conjunto de atividades ou práticas que objetivam a produção ou manutenção de um produto ou sistema de software; em outras palavras, passos que devem ser seguidos para o desenvolvimento de um determinado sistema de software. Segundo Tanaka, mesmo existindo vários processos de software, por padrão todos possuem algumas atividades em comum tais como: Especificação do software: responsável por descrever as funcionalidades e restrições do que o software irá conter; Projeto de implementação: garante que o software que será produzido irá atender todas as especificações levantadas; Validação do software: uma “avaliação” do software em relação às expectativas do cliente, pois indica se o software atende ou não tais expectativas; Evolução do software: processo de manutenções e alterações que o software sofre para que o mesmo atenda às “necessidades mutáveis” do cliente [6].
  21. 21. 20 Os processos como já foram ditos fornecem um “padrão de atividades” para o desenvolvimento de um sistema, porém, tais processos podem ser aprimorados ou customizados afim de automatizá-lo ou economizar recursos. O processo iterativo “divide” o projeto em pequenas e rápidas etapas (as iterações), em que é possível avaliar os requisitos de forma mais clara, estipulando ao final de cada iteração o nível de qualidade e confiabilidade dos requisitos em relação ao projeto, com isso obtém-se grande produtividade e menores níveis de falha. 2.1.2 Processos ágeis Devido às “necessidades dinâmicas” do mercado, as metodologias antigas de desenvolvimento estão se mostrando menos “atraentes” e eficientes em relação aos processos ágeis de desenvolvimento de software, pois é necessário que os projetos sejam realizados em uma menor quantidade de tempo com recursos limitados e, mesmo com todas essas restrições, é exigido que o projeto possua um nível de qualidade cada vez maior [6]. Diante disso, surgiram os processos ágeis, que assim como qualquer outro processo de desenvolvimento, possuem um conjunto de metodologias e propiciam uma base conceitual para criação de um projeto de software. 2.1.2.1 SCRUM Em 1995 o termo Scrum foi formalizado por Jeff Sutherland e Ken Schwaber. Porém, a sua prática, que são reuniões curtas para discutir próximos passos, foi introduzida anteriormente por empresas japonesas, conforme artigo publicado em 1986. E também foi verificado o aumento da produtividade na Borland Corporation, por meio da prática de reuniões diárias [7]. Teoricamente ele pode ser utilizado onde houver às necessidades de gerenciar um grupo de pessoas que trabalham juntas a fim de atingir um objetivo comum.
  22. 22. 21 O Scrum é uma das metodologias mais dinâmicas em gerência de projetos é um processo iterativo e incremental para o desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho sendo dividido em três fases: planejamento (Pregame), execução Sprint (ciclos) ou (Game) e encerramento (Post-Game). É uma gestão baseada em metodologia ágil, compreende-se em executar reuniões, planejados com metas de curto prazo, realizadas por toda a equipe do projeto com objetivo em produzir um produto. Nas reuniões é preferível a presença do cliente, sendo fundamental a troca de informações e de emoções. A partir de uma lista de metas chamada de Product Backlog, definidas por um responsável pelo produto objeto do desenvolvimento, dentre elas já estabelecidas em ordem de prioridade. Cada equipe de 6 a 10 pessoas fica responsável pelo cumprimento de metas conforme uma lista de tarefas chamadas de Sprint Backlog. O objetivo do Scrum é realizar atividades de maneira iterativa chamadas de Sprints, que são reuniões diárias. Estas que devem ser rápidas e objetivas, inclusive podendo ser realizadas em pé. Este encontro tem a finalidade de reportar atividades realizadas desde o último Sprint, identificar dificuldades, dar prioridade às tarefas a serem realizadas. O detalhamento de uma dificuldade ou até mesmo resoluções de problemas não são objetivos desta metodologia. Caso sejam identificadas dificuldades para executar determinada atividade, faz-se uma reunião ao par para o estudo do problema e levantamento de alternativas, sempre sob responsabilidade do facilitador e coordenador dos Sprints chamado de Scrum Master. Ao terminar o Sprint e demostrado o Sprint Review Meeting que é nada mais que a demonstração de todas as funcionalidades implementadas no projeto de software e assim por final é feita a Sprint Retrospective e a equipe parte para o planejamento de um novo Sprint e o ciclo se reinicia[6], conforme figura 1.
  23. 23. 22 Figura 1 – Ciclo do Scrum [8].  Product Backlog: É uma lista contendo todas as funcionalidades desejadas para um produto;  Product Owner: É a pessoa que define os itens do Product Backlog e os prioriza nas Sprint Planning Meetings o PO Team é o diálogo para priorizar o Product Backlog que acontece na reunião de planejamento da Sprint;  Sprint Backlog: É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint;  Sprint Planning Meeting: É uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente;  O Scrum Team: É a equipe de desenvolvimento;  O Scrum Master: É o que procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum;  Daily Scrum: É uma breve reunião diária que a equipe realiza a cada dia do Sprint, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que impede de seguir avançando (também conhecido como:
  24. 24. 23 Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião);  Release Burndown: Em um projeto Scrum, a equipe monitora seu progresso em relação a um plano atualizando um Release Burndown Chart 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: story points, dias ideais, team days e assim por diante [8]. 2.2 Qualidade no desenvolvimento de software Para a compreensão sobre padrões de qualidade de software, esta parte do referencial irá apresentar um dos modelos mais utilizados para garantir a qualidade no processo de desenvolvimento de software, mostrando a forma com que ele interage no processo e os resultados que devem ser obtidos para que seja considerado um processo de qualidade. 2.2.1 Qualidade Existem atualmente alguns padrões que são utilizados pelas empresas a fim de garantir e mensurar o nível de qualidade que estas possuem em relação ao seu processo de desenvolvimento. O resultado é obtido por meio de métricas e avaliações, e garante maior aceitabilidade e credibilidade por parte das empresas contratantes dessa categoria de serviços (o desenvolvimento de sistemas). Um dos principais modelos de qualidade é o CMMI.
  25. 25. 24 2.2.1.1 CMMI Um modelo de referência utilizado para garantir a qualidade no desenvolvimento de softwares é o CMMI. O modelo referenciado foi desenvolvido pelo SEI da Universidade Carnegie Mellon - EUA e patrocinado pelo Departamento de Defesa Americano (DoD), e visa estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. A versão atual do CMMI é a 1.3 e apresenta três modelos [9]: O primeiro, que foi publicado em agosto de 2006:  CMMI for Development (CMMI-DEV): CMMI para desenvolvimento;  Utilizado em processo de desenvolvimento de produtos e serviços. O segundo publicado em novembro de 2007:  CMMI for Acquisition (CMMI-ACQ): CMMI para aquisição;  Utilizado em processos de aquisição e terceirização de bens e serviços. E o último publicado em fevereiro de 2009:  CMMI for Services (CMMI-SVC): CMMI para serviços;  Utilizado em processos de empresas prestadoras de serviços. O CMMI é uma evolução do CMM (modelo de qualidade de software que objetiva controlar o processo de desenvolvimento, por meio de diretivas que sugerem meios de se obter o controle, e que são responsáveis por apresentar formas de evolução para um padrão de excelência na gestão de software) [9]. O modelo CMMI é composto pelas melhores práticas associadas às atividades de desenvolvimento e de manutenção de software desde a sua concepção até a entrega e manutenção. Essas práticas genéricas e especificas, é necessária a maturidade em disciplinas especificas como: Engenharia de Sistemas, Engenharia de Software, Engenharia de Hardware, Desenvolvimento Integrado de Produtos, Processos,
  26. 26. 25 Aquisição e Suporte, dando uma visão estruturada da melhoria da visão de processos de uma organização. Através de pesquisas, o SEI encontrou três dimensões críticas que as organizações pode focar para melhorar seus negócios: pessoas, procedimentos, métodos, ferramentas e equipamentos. Os processos utilizados nas organizações mantêm a coesão dessas dimensões. Os processos alinham a maneira de fazer negócio, aumentam o desempenho, facilitam a incorporação das melhores práticas, enfim, processos permitem a otimização de recursos e uma melhor compreensão dos negócios. Além disso, eles auxiliam a organização a alcançar seus objetivos trabalhando de forma mais inteligente com menos esforço e maior consistência. Segundo o Software Engineering Institute os CMM's se originaram nos anos 30 quando Walter Shewhart começou a desenvolver um trabalho de melhoria de processos utilizando princípios de controle estatístico de qualidade. Mais tarde esses princípios foram melhores trabalhados por W. Edwards Deming e Joseph Juran. A partir desses trabalhos, em 1989, Watts Humphrey e Ron Radice e outros estudiosos começaram a aplicar esses princípios em software dentro da IBM e do SEI, seus trabalhos na época. Alguns CMM's são baseados no trabalho de Humphrey, Managing the Software Process, utilizando conceitos básicos. O SEI desenvolveu seu primeiro CMM para organizações de software e em seguida publicou seu primeiro livro, The Capability Maturity Model: Guidelines for Improving the Software Process em 1995 [3].
  27. 27. 26 Figura 2 - História dos CMM's [12]. Desde 1991 foram desenvolvidos CMM's para várias disciplinas, dentre elas as mais conhecidas como Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gestão e Desenvolvimento de Força de Trabalho e Desenvolvimento Integrado de Processo e Produto. Infelizmente o uso múltiplo desses modelos para as organizações foi complicado. Diante dessa situação segundo a empresa Select Business Solutions o projeto do CMM Integration foi desenvolvido a partir da combinação de três modelos [10]:  SW-CMM v2.0 draft C;  SECM;  IPD-CMM v0.98. Esses modelos foram escolhidos pela sua popularidade nas comunidades de Software e de Engenharia de Sistemas, e pelas suas diferentes abordagens para melhoria
  28. 28. 27 de processo na organização. O objetivo era desenvolver um framework em que as organizações poderiam se apoiar para buscar melhorias de processos na corporação. Ao final da integração a equipe do produto CMMI construiu um material que acomodava múltiplas disciplinas e era flexível o suficiente para apoiar as diferentes abordagens dos CMM anteriores. 2.3 Estrutura do CMMI 2.3.1 Representações O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse. No entender de Groffe (2013): A implantação do CMMI é recomendável para grandes fábricas de software. Implementar os diversos estágios é uma tarefa árdua, não só numa fase inicial, mas também quando se leva em conta a migração de um nível para outro. Isto exigirá, invariavelmente, a realização de vultosos investimentos financeiros, assim como uma mudança de postura da organização (principalmente quando a mesma não contava com uma experiência anterior bem-sucedida no gerenciamento de processos) [11]. 2.3.1.1 Representação contínua e por estágios Conforme apresentado na figura 3 abaixo, é ilustrada a estrutura da representação contínua e por estágios, onde nota-se a diferença da estrutura de ambas as representações: enquanto a representação contínua utiliza níveis de capacidade nas metas e práticas genéricas a representação por estágios utiliza níveis de maturidade nas áreas de processo.
  29. 29. 28 Figura 3 - Estrutura da Representação: Contínua e por Estágios [12]. Mas também há semelhanças entre elas, ambas têm os mesmos componentes (Áreas de Processos, Metas Especificas, Metas Genéricas) e esses componentes tem a mesma hierarquia de configuração. Níveis de capacidade, associados à representação contínua, aplicam-se à melhoria de processo da organização em áreas de processos individuais. Esses níveis são um meio para melhorar, de forma incremental, os processos correspondentes a uma determinada área de processo. Há seis níveis de capacidade, numerados de 0 a 5.
  30. 30. 29 Níveis de maturidade, associados à representação por estágios, aplicam-se à melhoria de processo da organização em um conjunto de áreas de processo. Esses níveis auxiliam na previsão dos resultados de futuros projetos. Há cinco níveis de maturidade, numerados de 1 a 5. A Tabela 1 compara os seis níveis de capacidade com os cinco níveis de maturidade. Aonde temos quatro níveis com os mesmos nomes em ambas as representações. Onde as diferenças são: que não tem nível de maturidade 0 para a representação por estágios, e no nível 1, o nível de capacidade é “Executado”, ao passo que o nível de maturidade é “Inicial”. Assim, o ponto de partida é diferente para as duas representações. Tabela 1 - Comparação Entre Níveis de Capacidade e Maturidade [12]. A representação contínua preocupa-se tanto com a seleção de uma determinada área de processo para realizar melhorias quanto com a definição do nível de capacidade desejado para aquela área de processo. Com isso, é importante saber se um processo é “executado” ou “incompleto”. Portanto, se inicia representação contínua em “incompleto”. Já a representação por estágios preocupa-se com a maturidade da organização, não tendo como preocupação inicial se o processo é executado ou
  31. 31. 30 incompleto. Portanto, o ponto de partida da representação por estágios é chamado de “inicial”. 2.3.2 Níveis de Maturidade Para apoiar o uso da representação por estágios, todos os modelos CMMI refletem os níveis de maturidade em seu design e conteúdo. Segundo o (CMUSEI) "Um nível de maturidade é composto por práticas específicas e genéricas relacionadas a um conjunto predefinido de áreas de processos que melhoram o desempenho global da organização" [3]. O nível de maturidade de uma organização é uma indicação do desempenho da organização em uma determinada disciplinada ou conjunto de disciplinas. A experiência mostra que as organizações têm seu melhor desempenho quando focam os esforços de melhoria de processo em um número gerenciável de áreas de processos em um dado momento, e que essas áreas requerem sofisticação crescente à medida que a organização melhora. Um nível de maturidade é um plano evolutivo definido para melhoria de processo da organização. Cada nível de maturidade representa o amadurecimento de um importante subconjunto dos processos da organização, preparando-os para alcançar o próximo nível de maturidade. Os níveis de maturidade são medidos pela satisfação das metas específicas e genéricas associadas a cada conjunto predefinido de áreas de processo. Existem 5 níveis de maturidade. Cada um é uma camada que representa a base para as atividades de melhoria contínua de processo: 1. Inicial. 2. Gerenciado. 3. Definido. 4. Gerenciado Quantitativamente.
  32. 32. 31 5. Em Otimização. Nível de Maturidade 1 - Inicial: No nível de maturidade 1, geralmente os processos são ad hoc (expressão latina cuja tradução literal é “para isto”) e caóticos. Esse tipo de organização não fornece um ambiente estável para apoiar os processos. O sucesso depende da competência e do heroísmo das pessoas e não do uso dos processos comprovados. Apesar deste caos, organizações no nível de maturidade 1 frequentemente produzem produtos e serviços que funcionam. Entretanto, com frequência, eles extrapolam seus orçamentos e não cumprem seus prazos [3]. As organizações no nível de maturidade 1 são caracterizadas pela tendência de se comprometer além da sua capacidade, por abandonar o processo em um momento de crise, e por serem incapazes de repetir os próprios sucessos. Nível de Maturidade 2 – Gerenciado: No nível de maturidade 2, os projetos da organização têm a garantia de que os processos são planejados e executados de acordo com o planejamento; os projetos empregam pessoas experientes que possuem recursos; envolvem partes interessadas; são monitorados, controlados e revisados; e são avaliados para verificar sua união em relação à descrição de processo. A disciplina de processo nível de maturidade 2 contribui para que as práticas existentes sejam mantidas durante períodos de stress. Quando essas práticas estão em vigor, os projetos são executados e gerenciados de acordo com seus planos documentados. No nível de maturidade 2, o status dos produtos de trabalho e a entrega estão definidos. Os compromissos com as partes interessadas são estabelecidos e revisados. Os produtos de trabalho são controlados. Os produtos de trabalho e serviços satisfazem expectativas definidas pelas partes interessadas.
  33. 33. 32 Nível de Maturidade 3 – Definido: No nível de maturidade 3, os processos são caracterizados e definidos, são descritos em padrões, procedimentos, ferramentas e métodos. O conjunto de processos- padrão da organização é estabelecido e melhorado com o tempo, deste são utilizados para estabelecer padrões à organização. Os projetos estabelecem seus processos definidos ao adaptar o conjunto de processos-padrão da organização de acordo com as diretrizes para adaptação. No nível de maturidade 3, a organização deve amadurecer mais as áreas de processo do nível de maturidade 2. As práticas genéricas associadas à meta genérica 3 que não foram tratadas no nível de maturidade 2 são aplicadas para alcançar o nível de maturidade 3 [3]. Nível de Maturidade 4 - Gerenciado Quantitativamente: No nível de maturidade 4, a organização e os projetos estabelecem objetivos quantitativos para qualidade e para desempenho de processo, utilizando-os como critérios na gestão de processos. Objetivos quantitativos baseiam-se nas necessidades dos clientes, dos usuários finais, da organização e dos responsáveis pela implementação de processos. A qualidade e o desempenho de processo são entendidos em termos estatísticos e gerenciados ao longo da vida dos processos. Para subprocessos selecionados, medidas detalhadas de desempenho de processo são coletadas e analisadas estatisticamente. As medidas da qualidade e do desempenho de processo são incorporadas no repositório de medições da organização para apoiar a tomada de decisão baseada na pesquisa. Identificam-se as principais causas de variação de processo e onde, as causas dos problemas são corrigidas, assim prevenindo que tais erros se repitam [3]. Nível de Maturidade 5 - Em Otimização:
  34. 34. 33 No nível de maturidade 5, uma organização melhora continuamente seus processos com base no entendimento quantitativo das causas comuns de variação presente no processo. O nível de maturidade 5 tem foco na melhoria contínua do desempenho de processo por meio de melhorias incrementais e inovadoras de processo e de tecnologia. Os objetivos quantitativos de melhoria de processo para a organização são estabelecidos, continuamente revisados para refletir as mudanças nos objetivos estratégicos e são utilizados como critérios na gestão de melhoria de processo. Os efeitos das melhorias de processo implantadas são medidos e avaliados em relação aos objetivos quantitativos de melhoria de processo. Tanto os processos definidos quanto o conjunto de processos-padrão da organização são alvo de atividades de melhoria mensuráveis [3]. 2.3.3 Componentes O modelo CMMI possui três diferentes componentes associados. São eles os componentes requeridos, esperados e informativos. A Figura 4 abaixo ilustra a estrutura da área de processo, com seus objetivos específicos com as práticas especificas e os objetivos genéricos com as práticas genéricas.
  35. 35. 34 Figura 4 - Estruturas da área de processo [13]. 2.3.3.1 Componentes Requeridos Os componentes requeridos descrevem o que uma organização tem que realizar para satisfazer uma determinada área de processo. Estas realizações devem estar implementadas nos processos da organização. Este componente corresponde às metas especificas e as metas genéricas. O critério utilizado para decidir se uma área de processo foi implementada de maneira adequada e a satisfação de metas. 2.3.3.2 Componentes Esperados Os componentes esperados descrevem o que uma organização pode executar para satisfazer um componente requerido, orientando o responsável a implantar melhorias ou executar avaliações. Este componente corresponde às práticas especificas
  36. 36. 35 e as práticas genéricas. Para que as metas sejam consideradas satisfeitas, as práticas devem estar presentes nos processos planejados e implementados da organização. 2.3.3.3 Componentes Informativos Os componentes informativos auxiliam na implementação dos componentes requeridos e esperados. São exemplos deste componente: Subpráticas, produtos de trabalho típicos, extensões, orientações para aplicação de prática genérica, títulos de metas e práticas, notas de metas e práticas, e referências a outras áreas de processo. 2.3.4 Áreas de Processos Segundo o (CMUSEI) "Áreas de processos são um conjunto de práticas relacionadas a uma área que, quando implementadas, satisfazem a um conjunto de metas consideradas importantes para realizar melhorias significativas naquela área" [3]. Existem 22 áreas de processos relacionadas aos 5 níveis de maturidade. São elas apresentadas na ordem na Tabela 2, agrupadas em quatro categorias de afinidade: Tabela 2 - Níveis de maturidade X Categorias X Áreas de Processos [12]. Cada área de processo possui um objetivo específico, por exemplo, o texto da seção Objetivo da Área de Processo Definição dos Processos da Organizacional (OPD)
  37. 37. 36 é: “fornecer subsídios para estabelecer e manter um conjunto utilizável de ativos de processo da organização e de padrões de ambiente de trabalho” [3]. 2.3.5 Notas Introdutórias Notas Introdutórias é um componente informativo que descreve os principais conceitos abordados nas áreas de processo. Por exemplo, o conteúdo das notas introdutórias da área de processo Planejamento de Projeto é: “O planejamento tem início com os requisitos que caracterizam o produto e o projeto” [3]. 2.3.6 Metas Específicas Segundo o (CMUSEI) "Uma meta específica (SG) descreve as características que devem estar presentes para uma implementação se adequada a área de processo" [3]. Os processos do CMMI possuem de 1 a 3 metas específicas por processo. Ela é um componente requerido do modelo utilizada nas avaliações para determinar se uma área de processo está implementada. Por exemplo, uma meta específica da área de processo Gestão de Configuração é: “A integridade dos baselines é estabelecida e mantida”. Baseline é um Conjunto de especificações ou produtos de trabalho formalmente revisados e acordados, que servem como base para desenvolvimentos a partir de então. Um baseline só pode ser alterado por meio de procedimentos de controle de mudanças [3]. 2.3.7 Subpráticas Segundo o (CMUSEI) "A subprática é uma descrição detalhada que orienta a interpretação e implementação de uma prática específica ou uma prática genérica" [3]. Podem ser expressas de forma prescritiva, mas, na verdade, são componentes informativos que apenas visam fornecer ideias que sejam úteis para melhoria de processo.
  38. 38. 37 Por exemplo, uma subprática para a prática específica “Implementações corretivas para tratar as questões críticas identificadas”, na área de processo Monitoramento e Controle de Projeto, é: “Determinar e documentar as ações apropriadas necessárias para tratar as questões críticas identificadas” [2]. 2.3.8 Práticas Específicas A prática específica (SP) é a descrição de atividades importantes para satisfazer uma meta específica associada. As práticas específicas são componentes esperados com o objetivo de satisfazer metas específicas de uma área de processo. Por exemplo, uma prática específica da área de processo Gestão de Contrato com Fornecedores é: “Avaliar produtos de trabalho selecionados do fornecedor” [3]. 2.3.9 Metas Genéricas Metas genéricas são chamadas assim, pois valem para todas as áreas de processos de uma forma única, de maneira que a mesma meta irá significar para todas as outras áreas de processo. Existem metas genéricas para os níveis de capacidade de 1 a 5 e para os níveis de maturidade 2 e 3. São componentes requeridos do modelo utilizadas nas avaliações para determinar se uma área de processo está implementada. Elas descrevem as características necessárias para institucionalizar os processos que implementam a área de processo [3]. Um exemplo de meta genérica é: “O processo é institucionalizado como um processo definido”. 2.3.10 Práticas Genéricas As práticas genéricas são componentes esperados do modelo e são denominadas “genéricas” porque a mesma prática se aplica a várias áreas de processo. Segundo o
  39. 39. 38 (CMUSEI) "descrevem uma atividade considerada importante para a satisfação da meta genérica associada" [3]. Por exemplo, uma prática genérica da meta genérica “O processo é institucionalizado como um processo gerenciado” é: “Fornecer os recursos adequados para execução do processo de monitoramento e controle de projeto, envolvendo o desenvolvimento de produtos de trabalho e fornecimento dos serviços do processo”. 2.4 Áreas de Processo do Nível de Maturidade 2 Nesta parte do trabalho irá ser apresentado as áreas de processo do nível de maturidade 2, onde os processos básicos de gestão são definidos. Conforme será abordado no próximo capitulo a empresa “Realize-se” se encontra no processo inicial do nível de maturidade, ou seja, o nível 1. Para atingir o nível de maturidade 2 a empresa precisa criar uma base que seus processos sejam planejados e executados de acordo com o planejado, conforme será abordado no capitulo três. O nível de maturidade 2 é composto por sete áreas de processos, de acordo com a representação por estágios, sendo eles: 1) Gestão de Requisitos (REQM - Requirements Management); 2) Planejamento de Processo (PP - Project Planning); 3) Monitoramento e Controle do Projeto (PMC- Project Monitoring and Control); 4) Gestão de Contrato com Fornecedores (SAM- Supplier Agreement Management); 5) Medição e Análise (MA - Measurement and Analysis); 6) Garantia de Qualidade de Processo e Produto (PPQA - Process and Product Quality Assurance); 7) Gestão de Configuração (CM– Configuration Manegement) [12];
  40. 40. 39 Todas as áreas de processos possuem seus objetivos específicos (SG – specific goal), e cada um desses são subdivididos em práticas especificas (SP – specific practice), e essas são ainda mais detalhadas nas subpráticas. Além dos objetivos específicos o nível de maturidade 2 possui seus objetivos genéricos que tem a função de institucionalizar um processo gerenciado. O nível gerenciado possui os seguintes objetivos genéricos (GG – generic goal) seguidos de suas práticas genéricas (GP – generic practices) e os objetivos de cada uma [3]: GG 2 – Institucionalizar um Processo Gerenciado: GP 2.1 – Estabelecer uma Política Organizacional: 1) Estabelecer e manter uma política organizacional para planejamento e execução do processo de desenvolvimento de requisitos; GP 2.2 – Planejar o Processo: 2) Estabelecer e manter o plano para a execução do processo de desenvolvimento de requisitos; GP 2.3 – Fornecer Recursos: 3) Fornecer os recursos adequados para execução do processo de desenvolvimento de requisitos, envolvendo o desenvolvimento de produtos de trabalho e fornecimento dos serviços do processo; GP 2.4 – Atribuir Responsabilidades: 4) Atribuir responsabilidade e autoridade para execução do processo de desenvolvimento de requisitos, para desenvolvimento dos produtos de trabalho e fornecimento dos serviços do processo;
  41. 41. 40 GP 2.5 – Treinar Pessoas: 5) Treinar pessoas para executar ou apoiar o processo de desenvolvimento de requisitos conforme necessário; GP 2.6 – Gerenciar Configurações: 6) Colocar produtos de trabalho selecionados do processo de desenvolvimento de requisitos sob níveis apropriados de controle; GP 2.7 – Gerenciar e Envolver as Partes Interessadas Relevantes: 7) Identificar e envolver as partes interessadas relevantes do processo de desenvolvimento de requisitos conforme planejado; GP 2.8 – Monitorar e Controlar o Processo: 8) Monitorar e controlar o processo de desenvolvimento de requisitos em relação ao estabelecido no plano para execução do processo, e implementar ações corretivas apropriadas; GP 2.9 – Avaliar Objetivamente a Aderência: 9) Avaliar objetivamente a aderência do processo de desenvolvimento de requisitos em relação a sua descrição, padrões e procedimentos, e tratar não conformidades; GP 2.10 – Revisar Status com Gerência de Nível Superior: 10) Revisar as atividades, o status e os resultados do processo de desenvolvimento de requisitos com a gerência de nível superior e tratar questões críticas.
  42. 42. 41 2.4.1 Gestão de Requisitos (REQM) O objetivo desta área de processo é gerenciar os requisitos técnicos e não técnicos absorvidos ou gerados por um projeto, identificando as inconsistências em relação aos planos e produtos do projeto e tratando de forma adequada as mudanças necessárias e seus impactos [14]. Esse ciclo é de extrema importância para as áreas do projeto, com isso deve-se manter o controle de requisitos sempre atualizado. Alguns exemplos na prática em que não se aplica REQM em CMMI para Desenvolvimento nas organizações são:  O cliente pede uma coisa e é feito outra;  No primeiro contato com o cliente já é estipulado o valor e o prazo, sem mesmo verificar os projetos que estão em andamento. As metas (SG – specific goal) e práticas específicas (SP – specific practice) da área Gestão de Requisitos são [3]: SG 1 – Gerenciar Requisitos: SP 1.1 – Obter Entendimento dos Requisitos; SP 1.2 – Obter Comprometimento com os Requisitos; SP 1.3 – Gerenciar Mudanças nos Requisitos; SP 1.4 – Manter Rastreabilidade Bidirecional dos Requisitos; SP 1.5 – Identificar Inconsistências entre Produtos de Trabalho, Planos de Projeto e Requisitos. 2.4.2 Planejamento de Projeto (PP) O objetivo desta área de processo é estabelecer e manter planos que definem as atividades dos projetos, envolvendo a elaboração de estimativas, o estabelecimento do nível adequado de interação com os grupos envolvidos e a obtenção de compromissos
  43. 43. 42 [10]. Alguns exemplos na prática em que não se aplica PP em CMMI nas organizações são:  O planejamento do projeto não chega até a equipe de desenvolvimento;  Não é verificado pelo gerente do projeto se o programador que vai escrever os códigos vai sair de férias durante o período de desenvolvimento do sistema;  Não é feito plano de risco como no caso em que certos meses do ano chovem constantemente, no qual não é verificada tal necessidade de alugar um gerador de energia, pois caso ocorra quedas de rede elétrica durante o trabalho, irá prejudicar o andamento do projeto. As metas e práticas específicas da área Planejamento de Processo são [3]: SG 1 – Estabelecer Estimativas: SP 1.1 – Estimar o Escopo do Projeto; SP 1.2 – Estabelecer Estimativas para Atributos de Produtos de Trabalho e de Tarefas; SP 1.3 – Definir Ciclo de Vida do Projeto; SP 1.4 – Determinar Estimativas de Esforço e Custo. SG 2 – Elaborar um Plano de Projeto: SP 2.1 – Estabelecer Orçamento e Cronograma; SP 2.2 – Identificar Riscos do Projeto; SP 2.3 – Planejar Gestão de Dados; SP 2.4 – Planejar Recursos do Projeto; SP 2.5 – Planejar Habilidades e Conhecimento Necessários; SP 2.6 Planejar o Envolvimento das Partes Interessadas; SP 2.7 Estabelecer o Plano do Projeto. SG 3 – Obter Comprometimento com o Plano:
  44. 44. 43 SP 3.1 – Revisar Planos que Afetam o Projeto; SP 3.2 – Conciliar Carga de Trabalho e Recursos; SP 3.3 – Obter Comprometimento com o Plano. 2.4.3 Monitoramento e Controle do Projeto (PMC) O objetivo desta área de processo é permitir uma visibilidade adequada do progresso do projeto, de forma que possam ser tomadas ações corretivas apropriadas quando o seu desempenho apresentar desvios significativos em relação ao planejado "(replanejamento, estabelecimento de novos acordos e/ou mitigação de riscos)" [10]. Um exemplo na prática em que não se aplica PMC em CMMI nas organizações é:  O andamento do projeto pela equipe de desenvolvimento está no tempo de conclusão pela metade, mas na visão do gerente se encontra quase finalizado. As metas, práticas específicas e subpráticas da área Monitoramento e Controle do Projeto são: SG 1 – Monitorar o Projeto em Relação ao Plano: SP 1.1 – Monitorar os Parâmetros de Planejamento do Projeto; SP 1.2 – Monitorar Compromissos; SP 1.3 – Monitorar Riscos do Projeto; SP 1.4 – Monitorar a Gestão de Dados; SP 1.5 – Monitorar o Envolvimento das Partes Interessadas; SP 1.6 – Conduzir Revisões de Progresso; SP 1.7 – Conduzir Revisões de Marco. SG 2 – Gerenciar Ações Corretivas até sua Conclusão: SP 2.1 – Analisar Questões Críticas; SP 2.2 – Implementar Ações Corretivas; SP 2.3 – Gerenciar Ações Corretivas.
  45. 45. 44 2.4.4 Gestão de Contrato com Fornecedores (SAM) O objetivo desta área de processo é gerenciar a aquisição de produtos de fornecedores externos para os quais existe um acordo formal "produtos e/ou componentes entregáveis ao cliente, ou mesmo ferramentas e ambientes operacionais para o projeto " [10]. Alguns exemplos na prática em que não se aplica SAM em CMMI para desenvolvimento nas organizações são:  A empresa não monitora o trabalho do fornecedor;  O gerente de projeto muitas vezes procura formas de terceirizar o trabalho visando entrega rápida, mas muitas vezes, atrasa ainda mais a entrega do produto. As metas e práticas específicas da área Gestão de Contrato com Fornecedores são: SG 1 – Estabelecer Contratos com Fornecedores: SP 1.2 – Selecionar Fornecedores; SP 1.3 – Estabelecer Contratos com Fornecedores. SG 2 – Cumprir Contratos com Fornecedor: SP 2.1 – Executar Contrato com Fornecedor; SP 2.2 – Monitorar Processos Selecionados do Fornecedor; SP 2.3 – Avaliar Produtos de Trabalho Selecionados do Fornecedor; SP 2.4 – Aceitar Produto Adquirido; SP 2.5 – Transferir Produtos.
  46. 46. 45 2.4.5 Medição e Análise (MA) "O objetivo desta área de processo é desenvolver e manter uma capacitação de medição para suportar as necessidades de informações gerenciais, em termos de conceitos, técnicas e mecanismos de execução" [10]. Um exemplo na prática em que não se aplica MA em CMMI nas organizações é:  A empresa perde dinheiro sem saber o motivo. As metas e práticas específicas da área Medição e Análise são: SG 1 – Alinhar Atividades de Medição e Análise: SP 1.1 – Estabelecer Objetivos de Medição; SP 1.2 – Especificar Medidas; SP 1.3 – Especificar Procedimentos de Coleta e Armazenamento de Dados; SP 1.4 – Especificar Procedimento de Análise. SG 2 – Fornecer Resultados de Medição: SP 2.1 – Coletar Dados Resultantes de Medição; SP 2.2 – Analisar Dados Resultantes de Medição; SP 2.3 – Armazenar Dados e Resultados; SP 2.4 – Comunicar Resultados. 2.4.6 Garantia de Qualidade de Processo e Produto (PPQA) "Objetivo desta área de processo é prover aos integrantes das equipes uma visibilidade mais clara do andamento dos processos e dos produtos gerados, através de avaliações objetivas em relação às especificações, da identificação de não conformidades e do acompanhamento de ações corretivas" [10]. Um exemplo na prática em que não se aplica MA em CMMI nas organizações é:  Antes de entregar o produto final para o usuário não são realizados testes pela equipe para que o produto ofereça garantia de qualidade.
  47. 47. 46 As metas e práticas específicas da área Garantia de Qualidade de Processo e Produto são [3]: SG 1 – Avaliar Objetivamente Processos e Produtos de Trabalho: SP 1.1 – Avaliar Objetivamente os Processos; SP 1.2 – Avaliar Objetivamente Produtos de Trabalho e Serviços. SG 2 – Fornece Visibilidade: SP 2.1 – Comunicar e Assegurar a Solução de Não conformidades; SP 2.2 – Estabelecer Registros. 2.4.7 Gestão de Configuração (CM) O objetivo desta área de processo é estabelecer e manter a integridade dos produtos de trabalho através da identificação, do controle, da verificação e do monitoramento constante da situação da sua configuração [10]. Um exemplo na prática em que não se aplica CM em CMMI nas organizações é:  Os desenvolvedores/programadores muitas vezes sem saber qual versão utilizar, perdem o que já tinha sido codificado; As metas e práticas específicas da área Gestão de Configuração são [3]: SG 1 – Estabelecer Baselines: SP 1.1 – Identificar Itens de Configuração; SP 1.2 – Estabelecer um Sistema de Gestão de Configuração; SP 1.3 – Criar ou Liberar Baselines. SG 2 – Acompanhar e Controlar Mudanças: SP 2.1 – Acompanhar Solicitações de Mudança; SP 2.2 – Controlar Itens de Configuração.
  48. 48. 47 SG 3 – Estabelecer Integridade: SP 3.1 – Estabelecer Registros de Gestão de Configuração; SP 3.2 – Executar Auditorias de Configuração.
  49. 49. 48 3. PROJETO PARA IMPLANTAÇÃO DO CMMI DE NIVEL DE MATURIDADE DOIS E SCRUM NA EMPRESA REALIZE-SE Após compreender a estrutura do Scrum e do CMMI no capítulo anterior, neste capitulo nossa equipe irá demonstrar uma proposta para a implantação do modelo CMMI na empresa Realize-se utilizando a metodologia ágil Scrum. 3.1 A Empresa Figura 5 - Logo da Empresa Realize-se [15].  Empreendimento: Realize-se;  Idade: Três anos;  Área de atuação: Site de Relacionamento de noivos;  Produto: Website que permite a criação de uma página com o intuito facilitar para noivos preparativos para o casamento;  Porte: Pequeno porte, em fase de desenvolvimento;  Clientes: Noivos e Fornecedores. O projeto Realize-se surgiu a partir de uma necessidade identificada onde o mercado busca cada vez mais por serviços facilitadores que sejam intermediadores
  50. 50. 49 entre os noivos, os convidados e fornecedores de produto ou serviços para este nicho, atuando em todo processo que envolve um casamento. Propõe-se com este projeto; a criação de um Web Site, subdividido em duas partes: uma para atender às necessidades dos noivos, facilitando o contato com os convidados (o Site Personalizado dos Noivos), e outra para intermediar o contato entre os fornecedores e os canais (o Guia de Empresas). Sua viabilidade técnica é expansível para outros Estados do Brasil [15]. A seguir nossa equipe irá apresentar o relatório orientando a organização as mudanças que devem ser realizadas, informamos que o CMMI mostra “O QUÊ” fazer, e não “COMO” fazer. Esse trabalho tem o intuito de ajudar tanto a empresa Realize-se quanto outras pequenas empresas. 3.2 Relatório A empresa Realize-se possui uma equipe pequena e se encontra desestruturada para se adequar as áreas de processo do nível de maturidade 2 do modelo CMMI. Com este relatório traçaremos mudanças utilizando a metodologia Scrum. Durante o estágio realizado foi percebido que os requisitos não eram gerenciados da maneira correta. A infraestrutura da empresa era incompleta e não usava as ferramentas necessárias para a organização obter sucesso e ficar livre de erros. Não havia controle durante a criação de algo novo ou durante mudanças. Antes de serem iniciados projetos não havia um planejamento prévio, análise de riscos, gerenciamento de requisitos, previsão de custos, previsão de tempo, alguns dos problemas relatados com mais frequência nos projetos da organização foram:  Falta de conhecimento técnico.  Estimativas incorretas ou sem fundamento;  Falta de apoio da alta administração;
  51. 51. 50  Falta de competência para gerenciar projetos;  Falta de definição de responsabilidades;  Falta de uma ferramenta de apoio;  Falta de uma metodologia de apoio;  Mudanças de prioridade constantes;  Problemas com fornecedores;  Retrabalho em função da falta de qualidade do produto. Diante desse cenário a empresa Realize-se reconhece tal necessidade em atingir um alto nível de qualidade de produto do seu serviço, para que possa se fortalecer. Para a empresa alcançar o nível 2 gerenciado do nível de maturidade 2 no CMMI é necessário que ela esteja de acordo com as sete áreas de processos e nesse caso utilizando o Scrum como auxilio, sendo: 3.2.1 Requisitos Segundo (Leite) “Requisitos são objetivos estabelecidos por clientes e usuários juntamente com a equipe de desenvolvimento” [16]. Esses requisitos definem as propriedades que um software deve ter. Existem dois tipos de requisitos: funcionais e não-funcionais. Os requisitos funcionais descrevem as funções que o usuário final precisa ter para realizar suas tarefas. Os requisitos não-funcionais são qualidades que um software deve ter, como desempenho, usabilidade, manutenibilidade dentre outros. Durante a fase de levantamento de requisitos a organização avaliada não interage diretamente com o usuário final, por se tratar de uma empresa que disponibiliza serviços dentro do seu domínio na Internet com o objetivo de atrair clientes. É de suma importância que a empresa tenha cuidado ao incrementar e modificar requisitos já que são eles que basicamente atraem seus usuários.
  52. 52. 51 Os requisitos são levantados entre a equipe. Não existe uma gerência de requisitos gerando: retrabalho, desperdício de tempo com requisitos falhos e sem fundamentos entre outros mal-estares. Neste caso foram levantadas algumas falhas por parte da Realize-se, como:  Os requisitos não são analisados antes de serem implementados;  Os requisitos e suas mudanças não são documentados;  Algumas partes envolvidas não são contatadas quando mudanças são realizadas;  Não existem critérios para avaliar e aceitar os requisitos e mudanças;  Não são feitas reuniões para tratar de implementação de novos requisitos ou mudanças de alguns já existentes. Alguns elementos do Scrum podem ajudar a empresa a se organizar e manter um melhor gerenciamento de requisitos. O CMMI exige que se obtenha entendimento dos requisitos, comprometimento dos requisitos, gerencia de mudanças de requisitos, rastreabilidade de requisitos e que se identifique inconsistências entre produtos de trabalho, planos de projeto e requisitos. Analisando essas exigências e os elementos do Scrum traçamos a seguinte resolução para a empresa: 1. Eleger um Product Owner:  A empresa deve eleger uma fonte oficial para o fornecimento de requisitos para que esta defina os itens que irão compor o Product Backlog. 2. Apresentar a Sprint Backlog:  A Scrum Team deve tomar conhecimento dos itens do Product Backlog, revisá-los para que não haja mal entendimentos e aprová-los. Toda equipe deve se comprometer com os requisitos. 3. Realizar Daily Scrum.
  53. 53. 52  Nessas reuniões devem ser discutidas mudanças de requisitos ou inconsistências. O Scrum Master deve intermediar a reunião e gerar um documento de mudanças de requisitos, caso necessário, comentando sua motivação, mantendo a relação entre os requisitos originais e todos os requisitos de produto e de componentes de produto. Em caso de inconsistências ele deve também implementar ações corretivas. Fica a critério da empresa optar por uma ferramenta para ajudar na gerencia de requisitos. Caso a Realize-se deseje usar indicamos a OSRMT (Open Source Requirements Management Tool). É uma ferramenta CASE desenvolvida em Java por Aron Smith. Essa ferramenta de ajuda pode ser gratuitamente baixada no link: <http://sourceforge.net/projects/osrmt/files/>. 3.2.2 Planejamento Nesta seção trataremos do planejamento de projeto. Esta área trata do tempo, dos custos, do esforço, dos recursos entre outros envolvidos que serve para acompanhar o progresso da equipe durante todo o projeto. Identificamos vários problemas nessa fase. A empresa avaliada não possui uma estrutura de planejamento de projeto já definida. Diante dessa situação reorganizamos toda a parte de planejamento da empresa juntamente com os elementos Scrum. O projeto, segundo o Scrum, tem um ciclo de vida definido em 4 fases: Planejamento, Preparação e Escalonamento e Desenvolvimento e Entrega. O escopo e definido na fase de planejamento [8]. Para definir o escopo todas as partes interessadas fazem o papel de Product Owner. O Product Backlog fornece uma base para a elaboração de um plano de projeto. Para estimar o escopo do projeto é preciso estabelecer uma estrutura analítica de projeto (WBS) de alto nível. O WBS (work breakdown structure) deve identificar os
  54. 54. 53 riscos e suas tarefas de mitigação (eliminar riscos), tarefas relacionadas a entregáveis e a atividades de apoio, tarefas relacionadas à aquisição de conhecimento e competência, tarefas relacionadas a elaboração dos planos de suporte necessários e tarefas relacionadas a integração e a gestão de itens pré-desenvolvidos. A Estrutura Analítica ainda auxilia no cálculo do esforço do projeto em termos de tarefas e de papeis e responsabilidades da organização. Em Scrum, o Product Backlog e os Sprints que são pré-definidos podem ser considerados uma WBS, já que são esses que irão realizar as estimativas para o escopo do projeto Não existem orientações no Scrum para medir o tamanho e a complexidade dos produtos e atividades de um projeto. Entretanto, fugindo um pouco da metodologia ágil a Realize-se pode escolher métodos para determinar os atributos de produtos de trabalho e de tarefas que serão utilizados para estimar os requisitos de recursos. No caso da empresa avaliada, esse método pode ser linhas de código fonte. A Realize-se deve selecionar os dados que ela deseja para estimar o esforço e o custo, considerando necessidades da infraestrutura de suporte. A metodologia utilizada não possui recomendações para estimar custos, mas o Product Owner necessita destas informações para calcular o orçamento do projeto. Se necessário a empresa pode recorrer a uma ferramenta para ajudar a calcular os custos, como o software MS Project, um software para gerenciar projetos. O Scrum realiza as estimativas de esforço em 2 níveis:  Product Backlog: são pouco precisas, e tem a finalidade de gerar uma primeira visão para o Product Owner do esforço necessário para cada requisito;  Sprint Backlog: são precisas, e tem a finalidade auxiliar no controle e visibilidade do desenvolvimento das atividades.
  55. 55. 54 O orçamento e o cronograma do projeto são obtidos a partir do Product Backlog. Ele é dividido em Sprints alocando a equipe de acordo com a sua capacidade de produção. O cronograma é gerado nessa divisão. Este cronograma deve ser mantido atualizado a média que o projeto desenvolve. Não existem orientações definidas para se estabelecer o orçamento, entretanto o software citado acima, o MS Project, pode auxiliar tanto no estabelecimento do orçamento quanto na construção do cronograma. Segundo o CMMI devemos identificar os riscos do projeto. Utilizando o Scrum a empresa avaliada pode fazer isso durante uma Daily Scrum. Na reunião o Scrum Team pode levantar os riscos, documentá-los e corrigi-los. Caso novos riscos sejam identificados eles podem ser atualizados em uma nova Daily Scrum. Segundo a subprática na questão de planejar o gerenciamento de dados, somente quem é autorizado deve ter acesso aos dados do projeto, é necessário estabelecer um mecanismo para arquivamento dos dados e acesso a eles e determinar quais dados serão coletados. Não existe uma formalização no Scrum para a coleta de dados. Entretanto em uma Daily Scrum é possível comunicar entre o Scrum Team e também comunicar através de documentos. Para arquivar os dados, uma saída seria criar uma pasta e fornecer acesso ao pessoal autorizado. A alocação do time e a preparação da infraestrutura, segundo o Scrum, são realizadas no início do projeto. É importante determinar requisitos de processo para que a operação seja eficiente para a execução do projeto. A Realize-se deve também ter os requisitos para a composição da equipe, levando em conta as habilidades e conhecimento exigidos para cada função. Caso haja necessidade de mais recursos durante o projeto, o Scrum Master é responsável por prover o que falta.
  56. 56. 55 É importante que a equipe da empresa Realize-se tenhas habilidades e conhecimentos necessários para executar sua parte no projeto. Caso a equipe, ou um indivíduo da equipe não tenha a habilidade necessária para implementar o Spring Backlog está necessidade entra numa lista de impedimentos ou é incluída no Product Backlog. As práticas de Scrum garantem uma boa comunicação e colaboração entre as partes interessadas. O envolvimento dessas partes é monitorado pelo Scrum Master. Segundo o Scrum para iniciar um projeto o documento de visão de produto e o Product Backlog deve estar pronto. No documento de visão está descrito porque o projeto está sendo realizado e o esperado quando ele estiver finalizado. O Product Backlog define os requisitos funcionais e os não funcionais que o projeto deverá atender. No início de um Sprint, em uma Sprint Planning Meeting, e no final, em uma Sprint Review Meeting o Product Owner, o Scrum Master e o Scrum Team revisam os planos e os compromissos e se necessário são realizadas adaptações de acordo com as mudanças no projeto. Também durante o Sprint Planning Metting, as atividades a serem desenvolvidas são estimadas e o máximo de funcionalidades que poderá ser implementada no Sprint são definidas. Toda vez que um Sprint é iniciado há o comprometimento do plano. 3.2.3 Monitoramento e Controle Durante o andamento do projeto, é importante avaliar o andamento do projeto formalmente, com o intuito de ver a real condição em que o projeto se encontra até aquele determinado no momento. Na empresa Realize-se, o gerente de projetos necessita sempre estar informado sobre como está o andamento da equipe para
  57. 57. 56 averiguar se estará pronto no tempo estipulado. O grande problema é a comunicação falha, e a falta de monitoramento formal. Utilizando o Scrum a equipe pode monitorar o projeto nas Daily Scrum e usando o Release Burndown. Ao final de cada Sprint o time monitora seu progresso atualizando um Release Burndown Chart. Em reuniões diárias, o Scrum Master pode monitorar o esforço e o custo de sua equipe, analisando suas habilidades estão sendo suficientes para realizar suas tarefas. Na falta de recursos, o Scrum Master fica responsável por remover esses obstáculos. Os compromissos são estabelecidos a cada Sprint, na Sprint Planning Meeting. Eles são monitorados através do Release Burndown e são revistos na Sprint Retrospective. O Scrum busca monitorar qualquer risco do projeto nas Daily Scrum. Para se adequar ao CMMI, ao invés de registrar os riscos em um quadro-branco, deve-se criar um documento, registrando e atualizando esses impedimentos, assim como as ações corretivas realizadas. O Scrum não determina um procedimento para monitorar a gestão de dados, mas é possível acompanhar se os planos estão sendo cumpridos nas Daily Scrum. O Scrum Master é responsável por monitorar as partes interessadas mantendo-as informadas. Na Sprint Review, ao final de cada Sprint o progresso é avaliado, permitindo que seja possível visualizar o andamento e o cumprimento do combinado na Sprint Planning Meeting [8]. 3.2.4 Fornecedores A Realize-se não conta com contrato de fornecedores, ficando muitas vezes prejudicada por falta de equipamento para reposição, perda de tempo para adquirir novos equipamentos, falta de fornecedores e vários outros impedimentos.
  58. 58. 57 O Scrum não trata da aquisição de produtos. Entretanto o CMMI orienta as organizações a determinar que tipos de aquisição ela deseja, pode ser produtos de prateleira, produtos por contrato, produtos por fornecedor externo e etc. Após realizar essa escolha a empresa deve selecionar seus fornecedores, a partir de critério estabelecidos pela própria organização. Ao final disso a empresa deve estabelecer um contrato com os fornecedores selecionados. A empresa deve documentar o que o fornecedor vai cumprir e ao que eles terão acesso no projeto. A organização deve monitorar se o fornecedor contratado está executando as atividades conforme tratado no contrato e analisar se os processos escolhidos pelo contratado são críticos para o sucesso do processo. 3.2.5 Medição e Análise A empresa Realize-se desconhece essa área de processo Medição e Análise do CMMI. Essa área fornece capacidade de medição para dar suporte ás necessidades de informação apoiando os negócios, a organização e o projeto. Nos itens anteriores, requisitos e planejamento, são utilizadas medições para satisfazer a área de processo. No Scrum, os objetivos de medição podem ser documentados no Daily Scrum, pelo Scrum Master, a fim de melhorar o projeto. Os objetivos podem ser: reduzir o tempo de entrega, melhorar níveis de qualidade, melhorar índices de satisfação do cliente entre outros. Após os objetivos serem definidos devem-se especificar as medidas para satisfazê-los. Estas podem ser medidas-base ou medidas-derivadas. Medições diretas dão origem aos dados para as medidas-bases, já os dados das medidas-derivadas são obtidos provenientes de outros dados. As medidas devem ser revisadas por toda a equipe e atualizadas se necessário pois o principal objetivo da medição de software é
  59. 59. 58 permitir aos envolvidos conhecer o processo e melhorá-lo de forma contínua. Como um dos princípios do Scrum são transparência, inspeção e adaptação, não há forma melhor de deixarmos transparente a qualidade, efetividade e eficiência do processo de desenvolvimento Scrum utilizado pela equipe que não seja utilizando números. No Scrum há algumas métricas que são usadas constantemente como: velocidade média da equipe, estimativa da história, tamanho da Sprint, número de pontos aprovados em uma Sprint, etc. No Scrum não há gerentes de projetos que tenha a responsabilidade de decidir como será feito à medição do software. O certo seria que o grupo se conscientize o qão importante é medição, para que desse modo seja aperfeiçoado o processo no Scrum. Métricas devem somente ser escolhidas se necessária afim de responder perguntas específicas que tenha a melhoria do processo como objetivo no Scrum. Sem essa medição não é possível saber se algum aspecto do processo trabalhado possui algum potencial para ser melhorado e quais ações serão utilizadas para o aperfeiçoamento e correção. Causando problemas, pois à medida que falhas mais sérias aparecem, o grupo fica mais frustrado percebendo que suas correções não tiveram efeito. Mais outro problema relacionado a medição é o “medir por medir” que acontece ao saber que medir é importante, mas são feitas sem planejamento ou com nenhum objetivo claro. Para resolver o problema, foi criado o GQM. Método simples para planejar medições de maneira que sejam baseadas em objetivos específicos de medição. Como uma das responsabilidades do Scrum Master é zelar pelo processo, a medição deve ser um aliado importante do tralhado. Fazer análise dos pontos negativos e positivos levantados nas retrospectivas (principalmente os recorrentes) identificando falhos no processo.
  60. 60. 59 Assim, é possível aplicar o GQM no planejamento de processo e medição, isto ocorre definindo:  O objetivo da medição (GOAL). Ex: Melhorar a eficiência dos testes automatizados.  A questão a ser respondida (QUESTION). Ex: Qual a eficiência dos testes automatizados?  As métricas que respondem a questão respondida (METRIC). Ex: Intervalo entre falhas, Número de bugs encontrados em homologação etc. 3.2.6 Garantia de Qualidade de Processo e Produto A qualidade tem como objetivo o processo, aonde tem um tratamento contínuo para que produza resultados “o mais rápido possível” tentando “fazer o certo da primeira vez”. Com propósito de fornecer à equipe e à gerência uma visão objetiva dos processos e produtos de trabalho. Os processos devem fornecem o necessário para a implantação de um programa de qualidade que tenha a aderência dos processos e produtos de trabalho aos padrões, procedimentos e modelos. Afim de assegurar a qualidade, reduzir custos e esforço com retrabalho, minimizar os problemas nas atividades de testes e garantir a satisfação do cliente com o produto final. A Realize-se não conta com um grupo de Gerência da Qualidade de Produto (GQA), que tem a função de guiar um conjunto de atividades para a avaliação de processos de modo que esteja em conformidade com os requisitos especificados. Tendo como responsabilidade: Garantir que o "fluxo de trabalho" esteja sendo conduzido conforme o processo e gerando produtos de trabalho que possuem "sinais externos" conforme esperados pela documentação das auditorias. Por sua vez, o processo deve
  61. 61. 60 buscar atributos que evidenciem, em uma auditoria, sinais de integridade e qualidade perceptíveis por um auditor leigo na tecnologia.  Ações sobre Não Conformidades: Ao detectar uma não conformidade de processo ou produto, entra em ação um conjunto de padrões devem ser planejadas e realizadas.  Registro de Pendência: Toda não conformidade detectada durante a auditoria se torna uma pendencia, aonde há um responsável por ela. Este responsável poderá ser alguém do Scrum Team, do PO Team, algum Product Owner ou, em último caso, a Diretoria.  Fechamento da Pendência: A finalização do processo de auditoria somente ocorre quando uma eventual pendência foi fechada, o que pode ser realizado através de uma descrição da solução pelo responsável. As auditorias são classificadas em (Baixa, Média e Alta) com complexidade (Baixa, Média e Alta), que se diz respeito à probabilidade do impacto na detecção de não-conformidades e no esforço e dificuldade na solução do mesmo, respectivamente. Essa classificação considera a média da classificação dos itens da lista de verificação da auditoria e tem por objetivo pré-determinar o tempo máximo para a resolução das não-conformidades encontradas pelo responsável imediato, antes que as mesmas sejam escalonadas ao superior imediato. Com o prazo máximo em dias para a resolução das não-conformidades:
  62. 62. 61 Tabela 3 - Relação entre Criticidade e Complexidade. Os prazos são válidos para itens de auditoria de Pregame, Pre-Sprint, Post- Sprint, Post-Game e itens de auditorias de Sprint a serem resolvidos dentro da sprint onde foram relatados. As práticas de verificação envolvem uma análise técnica dos produtos e subprodutos produzidos pelo processo, para garantir que estejam feitos conforme o esperado (do jeito certo), em conformidade com atributos "internamente verificáveis". 3.2.7 Gestão de Configuração Essa área de processo é importante caso haja mudanças. Podem acontecer mudanças de requisitos, de ambiente, entre outros. A gestão de configuração descreve atividades para que essas modificações sejam feitas de maneira controlada, não comprometendo a estabilidade do projeto. A empresa Realize-se, pode colocar sob gestão de configuração os requisitos, os códigos, os dados de design e outros de sua preferência. Para estabelecer as baselines, linha de base do projeto, pode-se ter por base o Backlog do produto, que contém as funcionalidades desejadas para ele. Com o Backlog deve-se selecionar os itens de configuração. A empresa vai precisar de um sistema de gestão de configuração para controlar os produtos de trabalho, existem ferramentas open source, software de utilização livre. Alguns exemplos dessas ferramentas são
  63. 63. 62 Subversion, CVS, Trac, Scon, Bitten e várias outras. Existem dois tipos de baselines, são elas:  Baseline interna: itens de configuração técnicos e gerenciais;  Baseline externa: itens de configuração finalizados. Após a criação da baseline o Scrum Master vai analisar, em uma Sprint Planning Meeting, as solicitações de alteração solicitadas e criar uma Sprint Backlog para executar em um Sprint essas alterações. O Scrum Master deve manter um documento com todas as diferenças entre as baselines e confirma se os itens de configuração estão completos.
  64. 64. 63 Considerações finais O presente trabalho faz uma abordagem sobre o cenário atual das pequenas e médias empresas de tecnologia, aonde cada vez mais organizações reconhecem a necessidade em atingir um alto nível de qualidade de produto ou serviço. Os clientes atuais se tornam cada vez mais exigentes em qualidade, no qual as organizações se preocupam em gestão de processos e à empregar modelos de processos. Segundo Pfleeger (2004) a falta de qualidade de software pode custar caro: Quanto mais tempo um defeito permanece sem ser detectado, mais cara será sua correção. Estima-se que o custo para correção de um erro cometido em um projeto durante a etapa inicial da análise seja um décimo do custo para corrigir um erro semelhante depois que o sistema já foi entregue ao cliente [17]. Diante disso, são vários os benefícios alcançados decorrentes da avaliação de produtos de software:  O produtor poderá assegurar a qualidade do produto final;  Redução nos custos com a manutenção do software;  Satisfação do usuário final;  O vendedor poderá usar como argumento de venda a qualidade assegurada do produto que está vendendo;  Organizações poderão exigir critérios de qualificação com propósitos específicos;  Diminuição do esforço com retrabalhos;  Minimizar problemas nas atividades.
  65. 65. 64 De acordo com o CMMI Institute, “a IBM da Austrália na área de Serviços de gerenciamento de aplicativos fechou 95% dos problemas dentro do prazo especificado pelo cliente” [5]. Desse modo, a empresa analisada neste trabalho certamente encaixa-se neste cenário, logo a Realize-se adquire maturidade como organização tendo uma infraestrutura planejada com objetivos específicos de satisfação ao cliente e qualidade de produto a ser entregue graças a implantação do nível de maturidade 2 - Gerenciado do CMMI. Desta forma, presentes a proposta, a Empresa Realize-se poderá então tomar a melhor decisão para aprimorar seus processos e a qualidade de seus produtos, optando pelos processos de desenvolvimento e qualidade no processo de desenvolvimento de software mais adequado às suas necessidades. Como possíveis trabalhos futuros, pode- se apontar que a empresa alcance os próximos níveis de maturidade do CMMI.
  66. 66. 65 Referências [1] OLIVEIRA, F. B. Tecnologia da informação e da comunicação: desafios e propostas estratégicas para o desenvolvimento. São Paulo: Pearson Prentice Hall; Fundação Getúlio Vargas, 2006. [2] FÁCIL INFORMÁTICA. O que é MPS.BR. Disponível em: http://www.facilinformatica.com.br/Geral/Noticias.aspx/597. Acesso em: 31 de maio. 2014. [3] CMUSEI, Carnegie Mellon University, Software Engineering Institute. CMMI® for Development, Version 1.2. Pensilvania: Carnegie Mellon University, 2006. 20p. [4] WIKIPÉDIA A enciclopédia livre. Rugby. Disponível em: http://pt.wikipedia.org/wiki/Rugby. Acesso em: 31 de maio. 2014. [5] CMMI INSTITUTE. Benefíts of CMMI. Disponível em: http://cmmiinstitute.com/results/benefits-of-cmmi/. Acesso em: 31 de maio. 2014. [6] TANAKA S. S. Análise de sistemas I: São Paulo: Pearson Education, 2009.43 p. [7] PERINI L. S. Engenharia de software São Paulo: Pearson Education, 2009.82 p. [8] Desenvolvimento Ágil. Scrum. Disponível em: http://desenvolvimentoagil.com.br/scrum/ . Acesso em: 31 de maio. 2014. [9] CMMI Institute. Models. Disponível em: http://cmmiinstitute.com/cmmi-solutions/. Acesso em: 31 de maio. 2014. [10] SELECT Business Soluctions. What is the Capability Maturity Model? Disponível em: http://www.selectbs.com/process-maturity/what-is-the-capability- maturity-model. Acesso em: 31 de maio. 2014. [11] GROFFE, J. Maturidade no desenvolvimento de software: CMMI e MPS-BR. Sistemas de Informação. Universidade de Sorocaba, São Paulo, jan./ 2013. Disponível em <http://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi- e-mps-br/27010>. Acesso em: 01 jum. 2014. [12] LIMA, R. C. Capability Maturity Model Integration – CMMI para Desenvolvimento, Versão 1.2 Ago/2013. Disponível em <http://www.supergestor.com/qualidade/material4.pdf>. Acesso em: 01 jun. 2014.
  67. 67. 66 [13] ALMEIDA, Alessandro, Conhecendo o CMMI. In: WORKSHOP QUALITY PROCCESS, Workshop.ConhecendoCMMI-2oEdicao-DIS. 2005, São Paulo. 151 p. [14] KULPA, M.K., JOHNSON, K. A. Interpreting the CMMI®: A process Improvement Approach. 2nd. ed. Florida: Auerbach, 2008. 404p. [15] Realize-se. O site do seucasamento. Disponível em <http://www.realize- se.com.br/ .> Acesso em: 01 jun. 2014. [16] LEITE, J. C., Análise e Especificação de Requisitos. Disponível em <http://www2.dem.inpe.br/ijar/EngSofAnalEspc.html> Acesso em: 01 jun. 2014. [17] PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2º. ed. São Paulo: Pearson Prentice Hall, 2004. p. 6-7.

×