Tema 9 - Leitura Prévia - Gerenciamento de Mudanças de Requisitos

Prévia do material em texto

1 
 
Engenharia de Requisitos 
Tema 9 – Gerenciamento de Mudanças de Requisitos 
Motivações do Gerenciamento de Requisitos; Um Modelo de um processo de 
Gerenciamento de Mudanças; Estágios principais em um processo de 
gerenciamento de mudanças; Eventos impactantes na mudanças de Requisitos; 
Componentes críticos do Gerenciamento de Requisitos; Correlação de 
componentes e possíveis impactos do processos de gerenciamento de Mudanças dos 
Requisitos. 
 
 
I - Motivações do Gerenciamento de Requisitos 
 
O gerenciamento da Mudança de Requisitos é a disciplina que visa garantir a integridade 
das versões de requisitos e continuidade da evolução planejada do software. À primeira 
vista , muitos poderão pensar na Engenharia de Requisitos têm início e fim no projeto já 
implantado e assim todo trabalho de engenharia de requisitos está concluído. Nada mais 
ilusório que supor que um sistema uma vez implantado, o sistema não possa ser afetado 
por mudanças no seu limite e contexto e, que essas mudanças não afetem as definições 
anteriores. Nessa perspectiva é necessário estabelecer um processo sistematizado para 
gerenciar as mudanças advindas com as novas e eventuais exigências ao sistema. O 
gerenciamento de mudanças destina-se a garantir que a evolução do sistema seja um 
processo gerenciado e que seja dada prioridade às mudanças mais urgentes e efetivas. O 
processo de gerenciamento de mudanças está relacionado com a análise de custos e 
benefícios das mudanças propostas, a aprovação dessas mudanças que valem a pena e o 
acompanhamento dos componentes do sistema que foram alterados. Esse roteiro 
começou pela Introdução e avança aqui pelo Gerenciamento de Mudanças de Requisitos 
e essa rota segue no mundo da tecnologia pelos caminhos à sua escolha: 
 
 
 
A mudança é uma realidade para sistemas. As necessidades e requisitos organizacionais 
se alteram durante a vida útil de um sistema, bugs precisam ser reparados e os sistemas 
2 
 
necessitam se adaptar às mudanças em seu ambiente. Para garantir que as mudanças sejam 
aplicadas ao sistema de uma forma controlada, utiliza-se um conjunto de processos de 
gerenciamento de mudanças, apoiado por ferramentas. 
 
II - Um Modelo de um processo de Gerenciamento de Mudanças 
 
Num modelo de um processo de Gerenciamento de Mudanças1 e existem muitas variantes 
desse processo em uso. No entanto, para serem eficazes, os processos de gerenciamento 
de mudanças sempre devem ter um meio de verificação, custeio e aprovação de 
mudanças. Esse processo deve entrar em vigor quando o software é desenvolvido para 
entrega aos clientes ou para implantação em uma organização. A figura a seguir é um 
modelo de um processo de gerenciamento de mudanças que mostra as principais 
atividades de gerenciamento (SOMMERVILLE, 2011). 
 
 
Modelo de um processo de Gerenciamento de Mudanças2 
 
 
 
 
Sistematização e Controle de Mudanças O processo de gerenciamento de mudanças 
inicia-se quando um ‘cliente3’ preenche e envia uma solicitação de mudança (CR4) que 
descreve a mudança requerida para o sistema. Pode tratar-se de um relatório de bug, em 
que são descritos os sintomas de um bug, ou uma solicitação para adicionar 
funcionalidade extra ao sistema. Algumas empresas tratam relatórios de bugs e novos 
 
1 Sommerville, 2011. 
2 Idem 
3 O termo ‘cliente’ para incluir qualquer stakeholder que não seja parte da equipe de desenvolvimento, 
para que as mudanças possam ser sugeridas, por exemplo, pelo departamento de marketing de uma 
empresa. 
4 Sigla de origem do inglês Change Request 
3 
 
requisitos separadamente, mas, em princípio, ambas são solicitações de mudança. As 
solicitações de mudança podem ser apresentadas por meio de um formulário de 
solicitação de alteração (CRF, do inglês change request form). 
 
