Trabalho apresentado ao Prof. Dr. Rogério
Patrício Chagas do Nascimento como nota
para disciplina Gerência de Projetos do curso
de graduação em Sistemas de Informação –
Bacharelado da Universidade Federal de
Sergipe (UFS).
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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 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.
Este documento discute métricas, estimativas e planejamento para projetos de software orientado a objetos. Ele apresenta métricas comuns como número de classes, casos de uso e subsistemas que podem ser usadas para estimar o esforço de desenvolvimento. Também fornece diretrizes como classificar o tipo de interface do produto e multiplicar o número de classes-chave por um fator para estimar classes de suporte.
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
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.
Apresentação Scrum + Gerenciamento de PortfólioPlinio Tulio
Este documento discute a metodologia Scrum e gerenciamento de portfólios. [1] Apresenta as principais características do Scrum como método ágil, incluindo papéis, artefatos e reuniões. [2] Discute a história e conceitos de gerenciamento de portfólios, como alinhar projetos com a estratégia da organização e alocar recursos de forma eficiente. [3] Explica como o gerenciamento de portfólio pode melhorar a execução de projetos e garantir que sejam percebidos os
O documento apresenta as informações sobre o professor Rogério Patrício Chagas do Nascimento, incluindo sua formação acadêmica, áreas de pesquisa e interesse, disciplinas ministradas, parcerias internacionais e experiência.
Este documento discute planejamento temporal e monitoramento de projetos de software. Ele explica como (1) definir cronogramas com tarefas, responsáveis e datas; (2) como planejamento bem-feito leva a entregas bem espaçadas e considera riscos; e (3) como monitorar o progresso comparando planos com resultados reais.
Practice 4 :: Gestão de Projetos de SW OO :: Métricas, Estimação e PlanificaçõesRogerio P C do Nascimento
Este documento discute a gestão de projetos de software orientado a objetos. Ele apresenta métricas comuns usadas para estimar o esforço necessário para desenvolvimento de software, como número de classes, casos de uso e subsistemas. Também descreve o modelo de métricas de Lorenz e Kidd adotado pela Lacertae Software, que usa classes-chave, classes de suporte e multiplicadores para estimar o número de classes e esforço de um projeto.
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.
Este documento discute a gestão da configuração de software, incluindo: 1) O que é gestão da configuração e por que é importante, 2) Os conceitos de elementos da configuração e linhas base, 3) As tarefas e processos envolvidos na gestão da configuração como controle de versões e auditorias.
O documento apresenta uma introdução à gestão de riscos em projetos de software, definindo o que é gestão de riscos, quem a realiza e por que é importante. Também descreve os principais tipos de riscos de software e métodos para identificá-los e estimar seu impacto, como tabelas de riscos.
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 discute métricas e indicadores para processos e projetos de software. Ele explica que métricas são medidas quantitativas que permitem avaliar a eficácia do processo e do projeto ao longo do tempo. Também descreve domínios comuns de métricas como processo, projeto e produto e fornece exemplos de métricas específicas para cada domínio.
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.
Este documento discute planejamento temporal e monitorização de projetos de software. Ele introduz os conceitos-chave de planejamento temporal, incluindo decomposição de tarefas, diagramas de Gantt e tabelas de controle. Além disso, discute a importância da monitorização do progresso do projeto em relação ao cronograma planejado.
Este documento descreve ferramentas CASE (Computer-Aided Software Engineering). Detalha o que são ferramentas CASE, sua taxonomia e como fornecem integração através de um repositório central. O repositório CASE permite compartilhamento de informações, integração de dados e ferramentas, e imposição de metodologias durante o desenvolvimento de software.
Este documento apresenta o plano de ensino para a disciplina de Gerência de Projetos ministrada na Universidade Federal de Sergipe. O plano descreve o conteúdo programático, os procedimentos metodológicos, as atividades de avaliação e as referências bibliográficas para a disciplina. As aulas serão ministradas pelo professor Rogério Patrício Chagas do Nascimento e incluirão tanto aulas teóricas quanto práticas em laboratório. Os alunos serão divididos em grupos para realizar seminários, manter
Este documento apresenta uma aula introdutória sobre engenharia de software. Ele discute o objetivo da disciplina, o que é software e engenharia de software, características e objetivos da engenharia de software, qualidade de software, a crise do software e atividades e artefatos relacionados à engenharia de software.
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.
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...Felipe Pontes
1. O documento descreve um projeto de graduação para desenvolver um ambiente online chamado AMAO para auxiliar na correção e resolução de avaliações de programação.
2. O sistema AMAO será uma plataforma online de autocorreção que utilizará exclusivamente softwares livres para ajudar no aprendizado de programação de forma escalável e modularizada.
3. No desenvolvimento do AMAO, serão pesquisadas as principais características de ferramentas existentes de autocorreção para aproveitar tais conceitos e guiar o desen
Este documento descreve ferramentas CASE, que automatizam atividades de gestão de projetos e produtos de desenvolvimento de software. Ele discute a taxonomia de ferramentas CASE, arquitetura de integração e repositório CASE. O repositório CASE fornece funcionalidades como integridade de dados, informação compartilhada e imposição de metodologia.
Este documento discute a gestão da configuração de software, incluindo: (1) O que é e por que é importante controlar mudanças, (2) Os conceitos de elementos da configuração e linhas base, (3) As tarefas de gestão da configuração como controle de versões e auditorias.
Este documento discute métricas, estimativas e planejamento para projetos de software orientado a objetos. Ele apresenta métricas comuns como número de classes, casos de uso e subsistemas que podem ser usadas para estimar o esforço de desenvolvimento. Também fornece diretrizes como classificar o tipo de interface do produto e multiplicar o número de classes-chave por um fator para estimar classes de suporte.
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
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.
Apresentação Scrum + Gerenciamento de PortfólioPlinio Tulio
Este documento discute a metodologia Scrum e gerenciamento de portfólios. [1] Apresenta as principais características do Scrum como método ágil, incluindo papéis, artefatos e reuniões. [2] Discute a história e conceitos de gerenciamento de portfólios, como alinhar projetos com a estratégia da organização e alocar recursos de forma eficiente. [3] Explica como o gerenciamento de portfólio pode melhorar a execução de projetos e garantir que sejam percebidos os
O documento apresenta as informações sobre o professor Rogério Patrício Chagas do Nascimento, incluindo sua formação acadêmica, áreas de pesquisa e interesse, disciplinas ministradas, parcerias internacionais e experiência.
Este documento discute planejamento temporal e monitoramento de projetos de software. Ele explica como (1) definir cronogramas com tarefas, responsáveis e datas; (2) como planejamento bem-feito leva a entregas bem espaçadas e considera riscos; e (3) como monitorar o progresso comparando planos com resultados reais.
Practice 4 :: Gestão de Projetos de SW OO :: Métricas, Estimação e PlanificaçõesRogerio P C do Nascimento
Este documento discute a gestão de projetos de software orientado a objetos. Ele apresenta métricas comuns usadas para estimar o esforço necessário para desenvolvimento de software, como número de classes, casos de uso e subsistemas. Também descreve o modelo de métricas de Lorenz e Kidd adotado pela Lacertae Software, que usa classes-chave, classes de suporte e multiplicadores para estimar o número de classes e esforço de um projeto.
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.
Este documento discute a gestão da configuração de software, incluindo: 1) O que é gestão da configuração e por que é importante, 2) Os conceitos de elementos da configuração e linhas base, 3) As tarefas e processos envolvidos na gestão da configuração como controle de versões e auditorias.
O documento apresenta uma introdução à gestão de riscos em projetos de software, definindo o que é gestão de riscos, quem a realiza e por que é importante. Também descreve os principais tipos de riscos de software e métodos para identificá-los e estimar seu impacto, como tabelas de riscos.
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 discute métricas e indicadores para processos e projetos de software. Ele explica que métricas são medidas quantitativas que permitem avaliar a eficácia do processo e do projeto ao longo do tempo. Também descreve domínios comuns de métricas como processo, projeto e produto e fornece exemplos de métricas específicas para cada domínio.
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.
Este documento discute planejamento temporal e monitorização de projetos de software. Ele introduz os conceitos-chave de planejamento temporal, incluindo decomposição de tarefas, diagramas de Gantt e tabelas de controle. Além disso, discute a importância da monitorização do progresso do projeto em relação ao cronograma planejado.
Este documento descreve ferramentas CASE (Computer-Aided Software Engineering). Detalha o que são ferramentas CASE, sua taxonomia e como fornecem integração através de um repositório central. O repositório CASE permite compartilhamento de informações, integração de dados e ferramentas, e imposição de metodologias durante o desenvolvimento de software.
Este documento apresenta o plano de ensino para a disciplina de Gerência de Projetos ministrada na Universidade Federal de Sergipe. O plano descreve o conteúdo programático, os procedimentos metodológicos, as atividades de avaliação e as referências bibliográficas para a disciplina. As aulas serão ministradas pelo professor Rogério Patrício Chagas do Nascimento e incluirão tanto aulas teóricas quanto práticas em laboratório. Os alunos serão divididos em grupos para realizar seminários, manter
Este documento apresenta uma aula introdutória sobre engenharia de software. Ele discute o objetivo da disciplina, o que é software e engenharia de software, características e objetivos da engenharia de software, qualidade de software, a crise do software e atividades e artefatos relacionados à engenharia de software.
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.
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...Felipe Pontes
1. O documento descreve um projeto de graduação para desenvolver um ambiente online chamado AMAO para auxiliar na correção e resolução de avaliações de programação.
2. O sistema AMAO será uma plataforma online de autocorreção que utilizará exclusivamente softwares livres para ajudar no aprendizado de programação de forma escalável e modularizada.
3. No desenvolvimento do AMAO, serão pesquisadas as principais características de ferramentas existentes de autocorreção para aproveitar tais conceitos e guiar o desen
Este documento descreve ferramentas CASE, que automatizam atividades de gestão de projetos e produtos de desenvolvimento de software. Ele discute a taxonomia de ferramentas CASE, arquitetura de integração e repositório CASE. O repositório CASE fornece funcionalidades como integridade de dados, informação compartilhada e imposição de metodologia.
Este documento discute a gestão da configuração de software, incluindo: (1) O que é e por que é importante controlar mudanças, (2) Os conceitos de elementos da configuração e linhas base, (3) As tarefas de gestão da configuração como controle de versões e auditorias.
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMatheus Costa
O documento discute as principais metodologias ágeis para gestão e planejamento de projetos, incluindo Scrum, eXtreme Programming (XP) e Kanban. Ele explica os princípios e práticas de cada metodologia, como sprints, histórias de usuário e quadros de tarefas. O documento também discute os benefícios das metodologias ágeis, como entregas frequentes de software e adaptação a mudanças, em comparação com métodos mais tradicionais.
O documento discute a análise e gestão de riscos no desenvolvimento de software. Ele descreve o que é gestão de riscos, quem a realiza e por que é importante. Também explica como identificar, estimar e avaliar riscos de projeto, técnicos e de negócios, além de apresentar um método e tabela para gerenciá-los.
The document discusses various aspects of risk management for software engineering projects. It describes reactive risk management where risks are addressed after they occur versus proactive risk management where formal risk analysis is performed upfront. It outlines seven principles for effective risk management including maintaining a global perspective, encouraging open communication, and emphasizing a continuous process. The document also discusses different aspects of risk management such as risk identification, assessment, projection, and mitigation strategies.
The document discusses formulation and planning for web engineering projects. It begins by outlining the key steps in formulation, which include identifying business needs, describing objectives, defining features and functions, and establishing requirements gathering. It then provides details on gathering requirements such as defining user categories, communicating with stakeholders, analyzing information, and creating use cases. The document also discusses differences between outsourcing and in-house development, as well as best practices for planning web engineering projects.
O documento discute a importância da planificação de projetos de software. Explica que o plano de projeto define as tarefas, cronograma, recursos e riscos necessários para garantir a qualidade e o sucesso do projeto dentro do escopo, orçamento e prazo acordados.
Este documento discute as fases de engenharia de software e gestão de projetos de software. Descreve as principais fases de engenharia de software como definição, engenharia, planejamento, análise de requisitos, desenvolvimento, teste e manutenção. Também explica os conceitos-chave de gestão de projetos de software, como pessoas, produto, processo e projeto, e como a gestão de projetos é usada para garantir o sucesso das fases de engenharia de software.
The document discusses planning practices for software projects. It recommends understanding the project scope, involving stakeholders, recognizing planning is iterative, estimating based on known information, considering risk, being realistic, adjusting detail over time, defining quality and change management, and tracking plans. It also suggests asking key questions during initiation like purpose, tasks, timeline, responsibilities, locations, and resource needs. The practices include reassessing scope, risks, functions, and infrastructure to create a coarse plan with increments, schedule, and delivery dates, then making a detailed first increment plan and tracking progress.
The document discusses key concepts for managing software engineering projects including the four Ps (People, Product, Process, Project), stakeholders, software teams, and common challenges that can arise. It emphasizes that projects require understanding user needs, clear scope, managing changes, selecting the right team structure, and tracking progress through work products and quality assurance. Formal practices like risk management, metrics, and defect tracking are presented as critical to project success.
O documento discute o Capability Maturity Model Integration (CMMI) e o The Open Group Architecture Framework (TOGAF). O CMMI é um modelo de maturidade e melhores práticas para desenvolvimento e manutenção de software, enquanto o TOGAF é um framework para arquitetura empresarial. O documento também fornece contexto histórico sobre o desenvolvimento do CMMI e descreve suas principais representações e níveis de maturidade.
O documento descreve o modelo Capability Maturity Model (CMM), incluindo sua história, características, níveis de maturidade, áreas-chave de processo e evolução para o CMMI. O CMM avalia a capacitação de empresas de software através de cinco níveis de maturidade dos processos, desde inicial até otimizado.
Este documento fornece um resumo das principais metodologias ágeis, incluindo Kanban, Scrum e XP. Ele discute o histórico, conceitos, princípios e aplicação prática de cada metodologia.
1. O documento apresenta o plano de projeto para o desenvolvimento de um sistema E-Commerce.
2. Ele descreve as principais funcionalidades do sistema, estimativas de prazo e esforço, análise de riscos e planejamento da equipe.
3. O projeto tem duração estimada de 8 meses e envolverá 6 pessoas.
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.
Estimativa de software usando pontos de funçãoClaudio Martins
1. O documento apresenta a técnica de Pontos de Função para estimativa e medição de projetos de software.
2. A técnica envolve contar as funções do software, divididas em funções de dados e transações, e atribuir pesos de acordo com a complexidade para calcular os Pontos de Função.
3. Os Pontos de Função podem ser usados para estimar o tamanho, custo e esforço de projetos de software de forma independente da tecnologia.
▫ Integração com o Office.
• Pontos Negativos:
▫ Custo da licença;
▫ Pesada para pequenos projetos;
▫ Curva de aprendizado maior.
Microsoft Project
Microsoft Project
Microsoft Project
Agenda
• Introdução;
• Importância das Ferramentas;
• Ferramentas:
▫
▫
▫
▫
▫
▫
▫
▫
▫
Open Project;
Trac;
Redmine;
WebCollab;
GPWEB;
Collabtive;
Microsoft
Este documento apresenta os conceitos e ferramentas de sistemas de controle de versão, com foco no GIT. Apresenta os principais conceitos de VCS, como repositórios, commits e ramificações. Discute as características e comandos básicos do GIT e faz uma comparação com outros sistemas como Subversion, ClearCase e Mercurial. Por fim, apresenta um estudo de caso sobre o uso do GIT em um projeto de software.
O documento apresenta um plano de aula sobre estrutura atômica da matéria. O plano descreve os objetivos gerais e específicos da aula, o conteúdo a ser abordado, incluindo os principais modelos atômicos, a metodologia de ensino interativa e a avaliação dos alunos.
Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Geren...Igor Costa
Este documento apresenta o plano de projeto para o desenvolvimento de um sistema de gestão de eventos (SIGE) para a Universidade Federal de Sergipe. O SIGE permitirá cadastrar, analisar, reservar recursos e gerar relatórios de eventos. O projeto será desenvolvido por uma equipe de 4 pessoas usando metodologias ágeis em um período de 6 meses.
Este documento apresenta o plano de projeto de software para o Sistema de Informação da Unidade de Reabilitação (SIUR) do Hospital Universitário da Universidade Federal de Sergipe (HU/UFS). O SIUR tem como objetivo automatizar e integrar os processos da Unidade de Reabilitação do HU/UFS, melhorando a gestão dos pacientes, tratamentos, avaliações e prontuários. O documento descreve os requisitos funcionais e não funcionais, estimativas de esforço, riscos, planejamento e organização da equipe para o desenvolvimento
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.
Este relatório descreve um sistema WebCrawler. Apresenta os requisitos funcionais e não funcionais, incluindo casos de uso e modelos de classes. Também descreve a arquitetura do sistema dividida em subsistemas e a implementação das classes.
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 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
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.
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.
1. O documento apresenta um trabalho sobre a bonificação natalina da empresa ABC desenvolvido para a disciplina de Algoritmos II.
2. O trabalho propõe um sistema com funcionalidades como cadastro de funcionários, pesquisa por nome e código, relatório e salvar dados.
3. O objetivo é aplicar conceitos de programação estruturada em C como comandos de seleção, repetição, registros e structs, manipulação de arquivos.
1. O documento apresenta o plano de projeto de software para o sistema +Paciente, que tem como objetivo melhorar o atendimento aos pacientes do Hospital Universitário de Sergipe. 2. O sistema permitirá que pacientes e acompanhantes acessem informações sobre consultas, procedimentos cirúrgicos e pós-operatório de forma online. 3. Estimativas indicam que o projeto levará aproximadamente 6 meses e 7 dias para ser concluído por uma equipe de 5 pessoas.
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 um trabalho sobre a aplicação da abordagem GQM (Goal/Question/Metric) para definir um processo de engenharia de requisitos para sistemas embarcados. O trabalho realizou uma avaliação do processo de desenvolvimento de micro e pequenas empresas desenvolvedoras de software embarcado e propõe um processo de engenharia de requisitos para este tipo de sistema e empresas. A abordagem GQM foi utilizada para definir os objetivos de medição e melhoria do processo proposto.
Tecnologias da Informação no Chão de FábricaDaniel Pettini
Este documento apresenta as tecnologias de informação envolvidas nos sistemas de execução de manufatura, tendo como ponto de partida a informação no chão de fábrica. Aborda conceitos e aplicações de sistemas de controle como controladores lógicos programáveis, sistemas de aquisição de dados, controle estático de processos, controle numérico computadorizado, sistema digital de controle distribuído e célula flexível de manufatura, com o objetivo de levantar informações para melhorar a integração e o controle
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.
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.
O documento descreve o programa FTOOL, um software educacional para análise de estruturas. O documento apresenta: 1) como baixar e instalar o programa; 2) como manipular arquivos e exportar imagens; e 3) como criar e editar modelos estruturais, atribuir propriedades, aplicar cargas e visualizar resultados. O objetivo do programa é ensinar conceitos de mecânica estrutural de forma interativa.
Este documento fornece diretrizes para documentar o desenvolvimento de um software, incluindo requisitos, projeto, implementação, testes e implantação. Ele descreve os componentes necessários para documentar um projeto de software, como introdução, descrição geral do sistema, requisitos, análise e design, implementação, testes e implantação.
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.
Atividades de Inglês e Espanhol para Imprimir - AlfabetinhoMateusTavares54
Quer aprender inglês e espanhol de um jeito divertido? Aqui você encontra atividades legais para imprimir e usar. É só imprimir e começar a brincar enquanto aprende!
1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
DISCIPLINA: Gerência de Projetos
PERÍODO: 2015.2
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Matheus Mendonça Menezes
Ytallo Augusto Lima
Vanderson Sampaio
São Cristóvão – Sergipe
2016
2. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
DISCIPLINA: Gerência de Projetos
PERÍODO: 2015.2
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Matheus Mendonça Menezes
Ytallo Augusto Lima
Vanderson Sampaio
São Cristóvão – Sergipe
2016
Trabalho apresentado ao Prof. Dr. Rogério
Patrício Chagas do Nascimento como nota
para disciplina Gerência de Projetos do curso
de graduação em Sistemas de Informação –
Bacharelado da Universidade Federal de
Sergipe (UFS).
3. Índice
1. INTRODUÇÃO................................................................................................................................4
1.1 Âmbito do Projeto......................................................................................................................4
1.2 Funções principais do produto de software............................................................................... 4
1.3 Requisitos comportamentais ou de performance.......................................................................5
1.4 Gestão e Restrições Técnicas.....................................................................................................6
2. ESTIMAÇÕES DO PROJETO........................................................................................................ 6
2.1 Dados históricos utilizados para as estimações......................................................................... 6
2.2 Técnicas de estimação e resultados............................................................................................6
2.2.1 Técnica de estimação......................................................................................................... 6
2.3 Resultados..................................................................................................................................7
2.4 Recursos do Projeto................................................................................................................... 8
2.4.1 Recursos Humanos.............................................................................................................8
2.4.2 Hardware Necessário......................................................................................................... 9
2.4.3 Software de Suporte...........................................................................................................9
3. ANÁLISE E GESTÃO DE RISCOS................................................................................................9
3.1 Riscos do Projeto....................................................................................................................... 9
3.2 Tabela de Riscos.......................................................................................................................11
3.3 Redução e Gestão de Riscos.................................................................................................... 13
4. PLANEJAMENTO TEMPORAL.................................................................................................. 17
4.1 Conjunto de Tarefas Macro do Projeto.................................................................................... 17
4.2 Diagrama de Gantt...................................................................................................................18
5. ORGANIZAÇÃO DO PESSOAL..................................................................................................22
5.1 Estrutura da Equipe..................................................................................................................22
5.2 Mecanismos de Comunicação................................................................................................. 22
5.3 Uso do Edu-blog como ferramenta de apoio........................................................................... 23
6. PRECAUÇÕES TOMADAS PARAASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SOFTWARE.............................................................................................................23
7. Referências..................................................................................................................................... 24
Índice de figuras
Figura 1: Diagrama Caso de Uso do Sistema de Controle de Frequência............................................5
Figura 2: Multiplicadores para interfaces.............................................................................................7
Figura 3: Diagrama de Classes de Domínio do Sistema de Controle de Frequência...........................8
Figura 4: Lista de Tarefas - Sistema de Controle de Frequência........................................................18
Figura 5: Diagrama de Gantt - Sistema de Controle de Frequência...................................................21
Índice de tabelas
Tabela 1: Enquadramento dos Riscos do Projeto Sistema de Controle de Frequência......................11
Tabela 2: Impactos e Probabilidades dos Riscos do Sistema de Controle de Frequência..................13
Tabela 3: Integrantes da equipe e atribuições.....................................................................................22
4. Índice de Quadros
Quadro 1: Proibição de Utilização.....................................................................................................13
Quadro 2: Negação de Recursos para Integração...............................................................................13
Quadro 3: Atualizações do Sistema....................................................................................................14
Quadro 4: Risco de Política da Universidade.....................................................................................14
Quadro 5: Atividades Paralelas ao Projeto.........................................................................................14
Quadro 6: Congestionamento de Servidores......................................................................................15
Quadro 7: Atendimento à Exigência Tecnológica..............................................................................15
Quadro 8: Exclusão de Usuários........................................................................................................15
Quadro 9: Falta de Ferramentas de Testes.........................................................................................16
Quadro 10: Abandono de Disciplina..................................................................................................16
Quadro 11: Falta de conhecimento acerca das ferramentas a serem utilizadas.................................17
5. 1. INTRODUÇÃO
O Sistema de Controle de Frequência para dispositivos móveis destina-se aos
professores da Universidade Federal de Sergipe. Trata-se de uma alternativa ao
cumprimento dos deveres laborais desses professores, no que diz respeito à atualização
da frequência dos seus alunos, junto ao Sistema Integrado de Gestão Acadêmica (SIGAA,
como será chamado daqui em diante).
Este documento especifica os requisitos funcionais do Sistema de Controle de
Frequência. Tais requisitos foram levantados após entrevista com o cliente. Foram
também consequência da observação e análise da situação atual do ambiente do cliente.
Os requisitos levantados dão base para o desenvolvimento do Sistema de Controle de
Frequência para dispositivos móveis. O Sistema será criado para a plataforma Android, de
modo a atender a uma maior parcela de usuários em sua primeira versão.
1.1 Âmbito do Projeto
O Software permite que o usuário, qualquer professor da Universidade Federal de
Sergipe, cadastre as presenças e ausências dos seus alunos em suas turmas em
qualquer dispositivo Android. Dessa maneira os professores não ficariam mais reféns da
interface WEB provida pelo SIGAA. Isso se torna bastante útil principalmente quando da
necessidade de aulas em campo. Nessas aulas não há computadores com acesso à
internet disponíveis para que o professor cadastre as presenças e ausências no momento
da aula.
Além disso é possível também criar anotações referentes a cada aula, que o
professor julgue necessárias para a melhoria do seu trabalho.
1.2 Funções principais do produto de software
A Figura 1 mostra um diagrama de caso de uso que ilustra os atores que atuam no
Sistema de controle de frequência, como também os requisitos funcionais do Sistema.
4
6. Figura 1: Diagrama Caso de Uso do Sistema de Controle de Frequência
Na figura acima podem ser observados os atores representados como Professor e
SIGAA. Os atores são aqueles que executam funções no Sistema. Há também o registro
dos requisitos funcionais do Sistema, são eles: Selecionar Aula, Efetuar Chamada, Manter
Parâmetros, Informar Anotações, Cadastrar Usuário, Sincronizar Disciplina, Atualizar
Presença e Efetuar Login.
Vale ressaltar que vários desses requisitos dependem do Efetuar Login. Devido a
citada dependência, tais requisitos aparecem na Figura 1 ligados por uma linha pontilhada
ao requisito Efetuar Login. O parâmetro <<include>> é usado para ressaltar a
dependência.
1.3 Requisitos comportamentais ou de performance
O Sistema apresentado deve ser compatível com o maior número possível de
dispositivos Android ativos e presentes no mercado. Para tal o mesmo foi desenvolvido
tendo como requisito mínimo a versão 4.1 do Android, Jelly Bean. Dessa forma e de
acordo com dados providos pela IDE de desenvolvimento oficial do Android, Android
Studio, o sistema em questão atende a mais de 86% dos dispositivos Android ativos e
presentes atualmente no mercado.
5
7. O acesso ao Sistema se dará via cadastro de usuário no próprio Sistema. A
segurança será provida através de senha para acesso às funcionalidades do Sistema. Os
requisitos de hardware para uso do Sistema são:
- Smartphone compatível com sistema Android a partir da versão 4.1.x (Jelly Bean); -
Sistema Android 4.1.x ou superior instalado;
1.4 Gestão e Restrições Técnicas
Algumas restrições técnicas estão listadas abaixo:
O Sistema de Controle de Frequência será́ desenvolvido com a linguagem de
programação Java, com a IDE de desenvolvimento Android Studio;
O sistema de banco de dados a utilizado será o SQLite;
O sistema requer gosto por parte do usuário para com o uso de sistemas móveis;
O Sistema será uma aplicação mobile para dispositivos Android.
2. ESTIMAÇÕES DO PROJETO
2.1 Dados históricos utilizados para as estimações
Tendo em vista que este projeto é o primeiro a ser realizado pelos integrantes da
equipe, não será possível utilizar dados históricos para as estimações do mesmo.
2.2 Técnicas de estimação e resultados
2.2.1 Técnica de estimação
A técnica utilizada para a estimação e resultados foi a técnica de Lorenz & Kidd.
Trata-se de uma técnica orientada a classes que dá como resultado uma estimativa do
esforço necessário para desenvolver o software. O que se faz nessa técnica basicamente
é decompor os esforços usando como parâmetros o número de classes-chave do
Sistema. Essas classes são responsáveis pela estimativa de esforço final. Há também as
classes de suporte, que são classes que não fazem parte do domínio do problema,
geralmente representam janelas, botões, caixas de diálogo, etc.
Um quesito importante desta técnica é a classificação da interface do produto, que
resultará no multiplicador para as classes de suporte, de acordo com a Figura 2 abaixo.
6
8. Em seguida, são retratados os resultados obtidos ao aplicar-se a técnica
supracitada no projeto do Sistema de Controle de Frequência.
2.3 Resultados
Com base na técnica de Lorenz & Kidd e tendo sido utilizado o diagrama de
classes de domínio, exibido na Figura 3.
7
Figura 2: Multiplicadores para interfaces
9. Figura 3: Diagrama de Classes de Domínio do Sistema de Controle de Frequência
Foram obtidas as seguintes informações:
❏ Classes chaves: 8 classes: Aluno, Aula, EfetuarChamada, Frequência,
AtualizarFrequência, Anotacao, Usuario, Sincronizador;
❏ Tipo de interface: GUI Complexa;
❏ Classes de suporte: 8 (classes de domínio) X 3 (fator multiplicador) = 24 classes;
❏ Total de classes: 8 (classes chaves) + 24 (classes de suporte) = 32 classes;
❏ Como unidade média de trabalho por classe, utilizaremos 15 dias por pessoa,
totalizando 480 dias por pessoa.
❏ A equipe possui três membros, estimando um prazo de 160 dias para conclusão do
projeto. Nesses dias estão inclusos os sábados e domingos.
2.4 Recursos do Projeto
2.4.1 Recursos Humanos
A equipe é composta por um gestor de projetos, um arquiteto de software e um
analista de sistemas, tendo todos a atribuição de codificar e testar o sistema.
8
10. 2.4.2 Hardware Necessário
❏ Smartphone compatível com sistema Android a partir da versão 4.1.x (Jelly Bean);
❏ Sistema Android 4.1.x ou superior instalado;
❏ 512KB de espaço livre em disco;
❏ Dispositivo capaz de acesso à internet.
2.4.3 Software de Suporte
O sistema será desenvolvido na plataforma padrão de desenvolvimento do Google
para o sistema Android, Android Studio, serão usadas a linguagem Java (padrão para o
ambiente de desenvolvimento em questão) e o banco de dados SQLite. Maiores
informações acerca desse banco de dados podem ser obtidas no seguinte endereço
eletrônico: http://www.sqlite.org/.
3. ANÁLISE E GESTÃO DE RISCOS
3.1 Riscos do Projeto
A Tabela 1 descreve os riscos identificados no projeto do Sistema de Controle de
Frequência.
9
11. Especial Comum Negócio Técnico Projeto Risco
x x
A Universidade pode não
dar a autorização para
que o software possa se
utilizado.
x
Não disponibilização de
recursos para integração.
x x
P o d e m h a v e r
atualizações do sistema
operacional Android que
tornem o aplicativo ou
i n c o m p a t í v e l o u
i n a d e q u a d o à n o v a
versão.
x
Politica da Universidade
p o d e i n v i a b i l i z a r a
utilização do software.
x
Trabalhos paralelos,
profissionais ou da
Universidade.
x
Número de acessos ao
Sistema poderá causar
congestionamento.
x x
Como os clientes são
p e s s o a s , t o d o s
diferentes, alguns são
tecnologicamente mais
exigentes que outros.
x
O S i s t e m a f o i
desenvolvido apenas
p a r a a p l a t a f o r m a
Android, i s s o p o d e
prejudicar usuários de
outras plataformas.
x
Não foram estabelecidas
ferramentas automáticas
de teste.
x
Algum aluno abandonar a
disciplina.
x Falta de conhecimento
aprofundado por parte
10
12. dos desenvolvedores
acerca das ferramentas a
serem utilizadas.
Tabela 1: Enquadramento dos Riscos do Projeto Sistema de Controle de Frequência
3.2 Tabela de Riscos
A Tabela 2 apresenta os riscos, o impacto que eles ocasionam e a probabilidade de
que ocorram.
11
13. Impacto % Probabilidade Risco
Catastrófico 80 A Universidade pode não
dar a autorização para
que o software possa se
utilizado.
Catastrófico 70 Não disponibilização de
recursos para integração.
Catastrófico 20 P o d e m h a v e r
atualizações do sistema
operacional Android que
tornem o aplicativo ou
i n c o m p a t í v e l o u
i n a d e q u a d o à n o v a
versão.
Catastrófico 20 Politica da Universidade
p o d e i n v i a b i l i z a r a
utilização do software.
Crítico 60 Trabalhos paralelos,
p r o f i s s i o n a i s o u d a
Universidade.
Crítico 30 Número de acessos ao
sistema poderá causar
congestionamento.
Moderado 50 Como os clientes são
pessoas, todos diferentes,
a l g u n s s ã o
tecnologicamente mais
exigentes que outros.
Moderado 50 O s i s t e m a f o i
desenvolvido apenas para
a plataforma Android, isso
pode prejudicar usuários
de outras plataformas.
Moderado 30 Não foram estabelecidas
ferramentas automáticas
de teste.
Marginal 50 Algum aluno abandonar a
disciplina.
Marginal 20 Falta de conhecimento
aprofundado por parte
dos desenvolvedores
12
14. acerca das ferramentas a
serem utilizadas.
Tabela 2: Impactos e Probabilidades dos Riscos do Sistema de Controle de Frequência
3.3 Redução e Gestão de Riscos
Com base nos riscos já elencados, as seguintes estratégias de contingência foram
elaboradas:
RISCO: 01 - Proibição de
Utilização
Probabilidade: 80% Impacto: 5
Descrição: A Universidade pode não dar a autorização para que o software possa
ser utilizado.
Estratégia de redução: Apresentar as funcionalidades do software aos gestores
da Universidade Federal de Sergipe. Convidar professores interessados a
conversarem com a Universidade.
Plano de contingência: Apresentar o Sistema para outras Universidades que
utilizem sistema de controle de frequência eletrônico.
Pessoa responsável: Vanderson Sampaio.
Status: Aguardando reunião com responsáveis pelo SIGAA na UFS.
Quadro 1 – Risco: Proibição de Utilização
RISCO: 02 – Negação de
Recursos para Integração
Probabilidade: 70% Impacto: 5
Descrição: O setor responsável da Universidade pode não disponibilizar recursos
para integração entre o sistema legado e o Sistema de Controle de Frequência.
Estratégia de redução: Guardar os dados em base de dados local, para que não
sejam perdidos enquanto se aguarda a liberação dos recursos necessários.
Plano de contingência: Prover funcionalidades de exportação dos dados para
tabelas, permitir salvar dados na nuvem, de modo que o usuário possa acessar
tais dados em outros dispositivos ou até mesmo desktops.
Pessoa responsável: Vanderson Sampaio.
Status: Aguardando reunião com responsáveis pelo SIGAA na UFS.
Quadro 2 - Negação de Recursos para Integração
13
15. RISCO: 03 – Atualizações
de Sistema
Probabilidade: 20% Impacto: 5
Descrição: Podem haver atualizações do sistema operacional Android que tornem
o aplicativo incompatível ou inadequado à nova versão.
Estratégia de redução: Acompanhar atualizações regulares do sistema
operacional Android e verificar a necessidade de ajustes para adaptação.
Plano de contingência: Lançar atualização de aplicativo com as mudanças
requeridas pela nova versão do sistema operacional Android.
Pessoa responsável: Matheus Mendonça.
Status: Aguardando atualizações de sistema.
Quadro 3 – Atualizações de Sistema
RISCO: 04 – Risco de
Política da Universidade
Probabilidade: 20% Impacto: 5
Descrição: Política da universidade pode inviabilizar a utilização do software.
Estratégia de redução: Mostrar que o software é seguro e não oferecerá brechas
de segurança para com a base de dados da Universidade, além de tornar mais
prático o trabalho dos professores. Convidar professores interessados a
conversarem com a Universidade.
Plano de contingência: Apresentar o Sistema para outras Universidades que
utilizem sistema de controle de frequência eletrônico.
Pessoa responsável: Matheus Mendonça.
Status: Aguardando reunião com responsáveis pelo SIGAA na UFS.
Quadro 4 - Risco de Política da Universidade
RISCO: 05 – Atividades
paralelas ao Projeto
Probabilidade: 60% Impacto: 4
Descrição: Trabalhos paralelos, profissionais ou da Universidade.
Estratégia de redução: Dividir as tarefas adequadamente entre os integrantes.
Plano de contingência: Um integrante pode vir a ser responsável por tarefa(s) de
outro(s), em eventuais necessidades identificadas pelo gestor, para cumprir os
prazos do Projeto.
Pessoa responsável: Vanderson Sampaio.
Status: Aguardando início dos trabalhos.
Quadro 5 - Atividades paralelas ao Projeto
14
16. RISCO: 06 –
Congestionamento de
Servidores
Probabilidade: 30% Impacto: 4
Descrição: Número de acessos simultâneos ao sistema poderá causar
congestionamento.
Estratégia de redução: Solicitar ao administrador de redes uma configuração
para que os acessos sejam feitos paralelamente entre os servidores.
Plano de contingência: Instalação de novos servidores.
Pessoa responsável: Ytallo Lima.
Status: Configurando os servidores para o acesso ao sistema.
Quadro 6 – Congestionamento de Servidores
RISCO: 07 – Atendimento
à Exigência Tecnológica
Probabilidade: 50% Impacto: 3
Descrição: O Sistema é destinado aos mais diversos usuários, alguns
tecnologicamente mais exigentes que outros.
Estratégia de redução: Tornar a interface amigável e autodidata ao usuário.
Plano de contingência: Observar as avaliações, reclamações e sugestões dos
usuários na Google Play. Aplicar alterações buscando atender a maior parte dos
usuários.
Pessoa responsável: Matheus Mendonça.
Status: Modelos de interface em análise.
Quadro 7 - Atendimento à Exigência Tecnológica
RISCO: 08 – Exclusão de
Usuários
Probabilidade: 50% Impacto: 3
Descrição: O sistema foi desenvolvido apenas para a plataforma Android, isso
pode fazer com que usuários de outras plataformas sintam-se excluídos.
Estratégia de redução: Realizar uma pesquisa a fim de identificar quais SO são
mais utilizados pelos clientes.
Plano de contingência: Solicitar aos desenvolvedores a criação de um sistema
com maior portabilidade.
Pessoa responsável: Vanderson Sampaio.
Status: Pesquisa com os clientes a ser agendada.
Quadro 8 - Exclusão de Usuários
15
17. RISCO: 09 – Falta de
Ferramentas de Teste
Probabilidade: 30% Impacto: 3
Descrição: Não foram estabelecidas ferramentas automáticas de teste.
Estratégia de redução: Solicitar a aquisição de novas ferramentas automáticas
de Teste. Solicitar aos testadores que incluam essas ferramentas no processo de
teste.
Plano de contingência: Executar testes dentre uma amostra de usuários e anotar
o feedback provido por eles.
Pessoa responsável: Ytallo Lima.
Status: Seleção de novas ferramentas automáticas de teste.
Quadro 9 - Falta de Ferramentas de Teste
RISCO: 10 – Abandono
de Disciplina
Probabilidade: 50% Impacto: 2
Descrição: Algum aluno pode abandonar a disciplina Gerência de Projetos.
Estratégia de redução: Tentar convencer o possível desistente, mostrar como
pode ser prejudicial uma desistência ao seu histórico.
Plano de contingência: Realocar as atividades do Projeto dentre os membros
restantes da equipe.
Pessoa responsável: Ytallo Lima
Status: Seleção de pessoas para pesquisar os motivos de evasão.
Quadro 10 – Abandono de Disciplina
16
18. RISCO: 11 – Falta de
conhecimento acerca das
ferramentas a serem
utilizas
Probabilidade: 20% Impacto: 2
Descrição: Falta de conhecimento aprofundado por parte dos desenvolvedores
acerca das ferramentas a serem utilizadas no desenvolvimento do Sistema de
Controle de Frequência.
Estratégia de redução: Solicitar que os desenvolvedores dediquem algum tempo
para um maior conhecimento da ferramenta através de tutoriais online.
Plano de contingência: Contratar empresa especializada para realização de um
treinamento.
Pessoa responsável: Ytallo Lima
Status: Integrantes estudando ferramentas através de tutoriais.
Quadro 11 - Falta de conhecimento acerca das ferramentas a serem utilizas
4. PLANEJAMENTO TEMPORAL
4.1 Conjunto de Tarefas Macro do Projeto
Dias de Trabalho Porcentagem Tarefas Macro
7 4% Planejamento
61 38% Análise de Requisitos e
Modelagem
30 19% Codificação
62 39% Testes
Tabela 3: Relação das tarefas macro e dias de trabalho
Total de 160 dias para a execução do projeto.
17
19. 4.2 Diagrama de Gantt
Na Figura 4, são apresentadas todas as tarefas e sub-tarefas que serão realizadas
durante o desenvolvimento o produto de software. A fase de planejamento é composta
pelo levantamento de requisitos e validação de requisitos.
Levantamento de requisitos corresponde à etapa de compreensão do problema
aplicada ao desenvolvimento de software (BEZERRA, 2006). A fase de levantamento de
18
Figura 4: Lista de Tarefas - Sistema de Controle de Frequência
20. requisitos foi dividida em: Entrevista com clientes, acompanhamento da rotina dos
usuários e reunião com os responsáveis técnicos.
Na entrevista com o cliente, procura-se extrair o que o cliente quer e como são
desenvolvidas suas atividades, mas o mais importante é definir o que ele realmente
precisa. Na fase de acompanhamento da rotina dos usuários, como o próprio nome já diz,
é observar as atividades do usuário para que haja uma maior certeza sobre o que será
desenvolvido.
Na reunião com os responsáveis técnicos, serão apresentadas todas as
informações extraídas nas fases anteriores (entrevista com o cliente e acompanhamento
da rotina do usuário) com o objetivo de validá-las. A validação de requisitos é o processo
pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer
(SOMMERVILLE, 2011).
A fase de análise e projeto foi subdividida em seis fases:
● Criação de casos de uso;
● Criação de diagramas de classe de domínio;
● Definição da arquitetura do projeto;
● Criação do diagrama de classes de projeto;
● Criação do diagrama de sequência;
● Prototipação.
Segundo Bezerra (2006), é a especificação de uma sequência de interações que
ocorrem entre o sistema e os agentes externos que utilizam o sistema. Com a criação dos
casos de uso, será mais fácil a visualização das interações que deverão ocorrer.
O diagrama de classes é usado no desenvolvimento de um modelo de sistema
orientado a objetos para mostrar as classes de um sistema e as associações entre essas
classes (SOMMERVILLE, 2011). O diagrama de sequência é utilizado para indicar a
comunicações dinâmicas entre os objetos durante a execução de uma tarefa
(PRESSMAN,2011).
Na fase de prototipação serão construídos esboços de algumas partes do sistema,
com o intuito de permitir a visualização do cliente de como ficará a parte específica que
está sendo mostrada, dando uma maior segurança aos desenvolvedores, já que com o
aval do cliente, não haverá necessidade de retrabalho.
A fase de codificação será utilizada para o desenvolvimento das funcionalidades do
sistema. Ela está dividida em:
● Cadastrar Usuário;
● Efetuar Login;
● Manter parâmetros;
● Selecionar Disciplinas;
● Selecionar Aula;
● Informar anotações;
● Efetuar Chamada;
19
21. ● Atualizar presença.
Por último mas não menos importante, é apresentada a fase de testes. Essa fase
também é dividida em vários tipos de testes, para que possam dá uma maior segurança
ao software desenvolvido. A fase de teste foi dividida em:
● Teste unitário: tipo de teste que é realizado em nível de componente ou classe;
● Teste de integração: teste realizado entre um ou mais componentes para verificar
se eles combinados funcionam de forma correta;
● Teste de performance: teste onde é verificado se o tempo de resposta é o desejado
para o momento de utilização da aplicação.
● Teste de carga: responsável por verificar o funcionamento da aplicação com a
utilização de uma quantidade grande de usuário simultâneos;
● Teste de aceitação dos usuários: nesse teste é verificado se a solução será bem
vista pelo usuário;
● Teste de configuração: testa se a aplicação funciona corretamente em diferentes
ambientes de hardware ou de software;
● Teste de segurança: como o próprio nome diz, testa a segurança da aplicação em
suas diversas formas. São testados os perfis, permissões, papéis utilizados para
navegar no sistema.
A Figura 5 abaixo traz o Diagrama de Gantt para o Sistema de Controle de
Frequência. Todas as tarefas listadas na Figura 4 estão presentes no diagrama em
questão. Ao lado esquerdo de cada tarefa está o nome da mesma. Ao lado direito de cada
tarefa está a duração, em dias, da mesma.
20
23. 5. ORGANIZAÇÃO DO PESSOAL
Aqui será explanado a repeito de como serão distribuídos os recursos humanos
disponíveis para a elaboração do projeto.
5.1 Estrutura da Equipe
A equipe é composta por: Matheus Mendonça, Ytallo Lima e Vanderson Sampaio, a
tabela abaixo destrincha as funções a serem exercidas por cada um.
Integrante Função Sumário de atividades
Vanderson Sampaio Gestor do projeto Definir papéis e funções dos
demais integrantes do projeto.
Acompanhar e gerir o trabalho de
todos os envolvidos no projeto.
Ytallo Lima Analista de sistema Definir os requisitos do sistema
Matheus Mendonça Arquiteto de software Desenvolver a arquitetura do
sistema, inclusive os diagramas
de projeto.
Vanderson Sampaio
Ytallo Lima
Matheus Mendonça
Programadores Desenvolver o código do
sistema.
Vanderson Sampaio
Ytallo Lima
Matheus Mendonça
Testadores Testar os casos de uso do
software
Tabela 3: Integrantes da equipe e atribuições
5.2 Mecanismos de Comunicação
Os mecanismos de comunicação utilizados pela equipe foram: e-mail, WhatsApp e
Gtalk. Tais meios foram utilizados para troca de mensagens e informações inerentes ao
projeto em questão.
A plataforma Google Docs foi utilizada como ferramente colaborativa para a
execução deste documento, de modo a minimizar a necessidade de encontros in loco
para execução do mesmo.
22
24. 5.3 Uso do Edu-blog como ferramenta de apoio
O Edu-blog serviu principalmente para:
• Disseminação do conhecimento;
• Troca de informações entre equipes diferentes;
• Aprendizado de ferramentas que ajudaram no desenvolvimento do trabalho da
equipe;
• Compartilhamento de novidades e curiosidades que mostraram-se bastante úteis à
execução do projeto em questão.
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E
CONTROLAR A QUALIDADE DO PRODUTO DE
SOFTWARE
A primeira preocupação foi diretamente com o cliente. O mesmo foi envolvido em
conversas com os integrantes da equipe acerca das necessidades e obrigações dos
professores para com a Universidade Federal de Sergipe.
Foram levadas em consideração também os testes a serem aplicados no
desenvolvimento: unitário, interação, performance, carga, aceitação do usuário,
configuração, segurança.
As reuniões entre os membros da equipe responsável pelo Projeto foram
constantes. Tais reuniões foram também bastante úteis quanto ao esclarecimento de
dúvidas sobre o Projeto. A documentação e diagramas do sistema foram alteradas no
decorrer das reuniões, buscou-se entretanto manter os integrantes sempre a par de tais
mudanças em tempo hábil de evitar maiores dúvidas.
23
25. 7. Referências
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas Com Uml. 2. ed. São
Paulo: Campus, 2006
PRESSMAN, Roger. Engenharia de Software: Uma abordagem profissional. 7. ed.
São Paulo: Bookman, 2011.
24