A qualidade é relativa. O que é qualidade para uma …profcelso.orgfree.com/Arquivos_Aulas/06-Qualidade_Soft/AULAS/01... · Programas que simplesmente param de funcionar. Um exemplo

ADS / REDES / ENGENHARIA Prof. Celso Candido

QUALIDADE DE SOFTWARE

1

A qualidade é relativa. O que é qualidade para uma pessoa pode ser falta de qualidade para outra.

G. Weinberg



2

A ideia de qualidade é aparentemente intuitiva.

Contudo, quando examinado mais longamente, o conceito se revela complexo.



3

Definir qualidade para estabelecer objetivos é, assim, uma tarefa menos trivial do que aparenta a princípio.


QUALIDADE DE SOFTWARE H I S T Ó R I A

4

O controle de qualidade e o uso dos padrões ISO vem influenciando a forma como a qualidade tem sido usada nas últimas décadas, mas historicamente o assunto é muito antigo.

Através de relatos existentes há mais de quatro mil anos, os egípcios estabeleceram um padrão de medida de comprimento conhecido como cúbito, correspondente ao comprimento do braço do faraó reinante. Utilizado como unidade de medida nas construções egípcias.

O único problema era quando um novo faraó assumia o poder, a unidade de medida também se modificava.

A punição para quem não aceitava a mudança era a morte.



5

Um dos grandes marcos na história da qualidade foi a revolução industrial.

Nesse mesmo período está também associado a profundas mudanças econômicas e sociais, como o início da automação e o surgimento do consumo de massa.

Na década de 1920 surgiu o controle estatístico de produção, garantindo a produção de grandes quantidades.

Na década de 1940 surgiram vários organismos ligados à qualidade. Temos como exemplo: a ASQC (American Society for Quality Control), a ABNT (Associação Brasileira de Normas Técnicas) e, ainda, a ISO (International Standardization Organization).



6

No pós-guerra, o impulso recebido pelas indústrias se manteve.

Os computadores digitais em uso na época estavam restritos a meios militares e acadêmicos.

Só após alguns anos as máquinas se tornaram mais acessíveis e um maior número de pessoas as utilizava.

A qualidade dos softwares começou a se mostrar um objetivo mais importante.

Um dos fatores com grande influência negativa na qualidade de um projeto é a sua complexidade, associada a uma característica muito simples: o tamanho das especificações.



7

Exemplo de complexidade:

Construir um prédio de 10 andares implica em tratar um número de problemas muito maior do que os existentes em uma simples residência.

A diferença entre as duas construções, se analisarmos a fundo, está longe de ser resolvida apenas com um número maior de tijolos e uma quantidade maior de argamassa.

Em programas de computador, o problema de complexidade e seu tamanho é ainda mais grave, em razão das interações entre os diversos componentes do sistema.



8

Em meados da década de 1950, segundo a lei Grosch (Pick et al., 1986), acreditava-se em uma relação, onde o desempenho de um computador deveria ser proporcional ao quadrado de seu preço.

De acordo com essa lei uma ideia interessante seria juntar um grupo de usuários e adquirir um computador de grande porte, conhecido como mainframe.

Também era muito comum nessa época alugar uma máquina direto de seu fabricante.

Quando era encontrado problemas mais complexos, significava a necessidade de se alugar máquinas maiores.



9

Mas como eram essas grandes máquinas nessa época?

A memória semicondutora fora criada em 1966 (por Robert H. Dennard, na IBM) e produzida pela Intel só em 1970.

Em 1971, surgiu o primeiro microprocessador em silício de nome Intel 4004, possuía uma CPU de 4 bits utilizando menos de 3 mil transístores, possuía tanto poder de processamento quanto o ENIAC, 1945 – 1955, que possuía 18 mil válvulas.

Assim, um computador “grande”, em 1960, era uma máquina ocupando uma sala de dezenas de metros quadrados!



10

As novas tecnologias da época tiveram um grande efeito na produção de software.

A maior causa da crise do software é que as máquinas tornaram se várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema. Quando tivemos computadores fracos, isso se tornou um problema pequeno. Agora que temos computadores gigantescos, programar tornou-se um problema gigantesco.

Dijkstra, 1972

Os recursos de hardware se desenvolveram permitindo a criação de produtos mais complexos.



11

O relatório da conferência, realizado 1968, do Comitê de Ciência da NATO, revelou que: os problemas encontrados na época são os mesmos que encontrados atualmente. Exemplos:

Cronogramas não observados ou não seguidos; Projetos com tantas dificuldades que acabam sendo abandonados;

Módulos que não operam corretamente quando combinados; Os programas não fazem exatamente o que se esperava;

Os programas difíceis de usar, muitas vezes são descartados; Programas que simplesmente param de funcionar.

Um exemplo mais conhecido foi o Bug do Milênio, quando foi citado que seria o apocalipse dos sistemas informatizados.



12

A PARTIR DESTE SLIDE ATÉ O ÚLTIMO DESTA APRESENTAÇÃO O ASSUNTO FOI RETIRADO DO

Capítulo 17 – Gerenciando a Qualidade de Software

com Base em Requisitos

“Qualidade de Software: Teoria e Prática, Orgs. Rocha, Maldonado, Weber, Prentice-Hall, São Paulo, 2001”



13

Obter qualidade nos processos e produtos de engenharia de software não é uma tarefa trivial, comum ou fácil. Vários são os fatores de dificuldade para atingirmos os objetivos de qualidade.

Nada existe nada mais decepcionante do que produzir software que não satisfaça as necessidades dos clientes.