Registro e processamento de Mudanças - Formulários eletrônicos de solicitação de 
mudança registram informações compartilhadas entre todos os grupos envolvidos no 
gerenciamento de mudanças. À medida que é processada a solicitação de mudança, 
informação é adicionada ao CRF a fim de que se registrem as decisões tomadas em cada 
estágio do processo. Consequentemente, a qualquer momento, ele representa um 
instantâneo do estado da solicitação de mudança. Assim como registrar a mudança 
requerida, o CRF registra as recomendações relativas à mudança, a estimativa de custos 
da mudança e as datas de quando a mudança foi solicitada, aprovada, implementada e 
validada. O CRF também pode incluir uma seção na qual um desenvolvedor descreve 
como a alteração pode ser implementada5. 
 
Validação de Mudanças - Após uma solicitação de mudança ter sido submetida, ocorre 
a análise de sua validade. O verificador pode ser de um cliente ou uma equipe de suporte 
de aplicação, ou, para solicitações internas, pode ser um membro da equipe de 
desenvolvimento. A verificação é necessária porque nem todas as solicitações de 
mudança requerem ação. Se a solicitação de mudança é um relatório de bug, o bug pode 
já ter sido relatado. Às vezes, o que as pessoas acreditam ser problemas são os equívocos 
do que se espera do sistema. Em algumas ocasiões, as pessoas solicitam recursos que já 
foram implementados, mas que elas não conhecem. Se qualquer um desses for verdadeiro, 
a solicitação de mudança é fechada e o formulário é atualizado com o motivo de 
encerramento. Se o caso for de uma solicitação de mudança válida, esta será registrada 
como uma solicitação para análise posterior. 
 
Avaliação e Estimativa de Mudanças - Para solicitações de mudança válidas, o 
próximo estágio do processo é a avaliação e estimativa de custos de mudança. 
Geralmente, essa é a responsabilidade da equipe de desenvolvimento ou de manutenção, 
pois ela pode decidir o que está envolvido na implementação da mudança. O impacto da 
mudança sobre o resto do sistema deve ser verificado. Para fazer isso, se deve identificar 
todos os componentes afetados pela mudança. Se fazer a mudança implica na necessidade 
de novas mudanças em outro lugar no sistema, o custo de implementação da mudança 
obviamente aumentará. Em seguida, são avaliadas as mudanças requeridas para os 
módulos de sistema. Finalmente, o custo de fazer a mudança é estimado, levando-se em 
consideração os custos da mudança dos componentes relacionados. 
 
Comitê de Controle de Mudanças - Na sequência dessa análise, um grupo separado 
deve decidir se a partir de uma perspectiva de negócio, fazer a mudança no software será 
efetivo. Para sistemas militares e governamentais, esse grupo costuma ser chamado de 
Comitê de Controle de Mudanças6. Na indústria, ele pode ser chamado de algo como 
‘grupo de desenvolvimento de produto’, responsável pela tomada de decisões sobre como 
 
5 Para dar suporte ao gerenciamento de versões, melhores práticas recomendam usar ferramentas de 
gerenciamento de versões (às vezes, chamadas de sistemas de controle de versões ou sistemas de 
controle de códigos-fonte). Essas ferramentas identificam, armazenam e controlam o acesso a diferentes 
versões de componentes. Há disponíveis muitos sistemas de gerenciamento de versões diferentes, 
incluindo sistemas open source amplamente usados como o CVS e Subversion (PILATO et al., 2004; 
VESPERMAN, 2003). 
6 CCB, do inglês Change Control Board. 
4 
 
um sistema de software deve evoluir. Esse grupo deve revisar e aprovar todas as 
solicitações de mudança, a menos que as mudanças envolvam a correção de pequenos 
erros em telas, páginas da Web ou documentos. Essas pequenas solicitações devem ser 
passadas para a equipe de desenvolvimento sem análise detalhada, pois uma análise 
poderia custar mais do que a implementação da mudança. 
 
Grupo de Controle de Mudanças - O CCB, ou grupo de desenvolvimento de produto 
de Mudanças, considera o impacto da mudança a partir de um ponto de vista estratégico 
e organizacional, em vez de um ponto de vista técnico. Ele decide se a mudança em 
questão se justifica economicamente e prioriza, para a implementação, asmudanças 
aceitas. Para o grupo de desenvolvimento, as solicitações de mudança rejeitadas são 
fechadas e nenhuma outra ação é tomada. 
 
 
III - Estágios principais em um processo de gerenciamento de mudanças: 
 
