Вы находитесь на странице: 1из 28

Introduo Qualidade de Software

Prof Lisane Brisolara de Brisolara Metodologia de Desenvolvimento de Programas

Introduo
Cada vez mais sistemas so controlados por software. Portanto, importante garantir que o software tem qualidade satisfatria para seu ramo de atuao. O que qualidade de software...? Qualidade um conjunto de propriedades a serem satisfeitas em determinado grau, de modo que este satisfaa s necessidades dos usurios.

Introduo
Fatores de qualidade de Software: Confiabilidade Eficincia Usabilidade etc

Motivao
Existncia de servios prestados por software e que direta ou indiretamente afetam a vida de todos
Qualidade de software no pode ser tratada como assunto secundrio

muito mais barato atingir boa qualidade por construo do que depois ter de refazer ou corrigir problemas!

Desenvolvimento
Abordagem de tentativa e erro (desenvolver um pouco, testar um pouco, eliminar algumas falhas e prosseguir...)
Pequenos programas destinados a avaliar uma idia, ou usados para apreender uma linguagem, podem ser desenvolvidos com sucesso sem que siga um processo cuidadoso.

Programa mais complexo, ou que requer uma qualidade mais elevada, no pode ser desenvolvido segundo esta abordagem!
Exige uma etapa de projeto muito bem realizada!

Qualidade de Produtos de Software


Norma NBR 13596: verso brasileira da norma ISO/IEC 9126. Foi definida em 1996. Lista um conjunto de caractersticas que devem ser verificadas em um software para que ele seja considerado um software de qualidade Quais so as caractersticas desejadas???

Fatores de qualidade
Funcionalidade Confiabilidade Usabilidade Eficincia Manutenibilidade Portabilidade

Qualidade de Produtos de Software - NBR 13596


Caracterstica Subcaractersticas Pergunta chave para a subcaracterstica Prope-se a fazer o que apropriado? Faz o que props de maneira correta? Interage com os sistemas especificados? Evita acesso no autorizado a dados? Est de acordo com as normas, leis, etc. Com que frequncia apresenta falhas? Ocorrendo falhas, como reage? capaz de recuperar dados em caso de falhas? fcil entender o conceito e a aplicao? fcil aprender a usar? fcil operar e controlar

Funcionalidade (satisfaz as necessidades?)

Adequao Acurcia Interoperabilidade Segurana de acesso Conformidade

Confiabilidade ( imune a falhas?)

Maturidade Tolerncia a falhas Recuperabilidade Inteligibilidade Apreensibilidade Operacionalidade

Usabilidade ( fcil de usar?)

Qualidade de Produtos de Software - NBR 13596


Caracterstica Subcaractersticas Pergunta chave para a subcaracterstica Qual o tempo de resposta, velocid. de execuo? Quanto recurso usa? Durante quanto tempo? fcil encontrar uma falha, quando ocorre? fcil modificar e adaptar? H grande risco quando se faz alteraes? fcil testar quando se faz alteraes? fcil adaptar a outros ambientes? fcill instalar em outros ambientes? Est de acordo com padres de portabilidade? fcil usar para substituir outro sistema?

Eficincia (Rpido e enxuto)

Tempo Recursos

Manutenibilidade ( fcil de modificar?)

Analisabilidade Modificabilidade Estabilidade Testabilidade

Portabilidade ( fcil de usar em outro ambiente?)

Adaptabilidade Capacidade para ser instalado Conformidade Capacidade para substituir

Qualidade de cdigo
Escrever corretamente um cdigo
Reduo de defeitos Facilita a manutenco do cdigo Facilita trabalho em equipe

Aumenta a legibilidade do cdigo

Qualidade de cdigo
Escrever corretamente um cdigo
Evitando cdigos que Reduo de defeitos podem levar a erros Facilita a manutenco do cdigo Facilita trabalho em equipe

Qualidade de cdigo
Escrever corretamente um cdigo
Reduo de defeitos Facilita a manutenco do cdigo Facilita trabalho em equipe

Cdigo mais legvel e mais fcil de ser adaptado ou modificado

Como desenvolver software de qualidade?


Alm de um cdigo bem feito... necessrio seguir um processo de desenvolvimento bem definido e documentado. Afinal software no simplesmente um programa!

Fatores relacionados qualidade


Inspees e Teste Uso de padres de programao Uso de estilos e convenes para programao Uso de comentrios em cdigo Documentao de projeto

