UNVERSIDADE FEDERAL DO PAMPA

RELATRIO TCNICO GESTO DE DISPONIBILIDADE VERSO 1.0

Organizao Bruno Vicelli Helison Reus Teixeira Marcelo Maia Lopes Thiago Cassio Krug

Alegrete, 2012

BRUNO VICELLI HELISON REUS TEIXEIRA MARCELO MAIA LOPES THIAGO CASSIO KRUG

RELATRIO TCNICO GESTO DE DISPONIBILIDADE VERSO 1.0

Relatrio tcnico apresentado aos docentes e discentes da disciplina de Resoluo de Problemas V do curso de Engenharia de Software da Universidade Federal do Pampa como requisito parcial para a obteno da nota final do segundo Sprint de desenvolvimento. Orientador: Sergio Luis Sardi Mergen Co-orientador: Joo Pablo Silva da Silva

Alegrete 2012

RESUMO

O presente relatrio tem o objetivo de definir o problema a ser resolvido nesta edio de Resoluo de Problemas V e a soluo consolidada do primeiro Sprint de desenvolvimento. O problema a ser solucionado referente gesto de disponibilidade de horrios de professores e disciplinas para fechar a grade de horrios dos semestres, e, alm disso, a grande dificuldade de encaixar os horrios dos professores para marcar reunies e conseguir salas disponveis. O relatrio composto pela soluo de software construda at o primeiro Sprint de desenvolvimento, o detalhamento e especificao da soluo e a fundamentao tecnolgica utilizada nas principais atividades de levantamento de requisitos, projeto, implantao, validao e testes de sistema, assim como os artefatos gerados.

Palavras-chave: Gesto de Disponibilidade, Fundamentao Tecnolgica, Horrios, Soluo de Software.

LISTA DE FIGURAS

Figura 1 Diagrama de Casos de Uso Geral ........................................................................... 17 Figura 2 Diagrama de Casos de Uso Manter Salas ............................................................... 18 Figura 3 Caso de Uso Classificar Disciplinas de Interesse ................................................... 19 Figura 4 Diagrama de Pacotes ............................................................................................... 20 Figura 5 Diagrama de Classe referentes s classes da Model ............................................... 21 Figura 6 Comparao entre a estrutura do cdigo e o projeto UML ..................................... 21 Figura 7 Diagrama de Sequncia referente ao Caso de Uso Manter Sala ............................. 23 Figura 8 Resultado dos Casos de Teste ................................................................................. 24 Figura 9 Resultados por Sutes de Teste ................................................................................ 25 Figura 10 Relatrio de cobertura de cdigo gerado pelo PHP CodeCoverage ..................... 25

SUMRIO

1 INTRODUO ..................................................................................................................... 8 2 DOMNIO DO PROBLEMA ................................................................................................ 9 3 DOMNIO DA SOLUO ................................................................................................. 10 4 VERSO CONSOLIDADA DO PRODUCT BACKLOG ................................................. 11 5 SPRINT BACKLOG ........................................................................................................... 15 5.1 Gerenciamento de tarefas .................................................................................................. 16 5.2 Anlise ............................................................................................................................... 16 5.3 Projeto ............................................................................................................................... 20 5.4 Implementao .................................................................................................................. 24 5.5 Testes ................................................................................................................................. 24 6 CONSIDERAES FINAIS .............................................................................................. 26 REFERNCIAS ....................................................................................................................... 27 ANEXOS .................................................................................................................................. 28

1 INTRODUO Nesta edio da disciplina de Resoluo de Problemas o problema a ser solucionado trata-se de um problema recorrente da Universidade quanto gesto de disponibilidade de professores, disciplinas e horrios sendo que estas trs entidades precisam encaixar de alguma forma que seja a mais eficiente possvel. Alm de o produto de software ser funcional e atender s expectativas dos Product Owners, o processo de construo da soluo deve ser produtivo e propiciar um bom desenvolvimento do trabalho tanto individual como do trabalho em equipe. Para essa primeira etapa da construo da soluo, foi adotada uma metodologia gil baseada no Scrum, e como o Scrum divide o desenvolvimento em Sprints para esse Sprint foram definidas as User Stories que devem fazer parte do escopo as quais sero melhor abordadas nas sees seguintes.

