PlanodeProjeto GP 2.2

download PlanodeProjeto GP 2.2

of 17

Transcript of PlanodeProjeto GP 2.2

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