Inspees
As inspees so exames minuciosos no cdigo e outros artefatos do projeto Inspeo de cdigo uma anlise esttica
Podem ser usadas para encontrar erros e anomalias Podem ser usados para verificar se h desvio com relao a padres e estilos de codificao Tambm podem ser usadas para avaliar a qualidade do software, verificando se o mesmo est bem escrito e bem documentado

Teste
Objetivo: encontrar erros no software uma anlise dinmica Visa verificar se o sistema funciona corretamente para um dado conjunto de casos de teste e se atende aos requisitos do usurio Os testes podem somente mostrar a presena de erros, mas no sua ausncia!

Fatores relacionados a qualidade


Inspees e Teste Uso de padres de programao Uso de estilos e convenes para programao Uso de comentrios em cdigo Documentao de projeto

Legibilidade e manutenibilidade

Legibilidade
Legibilidade: Facilidade de ler e escrever programas Contrrio a intuio, programas so muito mais lidos por pessoas do que por processadores de linguagens. Conseqentemente, deveriam ser redigidos de forma a serem facilmente explorados, lidos e compreendidos

Legibilidade
Legibilidade influi:
desenvolvimento e depurao de programas manuteno de programas desempenho de equipes de programao Abstrao de dados Comandos de controle Modularizao de programas Documentao Convenes
Exemplo em Java: nomes de classes iniciam por letra maiscula, nomes de atributos usam letras minsculas

Fatores que melhoram a legibilidade:

Padres de Programao
Estabelecem:
Regras que devem ser aplicadas obrigatoriamente Excees que estabelecem condies especiais que determinam a aplicao alternativa a uma regra Recomendaes que devem ser seguidas na medida do possvel

Uso de Padres de Programao


Os padres podem ser adaptados a cada organizao Com a adoo de padres, espera-se:
uma reduo significativa de ocorrncia de erros comuns de programao evitar personalismos danosos qualidade de programas facilitar o desenvolvimento e a manuteno de um mesmo mdulo por vrias pessoas diferentes e em pocas bem distintas

A adoo de padres pode ser comprovada com inspees que verificam a conformidade com o padro

Padres: bno ou flagelo?


O objetivo do padro facilitar a manuteno, mas este no pode dificultar a vida do programador! Nenhum padro pode ser aplicvel em todas as circunstncias possveis Se os padres so impostos e no so explicados aos programadores, eles no adotam! Regras excessivamente restritivas podem ser contraproducentes interessante que estas regras possam ser verificadas por ferramentas, liberando o programador da tarefa de escrever conforme as regras

Padres definem
Regras para escolha de nomes Constantes Nmero mximo de if aninhados
R: No aninhar if com mais de 3 nveis Mdulos formados por 35 a 50 instrues

Tamanho mnimo e mximo para um mdulo Uso da linguagem padro Estilo de programao

Estilo de programao
Conjunto de diretrizes usadas ao codificar um programa com o propsito de facilitar a leitura do cdigo e compreenso do cdigo Base: bom senso e experincia, aliadas consistncia

Estilos de codificao
Cada linguagem de programao possui um estilo de escrita conhecido e aceito pela comunidade Um estilo se aprende observando cdigo escrito por outras pessoas Programao em dupla (pair-programming) ajuda a ter um cdigo mais legvel e melhor escrito

Bom estilo de cdigo


Caractersticas:
Lgica direta Expresso natural Uso convencional da linguagem Nomes significativos Formatao simples Comentrios teis

Estilo gosto pessoal?


Muitos programadores consideram o estilo usado como uma questo de gosto pessoal Porm, se o cdigo vai ser distribudo e/ou se o programador trabalha em equipe, preciso estabelecer um padro que dever ser adotado por toda a equipe!

Convenes
Palavras reservadas escritas em minsculo e ressaltadas com cor ou negrito no programa (while, if, else) Os identificadores, funes padro e procedimentos so escritos em minsculas, mas com primeira em maiscula (Escrever) Os identificadores definidos pelo programador com maisculas e minsculas (LerVetor, ListaNumeros)

Convenes do Java
Convenes usadas em Java Classes em maisculas Janela Objetos em minsculas janelaPrincipal Mtodo com verbo no infinitivo Desenhar( )

Regras de estilo de programao


Modularizar um programa em partes coerentes Escrever sub-rotinas curtas que faam bem somente uma coisa (coeso) Evitar variveis globais em subprogramas Usar nomes significativos para identificadores Definir constantes com nomes no incio do programa Evitar o uso de goto e no escrever cdigo spaghetti Tratamento de erros Comentrios adequados Leiaute Documentao

