Plano de Gestão de Projecto. SyncMasters. ConfiKepper v2.0

Transcrição

1 1 Plano de Gestão de Projecto SyncMasters ConfiKepper v2.0 Carlos Paiva, , Inês Parente, , Mariana Martins, , Nuno Susana, , Rodrigo Carvalho, ,

2 2 1 PREFÁCIO Este plano de gestão de projecto tem o propósito de auxiliar e guiar na gestão do projecto ConfiKeeper, projeto esse realizado pela equipa SyncMasters no âmbito da cadeira de Engenharia de Software referente à Licenciatura em Design e Multimédia e da Licenciatura em Engenharia Informática. O documento foi redigido com base no Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Project Management Plans, IEEE Std , tanto em termos de forma como de conteúdo.

3 3 CONTEÚDO 1 Prefácio 2 2 Visão Global Sumário Finalidade, Âmbito e Objetivos Premissas e Restrições Artefactos do Projeto Calendarização e Orçamento Evolução do Plano Estrutura do Documento Referências 9 4 Definições 10 5 Organização do Projecto Interfaces Externos Estrutura interna Funções Start Up Estimativas Recursos Humanos Aquisição de Recursos Treino do Pessoal Planeamento do Trabalho Planeamento Calenderização Tarefas Budget Controlo do Projeto Controlo de requisitos Schedule Control Budget Control Controlo de Qualidade Comunicação e Relatórios do Projecto Gestão de Risco Término do Projeto Processo Técnico Modelo do Processo Ferramentas e Técnicas Plano de Aceitação

4 4 9 Processo de Suporte Gestão de Configuração Verificação e Validação Independente Documentação Garantia de Qualidade Objetivo do QMP Visão Global do Plano Gestão de Qualidade do Projeto Plano de Gestão de Qualidade do Projeto Asseguramento de Qualidade Controlo do Projeto Revisões e Auditorias Resolução de Problema Planos Adicionais 22

5 5 Versão Data N o tabela A/M/D Descrição N o pedido de mudança / figura / parágrafo /11 Par 9 A Adição de novos dados 1 sobre a quali- dade do projeto /12 Todo o Doc M Mudanças referidas 2 pelo professor na avaliação /12 Todo o Doc M Atualização e revisão dos valores 3

6 6 2 VISÃO GLOBAL 2.1 Sumário O projecto baseia-se na realização de um sistema que consiste numa única parte: a ligação entre os switches e a aplicação. A aplicação vai permitir ao utilizador visualizar o histórico de todos os switches e comparar as diferentes configurações de cada um deles Finalidade, Âmbito e Objetivos A aplicação vai comunicar com os switches de forma a armazenar um histórico das configurações de cada um e irá apresentar essa informação ao utilizador através de uma interface. Os dados obtidos a partir dos switches são armazenados num ficheiro de texto simples, sendo que cada configuração é armazenada por um período predefinido de 12 meses, embora esse tempo possa depois ser alterado pelo utilizador. A aplicação deverá criar um registo dos backups efectuados, seja com sucesso ou não, de forma a ser apresentado posteriormente. Caso um backup falhe, será mandado uma notificação por a informar sobre esse facto. Na aplicação o utilizador vai poder visualizar o histórico das configurações dos diferentes switches. Vailhe ser possível pesquisar por switches, filtrar e organizar as pesquisas e visualizar e comparar os resultados obtidos. A pesquisa será possível de ser organizada por data da última alteração, marca/modelo e por ordem numérica e/ou alfabética do nome dos switches Premissas e Restrições A aplicação está limitada pelo facto de existirem diferentes marcas e modelos de switches em funcionamento no DEI, não tendo todos as mesmas funcionalidades, o que limita o acesso às informações por eles fornecidas. Alguns dos switches já têm alguma idade, não permitindo portanto atualização automática das configurações, sendo que isso limita a forma como a informação é obtida de todos eles, considerando que essa informação terá de ser obtida de forma consistente em todos os dispositivos. A variedade de marcas e modelos aplica restrições sobre especificidades da configuração e sobre a compatibilidade desta em caso de alterações nos switches. A aplicação necessita de acesso à rede do DEI, sendo que é por ela que são transmitidas as informações de cada switch, sendo assumido que a rede do DEI tem acesso a todos os switches e que, atraves desta, se consegue deles obter todas as informacoes necessarias de forma pontual e automatica. O armazenamento dos históricos está limitado ao espaço que o Helpdesk tem disponível Artefactos do Projeto Seguidamente elencam-se os artefactos a serem produzidos no âmbito deste projecto, assim como as datas em que estes deverão ser entregues.

