Portal Acompanhamento Egressos IFRS

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA
E TECNOLOGIA DO RIO GRANDE DO SUL
CÂMPUS BENTO GONÇALVES
PORTAL DE ACOMPANHAMENTO DE EGRESSOS
CASSIANO DA SILVA CARRARO
Bento Gonçalves, Dezembro de 2013

Relatório de estágio apresentado junto
ao curso de Técnico em Informática para
Internet do Instituto Federal de
Educação, Ciência e Tecnologia do Rio
Grande do Sul – Câmpus Bento
Gonçalves, como requisito parcial à
obtenção do título Técnico em
Informática para Internet.
Orientadora: Prof. Ma. Lissandra
Luvizão Lazzarotto.
Bento Gonçalves, Dezembro de 2013

Relatório de estágio apresentado junto
ao curso de Técnico em Informática para
Internet do Instituto Federal de
Educação, Ciência e Tecnologia do Rio
Grande do Sul – Câmpus Bento
Gonçalves, como requisito parcial à
obtenção do título Técnico em
Informática para Internet.
Orientadora: Prof. Ma. Lissandra
Luvizão Lazzarotto.
Aprovado em Dezembro, 2013.
___________________________________________________
Ma. Lissandra Luvizão Lazzarotto – Orientador
___________________________________________________
Dr. Sandro Neves Soares – Coorientador

RESUMO
Com a necessidade de melhorar a divulgação e otimizar o trabalho de
acompanhamento dos egressos, deu-se inicio ao projeto de extensão, Portal de
Acompanhamento de Egressos para o Instituto Federal de Educação, Ciência e
Tecnologia do Rio Grande do Sul – Câmpus Bento Gonçalves. A metodologia
utilizada para o desenvolvimento é composta de oito etapas: estudos e levantamento
de requisitos, análise e projeto dos requisitos levantados, construção de protótipos
de telas, avaliação dos protótipos, implementação, testes do produto, implantação
em um servidor e alimentação da base de dados. Para que fosse possível interligar
o egresso com a instituição, buscou-se utilizar e aplicar tecnologias e linguagens
web que podem ser executadas por meio de navegadores, presentes nos mais
diversos dispositivos. Desta forma, o produto gerado foi capaz de suprir as
necessidades do cliente, pois criou-se um ambiente para o egresso atualizar seus
dados, um portal para divulgação de informações e um ambiente administrativo
composto por diversas funcionalidades que auxiliam o gerenciamento dos egressos
e otimizam o trabalho dos servidores envolvidos.
Palavras-chave: estágio curricular, egresso, software.

LISTA DE TABELAS
Tabela 1: Cronograma de atividades do estágio.........................................................14
Tabela 2: Requisitos funcionais...................................................................................32
Tabela 3: Requisitos não funcionais............................................................................33
Tabela 4: Regras de negócio.......................................................................................34

LISTA DE FIGURAS
Figura 1: Estrutura do modelo incremental.................................................................23
Figura 2: Estrutura do modelo cascata.......................................................................23
Figura 3: Importância da modelagem de requisitos....................................................25
Figura 4: Esquema de módulos do Doctrine 2............................................................28
Figura 5: Declaração básica de dependência.............................................................29
Figura 6: Portal de egressos UNIVALI........................................................................31
Figura 7: Portal de egressos UFSC............................................................................31
Figura 8: Casos de uso do ator administrador............................................................35
Figura 9: Casos de uso do ator egresso.....................................................................36
Figura 10: Normalização de dados.............................................................................38
Figura 11: Diagrama ER do administrador..................................................................40
Figura 12: Diagrama ER do egresso...........................................................................41
Figura 13: Diagrama de classes parcial......................................................................43
Figura 14: Mapeamento das páginas do site..............................................................45
Figura 15: Protótipo da página inicial..........................................................................45
Figura 16: Protótipo da página cadastre-se................................................................46
Figura 17: Área administrativa: Listagem de egressos...............................................47
Figura 18: Área administrativa: Gráficos e Relatórios................................................49
Figura 19: Layout do portal em desktops....................................................................50
Figura 20: Layout do portal em tablets........................................................................50
Figura 21: Layout do portal em celulares....................................................................51
Figura 22: Área do egresso.........................................................................................52
Figura 23: Logo do Portal do Egresso........................................................................52
Figura 24: Estrutura dos módulos...............................................................................53
Figura 25: Dependências da aplicação.......................................................................55
Figura 26: Configuração da conexão com a base de dados......................................56
Figura 27: Código parcial da entidade curso..............................................................57
Figura 28: Controlador do administrador....................................................................58
Figura 29: Controlador da página inicial.....................................................................59
Figura 30: Objeto gerador do gráfico em colunas.......................................................60
Figura 31: Controlador de testes.................................................................................62
Figura 32: Execução de testes....................................................................................63

LISTA DE SIGLAS
AJAX Asynchronous Javascript and XML
ASCII American Standart Code for Information Interchange
CSS Cascading Style Sheets
DTI Departamento de Tecnologia de Informação
ER Entidade e Relacionamento
E-MAG Modelo de Acessibilidade de Governo Eletrônico
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IBGE Instituto Brasileiro de Geografia e Estatística
IFRS-BG Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do
Sul – Câmpus Bento Gonçalves.
JSON Javascript Object Notation
MEC Ministério da Educação
MVC Model-view-controller
NAPNE Núcleo de Apoio às Pessoas com Necessidades Especiais
PHP Hpertext Preprocessor
RF Requisitos Funcionais
RN Regras de Negócio
RNF Requisitos não Funcionais
SAIE Sistema de Acompanhamento Institucional de Egressos
SQL Structured Query Language
UML Unified Modeling Language
URL Uniform Resource Locator

WCGA Web Content Accessibility Guidelines
W3C World Wide Web Consortium
ZF2 Zend Framework 2

SUMÁRIO
1 INTRODUÇÃO.......................................................................................................11
1.1 METODOLOGIA..................................................................................................12
1.2 CRONOGRAMA..................................................................................................13
2 FUNDAMENTAÇÃO TEÓRICA.............................................................................17
2.1 EGRESSO COMO FONTE INFORMAÇÃO........................................................17
2.2 ACESSIBILIDADE NA WEB................................................................................18
2.2.1 Vantagens de um site acessível...................................................................18
2.2.2 Mitos sobre acessibilidade Web...................................................................19
2.2.3 Padrões E-MAG e WCGA...............................................................................19
2.2.4 Validadores de padrões e diretrizes.............................................................20
2.3 PROCEDIMENTOS METODOLÓGICOS...........................................................21
2.3.1 Processo de Desenvolvimento de Software...............................................22
2.3.1.1 Levantamento De Requisitos........................................................................24
2.3.1.2 Análise e Projeto...........................................................................................24
2.4 FERRAMENTAS DE PROGRAMAÇÃO.............................................................25
2.4.1 Linguagens Web.............................................................................................26
2.4.2 Zend Framework 2..........................................................................................26
2.4.3 Doctrine 2........................................................................................................27
2.4.4 Gerenciador de Dependências.....................................................................29
3 O PORTAL DE ACOMPANHAMENTO DE EGRESSOS DO IFRS – BG.............30
3.1 LEVANTAMENTO E ESPECIFICAÇÃO DOS REQUISITOS..............................30
3.1.1 Requisitos Funcionais...................................................................................32
3.1.2 Requisitos não Funcionais............................................................................33
3.1.3 Regras de Negócio.........................................................................................34
3.2 DIAGRAMA DE CASOS DE USO.......................................................................35
3.3 MODELAGEM DE BANCO DE DADOS.............................................................37
3.3.1 Normalização de Dados.................................................................................37
3.3.2 Diagrama Conceitual......................................................................................39
3.3.3 Diagrama Lógico............................................................................................39
3.4 DIAGRAMA DE CLASSES..................................................................................42
3.5 TELAS DO SISTEMA..........................................................................................44
3.5.1 Protótipos de telas.........................................................................................44
3.5.2 Telas Do Sistema............................................................................................47
3.6 IMPLEMENTAÇÃO..............................................................................................53
3.6.1 Base de Dados................................................................................................55
3.6.2 Codificação do Software...............................................................................57
3.7 TESTES DO PRODUTO.....................................................................................61
3.7.1 Teste Unitário..................................................................................................61
3.7.2 Testes Do Cliente............................................................................................63
3.8 IMPLANTAÇÃO...................................................................................................63
4 CONSIDERAÇÕES FINAIS...................................................................................65

REFERÊNCIAS...........................................................................................................67
ANEXO A – DIAGRAMA CONCEITUAL....................................................................69

11
1 INTRODUÇÃO
Entre as diversas informações mantidas pelas instituições de ensino, destaca-
se o acompanhamento de egressos que possibilita avaliar a qualificação dos alunos
após sua formação. Estas são de vital importância, pois manter dados do formando
é uma excelente forma de avaliar a qualidade do curso oferecido, além de
proporcionar novas oportunidades aos que fizeram parte da história da instituição.
O Instituto Federal de Educação Ciência e Tecnologia do Rio Grande do Sul –
Câmpus Bento Gonçalves (IFRS-BG) é uma instituição federal de ensino público
que está localizada na área central do Município de Bento Gonçalves. Esta entidade
é voltada à educação profissional e zela pela qualidade do ensino (INSTITUTO
FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO SUL –
CÂMPUS BENTO GONÇALVES, 2013, p.1).
A instituição tem realizado o acompanhamento de seus egressos a partir de
dados levantados por meio de ligações e e-mails, repassando os dados a planilhas
eletrônicas que permitem, posteriormente, a manipulação e análise das informações.
Todo o trabalho é realizado por uma servidora da instituição que é responsável,
também, por repassar os referidos dados para a comunidade escolar. Porém, a
centralização destas informações, e a utilização de ferramentas inapropriadas para o
compartilhamento, tem restringido o acesso das mesmas.
Diante disso, em busca de melhorar a divulgação destas informações e de
otimizar o trabalho dos servidores envolvidos, solicitou-se a criação de um software
que fosse disponibilizado na internet. Neste sentido, deu-se a abertura ao projeto de
extensão denominado “Portal de Acompanhamento de Egressos do IFRS-BG”, que
propõe a construção de uma ferramenta computacional capaz de armazenar dados
relativos aos egressos e que permite, também, extrair informações, de forma ágil, a
fim de auxiliar na autoavaliação institucional.
Para o desenvolvimento desse Portal foi elaborado um projeto de extensão,
Edital nº 018/2013 complementar ao Edital PROEX/IFRS nº 12/2013, sob

