UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
LUCAS DE ALMEIDA CRUZ
LUIZ PHILIPPE MORO DE CARMO
ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM
DESENVOLVIMENTO DE SOFTWARE
TRABALHO DE CONCLUSÃO DE CURSO
CURITIBA 2016
LUCAS DE ALMEIDA CRUZ
LUIZ PHILIPPE MORO DE CARMO
ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM
DESENVOLVIMENTO DE SOFTWARE
Trabalho de Conclusão do Curso de Bacharelado em Sistemas de Informação, apresentado à UTFPR como requisito parcial para obtenção do título de bacharel em Sistemas de Informação.
Orientador: Robson Ribeiro Linhares
CURITIBA
2016
RESUMO
Cruz, L., e Moro, L. ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM DESENVOLVIMENTO DE SOFTWARE. 2016. Monografia – Trabalho de conclusão de curso de Bacharelado em sistemas de informação, Universidade tecnológica federal do Paraná. Curitiba, 2016.
Este trabalho apresenta a análise do grau de maturidade de desenvolvimento de software realizada em um departamento de uma universidade federal, utilizando os princípios do CMMI. Apresenta-se conceitos de desenvolvimento de software e gerencia de projetos. Discute-se os conceitos do CMMI e Discute-seus enfoques, bem como sua relação com os processos de desenvolvimento. Complementado por uma pesquisa realizada com os membros do departamento estudado e análises dos documentos do processo atual, o estudo verificou as falhas de maturidade que existem dentro do modelo de desenvolvimento atual.
Apresenta-se como resultado um plano desenvolvido posterior a análise com objetivo de melhoria dos processos de desenvolvimento internos, buscando atingir o nível 2 de maturidade de acordo com o CMMI, bem como um website desenvolvido para a divulgação deste plano.
Palavras-chave: CMMI. Modelagem de sistemas. Maturidade em desenvolvimento de software. Modelagem de processos. Gerência de projetos.
ABSTRACT
Cruz, L., e Moro, L. ANÁLISE E APLICAÇÃO DE PRÁTICAS DO CMMI EM DESENVOLVIMENTO DE SOFTWARE. 2016. Monografia – Trabalho de conclusão de curso de Bacharelado em sistemas de informação, Universidade tecnológica federal do Paraná. Curitiba, 2016.
This Project presents an analysis of the maturity levels in the software development process of a department inside a federal university, using the principles of CMMI. The concepts of software development and project management are presented. The CMMI model and its focus are also discussed, as well as its relationship with the development processes.
Complemented for a research performed with the members of the studied department, and an analysis of the process documents, the study found flaws inside the current development model.
As result it presents an improvement plan, developed after the analysis, which aims to help the department to reach maturity level 2 in CMMI, as well as a website developed to publish this plan.
Keywords: CMMI. Systems modeling. Maturity in software development. Process modeling. Project management.
LISTA DE FIGURAS
Figura 1 - Modelo Cascata... 21
Figura 2 - Modelo incremental ... 22
Figura 3 - Modelo de prototipação ... 23
Figura 4 - Modelo de espiral de desenvolvimento ... 24
Figura 5 - Comparação dos custos das mudanças em diferentes ambientes de desenvolvimento ... 25
Figura 6 - Fluxo do processo Scrum ... 27
Figura 7 - As três dimensões críticas ... 29
Figura 8 - Áreas de Processo na representação por Estágio ... 31
Figura 9 - Áreas de Processo na representação Contínua ... 31
Figura 10 - Componentes do modelo CMMI ... 32
Figura 11 - Processo de Negócio do Sistema de Gerenciamento de Frota ... 51
Figura 12 - Fluxo de Atividades ... 52
Figura 13 - Comparativo das taxas de Aderência ... 57
Figura 14 - Aderência de REQM ... 58
Figura 15 - Aderência PP ... 59
Figura 16 - Aderência PMC... 59
Figura 17 - Aderência SAM... 60
Figura 18 - Aderência MA ... 61
Figura 20 - Aderência CM ... 62
Figura 21 - Processo Local de desenvolvimento(PLD) ... 64
Figura 22 - Títulos de reponsabilidade ... 68
Figura 23 - Relação de REQM com as outras áreas de processo ... 69
Figura 24 - Workflow de REQM ... 70
Figura 25 - Relação de PP com as outras áreas de processo... 70
Figura 26 - Workflow PP ... 71
Figura 27 - Relação de PMC com as outras áreas de processo ... 72
Figura 28 - Workflow PMC ... 73
Figura 29 - Relação de SAM com as outras áreas de processo ... 74
Figura 30 - Worflow de SAM... 75
Figura 31 - Relação de MA com as outras áreas de processo ... 76
Figura 32 - Workflow de MA ... 77
Figura 33 - Relação de PPQA com as outras áreas de processo ... 77
Figura 34 - Workflow de PPQA ... 78
Figura 35 - Relação de CM com as outras áreas de processo ... 79
Figura 36 - Workflow de CM ... 79
Figura 37 - Tela Inicial do Site ... 82
Figura 38 - Tela de apresentação do Processo Local ... 83
LISTA DE TABELAS
Tabela 1 - Metas Genéricas e Nomes de Processos ... 33
Tabela 2 - Critérios SCAMPI x Pesquisa ... 55
Tabela 3- REQM01 ... 69 Tabela 3- REQM01 ... 99 Tabela 4 - REQM02 ... 99 Tabela 5 - REQM03 ... 99 Tabela 6 - REQM01 ... 99 Tabela 7 - REQM05 ... 100 Tabela 8 - PP01 ... 100 Tabela 9 - PP02 ... 100 Tabela 10 - PP03 ... 100 Tabela 11 - PP04 ... 101 Tabela 12 - PP05 ... 101 Tabela 13 - PP06 ... 101 Tabela 14 - PP07 ... 101 Tabela 15 - PP08 ... 102 Tabela 16 - PP09 ... 102 Tabela 17 - PP10 ... 102 Tabela 18 - PP11 ... 102 Tabela 19 - PP12 ... 102 Tabela 20 - PP13 ... 103
Tabela 21 - PP14 ... 103 Tabela 22 - PMC01 ... 103 Tabela 23 - PMC02 ... 103 Tabela 24 - PMC03 ... 104 Tabela 25 - PMC04 ... 104 Tabela 26 - PMC05 ... 104 Tabela 27 - PMC06 ... 104 Tabela 28 - PMC07 ... 104 Tabela 29 - PMC08 ... 105 Tabela 30 - PMC09 ... 105 Tabela 31 - PMC10 ... 105 Tabela 32 - SAM01 ... 105 Tabela 33 - SAM02 ... 106 Tabela 34 - SAM03 ... 106 Tabela 35 - SAM04 ... 106 Tabela 36 - SAM05 ... 107 Tabela 37 - SAM06 ... 107 Tabela 38 - SAM07 ... 107 Tabela 39 - SAM08 ... 107 Tabela 40 - MA01 ... 108 Tabela 41 - MA02 ... 108 Tabela 42 - MA03 ... 108 Tabela 43 - MA04 ... 108
Tabela 44 - MA05 ... 108 Tabela 45 - MA06 ... 109 Tabela 46 - MA07 ... 109 Tabela 47 - MA08 ... 109 Tabela 48 - PPQA01 ... 109 Tabela 49 - PPQA02 ... 110 Tabela 50 - PPQA03 ... 110 Tabela 51 - PPQA04 ... 110 Tabela 52 - CM01 ... 111 Tabela 53 - CM02 ... 111 Tabela 54 - CM03 ... 111 Tabela 55 - CM04 ... 111 Tabela 56 - CM05 ... 112 Tabela 57 - CM06 ... 112 Tabela 58 - CM07 ... 112
LISTA DE SIGLAS
CMMI Capability Maturity Model® Integration
SEI Software Engineering Institute
RUP Rational Unified Process REQM Gerenciamento de Requisitos PP Planejamento de Projeto
PMC Monitoramento e Controle de Projeto SAM Gestão de Acordos com Fornecedores MA Medição e Análise
PPQA Garantia da Qualidade de Processo e Produto CM Gerenciamento de Configuração
AI Amplamente Implementada PI Parcialmente Implementada NI Não Implementada
LISTA DE SÍMBOLOS
∑ Somatório
n Número de respostas
ai Resposta amplamente implementada pi Resposta parcialmente implementada
SUMÁRIO
1 INTRODUÇÃO ... 15 1.1 Objetivo Geral ... 15 1.2 Objetivos Específicos ... 15 1.3 Justificativa ... 16 1.4 Método de Pesquisa ... 16 1.5 Organização do Trabalho ... 17 2 REFERENCIAL TEÓRICO ... 19 2.1 Processos de Software ... 19 2.2 Modelos de Processo ... 20 2.2.1 Modelo Cascata ... 202.2.2 Modelo de Processo Incremental ... 21
2.2.3 Modelo de Processo Evolucionário ... 22
2.3 Desenvolvimento Ágil ... 24 2.3.1 O Processo Ágil ... 25 2.3.2 Os Princípios da Agilidade ... 26 2.3.3 Scrum ... 26 2.4 CMMI ... 27 2.4.1 Tipo de Representação... 30
2.4.2 Componentes das Áreas de Processo ... 31
2.4.3 Metas e Práticas ... 33
2.4.5 As Áreas de Processo do Nível 2 de Maturidade ... 35
2.4.6 Planos em Melhoria de Processo ... 41
2.5 Métodos de Avaliação e Diagnóstico ... 41
2.5.1 SCAMPI ... 42
2.5.1 PIID ... 44
2.6 Estudos de Casos Relacionados em CMMI ... 44
2.7 Norma ISO/IEC 15504 ... 45
2.8 Considerações Finais ... 46
3 ANÁLISE DE MATURIDADE ... 48
3.1 Contexto ... 48
3.2 Método de Análise da Maturidade ... 52
3.3 Diagnóstico ... 52
3.4 Análise ... 55
3.5 Conclusões da Análise ... 63
4 PROPOSTA DE PROCESSO LOCAL DE DESENVOLVIMENTO ... 64
4.1 Etapas de Desenvolvimento ... 64
4.2 Detalhamento das Áreas de Processo ... 68
4.2.1 REQM ... 69
4.2.2 PP ... 70
4.2.3 PMC ... 72
4.2.4 SAM ... 74
4.2.6 PPQA ... 77 4.2.7 CM ... 79 4.3 Site de Divulgação ... 80 4.3.1 Aspectos Técnicos ... 80 4.3.2 Desenvolvimento ... 81 5 CONCLUSÃO ... 85 5.1 Objetivos Alcançados ... 85 5.2 Desafios ... 85
5.3 Conclusões sobre a Pesquisa ... 86
5.4 Trabalhos Futuros ... 86
REFERÊNCIAS ... 88
APÊNDICE A ... 91
1 INTRODUÇÃO
O desenvolvimento de software é a base na pirâmide para a evolução tecnológica na área da computação. Existem inúmeras etapas pelas quais um software passa desde a sua idealização até sua produção e posteriormente sua aplicação e suporte. O principal foco da Engenharia de Software é organizar todo esse processo conhecido como ciclo de vida de um software, que pode vir a ser extremamente complexo e problemático dependendo do nível de maturidade da organização. (CMMI-DEV, 2006).
Uma das maneiras para saber a situação de maturidade do desenvolvimento de software em uma organização é pelo Capability Maturity Model Integration (CMMI), que é homologado pela Software Engineering Institute. (CMMI-DEV, 2006).
1.1 Objetivo Geral
O principal objetivo deste trabalho de conclusão de curso é a análise das metodologias aplicadas no desenvolvimento de software dentro da Universidade Tecnológica Federal do Paraná (UTFPR) para descobrir em qual nível de maturidade a organização se encontra de acordo com o CMMI e propor a aplicação de práticas que visem a melhorar este nível de maturidade.
1.2 Objetivos Específicos
Os objetivos específicos são:
Análise das metodologias no desenvolvimento de software aplicadas atualmente na UTFPR por meio de um caso de estudo
Criação de uma proposta de modelo de desenvolvimento de software baseado em CMMI para aplicação interna da UTFPR
Divulgação deste modelo local por meio de um website de consulta de conteúdo para divulgar os processos a serem seguidos no desenvolvimento de software.
1.3 Justificativa
Um dos grandes desafios encontrados na produção de software é o gerenciamento da informação. Hoje em dia a tradicional divisão entre engenharia de software e o gerenciamento da informação nele contida vem diminuindo, e em grandes empresas o gerenciamento da informação já é moldado pela estrutura de processos usada na mesma.
Muitas empresas aplicam as práticas propostas pelo CMMI buscando uma maior maturidade no desenvolvimento de software, isso aperfeiçoa seus processos internos, o que consequentemente reduz os custos e aumenta sua produção. Ao se aplicar essas mesmas práticas na UTFPR é esperado um aumento da qualidade dos softwares produzidos caso ela venha a adotar um modelo estratégico eficiente. Outro fator muito importante é que como se trata de uma Universidade pública que muitas vezes tem recursos bem limitados, a redução do custo de desenvolvimento pode criar um melhor aproveitamento das verbas disponíveis para os projetos em questão.
1.4 Método de Pesquisa
O primeiro passo da pesquisa foi encontrar um departamento de desenvolvimento de software com projetos em andamento que pudéssemos avaliar. Foi encontrado um Departamento da Universidade (DU) que era responsável pelo desenvolvimento de software na UTFPR.
Foi entrado em contato com o diretor do departamento que em uma primeira instância se mostrou bastante entusiasmado com a ideia e nos forneceu a documentação do projeto que estava em desenvolvimento. A
partir daí deu se início a pesquisa do referencial teórico, avaliando quais seriam os melhores métodos a serem utilizados para analisar a situação atual do processo de desenvolvimento utilizado pelo DU e qual seu nível de maturidade.
Após um período de estudo do CMMI e de seus processos de análise, foi decidido que a melhor maneira de realizar a análise do nível de maturidade atual do departamento seria por meio de uma adaptação do Practical Implementation Indicator Document (PIID). Com isso foi criado um questionário (Apêndice A) que foi respondido pelos membros do time de desenvolvimento e que juntamente com a análise da documentação do projeto, nos permitiram avaliar as deficiências no processo do departamento estudado.
A partir do resultado dessa análise, foi construído um plano de melhoria que foi baseado nos planos e metas e no GAP analisys do CMMI, onde são listadas todas as ações que são necessárias para se atingir o nível 2 de maturidade do CMMI, em seguida as ações foram organizadas por áreas de processo e adaptadas para a realidade do departamento, customizando-as de modo a gerar uma proposta de melhoria simples e organizada que pudesse de fato ser seguida e implementada.
Por fim, com o intuito de disponibilizar a proposta do plano de melhoria, foi criado um website que pudesse ser facilmente acessado e visto por todos os membros e gestores do time de desenvolvimento do DU.
1.5 Organização do Trabalho
Este trabalho está dividido em 5 capítulos. Este primeiro capitulo de introdução situa o contexto deste trabalho e descreve os principais objetivos a serem alcançados.
No segundo capitulo é apresentado o referencial teórico do modelo CMMI bem como o de outros processos de desenvolvimento de software.
No Terceiro Capitulo é dissertado sobre o processo de análise que foi realizado durante este trabalho, e explicado sobre a metodologia utilizada e são apresentados os resultados que foram obtidos.
No quarto capitulo é apresentada a proposta de melhoria criada com base na análise realizada.
No quinto e último capitulo são relatadas as conclusões obtidas no trabalho e sugestões para trabalhos futuros.
2 REFERENCIAL TEÓRICO
Neste capitulo é apresentado o referencial teórico dos principais modelos de processo de software e do modelo de maturidade escolhido para a análise de CMMI.
2.1 Processos de Software
Uma das melhores definições do que é um processo de software foi apresentada por um economista chamado Howard Baetjer, que diz o seguinte:
“Pelo fato de software, como todo capital, ser conhecimento incorporado, e pelo fato de esse conhecimento ser, inicialmente, disperso, tácito, latente e em considerável medida, incompleto, o desenvolvimento de software é um processo de aprendizado social.” (Baetjer, 1998)
A metodologia para as atividades, ações e tarefas no desenvolvimento de software poderiam ser traduzidas como “processo de software”. Este processo segue uma metodologia genérica de engenharia de software que pode ser apresentada em cinco atividades: comunicação, planejamento, modelagem, construção e emprego (Pressman, 2010).
A primeira atividade é a comunicação que compreende o momento anterior ao início da parte técnica no desenvolvimento do software. Sua principal função é o levantamento dos requisitos do sistema que irão definir as características e funções do software. Nesta etapa do processo é de extrema importância a comunicação entre os stakeholders, neste caso o cliente e o grupo de desenvolvimento.
A segunda atividade é o planejamento que tem como objetivo a criação de um plano de projeto de software, que deve descrever as tarefas técnicas a serem conduzidas, quais são os riscos possíveis, quais recursos serão utilizados, o que será produzido e um cronograma do projeto.
A terceira atividade é a modelagem que tem como finalidade desenvolver um “esboço” da solução, para que se tenha uma ideia de tudo que o software precisa. Caso seja necessário compreender melhor o problema e como resolvê-lo, deve-se refinar o tal “esboço” para que possa atender as necessidades do projeto.
A quarta atividade é a construção que é caracterizada por ser mais técnica, onde é gerado o código do software (manual ou automatizada) e são realizados os testes de software para que estejam atendendo os requisitos.
A última atividade é o emprego que é conhecida muitas vezes como entrega ou integração, no qual o cliente recebe o software e faz uma avaliação e fornece um feedback.
2.2 Modelos de Processo
A seguir são apresentados os modelos de processo de software mais relevantes no escopo deste trabalho
2.2.1 Modelo Cascata
Muitas vezes conhecido como ciclo de vida clássico no desenvolvimento de software, o modelo cascata tem uma abordagem sequencial e sistemática do processo de desenvolvimento de software. Começando desde o levantamento de requisitos pelo cliente, avançando para o planejamento, modelagem, construção, até a entrega e suporte continuo do software (Pressman, 2010). O modelo cascata é considerado o paradigma mais antigo dentro da engenharia de software, que pode ser visualizado na Figura 1.
Figura 1 - Modelo Cascata Fonte: Pressman (2010)
Ao longo do tempo alguns problemas foram encontrados (Hanna, 1995). O primeiro problema encontrado foi que muitas vezes os projetos reais dificilmente seguem um fluxo sequencial que é proposto no modelo, e as mudanças que podem ocorrer num projeto real atrapalha esse fluxo sequencial. Outro problema é a dificuldade do cliente de explicitar logo de início todos os requisitos que o sistema deve conter, com isso a dificuldade de se adequar as mudanças que o cliente deseja. E por fim, uma versão operacional do sistema só estará pronta nas etapas finais do projeto, podendo assim o resultado ser desastroso se não atender as expectativas do cliente.
2.2.2 Modelo de Processo Incremental
Da combinação de elementos sequenciais e paralelos surgiu o modelo incremental, que aplica essas sequencias lineares de uma maneira escalonada conforme o decorrer do tempo o projeto (Figura 2). Os incrementos, que para esse modelo seriam os artefatos entregáveis do software, são gerados por cada sequência linear (McDermid e Rook, 1993).
Figura 2 - Modelo incremental Fonte: Pressman (2010)
Um bom exemplo de uso do modelo incremental seria o desenvolvimento de um processador de texto, que primeiramente liberaria as funções básicas de gerenciamento de arquivos, edição e produção de documentos num primeiro incremento. E num segundo incremento poderia apresentar funções adicionais como revisão ortográfica e gramatical (Pressman, 2010). Por isso é comum o primeiro incremento ser conhecido como o produto essencial, que atende aos requisitos básicos para o sistema operar. Além disso, este modelo tem como objetivo ter um produto operacional entregue em cada um dos seus incrementos. Quando comparado ao modelo anterior (cascata) que só teria a possibilidade de ter o produto em operação nas partes finais do processo, este modelo resolve o problema de alinhamento com as necessidades do cliente antes que seja tarde demais.
2.2.3 Modelo de Processo Evolucionário
Os sistemas estão em constante evolução e o software não foge a essa regra. O modelo evolucionário tenta estar preparado para as inúmeras possibilidades de evolução que o processo de desenvolvimento de software
pode ter. Por isso mesmo, que este modelo é iterativo e apresenta características que possibilite o desenvolvimento de versões cada vez mais completas de software. Existem dois modelos que surgiram a partir do processo evolucionário: prototipação e espiral (Pressman, 2010).
O primeiro modelo, de prototipação, é muitas vezes usado quando o cliente não tem definido quais são as funcionalidades para o sistema, mas sabe quais são seus objetivos gerais. Em outro momento, podem ser os desenvolvedores que não sabem ao certo como vai ocorrer a interação do homem com o software. Este modelo (Figura 3) tem início com a Comunicação, como nos modelos anteriores, mas a partir daí o processo muda completamente com relação aos anteriores. A partir do processo de comunicação se inicia o projeto rápido que tem como finalidade o início da construção do protótipo que deve ser realizado por meio dos processos seguintes. De maneira geral a ideia é que esses protótipos tenham uma opinião do cliente para que o software sofra o processo evolucionário e que a cada ciclo se transforme até o ponto de ser um sistema real. Toda a parte de prototipagem está mais voltada à parte de interação do cliente com o software.
Figura 3 - Modelo de prototipação Fonte: Pressman (2010)
O segundo modelo, o espiral (Figura 4), foi proposto por Barry Boehm que descreve esse modelo da seguinte forma: “O modelo espiral de desenvolvimento é um gerador de modelo de processos dirigidos a riscos e é utilizado para guiar a engenharia de sistemas intensivos de software, que ocorre de forma concorrente e em múltiplos envolvidos.” (Boehm, 2001). De maneira geral, quando se utiliza o modelo espiral se tem uma combinação das iterações da prototipação com os aspectos sistemáticos do modelo cascata, para que seja iterativo e ao mesmo tempo seja bem controlado. De maneira resumida cada um dos passos como o de comunicação, planejamento, modelagem, construção, emprego, são muito próximos daqueles explicados anteriormente, mas com a diferença que ao longo do ciclo de vida ele é realizado novamente várias vezes. Dessa maneira se tornando um processo evolutivo de desenvolvimento de software, se baseando no que havia sido realizado anteriormente.
Figura 4 - Modelo de espiral de desenvolvimento Fonte: Pressman (2010)
2.3 Desenvolvimento Ágil
Antes de buscar entender o que é o desenvolvimento Ágil deve-se buscar entender o que seria o termo agilidade na engenharia de software. Para explicar melhor este termo, Ivar Jacobson coloca a agilidade como sendo a palavra em comum nos dias atuais para descrever um moderno processo de software. Além disso, para ele o principal condutor para a agilidade é a inserção da mudança no decorrer do desenvolvimento
(Jacobson, 2002). A partir desse ponto pode se fazer uma comparação dos custos das mudanças em ambiente de desenvolvimento ágil que está preparado para a mudança com um clássico que não está (Figura 5).
Figura 5 - Comparação dos custos das mudanças em diferentes ambientes de desenvolvimento
Fonte: Pressman (2010)
2.3.1 O Processo Ágil
A partir de um melhor entendimento do que seria a agilidade dentro da engenharia de software já é possível entender um pouco o que seria esse processo ágil. Os projetos de software que utilizam esse processo são caracterizados pela maneira que interagem com uma série de processos chaves que são (Fowler, 2002):
A dificuldade de definir antecipadamente os requisitos do software que irão persistir ou serão alterados;
Indefinição com relação à quantidade de trabalho do projeto que será necessário antes da construção, para avaliar o projeto;
As partes de análise, projeto, construção e testes não são muito previsíveis, com relação ao planejamento.
2.3.2 Os Princípios da Agilidade
Para quem deseja ter agilidade a Aliança de Agilidade (Agile Alliance, 2003) estabelece os 12 princípios a seguir:
Garantir a satisfação do consumidor entregando rapidamente e continuamente software funcionais;
Software funcionais são entregues frequentemente (semanas, ao invés de meses);
Software funcionais são a principal medida de progresso do projeto; Até mesmo mudanças tardias de escopo no projeto são bem-vindas. Cooperação constante entre pessoas que entendem do “negócio” e
desenvolvedores;
Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
Design do software deve prezar pela excelência técnica; Simplicidade;
Rápida adaptação às mudanças;
Indivíduos e interações mais do que processos e ferramentas;
Software funcional mais do que documentação extensa;
Colaboração com clientes mais do que negociação de contratos; Responder a mudanças mais do que seguir um plano.
2.3.3 Scrum
O Scrum foi concebido por Jeff Sutherland e sua equipe de desenvolvimento no início dos anos 1990. E nos últimos anos sofreu
algumas atualizações nos métodos gráficos por Schwaber e Beedle (Schwaber e Beedle, 2001).
O Scrum se utiliza de um conjunto padrão de processos de software que tem provado serem muito eficientes com a necessidade de urgência de entrega, requisitos em constante mudança do negócio.
O backlog do produto é uma lista com todas as funcionalidades desejadas pelo cliente. E todas essas funcionalidades servem de base para a criação de uma Sprint backlog que apresenta uma funcionalidade que deve ser implementada durante o tempo da Sprint. Essa funcionalidade é quebrada em diversas tarefas que são chamadas de User Stories, ou histórias do usuário. O fluxo geral do processo Scrum é ilustrado na Figura 6.
Figura 6 - Fluxo do processo Scrum Fonte: Pressman (2010)
2.4 CMMI
Existem vários modelos de maturidade, padrão, metodologias e diretrizes que podem auxiliar uma organização a melhorar seus processos. Contudo, as outras abordagens disponíveis tem o seu foco em uma parte específica do negócio e não uma visão sistêmica do negócio. Esse tipo de
abordagem tende a criar barreiras e compartimentalizar as organizações. O CMMI seria um caminho para evitar ou eliminar essas barreiras por meio de modelos integrados de processos. E o CMMI-DEV (CMMI para desenvolvimento) oferece alguma das melhores práticas relacionadas com o desenvolvimento e manutenção de software (CMMI® for Development, 2006).
O Framework CMMI é um modelo criado pelo Instituto de Engenharia de Software(SEI) da universidade Carnegie Mellon(EUA), com apoio do departamento de defesa dos Estados Unidos. Esse modelo é uma evolução de seu predecessor, o CMM, que traz massivas melhorias e que tem como objetivo o aumento na qualidade dos produtos e serviços oferecidos, assim como melhoria na eficiência no desenvolvimento de softwares e hardwares (CMMI® for Development, 2006).
Existem três áreas principais nas quais as empresas normalmente investem quando estão em busca de desenvolvimento: Pessoas, Tecnologia e Processos. O mundo vive um momento cheio de mudanças no qual a tecnologia está sempre em avanço e mudando, e onde as pessoas costumam trabalhar para várias empresas diferentes durante sua carreira profissional, por isso o principal fator que faz com que as empresas funcionem e se mantenham estáveis são os processos. Ao se investir em melhorias processuais as organizações estão investindo em uma área que oferece a estabilidade e a infraestrutura necessária para lidar com um mundo que está sempre mudando, além de potencializar o rendimento de seu pessoal e de sua tecnologia/equipamento, aumentando assim sua produtividade. Na Figura 7 pode-se observar essas três dimensões críticas de CMMI (CMMI® for Development, 2006).
Figura 7 - As três dimensões críticas Fonte: CMMI® for Development 2006)
Vale ressaltar que o CMMI não é um processo, o CMMI é um modelo de processo que foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos e serviços, e que descreve as características que são necessárias para se obter uma cadeia de processos eficiente.
2.3.1 Diferenças entre os modelos de maturidade e capacidade
Quando se fala em CMMI se apresenta duas possibilidades de modelos a serem utilizados em sua aplicação dentro da organização, são eles os níveis de maturidade e de capacidade. A maior diferença entre eles está relacionada ao foco em que eles tem em relação à área de processo e como ele permite as organização se basearem a partir deles.
Os níveis de maturidade estão ligados a um conjunto de áreas de processos que representam a sua maturidade e os níveis de capacidade
estão ligados às áreas de processos em si, se aquela área tem capacidade ou não, e reunindo um grupo delas pode-se definir a sua capacidade. Um problema com relação à capacidade está no fato em que não foi muito utilizada nas organizações, diferente da maturidade que é usada desde o CMM.
2.4.1 Tipo de Representação
No CMMI são utilizados dois tipos de representação diferente para a melhoria e avaliação dos processos: estágio e contínua. A representação contínua (Figura 9) é focada nas áreas de processo do CMMI, e quando uma organização escolhe essa representação o seu foco é a melhoria individual de cada processo. Além disso, ela se utiliza de níveis de capacidade, que representa uma melhoria ligada a uma área do processo em particular. Do outro lado a representação por estágio (Figura 8) se utiliza de conjuntos pré-definidos das áreas de processos que irão auxiliar na definição da melhoria na organização. E esse caminho é definido por níveis de maturidade que é representado por um conjunto de áreas de processos que determinam aquele nível (CMMI® for Development, 2006).
Figura 8 - Áreas de Processo na representação por Estágio Fonte: CMMI® for Development (2006)
Figura 9 - Áreas de Processo na representação Contínua Fonte: CMMI® for Development (2006)
2.4.2 Componentes das Áreas de Processo
Primeiramente, antes de explicar sobre os componentes das áreas de processo, o modelo e o tipo de representação escolhido para o desenvolvimento desse trabalho são o modelo de maturidade e a representação por estágios.
Uma área de processo é formada por componentes, que são divididos em três categorias: requeridos, esperados e informativos. O primeiro são os componentes requeridos que representam o que essencialmente uma organização deve implementar para aquela área de processo. Eles são utilizados como critério de avaliação para decidir se a área foi implementada ou não. O segundo, são os componentes esperados que descrevem algumas possibilidades de implantação para satisfazer um componente requerido. Eles são constituídos de práticas genéricas e práticas específicas. E por fim os componentes informativos que são um meio de auxiliar as organizações no processo de implantação dos componentes requeridos e esperados. Na Figura 10 temos uma ideia dessa organização dos componentes dentro de uma área de processo.
Figura 10 - Componentes do modelo CMMI Fonte: CMMI® for Development (2006)
2.4.3 Metas e Práticas
As metas e práticas dentro processo de CMMI são maneiras de mostrar o que os processos de cada área devem apresentar. Para se ter um maior entendimento de como eles são organizados no modelo CMMI é necessário entender o conceito de institucionalização, por ser de extrema importância quando se trabalha com melhoria de processo.
A institucionalização se daria à medida que o processo fosse enraizado na forma que o trabalho é executado, assim se tornando uma padronização na execução do processo e um comprometimento em relação à sua execução. O nível de institucionalização é apresentado nas metas genéricas e expresso nos nomes dos processos associados a cada meta, como indicado na Tabela 1.
Tabela 1 - Metas Genéricas e Nomes de Processos Fonte: CMMI® for Development (2006)
Nesse trabalho é dado maior destaque ao processo executado, como apresentado pela meta genérica GG1. Esta meta define que o processo apoia e permite a satisfação das metas específicas da área de processo, transformando produtos de trabalho de entrada identificáveis em produtos de trabalho de saída identificáveis.
Outro ponto de destaque é a execução das práticas específicas do processo, auxiliando no desenvolvendo dos produtos de trabalho e também fornecendo serviços, que ajudam a satisfazer às metas específicas que são
apresentadas em cada área de processo. Algo que é importante ressaltar é que essas práticas podem ser executadas informalmente sem seguir uma descrição documentada de processo ou um plano.
2.4.4 Níveis de Maturidade
De acordo com os princípios vistos em CMMI pode-se quantificar o grau de maturidade de uma organização avaliando seus processos e a maneira como eles são gerenciados (CMMI® for Development, 2006). Existem cinco níveis de maturidade que podem ser atingidos por uma empresa: Inicial, Gerenciado, Definido, Gerenciado quantitativamente e Otimizando.
Nível 1 - Inicial: No nível inicial temos os processos que atingem seu objetivo porém não são controlados ou existe um déficit em seu controle. Os métodos usados são imprevisíveis e normalmente os projetos são feitos de forma reativa, combatendo os problemas depois que eles já apareceram (Fire Fighting). Nesse nível a efetividade dos processos é muito baixa e normalmente existe um alto grau de frustração do pessoal envolvido.
Nível 2 - Gerenciado: No segundo nível encontramos os processos Gerenciados. Processos gerenciados são aqueles que são planejados e executados seguindo uma política bem definida da empresa. Esses processos são executados por uma pessoa capaz, contam com recursos adequados e tem uma produção controlada. Esses projetos normalmente chegam mais perto de atingir objetivos específicos como custo, qualidade e cronograma.
Um dos grandes problemas desse nível é que eles normalmente são muito dependentes de algumas poucas pessoas experientes. Isso pode vir a ser um grande problema pois o processo para de funcionar caso esses “heróis” se afastem da operação por algum motivo.
Nível 3 - Definido: Processos classificados como definidos são aqueles que são definidos, compreendidos e aplicados englobando toda a organização. Os procedimentos, ferramentas, métodos e a visão do negócio são padronizados, isso faz com que a organização inteira siga os mesmos guidelines e esteja sempre em sincronia. Nesse nível os processos são normalmente proativos, ou seja, ao contrário dos dois primeiros níveis eles não são focados em arrumar problemas no improviso.
Nível 4 - Gerenciado Quantitativamente: No quarto nível de CMMI temos os processos gerenciados quantitativamente. Esses processos estabelecem metas de qualidade e desempenho e depois usam essas metas como critério para gerenciar projetos futuros. A principal diferença do quarto nível quando comparado ao terceiro é a habilidade de prever o desempenho e a eficiência dos projetos, pois nesse nível os projetos são controlados usando dados estatísticos e outras técnicas quantitativas.
Nível 5 - Em Otimização: Quando uma organização atinge o quinto e último nível de CMMI ela passa a focar continuamente na melhoria de seus processos utilizando medidas quantitativas e dados estatísticos para prever o resultado de seus projetos.
A principal diferença entre o quinto nível e seu predecessor é o foco de suas melhorias. No nível quatro os dados são obtidos e usados para melhoria de processos e subprocessos, enquanto no ultimo buscamos por melhorias que afetem a eficiência e a desempenho em nível global. Obtemos dados de múltiplos projetos e áreas de uma empresa e cruzamos esses dados, assim podemos ter um maior entendimento do funcionamento da organização como um todo.
2.4.5 As Áreas de Processo do Nível 2 de Maturidade
O nível 2 de maturidade em CMMI é formado por 7 áreas de processo (CMMI® for Development, 2006), sendo elas:
Gerência de Requisitos(REQM):
A gerência de requisitos é a área responsável por supervisionar todos os requerimentos recebidos e gerados durante a execução do projeto.
Para que um projeto seja bem sucedido e atenda as expectativas do cliente é essencial que a análise de requisitos seja feita de forma adequada e que exista um alinhamento entre os planos do projeto e seus requerimentos.
É importante também manter a documentação dos requisitos atualizada no decorrer do projeto, já que é bastante comum que durante um projeto as necessidades do cliente evoluam ou até mesmo mudem, que tecnologias se tornem obsoletas e que processos sejam alterados. Isso pode alterar drasticamente os requisitos do projeto.
Planejamento de Projeto(PP):
Área responsável pela elaboração e cumprimento do plano do projeto. Nesse plano são estabelecidos os produtos a serem produzidos, tarefas a serem executadas, o cronograma do projeto e também a distribuição de recursos.
É extremamente importante que essa análise seja feita cuidadosamente, uma vez que nessa etapa são estabelecidos pontos cruciais do projeto como escopo, divisão do trabalho e o orçamento. Além disso, durante o planejamento também são identificados os potenciais riscos do projeto e definido o envolvimento de cada equipe no desenvolvimento.
Semelhante aos requisitos do projeto (REQM), é necessário sempre manter o plano do projeto atualizado em relação ao estado atual de desenvolvimento, visto que o plano pode vir a mudar constantemente durante sua execução.
Acompanhamento e Controle de Projeto(PMC):
O objetivo dessa área é monitorar as atividades do projeto durante sua execução e determinar se o desempenho encontrado é semelhante ao que era esperado durante a fase de planejamento, assim ações corretivas podem ser tomadas caso o desempenho do projeto fuja muito do esperado.
São monitorados: Riscos do projeto Plano do projeto Atividades propostas
Envolvimento dos stakeholders Gerenciamento de dados
Milestones do projeto
Dependendo do resultado encontrado durante o monitoramento podem ser necessárias alterações no plano do projeto e no gerenciamento do mesmo.
Gerência de Acordos com Fornecedores(SAM):
Área responsável pelo controle de bens e serviços adquiridos para serem usados durante o projeto. Aqui são definidos os tipos de cada aquisição, escolhidos fornecedores confiáveis e estabelecidos acordos comerciais.
Medição e Análise(MA): “Por que medir?
Por que analisar?
Por que os dados que você coleta de nada servem se você não os entende” (CMMI-DEV v1.2)
O foco da medição e análise é coletar dados quantitativos sobre o processo de desenvolvimento, sobre o projeto e sobre o produto em si. Esses dados são então medidos e analisados com objetivo de ajudar a organização a entender melhor seus próprios processos e tomar melhores decisões estratégicas no futuro. A análise minuciosa dos dados pode também ajudar a identificar soluções para problemas de ineficiência dentro da empresa e outras oportunidades de melhorias.
Garantia da Qualidade de Processo e Produto(PPQA):
PPQA existe para garantir que os produtos entregues sejam da mais alta qualidade. Essa área proporciona aos gerentes do projeto feedback dos processos sendo executados e seus respectivos projetos.
O principal objetivo é garantir que todos os requerimentos sejam atendidos durante o desenvolvimento, seguindo sempre os procedimentos adequados e corrigindo qualquer possível falha no decorrer do processo.
Gerência de Configuração(CM):
CM é uma área importante para dar suporte ao processo de desenvolvimento do seu produto, sendo responsável por todo o processo de configuração de ambiente do desenvolvimento e até mesmo depois no processo de implantação.
2.4.6 Planos em Melhoria de Processo
No desenvolvimento de melhoria de processo é necessário definir um plano, bem como uma estratégia. Dentro do modelo CMMI é requisitada a criação de um plano para cada Área de Processo, e cada um desses planos contém: procedimentos, atividades, recursos, entre outros itens.
Um ponto que deve ser realçado no contexto proposto é que um plano não seria um cronograma, mas uma estratégia para chegar a um processo que esteja adequado em relação ao CMMI. Os principais planos em melhoria de processo são:
Plano de Melhoria de Processos: plano que inclui custos, recursos e define objetivos.
Plano de Implantação/Operação: plano de nível tático, com maior detalhamento, que indica qual o esforço que deve ser despendido nas tarefas gerenciáveis baseadas no resultado de avaliação e diagnóstico de CMMI, como o SCAMPI
Plano de Ação: Um plano com bastante detalhamento que define o que as equipes devem fazer e quando, são criados times que focam nas áreas de processos que foram identificadas e necessitam de melhoria.
O sucesso dos programas de melhoria depende mais do que de boa política e procedimentos, esses programas necessitam que a organização esteja convencida dos benefícios e esteja direcionando esforços para esse objetivo.
2.5 Métodos de Avaliação e Diagnóstico
A utilização de ciclos sucessivos de melhoria, com avaliações formais e informais em cada ciclo com o intuito de medir o avanço dos objetivos de
melhorias estabelecidos ou saber qual a atual situação, é de uso comum nos programas de melhoria de processos de software (Anacleto, 2005). Porém, com um alto custo envolvido na utilização de avaliações formais, os métodos de avaliação menores e menos formais foram sendo desenvolvidos pelas empresas de consultoria e empresas que implementam modelos de qualidade (PRIKLADNICKIÇ BECKERÇ YAMAGUTI, 2005)
A utilização de um diagnóstico inicial tem como finalidade identificar qual a real situação da empresa no início do projeto e embasar o planejamento do CMMI a ser executado a partir daquilo. O diagnóstico usualmente é realizado de forma simplificada, mas está embasado na lógica das avaliações formais, porém sem o mesmo rigor.
Os métodos que serão explicados, são aqueles que são utilizados usualmente no modelo CMMI, são eles o SCAMPI e o PIID
2.5.1 SCAMPI
O método Standard CMMI Appraisal Method for Process Improvement (SCAMPI) é utilizado para fornecer a graduação de maturidade do processo em relação ao modelo CMMI. O mesmo possui três tipos de avaliação: classe A, classe B e classe C. As avaliações classe A são as avaliações oficiais, onde a empresa recebe um certificado reconhecendo o seu nível de maturidade. As de classe B são avaliações menores não oficiais e tem a finalidade de verificar as oportunidades de melhoria, normalmente usada como preparação antes de ser submetida para uma avaliação oficial. E por último, as avaliações de classe C, ou gap analysis, são para encontrar as lacunas no atual processo de desenvolvimento de software, realizando uma comparação com as práticas existentes (PRIKLADNICKIÇ BECKERÇ YAMAGUTI, 2005)
Os principais objetivos do SCAMPI são: melhorias internas de processo, na seleção de fornecedores e no monitoramento de processos
através de um método de avaliação integrado e ser um método de avaliação eficiente. As principais fontes de dados a serem coletados são:
● Instrumentos: informações escritas, tais como questionários, descrições ou mapeamentos das práticas do modelo correspondentes ao processos da organização.
● Apresentações: informações preparadas pela organização e fornecidas, visual ou verbalmente, para a equipe de avaliação para descrever o processo e a implementação das práticas do CMMI.
● Documentos: artefatos que refletem a implementação de uma ou mais práticas do modelo (incluindo políticas organizacionais, procedimentos e artefatos, ao nível de implementação).
● Entrevistas: reunião com os responsáveis e usuários do processo (como líderes de projeto, gerentes, desenvolvedores).
O conceito utilizado pelo SCAMPI é que deve ocorrer uma investigação focada na otimização dos recursos, pois o modelo CMMI apresenta um grande número de práticas que devem ser analisadas e uma grande quantidade de dados a serem analisados. Estes dados são consolidados a partir de um consenso. Uma característica da implantação de uma prática é quando se dá uma evidência objetiva. As mesmas podem ser caracterizadas da seguinte forma:
● Totalmente implementada ● Amplamente implementada ● Parcialmente implementada ● Não implementada
Essas características que as práticas apresentam é a base para o registro das observações dos pontos fortes e fracos do processo, que formam uma avaliação preliminar. Esta avaliação é validada pela organização quando a equipe ainda está coletando dados. O nível de maturidade é baseado nos dados validados e são gerados no mínimo por cada meta específica de cada área de processo no escopo da avaliação (ASATO, SPINOLA, SILVA, 2010).
2.5.1 PIID
O PIID é um documento usado para indicar que práticas estão ou não sendo executadas no processo de desenvolvimento. Existem 3 tipos de PIIDs:
Artefato direto
Artefato indireto
Afirmações em uma entrevista
Primeiramente o artefato direto é conhecido por qualquer resultado que venha direto de uma implementação de uma das práticas do modelo CMMI, por exemplo os documentos de projeto, materiais de treinamentos entre outros. O segundo são os artefatos indiretos que seriam evidências de se estar utilizando as práticas do modelo, por exemplo relatórios e apresentações. E por fim as afirmações de forma escrita ou verbal conseguidas diretamente com as pessoas envolvidas no processo, um ótimo exemplo são as entrevistas (AMARAL, FARIA, 2010).
2.6 Estudos de Casos Relacionados em CMMI
A maioria do conteúdo sobre o processo de maturação de organizações baseado na aplicação do framework CMMI combina o CMMI e
mais algum tipo de técnica e faz uma avaliação e comparação entre os métodos usados.
Um dos exemplos que seguem esse padrão é o artigo desenvolvido por Minna Pikkarainen e Annukka Mäntyniem (Pikkarainen e Mäntyniemi, 2006). Nesse artigo as autoras estudam o uso do CMMI dentro do paradigma de desenvolvimento ágil, explorando três casos de uso e relatando o resultado. Esse estudo é realmente interessante, pois normalmente desenvolvimento de software ágil e CMMI são consideradas duas ideologias opostas de desenvolvimento.
Outro exemplo encontrado foi o artigo escrito por Paula Alexandra Fernandes Monteiro (Monteiro, 2014). Nesse artigo a autora explica como é difícil para pequenas empresas adotarem o CMMI, e propõe uma solução que integra o CMMI com a metodologia de desenvolvimento Rational Unified Process (RUP), criando assim um conjunto de soluções que guiam pequenas empresas na implementação dos primeiros níveis de maturidade do CMMI.
2.7 Norma ISO/IEC 15504
O desenvolvimento da norma ISO/IEC 15504 se deu pela necessidade de ter padrões na avaliação de processos de software, além disso esta norma também é considerada um framework. Basicamente, a norma é dividida em duas dimensões: níveis de processo e categorias de processo. Para ambos os casos devem ser apresentados os seguintes elementos:
Os processos: um avaliador conceituado deve verificar os requisitos previstos na norma;
Uma escala de medida: deve apresentar um modelo de avaliação de processo como uma referência;
Outro ponto importante de ser apresentado é o mecanismo de pontuação da norma, que é ordenada em uma escala de quatro valores. Esses valores são baseados no percentual de atendimento aos requisitos do processo. As variações são:
0 a 15% é declarado como não atendido;
16 a 50% é parcialmente atendido;
51 a 85% é largamente atendido;
86 a 100% é definido totalmente atendido;
Um exemplo é quando uma empresa pode ser considerada do nível 2 quando todos os atributos dos níveis inferiores são totalmente atendidos e todos os atributos do nível são largamente atendidos.
2.8 Considerações Finais
Neste capítulo foram mostrados vários conceitos no processo de desenvolvimento de software e do modelo CMMI, além de apresentar de maneira resumida a norma ISO/IEC 15504.
Primeiramente os conceitos relacionados ao processo de desenvolvimento de software serão utilizados no processo de análise do processo atual de desenvolvimento do DU e também na construção da proposta de melhoria.
Segundo, os conceitos estudados de CMMI são a referência de todo o processo de análise da maturidade e bem como a criação de uma proposta de melhoria.
E por fim, a norma ISO/IEC 15504 é utilizada como uma maneira de definir a aderência das práticas de desenvolvimento no DU, e com isso resultará no nível de maturidade em CMMI.
Nesse capítulo são apresentados os métodos utilizados no processo de avaliação e diagnóstico do nível de maturidade em CMMI, além de explicar qual a metodologia foi utilizada no mesmo. Além disso, são apresentadas as três fontes de análise, uma entrevista realizada com o diretor do departamento, os documentos relacionados com o projeto de gerenciamento de frota e uma pesquisa realizada com todo o grupo de desenvolvimento. Por fim, serão feitas as ressalvas sobre os desafios de se aplicar todas essas avaliações em um departamento de uma universidade pública.
3.1 Contexto
Foi realizado um contato direto com o Diretor do DU. Após a explicação sobre os objetivos dessa pesquisa ele se mostrou bastante interessado no nosso projeto e nos benefícios que ele poderia trazer para o departamento. Com isso ele nos autorizou a acompanhar todo o processo de desenvolvimento do projeto de gerenciamento de frotas da UTFPR.
O gerenciamento de Frotas da UTFPR, atualmente já é realizado, mas de forma manual, por meio do uso de planilhas, formulários em papel e principalmente pelo e-mail ou telefone aonde todo o processo inicia. Cada campus tem seu agendamento, o que dificulta e muito a gestão por parte da reitoria e principalmente as auditorias interna e eventualmente externas. O novo sistema visa agilizar o atendimento, padroniza-lo para todos os campus informatizando ao máximo possível as etapas, o que proporcionará mais agilidade e facilidade do gerenciamento e auditorias/relatórios de gestão.
3.1.1 Regras de Negócio
O Solicitante realiza o pedido de uso do veículo através do formulário de solicitação.
aprovação do uso do veículo na data e hora solicitadas.
A solicitação já previamente aprovada pelo responsável é encaminhada ao DISAU e este realiza a validação dos dados, prazos da solicitação, bem como a disponibilidade de veículo/motorista para o dia e horários solicitados.
Havendo disponibilidade então o DISAU retorna para o solicitante avisando-o da aprovação do uso, realiza a confirmação do agendamento (reserva veículo e motorista), comunica motorista do itinerário, data e hora de saída e chegada.
Em caso de não haver data ou ocorrerem problemas o DISAU comunica o solicitante do problema e solicita troca de data, correções ou encerramento da solicitação.
A seguir é apresentado o processo de negócio do sistema de Gerenciamento de Frotas que foi desenvolvido pelo departamento estudado.
Esse flowchart (Figura 11) mostra o fluxo de informações e a sequência de tomadas de decisão necessárias para gerenciar as frotas de veículos da UTFPR, iniciando pela solicitação do transporte feita pelo usuário, passando pela aprovação e agendamento do transporte, até a liberação e utilização do veículo.
Caso a aprovação seja declinada, ou não existam veículos disponíveis, é criada uma ocorrência para a alteração de data do transporte. Caso não seja possível alterar a data, a solicitação é encerrada.
Vale ressaltar também que após o uso dos veículos são criados documentos que servem como relatórios dos transportes.
Figura 11 - Processo de Negócio do Sistema de Gerenciamento de Frota Fonte: Caso de estudo
A metodologia aplicada para a análise da maturidade no departamento da UTFPR foi, partir dos estudos dos métodos de avaliação e diagnóstico explicados anteriormente na seção 2.5, definir qual seria a melhor maneira de conseguir extrair a real situação do grau de maturidade do departamento estudado. Para isso foi desenvolvido uma pesquisa com aspectos do PIID e além de colaborar com os aspectos requeridos pelo SCAMPI.
Outros materiais foram utilizados para realizar a avaliação da maturidade, como uma análise dos documentos referentes ao projeto de gerenciamento de frotas e uma entrevista com o diretor geral do departamento, que coordena as atividades de desenvolvimento no departamento. A Figura 12 mostra o processo resumido de determinação do nível de maturidade do departamento.
Figura 12 - Fluxo de Atividades Fonte: Autoria Própria
3.3 Diagnóstico
Nos processos de análise propostos por esta metodologia existem algumas práticas comuns usadas para extrair informações sobre o nível atual de maturidade apresentado pela organização. Essa extração de informações normalmente é feita através de uma pesquisa com integrantes do grupo de desenvolvimento que tenham ligação direta com o processo de desenvolvimento, entrevistas realizadas com o diretor do departamento em análise e validações dos documentos do projeto em avaliação pelo CMMI.
Nesse diagnóstico proposto, são apresentadas várias afirmações sobre o que deveria estar sendo realizado pelo grupo de desenvolvimento com relação a cada uma das áreas de processo do modelo. O escopo desse trabalho foi limitado às áreas de processo do nível 2 de maturidade. Na Figura 13 é apresentada a pesquisa relacionada a uma das áreas de processo e no Apêndice A é apresentado o questionário de maneira integral.
Figura 13 - Questionário de REQM Fonte: Autoria Própria
opções a seguir para cada uma das afirmações acima. Essas opções foram criadas utilizando a escala Likert, que define um método de avaliação para pesquisas.
● Concordo totalmente ● Concordo parcialmente ● Indiferente
● Discordo parcialmente ● Discordo totalmente
É importante também ressaltar que os participantes da pesquisa foram previamente instruídos sobre as terminologias e práticas comuns do CMMI, bem como uma breve explicação sobre cada área de processo e sua importância para a evolução do grau de maturidade do departamento. Isso foi feito para garantir que todas as perguntas fossem entendidas pelos participantes, visto que do contrário as respostas perderiam seu valor.
As perguntas dessa pesquisa foram elaboradas baseando no PIID e no SCAMPI, porém de forma simplificada. Isso foi feito pois ambos os métodos são muito complexos e possuem um questionário bastante extenso e detalhado, de forma que não seria possível aplica-los a realidade do departamento analisado. Para isso nós separamos as perguntas mais importantes de cada área de processo de forma a criar um questionário mais sucinto e que pudesse ser aplicado com mais facilidade dentro da organização. Algumas outras questões que eram muito especificas foram unidas em afirmações mais abrangentes, por exemplo “Ensure
that the supplier agreement is satisfied before accepting the acquired product.” e
“Perform activities with the supplier as specified in the supplier agreement.” Foram unidas em apenas uma afirmação simplificada: “São sempre estabelecidos e mantidos os acordos com fornecedores”.
A partir da compilação dos dados da pesquisa é possível realizar uma análise na situação atual do processo de desenvolvimento dentro da organização estudada. Primeiramente será feito uma análise geral com relação a todas as áreas de processo do nível 2 do modelo CMMI.
Para traduzir as respostas na pesquisa em alguma das características que as práticas de CMMI apresentam, como explicado anteriormente, foi definida a seguinte tabela de conversão das respostas.
Tabela 2 - Critérios SCAMPI x Pesquisa Fonte: Autoria Própria
Depois de feitas as conversões das respostas foi realizada uma compilação dos dados para se chegar em uma taxa de aderência, para isso foram calculados dois tipos de taxa, uma levando em consideração as respostas com “parcialmente implementada” e colocando um peso menor a essa característica em comparação a outra característica, e uma só utilizando as “amplamente implementada” em consideração. A seguir é possível visualizar as duas fórmulas que foram construídas, e o valor definido para o peso na fórmula TXA’’ é de 60%, ou seja, 0,6. Esse valor foi escolhido se baseando na norma ISO/IEC 15504, no intervalo de largamente atendido, que varia entre 51% e 85%.
Equação 1 - Fórmula da Taxa de Aderência 1 (TXA') Fonte: Autoria Própria
Equação 2 - Fórmula da Taxa de Aderência 2 (TXA'') Fonte: Autoria Própria
temos todas as áreas de processo com uma taxa de aderência abaixo dos 60%, independente da fórmula utilizada, mostrando o quanto ainda existe espaço para a melhoria do processo de desenvolvimento, como vimos anteriormente com base na normaISO/IEC 15504, descrita no item 2.7. O importante é ressaltar como no geral a taxa de aderência teve uma média de 15% para TXA’ e de 40% para TXA’’, de uma maneira mais simples, uma taxa é mais pessimista e apresenta uma percentagem bem inferior a outra que apresenta uma taxa mais otimista.
Devido a comparação dos resultados de ambas essas taxas com os documentos fornecidos sobre o projeto e com as conversas que tivemos com o gestor do departamento, percebemos que nenhuma das duas representava muito bem a realidade do departamento, sendo a TXA’ pessimista demais e TXA’’ otimista demais. Então para equilibrar essas taxas foi feito a média entre elas e teve como resultado o MTXA que apresenta uma aderência mais próxima do real. Outro fator que deve ser levado em conta é que o espaço amostral era extremamente limitado já que pouco mais de 10 funcionários trabalham no departamento avaliado.
Equação 3 - Média das Taxas de Aderência 1 e 2 (MTXA) Fonte: Autoria Própria
Figura 14 - Comparativo das taxas de Aderência Fonte: Autoria Própria
A seguir é feita uma análise mais detalhada de cada uma das áreas de processo, procurando entender como se chegou ao resultado acima.
A Primeira prática a ser analisada é o Gerenciamento de requisitos (Figura 14), que tem a terceira maior MTXA na avaliação, em torno de 35%. As respostas de “Amplamente Implementada” (AI) são as que tem maior impacto no resultado final, mas no caso dessa prática as respostas de “Parcialmente Implementada” (PI) foram predominantes. A afirmação P4(“Existe uma preocupação pra que os planos e atividades do projeto se mantenham alinhados aos requerimentos”) deve ser destacada por não apresentar resposta com “Não Implementada” (NI).
Figura 15 - Aderência de REQM Fonte: Autoria Própria
A segunda prática é o Planejamento de Projeto (Figura 15), apresentando uma MTXA de 29%, tem um aumento significativo das respostas de NI em comparação à prática apresentada anteriormente. Certamente uma prática influencia nas outras, principalmente quando apresentam tópicos parecidos, nesse caso REQM está de certa forma próximo de PP, pois fazem parte de um contexto de Gerenciamento de Projeto. A afirmação a ser destacada nesta prática é a P7 (“É feito uma avaliação da diferença entre os recursos disponíveis e os necessários para cada projeto”) por não apresentar nenhuma resposta com AI e uma predominância de respostas com NI, chegando uma possível conclusão de que não está sendo implementada no processo.
Figura 16 - Aderência PP Fonte: Autoria Própria
A terceira prática é Acompanhamento e controle do Projeto (Figura 16), que apresenta uma MTXA de 38%, a segunda maior entre as áreas avaliadas. Um dos destaques na avaliação dessa prática é apresentar um maior número de afirmações a serem respondidas, e um outro destaque é que pelo menos 4 afirmações não tiveram resposta de NI. E por fim a afirmação em destaque nesta prática é a P1 “É feito um monitoramento dos riscos durante o projeto” que não apresenta nenhuma resposta com AI, criando um alerta sobre o processo de monitoramento do projeto.
Figura 17 - Aderência PMC Fonte: Autoria Própria
apresenta uma das menores MTXA na avaliação, com 25%. Um destaque a ser feito nessa prática é que apresenta poucas afirmações na pesquisa, mas mesmo assim suas respostas são válidas e podem ser analisadas. A afirmação de maior destaque é a P2 “Os fornecedores são selecionados baseados em avaliação de suas habilidades para ir de encontro com os requisitos específicos e critérios estabelecidos” que não teve nenhuma resposta com AI.
Figura 18 - Aderência SAM Fonte: Autoria Própria
A quinta prática a ser analisada é Medição e Análise (Figura 18), que dentre todas as áreas analisadas é a que apresenta a menor MTXA, com 10%. Tem como destaque negativo apenas uma de seis afirmações ter respostas com AI. Dentre estas, tem destaque negativo a P3 “Existe um protocolo utilizado na análise e prestação de contas das métricas obtidas” que tem todas as respostas como NI.
Figura 19 - Aderência MA Fonte: Autoria Própria
A sexta prática é Garantia de Qualidade de Processo e Produto (Figura 19), e que apresenta uma das menores MTXA, com 18%. Tem um desempenho um pouco acima da área de processo anterior, e isso se deve a ter mais respostas como AI, neste caso metade das afirmações apresentaram essas respostas, mesmo com pouca expressão. E novamente uma grande quantidade de respostas como NI, totalizando 59% das respostas, em comparação as AI com 9%. A afirmação com maior número de NI foi a P5 “Existe uma pessoa designada que é responsável pelo controle de qualidade do projeto”, assume que existe uma grande necessidade de definir uma pessoa responsável pela qualidade dentro do processo de desenvolvimento.
Figura 20 - Aderência PPQA Fonte: Autoria Própria
A última prática a ser analisada é Gerenciamento de Configuração (Figura 20), que apresenta uma MTXA de 41%, bem acima das últimas práticas analisadas. Tem um destaque positivo de apresentar em todas as afirmações pelo menos uma resposta com AI, mostrando assim que alguma coisa no sentido desta área de processo está sendo realizada. Outro ponto de destaque é de que em duas afirmações não apresenta respostas com NI, aumentando ainda mais a sua aderência ao processo. A afirmação em destaque é a que tem maior taxa de NI, que foi a P6 “Identifica e envolve os stakeholders no processo de gerenciamento de configuração”, que assinala a necessidade de envolver as pessoas relacionadas ao projeto no gerenciamento da configuração.
Figura 21 - Aderência CM Fonte: Autoria Própria
