manual de implementação de processo do mps.br com apoio...

Manual de Implementação de Processo do MPS.BR com Apoio Ferramental

Processo: Desenvolvimento de Requisitos

Versão: 1.8

www.ufpa.br/spider

Histórico de Revisões

Data Versão Descrição Autor

01/10/20101.0 Início das descrições

dos capítulos 1, 3,4 e 5Ewelton Yoshidome

02/10/2010 1.1 Descrição do capítulo 5 Ewelton Yoshidome03/10/2010 1.2 Término da descrição

do capítulo 5.2Ewelton Yoshidome

04/10/2010 1.3 Revisão do capítulo 5.2 Ewelton Yoshidome04/10/2010 1.4 Correções gramaticais Ewelton Yoshidome07/10/2010 1.5 Ajustes no capítulo 5 Ewelton Yoshidome10/10/2010 1.6 Descricação do capitulo

5.1Ewelton Yoshidome

11/10/2010 1.7 Descrição do capítulo 2 Ewelton Yoshidome12/10/2010 1.8 Revisão Ewelton Yoshidome

Confidencial Página 2 de 28

Sumário


Manual de Implementação de Processo com Apoio Ferramental

1. Introdução

1.1. Finalidade

Este manual tem o propósito de descrever uma metodologia de implementação do processo de Desenvolvimento de Requisitos do Nível D do MPS.BR, utilizando apoio ferramental. Por meio de ferramentas livres, este guia descreve como atingir ou como as ferramentas fornecem insumos para alcançar os resultados esperados do processo.

1.2. Escopo

Este documento se restringe à visão ferramental da implementação do processo de Desenvolvimento de Requisitos no Nível D do MPS.BR. Não faz parte do escopo deste documento definir um processo para as organizações, mas definir práticas que podem ser inseridas ao processo de organizações que adotem este manual.

1.3. Definições

• Checklist: lista com critérios objetivos para efetuar verificação e validação dos requisitos do sistema;

• Issue: tarefa instaciada na ferramenta Redmine para as atividades de verificação, validação ou implementação dos requisitos;

• Requisitos do Cliente: conjunto de requisitos do sistema descritos em alto nível, derivados a partir das necessidades, expectativas e retrições do cliente;

• Requisitos Funcionais: requisitos que descrevem os serviços que o sistema deve provê;

• Requisitos Não-Funcionais: requistos que descrevem as propriedades que o sistema deve possuir, como performance, segurança ou restrições.

1.4. Referências

Pressman, R. S. Engenharia de software. Tradução Rosângela Delloso Penteado. São Paulo: McGraw-Hill, 2006.

SOFTEX - Associação Para Promoção Da Excelência Do Software Brasileiro. (2009a) “MPS.BR – Guia Geral:2009”. Disponível em: www.softex.br. Último acesso em 07 de agosto de 2010.

SOFTEX - Associação Para Promoção Da Excelência Do Software Brasileiro. (2009b) “MPS.BR – Guia de Implementação – parte 4:2009”. Disponível em: www.softex.br. Último acesso em 07 de agosto de 2010.

SOFTWARE ENGINEERING INSTITUTE - SEI. CMMI® for Development, Version 1.2, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, agosto, 2006. Disponível em: http://www.sei.cmu.edu, verificado em Abril/2009.

SOMMERVILLE, I. Software Engineering, Addison Wesley, 8ª edição, 2007.

2. Conceitos Básicos do Processo de Desenvolvimento de Requisitos

2.1. O que é Desenvolvimento de Requisitos?


A engenharia de requisitos tem a função de auxiliar no entendimento do sistema a ser desenvolvido, incluindo tarefas para analisar as necessidades do cliente e a forma de como o sistema irá interagir com os usuários finais [PRESSMAN, 2006]. A engenharia de requisitos pode ser dividida em duas atividades [SOFTEX, 2009]: Desenvolvimento de Requisitos e Gerência de Requisitos.

O objetivo do processo de desenvolvimento de requisitos é interpretar as necessidades do cliente para a criação dos requisitos do sistema a ser desenvolvido. As atividades que estão relacionadas a este processo são a elicitação, análise e modelagem dos requisitos.

O propósito das atividades de elicitação e análise é identificar, junto aos clientes e usuários finais, as necessidades e restrições que o sistema posssuirá [SOMMERVILLE, 2007]. A atividade de modelagem tem a função de gerar produtos de trabalho que utilizam a combinação de formas textuais e diagramáticas para prover uma fácil visualizaçao de dados, funções e comportamentos do sistema [PRESSMAN, 2006].

2.2. Benefícios do Processo de Desenvolvimento de Requisitos

A implementação de um bom processo de desenvolvimento de requisitos permite uma maior organização no momento de elicitação, registro e modelagem de requisitos. Uma vantagem de manter essa organização é proporcionar uma melhor análise sobre o documento de requisitos gerado, buscando erros, inconsistências, ambiguidades. Quando problemas são identificados durante o desenvolvimento dos requisitos, os problema de custo e retrabalho são consideravelmente reduzidos.

2.3. Objetivo do Processo de Desenvolvimento de Requisitos no contexto do MPS.BR

