Publicações do PESC Ambientes de Engenharia de Software Orientados a Corporação

(1)

(2)

SOUZA, GLEISON DOS SANTOS

Ambientes de Engenharia de Software Orientados a Corporação [Rio de Janeiro] 2008

XIX, 319 p. 29,7 cm (COPPE/UFRJ, D.Sc., Engenharia de Sistemas e Computação, 2008)

Tese - Universidade Federal do Rio de Janeiro, COPPE

1. Ambientes de Desenvolvimento de Software 2. Processos de Software

3. Qualidade de Software

(3)

AGRADECIMENTOS

À minha família pelo apoio e compreensão.

À Ana Regina, por acreditar em mim, pela orientação, pelas muitas oportunidades de aprendizado durante todos estes anos e pela amizade.

A Guilherme pela amizade, pela orientação, por acreditar no meu trabalho e por ter-me feito olhar com outros olhos quando preciso.

À Káthia pelo apoio e amizade desde o início do meu projeto final de curso, o que me proporcionou chegar até aqui.

A Mariano, Mariella e Carmem pelo tempo de trabalho na Embratel e por terem me incentivado a iniciar o doutorado.

A Karina pelo apoio e incentivo no final do mestrado e no início do doutorado. A todos os amigos que passaram pelo Laboratório de Engenharia de Software (LENS) da COPPE/UFRJ neste período, pelo aprendizado e oportunidades de trabalho. Em especial Ana Candida, André, Anne, Cristina, David, Gustavo Barbosa, Gustavo Coutinho, Mariano, Paula, Peter, Reinaldo, Rômulo Coutinho, Sávio e Sômulo. Aos companheiros de doutorado Adriano, Ahilton, Andrea, Fábio, Leonardo Murta, Monalessa e Tayana.

Aos amigos que compartilharam comigo várias angústias, alegrias, ausências, descontentamento e aspirações ao longo de todo o tempo, em especial a Thadeu, Mariano Jonice e Mônica.

A Luciano e Rafael por terem trabalhado para a construção da primeira versão da Estação Taba na Web. A Cristina e Peter por terem continuado e evoluído o trabalho. A Gustavo Barbosa, Gustavo Coutinho, Rômulo Coutinho e Reinaldo por terem contribuído decididamente para a implementação das ferramentas.

Aos professores Cláudia Werner, Geraldo Xexéo, Karin Breitman e Renata Araújo, por aceitarem contribuir com este trabalho participando da banca.

A Ricardo Falbo pelo auxílio sempre que foi preciso.

À Taisa Guidini, Ângela Coppieters, Ana Paula Prata, Claudia Prata, Solange, Sônia, Mercedes, Flávia e demais funcionários do PESC pelo auxílio, sempre que necessário. Aos demais professores do programa, pelo aprendizado proporcionado ao longo das disciplinas. Aos membros dos Centros de Computação da Aeronáutica em São José dos Campos e Brasília por contribuírem na realização do exemplo de uso deste trabalho.

(4)

Resumo da Tese apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Doutor em Ciências (D.Sc.)

AMBIENTES DE ENGENHARIA DE SOFTWARE ORIENTADOS A CORPORAÇÃO

Gleison dos Santos Souza

Julho/2008

Orientadores: Ana Regina Cavalcanti da Rocha Guilherme Horta Travassos

Programa: Engenharia de Sistemas e Computação

Esta tese propõe os Ambientes de Engenharia de Software Orientados a Corporação (AESCorp) como sendo ambientes de engenharia de software que fornecem o apoio computacional que possibilita a uma corporação, em relação aos processos de software, gerenciar a diversidade e os estágios de maturidade de cada uma das organizações que a compõem de forma adequada às suas necessidades através da definição de ambientes que apóiam a execução, gerência e melhoria dos diversos processos de Engenharia de Software, que incluem, mas não se limitam aos de desenvolvimento e de manutenção. Esse apoio computacional, também, permite às corporações e organizações serem capazes de gerenciar e controlar os diversos processos de software de que dispõem e/ou necessitam, bem como o conhecimento organizacional envolvido através da configuração de ambientes para corporações e, a partir desses, para as organizações que as compõem. Além disso, esta tese propõe um modelo que especifica os componentes necessários para que tais ambientes contemplem os seus requisitos. Por fim, uma estratégia para a construção de AESCorps a partir de um meta-ambiente foi definida, implementada e utilizada, evidenciando o apoio fornecido pelas ferramentas desenvolvidas.

(5)

Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Doctor of Science (D.Sc.)

CORPORATE-ORIENTED SOFTWARE ENGINEERING ENVIRONMENTS

Gleison dos Santos Souza

July/2008

Advisors: Ana Regina Cavalcanti da Rocha Guilherme Horta Travassos

Department: Computer Science and System Engineering

This thesis defines Corporate-Oriented Software Engineering Environments (COSEE) as software engineering environments that provides corporations the computational support to manage software processes diversity and maturity of its subordinated organizations. COSEE also allows the definition of environments to support the enactment, management and improvement of the software engineering processes involved. This computational support also allows corporations and organizations to manage and control their software processes and knowledge involved through the configuration of specific environments. Finally, a strategy for the construction of COSEE from a meta-environment was defined, implemented and used demonstrating the support provided by the tools developed.

(6)

ÍNDICE

Capítulo 1 - Introdução ...1 1.1 Motivação...1 1.2 Cenário...2 1.3 Objetivo...4 1.4 Organização do Texto...6

Capítulo 2 - Melhoria de Processos de Software ...8

2.1 Processos de Software...8

2.2 Normas e Modelos de Qualidade de Processos de Software ...11

2.2.1 Norma ISO/IEC 12207...11

2.2.2 Norma ISO/IEC 15504...13

2.2.3 CMMI-DEV...14

2.2.4 MPS.BR...16

2.3 Melhoria de Processos de Software em Organizações ...18

2.4 Melhoria de Processos de Software em Corporações...19

2.5 Diversidade de Processos de Software ...24

2.6 Considerações Finais ...25

Capítulo 3 - Infra-estrutura para Iniciativas de Melhoria de Processos de Software27 3.1 Introdução...27

3.2 Apoio Ferramental a Iniciativas de Melhoria de Processos...28

3.3 Ambientes para Apoio a Iniciativas de Melhoria de Processos...33

3.3.1 Ambientes de Desenvolvimento da COPPE/UFRJ...36

3.3.1.1 Estação Taba ...36

3.3.1.2 CORE-KM: Um Ambiente Customizável de Gerência de Conhecimento...43

3.3.2 Outros Ambientes...44

Capítulo 4 - Ambientes de Engenharia de Software Orientados a Corporação ...50

4.1 Introdução...50

4.2 Evoluindo de Ambientes de Desenvolvimento de Software para Ambientes de Engenharia de Software...52

(7)

4.2.2 Execução de Processos...54

4.2.3 Melhoria de Processos ...54

4.2.4 Gerência dos Ativos de Processos...55

4.2.5 Gerência de Conhecimento ...55

4.2.6 Requisitos de um Ambiente de Engenharia de Software ...56

4.3 Evoluindo de Ambientes Orientados a Organização para Ambientes Orientados a Corporação...56

4.3.1 Definição de Processos...57

4.3.4 Gerência dos Ativos de Processos...59

4.3.6 Disponibilização de Infra-estrutura ...60

4.3.7 Requisitos de um Ambiente Orientado a Corporação...61

4.4 Modelo para Construção de Ambientes de Engenharia de Software Orientados a Corporação...62

4.4.1 Definição e Geração de Ambientes...63

4.4.1.1 Meta-Ambiente ...64

4.4.1.2 Ambiente Corporativo...65

4.4.1.3 Ambiente Organizacional...65

4.4.1.4 Ambiente de Projeto ...65

4.4.1.5 Ambientes de Engenharia de Software Orientados a Corporação ...66

4.4.2 Definição de Processos...66

4.4.2.1 Definição de Processos para a Corporação ...69

4.4.2.2 Definição de Processos para a Organização...71

4.4.2.3 Definição de Processos para os Projetos ...71

4.4.3.1 Melhoria de Processos Determinada pela Corporação ...73

4.4.3.2 Melhoria de Processos em Projetos em Execução ...75

4.4.5 Gerência de Ativos de Processo...78

