SlideShare uma empresa Scribd logo
1 de 32
Baixar para ler offline
 
 
Universidade Federal de Sergipe 
Departamento de Computação 
Sistemas de Informação 
 
 
 
 
 
PLANO DO PROJETO DE SOFTWARE OO 
para produtos da Lacertae SW 
 
 
Anne Caroline Melo Santos 
Fábio Nascimento Santos 
Paulo Henrique dos Santos 
 
 
 
São Cristóvão 
2016 
 
 
 
Universidade Federal de Sergipe 
Departamento de Computação 
 
 
 
 
Anne Caroline Melo Santos  
Fábio Nascimento Santos  
Paulo Henrique dos Santos  
 
 
 
 
Trabalho apresentado como avaliação da disciplina           
Gerência de Projetos, no curso de Sistemas de               
Informação, na Universidade Federal de Sergipe. 
Prof. Dr. Rogério Patrício Chagas do Nascimento. 
 
 
 
São Cristóvão 
2016 
 
 
 
Sumário 
1.0 INTRODUÇÃO  
1.1 Âmbito do Projeto  
1.2 Funções principais do produto de software  
1.3 Requisitos comportamentais ou de performance  
1.4 Gestão e Restrições Técnicas  
2.0 ESTIMAÇÕES DO PROJETO  
2.1 Dados históricos utilizados para as estimações  
2.2 Técnicas de estimação e resultados  
2.2.1 Técnica de estimação  
2.3 Resultados  
2.4 Recursos do projeto  
2.4.1 Recursos Humanos  
2.4.2 Recursos de Software  
2.4.3 Recursos de Hardware  
3.0 ANÁLISE E GESTÃO DE RISCOS  
3.1 Riscos do projeto  
3.2 Tabela de riscos  
3.3 Redução e Gestão do Risco  
4.0 PLANEJAMENTO TEMPORAL  
4.1 Conjunto de Tarefas do Projeto  
4.2 Diagrama de Gantt  
5.0 ORGANIZAÇÃO DO PESSOAL  
5.1 Estrutura da equipe  
5.2 Mecanismos de comunicação  
5.3 Uso do Edu­blog como ferramenta de apoio  
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE 
DO PRODUTO DE SW  
 
 
1.0 INTRODUÇÃO 
1.1 Âmbito do Projeto 
Atualmente o Processo de Enfermagem realizado no Hospital Universitário de                   
Sergipe é feito manualmente. O Processo é lento e sujeito a falhas, pois não existem                             
mecanismos que controlem o acesso aos relatórios produzidos e que agilize o processo de                           
avaliação do paciente. Diante disso, foi proposta a construção de um módulo que                         
automatizasse o processo existente. Com a implantação desse módulo, os enfermeiros                     
terão que passar por um treinamento para poderem aprender a manipular o sistema                         
corretamente. Além disso, os formulários impressos serão substituídos por formulários                   
eletrônicos.  
O software proporcionará maior agilidade e facilidade no Processo de                   
Enfermagem. O sistema proverá maior controle sobre os relatórios produzidos. Os                     
profissionais com acesso a estes relatórios, também serão controlados.  
 
 ​1.2 Funções principais do produto de software 
As principais funções do Módulo de Processo de Enfermagem são:  
● Manutenir Prescrição; 
● Manutenir Diagnóstico; 
● Manutenir Necessidade; 
● Recuperar Dados do Paciente; 
● O Sistema deverá fazer o mapeamento de necessidades para diagnóstico e                     
de diagnóstico para prescrição, criando uma relação de dependência entre eles; 
● Manter Processo de Enfermagem; 
● Gerar Relatório de Evolução de Enfermagem; 
● Informar no relatório de evolução de enfermagem o nome do enfermeiro                     
que está mantendo o Processo de Enfermagem. 
 
 
 
 ​1.3 Requisitos comportamentais ou de performance 
Dentre os requisitos comportamentais e de performance temos:  
Usabilidade 
● O sistema deve apresentar uma interface amigável, intuitiva e de fácil                     
utilização para garantir uma boa comunicação entre usuários e sistema. 
● O sistema deverá utilizar palavras que fazem sentido para o usuário. Toda                       
comunicação do sistema precisa ser contextualizada ao usuário, e ser coerente com                       
o chamado modelo mental do usuário. 
Confiabilidade 
● O sistema deve apresentar mensagens de erros simples que ajudem o                     
usuário a entender e a resolver o problema. 
● O sistema deve evitar situações de erro através do reconhecimento das                     
situações que mais provocam erros e modificar a interface para que estes erros não                           
ocorram. 
Desempenho 
● O sistema deverá exibir na tela os dados do paciente em no máximo 10                           
segundos. 
● O sistema deverá realizar o mapeamento de uma entidade para outra em no                         
máximo 10 segundos. 
Segurança 
● O sistema deverá ter controle de acesso e de manipulação de recursos.  
● O sistema deverá garantir a integridade e confidencialidade dos dados.  
Implantação 
● O sistema deve ser implantado em um ambiente que tenha conexão com a                         
Internet.  
● É necessário que os usuários passem por um período de treinamento para                       
aprenderem a manipular o software corretamente.  
 
 
 ​1.4 Gestão e Restrições Técnicas 
As restrições técnicas encontradas no projeto foram: 
● O software deve ser feito no Eclipse, usando a linguagem java; 
● O software deve utilizar o banco de dados PostgreSQL; 
● Utilizar o TRELLO para gerenciar as tarefas durante o desenvolvimento do                     
software; 
● Utilizar o Enterprise Architect para fazer a modelagem dos dados e criar os                         
casos de uso; 
● Utilizar o Selenium para realização de testes; 
● Utilizar o Axure para prototipação das telas.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ​2.0 ESTIMAÇÕES DO PROJETO 
 ​2.1 Dados históricos utilizados para as estimações 
Não serão utilizados dados históricos na mensuração do projeto, uma vez que é 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. A                           
técnica escolhida foi a Lorenz & Kidd, Orientada a Objetos, adotada pela Lacertae                         
Software 
 ​2.2.1 Técnica de estimação 
A técnica de estimação escolhida para o Sistema de Processo de Enfermagem, foi                         
a Lorenz & Kidd. Trata­se de uma métrica orientada a objetos que consiste em: 
1. Determinar a quantidade de classes chave do projeto; 
2. Encontrar o número de classes de suporte, classificando o tipo de   
interface do produto e utilizando os multiplicadores correspondentes para  as 
classes de suporte; 
3. Multiplicar a quantidade de classes­chave 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 (dias­pessoa) por classe; 
5. Calcular o tempo previsto para a realização do projeto. 
Abaixo, temos uma tabela com os multiplicadores utilizados para encontrar a                     
quantidade de classes de suporte:  
 
 
 
 
Tabela 1 ­ ​Multiplicadores da Métrica Lorenz & Kidd. 
A tabela 1, classifica as interfaces em 4 tipos: não gráfica, baseada em texto, GUI                             
simples e GUI complexa. Para cada tipo de interface será atribuído um multiplicador.  
2.3 Resultados 
A seguir, temos o diagrama de classes do Módulo do Processo de Enfermagem. 
 
Figura 1 ​­ Diagrama de Classes (Autores). 
 
 
A figura 1 traz um Diagrama de Classes do Módulo de Processo de Enfermagem.                           
O Diagrama de Classe mostra um conjunto de classes com seus relacionamentos e atributos.                           
É o diagrama central da modelagem orientada a objetos.  
1. Classes Chaves do Software: Pessoa, Paciente, Enfermeiro, Leito, Processo                 
de Enfermagem, Prescrição Alternativa, Necessidade, Diagnóstico e Prescrição.               
Total: 9 Classes Chaves; 
2. Tipo das classes de suporte: Interface Gráfica com Usuário (Graphical User                     
Interface – GUI); 
3. Valor Multiplicador: 2,5; 
4. Classes de suporte: 9 (classes chaves) x 2,5 (Valor multiplicador) = 22,5                       
classes de suporte; 
5. Total de classes: 9 (chave) + 22,5 (suporte) = 31,5; 
6. Número médio de unidades de trabalho: 16 dias­pessoa; 
7. Tempo previsto: 31,5 (classes) x 16 (dias) = 504 dias por pessoa para a                           
construção das classes; 
8. Considerando que a equipe é formada por 3 pessoas, chega­se ao total de                         
168 dias; 
9. O tempo total de projeto é 7,6 meses. Foi considerado que um mês tem 22                             
dias levando em conta pontos facultativos e feriados. 
 ​2.4 Recursos do projeto 
Recursos humanos, de software e hardware, ferramentas de apoio e outros recursos 
necessários são listados abaixo: 
2.4.1 Recursos Humanos 
 
Optou­se pela adoção da Metodologia Ágil. Será adotada uma rotação na execução                       
das tarefas. Todos os envolvidos no desenvolvimento do projeto exercerão papéis                     
diferentes, sendo eles: gerente de projeto, desenvolvimento e testes. 
 
 
Serão adotadas 6 ​sprints​, onde cada uma delas terá duração de 28 dias. A divisão                             
das atividades pode ser visualizada abaixo:  
 
Sprint 1 
Período:  
Duração: 28 dias. 
Scrum Master: Anne Caroline Melo Santos 
Desenvolvedor (a): Paulo Henrique dos Santos 
Testador: Fábio Nascimento Santos 
 
Sprint 2 
Período:  
Duração: 28 dias. 
Scrum Master: Paulo Henrique dos Santos 
Desenvolvedor (a): Fábio Nascimento Santos 
Testador: Anne Caroline Melo Santos 
 
Sprint 3 
Período:  
Duração: 28 dias. 
Scrum Master:  Fábio Nascimento Santos 
Desenvolvedor (a): Anne Caroline Melo Santos 
Testador: Paulo Henrique dos Santos 
 
