Engenharia de Software

Taiichi Ohno, criador do Sistema Toyota de Produção, escreveu “existe algo chamado trabalho padrão, mas padrões devem ser alterados constantemente. Se você considera o padrão como o melhor que pode fazer, não há avanço”, Ohno prossegue dizendo que, se estabelecermos algo como a “melhor maneira possível, a motivação do kaizen [melhoria contínua incremental] deixará de existir” (1982).

Extraído do Livro Desenvolvimento de Software com SCRUM,

Aplicando Métodos Ágeis com Sucesso.

O Modelo Fabril

Até os anos 80, no Brasil, o processo de desenvolvimento de software caracterizou-se como um processo artesanal. O foco era no fechamento do negócio, precisávamos ganhar dinheiro e programar, custe o que custar. E o cliente? E o retorno do investimento? E o diferencial competitivo no mercado? Pois esta pode ser uma das razões que justificaram o investimento no sistema, na automação.

Este cenário começa a mudar com o surgimento do conceito de FÁBRICA de SOFTWARE. Pois é, o que a grande maioria encara como novidade, surgiu em meados da década de 80 e só foi colocado em pratica em 1993 no mercado paulista.

Antes, conceitos como gerenciamento de projetos e melhoria continua (qualidade), não eram vistos como necessários. Com a inserção no mercado internacional, as normas de qualidade passaram a ser adotadas, possibilitando a prestação de serviço em um mercado globalizado.

Quando me perguntam qual a metodologia que eu uso no processo de desenvolvimento de software, eu respondo com outra pergunta: Você conhece as normas da ABNT?

Objetivos das normas

Estabelecer um idioma internacional, onde todas as empresas falem a mesma língua, no tocante a gestão da qualidade.

…“facilitando a compreensão mútua no comércio nacional e internacional”. (ABNT NBR ISO 9000:2005)

Começamos a leitura da norma pelo item generalidades e podemos destacar o seu objetivo:

…“apoiar organizações, de todos os tipos e tamanhos, na implementação e operação de sistemas de gestão da qualidade EFICAZES”.

Nosso primeiro questionamento: Gerir a qualidade ou gerir com qualidade? Será que uma coisa depende da outra?

Neste ponto gostaria de chama a atenção para dois pequenos termos mais com um significado imenso:

• Eficaz
• Qualidade

Quanto ao primeiro recorrendo ao dicionário encontramos os seguintes significados:

Eficaz: que efetua o que promete ou o que se espera; que causa o resultado inicialmente pretendido, dicionário Priberam. No Aurélio encontramos como significado, aquele que produz o efeito esperado, que dá resultado.

Para definirmos qualidade recorremos ao processo de formação das normas, buscando os primeiros conceitos, em normas que atualmente já foram substituídas, mas que fundamentaram todo o processo, num clima nostálgico.

Qualidade: segundo antiga norma NBR ISO 8402 de 1993, que tratava da gestão da qualidade e garantia da qualidade, registramos o seguinte:

“Qualidade é a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”.

Trazendo estes conceitos para o nosso universo, o universo do desenvolvimento de sistemas, da engenharia de software. Na relação comercial com nossos clientes, que nos contrataram em busca de soluções tecnológicas que automatizem seus processos produtivos, de controle, científicos, matemáticos, financeiros, e uma série de outras atividades, que englobam as mais variadas áreas do conhecimento e de negócio, o que eles esperam de nós?

Baseados no significado do termo EFICAZ, poderíamos afirmar que o cliente quando nos contrata, ele espera que os resultados inicialmente pretendidos sejam atingidos, foco nas suas requisições no entendimento do negócio. Com relação ao conceito de qualidade, que disponibilizemos ”a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”, superando as suas expectativas.

Chegamos a conclusão que para mantermos uma relação saudável com o cliente de fato precisamos implantar um sistema coerente que apoie os nosso processos interno de produção, apoiados nas normas de qualidade, cada organização segundo as suas características, tirando o máximo proveito da norma:

…“apoiar organizações, de todos os tipos e tamanhos, na implementação e operação de sistemas de gestão da qualidade EFICAZES”.

