UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Gerência de Projetos 201...
Felipe Oliveira Carvalho
Ramon Batista Ramos
Rodrigo Losano Fontes Calheiros
Washington Cavalcante da Silva

PLANO DO PROJ...
Sumário
1.

INTRODUÇÃO.......................................................................................................
1. INTRODUÇÃO
1.1 Âmbito do Projeto

O SISCONI (Sistema de Controle de Internação) tem por objetivo auxiliar o
processo de...
Localizar dados de pacientes;

Atendente

Atualizar dados de pacientes

Atendente

Verificar o histórico de internações de...
1. Ser fácil de usar, possuindo uma linguagem de acordo com o ambiente do
negócio.
2. Ser capaz de estar funcionando a tod...
Este é o primeiro projeto desenvolvido pela equipe, não existindo assim, dados
históricos para balizar as estimativas dos ...
6. Multiplica-se a quantidade total de classes (chave mais suporte) pelo fator
encontrado na etapa anterior, encontrando a...
Fase

Estimativa

Dias de Trabalho

Planejamento

3%

105 x 3% = 3 dias

Análise e Projeto

20%

105 x 20% = 21 dias

Gera...
Sprint 2

Período: 10/02/2014 à 07/03/2014

Scrum Master

Ramon Ramos

Developer 1

Washington Silva

Developer 2

Rodrigo...
2.4.2 Recursos de Software
Para a construção do software serão utilizados alguns outros softwares que
auxiliarão no proces...
Com o objetivo de centralizar os artefatos gerados no processo de
desenvolvimento do software serão utilizados os serviços...
Retenção de pessoas chaves

X

X

Subestimativas do esforço

X

X

Tabela 3–Riscos gerais de um projeto de software.

Aval...
7. Os requisitos do projeto são estáveis?
Os requisitos foram bem definidos no início do trabalho, porém algumas
alteraçõe...
software.
Custos associados a um Produto

30%

Crítico

80%

Moderado

50%

Moderado

Atraso na entrega

50%

Moderado

Di...
Visando garantir a redução da probabilidade dos riscos identificados na seção
anterior, bem como seu impacto em caso de oc...
programadores.
Plano de contingência: Fazer com que os programadores alocados para
o projeto tenham bastante produtividade...
Estratégia de redução: Não pular etapas do processo de software
estabelecido na Organização. O processo de software deve s...
de um software com mais qualidade. Neste contexto, a ausência de
ferramentas CASE que dão suporte à essa atividade obriga ...
8. Atraso na entrega
Probabilidade: 50%

Impacto: Moderado

Descrição: É comum o atraso na entrega do software. Entretanto...
4.2 Diagrama de Gantt
O cronograma extraído do diagrama de gantt encontra-se abaixo:
Uma visão mais detalhada do diagrama de gantt pode ser vista no blog da
equipe FRRW Gerência: http://frrw-gerencia.blogspo...
Este papel tem como objetivo liderar e coordenar as atividades e os artefatos
técnicos no decorrer do projeto. Além disso,...
Analista de Sistemas

Felipe Carvalho

Arquiteto de Software

Rodrigo Calheiros

Analista de Testes

Ramon Ramos

5.2 Meca...
A fim de assegurar a qualidade do software, algumas atividades foram
desenvolvidas durante o projeto, sendo elas:

Testes:...
7. ANEXOS

Figura 1.1 – Diagrama de Classes de domínio do SISCONI
Figura 1.2 – Diagrama lógico do banco de dados do SISCONI
Upcoming SlideShare
Loading in …5
×

Plano de projeto de software - SISCONI