O gerenciamento de requisitos é o processo de compreensão e controle das mudanças nos 
requisitos do sistema. É preciso se manter a par das necessidades individuais e manter as 
ligações entre as necessidades dependentes para conseguir avaliar o impacto das 
mudanças nos requisitos.” (Sommerville, 2011, p.77-80). De acordo com Sommerville 
(2011) existem estágios principais em um processo de gerenciamento de mudanças: 
 
 Análise de problema e especificação de mudanças - O processo começa com 
um problema de requisitos identificado ou, às vezes, com uma proposta específica 
de mudança. Durante esse estágio, analisa-se o problema ou a proposta de 
mudança a fim de se verificar sua validade. Essa análise é transmitida a quem 
solicitou a mudança, que pode responder com uma proposta mais específica de 
mudança de requisitos ou retirar a solicitação. 
 
 Análise de mudanças e custos - O efeito da mudança proposta é avaliado por 
meio de informações de rastreabilidade e conhecimentos gerais dos requisitos do 
sistema. O custo de fazer a mudança é estimado em termos de modificações no 
documento de requisitos e, se apropriado, no projeto e implementação do sistema. 
Uma vez que essa análise é concluída, decide-se prosseguir ou não com a mudança 
de requisitos. 
 
 Implementação de mudanças. Melhores práticas recomendam organizar o 
documento de requisitos para poder fazer alterações sem ampla reformulação ou 
reorganização. Tal como acontece com os programas, a mutabilidade nos 
documentos é obtida minimizando-se as referências externas e tornando as seções 
do documento o mais modular possível. 
 
 Atualização da documentação - Se um novo requisito precisa ser implementado 
com urgência, há sempre a tentação de mudar o sistema e, em seguida, 
retrospectivamente modificar o documento de requisitos. Esse procedimento deve 
ser evitado, pois quase inevitavelmente faz com que a especificação de requisitos 
e a implementação do sistema fiquem defasadas. Uma vez que mudanças no 
sistema foram feitas, é fácil esquecer de incluir essas alterações no documento de 
requisitos ou acrescentar informações inconsistentes com a implementação no 
documento de requisitos. 
 
 
 
 
 
 
 
 
5 
 
 
IV -Eventos impactantes na mudanças de Requisitos 
 
1. As consequências de não fazer a mudança - Ao avaliar uma solicitação de mudança, 
melhores práticas recomendam considerar o que acontecerá se a mudança não for 
implementada. Se a mudança for associada a uma falha de sistema relatada, a gravidade 
da falha precisa ser levada em consideração. 
 
Imagem do negócio - Se a falha de sistema causar a interrupção do sistema, isso é muito 
grave, e uma falha em fazer a mudança pode interromper a operação do sistema. 
 
2. Impacto da mudança - A mudança é algo que beneficiará muitos usuários do sistema 
ou é uma proposta que beneficiará principalmente o proponente da mudança? Se apenas 
alguns usuários forem afetados, a mudança pode receber prioridade baixa. Na verdade, a 
mudança pode ser desaconselhada caso ela possa ter efeitos adversos sobre a maioria dos 
usuários de sistema. 
 
4. Impactos Financeiros - Os custos de se fazer a mudança. Se fazer a mudança afetar 
muitos componentes de sistema (aumentando, portanto, as chances de introdução de 
novos bugs) e/ou levar muito tempo para ser implementada, então ela pode ser rejeitada, 
dados os elevados custos envolvidos. 
 
5. Mudanças de produtos de Software - O gerenciamento de mudanças para produtos 
de software deve levar em consideração os impactos derivados sob a perspectiva das 
equipes de suporte do cliente, da equipe de marketing da empresa e dos próprios 
desenvolvedores em tempo de desenvolvimento . 
 
Manutenção de histórico de Mudanças – Melhores práticas para manutenção de 
histórico de Mudanças é a utilização de um repositório suportado por ferramentas 
especializadas automatizadas , as quais podem ser relativamente simples baseadas em 
Web, como o aplicativos usados para relatar problemas com muitos sistemas open source. 
Como alternativa, ferramentas mais complexas podem ser usadas aplicações integradas 
para automatizar todo o processo de tratamento de solicitações de mudança, desde a 
proposta inicial do cliente até a aprovação. 
 
 
Componentes críticos da Mudança de Requisitos 
 
