Gestão da Configuração do Software

Apresentação em tema: "Gestão da Configuração do Software"— Transcrição da apresentação:

1 Gestão da Configuração do Software
Aula 17

2 Sumário Introdução Conceitos Processo de GCS Tarefas de GCS O quê é?
Quem faz? Porquê é importante? Qual é o produto? Como saber se está bem feita? Conceitos ECS e Linhas Base Objectos da Configuração Processo de GCS Tarefas de GCS Controlo de versões Auditorias de configuração Geração de relatórios

3 Introdução (I) O quê é? Quem faz? Porquê é importante?
Conjunto de actividades para controlar as mudanças surgidas nos diversos produtos do processo de desenvolvimento de software Quem faz? Todos os envolvidos no processo de desenvolvimento Porquê é importante? Se não controlarmos as mudanças, elas que irão nos controlar…

4 Introdução (II) Qual o produto? Quando está bem feito?
Plano de Gestão da Configuração Quando está bem feito? Quando qualquer mudança puder ser monitorizada e analisada

5 Configuração de software
conceito: nome colectivo dado à informação derivada do processo de engenharia de software ECS - Elementos da Configuração de Software Programas (fonte e executáveis) Documentos que descrevem os programas (técnicos e de utilizador) Dados (dentro e fora do programa) o número de ECS cresce à medida que avança o processo de desenvolvimento o problema é que durante o processo ocorrem muitas mudanças em qualquer momento e por muitas causas

6 Origem das mudanças Mudança nos requisitos devido a:
Novos negócios ou condições comerciais Novas necessidades do cliente Reorganização do negócio Restrições de planeamento

7 Linhas Base Quando todas as partes de um ECS forem revistas, corrigidas e aprovadas o ECS converte-se numa linha base Assim, um ECS (especificação ou produto) revisto e aprovado serve como base para o desenvolvimento posterior e só poderá ser modificado através de procedimentos formais de controlo das mudanças É o ponto de referência no desenvolvimento de software que fica marcado pelo envio e aprovação de um ou mais ECS em revisões técnicas formais Por exemplo, os elementos de uma especificação de desenho se documentam e revisam. Se encontram erros e se corrigem. Quando todas as partes da especificação tem sido revistas, corrigido e aprovado, a especificação de desenho converte-se numa linha base. Só poder-se-ão fazer câmbios na arquitectura do software (documentado na especificação de desenho) depois de terem sido avaliados e aprovados. Somente poder-se-ão fazer mudanças nos ECS depois que estas tenham sido avaliadas e aprovadas.

8 ECS da Linhas Base Base de dados do projecto aprovada modificada
Tarefas de Engenharia de software Revisões técnicas formais armazenada Embora podem-se definir linhas a qualquer nível de detalhe, as linhas base mais comuns são as que aparecem na figura. A sequências de factos que conduzem a uma linha base também é ilustrada. As tarefas de engenharia do software produzem um ou mais ECS. Uma vez que um ECS tem sido revisto e aprovado, coloca-se numa base de dados do projecto.Quando um membro da equipa quer fazer modificações num ECS de linha base, copia-se da base de dados do projecto a um área de trabalho privada. No entanto, este elemento só poder-se-a modificar seguindo os controles de gestão da configuração. As linhas mostram o percurso da modificação de uma linha base ECS. Linhas base: Especificação do sistema Requisitos do software Especificações de desenho Código fonte Planos/Procedimentos Dados de teste Sistema de funcionamento Controlos GCS extraída

9 Objectos da configuração
Modelo de dados Especificação de desenho Desenho de dados Desenho arquitectónico Desenho de módulos Desenho de interfaces Componente N Componente N Descrição da interface Descrição do algoritmo Descrição da interface Descrição do algoritmo Já definimos um elemento de configuração de software como a informação criada como parte do processo de engenharia de software. Levado a o extremo, pode-se considerar um ECS como uma secção de individual de uma especificação ou cada caso de teste de um conjunto maior de casos de teste. De forma mais realista, um ECS é um documento, um conjunto completo de dados de teste ou um componente de um programa dado. Na realidade, os ECS organizam-se como objectos de configuração que devem ser catalogados, na base de dados do projecto com um nome único. Um objecto de configuração tem um nome e uns atributos e está ligado a outros objectos mediante associações. Segundo a figura, os objectos de configuração, Especificação de desenho, modelo de dados, componente N, código fonte e Especificação de teste, são definidos separadamente. No entanto, cada objecto está interligado com outros como mostram as setas. Uma seta curva representa uma relação de composição e uma seta recta, de dependência. Especificação de teste Plano de testes Procedimento de testes Casos de teste Código fonte

10 Processo de GCS - questões fundamentais
Como identificar e gerir as diferentes versões existentes de um programa e a sua documentação de forma a introduzir mudanças eficientemente? Como controlar as mudanças antes e depois da entrega do produto ao cliente? Quem tem a responsabilidade de aprovar e atribuir prioridades às mudanças? Como garantir a apropriada realização das mudanças? Quais os mecanismos para avisar aos outros das mudanças?

