Projeto de Interface com o Usuário Projeto de Interface O bom projeto de interface com o usuário é fundamental para o sucesso de um sistema. Uma interface que é difícil de ser utilizada, na melhor das hipóteses, resultará em um alto nível de erros do usuário. Profª Renata Vieira Dias Martins UNILESTEMG GUI - Graphical User Interface Vantagens das GUIs são: 1. Relativamente fáceis de aprender e utilizar; 2. O usuário tem várias telas para a interação com o sistema; 3. É possível a interação rápida com a tela inteira Profª Renata Vieira Dias Martins UNILESTEMG GUI - Graphical User Interface Profª Renata Vieira Dias Martins UNILESTEMG Projeto de Interface com o Usuário O que é? Seguindo um conjunto de princípios de projeto de interface, o projeto identifica objetos e ações de interface e depois cria um leiaute de tela que forma a base para um protótipo de interface com o usuário. Quais são os passos? Começa com a identificação dos requisitos de usuário, das tarefas e do ambiente. Profª Renata Vieira Dias Martins UNILESTEMG Projeto de Interface com o Usuário Qual o produto do trabalho? Cenários do usuário são criados e leiautes de telas são gerados. Um protótipo de interface é desenvolvido. Como garanto que fiz corretamente? O protótipo é direcionado a “testes” pelos usuários e a realimentação a partir do teste de direcionamento é usada para a modificação do protótipo. Profª Renata Vieira Dias Martins UNILESTEMG Projeto de Interface com o Usuário O projeto de interface com o usuário tem tanto a ver com o estudo de pessoas quanto com aspectos tecnológicos. o Quem é o usuário? o Como ele aprende a interagir com um novo sistema baseado em computador? o Como interpreta a informação produzida pelo sistema? Profª Renata Vieira Dias Martins UNILESTEMG Projeto de Interface com o Usuário Regras de Ouro - Theo Mandel 1. Coloque o usuário no controle 2. Reduza a carga de memória do usuário 3. Faça a interface consistente Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle “O que eu realmente gostaria é de um sistema que leia a minha mente. Que saiba o que eu quero fazer antes que eu precise fazê-lo e torne muito fácil para mim conseguir que seja feito. Isso é tudo, apenas isso” Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle A maioria das limitações e restrições de interface que são impostas por um projetista são destinadas a simplificar o modo de interação. Mas para quem? Em muitos casos o projetista pode introduzir restrições e limitações para simplificar a implementação da interface. Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle Defina os modos de interface de uma forma que não force o usuário a ações desnecessárias ou indesejadas Um modo de interação é o estado atual da interface. Por exemplo, uma opção para verificar ortografia num processador de textos, o usuário deve entrar e sair do modo com pouco ou nenhum esforço. Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle Proporcione interação flexível Como diferentes usuários têm diferentes preferências de interação, a escolha deve ser oferecida. Exemplo: Usuário interagir por meio de comando de teclado, movimento do mouse, caneta digitadora, comandos de reconhecimento de voz. Mas nem toda ação é adequada a todos os mecanismos de interação Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle Permita que a interação com o usuário possa ser interrompida e desfeita Mesmo quando envolvido numa seqüência de ações, o usuário deve poder interromper a seqüência para fazer alguma outra coisa. O usuário deve poder “desfazer” qualquer ação, inevitavelmente cometem erros. Confirme ações destrutivas. Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle Simplifique a interação à medida que os níveis de competência progridem e permita que a interação seja personalizada Os usuário freqüentemente descobrem que realizam a mesma seqüência de interações repetidamente. Vale a pena projetar um mecanismo “macro” que permita a um usuário avançado personalizar a interface para facilitar a interação.

Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle Esconda detalhes técnicos internos do usuário A interface com o usuário deve levar o usuário ao mundo virtual da aplicação. O usuário não deve perceber o sistema operacional, funções de gerenciamento de arquivos ou outra tecnologia obsoleta de computação. Profª Renata Vieira Dias Martins UNILESTEMG Coloque o usuário no controle Projete a interação direta com objetos que aparecem na tela O usuário tem uma sensação de controle quando pode manipular os objetos que são necessários para realizar uma tarefa de modo semelhante ao que iria ocorrer se o objeto fosse uma coisa física. Por exemplo, uma interface uqe permite a um usuário “esticar” um objeto (aumentá-lo de tamanho) é uma implementação de manipulação direta. Profª Renata Vieira Dias Martins UNILESTEMG Reduza a carga de memória do usuário Reduza a demanda da memória de curto prazo Quando os usuário estão envolvidos em tarefas complexas, a demanda da memória de curto prazo pode ser significativa. A interface deve ser projetada para reduzir a necessidade de lembrar ações e resultados anteriores. Isso pode ser conseguido através de indicadores visuais que permitem ao usuário reconhecer ações anteriores. Profª Renata Vieira Dias Martins UNILESTEMG Reduza a carga de memória do usuário Estabeleça defaults significativos O conjunto inicial de parâmetros (defaults) deve fazer sentido para o usuário médio, mas o usuário deve poder especificar preferências individuais. No entanto, uma opção “reset” (refazer os parâmetros iniciais) deve ser estar disponível, permitindo a redefinição dos valores originais. Profª Renata Vieira Dias Martins UNILESTEMG Reduza a carga de memória do usuário Defina atalhos que são intuitivos Quando são usados mnemônicos para realizar uma função do sistema (p. ex., alt+P para invocar a função de impressão), o mnemônico deve ser ligado à ação de um modo que seja fácil de lembrar (p. ex. primeira letra da tarefa a ser invocada) Profª Renata Vieira Dias Martins UNILESTEMG Reduza a carga de memória do usuário O leiaute visual da interface deve ser baseada numa metáfora do mundo Por exemplo, um sistema de pagamentos de contas deve usar uma metáfora de talão e canhoto de cheques para guiar o usuário durante o processo de pagamento de contas. Isso permite ao usuário se apoiar em indicações visuais bem-entendidas, ao invés de memorizar uma seqüência de interação esotérica. Profª Renata Vieira Dias Martins UNILESTEMG Reduza a carga de memória do usuário Revele informação de modo progressivo A interface deve ser organizada hierarquicamente. Isto é, a informação sobre a tarefa, um objeto ou algum comportamento deve ser inicialmente apresentada num alto nível de abstração. Mais detalhes devem ser apresentados, após o usuário indicar interesse com um clique do mouse. Ex: Sublinhar em processadores de texto. Profª Renata Vieira Dias Martins UNILESTEMG Faça a interface consistente Permita ao usuário situar a tarefa atual num contexto significativo É importante fornecer indicadores (p ex. títulos de janelas, ícones gráficos, código de cores consistente) que permitem ao usuário saber o contexto do trabalho em mãos. Além disso, o usuário deve poder determinar de onde veio e que alternativas existem de transição para uma nova tarefa. Profª Renata Vieira Dias Martins UNILESTEMG Faça a interface consistente Mantenha consistência ao longo de uma família de aplicações Um conjunto de aplicações (ou produtos) deve implementar as mesmas regras de projeto, de modo que seja mantida a consistência para toda interação. Comandos e os menus do sistema devem ter o mesmo formato e os parâmetros devem ser fornecidos a todos os comandos da mesma maneira. Profª Renata Vieira Dias Martins UNILESTEMG Faça a interface consistente Se modelos interativos anteriores criaram expectativas para o usuário, não faça modificações, a menos que haja forte razão para isso Quando uma seqüência interativa particular torna-se um padrão de fato (p. ex. o uso de alt+S para salvar um arquivo), o usuário espera isso em toda a aplicação que encontra. Uma modificação vai causar confusão Profª Renata Vieira Dias Martins UNILESTEMG Faltou um item nesta lista. Qual? É o princípio da assistência ao usuário. As interfaces devem ter opções de assistência ou recursos de ajuda ao usuário inseridas. Mensagens de erros cometidos pelo usuário e recursos de ajuda sensíveis ao contexto. Profª Renata Vieira Dias Martins UNILESTEMG Outro aspecto a ser sempre avaliado. Qual? É o princípio da diversidade de usuários. * Usuários Casuais - precisam de interfaces que forneçam interação * Usuários Freqüentes - requerem atalhos que lhes permitam interagir o mais rápido possível

