Plano de Projeto Portal de Ingressos UFS

Universidade Federal de Sergipe
Centro de Ciências Exatas e Tecnologia/CCET
Departamento de Computação/DCOMP
Gerência de Projetos
Prof.º Dr.º Rogério Patrício Chagas do Nascimento
Portal de Ingressos UFS e Acompanhamento do Discente
Plano de Projeto de Software
Jaine da Conceição Santos
José Valmir de Araújo Filho
Matheus Santos Almeida
Raul Oliveira de Andrade
Thomé Pereira Alves Neto
São Cristóvão – SE
Março 2019
1

Universidade Federal de Sergipe
Centro de Ciências Exatas e Tecnologia/CCET
Departamento de Computação/DCOMP
Gerência de Projetos
Prof.º Dr.º Rogério Patrício Chagas do Nascimento
Portal de Ingressos UFS e Acompanhamento do Discente
desenvolvido na disciplina de Gestão de
Projetos para obtenção de nota.
São Cristóvão - SE
Março 2019
2

Sumário
1 INTRODUÇÃO 5
1.1 Âmbito do Projeto 5
1.2 Funções principais do produto de software 7
1.3 Requisitos comportamentais ou de performance 12
1.3.1 Usabilidade 12
1.3.2 Confiabilidade 13
1.3.3 Performance 13
1.3.4 Suportabilidade 14
1.3.5 Segurança 14
1.4 Gestão e Restrições Técnicas 15
2 ESTIMAÇÕES DO PROJETO 15
2.1 Técnicas de estimação e resultados 16
2.1.1 Técnica de estimação 16
2.1.2 Resultados 17
2.2 Recursos do projeto 18
2.2.1 Recursos Humanos 18
2.2.2 Recursos de Software 18
2.2.3 Recursos de Hardware 18
3 ANÁLISE E GESTÃO DE RISCOS 18
3.1 Riscos do projeto 19
3.2 Redução e Gestão do Risco 20
4 PLANEJAMENTO TEMPORAL 24
4.1 Conjunto de Tarefas do Projeto 24
4.2 Diagrama de Gantt 26
5 ORGANIZAÇÃO DO PESSOAL 27
5.1 Estrutura da equipe 27
5.2 Mecanismos de comunicação 28
5.3 Uso do Edu-blog como ferramenta de apoio 28
3

6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW 29
REFERÊNCIAS 29
APÊNDICE A - DIAGRAMA DE GANTT DO PLANEJAMENTO TEMPORAL 30
APÊNDICE B - DIAGRAMA DE CLASSE 32
4

1 INTRODUÇÃO
O Projeto de software constitui em um portal de ingressos cujo o objetivo é
concentrar todo o processo de matrícula dos alunos de graduação da Universidade
Federal de Sergipe (UFS), um Banco de documentos para armazenar a
documentação digitalizada dos alunos e um dashboard para acompanhamento do
processo.
Atualmente existem três forma de ingresso na UFS: através do Sistema de
Seleção Unificada (SISU), Processo Seletivo (PS) para os cursos de música e letras
em Libras e o Processo Seletivo Campus Sertão. O SISU é a principal forma de
ingresso aos cursos de graduação, por esse motivo o número de alunos a serem
matriculados é grande causando congestionamento no Sistema Integrado de
Gestão de Atividades Acadêmicas (Sigaa) e uma parte desse processo é feita de
forma manual demandando muito recurso e tempo.
A ideia é desenvolver um sistema capaz de automatizar, agilizar, reduzir
erros e o congestionamento do Sigaa nesses períodos de matrículas, atendendo
todas as formas de ingresso aos cursos de graduação oferecidos pela UFS. Além
de utilizar os dados adquiridos nesse processo de matrícula para gerar informações
para a própria Universidade e para a comunidade.
1.1 Âmbito do Projeto
O Projeto de Software constitui em um portal de Ingresso 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. Exportar os dados dos matriculados para o Sigaa.
5

Neste portal deverão ser inseridos os dados dos candidatos que
participaram dos processos seletivos (SISU, PS Licenciatura em música e em letras
Libras e P. Campus Sertão). Após constarem no sistema, serão enviados links para
os candidatos que foram aprovados com o objetivo de realizar a etapa 2. O link terá
um formulário com os dados do próprio candidato para que o mesmo possa
confirmar se estão corretos, corrigir, caso não estejam, e preencher os demais
campos do formulário de matrícula, além de anexar os documentos digitalizados
exigidos no edital. Ao confirmar os dados o sistema confirmará a pré-matrícula
desse aluno, para os candidatos que não confirmarem seus dados, após o prazo
estipulado, o sistema colocará a vaga como ociosa, disponibilizando para a lista de
espera.
Em uma aba administrador do sistema, exibirá todos os candidatos que
confirmaram a matrícula e estão com o status de pré-matriculados. Nesta tela,
durante a etapa 3, o funcionário designado irá selecionar o formulário de um
candidato para validar os dados informados com os documentos originais
apresentados, se existir algum erro um novo link será enviado para o candidato
corrigir e retornar. Quando os dados estiverem corretos o funcionário irá confirmar a
matrícula, e o sistema mudará o status para matriculado.
No dia e hora determinado o sistema exportará os dados dos alunos
matriculados para o sigaa, onde os alunos poderão se cadastrar e ter acesso ao
sistema.
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 que ficaram na primeira
chamada e a ordem de classificação dos alunos obedecendo às regra dispostas no
edital. Essas listas serão divulgadas no portal e os alunos que foram classificados
irão participar do mesmo processo de matrícula da primeira chamada. O sistema
ficará repetindo esse processo até todas as vagas de todos os cursos serem
preenchidas ou não haver candidatos na lista de espera.
No caso de não haver mais candidatos na lista de espera, o sistema exibirá
para o administrador as vagas ociosas por curso, possibilitando a geração de um
6

