planode de projeto - sigep

UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO Gerência de Projetos 2014.2

PLANO DO PROJETO DE SOFTWARE

SISTEMA DE GERENCIAMENTO DE PROJETOS DE PESQUISA SIGEP

GRUPO 1

Domenico Medeiros Edson Fernando Poderoso Moreira

Eric Souza Henrique Mandt Lima Figueiredo

Vanessa Menezes Oliveira

São Cristóvão – Sergipe

2015 Domenico Medeiros

Edson Fernando Poderoso Moreira Eric Souza

Henrique Mandt Lima Figueiredo Vanessa Menezes Oliveira

PLANO DO PROJETO DE SOFTWARE

SISTEMA DE GERENCIAMENTO DE PROJETOS DE PESQUISA SIGEP

Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como parte avaliativa da disciplina Gerência de Projetos do Curso de Graduação em Sistemas de Informação da Universidade Federal de Sergipe – UFS.

São Cristóvão – Sergipe 2015

Sumário

1. INTRODUÇÃO................................................................................................................... 4

1.1 Âmbito do Projeto....................................................................................................... 4 1.2 Funções principais do produto de software.................................................................... 4 1.3 Requisitos comportamentais ou de performance............................................................ 5 1.4 Gestão e Restrições Técnicas..................................................................................... 6

2. ESTIMATIVAS DO PROJETO............................................................................................ 7

2.1 Dados históricos utilizados para as estimativas.............................................................. 7

2.2 Técnicas de estimação e resultados.............................................................................. 7

2.2.1 Técnica de estimativas........................................................................................ 7

2.3 Resultados.................................................................................................................. 8

2.4 Recursos do projeto................................................................................................... 10

2.4.1 Recursos Humanos........................................................................................... 10

2.4.2 Recursos de Software........................................................................................ 11

2.4.3 Recursos de Hardware....................................................................................... 12

3. ANÁLISE E GESTÃO DE RISCOS.................................................................................... 12

3.1 Riscos do projeto............................................................................................................. 13

3.2 Tabela de riscos............................................................................................................... 13

3.3 Redução e Gestão do Risco.............................................................................................. 14

4. PLANEJAMENTO TEMPORAL........................................................................................ 17

4.1 Conjunto de Tarefas do Projeto.......................................................................................... 17

4.2 Diagrama de Gantt........................................................................................................... 19

5. ORGANIZAÇÃO DO PESSOAL........................................................................................ 20

5.1 Estrutura da equipe.......................................................................................................... 20

5.2 Mecanismos de comunicação........................................................................................... 21

5.3 Uso do Edublog como ferramenta de apoio........................................................................ 21

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO

DE SOFTWARE………………………………………………………………………………………...22

1. INTRODUÇÃO

1.1 Âmbito do Projeto

O Sistema de Gerenciamento dos Projetos de Pesquisas (SIGEP) foi

desenvolvido para o Hospital Universitário da Universidade Federal de Sergipe, com o

objetivo de automatizar o processo do controle dos Projetos de Pesquisas realizados

pelo mesmo. Os professores poderão cadastrar novas pesquisas que futuramente

poderão ser validadas pelo Diretor. O sistema permitirá ainda, gerar relatórios para uma

melhor administração do controle das pesquisas do Hospital.

Antes da implementação do SIGEP, o processo era feito de forma manual. O

que resultava muitas vezes em perdas de informação. Com a automação, todo o

processo tornouse mais agilizado e seguro.

1.2 Funções principais do produto de software

O diagrama da exposto na Figura 1 abaixo, referese ao diagrama de Casos de

Uso e contém as principais funcionalidades do sistema SIGEP. Nele é apresentado as

operações que serão possíveis através do sistema, como: fazer login, cadastrar uma

pesquisa, validar a pesquisa, gerar relatórios, manutenir cadastros e alterar status da

pesquisa. As atividades que envolvem a manutenibilidade de determinado objeto estão

relacionadas com as operações: incluir, alterar e inativar.

Figura 1 Diagrama de Casos de Uso do SIGEP

1.3 Requisitos comportamentais ou de performance

Usabilidade:

As mensagens devem ser claras e objetivas, favorecendo o bom

entendimento do funcionamento do sistema.

Todas as telas referentes à transição deverão possuir a mesma estrutura

e padronização referente ao layout de cores.

