PlanodeProjeto GP 3.2

8/13/2019 PlanodeProjeto GP 3.2

1/18

UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CINCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAO Gerncia de Projetos 2013.2

PLANO DO PROJETO DE SOFTWARE para produtos da Lacertae SW

Plnio Eduardo Tlio Souza dos Santos Bruno Espndola Matos de PaivaPhilippe Melo da Rocha

So Cristvo Sergipe 2014


2/18

UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CINCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAO Gerncia de Projetos 2013.2

PLANO DO PROJETO DE SOFTWARE para produtos da Lacertae SW

Plnio Eduardo Tlio Souza dos Santos Bruno Espndola Matos de Paiva

Philippe Melo da Rocha

So Cristvo Sergipe 2014

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).


3/18

SUMRIO

1. INTRODUO ...................................................................................................... 41.1 mbito do Projeto ............................................................................................ 41.2 Funes principais do produto de software ..................................................... 41.3 Requisitos comportamentais ou de performance ............................................ 51.4 Gesto e Restries Tcnicas ......................................................................... 5

2. ESTIMAES DO PROJETO .............................................................................. 52.1 Dados histricos utilizados para as estimaes .............................................. 6

2.2 Tcnicas de estimao e resultados ............................................................... 62.2.1 Tcnica de estimao ................................................................................... 62.3 Resultados ...................................................................................................... 72.4 Recursos do projeto ........................................................................................ 82.4.1 Recursos humanos ....................................................................................... 82.4.2 Hardware necessrio .................................................................................... 82.4.3 Software de suporte ..................................................................................... 8

3. ANLISE E GESTO DE RISCOS....................................................................... 83.1 Riscos do projeto ............................................................................................. 83.2 Tabela de riscos .............................................................................................. 9

4. PLANEAMENTO TEMPORAL ............................................................................ 144.1 Conjunto de Tarefas Macro do Projeto .......................................................... 144.2 Diagrama de Gantt ........................................................................................ 14

5. ORGANIZAO DO PESSOAL ......................................................................... 165.1 Estrutura da equipe ....................................................................................... 165.2 Mecanismos de comunicao ....................................................................... 175.3 Uso do Edu-blog como ferramenta de apoio ................................................. 17

6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR AQUALIDADE DO PRODUTO DE SW ................................................................ 17


4/18

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 as ocorrncias queso identificadas em ambientes hospitalares. A principal motivao para sua concepo foi ofato 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 olocal de sua ocorrncia. Como entradas principais, temos:nome da infeco, local no 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

Na figura 1 temos um diagrama de use-case que mostra ilustrativamente os atores queatuam no sistema de controle de infeces e natabela 1, mostrado detalhadamente asprincipais funes do sistema, respeitando o controle de acesso por cada ator (usurios):

Figura 1: Diagrama de Use-Case


5/18

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

Tabela 1: Descrio da especialidade dos usurios

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 sistema 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, oproduto 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 ao 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


6/18

Nesta seo sero apresentadas as estimaes de tempo necessrio para a realizao

do projeto. Alm disso, ser considerado os recursos que sero utilizados. Atravs dessasinformaes ser possvel ter uma visomais aproximada do custo, esforo e tempo totalque ser empenhado no projeto.

2.1 Dados histricos utilizados para as estimaes

Tendo em vista deste 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 necessriopara a realizao do projeto. A utilizao 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 atabela 2, abaixo:

Tabela 2: Classificao do tipo de interface do produto

3. Calcular a quantidade de classes de suporte ao multiplicar o nmero de classeschave pelo multiplicador da interface.

4. Somar a quantidade de classes chave e de suporte e multiplicar pelo nmeromdio de unidades de trabalho por classe para determinar a quantidade deesforo estimada.


7/18

De acordo com o diagrama de classes,na figura 2, identificamos que o software

possui 7 classes chaves. Utilizando interface grfica, com fator multiplicador de 2,5,teremos 18 classes de suporte totalizando 25 classes.

Figura 2: Diagrama de Classes

2.3 Resultados

