Um pouco da História da Lógica Matemática?

Resumo

Neste caminho de aprendizagem vamos estudar os princípios fundamentais da matemática e da lógica, os principais elementos da lógica matemática e apresentar a lógica clássica utilizada na linguagem de programação.

UM POUCO DA HISTÓRIA DA LÓGICA

Antes da lógica proposicional que é o assunto abordado em nosso estudo, existe o estudo da lógica como um todo. Vamos ver os principais nomes que marcaram suas épocas no aperfeiçoamento deste estudo.

Aristóteles

Aristóteles (384 a.C.–322 a.C.), filó- sofo grego. Produziu uma obra rica e multifacetada. Nela encontramos uma exaustiva compilação dos conhecimentos do seu tempo, mas também, uma filosofia que ainda hoje influência a nossa maneira de pensar. 

Responsável por escrever os primeiros grandes trabalhos de lógica: Coleção de regras para raciocínio dedutivo que pode ser usado em qualquer área do conhecimento.

Leibniz

Gottfried Wilhelm Leibniz (1646–1716), filósofo e matemático alemão, provavelmente mais conhecido por ter inventado o cálculo integral e diferencial independentemente de Isaac Newton. Propõe o uso de símbolos para mecanizar o processo de raciocínio dedutivo.

Boole

George Boole (1815–1864), matemático e filósofo inglês. Propõem as bases da lógica simbólica moderna usando as idéias de Leibniz.

Video

Assista esse vídeo para ajudar você a entender o trabalho desses pensadores e estudiosos da época. 

LÓGICA PROPOSICIONAL

Em lógica e matemática, uma lógica proposicional (ou cálculo sentencial) é um sistema formal no qual as fórmulas representam proposições que podem ser formadas pela combinação de proposições atômicas usando conectivos lógicos e um sistema de regras de derivação, que permite que certas fórmulas sejam estabelecidas como "teoremas" do sistema formal. As proposições são sentença declarativa com valores verdadeiro ou falso. Por exemplo: “Maria gosta de João e de Pedro”; “Todos os seres humanos têm uma mãe”; “Cinco é maior que quatro”.

A lógica proposicional estuda como raciocinar com afirmações que podem ser verdadeiras ou falsas, isto é como deduzir de um certo conjunto de hipóteses (proposições verdadeiras num determinado contexto)

Pessoal não deixe de ver esse arquivo com excelente conteúdo complementar sobre lógica proposicional

PROPOSIÇÃO:

Sentenças declarativas afirmativas da qual tenha sentido afirmar que seja verdadeira ou que seja falsa. Ou seja, Conjunto de palavras ou símbolos que exprimem um pensamento de sentido completo.

Outro bom exemplo para aprender os conceitos e as principais características sobre lógica proposicional e seus cognitivos

· Buenos Aires é a capital do Brasil.

· A neve é branca.

· Matemática é uma ciência

Quando pensamos, efetuamos muitas vezes certas operações sobre proposições, chamadas operações lógicas. Estas operações lógicas obedecem a regras de um cálculo denominado CÁLCULO PROPOSICIONAL. 

Ficou claro o conceito de proposições??? 

Vamos continuar estudando!

CÁLCULO PROPOSICIONAL: Símbolos

VARIÁVEIS PROPOSICIONAIS: letras latinas minúsculas p, q, r, s,.... para indicar as proposições (fórmulas atômicas).

Exemplos:

A lua é quadrada: p

A neve é branca:  q

Proposições simples e compostas

Proposições simples

Proposições simples (unitárias) são aquelas que não estão acompanhadas de outras proposições.

Exemplos:

Aristóteles era grego.

Lógica não é difícil.

Proposições compostas

As proposições compostas são obtidas combinando proposições simples através de certos termos chamados conectivos. A Lógica dispõe de cinco conectivos: “e”, “ou”, “não”, “se – então”, e “se e somente se”. Utilizando esses conectivos podemos construir as seguintes proposições compostas 

•          João é magro e José é alto.
•          Mário foi ao cinema, João foi ao teatro e Marcelo ficou em casa.
•          Maria foi à praia ou ao mercado.
•          Mário foi ao cinema ou Marcelo ficou em casa.
•          A Lua não é o satélite da Terra.
•          Se a chuva continuar a cair, então o rio vai transbordar.
•          Se João estudar, será aprovado.
•          João será aprovado se e somente se estudar.

REFERÊNCIAS BIBLIOGRÁFICAS

B.M. Acioly. Programação como Matemática ou Lógica Construtiva. Anais do I

Workshop em Lógica, Banco de Dados e Inteligência Computacional, Natal-RN,

9 e 10 de novembro de 1998. Páginas 13 a 22.

B.M. Acioly; B.R.C. Bedregal; A. Lyra. Introdução na Teoria das Linguagens

Formais, dos Autômatos e da Computabilidade. Edições UnP, 2002.

Determinação e desempenho de Tipos de Testes?