arquivo csv com os candidatos matriculados e excluídos para serem importados no
sistema do sisu.
Os documentos inseridos pelos candidatos após o processo de matrícula
serão armazenados em uma banco de documentos para possíveis consultas
posteriores.
E por fim, partindo dos dados do portal o sistema irá gerar gráficos
informativos e automáticos em um painel dashboard disponível para uso da
comunidade em geral e personalizado para uso da Prograd.
1.2 Funções principais do produto de software
Nesta seção serão listados as principais funcionalidades do Projeto Portal de
Ingressos e Acompanhamento do Discente através das Imagens 1 e 2, as quais se
tratam do diagrama de caso de uso, e da lista de requisitos funcionais. O diagrama
de classes pode ser visto no Apêndice B.
7

Figura 1: Diagrama de caso de uso do portal.
8

Figura 2: Diagrama de caso de uso do módulo administrador.
Os dois diagramas, Figuras 1 e 2, representam os atores envolvidos no projeto, cada ator
representa um papel específico no sistema. A Tabela 1 descreve brevemente esses papéis.
Tabela 1: Lista de Atores.
Ator Descrição
Candidato Esse ator representa os alunos participantes do Sistema de
Seleção Unificada (SISU), que foram classificados, seja pela
chamada regular ou após processamento da lista de espera que
realizaram a matrícula na instituição.
Prograd Esse ator representa o(s) colaborador(es) da pró-reitoria de
graduação (PROGRAD), que publicará os editais e fará o
acompanhamento do processo de matrícula.
DCV Esse ator representa o(s) colaborador(es) do departamento de
concursos e vestibulares (DCV).
9

DAA Esse ator representa o(s) colaborador(es) do Departamento de
Administração Acadêmica (DAA).
Junta Médica Esse ator representa o(s) contratado(s) pela UFS para avaliar os
alunos inscritos a uma vaga de cotas por deficiência.
SIGAA Esse ator representa o Sistema Integrado de Gestão de
Atividades Acadêmicas (SIGAA) utilizado pela UFS.
Usuário Externo Esse ator representa qualquer usuário que deseja visualizar ou
realizar download de dados no dashboard de acompanhamento
dos ingressantes.
Na tabela 2 estão descritas as principais funcionalidades que o sistema terá, com base no
diagrama de caso de uso.
Tabela 2: Descrição dos requisitos.
Requisito Descrição
RF001 No portal deverá ficar disponível para acesso do usuário todos os
editais de processos seletivos, separados por: Processo em aberto, Em
andamento e Concluídos.
RF002 Qualquer usuário que acessa o portal poderá visualizar e/ou fazer
download dos editais.
RF003 Ter uma área administrador acessada através de login e senha,
restringindo funcionalidades por perfil.
RF004 O portal deverá permitir ao perfil prograd publicar os editais, para
ficarem disponíveis para que qualquer usuário externo possa ter
acesso.
RF005 Permitir o cadastro, alteração e exclusão de cada etapa de cada
processo seletivos. Essas etapas devem ter período determinado,
ficando ativas ao iniciar o período e inativas ao final.
RF006 Permitir cadastro, alteração e exclusão dos tipos de cotas oferecidas
pela instituição, informando o período de inclusão e o decreto.
RF007 Permitir a alimentação do sistema com os dados dos alunos aprovados
e na lista de espera, feitos por processo seletivo externo ao sistema.
Esses dados serão utilizados para realizar matrícula dos alunos
aprovados, fazer o processamento da lista de espera e para o
dashboard do ingressante.
RF008 Disponibilizar no portal todas as listas com as classificações dos alunos
e lista dos alunos aprovados na chamada regular, ordenadas e com
data de publicação.
10