7 7 Nome do Artefacto Data de Entrega Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Togg SRS - Documento de Requisitos Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl PMP - Project Management Plan Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl ADD - Architecture and Design Descriptions Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Submissão de ficheiro CSV - Toggl Entrega Final

8 Calendarização e Orçamento Semanas 1 - Definição da equipa e preparação e instalação das ferramentas a serem utilizadas - 40h total Semanas 2, 3 e 4 - Documento de Requisitos - 160h total Semanas 5 e 6 - Project Management Plan - 80h total Semanas 7 e 8 - Architectural Design - 80h total Semanas 9 e 10 - Ambiente de Desenvolvimento e Inicio dos Testes - 80h total Semanas 11 e 12 - Fase de Testes - 80h total Semanas 13 e 14 - Conclusão do Projecto - 80h total 2.2 Evolução do Plano Este documento irá ser gerido como qualquer outro artefacto, sendo dessa forma actualizado periodicamente conforme as necessidades. Servirá também de base para a realização de futuros artefactos. 2.3 Estrutura do Documento a. Secção 1 - Visão Global - Esta secção contém uma descrição detalhada acerca do projeto, do seu âmbito, dos seus objetivos, das suas premissas e restrições. Indica também quais os artefactos e as suas datas previstas de entrega, tal como a descrição da evolução do projeto; b. Secção 2 - Referências - Esta secção contém uma lista de todos os documentos, templates, processos e outras fontes de informação referenciadas no Plano de Gestão de Projeto; c. Secção 3 - Definições - Esta secção contém a explicação de todas as abreviações e acrônimos necessários para entender a totalidade do Plano de Gestão de Projeto; d. Secção 4 - Organização do Projeto - Esta secção identifica interfaces para organizar entidades externas para com o projeto, a estrutura organizacional interna do projeto e a define funções e responsabilidades para o projeto. e. Secção 5 - Gestão do Projeto - Esta secção descreve o planeamento do projeto em si. f. Secção 6 - Processo Técnico - Esta secção descreve o processo técnico do projeto, ou seja, os processos, metodologia e soluções implementadas neste projeto, as técnicas e ferramentas usadas para desenvolver as várias faces do produto, planos para estabelecer e fazer a manutenção da infra-estrutura do projeto. g. Secção 7 - Processos de Suporte - Esta secção descreve processos que estão incrementados para facilitar e controlar os processos mais técnicos do projeto, assim como controlar o estado deste. Estes incluem, entre outros, verificação e validação, documentação, revisões, auditorias, resolução de problemas, gestão do empregador e métodos para assegurar o desenvolvimento, evolução e aperfeiçoamento do projeto em si. h. Secção 8 - Planos Adicionais - Esta secção refere-se ao suporte logistico estratégico a ser aplicado para aumentar a efetividade operacional do sistema.

9 9 3 REFERÊNCIAS Abaixo encontram-se referenciados todos os documentos e standards referidos neste documento. Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Project Management Plans, IEEE Std SyncMasters, Documento de Especificação de Requerimentos V1.0

10 10 4 DEFINIÇÕES DEI - Departamento de Engenharia Informática ECTS - European Credit Transfer and Accumulation System ou Sistema Europeu de Acumulação e Transferência de Créditos SRS - System Requirement Specification ou Especificação de Requerimentos do Sistema - também referido como Documento de Requerimentos PMP - Project Management Plan ou Plano de Gestão do Projecto QP - Quality Planning QA - Quality Assurance QC - Quality Control