Outros Tipos de Testes

     Uma vez que determinamos que o sistema realize as funções exigidas pelos requisitos, devemos voltar à atenção para a forma de como essas funções são realizadas.

     O desempenho do sistema é avaliado em relação aos objetivos do desempenho definidos pelo cliente e expressos nos requisitos não funcionais. O teste de desempenho verifica se o calculo foi bem realizado, desta forma a velocidade da resposta aos comandos do usuário, a precisão do resultado e a acessibilidade dos dados são verificados de acordo com as prescrições de desempenho do cliente.

     Os testes de desempenho verificam tanto o hardware quanto o software e tem como base os requisitos, desta forma os tipos de testes são determinados pelos tipos de requisitos não funcionais especificados.

     Dentro os tipos de testes de desempenho temos:

• Testes de estresse

Avaliam o sistema quanto este é levado aos seus limites por um pequeno período. Se os requisitos definem que um sistema deve lidar com ate um numero especificado de dispositivos ou usuários, um teste e estresse avalia o desempenho do sistema quanto todos os dispositivos estiverem ativos simultaneamente.

• Testes de volume

Abordam a manipulação de grandes quantidades de dados no sistema. Tem por objeto garantir que os sistema reage de maneira conveniente quando os conjuntos de dados processados alcançam seu tamanho máximo.

• Testes de configuração

Analisam as diversas configurações de hardware e software especificados nos requisitos. Alguns sistemas podem ser definidos para atender um publico que possua uma grama variada e distinta de componente de hardware e software. Neste caso o teste de configuração avalia todas as configurações possíveis para garantir que cada uma delas satisfaça os requisitos.

• Testes de compatibilidade

São necessários quando um sistema faz interface com outros sistemas. Tem por objetivo detectar se as interfaces funcionam de acordo com os requisitos. No caso de um sistema banco de dados no intuito de recuperar dados, o teste de compatibilidade examina a velocidade e a precisão dos dados recuperados.

• Testes de regressão

São requeridos quando o sistema testado ira substituir um sistema existente. Este teste garante o desempenho do novo sistema é, pelo menos, tão bom quanto o sistema que vai ser substituído. Os testes de regressão são sempre usados durante o desenvolvimento em fases.

• Testes de segurança

Garantem que os requisitos de segurança sejam satisfeitos. É testado características tais como a disponibilidade, integridade e confidencialidade de dados e serviços.

• Teste de tempo

Avaliam os requisitos relacionados ao tempo necessário para responder a um usuário e ao tempo para realizar uma função. Se uma transação deve ocorrer dentro de um tempo determinado, o teste faz a transação e checa se os requisitos foram atendidos.

• Testes de ambiente

Analisam a capacidade de funcionamento do sistema no local de instalação. Nesse teste incluem tolerância à umidade, ao calor, ao movimento, a presença de produtos químicos, a portabilidade, a interrupção de energia ou a qualquer outra característica do ambiente definida.

• Testes de qualidade

Avaliam a confiabilidade, a manutenibilidade e a disponibilidade do sistema incluem o calculo do tempo médio entre as falhas e do tempo médio entre reparos, assim como o tempo médio para encontrar e resolver um defeito.

• Testes de recuperação

Tratam da resposta à presença de falhas ou a perda de dados, energia, dispositivos e serviços. Projetamos um teste para o sistema onde há uma perda de recursos e é observado como o sistema se recupera de forma apropriada.

• Testes de manutenção

Abordam a necessidade de ferramentas e procedimentos de diagnostico para ajudar a encontrar a fonte dos problemas. Verifica-se existem recursos de auxílio e se eles funcionam de forma adequada.

• Testes de documentação

Asseguram que escrevemos os documentos requeridos e verificamos se estes documentos (manuais de sistema, de usuário, de manutenção e técnicos) existem e se as informações que eles contem são consistentes, precisas e fáceis de entender.

• Testes de usabilidade

Investigam os requisitos que se relacionam com a interface com o usuário do sistema, analisando as telas de exibição, mensagens, formatos de relatórios e outros aspectos que podem relacionar a facilidade de uso.

Abordagem ao Desenvolvimento de software Cleanroom?

Desenvolvimento de software Cleanroom

     Métodos formais foram integrados como uma serie de processos de desenvolvimento de software. Uma abordagem bem documentada que também usa métodos formais é o processo de desenvolvimento Cleanroom. Este processo é uma filosofia de desenvolvimento de software que usa métodos formais para apoiar inspeção rigorosa de software.

     O objetivo dessa abordagem é o desenvolvimento de um software com defeito zero. O próprio nome Cleanroom foi uma analogia feita com as unidades de fabricação de semicondutores, onde os defeitos são evitados através de um processo de manufatura em uma atmosfera ultra limpa.

      A abordagem Cleanroom, baseia-se nas seguintes estratégias:

1. Especificação Formal: o software a ser desenvolvido é especificado formalmente.
2. Desenvolvimento Incremental: o software é particionado em incremento desenvolvidos e validados separadamente.
3. Programação Estruturada: um número limitado de construções abstratas de controle e de dados são usados. O processo de codificação de um programa é um processo de refinamentos sucessivos da especificação.
4. Verificação Estática: o software é verificado estaticamente por meio de inspeções rigorosas de software.
5. Testes Estatísticos de Sistema: cada incremento de software e testado estatisticamente parta determinar a confiabilidade. Esses testes são baseados num perfil operacional desenvolvido em paralelo com a especificação do sistema.

      O uso desta abordagem tem levado a construção de softwares com poucos erros. Os custos desses projetos foram comparáveis a outros projetos que usaram técnicas de desenvolvimento convencionais.

     A inspeção rigorosa do programa e uma parte fundamental do processo Cleanroom. Um modelo de estado do sistema é criado como especificação do sistema, onde o mesmo é refinado através de uma serie de modelos de sistema detalhada para um programa executável.

     Os argumentos matemáticos usados nos Cleanroom não são provas formais de correção. Elas dependem do uso do conhecimento de semânticas formais de linguagem de programação para construir teorias que relacionem o programa e a sua especificação formal.

     O desenvolvimento Cleanroom funciona quando é praticado por engenheiro habilidosos e comprometido.