Quando nos envolvemos em um projeto, em que momento nos lembramos desta definição: 

“Qualidade é a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”?.

Olha o Aurélio aí de novo, na definição do termo qualidade: 

“Superioridade, excelência em qualquer coisa”…

Vamos conhecer um pouco sobre a família ISO:

ABNT NBR ISO/IEC 14102:2002

Tecnologia de informação - Orientação para avaliação e seleção de ferramentas CASE

ABNT ISO/IEC TR 14471:2003

Tecnologia da informação - Engenharia de software - Orientação para adoção de ferramentas CASE

ABNT NBR ISO/IEC 9126-1:2003

Engenharia de software - Qualidade de produto Parte 1: Modelo de qualidade

ABNT NBR ISO/IEC 14598-2:2003

Engenharia de software - Avaliação de produto Parte 2: Planejamento e gestão

ABNT NBR ISO/IEC 14598-3:2003

Engenharia de software - Avaliação de produto Parte 3: Processo para desenvolvedores

ABNT NBR ISO/IEC 14598-4:2003

Engenharia de software - Avaliação de produto Parte 4: Processo para adquirentes

ABNT NBR ISO/IEC 14598-5:2001

Tecnologia de informação - Avaliação de produto de software Parte 5: Processo para avaliadores

ABNT NBR ISO/IEC 14598-6:2004

Engenharia de software - Avaliação de produto Parte 6: Documentação de módulos de avaliação

ABNT ISO/IEC TR 24774:2010

Engenharia de software e de sistemas — Gerenciamento de ciclo de vida — Orientações para descrição de processos

ABNT NBR ISO/IEC 25000:2008

Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE

ABNT NBR ISO/IEC 25001:2009 

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Planejamento e gestão

ABNT NBR ISO/IEC 25020:2009 

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Guia e modelo de referência para medição

ABNT NBR ISO/IEC 25030:2008

Engenharia de software - Requisitos e Avaliação da Qualidade de Produto de Software (SQuaRE) - Requisitos de qualidade

ABNT NBR ISO/IEC 25051:2008

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instruções para teste

ABNT NBR ISO/IEC 25062:2011

Engenharia de software — Requisitos e avaliação da qualidade de produto de software (SQuaRE) — Formato comum da indústria (FCI) para relatórios de teste de usabilidade

A implantação do sistema de gestão da qualidade nos permite dirigir e controlar a organização de maneira transparente e sistemática. Mas é preciso entendê-la como um único organismo, visão holística, esta visão tem que ser clara para quem a administra. E podemos começar com pequenos passos como a melhoria continua, aferindo o desempenho, atendendo as necessidades de todos os envolvidos, ou seja, mapeando os processos. O foco está na disciplina e na gestão da qualidade.

Oito princípios orientam a alta direção na implantação do processo de gestão da qualidade. A norma frisa alta direção, pois existe a necessidade da conscientização para a qualidade da diretoria, quem de fato decide ou não sobre a implantação. Não nos deixemos enganar! Para implantarmos o sistema de gestão da qualidade, é preciso que a alta direção esteja consciente da necessidade. Essa é a maneira mais eficaz.

Os oito princípios de gestão da qualidade são:

1. Foco no cliente
2. Liderança
3. Envolvimento de pessoas
4. Abordagem de processo
5. Abordagem sistêmica para a gestão
6. Melhoria contínua
7. Abordagem factual para tomada de decisão
8. Benefícios mútuos nas relações com os fornecedores

Foco no cliente

Já paramos para pensar na grande responsabilidade quando lidamos com os investimentos de terceiros? Quando o cliente nos confia a automação de processos, o desenvolvimento de um produto ou o fornecimento de qualquer bem que agregue valor ao seu negócio. Qual o seu objetivo? Do esforço do investimento o que ele espera? Aumentar o lucro? Reduzir seus custos? Ou a simples automação de tarefas que aumente a sua produtividade? Que por consequência aumenta o seu lucro e reduz os seus custos. Diversas são as possibilidades e cada uma, relacionada com o ramo de atividade da organização. Porém o nosso foco deverá sempre está voltado em atender as necessidades do cliente, agregando valor ao seu negócio.