11 11 5 ORGANIZAÇÃO DO PROJECTO 5.1 Interfaces Externos Para além dos 5 elementos que estão a realizar o projeto existem como intervenientes externos do projeto: o cliente para o qual o projeto está a ser desenvolvido; os gestões de clientes que lidam diretamente com o cliente devido à impossibilidade de cada grupo lidar diretamente com este (Miguel Martins Duarte, Vasco Bruno dos Santos Gouveia e Pedro Emanuel Sousa) e os professores envolvidos em algumas partes do projeto, nomeadamente na criação dos documentos de requesitos ou de gestão de projeto e na programação em si da aplicação (Mário Alberto da Costa Zenha Rela e Joel Perdiz Arrais). 5.2 Estrutura interna Apesar de divididos por funções específicas todos os elementos estarão envolvidos nas várias funções e fases do projeto Funções Carlos Paiva - Programador Inês Parente - Designer, Gestor de Cliente Mariana Martins - Gestor de Qualidade, Designer Nuno Susana - Programador Líder Rodrigo Carvalho - Gestor de Projeto, Designer Líder Âmbito da Autoridade: Programador Líder, Programador : Desenvolvimento do código. Designer Líder, Designer: Desenvolvimento da interface e layouts. Gestor de Projecto: Gere o desenvolvimento do projeto. Gestor de Qualidade: Gere Qualidade do projeto. Gestor de Cliente: Elo de ligação equipa/cliente Âmbito da Responsabilidade: Programador : Responsável pelo desenvolvimento do código usado no projeto. Designer: Responsável pelo desenvolvimento de layouts, interfaces, elementos gráficos, usabilidade, entre outros. Gestor de Projecto: Responsável pela gestão do projeto de um modo mais geral, tendo uma visão sobre a totalidade de projeto e a atualização dos vários documentos referentes a este. Gestor de Qualidade: Durante a redação dos vários documentos do projeto e da programação do código referente à aplicação, responsável pelo controlo de qualidade de qualquer resultado obtido e da manutenção dessa qualidade. Gestor de Cliente: Elo de ligação de equipa com cliente devido à impossibilidade do contacto entre todos os elementos grupo com o cliente, responsável pelo esclarecimento de dúvidas, caso existentes, com este Responsabilidades Internas: Como responsabilidades internas perceba-se responsabilidades que cada elemento tem consigo próprio, ou seja, reponsabilidades referentes ao trabalho que cada elemento tem, como parte de um projeto maior que depende de todos para ser realizado Responsabilidades Externas: Como responsabilidades externas perceba-se reponsabilidades para fora do grupo, isto é, para com o professor / cliente. O projeto é algo profissional e não pessoal pelo que a sua concretização é um reponsabilidade de todos.

12 12 6 START UP 6.1 Estimativas As estimativas a seguir apresentadas são aquelas calculadas ao efectuar a primeira edição do documento. A reavaliação destas será efectuada periodicamente, de acordo com as datas de cada meta do projecto e/ou caso seja reescrito um documento, ou seja, feita uma nova versão deste. O esforço e tempo gastos serão medidos com recurso a aplicações externas, como o Toggl e posteriormente tratadas e analizadas seja num âmbito individual como colectivo. 6.2 Recursos Humanos A equipa é constituída por 5 pessoas, sendo que 3 pertencem à Licenciatura em Design e Multimédia e os restantes 2 à Licenciatura em Engenharia Informática. De forma geral, o trabalho será dividido de forma igual entre todos os membros da equipa, sendo que algumas tarefas serão delegadas de acordo com as melhores qualidades de cada membro. Assim apesar de todos os elementos estarem ligados a todas as fases e faces do projeto cada elemento tera um foco mais especifico. Numa primeira fase de planeamento e estruturação os elementos de Design e Multimédia estarão a ter um papel mais ativo e decisivo na redação da documentação sendo apoiados pelos restantes elementos quando for necessário tomar decisões de carácter mais técnico. Numa primeira fase de programação, serão as pessoas de Engenharia Informática a tomar as decisões e a orientar o trabalho, que será então distribuído por toda a equipa. 6.3 Aquisição de Recursos Não será necessário neste projeto adquirir qualquer tipo de equipamentos ou serviços externos. 6.4 Treino do Pessoal A maioria das competências necessárias será adquirida no decorrer das aulas de Engenharia de Software, tanto teóricas como práticas. Esta aprendizagem será suplementada individualmente por cada membro da equipa, que irá procurar se informar sobre questões especificas que possam existir. Se necessárias competências extra ao que será adquirido nas aulas os elementos irão procurar adquiri-las noutro material seja este material online ou em livros.

13 13 7 PLANEAMENTO DO TRABALHO 7.1 Planeamento 7.2 Calenderização O projeto teve início dia 19 de Setembro e terá um término a 19 de Dezembro sendo as semanas começadas a contar após a primeira data referida. Planeamento - Semanas 1, 2, 3, 4 Requisitos - 4, 5 Design - 6, 7 Desenvolvimento - 8, 9, 10, 11 Testes - 12, 13 Versão Final Tarefas Os parágrafos seguintes oferecem o actual plano de trabalho para a execução do projecto. 7.4 Budget Tendo em conta o projeto o único budget que tempo é temporal. O projeto está a ser desenvolvido para um cadeira que tem o peso de 6 ECTS. Isto equivale mais ao menos a uma carga de 84 horas gastas por cada elemento do grupo, ou seja, 420 horas de trabalho total. Apesar da carga horária prevista para a cadeira, e tendo em conta a complexidade do projeto total em si, este número de horas gastas teoricamente, pode não ser igual ao gasto na prática. Esse tempo será analisado no decurso do projeto e no fim como já indicado. 7.5 Controlo do Projeto Controlo de requisitos Os parágrafos seguintes oferecem o actual plano de trabalho para a execução do projecto.

