Plano do-projeto-de-software- SACC- LACERTAE

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CARLSON SANTANA CRUZ
DANILO DUARTE CORREIA DA COSTA REIS
DANILO FERREIRA NEVES
ÍCARO DA SILVA TORRES
PLANO DO PROJETO DE SOFTWARE
para produtos da Lacertae SW
SÃO CRISTÓVÃO
2015

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CARLSON SANTANA CRUZ
DANILO DUARTE CORREIA DA COSTA REIS
DANILO FERREIRA NEVES
ÍCARO DA SILVA TORRES
PLANO DO PROJETO DE SOFTWARE
para produtos da Lacertae SW
Trabalho de Gerência de Projetos
submetido ao Departamento de
Computação da Universidade
Federal de Sergipe como requisito
parcial para a a aprovação na
disciplina.
Orientador: Prof. Dr. Rogério Patrício Chagas Nascimento
SÃO CRISTÓVÃO
2015

Sumário
1. INTRODUÇÃO ................................................................................................................................... 4
1.1 ÂMBITO DO PROJETO................................................................................................................ 4
1.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE ..................................................................... 5
1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE ............................................................. 5
1.4 GESTÃO E RESTRIÇÕES TÉCNICAS............................................................................................ 6
2. ESTIMAÇÕES DO PROJETO........................................................................................................... 7
2.1 DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMAÇÕES............................................................... 7
2.2 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS .................................................................................. 7
2.2.1 Técnica de estimação........................................................................................................ 7
2.3 RESULTADOS ........................................................................................................................... 9
2.4 RECURSOS DO PROJETO........................................................................................................... 9
3. ANÁLISE E GESTÃO DE RISCOS ................................................................................................. 10
3.1 RISCOS DO PROJETO .............................................................................................................. 10
3.2 TABELA DE RISCOS ................................................................................................................. 10
3.3 REDUÇÃO E GESTÃO DO RISCO............................................................................................... 11
4. PLANEJAMENTO TEMPORAL ...................................................................................................... 15
4.1 CONJUNTO DE TAREFAS DO PROJETO ..................................................................................... 15
4.2 DIAGRAMA DE GANTT ............................................................................................................. 15
5. ORGANIZAÇÃO DO PESSOAL...................................................................................................... 16
5.1 ESTRUTURA DA EQUIPE........................................................................................................... 16
5.2 MECANISMOS DE COMUNICAÇÃO ............................................................................................. 16
5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO ................................................................... 16
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW........................................................................................................................... 17

1. INTRODUÇÃO
O sistema do centro cirúrgico busca um gerenciamento de atividades automatizado,
trazendo agilidade e precisão na verificação de informações. Seu principal objetivo é
gerenciar a logística de forma precisa e assim obter maior eficiência nas atividades do
centro cirúrgico, focando principalmente nas cirurgias.
É de vital importância um gerenciamento eficaz, pois além de conseguir inferir com
precisão os valores envolvidos em cada cirurgia é possível identificar com antecedência
eventuais problemas na realização das cirurgias. É importante destacar que a qualidade da
gerência do centro cirúrgico implica diretamente na saúde e bem estar dos pacientes.
O sistema foca principalmente nas atividades que atuam diretamente para a
realização de cirurgia, sendo elas, controle de estoque de medicamentos e materiais,
gerenciamento de equipamentos e salas, além do controle de horário dos anestesistas e
cirurgiões.
Em virtudes das melhorias advindas do sistema, é avaliado que todas as pessoas
envolvidas direta – cirurgiões, enfermeiros, assistentes, técnicos – ou indiretamente –
pacientes e seus familiares – devem ser beneficiadas. Isso se comprova pois o sistema
proporcionará maior precisão em relação aos custos operacionais envolvidos e na redução
do número de cancelamentos das cirurgias.
1.1 Âmbito do Projeto
O sistema deve trazer um gerenciamento preciso da entrada e saída de
medicamentos e materiais do centro cirúrgico, com isso prever possíveis faltas de
algum dos itens. Além disso, ele deve administrar os horários dos anestesistas e dos
cirurgiões, gerando relatórios mensais, semanais e diários de forma automatizada,
para garantir a existência de um número mínimo de anestesistas por turno.
Tabela 1 - Quadro Resumo
Problemas  Gerenciamento de medicamentos;
 Gerenciamento de materiais;
 Controle de horário dos anestesistas e cirurgiões;
 Controle das cirurgias.
