A importância da qualidade de software

Conceitos fundamentais de qualidade

Para entendermos melhor os conceitos fundamentais que envolvem a área de qualidade de software, faremos uma pequena introdução sobre a importância da aplicação dos conceitos da qualidade e seu contexto dentro dos ambientes de desenvolvimento de software.

A influência do software sobre nós

Fonte: sdecoret / Shutterstock

A influência que produtos de software têm sobre nós, tanto nos aspectos profissionais quanto nos pessoais, é muito grande e se dá através de facilidades advindas de produtos diversos, como editores de texto, planilhas de cálculo, aplicativos de comunicação e de serviços através da internet, usando dispositivos móveis ou computadores de mesa. Para quem trabalha no desenvolvimento destes sistemas e aplicativos, o maior desafio é criar um produto de software com elevada produtividade dentro do prazo estabelecido, sem necessitar de mais recursos do que aqueles previstos, assegurando que atenda às necessidades do cliente e que seja confiável... em suma: que seja produzido um software de qualidade.

Apesar do reconhecimento em relação às facilidades que os produtos de software nos proporcionam, notadamente na área financeira e de telecomunicações, ainda há muito o que melhorar na qualidade dos produtos de software desenvolvidos.

Neste contexto, a aplicação eficaz e eficiente da engenharia de software é fundamental para aprimorar a qualidade dos produtos, diminuindo seus custos de desenvolvimento, aumentando a produtividade e reduzindo o tempo de atendimento ao mercado.

O fato de o desenvolvimento de produtos de software não ser um procedimento repetitivo torna a garantia da qualidade uma atividade difícil e, muitas vezes, imprevisível. A delimitação do escopo de sistemas e/ou produtos de software também não é uma tarefa trivial. Muitas vezes o usuário não consegue definir com precisão todos os requisitos necessários ao projeto. Além disso, ainda existe a volatilidade dos requisitos, que representa um aspecto muito comum no desenvolvimento de software.

Todo este cenário faz com que a importância da área de garantia da qualidade cresça continuamente nas organizações de desenvolvimento de software, pois a gerência de alto nível utiliza os resultados produzidos por esta área para obter visibilidade da qualidade dos processos executados e dos produtos entregues aos clientes. Além disso, decisões estratégicas de negócio são tomadas com base em dados consolidados das atividades de garantia da qualidade. Estes e outros fatores aumentam a complexidade e a relatividade do conceito de qualidade de software devido à sua forte dependência da perspectiva de quem está avaliando determinado produto ou serviço.

Para se obter software de alta qualidade devem ocorrer quatro atividades: processo e prática comprovados de Engenharia de Software , gerenciamento consistente de projetos, controle global de qualidade e presença de uma infraestrutura para garantir a qualidade. Para garantir que o trabalho foi realizado corretamente, a qualidade deve ser medida, os resultados de todas as atividades de controle de qualidade devem ser verificados e os erros e eventuais defeitos devem ser checados antes da entrega.

Fonte: PRESSMAN (2011, p. 358)

Em busca da obtenção de software de alta qualidade, normalmente as organizações definem padrões, processos e procedimentos que devem ser seguidos para assegurar a uniformidade e o controle com relação ao desenvolvimento e à manutenção de software. Esses padrões podem incluir especificação, documentação, revisões, auditorias e padrões de engenharia de software que geralmente encontram-se especificados em um plano de garantia da qualidade.

Área de garantia de qualidade.
Fonte: Cristina Dumitru / Shutterstock

A área de garantia da qualidade é constituída por um conjunto de atividades sistemáticas que fornecem evidência da capacidade do processo de software de desenvolver um produto que atenda aos seus propósitos. Este conjunto de atividades que compõem a área de garantia da qualidade é tratado como atividades de um processo de apoio na implantação de outros processos e na elaboração e avaliação de produtos de trabalho gerados por estes processos. No entanto, a execução de atividades para atingir graus elevados de qualidade em produtos e processos de software requer a aplicação de muitos recursos.

Mas, o termo qualidade não pode ser confundido com perfeição, pois qualidade é algo que pode-se conquistar através de adequações do produto sendo desenvolvido aos objetivos que se pretende atingir. Assim, o mais importante é que se busque alcançar o nível de qualidade que garanta o funcionamento correto do produto, dentro dos padrões almejados pelos usuários ou clientes.

