Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Gerenciamento de Diplomas Universitários
Semelhante a Gerenciamento de Diplomas Universitários (20)
Gerenciamento de Diplomas Universitários
- 2. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO PLANO DO PROJETO DE SOFTWARE OO para produtos da Lacertae SW Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como nota para disciplina Gerência de Projetos do curso de graduação em Sistemas de Informação – Bacharelado da Universidade Federal de Sergipe (UFS). Discipina: Gerência de Projetos Docente: Prof. Dr. Rogério Patrício Chagas Equipe: Daiana Joyce, Matheus Costa e Mike Farias São Cristóvão 2016 1
- 4. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 1.0 INTRODUÇÃO 1.1 Âmbito do Projeto O módulo Diploma permite gerenciar o processo de emissão de diplomas para os diversos níveis de ensino. Os módulos Stricto Sensu e Graduação já foram implantados. Nesse momento o foco se dará ao Lato Sensu. No módulo Diploma é possível cadastrar o livro de registro de diplomas, emitir diplomas de forma coletiva e individual, segunda via entre outras funcionalidades. 1.2 Funções principais do produto de software As principais funções do Módulo Diploma são as seguintes: ● Registrar diploma individual; ● Registrar diplomas para um grupo de alunos; ● Cadastrar assinaturas do diploma; ● Auditar a geração de diplomas; ● Auditar a requisição de número de registros; ● Consultar dados do discente; ● Atualizar dados pessoais dos discentes; ● Gerenciar livros de registro de diplomas; ● Buscar registros de diplomas; ● Buscar registros coletivos de diplomas; ● Editar observações do registro do aluno; ● Permitir Remover um Registro de Diploma; ● Imprimir diploma individual; ● Imprimir diploma coletivo; ● Imprimir segunda via de diploma; ● Listar alunos para assinatura no ato da colação. São Cristóvão 2016 3
- 6. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 1.4 Papéis O sistema deve disponibilizar as funções de acordo com os seguintes papéis: ● Gestor de Diplomas Lato, Gestor de Diplomas Stricto e Gestor de Diplomas Graduação são responsáveis pelo gerenciamento dos livros de registro e emissão de diplomas para os seus respectivos níveis de ensino. 1.5 Requisitos comportamentais ou de performance O produto apresentado tem como requisito uma interface de fácil usabilidade e o atendimento às restrições de acesso. Como foi mostrado, usuários com o devido papel terão acesso as funcionalidades específicas no sistema. Ao efetuar o login, será detectado se o usuário tem acesso ao sistema. Quanto à performance, os registros de diploma não poderão ser excluídos do sistema, pois é necessário que fiquem armazenados para consultas posteriores, geração de segunda via, entre outros. Também será garantido que apenas usuários com privilégios de acesso de Gestor de Diploma poderão acessar o módulo e executar as funcionalidades, e ainda o sistema deverá ser acessado completamente via navegador web. 1.6 Gestão e Restrições Técnicas Existem restrições que afetarão a maneira de conduzir o projeto por exemplo os recursos limitados e datas de entrega inflexíveis. Aqui são apontadas as abordagens técnicas do desenvolvimento de software (processo de software utilizados, entre outros). 2.0 ESTIVAMIVAS DO PROJETO Nesta seção, serão apresentadas as estimações de tempo necessário para a realização do projeto baseadas em dados, técnicas e recursos. São Cristóvão 2016 5
- 7. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 2.1 Dados históricos utilizados para as estimações Sendo este o primeiro projeto desta equipe, não existem dados históricos a serem utilizados para as estimações. 2.2 Técnicas de estimação e resultados Para estimar o tempo é necessária a utilização de uma técnica de estimativa. A técnica escolhida em nosso projeto foi a de Lorenz & Kidd, Orientada a Objetos, adotada pela Lacertae Software. 2.2.1 Técnica de estimação Para a utilização da técnica Lorenz & Kidd foi preciso primeiramente realizar uma contagem do total de classeschaves presentes no diagrama de classes de domínio. Classeschaves são classes do Diagrama de Classes de Domínio que estão diretamente ligadas com a regra de negócio, identificadas na elicitação dos requisitos. Após definir o número de classeschave, é preciso classificar o tipo de interface para a aplicação, que poderá ter uma interface baseada em texto, ou uma interface gráfica de usuário convencional, ou uma interface gráfica de usuário complexa, ou até mesmo nenhuma interface gráfica. E cada tipo de interface está associada a um multiplicador (2,0 para nenhuma interface, 2,25 para interface baseada em texto, 2,5 para interface convencional e 3,0 para a interface complexa) que será utilizado para estimar o número de classes de apoio (suporte). Para obter o número estimado de classes de apoio basta calcular a multiplicação entre o número de classeschave e o valor multiplicador relacionado com a interface da aplicação. Em seguida, será necessário multiplicar o número total de classes (classechave + classe de apoio) pelo número médio de unidades de trabalho por classe. Lorenz e Kidd surgerem 15 a 20 pessoasdia por classe. O resultado será a estimativa do tempo necessário para a realização do projeto. São Cristóvão 2016 6
- 8. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 2.3 Resultados Para a realização das estimações através da técnica de Lorenz & Kidd utilizamos o diagrama de Classes de Domínio na figura 2.1. Após a análise do diagrama e das considerações da técnica utilizada, foi possível obter as seguintes conclusões: Figura 2 Diagrama de Classes de Dominíno 1. Quantidade de classes chave: 4 (ResgistroDiploma, ResponsavelAssinatura, ObservaçãoRegistroDiploma, RegistroEntrada); 2. Tipo das classes de suporte: interface concencional; 3. Valor Multiplicador: 2,5; 4. Classes de suporte: 4 (classes chave) x 2,5 (Valor multiplicador) = 10 classes de suporte; 5. Total de classes: 4 (chave) + 10 (suporte) = 14; 6. Número médio de unidades de trabalho: 20 diaspessoa; 7. Tempo previsto: 14 (classes) x 20 (dias) = 280 dias por pessoa para a construção das classes. Tendo em vista que a equipe é formada por 3 integrantes chegase ao total de aproximadamente 93 dias; São Cristóvão 2016 7
- 9. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 8. Como um mês possui em média 22 dias úteis, feriados e pontos facultativos, o tempo total do projeto será de 4 meses e 5 dias. 2.3.1 Resultados no Projeto Real Esse projeto foi executado no Núcleo de Tecnologia da Informação da Universidade Federal de Sergipe. Nesse projeto a equipe de desenvolvimento foi formada por cinco membros, como segue abaixo o cálculo de estimações. 1. Quantidade de classes chave: 4; 2. Tipo das classes de suporte: interface concencional; 3. Valor Multiplicador: 2,5; 4. Classes de suporte: 4 (classes chave) x 2,5 (Valor multiplicador) = 10 classes de suporte; 5. Total de classes: 4 (chave) + 10 (suporte) = 14; 6. Número médio de unidades de trabalho: 20 diaspessoa; 7. Tempo previsto: 14 (classes) x 20 (dias) = 280 dias por pessoa para a construção das classes.A equipe foi formada por 5 integrantes chegase ao total de aproximadamente 56 dias; 8. Como um mês possui em média 22 dias úteis, feriados e pontos facultativos, o tempo total do projeto será de 2 meses e 12 dias. 2.4 Recursos do projeto Nesta secção serão especificados os recursos necessários para realização do projeto. Os recursos foram divididos em 3 (três) categorias, humanos, de software e de hardware. 2.4.1 Recursos Humanos Os profissionais necessários para o desenvolvimento deste projeto são os seguintes: ● 01 Gerente de Projeto; ● 02 Analista de Sistemas; ● 01 Analista de Testes; ● 02 Programador; ● 02 Testador. São Cristóvão 2016 8
- 10. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Como a equipe só dispõe de apenas 3 (três) integrantes, alguns papéis terão incomum a mesma pessoa. 2.4.2 Recursos de Software O projeto irá utilizar os seguintes recursos de software: ● PostgreSQL: permitirá a gerência do banco de dados usado na composição do produto final; ● Eclipse/Java: IDE e linguagem de programação a ser utilizada na implementação do produto de software final; ● OpenOffice e Microsoft Word: editores de texto usados na documentação, relatórios e documentos afins; ● Smart Sheet: gerenciador de projetos que servirá de base para gestão atualizada e confiável do projeto do produto; ● SVN: ferramenta utilizada para o controle de versão a ser utilizado para permitir desenvolvimento distribuído do software; ● StarUML: ambiente de modelagem dos diagramas UML; ● Mozila Firefox: navegador web; ● JBoss 4.2: servidor HTTP. 2.4.3 Recursos de Hardware Deverão ser utilizados 3 estações de trabalhos com a seguinte configuração de hardware: ● Processador Intel® Core™ i76500U Processor (4M Cache, up to 3.10 GHz) ou superior; ● 4 GB de memória RAM ou superior; ● 500 GB de armazenamento ou superior; ● 2 telas de 17 polegadas ou superior. 3.0 Análise e Gestão de Riscos Nesta seção serão apresentados os possíveis riscos do projeto e como serão gerenciados. São Cristóvão 2016 9
- 11. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 3.1 Riscos do projeto Riscos Projeto Técnico Negócio Comum Especial Não conseguir reutilizar o código desse projeto. x x Cliente não tem muito tempo para levantamento de requisitos x Perda de algum dado do banco de dados x Problemas com Interação entre sistemas diferentes x x Perda de membros da equipe x x O produto pode ser alterado depois da entrega x Custos associados ao mal funcionamento da ferramenta utilizada no desenvolvimento x Expectativas não satisfeitas x Pouco treinamento da equipe x x Baixo conhecimento prévio dos usuários x x Quadro 1 Riscos do projeto 3.2 Tabela de riscos Tabela com os riscos identificados a sua probabilidade de ocorrência e impacto esperado. São Cristóvão 2016 10
- 12. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Riscos % Probabilidade Impacto Não conseguir reutilizar o código desse projeto. 75% Catastrófico Cliente não tem muito tempo para levantamento de requisitos 75% Catastrófico Perda de algum dado do banco de dados 75% Catastrófico Falta de conhecimento do negócio 75% Catastrófico Problemas com Interação entre sistemas diferentes 30% Crítico Perda de membros da equipe 30% Crítico O produto pode ser alterado depois da entrega 30% Crítico Custos associados ao mal funcionamento da ferramenta utilizada no desenvolvimento 10% Marginal Ponto de corte Expectativas não satisfeitas 10% Marginal Pouco treinamento da equipe 10% Marginal Baixo conhecimento prévio dos usuários 10% Marginal Desenvolvedores não possuem tempo integral para desenvolvimento do produto 30% Crítico São Cristóvão 2016 11
- 13. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Quadro 2 Riscos do projeto identificando probabilidade 3.3 Redução e Gestão do Risco Para garantir a Redução, Supervisão e Gestão dos Riscos (RSGR) foram utilizadas as seguintes estratégias. 1 Não conseguir reutilizar o código desse projeto. Probabilidade: 75% Impacto: Catastrófico Descrição: Haverá uma reutilização de código, pois esse sistema já existe aplicado a outros níveis de ensino. Estratégia de Redução: Avaliação do módulo já implantado. Plano de Contigência: Devese identificar as prioridades do projeto e negociar um prazo maior. O projeto também deve ser remodelado de acordo com as tecnologias dominadas pelos integrantes. Responsável: Daiana Joyce Status: Em andamento Quadro 3 Estratégia de redução e gestão de risco 2 Cliente não tem muito tempo para levantamento de requisitos Probabilidade: 75% Impacto: Catastrófico Descrição: Cliente não tempo muito tempo disponível para discutir os requisitos do projeto. Estratégia de Redução: Prepararse bem para a entrevista, gravála para consultas futuras e seguir notas e depoimentos no projeto. Plano de Contigência: Solicitar ao cliente que indique uma pessoa disponível para esta etapa do projeto. Esta pessoal deve conhecer o negócio e saber expressar o que o São Cristóvão 2016 12
- 14. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO cliente deseja. Responsável: Matheus Status: Em andamento Quadro 4 Estratégia de redução e gestão de risco 3 Problemas com Interação entre sistemas diferentes Probabilidade: 30% Impacto: Crítico Descrição: O módulo Diploma deverá comunicarse diretamente com o módulo Lato Sensu. Estratégia de Redução: Realizar uma ampla gama de testes para garantir o funcionamento correto. Plano de Contigência: Corrigir as falhas detectadas na fase de testes. Responsável: Mike Status: Em andamento Quadro 5 Estratégia de redução e gestão de risco 4 Perda de membros da equipe Probabilidade: 30% Impacto: Crítico Descrição: Há apenas 3 pessoas envolvidas no projeto e não há garantia que todos permaneçam até o final do projeto Estratégia de Redução: Integrantes devem se reunir regularmente para que possam acompanhar o trabalho um do outro. Além disso, devem compartilhar os artefatos disponíveis e resultados atingidos para que possam motivar os integrantes a permanecerem no projeto até o final. Plano de Contigência: Caso um integrante saia, devese identificar as prioridades do projeto, negociar um prazo maior com a promessa de entregar incrementos neste período. São Cristóvão 2016 13
- 15. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Responsável: Daiana Joyce Status: Em andamento Quadro 6 Estratégia de redução e gestão de risco 5 O produto pode ser alterado depois da entrega Probabilidade: 30% Impacto: Crítico Descrição: Ápos a entrega o cliente pode solicitar mais alterações que estão fora do escopo. Estratégia de Redução: Criar protótipo para validar os requisitos e também criar um Documento de Escopo, acordando tudo que será entregue no projeto. Plano de Contigência: Ampliar o escopo, redefinindo prazos e valores do projeto. Responsável: Matheus Status: Em andamento Quadro 7 Estratégia de redução e gestão de risco 6 Custos associados ao mau funcionamento das ferramentas utilizadas no desenvolvimento Probabilidade: 10% Impacto: Marginal Descrição: Peda de tempo útil ocasionada por problemas (configuração ou mal funcionamento) acasionados por ferramentas utilizadas no desenvolvimento do produto de software. Estratégia de Redução: Pesquisar, analisar e testar a utilização destas ferramentas em projetos de terceiros, quais os prós e possíveis contras. Plano de Contigência: Suspender a utilização da ferramenta e se possível passar a utilizar outra semelhante. Responsável: Mike Status: Em Andamento São Cristóvão 2016 14
- 16. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Quadro 8 Estratégia de redução e gestão de risco 7 Expectativas não satisfeitas Probabilidade: 10% Impacto: Marginal Descrição: Apesar do acompanhemento do cliente no densevolvimento do produto de sofware, o mesmo pode não ficar satisfeito com o que foi entregue. Estratégia de Redução: Verificar quais são as expectativas do cliente, e separálas por nível de importância e buscar sempre alcançar as mais importantes. Plano de Contigência: Buscar no próximo projeto satisfazer as expectativas do cliente. Responsável: Matheus Status: Em andamento Quadro 9 Estratégia de redução e gestão de risco 8 Perda de algum dado do banco de dados. Probabilidade: 75% Impacto: Catastrófico Descrição: Possibilidade de haver alguma falha no banco de dados e perder dados importantes. Estratégia de Redução: Utilizar espelhamento de banco de dados. Plano de Contigência: Fazer uso periódico de backup Responsável: Mike Status:Em andamento Quadro 10 Estratégia de redução e gestão de risco 9 Pouco treinamento da equipe São Cristóvão 2016 15
- 17. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Probabilidade: 10% Impacto: Marginal Descrição: Integrantes não possuem treinamento necessário Estratégia de Redução: Utilizar cursos online, fóruns na internet e orientação de profissionais da área Plano de Contigência: Contratar cursos e treinamento para os integrantes Responsável: Daiana Joyce Status: Em andamento Quadro 11 Estratégia de redução e gestão de risco 10 Baixo conhecimento prévio dos usuários Probabilidade: 10% Impacto: Marginal Descrição: A equipe não tem conhecimeno prévio dos usuários. Estratégia de Redução: A equipe deve manter contato com os usuáris ápos as reuniões, para se necessário sanar qualquer dúvida, mesmo antes das reuniões definidas. Plano de Contigência: Aumentar o número de reuniões. Responsável: Mike Status: Em andamento Quadro 12 Estratégia de redução e gestão de risco 11 Desenvolvedores não possuem tempo integral para desenvolvimento do produto Probabilidade: 30% Impacto: Crítico Descrição: Integrantes realizam outras atividades e não podem se dedicar exclusivamente ao projeto. Estratégia de Redução: Evitar desperdício de tempo e recursos São Cristóvão 2016 16
- 18. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Plano de Contigência: Fazer bom uso do tempo disponível e utilizar ferramentas de nuvem que possibilitem alterações por múltiplas pessoas em tempo rel. Responsável: Daiana Joyce Status: Em andamento Quadro 13 Estratégia de redução e gestão de risco 12 Falta de conhecimento do negócio Probabilidade: 75% Impacto: Ctastrófico Descrição: Negócio do projeto é desconhecido por todos os integrantes Estratégia de Redução: Estudar a respeito do negócio e motivar a participação do cliente no projeto. Plano de Contigência: Contatar o cliente sempre que necessário Responsável: Mike Status: Em andamento Quadro 14 Estratégia de redução e gestão de risco 4.0 Planejamento Temporal Nesta seção serão apresentadas as tarefas e as suas dependências estimando a duração total do projeto. 4.1 Conjunto de Tarefas do Projeto No desenvolvimento do módulo Diploma, para o nível de ensino Lato Sensu, foi utilizado o modelo de processo incremental e iterativo, utilizando a metodologia ágil Scrum. As tarefas do projeto podem ser visualizadas nas seções 1.2 e 1.3, Funções principais do produto de software e Diagrama de Caso de Uso, respectivamente. São Cristóvão 2016 17
- 19. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO 4.2 Diagrama de Gantt O diagrama de Gant tem como objetivo disponibilizar aos membros da equipe todo o planejamento do projeto, considerando prazos e atribuições, de forma visual e de fácil compreensão. O desenvolvimento do diagrama de gantt do projeto foi baseada na metodologia Scrum, a mesma metodologia utilizada na execução do projeto. O tempo estimado para cada etapada do projeto não foi baseada na estimativa 4/2/4 (RequisitosAnáliseDesenho 40% / Geração de Código 20% / Testes 40%) sugerida pela literatura de Engenharia de Software, por dois motivos discutidos entre os membros da equipe: ● O uso da metodologia Scrum, na qual o desenvolvimento de software visa o atendimento das necessidades do cliente e realizar entregas do projeto em partes(sprints) para validação do cliente, que pode resultar em mudanças no planejamento; e ● Considerando a experiência no mercado em desenvolvimento dos membros da equipe, na qual o tempo gasto no desenvolvimento do software sempre demanda mais tempo que todas as outras etapas. A figura 1, apresenta as 4 etapas planejadas para execução e finalização do projeto: Planejamento, Especificação do Projeto, Desenvolvimento e Transição. Em cada etapa, são descritas as tarefas que devem ser executadas, os membros da equipe responsáveis pela execução, data início e data fim para execução, total de dias para execução da tarefa e ao lado uma linha do tempo de execução da tarefa dentro dos prazos definidos para cada tarefa. A linha do tempo citada anteriormente, que caracteriza um diagrama de gantt, tem início no dia 20 de janeiro de 2016 e encerra no dia 25/05/2016, tempo estimado para execução e finalização do projeto. Para preservar a legibilidade do diagramas, a linha temporal não foi apresentada completamente. Mas a Figura 1, Figura 2 e diagrama completo São Cristóvão 2016 18
- 20. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO podem ser acessados através do link: https://drive.google.com/folderview?id=0B8yfhL4YTZTGdFJKdXNsSGZYSHc &usp=sharing . Figura 1 Diagrama de Gantt Resumido. Farias, Mike (2016). A figura 2, apresenta as 4 sprints, apresentadas anteriormente, de forma expandida. Cada sprint possue suas respectivas tarefas e um tempo médio de execução de 17 dias. São Cristóvão 2016 19
- 21. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Figura 2 Diagrama de Gantt Expandido. Farias, Mike (2016). 5.0 Organização do Pessoal Nesta seção será apresentada a forma de distribuição dos recursos humanos no projeto e qual a função das pessoas envolvidas de acordo com o perfil necessário para o seu desempenho. 5.1 Estrutura da equipe Para execução do projeto contaremos com a participação de 3 (três) integrantes que desempenharão papéis necessários para garantir o andamentos e o sucesso final do projeto. Abaixo veremos a tabela 4.1, onde são descritas as responsabilidades de cada papel, seu responsável e o perfil necessário para ocupar este papel. São Cristóvão 2016 20
- 22. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Responsável Papel Descrição Perfil Daiana Joyce Gerente de Projeto Responsável pela alocação de recursos, ajuste de prioridades, coordenação das interações entre clientes e usuários, manter o foco da equipe na meta, e acompanhar as atividades executadas pela equipe do projeto. ● Possuir experiência em gerência de projetos, análise, gerenciamento de riscos, estimativas e planejamento. ● Ter bom relacionamento interpessoal. ● Possui capacidade de liderança. Matheus Costa e Mike Santos Analista de Sistemas Responsável pelo levantamento de requisitos e atividades de análise e projeto no qual irá elaborar todos os diagramas necessários para a implementação (codificação) do produto de software. ● Ter bom conhecimento do negócio. ● Comunicarse bem. Daiana Joyce Analista de Testes Responsável por identificar e definir os teste necessários, monitorar a abrangência dos testes e avaliar a qualidade obtida ao realizar os testes. ● Ser atencioso e detalhista. ● Conhecer bem o domínio do produto de software. ● Possuir exepriência em esforços de teste. Matheus Costa e Mike Santos Programador Responsável pela implementação do produto de software. ● Possuir experiência em coficiação. Matheus Costa e Daiana Joyce Testador Responsável pela realização dos testes sistémicos. ● Possuir experiência em testes. Tabela 4.1 5.2 Mecanismos de comunicação A comunicação foi por meio de reuniões semanais entre os membros da equipe. Estas reuniões serviram para discutir o andamento do projeto. Entre cada reunião, qualquer dúvida em relação ao projeto deverá ser exposta por meio de São Cristóvão 2016 21
- 23. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO um grupo de email a ser criado pela gerente do projeto e composto por todos os membros da equipe. 5.3 Uso do Edublog como ferramenta de apoio A utilização do Edublog fez com que nossa equipe compreendesse as principais metodologias ágeis que são utilzidas diariamente por várias empresas. E a partir deste aprendizado adquirido tentamos encaixálo na execução deste projeto. O Edublog facilitou também na interação entre nossa equipe e as outras esquipes da disciplina, fazendo com que adiquiríssemoos conhecimento sobre os assuntos abordados pelas outras equipes. Como por exemplo, a utilização de ferramentas para o gerenciamento de um projeto, ou a utilização da computação em nuvem para auxiliar no desenvolvimento de um produto de software. Este jeito fácil e empolgante de aprender sobre outros assuntos de diversas áreas por meio de uma ferramenta deste tipo só veio a somar no aprendizado desta equipe. 6.0 Precauções tomadas para assegurar e controlar a qualidade do produto de software Dentre as medidas utilizadas para assegurar e controlar a qualidade do produto de SW, destacamse a utilização da ferramenta SVN para controle de versão e a utilização de conceitos presentes na metodologia ágil Scrum. A ferramenta SVN foi utilizada para garantir o controle de todas as versões do produto e para o trabalho em conjunto de toda a equipe. Na utilização de conceitos presentes no Scrum, foi possível interagir de forma efetiva com o cliente, desde a análise de requisitos até a validação das 4 sprints (partes entregáveis do produto de sw). Cada sprint passou por revisão, testes e validação do usuário. São Cristóvão 2016 22