14 Schedule Control Os seguintes parágrafos definem a abordagem de gestão para o controlo do plano do projecto ConfiKeeper Schedule Tracking: Abaixo encontram-se os gráficos 3 e 4 que têm por intenção oferecer uma descrição das horas aplicadas ao projecto. O gráfico 3 apresenta as horas aplicadas até agora no projecto (segundo o que foi inserido no Toggl) e a entrega com a qual foram aplicadas, enquanto que o gráfico 4 apresenta essas mesmas horas em comparação com os valores que deviam ter sido alcançados, de acordo com o calculado através dos ECTS, ou seja, 8h x 5 elementos grupo = 40h semanais, para um total de 13 semanas, o que perfaz 520 horas totais Relatório de Execução: A partir dos gráfico 3 e 4 é possível identificar quantas horas por semana o grupo gastou numa determinada tarefa e comprar com as horas previstas dedicadas ao projeto Revisões do Plano: Caso se perceba que o projeto está a fugir excessivamente ao plano inicial, considerando-se para tal que, tidos em conta todos os dados, o projecto está a menos de 70% do proposto, este será revisto como um todo. Isto acontecerá em situações em que tenha passado mais de uma semana sem correspondência com o previsto Monitorização do Progresso: Idealmente os atrasos seriam nulos mas têm tolerância de cerca de uma semana para os elementos do grupo terem um horário mais flexível que se adapte às necessidades de cada um Alteração do Programa: Caso seja necessário alterar o plano do projeto este será decidido de uma forma relativamente democrática. O gestor de projeto irá analisar as várias opções em mesa, discutir as mesmas com todos os membros da equipa e decidir em conjunto com os restantes elementos qual a melhor maneira de lidar com a alteração.

15 Ações Corretivas: Através da análise do EV será claro se a eventual mudança do plano estará a surgir efeito, terá efeito nulo, ou estará a piorar a situação. Mediante essa análise será feito um novo plano ou corrigir-se o anteriormente usado Budget Control O budget do projeto baseiase apenas em tempo gasto dedicado ao projeto. Abaixo no gráfico encontrase exposto a quantidade de horas gastas por cada elemento em cada semana Controlo de Qualidade Nas fases finais do desenvolvimento do projecto, serão realizados diversos testes da aplicação, incluindo o teste de aceitação realizado pelos docentes. Estes testes baseiam-se na funcionalidade da aplicação e de tudo o que a constitui, assim como testes das acções de servidor, para existirem medidas de confiabilidade. Como resultado, pretendemos obter valores de confiabilidade, disponibilidade e tempos de resposta assim como medidas para melhorar a experiência do utilizador, facilitando ouso da aplicação Comunicação e Relatórios do Projecto Repositório: O repositório usado será o:

16 Recolha de Métricas: Serão recolhidas diferentes métricas em relação ao trabalho aplicado no decorrer deste projecto. A primeira será o esforço investido por cada membro da equipa, que será medido através das horas aplicadas no projecto e registadas através do Toggl. Os valores aqui recolhidos serão comparados com o número de horas que se prevê serem gastas com o projecto. Através de um EVM serão medidas e controladas todas as atividades já realizadas e aquelas ainda por realizar. Será também controlado o status de cada artefacto, a ser entregue através de uma simples folha de cálculo. As métricas aqui recolhidas serão comparadas com a calendarização prevista, de forma a aferir se o projecto está a cumprir os intervalos pré-estabelecidos. 7.6 Gestão de Risco Nesta seção tentamos prever os riscos externos ao desenvolvimento do projeto, tais como a não entrega atempada de documentação referente aos switches e a falta de comunicação da parte do cliente. A falta de clareza da informação dada pelo cliente referente ao projeto é também um risco. 7.7 Término do Projeto A entrega final do projecto irá incluir todos os artefactos produzidos até à altura, excluindo os registos semanais do Toggl. Assim, serão entregues todos os documentos realizados assim como o código completo e toda a informação adicional que estiver presente no repositório.

