Qual é a melhor medida de progresso para o desenvolvimento de sistemas complexos?

Por que eu devo ler este artigo:Os projetos de desenvolvimento de software caracterizam-se por apresentar alto grau de incerteza durante a fase de levantamento de requisitos. Mesmo ap�s os requisitos terem sido levantados e o projeto j� estar em desenvolvimento, mudan�as nos requisitos podem ocorrer. Conhecer maneiras de lidar com os requisitos que mais sofrem altera��es � primordial para garantir o sucesso do projeto. Este artigo apresenta diversas formas de gerenciar e controlar as mudan�as nos requisitos, principalmente os requisitos vol�teis. Para cada forma � apresentada a sua defini��o e seus benef�cios para o gerenciamento dos requisitos.

Desenvolver softwares n�o � uma tarefa f�cil, t�o pouco trivial. V�rios fatores de risco est�o associados ao desenvolvimento do produto a ser entregue, sejam eles conhecidos ou n�o. Essa dificuldade vem desde os prim�rdios da computa��o, onde era grande a dificuldade em entregar os sistemas. Naquela �poca n�o existiam processos de desenvolvimento de software bem definidos, ou simplesmente n�o havia nenhum. Com o passar do tempo surgiu a engenharia de software, a qual se ocupou em encontrar solu��es para resolver os problemas que levavam ao fracasso dos projetos. Processos de desenvolvimento de software e modelos de desenvolvimento de software foram criados e se tornaram excelentes ferramentas para construir sistemas.

Muitas solu��es foram propostas ao longo dos anos, de forma que os problemas relacionados aos requisitos considerados inst�veis fossem minimizados. Uma das solu��es propostas foi o congelamento dos requisitos, atrav�s de m�todos formais, os quais se utilizavam de nota��es matem�ticas para realizar a especifica��o de requisitos de software. Entretanto, a pr�tica mostrou que o congelamento de requisitos n�o era uma boa solu��o, uma vez que o engessamento do processo acabava atrapalhando. Com o passar do tempo chegou-se � conclus�o de que o projeto precisava ficar em constante refinamento, objetivando a estabilidade dos requisitos.

A ado��o da prototipa��o tornou-se uma �tima ferramenta, uma vez que ajuda o cliente a entender melhor as suas necessidades e validar os requisitos que foram coletados. A valida��o dos prot�tipos, por parte do cliente, refina os requisitos e direciona o desenvolvimento para um caminho ideal. Com o tempo, foram criados novos processos de desenvolvimento de software, os quais se tornaram mais din�micos e propuseram solu��es para lidar com requisitos vol�teis.

Embora a engenharia de software tenha criado processos que ajudaram a resolver os grandes atrasos e fracassos dos projetos, desenvolver softwares continuou a ser uma tarefa dif�cil. Ainda � muito comum que os usu�rios n�o conhe�am totalmente suas necessidades. Al�m disso, os requisitos n�o permanecem imut�veis ao longo do ciclo de vida do desenvolvimento do software, por isso � preciso estar bem atento a esse detalhe. A essa mudan�a dos requisitos d�-se o nome de volatilidade. Quanto mais vol�til for um requisito, maior ser� o risco de n�o entregar o projeto no prazo estipulado e dentro dos custos previstos. A volatilidade dos requisitos torna praticamente imposs�vel criar uma arquitetura que seja imune a isso, uma vez que na fase inicial do projeto os requisitos ainda n�o est�o bem definidos e na maioria das vezes alguns detalhes da especifica��o s� s�o conhecidos durante a implementa��o do sistema.

Requisitos vol�teis, estimativas pobres e muito otimistas se constituem nas principais causas dos projetos de software sa�rem do controle, tornando-se dif�cil de serem gerenciados. Os problemas relacionados �s estimativas s�o derivados diretamente da ger�ncia, a qual n�o fez uma estimativa correta. J� os problemas decorrentes da volatilidade dos requisitos est�o intimamente relacionados ao desenvolvimento do software, sendo bem mais complexos de serem resolvidos.

