EVERTON RODRIGUES GARCIA
RECOMENDAÇÕES PARA O ALCANCE DO NÍVEL G DO MODELO MPS.BR
Florianópolis 2015
RECOMENDAÇÕES PARA O ALCANCE DO NÍVEL G DO MODELO MPS.BR
Monografia apresentada ao Curso de Pós-Graduação Lato Sensu em Engenharia de Projetos de Software, da Universidade do Sul de Santa Catarina, como requisito parcial para obtenção do título de Especialista.
Orientador: Marcello Thiry Comicholi da Costa, Dr.
Florianópolis 2015
Esta Monografia foi julgada adequada à obtenção do título de Especialista em Engenharia de Projetos de Software e aprovado em sua forma final pelo Curso de Pós-Graduação Lato Sensu em Engenharia de Software, da Universidade do Sul de Santa Catarina.
Florianópolis, 12 de fevereiro de 2015.
__________________________________________________________ Prof. e orientador Marcello Thiry Comicholi da Costa, Dr.
Universidade do Sul de Santa Catarina
__________________________________________________________ M. Daniella Pinto Vieira
Considerando as melhores práticas para o desenvolvimento de software existentes no mercado brasileiro, através da ótica do modelo referência MPS.BR para software e do framework para organizar e gerenciar trabalhos complexos, chamado Scrum, este trabalho propõe o levantamento e mapeamento do processo de desenvolvimento de software da instituição estudo de caso, a identificação da distância dele em relação ao nível G do MPS.BR, e a proposição de um conjunto de recomendações para que o processo se torne aderente a este nível de maturidade. Para alcançar os objetivos propostos o modelo de referência MPS para software, especificamente o nível G, e o framework Scrum, formaram os pilares das recomendações deste estudo de caso. Primeiramente foram identificados e mapeados os processos de software existentes na empresa através do levantamento de suas atividades. Em seguida analisou-se a conformidade deste processo de software em relação aos resultados esperados do nível G, considerando somente aqueles relacionados à gerência de projetos e gerência de requisitos. Identificadas as oportunidades de melhoria no processo existente, partiu-se para um estudo das possíveis contribuições do Scrum e sua adequação à realidade da instituição para que o seu processo de software ficasse o mais aderente possível ao nível G do MPS.BR. A validação destas recomendações foi feita pelos profissionais de carreira da instituição que julgaram a viabilidade de sua implantação.
Palavras chave: Melhoria de processo. MPS.BR. Scrum. Diagnóstico. Gerência de projeto. Análise de requisitos.
Considering best practices for the development of existing software in the Brazilian market through the perspective of MPS.BR reference model for software and framework to organize and manage complex jobs, called Scrum, this paper proposes the survey and mapping of the development process of the case study company software, the identification of the distance from it to the level of G MPS.BR, and to propose a set of recommendations for the process to become adherent to this level of maturity. To achieve the proposed objectives MPS reference model for software, specifically the level L, and the Scrum framework, formed the pillars of the recommendations of this case study. Were first identified and mapped existing software processes in the company by raising its activities. Then analyzed the compliance of this software process from the expected results of the G level, considering only those related to the management of projects and management requirements. Identified opportunities for improvement in the existing process, broke for a study of the possible contributions of Scrum and its suitability to the company's reality so your software process would be as adherent as possible to the G level MPS.BR. The validation of these recommendations was made by the company professionals who judged the feasibility of its implementation.
Keywords: Process Improvement. MPS.BR. Scrum. Diagnosis. Project management. Requirements analisys.
1 INTRODUÇÃO …...8 1.1 OBJETO DA PESQUISA …...9 1.2 OBJETIVOS …...9 1.3 OBJETIVOS GERAIS …...9 1.4 OBJETIVOS ESPECÍFICOS …...9 1.5 JUSTIFICATIVA …...9 1.6 ESTRUTURA DA MONOGRAFIA ...10
2 DESENVOLVIMENTO DA FUNDAMENTAÇÃO BIBLIOGRÁFICA …...11
2.1 PROCESSO DE SOFTWARE ...11
2.1.1 Visão Geral …...11
2.1.2 Modelos de Ciclo de Vida de Processo de Software ...12
2.1.2.1 Modelo em Cascata …...14
2.1.2.2 Modelo Incremental …...15
2.1.2.3 Modelo Evolucionário …...17
2.1.2.4 Modelos Concorrentes …...20
2.2 MELHORIA DE PROCESSO DE SOFTWARE …...22
2.2.1 Visão Geral …...22
2.2.2 O que é a Melhoria de Processo de Software …...22
2.2.3 Maturidade do Processo na Melhoria de Processo de Software …...25
2.2.3.1 A Maturidade do Processo de Software …...26
2.2.4 O Processo de Melhoria …...28
2.2.5 Fatores de Sucesso na Melhoria de Processo de Software …...32
2.2.6 O futuro da Melhoria de Processo de Software …...32
2.3 DIAGNÓSTICO DE PROCESSO DE SOFTWARE …...34
2.4 MPS.BR – MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO …...37
2.4.1 Estrutura …...37
2.4.2 Modelo de Referência MPS para Software …...39
2.4.2.1 Níveis de Maturidade …...39
2.4.3 Processo …...40
2.4.4 Capacidade do Processo …...41
2.4.5.2 Processo: Gerência de Requisitos - GRE …...50 2.5 SCRUM …...…...53 2.5.1 Papéis no Scrum …...…...54 2.5.2 Eventos Scrum …...…...58 2.5.3 Artefatos Scrum …...62 2.5.4 Definição de Pronto …...65 3 DESENVOLVIMENTO DO ESTUDO …...67
3.1 CONTEXTUALIZAÇÃO DA INSTITUIÇÃO PÚBLICA TRT12...67
3.2 O PROCESSO DE SOFTWARE DA INSTITUIÇÃO PÚBLICA TRT12...70
3.2.1 Papéis no Processo …...71
3.2.2 Ciclo de vida do Processo …...72
3.3 APROXIMAÇÃO DO NÍVEL G DO MPS.BR …...86
3.4 ANÁLISE DO GRUPO DE PROCESSOS DA INSTITUIÇÃO PÚBLICA TRT12...89
3.4.1 Recomendações para o Grupo de Processos de Gerência de Projetos (GPR) ...90
3.4.2 Recomendações para o Grupo de Processos de Gerência de Requisitos (GRE) ....93
3.5 VALIDAÇÃO DAS RECOMENDAÇÕES …...93
4 CONCLUSÃO ...97
REFERÊNCIAS ...99
1 INTRODUÇÃO
O mercado de desenvolvimento de software está há algum tempo focado em fornecer produtos de qualidade. O retrabalho, a insatisfação do cliente, o baixo rendimento das equipes e a falta de planejamento e organização apresentam-se como as principais fatores num processo de desenvolvimento de software ineficiente, refletindo no produto final.
Produtos de software de qualidade requerem um processo de desenvolvimento eficiente e muitos esforços neste sentido têm sido apresentados, ainda mais pela complexidade crescente dos produtos. Não há mais espaço para processos de desenvolvimento informais e dependentes do talento dos seus funcionários, pois os clientes estão cada vez mais exigentes, os prazos cada vez mais enxutos e as tecnologias e arquiteturas cada vez mais complexas.
Desenvolvimento de software não é mais uma tarefa desacoplada do contexto de projeto e isto traz mais complexidade ao processo como um todo. São tantas as variáveis a serem tratadas e consideradas num processo de desenvolvimento de software que este é considerado um ambiente propício ao caos, portanto, organizar e melhorar constantemente a forma como os produtos de software são desenvolvidos, pode ser um dos fatores determinantes para o crescimento e a manutenção da empresa no mercado.
Para auxiliar os processos de desenvolvimento de software no contexto brasileiro o modelo de maturidade MPS.BR apresenta-se como uma referência fundamental para a área de qualidade de software de pequenas, médias empresas e do governo. Alinhado às principais abordagens internacionais, o modelo MPS.BR, através de seus guias de referência, baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade de produtos de software.
Para contribuir com os modelos de maturidade, que sugerem tudo o que pode se esperar de um processo de desenvolvimento de software mas não dizem como isso pode ser feito, é sugerido o framework Scrum que traz para o cotidiano das equipes suas regras, suas cerimônias e o sequenciamento bem definidos para a aplicação no contexto de projeto de software. Além disso, o Scrum traz para os projetos a possibilidade de gerenciá-los sob a ótica do gerenciamento ágil, ou seja, a de não burocratizar, não documentar excessivamente, e fomentar a simplicidade, produtividade e a agilidade, em detrimento de processos desnecessários.
Neste sentido, a proposta de melhorar o processo de desenvolvimento de software de organizações públicas possui igual, ou maior, responsabilidade que as privadas a partir do momento que o cliente é a sociedade e esta merece ter produtos de qualidade e que atendam suas expectativas.
1.1 OBJETO DA PESQUISA
Este trabalho está limitado a avaliar o processo de desenvolvimento de software da instituição pública Tribunal Regional do Trabalho da 12a Região (TRT12) sob a ótica do modelo
MR-MPS-SW, nível G, e de que forma uma metodologia ágil, neste caso o Scrum, pode contribuir neste contexto.
Está fora do escopo deste trabalho a análise dos Resultados Esperados de Atributo de Processo (RAP) deste modelo, pois estas são metas genéricas que avaliam capacidade e requerem certo grau de medição, o que não é realizado no contexto atual da instituição. Da mesma forma, também não serão aplicadas técnicas de diagnóstico de processo para o levantamento e mapeamento do processo de desenvolvimento de software da empresa TRT12, por entender que esta é uma atividade específica e ao mesmo tempo complexa, carecendo de um profissional experiente tanto para diagnosticar quanto um funcionário para dar o suporte necessário na empresa, além de sua disponibilidade para isso.
1.2 OBJETIVOS
Abaixo serão apresentados os objetivos gerais e os específicos deste trabalho.
1.3 OBJETIVOS GERAIS
Como objetivo geral deste trabalho pretende-se levantar o processo de desenvolvimento de software da empresa estudo de caso, identificar as oportunidades de melhoria, fazer recomendações de melhoria e validá-las junto à equipe de desenvolvimento de software, na pessoa dos seus arquitetos de sistemas mais experientes.
1.4 OBJETIVOS ESPECÍFICOS
O objetivo específico do estudo de caso é: a) efetuar o levantamento e mapeamento do processo de desenvolvimento de software da empresa estudo de caso; b) identificar oportunidades de melhoria no processo de software da empresa estudo de caso, conforme o MPS.BR, e; c) fazer recomendações, com o foco na qualidade do processo, baseadas em métodos ágeis, conforme o
Scrum. A validação das recomendações, além de respaldar as mudanças necessárias, proporcionam
uma auto-análise para os gestores do processo de desenvolvimento de software da instituição.
Apesar de não ser um assunto novo para a maioria dos profissionais de tecnologia da informação de órgãos públicos, a definição e a institucionalização da melhoria de processos de desenvolvimento de software é um assunto que todas as empresas desenvolvedoras devem levar a sério, mas que carece de patrocínio e de iniciativas para a sua execução e manutenção.
Comparar o processo de desenvolvimento de software da instituição TRT12 ao modelo de maturidade MPS.BR, fornecendo recomendações baseadas no Scrum, possibilitará a reavaliação dos seus processos atuais e, se aprovadas, dar início a uma atividade ainda não executada na instituição que é a melhoria contínua de processo de desenvolvimento de software. Esta é, com certeza, a maior fonte motivacional deste trabalho.
1.6 ESTRUTURA DA MONOGRAFIA
O restante do trabalho está organizado da seguinte forma: no Capítulo 2 apresenta-se a fundamentação teórica. O Capítulo 3 demonstra como foi levantado e mapeado o processo de desenvolvimento da instituição TRT12, a análise do processo frente aos resultados esperados do MR-MPS-SW e as recomendações de mudança no processo de desenvolvimento. Por fim, no Capítulo 4 são apresentadas as conclusões do trabalho.
2 DESENVOLVIMENTO DA FUNDAMENTAÇÃO BIBLIOGRÁFICA
2.1 PROCESSO DE SOFTWARE
2.1.1 Visão Geral
Entende-se por processo de software o conjunto de atividades previsíveis, práticas e transformações eficientes utilizados para atingir uma meta, estabelecida dentro de um prazo, que é desenvolver um software de alta qualidade e que atinja as necessidades de negócio.
Um processo é considerado adequado, para um determinado projeto, quando sua execução atender as expectativas de custos, de qualidade e de produção, previamente planejadas.
Um processo é considerado definido em uma empresa/instituição quando as atividades que devem ser seguidas, os papéis e responsáveis em cada atividade, as ferramentas que serão utilizadas e o produto de sua execução (programas, documentos, e dados) já estão estabelecidos.
Pressman (2011) um processo de software bem definido propicia estabilidade, o controle e a organização para o grande conjunto de atividades inerentes ao desenvolvimento de software. A sequência destas atividades, embora possuam uma ordenação parcial, podem ser executadas com paralelismo em diversos pontos do processo.
Numa empresa/instituição que possui um processo definido, os projetos seguem uma instância deste processo que é adaptado para suas necessidades. Assim, o processo possui uma versão e deve poder ser replicado por projetos similares na organização.
Nem sempre o desenvolvimento de um software é o produto final de um processo de software; além da produção de documentação e dados, muitas vezes o produto final pode ser a ampliação e a modificação de um sistema existente para torná-lo um novo software, ou a integração de componentes de sistemas que também se caracterizará como um novo software.
Para Sommerville (2007), por se tratarem de processos intelectuais, o processo de software e sua execução são atividades complexas e dependentes do julgamento e da criatividade humana, o que reduz a eficiência de sua automatização. Ferramentas de apoio à execução do processo de software (CASE - Computer-Aided Software Engineering) podem auxiliar em algumas atividades, mas não automatizá-lo por completo. Isso se deve normalmente em razão da grande diversidade de processos de software existentes. Cada organização adapta a abordagem que melhor se adéqua à sua realidade principalmente para tirar o melhor proveito das capacidades de seus colaboradores assim como para melhor ajustar o seu processo às características dos sistemas
desenvolvidos, onde sistemas críticos necessitam de processos de desenvolvimento mais rígidos e estruturados e sistemas de negócios que possuem requisitos que podem mudar rapidamente e necessitam de processos mais flexíveis. Assim, um processo possui um nível de maturidade alto quando os mecanismos de avaliação possibilitam determiná-lo como eficaz através da análise da qualidade de seus produtos, do cumprimento de prazos e da viabilidade do produto.
2.1.2 Modelos de Ciclo de Vida de Processo de Software
Para Pressmann (2011) o processo de software, de forma mais genérica, é definido como um conjunto de atividades baseadas numa metodologia, ações de engenharia de software e um conjunto de tarefas relacionadas a cada ação. Este conjunto de tarefas pode ser representado pelas tarefas a serem executadas, os artefatos de software a serem produzidos, os fatores de garantia de qualidade que serão exigidos ou os marcos indicativos de progresso. As tarefas são o que definem o verdadeiro trabalho a ser feito para atingir os objetivos de uma ação de engenharia de software, podendo ser mais profundas ou mais formais em determinado projeto e o contrário em outro. A equipe é quem seleciona o conjunto de tarefas a serem executadas para atingir o objetivo de cada ação.
Um processo de desenvolvimento de software pode ser composto por subprocessos como: especificação de requisitos, análise, desenho, implementação e testes.
Para Sommerville (2007), embora existam diversos modelos para desenvolvimento de software, algumas atividades são comuns a todos eles, a saber:
• Especificação de software: Definição das funcionalidades do software e as restrições sobre sua operação;
• Projeto e implementação de software: Desenvolvimento do software especificado;
• Validação de software: Validação das funcionalidades especificadas e que atenda ao cliente;
• Evolução do software: Melhorias inerentes a qualquer organização para a evolução do seu produto, sempre atendendo às necessidades do cliente;
Para abstrair os subprocessos de um processo de software sob uma determinada perspectiva, os modelos de ciclo de vida de processo funcionam como frameworks que podem ser adaptados e reutilizados para criar processos mais específicos, por isso são chamados de modelos
genéricos ou prescritivos, pois funcionam como uma recomendação que pode ser adaptada ou melhorada. Portanto, um processo é composto por atividades relacionadas e os modelos servem para dar uma visão de como é um processo. Os modelos prescritivos retratam como um processo deveria ser executado, pois esses modelos prescrevem um conjunto de elementos a serem executados e a maneira como esses elementos se inter-relacionam.
Assim, um modelo de ciclo de vida de processo definirá o que deve ser realizado em cada fase do desenvolvimento e dará as instruções de como realizar essas atividades, servindo como um guia para a execução de um processo de desenvolvimento.
Mesmo com a ascensão dos métodos ágeis de desenvolvimento de software, os modelos prescritivos ainda são muito utilizados nas organizações e seu objetivo principal foi trazer certa estrutura e organização inicial aos processos.
Os modelos prescritivos mais relevantes são: Modelo Cascata, Modelo Incremental, Modelo Evolucionário e Modelos Concorrentes.
Estes modelos são normalmente utilizados em conjunto no desenvolvimento de um sistema e é comum a utilização de mais de uma abordagem para diferentes módulos de um mesmo sistema.
Cada modelo possui o seu fluxo de processo bem específico o qual descreve como são organizadas as atividades da metodologia, assim como as ações e as tarefas de cada atividade, em relação à sequência e ao tempo de cada uma:
• Fluxo de processo linear: Executa as atividades da metodologia em sequência; • Fluxo de processo iterativo: Executa as atividades repetindo uma ou mais das atividades antes de prosseguir para a seguinte;
• Fluxo de processo evolucionário: Executa as atividades de forma circular e iterativa, onde cada volta representará uma versão software mais completa;
• Fluxo de processo paralelo: Executa uma ou mais atividades em paralelo com outras atividades.
A escolha da metodologia mais adequada a ser empregada deve levar em consideração a definição do conjunto de ações que serão apropriadas ao projeto ou ao problema a ser solucionado, deve considerar o perfil da equipe do projeto e da equipe de negócio ou os interessados que propuseram o projeto.
sistemática e sequencial, ou seja, uma nova atividade só pode ser iniciada quando a anterior estiver totalmente concluída. Paula Filho (2009) salienta que neste modelo os principais subprocessos são encadeados numa sequência que permite definir pontos de controle que facilitam a gestão do projeto, podendo ser utilizado em projetos de qualquer escala devido a sua confiabilidade.
2.1.2.1 Modelo em Cascata
Sua estrutura é bastante simples porque as atividades são claras e bem definidas, permitindo também que os desenvolvedores descrevam o que deve ser realizado.
Por outro lado, este modelo é considerado rígido e burocrático, pois o resultado de cada fase consiste na produção de um ou mais documentos que devem ser aprovados para que fase seguinte possa começar, tornando difícil qualquer alteração não prevista no sistema antes de sua conclusão e reproduzindo qualquer atraso para as fases seguintes. Um exemplo é a fase de levantamento de requisitos que deve ser perfeita o suficiente para que não haja a necessidade de nova iteração.
Observa-se na prática que as fases acabam por se sobrepor e trocar informações na medida que problemas são encontrados durante as iterações das atividades de desenvolvimento.
O modelo em cascata produz uma documentação detalhada e, desta forma, garante a aderência a outros modelos de processo de engenharia de software. Ainda, ele se mostra bastante eficiente quando os requisitos são bem compreendidos e com pouca probabilidade de mudanças durante o desenvolvimento do sistema, ou quando adaptações ou aperfeiçoamentos bem definidos precisam ser feitos em um sistema existente (PRESSMAN, 2011). Por outro lado esta dificuldade de reação a mudanças dos requisitos dos usuários torna este modelo um tanto engessado.
Em projetos reais, raramente se utiliza o fluxo sequencial, pois é difícil elucidar todos os requisitos inicialmente, assim como novos podem surgir durante o desenvolvimento, e por isso o modelo em cascata possui desvantagens. O fato de uma versão executável do software só ficar disponível para o cliente no final do processo caracteriza dar baixa visibilidade para o cliente, que só recebe o produto no final do projeto, extremamente evitado em contextos ágeis de desenvolvimento, onde o cliente tem participação ativa.
Figura 1 - O modelo em cascada
Fonte:(Pressman, 2011).
Características:
• Comunicação: O objetivo é definir e detalhar, em conjunto com os usuários, a
especificação que contempla os serviços, as restrições e os objetivos do sistema.
• Planejamento: Envolve o planejamento do projeto no tocante à estimativas,
cronograma e acompanhamento, e das atividades técnicas no tocante à definição da arquitetura do sistema através da divisão dos requisitos em sistemas de hardware e software. • Construção: O objetivo é a confecção do programa ou conjunto de programas
em conjunto com os testes unitários que garantirão que cada unidade de software atende à sua especificação. O teste completo do software através da integração de suas partes como um sistema completo e a avaliação dos requisitos também é executada.
• Emprego: O objetivo principal é colocar o sistema em operação. Além disso, a
manutenção do sistema deve ser realizada sempre que houver a necessidade de correção de erros, assim como a implementação de melhorias no software existente e a adição de novas funcionalidades/serviços à medida que novas necessidades são identificadas por parte do usuário.
2.1.2.2 Modelo Incremental
Considerado uma evolução do modelo em cascata, o modelo incremental caracteriza-se pelas mesmas atividades do modelo em cascata, porém estas atividades são realizadas repetidamente de forma iterativa e incremental, e ainda combina elementos dos fluxos de processos lineares e paralelos.
Com o foco voltado para a entrega de um produto operacional a cada incremento, este modelo é recomendado quando os requisitos do software estão bem definidos ou quando há a necessidade do rápido fornecimento de uma versão do software com um conjunto de
funcionalidades mais limitadas para os usuários, para depois refinar os requisitos e expandir sua funcionalidade em versões posteriores, projetando assim o produto de software de forma incremental.
Figura 2 - O modelo incremental
Fonte:(PRESSMAN, 2011).
Na figura acima, Pressman (2011) observa que neste modelo são aplicadas sequências lineares de forma escalonada à medida que o tempo vai avançando.
A execução do modelo incremental parte do primeiro incremento, chamado de produto essencial, no qual apenas os requisitos básicos são implementados, e que é detalhadamente avaliado pelo cliente. Esta avaliação serve de subsídio para o planejamento do incremento seguinte que já considera a inclusão dos recursos e funcionalidades adicionais. A cada incremento este processo é repetido, permitindo assim trabalhar com pequenos objetivos e foco no curto prazo.
É recomendado nos seguintes casos:
• Falta de pessoal para uma implementação completa; • Gerir riscos técnicos: indisponibilidade de material;
Além disso, observa-se que a cada incremento, uma nova funcionalidade é disponibilizada ao sistema. Isso favorece o gerenciamento de riscos de forma eficiente, pois trabalha com um universo menor de riscos a cada incremento, e dá uma maior visibilidade para o cliente que recebe um feedback desde o início e participa ativamente do projeto.
2.1.2.3 Modelo Evolucionário
Este modelo parte do pressuposto de uma implementação inicial, e disponível para avaliação do usuário, que será refinada por meio de diversas iterações até o produto final.
Presman (2011) observa que a medida que os projetos avançam, as necessidades do negócio e do produto também podem mudar, desta forma se torna mais eficaz o desenvolvimento que não siga um planejamento linear mas, ao contrário, disponibilize versões limitadas do sistema ao cliente com um conjunto limitado de funcionalidades e que evolua ao longo do tempo.
Assim, nos modelos evolucionários as atividades de especificação, desenvolvimento e validação são intercaladas
A abordagem evolucionária se mostra mais eficaz do que a em cascata quando há necessidade de atender o cliente com certa rapidez e haja prazo suficiente para evoluir o produto até o final do projeto.
O modelo evolucionário se caracteriza por dois modelos: Prototipação e Espiral.
• Prototipação: Modelo que procurar ajudar no entendimento dos requisitos, aprimorando-os
conforme o projeto evolui. O desenvolvimento do protótipo passa por um projeto, codificação e teste para em seguida ser avaliado pelo cliente para melhor entender os requisitos do sistema.
Recomendado para situações onde há dúvidas quanto à identificação detalhada dos requisitos para funções ou recursos e também para situações onde há dúvidas técnicas relacionadas à tecnologia. Pressman (2011) observa que este modelo pode ser útil nas possíveis dúvidas dos desenvolvedores relacionadas à eficiência de um algoritmo, adaptabilidade de um sistema operacional ou quanto a forma em que deva ocorrer uma interação homem/máquina.
É uma técnica que pode ser considerada complementar a qualquer outra para ajudar na elucidação de requisitos do software a ser construído.
Fases:
• Comunicação: Reunião para definição dos objetivos gerais do software,
requisitos conhecidos e áreas a serem exploradas;
• Modelagem e Projeto rápido: Representação dos aspectos do software que
serão visíveis aos usuários finais;
• Construção: Construção do protótipo;
feedback para o aprimoramento dos requisitos;
Figura 3 - Prototipação
Fonte: (PRESSMAN, 2011).
A iteração se desenvolve até que o protótipo se ajuste às necessidades dos interessados ao mesmo tempo que possibilita a compreensão exata das necessidades que devem ser atendidas e atuando como um mecanismo para identificar os requisitos do software.
Pressman (2011) identifica os benefícios da prototipação:
• Em sistemas de grande porte, onde há maior dificuldade em exprimir detalhadamente os requisitos;
• Pouco investimento inicial para mostrar uma versão experimental;
• O custo das fases posteriores diminui com a prototipação ao antecipar e melhorar o detalhamento dos requisitos;
• O protótipo pode demonstrar a viabilidade do sistema.
Deve ficar claro entre as equipes de desenvolvimento e de negócio que num dado momento o protótipo será descartado, inteiramente ou em partes, pois o seu objetivo é ser apenas um mecanismo de definição de requisitos, onde a qualidade e a manutenção a longo prazo não são o foco. Existem diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os
requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido. O protótipo não deve ser considerado como uma opção válida para entrar em operação porque sua construção foca apenas no seu objetivo que é ajudar na elucidação de requisitos.
• Modelo Espiral: O modelo espiral agrega as características iterativas do modelo de
prototipação com os aspectos sistemáticos e controlados do modelo em cascata, produzindo através de uma série de pequenos ciclos uma versão de software executável e cada vez mais completo.
Este modelo trouxe um novo elemento para esta abordagem que foi a análise de riscos. Com o foco em ampliar, incrementalmente a cada ciclo, o grau de definição e a implementação de um sistema, ela diminuía o grau de risco do mesmo.
Este modelo capacita a equipe de desenvolvimento e a equipe de negócio a entender e reagir aos riscos em cada etapa evolutiva. A minimização dos riscos para o projeto reduz os possíveis problemas que afetam cronograma e custos (SOMMERVILLE, 2007). Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso, pois se um grande risco não for descoberto, poderão ocorrer problemas.
Além dos riscos, a definição de pontos de controle é muito importante porque valida se a busca de soluções propostas são praticáveis e se atendem com comprometimento a necessidade das partes envolvidas.
A possibilidade de desenvolver paralelamente múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, requer o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.
O uso deste modelo organiza o desenvolvimento como um processo iterativo em que vários conjuntos de fases se sucedem até se obter o sistema final. Cada iteração na espiral que representa uma fase no processo de software está dividida por 4 (quatro) setores que, conforme Sommerville (2007), estão abaixo descritos. O modelo espiral pode considerar variações nas tarefas ou setores da espiral, podendo conter mais que os 4 (quatro) abaixo descritos:
Figura 4 - Modelo Espiral
Fonte: (SOMMERVILLE, 2007).
• Definição de objetivos: Definir os objetivos, as alternativas e as restrições.
Identificação das restrições sobre o processo e produto, elaboração de um plano detalhado de gerenciamento, identificação dos riscos do projeto e planejamento de estratégias alternativas. Ainda nesta fase, busca-se o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos;
• Avaliação e redução de riscos: Avaliar alternativas, identificar e resolver riscos.
Cada risco identificado deve ter uma análise detalhada com proposta de ação de contorno. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto.;
• Desenvolvimento e validação: Desenvolver, verificar produto de próximo nível.
Selecionar um modelo de desenvolvimento baseado na análise de riscos e na sua priorização, ou seja, dependendo do risco priorizado um modelo específico e que seja mais adequado deve ser selecionado. Neste quadrante pode-se considerar o modelo cascata;
• Planejamento: Planejar a próxima fase. O produto é avaliado e se prepara para
iniciar um novo ciclo. O projeto é revisado para então se decidir pelo prosseguimento ou não. Se positivo, desenvolve-se a elaboração de planos para a próxima fase.
2.1.2.4 Modelos Concorrentes
maiores e estados associados a elas. As atividades podem estar em qualquer um dos estados, observados em qualquer instante determinado. Da mesma forma, outras atividades podem ser representadas de maneira similar.
As interações das fases se dão através de eventos que disparam transições, fazendo assim a mudança de uma fase para outra, por exemplo, quando uma inconsistência é identificada ela gera um evento que produzirá a transição da atividade de um estado para outro do modelo.
Como todas as atividades de engenharia de software existem concorrentemente, porém em estados diferentes, elas podem ser afetadas e ter seus estados alterados com a ocorrência de apenas um evento. Este evento é que poderá disparar a transição dentre os estados possíveis de cada uma das atividades.
A modelagem concorrente se aplica a todos os tipos de desenvolvimento de software e fornece uma visão geral do estado atual do projeto. Ainda, ela não limita as atividades, ações e tarefas da engenharia de software a uma sequência de eventos, ao contrário, ela define uma rede de processos onde cada uma destas existe simultaneamente na rede e são afetadas pela ocorrência de eventos em um ponto da rede e que, consequentemente, geram transições necessárias nelas. (PRESSMAN, 2011).
Como todo processo evolucionário, este modelo também não estabelece a velocidade máxima da evolução do projeto.
Figura 5 - Modelos Concorrentes
2.2 MELHORIA DE PROCESSO DE SOFTWARE
Este capítulo aborda a definição de melhoria de processo, as características que envolvem este processo, as suas abordagens, a questão da maturidade das organizações que desejam implementar a melhoria de processo de software, o processo de melhoria de processo em si, os fatores de sucesso de uma implementação, assim como alguns aspectos a serem considerados para o futuro.
2.2.1 Visão Geral
Organizações que desenvolvem software possuem os mesmos desafios de qualquer outro segmento que são: o aumento da qualidade do produto, a redução dos custos e o atendimento do prazo estipulado. (PRESSMAN, 2011).
Atentas a esta necessidade, verifica-se nos últimos anos um aumento nas iniciativas das organizações para a adoção de práticas de melhoria de processos de software. Estas práticas variam desde iniciativas com processos ad hoc que são poucos controlados, não passíveis de repetição e dependentes do talento dos membros da equipe, outras iniciativas individuais e improvisadas que ocasionalmente atingem o resultado esperado, até aquelas que se baseiam em práticas de engenharia de software já consolidadas pelo mercado. (PRESSMAN, 2011).
Esforços no sentido de auxiliar na melhoria de qualidade dos processos de software, através de práticas de engenharia de software, têm sido propostos desde a década de 90.
Desde então melhorar os processos de software tem sido um desafio cada vez maior nas organizações que desenvolvem software, pois os processos de software são inerentemente complexos, com um grande número de atividades e com um grande número de características, com uma quantidade grande de pessoas envolvidas e ainda é necessário lidar diariamente com novas tecnologias, aplicando as melhores práticas para o bom desenvolvimento de suas atividades e obtenção de níveis de qualidade satisfatórios. Isto requer a constante melhoria do processo de desenvolvimento de software da organização através do profundo entendimento dos processos existentes e de sua alteração. (SOMMERVILLE, 2007).
2.2.2 O que é a Melhoria de Processo de Software
Para Sommerville (2007), melhoria de processo de software consiste em compreender os processos existentes na organização e modificá-los para obter melhores resultados na qualidade dos produtos e redução no número de defeitos no software entregue, que resulta em redução dos
custos e tempo de desenvolvimento. Assim, com a redução dos defeitos, até que o número possa ser repetível, tornando o resultado do processo previsível e sua versão padronizada, este é o momento em que o processo está pronto para iniciar os ciclos de aprimoramentos. (SOMMERVILLE, 2007).
Para Pressman (2011) a aplicação de melhoria de processo de desenvolvimento de
software transforma a abordagem existente em algo mais focado, mais confiável, em relação à
qualidade de produto e prazo de entrega, e passível de uma melhor repetitividade em projetos de características semelhantes, baseados nas seguintes premissas:
• Os elementos de um processo de um processo são definidos;
• A abordagem organizacional para o desenvolvimento pode ser avaliada em relação aos elementos e;
• Uma estratégia significativa para a melhoria pode ser definida.
Ainda, Pressman (2011) sustenta que embora as organizações possuam algum tipo de processo de desenvolvimento de software, sempre há espaço para melhorias no processo existente e que resultará numa versão mais refinada, otimizada e ajustada à realidade da organização, cujo produto do trabalho será entregue com um número menor de defeitos, menor esforço em retrabalho em cada fase do processo, assim como um planejamento de prazo mais eficiente.
Sommerville (2007) classifica os processos encontrados nas organizações, considerando suas características inerentemente complexas e ciente de que estas características podem ser encontradas simultaneamente, em:
• Processos Informais: Sem um modelo de processo definido, escolhido pela equipe de desenvolvimento. Aplicado a sistemas com tempo de vida curto, protótipos, sistemas de negócio em 4GL, sistemas de pequeno e médio porte;
• Processos Gerenciados: Com um modelo de processo definido. Aplicado a sistemas de grande porte e sistemas com tempo de vida longo;
• Processos Metódicos: Quando utiliza um método definido de desenvolvimento, se beneficia do apoio de ferramentas CASE para processos de análise e projeto. Aplicado a domínios de aplicação bem compreendidos e sistemas que passaram por reengenharia;
• Processos de Aprimoramento: Têm objetivos, orçamento e procedimentos para implantar aprimoramentos, podendo incluir a implantação de medição quantitativa.
Segundo Alves (2008 apud BARTI, 2002), a partir do momento que a organização identifica que fabricar software não adequado, prejudica a imagem da organização e aumenta os
custos totais de desenvolvimento, o seu processo de melhoria de processo de software deve assegurar que a nova versão do processo garanta e gerencie o nível de qualidade do produto e do próprio processo de desenvolvimento.
Considerando que a qualidade do produto está diretamente ligada à qualidade do processo, a atividade cíclica de melhoria de processo de software deve possuir meios de controlar estatisticamente a qualidade baseando sua análise na medição do número de defeitos do produto. Mesmo assim, este relacionamento processo/produto é um tanto complexo de se especificar com exatidão, pois depende de processos intelectuais que não podem ser automatizados nem medidos e o andamento do projeto depende das capacidades humanas individuais, onde as pessoas envolvidas são mais importantes do que o processo em si. (SOMMERVILLE, 2007).
Alves (2008 apud Paula Filho 2003) cita alguns benefícios que o estabelecimento de algumas práticas de melhoria de processo de software pode trazer para a organização:
• Capturar um requisito correto é 50 a 200 vezes mais barato que corrigí-lo durante a implementação ou operação. Assim, a engenharia e gestão dos requisitos estão entre as práticas de maior retorno de investimento;
• Fazer um desenho correto é 10 vezes mais barato do que corrigi-lo durante os testes de aceitação. Assim, o desenho tem forte impacto nos custos do projeto, embora menos que a engenharia de requisitos;
• Corrigir defeitos de requisitos, desenho e código consomem 40% a 50% do custo total dos projetos. Assim, a garantia da qualidade se paga rapidamente, à medida que diminui a necessidade de refazer;
• Cada hora gasta em prevenção de defeitos diminui de 3 a 10 horas na correção de defeitos. Assim as atividades de prevenção de defeitos são mais eficazes que as de correção.
Segundo Pressman (2011), a melhoria de processo de software está intimamente relacionada ao custo dos projetos e, consequentemente, ao retorno do investimento, cuja avaliação deve ser feita de forma mensurável. Para ele, existem fatores que são considerados os que mais trazem custo (tempo x dinheiro) para um projeto de desenvolvimento de software e mitigar suas causas proporciona melhora nos indicadores destes fatores (qualitativos) e garante o retorno do investimento:
• Menor propagação de defeitos; • Qualidade do produto;
• Manutenção;
• Suporte do software; • Atraso nas entregas.
2.2.3 Maturidade do Processo na Melhoria de Processo de Software
As abordagens para a melhoria de processo de software avaliam a maturidade do processo de uma organização indicando qualitativamente o seu nível de maturidade.
Por sua vez, a qualidade do produto é refletida pela maturidade do processo de software de uma organização. O processo possui uma série de indicadores que avaliam a sua qualidade através do modelo de maturidade escolhido para aplicar a melhoria de processo de software da organização. A estrutura e os indicadores da abordagem são padronizados e definidos pelo grupo que a desenvolve.
Pressman (2011) afirma que a maioria das abordagens de melhoria no processo de desenvolvimento de software possuem em sua estrutura o seguinte:
• Processo com características definidas, para se obter um processo de desenvolvimento eficaz;
• Um método para verificar se as características definidas estão presentes; • Uma forma de resumir os resultados de uma avaliação qualquer;
• Definição de um método para que a organização possa implementar as características de processo consideradas fracas ou ausentes.
Segundo Montoni (et al., 2008), além da necessidade das novas iniciativas de melhoria de processo de software seguirem as melhores práticas, algumas características necessárias e presentes na arquitetura de sua abordagem:
• Avaliar e identificar na organização os fatores que favorecem o sucesso das iniciativas de melhoria de processo de software, seja no início da implementação e durante o processo; • Agregar este conhecimento através da identificação fatores críticos de sucesso já provados
que atuaram em iniciativas de implementação de melhoria de processo de software, considerando formas de implementação em contextos e características organizacionais distintas;
• Planejar os projetos de melhoria de processo de software através da adaptação de estratégias padronizadas de implementação, adotar estratégias de implementação baseadas em
iniciativas anteriores, assim como monitorar e controlar os projetos de melhoria para assegurar a correta execução do plano;
• Tratar os projetos de melhoria de processo de software como projetos, considerando sempre os fatores particulares de cada projeto, os fatores humanos, o contexto da organização e a seleção da estratégia mais adequada;
• Manter os dados históricos dos projetos de melhoria de processo de software para apoiar a tomada de decisão durante as fases de definição, planejamento e monitoramento, de forma a constituir um repositório de informações (base de conhecimento) de seus diversos itens (equipe, estratégia utilizada, qualidade dos resultados, etc), para posteriormente analisar e assim obter um histórico de desempenho.
Independentemente da abordagem, algumas etapas devem estar presentes no estabelecimento da melhoria de processo de desenvolvimento de software (PRESSMAN, 2011):
• Avaliação do processo de software atual;
• Educação e treinamento dos profissionais e gerentes;
• Seleção e justificativa de elementos do processo, método de engenharia de software e ferramentas;
• Implementação do plano de melhoria;
• Avaliação e ajuste com base nos requisitos e resultados do plano.
2.2.3.1 A Maturidade do Processo de Software
Esforços no sentido de auxiliar na melhoria de qualidade dos processos de software, através de práticas de engenharia de software, têm sido propostos desde a década de 90 através de modelos de maturidade como o CMM (ALVES, 2008 apud PAULK et al., 1993), Spice - ISO/IEC 15504 (ALVES, 2008 apud CÔRTES, 2001), CMMI (ALVES, 2008 apud CMMI-DEV, 2006) e mais recentemente, no Brasil, o MPS.BR (ALVES, 2008 apud MPS.BR, 2004). (ALVES, 2008).
Sintomas de imaturidade, conforme Alves (2008):
• Há projetos mas estes não são definidos com a clareza necessária e suas atividades de desenvolvimento de software acabam disfarças em manutenção;
• As organizações não definem treinamento das equipes como algo prioritário, assim os membros não são treinados corretamente ou por falta de tempo ou por treinamento incorreto;
• Uso de ferramentas que não agregam valor às atividades, não resolvendo os problemas a que foram destinadas;
• Burocracia para os procedimentos e padrões, quando existentes.
Já conforme o Software Engineering Institute Team (ALVES, 2008 apud SEI, 1995), os sintomas da imaturidade nas organizações são:
• Processos de software improvisados, durante o andamento do projeto; • O processo de software foi definido, mas não é fielmente seguido; • Os gerentes estão focados em resolver crises;
• Devido a falta de estimativas efetivas, os prazos e orçamentos são excedidos;
• Falta de informações concretas que fundamente a definição da qualidade do produto ou para estimular a melhoria do processo ou produto;
• Pouca compreensão das equipes de como os passos do processo de qualidade podem afetar a qualidade como um todo.
Para Alves (2008 apud Paula Filho, 2003) a imaturidade traz prejuízos para a organização, a saber:
• O foco do trabalho acaba sendo o atendimento desesperado de prazos, independente da qualidade, tornando-se estressante e excessivo. Consequentemente isso afeta o ambiente de trabalho, tornando-o desgastante e com profissionais desmotivados;
• Não há gerenciamento de projeto e com isso diversos fatores são afetados como problemas de difícil solução, orçamentos e cronogramas atrasados, produtos de baixa qualidade e de difícil uso, além de muitos defeitos, ocasionando retrabalho;
• A gerência perde a credibilidade diante dos gerentes superiores e dos clientes que ficam insatisfeitos devido a defeitos ou por não conseguirem aprender o uso correto;
Nas organizações que possuem um processo maduro, não há interferência da tecnologia adotada na qualidade dos produtos, o processo é instanciável e passível de repetição, ele não depende do talento dos profissionais e é medido. Ao contrário, nas organizações com processos imaturos, existe muito esta dependência e desta forma traz baixa produtividade, alto custo de manutenção, risco na adoção de novas tecnologias e qualidade imprevisível para os projetos. (FERNANDES, 2012 apud SOFTEX, 2009).
Os modelos de maturidade indicam o nível de maturidade do processo de software de uma organização, ou seja, a qualidade do processo de software e o grau no qual os profissionais entendem e aplicam o processo. Este nível de maturidade é deliberado conforme uma escala onde cada nível representa as características do processo num determinado momento. Esta escala ordinal é adequada porque proporciona uma visão clara da qualidade do processo e pode ser utilizada como uma avaliação que serve como base para o planejamento de ações de melhoria. (PRESSMAN, 2011).
Os níveis de maturidade indicam patamares de evolução dos processos onde cada estágio representa uma melhoria na implementação de processos na organização. Identificando o nível de maturidade de uma organização permitirá prever o seu desempenho futuro na execução de seus processos.
Segundo a SOFTEX (2012), o modelo MPS.BR o Modelo de Referência MPS para Software (MR-MPS-SW) a escala de maturidade vai do nível G e avança até o A, onde para cada um é conferido um conjunto de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso nos níveis ocorre quando os processos da organização atendem os propósitos, todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para o nível em questão. Níveis de maturidade MR-MPS-SW:
• G (Parcialmente Gerenciado) • F (Gerenciado) • E (Parcialmente Definido) • D (Largamente Definido) • C (Definido) • B (Gerenciado Quantitativamente) • A (Em Otimização) 2.2.4 O Processo de Melhoria
Segundo Montoni (et al., 2008), é fundamental que o processo de melhoria seja conduzido por profissionais com formação em Engenharia de Software e que conheçam sobre como implementar melhorias em seu processo. Além disso, a organização também deve fornecer condições que apoiem a implementação da melhoria, seja mitigando os fatores críticos que afetam negativamente o processo, ou fomentando o comprometimento das equipes, pois equipes satisfeitas e motivadas tendem a implementar melhorias mais eficientemente.
Para Sommerville (2007), o processo de melhoria de processo de software é contínuo, de longo prazo e personalizado para cada organização, pois cada uma possui características específicas, e deve realizar uma análise prévia que considere fatores organizacionais locais, procedimento e padrões que influenciam o processo, não bastando adotar métodos específicos, ferramentas ou modelos de processo de mercado. Assim, sendo uma atividade cíclica a melhoria de processo de software engloba basicamente os estágios de Medição, Análise e Mudança, abaixo descritos.
A Medição busca medir atributos do projeto ou do produto atual, cujos valores servirão de base para a análise do aprimoramento necessário, conforme os objetivos da organização. Esta fase é que fornece dados quantitativos necessários, por exemplo do esforço e tempo empregados nas atividades, para avaliar a eficiência de um processo. Os dados qualitativos são aqueles relacionados ao processo de desenvolvimento de software e às atitudes da gerência e dos profissionais.
Sugestões de métricas de processo:
• Tempo de conclusão de um processo específico: é o tempo total dedicado a um processo; • Recursos necessário para um processo específico: são os recursos em geral como esforço
despendido, custos de viagem e recursos computacionais;
• Número de ocorrências de um evento específico: pode-se considerar o número de defeitos identificados durante uma inspeção de código ou o número de mudanças de requisitos solicitadas ou o número médio de linhas de código modificada sem resposta a uma mudança de requisitos;
(SOMMERVILLE, 2007).
A Análise do projeto atual proporciona profundo conhecimento, identifica pontos fracos no processo baseado nas medições e desenvolve modelos que substituam estes. Além da análise propriamente dita, a modelagem de processo é outra atividade necessária, pois envolve o estudo do processo existente e o desenvolvimento de um modelo abstrato desse processo que servirá para uma melhor compreensão, representação e comunicação com as equipes.
Segundo Pressman (2011), a modelagem do novo processo deve estar focada nos pontos fracos identificados, iniciando-se pela escolha do melhor modelo que se adapte às características da organização, aos seus interessados e às características do software produzido, observadas as seguintes características:
• Definir o conjunto de atividades de estrutura a ser aplicado; • Definir os principais artefatos que serão produzidos;
• Definir os pontos de verificação de garantia de qualidade que permitirão a equipe acompanhar o progresso.
Técnicas de análise de processo, segundo Sommerville (2007):
• Questionários e entrevistas: Técnica informal e lenta que permite obter informações sobre o andamento do projeto através de perguntas e respostas, que são refinadas durante as entrevistas. Deve ser executado com parcimônia, pois se mal formulado o modelo do processo ficará incompleto ou impreciso;
• Estudos etnográficos: Técnica na qual um conhecimento mais profundo será adquirido pela vivência direta da realidade no contexto onde ele se insere, requerendo a participação do analista desde as fases iniciais de um projeto até a entrega e manutenção do produto. Se apresenta com mais precisão na identificação do processo.
Para Pressman (2011), a Análise também proporciona o momento de verificar se as ações estão sendo executadas conforme as melhores práticas. Isso é possível, independente do modelo de processo escolhido, mas baseada nos mecanismos genéricos da organização (para comunicação com o cliente, como representa os requisitos do usuário, estrutura de gerenciamento de projeto, análise de risco, alterações, qualidade, controle, revisões, etc) através das respostas às seguintes questões:
• O objetivo da ação está claramente definido?
• Os produtos requeridos como entrada e produzidos como saída estão identificados e descritos?
• Os trabalhos a serem realizados estão claramente descritos?
• As pessoas que devem executar as ações estão identificadas de acordo com suas funções?
• Os critérios de entrada e saída foram estabelecidos? • Há ferramentas disponíveis para suportar a ação?
• Há um programa de treinamento explícito que trata da ação? • A ação é executada uniformemente para todos os projetos?
Ainda, ele especifica alguns fatores a serem considerados na Avaliação:
• Consistência: As atividades importantes, ações e tarefas são aplicadas de forma consistente em todos os projetos de software e por todas as equipes de software? • Sofisticação: As ações de gerência e técnica costumam seguir as melhores práticas? • Aceitação: O processo de software e as práticas de engenharia de software são amplamente aceitos pela gerência e pela equipe técnica?
• Compromisso: A gerência forneceu os recursos necessários para se consistência, sofisticação e aceitação?
realização deve vir pautada em objetivos específicos e que servirão de parâmetros para medir o seu progresso, como por exemplo a redução do número de defeitos durante a execução dos testes de integração em 25%. Além disso, assim que executada, seu acompanhamento e aprimoramento tornar-se-á uma tarefa constante e deverá contar com o apoio e o envolvimento das pessoas diretamente ligadas ao processo para o sucesso da implementação da mudança. Fases da mudança de processo:
• Identificação de Aprimoramentos: Analisar o processo, identificar pontos fracos e propor novos procedimentos, métodos e ferramentas;
• Priorização de Aprimoramentos: Avaliar e priorizar as mudanças, considerando custo e impacto;
• Introdução de Mudança de Processo: Implantar novos procedimentos, considerando o planejamento do tempo necessário para a sua integração com as demais atividades do processo e sua compatibilidade;
• Treinamento de Mudanças de Processo: Treinar as equipes para a disseminação do conhecimento e a compreensão dos benefícios da mudança na qualidade do produto;
• Ajuste de Mudanças: Ajustar as mudanças propostas de forma a solucionar pequenos problemas identificados, até que os engenheiros estejam satisfeitos com o novo processo. (SOMMERVILLE, 2007).
Segundo Pressman (2011), ainda há de se considerar que as mudanças podem ser instaladas como uma migração incremental de processo onde, numa abordagem formal, a mudança deve considerar o processo atual, o processo de transição e o processo alvo. Na hipótese do processo alvo ser muito diferente do processo atual, o processo de transição poderá ter diversas etapas, permitindo uma melhor adaptação da cultura da organização às alterações.
De acordo com Pressman (2011), tão relevante quanto a própria melhoria do processo de software é o seu gerenciamento de riscos. Há diversos fatores que fazem com que os esforços em melhoria de processo de software sejam perdidos, destacando os riscos organizacionais, riscos pessoais e riscos de gerenciamento de projetos. Por isso a necessidade de gerenciamento de riscos ocorrer antes de iniciar o processo de melhoria de processo de software, durante a execução de suas atividades e na fase de avaliação.
Fatores de riscos mais relevantes:
• Fatores de risco mais relevantes para os projetos de SPI: • Falta de suporte gerencial;
• Resistência cultural por parte do pessoal técnico;
• Estratégia de melhoria de processo de software mal planejada; • Cronograma mal planejado para a implementação da SPI; • Gerenciamento de projeto para a SPI;
• Abordagem excessivamente formal de melhoria de processo de software; • Escolha de um processo inadequado;
• Falta de pessoal para a SPI;
• Falta de interesse por parte dos principais envolvidos/interessados;
• Orçamento inadequado;
• Falta de treinamento de pessoal; • Instabilidade organizacional;
2.2.5 Fatores de Sucesso na Melhoria de Processo de Software
De acordo com Pressman (2011) alguns fatores devem estar presentes no ambiente onde se deseja introduzir a melhoria de processo de software:
• Comprometimento e suporte da gerência: A alta gerência deve entender que software de qualidade é fruto de um processo de qualidade assim como a necessidade de investir tempo, dinheiro e esforços para o sucesso. A gerência técnica devem se envolver em estratégias de melhoria de processo de software;
• Envolvimento do pessoal: Manter o envolvimento e o comprometimento dos profissionais sem a necessidade de imposição;
• Integração e entendimento do processo: O profundo conhecimento do processo, advindo da fase de análise, garante uma melhor adaptação e integração das novas atividades àquelas existentes, na fase de mudança;
• Estratégia de melhoria de processo de software personalizada: Considerar cada projeto de melhoria de processo de software como único, analisando as especificidades de cada organização, seu contexto, a cultura da equipe, produtos, pontos fortes e fracos.
• Sólido gerenciamento do projeto de melhoria de processo de software: Definir o gerenciamento de projeto como fator impeditivo para todos os projetos sob pena de fracasso, pois como qualquer projeto a melhoria de processo de software requer coordenação, cronograma, tarefas paralelas, resultados práticos, adaptação (quando há risco), políticas, controle de orçamento, etc.
2.2.6 O futuro da Melhoria de Processo de Software
De acordo com Pressman (2011), uma abordagem eficiente considerará características ágeis ao modelo de melhoria de processo de software, com pouco foco organizacional e maior foco na melhoria do projeto de equipe no curto prazo. Para esta efetividade em curto prazo, os modelos
mais simples devem ser adotados em substituição àqueles mais complexos e burocráticos. Um exemplo de boa estrutura dá ênfase apenas a práticas simples, em detrimento a dezenas de práticas chaves e centenas de práticas suplementares.
O conhecimento (educação e treinamento) necessário, como foco somente nas práticas críticas, para se atingir um nível produtivo eficiente custa caro e leva tempo, motivo pelo qual o treinamento à distância vem se apresentando como uma opção atraente nos últimos anos.
Para evitar o choque de mudança cultural, uma boa abordagem para dar início dos esforços de melhoria de processo de software numa organização é começar por um pequeno grupo de mudanças de cada vez para que os demais possam observar a mudança de cultura e os resultados obtidos.
2.3 DIAGNÓSTICO DE PROCESSO DE SOFTWARE
Segundo Paula Filho (et al., 2003) a fase de diagnóstico, que precede a fase de melhoria de processo de software e é uma das fases mais importantes, tem por objetivo obter um entendimento detalhado do processo e servir de base para o programa de melhoria, independentemente da metodologia de melhoria de processo de software escolhida pela organização. Este entendimento é obtido através de atividades de avaliação que são realizadas a fim de obter a especificação do estado atual do processo de software da organização, as principais características do processo, pontos fortes e fracos, assim como as oportunidades de melhoria. Feitas as avaliações, entendido o estado atual e definido o estado desejado, então são propostos um conjunto de recomendações para atingir este objetivo, os quais poderão compor um relatório de diagnóstico. (PAULA FILHO et al., 2003; FERNANDES 2012).
Avaliar o processo de software atual de uma organização ou medir os avanços de uma implementação de melhoria são o foco das avaliações formais como o SCAMPI (Standard CMMI
Appraisal Method for Process Improvement) para o CMMI (Capability Maturity Model Integration). O problema destes modelos formais é que possuem um alto rigor e custos associados.
(PRIKLADNICKI et al., 2005).
Em programas de melhoria de processos de software é comum o uso de ciclos sucessivos de melhoria, com avaliações de alguma natureza (formais ou informais) em cada ciclo ou em pontos-chave, para medir o avanço dos objetivos de melhoria estabelecidos (PRIKLADNICKI et al., 2005 apud ANACLETO et. al., 2005).
Prikladnicki (et al., 2005) cita os 2 (dois) principais métodos de avaliação formais aplicáveis aos modelos SW-CMM e CMMI, a saber:
SCAMPI
O método SCAMPI (The Standard CMMI® Appraisal Method for Process Improvement) é geralmente aplicado para o modelo CMMI, mas também pode ser aplicado para o SW-CMM. O SCAMPI também foi publicado em 2001 (SEI, 2001), e possui três classes de avaliação, quais sejam: classe A, classe B e classe C. As avaliações de classe A são consideradas avaliações oficiais, onde a empresa é oficialmente reconhecida em um nível de maturidade. As avaliações de classe B são mini-avaliações ou avaliações não oficiais cujo objetivo é verificar oportunidades de melhoria ou prontidão de uma empresa para ser submetida a uma avaliação oficial. Esta avaliação requer menos tempo do que a avaliação de classe A, e tem como resultado um plano de ação para completar as práticas do CMMI não atendidas. O propósito é dirigido a descobrir não-conformidades com base na informação fornecida pelas equipes dos projetos. Por fim, as avaliações de classe C ou gap
analysis são utilizadas para identificar oportunidades de melhoria e tomar ações coerentes à
realidade e aos objetivos das empresas. São identificadas lacunas existentes do atual processo de desenvolvimento de software das empresas, comparando-as com as práticas do modelo de referência. Os resultados gerados são um relatório e um plano de ação para a
implantação de um programa gradual de melhoria. CBA IPI
O método de avaliação CBA IPI (CMM Based Appraisal for Internal Process
Improvement), é um método de diagnóstico que permite a uma organização obter
informações sobre a maturidade de seu processo de desenvolvimento de software. Isto é feito identificando pontos fortes e fracos (oportunidades de melhoria) de seu processo atual com relação ao modelo CMM. Desta maneira, é possível atribuir prioridades às oportunidades de melhoria e focalizá-las, levando-se em consideração o nível de maturidade da organização e os seus objetivos do negócio.
Neste método, a avaliação é feita por um grupo treinado de profissionais atuando em equipe que, a partir da análise de documentação dos projetos, de respostas a questionários e de entrevistas realizadas com os gerentes, líderes de projeto e desenvolvedores, obtém dados suficientes para identificar evidências relacionadas às áreas de processo do CMM, observando o contexto da avaliação e confidencialidade. O método consiste de três fases. A primeira inclui atividades necessárias para planejar e preparar a avaliação. A segunda é formada por atividades que conduzem a avaliação no local a ser avaliado, incluindo técnicas de coleta, organização e consolidação dos dados. Já a terceira e última fase consiste em apresentar os resultados da avaliação, identificar melhorias no processo e enviar os resultados para o SEI. O método foi publicado pelo SEI em 2001 (Dunaway, 2001).
Segundo o estudo realizado por Fernandes (et al., 2012), onde o foco foi a busca de informações que apresentassem a forma como são realizados os diagnósticos de processo de software nas organizações que os desenvolvem, verificando se o grau de qualidade do diagnóstico automatizado é similar ou inferior ao diagnóstico realizado manualmente, não há uma metodologia definida para a realização do diagnóstico de processo e, na sua maioria, são realizados de forma manual, sem a utilização de técnicas de inteligência artificial e cuja análise das respostas é realizada por um especialista do modelo. Isto traz maior complexidade e custo para o processo de diagnóstico, cuja qualidade dependerá exclusivamente da experiência do especialista e da qualidade dos questionários.
Diante da constatação acima e da necessidade crescente da melhoria de processos de software, muitas organizações têm desenvolvido e empregado métodos de avaliação simplificados na forma de mini-avaliação ou avaliação de diagnóstico para embasar o planejamento de suas iniciativas de melhoria de processo, entretanto, são poucos os registros na literatura que explanam como estas avaliações foram realizadas. (PRIKLADNICKI et al., 2005).
Conforme Prikladnicki (et al., 2005) abaixo a descrição dos objetivos destas avaliações simplificadas:
• Mini-avaliação: Objetiva avaliar a situação da implantação dos modelos, identificar pontos fortes e fracos (oportunidades de melhoria), treinar a equipe de projeto em melhoria de processo de software, servir de catalisador para o programa de melhoria, preparar a