4.4.5.1 Controle de versão...78

(8)

4.4.5.3 Rastreabilidade de versões e mudanças...80

4.4.5.4 Bases de Ativos de Processo e Base de Versões de Ativos de Processo...81

Capítulo 5 - Definição e Construção de Ambientes de Engenharia de Software Orientados a Corporação na Estação Taba ...83

5.1 Introdução...83

5.2 Funções e Ambientes da Estação Taba ...83

5.3 Requisitos dos Ambientes da Estação Taba ...85

5.4 Ontologia de Corporação ...89

5.4.1 Organização e Corporação...90

5.4.2 Processo Padrão, Processo Especializado e Processo Definido para o Projeto...91

5.4.3 Ativo de Processo...94

5.5 Arquitetura da Estação Taba e dos Ambientes de Engenharia de Software Orientados a Corporação...95

5.5.1 Histórico de Evolução da Arquitetura da Estação Taba ...95

5.5.1.1 A Arquitetura da Estação Taba de 1990 a 1999...96

5.5.1.2 Arquitetura da Estação Taba de 1999 a 2003 – Implementação dos ADSOD...98

5.5.1.3 Arquitetura da Estação Taba de 2003 a 2007 – Implementação dos ADSOrg...99

5.5.2 A Implementação Atual da Estação Taba em Plataforma Web... 101

5.5.2.1 A Estação Taba na Web ... 102

5.5.2.2 Arquitetura Atual da Estação Taba... 106

5.5.2.3 Integração de Gerenciamento e Controle... 108

5.5.2.4 Integração de Apresentação e Interação ... 113

5.5.2.5 Integração de Dados – Mapeamento Objeto-Relacional na Estação Taba... 114

5.5.2.6 Integração de Dados – Repositórios dos Ambientes... 114

5.5.2.7 Integração de Conhecimento... 115

5.5.3 Avaliação do Modelo de Integração da Estação Taba... 116

(9)

5.6.1 Processo do Escritório de Projetos da Estação Taba ... 117

5.6.2 Processo de Desenvolvimento ... 118

5.6.3 Estratégia de Versionamento... 119

5.6.4 Ferramentas de Apoio ... 120

5.7 Modelo para Construção dos Ambientes de Engenharia de Software Orientados a Corporação na Estação Taba... 120

5.7.1 Gerência de Ambientes ... 121

5.7.2 Gerência de Processos... 125

5.7.3 Gerência de Ativos de Processos... 128

5.7.4 Gerência de Execução de Processos ... 130

5.7.5 Gerência de Conhecimento ... 132

5.8 Cenário de Uso dos Ambientes de Engenharia de Software Orientados a Corporação... 133

5.8.1 Iniciativa de Melhoria de Processos na Aeronáutica... 134

5.8.2 Apoio Ferramental ... 135

5.8.3 Resultados da Iniciativa de Melhoria de Processos... 144

5.9 Considerações Finais ... 144

Capítulo 6 - Conclusão e Perspetivas Futuras... 145

6.1 Conclusão... 145

6.1.1 Contribuições... 146

6.2 Perspectivas Futuras ... 147

Referências ... 149

Anexo I - Linguagem para Modelagem de Processos Organizacionais ... 170

1 Introdução... 170

2 Linguagem para Modelagem de Processos Organizacionais... 172

Referências Bibliográficas ... 179

Anexo II - Perfil UML para Modelagem de Ontologias ... 180

1 Perfil UML para Modelagem de Ontologias... 180

(10)

Anexo III - Estudo Baseado em Revisão Sistemática – Infra-estrutura de Apoio A

Iniciativas de Melhoria de Processos de Software ... 183

2 Protocolo do Estudo Baseado em Revisão Sistemática ... 185

2.1 Contexto... 185

2.2 Objetivo e Questões de Pesquisa ... 185

2.2.1 Objetivo... 185

2.2.2 Questões de pesquisa ... 186

2.3 Escopo da pesquisa ... 187

2.3.1 Critérios adotados para seleção das fontes... 188

2.3.2 Restrições ... 188

2.4 Idiomas... 188

2.5 Métodos de Busca de Publicações... 189

2.5.1 Expressão de Busca ... 189

2.5.2 Busca Manual... 190

2.6 Procedimentos de Seleção e Critérios... 190

2.6.1 Procedimentos de Seleção ... 190

2.6.2 Critérios de Inclusão... 195

2.7 Procedimentos para Extração dos Dados... 195

2.7.1 Na seleção e catalogação preliminar dos dados coletados... 195

2.7.2 Na seleção dos dados relevantes... 195

2.7.3 Extração de Dados ... 195

2.7.4 Sumarização dos resultados... 197

2.8 Procedimentos para Análise ... 197

2.8.1 Análise Quantitativa ... 197

2.8.2 Análise Qualitativa ... 198

3 Planejamento e Execução... 198

3.1 Definição do Escopo e Estudos Preliminares... 198

3.2 Identificação de Publicações de Controle e Palavras-Chave ... 199

3.2.1 Primeira Rodada... 200

3.2.2 Segunda Rodada... 200

3.2.3 Terceira Rodada ... 202

3.3 Definição das Máquinas de Busca ... 202

(11)

3.3.2 Expressão de Busca na Biblioteca Digital da IEEE ... 203

3.3.3 Expressão de Busca na Biblioteca Digital da Scopus ... 203

3.3.4 Instrumento para Consulta Manual... 203

3.4 Identificação do Período de Busca... 204

3.5 Execução do Protocolo... 205

3.6 Considerações sobre o Resultado do Estudo ... 207

3.6.1 Caracterização das Organizações... 208

3.6.2 Caracterização do Apoio Ferramental ... 210

4 Apoio Ferramental para Condução do Estudo ... 212

4.1 Análise da Expressão de Busca... 212

4.2 Análise das Publicações... 213

4.3 Relatórios ... 214

5 Dados Coletados... 215

5.1 Dados das Publicações Dentro do Escopo do Estudo... 216

5.2 Dados das Publicações Selecionadas a Partir das Palavras-Chave... 239

5.3 Dados das Publicações Selecionadas no Primeiro Filtro ... 253

Anexo IV - Ontologia de organização ... 260

2 Definição e Formalização da Ontologia... 261

2.1 Subontologia de Capital Intelectual... 264

2.1.1 Taxonomia de Competência ... 264

2.1.2 Interação entre Experiência e Conhecimento ... 265

2.1.3 Disponibilidade de Competências... 265

2.1.4 Decomposição de Domínio de Conhecimento... 266

2.2 Subontologia de Estrutura... 267

2.2.1 Decomposição da Organização ... 267

2.2.2 Distribuição de Autoridade e Responsabilidade entre Unidades Organizacionais... 269

2.2.3 Decomposição de Unidade Organizacional... 271

2.2.4 Distribuição de Autoridade e Responsabilidade entre Posições... 271

2.2.5 Especificação de Cargos e Posições... 272

(12)

2.2.7 Definição de Objetivos ... 273

2.3 Subontologia de Artefatos... 276

2.3.1 Decomposição de Artefato... 277

2.3.2 Taxonomia de Artefato... 277

2.4 Subontologia de Comportamento ... 280

2.4.1 Atividade como Ação de Transformação... 280

2.4.2 Taxonomia de Atividade... 281

2.4.3 Decomposição de Processo e Atividade ... 283

2.4.4 Subtipos de Processo... 285

2.4.5 Adoção de Procedimento ... 287

2.4.6 Taxonomia de Procedimento... 288

2.4.7 Método como Procedimento Sistemático... 289

2.4.8 Automatização de Procedimento ... 290

2.4.9 Processos definidos na Organização e Normas Associadas... 291

2.4.10Projetos da Organização ... 291

2.4.11Ativos de Processo ... 292

2.5 Subontologia de Estratégia Geral ... 293

2.5.1 Domínios de Atuação... 294

2.5.2 Artefatos e Serviços oferecidos pela Organização... 294

2.5.3 Relação com Organizações Clientes... 294

Anexo V - Especificação de Requisitos ... 298

1 Necessidades do Cliente ... 298

2 Modelo de Domínio ... 299

2.1 Gerência de Ambientes... 299

2.2 Gerência de Ativos de Processos ... 299

2.3 Gerência de Organização... 300

2.4 Gerência de Processos ... 300