12
coordenação da técnica administrativa Laura Zandonai Brancher e orientação da
professora Lissandra Luvizão Lazzarotto. Além disso, o projeto conta com dois
alunos bolsistas, Alessandra Daniela Buffon e Cassiano Da Silva Carraro,
responsáveis por construir o software com base nas informações referentes ao
acompanhamento de egressos. Portanto, este relatório tem como objetivo
apresentar as etapas do desenvolvimento do referido software, que foi construído
durante o estágio curricular supervisionado, sendo realizado no período de
01/05/2013 a 31/12/2013.
O desenvolvimento das atividades deu-se, principalmente, no Núcleo de
Apoio às Pessoas com Necessidades Especiais (NAPNE), departamento do IFRS-
BG relacionado ao desenvolvimento de projetos e tecnologias assistivas. Esse local
fornece um ambiente favorável à realização das tarefas por possibilitar o acesso ao
conhecimento de novas técnicas de desenvolvimento web acessível e por possuir
equipamentos mais adequados para a programação da aplicação.
1.1 METODOLOGIA
O desenvolvimento do projeto contou com uma equipe formada por quatro
membros, sendo: Alessandra Daniela Buffon, encarregada de analisar as
informações obtidas através dos relatórios do Portal do Egresso e divulgar as
mesmas para as pessoas ou setores interessados; Cassiano Da Silva Carraro,
bolsista, responsável por construir o software; Laura Zandonai Brancher,
responsável pelo acompanhamento dos egressos na instituição e usuária do sistema
e Lissandra Luvizão Lazzarotto, responsável por gerenciar o projeto.
O projeto foi dividido em oito etapas: estudos e levantamento de requisitos,
análise e projeto dos requisitos levantados, construção de protótipos de telas,
avaliação dos protótipos, implementação, testes do produto, implantação em um
servidor e alimentação de banco de dados. Esta também foi a sequência seguida
pela equipe no desenvolvimento, de modo que uma etapa complementou a outra. A
equipe realizava reuniões semanalmente para verificar o andamento do projeto,
avaliando os resultados obtidos e determinando os objetivos para a semana
seguinte.

13
Primeiramente, foram estudadas técnicas de usabilidade e acessibilidade
junto às tecnologias que facilitam o acesso ao conteúdo de sites a todos os usuários,
mesmo aqueles que possuem necessidades especiais. Estas atividades contaram
com o auxílio de bolsistas do NAPNE que forneceram materiais e sanaram as
dúvidas, sobre este tema, que surgiram ao longo do desenvolvimento.
A segunda etapa do projeto consistiu do estudo e levantamento de requisitos.
Para isso, pesquisou-se elementos que compõem portais de outras instituições
existentes atualmente na Web. O objetivo foi filtrar o que havia de melhor em cada
portal pesquisado, obtendo-se, ao final da pesquisa, uma modelagem mais completa
e concreta. As informações levantadas nessa etapa foram documentadas conforme
propõe a engenharia de software.
Os requisitos foram analisados e modelados por meio de uma linguagem
padrão, mais especificadamente a Unified Modeling Language1
(UML), que
possibilitou uma melhor orientação da fase de implementação do produto. Além
disso, durante esta fase, foi construído o projeto de banco de dados e o
levantamento de tecnologias a serem utilizadas na programação da aplicação.
Posteriormente, iniciou-se o desenvolvimento dos protótipos de telas que foram
avaliados pelos integrantes responsáveis pelo acompanhamento de egressos.
Com a aprovação dos protótipos das telas e das ideias gerais do projeto, deu-
se início à programação da aplicação que teve por objetivo concretizar as
informações geradas nas etapas de análise. O produto gerado nesta fase foi testado
pelos integrantes do projeto, sendo aprovado e passando então para a etapa da
hospedagem em um servidor.
1.2 CRONOGRAMA
As atividades realizadas durante o estágio curricular para a construção do
Portal de Acompanhamento de Egressos do IFRS – Câmpus Bento Gonçalves são
apresentadas na Tabela 1. Esse cronograma contempla as oito etapas citadas
1 A linguagem UML é o grupo de gerenciamento de objetos mais utilizada, é o caminho para
representar os modelos de objetos reais e não apenas as estruturas das aplicações, mas também
os processos de negócios e estrutura de dados (UML, 2013, p.1).

14
anteriormente, além da elaboração do relatório de estágio e dos estudos extras
sobre acessibilidade na web. Portanto, esta seção descreve brevemente essas
atividades e o período em que elas ocorreram.
Tabela 1: Cronograma de atividades do estágio
ATIVIDADES Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro
Estudo de
desenvolvimento
de sites acessíveis
X X - - - - - -
Levantamento de
requisitos
X X X X X X - -
Análise e projeto
dos requisitos
levantados
- X X X X X - -
Construção dos
protótipos de telas
X X - - - - - -
Avaliação dos
protótipos de telas
X X - - - - - -
Implementação do
software.
- X X X X X X X
Alimentação de
banco de dados
- - X X X - - -
Testes do produto. - X X X X X X X
Implantação do
Portal em um
servidor
- - - - - - - X
Relatório - X X X X X X X
O estudo de recursos e padrões de desenvolvimento de software acessível
tiveram início em 02/05/2013 e foram finalizados no dia 06/06/2013. Nesse momento
adquiriu-se conhecimento dos padrões e tecnologias utilizadas para o
desenvolvimento do produto, além de definir as principais funcionalidades do
sistema. Neste mesmo momento foram realizadas as atividades práticas de
acessibilidade junto aos bolsistas do NAPNE que forneceram materiais e atividades
para a prática de técnicas específicas e auxiliaram no decorrer da implementação
sanando dúvidas sobre este assunto.
A etapa de elaboração dos requisitos se estendeu durante maio a outubro,
isso se deve ao fato do projeto ser desenvolvido utilizando-se do processo de
desenvolvimento de software incremental. Desta forma, conforme as partes

15
funcionais do sistema eram entregues ao cliente, surgiam novas ideias de
implementação e melhorias, o que fazia com que a equipe iniciasse um novo
levantamento de requisitos para os itens solicitados.
Após a aprovação do levantamento de requisitos primordiais, iniciou-se a
construção dos protótipos de telas, desenvolvidos na data de 10/05/2013 a
23/05/2013. Com sua finalização, analisou-se, junto aos integrantes da equipe, a
integridade das telas e se estavam de acordo com o propósito do produto. No
entanto, surgiram sugestões de alterações que se sucederam no período de
24/05/2013 a 06/06/2013.
Com os protótipos de telas prontos, foi possível dar continuidade ao
desenvolvimento da documentação relacionada à análise e projeto do software.
Primeiramente, foi criado o diagrama conceitual de banco de dados, considerado a
parte central do sistema e que poderia apresentar maiores riscos de erros. Com a
finalização e aprovação do modelo conceitual, deu-se continuidade a criação dos
outros documentos de análise, como o diagrama de Entidade e Relacionamento
(ER) e o diagrama de casos de uso que foram finalizados antes do tempo esperado
possibilitando o início da fase de implementação do software. Estes processos foram
desenvolvidos no período de 07/06/2013 a 20/07/2013.
Sendo aprovados os documentos gerados na fase anterior, iniciou-se a
implementação do produto. No primeiro momento, foi desenvolvida a estrutura do
layout do portal, tendo como base os protótipos de telas. Após, implementou-se o
sistema de login para a área administrativa. Estes foram os passos iniciais da
implementação do software que tiveram início no dia 21/06/2013 e foram finalizados
27/06/2013.
Enquanto trabalhava-se na parte inicial da construção do ambiente
administrativo a bolsista Alessandra procurou junto a servidores do IFRS-BG,
relacionados ao acompanhamento de egressos, atualizar e padronizar as
informações contidas nas planilhas. Suas estruturas foram transformadas com base
no diagrama ER para que fosse possível a inclusão automática dos dados por meio
de um script. Estas atividades foram desenvolvidas no período de 27/06/2013 a
11/07/2013.
No período de 11/07/2013 a 28/08/2013, continuou-se a implementação da