O principal objetivo da garantia da qualidade é assegurar que padrões, procedimentos e políticas utilizados durante o desenvolvimento do software sejam adequados para prover o nível de confiança requerido para o processo ou produto de trabalho. No entanto, este nível de confiança varia de acordo com os diferentes tipos de usuários dos produtos de software, bem como o grau esperado de adequação do produto aos propósitos para os quais foi desenvolvido. Portanto, deve-se considerar que usuários diferentes provavelmente terão propósitos diferentes para o desenvolvimento de um mesmo produto.

Como realizar avaliações da capacidade do processo

De acordo com o padrão ISO/IEC 15504, que trata dos níveis de maturidade para desenvolvimento de software, as avaliações da capacidade do processo podem ser realizadas visando atingir diferentes objetivos e com graus de profundidade e rigor diferenciados.

Esses objetivos podem ser de interesse interno à organização, quando áreas da empresa são comparadas, ou de interesse interno e externo, quando a intenção é realizar uma análise de melhoria no processo, com geração de relatórios e certificações formais dos processos.

Na visão da ISO/IEC 15504, a abordagem para a avaliação do COBIT 5 baseia-se em objetivos que têm sido priorizados desde as primeiras versões, lançadas a partir do ano 2000. Esses objetivos, de acordo com a ISACA (2012, p. 47), são:

• Permitir que o órgão de governança e a administração avaliem o desempenho da capacidade do processo.
• Permitir verificar a situação atual dos processos (as is) e a situação futura e desejada (to be), de forma a dar suporte à tomada de decisão em relação à melhoria do processo pelas entidades de governança e pela administração.
• Contribuir para a realização de análises de falhas e fornecer informações para que possam ser feitos os planejamentos de melhorias justificáveis, dentre os quais estão os planos de ações e as adequações no processo.
• Oferecer formas de as entidades de governança e a administração classificarem as avaliações com o objetivo de medir e monitorar as capacidades atuais e definir ações para que a classificação almejada possa ser alcançada.

Conforme a ISACA (2012, p. 48), a avaliação de um processo para verificar se este atinge seus objetivos, ou seja, atinge a capacidade nível 1, pode ser feito de algumas maneiras:

[1] Analisando os resultados do processo conforme a descrição detalhada dele e utilizando a escala de classificação ISO/IEC 15504 para atribuir uma classificação ao grau de consecução de cada objetivo. A escala é formada pelas seguintes avaliações:

• N (não atingido): há pequena ou nenhuma evidência do atingimento de atributos definidos no processo avaliado (0% a 15 %).
• P (parcialmente atingido): há pouca evidência da abordagem e baixo atingimento do atributo definido no processo avaliado. Alguns aspectos do atingimento do atributo podem ser imprevisíveis (15% a 50%)
• L (amplamente atingido): há evidência da abordagem sistemática e atingimento significativo do atributo definido no processo avaliado. Alguns pontos fracos referentes a ele podem existir no processo avaliado (50% a 85%).
• F (plenamente atingido): há evidência da abordagem completa e sistemática e pleno atingimento do atributo definido no processo avaliado. Não existe nenhum ponto fraco significativo referente a ele no processo avaliado (85% a 100%).

[2] Utilizando a mesma escala de avaliação, que expressa em qual medida as práticas básicas foram aplicadas.

[3] Determinando em qual medida um atributo de avaliação específico foi atingido.

Embora cada organização tenha a liberdade de definir quais dos níveis de capacidade deseja atingir, a maior parte delas certamente vislumbrará que todos os seus processos atinjam a capacidade nível 1.

Se a capacidade de nível 1 não for atingida, os motivos do não atingimento ficam imediatamente evidentes a partir das três maneiras explicadas, e um plano de melhoria poderá ser definido, seguindo as seguintes premissas:

• Caso o resultado do processo não tenha sido atingido de forma consistente, o processo não alcançará seu objetivo e terá que passar por melhorias.
• A revelação de quais práticas estão faltando ou falhando, a partir da avaliação das práticas do processo, permitirá a adoção de melhorias, de forma que todos os resultados do processo possam ser alcançados.

