PMBOK

TAD0028 - Planejamento e Gerência de Projetos

Iniciação e Planejamento

FASE DE INICIAÇÃO

● TERMO DE ABERTURA DE PROJETO

● IDENTIFICAÇÃO DAS PARTES INTERESSADAS

Sugestão: utilizar o Documento de Visão e Escopo

Documento único

Permite apresentar quase todos os pontos tratados na Fase de Iniciação, ficando

faltando apenas Investimento e Aprovação de documentos, elementos que podem
ser adicionados à documentação.

Modelo de Documento de Visão e Escopo abaixo:

1
Documento de visão e escopo
Sistema para reserva de salas de laboratório
─

1. Requisitos de Negócio
1.1. Background
[Que processo será melhorado, como ele é feito hoje]
No prédio da Informática da Escola Agrícola de Jundiaí, temos 3 laboratórios de
informática, 1 sala teórica e 1 sala de monitoria. Essas salas e laboratórios podem ser
utilizadas para as aulas normais dos cursos de Análise e Desenvolvimento de Sistema e do
Técnico de Informática, e também por aulas extras e para alunos que desejam estudar em
horários extras. Visto que no prédio da Informática temos apenas 1 servidor para fazer
este controle, o modelo escolhido por ele foi o de fazer o controle em um papel, anotando
as reservas que tinham sido feitas, e comparando se o laboratório já não estava sendo
usado neste horário. Para fazer essa reserva, os alunos devem ir presencialmente falar
com o funcionário do prédio. Com isso, há uma grande possibilidade de número de
reservas erradas e conflitantes.

1.2. Oportunidade de Negócio

[Que oportunidade temos aqui, e qual a solução]
O servidor do setor da Informática sugeriu o uso de um sistema computacional que
permitisse um acesso mais simples às reservas de sala já feitas, além de um sistema mais
eficaz e seguro para a realização das reservas. A sugestão dele é que as reservas sejam
feitas também online, pelos próprios alunos, ficando para o servidor apenas confirmá-las.
Esse sistema permitiria um aproveitamento melhor dos espaços do prédio da Informática.

1.3. Objetivos de Negócio

[Especificar o que pretendemos atingir, em função de métricas.]
ON-1: Reduzir o tempo para realização de reserva para 20 segundos.
ON-2: Aumentar o número de reservas em 50% no primeiro semestre.

1.4. Métricas de Sucesso

2
[Medidas de qualidade.]
MS-1: 90% dos usuários conseguem realizar uma reserva sem a ajuda do servidor.
MS-2: O número de reservas em conflito é 0.

1.5. Declaração de Visão

[Para … que … o … é … que … Ao contrário de … o SISTEMA ...]
Para funcionários do prédio da informática e alunos do TADS e do Técnico de Informática
da EAJ/UFRN que desejam reservar salas do prédio, o Sistema para Reserva de Salas de
Laboratório é um sistema web que permitirá a reserva das salas do prédio da informática
de forma online e sem conflitos. Ao contrário do atual sistema de controle em planilhas e
papéis, os usuários do Sistema de Pedidos de Refeitório poderão fazer a reserva mais
rápido e sem chance de conflito de horários.

1.6. Riscos de Negócio

[Riscos de Negócio]
RIS-1: Os espaços podem mudar de capacidade, com a aquisição ou remoção de cadeiras.
(Probabilidade = 0,6; Impacto = 9)
RIS-2: Os alunos podem fazer um número muito grande de reservas, em um período
grande. (Probabilidade = 0,3; Impacto = 3)

1.7. Regras de Negócio e Dependências

[Regras de Negócio e dependências de outros sistemas]
REG-1: Não é possível fazer reservas em um dia em que o laboratório já está totalmente
lotado.
REG-2: Reservas de professores para turmas compõem todo o laboratório.
DEP-1: Não há relação dele com as turmas cadastradas no sigaa.

2. Escopo e Limitações
2.1. Funcionalidades Principais
[Requisitos funcionais]
RF-1: Realizar o agendamento de salas para turmas.
RF-2: Realizar o agendamento individual para salas.
RF-3: Visualizar a situação de agendamento das salas.

