Tribunal de Justiça de Pernambuco Diretoria de Informática Guia de Utilização do Mantis Máquina de Estados
Guia de Utilização Mantis Histórico de Alterações Data Versão Descrição Autor Aprovado Por 02/09/2008 00.01 Criação do documento. Jeane Mendes 18/09/2008 00.02 Atualização do documento com Jeane Mendes necessidades de alteração de André Poroca e Cristiano. 23/09/2008 00.03 Alteração no detalhamento da máquina de estados inserindo Jeane Mendes / Arthur Henriques informações relevantes. 03/10/2008 00.04 Atualização do documento para contemplar a interação entre Laísa Nascimento / Arthur Henriques GEDES e UGBD. Alterações na estrutura da seção que apresenta o detalhamento da máquina de estados. 19/12/2008 00.05 Atualização das Seções 2.2 e 2.3, Laísa Nascimento acrescentando detalhes acerca do registro de informações quando o software é liberado pela UES para homologação. 26/01/2009 00.06 Atualização do documento para Laísa Nascimento atender as mudanças referentes à nova máquina de estados. 10/02/2009 00.07 Atualização do documento para Laísa Nascimento atender a mudança dos nomes dos estados. Os nomes dos estados da máquina foram alterados para que a nova máquina contemple as ocorrências já existentes, que seguiam a máquina da versão 00.05 deste documento. A nova máquina também foi simplificada com relação à máquina da versão 00.06 desse documento. 11/03/2009 00.08 Atualização do documento Laísa Nascimento Página 2 de 22
Guia de Utilização Mantis acrescentando texto explicativo sobre a mudança de estado quando o analista encontra problemas durante a homologação 04/05/2009 00.09 Alterações nas Seções 1.0 e 2.1. Laísa Nascimento Criação da Seção 2.4 07/05/2009 00.10 Alteração nas Seções 2.2 e 2.4. Juliana Xavier 08/05/2009 00.11 Alteração na seção 2.4 Melhoria e Arthur Henriques campo Descrição Índice de tabelas e descrição da tabela 1 19/05/2009 00.12 Alteração do e-mail da Unidade de Arthur Henriques Qualidade de Desenvolvimento na pág. 7. 28/05/2009 00.13 Alteração da Seção 2.3. Inclusão de Laísa Nascimento texto explicativo acerca do procedimento de solicitação de serviços à GEPROD. 01/06/2009 00.14 Substituição em todo o texto dos Arthur Henriques Versão não publicada termos caso e ocorrência por solicitação. Substituição em todo o texto do termo...colocando como responsável... por... a solicitação é atribuída a.... Reestruturação da seção 2.5 Categorias e estruturas de texto requeridas para abertura de solicitação. 10/06/2009 00.15 Criação da Seção 2.2 Laísa Nascimento 23/07/2009 00.16 Inclusão do estado REJEITADO na máquina de estados e seus relacionamentos com os demais estados. Atualização dos diagramas. Retirada do diagrama de sequência (figura 2). Atualização da seção 2.4 Arthur Página 3 de 22
Guia de Utilização Mantis 3/08/2009 00.17 Alteração Seção 2.4 Fluxo de Arthur estados alternativo adotado na interação com as demais gerências. Nova máquina de estados para interação UES/UGBD 11/11/2009 0.18 Atualização da nova máquina de Juliana Xavier estados para interação UES/UGBD. 24/11/2009 0.19 Atualização do fluxo de implantação Juliana Xavier após a sua validação junto à UGBD e UGAPL.. 07/01/10 0.20 Atualização do fluxo de implantação Juliana Xavier após a apresentação aos Analistas de Negócio. Exclusão das seções 2.4 e 2.6.2. 22/01/10 0.21 Alterar a seção 2.5.1.2 para tornar o Juliana Xavier campo Critérios de Aceitação opcional. 05/02/10 0.22 Alteração da máquina de estados de Juliana Xavier solicitação de mudança e de implantação do sistema. 11/02/10 1.0 Alteração do responsável por colocar as solicitações filha em produção (seção 2.4). Juliana Xavier 26/03/10 1.1 Detalhamento de procedimentos Gustavo Carvalho realizados durante o uso do fluxo de estados adotado na GEDES e alteração da estrutura de texto padrão. 09/04/10 1.2 Alterando o texto para deixar claro Gustavo Carvalho que a estrutura padrão deve ser inserida no campo Descrição do Mantis. 20/05/10 1.3 Inclusão da máquina de estados de Gustavo Carvalho erros para fábricas externas. 21/06/10 1.4 Alteração na seção 2.5. Juliana Xavier Ana Luisa 02/08/10 1.5 Alteração da seção 2.6.1.2 para Juliana Xavier Página 4 de 22
Guia de Utilização Mantis tornar o campo Impacto obrigatório. 02/09/10 1.6 Alteração da seção 2.3 para indicar a quem deve ser atribuída a solicitação homologada pelo Analista. 01/10/10 1.7 Alteração da seção 2.3 para incluir o procedimento de verificação do sistema em produção pelo Analista de Negócio. Juliana Xavier Juliana Xavier Página 5 de 22
Guia de Utilização Mantis Índice 1.1 Público alvo...7 1.2 Convenções, termos e abreviações...7 2.1 Acesso ao sistema...8 2.2 Organização dos Projetos...8 2.3 Fluxo de estados adotado na GEDES...10 2.4 Fluxo de estados para implantação de sistemas...14 2.5 Fluxo de estados para correção de erros por Fábricas Externas...18 2.6 Categorias e estruturas de texto requeridas para abertura de solicitação...20 2.6.1 Na interação entre UN e Fábrica de Software...20 2.6.1.1 Categorias...20 2.6.1.2 Estrutura de texto padrão...21 Página 6 de 22
Índice de Figuras Figura 1 Fluxo da Solicitação de Mudança...12 Figura 2 Fluxo de Implantação do Sistema...15 Figura 3 Fluxo de Solicitação de Correção de Erros para Fábricas Externas...19 Índice de Tabelas Tabela 1 - Requisitos para preenchimento de abertura de casos de UN para Fábrica de Software...19
1 Introdução Este documento compreende as informações pertinentes ao detalhamento da forma de utilização do sistema Mantis pela Gerência de Desenvolvimento do Tribunal de Justiça de Pernambuco. A Seção 2 compreende: acesso ao sistema, organização de projetos, fluxos de estados, categorias e estruturas de texto padronizadas. As Seções 2.3 e 2.4 descrevem os estados existentes e o fluxo entre eles. O foco da Seção 2.5 está nas informações que devem ser relatadas ao se criar uma solicitação. 1.1 Público alvo Este documento destina-se a todos os trabalhadores envolvidos em projetos desenvolvidos pela GEDES e interessados em geral. 1.2 Convenções, termos e abreviações Esta seção explica o conceito de alguns termos importantes que serão mencionados no decorrer do documento. Estes termos são descritos na tabela a seguir, estando apresentados por ordem alfabética. Convenções, termos e abreviações. Termo Descrição DINFO GEDES GEPROD Scrum Sprint TJPE UES UGAPL UGCPD UGBD UN UTS Diretoria de Informática Gerência de Desenvolvimento do TJPE Gerência de Produção do TJPE Metodologia ágil para gerenciamento de projetos Iteração que segue o ciclo PDCA (Plan Do Check Act) e entrega incremento de software pronto Tribunal de Justiça de Pernambuco Unidade de Engenharia de Software Unidade de Gerenciamento de Aplicações Unidade de Gerenciamento do CPD Unidade de Gerenciamento de Banco de Dados Unidade de Negócio Unidade de Testes de Software
Termo Descrição 2 Mantis A solução Mantis Bug Tracker é originalmente um sistema responsável pela gerência de bugs em sistemas, organizando-os em categorias, clientes, entre outras características. Seu uso foi estendido para se tornar um gerenciador de solicitações em projetos e, portanto, serve como um centralizador de solicitações relacionadas ao desenvolvimento de sistemas pela Gerência de Desenvolvimento do Tribunal de Justiça de Pernambuco em seus diversos projetos. 2.1 Acesso ao sistema Para que o usuário possa acessar o Mantis e seus sistemas contidos, ele precisa estar previamente cadastrado. O cadastramento é realizado preferencialmente pelo chefe da unidade onde o novo usuário está alocado. Caso o chefe não use o Mantis ou não tenha perfil de Gerente no mesmo, a solicitação de criação de conta pode ser realizada via e-mail à Unidade de Gerenciamento de Aplicações (dinfo.ugapl@tjpe.jus.br). Na solicitação de cadastramento deve ser informado o e-mail e o nome do usuário, além dos sistemas aos quais o usuário deve ter acesso. A utilização do sistema deve ser feita acessando o endereço http://www.tjpe.jus.br/mantis, onde devem ser informados o login e a senha do usuário pré-cadastrado. 2.2 Organização dos Projetos O Mantis está organizado por Projetos. Cada projeto está associado a uma unidade/sistema e tem como participantes as pessoas envolvidas no projeto: analistas, desenvolvedores, clientes. A criação de um projeto é responsabilidade do gerente do projeto, que deve ter os seguintes cuidados no momento da criação: 1. Identificar o local de criação. Um projeto pode estar na raiz ou ser subprojeto de um projeto já existente. O criador deve ficar atento para o local correto de criação do sistema, pois deve respeitar a estrutura já existente (descrita mais adiante). 2. Verificar se o projeto está privado. Caso seja criado como público, todos os usuários do Mantis terão acesso ao projeto. 3. Inserir os participantes. Ao ser criado, um projeto não tem participantes. É necessário que o o criador inclua todos os usuários do Mantis que participarão do projeto, caso contrário, eles não visualizarão e conseqüentemente não acessarão o projeto. Cada participante deve
ser adicionado com o perfil adequado. Idealmente, um projeto deve ter apenas um participante com o perfil de gerente. 4. Inserir as categorias. Toda solicitação Mantis requer uma categoria associada (ver Seção ). Ao criar um projeto, é necessário inserir as categorias que farão parte do projeto. Caso não sejam inseridas, alguns participantes (dependendo do perfil de usuário no projeto) não conseguirão abrir uma solicitação, visto que a categoria é um campo obrigatório na abertura de uma solicitação. Cada unidade possui seu projeto e respectivos subprojetos. A necessidade de um novo projeto deve ser avaliada/autorizada pelo chefe da unidade e a criação realizada por algum membro (chefe ou não) da unidade que possua perfil de gerente no Mantis. Cada unidade de negócio e a unidade de engenharia de software têm subprojetos que devem ser utilizados conforme a necessidade de cada uma.
2.3 Fluxo de estados para Solicitações de Mudança Esta seção apresenta o fluxo de estados seguido por cada solicitação de criação ou melhoria dos sistemas que estão sob responsabilidade da Gerência de Desenvolvimento do Tribunal de Justiça de Pernambuco. O ciclo de vida de uma solicitação segue os estados presentes no fluxo. No Mantis, para cada estado (ou Status) em que se encontra a solicitação haverá um responsável (campo atribuído a ) que garantirá que as atividades associadas àquele estado serão realizadas. A Figura 1 apresenta o fluxo de estados definido. Uma solicitação deve ser criada no Mantis (Opção Relatar Caso) a partir de uma demanda para criação de um novo sistema ou por necessidade de melhoria em um sistema já existente. A solicitação é então associada ao projeto da unidade de destino ao qual está relacionada 1. O estado inicial da solicitação de mudança é EM ANÁLISE. Enquanto o analista responsável estiver avaliando a solicitação e elaborando a documentação necessária, a solicitação continua no estado EM ANÁLISE. Ao finalizar as atividades de análise, o analista atribui a solicitação para a Fábrica de Software e altera o seu estado para A EXECUTAR. Caso a Fábrica de Software/TIME SCRUM detecte que as declarações na abertura do caso não são satisfatórias, modifica o estado para REJEITADO, encaminha de volta a solicitação com a justificativa da rejeição para o analista responsável e aguarda nova atribuição para a Fábrica de Software. Enquanto o analista estiver fazendo as devidas modificações na especificação, a solicitação ficará no estado EM ANÁLISE. Após o término da análise, o analista modifica o estado da solicitação para A EXECUTAR e a encaminha de volta para a Fábrica de Software. Ao iniciar o projeto ou a sprint, o TIME SCRUM que ficar responsável pela resolução da solicitação altera o seu estado para EM EXECUÇÃO e atribui ao time a solicitação. Quando o TIME SCRUM concluir as atividades relacionadas à solicitação inicial, deverá atribuir o caso para a UTS ou UN, dependendo se a solicitação será testada pela Equipe de Testes. Caso a Equipe de Testes esteja participando da sprint, o responsável pela sprint ou projeto deverá atribuir o caso para a UTS, mas não muda o seu estado, ou seja, a solicitação permanece EM EXECUÇÃO. Ao iniciar os testes, a UTS deve colocar a solicitação para o estado EM TESTES. Caso sejam encontrados erros durante os testes, e este for diretamente relacionado ao caso testado, a UTS modifica o estado para REJEITADO e encaminha de volta a solicitação à Fábrica de Software. Se o erro encontrado não for diretamente relacionado ao caso testado, a UTS deve criar um novo caso no Mantis que descreve o erro encontrado. Em seguida, a UTS deve atribuir este novo caso ao analista de negócio da UN responsável. Este novo caso entrará na priorização do analista e, possivelmente, entrará no escopo da próxima sprint. Caso o erro seja crítico (impeditivo) e se o time de desenvolvimento tiver como corrigi-lo dentro do prazo da sprint (ou 1 O projeto relacionado está entre os projetos existentes na unidade a qual se destina a solicitação.
por alguma folga natural ou por retirar outros casos do escopo), o caso criado poderá entrar ainda no escopo da sprint corrente. Após a correção dos erros encontrados pela UTS, o seguinte procedimento deve ser adotado: o TIME SCRUM deve atribuir de novo o caso corrigido para a UTS, caso ainda se esteja dentro do período de desenvolvimento da sprint, para que esta valide a correção. Caso já esteja em tempo de liberar para homologação, a correção deve ser diretamente atribuída para a UN e ter o seu estado modificado para LIBERADO PARA HOMOLOGAÇÃO. Para os que não forem encontrados erros, a UTS deve atribuir o caso para a Gerência de Configuração. A partir daí, a Gerência de Configuração prepara o ambiente de homologação, atribui o caso para a UN e muda o estado da solicitação para LIBERADO PARA HOMOLOGAÇÃO. Caso a Equipe de Testes não esteja participando da sprint, o responsável pela sprint ou projeto atribui a solicitação para a UN e muda o estado da solicitação para LIBERADO PARA HOMOLOGAÇÃO.
Figura 1 Fluxo da Solicitação de Mudança Ao receber a solicitação no estado LIBERADO PARA HOMOLOGAÇÃO, o Analista de Negócio inicia a homologação e altera o estado do caso para EM HOMOLOGAÇÃO. Caso sejam encontrados erros durante a homologação, o analista responsável modifica o estado para REJEITADO e encaminha de volta a solicitação à Unidade de Engenharia de Software responsável. Na Unidade de Engenharia de Software será avaliada a atividade necessária para a correção e a solicitação poderá ter o estado modificado para EM EXECUÇÃO. Após as atividades de correção, o responsável pelo projeto ou sprint atribui a solicitação para a UN e muda o estado da solicitação para LIBERADO PARA HOMOLOGAÇÃO. Ao finalizar as atividades de homologação, o analista promoverá o estado para HOMOLOGADO. Caso não seja o momento de colocar a solicitação em produção, ela deve continuar atribuída ao Analista de Negócio. Quando chegar o momento da solicitação ir para Produção, a mesma deve ser atribuída à Gerência de Configuração. A partir daí, a Gerência de Configuração cria uma nova solicitação de mudança para implantação seguindo o fluxo descrito na seção 2.4. Se erros forem detectados em casos já homologados, mas que ainda não entraram em produção, devese atribuir o caso para a Unidade de Engenharia de Software responsável e mudar o estado deste para REJEITADO. Se este caso fizer parte do escopo da sprint corrente, o time deverá tentar corrigir o erro ainda na mesma sprint. Contudo, se o caso não fizer parte do escopo da sprint corrente, três situações podem ocorrer: (a) o time tenta corrigir o erro ainda na sprint corrente porque há folga; (b) negocia-se a saída de outros casos para tentar corrigir o erro ainda na sprint corrente; (c) a correção do erro fica para sprints futuras. Depois que o sistema tiver sido colocado em produção, a Gerência de Configuração atribui a solicitação de mudança novamente para o Analista de Negócio no estado EM PRODUÇÃO. O Analista de Negócio, por sua vez, deve verificar se realmente o sistema modificado está funcionando corretamente em produção. Em caso positivo, o Analista deve atribuir a solicitação para o usuário null e adicionar uma anotação ao caso do
mantis informando que essa verificação foi realizada. Caso o Analista encontre algum problema no sistema em produção, deve colocar a solicitação no estado REJEITADO e atribuí-la novamente à Unidade de Engenharia de Software responsável. Estado IMPEDIMENTO O estado de impedimento pode ser utilizado em vários momentos durante o ciclo de vida da solicitação. Ele indica que existe algum impedimento que está impossibilitando o andamento das atividades. O impedimento pode ser de dois tipos: Impedimento Interno: Indica algum obstáculo na resolução da solicitação que independe da intervenção de outras unidades. Não provoca mudança de atribuição da solicitação, e o motivo do impedimento deverá ficar descrito como anotação. Por exemplo: agendamento de reuniões internas, dependências com outras atividades, erros de configuração de ambiente e/ ou componentes, etc. Impedimento Externo: Indica algum obstáculo na resolução da solicitação que depende da intervenção de outras unidades. Não provoca mudança de atribuição da solicitação e o motivo do impedimento deverá ficar descrito como anotação. Por exemplo: agendamento de reuniões com os usuários, esclarecimento de requisitos, restrições de acesso, etc. Os dois tipos de impedimento são representados pelo estado IMPEDIMENTO. Estado REJEITADO O estado REJEITADO poderá ser utilizado: Quando não houver subsídios satisfatórios na solicitação para a implementação da solução ou quando a especificação da solicitação não se encontrar plenamente compreensível; Quando houver necessidade de correção no sistema detectada durante a homologação; Quando for necessário reabrir uma solicitação que já estava homologada. Em todos os casos deverá ser feita a justificativa da rejeição no campo Anotação do caso Mantis. Os casos rejeitados deverão ser atribuídos ao responsável pela resolução do problema identificado. Quando a rejeição for resultante de uma decisão gerencial, a solicitação será atribuída ao gestor do sistema que decidirá sobre a solução.
2.4 Fluxo de estados para implantação de sistemas Sistema WEB Quando um sistema WEB estiver pronto para ser posto em produção, a Gerência de Configuração cria uma solicitação (Opção Relatar Caso) para implantação do sistema. Nesse momento, a solicitação ficará no estado GERAÇÃO RELEASE. A Gerência de Configuração analisa o caso e, se houver alguma inconsistência, a solicitação deverá ser rejeitada (estado: REJEITADO). Quando a equipe resolver as pendências identificadas, o responsável pelo projeto deve retornar o caso para o estado GERAÇÃO RELEASE e atribuí-lo novamente à Gerência de Configuração. O caso continuará nesse estado até que o pacote esteja pronto para a produção e possa ser remetido para a unidade responsável. Caso haja necessidade de alteração no Banco de Dados, a Gerência de Configuração atribui a solicitação para a Unidade de Gerenciamento de Banco de Dados e muda o seu estado para EXECUÇÃO SCRIPT. A UGBD, por sua vez, analisa os scripts que devem ser executados e, caso não haja nenhum problema, executa os scripts enviados. Caso identifique algum problema na execução dos scripts, a UGBD deve rejeitar o caso (estado: REJEITADO) e atribuí-lo para o representante da Fábrica de Software responsável pelo projeto/sprint. Uma vez corrigido o problema, o responsável pelo projeto/sprint atribui o caso novamente para a UGBD e altera o estado do caso para EXECUÇÃO SCRIPT. Quando as alterações necessárias no banco de dados forem executadas com sucesso, a UGBD deve atribuir o caso de volta para a Gerência de Configuração e alterar o estado do caso para BANCO EM PRODUÇÃO. A Gerência de Configuração deve atribuir a solicitação para a UGAPL, e mudar o seu o estado para LIBERAÇÃO RELEASE. Enquanto a UGAPL estiver executando os procedimentos necessários para colocar o sistema em produção, a solicitação continua no estado LIBERAÇÃO RELEASE. Ao colocar o sistema efetivamente no ar, a UGAPL muda no estado para solicitação para EM PRODUÇÃO. Feito isso, a Unidade de Aplicações retorna a solicitação à Gerência de Configuração. A partir daí, a Gerência de Configuração verifica se o sistema está realmente em produção e coloca as solicitações filha do pacote no estado EM PRODUÇÃO. Esse fluxo está representado na Figura 2.
Figura 2 Fluxo de Implantação do Sistema Sistema Delphi Quando um sistema em delphi estiver pronto para ser posto em produção, a Gerência de Configuração cria uma solicitação (Opção Relatar Caso) para implantação do sistema. Nesse momento, a solicitação ficará no estado GERAÇÃO RELEASE. A Gerência de Configuração analisa o caso e, se houver alguma inconsistência, a solicitação deverá ser rejeitada (estado: REJEITADO). Quando a equipe resolver as pendências identificadas, o responsável pelo projeto deve retornar o caso para o estado GERAÇÃO RELEASE e atribuí-lo novamente à Gerência de Configuração. O caso continuará nesse estado até que o pacote esteja pronto para a produção e possa ser remetido para a unidade responsável. Caso haja necessidade de alteração no Banco de Dados, a Gerência de Configuração atribui a solicitação para a Unidade de Gerenciamento de Banco de Dados e muda o seu estado para EXECUÇÃO SCRIPT. A UGBD, por sua vez, analisa os scripts que devem ser executados e, caso não haja nenhum
problema, executa os scripts enviados. Caso identifique algum problema na execução dos scripts, a UGBD deve rejeitar o caso (estado: REJEITADO) e atribuí-lo para o representante da Fábrica de Software responsável pelo projeto/sprint. Uma vez corrigido o problema, o responsável pelo projeto/sprint atribui o caso novamente para a UGBD e altera o estado do caso para EXECUÇÃO SCRIPT. Quando as alterações necessárias no banco de dados forem executadas com sucesso, a UGBD deve atribuir o caso de volta para a Gerência de Configuração e alterar o estado do caso para BANCO EM PRODUÇÃO. A partir daí, a Gerência de Configuração deve colocar o novo sistema no ar (estado: EM PRODUÇÃO) e as solicitações filha do pacote no estado EM PRODUÇÃO. Sistema de Distribuição por várias Cidades Quando um sistema precisar ser distribuído em várias cidades (Ex.: Juizados Cíveis, Criminal, Judwin 1 o Grau) e estiver pronto para ser posto em produção, a Gerência de Configuração cria uma solicitação (Opção Relatar Caso) para implantação do sistema. Nesse momento, a solicitação ficará no estado GERAÇÃO RELEASE. A Gerência de Configuração analisa o caso e, se houver alguma inconsistência, a solicitação deverá ser rejeitada (estado: REJEITADO). Quando a equipe resolver as pendências identificadas, o responsável pelo projeto deve retornar o caso para o estado GERAÇÃO RELEASE e atribuí-lo novamente à Gerência de Configuração. O caso continuará nesse estado até que o pacote esteja pronto para a produção e possa ser remetido para a unidade responsável. Caso haja necessidade de alteração no Banco de Dados, a Gerência de Configuração atribui a solicitação para a Unidade de Gerenciamento de Banco de Dados e muda o seu estado para EXECUÇÃO SCRIPT. A UGBD, por sua vez, analisa os scripts que devem ser executados e, caso não haja nenhum problema, executa os scripts enviados. Caso identifique algum problema na execução dos scripts, a UGBD deve rejeitar o caso (estado: REJEITADO) e atribuí-lo para o representante da Fábrica de Software responsável pelo projeto/sprint. Uma vez corrigido o problema, o responsável pelo projeto/sprint atribui o caso novamente para a UGBD e altera o estado do caso para EXECUÇÃO SCRIPT. Quando as alterações necessárias no banco de dados forem executadas com sucesso, a UGBD deve atribuir o caso de volta para a Gerência de Configuração e alterar o estado do caso para BANCO EM PRODUÇÃO. A partir daí, a Gerência de Configuração deve atribuir a solicitação para a UGCPD e mudar o seu estado para LIBERAÇÃO RELEASE. Enquanto a UGCPD estiver executando os procedimentos necessários para colocar o sistema em produção, a solicitação continua no estado LIBERAÇÃO RELEASE. Ao colocar o sistema efetivamente no ar, a UGCPD muda no estado para solicitação para EM PRODUÇÃO. Feito isso, a Unidade de Gerenciamento do CPD retorna a solicitação à Gerência de Configuração. A partir daí, a Gerência de Configuração verifica se o sistema está realmente em produção e coloca as solicitações filha do pacote no estado EM PRODUÇÃO. Esse fluxo está representado na Figura 2.
Estado IMPEDIMENTO Se a solicitação estiver nos estados NOVO, GERAÇÃO RELEASE, APLICAÇÃO, EXECUÇÃO SCRIPT ou BANCO EM PRODUÇÃO e houver algum impedimento que está impossibilitando o andamento das atividades, o caso deverá ser colocado no estado IMPEDIMENTO. Quando o problema for resolvido, o caso volta para o estado que estava anteriormente. O impedimento indica algum obstáculo na resolução da solicitação. Não provoca mudança de atribuição da solicitação, e o motivo do impedimento deverá ficar descrito como anotação.
2.5 Fluxo de estados para correção de erros por Fábricas Externas Este fluxo de estados deve ser utilizado exclusivamente ao solicitar a correção de erros encontrados durante os testes de sistemas desenvolvidos ou mantidos por Fábricas Externas. Quando um erro for encontrado pela equipe de analistas de negócio do TJPE, uma nova solicitação deve ser criada no estado inicial, que é o ATRIBUÍDO, e em seguida ser atribuída ao usuário do Mantis que representa a Fábrica Externa. Em seguida, quando o erro tiver sido corrigido pela Fábrica Externa, o representante desta deve mudar o estado da solicitação para LIBERADO P/ HOMOLOGAÇÃO e atribuir de volta ao analista de negócio do TJPE. Neste momento, o analista do TJPE irá validar a correção realizada. Caso o erro tenha sido realmente corrigido, ele coloca a solicitação no estado final FECHADO e seleciona o motivo de resolução adequado (no caso, corrigido). Caso a correção não tenha sido satisfatória, o analista deve então mudar o estado da solicitação para REJEITADO e atribuir de volta ao representante da Fábrica Externa. Se a solicitação estiver com o estado REJEITADO, o representante da Fábrica deverá corrigir o erro e, ao concluir, colocá-la novamente no estado LIBERADO P/ HOMOLOGAÇÃO. Esse fluxo REJEITADO- LIBERADO P/ HOMOLOGAÇÃO continua até que a solicitação tenha sido corrigida com êxito. Além destas transições, a solicitação de correção do erro poderá em qualquer momento ser cancelada ou postergada. Nestes casos, deve-se atualizar o estado da solicitação para FECHADO e no motivo da resolução escolher a opção que melhor representa a situação (cancelamento ou adiamento da resolução). Apenas o Analista de Negócio poderá colocar a solicitação no estado FECHADO. Além disso, a solicitação poderá ser colocada a qualquer momento no estado IMPEDIMENTO, sinalizando dessa forma algum obstáculo na resolução da solicitação que independe da intervenção de outras unidades. Não provoca mudança de atribuição da solicitação, e o motivo do impedimento deverá ficar descrito como anotação.
Figura 3 Fluxo de Solicitação de Correção de Erros para Fábricas Externas Unidade de negócio (TJPE) Fábrica Externa Atribuído Atribuir para a Fábrica Externa Liberado p/ homologação Atribuir para o Analista do TJPE Fechado Rejeitado Atribuir para a Fábrica Externa Marcadores que podem acontecer em qualquer etapa do fluxo Impedimento Indica algum obstáculo na resolução da ocorrência que independe da intervenção de outras unidades. Não provoca mudança de atribuição e o motivo do impedimento deverá ficar descrito como anotação. Máquina de estados do MANTIS (Erros para Fábricas Externas ) Versão: 1.1 Criada por : UMCSTI-EQD Data: 20/05/2010 Última alteração: 17/06/2010
2.6 Categorias e estruturas de texto requeridas para abertura de solicitação 2.6.1 Na interação entre UN e Fábrica de Software Neste item trataremos das solicitações das Unidades de Negócio para a Unidade de Engenharia de Software 2.6.1.1 Categorias Uma categoria é requerida na abertura de uma solicitação no Mantis. Erro Indica que a solicitação está sendo aberta para tratar de algum erro que vem ocorrendo no sistema. Esse tipo de solicitação é adequado quando o funcionamento do sistema não corresponde à especificação do mesmo; Melhoria Indica que a solicitação está sendo aberta para tratar de alguma melhoria que será realizada no sistema. Essa melhoria pode ser tanto, adaptativa quanto evolutiva. Melhoria adaptativa é necessária quando o sistema deve se adequar a um novo ambiente, seja ele um novo computador com uma nova plataforma, ou uma nova conexão com outra base de dados, ou outra adaptação dessa natureza. Esse tipo de melhoria não altera os requisitos funcionais do sistema. O objetivo da melhoria evolutiva é alterar um requisito funcional já existente culminando com o aprimoramento do software; Novo Requisito Indica que a solicitação está sendo aberta para tratar de uma nova funcionalidade que o sistema deverá oferecer.
2.6.1.2 Estrutura de texto padrão Padrões de estrutura de texto são requeridos na abertura de uma solicitação no Mantis. Independentemente da categoria, ao abrir a solicitação, o relator deverá prover as seguintes informações no campo Descrição : Campo Descrição Classificação Objetivo Objetivo da solicitação Mandatório Descrição Perfil do Usuário Passos para Reproduzir Critérios de Aceitação Impacto Solução/dica Esse campo é onde o relator deve informar com a maior riqueza de detalhes o que está acontecendo, descrevendo o cenário atual e se possível o cenário esperado. No caso de sistemas que tenham documentação, se a solicitação for de novo requisito ou melhoria, o cenário esperado deve referenciar a documentação já atualizada do sistema. Sempre que aplicável, acrescentar a navegação de menu e o Print Screen da tela, que apontam onde encontrar o cenário, seja para erros seja para melhoria/novos requisitos. Perfil do usuário que será afetado. No caso de erros, é o perfil de usuário para o qual o problema está ocorrendo. Este campo é obrigatório para todas as solicitações, exceto para aquelas criadas pela UMCSTI-EQD e pela UTS. Neste campo devem ser informados os passos necessários para a reprodução de um erro. Este campo é opcional para todas as solicitações, exceto para aquelas que são do tipo ERRO. Critérios que o relator levará em consideração ao homologar a solução dada. Esses critérios também servirão de base para a escrita dos casos de teste. Contudo, em solicitações de mudança muito simples, em que a descrição já descreve de certa forma os critérios de aceitação, esse campo é opcional. Quais partes do sistema são afetadas com o atendimento dessa solicitação? Se houver documentação, lembrar de referenciar. Por exemplo, uma mudança no requisito X, afeta os requisitos Y e Z. Esse campo é útil quando o relator conhece o sistema e tem idéia do que deve ser feito. Por exemplo, um relatório A está dando erro. Por experiência, o relator sabe que esse problema é devido ao parâmetro X da tabela Y do banco de dados. Então, pode adicionar na solicitação essa dica de onde deve estar o problema. Mandatório Opcional Opcional Opcional Obrigatório Opcional Tabela 1 - Requisitos para preenchimento de abertura de casos de UN para Fábrica de Software.