2.5 Gerência de Execução de Processos... 301

3 Requisitos do Cliente... 301

(13)

4 Requisitos Funcionais de Software... 304

5 Caso de Uso e Processos de Apoio... 308

(14)

ÍNDICE DE TABELAS

Tabela 2.1 – Níveis de Capacidade dos Processos da Norma ISO/IEC 15504 (ISO/IEC,

2003) ...14

Tabela 2.2 – Áreas de Processo do CMMI-DEV ...15

Tabela 2.3 – Processos e Atributos de Processo do MPS.BR...17

Tabela 5.1 – Requisitos da Estação Taba e de seus Ambientes...86

Tabela 5.2 – Requisitos de Arquitetura do Produto da Estação Taba... 103

Tabela 5.3 – Solução Atual para Implementação dos Principais Requisitos de Arquitetura do Produto da Estação Taba... 104

Tabela 5.4 – Repositórios Presentes nos AESCorp ... 115

Anexo I Tabela 1 – Definição e Notação dos Objetos ... 172

Tabela 2 – Definição e Notação dos Adornos... 174

Tabela 3 – Definição e Notação das Áreas... 174

Tabela 4 – Definição e Notação das Ligações... 175

Anexo III Tabela 1 – Padrão para Descrição do Uso de Apoio Ferramental em Iniciativas de Melhoria de Processos ... 208

Tabela 2 – Artigos Selecionados pelas Palavras-Chave... 239

Tabela 3 – Artigos Lidos Após Aplicação do Primeiro Filtro ... 253

Anexo V Tabela 1 – Requisitos de Cliente da Gerência de Ambientes... 302

Tabela 2 – Requisitos de Cliente da Gerência de Ativos de Processos ... 302

Tabela 3 – Requisitos de Cliente da Gerência de Organização... 303

Tabela 4 – Requisitos de Cliente da Gerência de Processos ... 303

Tabela 5 – Requisitos de Cliente da Gerência de Execução de Processos... 304

Tabela 6 – Requisitos Funcionais – Gerência de Ambientes... 304

Tabela 7 – Requisitos Funcionais – Gerência de Ativos de Processos... 305

Tabela 8 – Requisitos Funcionais – Gerência de Organização... 306

(15)

Tabela 10 – Requisitos Funcionais – Gerência de Execução de Processos... 307

Tabela 11 – Casos de uso do processo Definir Ambientes Configurados... 309

Tabela 12 – Casos de uso do processo Definir Ambientes de Projetos... 309

Tabela 13 – Casos de uso dos processos Alterar Ambientes Corporativos, Alterar Ambientes Organizacionais e Alterar Ambientes de Projetos... 310

Tabela 14 – Casos de uso do processo Definir Base de Ativos de Processos... 311

Tabela 15 – Casos de uso do processo Gerenciar Base de Ativos de Processos ... 312

Tabela 16 – Casos de uso dos processos Descrever Corporação e Descrever Organização ... 315

Tabela 17 – Casos de uso do processo Manter Cadastros... 315

Tabela 18 – Casos de uso do processo Definir Processos e seus subprocessos ... 317

Tabela 19 – Casos de uso do processo Adaptar Processo para o Projeto ... 317

Tabela 20 – Requisitos de Produto da Estação Taba... 318

(16)

ÍNDICE DE FIGURAS

Figura 2.1 – Framework para promoção das Atividades de Melhoria de Processos na

Toshiba (OGASAWARA et al., 2006) ...21

Figura 3.2 – Esquema para Construção de ADS na Estação Taba...38

Figura 4.3 – Geração de Ambientes...64

Figura 4.4 – Abordagem para Definição de Processos (VILLELA, 2004) ...67

Figura 4.5 – Definição de Processos para a Corporação ...70

Figura 4.6 – Definição de Processos para a Organização...71

Figura 4.7 – Definição de Processos para Projetos ...72

Figura 4.8 – Legenda para o cenário de melhoria...73

Figura 4.9 – Uso dos processos pelos projetos e melhoria de processos na Organização ...74

Figura 4.10 – Uso do processo evoluído em novos projetos...74

Figura 4.11 – Avaliação e melhoria dos processos pela Corporação ...75

Figura 4.12 – Evolução dos processos organizacionais a partir de decisão corporativa...75

Figura 4.13 – Legenda para o cenário de melhoria para processos em execução ...76

Figura 4.14 –Processos em execução na organização ...76

Figura 4.15 –Implantação de melhoria em projetos em execução ...76

Figura 5.16 – Ambientes da Estação Taba...85

Figura 5.17 – Relações entre Organização e Corporação ...90

Figura 5.18 – Subtipos de processos segundo a natureza do processo ...92

Figura 5.19 – Conceitos derivados de Processo...94

Figura 5.20 – Serviços Básicos da Estação Taba... 107

Figura 5.21 – Detalhes de Implementação da Estação Taba na Web e dos AESCorp... 108

Figura 5.22 – Componentes do Meta-Ambiente... 110

Figura 5.23 – Serviços dos Ambientes Corporativos e Organizacionais... 111

Figura 5.24 – Serviços dos Ambientes de Projetos... 112

Figura 5.25 – Padronização de Interface... 113

Figura 5.26 – Visão Geral do Processo do Escritório de Projetos... 118

Figura 5.27 – Notação dos Diagramas de Requisitos... 121

Figura 5.28 – Definição de Ambientes Configurados – Requisitos e Casos de Uso... 122

Figura 5.29 – Definição de Ambientes de Projeto – Requisitos e Casos de Uso... 123

Figura 5.30 – Definição de Ambiente Configurado – Processo de Apoio ... 124

(17)

Figura 5.32 – Definição de Ambiente de Projeto – Processo de Apoio ... 124

Figura 5.33 – Definição de Processos Padrão e Especializados – Requisitos e Casos de Uso ... 126

Figura 5.34 – Definição de Processos Definidos para o Projeto – Requisitos e Casos de Uso... 127

Figura 5.35 – Biblioteca de Ativos de Processos – Requisitos e Casos de Uso ... 129

Figura 5.36 – Gerência de Versão de Ativos de Processos – Requisitos e Casos de Uso . 130 Figura 5.37 – Execução de Processos nos Ambientes de Projeto – Requisitos e Casos de Uso... 131

Figura 5.38 – Definição da Estrutura Organizacional I – Requisitos e Casos de Uso ... 132

Figura 5.39 – Definição da Estrutura Organizacional II – Requisitos e Casos de Uso ... 133

Figura 5.40 – Definição de Ambiente Configurado – Definir Ambiente Configurado ... 135

Figura 5.41 – Definição de Ambiente Configurado – Caracterizar Contexto de Configuração ... 136

Figura 5.42 – Definição de Ambiente Configurado – Selecionar Ativos de Processos ... 138

Figura 5.43 – Definição de Ambiente Configurado – Gerar Ambiente Configurado... 138

Figura 5.44 – Definição de Processos Especializados – Implementação... 139

Figura 5.45 – Descrição da Estrutura Organizacional da Corporação – Implementação . 140 Figura 5.46 – Biblioteca de Ativos de Processos - Implementação ... 141

Figura 5.47 – Gerência de Configuração de Ativos de Processos - Implementação... 141

Figura 5.48 – Definição de Ambiente de Projeto – Implementação ... 142

Figura 5.49 – Execução de Processos nos Ambientes de Projeto - Implementação... 143

Anexo I Figura 1 - Primitivas utilizando a Notação do Diagrama de Atividade UML... 178

Figura 2 - Primitivas utilizando a Notação Proposta... 179

Anexo II Figura 1 – Perfil UML (MIAN, 2003) ... 180

Anexo III Figura 1 – Quadro com Palavras-Chave ... 205

Figura 2 – Quadro para Controle de Pesquisa Manual ... 205

(18)

Figura 4 – Artigos Retornados que Passaram pelo Primeiro Filtro ... 207

Figura 5 – Artigos Retornados que Passaram pelo Segundo Filtro... 208

Figura 6 – Tamanho das Organizações ... 210

Figura 7 – Agregação das Organizações na Iniciativa de Melhoria de Processos... 210

Figura 8 – Influência de Modelos, Normas, Técnicas ou Métodos ... 211

Figura 9 – Abrangência do Apoio Ferramental... 212

Figura 10 – Agregação das Ferramentas Utilizadas ... 212