16
aplicação. Neste momento foi desenvolvida toda a parte de buscas, inserção,
alteração e visualização de informações dos egressos junto com o layout da área
administrativa. No entanto, a descoberta de inconsistências de dados advindas da
planilha eletrônica repassada, exigiu uma correção imediata que foi solucionada
neste mesmo espaço de tempo, o que explica o longo tempo tomado para a
conclusão destas tarefas.
No mês de setembro, o enfoque da implementação foram os gráficos, porém
não houve tanta dificuldade quanto imaginado. Isso permitiu que várias outras
funcionalidades fossem implementadas neste período, como o cadastro de egressos
no portal, junto ao seu ambiente restrito, configuração de conta do administrador e
implementação da estrutura de dados para armazenar notícias e oportunidades de
empregos.
Em outubro, o enfoque foi a continuação do cadastro de notícias,
oportunidades de emprego e ajustes no layout, principalmente na parte do portal.
Destas etapas, somente o layout não havia sido finalizado, pois algumas questões
de divulgação de informações estavam pendentes. Além do desenvolvimento do
projeto, este período, também abrangeu as etapas de elaboração das
apresentações para os eventos: IX Mostra Técnica, promovido pelo IFRS-BG e 1º
Seminário de Extensão (SEMEX), promovido pelo IFRS.
Portanto, em novembro foi possível fazer a implementação do cadastro de
usuários administrativos e incremento das funcionalidades do software, como por
exemplo, a expansão da variedade de relatórios gerados na área administrativa e a
restruturação da base de dados para agregar dados referentes às cotas. Além disso,
neste período, o produto foi apresentado a comunidade escolar e externa por meio
dos eventos Mostra Técnica e SEMEX.

17
2 FUNDAMENTAÇÃO TEÓRICA
A construção de um software de qualidade é resultado da utilização de
processo, método e ferramentas, conforme propõem a engenharia de software.
Nesse sentido, essa seção apresenta os conceitos das tecnologias aplicadas em
todo o desenvolvimento do Portal de Acompanhamento de Egresso, fundamentados
nas leituras especializadas na área.
2.1 EGRESSO COMO FONTE INFORMAÇÃO
O termo “egresso” pode ser empregado em várias ocasiões, mas é importante
apresentá-lo em seu significado dentro do âmbito educacional. De acordo com a
legislação da área educacional, Lei nº 9394 Seção I art. 22, o egresso é toda pessoa
que efetivamente concluiu os estudos, recebeu o seu diploma e está apto a
ingressar no mercado de trabalho e exercer sua cidadania (BRASIL, 1996).
O aluno egresso é um elemento importante para uma instituição de ensino,
pois, por meio deste, é possível avaliar se os cursos e métodos de ensino oferecidos
pela instituição estão sendo efetivos para a formação educacional e profissional do
indivíduo. Como apresenta o SAIE (Sistema de Acompanhamento Institucional de
Egressos),
[…] a instituição deve preocupar-se em saber a forma que os técnicos e
tecnólogos estão trabalhando, se estão com dificuldades no desempenho
profissional e se obtiveram melhorias profissionais e pessoais. As respostas
a estas indagações permitem perceber se o ensino oferecido contribuiu para
integrar o egresso como cidadão e profissional aos setores em que atua e
às necessidades do mercado (SAIE, 2013, p.1).
A internet é um meio que facilita a comunicação entre egresso e instituição,
auxiliando na coleta de dados. Estes, posteriormente, podem ser trabalhados e
manipulados para a construção de relatórios que representem a eficácia do ensino
oferecido pelo IFRS – BG.

18
2.2 ACESSIBILIDADE NA WEB
A acessibilidade para o projeto é um elemento importante, pois permite que
toda a comunidade externa e escolar tenha acesso homogêneo as informações e
funcionalidades que a aplicação oferece. Portanto, há uma legislação que norteia o
processo de acessibilidade conforme o decreto
[…] n° 6949, de 25 de agosto de 2009, que promulga a Convenção
Internacional sobre os Direitos das Pessoas com Deficiência elaborada
pelas Nações Unidas em 30 de março de 2007, definindo, em seu artigo 9°,
a obrigatoriedade de promoção do acesso de pessoas com deficiência a
novos sistemas e tecnologias da informação e comunicação, inclusive à
Internet (E-MAG, 2011, p.7).
De acordo com Cifuentes (2000 apud SONZA, 2008, p.120), Caplan (2002,
ibidem) e Dias (2003, ibidem), entende-se por acessibilidade à rede a possibilidade
de todos indivíduos, utilizando qualquer tipo de tecnologia de navegação
(navegadores gráficos, textuais, especiais para cegos ou para sistemas de
computação móvel), poder acessar o site e obter um total e completo entendimento
da informação contida nele, além de ter completa habilidade de interação.
Como consta no site da reitoria do IFRS – BG, o acesso à informação desta
instituição é regida pela Lei 12.527/2011 de acesso a informação, que estabelece
aos órgão e entidades públicas a divulgação de interesse coletivo de forma
homogênea e transparente (IFRS, 2013, p.1).
2.2.1 VANTAGENS DE UM SITE ACESSÍVEL
Segundo Lael Nervis (TcheLinux, 2012), um dos principais motivos de tornar
web sites acessíveis é que 23,9% da população brasileira possui algum tipo de
deficiência auditiva, motora, visual, entre outras. Essa porcentagem equivale a
aproximadamente 45 milhões de pessoas (2012, ibidem).
Outro motivo interessante é a evolução da web que está passando a exercer
um papel crescente e importante na área de educação, negócios, comércio,
governos e recreação. Então, torna-se fundamental a acessibilidade na rede para

19
proporcionar oportunidades iguais de acesso as diversas áreas e permitir a
participação de todos.
2.2.2 MITOS SOBRE ACESSIBILIDADE WEB
Há muitos mitos que envolvem o assunto, fazendo com que alguns
desenvolvedores deixem este requisito de lado por alguns motivos como (SONZA,
2008, p.120):
• Acessibilidade é somente para deficientes visuais.
• O número de usuários beneficiados com a acessibilidade é
relativamente pequeno.
• O melhor a se fazer é desenvolver dois sites, um acessível e outro
“normal”.
• Sites acessíveis demandam um tempo maior para serem
desenvolvidos e o custo será mais elevado.
• O desenvolvedor sabe o que é melhor para o usuário.
Com o desenrolar do projeto, ficou comprovado que estes fatos não condizem
com a realidade. Desenvolver um site acessível não só trará benefícios para quem
está utilizando-o, mas também para quem está desenvolvendo.
2.2.3 PADRÕES E-MAG E WCGA
A acessibilidade do site segue os padrões do Modelo de Acessibilidade de
Governo Eletrônico (E-MAG) e o Web Content Accessibility Guidelines (WCGA),
versão 2.0. Estes são alguns dos modelos mais seguidos no desenvolvimento de
páginas acessíveis.
O primeiro refere-se em normas a serem seguidas na construção de sites e
portais do governo brasileiro, isto serve para padronizar e facilitar a implementação.
Como o projeto é referente a um software para uma instituição federal, fez-se
necessária a utilização deste, pois é coerente com as necessidades brasileiras e

20
está em conformidade com os padrões internacionais.
Já as normas WCGA são elaboradas pelo World Wide Web Consortium
(W3C) e possuem como objetivo principal fornecer uma vasta gama de
recomendações para tornar o conteúdo web mais acessível. De acordo com o
documento online oficial do WCGA 2.0 (W3C, 2008, p.1), estas abrangem uma
grande quantidade de pessoas com deficiências, incluindo cegos, pessoas com
baixa visão, surdos, pessoas com baixa audição, com problemas de aprendizagem,
limitações cognitivas, limitações de movimentos, pessoas com sensibilidade a certas
cores e inclusive pessoas que possuam uma combinação de necessidades
especiais.
2.2.4 VALIDADORES DE PADRÕES E DIRETRIZES
Os validadores de padrões acessíveis auxiliam o desenvolvedor a descobrir
falhas de sintaxe no código que prejudiquem a usabilidade, indicando o local do erro
e, se possível, apresentando uma solução. Alguns validadores, como o site DaSilva,
também contam com mecanismos de avaliação da acessibilidade do conteúdo. Para
isso, o DaSilva organiza a execução de sua validação em três passos de modo que
cada um foque em prioridades distintas.
Conforme o site DaSilva, as prioridades são pontos que os criadores de
conteúdo web devem satisfazer inteiramente. Se não o fizerem, um ou mais grupos
de usuários ficarão impossibilitados de acessar informações contidas nos
documentos.
A primeira prioridade determina requisitos básicos para que vários grupos de
pessoas possam acessar documentos online. Como exemplos de pontos de
verificações desta, cita-se as páginas que possuem movimento proporcionam meios
para o usuário controlar esta animação e se as cores utilizadas no layout da
aplicação são favoráveis à leitura do conteúdo, mesmo sendo executado em
monitores monocromáticos.
Na segunda prioridade, o enfoque é a remoção de barreiras significativas ao
acesso de documentos digitais. Alguns pontos desta etapa, avaliam se houve o uso

21
correto de elementos de formulários, por exemplo, o uso do elemento label2
acompanhado do ID para indicar rótulos dos respectivos controles de formulários, se
a ordem da disposição de opções do menu é relativa em todas as páginas e se há a
existência de um mapa do site.
Já na terceira, procura-se diminuir as dificuldades de acesso às informações,
melhorando alguns aspectos que não são verificados na etapa anterior. Como
exemplo, tem-se a validação da identificação clara do destino de cada link, botão ou
elemento que submeta uma ação e se há a agregação de informações semânticas e
descritivas importantes do software por meio de metadados.
2.3 PROCEDIMENTOS METODOLÓGICOS
De acordo com Pressman (2011) a construção de um software envolve a
aplicação de um processo que leva a um resultado de alta qualidade e que satisfaça
às necessidades das pessoas que utilizarão esse produto.
Sommerville (2011) define Processo de Software como um conjunto de
atividades realizadas numa sequência lógica, com o objetivo de desenvolver um
produto de qualidade (SOMMERVILLE, 2011). O autor destaca que há quatro
atividades fundamentais que são comuns a todos os processos de software, são
elas: especificação, desenvolvimento, validação e evolução.
Diante disso, as seções seguintes abordam os conceitos relativos aos
processos e as atividades fundamentais utilizadas na construção do Portal de
Acompanhamento de Egressos.
2 A tag HTML label define um rótulo para um campo de formulário. Utilizar este elemento não trará
nada de diferenciado no visual, mas, por outro lado, trará uma melhoria de usabilidade, pois se o
usuário clicar no texto que é formado pelo elemento label, ele imediatamente terá o controle do
campo.

