O documento descreve um plano de projeto de software para o Sistema de Controle de Internação (SISCONI) de um hospital universitário. O projeto estima 105 dias para desenvolvimento do software, distribuídos em 4 fases. A equipe é composta por 4 membros que irão rotacionar entre os papéis de Scrum Master, desenvolvedor e testador ao longo de 4 sprints.
O documento apresenta o plano de projeto para o desenvolvimento de um sistema de processos de enfermagem (SISPE) na Universidade Federal de Sergipe. O projeto utilizará a metodologia ágil Scrum e estima que levará 9,5 meses para ser concluído por uma equipe de 4 pessoas. O sistema terá funcionalidades como manutenção de dados do paciente, mapeamento de necessidades e prescrições, e geração de relatórios.
Este documento apresenta o plano de projeto de software para a Laceratae SW, incluindo: (1) o escopo do projeto para o sistema SISCONI, (2) estimativas de tempo e recursos para o projeto, e (3) análise e gestão de riscos.
Este documento apresenta o plano de projeto para o desenvolvimento de um software de gerenciamento de acervo de arte para a empresa Lacerdae SW. O projeto será desenvolvido por uma equipe de 4 estudantes e tem como objetivo construir um sistema web para controlar informações sobre obras de arte, como cadastro, edição e visualização. O documento inclui estimativas de esforço, análise de riscos, cronograma e planos para garantir a qualidade do software.
Este documento apresenta o plano de projeto de um sistema de gerenciamento de acervo de arte chamado ControlArt. O projeto será desenvolvido por uma equipe de 4 estudantes de sistemas de informação utilizando metodologia ágil. O documento descreve o escopo, estimativas de tempo e recursos, análise de riscos e planejamento do projeto.
O documento apresenta o plano de projeto de um software educacional chamado Diagnosticus Action. Ele descreve as funcionalidades do software, requisitos, estimativas de projeto, recursos, análise de riscos e organização da equipe. O software simula casos médicos para treinar estudantes sem colocar pacientes em risco. O projeto está estimado em 9 meses com uma equipe de 4 pessoas.
Plano de Projeto - Gerencia de ProjetosHelder Filho
O documento apresenta o plano de projeto de um software educacional para simulação de casos médicos chamado Diagnosticus Action. Ele descreve as funcionalidades do software, estimativas de tempo e custo do projeto, análise de riscos e plano de gerenciamento da qualidade.
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWMatheus Costa
1. O documento apresenta o plano de projeto de software para o módulo Diploma de uma universidade, descrevendo suas principais funções e requisitos.
2. As estimativas indicam que o projeto terá 4 classes-chave, 10 classes de suporte, demandando cerca de 93 dias para uma equipe de 3 pessoas.
3. O plano descreve também a análise de riscos, cronograma, organização da equipe e controles de qualidade.
O documento apresenta o plano de projeto de um sistema de gerenciamento de instrumentos para uma prefeitura, descrevendo suas principais funcionalidades, estimativas de esforço, riscos e plano de gerenciamento.
O documento apresenta o plano de projeto para o desenvolvimento de um sistema de processos de enfermagem (SISPE) na Universidade Federal de Sergipe. O projeto utilizará a metodologia ágil Scrum e estima que levará 9,5 meses para ser concluído por uma equipe de 4 pessoas. O sistema terá funcionalidades como manutenção de dados do paciente, mapeamento de necessidades e prescrições, e geração de relatórios.
Este documento apresenta o plano de projeto de software para a Laceratae SW, incluindo: (1) o escopo do projeto para o sistema SISCONI, (2) estimativas de tempo e recursos para o projeto, e (3) análise e gestão de riscos.
Este documento apresenta o plano de projeto para o desenvolvimento de um software de gerenciamento de acervo de arte para a empresa Lacerdae SW. O projeto será desenvolvido por uma equipe de 4 estudantes e tem como objetivo construir um sistema web para controlar informações sobre obras de arte, como cadastro, edição e visualização. O documento inclui estimativas de esforço, análise de riscos, cronograma e planos para garantir a qualidade do software.
Este documento apresenta o plano de projeto de um sistema de gerenciamento de acervo de arte chamado ControlArt. O projeto será desenvolvido por uma equipe de 4 estudantes de sistemas de informação utilizando metodologia ágil. O documento descreve o escopo, estimativas de tempo e recursos, análise de riscos e planejamento do projeto.
O documento apresenta o plano de projeto de um software educacional chamado Diagnosticus Action. Ele descreve as funcionalidades do software, requisitos, estimativas de projeto, recursos, análise de riscos e organização da equipe. O software simula casos médicos para treinar estudantes sem colocar pacientes em risco. O projeto está estimado em 9 meses com uma equipe de 4 pessoas.
Plano de Projeto - Gerencia de ProjetosHelder Filho
O documento apresenta o plano de projeto de um software educacional para simulação de casos médicos chamado Diagnosticus Action. Ele descreve as funcionalidades do software, estimativas de tempo e custo do projeto, análise de riscos e plano de gerenciamento da qualidade.
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWMatheus Costa
1. O documento apresenta o plano de projeto de software para o módulo Diploma de uma universidade, descrevendo suas principais funções e requisitos.
2. As estimativas indicam que o projeto terá 4 classes-chave, 10 classes de suporte, demandando cerca de 93 dias para uma equipe de 3 pessoas.
3. O plano descreve também a análise de riscos, cronograma, organização da equipe e controles de qualidade.
O documento apresenta o plano de projeto de um sistema de gerenciamento de instrumentos para uma prefeitura, descrevendo suas principais funcionalidades, estimativas de esforço, riscos e plano de gerenciamento.
1. O documento descreve um plano de projeto de software para um sistema de gerenciamento de atividades administrativas de um Centro de Formação de Condutores. 2. As principais funções do sistema incluem cadastro de instrutores, alunos, veículos e aulas, além de relatórios gerenciais. 3. Estimativas de prazo, custo e esforço serão realizadas usando a métrica de Lorenz & Kidd.
1. O documento apresenta uma comparação entre o Rational Unified Process (RUP) e o Project Management Body of Knowledge (PMBOK);
2. Descreve as principais características e componentes de cada um, como fases, disciplinas, áreas de conhecimento;
3. Discutem como o PMBOK fornece parâmetros de gerenciamento de projetos enquanto o RUP auxilia na implementação dessas práticas para projetos de software.
Este documento apresenta o plano de projeto de um sistema de gerenciamento de serviços (SGS) para a Universidade Federal do Amazonas (UFAM). O SGS visa melhorar o controle e acompanhamento de requisições de serviços, permitindo o cadastro eletrônico de requisições, o acompanhamento online do status das atividades solicitadas e a emissão de relatórios. O plano detalha a estimativa de esforço e prazo do projeto utilizando a técnica de Lorenz & Kidd, identifica os principais riscos e define
Este documento apresenta o plano de projeto para o desenvolvimento de um sistema chamado e-Litter, que irá auxiliar na manutenção de dados de coletas de materiais orgânicos realizadas em pesquisas de biologia. O documento descreve o escopo do projeto, suas principais funções, requisitos, estimativas de tempo e custo utilizando a técnica de Lorenz & Kidd, recursos envolvidos e uma análise de riscos.
Este documento resume o plano de projeto para o desenvolvimento do sistema CAFIS pela equipe da Lacertae Software. O projeto visa desenvolver um sistema para gerenciar as informações sobre edificações da Universidade Federal do Amazonas. O documento descreve o escopo, recursos, riscos, cronograma e equipe do projeto.
Plano de Projeto de Software para produtos da Lacertae SWrafahreis
1. O documento apresenta o plano de projeto de software para produtos da empresa Lacertae SW para o Hospital Universitário da UFS.
2. O software tem como objetivo gerenciar informações sobre ocorrências no hospital de forma a notificar os setores envolvidos.
3. Foram estimados 315 dias-pessoa de trabalho utilizando a técnica de Lorenz & Kidd com base no diagrama de classes do sistema.
1) O documento apresenta instruções para a realização de uma prova de múltipla escolha com 60 questões sobre gestão em infraestrutura de TI e analista de finanças e controle.
2) As instruções incluem o preenchimento do cartão de respostas, a duração da prova de 3 horas, a proibição de consulta entre candidatos e o uso de equipamentos eletrônicos.
3) Ao final da prova, o caderno e o cartão de respostas devem ser entregues ao fiscal.
Este documento define o processo de desenvolvimento de software para projetos acadêmicos. Ele adapta o processo RUP, identificando as fases, disciplinas, papéis e artefatos essenciais. O ciclo de vida consiste nas fases de Concepção, Elaboração e parte da Construção. As disciplinas incluem Requisitos, Análise e Projeto, Teste e Gerenciamento de Projeto. Para cada disciplina, o documento descreve o fluxo de trabalho, artefatos e relatórios.
1. O documento apresenta o plano de projeto de software para o Sistema Eletrônico de Informação e Comunicação com o Cidadão (SICC) desenvolvido por estudantes da Universidade Federal de Sergipe.
2. O SICC tem como objetivo facilitar a comunicação entre cidadãos e órgãos governamentais estaduais de acordo com a Lei de Acesso à Informação.
3. O plano detalha o escopo, estimativas de tempo e custo, análise de riscos, cronograma e organização da equipe para o
Este documento apresenta o plano de projeto para o desenvolvimento de um software chamado NutriBR para o Hospital Universitário (HU) de Sergipe. O NutriBR irá gerenciar uma base de dados para acompanhar a dieta de pacientes com problemas cardíacos divididos em dois grupos (grupo prevenção e grupo controle). O documento descreve as estimativas de tempo e recursos para o projeto, análise de riscos, cronograma e organização da equipe.
O documento apresenta o plano de projeto de software para o produto Diagnosticus Action, um jogo de simulações de casos emergenciais em um hospital. Ele descreve as funcionalidades do software, estimativas de tempo e custo do projeto, análise de riscos e plano de gerenciamento. O projeto tem duração estimada de 9 meses e envolve 4 membros da equipe. Riscos importantes incluem mudanças nos requisitos, qualidade do código e atrasos no cronograma.
O documento descreve o plano de projeto para o desenvolvimento de um sistema de painel de estoque para um hospital universitário utilizando Java. Ele inclui estimativas de esforço, análise de riscos, planejamento de tarefas e qualidade, além de detalhar os requisitos funcionais e não funcionais do sistema. A equipe estima que o projeto pode ser concluído em 48 dias.
Este documento apresenta o plano de projeto de software para o desenvolvimento de um sistema integrado de gerenciamento de atividades administrativas de um centro de formação de condutores. O plano descreve as principais funcionalidades do sistema, estimativas de esforço, análise e gestão de riscos, cronograma, equipe e medidas de qualidade. O projeto visa melhorar a gestão dos centros de formação através de ferramentas e indicadores que auxiliem na tomada de decisões.
Plano do projeto de software SIGEM - Sistema de gestão de materiaisMarcos Pessoa
Este documento apresenta o plano de projeto de software para produtos da Lacertae SW. Ele descreve o escopo, funcionalidades, requisitos, estimativas, riscos, cronograma e controles de qualidade do projeto de desenvolvimento de um sistema de gestão de materiais para uma universidade.
Plano de Projeto de Software do Residents Controlazarael2607
O documento apresenta o plano de projeto de software para o sistema Residents Control, desenvolvido para o condomínio Sergipe Del Rey. O sistema tem como objetivo controlar a entrada e saída de visitantes e funcionários, além de manter cadastros de moradores, visitantes e visitas. O projeto foi estimado em aproximadamente 3 meses para uma equipe de 4 pessoas, utilizando a metodologia Scrum e ferramentas como Delphi e SVN.
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Urique Hoffmann
Este documento apresenta o plano de projeto de software para o desenvolvimento de um sistema chamado PIC Eletrônico na Universidade Federal do Amazonas. O sistema tem como objetivo dar suporte ao Plano Institucional de Capacitação da universidade e abrangerá três das quatro etapas do processo de PIC. O documento descreve o escopo do projeto, os requisitos, as restrições técnicas, a estimativa de tempo de desenvolvimento utilizando a métrica de Lorenz & Kidd, e os recursos humanos, de software e hardware necessários.
1. O documento apresenta o plano de projeto para o desenvolvimento de um sistema de controle de estágio.
2. É descrito o escopo do projeto, as estimativas de tempo e custo, análise de riscos, planejamento e a equipe envolvida.
3. O projeto tem previsão de conclusão entre 4,5 a 5 meses e envolve o desenvolvimento de um sistema web para gestão de estágios de estudantes.
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. O documento descreve um projeto de software para gerenciar atividades de extensão na UFS. 2. Inclui estimativas de prazo, custo e recursos para o projeto, além de análise de riscos. 3. O principal risco identificado é a insuficiência de pessoas na equipe, enquanto a perda de dados na integração dos sistemas UFS-UFRN pode ter impacto catastrófico.
O documento apresenta o projeto de desenvolvimento de um aplicativo móvel para enviar lembretes de devolução de livros emprestados de bibliotecas. O projeto inclui o desenvolvimento da arquitetura do sistema, modelagem de classes, diagramas, e cronograma com as atividades e responsáveis. O aplicativo receberá dados de empréstimos por meio de arquivos XML e enviará notificações baseado na data de devolução.
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWLays Lopes
Este documento apresenta o plano de projeto de software para o sistema Bariatric Dashboard System, desenvolvido para o gerenciamento de cirurgias bariátricas em um hospital universitário. O plano descreve as principais funções do sistema, como manutenção de pacientes, usuários, profissionais de saúde e especialidades médicas. Também apresenta estimativas de tempo e custo usando a técnica de Lorenz e Kidd, além de análises de riscos, cronograma e estrutura da equipe.
1. O documento descreve um plano de projeto de software para um sistema de gerenciamento de atividades administrativas de um Centro de Formação de Condutores. 2. As principais funções do sistema incluem cadastro de instrutores, alunos, veículos e aulas, além de relatórios gerenciais. 3. Estimativas de prazo, custo e esforço serão realizadas usando a métrica de Lorenz & Kidd.
1. O documento apresenta uma comparação entre o Rational Unified Process (RUP) e o Project Management Body of Knowledge (PMBOK);
2. Descreve as principais características e componentes de cada um, como fases, disciplinas, áreas de conhecimento;
3. Discutem como o PMBOK fornece parâmetros de gerenciamento de projetos enquanto o RUP auxilia na implementação dessas práticas para projetos de software.
Este documento apresenta o plano de projeto de um sistema de gerenciamento de serviços (SGS) para a Universidade Federal do Amazonas (UFAM). O SGS visa melhorar o controle e acompanhamento de requisições de serviços, permitindo o cadastro eletrônico de requisições, o acompanhamento online do status das atividades solicitadas e a emissão de relatórios. O plano detalha a estimativa de esforço e prazo do projeto utilizando a técnica de Lorenz & Kidd, identifica os principais riscos e define
Este documento apresenta o plano de projeto para o desenvolvimento de um sistema chamado e-Litter, que irá auxiliar na manutenção de dados de coletas de materiais orgânicos realizadas em pesquisas de biologia. O documento descreve o escopo do projeto, suas principais funções, requisitos, estimativas de tempo e custo utilizando a técnica de Lorenz & Kidd, recursos envolvidos e uma análise de riscos.
Este documento resume o plano de projeto para o desenvolvimento do sistema CAFIS pela equipe da Lacertae Software. O projeto visa desenvolver um sistema para gerenciar as informações sobre edificações da Universidade Federal do Amazonas. O documento descreve o escopo, recursos, riscos, cronograma e equipe do projeto.
Plano de Projeto de Software para produtos da Lacertae SWrafahreis
1. O documento apresenta o plano de projeto de software para produtos da empresa Lacertae SW para o Hospital Universitário da UFS.
2. O software tem como objetivo gerenciar informações sobre ocorrências no hospital de forma a notificar os setores envolvidos.
3. Foram estimados 315 dias-pessoa de trabalho utilizando a técnica de Lorenz & Kidd com base no diagrama de classes do sistema.
1) O documento apresenta instruções para a realização de uma prova de múltipla escolha com 60 questões sobre gestão em infraestrutura de TI e analista de finanças e controle.
2) As instruções incluem o preenchimento do cartão de respostas, a duração da prova de 3 horas, a proibição de consulta entre candidatos e o uso de equipamentos eletrônicos.
3) Ao final da prova, o caderno e o cartão de respostas devem ser entregues ao fiscal.
Este documento define o processo de desenvolvimento de software para projetos acadêmicos. Ele adapta o processo RUP, identificando as fases, disciplinas, papéis e artefatos essenciais. O ciclo de vida consiste nas fases de Concepção, Elaboração e parte da Construção. As disciplinas incluem Requisitos, Análise e Projeto, Teste e Gerenciamento de Projeto. Para cada disciplina, o documento descreve o fluxo de trabalho, artefatos e relatórios.
1. O documento apresenta o plano de projeto de software para o Sistema Eletrônico de Informação e Comunicação com o Cidadão (SICC) desenvolvido por estudantes da Universidade Federal de Sergipe.
2. O SICC tem como objetivo facilitar a comunicação entre cidadãos e órgãos governamentais estaduais de acordo com a Lei de Acesso à Informação.
3. O plano detalha o escopo, estimativas de tempo e custo, análise de riscos, cronograma e organização da equipe para o
Este documento apresenta o plano de projeto para o desenvolvimento de um software chamado NutriBR para o Hospital Universitário (HU) de Sergipe. O NutriBR irá gerenciar uma base de dados para acompanhar a dieta de pacientes com problemas cardíacos divididos em dois grupos (grupo prevenção e grupo controle). O documento descreve as estimativas de tempo e recursos para o projeto, análise de riscos, cronograma e organização da equipe.
O documento apresenta o plano de projeto de software para o produto Diagnosticus Action, um jogo de simulações de casos emergenciais em um hospital. Ele descreve as funcionalidades do software, estimativas de tempo e custo do projeto, análise de riscos e plano de gerenciamento. O projeto tem duração estimada de 9 meses e envolve 4 membros da equipe. Riscos importantes incluem mudanças nos requisitos, qualidade do código e atrasos no cronograma.
O documento descreve o plano de projeto para o desenvolvimento de um sistema de painel de estoque para um hospital universitário utilizando Java. Ele inclui estimativas de esforço, análise de riscos, planejamento de tarefas e qualidade, além de detalhar os requisitos funcionais e não funcionais do sistema. A equipe estima que o projeto pode ser concluído em 48 dias.
Este documento apresenta o plano de projeto de software para o desenvolvimento de um sistema integrado de gerenciamento de atividades administrativas de um centro de formação de condutores. O plano descreve as principais funcionalidades do sistema, estimativas de esforço, análise e gestão de riscos, cronograma, equipe e medidas de qualidade. O projeto visa melhorar a gestão dos centros de formação através de ferramentas e indicadores que auxiliem na tomada de decisões.
Plano do projeto de software SIGEM - Sistema de gestão de materiaisMarcos Pessoa
Este documento apresenta o plano de projeto de software para produtos da Lacertae SW. Ele descreve o escopo, funcionalidades, requisitos, estimativas, riscos, cronograma e controles de qualidade do projeto de desenvolvimento de um sistema de gestão de materiais para uma universidade.
Plano de Projeto de Software do Residents Controlazarael2607
O documento apresenta o plano de projeto de software para o sistema Residents Control, desenvolvido para o condomínio Sergipe Del Rey. O sistema tem como objetivo controlar a entrada e saída de visitantes e funcionários, além de manter cadastros de moradores, visitantes e visitas. O projeto foi estimado em aproximadamente 3 meses para uma equipe de 4 pessoas, utilizando a metodologia Scrum e ferramentas como Delphi e SVN.
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Urique Hoffmann
Este documento apresenta o plano de projeto de software para o desenvolvimento de um sistema chamado PIC Eletrônico na Universidade Federal do Amazonas. O sistema tem como objetivo dar suporte ao Plano Institucional de Capacitação da universidade e abrangerá três das quatro etapas do processo de PIC. O documento descreve o escopo do projeto, os requisitos, as restrições técnicas, a estimativa de tempo de desenvolvimento utilizando a métrica de Lorenz & Kidd, e os recursos humanos, de software e hardware necessários.
1. O documento apresenta o plano de projeto para o desenvolvimento de um sistema de controle de estágio.
2. É descrito o escopo do projeto, as estimativas de tempo e custo, análise de riscos, planejamento e a equipe envolvida.
3. O projeto tem previsão de conclusão entre 4,5 a 5 meses e envolve o desenvolvimento de um sistema web para gestão de estágios de estudantes.
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. O documento descreve um projeto de software para gerenciar atividades de extensão na UFS. 2. Inclui estimativas de prazo, custo e recursos para o projeto, além de análise de riscos. 3. O principal risco identificado é a insuficiência de pessoas na equipe, enquanto a perda de dados na integração dos sistemas UFS-UFRN pode ter impacto catastrófico.
O documento apresenta o projeto de desenvolvimento de um aplicativo móvel para enviar lembretes de devolução de livros emprestados de bibliotecas. O projeto inclui o desenvolvimento da arquitetura do sistema, modelagem de classes, diagramas, e cronograma com as atividades e responsáveis. O aplicativo receberá dados de empréstimos por meio de arquivos XML e enviará notificações baseado na data de devolução.
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWLays Lopes
Este documento apresenta o plano de projeto de software para o sistema Bariatric Dashboard System, desenvolvido para o gerenciamento de cirurgias bariátricas em um hospital universitário. O plano descreve as principais funções do sistema, como manutenção de pacientes, usuários, profissionais de saúde e especialidades médicas. Também apresenta estimativas de tempo e custo usando a técnica de Lorenz e Kidd, além de análises de riscos, cronograma e estrutura da equipe.
Este documento apresenta o plano de projeto de software para uma escola de línguas utilizando a metodologia ágil Scrum. O projeto visa desenvolver um sistema web para gerenciar matrículas, turmas e notas de alunos de forma online. É estimado que o projeto terá 5 classes principais e 12,5 classes de suporte, totalizando 17,5 classes. Considerando 20 dias de trabalho por classe, o esforço total estimado é de 350 dias. O documento também descreve os requisitos funcionais, riscos, cronogramas e estrutura da equipe para
Plano do projeto de software SACC produzido na disciplina de Gerência de projetos, orientado pelo Prof. Dr. Rogério Patrício Chagas Nascimento e desenvolvido pelos integrantes: Carlson Santana Cruz, Danilo Duarte Correia da Costa Reis, Danilo Ferreira Neves e Ícaro da SIlva Torres, no período letívo de 2014.2 para a UFS- Universidade Federal de Sergipe
1. O documento apresenta o plano de projeto de software para o aplicativo Outlay, que tem como objetivo fornecer ferramentas para gerenciamento de finanças pessoais.
2. São descritas as principais funcionalidades do aplicativo, incluindo diagramas de casos de uso e requisitos funcionais e não funcionais.
3. Estimativas iniciais indicam que o projeto pode ser concluído em aproximadamente 4 meses e 18 dias por uma equipe de 5 pessoas.
BIODATA: SOFTWARE WEB PARA GERENCIAMENTO DE COLETA DE DADOS BIOMÉDICOSAdilmar Dantas
Este documento descreve a arquitetura e organização de um software web para gerenciamento e armazenamento de dados biomédicos chamado BIODATA. O software permite o cadastro de usuários, protocolos, equipamentos e estudos, além do upload e armazenamento de arquivos de dados biomédicos como ECG e EEG. Testes demonstraram que o sistema suporta até 50 usuários simultâneos com tempo de resposta adequado e baixo uso de CPU. O software foi desenvolvido para organizar e facilitar o acesso a dados coletados por pesquisadores.
1. O documento apresenta o plano de projeto de software para o Sistema de Gerenciamento de Projetos de Pesquisa (SIGEP) para o Hospital Universitário da Universidade Federal de Sergipe.
2. As principais funcionalidades do SIGEP incluem fazer login, cadastrar pesquisas, validar pesquisas, gerar relatórios e manter cadastros.
3. O projeto foi estimado em 63 dias para ser concluído por uma equipe de 5 pessoas utilizando a técnica de estimativa de Lorenz & Kidd orientada a classes.
Plano de projeto: Bichos do Campus na WebJorge Roberto
1. O documento apresenta o plano de projeto de software para o sistema "Bichos do Campus na Web".
2. O sistema tem o objetivo de melhorar a visibilidade e o processo de adoção de animais disponíveis no campus da Universidade Federal de Sergipe.
3. O plano detalha os requisitos, estimativas de tempo e custo, análise de riscos, planejamento, equipe e controles de qualidade para o desenvolvimento do sistema.
O documento apresenta o Planejamento Estratégico de Tecnologia da Informação e Comunicação (PETIC) da Universidade Federal de Sergipe para o período de 2010 a 2012. O PETIC descreve o contexto atual de TI na universidade, identificando desafios como sistemas desintegrados e falta de políticas formais. Ele também define o cenário desejado, com a adoção de novas ferramentas e melhorias na infraestrutura e gestão de pessoal. O PETIC foi elaborado após análise das cinco áreas de TI da
Documentação e gestão realizada da equipe do sistema de Georreferenciamento de Ocorrências dos órgãos de segurança pública da Prefeitura Municipal da cidade de Poços de Caldas onde me graduei na universidade.
Semelhante a Plano de projeto de software - SISCONI (20)
O Que é Um Ménage à Trois?
A sociedade contemporânea está passando por grandes mudanças comportamentais no âmbito da sexualidade humana, tendo inversão de valores indescritíveis, que assusta as famílias tradicionais instituídas na Palavra de Deus.
Caderno de Resumos XVIII ENPFil UFU, IX EPGFil UFU E VII EPFEM.pdfenpfilosofiaufu
Caderno de Resumos XVIII Encontro de Pesquisa em Filosofia da UFU, IX Encontro de Pós-Graduação em Filosofia da UFU e VII Encontro de Pesquisa em Filosofia no Ensino Médio
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 11, Central Gospel, Os Mortos Em Cristo, 1Tr24, Pr Henrique, EBD NA TV, Revista ano 11, nº 1, Revista Estudo Bíblico Jovens E Adultos, Central Gospel, 2º Trimestre de 2024, Professor, Tema, Os Grandes Temas Do Fim, Comentarista, Pr. Joá Caitano, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Com. Extra Pr. Luiz Henrique, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique
Educação trabalho HQ em sala de aula uma excelente ideia
Plano de projeto de software - SISCONI
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 4.2 Diagrama de Gantt
O cronograma extraído do diagrama de gantt encontra-se abaixo:
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. 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. 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. 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.