Encerrado o processo de desenvolvimento, com a entrega do sistema ao cliente, diz-se 
que o sistema está em operação, quando o software é utilizado pelos usuários no ambiente 
de produção. Contudo, indubitavelmente, o software sofrerá mudanças após ter sido 
entregue para o cliente. Alterações ocorrerão porque erros foram encontrados, porque o 
software precisa ser adaptado para acomodar mudanças em seu ambiente externo, ou 
porque o cliente necessita de funcionalidade adicional ou aumento de desempenho. Tais 
mudanças incluem, entre outros aspectos: ambiente operacional, orientação 
Organizacional, conflitos de prioridades entre partes interessadas (stakeholders). 
 
 
 Quanto à Mudanças no ambiente operacional - Vimos na definição do 
requisitos que existem requisitos funcionais que se referem aos objetivos do 
6 
 
negócio, diretamente vinculados as soluções do analista para os problemas no 
domínio e regras do cliente, requisitos inversos que se referem a deixar claro 
aquelas funcionalidades que o limite do sistema não comportará e os requisitos 
não funcionais, que se referem a desempenho e qualidade a partir de uma 
arquitetura de ambiente operacional. Com efeito, “após a instalação, o ambiente 
técnico e de negócios do sistema sempre muda. Um novo hardware pode ser 
introduzido, pode ser necessário fazer a interface do sistema com outros sistemas, 
as prioridades do negócio podem mudar (com consequentes alterações necessárias 
no apoio do sistema), podem ser introduzidas novas legislações e regulamentos 
aos quais o sistema deve, necessariamente, respeitar etc” (SOMMERVILLE, 
2011, p.77-80). 
 
 Quanto à Mudanças na orientação Organizacional - Assim como os sistemas 
em função da interação com o meio ambiente, as tomadas de decisões nas 
organizações também estão em constante mudanças derivadas das estratégias 
organizacionais diante dos desafios do mercado e da conjuntura, o entendimento 
dos stakeholders a respeito do problema está em constante mutação”( 
SOMMERVILLE, 2011, p.77-80). Não raro, as pessoas que pagam por um 
sistema e os usuários desse sistema são os mesmos. “Os requisitos são 
influenciados por restrições orçamentárias e organizacionais, os quais podem 
entrar em conflito com os requisitos do usuário final, e após a entrega, novos 
recursos podem ser adicionados, para dar suporte ao usuário, a fim de que o 
sistema cumpra suas metas” (...) “Os requisitos para sistemas de software de 
grande porte estão sempre mudando ”( SOMMERVILLE, 2011, p.77-80). 
. 
 Quanto à Mudanças derivadas de conflitos de prioridades entre partes 
interessadas (stakeholders) – Conforme vimos em temas anteriores. Por 
definição um Requisito é uma condição ou capacidade necessária para um usuário 
resolver um problema ou alcançar um objetivo. Tal condição deve estar presente 
num sistema ou componente deste para satisfazer um contrato, norma, 
especificação ou outro documento formalmente imposto7. Uma representação 
comentada de uma condição ou capacidade pra resolver um problema, alcançar 
um objetivo ou contrato envolvendo stakeholders. A questão que se impõe é que 
conhecer os requisitos relevantes e estabelecer um consenso entre stakeholders 
acerca dos mesmos, de acordo com determinados padrões e processos de 
gerenciamento sistemáticos, muitas vezes representa um desafio: “Geralmente, 
sistemas de grande porte têm uma comunidade de diversos usuários, com 
diferentes requisitos e prioridades, que podem ser conflitantesou contraditórios. 
Os requisitos do sistema final são, certamente, um compromisso entre esses 
usuários, e, com a experiência, frequentemente se descobre que o balanço de apoio 
prestado aos diferentes usuários precisa ser mudado. 
 
 
Melhores Práticas em Sistema de Gerenciamento de Versões 
Normalmente, os sistemas de gerenciamento de versões fornecem uma variedade de 
recursos: 
 
7 Fonte: IEEE Standard 610.12.1990 
7 
 
