UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAO

Sistema de Gerenciamento de Atendimento - SGA

Plano de Projeto de Software

Danillo Ramos,Fiama Santos, Joo Pedro, Matheus Santos,

Ricardo Passos e Walter Wallace

Departamento de Computao/UFS

So Cristvo Sergipe
2017
 UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CINCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAO

Plano do Projeto de Software para Produtos da Lacertae SW

Trabalho apresentado ao Prof. Dr. Rogrio Patrcio

Chagas do Nascimento como nota para a disciplina
Gerncia de Projetos do curso de graduao em Sis-
temas de Informao da Universidade Federal de Ser-
gipe(UFS).

Professor(a): Dr. Rogrio Patrcio Chagas do Nasci-

mento

So Cristvo Sergipe
2017
 Lista de ilustraes

Figura 1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figura 2 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figura 3 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figura 4 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

 Lista de tabelas

Tabela 1 Funcionalidades e Usurio . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Tabela 2 Tabela de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tabela 3 Tarefas do Projeto e Tempo Estimado . . . . . . . . . . . . . . . . . . . . . 23

Tabela 4 Integrantes e suas funes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

 Sumrio

1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Funes principais do produto de software . . . . . . . . . . . . . . . . . . . . 5
1.3 Requisitos comportamentais ou de performance . . . . . . . . . . . . . . . . . 7
1.4 Gesto e Restries Tcnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Estimaes do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Dados histricos utilizados para as estimaes . . . . . . . . . . . . . . . . . . 9
2.2 Tcnicas de estimao e resultados . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Tcnica de estimao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Recursos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.3 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Gesto de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Riscos Genricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Riscos Especficos do Produto . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Tabela de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Reduo e Contingncia de Riscos . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Conjunto de Tarefas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Organizao da equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 Estrutura da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Mecanismos de comunicao . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Uso do Edu-blog como ferramenta de apoio . . . . . . . . . . . . . . . . . . . 26

6 Precaues tomadas para assegurar e controlar a qualidade do produto de soft-

ware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
 5

1
Introduo

1.1 Escopo do Projeto

O software auxilia no gerenciamento de filas geradas em recepes com uso de senhas.
As senhas so geradas de acordo com as prioridades dos usurios e tipos dos servios disponveis,
melhorando o atendimento e minimizando possveis conflitos que possam vir a acontecer em filas
nos rgos pblicos. As entradas so o tipo de servio desejado, como por exemplo, marcao e
realizao de exames ou consultas, e a definio da prioridade necessria ao perfil do usurio.
Neste ltimo caso, so especificadas como Normal, ou seja, usurio que no necessita de
atendimento prioritrio e Prioridade.

1.2 Funes principais do produto de software

As principais funes do produto de software esto listadas abaixo:

Tabela 1 Funcionalidades e Usurio

Funcionalidade Usurio
Efetuar Login Recepcionista
Informa Pronturio Recepcionista
Gera Senha Recepcionista
Imprime Senha Recepcionista
Chama Prximo Recepcionista

As figuras 1 e 2 representam os diagramas criados de acordo com os requisitos necessrios

para a construo do produto de software.
Captulo 1. Introduo 6

Figura 1 Diagrama de Casos de Uso

Captulo 1. Introduo 7

Figura 2 Diagrama de Classes

1.3 Requisitos comportamentais ou de performance

Os clientes esperam do produto de software os seguintes comportamentos:

A interface do software ser amigvel e de fcil usabilidade, proporcionando uma boa

familiarizao do usurio;
Captulo 1. Introduo 8

Os objetivos do usurio ao operar o software devero ser atingidos sem dificuldades;

O software dever estar disponvel sempre que necessrio;

O tempo de resposta na gerao de senhas no dever ultrapassar 10 segundos

1.4 Gesto e Restries Tcnicas

Restries tcnicas que afetaro o projeto:

O software ser desenvolvido em Ruby;

O cliente dever seguir a risca as instrues para correta preparao

do ambiente de execuo;

Os prazos de entrega podero ser estendidos;

O tempo de resposta para impresso das senhas ainda longo;

O software funciona de forma melhor em ambiente Linux.

 9

2
Estimaes do Projeto

