SlideShare une entreprise Scribd logo
1  sur  31
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Portal de Ingressos UFS
Plano do Projeto de Software
Aniel Bispo da Cruz
Igor Gonçalves Antão
Jardel Santos Nascimento
Jonathan Kelvin de Jesus Santos
Luiz Gabriel Gusmão Santos
Mayara Santos Machado
Prof. Dr. Rogério Patrício Chagas do Nascimento.
São Cristóvão - Sergipe
Janeiro de 2019
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Aniel B. da Cruz
Igor G. Antao
Jardel S. Nascimento
Jonathan K. de J. Santos
Luiz G. G. Santos
Mayara S. Machado
Portal de Ingressos UFS
Plano de Projeto de Software apresentado ao
Prof. Dr. Rogério Patrício Chagas do
Nascimento como requisito da disciplina de
Gerência de Projeto.
Orientador: Prof. Dr. Rogério Patrício Chagas
do Nascimento.
São Cristóvão - Sergipe
Janeiro de 2019
1
Histórico de Alterações
Data Versão Descrição Autor(es)
29/11/2018 0.1 Introdução,​ ​Brainstorm ​para a Análise de Riscos Todos
06/12/2018 0.2 Brainstorm ​Gestão de Projetos de SW OO: métricas,
estimação e planificação
Todos
20/12/2018 1.0 Estimação do projeto Todos
15/01/2018 1.0.1 Transcrição da organização pessoal Todos
20/03/2019 1.1 Ajustes pós-reunião com Prof. Dr. Rogério Patrício Todos
2
Sumário
Sumário 3
Lista de Ilustrações 4
Lista de tabelas 4
Lista de quadros 5
Lista de abreviaturas e siglas 6
1. Introdução 7
1.1. Âmbito do Projeto 7
1.2. Funções principais do produto de software 9
1.3. Requisitos comportamentais ou de performance 1​0
1.4. Gestão e Restrições Técnicas 1​1
2. Estimações do Projeto 1​1
2.1. Dados históricos utilizados para as estimações 1​1
2.2. Técnicas de estimação e resultados 1​1
2.2.1. Técnica de estimação 1​1
2.2.2. Resultados 1​2
2.3. Recursos do projeto 1​3
2.3.1. Recursos humanos 1​3
2.3.2. Recursos de Software 1​4
2.3.3. Recursos de Hardware 1​4
3. Análise e Gestão de Riscos 1​5
3.1. Riscos do Projeto 1​5
3.2. Redução e Contingência de Riscos 1​6
4. Planejamento Temporal 2​1
4.1. Conjunto de Tarefas do Projeto 2​1
4.2. Diagrama de Gantt 2​5
5. Organização do Pessoal 2​8
5.1. Estrutura da Equipe 2​8
5.2. Mecanismos de Comunicação 2​8
5.3. Uso do Edu-blog como Ferramenta de Apoio 2​8
6. Precauções tomadas para assegurar e controlar a qualidade do produto de
software 2​9
Referências 30
3
Lista de Ilustrações
Figura 1 ​- Diagrama de Casos de Uso
Figura 2 ​- Diagrama de Classes
Figura 3​ - Diagrama de Gantt - Portal de Ingressos UFS
Lista de tabelas
Tabela 1 ​- Principais funções de acordo com o ator
Tabela 2​ - Multiplicadores da Métrica Lorenz & Kidd.
Tabela 3​ - Riscos Identificados no Projeto
Tabela 4​ - Fases do Projeto e Tarefas Associadas
Tabela 5 ​- Estrutura da Equipe
4
Lista de quadros
Quadro 1​ - Quadro de Redução e Contingência do Risco 1
Quadro 2​ - Quadro de Redução e Contingência do Risco 2
Quadro 3 ​- Quadro de Redução e Contingência do Risco 3
Quadro 4​ - Quadro de Redução e Contingência do Risco 4
Quadro 5​ - Quadro de Redução e Contingência do Risco 5
Quadro 6​ - Quadro de Redução e Contingência do Risco 6
Quadro 7​ - Quadro de Redução e Contingência do Risco 7
Quadro 8​ - Quadro de Redução e Contingência do Risco 8
Quadro 9​ - Quadro de Redução e Contingência do Risco 9
Quadro 10​ - Quadro de Redução e Contingência do Risco 10
5
Lista de abreviaturas e siglas
Significado Sigla/Abreviação
Ambiente de Desenvolvimento Integrado
Integrated Development Environment
IDE
Exame Nacional do Ensino Médio ENEM
Interface Gráfica do Usuário
Graphical User Interface
GUI
Linhas de Código
Lines of Code
LOC
Núcleo de Tecnologia da Informação NTI
Processo Seletivo P.S.
Sistema de Gerenciamento de Banco de Dados SGBD
Sistema Integrado de Gestão de Atividades
Acadêmicas
SIGAA
Sistema de Seleção Unificada SISU
Software SW
Universidade Federal de Sergipe UFS
6
1. Introdução
O Projeto de ​software, ​abordado neste documento, ​constitui em um portal de
ingressos. O objetivo é concentrar todo o processo de matrícula dos alunos ingressantes dos
cursos de graduação da Universidade Federal de Sergipe (UFS). Atualmente existem três
formas de ingresso na UFS: o Sistema de Seleção Unificada (SISU), o Processo Seletivo para
os Cursos de Música e Letras em Libras e o Processo Seletivo Campus Sertão.
Essa necessidade surgiu por conta do funcionamento atual do Processo Seletivo na
UFS. O SISU é a principal forma de ingresso aos cursos de graduação e por esse motivo o
número de alunos a serem matriculados é alto. Esse fenômeno acaba causando
congestionamento no Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA). Pois
uma parte desse processo é feita manualmente, demandando tempo e recursos, devido a
dependência de “mão de obra” específica.
Além disso, o atual sistema responsável pelo processo foi desenvolvido às pressas,
sem documentação adequada, o que dificulta a manutenibilidade e consequentemente o
desempenho do sistema.
A ideia do projeto é desenvolver um sistema que automatize e agilize esse processo.
Com isso, reduzir erros e o congestionamento do SIGAA no período de matrículas. Ao
atender todas as formas de ingresso aos cursos de graduação oferecidos pela UFS.
O desenvolvimento do portal, além de trazer agilidade ao processo, trará garantia de
segurança com a automatização. Visto que apenas a etapa de validação de documentos
necessitará de uma pessoa responsável que pode ser substituída.
1.1. Âmbito do Projeto
O Projeto de ​Software ​constitui em um Portal de Ingressos onde serão publicados
todos os editais de matrícula, juntamente com a informação dos prazos de realização de cada
etapa. Estas etapas são:
1. Divulgação das lista de aprovados;
2. Confirmação dos dados e envio das cópias dos documentos pelos candidatos;
3. Entrega presencial dos documentos originais e validação dos dados;
4. Exportação dos dados dos matriculados para o SIGAA.
7
Neste portal serão ser inseridos os dados dos alunos que participaram dos processos
seletivos (SISU, P.S. Licenciatura em música e em letras Libras e P.S. Campus Sertão). Após
os dados constarem no sistema, serão enviados ​links ​para os candidatos que foram
aprovados, com o objetivo de realizar a etapa 2. O ​link ​dará acesso a um formulário com os
dados do próprio candidato para que o mesmo possa confirmar se estão corretos. Caso hajam
divergências, os candidatos poderão corrigi-las preenchendo/alterando os campos do
formulário. Além disso, os candidatos deverão anexar os documentos digitalizados exigidos
no edital. Ao confirmar os dados, o sistema confirmará a pré-matrícula desse candidato. As
vagas do candidatos que não confirmarem os dados no prazo serão colocadas como ociosas e
disponibilizadas para a lista de espera.
Uma aba para o administrador do sistema exibirá uma listagem dos candidatos que
estão com o ​status ​de pré-matriculados. Nesta tela, durante a etapa 3, o funcionário delegado
irá selecionar o formulário do candidato para validar os dados informados com os
documentos originais apresentados. Se existir algum erro, um novo ​link ​poderá ser enviado
para o candidato corrigir e retornar, desde que dentro do prazo. Quando os dados estiverem
corretos um funcionário da UFS irá confirmar a matrícula e o sistema mudará o ​status ​do
aluno​ ​para matriculado.
No dia e hora determinado, o sistema exportará os dados dos alunos matriculados
para o SIGAA. A partir daí, os alunos poderão realizar seus cadastros para ter acesso ao
mesmo.
Ao fim dessa etapa regular, serão importados no sistema os dados dos candidatos
que estão na lista de espera. O sistema irá organizar a lista considerando a quantidade de
vagas ociosas por curso e a ordem de classificação dos alunos, obedecendo às regra dispostas
no edital do SISU. Essas listas serão divulgadas no portal e os alunos que forem classificados
irão participar do mesmo processo de matrícula da primeira chamada. Esse processo ficará
repetindo até que todas as vagas, de todos os cursos, estejam preenchidas ou não houver
candidatos na lista de espera.
O sistema exibirá para o administrador as vagas ociosas por curso, para o caso de
não haver mais candidatos na lista de espera.
8
1.2. Funções principais do produto de software
As funções principais do produto de ​software ​são descritas, de um modo geral, pelo
diagrama de casos de uso na Figura 1.
Esse diagrama demonstra como os participantes do processo de matrícula,
denominados atores, se relacionam com as funcionalidades do produto de ​software​. Esses
atores podem ser indivíduos (Aluno), departamentos e seus administradores (PROGRAD e
CCV) e ​softwares ​(SIGAA).
Figura 1: ​Diagrama de Casos de Uso
9
A Tabela 1 descreve as principais funções desempenhadas pelo sistema de acordo
com o ator responsável pela ação.
Função Ator
Disponibilizar os editais de ingresso PROGRAD
Validar dados de matrícula PROGRAD
Finalizar matrícula PROGRAD
Controlar vagas CCV
Divulgar lista de aprovados CCV
Importar dados dos processos CCV
Realizar processamento de lista de espera CCV
Confirmar dados de matrícula Aluno
Realizar confirmação de matrícula Aluno
Enviar documentos digitalizados Aluno
Integrar dados SIGAA
Tabela 1: ​Principais funções de acordo com o ator
1.3. Requisitos comportamentais ou de performance
Os requisitos tratados a seguir são conhecidos como requisitos não-funcionais e tem o
intuito de prover características de qualidade ao produto de ​software​. Consideramos os
seguintes requisitos para o Portal de Ingressos:
● Usabilidade
○ O ​software ​terá uma interface intuitiva e de fácil uso.
● Confiabilidade
○ As informações disponibilizadas pelos atores devem permanecer confiáveis
durante todo processo de matrícula.
● Desempenho
○ O envio dos dados para o SIGAA, para a validação e finalização da matrícula,
deve ser feito em um horário de pouco acesso, de preferência a noite. Evitando
a concorrência de recursos.
● Segurança
○ O ​software ​deve prover autenticação para os usuários de acordo com os níveis
de acesso;
○ Após o prazo de cada etapa do processo de matrícula, as mesmas ficarão
indisponíveis.
10
1.4. Gestão e Restrições Técnicas
A metodologia de desenvolvimento a ser utilizada será Desenvolvimento Ágil.
Atualmente é uma metodologia que vem ganhando bastante espaço no mercado e aos poucos
vem sendo utilizada no Núcleo de Tecnologia da Informação (NTI) da UFS.
Enquanto a linguagem será Java, esta que hoje é a mais utilizada no NTI. A
necessidade desse alinhamento com as tecnologias utilizadas se dá pois, após a entrega do
software​, a responsabilidade de manutenção do mesmo fica a cargo do NTI.
Com relação a data de entrega, está previsto que no processo seletivo de 2020.1
estejam prontos pelo menos os módulos e funcionalidades necessários para a matrícula.
Contudo, está previsto que testes já sejam realizados no processo seletivo que ocorre em
2019.2 no Campus Itabaiana.
2. Estimações do Projeto
Esta seção fornece as estimativas de esforço e tempo.
2.1. Dados históricos utilizados para as estimações
Não existe projetos anteriores desenvolvidos pela equipe, portanto não houve como
utilizar dados históricos para a estimação.
2.2. Técnicas de estimação e resultados
Para estimar o tempo foi necessária a utilização de uma técnica de estimativa. A
técnica escolhida foi a de Lorenz & Kidd [3], orientada a objetos, adotada pela Lacertae
Software.
2.2.1. Técnica de estimação
A técnica de estimação Lorenz & Kidd [3] utilizada no projeto para o sistema
do Portal de Ingressos UFS consiste em:
1. Determinar a quantidade de classes chave do projeto;
2. Encontrar o número de classes de suporte, classificando o tipo de
interface do produto e utilizando os multiplicadores correspondentes
para as classes de suporte;
3. Multiplicar a quantidade de classes​ chave pelo multiplicador
correspondente para estimar o número de classes de suporte;
4. Multiplicar o total de classes (chave + suporte) pelo número médio de
unida des de trabalho (dias/​pessoas) por classe;
5. Calcular o tempo previsto para a realização do projeto.
11
Na Tabela 2 constam os multiplicadores utilizados para as classes de suporte.
Interface Multiplicador
Não Gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI Complexa 3
Tabela 2 - ​Multiplicadores da Métrica Lorenz & Kidd.
2.2.2. Resultados
Usamos como base o diagrama de classes do projeto da Figura 2.
Figura 2 ​- Diagrama de Classes
12
A partir do diagrama da Figura 2, identificamos:
1. Classes Chave: Aluno, ListaEspera, ListaAprovados, Formulario, Documentos,
ProcessoSeletivo, Edital, Cotas, Etapa, TecnicoUfs, Matricula.
Total: 11 Classes Chaves;
2. Tipo das classes de suporte: ​Interface Baseada em Texto;
3. Valor Multiplicador referente a interfaces baseadas em texto, seguindo a Tabela 2:
2,25;
4. Classes de suporte: 11 (chave) x 2,25 (multiplicador) = ​24,75 classes de suporte;
5. Total de classes: 11 (classes chave) + 24,75 (classes suporte) = ​35,75;
6. Número médio de unidades de trabalho: ​20 dias/​pessoa​. O valor de 20 dias é
conseguido levando em consideração as métricas de Lorenz-Kidd usadas ao longo do
projeto. De acordo com aquelas métricas, o número de dias-pessoa varia de 15 a 20, a
depender da experiência dos desenvolvedores. Como o projeto será desenvolvido por
alunos, e não por profissionais, optou-se pelo valor de 20 dias-pessoa​;
7. Tempo previsto: 35,75 (classes) x 20 (dias) = ​715 dias ​para a construção das classes;
8. Como a equipe de programadores é formada por 7 pessoas, chega-​se ao total de
aproximadamente ​103 dias​;
9. Com isso, tem-se que o tempo total de projeto é 103/22 = 4,7 meses , considerando
que um mês tem 22 dias úteis e também levando em conta pontos facultativos e
feriados. Porém, os desenvolvedores envolvidos no projeto trabalharão apenas 20
horas semanais, a metade da carga horária de trabalho padrão. Com isso,
multiplicamos o resultado encontrado por 2 e obtivemos o tempo total do projeto de
9,4 meses ​de 22 dias, com 4 horas diárias.
2.3. Recursos do projeto
Recursos humanos, de ​software ​e ​hardware​, ferramentas de apoio e outros recursos
necessários são listados nesta seção.
2.3.1. Recursos humanos
Os profissionais envolvidos no desenvolvimento deste projeto são os
seguintes:
● 01 Gerente de Projeto;
● 02 Orientadores;
● 07 Programadores.
13
2.3.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;
● Google Docs: editores de texto usados na documentação, relatórios e
documentos afins;
● GitBucket: ferramenta utilizada para o controle de versão do ​software;
● StarUML: ambiente de modelagem dos diagramas UML;
● Mozilla Firefox: navegador web.
2.3.3. Recursos de ​Hardware
O projeto irá utilizar os seguintes recursos de ​hardware​:
● Computadores;
● Servidor.
14
3. Análise e Gestão de Riscos
Em um projeto de ​software ​a ocorrência de eventos, conhecidos como riscos, pode
causar perda de recursos ou até o cancelamento do mesmo. Por conta disso, há a necessidade
da Análise e Gestão de Riscos.
A gestão de risco, segundo Harold Kerzner [4], é um meio de identificar e medir
riscos de forma organizada. Com essa gestão é possível selecionar e gerenciar opções para
lidar com esses eventos quando eles de fato acontecerem.
Esta seção apresenta a descrição e os planos de redução e contingência dos riscos
identificados no projeto.
3.1. Riscos do Projeto
A ​Tabela 3 é proveniente de um ​brainstorming ​e uma análise circular entre os
membros do grupo. A tabela apresenta os possíveis riscos encontrados e seus tipos, definidos
por PRESSMAN [2], ​em ordem decrescente de impacto e probabilidade.
Nº Risco Tipo Impacto Porcentagem
1 Saída de membros durante o projeto Staff/People Crítico 60%
2 Grande estimativa de transações Product Size Crítico 50%
3 Interoperabilidade com sistema legado Business impact Crítico 40%
4 Alteração nas regras de negócio Business impact Crítico 40%
5 Comprometimento da equipe Staff/People Crítico 30%
6 Difícil manutenabilidade Business impact Crítico 20%
7 Requisitos mal compreendidos Due to the
Customer
Marginal 40%
8 Tamanho subestimado Staff/People Marginal 40%
9 Falta à equipe domínio das tecnologias Staff/People Marginal 40%
Tabela 3 - ​Riscos Identificados no Projeto
15
3.2. Redução e Contingência de Riscos
Com o objetivo de antecipar e minimizar os problemas decorrentes dos riscos listados
na Tabela 3, foram traçados os Planos para Redução, Supervisão e Contingência de Riscos.
Esses planos foram representados em 11 quadros, um para cada risco identificado, seguindo a
ordem exposta na Tabela 3.
Risco:​ Saída de membros durante o projeto
Código:​ 001 Impacto:​ Crítico Probabilidade:​ 60%
Descrição: Membros da equipe saírem no meio do projeto. Mesmo com a chamada de
novos membros, causaria problemas no desenvolvimento do projeto visto que, os novos
membros precisam de tempo para adaptação.
Estratégia de redução: Desenvolvimento de uma documentação e processos de
treinamento como cursos e material didático para melhor adaptação de novos membros,
assim como a inclusão de um plano de acompanhamento do membro que vai sair da equipe
ao novo componente do time.
Plano de contingência: Manter lista com os candidatos excedentes do processo de seleção.
E solicitar que o membro sainte entregue uma documentação que sirva de referência para
que o novo integrante situe-se no projeto.
Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento
Status:​ Simulação incompleta
Quadro 1 ​- Quadro de Redução e Contingência do Risco 1
16
Risco:​ Grande estimativa de transações
Código:​ 002 Impacto:​ ​Crítico Probabilidade:​ 50%
Descrição: Grande estimativa de transações e sobrecarga nos servidores, considerando o
grande número de matrículas realizadas no período. O volume de dados pode causar
congestionamento nas operações devido aos limites de ​hardware​. Assim, causando mau
funcionamento do sistema em produção.
Estratégia de redução: Já no planejamento, prevendo essa possibilidade, elaborar um bom
Projeto de Banco de Dados. Definir as tecnologias, como SGBD, de forma que suportem
com folga as estimativas. Além disso, o controle de transações e a realização de testes de
estresse e desempenho podem-se mostrar úteis.
Plano de contingência: Realizar mudanças na execução de procedimentos que sejam
gargalos para o sistema (como o cálculo de classificação) para horários fora do intervalo de
atendimento. Realizar migração dos dados para outro SGBD.
Pessoa responsável:​ Alberto C. Neto
Status:​ Simulação incompleta
Quadro 2 ​- Quadro de Redução e Contingência do Risco 2
Risco:​ Interoperabilidade com sistema legado
Código:​ 003 Impacto:​ ​Crítico Probabilidade:​ 40%
Descrição: Possíveis conflitos com o sistema do SIGAA podem causar impacto na
conexão entre bases do sistema, considerando o tamanho e regras particulares da aplicação
legada.
Estratégia de redução: Desenvolver o projeto com o acompanhamento do NTI. Assim,
como o NTI detém maior conhecimento acessível a respeito do SIGAA, o projeto poderá
ser desenvolvido da melhor forma possível.
Plano de contingência:​ Buscar ajuda e alinhamento com o NTI.
Pessoa responsável:​ Marcos B. Dósea
Status:​ Simulação incompleta
Quadro 3 ​- Quadro de Redução e Contingência do Risco 3
17
Risco:​ Alteração nas regras de negócio
Código:​ 004 Impacto:​ Crítico Probabilidade:​ 40%
Descrição: É necessário considerar as constantes mudanças das regras de seleção já
anunciadas e ou possíveis no processo seletivo ao longo dos anos.
Estratégia de redução: Planejar o desenvolvimento dos módulos de forma que, caso haja
mudanças nas regras de negócio (editais nos quais serão baseadas as funcionalidades), a
adaptação seja a mais simples possível.
Plano de contingência: Adaptar o ​software às novas regras de negócios. Aplicar, quando
possível, os módulos do sistema de forma gradativa nos processos de seleção.
Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento
Status:​ Simulação incompleta
Quadro 4 ​- Quadro de Redução e Contingência do Risco 4
Risco:​ Comprometimento da equipe
Código:​ 005 Impacto:​ Crítico Probabilidade:​ 30%
Descrição: Como a equipe que desenvolverá o projeto é composta por alunos, sabemos que
não poderão dedicar-se exclusivamente ao projeto. Assim, é possível que demandas
externas como provas, trabalhos e atividades extracurriculares possam diminuir a
produtividade dos membros e atrasar o cronograma.
Estratégia de redução: Priorizar as partes mais importantes do projeto. Criar um sistema
de rotação dos membros, de forma que possam ser alocados em partes menos importantes
enquanto sobrecarregados.
Plano de contingência: Em casos onde não haja a possibilidade de realocação, outro aluno
deve ser chamado a partir da lista de espera da seleção.
Pessoa responsável:​ Alberto C. Neto
Status:​ Simulação incompleta
Quadro 5 ​- Quadro de Redução e Contingência do Risco 5
18
Risco:​ Difícil manutenabilidade
Código:​ 006 Impacto:​ Crítico Probabilidade:​ 20%
Descrição: Devido à inexperiência da equipe, pode haver problemas com código-fonte e
documentação. Assim, atrapalhando a evolução e correção de erros dos sistema, bem como
a circulação de informações.
Estratégia de redução: Cobrar dos programadores e responsáveis que desenvolvam a
documentação em conjunto com a codificação. Adotar técnicas de revisão de código, com
intuito de melhorar a qualidade do código.
Plano de contingência:​ Exigir preparo e entrega de documentação.
Pessoa responsável:​ Marcos B. Dósea
Status:​ Simulação incompleta
Quadro 6 ​- Quadro de Redução e Contingência do Risco 6
Risco:​ Requisitos mal compreendidos
Código:​ 007 Impacto:​ Marginal Probabilidade:​ 40%
Descrição:​ Dificuldade dos projetistas em compreender os requisitos passados pelos
usuários na fase inicial do projeto ou durante o desenvolvimento. Com isso, acarretando em
atraso de entregáveis e na dificuldade de gerenciar mudanças do projeto.
Estratégia de redução: Manter o processo de desenvolvimento com acompanhamento dos
stakeholders​, assim haverá menores chances de que algum requisito mal entendido passe
despercebido. Estabelecer processo de registro de solicitação de alterações, documentando
assim as mudanças exigidas pelos ​stakeholders​.
Plano de contingência:​ Validar as alterações dos requisitos solicitadas através de
alinhamento com os ​stakeholders​.
Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento
Status:​ Simulação incompleta
Quadro 7 ​- Quadro de Redução e Contingência do Risco 7
19
Risco:​ Tamanho subestimado
Código:​ 008 Impacto:​ Marginal Probabilidade:​ 30%
Descrição: Os projetistas não prevêem de maneira adequada o tempo necessário para
realização do projeto, causando atrasos na sua entrega.
Estratégia de redução: Utilizar o modelo de desenvolvimento iterativo e incremental.
Garantir que as estimativas do projeto sejam seguidas. Além disso, definir prioridades de
modo que as partes essenciais estejam prontas no tempo previsto.
Plano de contingência: Realizar acompanhamento periódico da evolução do projeto,
evitando que problemas que possam atrapalhar o andamento do desenvolvimento sejam
mitigados. Renegociar os prazos de entrega.
Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento
Status:​ Simulação incompleta
Quadro 8 ​- Quadro de Redução e Contingência do Risco 8
Risco:​ Falta à equipe domínio das tecnologias
Código:​ 009 Impacto:​ Marginal Probabilidade:​ 40%
Descrição:​ O processo de seleção dos alunos não exigiu colaboradores com experiência
suficiente nas tecnologias utilizadas no projeto. Pode ser necessário dedicar tempo do
projeto para corrigir a curva de conhecimento, causando atrasos no cronograma.
Estratégia de redução: Treinamento de pessoal com cursos e outras ferramentas de
ensino. Divisão das equipes de acordo com a experiência, de forma que os mais experientes
possam dar apoio aos demais. Busca de mentores do mercado de trabalho ou de programa
de mestrado da área de tecnologia que possam orientar, de forma voluntária, os alunos
integrantes do projeto.
Plano de contingência:​ Realizar treinamento da equipe com as tecnologias necessárias
para o desenvolvimento do projeto. Caso seja possível, estender o treinamento para os
candidatos que ficaram de reserva para a colaboração do projeto.
Pessoa responsável:​ Marcos B. Dósea
Status:​ Simulação incompleta
Quadro 9 ​- Quadro de Redução e Contingência do Risco 9
20
4. Planejamento Temporal
4.1. Conjunto de Tarefas do Projeto
Na fase inicial do projeto foram utilizados 16 dias para as atividades de Planejamento
e Projeto. O método de estimativa de Lorenz & Kidd [3] usado anteriormente na seção
“Estimações do Projeto” resultou num total necessário de 9,4 meses de 22 dias, ou 206 dias,
para as atividades de Desenvolvimento e Testes, divididos em 13 ​sprints​ de 15 dias.
Também foi reservado um período de 21 dias para as atividades de Implantação.
A Tabela 4 mostra uma representação das fases do projeto e a relação de atividades
relacionadas a cada uma delas.
21
Fase do Projeto Atividades
Planejamento e Projeto 1. Visão Geral do Projeto de Software;
2. Levantamento de Requisitos;
3. Criação do Diagrama de Casos de Uso;
4. Criação do Diagrama de Classes de Domínio;
5. Estimação e Planificação do Projeto;
6. Elaboração da Análise de Riscos;
7. Definição do Product Backlog;
8. Preparação do Ambiente de Desenvolvimento;
Desenvolvimento e Testes 9. Preparação do Banco de Dados;
10. Sprint Plannings da Sprint 1;
11. Implementação do Caso de Uso Confirmação de
Matrícula;
12. Testes Unitários;
13. Testes de Integração;
14. Revisão da Sprint;
15. Retrospectiva da Sprint;
16. Sprint Planning da Sprint 2;
17. Implementação do Caso de Uso Envio de Documentos;
18. Testes Unitários;
19. Testes de Integração;
20. Revisão da Sprint;
21. Retrospectiva da Sprint;
22. Sprint Planning da Sprint 3;
23. Implementação dos Casos de Uso Reenvio de
Documentos;
24. Testes Unitários;
25. Testes de Integração;
22
26. Revisão da Sprint;
27. Retrospectiva da Sprint;
28. Sprint Planning da Sprint 4;
29. Implementação do Caso de Uso Controle de Vagas;
30. Testes Unitários;
31. Testes de Integração;
32. Revisão da Sprint;
33. Retrospectiva da Sprint;
34. Sprint Planning da Sprint 5;
35. Implementação do Caso de Uso Integração dos Dados
pelo SIGAA;
36. Testes Unitários;
37. Testes de Integração;
38. Revisão da Sprint;
39. Retrospectiva da Sprint;
40. Sprint Planning da Sprint 6;
41. Implementação do Caso de Uso Validação de Dados de
Matrícula;
42. Testes Unitários;
43. Testes de Integração;
44. Revisão da Sprint;
45. Retrospectiva da Sprint;
46. Sprint Planning da Sprint 7;
47. Implementação do Caso de Uso Disponibilização de
Editais;
48. Testes Unitários;
49. Testes de Integração;
50. Revisão da Sprint;
51. Retrospectiva da Sprint;
52. Sprint Planning da Sprint 8;
53. Implementação dos Casos de Uso Manter Etapas do
23
Processo Seletivo;
54. Testes Unitários;
55. Testes de Integração;
56. Revisão das Sprint;
57. Retrospectiva das Sprint;
58. Sprint Planning da Sprint 9;
59. Implementação do Caso de Uso Controle de Vagas;
60. Testes Unitários;
61. Testes de Integração;
62. Revisão das Sprint;
63. Retrospectiva da Sprint;
64. Sprint Planning da Sprint 10;
65. Implementação do Caso de Uso Processamento da
Lista de Espera;
66. Testes Unitários;
67. Testes de Integração;
68. Revisão da Sprint;
69. Retrospectiva da Sprint;
70. Sprint Planning da Sprint 11;
71. Implementação do Caso de Uso Importação de Dados
dos Processos;
72. Testes Unitários;
73. Testes de Integração;
74. Revisão da Sprint;
75. Retrospectiva da Sprint;
76. Sprint Planning da Sprint 12
77. Implementação do Caso de Uso Divulgação da Lista de
Aprovados;
78. Testes Unitários;
79. Testes de Integração;
24
80. Revisão da Sprint;
81. Retrospectiva da Sprint;
82. Preparação do Banco de Dados;
83. Sprint Planning da Sprint 13;
84. Implementação do Caso de Uso Acompanhamento de
Processos;
85. Testes Unitários;
86. Testes de Integração;
87. Revisão da Sprint;
88. Retrospectiva da Sprint;
Implantação 89. Documentação do Projeto;
90. Manual do Usuário;
91. Montagem do pacote executável;
Tabela 4 - ​Fases do Projeto e Tarefas Associadas
4.2. Diagrama de Gantt
O diagrama de Gantt descreve o período de execução das atividades necessárias para a
consecução do produto final, bem como a distribuição das mesmas sobre o tempo.
O diagrama de Gantt resultado do processo de estimativa neste projeto é bastante
extenso para ser incluído neste documento de forma confortável para a leitura. Dessa forma,
ele está disponível de forma compactada na Figura 3, mas deve ser melhor analisado no
seguinte ​hiperlink​: ​https://bit.ly/2TZ0n1J​.
25
26
Figura 3 ​- Diagrama de Gantt - Portal Ingressos UFS
27
5. Organização do Pessoal
5.1. Estrutura da Equipe
A equipe responsável pelo desenvolvimento do projeto é representada na Tabela 5. A
tabela mostra os integrantes e seus papéis no desenvolvimento do projeto.
Responsável Papel Descrição
Prof. Dr. Rogério P. C. do
Nascimento
Coordenador/Gerente de
Projetos
Planejar e gerir a execução
dos projetos.
Alberto C. Neto Orientador/​Scrum Master ​1 Módulo de processamento de
ingressos.
Marcos B. Dósea Orientador/​Scrum Master ​2 Módulo Web do Portal.
Claudio L. L. Carvalho Programador 1 Codificar e/ou manutenir.
Diego R. Santos Programador 2 Codificar e/ou manutenir.
João A. M. Junior Programador 3 Codificar e/ou manutenir.
Antonio C. M. P. Junior Programador 4 Codificar e/ou manutenir.
Geovanne S. Atanazio Programador 5 Codificar e/ou manutenir.
Tiago A. de Farias Programador 6 Codificar e/ou manutenir.
Victor S. Vieira Programador 7 Codificar e/ou manutenir.
Tabela 5 - ​Estrutura da Equipe
5.2. Mecanismos de Comunicação
Os mecanismos de comunicação que utilizamos, basicamente, foram Telegram e
Google Drive. As discussões quando não presenciais, foram feitas através de um grupo no
Telegram. Enquanto na criação de diagramas e do plano em conjunto, utilizamos o Draw.io e
o Docs com Google Drive.
5.3. Uso do Edu-blog como Ferramenta de Apoio
O uso do Edu-blog [1] na disciplina proporcionou que adquiríssemos conhecimentos
que, se fossem passados em sala de aula, poderiam ser bem maçantes. Dessa forma,
aprendemos muito sobre nosso tema proposto, pesquisando para escrever no ​blog​. E, ao
mesmo tempo, aprendemos um pouco de cada tema através das pesquisas de cada grupo.
Conhecemos ferramentas úteis, como o Trello e GitHub, e metodologias de desenvolvimento
28
de ágil como Scrum e Kanban. Ferramentas que foram/poderiam ter sido usadas no
desenvolvimento do projeto.
6. Precauções tomadas para assegurar e controlar a qualidade
do produto de ​software
Esta seção descreve as medidas previstas para que possa ser mantida a qualidade do
software​.
● Controle de versão
Plano de versionamento do projeto para garantir que as alterações realizadas sejam
controladas. Assim, planejadas em versões de entrega que possam ser revertidas em possíveis
falhas em novas funcionalidades.
● Testes unitários
Tem a função de manter a corretude do código através de testes em frações do código.
Esses testes são feitos a partir de classes com apenas esse intuito. Garantindo que
funcionalidades e trechos de código tenham sido testados de forma única e automática, e que
de código de teste não sejam esquecidos no código-fonte.
29
Referências
[1] Edu-blog > GP | UFS 2018. Disponível em:<​https://gp-ufs.blogspot.com/​>
[2] PRESSMAN, R. S. Engenharia de Software - 7.ed. McGraw Hill Brasil, 2009
[3] LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide.
Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994.
[4] Kerzner, H. Gestão de Projetos - As Melhores Práticas - 3ª Ed. 2016
30

