Download - TAP - Mentoring
• Projeto: MENTORING
• Cliente: Lisieux Andrade
• Data: 17/02/2014
Docu
men
taçã
o
Sumário
Sumário...................................................................................................................................................2
1. Termo de Abertura............................................................................................................................4
1.1 Informações sobre o Documento.....................................................................................................5
2. Declaração de Escopo.........................................................................................................................8
2.1 Histórico............................................................................................................................................8
2.2 Objetivos do Projeto.........................................................................................................................8
2.3 Benefícios do Projeto........................................................................................................................8
2.4 Descrição do Projeto........................................................................................................................9
Projeto de desenvolvimento de um sistema a serviço do projeto Mentoring, cuja finalidade é de facilitar a comunicação e interação entre alunos e professores.........................................................9
2.5 Principais Produtos..........................................................................................................................9
2.6 Critérios de aceitação.......................................................................................................................9
2.7 Restrições existentes (Caso haja!)...................................................................................................9
2.8 Riscos identificados..........................................................................................................................9
2.9 Estimativas iniciais.........................................................................................................................10
2.10 Organização inicial do Projeto....................................................................................................10
2.11 Principais marcos.........................................................................................................................10
3. EAP/WBS..........................................................................................................................................13
4. Gestão de RH....................................................................................................................................14
4.1 Perfil e características Técnicas desejadas...................................................................................14
5. Plano de Execução............................................................................................................................16
5.1 Equipe Responsável........................................................................................................................16
5.2 Identificação do cliente..................................................................................................................16
5.3 Levantamento de Recursos do Projeto.........................................................................................175.3.1 Recursos Humanos.....................................................................................................................175.3.2 Infraestrutura do Projeto............................................................................................................185.3.3 Tecnológicos..............................................................................................................................18
5.4 Cronograma Inicial........................................................................................................................195.4.1 Gráfico de Gantt.........................................................................................................................19
5.5 Definição do Sistema.....................................................................................................................19
5.6 Definição do problema...................................................................................................................19
5.8 Requisitos (Funcionais e Não-Funcionais)...................................................................................205.8.1 Levantamento dos Requisitos Funcionais..................................................................................205.8.3 Levantamento dos Requisitos Não-Funcionais..........................................................................205.8.2 Descrições dos Requisitos Funcionais.......................................................................................21
Portal ODM Página 2
5.8.3 Levantamento dos Requisitos Não-Funcionais..........................................................................215.9 Diagrama de Use-Cases (Casos de Uso).......................................................................................235.9.1 Descrição de Casos de Uso – Maneira Detalhada......................................................................245.10 Diagrama de Domínio.................................................................................................................255.11 Diagrama de Classes...................................................................................................................26
5.12 Diagrama Arquitetural................................................................................................................275.12.1 Modelo Arquitetural Interna (MVC).......................................................................................275.12.2 Modelo Arquitetural Externa (Instalação)...............................................................................27
5.13 Diagramas comportamentais......................................................................................................285.13.1 Atividades................................................................................................................................285.13.2 Sequencia.................................................................................................................................28
5.14 Conclusão......................................................................................................................................28
5.15 Contatos.........................................................................................................................................28
ANEXOS...............................................................................................................................................29
Portal ODM Página 3
1. Termo de Abertura
Portal ODM Página 4
1.1 Informações sobre o Documento
Nome do Projeto: MentoringGerente do Projeto: Thalles RafaelElaborado por: Thalles RafaelRevisado por: (caso tenha sido revisado)
Versão do Documento: 001Data da Versão: 19/02/2014Data Revisão: (caso tenha sido revisado)
DESIGNAÇÃO
Thalles Rafael, você foi designado como Gerente de Projeto do Mentoring. Você é responsável por assegurar que os requerimentos do cliente sejam satisfeitos e que todos os produtos e serviços cotados ou contratados sejam entregues. Você é responsável pelo sucesso do projeto e estará trabalhando próximo aos gerentes funcionais apropriados para assegurar que todos os objetivos do projeto sejam atingidos.
RESPONSABILIDADES
Revisar a documentação formal do projeto e tomar uma decisão para [Aceitar, Recusar ou Aceitar com condições] a responsabilidade pelo projeto.
Atuar como o ponto central de contato para toda comunicação formal relacionada entre a organização e o cliente.
Assegurar que os membros da equipe do projeto estejam cientes de suas responsabilidades e também, que todos os compromissos assumidos pelos indivíduos sejam realizados.
Gerenciar os compromissos contratuais para realiza-los em tempo, dentro do orçamento e com satisfação do cliente.
Elaborar e atuar o Plano de Projeto com a anuência expressa do cliente. Controlar os custos, cronograma, orçamento e variações técnicas dentro das margens
estabelecidas do projeto. Manter toda documentação atualizada nos sistemas, bem com na base de conhecimento. Seguir todos os processos e padrões metodológicos. Reportar formalmente o status do projeto a gerencia regularmente, evitando surpresas.
AUTORIDADE
Engajar e substituir o pessoal da equipe quando necessário e dirigir as atividades da equipe.
Acessar os contatos com o cliente em todos os assuntos relativos a este projeto. Acessar os Gerentes de Recursos em todos os assuntos relativos ao projeto. Controlar o orçamento do projeto. Dirigir ações de monitoramento de atividades referentes à, tempo, custo, risco,
Portal ODM Página 5
performance e qualidade de forma a garantir que todos os problemas sejam prontamente identificados, reportados e solucionados.
Contatar através das unidades funcionais e com todos os níveis de gerencia para realizar os objetos do projeto.
Delegar responsabilidades e autoridade do projeto dos membros de sua equipe.
ESCOPO
Objetivos: O Projeto Mentoring tem como objetivo Desenvolver um sistema que será utilizado por alunos e professores. O Portal deverá apresentar-se como uma importante ferramenta de comunicação entre o aluno e o professor.
Metas: Ter um sistema de alta usabilidade, que proporcione aos alunos e professores um meio de
comunicação acadêmica para a solução de dúvidas relativas ao âmbito acadêmico.
Premissas: O sistema deverá rodar em plataforma Web
Restrições: O produto deverá ser entregue até 26/02/2014.
Normas Verificadas
Exigências legais verificadas
Restrições verificadas
Envolvidos comunicados
RISCOS
Os riscos que poderão a vir acontecer no decorrer do desenvolvimento do projeto são: Afastamento de membros da equipe por motivos diversos, isso ira afetar
consideravelmente o desenvolvimento do projeto já que a saída de um membro pode vir a atrasar as entregas das funcionalidades nos prazos determinados.
Possíveis mudanças de politicas corporativas, essas mudanças podem afetar o projeto no que diz respeito às importâncias de entrega dos requisitos.
Mudanças constantes nas funcionalidades propostas inicialmente no projeto podem tornar o projeto inviável, pois essas mudanças poderão provocar atrasos no prazo de entrega.
Portal ODM Página 6
PRAZO
O projeto terá o prazo de 15 dias, a partir da data de aprovação e iniciação do desenvolvimento do projeto.Assim sendo, o prazo final para a entrega do projeto, com todos os seus requisitos estando em pleno funcionamento, ocorrerá em 26/02/2014
INVESTIMENTO
Por tratar-se de um projeto de extensão que visa o aprendizado e desenvolvimento do(s) envolvido(s) como premissa e, cujos fins são de cunho benéficos à sociedade, o referido projeto não apresenta investimento.
PRINCIPAIS ENVOLVIDOS
A equipe da Fábrica de Software do Unipê responsável pelo desenvolvimento e entrega do portal, bem como o diretor que representa a Fábrica – Walace Bonfim. A coordenadora do projeto Mentoring – Lisieux Andrade, bem como a própria instituição Unipê.
Portal ODM Página 7
2. Declaração de Escopo
2.1 Histórico
O projeto foi identificado como uma oportunidade de padronizar a interação entre o aluno e o professor para solucionar as dúvidas, através do Sistema Mentoring. Que antes era realizado por e-mails.
2.2 Objetivos do Projeto
Criar um sistema de fácil interatividade, que apresente clareza e intuitividade e, principalmente, que alcance o objetivo de proporcionar um relacionamento entre alunos e professores, para a solução de duvidas sobre o ambiente acadêmico.
2.3 Benefícios do Projeto
Portal ODM Página 8
Ordem Descrição1 Facilitar a relação aluno-professor2 Desenvolvimento acadêmico
2.4 Descrição do Projeto
Projeto de desenvolvimento de um sistema a serviço do projeto Mentoring, cuja finalidade é de facilitar a comunicação e interação entre alunos e professores.
2.5 Principais Produtos
Ordem Produto Descrição
1 MentoringSistema do Mentoring, que facilitará a relação entre professores e alunos.
2 Treinamento de usuáriosManual explicativo para facilitar a utilização e o conhecimento do sistema Mentoring.
2.6 Critérios de aceitação
Ordem Produto Descrição
1 MentoringInterface gráfica Facilidade de utilizaçãoInteratividadePerformance
2 Treinamento de usuários Utilização de uma didática adequada para o usuário final
2.7 Restrições existentes (Caso haja!)
Ordem Restrições1 O sistema deverá rodas em plataforma Web.2
2.8 Riscos identificados
Ordem Risco Resposta
Portal ODM Página 9
1Evasão de membros da equipe
2.9 Estimativas iniciais
EstimativaDuração do projeto 10 diasData de Inicio 17/02/2014Data de Termino 26/02/2014Recursos Consultoria
SoftwareTreinamentoEquipe interna TI: 1 analista de sistema; 1 analista de dados e georeferência; 3 desenvolvedores; 1design; 1 gerente de projeto; 1 dba; 1 front-end.
Qualidade Critérios de qualidade necessáriosCustos Sem custos financeiros envolvidos.
2.10 Organização inicial do Projeto
Função Recurso
Responsável pelo Projeto Thalles Rafael
Equipe de TI -Thalles Rafael Gerente de Projeto- xxxx Analista de Sistemas- xxxx Analista de Dados e Georeferência- xxxx Desenvolvedor- xxxx Desenvolvedor- xxxx Designer
2.11 Principais marcos
Portal ODM Página 10
Fase Marco(Produto / Entrega)
Entrega Prevista
Inicio do projeto Levantamento dos requisitos 11/02/2014Implantação Diagnostico de erros e revisão do escopo 12/02/2014
Implantação do sistema (parcialmente) 24/02/2014Verificação de erros e correção de erros xx/xx/xxImplantação do sistema versão final xx/xx/xxTreinamento dos usuários e entrega final do sistema
xx/xx/xx
Operação assistida Consultoria para implementação de ajustes e novas ou novas implementações
Conforme demanda
Caso haja!Vai variar de projeto para projeto.
Caso haja!Vai variar de projeto para projeto.
Portal ODM Página 11
3. EAP/WBS
Portal ODM Página 12
4. Gestão de RH
4.1 Perfil e características Técnicas desejadas
RECURSOS HUMANOS
PERFIL CARACTERÍSTICAS TECNICAS
Gerente de Projeto
- Formação em Gestão da TI, Engenharia da Computação ou afins;- Experiência em gerenciamento de projetos de desenvolvimento de software;- Conhecimento nas principais metodologias de desenvolvimento de sistemas, tais como RUP, XP, CMMI, dentre outras;- Conhecimento nas principais metodologias de gerenciamento de projetos, tais como PMBOK, metodologias ágeis, dentre outras;- Experiência com ferramentas de controle de projetos (WBS Chart Pro, MS-Project, etc);
- Desejável Certificação PMP ou CAPM;- MBA ou pós-graduação em gerenciamento de projetos- Fluência em inglês falado;- Disponibilidade imediata.
Portal ODM Página 13
- Excelentes capacidades de liderança, comunicação, influência e negociação;- Bom domínio do inglês (principalmente, leitura e escrita);- Excelente domínio do português;
Analista de Sistemas
Nível Superior incompleto;Facilidade de comunicação;Conhecimento de administraçãoPersonalidade carismática;Organização;Domínio nas ferramentas e linguagens supracitadas;Gestão operação e padrões de mercado.
Notação UML, Notação BPM, Metodologias Ágeis, Conceitos de qualidade de software.
Desenvolvedor Nível Superior\Técnico incompletoFacilidade de comunicação;Facilidade de trabalho em grupo;Organização;Domínio nas ferramentas e linguagens supracitadas;
Conhecimentos em SEO, SVN e Grails Framework; Experiência em desenvolvimento de softwares de código aberto Habilidade para dar boas estimativas; Comprometimento com o prazo; Boa comunicação; Teamplay. Bom humor.
Teste de Software
Nível Superior incompletoFacilidade de comunicação;Facilidade de trabalho em grupo;Organização;Domínio nas ferramentas e linguagens supracitadas;
Jmit, Selenium, ferramenta de teste de SQL ingetion
Portal ODM Página 14
5. Plano de Execução
5.1 Equipe Responsável
Thalles Rafael (Gerente de Projeto) xxxxxxxxx (Analista de Sistemas) xxxxxxxxx (Analista de Dados e Georeferência) xxxxxxxxx (Desenvolvedor) xxxxxxxxx (Desenvolvedor) xxxxxxxxx (Designer)
Equipe: Observatório do Milênio
5.2 Identificação do cliente
Nome do Cliente: Lisieux Andrade
Portal ODM Página 15
Endereço: BR 230, KM 22, Água Fria – João Pessoa/PBCEP: 58053-0000Fone/Fax: (83) 2106-9274 Dirigentes atuais e respectivos cargos:
Lisieux AndradeCoordenadora do Projeto
Lisieux AndradeResponsável pelo Projeto
Ramos de negocio: MentoringResponsável pelo Levantamento: Thalles Rafael
5.3 Levantamento de Recursos do Projeto
5.3.1 Recursos Humanos
RECURSOS HUMANOS PERFIL
01 Gerente de Projetos- Thalles Rafael
- Nível Superior em Gestão da Tecnologia da Informação ou afim;
- Facilidade de comunicação;- Capacidade de Liderança;- Capacidade de Negociação;- Conhecimento nas principais
metodologias de gerenciamento de projetos, tais como PMBOK, metodologias ágeis, dentre outras;Experiência com ferramentas de controle de projetos (WBS Chart Pro, MS-Project, etc);
- Excelente domínio do português;- Capacidade de Persuasão;- Organização.- Conhecimento em ferramentas
gerenciais em geral.
02 Analistas de Sistemas.- xxxxxxxxx
*Graduando em Ciência da Computação ou Afins;
*Facilidade de comunicação;*Conhecimento de administração*Personalidade carismática;*Organização;*Domínio nas ferramentas e linguagens
supra citadas;*Gestão operação e padrões de mercado.
03 Desenvolvedores *Graduando em Ciência da Computação ou
Portal ODM Página 16
- xxxxxxxxx - xxxxxxxxx - xxxxxxxxx
Afins;*Facilidade de comunicação;*Facilidade de trabalho em grupo;*Organização;*Domínio nas ferramentas e linguagens
supra citadas;
01 Analista em Georeferência - xxxxxxxxx
*Graduando em Ciência da Computação ou Afins;
*Facilidade de comunicação;*Facilidade de trabalho em grupo;*Organização;*Domínio nas ferramentas e linguagens supracitadas;
01 Designer - xxxxxxxxx
*Graduando em Ciência da Computação ou Afins;
*Criatividade;*Proatividade;*Conhecimentos das principais ferramentas
para design, como Photoshop, Corel Draw, Dreamweaver.
Conhecimentos de modelagem, desenho e cores.
5.3.2 Infraestrutura do Projeto
DISCRIMINAÇÃO QUANT.
5.3.3 Tecnológicos
DESCRIMINAÇÃO QUANT. PLATAFORMA
Software / Tecnologias
Portal ODM Página 17
5.4 Cronograma Inicial
Análise, planejamento e especificação.Projeto, modelagem, construção e testes (Iterações)Desenvolvimento / Testes
5.4.1 Gráfico de Gantt
5.5 Definição do Sistema
xxxxxxxxx
5.6 Definição do problema
O Problema xxxxx
Quem é afetado?
xxxxx
Proposta de Solução
xxxx
5.8 Requisitos (Funcionais e Não-Funcionais)
Portal ODM Página 18
Os requisitos definem os serviços que o sistema deverá oferecer, e o conjunto deles determina a operação do sistema. São divididos em Requisitos Funcionais e Não-Funcionais.
5.8.1 Levantamento dos Requisitos Funcionais
Os requisitos funcionais referem-se aos requisitos que estão relacionados com a maneira com que o sistema deve operar, onde se especificam as entradas e saídas do sistema e o relacionamento comportamental entre elas, assim como a interação com o usuário.
Desta forma, os requisitos funcionais encontrados para o Mentoring são:
5.8.3 Levantamento dos Requisitos Não-Funcionais
Os requisitos não funcionais são aqueles que não estão especificamente relacionados com a qualidade do sistema. Eles impõem restrições no produto a ser desenvolvido e/ou no processo de desenvolvimento do sistema como também especificam restrições externas as quais o produto precisa atender.
Eles referem-se a questões como: segurança, confiabilidade, usabilidade, desempenho, entre outros.
Desta forma, os requisitos não funcionais encontrados para o Mentoring são:
Portal ODM Página 19
RF REQUISITOS FUNCIONAIS
RF01 Inserir chamado
RF02 Listar chamados
RF03 Visualizar chamado
RF04 Responder chamado
5.8.2 Descrições dos Requisitos Funcionais
[RF1]–Abrir chamadoAtores: Aluno.Pré Condições: Acessar URL do sistema.Pós Condições: Visualizando tela inicia1
Descrição: Este caso de uso tem por objetivo efetuar/executar um novo chamado aberto pelo aluno.
[RF2] – Listar chamadoAtores: Coordenador do Mentoring.Pré Condição: Acesso ao link xxx(acrescentar nome do link).Pós Condições: Visualização da tela do chamado.Descrição: Este caso de uso consiste em realizar a operação de visualização de todas as chamadas, podendo ser ordenadas de acordo com o filtro de status (aberto, fechado, encaminhado).
[RF03] – Visualizar Chamado (Aluno)Atores: Aluno Descrição: O objetivo deste caso de uso é permitir que o aluno visualize a resposta de um chamado que por ele foi aberto.Pré-Condições: Acessar o link que foi enviado ao email do aluno, quando o chamado for respondido. Pós-Condições: O aluno visualizando a tela de Abrir Chamado.
1Estas são funcionalidades e não estados.
Portal ODM Página 20
[RF4] – Responder Chamado (Mentor)Atores: Coordenador do Mentoring (Mentor)Pré Condição: Estar visualizando um chamado com estado abertoPós Condições: Visualização da tela de que a resposta foi enviada com sucesso.Descrição: Este caso de uso consiste em realizar a operação do mentor que responde a um chamado, que implicitamente é fechado ao ser respondido.
5.8.3 Levantamento dos Requisitos Não-Funcionais
Os requisitos não funcionais são aqueles que não estão especificamente relacionados com a qualidade do sistema. Eles impõem restrições no produto a ser desenvolvido e/ou no processo de desenvolvimento do sistema como também especificam restrições externas as quais o produto precisa atender.
Eles referem-se a questões como: segurança, confiabilidade, usabilidade, desempenho, entre outros.
Desta forma, os requisitos não funcionais encontrados para o Portal ODM são:
Portal ODM Página 21
REF REQUISITO
RNF01O Portal deve ser acessível pelos browsers Microsoft Internet Explore, Firefox da Mozilla, Google Chrome e Apple Safari. (USABILIDADE)
RNF02As páginas Web não devem demorar mais do que 10 segundos para serem carregadas no browser durante o uso normal do sistema. (DESEMPENHO)
RNF03O sistema não deve demorar mais do que 3 segundos para responder a um pedido do cliente de uma página Web estática. (DESEMPENHO)
RNF04O sistema não deve demorar mais do que 8 segundos para responder a um pedido do cliente de uma página Web dinâmica. (DESEMPENHO)
RNF05 Um chamado não poderá ser excluido. (SEGURANÇA)
5.9 Diagrama de Use-Cases (Casos de Uso)
Portal ODM Página 22
5.9.1 Descrição de Casos de Uso – Maneira Detalhada
[RF1] –Abrir chamadoAtores: Aluno.Pré Condições: Acessar URL do sistema.Pós Condições: Visualizando tela inicia2
Descrição: Este caso de uso tem por objetivo receber um novo chamado aberto pelo aluno.
Sequencia de Eventos: Fluxo Principal
Ação do Ator Resposta do sistema1 O aluno informa a URL xxx no browser 2 Apresenta a tela de abertura de chamado
(EI1)3. O aluno ao acessar o sistema, deverá informar os seguintes campos: Nome, Curso, Período, Matricula, Email, Telefone, Categoria, Assunto e Pergunta, conforme EA1. Após digitados todos os campos, o aluno deverá clicar no botão “enviar”.
4. Caso todos os campos estiverem preenchidos, o sistema envia um e-mail de confirmação para o aluno e para o coordenador e apresenta a mensagem M1 em uma janela tipo popup com botão de confirmação.
3. O aluno clica no botão de confirmação. 4. O sistema retorna à URL inicial.
Seqüência de Eventos: Fluxo Alternativo
Ação do Ator Resposta do sistema1 O aluno informa a URL xxx no browser 2 Apresenta a tela de abertura de chamado
(EI1)3. O aluno ao acessar o sistema, deverá informar os seguintes campos: Nome, Curso, Período, Matricula, Email, Telefone, Categoria, Assunto e Pergunta, conforme EA1. O aluno digita o botão “Cancelar”.
4. O sistema limpa todos os campos.
Sequencia de Eventos: Fluxo de Exceção 1
Ação do Ator Resposta do sistema1. Deixar algum campo não preenchido. 2. Caso algum campo não seja preenchido, o
sistema exibirá mensagem de erro M2 em uma janela tipo popup com botão de confirmação.
3 O aluno clica em OK 4 A tela de abertura é disponibilizada no estado que estava antes da mensagem de erro.
Quadro de MENSAGENS2
? Estas são funcionalidades e não estados.
M1 Chamado recebido com sucesso. Você receberá o protocolo por e-mail dentro de alguns instantes.
M2 Todos os campos deverão ser preenchidos.
Quadro de ESPECIFICAÇÃO DE ATRIBUTOSNome TextoCurso TextoPeríodo TextoMatricula InteiroE-mail TextoTelefone InteiroCategoria TextoAssunto TextoPergunta Texto
ESBOÇOS DE INTERFACES
● RF2 –Visualizar listagem de chamadas
Portal ODM Página 24
Atores: Coordenador do Mentoring.Pré Condição: Acesso ao link xxxPós Condições: Visualização da tela do chamado.Descrição: Este caso de uso consiste em realizar a operação de visualização de todas as chamadas, podendo ser ordenadas de acordo com o filtro de status (aberto, fechado, encaminhado).
● Sequencia de Eventos: Fluxo Principal – Visualizar listagem de chamadas
Ação do Ator Resposta do sistema
1. Usuário digita a URL de acesso a listagem navegador.
2. Exibe para o usuário a tela com a listagem de todas as chamadas, ordenadas de forma decrescente de acordo com a data. (E1).
3. Seleciona um chamado com um clique que remete a uma URL de detalhamento do referido chamado
4. Exibe na tela o chamado selecionado. (EI2).
● Sequencia de Eventos: Fluxo Alternativo 1 – Busca de chamadas por filtro
Ação do Ator Resposta do sistema
1. Usuário digita a URL no navegador.
2. Exibe para o usuário a tela com a listagem de todas as chamadas, ordenadas de forma decrescente de acordo com a data. (EI1).
3. Seleciona opção de filtro de chamadas de acordo com critérios de status (aberto, fechado ou encaminhado) e clica no botão “Buscar”. (EI3)
4. Exibe as chamadas listadas de acordo com o filtro de busca escolhido. (EI4).
● Sequencia de Eventos: Fluxo de Exceção 1 – Sem registros da busca
Ação do Ator Resposta do sistema
1. Usuário digita a URL no navegador.
2. Exibe para o usuário a tela com a listagem de todas as chamadas, ordenadas de forma
Portal ODM Página 25
decrescente de acordo com a data. (EI1).
3. Seleciona opção de filtro de chamadas de acordo com critérios de status e clica no botão “Buscar”. (EI3)
4. Realiza busca no Banco de Dados e, caso não encontre nenhum registro de abertura de chamado com o filtro, exibe para o usuário a mensagem (M1) na mesma tela acima da listagem de chamados (vazia).
Quadro de Mensagens
M1 Nenhum registro foi encontrado.
ESBOÇOS DE INTERFACES
Portal ODM Página 26
● [RF3] – Responder Chamado (Mentor)Atores: Coordenador do Mentoring (Mentor)Pré Condição: Estar visualizando um chamado com estado abertoPós Condições:Visualização da tela de que a resposta foi enviada com sucesso.Descrição: Este caso de uso consiste em realizar a operação do mentor que responde a um chamado, que implicitamente é fechado ao ser respondido.
● Sequencia de Eventos: Fluxo Principal – Responder Chamado pela Listagem de Chamados
Ação do Ator Resposta do sistema
1. Usuário digita a URL de acesso a listagem navegador.
2. Exibe para o usuário a tela com a listagem de todas as chamadas, ordenadas de forma decrescente de acordo com a data. (E1).
3. Seleciona um chamado com um clique que remete a uma URL de detalhamento do referido chamado
4. Exibe na tela o chamado selecionado. (EI2). O campo de resposta fica disponível se o estado do chamado em visualização estiver aberto.
5. Preenche o campo de resposta com a mensagem e clica no botão "Responder".
6. Exibe na tela a mensagem M1 juntamente com o botão "Voltar para Chamados".
● Sequencia de Eventos: Fluxo Alternativo 1 – Responder chamado pela URL de notificação (pelo E-mail)
Ação do Ator Resposta do sistema
7. Mentor acessa email e clica na URL para visualização do chamado recém aberto.
8. Exibe na tela o chamado selecionado. (EI2). O campo de resposta fica disponível se o estado do chamado em visualização estiver aberto.
9. Preenche o campo de resposta com a mensagem e clica no botão "Responder".
10.Exibe na tela a mensagem M1 juntamente com o botão "Fechar.
Portal ODM Página 27
● Sequencia de Eventos: Fluxo de Exceção 1 – Sem registros da busca
Ação do Ator Resposta do sistema
11. Caso o mentor tenta acessar uma URL inválida para a visualização de um chamado
12. Caso o link esteja corrompido, apresenta a M2 na tela.
13. Clica no botão “Fechar”
14. Fechar a tela.
Quadro de Mensagens
M1 A resposta foi enviada com sucesso! O chamado foi encerrado e o aluno será notificado dentro de alguns instantes.
M2 Não existe chamado correspondente a este protocolo.
ESBOÇOS DE INTERFACES
[RF4] - Visualizar Chamado
Portal ODM Página 28
[RF4.1] - Visualizar Chamado (Aluno)● Atores: Aluno ● Descrição: O objetivo deste caso de uso é permitir que o aluno visualize a resposta de um
chamado que por ele foi aberto.● Pré-Condições: Acessar o link que foi enviado ao email do aluno, quando o chamado for
respondido. ● Pós-Condições: O aluno visualizando a tela de Abrir Chamado.
Fluxo PrincipalAção do Ator Resposta do sistema1. Acessa o link que foi
enviado ao email do mesmo, quando o chamado for respondido pelo Mentor.
2. Captura a URL constante no link e exibe a tela conforme (EI1); o link conterá o número de protocolo gerado quando da abertura do chamado que é chave para acessar e recuperar os dados correspondentes ao aluno no banco; para descrição do número de protocolo veja caso de uso “Abrir Chamado”.
3. Clica no botão “Fechar” 4. Fecha a janela de visualização do chamado pelo Aluno.
Exceção 1Ação do Ator Resposta do sistema
1. Caso o aluno tenta acessar uma URL inválida para a visualização de um chamado
1 Caso o link esteja corrompido, apresenta a M1 na tela.
2 Clica no botão “Fechar” 3. Fechar a tela.
Mensagem
Quadro de Mensagens
M1 Não existe chamado correspondente a este protocolo.
Portal ODM Página 29
ESBOÇOS DE INTERFACE
[RF4.2] - Visualizar Chamado (Mentor)● Atores: Mentor● Descrição: O objetivo deste requisito é permitir que o mentor visualize o chamado que foi
aberto pelo aluno.● Pré-Condições: Acessar o link que foi enviado ao email do mentor ou acessar diretamente o
portal do mentor. ● Pós-Condições: O mentor visualiza o chamado feito pelo aluno.● Fluxo Principal:
Visualizar Chamado (Mentor/Professor(a))Ação do Ator Resposta do sistema5. Acessa o link que foi
enviado ao email do mentoring/professor(a) ou acessa diretamente o portal do mentoring, contendo o chamado do aluno.
6. O mentoring/professor(a) visualiza o chamado feito pelo aluno.
Portal ODM Página 30
ESBOÇOS DE INTERFACE
5.11 Diagrama de Classes
Portal ODM Página 31
5.12 Diagrama Arquitetural
Portal ODM Página 32
5.12.1 Modelo Arquitetural Interna (MVC)
5.13 Banco de dados
Portal ODM Página 33
5.13.1 Modelo conceitual
5.13.2 Modelo lógico
5.13.3 Modelo físicoSegue em anexo.
Portal ODM Página 34
5.14 Conclusão
5.15 Contatos
Thalles RafaelGerente de ProjetoE-mail: ---
xxxxxxxxx Analista de SistemasE-mail: ---
xxxxxxxxx Analista de dados e georeferênciaE-mail: ...
xxxxxxxxxDesignerE-mail: ...
xxxxxxxxxDesenvolvedorE-mail: ...
xxxxxxxxxDesenvolvedorE-mail: ...
Portal ODM Página 35
ANEXOS
Portal ODM Página 36
Portal ODM Página 37