planodeprojeto gp 2.2
TRANSCRIPT
-
8/13/2019 PlanodeProjeto GP 2.2
1/17
-
8/13/2019 PlanodeProjeto GP 2.2
2/17
UNIVERSIDADE FEDERAL DE SERGIPECENTRO DE CINCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAOGerncia de Projetos 2013.2
PLANO DO PROJETO DE SOFTWAREpara produtos da Lacertae SW
Plnio Eduardo Tlio Souza dos SantosBruno Espndola Matos de Paiva
Philippe Melo da Rocha
So Cristvo Sergipe2014
Trabalho apresentado ao Prof. Dr.Rogrio Patrcio Chagas do Nascimento comonota para disciplina Gerncia de Projetos do
curso de graduao em Sistemas deInformao Bacharelado da UniversidadeFederal de Sergipe (UFS).
-
8/13/2019 PlanodeProjeto GP 2.2
3/17
SUMRIO
1. INTRODUO ...................................................................................................... 4
1.1 mbito do Projeto ............................................................................................ 4
1.2 Funes principais do produto de software ..................................................... 4
1.3 Requisitos comportamentais ou de performance ............................................ 5
1.4 Gesto e Restries Tcnicas ......................................................................... 5
2. ESTIMAES DO PROJETO .............................................................................. 5
2.1 Dados histricos utilizados para as estimaes .............................................. 6
2.2 Tcnicas de estimao e resultados ............................................................... 6
2.2.1 Tcnica de estimao ................................................................................... 6
2.3 Resultados ...................................................................................................... 7
2.4 Recursos do projeto ........................................................................................ 7
2.4.1 Recursos humanos ....................................................................................... 7
2.4.2 Hardware necessrio .................................................................................... 7
2.4.3 Software de suporte ..................................................................................... 7
3. ANLISE E GESTO DE RISCOS....................................................................... 83.1 Riscos do projeto ............................................................................................. 8
3.2 Tabela de riscos .............................................................................................. 8
4. PLANEAMENTO TEMPORAL ............................................................................ 13
4.1 Conjunto de Tarefas Macro do Projeto .......................................................... 13
4.2 Diagrama de Gantt ........................................................................................ 13
5. ORGANIZAO DO PESSOAL ......................................................................... 15
5.1 Estrutura da equipe ....................................................................................... 15
5.2 Mecanismos de comunicao ....................................................................... 16
5.3 Uso do Edu-blog como ferramenta de apoio ................................................. 16
6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW ................................................................ 16
-
8/13/2019 PlanodeProjeto GP 2.2
4/17
1. INTRODUO
O sistema de controle de infeces um produto de software que tem como objetivodigitalizar e armazenar em um banco de dados, as infeces, assim como suas ocorrnciasque so identificadas em ambientes hospitalares. A principal motivao para sua concepo foio fato de que muitos hospitais ainda armazenam suas informaes em meio fsico (papel), deforma que este material no integrado rede de computadores, no possui um banco dedados seguro e nem restrio adequada s informaes.
1.1 mbito do Projeto
O software armazena dados de infeces e ocorrncia destas, informando tambm o
local de sua ocorrncia. Como entradas principais, temos: Nomeda infeco, localno qual ainfeco foi detectada, gravidade da infeco e data na qual a infeco foi identificada. Assadas principais so os relatrios nos quais trazem o histrico das ocorrncias.
1.2 Funes principais do produto de software
Abaixo temos um diagrama de use-case que mostra ilustrativamente os atores queatuam no sistema de controle de infeces e uma tabela mais detalhada onde so listadas asprincipais funes do sistema, respeitando o controle de acesso por cada ator:
-
8/13/2019 PlanodeProjeto GP 2.2
5/17
Ator Funcionalidades
Usurio
Autenticar usurio Alterar senha Consultar usurios Consultar infeces Consultar ocorrncias de infeces
Infectologista(Especializao de
Usurio)
Emitir relatrios Adicionar recomendaes para tratamento das infeces Cadastrar infeces Cadastrar ocorrncias de infeces Enviar ocorrncias de infeces para a vigilncia sanitria Tratar ocorrncias de infeces Alterar dados de infeces Alterar dados de ocorrncias de infeces
Administrador(Especializao deUsurio)
Cadastrar usurios Alterar dados dos usurios Bloquear usurios Ativar usurios Alterar configuraes do sistema
1.3 Requisitos comportamentais ou de performance
O produto apresentado tem como requisito uma interface de fcil usabilidade e oatendimento s restries de acesso. Como foi mostrado, cada tipo de usurio do distema tempermisso para utilizar funcionalidades especficas no sistema, sendo que ao efetuar o login, detectado o tipo de usurio, restringindo assim as outras funes. Quanto performance o
produto requer as caractersticas de hardware definidas no documento de implantao dosoftware.
As infeces e ocorrncias no podem ser excludas do sistema, pois necessrio queo histrico fique armazenado para consultas posteriores. Para as ocorrncias de infeces,como so associadas ao infectologista que a cadastrou e local onde ocorreu, estes tambmno podem ser excludos do sistema.
1.4 Gesto e Restries Tcnicas
Algumas restries tcnicas so listadas abaixo:
O sistema de controle de infeces ser desenvolvido com a linguagem deprogramao Java;
Deve usar o sistema de banco de dados Microsoft SQL Server 2008 R2; O sistema requer que o hospital tenha uma estrutura de intranet para acesso entre os
computadores; O sistema ser uma aplicao desktop.
2. ESTIMAES DO PROJETO
-
8/13/2019 PlanodeProjeto GP 2.2
6/17
Nesta seo sero apresentadas as estimaes de tempo necessrio para a realizaodo projeto. Alm disso, ser considerado os recursos que sero utilizados. Atravs dessasinformaes ser possvel ter uma viso mais precisa do custo, esforo e tempo total que serempenhado no projeto.
2.1 Dados histricos utilizados para as estimaes
Tendo em vista desse ser o primeiro projeto dos integrantes da equipe, no serpossvel utilizar dados histricos para as estimaes do projeto.
2.2 Tcnicas de estimao e resultados
O nosso projeto utilizar a mtrica de Lorenz & Kidd para calcular o tempo necessrio
para a realizao do projeto. A utlizao de uma tcnica de estimao importante parafornecer indicadores que possibilitem avaliar de modo aprofundado o projeto.
2.2.1 Tcnica de estimao
A tcnica de estimao elaborada por Lorenz & Kidd orientada a classes.Para determinar o tempo necessrio para a realizao do projeto, deve-se seguir osseguintes passos:
1. Determinar atravs do diagrama de classes do domnio a quantidade declasses chaves.
2. Classificar o tipo de interface do produto utilizando a tabela abaixo:
3. Calcular a quantidade de classes de suporte ao multiplicar o nmero declasses chave pelo multiplicador da interface.
4. Somar a quantidade de classes chave e de suporte e multiplicar pelonmero mdio de unidades de trabalho por classe para determinar aquantidade de esforo estimada.
De acordo com o diagrama de classes, identificamos que o software possui 7
-
8/13/2019 PlanodeProjeto GP 2.2
7/17
-
8/13/2019 PlanodeProjeto GP 2.2
8/17
dados relacional da Microsoft. NetBeans IDE 6.9.1: IDE utilizada para desenvolvimento. iReport 1.3.1: Ferramente Java de relatrio.
3. ANLISE E GESTO DE RISCOS
Nesta seo, analisaremos os riscos de acordo com suas classificaes e com base nasua probabilidade e seu impacto no projeto.
3.1 Riscos do projeto
Abaixo podemos verificar a tabela de riscos de acordo com sua clasificao.
RiscoProjetoTcnicoNegcioComumEspecial
Sada de um dos integrantes daequipe
XX
Falta de conhecimento donegcio
XX
Falta de treinamento disponvelXX
Cliente no tem muito tempo paralevantamento de requisitos.
XX
Pouca experincia emdesenvolvimento
XX
Desenvolvedores no possuemtempo integral para odesenvolvimento do produto
XX
Alterao dos requisitos durante aconstruo ou at mesmo aps aentrega.
XX
Grande nmero de usuriosXX
Tamanho do banco de dadosXX
Interface especializada paradeterminado usurio
XX
3.2 Tabela de riscos
Tabela de riscos, identificadas as suas probabilidades de ocorrncia e impactoesperado.
-
8/13/2019 PlanodeProjeto GP 2.2
9/17
-
8/13/2019 PlanodeProjeto GP 2.2
10/17
2 - Risco: Falta de conhecimento do negcio
Probabilidade: 80%
Impacto: Crtico
Descrio: Negcio do projeto desconhecido por todos os integrantes
Estratgia de reduo: Estudar a respeito do negcio e buscar orientao depessoas que conheam e possuam experincia no negcio.
Plano de contingncia: Ter uma pessoa disponvel a ser consultada em caso denecessidade.
Responsvel: Bruno EspndolaStatus: Em andamento
3 - Risco: Falta de treinamento disponvel
Probabilidade: 80%
Impacto: Crtico
Descrio: Integrantes no possuem treinamento necessrio
Estratgia de reduo: Utilizar cursos online, fruns na internet e orientao deprofissionais da rea.
Plano de contingncia: Ter uma pessoa disponvel a ser consultada em caso denecessidade.
Responsvel: Bruno Espndola
Status: Em andamento
4 - Risco: Cliente no tem muito tempo para levantamento de requisitos
Probabilidade: 75%
Impacto: Crtico
Descrio: Cliente no possui muito tempo disponvel para discutir os requisitos doprojeto.
Estratgia de reduo: Utilizar de etnografia e questionrios para o levantamentodos requisitos.
Plano de contingncia: Preparar-se bem para a entrevista e grav-la para consultas
-
8/13/2019 PlanodeProjeto GP 2.2
11/17
futuras.
Responsvel: Philippe Melo
Status: Em andamento
5 - Risco: Pouca experincia em desenvolvimento
Probabilidade: 70%
Impacto: Crtico
Descrio: Integrantes nunca construram um projeto de software antes
Estratgia de reduo: Se planejar bem para o projeto e buscar fazer um projetoeficaz, porm enxuto e simples.
Plano de contingncia: Ter uma pessoa disponvel a ser consultada em caso denecessidade.
Responsvel: Bruno Espndola
Status: Em andamento
6 - Risco: Desenvolvedores no possuem tempo integral para odesenvolvimento do produto
Probabilidade: 70%
Impacto: Crtico
Descrio: Integrantes realizam outras atividades e no podem se dedicarexclusivamente ao projeto.
Estratgia de reduo: Evitar desperdcio de tempo e simplificar o projeto aomximo.
Plano de contingncia: Programar de madrugada e nos fins de semana.
Responsvel: Plnio Santos
Status: Em andamento
7 - Risco: Alterao dos requisitos durante a construo ou at mesmo aps aentrega desenvolvimento do produto
Probabilidade: 60%
Impacto: Crtico
-
8/13/2019 PlanodeProjeto GP 2.2
12/17
Descrio: Solicitao de alteraes aps o levantamento de requisitos.
Estratgia de reduo: Fazer uso de prototipao para que alteraes necessriassejam identificadas logo e no apenas ao final do projeto.
Plano de contingncia: Entregar prottipos periodicamente.
Responsvel: Philippe Melo
Status: Em andamento
8 - Risco: Grande nmero de usurios
Probabilidade: 40%
Impacto: Moderado
Descrio: Haver muitos usurios e assim um grande nmero de acessossimultneos.
Estratgia de reduo: Implantar servidores robustos.
Plano de contingncia: Monitorar utilizao dos usurios e deslogar em caso detempo de inatividade superior a 2 horas.
Responsvel: Philippe Melo
Status: Em andamento
9 - Risco: Perda de algum dado do banco de dados
Probabilidade: 40%
Impacto: Moderado
Descrio: Possibilidade dehaver alguma falha no banco de dados e perder dadosimportantes
Estratgia de reduo: Utilizar espelhamento do banco de dadosPlano de contingncia: Fazer uso peridico de backup.
Responsvel: Plnio Santos
Status: Em andamento
10 - Risco: Interface especializada para determinado usurio
Probabilidade: 30%
-
8/13/2019 PlanodeProjeto GP 2.2
13/17
Impacto: Marginal
Descrio: Existem diferentes tipos de usurios, cada um com um nvel de restrioespecfico.
Estratgia de reduo: No deixar visvel o que o usurio no possui permisso.
Plano de contingncia: Monitorar o uso para que no haja acessos indevidos emcaso de erro.
Responsvel: Plnio Santos
Status: Em andamento
4. PLANEAMENTO TEMPORAL
Nesta seo iremos definir todas as atividades relativas a execuo do projeto, comsuas respectivas data de execuo e prazo. Para auxiliar a visualizao de todas tarefas, emrelao ao aspecto temporal faremos o uso do grfico de Gannt.
4.1 Conjunto de Tarefas Macro do Projeto
Tarefas MacroPorcentagemDias de Trabalho
Planejamento4%14Anlise de Requisitos eModelagem
37%70
Codificao25%45
Testes32%42
Total de dias de trabalho = 176 dias.
4.2 Diagrama de Gantt
Na figura 1 temos o cronograma com a descrio de todas as atividades doprojeto e na figura 2 temos a representao deste cronograma de forma temporalatravs do Diagrama de Gannt.
-
8/13/2019 PlanodeProjeto GP 2.2
14/17
Figura 1
-
8/13/2019 PlanodeProjeto GP 2.2
15/17
5. ORGANIZAO DO
Nesta seo veremosassim como ser feita a com
5.1 Estrutura da equipe
Para a execuiro desempenhar pa
projeto. Abaixo vererespectivas funes:
DescResponsvel
Respativid
Plnio Eduardo
Respativid
Bruno Espindola
Figura 2
ESSOAL
como os recursos humanos alocados no pnicao entre as pessoas envolvidas.
o do projeto, contaremos com a participapis necessrios para garantir o andament
os a tabela com os recursos alocados
rio
nsvel por gerenciar e acompanhar asdes executadas pela equipe do projeto.
svel pelo levantamento de requisitos edes de anlise e projeto no qual ir
ojeto sero utilizados,
o de 3 pessoas quee o sucesso final do
ara o projeto e suas
Papel
Gerente de Projeto
nalista de Sistema
-
8/13/2019 PlanodeProjeto GP 2.2
16/17
-
8/13/2019 PlanodeProjeto GP 2.2
17/17
Para alinhar a expectativa do cliente com o andamento do projeto, foramrealizadas algumas reunies em etapas do projeto, nas quais a equipe discutia oandamento do projeto juntamente com o cliente.
Controle de verses:
Para a confeco dos documentos foram utilizados histricos de revises comobjetivo de melhor identificar as alteraes realizadas e sempre informando oresponsvel pela alterao. No desenvolvimento de software foi realizado o controle deverses atribuindo marcos nos quais representavam algum tipo de alterao, seja elade melhoria, correo ou at mesmo a incluso de uma nova funcionalidade.
Documentao atualizada:
Durante o projeto, a equipe se preocupou e tomou como compromisso realizar aatualizao da documentao do sistema sempre que uma alterao em nvel deprojeto era realizada. Essa preocupao com a documentao do sistema foi alcanadapela rigidez que os testes demandavam afim de que o sistema estivesse totalmente deacordo com as especificaes.
Testes:
Afim de atribuir qualidade final ao produto e minimizar as eventuais falhas queviesse a ocorrer, os testes foram realizados em 3 nveis, no nvel unitrio no qual erarealizado pelo prprio programador, nvel de integrao e de sistema ambos realizadospelo Analista de Teste e testador.