17 17 8 PROCESSO TÉCNICO 8.1 Modelo do Processo Partindo de um modelo de desenvolvimento de waterfall podemos indicar que o processo de desenvolvimento do projecto teve inicio com a identificação dos requerimentos, sendo estes depois definidos. Em seguida deu-se inicio ao planeamento da arquitectura e design da aplicação e, posteriormente, à sua implementação. A etapa seguinte é a de realização de testes para verificar se todas as funcionalidades estão a ser implementadas correctamente e se não existem erros ou bugs. A última fase do projecto, a de manuntenção, seria realizada periodicamente por parte do Helpdesk, caso a aplicação fosse efetivamente utilizada. 8.2 Ferramentas e Técnicas Nas ferramentas usadas, para além dos programas básicos de edição de texto e de código como Sublime Text ou Brackets, serão utilizadas linguagens HTML e CSS para as interfaces, JavaScript e PHP para o lado de cliente e C para o lado de servidor. 8.3 Plano de Aceitação No fim do projeto, e caso as testes de aceitação sejam os mínimos requeridos, a aplicação será aceite. O documento Plano de Aceitação será posteriormente fornecido pelos docentes e anexado a este documento.

18 18 9 PROCESSO DE SUPORTE 9.1 Gestão de Configuração Foi utilizada, como indicado pelo professor, a estrutura do GIT, sendo que todo o projeto estará num repositório para o qual toda a equipa irá contribuir, de forma a haver um melhor controlo de versões. 9.2 Verificação e Validação Independente A verificação e validação do projeto é feita por uma identidade independente ao projeto em si, ou seja, que não tenha feito em qualquer momento parte do projeto. Neste caso podemos dizer que essa entidade independente serão os professores da cadeira. 9.3 Documentação Em termos de documentação tentamos manter os documentos todos semelhantes para facilitar a leitura dos mesmos, sendo que estes são actualizados de tempo a tempo conforme o necessário. 9.4 Garantia de Qualidade Objetivo do QMP O objetivo deste documento ( Quality Management Plan - Plano de Gestão de Qualidade) é documentar a informação necessária para efetivamente gerir a qualidade do projeto desde a primeira fase de planeamento até à fase final de entrega. Este define a política, procedimentos, critérios, papéis, responsabilidades e autoridades dentro do projeto e da equipa. Este documento foi criado durante a fase de planeamento do projeto. O público alvo deste mesmo documento é todo o pessoal envolvido no projeto, desde a equipa do projeto, passando pelos patrocinadores (caso haja) e terminando em qualquer pessoa cujo apoio ao projeto seja fulcral para a sua execução.

19 Visão Global do Plano Gestão de Qualidade do Projeto Organização, Responsabilidades e Papéis: Nome Papel Responsabilidades Carlos Paiva Programador Estar envolvido ativamento no desenvolvimento de todo o código desenvolvido no projeto para a aplicação. Inês Parente Designer/Gestor de Cliente Estar envolvida ativamente no desenvolvimento do design do projeto / Gerir a relação cliente-equipa (que no caso deste projeto é uma relação indireta devido às dificuldades encontradas). Mariana Martins Designer/Gestor de Qualidade Estar envolvida ativamente no desenvolvimento do design do projeto / Garantir a qualidade do projeto em si, fazendo a análise necessária ao mesmo as vezes que forem necessárias. Nuno Susana Programador Líder Liderar o desenvolvimento do código envolvido no projeto e garantir o bom funcionamento da restante equipa de programação. Rodrigo Carvalho Gestor de Projeto/Designer Líder Garantir um desenvolvimento positivo e saudável da equipa e, consequentemente, do projeto em si / Liderar o desenvolvimento do design da aplicação e garantir o bom funcionamento da retante equipa de design Ferramentas, Interfaces e Ambiente: A fase de testes que está planeada até à data não inclui quaisquer ferramentas de software, baseando-se apenas nos testes com pessoas. Após recebermos a informação para os testes de aceitação, essa será a base dos nossos testes Plano de Gestão de Qualidade do Projeto O Plano de Gestão de Qualidade de Projeto envolve o planeamento, desenvolvimento, controlo e atuação para desenvolver e melhorar a qualidade do projeto. Divide-se então o QP em três grupos distintos: QP - Quality Planning, QA - Quality Assureance e QC - Quality Control. Esta secção define como será aplicada cada um destes três grupos ao projeto, para assim definir, monitorizar e controlar as normas de qualidade Planeamento de Qualidade: Nos vários documentos redigidos ao longo da fase de planeamento do projeto foram sendo indicados a qualidade, recursos e funcionalidades mínima que deverão existir no produto final: Documentação: A documentação do projeto será sempre analisada e seguida durante o decorrer do projeto. Se em alguma fase do projeto for necessária uma mudança no desenvolvimento deste, essa mudança deverá ser imediatamente registada e corrigida no(s) documento(s) onde esta for mencionada.