3
RF-4: Cadastrar alunos para realizar o agendamento de salas.
RF-5: Manter as salas do prédio atualizadas no sistema.

2.2. Escopo dos Releases

[Planejamento de releases, e funcionalidades que serão entregues em cada um deles.]
Funcionalidade Release 1 Release 2

RF-1: Realizar o Totalmente implementada

agendamento de salas para
turmas

RF-2: Realizar o Não implementada Totalmente implementada

agendamento individual
para salas

RF-3: Visualizar a situação Visualização de Visualização de

de agendamento das salas agendamento por turmas agendamentos individuais -
Totalmente implementada

RF-4: Cadastrar alunos para Totalmente implementado

realizar o agendamento de
salas

RF-5: Manter as salas do Criação, visualização, Edição de salas -

prédio atualizadas no listagem e deleção de salas Totalmente implementada
sistema

2.3. Limites e Exclusões

[As limitações do sistema, e o que iria ter nele, mas que foi retirado (exclusões).]
LI-1: A reserva deve ser confirmada pelo funcionário responsável pelo prédio.
LI-2: Um usuário não pode reservar individualmente uma sala para outra pessoa.
EX-1: ???

3. Contexto de Negócio
3.1. Perfil dos Interessados
[As pessoas interessadas no sistema, os que pediram o sistema e os que vão utilizá-lo.]

Interessado Valor principal Atitudes Principal Restrições

4
 interesse

Professores Facilitar a Alto Marcar aulas Não

reserva de comprometimento extras de forma identificadas
salas para mais fácil
aulas extras

Funcionário Melhor uso do Medo de Realização de suas É necessário

do prédio seu tempo; demissões, mas atividades de o acesso a
redução de empolgado forma mais internet
erros em simples
reservas

Alunos Maior uso dos Receptiva, mas Chance de utilizar Dúvidas com
espaços do com medo mais as relação a
prédio instalações do algumas
prédio limitações do
sistema

3.2. Prioridades do Projeto

[Quais as prioridades nos 3 requisitos em questão.]
Dimensão Restrição Condução Grau de liberdade

Funcionalidade Todos os recursos Podem ser

programados para o alteradas, conforme
release 1.0 devem necessidade
estar totalmente
operacionais

Qualidade 95% dos testes de Testes unitários

aceitação do usuário devem ser feitos
devem ser para garantir REG-1
aprovados e REG-2

Cronograma O sistema deve ser

totalmente
desenvolvido antes
de 28/03/2022

Custo Orçamento
excedido em até
15% aceitável sem
revisão do
patrocinador

Equipe O tamanho da

5
 equipe é: gerente de
projeto de meio
período, 3
desenvolvedores e 1
testador;
desenvolvedor
adicional e testador
de meio período
disponível, se
necessário

3.3. Consideração para Deploy

[Como será feito o Deploy.]
O software do servidor web precisará ser atualizado para a versão mais recente. Qualquer
mudança de infraestrutura correspondente deverá estar em vigor no momento do
segundo lançamento. Vídeos com não mais de cinco minutos de duração devem ser
desenvolvidos para treinar os usuários.

6
FASE DE PLANEJAMENTO

PLANO DE GERENCIAMENTO DO PROJETO

1) Escopo

Vamos definir o escopo através de reuniões via Google Meet com o cliente.

No primeiro dia do mês, teremos reunião com o cliente para apresentar o que foi
feito até então, e definir possíveis mudanças nos requisitos do sistema.

Toda documentação feita sobre escopo deve ser aprovada pelos clientes.

O cliente deve participar das reuniões de priorização de requisitos.

2) Cronograma

Vamos utilizar o Trello para manutenção do calendário.

O gerente de projetos deve utilizar esse sistema para descrição das atividades, e
consequente criação do cronograma (por sprint).

As definições dos releases do sistema (feitas na iniciação do projeto) devem ser

utilizadas como base para a definição dos cronogramas. Mudanças nos releases
devem ser aprovadas pelo cliente.

3) Custos

O orçamento do sistema deve ser gerenciado pelo GP, feito em conjunto com o dono
da empresa. Alterações no orçamento devem ser discutidas com SM para tomada de
decisões.