Pessoas Atingidas  Cirurgiões;
 Anestesistas;
 Equipe de enfermagem;
 Pacientes.
Cujo impacto é  Sem medicamentos a cirurgia é suspensa ou
cancelada;
 Sem materiais a cirurgia é suspensa ou cancelada;
 Sem anestesistas a cirurgia não pode ser realizada;
 Horários de cirurgiões e cirurgias não devem chocar.
Uma solução bem
sucedida traria
 Controle de entrada e saída de medicamentos e
materiais que torne possível prever quando um
medicamento ou um material está na sua quantidade
mínima;
 Manter os horários dos anestesistas e dos cirurgiões
para gerar relatórios automatizados dos seus horários
e prever sua disponibilidade;
 Manter as cirurgias, contendo a data, horário e seu
status (agendada, realizada ou suspensa).

1.2 Funções principais do produto de software
Na Figura 1 temos um diagrama de caso de uso que mostra ilustrativamente
os atores que atuam no Sistema de Administração do Centro Cirúrgico:
1.3 Requisitos comportamentais ou de performance
Para atender os seus usuários com eficiência e qualidade, o Sistema de
Administração do Centro Cirúrgico:
 Usabilidade:
◦ O sistema deve possuir no máximo 12 campos na tela;
◦ O sistema deve possuir teclas de atalho para funcionalidades e
tornar o uso de mouse opcional;
 Desempenho:
Figura 1 - Diagrama de caso de uso

◦ O sistema não deve levar mais que 3 segundos para realizar uma
requisição de cadastro;
◦ O sistema deve gerar relatórios em tempo máximo de 5 segundos;
 Integração:
◦ O sistema deve se comunicar com o SIGTAP, sistema que
armazena dados a respeito cirurgias do SUS;
◦ O sistema deve se comunicar com o sistema de funcionários para
capturar informações a respeitos dos cirurgiões e anestesistas do
hospital;
◦ O sistema deve se comunicar com o sistema da farmácia, que
armazena dados a respeito dos medicamentos e matérias;
◦ O sistema deve se comunicar com o sistema de bolsa de sangue do
HU, para realizar pedidos de sangue.
1.4 Gestão e Restrições Técnicas
Algumas restrições técnicas são listadas abaixo:
 O sistema utilizará banco de dados PostgreSQL para manter os dados;
 O sistema deverá ser desenvolvido em plataforma web;
 O sistema deve ser modelado em arquitetura de três camadas;
 O sistema deve utilizar Factory em classes de conexão;
 O sistema deve utilizar Facete para integrar com subsistemas.

2. ESTIMAÇÕES DO PROJETO
Nesta seção serão apresentadas as estimações de tempo necessário para a
realização do projeto. Além disso, será considerado os recursos que serão
utilizados. Através dessas informações será possível ter uma visão mais aproximada
do custo, esforço e tempo total que será empenhado no projeto.
2.1 Dados históricos utilizados para as estimações
Tendo em vista deste ser o primeiro projeto dos integrantes da equipe, não
será possível utilizar dados históricos para as estimações do projeto.
2.2 Técnicas de estimação e resultados
O nosso projeto utilizará a métrica de Lorenz & Kidd para calcular o tempo
necessário para a realização do projeto. A utilização de uma técnica de
estimação é importante para fornecer indicadores que possibilitem avaliar de
modo aprofundado o projeto.
2.2.1 Técnica de estimação
A técnica de estimação elaborada por Lorenz & Kidd é orientada a
classes. Para determinar o tempo necessário para a realização do
projeto, deve-se seguir os seguintes passos:
1. Determinar através do diagrama de classes do domínio a
quantidade de classes chaves.
2. Classificar o tipo de interface do produto utilizando a tabela 2,
abaixo:
Tabela 2 - Relação entre a Interface e o Multiplicador
Interface Multiplicador
Sem interface 2
Interface de texto (CLI) 2,25
Interface Gráfica (GUI) 2,5
Interface Gráfica (GUI) Complexa 3
3. Calcular a quantidade de classes de suporte ao multiplicar o
número de classes chave pelo multiplicador da interface.
4. Somar a quantidade de classes chave e de suporte e multiplicar
pelo número médio de unidades de trabalho por classe para
determinar a quantidade de esforço estimada.
De acordo com o diagrama de classes, na figura 2, identificamos que o
software possui 7 classes chaves (destacadas com contorno).
Utilizando interface gráfica, com fator multiplicador de 2,5, teremos
17,5 classes de suporte totalizando 24,5 classes.