O processo de Desenvolvimento de Requisitos (DRE) faz parte nível de maturidade D (Largamente Definido) do MPS.Br, com o propósito de definir os requisitos do cliente, do produto e dos componentes do produto [SOFTEX, 2009a]. Este propósito é alcançado quando são identificados, registrados e refinados os requisitos funcionais e não-funcionais do sistema a partir dos requisitos do cliente.

O processo de desenvolvimento de requisitos é composto por oito resultados esperados que servem de base para a implementação do processo. Resultado esperado “é um resultado observável do sucesso do alcance do propósito do processo” [ISO/IEC, 2004].

2.4. Resultados Esperados

2.4.1. DRE1: As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces são identificadas.

O alcance deste resultado esperado envolve a utilização de métodos adequados para identificar necessidades, expectivas, restrições e interfaces do cliente [SOFTEX, 2009b]. A coleta desses requisitos podem ser feitos a partir de métodos de elicitação de requisitos como entrevistas, questionários, brainstorms, uso de protótipos, casos de uso, entre outras.

Para evidenciar a implementação do resultado esperao DRE1, as necessidades, expectativas e restrições do cliente devem ser registradas. Uma boa prática que pode ser adotada é o registro e descrição da forma de elicitação de requisitos utilizada na empresa desenvolvedora de software, para que estas informações possam ser acessadas por todos da organização.

2.4.2. DRE2: Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas

O segundo resultado esperado pede que seja gerado os requisitos do cliente a partir das necessidades, expectavias e restrições do cliente. Haverá casos que, para gerar os requisitos do cliente, será necessário a resolução de conflitos entre os fornecedores de requisitos e os demais envolvidos no projeto [SOFTEX, 2009b]. Além disso, deve ser possível o mapeamento entre os requisitos do cliente com as necessidades, expectavias ou restrições que os geraram.


2.4.3. DRE3: Um conjunto definido de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido é definido e mantido a partir dos requisitos do cliente.

A contemplação deste resultado esperado é alcançado quando são gerados requisitos funcionais e não-funcionais a partir dos requisitos do cliente definidos no DRE2. Além de ser possível efetuar o mapeamento entre esses requisitos aos requisitos do cliente.

Requisitos funcionais descrevem os serviços que o sistema deve provê, diferentemente dos requisitos do cliente o qual a descrição é feia em alto nível, os requisitos funcionais devem expressar uma liguagem técnica detalhando os métodos, excessões, as entradas e saídas de cada componente do produto [SOMMERVILLE, 2007].

Os requisitos não-funcionais são os requisitos que descrevem as propriedades ou características que o sistema deve possuir, são exemplos de requisitos não-funcionais: confiabilidade, tempo de resposta e espaço de armazenamento. Também existirão casos em que os requisitos não-funcionais estarão associados às restrições do sistema [SOMMERVILLE, 2007].

2.4.4. DRE4: Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados.

Para alcançar este resultado esperado, deve ser evidenciado a presença de diagramas derivadas a partir dos requisitos funcionais e não-funcionais. Exemplos de diagramas são: diagramas de fluxo de dados (DFD), diagrama de transição de estados (DTE), modelo de caso de uso, diagrama de classes, diagrama de atividades, diagrama de compoentes, entre outros. Deve haver, também, uma descrição detalhada de cada diagrama além de ser necessário mapeá-los aos requisitos funcionais e não-funcionais que os geraram.

Por fim, é necessário a alocação dos requisitos funcionais e não-funcionais, juntamente com os diagramas relacionados, para serem verificados, validados e implementados.

2.4.5. DRE5: Interfaces internas e externas do produto e de cada componente do produto são definidas.

Contemplar o quinto resultado esperado é necessário que as “interfaces internas e externas do produto e de cada componente do produto sejam especificados e documentas de acordo com a arquitetura definida do produto” [SOFTEX, 2009b]. A utilização das interfaces é útil para a visualização dos tipos e formatos de entrada e saída de dados dos componentes, permitindo que não ocorra erros na comunicação entre os componentes do produto no momento da implementação.

2.4.6. DRE6: Conceitos operacionais e cenários são desenvolvidos.

Para alcançar o resultado esperado DRE6 é necessário a definição dos cenários e conceitos operacionais. Um cenário é uma sequência de eventos que podem ocorrer durante o uso do sistema, com o propósito de evidenciar as necessidades dos stakeholders [SEI, 2006]. Os conceitos operacionais dependem geralmente da solução do projeto e os cenários, o seu objetivo é mostrar o comportamento entre o sistema, o ambiente e o usuário [SEI, 2006].

Uma forma de descrever um cenário é utilizando o diagrama de casos de uso. Esta modelagem ilustra uma sequência de ações que podem ser realizadas pelo usuário, juntamente com a descrição dos seus fluxos principal e alternativos, além de suas pré-condições e pós-condições.

A implementação de conceitos operacionais pode ser feita com a utilização dos diagramas de implantação, navegabilidade ou atividades, com o objetivo de permitir a visualização da interação do produto, do usuário final e do ambiente [SOFTEX, 2009b].

2.4.7. DRE7: Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as restrições existentes.

O resultado esperado DRE7 tem o objetivo de garantir que os requisitos (requisitos do cliente, funcionais e não-funcionais) sejam analisados verificando se são necessários, corretos, testáveis e suficiente para atingir seus objetivos [SOFTEX, 2009b]. Se erros foram detectados durante a verificação, os requisitos serão enviados para correção, caso contrário, será feito a validação desses requisitos com o cliente.