Para realizarmos as estimaes atravs da tcnica de Lorenz & Kidd utilizamoso diagrama de classes de domnio,exibido na figura 2. Aps a anlise do diagrama edas consideraes da tcnica utilizada, podemos obter as seguintes concluses:

1. Classes chaves: 7 classes.2. Tipo de interface: GUI simples.3. Classes de suporte: 7 (n de classes chaves) x 2,5 (multiplicador) = 18

classes.4. Total de classes: 7(n de classes chaves) + 18 (classes de suporte) = 25

classes.5. Como unidade mdia de trabalho por classe, utilizaremos 20 dias-pessoa.

Sendo assim, 25 (total de classes) x 20 (dias-pessoa) = 500 dias-pessoa.6. Sendo 3 o nmero de integrantes do projeto, teremos que ser


8/18

necessrio aproximadamente 167 dias para a realizao do projeto.

2.4 Recursos do projeto

2.4.1 Recursos humanos

Analista de software Arquiteto de software Gestor de projeto Analista de Teste Testador

2.4.2 Hardware necessrio

Processador Core 2 Duo ou superior Memria RAM de 4GB ou superior Disco Rgido de 200 GB ou superior

2.4.3 Software de suporte

JDK - Java SE Development Kit 1.7: Kit de desenvolvimento Java queprov o ambiente necessrio para se programar em Java.

Adobe Acrobat Reader 9.0: Leitor de arquivos em formato PDF. Microsoft Net Framework 4.0: Framework de ambiente de

desenvolvimento e execuo desenvolvido pela Microsoft. Microsoft SQL Server 2008 R2: Sistema de gerenciamento de banco de

dados relacional da Microsoft. NetBeans IDE 6.9.1: IDE utilizada para desenvolvimento. iReport 1.3.1: Ferramenta 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 atabela 3, onde mostra os riscos de acordo com suaclassificao.

Risco Projeto Tcnico Negcio Comum Especial

Sada de um dos integrantes daequipe

X X


9/18

Falta de conhecimento donegcio

X X

Falta de treinamento disponvelX X

Cliente no tem muito tempo paralevantamento de requisitos.

X X

Pouca experincia emdesenvolvimento

X X

Desenvolvedores no possuemtempo integral para odesenvolvimento do produto

X X

Alterao dos requisitos durante aconstruo ou at mesmo aps aentrega.

X X

Grande nmero de usurios podederrubar a rede

X X

Tamanho do banco de dadosX X

Interface especializada paradeterminado usurio

X X

Tabela 3: Tabela de riscos de acordo com a classificao

3.2 Tabela de riscos

Abaixo temos a tabela 4, identificando os riscos e suas probabilidades deocorrncia e impacto esperado.

Risco% ProbabilidadeImpacto

Sada de um dos integrantes da equipe30Catastrfico

Falta de conhecimento do negcio80Crtico

Falta de treinamento disponvel80Crtico

Cliente no tem muito tempo para levantamento derequisitos.

75Crtico

Pouca experincia em desenvolvimento70Crtico

Desenvolvedores no possuem tempo integral para odesenvolvimento do produto

70Crtico


10/18

Alterao dos requisitos durante a construo ou atmesmo aps a entrega.

60Crtico

Grande nmero de usurios pode derrubar a rede40Moderado

Perda de dados do banco de dados40Moderado

Interface especializada para determinado usurio30Marginal

Tabela 4: Tabela de riscos de acordo com a probabilidade de ocorrncia e impactos

3.3 Reduo e Gesto do Risco

Levando em considerao os riscos j identificados, elaboramos um plano para

reduzir e gerir os riscos caso venham a ocorrer.

1 - Risco: Sada de um dos integrantes da equipe

Probabilidade: 30%

Impacto: Catastrfico

Descrio: H apenas 3 pessoas envolvidas no projeto e no h garantia que todospermaneam at o final do projeto.

Estratgia de reduo: Integrantes devem se reunir regularmente para que possamacompanhar o trabalho um do outro. Alm disso, devem compartilhar os artefatosdisponveis e resultados atingidos para que possam motivar os integrantes apermanecerem no projeto at o final.

Plano de contingncia: Caso um integrante saia, deve-se identificar as prioridadesdo projeto, negociar um prazo maior com a promessa de entregar incrementos nesteperodo.