RF009 Informar ao candidato que foi aprovado ou classificado como suplente
ou excedente, passando as orientações do procedimento de matrícula.
RF010 Permitir ao candidato o acesso livre a área de sua matrícula de forma
segura, através da verificação de alguns dados presentes na inscrição
do sisu (exemplo: CPF, nome da mãe o código de inscrição do enem).
RF011 Exibir formulário com os dados já adquiridos através do SISU, para que
o candidato possa verificar, corrigir e preencher caso seja necessário.
RF012 Encaminhar documentos necessários para matrícula digitalizados,
separados por tipo de documento e de acordo com a vaga do candidato
(Exemplo: candidato a uma vaga de cota por deficiência deverá enviar
os exames e laudo médico).
RF013 Permitir ao aluno acompanhar o processo da sua matrícula informando
se está pendente, se inconsistência de dados, documentos inválidos ou
faltando, se já foi aprovada pela prograd, se foi finalizada e se já pode
fazer o cadastro no sigaa.
RF014 Encaminhar novamente os documentos e/ou corrigir dados caso não
tenham sido aprovados na etapa de validação.
RF015 Caso o candidato seja optante por vaga de deficientes, e caso a junta
médica pelos documentos enviados avalie como necessário o
atendimento. Deverá possibilitar o agendamento em um dos horários,
evitando filas.
RF016 Após o prazo para matrícula da chamada regular, as vagas que não
foram preenchidas serão utilizadas para lista de espera. O
processamento será feito com base na classificação do candidato e nas
regras dispostas no edital, resultando em uma lista de candidatos
aprovados, suplente e excedentes. Esse processamento ficará
disponível até não ter mais vagas ou o prazo para chamada encerrar.
RF017 No caso de Candidato optante por uma vaga de cotas por baixa renda,
a documentação do mesmo deverá ser encaminhada para o dcv avaliar
a veracidade.
RF018 Após a matrícula, segundo o edital do sisu, a instituição deve enviar um
arquivo informando as vagas preenchidas.
RF019 No caso de Candidato optante por uma vaga de cotas por deficiência, a
documentação do mesmo deverá ser encaminhada à junta médica para
avaliar a veracidade.
RF020 No caso de Candidato optante por uma vaga de cotas por deficiência,
após a avaliação da junta médica a mesma emitirá um laudo de
comprovação.
RF021 Após a autorização das documentações dos candidatos que optaram
por uma vaga de cotas, as mesma são encaminhadas para o DAA com
11

suas devidas autorizações.
RF022 Permitir cadastro, alteração e exclusão dos cursos e vagas oferecidas
pela instituição, informando o período de inclusão e o decreto.
RF023 Exibir na tela os dados e documentação do candidato selecionado para
que os responsáveis possam validar e matricular o candidato.
RF024 No caso de Candidato optante por uma vaga de cotas por deficiência, a
documentação do mesmo deverá ser encaminhada à junta médica para
avaliar a veracidade
RF025 Exibir informações sobre a quantidade de vagas ocupadas e não
ocupadas.
RF026 Confirmar a pré-matrícula do candidato emitindo um comprovante e
colocando o candidato com status de matriculado. Para que ao final do
prazo de matrícula, todos os cadastros com este status sejam
exportados para o sigaa.
RF027 Após finalização da matrícula os dados matriculados serão importados
para o sistema sigaa. Para dar prosseguimento ao processo de
confirmação da matrícula e restante da vida acadêmica do aluno.
RF028 Informar ao portal os alunos que não confirmaram matrícula na devida
data e tiveram seus cadastros excluídos.
1.3 Requisitos comportamentais ou de performance
Nesta seção estão descritos os requisitos que não estão relacionados
diretamente às funcionalidades de um sistema, sendo aplicados a muitos aspectos
diferentes do sistema que vão desde usabilidade até a performance. Nas subseções
os requisitos não funcionais estão agrupados levando em consideração esses
aspectos.
1.3.1 Usabilidade
Esse grupo de requisitos se relaciona com a capacidade do usuário aprender
a operar, preparar entradas e interpretar saídas do sistema ou seus componentes.
Tabela 3: Requisitos Não Funcionais de Usabilidade.
RNF001 Ter uma interface fácil e intuitiva para o usuários.
RNF002 Possuir mecanismos de ajuda como explicação passo a passo.
12

RNF003 Recurso de acessibilidade.
RNF004 Editais mais recentes devem estar mais visíveis.
RNF005 Possui filtros para melhorar a consulta
1.3.2 Confiabilidade
Esse grupo é inerente a capacidade do sistema ou componente para
executar as funções requeridas sob determinadas condições por um período de
tempo específico.
Tabela 4: Requisitos Não Funcionais de Confiabilidade.
RNF006 Deve estar sempre disponível para acesso, principalmente no
período de matrícula.
RNF007 Os prazos determinados nas etapas irão habilitar e inabilitar as
funcionalidades determinadas.
RNF008 O processamento da lista de espera deve estar correspondente
as regras de classificação e a ordem. A medida das
disponibilizações das vagas.
RNF009 Os dados presentes no dashboard devem estar sempre
atualizados.
RNF010 As documentações dos alunos matriculados devem ficar
disponíveis por pelo menos 5 anos após a conclusão do curso.
RNF011 Os estados do acompanhamento de matrícula devem estar
sempre atuais.
1.3.3 Performance
Esse grupo se refere a atributos quantificáveis do sistema, como tempo de
resposta, quanto trabalho o sistema pode executar dentro de um período de tempo
especificado, disponibilidade e precisão.
Tabela 5: Requisitos Não Funcionais de Performance.
RNF012 Ter a capacidade para mais de 5 mil acessos simultâneos.
13