Dependendo do cen�rio que ocasiona a volatilidade dos requisitos, torna-se necess�rio considerar a utiliza��o de metodologias �geis, pois elas proporcionam um feedback cont�nuo ao cliente e a equipe, atrav�s de curtas itera��es e pequenos releases, objetivando entregar uma solu��o que atenda �s necessidades do cliente e com qualidade. Al�m de utilizar metodologias �geis, tamb�m � necess�rio que o projeto seja dividido em m�dulos, cada um com �vida pr�pria� e com pequenos ciclos de desenvolvimento. Dessa forma, um m�dulo n�o depende funcionalmente de outro m�dulo e se acontecer alguma mudan�a nos requisitos n�o haver� um grande impacto no sistema como um todo, apenas no m�dulo onde ocorreu a mudan�a dos requisitos.

Requisitos est�veis e requisitos vol�teis

Mudan�as nos requisitos de um sistema podem acontecer em qualquer fase do ciclo de desenvolvimento do software. Alguns requisitos s�o mais suscept�veis a mudan�as do que outros, o que os torna muito mais inst�veis. A mudan�a nos requisitos n�o implica em dizer que o processo de desenvolvimento adotado n�o � eficiente, afinal as mudan�as s�o inevit�veis. Nesta situa��o � fundamental saber controlar essas mudan�as de forma que a implementa��o do software seja poss�vel.

Os requisitos s�o considerados est�veis ou permanentes quando s�o derivados da atividade principal da organiza��o, isto �, s�o derivados do modelo de dom�nio da organiza��o. Como exemplo de requisitos est�veis, podemos considerar os requisitos de uma faculdade, onde sempre haver� requisitos relativos aos alunos, aos professores, as turmas, notas dos alunos e as aulas.

Os requisitos s�o considerados vol�teis quando mudam � medida que o sistema est� em desenvolvimento ou j� em uso. Podemos citar com exemplos de requisitos vol�teis os requisitos resultantes de pol�ticas governamentais, os quais mudam de acordo com a aprova��o de uma legisla��o ou decreto, requisitos que n�o podem ser completamente definidos antes da implementa��o do sistema, entre outros.

Os requisitos vol�teis s�o classificados como:

1. Requisitos mut�veis se modificam de acordo com as mudan�as do ambiente ao qual a organiza��o est� operando;
2. Requisitos emergentes: s�o requisitos que v�o surgindo � medida que a compreens�o do cliente se desenvolve durante o desenvolvimento do sistema. Ao longo do ciclo de desenvolvimento poder�o surgir novos requisitos emergentes;
3. Requisitos consequentes: s�o requisitos que resultam da introdu��o do sistema no ambiente do usu�rio. Essa introdu��o faz com que o cliente perceba a necessidade de outros requisitos em consequ�ncia do uso do sistema que foi introduzido no meio de trabalho;
4. Requisitos de compatibilidade: dependem de outros elementos e mudam sempre que estes mesmos elementos tamb�m mudam.

A seguir ser�o apresentadas algumas estrat�gias para lidar com os requisitos vol�teis.

Gerenciamento de mudan�as de requisitos

Como citado anteriormente, inevitavelmente, os requisitos v�o mudar ao longo do ciclo de desenvolvimento do sistema e quanto mais vol�teis forem os requisitos, maiores as probabilidades de haver mudan�as. Gerenciar essas mudan�as torna-se crucial para poder ter um controle sobre os requisitos do sistema. Utilizar um processo formal de gerenciamento de mudan�a de requisitos faz com que todas as propostas de mudan�a sejam tratadas de modo consistente, contribuindo para que as mudan�as nos documentos sejam feitas de forma controlada.

V�rios fatores ocasionam mudan�a nos requisitos, tais como:

• Requisitos que n�o s�o claramente definidos e/ou escritos de forma amb�gua;
• Os requisitos foram obtidos de v�rios usu�rios diferentes;
• Mudan�a de usu�rios chave durante o levantamento dos requisitos;
• Dificuldade em expressar os requisitos utilizando a linguagem natural;
• Diferentes tipos de requisitos em diferentes n�veis de detalhe;
• Depend�ncia entre os requisitos;
• Altera��es constantes nos requisitos em decorr�ncia do entendimento sobre o neg�cio evoluir apenas durante a fase de desenvolvimento.