Técnicas de Testes com Métodos Formais?

Métodos Formais

     Os métodos formais permitem a um engenheiro de software criar uma especificação mais completa, consistente e precisa do que aquelas produzidas por métodos convencionais. A teoria dos conjuntos e a notação logica são usadas para criar um enunciado claro dos requisitos. Essa especificação matemática pode ser analisada para melhorar a correção e consistência. Como a especificação é criada usando uma notação matemática, ela é inerente e menos imprecisa que os métodos informais de representação.

      Essa especificação geralmente é realizada engenheiros de software especialmente treinados. Os métodos formais são importantes por que as falhas podem ter um alto custo em sistemas críticos. Pois vidas podem ser perdidas ou severas consequências econômicas podem ocorrer quando há uma falha do software. Nestas situações é importante que os erros sejam descobertos antes que o software seja posto em operação. Os métodos formais reduzem drasticamente os erros de especificação e como consequência serve de base para um produto com poucos erros no momento que o cliente passa a utilizá-lo.

      Com relação aos passos para a utilização dos métodos formais, o mesmo usa uma notação heurística de conjuntos e especificação construtiva – operadora de conjuntos, operadores lógicos e sequenciais – formam a base dos métodos formais. Os métodos formais definem dados, estados e operações de uma função que não variam pela tradução dos requisitos informais dos problemas para uma representação mais formais. O produto do trabalho é uma especificação formal em uma linguagem formal tal como OCL e Z, que é produzida quanto métodos formais são usados.

      Como os métodos formais usam matemática discreta como mecanismo de especificação, provas logicas podem ser aplicadas a cada função do sistema para demonstrar que a especificação esta correta. Porém, mesmo se as provas logicas não são usadas, a estrutura e disciplina de uma especificação formal vai melhorar a qualidade do software.

     Decidir pelo uso de métodos formais leva em consideração os custos de implantação, bem como as modificações culturais associadas com uma tecnologia radicalmente diferente. Na maior parte dos exemplos, métodos formais tem maior retorno em sistemas de segurança e de negócios críticos.

Técnica deTeste de Software?

Teste de Software

 

 

     Teste de software é o processo de execução do software a fim de determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. Tem por objetivo revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final. E por essa característica da atividade de teste, é dizemos que sua natureza é “destrutiva”, e não “construtiva”, uma vez que visa o aumento da confiança de um software através da exposição de seus problemas antes de sua entrega ao usuário final.

 

     O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal, uma vez que há várias formas de defini-lo onde a forma simples é testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. Onde o objetivo principal desta tarefa é revelar o número máximo de falhas dispondo do mínimo de esforço, mostrando aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.

Segundo Craig e Jaskiel apud Barbosa (2000) a atividade de teste é composta por alguns elementos essenciais que auxiliam na formalização desta atividade. Esses elementos são os seguintes:

• Caso de Teste. descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.
• Procedimento de Teste. é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste.
• Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto. Os critérios de teste podem ser utilizados como:
  • Critério de Cobertura dos Testes: permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado.
  • Critério de Adequação de Casos de Teste: quando, a partir de um conjunto de casos de teste, ele é utilizado para verificar se satisfaz os requisitos de teste estabelecidos pelo critério.
  • Critério de Geração de Casos de Teste: quando o critério é utilizado para gerar um conjunto de casos de teste adequado para um produto ou função.

Defeitos no desenvolvimento de software

Dentro do processo de desenvolvimento de software, todos os defeitos são humanos e, apesar do uso dos melhores métodos de desenvolvimento, ferramentas ou profissionais, permanecem presentes nos produtos, o que torna a atividade de teste fundamental durante o desenvolvimento de um software. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo são dois possíveis fatores que aumentam a complexidade dessa tarefa, e consequentemente aumentam a probabilidade de defeitos. Assim sendo a ocorrência de falhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa que o funcionamento do programa não está de acordo com o esperado pelo usuário. Esse tipo de falha pode ser originado por diversos motivos:

• A especificação pode estar errada ou incompleta;
• A especificação pode conter requisitos impossíveis de serem implementados devido a limitações de hardware ou software;
• A base de dados pode estar organizada de forma que não seja permitido distinguir os tipos de usuário;
• Pode ser que haja um defeito no algoritmo de controle dos usuários.

Os defeitos são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software.

Por exemplo simples de ciclo de vida de desenvolvimento de software (vide a figura 1) : os requisitos expressos pelo cliente são relatados textualmente em um documento de especificação de requisitos em seguida esse documento é então transformado em casos de uso, que por sua vez foi o artefato de entrada para o projeto do software e definição de sua arquitetura utilizando diagramas de classes da UML. Logo após esses modelos de projetos foram usados para a construção do software em uma linguagem que não segue o paradigma orientado a objetos. Note que durante todo esse período uma série de transformações foi realizada até chegarmos ao produto final. Nesse meio tempo, defeitos podem ter sido inseridos.