20 20 Testes: Os testes da aplicação em si serão realizados a partir do momento em que haja o mínimo de funcionalidades nesta para garantir a sua efetividade. Se em algum momento dos testes for encontrado um problema este deve ser analisado e posteriormente corrigido. Entregas: Todas as entregas planeadas deverão ser entregues dentro dos prazos existentes. Caso não sejam devem ser o mais rapidamente possível repostas para não por em causa o sucesso do projeto. Funcionalidade do projeto: O projeto deve atingir no mínimo as funcionalidades pedidas. Caso essas funcionalidades sejam atingidas atempadamente à entrega do projeto serão analisadas e adicionadas mais funcionalidades conforme a sua relevância Definir Qualidade do Projeto: Existem pré-requisitos mínimos a serem atingidos para a qualidade do projecto ser considerada aceitável. Entre eles, espera-se que toda a documentação seja completa e detalhada, redigida de acordo com os standards da IEEE. Espera-se também que todas as milestones do projecto sejam entregues dentro dos limites especificados. O projecto deve cumprir todas as funcionalidades estabelecidas por nós como essenciais, sendo que as restantes serão extras agradáveis mas não estritamente necessárias. No que toca aos testes que serão efetuados, espera-se que os resultados neles obtidos caiam dentro de um espectro por nós definido Medir Qualidade do Projeto: Como já foi referido, a qualidade do projecto será medida por quatro variáveis: a documentação, as entregas, os testes e a funcionalidade do projecto. Assim, os requisitos de qualidade variam de acordo com cada uma delas. A documentação deve explicitar toda a informação necessária à compreensão do projecto, sendo que esta deve ser redigida de acordo com os standards da IEEE, apresentando a formatação por este sugerida. As entregas devem todas cumprir os prazos definidos pelos docentes da disciplina de Engenharia de Software. Devem também incluir tudo o que, por esses mesmos docentes, seja pedido, sem falha. No que toca à funcionalidade do projecto, a qualidade será medida através dos diferentes requisitos funcionais alcançados, sendo que para uma avaliação positiva é necessário que as funcionalidades de maior importância, já definidas por nós no Documento de Requisitos deste mesmo projecto, sejam alcançadas. Por fim, espera-se que os resultados obtidos nos testes obtenham os valores que, anteriormente à efectuação destes, sejam alcançados Asseguramento de Qualidade No ponto Controlo do Projeto já são identificados quais os pontos e as ações que são tomadas para garantir que o projeto tem qualidade e está de facto a atingir as metas ideais Analisar Qualidade do Projeto: A partir da experiência adquirida ao longo da redação dos vários documentos e do decurso do projeto tentar eliminar falhas que ainda haja do plano inicial do projeto com o projeto em si Melhorar Qualidade do Projeto: Para melhorar a qualidade do projeto serão identificadas as melhores maneiras e mais produtivas para que o projeto atinja as metas propostas.

21 Controlo do Projeto Durante o desenvolvimento do projecto serão tomadas em atenção as metas a atingir e, periodicamente e conforme o necessário, o projecto será analisado e testado para ver se estas metas, previstas na fase de planeamento, têm sido atingidas. 9.5 Revisões e Auditorias A ser descrito mais tarde. 9.6 Resolução de Problema Quando o grupo se deparar com um conflito interno, este será resolvido internamente tendo em conta o bem do projeto em si. Caberá ao gestor de projeto analisar o problema criado e arranjar a melhor solução para o conflito em conjunto com o resto da equipa. Tendo em conta que a equipa é constituída por 5 elementos, e que, em caso de votação todos serão obrigados a votar positiva ou negativamente, não existe a possibilidade de empate. Assim, a votação será o método escolhido para a escolha da melhor solução apresentada.. ConfiKeeper PMP v2.0, 21 de Dezembro de 2014

22 22 10 PLANOS ADICIONAIS