Contenu connexe

Similaire à Plano de Projetos Portal de Ingressos UFS

Plano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWPlano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWrafahreis
 
Gestão da Tecnologia da Informação (27/02/2014): Status Report do TCC
Gestão da Tecnologia da Informação (27/02/2014): Status Report do TCCGestão da Tecnologia da Informação (27/02/2014): Status Report do TCC
Gestão da Tecnologia da Informação (27/02/2014): Status Report do TCCAlessandro Almeida
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWInstituto Federal de Sergipe
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWMatheus Costa
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONIocfelipe
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de SoftwareLeonardo Felipe
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRaffonsosouza
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisadoJorge Barreto
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONIocfelipe
 
[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report
[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report
[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status ReportAlessandro Almeida
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de SoftwareMatheus Mendonça
 
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Urique Hoffmann
 
Apresentação do SCAD, Sistema Académico do DIEE
Apresentação do SCAD, Sistema Académico do DIEEApresentação do SCAD, Sistema Académico do DIEE
Apresentação do SCAD, Sistema Académico do DIEEalexculpado
 
plano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhoplano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhouserrx
 

Similaire à Plano de Projetos Portal de Ingressos UFS (20)

Plano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWPlano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SW
 
Gestão da Tecnologia da Informação (27/02/2014): Status Report do TCC
Gestão da Tecnologia da Informação (27/02/2014): Status Report do TCCGestão da Tecnologia da Informação (27/02/2014): Status Report do TCC
Gestão da Tecnologia da Informação (27/02/2014): Status Report do TCC
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
 
Modelo plano projeto de sw oo
Modelo plano projeto de sw ooModelo plano projeto de sw oo
Modelo plano projeto de sw oo
 
Manual gp eg_versao_final
Manual gp eg_versao_finalManual gp eg_versao_final
Manual gp eg_versao_final
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBR
 
Plano de Projeto SGS
Plano de Projeto SGSPlano de Projeto SGS
Plano de Projeto SGS
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisado
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
 
[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report
[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report
[SIN-NA7] Gestão de Projetos e Empreendedorismo - Atividade: Status Report
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
 
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
 
Apresentação do SCAD, Sistema Académico do DIEE
Apresentação do SCAD, Sistema Académico do DIEEApresentação do SCAD, Sistema Académico do DIEE
Apresentação do SCAD, Sistema Académico do DIEE
 
plano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhoplano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunho
 
Plano de projeto - Gerência de Projetos
Plano de projeto - Gerência de ProjetosPlano de projeto - Gerência de Projetos
Plano de projeto - Gerência de Projetos
 
Plano de projeto
Plano de projetoPlano de projeto
Plano de projeto
 
Tcc - Work control
Tcc - Work controlTcc - Work control
Tcc - Work control
 

Dernier

PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...Colaborar Educacional
 
Caça palavras - BULLYING
Caça palavras  -  BULLYING  Caça palavras  -  BULLYING
Caça palavras - BULLYING Mary Alvarenga
 
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdfARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdfItaloAtsoc
 
Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024gilmaraoliveira0612
 
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxQUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxAntonioVieira539017
 
Cruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegyptiCruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegyptiMary Alvarenga
 
arte retrato de um povo - Expressão Cultural e Identidade Nacional
arte retrato de um povo - Expressão Cultural e Identidade Nacionalarte retrato de um povo - Expressão Cultural e Identidade Nacional
arte retrato de um povo - Expressão Cultural e Identidade Nacionalidicacia
 
Poder do convencimento,........... .
Poder do convencimento,...........         .Poder do convencimento,...........         .
Poder do convencimento,........... .WAGNERJESUSDACUNHA
 
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptxSlides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptxLuizHenriquedeAlmeid6
 
Depende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxDepende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxLuzia Gabriele
 
A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...
A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...
A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...Unidad de Espiritualidad Eudista
 
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdfRitoneltonSouzaSanto
 
Aula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptxAula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptxMarceloDosSantosSoar3
 
Como fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de GestoresComo fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de GestoresEu Prefiro o Paraíso.
 
Apresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptxApresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptxtaloAugusto8
 
autismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entenderautismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entenderLucliaResende1
 
Trabalho DAC História 25 de Abril de 1974
Trabalho DAC História 25 de Abril de 1974Trabalho DAC História 25 de Abril de 1974
Trabalho DAC História 25 de Abril de 1974AnaRitaFreitas7
 

Dernier (20)

Abordagem 3. Análise interpretativa (Severino, 2013)_PdfToPowerPoint.pdf
Abordagem 3. Análise interpretativa (Severino, 2013)_PdfToPowerPoint.pdfAbordagem 3. Análise interpretativa (Severino, 2013)_PdfToPowerPoint.pdf
Abordagem 3. Análise interpretativa (Severino, 2013)_PdfToPowerPoint.pdf
 
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
 
Caça palavras - BULLYING
Caça palavras  -  BULLYING  Caça palavras  -  BULLYING
Caça palavras - BULLYING
 
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdfARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
 
Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024
 
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxQUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
 
Cruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegyptiCruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegypti
 
arte retrato de um povo - Expressão Cultural e Identidade Nacional
arte retrato de um povo - Expressão Cultural e Identidade Nacionalarte retrato de um povo - Expressão Cultural e Identidade Nacional
arte retrato de um povo - Expressão Cultural e Identidade Nacional
 
Poder do convencimento,........... .
Poder do convencimento,...........         .Poder do convencimento,...........         .
Poder do convencimento,........... .
 
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptxSlides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
 
Depende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxDepende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsx
 
A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...
A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...
A Congregação de Jesus e Maria, conhecida também como os Eudistas, foi fundad...
 
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
 
Aula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptxAula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptx
 
Como fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de GestoresComo fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de Gestores
 
Apresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptxApresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptx
 
Abordagem 1. Análise textual (Severino, 2013).pdf
Abordagem 1. Análise textual (Severino, 2013).pdfAbordagem 1. Análise textual (Severino, 2013).pdf
Abordagem 1. Análise textual (Severino, 2013).pdf
 
autismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entenderautismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entender
 
Trabalho DAC História 25 de Abril de 1974
Trabalho DAC História 25 de Abril de 1974Trabalho DAC História 25 de Abril de 1974
Trabalho DAC História 25 de Abril de 1974
 
Abordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdf
Abordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdfAbordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdf
Abordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdf
 

Plano de Projetos Portal de Ingressos UFS

  • 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Portal de Ingressos UFS Plano do Projeto de Software Aniel Bispo da Cruz Igor Gonçalves Antão Jardel Santos Nascimento Jonathan Kelvin de Jesus Santos Luiz Gabriel Gusmão Santos Mayara Santos Machado Prof. Dr. Rogério Patrício Chagas do Nascimento. São Cristóvão - Sergipe Janeiro de 2019
  • 2. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Aniel B. da Cruz Igor G. Antao Jardel S. Nascimento Jonathan K. de J. Santos Luiz G. G. Santos Mayara S. Machado Portal de Ingressos UFS Plano de Projeto de Software apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como requisito da disciplina de Gerência de Projeto. Orientador: Prof. Dr. Rogério Patrício Chagas do Nascimento. São Cristóvão - Sergipe Janeiro de 2019 1
  • 3. Histórico de Alterações Data Versão Descrição Autor(es) 29/11/2018 0.1 Introdução,​ ​Brainstorm ​para a Análise de Riscos Todos 06/12/2018 0.2 Brainstorm ​Gestão de Projetos de SW OO: métricas, estimação e planificação Todos 20/12/2018 1.0 Estimação do projeto Todos 15/01/2018 1.0.1 Transcrição da organização pessoal Todos 20/03/2019 1.1 Ajustes pós-reunião com Prof. Dr. Rogério Patrício Todos 2
  • 4. Sumário Sumário 3 Lista de Ilustrações 4 Lista de tabelas 4 Lista de quadros 5 Lista de abreviaturas e siglas 6 1. Introdução 7 1.1. Âmbito do Projeto 7 1.2. Funções principais do produto de software 9 1.3. Requisitos comportamentais ou de performance 1​0 1.4. Gestão e Restrições Técnicas 1​1 2. Estimações do Projeto 1​1 2.1. Dados históricos utilizados para as estimações 1​1 2.2. Técnicas de estimação e resultados 1​1 2.2.1. Técnica de estimação 1​1 2.2.2. Resultados 1​2 2.3. Recursos do projeto 1​3 2.3.1. Recursos humanos 1​3 2.3.2. Recursos de Software 1​4 2.3.3. Recursos de Hardware 1​4 3. Análise e Gestão de Riscos 1​5 3.1. Riscos do Projeto 1​5 3.2. Redução e Contingência de Riscos 1​6 4. Planejamento Temporal 2​1 4.1. Conjunto de Tarefas do Projeto 2​1 4.2. Diagrama de Gantt 2​5 5. Organização do Pessoal 2​8 5.1. Estrutura da Equipe 2​8 5.2. Mecanismos de Comunicação 2​8 5.3. Uso do Edu-blog como Ferramenta de Apoio 2​8 6. Precauções tomadas para assegurar e controlar a qualidade do produto de software 2​9 Referências 30 3
  • 5. Lista de Ilustrações Figura 1 ​- Diagrama de Casos de Uso Figura 2 ​- Diagrama de Classes Figura 3​ - Diagrama de Gantt - Portal de Ingressos UFS Lista de tabelas Tabela 1 ​- Principais funções de acordo com o ator Tabela 2​ - Multiplicadores da Métrica Lorenz & Kidd. Tabela 3​ - Riscos Identificados no Projeto Tabela 4​ - Fases do Projeto e Tarefas Associadas Tabela 5 ​- Estrutura da Equipe 4
  • 6. Lista de quadros Quadro 1​ - Quadro de Redução e Contingência do Risco 1 Quadro 2​ - Quadro de Redução e Contingência do Risco 2 Quadro 3 ​- Quadro de Redução e Contingência do Risco 3 Quadro 4​ - Quadro de Redução e Contingência do Risco 4 Quadro 5​ - Quadro de Redução e Contingência do Risco 5 Quadro 6​ - Quadro de Redução e Contingência do Risco 6 Quadro 7​ - Quadro de Redução e Contingência do Risco 7 Quadro 8​ - Quadro de Redução e Contingência do Risco 8 Quadro 9​ - Quadro de Redução e Contingência do Risco 9 Quadro 10​ - Quadro de Redução e Contingência do Risco 10 5
  • 7. Lista de abreviaturas e siglas Significado Sigla/Abreviação Ambiente de Desenvolvimento Integrado Integrated Development Environment IDE Exame Nacional do Ensino Médio ENEM Interface Gráfica do Usuário Graphical User Interface GUI Linhas de Código Lines of Code LOC Núcleo de Tecnologia da Informação NTI Processo Seletivo P.S. Sistema de Gerenciamento de Banco de Dados SGBD Sistema Integrado de Gestão de Atividades Acadêmicas SIGAA Sistema de Seleção Unificada SISU Software SW Universidade Federal de Sergipe UFS 6
  • 8. 1. Introdução O Projeto de ​software, ​abordado neste documento, ​constitui em um portal de ingressos. O objetivo é concentrar todo o processo de matrícula dos alunos ingressantes dos cursos de graduação da Universidade Federal de Sergipe (UFS). Atualmente existem três formas de ingresso na UFS: o Sistema de Seleção Unificada (SISU), o Processo Seletivo para os Cursos de Música e Letras em Libras e o Processo Seletivo Campus Sertão. Essa necessidade surgiu por conta do funcionamento atual do Processo Seletivo na UFS. O SISU é a principal forma de ingresso aos cursos de graduação e por esse motivo o número de alunos a serem matriculados é alto. Esse fenômeno acaba causando congestionamento no Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA). Pois uma parte desse processo é feita manualmente, demandando tempo e recursos, devido a dependência de “mão de obra” específica. Além disso, o atual sistema responsável pelo processo foi desenvolvido às pressas, sem documentação adequada, o que dificulta a manutenibilidade e consequentemente o desempenho do sistema. A ideia do projeto é desenvolver um sistema que automatize e agilize esse processo. Com isso, reduzir erros e o congestionamento do SIGAA no período de matrículas. Ao atender todas as formas de ingresso aos cursos de graduação oferecidos pela UFS. O desenvolvimento do portal, além de trazer agilidade ao processo, trará garantia de segurança com a automatização. Visto que apenas a etapa de validação de documentos necessitará de uma pessoa responsável que pode ser substituída. 1.1. Âmbito do Projeto O Projeto de ​Software ​constitui em um Portal de Ingressos onde serão publicados todos os editais de matrícula, juntamente com a informação dos prazos de realização de cada etapa. Estas etapas são: 1. Divulgação das lista de aprovados; 2. Confirmação dos dados e envio das cópias dos documentos pelos candidatos; 3. Entrega presencial dos documentos originais e validação dos dados; 4. Exportação dos dados dos matriculados para o SIGAA. 7
  • 9. Neste portal serão ser inseridos os dados dos alunos que participaram dos processos seletivos (SISU, P.S. Licenciatura em música e em letras Libras e P.S. Campus Sertão). Após os dados constarem no sistema, serão enviados ​links ​para os candidatos que foram aprovados, com o objetivo de realizar a etapa 2. O ​link ​dará acesso a um formulário com os dados do próprio candidato para que o mesmo possa confirmar se estão corretos. Caso hajam divergências, os candidatos poderão corrigi-las preenchendo/alterando os campos do formulário. Além disso, os candidatos deverão anexar os documentos digitalizados exigidos no edital. Ao confirmar os dados, o sistema confirmará a pré-matrícula desse candidato. As vagas do candidatos que não confirmarem os dados no prazo serão colocadas como ociosas e disponibilizadas para a lista de espera. Uma aba para o administrador do sistema exibirá uma listagem dos candidatos que estão com o ​status ​de pré-matriculados. Nesta tela, durante a etapa 3, o funcionário delegado irá selecionar o formulário do candidato para validar os dados informados com os documentos originais apresentados. Se existir algum erro, um novo ​link ​poderá ser enviado para o candidato corrigir e retornar, desde que dentro do prazo. Quando os dados estiverem corretos um funcionário da UFS irá confirmar a matrícula e o sistema mudará o ​status ​do aluno​ ​para matriculado. No dia e hora determinado, o sistema exportará os dados dos alunos matriculados para o SIGAA. A partir daí, os alunos poderão realizar seus cadastros para ter acesso ao mesmo. Ao fim dessa etapa regular, serão importados no sistema os dados dos candidatos que estão na lista de espera. O sistema irá organizar a lista considerando a quantidade de vagas ociosas por curso e a ordem de classificação dos alunos, obedecendo às regra dispostas no edital do SISU. Essas listas serão divulgadas no portal e os alunos que forem classificados irão participar do mesmo processo de matrícula da primeira chamada. Esse processo ficará repetindo até que todas as vagas, de todos os cursos, estejam preenchidas ou não houver candidatos na lista de espera. O sistema exibirá para o administrador as vagas ociosas por curso, para o caso de não haver mais candidatos na lista de espera. 8
  • 10. 1.2. Funções principais do produto de software As funções principais do produto de ​software ​são descritas, de um modo geral, pelo diagrama de casos de uso na Figura 1. Esse diagrama demonstra como os participantes do processo de matrícula, denominados atores, se relacionam com as funcionalidades do produto de ​software​. Esses atores podem ser indivíduos (Aluno), departamentos e seus administradores (PROGRAD e CCV) e ​softwares ​(SIGAA). Figura 1: ​Diagrama de Casos de Uso 9
  • 11. A Tabela 1 descreve as principais funções desempenhadas pelo sistema de acordo com o ator responsável pela ação. Função Ator Disponibilizar os editais de ingresso PROGRAD Validar dados de matrícula PROGRAD Finalizar matrícula PROGRAD Controlar vagas CCV Divulgar lista de aprovados CCV Importar dados dos processos CCV Realizar processamento de lista de espera CCV Confirmar dados de matrícula Aluno Realizar confirmação de matrícula Aluno Enviar documentos digitalizados Aluno Integrar dados SIGAA Tabela 1: ​Principais funções de acordo com o ator 1.3. Requisitos comportamentais ou de performance Os requisitos tratados a seguir são conhecidos como requisitos não-funcionais e tem o intuito de prover características de qualidade ao produto de ​software​. Consideramos os seguintes requisitos para o Portal de Ingressos: ● Usabilidade ○ O ​software ​terá uma interface intuitiva e de fácil uso. ● Confiabilidade ○ As informações disponibilizadas pelos atores devem permanecer confiáveis durante todo processo de matrícula. ● Desempenho ○ O envio dos dados para o SIGAA, para a validação e finalização da matrícula, deve ser feito em um horário de pouco acesso, de preferência a noite. Evitando a concorrência de recursos. ● Segurança ○ O ​software ​deve prover autenticação para os usuários de acordo com os níveis de acesso; ○ Após o prazo de cada etapa do processo de matrícula, as mesmas ficarão indisponíveis. 10
  • 12. 1.4. Gestão e Restrições Técnicas A metodologia de desenvolvimento a ser utilizada será Desenvolvimento Ágil. Atualmente é uma metodologia que vem ganhando bastante espaço no mercado e aos poucos vem sendo utilizada no Núcleo de Tecnologia da Informação (NTI) da UFS. Enquanto a linguagem será Java, esta que hoje é a mais utilizada no NTI. A necessidade desse alinhamento com as tecnologias utilizadas se dá pois, após a entrega do software​, a responsabilidade de manutenção do mesmo fica a cargo do NTI. Com relação a data de entrega, está previsto que no processo seletivo de 2020.1 estejam prontos pelo menos os módulos e funcionalidades necessários para a matrícula. Contudo, está previsto que testes já sejam realizados no processo seletivo que ocorre em 2019.2 no Campus Itabaiana. 2. Estimações do Projeto Esta seção fornece as estimativas de esforço e tempo. 2.1. Dados históricos utilizados para as estimações Não existe projetos anteriores desenvolvidos pela equipe, portanto não houve como utilizar dados históricos para a estimação. 2.2. Técnicas de estimação e resultados Para estimar o tempo foi necessária a utilização de uma técnica de estimativa. A técnica escolhida foi a de Lorenz & Kidd [3], orientada a objetos, adotada pela Lacertae Software. 2.2.1. Técnica de estimação A técnica de estimação Lorenz & Kidd [3] utilizada no projeto para o sistema do Portal de Ingressos UFS consiste em: 1. Determinar a quantidade de classes chave do projeto; 2. Encontrar o número de classes de suporte, classificando o tipo de interface do produto e utilizando os multiplicadores correspondentes para as classes de suporte; 3. Multiplicar a quantidade de classes​ chave pelo multiplicador correspondente para estimar o número de classes de suporte; 4. Multiplicar o total de classes (chave + suporte) pelo número médio de unida des de trabalho (dias/​pessoas) por classe; 5. Calcular o tempo previsto para a realização do projeto. 11
  • 13. Na Tabela 2 constam os multiplicadores utilizados para as classes de suporte. Interface Multiplicador Não Gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI Complexa 3 Tabela 2 - ​Multiplicadores da Métrica Lorenz & Kidd. 2.2.2. Resultados Usamos como base o diagrama de classes do projeto da Figura 2. Figura 2 ​- Diagrama de Classes 12
  • 14. A partir do diagrama da Figura 2, identificamos: 1. Classes Chave: Aluno, ListaEspera, ListaAprovados, Formulario, Documentos, ProcessoSeletivo, Edital, Cotas, Etapa, TecnicoUfs, Matricula. Total: 11 Classes Chaves; 2. Tipo das classes de suporte: ​Interface Baseada em Texto; 3. Valor Multiplicador referente a interfaces baseadas em texto, seguindo a Tabela 2: 2,25; 4. Classes de suporte: 11 (chave) x 2,25 (multiplicador) = ​24,75 classes de suporte; 5. Total de classes: 11 (classes chave) + 24,75 (classes suporte) = ​35,75; 6. Número médio de unidades de trabalho: ​20 dias/​pessoa​. O valor de 20 dias é conseguido levando em consideração as métricas de Lorenz-Kidd usadas ao longo do projeto. De acordo com aquelas métricas, o número de dias-pessoa varia de 15 a 20, a depender da experiência dos desenvolvedores. Como o projeto será desenvolvido por alunos, e não por profissionais, optou-se pelo valor de 20 dias-pessoa​; 7. Tempo previsto: 35,75 (classes) x 20 (dias) = ​715 dias ​para a construção das classes; 8. Como a equipe de programadores é formada por 7 pessoas, chega-​se ao total de aproximadamente ​103 dias​; 9. Com isso, tem-se que o tempo total de projeto é 103/22 = 4,7 meses , considerando que um mês tem 22 dias úteis e também levando em conta pontos facultativos e feriados. Porém, os desenvolvedores envolvidos no projeto trabalharão apenas 20 horas semanais, a metade da carga horária de trabalho padrão. Com isso, multiplicamos o resultado encontrado por 2 e obtivemos o tempo total do projeto de 9,4 meses ​de 22 dias, com 4 horas diárias. 2.3. Recursos do projeto Recursos humanos, de ​software ​e ​hardware​, ferramentas de apoio e outros recursos necessários são listados nesta seção. 2.3.1. Recursos humanos Os profissionais envolvidos no desenvolvimento deste projeto são os seguintes: ● 01 Gerente de Projeto; ● 02 Orientadores; ● 07 Programadores. 13
  • 15. 2.3.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; ● Google Docs: editores de texto usados na documentação, relatórios e documentos afins; ● GitBucket: ferramenta utilizada para o controle de versão do ​software; ● StarUML: ambiente de modelagem dos diagramas UML; ● Mozilla Firefox: navegador web. 2.3.3. Recursos de ​Hardware O projeto irá utilizar os seguintes recursos de ​hardware​: ● Computadores; ● Servidor. 14
  • 16. 3. Análise e Gestão de Riscos Em um projeto de ​software ​a ocorrência de eventos, conhecidos como riscos, pode causar perda de recursos ou até o cancelamento do mesmo. Por conta disso, há a necessidade da Análise e Gestão de Riscos. A gestão de risco, segundo Harold Kerzner [4], é um meio de identificar e medir riscos de forma organizada. Com essa gestão é possível selecionar e gerenciar opções para lidar com esses eventos quando eles de fato acontecerem. Esta seção apresenta a descrição e os planos de redução e contingência dos riscos identificados no projeto. 3.1. Riscos do Projeto A ​Tabela 3 é proveniente de um ​brainstorming ​e uma análise circular entre os membros do grupo. A tabela apresenta os possíveis riscos encontrados e seus tipos, definidos por PRESSMAN [2], ​em ordem decrescente de impacto e probabilidade. Nº Risco Tipo Impacto Porcentagem 1 Saída de membros durante o projeto Staff/People Crítico 60% 2 Grande estimativa de transações Product Size Crítico 50% 3 Interoperabilidade com sistema legado Business impact Crítico 40% 4 Alteração nas regras de negócio Business impact Crítico 40% 5 Comprometimento da equipe Staff/People Crítico 30% 6 Difícil manutenabilidade Business impact Crítico 20% 7 Requisitos mal compreendidos Due to the Customer Marginal 40% 8 Tamanho subestimado Staff/People Marginal 40% 9 Falta à equipe domínio das tecnologias Staff/People Marginal 40% Tabela 3 - ​Riscos Identificados no Projeto 15
  • 17. 3.2. Redução e Contingência de Riscos Com o objetivo de antecipar e minimizar os problemas decorrentes dos riscos listados na Tabela 3, foram traçados os Planos para Redução, Supervisão e Contingência de Riscos. Esses planos foram representados em 11 quadros, um para cada risco identificado, seguindo a ordem exposta na Tabela 3. Risco:​ Saída de membros durante o projeto Código:​ 001 Impacto:​ Crítico Probabilidade:​ 60% Descrição: Membros da equipe saírem no meio do projeto. Mesmo com a chamada de novos membros, causaria problemas no desenvolvimento do projeto visto que, os novos membros precisam de tempo para adaptação. Estratégia de redução: Desenvolvimento de uma documentação e processos de treinamento como cursos e material didático para melhor adaptação de novos membros, assim como a inclusão de um plano de acompanhamento do membro que vai sair da equipe ao novo componente do time. Plano de contingência: Manter lista com os candidatos excedentes do processo de seleção. E solicitar que o membro sainte entregue uma documentação que sirva de referência para que o novo integrante situe-se no projeto. Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento Status:​ Simulação incompleta Quadro 1 ​- Quadro de Redução e Contingência do Risco 1 16
  • 18. Risco:​ Grande estimativa de transações Código:​ 002 Impacto:​ ​Crítico Probabilidade:​ 50% Descrição: Grande estimativa de transações e sobrecarga nos servidores, considerando o grande número de matrículas realizadas no período. O volume de dados pode causar congestionamento nas operações devido aos limites de ​hardware​. Assim, causando mau funcionamento do sistema em produção. Estratégia de redução: Já no planejamento, prevendo essa possibilidade, elaborar um bom Projeto de Banco de Dados. Definir as tecnologias, como SGBD, de forma que suportem com folga as estimativas. Além disso, o controle de transações e a realização de testes de estresse e desempenho podem-se mostrar úteis. Plano de contingência: Realizar mudanças na execução de procedimentos que sejam gargalos para o sistema (como o cálculo de classificação) para horários fora do intervalo de atendimento. Realizar migração dos dados para outro SGBD. Pessoa responsável:​ Alberto C. Neto Status:​ Simulação incompleta Quadro 2 ​- Quadro de Redução e Contingência do Risco 2 Risco:​ Interoperabilidade com sistema legado Código:​ 003 Impacto:​ ​Crítico Probabilidade:​ 40% Descrição: Possíveis conflitos com o sistema do SIGAA podem causar impacto na conexão entre bases do sistema, considerando o tamanho e regras particulares da aplicação legada. Estratégia de redução: Desenvolver o projeto com o acompanhamento do NTI. Assim, como o NTI detém maior conhecimento acessível a respeito do SIGAA, o projeto poderá ser desenvolvido da melhor forma possível. Plano de contingência:​ Buscar ajuda e alinhamento com o NTI. Pessoa responsável:​ Marcos B. Dósea Status:​ Simulação incompleta Quadro 3 ​- Quadro de Redução e Contingência do Risco 3 17
  • 19. Risco:​ Alteração nas regras de negócio Código:​ 004 Impacto:​ Crítico Probabilidade:​ 40% Descrição: É necessário considerar as constantes mudanças das regras de seleção já anunciadas e ou possíveis no processo seletivo ao longo dos anos. Estratégia de redução: Planejar o desenvolvimento dos módulos de forma que, caso haja mudanças nas regras de negócio (editais nos quais serão baseadas as funcionalidades), a adaptação seja a mais simples possível. Plano de contingência: Adaptar o ​software às novas regras de negócios. Aplicar, quando possível, os módulos do sistema de forma gradativa nos processos de seleção. Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento Status:​ Simulação incompleta Quadro 4 ​- Quadro de Redução e Contingência do Risco 4 Risco:​ Comprometimento da equipe Código:​ 005 Impacto:​ Crítico Probabilidade:​ 30% Descrição: Como a equipe que desenvolverá o projeto é composta por alunos, sabemos que não poderão dedicar-se exclusivamente ao projeto. Assim, é possível que demandas externas como provas, trabalhos e atividades extracurriculares possam diminuir a produtividade dos membros e atrasar o cronograma. Estratégia de redução: Priorizar as partes mais importantes do projeto. Criar um sistema de rotação dos membros, de forma que possam ser alocados em partes menos importantes enquanto sobrecarregados. Plano de contingência: Em casos onde não haja a possibilidade de realocação, outro aluno deve ser chamado a partir da lista de espera da seleção. Pessoa responsável:​ Alberto C. Neto Status:​ Simulação incompleta Quadro 5 ​- Quadro de Redução e Contingência do Risco 5 18
  • 20. Risco:​ Difícil manutenabilidade Código:​ 006 Impacto:​ Crítico Probabilidade:​ 20% Descrição: Devido à inexperiência da equipe, pode haver problemas com código-fonte e documentação. Assim, atrapalhando a evolução e correção de erros dos sistema, bem como a circulação de informações. Estratégia de redução: Cobrar dos programadores e responsáveis que desenvolvam a documentação em conjunto com a codificação. Adotar técnicas de revisão de código, com intuito de melhorar a qualidade do código. Plano de contingência:​ Exigir preparo e entrega de documentação. Pessoa responsável:​ Marcos B. Dósea Status:​ Simulação incompleta Quadro 6 ​- Quadro de Redução e Contingência do Risco 6 Risco:​ Requisitos mal compreendidos Código:​ 007 Impacto:​ Marginal Probabilidade:​ 40% Descrição:​ Dificuldade dos projetistas em compreender os requisitos passados pelos usuários na fase inicial do projeto ou durante o desenvolvimento. Com isso, acarretando em atraso de entregáveis e na dificuldade de gerenciar mudanças do projeto. Estratégia de redução: Manter o processo de desenvolvimento com acompanhamento dos stakeholders​, assim haverá menores chances de que algum requisito mal entendido passe despercebido. Estabelecer processo de registro de solicitação de alterações, documentando assim as mudanças exigidas pelos ​stakeholders​. Plano de contingência:​ Validar as alterações dos requisitos solicitadas através de alinhamento com os ​stakeholders​. Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento Status:​ Simulação incompleta Quadro 7 ​- Quadro de Redução e Contingência do Risco 7 19
  • 21. Risco:​ Tamanho subestimado Código:​ 008 Impacto:​ Marginal Probabilidade:​ 30% Descrição: Os projetistas não prevêem de maneira adequada o tempo necessário para realização do projeto, causando atrasos na sua entrega. Estratégia de redução: Utilizar o modelo de desenvolvimento iterativo e incremental. Garantir que as estimativas do projeto sejam seguidas. Além disso, definir prioridades de modo que as partes essenciais estejam prontas no tempo previsto. Plano de contingência: Realizar acompanhamento periódico da evolução do projeto, evitando que problemas que possam atrapalhar o andamento do desenvolvimento sejam mitigados. Renegociar os prazos de entrega. Pessoa responsável:​ Prof. Dr. Rogério P. C. do Nascimento Status:​ Simulação incompleta Quadro 8 ​- Quadro de Redução e Contingência do Risco 8 Risco:​ Falta à equipe domínio das tecnologias Código:​ 009 Impacto:​ Marginal Probabilidade:​ 40% Descrição:​ O processo de seleção dos alunos não exigiu colaboradores com experiência suficiente nas tecnologias utilizadas no projeto. Pode ser necessário dedicar tempo do projeto para corrigir a curva de conhecimento, causando atrasos no cronograma. Estratégia de redução: Treinamento de pessoal com cursos e outras ferramentas de ensino. Divisão das equipes de acordo com a experiência, de forma que os mais experientes possam dar apoio aos demais. Busca de mentores do mercado de trabalho ou de programa de mestrado da área de tecnologia que possam orientar, de forma voluntária, os alunos integrantes do projeto. Plano de contingência:​ Realizar treinamento da equipe com as tecnologias necessárias para o desenvolvimento do projeto. Caso seja possível, estender o treinamento para os candidatos que ficaram de reserva para a colaboração do projeto. Pessoa responsável:​ Marcos B. Dósea Status:​ Simulação incompleta Quadro 9 ​- Quadro de Redução e Contingência do Risco 9 20
  • 22. 4. Planejamento Temporal 4.1. Conjunto de Tarefas do Projeto Na fase inicial do projeto foram utilizados 16 dias para as atividades de Planejamento e Projeto. O método de estimativa de Lorenz & Kidd [3] usado anteriormente na seção “Estimações do Projeto” resultou num total necessário de 9,4 meses de 22 dias, ou 206 dias, para as atividades de Desenvolvimento e Testes, divididos em 13 ​sprints​ de 15 dias. Também foi reservado um período de 21 dias para as atividades de Implantação. A Tabela 4 mostra uma representação das fases do projeto e a relação de atividades relacionadas a cada uma delas. 21
  • 23. Fase do Projeto Atividades Planejamento e Projeto 1. Visão Geral do Projeto de Software; 2. Levantamento de Requisitos; 3. Criação do Diagrama de Casos de Uso; 4. Criação do Diagrama de Classes de Domínio; 5. Estimação e Planificação do Projeto; 6. Elaboração da Análise de Riscos; 7. Definição do Product Backlog; 8. Preparação do Ambiente de Desenvolvimento; Desenvolvimento e Testes 9. Preparação do Banco de Dados; 10. Sprint Plannings da Sprint 1; 11. Implementação do Caso de Uso Confirmação de Matrícula; 12. Testes Unitários; 13. Testes de Integração; 14. Revisão da Sprint; 15. Retrospectiva da Sprint; 16. Sprint Planning da Sprint 2; 17. Implementação do Caso de Uso Envio de Documentos; 18. Testes Unitários; 19. Testes de Integração; 20. Revisão da Sprint; 21. Retrospectiva da Sprint; 22. Sprint Planning da Sprint 3; 23. Implementação dos Casos de Uso Reenvio de Documentos; 24. Testes Unitários; 25. Testes de Integração; 22
  • 24. 26. Revisão da Sprint; 27. Retrospectiva da Sprint; 28. Sprint Planning da Sprint 4; 29. Implementação do Caso de Uso Controle de Vagas; 30. Testes Unitários; 31. Testes de Integração; 32. Revisão da Sprint; 33. Retrospectiva da Sprint; 34. Sprint Planning da Sprint 5; 35. Implementação do Caso de Uso Integração dos Dados pelo SIGAA; 36. Testes Unitários; 37. Testes de Integração; 38. Revisão da Sprint; 39. Retrospectiva da Sprint; 40. Sprint Planning da Sprint 6; 41. Implementação do Caso de Uso Validação de Dados de Matrícula; 42. Testes Unitários; 43. Testes de Integração; 44. Revisão da Sprint; 45. Retrospectiva da Sprint; 46. Sprint Planning da Sprint 7; 47. Implementação do Caso de Uso Disponibilização de Editais; 48. Testes Unitários; 49. Testes de Integração; 50. Revisão da Sprint; 51. Retrospectiva da Sprint; 52. Sprint Planning da Sprint 8; 53. Implementação dos Casos de Uso Manter Etapas do 23
  • 25. Processo Seletivo; 54. Testes Unitários; 55. Testes de Integração; 56. Revisão das Sprint; 57. Retrospectiva das Sprint; 58. Sprint Planning da Sprint 9; 59. Implementação do Caso de Uso Controle de Vagas; 60. Testes Unitários; 61. Testes de Integração; 62. Revisão das Sprint; 63. Retrospectiva da Sprint; 64. Sprint Planning da Sprint 10; 65. Implementação do Caso de Uso Processamento da Lista de Espera; 66. Testes Unitários; 67. Testes de Integração; 68. Revisão da Sprint; 69. Retrospectiva da Sprint; 70. Sprint Planning da Sprint 11; 71. Implementação do Caso de Uso Importação de Dados dos Processos; 72. Testes Unitários; 73. Testes de Integração; 74. Revisão da Sprint; 75. Retrospectiva da Sprint; 76. Sprint Planning da Sprint 12 77. Implementação do Caso de Uso Divulgação da Lista de Aprovados; 78. Testes Unitários; 79. Testes de Integração; 24
  • 26. 80. Revisão da Sprint; 81. Retrospectiva da Sprint; 82. Preparação do Banco de Dados; 83. Sprint Planning da Sprint 13; 84. Implementação do Caso de Uso Acompanhamento de Processos; 85. Testes Unitários; 86. Testes de Integração; 87. Revisão da Sprint; 88. Retrospectiva da Sprint; Implantação 89. Documentação do Projeto; 90. Manual do Usuário; 91. Montagem do pacote executável; Tabela 4 - ​Fases do Projeto e Tarefas Associadas 4.2. Diagrama de Gantt O diagrama de Gantt descreve o período de execução das atividades necessárias para a consecução do produto final, bem como a distribuição das mesmas sobre o tempo. O diagrama de Gantt resultado do processo de estimativa neste projeto é bastante extenso para ser incluído neste documento de forma confortável para a leitura. Dessa forma, ele está disponível de forma compactada na Figura 3, mas deve ser melhor analisado no seguinte ​hiperlink​: ​https://bit.ly/2TZ0n1J​. 25
  • 27. 26
  • 28. Figura 3 ​- Diagrama de Gantt - Portal Ingressos UFS 27
  • 29. 5. Organização do Pessoal 5.1. Estrutura da Equipe A equipe responsável pelo desenvolvimento do projeto é representada na Tabela 5. A tabela mostra os integrantes e seus papéis no desenvolvimento do projeto. Responsável Papel Descrição Prof. Dr. Rogério P. C. do Nascimento Coordenador/Gerente de Projetos Planejar e gerir a execução dos projetos. Alberto C. Neto Orientador/​Scrum Master ​1 Módulo de processamento de ingressos. Marcos B. Dósea Orientador/​Scrum Master ​2 Módulo Web do Portal. Claudio L. L. Carvalho Programador 1 Codificar e/ou manutenir. Diego R. Santos Programador 2 Codificar e/ou manutenir. João A. M. Junior Programador 3 Codificar e/ou manutenir. Antonio C. M. P. Junior Programador 4 Codificar e/ou manutenir. Geovanne S. Atanazio Programador 5 Codificar e/ou manutenir. Tiago A. de Farias Programador 6 Codificar e/ou manutenir. Victor S. Vieira Programador 7 Codificar e/ou manutenir. Tabela 5 - ​Estrutura da Equipe 5.2. Mecanismos de Comunicação Os mecanismos de comunicação que utilizamos, basicamente, foram Telegram e Google Drive. As discussões quando não presenciais, foram feitas através de um grupo no Telegram. Enquanto na criação de diagramas e do plano em conjunto, utilizamos o Draw.io e o Docs com Google Drive. 5.3. Uso do Edu-blog como Ferramenta de Apoio O uso do Edu-blog [1] na disciplina proporcionou que adquiríssemos conhecimentos que, se fossem passados em sala de aula, poderiam ser bem maçantes. Dessa forma, aprendemos muito sobre nosso tema proposto, pesquisando para escrever no ​blog​. E, ao mesmo tempo, aprendemos um pouco de cada tema através das pesquisas de cada grupo. Conhecemos ferramentas úteis, como o Trello e GitHub, e metodologias de desenvolvimento 28
  • 30. de ágil como Scrum e Kanban. Ferramentas que foram/poderiam ter sido usadas no desenvolvimento do projeto. 6. Precauções tomadas para assegurar e controlar a qualidade do produto de ​software Esta seção descreve as medidas previstas para que possa ser mantida a qualidade do software​. ● Controle de versão Plano de versionamento do projeto para garantir que as alterações realizadas sejam controladas. Assim, planejadas em versões de entrega que possam ser revertidas em possíveis falhas em novas funcionalidades. ● Testes unitários Tem a função de manter a corretude do código através de testes em frações do código. Esses testes são feitos a partir de classes com apenas esse intuito. Garantindo que funcionalidades e trechos de código tenham sido testados de forma única e automática, e que de código de teste não sejam esquecidos no código-fonte. 29
  • 31. Referências [1] Edu-blog > GP | UFS 2018. Disponível em:<​https://gp-ufs.blogspot.com/​> [2] PRESSMAN, R. S. Engenharia de Software - 7.ed. McGraw Hill Brasil, 2009 [3] LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994. [4] Kerzner, H. Gestão de Projetos - As Melhores Práticas - 3ª Ed. 2016 30