gestão de configurações num processo de desenvolvimento de ... · níveis de qualidade, foram...

Faculdade de Engenharia da Universidade do Porto

Mestrado Integrado em Engenharia Informática e Computação

Gestão de Configurações num Processo de Desenvolvimento de Software – Análise de uma Situação Real

Relatório de Projecto do MIEIC 2007/2008

Joana Vasconcelos de Castro Gonçalves

Orientador na FEUP: Prof. Raul Moreira Vidal

Responsável pelo acompanhamento na Critical Software: Engª. Carla Nogueira

Fevereiro de 2008

ii

Abstract

The quality of the software development process is essential to guarantee the quality of the product. In the software development industry, the experience made clear that there is a need to standardize the activities of development and its control.

The configuration management of software is a formal software engineering discipline that provides the methods and tools to identify and control the software throughout its development and use.

Rapid environmental changes, accelerated growth and the requirement of surpassing the high levels of quality, were some of the factors that created the necessity of evaluation of possible operational improvements to the configuration management process and to the associated processes.

This project’s scope is to analyse the processes, the activities that constitute it, and to design a solution that aims to improve its performance. This solution allows operational improvements in time, in effort and visibility to the configuration management, delivery management and review management.

The developed tool in this project, the Configuration Management Office, is a project oriented, web-based tool that supports the activities that were identified as capable of being improved. The main advantages of the tool are the automation, the centralization, the assurance that the information is always updated, the reduction of some steps and an easy to use wizard like approach.

iii

Resumo

A qualidade do processo de desenvolvimento de software é essencial para garantir a qualidade do produto. No desenvolvimento de software, a experiência tornou claro que há uma necessidade de padronizar as actividades de desenvolvimento e o seu controlo.

A gestão de configurações de software é uma disciplina da engenharia de software, que compreende ferramentas e técnicas para gerir a alteração aos recursos de software.

Mudanças rápidas no ambiente, crescimento acelerado, e a exigência em superar os altos níveis de qualidade, foram alguns dos factores que despoletaram a necessidade de avaliação de possíveis melhorias operacionais no processo de gestão de configurações e nos processos associados.

Este projecto centra-se na análise dos processos, nas actividades em que estes se traduzem, e no desenho de uma solução que vise melhorar o seu desempenho. Esta solução, permite melhorias operacionais, tanto em termos de tempo, como de esforço e de visibilidade relativamente à gestão de configurações, gestão de entregas e gestão de revisões.

A ferramenta desenvolvida no âmbito do projecto, o Configuration Management Office, é, uma ferramenta web-based, orientada ao projecto, que dá suporte às actividades identificadas como passíveis de melhoria. As principais vantagens são a automatização, a garantia de que a informação se encontra sempre actualizada, a eliminação de alguns passos no processo e o acompanhamento das acções ao utilizador.

iv

Agradecimentos

A todas as pessoas da Critical Software que estiveram directamente envolvidas no meu trabalho.

À Carla, por todo o apoio e ajuda.

À Braselina pela disponibilidade para ajudar e por toda a paciência, e a todo o departamento de Qualidade pela forma como me acolheram na equipa.

Ao meu orientador da FEUP, Professor Raul Vidal, pelo papel chave que desempenhou durante o projecto, pelas linhas de orientação e pelos seus conselhos.

À minha familia, ao Álvaro e aos meus amigos pela paciência e dedicação.

v

Índice de Conteúdos

1 Introdução ........................................................................................................................................... 1 1.1 Engenharia de Qualidade de Software................................................................................................. 1 1.2 Processos de Software ........................................................................................................................ 1 1.3 Gestão do Projecto .............................................................................................................................. 3 1.4 Qualidade ............................................................................................................................................. 4 1.4.1 Gestão da Qualidade ........................................................................................................................... 5 1.4.2 Abordagem por processos ................................................................................................................... 6 1.4.3 Métricas ................................................................................................................................................ 6 1.4.4 Modelos de referência .......................................................................................................................... 8 1.4.4.1 Gestão de Configurações nos modelos de referência ................................................................. 8 1.5 Definições e acrónimos ........................................................................................................................ 9 1.6 Organização e Temas Abordados no Presente Relatório .................................................................... 9

2 Gestão de Configurações ................................................................................................................. 11 2.1 O processo ......................................................................................................................................... 11 2.2 Conceitos do processo ....................................................................................................................... 12 2.2.1 Item de Configuração (CI) .................................................................................................................. 12 2.2.2 Work product ...................................................................................................................................... 12 2.2.3 Baseline ............................................................................................................................................. 12 2.2.4 Versão ................................................................................................................................................ 13 2.2.5 Release .............................................................................................................................................. 13 2.2.6 Revisão .............................................................................................................................................. 13 2.2.7 Auditoria ............................................................................................................................................. 13 2.2.8 Build ................................................................................................................................................... 13 2.2.9 TAG ................................................................................................................................................... 13

3 Configuration Management (CM) na Critical Software,S.A............................................................... 14 3.1 Actividades do processo .................................................................................................................... 14 3.1.1 Actividade A1 – definir o plano de CM ............................................................................................... 15 3.1.2 Actividade A2 – identificar CIs ............................................................................................................ 15 3.1.3 Actividade A3 – gestão de versões .................................................................................................... 16 3.1.4 Actividade A4 – gestão de alterações ................................................................................................ 16 3.1.5 Actividade A5 – estabelecer baselines ............................................................................................... 16 3.1.6 Actividade A6 – build .......................................................................................................................... 17 3.1.7 Actividade A7 – release ...................................................................................................................... 17 3.1.8 Actividade A8 – relatório de estado .................................................................................................... 17 3.1.9 Actividade A9 – auditorias de CM ...................................................................................................... 18 3.2 Processos associados ........................................................................................................................ 18 3.2.1 Project Incident Management ............................................................................................................. 18 3.2.2 Delivery .............................................................................................................................................. 19 3.2.3 Verification ......................................................................................................................................... 19 3.3 Entradas e saídas do processo de CM .............................................................................................. 20 3.3.1 Ferramentas utilizadas ....................................................................................................................... 20 3.3.1.1 WISE – Intradoc ......................................................................................................................... 20 3.3.1.2 Work Orders Web (WOW) ......................................................................................................... 20

vi

3.3.1.3 CVS ........................................................................................................................................... 20 3.4 Implementação das actividades de CM e processos associados ...................................................... 22 3.4.1 Actividade A2 de CM .......................................................................................................................... 22 3.4.2 Actividade A9 de CM .......................................................................................................................... 23 3.4.3 Processos associados ........................................................................................................................ 24 3.4.3.1 Verification ................................................................................................................................. 24 3.4.3.2 Delivery ...................................................................................................................................... 25 3.5 O que pode ser melhorado? ............................................................................................................... 26

4 O CMO – Configuration Management Office .................................................................................... 28 4.1 Introdução .......................................................................................................................................... 28 4.2 Especificação da solução proposta .................................................................................................... 28 4.2.1 Itens de Configuração ........................................................................................................................ 29 4.2.2 CVS ................................................................................................................................................... 30 4.2.3 CVS Audit ........................................................................................................................................... 30 4.2.4 Revisões ............................................................................................................................................ 30 4.2.5 Releases ............................................................................................................................................ 31 4.3 Práticas de Gestão de Configurações depois do CMO ...................................................................... 31 4.3.1.1 Actividade A2 de CM no módulo de Itens de Configuração ....................................................... 32 4.3.1.2 Actividade A9 de CM no módulo de CVS Audit ......................................................................... 33 4.3.1.3 Módulo de CVS .......................................................................................................................... 34 4.3.1.4 Módulo de Revisões .................................................................................................................. 35 4.3.1.5 Módulo de Releases .................................................................................................................. 36 4.4 Visão integrada .................................................................................................................................. 38

5 Reflexão crítica .................................................................................................................................. 40 5.1 Conclusões ........................................................................................................................................ 40 5.2 Perspectivas de trabalho futuro .......................................................................................................... 42

Glossário ................................................................................................................................................ 44

Referências e Bibliografia ...................................................................................................................... 46

ANEXO A: Apresentação da instituição de projecto, Critical Software, S.A. ................................. 48

vii

Índice de Figuras

Figura 1 – modelo em cascata .................................................................................................... 2

Figura 2 – modelo evolutivo ....................................................................................................... 2

Figura 3 – modelo baseado em componentes ............................................................................. 3

Figura 4 – triângulo da gestão do projecto ................................................................................. 4

Figura 5 – atributos de qualidade ............................................................................................... 5

Figura 6 – abordagem por processos .......................................................................................... 6

Figura 7 – níveis de objectivos ................................................................................................... 7

Figura 8 – organização do relatório .......................................................................................... 10

Figura 9 – actividade de CM durante o ciclo de vida do projecto na CSW ............................. 14

Figura 10 – entradas e saídas do processo de CM na CSW ..................................................... 20

Figura 11 – operações no CVS ................................................................................................. 21

Figura 12 – (replicação da Figura 10) entradas e saídas do processo ....................................... 22

Figura 13 – actividade de identificação de CIs......................................................................... 23

Figura 14 – actividade de auditoria de CM .............................................................................. 24

Figura 15 – fases da revisão ..................................................................................................... 25

Figura 16 – fases da release ..................................................................................................... 26

Figura 17 – (replicação da Figura 13) actividade de identificação de CIs antes do CMO ....... 30

Figura 18 – (replicação da Figura 13) actividade de identificação de CIs antes do CMO ....... 32

Figura 19 – actividade de identificação de CIs depois do CMO .............................................. 33

Figura 20 – actividade de auditoria de CM depois do CMO .................................................... 34

Figura 21 – operações no CVS depois do CMO ...................................................................... 35

Figura 22 – revisões no CMO .................................................................................................. 36

Figura 23 – release no CMO .................................................................................................... 37

Figura 24 – gestão integrada ..................................................................................................... 38

viii

Índice de Tabelas

Tabela 1 – Tabela de Acrónimos ................................................................................................ 9

Tabela 2 – dados de operações no CVS ................................................................................... 21

Tabela 3 – dados relativos a 1 item de configuração ................................................................ 23

Tabela 4 – dados relativos a uma auditoria de CM .................................................................. 24

Tabela 5 – dados relativos a uma revisão ................................................................................. 25

Tabela 6 – dados relativos a uma release (15 CIs) ................................................................... 26

Tabela 7 – informação disponibilizada na tabela de CIs internos ............................................ 29

Tabela 8 – informação disponibilizada na tabela de CIs externos ........................................... 29

Tabela 9 – métricas do procedimento de revisões .................................................................... 31

Tabela 10 – resumo das diferenças no módulo de CI ............................................................... 33

Tabela 11 – resumo das diferenças em CVS Audit .................................................................. 34

Tabela 12 – resumo das diferenças no módulo de CVS ........................................................... 35

Tabela 13 – resumo das diferenças no módulo de revisões ...................................................... 36

Tabela 14 – resumo das diferenças no módulo de releases ...................................................... 38

Tabela 15 – melhoria no módulo de CI .................................................................................... 40