Para níveis de capacidade de processo acima de 1, as práticas utilizadas devem ser obtidas do padrão ISO/IEC 15504, que oferece descrições genéricas para cada um dos níveis que a organização almeja alcançar.

Diferenças entre o modelo de maturidade do COBIT 4.1 e do modelo de capacidade do COBIT 5

 O COBIT 4.1 e o COBIT 5 apresentam modelos bem distintos de avaliação de processos. Uma forma de ampliar o entendimento entre eles é comparando-os. Vamos fazer umas considerações sobre suas diferenças na teoria e na prática.

De acordo com a ISACA (2012, p. 43-44), as principais diferenças entre o modelo de maturidade do COBIT 4.1 e a avaliação de capacidade de processo do COBIT 5 são:

• A nomenclatura e o significado dos níveis de capacidade definidos para o COBIT 5, com base na ISO/IEC 15504, são diferentes dos níveis de maturidade dos processos do COBIT 4.1.
• No COBIT 5, baseado na ISO/IEC 15504, os níveis de capacidade são definidos por um conjunto de nove atributos de processo. Estes abrangem alguns fundamentos cobertos pelos atributos de maturidade e/ou pelos controles de processos do COBIT 4.1, mas somente até um certo ponto e de uma forma diferente.

Em relação aos atributos, a tabela apresenta um comparativo entre os atributos de maturidade do COBIT 4.1 e os atributos de processo do COBIT 5.

Comparação entre atributos de maturidade do COBIT 4.1 e atributos de processo do COBIT 5

Fonte: ISACA (2012, p. 47).

Na prática, com certeza há importantes reflexos relativos às mudanças nos modelos de avaliação de processo. Algumas delas, conforme a ISACA (2012, p. 45), são:

• As escalas de avaliação, embora apresentem seis níveis, tanto no COBIT 4.1 quanto no COBIT 5, são muito distintas em relação a escopo, foco e intenção.
• No modelo de maturidade do COBIT 4.1, um processo poderia atingir o nível 1 ou 2 sem completar plenamente todos os objetivos do processo; no nível de capacidade de processo do COBIT 5, isso resultaria em uma avaliação mais baixa, como nível 0 ou nível 1.
• No COBIT 5, não há mais um modelo de maturidade específico por processo no conteúdo do processo detalhado porque a abordagem da avaliação da capacidade de processo ISO/IEC 15504, no qual o método se baseia, além de não exigir isso, proíbe essa abordagem.
• Os atributos de maturidade do COBIT 4.1 e os atributos de capacidade de processo do COBIT 5 não são idênticos, conforme foi mostrado na tabela 2. Esses atributos sobrepõem-se ou podem ser mapeados até certo ponto. As organizações que utilizam a abordagem dos atributos do modelo de maturidade do COBIT 4.1 podem reutilizar os atuais dados da sua avaliação e reclassificá-los segundo as avaliações de atributos do COBIT 5.

O modelo de maturidade do COBIT 4.1 produziu um perfil de maturidade, com o objetivo de identificar em quais dimensões ou para quais atributos havia pontos fracos específicos que necessitavam de melhorias em uma organização. Esta abordagem foi utilizada quando havia um foco na melhoria sem necessariamente ter que se obter um número de maturidade para fins de relatório. No COBIT 5, o modelo de avaliação de processos trabalha em uma escala de medição para cada atributo de capacidade e fornece orientações sobre como aplicá-la. Assim, uma avaliação pode ser feita para cada um dos nove atributos de capacidade para cada processo escolhido pela organização.
Fonte: ISACA (2012, p. 45).

As escalas de maturidade do COBIT 4.1 e as escalas de capacidade do COBIT 5 podem ser consideradas para um mapeamento aproximado, conforme mostra o quadro.

Comparação entre níveis de maturidade do COBIT 4.1 e níveis de capacidade do COBIT 5