Profª Renata Vieira Dias Martins UNILESTEMG Diversidade de Usuários Além disso alguns usuários podem apresentar diferentes tipos de problemas físicos e, se possível, a interface deve ser adaptável para atendê-los. Pode ser necessário fornecer recursos para exibir texto ampliado, substituir som por texto, produzir botões grandes, e assim por diante. Profª Renata Vieira Dias Martins UNILESTEMG Princípios de Projeto com o Usuário Profª Renata Vieira Dias Martins UNILESTEMG Interação com Usuários Profª Renata Vieira Dias Martins UNILESTEMG Projeto de Interface 1. O usuário está interessado em informações precisas ou nas relações entre diferentes valores de dados? 2. Com que rapidez os valores das informações são modificados? A mudança em um valor deve ser imediatamente ao usuário? 3. O usuário deve tomar alguma iniciativa em resposta a uma mudança nos informações? 4. O usuário precisa interagir com as informações exibidas por meio de uma interface de manipulação direta? 5. As informações a serem exibidas são textuais ou numéricas? O valores relativos dos itens das informações são importantes? Profª Renata Vieira Dias Martins UNILESTEMG Ambiente de Trabalho Físico * Onde a interface será localizada fisicamente? * O usuário vai estar sentado, em pé, ou realizando outras tarefas não-relacionadas à interface? * O hardware da interface acomoda as restrições de espaço, luz ou ruído? * Há considerações especiais de fatores humanos determinados por fatores ambientais? Profª Renata Vieira Dias Martins UNILESTEMG Tarefa de Validação * Capacidade da interface de implementar todas as tarefas do usuário corretamente, de acomodar todas as variantes de tarefa e de atingir todos os requisitos gerais do usuário; * O grau em que a interface é fácil de usar e fácil de aprender * A aceitação dos usuários da interface como ferramenta útil ao seu trabalho. Profª Renata Vieira Dias Martins UNILESTEMG Aspectos do Projeto A medida que o projeto de interface com o usuário evolui, quatro questões comuns de projeto quase sempre aparecem: * Tempo de resposta do sistema; * Facilidade de ajuda ao usuário; * Manipulação de erro; * Rotulação de comandos. Profª Renata Vieira Dias Martins UNILESTEMG Facilidade de Ajuda É projetada no software desde o início ou é integrada ao software após o sistema ter sido construído? * A ajuda vai estar disponível para todas as funções do sistema em todos os momentos durante a interação do sistema? * Como o usuário vai solicitar ajuda? * Como a ajuda vai ser representada? * Como o usuário vai voltar à interação normal? * Como a informação de ajuda vai ser estruturada? Profª Renata Vieira Dias Martins UNILESTEMG Mensagens e Alertas de Erro * Deve descrever o problema num jargão que o usuário possa entender; * Deve fornecer sugestões construtivas para se recuperar do erro; * Deve indicar quaisquer conseqüências negativas do erro; * Deve ser acompanhada por uma indicação audível ou visual; * Deve ser não “opinativa”, ou seja, nunca colocar a culpa no usuário. Profª Renata Vieira Dias Martins UNILESTEMG Mensagens e Alertas de Erro Profª Renata Vieira Dias Martins UNILESTEMG Mensagens e Alertas de Erro Profª Renata Vieira Dias Martins UNILESTEMG Comando Digitado - Projeto * Cada opção de menu vai ter um comando correspondente? * Que forma os comando vão tomar? Seqüência de controle, teclas de função ou palavra digitada. * Quão difícil será aprender e lembrar os comandos? O que pode ser feito se um comando for esquecido? * Os comandos podem ser personalizados ou abreviados pelo usuário? * Estabeleça Convenções! Profª Renata Vieira Dias Martins UNILESTEMG Cores no Projeto de Interface 1. Limite o número de cores utilizadas e seja conservador no modo de utilizá-las 2. Utilize a mudança de cores para mostrar uma modificação no status do sistema 3. Utilize código de cores para apoiar a tarefa que os usuários estão tentando realizar 4. Utilize código de cores de maneira cuidadosa e consistente 5. Seja cuidadoso quanto a pares de cores. Profª Renata Vieira Dias Martins UNILESTEMG 1. Os ícones são auto explicativos? Em caso negativo que ícones não são claros? 2. As ações são fáceis de lembrar e de invocar? 3. Quantas ações diferentes você usou?

4. Quão fácil foi aprender as operações básicas do sistema (escala de 1 a 5)? 5. Comparada com outras interfaces que você já usou, como classifica essa? Avaliação da Interface - Qualitativo Profª Renata Vieira Dias Martins UNILESTEMG Os usuários são observados durante a interação e dados -tais como: * Número de tarefas corretamente completadas num tempo padrão * Freqüência de ações * Seqüência de ações * Tempo gasto “olhando” o monitor de vídeo * Número de erros * Tempo de recuperação de erro * Tempo gasto olhando a ajuda * Número de referências à ajuda num tempo padrão São coletadas e usadas como diretriz na modificação da interface. Avaliação da Interface – Quantitativo

Testes_de_Software Técnicas de Testes de Software Profª Renata Vieira Dias Martins UNILESTEMG Uma vez gerado o código-fonte, o software deve ser testado para descobrir e corrigir tantos erros quanto possível antes de ser entregue ao cliente. Sua meta é projetar uma série de casos de teste que têm alguma probabilidade de encontrar erros – mas como? O que é? Profª Renata Vieira Dias Martins UNILESTEMG É aí que as técnicas de testes de software entram em cena fornecendo diretrizes sistemáticas para projetar testes que exercitam: * a lógica interna dos componentes do software * os domínios de entrada e saída do programa para descobrir erros na função, comportamento e desempenho do programa Como? Profª Renata Vieira Dias Martins UNILESTEMG Por que é importante? Erros podem vir a ocorrer até no início do processo, onde os objetivos podem ser errônea ou imperfeitamente especificados, bem como em estágios posteriores do projeto e desenvolvimento. Por causa da inabilidade humana de realizar e de se comunicar com perfeição, o desenvolvimento é acompanhado por uma atividade de garantia de qualidade. Profª Renata Vieira Dias Martins UNILESTEMG Por que é importante? Teste de software é um elemento crítico da garantia de qualidade do software e representa a revisão final da especificação, projeto e geração de código. Não é raro uma organização de desenvolvimento gastar de 30 a 40% do esforço total do projeto no teste. A rigor, o teste do software que envolve vidas pode custar de três a cinco vezes mais do que todos os outros passos de Engenharia de Software combinados! Profª Renata Vieira Dias Martins UNILESTEMG Quais são os passos? O engenheiro cria uma série de casos de testes, que são destinados a “demolir” o software que foi construído. Um conjunto de casos de teste planejado é projetado e documentado para exercitar tanto a lógica interna quanto os requisitos externos. Os resultados esperados e os resultados reais são registrados. O processo de teste deve-se tentar “quebrar” arduamente o software ! Profª Renata Vieira Dias Martins UNILESTEMG Objetivos do teste * É o processo de execução de um programa com o objetivo de encontrar um erro * Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro * Um teste bem-sucedido é aquele que descobre o erro ainda não descoberto O teste não pode mostrar a ausência de erros e defeitos, mas apenas mostrar que erros e defeitos do software estão presentes! Profª Renata Vieira Dias Martins UNILESTEMG Princípios do teste * Todos os testes dever ser relacionados aos requisitos do cliente * Os testes devem ser planejados muito antes do início do teste * O teste deve começar “no varejo” e progredir até o teste “no atacado” * Teste completo não é possível * Para ser mais efetivo, o teste deveria ser conduzido por terceiros Profª Renata Vieira Dias Martins UNILESTEMG São impraticáveis os testes exaustivos Testes têm que ser baseados em um subconjunto de possíveis casos de testes As políticas de testes podem ter como base a experiência de utilização do sistema Detecção de defeitos Profª Renata Vieira Dias Martins UNILESTEMG Projeto – Casos de Teste Qualquer produto pode ser testado por uma das duas maneiras: * sabendo a função especificada que o produto foi projetado para realizar, podem se realizados testes que demonstram que cada função está plenamente operacional, enquanto ao mesmo tempo procuram erros em cada função; * sabendo como é o trabalho interno de um produto, podem ser realizadas de acordo com as especificações e que todos os componentes internos foram adequadamente exercitados. Profª Renata Vieira Dias Martins UNILESTEMG Utilizando métodos de teste caixa-branca pode-se derivar casos de teste que: * Garantam que todos os caminhos independentes de um módulo tenham sido exercitados pelo menos uma vez; * Exercitam todas as decisões lógicas em seus lados verdadeiro e falso; * Checam todos os ciclos nos seus limites e dentro de seus intervalos operacionais; * Exercitam as estruturas de dados internas para garantir sua validade. Testes Caixa Branca Profª Renata Vieira Dias Martins UNILESTEMG Inspeções de Software * Não requerem que o programa seja executado e provam ser uma técnica eficaz na detecção de erros; * Também pode considerar outros atributos de qualidade, como conformidade com padrões, a portabilidade e a facilidade de manutenção; * Muitos defeitos diferentes podem ser testados com uma única sessão de inspeção; * Reutilizam o conhecimento de domínio e de linguagem. Profª Renata Vieira Dias Martins UNILESTEMG Inspeções devem substituir os testes? * É quase sempre impraticável inspecionar um sistema inteiro, com uma série de subsistemas;