Esta parte do documento fornece estimativas relacionadas ao custo, trabalho e tempo de

desenvolvimento do projeto.

2.1 Dados histricos utilizados para as estimaes

Por ser o primeiro projeto desenvolvido por esta equipe, no dispomos de um parmetro
histrico para as estimativas.

2.2 Tcnicas de estimao e resultados

Para propor estimativas de forma sria e verdadeiramente mensurvel, preciso utilizar
alguma tcnica disponvel no mercado ou no meio acadmico, nossa equipe escolheu a tcnica
de Lorenz e Kidd (1994), por ser orientada a objetos, assim como o desenvolvimento do nosso
software.

2.3 Tcnica de estimao

A tcnica acima citada, consiste basicamente nos seguintes aspectos:

1. Verificar quantas classes chaves existem no sistema, que so as classes ligadas diretamente
as regras de negcio;

2. Definir o tipo de interface do sistema, e associ-la a um multiplicador de acordo com sua

complexidade;
Captulo 2. Estimaes do Projeto 10

3. Multiplicar as classes chaves por seus respectivos multiplicadores, para descobrir o nmero
de classes de suporte;

4. Multiplicar o nmero total de classes (chave + suporte) pelo nmero mdio de unidades de
trabalho por classe.

5. O resultado ser a estimativa de tempo necessrio para desenvolver o projeto.

2.4 Resultados
Resultados gerados pela aplicao da tcnica de estimao de Lorenz & Kidd, a seguir
como podemos observar na figura 3 o diagrama de classes de domnio:
Captulo 2. Estimaes do Projeto 11

Figura 3 Diagrama de Classes

A figura acima a figura 3, retrata o diagrama de classe de domnio do projeto, esse

diagrama serve para representar de forma mais clara o modelo de domnio que nada mais do
que um artefato da engenharia de software que representa as relaes entre as classes.

1. Classes chaves: 9 (PatientsController, DashboardController, ResourceController, Scree-

ningController, UsersController, QueueController, ApplicationController, User, Patient).

2. Todo nosso sistema baseado em uma interface grfica simples.

Captulo 2. Estimaes do Projeto 12

3. Sendo assim atribumos o multiplicador 2,5.

4. Classes de suporte: 9 (classes chave) x 2,5 (multiplicador), totalizando 22,5 classes de

suporte.

5. Total de classes 9 (chaves) + 22,5 (suporte) = 31,5.

6. Nmero mdio de unidade de trabalho: 16 dias-pessoa.

7. Tempo previsto: 31,5 (classes) x 16 (dias) = 504 dias por pessoa para construo das
classes.

8. Como nossa equipe possui 6 pessoas conclumos que o tempo estimado ser de 84 dias
teis.

9. Considerando um ms comercial com 22 dias, levaramos aproximadamente 3,8 meses

para concluir o projeto.

2.5 Recursos do projeto

Considerando um ms comercial com 22 dias, levaramos aproximadamente 3,8 meses
para concluir o projeto.

2.5.1 Recursos Humanos

Profissionais da equipe:
1 Gerente do Projeto
1 Analista de sistemas
3 programadores
1 Testador

2.5.2 Recursos de Software

IDE para desenvolvimento do sistema: Netbeans
Gerncia do Banco de Dados: PostgreSQL
Ferramenta para controle de verso: SVN
Ambiente de modelagem dos diagramas UML: Star UML
Captulo 2. Estimaes do Projeto 13

2.5.3 Recursos de Hardware

1. 3 estaes de trabalho, cada estao com a seguinte configurao: Processador Core i7,
8gb de memria RAM, 500gb de HD, 2 monitores de 19 polegadas.

2. Notebook para apresentao do sistema ao cliente

 14

3
Gesto de Riscos

Nesta seo iremos identificar e analisar os riscos envolvidos em possveis eventos

ocorridos durante o ciclo de vida do software. Na Seo 3.1 iremos apresentar os dezoito riscos
considerados mais importantes pela equipe de desenvolvimento. Na Seo 3.2 ser apresentada
uma tabela contendo os riscos identificados, a probabilidade de ocorrncia de cada um, e o
impacto destes riscos no ciclo de vida do projeto. Por ltimo, a Seo 3.3 ir identificar aes
e mtodos que podem ser utilizados para previso, identificao e gerenciamento dos riscos
identificados.