Nível do Modelo de Maturidade de COBIT 4.1	Capacidade de Processo com Base no ISO/IEC 15504	Contexto
5 Otimizado - Os processos foram refinados ao nível de boa prática, com base nos resultados de melhorias contínuas e modelagem da maturidade com outras organizações. TI é aplicada de forma integrada para automatizar o fluxo de trabalho, oferecendo ferramentas para melhoria de qualidade e da eficácia, fazendo com que a organização se adapte rapidamente.	Nível 5: Processo Otimizado - O processo previsível, nível 4, é continuamente melhorado de modo a atender os objetivos corporativos pertinentes, atuais ou previsots.	Visão da Organização Conhecimento Corporativo
4 Controlado e Mensurável - A administração monitora e mede a conformidade com os procedimentos e toma medidas quando parecer que os processos não estão funcionando efetivamente. Os processos estão em constante melhoria e resultam em boas práticas. Automação e ferramentas são utilizadas de maneira limitada ou fragmentada.	Nível 4: Processo Previsível - O processo Estabelecido, nível 3, opera agora com limites definidos, atingidos nos resultados do processo.
3 Processo Estabelecido - Os procedimentos foram padronizados, documentados e comunicados por meio de treinamento. Seguir esses processos é obrigatório no entanto, é impossível que os desvios sejam detectados. Os procedimentos por si só, não são sofisticados, mas são a formalização das práticas existentes.	Nível 3: Processo Estabelecido - O proceosso Gerenciado, nível 2, é agora implementado usando um processo definido capaz de atingir os resultados do processo.
	Nível 2: Processo Gerenciado - O processo Executado, nível 1, é agora implementado de forma gerenciada (planejado, monitorado e ajustado) e seus produtos do trabalho são adequadamente estabelecidos, controlados e mantidos.	Visão de Instância Conhecimento individual
2 Repetível, mas intuitivo - Os processos se desenvolveram até o estágio em que procedimentos semelhantes são adotados por diferentes pessoas que realizam o mesmo trabalho. Não há treinamento formal ou comunicação de procedimentos padrão e a responsabilidade fica a critério do indivíduo. Há um alto grau de confiança no conhecimento das pessoas e, portanto, erros são possíveis.	Nível 1: Processo Executado - O processo implementado atinge a finalidade do processo. Observação: É possível que alguns processos classificados como Modelo de Maturidade Nível 1 sejam classificados como nível 0 na ISO/IEC15504, se os resultados do processo não forem alcançados.
1 Inicial/Ad hoc - Há evidências de que a organização tenha reconhecido a existência de problemas que deveriam ser tratados. Contudo, não há processos padronizados; em vez disso, há abordagens ad hoc, que tendem a ser aplicadas individualmente ou com base em cada caso. A abordagem geral da gestão é desorganizada.
0 Inexistente - Completa falta de processos reconhecíveis. A organização nem sequer reconheceu que existe um problema a ser tratado.	Nível 0: Processo incompleto - O processo não foi implementado ou não cumpre sua finalidade

Fonte: ISACA (2012, p. 46).

Benefícios do modelo de capacidade de processo do COBIT 5 quando comparado com o modelo de maturidade do COBIT 4.1:

• Maior ênfase no processo que está sendo realizado para confirmar que está efetivamente alcançando seus objetivos e os resultados esperados.
• Simplificação do conteúdo por meio da eliminação da duplicação, porque a avaliação do modelo de maturidade do COBIT 4.1 exigia o uso de diversos componentes específicos, inclusive modelo de maturidade genérico, modelos de maturidades do processo, objetivos de controle e controles de processo, para apoiá-la.
• Maior confiabilidade e repetitividade das atividades e das análises da avaliação da capacidade do processo, reduzindo debates e desentendimentos entre as partes interessadas em relação aos resultados da avaliação.
• Maior uso dos resultados da avaliação da capacidade do processo, visto que o novo modelo estabelece uma base para a realização de avaliações mais rigorosas e formais, tanto para finalidades internas como externas em potencial.
• Conformidade com um padrão de avaliação de processo geralmente aceito e, portanto, um forte apoio à abordagem de avaliação do processo no mercado (ISACA, 2012, p. 47).

O modelo de capacidade do COBIT 5

O modelo de capacidade de processo do COBIT 5 tem como base o padrão de Avaliação de Processo – Engenharia de Software ISO/IEC 15504, que é reconhecido internacionalmente.

