Árvore de páginas

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 36 Próxima »

$paramDesc

Voltar à HOME

    O que é?

    É a construção de fato sobre o desenho detalhado aprovado na fase anterior.
    Esta construção implica na disponibilidade dos ambientes de trabalho, execução das sprints de configuração do sistema, desenvolvimento das customizações, carga dos dados e validação da entrega, através de ciclos técnicos e de negócio.

    É importante definir quais testes críticos deverão ser feitos na transição (virada) e rever o plano de virada do sistema para o ambiente produtivo.

    A construção e testes são baseadas em Sprints com base no backlog. A execução do plano de virada e dos testes integrados ocorrem nesta etapa.

    Recapitulando, este grupo de tarefas, têm o objetivo de controlar a construção do sistema dentro do desenho aprovado, garantir o atendimento dos requisitos e um bom plano de virada, administrando a entrega dentro do planejamento aprovado com o Cliente.

    Entregáveis

    Atividades

    Configurar produto

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Consultor de Implantação
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do cliente
    Contexto

    É nesta etapa que a configuração do produto ocorre como o combinado e aprovado pelo cliente, respeitando o que foi definido na fase de refinamento e priorizado para cada sprint.

    Caso surjam questões não previstas ou tratadas na fase anterior, estas serão discutidas pelo time nas reuniões de retrospectivas da Sprint e dependendo da questão deve-se obrigatoriamente registrar uma Solicitação de Mudança para que seja avaliado o impacto e se tenha uma aprovação formal desta, que pode alterar prazo, custo ou qualidade definida durante o Refinamento da Solução.

    As entregas ocorrem através de Sprints (iterações) com tempo definido (idealmente de 2 a 4 semanas) e cada Sprint deve entregar um incremento do produto que pode ou não ser validado com o cliente, de acordo com o planejamento das releases (grupos de Sprints).

    É esperado que as seguintes cerimônias aconteçam a cada ciclo de Sprint:

    • Planejamento da Sprint: Cerimônia para definição do objetivo da sprint, escopo de trabalho, como e o que será entregue.

    • Reunião da Iteração: (“Daily”) É a reunião de acompanhamento da sprint, onde é verificado o andamento da Sprint. De curta duração (não mais que 30 min), na qual cada membro reflete sobre: O que fez de ontem para hoje? O que farei de hoje até amanhã? Existe algum impedimento? 

    A recorrência da reunião pode ser definida de acordo com o contexto de cada projeto e pode ser realizada com todo o time do projeto com ou sem a participação do Coordenador ou Gerente do Projeto.

    • Revisão da Sprint: é a cerimônia de apresentação do que ficou pronto para validação e coleta de feedback.

    • Retrospectiva da Sprint: é a última atividade da sprint, na qual a equipe avalia sua própria atuação durante o processo de trabalho e planeja ações de melhoria a serem implementadas na próxima sprint

    Questões como: O que deu certo? O que pode melhorar? pendências e aprendizado (lições aprendidas) devem ser abordadas e registradas na planilha de Monitoramento e Controle do Projeto.


    NOTA: Recomenda-se organizar várias Solicitações de Mudança - MIT031 em conjunto para se ter uma melhor percepção dos impactos, ao invés de avaliá-las individualmente. Para tanto, pode-se estipular momentos / datas programadas para solicitar, avaliar e aprovar a demanda.

    Ações /
    descritivo
    da atividade
    • Durante a Sprint o Analista ou Consultor de Implantação:
      • Configura o sistema com base no Diagrama do processo aprovado pelo Cliente e backlog priorizado para a Sprint.
      • Reporta o avanço, riscos ou issues encontrados, eventuais atrasos e desvios ocorridos através das reuniões da iteração, ou das reuniões diárias.
    • O Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto ou Cliente.
    • Ao final de cada Sprint é esperado que ocorra a reunião de retrospectiva, com todo o time que participou da Sprint.
    • Após o encerramento de cada Sprint, inicia-se um novo ciclo de iteração até que todo o backlog do produto seja entregue.
    Resultado /
    Critérios de
    Saída

    Encomendar/Desenvolver customizações

    Insumos /
    Critérios de
    Entrada
    • Projeto Lógico aprovado (PL)
    Papéis
    envolvidos
    • Desenvolvedor (Fábrica de Software)
    • Líder Técnico (Fábrica de Software)
    • Analista / Consultor de Implantação
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    Contexto

    O desenvolvimento das customizações deve seguir o combinado e aprovado pelo Cliente, ou seja, seguir o que foi definido no Diagrama dos Processos MIT041.

    Ações /
    descritivo
    da atividade
    • Líder Técnico organiza as entregas com o time de desenvolvimento (Backlog / Sprints / Deploy)
    • Time da Fábrica realiza o desenvolvimento  de acordo com o que foi definido no Projeto Lógico (PL)
    • Líder Técnico da Fábrica de Software:
    • Reporta avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos
    • Envia as evidências de teste realizado, demonstrando o resultado positivo.
    • Gerente ou Coordenador do Projeto acompanha a evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
    Resultado /
    Critérios de
    Saída
    • Customizações desenvolvidas.

    Atividades

    Capacitar usuários-chave

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Consultor de Implantação
    • Usuários-Chave (Cliente)
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    Contexto

    Esta capacitação deve conduzir os usuários-chave ao uso efetivo do sistema de acordo com o Desenho da Solução aprovado.

    Deve-se lembrar o compromisso alinhado na preparação / Reunião de Abertura do projeto, que os usuários-chave são responsáveis por replicar o conhecimento e também por eventual suporte.

    Ações /
    descritivo
    da atividade
    • Analistas / Consultores e Usuários-Chave se reúnem conforme planejamento da Capacitação realizada no Refinamento
    • Os Analistas ou Consultores ministram as capacitações de acordo com o Desenho da Solução aprovado e respectivas configurações.
    • Usuários-Chave:
      • Devem absorver o conhecimento e realizar o aprofundamento do sistema na prática para garantir eficiência no uso
      • Formalizam o recebimento do conhecimento e uso do sistema junto aos Consultores que ministraram o treinamento
    • Gerente ou Coordenador do Projeto organiza as formalizações e realiza a validação desta etapa junto ao Comitê do Projeto
    • El Comité de Proyecto aprueba la formación mediante la firma del procedimiento de capacitación.
    Resultado /
    Critérios de
    Saída

    Roteiro de capacitação - MIT037 enviado para o usuário chave para que ele realize a aprovação via assinatura da Capacitação realizada.

    Atividades

    Preparar e executar carga de dados

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Consultor de Implantação
    • Usuários-Chave (Cliente)
    • TI (Cliente), se houver
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    Contexto

    Neste momento são realizadas as cargas identificadas e planejadas, seguindo o método estipulado, pelos respectivos responsáveis pela mesma.

    É de igual importância que se tenha critérios de validação para garantir que a carga tenha tido sucesso, para que os testes e validações seguintes possam gerar os resultados esperados.

    • NOTA: Nos casos de carga manual, ou seja, dados inseridos manualmente pelos usuários-chave, deve-se combinar muito bem o esforço e os prazos para que o cronograma esteja bem alinhado.
    Ações /
    descritivo
    da atividade
    • Analista(s) / Consultor(es) de implantação executam as cargas de dados com rotinas / ferramentas definidas, conforme planejado e alinhado durante a fase Refinamento.
    • Usuários-Chave:
      • Executam a carga de dados manualmente conforme planejado e alinhado durante a fase Refinamento.
      • Validam os dados migrados, por um método ou outro, utilizando as ferramentas combinadas.
    • Usuários e Analista(s) / Consultor (es) reportam avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
    • Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
    Resultado /
    Critérios de
    Saída

    Dados planejados disponíveis e validados no sistema, Roteiro de Conversão de Dados - MIT053 e Roteiro de Interface – MIT055, atualizados.

    Atividades

    Realizar testes unitários

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Consultor de implantação
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    Contexto

    O objetivo principal desta tarefa é garantir o funcionamento do sistema para que os usuários-chave possam validar efetivamente a solução. Portanto, o alvo destes testes deve ser mais voltados em executar as rotinas e ter menos foco nos resultados esperados, como por exemplo o cálculo correto dos impostos.

    • NOTA: Esta divisão de prioridade ocorre porque muito dos resultados esperados tem relação direta com os cadastros e o negócio em si. Por esta razão é que se costuma planejar ciclos com aspectos diferentes.
    Ações /
    descritivo
    da atividade
    • Analista(s) / Consultor(es) de implantação, normalmente em conjunto com o time de TI, executam os testes elaborados no Roteiro de Testes com foco no funcionamento do sistema, a fim de garantir sua disponibilidade aos usuários-chave na validação efetiva.
    • Analista(s) / Consultor(es) reportam avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
    • Gerente ou Coordenador do Projeto acompanha a evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
    Resultado /
    Critérios de
    Saída

    Sistema testado em toda sua funcionalidade, sem considerar resultados de negócio (que dependam de aspectos de cadastros e regras de negócio) e Roteiro de Testes - MIT045 atualizado.

    Realizar testes integrados do sistema - Time TOTVS

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Consultor de implantação
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    • Suporte TOTVS (Opcional)
    Contexto

    O objetivo principal desta tarefa é garantir, além do funcionamento do sistema, que os resultados esperados sejam validados, assim como os processos e seus diferentes cenários. Em alguns casos, é incluído após os testes integrados, o teste de carga do sistema.

    Ações /
    descritivo
    da atividade
    • Analista(s) / Consultor(es) se organizam de acordo com o planejado para executar a validação geral da solução.
    • NOTA 1: nesta etapa, com o sistema em pleno funcionamento, deve-se validar os processos, seus diferentes cenários e apurar os resultados esperados.
    • Analista(s) / Consultor(es) reportam o avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
    • Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.

    NOTA 2: o Gerente ou Coordenador do Projeto pode identificar a necessidade de fazer um teste de carga no sistema, devendo ser realizado nesta etapa, usando um documento de Termo de Validação - MIT010 com o resultado dos testes.

    Resultado /
    Critérios de
    Saída
    • Solução testada em toda sua funcionalidade, processos e cenários, considerando inclusive os resultados de negócio (que dependem de aspectos de cadastros e regras de negócio) e Roteiro de Testes - MIT045, atualizado.
    • Se aplicável, o Termo de Validação - MIT010 com o resultado dos testes de carga.

    Realizar testes integrados do sistema – Time Cliente

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Consultor de implantação
    • Usuários-Chave (Cliente)
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    Contexto

    O objetivo principal desta tarefa é garantir, além do funcionamento do sistema, que os resultados esperados sejam validados, assim como os processos e seus diferentes cenários.

    Ações /
    descritivo
    da atividade
    • Analista(s) / Consultor(es) e Usuários-Chave se organizam de acordo com o planejado para executar a validação geral da solução.
    • NOTA: nesta etapa, com o sistema em pleno funcionamento, deve-se validar os processos, seus diferentes cenários e apurar os resultados esperados.
    • Analista(s) / Consultor(es) reportam o avanço, riscos / issues encontrados, eventuais atrasos e desvios ocorridos.
    • Gerente ou Coordenador do Projeto acompanha evolução e trabalha na comunicação e alinhamento com o Comitê do Projeto / Cliente.
    Resultado /
    Critérios de
    Saída

    Solução testada em toda sua funcionalidade, processos e cenários, considerando inclusive os resultados de negócio (que dependem de aspectos de cadastros e regras de negócio,) Roteiro de Testes - MIT045 e Termo de Validação - MIT010 (Termo de homologação) assinada.

    Atividades

    Definir testes de Virada (Melhor Prática)

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Especialista 
    • Usuários-Chave (responsável pela execução)
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    Contexto

    É fundamental restringir o lançamento oficial do sistema aos usuários-chave, para que estes possam realizar atividades reais no sistema já no ambiente de Produção, garantindo o funcionamento essencial do negócio, considerando todos os processos críticos.

    Ações /
    descritivo
    da atividade
    • Usuários-Chave definem as operações críticas como critério de GO LIVE, logo após a execução do Cutover
    • Gerente ou Coordenador do Projeto:
    • Acompanha as definições e avalia se estão de acordo com os critérios de qualidade estabelecidos
    • Ao final, registra a decisão no Roteiro de Testes - MIT045.
    Resultado /
    Critérios de
    Saída
    Roteiro de Testes atualizado - MIT045

    Definir/Revisar plano de virada

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Especialista
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    • Usuários-Chave (Cliente)
    • Cloud TOTVS (quando houver serviço de host)
    Contexto

    A Definição/Revisão do plano de virada deve ser realizado logo após serem obtidos os resultados dos Testes Integrados e Validação da Solução, onde se tem mais detalhes sobre as necessidades de suspensão do sistema, sobre as mudanças de processo no negócio, sobre o impacto nas demais áreas etc.

    É importante que qualquer nova questão que surja seja tratada neste momento, evitando assim postergar um problema que pode trazer impactos negativos para todo o projeto.

    Ações /
    descritivo
    da atividade
    • Analista / Especialista e Usuários-Chave (Cliente) reavaliam os detalhes dos impactos na transição do sistema para Produção após resultados, considerando aspectos técnicos e funcionais:


    • Técnicos
      • Ações de ambiente (infraestrutura)
      • Ações de configuração
      • Ações de transporte de dados
      • Ações equalização de customizações
      • Ações de atualização da aplicação (software), que pode decorrer ao longo do projeto
      • Preparação de atividades Cloud (quando houver serviços de host). 
    • Funcionais:
      • Alinhamento com as áreas que podem sofrer impacto com o período de suspensão (execução do cutover)
      • Alinhamento com os Clientes sobre a mesma questão
      • Alinhamento com Fornecedores e Parceiros sobre a mesma questão
      • Treinamento e preparação das mudanças operacionais (processos TO BE)
      • Plano de Contingência de negócio
    • Comitê do Projeto aprova a revisão do plano de Virada e Rollback - MIT054
    Resultado /
    Critérios de
    Saída

    Plano de Virada e Rollback - MIT054 revisado com as partes interessadas devidamente alinhadas.

    Aprovar e divulgação a virada

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Analista / Especialista
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    • Usuários-Chave (Cliente)
    • Suporte TOTVS (Opcional)
    Contexto

    A aprovação do Comitê (decisão de GO) deve ser seguida de uma divulgação oficial de liberação da execução do Transição a todos os interessados para que:

    • Todas as áreas envolvidas, Cliente, Fornecedores e Parceiros possam se programar adequadamente e/ou combinarem planos de contingência
    • O projeto ganhe força política e estratégica na Organização
    • O projeto tenha engajamento final, pois neste momento é fundamental que todos coloquem a devida prioridade do seu tempo em prol da qualidade da transição.
    Ações /
    descritivo
    da atividade
    Resultado /
    Critérios de
    Saída

    Plano de Virada e Rollback - MIT054 aprovado e divulgado oficialmente entre todas as partes interessadas do Projeto.

    Atividades

    Encerrar a fase e avaliar Quality Gate

    Insumos /
    Critérios de
    Entrada
    Papéis
    envolvidos
    • Gerente ou Coordenador do Projeto
    • Coordenador ou Comitê do Projeto por parte do Cliente
    • Cliente
    Contexto

    Revisão do gate e conclusão das entregas da fase

    Ações /
    descritivo
    da atividade
    • Gerente ou Coordenador do Projeto revisam os entregáveis da fase.
    Resultado /
    Critérios de
    Saída
    • Revisão do Gate e entregáveis da fase concluídos

    ¿Qué es?

    Es la construcción de facto en base al diseño detallado aprobado en la fase anterior.


    Esta construcción implica la disponibilidad de los entornos de trabajo, ejecución de las sprints de configuración del sistema, desarrollo de las personalizaciones, carga de los datos y validación de la entrega, a través de ciclos técnicos y empresariales.


    Es importante definir qué pruebas críticas se deben llevar a cabo en la transición y revisar el plan de transición del sistema para el entorno productivo.


    La construcción y las pruebas se basan en sprints basados en el backlog. La ejecución del plan de transición y de las pruebas integradas ocurren en esta etapa.

    Para resumir, este grupo de tareas tiene como objetivo controlar la construcción del sistema dentro del diseño aprobado, garantizar la atención de los requisitos y un buen plan de transición, administrando la entrega dentro de la planificación aprobada con el Cliente.

    Entregables

    Actividades

    Configuración del producto

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Consultor de Implantación
    • Gerente o coordinador del proyecto
    • Coordinador o Comité del Proyecto por parte del cliente
    Contexto

    Es en esta etapa que la configuración del producto ocurre como combinado y aprobado por el cliente,

    respetando lo que se definió en la fase de refinamiento y priorizado para cada sprint.


    Si surgen problemas imprevistos o tratados en la fase anterior, estos serán discutidos por el equipo en las
    reuniones de retrospectivas de la Sprint y dependiendo del problema, obligatoriamente se debe registrar una

    Solicitud de Cambio para evaluar el impacto y tener una aprobación formal de esta, que puede cambiar el
    plazo, costo o calidad definida durante el Refinamiento de la Solución.

    Las entregas ocurren a través de Sprints (iteraciones) con tiempo definido (idealmente de 2 a 4 semanas) y
    cada Sprint debe entregar un incremento de producto que puede o no validarse con el cliente, de acuerdo
    con la planificación de las releases (grupos de Sprints).

    Se espera que las siguientes ceremonias se lleven a cabo cada ciclo de Sprint:

    • Planificación de la Sprint: Ceremonia para definición del objetivo de la sprint, alcance del trabajo,
      cómo y qué se entregará.
    • Reunión de la iteración (“Daily”): es la reunión de seguimiento de la sprint, donde se verifica la
      marcha de la sprint. De corta duración (no más de 30 min), en la que cada miembro reflexiona
      sobre: ¿Qué ha hecho de ayer a hoy?, ¿Qué haré de hoy hasta mañana?, ¿hay algún impedimento?
      La periodicidad de la reunión se puede definir según el contexto de cada proyecto y se puede
      realizar con todo el equipo del proyecto con o sin la participación del coordinador o gerente del
      proyecto.
    • Revisión de la sprint: es la ceremonia de presentación de lo que está listo para la validación y la
      recopilación de feedback.
    • Retrospectiva de la sprint: es la última actividad de la sprint, en la que el equipo evalúa su propio
      desempeño durante el proceso de trabajo y planifica las acciones de mejora que se implementarán
      en la próxima sprint.
      Cuestiones tales como: ¿Qué funcionó? ¿Qué puede mejorar? actividades pendientes y de
      aprendizaje (lecciones aprendidas) deben abordarse y registrarse en la lista de Retrospectiva y
      Actividades Pendientes.


    NOTA: Se recomienda organizar varias Solicitudes de Cambio - MIT031 juntas para tener una mejor
    percepción de los impactos, en lugar de evaluarlos individualmente. Para ello, es posible estipular
    momentos/fechas programadas para solicitar, evaluar y aprobar la demanda.

    Acciones/
    Descriptivo de
    la actividad
    • Durante la Sprint el analista o consultor de implementación:

      • Configura el sistema en función del diagrama de procesos aprobado por el Cliente y el
        backlog priorizado para la Sprint.

      • Informa el avance, riesgos o issues encontrados, eventuales retrasos y desviaciones que se
        produjeron a través de reuniones de la iteración, o reuniones diarias.

    • El gerente o coordinador del proyecto sigue la evolución y trabaja en la comunicación y alineación con el Comité del Proyecto o Cliente.

    • Al final de cada Sprint se espera que tenga lugar la reunión retrospectiva, con todo el equipo que
      participó en el Sprint.

    • Después de la finalización de cada Sprint, comienza un nuevo ciclo de iteración hasta que se entrega todo el backlog del producto.

    Resultados
    /Criterios
    de salida

    Encomienda/Desarrollo de personalizaciones

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Desarrollador (Fábrica de Software)
    • Líder técnico (Fábrica de Software)
    • Analista/Consultor de Implantación
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    Contexto

    El desarrollo de las personalizaciones debe seguir lo acordado y aprobado por el Cliente, es decir, seguir lo que se definió en el Diagrama de Proceso MIT041.

    Acciones/
    Descriptivo
    de la
    actividad
    • Líder Técnico organiza entregas con el equipo de desarrollo (Backlog/Sprints/Deploy)
    • Equipo de la Fábrica realiza el desarrollo según lo solicitado en función de las Especificaciones de las
      personalizaciones y Proyecto Lógico (PL)
    • Líder técnico de la Fábrica de Software:
      • Informa avance, riesgos/issues encontrados, posibles retrasos y desviaciones ocurridas
      • Envía las evidencias de la prueba realizada, demostrando el resultado positivo.
    • Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el
      Comité del Proyecto/Cliente.
    Resultados/
    Criterios
    de salida
    • Personalizaciones desarrolladas.

    Actividades

    Capacitación de los usuarios clave

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Consultor de Implantación
    • Usuarios clave (Cliente)
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    Contexto

    Esta capacitación debe conducir a los usuarios clave al uso eficaz del sistema de acuerdo con el Diseño de la solución aprobado.
    Cabe recordar el compromiso alineado en la preparación/Reunión de Apertura del proyecto, que los usuarios clave son responsables de replicar el conocimiento y también de eventual soporte.

    Acciones/
    Descriptivo
    de la
    actividad
    • Analistas/consultores y usuarios clave se reúnen de acuerdo con la planificación de la Capacitación realizada en el Refinamiento

    • Analistas o consultores imparten las capacitaciones de acuerdo con el Diseño de la Solución aprobado y sus respectivas configuraciones.

    • Usuarios clave:

      • Deben absorber el conocimiento y realizar la profundización del sistema en la práctica para garantizar la eficiencia en el uso

      • Formalizan la recepción de conocimiento y uso del sistema con los Consultores que impartieron la capacitación

    • El gerente o coordinador del proyecto organiza las formalizaciones y valida esta etapa con el Comité del Proyecto

    • El Comité del Proyecto aprueba la realización de la Capacitación a través del documento de comprobación de la etapa.

    Resultados/
    Criterios
    de salida

    Se envía el procedimiento de capacitación - MIT037 al usuario clave para su aprobación mediante la firma
    de la formación realizada.

    Actividades

    Carga de datos

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Consultor de Implantación
    • Usuarios clave (Cliente)
    • TI (Cliente), si lo hay
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    Contexto

    En este momento, se realizan las cargas identificadas y planificadas, siguiendo el método estipulado, por los

    respectivos responsables de la misma.
    Es igualmente importante que se tengan criterios de validación para garantizar que la carga se ha realizado
    con éxito, de modo que las pruebas y validaciones siguientes puedan generar los resultados esperados.

    • NOTA: En los casos de carga manual, es decir, datos introducidos manualmente por los usuarios clave,
      se debe combinar muy bien el esfuerzo y los plazos para que el cronograma esté bien alineado.
    Acciones/
    Descriptivo
    de la
    actividad
    • Los analista(s)/consultor(es) de implementación ejecutan las cargas de datos con rutinas/herramientas
      definidas, según lo planificado y alineado durante la fase de Refinamiento.
    • Usuarios clave:
      • Ejecutan la carga de datos manualmente según lo planificado y alineado durante la fase de
        Refinamiento.
      • Validan los datos migrados por un método u otro utilizando las herramientas combinadas.
    • Usuarios y analista(s)/Consultor(es) informan el avance, riesgos/issues encontrados, eventuales
      retrasos y desviaciones ocurridas.
    • Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el
      Comité del Proyecto/Cliente.
    Resultados/
    Criterios
    de salida

    Datos planificados disponibles y validados en el sistema y el Procedimiento de Conversión de Datos -
    MIT053
    actualizado.

    Actividades

    Pruebas unitarias

    Insumos/
    Criterios
    de entrada
    Papeles
    involucrados
    • Analista/Consultor de Implantación
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    Contexto

    El objetivo principal de esta tarea es garantizar el funcionamiento del sistema para que los usuarios clave
    puedan validar eficazmente la solución. Por lo tanto, la meta de estas pruebas debe centrarse más en la
    ejecución de rutinas y tener menos atención en los resultados esperados, como el cálculo correcto de los
    impuestos.

    • NOTA: Esta división de prioridad ocurre porque gran parte de los resultados esperados están
      directamente relacionados con los registros y el propio negocio. Por esta razón, generalmente se
      planifican ciclos con diferentes aspectos.
    Acciones/
    Descriptivo
    de la
    actividad
    • Analista(s)/consultor(es) de implementación, generalmente en conjunto con el equipo de TI, realizan
      las pruebas elaboradas en el Itinerario de Pruebas centradas en el funcionamiento del sistema, con el
      fin de garantizar su disponibilidad a los usuarios clave en la validación efectiva.
    • Analista(s)/consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y
      desviaciones ocurridas.
    • Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el
      Comité del Proyecto/Cliente.
    Resultados/
    Criterios
    de salida

    Sistema probado en toda su funcionalidad, sin tener en cuenta los resultados de negocio (que dependen de aspectos de registros y reglas de negocio) e Guia de Pruebas - MIT045 actualizado.

    Pruebas Integradas del Sistemas - Equipo TOTVS

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Consultor de Implantación
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    • Soporte TOTVS (Opcional)
    Contexto

    El objetivo principal de esta tarea es garantizar, además del funcionamiento del sistema, que se validen los
    resultados esperados, así como los procesos y sus diferentes escenarios. En algunos casos, se incluye
    después de las pruebas integradas, la prueba de carga del sistema.

    Acciones/
    Descriptivo
    de la
    actividad
    • Analista(s)/consultor(es) se organizan de acuerdo con lo planificado para realizar la validación
      general de la solución.
      • NOTA 1: en esta etapa, con el sistema en pleno funcionamiento, se deben validar los procesos, sus
        diferentes escenarios y determinar los resultados esperados.
    • Analista(s)/Consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y
      desviaciones ocurridas.
    • Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el
      Comité del Proyecto/Cliente.
      • NOTA 2: el gerente o coordinador del proyecto puede identificar la necesidad de realizar una prueba
        de carga en el sistema, que debe realizarse en esta etapa, utilizando un documento Término de
        Validación - MIT010
        con el resultado de las pruebas.
    Resultados/
    Criterios
    de salida
    • Solución probada en todas sus funcionalidades, procesos y escenarios, considerando incluso los
      resultados del negocio (que dependen de aspectos de registros y reglas de negocio) e Guia de Pruebas -
      MIT045
      , actualizado.
    • Si procede, el Término de Validación - MIT010 con el resultado de las pruebas de carga.

    Pruebas Integradas del Sistema - Equipo Cliente

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Consultor de Implantación
    • Usuarios clave (Cliente)
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    Contexto

    El objetivo principal de esta tarea es garantizar, además del funcionamiento del sistema, que los resultados esperados se validen, así como los procesos y sus diferentes escenarios.

    Acciones/
    Descriptivo
    de la
    actividad
    • Analista(s)/consultor(es) y usuarios clave se organizan de acuerdo con lo planificado para realizar la
      validación general de la solución.
    • NOTA: en esta etapa, con el sistema en pleno funcionamiento, se deben validar los procesos, sus
      diferentes escenarios y determinar los resultados esperados.
    • Analista(s)/Consultor(es) informan el avance, riesgos/issues encontrados, eventuales retrasos y
      desviaciones ocurridas.
    • Gerente o coordinador de proyecto sigue la evolución y trabaja en la comunicación y alineación con el
      Comité del Proyecto/Cliente.
    Resultados/
    Criterios
    de salida

    Solución probada en todas sus funcionalidades, procesos y escenarios, considerando incluso los resultados de negocio (que dependen de aspectos de registros y reglas de negocio), Guia de prueba - MIT045 y Término de Validación - MIT010 (Término de Homologación) firmado.

    Actividades

    Definición de la Prueba de Transición (Mejor Práctica)

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Especialista
    • Usuarios clave (responsables de la ejecución)
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    Contexto

    Es fundamental restringir el lanzamiento oficial del sistema a los usuarios clave, para que puedan realizar
    actividades reales en el sistema ya en el entorno de producción, garantizando el funcionamiento esencial del negocio, considerando todos los procesos críticos.

    Acciones/
    Descriptivo
    de la
    actividad
    • Usuarios clave definen las operaciones críticas como criterios de GO LIVE, justo después de la
      ejecución del Cutover
    • Gerente o coordinador del proyecto:
      • Hace el seguimiento de las definiciones y evalúa si están de acuerdo con los criterios de
        calidad establecidos
      • Al final, registra la decisión en el Guia de Pruebas - MIT045.
    Resultados/
    Criterios
    de salida
    Guia de Pruebas actualizado - MIT045.

    Definición/Revisión del Plan de Transición

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Especialista
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    • Usuarios clave (Cliente)
    • Cloud TOTVS (cuando hay servicio host)
    Contexto

    La definición/revisión del plan de transición debe realizarse inmediatamente después de obtener los
    resultados de las Pruebas Integradas y Validación de la Solución, donde se dispone de más detalles sobre las
    necesidades de suspensión del sistema, sobre los cambios de proceso en el negocio, sobre el impacto en otras
    áreas, etc.
    Es importante que cualquier nuevo problema que surja se trate en este momento, evitando así posponer un
    problema que pueda traer impactos negativos a todo el proyecto.

    Acciones/
    Descriptivo
    de la
    actividad
    • Analista/especialista y usuarios clave (Cliente) reevalúan los detalles de los impactos en la transición
      del sistema a la producción después de los resultados, considerando aspectos técnicos y funcionales:
    • Técnicos
      o Acciones de entorno (infraestructura)
      o Acciones de configuración
      o Acciones de transporte de datos
      o Acciones ecualización de personalizaciones
      o Acciones de actualización de la aplicación (software), que pueden transcurrir a lo largo del
      proyecto
      o Preparación de actividades Cloud (cuando hay servicios de host).
    • Funcionales:
      o Alineación con áreas que pueden sufrir impacto con el período de suspensión (ejecución de
      cutover)
      o Alineación con los Clientes sobre la misma pregunta
      o Alineación con proveedores y asociados en la misma pregunta
      o Capacitación y preparación de los cambios operativos (procesos TO BE)
      o Plan de contingencia de negocio
    • Comité de Proyecto aprueba la revisión del Plan de giro y Retroceso - MIT054
    Resultados/
    Criterios
    de salida

    Plan de Transición y Rollback - MIT054 revisado con las partes interesadas correctamente alineadas.

    Aprobación y divulgación de la transición

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Analista/Especialista
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    • Usuarios clave (Cliente)
    • Soporte TOTVS (Opcional)
    Contexto

    La aprobación del Comité (decisión de GO) debe ir seguida de una divulgación oficial de la liberación de la ejecución de la Transición a todos los interesados para que:

    • Todas las áreas involucradas, Clientes, Proveedores y Asociados puedan programar adecuadamente y/o combinar planes de contingencia
    • El proyecto gane fuerza política y estratégica en la Organización
    • El proyecto tenga un compromiso final, porque en este momento es fundamental que todos pongan la adecuada prioridad de su tiempo a favor de la calidad de la transición.
    Acciones/
    Descriptivo
    de la
    actividad
    Resultados/
    Criterios
    de salida

    Plan de giro y Retroceso - MIT054 aprobado y divulgado oficialmente entre todas las partes interesadas
    del Proyecto

    Atividades

    Finalización de la fase y evaluación de Quality Gate

    Insumos/
    Criterios de
    entrada
    Papeles
    involucrados
    • Gerente o coordinador del proyecto
    • Coordinador o Comité de Proyecto por parte del Cliente
    • Cliente
    Contexto

    Revisión del gate y conclusión de las entregas de fase

    Acciones/
    Descriptivo
    de la
    actividad
    • Gerente o coordinador del proyecto revisan los entregables de la fase.
    Resultados/
    Criterios
    de salida
    • Revisión del Gate y entregables de la fase completados

    Which is?

    It is the actual building on the detailed design approved in the previous stage.

    This construction implies the availability of work environments, execution of system configuration sprints, development of customizations, data loads and delivery validation, through technical and business cycles.

    It is important to define which critical tests must be performed in the transition (turnover) and to review the plan for the system’s turn over to the production environment.

    Construction and testing are based on Sprints based on the backlog. The execution of the turnover plan and the integrated testing occur at this stage.

    To recapitulate, the purpose of this group of tasks is to control the construction of the system within the approved design, ensuring the fulfillment of the requirements and a smooth turnover plan, managing the delivery within the planning approved by the Customer.

    Deliverables

    Activities

    Product configuration

    Inputs/Entry Criteria
    Roles involved
    • Deployment Analyst/Consultant
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    It is at this stage that the product configuration occurs as agreed and approved by the customer, respecting what was defined in the refinement stage and prioritized for each sprint.
    In the event that unforeseen issues arise or are addressed in the previous stage, these will be discussed by the team at Sprint retrospective meetings and depending on the issue, a Change Request must be recorded in order to evaluate the impact and obtain its formal appr oval, which can change the deadline, cost or quality defined during the Solution Refinement.
    Deliveries occur through Sprints (iterations) with defined time (ideally 2 to 4 weeks) and each Sprint must deliver an increment of the product that may or may not be validated with the customer, according to the release schedule (Sprint groups).
    The following ceremonies are expected to take place during each Sprint cycle:


    Sprint Planning: Ceremony to define the sprint’s purpose, scope of work, how and what will be
    delivered.
    Iteration Meeting (“Daily”): This is the sprint follow-up meeting, where its progress is checked.
    Short duration (no more than 30 min), in which each member reflects on: What did you do from
    yesterday to today?, What will I do from today to tomorrow?, Are there any hindrances?
    The recurrence of the meeting can be defined according to the context of each project and can be
    conducted with the entire project team with or without the participation of the Project Coordinator
    or Manager.

    NOTE: It is recommended to organize several Change Requests – TIM031 together to have a better
    perception of the impacts, instead of evaluating them individually. To that end, it is possible to stipulate
    scheduled times/dates to request, evaluate and approve the demand.

    Activity description/actions
    • During the Sprint, the Deployment Analyst or Consultant:

    o Configures the system based on the Process Diagram approved by the Customer and prioritized backlog for the Sprint.
    o Reports the progress, risks or issues found, any delays and deviations that occurred through the iteration meetings or the daily meetings.

    • The Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee or Customer.

    • At the end of each Sprint, a retrospective meeting is expected to be held with the entire team that participated in the Sprint.

    • After the completion of each Sprint, a new iteration cycle begins until the entire product backlog is delivered.

    Result/Exit Criteria

    Backlog/Development of Customizations

    Inputs/Entry Criteria
    Roles involved
    • Developer (Software Factory)
    • Technical Lead (Software Factory)
    • Deployment Analyst/Consultant
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    The development of customizations must follow that agreed and approved by the Customer, i.e. follow what was defined in the TIM041 Process Diagram.

    Activity description/ actions
    • Technical Lead organizes deliveries with the development team (Backlog/Sprints/Deploy)
    • Factory Team performs development as requested based on Customization Specifications and Logical Project (PL)
    • Software Factory Technical Lead:
      o Reports progress, risks/issues found, possible delays and deviations that occurred
      o Sends the evidence of the test performed, showing the positive result.
    • Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
    Result/Exit Criteria
    • Customizations developed.

    Activities

    Training of Key Users

    Inputs/Entry Criteria
    Roles involved
    • Deployment Analyst/Consultant
    • Key Users (Customer)
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    This training should lead key users to the effective use of the system in accordance with the approved Solution Design.
    It is important to remember the commitment aligned in the preparation/Project Kickoff Meeting, that the key users are responsible for replicating the knowledge and also for any support.

    Activity description/ actions
    • Analysts / Consultants and Key Users meet according to the training plan carried out in Refinement
    • Analysts or Consultants provide training in accordance with the approved Solution Design and respective configurations.
    • Key Users:

    o They must absorb the knowledge and deepen the system in practice to ensure efficient use

    o Formalize the receipt of knowledge and use of the system with the Consultants who provided the training

    • Project Manager or Coordinator organizes the formalizations and carries out the validation of this stage with the Project Committee
    • The Project Committee approves the training by signing the Training Script - TIM037.
    Result/Exit Criteria

    Training script - MIT037 sent to the key user for approval via signature of the Training carried out.

    Activities

    Data Load

    Inputs/Entry Criteria
    Roles involved
    • Deployment Analyst/Consultant
    • Key Users (Customer)
    • IT (Customer), if any
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    At this time, the identified and planned loads are conducted, following the stipulated method, by the respective persons in charge of such task.
    It is equally important to have validation criteria to ensure that the load has been successful, to ensure that the following tests and validations can generate the expected results.

    NOTE: In cases of manual loading, i.e. data entered manually by key users, the effort and deadlines
    must be carefully agreed to ensure a well-aligned schedule.

    Activity description/ actions
    • Deployment Analyst(s)/Consultant(s) perform the data loads with defined routines/tools, as planned
      and aligned during the Refinement stage.
    • Key users:
    • Perform data loads manually as planned and aligned during the Refinement stage.
    • Validate the migrated data, by one method or another, using the agreed tools.
    • Users and Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations
      that occurred.
    • Project Manager or Coordinator monitors progress and works on communication and alignment with
      the Project Committee/Customer.
    Result/Exit Criteria

    Planned data available and validated in the system, Data Conversion Roadmap - MIT053 and Interface
    Script - MIT055
    , updated.

    Activities

    Unit Tests

    Inputs/Entry Criteria
    Roles involved
    • Deployment analyst/consultant
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    The main purpose of this task is to guarantee the functioning of the system so that key users can effectively validate the solution. Therefore, the target of these tests should be more focused on executing the routines and less focused on the expected results, such as the correct calculation of taxes, for example.
    o NOTE: This priority division occurs because a large part of the expected results is directly related to
    the registrations and the business itself. That is why it is customary to plan cycles with different aspects.

    Activity description/actions
    • Implementation Analyst(s)/Consultant(s), usually in conjunction with the IT team, perform the tests
      developed in the Test Procedure with a focus on the functioning of the system, in order to guarantee
      its availability to key users in the effective validation.
    • Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
    • Project Manager or Coordinator monitors progress and works on communication and alignment with
      the Project Committee/Customer.
    Result/Exit Criteria

    System tested in all its features, without considering business results (which depend on aspects of registration and business rules) and Test Script - TIM045 updated.

    Integrated System Testing – TOTVS Team

    Inputs/Entry Criteria
    Roles involved
    • Deployment analyst/consultant
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    • TOTVS Support (Optional)
    Context

    The main purpose of this task is to ensure, in addition to the functioning of the system, that the expected results are validated, as well as the processes and their different scenarios. In some cases, the system load test is included after the integrated tests.

    Activity description/ actions
    • Analyst(s)/Consultant(s) are organized according to the plan to perform the overall validation of the solution.
      o NOTE 1: at this stage, with the system fully operational, the processes and their different scenarios must be validated and the expected results verified.
    • Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
    • Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
      o NOTE 2: the Project Manager or Coordinator can identify the need to conduct a load test on the system, which must be performed at this stage, using a Validation Statement document – TIM010 with the results of the tests.
    Result/ Exit Criteria
    • Solution tested in all its features, processes and scenarios, also considering business results (which depend on aspects of registration and business rules) and Test Script - TIM045 updated.
    • If applicable, the Validation Term - TIM010 with the result of the load tests.

    Integrated System Testing – Customer Team

    Inputs/Entry Criteria
    Roles involved
    • Deployment analyst/consultant
    • Key Users (Customer)
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    The main purpose of this task is to ensure, in addition to the functioning of the system, that the expected results are validated, as well as the processes and their different scenarios.

    Activity description/ actions
    • Analyst(s)/Consultant(s) and Key Users are organized according to the plan to perform the overall validation of the solution.
      o NOTE: at this stage, with the system fully operational, the processes and their different scenarios must be validated and the expected results verified.
    • Analyst(s)/Consultant(s) report progress, risks/issues found, possible delays and deviations that occurred.
    • Project Manager or Coordinator monitors progress and works on communication and alignment with the Project Committee/Customer.
    Result/Exit Criteria

    Solution tested in all its features, processes and scenarios, also considering business results (which depend on aspects of registration and business rules), Test Script - TIM045 and Validation Term - TIM010 Ratification Statement) signed.

    Activities

    Turnover Testing Definition (Best Practice)

    Inputs/Entry Criteria
    Roles
    involved
    • Analyst/Expert
    • Key Users (person responsible for the execution)
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    Context

    It is essential to restrict the official release of the system to key users, so that they can perform real activities
    in the system already in the Production environment, guaranteeing the essential functioning of the business, considering all critical processes.

    Activity
    description/
    actions
    • Key Users define critical operations as a GO LIVE criterion, right after the Cutover is executed
    • Project Manager or Coordinator:
      o Monitor definitions and assess whether they meet the established quality criteria
      o At the end, record the decision in the Test Script - TIM045.
    Result/Exit Criteria Updated Test Script - TIM045.

    Definition/Review of the Turnover Plan

    Inputs/Entry Criteria
    Roles involved
    • Analyst/Expert
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    • Key Users (Customer)
    • TOTVS Cloud (when there are host services)
    Context

    The Definition/Review of the turnover plan must be conducted immediately after obtaining the results of the Integrated Tests and Solution Validation, where there are more details about the needs for suspension of the system, changes in the business process, the impact on other areas etc.


    It is important that any new issue that arises be addressed at this time, thus avoiding postponing a problem that may cause negative impacts to the entire project.

    Activity description/actions
    • Analyst/Expert and Key Users (Customer) reassess the details of the impacts on the system transition
      to Production after results, considering technical and functional aspects:
    • Technical:
      o Environment actions (infrastructure)
      o Configuration actions
      o Data transport actions
      o Customization equalization actions
      o Update application actions (software), which can take place throughout the project
      o Preparation of Cloud activities (when there are host services).
    • Functional:
      o Alignment with areas that may be impacted by the suspension period (cutover execution)
      o Alignment with Customers on the same issue
      o Alignment with Suppliers and Partners on the same issue
      o Training and preparation of operational changes (TO BE processes)
      o Business Contingency Plan
    • Project Committee approves the review of the Turnover and Rollback plan – TIM054
    Result/Exit Criteria

    Turn and Rollback Plan - TIM054 reviewed with properly aligned stakeholders.

    Turnover Approval and Disclosure

    Inputs/Entry Criteria
    Roles involved
    • Analyst/Expert
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    • Key Users (Customer)
    • TOTVS Support (Optional)
    Context

    The Committee's approval (GO decision) must be followed by an official release of the Transition execution to all stakeholders so that:

    • All areas involved, Customer, Suppliers and Partners can properly plan and/or agree on contingency plans
    • The project gains political and strategic strength in the Organization
    • The project must have final engagement, because at this moment it is essential that everyone appropriately prioritize their time in favor of the quality of the transition.
    Activity description/ actions
    Result/Exit Criteria

    Turn and Rollback Plan - TIM054 officially approved and disclosed to all Project stakeholders

    Activities

    Stage completion and Quality Gate evaluation

    Inputs/Entry Criteria
    Roles involved
    • Project Manager or Coordinator
    • Customer’s Project Coordinator or Committee
    • Customer
    Context

    Gate review and completion of stage deliveries

    Activity description/actions
    • Project Manager or Coordinator reviews the deliverables for the stage.
    Result/Exit Criteria
    • Gate review and stage deliverables completed
    • Sem rótulos