Sprint 4 
Período:  
Duração: 28 dias. 
Scrum Master: Anne Caroline Melo Santos 
Desenvolvedor (a): Paulo Henrique dos Santos 
 
 
Testador: Fábio Nascimento Santos 
 
Sprint 5 
Período:  
Duração: 28 dias. 
Scrum Master: Paulo Henrique dos Santos 
Desenvolvedor (a): Fábio Nascimento Santos 
Testador: Anne Caroline Melo Santos 
 
 
Sprint 6 
Período:  
Duração: 28 dias. 
Scrum Master: Fábio Nascimento Santos 
Desenvolvedor (a): Anne Caroline Melo Santos 
Testador: Paulo Henrique dos Santos 
 
2.4.2 Recursos de Software 
No desenvolvimento do projeto serão utilizados os seguintes softwares: 
● Eclipse 
■ IDE para o desenvolvimento do sistema. 
● Trello 
■ Ferramenta para o gerenciamento das atividades. 
● PostgreSQL 
■ Serviço de banco de dados que será utilizado para o armazenamento                     
das informações geradas pelo sistema. 
● Enterprise Architect  
■ Software que será utilizado para fazer a modelagem dos dados e                     
criar os casos de uso. 
 
 
● Selenium 
■  Realização de testes. 
● Axure  
■ Prototipação das telas. 
 
2.4.3 Recursos de Hardware 
Serão utilizados 3 ​notebooks ​para o desenvolvimento do software aqui proposto. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ​3.0 ANÁLISE E GESTÃO DE RISCOS 
Nessa seção, analisaremos os riscos envolvidos no projeto com o objetivo de                       
indentificá­los, a fim de, elaborar um plano de contingência para minimizar sua ocorrência e                           
fazendo com que os possíveis danos causados sejam mais previsíveis. 
 ​3.1 Riscos do Projeto 
  A identificação dos Riscos do Projeto é uma etapa importante para a redução de                           
ocorrências dos mesmos. Na Tabela 2, estão listados alguns dos riscos mais críticos                         
identificados no projeto. 
 
Risco  Projeto  Técnico  Negócio  Comum  Especial 
Dificuldade de integrar 
com os sistemas já 
existentes no hospital 
X  X      X 
Queda de energia pode 
causar alguma falha e o 
processo de enfermagem 
pode ficar indisponível 
por algum tempo 
    X    X 
Enfermeiros podem não 
aderir à mudança no seu 
processo de trabalho 
    X    X 
Os chefes de enfermagem 
não participam das etapas 
do processo de software 
X    X     
O sistema ficar fora do ar    X  X    X 
Os gestores não são 
apoiadores do produto 
X        X 
Possibilidade do risco de 
incêndio na sala dos 
servidores 
    X    X 
 
 
Equipe de 
desenvolvimento pequena 
X        X 
Dificuldade dos usuários 
em manusear o sistema 
      X   
Falta de familiaridade da 
equipe com as 
tecnologias exigidas para 
a construção do software 
X  X       
Pouco treinamento da 
equipe do hospital 
    X  X   
Os enfermeiros podem, 
mesmo com treinos, não 
se adequar às capacidades 
técnicas exigidas pelo 
sistema 
    X  X   
Rotatividade dos 
membros da equipe de 
desenvolvimento 
X  X       
Tabela 2 ­ ​Caracterização dos Riscos do Projeto mais críticos identificados. 
 
3.2 Tabela de riscos 
Após a identificação dos principais Riscos do Projeto, é feita uma análise                       
probabilística de ocorrência para cada risco. Essa análise leva em consideração todas as                         
etapas do desenvolvido do software até depois de sua implantação. 
Os riscos de impacto “Catastrófico”, caracterizam a não disponibilidade ou não                     
utilização do software. Já os riscos de impacto “Crítico” dizem respeito às etapas de                           
desenvolvimentos ou dificuldades na utilização do software. 
 