Esse modelo busca atingir os mesmos objetivos gerais de avaliação e apoio à melhoria do processo, proporcionando meios para medir o desempenho de qualquer um dos processos de governança (baseados em EDM) ou de gestão (baseados em PBRM), permitindo a identificação das áreas que precisam ser melhoradas.

De acordo com a ISACA (2012, p. 44), um processo pode atingir seis níveis de capacidade, incluindo uma designação de processo incompleto, caso suas práticas não atinjam o objetivo. Esses níveis são:

[0] Nível 0 - Processo incompleto: o processo não foi implementado ou não atingiu seu objetivo. Nesse nível, há pouca ou nenhuma evidência de qualquer atingimento sistemático do objetivo do processo.

[1] Nível 1 - Processo executado (um atributo): o processo implementado atinge seu objetivo.

[2] Nível 2 - Processo gerenciado (dois atributos): o processo realizado descrito no nível 1 agora é implementado de forma administrativa (planejado, monitorado e ajustado), e seus produtos do trabalho são adequadamente estabelecidos, controlados e mantidos.

[3] Nível 3 - Processo estabelecido (dois atributos): o processo controlado descrito no nível 2 agora é implementado utilizando um processo definido capaz de atingir seus resultados.

[4] Nível 4 - Processo previsível (dois atributos): o processo criado descrito no nível 3 opera agora dentro dos limites definidos para produzir seus resultados.

[5] Nível 5 - Processo otimizado (dois atributos): o processo previsível descrito no nível 4 é continuamente melhorado visando ao atingimento dos objetivos corporativos pertinentes, atuais ou previstos.

Modelo de capacidade de processo do COBIT 5
Fonte: ISACA (2012, p. 44).

No COBIT 5, cada nível de capacidade só pode ser atingido quando o nível anterior tiver sido plenamente alcançado.

Caro aluno, observe que há uma diferença significativa entre a capacidade de processo nível 1 e os níveis superiores, de 2 a 5. Para atingir a capacidade nível 1, é necessário que o atributo de desempenho do processo seja amplamente atingido: isso significa que ele está sendo realizado com sucesso e que os resultados esperados estão sendo obtidos pela organização. A partir disso, os níveis de capacidade mais altos adicionam diferentes atributos a ele. Nesse esquema de avaliação, atingir a capacidade nível 1, mesmo em uma escala de 5, já pode ser considerada uma conquista muito relevante para a organização!

A grande flexibilidade desse modelo reside no fato de que cada organização pode definir, com base em critérios próprios, como custo-benefício e viabilidade, sua meta ou seu nível desejado. Na realidade, muito raramente a organização almeja de imediato níveis de capacidade mais altos. A abordagem da capacidade de processo do COBIT 5 pode ser resumida conforme mostra o gráfico 17.

Vejamos um exemplo: uma capacidade de processo nível 3 (processo criado) exige que a definição do processo e os seus atributos de implantação sejam amplamente atingidos depois que a capacidade dos atributos de processo do nível 2 forem atingidos (processo controlado).

Modelo de maturidade do COBIT 4.1

O COBIT 4.1 lida com as três necessidades elencadas, pois oferece às organizações que buscam um modelo de governança de TI:

• um modelo de maturidade, que permite que comparações sejam feitas, de forma a identificar as capacidades que precisam ser aprimoradas;
• objetivos de desempenho e métricas para os processos de TI, que mostram como os processos podem atingir os objetivos de negócios e de TI e como são utilizados para medir o desempenho dos processos internos, com base no BSC;
• objetivos de atividades, que habilitam os processos a atingir seu desempenho efetivo.

Modelo de maturidade do COBIT 4.1
Fonte: ITGI (2007, p. 22).

De acordo com o ITGI (2007, p. 22), o modelo de maturidade para o gerenciamento e controle dos processos de TI do COBIT 4.1 é baseado em um método de avaliar a organização, permitindo que ela seja pontuada de um nível de maturidade não existente (0) a um otimizado (5). Esse enfoque é derivado do modelo de maturidade do CMMI/SEI, definido para a maturidade da capacidade de desenvolvimento de software. O gráfico 16 ilustra esse processo.

