UNIVERSIDADE FEDERAL FLUMINENSE MARCOS ANTÔNIO … · Hackear – Neologismo derivado de hacker,...
60
UNIVERSIDADE FEDERAL FLUMINENSE MARCOS ANTÔNIO DE ALMEIDA PROPOSTA DE INTEGRAÇÃO ENTRE INICIATIVAS DE INCLUSÃO DIGITAL E PROGRAMAS DE QUALIFICAÇÃO PROFISSIONAL: PORTAL DE INCLUSÃO E RENDA PELA COMPETÊNCIA Niterói 2008
Transcript of UNIVERSIDADE FEDERAL FLUMINENSE MARCOS ANTÔNIO … · Hackear – Neologismo derivado de hacker,...
UNIVERSIDADE FEDERAL FLUMINENSEMARCOS ANTÔNIO DE ALMEIDA
PROPOSTA DE INTEGRAÇÃO ENTRE INICIATIVAS DE INCLUSÃO DIGITAL E PROGRAMAS DE QUALIFICAÇÃO PROFISSIONAL:
PORTAL DE INCLUSÃO E RENDA PELA COMPETÊNCIA
Niterói2008
MARCOS ANTÔNIO DE ALMEIDA
PROPOSTA DE INTEGRAÇÃO ENTRE INICIATIVAS DE INCLUSÃO DIGITAL E PROGRAMAS DE QUALIFICAÇÃO PROFISSIONAL:
PORTAL DE INCLUSÃO E RENDA PELA COMPETÊNCIA
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Tecnólogo em Sis-
temas de Computação.
Orientador:LEANDRO SOARES DE SOUSA
NITERÓI2008
MARCOS ANTÔNIO DE ALMEIDA
PROPOSTA DE INTEGRAÇÃO ENTRE INICIATIVAS DE INCLUSÃO DIGITAL E PROGRAMAS DE QUALIFICAÇÃO PROFISSIONAL:
PORTAL DE INCLUSÃO E RENDA PELA COMPETÊNCIA
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Tecnólogo em Sis-
temas de Computação.
Niterói, ___ de _______________ de 2008.
Banca Examinadora:
_________________________________________
Prof. Leandro Soares de Sousa, Msc. – Tutor Orientador
UFF - Universidade Federal Fluminense
_________________________________________
Prof. Alexandre Domingues Gonçalves, Msc. – Avaliador
UFF - Universidade Federal Fluminense
Dedico este trabalho a minha mãe Normélia,
meu pai Oscar, a minha eterna namorada
Rita e aos nossos filhos, Ique, Duda, Nana e
Totão.
AGRADECIMENTOS
A Deus, que sempre iluminou a minha cami-
nhada.
A meu Orientador Prof. Leandro Soares de
Sousa pelo estímulo e atenção que me con-
cedeu durante o curso.
Aos Colegas de curso pelo incentivo e troca
de experiências.
A todos os meus familiares e amigos pelo
apoio e colaboração.
“Só sei que nada sei”.
Sócrates
RESUMO
A “Inclusão Digital” só será um instrumento eficaz para promover o desen-volvimento social das populações de baixa renda se ela vier acompanhada de ferra-mentas que criem oportunidades reais e tangíveis de geração de renda para os membros destas comunidades.
Este trabalho visou contribuir com este objetivo através da especificação de uma ferramenta capaz de mapear o hiato de competência, que ocorre entre os membros da comunidade e as oportunidades existentes no mercado de trabalho.
O bom uso desta ferramenta requer de um lado a existência de uma ban-co de dados de oportunidades com seus requisitos, competências e certificações exigidas e de outro das habilidades, nível de escolaridade e competências adquiri-das pelos membros da comunidade.
O resultado prático é que para cada oportunidade oferecida é possível identificar quais são as competências que precisam ser adquiridas pelos membros da comunidade, de forma que eles possam se capacitar àquela oportunidade, ou seja, o chamado “hiato de competência”.
Estas informações poderão ser usadas de duas formas: individualmente, indicando um plano de desenvolvimento pessoal, e comunitariamente, para elabora-ção de um plano de treinamento para seus integrantes.
Palavras-chaves: Inclusão Digital, Geração de Renda e Hiato de Competência, métodos ágeis.
LISTA DE ILUSTRAÇÕES
Figura 1-1: Visão geral.........................................................................13Figura 1-1: Visão geral.........................................................................13 Figura 3-2: Diagrama de classes - conceitual...................................24 Figura 3-2: Diagrama de classes - conceitual...................................24Figura 4-3: Arquitetura do Joomla!.....................................................29Figura 4-3: Arquitetura do Joomla!.....................................................29Figura 4-4: Mapa das páginas do site.................................................30Figura 4-4: Mapa das páginas do site.................................................30Figura 4-3: Diagrama de casos de uso...............................................31Figura 5-5: Casos de uso do cenário 1...............................................36Figura 5-5: Casos de uso do cenário 1...............................................36Figura 5-2: Página principal do portal................................................37Figura 5-3: Cadastrar usuário portal...................................................38Figura 5-4: Caso de teste e-mail já cadastrado..................................39Figura 5-5: Caso de teste usuário em uso..........................................39Figura 5-6: Cadastramento efetuado com sucesso...........................39Figura 5-6: Caso de Teste "Usuário ok".............................................40Figura 5-7: Cadastramento integrante da comunidade.....................40Figura 5-8: Cadastrar nova profissão.................................................41Figura 5-9: Portal do ofertante.............................................................42Figura 5-60: Cadastra profissões – página inicial - consulta...........43Figura 5-60: Cadastra profissões – página inicial - consulta...........43Figura 5-11: Página cadastra nova profissão....................................43Figura 5-72: Cadastrar nova competência.........................................44
Figura 5-72: Cadastrar nova competência.........................................44Figura 5-13: Atualizar competências..................................................45Figura 5-14: Cadastrar profissões - atualiza competência...............46Figura 5-85: Atualizar competências – indica....................................46Figura 5-85: Atualizar competências – indica....................................46Figura 5-16: Certifica curso.................................................................47Figura 5-17: Certifica curso - consulta...............................................48Figura 5-18: Certifica curso – edita / novo curso ..............................49Figura 5-19: Certifica curso – consulta...............................................50Figura 5-20: Certifica curso.................................................................50Figura 5-21: Planejar eventos..............................................................51Figura 5-22: Instrutores cadastra........................................................52Figura 5-23: Programação de eventos ...............................................54Figura 5-24: Postar notícias.................................................................54Figura 5-25: Postar notícias - complemento......................................55Figura 5-26: Programação eventos – resultado.................................55Figura 5-27: Inscrever-se em um evento............................................56Figura 5-28: Inscrever-se em evento...................................................57Figura 5-29: Meus eventos - resultado ..............................................58
LISTA DE ABREVIATURAS E SIGLAS
PROMINP – Programa de Mobilização da Indústria Nacional de Petróleo e Gás Na-
tural.
CDI – Comitê para Democratização da Informática.
Telecentro – Iniciativas de Inclusão Digital que são patrocinadas pôr Instituições Pri-
vadas em comunidades de baixa renda.
WEB – Rede Mundial de Computadores.
Site – Designa um local na Internet onde um conjunto de páginas pode ser acessa-
do.
Servidor – Programa Aplicativo que disponibiliza algum serviço Especializado ou um
determinado computador que disponibiliza tais serviços.
Servidor WEB – Provê um serviço de acesso às páginas de um site.
APACHE – Programa de Aplicação para disponibilizar um servidor WEB.
SGDB – Sistema Gerenciador de Banco de Dados , provê acesso a dados organiza-
dos de forma estruturada.
MySQL – Programa de aplicação que implementa um SGBD.
PHP – Linguagem de Programação utilizada para desenvolver páginas dinâmicas
em um site.
CMS – (Contened Management System) Família de sistemas responsáveis pôr ge-
renciar o conteúdo das páginas de um site na Internet pêlos próprios usuários do
mesmo.
Joomla! – Programa de aplicação responsável pôr prover um CMS.
SO – Sistema Operacional, programa responsável pôr prover acesso aos recursos
físicos dos computadores para os programas de aplicação.
LINUX – Sistema operacional provido pôr uma comunidade de programadores.
Código-Fonte - Conjunto de instruções na linguagem de programação utilizada
para desenvolver um determinado sistema.
Software Livre – segundo a definição criada pela Free Software Foundation é qual-
quer programa de computador que pode ser usado, copiado, estudado, modificado e
redistribuído com algumas restrições. A liberdade de tais diretrizes é central ao con-
ceito, o qual se opõe ao conceito de software proprietário, mas não ao software que
é vendido almejando lucro (software comercial). A maneira usual de distribuição de
software livre é anexar a este uma licença de software livre, e tornar o código fonte
do programa disponível.
OpenSource – Qualquer programa que permita o acesso ao seu código fonte.
Framework – conjunto de regras de codificação e programas padrão que junto com
técnicas de programação necessárias para correta utilização consegue ter acesso
aos recursos existentes e oferecidos pôr uma aplicação para criar/modificar novos
recursos.
Framework Caixa Branca – Tipo de framework, no qual temos acesso direto a seu
código fonte e precisamos conhecer detalhes de sua implementação se desejarmos
altera-los ou amplia-los. Este é o caso o Joomla.
Hackear – Neologismo derivado de hacker, que significa, alterar um código existen-
te, colocando outro em seu lugar, que faça o que se deseja, muito comum no con-
texto do uso de software livre.
TI – Tecnologia da Informação – conjunto de recursos e serviços necessários para o
uso da informática.
MVC - Model-view-controller é um padrão de arquitetura de software. Com o aumen-to da complexidade das aplicações desenvolvidas torna-se fundamental a separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout. O model-view-controller resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de inte-ração com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto (Fonte: Wikipédia - http://pt.wikipedia.org/wiki/MVC).
SUMÁRIO
RESUMO ................................................................................................. 7 LISTA DE ILUSTRAÇÕES ...................................................................... 8 LISTA DE ABREVIATURAS E SIGLAS ............................................... 10 1 INTRODUÇÃO .................................................................................... 13 2 METODOLOGIA .................................................................................. 15 3 PROPOSTA ......................................................................................... 17 4 IMPLEMENTAÇÃO ............................................................................ 25 5 EXPERIMENTOS ................................................................................ 35 6 CONCLUSÕES E TRABALHOS FUTUROS ...................................... 59 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................... 60
1 INTRODUÇÃO
Este trabalho especifica uma ferramenta para integrar as oportunidades
existentes no mercado de trabalho com as iniciativas de inclusão digital em comuni-
dades de baixa renda.
Um dos resultados práticos de sua utilização é que para cada oportunida-
de oferecida pelo mercado de trabalho seja possível identificar quais são as compe-
tências que precisam ser adquiridas pelos membros da comunidade, de forma que
estes possam se capacitar àquela oportunidade, ou seja, o chamado “hiato de com-
petência”.
Figura 1-1: Visão geral
13
Assim os principais atores deste cenário são, como apresentado na Figura
1.1:
• Ofertantes;
• Agentes de inclusão digital; e
• Integrantes das comunidades.
Cabe ao Ofertante postar suas ofertas de modo estruturado, ou seja, indi-
cando as qualificações necessárias para cada oportunidade, quais instituições estão
habilitadas a oferecer tais qualificações, quais eventos estão previstos no calendário
e etc.
Os setores que concentram muitas ofertas de trabalho em nosso estado,
tais como o petrolífero e o da construção naval, possuem entidades que estruturam
as qualificações necessárias para cada profissão e são candidatos naturais a ocupar
este papel.
Neste contexto, cabe ao Agente de inclusão, que já responde pela a infra-
estrutura de TI necessária à inclusão digital, acompanhar e promover ações para o
engajamento dos Integrantes das comunidades atendidas pelo portal e, finalmente,
cabe a cada Integrante interagir com o portal para obter informações de como,
quando e onde se capacitar para transformar a sua realidade.
No Capítulo 2, abordamos a metodologia adotada para o desenvolvimento
deste trabalho e no Capítulo 3 apresentamos a solução proposta. O protótipo é ex-
posto no Capítulo 4 e no quinto capítulo são apresentados os experimentos realiza-
dos, realizados com o protótipo, e seus resultados. Finalmente, no Capítulo 6 apre-
sentamos as conclusões bem como as perspectivas para trabalhos futuros.
14
2 METODOLOGIA
A metodologia de desenvolvimento adotada, para a construção do protóti-
po, utilizou parte do banco de oportunidades existente no PROMINP, com o objetivo
de criar ama base de oportunidades e comunidade fictícias, de forma a possibilitar a
realização dos experimentos bem como aplicar métodos ágeis de desenvolvimento.
Neste contexto coube ao autor o duplo papel de cliente e desenvolvedor.
2.1 CRITÉRIOS ADOTADOS NA ESCOLHA DA METODOLOGIA
Dadas as características desta ferramenta foi um ponto crítico que a me-
todologia adotada desse maior peso à evolução do produto. Assim sendo, decidiu-se
adotar uma metodologia ágil. Neste contexto são consideradas metodologias ágeis
àquelas que tenham princípios aderentes ao “manifesto ágil” [1], descritos por Am-
bler [2], que foi transcrito na seqüência:
1. A prioridade é satisfazer ao cliente através de entregas contínu-as e freqüentes ;2. Receber bem as mudanças de requisitos, mesmo em uma fase avançada do projeto;3. Entregas com freqüência, sempre na menor escala de tempo;4. As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente;5. Manter uma equipe motivada fornecendo ambiente, apoio e confiança necessários;6. A maneira mais eficiente da informação circular é através de uma conversa face-a-face;7. Ter o sistema funcionando é a melhor medida de progresso; 8. Processos ágeis promovem o desenvolvimento sustentável; 9. Atenção contínua a excelência técnica e a um bom projeto au-mentam a agilidade;10. Simplicidade é essencial;11. As melhores arquiteturas, requisitos e projetos provêm de equi-pes organizadas;
15
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz;
(AMBLER , 2004 , p.23)
Porém, todas as metodologias, ágeis ou não, se baseiam num maior ou
menor grau de interação com os usuários do sistema. Esta foi a maior dificuldade
encontrada neste trabalho, visto que foi concebido pelo autor sem a participação de
usuários reais no processo.
Dentre as metodologias emergentes, a que se mostrou mais aderente
com as condições deste projeto foi a Getting Real [3], cujos preceitos estão em linha
com o manifesto ágil, mas admite o desenvolvimento da idéia para o produto sem in-
termediários (não só admite como em parte recomenda que o desenvolvedor seja
também seu próprio usuário). Porém, esta oferece os meios para que ele se comuni-
que com os novos usuários da ferramenta, o que é muito importante neste caso.
16
2.2 DESCRIÇÃO DA METODOLOGIA
Como toda metodologia ágil ela usa metáforas para apresentar seus con-
ceitos. As principais “metáforas” [3] são:
i. Qual é a grande idéia? (Escopo Mínimo -> foque no principal);
ii. Os Três mosqueteiros (Equipes Enxutas -> um desenvolvedor, um designer e
um faxineiro);
iii. Vá logo para o mundo real e veja o que acontece (Processo -> desenvolva e
teste na prática);
iv. A interface primeiro (desenhe a interface com o cliente antes de programar); e
v. Menos código (Mudanças rápidas).
Logo nos início do projeto, ficou clara a necessidade de uma ferramenta
de gerenciamento de conteúdo, cuja análise e escolha foi feita logo no primeiro ciclo
de desenvolvimento, junto com a definição dos requisitos de cada ator.
O processo de construção da ferramenta seguiu, atendendo em cada ci-
clo aos requisitos do Ofertante, do Agente e do Integrante. As primeiras funcionali-
dades desenvolvidas foram as do Ofertante, para que o protótipo tivesse uma mas-
sa de dados para aplicar aos demais atores: o Agente e o Integrante nesta ordem.
3 PROPOSTA
O atual cenário econômico do nosso estado oferece, através dos eleva-
dos investimentos nas áreas do petróleo e da construção naval, diversas oportunida-
17
des de emprego, que não são totalmente aproveitadas por falta de qualificação da
mão de obra.
Visando qualificar esta mão de obra ociosa, foi feito um esforço para iden-
tificar as qualificações necessárias de cada profissão, por parte das organizações
destes setores, tal como o PROMINP do setor petrolífero, de forma a criar cursos e,
assim, promover a qualificação para os empregos do setor Ofertante.
Por outro lado, existe um grande contingente de jovens e adultos perten-
centes às comunidades de baixa renda, que têm sido atendidos por programas de
inclusão digital dos tipos CDI e/ou Telecentro.
A maioria destes programas busca sua sustentação através do ofereci-
mento de cursos de capacitação para monitores da própria comunidade, que se en-
carregam de manter a infra-estrutura das salas em funcionamento, e oferecendo cur-
sos de difusão da cultura digital.
Embora estas ações sejam necessárias elas não são suficientes para que
as comunidades atendidas possam aproveitar tais oportunidades. Isto ocorre por ab-
soluta falta de integração entre os programas de inclusão digital e das organizações
dos setores Ofertantes.
Neste contexto, a ferramenta, desenvolvida neste trabalho, busca integrar
as ações dos CDI’s/Telecentros às dos Ofertantes por meio de um portal, no qual
as informações possam ser compartilhadas entre os Ofertantes e as comunidades.
18
Podemos resumir os requisitos do portal nos seguintes itens:
i. Disponibilizar uma área pública na qual as informações transitem para o público
em geral, permitindo que os interessados se cadastrem no portal.
ii. Garantir que cada ator (Agente, Integrante ou Ofertante) tenha acesso às roti-
nas pertinentes ao seu papel.
iii. Permitir que para cada comunidade e/ou Ofertante cadastrado tivessem um usu-
ário para administrar individualmente o seu próprio conteúdo no portal.
Como podemos notar estes requisitos são fortemente orientados aos pa-
péis de cada ator. Por isso, o detalhamento dos requisitos, descrito nas próximas se-
ções, e foi dividido por ator.
Na seção 3.1 tratamos dos requisitos da área pública, aberta ao público
em geral. Em 3.2 abordamos os requisitos do Ofertante e em 3.3 os do Agente. Fi-
nalmente, em 3.4, descrevemos a ferramenta sob o ponto de vista do Integrante da
comunidade.
3.1 REQUISITOS DA ÁREA PÚBLICA
A área pública é o local onde as informações são compartilhadas com o
público em geral, ou seja, com os usuários registrados ou não na ferramenta. Nela,
também, é importante que seja dada à oportunidade de se cadastrar um novo usuá-
rio, para que a ferramenta atinja ao maior número possível de usuários cadastrados
de forma a cumprir seu objetivo. Além disso, ela provê o acesso aos usuários regis-
trados e recuperação das senhas.
19
Na seqüência temos a descrição dos requisitos do portal para esta área,
que são:
i. Dispor de recursos de pesquisa e filtro dos artigos publicados na área pública.
ii. Permitir cadastramento de novo usuário: um usuário não registrado pode soli-
citar o seu cadastramento, desde que este forneça um endereço válido de e-
mail.
iii. Permitir acesso à área restrita aos usuários cadastrados: o acesso à área res-
trita do portal é permitido aos usuários cadastrados, obviamente após a sua
identificação através do nome do usuário e de sua senha.
iv. Garantir acesso à área restrita correspondente: o acesso à área restrita leva
em consideração o papel que o usuário desempenha e a qual comunidade ele
pertence.
3.2 REQUISITOS DO OFERTANTE
A área do Ofertante no portal é responsável pelo acesso às funcionalida-
des inerentes ao papel dos Ofertantes. Nela os Ofertantes podem manter seu ban-
co de oportunidades, profissões e qualificações, e ainda incluir ofertas de cursos,
empregos e demais notícias de interesse das comunidades.
Na seqüência listamos os requisitos desta área do portal, que são:
i. Permitir a administração do seu conteúdo no portal: é necessário que cada
Ofertante possua um e somente um usuário registrado no portal com permis-
são para administrar o conteúdo deste Ofertante. Este usuário será chama-
do de Ofertante, pois não há mais de um usuário para um mesmo Ofertante.
20
ii. Permitir acesso às funções do Ofertante: acesso à área restrita do portal aos
Ofertantes, para que estes possam cadastrar profissões, informar competên-
cias ou homologar cursos.
iii. Permitir o cadastramento de notícias no portal: funcionalidade para cadastra-
mento de notícias relacionadas aos eventos planejados na área pública do
portal.
v. Permitir planejar eventos: funcionalidade para planejar, promover e divulgar
os eventos para capacitações profissionais, destinados ao público.
iv. Permitir cadastrar instrutores : funcionalidade para cadastrar instrutores, para
os eventos planejados.
v. Permitir cadastrar instituições de ensino: funcionalidade para cadastrar insti-
tuições de ensino para os eventos planejados.
3.3 REQUISITOS DO AGENTE DE COMUNIDADE
A área do Agente é responsável pelo acesso às funcionalidades compatí-
veis com seu papel. Nela os Agentes podem planejar seus eventos e oferecê-los
para suas comunidades e/ou para o público em geral.
Na seqüência apresentamos os requisitos do Agente no portal, que são:
i. Permitir a administração do seu conteúdo no portal: funcionalidade para que
cada comunidade possua um e somente um usuário registrado no portal com
permissão para administrar o conteúdo daquela comunidade. Este usuário
será chamado de Agente da comunidade, pois não há mais de um usuário
com este perfil para a comunidade.
ii. Permitir atualizar os dados da comunidade: acesso a uma área restrita do
portal aos Agentes, para que eles possam atualizar os dados da sua comuni-
dade.
iii. Permitir o cadastro de notícias no portal: com o objetivo de cadastrar notícias
na área pública do portal e/ou da sua comunidade.
21
iv. Permitir planejar eventos: para planejar, promover e divulgar eventos, para
capacitação profissional destinado ao público e/ou à sua comunidade.
v. Permitir cadastrar instrutores: funcionalidade para cadastrar os instrutores dos
eventos planejados para o público e/ou à sua comunidade.
vi. Permitir cadastrar instituições de ensino: funcionalidade para cadastrar insti-
tuições de ensino para os eventos planejados na sua comunidade.
3.4 REQUISITOS DO INTEGRANTE DA COMUNIDADE
Através da área do portal específica para os Integrantes é fornecido o
acesso às funcionalidades referentes ao seu plano de desenvolvimento. Nesta, eles
poderão obter informações sobre as profissões de interesse, as qualificações neces-
sárias e onde obtê-las. Os Integrantes também podem atualizar suas informações
pessoais, sobre as qualificações conquistadas e, também, traçar um plano para ob-
ter as que estão faltando para atingir suas metas. Outra funcionalidade é o acesso
às oportunidades e/ou eventos em andamento, na sua comunidade em particular
e/ou abertas a todos usuários do portal.
Os requisitos do Integrante de comunidade são os seguintes:
i. Permitir atualizar seus dados: prover acesso, aos usuários registrados, à fun-
cionalidade onde possam atualizar seus dados particulares.
ii. Permitir a inscrição nos eventos: ofertar um recurso no portal para que cada
usuário registrado possa se inscrever diretamente nos eventos disponíveis ao
público e/ou sua comunidade particular.
iii. Permitir cadastrar suas habilidades. para que o Integrante possa cadastrar
e/ou acompanhar a evolução de suas habilidades, à medida que participa dos
eventos e adquire competências.
iv. Permitir consultar profissões: consultar as profissões com demanda para os
setores Ofertantes, de forma a escolher a que mais adequada a seus interes-
ses.
22
v. Permitir obter informações sobre a profissão: funcionalidade para simular pla-
nos com as profissões de interesse, comparando suas habilidades com as
exigidas, fazendo testes de aptidão, acessando a seções de perguntas mais
freqüentes, postando dúvidas sobre a profissão no fórum adequado, etc.
vi. Permitir administrar seu plano: funcionalidade para planejar a obtenção das
competências, para atender as exigências das profissões oferecidas pelos se-
tores Ofertantes.
3.5 MODELAGEM DOS DADOS DO PROTÓTIPO
A modelagem de dados da ferramenta migrou de um modelo conceitual,
muito simples, para o modelo de projeto de forma bastante rápida, o que está em
conformidade com a metodologia adotada. Nesta transição vencemos grandes desa-
fios, devido às questões trazidas pela arquitetura utilizada para a implementação,
assunto abordado no Capítulo 4. Entretanto, para uma melhor compreensão da pro-
posta desta ferramenta, vamos abordar neste capítulo o modelo conceitual.
Este modelo foi desenvolvido partindo de algumas premissas. A mais im-
portante é existência de um mapeamento entre uma profissão e as competências
necessárias para ela. Esta abstração deu origem do seu desenho do sistema. O
conceito de competência, no contexto em que estamos tratando, já foi abordado por
Le Boterf (1995) [5] e situa a competência de um indivíduo numa matriz de três di-
mensões: a pessoa (sua biografia, socialização), sua formação educacional e sua
experiência profissional.
Porém estamos realmente interessados é numa abordagem setorial como
a desenvolvida no trabalho de Fleury [4] e implementado na prática pelo Plano Naci-
onal de Qualificação Profissional (PROMINP) [6], que serviu de base para este mo-
delo. As profissões são organizadas em carreiras, de acordo com os segmentos da
Indústria do Petróleo, que podem possuir especializações, os requisitos destas pro-
23
fissões são expressos na forma de especialidades, qualificação técnica e experiên-
cia.
O nosso modelo conceitual busca a simplicidade e, em nome dela, apenas
o básico foi considerado. Assim consideraremos apenas a classe “profissão”, sem
divisões em carreiras, segmentos e especializações, pois isto foge ao escopo defini-
do para este trabalho. O que nos importa é a relação entre a profissão e suas com-
petências. Outras relações importantes são: pessoa e competência; e curso e com-
petência. Com esta abordagem, as classes a serem consideradas são: Profissões,
Pessoas, Competências e Cursos.
Poderíamos, desta forma resumir o modelo básico, conforme apresentado
na Figura 3.1, da seguinte forma: Pessoas escolhem Profissões que exigem Com-petências e fazem Cursos para adquirir tais Competências.
Figura 3-2: Dia-
grama de classes - conceitual
24
4 IMPLEMENTAÇÃO
Neste capítulo, como parte das especificações do sistema, foram selecio-
nados aspectos fundamentais para a sua completa implementação, como a utiliza-
ção uso de algumas das ferramentas definidas para o desenvolvimento requer trei-
namento e experiência, esta implementação será uma indicação para trabalhos futu-
ros. Com o objetivo de validar as especificações foi implementado um protótipo sim-
ples, na linguagem html, dos principais módulos do sistema, que foi utilizado nos ex-
perimentos do Capítulo 5.
Os requisitos da ferramenta apontam diretamente para uma plataforma
WEB, na qual os atores possam trocar e compartilhar informações de qualquer lugar
onde estejam. Mais especificamente, a maioria dos atores deverá incluir o conteúdo
para os demais, que se configura como escopo de aplicações do tipo Contened Ma-
nagement System (CMS) ou de Gerenciamento de Conteúdo, estes e outros aspec-
tos da plataforma serão tratados na seção 4.1.
Como nos capítulos anteriores, a descrição dos casos de uso é fortemen-
te orientada aos papéis de cada ator, por isso, dividimos em seções de 4.4 a 4.7,
acompanhando a mesma divisão feita para os requisitos no Capítulo 3.
4.1 PLATAFORMA
Os requisitos funcionais, descritos no Capítulo 3, apontam para adoção
de uma solução WEB de modo a permitir que usuários das comunidades, espalha-
25
das pelo Brasil, possam interagir com os Ofertantes através do portal. Uma platafor-
ma WEB é composta, entre outros componentes, por um sistema operacional, um
servidor WEB, por um servidor de banco de dados e por uma linguagem para cons-
trução de páginas dinâmicas. No nosso caso específico, devido às características da
ferramenta, é importante a presença de um componente para gerenciamento de
conteúdos das páginas pelos próprios usuários. Nas subseções 4.1.2 a 4.1.4 são
discutidos os critérios para escolha de cada um destes componentes.
Na subseção 4.1.1 trataremos de outros requisitos não funcionais, mas
que têm um forte impacto na escolha destes componentes.
4.1.1 REQUISITOS NÃO FUNCIONAIS
A ferramenta, aqui apresentada, possui requisitos funcionais que podem
ser atendidos por, praticamente, qualquer plataforma existente no mercado. Assim
sendo é conveniente identificar outros critérios para orientar sua escolha. Entre os
critérios possíveis, a definição do uso de software livre é muito importante, pois esta
escolha é coerente com a maioria dos programas de inclusão digital. Como nossa
ferramenta tem este público alvo, convém aderir a este requisito.
4.1.2 SISTEMA OPERACIONAL E SERVIDOR WEB
A decisão, pelo uso de software livre, tem impacto direto na escolha do
sistema operacional e servidor WEB, cuja escolha natural aponta para o sistema
operacional Linux e o servidor WEB Apache, pela estabilidade, escalabilidade destas
ferramentas e pela força das suas respectivas comunidades de desenvolvedores
(estes sistemas estão em constante evolução).
26
4.1.3 GERENCIAMENTO DE CONTEÚDO
Todos os principais requisitos do portal apontam para a necessidade de
uma ferramenta flexível, que permita aos usuários manterem seus próprios conteú-
dos. Existe uma classe de ferramentas dedicadas esta função os chamados CMS
(Contened Manager Systems). Atualmente temos disponíveis no mercado diversos
CMS, que atendem aos requisitos funcionais da ferramenta e que são software livre.
Os principais critérios para escolha foram: a facilidade e a rapidez de im-
plementação; o tamanho da comunidade (pela velocidade e consistência que isto
provoca nas atualizações do produto); a freqüência de atualização das novas
versões; e a possibilidade de integração das funcionalidades, desenvolvidas especi-
ficamente para a ferramenta, de forma a serem disponibilizadas para a comunidade
desenvolvedora do produto.
Utilizando estes critérios, entre as avaliadas escolhi o Joomla! [7]. Esta es-
colha foi decisiva na seleção dos demais componentes, como veremos nas próximas
subseções.
Uma ferramenta como o Joomla! encaminha todas as soluções para o tipo
de aplicação para o qual ela foi desenhada, ou seja, um CMS. Desenvolver uma so-
lução, integrada ao ambiente do Joomla!, utilizando as extensões permitidas por seu
framework adequadamente, requer um grau de maturidade no uso deste tipo de fer-
ramenta acima de minhas possibilidades atuais. Portanto, o desenvolvimento do sis-
tema utilizando as ferramentas selecionadas será alvo de futuros trabalhos.
Por outro lado, como objetivo deste trabalho foi desenvolver um protótipo
que permitisse apresentar o conceito da solução proposta e sua viabilidade de im-
plementação, optamos por usar nos casos de teste arquivos html puro, como con-
vém a um protótipo e por descrever como ela pode ser feita.
27
A Figura 4-1 mostra os principais componentes de sua arquitetura. Para
maiores informações sobre o Joomla! recomendo o acesso ao site do produto no
Brasil [7],. Na seqüência, incluo algumas informações sobre os componentes apre-
sentados na a Figura 4-1.
As extensões são classificadas de acordo com seu uso. Os componentes,
módulos e plug-ins , permitem a implementação de todo tipo de aplicação. Os tem-
plates e lanquages que são usadas com um fim específico, identidade visual e idio-
ma , respectivamente.
Os módulos são extensões que ficam sempre visíveis na página, geral-
mente menus, calendários, etc no entorno do conteúdo central e plug-ins são usados
para tratar eventos, em geral trabalham associados aos componentes
Os componentes são a extensão mais importante, pois nela estão imple-
mentadas as “bibliotecas” do sistema, segundo James Kennard [8] é a base funda-
mental para o desenvolvimento utilizando o Joomla!. Desde a versão 1.5 , o fra-
mework do Joomla! implementa a arquitetura MVC1. As classes abstratas JModel,
JView e JControl, oferecidas pela biblioteca do Joomla! é a essência do framework e
os componentes estendem estas classes.
Uma das características positivas do Joomla! é que a simples utilização de
seu site administrador permite com seus componentes básicos implementar facil-
mente um CMS.
1 MVC - Model-view-controller é um padrão de arquitetura de software. Com o aumento da complexi-
dade das aplicações desenvolvidas torna-se fundamental a separação entre os dados (Model) e o
layout (View). Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes
poderão ser reorganizados sem alterar o layout. O model-view-controller resolve este problema atra-
vés da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de
interação com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em
padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é tí-
pico para um padrão de projeto (Fonte: Wikipédia - http://pt.wikipedia.org/wiki/MVC).
28
Figura 4-3: Arquitetura do Joomla!
4.1.4 BANCO DE DADOS E LINGUAGEM DE APLICAÇÃO
Como conseqüência direta da escolha do Joomla! foram adotadas as
mesmas ferramentas utilizadas e, conseqüentemente, melhor suportadas por ele,
que foram: o servidor de banco de dados MySQL e a linguagem de programação o
PHP.
29
4.2 DIAGRAMA DE NAVEGAÇÃO
A ferramenta direciona a navegação pelas páginas do site segundo o
papel que cada ator desempenha, conforme apresentado na Figura 4-1. Assim, uma
vez identificado o usuário no login, seu papel fica definido e este é direcionado às
páginas correspondentes ao seu papel (Ofertante, Agente de Comunidade e
Integrante). Os visitantes não cadastrados tem acesso somente as notícias
públicas.
Figura 4-4: Mapa das páginas do site
30
4.3 CASOS DE USO
Os casos de uso conceituais foram muito úteis para a construção do protó-
tipo, embora a metodologia adotada não exija o seu uso, mas devido a sua capaci-
dade de organizar funcionalidades para atender aos requisitos funcionais, este foi
fundamental para o sucesso do desenho e projeto do sistema. Logo na primeira ite-
ração foi desenhado um diagrama de casos de uso, de forma a mapear as necessi-
dades de cada ator em casos de uso, conforme apresentado na Figura 4-2.
Figura 4-3: Diagrama de casos de uso
31
4.3.1 CASOS DE USO DO PORTAL: PRINCIPAL
Pela página principal, os visitantes podem ter acesso aos artigos, informa-
ções e ofertas postadas ao público em geral, estes podem também se cadastrar
para poder ter acesso à área restrita aos usuários cadastrados ou se identificar
como usuário cadastrado para acessar a área correspondente ao seu papel.
i. Cadastrar Novo Usuário: todo usuário deverá se cadastrar no portal, inde-
pendentemente do papel que ele vai cumprir. Ao se cadastrar o usuário infor-
ma um e-mail para contato. O portal então envia uma mensagem com um link
de confirmação. Esta funcionalidade é “nativa” do Joomla! e atendeu aos re-
quisitos sem precisar ser alterada.
ii. Atualizar Meus Dados, Atualizar Dados das Comunidades e Atualizar Dados do Ofertante: estes três casos de uso, são utilizados (“estendidos”)
inicialmente no passo seguinte do cadastro do usuário. O link enviado para o
usuário aponta para uma página desenvolvida para habilitar o login e comple-
mentar o cadastramento do usuário e das entidades as quais ele está relacio-
nado. Assim, um Ofertante deverá informar os campos relativos à instituição
a qual ele pertence, ou seja, cadastrar o Ofertante ,etc., analogamente o
Agente deverá preencher um formulário para cadastrar sua comunidade bem
como o Integrante deve informar a qual comunidade pertence. Embora estes
casos de uso pudessem ser chamados de Cadastrar Ofertantes e Cadastrar Comunidades, preferi adotar o termo Atualizar, pois uma vez cadastrada(o)
a Comunidade ou Ofertante só poderão ser atualizados.
iii. Pesquisar Notícias: este caso de uso dá acesso às notícias postadas pelos
Ofertantes ou Agentes de comunidade. Esta, também, é uma funcionalidade
“nativa” do Joomla!
32
4.3.2 CASOS DE USO PORTAL: OFERTANTE E AGENTE
Os portais do Ofertante e do Agente possuem um conjunto de casos de
uso básicos, com os quais eles podem gerenciar suas notícias, eventos etc. em con-
formidade aos requisitos i. a v. das seções 3.2 e 3.3, estes são descritos conceitual-
mente a seguir:
i. Atualizar Dados das Comunidades e Atualizar Dados do Ofertante: estes
dois casos de uso, no contexto de seus portais, são utilizados para atualizar
os dados de cadastro de suas comunidades ou Ofertantes.
ii. Postar Notícias: este caso de uso permite que uma notícia de interesse do
Ofertante ou Agente possa ser criada.
iii. Planejar Eventos: neste caso de uso o Ofertante ou Agente poderá planejar
um evento para uma determinada data, alocando recursos ao evento, indican-
do cursos oferecidos, aceitando candidatos e etc.
iv. Cadastrar Instrutor: caso de uso para se cadastrar instrutores e/ou certificá-
los nos cursos.
v. Cadastrar Instituição de Ensino: caso de uso para se cadastrar instituições
de ensino habilitadas a fornecer cursos de treinamento.
O portal do Ofertante possui ainda alguns casos de uso específicos para
funções de seu uso, correspondentes aos requisitos indicados no item ii da seção
3.2 do Capítulo 3.
vi. Cadastrar Profissões: uma das principais funções do Ofertante é mapear a
profissões e suas competências. Através deste caso de uso o Ofertante pode
cadastrar uma profissão e, ainda, identificar ou atualizar as competências exi-
gidas.
vii. Atualizar Competência: alternativamente o Ofertante pode atualizar uma
competência.
33
viii.Certificar Cursos: este caso de uso permite que um curso oferecido por uma
instituição de ensino possa ser certificado. Esta certificação deverá indicar
quais as competências são adquiridas no curso.
4.3.3 CASOS DE USO DO PORTAL: INTEGRANTE
No Meu Portal o Integrante de uma comunidade poderá administrar seu
plano de carreira com a aquisição de competências para a profissão desejada. Estes
casos de uso foram desenhados para aos requisitos indicados nos itens da seção
3.4 do capítulo 3:
i. Atualizar meus Dados: este caso de uso permite a atualização das informa-
ções do Integrante (item i).
ii. Consultar Profissões: este caso de uso permite a consultar as informações
e notícias sobre uma profissão de seu interesse (item iv).
iii. Simular Planos: o Integrante pode levantar o hiato de competência para se-
guir alguma outra carreira, antes de decidir por escolhê-la (itens iv e v).
iv. Administrar Plano: os planos de carreira são elaborados pela identificação
dos cursos necessários para obter as competências requisitadas (item vi).v. Cadastrar Minhas Habilidades: à medida que habilidades são adquiridas,
através dos cursos e eventos oferecidos no portal, estas migram para este ca-
dastro. Através dele é possível ainda indicar outra fonte de obtenção de com-
petências (item iii).vi. Inscrever-se em Eventos: este caso de uso é utilizado sempre que o Inte-
grante desejar participar de algum evento programado para a sua comunida-
de (item ii).
34
5 EXPERIMENTOS
Os experimentos realizados com o protótipo desenvolvido pretenderam
avaliar as funcionalidades de cada um dos casos de uso, dentro de um conjunto de
cenários representativos de sua utilização. Nas seções deste capítulo são apresen-
tados os resultados obtidos nos experimentos realizados com a ferramenta, de for-
ma a simular os seguintes cenários:
1. Cenário 1 - Cadastramento de um novo usuário, Integrante de comunida-
de, no portal (seção 5.1).
2. Cenário 2 - Acesso ao portal por um Ofertante para o cadastramento de
uma nova profissão, indicando as competências necessárias e incluindo uma
competência ainda não cadastrada (seção 5.2).
3. Cenário 3 - Acesso ao portal por um Ofertante para o cadastramento de
um curso que atenda a competência cadastrada previamente no item 2 (se-
ção 5.3).
4. Cenário 4 - Acesso ao portal por um Agente de comunidade para cadas-
trar um instrutor do curso inserido no item 3, bem como o planejamento de um
evento para ofertá-lo a sua comunidade (seção 5.4).
5. Cenário 5 - Acesso de um Integrante desta comunidade para consulta ao
seu plano e para inscrição no evento cadastrado no item 4 (seção 5.5).
Os experimentos que representam estes cenários estão detalhados nas
próximas seções.
35
5.1 CENÁRIO 1: CADASTRAMENTO DE UM NOVO USUÁRIO
O cadastramento de um novo usuário foi o primeiro cenário a ser explora-
do. A Figura 5-1 exibe os casos de uso associados a este cenário. Para cumpri-lo fo-
ram realizados os seguintes experimentos:
1. Acesso à página principal do portal.
2. Acesso à página de cadastramento do usuário.
3. Recebimento de e-mail
4. Acesso ao link e cadastramento de Integrante.
Estes passos são abordados na seqüência.
Figura 5-5: Casos de uso do cenário 1
36
5.1.1 ACESSO À PÁGINA PRINCIPAL
A página principal é a porta de entrada do público em geral. Ela é respon-
sável pelo acesso à área pública, na qual as informações são compartilhadas entre
todos os usuários do portal, ou seja, com os usuários registrados ou não na ferra-
menta. Além disso, ela provê o acesso aos usuários registrados bem como a recu-
peração das senhas.
Figura 5-2: Página principal do portal
Na página principal podemos cadastrar um novo usuário, como foi explo-
rado neste experimento. A Figura 5-2 exibe sua aparência. Note o link registre-se,
destacado na figura, pois é este que possibilita o acesso à próxima página.
37
5.1.2 ACESSO À PÁGINA DE CADASTRAMENTO DO USUÁRIO
O fluxo principal do caso de uso Cadastrar Novo Usuário segue os se-
guintes passos:
1. O usuário acessa o link registre-se na página principal do portal (Figura 5-2).
2. O portal exibe página de Cadastramento de Usuário (Figura 5-3).
3. O usuário informa: nome do usuário, identificação do usuário, senha e conta de
e-mail.
4. O portal valida dados do formulário e passa um e-mail para conta indicada com a
chave para desbloquear o usuário no portal.
Figura 5-3: Cadastrar usuário portal
38
Neste ponto colocamos os casos de teste para este cenário, apresenta-
dos na seqüência:
• e-mail já cadastrado (Figura 5-4).
• identificação já utilizada por outro usuário (Figura 5-5).
• cadastramento efetuado com sucesso, apresentado na (Figura 5-6).
Figura 5-4: Caso de teste e-mail já cadastrado
Figura 5-5: Caso de teste usuário em uso
Figura 5-6: Cadastramento efetuado com sucesso
39
Todos estes casos de testes se comportaram como esperado. Isto é com-
provado pelas mensagens recebidas e apresentadas nas figuras anteriores.
O passo seguinte foi acessar o link, recebido com sucesso via e-mail, e
complementar o cadastramento informando sua comunidade. O resultado alcançado
nesta operação foi correto, conforme apresentado na Figura 5-7.
Figura 5-7: Cadastramento integrante da comunidade
40
Figura 5-6: Caso de Teste "Usuário ok"
5.2 CENÁRIO 2: O OFERTANTE CADASTRA UMA NOVA PROFISSÃO
O cadastramento de uma nova profissão foi o cenário seguinte a ser ex-
plorado. A Figura 5-8 exibe os casos de uso necessários para cumpri-lo. Eles foram
realizados na seguinte ordem através dos experimentos descritos nas próximas sub-
seções :
I. Cadastrar uma nova profissão (5.2.1)
II. Criar uma nova competência (5.2.2)
III. Indicar as competências requisitadas pelo profissão .(5.2.3)
Figura 5-8: Cadastrar nova profissão
5.2.1 CADASTRAR NOVA PROFISSÃO
O cadastramento de uma nova profissão é uma funcionalidade exclusiva
dos Ofertantes. Em nosso experimento simulamos o acesso ao portal com uma
conta de usuário do PROMINP. O experimento foi efetuado na seguinte ordem de
navegação:
1. Acesso ao portal do Ofertante pela página principal do portal
(Figura 5-2) com uma conta de usuário do Ofertante.
41
2. Acesso à página de Cadastrar Profissão através da página
principal do Ofertante no link Cadastrar Profissão, assinalado na Fi-
gura 5-9.
3. O portal exibe a página Consultar Profissões, base para
acesso às outras páginas relativas aos casos de uso Cadastrar Pro-fissão e Atualizar Competências de uma determinada profissão.
Neste experimento fizemos o acesso à página Cadastrar Profissão através do ícone Nova, destacado na Figura 5-10.
4. Acionado o link do ícone Nova, que foi destacado na Figura 5-
10, tivemos acesso à página para cadastramento de uma nova profis-
são, conforme apresentado na Figura 5-11.
5. Ao final do preenchimento dos campos o Ofertante aciona o
botão Cadastro;
6. O portal emite mensagem de sucesso e retorna para página
Consulta Profissões , aguardando uma nova ação do Ofertante.
Figura 5-9: Portal do ofertante
42
Figura 5-60: Cadastra profissões – página inicial - consulta
Figura 5-11: Página cadastra nova profissão
43
5.2.2 CADASTRAR UMA NOVA COMPETÊNCIA
Neste experimento exploramos a inclusão de uma nova competência no
portal. Isto é feito através do ícone Novo da página de Competências da Profissão – Consulta, indicada na Figura 5-15, que dá acesso à página de Cadas-trar Nova Competência.
1. Acionamos o ícone Novo, na página de Competências da Profissão – Consulta, para cadastramos uma nova competência (Fig
5-15).
2. O portal exibe a página de Cadastrar Nova Competência (Figura 5-12). Neste momento, os campos Descrição Resumida e
Descrição foram prenchidos e acionamos o botão Cadastro, destacado na Figura 5-12, para concluirmos seu cadastramento.
3. O portal retorna à página de Competências da Profissão - Consulta na qual acionamos o botão Atualiza (Figura 5-13).
Figura 5-72: Cadastrar nova competência
44
Figura 5-13: Atualizar competências
5.2.3 INDICAR AS COMPETÊNCIAS DA PROFISSÃO
Ao final do experimento II, do cenário Ofertante - Cadastra nova Profis-são (seção 5.2), com o caso de uso Cadastrar Profissão, descrito na subseção
5.2.1, prosseguimos neste cenário com o experimento III . Neste experimento explo-
ramos a navegação da página de Consultar Profissões para página de Atualizar Competências, de forma a indicarmos quais são as competências necessárias para
a profissão que cadastramos no experimento I. Para tal, efetuamos os seguintes
passos:
1. O Ofertante aciona o icone Atualiza, indicado na Figura 5.15, da página
Consultar Profissões da linha correspondente à profissão desejada.
2. O portal exibe a página Competências da Profissão – Consulta, na qual
todas as competências cadastradas são exibidas.
45
3. Nesta página, Figura 5.14, indicamos as competências associadas a
profissão.
Figura 5-14: Cadastrar profissões - atualiza competência
Figura 5-85: Atualizar competências – indica
46
5.3 CENÁRIO 3: O OFERTANTE CERTIFICA O CURSO
A certificação de cursos, que promovam as competências demandadas
pelas profissões cadastradas pelo Ofertante, é um dos cenários típicos realizados
após o cadastramento de uma nova profissão. Realizamos nesta seção experimen-
tos que complementam o cenário anterior.
Neste cenário simulamos a necessidade de se cadastrar e certificar um
curso, para atender a uma competência requisitada no experimento II, que é ofereci-
da por uma instituição de ensino, ainda não cadastrada. Nesta seção apresentamos
os experimentos IV e V explorados neste cenário.
A Figura 5-16 exibe os casos de uso envolvidos neste cenário. Eles fo-
ram realizados na seguinte ordem, descritos nas próximas seções :
I. Cadastrar uma nova instituição de ensino (5.3.1)
II. Certificar um curso (5.3.2)
Figura 5-16: Certifica curso
47
5.3.1 CADASTRAR UMA NOVA INSTITUIÇÃO DE ENSINO
Neste experimento exploramos a inclusão de uma nova instituição de en-
sino no portal. Isto é feito através do ícone Novo da página Certificar Curso – Consulta, destacado na Figura 5-17. O acesso a esta página se deu pelo link Certi-ficar Curso, indicado na mesma figura.
Figura 5-17: Certifica curso - consulta
Nesse experimento cadastramos a instituição de ensino chamada ABRA-MAN. Durante esta ação o sistema se comportou forma adequada conforme vere-
mos na próxima subseção.
5.3.2 CERTIFICAR CURSO
A certificação do curso foi simulada em conjunto com o seu cadastramen-
to, pois tanto o curso quanto a instituição de ensino não estavam cadastrados até
este ponto do experimento.
Após o cadastramento da instituição de ensino uma nova linha aparece
na página Certifica Curso – Consulta, conforme exibido na Figura 5-18.
48
O acesso à página Editar Cursos se dá pelo ícone Editar, assinalado na
Figura 5-18. A página Editar Cursos (que permite editar, cadastrar e certificar cur-
sos - Figura 5-19) foi capturada após a conclusão do cadastramento do curso de
Montagem Mecânica na ABRAMAN, que foi feito através do acesso à página de
Cadastro de Cursos utilizando o ícone Novo.
Já o acesso à página de Certificação do Curso se dá pelo ícone Editar. Nesse experimento o curso foi cadastrado na instituição de ensino ABRAMAN e a
Figura 5-19 mostra o experimento após o cadastramento do curso, mas antes de
sua certificação.
Na certificação de um curso as competências providas por ele deverão
ser informadas. Isto é feito pela página Competências do Curso, ilustrada pela Fi-
gura 5-20. Nesta página assinalamos a competência desejada e atualizamos o portal
acionando o botão Atualiza, destacado na Figura 5.20.
Figura 5-18: Certifica curso – edita / novo curso
49
Figura 5-19: Certifica curso – consulta
Figura 5-20: Certifica curso
50
5.4 CENÁRIO 4: O AGENTE PROGRAMA UM EVENTO
A programação de um evento é um dos cenários típicos, no qual o Agen-
te de comunidade atua. Nele são programados os eventos de forma a oferecê-los
em sua comunidade ou para o público em geral. Nesta seção apresentamos os ex-
perimentos que exploraram este cenário.
A Figura 5-21 exibe os casos de uso envolvidos neste cenário e, para os
quais, realizados nos experimentos VI e VII, descritos nas próximas seções:
I. Cadastrar um novo instrutor (5.4.1)
II. Planejar e ofertar um evento (5.4.2)
Figura 5-21: Planejar eventos
Para a execução destes experimentos foi criado o usuário Admin CE-DERJ, que é um Agente da comunidade fictícia designada por CEDERJ.
51
5.4.1 O AGENTE CADASTRA UM NOVO INSTRUTOR
No experimento VI foi simulada a necessidade de se cadastrar um novo
instrutor para o curso cadastrado na subseção 5.3.2. Para isso, acessamos a página
principal do portal do Agente e, em seguida, à página Cadastrar Instrutor através
do link Instrutores, em destaque na Figura 5-22.
Nesta página criamos o instrutor Mário Andrade, informando seu e-mail,
a instituição de ensino a que ele pertence (no caso ABRAMAN) e o curso que ele
ministra (PNQC – Montagem Mecânica), feito isto acionamos o botão Cadastrar (Figura 5-22).
Uma mensagem foi enviada para o endereço e-mail fornecido, de forma a
avisar ao instrutor que ele foi cadastrado no portal. Este aviso é opcional, mas foi so-
licitado, como podemos observar na Figura 5-22, e se encontra imediatamente aci-
ma do botão Cadastrar.
Figura 5-22: Instrutores cadastra
52
5.4.2 O AGENTE PLANEJA E OFERTA UM EVENTO
O experimento VII, o último a ser efetuado neste cenário, simula o plane-
jamento e oferecimento do curso PNQC Montagem Mecânica aos usuários cadas-
trados no portal.
O primeiro passo realizado foi consultar a programação de eventos acio-
nando o link Eventos, destacado na Figura 5-23. Acessamos então a página de
Programação de Eventos, que mostra os eventos programados pelo Agente. Nes-
te momento, um novo evento foi então programado acionando-se o link Postar Notí-cias (Figura 5-24), que nos deu acesso à página Postar Notícias.
A página Postar Notícias permitiu publicar uma notícia oferecendo o
evento simulado neste experimento, para o qual os usuários cadastrados podem se
inscrever por um link incluído na própria notícia. Este recurso foi conseguido através
da seleção de parte do texto, no caso do experimento a palavra Aqui e o ícone ân-cora, ambos destacados na Figura 5-24, que solicita o endereço da página da WEB,
na qual a inscrição pode ser feita.
Neste experimento, a notícia foi publicada para público em geral, pois
esta foi à seleção feita no campo Nível de Acesso, assinalado na Figura 5-25, que
complementa a página Postar Notícias da Figura 5-24.
Após salvar esta notícia acionando o botão Salvar, destacado na Figura
5-24, acessamos novamente a página de Programação de Eventos onde obtive-
mos o resultado apresentado na Figura 5-26.
53
Figura 5-23: Programação de eventos
Figura 5-24: Postar notícias
54
Figura 5-25: Postar notícias - complemento
Figura 5-26: Programação eventos – resultado
Conforme podemos verificar através do conjunto de figuras desta subse-
ção que durante os experimentos o sistema se comportou dentro do esperado.
55
5.5 CENÁRIO 5: O INTEGRANTE SE INSCREVE NO EVENTO
O cenário típico de um Integrante de comunidade é aquele no qual ele se
inscreve nos eventos oferecidos através do portal, de forma a adquirir as competên-
cias necessárias ao seu plano.
I. Inscrever-se no evento (5.5.1)
II. Consultar meu plano (5.5.2)
Figura 5-27: Inscrever-se em um evento
5.5.1 INSCREVE-SE NO EVENTO
Neste experimento executamos o procedimento de inscrição. Pata tal, nós
utilizamos o usuário cadastrado no experimento 1 do cenário 1 descrito na subseção
5.1.2.
Ao acessarmos o portal com esta conta de usuário obtivemos acesso à
página principal, na qual tanto as notícias públicas quanto às direcionadas aos usuá-
rios registrados estão disponíveis conforme apresentado na Figura 5-28 .
56
Entre elas se encontra o evento ofertado pelo Agente chamado Admin CEDERJ, incluído no experimento VII da seção 5.4.
Figura 5-28: Inscrever-se em evento
Acionando o link, destacado na Figura 5-28, temos acesso ao site do
Ofertante, no qual foi possível realizar a inscrição para o evento.
57
5.5.2 CONSULTA PLANO
Concluindo o cenário Inscrever-se no Evento, simulamos neste experi-
mento uma Consulta Plano, na qual o Integrante verifica em quais os eventos está
inscrito. Para isto acessamos a página Consulta Meus Eventos, apresentada na Fi-
gura 5-29, através do link Meus Eventos, destacado na mesma figura.
Figura 5-29: Meus eventos - resultado
Conforme podemos observar o resultado do experimento foi o esperado.
58
6 CONCLUSÕES E TRABALHOS FUTUROS
O conjunto de experimentos realizados, percorrendo os principais cenári-
os representativos da interação entre os atores, pretendeu mostrar a potencialidade
desta ferramenta, que por ser um protótipo precisa conquistar, entre os possíveis in-
teressados, um que financie o seu efetivo desenvolvimento.
Independentemente de qualquer resultado alcançado, ao final deste traba-
lho posso contabilizar os seguintes ganhos obtidos no desenvolvimento do mesmo:
1. Aquisição de experiência na produção de um trabalho formal
acadêmico.
2. Aprofundamento do conhecimento técnico de um framework
CMS profissional.
No futuro desejo, além de completar o desenvolvimento desta ferramenta,
aproveitar os conhecimentos adquiridos, no desenvolvimento deste trabalho, para
aprofundar meus estudos na relação entre a informática e a sociedade.
59
REFERÊNCIAS BIBLIOGRÁFICAS
1. BACK, Kent e Outros . Manifesto for Agile Software Development, Snow-
bird, Utah , fev.2001 disponível em .<http://www.agilemanifesto.org> Acesso
em 06 out. 2008
2. SCOOT, Ambler. Modelagem Ágil: Praticas eficazes para Programação Extrema e o Processo Unificado. 1.ed. Porto Alegre: Bookman, 2004.
3. FRIED, Jason, HANSSON, David Heinemeier e outros Getting Real. Março
2006 .<http://gettingreal.37signals.com/toc.php> Acesso em 06 out. 2008
4. FLEURY, A. C. C, FLEURY, M. T. L. Estratégias Empresariais e Formação de
Competências. ed. São Paulo: Atlas, 2000.
5. LE BOTERF, G. De la compétence – essai sur un attracteur étrange.
Paris:Quatrième Tirage, 1995.
6. PROMINP. Plano Nacional de Qualificação Profissional. < http://www.pro-
minp.com.br/paginadinamica.asp?grupo=245&apres=dflt> Acesso em 10 out.
2008.
7. JOOMLA!.Site do Joomla! Brasil <http://www.joomla.com.br/> Acesso em 10
out. 2008.
8. KENNARD J. Mastering Joomla 1.5 Extensions and framework develop-ment ISBN 1847192823 Mumbai Packt Publishing ,2007
60