Responsvel: Plnio Santos

Status: Em andamento

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 motivar a participao docliente no projeto.


11/18

Plano de contingncia: Contatar o cliente sempre que necessrio.

Responsvel: Bruno Espndola


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: Contratar cursos e treinamento para os integrantes.



4 - Risco: Cliente no tem muito tempo para levantamento de requisitos

Probabilidade: 75%

Impacto: Crtico

Descrio: Cliente no tempo muito tempo disponvel para discutir os requisitos doprojeto.

Estratgia de reduo: Utilizar de etnografia, questionrios para o levantamento dosrequisitos e enviar artefatos do projeto atravs de e-mail e Google Drive.

Plano de contingncia: Preparar-se bem para a entrevista, grav-la para consultasfuturas e seguir notas e depoimentos no projeto.

Responsvel: Philippe MeloStatus: Em andamento

5 - Risco: Pouca experincia em desenvolvimento

Probabilidade: 70%

Impacto: Crtico

Descrio: Integrantes nunca construram um projeto de software antes


12/18

Estratgia de reduo: Aplicar boas prticas de desenvolvimento

Plano de contingncia: Consultar profissionais e professores experientes emdesenvolvimento.



6 - Risco: Desenvolvedores no possuem tempo integral para odesenvolvimento do produto

Probabilidade: 70%

Impacto: CrticoDescrio: Integrantes realizam outras atividades e no podem se dedicarexclusivamente ao projeto.

Estratgia de reduo: Evitar desperdcio de tempo e recursos.

Plano de contingncia: Fazer bom uso do tempo disponvel e utilizar ferramentas denuvem que possibilitem alteraes por mltiplas pessoas em tempo real.

Responsvel: Plnio Santos


7 - Risco: Alterao dos requisitos durante a construo ou at mesmo aps aentrega desenvolvimento do produto

Probabilidade: 60%

Impacto: Crtico

Descrio: Possibilidade de haver solicitao de alteraes aps o levantamento derequisitos.

Estratgia de reduo: Fazer uso de prototipao para que alteraes necessriassejam identificadas de imediato pelo cliente.

Plano de contingncia: Entregar prottipos ao cliente periodicamente.

Responsvel: Philippe Melo


8 - Risco: Grande nmero de usurios pode derrubar a rede


13/18


14/18


4. PLANEJAMENTO TEMPORAL

Nesta seo iremos definir todas as atividades relativas execuo do projeto comsuas respectivas data de execuo e prazo. Para auxiliar a visualizao de todas as tarefas,em relao ao aspecto temporal faremos o uso do grfico de Gantt.

4.1 Conjunto de Tarefas Macro do Projeto

Abaixo temos atabela 5, onde mostrado a relao das tarefas macro, dias de trabalho eporcentagem ao qual faz parte.

Tarefas Macro Porcentagem Dias de Trabalho

Planejamento4%14

Anlise de Requisitos eModelagem

37%70

Codificao25%45

Testes32%42

Tabela 5: Relao das tarefas macro e dias de trabalho

Total de dias de trabalho = 176 dias.

4.2 Diagrama de Gantt

Na figura 3 temos o cronograma com a descrio de todas as atividades do projeto. Ametodologia utilizada para desenvolvimento do projeto foi o RUP no qual a composio dasatividades se baseou. Seguindo o processo do RUP, o projeto foi dividido em quatro fases.

Na fase 1, fase de Concepo/Iniciao foi realizado a concepo geral do projeto,tendo como atividades realizar o levantamento de requisitos de software e logo aps o aelaborao da especificao dos requisitos que iro compor o software a ser desenvolvido.

Na fase 2, fase de elaborao, foi realizada a anlise mais detalhada do problema naqual pode-se criar modelagem dos componentes, criar os diagramas e criar os prottipos deinterface. Todos estes artefatos criados na fase 2, como podemos ver na figura 1 do item de Id6 ao item de Id 14, sero utilizados na fase 3 que a fase de construo ou codificao.

Na fase 3, a fase na qual ser desenvolvido todos os componentes criados na fase 2.Nesta fase ser codificado todas as funcionalidades do software para que seja passado para aprxima fase.


