O documento discute princípios de projeto de interface com o usuário, como colocar o usuário no controle, reduzir a carga de memória do usuário e fazer a interface consistente. Aborda também avaliação da interface, testes de software, mensagens de erro e casos de teste.

1. Projeto de Interface com o Usuário Profª Renata Vieira Dias Martins UNILESTEMG 4. Quão fácil foi aprender as operações básicas do sistema (escala de
Projeto de Interface Profª Renata Vieira Dias Martins UNILESTEMG 1 a 5)?
O bom projeto de interface com o usuário é Coloque o usuário no controle 5. Comparada com outras interfaces que você já usou, como classifica
fundamental para o sucesso de um sistema. Esconda detalhes técnicos internos do usuário Diversidade de Usuários essa?
Uma interface que é difícil de ser utilizada, na A interface com o usuário deve levar o usuário ao Além disso alguns usuários podem apresentar diferentes Avaliação da Interface - Qualitativo
melhor das hipóteses, resultará em um alto nível mundo virtual da aplicação. O usuário não deve tipos de problemas físicos e, se possível, a interface deve
de erros do usuário. perceber o sistema operacional, funções de ser adaptável para atendê-los. Profª Renata Vieira Dias Martins UNILESTEMG
gerenciamento de arquivos ou outra tecnologia Pode ser necessário fornecer recursos para exibir texto
Profª Renata Vieira Dias Martins UNILESTEMG obsoleta de computação. ampliado, substituir som por texto, produzir botões Os usuários são observados durante a interação e dados -tais como:
grandes, e assim por diante. * Número de tarefas corretamente completadas num tempo padrão
GUI - Graphical User Interface Profª Renata Vieira Dias Martins UNILESTEMG * Freqüência de ações
Vantagens das GUIs são: Profª Renata Vieira Dias Martins UNILESTEMG * Seqüência de ações
1. Relativamente fáceis de aprender e utilizar; Coloque o usuário no controle * Tempo gasto “olhando” o monitor de vídeo
2. O usuário tem várias telas para a interação Projete a interação direta com objetos que Princípios de Projeto com o Usuário * Número de erros
com o sistema; aparecem na tela * Tempo de recuperação de erro
3. É possível a interação rápida com a tela O usuário tem uma sensação de controle quando Profª Renata Vieira Dias Martins UNILESTEMG * Tempo gasto olhando a ajuda
inteira pode manipular os objetos que são necessários * Número de referências à ajuda num tempo padrão
para realizar uma tarefa de modo semelhante ao Interação com Usuários São coletadas e usadas como diretriz na modificação da interface.
Profª Renata Vieira Dias Martins UNILESTEMG que iria ocorrer se o objeto fosse uma coisa física. Avaliação da Interface – Quantitativo
Por exemplo, uma interface uqe permite a um Profª Renata Vieira Dias Martins UNILESTEMG
GUI - Graphical User Interface usuário “esticar” um objeto (aumentá-lo de tamanho)
é uma implementação de manipulação direta. Projeto de Interface
Profª Renata Vieira Dias Martins UNILESTEMG 1. O usuário está interessado em informações precisas Testes_de_Software
Profª Renata Vieira Dias Martins UNILESTEMG ou nas relações entre diferentes valores de dados?
Projeto de Interface com o Usuário 2. Com que rapidez os valores das informações são Técnicas de Testes de Software
O que é? Seguindo um conjunto de princípios Reduza a carga de memória do usuário modificados? A mudança em um valor deve ser Profª Renata Vieira Dias Martins UNILESTEMG
de projeto de interface, o projeto identifica Reduza a demanda da memória de curto prazo imediatamente ao usuário? Uma vez gerado o código-fonte, o software deve ser testado para
objetos e ações de interface e depois cria um Quando os usuário estão envolvidos em tarefas 3. O usuário deve tomar alguma iniciativa em resposta a descobrir e corrigir tantos erros quanto possível antes de ser entregue
leiaute de tela que forma a base para um complexas, a demanda da memória de curto prazo uma mudança nos informações? ao cliente.
protótipo de interface com o usuário. pode ser significativa. A interface deve ser projetada 4. O usuário precisa interagir com as informações exibidas Sua meta é projetar uma série de casos de teste que têm alguma
Quais são os passos? Começa com a para reduzir a necessidade de lembrar ações e por meio de uma interface de manipulação direta? probabilidade de encontrar erros – mas como?
identificação dos requisitos de usuário, das resultados anteriores. Isso pode ser conseguido 5. As informações a serem exibidas são textuais ou O que é?
tarefas e do ambiente. através de indicadores visuais que permitem ao numéricas? O valores relativos dos itens das informações Profª Renata Vieira Dias Martins UNILESTEMG
usuário reconhecer ações anteriores. são importantes? É aí que as técnicas de testes de software entram em cena fornecendo
Profª Renata Vieira Dias Martins UNILESTEMG diretrizes sistemáticas para projetar testes que exercitam:
Profª Renata Vieira Dias Martins UNILESTEMG Profª Renata Vieira Dias Martins UNILESTEMG * a lógica interna dos componentes do software
Projeto de Interface com o Usuário * os domínios de entrada e saída do programa para descobrir erros
Qual o produto do trabalho? Cenários do Reduza a carga de memória do usuário Ambiente de Trabalho Físico na função, comportamento e desempenho do programa
usuário são criados e leiautes de telas são Estabeleça defaults significativos * Onde a interface será localizada fisicamente? Como?
gerados. Um protótipo de interface é O conjunto inicial de parâmetros (defaults) deve * O usuário vai estar sentado, em pé, ou realizando Profª Renata Vieira Dias Martins UNILESTEMG
desenvolvido. fazer sentido para o usuário médio, mas o usuário outras tarefas não-relacionadas à interface? Por que é importante?
Como garanto que fiz corretamente? O protótipo deve poder especificar preferências individuais. No * O hardware da interface acomoda as restrições de Erros podem vir a ocorrer até no início do processo, onde os objetivos
é direcionado a “testes” pelos usuários e a entanto, uma opção “reset” (refazer os parâmetros espaço, luz ou ruído? podem ser errônea ou imperfeitamente especificados, bem como em
realimentação a partir do teste de iniciais) deve ser estar disponível, permitindo a * Há considerações especiais de fatores humanos estágios posteriores do projeto e desenvolvimento. Por causa da
direcionamento é usada para a modificação do redefinição dos valores originais. determinados por fatores ambientais? inabilidade humana de realizar e de se comunicar com perfeição, o
protótipo. desenvolvimento é acompanhado por uma atividade de garantia de
Profª Renata Vieira Dias Martins UNILESTEMG Profª Renata Vieira Dias Martins UNILESTEMG qualidade.
Profª Renata Vieira Dias Martins UNILESTEMG
Reduza a carga de memória do usuário Tarefa de Validação Profª Renata Vieira Dias Martins UNILESTEMG
Projeto de Interface com o Usuário Defina atalhos que são intuitivos * Capacidade da interface de implementar todas as Por que é importante?
O projeto de interface com o usuário tem tanto a Quando são usados mnemônicos para realizar uma tarefas do usuário corretamente, de acomodar todas as Teste de software é um elemento crítico da garantia de qualidade do
ver com o estudo de pessoas quanto com função do sistema (p. ex., alt+P para invocar a variantes de tarefa e de atingir todos os requisitos gerais software e representa a revisão final da especificação, projeto e
aspectos tecnológicos. função de impressão), o mnemônico deve ser ligado do usuário; geração de código.
o Quem é o usuário? à ação de um modo que seja fácil de lembrar (p. ex. * O grau em que a interface é fácil de usar e fácil de Não é raro uma organização de desenvolvimento gastar de 30 a 40%
o Como ele aprende a interagir com um primeira letra da tarefa a ser invocada) aprender do esforço total do projeto no teste. A rigor, o teste do software que
novo sistema baseado em computador? * A aceitação dos usuários da interface como envolve vidas pode custar de três a cinco vezes mais do que todos os
o Como interpreta a informação produzida Profª Renata Vieira Dias Martins UNILESTEMG ferramenta útil ao seu trabalho. outros passos de Engenharia de Software combinados!
pelo sistema?
Reduza a carga de memória do usuário Profª Renata Vieira Dias Martins UNILESTEMG Profª Renata Vieira Dias Martins UNILESTEMG
Profª Renata Vieira Dias Martins UNILESTEMG O leiaute visual da interface deve ser baseada numa Quais são os passos?
metáfora do mundo Aspectos do Projeto O engenheiro cria uma série de casos de testes, que são destinados a
Projeto de Interface com o Usuário Por exemplo, um sistema de pagamentos de contas A medida que o projeto de interface com o usuário evolui, “demolir” o software que foi construído.
Regras de Ouro - Theo Mandel deve usar uma metáfora de talão e canhoto de quatro questões comuns de projeto quase sempre Um conjunto de casos de teste planejado é projetado e documentado
1. Coloque o usuário no controle cheques para guiar o usuário durante o processo de aparecem: para exercitar tanto a lógica interna quanto os requisitos externos. Os
2. Reduza a carga de memória do usuário pagamento de contas. Isso permite ao usuário se * Tempo de resposta do sistema; resultados esperados e os resultados reais são registrados.
3. Faça a interface consistente apoiar em indicações visuais bem-entendidas, ao * Facilidade de ajuda ao usuário; O processo de teste deve-se tentar “quebrar” arduamente o software !
invés de memorizar uma seqüência de interação * Manipulação de erro;
Profª Renata Vieira Dias Martins UNILESTEMG esotérica. * Rotulação de comandos. Profª Renata Vieira Dias Martins UNILESTEMG
Objetivos do teste
Coloque o usuário no controle Profª Renata Vieira Dias Martins UNILESTEMG Profª Renata Vieira Dias Martins UNILESTEMG * É o processo de execução de um programa com o objetivo de
“O que eu realmente gostaria é de um sistema encontrar um erro
que leia a minha mente. Que saiba o que eu Reduza a carga de memória do usuário Facilidade de Ajuda * Um bom caso de teste é aquele que tem alta probabilidade de
quero fazer antes que eu precise fazê-lo e torne Revele informação de modo progressivo É projetada no software desde o início ou é integrada ao encontrar um erro
muito fácil para mim conseguir que seja feito. A interface deve ser organizada hierarquicamente. software após o sistema ter sido construído? * Um teste bem-sucedido é aquele que descobre o erro ainda não
Isso é tudo, apenas isso” Isto é, a informação sobre a tarefa, um objeto ou * A ajuda vai estar disponível para todas as funções do descoberto
algum comportamento deve ser inicialmente sistema em todos os momentos durante a interação do O teste não pode mostrar a ausência de erros e defeitos, mas apenas
Profª Renata Vieira Dias Martins UNILESTEMG apresentada num alto nível de abstração. Mais sistema? mostrar que erros e defeitos do software estão presentes!
detalhes devem ser apresentados, após o usuário * Como o usuário vai solicitar ajuda?
Coloque o usuário no controle indicar interesse com um clique do mouse. Ex: * Como a ajuda vai ser representada? Profª Renata Vieira Dias Martins UNILESTEMG
A maioria das limitações e restrições de Sublinhar em processadores de texto. * Como o usuário vai voltar à interação normal? Princípios do teste
interface que são impostas por um projetista são * Como a informação de ajuda vai ser estruturada? * Todos os testes dever ser relacionados aos requisitos do cliente
destinadas a simplificar o modo de interação. Profª Renata Vieira Dias Martins UNILESTEMG * Os testes devem ser planejados muito antes do início do teste
Mas para quem? Profª Renata Vieira Dias Martins UNILESTEMG * O teste deve começar “no varejo” e progredir até o teste “no
Em muitos casos o projetista pode introduzir Faça a interface consistente atacado”
restrições e limitações para simplificar a Permita ao usuário situar a tarefa atual num Mensagens e Alertas de Erro * Teste completo não é possível
implementação da interface. contexto significativo * Deve descrever o problema num jargão que o usuário * Para ser mais efetivo, o teste deveria ser conduzido por terceiros
É importante fornecer indicadores (p ex. títulos de possa entender;
Profª Renata Vieira Dias Martins UNILESTEMG janelas, ícones gráficos, código de cores * Deve fornecer sugestões construtivas para se Profª Renata Vieira Dias Martins UNILESTEMG
consistente) que permitem ao usuário saber o recuperar do erro; São impraticáveis os testes exaustivos
Coloque o usuário no controle contexto do trabalho em mãos. Além disso, o * Deve indicar quaisquer conseqüências negativas do Testes têm que ser baseados em um subconjunto de possíveis casos
Defina os modos de interface de uma forma que usuário deve poder determinar de onde veio e que erro; de testes
não force o usuário a ações desnecessárias ou alternativas existem de transição para uma nova * Deve ser acompanhada por uma indicação audível ou As políticas de testes podem ter como base a experiência de utilização
indesejadas tarefa. visual; do sistema
Um modo de interação é o estado atual da * Deve ser não “opinativa”, ou seja, nunca colocar a Detecção de defeitos
interface. Por exemplo, uma opção para verificar Profª Renata Vieira Dias Martins UNILESTEMG culpa no usuário.
ortografia num processador de textos, o usuário Profª Renata Vieira Dias Martins UNILESTEMG
deve entrar e sair do modo com pouco ou Faça a interface consistente Profª Renata Vieira Dias Martins UNILESTEMG Projeto – Casos de Teste
nenhum esforço. Mantenha consistência ao longo de uma família de Qualquer produto pode ser testado por uma das duas maneiras:
aplicações Mensagens e Alertas de Erro * sabendo a função especificada que o produto foi projetado para
Profª Renata Vieira Dias Martins UNILESTEMG Um conjunto de aplicações (ou produtos) deve realizar, podem se realizados testes que demonstram que cada função
implementar as mesmas regras de projeto, de modo Profª Renata Vieira Dias Martins UNILESTEMG está plenamente operacional, enquanto ao mesmo tempo procuram
Coloque o usuário no controle que seja mantida a consistência para toda erros em cada função;
Proporcione interação flexível interação. Comandos e os menus do sistema devem Mensagens e Alertas de Erro * sabendo como é o trabalho interno de um produto, podem ser
Como diferentes usuários têm diferentes ter o mesmo formato e os parâmetros devem ser realizadas de acordo com as especificações e que todos os
preferências de interação, a escolha deve ser fornecidos a todos os comandos da mesma Profª Renata Vieira Dias Martins UNILESTEMG componentes internos foram adequadamente exercitados.
oferecida. Exemplo: Usuário interagir por meio maneira.
de comando de teclado, movimento do mouse, Comando Digitado - Projeto Profª Renata Vieira Dias Martins UNILESTEMG
caneta digitadora, comandos de Profª Renata Vieira Dias Martins UNILESTEMG * Cada opção de menu vai ter um comando Utilizando métodos de teste caixa-branca pode-se derivar casos de
reconhecimento de voz. Mas nem toda ação é correspondente? teste que:
adequada a todos os mecanismos de interação Faça a interface consistente * Que forma os comando vão tomar? Seqüência de * Garantam que todos os caminhos independentes de um módulo
Se modelos interativos anteriores criaram controle, teclas de função ou palavra digitada. tenham sido exercitados pelo menos uma vez;
Profª Renata Vieira Dias Martins UNILESTEMG expectativas para o usuário, não faça modificações, * Quão difícil será aprender e lembrar os comandos? O * Exercitam todas as decisões lógicas em seus lados verdadeiro e
a menos que haja forte razão para isso que pode ser feito se um comando for esquecido? falso;
Coloque o usuário no controle Quando uma seqüência interativa particular torna-se * Os comandos podem ser personalizados ou * Checam todos os ciclos nos seus limites e dentro de seus
Permita que a interação com o usuário possa um padrão de fato (p. ex. o uso de alt+S para salvar abreviados pelo usuário? intervalos operacionais;
ser interrompida e desfeita um arquivo), o usuário espera isso em toda a * Estabeleça Convenções! * Exercitam as estruturas de dados internas para garantir sua
Mesmo quando envolvido numa seqüência de aplicação que encontra. Uma modificação vai validade.
ações, o usuário deve poder interromper a causar confusão Profª Renata Vieira Dias Martins UNILESTEMG Testes Caixa Branca
seqüência para fazer alguma outra coisa. O
usuário deve poder “desfazer” qualquer ação, Profª Renata Vieira Dias Martins UNILESTEMG Cores no Projeto de Interface Profª Renata Vieira Dias Martins UNILESTEMG
inevitavelmente cometem erros. Confirme ações 1. Limite o número de cores utilizadas e seja conservador Inspeções de Software
destrutivas. Faltou um item nesta lista. Qual? no modo de utilizá-las * Não requerem que o programa seja executado e provam ser uma
É o princípio da assistência ao usuário. As 2. Utilize a mudança de cores para mostrar uma técnica eficaz na detecção de erros;
Profª Renata Vieira Dias Martins UNILESTEMG interfaces devem ter opções de assistência ou modificação no status do sistema * Também pode considerar outros atributos de qualidade, como
recursos de ajuda ao usuário inseridas. Mensagens 3. Utilize código de cores para apoiar a tarefa que os conformidade com padrões, a portabilidade e a facilidade de
Coloque o usuário no controle de erros cometidos pelo usuário e recursos de ajuda usuários estão tentando realizar manutenção;
Simplifique a interação à medida que os níveis sensíveis ao contexto. 4. Utilize código de cores de maneira cuidadosa e * Muitos defeitos diferentes podem ser testados com uma única
de competência progridem e permita que a consistente sessão de inspeção;
interação seja personalizada Profª Renata Vieira Dias Martins UNILESTEMG 5. Seja cuidadoso quanto a pares de cores. * Reutilizam o conhecimento de domínio e de linguagem.
Os usuário freqüentemente descobrem que
realizam a mesma seqüência de interações Outro aspecto a ser sempre avaliado. Qual? Profª Renata Vieira Dias Martins UNILESTEMG Profª Renata Vieira Dias Martins UNILESTEMG
repetidamente. Vale a pena projetar um É o princípio da diversidade de usuários. Inspeções devem substituir os testes?
mecanismo “macro” que permita a um usuário * Usuários Casuais - precisam de interfaces que 1. Os ícones são auto explicativos? Em caso negativo que * É quase sempre impraticável inspecionar um sistema inteiro, com
avançado personalizar a interface para facilitar a forneçam interação ícones não são claros? uma série de subsistemas;
interação. * Usuários Freqüentes - requerem atalhos que 2. As ações são fáceis de lembrar e de invocar?
lhes permitam interagir o mais rápido possível 3. Quantas ações diferentes você usou?