“Organizações dependem de seus clientes e, portanto, convém que entendam as necessidades atuais e futuras do cliente, os seus requisitos e procurem exceder as suas expectativas”. (ABNT NBR ISO 9000:2005)

Novamente em nosso universo, Pressman, em seu famoso livro Engenharia de Software, 

“Qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido”.

Aumentou a nossa responsabilidade…

Podemos também dizer que qualidade é estar em conformidade com especificações, ou seja, quando os produtos possuem as características que estão descritas no projeto, catálogos ou listas de especificações.

Mais um questionamento: Entendemos o que nos foi confiado a desenvolver?

Liderança

É função precípua das lideranças manterem o ambiente interno voltado para os objetivos organizacionais. Amadores cansam o mercado com seus engodos, gerando a falsa impressão que realizaram algo de bom e produtivo para as empresas. O bom líder deve focar:

• Na unidade de propósito
• No rumo da organização.
• Nos objetivos da organização.

Envolvimento das Pessoas

A valorização do quadro funcional: investimento na capacitação, valorizando todos os profissionais que fazem parte da organização é uma prática fundamental para o sucesso nos projetos. Pois elas são a essência da organização, e me refiro a todo o quadro funcional, a todos os níveis hierárquicos. Um funcionário insatisfeito pode gerar prejuízos para a organização. Lembro-me de uso caso contado por um empresário argentino, onde um dos seus funcionários que trabalhava na distribuição das correspondências estava insatisfeito com o seu salário, e teve o pedido de reajuste salarial negado, adotou com procedimento jogar no lixo todas as correspondências referentes a participação em licitação. Resumindo a empresa teve grandes prejuízos, mas felizmente a atitude do funcionário foi descoberta a tempo.

Abordagem de Processo

A visão de processo nos direciona ao sucesso, pois atingimos os resultados esperados com mais eficiência. As atividades e os recursos fazem parte da visão. Todo é processo, tudo tem que estar completamente mapeado, controlado, gerido.

Abordagem sistêmica para gestão.

Os processos inter-relacionados na empresa dever ser identificados, entendidos e gerenciados, contribuindo para realização dos objetivos da organização com eficiência e eficácia.

Melhoria contínua

Se acreditarmos que não precisamos mudar mais nada na organização, alguma coisa está muito errada. O conceito de melhoria continua faz parte do universo da Qualidade, pois esta ligado ao desempenho global da organização, que deve ser medido sistematicamente e só desta forma conseguiremos atingir permanentemente os objetivos da organização.

Abordagem factual para tomada de decisão

A base de conhecimento da organização serve com parâmetro na tomada de decisão, aliamos a análise dos dados e todas as informações disponíveis. Chega de levantar a ponta do dedo e saber para onde o vento sopra.

“Decisões eficazes são baseadas na análise de dados e informações”. (ABNT NBR ISO 9000:2005)
Benefícios mútuos nas relações com os fornecedores

Uma relação comercial só é boa quando as partes envolvidas usufruem dos seus benefícios. Com foco no planejado atingindo os objetivos dos interessados, agregamos valores ao negócio. Existe uma interdependência entre organização e fornecedor, ou seja, um depende do outro para sobreviver no mercado.

“Qualidade é a totalidade das características de uma entidade (produto) que lhe confere a capacidade de satisfazer às necessidades explícitas (requisitos funcionais) e implícitas (requisitos não funcionais)”. (Antiga norma ABNT NBR ISSO 8402)

O que o cliente espera quando nos contratam? Que o produto ou serviço contratado tenha ”a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”.

Segundo Pressman, em seu famoso livro Engenharia de Software, “Qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido”. Poderia ser resumido em: …”a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”.

Aumentou a nossa responsabilidade…

Podemos também dizer que qualidade é estar em conformidade com especificações, ou seja, quando os produtos possuem as características que estão descritas no projeto, catálogos ou listas de especificações.

Devemos sempre nos perguntar: Entendemos o que nos foi confiado a desenvolver?

Fechamos o conceito de qualidade, com definição mais antiga e que nos reporta ao tempo acadêmico: “Qualidade é a adequação ao uso”.

