DESENVOLVIMENTO DE SOFTWARES PARA TERMINAIS MÓVEIS

TAP - Termo de Abertura do ProjetoProjeto

DESENVOLVIMENTO DE SOFTWARES PARA TERMINAIS MÓVEISDescrição

Desenvolvimento do software embarcado a partir do sistema operacional Android para terminais de telecomunicaçõesmóveis (smartphones ou tablets) de acordo com os requisitos comerciais pré-estabelecidos com as operadoras detelecomunicações móveis brasileiras, o time comercial da empresa e de regulamentações do mercado.

JustificativaO crescimento do uso de smartphones e tablets pela população brasileira tem sido constante nos últimos anos. Paraadequar aos anseios dos consumidores brasileiros, bem como às necessidades das operadoras e das agênciasregulatórias é necessário o desenvolvimento de um software específico para o mercado brasileiro, onde serãocontemplados os requisitos necessários. Além disso, o desenvolvimento de um software local dará vantangensestratégicas à empresa tais como isenção de impostos de fabricação e capacitação técnica do time dedesenvolvimento.

Objetivo S.M.A.R.T.Desenvolver um software embarcado para dispositivos móveis (smatphones ou tablets) com o sistema operacionalAndroid da Google de acordo com os requisitos de mercado coletados pelo time comercial com as operadoras detelecomunicações brasileiras, bem como os requsitos de agências regulatórias governamentais. Tal software deveráser embarcado posteriormente nos dispositivos móveis durante processo fabril, o que não está contemplado nesteprojeto.

Requisitos- Atender requisitos regulatórios da Anatel conforme normas 3GPP;- Atender requisitos comerciais conforme documento de requisitos - Requisitos Comerciais;- Atender requisitos das operadoras brasileiras (Vivo, Claro, Oi e TIM) conforme documento - Requisitos dasOperadoras;

DesignaçãoTBD

Milestones- Entrega do Termo de Abertura - Semana 01- Entrega do Plano de Gerenciamento do Projeto - Semana 02- Recebimento de protótipos - Semana 02- Fase de design de software completa - Semana 05- Inicio da fase de verificação - Semana 08- Inicio da fase de homologação - Semana 10- Fim da fase de homologação - Semana 12- Término dos testes internos e entrega de aprovação de qualidade interna - Semana 12- Entrega do software finalizado para produção - Semana 13

OrçamentoPara este projeto, para cada versão de software desenvolvida, teremos um orçamento (em alto nível) de $100.000,00além das despesas internas de RH detalhadas no plano de gerencimento de pessoas do projeto.

RiscosAbaixo a documentação em algo nível de alguns riscos do projeto. Os riscos detalhados, bem como suas respostasestão detalhados no Plano de Gerenciamento de Riscos.- Atraso no recebimento dos protótipos;- Atraso na coleta de requisitos;- Impossibilidade de completar os testes internos de qualidade;- Falta de recursos nas operadoras para início das homologações conforme cronograma;- SW não estável suficiente durante fases de teste e verificação;

- Falta de material na fábrica para inicio da produção;- Mal dimensionamento do time de codificação;- Falta de suporte para problemas de HW ou com terceiros.

Data, Assinatura do Sponsor14/01/2015 - Aprovado

ISH - Registro de Stakeholder Online

CadastroStakeholder Posição Papel no Projeto Email Telefone Celular

José Marcel Berto de Souza Membro da Equipe de Projeto [email protected]

MARCELO DE CASTRO

ALBELLA

Gerente de Projeto [email protected]

Paulo Oliveira Neto Gerente Técnico Sponsor do Projeto [email protected]

thiago sampaio milani Membro da Equipe de Projeto [email protected]

WBS - Estrutura de Decomposição do TrabalhoDescomposição

C.C. Fase / Subfase / Pacote de Trabalho Análise M/B1 Requisitos

1.1 Requisito de Mercado Make

1.2 Requisitos de Operadora Make

1.3 Requisitos Internos Make

2 Codificação2.1 Integração da Build Make

2.2 Revisão de Código Make