Essa série de transformações resultou na necessidade de realizar testes em diferentes níveis, visando avaliar o software em diferentes perspectivas de acordo com o produto gerado em cada fase do ciclo de vida de desenvolvimento de um software.

Figura 1. Diferentes Interpretações ao longo do ciclo de desenvolvimento de um software

Fonte: CRAIG e JASKIEL apud Barbosa 2000

Níveis de teste de software

O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software para tal podemos citar os principais níveis de teste de software são:

• Teste de Unidade: também conhecido como testes unitários, cujo objetivo é explorar a menor unidade do projeto, procurando gerar falhas ocasionadas por defeitos de lógica e de implementação em cada módulo, separadamente.
• Teste de Integração: tem como função básica provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto.
• Teste de Sistema: tem por objetivo realizar uma avaliação no software no intuito de encontrar falhas por meio da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software, checando se o produto satisfaz seus requisitos.
• Teste de Aceitação: são testes que simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.
• Teste de Regressão: Teste de regressão é uma estratégia importante para redução de “efeitos colaterais”. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema, podendo ser aplicado em qualquer nível de teste.

Técnicas de teste de software

Existem muitas formas de se testar um software, porém, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas orientados a objeto.

Apesar de os paradigmas de desenvolvimento serem diferentes, o objetivo principal destas técnicas continua a ser o mesmo encontrar falhas no software.

As técnicas de teste são classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. Elas contemplam diferentes perspectivas do software e impõe-se a necessidade de se estabelecer uma estratégia de teste que contemple as vantagens e os aspectos complementares dessas técnicas. As técnicas existentes são: técnica funcional e estrutural.

Técnica Estrutural (ou teste caixa-branca)

Técnica de teste que avalia o comportamento interno do componente de software, técnica que trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos.

Nesta técnica de teste, os aspectos a ser avaliados dependem da complexidade e da tecnologia que determinarem a construção do componente de software. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software.

Teste Funcional (ou teste caixa-preta)

É uma técnica de teste na qual o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não considerando o comportamento interno do mesmo. Nesta técnica os dados de entrada são fornecidos, o teste é executado e o resultado é comparado a um resultado esperado previamente conhecido. Neste caso o teste terá sucesso se o resultado obtido for igual ao esperado. Podemos testar um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste funcional é aplicável a todos os níveis de teste.

Um conjunto de critérios de teste pode ser aplicado aos testes funcionais podemos chamar de:

• Particionamento em classes de equivalência

Esse critério divide o domínio de entrada de um programa em classes de equivalência, a partir das quais os casos de teste são derivados. Tem por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste de cada classe. Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada.:

Devemos seguir tais passos para geração dos testes usando este critério:

1. Identificar classes de equivalência (é um processo heurístico)

- condição de entrada

- válidas e inválidas

2. Definir os casos de teste

- enumeram-se as classes de equivalência

- casos de teste para as classes válidas

- casos de teste para as classes inválidas

• Análise do valor limite

Esse critério de teste explora os limites dos valores de cada classe de equivalência para preparar os casos de teste. Se uma condição de entrada especifica uma faixa de valores limitada em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b.

• Grafo de causa-efeito

Esse critério de teste verifica o efeito combinado de dados de entrada. As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma tabela de decisão, e a partir desta, são derivados os casos de teste e as saídas).

O teste de software é uma das atividades mais custosas do processo de desenvolvimento de software, pois pode envolver uma quantidade significativa dos recursos de um projeto. O rigor e o custo associado a esta atividade dependem principalmente da criticalidade da aplicação a ser desenvolvida. Diferentes categorias de aplicações requerem uma preocupação diferenciada com as atividades de teste.

Um ponto bastante importante para a viabilização da aplicação de teste de software é a utilização de uma infraestrutura adequada. Realizar testes não consiste simplesmente na geração e execução de casos de teste, mas envolvem também questões de planejamento, gerenciamento e análise de resultados. Apoio ferramental para qualquer atividade do processo de teste é importante como mecanismo para redução de esforço associado à tarefa em questão, seja ela planejamento, projeto ou execução dos testes. Após ter sua estratégia de teste definida, tente buscar por ferramentas que se encaixem na sua estratégia. Isso pode reduzir significantemente o esforço de tal tarefa.

Além disso, é importante ressaltar que diferentes tipos de aplicações possuem diferentes técnicas de teste a serem aplicadas, ou seja, testar uma aplicação web envolve passos diferenciados em comparação aos testes de um sistema embarcado. Cada tipo de aplicação possui características especificas que devem ser consideradas no momento da realização dos testes. O conjunto de técnicas apresentado neste artigo cobre diversas características comuns a muitas categorias de software, mas não é completo.

VERIFICAÇÃO E VALIDAÇÃO (V&V) de um Software?