Com base nos conceitos acima, podemos avaliar a qualidade de um produto, verificando se ele atendeu ou não as necessidades do cliente. Entregamos aquilo que o cliente nos solicitou? Atendemos as suas expectativas?

Uma série de questionamentos que embora não estejam explícitos nas normas, nos direciona a satisfação do cliente, como por exemplo:

• Qual o objetivo do investimento no desenvolvimento do sistema?
• Existe alguma solução pronta?
• O que vale mais a pena desenvolver ou de fato comprar uma solução?
• O sistema tem como objetivo reduzir custos?
• O sistema tem como objetivo aumentar o lucro?
• O sistema tem como objetivo melhorar os processos internos automatizando?
• Quem vai usar o sistema?
• O que os envolvidos esperam do sistema?
• Como eles trabalham atualmente?
• Qual o impacto na rotina dos envolvidos?
• Levantamos todos os fluxos principais e alternativos do sistema?
• Foram identificados todos os atores primários e secundários do sistema?
• O ambiente operacional?
• Se o sistema vai interagir com outros sistemas?
• Se vamos consumir, gerar, ou seja, compartilhar informações com outros sistemas?
• Temos um layout aprovado pelo cliente?
• Conseguimos satisfazer as expectativas do cliente?

Ainda seriamos capazes de sentarmos em frente ao computador e sairmos escrevendo códigos feito um alucinado, sem nos preocupamos em entender o domínio do negócio, os requisitos do cliente? Se a nossa resposta for sim, estamos com sérios problemas, pois não percebemos a importância de conseguir um cliente e a responsabilidade em mantê-lo.

Aprofundando mais um pouquinho, questiono ainda:  

• Como fomos preparados para a vida profissional?  
• O que aprendemos com aplicação prática no âmbito da qualidade?

Recordando as atividades na vida acadêmica, se não me falha a memória, aprendemos uma linguagem de programação, noções de orientação o objetos, noções de UML, banco de dados, noções sobre sistemas operacionais, mas nossa vida acadêmica é direcionada para desenvolvermos o senso ético e moral na vida profissional? O que isso tem há ver com a qualidade? Qualidade – Ética – Moral? (consulte: Código de Ética dos Engenheiros de Software).

Vamos supor que aprendêssemos, antes de qualquer coisa, as normas de qualidade, em seguida fossemos orientados a entender o domínio do negócio, passando em seguida para a elicitação de requisitos, a análise orientada a objeto, a diagramação em UML, ao desenho da arquitetura do sistema, o uso de ferramentas que automatizam os processos, a documentação do sistema, enfim a entender e participar durante toda a vida acadêmica de todo o ciclo de vida do sistema. Sem falar nas metodologias de desenvolvimento como RUP, XP, SCRUM, ASD.

Voltando ao tema, várias são as vantagens da implementação do sistema da gestão da qualidade, destacando o aumento da credibilidade da organização frente ao mercado consumidor, o aumento da competitividade do produto ou serviço no mercado, a prevenção da ocorrência de deficiências e mitigação dos riscos comerciais (reivindicações de garantia e responsabilidades pelo produto).

Outro questionamento interessante: Qualidade se implanta?

Pensei em iniciar este item como o seguinte título “Implantando a Qualidade”, mas preferi fazer o questionamento “Qualidade se Implanta?”.

Qualidade não deveria ser implantada, mas praticada, nas mais variadas atividades em nossa vida profissional e também pessoal, quando a entendemos em sua essência, ela passa a ser natural e não precisamos implantá-la porque trabalhamos sempre com qualidade. É interessante o questionamento, pois se precisamos implantar a qualidade é por que trabalhamos sem qualidade, ou seja, de forma errada ou precária (sendo menos rigoroso, nível 1 CMM). A sistematização, a documentação dos processos, e todas as atividades pertinentes à implantação da gestão da qualidade seria a formalização do que se pratica.

Fatores que motivam a organização a implantar um sistema de gestão da qualidade:

• É preciso a conscientização da alta administração, é o efeito chuveiro, só funciona de cima para baixo. 
• Podemos afirmar que essa é a mais eficaz entre todas.