2.3 Grupos Técnicos2.3.1 Multimídia Make

2.3.2 Mensagens Make

2.3.3 Browser Make

2.3.4 System Make

2.3.5 Protocolo Make

2.3.6 Interface Homem-Máquina Make

3 Testes3.1 Testes de Desenvolvimento

3.1.1 Unit Test Make

3.1.2 Testes "Caixa-Preta" Make

3.2 Quality Assurance3.2.1 Testes de Campo Buy

3.2.2 Testes de UI Make

4 Homologação4.1 Operadora "V"

4.1.1 Documentação de "V" Make

4.1.2 Testes de Homologação - "V" Buy

4.2 Operadora "C"4.2.1 Documentação de "C" Make

4.2.2 Testes de Homologação - "C" Buy

4.3 Operadora "T"4.3.1 Documentação de "T" Make

4.3.2 Testes de Homologação - "T" Buy

4.4 Operadora "O"4.4.1 Documentação de "O" Make

4.4.2 Testes de Homologação - "O" Buy

5 Documentação5.1 Manual do Usuário

5.1.1 Tradução do Manual Buy

5.1.2 Diagramação do Manual Make

5.2 Matriz de Funcionalidades Make

5.3 Certificado Anatel Make

6 Gerenciamento6.1 Planejamento

6.1.1 Plano de Gerenciamento de Aquisições Make

6.1.2 Orçamento Make

6.1.3 Cronograma Make

6.2 Execução6.2.1 Conduzir Aquisições Make

6.2.2 Recursos Humanos Make

6.3 Monitoramento e Controle

6.3.1 Controlar Aquisições Make

6.3.2 Controlar Qualidade Make

6.4 Encerramento6.4.1 Encerrar Aquisições Make

6.4.2 Encerramento do Projeto Make

RR - Registro de RiscoId Categoria na RBS Risco Identificado Tipo Data de

RegistroQualitativoProbabilidade

P Qualitativo deImpacto

I Semáforo

71

0

W>Riscos técnicos>Riscos

específicos da tecnologia

Se a rede da operadora sob teste estiver

indisponível o prazo de entrega dos resultados

poderá atrasar.

Ameaça 14/1/2015 Média 0.5 Média 0.2 0.10

71

1

W>Riscos

técnicos>Complexidade do

projeto

Se o software a ser testado não ficar pronto até a

data planejada não será possível cumprir o

cronograma de testes.

Ameaça 14/1/2015 Média 0.5 Grande 0.4 0.20

71

2

W>Riscos técnicos>Protótipo Se os protótipos a serem usados nos testes

ficarem retidos na alfandega, os testes não

poderão ser iniciados.

Ameaça 14/1/2015 Provável 0.7 Grande 0.4 0.28

71

3

W>Riscos

legais>Reclamações contra

terceiros

Se o fornecedor não puder disponibilizar

engenheiros nos dias solicitados o inicio dos testes

será atrasado.

Ameaça 14/1/2015 Improvável 0.3 Grande 0.4 0.12

71

4

W>Riscos

técnicos>Complexidade do

projeto

Se os engenheiros do fornecedor não forem

experientes em testes de campo o término do ciclo

de testes poderá ser atrasado.

Ameaça 14/1/2015 Improvável 0.3 Grande 0.4 0.12

71

5

W>Externos

imprevisíveis>Desastres da

natureza

Se a rota estiver indisponível em algum dos dias de

testes por motivo de força maior como algum

acidente ou inundação, o final do ciclo será

atrasado.

Ameaça 14/1/2015 Provável 0.7 Grande 0.4 0.28

RR - Registro de RiscoV.M.E. antes daresposta [R$]

Resposta V.M.E. depois daresposta [R$]

Sinal de alerta Proprietário Ação a tomar

71

0

1.000,00 Mitigar 0,00 Acompanhar funcionamento da

rede durante os testes. Caso

testes básicos de sanidade não

puderem ser executados em

protótipos de referência há

indícios que a rede está

indisponível.

JosÃ© Marcel Berto de

Souza

Aprovar hora extra para o fornecedor continuar o