Figura 11 – Uso de Apoio Ferramental... 213

Figura 12 – Tela de Teste de Expressão de Busca... 214

Figura 13 – Transformação de Arquivo no Formato BibTeX para BibXML ... 215

Figura 14 – Formulário de Coleta de Informações... 216

Figura 15 – Relatório Final do Estudo Baseado em Revisão Sistemática ... 217

Figura 16 – Relatório Auxiliar para Análise de Abstracts ... 217

Anexo IV Figura 1 – Subontologias da Ontologia de Organização ... 263

Figura 2 – Subontologia de Capital Intelectual ... 264

Figura 3 – Decomposição da Organização... 268

Figura 4 – Distribuição de Autoridade e Responsabilidade ... 269

Figura 5 – Esquema das Estruturas adotadas nas Organizações... 270

Figura 6 – Decomposição de Unidade Organizacional... 271

Figura 7 – Distribuição de Autoridade e Responsabilidade ... 272

Figura 8 – Especificação de Cargos e Posições... 272

Figura 9 – Preenchimento de Vagas e Formação de Equipe ... 273

Figura 10 – Definição de Objetivos... 274

Figura 11 – Subontologia de Artefatos... 277

Figura 12 – Subontologia de Comportamento - Atividade como Ação de Transformação ... 281

Figura 13 – Taxonomia de Atividade quanto ao Papel... 282

Figura 14 – Taxonomia de Atividade quanto à Natureza... 283

Figura 15 – Decomposição de Processo e de Atividade... 284

Figura 16 – Subtipos de processos segundo a natureza do processo... 286

Figura 17 – Conceitos derivados de Processo... 288

(19)

Figura 19 – Taxonomia de Procedimento... 289

Figura 20 – Método como Procedimento Sistemático... 290

Figura 21 – Automatização de Procedimento ... 291

Figura 22 – Processos definidos na Organização e Normas Associadas... 292

Figura 23 – Projetos da Organização... 292

Figura 24 – Subontologia de Estratégia Geral... 294

Anexo V Figura 1 – Diagrama de domínio da Gerência de Ambientes... 299

Figura 2 – Diagrama de domínio da Gerência de Ativos de Processos ... 300

Figura 3 – Diagrama de domínio da Gerência de Organização... 300

Figura 4 – Diagrama de domínio da Gerência de Processos ... 301

Figura 5 – Diagrama de domínio da Gerência de Execução de Processos... 301

Figura 6 – Processo Definir Ambientes Configurados ... 308

Figura 7 – Processos Definir Ambientes de Projetos ... 309

Figura 8 – Processos Alterar Ambientes Corporativos, Alterar Ambientes Organizacionais e Alterar Ambientes de Projetos... 310

Figura 9 – Processo Definir Base de Ativos de Processos ... 311

Figura 10 – Processo Gerenciar Base de Ativos de Processos ... 312

Figura 11 – Processos Descrever Corporação e Descrever Organização - 1 ... 313

Figura 12 – Processos Descrever Corporação e Descrever Organização - 2 ... 314

Figura 13 – Processo Manter Cadastros... 315

Figura 14 – Processo Definir Processos e seus subprocessos ... 316

(20)

CAPÍTULO 1 - INTRODUÇÃO

1.1 Motivação

Uma característica cada vez mais comum no cenário de desenvolvimento de software é a existência de corporações com organizações subordinadas que desenvolvem software de forma independente entre si. Estas organizações muitas vezes possuem diferentes necessidades e realidades em relação ao desenvolvimento de software, por exemplo, nichos de mercado com características diferentes ou diferentes níveis de maturidade; corporações em que uma das organizações tem o desenvolvimento de software aderente a um modelo de maturidade e as demais desenvolvem software de forma ad hoc; ou ainda, corporações cujas organizações tenham seus processos institucionalizados em níveis distintos de maturidade e capacidade.

A variação destes processos se dá geralmente em função do tamanho do produto a ser desenvolvido (por exemplo, projetos de curta, média e longa duração) ou tipo de produto (por exemplo, desenvolvimento de software, desenvolvimento de software e hardware, desenvolvimento de softwares para web etc.). Os processos também podem ser influenciados pela adoção de métodos, técnicas ou abordagens de desenvolvimento. Neste aspecto, entretanto, a adoção de modelos de maturidade como o MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2007) e o CMMI (Capability Maturity Model Integration) (CHRISSIS et al., 2006) desempenha papel importante ao influenciar a implementação de diversas práticas e em diferentes níveis de rigor, algo que é, de certa forma, intrínseco à filosofia dos níveis de maturidade e capacidade. O CMMI consiste de boas práticas que tratam do desenvolvimento e manutenção de produtos e serviços cobrindo o ciclo de vida de um produto desde a concepção até a entrega e a manutenção. O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro e tem como objetivo definir um modelo de melhoria e avaliação de processo de software, preferencialmente para as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e a ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software.

Outro fator que tem aumentado a complexidade do desenvolvimento de software ao longo do tempo é o número de processos que são executados para a conclusão de um projeto de software. Organizações desenvolvedoras de software têm necessidade de executar diversos processos integrados ao processo de desenvolvimento para a execução de

(21)

um projeto de software (por exemplo, processos de apoio, como Garantia de Qualidade) e, também, processos executados de forma independente dos processos de desenvolvimento em si, mas também relacionados à produção de software ou gerência e estruturação do desenvolvimento (por exemplo, processos como Aquisição e Gerência de Projetos de Melhoria).

A existência de diversidade de processos não é exclusividade de organizações envolvidas com desenvolvimento de software ou com grandes departamentos relacionados a TI. A General Motors, por exemplo, recentemente fez com que seus principais fornecedores de serviços de TI (dentre eles EDS, HP e IBM, com unidades espalhadas pelo mundo) se comprometessem a utilizar 44 processos padrão desenvolvidos e utilizados por ela relacionados a várias tarefas de TI (WEIER e MURPHY, 2007). A gerência de processos em grandes organizações envolve lidar com grupos e processos com diferentes características dentro da organização. Por exemplo, a estrutura do grupo corporativo responsável pelos processos de engenharia de software da Toshiba era composto em 2005 por 20 pessoas e se relacionava hierarquicamente ou colaborativamente com cerca de 60 outros grupos de organizações subordinadas ou unidades organizacionais (OGASAWARA et al., 2006).

Além disso, de acordo com a importância das iniciativas de melhoria de processos para as organizações serem competitivas e, também, nas dificuldades que as organizações têm em implementar tais iniciativas devido ao custo e tempo necessários, é preciso realizar programas de melhoria mais acessíveis para a maior parte das organizações independentemente das características de cada organização (AMESCUA et al., 2006). Uma forma de reduzir os custos associados com uma iniciativa de melhoria de processos de software é adotar ferramentas adequadas para automatizar certas tarefas e, assim, reduzir o esforço necessário para realizá-las. É comum em relatos sobre fatores de sucesso e dificuldades relacionadas à execução de iniciativas de melhoria de processos (NIAZI et al., 2005; SANTOS et al., 2007a) a identificação da necessidade de uma infra-estrutura adequada como um importante fator de sucesso. De fato, grande parte das organizações com baixos níveis de maturidade não possuem uma infra-estrutura adequada para iniciar a iniciativa de melhoria de processos de software (SANTOS et al., 2007a).

1.2 Cenário

Com o crescimento, uma empresa de software tende a aumentar e mudar sua estrutura organizacional, se comportando como uma corporação, ou seja, passa a ser uma

(22)

organização composta de outras organizações (por exemplo, subsidiárias ou filiais) com certo grau de independência, mas subordinadas, de alguma forma, aos interesses e regras corporativas. O que difere uma corporação de uma organização é o fato de haver uma relação de hierarquia entre as organizações que compõem a corporação e a direção central da corporação. Esta relação de hierarquia pode estar configurada de diversas formas, por exemplo, ser uma relação apenas administrativa, sendo as organizações unidades independentes com ramos de negócio particulares, ou então ser uma relação de comando e gerência das atividades fins da organização, estando as organizações subordinadas a uma linha mestra definida pela corporação. Neste segundo caso, é comum, também, que estas organizações tenham ramos de atuação semelhantes e compartilhem alguns nichos de mercado, mas em contextos ou localidades diferentes.