Tabela 16 – melhoria no módulo de release ............................................................................ 41

Tabela 17 – melhoria no módulo de revisões ........................................................................... 41

Tabela 18 – melhoria no módulo de CVS ................................................................................ 41

Tabela 19 – melhoria no módulo de CVS Audit ...................................................................... 41

Tabela 20 – melhoria no CMO ................................................................................................. 42

Tabela 21 – sugestão de melhoria de interacção com o CVS ................................................... 43

Gestão de Configurações num Processo de Desenvolvimento de Software

Análise de uma Situação Real

1

1 Introdução

1.1 Engenharia de Qualidade de Software

Na indústria de desenvolvimento de software a experiência tornou claro que uma aproximação não estruturada dispara o custo e o tempo de um projecto. Entre 1960 e 1980 houve uma crise no desenvolvimento de software; muitos projectos excederam largamente o orçamento e o tempo previstos, sendo que outros projectos causaram danos em propriedades e vidas humanas. Assim, desenvolveu-se a tomada de consciência de que num mundo tecnológico, o risco associado a um projecto pode ter impactos incontroláveis, alertando para a necessidade de padronizar as actividades de desenvolvimento e o seu controlo. O desenvolvimento de software exige, nos dias de hoje, um esforço acrescido para garantir que até os imprevistos estão sob controlo.

Deste modo, surge uma nova disciplina, a engenharia de qualidade de software, que permite a avaliação, controlo e melhoria da qualidade de software. A qualidade de software é muitas vezes associada à fiabilidade do produto, em contraste com os seus requisitos funcionais, desempenho e requisitos de interface que são mais um resultado da engenharia de software (em todas as suas fases de desenvolvimento). [1]

A engenharia de qualidade actua complementarmente à engenharia de software, e têm ambas o objectivo comum de garantir um produto com qualidade.

1.2 Processos de Software

Um processo de software é um conjunto de actividades que levam à produção de um produto de software. Os processos de software descrevem as diversas actividades que são necessárias levar a cabo para conduzir de uma forma eficaz, controlada e previsível o desenvolvimento adequado do produto. Estes processos são normalmente complexos, uma vez que não há dois projectos iguais e é extremamente complicado garantir que os processos se moldam aos projectos e às suas próprias necessidades específicas. A maioria das empresas adopta uma abordagem consoante o tipo de projecto, mas, no entanto, ainda se verificam algumas inconsistências quando os projectos fogem aos padrões usuais.

Os padrões mais usuais de desenvolvimento de software englobam 3 tipos: modelo em cascata (Figura 1), modelo evolutivo (Figura 2) e modelo baseado em componentes (Figura 3).



Figura 1 – modelo em cascata

Uma das maiores dificuldades do modelo em cascata é não possibilitar alterações, após o início de um processo, visto que uma fase tem de estar terminada, para se passar à fase seguinte. Este modelo é, apenas, apropriado, quando os requisitos estão bem definidos, e há poucas possibilidades de se modificarem ao longo do desenvolvimento.

Figura 2 – modelo evolutivo

Este modelo representa um trabalho contínuo com o cliente de forma a estipular os requisitos, e fazer evoluir o sistema, adicionando-lhe funcionalidades.

Este método tem alguns problemas quanto à falta de previsibilidade de um processo. No entanto, caracteriza-se por apresentar uma grande aplicabilidade em pequenos projectos interactivos, em subsistemas de grandes projectos, ou em sistemas de curto tempo de vida.

2



Figura 3 – modelo baseado em componentes

O modelo baseado em componentes deriva de um uso sistemático de sistemas integrados em soluções chave na mão. A maior diferença para os modelos anteriores é que há uma alteração dos requisitos para incorporar a reutilização de componentes já desenvolvidos.

Apesar dos vários modelos existentes, as actividades fundamentais que são comuns a todos os processos são:

1) Especificação de software – definição das funcionalidades e restrições do software;

2) Desenho e implementação – produção do software de acordo com a especificação;

3) Validação – comprovar que o software faz o que cliente quer;

4) Evolução – o software sofre alterações para ir de encontro à necessidade do cliente.

Estas fases existem em todos os tipos de projecto, embora em alguns tipos não se distingam temporalmente.

1.3 Gestão do Projecto

A gestão de um projecto de software é diferente da gestão de um projecto em outras áreas de engenharia. Uma das diferenças é que o progresso é difícil de quantificar. As linhas de código podiam ser, à partida, uma boa quantificação, mas não o são, dado que o tamanho final é desconhecido, e, muitas vezes, a quantidade de linhas de código não significa qualidade. Outra diferença é que o processo de engenharia de software não é padronizado, e cabe ao gestor do projecto escolher a melhor abordagem. Devido à rápida evolução tecnológica, é normal que a experiência de gestão de um projecto não seja transferida para outra e isto é mais frequente acontecer na área de desenvolvimento de software do que em outras áreas de engenharia. [2]

A gestão de um projecto é uma actividade de organização e gestão de recursos e o gestor precisa do máximo de informações acerca do projecto, para ser capaz de tomar decisões. Uma boa fonte de informação está na documentação produzida nos projectos e no contacto directo com a equipa de projecto. No entanto, estas fontes não são suficientes e o gestor necessita de indicadores em tempo real, que lhe garantam que o caminho que o projecto está a seguir é o correcto.

A gestão do projecto tende a debruçar-se, tentando o equilíbrio entre 3 restrições; o âmbito, o tempo e o custo. Estas restrições são muitas vezes referenciadas como o triângulo de ferro da gestão do projecto, onde cada lado representa uma restrição (ver Figura 4).

3



Figura 4 – triângulo da gestão do projecto

4

opção. Este triângulo de ferro tende a não dar uma perspectiva

Na gestão de projectos de software, normalmente a qualidade aparece como sendo parte .

ser alterado. As

• Portabilidade – capacidade que um produto de software tem de ser transferido de um ambiente para outro.

A alteração de um dos lados afecta, obrigatoriamente, uma alteração nos outros lados. Estas 3 restrições juntas deram origem à frase On time, On spec, On budget.

Esta abordagem da gestão de projectos é, muitas vezes, rígida de mais no desenvolvimento de software, porque ela representa uma tendência em sacrificar a qualidade, quando o âmbito, o tempo e o custo não são uma muito clara do que é a gestão de projectos de software, onde a qualidade de um produto de software não é questionável.

integrante do âmbito

1.4 Qualidade

O grande problema da qualidade começa na sua própria definição. Não existe uma definição consensual. A qualidade é uma propriedade exigida mas muito dificilmente quantificável.

A norma ISO 9126 [3] define os atributos de qualidade de software através das suas características de:

• Funcionalidade – capacidade que um produto de software tem de providenciar funções para as quais foi pensado;

• Fiabilidade – capacidade de manter um nível específico de desempenho quando usado em condições especificas;

• Usabilidade – capacidade do produto ser compreendido, aprendido, utilizado e atractivo para o utilizador, quando utilizado em condições específicas;

• Eficiência – capacidade de fornecer o desempenho adequado relativamente à quantidade de recursos utilizados

• Sustentabilidade – capacidade que um produto de software tem demodificações podem incluir correcções, melhorias ou adaptação do software a mudanças de ambiente, de requisitos ou de especificações técnicas.



Figura 5 – atributos de qualidade

Estas características, e as sub-características em que se dividem, como se pode ver na Figura 5, caracterizam a qualidade de um produto de software e tornam a avaliação de qualidade mais facilmente quantificável.

Apesar desta definição formal e bastante detalhada, há uma tendência natural para associar a qualidade à ausência de defeitos, ou seja, a concentrar numa das suas características, a funcionalidade.

1.4.1 Gestão da Qualidade

A qualidade de um produto de software é influenciada pela qualidade do processo de desenvolvimento. Para que os atributos de qualidade de um produto sejam atingidos, é necessária a gestão de qualidade, e esta preocupa-se com a definição dos processos de desenvolvimento, pela garantia que eles são correctamente aplicados e seguidos. Estes procedimentos aplicados encapsulam boas práticas (reconhecidas e experimentadas) e, seguindo estas boas práticas, seguramente se estará no caminho da qualidade.

A gestão da qualidade não se preocupa, somente com procedimentos, mas também em transmitir, às pessoas, uma cultura de qualidade, onde toda a gente responsável pelo desenvolvimento de software esteja empenhada em atingir altos padrões de qualidade. Deste modo, as equipas são encorajadas a tomar responsabilidade pela qualidade do seu trabalho e em desenvolver novas abordagens para a melhoria da própria qualidade.

A garantia de qualidade é o processo de definir como a qualidade do software pode ser alcançada e de como a organização sabe que um produto tem o nível de qualidade pretendido. Os procedimentos podem ser aplicados a produtos ou processos de software. A razão pela qual os procedimentos são importantes, é por garantirem práticas que estão de acordo com o ambiente em que se enquadram e, consequentemente, os erros comuns são evitados. Os procedimentos também facilitam a continuidade, ao tornarem simples a integração de novos elementos num projecto ou numa organização.

5



1.4.2 Abordagem por processos

A norma ISO 9001:2000 [4] aponta para a adopção da abordagem por processos, na gestão da qualidade.

A maioria das organizações identifica e gere inúmeros processos interligados e detalha a abordagem por processos, pois é importante identificar as subdivisões de cada processo.

A aplicação de um sistema de processos numa organização, juntamente com a identificação e interacção dos mesmos e da sua gestão é que caracteriza a abordagem por processos.

Uma vantagem da abordagem por processos é o controlo contínuo, que garante uma ligação entre o processo individual e o sistema de processos, bem como da sua combinação e interacção.

Quando usada num sistema de gestão de qualidade, esta abordagem enfatiza a importância de entender e atingir os requisitos, a necessidade de considerar os processos, em termos de valor acrescentado, obter resultados de desempenho do processo e melhorar continuamente os processos baseados em medições objectivas [4] (ver Figura 6).

Figura 6 – abordagem por processos

Qualquer organização é um conjunto de processos, institucionalizados em actividades. Monitorizar e registar estas actividades é a chave para o sucesso de qualquer organização.

1.4.3 Métricas

A capacidade de poder fazer previsões e de se poder comprometer, relativamente aos produtos que produz, é uma grande vantagem competitiva.

6



Uma medição efectiva dos processos ajuda ao sucesso, permitindo entender as suas capacidades, de modo a possibilitar um planeamento eficaz para desenvolver e entregar produtos e serviços. A medição também dá a possibilidade de antecipar problemas, providenciando melhor controlo de custos, reduzindo o risco, melhorando a qualidade e garantindo que os objectivos sejam alcançados [5].

Existe uma relação entre os objectivos e indicadores, nos diferentes níveis de uma organização. Isto é, um objectivo de topo ao nível organizacional, tem de ter rastreabilidade para objectivos a níveis mais baixos na hierarquia, assim como, objectivos definidos na organização devem contribuir para os objectivos do nível de topo, caso contrário não faz sentido ter esse objectivo. Deverá ser possível também medir a ligação destes aos processos e o seu desempenho. Em linguagem mais simples, um objectivo de topo de uma organização deve obter contribuições de objectivos de níveis inferiores, das diferentes áreas em que a organização se decompõe e reflectir-se no desempenho dos seus processos, como se pode ver na Figura 7.

