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

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

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

Trabalho apresentado ao Prof. Dr. Rogrio Patrcio Chagas do Nascimento como nota para disciplina Gerncia de Projetos do curso de graduao em Sistemas de Informao Bacharelado da Universidade Federal de Sergipe (UFS).

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

So Cristvo Sergipe 2014

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 ........................................................................................ 8 2.4.1 Recursos humanos....................................................................................... 8 2.4.2 Hardware necessrio.................................................................................... 8 2.4.3 Software de suporte ..................................................................................... 8 3. ANLISE E GESTO DE RISCOS....................................................................... 8 3.1 Riscos do projeto ............................................................................................. 8 3.2 Tabela de riscos .............................................................................................. 9 4. PLANEAMENTO TEMPORAL ............................................................................ 14 4.1 Conjunto de Tarefas Macro do Projeto .......................................................... 14 4.2 Diagrama de Gantt ........................................................................................ 14 5. ORGANIZAO DO PESSOAL ......................................................................... 16 5.1 Estrutura da equipe ....................................................................................... 16 5.2 Mecanismos de comunicao ....................................................................... 17 5.3 Uso do Edu-blog como ferramenta de apoio ................................................. 17 6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW ................................................................ 17

1. INTRODUO O sistema de controle de infeces um produto de software que tem como objetivo digitalizar e armazenar em um banco de dados, as infeces, assim como as ocorrncias que so identificadas em ambientes hospitalares. A principal motivao para sua concepo foi o fato de que muitos hospitais ainda armazenam suas informaes em meio fsico (papel), de forma que este material no integrado rede de computadores, no possui um banco de dados 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: nome da infeco, local no qual a infeco foi detectada, gravidade da infeco e data na qual a infeco foi identificada. As sadas 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 que atuam no sistema de controle de infeces e na tabela 1, mostrado detalhadamente as principais funes do sistema, respeitando o controle de acesso por cada ator (usurios):

Figura 1: Diagrama de Use-Case

Ator Usurio

Infectologista (Especializao de Usurio)

Administrador (Especializao de Usurio)

Funcionalidades Autenticar usurio Alterar senha Consultar usurios Consultar infeces Consultar ocorrncias de infeces 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 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 o atendimento s restries de acesso. Como foi mostrado, cada tipo de usurio do sistema tem permisso 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 do software. As infeces e ocorrncias no podem ser excludas do sistema, pois necessrio que o 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 tambm no 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 de programao 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

Nesta seo sero apresentadas as estimaes de tempo necessrio para a realizao do projeto. Alm disso, ser considerado os recursos que sero utilizados. Atravs dessas informaes ser possvel ter uma viso mais aproximada do custo, esforo e tempo total que 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 ser possvel 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 utilizao de uma tcnica de estimao importante para fornecer 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 os seguintes passos: 1. Determinar atravs do diagrama de classes do domnio a quantidade de classes chaves. 2. Classificar o tipo de interface do produto utilizando a tabela 2, abaixo:

Tabela 2: Classificao do tipo de interface do produto 3. Calcular a quantidade de classes de suporte ao multiplicar o nmero de classes chave pelo multiplicador da interface. 4. Somar a quantidade de classes chave e de suporte e multiplicar pelo nmero mdio de unidades de trabalho por classe para determinar a quantidade de esforo estimada.

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 utilizamos o diagrama de classes de domnio, exibido na figura 2. Aps a anlise do diagrama e das 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

necessrio aproximadamente 167 dias para a realizao do projeto. 2.4 Recursos do projeto 2.4.1 Recursos humanos 2.4.2 Analista de software Arquiteto de software Gestor de projeto Analista de Teste Testador

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 que prov 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 na sua probabilidade e seu impacto no projeto. 3.1 Riscos do projeto Abaixo podemos verificar a tabela 3, onde mostra os riscos de acordo com sua classificao. Especial X Comum Negcio Tcnico Projeto X Risco Sada de um dos integrantes da equipe

X X X X X

X X X X X

Falta de negcio

conhecimento

do

Falta de treinamento disponvel Cliente no tem muito tempo para levantamento de requisitos. Pouca experincia desenvolvimento em

Desenvolvedores no possuem tempo integral para o desenvolvimento do produto Alterao dos requisitos durante a construo ou at mesmo aps a entrega. Grande nmero de usurios pode derrubar a rede Tamanho do banco de dados Interface especializada determinado usurio para