Além disso, conforme a organização aumenta de tamanho, é possível que a variedade de tipos de processos também aumente de acordo com as características dos novos projetos ou com as necessidades específicas de determinados clientes ou mercados em que atua. Por exemplo, atualmente são comuns organizações com equipes diferentes em fábricas de programas (contemplando apenas a construção e, às vezes, parte do projeto de software) e/ou fábricas de software (contemplando todo o ciclo de vida de desenvolvimento de um software, desde o levantamento de requisitos até a entrega para o cliente).

Em uma corporação, a diversidade de processos se torna mais evidente à medida que as organizações subordinadas podem adotar um conjunto variado de processos. E estes processos, apesar de se basearem num modelo padrão (por exemplo, específico para uma fábrica de software) podem sofrer adaptações decorrentes de necessidades diferentes. Por exemplo, organizações que tem um modelo de desenvolvimento de fábrica de software e processos compatíveis com diferentes níveis de modelos de maturidade.

A premissa principal que auxilia no entendimento do escopo e motivação deste trabalho é que organizações independentes, corporações e organizações subordinadas a corporações e têm diferentes necessidades de infra-estrutura para a implantação de um programa de melhoria de processos de software.

Nesta configuração, a gerência e monitoração da corporação sobre os processos de software podem ultrapassar os limites físicos de uma organização. Dessa forma, em vez de gerenciar ou monitorar como uma organização está gerenciando seus processos como um todo, pode gerenciar ou monitorar, por exemplo, como todas as equipes que compõem Fábricas de Software estão tendo seus processos evoluídos para atingir e manterem-se

(23)

aderentes a um determinado nível de maturidade. Neste caso, a monitoração realizada pela corporação passa a ser sobre os processos e não sobre as organizações.

Para este trabalho interessam as corporações cujas organizações desenvolvem software e compartilham uma linha de comando delineada pela corporação no que tange seus programas de melhoria de processos de software. Também no contexto deste trabalho, uma corporação é considerada como tendo um papel fundamentalmente gerencial em relação às atividades de software desempenhadas pelas organizações. Desta forma, assume-se, por exemplo, que não há desenvolvimento de software na corporação, que estas atividades são desempenhadas apenas nas organizações. Além disso, assume-se que as organizações tenham estruturas hierárquicas internas independentes entre si e que a cadeia de comando entre a corporação e as organizações esteja restrita à elaboração e execução das iniciativas de melhoria de processos em cada organização.

1.3 Objetivo

O objetivo deste trabalho é descrever os Ambientes de Engenharia de Software Orientados a Corporação (AESCorp). Tais ambientes fornecem o apoio computacional que possibilita a uma corporação, em relação aos processos de software, gerenciar a diversidade e os estágios de maturidade de cada uma das organizações que a compõem de forma adequada às suas necessidades através da definição de ambientes de apoio à execução e à gerência dos processos de Engenharia de Software, que incluem, mas não se limitam aos de desenvolvimento e de manutenção. Além disso, esse apoio computacional permite às corporações e organizações serem capazes de gerenciar e controlar os diversos processos de software de que dispõem e/ou necessitam, bem como o conhecimento organizacional envolvido através da configuração de ambientes para corporações e, a partir desses, para as organizações que as compõem.

A definição e construção dos Ambientes de Desenvolvimento de Software Orientados a Organização (VILLELA, 2004) supriu a necessidade de se apoiar a utilização do conhecimento organizacional e não só o conhecimento de domínio provido por especialistas (conforme identificado por OLIVEIRA (1999)), durante o desenvolvimento de software e, também, a necessidade de se apoiar o desenvolvimento de software em uma organização em particular. Entretanto, esta abordagem também possui limitações ao não apoiar outros processos que não os de desenvolvimento e manutenção e considerar apenas a existência de organizações independentes.

(24)

Dessa forma, os Ambientes de Engenharia de Software Orientados a Corporação visam a suprir estas limitações e podem ser considerados uma evolução dos Ambientes de Desenvolvimento de Software Orientados a Organização em dois sentidos:

(i) Evolução de Ambientes de Desenvolvimento de Software para Ambientes de Engenharia de Software, que envolve definir ambientes para outros processos além do de desenvolvimento e de manutenção, apoiando também a execução e a gerência de quaisquer processos de Engenharia de Software; e

(ii) Evolução de Ambientes Orientados a Organização para Ambientes Orientados a Corporação, que envolve configurar ambientes para corporações e, a partir desses, para as organizações que as compõem.

Estas duas evoluções não são concorrentes, mas sim complementares. Num sentido horizontal, o espectro de processos apoiado pelos ambientes é expandido, tornando possível a existência dos mais diversos tipos de processos de software (por exemplo, fornecimento, aquisição, treinamento, avaliação e melhoria, medição etc.). Por outro lado, num sentido vertical, cria-se um novo nível de hierarquia (ou seja, um nível corporativo além do organizacional e do de projetos) para cada processo de software individualmente, além de, em decorrência disso, possibilitar novos níveis de controle para gerenciar tanto a diversidade de processos quanto os níveis hierárquicos envolvidos.

Apesar de as organizações que compõem a corporação poderem estar geograficamente distribuídas, não serão discutidos no contexto deste trabalho aspectos relacionados ao desenvolvimento de software por equipes distribuídas (por exemplo, (AUDY e PRIKLADNICKI, 2007)) nem possíveis diferenças culturais que possam afetar a forma de trabalho nas organizações (por exemplo, (SIAKAS e GEORGIADOU, 2002)).

Este trabalho também não pretende discutir os aspectos gerenciais necessários para uma adequada gerência das atividades de melhoria de processos de software em corporações e organizações, discorrendo, por exemplo, sobre lições aprendidas ou propondo métodos ou diretrizes para a implantação de iniciativas de melhoria de software neste contexto. O foco principal está na identificação de requisitos e itens que devam compor a infra-estrutura computacional necessária para a condução de uma iniciativa de melhoria de processos de software no contexto corporativo. Dessa forma, sempre que o termo infra-estrutura é mencionado no texto desta tese, salvo observação em contrário, ele representa a infra-estrutura computacional (composta por ferramentas, ambientes, instrumentos de apoio etc.) que é necessária para apoiar uma iniciativa de melhoria de

(25)

processos de software, isto exclui, por exemplo, necessidades específicas relacionadas a disponibilidade de pessoas capacitadas ou de recursos financeiros.

1.4 Organização do Texto

Este capítulo introdutório apresentou a motivação e o cenário de aplicação das idéias a serem apresentadas nesta tese. Estes tópicos serão refinados ao longo dos próximos capítulos. A organização do texto deste trabalho segue a estrutura abaixo:

• Capítulo II – Melhoria de Processos de Software: Descreve os conceitos

relacionados a melhoria de processo de software que de alguma forma tem relação com o tema da tese. Esta seção utiliza o resultado de um estudo baseado em revisão sistemática para descrever necessidades relacionadas a processos de software durante a execução de uma iniciativa de melhoria de processos de software em uma organização e/ou corporação.

• Capítulo III – Infra-estrutura para Iniciativas de Melhoria de Processos de

Software: Descreve exemplos de infra-estrutura necessária para a execução de

processos de software no contexto de uma iniciativa de melhoria de processos de software. Esta seção também utiliza o resultado de um estudo baseado em revisão sistemática para descrever necessidades de infra-estrutura para a execução de uma iniciativa de melhoria de processos de software em uma organização e/ou corporação.

• Capítulo IV - Ambientes de Engenharia de Software Orientados a

Corporação: Descreve as necessidades de uma corporação para a execução de seus

processos e os requisitos necessários para que seja provido um apoio ferramental que atenda a estas necessidades.

• Capítulo V – Definição e Construção de Ambientes de Engenharia de

Software Orientados a Corporação na Estação Taba: Descreve as mudanças

realizadas na Estação Taba para tornar possível a implementação da abordagem proposta. Além disso, apresenta a descrição de um cenário de uso dos Ambientes de Engenharia de Software Orientados a Corporação.

• Capítulo VI – Conclusão e Perspectivas Futuras: Contém as conclusões e

contribuições do trabalho, além de indicar possíveis trabalhos futuros.

• Anexo I – Linguagem para Modelagem de Processos Organizacionais:

