SISTEMA GERENCIADOR DE ESCOLA PÚBLICA SIGEP

Transcrição

1 ORGANIZAÇÃO SETE DE SETEMBRO DE CULTURA E ENSINO LTDA FACULDADE SETE DE SETEMBRO FASETE CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Edício José Santos Elano José Santana Lima José Roberto Feitoza de Araújo Júnior SISTEMA GERENCIADOR DE ESCOLA PÚBLICA SIGEP Paulo Afonso BA Dezembro/2010

2 Edício José Santos Elano José Santana Lima José Roberto Feitoza de Araújo Júnior SISTEMA GERENCIADOR DE ESCOLA PÚBLICA SIGEP Monografia apresentada ao curso de Sistemas de Informação da Faculdade Sete de Setembro, como requisito para avaliação conclusiva. Orientador: Prof. Msc. Igor Medeiros Vanderlei. Co-orientador: Prof. Esp. Ricardo Azevedo Porto. Paulo Afonso BA Dezembro/2010

3 Edício José Santos Elano José Santana Lima José Roberto Feitoza de Araújo Júnior SISTEMA GERENCIADOR DE ESCOLA PÚBLICA SIGEP Data de aprovação / / Monografia apresentada ao curso de Sistemas de Informação da Faculdade Sete de Setembro, como requisito para avaliação conclusiva. Orientador Prof. Msc. Igor Medeiros Vanderlei Co-orientador Prof. Esp. Ricardo Azevedo Porto. Aprovado por: Prof. Msc. Igor Medeiros Vanderlei (Orientador) Prof. Esp. Igor de Oliveira Costa Prof. Esp. Jackson Pires de Oliveira Santos Júnior Paulo Afonso BA Dezembro/2010

4 DEDICATÓRIA DEDICAMOS À Deus "Hoje posso dizer que venci, mas é verdade que se não me curvei pelo cansaço e não me abati pelas dificuldades foi porque nos momentos difíceis voltei-me para meu coração e lá Te encontrei" (Giselle Silva Magalhães). À nossa família e aos nossos queridos amigos "Falar é completamente fácil, quando se tem palavras em mente que expressem sua opinião. Difícil é expressar por gestos e atitudes o que realmente queremos dizer, ou o quanto queremos dizer, antes que a pessoa se vá. Fácil é demonstrar raiva e impaciência quando algo o deixa irritado. Difícil é expressar o seu amor a alguém que realmente te conhece, te respeita e te entende." (Carlos Drummond de Andrade).

5 AGRADECIMENTOS Edício José Santos Agradeço primeiramente a Deus, por me dar força, coragem e sabedoria para que eu possa enfrentar e superar meus obstáculos e realizar meus sonhos, permitindo que mais uma etapa de minha jornada seja concluído. Agradeço a minha família, em especial meu pai Luiz José dos Santos e minha mãe Maria José dos Santos, meus espelhos, pelos seus ensinamentos, e que, em todos os momentos me deram o total apoio e incentivo. A minha noiva e futura esposa Cristina, minha inspiração, que teve muita paciência e tem me dado muito carinho, sempre estando ao meu lado. Ao meu tio e padrinho Cícero, pela ajuda financeira e estimulo que tem me dado durante minha graduação. Aos meus irmãos que sempre me incentivaram e torcem por mim. Agradeço em especial ao professor Igor Medeiros, pela sua extraordinária orientação, e ao professor Ricardo Porto, Co-Orientador, que tiveram um papel de fundamental importância, neste projeto, não só pelas orientações, mais pelos ensinamentos, conselhos, paciência, e amizade, destinados a mim. Representam para mim, verdadeiros mestres. Aos meus amigos e companheiros de jornada Elano e José Roberto, pela compreensão, paciência e dedicação que tem dado para que este trabalho pudesse ser concluído. Aos meus amigos e colegas de classe que em todos os momentos deram o apoio necessário, me incentivaram e contribuíram diretamente ou indiretamente.

6 Elano José Santana Lima É importante sermos gratos a todos aqueles que contribuem para o nosso sucesso, sendo assim, quero deixar aqui os meus agradecimentos a todos que direta ou indiretamente me ajudaram na execução desse trabalho. Agradeço a Deus pela vida, por ter me dado saúde, capacidade para aprender e por estar presente em cada segundo do meu dia. A minha família, em especial aos meus pais Espedito Lima e Ana Sandes, por acreditarem no meu potencial, pelo carinho e por não medirem esforços no intuito de me proporcionar uma educação de qualidade. A minha irmã Elisana Lima, pelos cuidados que teve comigo durante esses quatro anos em que fizemos companhia um ao outro. A minha namorada Tatiane Souza, por estar sempre comigo nos momentos em que mais preciso, pela paciência, compreensão e palavras de incentivo dadas durante todo o período em que estive desenvolvendo essa monografia. A todos os professores com os quais convivi durante os oito períodos em que estive cursando a graduação em Sistemas de Informação, pois os seus ensinamentos foram e continuam sendo de fundamental importância para a minha formação e crescimento não só profissional, mas também pessoal. Em especial aos Professores Igor Medeiros e Ricardo Porto, os quais ajudaram de forma incisiva para que este trabalho pudesse ser realizado. Aos colegas de classe com os quais compartilhei momentos de alegria e dificuldade, entretanto, sempre acreditando que os nossos objetivos seriam alcançados. Faço meu agradecimento especial a Edício Santos, José Roberto e Thiago Francisco, pelas constantes e bem sucedidas parcerias na realização de projetos e trabalhos. Aos demais colegas, amigos e familiares que fizeram parte deste ciclo de aprendizagem, o qual se encerra nesse momento para que novos caminhos sejam traçados.

7 José Roberto Feitoza de Araújo Júnior Em primeiro lugar quero dedicar esse momento a Deus, pois sem ele nada do que aconteceu até hoje seria possível e tenho certeza que ele é uma das razões de eu ter conseguido chegar aonde cheguei e com certeza ainda me proporcionará vôos mais altos. Agradecer a toda a minha família, em especial a meu pai, minha mãe e meu irmão por sempre estarem do meu lado nos momentos mais difíceis e por terem me proporcionado uma ótima educação, à qual foi de essencial importância nessa jornada. A Juliana, minha namorada, por ser tão compreensível, por estar sempre me apoiando e animando e por entender as ausências e privações que foram proporcionadas por mim durante essa jornada de aprendizagem e conhecimento. A todos os meus amigos, que sempre me apoiaram e, tenho certeza, vão continuar me apoiando em novas caminhadas. A todos os professores que me passaram um pouco do seu conhecimento, em especial a Igor Medeiros e Ricardo Porto, que possibilitaram que esse trabalho fosse concluído de forma tão eficiente. A todos os meus amigos de classe, que possibilitaram que essa jornada fosse mais alegre, satisfatória e agradável, em especial a Edício Santos e Elano Lima, pois foram os que estiveram comigo na criação, desenvolvimento e conclusão desse trabalho. A FASETE Faculdade Sete de Setembro por proporcionar um Ensino de qualidade e uma bela infraestrutura que me possibilitou concluir o curso de maneira satisfatória. E, por último, mas não menos importante, ao Governo Federal, especificamente ao Programa ProUni, por ter me proporcionado a bolsa de estudos que possibilitou a mais um brasileiro concluir o ensino superior.

8 ARAÚJO Jr., José Roberto Feitoza de; LIMA, Elano José Santana; SANTOS, Edício José. Sistema Gerenciador de Escola Pública - SIGEP f. Monografia de Graduação do Curso de Bacharelado em Sistemas de Informação. Faculdade Sete de Setembro - FASETE. Paulo Afonso BA. As instituições públicas de ensino do Brasil apresentam inúmeras deficiências no que diz respeito ao modo como executam suas atividades. Grande parte dessas deficiências poderia ser sanada se ocorresse à automatização dos processos escolares, através de um sistema computacional que gerencie o ambiente escolar. Tendo por vista tais necessidades, este projeto de conclusão de curso teve por finalidade idealizar a criação e desenvolvimento do Sistema Gerenciador de Escola Pública - SIGEP. Software que tem como objetivo principal gerenciar as atividades inerentes ao dia-a-dia de uma instituição escolar, contribuindo para tornar mais ágil o trabalho de diretores, assistentes administrativos, professores e alunos. Para a sua implementação, foram utilizadas tecnologias como ZK framework, JavaOnRoad, PostgreSQL, Hibernate, Spring, ireport e Spring Security. O SIGEP é um sistema open source, podendo ser aperfeiçoado por qualquer indivíduo que tenha o conhecimento necessário para aperfeiçoá-lo. Palavras-chave: Software, Escola, SIGEP, ZK framework.