RNF013 Exportação para o Sigaa deverá ser feita no último dia de
matrícula de madrugada.
RNF014 A emissão dos comprovantes de pré-matrícula deverão ficar
disponíveis para candidatos em até 10s após a validação da
matrícula.
1.3.4 Suportabilidade
Esses requisitos estão relacionados a facilidade de alterações no sistema
após a implantação, incluindo os aspectos de adaptabilidade, manutenibilidade e
internacionalização.
Tabela 6: Requisitos Não Funcionais de Suportabilidade.
RNF015 Fácil manutenabilidade.
RNF016 Possuir documentação e clareza no código.
RNF017 Integração com o Sigaa.
RNF018 Utilização de Linguagem de programação e outros recursos
conhecidos pelo NTI.
RNF019 Código comentado.
1.3.5 Segurança
Esse grupo refere-se aos requisitos associados à integridade, privacidade e
autenticidade dos dados.
Tabela 7: Requisitos Não Funcionais de Segurança.
RNF020 O armazenamento dos documentos deve ser seguro e restrito,
os dados só poderão ser divulgados e consultados com a devida
autorização.
RNF021 Garantir que apenas o candidato possa alterar seus próprios
dados, através de recursos de autenticação de acesso.
RNF022 As informações divulgadas no dashboard para o público externo
não podem conter dados pessoais dos alunos, apenas dados
gerais.
14

RNF023 Os links encaminhados para os candidatos deverão ser seguros
e com as devidas autenticações.
RNF024 Criação de acessos temporários para serem utilizados nos
períodos de matrícula.
1.4 Gestão e Restrições Técnicas
A equipe de desenvolvimento do projeto será composta por alunos dos
cursos de graduação do Departamento de Computação da UFS, que passaram por
um processo de classificação, mas que podem possuir pouca ou média experiência
com desenvolvimento de um projeto de software e com os recursos que serão
utilizados. Além disso os recursos que serão utilizados e os processos de
manutenção do software devem estar de acordo com as habilidade determinadas
pelo núcleo de tecnologia da Informação (NTI).
As restrições técnicas associadas ao desenvolvimento do projeto são:
1. Utilização de recursos open source e gratuitos.
2. Preferencialmente, deverá ser desenvolvido em Linguagem JAVA, mas a
utilização da linguagem Python pode ser negociada.
3. Utilização do banco de dados Postgresql versão 9.6.
4. Utilização do JAVA com Hibernate.
Esse projeto será desenvolvido baseado no modelo de desenvolvimento
iterativo-incremental, ou seja, a cada etapa será entregue um componente funcional
para que o cliente possa testar e validar. O gerenciamento da equipe será feito
seguindo a metodologia ágil, mais especificamente o framework Scrum, acordado
junto com a equipe. Esse gerenciamento será composto por um Dono do Produto,
um Scrum Master decidido pela equipe e o acompanhamento e orientações dos
professores participantes do projeto.
2 ESTIMAÇÕES DO PROJETO
Estimativas incorretas do projeto podem comprometer as entregas de
diversas formas: acabam gerando um cronograma impreciso (muito apertado ou
com muita folga que deixa a equipe ociosa), pode gerar mais custos para o projeto,
15

pode gerar horas extras para entregar no prazo acordado com o cliente, entre outros
(PAGANI, 2018).
Dessa forma, é muito importante que o plano de projeto de um software
forneça as estimações de custo, esforço e tempo. Assim, nesta seção essas
estimativas são apresentadas juntamente com a técnica utilizada para calculá-las.
2.1 Técnicas de estimação e resultados
Nesta subseção é apresentada a técnica de estimação selecionada e os
resultados derivados dela.
2.1.1 Técnica de estimação
A técnica de estimação utilizada neste projeto tem como base as métricas de
Lorenz e Kidd (LORENZ; KIDD, 1994). Essas métricas foram escolhidas por se
adequarem bem ao desenvolvimento de softwares construídos utilizando o
paradigma de orientação a objetos. A técnica é aplicada a partir da execução dos
seguintes passos:
1. Determinar o número de classes chave, ou seja, classes ligadas diretamente
às regras de negócio;
2. Definir o tipo de interface do sistema. Elas podem ser vistas na Tabela 8;
3. Encontrar o número de classes de suporte, que é dado pela multiplicação do
número de classe chave por um multiplicador que é definido pelo tipo de
interface do Sistema. Os multiplicadores podem ser visto na Tabela 8;
4. Multiplicar o número total de classes (chave + suporte) pelo número médio de
unidades de trabalho (dias-pessoas) por classe;
5. Determinar a quantidade de esforço estimada;
6. O resultado será a estimativa de tempo necessário para desenvolver o
projeto.
Tabela 8 - Tipos de interfaces do produto e respectivos multiplicadores.
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
16