O interesse por outros mercados no fornecimento de produtos e serviços, ou para órgãos ou empresas governamentais nos levam por forças contratuais, a implantação dos sistemas de gestão da qualidade. O tempo de maturação neste tipo de conscientização é maior, mas normalmente se alcança por razões de sobrevivência no mercado.

A agressiva competitividade no mercado força a conscientização da alta administração, ou seja, ou se adequa ao sistema de gestão da qualidade ou então morre.

Dançar conforme a música, é o conceito do modismo, é a menos eficaz, normalmente não se chega a alcançar o objetivo maior, que é a conscientização da alta administração.

NBR ISO/IEC 9126

Começaremos a partir deste post a versar sobre a NBR ISO/IEC 9126 e seus benefícios quando aplicados de forma correta durante o ciclo de vida do sistema. 

Segundo a NBR ISO/IEC 9126 a especificação e avaliação da qualidade do produto de software são fatores chave para garantir qualidade adequada. Isto pode ser alcançado pela definição apropriada das características de qualidade, levando em consideração o uso pretendido do produto de software. É importante que cada característica relevante de qualidade do produto de software seja especificada e avaliada utilizando, quando possível, métricas validadas ou amplamente aceitas, como a APF.

A especificação e validação passaram a ter como base o domínio do negócio e o envolvimento do cliente. Nenhuma proposta comercial pode ser enviada para o cliente sem a observação deste pré-requisito, o que reforça o transcrito na NBR ISO/IEC 9126 “levando em consideração o uso pretendido do produto de software”, ou seja, o domínio do negócio do cliente.

A NBR ISO/IEC 9126 propõe o modelo de qualidade do produto de software, em duas partes:

a) qualidade interna e qualidade externa, e especifica 6 características.

b) qualidade em uso, e especifica quatro características.

A tabela abaixo mostra as seis características e suas variações em sub características quando manifestadas externamente, o software é utilizado como parte de um sistema computacional, e são resultantes de atributos internos do software.

Características	Sub características
Funcionalidade	Adequação Acurácia Interoperabilidade Conformidade Segurança de Acesso
Confiabilidade	Maturidade Tolerância a falhas Recuperabilidade
Usabilidade	Intelegibilidade Apreensibilidade Operacionalidade
Eficiência	Tempo Recursos
Manutenibilidade	Analisabilidade Modificabilidade Estabilidade Testabilidade
Portabilidade	Adaptabilidade Capacidade de Instalação Conformidade Capacidade de Substituição

               Características e subcaracterísticas proposta pela NBR ISO/IEC 9126 

Para tornar a norma eficiente e eficaz no seu uso e implantação, é preciso fazer valer o seu uso dentro do processo de gestão de desenvolvimento de sistemas, fazendo parte do conceito de “pronto” do produto. Para tornar o processo mais eficiente e o uso efetivo da norma de qualidade, estrategicamente, a lista de características e subcaracterísticas passaram a fazer parte, como ponto de atenção, aos riscos do projeto de software em conjunto com os testes de software. Passamos a encarar como riscos de projeto as funcionalidades quando não estavam de acordo com o domínio do negócio, a confiabilidade, a usabilidade, a eficiência, a manutenibilidade e a portabilidade.

Segundo a NBR ISO/IEC 9126 a qualidade do produto de software é especificada e avaliada em diferentes perspectivas pelos envolvidos com aquisição, requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia de qualidade e auditoria de software. Ela pode, por exemplo, ser utilizada por desenvolvedores, adquirentes, pessoal de garantia de qualidade e avaliadores independentes, particularmente os responsáveis por especificar e avaliar qualidade do produto de software. Exemplos de usos do modelo de qualidade definido nesta parte da NBR ISO/IEC 9126 são para:

Validar a completitude de uma definição de requisitos;

• Identificar requisitos de software; 
• Identificar objetivos de projeto de software;
• Identificar objetivos para teste de software;
• Identificar critérios para garantia de qualidade;
• Identificar critérios de aceitação para produtos finais de software. 

Modelo de Qualidade para qualidade Externa e Interna, segunda NBR ISO/IEC 9126

