• Nenhum resultado encontrado

Capítulo 2 Avaliação e Melhoria de Processos de Software

2.4 Avaliações de processos de software (SPA)

O propósito da avaliação de processos de software é identificar as áreas prioritárias para melhorias e prover algum tipo de orientação sobre como fazer estas melhorias (HUMPHREY, 1989). ARES (2000) argumenta que as avaliações de processos de software devem ser mais rigorosas, incorporando os princípios da Teoria da Avaliação [Evaluation Theory – (SCRIVEM, 1991)], que foi desenvolvida inicialmente para aplicação em áreas como psicologia, educação e avaliação de projetos.

2.4.1 Teoria da Avaliação

Uma avaliação rigorosa é baseada em uma fundamentação teórica, levando a uma avaliação mais compreensível e confiável. A teoria de avaliação (SCRIVEN, 1991) descreve os componentes que deveriam estar presentes em uma avaliação rigorosa:

 Objeto da avaliação: O elemento a ser avaliado.

 Critérios: As características do objeto que serão avaliadas.

 Padrão de referência: Um padrão com o qual o elemento avaliado possa ser comparado.

 Técnicas de avaliação: As técnicas necessárias para avaliar cada um dos critérios definidos.

 Técnicas de síntese: Técnicas utilizadas para organizar e sintetizar as informações obtidas, permitindo a comparação com o Padrão de Referência.  Processo de avaliação: As atividades e tarefas que definem a avaliação,

organizadas na forma de um processo.

Para cada tipo de avaliação esses componentes devem ser desenvolvidos, conforme a metodologia da figura 2-4, proposta por ARES (2000). Uma vez que o objeto a ser avaliado seja definido, e delimitado, as características a serem avaliadas podem ser definidas.

Delimitação do objeto Definição do critério de avaliação Desenvolvimento do padrão de referência Desenvolvimento das técnicas de avaliação Desenvolvimento das técnicas de sintese Desenvolvimento do processo de avaliação

Cada característica do objeto avaliado deve ter um valor ideal associado, ou seja, um valor que o objeto deveria ter no caso de uma avaliação positiva. O conjunto destes valores esperados para todas as características compõem o padrão de referência. Devem ser coletados dados sobre a real situação do objeto avaliado, usando alguma técnica de avaliação para identificar os valores a serem atribuídos às características do objeto (ARES et al., 2000). Tendo sido coletados os dados sobre o objeto, esses devem ser organizados em uma estrutura apropriada e comparados com o padrão de referência, aplicando-se as técnicas de síntese desenvolvidas. Esta comparação será o resultado final da avaliação. Como não foi identificado na revisão da literatura um método de avaliação específico para ativos de processos de software, a metodologia proposta por ARES (2000) pode ser utilizada para a criação de um método com este propósito.

Quando todos os componentes de uma avaliação estão desenvolvidos, esta deve ser conduzida conforme o processo definido. PATTON (1991) propõe uma estrutura genérica de fases para o processo de avaliação como a da figura 2-5.

Necessidade de informação Coleta dos dados Análise dos dados Planejamento Relato dos achados Desenvolvimento do escopo Realimentação Decisão

Figura 2-5 Fases de um processo de avaliação (PATTON, 1991)

A Necessidade de Informação, na figura 2-5, não faz parte do processo de avaliação, mas é onde surge a motivação para a realização da avaliação. Quando as avaliações têm como meta a melhoria dos processos, esta necessidade está relacionada a

No contexto dos objetivos dessa tese essa Necessidade de Informação é a necessidade da instituição implementadora avaliar a qualidade dos ativos de processos que produz.

Na fase Desenvolvimento do Escopo são definidos os objetivos específicos da avaliação, formuladas as questões orientadoras, devendo ficar bem claros os motivos pelos quais a avaliação está sendo executada. A fase Planejamento inicia com a definição das fontes de informação que irão prover os dados que permitirão após as análises responder as questões formuladas. Também são definidas nesta fase as formas de coleta de dados.

A coleta de dados pode ser feita de diferentes maneiras, dependendo dos propósitos e objeto em avaliação. Os instrumentos mais comuns são (PATTON, 1991):