Figura 7 – níveis de objectivos

A necessidade de ter uma visibilidade do desempenho dos seus processos obriga à criação de métricas, que são valores recolhidos acerca de um determinado parâmetro, associados a indicadores e objectivos. Esta monitorização tem por objectivo dar uma visão quantitativa da organização.

7



8

ation (ISO) a maior organização de desenvolvimento e publicação de normas e o

ca-se a

melhoria dos processos, o Capability Maturity Model Integration (CMMI). O

obrem o ciclo de vida do produto, desde a concepção, até à entrega e

ão. Eles são classificados

erizados por projectos,

tinuamente, os seus processos.

O CMMI avalia a maturidade de áreas organizacionais específicas de uma empresa. a implementa todas as áreas de

, está descrito no ponto 4.2.4 da norma ISO 9001.

1.4.4 Modelos de referência

Há numerosas normas e modelos de processos que se aplicam à indústria do desenvolvimento de software, no que diz respeito à qualidade, sendo a International Organization for StandardizInstitute of Electrical and Electronics Engineers (IEEE) responsável pela publicação de vários referenciais normativos, no âmbito do desenvolvimento de software e da qualidade do software.

As normas da família ISO 9000 são referenciais para a implementação de sistemas de gestão da qualidade (SGQ) que representam um consenso internacional sobre boas práticas de gestão, e com o objectivo de garantir o fornecimento de produtos que satisfaçam os requisitos dos clientes ou estatutários e/ou regulamentares, bem como a prevenção dos problemas e a ênfase na melhoria contínua. A norma ISO 9001 é a mais genérica destas normas e apliorganizações preocupadas com o processo de qualidade que desenham, desenvolvem e garantem a manutenção de produtos. Na área de desenvolvimento de software surge a norma ISO 9000-3, que é uma interpretação da norma ISO 9001 direccionada para esta área.

O Software Engineering Institute (SEI) [6], desenvolveu, recentemente, um modelo de maturidade demodelo encapsula as melhores práticas relativas ao desenvolvimento e actividades de manutenção, que cmanutenção.

O CMMI estabelece vários níveis de maturidade de uma organizaçda seguinte forma:

• Nível 1. Inicial – a empresa possui processos ad hoc e caóticos. Neste ponto, ela ainda não possui nenhuma das áreas de processo implementadas;

• Nível 2. Gerido – a empresa possui processos geridos e caractmas, muitas vezes, ainda trabalha de forma reactiva;

• Nível 3. Definido – a empresa possui processos definidos e caracterizados para a organização, normalmente a empresa trabalha de forma activa;

• Nível 4. Gerido Quantitativamente – a empresa mede e controla os seus processos;

• Nível 5. Optimizado – a empresa tem o foco em descobrir a causa de seus problemas, e melhorar, con

Posicionar-se num certo nível de maturidade significa que elprocesso desse nível.

1.4.4.1 Gestão de Configurações nos modelos de referência

Nos vários modelos de referência, um dos processos destacados é o da gestão de configurações (configuration management - CM). O processo de gestão de configurações, detalhado no próximo capítulo



9

gestão de

o que o plano de gestão de configurações deve ter. Como a maioria das normas, esta fornece linhas de orientação a serem seguidas e o que deve constar no plano de

es quanto à implementação de actividades de CM.

O CMMI engloba a gestão d rte, sendo uma das suas 22 áreas de processo. A gestão dede matu

1.5 Definições e acrónimo

crónimos

As ISO/IEC 12207 e a IEEE/EIA 12207.0 são o resultado de um projecto conjunto entre o IEEE e a ISO sobre ciclo de vida dos processos de software, e abordam aconfigurações no ponto 6.2.

A norma IEEE 828-1998 é dedicada, única e exclusivamente, a este processo, definindo o conteúdo mínim

CM, mas não fornece indicaçõ

e configurações nas áreas de supo configurações encontra-se presente a partir do segundo nível

ridade.

s

Tabela 1 – Tabela de A

Acrónimos Descrição CI Configuration Item – Item de Configuração

CIL Configuration Item List – Lista de iIens de configuração

CM n Management – Gestão de Configurações Configuratio

CMMI Capability Maturity Model Integration

CMO Configuration Management Office

CSW Critical Software, S.A.

CVS Concurrent Versions System – Repositório de Controlo de Versões

DSI Department of Systems and Infra-Structures – Departamento de Sistemas e Infra-Estruturas

GUI Graphical User Interface – interface Gráfica com o Utilizador

IEEE Institute of Electrical and Electronics Engineers

Intra-doc de documentos Ferramenta interna de numeração

ISO International Standards Organization

PM Project Manager – Gestor do Projecto

SEI Software Engineering Institute

SGQ Sistema de Gestão da Qualidade

SQA Software Quality Assurance – responsável pela Garantia de Qualidade de Software

WISE Sistema de Informação da CSW

WOW Work Orders Web – ferramenta interna de gestão de acções

Quaisquer referências a nomes de processos ou actividades da Critical Software não são traduzidos para português.

1.6 Organização e Temas Abordados no Presente Relatório

O capítulo 2 apresenta uma breve introdução à gestão de configurações e introduz alguns

estão de configurações e processos associados, e introdução ao

ctividades

conceitos associados.

O capítulo 3 aborda a análise do problema da gna perspectiva da Critical Software (CSW). Este capítulo inclui uma parte dprocesso, uma descrição do processo na CSW, e a implementação das arelacionadas com o processo.



10

O capítulo 4 relata a solução proposta para melhorar o processo nos pontos estudados no

Figura 8 – organização do relatório

capítulo anterior e as melhorias introduzidas.

O capítulo 5 apresenta algumas conclusões e perspectivas de trabalho futuro.

Na figura seguinte (Figura 8), é esquematizada a abordagem seguida na elaboração deste relatório, a simbologia utilizada volta a aparecer no início de cada secção referida na imagem.



2 Gestão de Configurações

2.1 O processo

O desenvolvimento de software é despoletado por uma necessidade de um utilizador, ou pelo objectivo de conquista de um mercado. Hoje em dia, este negócio exige eficiência e eficácia.

É do conhecimento geral, por quem tem contacto com o desenvolvimento de software, a necessidade de controlo apertado do processo de desenvolvimento. Dessa necessidade reconhecida, surge a definição de gestão de configuração de software.

A gestão de configuração de software é a maneira de controlar a evolução de um produto de software. Esta engloba um conjunto de actividades, com o objectivo de controlar alterações:

• Identificar os produtos mais propícios a sofrerem alterações,

• Estabelecer relações entre eles,

• Definir mecanismos para gerir as diferentes versões,

• Controlar as mudanças impostas,

• Auditar,

• Relatar as alterações efectuadas.

Mais formalmente, a gestão de configuração de software é uma disciplina da engenharia de software, que compreende ferramentas e técnicas (processos ou metodologias), para gerir a alteração aos recursos de software. Segundo a norma IEEE 828-1998 [7], a gestão de configurações de software constitui uma boa prática de engenharia para todos os projectos de software, seja em projectos de desenvolvimento faseado, prototipagem rápida, ou de manutenção. Uma boa gestão de configurações realça a confiança e a qualidade do software:

• Criando uma estrutura para identificar e controlar a documentação, código, interfaces e bases de dados para suportar todas as fases do ciclo de vida;

• Suportando uma metodologia de desenvolvimento/manutenção que envolve requisitos, procedimentos, politicas, organização e gestão;

• Criando informação de gestão e do produto, dizendo respeito ao estado das baselines1, controlo de alterações, testes, entregas, auditorias, etc;

Claramente, o software muda muito facilmente e não só é fácil mudar, como também é praticamente impossível criar barreiras à mudança. Muitas vezes, as únicas barreiras são a imaginação humana. Incontrolável, a imaginação pode causar um pesadelo na gestão do desenvolvimento de software.

Hoje em dia, qualquer equipa de desenvolvimento de software tem conhecimento da necessidade da gestão de configurações para monitorizar e controlar a mudança. No entanto, mesmo com as melhores intenções, há projectos de software que continuam a falhar, devido a

11

1 Definida no ponto 2.2.3



12

problemas que poderiam ter sido evitados com um controlo mais apertado, ou com uma melhor visibilidade dos problemas.

O futuro do software depende de quão bem se gere o seu passado.

2.2 Conceitos do processo

A gestão de configurações traduz-se num conjunto de actividades que foram desenvolvidas para gerir a alteração e garantir o controlo durante o ciclo de vida do software. Para clarificar o processo, torna-se necessário introduzir alguns conceitos usados, frequentemente, na gestão de configurações.

A terminologia nem sempre é consistente na literatura, os termos podem ter diferentes definições, ou mais do que um significado. Nesta secção são introduzidos alguns conceitos, baseados, principalmente, na norma IEEE 610.12-1990 [8].

2.2.1 Item de Configuração (CI)

Itens de configuração são todos os artefactos do projecto (hardware, software ou ambos) que sejam sujeitos a gestão de configurações, ou seja, que possam ser alterados, por exemplo:

• Documentos produzidos ao longo do projecto, como um documento de especificação de requisitos, ou de arquitectura, são itens de configuração,

• Ficheiros de código são itens de configuração,

• Bibliotecas utilizadas são itens de configuração,

• Software utilizado para o desenvolvimento, ou produção de algum item de configuração, é um item de configuração,

• Hardware utilizado no sistema, ou na sua concepção, também pode ser um item de configuração.

2.2.2 Work product

Um work product é um artefacto associado à execução de um processo. Um artefacto pode ser usado, produzido ou alterado durante o processo.

2.2.3 Baseline

Uma baseline é uma especificação ou um produto que foi formalmente revisto e aprovado, e, como tal, serve de base a desenvolvimento futuro, só podendo ser alterado através de procedimentos de controlo de alterações. Uma baseline marca, formalmente, uma versão estável de um ou um conjunto de CI durante o seu ciclo de vida.

A alteração requer um estado inicial e um estado seguinte, portanto marcar os estados significativos torna-se muito importante, quando se lida com muitas alterações. A identificação de um estado significativo de entre a história de versões de um item de configuração é o objectivo principal da identificação de baselines.



13

2.2.4 Versão

Instância de um item de configuração identificada.

2.2.5 Release

Uma release é uma distribuição de uma versão particular de itens de configuração, com um determinado propósito.

Uma release pode conter uma versão integral do sistema desenvolvido, partes que o constituem (módulos ou correcções de partes com erros), ou ser simplesmente documentação.

2.2.6 Revisão

Processo ou reunião durante a qual um work product é apresentado à equipa de projecto, gestores, utilizadores, cliente e outras partes interessadas para comentário e aprovação.

2.2.7 Auditoria

Uma auditoria é uma verificação independente de um work product, para garantir a conformidade com as especificações, normas, acordos contratuais ou outro critério.