X X X X

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 de ocorrncia e impacto esperado. Impacto Catastrfico Crtico Crtico Crtico Crtico Crtico % Probabilidade 30 80 80 75 70 70 Risco Sada de um dos integrantes da equipe Falta de conhecimento do negcio Falta de treinamento disponvel Cliente no tem muito tempo para levantamento de requisitos. Pouca experincia em desenvolvimento Desenvolvedores no possuem tempo integral para o desenvolvimento do produto

Crtico Moderado Moderado Marginal

60 40 40 30

Alterao dos requisitos durante a construo ou at mesmo aps a entrega. Grande nmero de usurios pode derrubar a rede Perda de dados do banco de dados Interface especializada para determinado usurio

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 todos permaneam at o final do projeto. Estratgia de reduo: Integrantes devem se reunir regularmente para que possam acompanhar o trabalho um do outro. Alm disso, devem compartilhar os artefatos disponveis e resultados atingidos para que possam motivar os integrantes a permanecerem no projeto at o final. Plano de contingncia: Caso um integrante saia, deve-se identificar as prioridades do projeto, negociar um prazo maior com a promessa de entregar incrementos neste perodo. 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 do cliente no projeto.

Plano de contingncia: Contatar o cliente sempre que necessrio. Responsvel: Bruno Espndola Status: 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 de profissionais da rea. Plano de contingncia: Contratar cursos e treinamento para os integrantes. Responsvel: Bruno Espndola Status: Em andamento

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 do projeto. Estratgia de reduo: Utilizar de etnografia, questionrios para o levantamento dos requisitos e enviar artefatos do projeto atravs de e-mail e Google Drive. Plano de contingncia: Preparar-se bem para a entrevista, grav-la para consultas futuras e seguir notas e depoimentos no projeto. 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: Aplicar boas prticas de desenvolvimento Plano de contingncia: Consultar profissionais e professores experientes em desenvolvimento. Responsvel: Bruno Espndola Status: Em andamento

6 - Risco: Desenvolvedores desenvolvimento do produto Probabilidade: 70% Impacto: Crtico

no

possuem

tempo

integral

para

Descrio: Integrantes realizam outras atividades e no podem se dedicar exclusivamente ao projeto. Estratgia de reduo: Evitar desperdcio de tempo e recursos. Plano de contingncia: Fazer bom uso do tempo disponvel e utilizar ferramentas de nuvem que possibilitem alteraes por mltiplas pessoas em tempo real. Responsvel: Plnio Santos Status: Em andamento

7 - Risco: Alterao dos requisitos durante a construo ou at mesmo aps a entrega desenvolvimento do produto Probabilidade: 60% Impacto: Crtico Descrio: Possibilidade de haver solicitao de alteraes aps o levantamento de requisitos. Estratgia de reduo: Fazer uso de prototipao para que alteraes necessrias sejam identificadas de imediato pelo cliente. Plano de contingncia: Entregar prottipos ao cliente periodicamente. Responsvel: Philippe Melo Status: Em andamento

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

Probabilidade: 40% Impacto: Moderado Descrio: Devido ao grande nmero de usurios existentes, existe o risco de um alto nmero de acessos simultneos derrubar a rede. Estratgia de reduo: Implantar servidores robustos. Plano de contingncia: Monitorar a utilizao dos usurios e definir uma poltica de regras de utilizao. Responsvel: Philippe Melo Status: Em andamento

9 - Risco: Perda de algum dado do banco de dados Probabilidade: 40% Impacto: Moderado Descrio: Possibilidade de haver alguma falha no banco de dados e perder dados importantes Estratgia de reduo: Utilizar espelhamento do banco de dados Plano de contingncia: Fazer uso peridico de backup. Responsvel: Plnio Santos Status: Em andamento

10 - Risco: Interface especializada para perfis de usurio Probabilidade: 30% Impacto: Marginal Descrio: Existem diferentes tipos de usurios com perfis distintos. Pode haver acessos a funcionalidades indevidas. Estratgia de reduo: No deixar visvel as funcionalidades que o usurio no possui permisso. Plano de contingncia: Monitorar o uso para que no haja acessos indevidos em caso de erro. Responsvel: Plnio Santos

Status: Em andamento 4. PLANEJAMENTO TEMPORAL Nesta seo iremos definir todas as atividades relativas execuo do projeto com suas 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 a tabela 5, onde mostrado a relao das tarefas macro, dias de trabalho e porcentagem ao qual faz parte. Dias de Trabalho 14 70 45 42 Porcentagem 4% 37% 25% 32% Tarefas Macro Planejamento Anlise de Modelagem Codificao Testes Requisitos e

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. A metodologia utilizada para desenvolvimento do projeto foi o RUP no qual a composio das atividades 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 a elaborao 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 na qual pode-se criar modelagem dos componentes, criar os diagramas e criar os prottipos de interface. Todos estes artefatos criados na fase 2, como podemos ver na figura 1 do item de Id 6 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 a prxima fase.

