Histórico da Página

...

1. O analista de inovação deve gerar a especificação referente à sua tarefa, e se esta for necessária, e ao finalizar, enviá-la para homologação.
   Atenção: Durante a etapa de especificação, no Release Notes, o analista deverá enumerar todos os datasets e graphs que alterará ou adicionará.
2. Ao obter o retorno da homologação, se esta foi negativa, realize as alterações necessárias e envie novamente para homologação. Ao obter uma resposta positiva, dê continuidade aos próximos passos.
3. Antes de iniciar a codificação, o analista deverá primeiro realizar o check out do pacote com o projeto do TOTVS Smart Analytics mais atual no TFS, e copiá-lo como um projeto local.
4. Abra o projeto local com a ferramenta Cloud Connect, e dê início à etapa de codificação.
   Atenção: O analista de inovação deverá manter nota de todos datasets e graphs que foram alterados ou adicionados, para manter o Release Notes atualizado. Dessa forma, o cliente customizado terá a informação necessária para realizar a atualização de seu projeto.
5. Ao finalizar a codificação no Cloud Connect, o analista de inovação deverá publicar a modelagem e realizar o deploy/re-deploy do projeto no ambiente de desenvolvimento.
   Atenção: O analista deve-se atentar para anotar o versionamento de modelagem e ETL, para então efetuar o deploy/re-deploy com o versionamento correto.
6. O analista de inovação deverá, então, realizar o check in do projeto atualizado no TFS.
7. Para concluir a etapa de codificação, só resta ao analista realizar a criação de métricas, relatórios e/ou dashboards no analytics.totvs.com.br, no ambiente de desenvolvimento.
8. Ao concluir estes passos, o analista de inovação deverá sinalizar ao analista responsável pelo teste unitário, de que o projeto já está disponível para o teste de unidade.
9. O analista responsável pelo teste unitário, por sua vez, deverá realizar o mesmo passo de check out do projeto TOTVS Smart Analytics noTFS.
10. A partir de então, este analista deverá realizar o teste executando o Agent, ou rodando localmente no Cloud Connect, no ambiente de desenvolvimento (dependendo do que foi codificado, outro tipo de teste pode ser mais cabível). E se necessário, também deverá checar se os dados foram carregados na nuvem, por meio de criação de relatórios em analytics.totvs.com.br.
    1. Se for encontrado algum erro, este deve sinalizar para que o analista de inovação corrija-os e atualize o projeto no TFS. 
    2. Se os testes forem executados com sucesso, também deve-se sinalizar ao analista de inovação que o projeto está funcionando corretamente. 
11. Ao obter o retorno de que o teste unitário foi realizado com sucesso, o analista de inovação deverá, então, disponibilizar o projeto no ambiente do SQA, o que inclui publicação de modelagem e re-deploy do projeto TOTVS Smart Analytics, e a exportação de métricas, relatórios e dashboads criados e/ou modificados, por meio da extensão do Chrome para o GoodData.
12. A partir deste momento, o analista de testes ficará encarregado de testar o projeto TOTVS Smart Analytics, e seguirá o passo de realizar check out do projeto no TFS.
    1. Se erros forem encontrados, o analista de testes abrirá tarefas de defeito para a devida correção pelo analista de inovação.
13. Quando os testes forem finalizados com sucesso, o analista de testes deverá dar o sinal de sucesso para o analista de inovação, para que este mantenha o ambiente de Produção atualizado, conforme fechamento de releases.
    
    

...

Os seguintes passos devem ser seguidos pelo analista de manutenção que irá alterar ao projeto do TOTVS Smart AnalyticAnalytics:

1. O analista de manutenção deve gerar a especificação referente à sua tarefa, e ao finalizar, enviá-la para homologação.
   Atenção: Durante a etapa de especificação, no Release Notes, o analista deverá enumerar todos os datasets e graphs que alterará ou adicionará.
2. Ao obter o retorno da homologação, se esta foi negativa, realize as alterações necessárias e envie novamente para homologação. Ao obter uma resposta positiva, dê continuidade aos próximos passos.
3. Antes de iniciar a codificação, o analista deverá primeiro realizar o check out do pacote com o projeto do TOTVS Smart Analytics mais atual no TFS, e copiá-lo como um projeto local.
4. Abra o projeto local com a ferramenta Cloud Connect, e dê início à etapa de codificação.
   Atenção: O analista de manutenção deverá manter nota de todos datasets e graphs que foram alterados ou adicionados, para manter o Release Notes atualizado. Dessa forma, o cliente customizado terá informação necessária para realizar a atualização de seu projeto.
5. Ao finalizar a codificação no Cloud Connect, o analista de manutenção deverá publicar a modelagem e realizar o deploy/re-deploy do projeto no ambiente de desenvolvimento.
   Atenção: O analista deve-se atentar para anotar o versionamento de modelagem e ETL, para então efetuar o deploy/re-deploy com o versionamento correto.
6. O analista de manutenção deverá, então, realizar o check in do projeto atualizado no TFS.
7. Para concluir a etapa de codificação, só resta ao analista realizar a criação de métricas, relatórios e/ou dashboards no analytics.totvs.com.br, no ambiente de desenvolvimento.
8. Ao concluir estes passos, o analista de manutenção deverá sinalizar ao analista responsável pelo teste unitário, de que o projeto já está disponível para o teste de unidade.
9. O analista responsável pelo teste unitário, por sua vez, deverá realizar o mesmo passo de check out do projeto TOTVS Smart Analytics noTFS.
10. A partir de então, este analista deverá realizar o teste executando o Agent, ou rodando localmente no Cloud Connect, no ambiente de desenvolvimento (dependendo do que foi codificado, outro tipo de teste pode ser mais cabível). E se necessário, também deverá checar se os dados foram carregados na nuvem, por meio de criação de relatórios em analytics.totvs.com.br.
    1. Se for encontrado algum erro, este deve sinalizar para que o analista de manutenção corrija-os e atualize o projeto no TFS. 
    2. Se os testes forem executados com sucesso, também deve-se sinalizar ao analista de manutenção que o projeto está funcionando corretamente. 
11. Ao obter o retorno de que o teste unitário foi realizado com sucesso, o analista de manutenção deverá, então, disponibilizar o projeto no ambiente do SQA, o que inclui publicação de modelagem e re-deploy do projeto TOTVS Smart Analytics, e a exportação de métricas, relatórios e dashboads criados e/ou modificados, por meio da extensão do Chrome para o GoodData.
12. A partir deste momento, o analista de testes ficará encarregado de testar o projeto TOTVS Smart Analytics, e seguirá o passo de realizar check out do projeto no TFS.
    1. Se erros forem encontrados, o analista de testes abrirá tarefas de defeito para a devida correção pelo analista de manutenção.
13. Quando os testes forem finalizados com sucesso, o analista de testes deverá dar o sinal de sucesso para o analista de manutenção, para que este mantenha o ambiente de Produção atualizado, conforme fechamento de releases.

...

1. responsável pela abertura da FNC de Erro/Melhoria criará a FNC após notificação do solicitante que alerta sobre algum erro ou deseja uma melhoria.
2. O analista de manutenção verificará se a FNC procede:
   1. Em caso negativo, a FNC será rejeitada, e o solicitante será informado das justificativas.
   2. Em caso positivo, os passos do cenário de Inovação, apresentados acima, deverão ser seguidos.
   Atenção: No último passo, neste caso, o analista de testes deverá, além de sinalizar ao analista de inovação/manutenção, também informar ao solicitante que sua FNC foi concluída com êxito.

Mercado Internacional