Analise de Requisitos II

Analise de Requisitos II

(Parte 1 de 8)

Uma Estratégia para Implantação de uma Gerencia de Requisitos Visando a Melhoria Dos Processos de Software

Ana Elizabete Souza de Carvalho, Helena Cristina Tavares, Jaelson Brelaz Castro

Centro de Informática, Univesidade Federal de Pernanbuco {ana-elizabete.carvalho, helena-cristina.tavares}@serpro.gov.ar jbc@cin.ufpe.br

Resumo. A indústria de software vem demonstrando crescente interesse em engenharia de requisitos, isto é, entender o que se deseja construir antes de começar a fazê-lo. Estão percebendo que o tempo utilizado no entendimento do problema é um excelente investimento. Os requisitos de software são a base a partir da qual a qualidade é medida. Desta forma, a falta de conformidade aos requisitos significa falta de qualidade. O modelo de avaliação de maturidade do processo de desenvolvimento CMM (Capability Maturity Model) considera o gerenciamento de requisitos como sendo uma das primeiras etapas para alcançar a maturidade organizacional, e para haver o gerenciamento é preciso que o processo de desenvolvimento de requisitos esteja implantado na empresa. Desta forma, para se alcançar a gerência de requisitos é necessário que os requisitos tenham sido definidos, e é importante que a empresa também possua seus processos de desenvolvimento de requisitos definidos. Este artigo tem por objetivo definir uma estratégia para a implantação dos processos de desenvolvimento e gerenciamento de requisitos para os projetos de desenvolvimento e manutenção de software sob responsabilidade do SERPRO, estabelecendo um entendimento comum entre o cliente e a equipe de projeto quanto aos requisitos que serão atendidos no projeto de software.

Palavras chaves: requisitos, processos, gerenciamento.

1. Introdução

Ultimamente tem havido um grande interesse na comunidade de engenharia de software na melhoria do processo. As empresas precisam medir a sua capacidade de desenvolver software com qualidade. Para isto, estão utilizando o modelo CMM (Capability Maturity Model), que é um modelo gerencial que organiza as melhores práticas existentes, embora os padrões e as práticas que são aplicáveis não sejam completamente definidos.

Em geral, o desenvolvimento de software comercial responde rapidamente às mudanças tecnológicas [1]. Por isso, é importante investir no processo de melhoria contínua para o aumento da qualidade focalizando a engenharia de requisitos.

Encontram-se algumas tentativas de uso de requisitos nas organizações mas, infelizmente, as tentativas começam pela fase do gerenciamento do ciclo de vida e rastreabilidade dos requisitos, iniciada por um processo de avaliação de maturidade do nível organizacional SEI-CMM [2], sem antes ter o domínio da importante fase de descobrimento de requisitos, a partir do descobrimento dos fatos e fenômenos do ambiente ou domínio da aplicação [3]. Por isso, é importante que a empresa também possua seus processos para o desenvolvimento de requisitos definidos.

Na próxima Seção, é descrita a importância da Qualidade de Software e o contexto do SERPRO. Na Seção 3, os processos a serem executados para a implantação da Gerência de Requisitos que foram definidos pelo SERPRO são descritos. Na Seção 4, as fases utilizadas para a implantação dos processos para a gerência de requisitos definidos são descritas. Na seção 5 é feito um mapeamento entre a proposta apresentada e as práticas do CMM para a Gerência de Requisitos. Uma descrição breve do estudo de caso é apresentada na Seção 6 e, a Seção 7 é composta das conclusões e trabalhos futuros.

2. Importância da Qualidade de Software

A cada dia, as empresas tornam-se mais dependentes dos seus sistemas de informações. Construir esses sistemas, em tempo hábil para serem úteis aos negócios, com a qualidade e custos adequados à sua importância para a organização, é o desafio que todos os desenvolvedores estão enfrentando.

Pressman define qualidade de software como “conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido” [4].

