UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE ENGENHARIA MECÂNICA
Processo de Avaliação de Produto Final de
Software para Aquisição
Autora: Marbilia Passagnolo Sergio
UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE ENGENHARIA MECÂNICA
COMISSÃO DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Processo de Avaliação de Produto Final de
Software para Aquisição
Autora: Marbilia Passagnolo Sergio
Orientador: Prof. Dr. Marco Antonio Silveira
Curso: Engenharia Mecânica – Mestrado Profissional Área de concentração: Gestão da Qualidade Total
T Trraabbaallhhoo FFiinnaall ddee MMeessttrraaddoo PPrrooffiissssiioonnaall aapprreesseennttaaddoo àà CCoommiissssããoo ddee PPóóss--GGrraadduuaaççããoo ddaa F FaaccuullddaaddeeddeeEEnnggeennhhaarriiaaMMeeccâânniiccaaddaaUUnniivveerrssiiddaaddeeEEssttaadduuaallddeeCCaammppiinnaass,,ccoommoorreeqquuiissiittooppaarraa a aoobbtteennççããooddoottííttuullooddeeMMeessttrreePPrrooffiissssiioonnaalleemmGGeessttããooddaaQQuuaalliiddaaddeeTToottaall.. Campinas, 2004 S.P. - Brasil
FICHA CATALOGRÁFICA ELABORADA PELA
BIBLIOTECA DA ÁREA DE ENGENHARIA - BAE - UNICAMP
Se66p
Sergio, Marbilia Passagnolo
Processo de avaliação de produto final de software para aquisição / Marbilia Passagnolo Sergio.--Campinas, SP: [s.n.], 2004.
Orientador: Marco Antonio Silveira.
Dissertação (mestrado profissional) - Universidade Estadual de Campinas, Faculdade de Engenharia Mecânica.
1. Software - Avaliação. 2. Software - Avaliação. 3. Engenharia de software. 4. Qualidade dos produtos. 5. Gestão da qualidade total. I. Silveira, Marco Antonio. II. Universidade Estadual de Campinas. Faculdade de Engenharia Mecânica. III. Título.
UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE ENGENHARIA MECÂNICA
COMISSÃO DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
T
TrraabbaallhhooFFiinnaallddeeMMeessttrraaddooPPrrooffiissssiioonnaall
Processo de Avaliação de Produto Final de
Software para Aquisição
Autora: Marbilia Passagnolo Sérgio
Orientador: Prof. Dr. Marco Antonio Silveira
_
_________________________________________________________________________________________________________________________________________________________
Prof. Dr. Marco Antonio Silveira
Centro de Pesquisas Renato Archer - CenPRA/MCT
_______________________________________
Prof. Dr. Ettore Bresciani Filho
Faculdade de Engenharia Mecânica - UNICAMP
_______________________________________
Prof. Dr. Adalberto Nobiato Crespo
Centro de Pesquisas Renato Archer - CenPRA/MCT
Dedicatória
Para Raquel, Raphael e Gabriella, meus amados filhos; Amauri, meu esposo; Dulce, minha mãe, e Abel, meu pai (in memoriam), por terem, de alguma forma, compartilhado comigo esta jornada. Suas demonstrações de carinho, apoio e solidariedade deram-me, com a certeza de estar em seus corações, a força necessária para vencer mais este desafio.
Agradecimentos
A lista de companheiros que, de alguma forma, ajudaram-me nesta caminhada é sem dúvida bastante extensa, sendo impossível citar nominalmente a todos. De forma especial, quero agradecer:
Ao Departamento de Estatística do IMECC – Instituto de Matemática, Estatística e Ciência da Computação da UNICAMP, na pessoa do Prof. Ademir José Petenate, coordenador daquela instituição, que manteve abertas suas portas para que os alunos pudessem concluir seus trabalhos de dissertação.
Aos amigos e ex-colegas de trabalho da CPFL, na pessoa da Sra. Yone de Almeida Coco, ex-gerente do Departamento de Informática, que me permitiu freqüentar as aulas de qualificação para o mestrado.
Aos amigos e companheiros de trabalho do Centro de Pesquisas Renato Archer do Ministério da Ciência e Tecnologia - CenPRA - do Governo Federal, que me cederam parte de seu precioso tempo, dispondo-se a compartilhar seus conhecimentos técnicos e realizar extensas discussões sobre o tema. Naquele âmbito, foram capitais a cooperação de Maria Teresa Villalobos Aguayo, colega de trabalho e parceira no estudo das normas e na pesquisa estatística, e de Regina Thienne Colombo, gerente da Divisão de Qualificação de Software – DQS cujo apoio absoluto na cessão de espaço e na revisão de conceitos possibilitaram a conclusão deste trabalho.
Finalmente, devo ao Professor Marco Antonio Silveira, meu Orientador, a guiança segura e competente neste desafio, as idéias e sugestões valiosas, a cordialidade, o carinho e a cumplicidade demonstrados nesse período de trabalho conjunto, a que a conclusão deste mestrado vem gratamente brindar. A ele, meus mais sinceros agradecimentos, sobretudo por haver acreditado em mim antes que eu mesma o tivesse feito.
“Se não houver processo, ou seja, havendo caos, qualquer coisa pode acontecer, para melhor ou para pior (...) Objetivos numéricos não dão resultado (...) Apenas o método é importante.”
W. Edwards Deming, A Nova Economia, pp. 36 e 40.
Resumo
SERGIO, Marbilia Passagnolo, Processo de Avaliação de Produto Final de Software para
Aquisição, Campinas: Faculdade de Engenharia Mecânica, Universidade Estadual de
Campinas, 2004. 170 pp.Trabalho final de Mestrado Profissional.
Dada a importância do uso de computadores nos dias de hoje, a qualidade de um produto de software é um fator crítico. O presente trabalho objetiva analisar um método de avaliação da qualidade de um produto de software final para aquisição. Para tanto, após apresentar os conceitos básicos da área de qualidade de software e identificar aqueles de interesse para a realização de uma avaliação, é apresentado um estudo de caso, no qual o método de avaliação criado pelo CenPRA foi aplicado, como uma das atividades do edital de pré-qualificação de fornecedores do Programa Nacional de Apoio à Gestão Administrativa e Fiscal dos Municípios Brasileiros, do Ministério da Fazenda.
Busca-se demonstrar, através dos resultados obtidos, como o método utilizado, em uma avaliação independente, pôde atender a necessidade de verificar a conformidade de um produto final de software em relação à especificação de requisitos definidos pelo adquirente. É demonstrada a aderência do processo utilizado para o desenvolvimento do método e execução de avaliação com as normas internacionais.
Explica-se a construção do método dando ênfase às características e subcaracterísticas de qualidade de software aplicadas a cada componente do produto e na especificação da avaliação adotada.
Palavras-chave:
Produto de software; aquisição, avaliação; características de qualidade de software; requisitos.
Abstract
SERGIO, Marbilia Passagnolo, Evaluation Process of Final Software Product for Acquisition,
Campinas: College of Mechanical Engineering, Campinas State University, 2004.170 pgs.
Professional Master´s Degree Final Assigment.
Taking into account the importance of the use of computers nowadays, the quality of a software product is a critical factor. The aim of this work is to analize an evaluation method of final software product for acquisition. For that purpose, after expounding the basic concepts in the software quality area and identifying those points of interest for the accomplishment of an evaluation, a case study is presented, in which the evaluation method developed by the Renato Archer Research Center - CenPRA was applied as one activity of the pre-qualification Edict for suppliers of the National Program of Support to Administrative and Fiscal Management of Brazilian Municipal Districts – PNAFM, of the Treasury Department.
The results which were obtained showed how satisfactority the method used in an independent evaluation could meet the need to check on the conformity of a final software product with the specification of the requirements defined by an acquirer. It is demonstrated that the process used for the development of the method and for the accomplishment of the evaluation conforms to international norms.
The construction of the method is explained by laying emphasis on software quality characteristics and subcharacteristics applied to each component of the product and by specifying the adopted evaluation.
Key Words:
Índice
Lista de Tabelas ... xiii
Lista de Figuras ...xiv
Nomenclaturas ...xvi
Capítulo 1: Introdução ...1
1.1 Entidades e iniciativas em qualidade de software ...3
1.2 Mercado de software no Brasil ...4
1.3 Aquisição nas instituições públicas ...6
1.4 Maturidade das empresas de software ...7
1.4.1 Indicadores de maturidade das empresas de software nacional ...10
1.5 Motivação do trabalho ...11
1.5.1 Problema da pesquisa ...12
1.5.2 Objetivo da pesquisa...12
1.5.3 Restrições...13
1.6 Método de pesquisa ...14
1.6.1 O estudo do caso “Pré-qualificação do PNAFM” ...15
1.6.2 Planejamento do estudo do caso ...16
1.7 Organização da dissertação ...18
Capítulo 2: Conceitos básicos de qualidade e software...19
2.1 Aspectos da qualidade para software...19
2.2 Qualidade de processo de software ...23
2.2.1 NBR 12207 - processo do ciclo de vida do software ...24
2.2.2 Família NBR ISO 9000 ...27
2.2.3 CMM (SW-CMM – desenvolvimento e SA-CMM - aquisição) ...27
2.2.4 CMMI (por estágio e contínuo) ...28
2.2.5 ISO/IEC 15504 ...30
2.3 Qualidade de produto de software ...32
2.3.1 Modelo de qualidade - ISO/IEC 9126 ...33
2.3.2 Avaliação de produto de software - Normas NBR ISO/IEC 14598 ...38
2.3.2.1 Estabelecimento dos requisitos da avaliação...41
2.3.2.2 Especificação da avaliação ...42
2.3.2.3 Projeto da avaliação...45
2.3.2.4 Execução da avaliação...46
2.3.3 Pacotes de software ou produtos de prateleira - NBR ISO/IEC 12119 ...47
2.3.3.1 Requisitos de qualidade ...48
2.3.3.2 Instruções para Teste ...49
2.3.4 Requisitos de usabilidade da interface - ISO 9241...50
2.3.4.1 Princípios de diálogo ...50
2.3.4.2 Orientações sobre a usabilidade ...51
2.3.4.3 Organização da informação ...52
2.3.5 ERGOLIST - Critérios ergonômicos de interfaces homem-computador ...52
2.3.6 Requisitos de documentação de usuário - ANSI/IEEE 1063 ...53
Capítulo 3: Processo de avaliação de produto final de software para aquisição ...55
3.1 ETAPA 1- Estabelecer requisitos de avaliação ...61
3.1.1 Estabelecer o propósito da avaliação...62
3.1.2 Identificar tipos de produtos a serem avaliados...62
3.1.3 Especificar o modelo de qualidade ...66
3.2 ETAPA 2 - Especificar a avaliação ...70
3.2.1 Selecionar métricas...71
3.2.2 Estabelecer níveis de pontuação para as métricas ...76
3.2.3 Estabelecer critérios para julgamento...80
3.3 ETAPA 3 - Projetar a avaliação ...81
3.3.1 Construir o plano de avaliação ...81
3.3.2 Conteúdo do plano de avaliação ...83
3.3.3 Aprovar o plano e Relato...84
3.4 ETAPA 4 - Executar a avaliação ...85
3.4.1 Fase 1 - Pré-avaliação...85
3.4.2 Fase 2 - Avaliação por requisito ...86
3.4.3 Fase 3 - Reavaliação ...87
Capítulo 4: Estudo do caso - Avaliação de produto final de software para aquisição pelo Projeto Simplificado do PNAFM ...91
4.1 Programa PNAFM ...91
4.1.1 Propósito do programa...91
4.1.2 Processo de aquisição do Projeto simplificado do PNAFM...93
4.1.3 Produto de Software do Kit-Solução ...94
4.2 Processo de avaliação do PNAFM ...95
4.2.1 Propósito da avaliação no processo de aquisição ...95
4.2.2 Interseção do processo de avaliação com o de aquisição ...96
4.2.3 Atores, papéis e responsabilidades ...97
4.2.4 Cronograma do processo de avaliação ...98
4.2.5 Estratégia de execução da avaliação...100
4.3 ETAPA 1 - Estabelecer requisitos de avaliação ...101
4.3.1 Resultado da etapa 1 - Edital de pré-qualificação ...103
4.4 ETAPA 2 - Especificar a avaliação ...104
4.4.1 Resultado da etapa 2 - Fase 1 - Pré-avaliação ...104
4.4.2 Resultado da etapa 2 - Fase 2 - Avaliação por requisito ...107
4.4.3 Resultado da etapa 2 - Fase 3 – Reavaliação...112
4.5 ETAPA 3 - Projetar a avaliação ...113
4.5.1 Treinamento...114
4.5.2 Resultado da etapa 3 - plano de avaliação ...115
4.5.3 Cronograma ...117
4.6 ETAPA 4 - Execução da avaliação...118
4.6.1 Registro da avaliação...118
4.6.2 Resultados da etapa 4 - as avaliações ...118
Capítulo 5: Resultados das avaliações e análise...121
5.2.2 Requisitos sem erro grave por sistema ...124
5.2.3 Requisitos com erro grave por sistema...125
5.3 Visão do atendimento pelos componentes...126
5.3.1 Requisitos Atendidos por componente ...126
5.3.2 Requisitos sem erro grave por componente...127
5.3.3 Requisitos com erro grave por componente ...128
5.4 Visão do atendimento por tipo de requisito...129
5.4.1 Requisitos obrigatórios ...129
5.4.2 Requisitos desejáveis ...130
5.4.3 Requisitos recomendados ...131
5.5 Análise sobre o trabalho realizado...132
5.5.1 Contribuição para os fornecedores ...133
5.5.2 projeto Simplificado do PNAFM – sugestão para os próximos passos...134
Capítulo 6: Conclusão e propostas de novos trabalhos ...135
6.1 Conclusão sobre o trabalho...135
6.2 Trabalhos futuros ...137
Referências ...139
ANEXO I – Descrição das subcaracterísticas de qualidade da NBR 9126-1...147
ANEXO II – Exemplos de falhas primárias dos CSAs não qualificados ...149
ANEXO III – Falhas observadas em requisitos não atendidos pela maioria dos CSAs...151
APÊNDICE A – Regulamento Operativo - Setembro/1999 ...157
APÊNDICE B – Fluxo de procedimentos do projeto simplificado do PNAFM ...162
APÊNDICE C – Edital de Pré-qualificação do PNAFM – descrição ...165
1.0 PROGRAMA NACIONAL DE APOIO À GESTÃO ADMINISTRATIVA E FISCAL DOS MUNICÍPIOS BRASILEIROS – PNAFM ...166
Lista de Tabelas
Tabela 1.1 - Resumo do planejamento do estudo do caso PNAFM ... 17
Tabela 2.1 - Processo do ciclo de vida ... 25
Tabela 2.2 - Níveis de Maturidade do Modelo SW-CMM... 28
Tabela 2.3 - Áreas de Processo de CMMI... 29
Tabela 2.4 - Comparação dos Níveis SA-CMM versus CMMI ... 30
Tabela 2.5 - Níveis de capacidade da ISO 15504... 31
Tabela 3.1 - Valores mapeados às respostas possíveis ... 78
Tabela 3.2 - Tipos de itens... 78
Tabela 3.3 - Valores mapeados às respostas possíveis ... 79
Tabela 3.4 - Tipos de Itens ... 79
Tabela 4.1 - Exemplo de instrução da pré-avaliação... 105
Tabela 4.2 - Quantidade de instruções da Pré-avaliação por sistema aplicativo ... 106
Tabela 4.3 - Total de Instruções da Pré-avaliação para um CSA ... 107
Tabela 4.4 - Equipe de desenvolvimento da Etapa 2 e da Etapa 3 ... 108
Tabela 4.5 - Quantidade de Requisitos, Atributos e Itens do CSA ... 109
Tabela 4.6 - Quantidade de Requisitos, Atributos e Itens por sistema - parte 1... 110
Tabela 4.7 - Quantidade de Requisitos, Atributos e Itens por sistema - parte 2... 111
Tabela 4.8 - Capacitação para realizar a avaliação até Abril/2004 ... 115
Lista de Figuras
Figura 1.1 - Cenário das organizações imaturas... 7
Figura 1.2 - Cenário das organizações maduras ... 9
Figura 1.3 - Percentagem de empresas que conhecem e usam processos de software... 10
Figura 2.1 - Qualidade no Ciclo de Vida... 32
Figura 2.2 - Modelo de qualidade externa e interna ... 34
Figura 2.3 - Modelo de qualidade para qualidade em uso... 35
Figura 2.4 - Qualidade no ciclo de vida do software... 37
Figura 2.5 - Processo de Avaliação segundo NBR 14598-1 ... 39
Figura 2.6 - Processo de Avaliação segundo NBR 14598-4 ... 39
Figura 2.7 - Processo de avaliação segundo NBR 14598-5 ... 40
Figura 2.8 - Características, subcaracterísticas e atributos de qualidade de software. ... 42
Figura 2.9 - Níveis de pontuação para as métricas ... 44
Figura 2.10 - Estrutura da NBR ISO/IEC 12119... 48
Figura 3.1 - Estratégia de execução da avaliação de produto final de software para aquisição.... 58
Figura 3.2 - Etapas e atividades do processo de avaliação, incluindo as fases da estratégia ... 60
Figura 3.3 - Visão do Requerente sobre as etapas do processo de avaliação ... 60
Figura 3.4 - O modelo de qualidade para a Fase 1 - Pré-avaliação ... 68
Figura 3.5 - O modelo de qualidade para a Fase 2 - Avaliação por Requisito ... 69
Figura 3.6 - Níveis de pontuação para as métricas ... 76
Figura 4.1 - Visão do processo de aquisição do PNAFM, segundo a NBR 12207 ... 93
Figura 4.2 - Cronograma do processo de avaliação para o PNAFM simplificado ... 99
Figura 4.3 - Sistemas do CSA do Projeto Simplificado do PNAFM ... 103
Figura 4.4 - Exemplo de Requisitos de Aquisição ... 108
Figura 4.5 - Exemplo de atributos e itens de avaliação ... 109
Figura 4.6 - Exemplo do roteiro de esclarecimento da reavaliação... 112
Figura 4.7 - Cronograma das Atividades da Verificação de Conformidade ... 117
Figura 5.2 - Visão dos requisitos atendidos pelos sistemas... 123
Figura 5.3 - Visão dos requisitos com erro não grave nos sistemas ... 124
Figura 5.4 - Visão dos requisitos com erro grave nos sistemas... 125
Figura 5.5 - Visão dos requisitos atendidos pelos sistemas... 126
Figura 5.6 - Visão dos requisitos com erro não grave nos componentes ... 127
Figura 5.7 - Visão dos requisitos com erro grave nos sistemas... 128
Figura 5.8 - Visão do atendimento aos requisitos obrigatórios ... 129
Figura 5.9 - Visão do atendimento aos requisitos desejáveis ... 130
Nomenclaturas
Siglas
AAQPS Ambiente de Avaliação de Qualidade de Produto de Software;
ABNT Associação Brasileira de Normas Técnicas;
ANSI American National Standards Institute;
ASEC Applied Software Engineering Centre;
ASSESPRO Associação das Empresas Brasileiras de Tecnologia da Informação, Software e
Internet;
BID Banco Interamericano para o Desenvolvimento;
CenPRA Centro de Pesquisas Renato Archer;
CIO Chef Information Office;
CMM Capability Maturity Model;
CMMI Capability Maturity Model Integration;
COTS Commercial Off The Shelf;
CSA Conjunto de Sistemas Aplicativos;
DoD Department of Defense of USA;
ERP Enterprise Resource Planning;
ESI European Software Institute;
IEC International Electrotechnical Commission;
IEEE Institute of Electrical and Electronics Engineers;
IPD-CMM Integration Product Development - CMM;
ISO International Organization for Standardization;
MCT Ministério da Ciência e Tecnologia;
MEDEPROS® MÉtodo de Avaliação de qualidade DE PROdutos de Software;
MIT Massachussets Institute of Technology;
NDI Non Developmental Item;
P&D Pesquisa & Desenvolvimento;
PBQP/SW Programa Brasileiro de Qualidade e Produtividade em Software;
PNAFM Programa Nacional de Apoio à Gestão Administrativa e Fiscal dos Municípios
Brasileiros;
PNUD Programa das Nações Unidas para o Desenvolvimento;
Quick-BMA Software para tratamento dos resultados das avaliação do ambiente AAQPS;
ROP Regulamento OPerativo do PNAFM;
SA-CMM Software Acquisition - Capability Maturity Model;
SCOPE project Software CertificatiOn Programme in Europe project;
SE-CMM System Engineering - Capability Maturity Model;
SEI Software Engineering Institute;
SEPIN Secretaria da Política de Informática do MCT;
SPICE project Software Process Improvement and Capability dEtermination project;
SOFTEX Sociedade Software Exportação;
SW-CMM Software - Capability Maturity Model;
TI Tecnologia da Informação;
Capítulo 1: Introdução
Nos anos 90, o grande volume de serviços terceirizados no setor de informática afetou especialmente algumas áreas da gerência de TI, tais como: manutenção de equipamentos, gestão de rede e engenharia de software, esta última voltada para o desenvolvimento e a manutenção de software. A modernização administrativa das organizações levou ao enxugamento de sua estrutura interna, mantendo somente as atividades diretamente relacionadas ao negócio.
Para as empresas, o alto custo das áreas internas de TI e as constantes mudanças tecnológicas foram fatores decisivos na opção pela terceirização desses setores. Em geral, a disseminação das normas de gestão da qualidade, a globalização, e o conseqüente amadurecimento do mercado em relação à formação de parcerias viabilizaram novas soluções, que se apresentaram financeiramente mais vantajosas, reduzindo custos em serviços e produtos.
Disponibilizar para as empresas uma solução de TI é, nos dias de hoje, mais do que automatizar atividades repetitivas. O sistema de informação possue uma importância estratégica no suporte às tomadas de decisão. Esse pode ser percebido nas informações consistentes, estruturadas e adequadas que são disponibilizadas às diversas áreas de uma empresa.
Hoje, as empresas restringem-se a manter profissionais altamente qualificados para fornecer novas soluções de TI, com o objetivo de agregar valor aos negócios. Grandes empresas contam com um Chef Information Office - CIO para gerenciar uma equipe desses especialistas que buscam o alinhamento estratégico das organizações às novas tecnologias disponíveis.
Essas equipes multidisciplinares contam com analistas de negócios que especificam os requisitos de sistema e de software, avaliam e monitoram a entrada de novos produtos ou soluções de TI na rotina de uma empresa, e reduzem a margem de falha na aquisição de TI. Segundo Pivka (1995):
As possibilidades abertas pelo computador para a realização de serviços mostram consumidores deslumbrados, mas sem o mínimo de conhecimento necessário para
distinguir as mais elementares características da qualidade do produto. Assim, a questão da discussão da qualidade de software num mercado composto de milhares de pequenos produtores é o grande desafio.
Dentre os produtos e serviços de TI demandados por uma empresa, o software recebe um cuidado adicional. Não tanto ao se tratar da aquisição de pacote de software, como processador de texto, ou de software embarcado, que funciona em conjunto com uma máquina (SEPIN, 2002), mas da aquisição de serviços de software, especificamente sistemas aplicativos.
Associada à contratação de desenvolvimento e customização do produto, sempre existe a necessidade de conhecer o negócio e a cultura organizacional da empresa. No planejamento do processo de aquisição, devem estar inclusas as atividades de especificar, receber, implantar e aceitar o produto de software, assim como estabelecer o relacionamento com o fornecedor para obter a garantia de suporte técnico e de manutenção do produto.
A implantação de um produto de software pode representar a implementação de novos sistemas de informação numa empresa. Isso por vezes resulta em mudanças expressivas nas atividades da área beneficiada, podendo estender seus reflexos à empresa como um todo. Entretanto, também não são raros os relatos de insucesso na aquisição, quando produtos de software são abandonados antes mesmo de terem sido implantados. A dificuldade de quebrar a resistência à mudança dos funcionários envolvidos e a constatação, após a compra, de que o produto não é adequado à necessidade da empresa adquirente são dois dos vários motivos que podem explicar o malogro.
Adequar o sistema de informação da empresa ao novo produto de software pode ser uma alternativa para equacionar as falhas da aquisição, e pode representar outro problema a ser resolvido por uma empresa que compra software. Software que não atendem as necessidades ou atendem de forma inadequada e incompleta são exemplos de problemas já observados.
São muitas as soluções possíveis e originadas da tentativa de equacionar esse novo e complexo relacionamento comercial entre fornecedores e adquirentes de Tecnologia de Informação – TI. A solução a ser adotada deve considerar fatores que sinalizam a forma de condução do processo de aquisição, como: a disponibilidade do produto de software no mercado;
a complexidade do produto; o montante financeiro envolvido na aquisição; o nível de maturidade das empresas que o desenvolvem.
1.1 Entidades e iniciativas em qualidade de software
Existe um esforço científico no mundo e no Brasil, com o objetivo de estudar, compreender, desenvolver, criar normas e padrões e divulgar conhecimentos em TI. A qualidade de software vem sendo a chave para a sustentação da nova ciência - a engenharia de software.
Em várias regiões do mundo, existem centros de desenvolvimento tecnológico de TI, que acompanham o emprego dos recursos disponíveis na área de qualidade de software e repassam para organizações interessadas o estado da prática empregada e os resultados de projetos reais obtidos. Alguns exemplos das missões declaradas por esses centros são:
Software Engineering Institute (SEI), Estados Unidos: "identificar as necessidades de engenharia de software de nossas comunidades de clientes e prover produtos e serviços que permitam aos clientes: i) realizar melhorias duradouras em suas capacidades de adquirir, desenvolver e manter sistemas dependentes de software; ii) reduzir os riscos de realizar tais melhorias; e iii) educar outros grupos para atingir tais melhorias".
European Software Institute (ESI), Espanha: "dar suporte a nossos membros na indústria européia a aumentar sua competitividade ao prover e disseminar melhores práticas de software".
Applied Software Engineering Centre (ASEC), Canadá: “responder a uma necessidade
expressa pela indústria canadense e vendo como clientes-alvo companhias e agências canadenses, que se apóiam em tecnologia da informação para melhorar sua produtividade e a qualidade de seus serviços e produtos”.
No Brasil, desde 1993, têm surgido várias iniciativas nessa área, por parte do governo e também de centros de pesquisas, universidades, associações de classe e organismos normalizadores, tais como:
SOFTEX, cujo objetivo é apoiar micro e pequenas empresas de software, melhorando a qualidade nacional e aumentando a competitividade no mercado internacional.
Subcomitê de Software do Programa Brasileiro de Qualidade e Produtividade (SSQP/SW, 2002), cujo objetivo é estimular, articular, orientar e apoiar os esforços da sociedade na busca de competitividade nacional e internacional, no setor de software.
Secretaria da Política de Informática – SEPIN, do Ministério da Ciência e Tecnologia – MCT (2002), que conduz periodicamente pesquisas sobre qualidade e produtividade entre as empresas de software nacionais.
Subcomitê de Software, da Associação Brasileira de Normas Técnicas – ABNT, que elabora normas brasileiras relacionadas à qualidade de software.
Centro de Pesquisas Renato Archer – CenPRA, centro de pesquisa do Ministério da Ciência e Tecnologia, que desenvolve pesquisas aplicando conhecimentos de qualidade de software e divulga para a comunidade cientifica, acadêmica e empresarial os resultados de suas pesquisas, dando suporte ao desenvolvimento nacional.
Na busca por pesquisa de iniciativas nacionais e internacionais, no sentido de identificar as normas da área de engenharia de software e TI, destacaram-se, como fonte de informação para o desenvolvimento deste trabalho, o grupo de trabalho de engenharia de software Organização Internacional de Normalização –ISO (ISO/IEC, 2002) e o Subcomitê de Software da ABNT (ABNT/SW, 2003).
1.2 Mercado de software no Brasil
O mercado de software pode ser visto sob dois ângulos: o das empresas compradoras dos produtos de software e o das empresas desenvolvedoras ou fornecedoras de TI.
Em relação às primeiras, o resultado da pesquisa realizada pela SOFTEX (SOFTEX-MIT, 2002) no Brasil, a pedido de MIT, denominado “A Indústria de software no Brasil – 2002”, identifica o governo como um grande comprador. O governo federal é classificado como sendo um mercado importante, porém instável no atual momento. Os governos estaduais e municipais, em conjunto, representam uma demanda potencialmente interessante, caracterizada por
do total. A pesquisa observa que esse caráter regional de demanda deverá cumprir o papel de alavancar empresas pequenas; porém, a médio prazo, constituirá uma barreira para a formação de um verdadeiro mercado nacional.
Quanto ao nível de investimentos em capacitação tecnológica e Pesquisa & Desenvolvimento - P&D exigido pelo mercado das empresas que fornecem TI, a pesquisa aponta como nichos mais exigentes os de telecomunicações, gestão integrada e automação industrial, seguidos do software bancário e financeiro. Por outro lado, indica que integração de sistemas e área governamental estão associadas a atividades com menor exigência de P&D.
A pesquisa ainda sugere aos fornecedores um investimento na área de desenvolvimento, sinalizando que as principais oportunidades estarão potencialmente no governo, e indica o setor financeiro como o mercado mais sofisticado de software no Brasil.
São destacados dois importantes mercados homogêneos para a venda de produto tipo
Enterprise Resource Planning –ERPs: são aqueles voltados para organizações de pequeno e
médio porte, e serviços de fábrica de software para qualquer tamanho de empresa.
Os resultados da última pesquisa de qualidade e produtividade do setor de software brasileiro de 2001, realizada pela Secretaria de Política de Informática – SEPIN, do Ministério da Ciência de Tecnologia – MCT, no âmbito do Programa Brasileiro de Qualidade e Produtividade -PBQP/SW, com 446 empresas participantes, mostraram que 33% das empresas desenvolvem software para administração pública, ou seja, existe um número considerável de empresas fornecedoras em potencial para o governo.
No que se refere à atuação das empresas de software no mercado, a pesquisa SOFTEX define modelo de negócio da indústria de software, diagnosticando dois grupos: serviços e produtos de software. Para o grupo de serviços de software, em que a gestão e o relacionamento com o mercado incluem lidar com cada cliente e cada projeto como sendo únicos, são aproveitadas, de um contrato para outro, apenas as competências e experiências da empresa e dos profissionais envolvidos. O domínio do negócio está na capacidade de prestar o serviço mais eficiente possível.
Os negócios baseados em produtos de software são, por sua vez, os que asseguram a maior fatia de comercialização. O software embarcado e os componentes de software com serviços de alto valor adicionado, seguidos dos produtos customizáveis estão entre os mais procurados.
Para uma empresa de serviço, os requisitos do software são definidos pelo cliente, fato que desloca o foco de sua atenção para o processo. As empresas fornecedoras de produto de software, ao contrário, apresentam uma estratégia clara de oferta. Fornecedores de solução devem responder às necessidades de um grupo mais ou menos grande de clientes. Vendendo licença de utilização, eventualmente associam serviços de customização para atender necessidades específicas. Mesmo quando ocorre a customização (personalização) do produto, existe um núcleo de códigos que é sempre mantido e está na gênese dos rendimentos crescentes em escala. Mas essa situação obriga os fornecedores a estarem necessariamente expostos e focados nos requisitos específicos do cliente, já que a funcionalidade do produto é crucial para o sucesso da venda.
1.3 Aquisição nas instituições públicas
As instituições e empresas públicas devem seguir a LEI 8.666/93 – Licitações e Contratos, que estabelece a adoção obrigatória da licitação por técnica e preço de bens e serviços de informática (Art. 45, inciso IV, §4º), aumentando a complexidade do procedimento para aquisição de produtos e serviços de informática. Para esses órgãos, é bastante difícil, sem equipe técnica adequada, elaborar, especificar e acompanhar a licitação.
Pequenos municípios, sem condições financeiras para manter, em seu quadro, profissionais capacitados e atualizados em TI, passam por inúmeras dificuldades na elaboração do processo de licitação de serviços e produtos de informática.
Estabelecer requisitos de sistemas e especificar serviços de informática geralmente causa problemas por deixar pontos obscuros e/ou imprevistos, e não é raro que resulte em situações de litígio, acordo de cavalheiros e/ou na simples perda financeira, com o abandono do produto adquirido.
Sabe-se que, por mais que um adquirente tenha clareza do que deseja obter, o sucesso da aquisição também irá depender do fornecedor selecionado. Então, qual seria o nível de qualidade dos serviços e produtos das empresas que atuam no mercado?
1.4 Maturidade das empresas de software
Quando se pretende realizar um contrato de prestação de serviço ou aquisição de produtos de software, é relevante conhecer a forma de trabalho das empresas disponíveis no mercado, a fim de entender os riscos e o grau de satisfação que se pode obter no negócio.
Um conjunto de fatores pode caracterizar uma organização de software como madura ou imatura. A Figura 1.1 ilustra as principais características da empresa imatura.
$
Sucesso depende muito do esforço heróico das pessoas
Pouca repetibilidade ! Clientes e funcionários insatisfeitos * Produtos às vezes funciona, mas o prazo
e custo são maiores Abandono de planos
e procedimentos Acúmulo de trabalho
Figura 1.1 - Cenário das organizações imaturas.
Fonte: Adaptação do quadro apresentado na 3a. Semana de Engenharia de Software (Magnani, 1998).
Os fatores de imaturidade podem, resumidamente, ser identificados e agrupados pela falta de estrutura organizacional adequada, pela ausência de mecanismos de gerenciamento dos projetos, pela indefinição de processos e atividades a serem desenvolvidos e pela baixa previsibilidade da qualidade do produto a ser entregue ao cliente.
A ausência de uma definição e de disciplina na execução das atividades resulta num baixo nível de controle sobre as características de processo e produto. As tarefas executadas, tanto pela gerência quanto pelos técnicos, de maneira improvisada e sem o necessário rigor profissional evidenciam a imaturidade da organização.
A falta de qualidade nos produtos também é conseqüência do entendimento muitas vezes superficial ou incompleto a respeito das funções que devem ser neles inseridas.Outros riscos das organizações imaturas quanto ao serviço prestado também compreendem o prazo de entrega, o custo do desenvolvimento e a inserção de maior quantidade de melhorias nos produtos, mesmo que eles funcionem satisfatoriamente.
Não existe, ainda, uma definição clara e objetiva do que seja qualidade de serviço de software. Através de alguns dados estatísticos coletados nas indústrias de software européias, o trabalho Project Management Tutorial (Kasse, 2000) caracterizou uma empresa como imatura quando:
• 50% dos grandes projetos são superiores aos custos e cronogramas estimados;
• Quase todos os projetos são 20 % superiores ao custo e prazo estimados;
• 52,7% dos projetos custaram 189% acima das estimativas originais;
• 75% dos grandes sistemas não funcionam corretamente e não são plenamente
utilizados;
• 31,1% dos projetos foram cancelados antes de serem finalizados;
• 7% dos projetos de duração maior do que 6 meses foram completados no tempo e custo
previstos;
Já as empresas maduras apresentam características disseminadas pela comunidade envolvida na área de melhoria de processo de software, com base nos bons resultados obtidos (Garro, 1999).
Independente do modelo de processo adotado para efetivar essa melhoria, um conjunto de fatores pode indicar o sucesso de estruturas organizacionais estáveis.
institucionalização de seus processos fundamentais e conseguem prever e estimar a qualidade final de seus produtos, tendo por base o sucesso de projetos e produtos anteriores. A Figura 1.2 retrata o cenário idealizado que pode ser observado em qualquer tipo de organização já amadurecida. M a io r v is ib ilid a d e d a e x e c u ç ã o d o s p r o je to s M e lh o r q u a li d a d e d o p r o d u to M e lh o r h a b ilid a d e p a r a g e r e n c ia r c o m p le x i d a d e M e lh o r a m b i e n te d e t r a b a lh o e s a tis fa ç ã o d a s p e s s o a s M a io r p r o d u tiv id a d e M a io r p r e v is ib ilid a d e d o s r e s u lt a d o s
Figura 1.2 - Cenário das organizações maduras
Fonte: Adaptação do quadro apresentado na 3a. Semana de Engenharia de Software (Mangnani, 1998).
A organização madura apresenta claramente um conjunto de processos definido, documentado, institucionalizado e continuamente melhorado. A garantia da qualidade é um processo visível, bem controlado e apoiado pela gerência organizacional, por meio de constante monitoramento e aprimoramento.
A organização madura apresenta uma previsibilidade efetiva de resultados, que torna possível julgar e predizer um sensível incremento na qualidade de seus produtos intermediário e final. A qualidade do produto entregue ao cliente e sua satisfação retroalimentam e viabilizam o negócio da organização.
1.4.1 Indicadores de maturidade das empresas de software nacional
Embora a maioria das empresas declarem dispor de metodologia de desenvolvimento, a pesquisa SOFTEX revela que, entre as empresas brasileiras de software analisadas, a capacitação de processo é encontrada apenas numa pequena parcela, que tem uma certificação de elevada maturidade no seu processo de desenvolvimento de software, como o CMM nível 3 (três) ou superior.
Dentre as empresas com certificação, a maioria está associada a produto, enquanto as empresas de serviços empregam métodos sem certificação. A pesquisa da SEPIN (2002) detalha mais a situação da qualidade dos processos de software, informando as percentagens de empresas que conhecem e usam métodos com certificação: norma NBR 9000 - 34%, modelo CMM - 21%; norma NBR 12207 -16%; modelo SPICE - 4% (ver Figura 1.3).
0% 5% 10% 15% 20% 25% 30% 35% NBR 9000 Modelo CMM NBR 12207 Modelo SPICE
Empresas que conhecem e usam Processos de Software
Figura 1.3 - Percentagem de empresas que conhecem e usam processos de software
Fonte: SEPIN, 2002.
Com relação à qualidade de produto de software, a pesquisa da SEPIN (2002) esmiuça a seguinte situação: empresas que conhecem e usam a norma NBR 9126-1 - 11%, e a norma NBR 12119 - 8%. Quanto à avaliação de produto, a pesquisa apresenta que 57,8% das empresas não adotam avaliação de produtos; 31,4% declararam que estão estudando, implantando ou que
Esses indicadores sinalizam que há um número pequeno de empresas que conhecem e aplicam normas ou modelos de qualidade para produtos e processos de software. Porém, segundo o Guia da ABNT (1999), a avaliação de produtos de software vem sendo uma das formas empregadas por organizações que produzem ou adquirem software para obtenção de maior qualidade nesses produtos, sejam eles completos ou partes a serem integradas num sistema computacional mais amplo.
Embora ainda em pequena escala, a tendência de adotar processos de avaliação de produtos é crescente. A importância de seu uso adquire um papel chave em processos de aquisição.
1.5 Motivação do trabalho
A oportunidade de apresentar um método que avalia produtos finais de software, para fornecer informações objetivas que subsidiem a decisão pela qualificação ou não de produto num processo de aquisição, divulgando a melhoria da qualidade promovida para tais produtos, através da disponibilização dos resultados, passou a ser um objetivo atraente e motivador -principalmente pela possibilidade de apresentar um processo de desenvolvimento que possa constituir-se num roteiro para a construção de futuros novos métodos. Os potenciais benefícios de avaliação de um produto de software como uma atividade de aquisição devem levar:
• O adquirente a conhecer o nível de qualidade do produto, ajudando-o na tomada de
decisão;
• O fornecedor a obter confiança no valor do produto, e receber um relatório de
avaliação que pode ser utilizado para finalidades comerciais, mas, principalmente, como contribuição para o seu aprimoramento.
Deve-se considerar ainda que, diante de um mercado consumidor imaturo, a pessoa ou entidade que se coloca no papel de avaliador assume uma responsabilidade adicional: influir no mercado para que tanto os adquirentes como os produtores possam evoluir.
“O objetivo principal da avaliação de produto de software é fornecer resultados qualitativos e quantitativos sobre o produto de software que sejam compreensíveis, aceitáveis e confiáveis por quaisquer das partes interessadas (Bache, 1994)”.
1.5.1 Problema da pesquisa
Tendo como ponto de partida o programa coordenado pelo Ministério da Fazenda, com o objetivo de fornecer subsídios técnicos e financeiros para que os pequenos e médios municípios pudessem modernizar sua gestão administrativa e fiscal, através da informatização de sua infra-estrutura, foram definidas várias atividades a serem realizadas.
Especificar requisitos de software e de hardware únicos que abrangessem as áreas de gestão administrativa e fiscal de qualquer dos municípios brasileiros foi um grande marco para a contribuição desse programa, mas o desafio de garantir que os produtos a serem adquiridos viessem a atender aos requisitos ainda precisava ser vencido. A solução encontrada foi estabelecer um processo de pré-qualificação de fornecedores e produtos, em que os produtos de software a serem adquiridos pelos municípios através desse programa fossem avaliados quanto ao cumprimento dos requisitos especificados.
Assim, este trabalho deve responder à seguinte pergunta-problema:
“O método de avaliação aplicado no programa de aquisição de TI - o PNAFM - atende ao objetivo de verificar a conformidade de um produto final de software em relação à especificação de requisitos?”.
1.5.2 Objetivo da pesquisa
O objetivo geral deste trabalho é apresentar o método de avaliação de produto final de software desenvolvido para o Programa Nacional de Apoio à Gestão Administrativa e Fiscal dos Municípios Brasileiros – PNAFM, do Ministério da Fazenda, com os seguintes objetivos específicos:
1.Levantar conceitos básicos da área de qualidade de software, identificando aqueles de
interesse para a realização de uma avaliação para aquisição de produto final de software.
2.Demonstrar a aderência do processo de avaliação, utilizado para o desenvolvimento do
3.Explicar o método de avaliação desenvolvido, dando ênfase às características e subcaracterísticas de qualidade de software aplicadas a cada componente do produto, e na especificação e planejamento da avaliação adotada.
4.Apresentar o estudo do caso em que o método de avaliação, criado pelo CenPRA, foi
aplicado como uma das atividades do edital de pré-qualificação de fornecedores para o PNAFM.
5.Demonstrar, através da análise dos resultados obtidos, se o método de avaliação
utilizado por uma instituição independente atendeu ao objetivo requerido de verificar a conformidade do produto em relação à especificação de requisitos do adquirente.
1.5.3 Restrições
O objeto de estudo deste trabalho é o desenvolvimento e uso de um método de avaliação os quais se propõem a verificar a conformidade de produtos finais de software em relação a uma especificação de requisitos de aquisição, em que também é pontuado, o atendimento aos requisitos de qualidade reconhecidos internacionalmente.
A avaliação proposta não visa habilitar o fornecedor do produto sob aspectos econômicos, financeiros ou fiscais. Quando o adquirente apresentar tal necessidade, é recomendado que os referidos aspectos analisados em outra atividade do processo da aquisição.
O uso deste método de avaliação é recomendado quando o nível de integridade do software for enquadrado como médio ou alto, seja pela exigência prescrita pelo adquirente, seja pelo rigor de uso do software.
O produto de software avaliado pelo método apresentado enquadra-se nas características de aplicativos comerciais de baixo P&D, não existindo ainda casos de uso desse processo de avaliação em produtos de software científicos, embarcados, ou enquadrados como de alto nível tecnológico ou de P&D.
Trata-se da avaliação de um produto final, e não de um produto intermediário. Em razão disso, espera-se que o fornecedor declare, antes do início da avaliação, que o desenvolvimento do produto está encerrado.
O método avalia um produto final de software, independentemente da tecnologia, das ferramentas adotadas no seu desenvolvimento ou da plataforma necessária para sua operação.
A avaliação é feita do ponto de vista do usuário final e utiliza apenas o material que normalmente é disponibilizado aos usuários. Assim, os elementos do produto final de software a ser avaliado são o software executável e a documentação para usuário, não se aplicando qualquer análise sobre o código dos programas-fonte ou sobre a documentação gerada durante seu desenvolvimento, como “avaliação de custo” ou “documentos técnicos”.
É premissa deste estudo que os requisitos de aquisição sejam fornecidos pelo requerente da avaliação. Orienta-se que a especificação de aquisição atenda as orientações da norma NBR 12207 (NBR ISO/IEC 12207, 1998), a qual também é referenciada nas seções 6 e 7 da norma NBR 14598-4 (NBR ISO/IEC 14598-4, 1999).
A avaliação deve mostrar o grau de atendimento do produto de software em relação aos requisitos funcionais e de qualidade especificados por um adquirente. Em relação as características e subcaracterísticas de qualidade descritas na norma NBR 9126-1 (NBR ISO/IEC 9126-1, 2001), estão incluídas características como: confiabilidade, eficiência, funcionalidade e usabilidade, sendo as duas últimas, especialmente, detalhadas sob a ótica do adquirente.
Este método de avaliação é considerado um teste de caixa preta de software, que, de acordo com a literatura sobre o tema, percorre a lógica de verificar o atendimento aos requisitos, implementando casos de teste e alguns testes específicos para atender a necessidade de alguns requisitos funcionais.
A avaliação não é dirigida a um pacote de software nas condições descritas pela norma NBR 12119 (NBR ISO 12119, 1999); porém, conforme recomendações desta, foram adaptados e utilizados alguns de seus componentes, características de qualidade e instruções de teste.
1.6 Método de pesquisa
As pesquisas exploratórias têm como principal finalidade desenvolver, esclarecer e modificar conceitos e idéias, tendo em vista a formulação de problemas mais precisos ou hipóteses pesquisáveis para estudos posteriores (...) Habitualmente envolvem levantamento bibliográfico e documental, entrevistas não padronizadas e estudos de caso...
O presente estudo utiliza três dos quatro instrumentos de pesquisa citados por Gil. O levantamento bibliográfico foi feito em literatura especializada - normas, livros e artigos que tratam do tema engenharia de software e qualidade de software, com ênfase em avaliação de produto de software. Para o estudo, focou-se o programa PNAFM, coordenado pela Unidade Central de Programas do Ministério da Fazenda – UCP/MF e pelo Centro de Pesquisa Renato Archer – CenPRA –, cujos arquivos serviram ao levantamento documental.
Selltiz (apud Canedo, 1998, p. 62) afirma, sobre o estudo exploratório, que:
Muitos estudos exploratórios têm como objetivo a formulação de um problema para investigação mais exata ou para a criação de hipóteses. No entanto, um estudo exploratório pode ter outras funções: aumentar o conhecimento do pesquisador acerca do fenômeno que deseja investigar em estudo posterior (...); estabelecimento de prioridades para futuras pesquisas...
1.6.1 O estudo do caso “Pré-qualificação do PNAFM”
Segundo Gil (1999, p. 72), “o estudo de caso é caracterizado pelo estudo profundo e exaustivo de um ou de poucos objetos, de maneira a permitir o seu conhecimento amplo e detalhado, tarefa praticamente impossível mediante os outros tipos de delineamentos possíveis”. O estudo de caso pode ser utilizado tanto em pesquisas exploratórias, como a do presente trabalho, como nas descritivas e explicativas.
De acordo com Godoy (apud Antonialli, 2000), o estudo de caso tem se tornado a estratégia preferida quando os pesquisadores procuram responder a "como" e "por que" certos fenômenos acontecem, quando há pouca possibilidade de controle sobre os eventos estudados e quando o foco de interesse é sobre fenômenos atuais, que só poderão ser analisados dentro de algum contexto de vida real.
Neste trabalho, quer-se descobrir "como" a pré-qualificação de produto contribui para o sucesso do PNAFM, na sua principal etapa, a de verificar a conformidade de um produto de software e por atuar como filtro, estabelecendo o padrão mínimo de qualidade do produto a ser adquirido. Gil (1996) apresenta uma relação de vantagens e limitações do estudo de caso, da qual destacamos os seguintes trechos, de interesse para este trabalho:
O estudo de caso apresenta uma série de vantagens, o que faz com que se torne o delineamento mais adequado em várias situações. As principais vantagens são:
a)O estímulo a novas descobertas. Em virtude da flexibilidade do planejamento do estudo de caso, o pesquisador, ao longo do seu processo, mantém-se atento a novas descobertas (...) Daí porque é altamente recomendado para a realização de estudos exploratórios;
b)A ênfase na totalidade.
É claro que o estudo de caso também apresenta limitações. A mais grave refere-se à dificuldade de generalização dos resultados obtidos...
O estudo do caso aborda o processo de desenvolvimento do método e execução da avaliação de um produto de software denominado conjunto de sistemas aplicativos – CSA - do processo de aquisição do projeto simplificado do programa PNAFM do Ministério da Fazenda. Este CSA contém 8 (oito) sistemas aplicativos e um sistema de administração do produto. Cada sistema aplicativo contém um subconjunto de aplicações específicas, que pode ser encontrado no mercado como produto independente.
1.6.2 Planejamento do estudo do caso
O planejamento da pesquisa consiste na definição de um plano de ação para dar coerência lógica ao estudo. Segundo Yin (1994), ao ser planejado o estudo de caso, cinco componentes de um projeto de pesquisa são especialmente importantes:
• As questões, sendo “como” e “por que” as mais comuns para estudo de caso;
• As proposições que podem ser formuladas para direcionar o estudo; no entanto,
pesquisas do tipo exploratório normalmente não apresentam proposições;
• A unidade de análise, para se definir, claramente, o que é o caso em estudo;
Na Tabela 1.1 – Resumo do planejamento do estudo do caso PNAFM -, esses elementos são definidos e descritos de forma esquemática.
Tabela 1.1 - Resumo do planejamento do estudo do caso PNAFM
Unidade de análise A avaliação de produto final de software estabelecida na Pré-qualificação do projeto simplificado do Programa Nacional de Apoio à Gestão
Administrativa e Fiscal dos Municípios Brasileiros - PNAFM
Questões em estudo Como e por que a avaliação utilizada na pré-qualificação contribui para:
• a qualidade dos produtos a serem oferecidos ao programa;
• garantir um padrão mínimo de qualidade;
• aumentar a chance de sucesso do PNAFM;
• colaborar com os produtores na evolução da qualidade do produto final
de software oferecido às prefeituras;
• a disseminação do conhecimento na aplicação de normas de qualidade
de software e das boas práticas de administração pública municipal, nas atividades que estão sendo apoiadas pelo programa.
Proposições Iniciais Não há. Dados a serem
coletados
Estágio de evolução da ciência relacionadas a qualidade de software; Visão do nível de maturidade das empresas de software brasileiras; Situação atual do governo como adquirente no mercado de software; Detalhes sobre o programa PNAFM, o processo de pré-qualificação; Identificação do modelo de avaliação adotado nas normas de qualidade de software, experiências adquiridas no desenvolvimento do método e na execução das avaliações e coleta de registros dos resultados obtidos.
Conexão entre dados e proposições
Não há.
Fonte: Componentes de um estudo de caso, segundo Yin (1994)
Em alguns casos, pode ser também importante a definição dos critérios para interpretação dos resultados, o que não se aplica a este estudo.
A identificação das principais limitações e vantagens obtidas pelo estudo do caso adotado pode fornecer subsídios para trabalhos futuros, através da ótica crítica do processo adotado e pelas avaliações dos produtos de software. Dentro da análise proposta, a descrição do método de avaliação também deve possibilitar a adquirentes de software e, em especial, aos pesquisadores da área fundamentar aspectos da qualidade dos produtos de software acabados.
1.7 Organização da dissertação
Este trabalho está estruturado de forma a apresentar, no capítulo 2, uma revisão da literatura na área de qualidade de software, onde os temas “qualidade” e “software” são brevemente revisitados. É realizado um resumo dos modelos de maturidade em processos de software, dando ênfase a alguns elementos da engenharia de software, destacando-se o processo de aquisição. Com uma visão um pouco mais detalhada, são apresentadas as normas de qualidade de software e de avaliação de produto de software que subsidiaram a construção do método.
Em seguida, no capítulo 3, é formulada a proposta de um processo de avaliação de produto final de software, constituída com base na experiência registrada no estudo de caso, utilizando as quatro etapas: identificação dos requisitos de avaliação, especificação da avaliação, projeto de avaliação e execução da avaliação.
O capítulo 4 descreve a experiência da aplicação do processo de avaliação proposto no capítulo 3, no estudo do caso do PNAFM, relatando os registros e particularidades da aplicação e os resultados obtidos em cada etapa. E, principalmente, contextualiza o uso do processo de avaliação como uma estratégia de aquisição adotada pelo programa para atender os municípios.
No capítulo 5, é mostrada a análise dos resultados obtidos com a aplicação do método nos oito CSAs avaliados até o presente momento pelo PNAFM. Os resultados são analisados diferenciando os CSAs qualificados dos não qualificados - por tipo de requisito, por componente e por sistema aplicativo. Em seguida, explicita-se uma relação dos requisitos que obtiveram, em cinco ou mais avaliações, algum erro considerado grave e a descrição do mesmo.
Finalmente, no capítulo 6, estão colocadas as conclusões tiradas desta experiência de execução das avaliações nas condições do programa, indicando benefícios e outras conveniências a respeito do assunto. Ressaltam-se questões que ainda carecem de maior aprofundamento, e formula-se propostas novos trabalhos inclusive que possam contribuir com a qualidade de produtos a serem adquiridos e utilizados pelas instituições públicas.
Capítulo 2: Conceitos básicos de qualidade e software
Neste capítulo são apresentadas informações pesquisadas e entendidas como de interesse para o tema deste trabalho.
2.1 Aspectos da qualidade para software
Quando se aborda o tema qualidade, mesmo dentro de um contexto específico de software, faz-se necessário resgatar resultados de pesquisas, normas e outros materiais científicos que forneçam fundamentos e conceitos consagrados para a sustentação do trabalho.
Qualidade é o grau no qual um conjunto de características inerentes satisfaz a necessidade ou expectativa geralmente expressa, implícita ou obrigatória através de requisitos. Os tipos de requisitos são distinguidos pelo uso de um qualificador como, por exemplo, requisito do produto, requisito da gestão da qualidade, requisito do cliente (NBR ISO/IEC 9000, 1993).
Característica é uma propriedade diferenciadora. Pode ser inerente ou atribuída, qualitativa ou quantitativa. Uma característica pode ser física, sensorial, comportamental, temporal, ergonômica ou funcional (NBR ISO/IEC 9000, 1993). As características de qualidade estão relacionadas a requisitos inerentes a produto, processo ou sistema.
Gerir qualidade é uma ação voltada para o sistema, processo ou produto, e garantir qualidade é prover confiança em que os requisitos da qualidade estão sendo atendidos. Um sistema pode ser entendido como um conjunto de elementos inter-relacionados ou interativos, enquanto pode entender-se um processo como um conjunto de atividades inter-relacionadas ou interativas, que transformam insumos (entradas) em produtos (saídas). Um processo deve agregar valor ao produto. Procedimento é a execução de uma atividade ou um processo, de forma especifica (NBR ISO/IEC 9000, 1993).
Produto é o resultado de um processo, podendo ser classificado em 4 categorias: serviço (p.ex.: transporte); informações (p.ex.: dicionário, uma ata); materiais e equipamentos, e materiais processados (NBR ISO/IEC 9000, 1993).
Um programa é enquadrado, pela NBR ISO 9000, como produto do tipo informação. Um software, segundo Sommerville (2003), não é só um programa, mas também toda a documentação a ele associada, além dos dados de configuração necessários para sua correta operação.
Produto de software, diferente de outros produtos, como os manufaturados, possui propriedades que justificam grande parte da dificuldade para se obter qualidade. Segundo Tsumuko (1985), um produto de software é complexo, invisível, de produção única, não desgasta, funciona com múltiplos usuários ao mesmo tempo e possui um cálculo de custo centrado no custo do seu desenvolvimento.
Um sistema de software consiste em uma série de programas separados, arquivos de configuração, documentação da estrutura do sistema, e a documentação do usuário, explicando como utilizar. Produtos de software também incluem a presença de informações sobre procedimentos de atualização de versões (Sommerville, 2003).
Em síntese, um software composto por um ou mais programas possui características diferenciadas dos produtos manufaturados. Um produto de software é aquele que pode ser vendido a um cliente e deve possuir, além de todos os componentes de um sistema de software, atributos que norteiem o relacionamento adquirente-fornecedor.
Falando em aquisição de produto ou sistema de software, Sommerville (2003) pondera que ele não é uma entidade independente, mas existe em um ambiente que afeta o seu funcionamento.
Um ambiente, às vezes, pode ser considerado um sistema em si mesmo, mas em geral, ele consiste em uma série de outros sistemas que interagem entre si. Assim, há duas razões principais pelas quais o ambiente de um sistema deve ser compreendido num processo de aquisição: o sistema pode ser concebido para modificar o ambiente; e o funcionamento de um sistema pode ser afetado por mudanças de um ambiente.
que o uso do sistema atinja seu objetivo, temos as mudanças no processo mudanças de tarefas, mudanças organizacionais.
A norma NBR 9000 (NBR ISO/IEC 9000, 1993) identifica características de qualidade distintas para processo, produto e sistema, mas sempre relacionadas a requisitos. A engenharia de software aprimora as definições desses conceitos, acomodando sua compreensão para os aspectos da qualidade de software.
Qualidade do processo é o grau com que ele garante a qualidade dos respectivos produtos de software, enquanto a qualidade do produto é o grau de conformidade com os respectivos requisitos (Paula F, 2001). A totalidade das características do produto de software lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas (NBR ISO/IEC 9126-1, 2001).
Quando o foco é usar tecnologia da informação - TI, devem ser consideradas três instâncias para definir qualidade: o ambiente, o sistema de informação e o produto de software, em que uma instância está estreitamente relacionada às outras, influenciando a qualidade final do uso de TI. Para o ambiente, os elementos básicos relacionados são o local físico, o hardware, a telecomunicação/rede, o sistema de informação e o peopleware. Os aspectos de sistema de informação relacionam-se a integração de sistemas, produtos de software, nível de integridade, arquivo de configuração, estrutura de base de dados e documentação de sistema.
Cabe ao produto de software apresentar qualidade externa, qualidade em uso, documentação para o usuário e, principalmente, função ou aplicação com informações relacionadas ao propósito e desempenho esperado.
Assim, os requisitos de aquisição de um produto de software devem especificar, além dos requisitos funcionais do produto, incluindo leis e praxes da área, os requisitos de facilidade de uso e os requisitos de sistema, como o nível de integridade e integração requerido e os aspectos do ambiente (NBR ISO/IEC 12207, 1998).
Definir requisitos, geralmente, é expressar, em forma de documento, quais características uma entidade deve possuir para ser aceita (Paula F, 2001). Um requisito é:
• Explícito, se descrito num documento que arrola os requisitos, ou seja, um documento
• Implícito, quando não é documentado, porém cobrado em decorrência de sua experiência no momento de utilização.
• Normativo, quando decorre de lei, regulamentos, padrões e outros tipos de regras que
devem ser obedecidas. O requisito normativo define as condições em que a entidade deverá ser utilizada, seu objetivo, sua função e expectativa de desempenho.
Quando se definem requisitos para um ambiente, um sistema de informação ou um produto, devem ser levadas em consideração as três formas de apresentação de um requisito. Em geral, as necessidades explícitas são expressas na definição de requisitos propostos após o levantamento das necessidades. O enfoque da qualidade centrado no atendimento a esses requisitos é denominado "conformidade com os requisitos” (ISO/IEC 9126-2, 2001). Necessidades implícitas são percebidas quando o produto é utilizado em condições particulares (NBR ISO/IEC 14598-1, 1999), e são imprescindíveis no uso do software. Um produtor de software experiente tem mais facilidade para identificar requisitos implícitos, geralmente relacionados à "adequação ao uso".
Um software é considerado de qualidade se estiver correto, consistente, compreensível e testável. Para garantir a qualidade do software, são necessárias avaliações que podem envolver: verificação, validação e testes do produto (NBR ISO/IEC 14598-1, 1999).
Qualificar é demonstrar a capacidade que um produto ou processo tem de atender a requisitos específicos. Qualificar é designar uma situação correspondente, associada a pessoas, processos e produtos (NBR ISO/IEC 9000, 1993).
Para qualificar um produto ou um processo de software, faz-se necessária uma avaliação. A avaliação da qualidade de um produto de software é um exame sistemático que evidencia a capacidade do produto em atender os requisitos especificados (NBR ISO/IEC 14598-1, 1999). Ela pode ser aplicada a um produto intermediário ou final, resultante de uma atividade do processo de desenvolvimento de software (Scope, 1993).
A avaliação da qualidade de processo de software consiste no exame dos procedimentos operacionais e gerenciais, métodos e técnicas utilizados nas fases de desenvolvimento (Tsukumo, 1996a). O objetivo é identificar práticas que possam provocar problemas na qualidade do produto
geração de produtos melhores, entretanto, não garante a qualidade do produto final. Os dois tipos de avaliação são necessários e complementares; embora distintos, com técnicas e métodos próprios, eles têm como objetivo comum garantir a qualidade do produto final (Sant’Ana, 2002).
Um produto de software deve ser avaliado quanto a sua qualidade. Entre outros motivos, para identificar e entender as razões técnicas das deficiências e limitações manifestadas através de problemas operacionais ou problemas de manutenção, assim como para comparar produtos, mesmo que indiretamente; e/ou para formular-se um plano de ação para evoluí-lo.
O tema qualidade de software vem sendo aprofundado em suas diferentes visões: qualidade de processo, qualidade de produto e qualidade em uso, as quais são, por consenso, consideradas complementares (SSQP/SW, 2002).
As propostas de avaliação da qualidade de processos e de produtos, intermediários ou finais, têm como objetivo comum melhorar a qualidade do produto em uso. Qualidade em uso é o grau em que o produto pode ser usado por usuários específicos, num contexto específico de uso (ISO/IEC 9126-4, 2001).
Para permitir a correta avaliação de qualidade de software, tanto de produtos quanto de processos, muitas instituições vêm fornecendo informações em forma de normas, padrões e modelos. Uma experiência da aplicação das normas de qualidade de produto de software realizada no Brasil é apresentada por Tsukumo (1995 e 1996b) em seus artigos sobre o tema. Trata-se da avaliação de produto de software no Prêmio “Melhor software do ano”, realizado em 1994 pelo CenPRA e pela ASSESPRO, quando foi criado o método de avaliação de produto de software – MEDEPROS®.
Nos próximos tópicos deste capítulo, serão mostradas algumas das principais informações disponíveis para as visões de qualidade de processo e produto, incluindo, neste último, aspectos da qualidade em uso.
2.2 Qualidade de processo de software
Recentemente, os esforços de pesquisa na área de qualidade de software vêm se concentrando na parte de processo que está diretamente ligada à engenharia de software. Na
busca de explicar em detalhes como desenvolver um software com qualidade, essa área visa garantir a qualidade no desenvolvimento como um importante passo para obter produto de software com qualidade. Na área de qualidade de processo de software, existem modelos bastante disseminados e normas públicas. Dentre eles destacam-se:
• NBR 12207 – regulamenta o processo do ciclo de vida do software;
• Série NBR 9000, composta pelas partes 1, 2, 3, e 4 e as normas NBR 9001, NBR 9002,
NBR 9003, e NBR 9004;
• CMM - Capability Maturity Model, modelos SW-CMM e SA-CMM;
• CMMI - Capability Maturity Model Integration - por estágio e contínuo;
• ISO 15504 - SPICE - Software Process Improvement and Capability dEtermination.
2.2.1 NBR 12207 - processo do ciclo de vida do software
A norma NBR 12207 foi a primeira norma internacional a estabelecer uma estrutura comum, contendo processos, atividades e tarefas do ciclo de vida de software, com terminologia bem definida. Seu objetivo, além de criar uma linguagem comum para a engenharia de software, é prover processos que possam ser utilizados para definir, controlar e melhorar este ciclo de vida de software e servir de referência para os demais padrões que venham a surgir. Lançada pela ISO em agosto de 1995, e pela ABNT em 1998, ela é citada em quase todos os trabalhos relacionados à engenharia de software, inclusive os relativos à qualidade.
Os processos da norma NBR 12207 formam um conjunto abrangente. Organizações, projetos ou aplicações especiais devem selecionar um subconjunto apropriado, dependendo de seu objetivo. Os processos dividem-se em três classes: fundamentais, de apoio e organizacionais. Conforme Tabela 2.1 – processo do ciclo de vida.
Este trabalho utilizou conceito e informações do Processo Fundamental – Aquisição, em que, para suas atividades de monitoramento do fornecedor, foram identificados três (3) Processos de Apoio, que são: (1) verificação, (2) validação e (2) revisão conjunta.
Tabela 2.1 - Processo do ciclo de vida
Processo Descrição
Processos Fundamentais Início e execução do desenvolvimento, operação ou manutenção do
software durante seu ciclo de vida.
Aquisição Atividades de um adquirente de software.
Fornecimento Atividades do fornecedor (proposta, planos de projeto e entrega).
Desenvolvimento Atividades do desenvolvedor (análise de requisitos, projeto, testes,
instalação e aceitação).
Operação Atividades do operador (operação e suporte aos usuários).
Manutenção Atividades de quem faz a manutenção.
Processos de Apoio Auxiliam um outro processo.
Documentação Registro de informações produzidas por um processo ou atividade.
Gerência de Configuração Identificação e controle dos itens do software (armazenamento, versão, distribuição).
Garantia da Qualidade Processos e produtos de software em conformidade.
Verificação Produtos de software atendem requisitos ou condições impostas.
Validação Se os requisitos e o produto final atendem ao uso.
Revisão Conjunta Atividades de avaliação da situação e produtos de uma atividade de
um projeto, se apropriado.
Auditoria Adequação dos requisitos, planos e contrato, quando apropriado.
Resolução de Problemas Analisar e resolução dos problemas.
Processos Organizacionais Implementam uma estrutura de processos de ciclo de vida.
Processo Gerencial Gerenciamento de processos.
Infra-estrutura Fornecimento de recursos para outros processos. Inclui: hardware,
software, ferramentas, técnicas, padrões de desenvolvimento, operação ou manutenção.
Melhoria Estabelecer, avaliar, medir, controlar e melhorar um processo.
Treinamento Atividades para prover e manter pessoal treinado.
Fonte: elaborada com base nas normas NBR 12207 (1997)
O processo de aquisição consiste de cinco atividades: (1) iniciação; (2) preparação de pedido de proposta; (3) preparação e atualização do contrato; (4) monitoramento do fornecedor; e (5) aceitação e conclusão.
Na atividade de iniciação, são definidas as necessidades e requisitos de aquisição compostos pelos requisitos do sistema, de negócio, organizacionais, dos usuários, assim como os critérios de segurança, atividades do projeto, testes e aderência a padrões. Realiza-se a análise dos requisitos de sistemas e definem-se critérios de aquisição, levando em conta riscos, custos e benefícios, a estratégia de aceitação do produto, os direitos de propriedade, o suporte técnico; e estabelecendo-se o plano de aquisição.