3.1 Riscos do Projeto

Todos os riscos aqui listados foram classificados em dois grupos distintos: "Riscos
Genricos", e "Riscos Especficos do Produto".

3.1.1 Riscos Genricos

Os riscos genricos so riscos que podem ser vistos como potenciais ameaas para
todos os projetos de software desenvolvidos particularmente por uma empresa. Neste projeto,
identificamos os seguintes riscos genricos:
Indisponibilidade de Sistema: O sistema pode se tornar indisponvel por um perodo
de tempo indeterminado;
Descumprimento de prazo de entrega: A entrega feita num prazo superior ao pre-
visto;
Falta de clareza em documentao, manuais e treinamentos: Artefatos de software
gerados durante o desenvolvimento no so claros e de fcil entendimento;
Captulo 3. Gesto de Riscos 15

No utilizar ferramentas CASE para realizar testes de software

No ter garantia de qualidade de software: O produto no satisfaz os valores das
mtricas de qualidade estipuladas na fase de anlise de software;
No ter equipes definidas para desenvolvimento do projeto: Falta de pessoal neces-
srio, ou falta de atribuio de papis no processo de desenvolvimento;
Custo de reparos em defeitos do produto: necessrio usar recursos extras para
reparar certos defeitos do produto;
Custo de atraso na entrega do produto: necessrio usar recursos extras para com-
pensar o atraso na entrega do produto;
Impacto na receita da empresa: O desenvolvimento do produto muito custoso para a
empresa;

3.1.2 Riscos Especficos do Produto

Os riscos especficos do produto so riscos cujo escopo engloba apenas o projeto em
questo. Ao contrrio do risco genrico, um risco especfico do produto uma ameaa em
potencial apenas para o SGA. Foram identificados os seguintes riscos especficos do produto:
Cliente no ter uma ideia slida dos requisitos: O desenvolvimento do produto
muito custoso para a empresa;
Cliente no participar das reunies
Cliente no revisa o produto O produto no avaliado pelo cliente para determinar a
sua eficcia;
Alteraes projetadas aos requisitos do produto: Alteraes feitas nos requisitos antes
ou aps a entrega do produto;
No ter relao com o cliente: A interao com o cliente prejudicada por algum
motivo;
Exceder tamanho estimado do produto: O tamanho do produto em si maior do que
o esperado;
Exceder tamanho estimado do banco de dados: O banco de dados maior do que o
esperado;
Exceder nmero de linhas de cdigo projetadas: O produto tem mais linhas de cdigo
do que o previsto;
Exceder estimativa de usurios dirios: Nmero de acessos ao sistema superior ao
previsto;
Captulo 3. Gesto de Riscos 16

3.2 Tabela de Riscos

Cada risco identificado neste projeto dispe de informaes que podem ser consideradas
importantes ao seu respeito. Uma dessas informaes identificadas a categoria atribuda ao risco.
Riscos de categoria de negcio so considerados como ameaas ao desenvolvimento do prprio
software. J os riscos do cliente so ameaas que podem ocorrer devido ao relacionamento com
o cliente com o desenvolvimento do software. Por fim, os riscos de produto dizem respeito
a problemas relacionados a aspectos tcnicos do produto, como tamanho, disponibilidade,
velocidade, etc.
Outra informao identificada a probabilidade de ocorrncia de um risco. Tendo
esta informao vital, o analista pode tomar as medidas necessrias de acordo com o grau de
probabilidade. As probabilidades so dadas no formato de porcentagem.
Por fim, temos o impacto causado pela concretizao do risco. Esta informao con-
siderada vital para a gesto do projeto pelo analista. Podemos categorizar o impacto como
desprezvel, marginal, crtico e catastrfico.
A seguir apresentaremos uma tabela de riscos identificados durante o projeto. A cada linha
da tabela, teremos informaes como o nome do risco identificado, a categoria, a probabilidade
de ocorrncia e o seu impacto.

Tabela 2 Tabela de Riscos