“Esta seção define o modelo de qualidade externa e interna. Ele categoriza os atributos de qualidade de software em seis características (funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade) as quais são, por sua vez, subdivididas em subcaracterísticas. As subcaracterísticas podem ser medidas por meio de métricas externas e internas”. (NBR ISO/IEC 9126)

Uma definição é atribuída para cada característica e para cada subcaracterísticas do software que influencia a característica de qualidade. A capacidade do software é determinada por um conjunto de atributos internos que podem ser medidos, para cada característica e subcaracterísticas. Exemplos de métricas internas são dados na ISO/IEC 9126-3.

As características e subcaracterísticas podem ser medidas externamente pelo grau da capacidade do sistema contendo o software. Exemplos de métricas externas são dados na ISO/IEC 9126-2.

Funcionalidade segunda a Norma ISO 9126

“Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas”. (NBR ISO/IEC 9126)

A Norma ISO define como funcionalidade do sistema as funções em uso que atendam aos requisitos funcionais e não funcionais com base no domínio do negócio do cliente, o que nos serviu como definição para elaboração do Backlog do Produto.

Adequação

“Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados”. (NBR ISO/IEC 9126)

A Norma ISO define como adequação as funcionalidades que atendam os objetivos do usuário. Esta orientação contribui para elaboração da Sprint durante o seu planejamento.

Acurácia

“Capacidade do produto de software de prover, com o grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados”. (NBR ISO/IEC 9126)

A Norma ISO define como acurácia o grau de precisão e resultados corretos, atingidos com base no domínio do negócio. A acurácia passou a fazer parte a cada entrega de release, contribuindo para os três valores do Scrum: transparência, inspeção e adaptação.

Interoperabilidade

“Capacidade do produto de software de interagir com um ou mais sistemas especificados”. (NBR ISO/IEC 9126)

A Norma define como interoperabilidade a capacidade integração do sistema em desenvolvimento com outros sistemas no ambiente em que ele irá operar, englobando sistemas operacionais e sistemas que interagem com ele, porém fora da fronteira da aplicação em desenvolvimento, mas com possiblidade de fornecimento de informações.

Segurança de acesso

“Capacidade do produto de software de proteger informações e dados, de forma que pessoas ou sistemas não autorizados não possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou sistemas autorizados”. (NBR ISO/IEC 9126)

Conformidade relacionada à funcionalidade

“Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas à funcionalidade”. (NBR ISO/IEC 9126)

Faz parte do entendimento do domínio do negócio a imersão in totum nas peculiaridades do negócio do cliente. A não observância da Norma, a empresa desenvolvedora, corre o risco infringir a legislação que regulamenta o negócio do cliente.

Confiabilidade segundo a Norma ISO 9126

“Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas”. (NBR ISO/IEC 9126)

A Norma define como confiabilidade ao desempenho do sistema em produção.

Maturidade

“Capacidade do produto de software de evitar falhas decorrentes de defeitos no software”. (NBR ISO/IEC 9126)

A Norma define como maturidade o nível de erros, defeitos e falhas identificados no ciclo de vida de desenvolvimento. Os erros estão ligados a usabilidade do sistema, pois são gerados pelas ações do usuário na operação do sistema. Os defeitos do sistema estão ligados ao não entendimento do domínio do negócio, a má qualidade da informação ou mesmo a sua omissão. As falhas segundo o padrão IEEE ocorrem quando um programa não se comporta conforme o esperado ou apresenta resultados diferentes do planejado. (1983) A observância destes fatores contribuem para a qualidade e maturidade do sistema.

Tolerância a falhas

“Capacidade do produto de software de manter um nível de desempenho especificado em casos de defeito no software ou de violação de sua interface especificada”. (NBR ISO/IEC 9126)

A Norma define como tolerância a falhas de nível de desempenho especificado em casos de defeitos no software ou da violação da sua interface.  O Scrum contribui para a tolerância a falhas do sistema a cada iteração na dinâmica da arquitetura emergente do sistema, de acordo com as especificações, com base no domínio do negócio.

Recuperabilidade

“Capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha”. (NBR ISO/IEC 9126)

