plano de projeto

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 Edublog 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. Tratase 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 classeschave pelo multiplicador

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

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

unidades de trabalho (diaspessoa) por classe;

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

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 diaspessoa;

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, chegase 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

Optouse 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


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.




3 Enfermeiros podem não aderir à mudança no seu processo de trabalho


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



4 Os chefes de enfermagem não participam das etapas do processo de software


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




5 O sistema ficar fora do ar


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.




6 Os gestores não são apoiadores do produto


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.




7 Possibilidade do risco de incêndio na sala dos servidores


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 antiincê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.




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.




9 Dificuldade dos usuários em manusear o sistema


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



10 Falta de familiaridade da equipe com as tecnologias exigidas para a construção do software


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



11 Pouco treinamento da equipe do hospital


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.



12 Os enfermeiros podem, mesmo com treinos, não se adequarem às capacidades técnicas exigidas pelo sistema


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.



13 Rotatividade dos membros da equipe de desenvolvimento


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.



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

Optouse 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 Edublog como ferramenta de apoio

O Edublog foi fundamental para a construção deste trabalho. A equipe utilizouse

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 medilas 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, devese 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, devese 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, devese 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? Devese, 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, devese

usar métricas para calcular o acoplamento entre as classes. Além disso, devese 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.

Fazse 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. Devese 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.