VERIFICAÇÃO E VALIDAÇÃO (V&V)

 

     Logo após finalizar o processo de implementação, o programa deve ser verificado para termos a certeza de que ele atende a sua especificação e entrega a funcionalidade solicitada pelos clientes. O processo de Verificação e Validação (V&V) é o nome dado a esse processo de verificação e analise, onde as atividades de V&V ocorrem em cada fase do processo de software, iniciando com as revisões de requisitos , continuando com o projeto e das inspeções de código até os testes de produtos.

O processo de Verificação e Validação não são a mesma coisa, uma vez que a validação se preocupa se “estamos construindo o produto certo?” e a verificação tem o foco se “estamos construindo o produto da forma correta?”. Desta maneira o papel da verificação nos faz ver se o software esta de acordo com as especificações, se atende ou não os requisitos funcionais e não-funcionais. Já a validação é um processo mais amplo, cuja finalidade é garantir que o software atenda as expectativas do cliente. O maior objetivo do processo de V&V é estabelecer a confiança de que o software esteja adequado ao proposito ao qual foi desenvolvido, porém o nível de confiabilidade depende do fim a que se presta o software, das expectativas dos usuários do sistema e do atual ambiente de mercado.

Dentro do processo de V&V podemos verificar duas abordagens para a verificação e analise de sistema, onde a primeira seria a inspeção de software ou revisões por pares também chamado de técnica de V&V estática, onde analisam e verificam as representações do sistema como um documento de requisitos, diagramas de projeto, código-fonte do programas, etc. e a segunda abordagem seria a de testes de software também conhecida com técnica de V&V dinâmica, que envolvem a execução do software com dados de testes a fim de checar as saídas do software, o comportamento operacional no intuito de verificar se o seu desempenho está conforme o desejado.

As técnicas de inspeções incluem inspeções de programa e de analise de código-fonte, porem não podem demonstrar que o software é operacionalmente útil. Embora as inspeções de software sejam amplamente usadas, os testes de programas será sempre a técnica principal de V&V do software, uma vez que exercita o programa utilizando dados reais processados pelo programa, onde descobre erros e defeitos nos programas. Há dois tipos de testes que podem ser utilizados no processo de software o teste de validação que tem a finalidade de mostrar que o software é o que o cliente deseja e teste de defeitos que é destinado a revelar defeitos no sistema em vez de simular o seu uso operacional, tendo como objetivo encontrar inconsistências entre um programa e sua especificação.

Os processos de V&V e de depuração (debugging) geralmente são intercalados, na medida em que descobre os defeitos no programa, você deve alterar o programa para corrigir esses defeitos. Porem o teste e o debugging tem finalidades diferentes, onde os testes são dedicados a estabelecer a existência de defeitos no sistema e o debugging é um processo que localiza e corrige esses defeitos.

Planejar a verificação e validação é um processo caro, pois para alguns sistemas de tempo real com restrições não-funcionais complexas, boa parte do orçamento pode ser gasto em processos de V&V. Como parte do processo de planejamento de V&V há necessidade de decidir sobre o equilíbrio entre as abordagens estática e dinâmica para os processos de V&V, especificar os padrões e procedimentos para inspeções e testes de software e por fim estabelecer o checklists para direcionar as inspeções nos programas.

O planejamento de teste concentra-se no estabelecimento de padrões para o processo de teste e não apenas na descrição dos testes. Os principais componentes de um plano de teste são:

• Processo de teste
• Rastreabilidade de requisitos
• Itens testados
• Cronograma de testes
• Procedimentos de registro de testes
• Requisitos de hardware e software
• Restrições

Os planos de testes não são documentos estáticos, pois evoluem durante o processo de desenvolvimento, ou seja, mudam devido a atrasos em outros estágios do processo de desenvolvimento.

As inspeções de software é um processo de V&V estática, onde um sistema de software é revisto para encontrar erros, omissões e anomalias. Geralmente tem o foco no código-fonte, mas em qualquer representação legível do software pode ser inspecionado (requisitos, algoritmos, etc). Quando realizamos a inspeção de um sistema, nos usamos o conhecimento do sistema, seu domínio de aplicação, a linguagem de programação ou o modelo de projeto para descobrir erros.

Inspeções é uma ideias antiga, visto que as inspeções são mais eficientes para descobrir defeitos do que testes de programas. Dentre as vantagens dos processos de inspeção podemos citar:

• Durante os testes, os erros podem ocultar outros erros, pois, uma vez que um erro é descoberto não podemos ficar seguros de se outros erros descobertos são devidos a um novo erro ou se são efeitos colaterais dos erros descobertos originalmente. Por ser um processo estático, em uma única sessão de inspeção pode-se descobrir muitos erros de um sistema.
• Versões incompletas podem ser inspecionadas, se um programa esta incompleto é necessário desenvolver um conjunto de testes especializados para essas partes disponíveis, acrescentando assim os custos do projeto.
• A inspeção deve considerar atributos de qualidade mais abrangentes de um programa tais como a conformidade com padrões, portabilidade, facilidade de manutenção, etc.

Revisões e testes tem vantagens e desvantagens que devem ser usadas em conjunto no processo de V&V. Uma das aplicações mais eficientes das revisões é revisar os casos de testes para um sistema. As revisões podem descobrir problemas com esses testes e auxiliar a projetar caminhos mais eficientes para testar um sistema. Inicialmente o V&V do sistema deve começar inspeções no inicio do processo de desenvolvimento e se este for sistema integrado, é preciso testá-lo para verificar as propriedades emergentes e se a funcionalidade do sistema é a que o cliente realmente deseja.