Confiabilidade:

O sistema deve realizar as transações exatamente de acordo com o que

o usuário solicitar, sem excessos nem omissões.

O sistema deverá permitir que sua confiabilidade seja medida e avaliada,

principalmente através de testes, onde serão verificadas as transações

mais vulneráveis e que necessitam de maior atenção em correções e

ajustes.

Desempenho:

O sistema deverá retornar consultas gerais em no máximo 5s.

Para transações de cadastros e alterações em geral, o sistema deverá

retornar o sucesso ou insucesso da transação em no máximo 3s.

Segurança:

O Acesso do sistema se dará através de login e senha, com isso, poderá

acessar o sistema apenas pessoas habilitadas para este fim.

Todas as informações a nível de memória e armazenamento do browser

(cookies) serão sumariamente apagadas quando o usuário sair do

sistema, com isso, evitase o risco que informações possam de alguma

forma ser manipuladas por pessoas não autorizadas.

1.4 Gestão e Restrições Técnicas

As restrições encontradas na descrição do sistema que poderão limitar o

escopo podem ser:

É necessária a existência de uma estrutura de computadores ligados

através de uma rede interna.

É necessária a existência de uma máquina que será utilizada como

servidor com dedicação exclusiva que será responsável pelo controle de

todas as atividades referentes à infraestrutura, como backups de

informações e demais atividades controladas pela administração do

sistema.

O sistema atuará sobre a plataforma Windows XP SP3 ou superior.

O produto deve ser implementado como uma aplicação web e portável

para as plataformas Internet Explorer 8.0.6001.18702 (Ou superior) ou

Google Chrome 33.0.1750.117m (Ou superior) ou Mozilla Firefox 27.0.1

(Ou superior).

O produto deve utilizar Banco de Dados PostgreSql.

O produto deve ser implementado na linguagem de programação PHP.

Falta de capacitação técnica da equipe, sendo necessário um treinamento

específico para alguns componentes da equipe com ferramentas que

serão utilizadas.

2. ESTIMATIVAS DO PROJETO

2.1 Dados históricos utilizados para as estimações

Não serão utilizados dados históricos na avaliação do projeto, visto que este

será o primeiro projeto da equipe.

2.2 Técnicas de estimação e resultados

Para estimar o tempo é necessária a utilização de uma técnica de estimativa, e a

técnica escolhida foi a de Lorenz & Kidd, Orientada a Classes, adotada pela Lacertae

Software.

2.2.1 Técnicas de estimação e resultados

A técnica de estimação escolhida para o SIGEP foi a adotada pela Lacertae

Software. Tratase de uma métrica orientada a classes que consiste em:

1. Determinar a quantidade de classeschave do projeto;

2. Encontrar o número de classes de suporte, classificando o tipo de

interface do produto e utilizando multiplicadores correspondentes para as

classes de suporte;

3. Multiplicar a quantidade de classeschave pelo multiplicador

correspondente para estimar o número de classes de suporte;

4. Multiplicar o total de classes (chave + suporte) pelo número médio de

unidades de trabalho (diaspessoa) por classe;

5. Calcular o tempo previsto para a realização do projeto.

A Tabela 1 com os Multiplicadores utilizados para encontrar a quantidade de

classes de suporte:

INTERFACE MULTIPLICADOR

Não Gráfica 2

Baseada em Texto 2,25

GUI Simples 2,5

GUI Complexa 3 Tabela 1 Fatores Multiplicativos

2.3 Resultados

Com base no diagrama de classes de análise da Figura 2, fezse a estimativa:

1. Número de classeschave encontradas após a análise do diagrama de

classes de domínio: 10; 2. Interface selecionada (De acordo com o modelo de arquitetura do

sistema): GUI simples; 3. Número de classes de suporte encontrado: 10 (classeschave) x 2,5

(valor multiplicador utilizado da Tabela 1)= 25 classes de suporte; 4. Número total de classes: 10 (chave) + 25 (suporte)= 35 classes; 5. Quantidade de dias que uma pessoa gastaria para desenvolver uma

única classe: 9 dias; No modelo Lacertae, é recomendado o uso de 15 a 20 dias porém,

utilizamos a quantidade de 9 dias com base no tempo utilizado quando o SIGEP foi

desenvolvido.

6. Quantidade total de dias que uma pessoa gastaria para construir todo o