2 DOMNIO DO PROBLEMA A Universidade Federal do Pampa - Unipampa uma universidade em plena expanso, e conta com diversos professores espalhados nos seus dez campi no Rio Grande do Sul. Um dos problemas enfrentados atualmente particularmente pelo Campus Alegrete, conseguir definir as grades de horrios de forma eficiente e que consiga agregar horrios, disciplinas e professores da melhor forma possvel. Atualmente o problema central a gesto de disponibilidade envolvendo quatro esferas da universidade: Professores, Coordenadores, Disciplinas e Secretaria. O coordenador o responsvel por montar as grades de horrios de cada semestre letivo, e para fazer isso, deve levar em considerao os horrios disponveis de cada professor e as suas reas de interesse, as disciplinas que sero ministradas, as salas mais adequadas para cada disciplina e os equipamentos necessrios. Alm disso, da maneira que ocorre hoje em dia, um problema marcar uma reunio entre os professores, pois no h uma maneira de saber os horrios disponveis de cada professor, e tambm as salas disponveis para este fim.

10

3 DOMNIO DA SOLUO Dada a complexidade do problema, foi proposta uma soluo de software que otimize a gesto de disponibilidade e facilite o trabalho dos coordenadores e professores. O software que ir facilitar essa gesto de disponibilidade ser um software web, implementado em PHP utilizando o Zend Framework, Apache, e MySQL. O Zend um Framework baseado na arquitetura MVC que proporciona um robustez para a criao de sistemas escalveis e modularizados com uma qualidade elevada. O sistema de gerenciamento de disponibilidade ir auxiliar o coordenador a fazer a grade de horrios das turmas do ano atual, informando os professores, seus horrios e seus interesses em ministrar determinadas disciplinas. Para esta primeira verso do software as seguintes funcionalidades vo ser contempladas: 1. Cadastro de salas. 2. Cadastro de tipos de salas. 3. Cadastro de equipamentos para que estes sejam alocados nas salas 4. Cadastro de disciplinas de cada curso 5. Classificao do nvel de interesse nas disciplinas 6. Definio de reas de interesse 7. Incluso de eventos no calendrio

11

4 VERSO CONSOLIDADA DO PRODUCT BACKLOG Tabela 1 Definio do Product Backlog para todo o desenvolvimento Item 3 Product Backlog Como coordenador eu quero cadastrar as disciplinas correntes de cada semestre para poder alocar o professor mais apto. 9 Como secretario quero inserir no sistema informaes sobre as salas de aula para que os professores, coordenadores e alunos possam ter acesso as mesmas. 11 Como secretario eu quero cadastrar salas de aula para que as disciplinas sejam alocadas nas salas, e que todos possam visualizar. 18 Como professor eu quero classificar as minhas reas de interesse para que o coordenador utilize para fechar a grade de disciplinas. 20 Como professor eu quero colocar o meu nvel de interesse nas disciplinas a qualquer momento para que o coordenador saiba como distribuir os professores entre as disciplinas ofertadas. 23 Como professor eu quero inserir num calendrio os horrios que eu tenho disponveis para ministrar aulas, para que o coordenador tenha acesso. 1 Como coordenador antes de um semestre comear, eu quero visualizar as reas de interesse de cada professor para separar as disciplinas compatveis com os interesses. 2 Como coordenador eu quero visualizar a agenda de disponibilidade de cada professor 40h 3 45h 3 35h 1 X 20h 1 X 20h 1 X 30h 1 X 20h 1 X Estimativa de Tempo 25h Prioridade 1 Em andamento

12

para ver em qual horrio eu posso encaixar cada professor. 4 Como coordenador eu quero alocar professores s disciplinas para montar a grade de horrios do semestre. 5 Como coordenador eu quero estipular uma data limite para os professores colocaram ou atualizarem suas reas de interesse, para que depois desse perodo eu posso analisar os interesses. 6 Como coordenador eu quero estipular uma data limite para os professores colocaram ou atualizarem seus horrios disponveis para lecionar no prximo semestre. 7 Como coordenador eu quero cadastrar uma ementa de uma disciplina para que os professores consultem-na para formularem seus programas. 8 Como coordenador eu quero me logar no sistema para ter acesso as minhas informaes. 10 Como secretario quero informar ao sistema que algum equipamento de alguma sala encontra-se estragado, para que o mesmo possa ser consertado futuramente. 12 Como secretario eu quero visualizar as disciplinas que j foram alocadas as suas respectivas salas para verificar se a sala possui todos os equipamentos necessrios para a disciplina. 13 Como secretario eu quero pesquisar por alguma uma sala especfica. 14 Como secretario eu quero fazer login para 25h 3 15h 3 15h 3 15h 3 25h 3 25h 3 25h 3 30h 3 40h 3

13