Riscos Categoria Prob. Impacto
Indisponibilidade de Sistema Negcio 3% Marginal
Descumprimento de prazo de entrega Negcio 15% Marginal
Falta de clareza em documentao, manuais e treinamentos Negcio 10% Crtico
Alteraes projetadas aos requisitos do produto Negcio 10% Marginal
No utilizar ferramentas CASE para realizar testes de software Negcio 60% Marginal
No ter garantia de qualidade de software Negcio 10% Crtico
No ter equipes definidas para desenvolvimento do projeto Negcio 50% Desprezvel
Custo de reparos em defeitos do produto Negcio 3% Marginal
Custo de atraso na entrega do produto Negcio 5% Marginal
Impacto na receita da empresa Negcio 3% Crtico
Cliente no ter uma ideia slida dos requisitos Cliente 5% Crtico
Cliente no participar das reunies Cliente 5% Crtico
Cliente no revisa o produto Cliente 5% Marginal
No ter relao com o cliente Cliente 20% Crtico
Exceder tamanho estimado do produto Produto 50% Desprezvel
Exceder tamanho estimado do banco de dados Produto 50% Desprezvel
Exceder nmero de linhas de cdigo projetadas Produto 50% Desprezvel
Exceder estimativa de usurios dirios Produto 50% Desprezvel
Captulo 3. Gesto de Riscos 17

3.3 Reduo e Contingncia de Riscos

Aps a identificao dos riscos do projeto, importante a elaborao de estratgias
de reduo, responsveis por minimizar as chances dos riscos em questo se tornarem reais,
alm de planos de contingncia, que podem auxiliar nos casos em que o risco em questo se
torne realidade. Abaixo listamos dezoito tabelas, que so relacionados a cada risco identificado,
contendo as informaes identificadas na Seo 3.2 (Descrio, probabilidade de ocorrncia e
impacto), alm de estratgias de reduo, planos de contingncia, identificao dos responsveis
pela ativao do plano, e status atual do tratamento do risco.

Risco: 001 Prob: 3% Impacto: Marginal

Descrio: Indisponibilidade do sistema
Estratgia de reduo: Apenas realizar manutenes em horrios onde o acesso ao
sistema reduzido. Adquirir um servidor robusto para reduzir o tempo de
indisponibilidade. Realizao de manuteno peridica no servidor.
Plano de contingncia: Utilizar um servidor reserva. Reutilizar o antigo sistema de
gerenciamento de senhas, e utilizar mais pessoas no processo, para no gerar atrasos.
Pessoa responsvel: Analista de Testes.
Status: Simulao completada em 04/04/2017.

Risco: 002 Prob: 15% Impacto: Marginal

Descrio: Descumprimento do prazo de entrega
Estratgia de reduo: Propor ao cliente uma data de entrega mais elstica possvel.
Contratao temporria de estagirios para acelerar o processo de desenvolvimento do
produto.
Plano de contingncia: Negociar com o cliente a possibilidade da entrega ser incremental
ou iterativa. Renegociar a data de entrega com o cliente, de maneira realista e ciente.
Pessoa responsvel: Analista de Testes.
Status: Simulao completada em 04/04/2017.
Captulo 3. Gesto de Riscos 18

Risco: 003 Prob: 10% Impacto: Crtico

Descrio: Falta de clareza em documentao, manuais e treinamentos
(artefatos de software)
Estratgia de reduo: Participao de toda equipe de desenvolvimento na elaborao
dos artefatos de software. Manter um padro de estilo de documentao. Treinamento de
equipe para elaborao da documentao.
Plano de contingncia: Reunio com toda a equipe de desenvolvimento para ensinar e
explicar os artefatos de software. Modificao dos artefatos de software para a melhor
compreenso da equipe de desenvolvimento.
Pessoa responsvel: Analista de Testes.
Status: Simulao completada em 04/04/2017.

Risco: 004 Prob: 10% Impacto: Marginal

