Baixe Importância da Qualidade de Software e outras Notas de estudo em PDF para Redes de Computadores, somente na Docsity!
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, [email protected]
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].
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
- 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 M atrizes 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.
Rever as Mudanças e incorporar as apropriadas (At3)^ alterações
Usar os Requisitos para planejar os Atvidades^ Artefatos e(At2)
Baseline Contrato Técnico (Hb2)de Requisitos:
Avaliar impactos e renegociar compromissos
Rever os Requisitos antes de serem incorporados ao projeto (At1)
Sistemas (alocar^ Requisitos de- Hb2)
PDS Desenvolvimento- Plano de de Software
Partes Interessadas
Grupo de Eng. de Software
Grupo de Eng. de Software
Meta 2 são mantidas consistentes com os- Planos, produtos, atividades Requisitos
Meta 1 e a baseline- Requisitos são controladosé estabelecida para a Gestão da EngenhariaS f
RenegociarNotificar /
Desvios e SAR's ( de Alteração de Requisitos)Solictações
Novas Baselines
Responsável por analisar e alocar os requisitos (Hb1)
SAR de Alteração de- Solicitação Requisitos
Requisitos Validados
Requisito de Software
analisar e alocar os^ responsável por requisitos (Hb1)
Atividade (At)
Habilidade (Hb)
Subatividade Plano
Rever as Mudanças e incorporar as apropriadas (At3)^ alterações
Usar os Requisitos para planejar os Atvidades^ Artefatos e(At2)
Baseline Contrato Técnico (Hb2)de Requisitos:
Avaliar impactos e renegociar compromissos
Rever os Requisitos antes de serem incorporados ao projeto (At1)
Sistemas (alocar^ Requisitos de- Hb2)
PDS Desenvolvimento- Plano de de Software
Partes Interessadas
Grupo de Eng. de Software
Grupo de Eng. de Software
Meta 2 são mantidas consistentes com os- Planos, produtos, atividades Requisitos
Meta 1 e a baseline- Requisitos são controladosé estabelecida para a Gestão da EngenhariaS f
RenegociarNotificar /
Desvios e SAR's ( de Alteração de Requisitos)Solictações
Novas Baselines
Responsável por analisar e alocar os requisitos (Hb1)
SAR de Alteração de- Solicitação Requisitos
Requisitos Validados
Requisito de Software
analisar e alocar os^ responsável por requisitos (Hb1)
Atividade (At)
Habilidade (Hb)
Subatividade Plano
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.
A
2
Gerenciament e
4
Validaçã
A
3
Verificaçã
A
1
Definiçã
Métrica
Notificação para áreas
SAR'
SAR'
Plano de
SAR' (^) Matrize
Casos de
Notificação para áreas
DRS
Atas de Artefato
Nova
Requisito DR Impactado
Glossári
deSolicitaça Visã
Notificação para áreas
- Entender o domínio da aplicação : A reunião inicial com o cliente fornecerá a base para determinar quais os principais domínios serão necessários estudar mais profundamente para o desenvolvimento do sistema. Uma das principais dificuldades enfrentadas pelo desenvolvedor de software é a complexidade do domínio do problema [10]. Além disso, os usuários e desenvolvedores possuem perspectivas diferentes e fazem suposições diferentes sobre a natureza da solução [11]. Quando o desenvolvedor e o usuário compartilham a mesma linguagem, melhora a comunicação entre ambos. Em particular, se esta linguagem é própria do usuário esta comunicação melhora consideravelmente [12].
- Identificar as partes interessadas (stakeholders): Identifique as pessoas interessadas pelo produto, ou participarão do seu desenvolvimento. Para cada stakeholder é importante identificar além da função, o nome do stakeholder.
Figura 3. Processos para a Definição de Requisitos
- Escolher a técnica de elicitação: Ao escolher a técnica de elicitação deve-se considerar quais as fontes dos requisitos, a disponibilidade das pessoas e os tipos de requisitos a serem elicitados. A escolha da técnica apropriada para elicitar requisitos depende do tempo e recursos disponíveis, assim como do tipo de informação necessária. Algumas das classes de técnicas de elicitação são [13]: o Técnicas tradicionais – inclui o uso de questionários, entrevistas, análise de documentação existente [14]; − Questionários: questões predefinidas são distribuídas para uma amostragem significante e representativa de stakeholders e os resultados são avaliados. São úteis quando a quantidade de stakeholders é extremamente grande. Uma vez que todas as questões podem ser predeterminadas, é mais eficiente na avaliação de tendências de opiniões a respeito de requisitos específicos e bem definidos. − Entrevistas: Perguntar questões relacionadas aos stakeholders e/ou suas necessidades a respeito do problema a ser resolvido e
A
1
Elicitação Requisitosdos de Software
A 1 3
3
Negociação &Priorização
A
2
Glossário
SAR's
Matrize (Acompanhamentos e rastreabilidade )
Plano de Revisão
DRS
Visão
DRS
Solicitação de Sistemas (^) & Análise
Documentação
escutar suas respostas [15]. São úteis quando stakeholders possuem muitos conhecimentos subjetivos e estão dispostos a serem entrevistados. Para ser mais eficiente, o entrevistador deve ser experiente. o Técnicas de elicitação de grupo – são técnicas de dinâmica de grupo com o objetivo de entender de forma mais detalhada as necessidades dos usuários, estão incluídas: brainstorming, sessões JAD e RAD [16]; − Brainstorming: stakeholders são reunidos em um local, num ambiente que encoraje a participação, permitindo que todas as idéias sejam declaradas em voz alta (para que os demais sejam influenciados) e escritas (para que não sejam perdidas) [17]. É mais eficaz quando cada stakeholder possui uma parte do conhecimento de algum aspecto do problema. o Prototipação – implementação parcial de um sistema de forma rápida para obter feedback para o processo de requisitos. O protótipo é descartado. É utilizada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários; o Técnicas de modelagem – fornece um modelo específico das informações que serão adquiridas, e usa esse modelo para orientar o processo de elicitação. Uma técnica bastante utilizada é o uso de cenários para representar as tarefas que os usuários executam normalmente e aquelas que eles desejam executar [18]. Inclui métodos baseados em metas, tais como: KAOS [19] e I* [20] e métodos baseados em cenários como CREWS [21]. o Técnicas cognitivas – inclui uma série de técnicas originalmente desenvolvidas para aquisição de conhecimento para sistemas baseados em conhecimento, alguns exemplos são: Análise de protocolo, laddering, card sorting, repertory grids [22]; o Técnicas contextuais – surgiu como uma alternativa para as técnicas tradicionais e cognitivas, inclui técnicas de etnografia e análise social [23]; o Etnografia: observar potenciais usuários em seu ambiente natural. Resulta em uma percepção mais precisa do problema do que perguntar aos usuários o que eles fazem [24]. São úteis para suporte à automação de uma função pouco ou não automatizada, particularmente quando são disponíveis a observadores treinados sem noções preconcebidas do problema e de sua solução.
Condições específicas do projeto devem definir a técnica mais eficaz a ser utilizada [25], ou a combinação delas. No SERPRO, as técnicas mais utilizadas são a entrevista, o uso de cenários com Use Cases e a prototipação, com o acompanhamento do cliente não só na fase de requisitos, mas durante todo o processo de desenvolvimento do software. Um benefício é o comprometimento do cliente e a participação direta na definição dos
- Descrever os requisitos e os seus atributos: depois que os requisitos do sistema são elicitados, eles devem ser documentados com um nível apropriado de detalhes. Na maior parte das organizações os requisitos são escritos em linguagem natural, pois é uma notação que é de fácil entendimento para uma grande variedade de stakeholders. Entretanto, o nível de abstração dos requisitos varia de acordo com a organização e deve ser definido de acordo com o projeto ou até mesmo com o tipo de requisito. O principal foco da pesquisa em documentação de requisitos é prover notações e linguagens de especificação. Desde linguagem natural [26] à lógica [27], diferentes linguagens têm sido propostas para expressar e descrever requisitos. Pesquisas atuais têm reconhecido que o gerenciamento de requisitos é uma atividade crucial no processo de engenharia de requisitos, ou seja, é necessário não somente escrever os requisitos de forma entendível mas também permitir que eles possam ser rastreados e gerenciados ao longo da evolução do sistema [28].
Figura 5. Processo Documentação & Análise
- Definir a Fronteira do Software: freqüentemente os stakeholders não têm certeza do que deve ou não estar no software a ser desenvolvido, o que faz com que requisitos desnecessários sejam incluídos durante a fase de Elicitação de requisitos. Por isso, deve-se avaliar o conjunto de requisitos essenciais para a definição do Documento de Visão do software. O Documento de Visão deve incluir o escopo do projeto e suas limitações, bem como as principais características do software a ser desenvolvido [29]. É importante que seja documentado os argumentos técnicos e/ou econômicos que justificam a exclusão dos requisitos do escopo do software.
Descrever os Requisitos e seus atributos C
C
C
C
FIm
Início
Definir a Fronteirado Software
Utilizar Check List para analisar Requisitos
Analisar os Riscos dos requisitos
Classificar os Requisitos
Definir as Matrizes de Iteração e Rastreabilidade
Elaborar o Documento de Requisito de Software (DRS)
Descrever os Requisitos e seus atributos C
C
C
C
FIm
Início
Definir a Fronteirado Software
Utilizar Check List para analisar Requisitos
Analisar os Riscos dos requisitos
Classificar os Requisitos
Definir as Matrizes de Iteração e Rastreabilidade
Elaborar o Documento de Requisito de Software (DRS)
Descrever os Requisitos e seus atributos C
C
C
C
FIm
Início
Definir a Fronteirado Software
Utilizar Check List para analisar Requisitos
Analisar os Riscos dos requisitos
Classificar os Requisitos
Definir as Matrizes de Iteração e Rastreabilidade
Elaborar o Documento de Requisito de Software (DRS)
- Utilizar um Checklist para analisar os requisitos: para facilitar, otimizar e tornar mais completa a análise de requisitos, deve-se definir um checklist , por meio do qual cada requisito deve ser analisado. Além de reduzir a probabilidade de erros, a utilização de um checklist é uma forma de reutilizar o conhecimento em análise de requisitos entre diferentes projetos. Caso fique muito grande deve-se particioná-lo, de forma a criar vários checklists que possam ser distribuídos para diferentes analistas. O checklist deve ser periodicamente revisado e validado por analistas experientes para verificar a necessidade de alterações. É importante conscientizar os analistas de que o checklist deve ser apenas um guia e que podem existir outros problemas não cobertos pelo checklist.
- Analisar os Riscos dos requisitos: é uma forma de identificar os requisitos que poderão causar mais problemas aos desenvolvedores. Deve-se identificar os problemas que poderão surgir, a probabilidade destes problemas e os efeitos decorrentes desses problemas para cada requisito ou para grupos de requisitos. Explicitar os riscos associados aos requisitos nesta fase é uma forma de avaliar se os requisitos estão incompletos, se precisam ser modificados ou se é necessária a definição de procedimentos para redução da probabilidade do problema ocorrer e do impacto, caso ocorra.
- Classificar os requisitos: o objetivo da classificação dos requisitos é agrupá- los de forma a identificar requisitos semelhantes. É importante que o número de classes definido não seja muito grande, pois ficam muito poucos requisitos por classe. Geralmente, fica em cinco ou seis tipos de requisitos. Uma vez classificados, os requisitos de uma mesma classe devem ser comparados e analisados, pois conflitos e sobreposições são mais freqüentes em requisitos de um mesmo tipo. Requisitos similares também podem ser comparados e pode-se visualizar melhor a falta de algum requisito. A classificação dos requisitos deve ser definida no Guia de Classificação de Requisitos.
- Definir as Matrizes de Iteração e Rastreabilidade: numa matriz de interação, cada requisito deve ser comparado com os demais de forma a identificar se são conflitantes, sobrepostos ou independentes. Se a quantidade de requisitos for muito grande, deve-se definir a matriz para uma classe específica de requisito ou para os requisitos de um subsistema.
- Elaborar o Documento de Requisito de Software (DRS): o documento de requisitos é o meio através do qual é possível descrever as restrições quanto às características do produto e quanto ao processo de desenvolvimento, a interface com outras aplicações, a descrição sobre o domínio e as informações de suporte ao conhecimento do problema [30]. Em geral, é necessário que o documento de requisitos seja entendível por todos os envolvidos no processo de engenharia de requisitos pois ele servirá como um contrato entre usuários e desenvolvedores.
Durante a Negociação & Priorização (figura 8) as seguintes atividades são feitas:
- Escolher a técnica de negociação: o processo de negociação de requisitos tenta resolver conflitos entre usuários sem necessariamente comprometer a
por formulário padronizado ou por meio de sistema de solicitação de demandas.
- Registrar novos requisitos: Os novos requisitos também devem ser recebidos formalmente ou por formulário padronizado ou por meio de sistema de solicitação de demandas.
- Verificar requisitos relacionados: uma vez preenchidas as matrizes de rastreabilidade, de forma que tenham sido estabelecidos relacionamentos de rastreamento entre os requisitos, é necessário verificar os requisitos relacionados para que seja avaliado o impacto desta inclusão ou alteração posteriormente.
Figura 7. Processo de Gerenciamento & Métricas
- Elaborar relatórios de Impacto nos Requisitos: uma vez decidida a alteração, é mantido um histórico de alterações para cada requisito, permitindo uma visão cronológica das principais mudanças nos requisitos, inclusive em seus atributos. O autor, a data-hora, a descrição e a justificativa da alteração também são documentados.
- Notificar os envolvidos: todos os envolvidos devido à alteração dos requisitos devem ser notificados.
- Coletar Métricas: as métricas desempenham um papel essencial na detecção dos desvios, fornecendo meios para a visualização de discrepâncias e identificação de pontos fora de uma situação projetada. As métricas devem ser utilizadas e coletadas periodicamente para o devido acompanhamento das atividades da Gerência de Requisitos, fornecendo também uma indicação da
Verificar Requisitos Relacionados
Avaliar Impacto
Coletar Métricas
Notificar os envolvidos
Receber as SAR's
C
C
C
C
Fim
Início
Registrar novos Requisitos
Elaborar Relatório de Impacto nos Requisitos
Verificar Requisitos Relacionados
Avaliar Impacto
Coletar Métricas
Notificar os envolvidos
Receber as SAR's
C
C
C
C
Fim
Início
Registrar novos Requisitos
Elaborar Relatório de Impacto nos Requisitos
volatilidade dos requisitos. A equipe de gerência de requisitos deve definir quais métricas serão utilizadas no projeto, de acordo com suas características peculiares.
Durante processo de Validação (figura 10) as seguintes atividades são executadas:
- Usar Checklist de Validação: checklists estruturam o processo de validação de forma que aspectos importantes não sejam esquecidos. Embora sejam semelhantes aos checklists de análise, os checklists de validação devem focalizar aspectos de qualidade do documento de requisito como um todo, bem como os relacionamentos entre os requisitos. Algumas questões podem ser relacionadas para checar se algum requisito está ausente; se os requisitos estão consistentes e não contraditórios; se o documento está estruturado de forma a facilitar o entendimento; se foi feito o rastreamento dos requisitos; ou se o documento está de acordo com os padrões.
- Definir os casos de teste dos requisitos: definir um ou mais casos de testes que posteriormente permitam verificar se o sistema satisfaz o requisito, além de uma forma de validar os requisitos, pode servir como base para os testes finais do sistema. Ao escrever o caso de teste, o requisito estará sendo escrito de um ângulo diferente. Cada caso de teste deve possuir, no mínimo, um identificador, os requisitos a ele relacionados e a descrição do teste. Se utilizados em uma ferramenta, os casos de testes podem estar diretamente associados aos requisitos, além de permitir que os testes possam ser feitos automaticamente.
Figura 8. Processo de Validação
- Executar as Inspeções Formais: nas inspeções formais um grupo deve validar os requisitos de forma sistemática, descobrir os problemas relacionados a eles e entrar em um acordo a respeito de como solucioná-los.
C
Notificar Gerência Sênior
C
D
Final
Início
Desvios resolvíveis internamente
Desvios não resolvíveis internamente
Executar a Inspeção Formal para Validação
Notificar Gerente de Projeto e envolvidos
Usar os checklist de validação
Definir os casos de teste dos requisitos
C
Notificar Gerência Sênior
C
D
Final
Início
Desvios resolvíveis internamente
Desvios não resolvíveis internamente
Executar a Inspeção Formal para Validação
Notificar Gerente de Projeto e envolvidos
Usar os checklist de validação
Definir os casos de teste dos requisitos
Notificar Gerência Sênior
C
D
Final
Início
Desvios resolvíveis internamente
Desvios não resolvíveis internamente
Executar a Inspeção Formal para Validação
Notificar Gerente de Projeto e envolvidos
Usar os checklist de validação
Definir os casos de teste dos requisitos
4. As Fases para Implantação
Inicialmente, foram definidos os processos (vide Seção 3) e os padrões documentados que deverão ser utilizados, conforme a política de Gerência de Requisitos aprovada para o SERPRO. Também foi definido um plano de treinamento para ser utilizado pelas equipes. Em cada regional foi escolhido um projeto para ser desenvolvido utilizando os procedimentos para a Gerência de Requisitos definidos. A equipe deste projeto deve estar preparada para disseminar o conhecimento para as demais equipes do Pólo, aproveitando os conhecimentos adquiridos. Primeiramente algumas atividades foram executadas para a avaliação da situação da Gerência de Requisitos e definição da política, dos procedimentos, dos padrões documentados e do plano de treinamento que deverão ser utilizados pelas equipes na implantação da Gerência de Requisitos. Para a implantação do processo de melhoria, nove fases (figura 14) devem ser seguidas até que se consiga o resultado esperado. Ao longo de toda a implantação os processos devem ser avaliados e continuamente ajustados de acordo com o feedback obtido. O processos podem selecionados para serem implantados ou omitidos de acordo com as características e necessidades da organização. Por exemplo, uma organização que já possui profundo conhecimento do negócio do cliente pode omitir a atividade entender o domínio da aplicação. A seguir, são descritas as nove fases que foram seguidas para implantação dos processos:
- Fase 1 - Conscientização: nesta fase, deve-se identificar a situação atual, definir o status desejado (estabelecendo metas), e tomar ações para reduzir a distância entre o status atual e o almejado. O status atual pode ser obtido por meio de observações e de questionários e entrevistas aos desenvolvedores em relação ao conhecimento e utilização dos Processos de Engenharia de Requisitos. Uma vez obtidas as informações, estas devem ser consolidadas e apresentadas aos gerentes e desenvolvedores, o que pode ser feito por meio de uma workshop , de forma a conscientizar e mobilizar os gerentes e desenvolvedores para a promoção das práticas e mudanças requeridas pelo programa. Neste evento podem ser organizadas palestras sobre o tema. É fundamental o apoio gerencial para as ações e iniciativas de aprimoramento de processos de Engenharia de Requisitos. Manter esse comprometimento e repassá-lo para os analistas é parte fundamental do processo de melhoria.
- Fase 2 - Preparação: durante a preparação devem ser escolhidos os grupos de trabalho. Estes grupos devem estar profundamente familiarizados com a filosofia e os termos utilizados nos processos de Engenharia de Requisitos. O grupo de trabalho GT-Requisitos é definido para planejar e acompanhar todas as tarefas do projeto de melhoria da capacidade. Este grupo visa garantir que o processo de implantação do modelo como um todo flua de maneira adequada. Este grupo deve aprovar, com a participação da alta gerência, um cronograma com as macro-atividades e deve modificá-lo sempre que se fizer necessário. É da responsabilidade do GT-Requisitos acompanhar e atualizar este cronograma. Dependendo do tamanho da
Fase 1 - Conscientização
Fase 2 - Preparação
Fase 3 - Treinamento
Fase 5 - Elaboração do Plano Fase 4 - Levantamento de de Melhoria
Fase 6 - Definição dos Processos
Fase 7 - Definição de Papéis e Responsabilidades
Fase 8 - Implantação
Fase 9 - Acompanhamento e Ajustes
organização podem ser definidos subgrupos de trabalho, onde o coordenador deve ser um membro do GT-Requisitos. O grupo de trabalho GT-Pessoas- chave deve ser composto por pessoas que detêm o conhecimento de como é o processo de desenvolvimento e manutenção de software na empresa. Devem ser entrevistadas e treinadas primeiro de acordo com a necessidade e a disponibilidade. Este grupo pode mudar à medida que aumenta a compreensão dos processos de software. É importante que nesta fase esteja circulando na empresa informações a respeito do trabalho sendo desenvolvido, o que pode ser feito por meio de jornais internos, circulares, e- mail ou circulação de revistas e livros que tratem sobre o tema. Pode-se também disponibilizar informações na Intranet da empresa.
Figura 10. Fases para a Implantação
- Fase 3 - Treinamento: o GT-Requisitos também deve definir um Plano de Treinamento , priorizando a participação das pessoas que compõe os grupos de trabalho. O treinamento deve preferencialmente ser preparado e aplicado por integrantes do GT-Requisitos, pois deve ser dada uma atenção especial para a adaptação dos termos do modelo de melhoria para a cultura da empresa. Todos os termos devem ser definidos e explicados fazendo, quando possível, um mapeamento para os termos equivalentes utilizados na empresa. A importância do treinamento deve-se também à oportunidade de trocar experiência entre diferentes equipes de desenvolvimento, especialmente em empresas com diferentes pólos de desenvolvimento, cada qual trabalhando com um ambiente e características de projeto próprias. Durante o treinamento, é importante que um componente do GT-Requisitos anote as sugestões e considerações que porventura apareçam, pois podem ser de grande utilidade tanto para os próximos treinamentos como para utilização ao longo do processo de melhoria.
Práticas do CMM Estratégia
Co 1 O projeto segue uma política organizacionalpara gerenciar os requisitos de software. Fase 6 - Definição dos Processos
Hb 1
Para cada projeto, está estabelecida a responsabilidade para analisar os requisitos de sistema e alocá-los ao hardware, software ou outros componentes do sistema.
Fase 7 - Definição de Papéis e Responsabilidades
2 Os requisitos de software estãodocumentados Processo de Definição
3
Estão disponíveis os recursos e fundos necessários para gerenciar os requisitos de software.
Fase 1 - Conscientização Fase 2 - Preparação Processo de Definição Processo de Elicitação de Requisitos
4
Os membros do grupo de engenharia de software e de outros grupos relacionados a software estão treinados para realizar suas atividades de gerência de requisitos.
Fase 3 - Treinamento
At 1
O grupo de engenharia de software revisa os requisitos de software, antes de serem incorporados ao projeto.
Processo de Gerenciamento & Métricas Processo de Documentação & Análise Processo de Negociação & Priorização Processo de Validação Processo de Verificação
2
O grupo de engenharia de software utiliza os requisitos de software como base para confeccionar os planos de desenvolvimento do software, desenvolver produtos de trabalho e realizar atividades.
Processo de Verificação
3
Revisar as alterações nos requisitos de software e incorporá-las ao projeto de software.
Processo de Gerenciamento & Métricas
Ve 1
A gerência sênior revisa, periodicamente, todas as atividades de gerência dos requisitos de software.
Fase 9 - Acompanhamento e Ajustes
2
O gerente de projeto revisa periodicamente ou por evento, todas as atividades de gerência dos requisitos de software.
Fase 9 - Acompanhamento e Ajustes
3
O grupo de garantia de qualidade de software revisa e/ou audita as atividades e produtos de trabalho utilizados para gerenciar os requisitos de software, reportando seus resultados.
Processo de Validação
Tabela 2. Práticas-chave e estratégia
6. Estudo de Caso
Tendo definido as diretrizes para a implantação da gerência de requisitos, um projeto-piloto foi conduzido para validar a estratégia estabelecida. A decisão sobre qual sistema adotar foi tomada com base num perfil específico. O sistema deveria atender às seguintes características:
a. possuir um cliente disposto a ser o pioneiro no processo de implantação da gerência e requisitos;
b. possuir uma técnica devidamente treinada ou disponível para treinamento nos conceitos de engenharia de requisitos, em especial sobre processos para a melhoria da qualidade;
c. possuir um escopo mínimo definido e controlável;
d. ser de importância para o contexto das organizações participantes (SERPRO e Cliente);
e. ser de fácil inserção no contexto da gerência de requisitos do SERPRO.
O sistema escolhido foi o SAD (Sistema de Apoio à Decisão), um sistema de apoio à decisão, possibilitando aos usuários de alto escalão do Cliente realizar consultas analíticas sobre uma base de dados que agrega, para várias áreas de atuação do usuário, inúmeras informações sobre as suas atividades fins. Dando suporte ao projeto, um data warehouse congrega dados provenientes dos principais sistemas do cliente, obtidas por meio de um complexo processo de extração, agregação e carga. Uma interface Web provê a acessibilidade às consultas para usuários habilitados em todo país. Isto é possível por meio das funcionalidades OLAP ( On-line Analytical Process ) [35]. Dentre estas funcionalidades, o SAD possibilita ao usuário trabalhar a informação, manipulando a sua apresentação para permitir análises de diversas maneiras, segunda diferentes critérios. É um projeto de grande porte, envolvendo o processamento de 21 bases de dados de assuntos e extração distintas, o que implica na especificação de requisitos para 21 equipes de desenvolvimento. Vale ressaltar que as equipes estão localizadas nas diversas regiões do país. Tendo escolhido o projeto piloto, foi inicializado o processo para a implantação da gerência de requisitos. Foram utilizadas ferramentas automatizadas para gerenciamento de mudanças, gerenciamento de requisitos, gerenciamento de configuração e testes. Em processos de desenvolvimentos iterativos como os aplicados no SERPRO, uma das chaves para a qualidade do produto final é o acompanhamento eficiente dos requisitos, como forma de garantir que todos os requisitos fluam corretamente entre todos os envolvidos, sem que requisito algum seja perdido, mal interpretado ou simplesmente adicionado sem a anuência do cliente. Durante o processo de Definição , foram utilizadas como técnicas de elicitação prototipação e entrevistas ao usuário. A prototipação auxiliou o usuário na descoberta de requisitos não imaginados previamente. Durante as entrevistas, foram elaborados os documentos Glossário e Visão , cuja importância foi bastante evidenciada tanto pelos desenvolvedores como pelo cliente No passo seguinte de Análise & Documentação , os requisitos foram documentados utilizando os documentos Guia de Classificação de Requisitos , Especificação de Casos de Uso e Especificação Suplementar. Estes dois últimos juntos compõe o DRS (Documento de Requisitos de Software do sistema). A escrita dos requisitos utilizou Use Cases para requisitos funcionais e descrições textuais para os requisitos não-funcionais e restrições. Uma vez definidos e instanciados os documentos, os processos de Negociação & Priorização se seguiram, onde o Analista de Requisitos apresentou os documentos de requisitos por meio de um Workshop envolvendo o cliente com o intuito de validar o