22
2.3.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Para o desenvolvimento de software é indicado adotar um modelo de
processo de desenvolvimento de software. Segundo Pressman (2011), um modelo
de processo de software fornece estabilidade, controle e organização a uma
atividade que, sem controle, pode-se tornar caótica. Portanto, um processo
controlado direciona a equipe a uma sequência de ações planejadas em busca de
um produto de qualidade, ou seja, que atenda as necessidades do cliente.
De acordo com Pressman (2011), não existe um processo ideal, várias
empresas desenvolveram abordagens inteiramente diferentes para o
desenvolvimento de software. Com base nisso, para este projeto, foi adotado um
modelo híbrido de processo, baseado nas características dos modelos cascata,
incremental e a participação ativa do cliente durante todo o processo.
Portanto, durante a construção desta aplicação foram disponibilizados para o
cliente conjuntos funcionais do sistema para que fossem utilizados no decorrer da
implementação, fazendo com que surgisse sugestões para o acréscimo de
funcionalidades. Desta forma, por meio de um processo linear ocorreu o
desenvolvimento de cada incremento, contando sempre com a participação do
cliente para que os requisitos se mantivessem bem definidos, como sugere o modelo
cascata.
Desta forma, este modelo adotado, foi imprescindível para o desenvolvimento
do produto, pois permitiu uma sequencia linear na construção dos incrementos, junto
a dinamicidade fornecida pelo modelo incremental. Este permite que o cliente
participe ativamente do desenvolvimento, facilitando ao analista na modelagem dos
novos requisitos. Além disso, assegura-se que o produto final atenda as
necessidades do cliente.
Portanto, no modelo incremental (Figura 1), tem-se a mudança como um
ponto inevitável, neste projeto, os requisitos foram incrementados de modo que a
cada semana eram fornecidos, ao cliente, versões operacionais do sistema.
Conforme Pressman (2011, p.61), este modelo permite o fornecimento parcial de
funcionalidades do sistema para que depois sejam refinadas e expandidas, isso
ocorre com a aplicação de sequências lineares, porém de forma escalonada.

23
Por outro lado, o modelo cascata sugere a construção do software no modo
chamado ciclo de vida linear ou clássico. Este tem como base o levantamento dos
requisitos, avançando pelas fases de planejamento, modelagem, implementação,
implantação e atualização contínua (PRESSMAN, Roger S., 2011, p.59). Esta
estrutura foi seguida internamente durante o desenvolvimento dos incrementos de
modo que para cada se segue uma sequência sistemática contando com a
aprovação do cliente. A Figura 2 representa como funciona este modelo.
Figura 1: Estrutura do modelo incremental
Fonte: Roger S. Pressman, 2011.
Figura 2: Estrutura do modelo cascata

24
2.3.1.1 LEVANTAMENTO DE REQUISITOS
A elicitação dos requisitos permite a equipe de desenvolvedores e o cliente
discutirem e avaliarem os problemas que o software deverá solucionar. Para isso,
como sugere Pressman (2011, p.133), pode ser adotada uma abordagem
colaborativa pela equipe de modo que os interessados trabalhem juntos para
identificar e propor elementos para a solução dos problemas, sendo possível sua
realização por meio de reuniões periódicas entre os envolvidos.
Esta foi a metodologia seguida pela equipe, de modo que eram realizadas
reuniões semanais com todos os membros, para ser discutido sobre os problemas
resolvidos e aqueles que deveriam ser trabalhados na semana seguinte. Com isto,
foi possível elaborar um checklist de requisitos implementados e os que deveriam
ser programados, tudo sempre passando pela gerente de projeto, professora
Lissandra.
2.3.1.2 ANÁLISE E PROJETO
Os requisitos básicos do sistema tornam possível sua modelagem, pois, de
acordo com Pressman (2011, p.151), os resultados do levantamento de requisitos
resultam na especificação das características do sistema que indicam vários
elementos do software. Então, a partir disso, é possível usar a modelagem de
sistemas para dar aos projetistas informações que posteriormente serão
transformadas em componentes da aplicação e ao cliente para fornecer um meio de
verificar a qualidade do produto que será construído. Pode-se observar, na Figura 3,
a importância da modelagem dos requisitos que atua como uma ponte entre a
descrição do sistema e o modelo de projeto.

25
Já no âmbito do modelo de projeto, tem-se como resultado documentos que
serão utilizados pelos desenvolvedores, como, por exemplo, os diagramas de
classes, diagramas de casos de uso, diagramas de atividades, diagrama de entidade
e relacionamento, entre outros. Mas alguns podem ser apresentados e discutidos
com o cliente, como é o caso dos modelos conceituais ou de casos de uso, estes
são de fácil entendimento e não exigem conhecimento técnico para serem
compreendidos.
Para desenvolver toda esta documentação, existe a linguagem de modelagem
universal, a UML. Conforme Pressman (2011, p.727), esta oferece meios para a
especificação, visualização, construção e documentação dos componentes de uma
aplicação. Além disso, ela pode ser utilizada com diferentes tecnologias de
implementação.
2.4 FERRAMENTAS DE PROGRAMAÇÃO
Esta seção abrange as ferramentas e linguagens de programação utilizadas
no desenvolvimento do sistema. Todas as linguagens fazem referência a
programação web conforme descrito nos requisitos da aplicação.
Figura 3: Importância da modelagem de requisitos

26
2.4.1 LINGUAGENS WEB
Por este projeto ser um sistema online destinado a usuários externos quanto
internos, fez-se uso das principais linguagens web disponíveis atualmente. Estas
permitem a estruturação de conteúdo, interação do sistema com o usuário e
manipulação de informações pelo servidor hospedeiro.
Para a construção das páginas, utilizou-se as linguagens Hypertext Markup
Language (HTML) e Cascading Style Sheets (CSS). De acordo com a W3C (2013,
p.1), estas duas linguagens se completam e são a base da construção de aplicações
web de modo que o HTML fornece a estrutura da página e o CSS a apresentação.
Porém, estas duas linguagens não são suficientes para trazer uma
experiência de uso adequada para o usuário, então tem-se a linguagem Javascript.
Conforme o que diz a documentação W3C (2013, p.1), esta linguagem torna as
páginas mais dinâmicas e interativas, pois permite que funções do sistema sejam
disparados em um evento do usuário ou então execute atividades assíncronas, sem
que seja necessário recarregar as páginas.
2.4.2 ZEND FRAMEWORK 2
O Zend Framework 2 (ZF2) é um framework4
de código aberto que é utilizado
no desenvolvimento de aplicações e serviços web que faz o uso da versão 5.3 ou
superior do PHP (Hypertext Preprocessor). Esta é uma ferramenta totalmente
orientada a objetos, aproveitando-se das mais novas funções do PHP 5.3 (ZEND
TECHNOLOGIES LTD., 2013, p.1, tradução nossa).
Para o portal, foi interessante a utilização deste framework, pois, com ele, é
possível estruturar melhor o código do projeto, podendo trabalhar com métodos de
modularização que ajudam na programação e manutenção do sistema. Além da
estrutura do código, outro ponto interessante são funções auxiliares que permitem
agilizar o desenvolvimento e também fornecer mais segurança e consistência à
aplicação.
4 Framework é uma técnica orientada a objetos de reúso. Esta técnica fornece componentes que
podem facilmente ser conectados para fazer um novo sistema. O desenvolvedor deste sistema
não precisa saber como o componente é implementado facilitando a implementação destes
(RALPH, Johnson E., 1997, p.39, tradução nossa).

27
A estruturação de componentes do Zend Framework 2 é única, cada
componente é projetado com poucas dependências de outros. Este segue o
princípio sólido de projetos orientados a objetos. Essa arquitetura flexível permite ao
desenvolvedor utilizar qualquer componente que desejar, chamado, de acordo com a
documentação Zend, projetos de “use à vontade”.
Além disso, o framework também fornece integração de módulos para testes
unitários que no caso é utilizado o PHPUnit. De acordo com Sebastian Bergmann
(2013, p.4), o PHPUnit assume que a maioria dos testes passam e não vale a pena
informar os detalhes dos testes bem-sucedidos, mas sim informar a quantidade de
testes realizados. Já no caso de testes falhos é interessante detalhá-los e relatá-los
ao desenvolvedor, sendo este o principal objetivo do PHPUnit.
2.4.3 DOCTRINE 2
Esta ferramenta, unida ao Zend Framework 2, proporciona um controle maior
da aplicação, pois pode-se utilizar o Zend somente para as partes funcionais do
sistema e o Doctrine para cuidar do mapeamento e criação das entidades que
formam o banco de dados. Isso só é possível pelo fato de que as duas ferramentas
são compatíveis, assim, proporcionando maior facilidade na programação e na
manutenção do sistema. A definição desta ferramenta de acordo com a
documentação é a seguinte,
Doctrine 2 é um mapeador de entidades e relacionamentos que
utiliza as funções da versão do PHP 5.3 ou superior, fornecendo
persistência transparente de objetos do PHP. Este usa o padrão Data
Mapper em seu núcleo, visando uma completa separação da lógica de
domínio/negócios da parte do sistema que cuida do gerenciamento de
banco de dados relacional (DOCTRINE PROJECT TEAM, 2013, p.17,
tradução nossa).
Na Figura 4, encontra-se o esquema dos módulos deste framework, pode-se
observar que estão dispostos em três camadas, tendo na primeira camada a
centralização das funcionalidades no “doctrine/common” que é responsável por
todas as funcionalidades básicas. Na segunda, encontram-se os módulos utilizados
para fornecer a conexão com o banco de dados, somado a suas principais