2.2.8 Build

Versão operacional do sistema, ou componente, que incorpora um subconjunto de funcionalidades que o produto final vai ter.

2.2.9 TAG

Uma TAG é um termo frequentemente utilizado para definir uma etiqueta associada com uma determinada versão de um projecto mantido num sistema de controlo de versões. As TAGs permitem ao utilizadores definirem um nome com significado para ser atribuído a um estado particular do projecto submetido a controlo de versões.

Esta etiqueta pode ser usada em vez do número da versão. Quando se utiliza um sistema de controlo de versões, as baselines são, normalmente, traduzidas em TAGs, aplicadas aos ficheiros. Quando se pretende retroceder a uma versão estável, não é necessário saber em que versão estava cada item de configuração, basta retroceder à TAG que representa as versões desses itens.



3 Configuration Management (CM) na Critical Software,S.A.

A Critical Software (CSW) é uma empresa que desenvolve software para sistemas críticos (ver em anexo a descrição da empresa). A gestão de configurações é crucial em todos os seus projectos. Esta visa estabelecer e manter a integridade dos produtos de um projecto de software, durante o ciclo de vida de um projecto.

O nível de CMMI 3 da empresa garante que os processos se encontram definidos segundo as normas e que a empresa utiliza boas práticas de engenharia de software.

De um modo resumido, na CSW todos os projectos têm um controlo dos seus itens de configuração (CIs). Eles encontram-se identificados, controlados e com revisões e entregas planeadas.

Neste capítulo é descrita a gestão de configurações na CSW, tanto em termos das actividades em que se traduz o processo, como na maneira como elas são implementadas.

3.1 Actividades do processo

O processo é composto por várias actividades: estas encontram-se identificadas na Figura 9 e descritas nos pontos que se seguem.

Figura 9 – actividade de CM durante o ciclo de vida do projecto na CSW

14



15

3.1.1 Actividade A1 – definir o plano de CM

O objectivo desta actividade é definir um plano estratégico para as actividades de gestão de configurações.

Descrição da actividade:

1) Definir um plano interno ou externo de CM, baseado no tipo de projecto, tendo em conta as actividades obrigatórias:

• Identificar os itens de configuração;

• Definir a estratégia de build e release: diária, semanal, interna ou externa, etc.

• Relatar diferenças que possam existir relativamente à ferramenta de CM utilizada na Critical, na estrutura do repositório, procedimento de tagging, etc.

• Definir que relatórios de estado vão ser efectuados, a quem são dirigidos, e como;

• Definir como os incidentes do projecto (pedidos de alteração, correcção de erros, etc), builds, releases devem ser tratados;

2) Identificar um elemento da equipa como gestor de configurações, que deve ser o responsável por manter o plano de CM actualizado, e em linha com quaisquer alterações.

3.1.2 Actividade A2 – identificar CIs

Actividade que garante:

- a identificação de todos os itens que necessitem de ser identificados, guardados, testados, revistos, usados, alterados, entregues e/ou sujeitos a manutenção,

- que todos os itens de configuração têm uma identificação única,

- as dependências dos itens de configuração são identificadas e mantidas.

Esta actividade é feita durante todo o ciclo de vida do projecto, com o objectivo de garantir a lista de itens de configuração actualizada e adequada à evolução do projecto.


1) Identificar, unicamente, todos os itens de configuração relevantes do projecto, a sua relação estrutural, e as partes constituintes.

2) Usar o sistema de controlo de versões para guardar os CIs;

3) Garantir a correcta identificação de baselines e versões de CIs;

4) CIs que não sejam guardados no sistema de controlo de versões devem ser identificados;

5) CIs devem ser identificados no plano de CM, releases e outra documentação técnica do projecto.



16

3.1.3 Actividade A3 – gestão de versões

Esta actividade tem como objectivo manter os CIs com uma identificação única, com uma versão e guardados no repositório central, e manter as versões actualizadas.


1) Controlar a versão dos CIs

2) Identificar a versão dos work products (incluindo itens físicos);

3) Gerir iterações a versões

4) Fornecer um mecanismo para recuperar versões anteriores

3.1.4 Actividade A4 – gestão de alterações

Esta actividade garante um controlo total à necessidade de alteração e alterações implementadas em itens de baseline.


1) Fornecer um mecanismo para receber e aceitar alterações de clientes, ou, internamente, em itens de baseline;

2) Controlar a alteração em CI de baseline;

3) Se os CIs forem aceites, criar uma nova baseline de work product;

• Garantir que todas as partes afectadas pela proposta de alteração devem avaliar o esforço, programa e alterações ao impacto do produto;

• Garantir que todas as partes interessadas são notificadas da alteração proposta, da avaliação do impacto, e da prioridade e se a alteração foi aprovada ou rejeitada;

• Garantir que a aprovação ou rejeição é efectuada formalmente, e de uma maneira controlada, antes da implementação;

• Fornecer um histórico de desenvolvimento dos work products, incluindo as alterações propostas e implementadas.

3.1.5 Actividade A5 – estabelecer baselines

Esta actividade tem por objectivo identificar, claramente itens de uma milestone do projecto (release, build), estado (rascunho, aprovado, submetido a aprovação), ou uma altura particular que necessite de ser marcada por uma baseline.


1) Estabelecer, documentar e manter baselines internas e de entrega.

2) Estabelecer um grupo consistente de CIs num específico momento;

3) Estabelecer dependências entre CIs;

4) Sendo o CVS a ferramenta utilizada, as baselines devem ser aplicadas no CVS, utilizando as convenções de tagging e do CVS;



17

5) Se uma baseline incluir componentes que não se encontrem no CVS, essa informação deve ser escrita no documento e guardada no CVS;

6) As baselines devem ser aplicadas, pelo menos, quando existir uma release para o cliente. A informação de release deve incluir a referência da versão da baseline;

7) Começar a controlar a alteração das baselines estabelecidas.

3.1.6 Actividade A6 – build

O objectivo desta actividade é garantir um build limpo, sem nenhum problema conhecido.


1) Identificar claramente como executar um build do produto (passos, instruções, etc.);

2) Transformar o código fonte num executável/documentos revistos;

3) Fazer o build do código fonte;

4) Estabelecer uma baseline de build;

5) Garantir que os builds são reprodutíveis por futuros membros.

O procedimento de build é dependente da tecnologia utilizada no projecto, no entanto, o gestor de configurações do projecto deve garantir que o build é executado com os CIs mantidos no sistema de controlo de versões.

3.1.7 Actividade A7 – release

Actividade que visa implementar a gestão de configuração a actividades de release.


1) Manter sob controlo todos os CIs entregues (tags, revisão do CVS, etc),

2) Produzir a release com toda a informação de CM

3) Manter a informação release actualizada.

3.1.8 Actividade A8 – relatório de estado

Esta actividade tem como objectivo relatar o estado dos itens de configuração mais relevantes.


1) Relatar o estado dos CIs, para melhorar a capacidade de decisão;

2) Registar a informação de gestão de configurações (e.g. identificações aprovadas, estado de alterações propostas à configuração);

3) Relatar informação de gestão de configurações aos stakeholders;

4) Uma vez que são usadas ferramentas de controlo de versões e de alterações, a informação é registada automaticamente;

5) O gestor de configurações vai utilizar esta informação para produzir o relatório;

6) As auditorias de CM podem utilizar esta informação como evidência;



18

7) As auditorias de qualidade podem ser planeadas tendo em conta esta informação

3.1.9 Actividade A9 – auditorias de CM

As auditorias de CM têm como objectivo fornecerem uma avaliação dos itens de configuração, em particular, determinar o seu nível de conformidade com os requisitos predefinidos, baseados nas actividades do processo de CM, nos requisitos do projecto, e para garantirem a sua integridade.


1) Identificar critérios de configuração de auditoria, incluindo a conformidade com as seguintes acções

2) Verificar a aplicação efectiva das actividades do processo de CM

• Identificação de CIs

o Identificação de TAGs (e.g. na release sign-off form e no relatório de revisão)

o TAGs no CVS (releases e relatório de revisão)

o Convenção de TAGs e convenções de nomes

• Controlo de versões

• Identificação de versões (e.g. release sign-off form; relatórios de revisão; lista de itens de configuração)

o Versões submetidas no CVS

• Itens impressos

o Versões correctas assinadas (assinaturas autorizadas)

o Controlo de versões

o Identificação de CIs

• Controlo de alteração

3.2 Processos associados

Os processos associados são abordados com menor detalhe, sendo que o objectivo é explicar a relação com o processo de gestão de configurações e fazer uma breve descrição de como eles são abordados na CSW.

3.2.1 Project Incident Management

Durante o ciclo de vida de um projecto, muitos incidentes podem ocorrer. Um incidente pode ser um defeito detectado no código, um defeito num documento, um defeito na interface com o utilizador (GUI), um pedido de alteração, ou um novo requisito.

Os incidentes são registados, e, seguidos, de forma automática, utilizando uma ferramenta interna da CSW, o Work Orders Web (WOW). No ponto 3.3.1, é apresentada uma breve descrição das ferramentas utilizadas na Critical Software, referenciadas neste relatório.



19

3.2.2 Delivery

Este processo dá um suporte aos processos de engenharia, na medida em que garante que os produtos e serviços são entregues ao cliente, em conformidade com os requisitos acordados. Este processo pode ocorrer em todas as fases de um projecto e é despoletado pela necessidade de release de um work product ao cliente.

O procedimento de release é constituído por:

1) Criar a nota de release – criar um documento com a informação das alterações implementadas, problemas corrigidos, não conformidades existentes (se existirem), pedidos implementados e outra informação relevante, relacionada com a release. Esta informação deve ser entregue ao cliente como sendo parte do conteúdo da release.

2) Criar a baseline de configuração

3) Criar o release sign-off form – preencher o template (release sign-off form) com a informação de release

4) Criar o conteúdo de release intermédio – compilar todos os itens do release sign-off form para serem validados pelo gestor do projecto (PM).

5) Verificar a release – validar a informação do release sign-off form e que os itens fazem parte do conteúdo da release

6) Criar o conteúdo de release

7) Fazer uma cópia de segurança do conteúdo

8) Planear a próxima release

3.2.3 Verification

Apesar do processo de verificação não se encontrar mapeado na Figura 9, ele relaciona-se com o processo de CM, na medida em que é este processo que garante o controlo do estado do item de configuração. A estratégia de revisão encontra-se, tal como a estratégia de release, identificada na lista de itens de configuração (CIL).

A fim de atingir os objectivos, as actividades de verificação, como as revisões, têm de ser efectuados nos work products produzidos pela equipa de projecto. Claramente não é exequível, na maioria dos projectos, efectuar verificações a todos os work products, mas deve existir uma estratégia de verificação identificada.

As revisões podem ser formais, ou informais. Nas revisões informais, só é necessário haver um planeamento registado, mas, normalmente, não existe um documento de registo da revisão. As revisões formais podem ser de 3 tipos,