A Norma define como recuperabilidade o reestabelecimento do desempenho e a garantia da integridade dos dados gerados na utilização do sistema.

Conformidade relacionada à confiabilidade

Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações relacionadas à confiabilidade. (NBR ISO/IEC 9126)

Usabilidade segundo a Norma ISO 9126

 “Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas”. (NBR ISO/IEC 9126)

O envolvimento do Dono do Produto possibilita que o domínio do negócio seja refletido no sistema em desenvolvimento, garantindo pela coautoria do especialista a usabilidade do sistema.

Inteligibilidade

“Capacidade do produto de software de possibilitar ao usuário compreender se o software é apropriado e como ele pode ser usado para tarefas e condições de uso específicas”. (NBR ISO/IEC 9126)

Item da norma também garantida com o envolvimento do especialista do negócio.

Apreensibilidade

“Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação”. (NBR ISO/IEC 9126)

A facilidade de uso e apreensibilidade do sistema também é garantida pela participação do Dono do Produto no ciclo de vida de desenvolvimento do sistema, refletindo na sistematização o modus operandos do usuário final, tornando o sistema familiar e fácil de operar.

Operacionalidade

“Capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo”. (NBR ISO/IEC 9126)

O envolvimento dos stakeholders torna mais fácil a adequação do sistema a este item da Norma, garantindo a facilidade de operação e controle do sistema.

Atratividade

“Capacidade do produto de software de ser atraente ao usuário”. (NBR ISO/IEC 9126)

Conformidade relacionada à usabilidade

“Capacidade do produto de software de estar de acordo com normas, convenções, guias de estilo ou regulamentações relacionadas à usabilidade”. (NBR ISO/IEC 9126)

Eficiência segundo a Norma ISO 9126

“Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas”.

Comportamento em relação ao tempo

“Capacidade do produto de software de fornecer tempos de resposta e de processamento, além de taxas de transferência, apropriados, quando o software executa suas funções, sob condições estabelecidas”.

Utilização de recursos

“Capacidade do produto de software de usar tipos e quantidades apropriados de recursos, quando o software executa suas funções sob condições estabelecidas”.

Conformidade relacionada à eficiência.

“Capacidade do produto de software de estar de acordo com normas e convenções relacionadas à eficiência".

Manutenibilidade segundo a Norma ISO 9126

“Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais”. (NBR ISO/IEC 9126)

Analisabilidade

“Capacidade do produto de software de permitir o diagnóstico de deficiências ou causas de falhas no software, ou a identificação de partes a serem modificadas”. (NBR ISO/IEC 9126)

Modificabilidade

“Capacidade do produto de software de permitir que uma modificação especificada seja implementada”. (NBR ISO/IEC 9126)

Estabilidade

“Capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software”. (NBR ISO/IEC 9126)

Testabilidade

“Capacidade do produto de software de permitir que o software, quando modificado, seja validado”. (NBR ISO/IEC 9126)

Conformidade relacionada à Manutenibilidade

Capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à manutenibilidade.

Portabilidade segundo a Norma ISO 9126

“Capacidade do produto de software de ser transferido de um ambiente para outro”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Adaptabilidade

“Capacidade do produto de software de ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado”. (NBR ISO/IEC 9126)

Capacidade para ser instalado

“Capacidade do produto de software para ser instalado em um ambiente especificado”. (NBR ISO/IEC 9126)

Coexistência

“Capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns”. (NBR ISO/IEC 9126)

Capacidade para substituir

“Capacidade do produto de software de ser usado em substituição a outro produto de software especificado, com o mesmo propósito e no mesmo ambiente”. (NBR ISO/IEC 9126)

 

Conformidade relacionada à portabilidade

Capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à portabilidade.

Modelo de Qualidade para Qualidade em Uso segundo a Norma ISO 9126

Esta seção define o modelo de qualidade para qualidade em uso. Os atributos de qualidade em uso são categorizados em quatro características: eficácia, produtividade, segurança e satisfação.