* Os testes caixa preta são também necessários para a avaliação de confiabilidade, a análise de desempenho, a validação de interface com o usuário e para checar os requisitos; * Inspeções e Testes Caixa Preta não são técnicas concorrentes de Verificação. Inspeções de Software Profª Renata Vieira Dias Martins UNILESTEMG São revisões cujo objetivo é a detecção de defeitos no programa Para cada declaração condicional, a condição está correta? Cada loop está certo para terminar? As declarações compostas estão corretamente entre parênteses? Em declarações ‘case’ todos os casos são levados em conta? Se um identificador BREAK é requerido após cada caso em declarações ‘case’, esse identificador foi incluído? Defeitos de Controle Todas as variáveis de programa são iniciadas antes de seus valores serem utilizadas? Todas as constantes foram denominadas? O limite superior de vetores deve ser igual ao tamanho do vetor ou ao tamanho –1? Existe alguma possibilidade de overlow de buffer? Defeitos nos Dados Checagem de Inspeção Classe de defeitos Inspeções de Software Profª Renata Vieira Dias Martins UNILESTEMG Todas as possíveis condições de erros foram levadas em conta? Defeitos de Gerencia-mento de Exceções Se uma estrutura ligada é modificada, todos os links foram corretamente redesignados? Se o armazenamento dinâmico é utilizado, o espaço foi alocado corretamente? O espaço é explicitamente liberado, depois que não é mais necessário? Defeitos de Gerencia-mento de Armazena-mento Todas as chamadas de funções e métodos têm o número correto de parâmetros? Os tipos formais e reais de parâmetros combinam? Os parâmetros estão na ordem certa? Se componentes acessam memória compartilhada, eles têm o mesmo modelo da estrutura de memória compartilhada? Defeitos de Interface Todas as variáveis de entrada são utilizadas? Todas as variáveis de saída têm um valor designado antes de saírem? Entradas inesperadas podem fazer com que os dados sejam corrompidos? Defeitos de Entrada/ Saída Inspeções de Software Profª Renata Vieira Dias Martins UNILESTEMG A medida que uma organização adquire experiência no processo de inspeção, ela pode utilizar os resultados desse processo como meio de aperfeiçoa-lo. A quantidade de código que pode ser inspecionada em um determinado tempo depende da experiência da equipe de inspeção, da linguagem de programação e do domínio da aplicação. Inspeções de Software Profª Renata Vieira Dias Martins UNILESTEMG Testes Funcionais ou Comportamentais * Não é uma alternativa às técnicas caixa-branca * Focado na funcionalidade e não na implementação do software. Despreza, de propósito, a estrutura de controle, a atenção é focalizada no domínio da informação. Tenta encontrar erros nas seguintes categorias: o Funções incorretas ou omitidas o Erros de interface o Erros de estrutura de dados ou de acesso a base de dados externa o Erros de comportamento ou desempenho o Erros de inicialização e término Testes Caixa Preta Profª Renata Vieira Dias Martins UNILESTEMG * Diferente do teste caixa-branca, que é realizado no início do processo de teste, o teste caixa-preta tende a ser aplicado durante os últimos estágios do teste. * Hetzel descreve o teste caixa-branca como “teste de varejo”. Sua implicação é de que os testes caixa-branca são tipicamente aplicados a pequenos componentes de programa (p.ex. módulos ou pequenos grupos de módulos). O teste caixa-preta, por outro lado, amplia nosso enfoque e pode ser chamado de “teste por atacado”. Caixa-Branca x Caixa-Preta Estratégias de Teste de Software Profa. Renata Vieira Dias Martins UnilesteMG renatavd@uol.com.br “Como a morte e os impostos, o teste é tanto desagradável quanto inevitável” Ed Yourdon Profª Renata Vieira Dias Martins UNILESTEMG O projeto efetivo de casos de teste é importante, mas a estratégia que você usa para executá-los também é. * Deve desenvolver um plano formal para os testes? * Deve testar o programa inteiro como um todo ou apenas uma pequena parte dele? * Deve reexecutar testes que já conduziu quando adicionados um novo componente a um sistema grande? * Quando o cliente deve estar envolvido? O que é? Profª Renata Vieira Dias Martins UNILESTEMG Todas as estratégias de teste de software fornecem ao desenvolvedor um gabarito de teste e as seguintes características genéricas:

* o teste começa em nível de componente e prossegue “para fora”, em direção ao todo o sistema * diferentes técnicas de testes são adequadas em diferentes momentos * o teste é conduzido pelo desenvolvedor e, para projetos grandes, por um grupo de teste independente * o teste e a depuração são atividades diferentes mas a depuração deve fazer parte de qualquer estratégia de teste Abordagem Estratégica Profª Renata Vieira Dias Martins UNILESTEMG Abrange muitas das atividades a que nos referimos como garantia da qualidade de software (SQA) Validação: Estamos construindo o produto certo? Os requisitos descritos atendem às necessidades do cliente? Verificação: Estamos construindo certo o produto? O que está implementado está de acordo com os requisitos descritos no documento? Verificação e Validação Profª Renata Vieira Dias Martins UNILESTEMG Há um conflito de interesses inerente que ocorre quando o teste começa. O pessoal que construiu o software é agora solicitado a testá-lo. Isso parece inócuo em si mesmo; afinal de contas, quem conhece o programa melhor do que seus desenvolvedores? Infelizmente, esses mesmos desenvolvedores têm um interesse oculto em demonstrar que o programa está livre de erros, que funciona de acordo com os requisitos do cliente e que vai ser completado de acordo com o cronograma e dentro do orçamento. Cada um desses interesses se contrapõe a um teste rigoroso. Organização Profª Renata Vieira Dias Martins UNILESTEMG Para desenvolver o software nos movemos em espiral para dentro. Uma estratégia para teste de software pode também ser vista no contexto da espiral, de dentro para fora. Uma Estratégia Teste de Sistema Teste de Validação Teste de Integração Teste de Unidade Profª Renata Vieira Dias Martins UNILESTEMG Inicialmente o teste focaliza cada componente individualmente, garantindo que funciona adequadamente como uma unidade. O teste de unidade faz uso de técnicas de caixa-branca intensivamente, exercitando caminhos específicos na estrutura de controle de um módulo, para garantir completa cobertura e máxima detecção de erros. O teste de integração cuida dos aspectos associados aos problemas duais de verificação e construção de programas. As técnicas de projeto de casos de teste caixa-preta são mais prevalentes durante a integração, apesar de uma quantidade limitada de testes caixa-branca poder ser usada para garantir a cobertura dos principais caminhos de controle. Uma Estratégia Profª Renata Vieira Dias Martins UNILESTEMG Depois que o software foi integrado, um conjunto de testes de alto nível é conduzido. Critérios de validação (estabelecidos durante a análise de requisitos) precisam ser testados. Os testes de validação fornecem garantia final de que o software satisfaz todos os requisitos funcionais, comportamentais e de desempenho. As técnicas de teste caixa-preta são as únicas usadas durante a validação. O software, uma vez validado, deve ser combinado com os outros elementos do sistema (p.ex. o hardware, o pessoal, as bases de dados). O teste de sistema verifica se todos os elementos combinam adequadamente e se a função/desempenho global do sistema é conseguida. Uma Estratégia Profª Renata Vieira Dias Martins UNILESTEMG “Quando terminamos o teste para saber se testamos suficientemente?” Infelizmente não há resposta definitiva para esta questão, mas há algumas respostas pragmáticas e primeiras tentativas de respostas empíricas. Uma reposta à questão é: “Você nunca acaba de testar, o encargo simplesmente passa de você para o seu cliente”. Outra resposta (um tanto cínica, mas não obstante precisa) é: “Você acaba de testar quando o tempo ou o dinheiro acaba” Profª Renata Vieira Dias Martins UNILESTEMG Teste de Unidade * A interface do módulo é testada para garantir que a informação flui adequadamente para dentro e para fora da unidade de programa que está sendo testada. * A estrutura de dados local é examinada para garantir que dados armazenados temporariamente mantêm sua integridade durante todos os passos da execução. * As condições limites são testadas para garantir que o módulo opera adequadamente nos limiares estabelecidos para limitar ou restringir o processamento. * Os caminhos independentes ao longo da estrutura de controle são exercitados para garantir que todos os comandos de um módulo tenham sido executados pelo menos uma vez. * Todos os caminhos de manipulação de erros são testados. Profª Renata Vieira Dias Martins UNILESTEMG Teste de Unidade * O teste de unidade é normalmente considerado um apêndice ao passo de codificação. * Um bom projeto determina que condições de erros sejam antecipadas e caminhos de manipulação de erros estabelecidos para redirecionar ou claramente terminar o processamento quando um erro efetivamente ocorre. * Yourdon chama esta abordagem de antidefeitos. Infelizmente, há uma tendência de incorporar manipulação de erros no software e depois nunca testá-la.