Diversos modelos, ferramentas e propostas tem sido projetadas, desenvolvidas e sugeridas nos últimos anos, visando permitir as empresas a se capacitarem evolutivamente para o projeto de software, agregando à cultura empresarial mecanismos de medições e controle, bem como de evoluir toda a técnica utilizada sempre que necessário.

Entre as abordagens para a melhoria da qualidade, destaca-se aquela que atua nos processos utilizados por uma organização de software. O modelo CMM (Capability Maturity Model) foi desenvolvido para guiar a melhoria da qualidade, por meio da maturidade da capacidade dos processos de software.

A capacitação do processo permite uma maior previsibilidade de desempenho. A maturidade de um processo de software de uma organização ajuda a prever a habilidade em atingir suas metas. Quanto maior for a capacidade do processo, mais benefícios podem ser alcançados, tanto para o cliente (interno ou externo) quanto para os desenvolvedores [5].

O CMM é um modelo utilizado para medir a maturidade de uma organização nos seus processos de desenvolvimento de software. É um modelo gerencial que organiza as melhores práticas existentes. Segundo o modelo CMM, quanto maior o controle sobre o processo de desenvolvimento, mais madura é a organização. É organizado em cinco níveis de maturidade, considerados como a principal característica do modelo. Nível de maturidade é um estágio evolutivo bem definido para alcançar um processo de software maduro. Cada nível de maturidade indica um nível de capacidade do processo, visando a melhoria contínua do processo de desenvolvimento de software [6]. Com exceção do nível 1, cada nível é composto por várias Áreas-chave de Processo (ACPs). Estas áreas conduzem ao alcance das metas de melhoria de um determinado nível [7].

A primeira ACP do CMM para atingir o Nível 2 (figura 3) é a Gerência de

Requisitos, a qual estabelece as diretrizes para um comum entendimento entre o cliente e os requisitos de seu projeto de software, que serão conduzidos pela equipe do desenvolvimento. Este acordo com o cliente é a base para planejar e administrar o projeto de software. O controle das relações com o cliente depende de um efetivo controle do processo da mudança. Mas, para que a Gerência de Requisitos seja implantada na organização é necessário que um processo de Engenharia de Requisitos esteja implantado.

Como Empresa de Tecnologia da Informação, o SERPRO atua num mercado em permanente ebulição, por isso iniciou um processo para identificação e implantação das melhores práticas para elevar o estágio de maturidade do processo de desenvolvimento de software.

Impulsionando este processo está a meta de atingir o nível 2 de maturidade segundo o modelo CMM (Capability Maturity Model) do SEI até o final de 2002. E, os trabalhos iniciais verificaram que a falta de uma efetiva gerência de requisitos é um dos principais problemas a serem superados.

Dando início à estruturação interna de uma gerência de requisitos, o SERPRO participou do projeto Plataforma Tecnológica em Engenharia de Requisitos - Estratégias para o Aumento da Qualidade no Desenvolvimento de Sistemas [8], o qual teve como objetivo estabelecer bases para o aumento da qualidade dos processos de produção de software, por meio da cooperação entre universidades e empresas, com ênfase na utilização da Engenharia de Requisitos.

A plataforma foi extremamente importante para um melhor conhecimento dos problemas enfrentados pelas organizações que participaram do projeto e da possibilidade da cooperação com as instituições de pesquisa para minorar esses problemas.

Identificados os problemas, os processos a serem executados para a implantação da Gerência de Requisitos foram definidos pelo SERPRO e são descritos na próxima Seção.

3. O Processo para Implantação da Engenharia de Requisitos visando a melhoria da Qualidade de Software

A definição dos processos para a gerência de requisitos implantados no SERPRO foram baseadas nas boas práticas existentes na empresa, na cultura da organização e nas características de seus clientes. Pesquisas em bibliografia existente, o apoio de instituições de pesquisa e a utilização de benchmarking foram importantes para o desenvolvimento do projeto.