2. * Os testes caixa preta são também * o teste começa em nível de componente e É virtualmente impossível que se preveja como o cliente realmente
necessários para a avaliação de confiabilidade, prossegue “para fora”, em direção ao todo o sistema Profª Renata Vieira Dias Martins UNILESTEMG usará um programa. As instruções de uso podem ser mal-
a análise de desempenho, a validação de * diferentes técnicas de testes são adequadas em Teste de Unidade interpretadas, combinações estranhas de dados podem ser
interface com o usuário e para checar os diferentes momentos Erros potenciais que devem ser testados quando a regularmente usadas, saídas que pareciam claras ao analista podem
requisitos; * o teste é conduzido pelo desenvolvedor e, para manipulação de erros é avaliada são: ser ininteligíveis para um usuário em campo.
* Inspeções e Testes Caixa Preta não são projetos grandes, por um grupo de teste o A descrição do erro é ininteligível. Para um Software Customizado para um Cliente são realizados testes
técnicas concorrentes de Verificação. independente o O erro mencionado não corresponde ao erro de aceitação, conduzidos pelo usuário final a fim de capacitá-lo e para
Inspeções de Software * o teste e a depuração são atividades diferentes encontrado. validar todos os requisitos. Pode variar de um test drive informal a uma
mas a depuração deve fazer parte de qualquer o A condição de erro provoca a intervenção do série de testes planejados.
Profª Renata Vieira Dias Martins UNILESTEMG estratégia de teste sistema antes da manipulação do erro. Testes Alfa e Beta
São revisões cujo objetivo é a detecção de Abordagem Estratégica o O processamento da condição de exceção está Testes de Validação
defeitos no programa incorreto.
Para cada declaração condicional, a condição Profª Renata Vieira Dias Martins UNILESTEMG o A descrição de erro não fornece informação Profª Renata Vieira Dias Martins UNILESTEMG
está correta? Abrange muitas das atividades a que nos referimos suficiente para ajudar na localização da causa do erro. Se o software é desenvolvido como um produto a ser usado por vários
Cada loop está certo para terminar? como garantia da qualidade de software (SQA) clientes, não é prático realizar testes formais de aceitação de cada um.
As declarações compostas estão corretamente Validação: Estamos construindo o produto certo? Profª Renata Vieira Dias Martins UNILESTEMG A maioria dos desenvolvedores de software usa um processo
entre parênteses? Os requisitos descritos atendem às necessidades Teste de Unidade chamado teste alfa e beta para descobrir erros que apenas o usuário
Em declarações ‘case’ todos os casos são do cliente? * Teste de limite é a última tarefa (e provavelmente a final parece capaz de descobrir.
levados em conta? Verificação: Estamos construindo certo o produto? mais importante) do passo de teste de unidade. O Testes de Validação
Se um identificador BREAK é requerido após O que está implementado está de acordo com os software frequentemente falha nos seus limites. Isto é, Testes Alfa e Beta
cada caso em declarações ‘case’, esse requisitos descritos no documento? frequentemente ocorre um erro quando n-ésimo elemento
identificador foi incluído? Verificação e Validação de uma matriz n-dimensional é processado, quando a i- Profª Renata Vieira Dias Martins UNILESTEMG
Defeitos de Controle ésima repetição de um ciclo com i passos é invocada, Teste Alfa - É conduzido nas instalações do desenvolvedor com o
Todas as variáveis de programa são iniciadas Profª Renata Vieira Dias Martins UNILESTEMG quando o valor máximo e mínimo permissível é cliente. O software é usado num ambiente natural com o
antes de seus valores serem utilizadas? Há um conflito de interesses inerente que ocorre encontrado. desenvolvedor "olhando sobre os ombros" do usuário e registrando
Todas as constantes foram denominadas? quando o teste começa. O pessoal que construiu o * Casos de teste que exercitam a estrutura de dados, erros e problemas de uso. São conduzidos num ambiente controlado
O limite superior de vetores deve ser igual ao software é agora solicitado a testá-lo. Isso parece fluxo de controle e valores de dados imediatamente Teste Beta - é realizado nas instalações do cliente pelo usuário final do
tamanho do vetor ou ao tamanho –1? inócuo em si mesmo; afinal de contas, quem abaixo, sobre e imediatamente acima do máximo e do software. O desenvolvedor não está presente. O cliente registra os
Existe alguma possibilidade de overlow de conhece o programa melhor do que seus mínimo têm grande probabilidade de descobrir erros. problemas (reais ou imaginários) que são encontrados e os relata ao
buffer? desenvolvedores? Infelizmente, esses mesmos desenvolvedor a intervalos regulares.
Defeitos nos desenvolvedores têm um interesse oculto em Profª Renata Vieira Dias Martins UNILESTEMG Testes de Validação
Dados demonstrar que o programa está livre de erros, que Uma vez testados os componentes individuais de
Checagem de Inspeção funciona de acordo com os requisitos do cliente e programa, eles devem ser integrados para criar um Profª Renata Vieira Dias Martins UNILESTEMG
Classe de defeitos que vai ser completado de acordo com o sistema parcial ou completo. O que o engenheiro de software deve fazer?
Inspeções de Software cronograma e dentro do orçamento. Os testes de integração devem ser desenvolvidos a partir 1. Projetar caminhos de tratamento de erros que testem todas as
Cada um desses interesses se da especificação do sistema e começar assim que as informações que chegam de outros elementos do sistema.
Profª Renata Vieira Dias Martins UNILESTEMG contrapõe a um teste rigoroso. versões de alguns dos componentes do sistema estejam 2. Realizar uma série de testes que simulem dados ruins ou outros
Todas as possíveis condições de erros foram Organização disponíveis. erros em potencial na interface do software.
levadas em conta? Há complexas interações entre os componentes de 3. Registrar os resultados de teste para usar como "prova" se alguém
Defeitos de Gerencia-mento de Exceções Profª Renata Vieira Dias Martins UNILESTEMG sistema e, quando uma saída anômala é descoberta, lhe apontar o dedo.
Se uma estrutura ligada é modificada, todos os Para desenvolver o software nos movemos em pode ser difícil encontrar a origem do erro. 4. Participar do planejamento e projeto dos testes do sistema para
links foram corretamente redesignados? espiral para dentro. Testes de Integração garantir que o software seja adequadamente testado.
Se o armazenamento dinâmico é utilizado, o Uma estratégia para teste de software pode também Testes de Sistema
espaço foi alocado corretamente? ser vista no contexto da espiral, de dentro para fora. Profª Renata Vieira Dias Martins UNILESTEMG
O espaço é explicitamente liberado, depois que Uma Estratégia Integração não incremental: abordagem "big-bang". O Profª Renata Vieira Dias Martins UNILESTEMG
não é mais necessário? Teste de Sistema programa completo é testado como um todo e o resultado Muitos sistemas baseados em computador precisam recuperar-se de
Defeitos de Gerencia-mento de Armazena- Teste de Validação é o caos. Quando erros são encontrados, a correção é falhas e retomar o processamento dentro de um tempo previamente
mento Teste de Integração difícil porque o isolamento das causas é complicado pela especificado.Em certos casos, o sistema deve tolerar falhas, isto é, o
Todas as chamadas de funções e métodos têm Teste de Unidade vasta amplitude do programa inteiro. processamento de falhas não deve fazer com que uma função global
o número correto de parâmetros? Integração Incremental: o programa é construído e de sistema cesse.
Os tipos formais e reais de parâmetros Profª Renata Vieira Dias Martins UNILESTEMG testado em pequenos segmentos, onde os erros são mais Em outros casos, uma falha do sistema deve ser corrigida dentro de
combinam? Os parâmetros estão na ordem Inicialmente o teste focaliza cada componente fáceis de serem isolados e corrigidos; as interfaces têm um período previamente especificado; caso contrário, graves prejuízos
certa? individualmente, garantindo que funciona maior probabilidade de serem testadas completamente e econômicos ocorrerão.
Se componentes acessam memória adequadamente como uma unidade. uma abordagem sistemática ao teste pode ser aplicada. O teste de recuperação é um teste de sistema que força o software a
compartilhada, eles têm o mesmo modelo da O teste de unidade faz uso de técnicas de caixa- Testes de Integração falhar de diversas maneiras e verifica se a recuperação é
estrutura de memória compartilhada? branca intensivamente, exercitando caminhos adequadamente executada.
Defeitos de Interface específicos na estrutura de controle de um módulo, Profª Renata Vieira Dias Martins UNILESTEMG Teste de Recuperação
Todas as variáveis de entrada são utilizadas? para garantir completa cobertura e máxima Inicialmente, é necessário integrar uma configuração Testes de Sistema
Todas as variáveis de saída têm um valor detecção de erros. mínima do sistema e testar esse sistema.
designado antes de saírem? O teste de integração cuida dos aspectos Em seguida, são adicionados componentes a essa Profª Renata Vieira Dias Martins UNILESTEMG
Entradas inesperadas podem fazer com que os associados aos problemas duais de verificação e configuração mínima, que é testada depois de cada Qualquer sistema baseado em computador que gerencie informações
dados sejam corrompidos? construção de programas. As técnicas de projeto de componente adicionado. delicadas ou provoque ações que possam impropriamente prejudicar
Defeitos de Entrada/ Saída casos de teste caixa-preta são mais prevalentes Os testes realizados (ou beneficiar) pessoas constitui um alvo para o acesso impróprio ou
Inspeções de Software durante a integração, apesar de uma quantidade inicialmente devem ilegal.
limitada de testes caixa-branca poder ser usada ser repetidos O teste de segurança tenta verificar se todos os mecanismos de
Profª Renata Vieira Dias Martins UNILESTEMG para garantir a cobertura dos principais caminhos de a cada adição de proteção embutidos num sistema o protegerão, de fato, de acessos
A medida que uma organização adquire controle. componentes. indevidos.
experiência no processo de inspeção, ela pode Uma Estratégia Testes de Integração Durante o teste de segurança, o analista desempenha o papel de
utilizar os resultados desse processo como meio pessoa que deseja penetrar no sistema. Qualquer coisa vale!
de aperfeiçoa-lo. Profª Renata Vieira Dias Martins UNILESTEMG Profª Renata Vieira Dias Martins UNILESTEMG Teste de Segurança
A quantidade de código que pode ser Depois que o software foi integrado, um conjunto de Testes de Integração/Interface Testes de Sistema
inspecionada em um determinado tempo testes de alto nível é conduzido. Critérios de Os erros são um resultado da interação entre objetos e
depende da experiência da equipe de inspeção, validação (estabelecidos durante a análise de não do comportamento isolado em um único objeto. Profª Renata Vieira Dias Martins UNILESTEMG
da linguagem de programação e do domínio da requisitos) precisam ser testados. As setas para a delimitação da caixa significam que os o adquirir senhas mediante contatos externos
aplicação. Os testes de validação fornecem garantia final de casos de teste não são aplicados aos componentes o atacar o sistema com software customizado projetado para
Inspeções de Software que o software satisfaz todos os requisitos individuais, mas aos subsistemas criados pela derrubar quaisquer defesas que tenham sido construídas
funcionais, comportamentais e de desempenho. As combinação desses componentes. o desarmar o sistema, negando serviço a outros
Profª Renata Vieira Dias Martins UNILESTEMG técnicas de teste caixa-preta são as únicas usadas o provocar erros intencionalmente, esperando acessá-lo durante
Testes Funcionais ou Comportamentais durante a validação. Profª Renata Vieira Dias Martins UNILESTEMG a recuperação
* Não é uma alternativa às técnicas caixa- O software, uma vez validado, deve ser combinado Parâmetros: Dados ou referências de funções são o "folhear" através de dados inseguros esperando descobrir a
branca com os outros elementos do sistema (p.ex. o passados de um componente para o outro. chave para a entrada no sistema.
* Focado na funcionalidade e não na hardware, o pessoal, as bases de dados). O teste Memória compartilhada: Um bloco de memória é O papel do projetista do sistema é fazer com que o acesso custe mais
implementação do software. Despreza, de de sistema verifica se todos os elementos compartilhado entre subsistemas. Os dados são do que o valor da informação que será obtida.
propósito, a estrutura de controle, a atenção é combinam adequadamente e se a colocados na memória por um subsistema e são Testes de Sistema
focalizada no domínio da informação. função/desempenho global do sistema é recuperados a partir daí por outros subsistemas. Teste de Segurança
Tenta encontrar erros nas seguintes categorias: conseguida. Procedimento: Um subsistema encapsula um conjunto de
o Funções incorretas ou omitidas Uma Estratégia procedimentos que podem ser chamados por outros Profª Renata Vieira Dias Martins UNILESTEMG
o Erros de interface subsistemas. Os objetos e os tipos de dados têm essa Testes de Estresse
o Erros de estrutura de dados ou de Profª Renata Vieira Dias Martins UNILESTEMG forma de interface. Uma vez que o sistema tenha sido completamente integrado, é
acesso a base de dados externa “Quando terminamos o teste para saber se Passagem de mensagem: um subsistema pede um possível testá-lo quanto a desempenho e confiabilidade.
o Erros de comportamento ou testamos suficientemente?” serviço de outro subsistema, passando-lhe uma Sistemas são projetados para uma determinada carga.
desempenho Infelizmente não há resposta definitiva para esta mensagem. Uma mensagem de retorno inclui os Testes de estresse continuam além da carga máxima até que o
o Erros de inicialização e término questão, mas há algumas respostas pragmáticas e resultados da execução do serviço. Alguns sistemas sistema falhe.
Testes Caixa Preta primeiras tentativas de respostas empíricas. orientados a objetos têm esse tipo de interface, como Testes de Sistema
Uma reposta à questão é: “Você nunca acaba de acontece com os sistemas cliente-servidor.
Profª Renata Vieira Dias Martins UNILESTEMG testar, o encargo simplesmente passa de você para Testes de Integração/Interface Profª Renata Vieira Dias Martins UNILESTEMG
* Diferente do teste caixa-branca, que é o seu cliente”. Esse tipo de teste tem duas funções:
realizado no início do processo de teste, o teste Outra resposta (um tanto cínica, mas não obstante Profª Renata Vieira Dias Martins UNILESTEMG 1. Testa o comportamento de falha do sistema - eventos inesperados.
caixa-preta tende a ser aplicado durante os precisa) é: “Você acaba de testar quando o tempo Testes de Validação 2. Causa estresse no sistema e pode acarretar a detecção de defeitos
últimos estágios do teste. ou o dinheiro acaba” Ao término da atividade de teste de integração, o software que, normalmente não se manifestariam.
* Hetzel descreve o teste caixa-branca como está completamente montado como um pacote, erros de São particularmente relevantes
“teste de varejo”. Sua implicação é de que os Profª Renata Vieira Dias Martins UNILESTEMG interface foram descobertos e corrigidos e uma série final para sistemas distribuídos
testes caixa-branca são tipicamente aplicados a Teste de Unidade de testes de software – os testes de validação – podem Testes de Estresse
pequenos componentes de programa (p.ex. * A interface do módulo é testada para garantir começar. Testes de Sistema
módulos ou pequenos grupos de módulos). O que a informação flui adequadamente para dentro e A validação é bem sucedida quando o software funciona
teste caixa-preta, por outro lado, amplia nosso para fora da unidade de programa que está sendo de uma maneira razoavelmente esperada pelo cliente.
enfoque e pode ser chamado de “teste por testada. A Especificação de Requisitos de Software contém os Métricas e Estimativas
atacado”. * A estrutura de dados local é examinada para critérios de validação que formam a base para uma
Caixa-Branca x Caixa-Preta garantir que dados armazenados temporariamente abordagem ao teste de validação. Métricas e Medição de Software
mantêm sua integridade durante todos os passos da * Métrica é uma indicação do que e como medir.
Estratégias de Teste de Software execução. Profª Renata Vieira Dias Martins UNILESTEMG * Na Engenharia de Software, mede-se um software por várias
Profa. Renata Vieira Dias Martins * As condições limites são testadas para garantir A validação do software é realizada por meio de uma série razões:
UnilesteMG que o módulo opera adequadamente nos limiares de testes de caixa preta que demonstram a conformidade o Indicar a qualidade do produto
renatavd@uol.com.br estabelecidos para limitar ou restringir o com os requisitos. o Avaliar a produtividade das pessoas durante o projeto
“Como a morte e os impostos, o teste é tanto processamento. O plano e o procedimento de teste são projetados para o Avaliar os benefícios derivados de novos métodos e/ou
desagradável quanto inevitável” * Os caminhos independentes ao longo da garantir que: ferramentas de software
Ed Yourdon estrutura de controle são exercitados para garantir o todos os requisitos funcionais são satisfeitos; o Estabelecer uma baseline para futuras comparações e
que todos os comandos de um módulo tenham sido o todos os requisitos de desempenho são estimativas
Profª Renata Vieira Dias Martins UNILESTEMG executados pelo menos uma vez. conseguidos; o Justificar o pedido de novas ferramentas ou treinamento
O projeto efetivo de casos de teste é importante, * Todos os caminhos de manipulação de erros o a documentação está correta; adicional
mas a estratégia que você usa para executá-los são testados. o outros requisitos são cumpridos: portabilidade,
também é. compatibilidade, remoção de erros e manutenibilidade. * Existem diversos tipos de medidas, que podem ser divididas em
* Deve desenvolver um plano formal para os Profª Renata Vieira Dias Martins UNILESTEMG Testes de Validação duas classes principais:
testes? Teste de Unidade o Métricas de produtividade
* Deve testar o programa inteiro como um * O teste de unidade é normalmente considerado Profª Renata Vieira Dias Martins UNILESTEMG Permitem avaliar a produtividade do processo. Ou seja, avaliar a
todo ou apenas uma pequena parte dele? um apêndice ao passo de codificação. Um elemento importante do processo de validação é a eficiência do processo em relação a custos, prazos, recursos, etc.
* Deve reexecutar testes que já conduziu * Um bom projeto determina que condições de revisão de configuração ou auditoria. o Métricas de qualidade
quando adicionados um novo componente a um erros sejam antecipadas e caminhos de O propósito dessa revisão é garantir que todos os Permitem avaliar a qualidade do software. Isto é, verificar se o
sistema grande? manipulação de erros estabelecidos para elementos da configuração de software tenham sido número de erros está muito grande para o tamanho do programa, etc.
* Quando o cliente deve estar envolvido? redirecionar ou claramente terminar o adequadamente desenvolvidos, estão catalogados e têm * Em qualquer das classes, elas podem ser também classificadas
O que é? processamento quando um erro efetivamente os detalhes necessários para apoiar a fase de em duas outras categorias:
ocorre. manutenção do ciclo de vida do software. o Medidas diretas – por exemplo, o comprimento de uma mesa
Profª Renata Vieira Dias Martins UNILESTEMG * Yourdon chama esta abordagem de Revisão de Configuração ou o número de linhas de código
Todas as estratégias de teste de software antidefeitos. Infelizmente, há uma tendência de Testes de Validação o Medidas indiretas – a “qualidade” do parafuso ou a qualidade
fornecem ao desenvolvedor um gabarito de incorporar manipulação de erros no software e de um software.
teste e as seguintes características genéricas: depois nunca testá-la. Profª Renata Vieira Dias Martins UNILESTEMG Tipos de Métricas