Os sistemas devem ser desenvolvidos de forma a controlar as altera��es sofridas, fazendo com que seu desenvolvimento seja impactado o m�nimo poss�vel com tais mudan�as. A mudan�a dos requisitos deve ser um processo controlado, visando garantir a qualidade do sistema. Toda mudan�a deve ser analisada e avaliada, visando buscar maneiras de ser implementada de forma eficiente e com o m�nimo poss�vel de custo, quer seja custo financeiro ou de esfor�o.

O gerenciamento de mudan�a de requisitos pode ser organizado nos seguintes est�gios (ver Figura 1):

1. An�lise do problema e especifica��o da mudan�a � nesse est�gio � identificado um problema com os requisitos ou com a proposta de mudan�a requerida. Em seguida � feita uma an�lise sobre a validade dessa mudan�a, podendo ser feita uma proposta mais espec�fica de mudan�a nos requisitos;
2. An�lise e custo da mudan�a � nesse est�gio o efeito da mudan�a � avaliado junto a outros requisitos. Estima-se o custo da mudan�a em termos de modifica��o no documento de requisitos. Ap�s ser estimado o custo, ser� decidido se a altera��o ser� realizada ou n�o;
3. Implementa��o de mudan�as � nesse est�gio s�o feitas as atualiza��es nos documentos de requisitos de forma a refletir as mudan�as que foram solicitas;

Figura 1. Gerenciamento de Mudan�a de Requisitos.

As principais preocupa��es do gerenciamento dos requisitos s�o:

• Gerenciar as mudan�as nos requisitos;
• Manter a rastreabilidade entre os requisitos;
• Gerenciar os demais documentos que se relacionam aos documentos de requisitos ao longo do ciclo de vida do projeto.

Os requisitos devem ser documentados e controlados, de forma a minimizar o impacto e as dificuldades que possam vir a acontecer com as mudan�as. O gerenciamento de requisitos ajuda tamb�m a evitar que funcionalidades menos importantes sejam implementadas antes daquelas com maior urg�ncia, minimizando o impacto de altera��es que possam vir a ser desenvolvidas sem a devida aprova��o. Devemos tamb�m ter o cuidado com as mudan�as de requisitos solicitadas com urg�ncia, pois em muitos casos s�o realizadas as mudan�as no sistema, deixando para fazer a mudan�a nos requisitos posteriormente, o que em muitas situa��es acabam n�o acontecendo por falta de tempo ou esquecimento.

Uma boa pr�tica � antecipar as mudan�as de requisitos, classificando-os para identificar quais deles s�o os mais vol�teis e prever poss�veis mudan�as. Estas informa��es s�o �teis para projetar o sistema de forma que os requisitos sejam implementados com independ�ncia de componentes, minimizando assim a influ�ncia das mudan�as no sistema. A utiliza��o de m�tricas de software, como a APF (An�lise de Ponto de Fun��o) por exemplo, torna poss�vel medir uma funcionalidade e determinar o tamanho das mudan�as de requisitos, bem como a evolu��o do tamanho do sistema.

Note que o gerenciamento de mudan�a de requisitos se constitui numa excelente ferramenta para lidar com os requisitos vol�teis, uma vez que � um processo controlado, orientado a mudan�as e que possui as ferramentas necess�rias para esse controle.

Rastreabilidade de Requisitos

A rastreabilidade � uma ferramenta bastante �til, pois nos ajuda a entender o relacionamento entre produtos de trabalho, sejam eles especifica��es de requisitos, c�digo fonte, arquitetura do sistema, testes de softwares, entre outros, nos ajudando a garantir a integridade entre estes elementos. Em gerenciamento de requisitos, a rastreabilidade nos ajuda a entender a rela��o entre os requisitos definidos pelo cliente e os produtos resultantes destes requisitos como especifica��es, prot�tipos e testes.

A rastreabilidade ajuda a gerenciar os requisitos de forma mais eficaz. Diz-se que um requisito � rastre�vel quando � poss�vel identificar quem solicitou o requisito, porque o requisito existe, quais os requisitos que est�o relacionados com ele e como esses requisitos se relacionam entre si e com outros elementos do produto do trabalho. Todas essas informa��es s�o utilizadas para identificar quais requisitos s�o afetados por poss�veis propostas de mudan�as.