9 ARAÚJO Jr., José Roberto Feitoza de; LIMA, Elano José Santana; SANTOS, Edício José. Sistema Gerenciador de Escola Pública - SIGEP f. Monograph undergraduate Information Systems. Faculdade Sete de Setembro - FASETE. Paulo Afonso BA. Education institutions of Brazil have many shortcomings with regard to how they perform their activities. Most of these deficiencies could be remedied if there were the automation of school processes, through a computer system that manages the school environment. Having seen for such needs, this project completion of course was intended to idealize the creation and development of the Public School System Manager - SIGEP. Software that has as main objective to manage the activities related to day-to-day life of a school, helping to make faster work of directors, administrative assistants, teachers and students. For implementation technologies were used as ZK framework, JavaOnRoad, PostgreSQL, Hibernate, Spring, Spring Security and ireport. The SIGEP is an open source system can be improved by anyone who has the knowledge to improve it. Key words: Software, School, SIGEP, ZK framework.

10 LISTA DE FIGURAS Figura 1 - ESTRUTURA DO ZK Figura 2 CARTÃO DE HISTÓRIA DE USUÁRIO E TAREFAS Figura 3 ARQUITETURA DO SIGEP Figura 4 DIAGRAMA DE CLASSE Figura 5 MODELO ENTIDADE RELACIONAMETO - MER Figura 6 LOGIN DO SIGEP Figura 7 HOME PAGE DO SIGEP Figura 8 MENU ADMINISTRAÇÃO Figura 9 MENU ESCOLA Figura 10 MENU SECRETARIA Figura 11 MENU RELATÓRIOS Figura 12 MENU AJUDA Figura 13 JANELA CADASTRO DE ALUNO Figura 14 REGISTRO DE DISCIPLINA PASSO Figura 15 REGISTRO DE DISCIPLINA PASSO Figura 16 REGISTRO DE DISCIPLINA PASSO Figura 17 JANELA CADASTRO DE AVALIAÇÃO PASSO Figura 18 JANELA CADASTRO DE AVALIAÇÃO PASSO Figura 19 JANELA CADASTRO DE NOTAS PASSO Figura 20 JANELA CADASTRO DE NOTAS PASSO Figura 21 JANELA CADASTRO DE NOTAS PASSO Figura 22 JANELA CADASTRO DE FREQUENCIA PASSO Figura 23 JANELA CADASTRO DE FREQUENCIA PASSO Figura 24 JANELA CADASTRO DE FREQUENCIA PASSO

11 LISTA DE TABELAS Tabela 1 PLANEJAMENTO DOS RELEASES E INTERAÇÕES Tabela 2 HISTÓRIAS DE USUÁRIO PRIMEIRO RELEASE Tabela 3 - HISTÓRIAS DE USUÁRIO SEGUNDO RELEASE Tabela 4 - HISTÓRIAS DE USUÁRIO TERCEIRO RELEASE

12 SUMÁRIO 1 CONSIDERAÇÕES INICIAIS INTRODUÇÃO JUSTIFICATIVA PROBLEMA DE PESQUISA HIPÓTESES OBJETIVOS Geral Específico ORGANIZAÇÃO DO TRABALHO REFERENCIAL TEÓRICO METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE Metodologia Extreme Programming (XP) Práticas Fases da Metodologia XP SERVIDOR WEB Apache Tomcat LINGUAGEM DE PROGRAMAÇÃO E FERRAMENTAS Linguagem Java ECLIPSE SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) PostgreSQL... 32

13 2.6. JAVAONROAD HIBERNATE ZK FRAMEWORK Arquitetura do Zk IREPORT SPRING FRAMEWORK SPRING SECURITY HIPER TEXT MARKUP LANGUAGE (HTML) CASCADING STYLE SHEETS (CSS) CARACTERÍSTICAS DO SISTEMA PROPOSTO FUNCIONALIDADES ETAPAS DO DESENVOLVIMENTO PLANEJAMENTO INICIAL ARQUITETURA DO SISTEMA RECURSO DE HARDWARE UTILIZADO PARA O DESENVOLVIMENTO ESTRATÉGIA DE TESTES Teste de Unidade Teste de Aceitação do Sistema HISTÓRIAS DE USUÁRIOS RESULTADOS OBTIDOS DIAGRAMAS DE CLASSES MODELO ENTIDADE RELACIONAMENTO MER INTERFACE GRÁFICA DO SIGEP... 60

14 5.1. LOGIN HOME PAGE E MENUS CADASTROS Cadastro de Aluno Registro de Disciplina Avaliação Notas Frequência CONSIDERAÇÕES FINAIS CONTRIBUIÇÃO PARA TRABALHOS FUTUROS REFERÊNCIAS... 77

15 CAPÍTULO I CONSIDERAÇÕES INICIAIS

16 CAPÍTULO I - Considerações Iniciais 16 1 CONSIDERAÇÕES INICIAIS 1.1. INTRODUÇÃO A Tecnologia da Informação tem conseguido modernizar os diversos setores das organizações, sejam elas públicas ou privadas. O uso de tal meio, possibilita uma melhor gestão das informações e, desta forma, é possível agilizar, compartilhar e dar maior segurança às informações das empresas. Diante de tais vantagens, uma instituição educacional, munida de um bom software de gestão escolar, poderá realçar suas expectativas quanto ao aumento de produtividade e qualidade de seus núcleos (administrativo e pedagógico). Atualmente, na Escola Estadual de Xingó I, localizada no Município de Piranhas AL, não existe um sistema para o gerenciamento dos dados. O gerenciamento dos dados referente à matrícula, histórico, notas, conceitos, faltas, formação de turmas, e demais processos pedagógicos é realizado manualmente pelo assistente administrativo em uma ficha padrão e, ou digitados em planilhas no aplicativo BrOffice Calc, sendo em seguida, guardados em arquivo morto. Por esse motivo, faz-se necessário o uso da Tecnologia da Informação, mais especificamente, através de um aplicativo que melhore a capacidade de manipulação dos dados, visando assegurar rapidez na execução de atividades e garantir a veracidade das informações que são cruciais para o bom funcionamento da instituição. O presente projeto se dedica a desenvolver um software (Portal escolar) denominado de Sistema Gerenciador de Escola Pública - SIGEP, que seja livre, podendo ser estudado, adaptado, melhorado e instalado em diversas escolas. Assim pretende-se aumentar a produtividade e qualidade das equipes pedagógicas e administrativas das escolas públicas.

17 CAPÍTULO I - Considerações Iniciais JUSTIFICATIVA O modelo estrutural do ensino público brasileiro apresenta uma série de deficiências as quais refletem diretamente na qualidade dos serviços oferecidos à população. A grande maioria das escolas desempenha suas atividades manualmente, ocasionando perda de qualidade e produtividade. (NASCIMENTO, SALES, 2001) Neste sentido, o sistema SIGEP passa a exercer papel relevante, na medida em que terá como resultado um software completamente capaz de atender as mais diversas funções que fazem parte do dia-a-dia de uma escola. Garantindo assim, um melhor funcionamento das instituições públicas. Além de trazer segurança e comodidade aos processos escolares, o sistema SIGEP estará agregando valor aos princípios da tecnologia de desenvolvimento de software atual. Isto porque trará consigo os conceitos de software livre com código aberto, ocasionando a disseminação do conhecimento científico e melhorando a acessibilidade por parte de pessoas e/ou entidades que não possuem recursos para adquirir aplicativos com características semelhantes PROBLEMA DE PESQUISA Com a implantação do projeto, os processos acadêmicos serão otimizados? A informatização dos processos escolares fará com que consultas aos dados de professores e alunos sejam realizadas com maior eficiência? O projeto garantirá que os dados confidenciais de alunos e funcionários estarão armazenados em um ambiente computacional seguro, onde apenas pessoas devidamente autorizadas poderão acessá-los?

18 CAPÍTULO I - Considerações Iniciais 18 Com a utilização do software, o acesso a nota e aos processos escolares para os alunos e professores serão feitos de forma rápida? 1.4. HIPÓTESES Com a implantação do sistema SIGEP, os processos escolares serão otimizados, visto que, tarefas antes feitas manualmente ou por meio de planilhas eletrônicas passarão a ser realizadas com auxilio do software, solucionando problemas causados pela falta de suporte aos funcionários. Outros processos importantes como formação de turmas e geração de relatórios (histórico, diário de faltas e geração de boletim bimestral) serão feitos através de processos informatizados, o que diminuirá o trabalho dos funcionários em fazê-lo de forma manual. A geração dos resultados finais que antes levava bastante tempo para ser feita, agora poderá ser realizada a partir de alguns cliques, onde o funcionário gerará o resultado de todos os alunos de uma turma, a partir de informações que estarão contidas em um banco de dados que alimentará as informações presentes no resultado OBJETIVOS Geral Desenvolver um software denominado Sistema Gerenciador de Escola Pública SIGEP, que permitirá a informatização dos processos escolares, e conseqüentemente, um melhor gerenciamento dos mesmos.