28
funcionalidades, como exemplo, o mapeamento de entidades e paginação de
resultados de buscas. Por último, se localizam as camadas que fornecerão o tipo de
conexão com o a base de dados, podendo ser uma conexão SQL (Structured Query
Language) correspondente ao “doctrine/doctrine-orm-module” ou MongoDB que é
uma conexão não SQL, podendo ser utilizada por meio do “doctrine-mongo-odm-
module” (DOCTRINE PROJECT TEAM, 2013).
Desta forma, a disposição dos módulos acaba por fornecer ao desenvolvedor
maior praticidade, pois todas as funcionalidades utilizadas serão funcionas tanto
com conexão SQL quanto com conexão não SQL, bastando apenas trocar o módulo
que faz a ligação entre o banco e a aplicação. Além disso, a estrutura favorece a
utilização de todas as funcionalidades oferecidas pelo framework integradas ao
Zend.
Figura 4: Esquema de módulos do Doctrine 2
Fonte: Marco Pivetta, 2013.

29
2.4.4 GERENCIADOR DE DEPENDÊNCIAS
A função deste tipo de ferramenta é simples, gerenciar as bibliotecas
essenciais, utilizadas no desenvolvimento de uma aplicação, facilitando a
organização e atualização destas. O trabalho em questão utilizou o Composer, um
gerenciador de dependências PHP que permite a instalação de bibliotecas no
projeto, por meio da declaração em um arquivo JavaScript Object Notation (JSON)
(COMPOSER, 2013, p.9), como na Figura 5.
Figura 5: Declaração básica de dependência
Fonte: Composer, 2013.

30
3 O PORTAL DE ACOMPANHAMENTO DE EGRESSOS DO IFRS –
BG
Nesta seção são apresentados os resultados em cada etapa do processo de
desenvolvimento do Portal de Acompanhamento de Egressos para o IFRS – BG,
incluindo o levantamento e especificação dos requisitos, a modelagem,
implementação, testes e implantação do produto. Para isso, seguiu-se as premissas
abordadas na metodologia, de modo a se obter um produto que atenda às
necessidades do cliente.
3.1 LEVANTAMENTO E ESPECIFICAÇÃO DOS REQUISITOS
Este processo foi realizado junto a equipe, de modo que os requisitos básicos
do sistema foram descritos com base no problema o qual o software deve resolver.
Portanto, além de métodos que melhoram a divulgação das informações e otimizam
o trabalho de servidores envolvidos, para tornar este software mais completo,
procurou-se junto a portais de outras instituições, funcionalidades interessantes que
pudessem ser implementadas e melhoradas adequando-as as exigências do cliente.
Alguns exemplos são: o portal da Universidade do Vale do Itajaí (UNIVALI),
Figura 6, e Universidade Federal de Santa Catarina (UFSC), Figura 7. Na primeira,
a ideia de desenvolvimento de meios para divulgação de oportunidade profissionais
foi aproveitada, pois este é um atrativo para os egressos que desejam uma vaga no
mercado de trabalho. Já no portal da UFSC, achou-se interessante a criação de um
canal de comunicação e de apresentação dos egressos destaques.

31
Figura 6: Portal de egressos UNIVALI
Figura 7: Portal de egressos UFSC

32
Para demonstrar o modo como o sistema vai se comportar, os próximos
tópicos apresentarão respectivamente os requisitos funcionais, não funcionais e as
regras de negócio. Estas informações são interessantes para delimitar quais as
especificidades e necessidades desta aplicação.
3.1.1 REQUISITOS FUNCIONAIS
Os requisitos funcionais se referem as funcionalidades que devem estar
contempladas no software, informando os detalhes técnicos da aplicação além de
fornecer meios para a modelagem do sistema e sua implementação. Os principais
requisitos funcionais (RF) são:
Tabela 2: Requisitos funcionais
Requisito Funcional Descrição
RF 01 O software deve mostrar em sua página inicial o egresso
destaque.
RF 02 O software deve possuir um banco de talentos.
RF 03 O software deve permitir divulgar notícias.
RF 04 O software deve permitir divulgar oportunidades de
empregos.
RF 05 O software deve permitir divulgar os relatórios das
informações de acompanhamento de egressos.
RF 06 O software deve permitir divulgar as opiniões do egresso
sobre a qualidade de seu curso no Câmpus.
RF 07 O software deve fornecer uma área restrita para o egresso.
RF 08 O software deve permitir o cadastro de conta de egresso.
RF 09 O software deve possuir um sistema de busca de conteúdo
do portal.
RF 10 O software deve permitir a atualização de informações do
egresso.

33
Requisito Funcional Descrição
RF 11 O software deve possuir um mecanismo de recuperação de
senhas para o egresso.
RF 12 O software deve possuir uma área restrita para o
administrador.
RF 13 O software deve permitir manter o cadastro egressos.
RF 14 O software deve possuir um sistema de busca avançada de
egressos, na área administrativa.
RF 15 O software deve permitir a manutenção de informações
contidas no portal.
RF 16 O software deve gerar relatórios e gráficos.
RF 17 O software deve permitir o cadastro de novos
administradores.
3.1.2 REQUISITOS NÃO FUNCIONAIS
Enquanto os requisitos funcionais definiram as características, os requisitos
não funcionais (RNF), permitiram caracterizar as qualidades que o software teria que
possuir confirme suas funcionalidades. Neste projeto foram levantados os seguintes
requisitos não funcionais:
Tabela 3: Requisitos não funcionais
Requisito Não Funcional Descrição
RNF 01 O software deve ser desenvolvido no padrão MVC.
RNF 02 O software deve permitir acesso dos usuários por meio
de login e senha.
RNF 03 O software deve utilizar PHP 5.3.3 ou superior.
RNF 04 O software deve ficar disponível 24 horas.
RNF 05 O software deve ser desenvolvido utilizando HTML 4 ou
superior, CSS3 e JS 1.8 ou superior.

34
Requisito Não Funcional Descrição
RNF 06 O software deve funcionar em multiplataforma.
RNF 07 O software deve possuir um layout acessível e de fácil
uso.
RNF 08 O software deve possuir um layout responsivo.
RNF 09 O software deve fornecer segurança e confiabilidade
nas informações manipuladas.
RNF 09 O software deve ser seguro e consistente, possuindo
criptografia Blowfish com salt nas senhas dos usuários.
RNF 10 O software deve ser desenvolvido seguindo os padrões
de acessibilidade EMAG e WCGA 2.0.
3.1.3 REGRAS DE NEGÓCIO
Com base nos requisitos funcionais do sistema, documentou-se todas as
especificidades e restrições necessárias para o funcionamento completo da
aplicação. O resultado do levantamento das regras de negócio (RN) foi:
Tabela 4: Regras de negócio
Regra de Negócio Descrição
RN 01 A área de notícias será formada por notícias relacionadas a
egressos, procurando-se dar ênfase a notícias que envolvam
os egressos.
RN 02 Para conferir detalhes das oportunidades de emprego o
usuário deverá estar logado como egresso.
RN 03 As opiniões deverão ser avaliadas por um administrador do
sistema, para assegurar que não sejam publicadas
informações indevidas.
Regra de Negócio Descrição
RN 04 A recuperação da senha será feita via e-mail.
RN 05 Os gráficos devem ser gerados em formatos de imagem, para
posterior manipulação.

35
3.2 DIAGRAMA DE CASOS DE USO
A Figura 8 apresenta o diagrama de casos de uso do sistema destacando o
ator administrador. Como se pode observar, suas atividades baseiam-se
basicamente em manter as informações dos egressos, usuários e portal.
Na Figura 9 são mostradas as principais funcionalidades do egresso
permitindo ao mesmo manter suas informações e acessar dados restritos. Entende-
se manter, como o ato de alterar, inserir, permitir e excluir dados.
Figura 8: Casos de uso do ator administrador

36
Os dados restritos que os egressos poderão acessar, nesta versão, serão as
oportunidades de empregos. A ideia é disponibilizar o enunciado da vaga no site
para todos, porém as informações mais específicas, como nome da empresa, meios
de contato e informações especificas, serão visualizadas apenas para egressos.
Outra funcionalidade específica do egresso, será a autorização, não
obrigatória, para publicações de suas informações em mecanismos do sistema. Isto
ocorre no caso da autorização de seu perfil para poder ser “egresso destaque”,
sendo assim sua imagem e informações básicas como nome e curso serão
publicadas na página inicial do portal, caso seja selecionado. Já no caso do banco
de talentos, será disponibilizado apenas dados referentes a especialização do
mesmo. A função do banco de talentos é fornecer um espaço para os egressos
oferecerem seu trabalho para empresas interessadas.
Figura 9: Casos de uso do ator egresso

37
3.3 MODELAGEM DE BANCO DE DADOS
O desenvolvimento dos diagramas exigiram cautela pela equipe, pois a parte
central do sistema é manter os dados dos egressos. Como citado na introdução, a
manipulação destas informações eram feitas por meio de planilhas eletrônicas de
forma totalmente manual, sem o auxilio de mecanismos que verificasse a
consistência dos dados. Isto acabou dificultando a normalização de dados, mas não
impossibilitou esta ação.
3.3.1 NORMALIZAÇÃO DE DADOS
Este processo possibilitou, com base nas planilhas, a criação e organização
de um armazenamento consistente de dados utilizando-se conceitos relacionais
entre tabelas. Os passos seguidos neste foram: análise de dados e metadados das
planilhas, transcrição de dados para a primeira e segunda forma normal.

38
Figura 10: Normalização de dados

