Embed Size (px)
Citation preview
INPE-11550-TDI/958
UMA ABORDAGEM PARA A GERÊNCIA DA QUALIDADE EM UM AMBIENTE DE ENGENHARIA DE SOFTWARE
CENTRADO EM PROCESSO
Carlos Henrique Netto Lahoz
Dissertação de Mestrado do Curso de Pós-Graduação em Computação Aplicada, orientada pelo Dr. Nilson Sant’Anna, aprovada em 19 de março de 2004.
INPE São José dos Campos
2004
681.3.06 : 658.56 LAHOZ, C. H. N. Uma abordagem para a gerência da qualidade em um ambiente de engenharia de software centrado em processo / C. H. N. Lahoz. – São José dos Campos: INPE, 2004. 307p. – (INPE-11550-TDI/958). 1.Engenharia de software. 2.Ambientes de engenharia de software. 3.Processo. 4.Padronização. 5.Modelos. 6.Qualidade. I.Título.
“É preciso forjar a sua arte da espada com treinamentos de mil dias; depois,
poli-la com treinamentos de dez mil dias”.
MIYAMOTO MUSASHI
AGRADECIMENTOS
Agradeço a minhas meninas Mira, Beatriz e Patrícia pelo amor e paciência
durante as inúmeras horas que passei trabalhando longe delas.
Agradeço a colega Martha Abdala pelos artigos, trabalhos e discussões que
fizemos juntos, durante o caminho de realização do mestrado.
Agradeço ao amigo Carlos Moura pelas participações em trabalhos, pela
amizade e pelos comentários valiosos feitos à respeito dessa dissertação.
Agradeço a analista Roberta Panzera pelo inestimável auxílio na
implementação do protótipo apresentado nesta dissertação.
Agradeço ao meu orientador Nilson Sant’Anna por me conceder esta
oportunidade e por acreditar no meu potencial profissional.
Agradeço aos professores, colegas e amigos que, de alguma forma,
contribuíram com minhas pesquisas e na formação deste trabalho.
Agradeço a meus pais e em especial a Deus por estar aqui, pleno de minhas
funções e realizador.
RESUMO
No contexto atual da engenharia de software aplicada ao Programa Espacial Brasileiro, a necessidade de construir produtos em tempo hábil, com poucos recursos e com qualidade durante seu desenvolvimento é uma realidade inquestionável. Tanto o sistema de controle de satélites, sob responsabilidade do Instituto Nacional de Pesquisas Espaciais (INPE), como o software de bordo do Veículo Lançador de Satélites (VLS), sob responsabilidade do Instituto de Aeronáutica e Espaço (IAE) são exemplos típicos de projetos de engenharia de software que necessitam alcançar alto nível de qualidade e confiabilidade nos produtos desenvolvidos e alta produtividade de desenvolvimento. Planejar, executar e acompanhar as atividades referentes à qualidade, através de processos bem definidos e fazendo uso de ambientes que suportem sua modelagem e execução, mostra-se um caminho fortemente indicado para promover as boas práticas de engenharia de software nestas organizações. Este trabalho de dissertação de mestrado visa definir e modelar os processos da gerência da qualidade em um ambiente de desenvolvimento de projetos de software que fornece suporte eficiente e integrado a processos e que permite melhorias evolutivas da qualidade com relação a aspectos de gestão da qualidade e do controle dos produtos gerados durante o desenvolvimento de software.
AN APPROACH FOR QUALITY MANAGEMENT IN A PROCESS-CENTERED SOFTWARE ENGINEERING ENVIRONMENT
ABSTRACT
Nowadays in the software engineering applied to the Brazilian Space Progam the necessity to construct products in short time, with low resources and high quality during its development is an unquestioned reality. The development of the satellites control system under responsibility of National Institute for Space Research (INPE) as well as the development of the Satellite Launch Vehicle (VLS) on board software under responsibility of Aeronautics and Space Institute (IAE) are typical examples of software engineering projects that need to reach high level of quality and safety in the developed products and high productivity of development. Planning, executing and following the activities refered to quality, with well defined processes and using an environment that supports process modeling and execution, are indicated ways to promote good practices of software engineering in these organizations. This dissertation aims to define and model the quality management processes in a software project development environment that provides efficient and integrated support to processes and allows evolutive improvements of the quality regarding to aspects of quality management and control of the products generated during the software development.
SUMÁRIO
Pág.LISTA DE FIGURAS............................................................................................ 17 LISTA DE TABELAS............................................................................................ 21 CAPÍTULO 1 – INTRODUÇÃO............................................................................ 23 1.1 – Objetivo....................................................................................................... 26 1.2 – Motivação.................................................................................................... 27 1.3 – Organização do Trabalho............................................................................ 30 CAPÍTULO 2 –A GERÊNCIA DA QUALIDADE DE SOFTWARE.......................... 31 2.1 – Conceitos Importantes................................................................................ 33 2.1.1 – Qualidade................................................................................................. 33 2.1.2 – Qualidade de Produto.............................................................................. 34 2.1.3 – Qualidade de Processo............................................................................ 37 2.2 – A Gestão da Qualidade de Software........................................................... 38 2.2.1 – A Qualidade e Sua Gestão no Projeto..................................................... 39 2.2.2 – A Qualidade e Suas Responsabilidades no Projeto................................ 41 2.2.3 – A Qualidade e o Papel dos Envolvidos.................................................... 42 2.2.3.1 – O Gerente da Qualidade....................................................................... 43 2.2.3.2 – O Gerente de Projeto............................................................................ 44 2.2.3.3 – O Gerente da Configuração.................................................................. 44 2.2.3.4 – O Usuário ou Cliente............................................................................. 45 2.2.3.5 – O Analista da Qualidade....................................................................... 4 2.2.3.6 – O Testador............................................................................................ 46 2.2.3.7 – O Revisor.............................................................................................. 47 2.2.3.8 – O Auditor............................................................................................... 48 2.2.4 – A Qualidade e o Ciclo de Vida do Software............................................. 49 2.2.5 – A Qualidade e os Produtos de Software...... ........................................... 5
2.2.5.1 – As Categorias de Produto..................................................................... 5 2.2.6 – A Qualidade e os Marcos de Projeto....................................................... 53 2.2.7 – A Qualidade e os Padrões....................................................................... 54 2.2.7.1 – Áreas de Aplicações de Padrões.......................................................... 5 2.2.8 – A Qualidade e Métricas de Software........................................................ 5 2.2.8.1 – Categorias de Métricas......................................................................... 2.2.9 – A Qualidade e a Documentação.............................................................. 2.2.10 – A Qualidade e a Estruturação de Sua Gerência....................................2.2.10.1 – A Garantia da Qualidade..................................................................... 61 2.2.10.2 – O Planejamento da Qualidade............................................................ 2.2.10.3 – O Controle da Qualidade...................................................................... CAPÍTULO 3 – PADRÃO DE PROCESSO, LINGUAGEM DE MODELAGEM E O AMBIENTE CENTRADO EM PROCESSO........................................................ 65 3.1 – O Padrão ISO/IEC15504............................................................................. 66 3.1.1 – O Padrão ISO/IEC12207 e o 15504......................................................... 71 3.1.2 – O Modelo de Referência CMMI e o 15504............................................... 76 3.2 – A Linguagem de Modelagem de Processo................................................. 81 3.2.1 – Classificação das PMLs........................................................................... 82 3.2.2 – Elementos da Modelagem de Processo.................................................. 84 3.2.3 – Arquitetura da Modelagem....................................................................... 86 3.2.4 – O SPEM – Meta-modelo de Engenharia de Processo de Software......... 88 3.2.4.1 – Elementos da Linguagem SPEM.......................................................... 89 3.2.4.2 – A notação SPEM................................................................................... 92 3.3 – O Ambiente Centrado em Processo........................................................... 95 3.3.1 – O e-WebProject - Ambiente Integrado para Gestão de Projetos de Software............................................................................................................... 97 3.3.2 – Arquitetura Lógica do Ambiente............................................................... 98 3.3.3 – A arquitetura física................................................................................... 99 3.3.4 – Ciclo de Vida do Processo no Ambiente.................................................. 101 3.3.4.1 – A Fase de Planejamento e Definição do Processo............................... 102
3.3.4.2 – A Fase de Execução e Acompanhamento do Processo....................... 104 3.3.4.3 – A Fase de Avaliação e Proposta de Melhoria do Processo.................. 106 3.3.5 – O Serviço de Coordenação de Processos de Software........................... 107 3.3.6 – As Gerências no e-WebProject............................................................... 108 3.3.6.1 – A Gerência da Qualidade no e-WebProject......................................... 109 CAPÍTULO 4–OS MODELOS DE PROCESSO DA GERÊNCIA DA QUALIDADE 113 4.1 – O Escopo dos Processos da Qualidade..................................................... 4.2 – A Estratégia para a Definição e Modelagem dos Processos da Qualidade 119 4.2.1 – Papéis e Responsabilidades nos Processos da Qualidade..................... 120 4.2.2 – Principais Atividades nos Processos da Qualidade................................. 121 4.2.3 – Padrão e Notação Utilizados na Modelagem dos Processos.................. 4.3 – A Modelagem dos Processos da Qualidade................................................ 124 4.3.1 – Pacote Gerenciamento da Qualidade...................................................... 125 4.3.1.1 – Objetivos e Requisitos Básicos do Pacote............................................ 125 4.3.1.2 – Papéis, Responsabilidades e Produtos Envolvidos no Pacote............. 129 4.3.1.3 – Atividades do Pacote............................................................................ 132 4.3.1.3.1 – Pacote Estabelecimento do Sistema de Gerenciamento da Qualidade............................................................................................................. 133 4.3.1.3.2 – Pacote Definição dos Objetivos da Qualidade................................... 135 4.3.1.3.3 – Pacote Definição da Estratégia Geral da Qualidade......................... 136 4.3.1.3.4 – Pacote Estabelecimento dos Padrões de Produto............................. 137 4.3.1.3.5 – Pacote de Definição da Política de Documentação........................... 139 4.3.1.3.6 – Pacote de Definição da Estratégia de Medições da Qualidade........... 141 4.3.1.3.7 – Pacote de Avaliação dos Objetivos da Qualidade............................. 143 4.3.1.3.8 – Pacote Política de Tratamento de Não-Conformidades..................... 145 4.3.1.3.9 – Pacote Definição da Política de Divulgação de Resultados da Qualidade............................................................................................................. 147 4.3.2 – Pacote Garantia da Qualidade................................................................. 149 4.3.2.1 – Objetivos e Requisitos Básicos do Pacote............................................ 149
4.3.2.2 – Papéis, Responsabilidades e Produtos Envolvidos no Pacote............. 153 4.3.2.3 – Atividades do Pacote............................................................................ 157 4.3.2.3.1 – Pacote Definição da Estratégia da Qualidade em Projeto................. 158 4.3.2.3.2 – Pacote Definição dos Registros da Qualidade no Projeto................... 160 4.3.2.3.3 – Pacote Seleções de Padrões para o Projeto....................................... 161 4.3.2.3.4 – Pacote Seleção de Documentação...................................................... 163 4.3.2.3.5 – Pacote Definição da Política de Verificação e Validação no Projeto... 165 4.3.2.3.6 – Pacote Definição da Política de Revisão Conjunta e Auditoria no Projeto.................................................................................................................... 167 4.3.2.3.7 – Pacote de Extração dos Registros da Qualidade................................ 169 4.3.2.3.8 – Pacote de Identificação das Não-Conformidades............................... 170 4.3.3 – Processo Controle da Qualidade............................................................... 172 4.3.3.1 – Objetivos e Requisitos Básicos do Processo.......................................... 172 4.3.3.2 – Papéis, Responsabilidades e Produtos Envolvidos no Pacote.............. 175 4.3.3.3 – Atividades do Pacote.............................................................................. 182 4.3.3.3.1 – Pacote Verificação............................................................................... 182 4.3.3.3.2 – Pacote Validação................................................................................. 4.3.3.3.3 – Pacote Revisão Conjunta.................................................................... 4.3.3.3.4 – Pacote Auditoria................................................................................... 4.3.3.3.5 – Pacote Comunicação dos Resultados................................................. 4.3.4 – Pacote Qualidade de Produto.................................................................... 4.3.4.1 – Objetivos e Requisitos Básicos do Pacote............................................. 4.3.4.2 – Papéis, Responsabilidades e Produtos Envolvidos no Pacote.............. 4.3.4.3 – Atividades do Pacote.............................................................................. 212 4.3.4.3.1 – Pacote Usabilidade..............................................................................4.3.4.3.2 – Pacote Avaliação de Produto.............................................................. CAPÍTULO 5 – A IMPLEMENTAÇÃO DE UM PROTÓTIPO NO AMBIENTE INTEGRADO.......................................................................................................... 217 5.1 – Os Requisitos do Protótipo Garantia de Produto.......................................... 218 5.1.1 – Caso de Uso Definir Papéis da Qualidade na Avaliação........................... 221
5.1.2 – Caso de Uso Definir Política de Avaliação de Produto.............................. 221 5.1.3 – Caso de Uso Encaminhar Produtos para Controle.................................... 223 5.1.4 – Atividades Avaliar Produtos....................................................................... 224 5.2 – Os Recursos do Ambiente Necessários para os Processos........................ 227 5.2.1 – Os Recursos da Camada de Armazenamento e Acesso.......................... 227 5.2.2 – Os Recursos da Camada de Serviços....................................................... 228 5.2.3 – Os Recursos da Camada de Interação com o Usuário............................. 233 CAPÍTULO 6 – CONCLUSÕES............................................................................. 235 6.1 – Histórico........................................................................................................ 236 6.2 – Os Resultados Obtidos com os Trabalhos................................................... 239 6.2.1 – Os Resultados Obtidos com a Abordagem de Padrões............................ 240 6.2.2 – Os Resultados Obtidos com a Utilização da Modelagem.......................... 242 6.2.3 – Os Resultados Obtidos com a Utilização do Ambiente Integrado............. 245 6.3 – Benefícios e Recomendações do Trabalho.................................................. 247 6.3.1 – Benefícios da Abordagem.......................................................................... 248 6.3.2 – A Avaliação de Processo........................................................................... 249 6.3.3 – A Melhoria de Processo............................................................................. 251 REFERÊNCIAS BIBLIOGRÁFICAS...................................................................... 253 BIBLIOGRAFIA COMPLEMENTAR.................................................................... 265 APÊNDICE A – DIMENSÃO DE PROCESSO E DE CAPACIDA DO PADRÃO ISO/IEC 15504..................................................................................................... APÊNDICE B – TABELA DE PRODUTOS x PROCESSOS SUPORTE............. APÊNDICE C – TELAS DO PROTÓTIPO QUALITY MANAGEMENT– QM.......
LISTA DE FIGURAS
Pág.1.1 – Empresas que investiram em Programas de Qualidade............................ 25 1.2 – Conhecimento de Normas da Qualidade de Processo (Brasil).................. 28 2.1 – Um modelo de Sistema de Desenvolvimento de Software......................... 40 2.2 – Papéis dos envolvidos com a qualidade..................................................... 43 3.1 – Categorias de Processos da ISO/IEC15504.............................................. 68 3.2 – Níveis de Capacidade da ISO/IEC 15504.................................................. 69 3.3 – Áreas de processos para os Níveis 0,1 e 2 da ISO/IEC15504................... 70 3.4 – Áreas de processos para os Níveis 3,4 e 5 da ISO/IEC15504................... 70 3.5 – Classificação dos Processos da ISO/IEC12207......................................... 73 3.6 – Elementos e Relacionamentos de um Modelo de Processo...................... 86 3.7 – Níveis de abstração da modelagem de processos..................................... 87 3.8 – A camada conceitual do Ambiente e-WebProject...................................... 100 3.9 – Arquitetura 3 camadas para aplicações Web............................................. 100 3.10 – Ciclo de vida do processo Auditar Produto............................................... 102 3.11 – A fase de planejamento............................................................................ 103 3.12 – Os estados de um processo quando na etapa de Execução................... 106 4.1 – Os processos da Qualidade....................................................................... 117 4.2 – Meta-modelo do Processo de Qualidade de Software............................... 119 4.3 – Pacote Gerenciamento da Qualidade......................................................... 128 4.4 – Os produtos envolvidos com o Gerente da Qualidade no pacote Gerenciamento da Qualidade.............................................................................. 129 4.5 – Os produtos envolvidos com o Analista da Qualidade no pacote Gerenciamento da Qualidade.............................................................................. 131 4.6 – O Pacote Estabelecimento do Sistema de Gerenciamento da Qualidade 134 4.7 – O Pacote Definição dos Objetivos da Qualidade........................................ 135 4.8 – O Pacote Definição da Estratégia Geral da Qualidade.............................. 136 4.9 – O Pacote Estabelecimento dos Padrões de Produto................................. 138 4.10 – O Pacote Definição da Política de Documentação................................... 140 4.11 – O Pacote Definição da Estratégia de Medições da Qualidade................. 142 4.12 – O Pacote Avaliação dos Objetivos da Qualidade..................................... 144
4.13 – O Pacote Política de Tratamento de Não-Conformidades....................... 146 4.14 – O Pacote Definição da Política de Divulgação de Resultados da Qualidade............................................................................................................ 148 4.15 – Pacote Garantia da Qualidade................................................................. 152 4.16 – Os produtos envolvidos com o Gerente da Qualidade no pacote Garantia da Qualidade........................................................................................ 154 4.17 – Os produtos envolvidos com o Analista da Qualidade no pacote Garantia da Qualidade......................................................................................... 156 4.18 – Pacote Definição da Estratégia de Garantia da Qualidade em Projeto.... 159 4.19 – Pacote Definição dos Registros da Qualidade no Projeto........................ 160 4.20 – Pacote Seleção de Padrões para o Projeto.............................................. 162 4.21 – Pacote Seleção da Documentação.......................................................... 164 4.22 – Pacote Definição da Política de Verificação e Validação no Projeto........ 166 4.23 – Pacote Definição da Política de Revisão Conjunta e Auditoria no Projeto................................................................................................................. 168 4.24 – Pacote Extração dos Registros da Qualidade.......................................... 169 4.25 – Pacote Identificação de Não-Conformidade............................................. 171 4.26 – Pacote Controle da Qualidade.................................................................. 175 4.27 – Os produtos envolvidos com o Gerente da Qualidade no pacote Controle da Qualidade........................................................................................ 176 4.28 – Os produtos envolvidos com o Revisor no pacote Controle da Qualidade............................................................................................................ 178 4.29 – Os produtos envolvidos com o Testador no pacote Controle da Qualidade............................................................................................................ 180 4.30 – Os produtos envolvidos com o Auditor no pacote Controle da Qualidade............................................................................................................ 181 4.31 – Pacote Verificação.................................................................................... 183 4.32 – Diagrama de caso de uso Verificar Produto............................................. 184 4.33 – Diagrama de atividades Conduzir Verificação......................................... 187 4.34 – Pacote Validação...................................................................................... 189 4.35 – Diagrama de caso de uso Validar Produto............................................... 190 4.36 – Diagrama de atividades Conduzir Validação............................................ 193
4.37 – Pacote Revisão Conjunta......................................................................... 195 4.38 – Diagrama de caso de uso Revisar Produto/Processo.............................. 196 4.39 – Diagrama de atividades Conduzir Revisão Conjunta............................... 199 4.40 – Pacote Auditoria....................................................................................... 201 4.41 – Diagrama de caso de uso Auditar Produto/Processo............................... 202 4.42 – Diagrama de atividades Conduzir Auditoria............................................. 204 4.43 – Pacote Comunicação dos Resultados..................................................... 205 4.44 – Diagrama de caso de uso Comunicar Resultados................................... 206 5.45 – Pacote Qualidade de Produto.................................................................. 209 4.46 – Os produtos envolvidos com o Gerente da Qualidade no pacote Qualidade de Produto.......................................................................................... 210 4.47 – Os produtos envolvidos com o Analista da Qualidade no pacote Qualidade de Produto.......................................................................................... 211 4.48 – Os produtos envolvidos com o Revisor no pacote Qualidade de Produto................................................................................................................ 212 4.49 – Pacote Usabilidade................................................................................... 214 4.50 – Pacote Avaliação de Produto................................................................... 216 5.1 – Diagrama de Contexto da Garantia de Produto......................................... 220 5.2 – Caso de uso Definir Papéis da Qualidade na Avaliação............................ 221 5.3 – Caso de uso Definir Política de Avaliação de Produto............................... 222 5.4 – Caso de uso Encaminhar Produtos para Controle..................................... 224 5.5 – Diagrama de atividades Avaliar Produto.................................................... 226 C.1 – Tela de acesso ao protótipo QM................................................................ 287 C.2 – Tela de trabalho do usuário....................................................................... 288 C.3 – Tela de acesso às atividades do Time da Qualidade................................ 289 C.4 – Tela inicial da atividade Quality Planning................................................... 290 C.5 – Tela referente à lista de projetos instanciados........................................... 291 C.6 – Tela referente à definição dos papéis da qualidade no projeto................. 292 C.7 – Tela referente à opção de padrões de projeto........................................... 293 C.8 – Tela referente à opção de política de Verificação e Validação.................. 294 C.9 – Tela inicial da atividade de Garantia de Produto....................................... 295 C.10 – Tela de acompanhamento dos produtos encaminhados......................... 296
C.11 – Tela de encaminhamento de Produtos.................................................... 297 C.12 – Tela de acompanhamento dos produtos mudando o status para “Encaminhado a Qualidade”................................................................................ 298 C.13 – Tela inicial da atividade de Garantia da Qualidade.................................. 299 C.14 – Tela de avaliação de produto (visão Gerente da Qualidade)................... 300 C.15 – Tela de acompanhamento dos produtos mudando o status para “Encaminhado ao Revisor”.................................................................................. 301 C.16 – Tela inicial da atividade de Controle da Qualidade.................................. 302 C.17 – Tela de avaliação de produto (visão do Revisor da Qualidade).............. 303 C.18 – Tela de acompanhamento dos produtos mudando o status para “ Revisado”............................................................................................................. 304 C.19 – Tela de acompanhamento dos produtos mudando o status.................... 305 C.20 – Formulário de Encaminhamento de Produto........................................... 306 C.21 – Formulário de Avaliação de Produto........................................................ 307
LISTA DE TABELAS
Pág.2.1 – Classificação de Produto de Trabalho........................................................ 53 3.1 – Compatibilidade entre o ISO/IEC 15504 e o 12207.................................... 75 3.2 – O processo CMMI Garantia da Qualidade de Processo e Produto e os processos Suporte do 15504............................................................................... 81 3.3 – Principais ícones e estereótipos do SPEM................................................. 95 6.1 – Tabela de Relacionamento entre Processos e seus Atributos................... 242 B.1 – Produtos da categoria Organizacional relacionados aos processos da Qualidade............................................................................................................ 283 B.2 – Produtos da categoria Projeto relacionados aos processos da Qualidade 284 B.3 – Produtos da categoria Registros relacionados aos processos da Qualidade............................................................................................................ 285
23
CAPÍTULO 1
INTRODUÇÃO
É de senso comum hoje que a gestão da qualidade e o desenvolvimento de
software são atividades fortemente relacionadas. A necessidade de construção
de projetos que combinem entre si múltiplos requisitos, envolvendo equipes
heterogêneas de trabalho, gerando produtos materiais e não-materiais, um
mercado tecnológico extremamente competitivo e solicitações cada vez mais
sofisticadas dos clientes e usuários geram uma interdependência entre as
atividades de desenvolvimento de software e do gerenciamento de sua
qualidade. Além desse contexto, em uma economia altamente globalizada e
usuária da tecnologia da informação, a imposição de padrões de produção
internacionais, as exigências quanto à qualidade dos produtos e as
expectativas dos clientes tendem cada vez mais a crescer.
Outro consenso para a maioria dos especialistas de software é que a qualidade
do processo de software é tão importante como a qualidade do produto. Nos
anos 90, um dos grandes temas discutidos na área foi voltado para a pesquisa
da modelagem e melhoria do processo de software. Abordagens importantes,
como as normas da ISO 9000 (ISO9000, 2000), o ISO/IEC 12207
(ISO/IEC12207, 1995), o modelo Capability Maturity Model for Software (CMM-
SW, 1993) e o Software Process Improvement and Capability dEtermination
(SPICE) (SPICE, 1995), sugerem que, melhorando o processo de software,
pode-se melhorar a qualidade dos produtos (Pfleeger, 1998). Versões mais
atuais desses padrões, como o ISO/IEC 15504 (ISO/IEC15504-5, 2003), o
12207 (ISO/IEC12207, 2001) e o Capability Maturity Model Integration (CMMI)
(CMMI, 2002), reforçam ainda mais esta visão e a deste trabalho. A previsão
de Curtis (Curtis, 2000) de que as organizações, para a sua manutenção no
mercado, serão pressionadas para o uso de processos de produção de
software de qualidade, dentro de prazos cada vez menores e orçamentos
confiáveis e reduzidos, começa a se concretizar. Este tipo de tendência
24
fortalece ainda mais a necessidade de uso de processos bem-definidos e de
qualidade em organizações fabricantes de software.
Atualmente, no contexto da engenharia de software aplicada ao setor
tecnológico aeroespacial brasileiro, a necessidade de construir os produtos em
tempo hábil na maioria das vezes com poucos recursos e sem poder perder a
qualidade durante seu desenvolvimento é fato constante. No que se refere a
projetos científicos da área espacial, nota-se uma especial atenção a estes
requisitos de qualidade nas áreas de telecomunicações, meio-ambiente e
observação da Terra (Meira et al., 1999). O desenvolvimento do Sistema de
Controle de Satélites (SICS), de responsabilidade do Instituto Nacional de
Pesquisas Espaciais (INPE), bem como o desenvolvimento do Software
Aplicativo de Bordo (SOAB) do Veículo Lançador de Satélites (VLS), de
responsabilidade do Instituto de Aeronáutica e Espaço (IAE), são exemplos
típicos de projetos de engenharia de software que necessitam alcançar alta
qualidade e confiabilidade nos produtos desenvolvidos e alta produtividade de
desenvolvimento. Em acréscimo a isto, existe a necessidade contínua de
preocupação com a melhoria das técnicas utilizadas no desenvolvimento
propriamente dito, bem como com relação a aspectos de gestão de projetos, de
gestão da qualidade e de controle dos produtos gerados durante o
desenvolvimento.
Fica patente a necessidade de se estabelecerem princípios básicos de
engenharia para desenvolver software de qualificação espacial, de maneira
sistemática e econômica, visando um produto confiável e eficiente, devendo
para isto contemplar-se a especialização das atividades técnicas para sua
construção, um suporte automatizado para essas atividades e procedimentos
para ligar as técnicas às ferramentas (Moura et al., 2003).
Obviamente, muitos esforços estão sendo feitos na direção da regulamentação
e da melhoria da qualidade e da produtividade de software, como no contexto
da nova Lei de Tecnologia da Informação (Nascimento, 2002). Esta lei
25
estabelece uma política de qualidade de software que abrange a melhoria da
qualidade em processo e produto, propondo a reciclagem e atualização de
profissionais de desenvolvimento de software, a capacitação de empresas em
níveis de qualidade de padrão internacional e, conseqüentemente, sua
qualificação e certificação. A Figura 1.1 apresenta o resultado de uma pesquisa
sobre a melhoria da qualidade e produtividade no contexto desta nova Lei,
onde se observa que apenas 24% de um total de 415 empresas pesquisadas
em 2001 tinham um plano de qualidade total ou similar implantado na
organização.
18
26
11
24
1995 1997 1999 2001
Programa de qualidade total ou similar (415 empresas pesquisadas no Brasil)
em %
FIGURA 1.1 - Empresas que investiram em Programas de Qualidade.
FONTE: Nascimento (2002).
No contexto da gestão da qualidade para apoio ao desenvolvimento de
produtos de software dentro de organizações de pesquisa, como o INPE e o
IAE, devem ser implantados, além de procedimentos e padrões de qualidade,
uma cultura sobre sua necessidade e importância. Com isso, todos os
envolvidos na criação deste tipo de produto comprometem-se com o alcance
desses requisitos de qualidade, com o mais alto nível possível e dentro de
26
metas de tempo e custos estabelecidos, e com excelência tanto nos produtos
em si, como nos processos que auxiliaram seu desenvolvimento.
Fica patente, também, a contribuição de outros fatores para alcançar níveis de
qualidade satisfatórios, já que a qualidade de software não está embutida
somente nos produtos e nos seus processos, mas sim desde o começo de sua
criação, por meio da capacidade das pessoas que os criam, da tecnologia
utilizada e de uma disciplina gerencial que supervisione o processo (Yordon,
1995).
1.1 - Objetivo
Esta dissertação de mestrado, intitulada “Uma Abordagem para a Gerência da
Qualidade em um Ambiente de Engenharia de Software Centrado em
Processo” tem como objetivo principal identificar, definir e modelar as práticas
que a gestão da qualidade deve incorporar ao quotidiano de uma organização
desenvolvedora de software, principalmente do setor espacial. Acredita-se que,
definindo e modelando processos da qualidade que auxiliem os processos de
desenvolvimento de software, será possível obter um nível de maturidade
maior para as atividades da qualidade em projetos de software da área
espacial brasileira, obtendo assim, ganhos consideráveis de produtividade,
confiabilidade e qualidade de produto e de processo. Ao se definir as atividades
fundamentais da gerência da qualidade em um ambiente de desenvolvimento
integrado, será possível determinar, de maneira inequívoca, o nível de
qualidade dos produtos resultantes. A qualidade e a melhoria destes processos
passam a serem vistos, então, como um pré-requisito e um fator condicionante
da qualidade do produto (Rocha et al., 2001).
Desta forma, há necessidade de se planejar, executar e acompanhar os
processos e as atividades referentes à garantia da qualidade, principalmente
no que tange às características de qualidade dos produtos intermediários e de
27
seu processo de desenvolvimento (Troster e Tian, 1995). Para isto, é
necessário o uso de práticas da qualidade em ambientes que ofereçam suporte
eficiente e integrado aos processos de engenharia de software, tenham visão
adequada a de objetos, sejam organizados em áreas de negócio, dêem apoio
às gerências estabelecidas no projeto, permitam padrões evolutivos de
qualidade e utilizem conceitos de trabalho cooperativo (Sant’Anna, 2000).
1.2 - Motivação
Uma dificuldade ainda existente no setor de desenvolvimento de software para
aplicações espaciais no Brasil é que após a definição de quais procedimentos e
produtos serão implantados e controlados pela qualidade, haja a garantia que
todos os envolvidos no projeto estejam efetivamente comprometidos com o
cumprimento dos procedimentos e com a geração desses produtos ao longo do
tempo. A gerência da qualidade deve ser capaz, dentro deste escopo, de
fornecer resultados quantitativos e qualitativos referentes aos produtos e
processos, que sejam compreensíveis e confiáveis para a gerência geral ou
para outros envolvidos, permitindo assim analisar, conduzir e divulgar o
desenvolvimento da qualidade de produto (e de processo) dentro das
exigências e dos padrões para aplicações espaciais.
É também importante assegurar que os métodos e tecnologias utilizados
apóiem, avaliem e melhorem as atividades de desenvolvimento e manutenção
de software, e que se estabeleçam níveis mínimos de qualidade dos produtos e
se definam procedimentos e padrões a serem usados durante todo o seu
desenvolvimento.
A pesquisa "Qualidade e Produtividade no Setor de Software Brasileiro - 2001",
realizada pela Secretaria de Política de Informática do Ministério da Ciência e
Tecnologia (MCT/Sepin, 2001), propõe-se a acompanhar e divulgar a evolução
da qualidade nas empresas de software no Brasil. Nesta última edição, que
28
envolveu 446 empresas, (Figura 1.2), verifica-se que, apesar de a maioria
delas conhecerem normas e modelos da qualidade dos processos, apenas a
minoria os aplica em sua organização.
Os diversos modelos de processo de desenvolvimento de software surgidos
nos últimos anos, como o padrão 12207, o padrão 15504 e o modelo de
referência CMMI, prescrevem processos 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 este produto.
FIGURA 1.2 - Conhecimento de Normas da Qualidade de Processo (Brasil)
FONTE: MCT/Sepin (2001).
O padrão 15504, por exemplo, define uma estrutura para avaliação e melhoria
de processos de engenharia de software e define práticas básicas que devem
ser realizadas para que se atinjam certos níveis de maturidade.
Estes modelos representam o processo de software sob a perspectiva
funcional, mas não apresentam procedimentos definidos, como por exemplo, a
seqüência de atividades básicas que o processo deve realizar. Esta tarefa fica
a cargo da organização que implementa os processos sugeridos pelo padrão.
29
A possibilidade de se definir e modelar os processos da qualidade para
aplicação de software em projetos do setor espacial brasileiro, expressos em
uma linguagem de processo adequada, aliada a um suporte computacional
automatizado em ambientes de engenharia de software foi a principal
motivação deste trabalho.
Para isto, foi realizado um estudo sobre a definição e modelagem de processos
da garantia da qualidade para futura implantação em Ambientes de Engenharia
de Software Centrado em Processos, ambientes conhecidos como PSEEs
(Process-Centered Software Engineering Environments). Como ponto de
partida para a definição destes processos, foi utilizado o padrão ISO/IEC 15504
(ISO/IEC15504-5, 2003) e escolhida a linguagem de modelagem de processos
Software Process Engineering Metamodel (SPEM) (SPEM, 2002) para
expressá-los. Uma vez definidos, os processos serão implementados em um
ambiente PSEE e oferecidos como serviços que poderão ser adaptados às
necessidades da organização que utilizar este ambiente. Como modelo de
ambiente PSEE, foi utilizado o Ambiente Integrado para Desenvolvimento e
Gestão de Projetos de Software, o e-Webproject®. O e-WebProject é um
produto registrado pela Sistemas de Engenharia de Software (SESIS), projeto
oriundo de tese de doutorado do INPE (Sant’Anna, 2000), cujo
desenvolvimento é apoiado pelo Programa de Capacitação de Recursos
Humanos (RHAE) do Conselho Nacional de Desenvolvimento Científico e
Tecnológico (CNPq), fundação vinculada ao Ministério da Ciência e Tecnologia
(MCT) para o apoio à pesquisa brasileira. Atualmente, o e-WebProject, ainda
em fase de desenvolvimento, possui uma estrutura organizacional e uma série
de serviços que permitirão que os modelos de processos da qualidade sejam
rapidamente incorporados e executados no Ambiente Integrado, facilitando as
atividades de gestão e desenvolvimento de projetos de engenharia de software.
30
1.3 – Organização do Trabalho
No Capítulo 2 é apresentada a gerência da qualidade de software, onde são
definidos conceitos básicos de assuntos relacionados com a qualidade, sob o
ponto de vista de diversos autores e sob a luz desta abordagem. São
abordadas também, atribuições específicas e outros assuntos referentes à
gerência da qualidade de software.
No Capítulo 3 são descritos os recursos técnicos necessários para o
desenvolvimento do trabalho, como o padrão ISO/IEC 15504 e seus processos
da qualidade, bem como o relacionamento com o padrão ISO/IEC 12207 e o
modelo de referência CMMI. É apresentada a definição de linguagem de
modelagem de processo, e em particular o SPEM, e a definição de ambientes
PSSE, com ênfase no Ambiente Integrado e-WebProject.
No Capítulo 4 são apresentados os processos da Qualidade propostos para o
Ambiente Integrado. São definidos e modelados os processos da qualidade,
divididos nos sub processos: Gerenciamento da Qualidade, Garantia da
Qualidade, Qualidade de Produto e Controle da Qualidade, utilizando para
representação gráfica a linguagem de modelagem SPEM.
No Capítulo 5 são definidos os requisitos mínimos para a implementação de
um protótipo para aplicação de processos da GQ no Ambiente Integrado e-
WebProject, e também quais serviços o Ambiente deve prover para que os
processos da qualidade sejam implantados com sucesso e de maneira a
alcançar seus objetivos.
No Capítulo 6 são apresentadas as considerações finais desta dissertação,
descrevendo um breve histórico sobre a condução do trabalho, apresentando
os resultados decorrentes da utilização dos modelos de processos e da
implementação do protótipo, bem como os benefícios identificados e as
melhorias que ainda devem ser realizadas com trabalhos futuros.
31
CAPÍTULO 2
A GERÊNCIA DA QUALIDADE DE SOFTWARE
A implementação de conceitos de qualidade de produto tornou-se foco dos
negócios no Japão no início dos anos 50 (Juran, 1992), produzindo resultados
positivamente significativos na indústria daquele país. Muitos especialistas
norte-americanos, naquela época, foram convidados a observar esses
resultados e relataram em muitos de seus trabalhos o que estava acontecendo
com a indústria do Japão naquela época.
As organizações de software dirigiram seus esforços para essas abordagens
de gerenciamento da qualidade total, no intuito de ultrapassar a chamada crise
do software, que tinha se abatido no mundo a partir dos anos 60. Nos anos
seguintes um grande número de definições originou-se dos especialistas da
qualidade, como Kaoru Ishikawa, Joseph M. Juran, Lennart Sandholm, W.
Edwards Deming, e Philip Crosby. Muitos deles ainda têm-se dedicado, nos
últimos 30 anos, à consultoria, pesquisa, ensino e publicações de trabalhos
sobre a melhoria da qualidade (Wheeler e Duggins, 1998).
No fim dos anos 80, a indústria começou a procurar por especialistas em
métodos e técnicas de melhoria da qualidade. Nessa mesma época a rede
norte-americana NBC produziu um documentário chamado “Se o Japão pode,
porque nós não?” introduzindo uma atenção mundial a demanda premente da
qualidade em um contexto de competição global. Esse programa abordava a
teoria de Edward Deming sobre melhoria da qualidade, enfatizando sua filosofia
que acreditava que melhoria da qualidade poderia significar melhoria da
produtividade, custos menores e satisfação do cliente.
Toda esta evolução teve seu auge nos anos 90, que se caracterizaram como
os da era da qualidade.
32
Já as primeiras importantes contribuições da pesquisa na área de processos de
software foram iniciadas, nos anos 60 e 70, visando a aumentar a
conscientização da comunidade envolvida com software sobre a complexidade
no seu desenvolvimento. Pesquisadores e praticantes tinham percebido que
desenvolver software não é apenas a criação efetiva de linguagens de
programas e ferramentas, e sim um esforço feito de forma coletiva, e de modo
criativo.
Como uma disciplina autônoma, a área de processo de software começou nos
anos 80 através de uma série de workshops e eventos, em particular, o
International Software Process Workshop. Ao longo dos anos, novos eventos e
jornais foram criados, como o European Workshop on Software Process
Technology e o jornal Software Process - Improvement and Practice.
Importantes instituições organizaram-se nos Estados Unidos e na Europa para
estudar processos de software. O Software Engineering Institute (SEI) em
Pittsburgh, USA, e o European Software Institute (ESI) em Bilbao, Espanha.
Também organizações normalizadoras centraram importantes esforços em
processo de software. Por exemplo, a International Organization for
Standardization (ISO), conjuntamente com a International Electrotechnical
Commission (IEC), criaram dois importantes padrões: o 12207 (ISO/IEC12207,
1995), que define as atividades do ciclo de vida do software, e o 15504
(ISO/IEC15504-1, 1998) que determina a capacidade do processo de software
(Fuggetta, 2000).
Uma outra área decorrente da de processo de software, e que vem obtendo
interesse atualmente na engenharia de software, é a de construção de
ambientes para a modelagem, execução, simulação e evolução de processos
de desenvolvimento de software. Os processos de software são caracterizados
por um grande número de pessoas envolvidas, um cronograma apertado, com
muitas tarefas especializadas, realizados muitas vezes de forma distribuída. Os
estudos sobre ambientes de modelagem de processos visam a melhorar a
33
percepção do processo como um todo por parte dos envolvidos, de forma a
adequar e orientar a sua função em um projeto de software.
Na seção 2.1 são descritos alguns conceitos importantes relacionados à
qualidade, necessários para o entendimento deste trabalho, sob a ótica de
pesquisadores consagrados e de normas internacionais utilizadas pela
comunidade da área de engenharia de software. Na seção 2.2, tópicos
específicos sobre a qualidade, do ponto de vista gerencial e de projeto, são
detalhados. Procurou-se direcionar os conceitos abordados para o foco do
estudo em questão, sem perder a visão geral e abrangente do seu significado.
2.1 - Conceitos Importantes
Alguns tópicos importantes utilizados no desenvolvimento desta dissertação
são aqui definidos para harmonizar conceitos relacionados ao trabalho. O
significado de cada conceito não se restringe ao descrito nesta seção, mas o
objetivo é produzir um conjunto de definições que possibilite o melhor
entendimento do trabalho e a clareza dos assuntos abordados.
2.1.1 – Qualidade
Qualidade possui significados diversos para diferentes pessoas, em um
contexto altamente dependente. Portanto, não é trivial definir, nem tampouco
haver medidas simples de qualidade aceitáveis para todos. Para estimar ou
melhorar a qualidade de software numa organização, deve-se definir as
características de qualidade, nas quais se está interessado e, então, decidir
como serão medidas (Kitchenham et al., 1996).
34
O conceito de qualidade de software não pode ser definido de um modo
simples. Classicamente a noção de qualidade foi a do desenvolvimento de
produtos conforme o especificado (Crosby, 1980).
Software de alta qualidade deve possuir características que atendam às
necessidades de usuários, desenvolvedores e mantenedores (Pfleeger, 1991).
Qualidade de software pode ser definida como o conjunto das adequações aos
requisitos funcionais e de desempenho, documentação inteligível dos padrões
de desenvolvimento e características implícitas esperadas por todos os seus
profissionais (Pressman, 1992).
Qualidade é a totalidade de características de uma entidade, que lhe confere a
capacidade de satisfazer suas necessidades explícitas e implícitas.
Necessidades explícitas são aquelas expressas na definição de requisitos
proposta pelo produtor. Esses requisitos definem as condições em que os
produtos devem ser utilizados e seus objetivos. A necessidades implícitas são
aquelas que, embora não expressas nos documentos do produtor, são
necessárias para o usuário. Estão englobados nesta classe tanto os requisitos
que não precisam ser declarados por serem óbvios, como aqueles requisitos
que não são percebidos como necessários durante o desenvolvimento do
produto, mas que pela gravidade de suas conseqüências devem ser atendidos
(ABNT8402, 1997).
2.1.2 – Qualidade de Produto
Produto de software pode ser definido como resultado de um conjunto de
atividades inter-relacionadas ou interativas que transforma insumos (entrada)
em produtos (saídas) e tem como objetivo principal alcançar uma qualidade
necessária e suficiente para o seu uso, quando for entregue e realmente usado
pelos usuários (ISO/IEC9126, 1991).
35
No desenvolvimento de software o produto é a agregação de muitos artefatos,
com características executáveis e não executáveis. Com as seguintes
(Jacobson et al., 1999) características:
Executáveis (o código propriamente dito).
Não executáveis (diagramas como casos de uso, manuais, descrição
de testes, planos, modelos e vários outros recursos documentais).
Quando se deseja um produto de software de alta qualidade, deve-se
assegurar que cada uma de suas partes constituintes possua alta qualidade.
Portanto, os resultados intermediários, no processo de produção, devem ser
imediatamente examinados após sua conclusão, de maneira a garantir que
erros e inadequações no produto sejam detectados o mais cedo possível, pois
a qualidade final do produto é uma função de todas as fases anteriores de seu
ciclo de desenvolvimento (Humphrey, 1995).
A qualidade de produto de software é resultante das atividades realizadas no
processo de desenvolvimento do mesmo. Avaliar a qualidade de um produto de
software é verificar, através de técnicas e atividades operacionais, quanto os
requisitos são atendidos. Podemos classificar como requisitos básicos de
qualidade de produto a funcionalidade, confiabilidade, usabilidade, eficiência,
manutenabilidade e portabilidade. Tais requisitos, de uma maneira geral, são a
expressão das necessidades, explicitados em termos qualitativos ou
quantitativos, e têm por objetivo definir as características de um software, a fim
de permitir a verificação de seu atendimento (ISO9126, 1991).
As características que devem ser verificadas em um software, para que ele
seja considerado um produto de qualidade, é dividido em seis grandes grupos,
cada um dividido em sub-características (ISO9126, 1991):
36
Funcionalidade (adequação, acurácia, interoperabilidade,
conformidade e segurança de acesso).
Confiabilidade (maturidade, tolerância a falhas e recuperabilidade).
Usabilidade (inteligibilidade, apreensabilidade e operacionalidade).
Eficiência (tempo e recursos).
Manutenibilidade (analisabilidade, modificabilidade, estabilidade e
testabilidade).
Portabilidade (adaptabilidade, capacidade para ser instalado,
conformidade e capacidade para substituir).
Qualidade de produto é a qualidade do produto que foi produzido pelo
processo. Dentro do enfoque das características executáveis, a qualidade do
produto é determinada pela sua avaliação, medindo e registrando as
dimensões desta qualidade. São basicamente em três dimensões (Jacobson et
al., 1999):
Confiabilidade (código resiste à falha durante a execução).
Funcionalidade (código executável atende ao caso de uso
especificado).
Executabilidade (o código executa e responde em tempo e de
maneira aceitável e contínua quando em operação).
Dentro do enfoque das características não executáveis, a qualidade do produto
é determinada pelo seu propósito, objetivo e estrutura, e é avaliado de modo a
atender (Jacobson et al., 1999):
37
Consistência interna (entre os artefatos como a linguagem usada,
terminologia, semântica, etc).
Conformidade (a guias, padrões e requisitos contratuais).
Podemos identificar quatro fatores que afetam a qualidade dos produtos de
software (Sommerville, 2001): tecnologia de desenvolvimento, qualidade dos
processos, qualidade das pessoas e custos (tempo e cronograma).
2.1.3 – Qualidade de Processo
O processo de software é uma seqüência de estágios para desenvolver ou
manter o software, apresentando estruturas técnicas e de gerenciamento para
o uso de métodos e ferramentas, e incluindo pessoas para as tarefas do
sistema (Humphrey, 1995).
O processo ou um conjunto de processos, utilizados por uma organização ou
projeto para: planejar, gerenciar, executar, monitorar, controlar e melhorar as
atividades relacionadas à construção de software (SPICE, 1995).
Um conjunto de atividades inter-relacionadas, que transformam entradas em
saídas (ISO/IEC12207, 1995).
Processo de software é um conjunto parcialmente ordenado de atividades,
responsável pelo gerenciamento, desenvolvimento e manutenção de sistemas
de software (Acuña et al., 2000).
Conjunto de atividades, métodos, práticas e transformações que as pessoas
empregam para desenvolver e manter software e os produtos associados (por
exemplo, planos de projeto, documentos de projeto/design, código, casos de
teste, manual do usuário) (CTBrasil, 1999).
38
2.2 – A Gestão da Qualidade de Software
De modo mais específico, o papel da qualidade nos projetos de software,
dentro de uma organização, é garantir que os requisitos de qualidade de um
produto e de um processo sejam alcançados. Para isto, o responsável pela
qualidade se envolve com a definição de procedimentos e padrões que devem
ser usados durante o desenvolvimento do software e o exame constante de
que estes estão sendo seguidos por todos os envolvidos. Além disso, deve-se
desenvolver uma cultura da qualidade na organização, através da qual cada
responsável pelo desenvolvimento de produto é levado a se comprometer em
alcançar um alto nível de qualidade durante o desenvolvimento (Sommerville,
2001).
Uma atividade importante da qualidade em um projeto de software é a
definição e inclusão, na estrutura organizacional, das pessoas que realizarão
as atividades da qualidade: o chamado Time da Qualidade. Estes responsáveis
têm como papel a definição dos produtos da qualidade, a avaliação dos
produtos do projeto, a realização das auditorias da qualidade, a produção dos
registros da qualidade, o encaminhamento das não conformidades, entre
outras atividades. O Gerente da Qualidade deve ter uma visão do ambiente de
modo a entender o contexto do projeto dentro do contexto do negócio,
definindo qual será o controle e as responsabilidades da qualidade e como ela
deve interagir com o restante dos membros do projeto. Pode também,
identificar outros envolvidos com a qualidade na organização, definindo e
detalhando seus processos, sugerindo padrões, facilitando a modelagem,
gerenciando os relacionamentos externos à organização, dentre outras
atividades (Unhelkar, 2002)
Sommerville identifica quatro fatores que diretamente se relacionam com a
qualidade dos produtos de software: tecnologia de desenvolvimento; qualidade
dos processos; recursos humanos (qualidade das pessoas); e outros recursos
(orçamento, tempo e cronograma). No que tange a qualidade dos processos,
39
principal abordagem deste trabalho, estamos nos referindo ao grau de
satisfação e eficiência do processo ou um conjunto de processos, utilizados por
uma organização ou projeto para: planejar, gerenciar, executar, monitorar,
controlar e melhorar as atividades relacionadas à construção de software
(SPICE, 1995). Aspectos importantes sobre como a qualidade está inserida no
contexto das organizações produtoras de software são apresentados nas
seções a seguir.
2.2.1 – A Qualidade e sua Gestão no Projeto
Segundo Leite (Rocha et al., 2001), a visão atual de construção de software
agrega processos onde normas, procedimentos e gerência são bem definidos
para garantir a qualidade dos produtos. Bem diferente da visão tradicional de
processo de produção, onde a construção está centrada em fases e produtos.
Nesta nova visão, o papel da gerência passa a ser visto como um aspecto
técnico e estratégico, não somente como um aspecto exterior ao conhecimento
da engenharia de software. Leite cita que, para entender que o processo de
produção de software é composto por diferentes subsistemas (Freeman, 1987),
é importante entender o processo de produção de uma maneira mais ampla.
40
FIGURA 2.1 – Um modelo de Sistema de Desenvolvimento de Software.
FONTE adaptada de Ross (1977).
É necessária que a escolha dos métodos a serem utilizados no processo de
produção seja uma escolha gerencial ligada à qualidade, porque a qualidade
resultante será função dos métodos de produção escolhidos e seguidos. É
também importante que não se esqueça que a produção de software é um
processo que envolve, como parte fundamental, seres humanos. As
tecnologias de construção de software, nas quais se incluem as tecnologias de
gerenciamento, têm por objetivo automatizar ao máximo a construção de
software, mas ainda são fortemente dependentes da qualidade das equipes
envolvidas.
A qualidade deve estar presente não só nos produtos produzidos, como
também nos processos utilizados para gerar esses produtos de
desenvolvimento (Humphrey, 1995) (Jacobson et al., 1999). Neste caso os
41
processos de qualidade, ou de auditoria, são processos que se aplicam tanto
aos produtos, como aos próprios processos (uma meta aplicação dos
processos de qualidade). Mediante esta visão, aplicada ao modelo de Ross
(Ross, 1977) da Figura 2.1, para assegurar a qualidade dos produtos e dos
processos, a responsabilidade recai sobre o subsistema GERÊNCIA, que
necessita dispor de MÉTODOS e FERRAMENTAS compatíveis com a
qualidade desejada. A ação eficiente na função de garantir esta qualidade
exige conhecimento técnico sobre os MÉTODOS e FERRAMENTAS, além do
conhecimento de gerência para lidar com PESSOAL. Como base para qualquer
processo de gerência, deve existir um sistema de retroalimentação que forneça
ao subsistema GERÊNCIA as informações sobre o funcionamento do processo
para que eventuais problemas possam vir a serem corrigidos. Também é
necessário organizar as informações coletadas através de métricas, para que
se possa conhecer melhor os produtos produzidos, bem como os processos
utilizados na sua produção. A responsabilidade do armazenamento e da
distribuição dessas informações é do subsistema INFORMAÇÃO.
2.2.2 – A Qualidade e suas Responsabilidades no Projeto
Dentro deste aspecto de qualidade de produto e de processo, a gestão da
qualidade de software atua como uma atividade “guarda-chuva”, que é aplicada
ao longo de todo o processo de engenharia de software, podendo, segundo a
visão de Pressman (Pressman, 1995) abranger (1) a definição de métodos e
ferramentas para o desenvolvimento do produto; (2) revisões e técnicas formais
de avaliação que são aplicadas durante todo o ciclo de vida do produto; (3)
controle dos produtos, sua documentação e suas mudanças; (4) procedimentos
para a garantia e adequação aos padrões de desenvolvimento, quando
aplicáveis; (5) mecanismos de medição e divulgação. Além destas atividades,
podemos acrescentar a (6) criação de uma abordagem cultural da qualidade na
organização (Zulmer, 1989).
42
2.2.3 - A Qualidade e o Papel dos Envolvidos
Algumas das responsabilidades dos envolvidos no processo do gerenciamento
da qualidade são planejadas nas fases iniciais de um projeto, ou pré-
estabelecidas na estrutura organizacional da empresa de modo a, em linhas
gerais, identificar as expectativas dos usuários quanto ao produto a ser
desenvolvido, definir os padrões e procedimentos a serem usados no projeto,
revisar produtos e processos, solucionar problemas e propor melhorias no
projeto. Adicionado a isto, há uma tarefa preliminar muito importante que é
conseguir reunir as pessoas certas para o trabalho da qualidade. Os principais
papéis identificados no processo do gerenciamento da qualidade, segundo
Unhelkar (Unhelkar, 2002), são o do (1) Gerente da Qualidade, que organiza e
gerencia as funções da qualidade, incluindo a criação do ambiente da
qualidade; o do (2) Usuário, Clientes, gerentes e engenheiros de software
envolvidos no projeto, ligados diretamente às expectativas relacionadas com a
qualidade, aos quais os produtos e processos estão relacionados; o do (3)
Time da Qualidade: Analista, Revisor, Testador e Auditor são os principais
papéis, dentre outros, que cuidam das funções da qualidade; o de (4) outros
envolvidos: Gerente de Projeto, Gerente da Configuração, ou outras gerências
e os desenvolvedores, que poderão estar mais intensamente ligados à
qualidade dependendo da fase do ciclo de vida ou da atividade ao qual seu
produto ou processo estiver relacionado. A Figura 2.2 mostra os papéis mais
diretamente envolvidos com a qualidade.
43
Cliente
Gerenteda
Qualidade
Gerente da
Configuração
Analistada
Qualidade
Testador
Gerente de
Projeto
Revisor
Auditor
FIGURA 2.2 - Papéis dos envolvidos com a qualidade
FONTE adaptada de Unhelkar (2002).
Os envolvidos possuem papéis bem definidos nas atividades e tarefas do
projeto, com regras próprias e atribuições bem distintas no seu relacionamento
com a gestão da qualidade. Podem também ser inter-relacionados com os
outros papéis e ter denominações diferentes, dependendo da estrutura da
organização à qual pertencem.
2.2.3.1 – O Gerente da Qualidade
O Gerente da Qualidade é função derivada do Gerente do Projeto, mas com o
foco nos aspectos da qualidade. Requer um acesso independente às
atividades e produtos do projeto, provendo retorno do andamento destas
atividades às outras gerências. Organiza as inspeções, revisões e auditorias
44
dos produtos gerados durante o desenvolvimento do projeto, como também
direciona esforços na identificação de fatores como a qualidade do ambiente de
trabalho, a comunicação e os aspectos motivacionais no projeto. Estes fatores
tornam as atividades da gerência da qualidade muito próximas das de projeto.
2.2.3.2 – O Gerente de Projeto
O Gerente de Projeto é o papel do principal responsável pela condução do
desenvolvimento do software e de seus produtos relacionados, e pela
execução do processo de engenharia no projeto. Ele pode não agir diretamente
na confecção dos produtos, mas provê suporte para o ajuste fino do processo,
e pode ser o intermediário entre o Gerente da Qualidade e os membros da
equipe de engenharia, os desenvolvedores.
2.3.3.3 – O Gerente da Configuração
O Gerente da Configuração tem como principais atividades (Hass, 2002) a
identificação, o armazenamento, o controle de modificação e relato da situação
dos produtos de um projeto de software. A avaliação da configuração, o
gerenciamento da liberação e entrega dos produtos, bem como a manutenção
de cópias do código e da documentação por toda a vida do produto de software
também são atribuições dessa gerência. A atividade de auditoria ou avaliação
da configuração, incluída em algumas definições de atribuição da configuração
pode ser vista também como uma área de atividade da garantia da qualidade,
já que utiliza técnicas e métodos da garantia da qualidade, como revisões e
testes, além das informações da configuração na forma de relatórios de
situação.
45
2.3.3.4 – O Usuário ou Cliente
Apesar de a primeira responsabilidade do papel do Usuário estar relacionada
com o trabalho do Analista de Negócios, o Usuário é também importante para a
Qualidade. A primeira explicação para este fato é que o Cliente faz parte do
processo de testes de aceitação. Como este papel pode estar ligado
diretamente a confecção de Casos de Uso, diagramas de Atividades,
diagramas de Classes, ele pode também ajudar a criar um conjunto abrangente
de casos de teste endereçado ao plano de testes do projeto. Com esse
subsídio do Cliente é possível também aprimorar as futuras sessões de
treinamento do usuário ao final do projeto. Obviamente que a formulação dos
testes de aceitação não podem depender somente da visão do Cliente, mas
sim agregados a visão do Testador, que acrescentará testes técnicos
funcionais, testando as condições de contorno, condições de funcionamento
anormal e falhas no sistema, por exemplo.
Os membros da equipe de engenharia, os desenvolvedores, desempenham o
papel, de Usuários da qualidade, auxiliando na execução do processo. Isto
pode acontecer quando o desenvolvedor for um Autor de Produto (ou
processo), ou estiver ligado diretamente ao produto ou ao processo
instanciado. Ele pode, por exemplo, ser o Encaminhador de Produtos do
desenvolvimento do trabalho ao Analista da Qualidade, para sua devida
revisão, verificando e validando estes produtos de forma a obter o aceite da
qualidade. Poderá ser consultado sobre os produtos do projeto, desde a sua
alocação (nas primeiras fases do projeto) até a sua entrega (validação e aceite
do produto).
2.2.3.5 O Analista da Qualidade
O Analista da Qualidade executa todas as funções elementares da atividade da
qualidade no projeto. O nome Analista da Qualidade é comumente usado por
qualquer envolvido responsável pela qualidade de um produto a ser entregue.
Isto requer que o Analista da Qualidade seja capaz de entender o objeto a ser
46
manipulado pela qualidade, as atividades e as tarefas do processo e seja
capaz de dominar e utilizar a tecnologia empregada no projeto.
Preferencialmente, o Analista da Qualidade deve ser alguém que já tenha feito
alguma modelagem e trabalhos relacionados a processo em algum outro
projeto. A experiência prévia em criar modelos e trabalhar com processos pode
prover maior facilidade durante as atividades da qualidade como, inspeções,
revisões e auditorias realizadas durante o projeto.
Em muitas organizações o Analista da Qualidade trabalha muito próximo ao
Analista de Negócios, identificando, capturando, documentando e analisando
os requisitos. Também é seu papel certificar-se de que os aspectos mais
necessários do processo de qualidade foram executados.
Esse tipo de analista deve fazer uma verificação independente e robusta do
processo, bem como do produto do projeto. Dependendo do tamanho e do tipo
de projeto, bem como da estrutura organizacional, um Analista da Qualidade
pode se envolver em todos os níveis do desenvolvimento, ou ser solicitado
mais intensivamente só na fase de validação e entrega de produto.
2.2.3.6 – O Testador
O Testador é responsável pelo controle da qualidade do produto. Isto inclui,
mas não se limita, aos testes de produtos de software. Por exemplo, um
Testador cria um projeto de testes e os casos de teste, depois conduz os testes
e registra os resultados. Um grande auxílio que o Testador pode obter é a
colaboração de alguém da equipe de engenharia (quando ele mesmo não já
não é dela). Muitas vezes os programadores negligenciam este tipo de
atividade, acreditando que não existem erros possíveis de serem observados
após o desenvolvimento. Os scripts e os programas de teste devem atender
aos requisitos originalmente estabelecidos, e devem atender a três principais
47
visões: a de funcionalidade, a de tecnologia e a de arquitetura do sistema.
Ferramentas automáticas podem ser usadas para sua descrição, execução e
relato.
2.2.3.7 – O Revisor
O Revisor também é responsável pelo controle da qualidade do produto Este
papel está ligado principalmente a garantir que foram verificadas sintaxe,
semântica e estética dos produtos a serem entregues (um diagrama ou código,
ou documento). O Revisor pode executar diversos tipos de verificação: (1) de
do contrato: onde se observa se o fornecedor possui capacidade para
satisfazer os requisitos, se esses são coerentes, englobam todas as
necessidades do cliente, etc.; (2) de processo: onde se observa a adequação
do planejamento e do cronograma do projeto, o cumprimento das tarefas e dos
marcos estabelecidos no contrato, etc.; (3) de requisitos: onde se observa se
os requisitos do software em relação aos requisitos do sistema são coerentes,
factíveis e testáveis, etc.; (4) de projeto: onde se observa se o projeto está
correto e coerente com os requisitos, se ele implementa apropriadamente as
seqüências de eventos, entradas e saídas, requisitos de segurança, etc.; (5) de
código: onde se observa se o código está de acordo com os requisitos
funcionais e não funcionais, se é testável e correto, se atende aos padrões e
requisitos de codificação, etc.; (6) de integração: onde se observa se as
unidades e os componentes de código, bem como os itens de hardware e
software foram integrados completa e corretamente, de acordo com um plano
de integração; (7) de documentação: onde se observa se a documentação
está adequada, completa, coerente, produzida no tempo estabelecido e se a
gestão de configuração desses produtos segue os procedimentos
especificados.
O Revisor pode também atuar como uma espécie de intermediário nas revisões
conjuntas entre clientes e desenvolvedores, no interesse de uniformizar
48
conhecimento ou padronizar procedimentos. Dependendo da organização este
papel varia de atribuição.
2.2.3.8 – O Auditor
A atividade principal do Auditor é realizar um exame sistemático e
independente, para determinar se as atividades da qualidade e de configuração
estão de acordo com as disposições planejadas, se estas foram
implementadas com eficácia e se são adequadas à consecução dos objetivos
do projeto (ABNT8402, 1997).
As auditorias planejadas são aquelas definidas no Plano de Desenvolvimento
de Software do projeto. Exemplos destas auditorias são as de configuração
Funcional (para verificar se todos os requisitos foram atendidos) e de
configuração Física (para verificar que o software e sua documentação estão
completos e prontos para a entrega). Uma vez alcançada uma determinada
configuração de projeto (marco ou baseline) a ser auditada, prevista no Plano
de Desenvolvimento, a auditoria deverá ser realizada.
A atividade do Auditor pode estar também fortemente relacionada com o
controle da configuração do software, auxiliando a identificação e registro das
solicitações de modificações; analisando e avaliando as modificações;
aprovando ou desaprovando a solicitação, e na implementação, verificação e
liberação (release) do item de software modificado. Um procedimento de
auditoria deve existir de modo que cada modificação, com seu motivo e
autorização, possa ser controlada.
49
Uma das limitações da automação de processos, segundo Sommerville
(Sommerville, 2001) é a imensa diversidade de processos de desenvolvimento
de software. Não há um processo ideal e diferentes organizações têm
desenvolvido abordagens de diferentes níveis de complexidade. Processos
foram desenvolvidos para explorar a capacidade das pessoas na organização e
nas características específicas do sistema que está sendo construído. Modelos
como o de desenvolvimento cascata e o evolucionário são ainda os utilizados
para desenvolvimento da maioria dos sistemas. Já o modelo informal foi usado
com sucesso em alguns projetos (Mills et al., 1987) (Linger, 1994), mas ainda
são poucas as organizações que fazem uso deste modelo. O desenvolvimento
baseado em reuso talvez seja o modelo que mais tem influenciado os projetos
de software do século 21 (Sommerville, 2001). A idéia de construção de
projetos baseados em componentes, no modelo de reuso, é essencial para o
desenvolvimento de software rápido. Podemos também citar como modelos de
desenvolvimento de software os processos iterativos, como o incremental e o
espiral, que são ditos processos híbridos de desenvolvimento. Estes modelos
surgiram a partir das limitações da abordagem em cascata, e preconizam que o
desenvolvimento do software possa ser administrado numa série de
incrementos, onde poderia haver uma série de ciclos de vida em cascata para
cada incremento (Yordon, 1995).
Entretanto, mesmo com os muitos diferentes tipos de processo de
desenvolvimento de software, existem as atividades fundamentais que são
comuns a todos os processos. São elas:
Especificação de software: atividade que engloba a definição da
funcionalidade do software e suas restrições de operação;
Implementação e projeto de software: atividade que engloba a
especificação do software a ser produzido e a construção do produto;
Validação do software: atividade que engloba a validação do software
com a garantia de que ele faz o que o cliente (contrato) quer;
50
Evolução/manutenção de software: atividade que engloba o
desenvolvimento do software de modo a atender as mudanças
solicitadas pelo cliente.
Segundo esta visão, o gerenciamento da qualidade é implementado através de
todos os fluxos de trabalho (workflows), fases, e iterações do processo de
desenvolvimento de software. Na atividade de Especificação de software, o
gerenciamento da qualidade engloba a análise dos requisitos do conjunto de
produtos, para verificar consistência (entre padrões de artefatos e outros
produtos), clareza (clara comunicação entre os envolvidos e workers) e
precisão (nível de detalhe e acurácia apropriados). Na atividade de
Implementação e projeto de software a qualidade engloba a consistência do
modelo de projeto, sua tradução para os requisitos do produto, sua tradução
para a implementação e a verificação dos produtos em relação aos padrões de
projeto. Na atividade de Validação de software, a qualidade está envolvida
com a avaliação dos produtos de código fonte /executável contra os requisitos,
projeto e teste. Na atividade Evolução/ manutenção de software, a
qualidade, junto com o controle da configuração engloba a tradução da
solicitação de mudança em requisito do produto, a tradução para a
implementação e o encaminhamento para as outras atividades de ciclo de vida
pelas quais o produto deverá passar.
2.2.5 - A Qualidade e os Produtos de Software
Produto de software é o conjunto de programas, procedimentos e
possivelmente documentação e dados associados (ISO/IEC12207, 1995), que
são usados potencialmente como entradas e saídas de um processo
organizacional implementado (ISO/IEC15504-2, 1998).
51
Produtos do trabalho são os artefatos finais ou intermediários que são
produzidos e utilizados durante o desenvolvimento de um software, para
capturar e exprimir informações de projeto (Jacobson et al., 1999). Um artefato
pode ser (1) um documento, como o documento de estratégia de negócios ou o
documento de arquitetura de software, (2) um modelo, como um modelo de
caso de uso ou de projeto, (3) um elemento de um modelo, como uma classe
de um modelo ou (4) o código, incluindo programas fontes e código executável.
Modelos e elementos de modelos estão associados com relatórios, que
extraem informações sobre estes modelos de forma automatizada ou não. Um
relatório representa também um produto ou um conjunto de produtos. Para se
fazer o desenvolvimento gerencial de um sistema de software completo, os
produtos devem ser organizados em conjuntos que correspondam à fase ou ao
fluxo de trabalho correspondente a ele. Muitos produtos podem ser usados em
mais de uma fase, mas o produto vai sempre pertencer a fase em que foi
primeiramente produzido.
Isto quer dizer, que os produtos do trabalho possuem um ciclo de vida, que
consiste do ponto que se inicia sua concepção até o ponto em que é finalizado
o produto e disponibilizado para uso. Entretanto, como uma organização pode
produzir múltiplos produtos para múltiplos clientes, a descrição de ciclo de vida
de produto pode não ser adequada. Portanto, a organização pode definir um
conjunto de produtos aprovados dentro do modelo de ciclo de vida, sendo que
os modelos podem ser facilmente encontrados na literatura e devem ser
adaptados para uso na organização.
2.2.5.1 - As Categorias de Produto
Os produtos desenvolvidos durante as fases do ciclo de vida do software
podem ser categorizados de diversas maneiras. O mais importante é se
caracterizar (ou categorizar) o mesmo de modo a ser possível identificar,
52
acompanhar e manipular esses produtos no momento necessário à sua
utilização e de forma confiável. Atualmente, os produtos de um projeto são
utilizados como suporte a avaliações de maturidade de uma organização em
termos de capacidade, provendo evidências sobre um processo em particular,
ou sobre uma organização como um todo. Obviamente que uma metodologia
ou um julgamento mais apurado do avaliador é necessário para garantir o
contexto em que o processo é utilizado (domínio da aplicação, proposta do
negócio, metodologia de desenvolvimento, tamanho da organização, etc.)
quando se obtém esse tipo de informação (ISO/IEC15504-1, 1998).
Uma das formas de se caracterizar produto de software é através de três
principais categorias: organizacional, de projeto e de registro (ISO/IEC15504-5,
1998). A Tabela 2.1 mostra os principais produtos associados a estas
categorias.
TABELA 2.1 Classificação de Produto de Trabalho. Número
Categoria número Classificação
1 Organizacional
1.1 Política 1.2 Procedimento 1.3 Padrão 1.4 Estratégia
2 Projeto 2.1 Plano 2.2 Requisito 2.3 Projeto 2.4 Implementação 2.5 Produto 2.6 Entrega
3 Registro 3.1 Relatório 3.2 Registro 3.3 Medida 3.4 Dado
FONTE: ISO/IEC 15504-5 (1998).
53
No Apêndice B é apresentada uma tabela de produtos (adaptada do padrão
15504) classificados por categorias e relacionados aos processos da Garantia
da Qualidade do grupo Suporte.
2.2.6 - A Qualidade e os Marcos de Projeto
Outro fundamento importante, quando se trata do processo de gerenciamento e
construção de software, é de que cada dia mais o gerenciamento está baseado
no conceito de evolução (Leite, 1997), ou seja, sempre se está modificando
algum software já existente. Acredita-se que para lidar com evolução
constante, é fundamental utilizar o conceito de configuração base (baseline)
oriunda da área de configuração de sistemas. Uma baseline é uma espécie de
referencial que utilizamos durante o processo de construção/evolução de
software que deve servir como uma âncora, para que se possam gerir os
produtos e as mudanças de uma forma organizada.
Para que cada item da construção do software que se deseje efetivamente
controlado, é necessário o estabelecimento de pontos bem definidos dentro do
processo. Essas linhas de referência podem ocorrer ao final de cada uma das
fases de um processo de desenvolvimento, ou de algum outro modo definido
pela gerência. Os marcos são gerados para se prover o controle progressivo
das informações de projeto (código e documentação associada) descritos nos
vários itens projetados para o sistema. Nesses pontos estabelecidos, esses
itens devem ser identificados, analisados, revisados, corrigidos, aprovados e
armazenados em um local com algum tipo de controle de acesso. Este local
geralmente é chamado de repositório dos itens de configuração.
A gerência responsável pela gestão dos itens, ou produtos do trabalho, é a
Gerência da Configuração (GCS). O papel da GCS é identificar os chamados
itens de configuração, controlar suas modificações e versões durante todo o
seu ciclo de desenvolvimento e manutenção, ajudar a estabelecer os marcos
de projeto e configuração (junto às outras gerências), relatar a todos os
54
envolvidos o andamento dos produtos e das suas alterações. O papel da
Gerência da Qualidade (GQ) neste processo é realizar as revisões de
avaliação necessárias para que os produtos possam ser encaminhados para a
GCS, com o status revisado. As duas gerências atuam de forma muito próxima
durante todo o ciclo de vida do produto. Na visão da qualidade, pode-se
perceber este relacionamento estreito através do encaminhamento dos
produtos revisados para o controle de configuração, no acompanhamento dos
produtos que sofreram modificações ou da situação geral dos produtos em
relação aos marcos estabelecidos.
2.2.7 – A Qualidade e os Padrões
Uma das mais importantes e significantes contribuições da qualidade é no uso
adequado de padrões. O uso de padrões pode ser um recurso importante na
denominação dos produtos, no formato de diagramas, nos modelos de
documentos e na escolha dos produtos a serem entregues nas diversas fases
do desenvolvimento. Padrões não são entidades únicas aplicadas em todo o
projeto. Existem diferentes padrões nas diferentes áreas de um projeto e
diferentes fontes de padrões para a mesma área de um projeto.
2.2.7.1 – Áreas de Aplicações de Padrões
Um projeto baseado em padrões geralmente usa esses modelos em uma
grande variedade de áreas do ciclo de desenvolvimento do software. Por
exemplo, podem-se adotar padrões na modelagem do software, nos seus
processos, na modelagem da base de dados, na escolha da linguagem, na
qualidade e no modelo de gerenciamento do projeto.
Padrões de Modelagem: esses padrões ditam as notações, diagramas e
outros produtos associados para criar modelos no projeto do software.
55
No caso da Unified Modeling Language (UML), por exemplo, o padrão
provê vários tipos de modelos para os diagramas de um projeto de
software: ela é aceita em uma grande variedade de projetos e possui o
selo da ISO. Outras alternativas para padronização utilizam, por
exemplo, o Diagrama de Fluxo de Dados, Diagrama de Entidade–
Relacionamento entre outros.
Padrões de Processo: esses padrões ditam a maneira como o processo
é instanciado e desenvolvido em um projeto ou na organização como um
todo. Processos precisam de uma notação formal aceitável, descrita e
especificada em um formato, e seu desenvolvimento deve ser associado
com treinamento e suporte. Isto inclui a descrição formal das atividades
e tarefas, descrição do papel de cada responsável pelas tarefas no
processo, e modelos (templates) para os produtos resultantes. O CMM é
um exemplo de modelo de processo que provê medidas para revelar a
maturidade dos processos de software na organização ou em um projeto
em particular.
Padrões de Base de Dados: apesar de as ferramentas disponíveis
promoverem uma visão individual de seus padrões, o modelo relacional
beneficia e abrange grande parte dos padrões que seguem com o uso
de diagramas de Entidade-Relacionamento, bem como o uso de
normalização de tabelas relacionais. Para projetos de datawarehouse
(Kimball et al., 1998) pode-se considerar dois padrões: base de dados
de nomes de objeto e base de dados de nome e localização de arquivos
físicos.
Padrões de Linguagem: atualmente, projetos de software tendem a
colocar diversas linguagens juntas no seu desenvolvimento. Por
exemplo, uma aplicação servidora escrita em C++ e a aplicação cliente
rodando a linguagem JAVA. Com essa variedade e mistura de
linguagens, é importante seguir padrões de codificação. Seguindo
56
padrões bem definidos para essas diversas linguagens, é possível que
programadores em diferentes ambientes de desenvolvimento leiam e
façam manutenção de código de forma mais legível e fácil.
Naturalmente, padrões de linguagem devem ser adotados nas fases
iniciais de projeto, onde nomes de classes, atributos, operações fazem
parte dessas definições.
Padrões de Qualidade: padrões da qualidade podem, por exemplo,
descrever o ambiente da qualidade na organização (NBRISO9001,
2000), sugerir padrões para processos do ciclo de vida do software
(ISO/IEC12207, 2001) e podem relacionar-se com outros padrões.
Provêem modelos e gabaritos para documentos relacionados ao
gerenciamento da qualidade (plano da qualidade, por exemplo) e suas
necessidades específicas para a organização do trabalho entre os
envolvidos.
Padrões de Gerenciamento: podem ser derivados de padrões como o do
Project Management Institute (PMI). Esse tipo de padrão atua de forma
muito estreita com os padrões de processo, pois na prática, a criação e
padronização de um processo iterativo e incremental, por exemplo, é de
execução e responsabilidade do gerenciamento do projeto, atividade
ditada por padrões de gerenciamento.
2.2.8 – A Qualidade e Métricas de Software
O gerenciamento de um projeto de software agrega processos de tomada de
decisão, onde métricas podem ser úteis para fornecer uma base de
identificação de procedimentos que não estejam em conformidade com os
alvos pretendidos, bem como elas podem ser usadas como medidas de
atributos de projeto, auxiliando na elaboração de novas soluções que levem à
melhoria da qualidade (Yu e Lamb, 1995). Muitos autores têm trabalhado na
57
teoria das medições para métricas de software (Fenton e Pfleeger, 1997)
(Kitchenham et al., 1996) (Fenton, 1994) (Ambriola et al., 1994), e aplicado
métricas para controlar e estimar o desenvolvimento formal do software.
O primeiro passo para se elaborar um plano de medidas dentro de um projeto,
é fazer uma pesquisa, baseada em métricas, formulando os objetivos (em
forma de alvos) a serem alcançados: Qual é o propósito da pesquisa? Quem
usará as medidas e para que fim? Assim, os alvos podem ser refinados em
questões mais específicas, identificando-se métricas que forneçam respostas
quantitativas a estas questões.
2.2.8.1 – Categorias de Métricas
As principais categorias de métricas de qualidade são divididas nos seguintes
grupos:
Objetivas/Subjetivas: as objetivas são facilmente quantificadas e
medidas através de expressões numéricas ou representações gráficas
dessas expressões. As subjetivas são medidas relativas baseadas em
estimativas pessoais ou de grupo, sendo obtidas por termos lingüísticos
como alto, médio, baixo (Moller e Paulish, 1993).
Absolutas/Relativas: as absolutas são tipicamente invariantes para a
medição de novos itens, enquanto que as métricas relativas não.
Explícitas/Derivadas: as explícitas (ou diretas) quantificam um fator
observado em um único produto, enquanto as derivadas (ou indiretas)
envolvem medidas de um ou mais atributos relacionados a um produto
(Fenton, 1994) (Pressman, 1992).
Dinâmicas/Estáticas: as dinâmicas possuem uma dimensão temporal,
enquanto as estáticas permanecem invariáveis no tempo.
58
Preditivas/Explanatórias: as métricas preditivas (ou a priori) podem ser
obtidas ou geradas previamente, para realizar prognósticos do valor de
uma propriedade do sistema, que somente se tornará diretamente
observável em um estágio posterior a seu desenvolvimento
(Ponnambalam et al., 1996), enquanto as explanatórias (de resultado,
descritivas ou a posteriori) são geradas depois do fato ocorrido,
baseadas em dados coletados, indicando, simplesmente, o estado atual
do produto.
Existem, também, as métricas de produto (Ponnambalam et al., 1996)
(Bertolino e Strigini, 1996) (McCabe, 1976) e as métricas de processo (Moller e
Paulish, 1993). As métricas de produto indicam objetivamente as
características mensuráveis do produto de software, tal como tamanho,
complexidade, acoplamento. As métricas de processo medem aspectos de
desenvolvimento e manutenção e são, geralmente, usadas para caracterizar os
custos dessas atividades, como, por exemplo, quão efetivo é o processo de
remoção de defeitos.
Ponnambalam (Ponnambalam et al., 1996) considera, também, métricas de
projeto, como sendo da mesma importância que as métricas de produto e de
processos. Essa categoria de métrica mensura características de projeto e sua
execução como, por exemplo, o custo, o cronograma e o número de
desenvolvedores de software.
Munson (Munson, 1995) sugere, além das métricas de processo e de produto,
métricas de pessoal e de ambiente. As métricas de pessoal consideram os
recursos humanos, ao longo do processo de desenvolvimento. As métricas de
ambiente quantificam as circunstâncias físicas, que se referem à organização.
Na concepção de Moller e Paulish (Moller.e Paulish, 1993), as métricas podem
ser classificadas, ainda, em métricas globais e métricas de fase. Métricas
globais são indicadores de alto nível, que se disseminam ao longo do processo
de desenvolvimento do software, fornecendo direcionamentos para os
59
gerentes. Métricas de fase são indicadores somente para fases específicas do
processo de desenvolvimento do produto de software.
A qualidade de software é geralmente expressa em função de diversas
métricas de software, onde diferentes índices (Coleman et al., 1994) medem
diferentes aspectos de qualidade (Ponnambalam et al., 1996) (Oman et al.,
1994). Na prática, com o processo de medição, deseja-se saber se um bom
software é um bom negócio (Kitchenham et al., 1996).
2.2.9 - A Qualidade e a Documentação
Segundo Sanches (Sanches, 2001) a documentação de software é uma
atividade fundamental da qualidade no processo de desenvolvimento de
software. Cabe à documentação registrar a evolução do software, para que
sejam criadas as bases necessárias para uma melhor utilização e manutenção
do software.
Pela quantidade de atividades realizadas no desenvolvimento do software,
estima-se que cerca de 20% a 30% de todo o tempo empregado é dedicado à
elaboração de sua documentação (Parnas et al., 1994). Este valor torna
significativo, em termos de planejamento de projeto, o treinamento, o tempo e
os recursos humanos que devem ser alocados para esta atividade.
Sanches afirma também que, neste período, podem ser produzidos vários
documentos, retratando particularidades do projeto do software, ou do seu ciclo
de vida. Em acréscimo a isto, a documentação relacionada com o
desenvolvimento como contratos, documentos de sistema (que não o do
software), relatórios técnicos, descrição de procedimentos e de estratégias do
negócio, entre outros documentos, são manipulados pelos envolvidos no
projeto e devem ser, de alguma forma, controlados.
60
É importante que o documento do projeto de desenvolvimento de software
retrate fielmente o modo como as atividades de avaliação e modificação dos
produtos serão realizadas, procurando causar o menor impacto possível no
andamento do projeto. Muitos benefícios são obtidos a partir de uma
documentação cuidadosamente elaborada, tais como (Sanches, 2001):
Redução do tempo e do esforço despendido no desenvolvimento do
software.
Facilidade e maior eficiência no manuseio do software por parte dos
usuários.
Facilidade de localização das informações e melhor compreensão das
estruturas do software (Phoha, 1997).
2.2.10 - A Qualidade e a Estruturação de sua Gerência
O gerenciamento da qualidade de software diz respeito à garantia de que o
software tem um baixo número de defeitos e que o mesmo alcança os padrões
de manutenibilidade, confiabilidade, portabilidade, entre outros requisitos que
foram definidos no projeto. As atividades de gerenciamento da qualidade
incluem a garantia da qualidade, que define os padrões organizacionais para o
desenvolvimento de projetos de software, o planejamento da qualidade, que
define a estratégia da qualidade em um projeto e o controle da qualidade, que
verifica se o software atende esses padrões definidos. Portanto, a qualidade
pode ser estruturada, dentro de uma gerência, englobando três principais
atividades: garantia da qualidade, planejamento da qualidade e controle da
qualidade.
61
A garantia da qualidade consiste no estabelecimento de procedimentos e
padrões organizacionais, que levam a um software de alta qualidade e que
deverão ser aplicados no processo de desenvolvimento do software ou no
produto de software. Como padronização de produto pode-se citar, por
exemplo, a criação de um formulário de revisão de projeto, ou uma política para
a documentação de projeto, uma padronização para código em projetos, um
formato do plano de desenvolvimento ou de um formulário de requisição de
mudanças. Como padronização de processo pode-se citar os passos para a
condução da revisão/auditoria de projeto, o procedimento para a submissão de
documentos a uma gerência de configuração, o processo de controle de
mudanças, o processo de registro de teste, entre outros.
2.2.10.2 - O Planejamento da Qualidade
O planejamento define o conjunto de qualidades desejáveis aos produtos de
um projeto e também como estas qualidades devem ser verificadas. Envolve
também a seleção dos padrões organizacionais que serão apropriados a um
projeto (processo e produto) em particular. Essa atividade consiste
basicamente da adequação das políticas de revisões e auditorias ao projeto, da
seleção e adoção de padrões, da definição das atividades de subcontratados
(caso houver) no projeto, da definição dos papéis da qualidade no projeto, dos
meios de armazenamento dos produtos a serem gerados, da política de
controle da configuração e das modificações (quando for da atribuição da
qualidade), entre outras atividades.
2.2.10.3 – O Controle da Qualidade
O controle da qualidade é o processo que garante que os procedimentos e
padrões estão sendo seguidos durante o desenvolvimento de um software. Isto
62
é feito através de verificações, validações, auditorias e revisões conjuntas. A
verificação assegura que um produto do trabalho, ou parte dele, durante o
desenvolvimento do software, está sendo implementado corretamente ou que
os métodos e processos de desenvolvimento estão sendo aplicados
corretamente. A validação assegura que o software que está sendo
desenvolvido é o software correto, de acordo com os requisitos do usuário. A
revisão conjunta geralmente é empregada para se estabelecer um
entendimento comum entre as partes envolvidas. E a auditoria é empregada
para verificar se todos os requisitos foram atendidos, verificando o software e
sua documentação está completo e pronto para a entrega. O controle da
qualidade se propõe, também, a monitorar os resultados específicos do projeto
para determinar se eles estão de acordo com os padrões de qualidade
relevantes e, no caso da identificação de não-conformidades, durante a
execução de seus processos, e a agir de forma a encaminhar para tratamento
os desvios apresentados. São os chamados processos fundamentais da
qualidade.
63
64
65
CAPÍTULO 3
PADRÃO DE PROCESSO, LINGUAGEM DE MODELAGEM E O
AMBIENTE CENTRADO EM PROCESSO
Através do estudo de padrões é possível aprimorar as práticas de engenharia
de software, de modo a permitir alcançar melhores índices de qualidade e
confiabilidade nos produtos desenvolvidos e maior produtividade de
desenvolvimento. O padrão International Organization of
Standardization/International Electrotechnical Commission (ISO/IEC) 15504
(ISO/IEC15504-2, 2003), derivado do modelo de maturidade organizacional do
Software Process Improvement and Capability dEtermination (SPICE) (SPICE,
1995), se propõe a avaliar projetos e organizações de forma a verificar o nível
em que estas se encontram, em termos de maturidade dos processos
utilizados e das práticas organizacionais no desenvolvimento de projetos de
software. Já o padrão da ISO/IEC 12207 (ISO/IEC12207, 2001) descreve
processos para desenvolvimento e manutenção de software, fornecendo um
conjunto essencial de atividades que deverão ser completadas para obter um
produto de software. Finalmente, o modelo Capability Maturity Model
Integration (CMMI) (CMMI, 2002), que é um framework para avaliação e
melhoria de processo disponível para o desenvolvimento de produtos e
serviços, é patrocinado pelo Departamento de Defesa norte-americano, por
entidades do governo e da indústria, bem como pelo Software Engineering
Institute (SEI). Ele acomoda múltiplas disciplinas e é flexível tanto para verificar
o nível de maturidade dos processos, como para verificar o nível de maturidade
da organização em geral. Na seção 3.1 são identificados os processos desses
padrões relacionados com a qualidade, enfocando principalmente sua
compatibilidade com o padrão 15504, referência utilizada neste trabalho.
Após análise de quais são os processos básicos da qualidade mais adequados
para uma organização, ambiente ou projeto de desenvolvimento de software,
66
uma linguagem de modelagem de processo deve ser utilizada para definir e
representar os processos a serem implantados em um ambiente de engenharia
de software. Na seção 3.2 é apresentado o Software Process Engineering
Metamodel (SPEM) (SPEM, 2002) que, através de seus diagramas com
notação gráfica, permite representar de forma precisa e compreensível as
várias características ou elementos do processo de software para a
implantação e a execução em um ambiente de engenharia de software
centrado em processo. Na seção 3.3 é definido mais detalhadamente o
conceito de Ambientes de Engenharia de Software Centrados no Processo, os
chamados PSEEs, (Process-centered Software Engineering Environments),
que servem de apoio à implantação e à execução de processos de software. É
apresentado o Ambiente Integrado para Apoio ao Desenvolvimento e Gestão
de Projetos de Software, e-WebProject (Sant’Anna, 2000), que foi utilizado
como escopo 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.
3.1 – O Padrão ISO/IEC 15504
Em 1992, a ISO realizou um estudo chamado “Necessidades e exigências para
uma norma de avaliação de processo de software”, cujo resultado originou, em
janeiro de 1993, o projeto SPICE. Este projeto foi desenvolvido dentro do
subcomitê de engenharia de software, JTC/SC7, em elaboração conjunta pela
ISO e pelo IEC, que tinham como objetivo definir um framework para avaliação
de processos de engenharia de software e da organização de projeto e de
negócio. A última versão do SPICE como Relatório Técnico (TR-Technical
Report) foi aprovada em 1998, e a publicação do padrão ISO/IEC 15504, Parte
2, ocorreu em 30 de outubro de 2003.
O 15504 (ISO/IEC15504-5, 2003) possui um conjunto de documentos que
endereçam avaliação de processo, assessoria de treinamento e competência,
67
determinação da capacidade e melhoria de processo. Ele organiza e classifica
as práticas de engenharia de software em duas dimensões: de processo
(através de suas categorias) versus capacidade (através de seus níveis). No
Apêndice A podem se analisar as duas dimensões, de processo e de
capacidade, a partir de uma compilação reduzida, extraída da versão
Committeed Draft (CD) de 3 de Outubro de 2003. O contexto em que o padrão
atua é no de melhoria contínua e na determinação de capacidade, avaliando e
identificando as oportunidades de melhoria, bem como os riscos no emprego
de fornecedores (Salviano, 2003). Na dimensão de processo, o 15504 abrange
as categorias de processos Primários (ou Fundamentais), Organizacionais e de
Suporte, e dentro de cada categoria, grupos específicos de atuação, como
pode ser visto na Figura 3.1.
Na dimensão de capacidade, este modelo visa também avaliar a capacidade
da organização em cada processo, permitindo assim sua melhoria. Cada um
dos processos deve ser classificado em níveis (incompleto, executado,
gerenciado, estabelecido, previsível e otimizado).
Os processos e suas categorias estão contidos em um modelo de referência.
Este modelo de referência serve de base para o processo de avaliação como
um conjunto padronizado de processos fundamentais, que orientam para uma
boa engenharia de software.
68
FIGURA 3.1 - Categorias de Processos do ISO/IEC15504.
FONTE: ISO/IEC15504-5 (2003).
Processos do Ciclo de Vida PRIMÁRIOS
Processos do Ciclo de Vida de SUPORTE
AQUISIÇÃO(ACQ)
1) Preparação da aquisição 2) Seleção do fornecedor 3) Monitoração do fornecedor 4) Aceitação pelo cliente
FORNECIMENTO (SPL)
1) Proposição do fornecedor 2) Acordo do contrato 3) Liberação do software 4) Suporte à aceitação do software
ENGENHARIA (ENG)
01) Elicitação dos requisitos 02) Análise dos requisitos do sistema 03) Projeto de arquitetura do sistema 04) Análise de requisitos de software 05) Projeto de software 06) Construção do software 07) Integração do software 08) Teste do software 09) Instalação do software 10) Integração do sistema 11) Teste do sistema 12) Manutenção do sistema e do software
OPERAÇÃO (OPE) 1) Suporte ao cliente 2) Uso operacional
GERENCIAMENTO (MAN) 1) Alinhamento organizacional 2) Gerência da organização 3) Gerência de projeto 4) Gerência da qualidade 5) Gerência de risco 6) Medidas
Processos do Ciclo de Vida ORGANIZACIONAIS
MELHORIA DE PROCESSO (PIM) 1) Estabelecimento do processo 2) Avaliação do processo 3) Melhoria do processo
RECURSOS E INFRA-ESTRUTURA (RIN)
1) Gerência de recursos humanos 2) Treinamento 3) Gerência do conhecimento 4) Infra-estrutura
REUSO (REU) 1) Gerência de bens 2) Gerência do programa de reuso 3) Engenharia do domínio
CONTROLE DE CONFIGURAÇÃO (CFG) 1) Documentação 2) Gerência de configuração 3) Gerência de problemas 4) Gerência das solicitações da modificação
QUALIDADE DO PRODUTO (PRO) 1) Usabilidade 2) Avaliação de produto
GARANTIA DA QUALIDADE (QUA)
1) Garantia da qualidade 2) Verificação 3) Validação 4) Revisão conjunta 5) Auditoria
69
O nível de capacidade pode ser definido como um conjunto de práticas que
trabalham de forma conjunta para prover um maior ganho na capacidade de
execução de um processo. Cada nível estipula um ganho maior de capacidade
de execução do processo, constituindo um modo racional de melhoria da
capacidade de qualquer processo definido no 15504. São ao todo seis níveis
de capacidade descritos de forma simplificada na Figura 3.2.
FIGURA 3.2 – Níveis de Capacidade da ISO/IEC 15504.
FONTE: Salviano (2003).
A dimensão de capacidade é expressa no modelo de avaliação de processo em
termos de atributos de processo, PAs (Process Atributes), que são agrupados
em níveis de capacidade. PAs são características do processo que podem ser
avaliadas em uma escala de realização, provendo uma medida para a
capacidade do processo. Elas são aplicadas em todos os processos, e cada
PA descreve uma face de toda a capacidade de gerenciamento e melhoria que
todo processo busca.
O resultado de uma avaliação é um perfil da instituição em forma de matriz,
onde se têm os processos nas linhas e os níveis de capacitação nas colunas. A
Figura 3.3 exemplifica os atributos de processo necessários para os níveis
70
Incompleto, Executado e Gerenciado, de forma a poder atender as exigências
de cada capacidade.
FIGURA 3.3 - Atributos de processo para os Níveis 0, 1 e 2 do ISO/IEC15504.
FONTE: Moura et al. (2003).
A Figura 3.4 exemplifica os atributos de processo necessárias para os níveis
Estabelecido, Previsível e Otimizado, de forma a poder atender as exigências
de cada capacidade.
FIGURA 3.4 - Atributos de processo para os Níveis 3, 4 e 5 do ISO/IEC15504.
FONTE: Moura et al. (2003).
Incompleto
Executado
Gerenciado
(0) Falha em obter qualquer caracterização de processoPA: nenhum
(1) Proposta de processo alcançada, mas semplanejamento ou capacidade de rastreamentoPA1.1 Realização do processo
(2) Produto gerado dentro do tempo e doorçamento planejado, sem processo padrão
PA2.1 Gerenciamento realizadoPA2.2 Gerenciamento do produto do trabalho
Estabelecido
Previsível
Otimizado
(3) Processo é definido e segue princípios de engenharia desoftwarePA3.1 Definição do processoPA3.2 Recursos do processo
(4) Processo é controlado e medido, provendoentendimento quantitativoPA4.1 Medição do processoPA4.2 Controle do processo
(5) Processo segue os objetivos do negócio eé constantemente analisado / otimizadoPA5.1 Mudança do processoPA5.2 Melhoria contínua
71
Segundo a visão da gestão da qualidade deste estudo, as atividades da
qualidade estão presentes em toda a estrutura de uma organização produtora
de software. No padrão 15504 a categoria de Gerenciamento (MAN) consiste
dos processos que contêm práticas de natureza genérica, que podem ser
usadas por gerentes de projeto ou de processos de um ciclo de vida de
software. Dentre as diversas categorias, identifica-se no grupo Gerenciamento,
o processo Gerenciamento da Qualidade (MAN.4), que tem o propósito de
monitorar a qualidade dos produtos ou serviços e garantir a satisfação do
cliente. Este processo propõe o estabelecimento de um foco para o
monitoramento da qualidade de produto e processo, tanto no projeto como na
organização. Podem-se identificar também, na categoria Suporte (SUP), o
grupo Garantia da Qualidade (QUA), que contém os processos voltados para
as atividades da gestão da qualidade. A categoria SUP consiste dos processos
que podem ser aplicados por qualquer dos outros processos, inclusive do
próprio Suporte, nos vários pontos do ciclo de vida do software. Os processos
da categoria SUP Documentação (CFG.1 do grupo de Controle da
Configuração) e todos os processos do grupo QUA, Garantia da Qualidade
(QUA.1), Verificação (QUA.2), de Validação (QUA.3), de Revisão Conjunta
(QUA.4) e de Auditoria (QUA.5), bem como os processos Usabilidade (PRO.1)
e Avaliação de Produto (PRO.2) do grupo Qualidade de Produto, no
entendimento deste estudo, fazem parte do gerenciamento da qualidade.
3.1.1 – O Padrão ISO/IEC 12207 e o 15504
O padrão internacional ou modelo de referência ISO/IEC 12207 (ISO/IEC,
2001) – Tecnologia da Informação – Processos de Ciclo de Vida de Software é
usado como referência em muitos países, inclusive no Brasil, para alcançar um
patamar competitivo de qualidade e produtividade internacional. Tem como
principal objetivo auxiliar os envolvidos na produção de software a definir seus
papéis, por meio de processos bem definidos, e assim proporcionar, às
72
organizações que o utilizam, um melhor entendimento das atividades a serem
executadas nas operações que envolvem, de alguma forma, o software.
Tem como principal objetivo fornecer uma estrutura única para que o
adquirente, o fornecedor, o desenvolvedor, o mantenedor, o operador, os
gerentes e os técnicos envolvidos com o desenvolvimento de software utilizem
uma linguagem comum, que é estabelecida na forma de processos bem
definidos.
Sua estrutura foi concebida de maneira a ser flexível, modular e adaptável às
necessidades das organizações. Para isto, ele está fundamentado em dois
princípios básicos: modularidade e responsabilidade. Modularidade, no sentido
de processos com mínimo acoplamento e máxima coesão. Responsabilidade,
no sentido de estabelecer um responsável único por processo, facilitando a
aplicação do padrão em projetos onde várias pessoas podem estar legalmente
envolvidas.
Agrupa as atividades que podem ser executadas durante o ciclo de vida em
processos Primários, ou Fundamentais, de Suporte, e Organizacionais,
conforme ilustrado na Figura 3.5. Os processos Fundamentais atendem ao
contrato entre fornecedor e adquirente, à execução do desenvolvimento, à
operação e à manutenção de produtos de software durante o seu ciclo de
desenvolvimento. Os processo de Suporte auxiliam e contribuem para o
sucesso e a qualidade do projeto de software. Os processos Organizacionais
são empregados por uma organização para estabelecer e implementar uma
estrutura constituída pelos processos do ciclo de vida e pelo pessoal envolvido
no seu desenvolvimento. Cada processo é dividido em um conjunto de
atividades, e cada atividade, em um conjunto de tarefas. Os processos de
Suporte e Organizacionais devem existir independentemente da organização e
do projeto que está sendo executado.
73
FIGURA 3.5 – Classificação dos Processos do ISO/IEC12207.
FONTE traduzida: SEPT (2004).
Os processos Fundamentais são instanciados de acordo com a situação.
Esses processos, atividades e tarefas podem ser adaptados de acordo com as
características de um projeto de software.
PROCESSOS PRIMÁRIOS
PROCESSOS de SUPORTE
PROCESSOS ORGANIZACIONAIS
DOCUMENTAÇÃO
GERENCIAMENTO DA CONFIGURAÇÃO
GARANTIA DA QUALIDADE
VERIFICAÇÃO
RESOLUÇÃO DE PROBLEMA
USABILIDADE
AVALIAÇÃO DE PRODUTO
VALIDAÇÃO
REVISÃO CONJUNTA
AUDITORIA
OPERAÇÃO MANUTENÇÃO
AQUISIÇÃO FORNECIMENTO
DESENVOLVIMENTO
GERENCIAMENTO DE BENS
GERENCIAMENTO DE REUSO
ENGENHARIA DE DOMÍNIO
MELHORIA RECURSOS HUMANOS
GERENCIAMENTO INFRA-ESTRUTURA
Documento 12207
74
Enquanto o padrão ISO/IEC 15504 define uma estrutura para avaliação e
melhoria dos processos de engenharia de software, o 12207 preocupa-se com
os próprios processos. Ambos baseiam-se num modelo muito semelhante, de
modo que uma abordagem baseada no 12207 está alinhada ao 15504.
Segundo o 12207, os processos Fundamentais são responsáveis pela geração
dos produtos de software, constituindo o ciclo de vida de software propriamente
dito. Atendem ao início, à contratação entre o adquirente (organização que
adquire um sistema ou produto de software, podendo ser também representada
pelo comprador, cliente, proprietário ou usuário) e o fornecedor (organização
que fornece o sistema, serviço ou produto contratado). O desenvolvimento é o
processo-chave dos processos Fundamentais, incorporando as atividades que
vão desde a análise de requisitos até a implantação do software. Ao todo, este
grupo de processo é representado pelos processos de aquisição, fornecimento,
desenvolvimento, operação e manutenção.
Os processos de Suporte têm como objetivo auxiliar outros processos, visando
principalmente à qualidade e ao sucesso do projeto. É representado pelos
processos de documentação, gerenciamento da configuração, garantia da
qualidade, verificação, validação, revisão conjunta, auditoria, resolução de
problema, usabilidade e avaliação de produto.
Os processos Organizacionais têm como objetivo garantir e melhorar os
processos dentro da organização. É representado pelos processos de
gerenciamento, infra-estrutura, melhoria, recursos humanos, gerenciamento de
bens, gerenciamento do programa de reuso e de engenharia de domínio.
No 12207, pode-se entender que, dentre todos os processos, os relacionados
com as atividades da qualidade é o processo Gerenciamento da Qualidade que
é um dos processos de Gerenciamento do ciclo de vida Organizacional. Ele
tem o propósito de alcançar a satisfação do cliente através da monitoração da
qualidade dos produtos ou serviços no nível organizacional ou de projeto, para
garantir que seus requisitos sejam atendidos. Os processos Documentação,
75
Garantia da Qualidade, Verificação, Validação, Revisão Conjunta e Auditoria do
ciclo de vida Apoio têm suas funções atribuídas às atividades da qualidade.
Para a maioria dos processos do 12207 atualizados no Amendment 1, existe
uma correspondência com o 15504. Na versão 2003 do 15504, se faz
referência explícita o 12207, informando que, em alguns casos, o escopo do
modelo de referência é adaptado, de modo que uma avaliação de processo
baseado em um padrão 15504, ao ser aplicada em uma avaliação baseada no
12207, obtenha os mesmos resultados. A compatibilidade entre os processos
da qualidade do 15504 e do 12207 podem ser ilustradas na Tabela 3.1.
TABELA 3.1 - Compatibilidade entre a ISO/IEC 15504 e a 12207.
Identificação Processo 15504 Processo 12207 AMD 1
QUA.1 Garantia da Qualidade Anexo F; § F.2.3
QUA.2 Verificação Anexo F; § F.2.4
QUA.3 Validação Anexo F; § F.2.5
QUA.4 Revisão Conjunta Anexo F; § F.2.6
QUA.5 Auditoria Anexo F; § F.2.7
CFG.1 Documentação Anexo F; § F.2.1
MAN.4 Gerenciamento Qualidade Anexo F; § F.3.1.4.
FONTE: ISO/IEC15504-5 (2003).
Pode-se concluir que tanto o 12207 como o 15504 incluem as atividades do
gerenciamento da qualidade nos seus processos de forma compatível, com
modelos muito semelhantes, de modo que uma abordagem baseada no 12207
está alinhada ao 15504.
76
O projeto Capability Maturity Model Integration (CMMI) (CMMI, 2002) tem por
objetivo desenvolver um produto integrado de suporte ao processo e a melhoria
de produto tanto para a engenharia de sistemas Systems Engineering
Capability Model (SECM), como para a engenharia de software Capability
Maturity Model for Software (SW-CMM), como para também a integração do
desenvolvimento de produto Integrated Product Development Capability
Maturity Model (IPD-CMM).
O CMMI é patrocinado pelo Department of Defense (DoD) norte-americano e
pela National Defense Industrial Association (NDIA), com colaborações da
indústria, governo e pelo SEI norte-americano. Pode ser um modelo de
maturidade não somente para engenheiros de sistema e de software, mas
também para sistemas de desenvolvimento integrado de processo e produto,
os Integrated Product and Process Development (IPPD), engenharia de
sistemas e de software com fornecedores, os SS (Supplier Sourcing) e de
engenharia que integre IPPD e SS (Rout, 2002).
Pretende também reduzir o custo da implementação dos modelos de processo
base através de:
Eliminação de inconsistências, redução de duplicações.
Melhoria da clareza e entendimento.
Utilização de terminologia comum e estilo consistente.
Estabelecimento de regras de construção uniforme.
Manutenção de componentes comuns.
Sensibilidade às implicações dos esforços legados.
Além de integrar os diversos modelos CMMs existentes, como o SW-CMM, ele
pretende garantir compatibilidade com o ISO/IEC15504, através da sua visão
77
contínua de modelo, composto por áreas de processos universais e
fundamentais.
Possui dois modos de visão:
Continuos: semelhante ao 15504, com Áreas de Processo (Process
Areas) independentes do nível de maturidade.
Staged: abordagem semelhante ao SW-CMM, com novas Áreas de
Processo e alterações nas existentes.
O modelo Continuos é composto por áreas de processos universais e
fundamentais. Outra dimensão é composta por uma métrica para a avaliação
da capacidade de cada processo em uma organização. O exemplo mais
conhecido de modelo contínuo é o 15504. Na visão Continuos, qualquer área
de processo pode ter nível de capacidade entre 0 e 5 (Incompleto, Realizado,
Gerenciado, Definido, Quantitativamente Gerenciado e Otimizado). Para isso,
utiliza-se de dois tipos de objetivos e práticas:
Objetivos Genéricos, GGs (Generic Goals) e Práticas Genéricas GPs
(Generic Practices), associadas aos níveis e dissociadas das áreas de
processo.
Objetivos Específicos, SGs (Specific Goals) e Práticas Específicas, SPs
(Specific Practices), associadas às áreas de processo e dissociadas dos
níveis.
O SW-CMM, desenvolvido pelo SEI, é o exemplo mais conhecido dos modelos
Staged. O SW-CMM define cinco níveis seqüenciais de maturidade e as áreas
de processo para os níveis 2, 3, 4 e 5. Deste modo, para uma organização
estar com o seu processo de desenvolvimento e manutenção de software no
nível 3, este processo tem que satisfazer, caso apropriado, as áreas de
processo definidas nos níveis 2 e 3.
78
As áreas de processo, semelhante às categorias de processo da ISO/IEC
12207, são construídas em blocos. Cada objetivo específico possui um número
específico de práticas, que quando realizadas alcançarão um objetivo
específico:
Prática de Gerenciamento do Processo: Foco no Processo Organizacional;
Definição do Processo Organizacional; Treinamento Organizacional;
Gerenciamento Quantitativo da Qualidade e do Processo; Realização do
Processo Organizacional; Análise Causal e Resolução; Inovação Tecnológica
do Processo Organizacional; e Disponibilização do Processo de Inovação.
Prática de Gerenciamento do Projeto: Planejamento de Projeto; Monitoração e
Controle de Projeto; Gerenciamento de Acordo com Fornecedor;
Gerenciamento de Integração do Projeto; Gerenciamento de Risco; e
Gerenciamento Quantitativo de Projeto.
Prática de Engenharia: Gerenciamento de Requisitos; Desenvolvimento de
Requisitos; Soluções Técnicas; Integração do Produto; Verificação; e
Validação.
Prática de Suporte: Gerenciamento da Configuração; Garantia da Qualidade do
Produto e do Processo; Medições e Análises; Análise de Decisão e
Resoluções; e Análise Causal e Resoluções.
Como prática genérica para o nível 1 é estabelecida somente uma:
GP 1.1 Realizar práticas bases.
Como práticas genéricas para o nível 2, é proposto (Côrtes, 2001):
79
GP2.1 Estabelecer uma política organizacional para o planejamento e
execução do processo.
GP2.2 Planejar o processo.
GP2.3 Prover os recursos necessários para a execução do processo.
GP2.4 Definir e atribuir responsabilidades.
GP2.5 Providenciar o treinamento necessário para as pessoas
executarem o processo.
GP2.6 Gerenciar configurações e versões de produtos de trabalho
selecionados.
GP2.7 Monitorar e controlar a execução do processo.
GP2.8 Verificar a conformidade da execução do processo e dos
produtos de trabalho a procedimentos e padrões.
GP2.9 Submeter à análise gerencial os resultados e atividades do
processo.
Como prática genérica para o nível 3 é proposto:
GP3.1 Estabelecimento de um processo definido.
GP3.2 Coleta de informações de melhoria.
Como prática genérica para o nível 4 é proposto:
GP4.1 Estabelecimento de objetivos quantitativos para o processo.
GP4.2 Realização de subprocessos de forma estabilizada.
Como prática genérica para o nível 5 é proposto:
80
GP5.1 Garantia de melhoria contínua do processo.
GP5.2 Identificação da verdadeira causa de problemas.
Uma análise da representação do CMMI já foi realizada pelo Software Quality
Institute (SQI), a pedido do governo australiano, em 2001 (Rout et al., 2001),
com o intuito de avaliar sua compatibilidade com o modelo 15504
(ISO/IEC15504-2, 1998). O Departamento de Defesa australiano tinha
interesse em gerenciar a aquisição de software através de organizações
maduras em projetos (e processos) de engenharia de software. O estudo
concluiu que os elementos mais significantes do modelo CMMI tinham sido
endereçados com sucesso no padrão 15504. O exercício desse trabalho
proveu fundamentos para o desenvolvimento de um mecanismo de tradução,
para permitir que os resultados das avaliações baseadas no CMMI resultassem
num perfil de processo 15504. A Tabela 3.2 mostra, de forma simplificada,
como exemplo, os SGs e os SPs de um dos processos do CMMI, o da Garantia
da Qualidade de Processo e Produto em relação aos processos Suporte do
15504 (atualizado para a versão 2003).
81
Garantia da Qualidade de Processo e Produto
Suporte
Objetivos e Práticas Específicas CMMI (SG/SP)
ISO/IEC15504
SG 1 Avaliar Processos e Produtos do trabalho Objetivamente
QUA.1 QUA.2 QUA.3 QUA.5
SP 1.1-1 Avaliar Processos Objetivamente.
QUA.1 QUA.5
SP 1.2-1 Avaliar Produtos do Trabalho e Serviços Objetivamente.
QUA.1 QUA.2 QUA.3 QUA.5
SG 2 Prover Visão Objetiva QUA.1 QUA.4 QUA.5 CFG.3
SP 2.1-1 Comunicar e Garantir a Solução de Não-conformidades.
QUA.4 QUA.5 CFG.3
FONTE adaptada de Rout et al. (2001).
3.2 - A Linguagem de Modelagem de Processo
Processo é o principal elemento de um ambiente de desenvolvimento de
software. Como a qualidade dos produtos de software está diretamente ligada
à qualidade dos processos utilizados para seu desenvolvimento, há
necessidade de se formalizar os processos pelos quais são desenvolvidos
esses produtos. A modelagem de processos constitui-se num recurso
importante para se obter tal formalização. Para tal, um modelo deve
primeiramente ser construído para especificar como a atividade de engenharia
de software será conduzida, quais os papéis e tarefas envolvidos, os recursos
consumidos, as ferramentas utilizadas, os produtos desenvolvidos, bem como
os mecanismos de comunicação entre as tarefas e os papéis. Linguagens de
82
Modelagens de Processos, as chamadas Process Modelling Languages
(PMLs), são usadas para expressar esses modelos.
3.2.1 - Classificação das PMLs
Existem vários tipos diferentes de PMLs, utilizadas com propósitos diversos
(Zamli e Lee, 2001). Podem ser classificadas considerando-se, por exemplo, o
suporte à execução como critério. As linguagens podem ser executáveis,
quando permitem que o modelo do processo especificado seja executado,
possibilitando a condução ativa ou até mesmo o controle de um processo de
software; ou não-executáveis, quando provê em construções que permitem
somente a especificação de um processo de software, não sua execução. A
maioria das PMLs nesta categoria são derivadas de linguagens que já estão
em uso em outras áreas da engenharia, e tipicamente provêem construções
que permitem somente a especificação de um processo de software.
Seguindo uma similaridade com o ciclo de vida do desenvolvimento de
software, uma classificação pode ser obtida pela identificação das partes do
ciclo de vida do processo que a PML suporta, tendo-se assim Linguagens de
Especificação de Processos, Linguagens de Projeto de Processos e
Linguagens de Implementação de Processos.
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. A maioria das PMLs desta categoria são derivadas
83
de linguagem já usadas em outras áreas da engenharia e fornecem
construtores que possibilitam apenas a especificação do processo.
• Simulada: permite a simulação em alto nível de um modelo de
processo, que normalmente ajuda no projeto de novos processos de
software, mas não fornece uma orientação mais detalhada ou controle
do processo de software.
• Executável: 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
E3 (Environment for Experimenting and Envolving Software Processes)
(Jaccheri et al., 1998), (Jaccheri et al., 1999) e PROMENADE (Process-
oriented Modelling and Enactment of Software Developments) (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 meta-modelo UML como classes
prédefinidas.
84
As diversas abordagens de modelagem de processos apresentam diferentes
elementos de um processo. Segundo diversos autores (Acuña e Ferré, 2001)
(Fuggetta, 2000) (Conradi et al., 1994) (Feiler e Humphrey 1993) (Benali e
Derniane, 1992) (Finkelstein et al., 1994), verifica-se a existência de alguns
elementos comuns que devem ser estruturados em um modelo de processo:
• 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
encontram-se, provavelmente, organizadas 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 arbitrado a vários atores
cooperativos.
• Papéis: descrevem um conjunto de responsabilidades de agentes ou
grupos, os direitos e as habilidades requeridas para realizar uma
atividade específica do processo de software. São uma associação
entre agentes e atividades em termos de definição do conjunto de
responsabilidades executadas pelos agentes.
• 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
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,
dividida em outras atividades mais elementares. Pode também ser
organizada em redes com dimensão horizontal (encadeadas) e vertical
(decomposta). É associada a papéis, outras atividades e artefatos.
85
• Artefato ou Produto: é o (sub)produto e a matéria-prima de um
processo. Um artefato produzido por um processo pode ser usado
depois como matéria-prima para si mesmo ou para outros processos, de
modo a 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á entregue para um usuário é
chamado produto de software. Portanto, um relacionamento "composto
de" pode aparecer entre produtos, atividades e papéis.
Na Figura 3.6 mostram-se esses elementos e seus relacionamentos. Ainda
existem outros elementos possíveis, como eventos, projeto/organização, área
de trabalho (workspace), usuário, modelo de cooperação.
86
FIGURA 3.6 - Elementos e Relacionamentos de um Modelo de Processo.
FONTE: Acuña e Ferre (2001).
3.2.3 - Arquitetura da Modelagem
Um modelo está no primeiro nível de abstração acima dos itens de interesse
para o modelador. Já um meta-modelo está no segundo nível de abstração
para um modelador, e tem os próprios construtores de modelagem como seus
itens de interesse. Portanto, um meta-modelo deve ser construído de acordo
com um conjunto de regras restrito, que na maioria dos casos é derivado de
uma versão de atributo de entidade-relacionamento ou modelagem orientada a
objetos. 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 meta meta-modelos (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 MOF (Meta Object Facility), que define um meta meta-modelo (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 meta-modelos de
análise e projetos OO. Um meta meta-modelo é na verdade uma linguagem
que cria/define um meta-modelo, uma linguagem em que um meta-modelo
pode ser expresso. A integração entre meta-modelos se dá pelas interfaces
ATIVIDADE
PRODUTOATOR
PAPEL
Composto_de
Executa Saídas Entradas
Composto_de
Composto_de
Executa
87
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 Figura 3.7 mostra a arquitetura em 4 camadas de
modelagem definida pela OMG (Object Management Group), envolvendo os
níveis de abstração de modelagem. A OMG é uma organização internacional,
fundada em 1989, que promove a teoria e a prática da tecnologia da orientação
a objetos no desenvolvimento de software.
FIGURA 3.7 - Níveis de abstração da modelagem de processos. FONTE: SPEM (2002).
M3 MOF. Meta Object Facility
M2
M1
M0
Ex: UML, UMP, SPEM. Metamodelo de Processo . Esta camada serve como um template para o nível M1
Ex: RUP, Open. Esta camada inclui processos genéricos bem como a adequação específica destes processos em um dado projeto.
Um processo executável – isto é um processo de produção do mundo real – como ele é executado
88
3.2.4 - O SPEM – Meta-modelo de Engenharia de Processo de Software
O Software Process Engineering Metamodel (SPEM) é um meta-modelo que
pode ser usado para descrever um processo concreto ou uma família de
processos de desenvolvimento de software relacionados. A execução do
processo (enactment) não está no escopo deste modelo, o que o coloca,
portanto, na classe das linguagens de modelagem de processo não-
executáveis.
A linguagem SPEM foi desenvolvida pelo Grupo de Gerenciamento de Objetos,
a OMG, para tentar suprir a necessidade de um padrão para as técnicas de
modelagem de processo surgidas nos últimos anos. 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 Unified Modeling Language (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 meta-modelo, 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
O SPEM foi construído a partir do pacote SPEM_Foundations, que é baseado
em um subconjunto da UML 1.4, e do pacote SPEM_Extensions, que adiciona
as construções e a semântica necessários para a engenharia do processo de
software. Os subpacotes do SPEM_Extensions são: Elementos Básicos,
Dependências, Estrutura de Processo, Componentes do Processo e Ciclo de
Vida do Processo.
3.2.4.1 - 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 dinâmica 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 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.
Uma WorkDefinition é um tipo de Operation 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, como especificado pela classe ActivityParemeter.
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-
90
início com uma atividade A, então B pode iniciar somente depois que A
terminou.
Uma Phase é uma especialização de WorkDefinition. 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.
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, um código fonte. Descreve uma classe e uma
categoria de produto de trabalho produzido em um processo, como 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 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 WorkProducts 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.
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.
É possível agrupar Activity em uma Discipline. Uma Discipline é uma
especialização particular de Packages, que divide 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 Categorize fornece um meio de associar elementos de processo
a múltiplas categorias.
Como na UML, um Package é um recipiente que pode tanto possuir como
importar elementos de definição de processo. Package e a dependência
Categorize 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 Categorize 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. Tipos possíveis:
GuideLine, que é composto de um conjunto de regras e
recomendações sobre como um dado produto deve ser visto ou
organizado.
Technique é um algoritmo detalhado usado para criar um produto de
trabalho, e que ajuda a definir as habilidades requeridas para executar
tipos específicos de atividades.
92
UMLProfile fornece mecanismos que especializam a UML para uma
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.
ToolMentor, que mostra como usar uma ferramenta específica para
realizar uma atividade e está associado a uma única ferramenta.
CheckList, que representa uma lista de elementos que precisa ser
completada.
Template provê um documento de formato-padrão para um
determinado WorkProduct.
Estimate descreve o esforço associado a um elemento em particular.
3.2.4.2 - A notação SPEM
Diagramas da UML são 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 de Componentes não são usados porque
contêm alguns elementos semânticos da UML que foram excluídos do SPEM.
O diagrama de casos de uso, por exemplo, pode ilustrar o relacionamento entre
os envolvidos e as atividades do processo. As dependências realiza
(<<perform>>) e assiste (<<assist>>) podem ser usadas para definir as
relações entre um ator e o seu caso de uso.
93
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.
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, etc. A Tabela 3.3 mostra os
principais ícones utilizados no desenvolvimento dos modelos de processo.
94
TABELA 3.3 - 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.
FONTE: SPEM (2002).
95
3.3 - O Ambiente Centrado em Processo
Muitas das pesquisas na área de processo de software concluíram que
desenvolver software não é apenas uma questão de criar linguagens de
programação e ferramentas efetivas, mas é um esforço coletivo e criativo.
Assim, a qualidade do produto de software depende fortemente 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 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.
De maneira geral, um ciclo de vida do software define uma estrutura e uma
maneira de acordo com os quais o processo de software deve ser realizado. No
entanto, não prescreve uma direção precisa de ações a seguir, a forma de uma
organização; quais ferramentas e procedimentos operacionais adotar, quais as
políticas de desenvolvimento e restrições 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.
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.
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 em uma organização que desenvolve software.
Estas organizações diferem em sua cultura, habilidade das pessoas, produtos
entregue, estratégias comerciais e de desenvolvimento (Osterweil, 1987)
(Cugola e Ghezzi, 1998). Mesmo dentro de uma organização, projetos
96
diferentes apresentam variações de abordagens para o ciclo de vida e o ciclo
de desenvolvimento. 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 para um projeto específico e
levando 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 não desejados ou inesperados. Os produtos
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 modelos de qualidade e métodos de
melhoria de processo de software.
Um modelo de processo (Jaccheri et al., 1998) é um veículo para melhor
entendimento e comunicação do processo e pode ainda ser usado para
suportar as atividades de análise, simulação e execução do processo.
O desenvolvimento de modelos de processo é semelhante ao de software.
Requer 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 deveriam ser adequados ao processo
de desenvolvimento específico. Para satisfazer estes objetivos, Osterweil
(Osterweil, 1987) concluiu que seriam necessárias linguagens para descrição
dos processos de desenvolvimento de software. Os modelos resultantes
deveriam ser verificáveis e 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, 1998). Este ponto de vista estimulou uma área de pesquisa ativa,
voltada para o desenvolvimento de Ambientes de Engenharia de Software
Centrados no Processo (PSEEs, Process-centered Software Engineering
Environments) (Cugola e Ghezzi, 1998).
97
Os PSEEs são considerados como uma nova geração de ambientes de
desenvolvimento de software que podem ser adequados a cada projeto de
software específico, suprindo-os com o melhor suporte automatizado possível.
Eles suportam o processo de engenharia usado para conceber, projetar,
desenvolver e manter um produto de software através de uma representação
explícita do processo, ou modelo do processo. Tal modelo pode ser descrito
por meio de uma linguagem de modelagem de processo (PML, Process
Modeling Language) conveniente.
Uma máquina de processo, que é parte do PSEE, é utilizada para executar
(enact) o modelo de processo. Os PSEEs incluem ainda facilidades para editar
e analisar modelos de processos. Através da execução do modelo de
processo, um PSEE pode fornecer uma variedade de serviços, tais como
assistência para desenvolvedores de software, automação de tarefas rotineiras,
chamada e controle de ferramentas de desenvolvimento de software, e
aplicação de regras e práticas obrigatórias.
Dentre os diversos PSEEs existentes, podemos citar o SPADE-1 (Bandinelli et
al., 1996), Oz (Ben-Shaul e Kaiser, 1995) e o PROMENADE (Franch e Ribó,
1999).
3.3.1 - O e-WebProject - Ambiente Integrado para Gestão de Projetos de
Software
O Ambiente Integrado e-WebProject (Sant’Anna, 2000), atualmente em
desenvolvimento, serve como estudo de caso deste trabalho e pode ser
classificado como um ambiente centrado em processo (PSEE), utilizando
algumas das suas principais características (Abdala et al., 2003): 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
98
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 utilização de tecnologia para controle
dos processos envolvidos e a disponibilização 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 Integrado, para a obtenção de ganhos de produtividade. No e-
WebProject, são definidas categorias de gerenciamento estabelecidas pelo
Project Management Institute (PMI) (PMI, 1996) e acrescentadas outras para
melhor se adequar às necessidades específicas de projetos de software.
Dentre estas, a Gerência da Qualidade (GQ) compreende parte dos processos
de suporte ao desenvolvimento de software. Cabe ao Ambiente prover o apoio
necessário à implantação e à execução destes processos, de maneira que
cada gerência desempenhe com sucesso suas atividades.
3.3.2 - 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 lógica do Ambiente foi definida em três camadas:
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
99
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) com capacidade de
operação em modo gráfico e através de ambientes de janelas, possibilita
interação fácil e eficaz.
A arquitetura da camada lógica, ou conceitual do Ambiente, é apresentada na
Figura 3.8.
3.3.3 - A arquitetura física
O Ambiente leva dois aspectos em consideração à arquitetura física: os
requisitos propostos e a arquitetura conceitual. A abordagem utilizada segue o
modelo n-camadas para aplicações Web (Conallen, 2000). A camada 1
representa a interface com o usuário, a 3 a base de dados e a 2 as aplicações
desenvolvidas, como serviços ao cliente. A Figura 3.9 apresenta os
componentes da arquitetura física.
100
FIGURA 3.8 - A camada conceitual do Ambiente e-WebProject.
FONTE: Sant’Anna (2000).
FIGURA 3.9.- Arquitetura 3 camadas para aplicações Web.
FONTE: Sant’Anna (2000).
101
3.3.4 - Ciclo de Vida do Processo no Ambiente
O Ambiente Integrado e-WebProject propõe um modelo de processo de
desenvolvimento, levando em consideração principalmente o ciclo de vida do
produto e os envolvidos no processo. O Ambiente apresenta características
evolutivas e permite a configuração baseada nas necessidades organizacionais
e no elemento essencial do Ambiente, o processo (Sant’Anna, 2000). Para que
possa ser apoiado pelo Ambiente, um processo necessita ser detalhado e seu
modelo aprovado pela organização, transformando-se em um processo padrão
e efetivo. Este novo processo só 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.10 mostra como
exemplo o processo Auditar Produtos do Trabalho, adaptada da categoria de
processo do ISO/IEC 15504 (ISO/IEC15504-2,1998), que tem como objetivo
específico garantir que os produtos do trabalho e atividades dentro do
Ambiente estejam em conformidade com todos os padrões, procedimentos e
requisitos aplicáveis (Lahoz et al., 2002).
102
FIGURA 3.10 - Ciclo de vida do processo Auditar Produto.
FONTE: Lahoz et al. (2002).
3.3.4.1 - A Fase de Planejamento e Definição do Processo
Uma tarefa essencial para a automação de um processo é primeiramente
realizar seu planejamento. Para tal, é necessário que o modelo seja bem
entendido e aceito por toda a organização que dele se utilizará. 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. Para
este trabalho, 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.11.
A preparação do modelo de processo 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/ou saída) de
cada processo.
103
FIGURA 3.11 - A fase de planejamento.
FONTE: Sant’Anna (2000).
A preparação do modelo do processo deve abranger as seguintes atividades:
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 dos recursos necessários.
104
Definição das responsabilidades associando papéis às pessoas e aos
agentes.
Definição das métricas que serão utilizadas para monitorar o processo.
Definição dos pontos de controle para melhor acompanhar a execução
do processo.
3.3.4.2 - A Fase de Execução e Acompanhamento 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 neste estado pelo menos uma atividade que o inicia. A
execução desta atividade possibilita ao Ambiente instanciar uma ocorrência do
processo, devendo 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.
105
Informação aos gerentes e os participantes da execução do processo
informando 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 entra em um estado que é chamado de fechamento. O
fechamento é a fase onde o Ambiente cessa de apoiar o processo. Para parar
de prover este suporte, o Ambiente deve ter a preocupação de informar aos
gerentes e interessados que o Ambiente deixará de prover o apoio ao
determinado processo especificado, bem como deverá registrar em arquivos
históricos toda a informação referente ao trato do apoio ao processo
especificado. O término do suporte ao processo, normalmente, ocorre por
motivo de avaliação e melhoria do modelo-padrão definido para o processo.
A Figura 3.12 mostra os estados possíveis para um processo, quando em
execução.
106
FIGURA 3.12 – Os estados de um processo quando na etapa de execução.
FONTE: Sant’Anna (2000).
3.3.4.3 - A Fase de Avaliação e Proposta de Melhoria do Processo
Na fase de avaliação e melhoria do processo são compreendidas as atividades
relacionadas com a 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 necessidade 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 referente 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 ou saídas
do processo.
107
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.3.5 - 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
deve utilizar o conceito de fluxo de trabalho (workflow), empregar tecnologia
que possibilite automatizar processos, racionalizar suas potencialidades por
meio dos componentes, organização e tecnologia (Cruz, 1998).
A execução de processos no e-WebProject se dá por meio de um gerenciador
de fluxo de trabalho (Cereja Jr., 2003), 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 de 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 as suas determinações.
As execuções das tarefas podem 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).
108
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 e-WebProject 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 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.3.6 - As Gerências no e-WebProject
Dentro do Ambiente e-WebProject foram definidas as nove bases de categorias
de gerenciamento estabelecidas pelo PMI (PMI, 1996), porém ajustando
algumas e acrescentando outras para melhor se adequar as necessidades
especificas de projetos de software. Ao todo, foram onze áreas-chaves
definidas: a Gerência Geral de Projeto, a Gerência do Tempo, a Gerência do
Custo, a Gerência da Qualidade, a Gerência dos Recursos Humanos, a
Gerência da Comunicação, a Gerência de Risco, a Gerência de Fornecedores
e Sub-contratos, a Gerência de Requisitos, a Gerência das Modificações e das
Configurações e a Gerência 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.
109
3.3.6.1 - A Gerência da Qualidade no e-WebProject
A Gerência da Qualidade no e-WebProject é responsável pelos processos que
apoiem as atividades de projeto e de desenvolvimento de software, no sentido
de manipular todos os aspectos relacionados com a qualidade de produto e
processo. Consiste basicamente das atividades de garantia, planejamento e
controle da qualidade de software dos projetos que utilizarem o Ambiente.
Deve ser possível à Gerência da Qualidade o cadastramento, a manutenção e
a visualização de informações sobre (Sant’Anna, 2000):
O plano da qualidade adotada no projeto.
Os padrões (notação, documentação, código, telas, relatórios).
Os produtos encaminhados aceitos e controlados.
A situação dos produtos.
As revisões e auditorias dos produtos.
A conformidade com os padrões adotados.
O plano de melhoria.
Os históricos e as estatísticas.
Segundo a visão adotada para a Gerência da Qualidade no Ambiente, ela deve
prover verificações independentes no processo de desenvolvimento de
software. Os produtos gerados pelo processo de desenvolvimento são entrada
para as atividades da qualidade, e devem ser verificados para garantir que eles
sejam consistentes com os padrões e objetivos organizacionais. A equipe da
qualidade deve ter certa independência da equipe de desenvolvimento e da
equipe de gerenciamento de projeto, tendo uma visão imparcial e objetiva do
andamento do projeto. Ela deve relatar problemas, apontar dificuldades e
110
sugerir soluções para apreciação da alta gerência da organização. A Gerência
da Qualidade, a princípio, não deve estar compromissada com
responsabilidades de orçamento e cronograma do projeto.
Os dados coletados durante o desenvolvimento de um projeto, sejam estes
dados previstos ou não, devem ser registrados de forma a se poder
acompanhar a situação dos produtos, obtendo-se estatísticas referentes à
quantidade de produtos encaminhados, á quantidade de produtos aceitos
(índice de rejeição/aceitação), à quantidade de revisões/auditorias realizadas,
aos históricos referentes a informações temporais e qualitativas extraídas de
planos e procedimentos relativos aos produtos e aos padrões e sua situação
em um dado momento do projeto. Estes dados deverão servir para apresentar
a real evolução do desenvolvimento dos trabalhos, obtendo-se prognósticos
mais exatos para a definição das futuras ações a serem tomadas.
No que diz respeito aos processos da gestão da qualidade, é preciso detalhar
os fluxos de atividades, as pessoas envolvidas e os papéis que elas
desempenham naquele processo, os recursos e serviços necessários para sua
execução, bem como os produtos que serão controlados e gerados pelo
processo, isto tudo mediante o prévio estabelecimento de uma estrutura
organizacional maior que dê sustentação aos modelos propostos e sua gestão.
É necessário também identificar e atualizar as normas e padrões de processos
que estão voltados para a atividade da qualidade, para futura análise e
planejamento de implantação de novos processos, que atendam aos requisitos
da gestão da qualidade do Ambiente de forma íntegra e dos projetos que dele
se utilizarem.
111
112
113
CAPÍTULO 4
OS MODELOS DE PROCESSO DA QUALIDADE
Este capítulo apresenta a descrição e modelagem dos processos da qualidade
em um Ambiente Integrado para desenvolvimento e gestão de projetos de
software. Como apresentado no capítulo 2, o escopo da disciplina Qualidade e
de seus processos é amplo, bem como sua atuação no ciclo de vida de
desenvolvimento do software. Segundo o Swebok (Swebok, 2001), os maiores
processos discutidos na chamada área de conhecimento - KA (Knowledge
Area) da qualidade de software envolvem as atividades de Garantia da
Qualidade de Software – SQA (Software Quality Assurance) e de Verificação e
Validação (V&V, Verification & Validation). Essas atividades, além de afetarem
diretamente a qualidade final dos produtos de software, podem também ser um
auxílio fundamental na análise dos processos de desenvolvimento do software
e sua funcionalidade em um Ambiente Integrado. O planejamento cuidadoso
dessas atividades pode permitir efetivamente o alcance dos objetivos propostos
para o projeto, bem como o atendimento dos atributos da qualidade requeridos
para um software. Para o atendimento dos requisitos de qualidade do produto
final e dos produtos intermediários, é necessário também adotar a utilização de
um processo de Medição. Se as medições forem projetadas apropriadamente,
seus resultados podem aprimorar a qualidade de software (além de outros
aspectos dos processos de engenharia de software) de diversas formas:
podem auxiliar o gerenciamento do projeto na tomada de decisões; pode ajudar
a encontrar áreas problemáticas e gargalos durante o desenvolvimento dos
produtos de software; pode também auxiliar os desenvolvedores na avaliação
de seus produtos para a qualidade, bem como, em longo prazo, avaliar os
próprios processos da qualidade.
Sem a definição destas atividades da qualidade em um Ambiente Integrado, os
produtos e os processos de desenvolvimento de software podem ficar
114
extremamente prejudicados, e até mesmo comprometer o andamento de um
projeto. A definição e a modelagem dos processos da Qualidade, portanto, é o
foco principal da abordagem desta dissertação, cujo resultado deve ser
aplicado em ambientes de engenharia de software centrados em processo.
Segundo essa abordagem, um conjunto mínimo de processos da Qualidade
deve ser definido, utilizando para isto padrões de processo. Pretende-se
apresentar as atividades e práticas básicas que, se realizadas pelas
organizações que desenvolvem software, resultem no cumprimento dos
propósitos da qualidade definidos nessa abordagem e, conseqüentemente, em
melhores níveis de qualidade de produto e de processo destas organizações.
Para que um processo qualquer da qualidade seja efetivo, ele tem que ser
ajustado para reagir proporcionalmente ao esforço, às pessoas envolvidas, ao
escopo do grupo e às características do ciclo de vida do software adotado.
Estes parâmetros devem ser fornecidos pelo Ambiente Integrado quando da
instanciação de um determinado projeto. A idéia é fornecer um conjunto
mínimo de processos, chamados processos fundamentais da Qualidade, que
sejam suficientes para que as atividades básicas da qualidade atendam às
necessidades de uma organização fabricante de software e possam inclusive
planejar melhorias dos processos estabelecidos de modo a alcançar níveis
maiores de maturidade e capacitação na confecção de seus produtos.
Esta abordagem explora, ainda, as características de um Ambiente Integrado
que vêm atender às necessidades dos processos da Qualidade, quais sejam: a
capacidade de forçar o fluxo de trabalho e a disponibilidade de um conjunto de
ferramentas e serviços para, entre outras coisas, facilitar a comunicação entre
os envolvidos no processo.
Como visto no capítulo 3, o padrão ISO/IEC 15504 apresenta um modelo de
processo de referência, utilizado pelo 12207 e com o qual o CMMI tem
compatibilidade. São padrões internacionais de referência, que além da
possibilidade de se obter uma certificação de nível internacional, eles
115
representam um consenso da comunidade global a respeito de práticas
maduras de engenharia de software obtidas através de um processo rigoroso e
uniforme de escolha. Padrões internacionais representam também um conjunto
de convenções, requisitos técnicos ou práticas mais estáveis, facilitando o
desenvolvimento de processos relativamente difíceis e caros quando
implantados a partir de iniciativas isoladas e, principalmente, quando se trata
de tópicos especialmente controversos (Coallier, 2003).
Nestes padrões, os modelos de processo apresentam as atividades e práticas
básicas que a qualidade deve realizar, mas apenas em linhas gerais, ou seja,
O QUE o processo deve fazer, e não detalhes de COMO fazer para que o
processo seja implantado. Um processo precisa então ser definido, as práticas
básicas detalhadas, descritas as maneiras como estas devem ser
implementadas e os produtos que devem ser gerados. A modelagem de
processo é a técnica utilizada para representar os vários aspectos do processo
em questão, como visto no Capítulo 3. A modelagem em notação gráfica auxilia
no entendimento do processo, facilita sua documentação e, numa segunda
etapa, a tradução dos modelos para uma notação que possa ser executada
pela máquina de processo de um Ambiente Integrado. Ainda, com o
entendimento obtido, puderam ser identificados os vários níveis de automação
e serviços necessários que um Ambiente Integrado deve suprir para o apoio à
Qualidade.
Em resumo, o objetivo desse capítulo é apresentar como foi feita a definição
dos processos da Qualidade para um Ambiente Integrado, seus modelos
obtidos como resultado, tendo como referência todos os processos do Grupo
Garantia da Qualidade (QUA.1, Garantia da Qualidade, QUA.2, Verificação,
QUA.3 Validação, QUA.4, Revisão Conjunta e QUA.5, Auditoria), o processo
CFG.1, Documentação (do Grupo Controle de Configuração), e os processos
do Grupo Qualidade de Produto (PRO.1, Usabilidade e PRO.2, Avaliação de
Produto), todos da Categoria SUP, Suporte como apresentados na parte 5 do
ISO/IEC 15504. Também foi usado como referência o processo relacionado
116
com as atividades da Gerência da Qualidade (processo MAN.4, Gerenciamento
da Qualidade do Grupo Gerenciamento) da Categoria de processo ORG,
Organizacional, bem como em abordagens práticas encontradas na literatura,
referenciadas na bibliografia e apresentadas no capítulo 2. A definição e
modelagem dos processos da Qualidade são feitas abrangendo os requisitos
definidos por um Ambiente Integrado e divididos em quatro atividades
fundamentais: o Gerenciamento da Qualidade, a Garantia da Qualidade, o
Controle da Qualidade e a Qualidade de Produto. O Gerenciamento,
abrangendo as atividades da qualidade com o objetivo de cumprimento dos
seus requisitos, tanto no aspecto organizacional como de projeto. A Garantia
estabelece a garantia de que os produtos e processos estão em conformidade
com planos e estratégias pré-definidas. O Controle engloba os processos
básicos de suporte à verificação da qualidade. E a Garantia de Produto inclui
as atividades de garantia dos interesses e necessidades dos envolvidos com o
produto, no intuito de reduzir mudanças e rejeições, melhorando a
produtividade e qualidade desses produtos.
Ressalta-se ainda que os aspectos relacionados às atividades da qualidade
envolvidas diretamente no desenvolvimento de produtos (atividades ENG,
Grupo Engenharia), bem como às atividades relacionadas ao controle,
gerenciamento e manipulação de produtos (atividades CFG, Grupo
Gerenciamento da Configuração), não estão descritas nestes processos.
Acredita-se que estas atividades são de responsabilidade de gerências
específicas, como no do Ambiente Integrado e-WebProject, abordado no
capítulo 5, e não fazem parte do universo direto deste trabalho.
4.1 – O Escopo dos Processos da Qualidade
O aspecto de mais alto nível da qualidade no Ambiente Integrado é que será
chamado de Processo da Qualidade. Este processo, que compreende as
atividades da Qualidade no Ambiente Integrado, pode ser descrito em termos
117
de atividades relacionadas a papéis que utilizam/criam produtos. O Processo
da Qualidade foi dividido em quatro pacotes principais: Pacote Gerenciamento
da Qualidade, Pacote Garantia da Qualidade, Pacote Controle da Qualidade e
Pacote Qualidade de Produto. Esses processos podem ser representados
graficamente através da notação SPEM, conforme a Figura 4.1. Esta
subdivisão permite uma visão das atividades da qualidade em suas várias
dimensões, qual seja, organizacional, de projeto e de execução. A
nomenclatura adotada foi definida de forma a atender a estratégia da qualidade
proposta no trabalho sem pretender, entretanto, restringir os termos adotados,
muitas vezes, de forma diferente em outras abordagens relacionadas à
qualidade de software.
Gerenciamentoda
Qualidade
Garantiada
Qualidade
Controleda
Qualidade
Processo da Qualidade
Qualidadede
Produto
FIGURA 4.1 - Os processos da Qualidade.
Segundo Unhelkar (Unhelkar, 2002), o processo pode ser visto sob três
aspectos. Para se saber O QUE deve ser feito no processo de
desenvolvimento de um software devem-se definir os produtos (artefatos) a
serem desenvolvidos e o ferramental (guias, templates, ferramentas
automatizadas) utilizado no seu desenvolvimento, caracterizando a visão
118
tecnológica do processo. Também é importante saber COMO um processo em
particular é conduzido. Isto compreende uma seqüência de passos bem
definidos em uma ordem específica, caracterizando a visão metodológica do
processo. E, por fim, definir QUEM, ou seja, quais as pessoas que possuem
responsabilidades nas ações do processo e seguem a metodologia prescrita,
caracterizando a visão sociológica do processo.
No transcorrer deste capítulo é descrito O QUE, o COMO e QUEM envolvidos
na definição e modelagem de cada processo da Qualidade e em cada uma de
suas dimensões.
Para entender o contexto em que os processos da Qualidade estão inseridos
no processo de desenvolvimento do software, adaptou-se o diagrama de Meta-
modelo do Processo de Qualidade de Software de Unhelkar (Unhelkar, 2002),
Figura 4.2, descritos de modo simplificado, a visão de como os elementos do
processo são conectados e relacionados entre si. Usando a notação de
diagrama de classes da UML, podem-se identificar os Componentes do
Processo, que são feitos de Processos (Gerenciamento, Garantia, Controle da
Qualidade e Qualidade de Produto), Produtos e Papéis. Processos são
associados a Atividades. O Ciclo de Vida, cascata, espiral etc., provê um
recurso filosófico para a construção do Processo de Engenharia de Software
(PES), que é baseado em um Ciclo de Vida para criar/instanciar seus
Componentes do Processo. O PES também pode ser feito de Interações que
possuem incrementos.
119
Processos da Gerência da
Qualidade - GQ
Garantia Planejamento
Controle
Produtos do
Trabalho Papéis
Atividades
Processos deEngenharia de
Software
Interações (1, 2, 3,…)
Incrementos (1º, 2º, 3º,..)
Ciclo de Vida(cascata,
espiral, etc)
<<baseado em>> <<instanciados>>
FIGURA 4.2 – Meta-modelo do Processo de Qualidade de Software.
FONTE: Unhelkar (2002).
4.2 – A Estratégia para a Definição e Modelagem dos Processos da
Qualidade
O processo da Qualidade engloba o gerenciamento, a garantia, o controle da
qualidade e a qualidade de produto, condensando os aspectos tecnológicos,
metodológicos e sociais de uma organização fabricante de software, sob a
ótica da qualidade. Algumas de suas responsabilidades estão ligadas às
questões relacionadas à qualidade na organização como um todo, mas
também estão fortemente envolvidas com as atividades de planejamento de
projetos, na identificação de padrões (por exemplo, os padrões e modelos dos
diagramas a serem usados na representação da arquitetura do projeto), no
levantando das expectativas dos usuários (clientes, por exemplo), e o mais
importante, na atribuição das responsabilidades de trabalho das pessoas
envolvidas com a qualidade, principalmente no que tange garantir que os
padrões e procedimentos adotados pela qualidade na organização estão sendo
seguidos.
120
4.2.1 – Papéis e Responsabilidades nos Processos da Qualidade
Dentre os principais envolvidos e suas responsabilidade nos processos da
Qualidade podemos destacar:
O Gerente da Qualidade, que responde pela organização e
gerenciamento das funções da qualidade dentro do Ambiente Integrado,
sendo que suas atribuições estão fortemente dependentes do tipo de
projeto e da estrutura organizacional da empresa que utiliza este
Ambiente. 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.
O Gerente da Configuração, que é responsável pelo controle da
configuração e das modificações de produto, e que é responsável
também pelo repositório de artefatos e no auxílio à definição de quais
são os produtos a serem entregues ao final de cada fase do
desenvolvimento do projeto.
O Gerente de Projeto, que é o responsável geral pelo projeto e ao qual o
Gerente da Qualidade se reporta durante o andamento do projeto, com
relação a execução de algum processo da qualidade, no caso de
problemas ou para sua participa na divulgação dos resultados da
qualidade.
O Usuário ou Cliente, que é outro membro importante nos processos da
qualidade. É ele que provê ao Ambiente parte das expectativas com
relação à qualidade dos produtos e dá retorno se estas expectativas
foram alcançadas. Como usuário pode-se entender até os próprios
membros do projeto, como desenvolvedores ou terceiros que, de alguma
forma, estejam envolvidos no processo.
121
O Time da Qualidade, que cuida das funções práticas de planejamento e
execução das atividades de qualidade desta gerência. Este time,
formado por Revisores, Auditores, Testadores, entre outros, podem ser
pessoas da organização motivadas a desempenhar papéis da qualidade
no projeto e são responsáveis por seguir os padrões da qualidade
especificados. Devem prover as informações necessárias para a
condução do projeto, tanto no nível de projeto como no nível
organizacional.
O Agente Mensageiro, entidade computacional que realiza
automaticamente tarefas pré-determinadas dentro do Ambiente
Integrado. Ele auxilia o controle e execução de atividades pré-definidas,
como, por exemplo, realizar o serviço de comunicação automática de
notificação aos envolvidos de suas tarefas.
4.2.2 – Principais Atividades nos Processos da Qualidade
Nos processos da qualidade devem ser descritos os padrões a serem usados
em todos os níveis do desenvolvimento, incluindo o projeto, documentação,
codificação e padrões de teste. A documentação relacionada com a qualidade
no projeto inclui os recursos e cronogramas relacionados com o gerenciamento
da qualidade, bem como o gerenciamento do projeto como um todo. Essas
atividades podem ser consideradas como as principais formas de controle dos
produtos a serem entregues ao final de cada fase e/ou na entrega do produto
ao cliente.
O processo Gerenciamento da Qualidade é composto pelos processos de
definição das políticas e das atividades relacionadas com a qualidade na
organização e seu sistema de gerenciamento. Inclui também os objetivos da
qualidade, o estabelecimento dos padrões de produto, a política de
documentação de produtos, a política de divulgação de resultados, e outros
122
assuntos que dizem respeito à visão mais ampla e institucional desta gerência
nas suas atribuições organizacionais.
O processo Garantia da Qualidade é composto pelos processos de definição
da estratégia da garantia da qualidade nos projetos e na organização. Abrange
também a instanciação dos processos definidos pelo Gerenciamento da
Qualidade na forma de sua seleção e adaptação para um determinado projeto,
envolvendo atividades, produtos e papéis relacionados com o tipo de ciclo de
vida, metodologia de desenvolvimento, planejamento de projeto, controle da
configuração e outras características específicas do projeto a ser desenvolvido.
Inclui o tratamento de não-conformidades nos produtos e nos processos, tanto
no nível de projeto como no nível organizacional.
O processo Controle da Qualidade é composto dos chamados processos
básicos da qualidade. São os processos fundamentais, ou seja, os processos
de suporte às atividades da qualidade nos projetos e na organização como um
todo. São aqueles definidos pela Garantia da Qualidade e que vão ser
utilizados nas atividades de verificação, validação, auditoria, revisão conjunta e
comunicação dos resultados da qualidade.
O processo Qualidade de Produto é composto dos processos que garantam a
usabilidade dos produtos do projeto, principalmente no interesse da redução do
número de mudanças e de rejeição desses produtos, bem como na definição
dos processos de seu exame e de sua medição sistemática de acordo com
suas especificações e necessidades.
4.2.3 – Padrão e Notação Utilizados na Modelagem dos Processos da
Qualidade
Foram adotados como referência para a modelagem dos processos da
Qualidade o padrão de avaliação de processo 15504 e a notação SPEM da
Object Management Group (OMG), cujas principais características foram
descritas no capítulo 3. Utilizou-se como recurso gráfico de modelagem os
123
diagramas de pacote, de classe, de caso de uso, e de atividades propostos
pelo SPEM. Através do diagrama de caso de uso pode-se mostrar as relações
entre os papéis e as principais definições de trabalho dos processos, e com o
diagrama de atividades permite-se à 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. O diagrama de pacote permite agrupar as atividades, os
papéis e os produtos do trabalho de acordo com uma categoria geral de
elementos de descrição de um processo, ou seja, um tema comum.
Para apresentar os modelos de processo do Gerenciamento, Garantia e
Qualidade de Produto foi escolhido o diagrama de pacote. Este diagrama
apresenta claramente as práticas base da 15504 relacionadas ao processo
MAN.4, as práticas base QUA.1 e CFG.1 relacionadas com atividades
estratégicas do gerenciamento da qualidade, e as práticas base dos processos
PRO.1 e PRO.2, contemplando assim, aspectos organizacionais e de projeto
da qualidade propostos pelo padrão. Acredita-se que para este trabalho, o nível
de detalhamento do diagrama de pacote é suficiente para ilustrar as atividades
principais de Gerenciamento, Garantia e de Qualidade de Produto, tornando
possível à identificação das atividades que, em sua maior parte, são realizadas
pelo Gerente da Qualidade e pelo Analista da Qualidade.
Para apresentar os modelos de processo do Controle da Qualidade foi
escolhido, além do diagrama de pacote, o diagrama de caso de uso e o de
atividades. Esses dois diagramas modelam as práticas base da 15504 relativas
aos processos QUA.2, QUA.3, QUA.4 e QUA.5, do Grupo SUP. Estas práticas
dizem respeito à condução das atividades básicas da qualidade, como
verificação e validação de produtos e auditorias. O envolvimento de diversos
papéis e a necessidade de representar o fluxo de informações e das atividades
do processo induziu a utilização destes diagramas, tornando mais claro o
entendimento e a dinâmica dos processos do Controle da Qualidade.
124
Um outro tipo de diagrama, o de classe, foi utilizado para representar os
aspectos de relacionamento entre papéis e os produtos de trabalho de todo os
processos.
Os modelos da qualidade desenvolvidos nesta dissertação não se limitam só a
atender os processos do padrão 15504, mas também se propõem a possuir
uma visão abrangente da atuação da qualidade em projetos de
desenvolvimento de software, conforme apresentado nas seções seguintes
deste capítulo.
4.3 – A Modelagem dos Processos da Qualidade
Para o planejamento e definição dos modelos do processo, conforme descrito
na seção 3 do capítulo 3, inicialmente serão descritos e detalhadas as
atividades que o compõem no cotidiano da organização. Estas atividades são
descritas em termos de tarefas executadas e seus participantes, a alocação
dos indivíduos e produtos de trabalho necessários às tarefas, bem como a
especificação dos requisitos de entrada e saída de cada processo. Os passos
que foram adaptados do Ambiente Integrado e adotados para a preparação dos
modelos de processo da qualidade são os seguintes:
Descrição dos objetivos e dos requisitos básicos do processo a ser
modelado.
Identificação dos papéis, suas responsabilidades e produtos envolvidos
no processo.
Descrição do processo em atividades executáveis e factíveis
descrevendo os procedimento para execução destas tarefas.
125
4.3.1 – Pacote Gerenciamento da Qualidade
O pacote que engloba os processos relacionados ao Gerenciamento da
Qualidade abrange os processos de definição das políticas e das atividades
relacionadas com a qualidade na organização como um todo. Isto implica em
alcançar os objetivos da qualidade sob o ponto de vista da organização,
prevendo com isto: a gestão de diversos projetos ao mesmo tempo, a
necessidade de definir políticas diferentes de desenvolvimento de produto, a
utilização de padrões, a utilização de procedimentos e a utilização de pessoal
da qualidade alocado para estes projetos simultâneos. São de sua
responsabilidade o estabelecimento do sistema de gerenciamento da
qualidade, a política de medições da qualidade, de divulgação de resultados,
de tratamento de não-conformidades, entre outros assuntos que dizem respeito
à visão mais ampla e institucional desta gerência nas suas atribuições
organizacionais. Deve existir também a preocupação com a memória dos
projetos, a fim de facilitar a tomada de decisões e permitir previsões mais
confiáveis dos recursos necessários da qualidade em projetos futuros.
4.3.1.1 – Objetivos e Requisitos Básicos do Pacote
O objetivo principal desse pacote é determinar todas as práticas da qualidade,
no nível gerencial, de acordo com os requisitos definidos nesta subseção, de
maneira que os processos sejam utilizados de forma eficiente e clara e que os
resultados obtidos possam ser avaliados e divulgados entre os envolvidos no
processo. Os processos visam estabelecer padrões de desenvolvimento para
produtos e para processos de software, bem como garantir o gerenciamento e
bom desempenho no desenvolvimento de software no nível organizacional.
Estabelece ainda uma estratégia geral da qualidade modo que os projetos
possam atender seus requisitos de qualidade.
126
Os principais requisitos desse pacote são:
O sistema de gerenciamento da qualidade devem ser estabelecido: a
Qualidade deve criar e manter um sistema de gerenciamento para a
organização e consequentemente para os projetos, de modo a atender suas
atividades mínimas necessárias, qual seja, implementar, monitorar e controlar
as ações preventivas e corretivas da qualidade.
Os objetivos da qualidade devem ser definidos: a Qualidade deve traçar tanto
de forma geral (organizacional) como particular (projetos), quais são seus
objetivos básicos. Essas diretrizes permitirão conduzir todas as atividades da
qualidade de forma alinhada com os objetivos de negócio da organização.
A estratégia geral da qualidade deve ser definida: deve ser desenvolvida a
estratégia geral da qualidade incluindo os recursos e responsabilidades para a
obtenção dos seus objetivos e da contínua melhoria da qualidade.
Os padrões de produto devem ser estabelecidos: padrões para documentação
de projeto, de diagramas, de interface com o usuário, de código, de rotinas de
teste, de documentos da qualidade, como templates e checklists, bem como
qualquer outro padrão de produto que seja de uso da organização ou de
projetos.
Uma política de documentação de produto deve ser definida: uma política para
os documentos de produto em projetos deve ser definida de modo a atender
seus requisitos de desenvolvimento, principalmente no que tange ao tipo de
aplicação de software e seu ciclo de desenvolvimento.
Uma estratégia para medições da Qualidade na organização deve ser definida:
devem ser definidas métricas de software para uso em projetos e na
organização com um todo, a fim de quantificar e avaliar a qualidade do
software em desenvolvimento, bem como o impacto de mudanças
metodológicas, procedimentais e estruturais na organização.
127
Os objetivos da qualidade devem ser avaliados: deve ser avaliado se os
objetivos básicos definidos para a qualidade, tanto de forma geral
(organizacional) como particular (projetos), foram alcançados. Esta avaliação
permitirá conduzir todas as atividades da qualidade de forma alinhada com os
objetivos de negócio da organização.
As não-conformidades dos produtos e dos processos devem ser tratadas: os
produtos e processos que, em qualquer momento, forem identificados com
algum tipo de problema, não-conformidade ou desvio, devem ser
encaminhados ao processo de gerenciamento de problemas. Tem por objetivo
rotular e conduzir a não-conformidade ao processo de gerenciamento de
problema para solução e reenvio a qualidade.
Uma política para divulgação dos resultados da qualidade deve ser adotada: os
resultados das revisões, auditorias, desvios, resultados dos testes e outras
atividades da qualidade devem ser levados ao conhecimento dos envolvidos,
tendo como base a necessidade de manter o conhecimento difundido e
homogêneo no projeto e na organização.
Os requisitos do pacote Gerenciamento da Qualidade podem ser
representados, através do diagrama de Pacotes, Figura 4.3, que abrange os
processos relacionados com esta categoria.
128
Gerenciamentoda Qualidade
Definição dosObjetivos da
Qualidade
Estabelecimentodos Padrões de
Produto
Definição daEstratégia Geral
da Qualidade
Avaliação dos Objetivosda Qualidade
Estabelecimento doSistema de
Gerenciamento daQualidade
Definição da Política deDivulgação de Resultados
da Qualidade
Política deTratamento de
Não-Conformidades
Definição daPolítica de
Documentação deProduto
Definição da Estratégiade Medições da
Qualidade
FIGURA 4.3 - Pacote Gerenciamento da Qualidade.
129
4.3.1.2 – Papéis, Responsabilidades e Produtos Envolvidos no Pacote
O Gerente da Qualidade fica responsável pelo estabelecimento dos processos
fundamentais da qualidade, pela definição dos papéis e responsabilidades do
time da qualidade, pela definição dos objetivos da qualidade, pela definição das
políticas e pelas estratégias da qualidade na organização. Os principais
produtos de trabalho envolvidos neste processo são os documentos de Política
Geral da Organização, de Política Organizacional da Qualidade, de Política de
Documentação de Projeto, de Política de Treinamento da Qualidade, de
Relatório da Qualidade, de Avaliação da Qualidade e o documento que contém
a estratégia de Medições da Qualidade. O diagrama de classe da Figura 4.4
mostra o relacionamento entre o Gerente da Qualidade e os produtos
associados com o pacote Gerenciamento da Qualidade.
1
*
1
*
PolíticaOrganizacionalda Qualidade
Política deTreinamento da
Qualidade
1
*
Política Geral daOrganização
Relatório daAvaliação da
Qualidade
Medições daQualidade
Formulário deEncaminhamento de
Problemas
Política deDocumentação
1
*1
*
1
*
Produtos daQualidade
(apoio)
Gerenteda
Qualidade1
*
1
*
Plano daQualidade
1
*
Relatório daQualidade
FIGURA 4.4 – Os produtos envolvidos com o Gerente da Qualidade no pacote
Gerenciamento da Qualidade.
130
O Analista da Qualidade fica responsável por definir os produtos de apoio e os
templates dos produtos de desenvolvimento de software. Produtos de apoio
significam os produtos associados às revisões, auditorias, como o Checklist de
Verificação, de Validação, de Revisão Conjunta e de Auditoria e os de padrões
de projeto, como os Guias de Diagramas, de Código entre outros. Os produtos
relacionados com as medições que devem ser adotadas em projetos, como o
documento contendo os tipos de Medidas de Código, Medidas de Projeto e de
Processo que devem ser utilizados, também estão entre os produtos de
responsabilidade do Analista da Qualidade. O Formulário de Encaminhamento
de Problemas é de sua responsabilidade, bem como o do formato geral dos
produtos mínimos a serem desenvolvidos em um projeto de software, os
chamados produtos de desenvolvimento, como o template do Plano da
Qualidade e do Plano de Testes. O Relatório da Qualidade e de sua avaliação
também fazem parte do rol de documentos da responsabilidade do Analista. A
Figura 4.5 detalha o relacionamento entre o Analista da Qualidade e os
produtos associados como o pacote Gerenciamento da Qualidade.
131
1
*
1 *
1
*
1
*
Produtos daQualidade
(desenvolvimento)
Analistada
Qualidade
Formulário deAvaliação de
ProdutoCheklists deVerificação
Cheklists deValidação
TemplatePlano deTestes
Artefatos deSoftware
Guia de Padrões deDocumentação
Guia de Padrões deDiagramas
Guia de Padrões deInterfaces do
Usuário
Guia de Padrões deCódigo
Guia de Padrões deMódulos de Teste
Guia de Padrões deTemplates
Relatório daAvaliação da
Qualidade
Cheklists deRequisitos da
Qualidade
PolíticaOrganizacionalda Qualidade
Medidas deSoftware
Medições daQualidade
Medidas deProjeto
Medidas deProcesso
Política deDocumentação de
Projeto
Modelos deCiclo de Vida de
Projeto
Produtos daQualidade
(apoio)
TemplatePlano da
Qualidade
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1 *
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
Relatório daAuditoria
Cheklists deRevisão Conjunta
Cheklists deAuditoria
Solicitaçãode Revisão
Conjunta
1
*
1
*
1
*
Formulário deEncaminhamento
de Problemas
1
*
Relatório daQualidade
1
*
FIGURA 4.5 – Os produtos envolvidos com o Analista da Qualidade no pacote
Gerenciamento da Qualidade.
132
4.3.1.3 – Atividades do Pacote
O diagrama de pacote do processo Gerenciamento da Qualidade agrupa as
atividades, os papéis e os produtos do trabalho de acordo com os elementos
comuns das práticas da qualidade no nível organizacional e de projeto, de
maneira a disponibilizar os recursos necessários ao desenvolvimento das
atividades da qualidade de software. Entende-se que, através destes
processos, vários projetos, de diversas abordagens metodológicas, possam
utilizar estes recursos de forma eficiente e clara e os resultados obtidos
possam ser avaliados e divulgados entre os envolvidos no processo.
É importante frisar que as atividades, papéis e produtos envolvidos nestes
processos são o conjunto mínimo necessário para a organização e seus
projetos do ponto de vista do funcionamento da qualidade. Qualquer proposta
para a criação de um novo processo fica sujeita a 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 um Ambiente Integrado.
133
4.3.1.3.1 – Pacote Estabelecimento do Sistema de Gerenciamento da
Qualidade
O pacote Estabelecimento do Sistema de Gerenciamento da Qualidade, Figura
4.6, estabelece os processos básicos da qualidade para a organização e
conseqüentemente, para os projetos, de modo a atender suas funcionalidades
mínimas, qual seja, verificar e validar produtos, realizar auditorias e revisões
conjuntas entre outras. Para isto, utilizando como referência o Plano
Organizacional da Qualidade, este processo estabelece as atividades
fundamentais que posteriormente serão utilizados para controle da qualidade, e
estabelece os produtos associados com este processo. São associados os
produtos de desenvolvimento, como templates dos produtos estabelecidos no
pacote de Definição da Política de Documentação de Produto (templates para o
Plano da Qualidade, e para Plano de Testes) e produtos de apoio, onde são
criados os checklists das revisões (Checklist de Verificação, de Validação, de
Revisão Conjunta e de Auditoria) e formulários (Formulário de Avaliação de
Produto, Relatório de Auditoria e Solicitação de Revisão Conjunta).
134
Gerente da Qualidade - GQ
Estabelecer Processo de Verificação & Validação ( )
Estabelecer Processo de Revisão Conjunta ( )
Formulário deAvaliação de
Produto
Política Organizacionalda Qualidade
Estabelecer Processo de Auditoria ( )
Relatório daAuditoria
Analista da Qualidade
Definir Produtos Associados a Verificação ( )
Definir Produtos Associados a Revisão Conjunta ( )
Definir Produtos Associados a Validação ( )
Definir Produtos Associados a Auditoria ( )
Cheklists deVerificação
Cheklists deValidação
Cheklists deRevisãoConjunta
Cheklists deAuditoria
templatePlano deTestes
Estabelecimento doSistema de Gerenciamento
da Qualidade
Solicitaçãode Revisão
Artefatos deSoftware
templatePlano da
Qualidade
Estabelecer Procedimento de Ação Corretiva ( )
Plano da Qualidade
FIGURA 4.6 – O Pacote Estabelecimento do Sistema de Gerenciamento da
Qualidade.
135
4.3.1.3.2 – Pacote Definição dos Objetivos da Qualidade
O pacote Definição dos Objetivos da Qualidade, Figura 4.7 define de forma
geral (organizacional) como em particular (projetos), quais são os objetivos
básicos da qualidade na condução de todas as atividades da qualidade, de
forma alinhada com os objetivos de negócio da organização. Para isto este
processo se baseia no documento que trata da Política Geral da Organização,
e produz o documento de Política Organizacional da Qualidade. Define também
os principais itens do Relatório da Avaliação da Qualidade e os principais itens
relacionados ao documento de Medições da Qualidade.
Gerente da Qualidade - GQ
Estabelecer os Objetivos da Qualidade ( )
Alinhar os Objetivos da Qualidade aos Objetivosdo Negócio ( )
PolíticaOrganizacionalda Qualidade
Política Geralda Organização
Definição dosObjetivos da
Qualidade
Relatório daAvaliação da
Qualidade
Medições daQualidade
Estabelecer Critérios para Avaliação da Qualidadede Processo e Produto ( )
FIGURA 4.7- O Pacote Definição dos Objetivos da Qualidade.
136
4.3.1.3.3 – Pacote Definição da Estratégia Geral da Qualidade
O pacote Definição da Estratégia Geral da Qualidade, Figura 4.8, define os
principais papéis dos envolvidos com a qualidade na organização e nos
projetos, que tem como responsabilidade atender as atividades da qualidade,
como revisões e auditorias. Estes papéis e suas responsabilidade deverão
estar contidos no documento de Política Organizacional da Qualidade, bem
como os recursos necessários para o andamento normal dos trabalhos da
qualidade. Este processo também gera um outro produto que é o documento
da Política de Treinamento da Qualidade, cujas diretrizes comporão a política
de treinamento do time, para capacitação de suas funções.
Gerente da Qualidade - GQ
Definir os Papéis da Qualidade na Organização ( )
Definir Política de Treinamento da Qualidade ( )
Política Organizacionalda Qualidade
Política de Treinamentoda Qualidade
Definição daEstratégia Geral
da Qualidade
Definir os Recursos para a Qualidade ( )
FIGURA 4.8 - O Pacote Definição da Estratégia Geral da Qualidade.
137
4.3.1.3.4 – Pacote Estabelecimento dos Padrões de Produto
O pacote Estabelecimento dos Padrões de Produto, Figura 4.9 define as
atividades de padronização para produtos em projetos, criando guias de
padrões (Guia de Padrões para Documentação de Projeto, de Diagramas, de
Interface com o Usuário, de Código e Guia para a criação de Templates),
contendo as referências normativas que devem ser adotadas. Os guias devem
contemplar as possíveis abordagens metodológicas que um projeto pode ter. O
documento contendo a política de documentação de projeto, indiretamente, faz
parte desse pacote.
138
Analista da Qualidade
Estabelecer Padrões para Interfaces do Usuário ( )
Establecer Padrões para Módulos de Teste ( )
Estabelecer Padrões para Documentação emProjeto ( )
Estabelecer Padrões para Código ( )
Estabelecer Padrões para Templates ( )
Estabelecer Padrões para Diagramas ( )
Guia de Padrões deDocumentação
Guia de Padrões deDiagramas
Guia de Padrões deInterfaces do
Usuário
Guia de Padrões deCódigo
Guia de Padrões deMódulos de Teste
Guia de Padrões deTemplates
Estabelecimentodos Padrões de
Produto
Estabelecer Padrões para Documentação daOrganização ( )
FIGURA 4.9 - O Pacote Estabelecimento dos Padrões de Produto.
139
4.3.1.3.5 – Pacote Definição da Política de Documentação
O pacote Definição da Política de Documentação, Figura 4.10, estabelece a
estratégia para documentação de produto na organização, principalmente com
relação à qualidade nos projetos, de modo a atender os requisitos de
desenvolvimento. O processo define um conjunto de templates (templates do
Plano da Qualidade e do Plano de Testes) considerados, para a organização,
como indispensáveis para a qualidade em projetos de software. Este processo
não impede que, caso se queira alterar esse conjunto mínimo de
documentação da qualidade, sejam acrescidos novos templates ao pacote.
140
Gerente da Qualidade - GQ
Política Organizacional daQualidade
Analista da Qualidade
Definir Requisitos de Documentação ( )
Definir Estratégia de Documentação para Projetos ( )
Definição da Política deDocumentação
Definir Estratégia de Documentação para aOrganização ( )
Definir Padrões para a Documentação ( )
Política de Documentação
Modelos de Ciclode Vida de Projeto
TemplatePlano deTestes
TemplatePlano da
Qualidade
FIGURA 4.10 - O Pacote Definição da Política de Documentação de Produto.
141
4.3.1.3.6 – Pacote Definição da Estratégia de Medições da Qualidade
O pacote Definição da Estratégia de Medições da Qualidade, Figura 4.11,
estabelece a estratégia para medições da Qualidade na organização definindo
algumas métricas de software para uso em projetos e na organização com um
todo. Como isto, é possível quantificar e avaliar a qualidade do software em
desenvolvimento e o impacto de mudanças metodológicas, e estruturais na
organização. Com base na Política Organizacional da Qualidade um
documento contendo as Medições da Qualidade é gerado, com seus
respectivos guias de medições (Medidas de Software, Projeto e Processo) para
uso no Relatório da Qualidade e de sua avaliação.
142
Gerente da Qualidade - GQ
Política Organizacional daQualidade
Analista da Qualidade
Definir Métricas de Projeto ( )
Medidas deSoftware
Analisar Medidas ( )
Tomar Decisões ( )
Medições da Qualidade
Definir Métricas de Prcesso ( )
Definir Métricas de Software ( )
Definir Métricas Organizacionais ( )
Medições da Qualidade Medidas deProjeto
Medidas deProcesso
Definição da Estratégiade Medições da
Qualidade
Relatório daAvaliação da
QualidadeRelatório daQualidade
FIGURA 4.11 - O Pacote Definição da Estratégia de Medições da Qualidade.
143
4.3.1.3.7 – Pacote Avaliação dos Objetivos da Qualidade
O pacote Avaliação dos Objetivos da Qualidade, Figura 4.12, estabelece a
política de auditoria para os requisitos básicos definidos para a qualidade, tanto
de forma geral (organizacional) como particular (projetos), e os critérios para
avaliação se os objetivos foram alcançados. Esta avaliação permite conduzir
todas as atividades da qualidade de forma alinhada com os objetivos de
negócio da organização. Para isto o processo utiliza a documento contendo a
Política Organizacional da Qualidade, gerando o Relatório de Avaliação da
Auditoria e seu checklist de Requisitos.
144
Gerente da Qualidade - GQ
Estabelecer Política de Auditoria da Qualidade ( )
Política Organizacional daQualidade
Relatório daAvaliação da
Qualidade
Analista da Qualidade
Auditar Requisitos da Qualidade ( )
Cheklists deRequisitos da
Qualidade
Estabelecer Critérios para Avaliação da Qualidade ( )
Avaliação dos Objetivosda Qualidade
Relatório daQualidade
Medições daQualidade
Medidas deProjeto
Medidas deProcesso
FIGURA 4.12 – O Pacote Avaliação dos Objetivos da Qualidade.
145
4.3.1.3.8 – Pacote Política de Tratamento de Não-Conformidades
O pacote Política de Tratamento de Não-conformidades, Figura 4.13,
estabelece o processo que trata do encaminhamento das não-conformidades
dos produtos e dos processos envolvidos na execução de um processo da
qualidade em qualquer momento da vida do projeto ou da organização. Se
algum envolvido identificar algum tipo de problema, não-conformidade ou
desvio, este processo deve ser instanciado, através da abertura do Formulário
de Encaminhamento de Problemas. Este formulário abrange também outros
processos que não só os da qualidade. No caso específico dos processos da
qualidade, o envolvido que identificaria um problema, além do Gerente, alguém
do Time da Qualidade, como por exemplo, o Revisor. Ele abre este formulário,
que é encaminhado ao Gerente da Qualidade, que faz uma análise prévia do
grau de severidade e de implicação do problema, classificando o mesmo,
segundo critérios estabelecidos. Posteriormente o formulário é encaminhado ao
Analista de Problemas para solução. O Analista de Problemas se encarregará,
dependendo do tipo de problema, de envolver outros participantes para
solução. No caso específico desta abordagem, a atividade de Gerenciamento
de Problemas (CFG.3 do Grupo Controle de Configuração) é de
responsabilidade dos processos relacionados ao controle de configuração
(principalmente os problemas relativos ao desenvolvimento de projeto),
devendo a qualidade somente tratar inicialmente deste encaminhamento para
solução. Mesmo com o registro do problema no Formulário de
Encaminhamento de Problemas, o Relatório da Qualidade deve ser emitido,
apresentando as não-conformidades do produto ou processo.
146
Gerente da Qualidade - GQ
Definir Política de Ação Corretiva ( )
Política deTratamento de
Não-Conformidades
Formulário deEncaminhamento de
Problemas
Definir Política de Ação Preventiva ( )
Relatório daQualidade
Política Organizacionalda Qualidade
Plano da Qualidade
FIGURA 4.13 – O Pacote Política de Tratamento de Não-Conformidades.
147
4.3.1.3.9 – Pacote de Definição da Política de Divulgação de Resultados da
Qualidade
O pacote de Definição da Política de Divulgação de Resultados da Qualidade,
Figura 4.14, define a estratégia para divulgação dos resultados da qualidade,
tanto no nível organizacional com de projetos, baseado nos registros do
Relatório da Avaliação da Qualidade, no Formulário de Avaliação de Produto,
no Relatório da Auditoria e de seus documentos relacionados.
148
Gerente da Qualidade - GQ
PolíticaOrganizacionalda Qualidade
Analista da Qualidade
Definir os Registros da Qualidade para Divulgaçãono Nível Organizacional( )
Definir os Agentes Envolvidos na Divulgação ( )
Definir Estratégia de Divulgação da Qualidade naOrganização ( )
Definir Estratégia de Divulgação da Qualidade emProjetos ( )
Definir os Registros da Qualidade para Divulgaçãono Nível de Projeto ( )
Formulário deAvaliação de
Produto
Relatório daAuditoria
Medidas deSoftware
Medições daQualidade
Medidas deProjeto
Medidas deProcesso
Definição da Política deDivulgação de Resultados
da Qualidade
Relatório daAvaliação da
Qualidade
Relatório daQualidade
Relatório daQualidade
Relatório daAvaliação da
Qualidade
FIGURA 4.14 - O Pacote Definição da Política de Divulgação de Resultados da
Qualidade.
149
4.3.2 - Pacote Garantia da Qualidade
O pacote Garantia da Qualidade abrange os processos relacionados às
atividades que garantem que produtos e processos do trabalho estão em
conformidade com os planos e procedimentos pré-definidos, com a devida
adequação e instanciação dos processos e produtos definidos pelo
Gerenciamento da Qualidade para um projeto específico. Isto significa que
processos são devidamente selecionados e adaptados para um determinado
projeto, envolvendo atividades, produtos e papéis relacionados com o tipo de
ciclo de vida, metodologia de desenvolvimento, planejamento de projeto,
controle da configuração e outras características específicas do projeto a ser
desenvolvido. Para isto é necessário selecionar os padrões pertinentes à
metodologia adota, bem como, agregar aos documentos mínimos
estabelecidos no projeto outros necessários. Também pode ser necessário
adequar os processos estabelecidos pelo Gerenciamento da Qualidade em
conjunto com uma política própria para as atividades (verificação, validação,
revisão conjunta e auditoria) associada a produtos. A seleção dos membros do
time da qualidade necessários à condução do projeto, os marcos de projeto e
as informações da qualidade a serem difundidas, é tarefa fundamental para a
efetiva realização deste processo.
4.3.2.1 – Objetivos e Requisitos Básicos do Pacote
O objetivo principal desse pacote é utilizar práticas da qualidade, no nível de
garantia da qualidade, de acordo com os requisitos organizacionais definidos
pelo Gerenciamento da Qualidade, de maneira que os processos sejam
utilizados de forma eficiente e clara e que os resultados obtidos possam ser
avaliados e divulgados entre os envolvidos no processo. Tem também como
objetivo definir e adequar atividades, documentos, políticas e papéis às
características de cada projeto, de modo a atender os requisitos da qualidade
estabelecidos pela organização.
150
Os principais requisitos desse pacote são:
Uma estratégia para a garantia da qualidade em projetos deve ser
desenvolvida: uma estratégia para a condução das atividades de garantia da
qualidade, no nível de projeto, deve ser definida, consistente com a estratégia
da qualidade no nível organizacional.
Os registros da qualidade no projeto devem ser definidos: as informações
pertinentes ao acompanhamento da qualidade, junto aos marcos e aos
envolvidos no projeto, devem ser definidas para divulgação e acompanhamento
das atividades das atividades relacionadas à qualidade. Tem por objetivo definir
as informações que a qualidade utilizará para auxiliar a alta gerência (e a
própria Gerência da Qualidade) a tomar decisões e manter os envolvidos
informados sobre o andamento das atividades no projeto.
Padrões devem ser selecionados em um projeto: padrões de documentação,
diagramas, código entre outros, devem ser selecionados e adequados
observando as características metodológicas e de implementação do projeto.
Tem como objetivo manter o desenvolvimento do projeto dentro de padrões
pré-estabelecidos de documentação respeitando as características da
abordagem utilizada.
Uma documentação para o projeto deve ser selecionada: deve ser
estabelecido, identificado e categorizado um conjunto de documentos de
projeto, de acordo com a política de documentação da organização, e do
contrato de projeto. Tem por objetivo estabelecer e identificar os produtos a
serem gerados no projeto a fim de se poder controlar e manipular os mesmos.
Uma política de verificação e de validação no projeto deve ser definida: deve
ser definida qual será a política de verificações e validações que devem estar
associadas a marcos e produtos do projeto. Tem por objetivo verificar e validar
qualquer produto após ser encaminhado ao Ambiente para ser controlado no
projeto.
151
Uma política de revisão conjunta e de auditoria no projeto deve ser definida:
deve ser definida qual será a política de auditorias e de revisões conjuntas que
estarão associadas a marcos e produtos do projeto. Tem como objetivo,
principalmente no caso da auditoria, promover o desenvolvimento do projeto
para um novo marco e, no caso da revisão conjunta, ser útil para manter um
entendimento comum entre os envolvidos no projeto.
Os registros das atividades da garantia da qualidade devem ser produzidos e
armazenados: os registros dos produtos e dos processos da qualidade devem
ser identificados, extraídos e armazenados para futura divulgação e consulta
dos envolvidos tanto no nível organizacional como no de projetos. Tem por
objetivo auxiliar a tomada de decisão e o entendimento do processo por parte
dos membros envolvidos direta e indiretamente aos produtos e processos.
As não-conformidades devem ser identificadas: qualquer problema, desvio ou
não-conformidade deve ser identificado, verificando seu grau de severidade e
encaminhando para as devidas providências de solução ao Ambiente
Integrado.
Os requisitos do pacote Garantia da Qualidade podem ser representados
através da Figura 4.15, que abrange os processos relacionados com esta
categoria.
152
Garantia da Qualidade
Seleção dePadrões
para o Projeto Definição da
Estratégia de Garantiada Qualidade em
Projeto
Definição da Políticade Revisão Conjuntae Auditoria no Projeto
Definição dosRegistros da
Qualidade no Projeto
Definição da Políticade Verificação e
Validação no Projeto
Identificação deNão-Conformidades
Seleção daDocumentação de
Projeto
Extração dosRegistros da
Qualidade
FIGURA 4.15 - Pacote Garantia da Qualidade.
153
4.3.2.2 - Papéis, Responsabilidades e Produtos Envolvidos no Pacote
O Gerente da Qualidade, nesse pacote fica responsável pelas adequações,
políticas e definições das atividades e padrões de um projeto específico. Isto
inclui a seleção e adequação dos processos fundamentais da qualidade para
um projeto, pela definição das políticas de revisão (verificação, validação e
revisão conjunta) e auditoria, pela adequação dos padrões para o projeto, pelo
estabelecimento dos requisitos de documentação do projeto, por associar
papéis às responsabilidades no projeto e definição (quando houver) da
qualidade de serviços e produtos subcontratados. Pode-se citar, como
principais produtos de trabalho envolvidos neste processo, os documentos da
Política Organizacional da Qualidade, Contrato de Projeto, Plano de
Desenvolvimento de Software, documento de Projeto, Plano da Qualidade de
Software, documento de Adequação do Software, Plano de Testes, Política de
Documentação de Projeto, Relatório da Qualidade e o Contrato de Prestação
de Serviços. O diagrama de Classes da Figura 4.16 mostra o relacionamento
entre o Gerente da Qualidade e os produtos associados como o pacote
Garantia da Qualidade.
154
1
*
1
*
1
*
1
*1
*1
*
Produtos daQualidade
(desenvolvimento)
Gerenteda
Qualidade
Plano de Testesdo Software
Plano daQualidade de
Software
Documento deAdequação do
Software
Contrato deProjeto
Política deDocumentação
Modelo deCiclo de Vida
do Projeto
Política Geralda Organização
Plano deDesenvolvimento
de Software
PolíticaOrganizacionalda Qualidade
1
*
Documento de Projeto
1
*
Produtos daQualidade
(apoio)1
*
1
*
Relatório daQualidade1
*
1
*
Formulário deEncaminhamento
de Problemas
FIGURA 4.16 – Os produtos envolvidos com o Gerente da Qualidade no pacote
Garantia da Qualidade.
155
O Analista da Qualidade, neste pacote, fica responsável por associar os
produtos de apoio, de desenvolvimento e os artefatos de software aos
processos fundamentais. Os produtos relacionados com as revisões e
auditorias, a seleção dos padrões específicos para o projeto (documentação,
diagramas, interfaces, código, entre outros), a identificação e categorização
dos produtos, a definição de quais informações serão registradas para
divulgação aos envolvidos e a escolha das medidas de software e de projeto a
serem utilizadas nos registros fazem parte de suas atribuições. Como produtos
relacionados com esta atividade podemos citar os produtos de Apoio, como o
Formulário de Avaliação de Produto, o Formulário de Encaminhamento de
Problemas, a Solicitação de revisão Conjunta, os relatórios (da Qualidade, da
Avaliação da Qualidade e da Auditoria), checklists (de Verificação, Validação,
Revisão Conjunta e de Auditoria), os guias de padrões (de Documentação, de
Diagramas, de Interfaces, de código, de Módulos de Teste, de Templates) e a
listas (de Produtos do Projeto e de Categorias de Produtos); e os produtos
(templates) de desenvolvimento de software como o de Especificação de
Requisitos, o Plano de Desenvolvimento, o Plano da Qualidade, de Testes, o
Manual do Usuário e os próprios artefatos de software. A Figura 4.17 detalha o
relacionamento entre o Analista da Qualidade e os produtos associados como
o pacote Garantia da Qualidade.
156
1
*
1 *
1
*
1
*
Produtos daQualidade
(desenvolvimento)
Analistada
Qualidade
Formulário deAvaliação de
Produto
Relatório daAuditoria
Cheklists deVerificação
Cheklists deValidação
Cheklists deRevisão Conjunta
Cheklists deAuditoria
Plano deTestes
EspecificaçãoRequisitos
Solicitaçãode Revisão
Artefatos deSoftware
Guia de Padrões deDocumentação
Guia de Padrões deDiagramas
Guia de Padrões deInterfaces do
Usuário
Guia de Padrões deCódigo
Guia de Padrões deMódulos de Teste
Guia de Padrões deTemplates
Relatório daAvaliação da
Qualidade
Lista dasCategorias de
Produtos
Relatório daQualidade
Medidas deSoftware
Medições daQualidade
Medidas deProjeto
Política deDocumentação
Modelos deCiclo de Vida de
Projeto
Produtos daQualidade
(apoio)
Plano deDesenvolvimento
Documento deProjetoPlano da
Qualidade
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1 *
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*1
*
1
*
1
*
Lista deProdutos
Formulário deEncaminhamento
de Problemas
1
*
1*
PolíticaOrganizacionalda Qualidade
1
*
Contrato deProjeto
FIGURA 4.17 – Os produtos envolvidos com o Analista da Qualidade no pacote
Garantia da Qualidade.
157
4.3.2.3 - Atividades do Pacote
O diagrama de pacote Garantia da Qualidade agrupa as atividades, os papéis e
os produtos do trabalho de acordo com os elementos comuns das práticas da
qualidade no nível de um projeto de desenvolvimento de software,
proporcionando apoio as diferentes atividades da qualidade envolvidas neste
contexto. Entende-se que, através da utilização dos processos da Garantia da
Qualidade para um determinado projeto, é necessário criar uma instância
desses processos, de modo a adequar as necessidades metodológicas, de
recursos e de estratégia de desenvolvimento de modo a utilizar o processo o
mais racional e adequado quanto possível.
É importante frisar que as atividades, papéis e produtos envolvidos nesses
processos são o conjunto mínimo necessário para o desenvolvimento de um
projeto, do ponto de vista do funcionamento da qualidade, ficando qualquer
alteração sujeita a uma proposta de criação ou de melhoria de processo no
nível do Gerenciamento da Qualidade.
158
4.3.2.3.1 – Pacote Definição da Estratégia da Garantia da Qualidade em
Projeto
O pacote Definição da Estratégia da Garantia da Qualidade em Projeto, Figura
4.18, estabelece as atividades de adequação dos processos fundamentais da
qualidade ao projeto, de forma a atender as necessidades específicas do
projeto e conforme os requisitos de qualidade da organização e as políticas
definidas nos planos do projeto. Um exemplo de adequação seria a utilização,
ou não de revisões conjuntas no processo. Dependendo do tipo de
desenvolvimento de software – aplicação interna da organização, por exemplo
– este tipo de processo pode não ser necessário. Baseado no Plano de
Desenvolvimento e no de Projeto, bem como nas diretrizes do Plano da
Qualidade estes processos são adequados, bem como, os produtos
associados com estes processos. Isto inclui outros documentos oficiais de
projeto (Especificação de Requisitos, Plano de Testes, por exemplo), checklists
(de verificação, validação, auditoria e revisão conjunta), formulários da
qualidade (de avaliação de produto, de solicitação de revisão e relatórios (da
qualidade e da auditoria)).
159
Gerente da Qualidade - GQ
Adequar Processo de Verificação & Validação ( )
Adequar Processo de Revisão Conjunta ( )
Formulário deAvaliação de Produto
Adequar Estratégia do Projeto a Estratégia deGerenciamento da Qualidade ( )
Adequar Processo de Auditoria ( )
Relatório daAuditoria
Analista da Qualidade
Definir Produtos Associados aos Processos daQualidade no Projeto ( )
Cheklists deVerificação
Cheklists deValidação
Cheklists deRevisãoConjunta
Cheklists deAuditoriaPlano de Testes
EspecificaçãoRequisitos de Software
Definição da Estratégiade Garantia da
Qualidade em Projeto
Plano daQualidade de
Software
Plano deDesenvolvimento
de Software
Relatório daQualidade
Modelo de Ciclode Vida do Projeto
Solicitação deRevisão
PolíticaOrganizacionalda Qualidade
PolíticaGeral da
Organização
FIGURA 4.18 - Pacote Definição da Estratégia da Garantia da Qualidade em
Projeto.
160
4.3.2.3.2 – Pacote Definição dos Registros da Qualidade no Projeto
O pacote Definição dos Registros da Qualidade no Projeto, Figura 4.19,
estabelece quais são as informações, associadas aos marcos do projeto, que
devem ser registradas pela qualidade, para o acompanhamento das suas
atividades e das de projeto. Baseados nas medições e nas informações
extraídas pelo Time da Qualidade, estes registros divulgados aos envolvidos
(Relatório da Qualidade e da Avaliação da Qualidade, por exemplo) permitem
que outras gerências (e a própria Gerência da Qualidade) tomem decisões e,
também, permite que todos os envolvidos no processo e no projeto se
mantenham informados sobre o andamento das atividades da qualidade e do
desenvolvimento.
Analista da Qualidade
Plano daQualidade de
Software
Associar Registros aos Marcos do Projeto ( )
Definir Informações do Projeto para Registro ( )
Relatório deAvaliação da
Qualidade
Definição dosRegistros da
Qualidade no Projeto
Modelo de Ciclode Vida do
Projeto
Medidas deSoftware
Medições daQualidade
Medidas deProjeto
Relatório daQualidade
FIGURA 4.19 - Pacote Definição dos Registros da Qualidade no Projeto.
161
4.3.2.3.3 – Pacote Seleções de Padrões para o Projeto
O pacote Seleções de Padrões para o Projeto, Figura 4.20, estabelece o
processo de seleção/adequação, dos padrões adotados no projeto. Os padrões
(de documentação, diagramas, código entre outros) são selecionados
observando as características metodológicas do projeto, a linguagem, ou as
linguagens adotadas, para a implementação do código, como serão as telas de
interação com o usuário, os diagramas de representação do projeto, e qualquer
outra abordagem que o projeto necessitar, que se fará com o auxílio dos guias
de padrões.
162
Gerente da Qualidade - GQ
Plano da Qualidadede Software
Documento de Adequaçãodo Software
Analista da Qualidade
Adequar Padrões ao Projeto ( )
Selecionar Padrão de Interfaces do Usuário ( )
Selecionar Padrão de Módulos de Teste ( )
Selecionar Padrão de Documentação de Projeto ( )
Selecionar Padrão de Código ( )
Selecionar Padrão de Templates ( )
Selecionar Padrão de Diagramas ( )
Guia de Padrão deDocumentação
Guia de Padrão deDiagramas
Guia de Padrão deInterfaces do
Usuário
Guia de Padrão deCódigo
Guia de Padrão deMódulo de Teste
Guia de Padrão deTemplates
Seleção dePadrões
para o Projeto
FIGURA 4.20 - Pacote Seleções de Padrões para o Projeto.
163
4.3.2.3.4 – Pacote Seleção da Documentação
O pacote Seleção da Documentação Figura 4.21, estabelece o processo de
escolha dos documentos que serão adotados no projeto, de forma a atender
seus requisitos metodológicos, de ciclo de vida e de implementação, dentro das
categorias de produto estabelecido para projetos pela organização e pelos
requisitos do contratante.
164
Gerente da Qualidade - GQ
Plano daQualidade de
Software
Analista da Qualidade
Estabelecer Identificação da Documentação ( )
Estabelecer os Requisitos da Documentação ( )
Lista das Categoriasde Produtos
Manual doUsuário
Associar a Documentação a Categoria deProduto ( )
Contrato deProjeto
Lista dosProdutos
Seleção daDocumentação
Adequar a Documentação ( )
Política deDocumentação
Artefatos deSoftware
Modelo deCiclo de Vida
do Projeto
PolíticaOrganizacionalda Qualidade
Política deDocumentação
FIGURA 4.21 - Pacote Seleção da Documentação.
165
4.3.2.3.5 – Pacote Definição da Política de Verificação e Validação no
Projeto
O pacote Definição da Política de Verificação e Validação no Projeto, Figura
4.22, estabelece a política de verificação e validação no projeto que deve ser
definida de acordo com as características do projeto, como a metodologia de
desenvolvimento, os marcos adotados como referência para o projeto, os
produtos e as atividades associadas a estes marcos, o Plano de Testes
definido no projeto e a integração dos módulos de software, o reuso de
componentes, entre outros aspectos. Também neste processo são
selecionados os produtos de apoio ao processo para o suporte as atividades de
verificação, validação e testes (checklists de Verificação e de Validação). É
importante frisar que o conceito de validação neste processo está fortemente
associado ao de teste, complementando as atividades de engenharia (ENG.8,
do padrão 15504, conforme Apêndice A) que define o processo de confirmação
de que o produto de software integrado satisfaz os requisitos definidos. Estas
atividades que são formalizadas nos planos do projeto (Plano da Qualidade e
no Plano de Projeto) e devem ter os produtos de desenvolvimento, os
chamados artefatos de software, devidamente selecionados para a realização
das atividades do Controle da Qualidade. O formulário (de avaliação de
produto) e o relatório (da qualidade) são os meios de divulgação dos resultados
obtidos com este processo.
Outra definição importante neste processo é estipular quando os produtos
devem ser verificados e validados. Dentro desta política pode ser estipulado,
por exemplo, que todos os artefatos de software devem, ao final de sua
confecção ou modificação, serem encaminhados à qualidade para efetuar as
verificações e validações formais e posteriormente encaminhados ao controle
de configuração.
166
Gerente da Qualidade - GQ
Plano da Qualidadede Software
Definir Política de Verificação no Projeto ( )
Associar VV&T aos Marcos do Projeto ( )
Plano de Testes doSoftware
Formulário deAvaliação de
Produto
Analista da Qualidade
Selecionar Produtos Relacionados a Verificação ( )
Cheklist daVerificação
Selecionar Produtos Relacionados a Validação eTeste ( )
Plano de Testesdo Software
Plano da Qualidadede Software
Plano deDesenvolvimento de
Software
Cheklist daValidação
Definir Política de Validação e Testes noProjeto ( )
Artefatos deSoftware
Definição da Políticade Verificação e
Validação no Projeto
Relatório daQualidade
FIGURA 4.22 - Pacote Definição da Política de Verificação e Validação no
Projeto.
167
4.3.2.3.6 – Pacote Definição da Política de Revisão Conjunta e Auditoria
no Projeto
O pacote Definição da Política de Revisão Conjunta e Auditoria no Projeto,
Figura 4.23, define a política de revisão conjunta e auditoria no projeto e a
vinculação de marcos de projeto a realização destas atividades. Uma revisão
conjunta, em particular só será realizada quando houver uma solicitação de
revisão (que poderá ocorrer ou não). As auditorias (física e funcional) devem
ocorrer obrigatoriamente ao final de cada marco estabelecido no projeto.
Devem também acontecer quando for estabelecido em planos do projeto, bem
como através de uma solicitação de revisão, utilizando para isto o mesmo
formulário de entrada do processo de revisão conjunta. Os produtos
associados a estas atividades (artefatos de software, por exemplo) também são
previamente selecionados e fazem parte dos produtos controlados pela
configuração do projeto. O formulário (de avaliação de produto) e os relatórios
(da auditoria, da qualidade e de sua avaliação) são os meios de divulgação dos
resultados obtidos com estes processos.
Outra definição importante neste processo é estipular quando os produtos
devem ser revisados e auditados. Dentro desta política pode ser estipulado, por
exemplo, que todos os Artefatos de Software devem, ao final do
desenvolvimento, no marco de entrega deve ser efetuada a auditoria de
entrega do produto.
168
Gerente da Qualidade - GQ
Plano da Qualidadede Software
Definir Política de Auditoria no Projeto ( )
Plano deDesenvolvimento de
Software
Formulário deAvaliação de
Produto
Analista da Qualidade
Plano da Qualidadede Software
Associar Revisões e Auditorias a Marcos doProjeto ( )
Definir Política de Revisão Conjunta noProjeto ( )
Relatório daAuditoria
Associar Produtos Relacionados a RevisãoConjunta ( )
Associar Produtos Relacionados a Auditoria ( )
Artefatos deSoftware
Definição da Políticade Revisão Conjuntae Auditoria no Projeto
Relatório daAvaliação da
Qualidade
Contrato deProjeto
Solicitaçãode Revisão
Relatório daQualidade
FIGURA 4.23 - Pacote Definição da Política de Revisão Conjunta e Auditoria no
Projeto.
169
4.3.2.3.7 - Pacote Extração dos Registros da Qualidade
O pacote Extração dos Registros da Qualidade, Figura 4.24, estabelece o
processo que extrai, de qualquer processo ou qualquer produto instanciado, os
registros necessários para a divulgação da qualidade. Este processo também
se encarrega de formatar e armazenar estes registros na forma de relatório
(Relatório da Qualidade e Relatório da Avaliação da Qualidade, por exemplo)
para consulta e manipulação, tanto no nível de projeto como no organizacional.
Pode ser desempenhado por qualquer membro do Time da Qualidade.
Time da Qualidade
Extrair Registos ( )
Extração dos Registrosda Qualdiade
Formulário deEncaminhamento de
Problemas
Armazenar Registros ( )
Relatório daQualidade
Formulário deAvaliação de
Produto
Relatório daAuditoria
Medições daQualidade
Relatório daAvaliação da
QualidadeArtefatos de
SoftwareProdutos da
Qualidade (apoio edesenvolvimento)
FIGURA 4.24 - Pacote Extração dos Registros da Qualidade.
170
4.3.2.3.8 – Pacote Identificação de Não-Conformidades
O pacote Identificação de Não-Conformidades, Figura 4.25, estabelece o
processo de identificação de problemas, desvios e não conformidades
observadas pela qualidade durante sua atuação, atribuindo um grau de
severidade e providenciando o devido encaminhamento do problema para
solução. O Formulário de Encaminhamento de Problemas e o Relatório da
Qualidade são os produtos que contém os registros do problema observado. O
processo de Gerenciamento de Problema, CFG.3, do Grupo de Controle de
Configuração é quem tem a responsabilidade de solucionar o ocorrido.
171
Gerente da Qualidade - GQ
Atribuir Severidade ( )
Time da Qualidade
Identificação deNão-Conformidades
Formulário deEncaminhamento de
Problemas
Encaminhar Problema ( )
Identificar Problema ou Não -Conformidade ( )
Formulário deEncaminhamento
de Problemas
Relatório daQualidade
Relatório daQualidade
Atribuir Severidade ( )
Encaminhar Problema ( )
FIGURA 4.25 - Pacote Definição dos Papéis da Qualidade no Projeto.
172
4.3.3 - Pacote Controle da Qualidade
O pacote Controle da Qualidade é composto dos chamados processos
fundamentais da qualidade. São os processos básicos, ou seja, os processos
que ajudam outros processos, dando suporte às atividades tanto da qualidade
como do desenvolvimento nos projetos e na organização como um todo. Os
processos definidos pela Garantia da Qualidade e instanciados para um projeto
são, efetivamente, executados no Controle da Qualidade. São os passos que
um processo deve seguir, executados em uma seqüência lógica, para as
atividades da qualidade. As revisões e auditoria e a devida comunicação dos
resultados da qualidade aos envolvidos, são exemplos de processos do
Controle da Qualidade. Para isto, nesta seção, além do diagrama de pacote, é
usado o recurso do diagrama de caso de uso para representar o aspecto de
inter-relacionamento entre papéis e atividades do processo. Em alguns
processos, quando necessário, foi utilizado também o diagrama de atividades
para apresentar a visão dinâmica do processo.
4.3.3.1 - Objetivos e Requisitos Básicos do Pacote
O objetivo principal deste pacote é realizar as práticas básicas da qualidade,
tanto no nível de projeto como organizacional, de acordo com os requisitos
definidos pelo Gerenciamento e pela Garantia da Qualidade, de maneira que
os processos possam ser utilizados de forma eficiente e clara e que os
resultados obtidos possam ser avaliados e divulgados entre os envolvidos com
o projeto e com a qualidade. O pacote Controle da Qualidade tem como
principal objetivo assegurar que os produtos (e os processos) do trabalho (ou
parte dele), durante o desenvolvimento de um software ou, durante as
atividades organizacionais da qualidade, estejam sendo implementados
corretamente, baseando-se em métodos, padrões e políticas pré-definidas.
Os principais requisitos desse pacote são:
173
Cada produto do trabalho e/ou serviço de um processo ou projeto deve refletir
apropriadamente seus requisitos especificados: um processo de verificação
deve ser implantando a fim de verificar se os produtos e/ou serviços avaliados
estão em conformidade com normas, padrões e convenções propostas para o
mesmo. Tem como objetivo garantir que os produtos (documentação e os
artefatos de software) estão sendo feitos conforme planejado e segundo os
padrões estabelecidos.
Os requisitos propostos para uso de um produto de software devem estar
satisfeitos: um processo de validação deve ser implantado, a fim de avaliar se
os requisitos definidos para um produto do trabalho ou processo
atendem/satisfazem seu uso proposto. Tem como objetivo garantir que os
produtos atendem os requisitos (funcionais e não funcionais).
Um entendimento comum entre os envolvidos nos produtos e processos deve
ser mantido: um processo de revisão conjunta deve ser implantado a fim de
avaliar, quando solicitado, os trabalhos ou produtos em desenvolvimento. Tem
como objetivo garantir que os envolvidos tenham um entendimento comum
sobre os produtos e serviços desenvolvidos em relação aos requisitos
acordados (definidos pelo cliente em contrato, por exemplo).
Os produtos e os processos devem ser avaliados, quando apropriado e de
forma independente, em relação a requisitos, planos e contratos: um processo
de auditoria deve ser implantado a fim de avaliar produtos e processos em
relação aos requisitos estabelecidos. Tem como objetivo principal realizar um
exame sistemático e independente, para determinar se as atividades da
qualidade e de configuração estão de acordo com as disposições planejadas,
se estas foram implementadas com eficácia e se são adequadas à consecução
dos objetivos do projeto.
Os resultados dos processos da qualidade devem ser divulgados: os registros
da qualidade devem ser tratados e endereçados aos envolvidos nos processos
e nos produtos. Tem por objetivo dar ciência sobre o andamento dos processos
174
e produtos tanto no nível organizacional como no dos projetos em
desenvolvimento.
Os requisitos do Controle da Qualidade podem ser representados através do
diagrama de pacote, Figura 4.26, que abrange os processos relacionados com
esta categoria de processo.
175
Controle daQualidade
Validação
Revisão Conjunta
Verificação
Auditoria
Comunicação dosResultados
FIGURA 4.26 - Pacote Controle da Qualidade.
4.3.3.2 - Papéis, Responsabilidades e Produtos Envolvidos no Pacote
O Gerente da Qualidade, nesse pacote fica responsável pela condução dos
processos, abrindo e fechando os processos, dando pareceres e, no caso de
problemas, encaminhando para as devidas providências. Os principais
produtos de trabalho envolvidos neste processo são os documentos de apoio,
Formulário de Avaliação de Produto, a Solicitação de Revisão, o Relatório de
Auditoria, o Formulário de Encaminhamento de Problemas e o Modelo de Ciclo
de Vida. No caso dos documentos de desenvolvimento, o Gerente da
Qualidade se envolve em todos eles, mas somente de forma a dirigir alguma
solicitação de seu time. O diagrama de classes da Figura 4.27 mostra o
176
relacionamento entre o Gerente da Qualidade e os produtos associados como
o pacote Controle da Qualidade.
1*
1
*
1
*
1
*
Produtos daQualidade
(desenvolvimento)
Gerenteda
Qualidade
Plano daQualidade de
Software
Documento deProjeto
Plano deDesenvolvimento
de Software
1
*
1
*
1
*
Formulário deAvaliação de
Produto
Solicitaçãode Revisão
Relatório daAuditoria1 *Produtos da
Qualidade(apoio)
Formulário deEncaminhamento
de Problemas
Modelo deCiclo de Vida
do Projeto
1
*
Plano deTestes
Especificaçãode Requisitos
1
*
1
*
Manual doUsuário
Artefatos deSoftware
FIGURA 4.27 – Os produtos envolvidos com o Gerente da Qualidade no pacote
Controle da Qualidade.
177
O Revisor, neste processo fica responsável pela execução das verificações e
revisões conjuntas, definindo checklists, associados, dando pareceres e, no
caso de problemas, encaminhando para as devidas providências. Os principais
produtos de trabalho envolvidos neste processo são os documentos de apoio,
Formulário de Avaliação de Produto, a Solicitação de Revisão, o Relatório de
Auditoria, o Relatório da Qualidade e de sua avaliação, o Formulário de
Encaminhamento de Problemas e o Modelo de Ciclo de Vida. No caso dos
documentos de desenvolvimento, o Revisor se envolve em todos eles,
realizando a revisão propriamente dita tanto nos documentos como nos
artefatos de software. O diagrama de classes da Figura 4.28 mostra o
relacionamento entre o Gerente da Qualidade e os produtos associados como
o pacote Controle da Qualidade.
178
1*
1
*
1
*
1
*
Produtos daQualidade
(desenvolvimento)
Revisorda
Qualidade
Plano daQualidade de
Software
Documento deProjeto
Plano deDesenvolvimento
de Software
1
*
1
*
1
*
Formulário deAvaliação de
Produto
Solicitaçãode Revisão
Relatório daAuditoriaProdutos da
Qualidade(apoio)
Formulário deEncaminhamento
de Problemas
Modelo deCiclo de Vida
do Projeto
1
*
Plano deTestes
Especificaçãode Requisitos
1
*
1
*
Manual doUsuário
Artefatos deSoftware
Cheklist daVerificação
Cheklist daRevisãoConjunta
Relatório daQualidade
Relatório daAvaliação da
Qualidade
1
*
1
*
1
*
Medições daQualiadade
1
*
1
*
1*
FIGURA 4.28 – Os produtos envolvidos com o Revisor no pacote Controle da
Qualidade.
179
O Testador, neste processo fica responsável pela execução das validações dos
produtos em relação aos requisitos propostos. Os principais produtos de
trabalho envolvidos neste processo são os documentos de apoio Formulário de
Avaliação de Produto, o Relatório de Auditoria, o Relatório da Qualidade e de
sua avaliação e o Formulário de Encaminhamento de Problemas. No caso dos
documentos de desenvolvimento, o Testador se envolve principalmente como o
Documento de Especificação de Requisitos e o Plano de Testes e os artefatos
de software a serem testados. O diagrama de classes da Figura 4.29 mostra o
relacionamento entre o Testador e os produtos associados como o pacote
Controle da Qualidade.
180
1
*
1
*
1
*
Produtos daQualidade
(desenvolvimento)
Testadorda
Qualidade
Plano daQualidade de
Software
1
*
1
*
1
*
Formulário deAvaliação de
Produto
Produtos daQualidade
(apoio)
Formulário deEncaminhamento
de Problemas
Especificaçãode Requisitos
Artefatos deSoftware
Cheklist daValidação
Relatório daQualidade
Relatório daAvaliação da
Qualidade
1
*
Medições daQualiadade
1
*
1
*
Plano deTestes
FIGURA 4.29 – Os produtos envolvidos com o Testador no pacote Controle da
Qualidade.
181
O Auditor, neste processo fica responsável pela execução das auditorias
solicitadas e nas estabelecidas nos marcos do projeto. Os principais produtos
de trabalho envolvidos neste processo são o Relatório de Auditoria, o Relatório
da Qualidade e de sua avaliação e o Formulário de Encaminhamento de
Problemas. No caso dos documentos de desenvolvimento, o Revisor se
envolve com todos eles, dos documentos de projeto como os artefatos de
software. O diagrama de classes da Figura 4.30 mostra o relacionamento entre
o Revisor e os produtos associados como o pacote Controle da Qualidade.
1
*
1
*
1
*
Produtos daQualidade
(desenvolvimento)
Auditorda
Qualidade
Plano daQualidade de
Software
Documentode Projeto
Plano deDesenvolvimento
de Software
1
*
1
*
Relatório daAuditoria
Produtos daQualidade
(apoio)
Formulário deEncaminhamento
de Problemas
1
*
Especificaçãode Requisitos
1
*
1
*
Manual doUsuário
Artefatos deSoftware Cheklist da
Auditoria
Relatório daQualidade
Relatório daAvaliação da
Qualidade
1
*
1
*
Plano deTestes
1
*
FIGURA 4.30 – Os produtos envolvidos com o Auditor no pacote Controle da
Qualidade.
182
4.3.3.3 - Atividades do Pacote
Os diagramas de pacote, caso de uso e de atividades do Controle da
Qualidade agrupam as atividades, os papéis e os produtos do trabalho de
acordo com os elementos comuns das práticas fundamentais da qualidade,
proporcionando apoio as diferentes atividades da qualidade envolvidas na
organização e nos projetos. Com a utilização destes processos é possível
realizar as atividades básicas propostas pela gerência da qualidade, qual seja
revisões e auditorias, coleta e divulgação de resultados e encaminhamento de
não-conformidades.
É importante frisar que as atividades, papéis e produtos envolvidos nestes
processos são o conjunto mínimo necessário para o desenvolvimento de um
projeto do ponto de vista do funcionamento da qualidade. Fica, qualquer
alteração, sujeita a uma proposta de criação ou de melhoria de processo no
nível de Garantia da Qualidade.
4.3.3.3.1 - Pacote Verificação
O pacote Verificação, Figura 4.31, estabelece o processo que verifica se os
produtos avaliados estão em conformidade com normas, padrões e
convenções propostas para os mesmos. Tem como objetivo garantir que os
produtos de desenvolvimento (documentação e os artefatos de software) estão
sendo feitos conforme planejado e segundo os padrões estabelecidos. O
processo de verificação também pode ser utilizado para verificar se os produtos
de apoio foram feitos segundo os padrões estabelecidos.
183
Gerente da Qualidade - GQ
Conduzir Verificação ( )
Formulário deAvaliação de Produto
Revisor
Verificar Produto ( )
Cheklist daVerificação
Relatar Resultados ( )
Artefatos deSoftware
Verificação
Relatório daQualidade
Artefatos deSoftware
Formulário deAvaliação de Produto
Encaminhar Problemas ( )
Encaminhar Problemas ( )
FIGURA 4.31 - Pacote Verificação.
184
O diagrama de caso de uso Verificar Produto, Figura 4.32, detalha os
envolvidos nas atividades de verificação. O Gerente da Qualidade e o Revisor
são os responsáveis pela condução da verificação e pelo menos um, deve em
caso de não-conformidade do produto em verificação, encaminhar o problema
para solução. Um Agente Mensageiro fica responsável por relatar os
resultados. O Responsável pelo Produto, bem como o Gerente de Projeto,
atuam passivamente, acompanhando a execução do processo. Em casos de
não-conformidade ou problemas, o Gerente da Qualidade ou o Revisor
encaminha o problema para solução.
*
*
Revisor
Gerente daQualidade
ConduzirVerificação
Relatar Resultados
**
Responsável peloProduto
*
*
*
*
*
*
<<perform>>
<<perform>>
<<perform>>
<<perform>> <<assist>>
<<assist>>
*
*
<<perform>>
<<assist>>
* *
*
*
Gerente deProjeto
<<assist>>
<<perform>>
*
*
<<assist>>
EncaminharProblemas
AgenteMensageiro
<<assist>>
FIGURA 4.32 - Diagrama de caso de uso Verificar Produto.
A WorkDefinition Conduzir Verificação pode ser representada pelo diagrama
de atividades, Figura 4.33, compreendendo as seguintes atividades:
185
Atividade 1: Encaminhar Produto. O Responsável pelo Produto encaminha ao
Ambiente Integrado seu Artefato de Software para o devido controle.
Atividade 2: Abrir Verificação. Um código é atribuído pelo Gerente da
Qualidade ao Formulário de Avaliação de Produto, relacionando-o com o
Produto do Trabalho a ser verificado e os envolvidos são notificados (o
Responsável pelo Produto, o Revisor e o Gerente do Projeto).
Atividade 3: Definir Critérios da Verificação. O Revisor estabelece com a ajuda
de seus modelos de checklist (de Código, por exemplo), quais serão os
critérios a serem verificados para o devido registro no Formulário de Avaliação.
Atividade 4: Verificar Produto. A verificação consiste na investigação do
produto em questão pelo Revisor, que será feita através do confronto entre o
produto e os critérios estabelecidos no Formulário de Avaliação, para a
extração dos resultados. Quaisquer dúvidas ou observações necessárias são
imediatamente informadas ao Responsável pelo Produto para solução.
Atividade 5: Solucionar Dúvidas. Esta atividade só ocorrerá quando surgirem
dúvidas por parte do Revisor sobre o entendimento do Produto avaliado. O
Responsável pelo Produto deve dirimir qualquer dúvida para continuar o
andamento do processo.
Atividade 6: Emitir Parecer. Ao final, o Revisor preenche o Formulário de
Avaliação com seu parecer, que é encaminhado ao Gerente da Qualidade para
seu parecer final.
Atividade 7: Fechar Verificação. O processo é encerrado e a WorkDefiniton
Relatar Resultados é instanciada, informando aos envolvidos sobre os
resultados da Verificação. Em caso de parecer de conformidade o Responsável
pelo Produto e o Gerente do Projeto devem ser informados. No caso de não-
conformidade a WorkDefiniton Encaminhar Problemas deve ser instanciada.
186
Gerente daQualidade
Responsávelpelo Produto
Artefato deSoftware
Abrir Verificação
Form Avaliação deProduto
(código de identificação)Definir Critérios da
Verificação
Revisor
Form Avaliação deProduto
(critérios estabelecidos)
Verificar ProdutoSolucionarDúvidas solução não
OK
FecharVerificação
Form Avaliação deProduto
(parecer)
soluçãoOK
EncaminharProduto
dúvida
Chekclist deVerificação
Emitir Parecer
Form Avaliação deProduto
(parecer final)
FIGURA 4.33 - Diagrama de atividades Conduzir Verificação.
187
4.3.3.3.2 - Pacote Validação
O pacote Validação, Figura 4.34, estabelece o processo que avalia se os
requisitos definidos para um produto de desenvolvimento atende/satisfaz seu
uso proposto. Este pacote engloba tanto a validação de um diagrama, como
também testes de código implementado. No caso de testes, este processo está
relacionado ao processo de engenharia Teste de Software. Isto significa que o
processo Validação para testes de software deve incorporar suas
funcionalidades ao processo de Engenharia (ENG.8, Teste de Software e
ENG.11, Teste de Sistema) que não são descritas neste processo.
Basicamente, a Validação tem por objetivo garantir que os produtos atendam
os requisitos funcionais e não funcionais definidos pelo projeto e pela
qualidade.
188
Gerente da Qualidade - GQ
Conduzir Validação ( )
Formulário deAvaliação de Produto
Testador
Validar Produto ( )
Cheklist daValidação
Relatar Resultados ( )
Artefatos deSoftware
Validação
Relatório daQualidade
Artefatos deSoftware
Formulário deAvaliação de Produto
Encaminhar Problemas ( )
Encaminhar Problemas ( )
Plano de Teste
FIGURA 4.34 - Pacote Validação.
189
O diagrama de caso de uso Validar Produto, Figura 4.35, detalha os envolvidos
nas atividades de validação. O Gerente da Qualidade e o Testador são os
responsáveis pela condução da validação e pelo menos um deve, em caso de
não-conformidade do produto em validação, encaminhar o problema para
solução. Um Agente Mensageiro fica responsável por relatar os resultados e o
Responsável pelo Produto, bem como o Gerente de Projeto, atuam
passivamente, acompanhando a execução do processo. Em casos de não-
conformidade ou problemas, o Gerente da Qualidade ou o Testador encaminha
o problema para solução.
*
*
Gerente deProjeto
Testador
Gerente daQualidade
<<perform>>
ConduzirValidação
EncaminharProblemas
RelatarResultados
* *
Responsável peloProduto
*
*
*
*
*
*
<<perform>>
<<perform>>
<<perform>>
<<perform>>
<<assist>>
<<assist>>
<<assist>>
* *
*
*
<<perform>>
*
*
*
*
<<assist>>
<<assist>>
*
*
AgenteMensageiro
<<assist>>
FIGURA 4.35 - Diagrama de caso de uso Validar Produto.
190
A WorkDefinition Conduzir Validação pode ser representada pelo diagrama de
atividades, Figura 4.36, compreendendo as seguintes atividades:
Atividade 1: Encaminhar Produto. O Responsável pelo Produto encaminha ao
Ambiente Integrado seu Artefato de Software para o devido controle.
Atividade 2: Abrir Validação. Um código é atribuído pelo Gerente da Qualidade
ao Formulário de Avaliação de Produto, relacionando-o com o Produto do
Trabalho a ser validado e os envolvidos são notificados (o Responsável pelo
Produto, o Testador e o Gerente do Projeto).
Atividade 3: Associar Produtos a Validação. O Testador estabelece quais são
os produtos associados à validação, como o checklist de Validação, bem como
o Plano de Teste, quando for uma validação relacionada a código. Estes
produtos devem ser as ferramentas de auxílio ao processo e deve ser
registrado o seu uso no Formulário de Avaliação.
Atividade 4: Testar/Validar Produto. A validação consiste na investigação do
produto pelo Testador, que é feita através do confronto entre as
funcionalidades do produto avaliado e seu uso pretendido. Isto pode abranger
deste um diagrama (se atende ao seu uso específico) ao produto de software
integrado (se atende aos requisitos contratados). Quaisquer dúvidas ou
observações necessárias são imediatamente informadas ao Responsável pelo
Produto para solução.
Atividade 5: Solucionar Dúvidas. Esta atividade só ocorrerá quando surgirem
dúvidas por parte do Testador sobre o entendimento do Produto avaliado ou
sobre recursos necessários para avaliar o produto. O Responsável pelo
Produto deve dirimir qualquer dúvida para permitir a continuação do processo.
Atividade 6: Emitir Parecer. Ao final, o Testador preenche o Formulário de
Avaliação com seu parecer, que é encaminhado ao Gerente da Qualidade para
seu parecer final.
191
Atividade 7: Fechar Validação. O processo é encerrado e a WorkDefiniton
Relatar Resultados é instanciada, informando aos envolvidos sobre os
resultados da Validação. Em caso de parecer de conformidade o Responsável
pelo Produto e o Gerente do Projeto devem ser informados. No caso de não-
conformidade a WorkDefiniton Encaminhar Problemas deve ser instanciada.
192
Gerente daQualidade
Responsávelpelo Produto
Artefatos deSoftware
Abrir Validação
Form Avaliação de Produto
(código de identificação)Associar Produtos a
Validação
Testador
Testar/ValidarProduto
Analisar Resultados
FecharValidação
Form Avaliaçãode Produto(parecer)
EncaminharProduto Chekclist de
Validação
Emitir Parecer
Form Avaliação de Produto
(parecer final)
Plano deTeste
FIGURA 4.36 - Diagrama de atividades Conduzir Validação.
193
4.3.3.3.3 - Pacote Revisão Conjunta
O pacote Revisão Conjunta, Figura 4.37, estabelece o processo que mantém o
entendimento comum entre os envolvidos nos produtos (de desenvolvimento e
apoio) e processos. Este processo é iniciado quando um dos envolvidos, o
cliente, por exemplo, solicita uma revisão (técnica ou de procedimento) a fim de
entender ou avaliar produtos ou processos. Além do significado de revisão,
para uniformizar o entendimento entre os envolvidos, a Revisão Conjunta pode
ter o mesmo procedimento de uma Verificação como de uma Validação ou
como uma Auditoria, só que fora do previsto pela política estabelecida no Plano
da Qualidade. Deverá ocorrer uma solicitação formal (poderá partir de qualquer
envolvido no projeto), através do formulário de Solicitação de Revisão, pedindo
(por exemplo) uma verificação de produto expondo os motivos desta
solicitação. Será destinado ao Gerente de Projeto, que caso julgue procedente,
encaminha ao Gerente da Qualidade. O documento que acompanhará a
Revisão Conjunta será o Relatório da Auditoria.
194
Gerente da Qualidade - GQ
Conduzir Revisão Conjunta ( )
Relatório daAuditoria
Revisor
Revisar ( )
Cheklist daRevisãoConjunta
Relatar Resultados ( )
Revisão Conjunta
Relatório daQualidade
Solicitação deRevisão
Encaminhar Problemas ( )
Encaminhar Problemas ( )
Produtos da Qualidade(desenvolvimento e
apoio)Relatório da
Auditoria
Produtos daQualidade
(desenvolvimento eapoio)
FIGURA 4.37 - Pacote Revisão Conjunta.
195
O diagrama de caso de uso Revisar Produto/Processo, Figura 4.38, detalha os
envolvidos nas atividades de revisão. Qualquer envolvido, neste processo
chamado de Cliente, pode solicitar ao Gerente de Projeto uma Revisão
Conjunta. É ele que verifica a pertinência da solicitação O Gerente da
Qualidade é que conduz a revisão e o Revisor quem realiza as ações
corriqueiras de revisar. Um Agente Mensageiro é quem apresenta os
resultados. Ao final todos devem dar seu parecer para o fechamento da
revisão. Em casos de não-conformidade ou problemas, o Gerente da
Qualidade ou o Revisor encaminha o problema para solução.
*
*
Gerente deProjeto
Revisor
Gerente daQualidade
ConduzirRevisãoConjunta
RelatarResultados
*
*
Gerente daConfiguração
*
*
*
*
*
*
*
*<<perform>>
<<perform>>
<<perform>>
<<assist>>
<<assist>>*
*
*
*
<<perform>>
Cliente
*
*<<assist>>
*
*
*
*
Solicitar RevisãoConjunta
<<perform>>
*
*
*
*
<<perform>><<perform>>
<<perform>>
EncaminharProblemas
<<perform>>
AgenteMensageiro
<<assist>>
<<assist>>
<<assist>>
FIGURA 4.38 - Diagrama de caso de uso Revisar Produto/Processo.
196
A WorkDefinition Conduzir Revisão Conjunta pode ser representada pelo
diagrama de atividades, Figura 4.39, compreendendo as seguintes atividades:
Atividade 1: Solicitar Revisão Conjunta. O Cliente solicita uma revisão expondo
seus motivos. O Gerente de Projeto avalia a pertinência do pedido. Caso seja,
encaminha ao Gerente da Qualidade. Caso não, devolve ao Cliente a
solicitação.
Atividade 2: Abrir Revisão Conjunta. Um código é atribuído pelo Gerente da
Qualidade ao Relatório de Auditoria, relacionando-o com o Produto do Trabalho
ou Processo a ser revisado e os envolvidos são notificados (o Cliente, O
Gerente da Configuração, o Gerente do Projeto e o Revisor).
Atividade 3: Associar Produtos a Revisão. O Revisor estabelece quais são os
produtos associados a revisão, como o checklist de Revisão Conjunta, bem
como os Artefatos de Software relacionados. Estes produtos devem ser as
ferramentas de auxílio ao processo e deve ser registrado o seu uso no
Relatório de Auditoria.
Atividade 4: Revisar. A revisão consiste na investigação da solicitação de
revisão, analisando o produto (ou processo) envolvido. Esta revisão pode ser
feita através da busca de um entendimento comum sobre o objeto da revisão, a
detecção de alguma não-conformidade de procedimentos, ou meramente para
avaliar o estado atual do andamento dos trabalhos. Ela pode abranger também,
a análise de diagramas (proporcionar um entendimento de uso) ou os
procedimentos adotados para um processo (se atende ao uso pretendido).
Atividade 5: Apresentar Resultados. Esta atividade apresenta os resultados da
revisão, com o parecer do Revisor e endosso das partes envolvidas.
Atividade 6: Emitir Parecer. Ao final, todos os envolvidos como o Cliente, o
Gerente da Configuração, o Gerente de Projeto e o Gerente da Qualidade
preenchem o Relatório da Auditoria com seu parecer.
197
Atividade 7: Fechar Revisão Conjunta. O processo é encerrado e a
WorkDefiniton Relatar Resultados é instanciada, informando a todos os
interessados (além dos participantes envolvidos) sobre os resultados da
Revisão. Caso na Revisão apareça alguma não-conformidade a
WorkDefiniton Encaminhar Problemas deve ser instanciada.
198
Gerente daQualidade
Cliente
Solicitaçãode Revisão(solicitação)
Solicitar RevisãoConjunta
Associar Produtos aRevisão
Revisor
Revisar
Apresentar Resultados
Fechar RevisãoConjunta
Relatório de Auditoria(parecer dos envolvidos)
Gerente deProjeto
Relatório de Auditoria(código de identificação)
Cheklist deRevisão Conjunta
Artefatos deSoftware
Emitir ParecerEmitir ParecerEmitir Parecer
Abrir RevisãoConjunta
Relatório de Auditoria(parecer do Revisor)
GerentedaConfiguração
Emitir Parecer
pertinentenão pertinente
FIGURA 4.39 - Diagrama de atividades Conduzir Revisão Conjunta.
199
4.3.3.3.4 - Pacote Auditoria
O pacote Auditoria, Figura 4.40, estabelece o processo que avalia de forma
independente produtos e os processos, em relação a requisitos, planos e
contratos. O processo de auditoria é instanciado a fim de avaliar produtos (de
desenvolvimento e apoio) e processos em relação aos seus requisitos tanto no
nível organizacional como de projeto. A auditoria realiza um exame sistemático
e independente, determinando se as atividades da qualidade e de configuração
estão de acordo com as disposições planejadas, se estas foram
implementadas com eficácia e se são adequadas à consecução dos objetivos
do projeto. Pode-se citar como principais auditorias, a de configuração
Funcional (para verificar se todos os requisitos foram atendidos), e a de
configuração Física (para verificar que o software e sua documentação estão
completos e prontos para a entrega). Uma vez alcançada uma determinada
configuração de projeto (marco) a ser auditada, prevista no Plano de
Desenvolvimento, a auditoria deverá ser realizada. A solicitação esporádica de
uma auditoria também pode ocorrer, devendo seguir os mesmos
procedimentos das auditorias planejadas.
200
Gerente da Qualidade - GQ
Conduzir Auditoria ( )
Relatório daAuditoria
Auditor
Auditar ( )
Cheklist daAuditoria
Relatar Resultados ( )
Auditoria
Relatório daQualidade
Relatório daAuditoria
Encaminhar Problemas ( )
Encaminhar Problemas ( )
Produtos da Qualidade(desenvolvimento e
apoio)
Produtos da Qualidade(desenvolvimento
e apoio)
Liberar Item Auditado ( )
Modelo de Ciclode Vida do Projeto
FIGURA 4.40 - Pacote Auditoria.
201
O diagrama de caso de uso Auditar Produto/Processo, Figura 4.41, detalha os
envolvidos nas atividades de auditoria. Uma Auditoria de Produto acontece ao
final do desenvolvimento dos produtos relacionados a um marco de projeto. É
instanciada a auditoria para avaliar se os produtos deste marco atendem a
seus requisitos estabelecidos e se estão em conformidade com os contratos,
planos e políticas estabelecidas. O Gerente da Qualidade é quem conduz a
auditoria. O Cliente é aquele a quem o produto será entregue (externo o u
interno a organização) e deverá, ao final do processo, emitir seu parecer de
aceite. O Gerente de Projeto acompanha a Auditoria e ao final do processo
também emite seu parecer. O Auditor é quem audita o produto/processo e dá
seu parecer primeiramente O Gerente da Configuração também tem que dar
seu parecer ao final do processo bem como o Gerente da Qualidade, que além
do parecer, fecha a auditoria. Um Agente Mensageiro é quem apresenta os
resultados. Em casos de não-conformidade ou problemas, o Gerente da
Qualidade ou o Auditor encaminha o problema para solução.
*
*Gerente de
Projeto
Auditor
Gerente daQualidade
ConduzirAuditoria
RelatarResultados
*
*
Gerente daConfiguração
*
*
*
*
*
*
<<perform>>
<<perform>>
<<perform>>
<<perform>>
<<assist>>
<<assist>>
*
*
*
*
<<perform>>
Cliente
*
*
* *
*
*
<<assist>>
Liberar ItemAuditado
<<perform>>
<<perform>>
<<perform>>
<<perform>>
<<perform>>
<<perform>>
<<perform>>
EncaminharProblemas
AgenteMensageiro
<<assist>>
<<assist>>
FIGURA 4.41 - Diagrama de caso de uso Auditar Produto/Processo.
202
A WorkDefinition Conduzir Auditoria pode ser representada pelo diagrama de
atividades, Figura 4.42, compreendendo as seguintes atividades:
Atividade 1: Abrir Auditoria. Um código é atribuído pelo Gerente da Qualidade
ao Relatório de Auditoria, relacionando-o com o marco de desenvolvimento
alcançado e os Artefatos de Software (ou Processo) a ser auditado. Os
envolvidos são notificados (o Cliente, O Gerente da Configuração, o Gerente
do Projeto e o Auditor).
Atividade 2: Associar Produtos a Auditoria. O Auditor estabelece quais são os
produtos associados à auditoria, como o Checklist de Auditoria, bem como os
Artefatos de Software relacionados. Estes produtos devem ser as ferramentas
de auxílio ao processo para o devido registro no Relatório de Auditoria.
Atividade 3: Auditar. A revisão consiste na investigação do produto (ou
processo) pelo Auditor. No caso do marco de entrega de produto, a auditoria é
feita através do confronto dos itens (garantir que todos estão prontos) a serem
entregues nesta fase e da garantia de sua funcionalidade em relação aos
requisitos estabelecidos.
Atividade 4: Apresentar Resultados. Esta atividade apresenta os resultados da
auditoria, com o parecer do Auditor para avaliação das partes envolvidas.
Atividade 5: Emitir Parecer. Ao final, todos os envolvidos como o Cliente, o
Gerente da Configuração, o Gerente de Projeto, e o Gerente da Qualidade
preenchem o Relatório da Auditoria com seus pareceres.
Atividade 6: Fechar Revisão Conjunta. O processo é encerrado e a
WorkDefiniton Relatar Resultados é instanciada, informando a todos os
interessados (além dos envolvidos) sobre os resultados da Auditoria. Caso na
Auditoria apareça alguma não-conformidade a WorkDefiniton Encaminhar
Problemas deve ser instanciada.
203
Gerente daQualidade
Cliente
Associar Produtos aAuditoria
Revisor
Auditar
Apresentar Resultados
Fechar Auditoria
Relatório de Auditoria(parecer dos envolvidos)
Gerente deProjeto
Relatório de Auditoria(código de identificação)
Cheklist deAuditoria
Artefatos deSoftware
Emitir ParecerEmitir ParecerEmitir Parecer
Abrir Auditoria
Relatório de Auditoria(parecer do Auditor)
GerentedaConfiguração
Emitir Parecer
FIGURA 4.42 - Diagrama de atividades Conduzir Auditoria.
204
4.3.3.3.5 - Pacote Comunicação dos Resultados
O pacote Comunicação dos Resultados, Figura 4.43, estabelece o processo de
divulgação dos resultados da qualidade, na forma de seus registros extraídos
durante o processo instanciado. Esta comunicação deve ser feita por um
Agente Mensageiro do Ambiente Integrado (automatizado ou não) que
endereça as informações aos envolvidos no processo ou nos produtos
relacionados, bem como àqueles a quem o planos ou políticas previamente
determinarem.
Agente Mensageiro
Endereçar Registros ( )
Comunicação dosResultados
Notificar Envolvidos ( )
Relatório daQualidade
Relatório daAuditoria
Relatório daAvaliação da
Qualidade
Formulário deAvaliação de
Produto
Medições daQualidade
Formulário deEncaminhamento de
Problemas
FIGURA 4.43 - Pacote Comunicação dos Resultados.
205
O diagrama de caso de uso Comunicar Resultados, Figura 4.44, detalha os
envolvidos nas atividades de comunicação dos resultados da qualidade de um
projeto ou da organização como um todo. O Agente Mensageiro é que se
encarregará de endereçar o resultado, que pode ser o Relatório da Qualidade
ou outro documento qualquer, ao(s) envolvido(s) no processo conforme
definido. Neste caso de uso foram apenas representados os envolvidos mais
diretos nos processos da Qualidade. No caso de informar outro participante, só
é necessário o fornecimento de seu endereço eletrônico.
*
*
Gerente deProjeto
Time daQualidade
Analista deProblemas
NotificarEnvolvidos
Gerente daConfiguração
<<perform>>
<<perform>>
<<assist>>
<<assist>>
*
*
Cliente
*
*
*
*
<<assist>>
EndereçarRegistros
AgenteMensageiro
<<assist>>
<<assist>>
FIGURA 4.44 - Diagrama de caso de uso Comunicar Resultados.
206
4.3.4 - Pacote Qualidade de Produto
O pacote Qualidade de Produto é composto pelos processos que garantem a
qualidade de um produto com relação a sua usabilidade, por parte tanto dos
envolvidos com seu desenvolvimento como com seu uso proposto, como
também os processos relacionados com o exame sistemático do produto pela
qualidade. Envolve basicamente dois grandes pacotes, o de Usabilidade e de
Avaliação de Produto. A Usabilidade fica responsável por garantir que os
interesses e necessidades dos envolvidos estão de acordo com o uso
pretendido do produto, incluindo nisso questões como produtividade, qualidade
do produto, redução no índice de rejeição e melhoria do trabalho humano. A
Avaliação de Produto se propõe a garantir, através de um exame e medição
sistemática, que um produto atende os requisitos para qual foi proposto, tanto a
nível funcional como de utilização.
4.3.4.1 - Objetivos e Requisitos Básicos do Pacote
O objetivo principal deste pacote é realizar as práticas básicas da qualidade do
produto, de maneira que os produtos possam ser examinados, avaliados e
utilizados de forma que atenda seu uso pretendido. O produto deve ser usado
de forma eficiente e confortável para o usuário, e que os resultados dos
processos possam ser avaliados e utilizados para estabelecer critérios de
melhoria constante para a qualidade de produto.
Os principais requisitos deste pacote são:
O desenvolvimento do produto deve atender as necessidades do usuário: o
processo deve levar em conta as exigências e necessidades dos usuários e
levar em conta sua capacidade humana e limitações: técnicas. Tem como
objetivo garantir que os produtos serão feitos de forma a atender os requisitos
de usabilidade.
207
Fatores humanos, ergonômicos e do conhecimento devem ser considerados:
questões como interface homem-máquina e outros aspectos relacionados a
atividades centradas no homem, devem ser consideradas para se alcançar os
objetivos propostos para o uso do produto ou do sistema.
Um entendimento comum entre os envolvidos nos produtos e processos deve
ser mantido: um processo de revisão conjunta deve ser implantado a fim de
avaliar, quando solicitado, os trabalhos ou produtos em desenvolvimento. Tem
como objetivo garantir que os envolvidos tenham um entendimento comum
sobre os produtos e serviços desenvolvidos em relação aos requisitos
acordados (definidos pelo cliente em contrato, por exemplo).
O produto deve atender seu uso proposto: o sistema deve atender seu uso
proposto de forma efetiva, eficiente e satisfatória.
O produto deve ser avaliado: devem ser estabelecidos critérios, modelos,
métodos e medidas para a avaliação de produto. Tem como objetivo principal
realizar um exame sistemático no produto a fim de verificar se o mesmo atende
seu uso pretendido e de forma satisfatória às necessidades da qualidade.
Os resultados da avaliação do produto devem ser analisados e divulgados: os
resultados da avaliação qualidade devem ser analisados contra critérios bem
definidos e os resultados devem ser disseminados aos envolvidos. Tem por
objetivo verificar se os critérios da qualidade de produto foram atendidos e dar
ciência aos participantes sobre o andamento das atividades da qualidade de
produto.
Os requisitos do pacote Qualidade de Produto podem ser representados
através do diagrama de pacote, Figura 4.45, que abrange os processos
relacionados com esta categoria de processo.
208
Qualidade deProduto
Avaliação deProduto
Usabilidade
FIGURA 4.45 - Pacote Qualidade de Produto.
209
4.3.4.2 - Papéis, Responsabilidades e Produtos Envolvidos no Pacote
O Gerente da Qualidade, neste pacote fica responsável pelo estabelecimento
dos requisitos gerais de usabilidade e de avaliação de produto, pela
identificação do modelo da qualidade a ser adotado e por especificar os
métodos para avaliação de produto. Além disso, o Gerente também é
responsável por definir e priorizar as soluções de usabilidade em projetos e por
implementar um treinamento voltado a usabilidade para a equipe de
desenvolvimento. Os principais produtos de trabalho envolvidos neste processo
são a Política Organizacional e a Política de Treinamento da Qualidade, o
Plano de Avaliação de Produto, o Formulário de Avaliação de Produto e o
Plano da Qualidade de Software. O diagrama de classe da Figura 4.46 mostra
o relacionamento entre o Gerente da Qualidade e os produtos associados
como o pacote Qualidade de Produto.
1
*
PolíticaOrganizacionalda Qualidade
Política deTreinamento da
Qualidade
1
*
Plano deAvaliação de
Produto
Formulário deAvaliação de Produto
1
*
Produtos daQualidade
(apoio)
Gerenteda
Qualidade
1 *
1
*
Plano daQualidade
de Software
Produtos daQualidade
(desenvolvimento)
FIGURA 4.46 – Os produtos envolvidos com o Gerente da Qualidade no pacote
Qualidade de Produto.
210
O Analista da Qualidade, neste pacote fica responsável por definir a tipologia e
as necessidades das pessoas envolvidas com o produto, pela implementação
do projeto com relação aos aspectos de solução da interface com o homem e
por implementar os mecanismos de assistência aos usuários e
desenvolvedores, no que diz respeito ao treinamento, assistência através de
centrais de atendimento ou qualquer outro mecanismo de auxílio a usuário e
desenvolvedores nas questões de uso e avaliação de produto. Os principais
produtos de trabalho envolvidos neste pacote são o Plano de Avaliação de
Produto, o Guia de Usabilidade e o Formulário de Avaliação de Produto. O
diagrama de classe da Figura 4.47 mostra o relacionamento entre o Analista da
Qualidade e os produtos associados como o processo Qualidade de Produto.
1
*
Plano deAvaliação de
Produto
Formuláriode Avaliaçãode Produto
1
*
Produtos daQualidade
(apoio)
Analistada
Qualidade
Guia deUsabilidade
1
*
FIGURA 4.47 – Os produtos envolvidos com o Analista da Qualidade no pacote
Qualidade de Produto.
211
O Revisor, neste pacote fica responsável por validar os requisitos de
usabilidade em projetos de software, por especificar medidas e critérios para a
avaliação, realizar a avaliação de produto, analisar e comunicar os resultados
da avaliação. Os principais produtos de trabalho envolvidos neste processo são
o Plano de Avaliação de Produto, o Formulário de Avaliação de Produto, o Guia
de Usabilidade e os próprios artefatos de software que serão avaliados. O
diagrama de classe da Figura 4.48 mostra o relacionamento entre o Revisor e
os produtos associados como o pacote Qualidade de Produto.
1
*
Plano deAvaliação de
Produto
Formuláriode Avaliaçãode Produto
1
*
Produtos daQualidade
(apoio)
Revisorda
Qualidade
Guia deUsabilidade
1
*
Artefatos deSoftware
FIGURA 4.48 – Os produtos envolvidos com o Revisor no pacote Qualidade de
Produto.
212
O diagrama de pacote Qualidade de Produto agrupa as atividades, os papéis e
os produtos do trabalho de acordo com os elementos comuns das práticas de
qualidade de produto, no intuito de garantir os interesses e necessidades dos
envolvidos e que os produtos atendem os requisitos estabelecidos. Com a
utilização destes processos é possível realizar as atividades básicas propostas
pelos pacotes Usabilidade e Avaliação de Produto.
4.3.4.3.1 - Pacote Usabilidade
O pacote Usabilidade, Figura 4.49, estabelece o processo de garantia dos
interesses e necessidades dos envolvidos, de modo a otimizar o suporte e
treinamento e incrementar a produtividade e qualidade do trabalho. Tem como
objetivo melhorar as condições humanas de trabalho e reduzir a chance de
rejeição dos usuários ao produto.
213
Gerente da Qualidade - GQ
Definir Requisitos de Usabilidade para Produtos ( )
Formulário deAvaliação de Produto
PolíticaOrganizacional da
Qualidade
Definir e Priorizar as Soluções de Usabilidade emProjetos ( )
Implementar Treinamento de Usabilidade paraDesenvolvedores ( )
Analista da Qualidade
Definir Tipo e Necessidade do Usuário do Produto ( )
Implementar Mecanismos de Assistência aos Usuáriose Desenvolvedores para Questões de Usabilidade ( )
Implementar Projeto Centrado no Usuário ( )
Guia deUsabilidade
Usabilidade
Artefatos deSoftware
Política deTreinamento da
Qualidade
Formulário deAvaliação de
Produto
Revisor
Validar os Requisitos de Usabilidade no Projeto deSoftware ( )
Guia deUsabilidade
Plano daAvaliação de
Produto
Plano da Avaliaçãode Produto
Plano daAvaliação de
Produto
FIGURA 4.49 - Pacote Usabilidade.
214
4.3.4.3.2 - Pacote Avaliação de Produto
O pacote Avaliação de Produto, Figura 4.50, estabelece o processo de
garantia, através de um exame e uma medição sistemática, da qualidade do
produto, de modo a satisfazer seu uso pretendido e as necessidades dos
envolvidos. Tem como objetivo especificar os critérios e requisitos da avaliação
de produto, os métodos e medidas utilizados na avaliação, e como deverão ser
feitas a análise e divulgação dos resultados.
215
Gerente da Qualidade - GQ
Estabelecer os Requisitos Gerais de Avaliação deProduto ( )
Formulário deAvaliação de Produto
Identificar o Modelo da Qualidade ( )
Especificar Métodos para a Avaliação deProduto ( )
Revisor
Especificar Medidas para Avaliação de Produto ( )
Realizar Avaliação de Produto ( )
Especificar os Crritérios para Avaliação de Produto ( )
Guia deUsabilidade
Avaliação de Produto
Artefatos deSoftware
Plano da Avaliaçãode Produto
Formulário deAvaliação de Produto
Analisar os Resultados da Avaliação ( )
Comunicar os Resultados da Avaliação ( )
Plano da Avaliaçãode Produto
FIGURA 4.50 - Pacote Avaliação de Produto.
217
CAPÍTULO 5
A IMPLEMENTAÇÃO DE UM PROTÓTIPO NO AMBIENTE INTEGRADO
Para demonstrar a funcionalidade de um processo da qualidade no Ambiente
Integrado, dentre aqueles definidos e modelado no capítulo 4, foi elaborado o
protótipo intitulado Quality Management (QM). O segundo objetivo deste
protótipo foi identificar os serviços mínimos necessários para a implementação
de todos os processos da qualidade no e-WebProject. O processo identificado
como fundamental para as atividades da gestão da qualidade no Ambiente e-
WebProject, e adotado como modelo para o protótipo, foi o processo Garantia
de Produto.
O processo Garantia de Produto engloba as atividades de encaminhamento,
verificação e controle de produtos desenvolvidos em um projeto, após sua
confecção ou modificação.
Este processo, na visão da qualidade, consiste no encaminhamento dos
produtos de um projeto para avaliação e posterior encaminhamento ao controle
de configuração no Ambiente e-WebProject. Um Produto (artefato de software)
só será efetivamente controlado após sua confecção ou modificação, avaliação
(com parecer de conformidade satisfatório) e armazenamento no repositório
controlado de artefatos do Ambiente Integrado.
Este repositório controlado nada mais é do que uma área da camada de
armazenamento e acesso do Ambiente onde os produtos gerados no
desenvolvimento de um projeto estão revisados, controlados e prontos para
serem usados em uma nova fase de projeto, a chamada configuração base
(baseline). Uma das fases mais importantes em que os produtos estão
armazenados é a fase de entrega. Nesta fase reside a configuração final do
desenvolvimento, ou seja, o pacote a ser aceito e entregue ao cliente.
218
Os produtos que estão no repositório controlado devem ser armazenados
convenientemente, de maneira que seu acesso e/ou modificações possam ser,
de alguma forma, controlado.
Neste capítulo apresenta-se a definição dos requisitos mínimos para a
implementação do protótipo intitulado Quality Management (QM), mais
especificamente o processo Garantia de Produto, bem como os recursos
necessários, em termos de serviços, que o Ambiente Integrado deve prover
para que todos os processos da qualidade possam ser implementados de
forma a atender seus objetivos e funcionalidades.
5.1 – Os Requisitos do Protótipo Garantia de Produto
Para entender o contexto das atividades de encaminhamento de produtos para
controle, ou seja, realizando a atividade de avaliação e de configuração do
produto, deve-se entender o contexto que a Garantia de Produto se insere na
gestão da qualidade no Ambiente. Todo produto cuja categoria seja
considerada como a ser controlado, deve ao final de sua confecção ou
modificação, ser encaminhado para a uma área do repositório de artefatos do
Ambiente para ser avaliado e controlado. A avaliação e controle têm como
objetivo garantir que em uma área específica do Ambiente estejam sendo
arquivados e controlados todos os produtos concluídos e posteriormente
revisados do projeto. Isto permite avançar em uma nova fase do projeto ou
mesmo alcançar sua configuração final de entrega. Além disso, através de um
mecanismo de controle de configuração, é possível ter acesso (controlado), por
todos os envolvidos, de qualquer produto do sistema. Estas atividades,
consideradas de suporte ao desenvolvimento, são de responsabilidade,
principalmente, do Gerente da Qualidade e do Gerente da Configuração.
Um Responsável pelo Produto, ou Cliente da Qualidade, ao terminar a
confecção de seu artefato de software, deve encaminhá-lo para o Ambiente,
219
formalizando assim, temporariamente, a entrega de seu produto, ou seja, o
final de sua fabricação. Artefatos sujeitos a modificações estão sujeitos ao
mesmo procedimento de encaminhamento ao Ambiente.
Os produtos encaminhados, antes de serem controlados pelo repositório de
artefatos, devem sofrer uma avaliação, no intuito de garantir que este produto
atende seus requisitos, tanto de formato como de conteúdo e funcionalidade.
O processo de avaliação no e-WebProject consiste da verificação e validação
de produto, atividades que são de responsabilidade do Gerente da Qualidade e
de sua equipe (Time da Qualidade).
Dependendo da fase e da categoria do produto, o mesmo pode sofrer apenas
uma avaliação de verificação antes de ser controlado, ou uma avaliação de
verificação e validação.
Para poder realizar o processo de avaliação, na Garantia de Produto, todo
projeto que utilizar o Ambiente Integrado deve previamente estabelecer, nos
processos de Planejamento da Qualidade, quais são os produtos (em
categorias) que sofrerão as avaliações (verificação e validação).
O processo de Verificação verifica se o(s) produto(s) revisado(s) está em
conformidade com normas, padrões e convenções propostas para o mesmo.
Tem como objetivo garantir que os produtos de desenvolvimento
(documentação e os Artefatos de Software) estão sendo feitos conforme
planejado e segundo os padrões estabelecidos.
O processo de Validação avalia se os requisitos definidos para um produto de
desenvolvimento atende/satisfaz seu uso proposto. Este processo engloba
tanto a validação de um diagrama, como também testes de unidade e de
módulo do código implementado. Basicamente, a Validação tem por objetivo
garantir que os produtos atendem seus requisitos funcionais (e até mesmo os
não funcionais) definidos pelo projeto e pela qualidade.
220
Para que se possa visualizar, de uma forma gráfica, os requisitos do processo
Garantia de Produto do protótipo QM, foi utilizado o diagrama de contexto da
UML (Booch et al., 2000), conforme a Figura 5.1, somente abordando os
aspectos relacionados com as atividades da qualidade. O caso de uso
Controlar Produtos apresentado nesse diagrama, é uma das atividades
relacionadas com o controle de configuração e modificação de produto. Este
processo não foi implementado no protótipo por se tratar, dentro da estrutura
gerencial do e-WebProject, de atividade relacionada a Gerência da
Configuração.
FIGURA 5.1 - Diagrama de contexto da Garantia de Produto.
definir política deavaliação de
produto
encaminharprodutos para
controle
avaliar produtos
Gerente daQualidade
Revisor
Responsávelpelo Produto
Gerente daConfiguração
controlar produtos
atribuirresponsabilidades
na avaliação
221
5.1.1 – Caso de Uso Atribuir Responsabilidades na Avaliação
O objetivo deste caso de uso é definir os recursos humanos da qualidade
envolvidos com as atividades do processo Garantia de Produto, mais
especificamente na avaliação de produto. Estes papéis da qualidade devem ser
definidos de forma a atender as atividades de avaliação como testes e
verificações, estipuladas especificamente para o projeto instanciado, devendo
estes papéis, e suas atividades, estarem registrados no Plano da Qualidade. A
Figura 5.2 ilustra o caso de uso Atribuir Responsabilidades na Avaliação. A
Figura C.6, do Apêndice C ilustra a tela referente à funcionalidade do caso de
uso Papéis da Qualidade, do módulo Quality Planning, do protótipo QM.
associar papéis daqualidade asatividades deVerificação
Gerente daQualidade
FIGURA 5.2 - Caso de uso Atribuir Responsabilidades na Avaliação.
5.1.2 – Caso de Uso Definir Política de Avaliação de Produto
Os principais objetivos dessa funcionalidade são estabelecer a política de
verificação e validação no projeto (que deve ser definida respeitando-se as
características do projeto, como a metodologia de desenvolvimento, os marcos
adotados como referência para o projeto) e as categorias dos produtos que
serão verificados e validados (incluindo o Plano de Testes definido no projeto e
a integração dos módulos de software).
222
Para a execução deste processo são utilizados produtos de apoio como
checklists (de Verificação e de Validação) e o Formulário de Avaliação de
Produto, que é o documento que acompanha a revisão e serve como meio de
divulgação dos resultados obtidos com estes processos.
Neste processo são definidos quais produtos devem ser verificados e
validados. Dentro desta política deve ser estipulado por categoria, cada
Artefato de Software que, ao final de sua confecção ou modificação, será
encaminhado à qualidade para efetuar a verificação e/ou validação formal para
liberação ao controle de configuração. A Figura 5.3 ilustra o caso de uso Definir
Política de Avaliação de Produto. A Figura C.8, do Apêndice C ilustra a tela
referente à funcionalidade do caso de uso Verificação e Validação, do módulo
Quality Planning, do protótipo QM.
definir as categoriasde produtos
associadas aVerificação
Gerente daQualidade
Revisordefinir as categorias
de produtosassociadas a
Validação
associar as V&V aosmarcos de projeto
FIGURA 5.3 - Caso de uso Definir Política de Avaliação de Produto.
223
5.1.3 – Caso de Uso Encaminhar Produtos para Controle
Os principais objetivos dessa funcionalidade são estabelecer as atividades
relativas ao encaminhamento dos produtos de trabalho, os chamados Artefatos
de Software para sua avaliação e controle. Consiste basicamente do
encaminhamento do produto pelo Responsável, preenchendo os campos do
Formulário de Encaminhamento de Produtos para a subseqüente submissão
ao Ambiente Integrado. O Ambiente destina o encaminhamento ao Gerente da
Qualidade para suas providências. O Gerente da Qualidade recebe o
Formulário, atribui um código para a revisão e encarrega um Revisor para
avaliar o produto. Novamente encaminha para o Ambiente que destina o
Formulário para o Revisor encarregado para a avaliação. Todos esses passos
são acompanhados por um Agente Monitor do Ambiente que altera o status do
processo, conforme o fluxo do trabalho. Neste caso o status possível é
Encaminhado a Qualidade ou Encaminhado ao Revisor. Um Agente
Mensageiro se encarregará de avisar, na forma de uma mensagem eletrônica e
de um registro na área de trabalho do Revisor, da abertura de uma tarefa. Vale
ressaltar que o produto durante este processo fica congelado no repositório, e
seu status, a meta informação que varia conforme o andamento do processo,
vai mudando, até atingir o final do processo Garantia de Produto. A Figura 5.4
ilustra a funcionalidade do caso de uso Encaminhar Produtos para Controle. As
Figuras C.12 e C15, do Apêndice C ilustram algumas das telas relacionadas
aos módulos User e Quality Assurance do caso de uso Encaminhar Produtos
para Controle.
224
Gerente da Qualidade
encaminhar formulário para o Ambiente
mudar status
Responsável pelo Produto
Agente Mensageiro
encarregar Revisor para avaliação
notificar envolvidos
Agente Monitor
FIGURA 5.4 - Caso de uso Encaminhar Produtos para Controle.
5.1.4 – Atividades de Avaliar Produtos
O principal objetivo desse diagrama e representar as diversas atividades
envolvidas na avaliação de produto para seu encaminhamento ao repositório
controlado de artefatos. A avaliação do produto é feita através de uma revisão
(verificação ou validação) conduzida pelo Revisor, que após definir os critérios
da revisão (associar checklists ou os testes apropriados) executa a revisão.
Esta execução, ou condução da revisão consiste, no caso da verificação, da
identificação dos itens que atendem ou não ao checklist de verificação relativo
225
o produto revisado. Por exemplo, para a revisão de um artefato de código Java
deve ser identificado quais itens o programa atende em relação ao Checklist de
Código Objeto. O Checklist de Código Objeto deve fazer parte da biblioteca de
checklists do Ambiente, de forma a ser disponibilizado quando necessário. O
Revisor pode também questionar o Responsável pelo Produto sobre qualquer
dúvida adquirida durante a revisão. O Responsável pelo Produto deve atender
a solução dessas possíveis dúvidas de modo a permitir o andamento normal
das atividades de revisão. Ao final tanto o revisor como o Gerente da
Qualidade dão seu parecer sobre o produto revisado. Em caso de parecer de
não-conformidade, o produto é retirado da área congelada do repositório, e o
Responsável pelo Produto fica sabendo que o processo de encaminhamento
para solução do problema é iniciado. Em caso de parecer de conformidade o
produto é encaminhado ao controle de configuração para ser integrado aos
itens de produtos controlados pelo projeto e conseqüentemente pelo Ambiente.
O status do processo pode ser Encaminhado ao Revisor, ou Revisado, ou Sob
controle da Gerência da Qualidade, ou Encaminhado a Gerência da
Configuração, ou Não Conforme, ou Conforme, Encaminha para Solução de
Problemas. A Figura 5.5 ilustra o diagrama de atividades Avaliar Produto,
abrangendo desde o encaminhamento do Produto pelo Responsável até o
parecer final do Gerente da Qualidade. As Figuras C.11, C14, C17 e C.18, do
Apêndice C ilustram algumas das telas referentes às atividades de Revisar
Produtos, dos módulos Quality Assurance e Quality Control, do protótipo QM.
226
Gerente da QualidadeResponsável peloProduto
Revisor
Encaminhar Produto
Abrir Avaliação
Definir CritériosFAP [código]
Avaliar Produto
solucionarduvidaSolucionar Dúvidas
solução nãoOK
solução OK
Emitir Parecer
FAP [parecer]Emitir Parecer
FAP [parecer]
Fechar Avaliação
I
FIGURA 5.5 – Diagrama de atividades Avaliar Produto.
227
5.2 – Os Recursos do Ambiente Necessários para os Processos
Com base nos requisitos levantados e analisados na sessão anterior, torna-se
possível, através da prototipação, a definição de quais são os recursos
necessários, em termos de serviços, que o Ambiente Integrado deve prover
para o suporte e automação dos processos de Gerência da Qualidade na
implantação de todos os processos apresentados no capítulo 4.
Para o suporte e automação de qualquer processo, o Ambiente Integrado deve
fornecer uma infra-estrutura que permita a manutenção de informações; a
automatização ou execução das atividades de um processo e a definição clara
do papel de cada participante no processo. A implementação de serviços que
auxiliem esta condução e controle do processo permitirá uma fácil interação
com o usuário e um controle seguro dos artefatos produzidos e manipulados
pelos usuários.
O enfoque desta análise feita foi baseado principalmente nos requisitos
definidos para o protótipo e na arquitetura lógica oferecida pelo Ambiente,
apresentada no capítulo 3, onde podemos observar a sua caracterização em
três camadas: de armazenamento, de serviços e de interação.
5.2.1 – Os Recursos da Camada de Armazenamento e Acesso
Os elementos que compõem a camada de Armazenamento e Acesso são
responsáveis pelo armazenamento e acesso às informações manipuladas no
Ambiente. Estes elementos podem estar em plataformas distribuídas ou
centralizadas, mas devem, de qualquer forma, integrar e gerenciar as
informações da qualidade relacionadas a projetos ou a organização como um
todo.
228
Dos recursos definidos para esta camada pelo Ambiente Integrado (Sant’Anna,
2000) e necessários para a realização das atividades da qualidade,
consideramos:
O armazenamento e a recuperação das informações da qualidade (de
acesso imediato (on line), ou informação histórica (off line)), deve ser
eficiente e rápido, dentro dos prazos estabelecidos pelo projeto e pela
sua política de desenvolvimento.
Deve ser possível que os vários envolvidos no processo tenham acesso
simultâneo a informações da qualidade, respeitando os critérios de
responsabilidade e acesso definido no projeto.
A camada deve comportar que trafegue um grande volume de
informações da qualidade pelo Ambiente.
O acesso (consulta, inclusão, alteração ou exclusão) às informações da
qualidade deve ser permitido somente aos papéis autorizados e seus
responsáveis.
A disponibilização das informações da qualidade deve ser acessível a
qualquer instante de tempo e de local, devendo ser feita de forma
controlada (senha e restrições de acesso).
As informações da qualidade podem ser manipuladas de forma
centralizada ou distribuídas, respeitando os critérios de recuperação da
informação em casos de falha no Ambiente (hardware, software ou infra-
estrutura física).
5.2.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
229
para obtenção e disponibilização das informações de projeto parra a camada
de interação com o usuário. São os serviços relacionados ao trabalho
cooperativo, a 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 qualidade,
consideramos:
O Serviço de Coordenação de Processos do Ambiente deve apoiar os
processos da qualidade, permitindo que os processos sejam modelados,
configurados, instanciados, acompanhados e terminados. O Serviço de
Coordenação deve garantir que os processos da qualidade sigam seu
fluxo normal de execução, avisando e relatando os participantes
envolvidos do processo em questões 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 Ambiente deve prover o
serviço de troca de mensagens entre os participantes envolvidos nos
processos da qualidade, devendo sempre ter a participação de um
remetente e um destinatário na utilização deste serviço. Deve também
conter o assunto a ser tratado pela mensagem como forma de
comunicação básica. Um agente mensageiro deve ser o responsável por
realizar as tarefas básicas deste serviço, identificando os remetentes e
destinatários da mensagem, seus privilégios no Ambiente, endereços
eletrônicos e informações básicas deste tipo de serviço. Pode, caso seja
configurado neste serviço, verificar em 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 Time da Qualidade enviadas com cópia automática para
230
a Gerência da Qualidade, por exemplo). Listas de discussão devem ser
criadas para que os grupos do projeto possam debater assuntos de
interesse da qualidade. Estas listas devem ser preparadas para incluir
em seu conteúdo, 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 qualidade,
principalmente quando a questão for de fórum urgente ou envolver um
grande número de participantes.
Os Serviços de Agenda deve permitir que as atividades formais da
qualidade, como as reuniões de avaliação possam ser agendadas
eletronicamente, anexando junto o material necessário a realização do
processo. As agendas são importantes, pois mantêm os indivíduos
informados sobre seus compromissos com as atividades da qualidade
ao longo do tempo.
O Serviço de Compartilhamento Temporário deve permitir a autoria
cooperativa dos produtos da qualidade, 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 qualidade. As referências e a situação dos
produtos devem também ser disponibilizadas para os participantes do
processo de 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 tem
autorização de compartilhamento de quais produtos (dados e
231
informações). Após uma determinada fase, especificada no processo,
este compartilhamento temporário se encerra, devendo o arquivo ser
encaminhado para seu controle permanente ou devolvido ao seu autor
ou responsável. Um Agente monitor atua regularmente neste serviço,
atualizando o status de cada produto da qualidade, conforme a
monitoração de alguns campos pré-determinados pela qualidade, a fim
de acompanhar e monitorar o andamento de um artefato durante sua
vida nos processos da qualidade.
O Serviço de Biblioteca deve manter e disponibilizar, para os
participantes envolvidos com os processos da qualidade, documentos
técnicos como relatórios da qualidade, formulários e checklists utilizados
nas atividades da garantia, planejamento e controle da qualidade. O
Serviço de Biblioteca deve manter e garantir também o acesso às
informações que tem relacionamento indireto com o projeto (políticas
organizacionais ou estratégias de desenvolvimento, por exemplo) para
que, durante a vida de um projeto ou mesmo para a organização como
um todo, seja fácil a pesquisa de busca destas publicações e que
possam ser disponibilizadas de forma concorrente e consistente.
O Serviço de Lembrança, ou Agenda Pessoal deve informar o time da
qualidade sobre suas tarefas cotidianas, sobre as datas importantes da
qualidade, como reuniões pré-estabelecidas de auditoria, cronograma de
projeto e a qualidade (baseline a ser alcançada em uma determinada
data, por exemplo). Cabe a este serviço permitir que o time da qualidade
possa registrar algo para ser lembrado, e manter seus registros.
O Serviço de Dicionário, Enciclopédia deve permitir que todos os
participantes envolvidos com a qualidade (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 a qualidade, os conceitos e termos relacionados ao próprio
232
Ambiente devem também ser descrito. Este serviço deve ser ágil e de
fácil manutenção, permitindo que seja atualizado e revisado
constantemente.
O Serviço de Documentação de Escritório deve permitir aos
participantes envolvidos com a qualidade manter e recuperar a
documentação administrativa endereçada a 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 qualidade 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
qualidade. O serviço de mensagens 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 qualidade tenham a oportunidade de apresentar suas
críticas, sugestões e dúvidas com relação a qualquer tópico relacionado
à qualidade, ao projeto ou ao Ambiente Integrado. O usuário pode,
através deste serviço, colocar suas críticas de forma construtiva e de
forma a permitir uma melhor adaptação das atividades da qualidade no
ambiente às necessidades dos indivíduos participantes do projeto.
O Serviço de Segurança deve permitir que qualquer envolvido nos
processos da qualidade tenham disponíveis serviços e produtos da
qualidade no Ambiente, através de uma identificação de uma senha, que
o habilitará ao acesso, com privilégios relativos ao seu papel que
desempenha relacionado a qualidade (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.
233
5.2.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 são
responsáveis pela comunicação do usuário com os processos da qualidade no
Ambiente a partir de qualquer ponto de uma rede de computadores, permitindo
seu trabalho remoto e cooperativo. A camada de interação com o usuário, ou
camada de execução, permite que os aplicativos que implementam os serviços
da qualidade no Ambiente sejam executados e possam realimentar os
processos com a conclusão das atividades e a confecção dos produtos da
qualidade 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 qualidade,
consideramos:
O acesso aos processos da qualidade no Ambiente Integrado 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) permitindo que as aplicações sejam executadas em
qualquer tipo de plataforma.
As telas relacionadas com os processos da qualidade devem ser
formatas de acordo com o padrão de janelas do Ambiente Integrado,
de forma a atender as atividades da garantia, planejamento e
controle da qualidade.
234
235
CAPÍTULO 6
CONCLUSÕES
Esta dissertação de mestrado intitulada “Uma Abordagem para a Gerência da
Qualidade em um Ambiente Engenharia de Software Centrado em Processo”
identificou e modelou um conjunto mínimo de práticas que a gestão da
qualidade deve adotar dentro de organizações fabricantes de software,
principalmente do setor voltado para aplicações espaciais, como o INPE e o
IAE.
Acredita-se que a definição e modelagem destes processos da qualidade
auxiliarão aos projetos de desenvolvimento de software, principalmente no que
tange as atividades fundamentais da gerência da qualidade. A implantação das
práticas da gestão da qualidade (e de seus processos) dentro do contexto de
um ambiente automatizado de desenvolvimento e gestão de projetos
determinará de forma concreta e objetiva o nível de qualidade dos produtos
resultantes.
Para se alcançar este objetivo foi necessário primeiramente o planejamento,
definição e modelagem das atividades referentes à garantia, planejamento e
controle da qualidade, a caracterização dos produtos intermediários e finais do
desenvolvimento do software e a definição de qual seria o papel dos envolvidos
nos trabalhos da qualidade.
Foi necessário o estudo das práticas e das atividades da qualidade e de seu
gerenciamento em projetos de software, o estudo dos padrões e dos modelos
relacionados ao tema qualidade, bem como a escolha de uma linguagem de
modelagem de processo de software que representasse adequadamente os
modelos de processo propostos.
236
Em adição aos aspectos de qualidade, padrões e linguagens, foi necessário
aprimorar o conhecimento sobre ambientes centrados em processo, mais
especificamente o Ambiente Integrado e-WebProject, que oferece suporte
eficiente e automatizado aos processos de engenharia de software, é
organizado em áreas de negócio e apóia as gerências estabelecidas em um
projeto através de diversos serviços oferecidos.
Através da intersecção de todos estes fatores, foram criados os modelos do
processo da qualidade, apresentados no capítulo 4, de forma a viabilizar sua
futura implantação e execução, no Ambiente integrado, atendendo com isso, às
necessidades básicas das funções da qualidade em projetos, e na organização
produtora de software como um todo.
Na seção 6.1 apresenta-se o histórico da condução deste estudo,
descrevendo-se como foi o andamento dos trabalhos de pesquisa, em termos
de produção científica reconhecida pela comunidade da área e de forma a
entender a evolução do amadurecimento dos conceitos apresentados nesta
dissertação. Na seção 6.2 são discutidos os resultados que foram alcançados
com o trabalho, tanto no nível teórico (a definição e modelagem dos processos)
como prático (a implementação do protótipo). Na seção 6.3 são discutidos os
benefícios desse trabalho para o desenvolvimento de software do setor
espacial brasileiro e são feitas algumas recomendações para trabalhos futuros,
principalmente no que tange às tarefas de avaliação e melhoria de processo,
atividades relacionadas aos mais altos níveis de maturidade em termos de
atributos dos processos.
6.1 - Histórico
Dentre as diversas atividades decorrentes de um estudo voltado para a
implantação de processos da qualidade em um ambiente de desenvolvimento
de software centrado em processo, era importante definir quais seriam as
237
funcionalidades da qualidade teriam seus processos modelados; que padrão,
ou padrões seria adotado como referência para as melhores práticas da
qualidade; que linguagem de modelagem mais se adequaria aos modelos
propostos e como o Ambiente Integrado deveria atender a implantação e
execução destes modelos.
Partindo desse princípio, foram feitas pesquisas referentes à definição e
modelagem de um processo fundamental da qualidade, que culminou em um
artigo, que descrevia um estudo para a definição e modelagem do processo
Aditar Produtos do Trabalho no e-WebProject (Lahoz et al., 2002), apresentado
no IV Simpósio Internacional de Melhoria de Processo de Software (SIMPROS)
em Recife (PE). O SIMPROS é o maior fórum para intercâmbio de informações
e conhecimento na prática de melhoria de processo de software (Software
Process Improvement – SPI) e é baseado no formato das conferências SEPG
(Software Engineering Process Group) realizadas anualmente nos Estados
Unidos, Europa e agora no Brasil. O processo de Auditoria, da categoria de
processos Suporte do projeto SPICE, permitiu identificar quais seriam os
passos mínimos necessários para a definição de um processo no Ambiente
Integrado, sendo fundamental para o início da pesquisa de quais processos
(atividades) a qualidade se responsabilizaria no Ambiente.
Em seguida, foi feito um estudo para a definição de quais seriam efetivamente
os processos que a Gerência da Qualidade definiria e modelaria para o
Ambiente Integrado (Abdala, et al, 2002), que foi apresentado no II Workshop
dos Cursos de Computação Aplicada (WORKCAP) do INPE, em São José dos
Campos (SP). Neste trabalho foram identificados as atividades de garantia,
planejamento e controle da qualidade como as principais áreas de atuação da
qualidade no Ambiente Integrado e sua relação junto aos processos propostos
pelo padrão ISO/IEC 15504.
Com o amadurecimento até então adquirido nos estudos de qualidade, padrões
de processo, linguagens de modelagem e do Ambiente Integrado, foi possível
238
apresentar o tutorial intitulado “Um ambiente Integrado para Suporte a Projetos
de Engenharia de Software” (Sant´Anna 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, baseado
na WEB, para apoio ao desenvolvimento e gestão de projetos de software.
Foram demonstradas aos participantes as técnicas atuais utilizadas em
projetos de desenvolvimento de software, como melhoria de processos e
modelos de maturidade (CMMI e 15504), o conceito de workflow, de trabalho
cooperativo e distribuído, como pode ser feito o suporte a processos evolutivos
e apresentada a estruturação organizacional de gerências do e-WebProject,
baseada no PMI, e mais especificamente às características e atribuições da
Gerência da Qualidade no Ambiente Integrado.
No V SIMPROS um relato sobre como foi empregada a linguagem de
modelagem de processo escolhida para a modelagem dos processos da
Qualidade no Ambiente Integrado (Abdala et al, 2003) foi apresentado. A
linguagem de modelagem SPEM, notação padrão UML, permitiu a definição
clara e precisa dos processos da Gerência da Qualidade no Ambiente
Integrado, visando sua posterior implementação e execução dos processos da
qualidade no Ambiente.
No III WORKCAP do INPE apresentaram-se os padrões ISO/IEC12207 e
15504 e a modelagem de processos da qualidade de software (Lahoz e
Sant´Anna, 2003). Neste trabalho, os modelos de processo de Suporte do
ISO/IEC15504 e do 12207 são apresentados como ponto de partida para a
definição dos processos da qualidade que devem ser implantados e
executados em um Ambiente Integrado. Segunda a visão proposta pelo
trabalho, os processos Suporte são diretamente relacionados com a gestão da
qualidade no Ambiente Integrado.
Mais recentemente, um artigo técnico contendo os modelos de processos de
gestão da qualidade de software, baseados no Padrão ISO/IEC 15504 (Lahoz e
239
Sant´Anna, 2004), foi submetido a 3ª Conferência Iberoamericana de Sistemas,
Cibernética e Informática (CISCI) 2004 e aprovado para ser apresentado. Nele
são relatados os processos da qualidade, já na visão da 15504, versão 2003, e
a abordagem de definição e modelagem para o Ambiente Integrado.
6.2 – Os Resultados Obtidos com os Trabalhos
Sob a ótica da qualidade, na visão de Jacobson (Jacobson et al., 1999) todos
compartilham da responsabilidade de sucesso ao se alcançar produtos de alta
qualidade (ou das críticas de não obtê-la). Nos processos propostos procurou-
se identificar as práticas apropriadas para a efetiva implantação das atividades
da qualidade em uma organização produtora de software, bem como identificar
os produtos e os papéis que devem ser utilizados para garantir que os objetivos
da qualidade sejam alcançados em projetos ou na organização como um todo.
Procurou-se, através destes modelos, identificar e endereçar as questões que
afetam a qualidade o mais cedo possível, incluindo a avaliação dos esforços
despendidos no gerenciamento da qualidade e a identificação da melhor
configuração que o processo precisa ter para alcançar seus objetivos. Foi
avaliado neste trabalho qual produto de implementação e de desenvolvimento
(requisitos, projeto e teste) é realmente necessário para a construção do
software (a ser entregue ao cliente ou mesmo interno ao desenvolvimento). Foi
feita também uma avaliação dos esforços despendidos nas revisões e
auditorias para sua avaliação de implementação, aderência e progresso do
processo de desenvolvimento. Foram, enfim, modelados os processos mínimos
necessários para que as atividades da qualidade contribuam fortemente para a
construção de um software que possa alcançar um nível internacional de
qualidade, principalmente para produtos de tecnologia espacial.
240
6.2.1 – Os Resultados Obtidos com a Abordagem de Padrões
É importante assegurar que os métodos e tecnologias utilizadas em processos
apóiem, avaliem e melhorem as atividades de desenvolvimento e manutenção
de software, e que se estabeleçam níveis mínimos de qualidade dos produtos,
dos procedimentos e dos padrões a serem usados durante todo o
desenvolvimento e vida útil do produto.
Uma dificuldade ainda existente no setor de desenvolvimento de software para
aplicações espaciais no Brasil é, após a definição de quais procedimentos e
produtos serão implementados e controlados pela qualidade, garantir-se que
todos os envolvidos no projeto estejam efetivamente comprometidos com o
cumprimento dos procedimentos e com a geração desses produtos ao longo do
tempo.
A gerência da qualidade deve ser capaz, também, de fornecer resultados
quantitativos e qualitativos referentes aos produtos e processos do projeto, que
sejam compreensíveis e confiáveis para a gerência geral ou para outros
envolvidos, permitindo assim analisar, conduzir e divulgar o desenvolvimento
da qualidade de produto (e de processo) dentro das exigências e dos padrões
internacionais aplicáveis à área de software espacial.
Diversos padrões de modelos de processo de desenvolvimento de software
surgiram nos últimos anos como, por exemplo, o 15504, o 12207 e o modelo de
referência CMMI. 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. Já
o padrão 12207 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. O CMMI é
um framework para avaliação e melhoria de processo disponível para o
desenvolvimento de produtos e serviços que incorpora as atividades de
desenvolvimento de software. Estes modelos representam o processo de
241
software sob a ótica de seu funcionamento, mas não apresentam COMO estes
processos devem ser definidos, ficando esta responsabilidade como uma
atribuição das organizações fabricantes das aplicações de software.
Procurou-se nesta dissertação, com base nos padrões estudados, identificar:
quais são e como estas atividades e práticas básicas da qualidade devem ser
realizadas pelas organizações produtoras de software; quais são os produtos
mínimos necessários para atender a estas atividades; e qual é o papel de cada
envolvido com a qualidade em um ambiente centrado em processo. Pretende-
se com isto obter um resultando positivo no cumprimento dos propósitos da
qualidade e de seu gerenciamento, e conseqüentemente, obter-se melhores
níveis de qualidade dos produtos de software das organizações que utilizarem
o Ambiente Integrado.
Segundo esta abordagem, um conjunto mínimo de processos da qualidade foi
definido e modelado para uso da Gerência da Qualidade no e-WebProject,
utilizando-se para isto, principalmente, os modelos de processo Suporte do
padrão internacional 15504. Acredita-se ainda que, com a utilização destes
modelos de processo em uma organização, possam-se atingir níveis mais altos
de capacidade, no que tange aos processos da qualidade, permitindo com isto
atender a requisitos funcionais e não funcionais de projetos críticos como é o
caso de projetos do Sistema de Controle de Satélites (SICS), ou o do Software
Aplicativo de Bordo (SOAB).
Os processos da 15504 contemplados nas atividades da qualidade no
Ambiente, são suficientes para atender aos Atributos de Processo (Process
Attributes), da dimensão Capacidade, respectivamente nos níveis 2, 3 e 4,
conforme a Tabela 6.1, através dos processos Configuração (CFG.1),
Qualidade (QUA.1, QUA.2, QUA.4 e QUA.5), Qualidade de Produto (PRO.1 e
PRO.2) e Gerenciamento (MAN.4), propostos por este trabalho.
242
TABELA 6.1 - Tabela de Relacionamento entre Processos e seus Atributos. Atributos do Processo Processos Relacionados PA PA PA PA PA PA PA PA
2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2 CFG.1 Documentação CFG.2 Gerência de configuração CFG.3 Gerência de problemas QUA.1 Garantia da qualidade QUA.2 Verificação QUA.4 Revisão conjunta QUA.5 Auditoria MAN.1 Alinhamento organizacional MAN.2 Gerência da organização MAN.3 Gerência de projeto MAN.4 Gerência da qualidade MAN.5 Gerência de risco MAN.6 Medidas PIM.1 Estabelecimento do processo PIM.2 Avaliação do processo PIM.3 Melhoria do processo RIN.1 Gerência de recursos humanos RIN.2 Treinamento RIN.3 Gerência do conhecimento RIN.4 Infra-estrutura REU.1 Gerência de bens REU.3 Engenharia do domínio
♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦
♦ ♦
FONTE: ISO/IEC15504-5 (2003).
6.2.2 – Os Resultados Obtidos com a Utilização da Modelagem
Segundo Acuña (Acuña e Ferre, 2001), a modelagem de processo de software
se refere à definição dos processos como modelos padronizados, algum
suporte automatizado adicional para modelagem e a execução dos modelos
durante o processo de software. Feiler (Feiler, 1993) observa que, cada modelo
foca ou dá prioridade, a pontos particulares de cada mundo complexo da
construção de software. Diferentes modelos de processos podem definir
diferentes pontos de vista. Por exemplo, um modelo pode definir os agentes
envolvidos em cada atividade, enquanto outro pode estar centrado no
relacionamento entre as atividades. Há ainda modelos que endereçam a
243
cultura organizacional e são focados nas capacidades comportamentais ou nos
encargos dos papéis envolvidos no processo de software (Acuña, 2000).
Um modelo é sempre uma abstração da realidade e, como tal, representa a
descrição de uma realidade parcial e simplificada, isto é, nem todas as partes
ou aspectos do processo são levados em conta no modelo. Geralmente, um
modelo de processo pode ser dividido entre muitos sub-modelos, expressando
diferentes pontos de vista ou perspectivas (Acuña e Ferre, 2001).
Com a utilização da modelagem, foi possível especificar como as atividades da
qualidade no Ambiente seriam conduzidas, quais os papéis e tarefas
envolvidas, os recursos consumidos, as ferramentas utilizadas, os produtos
desenvolvidos, bem como os mecanismos de comunicação entre as tarefas e
os papéis.
Um fator que favoreceu a escolha do SPEM da OMG para a criação dos
modelos de processos, é que ele tenta suprir a necessidade de um padrão para
as técnicas de modelagem de processo surgidas nos últimos anos, definindo
um conjunto mínimo de elementos necessários para descrever qualquer
processo de desenvolvimento de software. Outra vantagem da linguagem é
que ela utiliza uma abordagem orientada a objetos e se beneficia da
expressividade da UML. Assim, os 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.
Parafraseando Curtis (Curtis et al., 1992), pode-se argumentar que os objetivos
requeridos na utilização da modelagem de processos e que foram alcançados
nos modelos de processo da qualidade foram:
Facilidade de entendimento e comunicação: os modelos dos
processos da qualidade contém informações suficientes para sua
representação. Desta maneira esta formalização está também
244
provendo uma base para treinamento dos usuários do processo a ser
automatizado.
Suporte e controle ao gerenciamento do processo: através dos
modelos dos processos da qualidade, qualquer uma de suas
atividades poderá ser projetada para execução, monitorada,
gerenciada e coordenada.
Condições para orientações automatizadas para realização de
processos: os modelos dos processos da qualidade permitem
orientações aos usuários, instruções e material de referência,
necessários em um ambiente efetivo de desenvolvimento de
software.
Condições para suporte à execução automatizada: através dos
modelos dos processos da qualidade é possível identificar as
atividades, papéis e produtos envolvidos nas atividades da qualidade
a serem automatizadas, representando como será o suporte ao
trabalho cooperativo, a forma de registro das medições e a garantia
da integridade do processo.
Suporte à melhoria do processo: os modelos permitem o reuso dos
modelos dos processos da qualidade de forma efetiva, a comparação
de processos alternativos e suporte ao desenvolvimento de outros
processos da qualidade.
Além dos benefícios de descrever a estrutura e organização de um processo,
promovendo seu entendimento de uma forma precisa, os modelos tornam-se
um instrumento importante para a eliminação de inconsistências na sua
especificação. Este recurso é útil para o treinamento e aprendizado de equipes
sobre procedimentos e operações organizacionais, onde os processos podem
245
ser interpretados e utilizados para fornecer diferentes níveis de suporte para as
pessoas envolvidas nas atividades da qualidade. Finalmente permite-se a
simulação e otimização de processos que pode ser útil para a avaliação de
problemas e propostas para melhorias.
6.2.3 – Os Resultados Obtidos com a Utilização do Ambiente Integrado
Ambientes de engenharia de software centrado em processos, os chamados
PSEEs, estão se tornando um recurso cada vez mais utilizado para auxiliar nos
projetos de desenvolvimento de software. Um crescente número de sistemas
está revelando e aplicando processos para produção de software, gerando
produtos e protótipos baseados em uma variedade de tecnologias e
abordagens, como as de linguagens e base de dados orientados a objetos,
notações orientadas a estados, linguagens baseadas em regras, e linguagens
lógicas (Ambriola et al; 1997).
Dentro deste enfoque, procurou-se disponibilizar modelos de processos para
serem implantados em uma máquina que permita a sua automação, dentro de
um ambiente, como o e-WebProject, que possa ser utilizado em aplicações de
desenvolvimento de software, principalmente no setor espacial brasileiro.
Definiu-se um conjunto mínimo de atividades, papéis e produtos que o
Ambiente Integrado deve gerenciar que, acredita-se, apesar de serem
caracterizadas de forma genérica, com as devidas adequações, permitirão
alcançar patamares satisfatórios de qualidade tanto de produto como de
processo de desenvolvimento de software.
Na definição e modelagem dos processos relacionados à gerência da
qualidade para o Ambiente Integrado e-WebProject, surgiram diversos modelos
de processos para cada atividade da qualidade e que afetam diretamente a
construção do software. Foram definidos os processos essenciais da qualidade
246
que o Ambiente Integrado deve disponibilizar, levando-se em conta as
atividades da qualidade (gerenciamento, garantia, controle e qualidade de
produto) voltadas para os projetos e para a organização como um todo.
Com os recursos do e-Webproject, como um conjunto de ferramentas
integradas para trabalho cooperativo, será possível dar o suporte à execução
de processos, disponibilizando informações através da WEB/Internet, e
permitindo a implantação dos processos da qualidade de forma a atingir seus
objetivos com um alto grau de qualidade e de forma rápida.
A perspectiva ainda de se obter maior eficiência nas atividades da qualidade,
através de facilidade de uso, do suporte à comunicação instantânea de uma
grande quantidade de usuários, da visibilidade dos produtos e dos processos e
do gerenciamento de projetos simultâneos, faz do Ambiente Integrado um
instrumento importante para o futuro das organizações que quiserem produzir
software com a qualidade dentro de padrões internacionais.
Vale ressaltar que durante o desenvolvimento do trabalho foi fundamental a
aplicação e implementação dos conceitos e tecnologias pesquisadas através
do desenvolvimento de um protótipo que contemplasse um processo
fundamental da qualidade.
Além de poder empregar os conceitos de qualidade, padrões e técnicas de
modelagem de processo, esta prática permitiu avaliar a real viabilidade de um
processo fundamental da qualidade quando de sua execução no Ambiente
Integrado. Através do protótipo foi também possível extrair informações
relativas aos serviços mínimos necessários que o e-WebProject deve prover
para a real implantação dos processos da qualidade no Ambiente.
247
6.3 – Benefícios e Recomendações do Trabalho
O setor espacial brasileiro, tanto no segmento de veículos como no de
satélites, na última década registrou expressivos avanços. Assim como em
outros programas espaciais, bem como outros setores industriais, observa-se
um crescimento exponencial do uso de software embarcado. O exercício de
propor novos procedimentos metodológicos e gerenciais para as atividades da
qualidade no desenvolvimento de projetos de software, permitirá a criação
tanto de produtos como de processos com mais qualidade e confiabilidade.
Posteriormente à identificação das melhores práticas observadas nos modelos
de qualidade propostos, o próximo passo seria apresentar como avaliar e
melhorar estes processos. A avaliação e melhoria devem ser feitas de modo a
considerar os aspectos gerencial, prático e estratégico, visando alcançar os
objetivos da qualidade, do projeto e do negócio da organização. A execução e
a forma de melhoria de cada processo avaliado, devem ser feitas dentro das
regras e critérios adotados pelo Ambiente e-WebProject, de maneira a atender
as organizações alvo, quais sejam, as de tecnologia espacial ou de qualquer
outro segmento de desenvolvimento de software.
Estas atividades devem ser conduzidas de forma a se atingir, dentro de um
contexto o mais amplo possível, as metas organizacionais, de qualidade, e de
desenvolvimento de qualquer tipo de projeto que fizer uso deste Ambiente.
Obviamente que um processo qualquer da qualidade, para ser efetivo, tem que
ser ajustado para reagir proporcionalmente ao esforço, pessoas envolvidas,
escopo do grupo e características do ciclo de vida do software adotado. Estes
parâmetros devem ser fornecidos pelo Ambiente Integrado quando da
instanciação de um determinado projeto.
O próximo passo seria fornecer um conjunto ideal de processos que atendam
qualquer exigência de projeto e da organização como um todo. As atividades
da qualidade assim serão capazes de atender as exigências estratégicas e
248
tecnológicas de um mercado em constante evolução, podendo inclusive, avaliar
e planejar melhorias dos processos estabelecidos de modo a alcançar níveis
mais elevados de maturidade e capacitação.
6.3.1 – Benefícios da Abordagem
Os avanços tecnológicos do setor espacial brasileiro, em especial o de projetos
de software, tem apresentado desafios que, para serem superados, exigem a
consideração de um vasto elenco de atributos de qualidade, considerando as
questões técnicas, metodológicas e gerenciais que o tratamento multidisciplinar
desse tipo de abordagem necessita. Para a efetivação dessa abordagem da
gerencia da qualidade, buscou-se consolidar, através da adoção de um modelo
formal dos processos da qualidade em um ambiente de engenharia de
software. Procurou-se, com os processos propostos, orientar procedimentos
para a avaliação dos produtos, para a definição da documentação e de seus
padrões, para a definição de métricas, entre outras questões necessárias à
altura da tecnologia em desenvolvimento. Isso requer ainda que a abordagem
proposta seja criticada e devidamente adequada ao ambiente específico em
que serão inserido os processos, de forma que favoreça o amadurecimento das
equipes e dos procedimentos organizacionais como um todo.
Entende-se que com o contínuo processo de inovação tecnológica e as
exigências de novos requisitos que envolvam software como componente
crítico do sistema, é necessário procedimentos de fabricação cada vez mais
rigoros e controlados. É imperioso que o tratamento de tais requisitos e da
complexidade decorrente seja feito com uma abordagem sistêmica, nela
compreendida o enfoque da garantia da qualidade e da segurança (Moura et al,
1998).
249
6.3.2 – A Avaliação de Processo
Avaliação de processo de software é o exame dos processos usados por uma
organização comparados com um conjunto de critérios que determina sua
capacidade para executá-los, dentro de objetivos de qualidade, custo e
cronograma. Seu objetivo na organização é de:
Caracterizar as práticas de engenharia de software correntes.
Identificar as competências e as fragilidades.
Estabelecer qual é a habilidade do processo para controlar ou evitar
as causas significantes de problemas na qualidade, nos custos, no
cronograma e na execução do projeto.
Os processos da qualidade precisam sofrer continuamente mudanças e
refinamentos para melhorar a sua habilidade de alcançar os requisitos
indicados e as expectativas dos envolvidos. Portanto, segundo Fuggetta
(Fuggetta, 2000), os processos precisam ser continuamente avaliados e
melhorados. Esta avaliação deve ter como objetivo (Oliveira, 1995):
A compreensão do estado dos processos de uma organização, para
a melhoria dos mesmos.
Estabelecer a conformidade dos processos de uma organização a
um requisito em particular ou uma classe de requisitos.
Determinar a adequação dos processos de uma outra organização a
um contrato ou uma classe de contratos.
Algumas das principais razões pelas quais as organizações devem fazer
avaliações sobre processos de software, são, segundo Jung (Jung et al, 2001):
250
Estabelecer marcos e/ou um caminho para a melhoria de processo
da organização.
Melhorar a eficiência.
Estabelecer um guia de boas práticas para a melhoria de processo
da organização.
Estabelecer marcos de projeto e/ou um caminho para a melhoria de
projeto/processo.
Melhorar o serviço ao cliente.
Atender a demanda do cliente por melhoria da capacidade do
processo.
Gerar suporte ao gerenciamento e melhoria do processo de
aquisição de software.
Gerar um time de suporte técnico e uma melhoria de processo de
aquisição de software.
Melhoria da confiabilidade dos produtos.
Melhoria da confiabilidade dos serviços de suporte aos produtos.
Obter vantagens de mercado.
Pressão de competição/mercado por demonstrar capacidade de
processo como um procedimento mensurável importante.
251
6.3.3 – A Melhoria de Processo
Melhoria de processo de software significa entender os processos existentes e
mudar estes processos para melhorar a qualidade dos produtos e/ou reduzir
custos e tempo de desenvolvimento (Sommerville, 2001).
O programa de melhoria das organizações de maior maturidade deve ter forte
ênfase na automatização dos processos de software e também precisa ser
endereçado a temas relacionados às pessoas envolvidas. Processos, coleta de
dados, análise estatística devem ser automatizados quando possível. O esforço
e a participação na definição e melhoria de processo precisa ser real e fazer
parte do trabalho cotidiano. A abordagem do gerenciamento da qualidade
envolve uma ligação da qualidade com os objetivos do negócio no foco da
satisfação do cliente (Paulk, 1999).
Além dos fatores citados, deve-se criar uma cultura de qualidade em
organizações de maior maturidade (Miller, 1998). Prêmios e incentivos devem
ser estabelecidos para a busca de melhoria de processos, e os esforços e a
participação dos funcionários devem ser mais do que uma frase de efeito. As
pessoas acreditam no processo, e quando erros acontecem (como
inevitavelmente acontece em qualquer esforço humano), o foco é na melhoria
do processo, não disciplinando as pessoas, que podem ser somente os
portadores de más notícias (Paulk, 1999).
252
253
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.
Resumo... 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.
Acuña, S. T. e 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. 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.
Ambriola, V. diI Meglio, R., Gervasi, V., Mercurio, B. In: Applying a metric
framework to the software process: an experiment. In: European Workshop
Software Process Technology, 3., 1994, London, UK. Proceedings... London:
Springer, 1994. p. 207-226.
254
Associação Brasileira de Normas Técnicas (ABNT), NBR-ISO 8402. Gestão da
qualidade e garantia da qualidade - Terminologia, Rio de Janeiro: 1997.
Associação Brasileira de Normas Técnicas (ABNT) NBR ISO-9001. Sistemas
de gestão da qualidade - requisitos, Rio de Janeiro: 2000.
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.
Ben-Shaul, I.; Kaiser, G. E. A paradigm for decentralized process modeling and
its realization in the Oz environment. In: International Conference on Software
Engineering ,16., (ICSE), May 1994, Sorrento, Italy. Proceedings... Sorrento,
1994. p. 179-188.
Bertolino, A. e Strigini, L. On the use of testability measures for dependability
assessment. IEEE Transaction on Software Engineering, v. 22, n. 2, p. 97-
108, Feb. 1996.
Booch, G., Rumbaugh, J., Jacobson, I. The unified modeling language: user
guide, Massachusetts, EUA: Addison-Wesley, 2000. 482p.
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.
Coallier, F. International standardization in software and systems engineering and the global IT market. Recife, 2003. Palestra realizada no
Simpósio Internacional de Melhoria de Processo de Software, 5. (SIMPROS)
em nov. 2003.
255
Coleman, D., Ash, D., Lowther, B., Oman, P. W. Using metrics to evaluate
software systems maintainability. IEEE Computer, v.27, n.8, p.44-49, Aug.
1994.
Conallen, J. Building web applications with UML. Massachusetts, EUA:
Addison Wesley, 2000. 320p.
Conradi, R., Fernstrom, C., Fuggetta, A. Concepts for evolving software
processes. In: Software process modeling and technology. Taunton, UK:
Research Studies Press, c. 2, 1994, p. 9-31.
Crosby, P. B. Quality is free: the art of making quality certain. New York:
Mentor Books; Reissue edition, Jan 1980. 288p.
Cruz, T. Workflow: a tecnologia que vai revolucionar processos. São Paulo:
Atlas, 1998. 232p.
Cugola, G. e 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, Sep. 1992.
Curtis, B. The global pursuit of process maturity. IEEE Software, v. 17, n. 4, p.
76-78, July/Aug. 2000.
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.
Fenton, N. E. e Pfleeger, S. L. Software metrics: a rigorous & practical
approach. Boston, USA: PWS Publishing Company; 1997. 656p.
256
Fenton, N. Software measurement: a necessary scientific basis. IEEE Transaction on Software Engineering, v. 20, n. 3, p. 199-206, Mar. 1994.
Finkelstein, A., Kramer, J. B., Nuseibeh, B. Software process modeling and technology. Taunton, UK: 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, 1999. p. 292-307.
Freeman, P. A. Software perspectives: the system is the message. Reading,
USA: Addison-Wesley, 1987, 294p.
Fuggetta, A. Software process: a roadmap. In: Future of Software Engineering.
Limerick, Ireland., 2000. Proceedings... New York: ACM Press, 2000. 630p.
Hass, A. Configuration management principles and practice. Boston, USA:
Person Education, 2002. 432p.
Humphrey, W. S. A discipline for software engineering. Reading, USA:
Addison-Wesley Publishing Company, 1995. 816p.
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.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 12207. International standard for information
technology - software life cycle processes. Geneva, Switzerland, 2001.
Amendment 1.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 15504-1. Information technology – software
257
process assessment part 1: concepts and introductory guide. Geneva,
Switzerland, 1998. Technical Report.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 15504-2. Information technology — process
assessment: part 2: - performing an assessment. Geneva, Switzerland, 2003.
International Standard.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 15504-2. Software process assessment – a
reference model for processes and process capability, part 2. Geneva,
Switzerland, 1998, Technical Report.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 15504-5, Information technology – software
process assessment part 5 - an assessment model an indicator guidance,
Geneva, Switzerland, 1998. Technical Report.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 15504-5. Information technology – process
assessment: part 5: - an exemplar process assessment model. Geneva,
Switzerland, 2003. Committee Draft.
International Organization of Standardization/ International Electrotechnical
Commission (ISO/IEC), ISO/IEC 9126, Information Technology - Software
product evaluation, quality characteristics and guidelines for their use. Geneva,
Switzerland, 1991. International Standard.
International Organization of Standardization (ISO), ISO 9000. Quality
management systems - fundamentals and vocabulary. Geneva, Switzerland,
2000. Standard.
258
Jacobson, I.; Booch, G., Rumbaugh, J. The unified software development process. Massachusetts, EUA: Addison-Wesley Publishing Company, 1999.
463p.
Jung, H., Hunter, R., Goldenson, D. R., El-Amam, K. Software process improve practice: findings from phase 2 of the SPICE trials. Hoboken, USA:
John Wiley & Sons, Ltd., 2001. p. 205-242.
Juran, J. M. Juran on quality by design: the new steps for planning quality
into goods and services. Washington, USA: Free Press, 1992. 538p.
Karlsson, E. A., Software reuse: a holistic approach. Hoboken, USA: John
Wiley & Sons, 1995. 528p.
Kimball, R., Reeves, L., Ross, M., Thornthwaite, W. The Data warehouse lifecycle toolkit: expert methods for designing, developing, and deploying data
warehouses. Hoboken, USA: John Wiley & Sons,1998. 800p.
Kitchenham, B., Pfleeger, S. L. Software quality: the elusive target, IEEE Software, v.13, n.1, p.12-21 Jan. 1996.
Lahoz, C. e Sant’Anna, N. Os padrões ISO/IEC 12207 e 15504 e a modelagem
de processos da qualidade de software, in: Workshop em Computação
Aplicada, 3., (Workcap), nov. 2003, São José dos Campos. Anais... São José
dos Campos: INPE, 2003. p. 43-48.
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, 4., (SIMPROS), set. 2002, Recife. Resumo... Recife, 2002.
Leite, J. C. S. P., Software evolution, the requirements engineering view. In:
Jornadas Argentinas de Informática e Investigación Operativa - Simpósio en
259
Tecnologia de Software, 26., (SoST), Buenos Aires, Argentina. Proceedings... Buenos Aires, 1997. p. 21-23.
Linger, R. C., Cleanroom process model, IEEE Software, v.11, n.20, p.50-58,
1994.
McCabe, T. J. A complexity measure, IEEE Transactions on Software Engineering; v. 2, n. 4, p- 308-320, Dec. 1976.
Ministério da Ciência e Tecnologia. Secretaria de Política de Informática
(MCT/SEPIN). Qualidade e produtividade no setor de software brasileiro
Disponível em < http://www.mct.gov.br/sepin>
Acesso em 11 maio 2003.
Meira Filho, L. G., Guimarães, T. F., Barcelos, E. D. Considerações sobre a
natureza estratégica das atividades espaciais e o papel da Agência Espacial
Brasileira. Parcerias Estratégicas, n. 7, p. 7- 20, out.1999.
Miller, C. Sustaining a continuous improvement culture: from start-up venture to
big business in a decentralized culture. In: Software Engineering Process Group
Conference (SEPG), Mar. 1998, Chicago, USA. Proceedings... Pittsburgh,
USA, 1998.
Mills, H. D., Dyer, M. Cleanroom software engineering. IEEE Software, V.4,
N.5, p.19-25, 1987.
Moller, K. H., Paulish, D. J. Software metrics: a practitioner’s guide to
improved product development. Los Alamitos, EUA: IEEE Computer Society,
Mar. 1993. 257p.
Moura, C. A. T., Lahoz, C., Abdala, M. A practical approach to quality
assurance in critical systems. In: First Latin American Dependable Computing-
LADC, São Paulo, Oct. 2003. Proceedings... New York: Springer, 2003,
v.2847. p. 369 – 370.
260
Moura, C. A. T., Domiciano, A. J. V., Fernandes, M. O. S. Incorporação de
software embarcado em veículos espaciais brasileiros. In: Congresso
Internacional de Tecnologia de Software, 9., Curitiba, Brasil,1998. Anais... Curitiba, 1998.
Munson, J. C. Software measurement: problems and practice. In: Software
Engineering, Switzerland, Aug. 1995. Annals... Switzerland, 1995, v.1. p. 255-
285.
Nascimento, C. J. A Melhoria da qualidade e produtividade no contexto da nova
lei de TI e da política de software, 2002. Palestra proferida no Workshop da
Qualidade e Produtividade em Software (WQPS) em 11 março de 2002.
Oliveira, A. M. Avaliação de processos de software: modelos e o TAQS-PROC.
In: Workshop de Qualidade de Software, 9. (SBES), Recife, 1995. Anais... Recife, v. 1. p. 42 - 46.
Oman, P. Construction and testing of polynomials predicting software
maintainability, Journal of System and Software, v. 24, n.3, p. 251-266, Mar.
1994.
Osterweil, L. Software processes are software too. In: International Conference
on Software Engineering, 9., Monterey, USA, Mar. 1987. Proceedings... Monterey, 1987. p. 2-13.
Parnas, D. L., MADEY, J., IGLEWSKI, M., Precise documentation of well-
structured programs, IEEE Transactions on Software Engineering, v. 20,
n.12, p. 948-976, 1994.
Paulk, M. C. Practices of high maturity organizations. In: SEPG Conference,
Atlanta, GE, USA, Mar. 1999. Proceedings... Atlanta, 1999. p.1-25.
Pfleeger, S. L. Software engineering: theory and practice. New York: Prentice
Hall, 2.ed., 2001. 576p.
261
Pfleeger, S. L. Software engineering: the production of quality software. 2.ed.,
New York: Macmillan Pub. Co., 1991. 517p.
PMI, Project Management Institute, A guide to the project management body of knowledge. Charlotte N. C: Project Management Institute, 1996. 216p.
Ponnambalam, K., S. Kalaichelvan, N. Goel, and Munikoti, R. Analyzing
sensitivities of software qualities to various metrics. In: International Conference
on Software Quality, 6., Ottawa, Canada, Oct. 1996. Proceedings....Ottawa,
1996.
Pressman, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
872p.
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.
Ross, D. Structured Analysis (SA): A language for communicating ideas, IEEE Transactions on Software Engineering, v. 3, n.1, p. 16-34, Jan. 1977.
Rout, T. Overview of CMMI: system/software eng. continuous representations.
In: Simpósio Internacional de Melhoria de Processo, 4., (SIMPROS), Recife,
Brasil, nov. 2002. Anais... Recife, 2002, v.1. p. 1-16.
Rout, T.P., Tuffley A., Cahill B. CMMI evaluation: Capability Maturity Model
Integration mapping to ISO/IEC 15504-2:1998. Queensland, Australia: Software
Quality Institute, Nov. 2001. prepared for the Australian Defense Material
Organization.
Salviano, C. F. Introdução aos modelos CMM: ISO/IEC 15504 (SPICE) e
CMMI. In: Simpósio Internacional de Melhoria de Processo de Software, 5.,
(SIMPROS), Recife, nov. 2003. Anais... Recife, 2003. p. 367-394.
262
Sanches, R. Documentação de software. In: Rocha, A.N.C., Maldonado, J. C.,
Weber, K. C.(aut.) Qualidade de software: teoria e prática. 1. ed., São Paulo:
Editora Makron Books, 2001, v.1. p. 54-59.
Sant’Anna, N., Cereja Jr., M. G., Borrego Filho, L. F., Luquel, L., Casilo, B. H.
e-WebProject - 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.
Magee, S. Software Engineering Process Technology (SEPT), Issaquah,
USA, Disponível em: <http://www.12207.com/12207-news.htm>
Acesso em: 18 de fev. 2004.
Sommerville, I., Software engineering, 6. ed., Reading: Person Education
Limited, 2001. 693p.
Software Process Engineering Metamodel Specification (SPEM), Version 1.0,
Needham, USA: Object Management Group, formal 02-11-14, Nov. 2002.
Software Process Improvement and Capability Determination (SPICE),
Software process assessment – part 2, a model for process management,
Queensland, Australia. Version 1.0. 1995.
Abran A., Moore, J. M. Guide to software engineering body of knowledge
(SWEBOK), Los Alamitos, USA: IEEE Computer Society, May 2001. trail
version,
Troster, J., Tian, J., Measurement and defect modeling for a legacy software
system, Annals of Software Engineering. V.1:, p. 95-118, 1995.
Unhelkar, B., Process quality assurance for UML-based projects. Boston,
USA: Addison-Wesley, Oct. 2002. 432p.
263
Wheeler, S. e Duggins, S. Improving software quality. In: ACM Southeast
Regional Conference, Marietta, USA, 1998. Proceedings…Marietta, 1998. p.
300-309.
Yu, X. e Lamb, D. A. Metrics applicable to software design. Annals of Software Engineering. v.1, p. 23-41,1995.
Zamli, K. Z. e Lee, P. A. Taxonomy of process modeling languages. In:
International Conference on Computer Systems and Applications, Beirut,
Lebanon, June 2001. Proceedings… Beirut, 2001. p. 435-437.
Zulmer, R. E. Software quality engineering: the Deming way, Englewood
Cliffs, USA: American Programmer, June 1989.
264
265
BIBLIOGRAFIA COMPLEMENTAR
Benali, K., Derniame, J. C. Software processes modeling: what, who, and when.
In: European Workshop on Software Process Technology, 2., Sep. 1992,
Trondheim, Norway. Proceedings... Trondheim, 1992. p. 21-25.
Cereja Jr, M. G. O serviço de coordenação de processos para o ambiente “e-WebProject”. Proposta (Mestrado em Computação Aplicada), Instituto
Nacional de Pesquisas Espaciais, São José dos Campos, 2002.
Cortês, M. L. INF310 - Curso de extensão em engenharia de software,
modelos de qualidade de software. Campinas: Unicamp, 2001.
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, UK: Springer-Verlag, 2000. p. 96-108.
Kadia, R. Issues encountered in building a flexible software development
environment: Lessons from the Arcadia project. In: Symposium on Software
Development Environments, Washington, USA, 1992. Proceedings... New
York: ACM Press, 1992.
Lahoz, C. e Sant’Anna, N. Os modelos de processos de gestão da qualidade
de software baseados no padrão ISO/IEC 15504, Conferencia Iberoamericana
en Sistemas, Cibernética e Informática, 3., (CISCI), Orlando, USA, July, 2004.
aceito.
266
Ministério da Ciência e Tecnologia (MCT), Qualidade e produtividade no setor de software, glossário de termos da qualidade, 1999.
Disponível em:<http://www.mct.gov.br/Temas/info/Dsi/qualidad/Qualidade.htm>
Acesso em: 26 abril 2002.
PHOPA, V. A. Standard for software documentation. IEEE Computer Society,
v.30, n.10, p. 97-98, 1997.
Sant’Anna, N., Um ambiente experimental para a engenharia de software,
1993. (INPE-5540-TDI/528). Dissertação (Mestrado em Computação Aplicada)-
Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 1993.
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.
Terry, R., Software process assessment, part1 concepts and introductory
guide. Queensland, Australia, ver. 1, 1995.
Yourdon, E. The Decline and fall of the american programmer. New York:
Prentice Hall, 1992. 212p.
267
APÊNDICE A
DIMENSÃO DE PROCESSO E DE CAPACIDADE DO PADRÃO
ISO/IEC 15504
Dimensão de Processo
A dimensão de processo está diretamente relacionada ao modelo de referência
de processo, Process Reference Model (PRM), que compreende definições de
processos em um ciclo de vida. Está descrito em termos de objetivos e
resultados de um processo e produtos do trabalho envolvidos no processo. O
ciclo de vida de processo possui três categorias: Primários (Primary),
consistindo dos grupos Aquisição, Fornecedor, Engenharia e Operação;
Organizacional (Organizational), consistindo dos grupos Gerenciamento,
Melhoria, Recurso & Infra-estrutura e Reuso; Suporte (Suport), consistindo dos
grupos Controle de Configuração, Garantia da Qualidade e Qualidade de
Produto. Para cada um destes processos existe uma definição dos resultados
da sua implementação bem sucedida bem como uma descrição detalhada de
cada uma das práticas básicas.
Categoria de Processos Primários
São responsáveis pela geração dos produtos de software, constituindo o ciclo
de vida de software propriamente dito. Atendem ao início, à contratação entre o
adquirente (organização que adquire um sistema ou produto de software,
podendo ser também representada pelo comprador, cliente, proprietário ou
usuário) e o fornecedor (organização que fornece o sistema, serviço ou produto
contratado). Atende também a execução do desenvolvimento e operação do
software durante seu ciclo de vida. São representados pelos processos de
Aquisição, Fornecimento, Engenharia e Operação.
268
Grupo de Processos de Aquisição (ACQ)
O grupo de processo Aquisição consiste dos processos realizados pelo cliente
de modo a adquirir um produto e/ou serviço.
Processo Preparação da Aquisição (ACQ.1)
Define o processo de estabelecimento das necessidades e objetivos para a
aquisição e a comunicação com os potenciais fornecedores.
Processo Seleção do Fornecedor (ACQ.2)
Define o processo de escolha da organização que será responsável pela
entrega dos requisitos do projeto.
Processo Monitorização do Fornecedor (ACQ.3)
Define o processo de acompanhamento e avaliação do desempenho do
fornecedor em conformidade com os requisitos acordados.
Processo Aceitação do Cliente (ACQ.4)
Define o processo de aprovação das entregas do fornecedor quando todos os
critérios de aceitação forem satisfeitos.
Grupo de Processo Fornecedor (SPL)
O grupo de processo Fornecedor consiste dos processos realizados pelo
fornecedor de modo a fornecer um produto e/ou serviço.
Processo Proposta do Fornecedor (SPL.1)
269
Define o processo de que estabelece uma interface de resposta para as
questões do cliente e requisições para propostas, preparação e submissão de
propostas, e confirmação de acordos através de um contrato estabelecido.
Processo Acordo Contratual (SPL.2)
Define o processo de negociação e aprovação de contratos/acordos claros e
sem ambigüidades de expectativas, responsabilidades, produtos do trabalho/
entregas e obrigações entre fornecedor e adquirente.
Processo Entrega de Software (SPL.3)
Define o processo de controle de entrega do “pacote” produto para o cliente.
Isto inclui sua configuração, a forma de entrega , a duração do suporte técnico
ao produto, entre outros detalhes.
Processo Suporte a Aceitação do Software (SPL.4)
Define o processo de ajuda ao cliente em alcançar confiança de uso e
apropriação do produto no ambiente de uso.
Grupo de Processo Operação (OPE)
O grupo de processo Operação consiste dos processos que dão suporte a
transição do produto ou serviço para o cliente, e provê sua correta operação e
uso.
Processo Uso Operacional (OPE.1)
Define o processo de garantia da correta e eficiente operação do produto
durante seu uso no ambiente instalado.
Processo Suporte ao Cliente (OPE.2)
270
Define o processo de estabelecimento e manutenção de um nível de serviço
aceitável para suporte ao produto do fornecedor para o cliente.
Grupo de Processo Engenharia (ENG)
O grupo de processo Engenharia consiste dos processos que diretamente
elicitam e gerenciam os requisitos do cliente, especificam, implementam, ou
mantém o produto de software e sua relação com o sistema.
Processo Elicitação de Requisitos (ENG.1)
Define o processo de reunião, processamento e investigação das necessidades
do cliente e seus requisitos, através do ciclo de vida do produto e/ou serviço de
software, para se estabelecer um marco (baseline) que servirá de base para
definir as necessidades dos produtos do trabalho.
Processo Análise de Requisitos de Sistema (ENG.2)
Define o processo de transformação dos requisitos definidos pelos envolvidos
em um conjunto de requisitos técnicos desejáveis, que servirão como guia para
o projeto do sistema.
Processo Projeto de Arquitetura do Sistema (ENG.3)
Define o processo de identificação de quais requisitos do sistema devem ser
alocados para quais elementos do sistema.
Processo Análise de Requisitos de Software (ENG.4)
Define o processo de estabelecimento dos requisitos dos elementos de
software do sistema.
Processo Projeto de Software (ENG.5)
271
Define o processo de definição do projeto para o software que implementa e
pode ser verificado em conformidade com seus requisitos.
Processo Construção de Software (ENG.6)
Define o processo de produção das unidades de software que refletem
apropriadamente o projeto de software.
Processo Integração de Software (ENG.7)
Define o processo de combinação das unidades de software de modo a
produzir um item integrado de software que demonstra que os requisitos
funcionais e não funcionais de software são satisfeitos em uma plataforma
operacional completa.
Processo Teste de Software (ENG.8)
Define o processo de confirmação de que o produto de software integrado
satisfaz os requisitos definidos.
Processo Instalação (ENG.9)
Define o processo de instalação do produto de software de acordo com os
requisitos estabelecidos e no ambiente de operação
Processo Integração de Sistema (ENG.10)
Define o processo de integração dos elementos do sistema (incluindo itens de
software, hardware, manual de operação, e outros sistemas) para produzir um
sistema completo que satisfará o projeto do sistema bem como as expectativas
do cliente expressadas nos requisitos do sistema.
Processo Teste de Sistema (ENG.11)
272
Define o processo de garantia de que a implementação de cada requisito do
sistema seja testado para confirmação de que o sistema está pronto para
entrega.
Processo Manutenção do Sistema e do Software (ENG.12)
Define o processo de modificação de um sistema/software depois da entrega
para correção de falhas, melhorias de desempenho ou outros atributos, ou para
adaptação de mudanças de ambiente.
Categoria de Processos Suporte
Define a categoria de processo que pode ser aplicado por qualquer outro
processo (incluindo outros processos da categoria Suporte) em vários pontos
do ciclo de vida do software. Têm como objetivo auxiliar outros processos,
visando principalmente à qualidade e o sucesso do projeto. São representados
pelos grupos de processos Controles de Configuração, Garantia da Qualidade
e Qualidade de Produto.
Grupo de Processo Controle de Configuração (CFG)
O grupo de processo Controle de Configuração consiste dos processos que
controlam e mantém a integridade dos produtos desenvolvidos pelos processos
de engenharia.
Processo Documentação (CFG.1)
Define o processo de desenvolvimento e manutenção dos registros das
informações produzidas por um processo.
Processo Gerenciamento da Configuração (CFG.2)
273
Define o processo de estabelecimento e manutenção da integridade de todos
os produtos do trabalho dos processos ou projeto e da sua disponibilização as
partes envolvidas.
Processo Gerenciamento de Problema (CFG.3)
Define o processo de garantia de que todos os problemas descobertos são
identificados, analisados, gerenciados e controlados para resolução.
Processo Gerenciamento de Solicitações de Mudanças (CFG.4)
Define o processo de garantia de que as mudanças solicitadas são
gerenciadas, rastreadas e controladas.
Grupo de Processo Garantia da Qualidade (QUA)
O grupo de processo Garantia da Qualidade consiste dos processos que
provêem a garantia de que todos os produtos/ ou processos do trabalho estão
em conformidade com planos e previsões pré-definidos.
Processo Garantia da Qualidade (QUA.1)
Define o processo de garantia de que e os processos os produtos do trabalho
estejam em conformidade com planos e previsões pré-definidos.
Processo Verificação (QUA.2)
Define o processo de confirmação de que cada produto de software e/ou
serviço de um processo ou projeto reflete apropriadamente os requisitos
especificados.
Processo Validação (QUA.3)
274
Define o processo de confirmação de que os requisitos específicos de uso,
pretendido para um produto de software, são preenchidos.
Processo Revisão Conjunta (QUA.4)
Define o processo de manutenção de entendimento comum entre os envolvidos
(o cliente principalmente) do progresso efetuado em relação ao contrato e o
pode ser feito ajudar a garantir que os produtos satisfaçam os envolvidos.
Podem acontecer durante todo o ciclo de vida do projeto e ser voltada para
uma abordagem gerencial ou técnica.
Processo Auditoria (QUA.5)
Define o processo de determinação independente da conformidade de produtos
e processos selecionados com os requisitos, planos e contratos, como
apropriado.
Grupo de Processo Qualidade de Produto (PRO)
Define o grupo de processo de garantia de que os produtos tenham boa
qualidade.
Processo Usabilidade (PRO.1)
Define o processo de garantia das considerações de interesse e necessidades
dos envolvidos de modo à otimização do suporte e treinamento, aumentando
produtividade e qualidade do trabalho, melhorando as condições de trabalho
humano e reduzindo a chance de rejeição do sistema por parte do usuário.
Processo Avaliação de Produto (PRO.2)
275
Define o processo de garantia, através de exame e medição sistemática, de
que o produto está conforme o especificado e satisfaz as necessidades do
usuário do produto.
Categoria de Processos Organizacionais
Têm como objetivo estabelecer os objetivos do negócio na organização e
desenvolver processos, produtos e recursos relacionados e que quando
usados pelos projetos na organização auxiliam a atingir seus objetivos. São
representados pelos grupos de processo Gerenciamentos, Melhoria, Recursos
& Infra-estrutura e Reuso.
Grupo de Processo Gerenciamento (MAN)
Define o grupo de processo que contém práticas de natureza genérica que
podem ser usadas por qualquer outra gerência de qualquer tipo de projeto ou
processo dentro de um ciclo de vida de software
Processo Alinhamento Organizacional (MAN.1)
Define o processo de capacitação dos processos de software de modo a
organização prover seus produtos ou serviços de software consistentes com
seus objetivos de negócio.
Processo Gerenciamento Organizacional (MAN.2)
Define o processo de estabelecimento e realização de práticas de
gerenciamento de software, durante a realização dos processos necessários
para prover os produtos e serviços de software, que sejam consistentes com os
objetivos da organização.
276
Processo Gerenciamento de Projeto (MAN.3)
Define o processo de identificação, estabelecimento, coordenação e
monitoração das atividades, tarefas e recursos necessários para um projeto
produzir um produto e/ou serviço, conforme seus requisitos e restrições.
Processo Gerenciamento da Qualidade (MAN.4)
Define o processo de monitoração da qualidade dos produtos e/ou serviços do
projeto e da garantia de que eles satisfaçam o cliente. O processo envolve o
estabelecimento de um foco (no nível de projeto e organizacional) da
monitoração da qualidade do produto e do processo para garantir o
cumprimento dos requisitos do cliente.
Processo Gerenciamento de Risco (MAN.5)
Define o processo de identificação, gerenciamento e atenuação de riscos
continuamente, no nível de projeto e organizacional.
Processo Medição (MAN.6)
Define o processo de coleta e análise de dados relativos aos produtos
desenvolvidos e processos implementados na organização e nos projetos, para
o suporte efetivo do gerenciamento dos processos e da demonstração objetiva
da qualidade dos produtos.
Grupo de Melhoria de Processo (PIM)
Define o grupo de processo de definição, desenvolvimento e melhoria dos
processos executados na unidade organizacional.
Processo Estabelecimento (PIM.1)
277
Define o processo de estabelecimento de um conjunto de processos
organizacionais para todo processo de ciclo de vida e sua aplicação para as
atividades do negócio.
Processo Avaliação (PIM.2)
Define o processo de avaliação de quão os processos padronizados na
organização contribuem para alcançar os objetivos do negócio e para auxiliar a
organização no enfoque das necessidades de melhoria contínua dos
processos.
Processo Melhoria (PIM.3)
Define o processo de melhoria contínua dos processos da organização, de
forma efetiva e eficiente, alinhando os processos às necessidades do negócio.
Grupo de Recursos & Infra-estrutura (RIN)
Define o grupo de processo de provisão dos recursos humanos adequados e
da infra-estrutura requerida por qualquer outro processo executado pela
unidade organizacional.
Processo Gerenciamento de Recursos Humanos (RIN.1)
Define o processo de fornecimento, na organização e no projeto, de indivíduos
que possuam técnicas e conhecimento para realizar seus papéis efetivamente
e que trabalhem juntos como um grupo coeso.
Processo Treinamento (RIN.2)
278
Define o processo de fornecimento, na organização e no projeto, de indivíduos
quer possuam as técnicas e o conhecimento necessários para desempenhar
seus papéis efetivamente.
Processo Gerenciamento do Conhecimento (RIN.3)
Define o processo de garantia de que o conhecimento individual, informações e
técnicas são coletados, compartilhados, reutilizados e melhorados através da
organização.
Processo Infra-estrutura (RIN.4)
Define o processo de manutenção de uma infra-estrutura estável e confiável
necessária para suportar a realização de qualquer outro processo. A infra-
estrutura pode incluir software, hardware, métodos, ferramentas, técnicas,
padrões e facilidades para o desenvolvimento, operação ou manutenção.
Grupo de Reuso (REU)
Define o grupo de processo de exploração sistemática das oportunidades de
reuso no programa de reuso da organização.
Processo Infra-estrutura (REU.1)
Define o processo de gerenciamento da vida dos bens de reuso da concepção
até seu desuso.
Processo Gerenciamento do Programa de Reuso (REU.2)
279
Define o processo de planejamento, estabelecimento, gerenciamento, controle
e monitoração do programa de reuso e da exploração sistemática das
oportunidades de reuso.
Processo Engenharia de Domínio (REU.3)
Define o processo de desenvolvimento e manutenção dos modelos do domínio,
arquitetura do domínio e bens para o domínio.
Dimensão Capacidade
O desenvolvimento da dimensão de capacidade é expressa no modelo de
avaliação de processo, Process Assessment Model (PAM) em termos de
atributos de processo, Process Atributes (PA) que são agrupadas em níveis de
capacidade. PAs são características do processo que podem ser avaliadas em
uma escala de realização, provendo uma medida para a capacidade do
processo. Elas são aplicadas em todos os processos, e cada PA descreve uma
face de toda a capacidade de gerenciamento e melhoria que todo processo
busca, no sentido de contribuir para o alcance dos objetivos do negócio da
organização.
Pode-se então definir o nível de capacidade como um conjunto de PAs que
trabalham conjuntamente para prover um maior ganho na capacidade de
execução de um processo. Cada nível estipula um ganho maior de capacidade
de execução do processo, constituindo um modo racional de melhoria da
capacidade de qualquer processo definido na 15504. São ao todo seis níveis
de capacidade descritos no modelo de referência, incorporando nove PAs.
280
Processo Incompleto - Nível 0
O processo não está implementado, ou falha ao tentar alcançar seus objetivos.
Neste nível existe uma pequena ou nenhuma evidência de qualquer realização
sistemática de um processo proposto. Não existem produtos de trabalho nem
saídas do processo facilmente identificáveis.
Processo Realizado – Nível 1
O processo em geral é atingido, embora não necessariamente de forma
planejada e controlada. Há um consenso na organização de que as ações
devem ser realizadas e quando são necessárias. Existem produtos de trabalho
para o processo e eles são utilizados para atestar o atendimento dos objetivos.
Realização do Processo (PA1.1)
É a medida que identifica se o processo alcança seus resultados,
transformando, através das entradas de seus produtos do trabalho, saídas
claramente identificadas.
Processo Gerenciado – Nível 2
O processo é agora implementado de modo gerenciado, de forma planejada,
monitorada e ajustada, e seus produtos de trabalho possuem qualidade
aceitável e são estabelecidos, controlados e mantidos.
Gerenciamento Realizado (PA2.1)
É uma medida que identifica se o processo realizado é gerenciado. Verifica se
os objetivos do processo foram bem identificados, se sua realização foi
planejada e monitorada, responsabilidades e recursos foram bem definidos,
281
alocados e usados e se a comunicação entre os envolvidos está clara e efetiva.
Os processos relacionados com esta PA são: MAN.3, MAN.5, CFG.3 e QUA.1.
Gerenciamento do Produto do Trabalho (PA2.2)
É uma medida que identifica se o processo controla quanto os produtos do
trabalho produzidos são apropriadamente gerenciados. Verifica se os requisitos
para os produtos, sua documentação e controle estão bem definidos, se estão
bem identificados, documentado e controlados e se forma revisados de acordo
com o planejado. Os processos relacionados com esta PA são: CFG.1, CFG.2,
CFG.3, QUA.1, QUA.2, QUA.4.
Processo Estabelecido – Nível 3
O processo gerenciado é agora implementado um processo definido, baseado
em padrões de processo e sua capacidade de obtenção dos resultados do
processo. As pessoas que implementam o processo usam processos
aprovados e os produtos de trabalho estão de acordo com padrões e
requisitos.
Definição do Processo (PA3.1)
É uma medida que identifica se padrões de processo são mantidos para o
suporte ao desenvolvimento de processos definidos. Verifica se padrões e suas
adequações apropriadas são definidos para a descrição dos elementos
fundamentais dos processos, a seqüência de atividades está determinada,
papéis para a execução do processo estão definidos, está definida uma infra-
estrutura, ambiente e um mecanismo de monitoração para a realização dos
processos. Os processos relacionados com esta PA são: MAN.2, PIM.1, RIN.1,
RIN.3, RIN.4, REU.1, REU.3, QUA.5.
Desenvolvimento do Processo (PA3.2)
282
É uma medida que identifica se processo padrão é efetivamente desenvolvido
como o processo definido para alcançar seus resultados. Verifica se o que foi
definido foi implementado, isto significa se os papéis, recursos e infra-estrutura
necessária para a execução do processo padrão estão efetivamente
designados, alocados e disponíveis. Os processos relacionados com esta PA
são: MAN.2, MAN.3, MAN.4, MAN.6, RIN.1, RIN.2, RIN.4, QUA.5.
Processo Previsível – Nível 4
O processo é realizado de forma consistente, dentro dos limites de controle,
para atingir os objetivos. Medidas da realização do processo são coletadas e
analisadas. Isto leva a um entendimento quantitativo da capacitação do
processo a uma habilidade de predizer a realização.
Medição do Processo (PA4.1)
É uma medida que identifica se o resultados das medições são usados para
garantir a realização do processo, de forma a alcançar seu objetivo definido e
os objetivos relevantes do negócio. Verifica se as informações relevantes ao
processo, de forma quantitativa, estão estabelecidas, e os resultados são
coletados, analisados e relatados de forma a monitorar e caracterizar o
processo. Os processos relacionados com esta PA são: MAN.1, MAN.4,
MAN.5, MAN.6, PIM.2.
Controle do Processo (PA4.2)
É uma medida que identifica se o processo é quantitativamente gerenciado
para produzir um processo estável, capacitado e previsível, dentro de limites
definidos. Verifica se o processo é controlado através de coleta, análise e
medições de produto e de processo, utilizados para corrigir, quando
necessário, a realização do processo na obtenção de alcançar produtos e
283
processo definidos. Os processos relacionados com esta PA são: MAN.1,
MAN.4, MAN.6, PIM.2, RIN.4.
Processo Otimizado – Nível 5
O processo realizado de forma otimizada para atender as necessidades atuais
e futuras do negócio. O processo atinge seu objetivo de negócio e consegue
ser repetido. São estabelecidos objetivos quantitativos de eficácia e eficiência
para o processo, segundo os objetivos da organização. Há o acompanhamento
constante do processo, obtendo retorno quantitativo e melhorias são propostas
através da análise destes resultados.
Inovação do Processo (PA5.1)
É uma medida que identifica se mudanças no processo são identificadas para
análise causas comuns na variação do desempenho e para investigações de
novas abordagens para a definição e desenvolvimento de processos. Verifica
se melhorias para o processo são definidas para se alcançar os objetivos de
negócio da organização e se dados apropriados são analisados para identificar
causas de variações e oportunidades para mudanças no processo. Os
processos relacionados com esta PA são: MAN.1, MAN.6, PIM.2, PIM.3, RIN.3.
Otimização do Processo (PA5.2)
É uma medida que identifica se o processo é medido com a intenção de
mudanças na definição, no gerenciamento e no desempenho do resultado do
processo, resultando em um impacto efetivo nos objetivos de melhoria do
processo. A implementação é gerenciada em todos os níveis de gerenciamento
e as mudanças são avaliadas contra os requisitos de produto e os objetivos do
processo. Os processos relacionados com esta PA são: MAN.1, PIM.3, REU.1,
REU.3.
285
APÊNDICE B
TABELA DE PRODUTOS x PROCESSOS SUPORTE
A Tabela B apresenta, segundo a visão deste estudo, uma classificação dos
produtos utilizados nos processos do grupo da Garantia da Qualidade. Os
produtos aparecem como entrada (e) e/ou saída (s) dos processos e são
relacionados às categorias adaptadas do padrão 15504 (ISO/IEC15504-5,
1998).
TABELA B.1 - Produtos da categoria Organizacional relacionados aos
processos da Qualidade. PROCESSOS do GRUPO GARANTIA DA QUALIDADE CATEGORIA - PRODUTO DE TRABALHO QUA ORGANIZA-CIONAL
1 2 3 4 5
1.1 Política da Qualidade e 1.1 Política de Verificação e 1.1 Política de Validação e 1.1 Objetivos da Qualidade e 1.1 Política de Auditoria e 1.2 Mecanismos de Comunicação e 1.2 Procedimento de trabalho/prática e/s e 1.2 Descrição do Processo e/s e e e e 1.2 Metodologia de Desenvolvimento de SW e e e 1.3 Padrão de Código e 1.3 Padrão de Interface e 1.3 Modelo de Ciclo de Vida e e 1.3 Padrões de Projeto e/s e e e 1.4 Oportunidade de Melhoria s 1.4 e 2.1 Estratégia/Plano Aceitação de Teste e e 1.4 e 2.1 Estratégia de Integração de Teste/ Plano e 1.4 e 2.1 Estratégia/Plano da Qualidade e/s e e e e
(continua)
286
(Tabela B.1 – conclusão)
1.4 e 2.1 Estratégia/Plano de Teste de Regressão e 1.4 e 2.1 Estratégia/Plano de Revisão e e e e/s 1.4 e 2.1 Estratégia/Plano de Gerenciamento de Risco e 1.4 e 2.1 Estratégia/Plano de Teste de Software e 1.4 e 2.1 Estratégia/Plano de Treinamento e 1.4 e 2.1 Estratégia/Plano de Teste Unitário e
FONTE adaptada: (ISO/IEC15504-5, 1998).
TABELA B.2 - Produtos da categoria Projeto relacionados aos processos da
Qualidade. PROCESSOS do GRUPO GARANTIA DA QUALIDADE CATEGORIA - PRODUTO DE TRABALHO QUA PROJETO
1 2 3 4 5
2.1 Plano da Garantia da Qualidade e e e e e 2.1 Estratégia/Plano de Validação s 2.1 Estratégia/Plano de Teste e 2.1 Plano de Projeto e e 2.1 Plano de Verificação s 2.1 Plano de Auditoria e/s2.1 Teste da especificação de requisitos e 2.2 Requisitos de Manutenção 2.1 Estrutura de Decomposição do Trabalho e e 2.2 Especificação de Requisitos e e e e 2.3 Caso de Teste e/s 2.3 Script de Teste e/s 2.4 Lista de Construção (Build list) e e 2.5 Documentação do Cliente e/s e 2.5 Instruções de Entrega e 2.5 Ambiente de Desenvolvimento e e 2.5 Guia de Instalação e 2.5 Unidade de Software (código) e e e e 2.5 Sistema de Rastreamento de Produto e/s s e e 2.5 Material de Treinamento e e 2.5 Produto do Trabalho e e e e 2.5 Descrição de Produto do Trabalho e e
FONTE adaptada: (ISO/IEC15504-5, 1998).
287
TABELA B.3 - Produtos da categoria Registros relacionados aos processos da
Qualidade. PROCESSOS do GRUPO GARANTIA DA QUALIDADE CATEGORIA - PRODUTO DE TRABALHO QUA REGISTROS
1 2 3 4 5
3.1 Minuta de Reunião s s s e/s s 3.2 Registro de Aceitação s s 3.2 Avaliação/ registro de Auditoria s s s e/s3.2 Contrato (produto ou serviço) e e 3.2 Registro de Revisão de Contrato s 3.2 Ação Corretiva (logs, planos, minutas) s s s s e/s3.2 Registro de Solicitação de Cliente (interno ou
externo) e
3.2 Registro/Relatório de Problema e/s e/s e/s e 3.2 Registro/Relatório de (Status) Progresso s e e 3.2 Registro da Qualidade e/s s s 3.2 Registro da Revisão s s s e/s 3.2 Registro/Relatório de Análise de Risco e 3.2 Histórico de Registro de Subcontratados e 3.2 Resultado de Teste s e 3.2 Mapeamento/ Registro de Rastreabilidade s e/s s s 3.2 Registro de Treinamento e 3.3 Estimativas e 3.3 Medida de Campo 3.3 Medidas e 3.3 Processo de Medição e e e 3.3 Projeto de Medição e e 3.3 Critérios da Qualidade e/s e e e 3.3 Medição da Qualidade e s e/s e 3.3 Medição de nível de Serviço e 3.4 Resultado de Análise s s s s s 3.4 Dados de Benchmarking 3.4 Dados de Satisfação do Cliente s e 3.4 Dados de Realização do Processo e 3.4 Resultado Análise de Problema e
FONTE adaptada: (ISO/IEC15504-5, 1998).
288
289
APÊNDICE C
TELAS DO PROTÓTIPO QUALITY MANAGEMENT - QM
As telas deste apêndice foram extraídas do módulo Garantia de Produto do
protótipo “Quality Management” – QM. O protótipo visa representar a seqüência
das atividades que cada papel deve desempenhar neste processo e seus
produtos relacionados. A Figura C.1 ilustra a tela de acesso ao protótipo
utilizando o serviço de segurança.
FIGURA C.1 - Tela de acesso ao protótipo QM.
290
A Figura C.2 ilustra a tela de trabalho do usuário, com as notícias (janela News)
remetidas ao mesmo. Pode-se também observar o recurso que possibilita que
qualquer usuário possa participar das atividades da Qualidade (janela
Cooperative Tools). A barra de opções (barra á direita mais acima) Support
permite o acesso dos membros do Time da Qualidade, para as atividades de
garantia, planejamento e controle da qualidade.
FIGURA C.2 - Tela de trabalho do usuário.
291
A Figura C.3 ilustra a tela referente as opções Support que, entre outras
serviços dá acesso dos membros do Time da Qualidade, para as atividades de
garantia, planejamento e controle da qualidade
FIGURA C.3 – Tela de acesso às atividades do Time da Qualidade.
292
A Figura C.4 ilustra a tela inicial da atividade Quality Planning do protótipo QM.
No protótipo foram implementados somente alguns dos serviços de
planejamento, ilustrando algumas das possibilidades de utilização.
FIGURA C.4 – Tela inicial da atividade Quality Planning.
293
A Figura C.5 ilustra a tela referente a lista de projetos instanciados para a
atividade de planejamento da qualidade 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.5 - Tela referente à lista de projetos instanciados.
294
A Figura C.6 ilustra a tela referente as opções de planejamento de projeto,
mais especificamente mostra a opção da tela de definição dos papéis dos
envolvidos com a qualidade. Este menu de abas permite também optar por
outras definições do planejamento da qualidade, tais como, a.atividade de
documentação de projeto, a estratégia de treinamento, a participação de
subcontratados, a escolha dos produtos que participarão das atividades de
revisão e auditoria.
FIGURA C.6 - Tela referente à definição dos papéis da qualidade no projeto.
295
A Figura C.7 ilustra a tela referente a opção de padrões de planejamento de
projeto, mais especificamente mostra a tela de definição dos padrões a serem
adotados em projetos, onde se incluem padrões de documentação, de
diagramas, de interfaces com o usuário, de código, de módulos de teste e de
templates de projeto
FIGURA C.7 - Tela referente à opção de padrões de projeto.
296
A Figura C.8 ilustra a tela referente a opção de definição dos produtos (em
categorias) com relação as fases em que serão realizadas as verificações e
validações do projeto. As fases forma definidas como de requisitos, de projeto,
de desenvolvimento, de teste e de entrega. Poderia também ser em todo
encaminhamento de produto ao Ambiente.
FIGURA C.8 - Tela referente à opção de política de Verificação e Validação.
297
A Figura C.9 ilustra a tela inicial da atividade de Garantia de Produto, por parte
do usuário (ou responsável pelo produto a ser encaminhado ao Ambiente), que
deve entrar na opção Quality Management da janela Cooperative Tools como
apresentado na tela de trabalho do usuário, Figura C.2. Para encaminhar
qualquer produto para o controle por parte do Ambiente, o encaminhador deve
ativar o ícone “Encaminhar Produto” encontrado no canto superior direito desta
tela.
FIGURA C.9 - Tela inicial da atividade de Garantia de Produto.
298
A Figura C.10 ilustra a tela de acompanhamento dos produtos encaminhados
ao Ambiente. Como o Responsável pelo Produto encaminhou nenhum produto,
o número de registros ainda é zero. Dependendo dos privilégios deste usuário
no Ambiente, a lista produtos encaminhados pode ser de todos os produtos
encaminhados (incluindo a de outros envolvidos). Possui alguns campos, como
nome e status do produto para um melhor acompanhamento do processo.
FIGURA C.10 - Tela de acompanhamento dos produtos encaminhados.
299
A Figura C.11 ilustra a primeira tela do Formulário de Encaminhamento de
Produto, que contém as meta informações relativas ao produto encaminhado.
Os dados a serem registrados são localização, nome, responsável, gerente,
descrição, identificação, categoria do produto e data do encaminhamento. Ao
final da tela, o usuário tem a opção de “Encaminhar” ou “Cancelar” o
encaminhamento.
FIGURA C.11 - Tela de encaminhamento de produtos.
300
A Figura C.12 ilustra a tela de acompanhamento dos produtos encaminhados
após o encaminhamento do Responsável pelo Produto. O campo status mostra
a situação do produto após esta primeira atividade do processo.
FIGURA C.12 - Tela de acompanhamento dos produtos mudando o status para
“Encaminhado a Qualidade”.
301
A Figura C.13 ilustra a tela inicial das atividades da Garantia da Qualidade, que
neste exemplo inclui somente a Avaliação de Produto. Sua participação neste
processo consiste de escolher o revisor e acrescentar mais algumas
informações que serão apresentadas após ativar o ícone “Avaliar Produto”
encontrado no canto superior direito desta tela.
FIGURA C.13 - Tela inicial da atividade de Garantia da Qualidade.
302
A Figura C.14 ilustra a tela de avaliação de produto, que contém as meta
informações relativas às atividades do Gerente da Qualidade para este
processo. Os dados a serem registrados são a escolha do revisor responsável,
a introdução de alguma observação (se necessário), tipo de avaliação
(verificação ou validação) e a inclusão de algum documento para auxiliar a
avaliação (ação opcional do gerente). Ao final da tela, o usuário tem a opção de
“Revisar” ou “Cancelar” o encaminhamento.
FIGURA C.14 - Tela de avaliação de produto (visão Gerente da Qualidade).
303
A Figura C.15 ilustra a tela de acompanhamento dos produtos encaminhados
após o encaminhamento do Gerente da Qualidade ao Revisor. O campo status
mostra a situação do produto após esta atividade do processo.
FIGURA C15 - Tela de acompanhamento dos produtos mudando o status para
“Encaminhado ao Revisor”.
304
A Figura C.16 ilustra a tela inicial das atividades do Controle da Qualidade, que
neste exemplo inclui somente a atividade de Revisar Produto. Sua participação
neste processo consiste de realizar a revisão e acrescentar as informações
pertinentes a verificação ou validação do produto (como dar o parecer de
conformidade) Estas informações serão apresentadas após ativar o ícone
“Revisar Produto” encontrado no canto superior direito desta tela.
FIGURA C.16 - Tela inicial da atividade de Controle da Qualidade.
305
A Figura C.17 ilustra a tela de avaliação de produto, que contém as meta
informações relativas às atividades do Revisor da Qualidade para este
processo. O checklist de avaliação (verificação de código fonte, neste exemplo)
é preenchido pelo Revisor que também dá seu parecer, faz recomendações e
aponta problemas (quando houver). Ao final da tela, o usuário tem a opção de
“Salvar” (em caso de uma revisão não ser completada em apenas uma sessão
de login”) ou “Encaminhar” o formulário de encaminhamento.
FIGURA C.17 - Tela de avaliação de produto (visão do Revisor da Qualidade).
306
A Figura C.18 ilustra a tela de acompanhamento dos produtos encaminhados
após o Revisor da Qualidade dar seu parecer. O campo status mostra a
situação do produto após esta atividade do processo.
FIGURA C18 - Tela de acompanhamento dos produtos mudando o status para
“Revisado”.
307
A Figura C.19 ilustra a tela de acompanhamento dos produtos encaminhados
com o campo status mostrando algumas das outras possíveis situações do
produto após sua verificação ou validação.
FIGURA C19 - Tela de acompanhamento dos produtos mudando o status.
308
Encaminhamento de Produto
Encaminhar produto Responsável pelo produto: Projeto: t Gerente:
Nilson Descrição do produto: Digite a descrição do produto.
Identificação do produto:
Categoria do produto:
2.1 Plan Data:
Cancelar
FIGURA C.20 – Formulário de Encaminhamento de Produto.
309
Garantia de Produto - Avaliação
Responsável pelo produto: Projeto: Gerente: Código do produto: Versão do produto: Nome do arquivo:. Descrição do produto: Categoria do produto: Data: Status: Revisor: Escolha um revisor.
Bruno Observações: Digite as observações.
Documentos para auxiliar na avaliação
check1padrãocheck2
check
Tipo de Avaliação: Escolha o tipo de avaliação.
Verif icação VER
FIGURA C.21 – Formulário de Avaliação de Produto.