Para contemplar este resultado esperado, podem ser feitos [SOFTEX, 2009b]: verificação de inexistencia de ambiguidades; detecção e correção de inconsistências, omissões e erros; remoção de possíveis conflitos entre as necessidades, expectativas e restrições do cliente; refinamento das necessidades, expectivas e restrições do cliente a partir da análise de cenários e conceitos operacionais.

2.4.8. DRE8: Os requisitos são validados.

Depois que os requisitos são aprovados na fase de verificação, a validação com o cliente é efetuada utilizando métodos adequados. Os métodos adequados utilizados na validação podem ser: critérios objetivos (checklist), prototipação, simulações, utilização de cenários, entre outros.

A contemplação deste resultado esperado é alcançado quando é evidenciado a definição do método de validação adotado pela organização, juntamento com a sua aplicação.

3. Ferramental de Apoio

3.1. Ferramentas Necessárias

Para a implementação do processo de desenvolvimento de requisitos do modelo MPS.Br, foram utilizados as ferramentas Openproj (gerência de projtos), OSRMT (gerência de requisitos), Redmine (controle de mudanças), Astah Community (modelagem UML - Unified Modeling Language) e Spider-CL (checklist). A quadro 1 descreve as funcionalidades de cada ferramenta para aderência dos resultados esperados (RE).

RE Ferramentas Funcionalidades/PráticasDRE1 Openproj/ OSRMT Definição do método de elicitação de requisitos no campo de notas;

Registro e descrição das necessidades, expectativas e restrições no campo Features.DRE2 OSRMT Registro e descrição dos requisitos do cliente no campo Requirements;DRE3 OSRMT Registro e descrição dos requisitos funcionais e não-funcionais no campo

Requirements;DRE4 OSRMT/ Redmine/

Astah CommunityAnexação de diagramas aos componentes e requisitos;Descrição dos diagramas nos componentes e requisitos;Alocação de um responsável na tela de detalhamento do requisito ou componente;Instanciação e acompanhamento de uma issue para alocação de tarefa.

DRE5 OSRMT/ Astah Community

Definição dos métodos e dados de entrada e saída dos componentes no campo description;Criação de diagramas de componente contendo suas interfaces.

DRE6 OSRMT/ Astah Community

Criação do diagrama de atividades;Descrição de cada atividade no design que corresponde ao diagrama de atividades;Criação dos diagramas de casos de uso;Descrição dos fluxos principal e alternativo, junto com as pré e pós condições na aba Use Case da tela de detalhamento do requisito.

DRE7 Redmine/ Spider-CL

Instanciação e acompanhamento da tarefa (issue) de verificação dos requisitos;Criação do checklist contendo os critérios objetivos para efetuar a verificação.

DRE8 Redmine/ Spider-CL

Instanciação e acompanhamento da tarefa (issue) de validação dos requisitos;Criação do checklist contendo os critérios objetivos para efetuar a validação.

Quadro 1. Mapeamento das funcionalidades com os resultados esperados de DRE do MPS.Br

3.2. Ferramentais de Apoio

Ferramenta Fornecedor Versão Data Site de ApoioOSRMT Sourceforge 1.5 28/03/2007 http://sourceforge.net/projects/osrmt/files/ Redmine http://www.redmine.orgSpider-CL Projeto Spider 1.0 http://www.ufpa.br/spider Openproj Projeto Spider 1.4 http://www.spider.ufpa.brAstah Astah 6.2.1 http://astah.change-vision.com


Community

3.2.1. OSRMT

A ferramenta OSRMT (Open Source Requeriments Management Tool), disponível em http://sourceforge.net/projects/osrmt/, é uma ferramenta desktop para gerenciamento de requisitos. Atualmente, encontra-se na versão 1.5.

O objetivo da ferramenta é contemplar os resultados esperados de desenvolvimento de requisitos no contexto de armazenamento e registro dos requisitos gerados durante a fase de elicitação.

3.2.2. Redmine