Na fase 4, fase de transio, tran como podemos ver nos itens de Id 31, 32, 33 e 34, ser realizado todos os testes com o objetivo de assegurar que o especificado foi realmente desenvolvido como tambm nesta fase ser realizada uma reunio de fechamento do projeto na qual ser entregue o produto final que o software pronto. No final de cada fase do pro processo, como podemos ver nos itens s de Id 4, 14, 29 e 33, foi realizada uma reunio de alinhament alinhamento o e planejamento do projeto para que todos os componentes da equipe pudessem acompanhar o que foi realizado nas atividades, alm de discutir as dvidas e dificuldades do projeto. Nas reunies tambm estava presente o cliente, no qual tinha papel fundamenta fundamental l para o acompanhamento e a validao de cada fase.

Figura 3: Cronograma com as descries das atividades

Na figura 4, temos a representao do cronograma de forma temporal atravs do Diagrama de Gantt, nele podemos ver por os recursos alocados para cada atividade e em qual momento cada atividade ser executada.

Figura 4: Diagrama de Gantt 5. ORGANIZAO DO PESSOAL Nesta seo veremos como os recursos humanos alocados no projeto sero utilizados, assim como ser feita a comunicao entre as pessoas envolvidas. 5.1 Estrutura da equipe Para a execuo do projeto, contaremos com a participao de 3 pessoas que iro desempenhar papis necessrios para garantir o andamento e o sucesso final do projeto. Abaixo veremos na tabela 6, 6 com os recursos alocados para o projeto e suas respectivas funes:

Responsvel Plnio Eduardo Bruno Espindola

Descrio

Papel

Responsvel por gerenciar e acompanhar as Gerente de Projeto atividades executadas pela equipe do projeto. Responsvel pelo levantamento de requisitos e Analista de Sistema atividades de anlise e projeto no qual ir elaborar todos os diagramas necessrios para a codificao do software. Responsvel pelo projeto arquitetural do Arquiteto sistema, incluindo os diagramas de projeto. Responsvel pela codificao do sistema. Programador

Bruno Espindola Philippe Melo Plnio Eduardo Plnio Eduardo

Responsvel pelo planejamento de testes de Analista de Teste sistema. Responsvel pela execuo dos testes do Testador sistema.

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 o email. O email foi utilizado bastante entre os membros da equipe e cliente para troca de informaes, tirar dvidas e discutir andamento do projeto. Alm do email, foi utilizado tambm o Gtalk para uma rpida comunicao entre os membros envolvidos no projeto. O Google Drive foi utilizado como ferramenta de colaborao que possibilitou a confeco e acompanhamento entre os envolvidos no projeto. Reunies presenciais eram realizadas a cada 15 dias para analisar o andamento do projeto. Nestas, era abordado as dvidas e problemas encontrados pelos membros da 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 do projeto. Com ele foi possvel conhecer ferramentas case para o gerenciamento de projeto 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 uma ferramenta na qual podemos compartilhar e disseminar os conhecimentos assimilados como tambm obter novos conhecimentos que serviram para o aperfeioamento de algumas atividades do projeto. 6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO

PRODUTO DE SW Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas preocupaes foram tomadas: Participao do cliente nas validaes do Projeto: Para alinhar a expectativa do cliente com o andamento do projeto, foram realizadas algumas reunies em etapas do projeto, nas quais a equipe discutia o andamento do projeto juntamente com o cliente. Controle de verses: Para a confeco dos documentos foram utilizados histricos de revises com objetivo de melhor identificar as alteraes realizadas e sempre informando o responsvel pela alterao. No desenvolvimento de software foi realizado o controle de verses atribuindo marcos nos quais representavam algum tipo de alterao, seja ela de 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 a atualizao da documentao do sistema sempre que uma alterao em nvel de projeto era realizada. Essa preocupao com a documentao do sistema foi alcanada pela rigidez que os testes demandavam afim de que o sistema estivesse totalmente de acordo com as especificaes. Testes: A fim de atribuir qualidade final ao produto e minimizar as eventuais falhas que viesse a ocorrer, os testes foram realizados em 3 nveis, no nvel unitrio no qual era realizado pelo prprio programador, nvel de integrao e de sistema ambos realizados pelo Analista de Teste e testador.