19 CAPÍTULO I - Considerações Iniciais Específico Identificar as necessidades do usuário, as quais terão que ser sanadas ao final do projeto; Buscar ferramentas que auxiliem e tragam maior agilidade ao processo de desenvolvimento do software em questão; Analisar detalhadamente as principais características da Metodologia de Desenvolvimento de Software Extreme Programming (XP), como forma de garantir que suas especificações serão seguidas pelos membros da equipe de desenvolvimento; Elaborar a documentação referente à engenharia do software; Efetuar a codificação do sistema SIGEP ORGANIZAÇÃO DO TRABALHO O presente trabalho está organizado da seguinte forma: Capítulo I CONSIDERAÇÕES INICIAIS: apresenta a introdução sobre o tema escolhido Sistema Gerenciado de Escola Pública SIGEP, seguido da justificativa para a escolha do tema, na seqüência as hipóteses, objetivo geral e objetivos específicos do trabalho. Capítulo II REFERENCIAL TEÓRICO: são apresentados os resultados de pesquisas sobre as tecnologias que foram estudadas e posteriormente utilizadas no desenvolvimento do sistema. Capítulo III CARACTERÍSTICAS DO SISTEMA PROPOSTO: expõe as funcionalidades do sistema SIGEP.

20 CAPÍTULO I - Considerações Iniciais 20 Capítulo IV ETAPAS DO DESENVOLVIMENTO: mostra os passos seguidos pela equipe para o desenvolvimento e implementação do sistema, baseado nas práticas da metodologia de desenvolvimento de software XP. Capítulo V INTERFACE GRÁFICA DO SIGEP: apresenta as principais telas do sistema SIGEP. Capítulo VI CONSIDERAÇÕES FINAIS: apresenta as conclusões obtidas durante o desenvolvimento do projeto. Referências consta a bibliografia e endereços eletrônicos utilizados durante a realização da pesquisa para a realização do trabalho.

21 CAPÍTULO II REFERENCIAL TEÓRICO

22 CAPÍTULO II Referencial Teórico 22 2 REFERENCIAL TEÓRICO Para o desenvolvimento, criação e implantação do sistema SIGEP serão usadas as tecnologias listadas a seguir METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE A metodologia presente no desenvolvimento de um software é responsável por fornecer um conjunto de processos a serem postos em prática, no intuito de garantir que o resultado final do projeto seja um sistema de qualidade, que atenda as necessidades do cliente. No entanto, a escolha de uma metodologia inapropriada pode ocasionar erros durante a sua execução, erros estes, que podem ser: o não cumprimentos de prazos, o aumento de custos, como também, a implementação de funcionalidades que possivelmente não serão utilizadas pelo usuário do sistema (LEITE, 2006). No intuito de evitar que os fatores expostos anteriormente venham a se tornar problemas reais no desenvolvimento do sistema SIGEP, foi utilizada a metodologia ágil Extreme Programming (XP), visto que, esta apresenta características relevantes na busca por maior agilidade, satisfação e eficiência das atividades que norteiam a execução de um projeto de software. O estímulo à comunicação constante entre desenvolvedor e usuário final, proposto pela metodologia XP, teve papel relevante no momento de sentenciar a sua escolha como sendo a que melhor se aplica ao projeto SIGEP, pois o feedback entre ambas as partes é fundamental para que erros sejam evitados ou corrigidos rapidamente, garantindo que o produto final atenderá perfeitamente as necessidades do cliente.

23 CAPÍTULO II Referencial Teórico Metodologia Extreme Programming (XP) A Extreme Programming consiste em uma metodologia ágil de desenvolvimento de software, criada por Kent Back a partir das experiências adquiridas pelo mesmo ao decorrer dos anos em que trabalhou como desenvolvedor de software. Trata-se de um conjunto de valores, princípios e práticas voltado para o desenvolvimento rápido de sistemas computacionais, preocupando-se em mostrar resultados imediatos ao cliente, como forma de diminuir os impactos causados por mudanças tardias. (BREWER, 2001) A utilização da XP, como metodologia de desenvolvimento de software, dá-se ao fato de que a mesma possui algumas características que são inerentes ao projeto em questão. Tais como: programação orientada a objetos, equipes que possuem no máximo 12 integrantes, requisitos incertos e desenvolvimento iterativo, bem como, a apresentação de pequenas versões do sistema durante todo o processo produtivo. Dessa forma, o mesmo poderá ser avaliado pelo usuário do sistema durante o seu processo de desenvolvimento. (TELES 2004, p.21) Segundo Teles (2004), a XP possui quatro valores, os quais funcionam como pilares de sustentação para todas as práticas inerentes a essa metodologia, são eles: Feedback: consiste na resposta dada pelo cliente ao utilizar as versões do software que está sendo implementado. Permitindo que o usuário final tenha a possibilidade de observar na prática, quais são as suas reais necessidades e, como consequência disto, existe uma melhora no diálogo entre o usuário e a equipe de desenvolvimento; Comunicação: na busca pelo entendimento comum entre o que o cliente deseja e o que a equipe precisa fazer, é necessário que haja uma troca de informações eficiente. Isto se dá por meio de uma comunicação constante, com o maior detalhamento possível; Simplicidade: tornar mais simples as tarefas do projeto significa estar focado naquilo que satisfaz a necessidade do cliente. Que conforme o autor: Ao codificar uma funcionalidade devemos nos preocupar apenas com os problemas de hoje e deixar os problemas do futuro para o futuro. Não devemos tentar prever o futuro, pois raramente acertamos nas previsões ; (TELES 2004, p.22)

24 CAPÍTULO II Referencial Teórico 24 Coragem: o desenvolvimento incremental, proposto pela XP, pode gerar situações onde alguma parte do software, apesar de estar funcionando perfeitamente, precise ser modificada para atender a outras necessidades encontradas durante o processo evolutivo. A adoção da XP como metodologia de desenvolvimento permite que resultados sejam satisfatórios mesmo após a alguma mudança inesperada Práticas A XP fornece um conjunto de práticas cuja utilização tem por objetivo garantir que os valores e princípios dessa metodologia estarão sendo aplicados ao decorrer do desenvolvimento do software. Essas práticas devem ser inseridas no projeto ao tempo em que a equipe achar necessário, não havendo obrigatoriedade de se utilizar todo o conjunto de uma só vez. (SATO, 2007, p. 23) A seguir serão descritas as práticas definidas pela metodologia em questão: Cliente presente: o cliente deve direcionar o processo de desenvolvimento a partir das respostas que lhe são fornecidas pelo sistema. A sua participação é essencial em todas as etapas do projeto, pois evita que hajam informações controversas a respeito dos requisitos do sistema e garante que o resultado final estará dentro do esperado; Jogo do planejamento: no início de cada iteração, a equipe de desenvolvimento reúne-se com o cliente para que o mesmo defina as funcionalidades que devem ser priorizadas e, consequentemente, implementadas no novo release. Após esta definição, é estimado o tempo que será gasto para finalizar cada funcionalidade, de modo que o cliente esteja ciente de tais informações; Reuniões em pé (Stand Up Meeting): diariamente a equipe de desenvolvimento realiza uma rápida reunião, geralmente no turno da manhã, para que sejam avaliadas as atividades executadas no dia anterior, sendo também definidas as prioridades que devem ser implementadas ao longo do novo dia de trabalho;

25 CAPÍTULO II Referencial Teórico 25 Programação em par: essa prática consiste em utilizar um único computador como ferramenta de trabalho para dois desenvolvedores, os quais devem trabalhar em conjunto. Dessa forma, o código é revisado constantemente ao mesmo tempo em que é gerado, além de aumentar a capacidade de se encontrar soluções rápidas e eficientes para problemas que surgem durante a implementação; Desenvolvimento guiado por testes: para garantir que o software em construção terá um excelente padrão de qualidade, a metodologia XP incentiva a realização de testes; Os desenvolvedores escrevem testes para cada funcionalidade antes de codificá-las. Fazendo isso, eles aprofundam o entendimento das necessidades do cliente (o que aprimora a análise), se preocupam com as interfaces externas dos métodos e classes antes de codificá-los (o que melhora o design), sabem até onde codificar cada funcionalidade (o que ajuda a manter o sistema simples) e passam a contar com uma massa de testes que pode ser usada a qualquer momento para validar todo o sistema. (TELES 2004, p. 25) Refatoração (Refactoring): para aperfeiçoar a legibilidade do código gerado, os desenvolvedores podem realizar alterações no mesmo, no entanto, sem modificar a funcionalidade para o qual foi implementado; Código coletivo: não existe uma pessoa responsável por determinada parte do código, visto que, ele é coletivo e pode ser alterado por qualquer desenvolvedor sem que seja necessário solicitar autorização. Com isso, busca-se tornar mais rápido o processo de desenvolvimento e permitir que o código seja revisado mais vezes; Código padronizado: para facilitar o entendimento e manipulação do sistema por parte dos desenvolvedores, a equipe deve definir padrões de codificação, sendo assim, o código se torna mais homogêneo e o processo de manutenção pode acontecer com maior agilidade; Design simples: a XP presa pela simplicidade do código, sendo assim, a equipe responsável pelo sistema deve se preocupar em implementar apenas o que for suficiente para atender as funcionalidades do presente. Necessidades futuras só devem ser implementadas quando, de fato, forem indispensáveis;

