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.

http://versaobeta-group.blogspot.com.br/2015/02/diagrama-gantt.html

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

Technology