Serão discutidos as noções de custo referentes a pessoal levando em consideração o

histórico de projetos anteriores.

4) Qualidade

Utilizaremos o TDD, com testes unitários feitos diariamente. O próprio desenvolvedor

da funcionalidade deve criar os casos de teste. Dúvidas sobre a funcionalidade
devem ser discutidas antes da criação do teste.

7
Casos de testes devem englobar apenas funcionalidades que envolvam análise de
dados ou buscas complexas com 2 ou mais tabelas.

Realizaremos testes de validação e aceitação mensalmente com o cliente (com os 3

perfis de Partes Interessadas).

5) Recursos

O GP irá definir os perfis de pessoal que serão necessários para compor a equipe,
considerando os limites orçamentários existentes.

6) Comunicação

Comunicação com a equipe será feita via email institucional, que deve ser olhado
diariamente em dias de trabalho.

Comunicação com o cliente será feita via grupo de whatsapp, e toda tomada de
decisão deve ser enviada e confirmada por email.

7) Riscos

A lista inicial de riscos será feita pelo GP juntamente com 3 desenvolvedores, levando
em consideração também as tabelas de risco de projetos anteriores.

O GP deverá analisar semanalmente a lista, para atualizar dados, se necessário. O

mesmo será responsável por propor reuniões caso seja necessário para tomar
medidas sobre mudanças ou adaptações no projeto.

8) Aquisições

Não serão necessárias.

9) Partes interessadas

Será criado um grupo de whatsapp com o GP e as partes interessadas do projeto.

Nele, devem ser dadas informações semanalmente ao cliente para indicar como
anda o projeto.

Sugestões sobre mudanças são melhor aceitas na reunião de apresentação mensal.

Toda comunicação formal será feita por email.

8
ESCOPO

● Coletar os requisitos
● Definir o escopo
● Criar a EAP

2) Coletar os requisitos

Foi atualizado o Documento de Visão e Escopo com essas informações.

3) Definir o escopo

Foi atualizado o Documento de Visão e Escopo com essas informações.

4) Criar a EAP

CRONOGRAMA

9
 ● Definir as atividades
● Sequenciar as atividades
● Estimar as durações das atividades
● Desenvolver o cronograma

2) Definir as atividades
RF-1: Realizar o agendamento de salas para turmas
AG.1: Modelar o banco para AGENDAMENTO
AG.2: Checar se não há agendamento individuais ou de turma para o dia/horário
AG.3: Realizar o agendamento para turma
AG.4: Criar Front-end para agendamento de turmas
AG.5: Editar/Deletar agendamento
AG.6: Criar Front-end para editar/deletar agendamento
RF-2: Realizar o agendamento individual para salas
AG.7: Realizar o agendamento individual
AG.8: Criar Front-end para agendamento individual
RF-3: Visualizar a situação de agendamento de salas
AG.9: Listar agendamento de salas
AG.10: Criar Front-end para listagem de agendamentos
RF-4: Cadastrar alunos para realizar o agendamento de salas
USU.1: Modelar o banco para USUÁRIOS
USU.2: Funcionalidade de criar usuário
USU.3: Criar Front-end para criação de usuários
USU.4: Funcionalidade para desabilitar usuários
USU.5: Criar Front-end para desabilitar usuários
USU.6: Funcionalidade de login
USU.7: Criar Front-end para login
USU.8: Funcionalidade de "esqueceu sua senha"
USU.9: Criar Front-end para "esqueceu sua senha"
USU.10: Funcionalidade de listar usuários
USU.11: Criar Front-end para listar usuários
RF-5: Manter as salas do prédio atualizadas no sistema
SALA.1: Modelar o banco para SALAS
SALA.2: Funcionalidade de criar sala
SALA.3: Criar Front-end para criação de salas
SALA.4: Funcionalidade de editar/deletar sala
SALA.5: Criar Front-end para editar/deletar salas
SALA.6: Funcionalidade de listar salas
SALA.7: Criar Front-end para listar salas

10
3) Sequenciar as atividades

4) Estimar as durações

5) Desenvolver o cronograma

11