120
TÓPICO 1
INTRODUÇÃO À QUALIDADE DE SOFTWARE
UNIDADE 3
1 INTRODUÇÃO
O entendimento popular sobre o conceito de qualidade tem evoluído à medida que a experiência humana acompanha a evolução tecnológica. As gerações que viveram períodos em que as experiências se davam de forma exclusivamente tangível ainda tem em sua programação genética a ideia de que qualidade é sinônimo de durabilidade.
Já as gerações cujas experiências são mais intangíveis possuem outros parâmetros para opinarem sobre qualidade. As gerações da era da intangibilidade utilizam outros critérios para indicarem se um produto ou serviço possui ou não os requisitos desejados de qualidade. Estas pessoas consideram a qualidade de forma mais sistêmica, considerando inclusive aspectos subjetivos.
Esta evolução foi praticamente proporcional nos padrões de qualidade reconhecidos internacionalmente. Há algumas décadas os padrões de qualidade consideravam critérios puramente tangíveis relacionados ao resultado final. O controle da qualidade se dava quase que exclusivamente no final do processo através de um processo de inspeção do resultado.
Houve um período intermediário em que se entendeu que a qualidade deveria ser inspecionada também nas demais fases de construção. Até que finalmente passou-se a defender a ideia de que a qualidade é resultante de um processo bem definido e que possa ser repetido e melhorado. Então os modelos de qualidade focaram os processos como forma de garantia da qualidade.
Houve também a onda da qualidade total. Todos queriam qualidade total para seus produtos e processos. Até que gradualmente os conceitos em torno da
UNIDADE 3 | QUALIDADE DE SOFTWARE
122
Esta perspectiva da qualidade não considera a área de atuação. Porém, para a área de Engenharia de Software é perfeitamente aderente. Na Engenharia de Software já vivemos o tempo em que software de qualidade era aquele que não apresentava falhas graves que impedissem a execução das funcionalidades para as quais o software foi construído.
Evoluímos em relação à qualidade de software, porém ainda há um longo caminho a ser percorrido para atingirmos um patamar aceitável. É necessário dar atenção à qualidade no início do processo de software e não apenas na fase de qualidade, revisão, testes ou qualquer outro nome que se dê para a atividade.
2 FUNDAMENTOS DE QUALIDADE DE SOFTWARE
A palavra qualidade é utilizada na Engenharia de Software e em outras áreas com frequência, porém há muitas dúvidas sobre seu real significado. Então, afinal, o que é qualidade?
Para responder a essa importante pergunta, vamos analisar como algumas autoridades na área da qualidade definem o termo. As autoridades da qualidade selecionadas para análise foram Crosby, Deming, Feigenbaum, Ishikawa, Juran e Shewhart. Iniciaremos entendendo o conceito de maneira independente de área.
Para Crosby (1979) o primeiro pressuposto incorreto sobre qualidade é o de que ela signifique durabilidade, luxo ou beleza. A palavra qualidade é frequentemente utilizada para significar o valor relativo de algo em frases como boa qualidade, má qualidade e qualidade de vida, o que possui significados diferentes para cada pessoa.
Qualidade pode ser definida como conformidade aos requisitos que estão sendo gerenciados. Consequentemente, as não conformidades identificadas significam ausência de qualidade, problemas de não conformidade se tornam problemas de qualidade e então se pode passar a definir o que é qualidade (CROSBY, 1979).
Ao analisar as palavras de Crosby pode-se concluir claramente que para ele qualidade significa conformidade com as especificações. Ele defende também a importância de compreender as expectativas que se tem em relação às questões relacionadas à qualidade de produção, bem como outras perspectivas externas.
Para Crosby (1979) o conceito de qualidade deve estar claro para que seja possível realizar medições e gerenciamento dela. A perspectiva de qualidade de Crosby pode ser sumarizada em quatorze passos que estão apoiados em quatro fundamentos absolutos de gestão da qualidade:
1. Qualidade é definida como conformidade com os requisitos, não como durabilidade ou beleza.
TÓPICO 1 | INTRODUÇÃO À QUALIDADE DE SOFTWARE
2 FUNDAMENTOS DE QUALIDADE DE SOFTWARE
2. A forma para obter qualidade é a prevenção, não inspeção. Isto é, a forma de qualidade para os fornecedores atenderem os requisitos dos clientes é fazer certo da primeira vez. Crosby é um forte defensor da prevenção ao invés da inspeção. Numa organização com cultura orientada às ideias de Crosby todos são responsáveis pelo resultado de seu trabalho. Não há ninguém para encontrar erros.
3. O padrão de desempenho deve ser zero defeitos, não sendo aceito o “está bom o suficiente”. Crosby (1979) defende que a noção de que zero defeitos pode e deve ser o objetivo.
4. A medida da qualidade é o custo da qualidade. Uma imperfeição tem um efeito imediato na redução do desempenho, podendo refletir na relação com o cliente. Neste caso, investimentos precisam ser feitos com treinamentos e outras atividades que permitam eliminar os erros e recuperar o custo das perdas.
Deming (1988) argumenta que a dificuldade em definir qualidade reside na tradução de futuras necessidades dos usuários em características mensuráveis.
Assim um produto pode ser projetado e produzido de forma a satisfazer as necessidades a um custo aceitável pelos usuários.
A grande dificuldade está no fato de que quanto mais se consegue aproximar do produto ideal, descobre-se que novos esforços precisam ser empreendidos. No tempo que as melhorias foram realizadas as necessidades dos usuários mudaram, os produtos concorrentes evoluíram mais rápido, entre outros fatores (DEMING, 1988).
O ponto chave do conceito de Deming é que a qualidade deve ser definida em termos de satisfação dos usuários. Este conceito muito mais amplo que a definição de qualidade como conformidade com as especificações. Deming (1988) defende que a qualidade deve ser definida apenas do ponto de vista de quem julga a qualidade.
Para facilitar o entendimento de sua perspectiva sobre qualidade, Deming (1988) introduziu catorze pontos de gerenciamento para ajudar as pessoas a entenderem e implementar a transformação necessária:
1. Criar constância de propósito para melhoria de produtos e serviços.
UNIDADE 3 | QUALIDADE DE SOFTWARE
124
12. Remover barreiras para poder orgulhar-se das habilidades.
13. Instituir um vigoroso programa de educação.
14. Agir para conquistar a transformação.
A qualidade não pode ser determinada pelos profissionais de software, nem pelo marketing, nem pela administração. Ela é determinada pelo cliente através de sua experiência com o produto ou serviços disponibilizado.
Os requisitos utilizados para determinação da qualidade podem ou não estar declarados, realizados ou não em consenso, tecnicamente operacionais ou completamente subjetivos. É importante que as metas apresentem sempre movimento no sentido de atender um mercado competitivo.
Para Feigenbaum (1983) a qualidade de produto ou serviço pode ser definida como: a composição total das características de marketing, engenharia, manufatura e manutenção de produtos e serviços através dos quais o uso atenderá as expectativas dos clientes.
Esta definição de qualidade pode ser resumida como atendimento das necessidades dos clientes. Embora Feigenbaum vá além, defendendo o atendimento atual e futuro das necessidades dos clientes. Isto significa que para ele o conceito de qualidade não é estático, mas que deve ser atualizado conforme mudarem as necessidades.
A forma de interpretar o termo qualidade é importante, pois se for interpretada de forma restrita significará qualidade de produtos, mas se for interpretada de forma abrangente, o termo significará qualidade de produtos, serviços, informações, processos, pessoas, sistemas etc. (ISHIKAWA, 1985).
No processo de controle de qualidade o objetivo é obter produtos cuja qualidade possa satisfazer os requisitos dos clientes. O simples fato de atender a padrões ou especificações nacionais não é o suficiente. Os padrões internacionais definidos pela ISO (International Organization for Standardization) ou pela IEC (International Eletrotechnical Commission) não são perfeitos.
Os padrões possuem muitas falhas. Os clientes podem não estar satisfeitos com um produto que atenda estes padrões. É necessário ter em mente que os requisitos dos clientes mudam de um ano para outro e mesmo padrões atualizados frequentemente dificilmente acompanham a velocidade de mudança dos requisitos dos clientes.
A perspectiva de qualidade de Ishikawa está direcionada para a definição de que qualidade é atender às necessidades dos clientes e acompanhar as mudanças de expectativas. Isto significa que qualidade é um conceito dinâmico, pois as necessidades, os requisitos e expectativas dos clientes mudam continuamente.
TÓPICO 1 | INTRODUÇÃO À QUALIDADE DE SOFTWARE
Desta forma, qualidade deve ser definida de forma compreensiva e dinâmica. Além disso, Ishikawa (1985) defende que o preço também é um atributo de qualidade. Ele argumenta que um produto com preço alto pode não satisfazer o cliente e consequentemente do ponto de vista dele não ter alta qualidade.
Qualidade é um requisito básico e implícito em qualquer atividade, porém é importante lembrar que vivemos em um mondo finito e, portanto, a qualidade também possui seus limites. Existem situações em que a melhoria na qualidade pode inviabilizar os custos do produto ou atividade, logo, procura-se trabalhar sempre dentro do equilíbrio entre estas forças.
UNI
Qualidade pode ter múltiplos significados no entendimento de Juran (1988). Destes múltiplos significados, dois são os mais importantes. O primeiro significado é o de que qualidade consiste das características do produto que atende às necessidades dos clientes, provendo um produto que atenda a suas necessidades.
O segundo significado diz que qualidade consiste na inexistência de deficiências. Analisando por outra ótica, Juran (1988) defende que o termo qualidade pode ser definido como adequado para uso (fitness for use).
A definição de qualidade de Juran (1988) destaca que não se pode definir qualidade apenas em termos de satisfação das expectativas ou especificações dos clientes por ser muito difícil atingi-la. Ao invés disso, ele define qualidade como adequado ao uso, indicando referências a requisitos e características do produto.
Desta forma, a definição de Juran (1988) pode ser interpretada como uma definição mais voltada para conformidade com as especificações do que uma definição de atendimento das necessidades dos clientes. Juran (1988) propôs três processos para o gerenciamento da qualidade:
UNIDADE 3 | QUALIDADE DE SOFTWARE
126
Um olhar que pode ser considerado ainda mais sistêmico é o de Shewhart (1931). Ele entende que há dois aspectos comuns na qualidade. O primeiro aspecto diz respeito à consideração da qualidade como um objetivo independente da existência do homem. O segundo, como se pensa, sente e percebe a realidade, ou seja, o lado subjetivo da qualidade.
Embora o conceito de qualidade de Shewhart seja de 1920 pode ser considerado um dos mais completos, pois define os lados objetivo e subjetivo da qualidade. O conceito se enquadra nas definições de conformidade com as especificações e atendimento das necessidades dos clientes.
Focando especificamente na área Engenharia de Software, também podemos encontrar algumas definições derivadas das clássicas e que são bastante interessantes. Do ponto de vista de Hoyer e Hoyer (2001), a qualidade de software possui duas principais definições:
• Conformidade com as especificações: aplicável quando a qualidade de um produto ou serviço é definida em termos de características mensuráveis em relação a uma especificação previamente definida.
• Atendimento das necessidades dos usuários: aplicável quando a qualidade de um produto ou serviço é definida em termos de satisfação das expectativas dos usuários, ou seja, independente de características mensuráveis em relação a uma especificação previamente definida.
Da mesma forma como os conceitos clássicos da qualidade, em software podemos utilizar abordagens qualitativas e quantitativas. As estruturas genéricas da qualidade são relativamente mais qualitativas. Para uma abordagem mais quantitativa podem-se utilizar modelos de qualidade dentre os quais se podem citar os modelos de McCall, Boehm, FURPS, Dromey, ISO, IEEE, CMM e Seis Sigma.
Do ponto de vista de Engenharia de Software, um dos modelos mais notáveis é o modelo de qualidade de McCall, também conhecido como o modelo da General Eletric de 1977. Este modelo, assim como outros contemporâneos, é originário das Forças Armadas dos EUA (desenvolvido para a Força Aérea dos EUA, promovido no âmbito do DoD) e é voltado principalmente para os desenvolvedores de sistemas e para os processos de desenvolvimento de sistemas.
Este modelo de qualidade tenta preencher a lacuna entre os usuários e desenvolvedores em torno de uma série de fatores de qualidade de software que refletem tanto as prioridades do ponto de vista dos usuários quanto dos desenvolvedores.
O modelo de qualidade de McCall tem três grandes perspectivas para a definição e identificação dos critérios de qualidade de um produto de software. O primeiro é a revisão do produto (capacidade de sofrer alterações), o segundo é a transição do produto (adaptabilidade a novos ambientes) e o terceiro a operação de produto (suas características de operação).
TÓPICO 1 | INTRODUÇÃO À QUALIDADE DE SOFTWARE
Uma das melhores referências que pode ser utilizada para o assunto é o SWEBOK (Software Engineering Body of Knowledge). Na realidade, ele trata de diversos aspectos relacionados a software e a qualidade é um deles.
O SWEBOK está organizado em diversos capítulos que tratam de requisitos, design, construção, testes, manutenção, gerenciamento de configuração, gerenciamento da engenharia, processos de engenharia, métodos e ferramentas de engenharia, qualidade e disciplinas relacionadas (IEEE, 2004).
UNI
No SWEBOK são citados alguns autores com maior aderência à área de software. Dentre os autores citados está Crosby (1979) definindo qualidade como conformidade aos requisitos do usuário, Humphrey como obtenção de excelentes níveis de adequação ao uso e IBM como qualidade orientada ao mercado, na qual a ideia é obtenção da satisfação total do cliente (IEEE, 2004).
Uma série de recomendações para a melhoria da qualidade de software pode ser encontrada no SWEBOK. Estas formas são divididas nas categorias estática e dinâmica. As formas estáticas não requerem a execução do software avaliado e as dinâmicas são baseadas na execução do software (IEEE, 2004).
Se analisarmos o capítulo que trata de qualidade de software, podemos observar que ele está estruturado da seguinte forma (IEEE, 2004):
• Fundamentos de qualidade de software.
• Processos de gerenciamento da qualidade de software.
• Considerações práticas.
FIGURA 17 – ESTRUTURA DA QUALIDADE DE SOFTWARE
UNIDADE 3 | QUALIDADE DE SOFTWARE
128
Na seção que trata dos fundamentos de qualidade de software o conceito importante que deve ser compreendido é que os requisitos de software definem as características da qualidade de software e influenciam os métodos de medição e critérios de aceitação (IEEE, 2004).
A seção que trata dos processos de gerenciamento da qualidade de software foca no quanto o produto de software satisfaz os requisitos dos usuários, agrega valor aos envolvidos e possui níveis de qualidade necessários para atender aos requisitos de software.
O processo de gerenciamento da qualidade de software consiste de uma série de atividades. Algumas visam encontrar defeitos e indicar onde seria recomendável realizar uma análise mais criteriosa. No planejamento da qualidade são definidos os requisitos de qualidade do produto e os processos para obtenção de tal produto.
Já a seção das considerações práticas relacionam recomendações sobre os requisitos da qualidade de software, caracterização de defeitos, técnicas de gerenciamento da qualidade de software e medição da qualidade de software. Em relação à medição da qualidade de software os indicadores são destacados como forma de explicitar a aderência aos padrões estabelecidos.
Seguindo a linha das definições e entendimentos de pesquisadores sobre qualidade de software Bartiè (2002) traz a seguinte contribuição. Para ele qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos.
Já Pressman (1995) entende que um software de qualidade é aquele que foi construído com base em padrões de desenvolvimento devidamente documentados, que esteja em conformidade com os requisitos funcionais e que atenda aos requisitos não funcionais declarados de maneira explícita.
Complementando seu conceito, Pressman (1995) indica que há três pontos importantes que devem ser observados:
• Os requisitos são a base para a qualidade.
• Os padrões de engenharia especificados devem ser seguidos.
• Os requisitos implícitos devem ser considerados e seguidos.
Uma das formas mais simples de medir a qualidade de software é contra os requisitos. Se os requisitos não forem especificados de maneira correta, a qualidade será comprometida. Qualquer software que seja construído sem que haja uma definição clara de seus requisitos terá alta probabilidade de problemas de qualidade durante seu ciclo de vida.
TÓPICO 1 | INTRODUÇÃO À QUALIDADE DE SOFTWARE
Quando somos levados a utilizar normas e padrões logo acreditamos que para segui-las precisaremos atender a uma extensa lista de atividades. Na realidade as normas e padrões que serão seguidos são definidos pela equipe. Os padrões de engenharia de software utilizados por uma equipe de desenvolvimento são definidos pela própria equipe.
Ao realizar a definição de processos de engenharia de software é importante ter foco em simplicidade e eficiência. Se o processo começar a ficar complexo, pode ser que a solução que está sendo desenhada não seja aplicável. Se essa premissa for seguida, os padrões definidos serão mais eficientes.
3 MELHORIA DA QUALIDADE
A melhoria da qualidade é uma questão cada vez mais latente na área de Engenharia de Software. À medida que aumenta a dependência das organizações por aplicações de software para realização de suas atividades, aumenta também a criticidade da falta deles. É muito crítico deixar uma unidade de negócios sem operar por falhas de software.
Esta questão está em discussão na Engenharia de Software e também em diversas áreas de negócios. A aceitação do conceito de que o processo de produção tem um grau de relevância representativo no resultado final, tem aumentado (GHEZZI, 2003).
Na Engenharia de Software os processos são um importante pilar. A Engenharia de Software está apoiada no tripé: pessoas, processos e tecnologias.
Os processos são importantes para facilitar uniformidade de desempenho no desenvolvimento de diversos projetos, permitindo redução de custos e do tempo de entrega.
Processos também tem alto grau de influência sobre a qualidade dos resultados do desenvolvimento de software. Esta influência está relacionada ao controle realizado nos processos. Os controles deve permitir obter maior domínio sobre a qualidade necessária para os softwares (GHEZZI, 2003).
UNIDADE 3 | QUALIDADE DE SOFTWARE
130
A finalidade destas normas e modelos é permitir a avaliação da qualidade do processo de software e realizar melhorias. A partir daí, as organizações poderão tornar-se mais competitivas disponibilizando produtos e serviços com patamares de qualidade reconhecidos nacional e internacionalmente.
No Brasil pode ser observado crescimento considerável no número de empresas que realizaram avaliações oficiais do CMMI nos últimos anos. Uma das principais evidências é o relatório publicado em agosto de 2006 pelo Ministério da Ciência e Tecnologia.
A curva de evolução das organizações com qualificação CMMI no Brasil até agosto de 2006 pode ser observada na figura a seguir. A figura demonstra que apenas no ano de 2003 houve a primeira avaliação CMMI oficial por uma empresa brasileira.
FIGURA 18 – QUANTIDADE DE ORGANIZAÇÕES COM QUALIFICAÇÃO CMMI NO BRASIL
FONTE: MCT, 2006
Pode-se observar também que em 2005 havia 17 empresas avaliadas e em 2006 já eram 21. Apesar deste crescimento, o número de empresas brasileiras avaliadas formalmente ainda é baixo em comparação com outros países. Uma das possíveis explicações pode estar na existência do modelo MPS.BR que é focado na realidade brasileira.
O que pode ser observado também é que a maioria das empresas está concentrada em avaliações em níveis mais baixos de maturidade. A pesquisa do MCT (2006) demonstra que existem 52% de avaliações no nível 2 do CMMI, 19%
no nível 3 e apenas 21% nos demais níveis.
TÓPICO 1 | INTRODUÇÃO À QUALIDADE DE SOFTWARE
FIGURA 18 – QUANTIDADE DE ORGANIZAÇÕES COM QUALIFICAÇÃO CMMI NO BRASIL
Porém se observarmos as tendências mundiais, estas estão em linha com a realidade apresentada nas empresas brasileiras. Dados do SEI (2007) demonstram que 40% das empresas foram avaliadas no nível 2 de maturidade, 37% no nível 3 de maturidade e os demais 23% distribuídos nos demais níveis.
Na pesquisa do SEI (2007) pode-se observar também que a concentração nos níveis de maturidade mais baixos é ainda mais acentuada nas micro e pequenas empresas. Esta concentração pode ser considerada natural, pois micro e pequenas empresas tipicamente ainda estão em níveis de maturidade inferiores.
E a maturidade será conquistada com o tempo e experiência.
Os atuais modelos de melhoria de processos de software propõem que empresas com níveis de maturidade baixa iniciem o processo de melhoria de seus processos em áreas chave. As principais áreas de processos que devem ser priorizadas são gerência de projetos e medição.
Com a melhoria de processos da gerência de projetos e medição, acredita-se que as empresas de software possam melhorar suas práticas de planejamento, monitoração e controle de seus projetos. Acredita-se também que adquiram
Com a melhoria de processos da gerência de projetos e medição, acredita-se que as empresas de software possam melhorar suas práticas de planejamento, monitoração e controle de seus projetos. Acredita-se também que adquiram