A rastreabilidade tem como principais objetivos:

• Compreender a origem dos requisitos;
• Gerenciar mudan�as nos requisitos;
• Avaliar o impacto da mudan�a de um requisito no projeto;
• Avaliar o impacto da falha de um teste nos requisitos;
• Verificar se todos os requisitos do sistema foram implementados.

Quando um requisito muda, seus relacionamentos com outros requisitos podem ser afetados. Assim, todos os v�nculos desse requisito s�o considerados como �v�nculo de rastreabilidade suspeito�. Isso ajuda a analisar a mudan�a e determinar se os itens associados tamb�m precisar�o ser mudados, contribuindo para uma melhor an�lise de mudan�as que poder�o vir a impactar no projeto.

Uma ferramenta bastante �til para fazer a rastreabilidade de requisitos � a matriz de rastreabilidade (ver Figura 2). Ela cont�m informa��es sobre os requisitos e a sua origem, sendo bastante �til para identificar a import�ncia de cada um dos requisitos descritos nos documentos de requisitos e consequentemente avaliar o grau de compatibilidade das entregas com o planejado.

Figura 2. Matriz de Rastreabilidade de Requisitos.

A rastreabilidade dos requisitos � uma forma bastante eficaz para lidar com requisitos vol�teis, uma vez que d� uma vis�o macro do impacto desses requisitos no projeto. O mais importante � fazer com que outros requisitos tenham o m�nimo poss�vel de depend�ncia dos requisitos vol�teis, diminuindo assim o custo, retrabalho e atrasos.

Valida��o dos Requisitos

A valida��o dos requisitos se encarrega de verificar se os requisitos realmente atendem as necessidades do cliente. Durante a valida��o dos requisitos, a decis�o sobre se um requisito possui o n�vel necess�rio de qualidade � tomada, e tamb�m, se os requisitos podem ser aprovados para uso nas demais atividades de desenvolvimento. Essa decis�o deve ser tomada com base em crit�rios de aceita��o previamente definidos. Assim, o objeto da valida��o de requisitos � descobrir erros nos requisitos documentados.

A valida��o dos requisitos � de fundamental import�ncia para o desenvolvimento de um sistema, uma vez que � uma forma de reduzir os riscos de um requisito errado ser propagado para as demais fases do ciclo de desenvolvimento, ajudando assim a melhorar a qualidade do produto que est� sendo desenvolvido. Resolver erros nos requisitos quando o sistema j� est� em opera��o implica no aumento de custos, esfor�o e tempo para corrigi-los.

Diferentes tipos de verifica��o devem ser feitos durante a valida��o dos requisitos. As principais s�o:

1. Verifica��es de validade;
2. Verifica��es de consist�ncia;
3. Verifica��es de completeza;
4. Verifica��es de realismo;
5. Facilidade de verifica��o.

As principais t�cnicas utilizadas para validar os requisitos s�o:

1. Revis�es de requisitos;
2. Prototipa��o;
3. Casos de testes;
4. An�lise automatizada da consist�ncia dos requisitos.

A valida��o dos requisitos � muito importante e no caso dos requisitos vol�teis se torna uma ferramenta bastante eficiente, uma vez que s�o verificadas as consist�ncias e validade desses requisitos. Isso faz com que os requisitos sejam priorizados de acordo com a sua criticidade, evitando desenvolver funcionalidades inst�veis demais e que geram muito retrabalho.

Revis�o de requisitos

A revis�o de requisitos � um processo manual, onde os documentos de requisitos s�o examinados e lidos por algu�m da equipe ou pelo pr�prio cliente. A revis�o ajuda na valida��o dos requisitos, uma vez que poss�veis erros de conte�do ou interpreta��o s�o esclarecidos, a fim de evitar requisitos mal definidos, perda de informa��es, inconsist�ncias, requisitos conflitantes ou requisitos irreais.

