Este documento resume um plano de projeto de software orientado a objetos para desenvolver um módulo de processo de enfermagem para um hospital. O projeto será realizado por uma equipe de 3 pessoas em 6 sprints de 4 semanas cada usando a metodologia ágil Scrum. O projeto levará cerca de 7 meses e meio para ser concluído.

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

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:

25.
​Figura 2 ​­ Conjunto de tarefas do projeto.(Autores)

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.

28.
Figura 3 ​­ Diagrama de Gantt ­ ​Tarefas a serem realizadas e suas datas de início e fim​.(Autores)

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.