GUI 2,5
GUI Complexa 3
2.1.2 Resultados
Os resultados obtidos pela aplicação das métricas de Lorenz e Kidd podem ser
vistos abaixo:
● Classes chaves: Foram identificadas 6 (seis) classes chaves (Aluno,
ProcessoSeletivo, Edital, ListaAprovados, Matricula e Curso), de acordo com
o Apêndice B;
● O sistema é baseado em uma interface gráfica simples, logo, atribui-se o
multiplicador 2,5, conforme a Tabela 8.
● Classes suportes: número de classes chaves x multiplicador, portanto, 6 x
2,5. Obtendo-se um total de 15 classes suportes;
● Total de classes do sistema: 15 + 6 = 21;
● O número médio de unidade de trabalho foi de 20 dias-pessoa, pois a equipe
tem pouca experiência na área de desenvolvimento.
● Esforço estimado: número total de classes x número médio de unidade de
trabalho, portanto, 21 x 20 = 420 dias-pessoa.
● Como a equipe é formada por 5 pessoas, cada membro da equipe
necessitará de 84 dias para a execução do projeto.
● Considerando um mês com 22 dias úteis, serão necessários
aproximadamente 3 meses e 18 dias para concluir o projeto.
Levando em consideração como fases do projeto: Definição, Desenvolvimento e
Testes e Manutenção e a distribuição de 40% do tempo para a Definição, 20% para
o Desenvolvimento e 40% para os Testes e Manutenção, a distribuição do trabalho
por pessoa é exibida na Tabela 9.
Tabela 9 - Dias de trabalho destinados para cada fase do projeto por pessoa.
Fase Tempo destinado em
porcentagem (%)
Cálculo Dias de trabalho
Definição 40 0,4 * 84 34
17

Desenvolvimento 20 0,2 * 84 16
Testes e
Manutenção
40 0,4 * 84 34
Total: 84
2.2 Recursos do projeto
Esta seção descreve os recursos humanos, de software e hardware,
ferramentas de apoio, entre outros usados no desenvolvimento deste projeto
2.2.1 Recursos Humanos
A equipe deste projeto é composta por Jaine Conceição, Valmir Araújo,
Matheus Almeida, Raul Andrade e Thomé Pereira, todos alunos do curso de Ciência
da Computação e, ocupando as funções de gerente de projetos, analista de
sistemas, arquiteto de software, desenvolvedor e analista de testes,
respectivamente.
2.2.2 Recursos de Software
Os software a serem utilizados no desenvolvimento deste projeto são:
● IDE para o desenvolvimento do sistema: Eclipse, Netbeans ou IntelliJ IDEA.
● Softwares para modelagem: StarUML e BrModelo.
● Sistema de gerenciamento de banco de dados: PostgreSQL.
● Sistema de controle de versão: Git.
● Escrita da documentação: Google Docs.
2.2.3 Recursos de Hardware
Os recursos de Hardware utilizados no desenvolvimento deste projeto são:
● Notebooks e Desktops: para a documentação, codificação e testes.
3 ANÁLISE E GESTÃO DE RISCOS
Um risco é um problema potencial e, como o desenvolvimento de um
software é difícil e dinâmico, é importante que a equipe esteja preparada para os
riscos. Para isso, existe a gestão de riscos, que é um conjunto de ações que tem o
18

objetivo de aumentar as chances de um projeto ser concluído com sucesso (JUSTO,
2018). Dessa forma, esta seção discute os riscos do projeto em questão e como
geri-los.
3.1 Riscos do projeto
Na Tabela 10 estão apresentados os riscos encontrados no projeto
juntamente com as probabilidades de ocorrência e os seus impactos. Esses riscos
foram identificados através de um brainstorming entre os integrantes da equipe.
Tabela 10 - Riscos do projeto com suas respectivas probabilidades de ocorrência e
impacto.
Risco Descrição Probabi
lidade
Impacto
01 Congestionamento do sistema provocado pelo
alto número de usuários ativos ao mesmo tempo
60% Catastrófico
02 Disponibilidade da equipe 40% Catastrófico
03 Restrição orçamentária 30% Catastrófico
04 Mau funcionamento dos equipamentos no dia da
exportação dos dados
20% Catastrófico
05 Perda de informações do Banco de dados 5% Catastrófico
06 Modificações nas formas de ingresso da
Universidade.
70% Crítico
07 Número de transações do Banco de Dados muito
alto
65% Crítico
08 Problemas durante a integração com outros
sistemas
55% Crítico
09 Falta de familiaridade da equipe com as
tecnologias adotadas
40% Crítico
10 Sistema ter baixa usabilidade 30% Crítico
PONTO DE CORTE
11 Distância entre cliente e os desenvolvedores 90% Marginal
12 Usuário carecer de habilidades necessárias para
utilizar o sistema
65% Marginal
19

13 Tamanho do Banco de Dados 65% Marginal
14 Número de linhas muito grande 50% Marginal
15 Falta de motivação 40% Marginal
16 Demora de entrega 20% Desprezível
17 Cliente com dificuldade de expressar as suas
necessidades
10% Desprezível
3.2 Redução e Gestão do Risco
Segundo o Project Management Body of Knowledge (PMBOK) (PMI, 2017),
um dos processos essenciais para um bom gerenciamento de riscos é planejar as
respostas a eles, ou seja, desenvolver alternativas, selecionar estratégias e acordar
ações para lidar com a exposição geral aos riscos e tratar os riscos individuais.
Uma das formas de fazer isso é através da Redução ou Mitigação de riscos,
isto é, reduzir a probabilidade e/ou impacto de um risco. Desse modo, abaixo são
apresentados planos de Redução, supervisão e gestão de risco (RSGR) para os
riscos catastróficos e críticos listados para o projeto.
Tabela 11 - Plano de RSGR para o risco 01.
Código: 01 Probabilidade: 60% Impacto: Catastrófico
Descrição: Congestionamento do sistema provocado pelo alto número de
usuários ativos ao mesmo tempo
Estratégia de Redução: Solicitar ao administrador de redes uma configuração
para que o acesso aos servidores sejam feitos paralelamente.
Estratégia de Contingência: Espelhar diversos servidores, pois caso um cair ou
falhar teremos outros servidores que operarão normalmente. E também testar
previamente se o espelhamento dos servidores está funcionando corretamente.
Pessoa Responsável: Gerente de Infraestrutura e Gerente de Projetos.
Status: Em andamento.
Descrição: Disponibilidade da equipe.
20