Nome do Risco  %Probabilidade  Impacto 
Dificuldade de integrar com os sistemas já             
existentes no hospital 
90%  Catastrófico 
 
 
Queda de energia pode causar alguma falha e o                 
processo de enfermagem pode ficar indisponível           
por algum tempo 
90%  Catastrófico 
Enfermeiros podem não aderir à mudança no seu               
processo de trabalho. 
60%  Catastrófico 
Os chefes de enfermagem não participam das             
etapas do processo de software 
30%  Catastrófico 
O sistema ficar fora do ar  10%  Catastrófico 
Os gestores não são apoiadores do produto  10%  Catastrófico 
Possibilidade do risco de incêndio na sala dos               
servidores 
10%  Catastrófico 
Equipe de desenvolvimento pequena  80%  Crítico 
Dificuldade dos usuários em manusear o sistema  80%  Crítico 
Falta de familiaridade da equipe com as             
tecnologias exigidas para a construção do           
software 
50%  Crítico 
Pouco treinamento da equipe do hospital  20%  Crítico 
Os enfermeiros podem, mesmo com treinos, não             
se adequar às capacidades técnicas exigidas pelo             
sistema 
20%  Crítico 
Rotatividade dos membros da equipe de           
desenvolvimento 
10%  Crítico 
Tabela 3 ­ ​Probabilidade e Impactos dos Riscos de Projetos mais críticos. 
3.3 Redução e Gestão do Risco 
Para garantir a Redução, Supervisão e Gestão dos Riscos (RSGR) foram utilizadas                       
as seguintes estratégias: 
1 ­ Dificuldade de integrar com os sistemas já existentes no hospital 
Probabilidade​: 90%  Impacto​: Catastrófico 
Descrição​: Dificuldade de integração com os sistemas já existentes no hospital,                     
acarretando em atraso na entrega e ou mau funcionamento do sistema. 
 
 
Estratégia de Redução​: Para dirimir as dificuldades de integração com os sistemas do                         
hospital, é ideal que se simule o ambiente tecnológico (servidores, banco de dados e                           
sistemas) do hospital e que sejam realizados testes prévios de integração durante o                         
desenvolvimento do software. 
Plano de Contingência​: Na ocorrência deste risco, primeiramente deverá ser analisado                     
se houve mudança entre o ambiente simulado e o ambiente do hospital. Após esta                           
análise, se houver mudanças elas deverão ser reparadas e novos testes de integrações                         
deverão ser feitos. É fundamental envolver as equipes de desenvolvimento do software e                         
a equipe de tecnologia do hospital. 
Responsável​: Paulo Henrique 
Status​: Em andamento. 
Quadro 1 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 1. 
2 ­ Queda de Energia 
Probabilidade​: 90%  Impacto​: Catastrófico 
Descrição​: A queda de energia pode causar alguma falha e o processo de enfermagem                           
pode ficar indisponível por algum tempo. 
Estratégia de Redução​: Para se evitar a queda de energia uma medida pode ser adotada:                             
aquisição de geradores de energia. Outra medida que poderia ser adotada, a respeito da                           
sala de servidores, é a replicação em regiões geográficas diferentes com a utilização de                           
técnicas de clusters. 
Plano de Contingência​: O processo de enfermagem não pode parar, logo na falta de                           
energia os sistemas estarão indisponíveis e os formulários impressos deverão ser                     
utilizados. Assim que a energia voltar estes formulários deverão ser transpostos para o                         
sistema para garantir a plena utilização do sistema. 
Responsável​: Paulo Henrique 
Status​: Em andamento. 
Quadro 2 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 2. 
3 ­ Enfermeiros podem não aderir à mudança no seu processo de trabalho 
Probabilidade​: 60%  Impacto​: Catastrófico 
Descrição​: Todo processo de mudança gera um desconforma para os envolvidos. Com                       
isso, os enfermeiros podem oferecer resistência na adoção do software desenvolvido. Se                       
os enfermeiros não aderirem ao software, este entrará em desuso. 
 
 
Estratégia de Redução​: Para dirimir as chances de haver resistência na adoção do                         
software, é necessário que se faça acompanhamento do projeto com os enfermeiros (que                         
são os principais utilizadores) para garantir que o produto seja satisfatório e de fato                           
melhore os processos de trabalho dos mesmos.  
Plano de Contingência​: Com a resistência na adoção do software pelos enfermeiros. É                         
necessário envolver os gestores do projeto para dialogar com os mesmos a fim de                           
convencê­los a utilizarem o software. 
Responsável​: Anne Caroline 
Status​: Em andamento. 
Quadro 3 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 3. 
4 ­ Os chefes de enfermagem não participam das etapas do processo de software 
Probabilidade​: 30%  Impacto​: Catastrófico 
Descrição​: O não envolvimento dos chefes de enfermagem (principais apoiadores) no                     
projeto pode acarretar na construção de software que não atenda as necessidades do setor                           
e portanto a não utilização do mesmo. 
Estratégia de Redução​: Os chefes de enfermagem devem participar de todas as etapas                         
de desenvolvimento do software, validando e testando, se o que está sendo construído                         
pela equipe de desenvolvimento está de acordo com suas necessidades. 
Plano de Contingência​: Após o software ter sido construído sem a participação dos                         
chefes de enfermagem, existe uma grande chance dos mesmos não utilizarem­no. Se isso                         
ocorre o ​Product Owner e os gestores do projeto deverão convencer os chefes a                           
utilizarem o software, caso contrário o software entrará em desuso.  
Responsável​: Anne Caroline 
Status​: Em andamento. 
Quadro 4 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 4. 
5 ­ O sistema ficar fora do ar  
Probabilidade​: 10%  Impacto​: Catastrófico 
Descrição​: A não disponibilidade do sistema poderá acarretará em prejuízo para o                       
hospital. Os processos de enfermagem não poderão ser executados com eficiência,                     
podendo causar danos para seus pacientes. Como também, gerará insatisfação nos                     
usuários e insegurança quanto à qualidade do software, o que poderá resultar na sua não                             
utilização se vier a ocorrer com frequência. 
 
 
Estratégia de Redução​: Deverão ser utilizadas ferramentas para diagnosticar todo o                     
ambiente onde o software estiver instalado. Ferramentas de monitoramento de banco de                       
dados e aplicações. Também deverão ser utilizadas estratégias de replicação para o                       
banco de dados e para a aplicação. 
Plano de Contingência​: O processo de enfermagem não pode parar, logo na                       
indisponibilidade do sistema, os formulários impressos deverão ser utilizados. E em                     
paralelo o ambiente deverá ser reiniciado e os logs das ferramentas de monitoramento                         
deverão ser revisto, a fim de, identificar e corrigir a falha. 
Responsável​: Paulo Henrique 
Status​: Em andamento. 
Quadro 5 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 5. 
6 ­ Os gestores não são apoiadores do produto 
Probabilidade​: 10%  Impacto​: Catastrófico 
Descrição​: Ter apoio dos gestores envolvidos no projeto é de fundamental importância                       
para a plena execução do software. Não ter apoio desses gestores pode acarretar na não                             
utilização do mesmo. 
Estratégia de Redução​: Todos os gestores devem participar das etapas de                     
desenvolvimento para garantir que o produto construído está em conformidade com suas                       
necessidades. 
Plano de Contingência​: Se os gestores não são apoiadores do software o ​Product                         
Owner deverá dialogar com os mesmos para convencê­los de sua utilização. Caso não                         
consiga, o software entrará em desuso. 
Responsável​: Anne Caroline 
Status​: Em andamento. 
Quadro 6 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 6. 
7 ­ Possibilidade do risco de incêndio na sala dos servidores 
Probabilidade​: 10%  Impacto​: Catastrófico 
Descrição​: A sala dos servidores é um local estratégico para as organizações. Com a                           
grande quantidade de equipamentos ou eventos externos, é possível haver focos de                       
incêndios. 
 
 
Estratégia de Redução​: Para dirimir a ocorrência de incêndios medidas como: sistema                       
anti­incêndio, e um efetivo sistema de refrigeração podem ser tomadas. Mas também, é                         
fundamental que haja um sistema de replicação geográfica das aplicações e do banco de                           
dados. 
Plano de Contingência​: Se o risco se concretizar o sistema de replicação deverá entrará 
em vigor, ou seja, o acesso deverá ser redirecionado para outro lugar. 
Responsável​: Paulo Henrique 
Status​: Em andamento. 
Quadro 7 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 7. 
8 ­ Equipe de desenvolvimento pequena 
Probabilidade​: 80%  Impacto​: Crítico 
Descrição​: Ter uma equipe de desenvolvimento pequena pode acarretar em atrasos na                       
entrega do produto se o escopo exigido pelo projeto for maior do que a equipe possa dar                                 
conta. 
Estratégia de Redução​: Se o escopo do projeto requer mais tempo do que foi planejado,                             
as datas e prazos deverão ser replanejadas para adequar ao tamanho da equipe. 
Plano de Contingência​: Caso não haja tempo suficiente para completar a                     
desenvolvimento do produto, será necessário decidir quais funcionalidades serão                 
efetivamente concluídas. Será necessário reunir todos os envolvidos do projeto para                     
tomarem essa decisão, a fim de, não comprometer a utilização mínima do software. 
Responsável​: Anne Caroline 
Status​: Em andamento. 
Quadro 8 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 8. 
9 ­ Dificuldade dos usuários em manusear o sistema 
Probabilidade​: 80%  Impacto​: Crítico 
Descrição​: Mudanças na rotina de trabalho e adoção de tecnologias novas podem                       
ocasionar dificuldades na utilização do software pelos usuários. 
Estratégia de Redução​: O sistema deve ser construído de forma que atenda os                         
requisitos de usabilidade do mercado, deve ter uma fácil e intuitiva utilização.                       
Treinamentos devem ser ministrados para os usuários. Também deverá ser feito                     
acompanhamento na utilização do software pelos usuários para identificar e executar                     
 
 
possíveis pontos de melhorias. Outra forma eficaz de realizar melhorias é ouvir o                         
feedback dos próprios usuários. 
Plano de Contingência​: Os gestores deverão ser notificados sobre essa dificuldade e                       
medidas como: realizar cursos de informática básica e ou avançados, a fim de, nivelar os                             
usuários nas tecnologias envolvidas. 
Responsável​: Fábio Nascimento 
Status​: Em andamento. 
Quadro 9 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 9. 
10 ­ Falta de familiaridade da equipe com as tecnologias exigidas para a construção                           
do software 
Probabilidade​: 50%  Impacto​: Crítico 
Descrição​: Existem requisitos mínimos impostos pelo hospital para construção do                   
software, como por exemplo linguagem de programação e banco de dados. Esses                       
requisitos podem não ser familiares para a equipe de desenvolvimento acarretando um                       
atraso na entrega e ou uma baixa qualidade no produto. 
Estratégia de Redução​: Uma vez identificados esses requisitos mínimos é necessários                     
verificar com a equipe de desenvolvimento se os membros estão familiarizados com os                         
mesmos. Caso não estejam, será necessário ajustar o planejamento do projeto para                       
conceber um tempo de aprendizagem. Através de treinamento e cursos. 
Plano de Contingência​: Ajustar o planejamento do projeto para conceber um tempo de                         
aprendizagem. Através de treinamento e cursos. Ou contratar pessoas que tenham                     
expertise nas tecnologias necessárias. 
Responsável​: Fábio Nascimento 
Status​: Em andamento. 
Quadro 10 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 10. 
11 ­ Pouco treinamento da equipe do hospital 
Probabilidade​: 20%  Impacto​: Crítico 
Descrição​: O treinamento é uma etapa importante na adoção de uma nova ferramenta de                           
trabalho. É através dele que dúvidas sobre o funcionamento e manuseio do software                         
serão sanadas. A falta de treinamento ou mesmo sua pouca execução pode ocasionar o                           
manuseio incorreto do software causando erros de informações e ou interpretações.                     
Como também, um descontentamento na utilização do mesmo. 
 
 
Estratégia de Redução​: A implantação do software deverá contemplar um período hábil                       
para treinamento dos usuários, como também o acompanhamento mais efetivo nos                     
primeiros meses de execução. 
Plano de Contingência​: Realizar treinamentos e acompanhamento mais efetivo nos 
primeiros meses de execução. 
Responsável​: Fábio Nascimento. 
Status​: Em andamento. 
Quadro 11 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 11. 
12 ­ Os enfermeiros podem, mesmo com treinos, não se adequarem às capacidades                         
técnicas exigidas pelo sistema 
Probabilidade​: 20%  Impacto​: Crítico 
Descrição​: Os enfermeiros podem, mesmo com treinos, não se adequarem às                     
capacidades técnicas exigidas pelo sistema podendo ocasionar a não utilização ou uma                       
má utilização do software. Causando erros de informações e ou interpretações. 
Estratégia de Redução​: Fazer análise dos perfis dos enfermeiros, a fim de, identificar                         
quais deverão ter atenção especial. Após essa análise, realizar cursos de informática                       
básica e ou avançados, a fim de, nivelar estes usuários nas tecnologias envolvidas. 
Plano de Contingência​: Realizar cursos de informática básica e ou avançados, a fim de, 
nivelar estes usuários nas tecnologias envolvidas. 
Responsável​: Fábio Nascimento. 
Status​: Em andamento. 
Quadro 12 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 12. 
13 ­ Rotatividade dos membros da equipe de desenvolvimento 
Probabilidade​: 10%  Impacto​: Crítico 
Descrição​: É comum haver rotatividades nas equipes de desenvolvimentos visto que este                       
equipe em especial é composta por alunos, onde os mesmos podem abandonar a                         
disciplina a qualquer momento. Com isso a equipe pode ficar reduzida e                       
consequentemente a entrega do projeto poderá atrasar. 
Estratégia de Redução​: Para dirimir os possíveis atrasos decorrentes da saída de                       
membros da equipe, algumas medidas podem ser tomadas, tais como: diminuir o escopo                         
 
 
do projeto, replanejar a data de entrega, dividir melhor as tarefas entre os membros                           
restantes ou recrutar novos integrantes para a equipe. 
Plano de Contingência​: Se nenhuma medida da estratégia de redução for efetiva os                         
gestores do projeto juntamente como o ​Product Owner deverão decidir como o projeto                         
será continuado ou mesmo se deverá ser abortado. 
Responsável​: Anne Caroline. 
Status​: Em andamento. 
Quadro 13 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 13. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4.0 PLANEJAMENTO TEMPORAL 
Nesta seção serão definidas datas, marcos, execução de tarefas e planos de ações.                         
Como também, os responsáveis por cada atividade anteriormente citada, o planejamento                     
temporal. Essa parte é de extrema importância para a mensuração do andamento do projeto,                           
e do cumprimento das suas expectativas na esfera temporal. 
 ​4.1 Conjunto de Tarefas do Projeto 
O modelo de processo a ser utilizado será a Metodologia Ágil de desenvolvimento                         
de projetos de software, o Scrum. 
As tarefas e atividades a serem realizadas durante o projeto de desenvolvimento                       
serão:  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                     ​Figura 2 ​­ Conjunto de tarefas do projeto.(Autores) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Acrônimos : ‘CRUD’ são todas as funcionalidades que devem ser realizadas para                       
manutenir uma classe. ex: funcionalidade de criação, alteração e exclusão.  
Segue uma visão geral das fases de desenvolvimento do software seguidos do seus                         
custos de tempo. 
 
Fase  Dias de Trabalho  Porcentagem de Dias de 
Trabalho com o Total de 
Dias 
Planejamento  16  8% 
Análise e Projeto  49  26% 
Codificação  39  20% 
Testes  90  46% 
Total de Dias  194  100% 
                              ​Tabela 4 ​­ Divisão dos dias de trabalho por fases do Projeto de Software.(Autores)​. 
 