Figura 2 - Diagrama de Classes de Projeto

2.3 Resultados
Para realizarmos as estimações através da técnica de Lorenz & Kidd
utilizamos o diagrama de classes de domínio, exibido na figura 2. Após
a análise do diagrama e das considerações da técnica utilizada,
podemos obter as seguintes conclusões:
 Classes chaves: 7 classes;
 Tipo de interface: GUI simples;
 Classes de suporte: 7 (nº de classes chaves) x 2,5
(multiplicador) = 17,5 classes;
 Total de classes: 7(nº de classes chaves) + 17,5 (classes de
suporte) = 24,5 classes;
 Como unidade média de trabalho por classe, utilizaremos 20
dias-pessoa. Sendo assim, 24,5 (total de classes) x 20 (dias-
pessoa) = 490 dias-pessoa;
 Sendo 4 o número de integrantes do projeto, teremos que será
necessário aproximadamente 122,5...dias (122 dias + meio dia
de trabalho) para a construção das classes definidas. Serão
necessários mais 20 dias de projeto, levantamento e análise de
requisitos (incluídos no Gantt como etapas iniciais) totalizando
142 dias e meio de trabalho para a realização do projeto.
2.4 Recursos do projeto
Recursos humanos:
 Gerente de Projeto - Ícaro Torres;
 Engenheiro de Software - Danilo Ferreira e Carlson Santana Cruz;
 Gerente de Negócio - Danilo Duarte Correia da Costa Reis.
Recursos de software:
 NetBeans IDE – IDE Utilizada para o Desenvolvimento;
 StarUML – Software utilizado para gerar na modelagem de artefatos do
projeto;
 Microsoft Windows 8 – Sistema operacional utilizada pela equipe;
 Bitbucket – Servidor utilizado para hospedar o código-fonte do projeto;
 Heroku – Servidor utilizado para rodar a aplicação web;
 Gmail – Servidor e cliente de e-mail utilizado;
 Freedcamp – Serviço web de gerenciamento de projetos.
Recursos de hardware:
Foram utilizados os computadores pessoais dos integrantes da equipe.

3. ANÁLISE E GESTÃO DE RISCOS
Nesta seção, analisaremos os riscos de acordo com suas classificações e com base
na sua probabilidade e seu impacto no projeto.
3.1 Riscos do projeto
Risco Projeto Técnico Negócio Comum
Ausência de testes regulares e
detalhados
X X
Cliente/usuário passar informações
incorretas das suas necessidades
X
Legislação ou regra de negócio mudar X X
Cliente/usuário não se disponibilizar para
fazer entrevistas
X
Impossibilidade de atualizar framework de
desenvolvimento
X
Servidor de Produção Indisponível X X
Membros da equipe não possuem
conhecimento sobre as tecnologias
utilizadas
X
Scripts não funcionam corretamente em
alguns navegadores
X
Tempo combinado insuficiente para
terminar o sistema
X
Custo de implantação ultrapassar o
estipulado
X
Falha no servidor de desenvolvimento X
Banco de dados não suportar demanda X
Tabela 3 - Identificação do Risco
3.2 Tabela de riscos
RISCO CATEGORIA PROB IMPACTO
01 - Servidor de produção indisponível Tecnologia 10 Catastrófico
02 - Custo de implantação ultrapassar o
estipulado
Negócio 30 Crítico
03 - Membros da equipe não possuem
conhecimento sobre as tecnologias utilizadas
Pessoal 30 Crítico
04 - Banco de dados não suportar demanda Tecnologia 30 Crítico
05 - Scripts não funcionam corretamente em
alguns navegadores
Tecnologia 20 Crítico
06 - Impossibilidade de atualizar framework de Tecnologia 80 Marginal