Comentrios
Comentrios destinam-se a acrescentar informao a um programa, quando esta informao no evidente, ao ler-se um cdigo. Comentrios aumentam a inteligibilidade de um programa Comentrio com as operaes abstratas representadas por aquele bloco de cdigo

Comentrios
Maus comentrios (listados pelo grau de nocividade) Comentrio obsoleto (no atualizado) Nenhum comentrio Comentrio irrelevante Comentrio que explica o que a instruo faz (A = 1, // Faz A igual a 1. ), assuma que o leitor conhece o suficiente sobre a linguagem Comentrio errado

Classes de comentrios
Comentrios de controle de configurao
Indicam os programadores que criaram e/ou alteraram o programa, as datas em que foram aceitos o programa original e as diversas alteraes, bem como o estado (verso ou modificao do mesmo) Contm cdigo desativado e facilmente reativvel, cuja finalidade auxiliar nas fases de tese, verificao e validao Descrevem o que o programa ou mdulo faz, que algoritmo usa, quais as restries e/ ou requisitos de uso, etc.

Comentrios de instrumentao

Comentrios gerais

Elaborando bons comentrios


Evitar comentrios difceis de modificar Comentar enquanto se codifica Evitar comentrios de pouca importncia Comentrios devem ser completos e sucintos Comentrios devem ser ressaltados do resto do programa Evitar comentrio no final da linha de instrues Comentar blocos de instruo, de preferncia a instrues individuais Colocar os comentrios antes do cdigo ao qual se aplicam Focalizar o porqu, de preferncia ao como Documentar surpresas e truques (se no puder evit-los) Evitar abreviaes Manter os comentrios prximo ao cdigo que comentam Evitar comentrios autopromocionais, insultuosos, obscenos, politicamente incorretos e similares

Leiaute de programa
O leiaute deve refletir a estrutura lgica do programa O objetivo principal a legibilidade (no a esttica) O leiaute deve ser consistente e resistente a modificaes
Ex: Usar { } depois de um if, mesmo que seja para conter uma nica instruo, facilita a posterior adio de outras instrues, caso venham a ser necessrias

Leiaute de programa
Espaamento Endentao (alinhamento, recuos e tabulao) Linhas em branco Tamanho das linhas

Endentao e quebras de linha


A endentao e a quebra de linha so fundamentais para a boa compreenso do cdigo-fonte. Faa a comparao: If bIsActive = True Then For iIndex = 0 To UBound(astrFileNames): Print #iFileNum, astrFileNames(iIndex): Next iIndex End If Ou ser que este no mais legvel? If bIsActive = True Then For iIndex = 0 To UBound(astrFileNames) Print #iFileNum, astrFileNames(iIndex) Next iIndex End If

Endentao
R: A endentao das estruturas de controle deve ocupar de 2 a 4 espaos R: A endentao pode ser feita por tabulaes.
Neste caso, indicar o fato em um comentrio colocado no inicio do programa, que indica o nmero de espaos De preferncia, no usar tabulao, para evitar a necessidade de configurar tabulao nos editores e facilitar a redistribuio de cdigo

Endentao: vrias formas


R: A endentao das chaves de estruturas de controle deve ser consistente
While (<expressao>) { <instrucao 1>; <instrucao 2>; } While (<expressao>) { <instrucao 1>; <instrucao 2>; }

Endentao: vrias formas


R: A endentao das chaves de estruturas de controle deve ser consistente
While (<expressao>) { <instrucao 1>; <instrucao 2>; } While (<expressao>) { <instrucao 1>; <instrucao 2>; } } While (<expressao>) { <instrucao 1>; <instrucao 2>;

Estilo preferencial

Endentao: preferencial
Usa-se as chaves mesmo que estas no sejam necessrias!
While (<expressao>) { <instrucao 1>; <instrucao 2>; } } if (<expressao>) { <instrucao 1>;

Configure o estilo que vai ser adotado no ambiente de programao!

Endentao: Alinhamento de Declaraes


R: Declaraes de dados devem ser colocadas uma por linha, com alinhamento do tipo
int idLinha; int idColuna; Ponto inferiorEsquerdo; Ponto superiorDireito; No assim: int idLinha, idColuna; Ponto inferioresquerdo, superiorDireito;

Linhas em branco
R: Instrues correlatas devem ser agrupadas, sem linhas me branco ou endentao desnecessria R: Pelo menos uma linha em branco deve separar um comentrio do cdigo precedente Blocos de comentrio devem ser separados de bloco de cdigo

Tamanho de linhas
R: Linhas de cdigo no devem exceder 80 caracteres Quando a instruo no cabe em uma linha, parti-la em duas ou mais linhas nos pontos de menor impacto sobre a legibilidade
If (<condicaoMuitoLonga1>) & (<condicaoMuitoLonga2>) {
v = <parte 1 da expressaoMuitoLonga>+ <parte 2 da expressaoMuitoLonga>;

Tamanho de linhas
R: Linhas de cdigo no devem exceder 80 caracteres Quando a instruo no cabe em uma linha, parti-la em duas ou mais linhas nos pontos de menor impacto sobre a legibilidade Ponto de quebra:
If (<condicaoMuitoLonga1>) & (<condicaoMuitoLonga2>) { v = <parte 1 da expressaoMuitoLonga> + <parte 2 da expressaoMuitoLonga>; }

- Depende da LP - Sugestes: logo aps a vrgula, fora de parnteses, mostrando que a linha est incompleta!

Tamanho de linhas (2)


R: Se uma lista de parmetros de uma funo for longa e no couber em 1 linha, cada linha de continuao deve ser alinhada e comear com um parmetro.
void mtodo (int parCurto1, float parCurto12, int primeiroParametroDeNomeLongo, float segundoParametroDeNomeLongo, float terceiroParametroDeNomeLongo)

Outra opo usar um parmetro por linha, mesmo quando for curto. Facilita a visualizao dos parmetros, mas ocupa mais espao!

Documentao: motivao
Nem sempre cdigo-fonte bem organizado e claro suficiente para compreenso rpida e fcil, por isso:
Inserir pistas no cdigo atravs de comentrios Amarrar o cdigo-fonte s especificaes, ou com documentos relacionados
// lao de contagem de bits // vide docR001.doc pgina 17 While (i > n) ...

Documentao
Diferentes objetivos Programadores: manuteno do cdigo -> manual de manuteno Operadores/usurios: rodar programa, inserir dados e extrair resultados - > manual do usurio

Manual do usurio
Tornar o SW mais acessvel e disponvel Na forma de manual, introduz as principais funes do SW, como instalar, detalha cada funo Manual de ajuda on-line: includo no programa

Manual de manuteno
Conhecido como documentao do sistema Mais tcnico do que o do usurio Inclui: especificaes originais, diagramas usados no projeto (DFD, ER, classes, sequncia, etc.) Problemas graves: a construo e atualizao desta documentao j que a especificao muda, diferentes solues podem ser testadas... A documentao requer atualizao contnua

Manual de manuteno
Documentao interna (dentro do cdigo)
Cabealhos de programas Nomes significativos Comentrios significativo (relativos a funo do programa, das rotinas) Especificao do software Diagrama que mostra estrutura hierrquica de mdulos Explicaes de frmulas complexas Especificao dos dados a serem processados (arquivos, ED, BD) Formatos de telas usadas para interface

Documentao externa (fora do cdigo fonte)

Regras para documentao


Comentrio de cabealho com:
Descrio do produto Autor e data Descrio da entrada e sada e variveis importantes Tipos de dados esperados Descrio da funo do mdulo, entradas e sadas

Comentrios nos mdulos Comentrios em cdigos complicados (algoritmos complexos) Descrever claramente e com preciso os modelos de dados e as ED usadas para represent-los, assim como operaes realizadas por cada procedimento Documentar como ltima etapa no uma boa prtica documente a medida que avana

Ferramentas para documentao


Ferramentas capazes de extrair informaes do cdigo: Ex: JavaDoc, DoxyGen, etc.
Hierarquia de chamadas de rotinas Gera relatrios em PDF, HTML, RTF Diagramas de herana e de chamada de sub-rotinas Declaraes de estruturas de dados Listas alfabticas de variveis, sub-rotinas, mdulos, etc.

Doxygen - Suporta C, Java, C++, C#

Resumo de Aspectos da legibilidade


Ter boa estrutura Bom projeto Bons comentrios Boa documentao Boa escolha de identificadores Boa endentao (indentao) Usar linhas em branco em lugares adequados

Bibliografia
Staa, Arndt von. Programao Modular. Ed. Campus, 2000. Aguilar, L. Joyanes. Fundamentos de Programao: Algoritmos, Estruturas de Dados e Objetos. Ed. McGrawHill, 2008. Koscianski, A. Soares, M. Qualidade de Software. Novatec, 2007.

Вам также может понравиться