Novidades da versão 1.03.06

A partir de agora é possível exibir uma lista de requisitos no dashboard, e quem determina os filtros é você, assim como na consulta avançada. É possível, por exemplo, listar os requisitos que estão liberados para a codificação, teste, ou atribuído a uma determinada pessoa.

Dashboard

Outra novidade é no diagrama: agora as solicitações de mudança também aparecem. É possível visualizar o diagrama com os requisitos impactados pela mudança.

Visando facilitar a identificação da versão do produto de trabalho que está relacionada a uma baseline, mudança ou a outro produto, agora identificamos  a versão junto ao nome, conforme podemos ver na figura acima ([v1], [v2]…). Além disso foram feitas algumas melhorias de usabilidade e no layout dos relatórios.

Controlle e o mps.br – Atendendo o GRE1

O primeiro passo para atender o GRE1 – O entendimento dos requisitos é obtido junto aos fornecedores de requisitos – é identificar e registrar os requisitos do projeto. Isto pode ser feito pelo diagrama (uma maneira simplificada e rápida de incluir requisitos) ou pela tela de cadastro de produto.  É possível vincular imagens, links, arquivos externos,  identificar a fonte/fornecedor do requisito, além de definir atributos personalizados. Conforme mostramos no post “User Story ou Caso de Uso? nenhum dos dois? você decide…“  os requisitos podem ser expressos de diferentes maneiras: através de uma lista de requisitos, especificação de caso de uso, user story, ou qualquer outra forma definida pela empresa.

Registro do Requisito

Após identificados, os requisitos devem ser agrupados em uma baseline. Aqui a idéia de baseline é  identificar o escopo do projeto, iteração, ou até mesmo da versão de um produto. Este agrupamento pode ser feito na tela de cadastro de baseline ou  no próprio registro do requisito a medida que eles vão sendo identificados.

Baseline do Projeto

Após o fornecedor avaliar a lista de requisitos, o registro de aceite pode ser feito diretamente na ferramenta Controlle. Basta alterar o status da baseline para, por exemplo, “Aprovada pelo Fornecedor de Requisitos” e solicitar que ele registre o comprometimento com esta aprovação. Este registro gera um log com as informações do usuário autenticado e é uma comprovação que aquele usuário concorda com a mudança de status. A ferramenta dispõe de um relatório com o histórico destas informações. O ciclo de vida de uma baseline pode ser configurado pelo usuário, adequando-se a realidade de cada empresa ou projeto.

Registro de Comprometimento

A evolução do entendimento dos requisitos pode ser evidenciada pelo log de alterações, onde é possível visualizar as diferenças entre os registros e identificar o motivo da alteração, caso tenha sido registrado pelo usuário.

Histórico de evolução dos requisitos

Controlle e o mps.br

Um dos objetivos da ferramenta Controlle é apoiar o processo de Gerência de Requisitos do mps.br, ajudando a equipe a atingir os resultados esperados e gerando evidencias sem esforço adicional. Nos próximos dias vamos apresentar uma série de posts descrevendo como os resultados esperados podem ser alcançados utilizando o Controlle.

A motivação para este post veio do artigo que apresentamos no WAMPS 2011 (sim, estivemos lá). O evento ocorreu de 24 a 26 de outubro e durante estes dias apresentamos a ferramenta e trocamos experiências com implementadores, empresas e universidades.

Para maiores informações sobre o evento e sobre o mps.br visite o site da softex (www.softex.br).


Nos próximos posts vamos abordar os seguintes tópicos:

GRE1 - O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;

GRE2 - Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido;

GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;

GRE4 – Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos;

GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto

RAP4 - (A partir do nível F) Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados;

User Story ou Caso de Uso? nenhum dos dois? você decide…

