E
EN
NG
G
EN
E
NH
HA
AR
R
IA
I
A
D
D
E
E
S
S
OF
O
FT
T
WA
W
AR
RE
E
2 35 3 Gerenciamento de Requisitos - Gerenciamento de Configuração - Gerenciamento de Mudanças – Gerenciamento de Versões e Releases
T
TÓÓPPIICCOO3355--GGEERREENNCCIIAAMMEENNTTOODDEECCOONNFFIIGGUURRAAÇÇÃÃOO--GGEERREENNCCIIAAMMEENNTTOO D
DEEMMUUDDAANNÇÇAASS––GGEERREENNCCIIAAMMEENNTTOO DDEEVVEERRSSÕÕEESSEERREELLEEAASSEESS
1. Gerência da Configuração
A Gerência de Configuração está comumente associada a dois tipos de tarefas: controle de versões e controle de configuração.
1.1 Controle de versões
Por controle de versões entende-se as atividades associadas a manter, sob estrito acompanhamento, as diferentes versões de um artefato. Nas metodologias tradicionais de desenvolvimento, após clientes, usuários e equipe de desenvolvimento terem identificado e validado o conjunto de requisitos que será atendido pelo software, tem início as etapas que envolvem design, codificação, testes, etc. Mudanças em requisitos já registrados no documento de requisitos podem impactar na arquitetura proposta para o sistema, na organização de componentes, em casos de testes, em prazos e custos. Mudanças, portanto, devem ser rigorosamente controladas; o controle de versões possibilita manter a história de todas as diferentes versões dos artefatos, ao longo do ciclo de vida do sistema; isto inclui desde o levantamento inicial de informações, passa pelas atividades do processo de requisitos, e indo ainda além, durante as atividades de evolução.
O controle de versões é fundamental para garantir que toda a equipe compartilha a mesma versão dos artefatos sendo trabalhados. Se isto não acontecesse, poderíamos ter a situação onde o conjunto de casos de teste sendo trabalhados pela equipe responsável pelos procedimentos de qualidade considera requisitos diferentes daqueles que estão em processo de implementação, ou mesmo já implementados. Se essa divergência entre o que foi implementado e o que vai ser testado não for identificada a tempo, os testes apontariam defeitos inexistentes, ou, no pior caso, deixariam de apontar defeitos presentes na implementação. Com o controle de versões, torna-se mais fácil garantir que todos os envolvidos no sistema em desenvolvimento compartilhem a mesma versão do documento de requisitos e dos demais artefatos utilizados durante as várias atividades associadas à criação do sistema.
Quando o desenvolvimento do software é distribuído, ou terceirizado, o controle de versões torna-se mais crítico, sendo fundamental a utilização de uma ferramenta que auxilie esse trabalho. Muitas vezes a empresa contratante sofre pressões para a rápida liberação do software no mercado, para fazer frente à concorrência. A tendência é dividir o trabalho entre várias equipes, e não é incomum a situação onde uma equipe executa o processo de requisitos, passa os artefatos para uma segunda equipe efetuar projeto e implementação, enquanto uma terceira fica encarregada dos testes. Se mudanças nos artefatos de requisitos não forem comunicadas a todos os envolvidos, então a situação descrita acima tem probabilidade bastante alta de acontecer.
Por controle de configuração entende-se as atividades associadas a manter, sob estrito acompanhamento, o conjunto de artefatos relacionadas a uma determinada configuração do sistema. Um exemplo bastante comum é encontrado nas versões demo de muitos softwares comercializados: em relação à versão full, a versão demo possui restrições de funcionalidades, de período de utilização ou de quantidade de informações manipulada e/ou armazenada. Nestes casos, os requisitos da versão demo certamente possuem diferenças em relação aos requisitos da versão full - essas diferenças correspondem justamente às restrições colocadas pelo fabricante na versão para demonstração. Isto vale também para outros artefatos, pois essas restrições não se limitam ao conjunto de requisitos: elas podem implicar na arquitetura, nos componentes, nos casos de teste, etc. Gerencia de configuração, portanto, envolve manter controle sobre os diferentes artefatos e componentes que fazem parte de cada uma das diferentes configurações para o software em pauta.
A figura 1.4 a seguir ilustra a situação onde, ao longo do tempo, foram sendo geradas diferentes revisões de uma mesma versão do software (a revisão 1.0 após a primeira alteração passou a ser denominada de 1.1, que por sua vez depois de alterada passou a ser denominada de 1.2 e assim por diante). Na mesma figura também podem ser visualizadas as revisões de outra configuração ou variante do mesmo software; revisões estas geradas a partir da revisão 1.1 da configuração principal. Todos os artefatos que correspondem a uma versão (ou revisão) devem ser consistentes uns com os outros, ou seja, todos devem refletir o mesmo conjunto de requisitos.
variante 1.1.1 1.1.2
...
configuração
Figura 1.4 - diferentes revisões e configurações de um software
1.3 Ferramentas para controle de versões e gerência de configuração
O mercado disponibiliza diversas ferramentas que podem ser utilizadas tanto para controle de versões como para gerência de configuração. Visual SourceSafe, CVS e ClearQuest são algumas das ferramentas disponíveis com estas finalidades. Uma das mais utilizadas é o CVS - Concurrent Version System, licenciado na forma de software livre. Iremos relacionar algumas das características deste software, que são também encontradas em outras ferramentas que possuem o mesmo propósito.
O CVS utiliza o conceito de repositórios para armazenamento e controle de versões de arquivos. Os diretórios que compõem a estrutura dos arquivos depositados no repositório são chamados de módulos; muitos comandos de CVS referem-se a módulos ao invés de arquivos. O administrador (gerente do projeto, por exemplo), cria o repositório e define os usuários que poderão ter acesso aos arquivos nele armazenados. É possível restringir os direitos de acesso dos usuários aos arquivos controlados. As operações de check in e check out possibilitam ao desenvolvedor executar a "retirada" de um arquivo (ou de um conjunto de arquivos) para o seu próprio diretório de trabalho, fazer as modificações necessárias e recolocar os componentes modificados sob o gerenciamento do controlador de versões. O controlador, por sua vez, mantém controle sobre estas operações, verificando e informando ao usuário se alguma outra operação de modificação foi executada sobre o mesmo componente.
Ferramentas deste tipo costumam trabalhar com estruturas de diretórios para o armazenamento das diferentes configurações do software sendo gerenciado; isto facilita a co-existência de diferentes configurações para um mesmo software. O espaço para armazenamento é otimizado, pois a cada nova versão, apenas as diferenças em relação à anterior são armazenadas - o CVS se encarrega de fazer a identificação das diferenças entre uma versão ou revisão e a sua anterior.
2. Controle de Mudanças
Em um ambiente real de desenvolvimento de software mudanças são inevitáveis. Em muitos dos casos os requisitos do sistema mudam enquanto o sistema aida está sendo desenvolvido. As razões para mudanças são de vários tipos, entre outras:
• A complexidade dos sistemas impõe mudanças à medida que se adquire maior conhecimento sobre os mesmos,
• Requisitos errados ou mal definidos precisam ser corrigidos/ajustados ao longo do processo de desenvolvimento,
• Mudanças no ambiente: regras de negócios, leis, políticas internas,
• Desenvolvedores querem adicionar funcionalidades mais avançadas de modo a oferecer vantangem
• Tecnologia muda, • Clientes mudam de idéia.
A grande verdade é que no ambiente corporativo atual, sistemas de informação devem estar em constante evolução de modo a servir as necessidades de seus usuários. Este fenômeno é particular a sistemas de inforamação e foi observado inicialmente por Manny Lehman [Lehman96]. Este tipo de sistema, também conhecido como sistema do tipo E (evolutionary) se caracteriza por, uma vez instalado, tornar-se parte do meio ambiente e acabar alterando seus próprios requisitos. Sistemas do tipo E estão inseridos
no mundo real, infinito e contínuo, o que determina a impossibilidade de se obter para os mesmos especificações exatas e completas. Os modelos de especificação de software que somos capazes de desenvolver são finitos (tempo finito para o desenvolvimento, memória finita para guardar, recursos limitados). Para agravar a situação, estes sistemas também devem levar em conta que o mundo real está em constante mudança – de modo que algumas das hipóteses iniciais podem se tornar incorretas (sem que nos demos conta disto).
Desta forma a atitude correta perante a gerência de requisitos é "preparar para mudar". Segundo Caper Jones os requistos de sofware se modificam, em média, na taxa de 2% ao mês durante as fases de projeto e codificação. Durante a fase de manutenção esta taxa pode aumentar. A mudança nos requisitos é comumente chamada de volatilidade; parte das atividades da gerência de requisitos é controlar mudanças. O CMM define mudanças como:
As alterações que precisam ser feitas nos requisitos e artefatos de software. É fudamental que as alterações dos requisitos sejam:
• Identificadas e avaliadas
• Avaliadas sob o ponto de vista de risco • Documentadas
• Planejadas
• Comunicadas aos grupos e indivíduos envolvidos
•
Acompanhadas até a finalizaçãoO ponto de vista do CMM é compartilhado por vários autores. Fundamental para garantir que o escopo do sistema é a manutençao de um processo de mudanças controlado. Um processo bem definido fornece aos interessados (clientes e desenvolvedores) um mecanismo formal de solicitação de mudanças nos requisitos de software. Este processo vai facilitar processos de tomada de decisão, gerência e controle de custos. O processo de controle de mudanças permite com que todas as mudanças sejam rastreadas e garante que nenhuma solicitação seja perdida ou deixada de lado.
Este processo não deve ser encarado como obstáculo mas sim como um filtro que vai permitir uma gerência mais eficaz e transparente. É fundamental que este processo seja bem documentado e que faça uso de templates para solicitação de mudanças. Os templates garantem consistência e uniformidade nas solicitações, facilitam a manipulação e o armazenamento das informações em um formato único e compartilhado. A figura 1.2 ilustra um exemplo de template de solicitação de mudança.
Templates para o registro de mudanças em requisitos devem conter,
minimamente, informações relativas ao tipo de mudanças, à pessoa responsável pela solicitação, data e órgão de origem, e uma boa descrição da mudança em si. Idealmente também pode conter informações relativas à prioridade da mudança, em relação às diretivas do projeto e um cronograma que estabeleça a data desejada em que a mudança deveria ser implementada.
Não-Funcional
Figura 1.2 - Exemplo de Registro de Solicitação de Mudança
Para o gerente de requisitos o mais importante é estabelecer uma prática consistente para a mudança dos requisitos. Para tal é necessário estabelecer um processo de tratamento de mudanças. Este processo, que deve ser acordado com os membros da equipe de desenvolvimento e usuários, deve ser descrito de modo a deixar claro:
• Entradas - quais condições devem ser satisfeitas antes de se dar partida ao processo
• Tarefas - detalhar quais são as tarefas envolvidas neste processo, deixando claro quem será responsável pela sua execução e o formato em que os resultados devem ser comunicados
• Verificação - definir etapas onde os resultados obtidos são verificados de modo a garantir consistência e qualidade
• Saídas - definir um critério claro que indique que o processo chegou ao fim. Na figura 1.3 apresentamos um exemplo de processo de mudança de requisitos, proposto por Karl Wiegers.
Figura 1.3 - Processo de requisição de mudança em requisito, proposto por Wiegers.
Profa. Tania N B Arruda – Engenharia de Software 7 Fonte: Gerência de Requisitos - Miriam Sayão e