Questionários: Devem ter uma explicação na seção inicial informando os propósitos com orientações para o respondente. Não devem ser longos, tendo questões abertas e fechadas. Devem finalizar com os agradecimentos e informações sobre a divulgação dos resultados. Versões dos questionários devem passar por avaliações piloto e melhoradas até estarem prontas para a aplicação definitiva.

Observações: Ajudam a entender melhor as situações relacionadas com os objetos avaliados. É importante que sejam bem focadas, para não capturar dados desnecessários que não colaborem para atender os objetivos da avaliação. Deve- se focar na coleta de dados e evitar as interpretações precipitadas, deixando a análise dos dados para após todas as coletas terem sido realizadas.

Estudo de documentos: Inicialmente devem-se selecionar os documentos a serem estudados e, para cada tipo de documento, decidir quais informações serão consideradas.

Entrevistas: Requerem profissionais com habilidades de comunicação para que bons dados sejam coletados, pois o entrevistador tem que saber lidar com os entrevistados, tornando-os cooperativos com a avaliação. Tipicamente os avaliadores são “temidos” pelos entrevistados, que ficam nervosos. Entrevistas podem ser estruturadas (questões preparadas), semi-estruturadas ou não- estruturadas.

Para a situação específica da avaliação de ativos de processos de software, os questionários são os instrumentos mais adequados para a coleta de dados, pois permitem uma avaliação mais objetiva, repetível, podendo ser aplicados em várias organizações de forma mais uniforme.

A fase Análise dos Dados sintetiza e interpreta os dados coletados. O Relato dos achados deve focar em responder às questões estabelecidas no Desenvolvimento do Escopo, usando como base os resultados da análise dos dados. Recomendações de melhoria, também, devem ser indicadas, e suas relações com os aspectos avaliados estabelecida. Finalmente, os resultados da avaliação devem ser apresentados aos interessados, e eventualmente ajustados. No caso de uma avaliação cujos objetivos sejam a melhoria dos processos, a fase de decisão estaria associada às ações de melhoria executadas a partir das recomendações da avaliação.

Tanto a metodologia proposta por ARES (2000), quanto o processo de SCRIVEN (1991), são genéricos, e não possuem uma orientação específica para ativos de processos de software. Portanto, não são de aplicação imediata no problema dessa tese, mas podem ser utilizados para o desenvolvimento de um método de avaliação que trate os propósitos dessa tese.

2.4.2 Abordagens de Avaliação de processos de software

Na maioria das abordagens de avaliação de processos existe algum tipo de modelo/método que identifica pontos fracos e fortes do processo. O resultado da avaliação também pode ser utilizado como uma fonte de confiança de que a organização irá cumprir seus compromissos, ou seja, uma organização que foi avaliada positivamente teria menos riscos em não cumprir seus prazos, custos e qualidade. Diferente das medições que ocorrem simultaneamente à execução dos processos, as avaliações ocorrem periodicamente em intervalos definidos pelo interesse da organização avaliada. A avaliação de processos é realizada nas organizações de software das mais variadas formas. WANG (2002) propõe a seguinte categorização para as abordagens de avaliação de processos de software (SPA):

 SPA com base em modelos de referência;  SPA com base em Benchmarks;

 SPA com base em normas;

Uma avaliação baseada em modelo é aquela em que os processos da organização são avaliados em relação a um modelo de referência de processos, seguindo um método

avaliação usa uma escala absoluta que é o modelo de referência. Encaixam-se nesta categoria o SCAMPI - Standard CMMI Appraisal Method for Process Improvement (DENNIS, 2005) e o MA-MPS (SOFTEX, 2007). Esse tipo de avaliação verifica se os processos em execução na organização são aderentes ao que é indicado no modelo de referência. Como resultado fornece o nível de maturidade obtido e os pontos fracos e oportunidades de melhoria dos processos, servindo como base para posteriores ações de melhoria.