• Commentary – este tipo de revisão é feito individualmente e os comentários são registados no próprio work product (código, documento ou GUI) e enviados para o autor.

• Meeting Walkthrough – neste tipo de revisão o work product é revisto numa reunião mas não é efectuada uma verificação completa.



• Meeting Full Reading – nesta revisão o work product é revisto numa reunião e é efectuada uma verificação completa.

As revisões são constituídas por 5 fases: planeamento, preparação, revisão, correcção e aprovação.

3.3 Entradas e saídas do processo de CM

As entradas e saídas do processo de CM encontram-se representadas na Figura 10.

Figura 10 – entradas e saídas do processo de CM na CSW

3.3.1 Ferramentas utilizadas

De seguida são descritas algumas ferramentas utilizadas na CSW, durante o processo de CM.

3.3.1.1 WISE – Intradoc

O WISE é um sistema desenvolvido internamente, com o objectivo de contribuir, de forma decisiva, para a uniformização e melhoria do processo de gestão de informação da organização. Ele dispõe de um conjunto de funcionalidades que facilitam a gestão de projectos, colaboradores, etc.

O Intradoc é uma das funcionalidades do WISE, parte do módulo que dá suporte ao sistema de gestão da qualidade, faz a gestão de todos os documentos produzidos na CSW, atribuindo-lhes numeração automática e única e guardando o registo da informação.

3.3.1.2 Work Orders Web (WOW)

O Work Orders Web é uma ferramenta de pedidos de acções web-based, que suporta processos estruturados, permitindo a submissão da acção, a sua monitorização e controlo dos pedidos submetidos. Os pedidos podem necessitar de acção de resposta, ou podem ser, simplesmente, uma informação. Os pedidos são trocados entre equipas, ou indivíduos, de acordo com o processo de negócio.

3.3.1.3 CVS

O sistema de controlo de versões de configuração garante que os work products do projecto são correctamente guardados e é possível fazer um acompanhamento de cada work product desde a sua baseline de configuração até ao estado actual.

20



Actualmente, a Critical Software utiliza um repositório de controlo de versões, suportado por CVSnt. O repositório tem uma estrutura bem definida, e é usado, não só, como repositório de código, como também é visto como um repositório global de toda a informação que está sujeita a controlo de versões.

Este repositório tem algumas limitações ao nível do utilizador normal (o departamento de Sistemas e Infra-estruturas2 pode realizar estas operações a pedido do utilizador). Operações de renomeação de ficheiros ou directorias, alteração da directoria, ou remoção de ficheiros, ou directorias, não são possíveis.

É necessário efectuar esse pedido (via WOW) ao departamento de Sistemas e Infra-estruturas (DSI) para efectuar a operação. O DSI recebe o pedido, atribui a um dos elementos do departamento, executa o pedido no repositório e actualiza o estado do pedido no WOW. O utilizador é avisado da execução do pedido e fecha o mesmo após confirmação. Os principais passos estão ilustrados na Figura 11.

Figura 11 – operações no CVS

Isto é um breve resumo da interacção necessária para efectuar uma operação (das descritas acima) no CVS. Estas operações podem ser relativamente rápidas ou podem demorar até 2 dias a serem executadas. Embora a empresa não guarde um registo discriminado das acções submetidas, foram recebidos pelo DSI no ano de 2007, 751 pedidos relativos ao CVS e foram gastas em média 3 horas desde a submissão até ao fecho do pedido. Destes pedidos estima-se que mais de metade sejam relacionados com as operação de: renomeação, alteração de sítio e remoção de ficheiros ou pastas.

Tabela 2 – dados de operações no CVS

Informação Valor Pedidos em 2007 751 pedidos (4003 de renomeação, alteração de sítio e remoção)

Tempo médio de espera4 3 horas

Recursos 1 pessoa

2 Departamento responsável pela administração do repositório de controlo de versões. 3 Valor estimado devido ao facto dos pedidos não serem discriminados. 4O tempo de execução do pedido não é registado, este é o tempo que demora, desde que o pedido é submetido até ao seu fecho, portanto é o tempo de espera do utilizador.

21



3.4 Implementação das actividades de CM e processos associados

Nesta secção vão ser explicadas as actividades que foram identificadas como possíveis de melhorar. Estas actividades são abordadas de um ponto de vista mais operacional, porque se verificam diferenças entre as definições das actividades e a forma de as implementar.

As actividades que não são referidas aqui, não tinham necessidade de serem melhoradas.

3.4.1 Actividade A2 de CM

Quando se inicia um projecto, há um planeamento de todos os itens de configuração que se vão produzir, das respectivas releases, e das revisões a que devem ser sujeitos. Esta informação é registada na lista de itens de configuração (CIL), uma das saídas do processo de CM (ver Figura 12).

Figura 12 – (replicação da Figura 10) entradas e saídas do processo

Esta CIL é uma folha de cálculo, guardada no repositório de CVS, que está sujeita a actualizações, de cada vez que se altera ou cria um novo CI, se altera uma data de revisão, ou de release.

Normalmente, o que acontece, na prática, é que os itens são planeados e registados na CIL antes do Kick Off Meeting (KOM), mas só quando se vai criar o documento é que se regista na ferramenta de controlo de documentos (o Intradoc), obtendo um código único que é inserido na CIL (ver Figura 13). Isto é recorrente e acontece para quase todos os CIs.

22



Figura 13 – actividade de identificação de CIs

Esta actividade pode ser quantificada em termos de número de passos, tempo de execução e recursos humanos necessários (ver Tabela 3).

Tabela 3 – dados relativos a 1 item de configuração

Passos Tempo Recursos Registo na CIL Até 1 minuto 1 pessoa

Registo no Intradoc Até 1 minuto 1 pessoa

Actualização da CIL Até 1 minuto 1 pessoa

3.4.2 Actividade A9 de CM

O repositório de controlo de versões é sujeito a verificação das regras de nomenclatura e de aplicação de TAGs: as auditorias de CM têm esse objectivo.

A maneira de proceder a estas verificações é verificar cada ficheiro manualmente através do cliente de CVS, tendo em conta que há ficheiros que não têm as mesmas regras de nomenclatura (exemplificado na Figura 14). Por exemplo, a ficheiros de código não se aplicam as mesmas regras que se aplicam aos documentos.

23



Figura 14 – actividade de auditoria de CM

Esta actividade é quantificada de acordo com a Tabela 4, tendo os valores do tempo sido recolhidos para uma directoria com 15 CIs.

Tabela 4 – dados relativos a uma auditoria de CM

Passos Tempo5 Recursos Actualização do repositório Até 1 minuto 1 pessoa

Verificação de TAGs Até 1 minuto 1 pessoa

Verificação de nomenclatura Até 1 minuto 1 pessoa

3.4.3 Processos associados

Relativamente aos processos associados, revisões e entregas, além do planeamento na CIL, elas são registadas sob a forma de relatórios, existindo na empresa templates a seguir na sua elaboração.

3.4.3.1 Verification

A estratégia de revisões do processo de Verification, é definida no início do projecto e registada na CIL para cada CI.

Cada revisão formal fica registada num relatório de revisão (review report). Este relatório inclui secções para registar as várias fases da revisão: o planeamento, preparação, revisão, correcção e aprovação (ver Figura 15). No entanto, a maioria das vezes o registo de todas as fases é efectuado na mesma altura, ou seja, durante a revisão.

O relatório de revisão é sujeito à verificação da aprovação (se o relatório se encontra assinado por quem tem autoridade para tal).

Com o objectivo da melhoria contínua, do procedimento de revisão é ainda necessário extrair algumas métricas. Estas métricas são extraídas manualmente a partir de cada relatório de revisão.

5 Valores estimados para verificação de 15 CIs na mesma directoria

24



Figura 15 – fases da revisão

Na Tabela 5 encontram-se alguns dados relativos a esta actividade.

Tabela 5 – dados relativos a uma revisão

Passos Tempo Recursos Registo da informação6 -- --

Recolha de métricas Até 30 minutos 1 pessoa

Verificação de assinaturas Até 1 minuto 1 pessoa

3.4.3.2 Delivery

A actividade de release do processo de Delivery, é também registada num relatório (release sign-off form). Esta actividade pode ser dividida em três fases, embora, normalmente, não ocorram separadas: a identificação, a adição de conteúdo e o registo de ambiente.

Quando se efectua uma release, é necessário aplicar uma TAG de release, aos ficheiros que dela fazem parte. Depois, cria-se o release package, que é um ficheiro único com os ficheiros e documentos que fazem parte da release e regista-se no relatório (release sign-off form) a informação respectiva:

• À identificação da release incluindo a TAG aplicada,

• Ao conteúdo, com todos os ficheiros que dela fazem parte,

• Ao ambiente de release incluindo versão e notas.

Por ultimo, há uma verificação de todos os ficheiros que estão identificados no conteúdo da release, para garantir que a TAG foi correctamente aplicada e que segue as convenções. Na Figura 16, encontra-se esquematizado o procedimento de release e na Tabela 6 os dados.

6 Depende do tipo de revisão, não é possível quantificar

25



Figura 16 – fases da release

Tabela 6 – dados relativos a uma release (15 CIs)

Passos Tempo7 Recursos Aplicação da TAG -- --

Criação do release package Até 20 minutos 1 pessoa

Verificação da informação Até 30 minutos 1 pessoa

3.5 O que pode ser melhorado?

Da análise dos processos e das actividades em que se sub-dividem, é relativamente fácil perceber que certas actividades são repetitivas e poderiam ter vantagens numa automatização. A solução proposta neste trabalho é uma ferramenta web-based que dá suporte às actividades identificadas no ponto 3.4 .e que permite para além de uma automatização de algumas das actividades referenciadas, a obtenção de dados importantes para medição.

A questão não estará com certeza nas vantagens introduzidas por uma ferramenta web-based em detrimento dos templates de documentos existentes actualmente mas sim pela melhoria obtida ao nível da uniformização, centralização e visualização da informação. Essas vantagens são claras, e, normalmente, superiores às desvantagens que se poderão identificar. Uma das desvantagens facilmente identificadas é, como qualquer tecnologia que depende de uma rede para funcionar, a sua disponibilidade. No entanto, o repositório remoto de controlo de versões e as outras ferramentas já usadas pela empresa (ex: WISE, WOW), também dependem dela e,

7 Tempo estimado para uma release de 15 CIs

26



27

por isso, a transição de uma maneira de trabalhar para a outra, não acrescenta um risco elevado.

Um dos problemas usualmente associados à qualidade é a burocracia. A definição dos processos garante que a organização tem padrões para as suas actividades, que os tem documentados e acessíveis a toda a organização.

No entanto, os processos e procedimentos que têm como um dos seus objectivos tornar as actividades simples, tornam-nas, muitas vezes, pesadas e criam uma certa inércia. Dão, muitas vezes, a noção, por quem os segue, que nem sempre estão actualizados, ou são relevantes. Normalmente envolvem muita burocracia e, quando não são suportados por ferramentas de software, tornam-se em trabalho manual cansativo, nada compensador e facilmente exposto ao erro humano.