Para validar os requisitos, torna-se importante ter um roteiro. Um checklist (lista de verifica��o) com crit�rios a serem avaliados deve ser seguido. O checklist cont�m perguntas ou afirma��es sobre uma determinada circunst�ncia, sendo aplicado sempre que v�rios aspectos tenham que ser considerados em ambientes complexos, em que nenhum aspecto possa vir a ser omitido.

A aplicabilidade de um checklist e seu sucesso depende da complexidade dele mesmo. Um n�mero muito grande de perguntas pode acabar dificultando o seu uso, j� que nem sempre o avaliador tem uma vis�o aprofundada sobre as perguntas. � extremamente recomend�vel que o checklist tenha um n�mero de perguntas que n�o venham a atrapalhar a sua pr�pria utiliza��o, e que essas perguntas n�o sejam demasiadamente gen�ricas, mas sim coesas e precisas.

Os principais objetivos de um checklist s�o:

• Descobrir erros de l�gica ou implementa��o;
• Verificar que o sistema atende aos requisitos especificados;
• Garantir que o sistema seja desenvolvido de maneira uniforme;
• Desenvolver projetos mais gerenci�veis.

As quest�es elaboradas para o checklist de requisitos devem apontar problemas e defeitos que possam aparecer nos documentos de requisitos. A Tabela 1 lista as principais caracter�sticas para uma boa especifica��o de requisitos.

Tabela 1. Caracter�sticas dos requisitos a serem avaliadas.

A Tabela 2 mostra quest�es a serem respondidas para cada uma das caracter�sticas mostradas na Tabela 1.

Tabela 2. Exemplo de checklist para avalia��o de requisitos

Conflitos, contradi��es, erros e omiss�es que por ventura foram encontrados, dever�o ser destacados na revis�o e serem formalmente registrados. A partir da�, fica a cargo dos usu�rios e da equipe de desenvolvimento propor e negociar solu��es para os problemas identificados.

Note que o checklist para a valida��o dos requisitos fornece estrat�gias para lidar com os requisitos vol�teis, ajudando no processo de gerenciamento dos requisitos.

Metodologias �geis e requisitos vol�teis

Press�es cada vez maiores por um desenvolvimento de software que se encaixe dentro do custo estipulado, com prazos cada vez menores, aliados a regras de neg�cio cada vez mais complexas, fez com que houvesse a necessidade de buscar um processo de desenvolvimento de software que pudesse suportar as press�es e desenvolver sistemas com qualidade e dentro dos prazos previstos.

Em 2001, um grupo de especialistas se reuniu e publicou um manifesto com uma s�rie de princ�pios comuns, visando acelerar o desenvolvimento de software atrav�s da melhoria cont�nua do processo, gerando benef�cios como o aumento da comunica��o e colabora��o cont�nua do cliente, evitando falhas na elabora��o, respostas r�pidas �s mudan�as e aumento significativo da produtividade. O manifesto recebeu o nome de �manifesto �gil�.

O manifesto �gil acabou propiciando o aparecimento das metodologias �geis, as quais t�m o objetivo de acelerar o desenvolvimento de software e garantir a qualidade do mesmo. O manifesto �gil possui os seguintes valores:

• Indiv�duos e intera��es s�o mais importantes do que processos e ferramentas;
• Software funcionando � mais importante do que uma documenta��o extensa;
• O relacionamento com o cliente � mais importante do que a negocia��o do contrato;
• Responder �s mudan�as � mais importante do que seguir o planejamento;

Al�m dos quatro valores citados, o manifesto �gil tamb�m publicou doze princ�pios, os quais s�o:

• Garantir a satisfa��o do cliente entregando rapidamente e continuamente softwares funcionais;
• Softwares funcionais s�o entregues frequentemente;
• Softwares funcionais s�o a principal medida de progresso do projeto;
• Mudan�as s�o bem-vindas, mesmo que ocorram tardiamente no desenvolvimento;
• Coopera��o constante entre o cliente e a equipe de desenvolvimento;
• Construa projetos em torno de indiv�duos motivados, propiciando a eles ambiente e suporte necess�rio e confiando neles para fazer o trabalho;
• Design do software deve prezar pela excel�ncia t�cnica;
• Simplicidade;
• R�pida adapta��o �s mudan�as;
• Indiv�duos e intera��es mais do que processos e ferramentas;
• Softwarefuncional mais do que documenta��o extensa;
• Colabora��o com clientes mais do que negocia��o de contratos;
• Responder a mudan�as mais do que seguir um plano.