que somente eu acesse as informaes referentes ao meu papel. 15 Como professor eu quero ver a ementa de uma disciplina para que eu possa elaborar um programa. 16 Como professor eu quero criar um programa para uma disciplina para que eu possa utiliz-la nas aulas. 17 Como professor eu quero colocar a bibliografia em uma disciplina para que os todos os professores possam consultar os livros utilizados no semestre anterior. 19 Como coordenador eu quero cadastrar as reas de interesse para que os professores classifiquem de acordo com seus interesses. 21 Como coordenador eu quero cadastrar os tipos de disciplinas (DCG, obrigatria) para que os professores possam visualizar qual o tipo de cada disciplina. 22 Como coordenador eu quero adicionar prrequisitos para uma disciplina para que todos possam visualizar que a disciplina depende de outras para poder ser ofertada para os discentes. 24 Como professor eu quero manter a minha agenda de compromissos sempre atualizada, para que os outros professores possam saber quando eu estou disponvel. 25 Como professor eu quero visualizar a agenda dos outros professores para quando necessrio marcar alguma reunio, ou algum outro compromisso. 26 Como professor eu quero decidir se eu vou 30h 3 30h 3 30h 3 25h 3 20h 3 25h 3 20h 3 25h 3 15h 3

14

tornar a minha agenda pblica ou no, para que eu mantenha o sigilo de certas informaes que eu quero. 27 Como professor eu quero me cadastrar no sistema para que eu possa acess-lo com minha conta. 28 Como professor eu quero modificar minha senha para que eu tenha mais segurana 29 Como professor caso eu perca minha senha quero informar ao sistema para que o mesmo me envie a senha por e-mail. 30 Como professor eu quero verificar se uma determinada sala esta disponvel para que eu possa marcar uma reunio. 40h 3 15h 3 10h 3 20h 3

15

5 SPRINT BACKLOG Tabela 2 User Stories pertencentes ao escopo de desenvolvimento Item Product Backlog Estimativa de Tempo 9 Como secretario quero inserir no sistema informaes sobre as salas de aula para que os professores, coordenadores e alunos possam ter acesso as mesmas. 11 Como secretario eu quero cadastrar salas de aula para que as disciplinas sejam alocadas nas salas, e que todos possam visualizar. 18 Como professor eu quero classificar as minhas reas de interesse para que o coordenador utilize para fechar a grade de disciplinas. 20 Como professor eu quero colocar o meu nvel de interesse nas disciplinas a qualquer momento para que o coordenador saiba como distribuir os professores entre as disciplinas ofertadas. 20h 1 X X 30h 20h 1 X X 24h 30h 1 X X 11.90h 20h 1 Prioridade Em andamento X X Fechadas Tempo Gasto 63.25h

16

23

Como professor eu quero inserir num calendrio os horrios que eu tenho disponveis para ministrar aulas, para que o coordenador tenha acesso.

35h

Como coordenador eu quero cadastrar as disciplinas correntes de cada semestre para poder alocar o professor mais apto.

25h

5.1

Gerenciamento de tarefas O trabalho foi divido de forma que a cada semana um papel era assumido por um

membro da equipe a cabia a ele responder sobre as suas tarefas. Exemplo: o analista o responsvel por levantar os requisitos juntos aos POs, fazer os casos de uso e levantar restries, regras de negcio que forem pertinentes. Para cada tarefa a ser realizada foi criado um registro no Redmine para o acompanhamento da mesma. O product backlog foi organizado no Redmine atravs do Scrumbler, e para cada User Storie no Scrumbler foram criadas subtarefas que seriam as atividades a serem realizadas por cada integrante do grupo durante a semana. Durante o decorrer do primeiro Sprint ocorreu a mudana da ferramenta utilizada para projetar o banco de dados, a ferramenta utilizada at ento era o DB-MAIN, que foi substituida pelo MySql Workbench, essa mudana foi registrada no Redmine na categoria de mudanas. 5.2 Anlise A anlise tem a finalidade de investigar o problema e definir os requisitos do sistema a para detalhar o que deve ser realizado e quais funcionalidades o sistema deve ter. Segundo Larman (2007, pag.35) Durante a anlise orientada a objetos, h uma nfase em encontrar e descrever os objetos - ou conceitos - no domnio do problema..

17

Nesta Fase coube ao analista conduzir as entrevistas com os clientes para extrair as informaes necessrias, e embasados por cada User Storie, as dvidas foram levantadas at que se chegou a um consenso do que deveria ser feito. Toda a anlise foi registrada atravs de documentos contendo o que foi discutido e tambm por e-mail para manter todos os envolvidos a par das conversas. Para a criao dos diagramas e os casos de uso foi utilizada a ferramenta de modelagem Astah. O resultado desta fase evidenciado pelos diagramas e pelos casos de uso apresentados a seguir: Figura 1 Diagrama de Casos de Uso Geral

18

Figura 2 Diagrama de Casos de Uso Manter Salas

19

Figura 3 Caso de Uso Classificar Disciplinas de Interesse