26 CAPÍTULO II Referencial Teórico 26 Metáfora: as metáforas são utilizadas para tornar mais fácil a compreensão das informações trocadas entre cliente e desenvolvedor, evitando que termos técnicos, os quais podem não fazer parte do cotidiano do cliente, se tornem um empecilho para um eficiente feedback; Ritmo sustentável: como forma de garantir a motivação, a criatividade e o melhor rendimento da equipe, a metodologia XP recomenda uma carga diária de trabalho de 8 horas, resultando em 40 horas semanais. Além disso, horas extras devem ser evitadas, para que a mente dos desenvolvedores estejam descansadas ao se iniciar o dia de trabalho; Integração contínua: na medida em que uma nova funcionalidade é produzida, o código gerado deve ser rapidamente integrado ao sistema como um todo. Durante esse processo, podem surgir erros em partes que até então estavam funcionando perfeitamente. Para detectá-los e corrigí-los com maior agilidade, é recomendável a execução de testes; Releases curtos: durante o desenvolvimento do software, são geradas pequenas versões do sistema a partir de um número reduzido de histórias do usuário. Essas versões, chamadas de release, são entregues ao cliente, de modo que ele possa se familiarizar com o produto que está sendo criado e expor sua opinião a respeito do que precisa ou não ser melhorado Fases da Metodologia XP O ciclo de vida da metodologia XP é percorrido várias vezes durante o processo de produção do software. Ao final de cada iteração, gera-se uma versão (release) do aplicativo para que o cliente faça a análise, facilitando o feedback deste com a equipe de desenvolvimento (VASCO; VITHOFT; ESTANTE, sd). As fases que compõem o ciclo XP são as seguintes: Exploração: fase onde são colhidas as solicitações do cliente (estórias do usuário), referentes às necessidades que o mesmo precisa suprir. Com base nesse levantamento,

27 CAPÍTULO II Referencial Teórico 27 são definidas as funcionalidades do sistema. Faz parte desta fase a escolha das ferramentas e tecnologias que serão utilizadas na criação do software; Planejamento: nesta etapa, em consenso com o cliente, a equipe responsável pelo projeto define quais são as prioridades do sistema e, a partir deste momento, elaboram o cronograma para a execução de cada funcionalidade; Iterações para release: fase onde são executadas as iterações necessárias para a criação de cada versão do sistema. Quando uma iteração chega ao seu fim, testes elaborados pelo cliente são realizados de modo a verificar se o resultado está dentro do que foi planejado; Produção: nesta fase são realizados testes complementares para garantir que a versão produzida atende a requisitos como desempenho e estabilidade. Em seguida, a release é disponibilizada ao cliente. É possível que imperfeições sejam detectadas, neste caso, a equipe deve decidir se corrige rapidamente ou se deve deixá-las para a próxima versão; Manutenção: consiste em dar suporte as versões que já foram apresentadas aos usuários, corrigindo possíveis falhas através de atualizações. É comum que durante esta fase o projeto sofra com a diminuição da produtividade, visto que, além de realizar a manutenção é preciso continuar o desenvolvimento de novas iterações; Morte: ocorre após todas as funcionalidades terem sido implementadas e o cliente ter considerado satisfatório o produto que lhe foi apresentado. Entretanto, esta fase pode também ser efetuada quando os custos do projeto tornam inviável o seu andamento ou quando os resultados esperados não são alcançados; A XP foi criada para acabar com os receios de programadores que se viam temerosos quanto a questões como: realização de trabalho desnecessário, paralisação das atividades devido à incapacidade técnica dos executantes e consequentes fracassos. Xp é leve, eficiente, de baixo risco, flexível, previsível, científica e torna o desenvolvimento de software divertido. (BECK, 2004)

28 CAPÍTULO II Referencial Teórico 28 Um dos fatores de sucesso desta metodologia é o fato de ter encontrado o equilíbrio entre cliente e desenvolvedor. A participação do usuário final no processo produtivo dá garantias de que resultados satisfatórios serão alcançados, evita a implementação de funcionalidades que jamais serão utilizadas, além de evitar reclamações futuras por parte do cliente, visto que, o mesmo esteve presente em todas as etapas do projeto, auxiliando e dando sua opinião. (TELES 2004, p.90) 2.2. SERVIDOR WEB O servidor Web é um programa de computador que processa solicitações Hyper- Text Transfer Protocol (HTTP), o protocolo padrão da Web. Quando se utiliza um navegador de internet para acessar determinado site, este faz as solicitações devidas ao servidor Web do site através de HTTP e então recebe o conteúdo correspondente. (DA SILVA, 2007) Dessa forma, ele é o responsável pela disponibilidade das páginas, por receber as solicitações do cliente, realizar o processamento e após a finalização, devolver o resultado ao mesmo, para que possa tomar a ação desejada, dentre outros recursos que você possa acessar Apache Tomcat O Apache Tomcat é um software livre, possui a licença GNU GPL 1, o que traz a possibilidade de que pessoas interessadas no assunto possam estudá-lo ou até mesmo alterar seu códigofonte, além da grande vantagem de poderem utilizá-lo gratuitamente. Consiste em um servidor Web configurável, robusto, seguro e de alta performance desenvolvido por uma equipe de voluntários (conhecida como Apache Group) buscando criar um servidor web com muitas características e com código fonte disponível via Internet. O 1 É a licença que acompanha os pacotes distribuídos pelo Projeto GNU, e mais uma grande variedade de software, incluindo o núcleo do sistema operacional Linux. A formulação da GPL é tal que ao invés de limitar a distribuição do software por ela protegido, ela de fato impede que este software seja integrado em software proprietário. (LIMA, 2007)

29 CAPÍTULO II Referencial Teórico 29 servidor Apache é mais usado do que todos os outros servidores web do mundo juntos (Da Silva). O Apache Tomcat é referência para as tecnologias Java Servlet e JavaServer Pages (JSP). Ele cobre parte da especificação J2EE com tecnologias como servlet e JSP, e tecnologias de apoio relacionadas como Realms e segurança, JNDI Resources e JDBC DataSources. (ALECRIM, 2006) Para o desenvolvimento do SIGEP, este foi o servidor web escolhido, não só por ser de grande reconhecimento na comunidade de desenvolvedores de software, mas principalmente pelo fato de ser freeware, open source e excessivamente testado por desenvolvedores de várias partes do planeta LINGUAGEM DE PROGRAMAÇÃO E FERRAMENTAS Os computadores podem ser considerados funcionários quase perfeitos. Pois, realizam tudo o que mandamos, sem reclamações, não importando-se em trabalhar até tarde da noite, não cobrando, assim, hora extra, nem férias. Porém, em compensação não pensam. Para que possam realizar qualquer atividade é necessário explicar tudo com os mínimos detalhes em sua língua. Considerando que tudo o que os computadores conseguem entender são seqüências intermináveis de números binários, não é tão fácil passar tais instruções aos mesmos, tornando-se um trabalho quase que impossível para um ser humano. Se os programadores precisassem escrever programas diretamente em forma de binários, decorando seqüências para cada instrução do processador e para cada endereço de memória a ser acessado, provavelmente não teríamos mais programadores. No intuito de facilitar as coisas, surgiram as linguagens de programação, que diferem entre si na sintaxe e recursos, mas possuem um ponto em comum entre elas, que é a existência de um

30 CAPÍTULO II Referencial Teórico 30 compilador. Seja programando em C, seja em Java, você provavelmente deverá usar um editor para escrever seu programa, respeitando as regras estabelecidas pela linguagem escolhida e em seguida rodará o programa em um compilador, que interpretará os comandos que inclui no programa e os transformará em binários, as instruções que são entendidas pelo processador. Uma linguagem de programação é um método padronizado para expressar instruções para um computador. É um conjunto de regras sintáticas e semânticas usadas para definir um programa de computador. Uma linguagem permite que um programador especifique precisamente sobre quais dados um computador vai atuar, como estes dados serão armazenados ou transmitidos e quais ações devem ser tomadas sob várias circunstâncias. (RAHAL JÚNIOR; LEITE, 2004) A orientação a objetos é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos. Um dos grandes diferenciais da programação orientada a objetos em relação a outros paradigmas de programação que também permitem a definição de estruturas e operações sobre essas estruturas está no conceito de herança, mecanismo através do qual definições existentes podem ser facilmente estendidas. Juntamente com a herança deve ser enfatizada a importância do polimorfismo, que permite selecionar funcionalidades que um programa irá utilizar de forma dinâmica, durante sua execução. (RICARTE, 2001) A linguagem utilizada como base no desenvolvimento do SIGEP será a linguagem Java Linguagem Java Java é uma linguagem computacional completa, adequada para o desenvolvimento de aplicações baseadas na rede Internet, redes fechadas ou ainda programas stand-alone (CAMPIONE; WALRATH, 1996).