teste por mais tempo durante aquele dia.

71

1

2.000,00 Mitigar 1.000,00 Verificar se SW está estável

suficiente no marco "Product

Verification Readiness" através de

testes internos.


Souza

Alocar pessoas de outros times para completar o

desenvolvimento a tempo da fase de testes de

campo.

71

2

3.000,00 Aceitar 1.500,00 Acompanhar através do número

de rastreamento para saber se os

protótipos foram retidos.

MARCELO DE

CASTRO ALBELLA

Contratar despachante aduaneiro para facilitar a

liberação dos protótipos.

71

3

1.000,00 Mitigar 0,00 Agendar e pedir comprometimento

formal do fornecedor ao menos 3

dias antes de iniciar o ciclo de

teste.

Paulo Oliveira Neto Alocar time interno para testes de campo.

71

4

1.000,00 Mitigar 0,00 Acompanhar relatórios parciais ao

final de cada dia e comparar com

desempenho esperado. Tomar

ação caso desempenho seja

abaixo de 75% em relação ao

esperado.

thiago sampaio milani Abrir uma disputa referente a multa presente no

contrato em caso de atraso por falta de capacidade

técnica do time do fornecedor.

71

5

1.000,00 Mitigar 200,00 Acompanhar o estado da rota

escolhida logo de manhã para

saber se ela está disponível ou

não.


Souza

Mudar planejamento diário para que se execute os

testes em outra rota naquele dia.

PGA - Plano de Gerenciamento das Aquisições

O PGA - Plano de Gerenciamento das Aquisições é um componente do PGP - Plano de Gerenciamento do Projeto quedescreve como a equipe do projeto adquirirá produtos e serviços fora da organização executora. Ele descreve como osprocessos de aquisição serão gerenciados, do desenvolvimento dos documentos de aquisições ao fechamento docontrato.

Um PGA - Plano de Gerenciamento das Aquisições deveria conter:

Tipos de contratos a serem usados;

Questões de gerenciamento dos riscos;

Se serão usadas estimativas independentes e se elas são necessárias como critérios de avaliação;

As ações que a equipe de gerenciamento de projetos pode adotar unilateralmente, caso a organização executora tenhaum departamento estabelecido de aquisições, contratos ou compras;

Documentos padronizados de aquisição, caso necessários;

Gerenciar vários fornecedores;

Coordenar as aquisições com outros aspectos do projeto, como cronogramas e relatórios de desempenho;

Quaisquer restrições e premissas que poderiam afetar as aquisições planejadas;

Lidar com o longo tempo de espera necessário para comprar alguns itens dos fornecedores e coordenar o tempo extranecessário para adquirir esses itens, com o desenvolvimento do cronograma do projeto;

Lidar com as decisões de fazer ou comprar e vinculá-las aos processos Estimar os recursos das atividades eDesenvolver o cronograma;

Definir as datas agendadas em cada contrato para os resultados e coordená-las com os processos de desenvolvimentoe controle do cronograma;

Identificar os requisitos de obrigações de realização ou contratos de seguros para mitigar algumas formas de riscos doprojeto;

Estabelecer a orientação a ser fornecida aos fornecedores para desenvolvimento e manutenção de uma WBS;

Estabelecer a forma e o formato a serem usados para as especificações do trabalho de aquisições/contratos;

Identificar fornecedores pré qualificados para sem usados;

Métricas de aquisições a serem usadas para gerenciar contratos e avaliar fornecedores.

O PGA - Plano de Gerenciamento das Aquisições pode ser formal ou informal, altamente detalhado ou amplamenteestruturado, e é baseado nas necessidades de cada projeto.

MA - Mapa de AquisiçõesConcorrência Item(s) a ser contratado Ref.WBS Fornecedores Orçamento Prazo Critérios MAKE OR BUY ultilizados Tipo de

contrato969 Testes > Quality Assurance

> Testes de Campo

3.2.1 Tech Master Tests

Full Max Tests

LabTech -

Laboratório de

Testes

Gwonseon -

Laboratório de

Testes

20.000,00 13/02/2015 Capacidade (quantidade e qualidade) da equipe

