Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados

(1)

Tribunal de Justiça de Pernambuco

Diretoria de Informática

Guia de Utilização do Mantis

Máquina de Estados

(2)

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 necessidades de alteração de André Poroca e Cristiano.

Jeane Mendes

23/09/2008 00.03 Alteração no detalhamento da máquina de estados inserindo informações relevantes.

Jeane Mendes / Arthur Henriques 03/10/2008 00.04 Atualização do documento para

contemplar a interação entre GEDES e UGBD. Alterações na estrutura da seção que apresenta o detalhamento da máquina de estados.

Laísa Nascimento / Arthur Henriques

19/12/2008 00.05 Atualização das Seções 2.2 e 2.3, acrescentando detalhes acerca do registro de informações quando o software é liberado pela UES para homologação.

Laísa Nascimento

26/01/2009 00.06 Atualização do documento para atender as mudanças referentes à nova máquina de estados.

Laísa Nascimento

10/02/2009 00.07 Atualização do documento para 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.

Laísa Nascimento

11/03/2009 00.08 Atualização do documento Laísa Nascimento

(3)

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. Criação da Seção 2.4

Laísa Nascimento 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

campo Descrição

Índice de tabelas e descrição da tabela 1

Arthur Henriques

19/05/2009 00.12 Alteração do e-mail da Unidade de Qualidade de Desenvolvimento na pág. 7.

Arthur Henriques

28/05/2009 00.13 Alteração da Seção 2.3. Inclusão de texto explicativo acerca do procedimento de solicitação de serviços à GEPROD. Laísa Nascimento 01/06/2009 00.14 Versão não publicada

Substituição em todo o texto dos 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.

Arthur Henriques

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

(4)

3/08/2009 00.17 Alteração – Seção 2.4 Fluxo de estados alternativo adotado na interação com as demais gerências. Nova máquina de estados para interação UES/UGBD

Arthur

11/11/2009 0.18 Atualização da nova máquina de estados para interação UES/UGBD.

Juliana Xavier 24/11/2009 0.19 Atualização do fluxo de implantação

após a sua validação junto à UGBD e UGAPL..

Juliana Xavier

07/01/10 0.20 Atualização do fluxo de implantação após a apresentação aos Analistas de Negócio.

Exclusão das seções 2.4 e 2.6.2.

Juliana Xavier

22/01/10 0.21 Alterar a seção 2.5.1.2 para tornar o campo Critérios de Aceitação opcional.

Juliana Xavier

05/02/10 0.22 Alteração da máquina de estados de solicitação de mudança e de

implantação do sistema.

Juliana Xavier

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 Ana Luisa

26/03/10 1.1 Detalhamento de procedimentos

realizados durante o uso do fluxo de estados adotado na GEDES e alteração da estrutura de texto padrão.

Gustavo Carvalho

09/04/10 1.2 Alterando o texto para deixar claro que a estrutura padrão deve ser inserida no campo “Descrição” do Mantis.

Gustavo Carvalho

20/05/10 1.3 Inclusão da máquina de estados de erros para fábricas externas.

Gustavo Carvalho

21/06/10 1.4 Alteração na seção 2.5. Juliana Xavier

02/08/10 1.5 Alteração da seção 2.6.1.2 para Juliana Xavier

(5)

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.

Juliana Xavier

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

(6)

Í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

(7)

Í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

(8)

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 Diretoria de Informática

GEDES Gerência de Desenvolvimento do TJPE

GEPROD Gerência de Produção do TJPE

Scrum Metodologia ágil para gerenciamento de projetos

Sprint Iteração que segue o ciclo PDCA (Plan Do Check Act) e

entrega incremento de software pronto

TJPE Tribunal de Justiça de Pernambuco

UES Unidade de Engenharia de Software

UGAPL Unidade de Gerenciamento de Aplicações

UGCPD Unidade de Gerenciamento do CPD

UGBD Unidade de Gerenciamento de Banco de Dados

UN Unidade de Negócio

(9)

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

(10)

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.

(11)

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á relacionada1.

_{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

(12)

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.

(13)

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, deve-se 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

(14)

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.

(15)

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

(16)

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.

(17)

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 1o 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.

SCRIPT. A UGBD, por sua vez, analisa os scripts que devem ser executados e, caso não haja nenhum

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.

(18)

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.

(19)

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

(20)

Figura 3 – Fluxo de Solicitação de Correção de Erros para Fábricas Externas

Fábrica Externa

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

Unidade de negócio (TJPE)

Atribuir para a Fábrica Externa Atribuído Liberado p/ homologação Rejeitado Atribuir para a Fábrica Externa Atribuir para o Analista do TJPE Fechado

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.

(21)

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

(22)

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 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.

Mandatório

Perfil do Usuário 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.

Opcional

Passos para Reproduzir 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.

Opcional

Critérios de Aceitação 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.

Opcional

Impacto 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.

Obrigatório

Solução/dica 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.

Opcional