Existem no mercado bastantes ferramentas de gestão de configurações, mas a maioria delas é bastante complexa e traz mais funcionalidades do que as exclusivamente pretendidas. A CSW já utiliza uma ferramenta de controlo de versões e, portanto, ferramentas complexas não trariam valor acrescentado numa empresa em que as práticas de gestão de configurações estão bem sedimentadas.

Embora haja algumas ferramentas que são open-source, a grande maioria delas são proprietárias e o seu valor económico associado ao custo de uma alteração nas práticas da empresa, não seria viável.

A empresa conta, na sua breve história, com alguns casos de sucesso de ferramentas desenvolvidas para consumo interno e que actualmente são comercializadas.

Assim, surge a possibilidade de se desenhar uma ferramenta interna que se enquadre com os processos da empresa, permita agilizá-los e que garanta que a alteração não tenha impacto significativo nas suas práticas. Esta ferramenta é o Configuration Management Office (CMO) e encontra-se explicado no próximo capítulo.



4 O CMO – Configuration Management Office

4.1 Introdução

O Configuration Management Office (CMO), surge da necessidade de automatizar os processos associados à gestão de configurações.

Na Critical Software, o processo de gestão de configurações, no âmbito de um projecto de desenvolvimento de software, é suportado por uma ferramenta que efectua o controlo de versões. Esta ferramenta mantém a integridade dos produtos de software durante o seu desenvolvimento.

Para tal, é utilizado um repositório, onde é mantida a informação relevante ao processo de desenvolvimento de software. No entanto, a interacção com o repositório de controlo de versões nem sempre é simples. Certas actividades de manipulação de ficheiros no repositório são demoradas devido à limitação que o utilizador tem em certas operações e à necessidade resultante de ter de recorrer ao departamento de Sistemas e Infra-Estruturas8. Actividades de renomeação de ficheiros ou pastas, alteração da pasta, ou mesmo remoções, não poderem ser feitas directamente no repositório, mesmo por utilizadores com permissão para tal. Estas actividades são muito frequentes e sobrecarregam o departamento de Sistemas e Infra-Estruturas.

As quatro principais actividades que compõem a gestão de configurações: identificação, controlo, monitorização do estado e auditorias, possuem a característica de serem repetitivas e morosas.

Como forma de reduzir o tempo ocupado com estas actividades, aumentar a visibilidade, e garantir um controlo mais eficiente, surgiu a necessidade de desenhar uma ferramenta que permita automatizar estas actividades e dar-lhes uma maior visibilidade.

4.2 Especificação da solução proposta

A solução proposta é, como referido anteriormente, uma ferramenta web-based, desenvolvida com a mesma arquitectura e tecnologia do WISE (descrito no ponto 3.3.1.1), para evitar problemas de integração e para garantir homogeneidade entre as ferramentas internas da empresa.

O CMO foi pensado para ajudar nas tarefas de gestão de configurações e é uma ferramenta orientada ao projecto que engloba vários módulos explicados de seguida:

• Itens de Configuração (4.2.1)

• CVS (4.2.2)

• CVS Audit (4.2.3)

• Revisões (4.2.4)

28

8 Departamento da CSW responsável pela administração de sistemas e infra-estruturas. É este departamento que

faz a gestão do repositório de controlo de versões.



29

• Release (4.2.5)

4.2.1 Itens de Configuração

Neste módulo, a ferramenta apresenta uma interface para a gestão de itens de configuração. O CMO disponibiliza duas tabelas de itens de configuração (internos e externos), com a respectiva informação mais relevante (ver Tabela 7 e Tabela 8).

Tabela 7 – informação disponibilizada na tabela de CIs internos

Informação Descrição Nome Nome do CI

ID interno Código interno do CI, referência Intradoc

ID do Plano do Projecto Código do CI no projecto (exemplo, DL-01)

Tipo de CI Código, interface gráfica com o utilizador ou documento

Versão aprovada Ultima versão aprovada do CI

Estado de revisão O estado de revisão, pode ser, não planeada, planeada,

Data da última acção Data da última acção relativa às revisões.

Tabela 8 – informação disponibilizada na tabela de CIs externos

Informação Descrição Nome Nome do CI

ID interno Código interno do CI

Notas Notas

É possível inserir, editar e eliminar itens de configuração internos e externos. Na inserção ou edição, o CMO detecta automaticamente se os nomes inseridos estão consoante as normas e avisa o utilizador.

O CMO tem a vantagem de estar integrado com o Intradoc. Sempre que um item é registado no Intradoc, ele é inserido automaticamente na tabela de CIs do CMO do respectivo projecto, deixando de ser necessária a sua actualização manual, todas as vezes que são registados novos itens (Figura 17).



Figura 17 – (replicação da Figura 13) actividade de identificação de CIs antes do CMO

4.2.2 CVS

No módulo de CVS é permitido efectuar algumas operações de renomeação, alteração do sítio e remoção de ficheiros e pastas. Estas operações ficam registadas para que a equipa saiba o que se passa no repositório do projecto.

4.2.3 CVS Audit

Este módulo apresenta três funcionalidades que permitem obter relatórios automáticos para actividades que anteriormente eram efectuadas manualmente:

• Obtenção de relatórios de auditorias de CM (por exemplo, que ficheiros têm uma determinada TAG aplicada, ou que TAGs estão aplicadas numa determinada directoria).

• Obtenção de relatórios de todos os ficheiros no repositório do projecto, ou numa subdirectoria, que não seguem as convenções de nomes da CSW, excluindo os ficheiros de código que têm convenções próprias.

• Obtenção de relatórios de todos os ficheiros submetidos no repositório do projecto, nos últimos dias (selecção de datas).

4.2.4 Revisões

Relativamente às revisões, o CMO permite uma visibilidade global do processo de Verification completamente diferente. A estratégia de revisão, assim como as revisões

30



efectuadas, estão visíveis numa tabela e a informação está integrada com a tabela de CIs, uma vez que, na tabela de CIs, está disponível o estado relativo às revisões.

O módulo de revisões garante ao utilizador um acompanhamento das várias fases do procedimento de revisão, com automatização de alguns passos e a vantagem que a informação disponível nas tabelas está sempre actualizada.

As métricas referidas na Tabela 9 associadas ao processo, são recolhidas automaticamente a partir dos campos preenchidos no CMO.

Tabela 9 – métricas do procedimento de revisões

Código Métrica Descrição

M17 Eficiência temporal da revisão Soma pesada dos defeitos encontrados por esforço gasto na revisão.

M25 Número de revisões conduzidas Número de revisões efectuadas durante o ciclo de vida do projecto.

M29 Peso dos defeitos da revisão Número total de defeitos encontrados (com o respectivo peso).

M30 Esforço/página da revisão O esforço médio necessário para rever uma página.

M31 Tempo de reunião/página Média do tempo necessário para rever uma página.

M33 Esforço médio de correcção de um

defeito

Média de tempo necessário para corrigir defeitos (por tipo).

4.2.5 Releases

O módulo de releases dá um apoio ao utilizador na gestão de releases e no procedimento em si. O CMO providencia, também neste módulo, uma melhoria no que diz respeito à visibilidade.

Quando há uma release, a ferramenta permite a sua identificação, selecção do conteúdo por escolha directamente a partir do CVS, aplicação da TAG de release ao conteúdo seleccionado e escolha de ambiente, a partir da lista geral de software utilizado na empresa.

4.3 Práticas de Gestão de Configurações depois do CMO

Uma das melhorias mais importantes introduzida pelo CMO é a automatização de tarefas. Há tarefas repetitivas, que passaram a ser automáticas e há tarefas que passam a ser possíveis no CMO. Uma vantagem inerente à automatização é a prevenção de introdução de erros.

O CMO também tem uma grande vantagem, em termos de visibilidade para a equipa de projecto, mas, principalmente, para o gestor do projecto (PM), para o gestor de configurações (CM) e para o responsável pela garantia de qualidade de software (SQA). Toda a informação relevante de gestão de configurações está centralizada numa ferramenta web-based.

Nos pontos seguintes, são apresentadas as principais alterações às práticas da empresa analisadas anteriormente, depois do CMO.

31



4.3.1.1 Actividade A2 de CM no módulo de Itens de Configuração

Uma melhoria significativa introduzida pela utilização do CMO para gerir os itens de configuração é o controlo automático de erros de nomenclatura. Quando o utilizador tenta registar um CI com um nome que não segue as convenções predefinidas pela empresa e pela ferramenta, o CMO alerta-o desse facto.

A integração com a ferramenta de numeração de documentos (Intradoc) permite diminuir o número de passos necessários e garante que a informação se encontra sempre actualizada. O CMO evita que haja uma necessidade de actualização da CIL, de todas as vezes que um CI é registado no Intradoc. A tabela de CIs no CMO é, automaticamente, actualizada, quando se cria, ou actualiza, um documento no Intradoc.

Antes do CMO, o registo dos CIs na CIL era feito no início do projecto (ver Figura 18) e só depois registado no Intradoc. Agora, o registo dos CIs no Intradoc aquando do seu planeamento, traz vantagens acrescidas, porque, o passo de ter de se registar na CIL deixa de ser necessário (é efectuado automaticamente conforme já referimos e como se pode ver exemplificado na Figura 19).

Figura 18 – (replicação da Figura 13) actividade de identificação de CIs antes do CMO

32



Figura 19 – actividade de identificação de CIs depois do CMO

Na Tabela 10 encontram-se as principais diferenças, nesta actividade, antes e depois do CMO.

Tabela 10 – resumo das diferenças no módulo de CI

Actividade Antes do CMO Depois do CMO

Registo - Registo na CIL

- Registo no Intradoc

- Actualização da CIL

- Registo no CMO ou no Intradoc

Actualização - Actualização da CIL

- Actualização do Intradoc

- Actualização no CMO ou no Intradoc

Tempo médio Cerca de 3 minutos Menos de 1 minuto

Recursos 3 pessoas (para a actividade de

registo)

2 pessoas (para a actualização)

1 pessoa (registo ou actualização)

4.3.1.2 Actividade A9 de CM no módulo de CVS Audit

O CMO apresenta relatórios de TAGs, nomenclatura e de ficheiros submetidos. O PM do projecto tem uma visibilidade do estado do seu projecto, bastando, para isso, seleccionar o relatório de ficheiros submetidos nos últimos dias.

Os SQAs (software quality assurance) e o CM (configuration manager) também têm as tarefas facilitadas pelos relatórios de CVS Audit, em vez de efectuarem uma verificação no repositório, é-lhes apresentado um relatório dos nomes de ficheiros, que não respeitam as normas e das TAGs aplicadas (ver Figura 20).

33



Figura 20 – actividade de auditoria de CM depois do CMO

A principais diferenças encontram-se na Tabela 11.

Tabela 11 – resumo das diferenças em CVS Audit


Passos - Actualização do repositório

- Verificação manual dos ficheiros (TAGs

ou nomes)

- Obtenção automática do relatório