Embora siga os conceitos do CMMI/SEI, a implementação do COBIT 4.1 difere deste, pois uma definição genérica é provida para as escalas de maturidade, que são similares às do CMMI, mas interpretadas de acordo com a natureza dos processos de gerenciamento de TI. Além disso, não há intenção de se medir os níveis de maneira precisa ou tentar certificar que aquele nível foi exatamente atingido (ISACA, 2012, p. 19).

Os níveis de maturidade são designados como perfis de processos de TI que a empresa reconheceria como descrição de possíveis situações atuais e futuras. Eles não são designados como um modelo inicial, em que não se pode avançar para o próximo nível sem antes ter cumprido todas as condições do inferior (ISACA, 2012, p. 19).

Esse modelo foi desenvolvido com uma ênfase forte em controles. A vantagem de uma abordagem de modelo de maturidade é a relativa facilidade de os gerentes colocarem a si mesmos em uma escala e avaliar o que está envolvido no aprimoramento da performance, se necessário. A escala inclui o zero, pois é possível que um processo não exista de fato (ISACA, 2012, p. 20).

O modelo de maturidade é uma forma de medir quão bons os processos de gerenciamento são, ou seja, quão capazes eles são. O quanto eles devem ser desenvolvidos ou capacitados deveria primariamente depender dos objetivos de TI e sua conexão com as necessidades de negócios que suportam (ISACA, 2012, p. 21).

É importante ressaltar que os controles a ser aplicados a cada um dos processos devem considerar dois aspectos principais: o apetite de risco da organização e os requisitos de conformidade que sejam aplicáveis.

Cabe aqui uma breve explicação sobre apetite de risco que, de acordo com o site Stakeholder News (2014), é definido como

o apetite de risco é o grau de incerteza que a entidade está disposta a assumir, em antecipação de uma recompensa. O apetite de risco de uma organização mostra o quanto uma organização está disposta a assumir um risco, a fim de crescer. É a quantidade de risco que uma organização está disposta a aceitar para atingir seu objetivo de negócios.

Os níveis da escala do modelo de maturidade do COBIT 4.1 ajudarão os profissionais de TI a indicar aos gerentes onde se encontram as deficiências no gerenciamento do processo e a, juntos, definir as metas para onde devem ir. O nível de maturidade é influenciado pelos objetivos de negócios e pelo ambiente operacional da organização, além de pelas práticas do mercado (ITGI, 2007, p. 23).

Em resumo, o modelo de maturidade fornece um perfil genérico de estágios por meio dos quais cada empresa pode evoluir em gerenciamento e controle de processos de TI.

Modelo de capacidade de processo do COBIT

As organizações e sua necessidade de avaliação da área de TI

Toda organização precisa ter uma ampla compreensão da situação de seus recursos e sistemas de TI para ter condições de decidir qual nível de gerenciamento e controle precisa ser implementado. A alta direção e os executivos têm que saber quão bem a área de TI está sendo gerenciada. Para ajudá-los, o ITGI (2007, p. 21), elenca um conjunto de perguntas, dentre as quais se encontram:

• Quanto devemos investir? O custo justificará o benefício?
• O que deve ser feito para conhecermos o nível de desempenho em que a organização se encontra? O que deve ser avaliado e como avaliar?
• Como estão nossos principais concorrentes e como está nossa posição no mercado em relação a eles?
• Quais são as boas práticas que podem causar impacto positivo em nosso negócio e quão distante estamos delas?
• Como podemos identificar, elencar e planejar o que precisa ser feito para que nossa organização atinja um nível adequado de gerenciamento e controle nos processos de TI?

Conseguir respostas corretas e adequadas para essas perguntas não é tarefa fácil. Mas o uso de ferramentas de benchmarking e de autoavaliação pode auxiliar a organização, de forma determinante, a saber o que deve ser feito para que a governança de TI possa ser implementada de maneira eficiente.

Começando a implantação da governança com as boas práticas do COBIT, os processos devem ser selecionados. Para cada processo a ser implementado, seu proprietário poderá gradativamente ampliar as comparações com os objetivos de controle, de forma a atender a três necessidades essenciais:

1. Obter uma medida relativa de onde a organização se encontra.