Derivados da falta de atenção na definição das tarefas a executar e em acompanhar a evolução dos requisitos durante o processo de construção de software.

Precisamos seguir as definições de construção e os requisitos, assim teremos os processos sendo desenvolvidos de maneira fundamental para a qualidade do software ou do produtos que será implantado.



14

Ao falarmos de qualidade software e de toda sua engenharia, estamos falando ao mesmo tempo de seus produtos e de seus processos.

Não adianta colocarmos nossa atenção apenas no produto ou no processo. Necessitamos que as duas visões caminhem juntas.

Quando lidamos com a qualidade, necessitamos que os processo de produção sejam claros e específicos quanto ao nível de qualidade e do produto a se obter.



15

A engenharia de software contempla uma visão orientada a qualidade do produto.

1. Prioridade na qualidade das representações.

2. Entender que a qualidade de um produto é formatada por um conjunto de vários tipos testes no decorrer de seu desenvolvimento e com as pessoas que estarão utilizando.

Dentro dessa visão destacamos três aspectos dominantes para a pesquisa e a prática no desenvolvimento de software:

3. O processo de produção necessita estar centrado em fases (módulos de produção), definidos e documentados.



16

A qualidade das representações, executáveis ou não, são um importante aspecto na engenharia de software.

Muitas vezes essas discussões saiam do nível técnico e passavam para discussões voltadas aos gostos pessoais.

A visão inicial do processo de produção, ou ciclo de vida do software, estava centrada no desenvolvimento de produtos e regras usando definições voltada ao produto final e não as suas etapas de produção.

Linguagens de programação robustas, maior confiabilidade e maior nível de abstração são muito discutidos, pois possuem alto grau de desenvolvimento.



17

Atualmente os engenheiros possuem uma visão mais ampla dos processos de produção:

Primeiro – O processo de produção deverá ser fundamental para obtermos produtos de qualidade.

Segundo – Devemos possuir uma visão equilibrada dos aspectos essenciais e acidentais contidos no uso pela engenharia de software.

Terceiro – A sociedade passa a entender melhor os custos relacionados com a evolução do software.



18

Possuir uma visão sobre a construção de software como um processo onde: normas, procedimentos e gerência, precisam estar bem definidos, garantindo a qualidade dos produtos.

Nesta visão, a gerência passa a ser vista como um aspecto técnico, baseado na experiência, deixando em segundo plano o conhecimento baseado na engenharia de software.

Difere da visão do processo de produção onde centralizamos o processo em fases/produtos.



19

Vamos analisar a importância dos aspectos essenciais salientada por Fred Brooks [Brooks 87]:

"A parte mais difícil de construir um sistema de software é decidir precisamente o que construir. Outro ponto crucial é a parte do trabalho conceitual, tão difícil como instituir uma técnica detalhada dos requisitos, incluindo toda a interface para as pessoas, máquinas e outros softwares nos sistemas. Não se pode falhar em nenhuma parte do trabalho, pois enfraquecerá as resultantes do sistema, causando um efeito contrário ao desejado, o que seria muito difícil de se retificar.”



20

Assim a QUALIDADE do produto software passa a ser um componente comum junto com outros produtos, desde carros, fornos de micro-ondas, elevadores, telefones, até sistemas de informação organizacionais.

Sendo esta exatamente a função da engenharia, procurar sistemas de melhor qualidade dentro de um custo compatível com essa qualidade, otimizando a redução de custos.

Exigindo que tenha qualidade compatível com o produto e um custo que seja o menor possível.



21

A escolha dos métodos que serão utilizados no processo de produção é tido como gerencial. Está ligado a qualidade, resultante da função dos métodos de produção escolhidos e seguidos. Envolvendo como agravante os seres humanos, exemplo: o usuário final.

A qualidade deve estar presente nos produtos produzidos, como nos processos utilizados para gerar esses produtos, auditando sua produção.

Sendo esta a função da engenharia, procurar sistemas de melhor qualidade, custo compatível e otimizado.



22



23

Assegurar a qualidade dos produtos e dos processos é responsabilidade do subsistema GERÊNCIA, que necessita dispor de MÉTODOS e FERRAMENTAS compatíveis com a qualidade desejada.

Em um processo de gerência, precisa existir um sistema de retroalimentação, fornecendo ao subsistema GERÊNCIA as informações sobre o funcionamento do processo para a correção de eventuais problemas que possam vir a surgir.

ENTENDO A FIGURA 01

Atuar eficazmente na função de garantir a qualidade exige conhecimento técnico sobre os MÉTODOS e FERRAMENTAS, além do conhecimento de gerência para lidar com PESSOAL .



24

Precisamos organizar as informações coletadas, que chamamos de métricas, para um melhor conhecimento dos produtos produzidos e dos processos utilizados na sua produção.

Sem as métricas não será possível comunicarmos de maneira precisa, fundamental para garantir a qualidade.

ENTENDO A FIGURA 01

A responsabilidade da guarda e distribuição dessas informações é do subsistema INFORMAÇÃO.



25

AULAS DE APOIO

Este arquivo será disponibilizadas para estudos para aprimoramento, estudos e consultas no formato PDF. Alguns estarão disponíveis para impressão, outros, somente para leitura.

www.aulasprof.6te.net ou www.profcelso.orgfree.com/

Documents

A qualidade é relativa. O que é qualidade para uma …profcelso.orgfree.com/Arquivos_Aulas/06-Qualidade_Soft/AULAS/01... · Programas que simplesmente param de funcionar. Um exemplo