Uma abordagem para a gerência das modificações e da

Transcrição

INPE-14099-TDI/1078
UMA ABORDAGEM PARA A GERÊNCIA DAS MODIFICAÇÕES
E DA CONFIGURAÇÃO EM UM AMBIENTE INTEGRADO PARA
O DESENSOLVIMENTO E GESTÃO DE PROJETOS DE
SOFTWARE
Martha Adriana Dias Abdala
Dissertação de Mestrado do Curso de Pós-Graduação em Computação Aplicada,
orientada pelo Dr. Nilson Sant’Anna, aprovada em 29 de junho de 2004.
INPE
São José dos Campos
2006
681.3.06
Abdala, M. A. D.
Uma abordagem para a gerência das modificações e da
configuração em um ambiente integrado para o
desenvolvimento e gestão de projetos de software / M. A. D.
Abdalla. – São José dos Campos: Instituto Nacional de
Pesquisas Espaciais (INPE), 2004.
292 p.; - (INPE-14099-TDI/1078)
1.Gerenciamento da configuração. 2.Engenharia de
software. 3.Ambientes de engenharia de software.
4.Processos. 5.Modelos. I.Título.
“Mudar e mudar para melhor são duas coisas diferentes”.
Provérbio alemão.
A meus pais,
ANDRÉ MIGUEL ABDALA e
MARIA DAS DÔRES DIAS ABDALA.
AGRADECIMENTOS
Ao Senhor Jesus, o Autor da minha Fé: “Não tenho palavras para agradecer Tua
bondade... Nunca me deixes esquecer que tudo o que tenho, tudo o que sou, o que vier a
ser, vem de Ti, Senhor”. †
Ao meu orientador, Prof. Dr. Nilson SantÁnna, agradeço pela oportunidade
proporcionada e pelos conhecimentos transmitidos.
Aos meus colegas e amigos, em especial ao Carlos Lahoz e à Luciana Burgareli, pelas
discussões técnicas e também pelo apoio, incentivo e pela paciência que tiveram
comigo: muito obrigada.
Meus agradecimentos à equipe da SESIS, em especial à Roberta Panzera, e à estagiária
Juliana que, com suas contribuições no desenvolvimento do protótipo, enriqueceram
este trabalho.
Minha gratidão ao Instituto Nacional de Pesquisas Espaciais, INPE, aos seus
professores e ao Instituto de Aeronáutica e Espaço, IAE, pela oportunidade desta
realização profissional.
Finalmente, aos meus familiares minha gratidão pelo apoio recebido, sem o qual não
teria chegado até aqui.
†
Bessa, A. P. V., em “Nos braços do Pai”, IBL, 2002.
RESUMO
Organizações responsáveis pelo Programa Espacial Brasileiro, o INPE, Instituto
Nacional de Pesquisas Espaciais, e o IAE, Instituto de Aeronáutica e Espaço, vêm
procurando entender e melhorar os processos empregados no desenvolvimento de
software, de maneira a alcançar alta qualidade e confiabilidade nos produtos
desenvolvidos. No INPE, a necessidade da adoção de novos paradigmas baseados nos
processos de software levou à proposta de um ambiente integrado para o apoio ao
desenvolvimento e gestão de projetos de software para o controle de satélites. Dentre
estes processos, os da Gerência das Modificações e da Configuração de Software (GCS)
são aqueles que visam minimizar os problemas que as modificações trazem durante o
desenvolvimento e a manutenção do software, de maneira a garantir a integridade dos
produtos gerados. Este trabalho de dissertação de mestrado apresenta uma abordagem
utilizada para a definição e a modelagem dos processos da GCS para este ambiente
integrado. A modelagem dos processos da GCS e o suporte automatizado deste
ambiente apresentam-se como facilitadores para a definição e a efetiva implantação
destes naquelas organizações.
AN APPROACH TO THE CHANGE AND CONFIGURATION MANAGEMENT IN AN
INTEGRATED ENVIRONMENT FOR SOFTWARE PROJECTS DEVELOPMENT
AND MANAGEMENT
ABSTRACT
The National Institute for Space Research (INPE), and the Aeronautics and Space Institute
(IAE), organizations responsible for the Brazilian Space Program, are trying to understand
and improve the processes employed in software development, in order to obtain software
products that are reliable and of higher quality. At INPE, the necesssity to adopt new
paradigms based on software development processes led to a proposal of an integrated
environment to support the development and management of the satellite control software
project. Among the processes to be supported by the environment, the Software Change
and Configuration Management (SCM) processes are those which purpose is to minimize
the problems that changes cause during software development and maintenance, so that the
integrity of the generated products may be assured. This dissertation presents an approach
used to define and model the SCM processes to this process-centered integrated
environment. The process modeling and the automated support provided by this
environment are presented as the factors that will facilitate the definition and effective
implementation of the SCM process in those organizations.
SUMÁRIO
Pág.
LISTA DE FIGURAS .........................................................................................................
LISTA DE TABELAS .........................................................................................................
CAPÍTULO 1 – INTRODUÇÃO
............................................................................................ 25
1.1 – Objetivo............................................................................................................................ 27
1.2 – Motivação......................................................................................................................... 28
1.2.1 – As Modificações no Software ..................................................................................... 28
1.2.2 – A Utilização de Técnicas de Modelagem de Processo................................................. 29
..........................................
1.2.3 – A GCS e os Padrões e Modelos Qualidade ................................................................. 29
1.2.4 – A GCS no Ambiente Integrado e o Suporte ao Processo............................................. 30
...............................
1.2.5 – A GCS e o Desenvolvimento de Software no Setor Aeroespacial
Brasileiro...................................................................................................................... 31
1.3 – Esboço Geral................................................................................................................... 33
CAPÍTULO 2 – A GERÊNCIA DA CONFIGURAÇÃO DE SOFTWARE
......................
35
2.1 – A Natureza e Complexidade de um Produto de Software............................................... 35
2.2 – A Gerência da Configuração de Software - Definições e Atividades............................. 36
2.2.1 – As Atividades da GCS.................................................................................................. 39
2.2.1.1 – Implementação do Processo...................................................................................... 39
2.2.1.2 – Identificação da Configuração................................................................................... 41
2.2.1.3 – Controle da Configuração.......................................................................................... 41
2.2.1.4 – Relato da S ituação da Configuração......................................................................... 42
2.2.1.5 – Avaliação da Configuração....................................................................................... 42
2.2.1.6 – Gerenciamento da Liberação e Entrega..................................................................... 43
2.3 – Conceitos Básicos da GCS.............................................................................................. 44
2.3.1 – Item de Configuração de So ftware............................................................................... 44
2.3.2 – Configuração- base........................................................................................................ 46
2.3.3 – Desenvolvimento de Software Baseado em Configuração- base.................................. 47
2.3.4 – Distribuições................................................................................................................. 51
2.3.5 – Informações Sobre os Itens de Configuração: Metadados........................................... 51
2.3.6 – Repositórios e Bibliotecas de Software........................................................................ 55
2.3.7 – Controle de Versões..................................................................................................... 57
2.3.8 – Linhas de Desenvolvimento......................................................................................... 59
2.3.9 – Variantes e Desenvolvimento Paralelo......................................................................... 60
2.3.10 – Operações de Acesso às Versões no Repositório....................................................... 62
2.3.11 – Agregações................................................................................................................. 62
2.4 – Breve Histórico da Gerência da Configuração de Software............................................ 63
2.5 – Áreas de Funcionalidade da GCS.................................................................................... 66
2.6 – A GCS e os Requisitos do Projeto................................................................................... 69
2.7 – Políticas e Modelos da GCS............................................................................................ 69
2.7.1 –Política de Check In/Check Out..........................................................……………….. 71
2.7.2 – Política de Composição................................................................................................ 72
2.8 – Mecanismos da GCS....................................................................................................... 73
2.9 – O Estado Atual da GCS................................................................................................... 73
2.10 – As Ferramentas de GCS................................................................................................ 75
CAPÍTULO 3 – MODELAGEM, PADRÕES E AMBIENTES CENTRADOS EM
PROCESSO DE SOFTWARE
.................................................................... 79
3.1 – Processos de Software, Modelos de Processos e Ambientes Centrados em Processos.. 81
3.2 – A Técnica de Modelagem de Processos.......................................................................... 84
3.2.1 – Elementos de um Processo de Software....................................................................... 84
3.2.2 – As Linguagens de Modelagem de Processos............................................................... 86
3.2.3 – Os propósitos das PMLs............................................................................................... 87
3.2.4 – Abordagens para a Modelagem de Processos.............................................................. 88
3.3 – A Linguagem de Modelagem de Processo SPEM........................................................... 89
3.3.1 – Arquitetura da Modelagem........................................................................................... 90
3.3.2 – Elementos da Linguagem SPEM.................................................................................. 91
3.3.3 – A notação SPEM.......................................................................................................... 93
3.4 – Padrões de Processos de Software e Modelos de Maturidade......................................... 96
3.4.1 – A Gerência da Configuração de Software em Padrões e Modelos de Maturidade...... 98
3.4.1.1 – A GCS e o Padrão ISO/IEC 12207........................................................................... 99
3.4.1.2 – A GCS no Modelo ISO/IEC 15504........................................................................... 99
3.4.1.3 – A Maturidade da GCS............................................................................................... 104
3.5 – O Ambiente Integrado para Apoio ao Desenvolvimento e Gestão de Projetos de
Software........................................................................................................................... 106
3.5.1 – Definições e Conceitos................................................................................................. 106
3.5.2 – Caracterização do Ambiente Integrado........................................................................ 107
3.5.3 – Arquitetura Lógica do Ambiente.................................................................................. 107
3.5.4 – A Arquitetura Física..................................................................................................... 109
3.5.5 – Ciclo de Vida do Processo no Ambiente...................................................................... 109
3.5.5.1 – A Fase de Planejamento do Processo........................................................................ 110
3.5.5.2 – A Fase de Execução do Processo.............................................................................. 112
3.5.5.3 – A Fase de Avaliação do Processo.............................................................................. 114
3.5.6 – O Serviço de Coordenação de Processos de Software................................................. 114
3.5.7 – As Gerências no Ambiente integrado........................................................................... 115
3.5.8 – Os Requisitos para a Gerência das Modificações e da Configuração no Ambiente
Integrado...................................................................................................................... 116
CAPÍTULO 4 – A
MODELAGEM
DO
PROCESSO
DA
GERÊNCIA
DAS
MODIFICAÇÕES E DA CONFIGURAÇÃO
............................................ 117
4.1 – Histórico e Desenvolvimento do Trabalho...................................................................... 118
4.2 – O Escopo do Processo da GCS........................................................................................ 120
4.3 – Estratégias para a Definição e Modelagem do Processo da GCS................................... 121
4.4 – A Modelagem do Processo da GCS................................................................................ 122
4.4.1 – Papéis e Responsabilidades no Processo da GCS........................................................ 123
4.4.2 – As Atividades do Processo da GCS............................................................................. 126
4.4.3 – Os Produtos do Processo da GCS................................................................................. 128
4.4.4 – O Processo de Definição das Estratégias Organizacionais da GCS............................. 131
4.4.4.1 – Objetivos e Requisitos Básicos do Processo............................................................. 132
4.4.4.2 – Papéis, Responsabilidades e Produtos Envolvidos no Processo............................... 134
4.4.4.3 – Atividades do Processo............................................................................................. 135
4.4.5 – O Processo de Planejamento da GCS........................................................................... 141
4.4.5.3.1 – O Pacote Definição do Gerenciamento e Relações com o Ambiente de Projeto... 147
4.4.5.3.2 – O Pacote Descrição das Atividades da GCS.......................................................... 150
4.4.5.3.3 – O Pacote Definição da Condução das Tarefas, Fases e Marcos da GCS............... 154
4.4.5.3.4 – O Pacote Descrição de Ferramentas, Técnicas e Métodos..................................... 156
4.4.5.3.5 – O Pacote Definição de Linhas de Desenvolvimento Paralelo................................ 159
4.4.5.3.6 – O Pacote Definição do Ambiente da GCS............................................................. 160
4.4.6 – O Processo de Gerenciamento da Configuração.......................................................... 162
4.4.6.3.1 – O Pacote Identificação da Configuração................................................................ 172
4.4.6.3.2 – O Pacote Armazenamento e Controle dos Itens de Configuração......................... 175
4.4.6.3.2.1 – A Definição de Trabalho Armazenar Item de Configuração para Produção...... 177
4.4.6.3.2.2 – A Definição de Trabalho Liberar It em de Configuração para Produção............ 180
4.4.6.3.2.3 – A Definição de Trabalho Liberar Item de Configuração para Utilização........... 181
4.4.6.3.3 – O Pacote Relato da Situação da Configuração....................................................... 185
4.4.7 – O Processo Gerenciamento das Solicitações de Modificação...................................... 188
4.4.7.2 – Papéis, Re sponsabilidades e Produtos Envolvidos no Processo............................... 191
4.4.7.3.1 – Atividade Identificar e Registrar a Solicitação de Modificação............................. 196
4.4.7.3.2 – Atividade Avaliar Impacto da Modificação........................................................... 198
4.4.7.3.3 – Atividade Identificar Atividades de Verificação/Validação.................................. 199
4.4.7.3.4 – Atividade Aprovar Modificação............................................................................. 199
4.4.7.3.5 – Atividade Agendar Modificação............................................................................ 199
4.4.7.3.6 – Atividade Desenvolver Produto............................................................................. 201
4.4.7.3.7 – Atividade Avaliar Produto de Trabalho................................................................. 201
4.4.7.3.8 – Atividade Revisar Modificação Implementada...................................................... 201
4.4.7.3.9 – Atividade Relatar Situação das Modificações........................................................ 202
CAPÍTULO 5 – O SUPORTE AUTOMATIZADO AO PROCESSO DA GERÊNCIA
DAS MODIFICAÇÕES E DA CONFIGURAÇÃO................................... 203
5.1 – Os Requisitos para a GCS no Ambiente Integrado......................................................... 204
5.1.1 – Gerenciamento do Processo da GCS............................................................................ 204
5.1.2 – Desenvolvimento de Software Baseado em Configurações- base................................ 206
5.1.3 – Suporte ao ciclo de vida do item de configuração........................................................ 206
5.1.4 – Suporte ao controle de versões..................................................................................... 207
5.1.4.1 – Biblioteca da GCS..................................................................................................... 207
5.1.4.2 – Política Check- in/Checkout e Composição............................................................... 207
5.1.5 – Política de Liberação.................................................................................................... 208
5.1.6 – Suporte ao Ciclo de Vida de uma Solicitação de Modificação.................................... 208
5.1.7 – Integração com a Garantia do Produto......................................................................... 208
5.2 – A Implementação do Protótipo Change and Configuration Management no Ambiente
Integrado.......................................................................................................................... 209
5.2.1 – Os Requisitos do Protótipo........................................................................................... 210
5.2.1.1 – Definir Estratégias da GCS....................................................................................... 211
5.2.1.2 – Planejar a GCS.......................................................................................................... 211
5.2.1.3 – Gerenciar Configurações- base.................................................................................. 213
5.2.1.3.1 – Caso de Uso Descrever Item de Configuração....................................................... 215
5.2.1.3.2 – Caso de Uso Criar Configurações- base.................................................................. 216
5.2.1.3.3 – Caso de Uso Liberar IC para Modificação............................................................. 216
5.2.1.3.4 – Caso de Uso Incorporar Modificações nas Configurações- base............................ 216
5.2.1.3.5 – Caso de Uso Obter IC para Utilização................................................................... 217
5.2.1.3.6 – Caso de Uso Obter Situação da Configuração e das Modificações....................... 217
5.2.1.3.7 – Registrar Distribuição de Configuração- base......................................................... 218
5.2.1.4 – Gerenciar Solicitações de Modificação..................................................................... 218
5.2.1.4.1 – Caso de Uso Abrir Solicitação de Modificação..................................................... 220
5.2.1.4.2 – Caso de Uso Avaliar Modificação.......................................................................... 221
5.2.1.4.3 – Caso de Uso Agendar Modificação........................................................................ 221
5.2.1.4.4 – Caso de Uso Registrar Implementação da Modificação........................................ 222
5.2.1.4.5 – Caso de Uso Registrar Verificação da Qualidade.................................................. 222
5.2.1.4.6 – Caso de Uso Revisar Modificação Implementada................................................. 222
5.3 – Os Recursos do Ambiente Necessários para os Processos.............................................. 223
5.3.1 – Os Recursos da Ca mada de Armazenamento e Acesso............................................... 223
5.3.2 – Os Recursos da Camada de Serviços........................................................................... 224
5.3.3 – Os Recursos da Camada de Interação com o Us uário.................................................. 229
CAPÍTULO 6 – CONCLUSÕES
231
6.1 – A modelagem de processos............................................................................................. 235
6.2 – Processo e melhoria de processo..................................................................................... 237
6.3 – Recomendações e Trabalhos futuros............................................................................... 237
REFERÊNCIAS BIBLIOGRÁFICAS
..................................................................................... 241
BIBLIOGRAFIA COMPLEMENTAR
................................................................................... 253
APÊNDICE A
A UTILIZAÇÃO DO SPEM NA MODELAGEM DE PROCESSOS 255
APÊNDICE B
EXERCÍCIO DE MODELAGEM - PROCESSO DE
GERENCIAMENTO DAS MODIFICAÇÕES
........................................... 261
APÊNDICE C
TELAS DO PROTÓTIPO CHANGE AND CONFIGURATION
MANAGEMENT........................................................................................ 265
LISTA DE FIGURAS
Pág.
2.1 – Atividades da GCS.......................................................................................................... 39
2.2 – Modelo de Desenvolvimento Genérico........................................................................... 47
2.3 – Visão Geral dos Metadados dos Itens de Configuração.................................................. 52
2.4 – Controle de Versões de um Arquivo............................................................................... 58
2.5 – Linhas de Desenvolvimento............................................................................................ 59
2.6 – Desenvolvimento Paralelo e União................................................................................. 61
2.7 – Agregações...................................................................................................................... 63
2.8 – Áreas de Funcionalidade da GCS.................................................................................... 68
2.9 – Check-out e Check-in....................................………………………………………….. 71
2.10 – A Política de Composição............................................................................................. 72
3.1 – Elementos e Relacionamentos de um Modelo de Processo............................................ 85
3.2 – Níveis de Capacidade e Atributos de Processo.............................................................. 105
3.3 – A Camada Conceitual do Ambiente e-WebProject......................................................... 108
3.4 – Arquitetura Três Camadas para Aplicações Web........................................................... 109
3.5 – Ciclo de Vida do Processo Auditar Produto.................................................................... 110
3.6 – Fase de Planejamento...................................................................................................... 111
3.7 – Os Estados de um Processo em Execução....................................................................... 113
4.1 – O Processo da GCS......................................................................................................... 126
4.2 – O Processo de Definição das Estratégias Organizacionais da GCS................................ 133
4.3 – O Gerente das Modificações e da Configuração e os Produtos do Processo de
Definição das Estratégias Organizacionais da GCS........................................................ 135
4.4 – O Processo de Planejamento da GCS.............................................................................. 144
4.5 – O Gerente das Modificações e da Configuração e os produtos do processo de
Planejamento da GCS...................................................................................................... 146
4.6 – O Pacote de Gerenciamento e Relações como o Ambiente de Projeto........................... 148
4.7 – O Pacote de Descrição das Atividades da GCS.............................................................. 151
4.8 – O Pacote de Definição da Condução das Tarefas, Fases e Marcos da GCS................... 155
4.9 – Pacote de Definição da Utilização de Ferramentas, Técnicas e Métodos....................... 157
4.10 – Pacote de Definição de Linhas de Desenvolvimento Paralelo....................................
159
4.11 – Pacote de Definição do Ambiente da GCS.................................................................
161
4.12 – O Processo Gerenciamento da Configuração................................................................ 165
4.13 – O Responsável pela GCS e os Produtos do Processo de Gerenciamento da
Configuração................................................................................................................. 168
4.14 – O Responsável pelo Produto e os Produtos do Processo de Gerenciamento da
Configuração................................................................................................................. 169
4.15 – Os Gerentes da Qualidade e Projeto e os Produtos do Processo de Gerenciamento da
Configuração................................................................................................................. 170
4.16 – O Cliente da GCS e os Produtos do Processo de Gerenciamento da
Configuração................................................................................................................. 171
4.17 – O Pacote de Identificação da Configuração.................................................................. 173
4.18 – A Definição de Trabalho do Armazenamento e Controle dos Itens de Configuração.. 177
4.19 – Diagrama de atividades da Definição de Trabalho de Armazenar Item de
Configuração para Produção......................................................................................... 179
4.20 – Diagrama de Atividades da Definição de Trabalho de Liberar Item de Configuração
para Produção................................................................................................................ 181
para Utilização Interna.................................................................................................. 182
para Utilização Interna.................................................................................................. 183
para Utilização Externa................................................................................................. 184
4.24 – O Pacote Relato da Situação da Configuração.............................................................. 186
4.25 – O Processo de Gerenciamento das Solicitações de Modificação.................................. 191
4.26 – O Responsável pela GCS e os Produtos do Processo de Gerenciamento das
Solicitações de Modificação.......................................................................................... 194
4.27 – O GCC e os Produtos do Processo de Gerenc iamento das Solicitações de
Modificação................................................................................................................... 195
4.28 – Diagrama de Atividades do Processo de Gerência das Solicitações de Modificação –
Avaliação e Aprovação de uma SM............................................................................... 197
4.29 – Diagrama de Atividades do Processo de Gerência das Solicitações de Modificação –
Encaminhamento para Implantação e Fechamento de SM........................................... 200
5.1 – Diagrama de Contexto do protótipo Change and Configuration Management.............. 210
5.2 – Diagrama de Casos de Uso da Definição das Estratégias da GCS.................................. 211
5.3 – Diagrama de Casos de Uso do Planejamento da GCS.................................................... 212
5.4 – Ciclo de Vida de um Item de Configuração.................................................................... 213
5.5 – Diagrama de Casos de Uso do Gerenciamento das Configurações-base........................ 215
5.6 – Ciclo de Vida de uma Solicitação de Modificação (SM)................................................ 219
5.7 – Diagrama de Casos de Uso do Gerenciamento das Solicitações de Modificação........... 220
A.1 – Comparação entre Fluxos de Trabalho.......................................................................... 259
C.1 – Tela de Trabalho do Usuário.......................................................................................... 266
C.2 – Tela de Acesso do Gerente das Modificações e da Configuração.................................. 267
C.3 – Tela Inicial das Atividades do Gerente das Modificações e da Configuração............... 268
C.4 – Tela de Convenção para Identificação Única para Documentos.................................... 269
C.5 – Tela de Convenções para Formação dos GCCs.............................................................. 270
C.6 – Tela Referente à Lista de Projetos Instanciados............................................................. 271
C.7 – Tela de Escolha de Membros para o GCC-Des.............................................................. 272
C.8 – Tela de Acesso dos Envolvidos com a GCS................................................................... 273
C.9 – Tela Inicial da Atividade de Gerenciamento das Solicitações de Modificação.............. 274
C.10 – Tela de Acompanhamento das SMs............................................................................. 275
C.11 – Tela de Abertura da SM................................................................................................ 276
C.12 – Tela de Acompanhamento das SM com o Status atualizado para “Aberta”................ 277
C.13 – Tela Inicial das Atividades do GCC............................................................................. 278
C.14 – Tela de Acompanhamento das SMs Encaminhadas para Avaliação............................ 279
C.15 – Tela de Avaliação da Modificação............................................................................... 280
C.16 – Tela de Acompanhamento das SM com o Status Atualizado para “Aprovada para
Implementação”............................................................................................................ 281
C.17 – Tela Inicial da Atividade de Agendar SM.................................................................... 282
C.18 – Tela da Atividade Agendar SM.................................................................................... 283
C.19 – Tela Inicial das Atividades do Cliente da GCS............................................................ 284
C.20 – Tela Inicial do Registro da Implementação da Modificação........................................ 285
C.21 – Tela da Atividade Registro da Implementação da Modificação................................... 286
C.22 – Tela Inicial do Registro da Aprovação da Modificação pela Qualidade...................... 287
C.23 – Tela da Atividade Registro da Aprovação pela Qualidade........................................... 288
C.24 – Tela Inicial do Fechamento da SM............................................................................... 289
C.25 – Tela de Fechamento da SM.......................................................................................... 290
C.26 – Registro de Histórico das Modificações....................................................................... 291
C.27 – Registro de Solicitação de Liberação........................................................................... 292
C.28 – Lista de Composição..................................................................................................... 292
LISTA DE TABELAS
Pág.
2.1 – Exemplos de Configuração-base................................................................................... 50
3.1 – Níveis de Abstração da Modelagem de Processos........................................................ 90
3.2 – Principais Ícones e Estereótipos do SPEM.................................................................... 95
3.3 – Categorias e Grupos de Processo do Padrão ISO/IEC 15504....................................... 101
4.1 – Papéis e Responsabilidades da GCS.............................................................................. 149
6.1 – A GCS nos Padrões e no Modelo Proposto................................................................... 233
CAPÍTULO 1
INTRODUÇÃO
Nos últimos 20 anos o software conquistou um papel essencial e crítico na sociedade, cada
vez mais dependente de sistemas computadorizados. Hoje em dia qualquer serviço ou
produto contém ou faz uso de algum software. À medida que mais e mais funcionalidades
são exigidas dos produtos de software estes se tornam mais complexos, aumentando assim
a dificuldade para desenvolvê-los e testá- los (Fuggeta, 2000).
O software pode ser ainda um elemento crítico dentro de um sistema maior. Um erro ou
defeito que venha a conter pode causar perdas não só financeiras, como também de vidas
humanas, como no caso de aplicações de software no controle de aeronaves, trens e metrô,
e também das aplicações aeroespaciais.
Diante disto, tem aumentado a preocupação dos pesquisadores e desenvolvedores em
entender e melhorar a qualidade do software produzido.Uma das principais direções
tomadas pela pesquisa na área de Engenharia de Software é aquela voltada para o estudo e
melhoria dos processos através dos quais o software é desenvolvido. Segundo essa
abordagem, há uma correlação direta entre a qualidade do processo empregado na
construção do software e a qualidade do produto resultante desse processo. A área de
pesquisa que trata destas questões é referenciada pelo termo processo de software
(Fuggetta, 2000).
A área de pesquisa em processo de software surgiu como disciplina ainda nos anos 80,
tendo sido apresentada em uma série de eventos e workshops. Desde então, muitos outros
eventos, publicações e instituições foram criados para tratar do assunto. Entres estas
instituições estão o Software Engeneering Institute (SEI), nos EUA, e o European Software
Institute (ESA), na Europa. Organismos internacionais de padronização também têm
centrado esforços no processo de software, como o International Organization for
Standardization/ International Electrotechnical Commission (ISO/IEC), com os padrões
25
12207 (atividades do ciclo de vida do software) (ISO/IEC 12207, 1995) e 15504
(determinação da capacidade de processo de software) (ISO/IEC 15504-2, 2003) derivado
do modelo de maturidade organizacional Software Process Improvement and Capability
dEtermination (SPICE) (SPICE, 1995).
No Brasil, nota-se nos últimos anos um interesse crescente pelo assunto por parte de
universidades, indústria e organizações governamentais, nos vários eventos de Engenharia
de Software e também em eventos realizados na área de processo de software, como o
SIMPROS, Simpósio Internacional de Melhoria de Processo de Software, um fórum para
intercâmbio de informações e conhecimento na prática de melhoria de processo de
software.
No Instituto Nacional de Pesquisas Espaciais (INPE), a necessidade da adoção desses
novos paradigmas para o desenvolvimento de software levou à proposta de um ambiente
integrado para o apoio ao desenvolvimento e para a gestão de projetos de software para
controle de satélites (Sant'Anna, 2000), que evoluiu para o e-Webproject® 1 , referenciado
neste trabalho como Ambiente ou Ambiente Integrado.
Esse Ambiente consiste de um conjunto integrado de ferramentas para apoiar as atividades
e tarefas do desenvolvimento e gestão do processo de construção de software. Utiliza a
abordagem de processos do modelo SPICE (atual ISO/IEC 15504) para o desenvolvimento
de projetos de software, integra todos os processos necessários de forma adequada à visão
de objetos e está organizado em áreas de negócio, proporcionando apoio eficiente à
gerência de projetos.
Entre as características do Ambiente, pode-se destacar: o trabalho cooperativo centrado no
processo; o conceito de ambiente ativo ou capacidade de forçar o fluxo de trabalho
(workflow); a integração das equipes de trabalho, a utilização de tecnologia para controle
1e-WebProject® é um produto registrado pela SESIS, Sistemas de Engenharia de Software, cujo desenvolvimento é apoiado pelo Programa de Capacitação de Recursos
Humanos (RHAE) do CNPq.
26
dos processos envolvidos no desenvolvimento de software; e a disponibilidade de um
conjunto de serviços oferecidos pela WEB/Internet para os vários participantes do processo
(desenvolvedores, gerentes, clientes), que podem trazer como benefícios a obtenção de
ganhos de produtividade e qualidade do software.
O Ambiente oferece suporte a categorias de gerenciamento estabelecidas pelo Project
Management Institute (PMI) (PMI, 1996), às quais foram acrescentadas outras para atender
melhor às necessidades específicas de projetos de software, como a Gerência das
Modificações e da Configuração de Software (GCS). Caberá ao Ambiente prover o apoio
necessário de maneira a que cada gerência desempenhe com sucesso suas atividades.
O processo de gerenciamento das modificações e da configuração, dentre os vários
processos empregados no desenvolvimento de software, é aquele que fornece as técnicas,
os métodos e procedimentos para manter a integridade do produto de software durante todo
seu ciclo de vida, através do controle sistemático de suas modificações e de seu
armazenamento controlado, bem como do relato da situação do produto a todos os
envolvidos no seu desenvolvimento. Essas atividades ajudam a eliminar inconsistências e
redundância de trabalho, aumentando assim a qualidade do produto e a produtividade dos
desenvolvedores.
1.1
Objetivo
Esta dissertação tem por objetivo apresentar uma abordagem para a definição e modelagem
do processo da Gerência da Configuração de Software para o Ambiente Integrado,
nomeado, neste ambiente, como Gerência das Modificações e da Configuração de
Software . Esta abordagem leva em consideração os processos da Gerência da Configuração
e das Solicitações de Modificação propostos nos padrões e modelos de processo (ISO/IEC
12207, 1995) e (ISO/IEC 15504-5, 2003) e em padrões específicos para a GCS (IEEE 828,
1998). Também são consideradas as funcionalidades da disciplina de Gerência da
Configuração de Software, descritas na literatura, como na abordagem prática apresentada
27
em (Hass, 2002) e as diretrizes propostas em (Sant'Anna, 2000), para definir e modelar os
processos e atividades essenciais desta Gerência que devem ser incorporados em uma
organização desenvolvedora de software de maneira a minimizar os problemas que surgem
durante o ciclo de vida de desenvolvimento do software devido às modificações.
Através do recurso da prototipação será possível apresentar a funcionalidade deste modelo
e ainda identificar os recursos do Ambiente necessários para apoiá- lo.
1.2
1.2.1
Motivação
As Modificações no Software
O software é mutável por natureza. Um produto de software passa por várias
transformações durante o seu ciclo de vida: parte de uma abstração ou idéia, até chegar a
ser código executável por uma máquina, que atenda ao propósito para o qual foi construído.
Modificações são, portanto, inerentes ao software, e inevitáveis em todo o seu ciclo de
desenvolvimento. Elas podem ocorrer também devido à correção de erros, à incorporação
de novas tecnologias e para atendimento a novos requisitos funcionais. Controlar as
modificações feitas no software é uma atividade crítica, pois modificação não gerenciada é,
sem dúvida, uma das causas de falha em entregar sistemas no tempo certo e dentro do
orçamento.
O gerenciamento da configuração, portanto, ajuda a proteger os investimentos no
desenvolvimento de software por meio do controle das modificações nele fe itas,
garantindo, por exemplo, que uma modificação errada possa ser revertida sem afetar a
integridade de todo o sistema. Também fornece uma estrutura básica para suporte a todo o
processo de engenharia de software através da configuração e controle dos subprodutos
deste processo, durante o desenvolvimento e após a entrega do produto. A GCS fornece as
técnicas, os métodos e os procedimentos para manter o histórico do produto, para
28
identificá- lo e localizar cada versão do produto, e controlar suas modificações. A GCS pode
ajudar, ainda, na coordenação e na comunicação entre os membros da equipe de
desenvolvedores, através do uso de um repositório comum de configurações e do suporte a
modificações (Van Brunt, 1996).
1.2.2
A GCS e os Padrões e Modelos de Qualidade
Dada a importância da GCS, padrões e modelos de processo de software, como o ISO/IEC
15504 e ISO/IEC 12207, exigem o controle das modificações nos produtos através do
gerenciamento da configuração. A GCS no Ambiente Integrado visa atender à necessidade
de se manter o controle sobre a configuração e sobre as modificações do produto de
software cujo desenvolvimento será apoiado pelo Ambiente, como recomendam estes
padrões e modelos de processo de software.
Segundo a abordagem proposta neste trabalho, um escopo mínimo para a GCS no
Ambiente Integrado pode ser definido pelas atividades e práticas básicas dos padrões de
processo que, se realizadas pelas organizações desenvolvedoras de software, resultam no
cumprimento dos propósitos da GCS e, conseqüentemente, contribuem para que melhores
níveis de qualidade dos produtos de software sejam obtidos nessas organizações.
Como nesses padrões as atividades e práticas básicas que a GCS deve realizar são
apresentadas em linhas gerais, ou seja, o padrão declara o que o processo deve fazer, e não
detalhes de como fazer para que o processo seja implantado, é preciso então definir o
processo da GCS, detalhar suas práticas básicas e descrever as maneiras como estas devem
ser implementadas.
1.2.3
A Utilização de Técnicas de Modelagem de Processo
Para os pesquisadores da área de processo de software, a principal causa dos problemas é
justamente a falta de um processo de desenvolvimento claramente definido e efetivo.
29
Entender e definir um processo de software não é tarefa trivial. A primeira contribuição da
área de pesquisa de processo de software foi justamente o aumento da percepção de que
desenvolver software é um processo complexo (Fuggeta, 2000). Por isso, sem uma
definição clara do processo, sua implantação efetiva pode ser comprometida.
Desta forma, a definição e a modelagem dos processos da GCS, tendo ainda o suporte
automatizado de um ambiente integrado para sua execução, apresentam-se como
facilitadores para a efetiva implantação destes em uma organização desenvolvedora de
software.
1.2.4
A GCS no Ambiente Integrado e o Suporte ao Processo
A GCS deve ser parte integrante de um ambiente completo de engenharia de software
(Sharon e Anderson, 1997). O Ambiente Integrado permite que as atividades de
manutenção da integridade do produto, como seu armazenamento controlado e o
acompanhamento das modificações, sejam integradas mais facilmente ao processo de
desenvolvimento e à cultura de uma organização. Outra vantagem de se ter a GCS
integrada ao Ambiente é a facilidade da utilização, por outras gerências, das informações
que ela fornece. Como exemplo, temos a informação da situação da configuração do
produto, que pode ser utilizada pela Gerência de Projeto para acompanhamento do
progresso de desenvolvimento do projeto.
A incorporação da idéia de suporte ao processo nas ferramentas e ambientes de
gerenciamento de configuração de software tem sido alvo de pesquisas nos últimos anos,
tendo surgido várias abordagens baseadas em atividades. O objetivo dessas abordagens é
fornecer capacidades de modelagem poderosas e mecanismos associados de maneira que os
usuários possam definir e controlar seus próprios processos de gerência de configuração
(Estublier, 2002; Estublier et al, 1997).
30
A GCS é uma das áreas da engenharia de software onde o suporte automatizado ao
processo provou ser crítico, tendo se tornado um dos maiores argumentos dos vendedores
de software e uma das maiores expectativas dos clientes (Estublier et al, 2002). Isto se deve
principalmente ao fato de que a maioria dos processos são repetitivos, prontos, assim, para
o suporte automatizado (Conradi e Westfechtel, 1999).
Antes do processo de GCS ser automatizado é necessário um entendimento completo dos
seus fundamentos e das políticas, procedimentos e instruções necessárias que são
adequadas para execução do processo (Starbuck, 1997).
Portanto, neste trabalho, procurou-se definir os processos e atividades essenciais da GCS,
baseadas nos padrões e modelos de processo, possibilitando assim a identificação dos
diferentes níveis de suporte automatizado que facilitam sua efetiva implantação em um
ambiente de desenvolvimento de software, como o Ambiente Integrado.
1.2.5
A GCS e o Desenvolvimento de Software no Setor Aeroespacial Brasileiro
Quando se tem um processo de desenvolvimento de software bem estabelecido, com
atividades agrupadas em fases, cujos produtos são bem definidos e documentados, a GCS
constitui-se na espinha dorsal sobre a qual essas fases são conduzidas e os produtos finais e
intermediários, controlados. No desenvolvimento de software comercial nacional,
entretanto, a realidade é um pouco diferente (Oliveira et. al., 2001).
Boa parte do software no Brasil é desenvolvida por pequenas empresas, que lutam contra a
escassez de recursos e deficiências tecnológicas para manter seus produtos no mercado.
Fases do desenvolvimento de software não são bem definidas; a codificação se mistura à
especificação e projeto do software. Testes, quando realizados, não são sistemáticos e
racionais. Isso tudo é refletido na documentação, quase sempre deficie nte e desatualizada
(Oliveira et. al., 2001).
31
No INPE, assim também como no Instituto de Aeronáutica e Espaço (IAE) esses problemas
têm sido combatidos com esforços para entender e melhorar o processo de desenvolvimento
de software que, no caso, pode ser crítico quanto à missão e à segurança.
No INPE, os sistemas de software para controle de satélites têm sido desenvolvidos com a
adoção de modelos e métodos de engenharia de software em seus projetos, de maneira a
alcançar alta qualidade e confiabilidade nos produtos desenvolvidos (SantÁnna, 2000). O
ambiente integrado para apoio ao desenvolvimento e gestão de projetos de software para
sistemas de controle de satélites tem sido desenvolvido justamente para apoiar o processo
de engenharia de software e consolidar os resultados obtidos. A GCS é um importante
aspecto da Engenharia de Software a ser contemplado pelo Ambiente.
No IAE, a preocupação com um processo de desenvolvimento de software existiu desde o
início do projeto do Software Aplicativo de Bordo (SOAB) do Veículo Lançador de
Satélites Brasileiro (VLS), devido à sua natureza crítica (Moura et. al., 1999). O padrão
adotado como referência para o desenvolvimento do SOAB, o DoD Std 2167A (DoD
2167A, 1988) tem no gerenciamento da configuração um dos seus destaques.
No desenvolvimento de software crítico quanto à segurança a GCS tem um papel ainda
mais importante, já que muitos acidentes reportados estão relacionados a falhas de software
(Kulkarni, 1996) que podem ocorrer devido a modificações em sistemas externos ou
subsistemas internos, ou como conseqüência não intencional de outras modificações. As
modificações no software devem, portanto, ser controladas e também ter seu impacto na
segurança avaliado (Leveson, 1995).
No caso do SOAB, por exemplo, as modificações são inevitáveis, já que o veículo lançador,
o sistema maior no qual o software se insere, está em desenvolvimento e, portanto, sujeito a
modificações em seus subsistemas, que acabam por se refletir no software. Assim, um
processo de gerência da configuração é essencial para que as modificações no software
32
possam ser feitas de maneira controlada, o que tem sido alvo de estudos da equipe
responsável pelo seu desenvolvimento (Moura et al, 2003).
Ainda que possa ser vista muitas vezes como um processo burocrático, que pode atrapalhar
ou inibir a criatividade dos desenvolvedores, principalmente em ambientes de pesquisa, a
GCS tem, no entanto, o objetivo de manter o controle sistemático e necessário sobre as
modificações, não o de inibi- las. A GCS não é a solução para todos os problemas do
software, mas uma disciplina que, envolvendo aspectos técnicos e gerenciais, se propõe a
minimizar os problemas que surgem durante o ciclo de vida de desenvolvimento do
software devido às modificações. É, portanto, um processo chave num ambiente de
desenvolvimento
de
software
de
qualidade,
como
no
caso
das
organizações
desenvolvedoras de software na área aeroespacial.
1.3
Esboço Geral
Este trabalho foi dividido em outros seis capítulos, apresentados a seguir:
•
CAPÍTULO 2 – A GERÊNCIA DA CONFIGURAÇÃO DE SOFTWARE : Este
Capítulo apresenta os fundamentos desta disciplina, bem como seus vários aspectos
considerados para elaboração da abordagem proposta.
•
CAPÍTULO 3 – MODELAGEM, PADRÕES E AMBIENTES CENTRADOS EM
PROCESSO DE SOFTWARE : Apresentam-se neste Capítulo os fundamentos
teóricos para a abordagem proposta na dissertação, como modelos e padrões de
qualidade, processos de software, ambientes centrados em processos de software e o
ambiente integrado para o desenvolvimento e gestão de projetos de software.
•
CAPÍTULO 4 – A MODELAGEM DO PROCESSO DA GERÊNCIA DAS
MODIFICAÇÕES E DA CONFIGURAÇÃO: Neste Capítulo mostra-se a definição e
33
a modelagem do processo da Gerência das Modificações e da Configuração para o
Ambiente Integrado.
•
CAPÍTULO 5 – O SUPORTE AUTOMATIZADO AO PROCESSO DA GERÊNCIA
DAS MODIFICAÇÕES E DA CONFIGURAÇÃO: Neste Capítulo são feitas
algumas considerações sobre as funcionalidades da GCS que o Ambiente deve
prover para que o processo modelado seja implantado de maneira a alcançar seus
objetivos. Um protótipo de aplicação é apresentado para ilustrar algumas destas
funcionalidades e possibilidades de automação de partes do processo, como o
gerenciamento das solicitações de modificação. Os recursos necessários para a
implementação do processo da GCS no Ambiente são também apresentados.
•
CAPÍTULO 6 - CONCLUSÕES: Este Capítulo apresenta as conclusões do trabalho
e sugestões de trabalhos futuros.
Feita, pois, esta abordagem introdutória, passa-se à apresentação dos principais
fundamentos da GCS e dos aspectos mais relevantes para este trabalho de pesquisa e sua
conseqüente proposta.
34
CAPÍTULO 2
A GERÊNCIA DA CONFIGURAÇÃO DE SOFTWARE
A Gerência da Configuração de Software (GCS) é uma disciplina abrangente. Vários
aspectos e funcionalidades desta disciplina têm sido explorados sob os mais diferentes
enfoques, tanto na literatura da Enge nharia de Software, em padrões e artigos
especializados, quanto em aplicações e ferramentas de software gratuitas e comerciais.
O conhecimento dos fundamentos da disciplina é essencial para que o processo da GCS
seja definido e descrito, como é feito adiante no Capítulo 4, de maneira que possa ser
implantado em uma organização.
Neste capítulo são apresentados alguns conceitos e definições da GCS, encontrados na
literatura da Engenharia de Software e em padrões, e outros assuntos relacionados,
coletados durante a pesquisa e utilizados no desenvolvimento deste trabalho, iniciandose com um entendimento da natureza e da complexidade de um produto de software.
2.1
A Natureza e Complexidade de um Produto de Software
Um produto de software, diferentemente do hardware no qual é executado, não é uma
entidade física e tangível. É mais complexo, mais fácil de ser modificado e, por
conseguinte, capaz de mais facilmente propagar os efeitos das modificações (Futrell et
al, 2002).
Um produto de software torna-se visível através dos vários modelos abstratos que
representam sua estrutura, sua funcionalidade e seus relacionamentos com o mundo
real, que formam a documentação do produto. Esta documentação torna-se a base para o
desenvolvimento e manutenção de um produto de software e, devido à sua importância,
é muitas vezes considerada parte do próprio software.
Um produto de software pode ser decomposto em vários níveis de hierarquia, como por
exemplo: sistema, subsistemas e componentes. Esta decomposição ajuda a diminuir a
35
comp lexidade, facilita tanto a divisão do trabalho dos desenvolvedores como a
manutenção, permitindo melhor restringir as modificações a partes do sistema.
Um produto de software pode sofrer modificações por vários motivos. O National
Institute of Standards and Technology (NIST) dos EUA, afirma que o software é
modificado para sua adaptação, aperfeiçoamento ou correção (Futrell et al, 2002).
Existe uma relação de dependência entre os componentes de um produto de software.
Modificações feitas na especificação afetam a implementação; modificações em um
subsistema afetam seus componentes, e assim por diante.
O fato de o produto de software ser facilmente modificável lhe confere bastante
flexibilidade, mas adiciona também complexidade ao gerenciamento de sua integridade.
Além disto, o desenvolvimento do produto de software envolve várias pessoas, como
desenvolvedores, gerentes, etc. Quanto mais pessoas estiverem envolvidas no projeto,
mais difícil se tornam a comunicação entre elas e a coordenação de suas atividades.
É necessária, portanto, uma abordagem disciplinada para tratar destas questões: a
Gerência da Configuração de Software - GCS.
2.2
A Gerência da Configuração de Software – Definições e Atividades
Várias definições para a Gerência da Configuração de Software podem ser encontradas
na literatura da Engenharia de Software e de padrões relacionados.
A GCS é definida por (Bersoff et al., 1980) como a disciplina de identificação da
configuração de um sistema, em pontos distintos no tempo, com o propósito de
controlar sistematicamente as modificações na configuração e manter a integridade e a
rastreabilidade da configuração durante todo o ciclo de vida do sistema.
Segundo (Sommerville, 2001), o gerenciamento da configuração de software constituise na aplicação e criação de padrões e procedimentos para o gerenciamento de um
produto de software em desenvolvimento.
36
Segundo (Pressman, 2001), a GCS é um conjunto de atividades projetadas para:
controlar as modificações, através da identificação dos produtos de trabalho que
provavelmente serão modificados; estabelecer relacionamentos entre eles; definir
mecanismos para gerenciar diferentes versões desses produtos de trabalho; controlar as
modificações impostas; e realizar auditorias e relatar as modificações feitas.
Vários padrões internacionais tratam do processo de desenvolvimento de software e,
conseqüentemente, da Gerência da Configuração. Para o padrão ISO/IEC 12207
(ISO/IEC12207, 1995) o processo da GCS é aquele que aplica procedimentos técnicos e
administrativos para suportar o ciclo de vida do software para: identificar e definir itens
de software em um sistema; controlar modificações e liberações dos itens; registrar e
informar a situação dos itens e solicitações de modificação; garantir a integridade,
consistência e correção dos itens; e controlar o armazenamento, o manuseio e a entrega
dos itens.
Vários padrões internacionais estão relacionados diretamente à Gerência da
Configuração. Uma visão geral destes pode ser obtida em (Hass, 2002). Um dos mais
utilizados e conhecidos é o padrão IEEE Std 828 (IEEE 828, 1998), que define a GCS
como a disciplina que fornece os métodos e ferramentas para identificar e controlar o
software durante todo o seu desenvolvimento e utilização.
Todos os padrões e modelos de maturidade para desenvolvimento de software incluem
requisitos para gerenciamento da configuração, apesar desses requisitos variarem de
modelo para modelo.
O CMMI-SW Versão 1.1 (CMMI-SW, 2002) afirma que o propósito da GCS é
estabelecer e manter a integridade dos produtos de trabalho usando a identificação da
configuração, o controle da configuração, o relato da situação da configuração e as
auditorias da configuração.
O padrão ISO/IEC 15504-5 (ISO/IEC 15504-5, 2003) na sua mais recente versão
Committed Draft (CD) de Outubro de 2003 apresenta um grupo de processos
denominado Grupo de Controle de Configuração, onde as atividades de gerenciamento
37
da configuração e de modificações estão agrupadas nos processos de Gerência da
Configuração e Gerência das Solicitações de Modificação. Segundo este padrão, o
propósito da Gerência da Configuração é estabelecer e manter a integridade de todos os
produtos de trabalho de um processo ou projeto e torná- los disponíveis às partes
envolvidas. A Gerência das Solicitações de Modificação tem o propósito de garantir que
as solicitações de modificação sejam gerenciadas, acompanhadas e controladas.
Com relação às áreas de atividades da GCS, encontram-se relacionadas no padrão IEEE
610.12 (IEEE 610.12, 1990) as seguintes: identificação, controle, relato da situação,
auditoria e revisão (Dart, 2000). O padrão IEEE 828 (IEEE 828, 1998), acrescenta a
essas as atividades de controle de interface e controle de subcontratante/vendedor. Dart
(Dart, 1991) considera também como atividades da GCS a construção, o gerenciamento
do processo e o trabalho em equipe, que são tarefas mais específicas para software.
Abordagens encontradas na Engenharia de Software apresentam como atividades
principais da Gerência da Configuração o planejamento da GCS, a gerência de
modificação, a gerência de versão e liberação (release) e a construção de sistemas
(Sommerville, 2001).
Em (Hass, 2002) é apresentada uma visão da GCS orientada a processo, que inclui as
áreas de atividade: identificação, armazenamento, controle de modificação e relato da
situação. Segundo essa abordagem, a área de atividade de auditoria não é considerada
parte da GCS, mas sim da Garantia da Qualidade, já que utiliza suas técnicas e métodos,
como revisões e testes. Ainda segundo a autora, a auditoria é um legado da origem
militar (Departamento de Defesa norte-americano) da GCS. Na prática, no entanto, a
auditoria pode envolver os responsáveis pela GCS.
Como visto, a caracterização das atividades da GCS não é uniforme na literatura,
embora exista um certo consenso em relação à definição do ISO/IEC 12207 (ISO/IEC
12207, 1995), que também é a visão adotada pelo Guide to the Software Engineering
Body of Knowledge (SWEBOK, projeto iniciado em 1998, por representantes da
indústria, agências de pesquisa e do IEEE, entre outros, para fornecer uma
38
caracterização dos limites da disciplina da Engenharia de Software e um acesso tópico
ao corpo de conhecimento que suporta esta disciplina) (IEEE SWEBOK, 2001).
2.2.1
As Atividades da GCS
Segundo o padrão ISO/IEC 12207 (ISO/IEC 12207, 1995) são consideradas atividades
principais da GCS: a implementação do processo, a identificação da configuração, o
controle da configuração, o relato da situação da configuração, a avaliação da
configuração e o gerenciamento da liberação e entrega.
Estas atividades (Figura 2.1) são aplicáveis a qualquer projeto de software, ainda que,
dependendo da implementação da GCS e das características do projeto, possam aparecer
de maneira um pouco diferente da apresentada.
Tem-se, nas seções seguintes, a descrição sucinta das atividades da GCS.
Implementação do
processo
Controle
Relato da
Situação
Avaliação
Gerenciamento da
Liberação e
Entrega
Identificação
FIGURA 2.1 – Atividades da GCS.
FONTE: Adaptada de (IEEE SWEBOK,
2001, p. 7-2).
2.2.1.1
Implementação do Processo
A implementação do processo da GCS baseia-se no desenvolvimento de um Plano de
Gerência de Configuração de Software (PGCS), onde são descritas as atividades
relacionadas à implantação e administração do processo. Este plano deve conter também
os procedimentos e o planejamento de execução destas atividades, os responsáveis por
39
elas e os recursos necessários. O plano deve refletir as particularidades de cada projeto,
dependendo das metas e soluções específicas a cada ambiente. O PGCS deve ser
documentado e implementado (ISO/IEC 12207, 1995).
O PGCS é o primeiro passo para estabelecer um bom gerenciamento da configuração,
quando se inicia um novo projeto de desenvolvimento de software, pois permite que as
tarefas da GCS sejam conhecidas de antemão, fornecendo as bases para a sua execução
(Bounds e Dart, 1993).
O PGCS pode ser criado a partir de uma orientação já existente, como o padrão IEEE
828 (IEEE 828, 1998) para Planos de Gerência de Configuração, que apresenta, no seu
Anexo B, diretrizes de conformidade com o padrão ISO/IEC 12207. Esse padrão pode
ser utilizado em conjunto com o Guia para a Gerência da Configuração de Software
(ANSI/IEEE 1042, 1987), que mostra uma visão de vários fatores que devem ser
considerados no planejamento da gerência da configuração e apresenta em seus anexos
vários exemplos de planos, para diferentes tipos de projeto e organizações. Esses
exemplos fornecem uma interpretação de como o padrão IEEE 828 pode ser utilizado
para o planejamento de diferentes tipos de desenvolvimento de software e atividades de
manutenção.
Na elaboração do PGCS é importante levar em consideração a experiência dos membros
da equipe de desenvolvimento. O responsável pela elaboração do plano deve questionar
membros-chave da equipe de desenvolvimento (gerente de projeto, arquiteto de
software, líder de desenvolvimento, responsável pelos testes). Assim poderá obter uma
percepção da abordagem da equipe de desenvolvimento de software, com relação, por
exemplo, a regras para identificação e nomenclatura dos itens de configuração ou
necessidades específicas do processo de controle de modificações (Sayko, 2003).
40
2.2.1.2
Identificação da Configuração
A identificação é um dos fundamentos da GCS, já que é impossível controlar algo cuja
identidade se desconhece. Esta atividade visa estabelecer um esquema para
identificação dos itens de software e suas versões a serem controladas.
O passo inicial desta atividade é a escolha dos itens que serão gerenciados. Devem-se
determinar as informações associadas a um item de configuração, que possam
identificá- lo de maneira única e especificar seus relacionamentos com o mundo exterior
e outros itens de configuração. A especificação dos relacionamentos é importante para a
manutenção, pois permite a rápida localização dos itens afetados em cada modificação.
Um esquema de identificação única consiste na atribuição de nomes exclusivos a cada
um dos componentes, para que seja possível reconhecer a evolução de suas versões e a
hierarquia existente entre elas, a partir de seus nomes. Para cada item e suas versões,
devem ser identificados: a documentação que estabelece a configuração-base (baseline),
as referências de versão e outros detalhes de identificação.
2.2.1.3
Controle da Configuração
Dois tipos de controle básicos estão incluídos no processo da GCS: o das modificações
e o das versões dos itens de configuração. O controle das modificações deve ser
implantado somente após uma configuração-base ter sido estabelecida. Este controle
consiste na identificação e registro das solicitações de modificações; análise e avaliação
das modificações; aprovação ou desaprovação da solicitação; e implementação,
verificação e distribuição (release) do item de software modificado. Deve existir um
procedimento de registro do motivo e autorização para a modificação.
O controle das versões consiste em controlar a criação e utilização das várias versões
dos itens de configuração, configurações-base e distribuições, que devem estar
armazenadas e identificadas convenientemente.
41
2.2.1.4
Relato da Situação da Configuração
O objetivo desta atividade é relatar informações das modificações às pessoas envolvidas
no desenvolvimento e na manutenção do software. Estas informações são relativas ao
que foi modificado, por quem e quando, e também o que foi afetado pela modificação.
Esta atividade consiste em gerenciar o registro e os relatórios da situação da
configuração, que mostram o estado e o histórico de itens controlados, incluindo as
configurações-base. Os relatórios de situação podem incluir o número de modificações
de um projeto, as últimas versões de itens de configuração, identificadores de
distribuições, o número de distribuições, e comparações entre as distribuições.
O registro das ocorrências na GCS é feito em uma base de dados que deve estar
disponível aos desenvolvedores, com acesso controlado por senhas. A partir dela são
emitidos os relatórios da GCS, que permitem uma melhor comunicação entre os
integrantes da equipe, agilizam o processo de desenvolvimento e eliminam problemas
relativos a modificações feitas no mesmo item com intenções diferentes e conflitantes
(Rocha et. al., 2001).
2.2.1.5
Avaliação da Configuração
Esta atividade consiste em determinar e garantir a funcionalidade dos itens de software
em relação aos seus requisitos e à integridade física dos itens de software (se seu projeto
e código refletem uma descrição técnica atual). Existem dois tipos de avaliações: a
funcional e a física.
A avaliação funcional compreende uma verificação técnica formal na configuração de
software, ou seja, preocupa-se com os aspectos internos dos arquivos. Esta verificação é
uma atividade do controle da qualidade que tenta descobrir omissões ou erros na
configuração que degradam os padrões de construção do software (Rocha et. al., 2001).
A avaliação física é um processo administrativo da qualidade que ocorre ao final de
cada fase do ciclo de vida do software e consiste em verificar se a configuração que será
estabelecida em uma configuração-base é composta pelos itens corretos, que foram
42
determinados para a fase específica do ciclo de vida, nas versões corretas. Esta
avaliação também verifica se os procedimentos e padrões que foram definidos foram
devidamente aplicados (Rocha et. al., 2001).
2.2.1.6
Gerenciamento da Liberação e Entrega
Esta atividade consiste em controlar formalmente a liberação e a entrega dos produtos
de software, ou seja, das configurações-base e distribuições. Ela envolve a decisão sobre
quando a distribuição deve ser feita, os procedimentos para a sua criação e sua
documentação (Sommerville, 2001; van der Hoek et. al., 1997).
Configurações-base internas são geradas a partir das necessidades dos desenvolvedores
e responsáveis por testes e são criadas, quando necessárias, segundo critérios técnicos.
As decisões sobre quando as distribuições (configurações-base de produto liberadas
para utilização fora da organização de desenvolvimento) são criadas devem ser
governadas por considerações técnicas e organizacionais, e envolvem fatores como
qualidade técnica da distribuição, adição significativa de novas funcionalidades,
competitividade do produto, propostas de modificações dos clientes, etc.
A criação das distribuições consiste na coleta dos arquivos e da documentação que as
compõem. O código executável dos programas e todos os arquivos de dados devem ser
coletados e identificados. Instruções necessárias para instalação e configuração devem
ser incluídas na distribuição. Finalmente, uma distribuição é colocada em um meio
físico para ser entregue.
A documentação da distribuição consiste de uma descrição do conteúdo de cada
distribuição, das versões dos componentes e do sistema operacional, compiladores e
outras ferramentas utilizadas para construir o software, bem como de arquivos de dados
e de configuração. Informações sobre a data em que foi entregue e para quem foi
entregue também devem ser mantidas.
43
Cópias do código e da documentação entregues devem ser mantidas por toda a vida do
produto de software. O código e a documentação que contiverem funções críticas
quanto à segurança ou confidenciais deverão ser tratados conforme políticas da
organização para tais casos.
2.3
Conceitos Básicos da GCS
As definições da GCS apresentadas incluem uma terminologia própria e ainda alguns
conceitos fundamentais, necessários para uma melhor compreensão das atividades da
GCS. Estes conceitos são apresentados nas seções seguintes.
2.3.1
Item de Configuração de Software
Item de configuração é um conceito fundamental do gerenciamento da configuração que
possui diversas interpretações.
Segundo o padrão IEEE 610.12 (IEEE 610.12, 1990) um item de configuração de
software é uma agregação de software designada para o gerenciamento da configuração
e tratada como uma entidade única no processo da GCS, isto é, um item de configuração
é uma unidade funcional que possui um ciclo de desenvolvimento e acompanha mento
próprios da GCS. Um sistema em desenvolvimento é particionado em itens de
configuração, que são particionados em outros conjuntos de itens, até que se obtenha
um conjunto de itens não particionáveis, que são desenvolvidos segundo um ciclo de
vida definido. A configuração do sistema de software é, assim, o conjunto das
configurações dos Itens de Configuração de Software (ICSWs) integrantes do sistema.
O padrão ISO/IEC 12207 (ISO/IEC 12207, 1995) diferencia itens de configuração e
itens de software. O processo da Gerência da Configuração se aplica a ambos os
elementos, mas, para os itens de configuração de software: (1) o tempo em que eles são
estabelecidos pode ser muito mais tarde no projeto; (2) a formalidade de identificação,
controle, relato da situação e avaliação pode ser muito mais rígida; e (3) o processo de
44
aprovação para modificar pode ser mais restritivo. De acordo com este padrão, os itens
de configuração de software deverão ser estabelecidos antes da integração de sistema.
Uma outra definição caracteriza um item de configuração como qualquer parte do
desenvolvimento ou entrega de um sistema ou produto que precisa ser identificado,
produzido, armazenado, utilizado e modificado individualmente (Hass, 2002).
Durante todo o ciclo de vida de um produto de software, existem elementos ou itens que
fazem parte dele e outros que são usados para suportar o seu desenvolvimento e
manutenção. Estes itens podem ser classificados em diferentes tipos, dependendo do
ponto de vista.
Sob a visão de produto, os itens colocados sob gerenciamento da configuração são,
tipicamente, arquivos de cabeçalho, arquivos do tipo include, arquivos de código fonte e
bibliotecas de sistema. Tipos derivados destes, como arquivos objetos e executáveis,
que também podem ser gerenciados, quando a rapidez para a entrega, por exemplo, é
um fator levado em consideração. Ainda sob a visão do produto podem-se considerar
itens de dados, como valores de parâmetros; serviços, como descrições de
procedimentos ou material de treinamento; e ferramentas utilizadas na produção dos
itens de software, como editores de texto, ferramentas de desenho, compiladores, banco
de dados, entre outros.
Sob a visão de projeto, a cada fase do ciclo de vida, e a cada atividade, itens são gerados
e podem ser colocados sob o gerenciamento da configuração. Estes itens podem ou não
ser entregues ao cliente. São exemplos de itens obtidos nas diferentes fases do ciclo de
vida:
•
Preparação: contratos, requisitos do usuário, plano de trabalho, etc.
•
Especificação de Requisitos: requisitos de software, protótipos, cenários, etc.
•
Projeto: especificação de projeto de arquitetura, especificação de projeto
detalhada, desenhos, diagramas, notas técnicas, etc.
45
•
Testes: drivers, stubs, dados de testes, especificações e procedimentos de testes,
relatórios de testes, etc.
•
Operação e Manutenção: procedimentos de instalação, procedimentos de
implantação, etc.
Um item de configuração é, portanto, considerado neste trabalho, como qualquer item
produzido ou utilizado durante o ciclo de vida do produto de software, como os
relacionados acima, que foi selecionado para estar sob o controle da GCS.
Um item de configuração pode variar em complexidade desde um item individual ou
atômico (não existem partes que podem ser variadas independentemente, sem modificar
o item como um todo) a uma coleção de outros itens, chamadas agregações ou
configurações (existem várias partes variáveis independentemente ou substituíveis, que
são atômicas ou outras configurações), que são também, por sua vez, colocados sob
gerenciamento da configuração.
Como são muitos os itens gerados durante o desenvolvimento de um projeto de
software, a seleção destes deve ser feita com critério, pois tentar colocar um grande
volume de itens sob o controle da GCS pode aumentar sobremaneira o volume de
trabalho, sem trazer em contrapartida mais benefícios. Geralmente, utilizam-se como
critérios para seleção dos itens de configuração de software: os itens de software mais
utilizados no ciclo de vida, os mais genéricos, os mais importantes para a segurança, os
projetados para reutilização e os que podem ser modificados por vários desenvolvedores
ao mesmo tempo (Rocha et. al., 2001). Considera-se que, no mínimo o código- fonte e a
documentação de projeto devem estar sob controle da GCS.
2.3.2
Configuração-base
Entende-se por configuração-base (baseline) um conjunto bem definido de itens de
configuração que representam um estágio de desenvolvimento do software,
formalmente aceitos, que servem como base para desenvolvimento posterior e que só
46
podem ser alterados segundo um procedimento de controle de modificações
estabelecido e documentado.
2.3.3
Desenvolvimento de Software Baseado em Configuração-base
Um ciclo de vida ou modelo de desenvolvimento representa uma quebra do trabalho de
desenvolvimento, produção e manutenção de um produto em fases limitadas. Um
produto passa, então, por várias atividades durante o ciclo de vida, nas quais o
gerenciamento da configuração deve ser considerado. Estas atividades podem ser, por
exemplo: preparação, especificação de requisitos, projeto, codificação, integração, testes
e operação e manutenção, como ilustra a Figura 2.2.
Projeto A
Desenvolvimento
Preparação
Operação e
Requisito Projeto Codificação Teste Manutenção
odificação
s
Gerência de Projeto
Garantia da Qualidade
Gerência da Configuração
FIGURA 2.2 - Modelo de Desenvolvimento Genérico.
FONTE: Adaptada de Hass (2002, p. xliii).
Podem-se considerar as atividades mencionadas como blocos de construção que são
arranjados de acordo com o modelo de desenvolvimento escolhido, como o clássico
modelo em cascata (semelhante à Figura 2.2), ou desenvolvimento iterativo, onde
algumas fases são mais curtas, mas repetidas várias vezes durante o ciclo de vida do
projeto, ou o desenvolvimento ágil, ou incremental. Como a Figura 2.2 mostra, existem
várias funções de suporte para preparar, desenvolver, operar e manter um produto. Estas
funções, que incluem o gerenciame nto de projeto, a garantia da qualidade e a gerência
da configuração, devem ser executadas durante toda a vida de um produto (Hass, 2002).
47
Independente do modelo escolhido para um dado projeto, cada fase termina em um
marco (milestone): um ponto específico no projeto no qual um resultado é esperado.
Este resultado constitui-se no conjunto de produtos de trabalho que devem ser
considerados para o controle pela GCS, ou seja, devem ser selecionados como itens de
configuração do projeto para formar uma configuração-base de projeto.
Ainda que as configurações-base possam ser estabelecidas em qualquer ponto do ciclo
de vida do desenvolvimento de software, é mais vantajoso fazer coincidir o
estabelecimento das configurações-base com os finais das fases do ciclo de vida
definido para o produto. O desenvolvimento em configurações-base pode ser descrito
pelo seguinte (Oliveira, et. al., 2001):
•
Obter, da gerência de projeto ou de desenvolvimento, a caracterização do ciclo
de vida, que consiste na identificação das fases de desenvolvimento, das
atividades a serem realizadas em cada uma delas e dos produtos que deverão ser
desenvolvidos.
•
Definir o conjunto de configurações-base obtidas a cada final de fase, ou marco
de desenvolvimento identificado, os itens de configuração que irão compor cada
configuração-base e as condições impostas para seu estabelecimento.
•
Durante cada fase, o desenvolvimento dos itens de configuração referentes a ela
está sob o controle dos desenvolvedores, que podem criá- los e modificá- los com
facilidade.
•
A modificação em uma configuração-base já estabelecida só pode ser feita de
forma controlada, através de procedimento bem definido.
•
Cada configuração base incorpora integralmente a anterior. Assim, em qualquer
instante do desenvolvimento, a última configuração-base estabelecida representa
o estado oficial de todo o desenvolvimento.
48
•
O estabelecimento de uma configuração-base é feito após aprovação pela
Gerência da Qualidade, que realiza as atividades de verificação e validação dos
produtos de trabalho, conforme especificado no Plano de Garantia da Qualidade.
Por exemplo (Oliveira, et. al., 2001), num desenvolvimento em cascata, inicialmente,
uma configuração-base de requisitos contém documentos de especificação do software a
ser construído. A configuração-base de projeto é composta pela configuração-base de
requisitos acrescentada dos documentos de projeto; uma configuração-base de código é
composta pelas anteriores mais o código produzido.
Outras configurações-base típicas geralmente utilizadas são as configurações-base
funcional, alocada, de desenvolvimento e de produto (IEEE SWEBOK, 2001). A
funcional corresponde aos requisitos de sistema revistos. A alocada corresponde às
especificações de requisitos de software e de interface de software revistas. A de
desenvolvimento representa a configuração de software em desenvolvimento, em certos
momentos durante o ciclo de vida do software. A de produto corresponde ao produto de
software completo entregue para integração do sistema.
Uma configuração-base constitui-se, portanto, em uma versão estável de um sistema,
que contém todos os itens de configuração que o constituem em um dado momento.
Uma vez que todos os itens de configuração de uma configuração-base tenham sido
desenvolvidos, a configuração-base é estabelecida, e daí em diante só poderá ser
modificada através de mecanismos formais estabelecidos pela GCS.
Entre uma configuração-base e a seguinte, novos itens de configuração são criados
livremente. Mas os itens de configuração que fazem parte da configuração-base anterior
também são passíveis de modificação, quer seja para correção ou aperfeiçoamento.
Assim, a evolução das configurações-base deve-se a dois fatores: criação de novos itens
e modificação dos já existentes.
Por exemplo, depois de estabelecida a configuração-base de requisitos, inicia-se a fase
de projeto, e os projetistas passam a desenvolver os itens de configuração referentes à
fase com base nos documentos (itens de configuração) já estabelecidos na configuração-
49
base de requisitos. Nesta fase, pode ocorrer uma necessidade de modificação em algum
dos itens de configuração já consolidados na configuração-base de requisitos. Quando
isto ocorre há a necessidade de seguir um procedimento bem definido para a realização
da modificação, discutida na atividade de controle da configuração. Uma vez verificado
que as modificações foram implementadas corretamente e não criaram inconsistências
na configuração-base, uma nova versão da configuração-base de requisitos é criada.
Estabelecida esta nova versão, os projetistas continuam suas atividades, tendo agora
como referência a nova configuração-base. E assim, de maneira semelhante, conforme
as fases seguintes vão sendo executadas, as novas configurações-base vão sendo
desenvolvidas, estabelecidas e modificadas, até que o desenvolvimento seja concluído.
O número de itens de configuração, os nomes e os conteúdos das configurações-base
dependem do projeto e do desenvolvimento adotado. Um exemplo de configuraçõesbase (CB) e seus conteúdos e desenvolvimento ao longo do tempo encontram-se na
TABELA 2.1.
TABELA 2.1 – Exemplos de Configuração-base.
Itens de
configuração
incluídos
CB
Requisitos
CB
Arquitetura
CB
Projeto
CB
Código
CB
Produto
CB
Distribuição
Plano de Projeto
Plano de GCS
Plano e especificação
de testes
Especificação de
requisitos
Especificação de
Projeto de arquitetura
Especificação do
Projeto detalhado
Manual do usuário
Subsistema 1
Subsistema 2
Sist. Completo
Notas de liberação
1.0
1.0
1.0
2.0
2.0
2.0
3.0
3.0
3.0
4.0
4.0
4.5
4.1
4.0
5.2
4.1
4.0
6.3
1.0
1.3
1.4
1.4
1.6
1.6
-
1.0
1.2
1.3
1.3
1.3
-
-
1.0
1.1
1.2
1.3
-
-
-
1.0
1.0
1.0
-
1.1
1.1
1.1
1.0
-
1.1
1.2
1.2
1.1
1.0
50
2.3.4
Distribuições
Uma distribuição consiste num conjunto de itens de configuração que foram entregues a
um usuário ou cliente no final do desenvolvimento, após o estabelecimento da última
configuração-base, geralmente a configuração-base de produto. Uma distribuição é,
portanto, uma configuração do produto para utilização em ambiente externo ao de
desenvo lvimento, como um setor ou organização responsável pelos testes finais do
produto ou o cliente final.
Nem sempre todos os itens que compõem a configuração-base de produto são entregues.
Os documentos de projeto, por exemplo, podem ficar em poder do desenvolvedor.
Assim, o conjunto de itens que constituem uma distribuição do produto pode não ser o
mesmo de uma configuração-base; às vezes, nem mesmo um subconjunto dela, no caso
de só serem entregues os arquivos executáveis, que não são colocados, geralmente, sob
gerenciamento da configuração.
Uma configuração-base que dá origem a uma distribuição é chamada de configuração
de distribuição. Estabelecer uma distribuição consiste em realizar um conjunto de ações
para, a partir de uma configuração-base, gerar uma distribuição do produto referente a
esta configuração.
2.3.5
Informações Sobre os Itens de Configuração: Metadados
Todas as atividades da GCS compartilham informações sobre os itens de configuração.
Estas informações são conhecidas como metadados: um conceito de banco de dados que
significa dados sobre os dados armazenados na base de dados. No contexto da GCS, os
metadados descrevem os itens de configuração de software. A Figura 2.3 apresenta uma
visão geral de quais os elementos de dados podem fazer parte dos me tadados de um
item de configuração. Estes dados podem ser considerados como aqueles estritamente
necessários sob o ponto de vista da GCS (Hass, 2002), embora outros possam ser
considerados necessários, sob o ponto de vista de outras gerências.
51
Produto
Pertence a
Produzido por
Pessoas
Sob responsabilidade de
Foi distribuído para
Aprovado por
Nome
Versão
Estado
Data
Localização
Ligado a
Produzido com
Derivado de
Consiste de
Outros itens
de
configuração
FIGURA 2.3 – Visão Geral dos Metadados dos Itens de Configuração.
FONTE: Adaptada de Hass (2002, p. 90).
Os metadados do item são compostos de elementos de dados que podem ser divididos
em quatro grupos: identificação única, autorização, relacionamentos com outros itens de
configuração e distribuição.
Identificação única. Metadados de identificação única do item de configuração, que
incluem:
•
Pertence a: indica o produto ao qual o item pertence.
•
Nome do item: nome dado ao item segundo convenções estabelecidas para o
tipo de item específico.
•
Versão: expressa o histórico de desenvolvimento do item.
•
Estado: expressa o estado atual do item de configuração.
•
Data: data em que o item foi colocado sob armazenamento controlado.
•
Localização: o caminho completo e o nome eletrônico do item que expressam a
localização física do item.
52
Autorização para o item de configuração. Três tipos de autorização estão associados
ao item de configuração, expressos nos relacionamentos: produzido por, sob
responsabilidade de e aprovado por.
•
Produtor: quem produz o item e o encaminha para avaliação pela qualidade e
posterior controle da GCS.
•
Responsável pelo item: quem possui a responsabilidade final pelo item no
projeto, que pode ser o Gerente de Projeto ou Gerente de Produto.
•
Responsável pela aprovação: a responsabilidade pela aprovação do item fica a
critério da Gerência da Qualidade, dependendo da fase de desenvolvimento em
que se encontra o item de configuração.
Relacionamentos entre o item de configuração e outros. Praticamente todos os itens
de configuração têm relacionamentos com outros itens, que podem ser:
•
ligado a: refere-se a itens das atividades anteriores no desenvolvimento, nos
quais o item de configuração é baseado. Geralmente o Plano de Projeto indica
como os itens estão ligados uns aos outros. Por exemplo:
-
Requisitos de software estão ligados aos requisitos dos usuários.
-
Especificações de teste de aceitação estão ligadas aos requisitos do usuário.
-
Projeto de arquitetura está ligado aos requisitos de software.
-
Especificações de teste do sistema estão ligadas aos requisitos de software.
-
O projeto detalhado está ligado ao projeto de arquitetura e aos requisitos de
software, e assim por diante.
Este relacionamento é freqüentemente do tipo vários-para-vários. O pré-requisito
para manter este relacionamento é que os itens de configuração tenham
identificação única e que não seja modificável, mas fácil de referenciar e
53
acessível. Este relacionamento deve ser registrado de maneira a possibilitar
relatar as ligações nas duas direções, ou seja, deve ser possível saber quais casos
de teste estão associados a qual requisito específico de software e saber a quais
requisitos de software um caso de teste específico está associado. Novos itens de
configuração herdam as ligações da versão anterior.
•
produzido com: indica qual a ferramenta utilizada na produção do item.
•
derivado de: expressa o histórico do item e deve ser utilizado somente quando o
nome do item muda de uma versão para outra.
•
consiste de: somente as configurações-base consistem de outros itens de
configuração. Os itens pertencentes a uma configuração-base devem ser
expressos precisamente, de maneira que o estado do item seja levado em
consideração quando forem agrupados, ou seja, somente os que estiverem
aprovados pela GQ e não apenas a última versão do item. Este relacionamento é
herdado da versão anterior de um item de configuração e deve-se verificá- lo para
que, caso na versão atual algum item tenha sido eliminado da configuração-base,
a informação contida neste relacionamento seja também eliminada.
Distribuição do item de configuração. Esta informação deve ser registrada quando
uma configuração-base de distribuição for liberada para um cliente externo à
organização de desenvolvimento e consiste no relaciona mento:
•
foi distribuído para: este relacionamento deve ser registrado após uma
solicitação de liberação ter sido atendida. Esta informação pode incluir um
registro do porque a liberação ocorreu (se o propósito foi um teste de integração
ou a entrega do produto todo ao cliente). Esta informação é registrada somente
depois que uma configuração-base de produto é estabelecida.
54
2.3.6
Repositórios e Bibliotecas de Software
Itens
de
configuração
de
software
devem
ser
reunidos
e
armazenados
convenientemente, de maneira a evitar que sejam perdidos ou danificados. Os acessos e
as modificações feitas nestes itens podem ser de alguma forma controlados, e um
registro de quem realizou estas operações pode ser mantido.
O armazenamento dos itens de configuração é feito em locais específicos, chamados de
bibliotecas. As bibliotecas podem ser apresentadas na forma de estrutura de arquivos e
diretórios. Fisicamente, uma biblioteca pode ser uma estrutura de diretório em uma
estação de trabalho, uma base de dados ou um repositório.
Um repositório, sob o ponto de vista da GCS, é uma biblioteca centralizada de arquivos
que fornece controle de versão para estes arquivos. Considera-se que qualquer arquivo
no repositório está sob uma forma de gerenciamento da configuração. Os arquivos no
repositório são imutáveis – não podem ser modificados. Realizar uma modificação em
um arquivo no repositório significa criar uma nova versão do arquivo.
As bibliotecas são também chamadas de sistemas de gerenciamento da configuração
(CMMI-SW, 2002) e repositórios de configurações-base.
Tradicionalmente, três tipos de biblioteca (Hass, 2002; IEEE 828, 1998) são ligados ao
desenvolvimento de software: a controlada, a dinâmica e a estática.
A biblioteca controlada, ou biblioteca da GCS é onde os itens de configuração são
armazenados. Ela pode estar dividida em várias bibliotecas físicas, especialmente
quando se tem vários tipos de itens de configuração, tais como documentos, código
fonte, etc.
A biblioteca dinâmica ou de desenvolvimento é onde os itens são mantidos enquanto
estão em produção. Está localizada na área de trabalho do desenvolvedor e pode
consistir de várias bibliotecas independentes. Esta biblioteca não está sob o
gerenciamento da configuração e sim sob a responsabilidade do desenvolvedor.
55
Bibliotecas controladas e dinâmicas podem, no entanto, se sobrepor, contendo tanto
itens de configuração quanto produtos de trabalho em desenvolvimento. Durante a
produção um item pode ser retirado e colocado na biblioteca várias vezes antes de ser
finalizado, sendo a biblioteca utilizada como uma forma de backup para os resultados
intermediários do trabalho. Estes resultados intermediários não são aprovados, nem
estão sob o gerenciamento da configuração. Para distingui- los das versões do mesmo
item que estão sob gerenciamento da configuração deve-se, então, usar códigos de
estado para tornar claro quando a versão modificada de um item é aprovada e está sob o
gerenciamento da configuração e quando não. Além disso, é necessário garantir que
quando um item é extraído da biblioteca este não é apenas um item que está em
desenvolvimento e sim uma versão que está realmente aprovada e sob o gerenciamento
da configuração.
A biblioteca estática é onde os itens são utilizados, não só pelos usuários finais, mas
também em outras aplicações, como por exemplo, no caso de teste parcial do sistema,
na integração de um sub-componente em um componente maior.
Na biblioteca estática os itens de configuração não são modificados. Esta biblioteca
pode ser constituída de vários repositórios físicos ou meios de armazenamento. A
localização desta biblioteca depende do tipo de item e sua utilização. Por exemplo, a
biblioteca estática pode ser idêntica à dinâmica, no caso do item ser utilizado no módulo
de teste de um outro item. Neste caso o item é copiado da biblioteca controlada para
uma cópia somente de leitura na área de trabalho do desenvolvedor. Quando o item for
um sistema em produção, a biblioteca estática pode estar situada na máquina de
produção ou estação de trabalho do usuário. Esta biblioteca não está sob o
gerenciamento da configuração, mas sob responsabilidade do desenvolvedor, ou gerente
de testes, ou do cliente, dependendo do contexto de utilização.
A biblioteca da GCS contém não somente os itens de configuração, mas também os
metadados associados ao item, utilizados para geração de relatórios e consultas.
56
2.3.7
Controle de Versões
O controle de versões é um mecanismo fundamental da GCS e consiste em ferramentas
e procedimentos utilizados para gerenciar as diferentes versões de arquivos criadas
durante o desenvolvimento de software.
Durante um projeto, os itens de software passam por vários estados, até que consigam
atender aos propósitos para os quais foram criados. Isto implica em diversas
modificações, gerando uma versão de item a cada estado. Fazendo-se uma analogia com
a abordagem orientada a objeto, um item de configuração pode ser visto como uma
classe e as suas versões como instâncias da classe (Hass, 2002). Uma versão é uma
instância do item de configuração que é diferente das out ras. Cadeias de versões de itens
de configuração – versões 1, 2, 3, etc - podem ser formadas indicando-se de qual item
de configuração um dado item é derivado ou em qual está baseado.
O gerenciamento de versão pode ser aplicado, inicialmente, ao código, à documentação
e às configurações-base e, mais à frente, também ao ambiente de desenvolvimento. A
reconstrução de versões anteriores de um produto só pode ser garantida se tanto o
código quanto o ambiente de desenvolvimento —compiladores, linkers, bibliotecas de
runtime, bibliotecas de banco de dados e de comunicação—forem idênticos àqueles
utilizados para criar a versão original.
O controle de versões possibilita o rastreamento automático dos arquivos e a prevenção
de conflito de acesso por parte dos desenvolvedores. Permite, ainda, a recuperação de
versões anteriores, criação de linhas de desenvolvimento, registro de informações
durante o desenvolvimento do arquivo (quem, quando, o quê foi modificado) e
estabelecimento de agregações de arquivos: as configurações-base e distribuições.
Um esquema de identificação feito em forma de árvore mantém um histórico das
versões dos itens e permite a identificação única e ramificações a partir de qualquer
versão. Um formato muito utilizado é o seguinte:
57
<Id_Principal>.<Id_Secundário>, onde o Id_Principal é o identificador principal da
versão, e constitui-se em um número inteiro, cujo valor inicial é 1, e o Id_Secundário é
o identificador secundário de versão e constitui-se de um número inteiro, iniciando-se
em 0. Para ambos os identificadores não existe um número limite superior.
Como exemplo, temos na Figura 2.4 um arquivo ARQ. A primeira versão de ARQ é a
1.0. Cada vez que uma nova versão de ARQ é criada, seu Id_Secundário é incrementado
de 1. Pode-se, também, a critério de pessoa com a autorização competente, avançar o
Id_Principal para 2. Neste caso, o Id_Secundário é reiniciado com 0. Um incremento no
I_Principal pode ser feito, por exemplo, quando uma nova funcionalidade significativa é
acrescentada ao arquivo.
Arquivo ARQ
Modificações
1.0
•
•
•
1.1
1.2
1.3
Quem
Quando
Por que
2.0
2.1
Versão atual
FIGURA 2.4 – Controle de Versões de um Arquivo.
Com o crescimento das ramificações na estrutura de versões, cresce também o espaço
necessário para o armazenamento das versões. Para minimizar a necessidade de espaço,
surgiu o conceito de delta, que é o conjunto de diferenças entre uma versão e outra.
Assim, é feito o armazenamento de apenas uma versão completa e das diferenças ou
deltas entre as versões. Este conceito tem duas variações: o delta positivo e o delta
negativo. Com o delta positivo, é armazenada a versão mais antiga, a partir da qual são
montadas as versões mais recentes, processando-se as diferenças (deltas) armazenadas.
Com o delta negativo, a versão mais recente é armazenada integralmente junto com as
diferenças até ela. Como é muito mais comum a utilização das versões mais recentes, o
delta negativo é o conceito mais utilizado nos sistemas de gerenciamento de versões.
58
Com ele, uma versão das mais recentes é obtida rapidamente, pois não é necessário o
acréscimo de muitos deltas para a sua obtenção.
Este método de deltas, eficiente para arquivos-texto, pode trazer um grande desperdício
de espaço se aplicado a arquivos binários. Deste modo, técnicas de compressão são
utilizadas para este tipo de arquivo, que têm suas versões armazenadas na íntegra.
Com o barateamento dos meios de armazenamento é razoável a utilização de técnicas de
compressão eficientes para o armazenamento de versões integrais de arquivos, evitandose, assim a montagem de versões a partir das diferenças entre elas.
2.3.8
Linhas de Desenvolvimento
As linhas de desenvolvimento (branches) são derivações a partir de uma determinada
versão de arquivo, que geram linhas paralelas a partir da linha de desenvolvimento
principal ou tronco principal de uma árvore de versões. São utilizadas quando se deseja
incorporar certas características em determinadas versões e não em outras. Isto pode ser
visualizado na Figura 2.5.
Arquivo Arq
1.0
1.1
1.2
1.3.1.1
1.3
2.0
1.2.1.1
1.2.1.2
2.1
FIGURA 2.5 – Linhas de Desenvolvimento.
A identificação de uma linha de desenvo lvimento pode ser feita da seguinte maneira:
<Id_Versão>.<Id_Linha>.<Id_Seq>, onde Id_Versão é a identificação de uma versão
existente denominada versão base, da qual a versão identificada é uma variante ou
59
paralela, o Id_Linha é o número de ordem inteiro, maior ou igual a 1, de uma linha
paralela a partir da versão base e Id_Seq é o número inteiro, maior ou igual a 1, da
ordem da versão dentro da linha paralela.
2.3.9
Variantes e Desenvolvimento Paralelo
Variantes ocorrem quando um item de configuração, aparentemente único sob o ponto
de vista funcional, aparece em várias versões simultaneamente, com pequenas
diferenças entre elas. Isto pode surgir por requisitos de linguagem (software em versões
em português e inglês, por exemplo), requisitos de hardware, protocolos de
comunicação, requisitos de clientes (produto com mais ou menos funcionalidades) ou
requisitos de plataforma de sistema operacional.
O desenvolvimento paralelo ocorre quando pessoas têm que trabalhar no mesmo item de
configuração ao mesmo tempo – quando linhas de desenvolvimento (branches) são
formadas a partir da linha principal e depois os resultados das linhas devem ser unidos.
A necessidade para o desenvolvimento paralelo pode surgir por fatores como pressões
de tempo, trabalho feito em turnos ou distribuição de competência (Hass, 2002).
Isto ocorre, por exemplo (Figura 2.6), quando uma especificação de requisitos de um
grande projeto envolve o trabalho de vários especialistas, que trabalham cada um em
uma parte da especificação ao mesmo tempo (Hass, 2002). O trabalho de especificação
de requisitos é então dividido e as partes resultantes são unidas em um documento ao
fim da atividade. Deve-se considerar cuidadosamente se o desenvolvimento paralelo
deve ficar restrito a ambientes de desenvolvimento ou se os itens de configuração
paralelos devem ser colocados sob gerenciamento da configuração.
60
ER 2A1
ER 2A2
ER 2A3
ER 1
ER 2
ER 2B1
ER 2B2
FIGURA 2.6 – Desenvolvimento Paralelo e União.
FONTE: Hass (2002, p. 246).
No exemplo da Figura 2.6, se não se deseja tornar públicas ou manter histórico das
versões intermediárias, mas apenas o histórico de ER 1 diretamente para ER 2, então o
desenvolvimento não é paralelo sob o ponto de vista da GCS; a união das versões deve
ser feita antes do resultado ser colocado sob a GCS.
Tanto a criação de variantes como o desenvolvimento paralelo adicionam complexidade
à GCS e devem ser considerados com cuidado. São decisões de planejamento e projeto
e, portanto, de responsabilidade do gerente de projeto ou de desenvolvimento, não da
GCS.
Técnicas de projeto podem ser utilizadas para reduzir o número de variantes ou linhas
de desenvolvimento paralelo. Por exemplo, no caso das variantes, pode-se retirar o
acesso a determinadas funcionalidades, ou utilizar compilação condicional (como o
#ifdef) ou, ainda, pode-se dividir um item em outros itens mais independentes. Quando
o desenvolvimento paralelo for inevitável, devem ser feitas freqüentes uniões (merges),
para que as linhas de desenvolvimento sejam poucas e o mais curtas possíveis.
As duas situações, variantes e desenvolvimento paralelo, devem se refletir na
identificação do item. Outros cuidados devem ser tomados durante o processo da GCS,
principalmente no controle de modificações, como por exemplo, se estas devem ou não
se propagar pelas variantes e linhas de desenvolvimento.
61
2.3.10 Operações de Acesso às Versões no Repositório
Ferramentas de controle de versão permitem acesso às versões armazenadas nos
repositórios através de um conjunto de operações básicas, conhecidas como política de
check-in/check-out, isto é, conferência na entrada e na saída.
As operações conceituais básicas desta política são:
•
Operação check-out. Uma cópia de trabalho da versão desejada é retirada do
repositório para modificação, ao mesmo tempo que impede acessos à versão por
outros desenvolvedores.
•
Operação check-in. Uma nova versão do arquivo é criada a partir da cópia de
trabalho modificada (obtida por check-out) e libera acessos à versão.
•
Operação get. Permite obter uma cópia específica de uma versão apenas para
leitura, não impedindo o acesso ao arquivo por outros usuários.
2.3.11 Agregações
O controle de versão inclui também um mecanismo de agregação, onde várias versões
de arquivos relacionadas são agregadas, referenciadas e obtidas em conjunto. Este
mecanismo consiste na atribuição de um rótulo (tag) comum a cada versão de arquivo
que integra o conjunto que se deseja caracterizar.
As operações básicas de check-in, check-out e get se aplicam também às agregações,
sendo aplicadas a todos os elementos do conjunto.
A Figura 2.7 apresenta o mecanismo de agregação. Nela, um produto é composto pelos
arquivos A, B e C. A primeira agregação, identificada como 1.0, é composta pelo
seguinte conjunto de versões de seus arquivos componentes: {A1.1, B3.2, C2.0}. A
segunda agregação, 1.1, é composta pelo seguinte conjunto: {A1.2, B3.2, C2.1}.
62
O mecanismo de agregação possibilita a implementação dos conceitos de configurações,
configurações-base e distribuições.
A
1.0
B
C
1.0
1.0
1.1
3.2
1.0
1.0
1.1
2.0
2.0
1.1
1.1
1.2
1.0
3.0
1.2
2.0
1.1
3.2
3.1
2.1
2.1 1.1
Agregações
3.2
1.0
1.1
FIGURA 2.7 – Agregações.
2.4
Breve Histórico da Gerência da Configuração de Software
A Gerência da Configuração (Oliveira et. al., 2001) teve o seu início ainda nos anos 60,
voltada para projetos de engenharia na área de defesa, em organizações militares norteamericanas. Na década de 1970, o governo americano desenvolveu vários padrões
militares, que incluíam o gerenciamento da configuração, sendo que o primeiro a
reconhecer a gerência de configuração tanto de hardware como de software foi o padrão
MIL STD 483, Configuration Management Practices for Systems, Equipment,
Munitions, and Computer Programs, publicado por volta de 1971. Nos anos de 1979 e
1981 foram realizadas conferências de software em Monterey, Califórnia, onde uma das
principais resoluções foi a determinação de se criar um padrão universal para
desenvolvimento de software. Este projeto se consolidou no padrão DOD STD 2167
Defense System Software Development publicada em 1985. Esta norma significou um
grande avanço nos conceitos de GCS principalmente com a introdução do conceito de
63
configuração-base (baseline), que organizava a GCS em termos das fases do ciclo de
vida.
A partir de 1988, com a demonstração de interesse do governo americano em fomentar
os trabalhos de normalização das associações da indústria, tais como IEEE, ANSI e
EIA, a evolução de GCS passou para entidades ligadas às indústrias e universidades,
ainda com grande participação das organizações militares e de defesa norte-americanas.
A IEEE publicou dois padrões enfocando especificamente a questão de elaboração de
planos de GCS: IEEE Std 828 Software Configurations Management Plans e o IEEE
Std 1042 Guide to Software Configuration Management. Esses padrões, principalmente
o IEEE Std 828, são internacionalmente bastante adotados como referência para a
elaboração de planos de GCS.
Mais tarde, especialmente nos anos 90, surgiram muitos outros padrões e publicações
discutindo o gerenciamento da configuração de software.
Com o Capability Maturity Model (CMM-SW, 1993), do Software Engineering
Institute da Carnegie Mellon University, a importância da disciplina GCS foi ainda mais
realçada, com sua identificação como processo-chave de um processo de software de
qualidade.
A International
Organization
for
Standardization
(ISO)
e
a International
Electrotechnical Commission (IEC) produziram o padrão ISO/IEC 12207:1995
Information technology – Software life cycle processes, que define uma estrutura de
processos para o processo de software. Neste modelo, é estabelecido o processo de GCS
como um dos processos de apoio ao desenvolvimento de software. A partir deste padrão
foi produzido o relatório técnico ISO/IEC TR 15846:1998 Information technology Software life cycle processes – Configuration Management que procura desenvolver a
caracterização resumida de GCS definida na ISO/IEC 12207.
Assim, nos últimos anos, o entendimento crescente do desenvolvimento de software
como uma coleção de processos inter-relacionados tem influenciado o trabalho da
64
Gerência da Configuração, que passou também a ser considerada sob o ponto de vista
de processo (Hass, 2002), como será visto no Capítulo 3.
A evolução da GCS pode ser observada ainda através das funcionalidades das gerações
de sistemas de GCS. No início, a gerência da configuração de software esteve voltada
para a captura da evolução de um sistema de software no nível de código fonte (van der
Hoek et. al., 2001). A primeira geração consistia de sistemas como o Source Code
Control System (SCCS) (Rochkind, 1975), desenvolvido pelos Laboratórios Bell no
começo dos anos 70, e o Revision Control System (RCS), desenvolvido na Universidade
Purdue, por W. Tichy (Tichy, 1991). Estes sistemas tinham como objetivos evitar que
múltiplos desenvolvedores fizessem modificações simultâneas no mesmo arquivo de
código-fonte e controlar a evolução, no tempo, de cada arquivo fonte. Isto foi
conseguido através da manutenção automática de arquivos de versão, onde cada arquivo
contém uma série de revisões de um único arquivo fonte (usando a técnica de
armazenamento de deltas para salvar espaço em disco) bem como bloqueios (locks) para
indicar modificações em progresso.
Para suprir as necessidades de múltiplas linhas de desenvolvimento e de trabalho
paralelo, o RCS introduziu o conceito de linhas de desenvolvimento (branches) para
armazenar variações lógicas em um arquivo de versões e o merging como um método
de incorporar as modificações de uma linha em outra. Combinadas, todas as revisões e
variantes formam uma árvore de versão, que é a entidade central através da qual os
usuários interagem com um sistema de GCS de primeira geração.
A complexidade dos projetos de software continuou a aumentar, levando a que se
desenvolvessem camadas de abstração, usando scripts, sobre as funcionalidades básicas
destas ferramentas, para atender a este aumento de complexidade.
A fim de suportar o controle de modificações compostas nos grupos de arquivos fontes
e gerenciamento avançado da área de trabalho (workspace), pesquisas em modelos de
sistemas iniciaram a criação da segunda geração de sistemas de GCS. Modelos de
sistemas e suas linguagens de modelagem associadas fornecem uma maneira de capturar
65
a estrutura do software que está sendo gerenciada através de configurações - conjunto
de versões específicas ou arquivos fonte específicos.
Para capturar a evolução potencial da própria estrutura, configurações podem existir em
diferentes revisões e variantes - assim como um arquivo fonte individual. Com a
automatização do gerenciamento da área de trabalho, através de especificações de
configuração (conjuntos de regras indicando qual versão de qual arquivo fonte colocar
em uma área de trabalho), modificações feitas em vários códigos fonte podem ser
colocadas de volta em um repositório em um único passo, atualizando assim tanto os
arquivos fontes individuais como as configurações.
O surgimento da terceira geração de sistemas de GCS deveu-se à necessidade de
políticas diferentes em situações onde um grande número de usuários opera um pequeno
conjunto de arquivos fontes ou em casos em que grupos distribuídos de desenvolvedores
modificam um único trecho de código (van der Hoek et. al., 2001). Ferramentas
modernas estenderam, então, as funcionalidades básicas das primeiras ferramentas,
suportando um desenvolvimento paralelo melhorado, gerenciamento de áreas de
trabalho, e gerenciamento de construção e liberação.
Atualmente, recursos avançados têm sido adicionados a várias ferramentas de GCS,
permitindo um suporte em um nível de abstração quase alinhado com outros aspectos da
Engenharia de Software, tais como gerenciamento das solicitações de modificação e
gerenciamento de projeto. Estas ferramentas dão suporte à atribuição de versões a todos
os artefatos de um projeto, a projetos de software cujos membros da equipe podem não
estar fisicamente no mesmo local, ao desenvolvimento baseado em componentes, e
gerenciamento da configuração baseado em atividades (White, 2000).
2.5
Áreas de Funcionalidade da GCS
Os diferentes grupos de pessoas envolvidas têm diferentes necessidades quando se
considera a perspectiva global de um projeto de software. Por exemplo, o desenvolvedor
necessita de uma visão mais detalhada, do que a do gerente de projeto.
66
Dart (Dart, 1991) apresenta um cenário típico, através do qual se pode ter uma visão dos
aspectos da GCS em uma organização. Este cenário envolve várias pessoas com
diferentes responsabilidades, por exemplo: um gerente de projeto, responsável por um
grupo de software, um gerente de configuração, responsável pelos procedimentos de
GCS, os engenheiros de software, responsáveis pelo desenvolvimento e manutenção dos
produtos de software, o responsável pelos testes de validação do produto, o gerente da
garantia da qualidade, que garante a alta qualidade do produto e o cliente que o utiliza.
Cada papel tem seus próprios objetivos e tarefas.
Com base neste cenário, Dart apresenta um conjunto de funcionalidades esperadas de
um sistema de GCS. Estas funcionalidades podem ser agrupadas em duas principais
áreas: equipe e processo, como mostrado na Figura 2.8.
As áreas funcionalidades centradas na equipe tratam de aspectos técnicos da GCS:
Componentes: identifica, classifica, armazena e acessa os componentes que formam o
produto.
Estrutura: representa a arquitetura do produto.
Construção: apóia a construção do produto e de seus artefatos.
Equipe: capacita uma equipe de projeto a desenvolver e manter uma família de
produtos.
Em contraste com as áreas centradas na equipe, as funcionalidades centradas em
processo cobrem as questões de gerenciamento:
Auditoria: mantém auditorias do produto e do seu processo.
Contabilidade: reúne estatísticas sobre o produto e seu processo.
Controle: controla como e quando as modificações são feitas.
Processo: suporta o gerenciamento da evolução do produto.
67
Dentre estas áreas, a de processo requer suporte para o modelo de ciclo de vida do
produto e as políticas da organização; habilidade para identificar tarefas a serem feitas e
como e quando elas estarão completas; possibilidade de comunicar informações sobre
eventos relevantes às pessoas certas e facilidades para documentar conhecimento sobre
o produto.
CONSTRUÇÃO
ESTRUTURA
Construção
Instantâneos
Otimização
Análise de impacto
de modificação
Regeneração
EQUIPE
Modelo do sistema
Interfaces
Relacionamentos
Seleção
Consistência
AUDITORIA
Áreas de trabalho
Resolução de conflitos
Famílias
Histórico
Rastreabilidade
Registro
Versões
Configuração
Versões de configuração
Configurações-base
Contextos de projeto
Repositório
Tipos de componentes
Suporte ao ciclo de vida
Gerenciamento de tarefas
Comunicação
Documentação
Estatísticas
Estado
Relatórios
PROCESSO
COMPONENTES
Controle de acesso
Solicitação de modificação
Acompanhamento de defeitos
Propagação das modificações
Particionamento
CONTABILIDADE
CONTROLE
FIGURA 2.8 - Áreas de Funcionalidade da GCS.
FONTE: Dart (1991, p.4).
Em (Frühauf e Zeller, 1999) os autores acrescentam à Figura 2.8 novas funcionalidades
como a Conectividade à funcionalidade de Equipe, e um novo grupo, denominado
Implantação, que inclui a Instalação, a Parametrização, a Instanciação e a
Reconfiguração.
68
Para o usuário, o sistema de GCS ideal seria aquele que fornecesse todas as áreas de
funcionalidade com o suporte à equipe e ao processo totalmente integrados, o que, no
entanto, não acontece com um único sistema de GCS existente.
Um espectro dos conceitos que suportam algumas das áreas de funcionalidade
identificadas anteriormente, representando uma evolução do suporte à GCS é
encontrado em (Dart, 1991).
2.6
A GCS e os Requisitos do Projeto
Os requisitos para a GCS podem variar em um projeto de software (White, 2000)
devido a mudanças que ocorrem no projeto ao longo do tempo, como: aumento da
complexidade do software que está sendo desenvolvido, aumento da complexidade do
ambiente no qual o software está sendo desenvolvido, mudanças nos requisitos baseadas
nas fases do ciclo de vida do desenvolvimento e mudanças nos processos de
gerenciamento da organização e/ou de pessoal.
Considerando-se as modificações nos requisitos baseadas nas fases do ciclo de vida, um
bom processo deve facilitar as modificações ao máximo sem perder o controle efetivo
sobre o software. Um exemplo de controle é o nível de aprovação necessário para
aceitação das modificações no projeto. Nas primeiras fases do desenvolvimento, podese requerer somente a aprovação do líder de projeto, enquanto nas últimas fases do
desenvolvimento, pode ser exigida a aprovação de um grupo de controle de modificação
(GCC). Além do nível de autoridade, a forma de atuação de um GCC pode variar de
reuniões formais, com controle da agenda das reuniões, até a troca de e-mails para a
tomada de decisão.Um sistema de GCS flexível permitiria ao usuário escolher o tipo de
controle desejado.
2.7
Políticas e Modelos da GCS
Feiler (Feiler, 1991) classificou quatro modelos para a GCS, baseados em certos
padrões observados no suporte à biblioteca controlada nos sistemas de GCS comerciais:
69
check-out/check-in, composição, longa transação e conjunto de modificações. Desde
esta pesquisa, muitos outros sistemas de GCS surgiram baseados, essencialmente, nestes
mesmos modelos (Hoen et. al., 2000).
Em (van der Lingen e van der Hoek, 2003), os autores diferenciam um modelo de
gerenciamento da configuração de uma política de gerenciamento da configuração. Os
dois termos são geralmente utilizados para denominar a mesma coisa, já que um sistema
típico de GCS requer um único modelo harmonizado com uma só política. Como
resultado, a terminologia não é muito clara e os primeiros artigos sobre políticas de
gerenciamento da configuração, como o citado (Feiller, 1991), referem-se a elas como
modelos. Segundo os autores, um modelo é definido como as estruturas de dados usadas
para rastrear a evolução de um ou mais artefatos e uma política é definida como um
conjunto de procedimentos através dos quais um usuário desenvolve os artefatos
armazenados nestas estruturas de dados. Por exemplo, o modelo de árvore de versão é
geralmente usado em conjunto com uma política de check-in/check-out. Já a política de
conjuntos de modificação geralmente usa estruturas de dados especializadas para
capturar e relatar conjuntos de modificação individuais.
Os modelos da GCS têm um grande efeito na funcionalidade exigida e no processo de
modificação desejado. Uma classificação dos desenvolvedores de sistemas de GCS de
acordo com estes modelos pode ser encontrada em (Dart, 1992). O modelo de longa
transação ou transação introduz a noção de workspace, onde os desenvolvedores estão
isolados das modificações dos outros. O modelo de conjunto de modificações tem o
foco nas modificações ao invés de nas versões. Neste modelo, as versões são o produto
de um conjunto de modificação aplicado a uma configuração-base. Este modelo é útil
para propagação e combinação de modificações entre usuários e sites. O modelo mais
utilizado ainda é o check-in/check-out (Dart, 1992; Estublier et al, 2002).
A seguir, são apresentadas as políticas de gerenciamento da configuração baseadas em
(Feiller, 1991), utilizadas nesta abordagem.
70
2.7.1
Política de Check In/Check Out
Esta política é baseada no conceito de repositório, onde todos os arquivos individuais e
suas versões estão armazenados. É um modelo tradicional usado por ferramentas como
o SCCS (Rochkind, 1975) e o RCS (Tichy, 1991), onde os arquivos no repositório ou
biblioteca não são operados diretamente por ferramentas do desenvolvedor, mas são
necessárias operações explícitas (Figura 2.9) para armazenar um arquivo (check-in) e
para retirá- lo para uma área de trabalho desejada (check-out). Quando o arquivo é
colocado no repositório (checked-in), geralmente após alguma modificação, uma nova
versão é criada. Quando se retira uma versão do repositório, esta tem que ser
identificada. Arquivos podem ser retirados para leitura ou escrita, permitindo ações de
controle de concorrência para evitar modificações indesejadas na mesma versão do
arquivo. Isto é feito com o mecanismo de bloqueio (lock), que garante que o arquivo
não será modificado por outra pessoa até que retorne ao repositório. Versões
seqüenciais de um arquivo são chamadas revisões e caminhos de desenvolvimento
paralelo (branches) podem ser linhas de desenvolvimento paralelo ou variantes. O
histórico de versão de um arquivo pode ser apresentado como um gráfico de versão,
como já apresentado também na Figura 2.5.
Biblioteca da GCS
Check-out
1.1
1.2
1.3
2.2
2.1
2.3
2.3
2.3
Check-in
Var1
Var2
Revisão de
Variante de
Área de Trabalho
FIGURA 2.9- Check-out e Check -in.
71
2.7.2
Política de Composição
Esta política é baseada nos conceitos de repositório e modelagem de sistema, que tem
como foco o suporte a configurações. Uma configuração consiste em um modelo de
sistema, que lista todos os componentes que formam um sistema, e as regras de seleção
de versão que são aplicadas a este modelo, a fim de escolher a versão desejada de cada
componente. Regras de seleção podem especificar também uma variante de um arquivo
e assim suportar o gerenciamento de variantes do sistema. A Figura 2.10 apresenta um
sistema que consiste dos componentes A, B e C. Uma regra de seleção escolhendo a
última versão de cada componente foi aplicada resultando na versão 1.2 do componente
A, 1.1 de B e 1.0 de C. O histórico das versões das configurações é armazenado através
da atribuição de versões ao modelo do sistema e das regras de seleção. Uma
configuração pode ter nomes de versão, usados para referenciá- la mais tarde. Várias
ferramentas combinam o modelo de composição e o check-in/check-out, como a
ferramenta livremente disponível Concurrent Versions Systems (CVS) (Cederqvist,
1993), construída sobre o RCS, que utiliza também um conceito de módulo para
facilitar a modelagem do sistema e ainda implementa o modelo de transação.
Componente A
1.0
1.1
Modelo de
Sistema
Componente A
Regras de Componente B
seleção
1.0
Componente B
1.1
Componente C
Componente C
1.0
FIGURA 2.10 - A Política de Composição.
72
1.2
2.8
Mecanismos da GCS
A GCS deve prover mecanismos para que suas funcionalidades possam ser fornecidas
(Jalote, 1999). Entre os mecanismos mais utilizados para fornecer as funcionalidades
mínimas necessárias incluem-se:
Convenções para identificação e organização de arquivos e manutenção de
informações de estado: a identificação de código e documentos de projeto de acordo
com convenção padrão de identificação e o armazenamento destes produtos em locais
planejados ajuda na rápida localização de um arquivo desejado. Através da identificação
pode-se conhecer a natureza do conteúdo do arquivo, sem precisar olhar seu conteúdo.
Controle de versão: o controle de versão, apresentado anteriormente, é um mecanismo
chave para a GCS. Muitas ferramentas estão disponíveis para ajudar a gerenciar versões
de arquivos e programas.
Acompanhamento das solicitações de modificação: este mecanismo provê um
mapeamento entre a solicitação de modificação e as modificações implementadas nos
arquivos.
Controle de acesso: garante que somente pessoas autorizadas podem modificar alguns
arquivos e somente uma pessoa pode modificar um arquivo em um dado momento.
Histórico de modificações: é um mecanismo que permite ligar uma modificação à
solicitação de modificação que a gerou.
2.9
O Estado Atual da GCS
Vários artigos retratam o estado da arte, os desafios e o impacto da comunidade de
pesquisa no campo do gerenciamento da configuração de software (van der Hoek et al,
1995; Frühauf, 1999; Conradi e Westfechtel, 1999; Crnkovic, 1999; Estublier, 2000 e
Estublier et al, 2002). Vários estudos têm sido conduzidos unindo a GCS a outras
disciplinas, como sistemas orientados a objetos (Jennings, 2000), a programação
orientada a componentes (Larsson e Crnkovic, 2000) e sistemas hipermídia (Bendix et
73
al, 2000), assim como um framework conceitual para integrar os conceitos de tecnologia
de processo à GCS já havia sido proposto em (Joeris, 1997).
No cenário internacional, a GCS é considerada uma disciplina madura, e uma das
tecnologias de engenharia de software bem sucedidas, com um mercado crescente, com
mais de US$1bilhão de vendas em 1998 (Estublier, 2000).
A GCS é uma disciplina que tem recebido contribuições de pesquisas tanto da área
acadêmica quanto das grandes indústrias de software. Em (Estublier et al, 2002) é
analisado o impacto destas pesquisas no campo da GCS.
Segundo (Oliveira et. al., 2001), nos Estados Unidos, as iniciativas a respeito da GCS
partiram principalmente de entidades governamentais (DoD, NASA entre outras). Como
grandes compradoras de software, acabam por ditar as regras do mercado, impondo
padrões de qualidade aos seus fornecedores. Estas práticas vão sendo disseminadas para
o restante do mundo, em maior ou menor rapidez.
Assim, nos países mais desenvolvidos, esforços consideráveis têm sido feitos na
pesquisa e implementação de ferramentas de GCS. Uma grande quantidade de
ferramentas, com os mais variados custos e funcionalidades encontram-se no mercado,
desde simples ferramentas para controle de versões até as mais sofisticadas, com
capacidades para geração de builds, relatórios e suporte ao desenvolvimento distribuído,
entre outras.
Segundo levantamento feito em 2001 (Oliveira et. al., 2001), no Brasil a GCS ainda era
um tanto desconhecida e não se desenvolviam ferramentas para o mercado. No entanto,
há um interesse crescente pela GCS devido ao aumento da competitividade no mercado
e da busca de certificação ou maiores níveis de maturidade por parte das organizações,
como os do ISO 9000, SEI CMM-SW e ISO/IEC 15504. A maior incidência da
utilização de ferramentas de GCS encontra-se, no entanto, em empresas multinacionais
e de grande porte.
74
2.10 As Ferramentas de GCS
O escopo da disciplina da GCS é muito amplo, assim como as funcionalidades
fornecidas por sistemas ou ferramentas de GCS, que variam desde um simples controle
de versões, oferecido por ferramentas gratuitas, até o suporte ao gerenciamento de áreas
de trabalho, e de construção/distribuição de produto, para desenvolvimento em
ambientes distribuídos, oferecido pelas mais recentes e poderosas ferramentas
comerciais. Estas, além do alto custo de utilização, apresentam também uma íngreme
curva de aprendizado (Jézéquel, 1998).
Existe, portanto, atualmente, um grande número de ferramentas de GCS e vários sites
dedicados exclusivamente à avaliação de suas capacidades (como o CM Today Yellow
Pages, www.cmtoday.com/yp/configuration_management.html). Não é objetivo deste
trabalho apresentar as ferramentas de GCS, quer sejam comerciais ou gratuitas, ainda
que eventualmente citadas, nem comparar as suas funcionalidades. No entanto é
interessante conhecer uma classificação das ferramentas, bem como alguns critérios
utilizados para avaliação das mesmas, uma vez que através deles, são ressaltadas as
funcionalidades da GCS esperadas.
Estes critérios (Oliveira, et. al., 2001) podem ser: o suporte à equipe de
desenvolvimento, ao desenvolvimento remoto, a configurações, à gerenciamento de
modificações, a construção e distribuição do produto e ao processo; a usabilidade, a
facilidade de operação e a capacidade de adequação ou personalização da ferramenta.
O suporte ao processo diz respeito ao controle efetivo sobre o desenvolvimento do
produto, através da possibilidade de aplicação de políticas, implementação do conceito
de ciclo de vida, estabelecimento de níveis de autoridade para acesso a funções de
acordo com os papéis dos vários envolvidos no projeto e o registro de históricos e
estados dos diversos itens sob o controle da ferramenta.
O suporte à gerência de modificações envolve o acompanhamento das modificações e
geração de relatórios, de maneira a permitir uma visão precisa da situação das
modificações, a qualquer momento.
75
Segundo Dart (Dart, 1996), as ferramentas de GCS podem ser classificadas, de maneira
simplificada, de acordo com suas características funcionais. Assim tem-se:
•
Ferramentas de controle de versões, que implementam os conceitos de
controle de versões, como apresentados na Seção 2.2.2.
•
Ferramentas orientadas ao desenvolvedor, que, além do controle de versões,
oferecem suporte ao trabalho em equipe, facilitando o desenvolvimento
concorrente. Caracterizam-se também pela integração ao ambiente de
desenvolvimento.
•
Ferramentas orientadas a processo, que oferecem o controle de versões e
suporte
a
parte
das
funcionalidades
das
ferramentas
orientadas ao
desenvolvedor, cuja característica principal é a automatização do gerenciamento
do ciclo de vida dos objetos envolvidos no desenvolvimento do software. Podem
fornecer também uma abordagem integrada ao gerenciamento das solicitações
de modificação.
Uma ferramenta de gerenciamento da configuração, no entanto, não é um instrumento
isolado e nem substitui a falta de um processo compreensível e definido (Starbuck,
1997). Independente da adoção de uma ferramenta automatizada de última geração, a
GCS só pode ser implantada em uma organização de maneira satisfatória desde que haja
conhecimento dos princípios básicos da GCS e um processo bem definido.
Sem a definição de um processo de GCS, um projeto de desenvolvimento de software
pode ser prejudicado, e até mesmo ter o seu bom andamento comprometido. O suporte
ao processo da GCS é, portanto, o foco da abordagem proposta para o Ambiente
Integrado.
Em resumo, a utilização de uma ferramenta automatizada de GCS facilita e até mesmo
viabiliza algumas de suas atividades, em alguns casos. Mas não é suficiente para que o
controle sobre as modificações no produto de software exista, nem que a integridade do
produto seja mantida durante seu desenvolvimento. Assim, um processo definido é a
76
solução mais eficaz. Se este processo contar com o suporte de mecanismos, como os
citados na Seção 2.8, automatizados, além de treinamento adequado dos usuários, as
chances de sua implementação bem sucedida são ainda mais elevadas.
77
78
CAPÍTULO 3
MODELAGEM, PADRÕES E AMBIENTES CENTRADOS EM PROCESSO DE
SOFTWARE
Neste Capítulo apresentam-se os conceitos, as técnicas e os padrões que apresentam a
GCS como processo integrante, utilizados na abordagem proposta, e o Ambiente
Integrado, que serve de contexto para o trabalho.
Um dos conceitos básicos utilizados na abordagem proposta nesta dissertação é o de
processo de software. Pode-se definir um processo de software (Fuggetta, 2000) como
um conjunto de políticas, estruturas organizacionais, tecnologias, procedimentos e
artefatos necessários para conceber, desenvolver, construir e manter um produto de
software.
A técnica de modelagem de processo de software refere-se à definição destes processos
como modelos, que são expressos em uma linguagem de modelage m adequada, aliada,
opcionalmente, a algum suporte computacional automatizado, disponível para modelar e
executar estes modelos (Acuña e Ferré, 2001). As linguagens utilizadas para expressar
estes modelos são conhecidas como Linguagens de Modelagem de Processo (Process
Modeling Languages – PMLs). As ferramentas de suporte utilizadas para a definição, a
análise, a execução e a melhoria de um modelo de processo são conhecidas como
Ambientes de Engenharia de Software Centrados em Processos (Process-Centered
Software Engineering Environments – PSEEs).
Modelos de referência para processos de software podem ser encontrados em padrões
como o ISO/IEC 12207 (ISO/IEC12207, 2001), que descreve os processos para
desenvolvimento e manutenção de software, fornecendo um conjunto essencial de
atividades que devem ser completadas para a obtenção de um produto de software. O
padrão ISO/IEC 15504 (ISO/IEC 15504, 2003) fornece um framework para a avaliação
de processo e estabelece um conjunto mínimo de requisitos para execução de uma
avaliação, de forma a verificar o nível em que as organizações se encontram, em termos
79
de maturidade dos processos e das práticas organizacionais utilizadas no
desenvolvimento de software.
Estes padrões utilizam um mesmo modelo de referência de processo (Process Refrence
Model – PRM), isto é, um modelo que compreende as definições dos processos em um
ciclo de vida descrito em termos de objetivos do processo e resultados, juntamente com
uma arquitetura que descreve os relacionamentos entre os processos.
O ISO/IEC 15504 (ISO/IEC 15504-5, 2003) fornece um exemplo de modelo para dar
suporte à avaliação de processo (Process Assessment Model – PAM), e contém
orientações sobre boas práticas de engenharia de software e gerenciamento que devem
ser consideradas na interpretação da finalidade do modelo de referência de processo.
Neste trabalho, o propósito e as atividades da GCS do padrão ISO/IEC 12207 (ISO/IEC
12207, 1995) e as práticas básicas do padrão ISO/IEC 15504 (ISO/IEC 15504-5)
servem como referência para os processos básicos da GCS no Ambiente Integrado. A
linguagem de modelagem de processo utilizada para defini- los e representá- los é o
Software Process Engineering Metamodel (SPEM) (OMG SPEM, 2002) que, através de
diagramas com notação gráfica da Unified Modeling Language (UML), permite
representar de forma compreensível as várias características ou elementos do processo
da GCS, facilitando sua implantação e execução em um ambiente de engenharia de
software centrado em processo.
O Ambiente Integrado para Apoio ao Desenvolvimento e Gestão de Projetos de
Software, (Sant’Anna, 2000) é o ambiente centrado em processo que define o contexto
para a abordagem proposta, e que se propõe a dar suporte à descrição e à execução
desses processos de modo a auxiliar e controlar todas as atividades envolvidas na
produção e manutenção de um projeto de software.
80
3.1
Processos de Software, Modelos de Processos e Ambientes Centrados em
Processos
A pesquisa na área de processo de software levou ao entendimento de que desenvolver
software não consiste apenas na utilização de linguagens de programação poderosas e
ferramentas eficazes, mas é um esforço coletivo, complexo e criativo (Fuggeta, 2000).
Assim, a qualidade do produto de software depende de pessoas, da organização e de
procedimentos usados para criá- lo e entregá- lo. Esta visão tem sua origem em trabalhos
de pesquisa realizados ainda nas décadas de 60 e 70, que tinham o foco nas técnicas de
programação estruturada, nos métodos de projeto, como a decomposição funcional e o
refinamento top-down, bem como na definição de um modelo de ciclo de vida para o
produto de software. Este último tópico está diretamente relacionado com a noção de
processo de software (Fuggeta, 2000).
De maneira geral, um ciclo de vida do software define uma estrutura e uma maneira de
acordo com as quais o processo de software deve ser realizado.
O ciclo de vida do software compreende um período de tempo que começa quando o
produto de software é concebido e termina quando o software já não está mais
disponível para uso. Um ciclo de vida tipicamente inclui as fases de concepção,
requisitos, projeto, implementação, teste, instalação, operação e manutenção (IEEE 610,
1990). Além disto, o ciclo de vida do software define também os princípios e
orientações para condução destes estágios. O modelo em cascata sugere que uma fase
específica só deve começar quando as entregas da fase anterior são completadas. O
modelo em espiral, considera o desenvolvimento de software como uma iteração
sistemática de várias atividades dirigidas pela análise de risco.
Um ciclo de vida, no entanto, não prescreve uma direção precisa de ações, nem como
elas devem estar organizadas, ou quais ferramentas e procedimentos operacionais,
políticas de desenvolvimento e restrições são aplicáveis ao projeto (Fuggeta, 2000).
Assim, não é suficiente para conduzir e controlar um projeto de software, ainda que seja
certamente um ponto de partida importante para definir como o software deve ser
desenvolvido.
81
Deste modo, a idéia de processo de software veio ampliar a noção de ciclo de vida
(Fuggeta, 2000), fornecendo um conceito mais abrangente e compreensível para
estruturar e organizar os diferentes fatores e questões relacionadas às atividades de
desenvolvimento de software.
Processo de software pode também ser definido como um conjunto parcialmente
ordenado de atividades, responsável pelo gerenciamento, desenvolvimento e
manutenção de sistemas de software (Acuña et al., 2000).
A visão do desenvolvimento de software como um processo ajuda a identificar suas
dimensões e problemas que precisam ser resolvidos para que práticas efetivas sejam
estabelecidas nas organizações.
Segundo Osterweil, estas organizações diferem em sua cultura, habilidades das pessoas,
produtos entregues, estratégias comerciais e de desenvolvimento (Osterweil, 1987;
Cugola e Ghezzi, 1998). Mesmo dentro de uma organização, projetos diferentes
apresentam variações. Como conseqüência, não existe um único e acabado processo de
desenvolvimento de software. O processo deve ser definido com base no problema a ser
solucionado, adaptado às características específicas do projeto e levar em consideração
as particularidades da organização e do produto que está sendo desenvolvido. Além
disto, os processos de software podem apresentar comportamentos indesejados ou
inesperados. Os produtos que são entregues podem não possuir a qualidade desejada,
em termos de confiabilidade, funcionalidade ou desempenho. Isto motivou uma série de
projetos voltados para a criação de padrões de modelos de qualidade e melhoria de
processo de software.
Ainda segundo Osterweil, o desenvolvimento de modelos de processo é semelhante ao
de software. Possui características específicas, passa por fases diferentes e requer
ferramentas específicas para ser suportado. Assim também os ambientes que suportam o
desenvolvimento de software devem ser adequados ao processo de desenvolvimento
específico. Para satisfazer estes objetivos, Osterweil (Osterweil, 1987) concluiu na
época que seriam necessárias linguagens para descrição dos processos de
desenvolvimento de software. Os modelos resultantes deveriam ser verificáveis e
82
executáveis. Isto requeria novos ambientes de desenvolvimento de software capazes de
suportar o desenvolvimento, documentação, análise, execução e evolução de modelos
de processos (Cuggola e Ghezzi, 1998).
Este ponto de vista estimulou, desde então, uma área de pesquisa ativa, voltada para o
desenvolvimento de Ambientes de Engenharia de Software Centrados no Processo (em
inglês, Process-centered Software Engineering Environments – PSEEs,) (Cuggola e
Ghezzi, 1998).
Os PSEEs, apresentados em (Ellmer, 1995) como ferramentas para suportar tanto a
execução como a melhoria dos processos, são ambientes que se propõem a melhorar a
comunicação entre os elementos envolvidos, acompanhar a situação atual dos produtos
e dos processos, permitir, entre outras coisas, ações automáticas durante o
desenvolvimento e conduzir o fluxo das atividades. Como exemplos de PSEEs podem
ser citados o SPADE-1 (Bandinelli et al., 1996), Oz (Ben-Shaul e Kaiser, 1994) e o
PROMENADE (Franch e Ribó, 1999).
Um modelo de processo dentro de um PSEE é instanciado pelo ambiente através de um
cronograma, definindo os desenvolvedores que atuarão no processo, os recursos a serem
alocados e os artefatos a serem manipulados. Um mecanismo de execução (enactment) é
responsável pela coordenação das atividades descritas em um modelo de processo, que
podem ser realizadas por desenvolvedores ou agentes de forma automatizada.
Segundo (Fuggetta, 2000) para que estes ambientes não se tornem complexos e
intrusivos, deve-se automatizar apenas processos ou fragmentos de processo que sejam
razoáveis para se automatizar, ou seja, atividades repetitivas e cansativas, como por
exemplo, o check-out de uma versão de um item de configuração. Liberando o
engenheiro de software ou desenvolvedor de um trabalho repetitivo, não só se reduz a
chance de erros, como também o tempo de entrega do produto.
Uma classificação e apresentação das características destes ambientes podem ser
encontradas em (Ambriola, et. al., 1997). Um interessante panorama do trabalho de
83
Osterweil e de outros pesquisadores na área de processo de software, inclusive os
citados anteriormente, pode ser encontrado em (Osterweil, 2003).
3.2
A Técnica de Modelagem de Processos
3.2.1
Eleme ntos de um Processo de Software
Em um processo de software podem-se identificar vários elementos a serem modelados,
como as atividades, os produtos e os recursos necessários para execução destas e os
papéis desempenhados pelos executores.
Existem várias classificações referentes aos principais elementos de um modelo de
processo (Conradi et. al., 1994; Feiler, 1993; Benali e Derniame, 1992; Finkelstein,
1994). Em (Acuña e Ferré, 2001) apresentam-se os seguintes elementos, como os mais
comumente modelados (Figura 3.1):
•
Agentes ou atores: entidades que executam um processo. Podem ser divididos
em dois grupos: a) atores humanos, que são pessoas que desenvolvem software
ou estão envolvidas no processo de software e estão, provavelmente,
organizados em equipes; b) atores sistemas ou ferramentas de sistema, que são
software de computador ou componentes de hardware. Um ator é caracterizado
pelas propriedades dos seus papéis e de suas disponibilidades e pode
desempenhar vários papéis, que são compostos de um conjunto consistente de
atividades. Um papel pode ser atribuído a vários atores cooperativos.
•
Papéis: descrevem um conjunto de responsabilidades de agentes ou grupos, os
direitos e habilidades requeridas para realizar uma atividade específica do
processo de software. São associações entre agentes e atividades em termos de
definição do conjunto de responsabilidades executadas pelos agentes.
•
Atividades: uma atividade é o estágio de um processo que produz mudanças de
estado externamente visíveis no produto de software. Uma atividade pode ter
uma entrada, uma saída e alguns resultados intermediários chamados
84
genericamente de produtos. Inclui e implementa procedimentos, regras, políticas
e objetivos para gerar e modificar um conjunto de artefatos. Pode ser realizada
por um agente humano ou por uma ferramenta e dividida em outras atividades,
mais elementares. Pode ser organizada em redes com dimensão horizontal
(encadeadas) e vertical (decomposta). É associada a papéis, outras atividades e
artefatos.
•
Artefatos ou Produtos : constituem-se no sub(produto) e na matéria prima de
um processo. Um artefato produzido por um processo pode ser usado depois
como entrada para o mesmo ou outros processos, para produzir outros artefatos.
Um artefato ou produto de software é desenvolvido e mantido dentro de um
processo. Um artefato pode ter uma longa duração. Podem existir diferentes
artefatos, à medida que o processo de software se desenvolve. Os (sub)produtos
podem ser criados, acessados ou modificados durante a atividade do processo.
Um conjunto de artefatos de software que serão entregues para um usuário é
chamado produto de software. Portanto, um relacionamento "composto de" pode
aparecer entre produtos.
Composto_de
Composto_de
Executa
PAPEL
ATIVIDADE
Executa
Composto_de
Entradas
Saídas
ATOR
PRODUTO
FIGURA 3.1 - Elementos e Relacionamentos de um Modelo de Processo.
FONTE: Adaptada de Acuña e Ferré (2001, p.2).
85
3.2.2
As Linguagens de Modelagem de Processos
Pelo fato dos processos de software serem entidades complexas, os pesquisadores da
área criaram uma variedade de linguagens e formalismos de modelagem, chamados de
Linguage ns de Modelagem de Processos (Process Modeling Languages – PMLs), para
de alguma maneira, formalizar estes processos. Estas linguagens permitem representar,
de maneira compreensível e precisa, os vários elementos do processo de software
identificados anteriormente, ou seja, as PMLs são constituídas de elementos core com
semânticas próprias, que representam os elementos comuns dos processos, e um
conjunto de associações utilizadas para a construção do modelo (Conradi e Liu, 1995).
Estas linguagens (Fuggeta, 2000), dos mais diferentes tipos, são geralmente baseadas
em paradigmas lingüísticos, como as Redes de Petri, que recebem extensões para
aumentar suas capacidades de expressão; outras abordagens, como a de Osterweil
(Osterweil, 1987), baseiam-se na idéia de que os processos podem ser descritos usando
o mesmo tipo de linguagem usada para criar software convencional (a idéia que
“processo de software é software também”).
Diversas classificações para as linguagens de processo de software são encontradas na
literatura, como a de (Zamli e Lee, 2001). Segundo os autores, uma classificação pode
ser obtida pela identificação das partes do ciclo de vida do processo que a PML suporta,
seguindo uma similaridade com o ciclo de vida do desenvolvimento de software, tendose, assim: Linguagens de Especificação de Processos, Linguagens de Projeto de
Processos e Linguagens de Implementação de Processos.
Já uma visão mais operacional das PMLs, sugere uma classificação baseada na
execução (enactement) do modelo de processo especificado em uma PML, já que um
processo de software só pode orientar, fazer cumprir e automatizar atividades da
engenharia de software através de sua execução.
Assim, segundo o suporte à execução do processo uma PML pode ser: não executável,
quando suporta somente o entendimento do processo e não sua execução; simulada,
quando permite a simulação em alto nível de um modelo de processo, que normalmente
86
ajuda no projeto de novos processos de software, mas não fornece uma orientação mais
detalhada ou controle do processo de software; e executável, quando permite que o
modelo de processo especificado seja executado para orientar de maneira ativa ou até
mesmo controlar um processo de software.
Como representantes desta última categoria, podem-se destacar as linguagens
Environment for Experimenting and Envolving Software Processes (E3), (Jacheri et al,
1998; Jacheri et al, 1999) e Process-oriented Modelling and Enactment of Software
Developments (PROMENADE) (Franch e Ribó, 1999).
A PML E3 oferece um conjunto de entidades básicas (tarefas, papéis, ferramentas e
artefatos) e relacionamentos envolvidos em processos de software. Estas entidades
podem ser adequadas às necessidades particulares do modelador por meio do uso de
herança.
A PML PROMENADE, assim como a E3, tem suas raízes baseadas em metodologias
orientadas a objetos. O meta-modelo PROMENADE apresenta elementos comuns como
meta-tarefas, meta-documentos, etc; está sendo desenvolvido com base na extensão do
metamodelo UML como classes pré-definidas.
Alguns pesquisadores voltaram-se à experimentação da UML como uma PML
(Schleicher et. al., 1998; Jäger et. al., 1999). A UML apresenta, como vantagem
competitiva em relação às PMLs mais especializadas, o fato de ser mais popular e
largamente utilizada, mas tem, no entanto, a limitação de não ter sido concebida como
uma linguagem executável por uma máquina de processo. Ainda recentemente, estudos
têm sido feitos no sentido de empregar um subconjunto da UML como uma PML
executável (Di Nitto et. al., 2002).
3.2.3
Os propósitos das PMLs
De acordo com Fuggetta (Fuggeta, 2000), as linguagens de modelagem de processos
podem ser utilizadas para diversos propósitos, como:
87
•
Entendimento do processo: Um modelo de processo pode ser utilizado para
representar, de uma forma precisa, como o processo está estruturado e
organizado, tornando-se um instrumento importante para a eliminação de
inconsistências na especificação do processo.
•
Projeto de um processo: Um modelo de processo pode ser utilizado para o
projeto de um novo processo, descrevendo sua estrutura e organização.
•
Treinamento e educação: Uma descrição precisa do processo pode ser útil para
o treinamento e aprendizado de equipes sobre procedimentos e operações
organizacionais.
•
Simulação e otimização de processos : Uma descrição de um processo pode ser
útil para a avaliação de problemas e propostas para melhorias.
•
Suporte a processos : Uma descrição detalhada de um processo pode ser
interpretada e utilizada para fornecer diferentes níveis de suporte para pessoas
envolvidas no processo.
3.2.4
Abordagens para a Modelagem de Processos
Um processo pode ser modelado em diferentes níveis de abstração e sob diferentes
pontos de vista. Assim, as informações contidas em um modelo podem ser estruturadas
sob perspectivas variadas, sendo, segundo (Curtis e Kellner, 1992; Acuña e Ferré, 2001)
as mais usualmente encontradas na literatura:
•
Funcional: representa quais elementos de processo estão sendo implementados
e quais fluxos de informação são importantes para estes elementos.
•
Comportamental: representa quando (seqüência) e sob quais condições os
elementos de processo são implementados.
•
Organizacional: representa onde e por quem os elementos de processo são
implementados.
88
•
Informativa: representa as entidades de informação que são manipuladas por
um processo, incluindo sua estrutura e relacionamentos.
Acredita-se que estas perspectivas devem ser contempladas, em maior ou menor grau,
em um modelo de processo.
3.3
A Linguagem de Modelagem de Processo SPEM
O Software Process Engineering Metamodel (SPEM) é um metamodelo que pode ser
usado para descrever um processo concreto ou uma família de processos de
desenvolvimento de software relacionados (OMG SPEM, 2002). Foi desenvolvido pelo
Object Management Group (OMG), para tentar suprir a necessidade de um padrão para
as técnicas de modelagem de processo surgidas nos últimos anos. A execução do
processo (enactment) não está no escopo deste modelo.
O SPEM define o conjunto mínimo de elementos de modelagem necessários para
descrever qualquer processo de desenvolvimento de software, utilizando uma
abordagem orientada a objetos e a UML. A UML é uma linguagem gráfica para
modelagem de sistemas discretos, de maior aplicabilidade na área de projeto de
software orientado a objetos.
Além de ser definido como um metamodelo, o SPEM é também definido como um
perfil da UML. Um perfil contém uma ou mais extensões relacionadas da semântica
padrão da UML, para adaptá- la a um domínio ou propósito particular. Esta extensão é
feita através de mecanismos conhecidos como estereótipos, valores atribuídos e
restrições. Um estereótipo, por exemplo, estende o vocabulário da UML, permitindo a
criação de novos blocos de construção derivados dos já existentes.
Um fator que favorece a escolha do SPEM para a definição de processos é que ele tanto
define capacidades de modelagem dedicadas ao domínio do processo de software,
quanto se beneficia da expressividade da UML. Assim, desenvolvedores de software
que estejam familiarizados com a UML podem reutilizar seus conhecimentos de
modelagem de software no domínio da modelagem de processos de software.
89
3.3.1
Arquitetura da Modelagem
Existem sempre três níveis de abstração para qualquer contexto de modelagem. Há o
próprio modelo (nível M1), há instâncias do modelo (nível M0), e há um conjunto de
construtores/regras para a construção do modelo (nível M2). Existem também os metametamodelos (nível M3) que são como um terceiro nível de abstração para um
modelador. Um bom exemplo de nível 3 é o Meta Object Facility (MOF) que define um
meta- metamodelo (também chamado de modelo MOF) simples e com semântica
suficiente para descrever meta modelos em vários domínios, sendo o foco inicial metamodelos de análise e projetos OO.
Um meta-metamodelo é na verdade uma linguagem que cria ou define um metamodelo;
uma linguagem na qual um metamodelo pode ser expresso A integração entre metamodelos se dá pelas interfaces também providas pelo MOF, sendo necessária para a
integração de ferramentas e aplicações (pelas diversas fases do ciclo de vida) utilizando
uma semântica comum.
A TABELA 3.1 mostra a arquitetura em 4 camadas de modelagem definida pela OMG
envolvendo os níveis de abstração de modelagem.
TABELA 3.1 – Níveis de Abstração da Modelagem de Processos.
M0 Um processo em execução – isto é, um processo de produção do mundo
real enquanto ele é executado.
M1 A definição do processo correspondente. Esta camada inclui processos
genéricos bem como a adaptação destes processos para um dado projeto
(como o RUP - Rational Unified Process, Open).
M2 Metamodelo de Processo (SPEM, UML). Esta camada serve como um
modelo para o nível M1.
M3 Meta Object Facility (MOF)
90
3.3.2
Elementos da Linguagem SPEM
Um processo pode ser visto como uma colaboração entre papéis para alcançar uma certa
meta ou objetivo. Para conduzir sua execução (enactement) pode-se restringir a ordem
na qual atividades devem, ou podem ser executadas. Existe também uma necessidade de
definir a forma do processo no tempo, e sua estrutura de ciclo de vida em termos de
fases e iterações.
Um ProcessComponent significa um conjunto não arbitrário de elementos de definição
de processo, modelados em SPEM.
Um WorkProduct ou artefato é alguma coisa produzida, consumida ou modificada por
um processo. Pode ser um pedaço de informação, um documento, um modelo, código
fonte. Descreve uma classe e uma categoria de produto de trabalho produzido em um
processo, como um Documento Texto, Modelo UML, Executável e Biblioteca de
Código. Os tipos de produto de trabalho variam dependendo do processo que está sendo
modelado.
Uma WorkDefinition é um tipo de operação que descreve o trabalho executado no
processo. Suas subclasses são Activity, Phase, Iteration e LifeCycle. Uma
WorkDefinition pode ser composta de outras WorkDefinitions, e estas podem estar
relacionadas a WorkProducts usados como entrada ou saída, especificados pela classe
ActivityParemeter.
Um LifeCycle é definido como uma seqüência de fases que alcançam uma meta
específica. Ele define o comportamento de um processo completo a ser executado em
um dado projeto.
O ProcessRole auxilia a definição do WorkProduct como entrada ou saída do processo.
Pode-se estabelecer uma relação de dependência entre uma WorkDefinition e outra para
indicar dependências início- início, fim- início ou fim- fim entre elas. Por exemplo, se a
atividade B tem uma dependência fim- início com uma atividade A, então B pode iniciar
somente depois que A terminou.
91
Uma Activity é a subclasse principal de WorkDefinition que descreve uma parte do
trabalho executado por um ProcessRole, suas tarefas, operações e ações que são
executadas. Uma Activity pode consistir de elementos atômicos chamados Steps.
Uma Phase é uma especialização de WorkDefinition, que é um tipo de operação que
descreve o trabalho executado no processo. Em uma Phase, uma pré-condição define o
critério de entrada e uma meta define o critério de saída da fase. Phases têm a restrição
adicional de seqüencialidade, isto é, suas atividades são executadas de acordo com
marcos distribuídos no tempo.
Uma Iteration é uma composição de WorkDefinition com um marco secundário. Estes
elementos não descrevem a execução em si, são elementos da descrição do processo
usados para ajudar a planejar e executar aquela descrição.
Uma WorkDefinition tem um ProcessPerformer próprio, representando o papel
principal que a executa no processo. Um ProcessRole é responsável por um conjunto de
WorkProduct.
Uma dependência entre WorkProducts indica que a modificação feita em um pode
invalidar o outro.
O ProcessPerformer tem uma subclasse, ProcessRole que define responsabilidades
sobre WorkProduct específicos, e define os papéis que executam e ajudam em
atividades específicas. Um ProcessPerformer é o executante de WorkDefinitions
agregadas de mais alto nível que não podem ser associadas a ProcessRoles individuais.
É possível agrupar mais de uma Activity em uma Discipline. Uma Discipline é uma
especialização particular de Package que particiona as atividades dentro de um processo
de acordo com um tema comum. A inclusão de uma Activity em uma Discipline é
representada pela dependência Categorizes, com a restrição adicional que toda Activity é
categorizada por exatamente uma Discipline. A dependência Categorizes fornece um
meio de associar elementos de processo a múltiplas categorias.
92
Como na UML, um Package é um recipiente que pode tanto possuir como importar
elementos de definição de processo. Package e a dependência Categorizes podem ser
usados para implementar uma categorização geral de elementos de descrição de
processo. Um Package é criado para representar esta categoria e todos os elementos
ligados pela dependência Categorizes ao pacote.
Guidances podem ser associados a todos os elementos de modelo do SPEM a fim de
fornecer informação mais detalhada aos praticantes sobre o elemento associado. Os
tipos possíveis são: GuideLine, que é composto de um conjunto de regras e
recomendações de como um dado produto deve ser visto ou organizado; Technique, que
é um algoritmo detalhado usado para criar um produto de trabalho e ajudam a definir as
habilidades requeridas para executar tipos específicos de atividades; o UMLProfile
fornece mecanismos que especializam a UML para um plataforma ou propósito
específico como análise, projeto, e assim por diante. Toda atividade de desenvolvimento
que utiliza UML pode ser regida por um profile, que dita as regras de consistência da
UML que precisam ser aplicadas ou qual elemento de modelo UML é relevante para o
contexto atual e o foco da atividade.
Um ToolMentor mostra como usar uma ferramenta específica para realizar uma
atividade e está associado a uma única ferramenta. Um CheckList representa uma lista
de elementos que precisa ser completado. O Template provê um documento de formato
padrão para um determinado WorkProduct. Estimate descreve o esforço associado com
um elemento em particular.
3.3.3
A notação SPEM
No SPEM, diagramas da UML podem ser usados para apresentar os vários aspectos de
um modelo de processo de software, como os diagramas de classe, de pacote, de
atividade, de caso de uso, de seqüência e de estados, com algumas restrições. Os
diagramas de implementação e componentes não são usados porque contêm alguns
elementos semânticos da UML que foram excluídos do SPEM.
93
Diagramas de classe permitem a representação de aspectos do processo de software
como
herança,
dependências;
associações
simples;
relacionamentos
entre
ProcessPerformer ou ProcessRole e WorkProduct; estrutura, decomposição e
dependências de WorkProdutcts.
Diagramas de Pacote permitem a representação de Process, ProcessComponents,
ProcessPackages e Disciplines. Podem ser usados formatos aninhados ou não
aninhados para a representação dos pacotes.
O diagrama de casos de uso, por exemplo, pode ilustrar o relacionamento entre os
envolvidos e as atividades do processo. As dependências <<perform>> e <<assist>>
podem ser usadas para se definir as relações entre um ator e o seu caso de uso.
Outro diagrama usado, o de atividades, permite a apresentação da seqüência de
atividades com seus produtos de trabalho de entrada e saída, bem como os estados do
fluxo de objetos. Raias podem ser utilizadas para separar as responsabilidades dos
diferentes papéis do processo.
Diagramas de seqüência podem ainda ser utilizados para ilustrar padrões de interação
entre instâncias de elementos do modelo SPEM, bem como diagramas de estado podem
ser usados para ilustrar o comportamento de elementos do modelo.
Os elementos de definição do processo do SPEM são representados por estereótipos.
Ícones especiais foram criados para os mais freqüentemente utilizados, como atividades,
produtos de trabalho, papéis, etc. A TABELA 3.2 mostra os principais ícones utilizados
no desenvolvimento dos modelos de processo.
94
TABELA 3.2 - Principais Ícones e Estereótipos do SPEM.
Estereótipo
Comentário
Notação
WorkProduct
É uma descrição de um pedaço de informação ou entidade física
produzida ou usada pelas atividades de um processo de engenharia
de software. Exemplos: modelos, planos, código, documentos,
base de dados, etc.
WorkDefinition
Descreve a execução, as operações executadas e as transformações
executadas nos WorkProducts pelos papéis. Tipos: Activity,
Phase, Iteration e LifeCycle.
Guidance
É associado aos principais elementos do modelo, e contém
descrições adicionais como técnicas, orientações, procedimentos,
padrões, modelos de documentos, etc. Exemplos: Guideline, Tool,
Checklist e Template .
Activity
Descreve o que um ProcessRole executa. As atividades são o
principal elemento do trabalho e descrevem as tarefas, as
operações e ações que são executadas por um papel.
ProcessPerformer
Define um executante para um conjunto de WorkDefinition em um
processo. É usado para WorkDefinitions que não podem ser
associadas a ProcessRoles individuais.
ProcessRole
Descreve os papéis, as responsabilidades e competências de um
indivíduo na execução de Activities em um processo e a
responsabilidade sobre certos WorkProducts.
ProcessPackage
Representação de um pacote do SPEM.
Phase
Especialização de WorkDefinition com critério de entrada definido
por pré-condição e critério de saída definido por seu objetivo (ou
marco), com restrição de seqüência.
Process
Descreve completamente um processo de engenharia de software,
em termos de ProcessPerformers, ProcessRoles,
WorkDefinitions, WorkProducts e Guidances associados.
Document
Diferentes tipos de WorkProduct como por exemplo Documento
Texto, um Modelo UML, Executável, Biblioteca de Código, etc.
UML Model
Um modelo representado em UML.
95
3.4
Padrões de Processos de Software e Modelos de Maturidade
O padrão ISO/IEC 12207 (ISO/IEC, 1995) prescreve um processo para o
desenvolvimento e manutenção de software, através da determinação de um conjunto de
atividades essenciais que devem ser completadas para se obter um produto de software.
Neste padrão, os processos que envolvem o ciclo de vida do software são agrupados em
três categorias, segundo a natureza deles: primários, de suporte e organizacionais.
Cada processo é, então, definido em termos de suas próprias atividades e cada atividade
é adicionalmente definida em termos de suas tarefas (Rocha et. al., 2001).
Independentemente do processo de desenvolvimento de software utilizado, o grau de
implantação deste varia de uma organização para outra e mesmo de um projeto para
outro. Na realidade, a partir de uma estrutura de um processo de desenvolvimento, uma
equipe normalmente define a forma como este vai ser implantado, os procedimentos que
serão adotados, os métodos e as ferramentas que serão utilizados, bem como as métricas
e medidas que serão coletadas.
Um modelo de maturidade procura avaliar a capacidade que uma organização
desenvolvedora de software tem em implementar a metodologia escolhida, ou seja,
avaliar sua maturidade na implementação do processo escolhido.
Em geral os modelos de maturidade buscam fornecer orientações às organizações para a
melhoria contínua de seus processos de construção de software. Visando estas
melhorias, estabelecem e colocam em ordem de prioridade as ações que devem ser
realizadas para se evitar erros e repetição de trabalho durante o ciclo de
desenvolvimento do software. Através de níveis de maturidade, os modelos permitem às
organizações buscarem, de maneira consistente, os requisitos do próximo nível a ser
atingido, compostos por objetivos de processo que, quando atingidos, indicam um
crescimento na maturidade do processo.
A capacidade de uma organização em executar uma disciplina ou área de processo
específico pode ser avaliada para uma única área de processo ou um conjunto de áreas
de processo, considerando-se um modelo dito contínuo, ou para um conjunto
96
estabelecido de áreas de processo através de uma organização, no chamado modelo em
estágios.
Alguns dos padrões de processo e modelos de maturidade mais utilizados e conhecidos
internacionalmente são o modelo Capability Maturity Model (CMM) do Software
Engineering Institute (SEI), da Universidade de Carnegie Mellon nos EUA (CMM-SW,
1993), que evoluiu para o Capability Maturity Model Integration (CMMI) (CMMI-SW,
2002) e também o ISO/IEC 15504 Este último teve suas origens no modelo Software
Process Improvement and Capability dEtermination (SPICE), desenvolvido dentro do
ISO/IEC JTC/SC7 (Subcomitê de Engenharia de Software) visando harmonizar as
várias abordagens para avaliação de processos existentes (como o CMM, o Trillium e o
Bootstrap), que resultou no ISO/IEC 15504, publicado em 1998 na forma de Relatório
Técnico, e como padrão internacional (Parte 2) em 2003.
Enquanto o padrão ISO/IEC 12207 prescreve um processo para o desenvolvimento e
manutenção de software, o padrão 15504 define uma estrutura para avaliação e melhoria
de processos de engenharia de software, e prescreve práticas básicas que devem ser
realizadas para que se atinjam certos níveis de maturidade. Ambos baseiam-se no
mesmo modelo de referência, de modo que uma abordagem baseada no 15504 está
alinhada ao 12207.
Pode-se constatar uma tendência de crescimento do interesse nestes padrões e modelos
no Brasil. Segundo pesquisa do Ministério da Ciência e Tecnologia (MCT)
(Nascimento, 2001), o nível de conhecimento destes modelos e padrões pelas
organizações de TI vem aumentando nos últimos anos. Isto é o que se verifica nos
Relatórios de Qualidade e Produtividade no Setor de Software Brasileiro de 1999 e de
2001, editados bienalmente pela Secretaria de Política de Informática do Ministério da
Ciência e Tecnologia – MCT (MCT/SEPIN, 1999; 2001).
O nível de conhecimento do CMM mais que triplicou de 1995 a 1999, passando de 14%
para 47%. O resultado de 43% alcançado em 1999 para conhecimento do padrão
ISO/IEC foi significativamente superior ao de 25% obtido na primeira medição deste
indicador em 1997. Este padrão, aprovado em 1995, está publicado no Brasil como
97
NBR ISO/IEC 12207: Tecnologia da informação – Processos de ciclo de vida de
software. Também foram apurados ganhos históricos significativos de 18% em 1997
para 31% em 1999 quanto ao conhecimento do15504 (Nascimento, 2001).
Junto com o aumento do interesse pelos padrões cresce também o interesse pela GCS, já
que todos estes padrões incluem requisitos para a Gerência da Configuração, apesar
destes requisitos variarem de modelo para modelo, e também a maneira como a GCS
toma parte nos métodos de avaliação de maturidade.
3.4.1
A Gerência da Configuração de Software em Padrões e Modelos de
Maturidade
Os propósitos, as atividades e as práticas básicas dos modelos de processo dos padrões
12207 e 15504 servem de ponto de partida para a definição do processo da GCS nesta
abordagem. Esta escolha é devida à própria utilização do modelo SPICE na concepção
geral do Ambiente Integrado (SantÁnna, 2000), sendo o 15504 uma evolução deste
modelo.
O modelo definido pelo padrão 15504 é um modelo bidimensional. Em uma dimensão,
a de processo, os processos são definidos e classificados em categorias. Na segunda
dimensão, a de capacidade, uma série de atributos de processo agrupados em níveis de
capacidade são definidos.
A dimensão de processo do 15504 está baseada nos propósitos e resultados descritos no
ISO/IEC 12207 AMD 1, e nas atividades e tarefas do ISO/IEC 12207, existindo uma
referência cruzada destas com cada prática básica associada, no caso da Gerência da
Configuração. Na nova versão do 15504 (ISO/IEC 15504-5, 2003), no entanto, o
processo de Gerência das Solicitações de Modificação é novo, não constando ainda da
estrutura do ISO/IEC 12207.
Cada processo na dimensão de processo tem um conjunto de práticas básicas
associadas, cuja execução fornece uma indicação da extensão da obtenção do propósito
98
do processo. Associados aos processos e suas práticas básicas estão os produtos de
trabalho que são utilizados ou produzidos durante a execução do processo.
3.4.1.1
A GCS e o Padrão ISO/IEC 12207
O padrão 12207 (ISO/IEC 12207/AMD 1, 2001) define o propósito do processo da GCS
como sendo o de estabelecer e manter a integridade de todos os produtos de trabalho de
um processo ou projeto e torná- los disponíveis às partes interessadas.
Como resultado de uma implementação bem sucedida do processo da GCS:
•
Uma estratégia para a gerência da configuração é desenvolvida;
•
Todos os itens gerados pelo processo ou projeto são identificados, definidos e
colocados em uma configuração-base;
•
Modificações e liberações dos itens são controladas;
•
Modificações e liberações são disponibilizadas para as partes interessadas;
•
A situação dos itens e das solicitações de modificações é registrada e relatada;
•
A integridade e consistência dos itens são garantidas; e
•
O armazenamento, o tratamento e a entrega dos itens são controlados.
Para que estes objetivos sejam alcançados, o processo da GCS deve realizar as
atividades de: implementação do processo, identificação, controle, relato da situação e
avaliação da configuração e gerenciamento da liberação e entrega.
3.4.1.2
A GCS no Modelo ISO/IEC 15504
O padrão 15504 é dividido em 5 partes, sob o título geral de Tecnologia da Informação
– Avaliação de Processo. Nesta dissertação, utiliza-se como referência a parte 5
(ISO/IEC CD 15504-5) que fornece um exemplo de modelo para suportar a avaliação de
99
processo e contém ainda orientações sobre as práticas básicas de engenharia de software
a serem consideradas na interpretação do modelo de referência, apresentado na parte 2
do padrão.
Os processos do padrão 15504 estão agrupados em 3 categorias de processos, idênticas
às categorias definidas no padrão 12207 AMD 1, que são: categoria de processos de
ciclo de vida Primários, de Suporte e Organizacionais.
Dentro de uma categoria de processo, os processos são agrupados em um segundo nível,
de acordo com o tipo de atividade que eles endereçam: os processos incluídos no
mesmo grupo têm um relacionamento lógico uma vez que suas capacidades são
relacionadas e contribuem para uma problemática complementar.
As categorias e os grupos de processo são mostrados na TABELA 3.3. A GCS é
encontrada na área de processos de suporte, no grupo de processos denominado Grupo
de Controle de Configuração (CFG), onde as atividades da GCS consideradas neste
trabalho estão agrupadas nos processos de Gerência da Configuração e Gerência das
Solicitações de Modificação.
O propósito da Gerência da Configuração é estabelecer e manter a integridade de todos
os produtos de trabalho de um processo ou projeto e torná- los disponíveis às partes
envolvidas. Os resultados esperados com a implementação bem sucedida deste processo
são os mesmos definidos no padrão 12207 para esta gerência.
Este processo apresenta onze Práticas Básicas (Base Practices, BP ) que são tarefas e
atividades da engenharia de software ou gerenciais que, quando executadas de maneira
consistente, contribuem para que o propósito de um processo, como o da GCS, seja
alcançado e produza os resultados esperados.
100
TABELA 3.3 – Categorias e Grupos de Processo do Padrão ISO/IEC 15504.
CATEGORIAS
PROCESSOS
DO CICLO DE
VIDA
PRIMÁRIOS
PROCESSOS
DO CICLO DE
VIDA
ORGANIZA CIONAIS
PROCESSOS
DO CICLO DE
VIDA DE
SUPORTE
GRUPOS DE PROCESSOS E PROCESSOS
FORNECIMENTO
ENGENHARIA
(SPL)
(ENG)
1) Proposição do
1) Elicitação dos
fornecedor
requisitos
2) Acordo do
2) Análise dos requisitos
contrato
do sistema
3) Liberação do
3) Projeto de arquitetura
software
do sistema
4) Suporte à
4) Análise de requisitos
aceitação do
do sistema
software
5) Projeto de software
6) Construção do
software
7) Integração do
software
8) Teste do software
9) Instalação do
software
10) Integração do
sistema
11) Teste do sistema
12) Manutenção do
sistema e do software
GERENCIAMENTO
MELHORIA DE
RECURSOS E
(MAN)
PROCESSO
INFRAESTRUTURA
(PIM)
(RIN)
1) Alinhamento
1) Estabelecimento
1) Gerência de recursos
organizacional
do processo
humanos
2) Gerência da
2) Avaliação do
2) Treinamento
organização
processo
3) Gerência do
3) Gerência de
3) Melhoria do
conhecimento
projeto
processo
4) Infra-estrutura
4) Gerência da
qualidade
5) Gerência de risco
6) Medidas
CONTROLE DE
GARANTIA DA
QUALIDADE DO
CONFIGURAÇÃO
QUALIDADE
PRODUTO
(CFG)
(QUA)
(PRO)
AQUISIÇÃO
(ACQ)
1) Preparação da
aquisição
2) Seleção do
fornecedor
3) Monitoração do
fornecedor
4) Aceitação do
cliente
1) Documentação
2) Gerência de
configuração
3) Gerência de
problemas
4) Gerência das
solicitações de
modificação
1) Garantia da
qualidade
2) Verificação
3) Validação
4) Revisão conjunta
5) Auditoria
101
1) Usabilidade
2) Avaliação de produto
OPERAÇÃO
(OPE)
1) Suporte ao
cliente
2) Uso
operacional
REUSO
(REU)
1) Gerência de
bens
2) Gerência do
programa de
reuso
3) Engenharia
do domínio
Práticas básicas representam as atividades funcionais únicas de um processo e são
descritas em um nível abstrato, identificando o que deveria ser feito sem especificar
como. A implementação destas práticas representa, no entanto, o primeiro passo na
construção da capacidade do processo. São elas:
•
CFG.2.BP1 – Desenvolver uma estratégia para a gerência da configuração.
•
CFG.2.BP2 – Identificar itens da configuração.
•
CFG.2.BP3 – Estabelecer estruturas e hierarquias de arquivo e diretório.
•
CFG.2.BP4 – Estabelecer estratégia de desenvolvimento paralelo.
•
CFG.2.BP5 – Estabelecer as configurações-base internas e de distribuição.
•
CFG.2.BP6 – Manter a descrição de item de configuração.
•
CFG.2.BP7 – Controlar modificações e liberações.
•
CFG.2.BP8 – Manter histórico do item de configuração.
•
CFG.2.BP9 – Relatar a situação da configuração.
•
CFG.2.BP10 – Verificar a informação sobre itens de configuração.
•
CFG.2.BP11 – Gerenciar o backup, armazenamento, arquivamento, tratamento e
distribuição dos itens de configuração.
O propósito da Gerência das Solicitações de Modificação é garantir que as solicitações
de modificação sejam gerenciadas, acompanhadas e controladas. Este processo não tem
equivalente no 12207. Os resultados esperados com a implementação bem sucedida
deste processo são:
•
Uma estratégia para o gerenciamento da modificação é desenvolvida.
•
Solicitações de modificação são registradas e identificadas.
102
•
Dependências e relacionamentos com outras solicitações de modificação são
identificados.
•
Critérios para confirmação da implementação das solicitações de modificação
são definidos.
•
Solicitações de modificação são priorizadas, e os recursos necessários são
estimados.
•
Modificações são aprovadas de acordo com a prioridade e disponibilidade de
recursos.
•
Modificações aprovadas são implementadas e acompanhadas até o fechamento.
•
A situação de todas as solicitações de modificação é conhecida.
Este processo apresenta dez práticas básicas (BP) que devem ser realizadas a fim de que
o propósito e resultados esperados sejam alcançados. São elas:
•
CFG.4.BP1 – Desenvolver uma estratégia de gerenciamento das modificações.
•
CFG.4.BP2 – Registrar a solicitação de modificação.
•
CFG.4.BP3 – Registrar a situação das solicitações de modificação.
•
CFG.4.BP4 – Fornecer possibilidade de rastreamento com o problema originário
ou relatórios de erros.
•
CFG.4.BP5 – Estabelecer as dependências e relacionamentos com outras
solicitações de modificação.
•
CFG.4.BP6 – Avaliar o impacto da modificação.
•
CFG.4.BP7 – Identificar as atividades de verificação e validação a serem
executadas para as modificações implementadas.
103
•
CFG.4.BP8 – Modificações são aprovadas antes da implementação.
•
CFG.4.BP9 – Agendar a modificação.
•
CFG.4.BP10 – Revisar a modificação implementada.
Um nível de capacidade é um conjunto de Atributos do Processo (Process Attributes,
PAs) que cooperam para proporcionar uma melhoria na capacidade de executar um
processo. Os PAs fornecem, assim, uma medida da capacidade do processo e são
aplicáveis a todos os processos. Cada atributo descreve um aspecto da capacidade
completa de gerenciamento e melhoria da eficiência do processo em alcançar seu
propósito e contribuir para os objetivos de negócio da organização.
Os níveis constituem uma maneira racional de progredir na melhoria da capacidade de
qualquer processo.
No padrão ISO/IEC 15504 existem seis níveis de capacidade, que incorporam nove
atributos de processo (Figura 3.2). Cada atributo de processo possui indicadores da
capacidade do processo. Na Seção 6 da parte 5 do padrão 15504 apresentam-se os
indicadores de atributos de processo relacionados aos nove atributos de processo
associados aos níveis de processo, que variam de 1 a 5. Entre estes indicadores estão os
processos relacionados aos PAs. O processo de Gerência da Configuração é um
processo relacionado ao PA 2.2 - Gerenciamento de Produto de Trabalho.
3.4.1.3
A Maturidade da GCS
Uma vez que o modelo do padrão 15504 é contínuo e os processos das Gerências da
Configuração e das Solicitações de Modificação são áreas de processo, elas podem ser
executadas nos níveis de maturidade definidos.
Para obter o Nível 1, os processos das Gerências da Configuração e das Solicitações de
Modificação devem ser executados de maneira a que seus propósitos sejam alcançados.
104
O Nível 2 requer um planejamento do gerenciamento da configuração e das solicitações
de modificação e um acompanhamento da execução de acordo com o plano ou
estratégias estabelecidas. Os produtos de trabalho devem ser controlados tanto em
relação à qualidade quanto à sua integridade, significando que os produtos de trabalho
dos processos que são relevantes, como o Plano de Gerência da Configuração, devem
ser colocados sob o gerenciamento de configuração.
5.1 Inovação do Processo
5.2 Otimização Contínua
Processo
Otimizado
4.1 Medição do Processo
4.2 Controle do Processo
Processo
Previsível
Processo
Estabelecido
Processo
Gerenciado
Processo
Executado
3.1 Definição do Processo
3.2 Implantação do Processo
2.1 Gerenciamento da Execução do Processo
2.2 Gerenciamento de Produto de Trabalho
1.1. Execução do Processo
Processo
Incompleto
FIGURA 3.2 - Níveis de Capacidade e Atributos de Processo.
No Nível 3 os processos têm que estar documentados de maneira padronizada e permitir
que adequações do processo sejam introduzidas e documentadas, e também para que
uma realimentação seja fornecida para o processo padrão. Os recursos necessários para
execução dos processos (recursos humanos e ferramentas) devem estar identificados e
disponíveis.
O Nível 4 requer que a execução do gerenciamento da configuração e das solicitações
de modificação, bem como seus resultados, sejam controlados através de medições e
que haja ajustes nos processos, caso saiam do controle.
No Nível 5 utilizam-se medidas para dar suporte à melhoria da execução dos processos
de gerenciamento da configuração e das solicitações de modificação e para medir os
efeitos desta melhoria.
105
A presença dos produtos de trabalho e a execução das práticas básicas fornecem
evidências objetivas do cumprimento do propósito do processo.
Os modelos e o padrão descritos nesta seção não detalham como deve ser feita a
implementação das tarefas e atividades incluídas nos processos por eles descritos.
Fornecem orientações gerais e alguns exemplos de quais atividades e produtos de
trabalho podem ser usados para implementar os processos. Detalhes como a seleção do
conjunto de métodos, técnicas e ferramentas a serem implementados, os momentos
certos para implementá- los e quais os recursos necessários devem ser definidos.
Estes detalhes dos processos da GCS são apresentados no modelo apresentado no
Capítulo 4 desta dissertação.
3.5
O Ambiente Integrado para Apoio ao Desenvolvimento e Gestão de Projetos
de Software
Nesta seção é introduzido o Ambiente Integrado, conforme descrito em (Sant’Anna,
2000), que fornece o contexto e a motivação para a abordagem proposta neste trabalho
de dissertação. Apresentam-se ainda alguns conceitos e definições utilizadas pelo
Ambiente.
3.5.1
Definições e Conceitos
Segundo (SantÁnna, 2000), um processo de engenharia de software é um processo
de software composto de um conjunto de processos capazes de conduzir a organização
envolvida com a construção de produtos de software com qualidade e custos previsíveis,
de forma eficiente, gerenciada e com a possibilidade de melhoria constante.
Um modelo de processo é uma representação detalhada e documentada dos processos
envolvidos em um processo de software, adotada por uma organização ou
empreendimento específico. Este modelo necessita ser consistente com as diretivas da
organização e estabelecido (aceito) pelos envolvidos na construção do software. O
modelo de processo pode ter um caráter formal ou não (textual ou gráfica apenas).
106
Um modelo de processo que é aceito pela organização é chamado de um processo
padrão. Um processo definido é uma customização do processo padrão estabelecido
pela organização, para atender a determinadas características de utilização especificada.
Um processo bem definido é um processo definido com entradas, critérios de entrada,
tarefas, validações, saídas e critérios de saídas consistentes, completos e documentados.
Um processo instanciado é um processo quando em execução por uma organização ou
empreendimento.
3.5.2
Caracterização do Ambiente Integrado
Este Ambiente, atualmente em desenvolvimento, consiste de um conjunto de
ferramentas para apoiar as atividades de desenvolvimento e gestão do processo de
construção de software, organizado em áreas de negócio, de maneira a proporcionar
apoio eficiente à gerência de projetos. Tem como características o uso do trabalho
cooperativo centrado no processo, o conceito de ambiente ativo ou capacidade de forçar
o fluxo de trabalho (workflow) e de agentes autônomos, elementos que executam ações
efetivas para o desenvolvimento, gerenciamento e controle dos produtos de software, de
forma independente da intervenção humana.
A integração das equipes de trabalho, a ut ilização de tecnologia para controle dos
processos envolvidos e a disponibilidade de um conjunto de serviços oferecidos pela
WEB/Internet para os vários participantes do processo (desenvolvedores, gerentes,
clientes) são alguns dos benefícios propostos por este ambiente, para a obtenção de
ganhos de produtividade.
3.5.3
Arquitetura Lógica do Ambiente
A arquitetura lógica permite, entre outras funções, que as atividades das gerências
propostas pelo ambiente possam ser executadas, acompanhadas e melhoradas,
disponibilizando para isto todos os recursos e os meios necessários à gestão de seus
processos. Para atender estas características, a arquitetura do ambiente foi definida em
três camadas:
107
•
Camada de Armazenamento: define os elementos responsáveis pelo
armazenamento e acesso às informações do projeto.
•
Camada de Serviços: abrange os elementos que permitem que os participantes
trabalhem de forma cooperativa, destacando-se os serviços de coordenação de
processo, de comunicação, agenda, segurança, dicionário, documentação,
armazenamento, entre outras.
•
Camada de Interação com o usuário: possui elementos que permitem que os
aplicativos de serviços sejam executados, a partir de uma rede de computadores,
disponibilizando com isso o trabalho remoto e cooperativo. A utilização de
navegadores (browsers), permite tal facilidade, dada a capacidade de operação
em modo gráfico e ambiente de janelas, possibilitando interação fácil e eficaz.
A arquitetura conceitual do ambiente é apresentada na Figura 3.3.
FIGURA 3.3 - A Camada Conceitual do Ambiente e-WebProject.
FONTE: Sant’Anna (2000, p.102 ).
108
3.5.4
A Arquitetura Física
O Ambiente leva dois aspectos em consideração: os requisitos propostos e a arquitetura
conceitual. A abordagem utilizada segue o modelo "n-camadas" para aplicações Web
(Conallen, 2000). A Figura 3.4 apresenta os componentes da arquitetura.
FIGURA 3.4 - Arquitetura Três Camadas para Aplicações Web.
FONTE: SantÁnna (2000, p. 150).
3.5.5
Ciclo de Vida do Processo no Ambiente
O Ambiente Integrado propõe um modelo de processo de desenvolvimento que leva em
consideração principalmente o ciclo de vida do produto e os grupos participantes. O
Ambiente apresenta características evolutivas e permite a configuração baseada nas
necessidades organizacionais. O processo é o elemento essencial do Ambiente
(Sant’Anna, 2000). Para que possa ser apoiado pelo Ambiente, um modelo de processo
necessita ser detalhado e aprovado pela organização, transformando-se em um processo
padrão. Um novo processo se torna padrão quando for instanciado, permitindo que este
seja executado por pessoas e agentes autônomos especificamente envolvidos na tarefa.
Dentro desta visão, o ciclo de vida proposto para um processo consiste do planejamento
e definição de um modelo, sua execução e acompanhamento e finalmente avaliação e
propostas de melhoria. A Figura 3.5 mostra como exemplo o processo Auditar Produtos
do Trabalho, adaptada da categoria de processo da ISO/IEC 15504, que tem como
objetivo específico garantir que os produtos do trabalho e atividades dentro do ambiente
109
estejam em conformidade com todos os padrões, procedimentos e requisitos aplicáveis
(Lahoz et al., 2002).
FIGURA 3.5 - Ciclo de Vida do Processo Auditar Produto.
FONTE: Lahoz et al (2002, p.2).
3.5.5.1
A Fase de Planejamento do Processo
Planejar um processo é uma tarefa essencial para sua automação, sendo necessário que
seu modelo seja bem entendido e aceito por toda a organização que dele se utiliza. A
fase de planejamento deve, portanto, permitir a especificação dos elementos essenciais
para execução do processo tais como, os recursos necessários, as entradas e saídas,
quais são as tarefas do processo e quem as executa. O planejamento do processo deve
passar pela preparação do modelo de processo, sua aprovação pela organização e o
encerramento do planejamento conforme a Figura 3.6.
A preparação do modelo de processos consiste inicialmente da descrição e detalhamento
das atividades que compõem o processo no cotidiano real da organização. Estas
atividades são descritas em termos de tarefas executadas e seus participantes, a alocação
dos indivíduos e recursos materiais necessários às tarefas, bem como a especificação
dos requisitos de entrada e saída de cada processo. A preparação do modelo do processo
deve abranger as seguintes atividades:
110
FIGURA 3.6 - A Fase de Planejamento.
FONTE: Sant’Anna (2000, p. 114).
•
Descrição da função e dos objetivos básicos do processo a ser modelado.
•
Descrição dos requisitos que o processo deve atender.
•
Identificação das entradas e saídas necessárias à execução do processo.
•
Definição dos critérios para iniciar e fechar uma instância de processo.
•
Descrição do processo em atividades executáveis e factíveis descrevendo os
procedimento para execução destas tarefas.
•
Definição da ordem de execução e a dependência entre as tarefas.
•
Definição dos papéis dos executores de cada tarefa.
•
Definição das responsabilidades associando papéis as pessoas e agentes.
•
Definição dos recursos necessários.
•
Definição das métricas que são utilizadas para monitorar o processo.
•
Definição dos pontos de controle para melhor acompanhar a execução do
processo.
111
A aprovação do modelo pela organização consiste na validação deste por uma comissão
de revisores, responsável pela análise e certificação do modelo definido. Uma vez
certificado, o modelo se torna modelo padrão de processo adotado pelo Ambiente e
disponível para ser executado.
O fechamento do planejamento consiste de atividades que tornam o modelo de processo
acessível ao Ambiente, como a definição de diretivas para execução do processo e para
preparação do processo quando automatizado.
3.5.5.2
A Fase de Execução do Processo
O processo, antes de tornar-se operacional no Ambiente, passa por uma fase de
preparação
que consiste de uma série de tarefas relacionadas à configuração do
ambiente e ajuste para que este possa suportar o processo de modo planejado. Uma vez
concretizada esta fase, o processo entra em um estado que é chamado de estado
operacional (em operação). Poderá então, quando neste estado, ser utilizado pelos
participantes do projeto.
Todo processo possui pelo menos uma atividade que o inicia. A execução desta
atividade possibilita ao ambiente instanciar uma ocorrência do processo, e deve tomar
as medidas necessárias para que o processo seja concluído conforme o especificado.
Este conjunto de atividades a serem executadas segue o modelo do processo proposto
no planejamento. A fase de operação permite, pois, que processos sejam instanciados e
concluídos.
A execução de um processo implica também na realização das seguintes atividades:
•
Informação aos participantes de suas novas atividades a serem executadas e os
prazos a serem cumpridos.
•
Supervisão das atividades, verificando se estão sendo cumpridas no prazo. Em
caso negativo, cabe ao ambiente forçar o andamento das atividades.
112
•
Informação aos gerentes e os participantes da execução do processo informado
do andamento da execução do processo.
•
Coleta de métricas de processo estabelecidas no planejamento para posterior
avaliação.
•
Realização de ação corretiva para ajuste de pequenas inadequações, em função
dos dados coletados através das métricas de processo.
Durante esta fase operacional, ou seja, enquanto o ambiente estiver apoiando sua
execução, deve-se realizar uma coleta de dados a fim de medir sua eficiência, que após
análise, servirá para avaliar a conformidade deste novo processo padrão no
cumprimento dos objetivos especificados. Isto permite tanto implantar este novo
modelo do processo, como também, caso já exista, melhorá- lo.
Quando for necessário parar de prover o serviço, o processo pode ser desativado e entrar
em um estado que é chamado de fechamento. O fechamento é a fase onde o Ambiente
cessa de apoiar o processo. Ao parar de prover este suporte, o Ambiente deve informar
aos gerentes e interessados que o apoio ao processo especificado deixa de ser oferecido,
bem como deve registrar em arquivos históricos, toda a informação referente ao trato do
apoio ao processo especificado. O término do suporte ao processo ocorre normalmente
por motivo de avaliação e melhoria do modelo padrão definido para o processo.
A Figura 3.7 mostra os estados possíveis para um processo, quando em execução.
Fechamento
Operação
Preparação
FIGURA 3.7 – Os Estados de um Processo em Execução.
FONTE: Sant’Anna (2000, p. 116 ).
113
3.5.5.3
A Fase de Avaliação do Processo
Na fase de avaliação e melhoria do processo estão compreendidas as atividades
relacionadas à análise das medidas coletadas durante a execução do processo, a fim de
se identificar problemas na modelagem referente às definições, sobrecargas e
necessidades das atividades do processo. A avaliação deve ser conduzida através de
uma investigação que procure identificar características importantes da construção e uso
do processo, como por exemplo:
•
Problemas na modelagem referentes ao desdobramento do processo em
atividades.
•
Sobrecarga de atividade, ou seja, uma atividade muito executada causando falta
de recurso.
•
Atividades não necessárias.
•
Pontos de estrangulamento devido a restrições de entradas do processo.
Após análise destas informações, medidas corretivas devem ser tomadas para que o
processo obtenha melhorias e possa ser oferecido ao Ambiente de maneira a atender
suas necessidades. A partir daí, um novo modelo deve ser elaborado e reconduzido para
avaliação conforme descrito na fase de planejamento.
3.5.6
O Serviço de Coordenação de Processos de Software
Um processo de software deve ser formalizado e apoiado por um ambiente de
engenharia de software através de um mecanismo coordenador de processos (process
engine) (Sant’Anna, 2000; Sant’Anna et al., 2002). Este mecanismo utiliza o conceito
de fluxo de trabalho (workflow), que possibilita automatizar processos, racionalizando
suas potencialidades por meio dos componentes, organização e tecnologia (Cruz, 1998).
114
A execução de processos no Ambiente se dá por meio de um gerenciador de workflow
(Cereja Jr., 2002), onde cada tarefa do sistema é orientada por regras e agentes
(humanos ou não) para o processamento de informações.
O sistema coordenador de processos tem como papel controlar a instância dos processos
apoiados pelo Ambiente, guiando as pessoas envolvidas nos processos na execução de
suas tarefas. Dentre as principais características do mecanismo coordenador de
processos do Ambiente podemos destacar:
•
O usuário (agente) pode guiar o processo e a máquina de processo deve operar
em resposta às suas determinações.
•
A execução das tarefas pode ocorrer sem intervenção dos usuários.
•
A máquina tem um papel pró-ativo lembrando aos envolvidos sobre tarefas que
devem ser completadas (dentre outras medidas que podem ser tomadas).
•
A máquina pode guiar as pessoas na execução das tarefas; ela controla os
artefatos e os recursos produzidos e utilizados pelos processos.
No Ambiente Integrado, um repositório de artefatos é responsável pelo armazenamento
e controle dos artefatos produzidos pelos processos. Este repositório serve como uma
base de meta informações de processos, caracterizando seus componentes e regras para
execução definida em um modelo de processo. Um conjunto de agentes autônomos
(agentes genéricos e específicos) é capaz de monitorar as instâncias de processos,
notificar pessoas envolvidas, coordenar outros agentes, transportar informações,
monitorar tarefas, dentre outros aspectos definidos para o serviço ou processo
específico. Aliado a tudo isto, uma Interface Gráfica de fácil interação homem- máquina
facilitará o uso e a implantação dos processos no Ambiente.
3.5.7
As Gerências no Ambiente Integrado
O Ambiente toma por base as nove categorias de gerenciamento estabelecidas pelo
Project Management Institute (PMI) (PMI, 1996), com alguns ajustes, e acrescenta
115
outras, para melhor adequação às necessidades específicas de projetos de software. São
estabelecidas, então, onze áreas chaves - as gerências: geral do projeto, do tempo, do
custo, da qualidade, dos recursos humanos, da comunicação, de risco, de fornecedores e
sub-contratos, de requisitos, de modificações e da configuração e a categoria de
gerenciamento da reutilização.
As gerências têm à sua disposição uma camada de serviços que suporta o trabalho
cooperativo, como visto na arquitetura lógica do Ambiente, Seção 3.5.3.
3.5.8
Os Requisitos para a Gerência das Modificações e da Configuração no
Ambiente Integrado
A Gerência da Configuração no Ambiente é parte integrante e essencial por todo o
processo de desenvolvimento de software, sendo responsável pela definição dos
elementos controlados ou itens de configuração, a garantia da correta modificação
nesses elementos, a disseminação da informação das modificações e o estabelecimento
da configuração de um produto.
O Ambiente deve fornecer à GCS, através da camada de serviço, uma visão que lhe
permita cadastrar, manter e visualizar informações sobre: os produtos controlados, suas
categorias, situação, cadeia de relacionamento e versões; o Plano da Configuração; as
solicitações e classes de modificações, bem como as reuniões de validação destas; os
resultados da análise de solicitação de modificação; as auditorias e revisões em produtos
decorrentes das modificações e as estatísticas e os históricos.
Estes requisitos devem ser atendidos pelo modelo de processo da Gerência das
Modificações e da Configuração, que é apresentado no Capítulo 4.
116
CAPÍTULO 4
A MODELAGEM DO PROCESSO DA GERÊNCIA DAS MODIFICAÇÕES E DA
CONFIGURAÇÃO
Este Capítulo apresenta a definição e a modelagem do processo da Gerência das
Modificações e da Configuração (GCS), para o Ambiente Integrado.
Como visto no Capítulo 3, o padrão ISO/IEC 12207 apresenta um modelo de processo de
referência, utilizado pelo padrão ISO/IEC 15504, que representa um consenso da
comunidade internacional a respeito de práticas da engenharia de software. Estas práticas
são apresentadas em linhas gerais, ou seja, o padrão declara o que o processo deve fazer, e
não detalhes de como realizar as atividades.
A definição e modelagem do processo da GCS, principais contribuições deste trabalho,
consistem, portanto, no detalhamento das práticas básicas encontradas nos padrões e na
descrição das maneiras como elas podem ser implementadas. Utiliza-se, para expressar o
modelo do processo, a linguagem SPEM, da OMG, descrita no Capítulo 3 deste trabalho.
A modelagem com utilização de notação gráfica auxilia no entendimento e comunicação do
processo, possibilita sua documentação de maneira padronizada e, numa próxima etapa,
permitirá a tradução dos modelos para uma notação executável em um PSEE, como o
Ambiente Integrado, ou sua utilização em outros ambientes de desenvolvimento, naquelas
organizações que buscam melhores níveis de qualidade de seus produtos, como é o caso das
organizações responsáveis por desenvolvimento de software para aplicações espaciais.
Inicialmente, neste Capítulo, apresenta-se o histórico da condução dos estudos necessários
ao desenvolvimento do trabalho, em termos de produção científica reconhecida pela
comunidade da área, para mostrar como se deram a evolução do amadurecimento dos
conceitos apresentados e, também, o desenvolvimento do trabalho de modelagem.
117
4.1
Histórico e Desenvolvimento do Trabalho
No início dos estudos deste trabalho de dissertação, duas linhas de pesquisa foram
identificadas: uma, relacionada a processos de software, incluindo a modelagem de
processos, linguagens de modelagem, padrões de processo de software e ambientes
centrados em processos, e outra relativa à disciplina de gerenciamento da configuração de
software, conforme apresentada em padrões e na literatura de engenharia de software.
Partindo-se destas linhas, foram feitas pesquisas referentes à definição e modelagem do
processo Auditar Produtos do Trabalho (Lahoz et al., 2002), que resultou na apresentação
de um trabalho no IV Simpósio Internacional de Melhoria de Processo de Software,
SIMPROS, em Recife (PE). Nele foi possível identificar os passos mínimos necessários
para a definição de um processo, baseados naqueles definidos para o Ambiente Integrado
(SantÁnna, 2000), sendo este um trabalho fundamental para o início da modelagem do
processo da GCS.
Em (Abdala et. al., 2002) foi feito um novo exercício de definição de processo, e um
levantamento inicial dos processos essenciais da GCS para o Ambiente Integrado. Este
trabalho foi apresentado no II Workshop dos Cursos de Computação Aplicada do INPE,
WORKCAP, em São José dos Campos (SP).
O amadurecimento adquirido até então nos estudos sobre o gerenciamento da configuração,
de padrões de processo, de linguagens de modelagem e do Ambiente Integrado, possibilitou
a participação, juntamente com outros, da apresentação do tutorial Um ambiente Integrado
para Suporte a Projetos de Engenharia de Software (SantÁnna et al., 2003), no Congresso
COMDEX, em São Paulo (SP). O objetivo foi apresentar conceitos como requisitos,
arquitetura e suporte a processos que norteiam o Ambiente Integrado e também os
conceitos e atividades da Gerência das Modificações e da Configuração.
Em continuação aos estudos sobre modelagem de processos e do processo da GCS em
padrões e modelos de processo foram ainda elaborados dois trabalhos, em conjunto com
118
outros autores: um apresentado como artigo técnico no V SIMPROS, que inclui o relato de
experiência na utilização do SPEM (Abdala et al, 2003); e o outro, no III WORKCAP do
INPE (Abdala e SantÁnna, 2003).
Como a linguagem de modelagem escolhida para expressar os modelos, o SPEM da OMG,
foi criado recentemente, faltavam referências e exemplos de sua utilização que pudessem
orientar a construção do modelo e servir para sua validação. Para isto, buscou-se contato
com participante do grupo de definição do SPEM. No Apêndice A é apresentado um
resumo desta experiência, contendo esclarecimentos sobre a linguagem que se acredita
serem úteis para outros que venham dela se utilizar.
Como já mencionado, definir processos não é uma tarefa trivial, sendo necessário para isto
conhecer os fundamentos e conceitos do processo a ser definido e modelado. Alguns dos
conceitos da GCS, ainda que entendidos facilmente, podem ser difíceis de implementar.
Além disto, muitos destes conceitos não são uniformes na literatura e nos padrões. Foi
fundamental, portanto, obter um entendimento desta disciplina, através de um estudo dos
seus conceitos e atividades fundamentais e suas variações, apresentados no Capítulo 2.
Muitas vezes a falta de uma definição clara leva a dificuldades na aplicação destes
conceitos no processo da GCS.
Seguindo a orientação do Ambiente, que é baseado no SPICE, foram utilizados os padrões
ISO/IEC 12207 e 15504, que apresentam práticas básicas consagradas, frutos de
experimentação e estão consolidados como padrões internacionais, como ponto de partida
do trabalho.
Uma vez identificadas as práticas básicas da GCS, foram feitas a definição e modelagem do
processo, detalhando-se suas atividades, os papéis que as desempenham e os produtos de
trabalho gerados ou utilizados na execução destes, empregando-se as técnicas e linguagem
apresentadas no Capítulo 3 desta dissertação.
119
4.2
O Escopo do Processo da GCS
As práticas básicas dos processos do grupo CFG2 – Gerência da Configuração e CFG4 –
Gerência das Solicitações de Modificação, da categoria de processos de suporte, da Parte 5
do ISO/IEC 15504, são utilizadas como ponto de partida para definição e modelagem do
processo da GCS. Outras práticas e abordagens encontradas na literatura e referenciadas na
bibliografia, como a abordagem prática encontrada em (Hass, 2002), e em padrões como o
(ANSI/IEEE Std 1042, 1987) são utilizadas para complementar esta definição e
modelagem.
O Processo da GCS nesta abordagem busca atender as atividades de implementação do
processo da GCS, de identificação da configuração, do controle da configuração, do relato
da situação da configuração e gerenciamento da liberação das configurações-base de
desenvolvimento e de distribuição, atribuídas à GCS, segundo o ISO/IEC 12207. A
avaliação da configuração não é considerada, nesta abordagem, uma atribuição do Processo
da GCS. Esta atividade fica sob responsabilidade da Gerência da Qualidade no Ambiente
Integrado, já que utiliza mecanismos de verificação e validação, sob responsabilidade desta
gerência (Hass, 2002). Outra consideração diz respeito às distribuições. Nesta abordagem o
controle sobre as distribuições é considerado o controle da configuração-base de
distribuição, ou seja, a configuração-base de produto utilizada para a geração de uma
distribuição do produto, não o processo de construção do sistema (system build) e
procedimentos para entrega. Estas atividades, que tradicionalmente estão associadas à GCS,
são tratadas em processo específico do Grupo de Processos de Fornecimento (Supply
Process Group), SPL3 - Liberação de Software, segundo o padrão ISO/IEC 15504, cujo
propósito é controlar a liberação de um produto ao cliente ao qual é destinado, não coberto
pela abordagem proposta.
O gerenciamento das modificações nos produtos de software contempla dois aspectos: o
acompanhamento de problemas e o controle das modificações. O acompanhamento de
problemas é o processo de registrar, acompanhar e relatar problemas e solicitações de
120
melhorias submetidas por usuários de um produto. O processo da Gerência de Proble mas
(CFG 3 - Problem Management) é coberto no Ambiente Integrado pelo processo
denominado Solucionar Ocorrências. Algumas destas ocorrências relatadas, que podem ser
problemas ou sugestões de melhorias, resultam em solicitações de modificação em um ou
mais itens de configuração de software. O Gerenciamento das Solicitações de Modificação
é o processo responsável pelo acompanhamento e controle das solicitações de modificação
nos itens de configuração de software durante todo o seu ciclo de vida, e é o aspecto
contemplado nesta abordagem.
4.3
Estratégias para a Definição e Modelagem do Processo da GCS
O processo da Gerência das Modificações e da Configuração, denominado aqui Processo da
GCS, é, nesta abordagem proposta, dividido em quatro outros processos, chamados:
Definição das Estratégias Organizacionais da GCS, Planejamento da GCS, Gerenciamento
da Configuração e Gerenciamento das Solicitações de Modificação.
Isto permite uma visão das atividades da GCS nos seus aspectos principais: elaboração de
estratégias para a GCS na organização, implantação do processo da GCS para um projeto
em particular, manutenção da integridade da configuração, através da identificação,
armazenamento, controle e relato da situação da configuração, e acompanhamento das
Para contemplar estes aspectos é necessário definir o que deve ser feito no processo. Isto
significa o material (produto) a ser desenvolvido ou as ferramentas utilizadas no seu
desenvolvimento, caracterizando a visão tecnológica do processo. Também é importante
saber como o processo é conduzido. Isto compreende uma seqüência de atividades e passos
bem definidos em uma ordem específica, caracterizando a visão metodológica do processo.
E também definir quem, ou seja, as pessoas que possuem responsabilidades nas ações do
processo e seguem a metodologia prescrita, caracterizando a visão sociológica do processo
121
(Unhelkar, 2002). Neste capítulo descreve-se o que, o como e o quem para o Processo da
GCS.
O contexto em que os processos da GCS se inserem no processo de desenvolvimento do
software, apresentado na Figura 2.4 do Capítulo 2, mostra que a GCS, como processo de
suporte, atua durante todo o ciclo de vida do software.
A notação utilizada na modelagem do Processo da GCS é o SPEM da OMG, cujas
principais características estão descritas no Capítulo 3.
Uma das vantagens da linguagem de modelagem SPEM é que ela permite a utilização da
representação gráfica da UML, ou seja, os diagramas da UML, que tornam mais fácil a
visualização das informações.
O SPEM oferece os recursos para a representação do processo de software como um todo,
detalhado nas suas atividades, fases, iterações e ciclo de vida. Como o Processo da GCS é
um processo de suporte, e utilizado por outros processos durante todo o ciclo de vida, ele é
representado como um Componente de Processo (ProcessComponent), que pode ser, assim,
composto com outros Componentes de Processo para criar um processo completo de
software, suportado pelo Ambiente Integrado.
Por sua vez, um Componente de Processo pode ser composto por outros. Utiliza-se, assim,
um diagrama de pacote de processo para representar o Processo da GCS, composto de
outros pacotes (Definição das Estratégias Organizacionais da GCS, Planejamento da GCS,
Gerenciamento da Configuração e Gerenciamento das Solicitações de Modificação). Estes
pacotes são detalhados e descritos, utilizando-se para isto, os diagramas de classe, caso de
uso e de atividades (ver Apêndice A).
4.4
A Modelagem do Processo da GCS
Conforme visto no Capítulo 3, uma seqüência de passos para a preparação dos modelos de
122
processo são apresentados em (SantÁnna, 2000), tendo sido utilizados neste trabalho como
uma referência para a definição do Processo da GCS. Para o planejamento e definição do
modelo do Processo da GCS inicialmente são descritas e detalhadas as atividades que o
compõem, que devem ser utilizadas no cotidiano de uma organização. Estas atividades
podem ser descritas em termos dos papéis e responsabilidades, das tarefas ou atividades
executadas, da alocação dos produtos de trabalho necessários às tarefas e da especificação
dos requisitos de cada processo.
O modelo da GCS apresentado nesta abordagem se propõe a atender aos processos do
padrão 15504 (CFG.2 – Gerência da Configuração e CFG.4 – Gerência das solicitações de
modificação), fornecendo também uma visão abrangente da atuação da GCS em projetos de
desenvolvimento de software em uma organização, contemplando as estratégias para o
processo na organização, conforme apresentada nas seções seguintes deste Capítulo.
4.4.1
Papéis e Responsabilidades no Processo da GCS
Descrever os papéis desempenhados nas atividades da GCS é importante para que se tenha
um entendimento mais abrangente do trabalho a ser realizado. Os papéis devem se encaixar
dentro de uma estrutura organizacional, que pode variar de uma organização para outra.
Uma ou mais pessoas podem desempenhar um papel, assim como uma só pessoa pode
desempenhar vários papéis.
Os papéis específicos para a GCS definidos nesta abordagem foram aqueles considerados
essenciais para o processo, baseados nos papéis para a GCS, apresentados em (Hass, 2002),
e estão apresentados sucintamente abaixo. Estes papéis aparecerão associados a atividades
do processo da GCS na modelagem apresentada nas seções seguintes deste Capítulo.
Gerente das Modificações e da Configuração: o Gerente das Modificações e da
Configuração, ou simplesmente Gerente da Configuração deve conhecer a disciplina da
GCS, seus processos e variações, e ter uma sólida experiência em software. Este papel
123
requer ainda conhecimento dos princípios da engenharia de software para entender as
necessidades de variação dos esforços de engenharia durante o desenvolvimento de um
produto e uma compreensão dos aspectos culturais da organização para implantar um
programa de GCS.
Grupo de Controle da Configuração (GCC): os membros do GCC, representados pelo
seu presidente, têm a responsabilidade geral de controlar as modificações dos itens de
configuração. O grupo é também responsável pela avaliação dos relatórios de ocorrência,
pela criação das solicitações de modificação (SMs) relacionadas, pelo acompanhamento do
ciclo de vida das SMs, pelo fornecimento de informações para o solucionador da ocorrência
e demais envolvidos na modificação, pela coordenação com outros GCCs, com a gerência
de projetos e outras gerências. O GCC é que decide o destino das ocorrências que afetam os
itens de configuração, por isso deve ser presidido por alguém com autoridade para tomar
decisões de acordo com o tipo de item de configuração ou fase do desenvolvimento, ou,
ainda, unidade da organização ao qual está ligado.
Os membros do GCC devem conhecer o propósito geral do produto e ter uma visão deste
que lhes permita avaliar as conseqüências das modificações solicitadas. Devem ter também
um conhecimento geral da GCS, especialmente no que diz respeito aos procedimentos de
controle das modificações, bem como das informações sobre os itens de configuração e
como acessá- las.
Um GCC é constituído por pessoas que desempenham vários outros papéis na equipe.
Dependendo do impacto sobre o produto de software que a modificação no item de
configuração tem, o número de pessoas que compõem o GCC pode variar. Quando a
modificação tem um impacto maior, um GCC pode ser constituído de várias pessoas, como
o gerente de projeto, representante do cliente e o responsável pela garantia da qualidade. Ou
pode consistir de uma só pessoa, como um desenvolvedor ou o responsável pela garantia da
qualidade, se lhe foi delegada esta autoridade por autoridade apropriada. Isto acontece
124
quando, durante o desenvolvimento, adota-se um controle menos formal sobre as
modificações.
Responsável pela Gerência das Modificações e da Configuração (RGCS): o
Responsável pela GCS implementa, mantém e melhora o gerenciamento da configuração
dentro da estrutura fornecida pelo gerente da configuração. O RGCS tem a
responsabilidade de utilizar-se dos recursos disponíveis para o suporte às atividades do
gerenciamento da configuração. O RGCS reporta-se diretamente ao gerente de projeto e
deve interagir também com o gerente de processos no que diz respeito aos processos
relevantes à GCS. O RGCS deve ter um senso de ordem e atenção a detalhes. Deve ter
noções de gerenciamento e boa comunicação com os vários tipos de pessoas envolvidas no
processo. Deve ter um conhecimento profundo da GCS e também das necessidades da
organização e do projeto, inclusive, para adequar o processo da GCS a estas necessidades.
Além destes papéis específicos da GCS, estão envolvidos no processo o Gerente da
Qualidade, o Gerente de Projeto, o Desenvolvedor e o Cliente.
Gerente da Qualidade: responde pela organização e gerenciamento das funções da
qualidade dentro do projeto. Ele formaliza as expectativas da atuação da equipe e da
abordagem utilizada para a qualidade em projetos, suas atividades e tarefas, a definição dos
produtos a serem entregues ao final do desenvolvimento de cada fase do projeto, os
mecanismos de verificação, validação e de retorno destas expectativas.
Gerente de Projeto: é o responsável geral pelo projeto e ao qual o Gerente da
Configuração se reporta no caso de problemas no andamento do projeto, na execução de
processos de planejamento ou controle e recebe os relatórios de situação da configuração.
Responsável pelo Produto: um envolvido no projeto de desenvolvimento que gera
produtos de trabalho, que, de alguma foram estarão sob controle da GCS.
125
Cliente da GCS: um cliente ou usuário do gerenciamento da configuração, que pode ser
um cliente interno à organização desenvolvedora, como desenvolvedores e gerentes, ou um
cliente externo ou final.
4.4.2
As Atividades do Processo da GCS
As atividades do Processo da GCS são agrupadas nos quatro pacotes de processos, que
podem ser visualizados no diagrama da Figura 4.1.
Gerência das Modificações e
da Configuração de Software - GCS
Definição das estratégias
organizacionais da GCS
Planejamento da
GCS
Gerenciamento da
configuração
Gerenciamento das
solicitações de modificação
FIGURA 4.1 – O Processo da GCS.
Estes processos, descritos de maneira sucinta abaixo, serão detalhados em seções
posteriores neste Capítulo.
126
1. Definição das Estratégias Organizacionais da GCS : este processo consiste em
definir as estratégias para as atividades da GCS na organização, para o
gerenciamento da configuração, das solicitações da modificação e desenvolvimento
paralelo.
Estas
estratégias
são
consolidadas
no
documento
de
Política
Organizacional da GCS ou em um documento de políticas da qualidade da
organização.
2. Planejamento da GCS : este processo consiste em estabelecer e manter um Plano
da GCS para um projeto em particular, baseado em estratégias da organização e na
implantação do sistema de gerenciamento da configuração e das modificações
adequado ao projeto em questão.
3. Gerenciamento da Configuração: consiste basicamente nas atividades de
manutenção
da
integridade
dos
itens
de
configuração
durante
todo
o
desenvolvimento do produto e após a entrega do mesmo, através da identificação
dos itens de configuração e estabelecimento das configurações-base, do
armazenamento, manuseio controlado, e da incorporação das modificações nestes
itens e do relato da situação da configuração, a todos os envolvidos no seu
desenvolvimento e utilização.
4. Gerenciamento das Solicitações de Modificação: este processo reúne as
atividades necessárias para o acompanhamento das solicitações de modificação
feitas nos itens de configuração, desde o surgimento da necessidade da modificação
até a incorporação destas aos itens de configuração, fornecendo visibilidade do
estado de cada solicitação de modificação e permitindo a verificação da correta
implementação destas nos itens afetados, durante todo o ciclo de vida do produto.
127
4.4.3
Os Produtos do Processo da GCS
Associados ao processo e suas práticas básicas estão os produtos de trabalho, que são os
produtos utilizados, gerados, ou ambos, na execução do processo. Os produtos de trabalho
são indicadores de que o processo é executado. Os principais produtos de entrada e saída do
Processo da GCS, segundo a ISO/IEC 15504-5, são os seguintes:
•
Item de configuração: item mantido sob controle de configuração, que possui
identificação única de versão e cuja descrição deve estar sempre disponível e
atualizada. Esta descrição inclui: o tipo de item, sistema, arquivo, biblioteca de
gerenciamento da configuração associados, responsável pelo item, data em que o
item foi colocado sob controle de configuração, informação do estado do item (em
desenvolvimento, configuração-base, etc.), relacionamento com os itens de
configuração de nível mais baixo, identificação dos registros de controle de
modificação, identificação do histórico de modificação.
•
Configuração do produto: constitui-se na visão geral da configuração do sistema.
Define cada componente e sua posição na arquitetura do sistema, define as
interfaces principais do sistema, bem como quaisquer considerações de rede,
configuração de hardware e configurações de desempenho/parâmetro de sistema.
•
Plano de Gerência da Configuração de Software: define ou referencia os
procedimentos para controlar modificações nos itens de configuração, define
medidas usadas para determinar a situação das atividades do gerenciamento da
configuração, identifica ferramentas ou mecanismos da biblioteca da GCS,
identifica os registros e relatórios de estado gerenciais que mostram o estado e
histórico dos itens controlados, especifica ou referencia a localização, os
mecanismos de acesso à biblioteca da GCS e mecanismos específicos para
arquivamento e obtenção das informações contidas na biblioteca.
128
•
Plano de distribuição: identifica a funcionalidade que deve ser incluída em cada
distribuição, quais os componentes associados requeridos (i.e., hardware, software,
documentação, etc.) e apresenta também um mapeamento das solicitações dos
clientes e requisitos satisfeitos para uma distribuição particular do produto.
•
Histórico de modificações: relatório dos registros históricos de todas as
modificações feitas em um objeto ou item de configuração (documento, arquivo,
módulo de software, etc.). Devem constar deste histórico a descrição da
modificação, a identificação da versão do objeto modificado, a data da modificação,
informações sobre o solicitante da modificação e de registro de controle de
modificação.
•
Sistema de acompanhamento: possui capacidade para registrar a informação do
cliente e do responsável pelo processo, capacidade de registrar informações da
configuração do sistema relacionado, capacidade de registrar informações sobre o
problema ou ação necessária (data de abertura e data esperada para fechamento,
severidade, estado de qualquer ocorrência ou ações necessárias, informações sobre o
responsável pela ocorrência ou solução, prioridade para atendimento da ocorrência),
capacidade para registrar a solução proposta ou plano de ação, capacidade para
fornecer informação sobre o estado do gerenciamento, disponibilidade de
informações a todos os envolvidos e sistema(s) de controle de solicitação de
modificação e registros.
•
Biblioteca da Gerência da Configuração: contém todos os itens de configuração
do projeto. Possibilita o controle de versão, armazenamento e obtenção de itens de
configuração, compartilhamento e transferência de itens de configuração entre
membros do projeto, controle efetivo sobre o acesso, manutenção da descrição dos
itens, recuperação de versões anteriores (archived) de itens de configuração.
Possibilita a criação das configurações-base de distribuição, interna ou externa,
além de conter os metadados dos itens de configuração, que permitem a extração de
129
relatório da situação da configuração e acompanhamento das solicitações de
modificação nos itens de configuração.
•
Orientação para manuseio e armazenamento: define as tarefas a serem
executadas no manuseio, armazenamento e obtenção dos itens de configuração, bem
como para a atualização do histórico de modificação.
•
Configuração-base de distribuição: é a configuração-base de produto utilizada
para gerar uma distribuição do produto para fora do ambiente de desenvolvimento.
•
Registro de estado de progresso: registro da situação do planejado em relação à
situação atual, como: tarefas atuais em relação às planejadas, resultados obtidos em
relação aos objetivos e metas, alocação de recursos em relação aos recursos
planejados, custo atual em relação ao estimado, tempo despendido em relação ao
cronograma estabelecido. Registro de qua isquer desvios das atividades planejadas e
motivos.
•
Relatório de controle de modificação: contém os atributos do registro de controle
de modificação. É usado como um mecanismo para controlar a modificação dos
itens de configuração contidos na biblioteca da GCS. Contém o registro da
modificação solicitada e feita em um produto de configuração-base. Contém
identificação: do sistema e dos documentos afetados pela modificação, do
solicitante da modificação, do responsável pela modificação e do estado da
modificação. Apresenta a ligação com outras modificações associadas (internas ou
do cliente) e aprovações apropriadas. As solicitações duplicadas são identificadas e
agrupadas.
•
Solicitação de modificação: deve permitir a identificação do propósito da
modificação, do estado da solicitação, informações do solicitante, itens impactados,
130
impacto nas operações de sistemas existentes, impacto na documentação associada,
severidade da solicitação e data para atendimento.
•
Relatório de ocorrência: contém a identificação do relator da ocorrência e outros
detalhes de contatos já submetidos associados à ocorrência, informações da
configuração do sistema (versão da distribuição, etc.), identificação do grupo ou
pessoa responsável pela correção, uma descrição do problema, severidade da
ocorrência, identificação do estado do problema relatado, quais componentes são
afetados, identificação de qual distribuição incluirá a correção do problema, a data
esperada para fechamento, os critérios de fechamento e ações de re- inspeção
necessárias.
•
Mecanismo de comunicação: uma maneira de distribuir informações, que permita
uma descrição clara daquilo que está sendo comunicado, a identificação da data de
envio, a distribuição a todos os envolvidos, a identificação do impacto, a
identificação cla ra do destinatário da mensagem, um mecanismo de recepção de
respostas quando necessário. Uma lista de distribuição atualizada deve estar
disponível. O mecanismo deve ainda permitir a especificação de uma data de
retorno.
4.4.4
O Processo de Definição das Estratégias Organizacionais da GCS
O desenvolvimento de uma política para a GCS em uma organização, e os subseqüentes
planos para cada produto desenvolvido, são essenciais para a implementação bem sucedida
da GCS (Futrell et al, 2002). As estratégias da GCS para a organização devem expor, de
maneira clara e concisa, as expectativas que a liderança da organização tem em relação às
atividades da GCS. Elas devem também possibilitar que os benefícios trazidos com a
adoção da GCS possam ser evidenciados, definindo os métodos para medir o desempenho
destes benefícios.
131
Este processo abrange, portanto, a definição das estratégias para as atividades relacionadas
à GCS na organização, ou seja, a definição de como é conduzido o processo da GCS, de
acordo com as características da organização e dos projetos.
Um procedimento para desenvolver um PGCS deve ser elaborado e um modelo de PGCS
deve ser colocado à disposição para ser adequado de acordo com as características de um
projeto.
4.4.4.1
Objetivos e Requisitos Básicos do Processo
O objetivo principal deste processo é definir as estratégias gerais do processo da GCS na
organização. Estas estratégias gerais incluem estratégias para as atividades do
gerenciamento da configuração, para as atividades do gerenciamento das solicitações de
modificação e de desenvolvimento paralelo. O responsável pela execução deste processo é
o Gerente da Configuração e das Modificações.
Os requisitos básicos deste processo são:
Estratégias para a GCS devem ser definidas: os objetivos e o escopo da GCS na
organização devem ser definidos; estratégias para as atividades do gerenciamento da
configuração, para o gerenciamento das solicitações de modificação e de desenvolvimento
paralelo, bem como para o planejamento do processo da GCS devem ser estabelecidas.
Métricas para a GCS devem ser definidas: métricas devem ser definidas para a GCS,
bem como os métodos utilizados para a coleta das medidas para as métricas.
Os requisitos para o processo de Definição das Estratégias Organizacionais da GCS são
atendidos pelo pacote de atividades que compõem o processo, representados através do
diagrama de pacotes da Figura 4.2.
132
Definição das Estratégias
Organizacionais da GCS
Gerente das Modificações e da Configuração
Definir objetivos e escopo da GCS ( )
Definir estratégias para identificação da
configuração ( )
Definir estratégias para armazenamento e controle
da configuração ( )
Definir estratégias para controle das solicitações de
modificações ( )
Definir estratégias para o relato da situação da
configuração ( )
Definir estratégias para desenvolvimento
paralelo ( )
Definir estratégias para o planejamento da GCS ( )
Definir métricas para a GCS ( )
Registro de Estado
do Progresso
Descrição,
procedimentos e
convenções da
GCS
Orientação para
elaboração do
PGCS
Modelos de
Formulários
Plano de
Estratégias da
GCS
Modelo
de PGCS
Modelos de
Relatórios
FIGURA 4.2 – O Processo de Definição das Estratégias Organizacionais da GCS.
Este processo pode valer-se ainda de uma ferramenta que auxilie o Gerente das
Modificações e da Configuração documentar e implementar o Plano de Estratégias para a
GCS.
133
4.4.4.2
Papéis, Responsabilidades e Produtos Envolvidos no Processo
Cabe ao Gerente das Modificações e da Configuração, em concordância com as políticas da
Qualidade e do Projeto, estabelecer as estratégias da GCS e consolidá- las em um Plano de
Estratégias da GCS para a organização. O Gerente das Modificações e da Configuração fica
ainda responsável pela elaboração das orientações para elaboração do Plano da GCS
(PGCS), bem como de um modelo de referência para um PGCS e outros modelos de
formulários e relatórios da GCS.
O Gerente das Modificações e da Configuração deve definir, de acordo com a política de
métricas da organização definida pela Qualidade, as métricas utilizadas pela GCS, que
devem fazer parte do Plano de Métricas da organização. O Gerente deve ainda determinar
os tipos dos relatórios de registro de estado, que contêm os resultados obtidos e são
encaminhados à Gerência superior.
O diagrama de classes da Figura 4.3 mostra o relacionamento entre o Gerente das
Modificações e da Configuração e os produtos associados com o processo de Definição das
Estratégias Organizacionais da GCS.
134
*
Plano de
Estratégias da
GCS
1
1
1
1
1
Gerente das Modificações
e da Configuração
Descrição, procedimentos
e convenções da GCS
1
*
Modelos de
Formulários
*
*
Modelos de
Relatórios
*
Orientação para
elaboração do PGCS
Registro de Estado do
Progresso
Modelo de
PGCS
FIGURA 4.3 – O Gerente das Modificações e da Configuração e os Produtos do Processo
de Definição das Estratégias Organizacionais da GCS.
4.4.4.3
Atividades do Processo
O pacote de processo de Definição das Estratégias Organizacionais da GCS agrupa as
atividades, os papéis e os produtos do trabalho que possibilitam a implantação do processo
da GCS com sucesso na organização. Através destas atividades, vários projetos, de
abordagens metodológicas diversas, podem utilizar os recursos fornecidos pela GCS de
forma eficiente.
Este pacote estabelece as estratégias gerais para as atividades da GCS, que servem de
orientação para todos os projetos de software desenvolvidos pela organização.
135
A necessidade de execução da GCS e o nível de ambição para esta execução podem ter
origem em diversos fatores, como: requisitos externos do cliente, padrões específicos, como
no caso de sistemas críticos quanto à segurança ou para certificação. Nesta abordagem, os
requisitos para a GCS se originam das práticas de um modelo de maturidade, para
organizações que visam a melhoria da qualidade no desenvolvimento de software.
É importante salientar que as estratégias para as atividades da GCS podem ser adequadas à
medida que uma organização utiliza um modelo de processo. Para isto é necessário que, a
partir de estratégias iniciais, o processo seja controlado (com o registro de estado do
progresso de suas atividades), avaliado e revisado, para que possa ser melhorado. Qualquer
proposta para a criação de um novo processo fica, portanto, sujeita ao seu planejamento e
definição de modelo, execução, acompanhamento e finalmente avaliação, conforme
descrito no Capítulo 3, no ciclo de vida proposto para o Ambiente Integrado. Os benefícios
da GCS, como os ganhos obtidos através da prevenção de problemas e a melhoria da
qualidade, devem ser explicitados e comunicados, quando da revisão do processo. Os
esforços da GCS devem priorizar estes ganhos, mantendo, no entanto, a coerência com o
foco estratégico da organização, que pode ser a satisfação do cliente, a produtividade, a
qualidade, a segurança, e assim por diante.
As atividades deste Pacote são descritas a seguir.
Definir objetivos e escopo da GCS. Esta atividade consiste em:
•
Definir claramente os objetivos da GCS na organização, ou seja, definir o ponto de
partida, com referências a problemas atuais, e onde se quer chegar.
•
Determinar o escopo da GCS, no que diz respeito aos tipos de objetos colocados sob
a GCS, aos graus de formalismo com que a GCS é executada e sob quais
circunstâncias cada grau é utilizado.
136
•
Definir os critérios para determinar quando cada item de configuração é colocado
sob o gerenciamento da configuração, que podem ser marcos do ciclo de vida do
projeto e o estado do item de configuração (quando estiverem aprovados pela
qualidade, por exemplo). Deve-se levar em conta o grau de controle desejado para o
item de configuração e limitações de custo e cronograma, requisitos do cliente, etc.
Definir estratégias para identificação da configuração. Esta atividade consiste em:
•
Definir os critérios que podem ser empregados na seleção dos itens de configuração.
•
Definir as convenções e esquemas para identificação única dos itens de
configuração.
•
Definir as características importantes que podem ser empregadas para descrever os
itens de configuração (autor, tipo, data de criação, responsável, etc.).
•
Definir as maneiras como o esquema de identificação pode endereçar as versões e
distribuições.
•
Definir critérios que podem ser utilizados para inter-relacionamento dos itens de
configuração.
•
Definir critérios para determinação do conjunto de configurações-base e do
conteúdo destas.
Definir estratégias para armazenamento e controle da configuração. Esta atividade
consiste em:
•
Definir estruturas e hierarquias gerais de diretórios e arquivos, que possam ser
adaptadas e utilizadas nos projetos da organização para fornecer um meio eficiente
de acessar e armazenar os itens necessários, facilitando o gerenciamento da
evolução dos itens de configuração e sua organização. Por exemplo, diretórios
137
separados podem ser utilizados para documentos de projeto, código fonte,
documentos de apoio, testes, linhas de desenvolvimento paralelo, etc.
•
Definir os tipos (estática, dinâmica e controlada) das bibliotecas utilizadas na
organização.
•
Definir procedimentos gerais para criação e retenção das bibliotecas no repositório.
•
Definir procedimentos e políticas gerais para as distribuições na organização.
•
Definir procedimentos gerais para o acesso aos itens de configuração contidos nas
bibliotecas.
•
Definir os tipos de informações sobre as modificações nos itens de configuração que
vão ser registradas.
•
Definir maneiras para retenção das informações sobre as modificações, que irão
compor o registro de histórico das modificações, na base de dados da GCS.
Definir estratégias para controle das solicitações de modificação. Esta atividade
consiste em:
•
Definir os procedimentos gerais para controle e acompanhamento das solicitações
de modificação nos itens de configuração.
•
Elaborar um checklist para análise de impacto das modificações.
•
Descrever os graus de controle sobre a configuração que podem ser utilizados. Estes
graus variam de acordo com critérios como severidade da modificação, urgência,
fase de desenvolvimento, tipo de projeto.
•
Descrever mecanismos que podem ser utilizados para graduar o controle. Estes
mecanismos podem ser os níveis de autoridade para a modificação, através dos
138
vários GCCs, modo de comunicação da modificação, na permissão de acesso à
biblioteca controlada e ao tipo de configuração-base.
•
Definir convenções para formar diferentes tipos de GCCs. Definir quais
informações deve m ser fornecidas, como responsabilidades, membros, papéis,
procedimentos, mecanismos de aprovação.
•
Definir convenções para a numeração e identificação das solicitações de
modificação.
•
Definir esquemas de classificação para aprovação das solicitações de modificação.
Definir estratégias para o relato da situação da configuração. Esta atividade consiste
em:
•
Definir critérios gerais para a coleta, registro, processamento e manutenção das
informações necessárias (metadados associados aos itens de configuração e os
obtidos das solicitações de modificação).
•
Definir periodicidade e tipos de relatórios de situação gerenciais, que mostram o
estado e histórico dos itens de configuração, e o público alvo de cada um.
•
Definir critérios que podem ser utilizados para extração de relatórios ad hoc.
•
Definir critérios para se restringir o acesso às informações da situação da
configuração.
Definir estratégias para desenvolvimento paralelo. Esta atividade consiste em:
•
Definir critérios para classificação de desenvolvimento paralelo e variante.
•
Definir estratégias para a união das linhas de desenvolvimento em um único item de
configuração.
139
•
Definir convenções para a definição da identificação das linhas de desenvolvimento
paralelo.
•
Definir critérios específicos que podem ser empregados para controle das
modificações e relato da situação das linhas de desenvolvimento paralelo.
Definir estratégias para o planejamento da GCS. Esta atividade consiste em:
•
Definir o contexto organizacional da GCS.
•
Definir restrições e orientações gerais aplicáveis a GCS na organização.
•
Descrever orientações para criação e manutenção do PGCS.
•
Elaborar a Orientação para elaboração do PGCS.
Definir métricas para a GCS. Esta atividade consiste em:
•
Definir quais as métricas vão ser utilizadas, ou seja, o que se deseja medir. Garantir
que as métricas definidas respondam a questões para as quais realmente se desejam
respostas.
•
Definir os tipos de dados a serem coletados (dados brutos, medidas diretas ou
indiretas).
•
Definir aspectos das métricas como definições, unidades, consistência, escala, etc.
Algumas das métricas que podem ser utilizadas são (CMBoK, 2003):
Média de tempo de processo por mês: útil para monitorar a efetividade do fluxo de
trabalho, como por exemplo, o tempo gasto para processar uma solicitação de modificação,
desde sua abertura até seu fechamento.
140
Atividade de modificação em um item de configuração de software : utilizada para
ilustrar, por exemplo, a taxa do número de modificações por item de configuração, feitas
mensalmente.
Finalização de modificação: utilizadas para analisar o tratamento de modificações adotado
pelo processo.
Outras métricas que podem ser coletadas e registradas são: número total de modificações
completadas, número de solicitações de modificação não concluídas, número de
solicitações de modificação rejeitadas, etc.
4.4.5
O Processo de Planejamento da GCS
Quando se deseja iniciar o processo da GCS em um projeto é preciso realizar o seu
planejamento de acordo com as características deste projeto. Este planejamento consiste na
adequação de estratégias já estabelecidas para a GCS na organização, definidas no Plano de
Estratégias da GCS, para um projeto em particular, e deve ser consolidado no Plano de
Gerência da Configuração de Software (PGCS) do projeto. Depois de revisado e aprovado,
o PGCS passa a servir como um guia para as atividades da GCS aos envolvidos no
processo. Ele deve ser apresentado a toda a equipe pelo gerente de projeto e disponibilizado
para ser acessado eletronicamente, a qualquer momento. O PGCS é ele próprio um item de
configuração e deve ser colocado sob o controle da GCS.
O planejamento da GCS envolve o planejamento da execução das atividades da GCS, a
definição do relacionamento da GCS com o ambiente de projeto, o planejamento das
atividades e da condução das tarefas, fases e marcos da GCS, e ainda, das ferramentas,
técnicas e métodos necessários para a implantação do processo.
As atividades da GCS devem ser integradas no cronograma geral do projeto, fazendo parte
do plano geral de projeto.
141
O planejamento da GCS deve ter seu início junto com o do projeto, mas os detalhes devem
ser planejados somente para o período ou fase imediatamente à frente, tal como a primeira
atividade da GCS. Mais detalhes vão sendo acrescentados à medida que se tornam
conhecidos, mas deve-se deixar bem claro o que ficou para ser definido depois.
Uma vez planejado o processo, é preciso estabelecer o ambiente para a GCS, ou seja,
configurar ferramentas de suporte, criar as bibliotecas da GCS para o projeto, etc.
4.4.5.1
O objetivo principal deste processo é planejar as estratégias do processo da GCS
específicas para um projeto. Estas estratégias incluem estratégias para as atividades do
gerenciamento da configuração, para as atividades do gerenciamento das solicitações de
modificação e de desenvolvimento paralelo.
O responsável pela execução deste processo é o Gerente das Modificações e da
Configuração.
O gerenciamento e as relações com o ambiente de projeto são definidos: engloba as
atividades de definição da organização da GCS, das responsabilidades, do controle de
interfaces, do gerenciamento de subcontratados, se houver, e de padrões relevantes para o
projeto.
As atividades da GCS são descritas: as atividades de ident ificação dos itens de
configuração, do armazenamento e controle dos itens de configuração, do controle e
acompanhamento das solicitações de modificação, e do relato da situação da configuração
devem ser definidas e descritas.
142
A condução das tarefas, fases e marcos da GCS são definidos: o relacionamento entre as
tarefas que devem ser executadas às fases e marcos gerais do gerenciamento da
configuração deve ser descrito.
A utilização de ferramentas, técnicas e métodos é descrita: isto envolve a descrição de
ferramentas, técnicas e métodos utilizados pela GCS ou referências a descrições,
procedimentos e convenções gerais existentes e documentados do processo.
A estrutura de arquivos e diretórios é definida: envolve a definição das estruturas de
arquivos e diretórios utilizados para conter os itens de configuração nas bibliotecas da
configuração. Esta estrutura deve ser organizada logicamente de maneira tal que garanta
que todos os itens de configuração estejam acessíveis. O formato da estrutura depende do
número de subsistemas ou módulos do software desenvolvido, e do número de
componentes em cada módulo. Esta estrutura lógica do produto não está totalmente
definida até o final das atividades de análise e projeto. No entanto, uma estrutura inicial
para o projeto deve ser criada para conter os produtos de trabalho das fases iniciais de
planejamento e gerenciamento. O restante da estrutura pode ser elaborada depois que as
decisões sobre o projeto tenham sido tomadas e a visão da implementação esteja mais clara,
bem como a maneira como os elementos do projeto serão agregados para implementação.
Linhas de desenvolvimento paralelo são definidas: estratégias para a criação de linhas de
desenvolvimento paralelo devem ser definidas para o projeto, se necessário, segundo as
diretrizes gerais definidas.
O ambiente para a GCS é estabelecido: isto envolve a preparação de um ambiente para a
GCS, incluindo a criação da biblioteca da GCS e definição das autorizações e mecanismos
de acesso, a configuração de ferramentas de suporte às atividades da GCS, como um
sistema de controle e acompanhamento de modificações entre outras.
143
Os requisitos para o processo Implantação da GCS são atendidos pelos pacotes de
atividades que compõem o processo, representados através do diagrama de pacotes da
Figura 4.4.
Planejamento da GCS
Definição do
gerenciamento e relações
da GCS com o ambiente
de projeto
Definição da condução das
tarefas, fases e marcos da
GCS
Definição de linhas de
desenvolvimento paralelo
Descrição das atividades da
GCS
Descrição de ferramentas,
técnicas e métodos da GCS
Definição do ambiente da
GCS
FIGURA 4.4 – O Processo de Planejamento da GCS.
Uma ferramenta para auxiliar o Gerente das Modificações e da Configuração a elaborar o
Plano da GCS e documentá- lo, tornando-o facilmente acessível a todos os envolvidos no
projeto, assim como, ferramentas de gerenciamento de projeto, como diagramas e gráficos,
144
para o suporte às descrições do planejamento e para o acompanhamento das atividades da
GCS no projeto são requisitos desejáveis para o processo.
4.4.5.2
Cabe ao Gerente das Modificações e da Configuração adequar as estratégias da GCS,
definidas na organização e estabelecidas no Plano de Estratégias da GCS, para um projeto
em particular e consolidá-las no Plano da GCS. Na elaboração do Plano devem ser seguidas
as orientações para elaboração do Plano da GCS (PGCS) já estabelecidas, assim como o
modelo de referência definido.
O Gerente das Modificações e da Configuração deve utilizar as descrições de processo,
procedimentos e convenções, já estabelecidos para o processo da GCS e referenciá- las no
Plano. Na falta destes, o Gerente das Modificações e da Configuração deve defini- los e
descrevê- los.
O diagrama de Classes da Figura 4.5 mostra o relacionamento entre o Gerente da
Configuração e das Modificações e os produtos associados com o processo de Implantação
da GCS.
145
Orientação para
PGCS
Plano de
Desenvolvimento
Modelo de
PGCS
Plano de
Distribuição
*
Gerente das Modificações
e da Configuração
1
1
Plano de1
Estratégias da
GCS
*
*
Modelos de
Formulários
Modelos de
Relatórios
FIGURA 4.5 – O Gerente das Modificações e da Configuração e os Produtos do Processo
de Planejamento da GCS.
4.4.5.3
Os diagramas de pacotes do processo de Planejamento da GCS agrupam as atividades, os
papéis e os produtos do trabalho que possibilitam a implantação do processo da GCS com
sucesso na organização.
146
Cabe ressaltar que as estratégias para as atividades da GCS para o projeto são estabelecidas
e consolidadas no PGCS à medida que o projeto se desenvolve. Assim, detalhes
desconhecidos no início do projeto, como por exemplo, os itens que compõem a
configuração-base de produto, são adicionados à medida que o projeto evolui para suas
fases finais. Para isto é necessário que o PGCS seja revisado periodicamente, dentro da
atividade de manutenção do plano. Deste modo, o plano deve identificar e descrever as
atividades e responsabilidades necessárias para garantir um planejamento continuado da
GCS durante todo o ciclo de vida do projeto.
4.4.5.3.1
O Pacote Definição do Gerenciamento e Relações com o Ambiente
de Projeto
O pacote de Gerenciamento e Relações com o Ambiente de Projeto, Figura 4.6, define os
papéis, a organização e a alocação de responsabilidades da GCS no projeto.
Definir o contexto organizacional da GCS. Esta atividade consiste em:
•
Especificar a organização completa da GCS e como esta se encaixa no resto da
organização do projeto.
•
Descrever em termos gerais os papéis a serem preenchidos. Caso várias
organizações estejam envolvidas no projeto, definir claramente qual delas é a
responsável pela condução da GCS, em qual fase do ciclo de vida do software.
Definir responsabilidades da GCS. Esta atividade consiste em:
•
Identificar os responsáveis pela execução de atividades da GCS, nas funções de
identificação, controle, registro e relato da situação da configuração.
147
Gerenciamento e Relações
com o Ambiente de Projeto
Definir o contexto organizacional da GCS ( )
Definir responsabilidades da GCS ( )
Definir procedimentos para gerenciar interfaces ( )
Definir padrões relevantes ( )
Plano de
Estratégias da
GCS
Modelo de
PGCS
Orientação para
elaboração do
PGCS
PGCS
FIGURA 4.6 – O Pacote de Gerenciamento e Relações com o Ambiente de Projeto.
•
Definir os papéis organizacionais responsáveis pela aprovação de configuraçõesbase e distribuições.
Isto pode ser apresentado conforme a TABELA 4.1.
148
TABELA 4.1 – Papéis e Responsabilidades da GCS.
Gerente de
projeto
Atividade 1
Atividade 2
Atividade 3
I
I
I
Papéis
Responsável Gerente das
pela GCS modificações
e da
Configuração
S
R
R
I
R
I
GCC-1
GCC-2
A
R=Responsável; A=Aprovação; S=Suporte; I=Informação (GCC – Grupo de Controle da
Configuração)
Definir procedimentos para gerenciar interfaces. Esta atividade consiste em:
•
Definir as atividades de coordenação das modificações feitas nos itens de
configuração do projeto que façam interface com itens de outros sistemas, caso
existam.
•
Definir as estratégias para o suporte a subcontratante/vendedor. Descrever qualquer
suporte e interface de subcontratante e/ou vendedor se aplicável.
•
Definir como incorporar os itens desenvolvidos externamente aos itens de
configuração do projeto, tanto de software subcontratado como adquirido.
Definir padrões relevantes. Esta atividade consiste em:
•
Descrever as orientações e políticas às quais o projeto segue, referenciando os
padrões e políticas da organização que afetam as atividades da GCS.
149
4.4.5.3.2
O Pacote Descrição das Atividades da GCS
O pacote de descrição das atividades da GCS, Figura 4.7, contém a descrição das atividades
da GCS a serem executadas para um projeto. Estas atividades consistem na identificação
dos itens de configuração, no controle do armazenamento apropriado e acesso aos itens de
configuração, no controle da configuração, no acompanhamento e controle das solicitações
de modificação, e também no relato da situação da configuração. Devem ser referenciados
as descrições, as convenções e os procedimentos já definidos do processo da GCS.
As atividades que compõem este pacote são descritas a seguir.
Identificar a configuração. Esta atividade consiste em:
•
Definir quais são os itens de configuração do projeto, segundo critérios
estabelecidos na organização.
•
Descrever ou referenciar as convenções e o esquema para identificação única dos
itens de configuração que serão utilizados no projeto, incluindo os documentos de
projeto, as configurações-base e distribuições.
•
Descrever ou referenciar os critérios de atribuição de número de revisão/versão aos
itens de configuração.
•
Especificar quando cada item de configuração é colocado sob o gerenciamento da
configuração.
•
Descrever o conjunto de configurações-base e distribuições, bem como as
convenções utilizadas para identificação das mesmas.
•
Descrever o conteúdo das configurações-base, como e quando elas são criadas,
quais os critérios e propósitos para a criação.
150
•
Descrever o critério para inter-relacionamento dos itens de configuração.
•
Descrever os procedimentos para herança de metadados dos itens de configuração.
Descrição das Atividades da GCS
Identificar a configuração ( )
Armazenar e controlar os itens de configuração ( )
Controlar modificações ( )
Relatar a situação da configuração ( )
Avaliar a configuração ( )
Plano de
Estratégias da
GCS
Orientação para
Modelo de
elaboração
do PGCS
PGCS
PGCS
Plano de
Distribuição
FIGURA 4.7 – O Pacote de Descrição das Atividades da GCS.
Armazenar e controlar os itens de configuração: Esta atividade consiste em:
151
•
Identificar as bibliotecas que serão utilizadas no projeto e o tipo de cada uma delas.
•
Descrever a estrutura de diretório a ser usada no projeto para gerenciar a evolução
dos itens de configuração e organizá- los (as bibliotecas podem ser apresentadas na
forma de estrutura de arquivos e diretórios, diretórios separados podem ser
utilizados para documentos de projeto, código fonte, documentos de apoio, testes,
etc.).
•
Descrever os procedimentos para criação e retenção das bibliotecas (o que precisa
ser retido, por quem e por quanto tempo) do projeto.
•
Descrever procedimentos e políticas para as distribuições no projeto.
•
Descrever procedimentos para o acesso aos itens de configuração contidos nas
bibliotecas do projeto.
•
Descrever as informações sobre as modificações nos itens de configuração que
serão armazenadas.
•
Descrever como o histórico das modificações é retido.
Controlar modificações: Esta atividade consiste em:
•
Descrever os procedimentos para controle e acompanhamento das solicitações de
modificação nas configurações-base do projeto, como a periodicidade das reuniões
do GCC.
•
Descrever os níveis de controle sobre a configuração adotados para o projeto, de
acordo com critérios já definidos, como severidade da modificação, urgência, fase
de desenvolvimento, tipo de projeto.
152
•
Selecionar os mecanismos usados pelo controle de modificações. Estes mecanismos
podem agir nos níveis de autoridade para a modificação, tipo da reunião do GCC e
no acesso à biblioteca controlada.
•
Descrever os diferentes tipos de GCCs necessários para o projeto, fornecendo, para
cada um, as seguintes informações: responsabilidades, membros, papéis,
mecanismos de aprovação. Quando aplicável, descrever as interfaces, a hierarquia
geral e a responsabilidade de comunicação entre os vários GCCs da organização.
•
Selecionar as regras de identificação do formulário de solicitação de modificação.
•
Selecionar o esquema de classificação para aprovação das solicitações de
modificação.
Relatar a situação da configuração. Esta atividade consiste em:
•
Descrever os métodos selecionados para coleta, registro, processamento e
manutenção dos dados necessários para fornecer informações da situação através de
relatórios e/ou acesso à base de dados da GCS e das solicitações de modificações.
•
Definir os tipos e a periodicidade dos relatórios gerenciais que mostram o estado e
histórico dos itens de configuração, bem como o público alvo de cada um.
•
Definir as restrições de acesso às informações da situação da configuração.
•
Definir as distribuições, para quem elas estão autorizadas e as informações que
devem ser registradas sobre elas, como: a funcionalidade incluída na distribuição, o
conteúdo da distribuição, componentes associados necessários, o meio no qual a
distribuição é feita, problemas conhecidos, soluções de problemas conhecidos,
instruções de instalação e um mapeamento das solicitações dos clientes e requisitos
satisfeitos pela distribuição. Estas informações podem ser consolidadas em um
Plano de Distribuição.
153
Avaliar a configuração. Esta atividade consiste em:
•
Referenciar as auditorias físicas e funcionais a serem realizadas pela Gerência da
Qualidade, bem como as revisões. Deve-se mencionar quando elas serão feitas, a
qual configuração-base elas estão ligadas, e qual é o papel desempenhado pela GCS.
4.4.5.3.3
O Pacote Definição da Condução das Tarefas, Fases e Marcos da
GCS
O pacote de Definição da Condução das Tarefas, Fases e Marcos da GCS, Figura 4.8,
descreve as tarefas ligadas às atividades da GCS, inclusive o treinamento necessário às
atividades. As tarefas estão intimamente relacionadas aos papéis que as realizam. É preciso,
tanto quanto possível, documentar quais pessoas preenchem quais papéis, de maneira que
os recursos necessários sejam planejados eficientemente. Como qualquer projeto de
desenvolvimento, a GCS possui vários marcos que devem ser definidos e descritos, e,
geralmente, coincidem com os marcos definidos para o projeto no Plano de
Desenvolvimento. Ferramentas de gerenciamento de projeto, como diagramas e gráficos,
podem ser utilizadas para o suporte às descrições do planejamento e para o
acompanhamento das atividades da GCS no projeto. O planejamento continuado da GCS
deve ser garantido durante todo o ciclo de vida do projeto.
154
Definição da Condução das
Tarefas, Fases e Marcos da
GCS
Definir a condução das tarefas da GCS ( )
Definir as fases e marcos da GCS ( )
Definir a manutenção do planejamento da GCS ( )
Plano de
Plano de
Modelo de Orientação para PGCS
Desenvolvimento
elaboração do
Estratégias da
PGCS
de
Software
PGCS
GCS
FIGURA 4.8 – O Pacote de Definição da Condução das Tarefas, Fases e Marcos da GCS.
Definir a condução das tarefas da GCS. Esta atividade consiste em:
•
Relacionar as tarefas das atividades da GCS.
•
Associar pessoas a papéis a serem desempenhados.
•
Determinar o tipo e a quantidade de treinamento (por exemplo, orientação,
ferramentas).
Definir as fases e marcos da GCS. Esta atividade consiste em:
155
•
Definir todos os marcos da GCS, tais como: sistema de GCS pronto para utilização
na próxima atividade, estabelecimento do(s) GCC(s), estabelecimento das
configurações-base, etc.
•
Descrever como os marcos da GCS estão ligados às fases estabelecidas para o
processo de desenvolvimento de software e os critérios para alcançar cada marco.
•
Definir os critérios para que o marco seja alcançado, ou seja, determinar as
condições que os itens de configuração que fazem parte da configuração-base
associada ao marco devem alcançar. Estes critérios são definidos em conjunto com
e verificados pelo processo da Qualidade.
Definir a manutenção do planejamento da GCS. Esta atividade consiste em:
•
Estabelecer quando os procedimentos e estrutura da GCS devem ser revistos.
•
Definir como as modificações no planejamento são avaliadas e aprovadas.
•
Definir quando as modificações são feitas e comunicadas aos integrantes do projeto.
4.4.5.3.4
O Pacote Descrição de Ferramentas, Técnicas e Métodos da GCS
O pacote Descrição de Ferramentas, Técnicas e Métodos da GCS, Figura 4.9, relaciona as
ferramentas, as técnicas e métodos disponíveis para a GCS selecionadas para o suporte às
suas atividades. Devem ser feitas descrições e referências às descrições, procedimentos e
convenções da GCS existentes, assim como às ferramentas e serviços de suporte às
atividades da GCS disponibilizadas pelo ambiente.
156
Descrição de Ferramentas,
Técnicas e Métodos da GCS
Descrever ferramentas da GCS ( )
Descrever métodos da GCS ( )
Descrever técnicas da GCS ( )
Definir modelos de formulários e relatórios da
GCS ( )
Plano de
Estratégias da
GCS
Modelo de
PGCS
Orientação para
elaboração do
PGCS
Modelos de
Relatórios
PGCS
Modelos de
Formulários
FIGURA 4.9 – Pacote de Definição da Utilização de Ferramentas, Técnicas e Métodos.
As ferramentas utilizadas referem-se àquelas desenvolvidas para facilitar e automatizar as
atividades da GCS, e podem ser ferramentas dedicadas, estruturas de diretórios, base de
dados, formulários, etc. Entre as primeiras estão ferramentas para armazenamento dos itens
de configuração e seus metadados, com controle de versões, e para o gerenciamento das
solicitações de modificação. Deve-se descrever como as ferramentas são utilizadas, bem
como as conexões com outras ferramentas. As técnicas e métodos descrevem o trabalho a
157
ser feito e a maneira como deve ser feito. As descrições podem ser para cada tipo de item
de configuração e para graus de formalismo diferentes para cada tipo. Devem ser definidos
ou incluídas referências aos modelos de formulários e relatórios a serem utilizados pela
GCS.
Descrever ferramentas da GCS. Esta atividade consiste em:
•
Referenciar as ferramentas aplicadas à estrutura e controle de acesso a bibliotecas,
desenvolvimento
e
rastreamento
de
documentação,
processamento
das
modificações, comunicação e autorização, relato de situação, armazenamento,
retenção e recuperação de itens de configuração, de planejamento da GCS, e
geração de distribuições do sistema.
•
Associar a ferramenta necessária para cada atividade da GCS identificada.
•
Descrever ou referenciar as funções de cada ferramenta.
Descrever métodos da GCS. Esta atividade consiste em:
•
Descrever ou referenciar a descrição dos métodos necessários para cada atividade
da GCS identificada.
Descrever técnicas da GCS. Esta atividade consiste em:
•
Descrever ou referenciar as técnicas necessárias para cada atividade da GCS
identificada.
Definir modelos de formulários e relatórios da GCS. Esta atividade consiste em:
•
Definir quais serão os formulários utilizados pela GCS.
158
•
Definir os relatórios a serem gerados pela GCS, segundo critérios estabelecidos para
a organização.
4.4.5.3.5
O Pacote Definição de Linhas de Desenvolvimento Paralelo
O pacote de Definição de Linhas de Desenvolvimento Paralelo, Figura 4.10, define a
estratégia de gerenciamento das linhas de desenvolvimento paralelo a ser utilizada no
projeto, quando necessário. No desenvolvimento paralelo pode ocorrer a necessidade da
união de linhas de desenvolvimento, no caso em que as particularidades de uma linha
devam ser incorporadas à linha principal. O momento em que uma linha de
desenvolvimento deve ser criada ou unida à principal deve ser definido, bem como o
critério utilizado para identificação das linhas de desenvolvimento e versões de seus
componentes.
Definição de Linhas de
Desenvolvimento Paralelo
Definir o gerenciamento das linhas
de desenvolvimento paralelo ( )
Definir critérios de identificação ( )
Plano de
Estratégias da
GCS
Modelo de
PGCS
Orientação para
PGCS
FIGURA 4.10 – Pacote de Definição de Linhas de Desenvolvimento Paralelo.
159
Definir o gerenciamento das linhas de desenvolvimento paralelo. Esta atividade consiste
em:
•
Definir quando e porque as linhas de desenvolvimento são criadas.
•
Definir atividades que ocorrerão nas linhas de desenvolvimento.
•
Definir quando as linhas de desenvolvimento são completadas.
•
Definir quando as linhas de desenvolvimento são unidas à linha principal.
Definir critérios de identificação. Esta atividade consiste em:
•
Definir a atribuição de números de versão às linhas.
•
Definir a atribuição de rótulos ou nome às linhas.
4.4.5.3.6
O Pacote Definição do Ambiente da GCS
O pacote Definição do Ambiente da GCS, Figura 4.11, define o ambiente operacional da
GCS, ou seja, o ambiente onde as atividades da GCS serão desenvolvidas. A definição do
ambiente envolve tanto a alocação de recursos físicos (espaço em disco para o repositório e
base de dados) quanto a instalação ou configuração de ferramentas utilizadas para o suporte
às atividades da GCS, como um sistema de controle e acompanhamento de modificações.
160
Definição do Ambiente da
GCS
Gerente das Modificações e da
Configuração
Alocar recursos físicos ( )
Criar a biblioteca da GCS ( )
Configurar ferramentas de suporte ( )
Item de
Configuração
Biblioteca
da GCS
Configuração
do produto
PGCS
Sistema de
acompanhamento
Orientação para manuseio e
armazenamento
FIGURA 4.11 – Pacote de Definição do Ambiente da GCS.
O estabelecimento do ambiente de desenvolvimento envolve, assim, o estabelecimento da
estrutura de diretório do produto, através da criação da biblioteca da GCS, a definição das
autorizações e mecanismos de acesso, o check-in dos arquivos já existentes, se for o caso,
por exemplo, de um projeto de manutenção de software. O ambiente estabelecido
inicialmente servirá de base para qualquer trabalho de desenvolvimento posterior.
161
Alocar recursos físicos. Determinar a localização física do repositório que conterá a
biblioteca da GCS.
Criar a biblioteca da GCS. Esta atividade consiste em:
•
Criar a biblioteca da GCS identificada no planejamento, segundo a estrutura de
diretório inicial selecionada para utilização no projeto e os procedimentos definidos.
•
Implementar as autorizações de acesso à biblioteca da GCS.
•
Implementar os mecanismos de acesso à biblioteca da GCS.
•
Armazenar itens existentes na biblioteca controlada.
Configurar mecanismos de suporte. Esta atividade consiste em configurar os mecanismos
ou ferramentas utilizadas no suporte ao processo, que podem incluir:
•
Ferramenta aplicada à estrutura e controle de acesso a biblioteca da GCS, utilizada
para o armazenamento, retenção e recuperação de itens de configuração e seus
metadados, bem como para o controle das versões destes itens.
•
Mecanismos de comunicação entre os envolvidos no processo, como listas de emails, agendas de reuniões, etc.
•
Ferramenta de geração de relatórios da configuração e das modificações.
•
Sistema para o acompanhamento das solicitações de modificação e respectiva base
de dados da modificação.
4.4.6
O Processo de Gerenciamento da Co nfiguração
O processo Gerenciamento da Configuração é formado pelos componentes de processo
fundamentais da GCS, ou seja, componentes básicos, que abrangem as atividades da GCS
162
que serão executadas durante a fase de desenvolvimento do projeto, e que foram
identificadas e descritas durante o processo de Implantação da GCS.
O processo Gerenciamento da Configuração é iniciado após o planejamento inicial da GCS,
quando os primeiros itens de configuração são produzidos, e abrange atividades de
identificação da configuração, do armazenamento e controle dos itens de configuração e do
relato da situação da configuração.
As atividades do gerenciamento da configuração são consideradas cíclicas para todos os
itens de configuração (Hass, 2002): o primeiro ciclo inicia-se com a necessidade de um
item de configuração, definida em plano, e os próximos ciclos são conseqüência de uma
solicitação de modificação.
Em cada ciclo o item é identificado, produzido, armazenado e liberado para uso. Relatórios
de ocorrências são emitidos com a experiência trazida pela utilização do item, levando ao
controle de modificação, que levará à identificação de uma nova versão do item original, e
assim por diante. Os itens colocados sob o gerenciamento da configuração não são
modificados, mas novas versões do mesmo são criadas, permitindo que se possa reverter a
uma situação anterior do item.
O gerenciamento da configuração interage com o processo de Controle da Qualidade
quando um produto de trabalho é encaminhado para armazenamento controlado, após
avaliação e aprovação. A aprovação da qualidade será dada após as atividades de
verificação e validação, ou ainda das auditorias físicas e funcionais, dependendo da
categoria do produto de trabalho.
4.4.6.1
À medida que o processo de desenvolvimento de software evolui, produtos de trabalho
começam a ser gerados. O objetivo deste processo é estabelecer e manter a integridade dos
163
produtos de trabalho de um processo ou projeto selecionados, e torná- los disponíveis às
partes interessadas, conforme o planejamento da GCS.
Para isto, todos os itens de configuração gerados pelo processo ou projeto devem ser
identificados e pertencer a uma configuração-base. As modificações e distribuições dos
itens devem ser controladas e disponibilizadas às partes interessadas. As situações dos itens
e das solicitações de modificação devem ser registradas e relatadas. A integridade e
consistência dos itens devem ser garantidas e o armazenamento, manuseio e entrega dos
itens devem ser controlados.
Todos os itens gerados pelo processo ou projeto são identificados, definidos e
pertencem a uma configuração-base. Isto envolve a identificação única de todos os itens
de configuração e a manutenção da descrição dos itens de configuração.
Modificações e liberações dos itens são controladas. Isto envolve o estabelecimento das
configurações-base internas e externas ou distribuições, a manutenção da descrição dos
itens de configuração e do histórico dos itens de configuração.
Modificações e distribuições são disponibilizadas para as partes interessadas. Para isto
é necessário que as descrições dos itens de configuração sejam mantidas, que as
modificações e liberações dos itens sejam controladas, o histórico do item de configuração
seja mantido e que o armazenamento dos itens de configuração seja gerenciado.
A situação dos itens e das solicitações de modificação é registrada e relatada. Isto
envolve o relato da situação da configuração e o gerenciamento do armazenamento e acesso
aos itens de configuração.
164
A integridade e consistência dos itens de configuração são garantidas. Isto envolve a
verificação da informação sobre os itens de configuração e o gerenciamento do
armazenamento e acesso aos itens de configuração.
O armazenamento, o acesso e a entrega dos itens de configuração são controlados.
Envolve o estabelecimento da biblioteca da GCS ou controlada, que contém os itens de
configuração e seus metadados, e no armazenamento físico desta no repositório, bem como
o controle de permissão de acesso e liberação dos itens de configuração.
Os requisitos básicos do processo de Gerenciamento da Configuração são atendidos pelos
pacotes de atividades que compõem o processo, que são representados através do diagrama
de pacotes da Figura 4.12.
Gerenciamento da
Configuração
Identificação da
configuração
Armazenamento e controle
dos itens de configuração
Relato da situação da
configuração
FIGURA 4.12 – O Processo Gerenciamento da Configuração.
165
Para representação deste processo é também utilizado o diagrama de caso de uso, que
mostra o relacionamento entre papéis e atividades do processo, agrupadas em Definições de
Trabalho (WorkDefinitions). O diagrama de atividades é ainda utilizado para representar
uma visão dinâmica de aspectos do processo.
Como requisitos para o processo tem-se um ambiente para a GCS preparado, com a
biblioteca da GCS criada, e disponíveis os mecanismos de criação, controle e acesso às
versões dos itens e manutenção dos registros de modificação da configuração, para o
histórico de modificação, assim como uma ferramenta para geração automatizada dos
relatórios da configuração e das modificações.
4.4.6.2
O Responsável pelo Produto, que representa aqui qualquer envolvido no projeto ou
processo responsável pela produção de um item de configuração, é quem identifica o item,
segundo critérios estabelecidos no PGCS, de acordo com a configuração do produto. Parte
da atividade de identificação é feita pela atribuição automática de um número de
identificação de versão quando o item é armazenado na biblioteca da GCS. O Responsável
pelo Produto registra os metadados do item de configuração, ao encaminhá- lo à Qualidade
para aprovação e posterior armazenamento na biblioteca controlada.
O Responsável pela GCS é quem mantém e controla a biblioteca da GCS e o seu conteúdo,
ou seja, realiza as operações de check-in e check-out dos itens de configuração aprovados
pela qualidade na biblioteca da GCS, registrando as informações sobre as modificações
feitas nos itens de configuração, para manutenção do histórico do item; cria e mantém
metadados das configurações-base, inclusive das de distribuição, mantendo o registro das
informações de modificação feitas nestas; libera itens das configurações-base para a
produção de acordo com o cronograma do projeto e cria as distribuições para utilização
externa baseado em solicitações de liberação. Cabe ao Responsável pela GCS comunicar a
situação da configuração e das modificações aos envolvidos no processo, extraindo as
166
informações para a produção dos relatórios de situação da configuração e das modificações,
e informações ad hoc, como medidas para outros processos. O Responsável pela GCS
também controla a integridade dos metadados da configuração, verificando se as
informações sobre os itens e suas estruturas fornecidas pelos relatórios de situação estão
completas, de acordo com a configuração do produto, e garantem a consistência dos itens.
Ainda que grande parte destas atividades seja suportada por ferramenta automatizada, a
supervisão destas é feita pelo Responsável pela GCS.
As Gerências de Projeto e da Qualidade, bem como o Cliente da GCS, que pode ser tanto
interno, como um desenvolvedor ou outro envolvido no projeto, quanto externo à
organização de desenvolvimento, são informados da situação da configuração, através de
relatórios específicos ou acesso à biblioteca da GCS e às configurações-base de
distribuição.
Os diagramas de classes das Figuras 4.13, 4.14, 4.15 e 4.16 mostram os relacionamentos
entre os papéis e os produtos associados ao processo de Gerenciamento da Configuração.
167
Configuração
do Produto
PGCS
Plano de
Distribuição
Sistema de
Acompanhamento
Orientação para Manuseio
e Armazenamento
Responsável
pela GCS
*
Histórico de
Modificação
1
Biblioteca da
GCS
1
1
*
Descrição do Item
de Configuração
*
Item de
Configuração
Configuração-base
de Distribuição
Relatórios Controle
das Modificações
Relatórios de Histórico
das Modificações
Relatórios de Estado
da Configuração
FIGURA 4.13 – O Responsável pela GCS e os Produtos do Processo de Gerenciamento da
Configuração.
168
Configuração
do Produto
e Armazenamento
*
1
Histórico de Modificação
1
Responsável
pelo Produto
1
Biblioteca da GCS
*
Descrição do Item
de Configuração
*
Relatórios de Estado
da Configuração
Item de
Configuração
FIGURA 4.14 – O Responsável pelo Produto e os Produtos do Processo de Gerenciamento
da Configuração.
169
Configuração
do produto
PGCS
e Armazenamento
Gerente da
Qualidade
*
1
Biblioteca
da GCS
1
1
*
Descrição do Item
de Configuração
*
Item de
Configuração
Relatórios de Estado da
Configuração
Gerente de
Projeto
Relatórios de Histórico das
Modificações
Relatórios de Controle das
Modificações
Configuração-base
de distribuição
FIGURA 4.15 – Os Gerentes da Qualidade e Projeto e os Produtos do Processo de
Gerenciamento da Configuração.
170
e Armazenamento
*
1
Cliente da
GCS
Biblioteca
da GCS
1
1
*
Descrição do Item
de Configuração
*
Item de
Configuração
Relatórios de Controle das
Modificações
Configuração-base
de distribuição
Relatórios de Estado da
Configuração
Relatórios de Histórico das
Modificações
FIGURA 4.16 – O Cliente da GCS e os Produtos do Processo de Gerenciamento da
Configuração.
4.4.6.3
O diagrama de pacote do processo de Gerenciamento da Configuração agrupa as atividades,
os papéis e os produtos de trabalho que possibilitam a execução do processo da GCS com
171
sucesso na organização. Estes pacotes compreendem as atividades básicas da GCS, que
consistem na identificação da configuração, no armazenamento e controle dos itens de
configuração e no relato da situação da configuração. Estas atividades são as mínimas
necessárias para, durante o desenvolvimento de um projeto de software, estabelecer e
manter a integridade dos produtos de trabalho gerados e torná-los disponíveis às partes
interessadas, conforme o planejado.
4.4.6.3.1
O Pacote Identificação da Configuração
O pacote Identificação da Configuração apresentado na Figura 4.17 agrupa as tarefas
ligadas à identificação de um item de configuração, que consiste em descrever um produto
de trabalho selecionado para estar sob o gerenciamento da configuração. A identificação do
item, ou parte dela, pode ser feita antes mesmo do item ter sido produzido, quando foi
tomada a decisão de produzi- lo.
Um item identificado não está sob o gerenciamento da configuração até que seja colocado
em armazenamento controlado na biblioteca da GCS. Assim, a identificação de um item é
uma atividade que se sobrepõe a outras atividades, como a produção do item, que está fora
do escopo do processo da GCS, e seu armazenamento controlado, quando, por exemplo, um
contador de número de versão automático é incrementado. Quem encaminha o item para a
Qualidade e posterior armazenamento controlado fica responsável pela sua identificação
única, que deve ser baseada nos critérios e convenções definidos no PGCS.
A primeira vez que o item é encaminhado à GCS, a identificação se inicia com uma
necessidade definida em planos. Do Plano de Projeto, obtém-se a informação que o item
deve ser produzido e do Plano de GCS, sabe-se que ele deve ser colocado sob
gerenciamento da configuração. Quando o item precisa ser modificado, a identificação
começa com a solicitação de modificação. Neste caso, no processo de gerenciamento das
solicitações de modificação foi decidido que uma nova versão de um item de configuração
172
deveria ser criada, e, conseqüentemente, esta nova versão deve ser colocada sob controle da
GCS.
O processo de identificação de um item de configuração engloba também a identificação de
configurações-base de projeto e distribuições. Quando se atinge o ma rco estabelecido para
a criação de uma configuração-base uma identificação única é atribuída ao conjunto de
itens que a constituem, nas versões correntes.
Identificação da Configuração
Responsável pelo Produto
Descrever item de configuração ( )
Item de
Configuração PGCS
Biblioteca
da GCS
Plano de
Distribuição
Orientação para
manuseio e
armazenamento
Responsável pela GCS
Estabelecer as configurações-base ( )
FIGURA 4.17 – O Pacote de Identificação da Configuração.
A identificação resulta no registro da descrição de um item de configuração na biblioteca da
GCS. Esta descrição consiste de informações sobre o item coletadas e mantidas durante
toda a sua existência. Estas informações ou metadados do item são compostas de elementos
173
de dados que podem ser divididos em quatro grupos (Hass, 2002): identificação única,
autorização, relacionamentos com outros itens de configuração e distribuição.
A identificação da configuração consiste em:
Descrever o item de configuração. A descrição de um item de configuração deve ser feita,
de acordo com as convenções estabelecidas no PGCS, quando o item é encaminhado para
controle e durante todo o processo da GCS. O esquema de identificação deve incluir:
•
Identificação do item de configuração. Constitui-se nos metadados de
identificação única do item de configuração
•
Autorização para o item de configuração. Informações de autorização associadas
ao item de configuração, registradas em momentos distintos, como no
encaminhamento do item à Qualidade e aprovação do item pela Qualidade.
•
Relacionamentos entre o item de configuração e outros. Metadados que
relacionam outros itens de configuração que estão associados ao item de
configuração descrito.
•
Distribuição do item de configuração. Esta informação sobre a distribuição de um
item deve ser registrada quando uma configuração-base de distribuição for liberada
para um cliente externo à organização de desenvolvimento.
Estabelecer as configurações-base. Esta atividade, realizada pelo Responsável pela GCS
quando o marco de projeto definido para a criação de uma configuração-base é atingido, ou
quando uma modificação deve ser incorporada à configuração-base atual, registrando a
versão e o estado de cada item de configuração, consiste em:
•
Selecionar os itens que fazem parte da nova configuração-base.
174
•
Atribuir um nome e um número de versão à configuração-base, conforme
convenções estabelecidas.
•
Registrar metadados da configuração-base.
4.4.6.3.2
O Pacote Armazenamento e Controle dos Itens de Configuração
Este processo envolve as atividades necessárias para garantir que o armazenamento dos
itens de configuração seja feito convenientemente, de maneira que não sejam perdidos ou
danificados, mas possam ser recuperados a qualquer momento, na condição esperada e que
o acesso e as modificações feitas neles sejam controlados. Para isto, registros de descrição e
histórico de modificações dos itens devem ser mantidos.
O armazenamento envolve o meio físico onde os itens de configuração são armazenados,
que é o repositório. Logicamente, os itens estão organizados em uma biblioteca, que reflete
as estruturas de diretório definidas no planejamento, de acordo com o projeto de arquitetura
do produto que está sendo desenvolvido. Juntamente com os itens de configuração são
armazenadas as informações sobre os itens, ou metadados. Os itens de configuração e seus
metadados, que constituem sua descrição, bem como os registros de histórico, formam a
base de dados da GCS, ou biblioteca da GCS.
Ainda que bibliotecas dinâmicas ou de desenvolvimento possam ser criadas no mesmo
repositório global de produtos de trabalho onde está a biblioteca da GCS, para serem
utilizadas pelos processos de engenharia, nesta abordagem considera-se que estas
bibliotecas estão fora do controle da GCS.
Um produto de trabalho, quando finalizado pelo seu responsável é encaminhado para
avaliação pela Qualidade, passando para o estado Encaminhado. O critério de aprovação é
definido pela Qualidade em plano, para cada categoria de item e é verificado nos marcos
específicos de projeto. Estes marcos de projeto indicam o estabelecimento de uma
175
configuração-base e todos os itens encaminhados à Qualidade que pertencem a esta
configuração-base e foram aprovados recebem então o estado de Controlado. Itens com o
estado Controlado pertencem à biblioteca controlada e será possível modificá- los apenas
através do processo de gerenciamento das modificações.
O processo de armazenamento e controle dos itens de configuração é responsável, portanto,
pelo gerenciamento da evolução das configurações-base, que se dá pela criação de novos
itens de configuração e pela modificação dos itens existentes, como também pela liberação
de itens de configuração, tanto para a produção de novos itens, como para a sua utilização.
A configuração atual de um produto é dada sempre pelas últimas versões aprovadas dos
itens de configuração, que compõem uma configuração-base. Nas operações de check-out,
utilizadas nas atividades desta Definição de Trabalho, está implícita a obtenção da última
versão do item solicitado. Quando se deseja obter uma versão anterior, deve-se explicitar o
número de versão na operação.
Este processo é composto por grupos de atividades ou Definições de Trabalho
(WorkDefinitions), apresentadas no diagrama de caso de uso da Figura 4.18.
176
Armazenar item de
configuração para
produção
Armazenamento
e controle dos
itens de
configuração
Liberar item de
configuração
para produção
Liberar item de
configuração
para utilização
FIGURA 4.18 – A Definição de Trabalho do Armazenamento e Controle dos Itens de
Configuração.
4.4.6.3.2.1
A Definição de Trabalho Armazenar Item de Configuração para Produção
Esta Definição de Trabalho consiste no armazenamento de um novo item de configuração e
dos metadados associados na biblioteca da GCS, bem como do registro de informações de
modificações, através de mecanismos apropriados (permissões de acesso, check-in, registro
de histórico), após a identificação e aprovação do item de configuração pela Qualidade. O
histórico do item deve ser mantido através do registro das informações sobre as
modificações feitas nos itens, quando uma nova versão do mesmo for criada. Como
resultado, tem-se o item acessível apenas através da biblioteca controlada e com seus
metadados atualizados apropriadamente. Deve-se assegurar a correta atualização das
177
versões dos itens e da configuração-base associada, no caso dos itens modificados. Os
envolvidos no desenvolvimento devem ser notificados, através do processo de relato da
situação, de que novos itens foram armazenados na biblioteca da GCS.
A Figura 4.19 apresenta o diagrama de atividades desta Definição de Trabalho, incluindo a
atividade de Descrever Item de Configuração, do pacote de Identificação da Configuração.
As atividades que estão fora do escopo do processo aparecem nos diagramas na cor cinza.
Esta Definição de Trabalho consiste das atividades:
•
Manter histórico do item, atualizando o registro de histórico do item com os
metadados pertinentes.
•
Colocar o item de configuração aprovado pela Qualidade na biblioteca da GCS
(controlada), através do procedimento de check-in:
o Atribuir um número de versão ou atualizar o número de versão, no caso de
um item modificado.
o Atualizar o estado do item para Controlado.
o Comunicar a inclusão do novo item a todos os clientes da GCS ou a
modificação aos que obtiveram cópia do mesmo na biblioteca da GCS.
178
Responsável
pelo produto
Responsável
pela Qualidade
Responsável
pela GCS
Não Aprovado
Desenvolver
produto
Encaminhar
produto
Descrever item de
configuração
Avaliar item de
configuração
Item de configuração
{Encaminhado}
Aprovado
Item de
configuração
{Encaminhado}
Manter histórico do
item de configuração
Check-In
{Controlado}
FIGURA 4.19 – Diagrama de atividades da Definição de Trabalho de Armazenar Item de
Configuração para Produção.
179
4.4.6.3.2.2
A Definição de Trabalho Liberar Item de Configuração para Produção
O evento que inicia a liberação de um item de configuração para a produção é a
necessidade da produção de um novo item baseado em um já existente. Esta necessidade é
expressa através de uma solicitação de modificação, quando esta é encaminhada para
implementação, e o controle da liberação do item é feito através dos mecanismos
apropriados (check-out), pelo Responsável pela GCS.
Como resultado, tem-se a liberação de uma cópia de um item de configuração armazenado
na biblioteca da GCS para uma área de trabalho, onde será modificado, e o registro de
quem e quando recebeu a cópia do item.
A Figura 4.20 apresenta o diagrama de atividades para a liberação de um item de
configuração para produção. As atividades que estão fora do escopo do processo aparecem
no diagrama na cor cinza.
Esta Definição de Trabalho consiste das atividades:
•
Manter histórico do item, atualizando o registro de histórico do item com os
metadados pertinentes.
•
Retirar o item de configuração a ser modificado referenciado na solicitação de
modificação, da biblioteca da GCS para a área de trabalho do responsável pelo
produto, através do procedimento de check-out:
o Atualizar o estado do item de configuração para Sob Modificação.
180
Responsável
pelo Produto
Responsável pela
GCS
Solicitação de
Modificação
{Encaminhada para
implementação}
Manter histórico do
item de configuração
Check-out
Desenvolver
produto
{Sob Modificação}
FIGURA 4.20 - Diagrama de Atividades da Definição de Trabalho de Liberar Item de
Configuração para Produção.
4.4.6.3.2.3
A Definição de Trabalho Liberar Item de Configuração para Utilização
A liberação de um item de configuração para utilização consiste em retirar um item único
ou uma configuração-base da biblioteca controlada para uma biblioteca estática. Deve-se
garantir que as liberações dos itens foram permitidas e documentar quando ocorreram.
Esta Definição de Trabalho pode ser visualizada no diagrama da Figura 4.21.
181
Liberar item de
configuração para
utilização interna
Liberar item de
configuração para
utilização
Liberar item de
configuração para
utilização externa
FIGURA 4.21 – A Definição de Trabalho Liberar Item de Configuração para Utilização.
Dentro da organização de desenvolvimento, a liberação é feita através da operação get, por
qualquer envolvido no projeto que tenha permissão para tal, identificado no diagrama como
Cliente da GCS, com registro de histórico do item. A Figura 4.22 apresenta o diagrama de
atividades para a liberação de item de configuração para utilização interna. A atividade que
está fora do escopo do processo aparece no diagrama na cor cinza.
As atividades desta Definição de Trabalho são:
•
Obter cópia do item de configuração desejado através da operação get.
•
Registrar informações de histórico do item: quem retirou, por que e quando.
182
Cliente
da GCS
Get
Registrar
histórico do item
Cópia do Item de
configuração
Utilização do item
Configuração para Utilização Interna.
Para a liberação de uma configuração-base de distribuição, que será utilizada fora da
organização de desenvolvimento, é necessário o registro de uma solicitação de liberação
pelo Responsável pela GCS. Neste caso, o Responsável pela GCS libera a configuraçãobase para utilização pelo cliente, conforme especificado no Plano de Distribuição.
A Figura 4.23 apresenta o diagrama de atividades para a liberação de item de configuração
para utilização externa. A atividade que está fora do escopo do processo aparece no
diagrama na cor cinza.
183
Cliente da
GCS
Responsável pela
Configuração
Solicitação de
Liberação
Plano de
Distribuição
Analisar solicitação
de liberação
Get
Registrar
liberação do item
Utilização do
item
Configuração-base de
distribuição
Configuração para Utilização Externa.
As seguintes informações devem constar da solicitação:
•
Identificação da configuração-base.
•
Solicitante.
184
•
Localização de destino.
•
Data da solicitação.
•
Data da liberação.
•
Responsável pela liberação.
•
Motivo.
4.4.6.3.3
O Pacote Relato da Situação da Configuração
O pacote Relato da Situação da Configuração, Figura 4.24, consiste nas atividades de
relatar a situação das modificações feitas nos itens de configuração do projeto e verificar se
as informações sobre os itens e suas estruturas fornecidas pelos relatórios de situação da
configuração estão completas e garantem a consistência dos itens.
O relato da situação torna disponível, de maneira útil e compreensível, a informação
necessária para um gerenciamento efetivo do desenvolvimento e manutenção de um
produto de software.
O relato da situação utiliza informações fornecidas por outras áreas de atividade da GCS,
na forma de metadados e informações sobre as modificações. Para isto é mantido, para cada
item de configuração, um conjunto organizado de registros de gerenciamento de
configuração: os registros de descrição do item e os de histórico das modificações. Além
destes registros, têm-se ainda as solicitações de modificação geradas como fonte para os
relatórios de situação das modificações. O relato da situação extrai, arranja e formata estes
dados de acordo com a demanda por eles.
Como resultado deste processo têm-se os relatórios periódicos de estado baseados nas
configurações-base de projeto, nas distribuições e nas modificações. Relatórios ad hoc
185
também podem ser extraídos, a qualquer tempo, conforme a necessidade pelo Responsável
pela GCS e usuários ou Clientes da GCS, como Gerentes, Responsável pela Qualidade e
outros que sejam autorizados.
Relato da Situação da Configuração
Responsável pela GCS
Gerar relatórios da situação da configuração ( )
Gerar relatórios de histórico das modificações ( )
Gerar relatórios de controle das modificações ( )
Verificar informações sobre os itens de
configuração ( )
PGCS
Biblioteca da
GCS
Orientação para
manuseio e
armazenamento
Relatórios de histórico
das modificações
Relatórios da situação
da configuração
Relatórios de controle
das modificações
Cliente da GCS
Obter relatórios da situação da configuração ad hoc ( )
FIGURA 4.24 – O Pacote Relato da Situação da Configuração.
186
Gerar Relatórios da situação da configuração. O Responsável pela GCS deve submeter
os Relatórios da Situação da GCS periodicamente ao Gerente de Projeto e da Qualidade,
conforme definido no PGCS, se quaisquer modificações foram feitas a qualquer item de
configuração desde o último relatório. Estes relatórios de situação podem conter:
•
Lista com as últimas versões dos itens de configuração, identificadores de
distribuição.
•
Número de distribuições, e comparações entre as distribuições.
•
Uma lista completa dos itens de configuração da configuração-base atual e números
de revisão/versão associados.
•
Registros de progresso do desenvolvimento do ciclo de vida indicando o estado de
cada item de configuração.
•
Data da liberação/distribuição do item de configuração.
Gerar relatórios de histórico das modificações. Relatórios de histórico das modificações
fornecem as seguintes informações sobre as modificações nos itens de configuração:
•
Um sumário das mais recentes modificações a cada item de configuração, desde o
último relatório, contendo a data, descrição das modificações, autor da modificação
e SM associada. Estes relatórios podem ser emitidos automaticamente após as
operações de check-in na biblioteca da GCS, comunicando a todos os envolvidos
que novos itens encontram-se à disposição na biblioteca.
Verificar informações sobre os itens de configuração. Os relatórios de situação da GCS
devem ser verificados pelo Responsável pela GCS para detectar possíveis inconsistências
entre a situação relatada e a real, mesmo quando a geração dos relatórios for automatizada.
Esta atividade consiste de:
187
•
Verificar se os registros foram feitos de maneira incorreta.
•
Verificar se as informações fornecidas estão incompletas.
Obter relatórios da situação da configuração ad hoc. Esta atividade é realizada por um
cliente da GCS que tenha autorização de acesso à base de dados da GCS e das solicitações
de modificação, que necessite de informações sobre a configuração ou sobre as
modificações. Consiste em:
•
Acessar a biblioteca da GCS, através da aplicação disponível.
•
Selecionar e obter o tipo de relatório desejado.
4.4.7
O Processo Gerenciamento das Solicitações de Modificação
O processo de Gerenciamento das Solicitações de Modificação é composto pelas atividades
fundamentais do controle das modificações, identificadas e descritas durante o processo de
implantação da GCS, que serão executadas nos projetos.
A necessidade de uma modificação surge devido a um evento verificado durante a
utilização do produto, que pode ser uma mudança nos requisitos, a introdução de novas
funcionalidades ou melhoria, a correção de erros ou evolução do ambiente operacional.
Este evento, registrado em um Relatório de Ocorrência, originado do processo Solucionar
Problemas, é a entrada para o processo de Gerenciamento das Solicitações de Modificação.
Um Relatório de Ocorrência é encaminhado ao Responsável pela GCS quando a ocorrência
relatada envolver uma modificação em um ou mais itens de configuração de software. Uma
solicitação de modificação (SM) é então registrada, para cada item de configuração a ser
modificado.
As solicitações de modificação têm um ciclo de vida que deve ser suportado pela GCS.
Estas solicitações, fechadas ao final do processo, devem ser mantidas na base de dados das
188
solicitações de modificação, de modo a que os relacionamentos entre as solicitações de
modificações e os itens de configuração afetados sejam mantidos.
O processo de Gerenciamento das Solicitações de Modificação é iniciado após a primeira
configuração-base ser estabelecida.
4.4.7.1
Objetivos e requisitos básicos do processo
O objetivo deste processo é garantir que as solicitações de modificação sejam gerenciadas,
acompanhadas e controladas, possibilitando a identificação das modificações feitas em
qualquer versão de um item de configuração, em relação à anterior.
Para isto, todas as solicitações de modificação nos itens de configuração devem ser
registradas, bem como o estado de cada uma delas. A relação de uma solicitação de
modificação com o Relatório de Ocorrência que a originou deve ser mantida, bem como
relacionamentos com outras solicitações de modificação e a configuração-base à qual a
modificação se refere. O ciclo de vida da solicitação de modificação deve ser
acompanhado, bem como as atividades do Grupo de Controle de Modificações (GCC).
Os principais requisitos para este processo são:
As solicitações de modificação devem ser registradas e identificadas. Uma identificação
única deve ser atribuída à solicitação de modificação e esta deve ser registrada e
armazenada apropriadamente.
Dependências e relacionamentos com outras solicitações de modificação são definidos.
Os relacionamentos entre a solicitação de modificação e o Relatório de Ocorrência que a
originou e outras solicitações de modificação, devem ser estabelecidos e mantidos.
As solicitações de modificação são priorizadas, os recursos necessários são estimados e
critérios para confirmação da implementação das solicitações de modificação são
189
definidos. Isto envolve a avaliação do impacto das modificações, dos recursos necessários
para sua implementação, dos benefícios resultantes desta implementação e também um
cronograma para execução da modificação.
As modificações são aprovadas com base na prioridade e disponibilidade de recursos.
Todas as modificações devem ser aprovadas antes da implementação, de acordo com o
resultado da avaliação de impacto, que leva em conta a prioridade e os recursos disponíveis
para a implementação.
As modificações aprovadas são implementadas e acompanhadas até seu fechamento.
As atividades de verificação e validação a serem executadas para as modificações
implementadas devem ser identificadas, o cronograma para a modificação deve ser seguido
e as modificações, após a implementação, devem ser revistas.
O estado de todas as solicitações de modificação é conhecido. Todas as modificações
devem ser revistas após a implementação e antes do fechamento da solicitação de
modificação.
Um processo efetivo para o gerenciamento de solicitações de modificação requer algum
tipo de ferramenta ou procedimento de suporte. Uma ferramenta automatizada para a
geração das solicitações de modificação (Sistema de Acompanhamento), que faça cumprir
o fluxo do processo de modificação, registrando as decisões do GCC e as demais
informações do processo de modificação pode ser utilizada.
Os requisitos básicos do processo de Gerenciamento das Solicitações de Modificação são
atendidos pelas atividades representadas através do diagrama de caso de uso da Figura 4.25.
As atividades que estão fora do escopo do processo da GCS aparecem no diagrama na cor
cinza. Diagramas de atividades são também utilizados para representar a visão dinâmica do
processo.
190
<<perform>>
Responsável
pela Qualidade
<<perform>>
Identificar atividades de
verificação/validação
Avaliar produto
de trabalho
Identificar e
registrar SM
<<perform>>
Responsável
pela GCS
<<perform>>
<<perform>>
Relatar situação
das modificações
Avaliar impacto da
modificação
<<perform>>
Presidente
do GCC
<<perform>>
Agendar
modificação
<<assist>>
<<assist>>
Membro
do GCC
Responsável
pelo produto
<<assist>>
Revisar modificação
implementada
<<perform>>
<<perform>>
Desenvolver
produto
Aprovar
modificação
FIGURA 4.25 – O Processo de Gerenciamento das Solicitações de Modificação.
4.4.7.2
O Responsável pela GCS recebe o Relatório de Ocorrência, com as modificações propostas
e registra uma Solicitação de Modificação (SM) para cada item de configuração a ser
modificado, encaminhando-as ao Presidente do Grupo de Controle de Configuração (GCC).
A formação do GCC é definida no planejamento de acordo com o tipo de controle desejado
191
para o projeto e fase de desenvolvimento. De acordo com a demanda das solicitações, o
GCC reúne-se para deliberar sobre as modificações propostas. Cabe ao Presidente do GCC
a condução e registro das atividades do grupo e a decisão final pela aprovação ou não da
modificação. Este deve ter, portanto, a autoridade necessária para aprovar a modificação na
configuração-base. As reuniões podem ser formais, onde os membros do GCC se reúnem
fisicamente para as deliberações ou informais, através da comunicação por meio eletrônico,
de acordo com o tipo de item ou fase de desenvolvimento, definidos no PGCS.
Após aprovação da modificação para implementação, o GCC agenda a modificação e
encaminha a SM ao Responsável pelo Produto para implementar a modificação, dentro de
um prazo estabelecido. A atividade de Liberar Item de Configuração para Produção é
realizada, para que cópias de trabalho dos itens de configuração sejam liberadas para o
Responsável pelo Produto, que as utiliza para preparar as novas versões dos itens. Após
implementar a modificação, atividade identificada neste processo como Desenvolver
Produto, o Responsável pelo Produto registra na SM a modificação realizada e a encaminha
à Qualidade, juntamente com o item de configuração modificado. A atividade de Avaliar
Produto de Trabalho é realizada pela Qualidade, para que se proceda às atividades de
verificação/validação no item modificado, conforme identificadas anteriormente no
planejamento da qualidade. A aprovação do item modificado é registrada na SM pela
Qualidade, ao final dessas atividades. A modificação tem sua implementação verificada
pelo GCC, a SM tem seu estado atualizado para Fechada, e é, então, armazenada. A
atividade de Armazenar Item de Configuração para Produção é realizada, de maneira que o
item modificado seja incorporado à biblioteca da GCS.
Se a modificação não for aprovada, o Presidente do GCC registra na SM os motivos da
rejeição, a SM tem o estado atualizado para Rejeitada e é armazenada.
Através do estado da SM, o processo Solucionar Ocorrências é informado do fechamento
ou rejeição das SMs relacionadas a uma ocorrência, para que o Relatório de Ocorrência que
192
originou as SMs seja também fechado ou, no caso de rejeição, sejam tomadas as medidas
necessárias.
Durante todo o processo, o estado de progresso da atividade é obtido através do estado da
SM que é registrado, podendo ser verificado a qualquer tempo. Relatórios de controle das
modificações são gerados para que a situação das modificações seja divulgada aos
envolvidos no processo, quando necessário.
Os diagramas de classes das Figuras 4.26 e 4.27 mostram os relacionamentos entre os
papéis e os produtos associados ao processo de Gerenciamento das Solicitações de
Modificação.
193
Item de
Configuração
Relatório de Controle
de Modificações
Solicitação de
Modificação
Relatório de
ocorrência
Responsável
pela GCS
PGCS
Histórico de
Modificação
Registro de estado de
progresso
Sistema de
Acompanhamento
FIGURA 4.26– O Responsável pela GCS e os Produtos do Processo de Gerenciamento das
194
Item de
Configuração
Configuração
do Produto Relatório de Controle
de Modificações
Solicitação de
Modificação
Check-list de Avaliação
de Impacto da
Modificação
Relatório de
ocorrência
Presidente
do GCC
PGCS
Histórico de
Modificação
Registro de estado de
Produto de
progresso
trabalho
Sistema de
Acompanhamento
FIGURA 4.27 – O Presidente do GCC e os Produtos do Processo de Gerenciamento das
4.4.7.3
Os diagramas de atividades do processo de Gerenciamento das Solicitações de
Modificação, Figuras 4.28 e 4.29, mostram o fluxo das atividades e os estados das
solicitações de modificação durante a execução do processo de controle das solicitações de
195
modificação. Estes diagramas compreendem as atividades básicas do gerenciamento das
solicitações de modificação, que consistem no registro da solicitação e no acompanhamento
desta solicitação por todo seu ciclo de vida.
As atividades do GCC são realizadas durante reuniões onde os seus membros, liderados
pelo Presidente do GCC, deliberam sobre a avaliação do impacto, a aprovação, o
agendamento e a verificação das modificações. Estas reuniões devem ocorrer
periodicamente, quando um certo número de SMs forem acumuladas, ou excepcionalmente,
quando o Presidente do GCC julgar necessário, de acordo com o tipo de modificação
solicitada ou fase do desenvolvimento do projeto. A comunicação da reunião para os
membros do GCC deve ser feita de maneira automatizada, atravé s de um mecanismo de
comunicação ou de agenda disponíveis. As atividades e deliberações do GCC podem ser
realizadas em reuniões onde os membros do GCC encontram-se fisicamente ou através de
um serviço de mensagens eletrônicas. Estas deliberações podem ocorrer em uma só reunião
ou várias, dependendo da quantidade de SMs tratadas.
4.4.7.3.1
Atividade Identificar e Registrar a Solicitação de Modificação
Esta atividade é realizada pelo Responsável pela GCS e inicia-se com o recebimento de um
Relatório de Ocorrência. Esse relatório deve conter uma proposta de solução para uma
ocorrência levantada que envolve a modificação de um ou mais itens de configuração. Para
cada item de configuração a ser modificado deve ser identificada e registrada uma
Solicitação de Modificação. Esta atividade consiste em:
•
Abrir uma nova SM para cada item de configuração que deve ser modificado,
identificando-a unicamente, conforme planejado.
•
Registrar informações de abertura da SM: a identificação do Relatório de
Ocorrência que originou a SM, identificação do projeto, identificação de
módulo/subsistema a que pertence o item, identificação do item de configuração,
196
tipo da modificação (corretiva, evolutiva, adaptativa e preventiva), sugestão de
solução, data da abertura.
Responsável
pela GCS
Relatório de
Ocorrência
Identificar e
Registrar a
SM
Presidente
GCC
SM
{Aberta}
Check-list para
avaliação de
impacto
Avaliar impacto
da modificação
SM
{Sob Avaliação}
Aprovar
modificação
rejeitada
aprovada
SM
{Rejeitada}
SM
{Aprovada para
Implementação}
FIGURA 4.28 – Diagrama de Atividades do Processo de Gerência das Solicitações de
Modificação – Avaliação e Aprovação de uma SM.
197
•
Registrar o estado da SM (Aberta). Esta informação será atualizada ao longo do
processo, de acordo com o andamento do mesmo.
•
Encaminhar a(s) SM(s) ao Presidente do GCC, para ser avaliada.
4.4.7.3.2
Atividade Avaliar Impacto da Modificação
A avaliação do impacto da modificação consiste em:
•
Atualizar o estado da(s) SM(s) para Sob Avaliação.
•
Realizar a avaliação, seguindo os critérios do check-list de avaliação de impacto da
modificação, que deve incluir:
o Verificação de requisitos afetados ou em conflito com a modificação,
possíveis efeitos adversos da implementação da modificação e efeitos nos
requisitos não funcionais.
o Avaliação dos recursos necessários para desenvolvimento da modificação
proposta, como custos, pessoas e tempo.
o Avaliação dos benefícios da modificação proposta e as conseqüências de não
realizá-la.
•
Atribuir uma prioridade à(s) SM(s), indicando a urgência da realização da
modificação.
•
Atribuir um grau de impacto da modificação. Por exemplo, uma modificação pode
ser de pequeno, médio ou grande impacto, dependendo da quantidade de recursos e
esforços necessários.
198
4.4.7.3.3
Atividade Identificar Atividades de Verificação/Validação
Esta atividade consiste na identificação do escopo das atividades de verificação e validação
a serem realizadas. Isto deve ser feito antes da modificação ser implementada, para que
sejam estimados os esforços e recursos para os testes necessários e para que as condições
de contorno sejam previstas. Esta atividade é realizada pela Qualidade, durante o
planejamento, para cada tipo de produto de trabalho.
4.4.7.3.4
Atividade Aprovar Modificação
A aprovação da modificação é de responsabilidade do Presidente do GCC, que toma esta
decisão com base na prioridade estabelecida para a modificação e na disponibilidade dos
recursos necessários.
A aprovação da modificação consiste em:
•
Verificar a disponibilidade dos recursos avaliados para as SMs existentes.
•
Aprovar ou reprovar a implementação da modificação, seguindo a ordem de
prioridade.
4.4.7.3.5
Atividade Agendar Modificação
Esta atividade realizada pelo GCC consiste em:
•
Verificar se os custos estimados estão dentro do orçamento geral e os recursos,
disponíveis. Para isto, informações de planejamento do projeto precisam ser
consultadas. Em caso negativo, a modificação deve ser adiada, sendo este estado
devidamente registrado na SM.
199
Responsável
pela Qualidade
Presidente do
GCC
Responsável
pelo produto
SM
{Aprovada para
Implementação}
Agendar
modificação
adiada
SM
{Encaminhada para
implementação}
Avaliar produto
de trabalho
SM
{Verificada}
Desenvolver
produto
SM
{Implementada}
Revisar modificação
implementada
SM
{Fechada}
FIGURA 4.29 - Diagrama de Atividades do Processo de Gerência das Solicitações de
Modificação - Encaminhamento para Implantação e Fechamento de SM.
•
Decidir em qual configuração-base a modificação será incorporada: na atual ou na
próxima a ser estabelecida.
•
Definir uma data para implementação da modificação e atribuí- la ao Responsável
pelo Produto ou desenvolvedor designado para implementá-la.
200
4.4.7.3.6
Atividade Desenvolver Produto
Esta atividade é realizada pelo Responsável pelo Produto ou outro desenvolvedor
designado pelo Gerente de Projeto, na condição de membro do GCC, conforme a
disponibilidade de recursos, e consiste na implementação das modificações indicadas na
SM. Esta atividade não está no escopo da GCS, mas sim no do desenvolvimento. Após o
término da implementação, o Responsável pelo Produto deve registrar na SM as seguintes
informações:
•
A descrição da implementação.
•
O esforço real despendido na implementação (horas trabalhadas).
•
A data de encaminhamento do produto para avaliação.
4.4.7.3.7
Atividade Avaliar Produto de Trabalho
Esta atividade é realizada pelo processo de Controle da Qualidade e também está fora do
escopo da GCS.
Ao final da atividade, deve-se registrar na SM:
•
O responsável pela avaliação do item modificado.
•
A data da avaliação.
•
O parecer do responsável pela avaliação.
4.4.7.3.8
Atividade Revisar Modificação Implementada
A atividade de revisão da modificação, feita pelo GCC após sua implementação, consiste
em verificar se as modificações tiveram o efeito desejado e alcançaram os objetivos
201
definidos. Caso as modificações não tenham alcançado os objetivos e efeitos desejados, o
GCC deve registrar uma nova ocorrência e submetê- la ao Solucionador de Ocorrência.
Ao final da atividade, deve-se registrar na SM:
•
O responsável pela revisão.
•
A data da revisão.
•
O parecer do responsável pela revisão.
4.4.7.3.9
Atividade Relatar Situação das Modificações
Esta atividade consiste na geração dos Relatórios de Controle das Modificações, e é
realizada pelo Responsável pela GCS, periodicamente, para relatar a situação das
modificações já realizadas e das que estão em andamento. Estes relatórios contêm
informações sobre as Solicitações de Modificação (SM) do tipo:
•
Relação dos relatórios de ocorrência e solicitações de modificação associadas.
•
O número de modificações de um projeto.
•
Quantas SMs foram: abertas, agendadas, fechadas.
•
Relação de SMs por prioridades.
•
Quantas SMs foram atribuídas a cada desenvolvedor.
•
Quantas SMs ainda não foram fechadas.
•
Em quanto tempo as SM são fechadas.
•
Quantas SMs são abertas por dia, semana, mês; quantas são fechadas.
202
CAPÍTULO 5
O SUPORTE AUTOMATIZADO AO PROCESSO DA GERÊNCIA DAS
MODIFICAÇÕES E DA CONFIGURAÇÃO
Segundo (Dart, 1992) uma solução de gerenciamento da configuração de software para
uma organização ou projeto envolve planejamento, definição de um processo,
negociação com pessoas, suporte automatizado e decisões gerenciais.
Estes aspectos podem ser contemplados quando a GCS se insere em um Ambiente
Integrado utilizado para gestão e desenvolvimento de projetos de software. O
planejamento da GCS consiste na escolha das estratégias apropriadas da GCS para a
organização como um todo, bem como a adequação destas a um projeto em particular,
que resulta na criação do Plano da GCS do projeto. O suporte adequado à definição e
estabelecimento do processo é efetuado com a ajuda do Ambiente através de atividades
automatizadas, de serviços e ferramentas; a negociação com pessoas é facilitada pelos
mecanismos de comunicação do Ambiente e da clara definição de papéis. Tomadas de
decisões gerenciais são facilitadas com a base de conhecimento do Ambiente, que
captura as informações da GCS e as fornece em forma de relatórios fixos ou consultas
ad hoc.
A modelagem do processo da GCS, apresentada no Capítulo 4, foi fundamental para a
sua compreensão, possibilitando a identificação de ferramentas e atividades que podem
ser automatizadas para fornecer, no conjunto, uma solução de GCS. Esta solução deve
levar em conta um número mínimo de funcionalidades, dentro do escopo das práticas
básicas do modelo do padrão ISO/IEC 15504.
Neste Capítulo, um protótipo de aplicação denominado Change and Configuration
Management
é
apresentado
para
ilustrar
algumas
destas
funcionalidades
e
possibilidades de automação de partes do processo, como o gerenciamento das
solicitações de modificação. Os recursos necessários para a implementação do processo
da GCS no Ambiente são também apresentados.
203
Inicialmente são feitas algumas considerações sobre as funcionalidades para a GCS no
Ambiente Integrado.
5.1
Os Requisitos para a GCS no Ambiente Integrado
Segundo Van Brunt (Van Brunt, 1996) a implantação da GCS em uma organização deve
ser incremental. A integração de funcionalidades ao longo do tempo pode ser uma
solução mais demorada, mas mais vantajosa sob o aspecto de choque cultural. Assim,
procurou-se nesta abordagem do processo da GCS contemplar inicialmente as seguintes
funcionalidades:
•
O gerenciamento do processo.
•
O desenvolvimento de software baseado em configurações-base.
•
O suporte ao ciclo de vida do item de configuração.
•
Suporte ao controle de versões:
o Biblioteca da GCS, contendo os itens de configuração e seus metadados,
e base de dados das Solicitações de Modificação.
o Políticas de check-in/checkout e composição.
•
Política de liberação.
•
Suporte ao ciclo de vida de uma solicitação de modificação.
•
Integração com o processo de Garantia do Produto.
5.1.1
Gerenciamento do Processo da GCS
O gerenciamento do processo da GCS no Ambiente deve ser definido em termos de
marcos, regras e responsabilidades durante o processo de desenvolvimento de software
de maneira a garantir que as modificações introduzidas no software sejam
204
cuidadosamente conduzidas através deste ciclo de vida com o nível de qualidade mais
alto possível.
Uma organização usuária do Ambiente deve ter a capacidade de adequar a GCS ao seu
estilo de desenvolver software. Isto requer funções de controle de processo que
permitam:
•
Atribuição de permissões aos usuários do Ambiente, vinculadas aos papéis que
desempenham, para controlar o acesso aos itens de configuração.
•
Possibilidade de definir fases dos processos e as transições entre elas – através
dos estados dos itens de configuração e das solicitações de modificação.
•
Definir uma maneira controlada de desenvolvimento com responsabilidades
claras e alto nível de visibilidade. A existência de marcos da GCS coincidentes
com os do ciclo de vida do projeto de software, garante que os itens de
configuração passarão pelos estágios desejados (produção, verificação pelo
controle da qualidade, estabelecimento de configurações-base e controle das
modificações), antes que o produto seja distribuído.
•
Graduar os níveis de autoridade para aprovação das modificações através de
vários Grupos de Controle de Configuração (GCCs), associados a tipos de
projetos ou etapas do desenvolvimento.
•
Permitir diferentes mecanismos de comunicação entre os envolvidos no
processo, de maneira a tornar mais ou menos formal esta comunicação, como no
caso das reuniões do GCC, por exemplo, que podem ocorrer fisicamente ou
através de trocas de mensagens eletrônicas entre seus membros.
•
Documentar as estratégias e o planejamento do processo, para que este seja
estabelecido e se torne gerenciado, isto é, possa ser executado para todos os
projetos da organização usuária do Ambiente.
205
5.1.2
Desenvolvimento de Software Baseado em Configurações-base
A GCS no Ambiente deve suportar o desenvolvimento de software baseado em
configurações-base. Itens de configuração são criados e modificados livremente pelo
responsável pelo produto na sua área de trabalho até que sejam encaminhados ao
Ambiente para serem aprovados pela qualidade, segundo critérios definidos para cada
tipo de item, e controlados, isto é, passarem a fazer parte de uma configuração-base de
projeto, na biblioteca controlada. As modificações nas configurações-base passam a ser,
então, controladas e acompanhadas pela GCS no Ambie nte.
Isto permite o apoio gerencial através do acompanhamento do desenvolvimento do
projeto pela evolução das configurações-base; após entrega do produto, através do
controle das distribuições do software, e durante todo o ciclo de vida do produto, pelo
acompanhamento de suas modificações.
5.1.3
Suporte ao Ciclo de Vida do Item de Configuração
Um item de configuração no Ambiente Integrado deve ter um ciclo de vida que consiste
de um conjunto de transições de estado, que definem qual papel um usuário da GCS
deve ter para mover o item de um estado para outro e o evento que provoca a transição.
Um produto de trabalho, ou item de configuração, depois de finalizado é identificado e
encaminhado pelo Responsável pelo Produto ao Ambiente, para ser avaliado e aprovado
pela Qualidade. Quando um marco específico do projeto é atingido, uma configuraçãobase é estabelecida com as versões atuais e aprovadas dos itens de configuração que a
compõem, que passam, então, para o controle da GCS.
Assim, o desenvolvimento continua, com os usuários e desenvolvedores tendo por base
a configuração estabelecida na biblioteca controlada. Modificações nos itens
controlados só podem ser feitas mediante um registro de uma ocorrência, através do
processo Solucionar Ocorrências.
206
5.1.4
Suporte ao Controle de Versões
O controle de versões é essencial, pois fornece o mecanismo para manter o histórico das
modificações nos itens de configuração encaminhados ao Ambiente. Para que se
estabeleça um controle sobre as diversas versões de um item de configuração, todas
devem ser armazenadas e identificadas unicamente. O esquema de identificação das
versões dos itens pode ser feito em forma de árvore, para permitir a identificação única
e das ramificações a partir de qualquer versão, ao mesmo tempo em que mantém o
histórico das versões.
5.1.4.1
Biblioteca da GCS
A biblioteca da GCS pode ser estruturada como uma hierarquia de arquivos e diretórios,
em forma de árvore, no repositório de produtos do Ambiente. Um usuário deste sistema
deve poder obter não somente a versão mais recente de um item de configuração, mas
também as anteriores. Para isto devem ser mantidos os metadados de descrição do item
de configuração e registros de histórico, que contêm informação suficiente para recriar
qualquer versão do arquivo.
A biblioteca da GCS pode ser, assim, composta por um módulo (ou mais de um) que é
uma hierarquia de diretório. Um projeto de software é identificado como um único
módulo na biblioteca.
5.1.4.2
Política Check-in/Checkout e Composição
As políticas empregadas para o armazenamento e acesso aos itens de configuração na
biblioteca controlada no Ambiente devem ser baseadas nas políticas de check-in/checkout e composição.
Operações básicas da política de check-in/check-out devem ser implementadas de
maneira a permitir que os itens de configuração sejam armazenados e acessados de
maneira controlada. Isto requer mecanismos de controle de acesso baseados em
autorizações e no estado do item, segundo o seu ciclo de vida definido.
207
A política de composição possibilita a criação de configurações-base, a partir da
biblioteca controlada, ou seja, agregações de itens de configuração identificadas por um
rótulo atribuído a todos os elementos do conjunto, em marcos específicos do
desenvolvimento do software, constituindo as configurações-base do projeto.
5.1.5
Política de Liberação
Todos os itens de configuração devem ser liberados e distribuídos pela GCS. Itens de
configuração não devem ser aceitos em qualquer situação senão diretamente da GCS.
Os desenvolvedores devem ter como objetivo o encaminhamento do item à Qualidade,
juntamente com as informações necessárias, para posterior controle pela GCS. Isto evita
problemas de inconsistência de versões na geração das distribuições e auditorias
adicionais nos produtos controlados quando forem efetivamente ent regues.
5.1.6
Suporte ao Ciclo de Vida de uma Solicitação de Modificação
Uma solicitação de modificação (SM) deve ter um ciclo de vida bem definido pela GCS
no Ambiente.
O Ambiente deve oferecer o suporte necessário a este ciclo de vida, de maneira a
agilizar o trabalho dos envolvidos nas atividades, documentar cada etapa do processo e
fornecer a visibilidade do estado da modificação, através do estado da SM.
Além disto, as Solicitações de Modificação devem ser mantidas em uma base de dados
a fim de que possam ser extraídos os relatórios de modificações e ser mantida a
rastreabilidade destas com os itens de configuração.
5.1.7
Integração com a Garantia do Produto
O processo da Garantia de Produto no Ambiente Integrado engloba as atividades de
encaminhamento, verificação e controle de produtos desenvolvidos em um projeto, após
sua confecção ou modificação.
208
Este processo, na visão da Gerência da Qualidade do Ambiente (Lahoz, 2004), consiste
no encaminhamento dos produtos de um projeto para avaliação e posterior
encaminhamento à GCS. Um produto de trabalho só será efetivamente controlado após
sua confecção ou modificação, avaliação (com parecer de conformidade satisfatório) e
armazenamento na biblioteca da GCS no repositório do Ambiente Integrado.
Este processo engloba parte da atividade de identificação da configuração, já que
quando os produtos de trabalho individuais são encaminhados pelos desenvolvedores os
metadados de identificação associados ao item são também fornecidos.
O processo de encaminhamento do produto é a interface de entrada de um item de
configuração no Ambiente.
5.2
A Implementação do Protótipo Change and Configuration Management no
Ambiente Integrado
O protótipo Change and Configuration Management foi elaborado para demonstrar
algumas das funcionalidades do processo da GCS, conforme modelado no Capítulo 4. A
elaboração do protótipo contribuiu também para a identificação dos serviços mínimos
necessários para a implementação dos processos da GCS no Ambiente Integrado.
Sendo parte essencial do processo da GCS, o gerenciamento das solicitações de
modificação foi adotado como base para a implementação do protótipo, ainda que
algumas interfaces dos outros processos da GCS tenham sido elaboradas para dar uma
idéia geral da GCS no Ambiente.
Nas seções seguintes deste Capítulo apresentam-se as definições dos requisitos mínimos
para o protótipo intitulado Change and Configuration Management, bem como os
recursos necessários, em termos de ferramentas e serviços, que o Ambiente Integrado
deve prover para que os processos da GCS possam ser implementados de forma a
atender seus objetivos.
209
5.2.1
Os Requisitos do Protótipo
Para que se possa visualizar, de uma forma gráfica, os requisitos para o protótipo
Change and Configuration Management , é utilizado o diagrama de contexto da UML
(Booch et al., 2000), conforme a Figura 5.1.
Change and Configuration
Management
Definir
Estratégias da
GCS
Planejar a
GCS
Gerente das
Modificações e da
Configuração
Gerenciar
Configuraçõesbase
Responsável pelo
Produto
Responsável
pela GCS
Gerenciar
solicitações de
Modificação
Presidente
do GCC
Cliente da
GCS
FIGURA 5.1 – Diagrama de Contexto do protótipo Change and Configuration
Management.
A seguir são descritos os componentes do diagrama de contexto apresentado
anteriormente.
210
5.2.1.1
Definir Estratégias da GCS
Através desta funcionalidade, o Gerente das Modificações e da Configuração
documenta as estratégias da GCS na organização, de maneira que estas possam ser
utilizadas para todos os projetos, incorporando também as definições, convenções e
procedimentos criados ou atualizados durante a execução dos projetos. Esta
funcionalidade pode ser detalhada conforme o diagrama de casos de uso da Figura 5.2.
Definir objetivos e
escopo da GCS
Gerente das
Modificações e da
Configuração
Definir
procedimentos e
convenções para as
atividades da GCS
Definir estratégias para
desenvolvimento
paralelo
Definir métricas para
a GCS
Definir estratégias
para o planejamento
da GCS
FIGURA 5.2 – Diagrama de Casos de Uso da Definição das Estratégias da GCS.
As Figuras C.3 a C.5 do Apêndice C ilustram algumas telas do protótipo relacionadas a
esta funcionalidade, realizadas pelo papel SCM Manager.
5.2.1.2
Planejar a GCS
Esta funcionalidade tem por objetivo auxiliar o Gerente das Modificações e da
Configuração no planejamento da GCS, através da definição: das relações com o
ambiente de projeto; das atividades, fases e marcos da GCS; das responsabilidades dos
211
envolvidos no processo e do ambiente da GCS, entre outras atividades, que permitem a
implantação da GCS com sucesso no projeto. Esta funcionalidade pode ser detalhada
conforme o diagrama de casos de uso da Figura 5.3.
Definir relações com
ambiente de projeto
Definir linhas de
desenvolvimento
Definir a atividade de
identificação da
configuração
armazenamento e
controle
Gerente das
Modificações e da
Configuração
avaliação da
configuração
Definir atividade d e
controle das
modificações
Definir relato da
situação
Definir Ambiente
da GCS
Definir ferramentas,
técnicas e métodos
Definir tarefas, fases
e marcos
FIGURA 5.3 – Diagrama de Casos de Uso do Planejamento da GCS.
As Figuras C.6 e C.7 do Apêndice C ilustram algumas telas desta funcionalidade
relacionadas ao papel SCM Manager.
212
5.2.1.3
Gerenciar Configurações-base
O principal objetivo desta funcionalidade é estabelecer as atividades para manter a
integridade das configurações-base de projeto e fornecer, aos envolvidos no processo da
GCS, o acesso aos itens de configuração e às informações referentes a eles. Esta
funcionalidade consiste em descrever os itens de configuração, armazená- los na
biblioteca da GCS e controlar o acesso aos mesmos, bem como controlar, registrar e
incorporar as modificações feitas neles, após a aprovação da Qualidade, e, ainda relatar
a situação da configuração e das modificações.
Durante estas atividades o item de configuração segue um ciclo de vida simplificado
que pode ser visualizado na Figura 5.4.
encaminhar produto
Encaminhado
encaminhar produto
check-in
Controlado
check-out
Sob Modificação
FIGURA 5.4 – Ciclo de Vida de um Item de Configuração.
Para entender o contexto do gerenciamento das configurações-base, é necessário
entender como deve ser feito o encaminhamento dos produtos ao Ambiente, através de
processo específico da Qualidade.
Um Responsável pelo Produto, ao terminar a confecção do seu produto de trabalho,
deve identificá- lo e encaminhá- lo ao Ambiente, formalizando assim, temporariamente, a
entrega de seu produto, ou seja, o final de sua fabricação. No encaminhamento do
213
produto, este deve ser identificado e descrito conforme definido no planejamento da
GCS. Itens modificados estão sujeitos ao mesmo procedimento de encaminhamento ao
Ambiente (Lahoz, 2004). Nesta fase, o estado do item está no estado Encaminhado.
Os itens encaminhados, antes de serem controlados pela GCS, devem sofrer uma
avaliação em marcos específicos do projeto, feita segundo o tipo e categoria dos itens,
no intuito de garantir que atendam a seus requisitos, tanto de formato como de conteúdo
e funcionalidade (Lahoz, 2004).
Quando é atingido o marco de projeto específico, conforme planejamento da GCS, uma
configuração-base é criada na biblioteca da GCS, contendo todos os itens de
configuração que a compõem e estão aprovados pela Qualidade, que passam para o
estado Controlado e a pertencer à biblioteca controlada. A partir daí, a configuraçãobase fica sujeita ao controle da GCS. Registros de históricos devem ser mantidos, de
maneira que as modificações e o acesso aos itens de configuração e as distribuições dos
mesmos sejam mantidos.
Quando uma solicitação de modificação em um item é aprovada para implementação, o
item de configuração é retirado da biblioteca controlada para a área de trabalho do
desenvolvedor (check-out) e tem seu estado atualizado para Sob modificação,
impedindo que outras operações de check-out sejam realizadas. Quando o item retirado
é encaminhado novamente para o Ambiente, após a aprovação da implementação pela
Qualidade, o item é colocado de volta na biblioteca (checked-in), este tem seu estado
atualizado para Controlado, e uma nova versão do mesmo é criada. Operações get
efetuadas sobre itens que estão sob modificação são registradas para que os usuários
sejam informados depois que a nova versão do item obtido foi colocado na biblioteca.
As operações de check-in/out na biblioteca da GCS são realizadas pelo Responsável
pela GCS.
Esta funcionalidade pode ser detalhada conforme o diagrama de casos de uso da Figura
5.5. O papel de Cliente da GCS representa, nesse diagrama, todos os clientes da GCS,
incluindo gerentes, desenvolvedores, clientes externos e demais envolvidos no processo
214
que têm permissão para obter produtos de trabalho da GCS, como itens de configuração
e relatórios.
Descrever item
de configuração
Responsável pelo
Produto
Criar
Configuraçõesbase
Incorporar
modificações às
configuraçõesbase
Responsável pela
GCS
Liberar IC para
modificação
Obter IC
para
utilização
Obter situação da
configuração e das
modificações
Cliente da GCS
Registrar
distribuição de
configuraçãobase
FIGURA 5.5 – Diagrama de Casos de Uso do Gerenciamento das Configurações-base.
5.2.1.3.1
Caso de Uso Descrever Item de Configuração
Neste caso de uso o Responsável pelo Produto registra no formulário de
encaminhamento do produto as informações referentes à identificação do item de
215
configuração, que serão armazenados na biblioteca controlada. Este caso de uso é
realizado quando o produto é encaminhado ao Ambiente.
5.2.1.3.2
Caso de Uso Criar Configurações-base
Este caso de uso permite que o Responsável pela GCS crie uma configuração-base a
partir da biblioteca da GCS, através da seleção dos itens que fazem parte da
configuração-base e da identificação e descrição da configuração-base criada. A criação
de uma nova configuração-base deve ser automaticamente comunicada a todos os
Clientes da GCS. Uma lista de composição da configuração-base deve ser emitida e
associada à configuração-base, indicando todos os itens que fazem parte da
configuração-base, com suas respectivas versões (Figura C.28).
5.2.1.3.3
Caso de Uso Liberar IC para Modificação
Através deste caso de uso o Responsável pela GCS realiza a operação de check-out ou
retirada de um ou mais itens de configuração para a área de trabalho do Responsável
pelo Produto para que as modificações sejam implementadas. O Responsável pelo
Produto ou desenvolvedor designado para implementar a modificação deve ser
informado de que o item está disponível na sua área de trabalho. Esses itens, que ficam
no estado Sob Modificação, não podem ser retirados novamente para modificação até
que as modificações já aprovadas para implementação sejam incorporadas à
configuração-base. Os itens podem ser obtidos para utilização somente, pelos Clientes
da GCS, que, no entanto, devem ser informados do estado do item. Se o cliente optar
pela obtenção do item, ele deve ser informado da atualização da versão do item na
configuração-base, quando esta ocorrer.
5.2.1.3.4
Caso de Uso Incorporar Modificações nas Configurações-base
Este caso de uso permite que o Responsável pela GCS incorpore a uma configuraçãobase os itens de configuração que foram modificados. O Responsável pela GCS deve
216
inicialmente selecionar a configuração-base à qual os itens serão incorporados (o default
é a configuração-base atual) e indicar a localização dos mesmos. A operação de checkin é realizada: os itens de configuração têm o estado atualizado para Controlado, os
contadores de número de versão são incrementados, tanto dos itens quanto da
configuração-base a que pertence. O Responsável pela GCS registra as informações
referentes ao histórico da modificação (Figura C.26).
5.2.1.3.5
Caso de Uso Obter IC para Utilização
Através deste caso de uso, um Cliente da GCS pode obter um item de configuração da
biblioteca controlada para utilização. Este caso de uso deve inicialmente permitir ao
Cliente da GCS selecionar a configuração-base (a default deve ser a atual). O esquema
de autorizações existente deve restringir o acesso aos itens para determinados clientes
ou partes da configuração. O cliente deve ter a opção de selecionar o(s) item(ns)
desejado(s), indicar o local onde deseja colocar (o default deve ser a sua área de
trabalho no Ambiente) e efetuar a operação. O cliente deve ser informado se o item
estiver sob modificação, para que tenha a opção de cancelar a operação. O cliente deve
ser solicitado a entrar com o motivo da retirada do item, para o registro de histórico (que
retém informações de quem obteve o item, quando e porque).
5.2.1.3.6
Caso de Uso Obter Situação da Configuração e das Modificações
Este caso de uso trata da obtenção do estado da configuração e das modificações, tanto
através de relatórios periódicos ou obtidos a qualquer mome nto para um determinado
propósito, quanto daqueles gerados automaticamente durante as operações realizadas na
biblioteca da GCS, como a informação da existência de um novo item de configuração
ou configuração-base na biblioteca.
Os relatórios periódicos são obtidos pelo Responsável pela GCS e disponibilizados para
as Gerências pertinentes (qualidade, projeto) e outros envolvidos no projeto.
217
Os relatórios automáticos devem ser gerados quando operações são realizadas na
biblioteca da GCS, como a informação de que um novo item foi inserido na biblioteca.
5.2.1.3.7
Registrar Distribuição de Configuração-base
Através desta funcionalidade as distribuições das configurações-base, geralmente as
configurações-base de produto, são registradas através do preenchimento de uma
solicitação de liberação, para que se tenha um controle sobre elas. Uma distribuição
pode ser liberada a um cliente específico em marcos definidos no planejamento, como
após o estabelecimento da primeira configuração-base de produto, ou quando solicitada
por um cliente autorizado. Consiste na ação de copiar a configuração-base selecionada
para uma área do repositório do Ambiente ou meio físico selecionado, com a verificação
da permissão de liberação do solicitante e o registro da solicitação de liberação
(informações sobre identificação da configuração-base, solicitante, localização de
destino, data da solicitação, data da liberação, responsável pela liberação e o motivo)
(Figura C.27).
5.2.1.4
Gerenciar Solicitações de Modificação
Esta funcionalidade tem por objetivo principal estabelecer as atividades relativas ao
gerenciamento das solicitações de modificação nos itens de configuração, desde sua
abertura até seu fechamento.
Uma modificação em um item de configuração surge como conseqüência de um evento
detectado após o estabelecimento da primeira configuração-base do projeto, que pode
ser uma mudança de requisitos, introdução de novas funcionalidades ou correção de
erros, por exemplo, registrado em um Relatório de Ocorrência, encaminhado ao
Responsável pela GCS, pelo Solucionador da Ocorrência. Uma Solicitação de
Modificação (SM) é então identificada e registrada, quando aberta pelo Responsável
pela GCS, para cada item de configuração afetado pela modificação descrita no
Relatório de Ocorrência e segue um ciclo de vida definido, conforme a Figura 5.6.
218
Todos esses passos são acompanhados pelo Ambiente que altera o estado do processo,
conforme o fluxo do trabalho. O Ambiente deve se encarregar de avisar, na forma de
uma mensagem eletrônica e registro na área de trabalho do Responsável pela GCS, bem
como dos demais envolvidos, das ocorrências, SMs e produtos encaminhados a eles.
Durante este processo o estado da SM varia conforme o andamento do processo, sendo
mudado, até atingir o final do processo de gerenciamento da solicitação de modificação.
Aberta
Fechada
Sob Avaliação
Verificada
Rejeitada
Aprovada
Implementada
Aprovadapara
Implementação
Encaminhada
para
Implementação
FIGURA 5.6 – Ciclo de Vida de uma Solicitação de Modificação (SM).
Os requisitos para o gerenciamento das solicitações de modificação podem ser
visualizados no diagrama de casos de uso da Figura 5.7.
219
Avaliar
Modificação
Presidente
do GCC
Membro do
GCC
Agendar
Modificação
Abrir Solicitação
de Modificação
Verificar
Modificação
Responsável pela
GCS
Registrar
Aprovação do
Item Modificado
Registrar
Implementação da
Modificação
Responsável pelo
Produto
FIGURA 5.7 – Diagrama de Casos de Uso do Gerenciamento das Solicitações de
Modificação.
5.2.1.4.1
Caso de Uso Abrir Solicitação de Modificação
Neste caso de uso, o Responsável pela GCS abre uma Solicitação de Modificação para
cada item de configuração a ser modificado em conseqüência da modificação sugerida
como solução para a ocorrência relatada no Relatório de Ocorrência recebido por ele.
Após preencher os campos do formulário pertinentes, inclusive a identificação do
Relatório de Ocorrência que o originou, o Responsável encaminha as SMs ao Presidente
220
do GCC para avaliação. As Figuras C.10, C.11 e C.12 do Apêndice C ilustram algumas
das telas relacionadas a este caso de uso.
5.2.1.4.2
Caso de Uso Avaliar Modificação
Neste caso de uso, o Presidente do GCC irá registrar individualmente, em cada SM
aberta, os resultados da avaliação da modificação relativos a uma ocorrência, que deve
ser analisada em conjunto pelos membros do GCC, cuja composição foi definida no
planejamento. O Presidente poderá valer-se dos recursos do módulo Meeting Support do
Ambiente para realização das reuniões do GCC. Documentos relevantes para a
realização da avaliação, como o check-list de avaliação de impacto da modificação entre
outros, podem ser enviados em anexo à comunicação da reunião para que os membros
do GCC possam ter subsídios para o seu parecer. Quando reuniões formais não forem
necessárias, o Serviço de Comunicação Assíncrona do Ambiente pode ser utilizado para
a comunicação entre os membros do GCC.
Através de pesquisa dos relacionamentos do item de configuração na biblioteca da GCS,
o Presidente do GCC deve certificar-se de que todos os itens impactados pela
modificação têm uma SM aberta.
Após a conclusão da avaliação, a modificação é aprovada ou rejeitada, de acordo com a
disponibilidade de recursos e impacto no projeto. O resultado deve ser registrado, assim
como o esforço estimado para implementação da modificação em cada item, seu grau de
impacto no projeto e a prioridade de sua execução. Se aprovada, a SM é então
encaminhada para ser age ndada. As Figuras C.14, C15 e C.16 apresentam algumas telas
relacionadas a este caso de uso.
5.2.1.4.3
Caso de Uso Agendar Modificação
Neste caso de uso o Presidente do GCC registra na SM o responsável pela
implementação da modificação aprovada, de acordo com a prioridade da SM e o
planejamento do projeto, conforme decisão do GCC tomada em conjunto. Para isto,
221
recursos do módulo Project Management são utilizados para verificação da
disponibilidade de recursos para alocação à tarefa. De acordo com essa disponibilidade
e o seu impacto, a modificação pode ser adiada ou encaminhada para implementação na
configuração-base atual ou na próxima a ser estabelecida. O Responsável pela GCS é
informado do estado das SMs e retira da biblioteca controlada para a área do
desenvolvedor designado para a implementação da modificação os itens que tiveram a
modificação aprovada para implementação, através do caso de uso Liberar IC para
Modificação. As Figuras C.17 e C.18 ilustram este caso de uso.
5.2.1.4.4
Caso de Uso Registrar Implementação da Modificação
Neste caso de uso o Responsável pelo Produto ou desenvolvedor designado para
implementação da modificação registra o resultado da implementação da modificação e
o esforço realmente despendido na realização do trabalho, encaminhando a SM para
registro do resultado da avaliação do item pela qualidade, após encaminhamento do
produto modificado ao Ambiente. As Figuras C.20 e C.21 apresentam telas do protótipo
relacionadas a este caso de uso.
5.2.1.4.5
Caso de Uso Registrar Aprovação do Item Modificado
Através deste caso de uso é feito o registro da aprovação da implementação da
modificação no item de configuração pela Qualidade. Um item modificado passa, assim,
pelas atividades de verificação e validação conforme seu tipo, e só volta a ser colocado
na biblioteca controlada depois de aprovado pela Qualidade, a fim de que a integridade
da configuração-base seja mantida. As Figuras C.22 e C.23 apresentam as telas do
protótipo referentes a este caso de uso.
5.2.1.4.6
Caso de Uso Fechar SM
Neste caso de uso, o Presidente do GCC fecha uma SM, registrando o resultado da
revisão da modificação, ou seja, a conclusão do GCC referente ao atendimento da
222
modificação implementada aos objetivos definidos e os resultados desejados. As
Figuras C.24 e C.25 apresentam telas do protótipo rela tivas a este caso de uso.
5.3
Os Recursos do Ambiente Necessários para os Processos
Com base nos requisitos apresentados na seção anterior e do protótipo desenvolvido, é
possível definir quais são os recursos necessários, em termos de serviços e ferramentas,
que o Ambiente Integrado deve prover para o suporte e automação dos processos da
GCS apresentados no Capítulo 4.
Para o suporte e automação dos processos da GCS, o Ambiente Integrado deve fornecer
uma infra-estrutura que permita: a manutenção das informações, a automatização ou
execução de atividades do processo e a definição clara do papel de cada participante no
processo. A implementação de serviços que auxiliem a condução e controle do processo
permitirá uma fácil interação com os usuários e um controle efetivo sobre os produtos
de trabalho gerados e utilizados por eles. Isto é possível através da arquitetura lógica
oferecida pelo Ambiente, apresentada no Capítulo 3, composta de três camadas: a de
armazenamento, a de serviços e a de interação com o usuário.
5.3.1
Os Recursos da Camada de Armazenamento e Acesso
Os elementos que compõem esta camada são os elementos responsáveis pelo
armazenamento e acesso às informações de projeto. É através do gerenciamento
disciplinado que estes elementos permitem a integração do ambiente. Em termos de
implementação da arquitetura, estes elementos podem estar em plataformas distribuídas
ou centralizadas, mas devem, de qualquer forma, integrar e gerenciar as informações
dos projetos (Sant’Anna, 2000).
O Ambiente deve prover, através desta camada, o meio físico ou repositório para o
armazenamento da biblioteca da GCS, que contém os itens de configuração e seus
metadados, apresentados no Capítulo 2 (Seção 2.3.2), bem como a base de dados de
223
modificações, composta por todas solicitações de modificação abertas durante o projeto,
conforme apresentadas no protótipo.
Nesta abordagem, portanto, o repositório de produtos do Ambiente é considerado como
a entidade física que detém as bases de informações necessárias para a GCS.
Todos os mecanismos de segurança, controle de acesso físico, procedimentos de backup e restauração das informações, soluções tecnológicas e aplicativos de banco de dados
devem ser providos pela camada de armazenamento e acesso do Ambiente.
5.3.2
Os Recursos da Camada de Serviços
Os elementos que compõem a camada de Serviços trabalham de forma cooperativa
utilizando os elementos da camada de armazenamento e acesso para que as informações
de projeto sejam obtidas e disponibilizadas para a camada de interação com o usuário.
São os serviços relacionados ao trabalho cooperativo, à utilização do conceito de fluxo
de trabalho e de ambiente com conhecimento.
Dos recursos definidos para esta camada pelo Ambiente Integrado (Sant’Anna, 2000) e
necessários para a realização das atividades da GCS, considera-se:
•
O Serviço de Coordenação de Processos do Ambiente, que deve apoiar os
processos
da
GCS,
permitindo
que
sejam
modelados,
configurados,
instanciados, acompanhados e terminados. O Serviço de Coordenação deve
garantir que os processos da GCS sigam seu fluxo normal de execução, avisando
e informando os participantes envolvidos no processo sobre a atual situação das
atividades (status) ou, por exemplo, de ocorrências que o impossibilitem de
terminar.
•
O Serviço de Comunicação Assíncrona do Amb iente deve prover o serviço de
troca de mensagens entre os participantes envolvidos nos processos da GCS.
Este serviço deve ter sempre a participação de um remetente e um destinatário e
conter o assunto a ser tratado. As tarefas básicas deste serviço podem ser
224
automaticamente realizadas pelo Ambiente, como a identificação dos remetentes
e destinatários da mensagem, seus privilégios no Ambiente, endereços
eletrônicos e outras informações básicas. O Ambiente pode também, caso seja
configurado neste serviço, verificar a intervalos pré-definidos de tempo, se a
mensagem foi aberta ou respondida pelo destinatário ou mesmo encaminhar
automaticamente uma cópia de todas as mensagens de um grupo para uma
determinada gerência (todas as mensagens do Grupo de Controle da
Configuração enviadas com cópia automática para o Presidente do GCC). Listas
de discussão podem ser criadas para que os grupos do projeto possam debater
assuntos de interesse da GCS, como o impacto de alguma modificação
solicitada. Estas listas devem ser preparadas para incluir apenas os participantes
envolvidos designados para debater um determinado assunto.
•
O Serviço de Comunicação Síncrona do Ambiente deve propiciar, quando
necessário, quadros de discussão para a eventual solução de alguma dúvida ou
solicitação de sugestões para a GCS, principalmente quando a questão for
urgente ou envolver um grande número de participantes.
•
Os Serviços de Agenda devem permitir que as atividades formais da GCS, como
as reuniões do GCC possam ser agendadas eletronicamente, anexando junto o
material necessário para a realização do processo, como o check-list de avaliação
do impacto da modificação. As agendas mantêm os indivíduos informados sobre
seus compromissos com as atividades da GCS ao longo do tempo.
•
O Serviço de Compartilhamento Temporário deve permitir a autoria cooperativa
dos produtos da GCS, permitindo que mais de um indivíduo trabalhe na
confecção de um mesmo produto de forma simultânea. Independente do local de
armazenamento ou plataforma computacional, o produto deve ser colocado em
uma determinada área do repositório de informações do Ambiente (situado na
Camada de Armazenamento e Acesso) para que possa ser acessado por todos os
envolvidos nos processos da GCS. As referências e a situação dos produtos
devem ser também disponibilizadas para os participantes do processo de
225
produção dos mesmos. Deve existir na configuração deste serviço uma relação
papel versus produto de tal maneira que durante a realização de um processo
seja possível identificar quais papéis têm autorização de compartilhamento de
quais produtos (dados e informações). Após uma determinada fase especificada
no processo, este compartilhamento temporário se encerra, devendo o arquivo
ser encaminhado ao Ambiente para aprovação da Qualidade e posterior controle
pela GCS, se for um item de configuração, ou devolvido ao seu autor ou
responsável. Um Agente monitor atua regularmente neste serviço, atualizando o
estado de cada produto da GCS, através da monitoração de alguns campos prédeterminados, como o estado de uma solicitação de modificação, por exemplo, a
fim de acompanhar e monitorar o andamento deste produto durante sua vida nos
processos da GCS.
•
O Serviço de Biblioteca deve manter e disponibilizar, para os participantes
envolvidos com os processos da GCS, os documentos técnicos, relatórios, e
check-lists utilizados nas atividades de gerenciamento da configuração e das
modificações. O Serviço de Biblioteca deve manter e garantir também o acesso
às informações que têm relacionamento indireto com o processo da GCS
(políticas organizacionais ou estratégias de desenvolvimento, por exemplo)
facilitando a busca de informações nestas publicações.
•
O Serviço de Lembrança, ou Agenda Pessoal deve informar os envolvidos com a
GCS sobre suas tarefas cotidianas, sobre as datas importantes como reuniões
pré-estabelecidas do GCC, cronograma de projeto e a data de entrega de um item
modificado, no caso de desenvolvedores. Cabe a este serviço permitir que os
envolvidos com a GCS possam registrar algo para ser lembrado, e manter seus
registros.
•
O Serviço de Dicionário e Enciclopédia deve permitir que todos os participantes
envolvidos com a GCS (na organização e nos projetos) possam manter e
consultar termos e conceitos utilizados por esta área de conhecimento. Além dos
conceitos relacionados diretamente à GCS, os conceitos e termos relacionados
226
ao próprio Ambiente devem também ser descritos. Este serviço deve ser ágil e
de fácil manutenção, para que possa ser atualizado e revisado constantemente.
•
O Serviço de Documentação de Escritório deve permitir aos participantes
envolvidos com a GCS manter e recuperar a documentação administrativa
endereçada à equipe. Isto pode incluir memorandos, circulares internas,
solicitações, ou qualquer documento de cunho administrativo que de alguma
forma afete as atribuições e as tarefas da GCS nos projetos ou na organização.
Através de uma base de dados de documentos de escritório, este serviço pode ser
uma forma segura e rápida de tramitar os documentos administrativos da GCS.
O serviço de me nsagens eletrônicas pode ser utilizado em conjunto com este
serviço para avisar um participante de um novo documento disponível, por
exemplo.
•
O Serviço de Atendimento ao Usuário deve permitir que todos os envolvidos
com a GCS possam apresentar suas críticas, sugestões e dúvidas com relação a
qualquer tópico relacionado à GCS, ao projeto ou ao Ambiente Integrado. O
usuário pode, através deste serviço, colocar suas críticas de forma construtiva e
sugerir adaptações às atividades da GCS no Ambiente.
•
O Serviço de Segurança deve permitir que qualquer envolvido nos processos da
GCS tenha disponíveis os serviços e produtos da GCS no Ambiente, através de
uma identificação de uma senha, que o habilitará ao acesso, com privilégios
relativos ao papel que desempenha relacionado à GCS (nos projetos e na
organização). Este serviço deve garantir que as informações e produtos não
públicos sejam disponibilizados apenas por pessoas devidamente credenciadas e
autorizadas.
•
Ferramenta de controle de versões dos itens de configuração, para o suporte ao
processo de gerenciamento da configuração, utilizada para controlar o
armazenamento e o acesso às versões dos itens de configuração e às informações
referentes a eles na biblioteca da GCS, contida no repositório de produtos do
227
Ambiente, durante todo o ciclo de vida do projeto. Deve oferecer também
suporte ao controle da distribuição das configurações-base para usuários dentro
do ambiente de desenvolvimento e distribuições para clientes externos. Devem
ser fornecidos mecanismos que permitam as seguintes ações sobre a biblioteca:
o Colocar novos itens de configuração.
o Obter os itens de configuração.
o Versionar seqüencialmente os itens de configuração armazenados.
o Registrar e atualizar informações de descrição dos itens de configuração
e das modificações realizadas sobre eles.
o Criar e manter as configurações-base de projeto e distribuições.
Para isto devem ser implementadas no mínimo as operações ou funcionalidades
identificadas a seguir:
•
Check-out: ler/copiar a (última) versão de um arquivo guardada no sistema. Esta
operação muda o estado do item retirado para Sob modificação até que seja
efetuada uma operação de check-in no item retirado.
•
Check-in: enviar as modificações para a biblioteca. Ação de inserir/atualizar o
conteúdo de um item na biblioteca, que resulta no incremento do número de
versão do item e no registro do histórico de modificações do item (informações
sobre data, hora, autor e descrição sucinta da modificação, incluindo a
identificação da solicitação de modificação associada)
•
Get: obter um arquivo ou vários para utilização somente. Ação de retirar um ou
vários itens da biblioteca para uma área de trabalho do Cliente da GCS para
utilização, após verificação da permissão de acesso ao item e resultando no
registro de histórico do item (informações sobre data, hora, autor e motivo da
retirada do item).
228
•
Criar Configuração-base: atribuir uma identificação de configuração-base a
um conjunto de versões selecionadas de itens pertencentes à biblioteca
controlada, que resulta na criação de um novo item de configuração-base que é
composto por outros itens de configuração.
5.3.3
Os Recursos da Camada de Interação com o Usuário
Os elementos que compõem a Camada de Interação com o Usuário, ou Camada de
Execução, serão responsáveis pela comunicação do usuário com os processos da GCS
no Ambiente a partir de qualquer ponto de uma rede de computadores, permitindo seu
trabalho remoto e cooperativo. Esta camada deverá permitir que os aplicativos que
implementam os serviços da GCS no Ambiente sejam executados e possam realimentar
os processos com a conclusão das atividades e a confecção dos produtos da GCS
executados pelos participantes envolvidos.
Dos recursos definidos para esta camada pelo Ambiente Integrado (Sant’Anna, 2000) e
necessários para a realização das atividades da GCS, consideram-se:
•
O acesso aos processos da GCS deve ser feito em locais que possuam recursos
de rede (local ou distribuída) através de navegadores (browsers) proporcionando
a facilidade de uso em modo gráfico e ambiente de janelas e que possam ser
executados a partir de diversas plataformas (Windows, Unix, Macintosh).
•
A apresentação das telas relacionadas aos processos da GCS deve ser feita de
acordo com o padrão de janelas do Ambiente Integrado.
229
230
CAPÍTULO 6
CONCLUSÕES
A implantação do processo da GCS é essencial para as organizações desenvolvedoras de
software que desejam obter melhor qualidade dos seus produtos e minimizar os
problemas causados pelas modificações no software, principalmente em se tratando de
organizações responsáveis por projetos de software na área aeroespacial.
Neste trabalho foi apresentada uma abordagem para o processo da Gerência das
Modificações e da Configuração de Software (GCS) em um Ambiente Integrado para o
apoio ao desenvolvimento e gestão de projetos de software.
Esta abordagem consistiu na definição e modelagem do processo da GCS, tendo como
ponto de partida as práticas básicas deste processo apresentadas em padrões e modelos
de processo de software. Como estes padrões apresentam o que o processo deve fazer,
mas não o como, buscou-se na literatura não só o entendimento dos fundamentos da
disciplina, mas também abordagens práticas da GCS, para que os detalhes necessários
para a modelagem do processo fossem obtidos.
Quanto à disciplina GCS, foram apresentados conceitos e definições importantes, suas
atividades fundamentais e funcionalidades, bem como os mecanismos e políticas
necessárias para o suporte a estas. Ainda que a apresentação de sistemas ou ferramentas
de GCS não fosse um objetivo do trabalho, a evolução e o estado atual, uma
classificação, e também alguns critérios utilizados para avaliação das mesmas foram
apresentados, para auxiliar no levantamento das funcionalidades da GCS a serem
contempladas na abordagem proposta.
Procurou-se neste trabalho evidenciar que um sistema ou ferramenta de GCS pode
facilitar ou até mesmo viabilizar algumas de suas atividades, mas sua utilização não é
suficiente para que se garanta a integridade do produto durante seu desenvolvimento
nem que se tenha controle sobre todas as modificações feitas nele. Para isto, um
231
processo de gerenciamento das modificações e da configuração bem definido deve ser
seguido durante todo o ciclo de vida do produto de software.
Quanto ao processo de software e sua modelagem, este trabalho procurou apresentar a
importância que o processo utilizado na construção do software tem para a obtenção de
produtos com mais qualidade, que venham atender aos propósitos para os quais foram
criados. Dentro desta visão é que foram tomados os modelos e padrões de processo de
software ISO IEC 12207 e 15504 como ponto de partida para a definição do processo da
GCS proposto. Na Tabela 6.1, associadas às atividades da GCS no padrão 12207,
encontram-se as práticas básicas do 15504, bem como, a título de comparação, as
práticas específicas do CMMI. Na última coluna da tabela apresentam-se os processos
fundamentais da GCS propostos por esta abordagem, que contemplam estas práticas.
Ainda dentro desta visão, procurou-se mostrar a necessidade de formalização dos
processos através do recurso da modelagem, bem como apresentar o SPEM, da OMG,
como uma linguagem adequada para expressar os modelos dos processos. A notação
padrão UML utilizada pelo SPEM facilita a atividade de modelagem de processos, uma
vez que se podem reutilizar os conhecimentos desta linguagem obtidos na prática da
modelagem de software.
A apresentação, neste trabalho, do Ambiente Integrado para apoio ao desenvolvimento e
gestão de projetos de software teve como objetivo não somente servir de contexto para a
abordagem apresentada, mas teve também por finalidade mostrar que o suporte
automatizado de um ambiente integrado apresenta-se como facilitador para a definição e
a efetiva implantação deste processo em organizações desenvolvedoras de software, que
procuram o sucesso no seu desenvolvimento em termos de qualidade e produtividade.
Uma avaliação completa do modelo do processo apresentado, no entanto, só será
possível após sua utilização prática em algum desenvolvimento de software.
232
TABELA 6.1 - A GCS nos Padrões e no Modelo Proposto.
ATIVIDADES
ISO/IEC 12207
Implantação do
processo.
Identificação da
configuração.
Controle da
configuração.
Relato da
situação da
configuração.
Avaliação da
configuração.
Gerenciamento
da liberação e
entrega.
-
PRÁTICAS BÁSICAS
ISO/IEC 15504
PRÁTICAS
ESPECÍFICAS
CMMI
CFG.2.BP1 – Desenvolver
SP 1.2-1 –
estratégia para o gerenciamento da Estabelecer um
configuração
sistema de
CFG.2.BP4 - Estabelecer estratégia gerenciamento da
de desenvolvimento de linhas de
configuração.
desenvolvimento.
CFG.2.BP2 – Identificar os itens de SP 1.1-1 –
configuração.
Identificar itens de
CFG2.BP3 – Estabelecer as
configuração.
estruturas e hierarquias de arquivos
e diretórios CFG.2.BP5 –
Estabelecer configurações-base
internas e distribuições.
CFG.2.BP6 – Manter descrição do
item de configuração.
CFG.2.BP7 – Controlar
SP 2.2-1 – Controlar
modificações e distribuições
itens de
CFG.2.BP6 – Manter descrição do configuração.
SP 3.1-1 –
CFG.2.BP8 – Manter histórico do
Estabelecer
registros do
CFG.2.BP10 – Verificar informação gerenciamento da
sobre itens controlados.
configuração.
CFG.2.BP11 – Gerenciar o backup,
armazenamento, manuseio e
distribuição dos itens controlados.
CFG.2.BP9- Relatar situação da
SP 3.1-1 –
configuração.
Estabelecer
registros do
gerenciamento da
configuração.
SP 3.2-1 – Executar
auditorias da
configuração.
CFG.2.BP5 – Estabelecer
SP 1.3-1 – Criar ou
configurações-base internas e
distribuir
distribuições.
configurações-base.
CFG.2.BP7 – Controlar
modificações e distribuições.
CFG.4 – Gerenciar solicitações de
modificação
233
SP 2.1-1 –
Acompanhar
solicitações de
modificação.
MODELO DA
GCS
PROPOSTO
Definição das
estratégias
organizacionais
da GCS.
Planejamento da
GCS.
Gerenciamento
da configuração:
Identificação da
Configuração.
Gerenciamento
da Configuração:
Armazenamento
e Controle dos
Itens de
Configuração.
Gerenciamento
da Configuração:
Relato da
Situação da
Configuração.
-
Gerenciamento
da Configuração:
Identificação da
Configuração e
Armazenamento
e Controle dos
Itens de
Configuração.
Gerenciamento
das solicitações
de modificação.
O suporte oferecido pelo Ambiente e uma ferramenta para o gerenciamento da
configuração foram apresentados como recursos facilitadores para a execução do
processo da GCS, contribuindo para o sucesso de sua implantação em uma organização.
A especificação e implementação de um protótipo para demonstração de
funcionalidades do processo, como o gerenciamento das solicitações de modificação,
mostraram-se um recurso muito útil para ilustrar e explorar as possibilidades de
automação de processo, a partir do modelo apresentado. Pode ainda servir de base para
desenvolvimento futuro e novas experimentações, como as de novos ciclos de vida para
as solicitações de modificação e para o item de configuração, por exemplo.
O modelo de processo proposto e as funcionalidades da GCS apresentadas na
especificação do protótipo certamente apresentam limitações, mesmo porque é muito
ampla a gama de funcionalidades que a GCS pode oferecer. De qualquer forma,
procurou-se cobrir as práticas básicas de um modelo de processo, como o ISO IEC
15504, e atender aos requisitos mínimos da GCS, que é controlar as configurações-base,
os itens produzidos ao longo do projeto e as modificações nestes, contribuindo, assim,
para que se atinja o objetivo de obter maiores níveis de qualidade dos produtos nas
organizações desenvolvedoras de software que porventura venham a utilizar este
modelo de processo, como o INPE e o CTA.
Ainda que a solução para a GCS apresentada neste trabalho tenha sido idealizada com a
intenção de integrá- la ao Ambiente, de maneira a tornar mais eficiente o processo de
desenvolvimento de software, esta integração não é necessária para uma implementação
da solução. O processo definido pode ser utilizado empregando-se ferramentas de
suporte disponíveis na organização, quando a utilização de uma ferramenta for um
requisito levantado para o processo.
Espera-se que uma abordagem como esta, juntamente com os avanços na automação de
processos proporcionados pelo Ambiente Integrado, sejam capazes de atender a
contento o gerenciamento da configuração e das modificações no desenvolvimento de
software, principalmente nas organizações responsáveis por aplicações aeroespaciais, no
sentido de minimizar os problemas causados pelas modificações no software.
234
Cabe ressaltar que, uma vez entendidas as melhores práticas para o gerenciamento da
configuração, é necessário também entender como aplicar com sucesso os processos da
GCS e as ferramentas para o seu suporte. Como observa White (White et al., 2000), um
erro cometido com freqüência é assumir que uma solução adotada se encaixa em
qualquer situação ou é a solução certa. Projetos diferentes apresentam requisitos para a
GCS diferentes. Um gerenciamento de configuração bem sucedido em qualquer projeto
é aquele que permite que as modificações ocorram tanto quanto possível, sem haver
perda de controle sobre o software. Existe, assim, a necessidade de que o processo da
GCS seja constantemente adequado de maneira a que a sobrecarga de trabalho
acarretada com a utilização das ferramentas de GCS satisfaça aos requisitos de
modificação do projeto em particular. A abordagem de melhoria de processo, adotada
em todo o Ambiente Integrado vai, portanto, ao encontro desta necessidade.
Cabe ainda salientar (Hass, 2002) que até mesmo o melhor sistema de GCS não é capaz
de resolver problemas de planejamento, projeto ou testes. A ordem na qual os objetos
são produzidos e colocados em uso é uma questão de planejamento, os relacionamentos
e dependências entre estes objetos é um problema de projeto e a determinação de
quando os objetos que foram finalizados podem ser utilizados nos testes de outros
objetos é um problema do planejamento dos testes. Cabe à GCS o papel, essencialmente
burocrático, de fornecer o estado dos itens de configuração, dizer como eles estão
relacionados, relatar o estado de um item e a composição das configurações-base.
Nas seções seguintes são ainda apresentadas conclusões sobre modelagem de processo e
utilização de padrões e modelos de processo. Finalmente, são feitas algumas
recomendações e sugestões de trabalhos futuros.
6.1
A modelagem de processos
A modelagem de processos ajuda os modeladores a identificar relacionamentos, efeitos
e objetos, possibilitando um exercício muito útil de simulação de decisões.
235
Os modelos de processo podem ser produzidos em quase qualquer nível de abstração,
dependendo da finalidade ou propósito para o qual são criados, como por exemplo,
entendimento, comunicação ou automação do processo.
A expectativa inicial deste trabalho, com relação ao modelo da GCS, era de chegar a um
nível de detalhe tal que proporcionasse sua execução na máquina de processos do
Ambiente Integrado, para um projeto de desenvolvimento. Esta expectativa não pôde
ser concretizada, devido a vários fatores. Primeiramente, devido à dificuldade de se
entender uma disciplina complexa como a GCS e definir um modelo de processo em tal
nível de detalhe. Depois, dada a impossibilidade de expressá- lo em uma linguagem de
modelagem que pudesse ser executada pela máquina de processos do Ambiente, ainda
em desenvolvimento.
Outras linguagens, não executáveis, foram pesquisadas como alternativa até que se
chegasse ao SPEM, que foi efetivamente utilizado, proporcionando, assim, a obtenção
de um modelo de processo da GCS, e permitindo também a identificação das
possibilidades de automação do processo.
Como um resumo da utilização de modelos de processo, pode-se ressaltar que estes:
•
Proporcionam uma documentação acurada de um processo de desenvolvimento,
que pode ser compartilhado com toda uma equipe.
•
Podem ser estudados para melhoria, avaliação de maturidade, etc.
•
Podem ser facilmente adequados para satisfazer partes diferentes da organização
ou projetos individuais.
•
Proporcionam a geração de fluxos de trabalho - as bases para a automação de
processo.
236
6.2
Processo e melhoria de processo
A GCS pode ser vista sob diferentes perspectivas. Quando uma organização começa a
considerar a implantação da GCS, a perspectiva de processo precisa ser levada em conta
primeiramente. Para sustentar o trabalho, os processos devem ser entendidos,
implementados e submetidos continuamente à melhoria.
Um processo definido e documentado é uma das exigências dos modelos de processo
para se obter um nível gerenciado. Para alcançar um Nível 3 de maturidade do padrão
ISO/IEC 15504, por exemplo, um processo deve estar documentado de maneira
padronizada, ou seja, um modelo de processo deve estar definido. A codificação das
práticas básicas permite a disseminação de metodologia por toda a organização, o que se
traduz em repetibilidade na execução dos projetos.
Não se encontram facilmente disponíveis relatos de experiências ou experimentos
controlados sobre a utilização de ferramentas ou melhoria do processo da GCS em
organizações nacionais. No entanto, em (Hass, 2002) são apresentados alguns relatórios
de companhias que experimentaram a introdução da GCS, encontrados no site na Web
do European Software Institute. As conclusões destes relatórios indicam que a
introdução do processo da GCS em uma organização traz grandes vantagens, mas o
suporte gerencial é essencial. Daí a importância das atividades de suporte ao
gerenciamento, enfocado na abordagem proposta. Outra conclusão é que a introdução
da GCS em uma organização é uma tarefa difícil, e deve ser feita gradualmente, em
projetos-piloto, antes de ser disseminada em larga escala na organização.
6.3
Recomendações e Trabalhos futuros
A modelagem de processos é um recurso essencial para a melhoria de processo. O fato
dos modelos de processo tratarem fundamentalmente de objetos e interações entre eles
os torna uma maneira muito útil e dinâmica de descrever os processos. Não existe,
ainda, uma metodologia para a modelagem de processos. Nesta dissertação a
representação dos modelos da GCS foi feita através de diagramas da UML. Para
237
representação de um processo completo de software, por exemplo, a representação pode
ser feita através de uma lista hierárquica de alto nível de uma Work Breakdown
Structure (WBS). A WBS de um modelo de processo descreve o trabalho a ser
executado, e o fluxo geral de atividades, que podem ser representadas em diferentes
níveis de detalhe através do conjunto de elementos do SPEM, como Lifecycle, Phase,
Iteration, WorkDefinition e Activity. Um exercício desta representação, feita com o
processo de Gerenciamento das Solicitações de Modificação é apresentado no Apêndice
B. Assim, abordagens ou uma metodologia para a modelagem de processo, utilizando o
SPEM, devem ser mais exploradas e a experiência relatada em artigo técnico.
O modelo da GCS apresentado como resultado deve ser colocado em prática, suas
lacunas e inconsistências devem ser detectadas, possibilitando, assim, sua revisão e
melhoria, que são, afinal, alvos da tecnologia de processo de software.
Inicialmente, segundo a abordagem proposta nesta dissertação, as funcionalidades da
GCS devem contemplar o armazenamento controlado dos itens de configuração, através
da política de check-in e check-out e composição, permitindo o gerenciamento de
configurações-base, até o estabelecimento da configuração-base de produto, que serve
de base para as distribuições, com acompanhamento das solicitações de modificação.
Entre as várias limitações do modelo do processo apresentado neste trabalho estão o
processo de construção (build) de sistema e o controle de áreas de trabalho, que devem
ser tratados pelos desenvolvedores, e o gerenciamento das distribuições. O enfoque é
dado para a manutenção da integridade dos itens de configuração, como código e
documentação associada, durante a fase de desenvolvimento do produto; o
gerenciamento das distribuições deve envolver um controle sobre as distribuições do
produto e situações mais complexas de modificações, quando várias versões do produto
final estão em uso. No entanto, para aplicações da área espacial, como no caso das
desenvolvidas no INPE e IAE, o número das distribuições é limitado, dadas as
características não comerciais das aplicações.
Por outro lado, deve-se considerar a complexidade do software desenvolvido nestas
organizações, nem tanto, às vezes, pela quantidade de linhas de código produzidas, mas
238
pela natureza crítica da aplicação e pelas interfaces com outros sistemas, como no caso
do SOAB, um sistema veículo lançador de satélites. Assim, estudos devem ser
conduzidos no sentido de se obter um melhor controle sobre as modificações nas
interfaces do software, bem como sobre a configuração dos amb ientes de testes e
simulação.
Um suporte mais efetivo ao desenvolvimento paralelo, o gerenciamento de áreas de
trabalho e o suporte à construção (build)/distribuição são áreas que também podem ser
exploradas em trabalhos futuros.
A GCS é um processo dentre os vários suportados pelo Ambiente Integrado. Existe a
necessidade de se fazer com que todos estes processos interoperem com redundância
mínima, para cobrir de maneira consistente o espectro completo de processos de uma
organização. Um trabalho a ser realizado, sem dúvida, é a harmonização da GCS a
todos os demais processos suportados pelo Ambiente.
239
240
REFERÊNCIAS BIBLIOGRÁFICAS
Abdala, M.; Lahoz, C.; Sant’Anna, N. Um estudo para a definição de processos das
gerências da qualidade e da configuração em um ambiente integrado para apoio ao
desenvolvimento e gestão de projetos de software. In: Workshop em Computação
Aplicada, 2., (Workcap), São José dos Campos, Brasil, nov. 2002. Resumos... São José
dos Campos: INPE, 2002. p.11.
Abdala, M.; Lahoz, C.; Sant’Anna, N. Utilizando o SPEM para a modelagem dos
processos da qualidade e do gerenciamento da configuração em um ambiente integrado.
In: Simpósio Internacional de Melhoria de Processo de Software, 5. (SIMPROS), nov.
2003, Recife. Anais... Recife: SIMPROS, 2003. p.91-102.
Abdala, M.; Sant’Anna, N. Modelagem do processo de gerenciamento da configuração
de software para um ambiente integrado, in: Workshop em Computação Aplicada, 3.,
(Workcap), Nov. 2003, São José dos Campos. Anais... São José dos Campos: INPE,
2003.
Acuña, S. T.; Ferré, X. Software Process Modelling. In: World Multiconference on
Systemics, Cibernetics and Informatics, 5. (SCI), July 2001, Orlando, Florida.
Proceedings... Orlando, 2001. p.237-242.
Acunã, S.; Barchin, G.; Laserre, C.; Silva, A.; Sosa, M.; Quincoces, V. Software
engineering and knowledge engineering software process: formalizing the who’s who.
In: International Conference on Software Engineering and Knowledge Engineering, 12.,
July 2000, Chicago, USA. Proceedings... Orlando: 2000. p.221-230.
Ambriola, V.; Conradi, R.; Fuggetta, A. Assessing process-centered software
engineering environments. ACM Transactions on Software Engineering and
Methodology, v.6, n.3, p.283–328, July 1997.
241
American National Standard Institue/Intitue of Electrical and Electronics Engineers.
ANSI/IEEE 1042. Guide to Software Configuration Management, New York, Sept.,
1987.
Bandinelli, S.; Di Nitto, E.; Fuggetta, A. Supporting cooperation in SPADE-1
environment. IEEE Transactions on Software Engineering, v.22, n.12, p.841-865,
1996.
Benali, K.; Derniame, J. C. Software processes modeling: what, who, and when. In:
European Workshop on Software Process Technology, 2., Sept. 1992, Trondheim,
Norway. Proceedings… Trondheim, 1992. p.21-25.
Ben-Shaul, I.; Kaiser, G. E. A paradigm for decentralized process modeling and its
realization in the Oz environment. In: Internationa l Conference on Software
Engineering ,16. (ICSE), May 1994, Sorrento, Italy. Proceedings… Sorrento, 1994.
p.179-188.
Bendix, L.; Dattolo, A.; Vitali, F. Software configuration management in software and
hypermedia engineering: a survey. In: Chang, S. K. (ed). Handbook of Software
Engineering and Knowledge Engineering. [S.l]: World Scientific Publishing, 2001.
v.1, p.523-548.
Bersoff, E.; Henderson, V.; Siegel, S. Software configuration management, an
investment in product integrity. Englewood Cliffs, EUA: Prentice-Hall, 1980. 385p.
Booch, G.; Rumbaugh, J.; Jacobson, I. The Unified Modeling Language: user guide.
Massachusetts, USA: Addison-Wesley, 2000. 482p.
Bounds, N. M.; Dart, S. Configuration Management (CM) Plans : the beginning to
your CM solution. Pittsburgh, USA: Carnegie Mellon Software Engineering Institute
(SEI), 1993. Disponível em:
http://www.sei.cmu.edu/legacy/scm/papers/CM_Plans/CMPlans.MasterToC.html.
Acesso em: 5 dez. 2001.
242
Configuration Management Body of Knowledge (CMBoK). Configuration Mange ment
Wiki Web Site. Disponível em: http://www.cmbok.com/. Acesso em: 10 jun. 2003.
Cederqvist, P. Version management with CVS for CVS 1.10. Copyright 1992, 1993
Signum Support AB. Disponível em: http://www.opencores.org/cvs.pdf. Acesso em: 7
jul. 2002.
Cereja Jr., M. G. O serviço de coordenação de processos para o ambiente “eWebProject”. 2002. Proposta de dissertação (Mestrado em Computação Aplicada) Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 2002.
Cereja Jr., M. G.; Sant’Anna, N.; Borrego Filho, L. F. Modelando um processo de
gestão de problemas em projeto – UML e PML uma exploração de abordagens para a
modelagem de processos. In: Simpósio Internacional de Melhoria de Processo de
Software (SIMPROS), 4., Nov. 2002. Resumos... Recife: SIMPROS, 2002.
Capability Maturity Model for Software (CMM-SW), - version 1.1, Pittsburgh:
Software Engineering Institute, Technical Report CMU/SEI-93-TR-24, Feb. 1993.
Capability Maturity Model Integration (CMMI), Version 1.1, CMMI for Software
Engineering (CMMI-SW), V1.1, Continuous Representation, CMU/SEI-2002-TR-028
- ESC-TR-2002-028, Aug. 2002.
Conallen, J. Building web applications with UML. Massachusetts, EUA: AddisonWesley, 2000. 320 p.
Conradi, R.; Westfechtel, B. SCM: status and future challenges. In: International
Symposium on System Configuration Management, 9. (SCM-9), Sept. 1999, Toulouse,
France. Proceedings… Toulouse, 1999. p.228-231.
Conradi, R.; Fernström, C.; Fuggetta, A. Concepts for evolving software processes. In:
Finkelstein, A.; Kramer, J.; Nuseibeh, B. (ed.). Software process modeling and
technology. Taunton, UK: Research Studies Press, 1994. cap.2, p.9-31.
243
Conradi, R.; Liu, C. Process modeling languages: one or many? In: European Workshop
Software Process Technology (EWSPT'95), 4., Apr. 1995, Noordwijkerhout, The
Netherlands. Proceedings… Noordwijkerhout : [S.n], 1995. p.98-118.
Crnkovic, I. Why do some mature organizations not use mature CM? In: Symposium on
Software Configuration Management, 9. (SCM-9), Sept. 1999, Toulouse, Franc e.
Proceedings… London: Springer-Verlag, Lecture Notes in Computer Science, 1999.
v.1675, p.50-65.
Cruz, T. Workflow: a tecnologia que vai revolucionar processos. São Paulo: Atlas,
1998. 232p.
Cugola, G.; Ghezzi, C. Software processes: a retrospective and a path to the future.
Software Process Improvement and Practice, v.4, n.3, p.101-123, 1998.
Curtis, B.; Kellner, M; Over, J. Process modeling. Communications of the ACM, v.35,
n.9, p.75-90, Sept. 1992.
Dart, S. Concepts in configuration management systems. In: International Workshop on
Software Configuration Management, 3., 1991, Trondheim, Norway. Proceedings…
New York: ACM Press, 1991. p.1-18.
Dart, S. The past, present, and future of configuration management. In: World
Computer Congress on Algorithms, Software, Architecture - Information Processing,
12., 1992, Madrid, Spain. Proceedings… Netherlands: North-Holland, 1992. v.1,
p.244-251.
Dart, S. Not all tools are created equal. Application Development Trends , p.7, Oct.
1996.
Dart, S. The urgent need for configuration management and benefits of automation.
Disponível em: http://www.susandart.com.au/print/. Acesso em: 14 nov. 2002.
Department of Defense (DoD), Military Standard - Defense System Software
Development STD, 2167A, Washington DC, Feb. 1988.
244
Di Nitto,E; Lavazza, L; Schiavoni, M; Tracanella, E; Trombetta, M. Deriving
executable process descriptions from UML. In: International Conference on Software
Engineering, 24., 2002., Orlando, USA. Proceedings… New York: ACM Press, 2002.
p.155–165.
Ellmer, E. Process-centered software engineering environments as the next generation
of CASE tools. In: European Workshop on Next Generation of CASE Tools (NGCT95),
Finland, 1995. Proceedings… Disponível em:
http://citeseer.ist.psu.edu/ellmer95processcentered.html. Acesso em: 4 dez. 2002.
Estublier, J. Software configuration management: a roadmap In: Conference on The
future of Software Engineering, 2000, Limerick, Ireland. Proceedings… New York:
ACM Press, 2000. p.279-289.
Estublier, J. et al. Impact of the research community on the field of software
configuration management: summary of an impact project report. In: Symposium on
the Foundations of Software Engineering (FSE-9), 9., 2001, Vienna, Austria.
Proceedings… New York: ACM Press, Sept. 2002. ACM SIGSOFT Software
Engineering Notes, v.27, n.5, p.31-39.
Estublier, J.; Dami, S.; Amiour, M. High level process modeling for SCM systems. In:
Workshop on System Configuration Management (SCM-7), 7., 1997, Boston, USA.
Proceedings… London: Springer-Verlag, 1997. Lecture Notes In Computer Science,
v.1235, p.81-97.
Feiler, P. H. Configuration Management models in commercial environments,
Technical Report CMU/SEI-91-TR-7, Software Engineering Institute, 1991. Disponível
em: http://www.sei.cmu.edu/legacy/scm/abstracts/abscm_models_TR07_91.html.
Acesso em: 15 out. 2002.
Feiler, P. H.; Humphrey, W. S. Software process development and enactment: concepts
and definitions. In: International Conference on Software Process, 2., Berlin, Germany,
Feb. 1993. Proceedings... Berlin: 1993. p.28-40.
245
Finkelstein, A.; Kramer, J. B.; Nuseibeh, B. Software process modeling and
technology. Taunton: Research Studies, 1994. 384p.
Franch, X.; Ribó, J. M. Using UML for modeling the static part of a software process.
In: UML International Conference, 2., Fort Collins, USA, Oct. 1999. Proceedings...
Fort Collins: [S.n], 1999. p.292-307.
Frühauf, K.; Zeller, A. Software configuration management: state of the art, state of the
practice. In: International Symposium on System Configuration Management (SCM-9),
9., 1999. Proceedings…London: Springer-Verlag, 1999. Lecture Notes In Computer
Science, v.1675, p.217-227.
Fuggetta, A. Software process: a roadmap. In: Future of Software Engineering.
Limerick, Ireland, 2000. Proceedings... New York: ACM Press, 2000. 630 p.
Futrell, R.; Shafer, D.; Shafer, L. Quality software project management. Indianapolis,
USA: Prentice Hall PTR, Jan. 2002. 1680p.
Hass, A. Configuration management principles and practice. Boston, USA: Person
Education, Dec. 2002. 432p.
Hoen, P.J.; Ter Beek, M. H. A conflict-free strategy for team-based model development.
In: International Workshop on Process support for Distributed Team-based Software
Development, 2., (PDTSD'00), World MultiConference on Systemics, Cybernetics and
Informatics (SCI 2000), 4., Orlando, Florida, 2000. Proceedings… Orlando:
International Institute of Informatics and Systemics, 2000. p.720-725.
Institute of Electrical and Electronics Engineers (IEEE), Computer Society, Guide to the
Software Engineering Body of Knowledge (SWEBOK), Trail Version 1.00, May 2001.
Institute of Electrical and Electronics Engineers (IEEE). IEEE 610.12 Standard
Glossary of Software Engineering Terminology, Dec.1990. Standard.
Institute of Electrical and Electronics Engineers (IEEE). IEEE 828 Standard for
Software Configuration Management Plans , 1998. Standard.
246
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC). ISO/IEC 12207 International standard for information
technology - software life cycle processes. Geneva, Switzerland, 1995. Standard.
Commission (ISO/IEC). ISO/IEC 12207 International standard for information
technology - software life cycle processes. Geneva, Switze rland, 2001. Amendment 1.
Commission (ISO/IEC), ISO/IEC 15504-2. Information technology — process
assessment: part 2: - performing an assessment. Geneva, Switzerland, 2003.
International Standard.
Commission (ISO/IEC), ISO/IEC 15504-5. Information technology – process
assessment: part 5: - an exemplar process assessment model. Geneva, Switzerland,
2003. Committee Draft.
Jaccheri, M. L.; Picco, G. P.; Lago, P. Eliciting software process models with the E3
language. ACM Transactions on Software Engineering and Methodology, v.7, n.4,
p.368-410, 1998.
Jaccheri, M. L., Baldi, M., Divitini, M. Evaluating the requirements of software process
modeling languages and systems. In: Process Support for Distributed Team-based
Software Development, Florida, USA.1999. Proceedings… London: Springer-Verlag,
2000. p.96-108.
Jäger, D.; Schleicher, A.; Westfechtel, B. Using UML for software process modeling.
In: European Software Engineering Conference, 7., Toulouse, France, Nov. 1999.
Proceedings… London: Springer-Verlag, 1999. p.91-108.
Jalote, P. CMM in Practice: process for executing software projects at Infosys,
Massachusetts: Addison Wesley Longman, 1999. 372p.
247
Jennings, C. G. Combining object-oriented systems and software configuration
management. Selected Topics in Object-Oriented Programming, Computer Science
770, McMaster University, Dec. 2000.
Jézéquel, J. M. Reifying Configuration Management for object-oriented software. In:
International Conference on Software Engineering, Kyoto, Japan, 1998. Proceedings…
Washington: IEEE Computer Society, 1998. p.240-249.
Joeris, G. Change management needs integrated process and configuration management.
In: European Software Engineering Conference, 6., Zürich, Swiss, 1997.
Proceedings… New York: Springer-Verlag, 1997. p.125-141.
Kulkarni, D. Causes of software accidents due to change, 1996. Disponível em:
http://ic.arc.nasa.gov/ic/projects/safety-maint/softmaint.failures.html. Acesso em: 18
fev. 2003.
Lahoz, C.; Abdala, M.; Sant’Anna, N. O processo de auditar produtos: uma pesquisa
referente à sua definição e modelagem para a garantia da qualidade no e-WebProject.
In: Simpósio Internacional de Melhoria de Processo de Software (SIMPROS), 4., set.
2002, Recife. Resumos... Recife, 2002.
Lahoz, C. Uma abordagem para a gerência da qualidade em um ambiente de
engenharia de software centrado em processo. 2004. 309p. (INPE-11550-TDI/958).
Dissertação (Mestrado em Computação Aplicada) – Instituto Nacional de Pesquisas
Espaciais, São José dos Campos, 2004.
Larsson, M.; Crnkovic, I. Component Configuration Management. In: ECOOP
Conference, Workshop on Component Oriented Programming, 5., Nice, France, 2000.
Proceedings.... Disponível em:
http://www.mrtc.mdh.se/index.phtml?choice=publications&id=0209. Acesso em: 19
set. 2002.
Leveson, N. G. Safeware: System Safety and Computers . Reading: Addison-Wesley
Publishing Company, 1995. 671p.
248
Ministério da Ciência e Tecnologia/ Secretaria de Política de Informática
(MCT/SEPIN). Qualidade e produtividade no setor de software brasileiro (1999 e
2001). Disponível em: http://www.mct.gov.br/sepin. Acesso em: 3 maio 2003.
Moura, C. A. T.; Lahoz, C.; Abdala, M. A practical approach to quality assurance in
critical systems. In: Latin American Dependable Computing (LADC), 1., São Paulo,
Brasil, Oct. 2003. Proceedings... New York: Springer, 2003. v.2847. p.369-370.
Moura, C.; Melnikoff, S. S. S.; Lahoz, C.; Abdala, M.; Fernandes, M. O. S. Uma
abordagem da garantia de qualidade de software no projeto do veículo lançador de
satélite brasileiro. In: Symposium on Software Technology (SoST), Buenos Aires,
Argentina, 1999. Proceedings… Buenos Aires: SADIO,1999. p.13-17.
Nascimento, C. J. A Evolução da Qualidade no Setor de Software Brasileiro: Quatro
Biênios Medindo e Acompanhando Indicadores de Gestão. In: Encontro para a
Qualidade nas Tecnologias de Informação e Comunicações (QUATIC'01), 4., Lisboa,
Portugal, 2001. Resumos eletrônicos ...
http://www.mct.gov.br/Temas/info/Dsi/palestra/QuartoEncontroQuali.htm. Acesso em:
11 out. 2002.
Oliveira, A.; Primo, F.; Cruz, J.; Martino, W. Gerência da Configuração de Software
- evolução de software sob controle, ITI, Ministério da Ciência e Tecnologia, jun.
2001. Disponível em:
http://www.psphome.hpg.ig.com.br/downloads/Apostila_curso_GCS.pdf. Acesso em:
29 set. 2003.
Osterweil, L. J. Understanding process and the quest for deeper questions in software
engineering research. In: ______. ACM SIGSOFT Software Engineering Notes. New
York, USA: ACM Press, Sept. 2003. v.28, p.6-14.
Osterweil, L. J. Software processes are software too. In: International Conference on
Software Engineering, 9., Monterey, California, USA, Mar 1987. Proceedings… Los
Alamitos: IEEE Computer Society Press, 1987. p.2-13.
249
Project Management Institute (PMI). A guide to the project management body of
knowledge. Charlotte N. C: Project Management Institute, 1996. 216p.
Pressman, R. Software engineering - a practioner’s approach. 3.ed. New York:
McGraw Hill, 1992. 880p.
Rocha, A.N.C.; Maldonado, J. C.; Weber, K. C. Qualidade de software: teoria e
prática. São Paulo: Prentice-Hall, 2001.
Rochkind, M. J. The source code control system. IEEE Transactions on Software
Engineering, v.4, p.364-370, 1975.
Sant’Anna, N.; Cereja Jr., M. G.; Borrego Filho, L. F.; Luque, L.; Casilo, B. H. eWebProject - um ambiente integrado para o apoio ao desenvolvimento e gestão de
projetos de software, Congresso Internacional de Tecnologia de Software: Qualidade e
Produtividade no Gerenciamento de Projetos, 13., Curitiba, Brasil, jun. 2002. Anais...
Curitiba, 2002. p.163-174.
Sant'Anna, N. Um ambiente integrado para apoio ao desenvolvimento e gestão de
projetos de software para sistemas de controle de satélites. 2000. 225p. (INPE-8306TDI/765). Tese (Doutorado em Computação Aplicada) – Instituto Nacional de
Pesquisas Espaciais, São José dos Campos, 2000.
Sant’Anna, N.; Lahoz, C.; Abdala, M. Um ambiente integrado para suporte a projetos
de engenharia de software. In: Comdex, Ago. 2003, São Paulo. Tutorial... São Paulo,
2003.
Sayko, M. Creating an SCM Plan to support iterative software development.
Crossroads News, Feb. 2003. Disponível em:
http://www.cmcrossroads.com/newsletter/articles/msfeb03.html. Acesso em: 2 fev.
2003.
Schleicher, A.; Westfechtel, B.; Jäger, D. Modeling dynamic software process in UML.
In: Technical Report AIB 98-11, RWTH Aachen, Germany, 1998.
250
Schleicher, A.; Westfechtel, B. Beyond stereotyping: metamodeling approaches for the
UML. In: Hawaiian International Conference on System Sciences (HICSS-34), 34.,
Island of Maui, 2001. Proceedings… Los Alamitos: IEEE Computer Society Press,
2001, v.3, p.3051.
Sharon, D.; Anderson, T. A complete software engineering environment. IEEE
Softwa re, p.123-127, Mar./Apr. 1997.
Software Process Engineering Metamodel Specification (SPEM ), Version 1.0,
Needham, USA: Object Management Group, formal 02-11-14, Nov. 2002.
Sommerville, I. Software engineering. 6.ed. Reading: Person Education Limited, 2001.
693p.
Software Process Improvement and Capability dEtermination (SPICE). Software
Process Assessment – Part 2, A model for process management, Version 1.0, 1995.
Starbuck, R. A. Software Configuration Management: don’t buy a tool first. CrossTalk
– The Journal of Defense Software Engeneering, Nov 1997. Disponível em:
http://www.stsc.hill.af.mil/crosstalk/1997/11/index.html. Acesso em: 2 jun. 2003.
Tichy, W. F. RCS - A System for Version Control. Software - Practice and
Experience, v.15, n.7, p.637-654, 1985.
Unhelkar, B. Process quality assurance for UML-based projects. Boston, USA:
Addison-Wesley, Oct. 2002. 432p.
Van Brunt, E. Implementing a Flexible Software Configuration Management
Process. Software Engineering II (Relatório Técnico), 1996. Disponível em:
www.ecse.rpi.edu/Courses/S96/35678/vanBrunt.ps. Acesso em: 2 ago. 2002.
Van Der Hoek, A.; Hall, R. S.; Heimbigner, D.; Wolf, A. L. Software Release
Management. In: European Conference on the Foundations of Software Engineering, 6.,
1997. Proceedings… New York: Springer-Verlag, 1997. p.159-175.
251
Van Der Hoek, A.; Heimbigner, D.; Wolf, A. L. Does configuration management
research have a future?. In: Lecture Notes In Computer Science, Selected papers from
the ICSE SCM-4 and SCM-5 Workshops, on Software Configuration Management.
London: Springer-Verlag, 1995. v.1005, p.305 – 309.
Van Der Hoek, A.; Mikic-Rakic, M.; Roshandel, R.; Medvidovic, N.,Taming
Architectural Evolution. In: European Software Engineering Conference, 8., ACM
SIGSOFT international symposium on Foundations of software engineering, 9.,
(ESEC/FSE), Vienna, Austria, 2001. Proceedings… New York: ACM Press, 2001. p.110.
Van Der Lingen, R.; Van Der Hoek, A. Dissecting Configuration Management Policies.
In: ICSE Workshop SCM 2003, Portland, OR, USA, May 2003. Proceedings…
Springer-Verlag GmbH, 2003. v.2649, p.177-190.
White, B. Software Configuration Management Strategies and Rational
ClearCase®: A Practical Introduction. Boston: Addison Wesley Professional, 2000.
336p.
Zamli, K. Z.; Lee, P. A. Ta xonomy of process modeling languages. In: International
Conference on Computer Systems and Applications, Beirut, June 2001. Proceedings…
IEEE Digital Library, 2001. p.435-437.
252
BIBLIOGRAFIA COMPLEMENTAR
Berczuk, S. Pragmatic Software Configuration Management. IEEE Software , p.15-17,
Mar. 2003.
Kidd, C. The case for configuration management. IEEE Review, p.37-41, Sept. 2001.
Lyon, D. Practical CM: best configuration management practices for the 21st
century. 3.ed. Pittsfield: RAVEN Publishing Company (Electronic Version), Jan. 2001.
174p.
Marshall, A. Software configuration management: function or discipline?, STSC
Crosstalk, Oct. 1995. Disponível em:
http://www.stsc.hill.af.mil/crosstalk/1995/10/index.html. Acesso em: 9 abr. 2002.
Mikkelsen, T.; Pherigo, S. Practical Software Configuration Management : The
latenight Developers´s Handbook. New Jersey, USA: Prentice Hall, 1997. 301p.
Vanhanen, J. Improving configuration management processes of a software
product. 1997. 62p. Thesis (Master) - Department of Computer Science, Laboratory of
Information Processing Science, Helsinki University of Technology, Helsinki, 1997.
Westfechtel, B; Conradi, R. Software Architecture and Software Configuration
Management. In: International Workshop on Software Configuration Management, 10.,
(SCM-10), Toronto, Canadá, May 2001. Proceedings… Toronto: IEEE Computer
Society, 2001. p.19-26.
Westfechtel, B; Munch, B. P.; Conradi, R. A layered architecture for uniform version
management, IEEE Transactions on Software Engineering, v.27, n. 12, p.1111-1133,
Dec. 2001.
253
254
APÊNDICE A
A UTILIZAÇÃO DO SPEM NA MODELAGEM DE PROCESSOS 1
Neste trabalho, as atividades da GCS identificadas foram agrupadas em um Diagrama
de Pacote (Package Diagram) composto por outros pacotes, da mesma forma que uma
Discipline. Isto permitiu representar, em alto nível, o agrupamento de atividades
correlatas do processo da GCS.
Aspectos dinâmicos do processo foram representados através de Diagramas de
Atividades, com os respectivos fluxos de produtos de trabalho, nos seus diversos
estados assumidos durante o processo.
WorkDefinitions foram utilizadas em um Diagrama de Caso de Uso para representar
grupos de Activities. Esta pode ser uma maneira útil para encapsular as atividades de um
processo, tornando o diagrama menor e mais fácil de ser visualizado.
A utilização dos Diagramas de Caso de Uso, no entanto, pode não ser muito adequado
para documentar modelos de processos com um grande número de atividades. A
principal razão é que para qualquer processo de tamanho significativo, o Diagrama de
Caso de Uso rapidamente se torna grande e difícil de ser navegado. Na realidade, sua
utilização depende do nível de abstração em que as atividades são modeladas. No caso
da abordagem apresentada neste trabalho foi feita uma definição em alto nível.
O SPEM 1.0 não oferece uma notação padronizada para representação dos processos,
nem exige que o modelador se prenda à notação UML. Pode-se, então, utilizar os
diagramas da UML como se apresentam na linguagem, ou adaptá-los para utilização
própria e usar a semântica padrão da UML para elementos como as dependências, por
exemplo, entre outros.
1
O material contido neste Apêndice foi baseado em uma apresentação (Process Engineering and
Modeling, SPIN de Montreal, Nov 2003) fornecida por Vivienne Suen, da Osellus Inc. e também em emails trocados com a mesma, a respeito da utilização do SPEM. Vivienne trabalha em Análise de
Sistemas e Consultoria de Processos e tem feito apresentações sobre modelagem e automação de
processos em reuniões do SPIN (Software Process Improvement Network ) no Canadá. Participou da
finalização do SPEM 1.0 e trabalha atualmente na definição da próxima versão do SPEM.
255
Uma outra abordagem para a modelagem de um processo completo de software consiste
na utilização de uma lista hierárquica de alto nível da Work Breakdown Structure
(WBS), como por exemplo:
Phase: Requisitos
Iteration: Primeira Iteração de Análise
WorkDefinition: Identificar Requisitos
Activity: Reunir requisitos dos envolvidos, etc.
WorkDefinition: Refinar Requisitos
Etc.
Diagramas de atividade, como definidos pela UML ou adaptados a uma maneira
particular de utilização, podem ser empregados para modelar a WBS, em diferentes
níveis de abstração: o primeiro mostraria as Fases, o segundo mostraria um
detalhamento da primeira Fase, e assim por diante.
Resumidamente, o metamodelo SPEM consistem em:
•
Elementos básicos: External Description, Guidance.
•
Dependências: Categorizes, Impacts, Import, Precedes, RefersTo, Trace.
•
Estrutura
de
Processo:
WorkProduct,
WorkDefinition,
Activity,
Step,
ProcessRole.
•
Componentes de Processo: Package, ProcessComponent, Process, Discipline.
•
Ciclo de vida do Processo: Lifecycle, Phase, Iteration, Precondition, Goal.
Uma WBS é modelada com Lifecycles, Phases, Iterations, WorkDefinitions e Activities.
Os artefatos e papéis são modelados como WorkProducts e ProcessRoles,
respectivamente entradas/saídas e performers/assistants para as Atividades.
Os Packages podem ser utilizados para se obter modularidade dos processos e facilitar a
reutilização dos mesmos.
256
Pode-se também começar a modelagem com elementos concretos – WorkProducts
(deliberables) e ProcessRoles.
Os WorkProducts são os artefatos de um processo – qualquer pedaço tangível de
informação produzido, consumido ou modificado pelo processo. Podem estar em
qualquer formato ou meio e WorkProductKinds podem ser utilizados para distingui- los.
Os produtos de trabalho podem ser agregações de outros e terem máquinas de estados
para descrever sua dinâmica no processo.
Os ProcessRoles não são descrições ou títulos de trabalho, nem pessoas, mas sim um
conjunto significativo de habilidades e responsabilidades a serem desempenhadas no
processo. Os ProcessRoles têm uma classe pai, o ProcessPerformer. No SPEM não
existem associações entre ProcessRoles e WorkDefinitions. A idéia é que os
ProcessPerformers deveriam ser associados a WorkDefinitions (e Iterations, Phases,
Lifecycles). Os ProcessPerformers (PP) podem ter sido introduzidos para integridade do
modelo, de maneira que um ProcessRole tivesse uma classe pai assim como uma
WorkDefinition (WD) é a classe pai de uma Activity. Por exemplo, um PP bem genérico
pode ser descrito, como “Time de Análise” e ser designado como o executante de
Iterations, etc. Isto pode ser feito quando já existe na organização um conceito muito
forte de responsabilidades abstratas e de alta granularidade que ainda podem ser
decompostas em tarefas discretas, do tipo de uma Activity. Assim, neste caso, o “Time
de Análise” pode ser designado para uma iteração, e as sub-atividades designadas para
serem executadas por ProcessRoles, como Analistas de Sistema, Arquitetos de
Software, etc. Deve-se ressaltar que, como a associação WD-PP não é obrigatória, não
existe a necessidade de agrupar os ProcessRoles apenas para formar um
ProcessPerformer no modelo, pois nem sempre existe uma correspondência entre os
dois.
A WBS de um modelo de processo descreve o trabalho a ser executado e o fluxo geral
de atividades. O SPEM identifica um conjunto de elementos da WBS, em níveis
variados de detalhe: Lifecycle, Phase, Iteration, WorkDefinition e Activity.
257
O elemento de mais baixo nível da WBS é a Activity. Uma Activity é um pedaço de
trabalho executado por um único ProcessRole. Não existem regras com relação ao
“tamanho” de uma Activity, somente que deve ser uma tarefa de um único ator com um
ProcessRole evidente que a executa, com um número qualquer de assistentes. Portanto,
o “tamanho” das Activities é grandemente influenciado pelo “tamanho” dos seus
ProcessRoles. Não existem requisitos para o número de passos (Steps) das atividades:
pode-se ter nenhum ou muitos, e, é importante ressaltar, que o fluxo de passos poderia
ser representado por gráficos de atividade da UML. Assim, uma Activity de alto nível de
abstração poderia encapsular um fluxo bem complicado de eventos nos seus passos. Os
WorkProducts são as entradas e saídas para uma Activity, através de uma classe de
associação.
Já como elementos de mais alto nível na WBS tem-se: WorkDefinitions, que descrevem
um conjunto composto de Activities; Iterations, que são WorkDefinitions compostas
com um marco (milestone) menor no projeto; Phases, que delimitam o espaço de tempo
entre dois marcos (que têm critérios de entrada e saída específicos), sem sobreposição; e
Lifecycle, que descreve o comportamento de um processo completo a ser executado em
um projeto em particular (série de Phases).
O fluxo de trabalho pode ser definido com a utilização de Preconditions, Goals e
Precedes na construção da WBS. A combinação de regras baseadas no término das
atividades e em condições é um recurso flexível e poderoso. Preconditions e Goals são
expressos em termos de estados dos WorkProducts. Expressões booleanas podem ser
utilizadas, como:
Documento de Arquitetura == aprovado && Modelo de Caso de Uso == pronto
A dependência Precede pode ser: Fim-Início, Fim-Fim, Início-Início. As Phases, por
exemplo, são ligadas através de dependências do tipo Fim-Início, já que não podem se
sobrepor.
Uma comparação entre fluxos de trabalho, com estas representações pode ser vista na
FIGURA A.1:
258
FIGURA A.1- Comparação entre Fluxos de Trabalho.
As dependênc ias Impacts podem ser utilizadas para demonstrar as dependências de
produtos de trabalho e a dependência Trace pode ser utilizada para rastrear o fluxo dos
requisitos do sistema por todo o modelo.
Guidances não são WorkProducts, nem são produzidas ou modificadas pelo processo.
Um artefato não pode ser Guidance e WorkProduct no mesmo processo. Qualquer
elemento pode ter qualquer número de Guidances associadas. Guidances devem ter um
GuidanceKind: Technique, UMLProfile, Checklist, ToolMentor, Guideline, Template,
Estimate, Technology Roadmap).
Uma vez tendo o modelo definido no nível elementar/estrutural, o gerenciamento do
modelo ajuda a facilitar o caminho para a adequação e evolução do processo.
Os Packages do SPEM, como na UML, são recipientes que tanto podem possuir como
importar elementos de definição de processo. Um ProcessComponent é um pedaço de
descrição de um processo que é auto-contido e internamente consistente, e pode ser
composto. Um Process é um processo completo. Uma Discipline é uma especialização
de um Package usado para categorizar as Activities de acordo com um tema comum,
como foi feito nesta dissertação com a GCS.
259
260
APÊNDICE B
EXERCÍCIO DE MODELAGEM – PROCESSO DE GERENCIAMENTO DAS
MODIFICAÇÕES
Process: Gerenciamento das Solicitações de Modificação
Subactivities
Activity: Identificar e Registrar Solicitação de Modificação
ProcessRole: Responsável pela GCS
ActivityParameters {kind : input}
WorkProduct: Relatório de Ocorrência
ActivityParameters {kind : output}
WorkProduct: Solicitação de Modificação
{state: Aberta}
Steps
Step: Registrar data da abertura
Step: Registrar identificação única da Solicitação de
Modificação
Step: Registrar identificação do Projeto/Subsistema
Step: Registrar identificação do Item de Configuração
Step: Referenciar Relatório de Ocorrência que originou a
solicitação
Step: Estabelecer relacionamentos com outras Solicitações de
Modificação
Step: Registrar tipo de modificação
Step: Registrar sugestões de solução
Step: Encaminhar
SM
ao
Presidente
do
GCC
Activity: Avaliar Modificação
ProcessRole: Presidente do GCC
{state: Aberta}
Guidance: Guia para avaliação de impacto da
modificação
{kind : checklist }
{state: Sob Avaliação}
Steps
261
Conduzir a avaliação do impacto da modificação,
cumprindo o check-list de Avaliação de Impacto da
Modificação
Step: Avaliar recursos necessários
Step: Avaliar benefícios da modificação
Step: Registrar resultado da avaliação
Step: Atribuir prioridade à Solicitação de Modificação
Step:
Activity: Aprovar modificação
{state: Sob Investigação}
{state: Aprovada para Implementação/Rejeitada}
Steps
Step: Verificar existência de recursos
Step: Aprovar SM de acordo com o resultado da avaliação e
prioridade dada ou Rejeitar a SM
Step: Registrar parecer
Activity: Agendar modificação
{state: Aprovada para Implementação}
{state: Encaminhada para Implementação/Adiada}
Steps
Step: Verificar adequação ao orçamento e disponibilidade dos
recursos
Step: Definir detalhes da implementação
Activity: Registrar Implementação da Modificação
ProcessRole: Responsável pelo Produto
{state: Aprovada para Implementação}
262
{state: Implementada}
Steps
Step: Registrar informações da implementação
Activity: Registrar Resultado da Avaliação de Item Modificado
ProcessRole: Responsável pela Qualidade
{state: Implementada}
{state: Verificada}
Steps
Step: Registrar parecer da avaliação
Activity: Revisar Modificação Implementada
ProcessRole: Membro do GCC
{state: Verificada}
{state: Fechada}
Steps
Step: Registrar parecer da verificação da implementação
Activity: Relatar Situação das Modificações
ProcessRole: Responsável pela GCS
{state: Fechada}
WorkProduct: Relatório de Controle de Modificação
Steps
Step: Emitir Relatório de Controle de Modificação
263
264
APÊNDICE C
TELAS DO PROTÓTIPO SOFTWARE CHANGE AND CONFIGURATION
MANAGEMENT - SCM
Neste Apêndice apresentam-se as telas extraídas do protótipo “Change and Configuration
Management” – SCM. O protótipo visa apresentar funcionalidades da GCS no Ambiente, e,
principalmente, representar a seqüência das atividades que cada papel deve desempenhar no
processo de gerenciamento das solicitações de modificação e o registro das informações
relacionadas a estas atividades na Solicitação de Modificação (SM).
A FIGURA C.1 apresenta a tela de trabalho do usuário, com as notícias (janela News)
remetidas ao mesmo. Observa-se o recurso que permite a qualquer usuário participar das
atividades da GCS, através da opção Change and Configuration Management (tela
Cooperative Tools). A barra de opções Support (barra à direita mais acima) permite o
acesso dos envolvidos com a GCS, entre eles os membros do GCC, às atividades de
gerenciamento da configuração e gerenciamento das solicitações de modificação. A opção
ProjectManagement, dá acesso ao Gerente das Modificações e da Configuração às suas
atividades.
265
FIGURA C.1 - Tela de Trabalho do Usuário.
A FIGURA C.2 ilustra a tela referente às opções ProjectManagement que, entre outros
serviços permite o acesso do Gerente das Modificações e da Configuração às atividades de
gerenciamento da GCS.
266
FIGURA C.2 – Tela de Acesso do Gerente das Modificações e da Configuração.
A FIGURA C.3 ilustra a tela inicial das atividades de definição de estratégias
organizacionais e do planejamento da GCS, denominadas Definir Estratégias e Planejar a
GCS.
267
FIGURA C.3 – Tela Inicial das Atividades do Gerente das Modificações e da
Configuração.
268
As FIGURAS C.4 e C.5 apresentam telas referentes às opções de definição de estratégias
da GCS para o projeto selecionado, mostrando algumas convenções para identificação de
itens de configuração e para formação de um GCC durante a fase de desenvolvimento, na
organização. O menu de abas permite também outras opções, que são: objetivo e escopo da
GCS, procedimentos e convenções para as atividades da GCS, desenvolvimento paralelo,
métricas e planejamento da GCS.
FIGURA C.4 – Tela de Convenção para Identificação Única para Documentos.
269
FIGURA C.5 - Tela de Convenções para Formação dos GCCs.
270
A FIGURA C.6 ilustra a tela referente à lista de projetos instanciados para a atividade de
planejamento da GCS com algumas informações pertinentes ao projeto e com a
possibilidade de inclusão ou exclusão desta atividade pelo usuário responsável.
FIGURA C.6 - Tela Referente à Lista de Projetos Instanciados.
271
A FIGURA C.7 apresenta a tela referente às opções de planejamento da GCS para o projeto
selecionado, mais especificamente mostra a opção da tela de escolha dos membros do GCC
na fase de desenvolvimento. Isto permitirá a inclusão destes membros nas listas de
comunicação das reuniões do GCC. Este menu de abas permite também outras opções do
planejamento da GCS para definição de: relações com o ambiente de projeto; atividades de
identificação da configuração, armazenamento e controle, avaliação da configuração,
controle das modificações e relato da situação; ferramentas, técnicas e métodos; linhas de
desenvolvimento; tarefas, fases e marcos da GCS e ambiente da GCS.
FIGURA C.7 - Tela de Escolha de Membros para o GCC-Des.
272
A FIGURA C.8 ilustra a tela referente às opções de Support que, entre outros serviços
permite o acesso dos envolvidos às atividades de gerenciamento da configuração e das
modificações.
FIGURA C.8 - Tela de Acesso dos Envolvidos com a GCS.
273
A FIGURA C.9 ilustra a tela inicial do Responsável pela GCS, que apresenta as opções de
gerenciamento das modificações e da configuração disponíveis. Nesta tela aparece mais à
esquerda a opção de abertura de uma Solicitação de Modificação (Abrir SM), atividade
inicial do Gerenciamento das Solicitações da Modificação.
FIGURA C.9 - Tela Inicial da Atividade de Gerenciamento das Solicitações de
Modificação.
274
A FIGURA C.10 ilustra a tela de acompanha mento das SMs abertas no Ambiente, referente
à opção Abrir SM. Como o Responsável pela GCS não abriu uma SM ainda, o número de
registros é zero. Esta tela possui alguns campos, como identificação e status da SM para um
melhor acompanhamento do processo.
FIGURA C.10 - Tela de Acompanhamento das SMs.
275
A FIGURA C.11 ilustra a tela do Formulário de Solicitação de Modificação, mostrada
quando o usuário insere um novo formulário de SM, que contém as informações relativas à
SM aberta pelo Responsável pela GCS, referente ao relatório de ocorrência recebido
(EWPJ_RO_001). Ao final da tela, o usuário tem a opção de “Encaminhar” ou “Cancelar”
o encaminhamento da SM ao Presidente do GCC.
FIGURA C.11 - Tela de Abertura da SM.
276
A FIGURA C.12 ilustra a tela de acompanhamento das SMs encaminhadas após a abertura
pelo Responsável pelo GCS. O campo status mostra a situação do produto após esta
primeira atividade do processo.
FIGURA C.12 - Tela de Acompanhamento das SMs com o Status atualizado para
“Aberta”.
277
A FIGURA C.13 ilustra a tela referente às atividades do GCC, que incluem a avaliação, o
agendamento da modificação, o registro da aprovação pela qualidade e o fechamento das
FIGURA C.13 - Tela Inicial das Atividades do GCC.
278
A FIGURA C.14 ilustra a tela de acompanhamento das SMs abertas e encaminhadas para
avaliação no Ambiente. Esta tela possui alguns campos, como identificação e status da SM
para um melhor acompanhamento do processo.
FIGURA C.14 - Tela de Acompanhamento das SMs Encaminhadas para Avaliação.
279
A FIGURA C.15 ilustra uma tela referente à atividade de avaliação da modificação,
acessível após selecionar o link da SM. Nela são registradas as informações referentes aos
resultados da ava liação da SM pelo GCC, como o esforço estimado para realização da
modificação, o impacto da modificação e o parecer. Ao final da tela, não visível na figura, o
usuário tem a opção de “Aprovar” ou “Rejeitar” a Solicitação de Modificação, após
registrar o parecer da avaliação e observações.
FIGURA C.15 - Tela de Avaliação da Modificação.
280
A FIGURA C.16 ilustra a tela de acompanhamento das SM após a aprovação pelo
Presidente do GCC. O campo status mostra a situação do produto após esta atividade do
processo.
FIGURA C16 - Tela de Acompanhamento das SM com o Status
“Aprovada para Implementação”.
281
Atualizado para
As FIGURAS C.17 e C.18 ilustram algumas telas da atividade de agendar a solicitação de
modificação. A tela inicial mostra as SMs que foram aprovadas para implementação. A
seguir, aparece a tela onde são acrescentadas as informações pertinentes ao
encaminhamento da SM para o Responsável pelo Produto ou outro desenvolvedor
designado para implementação da modificação. Estas informações serão apresentadas após
ativar o link referente à SM na tela inicial. Após a SM ser encaminhada para
implementação ela tem seu status atualizado para "Encaminhada para Implementação".
FIGURA C.17 - Tela Inicial da Atividade de Agendar SM.
282
FIGURA C.18 - Tela da Atividade Agendar SM.
A FIGURA C.19 ilustra a tela referente a algumas atividades do Cliente da GCS, que
incluem o registro da implementação das modificações nos itens de configuração e a
obtenção de itens de configuração para utilização.
283
FIGURA C.19 - Tela Inicial das Atividades Cliente da GCS.
As FIGURAS C.20 e C.21 ilustram as telas referentes ao registro da implementação da
modificação no item de configuração pelo Responsável pelo Produto. A tela inicial do
cliente da GCS, que no caso é o Responsável pelo Produto ou desenvolvedor, apresenta as
SMs que foram encaminhadas para implementação. Após a implementação da modificação
no item, que foi disponibilizado pelo Responsável pela GCS na sua área de trabalho, o
desenvolvedor deve encaminhar o item modificado para aprovação da modificação pela
284
Qualidade, registrar na SM as informações pertinentes e encaminhá- la. Depois disto, a SM
tem seu status atualizado para "Implementada".
FIGURA C.20 - Tela Inicial do Registro da Impleme ntação da Modificação.
285
FIGURA C.21 - Tela da Atividade Registro da Implementação da Modificação.
As FIGURAS C.22 e C23 ilustram as telas referentes ao registro da aprovação da
modificação no item de configuração pela qualidade. A tela inicial apresenta as SMs que
foram implementadas e aguardam aprovação pela qualidade. Após as atividades de
avaliação e revisão, a aprovação da qualidade deve ser registrada na SM, através da
referência aos relatórios das atividades de aprovação do item modificado, conforme a
FIGURA C.23. Para isto, o Presidente do GCC deve ter acesso ao relatório da aprovação do
286
item que deve ser referenciado na SM. Depois disto, a SM deve ter seu status atualizado
para "Verificada".
FIGURA C.22 - Tela Inicial do Registro da Aprovação da Modificação pela Qualidade.
287
FIGURA C.23 - Tela da Atividade Registro da Aprovação pela Qualidade.
As FIGURAS C.24 e C.25 ilustram as telas relativas ao fechamento da SM, após a revisão
da modificação implementada pelo GCC. São registradas na SM as informações referentes
288
ao fechamento da SM, e após a ativação da opção "Fechar", o status da SM é atualizado
para "Fechada".
FIGURA C.24 - Tela Inicial do Fechamento da SM.
289
FIGURA C.25 - Tela de Fechamento da SM.
290
A seguir são apresentadas algumas figuras mostrando exemplos de registros que devem ser
feitos durante as atividades de Gerenciamento da Configuração, como os registros das
modificações e das distribuições, e também um exemplo de relatório da configuração.
Registro de Histórico das Modificações
Identificação do Item de Configuração:
Responsável pela Modificação:
SM Associada:
Data: 20/01/2004 - 10:03:22
Descrição da Modificação:
FIGURA C.26 - Registro de Histórico das Modificações.
291
Registro de Solicitação de Liberação
Identificação da Distribuição:
Solicitante:
Data: 20/01/2004
Selecionar itens:
Responsável pela Distribuição: MADA
Descrição da Distribuição:
Registrar
Cancelar
FIGURA C.27 - Registro de Solicitação de Liberação.
Lista de Composição de Item
Configuração-Base: EWPJ_CBProduto 1.1
Marco de Projeto: Término dos Testes de Integração
Versão: 1.1
Data: __/__/_____
Responsável: RBP
Item de Configuração
Versão Estado
Data
Responsável
EWPJ_ERS.DOC
1.4
Controlado 10/11/2003
LAN
EWPJ_EPD.DOC
1.3
MRA
EWPJ_PPJ.DOC
2.3
JLM
....
Subsistema EWPJ_XXXX
>>>Componente EWPJ_Comp_A
1.3
..............
...
....
......
FIGURA C.28 - Lista de Composição.
292

Uma abordagem para a gerência das modificações e da

Transcrição

Documentos relacionados

TREMORES EM CÃES - ABORDAGEM E TRATAMENTO Ronaldo

americatv

Visualizar/Abrir - Repositório UNIFEI

Apresentação 1 - Universidade Católica Editora

Superslot Cl ássicos na Slot

Circuito Regional

Artigo Completo - LivrosOdonto.com.br

Transair®, redes de ar comprimido inteligentes

condiciones cancelacion PERU pt.indd

ODYSSEY-CCS: UMA ABORDAGEM PARA O - Introdução