3. do usuário o Ameaça: probabilidade de que um ataque determinou-se que o projeto exigiria aproximadamente 150 pessoas-
MEDIDAS DO SOFTWARE nro de arquivos x 7 10 ocorrerá dentro de um determinado tempo mês de esforço para ser concluído.
MEDIDAS DIRETAS 15 o Segurança: probabilidade de que o ataque será * Usando-se um modelo empírico, estimou-se que a duração do
MEDIDAS INDIRETAS nro de interfaces x 5 7 contido. projeto se estenderia por aproximadamente 15 meses de calendário.
* Custo 10 Integridade = S [1 – ameaça x (1-segurança)] * E agora? Apenas "começamos"?
* Esforço externas Integridade * A resposta, naturalmente, é NÃO.
* Linhas de Código Contagem-Total
* Velocidade de Execução Métricas * Mede se o software é amigável, ou user-friendly. O Planejamento de Projetos Integração
* Memória * A usabilidade tenta quantificar o quão amigável o * Antes de começar devemos :
* Nro de Erros * Após preencher os dados da contagem, deve-se software é, por meio de quatro características: o responder a algumas questões importantes sobre riscos
* Funcionalidade multiplicar por um valor de complexidade. o a habilidade física e/ou intelectual exigida para se o desenvolver uma estratégia para atacarmos o problema
* Qualidade * Cada empresa utiliza seus próprios critérios aprender o sistema; o estabelecer um mecanismo para avaliarmos o progresso
* Complexidade para definir se a complexidade é pequena, média ou o o tempo exigido para se tornar moderadamente o organizar os membros do pessoal que foram escolhidos para
* Eficiência alta. eficiente no uso do sistema construir o produto.
* Confiabilidade * Após definir a contagem total, calcula-se um o o aumento líquido de produtividade (quando o o cada uma dessas atividades faz parte do planejamento do
* Manutenabilidade valor final FP (Function Point): sistema substituiu outro) quando o sistema é usado por projeto
Tipos de Métricas FP = contagem total x [0,65 + (0,01xSOMA(Fi))] alguém moderadamente eficiente. Estimativas do Projeto de Software
* Os valores constantes da equação são o avaliação subjetiva das atitudes dos usuários em Profa. Renata Vieira Dias Martins
* Exemplos de medidas diretas: determinados empiricamente. relação ao sistema. UnilesteMG
o custo do software em R$, US$, etc. * Os valores de Fi também se referem a ajustes Usabilidade renatavd@uol.com.br
o tempo gasto para produção de complexidade, com base na resposta das 14
o número de linhas de código produzidas perguntas – Segundo Passo: * Por que medir qualidade? Introdução
o Velocidade de execução (em segundos) o Avaliar a efetividade do processo de engenharia * Seção anterior – Métricas de Software
de uma tarefa MÉTRICA ORIENTADA À FUNÇÃO - PF de software o Indicam COMO medir a qualidade e produtividade
o Tamanho de memória ocupado pelo 2) Responder as questões 1-14, considerando a o Tomar providências para corrigir elementos do o Utilizadas antes, durante e após o desenvolvimento
software escala de 0 a 5: processo que produzem defeitos o Objetivo: identificar problemas e gerar soluções
o Número de erros encontrados em um influência 0 1 2 3 4 5 o O gerente pode identificar quais qualidades são * Agora: Estimativas de software
espaço de tempo nenhuma pouca moderada média importantes em cada caso o São realizadas antes do desenvolvimento de software. No
* Exemplos de medidas indiretas: significante essencial o Pode-se avaliar quão bem o desenvolvimento entanto, são atualizadas conforme o desenvolvimento avança.
o qualidade do software 1. O sistema exige backup e recuperação está progredindo em relação às metas de qualidade o Objetivos:
o usabilidade do software confiáveis? estabelecidas + adequar os recursos ao problema
o manutenibilidade 2. É requerida comunicação de dados? o Para que o pessoal da área de controle de + Cobrar produtividade dos desenvolvedores na medida
o funcionalidade 3. Existem funções de processamento qualidade identifique a necessidade de melhores padrões certa
o eficiência distribuído? a serem adotados no futuro. + Dados para comparação
o confiabilidade 4. O desempenho é crítico? + Verificar a viabilidade de projetos
5. O sistema funcionará num sistema operacional Análise de métricas
Métricas orientadas ao tamanho existente e intensamente utilizado? * As métricas que levam em consideração o tamanho Dificuldades
* São métricas diretas 6. São requeridas entrada de dados on-line? do código geram muitas controvérsias. Como, então, 1. Complexidade do projeto
* São também o tipo de métricas mais 7. As entradas on-line requerem que as deve-se medir produtividade? o Quanto mais complexo for o projeto, mais difícil será estimar
simples transações de entrada sejam construídas com * Para responder essa pergunta deve-se analisar os os recursos necessários.
* Geralmente se baseiam principalmente no várias telas e operações? fatores que influenciam a produtividade: o Por outro lado, a familiaridade com o tipo de aplicação anula
número de linhas de código de um software. 8. Os arquivos são atualizados on-line? o Fatores humanos: o tamanho e a experiência da esta dificuldade.
o O termo utilizado para descrever o 9. Entradas, saídas, arquivos e consultas são equipe de desenvolvimento o Por exemplo, uma aplicação de tempo real é naturalmente
tamanho do programa é LOC (Lines of Code), complexos? o Fatores do problema: A complexidade do complexa. No entanto, se a equipe de desenvolvimento estiver
ou linhas de código 10. O processamento interno é complexo? problema a ser resolvido e o número de mudanças nos familiarizada com esse tipo de aplicação, as experiências passadas
o Também é comum fazer a medida em 11. O código é projetado para ser reusával? requisitos ou restrições do projeto ajudarão a realizar estimativas acertadas.
termos de milhares de linhas de código, ou 12. A conversão e a instalação estão incuídas o Fatores do processo: Técnicas de análise e
KLOC (Thousand Lines of Code). no projeto? projeto que são utilizados, linguagens, ferramentas e 2. Tamanho do Projeto
* Se a organização fizer um registro de suas 13. O sistema é projetado para múltiplas técnicas de revisão. o O tamanho dificulta as estimativas, pois, à medida que um
atividades, as medidas de tamanho são instalações em diferentes organizações? o Fatores do produto: Confiabilidade e desempenho software cresce, aumenta as conexões entre os vários elementos
computadas quase automaticamente. 14. A aplicação é projetada de forma a facilitar do sistema baseado em computador desse software, dificultando a decomposição do problema.
mudanças e o uso pelo usuário? o Fatores relacionados a recursos: disponibilidade o Como a decomposição do problema é uma das principais
Métricas Métricas de ferramentas CASE, recursos de hardware e software. abordagens para a realização de estimativas, a dificuldade de
MÉTRICAS ORIENTADAS AO TAMANHO decomposição implica na dificuldade de realizar estimativas.
LOC/KLOC MÉTRICA ORIENTADA À FUNÇÃO - PF * Por exemplo, suponha que duas equipes, A e B,
projeto esforço $ KLOC pags.docum. erros 3) Ajustar os Pontos por Função de acordo com a tenham pessoas com iguais habilidades, usando os 3. Disponibilidade de Informações Históricas
pessoas complexidade mesmos recursos e o mesmo processo. o Quanto maior a disponibilidade de dados sobre os projetos
projA-01 24 168 12.1 365 29 3 do sistema, através da seguinte fórmula: * A equipe A está trabalhando num problema simples, realizados anteriormente, melhor serão as estimativas.
projB-04 60 440 27.2 1224 PF = Contagem-Total x 0,65 + 0,01 x (Fi) com requisitos de confiabilidade e desempenho médios. o Verificando o histórico de recursos gastos com aplicações e a
86 5 * A equipe B está trabalhando num problema complexo, qualidade de softwares já produzidos, pode-se estimar os recursos
projC-03 48 314 20.2 1050 i=1 com metas de confiabilidade e desempenho necessários e a qualidade do software que irá ser desenvolvido.
64 6 Fi = valores de ajuste da complexidade extremamente rígidas. 4. Falta de Dados Concretos
MÉTRICAS DERIVADAS das perguntas 1-14 * Portanto, com base nos fatores apresentados, a o Embora se deseje estimativas quantitativas, ainda não existem
PRODUTIVIDADE = MÉTRICAS DERIVADAS produtividade da equipe A será entre 40 e 140% melhor muitos dados sobre o projeto a ser desenvolvido.
QUALIDADE = PRODUTIVIDADE = do que a da segunda equipe.
CUSTO = QUALIDADE = Estimativas de Recursos
DOCUMENTAÇÃO = CUSTO = Métricas * O gerente de projetos deve fazer estimativas relacionadas a
KLOC / pessoas-mês DOCUMENTAÇÃO = BASELINE - DADOS HISTÓRICOS recursos humanos e também de software e hardware.
erros / KLOC PF / pessoas-mês * Atributos dos Dados Históricos: * Em relação a recursos humanos, deve especificar:
$ / KLOC erros / PF o Ajudam a reduzir o risco das estimativas o Habilidades exigidas
pags.docum. / KLOC $ / PF o Devem ser precisos ou próximos de um valor real o Disponibilidade
pags.docum. / PF o Coletados do maior número de projetos possível o Duração das tarefas
* Fáceis de serem obtidas Métricas o As medidas devem ser interpretadas da mesma o Data de início
* Existem vários modelos e literatura que se maneira durante todo o projeto * Em relação a recursos “físicos”, deve especificar:
baseiam nas linhas de código * Independe da linguagem de programação o As aplicações devem ser similares às do trabalho o Descrição
VANTAGENS * Pode ser utilizada no começo da evolução de que se quer estudar o Disponibilidade
DESVANTAGENS um projeto + Deve existir na empresa um modelo para o Duração do uso
* O número de LOC depende da linguagem VANTAGENS coleta e cálculo de dados históricos do software o Data de entrega
de programação DESVANTAGENS
* Programas bem projetados, pequenos, * O método inclui contagens de dados subjetivos. Métricas Recursos Humanos
serão injustamente classificados como * O valor FP não tem nenhum significado físico COLETA, COMPUTAÇÃO E AVALIAÇÃO DAS * O responsável pelos recursos humanos deve considerar várias
improdutivos. direto – é apenas um número. MÉTRICAS questões:
* Linguagens não procedimentais não podem Profissionais o Postos organizacionais – gerente, engenheiro de software,
ser avaliadas por estas medidas Métricas de Qualidade Gerentes analista, programador, etc.
* Não se pode utilizar essas métricas para * A qualidade pode e deve ser medida durante Software o Especialidades – telecomunicações, microprocessador,
fazer estimativas na fase de planejamento. todo o desenvolvimento e duração de um software: Processo de Engenharia de Software sistemas de tempo real, IA, etc.
o antes do desenvolvimento Computação das Métricas o Habilidades – linguagens de programação, banco de dados,
Métricas Orientadas à Função o durante o desenvolvimento Avaliação dos Dados ferramentas CASE.
* São métricas indiretas o após o desenvolvimento Coleta de Dados o Número de pessoas necessárias
* Em vez de contar o número de linhas de o após o software ser entregue aos clientes e BASELINE - DADOS HISTÓRICOS o Disponibilidade
código, concentra-se na funcionalidade e usuários o Duração das tarefas
utilidade do software. * Quando se mede a qualidade antes, durante e Estimativas o Data de início
* Geralmente utiliza-se o conceito de “pontos após o desenvolvimento, temos por exemplo as * O gerente de projetos de software confronta-se com
por função”, ou function point. seguintes métricas: um dilema logo no começo de um esforço de Recursos de Hardware
* Os pontos por função são computados o complexidade do programa desenvolvimento: * As questões relativas a hardware devem ser consideradas sob
utilizando cinco tipos de informações baseadas o modularidade efetiva o são exigidas estimativas quantitativas mas não dois aspectos principais:
no software. o tamanho do programa existem informações sólidas disponíveis o Hardware de desenvolvimento – aquele necessário para
o Número de entradas do usuário * A estimativa dos recursos, custo e programação das desenvolver o software
o Número de saídas do usuário * E as seguintes métricas são aplicadas após a atividades para um esforço de desenvolvimento de o Hardware de produção – aquele no qual o software
o Número de consultas do usuário entrega do software: software exige: desenvolvido será executado.
o Número de arquivos o corretitude (número de defeitos) o experiência * O primeiro tipo dependerá do segundo, já que o ideal é testar o
o Número de interfaces externas o manutenibilidade o acesso a boas informações históricas sistema no ambiente em que ele será executado.
o integridade o coragem para se comprometer com medidas * Deve-se levar em consideração também a capacidade de
o Entradas do usuário – cada ponto do o usabilidade quantitativas quando só existirem dados qualitativos armazenamento e a comunicação entre computadores, permitindo
software onde o usuário entra com qualquer tipo Corretitude assim interação entre os desenvolvedores.
de dado. * É o grau em que o software executa a função Fator que Reduz o Risco das Estimativas
o Saídas do usuário – pontos onde o que é dele exigida DADOS HISTÓRICOS Recursos de Software
software fornece informações ao usuário, tais * A medida mais comum de corretitude são os • Estimativas podem ser feitas com maior segurança * Para auxiliar o desenvolvimento de software, pode-se utilizar
como relatórios, telas, mensagens de erro etc. defeitos por KLOC • Prazos podem ser estabelecidos para se evitar diversas ferramentas, tais como ferramentas de modelagem,
o Consultas do usuário – pontos do * Defeito é uma falta de acordo com os requisitos dificuldades passadas ambientes de linguagens de programação, compiladores, etc.
software onde o usuário entra com um dado, por • Riscos globais podem ser reduzidos * Já se tornam comuns as chamadas ferramentas CASE (Computer
meio do qual o sistema gera uma saída (a * A manutenção exige mais esforço que qualquer Aided Software Engineering).
resposta à sua consulta). outra atividade da ES Estimativas de Projeto de Software
o Arquivos – Número de arquivos que * A manutenibilidade mede a facilidade com que * As estimativas são afetadas por muitas variáveis: Reusabilidade
compõem o software. um programa pode ser: o humanas * Outro recurso de software que pode ser utilizado para o
o Interfaces externas – meios de o corrigido se um erro for encontrado o técnicas desenvolvimento de sistemas são trechos de código já desenvolvidos.
comunicação do software com entidades o ampliado se o cliente desejar inclusões e o ambientais * Ou seja, em vez de desenvolver completamente um software,
externas a ele, tais como disquetes, impressora, alterações o políticas pode-se reutilizar funções, procedimentos ou módulos já
etc. * Não há como medi-la diretamente * As opções para se ter estimativas com graus desenvolvidos para outros softwares.
* Após a computação desses valores, * Exemplo de métrica indireta: Tempo Médio para aceitáveis de risco: * No entanto, diversos cuidados e preparativos são necessários. O
preenche-se a seguinte tabela: a Mudança (MTTC): o retardar as estimativas do projeto ideal é que, quando se produza um software, já se tomem
o tempo que demora para: o usar técnicas de decomposição (dividir o providências para permitir que partes do código sejam reutilizadas
MÉTRICA ORIENTADA À FUNÇÃO - PF + analisar o pedido de mudança problema complexo em pequenos problemas) mais tarde. Alguns cuidados são:
PONTOS POR FUNÇÃO É APLICADO + projetar uma modificação adequada o desenvolver um modelo empírico o Boa documentação
ATRAVÉS DE 3 PASSOS: + implementar a mudança o adquirir ferramentas de estimativas o Catalogação e padronização
1) Completar a seguinte tabela: + testar o Categorização em bibliotecas
fator de ponderação + distribuir a todos os usuários Estimativas de Projeto de Software
Parâmetro Contagem Simples Médio Complexo Manutenabilidade * Cada uma das opções viáveis de estimativas é tão * Quando o gerente de projetos considerar a reutilização de código,
nro de entradas x 3 boa quanto bons forem os dados históricos usados para deve seguir duas orientações:
4 6 * Está relacionada com a segurança fundamentar a estimativa o Se já existem trechos ou blocos de códigos prontos que
do usuário * Mede a capacidade que um sistema tem de * Se não existir nenhum dado histórico, o levantamento podem ser prontamente utilizados, ele deve comprá-los (ou utilizá-los).
nro de saídas x 4 suportar ataques à sua integridade repousará sobre uma base muito instável O custo para comprá-los será quase sempre menor que o custo para
5 7 * Os ataques incluem tanto ataques a programas, desenvolvê-lo.
do usuário dados e documentos. As Estimativas Bastam? o No entanto, se os trechos ou blocos de códigos existentes
nro de consultas x 3 * Para medir integridade, utiliza-se dois atributos * Para um determinado projeto de software uma série demandarem algum tipo de modificação ou adequação para poder ser
4 6 adicionais: ameaça e segurança. de diferentes técnicas de estimativa foram usadas e