Apresenta a linguagem de modelagem de processos utilizada em alguns dos diagramas presentes no texto desta tese.

(26)

• Anexo II – Perfil UML para Modelagem de Ontologias: Apresenta a linguagem

de modelagem de ontologias utilizada em alguns dos diagramas presentes no texto desta tese.

• Anexo III – Estudo Baseado em Revisão Sistemática – Infra-estrutura de

Apoio a Iniciativas de Melhoria de Processos de Software: Apresenta detalhes

do estudo baseado em revisão sistemática realizada dentro do escopo desta tese.

• Anexo IV – Ontologia de Corporação: Apresenta a versão completa da ontologia

de corporação definida no contexto desta tese a partir da atualização da ontologia de organização anterior.

• Anexo V – Especificação de Requisitos: Apresenta com mais detalhes o

levantamento de requisitos inicial para as principais funcionalidades dos AESCorp identificadas nesta tese.

(27)

CAPÍTULO 2 - MELHORIA DE PROCESSOS DE

SOFTWARE

Neste capítulo são apresentados conceitos relacionados a melhoria de processos de software, incluindo normas e modelos de qualidade de processos de software nacionais e internacionais. São apresentados também exemplos de iniciativas de melhoria de processos de software em organizações e corporações.

2.1 Processos de Software

Desenvolvimento de software não é apenas uma questão de criar ferramentas e linguagens de programação efetivas. O desenvolvimento de software é uma tarefa coletiva, complexa e criativa. Assim sendo, a qualidade do produto de software depende em grande parte das pessoas, da organização e dos procedimentos utilizados para criá-lo e disponibilizá-lo. A noção de um processo de software implica na noção de um ciclo de vida e provê um grande e abrangente conceito para enquadrar e organizar diferentes fatores e questões relacionadas às atividades de desenvolvimento de software (FUGGETTA, 2000).

Um processo pode ser definido como um conjunto de atividades estruturadas e destinadas a resultar em um artefato ou serviço de valor para a organização ou para um determinado cliente ou mercado e implica em uma ordenação específica das atividades com começo, fim, insumos e produtos claramente identificados (VILLELA, 2004). Um processo de software, por sua vez, pode ser definido como um conjunto de políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que são necessários para conceber, desenvolver, entregar e manter um produto de software (FUGGETTA, 2000) e também produtos associados, como planos do projeto, documentos de projeto, código fonte, casos de teste e manuais do usuário (PAULK et al., 1993b). Além disso, um processo de software independe da tecnologia utilizada no desenvolvimento e define o modo pelo qual o desenvolvimento de software é organizado, gerenciado, medido, apoiado e melhorado (MONTANGERO et al., 1999). Em todo caso, o processo deve ajudar a guiar as pessoas em relação ao que fazer sobre a divisão e coordenação dos trabalhos e garantir uma comunicação efetiva (LINDVALL e RUS, 2000).

O trabalho em processo de software apóia a construção da qualidade no software ao manter o foco em como o software é construído e avaliado. A comunidade de processos

(28)

de software trata o software como uma informação agregada complexa, intricada e interconectada que foi construído através da execução de um processo que deveria ser ordenado e sistemático. Um produto de software pode ser considerado de grande qualidade apenas quando se pode demonstrar que os artefatos que o constituem são consistentes entre si de diferentes formas. Infelizmente, no entanto, produtos de software são geralmente desenvolvidos utilizando processos ad hoc que geralmente residem na cabeça daqueles que os executam e supervisionam. Como conseqüência, projetos de software são geralmente mal coordenados, supervisionados inadequadamente e falham em entregar produtos que demonstrem grande qualidade. Tornar o processo de desenvolver software explícito pode ajudar a resolver muitos destes problemas e, de fato, parece que o aumento do rigor e detalhe das definições de processo de software leva um aumento na eficiência no desenvolvimento de produtos de software cuja qualidade é tanto assegurada como demonstrável (OSTERWEIL, 1996).

Segundo BOEHM (2006), ao traçar um panorama da engenharia de software, a partir do trabalho de OSTERWEIL (1996) que dizia que “processos de software também são software”, houve uma reorientação do foco dos ambientes de desenvolvimento de software além da exposição da dualidade entre práticas boas para desenvolver produtos e aquelas boas para o desenvolvimento de processos. Inicialmente, o foco foi em ferramentas e linguagens de programação, mas o conceito foi estendido para abranger insights úteis relacionados a requisitos de processos de software, arquitetura de processos, processo de gerência de mudança, família de processos, biblioteca de ativos de processos com componentes de processo reusáveis e passíveis de composição. Isso tudo permitiu a realização de maiores níveis de maturidade de processo de software com uma melhor relação custo-benefício (BOEHM, 2006).

Um dos primeiros modelos de maturidade a surgir, o SW-CMM (PAULK et al., 1993a) foi criado a partir de necessidades do Departamento de Defesa Americano (DoD) em identificar empresas capazes de desenvolver software e não aquelas que eram capazes de fazer boas propostas de desenvolvimento (BOEHM, 2006). Ao longo do tempo, muitas empresas têm relatado bom retorno de investimento devido à redução de retrabalho (BOEHM, 2006). Além desse, outros modelos de maturidade e normas internacionais voltados para processos de software surgiram com o passar do tempo. Cada vez mais, organizações são forçadas a aderir a restrições regulatórias que exigem a existência de processos explícitos e a demonstração da aderência a estes processos (MUNCH e VIERIMAA, 2006).

(29)

Segundo MUNCH e VIERIMAA (2006), atualmente dois tipos de abordagens para melhoria de processos de software são mais utilizados na prática: (i) abordagens contínuas (também mencionadas como abordagens orientadas a problemas) e (ii) abordagens baseadas em modelos (também mencionadas como abordagens orientadas a soluções). O escopo dos métodos e modelos de melhoria devem ser abrangentes o suficiente para considerar todos os diferentes fatores que afetam as atividades de desenvolvimento de software e, também, reutilizar experiências adquiridas em outros domínios de negócio e em pesquisas sobre o comportamento organizacional (FUGGETTA, 2000).

As abordagens contínuas (por exemplo, o PDCA (DEMING, 1986) e QIP (BASILI et al., 1994)) focam na seleção de problemas de uma organização de desenvolvimento de software e geralmente envolvem ciclos de melhoria com base na comparação com uma situação ou dados específicos. Uma importante vantagem dessa abordagem é o foco na resolução de problemas específicos ao analisar o problema em questão, implementando e observando ações de melhoria focadas em problemas e medindo os efeitos de tais ações. Entretanto, devido à sua natureza, é difícil criar uma percepção geral para as questões de qualidade em organizações muito grandes, com muitos colaboradores (MUNCH e VIERIMAA, 2006).

As abordagens baseadas em modelos (por exemplo, ISO/IEC 15504 (ISO/IEC, 2003) e CMMI (CHRISSIS et al., 2006)) comparam os processos e práticas correntes de uma organização contra um modelo de referência ou benchmark. Uma desvantagem desta abordagem é a de geralmente não avaliar o impacto das características do processo ou do produto e, por isso, não podem ser utilizadas para analiticamente identificar e lidar com os problemas dos processos que causam as deficiências nos produtos. Tipicamente é verificado se a prática ou processo está presente, mas seu impacto nos objetivos de negócio ou seu valor para a organização não é avaliado (MUNCH e VIERIMAA, 2006).

Segundo MUNCH e VIERIMAA (2006), no entanto, as abordagens contínuas e as baseadas em modelo podem ser vistas como complementares: as baseadas em modelos podem ser utilizadas para identificar áreas de problemas e opções potenciais de melhoria e as contínuas podem ser utilizadas para implementar e otimizar as soluções. Na prática, a questão típica não é se a melhoria de processos é necessária, mas como definir e implementar uma estratégia para introduzir melhoria avançada de processo passo a passo e como avaliar seu sucesso.

(30)

2.2 Normas e Modelos de Qualidade de Processos de Software