Tempo médio execução Estima-se 1 minuto numa directoria com 15

ficheiros.

Menos de 1 minuto, independentemente da

dimensão

Recursos 1 pessoa para efectuar a verificação 0, verificação automática

4.3.1.3 Módulo de CVS

Operações recorrentes de renomeação, alteração de pasta, ou remoção de um ficheiro, ou de uma pasta, no repositório do projecto, tinham de passar, obrigatoriamente, pelo departamento de Sistemas e Infra-Estruturas e, obviamente, não eram imediatas.

No CMO passa a ser possível, ao próprio utilizador, desde que tenha permissões para isso, executar directamente as acções no CVS. As acções suportadas de renomeação, alteração do sítio e remoção de ficheiros e pastas, passam a ser possíveis directamente na ferramenta, como ilustrado na Figura 21.

34



Figura 21 – operações no CVS depois do CMO

35

A Tabela 12 apres pois do CMO.

Tabela 12 – resumo das diferenças no módulo de CVS

enta um resumo das diferenças nestas operações, antes e de

de Antes do CMO Depois do CMO Activida

Passos tamento de

I)

DSI

o pedido

- Execução directamente no CMO - submissão do pedido ao Depar

Sistemas e Infra-estruturas (DS

- pedido executado pelo

- fecho d

Tempo médio de espera o 3 horas o tempo de execução de uma operação n

módulo de CVS é de menos de 1 minuto.

Recursos utilizados 1 pessoa – é necessário pelo menos um

o DSI para efectuar esta tarefa.

0 – a tarefa é executada pelo próprio utilizador.

elemento d

4.3.1.4 Módulo de Revisões

No processo de revisões, introduz-se a capacidade de recolher métricas, em tempo real, e de

s fases de revisão e também garante uma adequada aprovação da revisão (garante que a mesma só fica fechada quando devidamente aprovada pelo responsável pela aprovação).

forma automática. Este era o principal objectivo para o desenvolvimento do módulo de revisões (ver Figura 22).

O módulo providencia assim o acompanhamento das vária



Figura 22 – revisões no CMO

A Tabela 13 apresenta um resumo das diferenças nas revisões antes e depois do CMO.

Tabela 13 – resumo das diferenças no módulo de revisões


Passos - registo da informação de revisão no

relatório de revisão

- verificação de assinaturas

- recolha de métricas

- registo da informação no CMO

Tempo médio9 30 minutos para recolha de métricas e

verificação de assinaturas.

Instantâneo, o CMO faz o processamento

automático e não permite a aprovação de uma

revisão por quem não está autorizado.

Recursos utilizados 3 pessoas 1 pessoa – tarefas de verificação de assinaturas e

recolha de métricas passam a ser automáticas.

4.3.1.5 Módulo de Releases

As releases no CMO ficam bastante simplificadas, uma vez que, deixa de ser necessário o passo de aplicação de TAGs aos ficheiros de release. Em vez de se registar em papel quais são os ficheiros que fazem parte da release, o CMO permite que se escolham directamente do CVS e a TAG é aplicada a partir da aplicação (como se pode ver na Figura 23).

9 Este tempo médio não contabiliza o tempo da revisão, só as tarefas de verificação de assinaturas e recolha de

métricas.

36



Figura 23 – release no CMO

A criação do release package é opcional, mas permite que seja criado um ficheiro único, com a informação de release e os ficheiros seleccionados.

Na Tabela 14, é apresentado um resumo das diferenças deste procedimento, antes e depois do CMO.

37



Tabela 14 – resumo das diferenças no módulo de releases


Passos - aplicação de TAG aos ficheiros

- criação do release package

- registo da informação da release no

relatório (release sign-off form)

- registo da informação de release no CMO.

Tempo médio 5 minutos (para aplicação da TAG e criação

do release package para uma release com

15 CIs).

1 minuto (a aplicação de TAG e a criação do

release package são automáticos)

Recursos 3 pessoas 1 pessoa (2 passos passam a ser automáticos)

4.4 Visão integrada

O CMO é uma ferramenta que integra várias funcionalidades, relacionadas com a gestão de configurações. Uma das suas principais vantagens, como foi referido anteriormente é a visão integrada que a ferramenta providencia de todo o processo e a sua interacção com os processos de Verification e Delivery.

Em vez de um conjunto de documentos separados no repositório do projecto, com registo de informação, passamos a ter um sítio único onde existe toda a informação relevante.

Como se pode ver na Figura 24, o CMO acompanha todo o ciclo de vida de um item de configuração, desde o seu planeamento, até à release.

Figura 24 – gestão integrada

Os processos também passam a ser muito mais intuitivos, porque há um acompanhamento das acções através da ferramenta, para que, o utilizador seja guiado pela mesma sem que tenha

38



39

real conhecimento do passo seguinte. Embora os processos e procedimentos estejam bem documentados, há uma diferença muito grande entre ter a documentação acessível, ou ter um acompanhamento das acções estilo wizard, para criação de uma release ou revisão, com automatização de alguns passos e com ajudas, no que diz respeito aos campos obrigatórios.

As equipas de projecto passam a ver os processos de qualidade de uma forma muito menos penosa, que se encaixam mais com o respectivo projecto e pensados de maneira a que tragam mais valias para o projecto.

De uma forma geral, o CMO integra todas as actividades relacionadas com gestão de configurações e permite automatiza-las, controla-las mas, principalmente, permite aumentar a sua visibilidade, e, muitas vezes, permite justificar a existência do próprio processo.



40

5 Reflexão crítica

Os modelos de referência de Qualidade, como a ISO 9001:2000, ou o CMMI, descrevem critérios de processos que devem ser implementados, mas não descrevem, em particular, como os implementar. A implementação fica a cabo da organização que pretende implementar o sistema de qualidade.

A gestão de configurações é uma parte muito importante do processo de desenvolvimento de software. No entanto, à medida em que as organizações começam a tornar específicos os seus objectivos, no que respeita à gestão de configurações, as actividades tendem a tornar-se penosas.

Um processo ideal é um processo equilibrado, ou seja, suficientemente longo para contemplar as actividades necessárias e razoavelmente curto para não ser penoso.

O estudo aqui apresentado visa trazer algum valor acrescentado, no que diz respeito à automatização da qualidade. O processo de Configuration Management e a sua implementação foi estudado e foi sugerida e implementada uma solução que permite agilizar o processo, principalmente nos pontos analisados como passíveis de melhoria.

5.1 Conclusões

O CMO diminui alguns passos, tempo e o número de pessoas necessárias à execução de actividades do processo de Configuration Management.

Os módulos de CVS e CVS Audit (descritos em 4.2.2 e 4.2.3), encontram-se já testados e em produção. Os outros módulos ainda necessitam de aprovação, embora os módulos de Itens de Configuração e de release estejam implementados, apenas o de revisões ainda não foi desenvolvido.

O CMO é visto como uma melhoria operacional do processo, com capacidade para integrar outras actividades e mesmo servir de plataforma de interacção com o CVS.

Na actividade A2 de CM (identificação de itens de configuração), temos uma melhoria em termos de diminuição de passos e de recursos de 67.7% e uma diminuição de tempo de 80.0% (ver Tabela 15).

Tabela 15 – melhoria no módulo de CI

Actividade Antes do CMO Depois do CMO Melhoria

Passos (número) 3 1 66.7%

Tempo médio (minutos) 5 1 80.0%

Recursos (pessoas) 3 1 66.7%

Na actividade de release temos uma diminuição, no número de passos e recursos necessários, de 66.7% e uma diminuição do tempo médio de 80.0%, como se pode verificar na Tabela 16.



41

Tabela 16 – melhoria no módulo de release



Tempo médio (minutos) 5 1 80.0%


Na actividade de revisão estima-se uma diminuição de passos e de recursos necessários de 67,7% e de tempo médio de aproximadamente 100.0% (ver Tabela 17).

Tabela 17 – melhoria no módulo de revisões



Tempo médio (minutos) 30 ~0 ~100%


De forma a efectuar operações no CVS dos projectos era necessário pedir (via work-orders) a execução da operação ao departamento de Sistemas. No CMO, essas operações tornam-se possíveis sem ter de recorrer a terceiros, assim, estas actividades conseguem têm uma diminuição de 66.7% no número de passos necessários, de 100% no tempo médio de execução e de 50% nos recursos (ver Tabela 18).

Tabela 18 – melhoria no módulo de CVS



Tempo médio (minutos) 240 1 ~100.0%

Recursos (pessoas) 2 1 50%

As auditorias de CM passam a ser completamente automáticas. Assim sendo, as actividades suportadas por este módulo, têm uma redução do número de passos de 50% e de tempo médio e de recursos necessários de 100% (ver Tabela 19).

Tabela 19 – melhoria no módulo de CVS Audit


Passos (número) 2 1 50%

Tempo médio

(minutos)10

1 ~0 100%

Recursos (pessoas) 1 0 100%

10 Valor estimado para uma verificação de 15 ficheiros na mesma pasta.



42

No total, o CMO trás uma melhoria ao nível de redução do numero de passos de 63.3%, de redução de tempo necessário à execução de 92% e de recursos de 70% (ver Tabela 20).

Tabela 20 – melhoria no CMO

Módulo Passos Tempo Recursos

CI 66.7% 80.0% 66.7%

CVS 66.7% 100.0% 50.0%

CVS Audit 50.0% 100.0% 100.0%

Revisões 66.7% 100.0% 66.7%

Release 66.7% 80.0% 66.7%

Média 63.3% 92.0% 70.0%

Como já foi referido anteriormente, os módulos de CVS e CVS Audit encontram-se testados e em produção, contudo, os outros módulos ainda necessitam de aprovação. Devido a uma reestruturação que a empresa está a sofrer, esta ferramenta deixou de ser uma prioridade, o que levou a um atraso na aprovação dos restantes módulos, no entanto, ainda está nos planos a continuação do desenvolvimento do CMO. De seguida são apresentadas algumas perspectivas de trabalho futuro.

5.2 Perspectivas de trabalho futuro

A especificação proposta neste projecto, visou identificar as oportunidades de melhoria e quantificar os aperfeiçoamentos implementados. Há algumas actividades que poderiam sofrer melhorias, mas ainda não foram especificadas, uma vez que não são prioritárias. Isto deve-se ao facto de estas actividades serem pouco frequentes (poucas vezes por projecto).

Uma sugestão de melhoria que facilitaria o início do projecto, seria possibilitar a escolha de tipos de CIs que se vão produzir. Neste momento, eles têm de ser introduzidos um a um, seja no Intradoc, no CMO, ou na CIL. Uma vez que, é de todo o interesse identificar os CIs no início do projecto, seria vantajoso seleccioná-los a partir de uma lista de itens comuns ao tipo de projecto que se está a desenvolver. Quando os CIs são escolhidos, o CMO atribuir-lhes-ia a referência Intradoc. Estima-se que esta abordagem simplificaria, o início do projecto, no entanto, esta melhoria é difícil de quantificar na medida em que não seriam diminuídos o número de passos ou os recursos envolvidos, e o tempo é difícil avaliar já que mesmo através de selecção, cada CI teria de ser editado para registar a restante informação.

Outra possibilidade para melhorar a interacção com o CVS, seria fazer uma ligação entre o CI (quando aplicável) e o local onde ele está no repositório. Registando o local, permitiria que, ao actualizar, por exemplo, o nome, o CMO renomeasse no CVS e actualizasse o Intradoc. Ou seja, quando se pretende renomear um CI, ainda são necessários 2 passos, renomeação no CVS e no CMO (ou no Intradoc). Esta melhoria permitiria um ganho de 50.0% a nível de tempo (ver Tabela 21).



43

Tabela 21 – sugestão de melhoria de interacção com o CVS

Actividade Antes Depois Melhoria

Passos 2 1 50.0%

Tempo médio (minutos) 2 ~1 50.0%

Recursos 1 0 100.0%

Embora a melhoria de 50.0% em termos de tempo, seja considerável, ela não foi considerada para implementação, porque não é uma actividade tão frequente como as anteriormente mencionadas (como mencionadas no capítulo 4).

O módulo de release poderia incluir a nota de release. Neste documento são registadas as alterações implementadas, os problemas corrigidos, as não conformidades existentes (se aplicável), os pedidos implementados e outras informações relevantes relacionadas com a release.

Deste modo, todo o procedimento de release ficaria integralmente suportado pelo CMO, mas esta sugestão de melhoria não é quantificável.

O módulo de revisões poderia utilizar a funcionalidade de marcação de eventos do WISE quando se planeia uma revisão. No planeamento da revisão seria criado um evento automaticamente e os intervenientes receberiam um alerta com a informação respectiva.

Estas sugestões de melhoria foram surgindo à medida que o projecto foi avançando. Algumas delas fogem do âmbito do projecto, no entanto, se a ferramenta puder evoluir para tornar a interacção com o repositório de versões mais simples, estas sugestões devem ser tomadas em conta para desenvolvimentos futuros.



44

Glossário

Baseline

Conjunto de especificações que foi formalmente revisto e validado que servirá como base para futuros desenvolvimentos, e pode apenas ser alterado sob procedimentos de controlo de modificações.

Build

Processo de converter ficheiros de código fonte em ficheiros de software que podem correr num computador.

CMMI

Abordagem integrada ao modelo de maturidade e capacidade dos processos. Suporta modelos de maturidade contínuos e discretos e integra sistemas e modelos de maturidade de processos engenharia de software.

CVS

Repositório de controlo de versões que permite trabalhar com diversas versões de ficheiros organizados num directório, mantendo versões antigas e relatórios de quem/quando se criou/modificou os ficheiros.

Item de Configuração (CI)

Agregação de work products que é designado para gestão de configurações e tratado como uma única entidade no processo de gestão de configurações.

Kick Off Meeting (KOM)

Reunião que marca o inicio do projecto.

Milestone

Marca temporal do fecho de uma fase do projecto.

Project Incident

Incidentes do projecto são todas as ocorrências que acontecem durante o ciclo de desenvolvimento do projecto e precisam de ser analisadas e classificadas depois de análise.

Release

Versão de um sistema de software que é disponibilizado ao cliente.

Release sign-off form

Template utilizado na CSW para registar a informação relativa à release.

Revisão

Processo ou reunião durante a qual um work product é apresentado à equipa de projecto, gestores, utilizadores, cliente e outras partes interessadas para comentário e aprovação.

Stakeholders

Partes interessadas.



45

TAG

Etiqueta que identifica inequivocamente uma baseline.

Tagging

Acto de aplicar TAGs.

Verification

Processo de certificar que o sistema vai de encontro às suas especificações.

Work product

[ISO 15504-9] artefacto associado à execução de um processo. Um artefacto pode ser usado, produzido ou alterado durante o processo [9].



46

Referências e Bibliografia

[1] NASA, The Software Assurance Technology Center, http://satc.gsfc.nasa.gov/ . Visitado em 16 de Janeiro de 2008

[2] SOMMERVILLE, Ian (2007). Software engineering, (8th Edition), Harlow: Addison-Wesley Professional. ISBN 978-0-321-31379-9,

[3] ISO 9126. 1999, Software Engineering - Product quality. ISO. (Norma Internacional)

[4] ISO 9001. 2000, Quality Management Systems – Requirements. ISO. (Norma Internacional)

[5] FLORAC, William A. et al. (1997), Measuring for Process Management and Improvement , CMU/SEI-97-HB-003

[6] SEI, The Software Engineering Institute, http://www.sei.cmu.edu/, Visitado em 18 de Janeiro de 2008

[7] IEEE Std 828. 1998, Standard for Software Configuration Management Plans. IEEE. (Noma Internacional)

[8] IEEE Std 610.12. 1990, Standard Glossary of Software Engineering Terminology. IEEE. (Norma Internacional)

[9] ISO/IEC 15504-9. 1998, Information Technology – Software Process Improvement. ISO. (Norma Internacional)

[10] ISO/IEC 12207. 1995, Information Technology - Software Life Cycle Processes. ISO. (Norma Internacional)

[11] IPQ, NP 405-1. 1995, Informação e documentação – Referências bibliográficas: documentos impressos. IPQ. (Norma Portuguesa)

[12] SEI, (2005). CMMI Guidelines for Process Integration and Product Improvement, (2nd edition). Addison-Wesley Professional. ISBN-10: 0-321-27967-0

[13] DART, Susan (1991), Concepts in Configuration Management Systems, Third International Software Configuration Management Workshop, ACM Press.

[14] DART, Susan (1991), Best practice for a Configuration Management system, System Configuration Management, ICSE’96 SCM-6 Workshop Berlin, Germany

[15] COLLINS-SUSSMAN, Ben ,Brian W. Fitzpatrick, C. Michael Pilato (2004). Version Control with Subversion. ISBN 10: 0-596-00448-6

[16] FEILER, P. (1990). Software Process Support in Software Development Environments, Fifth International Software Process Workshop, ACM Press.

[17] BANNATAN, E.M (2005). Software Project Management: A practitioner’s approach, (6th Edition) McGRAW-HILL. ISBN 0072853182

[18] GILB, Tom, Susannah Finzi. (1997), Principles of software engineering management. Addison-Wesley Professional, Longman Limited

[19] LYON, David Douglas. (2003), Practical CM: Best Configuration Management Practices for the 21st Century. Raven Pub Co, ISBN-10: 0966124847

http://satc.gsfc.nasa.gov/

http://www.sei.cmu.edu/



47

[20] HASS, Anne Mette Jonassen. (2003), Configuration Management Principles and Practice. Addison-Wesley Professional. ISBN-10: 0321117662

[21] LEON, Alexis. (2000), A Guide to Software Configuration Management, Artech House. ISBN-10: 1580530729

http://www.amazon.com/exec/obidos/search-handle-url/102-0299728-9183362?%5Fencoding=UTF8&search-type=ss&index=books&field-author=Anne%20Mette%20Jonassen%20Hass



48

ANEXO A: Apresentação da instituição de projecto, Critical Software, S.A.

O projecto foi desenvolvido na Critical Software, S.A. A empresa, fundada em 1998 em resultado de um spin-off do Instituto Pedro Nunes (IPN) em Coimbra, situa-se no mercado das Tecnologias de Informação (TI). A empresa tem como actividade fornecer soluções, serviços e tecnologias para os sistemas de informação críticos das empresas, respondendo às necessidades de clientes de diversos mercados, designadamente: Telecom, Media e Entretenimento, Sector Público, Indústria, Aeronáutica, Espaço, Defesa e Segurança, Finanças e Energia.

A Critical Software S.A. tem vindo a constitui-se como um fornecedor de soluções e tecnologias para empresas como a NASA, Agência Espacial Europeia, Siemens, Westland Helicopters, Vodafone, EADS, Astrium, TUV, Terma, Eumetsat, Chevron Texaco, VCS, Honeywell, entre outros.

A Qualidade é um elemento central da estratégia empresarial da Critical Software desde a sua fundação. Ao longo do tempo, o melhoramento contínuo dos processos de desenvolvimento do software de acordo com as normas ISO 15504, permitiu à empresa atingir um nível de maturidade ímpar a nível nacional, e certificar o seu sistema de gestão da qualidade (SGQ) de acordo com a norma ISO 9001:2000 segundo o referencial TickIT, sendo a única empresa Ibérica com esta certificação. A Critical é também a primeira empresa portuguesa em TI a obter a Certificação AQAP 2110 e AQAP 150, normas específicas da NATO para o desenvolvimento de software no domínio da Defesa. Alcançou também, recentemente, a certificação com o nível de Maturidade 3 do CMMI – modelo SE/SW, que inclui práticas de engenharia de software e de engenharia de sistemas, bem como a certificação EN9100

O crescimento da empresa, que se caracteriza pelo espírito jovem e inovador, tem sido muito rápido, um ano depois de ter iniciado as suas actividades no IPN11, abre uma subsidiária na Califórnia. Nos 4 anos seguintes, tem um crescimento na ordem de 80% por ano.

A Critical Software é, pelo 4º ano consecutivo, uma das 500 empresas com maior crescimento na Europa, e o seu sucesso está em trazer a qualidade e inovação para os seus clientes de uma maneira eficaz e eficiente, em tempo, em qualidade e em orçamento.

11 O Instituto Pedro Nunes ( IPN ) – Foi criado em 1991, resulta da Associação para a Inovação e Desenvolvimento em Ciência e Tecnologia , é uma instituição de utilidade pública e sem fins lucrativos, cujo o objectivo é de promover a inovação e a transferência de tecnologia

http://pt.wikipedia.org/wiki/1998

http://pt.wikipedia.org/wiki/Spin-off

http://pt.wikipedia.org/wiki/Instituto_Pedro_Nunes

http://pt.wikipedia.org/wiki/Coimbra

http://pt.wikipedia.org/wiki/Aeron%C3%A1utica

http://pt.wikipedia.org/wiki/NASA

http://pt.wikipedia.org/wiki/Ag%C3%AAncia_Espacial_Europeia

http://pt.wikipedia.org/wiki/Siemens_AG

http://pt.wikipedia.org/wiki/Vodafone

http://pt.wikipedia.org/wiki/EADS

http://pt.wikipedia.org/wiki/ChevronTexaco

http://pt.wikipedia.org/wiki/Honeywell

http://pt.wikipedia.org/wiki/ISO/IEC_15504

http://pt.wikipedia.org/wiki/Sistemas_de_Gest%C3%A3o_da_Qualidade

http://pt.wikipedia.org/wiki/ISO_9000

http://pt.wikipedia.org/wiki/Pen%C3%ADnsula_Ib%C3%A9rica

http://pt.wikipedia.org/wiki/Organiza%C3%A7%C3%A3o_do_Tratado_do_Atl%C3%A2ntico_Norte

http://pt.wikipedia.org/wiki/CMMI

gestão de configurações num processo de desenvolvimento de ... · níveis de qualidade, foram...

Documents