Estratégia de Redução: Oferecer boas condições de trabalho e uma política de
aviso prévio, de modo a preparar a equipe para a falta de um dos membros.
Estratégia de Contingência: Deixar todos os membros da equipe informados
sobre todos os estágios do projeto, sendo possível a execução de determinada
tarefa por qualquer membro da equipe. Também disponibilizar a documentação do
sistema. Contratar antecipadamente membros reservas.
Pessoa Responsável: Gerente de projetos.
Descrição: Restrição orçamentária.
Estratégia de Redução: Identificar qual o limite mínimo orçamentário para
desenvolvimento do projeto e quais componentes devem ser priorizados, levando
em conta esse limite. Convencer os gestores a não ultrapassar o limite em caso
de restrição orçamentária.
Estratégia de Contingência: Estender o prazo do projeto. Encerrar o
desenvolvimento de componentes do Sistema que não sejam essenciais.
Reavaliar, junto com os stakeholders e clientes, os requisitos, para identificar
quais são prioridades, dado o novo orçamento.
Descrição: Mau funcionamento dos equipamentos no dia da exportação dos
dados.
Estratégia de Redução: Testar antecipadamente todos os equipamentos
necessários no mínimo 2 vezes, sendo o primeiro teste realizado 3 dias antes e o
segundo realizado 1 dia antes da exportação.
Estratégia de Contingência: Possuir alguns equipamentos reservas prontos para
funcionar imediatamente caso algum equipamento apresente defeito.
Pessoa Responsável: Analista de Sistemas.
21

Descrição: Perda de informações do Banco de dados.
Estratégia de Redução: Realizar o espelhamento do banco de dados e tentar
identificar os fatores causadores das perdas.
Estratégia de Contingência: Estabelecer um bom plano de backup que ajude a
minimizar as perdas e acelerar a recuperação das informações.
Pessoa Responsável: Administrador de Banco de Dados e Gerente de Projetos.
Código: 06 Probabilidade: 70% Impacto: Crítico
Descrição: Modificações nas formas de ingresso da Universidade.
Estratégia de Redução: Aplicação de padrões de projeto (como Strategy e
Bridge)(GAMMA, 1995) na arquitetura do sistema para que seja possível modificar
as regras de negócio sem ter que modificar toda a arquitetura do sistema.
Estratégia de Contingência: Interromper o desenvolvimento de qualquer classe
e funcionalidade relacionada à forma de ingresso anterior. Solicitar que arquitetos
do sistema refaçam o diagrama de classe, levando em consideração as
modificações na forma de ingresso da Universidade. Iniciar o desenvolvimento
das classes e funcionalidade que foram modificadas, desconsiderando toda a
parte do desenvolvimento que foi interrompida.
Pessoa Responsável: Gerente do Projetos.
Descrição: Número de transações do Banco de Dados muito alto.
Estratégia de Redução: Utilização de ferramentas como Priorização de Query e
Enfileiramento de Query.
Estratégia de Contingência: Melhorar o poder computacional do sistema. Por
exemplo, adicionando processadores mais rápidos ou com mais núcleos
Pessoa Responsável: Administrador de Banco de Dados e Gerente de Projetos.
22

Descrição: Problemas durante a integração com outros sistemas
Estratégia de Redução: Criar uma documentação com base na utilização desses
outros sistemas. Ou seja, utilizar e analisar o fluxo dos outros sistemas.
Estratégia de Contingência: Solicitar documentação dos outros sistemas, com o
intuito de garantir que os desenvolvedores tenham informações técnicas
necessárias sobre os outros sistemas.
Descrição: Falta de familiaridade da equipe com as tecnologias adotadas.
Estratégia de Redução: Buscar contratar pessoas com experiência nas
tecnologias adotadas, disponibilizar o máximo de informações possível sobre as
tecnologias, como manuais, documentações, cursos, entre outros, e oferecer
treinamentos.
Estratégia de Contingência: Negociar novas datas de entrega das
funcionalidades e reservar um tempo para treinamentos mais intensos.
Descrição: Sistema ter baixa usabilidade.
Estratégia de Redução: Buscar seguir as metas de usabilidade de Nielsen
(NIELSEN, 1990) durante o desenvolvimento do sistema.
Estratégia de Contingência: O Analista de UX irá avaliar a usabilidade segundo
as heurísticas e propor soluções para os problemas detectados. As soluções
propostas serão implementadas pelos desenvolvedores.
Pessoa Responsável: Analista de UX e Gerente de Projetos.
23