A figura 1 resume a estrutura adotada. Para alcançar as metas, algumas atividades precisam ser executadas por pessoas com papéis bem definidos. O responsável por analisar e selecionar os requisitos coleta os requisitos de software, os quais são revistos pelo Grupo de Engenharia de Software antes de sua incorporação no projeto. Uma vez incorporados, os requisitos formam uma baseline, que será a base para o Contrato Técnico entre o cliente e o desenvolvedor. Depois de validados, os requisitos são utilizados pelo Grupo de Engenharia de Software para planejar os artefatos e as atividades do desenvolvimento que irão compor o Plano de Desenvolvimento de

Software. Os desvios e as solicitações de alteração de requisitos são revistos antes de serem incorporados, seus impactos são avaliados, e os compromissos assumidos são renegociados com as partes interessadas (stakeholders).

Figura 1. Área-Chave de Processo Gerência de Requisitos

Os processos devem definir as atividades que deverão ser executadas para que as metas sejam atingidas. Nesta proposta, os processos da Gerência de Requisitos foram divididos em: Definição, Gerenciamento & Métricas, Validação e Verificação (figura 2) e definem as atividades a serem executadas por uma empresa que desenvolve sistemas a partir das solicitações de um cliente.

Ao receber uma Solicitação de Serviço, o processo de Definição elabora o documento de Visão, o Glossário, o Documento de Requisitos de Software (DRS) e as Matrizes de Rastreabilidade. Caso uma Solicitação de Alteração de Requisitos (SAR) seja recebida, o processo para Gerenciamento & Métricas de requisitos, juntamente com as Matrizes de Rastreabilidade e o Documento de Requisitos de Software (DRS), analisa os requisitos impactados, gera uma nova versão atualizada dos requisitos (baseline), atualiza o Documento de Requisitos de Software (DRS) e comunica as alterações às áreas envolvidas. Neste processo também são coletadas as métricas para controle. Durante o processo de Validação, o Documento de Requisitos de Software (DRS) e demais artefatos são avaliados para a elaboração dos Casos de Testes, além das comunicação das áreas envolvidas. O processo de Verificação recebe os artefatos dos modelos do processo de desenvolvimento e avalia se estão de acordo com os requisitos definidos.

As figuras 2 e 3 são apresentadas apenas com as entradas e saídas da técnica

IDEF0. A Tabela 1 descreve as principais entradas e saídas dos processos descritos anteriormente.

Figura 2. Grupos de Processos para a obtenção da Gerência de Requisitos

A figura 4 apresenta o detalhamento do processo para a definição de requisitos que foi exibido no macroprocesso da figura 2. É composto de Elicitação, Análise &Documentação e Negociação & Priorização (figura 4).

O processo de Elicitação dos Requisitos de Software recebe novos requisitos por meio de uma Solicitação de Serviço ou Solicitação de Alteração de Requisitos entre outras fontes, e uma vez documentados e analisados, são elaboradas as Matrizes de Rastreabilidade e o Documento de Requisitos de Software (DRS) entram num processo para negociação de prioridades, conforme detalhado a seguir. A Elicitação pode ser subdividida nas seguintes atividades, e seguem a ordem seqüencial e o paralelismo explicitado na figura 6 a qual utiliza o diagrama de atividades da UML [9]:

• Efetuar a reunião inicial com o cliente: Devem participar da reunião inicial com o cliente todos as partes interessadas (stakeholders) candidatos. Nesta reunião devem ser obtidos os principais assuntos que deverão estar presentes no Documento de Visão.

Gerenciament e

4 Validaçã

Verificaçã

Definiçã

Métrica

Notificação para áreas

Plano de SAR' Matrize

Casos de

Notificação para áreas

Atas de Artefato

Nova

Requisito ImpactadoDR

Glossári

(Parte 1 de 8)

Comentários