desenvolvimento
07 - Tempo combinado insuficiente para
terminar o sistema
Negócio 30 Marginal
08 - Cliente/usuário passar informações
incorretas das suas necessidades
Cliente 20 Marginal
09 - Falha no Servidor de desenvolvimento Tecnologia 10 Marginal
10 - Ausência de testes regulares e detalhados Processo 60 Desprezável
11 - Legislação ou regra de negócio mudar Negócio 15 Desprezável
12 - Cliente/usuário não se disponibilizar para
fazer entrevistas
Cliente 10 Desprezável
Tabela 4 - Tabela de Risco
3.3 Redução e Gestão do Risco
Análise de Risco 01
Risco: Servidor de Produção Indisponível
Prob: 10 Impacto: Catastrófico
Descrição: O servidor sai do ar, impossibilitando o acesso ao sistema.
Estratégia de redução: Criar servidores espelhos.
Plano de Contingência: Desviar trafego para servidor espelho.
Pessoa Responsável: Carlson Santana
Status: Finalizado
Risco: Custo de implantação ultrapassar o estipulado
Prob: 30 Impacto: Crítico
Descrição: O prazo de entrega será excedido.
Estratégia de redução: Negociar custo realista.
Plano de Contingência: Renegociar custos do sistema.
Pessoa Responsável: Ícaro Torres
Status: Finalizado
Risco: Membros da equipe não possuem conhecimento sobre as tecnologias
utilizadas
Descrição: A equipe nunca trabalhou, ou conhece pouco, sobre as ferramentas

utilizadas
Estratégia de redução: Treinamento para os desenvolvedores.
Plano de Contingência: Contratar desenvolvedores com experiências nas
ferramentas.
Pessoa Responsável: Ícaro Torres
Status: Andamento
Risco: Banco de dados não suportar demanda
Descrição: Banco de dados fica inacessível pela quantidade de requisições.
Estratégia de redução: Realizar otimização nas consultas.
Plano de Contingencia: Mover projeto para um banco de dados mais eficiente.
Pessoa Responsável: Danilo Ferreira
Status: Finalizado
Risco: Scripts não funcionam corretamente em alguns navegadores
Descrição: Funções ou bibliotecas scripts não funcionam corretamente em
determinados navegadores.
Estratégia de redução: Criar avisos recomendando a atualização do navegador.
Plano de Contingência: Bloquear o sistema em navegadores obsoletos.
Status: Finalizado
Risco: Impossibilidade de atualizar framework de desenvolvimento
Prob: 80 Impacto: Marginal
Descrição: A codificação realizada não é compatível com as novas versões do
framework.
Estratégia de redução: Criar novos módulos em uma ferramenta mais atualizada.
Plano de Contingência: Destinar uma equipe para transcrever o sistema para um
novo framework.
Pessoa Responsável: Danilo Neves

Status: Finalizado
Risco: Tempo combinado insuficiente para terminar o sistema
Descrição: O prazo de entrega será excedido.
Estratégia de redução: Usar metodologias de desenvolvimento, negociar prazos
realistas.
Plano de Contingência: Aprovar novos prazos com cliente, liberar os módulos
concluídos do sistema.
Pessoa Responsável: Danilo Duarte
Status: Andamento
Risco: Cliente/usuário passar informações incorretas das suas necessidades
Descrição: Criação de um modulo baseado em uma informação equivocada.
Estratégia de redução: Reuniões frequentes com o cliente e criação de artefatos, tais
como: caso de uso, diagrama de sequência, diagrama de classe.
Plano de Contingência: Mover parte da equipe para refazer módulos com problemas,
se possível com maior presença do cliente.
Status: Andamento
Risco: Falha no servidor de desenvolvimento
Descrição: Impossibilidade de acesso aos dados de desenvolvimento.
Estratégia de redução: Backup periódicos.
Plano de Contingência: Manter repositórios online.
Status: Andamento
Risco: Ausência de testes regulares e detalhados