415 views
266 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
415
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Plano de projeto de software - SISCONI

  1. 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Gerência de Projetos 2013.2 PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW Felipe Oliveira Carvalho Ramon Batista Ramos Rodrigo Losano Fontes Calheiros Washington Cavalcante da Silva São Cristóvão – Sergipe 2014
  2. 2. Felipe Oliveira Carvalho Ramon Batista Ramos Rodrigo Losano Fontes Calheiros Washington Cavalcante da Silva PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como parte avaliativa da disciplina Gerência de Projetos do Curso de Graduação em Sistemas de Informação da Universidade Federal de Sergipe – UFS. São Cristóvão – Sergipe 2014
  3. 3. Sumário 1. INTRODUÇÃO.................................................................................................................... 4 1.1 1.2 Funções principais do produto de software ............................................................ 4 1.3 Requisitos comportamentais ou de performance ................................................... 5 1.4 2. Âmbito do Projeto ...................................................................................................... 4 Gestão e Restrições Técnicas .................................................................................. 6 ESTIMATIVAS DO PROJETO ............................................................................................ 6 2.1 Dados históricos utilizados para as estimações ..................................................... 6 2.2 Técnicas de estimação e resultados ........................................................................ 7 2.3 Resultados ................................................................................................................. 8 2.4 Recursos do projeto .................................................................................................. 9 2.4.1 2.4.2 Recursos de Software .......................................................................................11 2.4.3 3. Recursos Humanos ............................................................................................ 9 Recursos de Hardware ......................................................................................11 ANÁLISE E GESTÃO DE RISCOS ...................................................................................12 3.1 3.2 Tabela de riscos ........................................................................................................14 3.3 4. Riscos do projeto......................................................................................................12 Redução e Gestão do Risco .....................................................................................15 PLANEJAMENTO TEMPORAL ........................................................................................20 4.1 4.2 5. Conjunto de Tarefas do Projeto ...............................................................................20 Diagrama de Gantt ....................................................................................................21 ORGANIZAÇÃO DO PESSOAL ........................................................................................22 5.1 Estrutura da equipe ..................................................................................................22 5.2 Mecanismos de comunicação..................................................................................24 5.3 Uso do Edu-blog como ferramenta de apoio ..........................................................24 6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE .....................................................................................................24 7. ANEXOS............................................................................................................................26
  4. 4. 1. INTRODUÇÃO 1.1 Âmbito do Projeto O SISCONI (Sistema de Controle de Internação) tem por objetivo auxiliar o processo de Internação do Hospital Universitário da Universidade Federal de Sergipe. Além de auxiliar esse processo, ele também atua como fonte de informações estatísticas e históricas para os processos de tomada de decisão na gerência do hospital. Com o SISCONI é possível agilizar o processo de internação, manter centralizadas as informações referentes aos leitos do hospital, manter um cadastro de pacientes e informações à respeito de suas internações. Permite também o remanejamento de leitos, além do controle de altas dadas pelos médicos aos pacientes internados. Através das Figuras 1.1 e 1.2 mostradas no anexo (seção 7) deste documento é possível observar respectivamente os diagramas de classe do domínio do projeto e o digrama do modelo lógico do banco de dados. Com estes digramas é possível obter uma abstração da estrutura do sistema. 1.2 Funções principais do produto de software O sistema a ser desenvolvido será composto de diversas funcionalidades. Todas elas com maior ou menor importância dentro do projeto, mas que juntas formamo software necessário para a atividade do cliente. As principais funcionalidades com seus respectivos usuários serão detalhadas abaixo: Funcionalidade Usuários Cadastrar os dados de pacientes a serem Atendente internados
  5. 5. Localizar dados de pacientes; Atendente Atualizar dados de pacientes Atendente Verificar o histórico de internações de um Atendente paciente Cadastrar um leito Gestor Bloquear um leito Gestor Desbloquear um leito Gestor Liberar um leito Atendente Verificar a ocupação dos leitos Atendente Iniciar uma internação Atendente Agendar uma internação Atendente Dar alta a um paciente Remanejar uma internação Médico Gestor, Médico Encerrar uma internação Atendente Cancelar um agendamento de internação Atendente Efetuar login no sistema Gerar estatísticas de ocupação dos leitos Atendente, Médico, Gestor Gestor 1.3 Requisitos comportamentais ou de performance Para que o SISCONI possa atender de forma eficiente aos seus usuários, o sistema deve:
  6. 6. 1. Ser fácil de usar, possuindo uma linguagem de acordo com o ambiente do negócio. 2. Ser capaz de estar funcionando a todo momento (próximo às 24 horas do dia). 3. Todos os possíveis usuários do SISCONI deverão ter acesso restrito às funcionalidades que lhe são cabíveis, mediante um código de acesso e uma senha. 4. As informações disponibilizadas pelo SISCONI deverão ser íntegras e passíveis de auditoria. 1.4 Gestão e Restrições Técnicas As restrições técnicas que definem o escopo do SISCONI são: 1. O Sistema de Gerenciamento de Banco de Dados utilizado pelo SISCONI será o MySQL. 2. A linguagem de programação a ser utilizada será a JAVA. 3. Todas as máquinas do Hospital Universitário devem possuir um browser web para o acesso ao SISCONI. 4. O funcionamento do SISCONI depende de uma infraestrutura de rede intranet entre os diversos computadores que o utilizarão. 2. ESTIMATIVAS DO PROJETO Serão descritas nesta seção, as etapas utilizadas para calcular o tempo total de execução deste projeto. Para isso, a métrica de Lorens&Kidd será aplicada para estimar esse tempo. 2.1 Dados históricos utilizados para as estimações
  7. 7. Este é o primeiro projeto desenvolvido pela equipe, não existindo assim, dados históricos para balizar as estimativas dos cálculos. 2.2 Técnicas de estimação e resultados Como descrito anteriormente, neste projeto será utilizada a métrica de Lorens&Kidd para o cálculo do tempo de execução do projeto. Esta técnica leva em consideração as classes que serão construídas no projeto. Assim, as seguinte etapas serão utilizadas para essa estimação: 1. Com base no diagrama de classes de domínio, determina-se as classes-chave do projeto. 2. Classifica-se o tipo de interface do produto e desenvolve-se um multiplicador para encontrar o número de classes de suporte. Para isso, são usadas as informações contidas na Tabela 1. Interface Multiplicador Interface não gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI complexa 3 Tabela 1 - Interface x Multiplicador. 3. Calcula-se o produto entre o número de classes-chave pelo multiplicador selecionado na etapa anterior, encontrando assim o número de classes de suporte. 4. Calcula-se o total de classes do projeto (classes-chave + classes de suporte) 5. Determina-se os dias por pessoa necessários para construção de uma única classe.
  8. 8. 6. Multiplica-se a quantidade total de classes (chave mais suporte) pelo fator encontrado na etapa anterior, encontrando assim a quantidade que uma pessoa levaria para a desenvolvimento do projeto, ou seja, o esforço estimado. 7. Por fim, calcula-se o tempo necessário (previsto) para o desenvolvimento do projeto. 2.3 Resultados Através da aplicação da técnica de Lorenz &Kidd, os seguintes cálculos e resultados foram obtidos: 1. Após a análise do diagrama de classes de domínio, o número de classes-chave encontrado foi de 8 classes. 2. Devido a sua natureza, a interface do sistema foi considerada apenas como GUI, recebendo como multiplicador o valor 2,5. 3. Foi determinado o número de classes de suporte, tendo como base o multiplicador escolhido na etapa anterior. Assim, multiplicando 8 x 2,5 obteve-se um total de 20 classes de suporte. 4. O número de total de classes (chave + suporte) é de 28 classes. 5. Como não há registros históricos anteriores, usa-se como base a sugestão da técnica de Lorenz &Kidd (15 a 20 dias/pessoa). Assim, determinou-se 15 dias/pessoa para o desenvolvimento de uma única classe. 6. Tendo como parâmetro 15 dias/pessoa para o desenvolvimento de uma classe, calcula-se 15 x 28, totalizando-se 420 dias/pessoa para a consecução do sistema. 7. Tendo a vista que o projeto é composto por 4 (quatro) integrantes, chega-se ao total de 105 dias para o desenvolvimento do projeto. Considerando as porcentagens de distribuição de componentes essenciais no projeto, sugeridas pelas diretrizes da Lacertae Software, os 105 dias estimados para o desenvolvimento do projeto são distribuídos nas respectivas fases do projeto:
  9. 9. Fase Estimativa Dias de Trabalho Planejamento 3% 105 x 3% = 3 dias Análise e Projeto 20% 105 x 20% = 21 dias Geração de Código 40% 105 x 40% = 42 dias Testes 37% 105 x 37% = 39 dias Tabela 2–Estimativa dos dias de trabalho por fase do projeto. 2.4 Recursos do projeto Os recursos utilizados no projeto serão explanados nas sessões abaixo. Eles se subdividem em Recursos Humanos, Recursos de Software e Recursos de Hardware. 2.4.1 Recursos Humanos Com o objetivo de manter o bom relacionamento e interatividade da equipe, será utilizada a Scrum como metodologia ágil de gerenciamento do projeto. Além disso será utilizada a XP como metodologia ágil de desenvolvimento que tem como característica principal a programação em pares. Com o objetivo de envolver todos os integrantes em todas as áreas da construção do software, o cronograma será dividido em quatro fases, onde todos passarão por todos os papéis, como segue abaixo. Sprint 1 Período: 13/01/2014 à 07/02/2014 Scrum Master Washington Silva Developer 1 Rodrigo Calheiros Developer 2 Felipe Carvalho Tester Ramon Ramos
  10. 10. Sprint 2 Período: 10/02/2014 à 07/03/2014 Scrum Master Ramon Ramos Developer 1 Washington Silva Developer 2 Rodrigo Calheiros Tester Felipe Carvalho Sprint 3 Período: 10/03/2014 à 04/04/2014 Scrum Master Felipe Carvalho Developer 1 Ramon Ramos Developer 2 Washington Silva Tester Rodrigo Calheiros Sprint 4 Período: 07/04/2014 à 25/04/2014 Scrum Master Rodrigo Calheiros Developer 1 Felipe Carvalho Developer 2 Ramon Ramos Tester Washington Silva
  11. 11. 2.4.2 Recursos de Software Para a construção do software serão utilizados alguns outros softwares que auxiliarão no processo de desenvolvimento. Dentro de um conjunto de softwares estão contidos editor de texto, servidor HTTP, máquina virtual, IDE de Desenvolvimento, entre outros. Apache Tomcat 7.0 - Servidor HTTP produzido pela Apache e distribuído como software livre. Java - Linguagem de programação utilizada no desenvolvimento do projeto. JRE - Máquina virtual Java. Eclipse Java EE IDE Kepler - IDE de codificação do software. Astah - Ambiente de modelagem dos diagramas UML. Microsoft Office Word –Editor de texto para a documentação do software. Open Project - Ambiente de gerenciamento e criação de cronogramas a serem executados durante o processo de desenvolvimento do software. Google Drive - Software de armazenamento em nuvem. GIT- Sistema livre de controle de versão. GitHub - Armazenamento em nuvem do controle de versão implementado pelo GIT. 2.4.3 Recursos de Hardware
  12. 12. Com o objetivo de centralizar os artefatos gerados no processo de desenvolvimento do software serão utilizados os serviços disponíveis na nuvem como Google Drive para o armazenamento da documentação do software, como também os diagramas gerados ao decorrer do desenvolvimento. O controle de versão será apoiado peloGitHub. Sendo assim, os computadores pessoais de cada membro da equipe seriam os únicos hardwares diretos necessários. 3. ANÁLISE E GESTÃO DE RISCOS Um risco é um problema em potencial, ou seja, um problema com certa probabilidade de acontecer que pode afetar de diversas formas o andamento do projeto. Todo projeto está sujeito a determinados riscos. Cada risco tem um percentual de chance de acontecer (sendo uns com maior e outros com menor possibilidade de ocorrência), e um determinado impacto sobre o projeto. É preciso conhecê-los e determinar as formas de minimizar a probabilidade de sua ocorrência, bem como o seu impacto, caso ele venha a acontecer. 3.1 Riscos do projeto Os riscos de um projeto podem ser distinguidos em gerais (comuns a todo projeto) e específicos (únicos de cada projeto). Os riscos gerais, comuns a qualquer projeto são listados abaixo: Risco Projeto Equipamento não disponível Requisitos incompletos Técnico Negócio Comum Especial X X X Uso de metodologias especiais X X Problemas na busca da confiabilidade requerida X X
  13. 13. Retenção de pessoas chaves X X Subestimativas do esforço X X Tabela 3–Riscos gerais de um projeto de software. Avaliação global dos riscos: 1. O Gestor de Software dá suporte ao projeto? Sim. O gestor de software tem um papel importante para o bom andamento do projeto, e seu apoio tem sido fundamental durante a consecução do trabalho. 2. Os Clientes estão entusiasmados com o projeto e o produto? O cliente está muito interessado no produto pois a ferramenta automatizará o atual processo de controle dos leitos, o que evitará os frequentes erros incorridos pelo processo manual de trabalho. 3. Os Engenheiros de Software compreenderam bem os requisitos? Sim, os engenheiros compreendem bem os requisitos do projeto, pois estão participando desde o início do trabalho. 4. Os Clientes estiveram envolvidos na definição dos requisitos? Sim. Devido ao grande interesse no sistema, eles estiveram evolvidos durante a definição dos requisitos. 5. O âmbito do projeto é estável? Sim. 6. Os engenheiros de Software têm as competências requeridas? Apesar de pouco experientes, os Engenheiros de Software tem como principal objetivo a busca por novas experiências e, consequentemente, o aumento de suas competências.
  14. 14. 7. Os requisitos do projeto são estáveis? Os requisitos foram bem definidos no início do trabalho, porém algumas alterações foram solicitadas para melhor desenvolvimento do produto. A metodologia utilizada para o desenvolvimento do software visa lidar com essas mudanças de maneira que não impacte tanto no desenvolvimento do trabalho. 8. A Equipe de Desenvolvimento tem experiência na tecnologia a implementar? Não, poucos membros da equipe tem um boa experiência técnica profissional, já a maioria tem apenas experiência em desenvolvimento de trabalhos acadêmicos. 9. É adequado o número de pessoas da equipe de trabalho? Não. Apesar de o sistema não ser tão grande, é necessária a presença de mais uma pessoa na equipe, desde que esta seja experiente, devido à falta de experiência da equipe atual. 3.2 Tabela de riscos Para o desenvolvimento do software, alguns riscos foram identificados e classificados quanto a sua probabilidade e seu impacto no projeto. A tabela abaixo demostra os riscos com seus valores associados. Nome do risco Probabilidade Impacto Desistência do cliente 10% Catastrófico Poucos programadores no 80% Crítico Requisitos mal compreendidos 60% Crítico Ausência de inspeções no processo de 50% Crítico desenvolvimento
  15. 15. software. Custos associados a um Produto 30% Crítico 80% Moderado 50% Moderado Atraso na entrega 50% Moderado Disponibilidade do cliente para o 30% Moderado 20% Moderado Grande número de classes 20% Moderado Restrições governamentais 30% Marginal Grande volume de dados 25% Marginal Manutenção associada às tecnologias e 20% Marginal Grande número de usuários 15% Marginal Ausência de integração das 50% Desprezível defeituoso Ausência de ferramentas CASE adequadas para testes de software Dedicação integral dos desenvolvedores ao projeto desenvolvimento Falta de treinamento da equipe nas ferramentas de desenvolvimento ferramentas livres ferramentas de desenvolvimento Tabela 4–Tabela de riscos específicos. 3.3 Redução e Gestão do Risco
  16. 16. Visando garantir a redução da probabilidade dos riscos identificados na seção anterior, bem como seu impacto em caso de ocorrência, abaixo serão descritas as formas de redução bem como o plano de contingência necessário em caso de ocorrência. 1. Desistência do Cliente Probabilidade: 10% Impacto: Catastrófico Descrição: Insatisfação do cliente com o andamento do projeto, ou desinteresse pode levá-lo a desistir do projeto. Estratégia de redução: Envolvê-lo em todas as fases do projeto, para que ele se sinta parte importante no processo de desenvolvimento, mostrando sempre a evolução do software. Plano de contingência: Durante o desenvolvimento do projeto, demonstrar a possíveis novos clientes as funcionalidades do sistema e como ele poderia ser importante em suas empresas. Responsável: Washington Silva Status: Iniciado 2. Poucos programadores no desenvolvimento Probabilidade: 80% Impacto: Crítico Descrição: O número de programadores no desenvolvimento do projeto deste software é pequeno. Estratégia de redução: Melhorar a produtividade dos programadores através de incentivos financeiros e pessoais ou contratar mais alguns
  17. 17. programadores. Plano de contingência: Fazer com que os programadores alocados para o projeto tenham bastante produtividade, dadas às limitações existentes. Responsável: Felipe Carvalho Status: Iniciado 3. Requisitos mal compreendidos Probabilidade: 60% Impacto: Crítico Descrição: Diferentes stakeholderstêm em mente diferentes requisitos e podem expressá-los de maneiras distintas. Estratégia de redução: Combinar o uso das mais diversas técnicas de elicitação no processo de descoberta dos requisitos do stakeholders. Plano de contingência: Analisar os artefatos oriundos da elicitação dos requisitos com os stakeholderse encontrar os pontos comuns e os pontos conflitantes. Responsável: Ramon Ramos Status: Em andamento 4. Ausência de inspeções no processo de software Probabilidade: 50% Impacto: Crítico Descrição: A inspeção de software pode não ser executada, geralmente, devido a atrasos no cronograma.
  18. 18. Estratégia de redução: Não pular etapas do processo de software estabelecido na Organização. O processo de software deve ser seguido. Plano de contingência: Intensificar os testes de sistema. Responsável: Ramon Ramos Status: Em andamento 5. Custos associados a um produto defeituoso Probabilidade: 30% Impacto: Crítico Descrição: Qualquer software possui erros. Com isso, as correções deles são custosas a depender de quando são encontrados. Além disso eles podem gerar grandes prejuízos a instituição usuária do software. Estratégia de redução: Enfatizar a fase de teste no processo de desenvolvimento de software. A equipe de teste deve testar exaustivamente o software sempre procurando pelos erros. Plano de contingência: Focar a equipe desenvolvedora do software na resolução do erro. Responsável: Rodrigo Calheiros Status: Em andamento 6. Ausência de ferramentas CASE adequadas para testes de software Probabilidade: 80% Impacto: Moderado Descrição: O processo de gerar testes automatizados auxilia na produção
  19. 19. de um software com mais qualidade. Neste contexto, a ausência de ferramentas CASE que dão suporte à essa atividade obriga a execução de testes manuais exaustivos. Estratégia de redução: Ter um enfoque na fase de testes, elaborando casos de teste que abranjam as possíveis entradas e combinações de entradas do software. Plano de contingência: Terceirizar o processo de testes do software. Responsável: Felipe Carvalho Status: Em andamento 7. Dedicação integral dos desenvolvedores ao projeto Probabilidade: 50% Impacto: Moderado Descrição: A maioria dos integrantes não tem como se dedicar exclusivamente para o projeto, principalmente por questões de compatibilidade de horário com outros afazeres. Estratégia de redução: Tentar adequar o trabalho de cada um com o seu tempo disponível, sem que isto afete seu tempo de lazer. As atribuições de cada membro serão dividas de forma a não onerar o seu tempo de disponibilidade nem atrasar o andamento do projeto. Plano de contingência: Incentivar os integrantes da equipe para que eles usem um pouco do seu tempo de lazer disponível, em momentos de grande necessidade, para consecução do trabalho. Responsável: Washington Silva Status: Em andamento
  20. 20. 8. Atraso na entrega Probabilidade: 50% Impacto: Moderado Descrição: É comum o atraso na entrega do software. Entretanto é algo que não deve acontecer. Esse é um risco que pode levar a descredibilidade da empresa desenvolvedora além de caracterizar uma quebra de contrato. Estratégia de redução: Planejar o desenvolvimento do software levando em conta todas as possíveis eventualidades, além de estimar o tempo do desenvolvimento com um acréscimo. Com esse planejamento a equipe deve seguir o cronograma e assim cumprir as atividades no tempo correto. Plano de contingência: Focar equipe no projeto sem dispersar com outras atividades. Responsável: Rodrigo Calheiros Status: Iniciado 4. PLANEJAMENTO TEMPORAL Nesta seção, são definidas as datas de execução das tarefas, bem como seus responsáveis. Para descrever esse aspecto temporal, foi elaborado o Diagrama de Gantt. 4.1 Conjunto de Tarefas do Projeto O modelo de ciclo de vida usado foi o modelo iterativo incremental. Assim, as atividades de planejamento, levantamento de requisitos, análise, projeto, codificação e testes são executadas continuamente durante todo o ciclo de vida de desenvolvimento do software.
  21. 21. 4.2 Diagrama de Gantt O cronograma extraído do diagrama de gantt encontra-se abaixo:
  22. 22. Uma visão mais detalhada do diagrama de gantt pode ser vista no blog da equipe FRRW Gerência: http://frrw-gerencia.blogspot.com.br/2014/01/diagrama-degantt-do-sisconi.html 5. ORGANIZAÇÃO DO PESSOAL Apesar da existência do gestor do projeto, toda decisão a respeito do trabalho é compartilhada com todos os envolvidos. Além disso, a equipe foi estruturada, ou seja, dividida em papeis para melhor condução do projeto. 5.1 Estrutura da equipe O projeto será desenvolvido através de um modelo iterativo e incremental, uma vez que certas funcionalidades do sistema dependem do correto funcionamento de outras. Dessa forma, foi preciso definir os papéis envolvidos no projeto, bem como o perfil necessário para o seu desempenho. Assim, os seguinte papeis e critérios foram especificados: Gerente de Projetos Será o responsável pela alocação de recursos, ajuste de prioridades, coordenação das interações entre clientes e usuários, e manter o foco da equipe na meta. O gerente de projeto também estabelece um conjunto de práticas que garantem a integridade e a qualidade dos artefatos do projeto. Para esse papel, são de grande valia habilidades como experiência anterior em gerência de projetos, experiência em análise, gerenciamento de riscos, estimativas, planejamento e análise de decisões. Saber se apresentar e se comunicar de forma clara, ter a capacidade de liderança, bom relacionamento interpessoal e boa capacidade de gerenciamento de tempo também foram verificados. Arquiteto de Software
  23. 23. Este papel tem como objetivo liderar e coordenar as atividades e os artefatos técnicos no decorrer do projeto. Além disso, o arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Para esse papel, contam as habilidades como grande conhecimento geral, maturidade, visão e profunda experiência que permita identificar problemas rapidamente. Analista de Sistemas Terá a responsabilidade de liderar e coordenar a equipe na identificação de requisitos e na modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade. Como critério para escolha do integrante para este papel, qualidades como bom conhecimento do negócio e facilidade de comunicação foram observadas. Analista de Teste Será o responsável por identificar e definir os testes necessários, monitorar a abrangência dos testes e avaliar a qualidade obtida ao realizar os testes. Além disso, será responsável por desenvolver e testar componentes de acordo com os padrões adotados para o projeto, para fins de integração com subsistemas maiores. Para esse papel, foram observados as seguintes habilidades: boa habilidade analítica, atenção aos detalhes e tenacidade, entendimento de falhas de software comuns, conhecimento do domínio, conhecimento do sistema ou aplicativo em teste e experiência em vários esforços de teste. Com base nos papéis e habilidades descritas anteriormente, a alocação da equipe se dará da seguinte forma: Papel Gerente de Projetos Integrante Washington Silva
  24. 24. Analista de Sistemas Felipe Carvalho Arquiteto de Software Rodrigo Calheiros Analista de Testes Ramon Ramos 5.2 Mecanismos de comunicação Para a efetiva comunicação entre os participantes da equipe, diversas ferramentas foram abordadas. Dentre elas, é possível destacar: ● O e-mail foi a ferramenta mais utilizada, principalmente por sua onipresença entre os participantes. ● Ferramentas de colaboração como o Google Drive que permitiu a confecção dos diversos documentos de trabalho, bem como a comunicação instantânea entre os participantes por meio de chat. ● Reuniões presenciais também serviram para tratar dúvidas e problemas relacionados com o projeto. 5.3 Uso do Edu-blog como ferramenta de apoio É uma ferramenta bastante simples e de acesso facilitado, que apoia a colaboração entre pessoas como fonte de disseminação de conhecimentos. A utilização do blog durante do desenvolvimento desse trabalho foi importante para o seu bom andamento. Um importante papel do blog foi compartilhar os conhecimentos por nós elencados, bem como obter informações de outras equipes que serviram como base para a edição deste documento. 6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE
  25. 25. A fim de assegurar a qualidade do software, algumas atividades foram desenvolvidas durante o projeto, sendo elas: Testes: Os testes de software foram elaborados e colocados em prática durante todo o ciclo de desenvolvimento do projeto. A contínua aplicação de testes permite que os defeitos sejam descobertos o mais cedo possível, causando assim um menor impacto nos custos de modificações do software. Isso se dá pelo fato de que quanto mais cedo um defeito é descoberto, mais fácil é de se consertá-lo. Seguimento e desenvolvidas controle durante do projeto todo o de software: ciclo de As atividades desenvolvimento são acompanhadas constantemente e todos os requisitos são validados com os clientes. Produção de documentação: Todas as informações obtidas nas etapas do desenvolvimento foram compiladas e documentadas. A produção de documentação fornece um parâmetro para avaliar o que foi feito na prática em comparação que foi descrito. Programação Pareada: É uma das técnicas de metodologias de desenvolvimento ágil como o XP. Através da programação pareada, um desenvolvedor escreve o código enquanto o outro analisa. Isso permite que o observador encontre erros que não foram percebidos por quem está escrevendo o código. Os papeis são trocados com frequência visando uma melhor produtividade.
  26. 26. 7. ANEXOS Figura 1.1 – Diagrama de Classes de domínio do SISCONI
  27. 27. Figura 1.2 – Diagrama lógico do banco de dados do SISCONI

×