Redmine é uma ferramenta web de bugtracking (disponível em http://www.redmine.org), desenvolvida em Ruby, com o objetivo de gerenciar mudanças nos produtos de trabalho de um projeto. Além de efetuar a gestão de mudanças, a ferramenta Redmine proporciona um suporte para o processo de gerência de projetos com o uso das funcionalidades de milestone e Gantt Chart.

Para o contexto da metodologia, a ferramenta de controle de mudanças será utilizada para o controle do ciclo de vida das tarefas de verificação, validação e implementação dos requisitos.

3.2.3. Spider-CL

Spider-CL é uma ferramenta desenvolvida no projeto SPIDER, com propósito de criar checklists compostos por critérios objetivos para utilização em diversos contextos, provendo mecanismos para a aplicação destes checklists, mantendo histórico e registrando seus resultados. Checklists são bastante utilizados para avaliações e inspeções objetivas de produtos de trabalhos diversos em organizações. Checklist é um conjunto de atributos que servem para avaliar determinado produto de trabalho, cada atributo possui uma lista de possíveis alternativas das quais apenas uma pode ser escolhida. Um checklist nada mais é do que uma relação organizada de critérios objetivos [Barros, 2009].

O Spider-CL é uma ferramenta web que pode ser executada através de servidor Tomcat, sendo acessível de qualquer navegador web, e seu banco de dados é estruturado em MySQL. Conta com serviço de controle de acesso através de cadastro de usuários e provê a sistematização do processo de definição e aplicação de checklists para avaliação, inspeção ou revisão através de critérios objetivos. A interface da Spider-CL foi desenvolvida utilizando componentes gráficos convencionais como caixas de textos, tabelas, listas e botões, para permitir fácil utilização [Barros, 2009].

A ferramenta Spider-CL é marcada pelas seguintes características: • É uma ferramenta gratuita; • É portável, sendo desenvolvida como uma aplicação para o servidor Tomcat. A ferramenta pode ser

executada em qualquer servidor capaz de executar o Tomcat 6.0 e o MySQL 5.1; • Possui uma interface de fácil utilização;

• Pode ser utilizada para o desenvolvimento de qualquer tipo de checklist objetivo;

• Possui controle de acesso e mantém registro de todas as utilizações de cada checklist;

• Exporta os checklists preenchidos e seus resultados para o formato PDF. No contexto da metodologia a ser proposta neste manual, os checklists gerados pela ferramenta Spider-CL serão

utilizados para definição de critérios objetivos, necessários para a implementação de alguns resultados esperados.

3.2.4. Openproj

O Openproj é uma ferramenta desktop, livre e open source, voltada para a gerência de projetos. Esta ferramenta é composta por um grande número de funcionalidades que dão suporte à cronograma, gestão de recursos humanos e riscos. Outra característica presente na ferramenta é a possibilidade de gerar representações gráficas como WBS (Work Breakdown Structure), RBS (Resource Breakdown Structure), CPM (Critcal Path Method) e Gantt Chart.

A versão utilizada na metodologia foi modificada pelo projeto Spider com a adição de novas funcionalidades que darão suporte à estimativas, riscos e um campo para a definição do escopo do projeto. O objetivo das alteraçãoes é permitir que a ferramenta possua uma maior aderência ao MPS.Br.

O propósito do uso da ferramenta Openproj, na metodologia, será para efetuar o registro e armazenamento do método de elicitação de requisitos.


3.2.5. Astah Community

Astah Community é uma ferramenta livre, disponível em http://astah.change-vision.com, voltada para a modelagem de diagramas UML – Unified Modeling Leanguage. Além do Astah Community, existem outras três versões: Astah UML, Astah Professional e Astah Share, que disponibilizam outras funcionalidades além da modelagem UML, porém, sua licensa é comercial.

Na metodologia, a ferramenta Astah Community será responsável no desenvolvimento dos diagrams necessários para a contemplação dos resultados esperados do processo de Desenvolvimento de Requisitos do MPS.Br.

4. Implantação das Ferramentas

4.1. Instalação4.1.1. Requisitos do Sistema

Para a instalação da ferramenta OSRMT, deve existir uma máquina virtual Java (http://www.java.com/pt_BR/download/index.jsp) instalada. Após baixar o arquivo compactado no site Source Forge (http://sourceforge.net/projects/osrmt/), basta apenas descompactar o arquivo, que será reconhecido como um executável Java, e executá-lo. A instalação é de fácil entendimento e intuitiva, é possível selecionar o local de instalação.

O procedimento de instalação do Redmine pode ser encontrado no próprio site, localizado no endereço http://www.redmine.org.

5. Implementação do Processo de Desenvolvimento de Requisitos do MPS.BR usando as Ferramentas OSRMT, Spider-CL, Openproj e Redmine

5.1. Integração do Ferramental

As ferramentas utilizadas na metodologia não possuem uma integração funcional, dificultando a rastreabilidade d as informações entre diferentes ferramentas. Por esse motivo, os documentos e tarefas gerados deverão seguir um padrão de nomenclatura para manter as consistências de seu conteúdo referenciado em diferentes ferramentas.

Primeiramente, o nome do projeto criado no OSRMT será o mesmo definido no Openproj, para evidenciar que os requisitos registrados na ferramenta OSRMT pertencem ao projeto cadastrado na ferramenta de gerência de projtos.

Outra medida que visa a integração metodológica é referente aos nomes das tarefas instanciadas no Redmine que deverão estar consistentes aos nomes dos componentes registrados na ferramenta OSRMT. As tarefas instanciadas são geradas no momento em que uma alocação para verificação, validação ou implementação é feita ao componente e sua nomenclatura deverá seguir o seguinte padrão:

• Verificação do componente “NOME DO COMPONENTE”• Validação do componente “NOME DO COMPONENTE”• Implementação do componente “NOME DO COMPONENTE”

5.2. Metodologia de Uso

A metodologia, inicialmente, fará a contemplação do resultado esperado DRE1 o qual envolve a utilização de métodos adequados para identificar necessidades, expectativas, restrições e interfaces do cliente [SOFTEX, 2009b]. A coleta desses requisitos pode ser feita a partir de métodos de elicitação de requisitos como entrevistas, questionários, brainstorms, uso de protótipos, casos de uso, entre outras.

Primeiramente, deverá ser descrito o método de elicitação de requisitos no plano de projeto, o qual será definido na ferramenta Openproj. A definição do método de coleta de requisitos é feita selecionando a opção “Arquivo/Novo Projeto” e em seguida, preencher os campos “Nome do Projeto”, “Gerente” e “Notas”.


http://astah.change-vision.com/

Figura 1. Tela de cadastro de projeto no Openproj

Após esse procedimento, será descrito o método de elicitação de requisitos na ferramenta de gerência de projetos selecionando a opção “Projeto/Informações do Projeto”, onde será exibida uma tela contendo os dados do projeto. Nesta janela, escolhendo a aba “Notas”, será feito a descrição do método utilizado para a coleta de requisitos. Pode-se observar que o textbox já se encontra preenchido com informações do produto a ser desenvolvido, para tornar este campo mais organizado, uma boa prática é separar a descrição e o método de elicitação de requisitos definindo um título cada um desses itens, como descrito na figura 2.

Figura 2. Descrição do método de elicitação de requisitos no Openproj

Depois que o método de elicitação de requisitos foi definido e aplicado, será necessário efetuar o cadastro das informações coletadas com o cliente, essas informações são denominadas de necessidades, expectativas e restrições. Inicialmente, deverá ser feito o login na ferramenta OSRMT, como mostra a figura 3. Para efetuar a primeira operação de


login, pode-se utilizar o nome de usuário “DEMO” e senha “demo” que são default na ferramenta, além de possuir acesso de administrador.

Figura 3. Tela de login do OSRMT

Após logar-se na ferramenta, será necessário criar um novo projeto em “File/New Product”, o campo “Product” deve ser preenchido com o mesmo nome do projeto cadastrado na ferramenta Openproj. Com o projeto criado, será visualizada uma estrutura de árvores, na região demarcada da tela principal, com os seguintes itens: Features, Requirements, Design, Implementation e TestCase, como demonstrado na figura 4.


Figura 4. Tela principal do OSRMT

Para contemplar totalmente o primeiro resultado esperado, deverá ser criada uma feature para as necessidades, uma para as expectativas e outra para as restrições do cliente, no campo “Features”. Features são características ou propriedades que um sistema possui. Para efetuar o cadastro de features, basta clicar com o botão direito no item “Features” e selecionar a opção “New/Feature”, como mostra a figura 5.


Figura 5. Criação de features

Ao criar as features que representarão as necessidades, expectativas e restrições do cliente, deverão ser feitas as descrições das mesmas, as descrições são registradas na tela de detalhamento da feature, para acessá-la, basta selecioná-la com o botão direito e, em seguida, escolher a opção “Edit” o qual abrirá uma janela contendo os campos que representam nome, versão, prioridade, estado, descrição e uma lista de anexos. No campo “Description”, de cada feature, será preenchido com as informações coletadas na elicitação de requisitos, finalizando a aderência do resultado esperado DRE1. A figura 6 mostra o preenchimento da descrição de “Necessidades” o qual será listada todas as necessidades do cliente, obtidas na elicitação de requisitos.


Figrua 6. Tela de descrição das necessidades do cliente

Quando as necessidades, expectativas e restrições estão devidamente registradas e detalhadas, é o momento de utilizá-las como insumo para a geração dos requisitos do cliente. Os requisitos do cliente deverão ser registrados com o uso do item “Requirements”, localizada na região demarcada da tela principal, como ilustrado na figura 4.

Em primeiro lugar, deve-se criar um requirement denominado de “Requisitos do Cliente”, onde serão listadas todos os requisitos do cliente derivados das necessidades, expectativas e restrições. Um requirement é a representação de um requisito ou componente do produto na ferramenta OSRMT.

O procedimento para a criação de um requiriment é semelhante à criação de feature, demonstrada no DRE1. Para iniciar a instanciação de um requerement, basta clicar com o botão direito em “Requirements” e em seguida selecionando a opção “New/Requirement”. Para cada requisito do cliente derivado das necessidade, expectativas e restrições, deve-se criar um requirement dentro de “Requistos do Cliente”, como demonstrado na figura 7.


Figura 7. Registro dos requisitos do cliente

Cada requisito do cliente registrado deve possuir uma descrição em sua tela de detalhamento, bastando selecionar a opção “Edit” clicando com o botão direito no requisito desejado. Na tela seguinte, é necessário que o campo “Description” seja preenchido relatando as funcionalidades e características do requisito. Uma boa prática durante o detalhamento do requisito é, além de descrevê-lo, informar sua prioridade, complexidade e versão.


Figura 8. Detalhando os requisitos do cliente

Outra necessidade é mapear os requisitos do cliente com as necessidades, expectativas ou restrições que os geraram, o propósito deste mapeamento é permitir o rastreio do impactos que as modifcações causarão aos demais produtos de trabalho que compõe o projeto. O mapeamento é evidenciado selecionando a aba “Dependencies”, na tela de detalhamento dos requisitos. Na tela de dependências, deverão ser listadas as necessidades, expectativas ou restrições registradas em “Features”, esta operação é feita ao selecionar a opção “New...”, clicando-se com o botão direito na tela de dependências. Em seguida, será exibida uma nova tela na qual o usuário poderá buscar e selecionar a necessidade, expectativa ou restrição que originou o requisito.


Figura 9. Tela de dependências

Figura 10. Tela de seleção de requisito dependente

Para alcançar o resultado esperado DRE3, os requisitos funcionais e não-funcionais serão derivados a partir dos requisitos do cliente, devidamente registrados, detalhados e mapeados pela ferramenta OSRMT.

O registro dos requisitos funcionais e não-funcionais será feito dentro de um requirement, denominado “Requisitos Funcionais e Não-Funcionais” o qual estará localizado em “Requirements”. Uma boa prática sugerida pelo guia de implementação é a utilização de um critério para o agrupamento dos requisitos funcionais e não-funcionais listados.

Na metodologia, o critério de agrupamento dos requistos será feito com o uso do conceito de componente. Componente é um bloco construtivo modular para software de computador [PRESSMAN, 2006]. Para a representação de um componente, será criado um requirement com o nome no formato “COMP: NOME_DO_COMPONENTE” o qual será registrado dentro do item “Requisitos Funcionais e Não-Funcionais”. Cada componente possuirá um conjunto de requisitos funcionais e não-funcionais. Com o objetivo de preservar a legibilidade, será adotado o uso das tags “RF:” e


“RNF:”, antes do nome de cada requisito, os quais significam requisitos funcionais e requisitos não-funcionais, respectivamente. A figura 11 ilustra como ficaria a estrutura de organização com o uso do conceito de componentes no OSRMT.

Figura 11. Estruturando e organizando requisitos funcionais e não-funcionais

Após o cadastramento de um requisito funcional e não-funcional, é imprescindível o seu detalhamento, por isso, deve-se descrevê-lo, informar sua versão, o nível de sua complexidade e urgência. Além de caracterizar o requisito, é necessário fazer o mapeamento ao componente em que pertence, na aba de dependências. O propósito deste mapeado é evidenciar que conjunto de requisitos faz parte de um determinado componente quando uma rastreabilidade for efetuada.

Quando todos os requisitos funcionais e não-funcionais forem detalhados e mapeados ao seu componente, este componente deverá, também, ser detalhado. Primeiramente, no campo “Description” deve ser preenchida com informações de sua interface (métodos utilizados e dados de entrada e saída), além de descrever sobre suas funcionalidades. Com o objetivo de organizar as informações presentes no campo de descrição, serão criados tópicos para separar a descrição, os métodos e os dados de entrada e saída do componente. A utilização de tópicos não precisa se restringir apenas na separação desses conteúdos, para cada novo conteúdo, um novo tópico pode ser criado. O detalhamento do componente, juntamente com a estrutura de tópicos sugerida, é ilustrada na figura 12. Com o detalhamento concluído, o componente deve ser mapeado com requisito do cliente que o gerou, na sua tela de dependências.


Figura 12. Tela de detalhamento do componente

Depois do registro e detalhamento do componente, será necessário refiná-lo, ou seja, deverão ser utilizadas técnicas de modelagem para o desenvolvimento de diagramas com o objetivo de proporcionar uma análise do projeto com diferentes perspectivas.

A ferramenta responsável pela modelagem utilizada na metodologia será o Astah Community o qual permite a elaboração de diagramas de atividades, classes, sequência, comunicação, casos de uso, componente e implantação. Para acessar essas funcionalidades, deve-se selecionar a opção “Diagram” e em seguida o diagrama que deseja-se desenvolver.


Figura 13. Tela principal do Astah Community

No momento em que os diagramas são elaborados, é necessário disponibilizar e mapeá-los aos requisitos que os geraram, para isso, duas abordagens serão adotadas na metodologia: (1) os diagramas produzidos serão anexados aos componentes ou requisitos que os geraram; (2) no campo “Design”, localizada na região demarcada na figura 4, será criado designs. Na ferramenta OSRMT, design é o componente que representa e descreve os dados arquiteturais do sistema. Para cada design, será anexado apenas um tipo de diagrama e seu nome estará associado a este tipo, ou seja, se o diagrama anexado ao design for um diagrama de classes, seu nome será “Diagrama de Classes”.

A abordagem (1) será utilizada nos casos em que os diagramas gerados representam uma parte específica do projeto, como um componente ou requisito. Em casos em que o diagrama possui um escopo mais abrangente, como a representação da comunicação entre componentes, será feito uso da abordagem (2).

Para execução da primeira abordagem, deve-se abrir a tela de detalhamento do requisito ou componente desejado e clicar com o botão direito no campo “Attachments” e selecionar a opção “Attach file”, em seguida, uma nova tela será exibida onde poderá ser feita a seleção do arquivo a ser anexado. Para cada novo diagrama anexado, deve ser feito o seu detalhamento no campo de descrição do requisito ou componente, criando-se um novo tópico representando a descrição do diagrama.


Figura 14. Anexando arquivo em um requirement

Figura 15. Tela de seleção de arquivo a ser anexado

O cumprimento da abordagem (2) se inicia com a criação de designs clicando-se com o botão direito em “Design” e selecionando a opção “New/Design”. A anexação de arquivo em um design é idêntica à anexação de arquivo definida em requirements. Da mesma forma que na abordagem (1), os diagramas anexados devem ser bem descritos no campo “Description”, localizado na tela de detalhamento do design. Como os diagramas não estão anexados diretamente ao seus componentes ou requisitos, o mapeamento aos requisitos funcionais e não-funcionais que os geraram é necessário.


Cada diagrama desenvolvido permite uma análise em uma determinada perspectiva, porém, para o MPS.Br, devem ser gerados diagramas que modelem cenários, conceitos operacionais e interfaces internas e externas, obviamente não se restringindo apenas a essas visões.

Na metodologia, serão modelados casos de uso para evidenciar que os cenários foram desenvolvidos. Cada caso de uso produzido será anexado ao componente ou requisito que o gerou. Depois de efetuado a anexação, deverão ser descritas suas pré e pós condições, juntamente com seus fluxos principal e alternativo. Para implementar este procedimento na ferramenta, deve-se anexar o diagrama de casos de uso no componente ou requisito, e em seguida selecionar a aba “Use Case” na tela de detalhamento do requisito, nesta tela serão exibidas os seguintes campos:

• Pré-condição: Este campo deve ser preenchido com as condições necessárias para que o caso de uso tenha início.

• Pós-condição: Este campo descreve o estado em que o sistema se encontrará após o término do caso de uso.

• Fluxo Principal: Este espaço deve ser preenchido com a sequência de passos que serão executados caso não ocorra nenhum desvio.

• Fluxo Alternativo: Neste campo, será relatada uma sequência de passos que não faz parte do fluxo normal do sistema.O cadastramento de cada passo dos fluxos principal e alternativo é realizado selecionando a opção “Add row”.

Além dessa opção, a ferramenta disponibiliza funcionalidades para o manuseio dos itens cadastros, permitindo ordená-los utilizando os botões “Move Up” e “Move Down”.

Figura 16. Tela de cadastramento de cenários

Os conceitos operacionais podem ser implementados com o uso de diagramas de implantação, navegabilidade ou atividades. Esta metodologia fará uso do diagrama de atividades, cada organização está livre para escolher a melhor forma de representar os conceitos operacionais do projeto, não estando restritos a apenas um tipo de diagrama.

Primeiramente, deve-se criar um design com o nome de “Diagrama de Atividades”, dentro deste item serão anexados os diagramas de atividades. Outra necessidade é o detalhamento de cada atividade que compõe o diagrama, o qual deve ser relatado no campo “Description”. Por fim, será necessário efetuar o mapeamento entre o diagrama de atividades aos requisitos os quais o geraram, na aba “Dependencies”. Após a definição dos cenários e conceitos operacionais, o resultado esperado DRE6 estará totalmente satisfeito.


Figura 17. Registro do design “Diagrama de Atividades”

Com o propósito de alcançar o resultado esperado DRE5, será necessário elaborar as interfaces internas e externas do sistema. Para contemplar este resultado esperado, na metodologia, será modelado os diagramas de componente contendo suas interfaces de comunicação. Este diagrama deve ser anexado a um design denominado “Diagrama de Componentes”, além de detalhá-lo a partir do campo “Description”. Também é importante que o diagrama de componentes esteja mapeado ao componente ou requisitos funcionais e não-funcionais que serviram de insumo para seu desenvolvimento.

A evidência da implementação do DRE5 será feita quando for presenciado o diagrama de componentes, juntamente com suas interfaces e descrição, como ilustrado na figura 18. Outra evidência, presente na metodologia, é a presença da lista de métodos e dados de entrada e saída no campo de descrição dos componentes. Na figura 12 podemos identificar as interfaces do componente, no campo “Description”, separadas pela estrutura de tópicos.

Quando todos os diagramas necessários são modelados, descritos e mapeados, deve-se alocar alguém para efetuar a verificação, validação e implementação dos componentes, junto aos seus diagramas. A alocação é feita atribuindo o nome do responsável no campo “Assigned”, na tela de detalhamento do componente.

Figura 18. Diagrama de componente contendo as interfaces do sistema


Figura 19. Alocação de responsável na ferramenta OSRMT

Além de designar um responsável na ferramenta OSRMT, uma issue deve ser instanciada na ferramenta Redmine com o objetivo de informar a alocação da tarefa à pessoa responsável, além de possibilitar o acompanhamento da evolução da issue alocada. Uma issue é a representação de uma solicitação de mudança, tarefa, defeito ou problema que terá sua evolução acompanhada desde sua criação até seu desfecho. A criação de uma issue é feita selecionando a opção “New Issue”, essa operação direcionará para uma tela contendo os seguintes campos:

• Tracker: O tipo de issue, nesta metodologia, será utilizado o tipo tarefa;

• Subject: O assunto em que se trata a tarefa. Como um componente pode ser enviado para verificação, validação ou implementação, é recomendável que o nome da tarefa explicite o tipo de ação que será executado sobre o componente alocado. Para isso, pode ser adotado um padrão de nomenclatura na definição do assunto, na metodologia será utilizado as tags:

o Verificação do componente “Nome_do_componente”: Para tarefa de verificação;o Validação do componente “Nome_do_componente”: Para tarefas de validação;o Implementação do componente “Nome_do_componente”: Para tarefas de implementação.

• Description: Descrição da tarefa instanciada;

• Status: O estado em que se encontra a tarefa;

• Priority: Representa a urgência em que a tarefa deve ser resolvida;

• Assigned to: A pessoa responsável em resolver a tarefa;

• Start: Data de instanciação da tarefa;

• Due Date: Data limite para o término da tarefa;

• Estimated Time: Tempo estimado para resolução da tarefa;

• % Done: Percentual de conclusão da tarefa;

• Files: Arquivos anexados à tarefa.


Figura 20. Instanciação de tarefa no Redmine

A criação da tarefa estará concluída no momento em que o botão “Create” for selecionado. Ao instanciar uma issue, será enviado um e-mail ao responsável, notificando-o da tarefa.

Um componente, antes de ser implementado, deve passar pelo processo de verificação e, em seguida, validação. Com o objetivo de auxiliar no processo de verificação e validação, será utilizado o conceito de checklist. Checklist é um conjunto de atributos que servem para avaliar determinado produto de trabalho, cada atributo possui uma lista de possíveis alternativas das quais apenas uma pode ser escolhida.

O primeiro processo que deve ser executado é a verificação, com o objetivo de detectar erros, inconsistências, ambiguidades, omissões no documento de requisitos. Na metodologia, será criada uma tarefa solicitando que um componente seja verificado, juntamente com a disponibilização do checkilist a ser aplicado. Caso seja detectado algum defeito, o estado da tarefa será modificado para “Feedback” e haverá a alocação de um responsável para efetuar as devidas correções, além de efetuar a anexação do checklist aplicado, em formato pdf, à tarefa. Por fim, o componente verificado, retornará para a fase de análise de requisitos.

Caso não tenha sido detectado nenhum defeito no componente, o estado da tarefa será modificado para “Resolved” e o campo “% Done” deverá ser preenchido com “100%”, além de efetuar a anexação do checklist aplicado em formato pdf.

Para a gereração dos checklists, será feito uso da ferramenta Spider-CL. Antes de efetuar a aplicação dos checklists, deve-se primeiro efetuar o cadastro dos critérios objetivos na funcionalidade “Cadastrar Critérios” na tela principal da ferramenta.


Figura 21. Tela principal do Spider-CL

Ao selecionar a funcionalidade “Cadastrar Critérios”, uma nova tela será exibida o qual possuirá três campos de texto. O primeiro campo deve ser preenchido com o critério desejado, e nos demais campos serão registrados com as possíveis alternativas. Para concluir o cadastro do critério, basta clicar em “Salvar”. Poderão existir casos em que um critério aceite mais de duas alternativas, nestas situações um novo campo para alternativa pode ser gerado, selecionando o botão “Adicionar Alternativa”.

Figura 22. Tela de cadastro de critérios

Depois de cadastrar todos os critérios, um checklist deverá ser criado com a utilização da funcionalidade “Novo Checklist”, na tela principal da ferramenta. Ao selecionar esta opção, será apresentado a tela de criação do checklist o qual


conterá um campo de texto onde será feito a sua descrição, em seguida um campo onde serão listadas os critérios definidos anteriormente.

Figura 23. Tela de criação do checklist

Ao finalizar o cadastro do checklist, este pode ser reutilizado para realizar a verificação e validação de vários projetos. Para aplicar o checklist, basta selecionar a funcionalidade “Aplicar Checklist”. Depois de aplicado, deve ser gerado um arquivo em formato pdf deste checklist, essa operação é feita selecionando a opção “Visualizar Checklist”. Na tela de visualização, o checklist desejado deverá ser selecionado e, em seguida, a opção “Baixar PDF” escolhida.

No momento em que um componente é aprovado na fase de verificação, será instanciado uma tarefa para efetuar a sua validação. O processo de validação tem o objetivo confirmar se o produto ou componente do produto atenderá o seu uso pretendido quando colocado no ambiente para qual foi desenvolvido [SOFTEX, 2009b]. Diferente da verificação, a validação será executada pelo cliente externo, por esse motivo, deve ser disponibilizada uma conta na ferramenta Spider-CL com o perfil de cliente externo.

Quando o componente receber a aprovação do cliente, a tarefa deve ser modificado para o estado “Resolved” e o campo “% Done” preenchido para “100%”, além de anexar o checklist aplicado. Em fim, uma tarefa solicitando a implementação do componente deve ser instanciada, juntamente com a alocação de um responsável para resolvê-la.

Caso o componente não seja validado, a tarefa será modificado para o estado “Feedback” e será anexado o checklist aplicado. O componente reprovado na validação, será enviado para a fase de análise visando corrigir os problemas detectados, como consequência, o componente passará pela fase de verificação novamente, com o objetivo de detectar o surgimento de novos defeitos provenientes das modificações realizadas. A figura 24 ilustra o percurso dos requisitos desde da fase de análise até sua implementação.


Figura 24. Workflow dos requisitos

No momento em que as tarefas de refinamento, detalhamento e alocação dos requisitos funcionais e não-funcionais são feitas, o resultado esperado DRE4 é alcançado. Para os resultados esperado DRE7 e DRE8, são contemplados quando os procedimentos para gerenciar os ciclos de vida das tarefas de verificação e validação são executados.

5.3. Análise do Atendimento ao Processo de Desenvolvimento de Requisitos do MPS.BR

As ferramentas utilizadas na metodologia permitem a sistematização do processo de desenvolvimento de requisitos, proporcionando a possibilidade do aumento na produtividade e redução de burocracia. Porém, um efeito contrário pode ocorrer, se as ferramentas forem utlizadas de forma indevida.

O conjunto de ferramentas livres proposto é capaz de implementar totalmente os resultados esperados do processo de Desenvolvimento de Requisitos do MPS.Br, desde que sejam seguidos os procedimentos citados na metodologia. Esta metodologia pode ser adaptada para se adequar ao conjunto de ferramentas utilizadas na organização.


manual de implementação de processo do mps.br com apoio...

Documents