Conforme apresentado no capítulo 1, o objetivo geral deste estudo é criar um modelo conceitual e respectivo modelo computacional de um ambiente de apoio à tomada de decisão na atividade de avaliação de pessoas por Competências.
Como visto nos capítulos anteriores, os padrões existentes intitulam de Competência o que neste estudo é um SKILL, ou seja, um item que compõe dada Competência. Tomando como exemplo o artigo de Bailey et. al. (2001), em que são relacionados 85 skills necessários para o bom desempenho da função de programador de sistemas de computador, esta competência, nos padrões (IEEE, 2005 e HR-XML, 2007), para que uma determinada pessoa apresente um bom desempenho na função de programador, são necessárias 85 “competências”, ao passo que no modelo deste estudo, baseado no modelo CHA, a Competência (no singular) necessária envolve 85 itens ou SKILLs. Em outras palavras “Quais as competências necessárias” versus “Que SKILLs compõe a Competência”. Trata-se apenas de uma diferença de classificação.
O padrão HR-XML implementa o modelo proposto neste estudo através do aninhamento de competencies, ou como chamado nesse padrão Recursive Competencies (vide ANEXO A).
Em termos práticos, por observação histórica, os sistemas computacionais desta natureza tem seus dados armazenados em bancos de dados e um programa (software), ou conjunto de programas, que manipula esses dados, localizando o que de interesse do usuário num dado momento e apresentando em algum tipo de dispositivo de saída, via de regra um monitor de LCD ou uma impressora, em um formato e/ou agrupamento que tenha um significado contextual. Em termos estruturais o sistema tem esses dois grandes blocos. A massa de dados das pessoas, empresas e instituições de ensino salvas no banco de dados e uma lógica de manipulação para alterações nos dados, busca, consolidação de informações e apresentação aos usuários.
Com base nestes conceitos e demais conceitos analisados anteriormente, chegou-se, após ensaios conceituais e experimentais diversos, ao modelo computacional descrito a seguir. Este modelo foi implementado experimentalmente sob a designação de SACHA (Sistema de Avaliação por Conhecimentos, Habilidades e Atitudes).
4.1 PLATAFORMA TECNOLÓGICA E AMBIENTE DE DESENVOLVIMENTO
Optou-se por uma plataforma que fosse open source e que fosse suportada por diversos sistemas operacionais. Para o bloco de software foi adotado o padrão
J2EE (Java 2 Enterprise Edition - http://java.sun.com/j2ee/overview.html) de base
Java, movido pelo servlet container Tomcat (http://tomcat.apache.org), e para o bloco de dados foi adotado o SGBDR (Sistema Gerenciador de Bancos de Dados Relacionais) MySQL (http://www.mysql.com), que atualmente está sob a tutela da Sun Microsystems (http://www.sun.com/), que mantém tanto a versão comercial quanto a versão freeware.
Dentro do modelo J2EE foi utilizada a estrutura MVC (Model-View-Control) em que tanto Controllers como Views foram implementados em scripts JSP (Java Server Pages) e a lógica de negócio e bibliotecas de utilitários em JavaBeans.
Figura 11 - Modelo MVC
A figura anterior mostra o diagrama da estrutura MVC, onde a View é representada pelos scripts que geram saída para o usuário e que permitem o retorno de comandos (web requests). Os requests gerados pelo usuários são recebidos
pelos Controllers que por sua vez tratam de providenciar os resultados esperados pelo usuário via lógica de negócios e manipulação nos estados dos Models e também definem a View a ser devolvida ao usuário. A View, para fechar o ciclo, antes de ser lançada no web response, lê os estados do Model, coleta os dados necessários e os dispõe no lay-out adequado para interpretação do usuário.
Quanto ao SGBDR escolhido, o MySQL, mesmo tratando-se de um banco de dados open source de grande utilização mundial, construiu-se o SACHA de forma a se utilizar de sintaxes SQL padronizadas ANSI 92 (http://www.ansi.org) de modo a poder operar em qualquer outro banco de dados que siga estes padrões sem que haja necessidade de reprogramação nas lógicas de controle.
O ambiente de desenvolvimento adotado foi o NetBeans da Sun Microsystems, versão 6.5; o ambiente de modelagem foi o DB Designer 4, também freeware, da fabForce.net e a máquina de desenvolvimento foi um Pentium Duo Core, T8100, 2.1GHz, Windows Vista professional, memória 3 GB.
4.2 A BASE DE DADOS
O modelo deste estudo foi baseado na estrutura convencional de sistemas de bancos de dados, com as tecnologias adotadas, conforme ilustrado na figura abaixo:
Em linhas gerais deseja-se localizar, na base de dados, Pessoas que tenham determinados SKILLs que estejam em conformidade com os SKILLs solicitados por determinada Oportunidade (Competência) publicada por uma determinada Empresa. Sendo assim, necessita-se que nesta base existam as seguintes tabelas principais:
• Pessoas
• Oportunidades
• SKILLs
• Itens de SKILLs
• SKILLs das Pessoas
• SKILLs requeridos pelas Oportunidades
• Itens de SKILL das Pessoas
• Itens dos SKILL requeridos pelas Oportunidades Vide Normalização deste modelo no APÊNDICE B.
4.2.1 O Modelo do SKILL
Figura 14 – Diagrama Entidade-Relacionamento do modelo do SKILL
A tabela skill relaciona os SKILLs cadastrados e reconhecidos pelo sistema. Em relação ao padrão HR-XML:
HR-XML SACHA
CompetencyId skill_NR
Name skill_NM
Description Não implementado
Tabela 3 – Tabela “skill” segundo o padrão HR-XML
A tabela skill_item relaciona a declaração dos itens dos SKILLs cadastrados na cardinalidade de 1:N. Um SKILL pode se compor de quantos itens forem necessários para representar a realidade.
Em relação ao padrão HR-XML
HR-XML SACHA
--- skill_NR = Chave Estrangeira
CompetencyId / id skill_item_CD
Não previsto skill_item_NM = nome do item
Description skill_item_DS
Tabela 4 – Tabela “skill_item” segundo o padrão HR-XML
A tabela skill_item_def armazena as definições de um determinado SKILL que foi modelado, como será visto mais adiante no item 4.6, na chamada, neste estudo, de Série de Modelos 9000. Todas as definições então no binômio parâmetro=valor. Qualquer tipo de informação alfanumérica pode ser armazenada nesta tabela. Os parâmetros sempre estarão relacionados com os parâmetros previstos na classe que controla a lógica do referido SKILL.
Em relação ao padrão HR-XML
HR-XML SACHA
--- skill_NR = Chave Estrangeira --- skill_item_CD = Chave Estrangeira CompetencyEvidence / typeId parâmetro
CompetencyEvidence / StringValue valor
4.2.2 O Modelo da Pessoa e respectivos SKILLs
Figura 15 – Diagrama Entidade-Relacionamento do modelo “Pessoa”
A tabela pessoa relaciona todas as pessoas que se cadastraram no sistema e, portanto, visíveis aos mecanismos de busca. O modelo HR-XML não especifica o modelo da Pessoa em si já que esta se trata do “Competency Owner”. Nesta tabela, além do campo chave, pessoa_NR, devem constar as informações de identificação pessoal, que no caso deste estudo foram definidas apenas algumas para dar um mínimo de funcionalidade no protótipo implementado.
As tabelas pessoa_skill e a pessoa_skill_item relacionam, respectivamente, os SKILLs e respectivos itens de SKILL que determinada pessoa possui, acompanhados dos valores. Estas duas tabelas refletem exatamente o que foi ilustrado nas figuras 8 e 9 vistas anteriormente.
Em relação ao padrão HR-XML
HR-XML SACHA
--- Pessoa_NR = Chave Estrangeira
--- skill_NR = Chave Estrangeira --- skill_item_CD = Chave Estrangeira
--- skill_ocorrencia = (*)
CompetencyEvidency / NumericValue pessoa_skill_vln CompetencyEvidency / StringValue pessoa_skill_vla CompetencyEvidency / NumericValue skill_item_vln CompetencyEvidency / StringValue skill-item_vla
Tabela 6 – Tabela “pessoa_skill_item” segundo o padrão HR-XML
(*) skill_ocorrencia é um campo não especificado de forma clara pelo padrão HR- XML. No modelo proposto por este estudo, possibilita a ocorrência de mais de um SKILL de mesmo identificador para uma mesma pessoa. O valor default é 1.
4.2.3 O Modelo da Oportunidade e respectivos SKILLs
Figura 16 – Diagrama Entidade-Relacionamento do modelo “Oportunidade”
De forma análoga à Pessoa, a Oportunidade segue o mesmo modelo com alguns campos a mais.
A tabela empresas é uma tabela complementar para armazenar os geradores de oportunidades de trabalho cadastrados no sistema.
A tabela oportunidades é o par da tabela pessoa. Em termos comparativos, uma pessoa está para uma oportunidade. Os campos especificam os dados de identificação, que neste estudo foram escolhidos a data de publicação da Oportunidade, o nome ou título, por exemplo “Programador Java Júnior” e um indicador de nível hierárquico para possibilitar, no protótipo, que uma determinada pessoa procure oportunidades de um determinado nível.
A tabela oportunidade_skill é o par da tabela pessoa_skill, ou seja, os SKILLs relacionados em determinada Oportunidade são os procurados em alguma Pessoa que esteja cadastrada no sistema.
A tabela oportunidade_skill_item é o par da tabela pessoa_skill_item com alguns campos adicionais. Esses campos adicionais são os três descritos abaixo:
• miM : este campo, data type CHAR(1), especifica se o item do SKILL deverá
ser procurado na base de dados como sendo valor “no mímino” (m) em relação ao especificado no campo skill_item_vln, se “igual” (i) ou se “no máximo” (M). Em termos práticos, nos sites de Currículos convencionais, tem- se por padrão trazer no resultado da busca todas as pessoas que tenham no mínimo aquele valor ou aquela nota, entendendo-se que em se conseguindo recursos humanos melhores que o mínimo especificado, melhor para a organização contratante. Mas o modelo deste estudo prevê a possibilidade de que se possa fazer a busca com valores iguais ou máximos.
• OD : este campo, data type CHAR(1) , especifica se o item do SKILL deverá
ser obrigatório (O) ou desejável (D). Os itens obrigatórios excluem do resultado de busca as pessoas que não tiverem aquele determinado item ou não atenderem à especificação miM. Os itens desejáveis serão utilizados para compor a somatória adicional de pontos para gerar listas ordenadas na forma de ranking, dando mais recursos à empresa empregadora para identificar as melhores pessoas para preencher o posto.
• skill_item_relevancia : este campo, data type INTEGER, possibilita que a
empresa empregadora pondere os itens, atribuindo mais peso a uns e menos a outros, de forma a ajustar a lista de ranking aos itens de SKILL que tem maior importância na situação. No protótipo implementado neste estudo o valor default é 10, podendo variar 0 a 10. Foi implementado um valor 15 com objetivo de possibilitar, uma vez configurada toda a Competência, dar destaque a determinado item de SKILL sem a necessidade de se proceder ao rebaixamento de todas as demais relevâncias.
4.2.4 Tabelas de Referência
Todo SKILL e outros atributos em que há interesse na formação do perfil geral da pessoa são armazenados nas tabelas pessoa_skill e pessoa_skill_item com seus valores atribuídos, ou no campo skill_item_vln ou no skill_item_vla. Incluem- se, por exemplo, nos campos de valores, geralmente no campo skill_item_vln, o id de um curso que tenha sido realizado pela pessoa. Este id é proveniente da Chave Primária de uma tabela em que contenha “Cursos”, que no caso do protótipo deste estudo trata-se do campo curso_nr. No caso deste último exemplo não há como estabelecer um relacionamento de Chave Estrangeira no banco de dados, pois o campo skill_item_vln contém números das mais variadas origens inclusive “Chaves Estrangeiras” de diversas outras tabelas.
Essas tabelas, cuja Chave Primária é referenciada no campo skill_item_vln, e portanto não sofrem controle de integridade referencial exercido pelo SGBDR, mas que necessitam deste controle no nível da aplicação, foram chamadas, neste estudo, de Tabelas de Referência.
No protótipo implementado existem 3, escolas, para cadastro de entidades acadêmicas em que as pessoas possam obter graduação em determinados cursos,
area_interesse, para cadastro das áreas em que pessoas possam estar
interessadas em trabalhar e cursos, para cadastro de cursos existentes.
4.3 SQL APLICADA AO MODELO
Apesar da simplicidade do modelo DER, a sintaxe SQL necessária para localizar os SKILLs de interesse não é tão direta, sendo necessários alguns recursos de agrupamento e contagem para que se consiga identificar se determinada pessoa possui todos os SKILLs requeridos ou não.
Nas estruturas das bases de Currículos convencionais, em que cada SKILL é representado em uma coluna distinta na tabela da base de dados, os itens obrigatórios da Competência são buscados encadeando-se os argumentos pelo conector AND. No modelo deste estudo, em que os valores dos itens são armazenados na mesma coluna, este tipo de encadeamento não funciona, sendo possível apenas pelo conector OR associado à contagem de itens retornados.
No exemplo abaixo, a query SQL pretende recuperar registros na tabela pessoa_skill_item que tenha o SKILL de CompetencyId igual a 1 e itens de SKILL cujas CompetencyId sejam ‘A’ com valor 3, ou ‘B’ com valor 1, ou ‘C’ com valor 2, que tenha relação com a mesma pessoa (GROUP BY pessoa_NR) e que o agrupamento contenha 3 registros. Se essas condições não forem todas satisfeitas em uma determinada pessoa encontrada na base de dados, esta não será incluída no ranking.
SELECT COUNT(pessoa_NR),pessoa_NR
FROM pessoa_skill_item WHERE
skill_NR=1 AND (
(skill_item_CD=’A’ AND skill_item_vln=3) OR (skill_item_CD=’B’ AND skill_item_vln=1) OR (skill_item_CD=’C’ AND skill_item_vln=2) OR )
GROUP BY pessoa_NR HAVING COUNT(pessoa_NR)=3
Neste primeiro protótipo não foi explorada a pesquisa pela tabela
pessoa_skill, onde estaria armazenada a informação global do SKILL, mas sim pela
tabela pessoa_skill_item, onde as possibilidades de refinamento por item são bem mais amplas.
4.3.1 A busca por múltiplos SKILLs – uma Competência
Localizar pessoas que possuam determinado SKILL, como visto, envolve a especificação valorada dos itens do SKILL, o que resulta em uma query composta e de relativa complexidade. Mas o objeto deste estudo é a Competência, entidade formada por uma composição de SKILLs. O exemplo da tabela 7 mostra uma Competência composta por 3 SKILLs.
SKILL 1 (Língua estrangeira) Item 1 (leitura) = 3 (avançado) Item 2 (escrita) >= 1 (básico) Item 3 (compreenção) = 3 (avançado) Item 4 (fala) >= 1 (básico) SKILL 2 (Linguagem de programação
Java) 0 a 2,9 = pouco conhecimento 3 a 4,9 = conhecimento básico 5 a 6,9 = conhecimento intermediário 7 a 10 = conhecimento avançado
Item 1 (único) >= 7 (avançado)
SKILL 3 (Formação Superior) Engenharia = 15 ou
Matemática = 68 ou Física = 37
Tempo de formado >= 5 anos
Item 1 (curso) = 15 ou 68 ou 37
Item 2 (tempo format.) ano atual – ano formatura >= 5
Tabela 7 – Exemplo de formação de uma Competência no modelo computacional proposto
Neste exemplo procura-se pessoas que leiam e compreendam bem o idioma inglês, que tenham conhecimentos avançados na linguagem de programação Java e que tenham formação em Engenharia, Matemática ou Física há mais de 5 anos. O SKILL número 1 se compõe de 4 itens, o SKILL de id 2 é formado por uma única nota que define uma classificação entre 4 faixas e o SKILL da formação acadêmica, no exemplo, está cadastrado na base de dados como o curso de Engenharia tendo o id 15, o de Física o id 37 e o de Matemática o id 68. O segundo item deste SKILL de id 3 é o ano de formatura, sendo que para se obter o tempo de formado basta subtrair o ano atual do ano de formatura (a rigor seria necessário saber se o ano corrente encontra-se no início, meio ou fim para um cálculo mais preciso, mas esta precisão não vem ao caso neste momento do estudo).
Para que esta busca seja realizada na base de dados, a query SQL deverá ter a seguinte estrutura:
SELECT COUNT(pessoa_NR),pessoa_NR FROM pessoa_skill_item WHERE
(argumentos do primeiro SKILL)
(skill_NR=1 AND ((skill_item_CD='1' AND VALOR=3) OR (skill_item_CD='2' AND VALOR>=1) OR (skill_item_CD='3' AND VALOR=3) OR (skill_item_CD='4' AND VALOR>=1))
OR
(argumentos do segundo SKILL)
(skill_NR=2 AND skill_item_CD='1' AND VALOR>=7) OR
(argumentos do terceiro SKILL)
(skill_NR=3 AND ((skill_item_CD='1' AND VALOR=15) OR (skill_item_CD='1' AND VALOR=68) OR (skill_item_CD='1' AND VALOR=37)) OR (skill_item_CD='2' AND "<ano atual>" - VALOR >= 5))
GROUP BY pessoa_NR HAVING COUNT(pessoa_NR)>=7
É formado um bloco de argumentos para cada SKILL, também concatenados pelo operador OR (o operador AND só se aplica na identificação do registro: skill_NR + skill_item_CD + skill_item_vln). O operador HAVING COUNT deve especificar a quantidade mínima de registros esperados, que neste exemplo é de 7, podendo chegar a 9 caso a pessoa tenha formação acadêmica superior nos 3 cursos elencados na Competência-exemplo ilustrada na tabela 7.
Trata-se de uma query composta de 3 grupos de argumentos, os referentes ao SKILL número 1, os referentes ao número 2 e os do número 3 (supõe-se que os números de cadastro destes SKILLs sejam 1, 2 e 3). O primeiro grupo é idêntico ao analisado anteriormente, o segundo grupo é o mais simples exigindo apenas que o SKILL seja o de número 2 e que o item 1 tenha o valor maior ou igual a 7, e o terceiro grupo tem 3 alternativas para o item 1 e um valor calculado para o item 2.
O modelo deste estudo não pesquisou as conseqüências no desempenho do SGBDR nos casos de Competências compostas por grandes quantidades de SKILLs. A “Competência” de Bailey et al. (2001) em que são relacionados 85 SKILLs necessários aos programadores do mercado de trabalho norte-americano, por exemplo, geraria uma String SQL com 85 blocos de argumentos semelhantes aos do exemplo anterior. Mesmo que um determinado servidor, com determinada configuração de hardware, não tivesse problemas em executar esta query, não se poderia dizer o mesmo em uma situação de tráfego mais intenso em que o SGBDR precisaria interpretar e executar rapidamente as querys entrantes para evitar problemas de enfileiramento. No entanto, em termos práticos, inclusive pela própria vivência do autor em ambientes operacionais de recrutamento e seleção de pessoas, os requisitos obrigatórios raramente ultrapassam 6 ou 7. Os demais requisitos entram na categoria de “Desejáveis”, ou seja, não excluem as pessoas que não os possuem, mas as classificam melhor na lista de ranking. De forma que uma Competência composta por 10 SKILLs obrigatórios é bastante rara de ocorrer, mesmo porque o afunilamento que se forma à medida em que novos SKILLs são acrescentados acaba por reduzir demasiadamente a lista resultante de possíveis candidatos. Como será visto mais à frente, os SKILLs classificados como
“Desejáveis” não entram na query SQL, ficando o custo de processamento por conta do algoritmo implementado no modelo.
4.4 CASOS DE USO
No âmbito deste estudo, 3 são os atores e 6 são os casos de uso de interesse.
Atores:
• Empregador: entidade geradora de oportunidades de trabalho; define e
configura as Competências desejadas.
• Profissional: Pessoa à procura de oportunidades de trabalho.
• Aluno/estagiário: Pessoa em formação acadêmica em busca da primeira
oportunidade de trabalho.
Casos de uso:
• Criar/alterar oportunidade + associar SKILLs: o empregador cria uma nova
oportunidade e seleciona os SKILLs necessários com as configurações desejadas.
• Buscar Pessoas: o empregador, de posse de uma oportunidade
(Competência) previamente configurada, executa a rotina de busca, na base de dados, por pessoas que atendam aos requisitos obrigatórios da oportunidade em questão.
• Incluir/Alterar cadastro Pessoal + associar SKILLs: o profissional ou o
aluno/estagiário cadastram-se no sistema, recebem uma senha, e selecionam os seus SKILLs com as especificações individuais.
• Buscar oportunidades: o profissional ou o aluno/estagiário executam a
rotina de busca, na base de dados, por oportunidades publicadas das quais tenha possibilidades de se candidatar.
• Comparar atributos pessoais X requisitos da oportunidade: o profissional
ou o aluno/estagiário executam a rotina que verifica em todos os itens se todos os seus SKILLs e demais atributos atendem aos requisitos de uma determinada oportunidade.
Figura 17 – Diagrama de Casos de Uso
4.5 DIAGRAMA DE CLASSES E OPERACIONALIZAÇÃO DO MODELO
Nas classes do SACHA existem 3 representações principais de objetos: A Pessoa, a Oportunidade e o SKILL. Todas as pessoas, assim como todas as oportunidades, tem idêntica estrutura em termos de classe. Os campos e métodos são os mesmos, assim como o corpo dos métodos também o é. De forma que para toda e qualquer pessoa, assim como para toda e qualquer oportunidade, uma classe para a pessoa e uma classe para a oportunidade são suficientes para representar esses dois domínios.
A representação do SKILL, no entanto, exige classes distintas para representação de SKILLs de naturezas distintas. Uma classe projetada para um SKILL de idioma estrangeiro, por exemplo, pode ser utilizada por outros SKILLs de
idiomas, desde que a representação seja a mesma. Já um SKILL de conhecimentos de linguagem de programação se representa por outros tipos de atributos, tendo que ter uma classe com outros tipos de campos e outros métodos.
Projetar uma classe diferente para cada tipo de SKILL pode ser algo inevitável pelas diferenças que existem entre esses tipos, mas inserir na programação do sistema todo um conjunto de instruções para operar com cada novo SKILL que surja no decorrer do tempo pode inviabilizar um sistema deste tipo em uma