Existência de fornecedores confiáveis.

Necessidade de fornecimento especializado

O core business da empresa

Custo

Reembolsável

970 Homologação > Operadora

"V" > Testes de

Homologação - "V"

4.1.2 50.000,00 27/03/2015 Existência de fornecedores confiáveis.


Problemas legais ou de segurança da informação

Contratação requerida pelo cliente

Preço Fixo


"C" > Testes de

Homologação - "C"


Full Max Tests

LabTech -

Laboratório de

Testes





Problemas legais ou de segurança da informação

Preço Fixo


"T" > Testes de

Homologação - "T"


Full Max Tests

LabTech -

Laboratório de

Testes






Preço Fixo


"O" > Testes de

Homologação - "O"


Full Max Tests

LabTech -

Laboratório de

Testes

Gwonseon -

Laboratório de

Testes






Preço Fixo

974 Documentação > Manual do

Usuário > Tradução do

Manual

5.1.1 Lion Traduções

LIve Moment

Traduções

Técnicas

Focus Mind

Traduções




Restrições de prazo

Tempo e Material

MA - Mapa de Aquisições

RFP - 969

3.2.1 Testes > Quality Assurance > Testes de Campo

DT - Declaração de TrabalhoEspecificação Quantidade Unidade

Quantidade de Testes por Ciclo (minimo) 3000 Casos de Teste

Horas de Teste (minimo) 8 horas por dia

Relatórios por Ciclo (minimo) 2 relatórios por ciclo

Duração do Ciclo (máximo) 3 dias

Rota de Teste (máximo) 2 quilômetros

PrazosA atividade de testes de campo deverão ocorrer em ciclos sucessivos durante o desenvolvimento do software doterminal móvel. Desta forma, todos os ciclos devem ser entregues conforme planejado dentro de 3 dias após adisponibilização do software de teste.

Qualidade RequiridaTodos os testes planejados devem ser executados dentro do prazo e seus resultados (PASSADO ou FALHADO)deverão ser reportados com acurácia a fim de evitar problemas futuros durante os testes de homologação do cliente.Os casos de testes marcados como FALHADOS deverão possuir uma NOTIFICAÇÃO DE DEFEITO correspondenteaberta em ferramenta de gerenciamento adequada indicando como o problema pode ser reproduzido ao time dedesenvolvimento para correção. O time de testes deve investigar os casos de falha antes de abrir uma notificação dedefeitos a fim de evitar abertura de defeitos não válidos. Ao final do último ciclo do processo a meta é termos zerodefeitos críticos que possam impedir a homologação do software do produto.

Suporte TécnicoOs times de técnicos de desenvolvimento irão prover suporte técnico durante as atividades de testes, debug,investigação e re-testes.

Treinamento DesejadoÉ mandatório que o time de testes do fornecedor tenha treinamento em tecnologia celular 2G, 3G e 4G, bem como emprocessamento de chamada e comportamento das redes celulares móveis. Também será necessário treinamento nostipos de chipset de hardware dos dispositivos móveis a fim de facilitar a coleta e análise de logs durante os testes.Assume-se que o fornecedor irá prover os treinamentos necessários aos seus funcionários, não sendo escopo destaaquisição.

Nivel ServiçoO fornecedor deverá acompanhar o ciclo de vida das NOTIFICAÇÕES DE DEFEITO abertas na ferramenta até o seufechamento. Também se pressupõe que o fornecedor irá executar ciclos de re-teste assim que novas versões dosoftware estejam disponíveis até que o mesmo seja aprovado para a fase seguinte.

GarantiaO fornecedor deverá garantir que todos os casos e rotas de testes exigidos no contrato serão cumpridos dentro doprazo estipulado.

Local EntregaOs relatórios parciais e final deverão ser entregues por e-mail assim que os ciclos forem finalizados. Os relatórios dedesempenho deverão ser entregues por e-mail e também por via impressa na sede da empresa.

DT - WBS do ContratoC.C. Fase / Pacote de Trabalho Unidade Quantidade

PlanejadaOrçamento