Os demais diagramas se encontram na Seo: ANEXOS

20

5.3

Projeto O projeto enfatiza a soluo do problema de forma conceitual e estrutura a arquitetura

como o sistema deve ser para atender as necessidades do cliente e para solucionar o problema da melhor forma possvel. Segundo Larman (2007, pag.35) Durante o projeto orientado a objetos (ou simplesmente projeto de objetos), h uma nfase na definio dos objetos de software e como eles colaboram para a satisfao dos requisitos. Na fase de projeto o grupo decidiu em conjunto a melhor forma de estruturar o software e coube ao Projetista dar a palavra final sobre as decises tomadas. Os diagramas de classe foram feitos na ferramenta Astah e o modelo de banco de dados no MYSQLWorkbench. Como resultado desta fase, foram criados diagramas de classe, diagramas de sequncia e o modelo de banco de dados para dar suporte programao que podem ser vistos a seguir. Figura 4 Diagrama de Pacotes

21

Figura 5 Diagrama de Classe referentes s classes da Model

Figura 6 Comparao entre a estrutura do cdigo e o projeto UML

22

Figura 6 Diagrama de Classes referentes DBTable

23

Figura 7 Diagrama de Sequncia referente ao Caso de Uso Manter Sala

Os demais diagramas se encontram na Seo: ANEXOS

24

5.4

Implementao Na fase de implementao coube ao programador seguir aquilo que foi projetado e

implementar o sistema de acordo com as especificaes e tambm seguir o padro que o Zend Framework impe. O cdigo do projeto foi versionado atravs do GitHub e encontra-se pblico, ou seja, qualquer pessoa pode ter acesso atravs do endereo:

https://github.com/grupo3rpv/rpv O sistema funcional pode ser acessado no endereo:

http://46.4.218.254/rpv/gestaodisponibilidade/public/ 5.5 Testes O teste do software tem a finalidade de investigar o software a fim de fornecer informaes sobre sua qualidade em relao ao contexto em que ele deve operar, avaliar o software perante a especificao feita atravs do levantamento de requisitos, e inclui tambm o processo de utilizar o produto para encontrar seus defeitos. Nesta fase coube ao testador escrever os scripts de teste e execut-los, assim como escrever os casos de testes baseados nos casos de uso e execut-los com o sistema. Como resultado dos testes unitrios foram gerados relatrios de cobertura de cdigo com a ferramenta Code Coverage e os casos de teste evidenciados na ferramenta TestLink. Figura 8 Resultado dos Casos de Teste

25

Figura 9 Resultados por Sutes de Teste

Figura 10 Relatrio de cobertura de cdigo gerado pelo PHP CodeCoverage

Os demais relatrios se encontram na Seo: ANEXOS

26

6 CONSIDERAES FINAIS

O desenvolvimento de software para obter sucesso requer um processo de desenvolvimento bem organizado e o comprometimento de todos os membros da equipe trabalhando cooperativamente e mantendo uma comunicao efetiva. Essa afirmao se torna ainda mais relevante levando-se em conta a utilizao do Scrum como processo gil de desenvolvimento, onde a interao entre os componentes constante e todos atacam o mesmo problema para tentar solucion-lo da melhor forma e mais rpido possvel. Ser gil dficil, embora valha a pena, porque requer mudanas de pensamentos, de comportamentos, quebras de paradigmas e sair da zona de conforto. Alm da adoo do Scrum na prtica, outro fator crtico para o projeto o tempo, conseguir administr-lo de forma eficiente e satisfatria, de forma que o escopo seja atendido em sua totalidade um desafio, e representou o maior risco para o projeto. Alm disso, foi um desafio conseguir refletir no diagrama de sequncia a soluo de implementao e nivelar o conhecimento sobre o Zend Framework. Como pontos de sucesso do projeto podem ser destacados o trabalho colaborativo em grupo, a maior parte das tarefas concludas e funcionais, o aprendizado colaborativo e a aplicao de conhecimentos de engenharia de software na prtica.

27

REFERNCIAS

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientado a objetos e ao desenvolvimento iterativo - 3 Edio - Porto Alegre: Bookman, 2007.

COHN, Mike. Desenvolvimento de software com Scrum: aplicando mtodos geis com sucesso / Mike Cohn 1 Edio Porto Alegre: Bookman, 2011.

ZEND Framework. Disponvel em: <http://framework.zend.com/>. Acesso em maio de 2012

28

ANEXOS 1. DIAGRAMAS DE CASO DE USO 2. DIAGRAMAS DE CLASSE 3. DIAGRAMAS DE SEQUNCIA 4. PHPUNIT 5. TESTLINK 6. DIAGRAMA DE GANNT