31 CAPÍTULO II Referencial Teórico 31 O Java é uma linguagem de programação criada e desenvolvida pela Sun Microsystems, na década de 90. A mesma possui uma diferencial importante em relação a maioria das linguagens de programação, pois, após ser compilada gera uma espécie de bytecode 2, onde este será executado por uma máquina virtual instalada no computador. Java é uma linguagem poderosa em ambientes distribuídos complexos como a rede Internet. Mas sua versatilidade permite ao programador ir além, oferecendo uma poderosa linguagem de programação de uso geral, com recursos suficientes para a construção de uma variedade de aplicativos que podem ou não depender do uso de recursos de conectividade. (WUTKA, 1997) A linguagem Java apresenta algumas vantagens, tais como: segurança, portabilidade e recursos de rede. Outro aspecto importante a ressaltar na linguagem Java são as extensões. A mesma apresenta diversas extensões, dentre as principais podemos destacar o Java Server Pages (JSP) e o Java Script ECLIPSE Plataforma IDE livre mantida pela Eclipse Foundation, focada no desenvolvimento de aplicações e ferramentas. Pode ser utilizada para programar códigos em JAVA, PHP, C, C++. Através da instalação de plug-ins é possível ter um ambiente de desenvolvimento amplo e completo, com várias ferramentas que abrange desde modelagens à administração de base de dados. 2 Código gerado pelo compilador de Java e executado pelo interpretador de Java. O código é independente da máquina. (Glossário de Termos Java, 2009)

32 CAPÍTULO II Referencial Teórico SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) Um Sistema Gerenciador de Banco de Dados (SGBD) é o conjunto de programas de computador (software) responsável pelo gerenciamento de uma base de dados. Ele permite ao usuário definir, construir, manipular e extrair dados de uma base de dados para as mais diversas finalidades. (MATTOSO) São várias as características dos SGBDs, dentre elas podemos citar o Controle de Acesso, que permite manter a segurança dos dados, evitando que pessoas não autorizadas possam manipular os dados, a Integridade dos Dados, garantindo a qualidade dos dados, Compartilhamento de Dados, coordenando o compartilhamento dos dados, por acessos concorrentes, sem interferir na ação de cada um deles. Para escolher um SGBD, é preciso entender quais os recursos a aplicação em questão precisa. Deve-se levar em consideração o volume de dados (em escala de tempo), as funcionalidades necessárias (complexidade), dentre outras informações relevantes PostgreSQL O PostgreSQL é um SGBD Objeto-Relacional e foi desenvolvido para lidar com base de dados de grande porte, por isso tem sido utilizado em ambientes de produção com alta demanda de dados, por diversos anos e, com segurança. (PostgreSQL, 2007). Um SGBD Objeto-Relacional é uma extensão do modelo tradicional, que incorpora novas funcionalidades e capacidade de modelagem para tratar dados complexos (objetos) sobre estruturas físicas relacionais (tabelas), ou seja, ele é considerado objeto-relacional por implementar, além das características de um SGBD relacional, algumas características de orientação a objetos, como herança, tipos complexos (Coleções e Objetos Longos Large Objetcs LOBS, exemplo: Documentos XML), dentre outros. (MATTOSO)

33 CAPÍTULO II Referencial Teórico 33 Além disso, o PostgreSQL possui suporte nativo para conexões SSL 3, dessa forma aumenta a segurança criptografando as comunicações cliente/servidor. (PostgreSQL, 2007) 2.6. JAVAONROAD Segundo Varjão (2008, p.37), a Java OnRoad é uma ferramenta de desenvolvimento ágil, cujo objetivo é aumentar a produtividade para novos desenvolvedores que utilizam a tecnologia Java, pois a mesma gera de forma automática as camadas de coleção e de negócio das aplicações. Atualmente, a Java OnRoad possibilita a produção quase que integral de um aplicativo, criando desde as classes básicas, todas as camadas do projeto, para isso faz uso da arquitetura Model View Controller a MVC, além de criar a interface gráfica Web. Varjão (2008, p.37) lista algumas vantagens que podem ser relacionadas ao uso do framework JavaOnRoad, entre elas podemos destacar três que, por si só, demonstram a viabilidade da adoção da ferramenta, são elas: Velocidade no desenvolvimento: incontestavelmente esse é o principal benefício trazido pelo JavaOnRoad. A massiva quantidade de código por ele gerada desafoga o programador de boa parte do trabalho, agilizando significativamente a programação. Aproveitamento da mão de obra qualificada na linguagem Java: Sendo aproveitado todo o uso do JavaOnRoad, nas universidades, de modo que os alunos e ou profissionais que já estão no mercado de trabalho não procurem outras linguagens para agilizar o desenvolvimento, e sim aprimorem o seus conhecimentos através do JavaOnRoad. 3 Secure Socket Layer ou SSL, é uma tecnologia que permite que os navegadores e servidores web possa se comunicar através de uma conexão segura. Isto significa que os dados enviados são criptografados por um lado, transmitida, então descodificada pelo outro lado antes do processamento. Este é um processo, em dois sentidos, o que significa que o servidor e o navegador criptografar todo o tráfego antes de enviar dados (PostgreSQL, 2007).

34 CAPÍTULO II Referencial Teórico 34 Padronização da maior parte do código, o que facilita o trabalho em equipe, auxiliar na produção, atualização e aproveitamento do código, além de auxiliar na produção da documentação do projeto HIBERNATE O Hibernate tem como objetivo fazer o mapeamento objeto/relacional no ambiente Java. O termo de mapeamento de objeto/relacional ou ORM - Object/Relational Mapping se refere à técnica de mapear uma representação de dados de um modelo de objeto para dados de modelo relacional com o esquema baseado em SQL. Segundo o site Jboss 4, o Hibernate não somente cuida do mapeamento de classes Java para tabelas de banco de dados (e de tipos de dados em Java para tipos de dados em SQL), como também fornece facilidade de consultas e recuperação de dados, podendo também reduzir significantemente o tempo de desenvolvimento gasto com a manipulação manual de dados no SQL e JDBC. O objetivo do Hibernate é aliviar o desenvolvedor de 95 por cento das tarefas comuns de programação relacionadas à persistência de dados ZK FRAMEWORK Mr. Sachin K Mahajan (2010), define ZK framework como uma estrutura de software livre de Asynchronous JavaScript + XML (Ajax), desenvolvida em código JavaTm, que permite criar um aplicativo rico de Internet habilitado pra Web 2.0. Esse framework possibilita ao desenvolvedor criar um aplicativo web sem que haja a necessidade de digitar uma única linha de código JavaScript. 4

35 CAPÍTULO II Referencial Teórico 35 Em outras palavras podemos entender o ZK como sendo análogo ao Ajax, mas sem JavaScript. Em sua composição apresenta um mecanismo baseado em Ajax que é acionado por eventos, um rico conjunto de componentes Extensible Hypertext Markup Language (XHTML) e XML User Interface language (XUL) e uma linguagem de marcação chamada ZUML, que é usada para criar interfaces do usuário ricas em recursos. A lógica de negócio é implementado em código Java e integrado com o aplicativo, e que é acionado com base em eventos e componentes. O recurso mais relevante do ZK é o seu conjunto de bibliotecas de controle para o desenvolvimento de interfaces do usuário. Mahajan (2010), lista abaixo, os principais benefícios do zk. Rico conjunto de interfaces do usuário; Ligação de dados do componente; Linguagem de marcação simples, mas poderosa, o ZUML; Alta capacidade de manutenção e extensão porque não há código no cliente; Alta usabilidade; Maior produtividade para o desenvolvedor Arquitetura do Zk Um aplicativo web desenvolvido com o ZK Framework, tem as características de um aplicativo desktop. As atividades do usuário disparam, automaticamente, eventos no servidor por meio do Cliente Engine. No servidor os componentes em execução atualizam a visualização, para que em seguida haja o retorno do cliente. O cliente (navegador) age como um visualizador, enquanto o aplicativo em questão é executado no servidor, tendo totalmente o acesso aos recursos (banco de dados, serviços da Web, etc).