Modelos de Capacidade e Maturidade têm foco na melhoria de processos numa organização. Eles contêm os elementos essenciais de processos para uma ou mais disciplinas e descrevem um caminho evolucionário de melhoria partindo de processos ad hoc e imaturos até chegar a processos disciplinados e maduros com a melhora da qualidade e eficiência (CHRISSIS et al., 2006). Apesar de serem importantes mecanismos para fomentar definição, institucionalização e melhoria de processos de software em uma organização, os modelos de maturidade e normas internacionais não descrevem de fato os processos a serem seguidos pelas organizações. Padrões de engenharia de software apenas provêem referências normativas e estas referências não são diretamente aplicáveis em um processo de engenharia de software (EMMERICH et al., 1999). A definição destes processos deve ser feita respeitando as características da organização e depende de muitos fatores, incluindo o domínio da aplicação, a estrutura e o tamanho da organização (CHRISSIS et al., 2006).

Há algumas razões, no entanto, para que padrões de Engenharia de Software e melhoria de processos de software tenham ganhado mais atenção ao longo dos tempos, por exemplo (EMMERICH et al., 1999): (i) padrões são reconhecidos pela indústria de software como um meio de transferência de boas práticas em uso industrial; (ii) padrões garantem que o nível alvo de qualidade (associado com o padrão) foi seguido durante o desenvolvimento de software e é, por isso, refletido na qualidade do próprio software; (iii) padrões são usados como a base pela qual organizações e/ou produtos de software são certificados e/ou avaliados; finalmente, (iv) se duas organizações colaboram no desenvolvimento de um produto de software seguem os mesmos padrões, então a cooperação será consideravelmente simplificada.

Alguns exemplos de normas internacionais e modelos de maturidade utilizados pela indústria atualmente são o CMMI (Capability Maturity Model Integration) (CHRISSIS et al., 2006), MR MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2007), a norma ISO/IEC 12207 (ISO/IEC, 2008b) e a norma ISO/IEC 15504 (ISO/IEC, 2003) e serão descritos nas subseções a seguir.

2.2.1 Norma ISO/IEC 12207

A norma internacional ISO/IEC 12207 (ISO/IEC, 2008b) teve sua primeira versão editada em 1995 (ISO/IEC, 1995), posteriormente, duas evoluções foram elaboradas em 2002 (ISO/IEC, 2002) e 2004 (ISO/IEC, 2004) devido à evolução natural da Engenharia

(31)

de Software ao longo do tempo, ao retorno fornecido pelos seus usuários e, também, à necessidade de adequação à norma ISO/IEC 15504 (ISO/IEC, 2003) que trata da avaliação de processos de software.

A versão inicial da norma (ISO/IEC, 1995) agrupa as atividades que podem ser executadas durante o ciclo de vida de software em um conjunto de processos fundamentais, de apoio e organizacionais, além de um processo de adaptação para estes processos. Os processos fundamentais do ciclo de vida (Aquisição, Fornecimento, Desenvolvimento, Operação e Manutenção) atendem as partes fundamentais (ou seja, aquela que inicia ou executa o desenvolvimento, operação ou manutenção dos produtos de software) durante o ciclo de vida de software. Estas partes fundamentais são o adquirente, o fornecedor, o desenvolvedor, o operador e o mantenedor do software. Os processos de apoio de ciclo de vida (Documentação, Gerência de Configuração, Garantia da Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria e Resolução de Problema) auxiliam outro processo como uma parte integrante, com um propósito distinto, e contribui para o sucesso e qualidade do projeto de software. Um processo de apoio é empregado e executado quando necessário por outro processo. Os processos organizacionais de ciclo de vida (Gerência, Infra-estrutura, Melhoria e Treinamento) são utilizados por uma organização para estabelecer e implementar uma estrutura subjacente, constituída de processos de ciclo de vida e pessoas associados, e melhorar continuamente a estrutura e os processos. Eles são tipicamente empregados fora do domínio de projetos, entretanto contribuem para a melhoria da organização.

Com as duas revisões (ISO/IEC, 2002; ISO/IEC, 2004), novos processos foram definidos (Gerência de Ativos, Gerência de Pedidos de Mudança, Engenharia de Domínio, Recursos Humanos, Avaliação de Produto, Gerência de Programa de Reuso, Usabilidade), outros foram expandidos e para cada processo foram definidos um propósito e uma lista de resultados esperados.

A versão atual da norma (ISO/IEC, 2008b) integra a versão original com suas revisões (portanto, mantendo o alinhamento com a norma ISO/IEC 15504). Além disso, devido à abrangência do software (que indica que o software e seus processos de construção não devem ser considerados de forma separada daqueles processos relacionados a sistemas, mas, sim, como uma parte deles), também mantém o alinhamento com a norma ISO/IEC 15288 (ISO/IEC, 2008a) que descreve os processos de ciclo de vida de sistema.

(32)

A Norma não especifica os detalhes de como implementar ou executar as atividades e tarefas incluídas nos processos, nem prescreve um modelo específico de ciclo de vida ou método de desenvolvimento de software. As empresas podem adaptar os processos definidos na norma ISO/IEC 12207, de acordo com as particularidades dos seus projetos de software, utilizando o processo de adaptação. Por exemplo: DEMIRORS et al. (2000) descrevem a adaptação da norma para a definição de um processo de desenvolvimento de software para o governo da Turquia; SANTOS et al. (2005) descrevem a utilização da norma durante a definição de processos de software de desenvolvimento e manutenção adequado para pequenas e médias empresas brasileiras; SIQUEIRA e SILVA (2005) utilizam o processo gerencial definido pela norma para fazer um mapeamento com papéis gerenciais baseados no Rational Unified Process (RUP); HOYER e CHROUST (2006) apresentam uma análise da norma visando a identificação dos processos que necessitam de alguma adaptação para adequação ao desenvolvimento de uma linha de produtos. Além disso, como a ISO/IEC 12207 é o modelo de referência primário para a aplicação da norma ISO/IEC 15504, muitas das vezes é usada indiretamente em conjunto com essa norma, como, por exemplo, descrito por JABLONSKI e FAERBER (2007).

2.2.2 Norma ISO/IEC 15504

A norma ISO/IEC 15504 (ISO/IEC, 2003) provê um framework para a avaliação de processos de software que pode ser usado por organizações envolvidas com o planejamento, monitoração, controle, aquisição, fornecimento, desenvolvimento, operação, evolução e suporte a software. Este framework não provê um método único de avaliação de processos, mas todo um conjunto de requisitos que uma avaliação deve seguir para ter conformidade com a norma. O ganho resultante dessa abordagem é flexibilidade. Dessa forma podem existir diferentes modelos/métodos de avaliação, usando diferentes modelos de processo de referência, todos aderentes à norma.

A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de

(33)

decisão de contratá-lo ou não. A norma define seis níveis de capacidade, como pode ser visto na Tabela 2.1.

Tabela 2.1 – Níveis de Capacidade dos Processos da Norma ISO/IEC 15504

(ISO/IEC, 2003)

Nível Descrição

0 – Incompleto Processo não existe ou geralmente falha.

1 – Executado Processo atinge os objetivos, porém sem padrão de qualidade e sem controle de prazos e custos.

2 – Gerenciado Processo planejado e acompanhado. Satisfaz requisitos definidos de qualidade, prazo e custos. Seus produtos de trabalho são gerenciados.

3 – Estabelecido Processo executado e gerenciado com uma adaptação de um processo padrão, definido, eficaz e eficiente.

4 – Previsível Processo executado dentro de limites de controle definidos e com medições detalhadas e analisadas.

5 – Em Otimização Processo melhorado continuamente de forma disciplinada.

Exemplos de utilização da norma incluem a sua utilização como modelo para avaliação de processos em organizações e também como base para a definição de processos, como descritos, por exemplo, por CASS et al. (CASS et al., 2002), GUZMAN et al. (2006), CHOI et al. (CHOI et al., 2005), ANACLETO e von WANGENHEIM (2005), von WANGENHEIM et al. (2006) e COLETTA (2007).

2.2.3 CMMI-DEV

O CMMI (Capability Maturity Model Integration) (CHRISSIS et al., 2006) consiste de boas práticas que tratam do desenvolvimento e manutenção de produtos e serviços cobrindo o ciclo de vida de um produto desde a concepção até a entrega e a manutenção. O modelo é composto de 22 áreas de processo. Cada área contém práticas relacionadas que, quando implementadas, coletivamente satisfazem um conjunto de objetivos considerados importantes para fazer melhorias significativas nesta área.