4 PLANEJAMENTO TEMPORAL
Nesta seção são apresentadas as tarefas que devem ser executadas no
desenvolvimento do projeto e suas dependências de forma a estimar a duração total
do projeto.
4.1 Conjunto de Tarefas do Projeto
O modelo escolhido para a execução do projeto foi o iterativo-incremental e o
tempo necessário para executá-lo é apresentado na Tabela 9 na subseção 2.1.2. O
desenvolvimento do projeto foi organizado de acordo com as seguintes tarefas:
Tabela 21: Tarefas existentes no projeto.
Número Tarefa Descrição
01 Reuniões com o cliente Encontros e entrevistas com o cliente para
falar sobre o projeto.
02 Levantamento de
requisitos
Identificação das funcionalidades e
requisitos de qualidade do sistema.
03 Análise de requisitos Observação e levantamento dos elementos
do ambiente onde o software será
implantado.
04 Prototipação das telas Elaboração de protótipos de telas do
sistema para validação dos requisitos.
05 Definição da arquitetura Escolha de uma arquitetura de software
para modelar o sistema.
06 Análise e gestão de
riscos
Definição de um conjunto de ações
estratégicas, como identificação,
administração, condução e prevenção dos
riscos ligados às atividades do projeto.
07 Definição dos testes Escolha dos testes que serão realizados na
validação do sistema.
08 Documentação Elaboração do documento que detalha a
arquitetura, os requisitos e os métodos de
teste para o desenvolvimento do sistema.
09 Codificação da classe
Aluno
Implementação através de uma linguagem
de programação das telas e das
24

funcionalidades relacionadas às regras de
negócio da classe Aluno do sistema e suas
classes suportes.
ProcessoSeletivo
negócio da classe ProcessoSeletivo do
sistema e suas classes suportes.
Edital
negócio da classe Edital do sistema e suas
classes suportes.
ListaAprovados
negócio da classe ListaAprovados do
sistema e suas classes suportes.
Matricula
negócio da classe Matricula do sistema e
suas classes suportes.
Curso
negócio da classe Curso do sistema e suas
classes suportes.
15 Testes Unitários Realização de testes em unidades
individuais de código fonte. Unidades
podem ser métodos, classes,
funcionalidades, módulos, etc.
16 Testes de Integração Realização de testes em módulos
combinados do sistema.
17 Testes de Sistema Realização de testes no sistema já
completamente integrado, fazendo a
verificação quanto a seus requisitos num
ambiente de produção.
18 Criação do manual do
usuário
Desenvolvimento de uma documentação
para auxiliar o usuário na utilização do
sistema.
19 Treinamento do usuário Treinamento com os usuários do sistema
25

visando capacitá-los na utilização do
mesmo.
20 Implantação Passagem do software para o ambiente de
produção.
4.2 Diagrama de Gantt
O Diagrama de Gantt é uma forma visual para controlar o cronograma de um
projeto, ajudando a avaliar os prazos de entrega e os recursos críticos. Esse
diagrama mostra visualmente um painel com as tarefas que precisam ser
realizadas, a relação de precedência entre elas, quando as tarefas serão iniciadas,
sua duração, responsável e previsão de término (LEÃO, 2019).
Dessa forma fica mais simples conseguir fazer com que toda a equipe
entenda suas responsabilidades, e acompanhar o andamento do projeto. No
Apêndice A é possível ver o Diagrama de Gantt do projeto Portal de Ingressos UFS
e Acompanhamento do Discente.
5 ORGANIZAÇÃO DO PESSOAL
Esta seção apresenta de que forma a equipe foi organizada e as ferramentas
de comunicação e apoio utilizadas. A atribuição dos papéis de cada membro da
equipe foi feita analisando as habilidades de cada um, visando assim, obter uma
melhor alocação de pessoas às tarefas.
5.1 Estrutura da equipe
Na tabela a seguir, pode-se observar os papéis designados para cada
integrante da equipe, assim como a descrição da função de cada um.
Responsável Papel Descrição
Jaine Conceição Gerente de projetos Trabalha com a elaboração
de propostas, planejamento,
monitoramento e revisão de
projetos, seleção e
avaliação de pessoal, etc.
26

José Valmir Analista de Sistemas e
Administrador de Banco
de Dados
Criar, planejar e
desenvolver programas
personalizados para cumprir
os objetivos da empresa e
administração dos
servidores,
acompanhamento de
desempenho, programação
de rotina, além de garantir a
segurança de acesso..
Matheus Santos Almeida Arquiteto de Software e
Gerente de
Infraestrutura
Lidera e coordena as
atividades e os artefatos
técnicos no decorrer do
projeto, estabelece a
estrutura geral de cada
visão de arquitetura, integra
sistemas, avalia e identifica
soluções tecnológicas,
elabora estratégias e
procedimentos de
contingências.
Raul Andrade Desenvolvedor e
Analista UX
É responsável pelo
desenvolvimento do
software que lhes é
passado por engenheiros e
analistas de sistemas e por
desenhar experiências do
usuário positivas para o
produto desde o início até o
fim do projeto.
Thomé Pereira Analista de Testes Responsável por identificar
e elaborar os planos de
teste apropriados, pela
execução correta de tais
testes, e avaliar os
resultados obtidos de cada
ciclo de teste.
5.2 Mecanismos de comunicação
Para realizar a comunicação entre os membros da equipe e o monitoramento
do avanço do projeto, foram utilizadas ferramentas como o Telegram, Trello e o
Google Calendar.
27