36 CAPÍTULO II Referencial Teórico 36 A Figura 1 demonstra os componentes que fazem parte da estrutura do ZK. São três os componentes: ZK Client Engine, ZK Loader, e o ZK Update Engine. Figura 1 - ESTRUTURA DO ZK Fonte: Mahajan (2010) ZK Client Engine: Este é o lado do cliente do ZK, ou seja, o navegador, que envia solicitações ao servidor para obter respostas correspondentes do ZK. Essas respostas, por sua vez, são usadas pelo mecanismo para atualizar o DOM 5 no navegador. Esse componente é responsável por acionar eventos com base nas ações do usuário, exemplos desses eventos são onchange, onclick e etc. ZK Loader: Este componente gera uma página HTML, com base na URL que é solicitado pelo cliente, incluindo o CSS, além de incluir o ZK Cliente Engine, responsável por monitorar eventos do lado cliente. ZK Update Engine: Também conhecido como Asynchronous Update (AU) Engine. Este componente é responsável por receber a solicitação Ajax e atualizar os atributos correspondentes no componente ZK para que o Client Engine possa atualizar a visualização no navegador. Mahajan (2010) define o mecanismo do fluxo presente na Figura 1 da seguinte forma: 5 O Document Object Model (DOM) é uma API para documentos HTML e XML. Providencia uma representação estruturada do documento, permitindo alterar o conteúdo e apresentação visual. Essencialmente, liga páginas web a scripts ou linguagens de programação (Mozilla Developer Center).

37 CAPÍTULO II Referencial Teórico 37 O Client Engine aciona eventos com base nas ações do usuário, como onchange, onclick etc. Tais eventos chamam o ZK Update Engine, responsável por atualizar as propriedades dos componentes ZK e responder ao Client Engine. Após receber esta resposta, o Client Engine atualiza a árvore DOM no navegador para que o usuário possa obter a visualização atualizada IREPORT Segundo o site JasperReports 6, O ireport é uma framework open-source que visa facilitar a construção de relatórios utilizando a biblioteca através de uma interface gráfica desenvolvida em Swing. Ele dispõe de importantes ferramentas para desenvolver relatórios. Com ele é possível fazer layout sofisticados, contendo gráficos, imagens, sub-relatórios, tabelas de referência cruzada e muito mais. Os dados podem ser acessado via JDBC, TableModels, Java Beans, XML, Hibernate e CSV. Os relatórios gerados pelo IReport podem ter os seguintes formatos: PDF, RTF, XML, XLS, CSV, HTML, XHTML, textos, DOCX ou OpenOffice SPRING FRAMEWORK O Spring é um framework não intrusivo usado na criação de aplicações corporativas que se tornou bastante popular como uma alternativa ao padrão EJB. Com Spring não é necessário que as classes referenciem o código-fonte do projeto, reduzindo desta forma o acoplamento. (WEISSMANN, 2006) O Spring Framework tem como principal característica, separar a configuração do código da aplicação. Para isso utiliza um arquivo em formato XML especificando o relacionamento entre os componentes e os valores para propriedades que precisem ser configuradas. Partindo disto, é possível utilizar o arquivo de configuração do Spring Framework para configurar o 6 JasperReports ( )

38 CAPÍTULO II Referencial Teórico 38 valor de qualquer tipo de propriedades de Java Beans, e não apenas relacionamento/dependências entre componentes. A base do Spring Framework é um container de injeção de dependências cujo objetivo é reduzir ao máximo o acoplamento entre os componentes de um sistema em desenvolvimento.(jardim, 2010) SPRING SECURITY A Segurança é um requisito importante presente na grande maioria dos sistemas desenvolvidos. Com a necessidade de melhorar o suporte à segurança oferecida pela especificação Java EE surgiu o Spring Security. Através dele é possível em apenas um único arquivo XML, centralizar toda a configuração de segurança de um sistema WEB. Com o Spring Security é possível criar um mecanismo de autenticação e autorização para sua aplicação web em questão de minutos. O framework foca em facilitar a implementação dos casos de uso mais freqüentes, porém oferece valiosos pontos de extensão para requisitos mais complexos. Por fim, disponibiliza suporte a inúmeros diferentes tipos de autenticação e integração com as mais usadas tecnologias na área de segurança. (ZANINI) HIPER TEXT MARKUP LANGUAGE (HTML) A HTML é responsável pela criação dos documentos, denominados de páginas, da Web. Por meio dessa linguagem, o desenvolvedor pode especificar atributos para um texto (como tipo de fonte, tamanho, cor, etc) ou criar marcações que definem um vínculo com outro documento, que será apresentado quando o usuário clicar na referida marcação. Esta é a idéia por trás dos hipertextos: permitir a criação de vínculos entre diversos documentos a partir de marcações internas. (Alves, 2001)

39 CAPÍTULO II Referencial Teórico CASCADING STYLE SHEETS (CSS) O Cacading Style Sheets (CSS) ou Folha de Estilo em Cascata, se trata de um documento onde são definidas as regras de formatação ou estilos, aplicadas aos elementos estruturais de marcação. Sendo assim, o uso do CSS permite que sejam determinadas as cores, formas, tamanhos, posições e tipos, ou seja, tudo o que está relacionado a parte visual da página. Dessa forma, há uma separação entre o conteúdo e a sua visualização. (ALVES, 2001) Segundo Alves (2001), através do uso do CSS é possível: Controlar a partir de um arquivo central toda a apresentação de um site; Agilizar a manutenção do site; Permite a portabilidade dos documentos Web.

40 CAPÍTULO III CARACTERÍSTICAS DO SISTEMA PROPOSTO

41 CAPÍTULO III Características do Sistema Proposto 41 3 CARACTERÍSTICAS DO SISTEMA PROPOSTO O sistema centralizará todas as informações da escola, em um Banco de Dados localizado no servidor, facilitando o gerenciamento da instituição. Dessa forma, apenas usuários devidamente autorizados terão acesso ao sistema, sendo possível solicitar dados e relatórios necessários a um pleno e ágil funcionamento da instituição FUNCIONALIDADES O sistema tem como principal funcionalidade o acompanhamento das informações acadêmicas do ano letivo nas escolas públicas, gerenciando todo o calendário letivo por meio das seguintes funcionalidades: Cadastramento de cursos, séries, disciplinas, ano letivo; Realização de matrículas, permitindo que se faça a matrícula de um aluno novato, assim como, a renovação da matrícula de um aluno veterano; Registro de notas e faltas de alunos; Formação de turmas, permitindo o cadastro de turmas, para que as mesmas possam comportar os alunos matriculados, além de propiciar a mudança de turma de um determinado aluno, mesmo que o indivíduo já esteja ligado a uma turma, após o processo de formação de turmas; Notificação de ocorrências disciplinares, como advertências e suspensões, explicando o motivo pelo qual o referido aluno recebeu tal notificação; Cálculos de exame final, registrando atas de resultados finais, onde irá constar o desempenho da turma, seus respectivos alunos e notas finais média das notas conseguidas por ele durante os períodos letivos, referente à determinada matéria,

42 CAPÍTULO III Características do Sistema Proposto 42 resultado final somatório das notas finais, resultado da frequência quantidade de presenças do aluno em determinado ano letivo; Disponibilizar certificado de conclusão de curso/histórico (o sistema deve ser capaz de produzir o histórico do aluno, através das notas atribuídas a ele, nas disciplinas e séries cursadas pelo mesmo durante os anos letivos em que esteve matriculado); Elaborar a ficha individual de desempenho do educando, mostrando todas as informações do aluno, durante o ano letivo ao qual o mesmo esteve matriculado na instituição, como: faltas, notas referentes a cada período do ano, advertências, ocorrências e suspensões; Cadastro de pessoal (assistentes administrativos, professores, coordenadores, diretores entre outros), onde todos os funcionários serão registrados de acordo com suas funções, titulações e outros dados funcionais e profissionais específicos de cada função; Disponibilizar informações onde exibam dados de quais professores que estão lotados naquela escola; Cadastrar as avaliações referentes às etapas de cada período do ano letivo; Registrar o professor que será responsável por determinada disciplina de uma série e turma. O sistema será capaz de permitir que apenas usuários devidamente autorizados e cadastrados no sistema, possam acessar os dados e suas funcionalidades. Portanto, não será admitido a um usuário acessar funcionalidades que não estejam de acordo com o nível de permissão do mesmo. O sistema deverá ser capaz de responder a algumas questões e fornecer diversas informações, a saber: Dada a série e a turma, listar os alunos pertencentes à mesma; Permitir que os alunos visualizem suas respectivas notas durante e ao final do ano letivo;

43 CAPÍTULO III Características do Sistema Proposto 43 Dado o nome de um funcionário, exibir os seus dados, tais como: endereço, cargo exercido, data de admissão, data de saída, caso não esteja mais na instituição; Ao informar o RG de um aluno, apresentar todas as ocorrências referentes ao mesmo.

44 CAPÍTULO IV ETAPAS DO DESENVOLVIMENTO