4.2 Diagrama de Gantt  
O diagrama de Gantt que será apresentado foi baseado nas tarefas das Sprints de 1                             
a 6 da Figura 2, onde a ordem de apresentação das tarefas é a ordem que deve ser                                   
executada pelo(s) responsáveis no tempo proposto. 
 
 
 
 
 
Figura 3 ​­ Diagrama de Gantt ­ ​Tarefas a serem realizadas e suas datas de início e fim​.(Autores) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5.0 ORGANIZAÇÃO DO PESSOAL 
 ​5.1 Estrutura da equipe 
Como foi exposto nas seções anteriores, a estrutura da equipe ​terá ​alterações ao                         
longo do processo de trabalho. Portanto, todos os integrantes da equipe desempenharão                       
papel de gestor, desenvolvedor e testador.  
 ​5.2 Mecanismos de comunicação  
Optou­se pela utilização do software Trello, disponível na Internet, para o controle                       
e alocação das atividades. Este software possui ferramentas que facilitam a comunicação e                         
prestação de contas entre os integrantes. Também serão utilizados telefones, ​emails ​e                       
aplicativos de troca de mensagens para o estabelecimento da comunicação entre os                       
envolvidos. 
  5.3 Uso do Edu­blog como ferramenta de apoio 
O Edu­blog foi fundamental para a construção deste trabalho. A equipe utilizou­se                       
do mesmo para recorrer a trabalhos já desenvolvidos com o intuito de de produzir um                             
produto tão bom quanto os que já foram desenvolvidos. Além disso, o ​blog ​possibilitou                           
que os integrantes da equipe pudessem conhecer melhor, as tecnologias de computação em                         
nuvem disponíveis no mercado.  
O ​blog ​também foi uma experiência positiva, pois possibilitou o trabalho em                       
equipe, onde cada um buscou desempenhar seu papel da melhor maneira possível. 
Por fim, a utilização do ​blog ​fomentou a aprendizagem dos alunos, pois permitiu                         
que estes interagissem entre si e introduzissem novas ferramentas, conceitos, tecnologias e                       
abordagens, contribuindo para o crescimento intelectual de todos da turma. 
 
 
 
 ​6.0  PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A 
QUALIDADE DO PRODUTO DE SW 
Definições de Métricas 
Definir na fase de análise e projeto do sistema todas as métricas necessárias e seus                             
valores desejados, para quando medi­las no sistema de software verificar se os valores                         
medidos estão satisfazendo os valores desejados para a métrica medida. As métricas a serem                           
utilizadas serão a respeito da usabilidade, funcionalidade, portabilidade e manutenibilidade. 
Para garantir a qualidade da usuabilidade, deve­se usar métricas referente a                     
quantidade de ​clicks ​necessários para realizar um registro ou alteração no sistema,                       
quantidade de erros apresentados que não são mostrados ao usuários, tempo necessário para                         
realizar alguma tarefa. 
Na garantia da funcionalidade, deve­se usar métricas como a de verificação para                       
verificar se as funcionalidades estão sendo executadas em tempo satisfatório, quantos erros                       
possuem numa dada funcionalidade, e verificar quantos requisitos funcionais foram                   
completamente atendidos. 
Já na portabilidade, deve­se usar métricas para mensurar a capacidade que o                       
sistema possue para se comunicar com outros sistemas dentro da organização (HU). Qual o                           
nível de complexidade que o sistema necessita para que possa ser possível a comunicação                           
dele a outros, quando necessário? Deve­se, sempre, ter isso em mente, na escolha da                           
linguagem, frameworks, banco de dados e medir a complexidade segundo a quantidade de                         
alterações e adições necessárias no código fonte para que uma comunicação com um outro                           
sistema seja possível. 
Por fim, quanto as métricas relacionadas a manutenibilidade do sistema, deve­se                     
usar métricas para calcular o acoplamento entre as classes. Além disso, deve­se utilizar                         
métricas que verifiquem se o sistema está de acordo com as características da Orientação a                             
Objetos (OO), como: encapsulamento, herança e polimorfismo. Quanto maior a                   
conformidade com as características da Orientação a Objetos, maior é a facilidade de dar                           
manutenção ao software. É importante, também, definir uma métrica que indique a                       
 
 
quantidade de Padrões de Projeto que o sistema possui. Quanto maior o número de padrões,                             
mais fácil a realização de manutenção. 
Realização de Testes 
Os testes a serem realizados serão os testes unitários, de integração e de sistema.                           
Faz­se necessária a utilização em conjunto dos testes com as métricas para garantir a                           
qualidade do software. 
Os testes unitários serão realizados por uma pessoa diferente daquela que codificou                       
a funcionalidade a testar. Esse teste será realizado quando a funcionalidade for concluída.                         
Caso sejam identificadas falhas, os erros deverão ser corrigidos. Ao final da correção, a                           
sprint ​é finalizada. 
Os testes de integração são realizados quando todo o sistema for construído.                       
Assim, toda a comunicação e depedências entre componentes e funcionalidades serão                     
testados, para verificar se os requisitos estão sendo satisfeitos. 
O teste de sistema indica se o software junto com o seu banco de dados, servidor                               
web​, rede e hardware está funcionando corretamente. 
Desenvolvimento Iterativo 
Usando os princípios da Engenharia de Software, e adotando a técnica de                       
desenvolvimento iterativo é possível aumentar o nível de qualidade do produto de software.                         
Isto ocorre porque no desenvolvimento iterativo, é possível retomar a fases anteriores, na                         
ocorrência ou identificação de erros. Por exemplo, caso seja verificado durante a fase de                           
codificação que a regra de negócio está incorreta, os documentos da fase de análise e                             
projeto, poderão ser alterados. Esta prática só é possível, devido a Metodologia Ágil.                         
Durante o desenvolvimento do software é realizado uma espécie de evolução, onde todas as                           
fases podem sofrer alterações. 
Seguir a Metodologia Ágil Scrum 
 
 
O gestor do projeto deve fazer reuniões a cada sprint, para verificar com o                           
ScrumMaster se o processo de desenvolvimento de software está sendo realizado                     
corretamente. Deve­se ter em mente que ideias, inovações e adaptações sugeridas pela                       
equipe devem ser analisadas. Caso as sugestões sejam pertinentes, elas devem ser anexadas                         
mesmo que modifiquem o processo de desenvolvimento, criando uma espécie de Scrum                       
modificado. O objetivo central é melhorar o desempenho da equipe e consequentemente o                         
resultado final do projeto.   
 
 
 

Mais conteúdo relacionado

Mais procurados

Métricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de SoftwareMétricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de Software
Rogerio P C do Nascimento
 
Gerenciamento de Projeto para Desenvolvimento de Sistema
Gerenciamento de Projeto para Desenvolvimento de SistemaGerenciamento de Projeto para Desenvolvimento de Sistema
Gerenciamento de Projeto para Desenvolvimento de Sistema
elliando dias
 

Mais procurados (20)

Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Practice 4 :: Gestão de Projetos de SW OO :: Métricas, Estimação e Planificações
Practice 4 :: Gestão de Projetos de SW OO :: Métricas, Estimação e PlanificaçõesPractice 4 :: Gestão de Projetos de SW OO :: Métricas, Estimação e Planificações
Practice 4 :: Gestão de Projetos de SW OO :: Métricas, Estimação e Planificações
 
Aula9 TEES UFS Gestao de Configuração de SW
Aula9 TEES UFS  Gestao de Configuração de SWAula9 TEES UFS  Gestao de Configuração de SW
Aula9 TEES UFS Gestao de Configuração de SW
 
Lecture 5 :: Planejameto Temporal e Monitorização do Projeto
Lecture 5 :: Planejameto Temporal e Monitorização do ProjetoLecture 5 :: Planejameto Temporal e Monitorização do Projeto
Lecture 5 :: Planejameto Temporal e Monitorização do Projeto
 
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDDisciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
 
Métricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de SoftwareMétricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de Software
 
Plano de Ensino - Gerencia de Projetos - UFS - 2017-2
Plano de Ensino - Gerencia de Projetos - UFS - 2017-2Plano de Ensino - Gerencia de Projetos - UFS - 2017-2
Plano de Ensino - Gerencia de Projetos - UFS - 2017-2
 
Lecture 1 :: Gestão de Projetos de SW - 4 Ps - Fases da Engenharia de SW
Lecture 1 :: Gestão de Projetos de SW - 4 Ps - Fases da Engenharia de SWLecture 1 :: Gestão de Projetos de SW - 4 Ps - Fases da Engenharia de SW
Lecture 1 :: Gestão de Projetos de SW - 4 Ps - Fases da Engenharia de SW
 
Lecture 3 :: Análise e Gestão de Risco
Lecture 3 :: Análise e Gestão de RiscoLecture 3 :: Análise e Gestão de Risco
Lecture 3 :: Análise e Gestão de Risco
 
Lecture 4 :: As métricas para o Processo e Projeto de SW
Lecture 4 :: As métricas para o Processo e Projeto de SWLecture 4 :: As métricas para o Processo e Projeto de SW
Lecture 4 :: As métricas para o Processo e Projeto de SW
 
Plano de projeto - Gerência de Projetos
Plano de projeto - Gerência de ProjetosPlano de projeto - Gerência de Projetos
Plano de projeto - Gerência de Projetos
 
Aula11 TEES UFS Ferramentas CASE
Aula11  TEES  UFS   Ferramentas  CASEAula11  TEES  UFS   Ferramentas  CASE
Aula11 TEES UFS Ferramentas CASE
 
Gestão de Riscos by Lacertae SW
Gestão de Riscos by Lacertae SWGestão de Riscos by Lacertae SW
Gestão de Riscos by Lacertae SW
 
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SWAula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
 
Gerenciamento de Projeto para Desenvolvimento de Sistema
Gerenciamento de Projeto para Desenvolvimento de SistemaGerenciamento de Projeto para Desenvolvimento de Sistema
Gerenciamento de Projeto para Desenvolvimento de Sistema
 
Plano projeto(final)
Plano projeto(final)Plano projeto(final)
Plano projeto(final)
 