1. Identificação de versão e release. Versões gerenciadas recebem identificadores 
quando são submetidas ao sistema. Normalmente, esses identificadores se baseiam no 
nome do item de configuração seguido por um ou mais números. Um sistema de 
identificação consistente é importante porque ele simplifica o problema de definição de 
configuração. Ele simplifica o uso de referências de forma abreviada. 
2. Gerenciamento de armazenamento - Para reduzir o espaço requerido de 
armazenamento pelas várias versões de componentes que diferem apenas ligeiramente, 
os sistemas de gerenciamento de versões em geral fornecem recursos de gerenciamento 
de armazenamento. Em vez de manter uma cópia completa de cada versão, o sistema 
armazena uma lista de diferenças (deltas) entre uma versão e outra. Ao aplicar estas em 
uma versão- -fonte (geralmente, a versão mais recente), uma versão de destino pode ser 
recriada. Esse processo é ilustrado 
3. Registro de histórico de mudanças - Todas as mudanças feitas no código de um 
sistema ou componente são registadas e listadas. Em alguns sistemas, essas mudanças 
podem ser usadas para selecionar uma versão específica do sistema. Isso envolve marcar 
os componentes com palavras-chave que descrevem as mudanças feitas. Em seguida, 
você usa essas marcações para selecionar os componentes que serão incluídos na baseline. 
4. Desenvolvimento independente - Desenvolvedores diferentes podem trabalhar no 
mesmo componente ao mesmo tempo. O sistema de gerenciamento de versões 
acompanha os componentes que tenham sido verificados para edição e garante que as 
mudanças feitas em um componente por diferentes desenvolvedores não interfiram 
mutuamente de modo negativo. 
5. Suporte a projetos. Um sistema de gerenciamento de versões pode apoiar o 
desenvolvimento de vários projetos, que compartilham componentes. Em sistemas de 
suporte a projetos, é possível fazer check-in e checkout de todos os arquivos associados 
a um projeto, em vez de precisar trabalhar com um arquivo ou diretório de cada vez. 
 
Sistema de Gerenciamento de Versões8 
 
 
 
 
8 Sommerville, 2011 
8 
 
Componentes críticos do Gerenciamento de Mudanças de Requisitos 
 
Após a aprovação do documento de requisitos, o gerenciamento de mudança de requisitos 
deve ser aplicado a todas as mudanças propostas aos requisitos de um sistema. O 
gerenciamento de mudanças é essencial, pois é necessário decidir se os benefícios da 
implementação de novos requisitos justificam os custos de implementação. A vantagem 
de se usar um processo formal de gerenciamento de mudanças é que todas as propostas 
de mudanças são tratadas de forma consistente, e as alterações nos documentos de 
requisitos são feitas de forma controlada. Os componentes críticos do Gerenciamento de 
Requisitos incluem: 
 
 
 Identificação de requisitos - Cada requisito deve ser identificado unicamente 
para poder ser comparado com outros requisitos e usado em avaliações de 
rastreabilidade. 
 Políticas de rastreabilidade para seleção de requisitos a serem mantidos - 
Tais políticas definem critérios para definir como e quais registros devem ser 
mantidos. 
 Uso de Ferramenta de apoio – O processo de gerenciamento de mudanças 
simplificado quando as ferramentas ativas de apoio estão disponíveis. As 
ferramentas que podem ser usadas variam desde sistemas especializados em 
gerenciamento de requisitos até planilhas e sistemas de banco de dados simples. 
O gerenciamento de requisitos precisa de apoio automatizado, e as ferramentas de 
software para esse gerenciamento devem ser escolhidas durante a fase de 
planejamento, as principais aplicações no uso de ferramentas de apoio incluem: 
 
 Guarda e Recuperação - Os requisitos devem ser mantidos em um repositório 
de dados gerenciado e seguro, acessível a todos os envolvidos no processo de 
engenharia de requisitos. 
 
 
Correlação de componentes e possíveis impactos do processos de gerenciamento de 
Mudanças dos Requisitos - O quadro a seguir faz a correlação desses componentes 
possíveis impactos do processos de gerenciamento de Requisitos. 
 
9 
 
Referências Bibliográficas 
 
FALBO, Ricardo de Almeida. Engenharia de Software. Notas de Aula UFES - 
Universidade Federal do Espírito Santo. 2014. 
 
IEEE Std 830. Prática Recomendada Para Especificações de Exigências de Software: 
Standard Internacional; por André Gonçalves, Fernando Martins, Paulo Carreira, Pedro 
Lopes, e Sérgio Nunes. Publicado Abril, 2004. Norma IEEE Std 830-1998 
 
POHL, Klaus; RUPP Chris. Fundamentos da Engenharia de Requisitos - Um guia 
para o exame CPRE-FL em conformidade com o padrão IREB. 
 
SOMMERVILLE, Ian. Engenharia de Software, 9th Edition. Pearson Brazil, 11/2015. 
VitalBook file. 
 
WASSON. System analysis, Design, and Development. Concepts, Principles, and 
Practices. Wiley-Interscience. 2006.