Na há duvidas de que as inspeções que começam no inicio os custos de V&V do sistemas e resultam em economia de custos somente depois que as equipes de desenvolvedores se tornam experientes em seu uso. Além disso as inspeções levam tempo para serem organizadas e parecem diminuir a velocidade do processo de desenvolvimento, sendo difícil de convencer um gerente com projetos em atraso de que esse tempo pode ser recuperado mais tarde pelo fato de que menos tempo será dispendido no processo de debugging.

 

Qual a diferença entre Defeitos, Erros e Falhas em um software?

Inicialmente, precisamos conhecer a diferença entre Defeitos, Erros e Falhas.

• Defeito é um to inconsciente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto.
• Erro é uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro.
• Falha é o comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.

 

Como medir com eficiência a qualidade de software na sua empresa?

Não adianta ter um processo impecável de produção de aplicativo se o produto não estiver em linha com as boas práticas e necessidades do negócio.

Jitendra Subramanyam, NetworkWorld/EUA

13 de maio de 2014 - 09h00

link http://computerworld.com.br/tecnologia/2014/05/13/como-medir-com-eficiencia-a-qualidade-de-software-na-sua-empresa/

     Avaliar a qualidade de um software é um mistério. Muitos profissionais de TI ficam frustrados sobre como definir e medir a qualidade das aplicações.

     Não surpreendentemente, essas dificuldades resultam de um foco incorreto sobre o processo pelo qual o software é construído. Achamos que podemos definir essas atividades e medi-los com precisão para que as pessoas possam ver e focar nas atividades necessárias para criar, melhorar e gerenciar o software.

     Mas de nada adianta ter um processo impecável se o produto não estiver em linha. Infelizmente, esse é o tipo de falha que corremos o risco quando não somos capazes de medir a qualidade do software.

     Essa falta de visibilidade sobre a qualidade está na raiz de muitos problemas de gestão de software. Os executivos de negócios não conseguem entender por qual motivo um software custa tanto, demora tanto tempo para ser desenvolvido e ainda tem custos associados para mudá-lo. CFOs e CEOs, por sua vez, não conseguem entender por que o investimento em TI é tão alto.

     Você deve estar pensando: "Será que não cuidamos da qualidade de testes de software?" Mas o teste é na melhor das hipóteses uma solução parcial. O teste não é realmente concebido para medir a qualidade estrutural do software - a qualidade do design de um aplicativo e da fidelidade de sua implementação para o projeto.

     Um software bem concebido, bem arquitetado e bem executado possui alta qualidade. É fácil trabalhar com ele, mantê-lo e melhorá-lo para suprir as demandas dos negócios. Nós sabemos que medir a qualidade do software é bom, mas podemos, de fato, medi-lo? Sim, graças a produtos que realizam essa tarefa.

     Em uma aplicação, a qualidade de qualquer componente depende de outros componentes que ele está integrado. A qualidade de um aplicativo como um todo é, portanto, mais do que simplesmente a soma da qualidade de seus componentes. O erro mais frequente em engenharia de software é esquecer esse fato.

     Por isso, qualquer sistema que possa ajudá-lo nessa tarefa deverá medir cinco pontos:

1. Alcance: deve ser capaz de lidar com várias tecnologias. A maioria dos aplicativos modernos contém vários idiomas e sistemas que são ligados entre si de forma complexa.

2. Profundidade: deve ser capaz de gerar mapas completos e detalhados da arquitetura do aplicativo do Graphical User Interface (GUI), ferramenta de captura, processamento e análise de imagem, para o banco de dados. Sem essa detalhada arquitetura, seria impossível obter contextualização da aplicação.

3. Tornar o conhecimento explícito de engenharia de software:deve ser capaz de verificar a aplicação inteira contra centenas de padrões de implementação que codificam as melhores práticas de engenharia.

4. Métricas acionáveis: as métricas de qualidade não devem apenas informar, mas também orientar sobre como realizar a melhoria da qualidade do software, mostrando o que fazer primeiro, como fazê-lo, próximos passos etc.

5. Automatização: finalmente, deve ser capaz de realizar todos os pontos descritos acima de forma automatizada. Nenhum profissional ou equipe pode fazer essa tarefa, muito menos fazê-la em um curto espaço de tempo.

      É importante medir a qualidade do software, mas é igualmente importante executar a atividade de forma correta. Essa ação é muito útil no desenvolvimento de software, mas, muitas vezes, é melhor não ter medição alguma do que contar com uma errada.