Profª Renata Vieira Dias Martins UNILESTEMG Teste de Unidade Erros potenciais que devem ser testados quando a manipulação de erros é avaliada são: o A descrição do erro é ininteligível. o O erro mencionado não corresponde ao erro encontrado. o A condição de erro provoca a intervenção do sistema antes da manipulação do erro. o O processamento da condição de exceção está incorreto. o A descrição de erro não fornece informação suficiente para ajudar na localização da causa do erro. Profª Renata Vieira Dias Martins UNILESTEMG Teste de Unidade * Teste de limite é a última tarefa (e provavelmente a mais importante) do passo de teste de unidade. O software frequentemente falha nos seus limites. Isto é, frequentemente ocorre um erro quando n-ésimo elemento de uma matriz n-dimensional é processado, quando a i-ésima repetição de um ciclo com i passos é invocada, quando o valor máximo e mínimo permissível é encontrado. * Casos de teste que exercitam a estrutura de dados, fluxo de controle e valores de dados imediatamente abaixo, sobre e imediatamente acima do máximo e do mínimo têm grande probabilidade de descobrir erros. Profª Renata Vieira Dias Martins UNILESTEMG Uma vez testados os componentes individuais de programa, eles devem ser integrados para criar um sistema parcial ou completo. Os testes de integração devem ser desenvolvidos a partir da especificação do sistema e começar assim que as versões de alguns dos componentes do sistema estejam disponíveis. Há complexas interações entre os componentes de sistema e, quando uma saída anômala é descoberta, pode ser difícil encontrar a origem do erro. Testes de Integração Profª Renata Vieira Dias Martins UNILESTEMG Integração não incremental: abordagem "big-bang". O programa completo é testado como um todo e o resultado é o caos. Quando erros são encontrados, a correção é difícil porque o isolamento das causas é complicado pela vasta amplitude do programa inteiro. Integração Incremental: o programa é construído e testado em pequenos segmentos, onde os erros são mais fáceis de serem isolados e corrigidos; as interfaces têm maior probabilidade de serem testadas completamente e uma abordagem sistemática ao teste pode ser aplicada. Testes de Integração Profª Renata Vieira Dias Martins UNILESTEMG Inicialmente, é necessário integrar uma configuração mínima do sistema e testar esse sistema. Em seguida, são adicionados componentes a essa configuração mínima, que é testada depois de cada componente adicionado. Os testes realizados inicialmente devem ser repetidos a cada adição de componentes. Testes de Integração Profª Renata Vieira Dias Martins UNILESTEMG Testes de Integração/Interface Os erros são um resultado da interação entre objetos e não do comportamento isolado em um único objeto. As setas para a delimitação da caixa significam que os casos de teste não são aplicados aos componentes individuais, mas aos subsistemas criados pela combinação desses componentes. Profª Renata Vieira Dias Martins UNILESTEMG Parâmetros: Dados ou referências de funções são passados de um componente para o outro. Memória compartilhada: Um bloco de memória é compartilhado entre subsistemas. Os dados são colocados na memória por um subsistema e são recuperados a partir daí por outros subsistemas. Procedimento: Um subsistema encapsula um conjunto de procedimentos que podem ser chamados por outros subsistemas. Os objetos e os tipos de dados têm essa forma de interface. Passagem de mensagem: um subsistema pede um serviço de outro subsistema, passando-lhe uma mensagem. Uma mensagem de retorno inclui os resultados da execução do serviço. Alguns sistemas orientados a objetos têm esse tipo de interface, como acontece com os sistemas cliente-servidor. Testes de Integração/Interface Profª Renata Vieira Dias Martins UNILESTEMG Testes de Validação Ao término da atividade de teste de integração, o software está completamente montado como um pacote, erros de interface foram descobertos e corrigidos e uma série final de testes de software – os testes de validação – podem começar. A validação é bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente. A Especificação de Requisitos de Software contém os critérios de validação que formam a base para uma abordagem ao teste de validação. Profª Renata Vieira Dias Martins UNILESTEMG A validação do software é realizada por meio de uma série de testes de caixa preta que demonstram a conformidade com os requisitos. O plano e o procedimento de teste são projetados para garantir que: o todos os requisitos funcionais são satisfeitos; o todos os requisitos de desempenho são conseguidos; o a documentação está correta; o outros requisitos são cumpridos: portabilidade, compatibilidade, remoção de erros e manutenibilidade. Testes de Validação Profª Renata Vieira Dias Martins UNILESTEMG Um elemento importante do processo de validação é a revisão de configuração ou auditoria. O propósito dessa revisão é garantir que todos os elementos da configuração de software tenham sido adequadamente desenvolvidos, estão catalogados e têm os detalhes necessários para apoiar a fase de manutenção do ciclo de vida do software. Revisão de Configuração Testes de Validação Profª Renata Vieira Dias Martins UNILESTEMG

É virtualmente impossível que se preveja como o cliente realmente usará um programa. As instruções de uso podem ser mal-interpretadas, combinações estranhas de dados podem ser regularmente usadas, saídas que pareciam claras ao analista podem ser ininteligíveis para um usuário em campo. Para um Software Customizado para um Cliente são realizados testes de aceitação, conduzidos pelo usuário final a fim de capacitá-lo e para validar todos os requisitos. Pode variar de um test drive informal a uma série de testes planejados. Testes Alfa e Beta Testes de Validação Profª Renata Vieira Dias Martins UNILESTEMG Se o software é desenvolvido como um produto a ser usado por vários clientes, não é prático realizar testes formais de aceitação de cada um. A maioria dos desenvolvedores de software usa um processo chamado teste alfa e beta para descobrir erros que apenas o usuário final parece capaz de descobrir. Testes de Validação Testes Alfa e Beta Profª Renata Vieira Dias Martins UNILESTEMG Teste Alfa - É conduzido nas instalações do desenvolvedor com o cliente. O software é usado num ambiente natural com o desenvolvedor "olhando sobre os ombros" do usuário e registrando erros e problemas de uso. São conduzidos num ambiente controlado Teste Beta - é realizado nas instalações do cliente pelo usuário final do software. O desenvolvedor não está presente. O cliente registra os problemas (reais ou imaginários) que são encontrados e os relata ao desenvolvedor a intervalos regulares. Testes de Validação Profª Renata Vieira Dias Martins UNILESTEMG O que o engenheiro de software deve fazer? 1. Projetar caminhos de tratamento de erros que testem todas as informações que chegam de outros elementos do sistema. 2. Realizar uma série de testes que simulem dados ruins ou outros erros em potencial na interface do software. 3. Registrar os resultados de teste para usar como "prova" se alguém lhe apontar o dedo. 4. Participar do planejamento e projeto dos testes do sistema para garantir que o software seja adequadamente testado. Testes de Sistema Profª Renata Vieira Dias Martins UNILESTEMG Muitos sistemas baseados em computador precisam recuperar-se de falhas e retomar o processamento dentro de um tempo previamente especificado.Em certos casos, o sistema deve tolerar falhas, isto é, o processamento de falhas não deve fazer com que uma função global de sistema cesse. Em outros casos, uma falha do sistema deve ser corrigida dentro de um período previamente especificado; caso contrário, graves prejuízos econômicos ocorrerão. O teste de recuperação é um teste de sistema que força o software a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada. Teste de Recuperação Testes de Sistema Profª Renata Vieira Dias Martins UNILESTEMG Qualquer sistema baseado em computador que gerencie informações delicadas ou provoque ações que possam impropriamente prejudicar (ou beneficiar) pessoas constitui um alvo para o acesso impróprio ou ilegal. O teste de segurança tenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de fato, de acessos indevidos. Durante o teste de segurança, o analista desempenha o papel de pessoa que deseja penetrar no sistema. Qualquer coisa vale! Teste de Segurança Testes de Sistema Profª Renata Vieira Dias Martins UNILESTEMG o adquirir senhas mediante contatos externos o atacar o sistema com software customizado projetado para derrubar quaisquer defesas que tenham sido construídas o desarmar o sistema, negando serviço a outros o provocar erros intencionalmente, esperando acessá-lo durante a recuperação o "folhear" através de dados inseguros esperando descobrir a chave para a entrada no sistema. O papel do projetista do sistema é fazer com que o acesso custe mais do que o valor da informação que será obtida. Testes de Sistema Teste de Segurança Profª Renata Vieira Dias Martins UNILESTEMG Testes de Estresse Uma vez que o sistema tenha sido completamente integrado, é possível testá-lo quanto a desempenho e confiabilidade. Sistemas são projetados para uma determinada carga. Testes de estresse continuam além da carga máxima até que o sistema falhe. Testes de Sistema Profª Renata Vieira Dias Martins UNILESTEMG Esse tipo de teste tem duas funções: 1. Testa o comportamento de falha do sistema - eventos inesperados. 2. Causa estresse no sistema e pode acarretar a detecção de defeitos que, normalmente não se manifestariam. São particularmente relevantes para sistemas distribuídos Testes de Estresse Testes de Sistema

