Santos.paula (discussão | contribs)
 
(31 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 5: Linha 5:
== Título da Ideia  ==
== Título da Ideia  ==


Cell Broadcast
[[Cell Broadcast]]


<br>  
<br>


== Objetivos  ==
== Objetivos  ==
Linha 27: Linha 27:
<br>  
<br>  


Informe sobre as particularidades, aspectos e atributos desta ideia.
*Envio de mensagens em massa a todos os dispositivos conectados a células específicas da rede móvel.
 
*Não requer cadastro prévio do usuário.
 
*Entrega quase instantânea em áreas geográficas definidas.
 
*Funciona mesmo quando redes de voz/dados estão congestionadas.
 
*Suporte nativo em dispositivos compatíveis (a maioria dos smartphones modernos).
 
*Sem custo para o usuário final.
 
*Não utiliza SMS nem internet móvel.


<br>  
<br>  


<br>  
<br>


== Estudo Dirigido  ==
== Estudo Dirigido  ==
Linha 40: Linha 52:
*Redigir sobre Conceito conforme orientações do template
*Redigir sobre Conceito conforme orientações do template
*Definir Objetivos com o time
*Definir Objetivos com o time
*Descrever as principais soluções do mercado incluindo num item apropriado
<br>
*Descrever as principais soluções do mercado incluindo num item apropriado:
<br>
*Sistemas similares implementados:
**Japão: sistema nacional de alerta precoce para terremotos e tsunamis.
**EUA: Wireless Emergency Alerts (WEA).
**União Europeia: obrigatório em todos os estados-membros desde 2022 para desastres naturais.
<br>
*Avaliar os ratings e montar quadro comparativo
*Avaliar os ratings e montar quadro comparativo
*Pesquisar soluções open-source
*Pesquisar soluções open-source
Linha 46: Linha 65:




<br>  
<br>


= Fase II - Ensino  =
= Fase II - Ensino  =
Linha 87: Linha 106:
<br>
<br>


  Que questões envolvem a pesquisa?
*A tecnologia Cell Broadcast é capaz de cobrir de forma confiável áreas de risco sem depender da infraestrutura de dados móveis.
O que se espera provar?
 
O que se espera como resultado?
*Usuários receberão e reagirão adequadamente aos alertas, mitigando impactos dos desastres.
Explicações e argumentos que subsidiem a investigação em curso
 
*O sistema poderá ser implementado com custos viáveis para a empresa e parceiros públicos.
 
*Desafios tecnológicos e regulatórios podem ser superados com as metodologias escolhidas.
<br>
<br>


Linha 106: Linha 128:
== Benefícios para quem for oferecer esta solução  ==
== Benefícios para quem for oferecer esta solução  ==


    Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias
*Potencial geração de novas receitas com serviço inovador.
 
*Diferenciação da empresa no mercado.
 
*Cumprimento de responsabilidades sociais e regulatórias.
 
*Criação de novas parcerias com instituições acadêmicas.
 
*Fortalecimento da imagem institucional e responsabilidade social.
 
*Potencial receita via contratos com órgãos públicos.
 


<br>  
<br>  
Linha 114: Linha 147:
== Benefícios para o usuário  ==
== Benefícios para o usuário  ==


    Descrever em tópicos os benefícios para os usuários desta solução.
*Recebimento de alertas rápidos e precisos em situações de risco.
    Pode se inspirar no Canvas.
 
*Maior segurança pessoal e coletiva.


<br>  
*Facilidade de acesso à informação crítica sem necessidade de aplicativos adicionais.
 
*Não requer inscrição, instalação de app ou configuração.
 
*Serviço gratuito e inclusivo.
 
<br>


== Direcionadores chave para esta iniciativa  ==
== Direcionadores chave para esta iniciativa  ==


    Descrever em tópicos o que esta iniciativa pode proporcionar
*Atendimento a demandas sociais e regulatórias por maior segurança em áreas de risco.
 
*Aumento da frequência de eventos climáticos extremos.
 
*Inovação tecnológica e fortalecimento de parcerias acadêmicas.
 
*Melhoria da experiência do cliente.


<br><br>  
*Necessidade de soluções escaláveis e rápidas para comunicação em emergências.
 
*Contribuir para redução de perdas humanas e econômicas.
 
<br><br>


== Possíveis modelos de negócios  ==
== Possíveis modelos de negócios  ==


    Descrever em tópicos os possíveis modelos de negócios
*Oferta gratuita como serviço de valor agregado.
 
*Inclusão em pacotes premium de serviços.
 
*Licenciamento ou white-labeling para órgãos governamentais.
 
*Serviço contratado por órgãos governamentais (B2G).
 
*Parcerias com seguradoras e empresas para alertas corporativos.
 
*Licenciamento da plataforma para outras operadoras.


== Pesquisa de Mercado e Análise de Tendências  ==
== Pesquisa de Mercado e Análise de Tendências  ==
   
   
  Coletar dados relevantes sobre o mercado, como tamanho, crescimento, concorrência e comportamento do consumidor. Identificar tendências tecnológicas, comportamentais ou regulatórias que possam impactar o projeto.
*Crescente exigência regulatória (ex.: UE).
 
*Investimento global em sistemas de resiliência a desastres.
 
*Popularização de smartphones compatíveis.
 
*Demanda por comunicação pública confiável.
   
   
<br>
<br>
 
== Análise de Concorrentes e Soluções Existentes  ==
== Análise de Concorrentes e Soluções Existentes  ==
   
   
  Pesquisar e analisar soluções concorrentes ou similares no mercado. Entender como os concorrentes monetizam suas soluções e identificar oportunidades de diferenciação.
*EUA: WEA — gratuito, regulamentado pelo FCC.
 
*Japão: Early Warning System.
 
*Europa: Cell Broadcast Service obrigatório.
 
*No Brasil: atualmente defesa civil utiliza SMS opt-in (menos eficiente).
   
   
<br>
<br>
 
== Público - Alvo  ==
== Público - Alvo  ==
   
   
  Identificar os principais segmentos de clientes (B2B, B2C, etc.). Descrever as características demográficas, comportamentais e necessidades do público-alvo.
*População em áreas de risco.
 
*Órgãos públicos (Defesa Civil, prefeituras, governos estaduais).
 
*Empresas com operações em áreas críticas.
   
   
<br>
<br>
 
== Cenários e Oportunidades  ==
== Cenários e Oportunidades  ==
   
   
  Avaliar a possibilidade de contratar fornecedores externos para acelerar o desenvolvimento. Considerar o desenvolvimento interno da solução, se for viável. Explorar parcerias estratégicas com outras empresas ou investidores.
*Parceria com UFU já em andamento.
 
*Possibilidade de parcerias com Defesa Civil, Anatel, Ministério da Integração.
 
*Desenvolvimento interno do software com integração aos equipamentos de rede.
   
   
<br>
<br>
 
== Premissas Financeiras  ==
== Premissas Financeiras  ==
   
   
  Listar os principais custos envolvidos no desenvolvimento e operação da solução. Estimar a receita esperada com base em projeções de mercado. Considerar reajustes anuais de preços ou custos.
*Custos: adaptação de rede, contratação de serviços, suporte técnico.
 
*Receita: contratos governamentais, parcerias B2B.
 
*Reajustes anuais para manutenção e atualização tecnológica.
   
   
<br>
<br>
 
== Riscos do Projeto  ==
== Riscos do Projeto  ==
   
   
  Identificar os principais riscos do projeto (tecnológicos, financeiros, de mercado, etc.). Propor estratégias para mitigar os riscos identificados.
*Compatibilidade com dispositivos mais antigos.
 
*Custos elevados de implantação inicial.
 
*Aceitação dos órgãos reguladores.
 
*Percepção pública negativa se não for bem testado.
   
   
<br>
<br>
Linha 175: Linha 265:


* Projeto possui algum elemento tecnologicamente novo ou inovador?  
* Projeto possui algum elemento tecnologicamente novo ou inovador?  
Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada
A defesa civil já implementou seu programa de alerta.
<br>
<br>


* Projeto possui barreira ou desafio tecnológico superável?  
* Projeto possui barreira ou desafio tecnológico superável?  
Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese
Sim, integração com infraestrutura legada e conformidade com LGPD.
<br>
<br>


* Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?  
* Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?  
Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto
Sim, o projeto visa reduzir o atraso no recebimento do alerta pelos usuários.
<br>
<br>


* Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?
* Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?
Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa?
Sim, com a UFU. O desenvolvimento tecnológico é executado por um associado Algar (Ericson Luiz Araujo de Oliveira).
Anexar cópia do contrato
<br>


= Fase IV - Protótipo orientado ao Negócio  =
= Fase IV - Protótipo orientado ao Negócio  =
Linha 222: Linha 310:
<br>
<br>


* Avaliar condições referentes à Lei Geral de Proteção de Dados
* Garantir que não sejam coletados dados pessoais individualizados.
 
*Comunicação é unidirecional e não identifica usuários.
<br>
<br>



Edição atual tal como às 18h54min de 3 de julho de 2025

Fase I - Estudo


Título da Ideia

Cell Broadcast


Objetivos

Desenvolvimento de um serviço de alerta para clientes baseado em alarmes gerados pela UFU, com foco em áreas de risco sujeitas a fenômenos meteorológicos.


Conceito


Em parceria com a UFU, está sendo desenvolvido um sistema que utiliza alertas meteorológicos gerados via satélite para enviar notificações aos celulares conectados à rede, localizados em regiões de risco. Por exemplo, pessoas presentes em áreas sujeitas a alagamentos, como na Avenida Rondon Pacheco, serão alertados de forma rápida e eficiente.


Características 


  • Envio de mensagens em massa a todos os dispositivos conectados a células específicas da rede móvel.
  • Não requer cadastro prévio do usuário.
  • Entrega quase instantânea em áreas geográficas definidas.
  • Funciona mesmo quando redes de voz/dados estão congestionadas.
  • Suporte nativo em dispositivos compatíveis (a maioria dos smartphones modernos).
  • Sem custo para o usuário final.
  • Não utiliza SMS nem internet móvel.



Estudo Dirigido


  • Pesquisar e escrever sobre as características principais da tecnologia
  • Redigir sobre Conceito conforme orientações do template
  • Definir Objetivos com o time


  • Descrever as principais soluções do mercado incluindo num item apropriado:


  • Sistemas similares implementados:
    • Japão: sistema nacional de alerta precoce para terremotos e tsunamis.
    • EUA: Wireless Emergency Alerts (WEA).
    • União Europeia: obrigatório em todos os estados-membros desde 2022 para desastres naturais.


  • Avaliar os ratings e montar quadro comparativo
  • Pesquisar soluções open-source
  • Começar a pensar numa aplicação dessa tecnologia que deverá estar alinhada com o objetivo.



Fase II - Ensino


Conteúdo

Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável


Apresentação

Apresente ao grupo (reunião, EAD, Blog, ...)
Publique aqui


Metodologia


Descrevas as metodologias usadas. Alguns exemplos:
Estratégia de Job Rotation
Estudos básicos para conhecimento do potencial
Estudos básicos para entendimento sobre o problema
Estudos para dar base aos pesquisadores
Benchmarking com empresas estrangeiras 
Aceleradoras de empresas
Adoção de novas tecnologias
Utilização da proposta de soluções Open-source
Priorização no desenvolvimento interno
Foco na não dependência de fornecedores
Prática de formação dos talentos necessários 


Hipóteses


  • A tecnologia Cell Broadcast é capaz de cobrir de forma confiável áreas de risco sem depender da infraestrutura de dados móveis.
  • Usuários receberão e reagirão adequadamente aos alertas, mitigando impactos dos desastres.
  • O sistema poderá ser implementado com custos viáveis para a empresa e parceiros públicos.
  • Desafios tecnológicos e regulatórios podem ser superados com as metodologias escolhidas.


Fase III - Exemplo de Caso de Negócio


Product Backlog


Descreva os requisitos deste projeto


Benefícios para quem for oferecer esta solução

  • Potencial geração de novas receitas com serviço inovador.
  • Diferenciação da empresa no mercado.
  • Cumprimento de responsabilidades sociais e regulatórias.
  • Criação de novas parcerias com instituições acadêmicas.
  • Fortalecimento da imagem institucional e responsabilidade social.
  • Potencial receita via contratos com órgãos públicos.




Benefícios para o usuário

  • Recebimento de alertas rápidos e precisos em situações de risco.
  • Maior segurança pessoal e coletiva.
  • Facilidade de acesso à informação crítica sem necessidade de aplicativos adicionais.
  • Não requer inscrição, instalação de app ou configuração.
  • Serviço gratuito e inclusivo.


Direcionadores chave para esta iniciativa

  • Atendimento a demandas sociais e regulatórias por maior segurança em áreas de risco.
  • Aumento da frequência de eventos climáticos extremos.
  • Inovação tecnológica e fortalecimento de parcerias acadêmicas.
  • Melhoria da experiência do cliente.
  • Necessidade de soluções escaláveis e rápidas para comunicação em emergências.
  • Contribuir para redução de perdas humanas e econômicas.



Possíveis modelos de negócios

  • Oferta gratuita como serviço de valor agregado.
  • Inclusão em pacotes premium de serviços.
  • Licenciamento ou white-labeling para órgãos governamentais.
  • Serviço contratado por órgãos governamentais (B2G).
  • Parcerias com seguradoras e empresas para alertas corporativos.
  • Licenciamento da plataforma para outras operadoras.

Pesquisa de Mercado e Análise de Tendências

  • Crescente exigência regulatória (ex.: UE).
  • Investimento global em sistemas de resiliência a desastres.
  • Popularização de smartphones compatíveis.
  • Demanda por comunicação pública confiável.


Análise de Concorrentes e Soluções Existentes

  • EUA: WEA — gratuito, regulamentado pelo FCC.
  • Japão: Early Warning System.
  • Europa: Cell Broadcast Service obrigatório.
  • No Brasil: atualmente defesa civil utiliza SMS opt-in (menos eficiente).


Público - Alvo

  • População em áreas de risco.
  • Órgãos públicos (Defesa Civil, prefeituras, governos estaduais).
  • Empresas com operações em áreas críticas.


Cenários e Oportunidades

  • Parceria com UFU já em andamento.
  • Possibilidade de parcerias com Defesa Civil, Anatel, Ministério da Integração.
  • Desenvolvimento interno do software com integração aos equipamentos de rede.


Premissas Financeiras

  • Custos: adaptação de rede, contratação de serviços, suporte técnico.
  • Receita: contratos governamentais, parcerias B2B.
  • Reajustes anuais para manutenção e atualização tecnológica.


Riscos do Projeto

  • Compatibilidade com dispositivos mais antigos.
  • Custos elevados de implantação inicial.
  • Aceitação dos órgãos reguladores.
  • Percepção pública negativa se não for bem testado.


Business Case

    Anexar material de apresentação do Business Case (caso exista)


Alinhamento com Lei do Bem


  • Projeto possui algum elemento tecnologicamente novo ou inovador?

A defesa civil já implementou seu programa de alerta.

  • Projeto possui barreira ou desafio tecnológico superável?

Sim, integração com infraestrutura legada e conformidade com LGPD.

  • Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?

Sim, o projeto visa reduzir o atraso no recebimento do alerta pelos usuários.

  • Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?

Sim, com a UFU. O desenvolvimento tecnológico é executado por um associado Algar (Ericson Luiz Araujo de Oliveira).

Fase IV - Protótipo orientado ao Negócio


Escopo


Explique o escopo deste protótipo


Limitações


Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.


PoC


Desenvolva um PoC (Proof of Concept)


Privacidade (LGPD)


  • Garantir que não sejam coletados dados pessoais individualizados.
  • Comunicação é unidirecional e não identifica usuários.


Detalhamento Técnico


Descreva especificamente os aspectos técnicos desta pesquisa





Cronograma Macro


Histórico

Responsável: Paula

Semana de 26 à 30/05/2025

  • Acompanhamento do processo de edição do Memorando de Entendimento (M.O.U)


Semana de dd à dd/mm/yyyy


Pesquisadores


  • Paula Nunes Santos (Brain)
  • Luigi Negrini (Brain)
  • Lucas Sleyder (Brain)
  • Elias Brandão (Algar)
  • Ericson Luiz Araujo de Oliveira (Algar)
  • Alan Petrônio Pinheiro (UFU)