Descrio: Alteraes projetadas aos requisitos do produto
Estratgia de reduo: Implementar um processo de gerenciamento de mudanas de
requisitos;Dar enfase ao processo de engenharia de requisitos, utilizando metodologias
que permitam uma participao colaborativa dos stakeholders junto as atividades de
levantamento, anlise e validao dos requisitos.
Plano de contingncia: Realizar reunio com os stakeholders e aplicar o processo de
gerenciamento de mudanas, com o objetivo de identificao e registrar as necessidade de
mudana, fazer uma anlise de impacto e posteriormente implementar a mudana.
Pessoa responsvel: Analista de Sistemas.
Status: Concludo.

Risco: 005 Prob: 60% Impacto: Marginal

Descrio: No utilizar ferramentas CASE para realizar testes de software
Estratgia de reduo: Definir um membro da equipe para ser Testador de software com
o objetivo de identificar problemas no software e relatar aos desenvolvedores.
Plano de contingncia: Realizar uma bateria de testes diferentes, que envolvem desde
anlise da estrutura interna at a avaliao da interface do software.
Pessoa responsvel: Testador de Software.
Status: Em Concludo.
Captulo 3. Gesto de Riscos 19

Risco: 006 Prob: 10% Impacto: Crtico

Descrio: No ter garantia de qualidade de software
Estratgia de reduo: Implementar os requisitos solicitados pelos stakeholders, que
foram definidos por meio da aplicao do processo de engenharia de requisitos e
documentados pela equipe do projeto.
Plano de contingncia: Investir na melhoria da qualidade dos processo de
desenvolvimento de software para conseguir satisfazer as necessidades implcitas e
explcitas dos usurios.
Pessoa responsvel: Analista de sistemas e desenvolvedor.
Status: Em anlise.

Risco: 007 Prob: 50% Impacto: Desprezvel

Descrio: No ter equipes definidas para desenvolvimento do projeto
Estratgia de reduo: Definir formalmente a equipe, documentando a funo de
cada componente.
Plano de contingncia: Realizar reunies para definio concreta das funes dos
componentes e elaborar uma documentao para formalizar essa definio
Pessoa responsvel: Gestor de Projetos.
Status: Em andamento.

Risco: 008 Prob: 3% Impacto: Marginal

Descrio: Custo de reparos em defeitos do produto.
Estratgia de reduo: Tornar os testes mais rigorosos para mitigar os defeitos.
Plano de contingncia: Iniciar um GoFundMe para arrecadar mais recursos para o
projeto.
Pessoa responsvel: Gestor de Projetos.
Status: Em andamento.

Risco: 009 Prob: 5% Impacto: Marginal

Descrio: Custo de atraso na entrega do produto.
Estratgia de reduo: Acordar com o cliente prazos mais viveis no momento da
definio de requisitos
Plano de contingncia: Montar e capacitar uma equipe de forma correta e com nmero
suficiente de componentes.
Pessoa responsvel: Gestor de Projetos.
Status: Em andamento.
Captulo 3. Gesto de Riscos 20

Risco: 010 Prob: 3% Impacto: Crtico

Descrio: Impacto na Receita da Empresa
Estratgia de reduo: Otimizar os trabalhos realizados e evitar o desperdcio de
capital Humano.
Plano de contingncia: Acompanhar rigorosamente as metas e prazos para evitar o
desperdcio da Hora/Homem. Mantendo assim o oramento, dentro do que foi estipulado
no incio do desenvolvimento do projeto.
Pessoa responsvel: Gestor de Projetos.
Status: Em andamento.

Risco: 011 Prob: 5% Impacto: Crtico

Descrio: Cliente no ter uma ideia slida dos requisitos
Estratgia de reduo: Buscar identificar as necessidades do cliente e explica-lo durante
as reunies, como estas so classificadas como requisitos.
Plano de contingncia: Intensificar as reunies, para esclarecer da melhor forma
possvel, o que o cliente precisa para suprir suas necessidades, tambm manter a equipe de
desenvolvimento em contato frequento com os usurios.
Pessoa responsvel: Equipe de Desenvolvimento.
Status: Em andamento.

Risco: 012 Prob: 5% Impacto: Crtico

Descrio: Cliente no participar das reunies
Estratgia de reduo: Flexibilizar datas e horrios das reunies, para melhor atender as
disponibilidades do cliente.
Plano de contingncia: Estender os prazos para entrega do projeto, de acordo com o
aumento das dificuldades em identificar as necessidades do cliente.
Pessoa responsvel: Gestor de Projeto.
Status: No houve necessidade de se aplicar.