Métricas e Estimativas Métricas e Medição de Software * Métrica é uma indicação do que e como medir. * Na Engenharia de Software, mede-se um software por várias razões: o Indicar a qualidade do produto o Avaliar a produtividade das pessoas durante o projeto o Avaliar os benefícios derivados de novos métodos e/ou ferramentas de software o Estabelecer uma baseline para futuras comparações e estimativas o Justificar o pedido de novas ferramentas ou treinamento adicional * Existem diversos tipos de medidas, que podem ser divididas em duas classes principais: o Métricas de produtividade Permitem avaliar a produtividade do processo. Ou seja, avaliar a eficiência do processo em relação a custos, prazos, recursos, etc. o Métricas de qualidade Permitem avaliar a qualidade do software. Isto é, verificar se o número de erros está muito grande para o tamanho do programa, etc. * Em qualquer das classes, elas podem ser também classificadas em duas outras categorias: o Medidas diretas – por exemplo, o comprimento de uma mesa ou o número de linhas de código o Medidas indiretas – a “qualidade” do parafuso ou a qualidade de um software. Tipos de Métricas

MEDIDAS DO SOFTWARE MEDIDAS DIRETAS MEDIDAS INDIRETAS * Custo * Esforço * Linhas de Código * Velocidade de Execução * Memória * Nro de Erros * Funcionalidade * Qualidade * Complexidade * Eficiência * Confiabilidade * Manutenabilidade Tipos de Métricas * Exemplos de medidas diretas: o custo do software em R$, US$, etc. o tempo gasto para produção o número de linhas de código produzidas o Velocidade de execução (em segundos) de uma tarefa o Tamanho de memória ocupado pelo software o Número de erros encontrados em um espaço de tempo * Exemplos de medidas indiretas: o qualidade do software o usabilidade do software o manutenibilidade o funcionalidade o eficiência o confiabilidade Métricas orientadas ao tamanho * São métricas diretas * São também o tipo de métricas mais simples * Geralmente se baseiam principalmente no número de linhas de código de um software. o O termo utilizado para descrever o tamanho do programa é LOC (Lines of Code), ou linhas de código o Também é comum fazer a medida em termos de milhares de linhas de código, ou KLOC (Thousand Lines of Code). * Se a organização fizer um registro de suas atividades, as medidas de tamanho são computadas quase automaticamente. Métricas MÉTRICAS ORIENTADAS AO TAMANHO LOC/KLOC projeto esforço $ KLOC pags.docum. erros pessoas projA-01 24 168 12.1 365 29 3 projB-04 60 440 27.2 1224 86 5 projC-03 48 314 20.2 1050 64 6 MÉTRICAS DERIVADAS PRODUTIVIDADE = QUALIDADE = CUSTO = DOCUMENTAÇÃO = KLOC / pessoas-mês erros / KLOC $ / KLOC pags.docum. / KLOC * Fáceis de serem obtidas * Existem vários modelos e literatura que se baseiam nas linhas de código VANTAGENS DESVANTAGENS * O número de LOC depende da linguagem de programação * Programas bem projetados, pequenos, serão injustamente classificados como improdutivos. * Linguagens não procedimentais não podem ser avaliadas por estas medidas * Não se pode utilizar essas métricas para fazer estimativas na fase de planejamento. Métricas Orientadas à Função * São métricas indiretas * Em vez de contar o número de linhas de código, concentra-se na funcionalidade e utilidade do software. * Geralmente utiliza-se o conceito de “pontos por função”, ou function point. * Os pontos por função são computados utilizando cinco tipos de informações baseadas no software. o Número de entradas do usuário o Número de saídas do usuário o Número de consultas do usuário o Número de arquivos o Número de interfaces externas o Entradas do usuário – cada ponto do software onde o usuário entra com qualquer tipo de dado. o Saídas do usuário – pontos onde o software fornece informações ao usuário, tais como relatórios, telas, mensagens de erro etc. o Consultas do usuário – pontos do software onde o usuário entra com um dado, por meio do qual o sistema gera uma saída (a resposta à sua consulta). o Arquivos – Número de arquivos que compõem o software. o Interfaces externas – meios de comunicação do software com entidades externas a ele, tais como disquetes, impressora, etc. * Após a computação desses valores, preenche-se a seguinte tabela: MÉTRICA ORIENTADA À FUNÇÃO - PF PONTOS POR FUNÇÃO É APLICADO ATRAVÉS DE 3 PASSOS: 1) Completar a seguinte tabela: fator de ponderação Parâmetro Contagem Simples Médio Complexo nro de entradas x 3 4 6 do usuário nro de saídas x 4 5 7 do usuário nro de consultas x 3 4 6

do usuário nro de arquivos x 7 10 15 nro de interfaces x 5 7 10 externas Contagem-Total Métricas * Após preencher os dados da contagem, deve-se multiplicar por um valor de complexidade. * Cada empresa utiliza seus próprios critérios para definir se a complexidade é pequena, média ou alta. * Após definir a contagem total, calcula-se um valor final FP (Function Point): FP = contagem total x [0,65 + (0,01xSOMA(Fi))] * Os valores constantes da equação são determinados empiricamente. * Os valores de Fi também se referem a ajustes de complexidade, com base na resposta das 14 perguntas – Segundo Passo: MÉTRICA ORIENTADA À FUNÇÃO - PF 2) Responder as questões 1-14, considerando a escala de 0 a 5: influência 0 1 2 3 4 5 nenhuma pouca moderada média significante essencial 1. O sistema exige backup e recuperação confiáveis? 2. É requerida comunicação de dados? 3. Existem funções de processamento distribuído? 4. O desempenho é crítico? 5. O sistema funcionará num sistema operacional existente e intensamente utilizado? 6. São requeridas entrada de dados on-line? 7. As entradas on-line requerem que as transações de entrada sejam construídas com várias telas e operações? 8. Os arquivos são atualizados on-line? 9. Entradas, saídas, arquivos e consultas são complexos? 10. O processamento interno é complexo? 11. O código é projetado para ser reusával? 12. A conversão e a instalação estão incuídas no projeto? 13. O sistema é projetado para múltiplas instalações em diferentes organizações? 14. A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário? Métricas MÉTRICA ORIENTADA À FUNÇÃO - PF 3) Ajustar os Pontos por Função de acordo com a complexidade do sistema, através da seguinte fórmula: PF = Contagem-Total x 0,65 + 0,01 x (Fi) i = 1 Fi = valores de ajuste da complexidade das perguntas 1-14 MÉTRICAS DERIVADAS PRODUTIVIDADE = QUALIDADE = CUSTO = DOCUMENTAÇÃO = PF / pessoas-mês erros / PF $ / PF pags.docum. / PF Métricas * Independe da linguagem de programação * Pode ser utilizada no começo da evolução de um projeto VANTAGENS DESVANTAGENS * O método inclui contagens de dados subjetivos. * O valor FP não tem nenhum significado físico direto – é apenas um número. Métricas de Qualidade * A qualidade pode e deve ser medida durante todo o desenvolvimento e duração de um software: o antes do desenvolvimento o durante o desenvolvimento o após o desenvolvimento o após o software ser entregue aos clientes e usuários * Quando se mede a qualidade antes, durante e após o desenvolvimento, temos por exemplo as seguintes métricas: o complexidade do programa o modularidade efetiva o tamanho do programa * E as seguintes métricas são aplicadas após a entrega do software: o corretitude (número de defeitos) o manutenibilidade o integridade o usabilidade Corretitude * É o grau em que o software executa a função que é dele exigida * A medida mais comum de corretitude são os defeitos por KLOC * Defeito é uma falta de acordo com os requisitos * A manutenção exige mais esforço que qualquer outra atividade da ES * A manutenibilidade mede a facilidade com que um programa pode ser: o corrigido se um erro for encontrado o ampliado se o cliente desejar inclusões e alterações * Não há como medi-la diretamente * Exemplo de métrica indireta: Tempo Médio para a Mudança (MTTC): o tempo que demora para: + analisar o pedido de mudança + projetar uma modificação adequada + implementar a mudança + testar + distribuir a todos os usuários Manutenabilidade * Está relacionada com a segurança * Mede a capacidade que um sistema tem de suportar ataques à sua integridade * Os ataques incluem tanto ataques a programas, dados e documentos. * Para medir integridade, utiliza-se dois atributos adicionais: ameaça e segurança.