4. utilizado, quase sempre o custo de compra + Termo que pode ser definido de várias formas, Taxa de defeitos, Facilidade de Manutenção e
modificação será igual ou maior que o custo causando mal-entendidos: Conformidade em relação aos Requisitos de Usuários, etc Qualidade do Produto
para desenvolver o código equivalente. 1. Qualidade não tem um único sentido; usuário Normas internacionais para avaliação de um produto
* Deve-se lembrar ainda de considerar a 2. Para cada conceito existem vários níveis de desenvolvedor ISO14598-2 Planejamento e Gerenciamento
reusabilidade durante a fase de planejamento e abstração; organização Fornece os requisitos e os guias para que seja dado suporte às
não apenas na fase de codificação. Caso 3. Visão popular pode ser diferente do seu uso Cumprimento de Prazo, Boa Previsão de Custo, Boa atividades de: desenvolvimento, aquisição, padronização, controle,
contrário, não haverá tempo para planejar profissional. Produtividade transferência e realimentação do uso de tecnologias de avaliação no
adequadamente e fazer estimativas de custo e DEFINIÇÃO: âmbito da organização
tempo. “produto ou serviço de qualidade é aquele que Qualidade do Produto ISO14598-3 Processo para Equipe de Desenvolvimento
atende perfeitamente, de forma confiável, de forma Normas internacionais para avaliação de um produto Indicadores de qualidade Coleta de dados
Estimativa de Custo acessível, de forma segura e no tempo certo as ISO9126 Características de Qualidade e Métricas Avaliação dos dados de medição Melhoria do processo de
e Preço de Venda necessidades dos clientes” (versão brasileira – NBR 13596) medição
* Vimos anteriormente que, quando não Qualidade ISO9126-1 Características e Subcaracterísticas de
existem experiências anteriores, é muito Qualidade Qualidade do Produto
complicado realizar estimativas QUALIDADE Confiabilidade Eficiência Normas internacionais para avaliação de um produto
* Nesses casos, a técnica consiste dos ESTÁGIOS DE EVOLUÇÃO Portabilidade ISO14598-4 Processo para Adquirentes
seguintes passos: * abordagem corretiva Usabilidade Manutenibilidade Os processos pacotes são avaliados por esta norma que estabelecerá
o Decompor o projeto em componentes + - inspeção 100% do produto Funcionalidade um processo sistemático de avaliação
elementares + - inspeção por métodos estatísticos ISO14598-5 Processo para Avaliadores
o Identificar as atividades necessárias à * abordagem preventiva Qualidade do Produto - ISO9126-1 Define as atividades necessárias para analisar os requisitos de
implementação de cada componente + - controle da qualidade Normas internacionais para avaliação de um produto avaliação
o Estimar o esforço exigido para cada + - garantia da qualidade Funcionalidade: refere-se a existência de um conjunto de ISO14598-6 Módulos de Avaliação
atividade. + - gestão da qualidade funções que satisfazem à necessidades estabelecidas ou Define os procedimentos de avaliação e o formato do relatório de
o Atribuir um valor de custo associado a implícitas, e suas propriedades específicas. apresentação dos resultados das medições em conseqüência das
cada atividade Qualidade: Visão Popular 1) Acurácia (Exatidão de uma operação) Faz o que foi aplicações das técnicas
* Deve-se também definir o que se entende * termo indefinível. proposto de forma correta?
por “custo”. * pode ser sentida, discutida, julgada, mas não O produto gera resultados precisos ou dentro do Qualidade de Software
o Custos não compreendem apenas os pode ser medida; esperado? Normas e Certificação
custos dos salários dos desenvolvedores do * luxo, classe e elegância. Produtos caros e 2) Adequação Propõe-se a fazer o que é apropriado? Órgãos responsáveis pela avaliação e a criação de normas e padrões:
software complexos têm melhor nível de qualidade. Presença das funções especificadas? * ISO
o Deve-se considerar o custo total de Confiabilidade e o número de reparos efetuados não 3) Interoperabilidade Interage com os sistemas * IEEE
operação, dividindo-o pelo número de pessoas são considerados. especificados? * ABNT
produtivas. 4) Conformidade Está de acordo com as normas, leis, * SEI
Definições etc.? * Softex
* Os custos incluem diversas categorias, tais Crosby: “Conformidade aos Requisitos” Está de acordo com padrões, regras? Qualidade
como: Juran: “Conveniência para Uso” 5) Segurança de acesso Evita (ou ao menos previne) Qualidade do Processo
o Custos relativos ao fornecimento de Requisitos devem ser claramente definidos e não acesso não A ISO e a IEC definem processo de software como sendo:
energia; podem ser mal-interpretados. autorizado aos dados? “Conjunto de processos usados por uma organização para: planejar,
o Custos com recursos humanos de Não conformidade = ausência de qualidade. gerenciar, executar, monitorar e melhorar as atividades relacionadas
apoio, como contadores, secretários, faxineiros, * Considera os requisitos e a expectativa do Qualidade do Produto - ISO9126-1 ao software.”
etc; cliente. Normas internacionais para avaliação de um produto
o Custos com operações em rede e * Um produto deve ter elementos que satisfaçam Confiabilidade: refere-se à capacidade do Software Qualidade do Processo
comunicações; as diversas maneiras com que os clientes o manter seu nível de desempenho, sob condições Melhoria de Processos e Noções de Maturidade
o Custo com instalações centrais, como utilizarão. estabelecidas, e sem apresentar falhas, por um certo
biblioteca, sanitários, instalações recreativas, * Parâmetros da conveniência para uso: período de tempo. Fluxo contínuo de informação com referencia ao progresso e ao
etc. e Qualidade de Projeto e de Conformidade. 1) Maturidade Com que freqüência apresenta falhas? sucesso de todas as pessoas envolvidas no programa
o Custos com previdência social e As duas definições são similares embora a segunda 2) Tolerância a falhas Ocorrendo falhas, como ele Melhoria do Processo
benefícios, tais como plano de saúde dê mais ênfase às expectativas do usuário. reage? Acordo de metas
* Quando se consideram todas essas Qualidade: Visão Profissional Capacidade do produto para manter Suporte duradouro e visível pelo gerenciamento
despesas, o valor por cabeça chega a um valor determinados níveis de desempenho Planejamento de metas
médio de o dobro do salário dos engenheiros de Qualidade de Software mesmo na presença de problemas. Supervisão contínua e controlada
software. * Perspectiva Histórica da Engenharia de 3) Recuperabilidade É capaz de recuperar dados em Avaliação das melhorias do processo pela medição dos resultados
* Ou seja, se um engenheiro recebe Software: caso de Identificação e Remoção de barreiras
R$3.000,00 por mês, a empresa terá um custo o anos 60 - Era Funcional falha? Capacidade do produto para Provisão de recursos requisitados
total de R$6.000,00 vezes o número de o anos 70 - Era do Método restabelecer o nível de desempenho
engenheiros de software. o anos 80 - Era do Custo desejado Qualidade do Processo
o anos 90 e depois - Era da Qualidade e recuperar dados em caso de Normas e propostas
* Quando se estima o preço que será pedido * Qualidade não é um fator de vantagem no ocorrência de * ISO9000-3: Normas para aplicação da série ISO9000 em
ao cliente, geralmente é algo do tipo: custo + mercado, mas é uma necessidade para a garantia falha. processos de software.
lucros. da competitividade. * ISO12207: Processos do ciclo de vida do software.
* Assim, se cada engenheiro recebe Usabilidade: refere- se ao esforço necessário ao uso e * CMM: Capability Maturity Model
R$3.000,00 por mês e os cálculos mostraram * planejamento de qualidade à homologação individual de tal uso, por um conjunto de * PSP: Personal Software Process
que preciso de 5 engenheiros trabalhando por * melhoria no processo e controle de qualidade usuários estabelecido ou subentendido. * ISO15504 SPICE: Software Process Improvement and Capability
seis meses, o custo será de (3.000 x 5)x2 = * gerenciamento de qualidade no processo 1) Inteligibilidade É fácil entender o conceito e a dEtermination
R$30.000,00. * análise de dados sobre a satisfação do cliente aplicação?
* Portanto, o preço de venda para o cliente são exemplos de técnicas aplicadas ao processo de 2) Apreensibilidade É fácil aprender a usar? * Guia para a aplicação da ISO 9001 para o desenvolvimento,
será de aproximadamente R$30,000,00 + lucro desenvolvimento. 3) Operacionalidade É fácil de operar e controlar? fornecimento e manutenção de software, criado em 1993.
desejado. Qualidade de Software * Especifica requisitos mínimos para assegurar a qualidade de
* Suponha um lucro de 30%. Valor final: Qualidade do Produto - ISO9126-1 produtos e serviços, não definindo modelos ou impondo sistemas de
R$39.000,00 Visões sobre a importância da qualidade do produto Normas internacionais para avaliação de um produto qualidade.
* No entanto, deve-se levar em conta vários e do processo Processos da ISO 9000-3:
fatores ao decidir a margem de lucro, tais como: * Visão que aborda a qualidade do produto Qualidade do Produto - ISO9126-1 o A estrutura
o Funcionalidade, confiabilidade, usabilidade, Normas internacionais para avaliação de um produto o Atividades do ciclo de vida
o Oportunidade de mercado eficiência, manutenibilidade e portabilidade (ISO Eficiência:refere-se ao relacionamento entre o nível de o Atividades de apoio (Suporte)
Pode-se optar por um preço baixo, com o 9126). desempenho do software e a qualidade de recursos
objetivo de iniciar um novo segmento do * Visão que aborda a qualidade do processo utilizados, sob as condições estabelecidas. A Eficiência Qualidade do Processo
mercado de software. Aceitando um lucro o Dos requisitos do usuário à entrega do serve para avaliar como o Software aproveita esses ISO 9000-3
menor, pode-se obter melhores lucros a longo produto final, existe um processo de recursos no tempo.
prazo. desenvolvimento complexo e dividido em fases, que 1) Comportamento em relação ao tempo Qual é o Qualidade do Processo
o Incerteza da estimativa pode comprometer a qualidade do software. tempo de resposta, a velocidade de execução? Normas e propostas – ISO 9000-3
Quando uma empresa não está segura das Mesmo diante de divergências, o fato é que o Medida do tempo de resposta e de processamento Seqüência para certificação:
estimativas, estima o custo colocando um lucro processo influi nas características finais do software. ou taxas de processamento (throughput), ao executar as 1) Estabelece o Sistema de Qualidade
bem acima do normal, prevendo que surgirão funções prescritas. 2) Solicitação ao órgão certificador
despesas imprevistas. QUALIDADE DE SOFTWARE 2) Comportamento em relação a recursos Quanto 3) Visita à empresa
o Condições Contratuais DEFINIÇÕES: recurso usa? Durante quanto tempo? 4) Auditoria
Se o desenvolvedor quiser manter a “Qualidade de Software é um conjunto de Medida da quantidade de recursos necessários 5) Emissão do Certificado
propriedade do código-fonte para reutilizá-lo, propriedades a serem satisfeitas em um (CPU, disco e memória, dentre outros) e a duração do seu Quadro Comparativo
geralmente cobra um preço menor. determinado grau de modo que o software satisfaça uso ao executar as funções prescritas. Quadro Comparativo
o Volatilidade dos Requisitos às necessidades de seus usuários”
Se existe a probabilidade de que os Ana Regina C. da Rocha Manutenibilidade: refere-se ao esforço necessário para se MPS.BR
requisitos sejam modificados, uma empresa “Qualidade de software é a conformidade a fazer modificações específicas no Software. * Melhoria de Processos do Software Brasileiro, é simultaneamente
pode baixar os preços para “ganhar o cliente” e, requisitos funcionais e de desempenho 1) Analisabilidade É fácil de encontrar uma falha, quando um movimento para a melhoria e um modelo de qualidade de processo
mais tarde, cobrar preços altos pelas mudanças. explicitamente estabelecidos, a padrões de ocorre? voltada para a realidade do mercado de pequenas e médias empresas
o Saúde Financeira desenvolvimento explicitamente documentados, e a Esforço necessário para diagnosticar deficiências ou de desenvolvimento de software no Brasil.
Em época de “vacas magras”, aceita-se um características implícitas que são esperadas de todo causas de falhas, ou localizar as partes a serem * Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC
preço reduzido, mas que mantenha a empresa software desenvolvido profissionalmente” modificadas para corrigir os problemas 15504 e na realidade do mercado brasileiro.
funcionando a longo prazo. Pressman 2) Modificabilidade É fácil modificar e adaptar? * No Brasil, uma das principais vantagens do modelo é seu custo
Esforço necessário para realizar alterações, remover reduzido de certificação em relação as normas estrangeiras, sendo
Resumo QUALIDADE DE SOFTWARE falhas ou para adequar o produto a eventuais mudanças ideal para micro, pequenas e médias empresas.
* O que fazer quando existem dados * qualidade de software não é espontânea. de ambiente operacional
históricos? * qualidade do produto depende da qualidade do 3) Estabilidade Há grande risco quando se faz alterações? MPS.BR
o Decompor o problema em sub- processo de desenvolvimento. 4) Testabilidade É fácil testar quando se faz alterações?b * O projeto tem apoio do Ministério de Ciência e Tecnologia, FINEP
problemas * a existência de um processo formalizado para Qualidade do Produto - ISO9126-1 e Banco Interamericano de Desenvolvimento. No Brasil o projeto é
o Utilizar os dados históricos para fazer desenvolver software é pré-requisito para o Normas internacionais para avaliação de um produto desenvolvido: Softex, governo e universidades.
estimativas de LOC para cada subproblema ou estabelecimento de um programa de qualidade. O MPS.Br é dividido em 3 partes:
utilizar a métrica FP. Atividades para se obter a qualidade do software: Qualidade do Produto - ISO9126-1 o MR-MPS: Modelo de referência para melhoria do processo de
o A partir dos LOC e FP, usar dados * definir os requisitos de qualidade Normas internacionais para avaliação de um produto software
históricos de produtividade para calcular o * embutir qualidade no produto (definição e Portabilidade: refere-se à capacidade do Software ser o MA-MPS – Método de avaliação para melhoria do processo de
esforço. controle do processo) transferido de um ambiente para outro, com o menor software
o A partir do esforço, calcular o custo. * medir a qualidade (avaliar o processo e produto) esforço possível. o MN-MPS – Modelo de negócio para melhoria do processo de
o Em seguida, propor um lucro e calcular 1) Adaptabilidade É fácil adaptar a outros ambientes? software
o valor final. Qualidade de Software 2) Capacidade de ser instalado É fácil instalar em
* E se não existem dados históricos? Medidas e Métricas outros ambientes? * Não existe um modelo ideal de avaliação de qualidade que seja
o Utilizar a experiência dos “Medir um sistema é conhecer o sistema, por isso 3) Conformidade Está de acordo com padrões de aplicável indistintamente às organizações, abrangendo os diversos
desenvolvedores ou contratar especialistas no medimos um sistema para controlar a sua portabilidade? objetivos que elas tem em relação a qualidade.
domínio da aplicação para calcular LOC utilizar qualidade.” 4) Capacidade de substituição É fácil usar para * A qualidade de software não é garantida somente pela qualidade
a métrica FP Porque estabelecer sistemas de medidas? substituir outro? de processo, mas também pela garantia de qualidade do produto final.
o Estimar produtividade para calcular o * Avaliar a produtividade de cada Software * A maior preocupação deve ser sempre a satisfação do usuário
esforço * Comparar a qualidade de um sistema com outro ISO9126-2 Métricas Externas final.
o A partir do esforço calcular o custo * Estimar custo e tempo necessário para São medidas indiretas do software, coletadas a partir da Conclusões
o Propor o lucro e calcular o valor final desenvolver os sistemas medição do sistema computacional no qual o software
* Avaliar a qualidade do serviço está inserido.
* Dar suporte ao cliente ISO9126-3 Métricas Internas
Qualidade de Software São medidas direta ou indiretamente do software,
QUALIDADE DE SOFTWARE Qualidade de Software coletadas a partir de suas próprias características
* Qualidade é um dos principais objetivos da Medidas e Métricas internas, sem a necessidade de execução do código.
Engenharia de Software. Após a avaliação: Qualidade do Produto - ISO9126
* Muitos métodos, técnicas e ferramentas são * Aumento da produtividade Normas internacionais para avaliação de um produto
desenvolvidas para apoiar a produção com * Aumento da satisfação do cliente
qualidade. * Informações para o ciclo de vida do sistema Qualidade do Produto
* Tem-se dado grande importância ao * Identificação de softwares complexos Normas internacionais para avaliação de um produto
processo como forma de se garantir um ISO 14598 Avaliação dos Produtos de Software
software de melhor qualidade. Visões de Qualidade de Software ISO14598-1 Visão Geral
Qualidade de Software Facilidade de Uso, Desempenho, Confiabilidade dos É o complemento da série ISO/IEC 9126, e mostra toda a
Resultados, Preço do Software, etc. estrutura de funcionamento das normas da série ISO/IEC
14598, definindo os termos técnicos usados no modelo.