11 Tarefas da GCS - devem ser adicionadas ao Plano de Gantt…
Identificação dos objectos da configuração Básicos uma secção de uma especificação de requisitos, um código fonte de um módulo, um conjunto de casos teste usados para exercitar o código, etc Compostos Especificação de Desenho, Especificação de Testes.. Controlo de versões Auditorias de configuração Geração de relatórios Identificação: podem-se identificar 2 tipos de objectos; objectos básicos e compostos. Um objecto básico é uma unidade de texto criado por um engenheiro de software durante a análise, desenho, codificação e teste. Por exemplo, um objecto básico poderá ser uma secção de uma especificação de requisitos, um listado fonte de um módulo o um conjunto de casos teste usados para exercitar o código.Um objecto composto é uma colecção de objectos básicos e de outros objecto compostos. Na figura anterior, a especificação de desenho é um objecto composto. Cada objecto terá um conjunto de características únicas que o identificam; um nome uma descrição uma lista de recursos e uma realização. Existem várias ferramentas automáticas para ajudar na tarefa de identificação e outras da GCS.

12 Controlo de versões 1.0 1.1 1.2 1.3 1.4 2.0 2.1 1.1.1 1.1.2 Cada nó é um objecto composto: uma versão completa do software Cada versão do software é uma colecção de ECS Cada versão pode estar composta de variantes (cor, monocromático) No gráfico mostra-se uma representação das diferentes versões de um sistema. Cada nó é um objecto composto i.e. Uma versão completa do software. Cada versão do software é uma colecção de ECS e cada versão pode estar composta de variantes Um exemplo: programa com 5 componentes. O componente 4 só se implementa para monitores de cor, o 5 para monitores monocromáticos. Portanto, podemos definir 2 variantes 1,2,3,4 (cor) e 1,2,3,5 (mono). Para construir a variante adequada, atribuem-se atributos a cada componente que definem a qual variante corresponde (ex.cor) O controlo de versões combina procedimentos e ferramentas para gerir as versões dos objectos da configuração criados durante o processo de software

13 Controlo das mudanças SIM NÂO
Reconhece-se a necessidade da mudança O utilizador subscreve o pedido O eng de software a avalia Gera-se um informe de mudanças ACM (Autoridade de Controlo de Mudanças) decide Gera-se a OME (Ordem de Mudança de Engenharia) Atribuição personalizada dos objectos da configuração Dar “baixa” aos objectos da configuração Realização e revisão da mudança Dar “alta” aos objectos mudados Estabelecimento de nova linha base para teste Realização de actividades de garantia da qualidade Inclusão das mudanças na próxima versão Distribuição da nova versão SIM Faz-se o pedido de mudança e avalia-se para calcular o esforço técnico, os possíveis efeitos secundários, o impacto global sobre outras funções do sistema e sobre outros objectos da configuração. Os resultados da avaliação se apresentam como um informe de mudanças à Autoridade de Controlo de Mudanças (ACM). Para cada mudança aprovada gera-se uma Ordem de Mudança de Engenharia (OME) A OME descreve a mudança a realizar, as restrições a respeitar e os critérios de revisão e de auditoria. O elemento a modificar dado “baixa” da base de dados do projecto, realiza-se a mudança e aplicam-se as medidas apropriadas de garantia da qualidade. Depois é dado “alta” ao elemento na base de dados e usam-se os mecanismos de controlo de versões apropriados para aprovar a próxima versão do software. NÂO Pedido de mudança é negado Informa-se ao utilizador

14 Controlo de acesso e sincronização - feito automaticamente, e sem bloqueio, em ferramentas de CVS (Concurrent Versions Systems) alta baixa Controlo De acesso Base de dados do projecto Engenheiro de software Elemento de Configuração modificado Informação de auditoria (linha base) de pertinência extraído desbloqueio bloqueio Os processos de alta e baixa implementam 2 elementos importantes no controlo de modificações; controlo de acesso e de sincronização. O controlo de acesso governa os direitos de acesso dos engenheiros de software a aceder e modificar elementos de configuração concretos. O controlo de sincronização assegura que as mudanças em paralelo, realizadas por pessoas diferentes, não se sobre-escrevam mutuamente.

15 Auditoria da Configuração - como podemos saber se as mudanças foram feitas correctamente?
Revisões técnicas formais Correcção técnica do ECS Auditorias de configuração Foi realizado a mudança especificada pela OME? Houve modificações extras? Foi feita uma revisão técnica formal? Foi seguido o processo de software? Aplicaram-se os standards? Tem-se destacado as mudanças no ECS? Especificou-se o autor e a data da modificação? Seguiram-se os procedimentos de GCS para assinalar, registar e divulgar a mudança efectuada? Têm sido actualizados os ECS relacionados? A identificação, o controlo de versões e o controlo de câmbios ajudam a manter uma ordem. No entanto, até os mecanismos mais correctos de controlo de câmbios seguem os câmbios até a geração da OCI. Como podemos então saber se o câmbio foi implementado correctamente? A resposta está nas Revisões técnicas formais Auditorias de configuração do software As revisões técnicas focam a correcção técnica do elemento da configuração modificado A auditoria complementa a revisão técnica formal ao comprovar que geralmente não consideradas na revisão. A auditoria plantea e responde as perguntas da figura.

16 Relatórios de estado - normalmente preenchidos em ferramentas CASE
O quê se passou? Quem o fez? Quando se passou? Quem foi afectado?

17 Fim