39
Portanto, com base na análise dos dados, extraiu-se a tabela não
normalizada para que fosse possível aplicar este processo. Com esta, deu-se inicio
a passagem à primeira forma normal, de modo que os atributos multivalorados foram
retirados, transformando-se em novas tabelas. Na segunda forma normal,
reorganizou-se os atributos dependentes de chave primária, como, os referentes aos
endereços. Para prosseguir a 3º forma normal, as tabelas devem estar na 2º forma
normal e os atributos não chave, não devem possuir dependência transitiva, portanto
considerou-se o processo finalizado na 2º forma normal, pois as exigências foram
cumpridas. Esses processos são mostrados na Figura 10.
3.3.2 DIAGRAMA CONCEITUAL
A base de dados é a parte central do sistema, por este motivo fez-se
necessário a criação do diagrama conceitual da base de dados (Anexo A), para
facilitar na compreensão e permitir a interação com o cliente para o desenvolvimento
deste requisito. Além disto, este modelo serviu de base para a criação do diagrama
lógico que, posteriormente, foi utilizado na implementação.
3.3.3 DIAGRAMA LÓGICO
As tabelas de dados referentes a administração do sistema estão dispostas
conforme a Figura 11. A tabela “admin” é responsável por guardar as informações
das contas de administradores. Desta forma os administradores estarão
relacionados com as tabelas “virou_noticia” e “oportunidade_emprego”, pelo fato de
que o software possuirá vários administradores, tornando interessante a
identificação dos autores de cada conteúdo do portal. Já a tabela “grafico_resultado”
é a que persiste as informações dos gráficos que serão publicados na parte de
resultados do portal, que fica exposto a comunidade externa.

40
O desenvolvimento do diagrama de dados do egresso foi a parte que mais
exigiu da equipe, pois a parte central do sistema é manter os dados do egresso.
Como citado na introdução, a manipulação destas informações eram feitas por meio
de planilhas eletrônicas e de forma totalmente manual, sem a ajuda de mecanismos
que verificasse a consistência dos dados. Isto acabou dificultando a normalização de
dados, mas não impossibilitou esta ação.
A estrutura final de dados do egresso está conforme a Figura 12, para chegar
a este resultado foi necessário a alteração e o estudo de alguns casos específicos
além dos que foram repassados pelas planilhas. Estas informações são suficientes
para atender a demanda atual do cliente, mas já há previsão de inclusão de novas
informações do egresso, como por exemplo, se este teve acesso ao curso pelo
sistema de cotas e qual o tipo.
Figura 11: Diagrama ER do administrador

41
Figura 12: Diagrama ER do egresso

42
3.4 DIAGRAMA DE CLASSES
A diagramação de classes do sistema não foi feita por completa, pois foi
definido pela equipe que não havia necessidade. Porém, para se ter ideia de como
ficaria a parte do cadastro de informações do egresso pelo administrador e como
funcionaria o seu login, foi feito o diagrama representado na Figura 13.
Pode-se observar a comunicação entre os dois módulos do software,
administração e egresso. O “EgressoController” fornece ao administrador todas as
funcionalidades necessárias para a manutenção, inclusão e pesquisa de dados dos
egressos. Pelo outro lado, tem-se o modelo do administrador que é gerenciado pelo
“AdminController” de modo que a ação “contaAction()” fornece os meios para
alteração de suas informações como nome e senha.
O controlador “AuthController” fornece os caminhos para a autenticação no
sistema, sendo processos semelhantes para os dois atores. As funções fornecidas
por esse controlador servem principalmente para fazer a autenticação do usuário no
sistema (authenticateAction); verificar se o mesmo está logado (loginAction);
encerrar sua sessão (logoutAction); manipular o formulário de login (getForm) e
utilizar o serviço de autenticação disponibilizado pelo Doctrine 2 (getAuthService).

43
Figura 13: Diagrama de classes parcial

44
3.5 TELAS DO SISTEMA
Para esta etapa, utilizou-se como base o guia para o uso de layouts do IFRS -
BG que propunha pontos imprescindíveis para a estrutura das páginas que remetem
a instituição. Além disto, seguiu-se também, os padrões de acessibilidade já
descritos anteriormente.
O desenvolvimento das telas do sistema foi dividido em duas etapas: criação
dos protótipos das telas para a avaliação da equipe e a implementação das
mesmas. Portanto, a seção 3.5.1 apresenta os protótipos de telas criados para
serem avaliadas pela equipe e a seção 3.5.2 mostra, as telas do sistema
implementadas.
3.5.1 PROTÓTIPOS DE TELAS
A construção dos protótipos teve como objetivo, identificar uma estrutura
base das páginas definida pelos envolvidos no projeto, diminuindo os riscos de
possíveis alterações drásticas e de incompatibilidade com alguns padrões.
A prototipação das telas foram feitas apenas para as páginas expostas para a
comunidade externa. O motivo disto foi procurar a melhor maneira de disponibilizar
as informações de forma transparente e acessível.
Inicialmente, foi elaborado o mapeamento das possíveis telas do sistema
tendo como resultado a Figura 14. Este, além de permitir uma ampla visualização da
estrutura das páginas, facilitou na criação dos breadcrumbs e mapa do site, que
auxiliam o usuário a se localizar no portal.

45
O primeiro protótipo construído e aprovado pela equipe, foi o da página inicial
do Portal, representado na Figura 15. Ele foi pensado tendo como base alguns
elementos de outros portais, mas sua estrutura é única. Este possui alguns
elementos essenciais que são propostos pelos padrões seguidos, como a barra
obrigatória do Ministério da Educação (MEC) e a barra de acessibilidade.
Figura 15: Protótipo da página inicial
Figura 14: Mapeamento das páginas do site

46
As outras páginas seguiram o mesmo padrão da página inicial, porém
algumas sofreram mudanças quando foram implementadas pelo fato de que se
observou um excesso desnecessário de informações ou requisições, como no caso
da parte de cadastro (Figura 16). Em um primeiro momento, a equipe decidiu que
era obrigatório para o egresso se cadastrar informar vários dados, como seu nome,
data de nascimento, telefone, e-mail, curso e ano de conclusão do curso. Tudo isso
serviria para garantir sua identidade pessoal. Porém, no decorrer do projeto,
observou-se que apenas a informação do CPF e a confirmação de seu e-mail já era
o suficiente.
Figura 16: Protótipo da página cadastre-se

47
3.5.2 TELAS DO SISTEMA
Como a prioridade do sistema era a manutenção de informações do egresso,
foi programado primeiramente as telas correspondentes a parte administrativa da
aplicação. Elas deveriam seguir os requisitos levantados nas etapas iniciais do
projeto, então com estes documentos foi possível dar início a programação das
páginas.
Na Figura 17 está a tela da listagem dos egressos que permite ao
administrador fazer pesquisas avançadas dos egressos cadastrados no sistema e
também visualizar as informações de cada um. Como exemplo na imagem, são
listados os egressos do curso superior de Tecnologia em Logística, na listagem
simplificada são mostrados o nome, a data de nascimento, o CPF e e-mail dos
egressos, estas são as informações mais buscadas sobre os egressos de acordo
com o que diz o cliente.
Figura 17: Área administrativa: Listagem de egressos

48
Ao total são apresentados 25 registros por página e seu carregamento é feito
com a tecnologia Asynchronous Javascript and XML (AJAX), proporcionando ao
administrador mais dinamismo e praticidade, pelo fato de não ser necessário
recarregar a página para fazer as pesquisas nem para utilizar a paginação.
As informações mais específicas se encontram em outra página que pode ser
acessada pelo ícone de informações do egresso. Nesta, serão apresentados todos
os dados e um meio para alterar suas informações.
O formulário para a inclusão de egressos foi estruturado para ser o mais
acessível possível, proporcionando meios para a solução de problemas de
inconsistência de dados, detectados anteriormente com o uso das planilhas. Este
fornece a padronização de dados com o uso de validadores nos campos e funções
de preenchimento automático com base nos dados já cadastrados para evitar a
duplicidade de informações sintaticamente diferentes, porém semanticamente iguais.
Isso é essencial para que não ocorra discordância na construção dos gráficos.
Os gráficos estão estruturados de acordo com a Figura 18, no lado esquerdo
da tela tem-se o menu com os possíveis gráficos a serem gerados, na parte
superior, há um filtro e abaixo o resultado das informações requisitadas. Os dados
podem ser visualizados pela tabela descritiva ou pelo gráfico gerado com o auxílio
da biblioteca de gráficos interativos Hightcharts, que além disso, permite a
exportação para os formatos PNG, JPG, PDF e SVG, facilitando a construção de
relatórios de gestão de egressos do IFRS - BG.

49
Atualmente, são gerados informações das mais diversas áreas que estão
separadas por categorias, como: situação do egresso, tipo de empresas que os
egressos trabalham, local de trabalho, ranking entre outras. Estas podem ser
apresentadas em colunas ou em pizza. As outras funcionalidades da área
administrativa seguem o mesmo padrão de layout das apresentadas, porém com
suas especificidades.
A estrutura das páginas foi pensada seguindo os padrões de acessibilidade
combinado a normas de usabilidade que permitem o portal ser executado nas mais
diversas plataformas e dispositivos. Na Figura 19, é mostrada a tela inicial do portal,
contendo a visualização em um desktop. Por outro lado na Figura 20, é apresentada
a tela visualizada em um tablet, de modo que algumas informações são ocultadas,
como, por exemplo, a barra de destaque no lado direito e o formulário de login do
Figura 18: Área administrativa: Gráficos e Relatórios

50
egresso. Por fim tem-se a visualização em celular (Figura 21), de forma que é
reorganizado o modo de dispor o menu principal e as informações poucos relevantes
não são carregadas, como, por exemplo, o carrossel de imagens e o logo.
Figura 19: Layout do portal em desktops
Figura 20: Layout do portal em tablets