A falta de informa��o e a falta de experi�ncia na utiliza��o das metodologias �geis tem feito com que muitos profissionais negligenciem as t�cnicas tradicionais de levantamento e an�lise de requisitos. Isso se explica devido � confus�o feita com o segundo valor do manifesto �gil, o qual diz que software funcionando � mais importante do que uma documenta��o extensa. Ao contr�rio do que se pensa, as metodologias �geis n�o rejeitam os processos e ferramentas, documenta��o, negocia��o de contratos e o planejamento. Longe disso, as metodologias �geis mostram que estes itens t�m uma import�ncia secund�ria quando comparados com os indiv�duos e intera��es, um software funcional, a colabora��o do cliente, respostas r�pidas a mudan�as e intera��es.

As metodologias �geis t�m como foco principal entregar software ao cliente, atrav�s de entregas frequentes em intervalos de tempo mais curtos. Devido ao curto intervalo de tempo para as entregas, a documenta��o dever� ser criada de forma a atender apenas ao que est� sendo entregue. Assim, evita-se criar uma documenta��o extensa, a qual conter� requisitos e regras de neg�cios que n�o sejam implementadas ou ent�o que sejam desatualizadas.

As metodologias �geis possuem as seguintes vantagens:

• Entregas mais r�pidas, frequentes e regulares;
• Foco no que � priorit�rio e traz mais valor para o cliente;
• Transpar�ncia e visibilidade do status do projeto;
• Flexibilidade para as mudan�as nos requisitos, antecipa��o dos problemas e maior agilidade na tomada de decis�es;
• Melhoria da qualidade final do produto;
• Produtividade;
• Equipes auto gerenci�veis, maior autonomia, disciplina e regularidade;
• Maior comprometimento por parte dos integrantes da equipe;
• Melhoria na comunica��o.

Nos m�todos tradicionais de desenvolvimento de software � definido, no in�cio do projeto, um cronograma que cont�m as atividades a serem realizadas durante o andamento do projeto e o prazo de conclus�o do mesmo. Na pr�tica, os prazos podem sofrer atrasos e falhar por diversos motivos. Com as metodologias �geis esse problema praticamente n�o ocorre, pois os prazos s�o dados para que sejam desenvolvidas pequenas partes do sistema, num curto prazo. Assim, s�o feitas entregas que agregam valor ao sistema e ao cliente, evitando criar documenta��o e funcionalidades desnecess�rias.

A principal ideia das metodologias �geis � que � imposs�vel conhecer todos os requisitos antes de come�ar a codificar o sistema, por isso � um desperd�cio de esfor�o tentar. Assim, as metodologias �geis prezam por determinar o m�nimo necess�rio para come�ar a implementar o sistema e suprir a falta de documenta��o escrita trazendo a pr�pria fonte das informa��es para pr�ximo da equipe de desenvolvimento. As metodologias �geis s�o baseadas em entregas iterativas e incrementais, ou seja, s�o baseadas em ciclos curtos, nos quais o sistema vai sendo entregue em peda�os funcionais para o cliente. Com isso, o retorno quanto � adequa��o do software � obtido de maneira mais r�pida, sendo mais f�cil fazer corre��es ou adapta��es de requisito.

Nas metodologias �geis, a principal caracter�stica � a aceita��o de mudan�a nos requisitos, planejamento do escopo e nas prioridades do projeto. Assim, deve-se focar na simplicidade e na rapidez, buscando reduzir custos e tempo quando mudan�as surgirem e decidir quais provid�ncias dever�o ser tomadas nessas situa��es. O gerenciamento dos projetos que utilizam as metodologias �geis se preocupa em definir o escopo em um alto n�vel, permitindo o entendimento do trabalho. Uma vez que o escopo est� definido, os requisitos s�o priorizados e definidos com a participa��o de toda a equipe do projeto e o cliente, os quais discutem e definem as funcionalidades durante cada itera��o do ciclo de desenvolvimento. Essa abordagem � importante, pois reduz o efeito gold plating, ou seja, adicionar ao sistema, de forma arbitr�ria, funcionalidades que n�o foram solicitadas pelo cliente, apenas porque os desenvolvedores consideraram que o sistema necessitava da funcionalidade e que ela iria agregar algum valor ao sistema, ao inv�s de agregar valor ao neg�cio do cliente.

