1. TAP - Termo de Abertura do Projeto
Projeto
AUFE
Descrição
Alternador de Uso de Fonte de Energia - software inteligente que identifica se um dispositivo móvel está usando uma
fonte de energia elétrica, mesmo quando sua bateria está 100% carregada. Isso identificado, automaticamente o
software transfere ao uso da bateria, mesmo se o dispositivo estiver ligado a uma tomada ou base para carregá-lo.
Justificativa
A maioria dos usuários de dispositivos móveis, especialmente de notebooks, tem o costume de usar uma fonte elétrica
para mantê-los funcionando mesmo quando a bateria está 100% carregada e pronta para uso. Isso faz com que a vida
útil da bateria seja prejudicada e diminuida, pois ela não completa um ciclo de vida, que é partir de 100% carregada
para 30% ou 20%. Isso leva a perda de performance e durabilidade da bateria e do aparelho. Atualmente os
dispositivos móveis não possuem nenhum tipo de software inteligente que identifique se a fonte de energia que está
sendo usada é a bateria do prórpio notebook ou uma fonte elétrica. Exatamente para isso que o AUFE foi criado - para
ser sustentável e rentável a longo prazo.
Do ponto de vista econômico, essa identificação preserva a qualidade dos dispositivos (bateria, aparelhos, bases)
assim como a economia de recursos gastos com energia elétrica.
Objetivo S.M.A.R.T.
Descritos de maneira específica, mensurável, alcançável, realista e com datas:
1) Marca: Tornar a marca AUFE referência de mercado, sinônimo de sustentabilidade e a preferida do público
empresarial de tecnologia do Brasil após 1 ano de seu lançamento;
2) Geração de receita: venda do software AUFE através de lojas de aplicativos como Apple Store, Google Play etc.
tanto para empresas como para pessoas físicas. Ter 35% de retorno líquido do capital investido em agosto de 2016;
3) Market Share: mesmo sendo um software mais útil e funcional que os atuais de economia de bateria, vamos usá-los
como referência para alcançar 30% deste mercado em dez/15, 40% em mar/16 e finalmente nos destacar e criar um
novo segmento de mercado.
Requisitos
Geração de valor conquistado no futuro:
1) Tornar-se referência no nosso segmento de mercado;
2) Construir a imagem de uma organização sustentável e preocupada com o melhor uso da energia elétrica;
3) Transformar a marca AUFE sinônimo de economia de recursos financeiros via monitoramento do uso de energia.
Designação
Naf Damasceno foi designado Gerente de Projeto do AUFE. Ele é responsável por assegurar que os requisitos do
cliente sejam satisfeitos e que todos os produtos e serviços cotados ou contratados sejam entregues. Também é
responsável pelo sucesso do projeto e trabalhará próximo aos gerentes funcionais apropriados para assegurar que
todos objetivos do projeto sejam atingidos. Carime Bumaruf será a gestora financeira, Alaíde Herculano a gestora de
marketing, Paulo Ripoli o engenheiro de software e Bruno Castanho o gestor de TI. Esses dois últimos são os
responsáveis pela análise a aprovação de todas as especificações técnicas do AUFE.
Milestones
1) Análise de viabilidade de mercado: Início 30abr15 - Fim 30mai15
2) Desenvolvimento: Início 01jun15 - Fim 01set15
3) Qualificação (Teste e Validação): Início 02set15 - Fim 30nov15
4) Promoção do Produto: Início 01/dez/15 - 01/mar/16
Orçamento
1) Pessoal: R$ 712.526,00
2) Desenvolvimento: R$ 1.548.267,00
3) Marketing: R$ 600.986,00
4) Contingência: R$ 400.000,00

2. Riscos
1) Desistência de integrantes da equipe de desenvolvimento - Risco de média importância.
Caso ocorra desistência de algum integrante, haverá uma sobrecarga de atividades para os demais integrantes, que
terão que ser novamente distribuídas.
2) Perda de qualquer tipo de dados do projeto - Risco de grande importância.
Pode haver perda de dados independente de haver um backup de segurança ou não, já que não há como prever um
incêndio, enchente, roubo, entre outros fatores.
3) Aceitação do software no mercado de soluções de sustentabilidade - Risco de grande importância.
Pode haver uma não aceitação do software no mercado do software ocasionando perda de tempo e dinheiro já que
todo o projeto terá que passar por uma reciclagem.
Data, Assinatura do Sponsor
30/11/-0001 - Aguardando