sistema: 9 (dias) * 35 (classes) = 315 dias; 7. Quantidade total de dias que a equipe gastaria para construir todo o

sistema: 315 (dias) / 5 (quantidade de integrantes)= 63 dias.

Sendo assim, o tempo necessário para a construção do projeto deve ser de,

aproximadamente, 63 dias, que dividindo por 22 (quantidade de dias úteis de um mês)

resulta num tempo aproximado de 3 meses.

2.4 Recursos do projeto

2.4.1 Recursos Humanos

O projeto contará com cinco pessoas que exercerão os diversos papéis

que serão necessários para a execução do projeto de desenvolvimento de software. Na

Tabela2 abaixo, podemos verificar os envolvidos de acordo os com seus respectivos

papéis.

Papel Responsável

Gerente de Projeto Vanessa Menezes

Analista de Sistemas Henrique Mandt

Arquiteto de Software Edson Poderoso

Codificador Domenico Medeiros, Edson Poderoso

Testador Eric Souza, Henrique Mandt, Vanessa Menezes Tabela 2 Recursos Humanos

2.4.2 Recursos do Ambiente de Desenvolvimento

Para o bom desenvolvimento deste projeto, foram utilizados os seguintes

recursos de software:

PostgreSql Sistema de gerenciamento do banco de dados;

PHP Linguagem de programação a ser utilizada no

desenvolvimento do software;

Microsoft Office Editor de texto, planilhas e apresentações usados

na documentação e relativos;

Gmail Sistema de email utilizado para troca de informações;

Google Drive Sistema de armazenamentos de dados em nuvem

para compartilhamento de arquivos e alterações dos mesmos em

tempo real;

GanttProject 2.7 Utilizada para elaborar o Diagrama de Gantt;

NetBeans 7.2.1 IDE que será utilizada na implementação do

produto de software;

MsProject 2010 Auxilia na gerência das atividades do projeto.

2.4.3 Recursos de Hardware

Computador para Desenvolvimento:

Processador: Core i3 ou superior.

Memória RAM: 4 Gb de RAM.

HD: 250 Gb ou superior.

3. ANÁLISE E GESTÃO DE RISCOS

Nesta seção, serão analisados os possíveis riscos prejudiciais para o

desenvolvimento do projeto de software. Por meio desta análise, visamos minimizar o

máximo possível a sua ocorrência e, consecutivamente, o seu impacto caso venha a

ocorrer.

3.1 Riscos do projeto

Segue abaixo a Tabela 3 com os riscos levantados para o referido projeto:

Risco Projeto Técnico Negócio Comum Especial

Equipe não domina totalmente a tecnologia adotada no projeto

X

X

Equipe não possui o treinamento necessário na linguagem de desenvolvimento adotada

X

X

Equipe pequena no desenvolvimento do projeto

X X

Custos relacionados ao mal uso da ferramenta

X X

Ferramentas de teste com baixo suporte à tecnologia empregada no projeto

X

X

Período de desenvolvimento do projeto relativamente curto

X X

Equipe não disponível em tempo integral

X X

Constante necessidade de aprimoramento do software

X X

Tabela 3 Riscos x Classificação

3.2 Tabela de riscos

Na Tabela 4 a seguir, foram definidos para cada risco, apresentado

anteriormente na Tabela 3, uma probabilidade que determina a chance de ocorrência

do mesmo, bem como o impacto após o acontecimento do risco.

Risco Probabilidade (%) Impacto

Ferramentas de teste com baixo suporte à tecnologia empregada no projeto

90% Catastrófico

Período de desenvolvimento do projeto relativamente curto

80% Crítico

Equipe não disponível em tempo integral 70% Moderado

Equipe pequena no desenvolvimento do projeto

70% Marginal

Custos relacionados ao mal uso da ferramenta

70% Marginal

Equipe não domina totalmente a tecnologia adotada no projeto

60% Moderado

Equipe não possui o treinamento necessário na linguagem de desenvolvimento adotada

60%

Moderado

Constante necessidade de aprimoramento do software

40% Moderado

Tabela 4 Riscos do Projeto

3.3 Redução e Gestão do Risco

Visando garantir a redução e/ou gestão dos riscos apresentados, as estratégias

de redução, supervisão e gestão dos riscos (RSGR) foram adotadas:

1. Equipe não domina totalmente a tecnologia adotada no projeto

Probabilidade: 60% Impacto: Moderado

Descrição: A equipe não possui o conhecimento mínimo suficiente sobre a tecnologia utilizada no desenvolvimento do projeto.

Estratégia de Redução: Buscar métodos que visem expandir e aprimorar os conhecimentos acerca da referida tecnologia.

Plano de Contingência: Planejar e definir em em equipe as estruturas de dados utilizadas no SIGEP em oposição à prática do desenvolvimento individual com o intuíto de evitar bloqueios por falta de domínio da tecnologia.

Responsável: Edson Poderoso

Status: Concluído Tabela 5 Análise do risco 1

2. Equipe não possui o treinamento necessário na linguagem de desenvolvimento adotada


Descrição: Devido à escassez de cursos locais, o treinamento da equipe é baixo.

Estratégia de Redução: Cursos e apostilas de aprendizado online

Plano de Contingência: Adotar uma linguagem de programação comum ao conhecimento de todos os participantes.

Responsável: Domenico Medeiros


3. Equipe pequena no desenvolvimento do projeto

Probabilidade: 70% Impacto: Marginal

Descrição: A equipe responsável pela construção do projeto é relativamente pequena.

Estratégia de Redução: Divisão das tarefas da equipe de acordo com um planejamento, evitando assim a sobrecarga de funções.

Plano de Contingência: Entregar o projeto em etapas incrementais.

Responsável: Vanessa Menezes Oliveira


4. Custos relacionados ao mau uso do SIGEP

Probabilidade: 70% Impacto: Marginal

Descrição: Caso o software se comporte de forma não planejada, erros poderão acontecer implicando em custos extras

Estratégia de Redução: Efetuar exaustivos testes no software antes da entrega.

Plano de Contingência: Capacitar pessoas a oferecer suporte ao SIGEP, bem como fornecer manuais de uso para os usuários.

Responsável: Eric Souza


5. Ferramentas de teste com baixo suporte à tecnologia empregada no projeto

Probabilidade: 90% Impacto: Catastrófico

Descrição: Ferramentas de teste automatizado acabam por oferecer pouco suporte à tecnologia usada na codificação do produto.

Estratégia de Redução: Diminuição gradativa do uso dessas ferramentas por meio da implantação de outros processos de teste, visando novas soluções.

Plano de Contingência: Divisão de testes complexos em outros menores, mais simplificados, de forma a facilitar o uso das ferramentas já utilizadas.

Responsável: Henrique Mandt


6. Período de desenvolvimento do projeto relativamente curto

Probabilidade: 80% Impacto: Crítico

Descrição: O prazo para a completa construção do software é curto.

Estratégia de Redução: Divisão pertinente das atividades seguindo o planejamento.

Plano de Contingência: Efetuar entregas parciais do SIGEP ao usuário.



7. Equipe não disponível em tempo integral


Descrição: Devido às atividades independentes dos membros da equipe, o tempo disponível para o projeto não é integral.

Estratégia de Redução: Divisão pertinente das atividades seguindo 0 planejamento à risca.

Plano de Contingência: Revisar as atividades realizadas por cada integrante de forma a não haver uma sobrecarga de tarefas. Uma nova divisão de tarefas pode facilitar o processo.

Responsável: Vanessa Menezes


8. Constante necessidade de aprimoramento do SIGEP


Descrição: As necessidades do usuário podem passar por diversas modificações mediante a evolução das atividades, levando a uma constante modificação do produto.

Estratégia de Redução: Disponibilizar versões alpha (versões de testes) para que os usuários conheçam o software e possam opinar no aprimoramento do mesmo, identificando precocemente as necessidades dos usuários, de forma a melhorar o produto.

Plano de Contingência: Buscar atender prioritariamente as obrigações definidas contratualmente, oferecendo o serviço de customização como uma opção posterior.



4. PLANEJAMENTO TEMPORAL

Nesta seção serão apresentadas as tarefas realizadas no SIGEP e seu

planejamento temporal do Diagrama de Gantt, onde será definido as datas de início e

fim e o responsável por cada tarefa.

4.1 Conjunto de Tarefas do Projeto

Aqui são apresentados o Modelo de Processo escolhido, suas atividades e

algumas tarefas escolhidas para serem apresentadas nesta seção.

Com base nos cálculos descritos na seção 2 presente no item 2.3 (Resultados),

o esforço estimado para a realização do projeto é de 63 dias trabalhados.

Abaixo é exibido o plano temporal das fases do SIGEP.

Fases Porcentagem Dias Trabalhados

Planejamento 18% 11,34

Análise de Requisitos 34% 21,42

Geração de Código 37% 23,31

Testes 11% 6,93 Tabela 13 Dias por Tarefa

A porcentagem estabelecida para as fases do SIGEP diferenciamse das

sugeridas no modelo Lacertae. Visto que o SIGEP já foi desenvolvido posteriormente e

a média de dias para desenvolvimento de uma classe (apresentada na secão 2, item

2.3) também resultou nos valores de porcentagem apresentados na Tabela 13.

Diagrama de Gantt

5. ORGANIZAÇÃO DO PESSOAL

Cada membro da equipe possui seus papéis e atividades bem definidas, onde

cada um sabe qual deverá ser a tarefa a ser realizada. As decisões são sempre

tomadas em conjunto.

5.1 Estrutura da equipe

Analista de Sistemas estudam os diversos sistemas existentes entre

hardwares (equipamentos), softwares (programas) e o usuário final.

Responsável: Henrique Mandt

Analista de Testes identificam e definem os testes necessários, monitorar a

abrangência dos testes e avaliar a qualidade obtida ao realizar os testes. Responsável

ainda por desenvolver e testar componentes de acordo com os padrões adotados para

o projeto, para fins de integração com subsistemas maiores.


Arquiteto de Software lideram e coordenam as atividades e os artefatos

técnicos no decorrer do projeto. Estabelece também, a estrutura geral de cada visão de

arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces

entre esses principais agrupamentos.


Gerente de Projetos gerencia o progresso do empreendimento e por meio

das variáveis (qualidade, custo, prazo e âmbito) verificam seus desvios, de forma a

minimizar as falhas ligadas ao processo.

Responsável: Vanessa Menezes

Product Owner tratase da única pessoa responsável pelo gerenciamento do

Backlog do Produto e por garantir o valor do trabalho realizado pelo Time Scrum,

permitindo que todos os outros membros da equipe possam visualizálo.

Responsável: Domenico Medeiros.

5.2 Mecanismos de comunicação

As formas de comunicação utilizadas para o projeto foram:

Email comunicação direta para os demais participantes do projeto com

relatórios informando as evoluções e problemas encontrados ao longo do

desenvolvimento.

Reuniões Diárias permitiram a comunicação faceaface e ajudaram a

verificar o andamento do projeto.

Ferramentas Colaborativas documentos importantes foram

compartilhados e editados em tempo real por meio do Google Drive,

permitindo a participação de todos os envolvidos.

Aplicativos (Whatsapp) interações rápidas e tomadas de decisões

diretas foram realizadas em tempo hábil através da criação de um grupo

no aplicativo para smatphones.

5.3 Uso do Edublog como ferramenta de apoio

O Edublog é uma ferramenta bastante simples e possui acesso facilitado, apóia

a colaboração entre pessoas como fonte de disseminação de conhecimentos.

A utilização do blog durante o desenvolvimento desse trabalho foi importante

para o seu bom andamento. Um importante papel do blog foi compartilhar os

conhecimentos por nós elencados, bem como compartilhar informações com outras

equipes que serviram como base para a edição deste documento.

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A

QUALIDADE DO PRODUTO DE SOFTWARE

Visando garantir a qualidade do software, algumas atividades foram

desenvolvidas durante o projeto, sendo elas:

Testes Sucessivos testes foram realizados durante a fase de

desenvolvimento do software, com a finalidade de evitar futuras releases

de correção de eventuais erros que possam vir a ocorrer no software.

Reuniões Diárias Por meio das reuniões diárias realizadas pelos

membros da equipe, foi possível sanar eventuais dúvidas que vieram a

surgir com relação ao desenvolvimento do projeto. Auxiliando evitar, de

maneira ágil, desvios de má interpretação. Atividades de brainstorming

foram essenciais para tomadas de decisão com relação a um melhor

desenvolvimento do software.

Elaboração de Documentação para um melhor controle do projeto,

documentações foram elaboradas nas fases de análise, projeto e testes.

planode de projeto - sigep

Education