Aula Gestão de Projetos Escopo, Tempo e Custo
Aula Gestão de Projetos Escopo, Tempo e CustoAula Gestão de Projetos Escopo, Tempo e Custo
Aula Gestão de Projetos Escopo, Tempo e Custo
 
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFS
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFSApresentação da Disciplina Gerência de Projetos - DCOMP - UFS
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFS
 
Lecture 6 :: Gestão de Configuração de Software
Lecture 6 :: Gestão de Configuração de SoftwareLecture 6 :: Gestão de Configuração de Software
Lecture 6 :: Gestão de Configuração de Software
 

Destaque

Aula 2 - Planning for Web Engineering by Roger Pressman
Aula 2 -  Planning for Web Engineering by Roger PressmanAula 2 -  Planning for Web Engineering by Roger Pressman
Aula 2 - Planning for Web Engineering by Roger Pressman
Rogerio P C do Nascimento
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
ocfelipe
 
Aula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger PressmanAula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger Pressman
Rogerio P C do Nascimento
 
Ferramentas de planejamento
Ferramentas de planejamentoFerramentas de planejamento
Ferramentas de planejamento
Otavio Siqueira
 
Aula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger PressmanAula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger Pressman
Rogerio P C do Nascimento
 
Sistemas de controle de versão
Sistemas de controle de versãoSistemas de controle de versão
Sistemas de controle de versão
ocfelipe
 
Gt5 - Plano de Projeto
Gt5 - Plano de ProjetoGt5 - Plano de Projeto
Gt5 - Plano de Projeto
Manoel Mota
 

Destaque (17)

Ferramentas CASE
Ferramentas  CASEFerramentas  CASE
Ferramentas CASE
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
 
Risk Management by Roger Pressman
Risk Management by Roger PressmanRisk Management by Roger Pressman
Risk Management by Roger Pressman
 
Aula 2 - Planning for Web Engineering by Roger Pressman
Aula 2 -  Planning for Web Engineering by Roger PressmanAula 2 -  Planning for Web Engineering by Roger Pressman
Aula 2 - Planning for Web Engineering by Roger Pressman
 
Planificação do Projeto de Software
Planificação do Projeto de SoftwarePlanificação do Projeto de Software
Planificação do Projeto de Software
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
 
Aula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger PressmanAula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger Pressman
 
Ferramentas de planejamento
Ferramentas de planejamentoFerramentas de planejamento
Ferramentas de planejamento
 
Aula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger PressmanAula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger Pressman
 
Sistemas de controle de versão
Sistemas de controle de versãoSistemas de controle de versão
Sistemas de controle de versão
 
Slide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAFSlide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAF
 
Seminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XPSeminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XP
 
Gt5 - Plano de Projeto
Gt5 - Plano de ProjetoGt5 - Plano de Projeto
Gt5 - Plano de Projeto
 
Plano de Projeto SGS
Plano de Projeto SGSPlano de Projeto SGS
Plano de Projeto SGS
 
CMM – Capability Maturity Model
CMM – Capability Maturity Model CMM – Capability Maturity Model
CMM – Capability Maturity Model
 
Estimativa de software usando pontos de função
Estimativa de software usando pontos de funçãoEstimativa de software usando pontos de função
Estimativa de software usando pontos de função
 

Semelhante a Plano de Projeto

plano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhoplano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunho
userrx
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
ocfelipe
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisado
Jorge Barreto
 
plano_de_projeto_controlart_final
plano_de_projeto_controlart_finalplano_de_projeto_controlart_final
plano_de_projeto_controlart_final
userrx
 
Apostila de algoritmo e programação
Apostila de algoritmo e programaçãoApostila de algoritmo e programação
Apostila de algoritmo e programação
Thiago Marques
 

Semelhante a Plano de Projeto (20)

Plano do Projeto
Plano do ProjetoPlano do Projeto
Plano do Projeto
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Control
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
Planode de Projeto - SIGEP
Planode de Projeto - SIGEPPlanode de Projeto - SIGEP
Planode de Projeto - SIGEP
 
plano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunhoplano_de_projeto_controlart_rascunho
plano_de_projeto_controlart_rascunho
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
 
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisado
 
Plano de Projeto - Gerencia de Projetos
Plano de Projeto - Gerencia de ProjetosPlano de Projeto - Gerencia de Projetos
Plano de Projeto - Gerencia de Projetos
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
 
plano_de_projeto_controlart_final
plano_de_projeto_controlart_finalplano_de_projeto_controlart_final
plano_de_projeto_controlart_final
 
Plano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiaisPlano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiais
 
Plano de projeto
Plano de projetoPlano de projeto
Plano de projeto
 
Plano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWPlano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SW
 
Algoritmos e-programacao-apostila-completa
Algoritmos e-programacao-apostila-completaAlgoritmos e-programacao-apostila-completa
Algoritmos e-programacao-apostila-completa
 
Plano do-projeto-de-software- SACC- LACERTAE
Plano do-projeto-de-software- SACC- LACERTAEPlano do-projeto-de-software- SACC- LACERTAE
Plano do-projeto-de-software- SACC- LACERTAE
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de software
 
Plano de Projeto - OUTLAY
Plano de Projeto - OUTLAYPlano de Projeto - OUTLAY
Plano de Projeto - OUTLAY
 
algoritmos e programacao apostila completa
 algoritmos e programacao apostila completa algoritmos e programacao apostila completa
algoritmos e programacao apostila completa
 
Apostila de algoritmo e programação
Apostila de algoritmo e programaçãoApostila de algoritmo e programação
Apostila de algoritmo e programação
 