51
O espaço destinado ao egresso permite uma comunicação direta com a
instituição, pois seus dados podem ser atualizados instantaneamente pelo próprio
egresso. Além disso, este fornece ao egresso a possibilidade de expressar suas
ideias sobre a instituição que poderão ser publicadas na parte de “Palavra do
Egresso” no Portal. A Figura 22 mostra a área destinada ao egresso, sempre que o
egresso entrar em sua conta, uma mensagem será exibida para alertar a
importância de manter seus dados atualizados.
Figura 21: Layout do portal em celulares

52
O logo do portal (Figura 23), foi desenvolvido pela professora colaboradora,
Michelle Chagas de Farias. Este possui uma identificação com o egresso, explicada
pela disposição do quadrado vermelho que assemelha-se a uma flecha o que
remete aos alunos que já se formaram na instituição. Já os outros 3 triângulos, junto
às cores utilizadas, identificam a instituição.
Figura 22: Área do egresso
Figura 23: Logo do Portal do Egresso

53
3.6 IMPLEMENTAÇÃO
O sistema foi desenvolvido em um contexto modularizado (Figura 24), de
modo que cada módulo possui sua estrutura Model-view-controller (MVC)
implementada separadamente. Fazem parte do software os seguintes, com suas
respectivas atividades:
• Portal: no módulo do Portal se encontram todas as funcionalidades do
sistema que serão disponibilizados a qualquer visitante. Esta parte
disponibiliza informação para comunidade externa e escolar, além de
divulgar e atrair os egressos para a sua utilização.
• Egresso: este módulo se encarrega de armazenar, gerenciar e
disponibilizar um local para os egressos cadastrados do portal. É neste
que ocorre a troca de informações entre o egresso e a instituição.
• Administração: este é um módulo de uso restrito apenas para
servidores envolvidos na administração e gerenciamento do portal. O
principal objetivo deste é fornecer um meio para a manutenção e
manipulação de informações referentes aos egressos, usuários, portal,
relatórios e gráficos.
Figura 24: Estrutura dos módulos

54
Para começar a implementação, foi necessário utilizar um servidor web, neste
caso, o Apache 2.0, junto com o PhpMyAdmin que fornece um ambiente para fazer o
gerenciamento do banco de dados MySQL, além da própria linguagem PHP versão
5.3, isto no ambiente Linux. Já no ambiente Windows fez-se o uso da ferramenta
Wamp Server que também forneceu todas estas tecnologias.
Após ter configurado os respectivos servidores para receber a aplicação,
buscou-se as tecnologias que seriam utilizadas na programação do software. Como
citado anteriormente, além da biblioteca do Zend, fez-se o uso do Doctrine 2. Todas
estas bibliotecas foram baixadas e configuradas por meio de um gerenciador de
dependências PHP, o Composer. Por meio deste é possível gerenciar os pacotes
necessários, declarando-os no formato de intercâmbio de dados JSON. Com base
nisso, as dependências declaradas no arquivo JSON, como mostra a Figura 25, são:
• PHP 5.3 ou superior: Linguagem utilizada na programação do lado
servidor do software.
• Zend Framework: Refere-se ao framework de programação PHP
utilizado, sendo que para o pleno funcionamento da aplicação deve-se
utilizar a versão 2.2 ou superior.
• Doctrine ORM Module: Módulo referente as bibliotecas utilizadas pelo
Doctrine 2.
• Zend Developer Tools: Ferramenta para desenvolvedores que auxilia
na depuração do código. Este fornece informações relevantes de erros,
aletras, quantidade de bytes carregados, tempo de execução, entre
outras características do software que está sendo executado.

55
3.6.1 BASE DE DADOS
Após terminar a configuração da aplicação no servidor local e declarar suas
dependências, iniciou-se a criação das entidades do sistema que deram origem a
base de dados. Porém, foi necessário a criação de um arquivo, como o da Figura 26,
encarregado de fornecer as informações essenciais para a ligação direta entre
software e banco de dados.
Figura 25: Dependências da aplicação

56
Com a interligação pronta, iniciou-se a criação dos modelos junto ao
mapeamento, como mostra a Figura 27, de modo que toda a descrição dos
mapeamentos estão comentadas acima de suas respectivas variáveis. Isto permite
que o banco de dados possa ser criado a partir deste, sem que haja a necessidade
de instruções SQL para esta tarefa. Além disso, também é possível validar as
tabelas previamente à sua criação com o uso de ferramentas específicas
disponibilizadas pelo Doctrine.
Figura 26: Configuração da conexão com a base de dados

57
3.6.2 CODIFICAÇÃO DO SOFTWARE
Os códigos programados nesta aplicação utilizam-se das linguagens, PHP,
para o lado servidor, Javascript para a interação do sistema com o usuário, SQL
para criação de instruções de consultas no banco de dados, HTML e CSS para
estruturação e estilização das informações. Estas foram utilizadas, pois fornecem
todas as funcionalidades imprescindíveis para a solução do problema.
Figura 27: Código parcial da entidade curso

58
Então, a programação com a linguagem PHP foi feita com o auxílio de um
framework que forneceu uma série de componentes “prontos para uso” que
tornaram o processo mais ágil e consistente. A Figura 28, demonstra como é o
funcionamento de um controlador do sistema, neste caso do administrador.
Primeiramente, todas as classes contidas no interior dos módulos que exercem
alguma função no sistema devem possuir um identificador. Isto é feito com a
utilização do namespace que facilita a identificação dos complementos e
consequentemente, sua utilização é facilitada.
Este controlador estende as funções do controle abstrato de ações do Zend,
que serve para fazer a ligação entre o sistema e ambiente de visualização. Deste
modo, todas as funções sucedidas da palavra “Action” são interpretadas como
saídas de telas ou rotas do software. Por exemplo, ao acessar o link da página inicial
do portal, a função “indexAction” será executada e retornará um objeto de
visualização, o “ViewModel”. Este objeto permite a inserção de conteúdo das
páginas e também possibilita que sejam enviadas variáveis, por meio de um array,
para serem utilizadas. Pode-se observar isto na Figura 29 que ilustra o exemplo
citado de modo que, a página principal é gerada por meio da função “indexAction”
Figura 28: Controlador do administrador

59
que retorna para a tela do usuário uma série de variáveis e entre elas está as
oportunidades de emprego que serão listadas para o usuário.
O âmbito interativo da aplicação está composta por códigos Javascript que
foram desenvolvidos com auxílio do jQuery, uma biblioteca que fornece funções para
fazer a manipulação de elementos, animação, disparador de eventos, funções para
fácil utilização de AJAX, entre outras. Essas funcionalidades, principalmente AJAX,
foram utilizadas em sistemas de buscas, listagem de egressos, listagem de notícias
e oportunidades, criação de gráficos e interação da interface gráfica com o usuário.
Além disto, também fez-se o uso de uma biblioteca geradora de gráficos interativos,
a Hightcharts. Sua utilização sucedeu-se a partir notação de orientação a objetos em
Javascript, para tornar as funções geradoras mais flexíveis. Como se observa na
Figura 30, o objeto “GraficoColuna” compreende todas as variáveis essenciais para
a posterior utilização na criação dos gráficos. A função “gerar” se encarrega de
Figura 29: Controlador da página inicial

60
retornar para o usuário o gráfico interativo, por meio de informações requisitadas via
AJAX que são setadas neste objeto.
Enquanto ao HTML e CSS, procurou-se fazer uso de algumas funcionalidades
da versão HTML 5 e CSS3, porém sempre visualizando quais seriam os impactos na
usabilidade e acessibilidade do site. Um exemplo de conflito encontrado foi o uso
Figura 30: Objeto gerador do gráfico em colunas

61
dos placeholders junto com as máscaras nos campos de entrada de dados.
Primeiramente, observou-se que o placeholder não tinha sua funcionalidade
completa em todos os navegadores disponíveis atualmente, prejudicando a
usabilidade, o que levou ao desenvolvedor a procurar uma solução, encontrada com
o uso da biblioteca jQuery Placheholder, que verifica se o navegador possui suporte
a esta funcionalidade, caso não, ele fornece funções Javascript que simulam a
mesma. Já na área de acessibilidade, foi encontrado um problema com o uso de
máscaras, pois ao serem testadas com leitores de tela, essas eram lidas para o
usuário, podendo confundi-lo. Desta forma, a solução encontrada também foi a troca
do conjunto que fornecia essa funcionalidade por outro.
3.7 TESTES DO PRODUTO
Os testes do produto tiveram por objetivo minimizar erros e identificar
melhorias no software para que atendesse as necessidades do cliente. Para isso, a
aplicação passou por uma série de testes unitários além dos testes envolvendo o
cliente e o responsável pela manutenção.
3.7.1 TESTE UNITÁRIO
Para a execução deste teste, foi utilizado a ferramenta PHPUnit, citada
anteriormente, que possibilitou ao desenvolvedor saber se todos os elementos do
sistema estavam funcionando como se esperava. Os testes, são executados de
forma simples, sendo que esta ferramenta fornece uma ampla gama de testes
possíveis para serem feitos em um software.
Nesta fase de testes, procurou-se verificar se todas as rotas do sistema
estavam de acordo, uma vez que deve-se assegurar que ao interagir com o site, o
usuário, não deve ser remetido a uma página indevida ou inexistente. Para isto
criou-se um ambiente de testes na aplicação para desenvolver os controladores de
testes. Como pode ser observado na programação parcial na Figura 31, são
fornecidos na função: a rota que o usuário pode acessar via navegador; o código de