Assim como os processos tradicionais, os processos focados nas metodologias �geis tamb�m precisam lidar com as mudan�as que surgem ao longo do ciclo de desenvolvimento, especialmente os requisitos vol�teis. Desta forma, torna-se necess�rio um modelo eficiente e capaz de gerenciar as mudan�as e a utiliza��o das vers�es dos artefatos que s�o geradas a cada nova funcionalidade ou mudan�a. A engenharia de software possui uma �rea que tem como objetivo controlar e gerenciar as mudan�as, a qual � chamada de Gest�o de Configura��o de Software (GCS). Ela � capaz de atender tanto os processos formais, quanto as metodologias �geis, propiciando o controle do processo de desenvolvimento e as mudan�as do produto durante todo o ciclo de vida, permitindo que elas ocorram sem causar impacto no ambiente de desenvolvimento. O objetivo da GCS � manter a integridade dos produtos de trabalho, realizando identifica��o de todos os itens de configura��o do software desenvolvidos, mantendo rastreabilidade das mudan�as, disponibilizando informa��es sobre o est�gio do desenvolvimento e realizando auditorias nos processos de GCS.

A ado��o da GCS em ambientes �geis � extremamente eficiente, uma vez que o software evolui de maneira segura e ordenada, disponibilizando informa��es sobre o est�gio do desenvolvimento e auxiliando a melhoria cont�nua do processo de produ��o. Tudo isso � fundamental em um ambiente �gil, onde s�o feitas libera��es constantes de novas vers�es e a absor��o cont�nua de novos requisitos. As pr�ticas tradicionais e o planejamento da GCS devem ser adaptados, de forma a controlar as mudan�as sem comprometer a filosofia das metodologias �geis. Para isso, deve-se adotar ferramentas que automatizem as atividades da GCS, como as ferramentas de controle de vers�o e mudan�a, uma vez que oferecem funcionalidades �teis como o versionamento autom�tico dos itens de configura��o, integra��o cont�nua e rastreabilidade das mudan�as.

As metodologias �geis contribuem significativamente para desenvolver sistemas que apresentam requisitos vol�teis, uma vez que elas priorizam os requisitos que s�o melhor compreendidos e mais est�veis. Al�m disso, elas possuem uma boa aceita��o em rela��o �s mudan�as, buscando resolv�-las da forma mais r�pida poss�vel, evitando implementar o sistema com erros e atrasos.

Desenvolver sistemas sem que haja mudan�a nos requisitos seria ideal para qualquer time de desenvolvimento. Entretanto, mudan�as sempre ir�o ocorrer e � preciso estar preparado para receb�-las e, principalmente, como solucion�-las de forma a cumprir com o escopo e o prazo que foram acordados. A volatilidade dos requisitos influencia muito no gerenciamento dos requisitos, mas isso n�o � o fim do mundo. � preciso estar muito atento em rela��o �s mudan�as e se utilizar das melhores pr�ticas da engenharia de software, de forma a contornar os problemas quando eles aparecerem e garantir o sucesso do projeto.

Confira tamb�m

Refer�ncias

• AGILE ALLIANCE, Manifesto for agile software development
• ENGHOLM, H�lio, Engenharia de Software na Pr�tica, 1 �. ed , S�o Paulo, Novatec, 2010.
• MACEDO, P. C., Sbrocco, T. C., Henrique, J., Metodologias �geis: Engenharia de Software Sob Medida, 1 �. ed, �rica, S�o Paulo, 2012.
• PRESSMAN, Roger S., Engenharia de Software, 6 �. ed, S�o Paulo, McGrawHill, 2006.
• SOMMERVILLE, Ian, Engenharia de Software, 8�. ed, S�o Paulo, Addison-Wesley, 2007.

• Engenharia de Software
• Requisitos

Confira outros conte�dos: