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