62
resposta HTTP (Hypertext Transfer Protocol) esperado, neste caso é setado o valor
200 que refere-se a requisição ao servidor retornada com sucesso; o identificador do
controlador que deve executar a ação; a classe do controlador e o nome da rota que
deve ser acionada, declarada nas configurações do módulo.
Com a classe pronta, pode-se executá-la a partir de um terminal, como na
Figura 32, utilizando-se o comando “phpunit”. Desta forma, os testes serão
executados de modo independente, sem que haja a intervenção no código do
sistema, ou seja, o ambiente de testes está isolado, o que permite uma maior
facilidade de executá-los e a certeza que se acontecer algum erro durante o
processo o sistema não será afetado. Portanto, ao ser executado as informações
importantes do software em operação são retornadas como, por exemplo, o tempo
de execução, a memória total utilizada pelo servidor e o número de testes
executados. Caso sejam encontrados erros, eles serão relatados e descritos nesta
mesma tela.
Figura 31: Controlador de testes

63
3.7.2 TESTES DO CLIENTE
Como a participação ativa do cliente no desenvolvimento do projeto, foi
possível trabalhar com o processo incremental de forma concisa, de modo que eram
fornecidos partes operacionais do sistema para que o cliente utilizasse. Portanto,
durante sua utilização, surgiram sugestões de melhorias, ideias de ampliação de
algumas funcionalidades e aceitação de outras.
As reuniões semanais tornaram este processo mais efetivo, pois permitiam a
comunicação direta entre o cliente e desenvolvedor. Durante estas, se destacam
alguns pontos importantes levantados pela equipe sobre a aplicação, como:
“Ao efetuar os testes, constatou-se que o software gerava as informações
desejadas com o diferencial dos gráficos interativos, no entanto sugeriu-se que o
demonstrativo de gráficos fosse ampliado.”
“A Direção de Ensino, sugeriu, que fosse planejado um espaço para inclusão
de informações sobre o egresso que ingressou no Câmpus através de cotas.
Atualmente estas informações não são persistidas, porém prevê-se seu uso.”
3.8 IMPLANTAÇÃO
O software tem previsão de ser implantado em um servidor no mês de março
de 2014. Isso ocorre pelo fato de que a instituição necessitou adquirir um novo
servidor para comportar novas aplicações e, para isso, passou por um processo
licitatório que leva certo tempo para ser executado.
Figura 32: Execução de testes

64
Portanto, enquanto o servidor não estiver disponível, a implantação e a
manutenção deste software, para que esteja online, será de responsabilidade do DTI
(Departamento de Tecnologia de Informação) do IFRS – BG. Este possuirá a versão
final do software e da base de dados já existente, aprovados pelo cliente.

65
4 CONSIDERAÇÕES FINAIS
O trabalho apresentou os conceitos e etapas de desenvolvimento do projeto
Portal de Acompanhamento de Egressos, desenvolvido durante o estágio curricular
supervisionado. Este foi de vital importância para a prática e aprimoramento de
conhecimentos técnicos e teóricos assimilados durante o curso e para o crescimento
pessoal e profissional.
No âmbito do processo de desenvolvimento de software, observou-se que o
processo utilizado possibilitou a equipe uma comunicação direta entre
desenvolvedor e cliente; como consequência, obteve-se um produto que atendesse
suas necessidades. Além disso, este modelo proporcionou um sistema de metas
semanais, de modo que a cada semana foram definidas as atividades a serem
realizadas para a próxima.
Na programação, novas técnicas foram adquiridas, principalmente na área de
acessibilidade e usabilidade, que englobam tecnologias assistivas, boas práticas
HTML/CSS e interações Javascript. Além das técnicas, obteve-se, também,
aprimoramento teórico de padrões web para desenvolvimento de sites, como o
WCAG 2.0 e e-MAG.
Já no lado servidor, houve uma evolução nos conhecimentos sobre a
linguagem PHP e gerenciamento de dependências de projeto, principalmente por
ter-se trabalhado com frameworks que utilizam a notação MVC. Eles exigem do
programador um conhecimento consistente sobre a utilização deste modelo de
arquitetura de software para que seja possível a elaboração de uma aplicação.
Outro ponto interessante foi o entendimento preciso e mais específico do
funcionamento do servidor Apache. Geralmente, este está configurado para executar
aplicações web padrões. No entanto, para o desenvolvimento desta, foi necessário
algumas configurações específicas, como a criação de virtual host para executar o
software na máquina local; a utilização do módulo do Apache “rewrite_module” que
fornece um caminho flexível para a manipulação de Uniform Resource Locator

66
(URL), criando estas a partir de regras declaradas pelo desenvolvedor; a criação de
arquivos “.htaccess” para indicar a este servidor o nível de diretório da pasta raiz e
como devem agir ao ser requisitado o acesso desta.
O Portal foi divulgado internamente e externamente, por meio de
apresentações nos eventos Mostra Técnica do IFRS – BG e SEMEX do IFRS.
Observou-se uma boa aceitação do público interno e externo, tendo como um dos
resultados a premiação de trabalho destaque, na área de comunicação, do SEMEX.
O produto deste trabalho tem previsão de implantação para março de 2014,
pois neste período será adquirido, pela instituição, um servidor que comporte novas
aplicações. A responsabilidade desta aplicação estará com o DTI do IFRS-BG e
respectivo professor e servidor que participaram do desenvolvimento.
Conforme o cliente, a aplicação superou as expectativas, pois além de facilitar
a manipulação das informações dos egressos ampliou os meios para a divulgação
destas entre a comunidade externa e interna. Além disso há a ligação direta entre
egresso e instituição que permitirá a frequente troca de informações.
Como trabalhos futuros, estuda-se a possibilidade de integração da base de
dados desta aplicação com o do Sistema Acadêmico do IFRS-BG, para que seja
possível a uniformização e centralização de informações dos egressos e estudantes
entre os sistemas. Isso foi observado pelo fato de que todas as informações
cadastradas na base de dados deste sistema, referentes a egressos, foram retiradas
do Sistema Acadêmico.

67
REFERÊNCIAS
BERGMANN, Sebastian. PHPUnit Manual. Disponível em :
<http://phpunit.de/manual/3.7/pt_br/phpunit-book.pdf>. Acesso em: 22 set. 2013.
BRASIL. Lei de diretrizes e bases da educação nacional – LDB. Lei nº 9394, de 20
de dezembro, de 1996.
BRASIL. MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO.
SECRETARIA DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO. E-MAG Modelo
de Acessibilidade em Governo Eletrônico. Disponível em:
<emag.governoeletronico.gov.br/emag/emag-3.pdf>. Acesso em: 25 jun. 2013.
CENTRO PAULA SOUZA. SAI (Sistema de Avaliação Institucional). Disponível
em: <http://www.centropaulasouza.sp.gov.br/sai/SAI.html>. Acesso em: 09 jul. 2013.
DASILVA. Perguntas Mais Frequentes. Disponível em:
<http://www.dasilva.org.br/>. Acesso em: 8 ago. 2013.
DOCTRINE PROJECT TEAM. Doctrine 2 ORM Documentation. Disponível em:
<https://media.readthedocs.org/pdf/doctrine-orm/latest/doctrine-orm.pdf>. Acesso
em: 25 set. 2013.
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO
GRANDE DO SUL. Lei de Acesso à Informação. Disponível em:
<http://www.ifrs.edu.br/site/conteudo.php?cat=231>. Acesso em: 13 out. 2013.
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO
GRANDE DO SUL – CÂMPUS BENTO GONÇALVES. Histórico. Disponível em:
<http://bento.ifrs.edu.br/site/conteudo.php?cat=26>. Acesso em: 20 jun. 2013.

68
JOHNSON, Ralph. Frameworks = (Components + Patterns). Vol. 40. Disponível em:
<http://www.inf.ufsc.br/~vilain/framework-thiago/p39-johnson.pdf>. Acesso em: 22
set. 2013.
PRESSMAN, Roger . Engenharia de Software: Uma Abordagem Profissional. São
Paulo: AMGH Editora Ltda., 2011.
SEMINÁRIO DE TECNOLOGIA EM SOFTWARE LIVRE TCHELINUX, II. 2012,
Bento Gonçalves. Desenvolvimento Web Acessível. Bento Gonçalves: TcheLinux,
2012.
SOMMERVILLE, Ian. Engenharia de Software. 9.ed. São Paulo: Pearson Education
– Br, 2011.
SONZA, Andréa Poletto. Ambientes virtuais sob a perspectiva de usuários com
limitação visual. Porto Alegre: UFRGS, 2008. 313f. Tese (Apresentada ao
Programa de Pós-Graduação em Informática), Universidade Federal do Rio Grande
do Sul, Porto Alegre, 2008.
THE COMPOSER COMMUNITY. Composer. Disponível em:
<http://getcomposer.org/book.pdf>. Acesso em: 09 out. 2013.
UML. Introduction Unified Modeling Language. Disponível em:
<http://www.uml.org/>. Acesso em: 1 ago. 2013.
WEB CONTENT ACESSIBILITY GUIDLINES 2.0. W3C Recommendation 11
December 2008. Disponível em: <http://www.w3.org/TR/WCAG20/>. Acesso em: 10
jul. 2013.
W3C. HTML & CSS. Disponível em:
<http://www.w3.org/standards/webdesign/htmlcss.html>. Acesso em: 05 out. 2013.
W3C. Javascript Web APIS. Disponível em:
<http://www.w3.org/standards/webdesign/script.html>. Acesso em: 05 out. 2013.

69
ANEXO A – DIAGRAMA CONCEITUAL

Portal Acompanhamento Egressos IFRS

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Portal Acompanhamento Egressos IFRS

Ähnlich wie Portal Acompanhamento Egressos IFRS (20)

Portal Acompanhamento Egressos IFRS