Risco: 013 Prob: 5% Impacto: Marginal

Descrio: Cliente no revisa o produto
Estratgia de reduo: Solicitar verificaes perodicas do produto ao cliente.
Plano de contingncia: Manter contato com um preposto ou secretrio do cliente.
Pessoa responsvel: Gestor do projeto.
Status: No houve necessidade de se aplicar.
Captulo 3. Gesto de Riscos 21

Risco: 014 Prob: 20% Impacto: Crtico

Descrio: No ter relao com o cliente
Estratgia de reduo: Realizar mais visitas ao cliente.
Plano de contingncia: Manter contato via e-mail ou vdeoconferncia com o cliente.
Pessoa responsvel: Gestor do projeto.
Status: No houve necessidade de se aplicar.

Risco: 015 Prob: 50% Impacto: Desprezvel

Descrio: Exceder tamanho estimado do produto
Estratgia de reduo: Verificar escopo do projeto a cada reunio
Plano de contingncia: Renegociar valores com o cliente.
Pessoa responsvel: Gestor do projeto.
Status: No houve necessidade de se aplicar.

Risco: 016 Prob: 50% Impacto: Desprezvel

Descrio: Exceder tamanho estimado do banco de dados
Estratgia de reduo: Estimar o tamanho do banco de dados com informaes do uso
real, como o prazo mnimo de permanncia dos dados e definir um percentual extra para
picos de uso.
Plano de contingncia: Otimizar o banco de dados afim de compactar o mesmo ou seno
aumentar o limite mximo do banco.
Pessoa responsvel: Arquiteto de Software.
Status: Concludo.

Risco: 017 Prob: 50% Impacto: Desprezvel

Descrio: Exceder nmero de linhas de cdigo projetadas
Estratgia de reduo: Definir antes da codificao o esqueleto bsico juntamente com
o Arquiteto de Software as estruturas que compe cada mdulo do software durante a
codificao.
Plano de contingncia: Otimizar os mdulos usando herana, polimorfismo e
pr-processamento de dados.
Pessoa responsvel: Arquiteto de Software.
Status: Concludo.
Captulo 3. Gesto de Riscos 22

Risco: 018 Prob: 50% Impacto: Desprezvel

Descrio: Exceder estimativa de usurios dirios
Estratgia de reduo: Coletar informaes juntamente com o usurio, inspecionar
pessoalmente a quantidade de usurios observando os picos de uso, para estimar o mais
prximo possvel do ideal.
Plano de contingncia: Melhorar os recursos da mquina do software. O sistema deve
estar rodando em uma mquina que suporte melhoramentos para suportar maior demanda
de usurios caso necessrio.
Pessoa responsvel: Analista de Sistemas.
Status: Concludo.
 23

4
Planejamento Temporal

O planejamento de software uma tarefa importante do projeto de software, que serve

como base para o gerenciamento do desenvolvimento do software. O planejamento temporal deve
ser criado no incio do projeto, com o objetivo de identificar as tarefas, designar o responsvel
pela mesma, fornecer uma viso do progresso do projeto e pode ser utilizado tanto pelo cliente
como pela equipe de desenvolvimento (SOMMERVILLE, 2011).

4.1 Conjunto de Tarefas do Projeto

O conjunto de tarefas definidas para realizar o processo de desenvolvimento do SGA
esto dispostas na Tabela 3, bem como o tempo estimado para a concluso de cada uma delas.
A definio do tempo estimado para realizao das atividades foi de 84 dias teis e distribudo
com base na regra 40-20-40, onde 38% do esforo do projeto foi destinado a atividade de
Levantamento, Anlise e Especificao de Requisito, 20% destinado a Codificao do software,
39% para a realizao de Testes e 3% para o Planejamento.
Para realizar o gerenciamento destas tarefas foi adotada a metodologia SCRUM, por ser
uma metodologia gil que permite o desenvolvimento iterativo e incremental do produto.

Tabela 3 Tarefas do Projeto e Tempo Estimado