Existem dois tipos de representação no CMMI: em estágios e contínua. A representação em estágios define um conjunto de áreas de processo para definir um caminho de melhoria para a unidade organizacional, descrito em termos de níveis de maturidade. Os possíveis níveis de maturidade da organização na representação por estágios são: 1 – Inicial; 2 – Gerenciado; 3 – Definido; 4 - Gerenciado Quantitativamente; 5 – Otimizado. A representação contínua (conforme é utilizada na norma ISO/IEC 15504) permite que uma organização selecione uma área de processo específica e melhore com relação a esta área. A representação contínua usa níveis de capacidade para caracterizar melhoria relacionada a uma área de processo. Os possíveis níveis de capacidade de uma área de processo são: 0 – Incompleto; 1 – Desempenhado; 2 – Gerenciado; 3 – Definido;

(34)

4 - Gerenciado Quantitativamente; 5 – Otimizado. A Tabela 2.2 apresenta a estrutura de cada nível do CMMI-DEV.

Tabela 2.2 – Áreas de Processo do CMMI-DEV Nível de

Maturidade Área de Processo

Monitoração e Controle do Projeto (PMC) Planejamento do Projeto (PP)

Gerência de Requisitos (REQM) Análise e Medição (MA)

Garantia da Qualidade do Processo e do Produto (PPQA) Gerência de Configuração (CM)

2

Gerência de Fornecedor Integrada (SAM) Gerência de Projeto Integrada (IPM) Gerência de Riscos (RSKM)

Definição do Processo Organizacional (OPD) Foco no Processo Organizacional (OPF) Treinamento Organizacional (OT) Desenvolvimento de Requisitos (RD) Integração do Produto (PI)

Solução Técnica (TS) Validação (VAL) Verificação (VER)

3

Análise de Decisão e Resolução (DAR) Gerência Quantitativa do Projeto (QPM)

4 _{Desempenho do Processo Organizacional (OPP)}

Inovação Organizacional e Posicionamento Estratégico (OID)

5

Resolução e Análise Causal (CAR)

O mapeamento entre as práticas do CMMI e os requisitos descritos na norma ISO/IEC 15504 ainda não é total, ajustes ainda precisam ser feitos (ROUT e TUFFLEY, 2007) apesar das alterações realizadas na versão 1.2 e de o SEI (órgão criador e mantenedor do CMMI) estar trabalhando para isso (SEI, 2008).

Os exemplos de utilização do CMMI (e de suas versões anteriores) são variados na literatura, por exemplo, (CHANWOO et al., 2004; FALBO et al., 2004; AGUIAR et al., 2005; DUARTE et al., 2005; MARCZAK et al., 2005; MOREIRA et al., 2005; PRIKLADNICKI et al., 2005; EKDAHL e LARSSON, 2006; GONÇALVES et al., 2006; GUERRA et al., 2006; MACEDO et al., 2006; MARINHO et al., 2006; MONTEIRO et al., 2006; OGASAWARA et al., 2006; WANG e LI, 2006; MARÇAL et al., 2007). Parte de sua influência pode ser creditada à longa existência se contado a partir da primeira versão do CMM, de que é derivado, e também à sua influência econômica. Essa influência pode ser ilustrada, por exemplo, pelo fato de ter sido criado a partir de uma cooperação entre o Departamento de Defesa dos EUA e a Universidade Carnegie Mellon para facilitar a identificação de bons fornecedores de software e, para citar um exemplo brasileiro, pela bonificação oferecida em licitações a empresas avaliadas em algum nível do modelo.

(35)

2.2.4 MPS.BR

O MPS.BR (SOFTEX, 2007) é um programa para Melhoria de Processo do Software Brasileiro coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) e tem como objetivo definir um modelo de melhoria e avaliação de processo de software, preferencialmente para as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e a ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software. Este é o motivo pelo qual ele está aderente a modelos e normas internacionais. O MPS.BR também define regras para sua implementação e avaliação, dando sustentação e garantia de que o MPS.BR está sendo empregado de forma coerente com as suas definições.

O Modelo de Referência para Melhoria de Processo do Software Brasileiro (MR-MPS) contém os requisitos que as organizações deverão atender para estar em conformidade com o MR-MPS. Ele contém as definições dos níveis de maturidade, da capacidade de processos e dos processos em si, tendo sido baseado nas normas ISO/IEC 12207 e suas emendas 1 e 2, na ISO/IEC 15504. Além disso, existe uma equivalência entre o MPS.BR e o CMMI (SOFTEX, 2008b). Esta equivalência é total do ponto de vista do MPS.BR para o CMMI, isto é, todos os requisitos das áreas de processo do CMMI estão presentes no MPS.BR. Entretanto não existe equivalência total do ponto de vista do CMMI para o MPS.BR, pois, visando à conformidade com as normas internacionais ISO/IEC 12207 e 15504-2, as exigências do MR-MPS são maiores do que as do CMMI nos seguintes processos: Gerência de Recursos Humanos que no MR-MPS (conforme disposto nas normas ISO/IEC 12207 e 15504-2) abrange aquisição de pessoal, treinamento organizacional e gerência do conhecimento e no CMMI trata apenas de treinamento organizacional; Gerência de Reutilização e Desenvolvimento para Reutilização estão incluídos no MR-MPS (atendendo requisitos das normas ISO/IEC 12207 e 15504-2) e não existem no CMMI.

O MR-MPS define sete níveis de maturidade: G (Parcialmente Gerenciado), F (Gerenciado), E (Parcialmente Definido), D (Largamente Definido), C (Definido), B (Gerenciado Quantitativamente) e A (Em Otimização). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade foi atribuído um perfil de processos e de capacidade de processos (baseados naqueles definidos pela ISO/IEC 15504) que indicam onde a organização tem que colocar esforço para melhoria. A divisão em estágios, embora baseada nos níveis de maturidade do CMMI-DEV, tem uma graduação diferente, com o objetivo de possibilitar uma implementação e

(36)

avaliação mais gradual e adequada às pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis permite uma visibilidade dos resultados de melhoria de processos com prazos mais curtos.

Para que as organizações alcancem um determinado nível de maturidade do MPS.BR, todos os propósitos e resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível e para os níveis anteriores devem ser atendidos, conforme pode ser visto na Tabela 2.3 (onde a sigla AP significa Atributo de Processo).

Tabela 2.3 – Processos e Atributos de Processo do MPS.BR

Nível Processo Capacidade

A Análise de Causas de Problemas e Resolução (ACP) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2

B Gerência de Projetos (GPR, evolução) AP 1.1, AP 2.1, AP 2.2, _{AP 3.1, AP 3.2, AP 4.1 e AP 4.2} Gerência de Riscos (GRI)

Desenvolvimento para Reutilização (DRU) Análise de Decisão e Resolução (ADR)

C

Gerência de Reutilização (GRU, evolução)

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Verificação (VER) Validação (VAL)

Projeto e Construção do Produto (PCP) Integração do Produto (ITP)

D

Desenvolvimento de Requisitos (DRE)

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Gerência de Projetos (GPR, evolução) Gerência de Reutilização (GRU) Gerência de Recursos Humanos (GRH) Definição do Processo Organizacional (DFP)

E

Avaliação e Melhoria do Processo Organizacional (AMP)

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Medição (MED)

Garantia da Qualidade (GQA) Gerência de Configuração (GCO)

F

Aquisição (AQU)

AP 1.1, AP 2.1 e AP 2.2

Gerência de Requisitos (GRE)

G _{Gerência de Projeto (GPR)} AP 1.1 e AP 2.1

Exemplos de utilização do MPS.BR por empresas brasileiras na literatura especializada, apesar de ainda pequeno em relação a outros modelos e normas de maturidade, é significativo levando em consideração ao pequeno tempo de vida do modelo, como pode ser visto, por exemplo, em (ROCHA et al., 2005b; FERREIRA et al., 2006a; NUNES et al., 2006; BORSSATTO e MORO, 2007; BRIETZKE et al., 2007; FERREIRA et al., 2007a; FERREIRA et al., 2007b; FERREIRA et al., 2007c; MONTONI et al., 2007b; SANTOS et al., 2007b; SANTOS et al., 2008b). Além disso, mecanismo instituído pela entidade mantenedora do modelo garante que lições aprendidas e experiências relacionadas a adoção e utilização do modelo por Instituições Implementadoras (II), Avaliadoras (IA) e