Qualidade em uso é a visão da qualidade sob a perspectiva do usuário. A obtenção de qualidade em uso é dependente da obtenção da necessária qualidade externa, a qual, por sua vez, é dependente da obtenção da necessária qualidade interna. Normalmente, são necessárias medidas em todos os três níveis, pois atender aos critérios para medidas internas em geral não é suficiente para garantir o atendimento aos critérios para medidas externas, e atender aos critérios para medidas externas de sub-características em geral não é suficiente para garantir o atendimento aos critérios para qualidade em uso.

Qualidade em uso

“Capacidade do produto de software de permitir que usuários especificados atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso especificados”. (NBR ISO/IEC 9126)

Eficácia

“Capacidade do produto de software de permitir que usuários atinjam metas especificadas com acurácia e completitude, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Produtividade

“Capacidade do produto de software de permitir que seus usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Segurança

“Capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Satisfação

“Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Métricas de software

Atributos Externos e Internos

Constata-se que os níveis de certos atributos internos influenciam os níveis de alguns atributos externos, de modo que há tanto um aspecto externo quanto um aspecto interno na maioria das características. Por exemplo, a confiabilidade pode ser medida, externamente, observando-se o número de falhas, num dado período de tempo de execução, durante um experimento de uso do software e, internamente, inspecionando as especificações detalhadas e o código-fonte para avaliar o nível de tolerância a falhas. Os atributos internos são tidos como indicadores dos atributos externos.

Um atributo interno pode influenciar uma ou mais características e uma característica pode ser influenciada por mais de um atributo (ver figura A.1). Neste modelo, todos os atributos de qualidade do produto de software são classificados numa estrutura hierárquica, em árvore, de características e subcaracterísticas. O nível mais alto desta estrutura consiste em características de qualidade e o nível mais baixo consiste em atributos de qualidade de software. A hierarquia não é perfeita, pois alguns atributos podem contribuir para mais de uma subcaracterística.

Fonte: NBR ISO/IEC 9126.

Subcaracterísticas podem ser medidas por métricas internas ou por métricas externas.

A correlação entre atributos internos e medidas externas nunca é perfeita e o efeito que um dado atributo interno tem sobre uma medida externa associada será determinado pela experiência e dependerá do contexto específico no qual o software será usado.

Do mesmo modo, propriedades externas (tais como: adequação, acurácia, tolerância a falhas ou comportamento em relação ao tempo) influenciarão a qualidade observada. Uma falha na qualidade em uso (por exemplo, o usuário não consegue terminar uma tarefa) pode ser relacionada a atributos de qualidade externa (por exemplo, adequação ou operabilidade) e a atributos internos associados que precisam ser modificados.

Métricas internas

Métricas internas podem ser aplicadas a um produto de software não executável, tais como uma especificação ou código fonte, respectivamente, durante o projeto e a codificação. Convém que, no desenvolvimento de um produto de software, os produtos intermediários sejam avaliados utilizando-se métricas internas, as quais medem propriedades intrínsecas, incluindo aquelas que podem ser derivadas de um comportamento simulado. O propósito básico destas métricas internas é assegurar que a qualidade externa e a qualidade em uso requerida sejam alcançadas; exemplos são encontrados na ISO/IEC 9126-3. Métricas internas oferecem a usuários, avaliadores, executores de teste e desenvolvedores os benefícios de poderem avaliar a qualidade do produto de software e considerar questões relativas à qualidade bem antes do produto de software se tornar executável.

Métricas internas medem atributos internos pela análise das propriedades estáticas dos produtos de software intermediários ou preparados para entrega. Da mesma forma, as métricas internas podem ser indicadoras de atributos externos.

Métricas Externas  

Utilizam medidas de um produto de software derivadas de medidas do comportamento do sistema do qual o software é uma parte, através de teste, operação e observação do software executável ou do sistema. Antes de adquirir ou utilizar um produto de software, convém que ele seja avaliado utilizando-se métricas baseadas nos objetivos de negócio e relacionadas ao uso, exploração e gestão do produto num ambiente técnico e organizacional especificado.

As métricas citadas são, primordialmente, métricas externas; exemplos são encontrados na ISO/IEC 9126-2. Métricas externas oferecem a usuários, avaliadores, executores de teste e desenvolvedores os benefícios de poderem avaliar a qualidade do produto de software durante seu teste ou operação.