45 CAPÍTULO IV Etapas do Desenvolvimento 45 4 ETAPAS DO DESENVOLVIMENTO O Projeto teve início em Agosto de 2010, após a observação do funcionamento de uma escola pública denominada Escola Estadual de Xingó I EEX-I, no Município de Piranhas AL. A escola, assim como muitas, detém computadores e internet, mas não existe um software que auxilie no gerenciamento dos dados escolares e, como citado anteriormente, todos os processos pedagógicos são feitos manualmente pelo assistente administrativo e diretor. No intuito de automatizar esses processos acadêmicos, foi idealizado um sistema capaz de atender as diversas necessidades encontradas, que trouxesse rapidez no desenvolvimento dessas atividades, fizesse com que a produção, por parte dos funcionários, fosse elevada de maneira significativa, sendo capaz de gerenciar, satisfatoriamente, esses processos. Partindo desse ideal, após a criação do Projeto de Pesquisa, foi feito um estudo bibliográfico, estudo de caso, coleta e análise de dados através de pesquisas e entrevistas realizadas junto aos assistentes administrativos, professores, coordenadores e diretores pertencentes à EEX-I PLANEJAMENTO INICIAL Inicialmente foi feito uma reunião com os membros da equipe de desenvolvimento, no âmbito de discutir o planejamento do projeto. Dentre as diversas questões levantadas, a que mais repercutiu foi o tempo que teríamos para desenvolver um software e concluir o nosso projeto. Como adotamos a Metodologia XP para o desenvolvimento do SIGEP, temos por obrigação seguir as práticas estabelecidas pela mesma. Dessa forma, assim como recomenda essa metodologia, foram desenvolvidos releases em pequenos períodos de tempo, visando identificar possíveis erros de forma rápida e corrigí-los ao passo em que o projeto era desenvolvido. Estes por sua vez, foram divididos em iterações, que são ciclos menores os quais permitem um melhor gerenciamento do projeto.

46 CAPÍTULO IV Etapas do Desenvolvimento 46 Foi estabelecido que o SIGEP deveria ter, até o último release, as funcionalidades mais relevantes para o pleno e ágil gerenciamento dos processos escolares, ressaltando que, quando necessário, o projeto poder ser modificado. A Tabela 1 ilustra o planejamento dos releases e suas iterações. 1º RELEASE 2º RELEASE 3º RELEASE 1ª It. 2ª It. 3ª It. 4ª It. 5ª It. 6ª It. 05/09/ /09/ /10/ /11/ /11/ /11/2010 Tabela 1 PLANEJAMENTO DOS RELEASES E INTERAÇÕES Fonte: SANTOS, Edício (2010) Para o planejamento e definição de um release é necessário que haja o envolvimento, tanto da equipe quanto do cliente. Visto que, o conteúdo de tal release será definido com base nas estórias do usuário, as quais têm como objetivo descrever os fragmentos de funcionalidades que devem ser incorporados ao sistema. A Figura 3 ilustra o Cartão de História de Usuário e Tarefas.

47 CAPÍTULO IV Etapas do Desenvolvimento 47 Figura 2 CARTÃO DE HISTÓRIA DE USUÁRIO E TAREFAS Fonte: SANTOS, Edício (2010) O cartão de História de Usuário e Tarefas apresenta os seguintes campos de descrição: Número referente ao próprio cartão; Data de criação do cartão; Dificuldade atribuída pelo desenvolvedor àquela História de Usuário; Valor atribuído à História de Usuário; Referência anterior da História de Usuário, caso haja alguma; Prioridades, tanto para o usuário quanto para o desenvolvedor;

48 CAPÍTULO IV Etapas do Desenvolvimento 48 Estimativa de tempo até a sua conclusão; Grau de risco que apresenta a referida História de Usuário; Descrição da História de Usuário, para que possa orientar o desenvolvedor acerca da criação e desenvolvimento correto da unidade a ser implementada; Notas que podem ser usadas pelo desenvolvedor acerca de algumas anotações especificas sobre a História de Usuário em questão; Quadro de Acompanhamento de Tarefas, onde são descritas o número da tarefa, a sua descrição, o estado em que se encontra tal tarefa e suas respectivas observações, por onde o desenvolvedor pode ser auxiliado e acompanhar o desenvolvimento de tarefas paralelas e/ou que dependam para que a referida História de Usuário possa ser concluída. JEFFRIES, ANDERSON (citados por TELES, 2007, p.75) afirma que em cada ciclo de release, o cliente controla o escopo, decidindo o que fazer e o que adiar, de modo a prover o melhor release possível na data acertada. O trabalho se encaixa no cronograma baseado no valor para o negócio, dificuldade e a velocidade de implantação da equipe. Nas reuniões junto ao assistente administrativo da EEX-I, foi selecionado um conjunto de histórias e, em seguida, notificando-as no Cartão de História de Usuário e Tarefas. Após a seleção das histórias foi feito uma estimativa de quanto tempo levaria para implementar cada uma delas, priorizando os cartões de maior importância para que na próxima iteração, esteja implementada ARQUITETURA DO SISTEMA A arquitetura adotada para o desenvolvimento do SIGEP, leva em consideração as facilidades com as quais os futuros usuários poderão acessar as funcionalidades do sistema. A figura 2 ilustra como está configurada, na prática, a arquitetura do sistema, a qual será descrita a seguir.

49 CAPÍTULO IV Etapas do Desenvolvimento 49 Figura 3 ARQUITETURA DO SIGEP Fonte: SANTOS, Edício (2010) Para a implementação da camada de apresentação o framework escolhido foi o ZK, tendo em vista que esse framework proporciona diversas facilidades, uma delas é o suporte ao padrão Model View Controller MVC, a qual é provida através da interface Java Genericforwardcomposer.java, representando aqui o conceito do Controller, utilizada no servidor. O ZK, por sua vez, é responsável por construir a interface gráfica do sistema através dos arquivos de extensão.zul. Ainda na Camada de Apresentação (View), o framework escolhido para a apresentação dos dados no formato de relatório foi o ireport, pois demonstrou uma curva de aprendizado bastante simples e de fácil implementação, possibilitando a geração de relatórios em várias extensões, dentre as quais podemos citar, os arquivos.pdf

50 CAPÍTULO IV Etapas do Desenvolvimento 50 Para a implementação da camada de persistência, o padrão utilizado no desenvolvimento do projeto SIGEP foi o Data Acess Object (DAO) e o framework que possibilitou que tal camada fosse implementada, sendo assim o responsável por prover essa funcionalidade, foi o Hibernate. A camada de segurança é responsável por gerenciar todo o processo referente à autenticação de usuário e autorização de acesso ao sistema. A autenticação se refere à habilidade da aplicação confirmar se o usuário pode acessar ou não o sistema através de login e senha. Essa camada está entre as camadas de apresentação, negócios e integração, ou seja, para que se tenha acesso a quaisquer recursos dessas camadas é necessário passar pelas regras de segurança da aplicação. Por oferecer recursos de fácil utilização, o framework Spring Security é utilizado para implementação da camada de segurança do sistema. Não existe um padrão que atua nessa camada, o que existem são regras que devem ser configuradas na ferramenta para que atenda as necessidades da aplicação. A visualização do sistema, por parte dos usuários, dá-se através da utilização de um browser, onde os clientes podem realizar as solicitações ao servidor Web. Para o projeto em questão, o servidor escolhido foi o Apache, responsável por responder as requisições feitas pelos usuários através do browser. Essa arquitetura foi escolhida devido à facilidade de aprendizado e emprego dos frameworks utilizados, por parte dos desenvolvedores, possibilitando ao mesmo, que o aprendizado se desse em um pequeno espaço de tempo e ainda um acréscimo no prazo para que fossem solucionadas outras questões referentes a, como por exemplo: modelagem de negócio e especificação de requisitos.

51 CAPÍTULO IV Etapas do Desenvolvimento RECURSO DE HARDWARE UTILIZADO PARA O DESENVOLVIMENTO Para o desenvolvimento do sistema SIGEP foi utilizado três notebooks com as seguintes configurações de hardware e software: Notebook CCE, Processador Intel Core 2 Duo, Memória de 2GB, HD de 320 GB, Sistema Operacional Windows 7 Profissional 32 bits, Gerenciador de banco de dados PostgreSQL, Ambiente de desenvolvimento Eclipse Ganymede 3.4, Servidor Apache Tomcat 6.0. Browser Firefox 3.6; Notebook CCE, Processador Intel Core 2 Duo, Memória de 2GB, HD de 120 GB, Sistema Operacional Windows 7 Profissional 32 bits, Gerenciador de banco de dados PostgreSQL, Ambiente de desenvolvimento Eclipse Ganymede 3.4, Servidor Apache Tomcat 6.0. Browser Firefox 3.6; Notebook DELL, Processador Intel Core 2 Duo 2.00 GHz, Memória de 2GB, HD de 120 GB, Sistema Operacional Windows 7 Profissional 32 bits, Gerenciador de banco de dados PostgreSQL, Ambiente de desenvolvimento Eclipse Ganymede 3.4, Servidor Apache Tomcat 6.0. Browser Firefox ESTRATÉGIA DE TESTES É comum ser encontradas em projetos de software diversas dificuldades ao longo da execução do mesmo. Um dos problemas que mais se destaca é a incidência de defeitos. Segundo (BECK, 2000), a metodologia XP traz no escopo um desenvolvimento orientado a testes onde o software deve ser testado constantemente em todo o ciclo de desenvolvimento para que haja o menor número de erros. Seguindo esse contexto, no desenvolvimento do SIGEP foram executados vários testes, os quais serão descritos a seguir.