o Ameaça: probabilidade de que um ataque ocorrerá dentro de um determinado tempo o Segurança: probabilidade de que o ataque será contido. Integridade = S [1 – ameaça x (1-segurança)] Integridade * Mede se o software é amigável, ou user-friendly. * A usabilidade tenta quantificar o quão amigável o software é, por meio de quatro características: o a habilidade física e/ou intelectual exigida para se aprender o sistema; o o tempo exigido para se tornar moderadamente eficiente no uso do sistema o o aumento líquido de produtividade (quando o sistema substituiu outro) quando o sistema é usado por alguém moderadamente eficiente. o avaliação subjetiva das atitudes dos usuários em relação ao sistema. Usabilidade * Por que medir qualidade? o Avaliar a efetividade do processo de engenharia de software o Tomar providências para corrigir elementos do processo que produzem defeitos o O gerente pode identificar quais qualidades são importantes em cada caso o Pode-se avaliar quão bem o desenvolvimento está progredindo em relação às metas de qualidade estabelecidas o Para que o pessoal da área de controle de qualidade identifique a necessidade de melhores padrões a serem adotados no futuro. Análise de métricas * As métricas que levam em consideração o tamanho do código geram muitas controvérsias. Como, então, deve-se medir produtividade? * Para responder essa pergunta deve-se analisar os fatores que influenciam a produtividade: o Fatores humanos: o tamanho e a experiência da equipe de desenvolvimento o Fatores do problema: A complexidade do problema a ser resolvido e o número de mudanças nos requisitos ou restrições do projeto o Fatores do processo: Técnicas de análise e projeto que são utilizados, linguagens, ferramentas e técnicas de revisão. o Fatores do produto: Confiabilidade e desempenho do sistema baseado em computador o Fatores relacionados a recursos: disponibilidade de ferramentas CASE, recursos de hardware e software. * Por exemplo, suponha que duas equipes, A e B, tenham pessoas com iguais habilidades, usando os mesmos recursos e o mesmo processo. * A equipe A está trabalhando num problema simples, com requisitos de confiabilidade e desempenho médios. * A equipe B está trabalhando num problema complexo, com metas de confiabilidade e desempenho extremamente rígidas. * Portanto, com base nos fatores apresentados, a produtividade da equipe A será entre 40 e 140% melhor do que a da segunda equipe. Métricas BASELINE - DADOS HISTÓRICOS * Atributos dos Dados Históricos: o Ajudam a reduzir o risco das estimativas o Devem ser precisos ou próximos de um valor real o Coletados do maior número de projetos possível o As medidas devem ser interpretadas da mesma maneira durante todo o projeto o As aplicações devem ser similares às do trabalho que se quer estudar + Deve existir na empresa um modelo para coleta e cálculo de dados históricos do software Métricas COLETA, COMPUTAÇÃO E AVALIAÇÃO DAS MÉTRICAS Profissionais Gerentes Software Processo de Engenharia de Software Computação das Métricas Avaliação dos Dados Coleta de Dados BASELINE - DADOS HISTÓRICOS Estimativas * O gerente de projetos de software confronta-se com um dilema logo no começo de um esforço de desenvolvimento: o são exigidas estimativas quantitativas mas não existem informações sólidas disponíveis * A estimativa dos recursos, custo e programação das atividades para um esforço de desenvolvimento de software exige: o experiência o acesso a boas informações históricas o coragem para se comprometer com medidas quantitativas quando só existirem dados qualitativos Fator que Reduz o Risco das Estimativas DADOS HISTÓRICOS • Estimativas podem ser feitas com maior segurança • Prazos podem ser estabelecidos para se evitar dificuldades passadas • Riscos globais podem ser reduzidos Estimativas de Projeto de Software * As estimativas são afetadas por muitas variáveis: o humanas o técnicas o ambientais o políticas * As opções para se ter estimativas com graus aceitáveis de risco: o retardar as estimativas do projeto o usar técnicas de decomposição (dividir o problema complexo em pequenos problemas) o desenvolver um modelo empírico o adquirir ferramentas de estimativas Estimativas de Projeto de Software * Cada uma das opções viáveis de estimativas é tão boa quanto bons forem os dados históricos usados para fundamentar a estimativa * Se não existir nenhum dado histórico, o levantamento repousará sobre uma base muito instável As Estimativas Bastam? * Para um determinado projeto de software uma série de diferentes técnicas de estimativa foram usadas e

determinou-se que o projeto exigiria aproximadamente 150 pessoas-mês de esforço para ser concluído. * Usando-se um modelo empírico, estimou-se que a duração do projeto se estenderia por aproximadamente 15 meses de calendário. * E agora? Apenas "começamos"? * A resposta, naturalmente, é NÃO. O Planejamento de Projetos Integração * Antes de começar devemos : o responder a algumas questões importantes sobre riscos o desenvolver uma estratégia para atacarmos o problema o estabelecer um mecanismo para avaliarmos o progresso o organizar os membros do pessoal que foram escolhidos para construir o produto. o cada uma dessas atividades faz parte do planejamento do projeto Estimativas do Projeto de Software Profa. Renata Vieira Dias Martins UnilesteMG renatavd@uol.com.br Introdução * Seção anterior – Métricas de Software o Indicam COMO medir a qualidade e produtividade o Utilizadas antes, durante e após o desenvolvimento o Objetivo: identificar problemas e gerar soluções * Agora: Estimativas de software o São realizadas antes do desenvolvimento de software. No entanto, são atualizadas conforme o desenvolvimento avança. o Objetivos: + adequar os recursos ao problema + Cobrar produtividade dos desenvolvedores na medida certa + Dados para comparação + Verificar a viabilidade de projetos Dificuldades 1. Complexidade do projeto o Quanto mais complexo for o projeto, mais difícil será estimar os recursos necessários. o Por outro lado, a familiaridade com o tipo de aplicação anula esta dificuldade. o Por exemplo, uma aplicação de tempo real é naturalmente complexa. No entanto, se a equipe de desenvolvimento estiver familiarizada com esse tipo de aplicação, as experiências passadas ajudarão a realizar estimativas acertadas. 2. Tamanho do Projeto o O tamanho dificulta as estimativas, pois, à medida que um software cresce, aumenta as conexões entre os vários elementos desse software, dificultando a decomposição do problema. o Como a decomposição do problema é uma das principais abordagens para a realização de estimativas, a dificuldade de decomposição implica na dificuldade de realizar estimativas. 3. Disponibilidade de Informações Históricas o Quanto maior a disponibilidade de dados sobre os projetos realizados anteriormente, melhor serão as estimativas. o Verificando o histórico de recursos gastos com aplicações e a qualidade de softwares já produzidos, pode-se estimar os recursos necessários e a qualidade do software que irá ser desenvolvido. 4. Falta de Dados Concretos o Embora se deseje estimativas quantitativas, ainda não existem muitos dados sobre o projeto a ser desenvolvido. Estimativas de Recursos * O gerente de projetos deve fazer estimativas relacionadas a recursos humanos e também de software e hardware. * Em relação a recursos humanos, deve especificar: o Habilidades exigidas o Disponibilidade o Duração das tarefas o Data de início * Em relação a recursos “físicos”, deve especificar: o Descrição o Disponibilidade o Duração do uso o Data de entrega Recursos Humanos * O responsável pelos recursos humanos deve considerar várias questões: o Postos organizacionais – gerente, engenheiro de software, analista, programador, etc. o Especialidades – telecomunicações, microprocessador, sistemas de tempo real, IA, etc. o Habilidades – linguagens de programação, banco de dados, ferramentas CASE. o Número de pessoas necessárias o Disponibilidade o Duração das tarefas o Data de início Recursos de Hardware * As questões relativas a hardware devem ser consideradas sob dois aspectos principais: o Hardware de desenvolvimento – aquele necessário para desenvolver o software o Hardware de produção – aquele no qual o software desenvolvido será executado. * O primeiro tipo dependerá do segundo, já que o ideal é testar o sistema no ambiente em que ele será executado. * Deve-se levar em consideração também a capacidade de armazenamento e a comunicação entre computadores, permitindo assim interação entre os desenvolvedores. Recursos de Software * Para auxiliar o desenvolvimento de software, pode-se utilizar diversas ferramentas, tais como ferramentas de modelagem, ambientes de linguagens de programação, compiladores, etc. * Já se tornam comuns as chamadas ferramentas CASE (Computer Aided Software Engineering). Reusabilidade * Outro recurso de software que pode ser utilizado para o desenvolvimento de sistemas são trechos de código já desenvolvidos. * Ou seja, em vez de desenvolver completamente um software, pode-se reutilizar funções, procedimentos ou módulos já desenvolvidos para outros softwares. * No entanto, diversos cuidados e preparativos são necessários. O ideal é que, quando se produza um software, já se tomem providências para permitir que partes do código sejam reutilizadas mais tarde. Alguns cuidados são: o Boa documentação o Catalogação e padronização o Categorização em bibliotecas * Quando o gerente de projetos considerar a reutilização de código, deve seguir duas orientações: o Se já existem trechos ou blocos de códigos prontos que podem ser prontamente utilizados, ele deve comprá-los (ou utilizá-los). O custo para comprá-los será quase sempre menor que o custo para desenvolvê-lo. o No entanto, se os trechos ou blocos de códigos existentes demandarem algum tipo de modificação ou adequação para poder ser

