Baixe o app para aproveitar ainda mais
Prévia do material em texto
MICHELE DE SOUZA LIMA O IMPACTO DO MODELO CMMI NA QUALIDADE DO SOFTWARE: UM ESTUDO SOBRE A MELHORIA DOS PROCESSOS CATAGUASES FACULDADES UNIFICADAS DE CATAGUASES BACHARELADO EM SISTEMAS DE INFORMAÇÃO 2016 MICHELE DE SOUZA LIMA O IMPACTO DO MODELO CMMI NA QUALIDADE DO SOFTWARE: UM ESTUDO SOBRE A MELHORIA DOS PROCESSOS Projeto de Monografia apresentado ao Curso de Sistemas de Informação do Instituto Doctum de Educação e Tecnologia, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Área de Concentração: Engenharia de Software Orientador: Prof.Matheus Botarro. CATAGUASES FACULDADES UNIFICADAS DE CATAGUASES BACHARELADO EM SISTEMAS DE INFORMAÇÃO 2016 FACULDADES UNIFICADAS DE CATAGUASES CATAGUASES 2016 MICHELE DE SOUZA LIMA O IMPACTO DO MODELO CMMI NA QUALIDADE DO SOFTWARE: UM ESTUDO SOBRE A MELHORIA DOS PROCESSOS Trabalho de Conclusão de Curso apresentado ao Curso de Sistemas de Informação das Faculdades Unificadas de Cataguases, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. BANCA EXAMINADORA _____________________________________________ Prof. Matheus Botarro – Orientador Faculdades Unificadas de Cataguases _____________________________________________ Prof. Xxxxxxx Faculdades Unificadas de Cataguases _____________________________________________ Prof. Xxxxxxx Faculdades Unificadas de Cataguases RESUMO O presente trabalho trata os conceitos relativos à qualidade do software e modelos de maturidades. Dentro dessa proposta, foram abordadas as principais atividades do processo de garantia de qualidade, segundo o modelo de melhoria de processo CMMI. O projeto iniciou-se com a realização de um questionário que indicaram quais metas e benefícios às empresas esperam com a implantação do modelo CMMI, onde serviu como estudo de caso para o presente projeto. Foram identificadas as demandas de processos que deveriam ser avaliados e melhorados, a fim de se alcançar as metas e objetivos estabelecidos no questionário, passou-se a fase de estudos dos modelos, dentre os existentes se adaptariam melhor as metas e objetivos da organização. PALAVRAS-CHAVE: Qualidade, Software, Qualidade de Software, Garantia da Qualidade de Software. SUMÁRIO INTRODUÇÂO ....................................................................................................................... 12 CAPÍTULO 1 – VISÃO GERAL DA ENGENHARIA DE SOFTWARE ......................... 14 CAPÍTULO 2 – QUALIDADE DE SOFTWARE ............................................................... 16 2.1 SQA (Garantia da Qualidade de Software) ........................................................... .18 2.2 SEPG (Software Engineering Process Group) ...................................................... 20 CAPÍTULO 3 – MODELOS DE MATURIDADE ............................................................... 22 3.1 CMM (CAPABILITY MATURITY MODEL) ................................................................. 23 3.2 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) ................................... 25 3.2.1 Representação dos Modelos .................................................................................. 28 3.2.1.1 Representação por Estágio ................................................................................. 28 3.2.1.2 Representação Contínua ...................................................................................... 30 3.2.2 Áreas-chave de processo (Key Process Areas ou KPAs) .............................. 32 3.2.3 Características Comuns e Práticas-chave .......................................................... 33 3.3 MPS-BR (MELHORIA DO PROCESSO DE SOFTWARE) .................................... 34 3.3.1 Níveis de maturidade ................................................................................................ 35 CAPÍTULO 4 – APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE CASO COM MODELO CMMI .................................................................................. 37 4.1 Tipo de pesquisa ............................................................................................... 37 4.2 Processos metodológicos ................................................................................ 37 4.3 Etapas do questionário ..................................................................................... 38 4.4 Elaboração do plano de ação .................................................................................... 43 4.5 Soluções encontradas ...................................................................................... 43 4.6 Resultados esperados com a implantação do CMMI ..................................... 44 CONSIDERAÇÕES FINAIS ...................................................................................... 46 REFERÊNCIAS ......................................................................................................... 47 ANEXO A .................................................................................................................. 51 DEDICATÓRIA Primeiramente a Deus, por tudo que me proporcionou na vida, por me dar forças para alcançar meus objetivos, por me cercar de pessoas maravilhosas sem as quais minha caminhada não teria sentido e por todas as oportunidades a mim proporcionadas. A minha mãe Marilucia de Souza Lima, pelo esforço empreendido, por sempre me apoiar, e pelo exemplo de vida e luta. AGRADECIMENTOS Agradeço a Deus por tudo o quanto tem feito e por sua misericórdia infinita. Aos meus pais, por terem me ajudado financeiramente quando eu mais precisei. Aos meus professores e as pessoas que de alguma maneira contribuíram para a realização desse trabalho. “Para se ter sucesso, é necessário amar de verdade o que se faz. Caso contrário, levando em conta apenas o lado racional, você simplesmente desiste. É o que acontece com a maioria das pessoas”. (Steve Jobs) LISTA DE FIGURAS Figura 1: Camadas de engenharia de software ..................................................... ...15 Figura 2: Modelo de Maturidade de Capacitação do SEI ......................................... 24 Figura 3: Estrutura de representação por estágio .................................................... 30 Figura 4: Estrutura de representação contínua ........................................................ 31 Figura 5: Pergunta número 04 do questionário ao usuário ...................................... 38 Figura 6: Pergunta número 05 do questionário ao usuário ...................................... 39 Figura 7: Pergunta número 06 do questionário ao usuário ...................................... 39 Figura 8: Pergunta número 07 do questionárioao usuário ...................................... 40 Figura 9: Pergunta número 08 do questionário ao usuário ...................................... 40 Figura 10: Pergunta número 09 do questionário ao usuário .................................... 41 Figura 11: Pergunta número 10 do questionário ao usuário .................................... 41 Figura 12: Pergunta número 11 do questionário ao usuário .................................... 42 Figura 13: Pergunta número 12 do questionário ao usuário .................................... 42 LISTA DE TABELAS Tabela 1: Áreas de processos .................................................................................. 33 Tabela 2: Resultados do desempenho CMMI ........................................................... 45 ABREVIATURAS E SIGLAS DOD - Departamento de Defesa dos Estados Unidos CMM - Capability Maturity Model CMM - Capability Maturity Model Integration KPA - Key Process Areas MPS.BR - Melhoria do Processo de Software Brasileiro ROI - Retorno de Investimento SEI - Software Engineering Institute SGQ - Sistema de gestão da qualidade. SQA - Software Quality Assurance QA - Quality Assurance 12 INTRODUÇÃO A busca pela qualidade é um dos assuntos mais discutidos nas organizações desenvolvedoras de software. Nos dias de hoje, não são mais permitidos entregar produtos com baixa qualidade e corrigir os erros e falhas depois que o produto é fornecido aos clientes. Para PRESSMAN (1995)1, “os problemas que afligem o desenvolvimento de software podem ser caracterizados a partir de uma série de perspectivas diferentes”, mas, em muitos casos, ocorre uma grande frustração por parte dos clientes pelo não atendimento dos requisitos e prazos de entrega. Para dar soluções aos desafios e aumentar o grau de maturidade das empresas, vários modelos de melhoria de qualidade foram propostos, dentre eles, destacam-se os baseados em processos como o CMMI (Capability Maturity Model Integration) e MPS.BR (Melhoria do Processo de Software Brasileiro). Segundo SOMMERVILLE (2003)2, “a melhoria do processo significa compreender os processos existentes e modificá-los, a fim de melhorar a qualidade do produto e/ou reduzir custos e o tempo de desenvolvimento”. Conforme o autor é necessário seguir uma sequência de atividades denominada de estágios que envolvem: Análise de processos, identificação de melhoria, introdução de mudanças nos processos, treinamento de mudanças e ajustes. Diante disso, é essencial que os desenvolvedores coloquem eficiência e eficácia nos seus processos, garantindo a melhoria conforme os padrões de qualidade internacionais. Sobre o conceito de organizações que desenvolvem software, o presente trabalho tem como foco principal retratar a importância de qualidade de software, a partir da utilização de modelos de melhoria de processos e atividades de garantia qualidade. O trabalho é iniciado com base na engenharia de software e se dirige a um mercado que só há pouco tempo vêm revelando o seu interesse em certificações de qualidade em seus processos. Para melhor abordar o assunto, o presente trabalho questiona alguns problemas que a engenharia de software se propõe a resolver como: falta de qualidade, insatisfação dos clientes e custo. Para esses problemas, a causa mais 1 PRESSMAN, 1995, p. 23. 2 SOMMERVILLE, 2003, p.477. 13 relevante e a falta de experiência de profissionais durante o desenvolvimento, a falta de treinamento em relação aos modelos e técnicas, a atenção aos requisitos implícitos pelos clientes, e as mudanças no ramo (novas técnicas de desenvolvimento). Este trabalho está definido em uma sequência que auxilia no entendimento e desenvolvimento. A parte inicial disserta os conceitos básicos de engenharia de software e as principais questões relacionadas à crise de software. No segundo capítulo são apresentados teorias, conceitos e fatores sobre a qualidade do software, assim como, o gerenciamento e equipe de produção. No terceiro capítulo são apresentados os modelos de melhorias criados pelo SEI: CMM e CMMI, como também o modelo MPS.BR. Ambos possuem a mesma terminologia e o mesmo objetivo, garantir a melhoria dos processos. Para tanto, foi feito um estudo sobre os níveis e componentes sobre os dois Modelos de Maturidade. O quarto capítulo consiste na aplicação de um estudo de caso, com a finalidade de colher informações for meio de um questionário que foi aplicado em algumas empresas no setor de desenvolvimento de software e por profissionais na área de tecnologia da informação. Todo o referencial teórico, bem como o estudo realizado, se deu através de artigos publicados, sites de desenvolvedores e livros de engenharia de software baseado em teorias tecnológicas de PRESSMAN, SOFTEX, SOMMERVILLE, dentre outros que deram sustento a concretização da pesquisa. Abaixo, surgem as considerações finais, onde relata uma conclusão geral do trabalho realizado, as dificuldades encontradas e as recomendações. Por fim, as referências bibliográficas, de onde foi retirada toda a teoria expressa. 14 1 VISÃO GERAL DA ENGENHARIA DE SOFTWARE A engenharia de software é uma disciplina que está presente em todo o ciclo de vida do software, desde o inicio de criação, até a entrega e a manutenção. Segundo HIRAMA (2012)3, o termo engenharia de software foi nomeado a primeira vez em 1969, devido a um conjunto de problemas encontrados na produtividade dos softwares em meio à famosa ‘crise de software’. A crise se referia aos softwares desenvolvidos naquela época que apresentavam uma grande quantidade de defeitos, custos excessivos, qualidade do produto inadequada e prazos elevados. Sua implementação era iniciada a partir de uma simples definição. Não eram utilizados metodologias, métricas, processos, planejamento e cronogramas, o que trazia grandes problemas aos projetos. Para PRESSMAN (1995)4, os problemas relacionados à crise foram provocados pelo próprio software e por falhas de pessoas responsáveis pelo seu desenvolvimento. Além disto, na tentativa de se consertar os erros, muitas vezes as pessoas introduziam mais erros no código. Contudo, tanto o desenvolvimento como as correções eram trabalhosas e requeria muito tempo, sem contar que a linguagem utilizada era de baixo nível. SOMMERVILLE (2003)5, afirma que novas técnicas e métodos foram necessários para controlar as dificuldades dos grandes sistemas da época. Diante disso, surgiu o termo Engenharia de Software, que se refere ao desenvolvimento de software por pessoas qualificadas, englobando aspectos técnicos e não-técnicos, de forma a produzir software de qualidade, eficiente e dentro de custos aceitáveis. Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. A engenharia de software é abrangida por um conjunto de três elementos que envolvem métodos, ferramentas e procedimentos. Esses elementos são focados na busca pela qualidade e melhoria dos processos, como demonstra a figura 1. 3 HIRAMA, 2012, p. 7-8. 4 PRESSMAN, 1995, p.24. 5 SOMMERVILLE, 2003, p.4 15Figura 1: Camadas de engenharia de software Fonte: PRESSMAN e MAXIM, 2016, p.16. Segundo PRESSMAN (1995)6, os três elementos possibilita aos gerentes e engenheiros um controle sobre o processo de desenvolvimento, e assegura uma base para a elaboração de software de boa qualidade. A qualidade de um software pode ser vista no processo utilizado na produção dele. Muitas vezes os processos não são tomados devido à falta de qualificação da equipe, por ausência de ferramentas e por pressão de prazos que levam os gerentes a eliminar fases da garantia de qualidade (FILHO, 2008)7. Devido a isso, a engenharia de software foi desenvolvida para se ocupar de buscar fórmulas e regras para o desenvolvimento do software e determinar essas regras da melhor forma possível a todos os envolvidos no projeto. Para construção de um software de boa qualidade, é necessário que o conceito seja aplicado por toda equipe, começando pelo os gerentes, engenheiros, diretores, analistas, programadores, e usuários do sistema (RODRIGUES, 2008)8. Obter esse conceito não é uma tarefa muito fácil para uma organização. Contudo, a engenharia de software surgiu em meio aos problemas encontrados no desenvolvimento, sucedendo em práticas, soluções e melhorias que são utilizadas por todas as organizações até os dias de hoje. 6 PRESSMAN, 1995, p.31. 7 FILHO, 2008, p.19. 8 RODRIGUES, 2008, p.8. 16 2 QUALIDADE DE SOFTWARE Criar um software de qualidade é o objetivo de todas as organizações desenvolvedoras de software. A maior parte da literatura relacionada a esse assunto acredita que a qualidade pode ser vista quando um produto final é aceito pelo cliente dentro do prazo estabelecido, conforme as funcionalidades em perfeito funcionamento. Entretanto, para assegurar a qualidade do produto, é preciso seguir todas as fases de desenvolvimento que vem desde a coleta de requisitos. A partir do momento que os requisitos são atendidos, é atribuída a qualidade no software. Em um produto de software de má qualidade, muitos dos requisitos não são atendidos completamente, devido à falta de qualificações das pessoas, deficiências de ferramentas ou porque pressões de prazo que levam os gerentes de projeto a eliminar etapas relacionadas ao controle de qualidade. Para atingir a qualidade do software, é necessário um planejamento, utilizando procedimentos, modelo e padrões, seguindo todas as etapas do ciclo de vida do software com atividades que asseguram garantir a qualidade do processo, e qualidade do produto desenvolvido. Segundo PFLEEGER (2004)9 a qualidade pode é atendida por três modos diferentes: “qualidade do produto, qualidade do processo que resulta o produto e qualidade do produto no contexto do ambiente de negócios em que ele será desenvolvido. Geralmente a qualidade de um produto, decorre diretamente da qualidade do processo utilizado na produção dele. No entanto, há de se considerar que diferentes usuários têm intenções diferentes para o mesmo produto. Persiste agravante no mercado nacional, em que, em virtude da má qualidade dos processos de desenvolvimento, há necessidade de retrabalho. Mesmo assim, empresas entregam produtos com erros, fazendo com que elas não consigam atingir níveis de qualidade internacional, o que afeta a exportação de produtos de software. 9 PFLEEGER, 2004,8. 17 A partir disso, existem vários conceitos de diferentes autores sobre o que é a qualidade de um produto de software. Conforme Pressman (1995)10, a qualidade pode ser entendida como: Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido. Nessa definição o autor enfatiza três pontos importantes: Os requistos de softwares que são avaliados para assegurar a qualidade. Aos padrões que estabelecem a maneira como o software é desenvolvido. Aos requisitos implícitos que não são documentados Conforme as indústrias cada vez mais competitivas, a procura pela qualidade tem sido uma grande aflição para as organizações. Um software pode ser desenvolvido ou não com técnicas de engenharia de software. Para RODRIGUES (2008)11, os perigos em desenvolver software sem técnicas de engenharia de software, são as resultados adquiridos depois que o projeto é finalizado. Um software sem as técnicas de engenharia pode acometer a qualidade do produto levando ao insucesso e fracassos no desenvolvimento, consequentemente trazendo pontos negativos para a empresa. Hoje em dia não é mais permitido entregar produtos com baixa qualidade e corrigir erros e falhas após o produto ser fornecido ao cliente, quanto mais tarde os erros são encontrados, mais cara e a correção do produto. SOMMERVILLE (2003)12 constata que: Atingir um alto nível de qualidade de produto e serviço é o objetivo da maioria das organizações desenvolvedoras. Atualmente não e mais aceitável entregar produtos com baixa qualidade e reparar os problemas e as deficiências depois que os produtos foram entregue. A esse respeito, o software é igual a qualquer outro produto manufaturado, como carros, televisão e computadores. 10 PRESSMAN, 1995, p.724. 11 RODRIGUES, 2008, p.10. 12 SOMMERVILLE, 2003, p.458. 18 É necessário tomar precauções para que ao construir o produto sejam estabelecidos testes, práticas e procedimentos, visando assegurar que o perfil do produto seja de total qualidade e aceito pelo o cliente. Diante disso SOMMERVILLE (2003)13 afirma que é da responsabilidade dos gerentes em uma organização assegurar que o grau de qualidade do software seja alcançado. Eles precisam elaborar, programar e conferir os trabalhos para garantir que estejam sendo desenvolvidos conforme os critérios requeridos. Uma forma de validar a qualidade no processo de desenvolvimento é a conquista do certificado de qualidade. Certificações de qualidade são concedidas por organizações respeitadas no mercado e representa um grande diferencial para a empresa certificada dado o alto crescimento da concorrência no setor. Organizações que desenvolvem software de boa qualidade podem quase sempre oferecer um melhor produto a um preço mais elevado, devido ao investimento e as revisões feitas durante o processo de desenvolvimento. A melhoria dos processos de software é de suma importância para que erros sejam evitados, assim melhorando a qualidade dos produtos. Diante disso, é necessária a implantação de processos bem estabelecidos e seguidos por modelos de melhorias. HIRAMA (2012)14 acrescenta que para garantir a qualidade de um software, são necessário técnicas como verificação, validação, gerenciamento de configuração e qualidade. Para essas afirmações pode-se observar que a qualidade é um arranjo de fatores que altera de acordo com aplicações e requisitos de clientes. Um produto de software com boa qualidade pode garantir uma segurança na rede, disponibilidade nos serviços, grande rendimento e satisfação e confiança dos clientes. 2.1 SQA (Garantia da qualidade de Software) Um dos problemas encontrados durante o desenvolvimento do software são as revisões dos serviços. Encontrar pessoas experientes e comprometidas com o projeto é uma tarefa muito difícil. Os gerentes do projeto querem os melhores programadores para desenvolver seusprodutos, diante disso surgiu o SQA. 13 SOMMERVILLE, 2003, p.458. 14 HIRAMA, 2012, p.3. 19 Garantia de qualidade de software ou Software Quality Assurance (SQA), é um grupo formado por diferentes atividades e ações que objetivam qualidade no desenvolvimento do software. O SQA integra todo o processo de desenvolvimento do software, verificando se os padrões e processos estão seguidos corretamente, assim prevenindo que nenhum erro seja encontrado no final do projeto. Segundo PRESSMAN (1995)15 o grupo SQA atua como um representante do cliente. Isto é, os envolvidos no grupo observam o software sobre o mesmo ponto de vista do cliente. Existem algumas vantagens que um processo de software garante ao ser implantado por um grupo SQA: Melhoria na qualidade do processo. Remoção de defeitos no processo. Uma criação de um banco de dados com técnicas como: revisão, medição, auditorias e fatores de qualidade, etc. Monitoração e melhora de todo o processo em ação. Atividades de melhoria desde o inicio do projeto do software. Conforme PRESSMAN (1995)16 o SQA integra um conjunto de tarefas relacionadas a sete atividades: aplicação de métodos técnicos, revisões técnicas formais, afazeres de teste, aplicação de padrões, domínio de mudanças, medições e manutenção de documento e reportagem. Todas as atividades são ações que acontecem no decorrer do software, podendo ser representada por um conjunto de alteração de um serviço pra outro, combinação de dados ou modificação de localização. Com isso, o SQA estabelece métodos, técnicas e ferramentas que ajudam os programadores a desenvolver um software de total qualidade. Sendo assim, a principal função de um SQA, é averiguar se estão usando os métodos e padrões conforme os conhecimentos requeridos. PRESSMAN (1995)17 afirma “se existirem padrões formais (escritos), uma atividade SQA deve ser estabelecida para garantir que eles sejam seguidos”. 15 PRESSSMAN, 1995, p.734. 16 ibidem, idem, p.734. 17 ibidem, idem, p.734. 20 Os padrões são incluídos nos procedimentos ou aplicados durante o processo de desenvolvimento. Conforme SOMMERVILLE (2003)18 existem dois tipos de padrões que englobam o processo de garantia de qualidade de software: 1- Padrões de produto: São padrões que se aplicam ao produto de software em desenvolvimento. Eles incluem padrões de documentos, como a estrutura de requisitos a ser desenvolvido de requisitos a ser produzido; padrões de documentação, como um cabeçalho-padrão de comentário para uma definição de classe de objeto, e padrões de codificação, que definem como uma linguagem de programação deve ser utilizada. 2- Padrões de processo: São padrões que definem os processos a serem seguidos durante o desenvolvimento de software. Eles podem incluir definições de especificação, processos de projeto e validação, e uma descrição dos documentos que devem ser gerados no curso desses processos. Os padrões concedem uma estrutura em torno do qual o processo de garantia de qualidade pode ser implantado. Eles ajudam em termo de continuidade, quando um projeto é começado por uma pessoa e assumido e seguido por outra. Eles abrangem as melhores práticas de controle de qualidade, que simplesmente assegura a capacidade e valor no produto de software da organização. Segundo os autores PRESSMAN e MAXIM (2016)19, os padrões do CMMI e ISSO 9000, são os mais usados. Cada um propõe uma sintaxe e uma semântica, que leva as práticas de engenharia de software que melhoram a qualidade do produto. Por fim, todas as etapas do software devem ser agregadas com atividades que propõe atingir qualidade dos requisitos, qualidade do projeto, qualidade do código e eficácia do controle de qualidade. 2.2 SEPG (Software Engineering Process Group) O SEPG (Software Engineering Process Group) estabelece um grupo que planeja e acompanha todas as tarefas do projeto de melhoria de capacidade, com apoio da alta administração. Esses indivíduos são responsáveis por garantir que todo o processo de implantação do modelo flua de maneira adequada, envolvendo as pessoas para o entendimento dos benefícios de trabalhar com qualidade, alocando os recursos necessários para a melhoria dos processos. Eles realizam 18 SOMMERVILLE, 2003, p.460-461. 19 PRESSMAN e MAXIM, 2016, p.452. 21 avaliações da capacidade, desenvolvem planos para implementar melhorias necessárias, coordenam a implementação desses planos e medem a eficácia desses esforços. O grupo de processos de engenharia de software é uma força central para a melhoria de processos. O grupo mantém a visão geral dos esforços atuais e geralmente se concentra na definição de prioridade, aprovação, desenvolvimento, implantação e acompanhamento do conjunto de técnicas e processos utilizados pela organização. Os membros do SEPG são desenvolvedores de software e têm o seu comprometimento assegurado através de autorização do gerente responsável, que aloca no mínimo 2 horas semanal para o trabalho com processo. Os membros promovem a colaboração entre todos na organização que estejam envolvidos com a melhoria do processo. O SEPG é envolvido com algumas atividades de melhoria de processos CMMI, tais como: Planejamento das atividades de melhoria de processos. Desenvolvimento e valorização do SGQ (Sistema de gestão da qualidade). Avaliação e sugestões de melhoria de processo da organização ou das entidades externas. Preparação e atualização do tamanho e equipe de projeto. O grupo estabelece metas organizacionais de qualidade. Facilita a criação e manutenção de definições de processo, em colaboração com os gerentes e pessoal de engenharia. Mantém um banco de dados processo. O grupo SEPG tem enfoque de atuação em organizar treinamentos, acompanhar, monitorar e relatar esforços de melhoria de processos. Todos os métodos devem estar definidos na organização, e deve ser monitorado, gerenciado e atualizado pela alta direção. 22 Dentre suas principais funções e atividades, podem-se destacar: Fornecer orientação para uso de dados históricos Identificação de um conjunto de padrão de produtos de trabalho de software das áreas envolvidas. Medir, informar e divulgar as atividades de desenvolvimento e de melhoria de processo de software no âmbito da organização. Em resumo, o SEPG contribui para varias funções e atuações e mantém e favorece todo controle das melhores ações de melhoria das áreas envolvidas. 3 MODELOS DE MATURIDADE Devido ao insucesso dos projetos, as organizações desenvolvedoras vêm originando procedimentos, ferramentas e paradigmas para garantir a melhoria da qualidade nos processos organizacionais. Os paradigmas são utilizados para habilitar a capacidade dos processos, localizar oportunidades de melhoria de produtividade e monitorar as ações de qualidade e redução de custo. Um processo de desenvolvimento de software envolve um conjunto de atividades, práticas e métodos que uma equipe utiliza para manter o software e produtos associados. O grau de maturidade e adquirido quando uma empresa utiliza as metodologias de processos nos modelos implantados. Esses modelos fornecem um framework de soluções para analise, definição, implantação e melhoria de processos. Segundo a Associação para Promoção da Excelência do Software Brasileiro – SOFTEX (2012)20, para produzir um softwareconcorrido a nível nacional e internacional, é importante que as organizações coloquem competência nos seus processos e um grupo de qualidade que tomem decisões estratégicas conforme os padrões de qualidade internacional. A melhoria nos processos fornece a organização uma mudança no modo de desenvolvimento conforme o mundo em grande concorrência. 20 SOFLEX, 2012, p.6. 23 São feitas avaliações de qualidade como forma de aprimorar os processos, avaliando a qualidade do produto e a aquisição para escolha de software de melhor qualidade. A avaliação de verificação envolve: Capacidade: Uma avaliação feita para analisar a capacidade de um processo, comparando a qualidade de uso com as exigências do produto. Permite determinar resultado para os futuros projetos. Desempenho: Avaliação feita para analisar o desempenho do processo de acordo com o tempo de uso. Maturidade: Uma avaliação feita para testar a qualidade de crescimento de um processo, avaliando o mesmo para verificar se está de acordo com os objetivos da organização. Em uma organização, os modelos de maturidade e capacidade medem a habilidade técnica, gerencial e a competência que a organização possui em desenvolver software de boa qualidade, dentro do prazo e custos razoáveis (FILHO, 2000)21. A identificação de um modelo para uma organização se baseia nos procedimentos de cada modelo de acordo com os objetivos procurados. Com isso, a existência dos modelos é fundamental para organizações alcançar um resultado positivo na produção do software. 3.1 CMM (CAPABILITY MATURITY MODEL) O CMM trata-se de um modelo de maturidade e capacidade composto por elementos básicos de processos para garantia de qualidade, e descreve um caminho evolutivo de processos imaturos a processos maduros. Foi desenvolvido pelo SEI (Software Engineering Institute)22 da Universidade Carnegie Mellon. A principal missão do modelo foi atender o DOD (Departamento de Defesa dos Estados Unidos) com ferramentas de capacitação para avaliar seus grandes fornecedores. Publicado em 1992, o CMM dispõe das melhores práticas de maturidade e capacidade e fornece uma estrutura para a organização estabelecer as 21 FILHO, 2000, p.22 22 Instituto fundado pelo Departamento de defesa dos Estados Unidos, cuja missão é a transferência de tecnologia de software (SOMMERVILLE, 2003, p.485). 24 preferências de melhorias dentro dos padrões de qualidade (SOMMERVILLE, 2003)23. O modelo CMM pode ser aplicado por dois métodos diferentes: pelos clientes para poder identificar o nível de qualidade de seus fornecedores e pelos desenvolvedores para analisar a sua capacidade de esclarecer e definir melhorias. Através da avaliação da maturidade é possível realizar mudanças, auxiliar o gerenciamento e melhorar a qualidade do software (PFLEEGER, 2004)24. Nas organizações desenvolvedoras, existe uma grande procura pela qualidade e com isso ocorre alto investimento financeiro para melhorar seus processos. A implantação do modelo assegura benefícios no desenvolvimento do código, controle de prazos, quitação de custos e melhoria de redução de riscos. Segundo SCHACH (2010)25, o aperfeiçoamento do processo induz mudanças incrementais associado em cinco níveis de maturidade, que vai aumentando conforme os processos vão se melhorando em pequenos passos revolucionários, garantindo o aumento dos níveis mais alto do modelo. A figura 2 apresenta os níveis oferecidos no modelo CMM, onde os cinco níveis estabelecem um conjunto de ações que permitem a empresa subir no patamar de melhoria dos processos. Figura 2: Modelo de Maturidade de Capacitação do SEI Fonte: SOMMERVILLE, 2003, p.486 23 SOMMERVILLE, 2003, p. 485. 24 PFLEEGER, 2004, p.444. 25 SCHACH, 2010, p.92. 25 Como demonstra a figura 2, o nível mais alto corresponde o maior rendimento e qualidade da empresa. Cada nível de maturidade, com exceção do primeiro, agrupa um conjunto de áreas-chave de processo, chamados de KPA – Key Process Areas. Cada área-chave é baseada em práticas-chave (Key Practices), que são incluídas no modelo para alcance de melhorias e metas. Conforme SOMMERVILLE (2003)26, a melhoria dos processos deve se apropriar de estabelecer os processos- chave e não atingir outro nível do modelo. Para que uma organização atinja um nível de maturidade satisfatório é necessário seguir as práticas do processo para subir a um determinado nível de maturidade. 3.2 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) Segundo SOMMERVILLE (2003)27, com base na experiência adquirida com o modelo CMM, o SEI desenvolveu um novo modelo de maturidade e capacitação chamado CMMI. O modelo integra todos os aspectos de processo de software, de engenharia de sistemas e definição de produtos. O CMMI surgiu como forma de estabelecer diferentes modelos, em um único e completo modelo, preservando investimentos, e reduzindo custos de treinamento de melhorias. Sua principal qualidade é assegurar a melhoria contínua dos processos em duas versões diferentes – contínua e estagiada. Dentre dos modelos existentes da SEI, os que mais atribuíram valor são: Software Acquisition CMM (AS-CMM) Systems Enginnering CMM (SE-CMM) Integrated Product Development CMM (IPD-CMM) People CMM (P-CMM) O CMMI foi baseado nas melhores práticas para desenvolvimento, aquisição e manutenção de softwares, além disso, dispõe de ações apropriadas para todos os envolvidos no projeto. A versão atual do modelo é a (versão 1.3) que apresenta três atuações: 26 SOMERVILLE, 2003, p.487. 27 ibidem, 2003, p.489. 26 CMMI-ACQ- Voltado para as atividades de aquisição de produtos e prestação de serviços. Fornece uma aplicação para atender as necessidades dos clientes e usuários finais. CMMI-DEV- Modelo voltado para desenvolver produtos. Contém práticas de Gestão de processos, engenharia de sistemas, engenharia de softwares e entre outros. CMMI-SVC- Modelo voltado para conferir a qualidade dos processos e prestação de serviços. Contém práticas de engenharia de aquisição, gestão de processos e serviços. O CMMI é uma grande ferramenta que fornece estrutura para a motivação, reconhecimento, padronização e melhorias. Foi desenvolvido para avaliar a capacitação de empresas de grande porte, de longo tempo de duração, com complexas interfaces com o hardware e outros sistemas de softwares. O modelo mede a maturidade e a capacitação dos processos de acordo com cada nível. À medida que o nível evolui, a capacidade de melhorias dos processos é percebida pela organização (SOMMERVILLE, 2003)28. Segundo HIRAMA (2012)29 “o CMMI tem reconhecimento mundial, e no Brasil existem muitas empresas que possuem certificações baseadas nesse modelo”. Utilizando-se do modelo CMMI, uma organização observa melhora logo no nível 2, e neste que são apresentados práticas em gerenciamento de requisitos e controle do progresso do software. No entanto, pode se perceber que nos dias de hoje a melhoria de processos com a utilização do CMMI é vista como um diferencial competitivo. a) Objetivos do modelo Além de garantir a melhoria nos processos de softwares, o CMMI apresenta os seguintes objetivos: Reduzir repetição de processos. Disponibilidade de recursos.28 SOMMERVILLE, 2003, p.487. 29 HIRAMA, 2012, p.4. 27 Aumentar o foco das atividades dentro das organizações. Auxiliar no gerenciamento de mudanças. Associar os processos existentes. Atingir as metas estipuladas pela empresa. Garantir que os processos sejam seguidos conforme a norma ISO 15504. Aumentar a capacitação dos softwares. Assegurar ferramentas de qualidade para o Departamento de Defesa dos Estados Unidos. b) Vantagens do modelo O CMMI é um modelo de certificado internacional e a cada ano vem se tornando uma marca de registro no mercado. Empresas como a Microsoft utiliza o modelo como forma de obter ganhos, de maneira estratégica para exportações para outros países. Uma das principais vantagens do modelo CMMI, e a possibilidade de monitoramento dos processos, ou seja, a organização consegue controlar seus processos, verificar melhorias, e possíveis conclusões sobre o projeto. c) Desvantagens do modelo O modelo possui alto custo com a implantação e manutenção do processo, além da demora. Dependendo do nível de complexidade de uma organização, o custo visa em torno de duzentos mil reais e leva em média 18 meses a 3 anos. Diante disso, SCHACH (2010)30 afirma que uma organização pode levar em média 3 a 5 anos para elevar o 1º nível para o 2° nível . Ainda segundo o autor, isso é reflexo da grande dificuldade que é adicionar uma abordagem metódica em uma organização que até então funcionou puramente em termos de medidas relativas e sem planejamento. Desse modo, empresas de pequeno porte possuem uma dificuldade em adotar o CMMI de acordo com o valor de investimento alto. Uma das desvantagens desse modelo é em relação às praticas utilizadas. Muitas dessas práticas são utilizadas sem necessidade, principalmente em projetos menores, que na maioria dos casos não possuiria custo para a implantação. 30 SCHACH, 2010, p.94 e 95. 28 3.2.1 Representação dos Modelos A arquitetura do modelo CMMI pode ser representada por duas diferentes versões: estagiada (como o antigo modelo CMM) e contínua (classifica cada área de processo segundo a norma ISO/IEC 15504). Estas duas versões proporcionam a organização aplicar diversas maneiras para melhoria conforme sua necessidade. Os níveis de maturidade estabelecem um meio de indicar a evolução dos processos da organização, caracterizando estágios de melhoria conforme a qualidade é obtida. “O nível de maturidade em que uma organização se encontra, permite prever o seu desempenho futuro ao executar um ou mais processos” (SOFLEX, 2012)31. 3.2.1.1 Representação por Estágio Essa representação se afigura bastante ao CMM com cinco níveis de maturidade direcionados aos negócios da organização. Na representação em níveis, as práticas são caracterizadas pelos atributos: Compromisso para execução (práticas que garantem que o processo seja estabelecido e apoiado); Habilidade para execução (práticas que criam condições para que o processo seja estabelecido completamente); Atividade para execução (práticas que implementam diretamente o processo), controle e verificação de implementação. A ordem de melhoria é seguida em dependência aos anteriores, sendo assim, o aprimoramento de cada nível serve como base para o outro nível. Cada nível de maturidade serve como base para o próximo nível, em uma sequência bem detalhada de melhorias de processos, que facilita a comparação de processos entre diferentes organizações. A implantação em estágios garante à organização um grande investimento financeiro, visando assegurar uma mudança na figura organizacional. 31 SOFLEX, 2012, p.17. 29 1- Inicial: A organização não oferece um ambiente para desenvolvimento. Esse nível e visto como negativo, pois não imaturidade no setor produtivo. 2- Gerenciado: Os processos são repedidos conforme os anteriores. São empregados nesse nível sete áreas-chave como: controle de requisitos, revisões de processos, medição e análises. Os stakeholders32 são envolvidos durante o desenvolvimento para melhorar e satisfazer os requisitos dos clientes. Conforme PFLEEGER (2004)33, a melhoria dos processos gerenciados levam a melhorias dos processos definidos, “em que atividades de gerenciamento e de engenharia, são documentadas, padronizadas e integradas, o resultado é um processo padrão para todos na organização”. 3- Definido: Os processos são repedidos por todos os projetos de software da organização. São empregados nesse nível: ações de integração, Validação e Verificação de produto; 4- Quantitativamente Gerenciado: Nesse nível, a coleta de dados do processo é feita de forma quantitativa. São empregados nesse nível duas áreas-chave de processo: gerenciamento e desempenho do processo. 5- Otimizado: Ações de melhoria, com implantações de mudanças no processo da organização. Conforme PFLEEGER (2004)34, “o nível mais desejado é o otimizado, em que o feedback35 quantitativo é incorporado no processo para produzir melhorias contínuas no processo [...]”. A razão da divisão em estágios, está em possibilitar as organizações implementar e avaliar de forma mais apropriada os processos desenvolvidos. A facilidade de se efetuar avaliações considerando mais níveis de maturidade, é a garantia da transparência qualidade dos processos em tempos mais curtos. Uma empresa no primeiro nível, não dá garantia de prazo, custo ou funcionalidade. No segundo nível, a empresa já consegue produzir bons softwares, com custo previsível e prazo estimado. No terceiro, a empresa já garante um excelente nível de qualidade, tanto no produto quanto no processo de 32 Conjunto de pessoas que de alguma influencia no sucesso do projeto. 33 PFLEEGER, 2004, p.446. 34 Ibidem, 2004, p.446. 35 Resultados baseados em números. 30 desenvolvimento como um todo. Atualmente, no mundo, não há muitas empresas que tenham chegado aos níveis 4 e 5. A estrutura do modelo CMMI representação por estágio é apresentado na figura abaixo: Figura 3: Estrutura de representação por estágio Fonte: O autor Como ilustrado na figura 3, os níveis maturidade organizam as áreas de processo. Dentro das áreas de processo existem objetos genéricos e específicos, assim como praticas genéricas e especificas. Essa representação foca as melhores práticas que a organização poderá utilizar, para melhorar os processos das áreas de processo que se encontram no nível de maturidade, escolhido para alcançar. 3.2.1.2 Representação contínua Define uma sequência de melhorias para atender os objetivos de negócio da organização, podendo classificar a capacidade a cada nível de processo. O perfil da capacidade dos processos é seguido por cada nível – Capability Levels. Com isso, uma organização pode trabalhar em outras áreas de atuação de acordo com sua estratégia de negócio. A estrutura do modelo CMMI representação contínua é representada na figura abaixo: 31 Figura 4: Estrutura de representação contínua Fonte: O autor Como ilustrado na figura 4, os objetivos específicos organizam praticas especificas e os objetivos genéricos organizam praticas genéricas. Cada pratica especifica e genérica corresponde a um nível de capacidade. O nível 1 tem a ver com a implementação dos objetivos e práticas especificas da área de processo em trabalho. Os objetivose as praticas especificas aplicam-se individualmente as áreas de processo, enquanto, os objetivos e as praticas genéricas se aplicam a todas as áreas de processo em análise. Os objetivos e as praticas genéricas definem a sequencia dos níveis de capacidade que representam melhorias na implementação e efetividade de todos os processos que foram escolhidos para melhoria. Essa representação apresenta 25 áreas de processos, que são inseridas em 4 grupos distintos, que são estabelecidos em seis níveis de capacidade e são medidos pelo atendimento de metas específicas e genéricas: 0- Incompleto - Ad-hoc36: Processo não executado ou realizado. 1- Executado: O projeto é planejado e executado de acordo com cada projeto. Engloba ações de inovação, desempenho e treinamento da organização. 2- Gerenciado: A área de processo é executada de acordo com as metas especificas. Envolve ferramentas, métodos e procedimentos. São incluídas ações de planejamento, monitoração e gerenciamento do projeto. 3- Definido: O processo fornece informações de melhoria, de acordo com o processo padrão da organização. 36 Processo de software em construção. 32 4- Gerenciado quantitativamente37: Os processos são baseados em indicadores e outros métodos quantitativos. 5- Otimizado: Adaptado para atender os objetivos atuais de negócios. O foco nesse nível e a melhoria dos processos, com ações baseadas em métricas e ferramentas inovadoras. O modelo de representação contínua é indicado, quando se deseja comparação com processos de outras organizações assegurando máxima flexibilidade e processos mais maduros. Através do nível de maturidade, as empresas garantem certificação e reconhecimento de maturidade a nível internacional. O modelo de maturidade é uma importante contribuição, mais não deve ser tomado como um modelo definitivo para capacitação de todos os processos. Esse modelo foi desenvolvido para capacitar os processos de empresas que desenvolvem software de defesa. O modelo vem se transformando em um padrão mundial para avaliação de melhoria de processos e se tornando uma grande ferramenta de competitividade entre diferentes organizações (SOMMERVILLE, 2003)38. 3.2.2 Áreas-chave de processo (Key Process Areas ou KPAs) Os níveis de maturidade segue um estágio de melhoria nos processos, ou seja, a partir de um caminho evolutivo a qualidade nos processos organizacionais e alcançada. Todo nível de maturidade é formado por um conjunto de áreas de processos onde são explorados os processos essenciais. A capacidade de cada processo é interpretada por uma soma de atributos conforme os resultados alcançados. Cada nível de maturidade, exceto o nível 1, é composto por varias áreas- chave de processo que instrui quais áreas que uma organização deve focalizar para melhorar seu processo de software. A tabela abaixo apresenta todas as áreas de processo organizadas nos cinco níveis de maturidade e capacidade do CMMI: 37 Questionários alternativos com resultados numéricos. 38 SOMMERVILLE, 2003, p.487- 490. 33 Nível de Maturidade Áreas-Chave de Processo 1. Nível Inicial: Não contém áreas-chave de processo. 2. Nível Repetível: Gerenciamento de projeto básico Gerenciamento das necessidades, Gerenciamento de projeto de software, Acompanhamento e supervisão de projetos de software, Gerenciamento terceirizado de software e Garantia de Qualidade de Software (SQA) 3. Nível Definido: Definição de processos Foco nos Processos Organizacionais, Definição dos Processos da Organização, Gerenciamento de Software Integrado, Engenharia de Projeto de Software, Coordenação entre os grupos e Revisões pontuais. 4. Nível Gerenciado: Medição de processos Gerenciamento de processos quantitativos e Gerenciamento da qualidade do software. 5. Nível Otimizado: Controle de processos Prevenção de Defeito, Gerenciamento de Mudança de Tecnologia e Gerenciamento de Mudança de Processos. Tabela 1: Áreas de processo. Fonte: SCHACH, 2010, p.92 Esses cinco níveis de maturidades são sintetizados na tabela 1, apresenta as áreas fundamentais associadas a cada nível de maturidade. Todas as áreas de processo são comuns nas duas representações do modelo CMMI. Para que uma empresa possa qualificar em um determinado nível de maturidade, ela precisa estar realizando os processos relacionados às áreas-chave daquele determinado nível. A forma de atingir as metas de uma área-chave de processo pode diferir entre projetos, de acordo com as diferenças de domínios de aplicação ou de ambientes. Todavia, todas as metas de uma área-chave de processo devem ser atingidas para que uma organização satisfaça essa área-chave. Quando as metas de uma área- chave são cumpridas de maneira continuada em um projeto, a organização pode ser considerada como tendo institucionalizado a capacidade do processo caracterizada por essa área-chave. 3.2.3 Características Comuns e Práticas-chave As características comuns são itens a serem observados para que se possa verificar a implementação e institucionalização de cada área-chave de processo. Elas podem indicar se a área-chave de processo é eficiente, repetível e duradoura. 34 Toda área-chave de processo (KPA) é constituída por um grupo de atividades relacionadas à área, que quando executadas coletivamente, atingem um conjunto de objetivos e metas consideradas importantes para a melhoria significativa do processo. Cada área é composta por práticas genéricas e específicas, que são essenciais para a implantação do modelo. As práticas especificam o que deve ser cumprido, exigindo documentos, treinamentos ou políticas definidas para as atividades, mas nunca especificam como elas devem ser implementadas. No geral, a avaliação oficial do SEI é bastante abrangente, cara, e certamente a mais traumática. Por isto dificilmente deve ser utilizada como pontapé inicial da implantação do modelo. O primeiro ciclo de análise/planejamento/ação tem algumas características especiais. É nele que se cometem mais erros e se criam mais soluções. Um método abrangente, mas ao mesmo tempo flexível pode reduzir os traumas e liberar a criatividade, e maximizar os resultados obtidos no trabalho. 3.3 MPS.BR (MELHORIA DO PROCESSO DE SOFTWARE) Conforme o guia SOFTEX (2012)39, o MPS. BR é um modelo direcionado para o ramo de qualidade de software, coordenado pela Associação para Promoção da Excelência do Software Brasileiro – SOFTEX, iniciado em dezembro de 2003. O modelo foi desenvolvido com intuito de diminuir o retrabalho, atender as necessidades de negócio e para garantir a qualidade nos processos de software das pequenas e médias empresas Brasileiras. Uma de suas características é poder disponibilizar mais níveis de maturidade para as organizações, e seu valor de certificação se comparado a outros modelos de qualidade. Isto se justifica, devido ao custo financeiro que o CMMI exerce o que torna o modelo mais indicado às grandes organizações. O apoio técnico para a o desenvolvimento do MPS. BR foi descrito segundo as normas ISO/IEC 12207 e ISO/IEC 15504, e o modelo CMMI. Dessa forma, todos os processos em desenvolvimento serão seguidos conforme as normas. O MPS. BR baseia-se nos conceitos de maturidade e capacidade de processo para avaliação e melhoria de produtividade de software. 39 SOFLEX, 2012, p. 4. 35 Dentrodesse contexto, atualmente o modelo está dividido em cinco elementos: (MR-MPS-SW) - Modelo de referência MPS para melhoria de processo de software. (MR-MPS-SV) - Modelo de referência MPS para serviços. (MA-MPS) - Método de avaliação de requisitos para melhoria do modelo. (MRMPS-RH) - Modelo de referência MPS para gestão de pessoas. (MN-MPS) - Modelo com regras de negócios, para atender as empresas de grande porte40. Todos esses modelos são divididos em níveis de maturidade garantem capacidade nos processos organizacionais. 3.3.1 Níveis de Maturidade O modelo é dividido por uma representação por estágio, em sete níveis maturidade, que visa analise sobre as pequenas empresas, bem como melhorias nos processos organizacionais. A - Em Otimização B - Gerenciado Quantitativamente C - Definido D - Largamente Definido E - Parcialmente Definido F – Gerenciado G - Parcialmente Gerenciado A sequência começa no nível G de pior qualidade e finaliza no nível A, onde se obtém a melhor qualidade no processo. Para cada um desses níveis é atribuído um conjunto de processos que indicam onde a organização deve colocar total empenho de melhoria. O crescimento de cada nível no modelo MPS se obtêm, quando são atendidos os objetivos dos processos e dos atributos de processo estabelecidos para um determinado nível. Os modelos CMMI e MPS.BR possui diversos aspectos em comum durante as fases de implantação, porem o foco de atuação dos modelos são diferentes um 40 SOFLEX, 2012, p.6. 36 do outro. O MPS.BR foi criado em função das pequenas empresas, já o CMMI tem o foco as empresas de grande porte. Contudo, apesar das diferenças, ambos requerem que procedimentos da parte alta das empresas, alem de que as organizações precisam estar dispostas a investir tempo, dinheiro e infra-estrutura para melhorias dos produtos e serviços. Para alcance das metas e necessário um treinamento para os profissionais, e reformulação e adequação as mudanças conforme os processos internos e externos. As médias e pequenas empresas adotam o MPS.BR com o objetivo de conseguir alcançar uma padronização e qualidade no processo com mais velocidade e de baixo custo. No geral, os modelos de melhoria de processo de software, atende as necessidades das organizações com modelos baseados em níveis de habilidade e capacidade, visando alcançar os objetivos atuais e futuros. A representação por estágios fornece melhorias de processos baseando-se em um roteiro por vez. Nesse sentido, o uso de modelos ajuda o processo de construção de softwares garantindo a qualidade no produto e no serviço. 37 CAPÍTULO 4 – APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE CASO COM MODELO CMMI 4.1 Tipo de pesquisa Nessa parte, será apresentado o estudo de caso e as principais atividades que foram utilizadas para conseguir reunir todos os dados obtidos no questionário. Do ponto de vista da forma de abordagem, o método de pesquisa denominado nesse trabalho, e visto como pesquisa qualitativa, pois as dificuldades apresentada pelas empresas de aplicação da qualidade em seus processos não pode ser descrita em números, por ser de caráter descritivo (problema não é quantificado, mas definido). 4.2 Processos metodológicos A pesquisa foi realiza nos meses de Novembro e Dezembro de 2016. Foi elaborado um questionário com perguntas que apresentavam a finalidade de identificar os resultados esperados na melhoria do processo de acordo com o modelo CMMI, conforme (Anexo A). O questionário foi formado de acordo com dados obtidos em links que abordam o tema e monografias que já foram publicadas. Com base nesses dados, foi possível comparar as opiniões que as empresas apresentam em relação ao modelo. O questionário de maturidade não foi projetado para ser usado para ser usado como instrumento de avaliação para conhecimento da organização alvo. A primeira pergunta do questionário visou identificar dados sobre o entrevistado e a empresa que ele atua. Em seguida, dados sobre quantidade de funcionários dentro da empresa. Conforme as perguntas o entrevistado poderia obter um melhor entendimento em relação ao modelo, pois 3 perguntas avaliava a importância do modelo na melhoria dos processos de software. Para realizar o estudo proposto foram acompanhados e investigados os seguintes procedimentos: - realização de diagnóstico da empresa para a elaboração do planejamento das atividades e identificação do estado atual da empresa. 38 - elaboração de um Plano de Ação, onde foram descritas as atividades para a execução do projeto, a estimativa de duração e um cronograma. - O questionário foi encaminhado aos responsáveis nas empresas pelo setor de Engenharia e Gerência de Software e de Qualidade. - Para desenvolvimento do instrumento de coleta e da coleta de dados usou- se uma ferramenta web gratuita de formulários disponibilizada pela organização Google. 4.3 Etapas do questionário De acordo com os dados coletados foram gerados gráficos para melhor exposição da pesquisa, sendo que o questionário começa perguntando dados como nome, email e nome da empresa do entrevistado. Em relação ao tamanho da empresa, 75% dos entrevistados disseram que a empresa possui pequeno porte, enquanto 25% assinalaram que a empresa e de médio porte, conforme Figura 5. Figura 5: Pergunta número 04 do questionário ao usuário Fonte: O autor. Como mostra a Figura 5, no total de quatro empresas pesquisadas, três são de pequeno porte. Em relação ao tempo de existência da empresa: 50% dos usuários disseram que a empresa possui menos de 5 anos de existência. 25% opinaram que a empresa possui entre 5 a 10 anos e outros 25% disseram maior que 10 anos, como demonstrado da Figura 6. 39 Figura 6: Pergunta número 05 do questionário ao usuário Fonte: O autor. Levando em consideração ao número de clientes: Devido à forte presença de clientes, 50% disseram entre 100 a 300, enquanto houve um empate entre menor que 100 e 50 a 100, de acordo com a Figura 7. Figura 7: Pergunta número 06 do questionário ao usuário Fonte: O autor. Levando em consideração a posição do cargo do entrevistado: 70% disseram que não trabalham em nenhum dos cargos informados no questionário e outros 25% disseram desenvolvedor ou analista de suporte, conforme Figura 8. 40 Figura 8: Pergunta número 07 do questionário ao usuário Fonte: O autor. Em relação ao relacionamento do entrevistado aos membros da empresa: 75% dos usuários entrevistados acreditam que o relacionamento com os membros é bom, enquanto os 25% considera regular, como amostrado na Figura 9. Figura 9: Pergunta número 08 do questionário ao usuário Fonte: O autor A empresa já adotou algum modelo ou padrão de qualidade? Quanto ao modelo de melhoria de processos, 75% dos entrevistados alegaram que as empresas não adotam nenhum e 25% disseram que sim, como demonstrado na Figura 10. 41 Figura 10: Pergunta número 09 do questionário ao usuário Fonte: O autor. Em relação ao CMMI: Foi questionado aos usuários se havia interesse pelas empresas em adotar o modelo CMMI futuramente, e 50% alegaram que sim, e 50% não possuam interesse, como apresentado na Figura 11. Figura 11: Pergunta número 10 do questionário ao usuário Fonte: O autor.Em relação aos benefícios com a implantação do CMMI: Ao questionar a respeito do modelo CMMI, e as benefícios que se esperam em optar em implantar um modelo de melhoria nos processos organizacionais, 50% disseram que esperam por todas as opções, 25% afirmaram integração de sistemas e 25% projetos dentro do prazo, conforme apresentado na Figura 12. 42 Figura 12: Pergunta número 11 do questionário ao usuário Fonte: O autor. Em relação aos desempenhos esperados pelo modelo CMMI: 75% dos entrevistados disseram que o modelo é muito importante, pois seu reconhecimento é reconhecido internacionalmente e outros 25% disseram que baixa, pois o principal objetivo é apenas a melhoria dos processos, apresentado no gráfico da Figura 13. Figura 13: Pergunta número 12 do questionário ao usuário Fonte: O autor. 43 4.4 Elaboração do plano de ação Com base nos resultados encontrados no questionário e visando uma melhor condução das atividades relacionadas ao modelo CMMI, foi elaborado um plano de ação, ou seja, uma estratégia, para preparar a organização. O plano de ação identifica quais as ações específicas e os recursos necessários para a implantação das melhorias do processo de software. Geralmente, é incluída na definição do escopo, dando inicio a documentação do software. Foram identificados os seguintes problemas: Falta de comunicação entre os membros da equipe; Resistência à mudança na cultura organizacional da empresa; Procedimentos e práticas que ainda não eram documentadas; Falta de conhecimento em relação ao modelo CMMI. Para melhor alcançar sucesso no plano, é preciso boas políticas e procedimentos. A organização deve estar segura dos benefícios esperados com o modelo, especialmente no inicio devido aos custos. O problema é encontrar técnicas e métodos de acordo com os níveis de maturidade dos processos, diferente expectativa da gerencia e treinamento. 4.5 Soluções encontradas Para melhor solucionar os problemas em adequação ao modelo nas organizações, seria importante a colaboração das empresas em contratar uma equipe adequada, como SEPG, para garantir o controle nos processos de software e reestruturar as equipes em busca de melhor formação. É necessário garantir integração aos procedimentos. Um dos defeitos de se possuir diversas iniciativas de melhoria e a geração de um conjunto de procedimentos incompatíveis. Outras soluções encontradas: Programas de medição; Programas de treinamentos. 44 4.6 Resultados esperados com a Implantação do CMMI Existe a necessidade de modelar um plano de melhoria de qualidade de processo de desenvolvimento de software. Dentre os planos existentes, foi escolhido o CMMI por se tratar de um dos melhores modelos do mercado. Segundo PRESSMAN (1995)41, o software tornou-se elemento chave de evolução, mais durante as ultimas quatro décadas, com a história da ‘programação’, criaram um conjunto de problemas que persistem ate os dias de hoje. A falta de definição de seus processos de desenvolvimento de software, e também a falta de uso de uma padronização de documentação e metodologia de controle, ocasionou um quadro considerado preocupante: Aumento na manutenção de projetos finalizados; Novos projetos entravam em produção sem nenhum controle do escopo; Dificuldade no cumprimento de contratos com os clientes, devido aos contratos serem mal definidos; Dificuldade em realizar orçamento de novos; Projetos, devido à grande variação de custos; Dificuldade na definição e cumprimento de cronogramas; Dificuldade em controlar versões de sistemas e manter versões estáveis; Mudanças nos requisitos sem controle e gerenciamento; Falta de padronização e organização dos documentos. A análise realizada nos processos existentes nas empresas, comparando com os padrões de desenvolvimento propostos pelo modelo internacional CMMI, poderá contribuir para a tomada de decisão, no que diz respeito à implantação completa do projeto de melhoria de processos de software na empresa. Segundo todo o estudo realizado e com base no ROI (Return on Investiment – Retorno de Investimento), foi utilizado uma comparação usando um percentual, dando inicio as iniciativas do modelo de melhorias de processos CMMI. Segue os dados na tabela abaixo: 41 PRESSMAN, 1995, 48. 45 Desempenho Média de melhoria Custo 34% Cronograma 50% Produtividade 61% Qualidade 48% Satisfação 14% ROI 4,0 :1 Tabela 2: Resultados do desempenho CMMI Fonte: O autor Estes questionamentos buscam compreender quais dados precisos sobre a implantação do modelo utilizado pelas empresas. Foi gerada uma tabela exposição dos resultados. Segundo os dados, uma organização apresenta 61% de produtividade nos seus processos, e dependendo do nível financeiro da empresa, uma empresa faz um investimento de 34% com a espera de receber 40% em cima do valor investido. Com isso, pode-se concretizar que o intuito do modelo, e ajudar em todas as decisões das empresas, com garantia de um retornou percentual ao que foi investido, e que se espera para os próximos anos muitas organizações com certificação do modelo pelo o Brasil. 46 CONSIDERAÇÕES FINAIS A qualidade é a principal finalidade das empresas desenvolvedoras de software nos dias de hoje. A maturidade é uma meta que só é atingida de forma sucessiva e pode significar também, que a organização está perfeitamente bem para gerenciar seus projetos, isto é, fazê-la de forma regulamentada. Essa dissertação visou uma pesquisa das diferentes metodologias existentes na área de qualidade dos processos de desenvolvimento de software. Com isso, foi realizada uma análise das empresas através de um questionário para saber sobre o posicionamento dentro das empresas, para que então, fosse possível descobrir suas principais características, como visão estratégica e atividades importantes. Diante disso, iniciou-se uma avaliação das empresas, o que permitiu um diagnóstico sobre a situação gradativa, o que serviu como base para elaboração do plano proposto. Particularmente para empresas onde o produto principal e o desenvolvimento de software seriam necessários à implantação do CMMI, e o conhecimento sobre o modelo. A não aplicação torna-se uma limitação para o resultado deste trabalho, pois não é possível afirmar a sua aplicabilidade. Apesar da dificuldade de se obter um numero maior de empresas, pode se ter mostrado um método mais formal, tirando a conclusão sobre a qualidade e a necessidade das mesmas. Contudo, a presente dissertação pretendeu dar a conhecer de uma forma detalhada e especifica as características, e os principais benefícios e limitações que esse modelo CMMI oferece, para as soluções dos objetivos da empresa. A produção deste trabalho pôde proporcionar o conhecimento da prática do modelo. As empresas, no geral, demonstram bastante interesse em qualidade de processos de software para garantir concorrência no mercado e mostram-se dedicadas de alguma forma na busca de uma certificação em qualidade. Umas das grandes dificuldades constatadas destas organizações são de como implantar certos quesitos de qualidade e adaptá-los a sua empresa Pode-se concluir que os modelos de qualidade propõem as melhores ações de garantia de qualidade, e que através douso as organizações desenvolvem os melhores processos a fim de atingir um melhor produto do mercado. 47 REFERÊNCIAS CAMPOS, Fábio Martinho. Qualidade, qualidade de software e garantia da qualidade de software são as mesmas coisas? 2013. Disponível em: < http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e- garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx > Acesso em: 21 Nov. 2016. FERNANDES, Ana Carla, VALLS, Carmem, SAVOINE, Márcia Maria. Análise da qualidade de software utilizando as normas 12207,15504, ISO 9000-3 e os modelos CMM/CMMI e MPS.BR. Revista Científica do ITPAC. Araguaína, v.4, n º 4, Pub 5, Outubro de 2011. Disponível em < http://www.itpac.br/arquivos/Revista/44/5.pdf>. Acesso em: 15 Nov. 2016. FILHO, Wilson de Pádua Paula. Manual do Engenheiro de software. Belo Horizonte: UFMG, 2000. Disponível em: < https://pt.scribd.com/doc/7570545/MAnualEngSW > Acesso em: 24 Nov. 2016. FRANCISCANI, Juliana de Fátima. PESTILI, Ligia Cristina. CMMI e MPS.BR: Um Estudo Comparativo CMMI and MPS.BR: A Comparative Study. Unicerp. Patrocínio, MG. Disponível em: < http://www.unicerp.edu.br/images/revistascientificas/3%20- %20CMMI%20e%20MPS.BR%20Um%20Estudo%20Comparativo1.pdf > Acesso em: 28 Set. 2016. HIRAMA, Kechi. Engenharia de Software. Rio de Janeiro: Elsevler Editora Ltda, 2012.p.232. Disponível em: < https://books.google.com.br/books?id=tYhQYH2yiiYC&printsec=frontcover&dq#v=on epage&q&f=false> Acesso em: 24 Nov. 2016. 48 JANUZZI, Glauter. Metodologia da Qualidade em TI. 2007. Disponível em:< http://imasters.com.br/artigo/5269/ > Acesso em: 10 Nov. 2016. NUNES, Breno O. CMMI – Representação Contínua - Níveis de Capacidade. 2013. Disponível em: < http://tiinteligente.blogspot.com.br/2013/05/cmmi-representacao- continua-niveis-de.html > Acesso em: 10 Nov. 2016. PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice Hall, 2004.p.560. PRESSMAN, Roger S. Engenharia de software. 5 ed. São Paulo: Editora Makron Books, 1995.p.1056. PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de software. Uma abordagem profissional. 8 ed. São Paulo: AMGH Editora Ltda, 2016.p.16. RODRIGUES, Ana N; MOURA, Mirtes; RODRIGUES, Paula; SANTOS, Vanusa. Qualidade de Software. Disponível em: < http://www.devmedia.com.br/qualidade- de-software-parte-01/9408 > Acesso em: 29 Out. 2016. RODRIGUES, Edson Junior Lobo. Curso de Engenharia de Software. São Paulo: Universo dos Livros Editora Ltda, 2008.p.111. Disponível em: < https://books.google.com.br/books?id=ZJznA9UrtVAC&printsec=frontcover&d#v=one page&q&f=false > Acesso em: 04 mai. 2016. SALVI, WAGNER. CMMI – Áreas de processo. Blog tecnologia da informação. 2012. Disponível em: < http://www.wagnersalvi.com.br/index.php/cmmi-areas-de- processos/ > Acesso em: 04 Out. 2016. 49 SIMPROS. Tutorial SEPG Software Engineering Process Group. 2003. Disponível em < http://asrconsultoria.com.br/wp- content/uploads/2016/04/Tutorial_SEPG_ASR_2slides.pdf > Acesso em: 01 Dez. 2016. SCHACH, Stephen R. Os Paradigmas Clássico e Orientado a Objetos. São Paulo: AMGH Editora Ltda, 2010. P.92. Disponível em: < https://books.google.com.br/books?id=Mkk7MriAp_wC&pg=PA92&lpg=PA92&dq=mo delos+de+maturidade+e+capacidade&source=bl&ots=q3W6O8BYs- &sig=vbE5mQhezEBidop7YaOVsPfpwjM&hl=pt-BR&sa=X&ved=0ahUKEwj8p- iLm7nMAhUFkZAKHbaTAqo4ChDoAQhOMAk#v=onepage&q=modelos%20de%20m aturidade%20e%20capacidade&f=false> Acesso em: 19 Out. 2016. SILVEIRA, Artur Rafael. O que é o MPS.BR? 2012. Disponível em: < https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos-do- software-brasileiro--mpsbr > Acesso em: 03 jun. 2016. SOFTEX - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO. MPS. BR. Melhoria de Processo do Software Brasileiro. 2012. Disponível em: < http://www.softex.br/mps>. Acesso em: 05 de maio de 2016. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, 2003.p.592. SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson Addison Wesley, 2007.p.552. Disponível em: < http://www.ebah.com.br/content/ABAAAgMuQAG/sommerville-engenharia-software- 8-edicao> Acesso em: 28 Set. 2016. 50 VASCONCELOS, Audrey, MORAES, Lenildo. Modelos de Maturidade para Processos de Software: CMMI e MPS. BR. Centro de Informática – UFPE. Disponível em < http://www.cin.ufpe.br/~processos/TAES3/Livro/00-LIVRO/08- CMMI_MPSBR_v6_CORRIGIDO.pdf > Acesso em: 29 Set.2016. VASCONCELOS, Alexandre Marcos Lins, ROUILLER, Ana Cristina, MACHADO, Cristina Ângela Filipak, MEDEIROS, Teresa Maria Maciel. Introdução à Engenharia de software e à qualidade de software. Universidade Federal de Lavras – UFLA. Lavras – MG. 2006. Disponível em: < http://www.cin.ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia%26QualidadeSoft ware_V.28.09.06.pdf> Acesso em: 18 Out.2016 VOLPE, Renato Luiz Della. Visão Geral do SW-CMM. 2002. Disponível em: < http://www.asrconsultoria.com.br/docs/cmm_vg_ppt.pdf>Acesso em: 29 Set. 2016. WIKIPÉDIA, CMMI. Disponível em: < https://pt.wikipedia.org/wiki/CMMI > Acesso em: 10 Out. 2016. WIKIPÉDIA, Grupo de Processo de engenharia de software. Disponível em: < https://en.wikipedia.org/wiki/Software_Engineering_Process_Group > Acesso em: 13 Nov. 2016. 51 Anexo A 52 53
Compartilhar