Plano de Projeto

  • 2.   Universidade Federal de Sergipe  Departamento de Computação          Anne Caroline Melo Santos   Fábio Nascimento Santos   Paulo Henrique dos Santos           Trabalho apresentado como avaliação da disciplina            Gerência de Projetos, no curso de Sistemas de                Informação, na Universidade Federal de Sergipe.  Prof. Dr. Rogério Patrício Chagas do Nascimento.        São Cristóvão  2016     
  • 3.   Sumário  1.0 INTRODUÇÃO   1.1 Âmbito do Projeto   1.2 Funções principais do produto de software   1.3 Requisitos comportamentais ou de performance   1.4 Gestão e Restrições Técnicas   2.0 ESTIMAÇÕES DO PROJETO   2.1 Dados históricos utilizados para as estimações   2.2 Técnicas de estimação e resultados   2.2.1 Técnica de estimação   2.3 Resultados   2.4 Recursos do projeto   2.4.1 Recursos Humanos   2.4.2 Recursos de Software   2.4.3 Recursos de Hardware   3.0 ANÁLISE E GESTÃO DE RISCOS   3.1 Riscos do projeto   3.2 Tabela de riscos   3.3 Redução e Gestão do Risco   4.0 PLANEJAMENTO TEMPORAL   4.1 Conjunto de Tarefas do Projeto   4.2 Diagrama de Gantt   5.0 ORGANIZAÇÃO DO PESSOAL   5.1 Estrutura da equipe   5.2 Mecanismos de comunicação   5.3 Uso do Edu­blog como ferramenta de apoio   6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE  DO PRODUTO DE SW    
  • 4.   1.0 INTRODUÇÃO  1.1 Âmbito do Projeto  Atualmente o Processo de Enfermagem realizado no Hospital Universitário de                    Sergipe é feito manualmente. O Processo é lento e sujeito a falhas, pois não existem                              mecanismos que controlem o acesso aos relatórios produzidos e que agilize o processo de                            avaliação do paciente. Diante disso, foi proposta a construção de um módulo que                          automatizasse o processo existente. Com a implantação desse módulo, os enfermeiros                      terão que passar por um treinamento para poderem aprender a manipular o sistema                          corretamente. Além disso, os formulários impressos serão substituídos por formulários                    eletrônicos.   O software proporcionará maior agilidade e facilidade no Processo de                    Enfermagem. O sistema proverá maior controle sobre os relatórios produzidos. Os                      profissionais com acesso a estes relatórios, também serão controlados.      ​1.2 Funções principais do produto de software  As principais funções do Módulo de Processo de Enfermagem são:   ● Manutenir Prescrição;  ● Manutenir Diagnóstico;  ● Manutenir Necessidade;  ● Recuperar Dados do Paciente;  ● O Sistema deverá fazer o mapeamento de necessidades para diagnóstico e                      de diagnóstico para prescrição, criando uma relação de dependência entre eles;  ● Manter Processo de Enfermagem;  ● Gerar Relatório de Evolução de Enfermagem;  ● Informar no relatório de evolução de enfermagem o nome do enfermeiro                      que está mantendo o Processo de Enfermagem.     
  • 5.    ​1.3 Requisitos comportamentais ou de performance  Dentre os requisitos comportamentais e de performance temos:   Usabilidade  ● O sistema deve apresentar uma interface amigável, intuitiva e de fácil                      utilização para garantir uma boa comunicação entre usuários e sistema.  ● O sistema deverá utilizar palavras que fazem sentido para o usuário. Toda                        comunicação do sistema precisa ser contextualizada ao usuário, e ser coerente com                        o chamado modelo mental do usuário.  Confiabilidade  ● O sistema deve apresentar mensagens de erros simples que ajudem o                      usuário a entender e a resolver o problema.  ● O sistema deve evitar situações de erro através do reconhecimento das                      situações que mais provocam erros e modificar a interface para que estes erros não                            ocorram.  Desempenho  ● O sistema deverá exibir na tela os dados do paciente em no máximo 10                            segundos.  ● O sistema deverá realizar o mapeamento de uma entidade para outra em no                          máximo 10 segundos.  Segurança  ● O sistema deverá ter controle de acesso e de manipulação de recursos.   ● O sistema deverá garantir a integridade e confidencialidade dos dados.   Implantação  ● O sistema deve ser implantado em um ambiente que tenha conexão com a                          Internet.   ● É necessário que os usuários passem por um período de treinamento para                        aprenderem a manipular o software corretamente.    
  • 6.    ​1.4 Gestão e Restrições Técnicas  As restrições técnicas encontradas no projeto foram:  ● O software deve ser feito no Eclipse, usando a linguagem java;  ● O software deve utilizar o banco de dados PostgreSQL;  ● Utilizar o TRELLO para gerenciar as tarefas durante o desenvolvimento do                      software;  ● Utilizar o Enterprise Architect para fazer a modelagem dos dados e criar os                          casos de uso;  ● Utilizar o Selenium para realização de testes;  ● Utilizar o Axure para prototipação das telas.                              
  • 7.    ​2.0 ESTIMAÇÕES DO PROJETO   ​2.1 Dados históricos utilizados para as estimações  Não serão utilizados dados históricos na mensuração do projeto, uma vez que é 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. A                            técnica escolhida foi a Lorenz & Kidd, Orientada a Objetos, adotada pela Lacertae                          Software   ​2.2.1 Técnica de estimação  A técnica de estimação escolhida para o Sistema de Processo de Enfermagem, foi                          a Lorenz & Kidd. Trata­se de uma métrica orientada a objetos que consiste em:  1. Determinar a quantidade de classes chave do projeto;  2. Encontrar o número de classes de suporte, classificando o tipo de    interface do produto e utilizando os multiplicadores correspondentes para  as  classes de suporte;  3. Multiplicar a quantidade de classes­chave 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 (dias­pessoa) por classe;  5. Calcular o tempo previsto para a realização do projeto.  Abaixo, temos uma tabela com os multiplicadores utilizados para encontrar a                      quantidade de classes de suporte:      
  • 8.     Tabela 1 ­ ​Multiplicadores da Métrica Lorenz & Kidd.  A tabela 1, classifica as interfaces em 4 tipos: não gráfica, baseada em texto, GUI                              simples e GUI complexa. Para cada tipo de interface será atribuído um multiplicador.   2.3 Resultados  A seguir, temos o diagrama de classes do Módulo do Processo de Enfermagem.    Figura 1 ​­ Diagrama de Classes (Autores).   
  • 9.   A figura 1 traz um Diagrama de Classes do Módulo de Processo de Enfermagem.                            O Diagrama de Classe mostra um conjunto de classes com seus relacionamentos e atributos.                            É o diagrama central da modelagem orientada a objetos.   1. Classes Chaves do Software: Pessoa, Paciente, Enfermeiro, Leito, Processo                  de Enfermagem, Prescrição Alternativa, Necessidade, Diagnóstico e Prescrição.                Total: 9 Classes Chaves;  2. Tipo das classes de suporte: Interface Gráfica com Usuário (Graphical User                      Interface – GUI);  3. Valor Multiplicador: 2,5;  4. Classes de suporte: 9 (classes chaves) x 2,5 (Valor multiplicador) = 22,5                        classes de suporte;  5. Total de classes: 9 (chave) + 22,5 (suporte) = 31,5;  6. Número médio de unidades de trabalho: 16 dias­pessoa;  7. Tempo previsto: 31,5 (classes) x 16 (dias) = 504 dias por pessoa para a                            construção das classes;  8. Considerando que a equipe é formada por 3 pessoas, chega­se ao total de                          168 dias;  9. O tempo total de projeto é 7,6 meses. Foi considerado que um mês tem 22                              dias levando em conta pontos facultativos e feriados.   ​2.4 Recursos do projeto  Recursos humanos, de software e hardware, ferramentas de apoio e outros recursos  necessários são listados abaixo:  2.4.1 Recursos Humanos    Optou­se pela adoção da Metodologia Ágil. Será adotada uma rotação na execução                        das tarefas. Todos os envolvidos no desenvolvimento do projeto exercerão papéis                      diferentes, sendo eles: gerente de projeto, desenvolvimento e testes.   
  • 10.   Serão adotadas 6 ​sprints​, onde cada uma delas terá duração de 28 dias. A divisão                              das atividades pode ser visualizada abaixo:     Sprint 1  Período:   Duração: 28 dias.  Scrum Master: Anne Caroline Melo Santos  Desenvolvedor (a): Paulo Henrique dos Santos  Testador: Fábio Nascimento Santos    Sprint 2  Período:   Duração: 28 dias.  Scrum Master: Paulo Henrique dos Santos  Desenvolvedor (a): Fábio Nascimento Santos  Testador: Anne Caroline Melo Santos    Sprint 3  Período:   Duração: 28 dias.  Scrum Master:  Fábio Nascimento Santos  Desenvolvedor (a): Anne Caroline Melo Santos  Testador: Paulo Henrique dos Santos    Sprint 4  Período:   Duração: 28 dias.  Scrum Master: Anne Caroline Melo Santos  Desenvolvedor (a): Paulo Henrique dos Santos   
  • 11.   Testador: Fábio Nascimento Santos    Sprint 5  Período:   Duração: 28 dias.  Scrum Master: Paulo Henrique dos Santos  Desenvolvedor (a): Fábio Nascimento Santos  Testador: Anne Caroline Melo Santos      Sprint 6  Período:   Duração: 28 dias.  Scrum Master: Fábio Nascimento Santos  Desenvolvedor (a): Anne Caroline Melo Santos  Testador: Paulo Henrique dos Santos    2.4.2 Recursos de Software  No desenvolvimento do projeto serão utilizados os seguintes softwares:  ● Eclipse  ■ IDE para o desenvolvimento do sistema.  ● Trello  ■ Ferramenta para o gerenciamento das atividades.  ● PostgreSQL  ■ Serviço de banco de dados que será utilizado para o armazenamento                      das informações geradas pelo sistema.  ● Enterprise Architect   ■ Software que será utilizado para fazer a modelagem dos dados e                      criar os casos de uso.   
  • 12.   ● Selenium  ■  Realização de testes.  ● Axure   ■ Prototipação das telas.    2.4.3 Recursos de Hardware  Serão utilizados 3 ​notebooks ​para o desenvolvimento do software aqui proposto.                             
  • 13.    ​3.0 ANÁLISE E GESTÃO DE RISCOS  Nessa seção, analisaremos os riscos envolvidos no projeto com o objetivo de                        indentificá­los, a fim de, elaborar um plano de contingência para minimizar sua ocorrência e                            fazendo com que os possíveis danos causados sejam mais previsíveis.   ​3.1 Riscos do Projeto    A identificação dos Riscos do Projeto é uma etapa importante para a redução de                            ocorrências dos mesmos. Na Tabela 2, estão listados alguns dos riscos mais críticos                          identificados no projeto.    Risco  Projeto  Técnico  Negócio  Comum  Especial  Dificuldade de integrar  com os sistemas já  existentes no hospital  X  X      X  Queda de energia pode  causar alguma falha e o  processo de enfermagem  pode ficar indisponível  por algum tempo      X    X  Enfermeiros podem não  aderir à mudança no seu  processo de trabalho      X    X  Os chefes de enfermagem  não participam das etapas  do processo de software  X    X      O sistema ficar fora do ar    X  X    X  Os gestores não são  apoiadores do produto  X        X  Possibilidade do risco de  incêndio na sala dos  servidores      X    X   
  • 14.   Equipe de  desenvolvimento pequena  X        X  Dificuldade dos usuários  em manusear o sistema        X    Falta de familiaridade da  equipe com as  tecnologias exigidas para  a construção do software  X  X        Pouco treinamento da  equipe do hospital      X  X    Os enfermeiros podem,  mesmo com treinos, não  se adequar às capacidades  técnicas exigidas pelo  sistema      X  X    Rotatividade dos  membros da equipe de  desenvolvimento  X  X        Tabela 2 ­ ​Caracterização dos Riscos do Projeto mais críticos identificados.    3.2 Tabela de riscos  Após a identificação dos principais Riscos do Projeto, é feita uma análise                        probabilística de ocorrência para cada risco. Essa análise leva em consideração todas as                          etapas do desenvolvido do software até depois de sua implantação.  Os riscos de impacto “Catastrófico”, caracterizam a não disponibilidade ou não                      utilização do software. Já os riscos de impacto “Crítico” dizem respeito às etapas de                            desenvolvimentos ou dificuldades na utilização do software.    Nome do Risco  %Probabilidade  Impacto  Dificuldade de integrar com os sistemas já              existentes no hospital  90%  Catastrófico   
  • 15.   Queda de energia pode causar alguma falha e o                  processo de enfermagem pode ficar indisponível            por algum tempo  90%  Catastrófico  Enfermeiros podem não aderir à mudança no seu                processo de trabalho.  60%  Catastrófico  Os chefes de enfermagem não participam das              etapas do processo de software  30%  Catastrófico  O sistema ficar fora do ar  10%  Catastrófico  Os gestores não são apoiadores do produto  10%  Catastrófico  Possibilidade do risco de incêndio na sala dos                servidores  10%  Catastrófico  Equipe de desenvolvimento pequena  80%  Crítico  Dificuldade dos usuários em manusear o sistema  80%  Crítico  Falta de familiaridade da equipe com as              tecnologias exigidas para a construção do            software  50%  Crítico  Pouco treinamento da equipe do hospital  20%  Crítico  Os enfermeiros podem, mesmo com treinos, não              se adequar às capacidades técnicas exigidas pelo              sistema  20%  Crítico  Rotatividade dos membros da equipe de            desenvolvimento  10%  Crítico  Tabela 3 ­ ​Probabilidade e Impactos dos Riscos de Projetos mais críticos.  3.3 Redução e Gestão do Risco  Para garantir a Redução, Supervisão e Gestão dos Riscos (RSGR) foram utilizadas                        as seguintes estratégias:  1 ­ Dificuldade de integrar com os sistemas já existentes no hospital  Probabilidade​: 90%  Impacto​: Catastrófico  Descrição​: Dificuldade de integração com os sistemas já existentes no hospital,                      acarretando em atraso na entrega e ou mau funcionamento do sistema.   
  • 16.   Estratégia de Redução​: Para dirimir as dificuldades de integração com os sistemas do                          hospital, é ideal que se simule o ambiente tecnológico (servidores, banco de dados e                            sistemas) do hospital e que sejam realizados testes prévios de integração durante o                          desenvolvimento do software.  Plano de Contingência​: Na ocorrência deste risco, primeiramente deverá ser analisado                      se houve mudança entre o ambiente simulado e o ambiente do hospital. Após esta                            análise, se houver mudanças elas deverão ser reparadas e novos testes de integrações                          deverão ser feitos. É fundamental envolver as equipes de desenvolvimento do software e                          a equipe de tecnologia do hospital.  Responsável​: Paulo Henrique  Status​: Em andamento.  Quadro 1 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 1.  2 ­ Queda de Energia  Probabilidade​: 90%  Impacto​: Catastrófico  Descrição​: A queda de energia pode causar alguma falha e o processo de enfermagem                            pode ficar indisponível por algum tempo.  Estratégia de Redução​: Para se evitar a queda de energia uma medida pode ser adotada:                              aquisição de geradores de energia. Outra medida que poderia ser adotada, a respeito da                            sala de servidores, é a replicação em regiões geográficas diferentes com a utilização de                            técnicas de clusters.  Plano de Contingência​: O processo de enfermagem não pode parar, logo na falta de                            energia os sistemas estarão indisponíveis e os formulários impressos deverão ser                      utilizados. Assim que a energia voltar estes formulários deverão ser transpostos para o                          sistema para garantir a plena utilização do sistema.  Responsável​: Paulo Henrique  Status​: Em andamento.  Quadro 2 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 2.  3 ­ Enfermeiros podem não aderir à mudança no seu processo de trabalho  Probabilidade​: 60%  Impacto​: Catastrófico  Descrição​: Todo processo de mudança gera um desconforma para os envolvidos. Com                        isso, os enfermeiros podem oferecer resistência na adoção do software desenvolvido. Se                        os enfermeiros não aderirem ao software, este entrará em desuso.   
  • 17.   Estratégia de Redução​: Para dirimir as chances de haver resistência na adoção do                          software, é necessário que se faça acompanhamento do projeto com os enfermeiros (que                          são os principais utilizadores) para garantir que o produto seja satisfatório e de fato                            melhore os processos de trabalho dos mesmos.   Plano de Contingência​: Com a resistência na adoção do software pelos enfermeiros. É                          necessário envolver os gestores do projeto para dialogar com os mesmos a fim de                            convencê­los a utilizarem o software.  Responsável​: Anne Caroline  Status​: Em andamento.  Quadro 3 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 3.  4 ­ Os chefes de enfermagem não participam das etapas do processo de software  Probabilidade​: 30%  Impacto​: Catastrófico  Descrição​: O não envolvimento dos chefes de enfermagem (principais apoiadores) no                      projeto pode acarretar na construção de software que não atenda as necessidades do setor                            e portanto a não utilização do mesmo.  Estratégia de Redução​: Os chefes de enfermagem devem participar de todas as etapas                          de desenvolvimento do software, validando e testando, se o que está sendo construído                          pela equipe de desenvolvimento está de acordo com suas necessidades.  Plano de Contingência​: Após o software ter sido construído sem a participação dos                          chefes de enfermagem, existe uma grande chance dos mesmos não utilizarem­no. Se isso                          ocorre o ​Product Owner e os gestores do projeto deverão convencer os chefes a                            utilizarem o software, caso contrário o software entrará em desuso.   Responsável​: Anne Caroline  Status​: Em andamento.  Quadro 4 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 4.  5 ­ O sistema ficar fora do ar   Probabilidade​: 10%  Impacto​: Catastrófico  Descrição​: A não disponibilidade do sistema poderá acarretará em prejuízo para o                        hospital. Os processos de enfermagem não poderão ser executados com eficiência,                      podendo causar danos para seus pacientes. Como também, gerará insatisfação nos                      usuários e insegurança quanto à qualidade do software, o que poderá resultar na sua não                              utilização se vier a ocorrer com frequência.   
  • 18.   Estratégia de Redução​: Deverão ser utilizadas ferramentas para diagnosticar todo o                      ambiente onde o software estiver instalado. Ferramentas de monitoramento de banco de                        dados e aplicações. Também deverão ser utilizadas estratégias de replicação para o                        banco de dados e para a aplicação.  Plano de Contingência​: O processo de enfermagem não pode parar, logo na                        indisponibilidade do sistema, os formulários impressos deverão ser utilizados. E em                      paralelo o ambiente deverá ser reiniciado e os logs das ferramentas de monitoramento                          deverão ser revisto, a fim de, identificar e corrigir a falha.  Responsável​: Paulo Henrique  Status​: Em andamento.  Quadro 5 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 5.  6 ­ Os gestores não são apoiadores do produto  Probabilidade​: 10%  Impacto​: Catastrófico  Descrição​: Ter apoio dos gestores envolvidos no projeto é de fundamental importância                        para a plena execução do software. Não ter apoio desses gestores pode acarretar na não                              utilização do mesmo.  Estratégia de Redução​: Todos os gestores devem participar das etapas de                      desenvolvimento para garantir que o produto construído está em conformidade com suas                        necessidades.  Plano de Contingência​: Se os gestores não são apoiadores do software o ​Product                          Owner deverá dialogar com os mesmos para convencê­los de sua utilização. Caso não                          consiga, o software entrará em desuso.  Responsável​: Anne Caroline  Status​: Em andamento.  Quadro 6 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 6.  7 ­ Possibilidade do risco de incêndio na sala dos servidores  Probabilidade​: 10%  Impacto​: Catastrófico  Descrição​: A sala dos servidores é um local estratégico para as organizações. Com a                            grande quantidade de equipamentos ou eventos externos, é possível haver focos de                        incêndios.   
  • 19.   Estratégia de Redução​: Para dirimir a ocorrência de incêndios medidas como: sistema                        anti­incêndio, e um efetivo sistema de refrigeração podem ser tomadas. Mas também, é                          fundamental que haja um sistema de replicação geográfica das aplicações e do banco de                            dados.  Plano de Contingência​: Se o risco se concretizar o sistema de replicação deverá entrará  em vigor, ou seja, o acesso deverá ser redirecionado para outro lugar.  Responsável​: Paulo Henrique  Status​: Em andamento.  Quadro 7 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 7.  8 ­ Equipe de desenvolvimento pequena  Probabilidade​: 80%  Impacto​: Crítico  Descrição​: Ter uma equipe de desenvolvimento pequena pode acarretar em atrasos na                        entrega do produto se o escopo exigido pelo projeto for maior do que a equipe possa dar                                  conta.  Estratégia de Redução​: Se o escopo do projeto requer mais tempo do que foi planejado,                              as datas e prazos deverão ser replanejadas para adequar ao tamanho da equipe.  Plano de Contingência​: Caso não haja tempo suficiente para completar a                      desenvolvimento do produto, será necessário decidir quais funcionalidades serão                  efetivamente concluídas. Será necessário reunir todos os envolvidos do projeto para                      tomarem essa decisão, a fim de, não comprometer a utilização mínima do software.  Responsável​: Anne Caroline  Status​: Em andamento.  Quadro 8 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 8.  9 ­ Dificuldade dos usuários em manusear o sistema  Probabilidade​: 80%  Impacto​: Crítico  Descrição​: Mudanças na rotina de trabalho e adoção de tecnologias novas podem                        ocasionar dificuldades na utilização do software pelos usuários.  Estratégia de Redução​: O sistema deve ser construído de forma que atenda os                          requisitos de usabilidade do mercado, deve ter uma fácil e intuitiva utilização.                        Treinamentos devem ser ministrados para os usuários. Também deverá ser feito                      acompanhamento na utilização do software pelos usuários para identificar e executar                       
  • 20.   possíveis pontos de melhorias. Outra forma eficaz de realizar melhorias é ouvir o                          feedback dos próprios usuários.  Plano de Contingência​: Os gestores deverão ser notificados sobre essa dificuldade e                        medidas como: realizar cursos de informática básica e ou avançados, a fim de, nivelar os                              usuários nas tecnologias envolvidas.  Responsável​: Fábio Nascimento  Status​: Em andamento.  Quadro 9 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 9.  10 ­ Falta de familiaridade da equipe com as tecnologias exigidas para a construção                            do software  Probabilidade​: 50%  Impacto​: Crítico  Descrição​: Existem requisitos mínimos impostos pelo hospital para construção do                    software, como por exemplo linguagem de programação e banco de dados. Esses                        requisitos podem não ser familiares para a equipe de desenvolvimento acarretando um                        atraso na entrega e ou uma baixa qualidade no produto.  Estratégia de Redução​: Uma vez identificados esses requisitos mínimos é necessários                      verificar com a equipe de desenvolvimento se os membros estão familiarizados com os                          mesmos. Caso não estejam, será necessário ajustar o planejamento do projeto para                        conceber um tempo de aprendizagem. Através de treinamento e cursos.  Plano de Contingência​: Ajustar o planejamento do projeto para conceber um tempo de                          aprendizagem. Através de treinamento e cursos. Ou contratar pessoas que tenham                      expertise nas tecnologias necessárias.  Responsável​: Fábio Nascimento  Status​: Em andamento.  Quadro 10 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 10.  11 ­ Pouco treinamento da equipe do hospital  Probabilidade​: 20%  Impacto​: Crítico  Descrição​: O treinamento é uma etapa importante na adoção de uma nova ferramenta de                            trabalho. É através dele que dúvidas sobre o funcionamento e manuseio do software                          serão sanadas. A falta de treinamento ou mesmo sua pouca execução pode ocasionar o                            manuseio incorreto do software causando erros de informações e ou interpretações.                      Como também, um descontentamento na utilização do mesmo.   
  • 21.   Estratégia de Redução​: A implantação do software deverá contemplar um período hábil                        para treinamento dos usuários, como também o acompanhamento mais efetivo nos                      primeiros meses de execução.  Plano de Contingência​: Realizar treinamentos e acompanhamento mais efetivo nos  primeiros meses de execução.  Responsável​: Fábio Nascimento.  Status​: Em andamento.  Quadro 11 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 11.  12 ­ Os enfermeiros podem, mesmo com treinos, não se adequarem às capacidades                          técnicas exigidas pelo sistema  Probabilidade​: 20%  Impacto​: Crítico  Descrição​: Os enfermeiros podem, mesmo com treinos, não se adequarem às                      capacidades técnicas exigidas pelo sistema podendo ocasionar a não utilização ou uma                        má utilização do software. Causando erros de informações e ou interpretações.  Estratégia de Redução​: Fazer análise dos perfis dos enfermeiros, a fim de, identificar                          quais deverão ter atenção especial. Após essa análise, realizar cursos de informática                        básica e ou avançados, a fim de, nivelar estes usuários nas tecnologias envolvidas.  Plano de Contingência​: Realizar cursos de informática básica e ou avançados, a fim de,  nivelar estes usuários nas tecnologias envolvidas.  Responsável​: Fábio Nascimento.  Status​: Em andamento.  Quadro 12 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 12.  13 ­ Rotatividade dos membros da equipe de desenvolvimento  Probabilidade​: 10%  Impacto​: Crítico  Descrição​: É comum haver rotatividades nas equipes de desenvolvimentos visto que este                        equipe em especial é composta por alunos, onde os mesmos podem abandonar a                          disciplina a qualquer momento. Com isso a equipe pode ficar reduzida e                        consequentemente a entrega do projeto poderá atrasar.  Estratégia de Redução​: Para dirimir os possíveis atrasos decorrentes da saída de                        membros da equipe, algumas medidas podem ser tomadas, tais como: diminuir o escopo                           
  • 22.   do projeto, replanejar a data de entrega, dividir melhor as tarefas entre os membros                            restantes ou recrutar novos integrantes para a equipe.  Plano de Contingência​: Se nenhuma medida da estratégia de redução for efetiva os                          gestores do projeto juntamente como o ​Product Owner deverão decidir como o projeto                          será continuado ou mesmo se deverá ser abortado.  Responsável​: Anne Caroline.  Status​: Em andamento.  Quadro 13 ­ ​Redução, Supervisão e Gestão dos Riscos (RSGR) do ​Risco 13.                                     
  • 23.   4.0 PLANEJAMENTO TEMPORAL  Nesta seção serão definidas datas, marcos, execução de tarefas e planos de ações.                          Como também, os responsáveis por cada atividade anteriormente citada, o planejamento                      temporal. Essa parte é de extrema importância para a mensuração do andamento do projeto,                            e do cumprimento das suas expectativas na esfera temporal.   ​4.1 Conjunto de Tarefas do Projeto  O modelo de processo a ser utilizado será a Metodologia Ágil de desenvolvimento                          de projetos de software, o Scrum.  As tarefas e atividades a serem realizadas durante o projeto de desenvolvimento                        serão:      
  • 26.   Acrônimos : ‘CRUD’ são todas as funcionalidades que devem ser realizadas para                        manutenir uma classe. ex: funcionalidade de criação, alteração e exclusão.   Segue uma visão geral das fases de desenvolvimento do software seguidos do seus                          custos de tempo.    Fase  Dias de Trabalho  Porcentagem de Dias de  Trabalho com o Total de  Dias  Planejamento  16  8%  Análise e Projeto  49  26%  Codificação  39  20%  Testes  90  46%  Total de Dias  194  100%                                ​Tabela 4 ​­ Divisão dos dias de trabalho por fases do Projeto de Software.(Autores)​.    4.2 Diagrama de Gantt   O diagrama de Gantt que será apresentado foi baseado nas tarefas das Sprints de 1                              a 6 da Figura 2, onde a ordem de apresentação das tarefas é a ordem que deve ser                                    executada pelo(s) responsáveis no tempo proposto.   
  • 29.   5.0 ORGANIZAÇÃO DO PESSOAL   ​5.1 Estrutura da equipe  Como foi exposto nas seções anteriores, a estrutura da equipe ​terá ​alterações ao                          longo do processo de trabalho. Portanto, todos os integrantes da equipe desempenharão                        papel de gestor, desenvolvedor e testador.    ​5.2 Mecanismos de comunicação   Optou­se pela utilização do software Trello, disponível na Internet, para o controle                        e alocação das atividades. Este software possui ferramentas que facilitam a comunicação e                          prestação de contas entre os integrantes. Também serão utilizados telefones, ​emails ​e                        aplicativos de troca de mensagens para o estabelecimento da comunicação entre os                        envolvidos.    5.3 Uso do Edu­blog como ferramenta de apoio  O Edu­blog foi fundamental para a construção deste trabalho. A equipe utilizou­se                        do mesmo para recorrer a trabalhos já desenvolvidos com o intuito de de produzir um                              produto tão bom quanto os que já foram desenvolvidos. Além disso, o ​blog ​possibilitou                            que os integrantes da equipe pudessem conhecer melhor, as tecnologias de computação em                          nuvem disponíveis no mercado.   O ​blog ​também foi uma experiência positiva, pois possibilitou o trabalho em                        equipe, onde cada um buscou desempenhar seu papel da melhor maneira possível.  Por fim, a utilização do ​blog ​fomentou a aprendizagem dos alunos, pois permitiu                          que estes interagissem entre si e introduzissem novas ferramentas, conceitos, tecnologias e                        abordagens, contribuindo para o crescimento intelectual de todos da turma.     
  • 30.    ​6.0  PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A  QUALIDADE DO PRODUTO DE SW  Definições de Métricas  Definir na fase de análise e projeto do sistema todas as métricas necessárias e seus                              valores desejados, para quando medi­las no sistema de software verificar se os valores                          medidos estão satisfazendo os valores desejados para a métrica medida. As métricas a serem                            utilizadas serão a respeito da usabilidade, funcionalidade, portabilidade e manutenibilidade.  Para garantir a qualidade da usuabilidade, deve­se usar métricas referente a                      quantidade de ​clicks ​necessários para realizar um registro ou alteração no sistema,                        quantidade de erros apresentados que não são mostrados ao usuários, tempo necessário para                          realizar alguma tarefa.  Na garantia da funcionalidade, deve­se usar métricas como a de verificação para                        verificar se as funcionalidades estão sendo executadas em tempo satisfatório, quantos erros                        possuem numa dada funcionalidade, e verificar quantos requisitos funcionais foram                    completamente atendidos.  Já na portabilidade, deve­se usar métricas para mensurar a capacidade que o                        sistema possue para se comunicar com outros sistemas dentro da organização (HU). Qual o                            nível de complexidade que o sistema necessita para que possa ser possível a comunicação                            dele a outros, quando necessário? Deve­se, sempre, ter isso em mente, na escolha da                            linguagem, frameworks, banco de dados e medir a complexidade segundo a quantidade de                          alterações e adições necessárias no código fonte para que uma comunicação com um outro                            sistema seja possível.  Por fim, quanto as métricas relacionadas a manutenibilidade do sistema, deve­se                      usar métricas para calcular o acoplamento entre as classes. Além disso, deve­se utilizar                          métricas que verifiquem se o sistema está de acordo com as características da Orientação a                              Objetos (OO), como: encapsulamento, herança e polimorfismo. Quanto maior a                    conformidade com as características da Orientação a Objetos, maior é a facilidade de dar                            manutenção ao software. É importante, também, definir uma métrica que indique a                         
  • 31.   quantidade de Padrões de Projeto que o sistema possui. Quanto maior o número de padrões,                              mais fácil a realização de manutenção.  Realização de Testes  Os testes a serem realizados serão os testes unitários, de integração e de sistema.                            Faz­se necessária a utilização em conjunto dos testes com as métricas para garantir a                            qualidade do software.  Os testes unitários serão realizados por uma pessoa diferente daquela que codificou                        a funcionalidade a testar. Esse teste será realizado quando a funcionalidade for concluída.                          Caso sejam identificadas falhas, os erros deverão ser corrigidos. Ao final da correção, a                            sprint ​é finalizada.  Os testes de integração são realizados quando todo o sistema for construído.                        Assim, toda a comunicação e depedências entre componentes e funcionalidades serão                      testados, para verificar se os requisitos estão sendo satisfeitos.  O teste de sistema indica se o software junto com o seu banco de dados, servidor                                web​, rede e hardware está funcionando corretamente.  Desenvolvimento Iterativo  Usando os princípios da Engenharia de Software, e adotando a técnica de                        desenvolvimento iterativo é possível aumentar o nível de qualidade do produto de software.                          Isto ocorre porque no desenvolvimento iterativo, é possível retomar a fases anteriores, na                          ocorrência ou identificação de erros. Por exemplo, caso seja verificado durante a fase de                            codificação que a regra de negócio está incorreta, os documentos da fase de análise e                              projeto, poderão ser alterados. Esta prática só é possível, devido a Metodologia Ágil.                          Durante o desenvolvimento do software é realizado uma espécie de evolução, onde todas as                            fases podem sofrer alterações.  Seguir a Metodologia Ágil Scrum   
  • 32.   O gestor do projeto deve fazer reuniões a cada sprint, para verificar com o                            ScrumMaster se o processo de desenvolvimento de software está sendo realizado                      corretamente. Deve­se ter em mente que ideias, inovações e adaptações sugeridas pela                        equipe devem ser analisadas. Caso as sugestões sejam pertinentes, elas devem ser anexadas                          mesmo que modifiquem o processo de desenvolvimento, criando uma espécie de Scrum                        modificado. O objetivo central é melhorar o desempenho da equipe e consequentemente o                          resultado final do projeto.