Gosto não se discute!!! queria dar os parabéns pra quem disse isso pela primeira vez. Trazendo pro nosso contexto, não importa se você detalha os requisitos em forma de caso de uso, user story, só faz um protótipo de tela ou apenas um texto detalhado no próprio requisito. No Controlle você cria o template dos artefatos que vai utilizar no projeto e ainda define a nomenclatura que a equipe já está acostumada e as informações que cada artefato vai ter. A figura abaixo mostra a tela onde é possível fazer esta configuração.

Atributos são os campos, as informações do seu artefato. É possível criar atributos de vários tipos:  valores numéricos, texto simples ou formatado (rich text), lista de valores, data e hora, entre outros. E cada projeto pode ter uma configuração diferente, dependendo da sua necessidade. Também é possível definir modelos que podem ser importados quando se instância um novo projeto.

Assim você não fica preso a nenhuma metodologia e ainda consegue registrar qualquer artefato ou produto de trabalho definido no seu processo, de um documento relacionado ao negócio até a especificação técnica. Pode ser um documento de captura de requisitos como uma ata de reunião ou um questionário, um requisito de mais alto nível, regra de negócio, caso de teste ou até mesmo tabela do banco de dados, uma package ou código fonte. Assim da até pra fazer a rastreabilidade completa…

Rastreabilidade de requisitos e a ferramenta Controlle

Com a ferramenta Controlle manter a rastreabilidade deixou de ser um bicho de sete cabeças. A ideia é que a rastreabilidade comece a ser feita desde os primeiros passos do projeto, quando os requisitos estão sendo identificados,  e vá evoluindo a medida que novos artefatos vão surgindo (classe, tabela, package, código fonte, caso de teste…). E esta “evolução da rastreabilidade” pode ser registrada pelo desenvolvedor ou pelo testador, e não apenas pelo analista, já que toda a equipe do projeto trabalha com a ferramenta .

É possível relacionar um produto de trabalho com qualquer outro, inclusive com documentos de captura de requisitos como ata de reunião e questionários, por exemplo. Mas como assim com qualquer outro produto? É que no Controlle você configura os artefatos que seu projeto vai trabalhar, assim você não fica preso a uma determinada metodologia. No post “User Story ou Caso de Uso? nenhum dos dois? você decide…” ou em “Configurando o Projeto” você pode entender melhor como isso funciona.

A rastreabilidade pode ser mantida de duas maneiras: visualmente, através do diagrama de produtos, ou na própria tela de registro de produto de trabalho.

No diagrama tudo é feito de maneira intuitiva, visual… é possível incluir um novo produto, criar e editar relacionamentos, visualizar informações detalhadas e ”navegar” entre os requisitos do projeto. Esta navegação pode ser realizada a partir de qualquer ponto da documentação e pode seguir para cima (até os requisitos ou documentos de captura) ou para baixo (até o código fonte). Isso é rastreabilidade bi-direcional!!!

Quando se relaciona dois produtos é possível definir a direção e o tipo do relacionamento, que é uma informação configurada pelo usuário e auxilia a identificar os diferentes tipos de rastreabilidade, como por exemplo composição, “implementado por”, “testado por”, ou uma simples dependência. Estas informações ajudam a equipe a identificar em que contexto os produtos se relacionam e ainda distinguir rastreabilidade horizontal e vertical.

A figura abaixo mostra a rastreabilidade na tela de cadastro de produto. Aqui podemos relacionar requisitos de outros projetos. Um exemplo de utilização seria relacionar os requisitos de um produto com os requisitos do framework da empresa. Assim se for necessário alterar uma funcionalidade do framework você tem condições de saber todos os produtos /projetos que serão impactados.

Além da rastreabilidade com outros produtos de trabalho também é possível identificar a origem/fonte de um determinado requisito (que pode ser um stakeholder ou um documento ou legislação). Tem também a rastreabilidade com as mudanças, identificando  se um requisito foi impactado, alterado ou gerado por uma determinada mudança. Mas isso é assunto para um próximo post.

Dúvidas ou sugestões? fique à vontade para compartilhar conosco comentando esse tópico!!!