15/18

Na fase 4, fase de trrealizado todos os testes cdesenvolvido como tambmna qual ser entregue o prod

No final de cada faserealizada uma reunio decomponentes da equipe puddiscutir as dvidas e dificuldno qual tinha papel fundame

Figura 3:

nsio, como podemos ver nos itens de Id om o objetivo de assegurar que o espe

nesta fase ser realizada uma reunio de fto final que o software pronto.

do processo, como podemos ver nos itensalinhamento e planejamento do projetoessem acompanhar o que foi realizado nades do projeto. Nas reunies tambm esttal para o acompanhamento e a validao d

Cronograma com as descries das ativida

31, 32, 33 e 34, serificado foi realmente

echamento do projeto

e Id 4, 14, 29 e 33, foipara que todos os

s atividades, alm deva presente o cliente,e cada fase.

es


16/18

Na figura 4, temos aDiagrama de Gantt, nele poqual momento cada atividad

5. ORGANIZAO DO

Nesta seo veremos

assim como ser feita a com

5.1 Estrutura da equipe

Para a execuo dodesempenhar papis necesAbaixo veremos natabelafunes:

representao do cronograma de forma tememos ver por os recursos alocados para ca

e ser executada.

Figura 4: Diagrama de Gantt

ESSOAL

como os recursos humanos alocados no p

nicao entre as pessoas envolvidas.

projeto, contaremos com a participao drios para garantir o andamento e o suc, com os recursos alocados para o proje

poral atravs doda atividade e em

ojeto sero utilizados,

3 pessoas que iroesso final do projeto.to e suas respectivas


17/18

Papel DescrioResponsvel

Gerente de ProjetoResponsvel por gerenciar e acompanhar asatividades executadas pela equipe do projeto.

Plnio Eduardo

Analista de SistemaResponsvel pelo levantamento de requisitos eatividades de anlise e projeto no qual irelaborar todos os diagramas necessrios paraa codificao do software.

Bruno Espindola

ArquitetoResponsvel pelo projeto arquitetural dosistema, incluindo os diagramas de projeto.

Bruno Espindola

ProgramadorResponsvel pela codificao do sistema.Philippe Melo

Analista de TesteResponsvel pelo planejamento de testes desistema.Plnio Eduardo

TestadorResponsvel pela execuo dos testes dosistema.

Plnio Eduardo

Tabela 6: Relao entre atividades, responsvel e papel do mesmo no projeto

5.2 Mecanismos de comunicao

No projeto uma das formas de comunicao entre os membros da equipe foi oemail. O email foi utilizado bastante entre os membros da equipe e cliente para troca deinformaes, tirar dvidas e discutir andamento do projeto. Alm do email, foi utilizadotambm o Gtalk para uma rpida comunicao entre os membros envolvidos no projeto.

O Google Drive foi utilizado como ferramenta de colaborao que possibilitou aconfeco e acompanhamento entre os envolvidos no projeto.

Reunies presenciais eram realizadas a cada 15 dias para analisar o andamentodo projeto. Nestas, era abordado as dvidas e problemas encontrados pelos membrosda equipe e realizava-se o alinhamento das expectativas.

5.3 Uso do Edu-blog como ferramenta de apoio

O uso do Edu-Blog foi fundamental para o andamento e aperfeioamento doprojeto. Com ele foi possvel conhecer ferramentas case para o gerenciamento deprojeto que se tornaram um aliado para se obter o sucesso por parte de toda equipe,principalmente para o gestor de projeto.

O blog tambm desempenhou um papel importante por se tratar de umaferramenta na qual podemos compartilhar e disseminar os conhecimentos assimiladoscomo tambm obter novos conhecimentos que serviram para o aperfeioamento dealgumas atividades do projeto.

6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO


18/18

PRODUTO DE SW

Com a finalidade de garantir a qualidade de todas as fases do projeto, algumaspreocupaes foram tomadas:

Participao do cliente nas validaes do Projeto:

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:

A fim 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.

PlanodeProjeto GP 3.2

Documents

Transcript of PlanodeProjeto GP 3.2