1 Plano de Testes 7.000,001.1 Especificações Testes 3000 1,00

1.2 Casos de Teste Testes 3000 1,00

1.3 Rotas de Teste km 2 1.000,00

1.4 Execução dos ciclos Horas por Dia 8 5.998,00

2 Relatórios 3.000,002.1 Relatórios de Resultados Parciais RelatÃ³rios por

Ciclo

3 1.000,00

2.2 Relatório de Resultados Final RelatÃ³rios Finais 1 1.000,00

2.3 Relatórios de Desempenho RelatÃ³rios de

Desemp

1 1.000,00

3 Defeitos 5.000,003.1 Debug de Defeitos Defeitos 10 3.000,00

3.2 Investigação Defeitos 10 1.998,00

3.3 Abertura de Defeitos na Ferramenta Defeitos Abertos

pro

10 1,00

3.4 Encerramento dos Defeitos Defeitos 10 1,00

4 Re-Testes 1.000,004.1 Estratégia Testes 1000 500,00

4.2 Re-Execução Testes

re-executados

1000 500,00

5 Contrato 4.000,005.1 Assinatura contrato 1 1.000,00

5.2 Controle contrato 1 1.000,00

5.3 Gerenciamento contrato 1 1.000,00

5.4 Encerramento contrato 1 1.000,00

EqualizaçãoTech Master Tests Full Max Tests LabTech - LaboratÃ³rio de Testes Gwonseon - LaboratÃ³rio de

TestesEspecificação Técnica Quant Unid Valor

UnitValorTotal

Quant Unid ValorUnit

ValorTotal


ValorTotal


ValorTotal

Quantidade de Testes por Ciclo (minimo) 3500 casos

de

teste

0,50 1.750,00 4000 casos

de

testes

0,50 2.000,00 2000 casos

de

teste

1,00 2.000,00 5000 casos

de

teste

0,50 2.500,00

Horas de Teste (minimo) 8 horas

por dia

1.000,00 8.000,00 8 horas

por dia

500,00 4.000,00 7 horas

por

dia

600,00 4.200,00 8 horas

de

teste

por d

400,00 3.200,00

Relatórios por Ciclo (minimo) 3 relatóri

os por

ciclo

80,00 240,00 3 relatóri

os por

ciclo

100,00 300,00 2 relatóri

os por

ciclo

100,00 200,00 2 relatóri

os

100,00 200,00

Duração do Ciclo (máximo) 3 dias 3.000,00 9.000,00 4 dias 2.000,00 8.000,00 4 dias 2.100,00 8.400,00 5 dias 1.800,00 9.000,00

Rota de Teste (máximo) 3 quilôm

etros

1.300,00 3.900,00 4 quilôm

etros

1.000,00 4.000,00 3 quilôm

etros

1.100,00 3.300,00 3 quilôm

etros

1.100,00 3.300,00

SP - Sistema de PontuaçãoId Critério Classificatório Comercial Peso Tech Master

TestsFull Max Tests LabTech -

LaboratÃ³rio deTestes

Gwonseon -LaboratÃ³rio deTestes

Nota Média Nota Média Nota Média Nota Média1046 Tempo de resposta a um atendimento 4 8.5 34 8.5 34 9.25 37 9.75 39

1047 Histórico de relacionamento com o

cliente

5 9.75 48.75 10 50 8.75 43.75 8.75 43.75

1048 Localização física da empresa 2 8.75 17.5 8.75 17.5 9.75 19.5 8.25 16.5

1049 Consegue entregar resultados dentro do

prazo estipulado

4 9.25 37 9 36 7.75 31 9.75 39

1050 Disponibilidade de atendimento fora do

horário comercial

3 9.25 27.75 8.75 26.25 7 21 9.75 29.25

1051 Preço compatível ao mercado 4 9 36 10 40 9.75 39 9.75 39

Id Critério Classificatório Técnico Peso Tech MasterTests

Full Max Tests LabTech -LaboratÃ³rio deTestes

Gwonseon -LaboratÃ³rio deTestes