Padrões de projeto na arquitetura de software?

     Padrões de projeto são comumente definidos como soluções já testadas para problemas recorrentes de design. Padrões de projeto têm suas raízes no trabalho de Christopher Alexander, um engenheiro civil, que escreveu sobre sua experiência na resolução de problemas de design e como eles se relacionam com os edifícios e cidades. Ocorreu a Alexander que certas construções de design, quando eventualmente era usado, levava ao efeito desejado. Ele documentou e publicou a sua experiência para que outras pessoas pudessem se beneficiar. Os profissionais de software passaram a incorporar princípios de Alexander para a criação e documentação de padrão de design.

     Os Design Patterns (Padrão de projeto) são uma coleção de padrões de design de software, que são soluções para problemas conhecidos e recorrentes no desenvolvimento de software. Um Pattern descreve uma solução comprovada para um problema de design recorrente. Patterns são dispositivos que permitem que os programas compartilhem conhecimento sobre o seu design. Quando programamos, nós encontramos muitos problemas que ocorrem, ocorreram e irão ocorrer novamente. A questão que nos perguntamos agora é como nós vamos solucionar este problema desta vez? Documentar um padrão (pattern) é uma maneira de você poder reusar e possivelmente compartilhar informação que você aprendeu sobre a melhor maneira de se resolver um problema de design de software.

PORQUE USAR OS PATTERNS?

• Porque eles foram provados. Os padrões refletem a experiência, conhecimento e soluções dos desenvolvedores que tiveram sucesso usando esses padrões em seus trabalhos.
• São reusáveis. Os padrões provêem uma solução pronta que pode ser aplicada à diferentes problemas.
• São expressíveis. Os padrões provêem um vocabulário comum de soluções que podem expressar muitas soluções, sucintamente. É importante lembrar que os padrões, por si só, não garantem o sucesso do seu uso. A descrição do padrão indica quando ele pode ser aplicado, mas apenas a experiência pode proporcionar o entendimento de quando um padrão particular irá melhorar o design do sistema.

Tipo de padrão

     Eles podem ser de criação (Creational Patterns), de estrutura e de comportamento. Por exemplo: se preciso adotar um padrão para criação de objetos, terei que olhar para os padrões existentes em “padrões de criação”.

• Creational Patterns

     Todos os padrões criacionais (Creational) lidam com a melhor forma de se criar instâncias dos objetos. Isto é importante porque seu programa não deveria depender de como os objetos são criados e arranjados.

• Factory Method

     Este é um tipo bem comum de padrão utilizado nos programas orientados ao objeto. O padrão Factory Method é caracterizado por retornar uma instância dentre muitas possíveis classes, dependendo dos dados providos a ele. Geralmente, todas as classes que ele retorna têm uma classe pai e métodos em comum, mas cada um executa tarefas diferentes e é otimizado para diferentes tipos de dados.

• Abstract Factory Method

     O padrão Abstract Factory está a um nível de abstração maior do que o padrão Factory Method. Você pode usar este padrão quando deseja retornar uma das muitas classes de objetos relacionadas, cada qual pode retornar diferentes objetos se requisitado. Em outras palavras, o padrão Abstract Factory é uma fábrica de objetos que retorna uma das várias fábricas.

• Singleton

      O padrão Singleton assegura que apenas uma única instância daquela classe vai existir. Por exemplo, seu sistema pode ter apenas um gerenciador de janelas, ou gerenciador de impressão, ou então um único ponto de acesso ao banco de dados.

• Builder

     O padrão Builder constrói um número de objetos, como telas, de vários modos, dependendo dos dados. 

     O padrão Builder é algo como o Abstract Factory, na qual ambos retornam um número de métodos e objetos. A principal diferença é que enquanto o Abstract Factory retorna uma família de classes relacionadas, o Builder constrói um objeto complexo passo-a-passo, dependendo dos parâmetros passados a ele.

Arquitetura de Software e Padrões de Projeto?

Uma arquitetura define a estrutura

     Se você pedir a pessoa para descrever "arquitetura", nove em cada dez vão fazer alguma referência à estrutura. Essas estruturas na maioria das vezes vão fazer referencia a um edifício ou qualquer outra estrutura de engenharia civil como uma ponte por exemplo. Embora existam outras características da arquitetura de software como o comportamento, adequação à finalidade, e até mesmo a estética, é a característica estrutural que é frequentemente mencionados.

     Portanto quando você pedir a alguém para descrever a arquitetura de um sistema de software que ele está trabalhando, provavelmente ele te mostrará um diagrama que mostra os aspectos estruturais do sistema.

Muitas definições de arquitetura também reconhece não só os próprios elementos estruturais, mas também a composição de elementos estruturais, seus relacionamentos (e todos os conectores necessários para apoiar essas relações).

Uma arquitetura define o comportamento

     Além de definir os elementos estruturais, uma arquitetura define as interações entre esses elementos estruturais. São essas interações que fornecem o comportamento do sistema desejado.

Uma arquitetura concentra-se em elementos significativos

     Enquanto se define a estrutura e comportamento, ela não está preocupado com a definição de toda a estrutura e de todos os comportamentos. Ela só se preocupa com os elementos que são considerados significativos. Elementos significativos são aqueles que têm um efeito longo e duradouro, tais como os principais elementos estruturais, os elementos associados com o comportamento essencial, e os elementos que abordam qualidades importantes, como confiabilidade e escalabilidade. Em geral, a arquitetura não está preocupado com os detalhes de granulação fina desses elementos.

     Também é interessante notar que o conjunto de elementos significativos não é estática e pode mudar ao longo do tempo. Em consequência das exigências sendo refinada, os riscos identificados, software executável e as lições aprendidas, o conjunto de elementos significativos podem mudar. No entanto, a relativa estabilidade da arquitetura em face da mudança é um sinal de uma boa arquitetura, e o fato de executar bem um processo de arquitetura, é o sinal de um bom arquiteto. Se a arquitetura precisa ser continuamente revista devido a mudanças relativamente pequenas, então este não é um bom sinal.