52 CAPÍTULO IV Etapas do Desenvolvimento Teste de Unidade O teste de unidade tem por objetivo verificar se os resultados gerados por cada classe estão corretos. É a fase em que se testam as menores unidades de softwares desenvolvidas (pequenas partes ou unidades do sistema). Esses testes revelam erros no código. Devido aos valores da metodologia XP, os testes de unidade foram sendo desenvolvidos paralelamente, usando um caso de teste para cada método, sendo realizado no início de cada iteração, enquanto desenvolvíamos o sistema, sendo executado por várias vezes até finalmente as classes e ou métodos serem validados Teste de Aceitação do Sistema O objetivo do teste de aceitação é avaliar o sistema em desenvolvimento do ponto de vista do cliente, revelando se foi implementado no software as funcionalidades que o mesmo esperava. Após a conclusão de uma iteração, foi executado o plano de teste de aceitação do sistema. Nesse teste, os futuros usuários do SIGEP (assistentes administrativos e coordenador) interagia livremente pelo sistema no âmbito de testar se todas as funcionalidades implementadas na iteração atendiam as suas expectativas. Durante o processo de teste, alguns ajustes foram solicitados pelo cliente HISTÓRIAS DE USUÁRIOS Com base nas informações coletadas através dos cartões de Histórias de Usuários e Tarefas são montadas as releases. Essas, por sua vez, contém as Histórias de Usuários mais importantes naquele momento para o cliente. As tabelas a seguir, apresentam a seguinte descrição: Número da release à qual se refere; Número das Histórias de Usuários que fazem parte da release; Descrição das referidas Histórias de Usuários;

53 CAPÍTULO IV Etapas do Desenvolvimento 53 Prioridades, das Histórias de Usuários, para o cliente (assistente administrativo da escola EEX I) e para o desenvolvedor; e Situação em que se encontra a História de Usuário (Implementado/Não- Implementado). A Tabela 2 ilustra a primeira release do SIGEP. RELEASE HIST. Nº DESCRIÇÃO PRIORIDADE SITUAÇÃO ASS DES R1 01 O sistema deverá cadastrar os blocos da escola, assim como, a sala contida nos mesmos. Deverá também Listar, Alterar e Excluir os mesmos. 02 O sistema deverá cadastrar, funcionários e professores. Deverá também Listar, Alterar e Excluir os mesmos. 1 2 Implementado 2 1 Implementado 03 O sistema deverá cadastrar Ano Letivo, Disciplina. Deverá também Listar, Alterar e Excluir os mesmos. 2 1 Implementado 04 O sistema permitira o cadastro de Série e Turma. Deverá também Listar, Alterar e Excluir os mesmos. 05 O sistema deverá cadastrar Aluno. Deverá também Listar, Alterar e Excluir os mesmos. 1 1 Implementado 1 2 Implementado

54 CAPÍTULO IV Etapas do Desenvolvimento 54 Tabela 2 HISTÓRIAS DE USUÁRIO PRIMEIRO RELEASE. Fonte: SANTOS, Edício (2010) A Tabela 3 ilustra a segunda release do SIGEP, as devidas Histórias de Usuários pertencentes à release, suas respectivas descrições, prioridades e situações. RELEASE HIST. Nº DESCRIÇÃO PRIORIDADE SITUAÇÃO ASS DES 06 O sistema deverá cadastrar os tipos de usuário que terá acesso ao sistema. Deverá também Listar, Alterar e Excluir os mesmos. 1 1 Implementado. R2 07 O sistema deverá ser capaz de alocar professores as Disciplinas, através do Registro de Disciplina. 08 O sistema deverá cadastrar à Avaliação, para cada disciplina cadastrada, atribuindo a nota da mesma, e selecionando a turma em que a avaliação será aplicada. 09 O sistema deverá cadastrar as notas dos alunos referente à avaliação Implementado. Implementado. Implementado. Tabela 3 - HISTÓRIAS DE USUÁRIO SEGUNDO RELEASE. Fonte: SANTOS, Edício (2010)

55 CAPÍTULO IV Etapas do Desenvolvimento 55 A Tabela 4 ilustra o andamento da terceira release do SIGEP. RELEASE HIST. Nº DESCRIÇÃO PRIORIDADE SITUAÇÃO ASS DES 10 O sistema deverá emitir para cada aluno cadastrado e matriculado o formulário de Matricula devidamente preenchido. 11 O sistema deverá emitir para cada aluno matriculado o Certificado de Conclusão de Série ou Histórico Escolar devidamente preenchido. 1 2 Implementado. 2 1 Implementado. R3 12 O sistema deverá emitir para cada turma selecionada, o Registro dos Resultados devidamente preenchido. 1 2 Implementado O sistema deverá emitir para cada turma selecionada a Ata de Resultados Finais devidamente preenchidos (para a modalidade do Ensino Fundamental). O sistema deverá emitir para cada turma selecionada a Ata de Resultados Finais devidamente preenchidos (para a modalidade do Ensino Médio) Implementado. Implementado. 15 O sistema deverá emitir para cada aluno selecionado a Ficha Individual de Desempenho devidamente preenchida (para a 1 1 Implementado.

56 CAPÍTULO IV Etapas do Desenvolvimento 56 modalidade do Ensino Fundamental). 16 O sistema deverá emitir para cada aluno selecionado a Ficha Individual de Desempenho devidamente preenchida (para a modalidade do Ensino Médio). 2 2 Implementado. Tabela 4 - HISTÓRIAS DE USUÁRIO TERCEIRO RELEASE. Fonte: SANTOS, Edício (2010) 4.6. RESULTADOS OBTIDOS Ao final do terceiro release foi apresentado à versão implementada com todos os releases. A versão beta do SIGEP contém todas as funcionalidades para que os processos escolares fundamentais possam ser automatizados pelo sistema. Dentre as funcionalidades implementadas podemos citar: Cadastro de Turma, Série, Disciplina, Ano Letivo, Avaliação, Emissão do Relatório de Matrícula, Histórico, Ata de Resultados Finais, Ficha Individual de Desempenho, e as demais funcionalidades citadas no projeto. O teste de aceitação foi de fundamental importância para a conclusão da versão beta do SIGEP, pois através dele observamos que o SIGEP atendeu as expectativas esperadas pelos futuros usuários, os assistentes administrativos e coordenadores da EEX-I. Essa afirmação é facilmente comprovada através dos diversos feedbacks positivos passados pelos usuários do sistema a nós da equipe de produção.

57 CAPÍTULO IV Etapas do Desenvolvimento DIAGRAMAS DE CLASSES Figura 4 DIAGRAMA DE CLASSE Fonte: SANTOS, Edício (2010)

58 CAPÍTULO IV Etapas do Desenvolvimento MODELO ENTIDADE RELACIONAMENTO MER Figura 5 MODELO ENTIDADE RELACIONAMETO - MER Fonte: SANTOS, Edício (2010)

59 CAPÍTULO V INTERFACE GRÁFICA DO SIGEP

60 CAPÍTULO V Interface Gráfica do SIGEP 60 5 INTERFACE GRÁFICA DO SIGEP Após o desenvolvimento foi produzida a interface gráfica do software, a qual será descrita a seguir LOGIN Para acessar o SIGEP, é preciso fazer a autenticação digitando o usuário e senha conforme ilustra a Figura 6. Figura 6 LOGIN DO SIGEP Fonte: SANTOS, Edício (2010) 5.2. HOME PAGE E MENUS Após a autenticação é exibida a home page do SIGEP.

61 CAPÍTULO V Interface Gráfica do SIGEP 61 Figura 7 HOME PAGE DO SIGEP Fonte: SANTOS, Edício (2010) A home page do SIGEP esta organizado da esquerda para direita com os seguintes menus: Menu Administração Encontra-se os submenus: tipos de usuário, permissão, funcionário, professor, outros vínculos (vínculos do professor), formação (formação do professor), resultado final. Figura 8 MENU ADMINISTRAÇÃO Fonte: SANTOS, Edício (2010)