TEMPO
TAREFAS PORCENTAGEM
(DIAS DE TRABALHO)
Planejamento 3% 2
Levantamento, Anlise e
38% 32
Especificao de Requisitos
Codificao 20% 17
Testes 39% 33
Total: 84 dias
Captulo 4. Planejamento Temporal 24

4.2 Diagrama de Gantt

Para representar graficamente o calendrio das atividades definidas no projeto, foi utili-
zado o diagrama de Gantt disposto na Figura 4. O diagrama foi construdo por meio da utilizao
da ferramenta GanttProject.

Figura 4 Diagrama de Gantt

fim.png
 25

5
Organizao da equipe

5.1 Estrutura da Equipe

A tabela 4 , demonstra o papel bsico de cada integrante, porm no limita suas atribui-
es, no decorrer do processo de desenvolvimento do Projeto.

Tabela 4 Integrantes e suas funes

Profissional Funo Atividades
Realizar estudos de processos computacionais,
Fiama Santos Analista de Sistema planejar e coletar informaes junto ao usurio,
com a finalidade de implantar o projeto.
Liderar e coordenar as atividades e os artefatos
Joo Pedro Arquiteto de Software
tcnicos no decorrer do projeto.
Ricardo Passos e Transformar o projeto no Sistema propriamente dito.
Desenvolvedores
Walter Walace Programar.
Planejar, controlar e executar projetos, sempre
Danillo Siqueira Gestor de Projetos
atento aos prazos e custos de produo.
Realizar testes durante o processo de desenvolvimento,
Matheus Silva Testador de Software
garantindo o funcionamento e a qualidade do sistema.

5.2 Mecanismos de comunicao

Foram utilizados como ferramentas de comunicao: E-mails, Grupo de whatsapp, assim
como reunies peridicas, para proporcionar uma melhor integrao entre a equipe. As reunies
tambm so fundamentais, pois nelas, ficam claros os objetivos, tanto individuais, quanto
coletivos. As dvidas so sanadas e todos ficam cientes do andamento do projeto.
Captulo 5. Organizao da equipe 26

5.3 Uso do Edu-blog como ferramenta de apoio

Existem as mais diversas forma de se compartilhar o conhecimento, dentre elas, a
utilizao da ferramenta Edu-blog, que nesta disciplina, foi de fundamental importncia. Olhando
especificamente para o projeto desenvolvido por esta equipe, as informaes contidas nos blogs,
foram de fundamental importncia para o bom andamento das atividades por ns desenvolvidas.
O legado de conhecimento explicitado por colegas de perodos anteriores, nos ajudou a otimizar
os processos, evitando o trabalho de reinventar a roda. A ferramenta foi o complemento ideal
para a metodologia empregada pelo docente. A facilidade de ter o contedo disponvel a todo
tempo e a oportunidade de trocar experincias com pessoas de dentro e fora do curso aprimora o
conhecimento e torna o aprendizado mais prazeroso.
 27

6
Precaues tomadas para as-
segurar e controlar a quali-
dade do produto de software

Com intuito de garantir que o projeto e o produto sejam produzidos com alto rigor de
qualidade e controle, sero tomadas as seguintes precaues:
Documentao: Ser feita a documentao durante todo o ciclo do produto de software,
contendo as principais informaes, progresso e observaes da equipe e projeto. Alm disso
trar as tomadas de decises que foram seguidas durante o projeto juntamente com os resultados.
Controle de verses: O projeto contar com um controle sobre todas a implementaes,
modificaes e remoes dos artefatos do produto de software, mostrando assim sua evoluo,
histrico e progresso da produo do software para a equipe.
Reunies de equipe: Sero feitas reunies com a equipe que compe este projeto, onde
ser discutido sobre o andamento do projeto. Estes encontros favoreceram o progresso da criao
do produto, assim como a interao da equipe.
Testes: Ser implementado e executado testes durante o ciclo do produto de software
seguindo a documentao e requisitos para elevar qualitativamente a funcionalidade, eficincia,
confiabilidade e usabilidade do software.
 28

Referncias

LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. [S.l.: s.n.], 1994.
Citado na pgina 9.

SOMMERVILLE, I. Engenharia de Software 9Edio. [S.l.: s.n.], 2011. Citado na pgina 23.