utilizado, quase sempre o custo de compra + modificação será igual ou maior que o custo para desenvolver o código equivalente. * Deve-se lembrar ainda de considerar a reusabilidade durante a fase de planejamento e não apenas na fase de codificação. Caso contrário, não haverá tempo para planejar adequadamente e fazer estimativas de custo e tempo. Estimativa de Custo e Preço de Venda * Vimos anteriormente que, quando não existem experiências anteriores, é muito complicado realizar estimativas * Nesses casos, a técnica consiste dos seguintes passos: o Decompor o projeto em componentes elementares o Identificar as atividades necessárias à implementação de cada componente o Estimar o esforço exigido para cada atividade. o Atribuir um valor de custo associado a cada atividade * Deve-se também definir o que se entende por “custo”. o Custos não compreendem apenas os custos dos salários dos desenvolvedores do software o Deve-se considerar o custo total de operação, dividindo-o pelo número de pessoas produtivas. * Os custos incluem diversas categorias, tais como: o Custos relativos ao fornecimento de energia; o Custos com recursos humanos de apoio, como contadores, secretários, faxineiros, etc; o Custos com operações em rede e comunicações; o Custo com instalações centrais, como biblioteca, sanitários, instalações recreativas, etc. e o Custos com previdência social e benefícios, tais como plano de saúde * Quando se consideram todas essas despesas, o valor por cabeça chega a um valor médio de o dobro do salário dos engenheiros de software. * Ou seja, se um engenheiro recebe R$3.000,00 por mês, a empresa terá um custo total de R$6.000,00 vezes o número de engenheiros de software. * Quando se estima o preço que será pedido ao cliente, geralmente é algo do tipo: custo + lucros. * Assim, se cada engenheiro recebe R$3.000,00 por mês e os cálculos mostraram que preciso de 5 engenheiros trabalhando por seis meses, o custo será de (3.000 x 5)x2 = R$30.000,00. * Portanto, o preço de venda para o cliente será de aproximadamente R$30,000,00 + lucro desejado. * Suponha um lucro de 30%. Valor final: R$39.000,00 * No entanto, deve-se levar em conta vários fatores ao decidir a margem de lucro, tais como: o Oportunidade de mercado Pode-se optar por um preço baixo, com o objetivo de iniciar um novo segmento do mercado de software. Aceitando um lucro menor, pode-se obter melhores lucros a longo prazo. o Incerteza da estimativa Quando uma empresa não está segura das estimativas, estima o custo colocando um lucro bem acima do normal, prevendo que surgirão despesas imprevistas. o Condições Contratuais Se o desenvolvedor quiser manter a propriedade do código-fonte para reutilizá-lo, geralmente cobra um preço menor. o Volatilidade dos Requisitos Se existe a probabilidade de que os requisitos sejam modificados, uma empresa pode baixar os preços para “ganhar o cliente” e, mais tarde, cobrar preços altos pelas mudanças. o Saúde Financeira Em época de “vacas magras”, aceita-se um preço reduzido, mas que mantenha a empresa funcionando a longo prazo. Resumo * O que fazer quando existem dados históricos? o Decompor o problema em sub-problemas o Utilizar os dados históricos para fazer estimativas de LOC para cada subproblema ou utilizar a métrica FP. o A partir dos LOC e FP, usar dados históricos de produtividade para calcular o esforço. o A partir do esforço, calcular o custo. o Em seguida, propor um lucro e calcular o valor final. * E se não existem dados históricos? o Utilizar a experiência dos desenvolvedores ou contratar especialistas no domínio da aplicação para calcular LOC utilizar a métrica FP o Estimar produtividade para calcular o esforço o A partir do esforço calcular o custo o Propor o lucro e calcular o valor final

Qualidade de Software QUALIDADE DE SOFTWARE * Qualidade é um dos principais objetivos da Engenharia de Software. * Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção com qualidade. * Tem-se dado grande importância ao processo como forma de se garantir um software de melhor qualidade. Qualidade de Software

Termo que pode ser definido de várias formas, causando mal-entendidos: 1. Qualidade não tem um único sentido; 2. Para cada conceito existem vários níveis de abstração; 3. Visão popular pode ser diferente do seu uso profissional. DEFINIÇÃO: “produto ou serviço de qualidade é aquele que atende perfeitamente, de forma confiável, de forma acessível, de forma segura e no tempo certo as necessidades dos clientes” Qualidade QUALIDADE ESTÁGIOS DE EVOLUÇÃO * abordagem corretiva + - inspeção 100% do produto + - inspeção por métodos estatísticos * abordagem preventiva + - controle da qualidade + - garantia da qualidade + - gestão da qualidade Qualidade: Visão Popular * termo indefinível. * pode ser sentida, discutida, julgada, mas não pode ser medida; * luxo, classe e elegância. Produtos caros e complexos têm melhor nível de qualidade. Confiabilidade e o número de reparos efetuados não são considerados. Definições Crosby: “Conformidade aos Requisitos” Juran: “Conveniência para Uso” Requisitos devem ser claramente definidos e não podem ser mal-interpretados. Não conformidade = ausência de qualidade. * Considera os requisitos e a expectativa do cliente. * Um produto deve ter elementos que satisfaçam as diversas maneiras com que os clientes o utilizarão. * Parâmetros da conveniência para uso: Qualidade de Projeto e de Conformidade. As duas definições são similares embora a segunda dê mais ênfase às expectativas do usuário. Qualidade: Visão Profissional Qualidade de Software * Perspectiva Histórica da Engenharia de Software: o anos 60 - Era Funcional o anos 70 - Era do Método o anos 80 - Era do Custo o anos 90 e depois - Era da Qualidade * Qualidade não é um fator de vantagem no mercado, mas é uma necessidade para a garantia da competitividade. * planejamento de qualidade * melhoria no processo e controle de qualidade * gerenciamento de qualidade no processo * análise de dados sobre a satisfação do cliente são exemplos de técnicas aplicadas ao processo de desenvolvimento. Qualidade de Software Visões sobre a importância da qualidade do produto e do processo * Visão que aborda a qualidade do produto o Funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade (ISO 9126). * Visão que aborda a qualidade do processo o Dos requisitos do usuário à entrega do produto final, existe um processo de desenvolvimento complexo e dividido em fases, que pode comprometer a qualidade do software. Mesmo diante de divergências, o fato é que o processo influi nas características finais do software. QUALIDADE DE SOFTWARE DEFINIÇÕES: “Qualidade de Software é um conjunto de propriedades a serem satisfeitas em um determinado grau de modo que o software satisfaça às necessidades de seus usuários” Ana Regina C. da Rocha “Qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente estabelecidos, a padrões de desenvolvimento explicitamente documentados, e a características implícitas que são esperadas de todo software desenvolvido profissionalmente” Pressman QUALIDADE DE SOFTWARE * qualidade de software não é espontânea. * qualidade do produto depende da qualidade do processo de desenvolvimento. * a existência de um processo formalizado para desenvolver software é pré-requisito para o estabelecimento de um programa de qualidade. Atividades para se obter a qualidade do software: * definir os requisitos de qualidade * embutir qualidade no produto (definição e controle do processo) * medir a qualidade (avaliar o processo e produto) Qualidade de Software Medidas e Métricas “Medir um sistema é conhecer o sistema, por isso medimos um sistema para controlar a sua qualidade.” Porque estabelecer sistemas de medidas? * Avaliar a produtividade de cada Software * Comparar a qualidade de um sistema com outro * Estimar custo e tempo necessário para desenvolver os sistemas * Avaliar a qualidade do serviço * Dar suporte ao cliente Qualidade de Software Medidas e Métricas Após a avaliação: * Aumento da produtividade * Aumento da satisfação do cliente * Informações para o ciclo de vida do sistema * Identificação de softwares complexos Visões de Qualidade de Software Facilidade de Uso, Desempenho, Confiabilidade dos Resultados, Preço do Software, etc.

