Projeto de Interface com o Usuário                   Profª Renata Vieira Dias Martins UNILESTEMG                          ...
* Os testes caixa preta são também                  * o teste começa em nível de componente e                             ...
do usuário                                                     o Ameaça: probabilidade de que um ataque                 de...
Um pouco de engenharia de software
Upcoming SlideShare
Loading in …5
×

Um pouco de engenharia de software

2,117 views

Published on

Eu me considero a professora Renata Vieira que deu grandes aulas no UnilesteMG uma das melhores professoras no assunto como não poderia deixar o que eu aprendi de lado, na época eu fiz um pequeno resumo de varias assuntos abordados por ela. Nesta 4 páginas tem um pouco sobre teste do software, usúario, métricas de software e qualidade.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,117
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
31
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Um pouco de engenharia de software

  1. 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 deProjeto 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 classificafundamental 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 - Qualitativomelhor 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 devede 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 textoProfª 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ãoGUI - Graphical User Interface Profª Renata Vieira Dias Martins UNILESTEMG * Freqüência de açõesVantagens das GUIs são: Profª Renata Vieira Dias Martins UNILESTEMG * Seqüência de ações1. Relativamente fáceis de aprender e utilizar; Coloque o usuário no controle * Tempo gasto “olhando” o monitor de vídeo2. 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 erroscom o sistema; aparecem na tela * Tempo de recuperação de erro3. É 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 ajudainteira 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 UNILESTEMGGUI - Graphical User Interface usuário “esticar” um objeto (aumentá-lo de tamanho) é uma implementação de manipulação direta. Projeto de InterfaceProfª 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 SoftwareO 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 UNILESTEMGde 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 paraobjetos 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 entregueleiaute 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 algumaQuais 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 fornecendoProfª 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 softwareProjeto de Interface com o Usuário * os domínios de entrada e saída do programa para descobrir errosQual 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 programausuá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 UNILESTEMGdesenvolvido. 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 emrealimentaçã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 dadirecionamento é 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, oprotó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 UNILESTEMGProjeto 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 dover 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 easpectos 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 quenovo 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 UNILESTEMGProfª 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 aProjeto 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 documentado1. 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. Os2. 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 testeColoque 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 erroque 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 dequero 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 erromuito 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ãoIsso é 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 apenasProfª 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 UNILESTEMGA 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 testeinterface 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 clientedestinadas a simplificar o modo de interação. Profª Renata Vieira Dias Martins UNILESTEMG * Os testes devem ser planejados muito antes do início do testeMas para quem? Profª Renata Vieira Dias Martins UNILESTEMG * O teste deve começar “no varejo” e progredir até o teste “noEm 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ívelimplementaçã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 exaustivosColoque 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 casosDefina os modos de interface de uma forma que usuário deve poder determinar de onde veio e que erro; de testesnã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çãoindesejadas tarefa. visual; do sistemaUm modo de interação é o estado atual da * Deve ser não “opinativa”, ou seja, nunca colocar a Detecção de defeitosinterface. 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 UNILESTEMGdeve entrar e sair do modo com pouco ou Faça a interface consistente Profª Renata Vieira Dias Martins UNILESTEMG Projeto – Casos de Testenenhum 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 paraProfª 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 procuramColoque 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 serComo 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 ospreferê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 UNILESTEMGcaneta 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 dereconhecimento 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 seusPermita 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 suaMesmo 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 Brancaseqüência para fazer alguma outra coisa. Ousuário deve poder “desfazer” qualquer ação, Profª Renata Vieira Dias Martins UNILESTEMG Cores no Projeto de Interface Profª Renata Vieira Dias Martins UNILESTEMGinevitavelmente cometem erros. Confirme ações 1. Limite o número de cores utilizadas e seja conservador Inspeções de Softwaredestrutivas. 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 deColoque 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 únicade 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 querealizam 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 UNILESTEMGrepetidamente. 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, comavanç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. 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 realmentenecessá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 serinterface 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 podemrequisitos; * 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 testesté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 paraInspeçõ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 BetaSã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çãodefeitos 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 UNILESTEMGestá 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áriosCada 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 processoentre parênteses? Os requisitos descritos atendem às necessidades Teste de Unidade chamado teste alfa e beta para descobrir erros que apenas o usuárioEm 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çãoSe 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 Betacada caso em declarações ‘case’, esse requisitos descritos no documento? frequentemente ocorre um erro quando n-ésimo elementoidentificador foi incluído? Verificação e Validação de uma matriz n-dimensional é processado, quando a i- Profª Renata Vieira Dias Martins UNILESTEMGDefeitos de Controle ésima repetição de um ciclo com i passos é invocada, Teste Alfa - É conduzido nas instalações do desenvolvedor com oTodas 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 oantes de seus valores serem utilizadas? Há um conflito de interesses inerente que ocorre encontrado. desenvolvedor "olhando sobre os ombros" do usuário e registrandoTodas 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 controladoO 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 dotamanho 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 osExiste 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 aobuffer? 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çãoDados demonstrar que o programa está livre de erros, que Uma vez testados os componentes individuais deChecagem 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 UNILESTEMGClasse 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 outrosTodas 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émDefeitos 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 paralinks 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 Sistemaespaço foi alocado corretamente? ser vista no contexto da espiral, de dentro para fora. Profª Renata Vieira Dias Martins UNILESTEMGO espaço é explicitamente liberado, depois que Uma Estratégia Integração não incremental: abordagem "big-bang". O Profª Renata Vieira Dias Martins UNILESTEMGnão é mais necessário? Teste de Sistema programa completo é testado como um todo e o resultado Muitos sistemas baseados em computador precisam recuperar-se deDefeitos 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 previamentemento Teste de Integração difícil porque o isolamento das causas é complicado pela especificado.Em certos casos, o sistema deve tolerar falhas, isto é, oTodas 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 globalo 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 decombinam? 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ízoscerta? 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 acompartilhada, 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çãoTodas as variáveis de entrada são utilizadas? para garantir completa cobertura e máxima Inicialmente, é necessário integrar uma configuração Testes de SistemaTodas 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 UNILESTEMGEntradas 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çõesdados sejam corrompidos? construção de programas. As técnicas de projeto de componente adicionado. delicadas ou provoque ações que possam impropriamente prejudicarDefeitos 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 ouInspeçõ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 deProfª 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 acessosA 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 deutilizar 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çaA quantidade de código que pode ser Depois que o software foi integrado, um conjunto de Testes de Integração/Interface Testes de Sistemainspecionada em um determinado tempo testes de alto nível é conduzido. Critérios de Os erros são um resultado da interação entre objetos edepende 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 UNILESTEMGda 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 externosaplicaçã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 paraInspeçõ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 outrosProfª Renata Vieira Dias Martins UNILESTEMG técnicas de teste caixa-preta são as únicas usadas o provocar erros intencionalmente, esperando acessá-lo duranteTestes 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 abranca 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 maisimplementaçã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 Sistemafocalizada no domínio da informação. função/desempenho global do sistema é recuperados a partir daí por outros subsistemas. Teste de SegurançaTenta 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ídostestes caixa-branca são tipicamente aplicados a Teste de Unidade de testes de software – os testes de validação – podem Testes de Estressepequenos componentes de programa (p.ex. * A interface do módulo é testada para garantir começar. Testes de Sistemamó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 funcionateste 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 Estimativasatacado”. * A estrutura de dados local é examinada para critérios de validação que formam a base para umaCaixa-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áriasProfa. 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 produtorenatavd@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/oudesagradável quanto inevitável” * Os caminhos independentes ao longo da garantir que: ferramentas de softwareEd 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 estimativasProfª Renata Vieira Dias Martins UNILESTEMG executados pelo menos uma vez. conseguidos; o Justificar o pedido de novas ferramentas ou treinamentoO projeto efetivo de casos de teste é importante, * Todos os caminhos de manipulação de erros o a documentação está correta; adicionalmas 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 atodo 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 qualidadequando 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 osistema 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 classificadasO 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 mesaProfª Renata Vieira Dias Martins UNILESTEMG * Yourdon chama esta abordagem de Revisão de Configuração ou o número de linhas de códigoTodas 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 qualidadefornecem 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. 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 doMEDIDAS 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 projetoTipos 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 Softwarede 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 desenvolvimentosoftware 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 softwareespaç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étricasMé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á estimarsimples 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 anulanú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 é naturalmentetamanho do programa é LOC (Lines of Code), complexos? o Fatores do problema: A complexidade do complexa. No entanto, se a equipe de desenvolvimento estiverou 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 eKLOC (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 umatividades, 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 elementoscomputadas 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 principaisMétricas Métricas de ferramentas CASE, recursos de hardware e software. abordagens para a realização de estimativas, a dificuldade deMÉ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óricaspessoas complexidade mesmos recursos e o mesmo processo. o Quanto maior a disponibilidade de dados sobre os projetosprojA-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 a86 5 * A equipe B está trabalhando num problema complexo, qualidade de softwares já produzidos, pode-se estimar os recursosprojC-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 ConcretosMÉTRICAS DERIVADAS das perguntas 1-14 * Portanto, com base nos fatores apresentados, a o Embora se deseje estimativas quantitativas, ainda não existemPRODUTIVIDADE = 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 RecursosDOCUMENTAÇÃO = CUSTO = Métricas * O gerente de projetos deve fazer estimativas relacionadas aKLOC / 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 exigidaspags.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çãoVANTAGENS * Pode ser utilizada no começo da evolução de que se quer estudar o DisponibilidadeDESVANTAGENS 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 entregade programação DESVANTAGENS * Programas bem projetados, pequenos, * O método inclui contagens de dados subjetivos. Métricas Recursos Humanosserã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áriasimprodutivos. 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 Disponibilidadecódigo, concentra-se na funcionalidade e usuários o Duração das tarefasutilidade 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 compor 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 sobutilizando 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, permitindosoftware 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 Softwaresoftware 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 utilizarcomo 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 (Computermeio 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: Reusabilidadecompõ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. Opreenche-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 reutilizadasMÉ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çãoATRAVÉS DE 3 PASSOS: + implementar a mudança o adquirir ferramentas de estimativas o Catalogação e padronização1) Completar a seguinte tabela: + testar o Categorização em bibliotecasfator de ponderação + distribuir a todos os usuários Estimativas de Projeto de SoftwareParâ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 quedo 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 para5 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 existentesnro 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 ser4 6 adicionais: ameaça e segurança. de diferentes técnicas de estimativa foram usadas e

×