Prob: 60 Impacto: Desprezável
Descrição: Criação de testes caixa branca e caixa-preta.
Estratégia de redução: Desviar parte dos recursos para criação de uma equipe de
testes.
Plano de Contingência: Contratar uma empresa de testes.
Pessoa Responsável: Danilo Neves
Status: Andamento
Risco: Legislação ou regra de negócio mudar
Descrição: Surgimento de novas regras de negócio ou alteração de uma lei que
influencie direto no funcionamento do sistema.
Estratégia de redução: Equipe atualizada com as novas regras de negócio.
Plano de Contingência: Contratar especialista na área.
Status: Finalizado
Risco: Cliente/usuário não se disponibilizar para fazer entrevistas
Descrição: Cliente não está disponível para participar ativamente do projeto.
Estratégia de redução: Envolver pelo menos dois stakeholder.
Plano de Contingência: Coletar informações com prováveis usuários, conhecer o
possível ambiente de utilização do software.
Status: Andamento

4. PLANEJAMENTO TEMPORAL
Nesta seção definiremos todas as atividades relativas à execução do projeto com
suas respectivas data de execução e prazo. Para auxiliar a visualização de todas as
tarefas, em relação ao aspecto temporal faremos o uso do gráfico de Gantt.
4.1 Conjunto de Tarefas do Projeto
Foi utilizado o modelo de processo em cascata e suas camadas: elicitação,
implementação, testes e implantação.
4.2 Diagrama de Gantt
O Diagrama Gantt pode ser visualizado através deste link: http://versaobeta-
group.blogspot.com.br/2015/02/diagrama-gantt.html.

5. ORGANIZAÇÃO DO PESSOAL
Nesta seção veremos como os recursos humanos alocados no projeto serão utilizados,
assim como será feita a comunicação entre as pessoas envolvidas.
5.1 Estrutura da equipe
Para a execução do projeto, contaremos com a participação de 4 pessoas
que desempenharão papéis necessários para garantir o andamento e o
sucesso final do projeto. Na tabela abaixo, são mostradas as pessoas, suas
funções e a descrição da função:
Tabela 5 - Estrutura da equipe
Papel Responsabilidades Stakeholders
Gerente de Projeto Planejar, supervisionar e
controlar a organização da
equipe.
Ícaro Torres
Engenheiro de
Software
Planejar, supervisionar e
controlar as tarefas técnicas.
Danilo Ferreira e Carlson
Santana
Gerente de Negócio Coordenar as relações de
negócio.
Danilo Duarte
Programador Responsável pela codificação
do sistema.
Danilo Ferreira e Danilo Duarte
Testador Responsável pelo
planejamento e execução dos
testes do sistema
Carlson Santana e Ícaro Torres
5.2 Mecanismos de comunicação
Como os membros do projeto moram distantes uns dos outros, todos
trabalham e estudam, para a realização do projeto foram utilizadas formas de
comunicação a distância como o Gmail para o envio de e-mail e reuniões
através do Hangouts. Para o gerenciamento de projetos foi utilizado o
Freedcamp que possibilita a criação e a atribuição de uma tarefa para
determinada pessoa. Mas mesmo utilizando essas ferramentas a equipe se
reunia a cada 2 semanas para discutir sobre o projeto.
5.3 Uso do Edu-blog como ferramenta de apoio
O uso do Edu-Blog foi fundamental para o andamento e aperfeiçoamento do
projeto. Com ele foi possível conhecer ferramentas de controle de versões
para o projeto que se tornaram um aliado para se obter o sucesso por parte
de toda equipe.

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
Documentação: todos os requisitos foram documentados assim como a
arquitetura e os processos do software, sendo que cada requisito
documentado foi validado pelos stakeholders do projeto.
Testes: a fim de atribuir qualidade final ao produto e minimizar as eventuais
falhas que viesse a ocorrer.
Controle de versões: para manter o histórico das alterações sofridas no
código-fonte do projeto, o que possibilita também o acompanhamento
histórico da evolução do projeto assim como voltar a versões anteriores.
Integração Contínua: em conjunto com o controle de versões e os testes o
servidor de integração contínua assegura que o software sempre será testado
antes de ir para o servidor utilizado pelo usuário e quando ocorria algum erro
nos testes todos eram notificados.

Plano do-projeto-de-software- SACC- LACERTAE

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Plano do-projeto-de-software- SACC- LACERTAE

Semelhante a Plano do-projeto-de-software- SACC- LACERTAE (20)

Plano do-projeto-de-software- SACC- LACERTAE