3. ISH - Registro de Stakeholder Online
Cadastro
Stakeholder Posição Papel no Projeto Email Telefone Celular
Alaide Herculano Gestora de Marketing Membro da Equipe de Projeto alaide81@hotmail.com
Bruno Castanho Gestor de TI Membro da Equipe de Projeto BCastanho@gmail.com
Lionel Messi Contato na empresa contratada empresa@marketing.com.rs
Naf Damasceno Gestor de Suprimentos Gerente do Projeto nafdamasceno@yahoo.com.br
PAULO RIPOLI Engenheiro de Software Membro da Equipe de Projeto paulo.ripoli@gmail.com
carime bumaruf Gestora de Finanças Sponsor do Projeto carime@gmail.com

4. ISH - Registro de Stakeholder Online
Qualificação Requisitos Superficiais Plano de Ação do G.P.
Classificação Outras Caracteristicas Requisitos Superficiais Estrátegia
Gerenciar com atenção Pretende divulgar propagandas do AUFE antes de
novembro 2015, com o argumento de que
aproveitaríamos as vendas do Black Friday e as
pré-vendas de Natal.
Precisa que o cronograma de milestones seja seguido
a risca, sem mudanças em datas de entrega ou
postergações. Espera que a equipe se empenha o
suficiente para terminar o desenvolvimento antes do
prazo calculado.
Ensinar o passo a passo do desenvolvimento técnico
a fim de gerenciar a expectativa alta quanto às
entregas antes do prazo calculado.
Gerenciar com atenção Super experiente em desenvolvimento de software e
hardware. Consciente das capacidades e limitações do
departamento. Acha que podemos atender a todas as
áreas dentro dos prazos estabelecidos.
Anseia por processos de aprovação unilaterais, porém
até agora sem apoio.
Exigir que todos os relatórios contendo resultados
técnicos e de desenvolvimento passe por seu crivo e
aprovação.
Gerenciar com atenção Simpático, porém enrolado. Gosta de marcar reuniões
para visitar o cliente, às vezes sem causa aparente.
Não mostrou-se positivo em fazer entregas antes do
prazo combinado. Deseja máxima compreensão do
depto. financeiro quanto a custos adicionais não
previstos.
Não dar chances de cobranças extras para evitar
choques com a gestora financeira.
Gerenciar com atenção Cobra diariamente as entregas de cada área e para
isso mantém a melhor equipe de porfissionais. Não
aceita postergações sem aviso prévio de 2 semanas e
aprovação do conselho.
Quer a todo custo manter a lista de milestones para
evitar choques e conflitos entre os outros stakeholders
do projeto.
Visita surpresa a todas as áreas diariamente. Se ver
algo que não aprova, marcar reunião de 15 minutos
com o gestor responsável.
Gerenciar com atenção Ótima relação interpessoal com a equipe e com TI.
Trabalham juntos sem grandes problemas. Detalhista e
exigente com todos.
Gerenciar expectativas é sem maior desafio, já que
grande parte dos pacotes de trabalhos, entregas e
relatórios sobre o desempenho do software sairá de
sua área.
Acompanhar caso a caso, entrega a entrega a fim de
manter todo o restante da equipe bem informado sobre
todas suas tarefas realizadas e aceitas.
Gerenciar com atenção Têm foco e prioridade absoluta sobre receita e
otimização de gastos.
Quer entrevistar cada empresa de pesquisa de
mercado que participará da licitação inicial. Necessita
de uma proposta técnico-comercial detalhada com
possíveis gastos adicionais.
Informar todo resultado alcançado dentro do
orçamento aprovado e marcar reunião para resultados
que necessitarão de maior orçamento.

5. WBS - Estrutura de Decomposição do Trabalho
Descomposição
C.C. Fase / Subfase / Pacote de Trabalho Análise M/B
1 Análise
1.1 Relatório de viabilidade de mercado Buy
1.2 Método de modelagem Make
2 Definição de Requisitos
2.1 Definição requisitos funcionais e não-funcionais Make
2.2 Definição design e arquitetura Make
2.3 Definição de infraestrutura Make
3 Desenvolvimento
3.1 Definição da metodologia Make
3.2 Ferramentas Make
3.3 Codificação/Programação Make
3.4 Testes Iniciais Make
3.5 Correções Iniciais Make
4 Implantação
4.1 Piloto em ambiente de produção Make
4.2 Turn Key (entrar em produção) Make
5 Operação Assistida
5.1 Suporte aos clientes iniciais Make
5.2 Mudanças e updates referentes a desenvolvimento Make