Taxa de defeitos, Facilidade de Manutenção e Conformidade em relação aos Requisitos de Usuários, etc usuário desenvolvedor organização Cumprimento de Prazo, Boa Previsão de Custo, Boa Produtividade Qualidade do Produto Normas internacionais para avaliação de um produto ISO9126 Características de Qualidade e Métricas (versão brasileira – NBR 13596) ISO9126-1 Características e Subcaracterísticas de Qualidade Confiabilidade Eficiência Portabilidade Usabilidade Manutenibilidade Funcionalidade Qualidade do Produto - ISO9126-1 Normas internacionais para avaliação de um produto Funcionalidade: refere-se a existência de um conjunto de funções que satisfazem à necessidades estabelecidas ou implícitas, e suas propriedades específicas. 1) Acurácia (Exatidão de uma operação) Faz o que foi proposto de forma correta? O produto gera resultados precisos ou dentro do esperado? 2) Adequação Propõe-se a fazer o que é apropriado? Presença das funções especificadas? 3) Interoperabilidade Interage com os sistemas especificados? 4) Conformidade Está de acordo com as normas, leis, etc.? Está de acordo com padrões, regras? 5) Segurança de acesso Evita (ou ao menos previne) acesso não autorizado aos dados? Qualidade do Produto - ISO9126-1 Normas internacionais para avaliação de um produto Confiabilidade: refere-se à capacidade do Software manter seu nível de desempenho, sob condições estabelecidas, e sem apresentar falhas, por um certo período de tempo. 1) Maturidade Com que freqüência apresenta falhas? 2) Tolerância a falhas Ocorrendo falhas, como ele reage? Capacidade do produto para manter determinados níveis de desempenho mesmo na presença de problemas. 3) Recuperabilidade É capaz de recuperar dados em caso de falha? Capacidade do produto para restabelecer o nível de desempenho desejado e recuperar dados em caso de ocorrência de falha. Usabilidade: refere- se ao esforço necessário ao uso e à homologação individual de tal uso, por um conjunto de usuários estabelecido ou subentendido. 1) Inteligibilidade É fácil entender o conceito e a aplicação? 2) Apreensibilidade É fácil aprender a usar? 3) Operacionalidade É fácil de operar e controlar? Qualidade do Produto - ISO9126-1 Normas internacionais para avaliação de um produto Qualidade do Produto - ISO9126-1 Normas internacionais para avaliação de um produto Eficiência:refere-se ao relacionamento entre o nível de desempenho do software e a qualidade de recursos utilizados, sob as condições estabelecidas. A Eficiência serve para avaliar como o Software aproveita esses recursos no tempo. 1) Comportamento em relação ao tempo Qual é o tempo de resposta, a velocidade de execução? Medida do tempo de resposta e de processamento ou taxas de processamento (throughput), ao executar as funções prescritas. 2) Comportamento em relação a recursos Quanto recurso usa? Durante quanto tempo? Medida da quantidade de recursos necessários (CPU, disco e memória, dentre outros) e a duração do seu uso ao executar as funções prescritas. Manutenibilidade: refere-se ao esforço necessário para se fazer modificações específicas no Software. 1) Analisabilidade É fácil de encontrar uma falha, quando ocorre? Esforço necessário para diagnosticar deficiências ou causas de falhas, ou localizar as partes a serem modificadas para corrigir os problemas 2) Modificabilidade É fácil modificar e adaptar? Esforço necessário para realizar alterações, remover falhas ou para adequar o produto a eventuais mudanças de ambiente operacional 3) Estabilidade Há grande risco quando se faz alterações? 4) Testabilidade É fácil testar quando se faz alterações?b Qualidade do Produto - ISO9126-1 Normas internacionais para avaliação de um produto Qualidade do Produto - ISO9126-1 Normas internacionais para avaliação de um produto Portabilidade: refere-se à capacidade do Software ser transferido de um ambiente para outro, com o menor esforço possível. 1) Adaptabilidade É fácil adaptar a outros ambientes? 2) Capacidade de ser instalado É fácil instalar em outros ambientes? 3) Conformidade Está de acordo com padrões de portabilidade? 4) Capacidade de substituição É fácil usar para substituir outro? ISO9126-2 Métricas Externas São medidas indiretas do software, coletadas a partir da medição do sistema computacional no qual o software está inserido. ISO9126-3 Métricas Internas São medidas direta ou indiretamente do software, coletadas a partir de suas próprias características internas, sem a necessidade de execução do código. Qualidade do Produto - ISO9126 Normas internacionais para avaliação de um produto Qualidade do Produto Normas internacionais para avaliação de um produto ISO 14598 Avaliação dos Produtos de Software ISO14598-1 Visão Geral É o complemento da série ISO/IEC 9126, e mostra toda a estrutura de funcionamento das normas da série ISO/IEC 14598, definindo os termos técnicos usados no modelo.

Qualidade do Produto Normas internacionais para avaliação de um produto ISO14598-2 Planejamento e Gerenciamento Fornece os requisitos e os guias para que seja dado suporte às atividades de: desenvolvimento, aquisição, padronização, controle, transferência e realimentação do uso de tecnologias de avaliação no âmbito da organização ISO14598-3 Processo para Equipe de Desenvolvimento Indicadores de qualidade Coleta de dados Avaliação dos dados de medição Melhoria do processo de medição Qualidade do Produto Normas internacionais para avaliação de um produto ISO14598-4 Processo para Adquirentes Os processos pacotes são avaliados por esta norma que estabelecerá um processo sistemático de avaliação ISO14598-5 Processo para Avaliadores Define as atividades necessárias para analisar os requisitos de avaliação ISO14598-6 Módulos de Avaliação Define os procedimentos de avaliação e o formato do relatório de apresentação dos resultados das medições em conseqüência das aplicações das técnicas Qualidade de Software Normas e Certificação Órgãos responsáveis pela avaliação e a criação de normas e padrões: * ISO * IEEE * ABNT * SEI * Softex Qualidade Qualidade do Processo A ISO e a IEC definem processo de software como sendo: “Conjunto de processos usados por uma organização para: planejar, gerenciar, executar, monitorar e melhorar as atividades relacionadas ao software.” Qualidade do Processo Melhoria de Processos e Noções de Maturidade Fluxo contínuo de informação com referencia ao progresso e ao sucesso de todas as pessoas envolvidas no programa Melhoria do Processo Acordo de metas Suporte duradouro e visível pelo gerenciamento Planejamento de metas Supervisão contínua e controlada Avaliação das melhorias do processo pela medição dos resultados Identificação e Remoção de barreiras Provisão de recursos requisitados Qualidade do Processo Normas e propostas * ISO9000-3: Normas para aplicação da série ISO9000 em processos de software. * ISO12207: Processos do ciclo de vida do software. * CMM: Capability Maturity Model * PSP: Personal Software Process * ISO15504 SPICE: Software Process Improvement and Capability dEtermination * Guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software, criado em 1993. * Especifica requisitos mínimos para assegurar a qualidade de produtos e serviços, não definindo modelos ou impondo sistemas de qualidade. Processos da ISO 9000-3: o A estrutura o Atividades do ciclo de vida o Atividades de apoio (Suporte) Qualidade do Processo ISO 9000-3 Qualidade do Processo Normas e propostas – ISO 9000-3 Seqüência para certificação: 1) Estabelece o Sistema de Qualidade 2) Solicitação ao órgão certificador 3) Visita à empresa 4) Auditoria 5) Emissão do Certificado Quadro Comparativo Quadro Comparativo MPS.BR * Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. * Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro. * No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas. MPS.BR * O projeto tem apoio do Ministério de Ciência e Tecnologia, FINEP e Banco Interamericano de Desenvolvimento. No Brasil o projeto é desenvolvido: Softex, governo e universidades. O MPS.Br é dividido em 3 partes: o MR-MPS: Modelo de referência para melhoria do processo de software o MA-MPS – Método de avaliação para melhoria do processo de software o MN-MPS – Modelo de negócio para melhoria do processo de software * Não existe um modelo ideal de avaliação de qualidade que seja aplicável indistintamente às organizações, abrangendo os diversos objetivos que elas tem em relação a qualidade. * A qualidade de software não é garantida somente pela qualidade de processo, mas também pela garantia de qualidade do produto final. * A maior preocupação deve ser sempre a satisfação do usuário final. Conclusões