● O Telegram foi usado para proporcionar discussões sobre o projeto de modo
geral.
● O Trello foi onde os membros organizaram suas tarefas, o que precisavam
fazer, o que estavam fazendo e o que já havia sido finalizado.
● E por fim, o Google Calendar, era utilizado para organizar todos os deadlines.
Além disso, foram realizadas reuniões semanais com todos os integrantes da
equipe na Universidade Federal de Sergipe.
5.3 Uso do Edu-blog como ferramenta de apoio
Para a construção deste plano foi utilizado ainda o material disponível no
edu-blog da disciplina, serviço fornecido pelo google chamado de blogger, e
disponibilizado pela disciplina Gerência de Projetos, ministrada pelo Prof.º Dr.º
Rogerio Patricio Chagas do Nascimento.
O uso dessa ferramenta foi interessante no decorrer da disciplina, pois
impulsionou o trabalho em equipe e a pesquisa. Além disso, o blog agregou na
descoberta de novas ferramentas, tecnologias e conceitos para cada um dos
membros da equipe.
Outro fator relevante é a disponibilidade de acessar os blogs das outras
equipes, ou seja, dos nossos colegas de turma e de turmas passadas, pois temos
acesso a um conteúdo diversificado e uma base relativamente extensa como
referência.
Por fim, como o blog é público, qualquer pessoa tem a oportunidade de
comentar, visualizar e baixar arquivos, não só as pessoas envolvidas com a
disciplina, e isso é legal pois sentimos que estamos contribuindo com o
desenvolvimento intelectual da comunidade.
6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
A garantia de qualidade do Software é formada por um conjunto planejado e
sistemático de atividades, que tem como objetivo principal promover confiança
sobre o Software solicitado pelo cliente e atender as necessidades do usuário final
(WIKIPEDIA, 2018).
28

Uma precaução é realizar reuniões com o cliente e toda a equipe de
desenvolvimento, com o intuito de promover mais eficiência na comunicação. Pois
isso reforça que todos os requisitos de Software estão de acordo com o que o
cliente deseja.
Uma outra boa precaução é realizar toda uma documentação adequada que
vai desde o planejamento até os testes no Software. Além disso, lembrar sempre de
atualizar a documentação quando mudanças ocorrerem, pois isso garante que a
documentação estará sempre atualizada.
Mais precauções para assegurar a qualidade do produto são:
● A utilização de uma metodologia: e no caso desse projeto foi escolhida
uma metodologia Ágil e o framework Scrum;
● A utilização de um glossário, visto que facilita a comunicação entre os
desenvolvedores e clientes;
● A utilização de um guia de estilo para a codificação, pois facilita a
leitura e a codificação entre a equipe.
● A utilização de uma ferramenta de controle de versão, como por
exemplo o git.
Por fim, mas não menos importante, seguir as melhores práticas de gestão
de projeto segundo o PMBOK (PMI, 2017).
REFERÊNCIAS
GAMMA, Erich. Design patterns: elements of reusable object-oriented software.
Pearson Education India, 1995.
JUSTO, Andreia Silva. Gerenciamento de Riscos em Projetos: aprenda a lidar
com as incertezas na gestão de iniciativas. Disponível em:
<https://www.euax.com.br/2018/02/importancia-do-gerenciamento-de-riscos/>.
Acesso em: 07 de março de 2019.
LORENZ, Mark; KIDD, Jeff. Object-oriented software metrics: a practical guide.
Prentice-Hall, Inc., 1994.
29

LEÃO, Tiago. Gráfico de Gantt: o que é, como funciona e como montar o seu é
tão difícil?. Disponível em:
<https://www.nomus.com.br/blog-industrial/grafico-de-gantt>. Acesso em: 07 de
março de 2019.
NIELSEN, J.; MOLICH, R. Heuristic evaluation of user interfaces. Proc. ACM
CHI'90 Conf., Seattle, EUA, 1-5 abril, p. 249-256, 1990.
PAGANI, Talita. Como estimar o esforço de desenvolvimento de software e por
que isso é tão difícil? - Parte 1. Disponível em:
<https://medium.com/@talitapagani/como-estimar-esforco-desenvolvimento-software
-parte-1-2ab28c271943>. Acesso em: 07 de março de 2019.
PMI. Um guia do conhecimento em gerenciamento de projetos. 6. ed. EUA:
Project Management Institute, 2017.
WIKIPEDIA. Software Engineering Body of Knowledge. Disponível em:
<https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge>. Acesso
em: 07 de março de 2019.
30

APÊNDICE A - DIAGRAMA DE GANTT DO PLANEJAMENTO TEMPORAL
31

APÊNDICE B - DIAGRAMA DE CLASSE
33

Plano de Projeto Portal de Ingressos UFS

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Plano de Projeto Portal de Ingressos UFS

Semelhante a Plano de Projeto Portal de Ingressos UFS (17)

Plano de Projeto Portal de Ingressos UFS