6. D-WBS - Dicionário WBS Fase : Análise
C.C. Pacote de Trabalho Descrição Entrega do PT Critério de Aceitação OK
1.1 Relatório de viabilidade de
mercado
Relatório onde é demonstrado qual a demanda que
o software possa ter ao ser disponibilizado nas lojas
virtuais, Google Play, Apple Store, entre outras.
Relatório de viabilidade de mercado em
formato eletrônico
Pagamento da parcela condicionada a
entrega do relatório
Aguardando
1.2 Método de modelagem Documento de demonstra quais os tipos de
modelagem disponíveis para desenvolvimento do
software
Relatório com os tipos de modelagem
disponiveis
Assinatura no relatório Aguardando

7. D-WBS - Dicionário WBS Fase : Definição de Requisitos
C.C. Pacote de Trabalho Descrição Entrega do PT Critério de Aceitação OK
2.1 Definição requisitos funcionais e
não-funcionais
F: relatório com cálculos, detalhes técnicos,
manipulação de dados e de processamento e outras
funcionalidades específicas.
NF: Uso da aplicação em termos de desempenho,
usabilidade, confiabilidade, segurança,
disponibilidade, manutenibilidade e tecnologias
envolvidas.
Conjunto de entradas, seu
comportamento e as saídas.
Aprovação TI e Engenharia de software Aguardando
2.2 Definição design e arquitetura Sistemas de biblioteca e gerenciamento de
conteúdo. Possível desenvolvimento web, interações
de usuários, desenvolvimento de banco de dados e
programação.
Relatório eletrônico Aprovação TI e Engenharia de software Aguardando
2.3 Definição de infraestrutura Critérios de disposição da rede de cabos que
suporte o servidor do AUFE e outros hardwares que
venham a ser acrescentados.
Plano de cabeamento e rede Aprovação TI e Engenharia de software Aguardando

8. D-WBS - Dicionário WBS Fase : Desenvolvimento
C.C. Pacote de Trabalho Descrição Entrega do PT Critério de Aceitação OK
3.1 Definição da metodologia Após análise junto aos programadores, deve-se
elaborar o relatório explicando e demonstrando os
critérios adotados para a escolha do método
Relatório informativo sobre a
metodologia adotada
Aprovação eletrônica Aguardando
3.2 Ferramentas Para o desenvolvimento do software é necessário a
aquisição de programas específicos para
desenvolver o software para as plataformas
existentes no mercado
Programas necessário para o
desenvolvimento do software inta
Registro dos programas Aguardando
3.3 Codificação/Programação Os arquivo eletrônicos serão armazenados no
sistema de controle e versionamento de softwares.
Arquivos eletrônicos do software AUFE Aprovação eletrônica dentro no sistema
de versionamento
Aguardando
3.4 Testes Iniciais O roteiro de teste consiste em atividades que devem
ser conduzidas na operação do software, sendo
seus resultados anotados nesse roteiro
Roteiro de teste com o parecer de cada
teste efetuado
Roteiro com o status de finalizado
identificado
Aguardando
3.5 Correções Iniciais Nesse relatório deverá conter, todos os erros
encontrados e quais foram a correções para eles,
deve ser apontado também as melhorias
implementadas após o feedback dos testes
Relatório de correções e melhorias
implementadas
Aprovação eletrônica Aguardando

9. D-WBS - Dicionário WBS Fase : Implantação
C.C. Pacote de Trabalho Descrição Entrega do PT Critério de Aceitação OK
4.1 Piloto em ambiente de produção Análises de dados, velocidade, gráficos,
personalização, relatórios programados e tempo
empregado em cada tarefa.
Relatório de desempenho e performance Aprovação TI e Engenharia de software Aguardando
4.2 Turn Key (entrar em produção) Integração de todas as partes em ambiente de
produção
Rodar o software completo Não deve haver nenhuma mensagem de
erro
Aguardando

10. D-WBS - Dicionário WBS Fase : Operação Assistida
C.C. Pacote de Trabalho Descrição Entrega do PT Critério de Aceitação OK
5.1 Suporte aos clientes iniciais Somente os 15 primeiros clientes poderão participar
desta operação assistida.
Atendimento online Solução do problema trazido pelo cliente Aguardando
5.2 Mudanças e updates referentes a
desenvolvimento
Só haverá lançamento de update se houver
problemas relativos ao desenvolvimento do software
Pacote de melhorias ou consertos Aprovação pelo engenheiro responsável Aguardando

11. Fluxograma de Iniciação

12. Fluxograma de Planejamento

13. Fluxograma de Execução

14. Fluxograma de Monitoramento & Controle

15. Fluxograma de Encerramento