MODELO DE PRIORIZAÇÃO DE
ATIVIDADES EM PROJETO DE TI: UMA
PROPOSTA UTILIZANDO O MÉTODO
PROMETHEE DE CLASSIFICAÇÃO
Marilia Florencio Santos (UFPE)
lilahfs@hotmail.com
Caroline Maria de Miranda Mota (UFPE)
carolmm@ufpe.br
ANDRE MORAIS GURGEL (UFPE)
andmgurgel@gmail.com
Atualmente é crescente o investimentos das empresas em projetos de tecnologia da informação. Por isso, o seu gerenciamento vem se mostrando cada vez mais necessário. Este trabalho desenvolveu um modelo baseado no método multicritério PROMETTHEE de classificação para a priorização de atividades de TI em processos de replanejamento a partir dos critérios definidos pelo decisor que seguem a visão da classificação por nível de criticidade. A modelagem desenvolvida foi aplicada a uma empresa do ramo e se mostrou eficaz e robusta.
Palavras-chaves: Gestão de Projetos, Priorização de Atividades, TI, PROMETHEE
2
1. Introdução
Projeto significa esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Gerenciá-lo é aplicar conhecimentos, habilidades, ferramentas e técnicas às suas atividades com o objetivo de atender a seus requisitos (PMI, 2004).
A gestão de projetos exerce um papel importante na sociedade atual tendo a globalização grande influencia nesse acontecimento. Kerzner (2002) a define como o planejamento, programação e controle de uma série de tarefas integradas voltadas a atingir um objetivo específico com êxito.
Os projetos de Tecnologia da Informação têm como característica sua alta complexidade, e envolvem, além de todas as dificuldades relacionadas ao uso e programação de software, o tempo reduzido para entrega. Isto pode propiciar o surgimento de falhas durante o processo de desenvolvimento ou no produto final.
Para Cormican e O’Sullivan (2004) projetos de TI são caracterizados, em geral, por uma definição inadequada do escopo, não possuírem instruções bem documentadas, e em alguns casos, não fornecerem uma base de dados confiável de projetos anteriores. Além disto, estes envolvem um grande número de iterações e uma constante interação entre todos os envolvidos. Tornando assim o trabalho interdependente e gerando necessidade de comunicação eficiente entre a equipe.
As principais falhas apresentadas no desenvolvimento de projetos de TI relatadas em levantamento realizado por Hinde (2005) são gastos acima do orçamento, falta de economia ou funcionalidade demandada pelo negócio e por seus usuários, atrasos na entrega, riscos não considerados, falta de controle efetivo sobre o desenvolvimento do processo e finalmente a falta de investimento no treinamento adequado do pessoal e nas perspectivas dos usuários. Por isto, há uma necessidade de prover mecanismos de replanejamento em situações de mudanças no cenário em que o projeto está inserido. Caso esse replanejamento venha a se tornar um imperativo, cabe ao gerente identificar quais atividades precisarão ser mantidas, devido a restrições de precedência, de recursos ou impostas por stakeholders, e quais poderão ser postergardas.
Considerando o ambiente dinâmico da TI, este trabalho apresenta um modelo para auxiliar o gerenciamento de projetos, levando em consideração as prioridades das atividades e recursos necessários para execução. O modelo proposto tem como objetivo classificar, utilizando como base o método multicritério PROMETHEE II, as atividades a serem desenvolvidas no projeto em função da sua prioridade global, considerando seu impacto no projeto como um todo. Na seção seguinte é apresentado um breve referencial teórico no tema Métodos Multicritério de Apoio a Decisão. A seção 3 compreende a justificativa da seleção do método usado na elaboração do modelo bem como uma apresentação de conceitos utilizados para o desenvolvimento do mesmo. A seção 4 traz a aplicação do modelo como base no estudo de caso realizado. A seção 5 trata das considerações finais do trabalho realizado, apresenta análise de resultados e limitações do modelo.
2. Métodos Multicritério de Apoio a Decisão
Os métodos Multicritério de Apoio a Decisão (MCDA) surgiram a partir da limitação dos métodos clássicos de Pesquisa Operacional em solucionar sistemas mais complexos, nos quais não convinha analisar o problema sob apenas um aspecto, mas sim sob sua totalidade. Os métodos MCDA foram desenvolvidos então de forma a possibilitar a solução de problemas
3 onde estão presentes vários objetivos, e principalmente quando estes não podem ser representados por uma mesma unidade de medida, como por exemplo, na indústria de serviços.
A depender do número de alternativas possíveis no problema, ele pode ser classificado como discreto ou contínuo. Discreto, quando a quantidade de alternativas for finita, e contínuo, quando se pode considerar que o conjunto de alternativas é infinitamente grande. Estes podem ser resolvidos através de programação matemática multiobjetivo, os chamados métodos de otimização multicritério. Já para aqueles onde a quantidade de alternativas é finita existem métodos de apoio a problemas discretos de decisão.
Além do fato de os métodos clássicos serem mono-critério, outro fator importante e que difere os métodos MCDA dos já existentes é a presença da subjetividade no processo decisório. Nesse caso, existem um ou mais decisores cujas preferencias são levadas em consideração durante a elaboração do modelo. Portanto, a depender do decisor e, consequentemente, de sua estrutura de preferencias, a partir de um mesmo problema poderão ser originados diversos modelos.
Roy (1993) apresenta fatores que justificam a impossibilidade de se buscar uma solução (decisão) objetivamente ótima:
a) É difícil estabelecer a fronteira entre as decisões praticáveis e as impraticáveis, e esta pode evoluir ao longo do tempo;
b) Os dados estão sujeitos a imprecisão, incerteza e a arbitrariedade;
c) Há casos em que não existe apenas um decisor, mas sim múltiplos decisores cujas preferencias nem sempre são estáveis e firmemente estabelecidas por estarem sujeitas a indefinições, contradições e conflitos internos;
d) As preferencias não são vistas como sendo preexistentes, elas vão sendo construídas ao longo do processo de decisão;
e) Em geral, uma decisão não pode ser considerada boa ou má tomando-se por base um modelo matemático sem atender aos aspectos organizacionais, pedagógicos e culturais de todo o processo de decisão, que por vezes não são incluídos no modelo.
Vale salientar que, devido a natureza conflitante dos diversos critérios envolvidos, muitas vezes não é possível que os métodos MCDA forneçam a solução ideal que otimize todos esses critérios ao mesmo tempo, o objetivo do método multicritério é fornecer a melhor solução dentre as alternativas existentes. Buscando, dessa forma, estabelecer o ótimo de Pareto definido por Silva (1997) como o conjunto de soluções viáveis e que possuam desempenho igual ou superior as demais alternativas, sendo estritamente preferíveis às outras em ao menos um critério.
Existe um grande numero de métodos MCDA e cada um deles é baseado na estrutura de preferencias pressuposta para o decisor, que geralmente é representada por uma função utilidade ou por relações de sobreclassificação.
Métodos que assumem relações de sobreclassificação são baseados na suposição de que a estrutura de preferencias do decisor pode ser representada através de relações de sobreclassificação par a par entre as alternativas. PROMETHEE e ELECTRE são famílias de métodos de sobreclassificação já renomados, representantes da Escola Francesa (ÖZEROL e KARASAKAL, 2007).
4 de fatores. Após considerar a multiplicidade de critérios envolvidos, além da avaliação do problema, o contexto, a estrutura de preferencias do decisor e a problemática envolvida em questão, cabe atentar para a racionalidade que mais convenha ao decisor, por isso é fundamental analisar a necessidade ou não de um método compensatório (ALMEIDA, 2010).
3. Modelo de Classificação para Priorização das Atividades
A estruturação do método multicritério para a priorização das atividades utilizou-se de três critérios, definidos pelo decisor, que foram: o setor da empresa, a prioridade da atividade e o esforço necessário para a sua realização. Atendendo às muitas características do problema e pela facilidade de aplicação e entendimento por parte do decisor, o método selecionado neste trabalho foi o PROMETHEE de classificação, proposto por Cavalcante (2005).
Segundo Almeida (2010), a família de métodos PROMETHEE apresenta avaliações não-compensatórias e se baseia na comparação par a par entre alternativas de forma a explorar as relações de sobreclassificação entre elas.
O decisor estabelece os critérios(xi) e pesos(pi) e para obtenção do grau de sobreclassificação de a sobre b calcula-se:
Fi(a.b) pode assumir 6 diferentes tipos de funções, a depender das preferencias do decisor. Em seguida, explora-se a relação de sobreclassificação que dará apoio a decisão, são calculados os fluxos positivo e negativos, que funcionam como indicadores de preferencia de uma alternativa sobre todas as outras e a intensidade de preferencia de todas as outras alternativas em relação a uma, respectivamente.
O PROMETHEE II estabelece uma ordem completa através das relações entre os fluxos líquidos das alternativas, que consiste no calculo de:
O método PROMETHEE de classificação propõe a classificação das alternativas em categorias C1,C2,.., Cq ,este método consiste na comparação do conjunto de alternativas A={a1, a2, ...,am} com perfis de referência rk, para k=1,..n, que são os pontos de referencia que separam as classes consecutivas. Para m critérios g={g1, g2,...gn}, alternativas e perfis são comparados par a par, e através da aplicação do PROMETHEE II é obtida uma pré-ordem, que irá ser usada para classificar a alternativa entre os perfis de referencia, que a antecede e a sucede (CAVALCANTE, 2005).
4. Aplicação do Modelo
A aplicação do modelo será realizada em um projeto de tecnologia da informação que está sendo desenvolvido por uma empresa multinacional de grande porte que atua no setor de alumínio.
5 em especial no chão de fábrica de uma de suas unidades. O novo sistema envolve muitas áreas da empresa, e estas incluem: Comercial, Financeira, PCP, Produção, Qualidade e Expedição. A quantidade de pessoas na equipe ultrapassa os 100 e são inúmeros os stakeholders envolvidos no projeto.
O projeto foi dividido em 6 grandes fases descritas a seguir:
a) Project start up: são realizadas todas as atividades de iniciação do projeto, como obtenção do compromisso das lideranças e dos recursos necessários à implantação do novo sistema, quantificar benefícios, definir escopo e preparar o plano em alto nível do projeto.
b) Project Focus: fase de validação do escopo do projeto, assim como o plano de comunicação e gerenciamento de mudanças, os controles para os riscos e o planejamento de uma forma geral.
c) Design Build and Test: sob o ponto de vista da gerente, é considerada a fase de maior importância, nela são alinhadas as expectativas dos usuários com os desenvolvedores, são identificados os ajustes, diferenças e oportunidades. Equipes recebem treinamentos básicos e o desenho detalhado inicial do novo sistema é finalizado, concluindo a definição d etudo que será realizado durante o projeto. Esta fase toma metade do prazo de todo o projeto.
d) Validate Solution: após desenho, construção e testes, o sistema é validado pela empresa e deve-se iniciar a elaboração do plano de corte para a conversão dos dados do sistema antigo para o novo. Também são realizados o ajuste fino de relatórios, interfaces e configurações do programa, e são preparadas as turmas de treinamento para os usuários do novo sistema.
e) Deploy: o plano de corte é validado e os treinamentos com os usuários são realizados. São realizadas simulações “day in life” com os usuários nas plantas, e levantadas as opções de melhoria do sistema.
f) Stabilize: o sistema é estabilizado e enfim pode ser feito o suporte da equipe responsável por sustentar a ultilizaçao do novo sistema na empresa no lugar da equipe de gerenciamento do projeto. cada uma delas possuindo diferente nível de participação de cada uma das frentes de trabalho.
São, no total, 6 frentes de trabalho e 49 as atividades a serem realizadas no projeto, sendo 5 delas consideradas showstoppers, ou seja, não podem ser reprogramadas. Por isso, o trabalho trata da classificação das 44 atividades restantes que poderão ser reprogramadas.
Os dados utilizados no estudo são secundários e foram obtidos a partir de trabalho realizados por Andrade (2010).
4.1 Identificação do Cenário
O gerente do projeto foi identificado como o ator do processo decisório. É ele, considerado como o único decisor quem fornecerá informações sobre as atividades e recursos do projeto, o tipo de função, os critérios a serem adotados na elaboração do modelo, os pesos relativos a esses critérios e informações sobre as variações de valores para casa alternativa que irão determinar a escolha do critério geral.
4.2 Identificação das Alternativas
Foram identificadas pelo gerente do projeto (decisor) carência de recursos humanos e tempo para a realização das atividades conforme a programação inicial.
6 O projeto se encontra em fase de Deploy, que consiste basicamente no levantamento de opções para melhoria do sistema e ajustes no software. Essa fase demonstrou a necessitar mais esforço do que o previsto e cabe ao gerente do projeto disponibilizar os recursos para sua execução. No entanto, por restrições de fluxo de caixa e prévia negociação com as partes interessadas, o projeto não poderá ter sua data de entrada adiada.
Por se tratar de um projeto de TI, o projeto requer uma mão-de-obra extremamente especializada e já familiarizada às operações da empresa, não sendo recomendável, portanto, a contratação de recurso adicional. Devido a isso, a solução sugerida é a criação de classes que identifiquem as atividades de acordo com o nível de atenção requerido. As classes C1, C2 e C3 representam respectivamente as atividades que necessitam menor, média e maior atenção. De um total de 49 atividades a serem realizadas durante o projeto, as atividades A4, A5, A6, A17 e A19 possuem restrição em relação a sua postergação, por isso não serão consideradas durante o processo de decisão. O gerente forneceu a avaliação dos critérios das atividades (Anexo 1) a serem classificadas. Considera-se, a termos de simplificação, que todas as atividades requerem a utilização do mesmo tipo de recurso.
4.3 Definição dos Critérios
O gerente do projeto apontou três critérios a serem considerados durante o processo decisório. a) O setor da empresa no qual a atividade está inserida (x1): chão de fábrica, manufatura,
ordem de produção ou todos os setores;
b) A prioridade da atividade (x2): baixa, média, alta ou crítica;
c) O esforço necessário para realizar a atividade (x3): muito baixo, baixo, médio, alto ou muito alto.
As tabelas 1 a 3 apresentam a avaliação dos critérios e sua conversão em escala numérica.
Setor da Empresa (x1) Chao de Fabrica 1 Manufatura 2 Ordem de Produção 2 Todos os setores 3 Fonte: Autores
Tabela 1- Escala numérica de avaliação critério x1
Prioridade (x2) Baixa 1 Média 2 Alta 3 Crítica 4 Fonte: Autores
Tabela 2 – Escala numérica de avaliação critério x2
Esforço requerido (x3)
7 Baixo 4 Médio 3 Alto 2 Muito Alto 1 Fonte: Autores
Tabela 3 - Escala numérica de avaliação critério x3
São prioritárias as atividades que possuem os maiores valores de julgamento para os critérios, portanto todas as funções são de maximização. A tabela com a avaliação para cada critério de todas as atividades se encontra no anexo deste artigo.
Os pesos dos critérios foram obtidos através de um processo de elicitação junto ao gerente do projeto, que determinou que a importância do critério x2 é a maior dentre os 3 critérios, os critérios x1 e x3 possuem o mesmo nível de importância, e que x2 não apresenta maior importância do que os dois critérios restantes juntos. Como para o decisor não existem limites de preferencia ou indiferença, o critério geral a ser adotado para a elaboração das funções de preferencia F(a,b) é o tipo I. A tabela 4 apresenta os pesos adotados no modelo bem como o critério geral.
Critério Peso Tipo
x1 0,1 I
x2 0,5 I
x3 0,4 I
Fonte: Autores
Tabela 4 – Pesos e critério geral
4.4 Definição das Classes e Procedimento de Classificação
Foram designadas 3 classes de atividades de acordo com o nível de atenção requerido, e elas se dividem em menor atenção(C1), atenção média (C2) e maior atenção (C3). Para definir as classes do modelo foi necessário estabelecer os limiares r1 e r2 que as separam, os perfis de referencia. Os perfis correspondem a alternativas que não necessariamente pertencem ao grupo de análise, mas que, assim como as alternativas do problema, carregam informações sobre seu desempenho para cada um dos critérios considerados. A tabela 5 exibe o valores assumidos para r1 e r2 de acordo com a preferencia do decisor, e os padrões das classes.
x1 x2 x3 r1 = Separa C1 de C2 1 2 2 r2 = Separa C2 de C3 2 3 4 Fonte: Autores
Tabela 5 – Padrões de referencia para os perfis de classe
Na situação em questão, a preferencia aumenta a medida que o valor de cada critério é aumentado. A Figura 1 faz uma representação do esquema das classes.
8 Figura 1- esquema das classes e perfis
Após definidos os perfis de referencia, a próxima etapa é a aplicação do método multicritério selecionado para a obtenção de uma ordem completa. Uma a uma, todas as alternativas são confrontadas, através da aplicação do PROMETHEE II, com os perfis de referencia. A classificação é realizada por meio da comparação dos fluxos líquidos de cada alternativa com os fluxos líquidos de cada perfil. Como explicitado abaixo:
Se Φ(Ai) ≥ Φ(r2), então a atividade fará parte da classe C3
Se Φ(r1) ≤ Φ(Ai) < Φ(r2), então a atividade fará parte da classe C2 Se Φ(Ai) < Φ(r1), então a atividade fará parte da classe C1
A Tabela 6 apresenta os resultados obtidos da aplicação do PROMETHEE II e a classificação das atividades.
Alternativa Fluxo (Ai) Fluxo (r1) Fluxo (r2) Baixa PrIordade Média Prioridade Alta Prioridade
A1 0,35 -0,8 0,45 X A2 0,55 -1 0,45 X A3 0,55 -1 0,45 X X A7 0,3 -1 0,7 X A8 0,3 -1 0,7 X A9 0,1 -0,8 0,7 X A10 0 -0,75 -0,75 X A11 -0,2 -0,75 -0,95 X A12 0 -0,75 -0,75 X A13 -0,6 -0,35 -0,95 X A14 -0,2 -0,75 -0,95 X A15 0,55 -1 0,45 X A16 0,3 -1 0,7 X A18 0,3 -1 0,7 X A20 0,3 -1 0,7 X A21 0,3 -1 0,7 X A22 0,1 -0,8 0,7 X A23 0,1 -0,8 0,7 X A24 0 -0,75 -0,75 X A25 -0,4 -0,55 -0,95 X A26 -0,2 -0,75 -0,95 X C1 C2 C3 x1 x2 x3 r1 r2
9 A27 0,45 -0,95 0,5 X A28 0,45 -0,95 0,5 X A29 0,25 -0,75 0,5 X A30 0,25 -0,75 0,5 X A31 0,45 -0,95 0,5 X A32 0 -0,75 0,75 X A33 0 -0,75 0,75 X A34 0 -0,75 0,75 X A35 0,4 -0,95 0,55 X A36 0 -0,75 0,75 X A37 0 -0,75 0,75 X A38 0,2 -0,95 0,75 X A39 0,2 -0,95 0,75 X A40 -0,2 -0,55 0,75 X A41 -0,2 -0,55 0,75 X A42 0 -0,75 0,75 X A43 -0,2 -0,55 0,75 X A44 -0,1 -0,7 0,8 X A45 0 -0,75 0,75 X A46 0,2 -0,95 0,75 X A47 -0,7 -0,3 1 X A48 -0,5 -0,5 1 X A49 0,25 -0,75 0,5 X
Fonte: Elaborado pelos autores
Tabela 6 – Fluxos líquidos e classificação das alternativas
Apenas uma atividade foi classificada como pertencente à classe das atividades que necessita menor atenção, a atividade A47. Além do fato dessa atividade exigir baixa prioridade e alto nível de esforço para ser realizada, isso aconteceu devido ao fato de ela estar localizada no setor considerado de menor importância para o projeto, o chão de fábrica, onde os problemas são considerados pontuais envolvendo, em geral, equipamentos específicos da planta da fábrica. Todos os desempenhos desta atividade são antagônicos em relação à função definida anteriormente junto ao gerente e, portanto, em relação a sua priorização.
A maioria das atividades foi classificada na segunda classe, o que indica que seus desempenhos em relação aos critérios considerados pelo gerente foram balanceados.
O modelo sugere que 11 das atividades devem ser consideradas com uma maior atenção, o que significa dizer que, dado o contexto da necessidade de reprogramar as atividades do projeto, o gerente deve optar por priorizar essas atividades frente às demais.
4.5 Análise de sensibilidade
A análise de sensibilidade pode ser vista como uma forma de avaliar a robustez do modelo. Neste artigo, a análise de sensibilidade foi realizada através da variação dos pesos de cada critério.
Na medida em que se incrementa em 0,1 até 0,3 o peso do critério x1, observa-se uma pequena mudança nos resultados de forma a obter-se um número crescente de atividades migrando em direção a classe central (C2), . Uma maior variação no critério prioridade (x2)
10 não afetou consideravelmente as classificações inicias. E mesmo em valores relativamente altos, aumentando-o até 0,6, esse critério não trouxe atividades com altas pontuações avaliadas pelo gerente para o grupo C3, que é o considerado de prioridade máxima pelo decisor. O que pode indicar que o nome atribuído a este critério pelo gerente pode ser inadequado.
5.Considerações Finais
O problema tratado neste artigo está inserido no contexto de priorização de atividades e visa ao desenvolvimento de um modelo de classificação das atividades para projetos de TI.
Para solucionar o problema, foi proposto um modelo apoio à decisão baseado no PROMETHEE II adaptado para a classificação de alternativas. Com isto, foi possível a ordenação das atividades de projeto por níveis de criticidade e permitiu que a utilização destas informações na tomada de decisão em contextos de reprogramação das atividades.
Segundo Almeida (2010), a análise de resultados não consiste apenas na determinação das alternativas a serem recomendadas ao decisor, é necessário também mostrar o quanto essa recomendação é sensível aos parâmetros identificados no processo elicitatório.
O modelo sugere que as atividades A2, A3, A10, A11, A12, A13, A14, A15, A24, A25 e A26 devem ser priorizadas em relação as demais. A atividade A47 possui menor nível de prioridade e as demais podem ser reprogramadas com uma prioridade menor que as primeiramente citadas, porém mais cedo que a atividade A47.
Foi verificada a relação entre o range de pontuação dos critérios e o estabelecimento de perfis de referencia para se utilizarem na etapa de classificação do modelo. Quanto menos níveis se tem para avaliar um critério, menores são as distancia entre as avaliações e portanto menor é a quantidade de perfis que se pode definir.
O método PROMETHEE apresenta limitações ao se trabalhar com poucas alternativas perfis. Neste caso, a comparação com cada alternativa do projeto foi feita com apenas duas referencias e pôde-se verificar uma predominância na classificação das atividades na classe central.
A sugestão para trabalhos futuros é o desenvolvimento de mais perfis intermediários, e para isso seria necessário elicitar junto ao decisor mais níveis de avaliação dos critérios.
Referências
ALMEIDA, A. T. O conhecimento e o uso de métodos multicritério de apoio à decisão. Recife: Ed.
Universitária da UFPE, 2010.
DIAS, L. M. C. A informação imprecisa e os modelos multicritério de apoio a decisão: identificação e uso de
conclusões robustas. Universidade de Coimbra. Faculdade de Economia. 2000.
ANDRADE, C. C. P. Modelo Multicritério de Apoio a Decisão para Priorização de Atividades em Projetos de
Tecnologia da Informação. Trabalho de Conclusão de Curso – UFPE, 2010.
BRANS, J. P. & MARESCHAL, B. How to select and how to rank projects: The PROMETHEE method.
European Journal of Operational Research. Vol.24. p.228-238, 1986.
CAVALCANTE, C. A. V. Modelagem de decisão multicritério no planejamento da manutenção abordando
problemáticas de escolha e classificação. Tese de Doutorado – UFPE, 136p, 2005.
CORMICAN, K.; O’SULLIVAN, D. Auditing best practice for effective product innovation management.
11
HINDE, B. S. Why do so many major IT projects fail? Computer Fraud & Security: 15-17, 2005. KERZNER, H. Gestão de Projetos: as melhores práticas. Porto Alegre: Bookman, 2002.
ÖZEROL, G.; KARASAKAL, E. A parallel between regret theory and outranking methods for multicriteria
decision making under imprecise information. Theory and Decision 65:45–70, 2008.
PMI. A guide to the Project management body of knowledge (PMBOK). 3 ed. Project Management Institute,
2004.
ROY, B. & BOUYSSOU, D. Aide Multicriterère à la Décision: Méthods et Cas. Paris, Economica, 1993 SILVA, J. T. M. Programação Linear com objetivos múltiplos Um instrumento para a tomada de decisão.
Revista dos Programas de Mestrado do Centro Universitário UNA. 1997.
ANEXO
Alternativa Setor Prioridades Esforço
A1 2 4 2 A2 2 4 3 A3 2 4 3 A7 2 3 3 A8 2 3 3 A9 2 3 2 A10 2 2 4 A11 2 2 3 A12 2 2 4 A13 2 2 1 A14 2 2 3 A15 2 4 3 A16 2 3 3 A18 2 3 3 A20 2 3 3 A21 2 3 3 A22 2 3 2 A23 2 3 2 A24 2 2 4 A25 2 2 2 A26 2 2 3 A27 1 4 3 A28 1 4 3 A29 1 4 2 A30 1 4 2 A31 1 4 3 A32 1 3 2 A33 1 3 2 A34 1 3 2
12 A35 1 3 4 A36 1 3 2 A37 1 3 2 A38 1 3 3 A39 1 3 3 A40 1 3 1 A41 1 3 1 A42 1 3 2 A43 1 3 1 A44 1 3 2 A45 1 3 2 A46 1 3 3 A47 1 2 1 A48 1 2 2 A49 3 2 5 Fonte: Autores