O SPICE (Software Process Improvement and Capability dEtermination) foi um projeto internacional (EMAM et al., 1998), com participação de representantes de 25 países, que desenvolveu a norma internacional para avaliação de processos, a ISO- 15504 Information Tecnology-Process Assessment (ISO, 2003). A ISO 15504 provê um framework para a avaliação de processos de software, que pode ser usado por organizações envolvidas com o planejamento, monitoração, controle, aquisição, fornecimento, desenvolvimento, operação, evolução, e suporte a software. A ISO-15504 define um conjunto de requisitos que uma avaliação de processos deve ter. Isso permite muita flexibilidade, pois podem existir diferentes modelos/métodos de avaliação, usando diferentes modelos de processo de referência, podendo ser todos conformes à norma. O método MA-MPS (SOFTEX, 2006) é um exemplo de método de avaliação definido em conformidade com a norma ISO-15504.

Os métodos de avaliação baseados em modelos de maturidade atendem ao propósito para o qual foram criados, mas muitas vezes geram um efeito colateral, que é levar a organização de software a só valorizar a perspectiva que será verificada em uma avaliação da maturidade. Essas avaliações também não consideram se o processo em execução na organização é eficaz ou eficiente, mas somente se é aderente ao modelo de maturidade, gerando alguns antagonismos, onde processos podem ser ineficazes e ineficientes, e ao mesmo tempo aderentes ao modelo de maturidade. Avaliações da maturidade são importantes em uma estratégia de melhoria de processos, mas a organização considerar apenas a perspectiva da aderência a um modelo em suas estratégias de melhoria é uma visão limitada da qualidade dos processos.

Outro aspecto relativo às abordagens de avaliação, envolvendo algum tipo de “certificação”, é que não existe uma motivação dos profissionais da organização avaliada em expor aos avaliadores os problemas que eles julguem existir, pois isso poderia prejudicar a organização avaliada a “passar” na avaliação. Essa postura não impede que os avaliadores identifiquem os principais problemas em relação ao modelo

de referência, mas filtra uma série de outros problemas que poderiam ser apontados, entre eles problemas relativos aos ativos de processo de software utilizados.

Uma avaliação baseada em Benchmark é uma abordagem de avaliação relativa, onde os dados de desempenho dos processos da organização são comparados com dados de organizações semelhantes, ou uma média de um dado setor (JONES, 2000). O resultado para cada processo indica se o desempenho do mesmo se encontra abaixo, igual, ou acima dos valores de referência. Em avaliações baseadas em Benchmarks buscam-se dados quantitativos do desempenho dos processos, tais como: esforço, duração, tamanho e quantidade de defeitos. É estabelecida uma baseline do desempenho dos processos organizacionais, para posteriormente se comparar com dados de bases históricas de organizações no mesmo contexto, sabendo-se a partir da comparação como a organização se situa entre as suas semelhantes. Sucessivas baselines ao longo do tempo vão permitir à organização acompanhar sua evolução. Nesse caso, as avaliações usam uma escala relativa, pois podem ser feitas comparações de diversos tipos. A abordagem proposta pelo Software Productivity Research (SPR) (JONES, 2000) é uma avaliação dessa categoria.

No caso de avaliações de ativos de processos não seria aplicável uma avaliação baseada em Benchmark, pois não existem dados de avaliações para se fazer qualquer tipo de comparação. Entretanto, seria interessante algum tipo de comparação entre diferentes variações de um mesmo ativo de processos, permitindo avaliar qual estaria melhor qualificado.

Uma avaliação baseada em normas verifica a conformidade dos processos da organização com os requisitos de uma norma. Existe um conjunto de requisitos que devem ser atendidos e o avaliador segue uma lista de verificação (checkList), verificando se os requisitos estão atendidos ou não. Se todos os requisitos estabelecidos forem atendidos, a organização é declarada como estando em conformidade com os requisitos (WANG, 2000). Nesse caso também se define o processo de avaliação e as qualificações do avaliador autorizado. A avaliação do sistema de gestão da qualidade da ISO-9000 se enquadra nesse grupo.

O propósito das abordagens de avaliação é fornecer informações objetivas para que possa ser feito um planejamento e execução das ações de melhoria, portanto o resultado das abordagens de avaliação serve de entrada para as abordagens de melhoria.