2. Conseguir determinar caminhos eficientes que levem a organização a decidir para onde ir.

3. Obter uma ferramenta para avaliar o progresso da implementação em relação às metas a ser alcançadas.

Software x Hardware

De acordo com Pressman (2011, p. 32-33), comparar o software com produtos de hardware auxilia na compreensão das diferenças existentes entre eles e enfatiza as características inerentes a um software. O processo de desenvolvimento do software apresenta diferenças fundamentais em relação ao hardware:

Software x Hardware

Fonte: Moon Light PhotoStudio/shutterstock

• O processo criativo do hardware gera algo físico (por exemplo, placas de circuitos). O desenvolvimento de software resulta em um elemento pertencente a um sistema lógico, intangível;
• O software geralmente é desenvolvido sob medida, ao contrário do hardware, no qual o projetista tem acesso a componentes existentes que executam tarefas definidas. O projetista do software nem sempre terá acesso a módulos prontos para utilização e quando o faz, pode elevar o risco do produto devido a questões de segurança;
• Os custos do software estão concentrados no desenvolvimento e não no processo de manufatura, logo, não pode ser gerido como projeto de manufatura;
• Ao longo do tempo, o produto de software não se desgasta, mas se deteriora em função da introdução de erros oriundos de atividades de manutenção ou evoluções implícitas no processo que devem ser reconsideradas no modelo original.

Desta forma, o software sofre deterioração ocasionada por diversos fatores sendo uma característica peculiar do produto. Ainda segundo Pressman (2011), no caso do hardware, temos um alto índice de falhas no início do seu ciclo de vida ocasionado por defeitos de fabricação e projeto. Posteriormente os defeitos são corrigidos, dando estabilidade nas falhas ou mantendo-a em um nível muito baixo e suportável para a estrutura. Já no final do ciclo de vida do produto podem surgir problemas relacionados ao envelhecimento, acúmulo de poeira, vibração, abuso, temperaturas extremas, entre outros. Este processo pode ser visto no gráfico apresentado na figura.

Curva de falhas do hardware. Fonte: PRESSMAN (2011, p. 32)

Diferentemente da curva teórica de falhas do hardware, a de software leva em conta que o software não sofre processos de envelhecimento como o hardware, pois o software não é algo físico. No início do ciclo de vida do software, teremos problemas (bugs) que serão ajustados no decorrer do desenvolvimento e se estabilizarão, gerando uma tendência de achatamento da curva, conforme pode ser visto na figura.

Curva de falhas do software.

Fonte: PRESSMAN (2011, p. 33)

Notemos que esta é apenas uma teoria, já que a curva real do índice de falhas de um software considera o processo de manutenção e mudanças. Durante o processo de refinamento do produto ou mudanças a probabilidade de inserção de novos erros aumenta consideravelmente, gerando picos na curva de falhas. As sucessivas alterações do software tendem a introduzir mais erros antes da estabilização dos erros de alterações anteriores, ocasionando a tendência crescente do índice de falhas.

Isso nos remete a uma realidade bastante complicada em relação ao software: ele é um produto que quanto mais se conserta, pior fica. Um software em constante manutenção pode ser tornar uma espécie de “colcha de retalhos”, gerando pontos de falhas diversos, difíceis de se identificar e de se ajustar. O melhor modelo é o desenvolvimento de um novo produto após o tempo de vida útil do anterior, considerando-se as novas necessidades e tecnologias disponíveis.

Quando o hardware é projetado e construído, os componentes digitais são inseridos em catálogos. A cada circuito integrado ou componente é assinalado um código, uma função definida e validada, uma interface especificada e um conjunto padrão de integração. Uma vez escolhido no catálogo, o componente desejado pode ser adquirido e utilizado em diferentes projetos de hardware, com alta confiabilidade.

No mundo do software, isso é algo que está apenas começando a ser utilizado em uma escala mais ampla, apesar de existirem alguns casos antigos de reuso, como as bibliotecas de subrotinas científicas. Atualmente, a visão de reuso foi ampliada para abranger não apenas algoritmos consagrados, mas também estruturas de dados, interfaces gráficas e diferentes classes e componentes orientados a objetos.