Nota Média Nota Média Nota Média Nota Média1058 Filiais em outras capitais brasileiras 2 6.5 13 8.75 17.5 9.25 18.5 9.25 18.5

1057 Conhecimento das rotas das operadoras

brasileiras

5 9.5 47.5 10 50 9 45 7 35

1056 Já executou projetos com operadoras

brasileiras

4 9.75 39 9.25 37 9.25 37 6 24

1055 Número de engenheiros de teste 3 9.75 29.25 8.5 25.5 8.5 25.5 9.25 27.75

1054 Estrutura comprovada para suporte

técnico

4 9.75 39 9.5 38 8.25 33 9.25 37

1053 Atestado de capacidade técnica 5 9.5 47.5 9.75 48.75 8.75 43.75 9.75 48.75

1052 Alinhamento com DT 5 9 45 8.5 42.5 7.25 36.25 8.75 43.75

1059 Engenheiros com disponibilidade para

viagens nacionais e internacionais

4 9.75 39 9.75 39 9 36 10 40

BM - Boletim de MediçãoItem Descrição Unidade Orçamento da

FasePeso[%] Quant

PlanejadaQuant

RealizadaCritério

[%]Avanço Físico

PlanejadoAvanço Físico

Realizado[%]

1 Plano de Testes - 7.000,00 35 - - - - - -

1.1 Especificações Testes - - 3000 3000 0.01 1,00 1,00 100

1.2 Casos de Teste Testes - - 3000 2500 0.01 1,00 0,83 83.33

1.3 Rotas de Teste km - - 2 1 14.29 1.000,00 500,00 50

1.4 Execução dos ciclos Horas por

Dia

- - 8 8 85.69 5.998,00 5.998,00 100

2 Relatórios - 3.000,00 15 - - - - - -

2.1 Relatórios de Resultados Parciais Relatório

s por

Ciclo

- - 3 2 33.33 1.000,00 666,70 66.67

2.2 Relatório de Resultados Final Relatório

s Finais

- - 1 0 33.33 1.000,00 0,00 0

2.3 Relatórios de Desempenho Relatório

s de

Desemp

- - 1 0 33.33 1.000,00 0,00 0

3 Defeitos - 5.000,00 25 - - - - - -

3.1 Debug de Defeitos Defeitos - - 10 3 60 3.000,00 900,00 30

3.2 Investigação Defeitos - - 10 1 39.96 1.998,00 199,80 10

3.3 Abertura de Defeitos na Ferramenta Defeitos

Abertos

pro

- - 10 5 0.02 1,00 0,50 50

3.4 Encerramento dos Defeitos Defeitos - - 10 1 0.02 1,00 0,10 10

4 Re-Testes - 1.000,00 5 - - - - - -

4.1 Estratégia Testes - - 1000 1 50 500,00 0,50 0.10

4.2 Re-Execução Testes

re-execut

ados

- - 1000 0 50 500,00 0,00 0

5 Contrato - 4.000,00 20 - - - - - -

5.1 Assinatura contrato - - 1 1 25 1.000,00 1.000,00 100

5.2 Controle contrato - - 1 1 25 1.000,00 1.000,00 100

5.3 Gerenciamento contrato - - 1 1 25 1.000,00 1.000,00 100

5.4 Encerramento contrato - - 1 0 25 1.000,00 0,00 0

TOTAL - - - 2,000,00

0

20.000,00 11.267,43 47.06


RFP - 970

4.1.2 Homologação > Operadora "V" > Testes de Homologação - "V"


RFP - 971

4.2.2 Homologação > Operadora "C" > Testes de Homologação - "C"


RFP - 972

4.3.2 Homologação > Operadora "T" > Testes de Homologação - "T"


RFP - 973

4.4.2 Homologação > Operadora "O" > Testes de Homologação - "O"


RFP - 974

5.1.1 Documentação > Manual do Usuário > Tradução do Manual

Fluxograma de Execução

DESENVOLVIMENTO DE SOFTWARES PARA TERMINAIS MÓVEIS

Documents

Transcript of DESENVOLVIMENTO DE SOFTWARES PARA TERMINAIS MÓVEIS