Uma arquitetura incorpora decisões baseadas em lógica

     Um aspecto importante de uma arquitetura não é apenas o resultado final, a própria arquitetura, mas a razão por ela ser do jeito que é. Assim, uma consideração importante documentar as decisões que levaram a esta arquitetura e as razões para tais decisões.

     Esta informação é relevante para muitas partes interessadas, especialmente os que devem manter o sistema. Esta informação é muitas vezes valiosa para o arquiteto, quando ele precisa de revisar o raciocínio por trás das decisões que foram tomadas. Por exemplo, esta informação é utilizada quando a arquitetura precisa revisar e justificar as decisões que foram tomadas.

Uma arquitetura pode estar de acordo com um estilo arquitetônico

     A maioria das arquiteturas são derivadas de sistemas que compartilham um conjunto semelhante de preocupações. Esta semelhança pode ser descrita como um modelo de arquitetura, que pode ser pensado como um tipo particular de padrão. Como um padrão, um estilo arquitetônico representa uma codificação da experiência, e é uma boa prática para arquitetos para procurar oportunidades para reutilizar tal experiência. Exemplos de estilos arquitetônicos incluem um estilo distribuído, um estilo centrado em dados, um estilo baseado em regras, e assim por diante. Um sistema dado pode apresentar mais do que um estilo arquitetônico.

Como Shaw e Garlan descreve:

[Um estilo arquitetônico] define uma família de sistemas em termos de um padrão de organização estrutural. Mais especificamente, um estilo arquitetônico define um vocabulário de componentes e tipos de conectores, e um conjunto de restrições sobre como eles podem ser combinados. 9

Ou em termos de UML:

[Um padrão é] uma solução comum para um problema comum em um dado contexto.

Além da experiência em reuso, a aplicação de um estilo arquitetônico (ou padrão) torna a nossa vida um pouco mais fácil, já que um estilo é normalmente documentado em termos da razão para usá-lo e em termos de sua estrutura e comportamento (e por isso há menos documentação arquitetura a ser produzida, uma vez que pode simplesmente se referir ao estilo em seu lugar).

Arquitetura de Software?

     Arquitetura de Software é um conjunto de decisões significativas sobre a organização de um sistema de software, a seleção de elementos estruturais e suas interfaces juntamente com o comportamento especificado nas colaborações entre estes elementos, a composição destes elementos em subsistemas progressivamente maiores e o estilo arquitetural que guia esta organização (IBM).


     Arquitetura é a organização fundamental de um sistema materializado em seus componentes, na relação entre eles e com o ambiente e nos princípios que guiam seu projeto e evolução (IEEE)


     A arquitetura de software define quais serão os elementos que constituirão o software (módulos) seus relacionamentos e pelos princípios (padrão) que conduzem seu design e evolução.


     Ela está preocupada em compreender como deve ser organizado os elementos do sistema e suas estruturas. No processo de desenvolvimento de software, o projeto de arquitetura é um dos principais estágios que liga o projeto à engenharia de requisitos, pois é nesta fase que são identificados os principais componentes, estruturas e seus relacionamentos. O resultado do projeto de arquitetura é um modelo que descreve como deve ser organizado os elementos (componentes ou módulos) do sistema e de que forma estes elementos irão se comunicar (protocolos de comunicação).


     O projeto de arquitetura de sistema é muito importante, pois afeta diretamente o desempenho, a robustez do software, a capacidade de distribuição e na sua manutenção. Cada componente individua representa um requisito funcional do sistema, já os requisitos não funcionais dependem da arquitetura do sistema ou seja a forma como estes componentes estão organizados e da comunicação entre eles.

Bass et al. (2003) discute três vantagens de projetar e documentar a arquitetura de software.

• Comunicação de stakeholders. A arquitetura é uma apresentação de alto nível do sistema e pode ser usada como um foco de discussão por uma série de diferentes stakeholders.
• Análise de Sistemas. Tornar explícita a arquitetura de sistema, em um estágio inicial do desenvolvimento, requer alguma análise. As decisões de projeto de arquitetura tem um efeito profundo sobre a possibilidade de o sistema atender ou não aos requisitos críticos, como desempenho, confiabilidade e manutenibilidade.
• Reuso em larga escala. Um modelo de arquitetura de sistemas é uma descrição compacta e gerenciável de como um sistema é organizado e como os componentes interoperam. A arquitetura do sistema geralmente é a mesma com requisitos semelhantes e, por isso, pode apoiar o reuso de software em grande escala.

     Não há dúvida de que o mundo está se tornando cada vez mais dependentes de software. Software é um elemento essencial no mundo corporativo e por que não dizer nas nossas vidas em particular. Mesmo as organizações tradicionais, como organizações financeiras, varejo e setor público, não sobreviveriam sem a presença forte de um software. Hoje em dia, a aplicação de softwares em seus negócios.

     Para que estas organizações sobrevivam, o software de que eles dependem devem fornecer a capacidade exigida, ter qualidade suficiente, estar disponível quando prometido, e ser entregue a um preço aceitável.

     Todas essas características são influenciadas pela arquitetura do software.