Trabalho Acadêmico Individual 1º Semestre

SUMÁRIO

1 INTRODUÇÃO 3

1 OBJETIVOS 3

2 PESQUISA SOBRE: 4

2.1 – O processo de inspeção de software 4

2.1.1 Verificação e validação 4

2.1.1.1 Testabilidade de Software 4

3.1 Recomenção de SGBD 5

3.2 Escolha e defesa de linguagem de programação 5

3.3 Escolha de Modelo e Justificativa 6

4 CONCLUSÃO 7

REFERÊNCIAS 8

INTRODUÇÃO

Este estudo mostra os conceitos do processo de inspeção, validação, verificação e testabilidade de software, mostrando como é importante a escolha de um SGBD correto, e toda a complexidade que envolve seus desdobramentos serão objeto de detalhada análise no decorrer deste estudo.

Uma escolha certa de SGBD pode ajudar uma empresa com gastos futuros em manutenção ou até mesmo reformulação de um sistema.

OBJETIVO

GERAL

Conhecer a importância de se escolher bem o melhor SGBD, como as empresas devem utiliza-lo e quais suas vantagens. Apresentar o SGBD da minha escolha e defende-lo mostrando o porquê é a melhor ferramenta.

ESPECIFICOS

• Compreender o processo de inspeção, validação, verificação e testabilidade de software;

• Recomendar o melhor SGBD de minha escolha;

• Identificar a melhor linguagem de programação e defende-la;

• Encontrar o modelo que melhor se adapta ao cenário, e justifica-lo.

1 DESENVOLVIMENTO

1.1 O PROCESSO DE INSPEÇÃO DE SOFTWARE

A inspeção é um processo de revisão formal de software e corresponde a uma das mais importantes atividades de Garantia de Qualidade de Software, sendo que o principal objetivo é descoberta antecipada de falhas (produção de uma saída incorreta em relação à especificação), de modo que eles não se propaguem para o passo seguinte do processo de software. Assim, a Engenharia de software tem utilizado a inspeção como um dos métodos mais eficientes e efetivos na busca por um produto de melhor qualidade[Felizardo 2004].

A inspeção visa encontrar erros lendo, entendendo o que o documento descreve e checando através de um checklist as propriedades de qualidade requeridas, é composto por seis fases, que são: Planejamento, Apresentação, Preparação, Reunião de Inspeção, Retrabalho e Acompanhamento[Fagan 1986].

O processo de inspeção é realizado por uma equipe composta por desenvolvedores e também por mais participantes, que realizam os seguintes papéis[Fagan 1986]:

Autor: é o próprio desenvolvedor do artefato que será inspecionado;

Moderador: é quem lidera a inspeção e as reuniões;

Redator: é quem relata os defeitos encontrados e as soluções sugeridas durante a inspeção;

Inspetor: membros da equipe que tentam encontrar erros no produto.

A inspeção pode ser feita tanto em produtos de software com projetos de software, depende do aspecto que será analisado durante a revisão. Podemos classificar dois tipos básicos de revisão de acordo com os aspectos analisados:

Inspeção de documentos de requisitos: analisa documentos de requisitos encontrando erros enquanto eles são mais fáceis e baratos de serem corrigidos.

Inspeção de código-fonte: Visa a encontrar defeitos no código-fonte, realizando uma análise estática do código. Tornam os programas menos complexos, pois os subprogramas são escritos em um estilo consistente e obedecem a padrões estabelecidos, além disso, o desenvolvimento de sistemas torna-se transparente, a estimativa e o planejamento torna-se mais confiáveis e facilita a manutenção, com o desenvolvimento de sistemas mais compreensíveis e bem documentados.

A inspeção em documentos de requisitos pode revelar inúmeros defeitos, podemos classificá-los como:

Defeito de omissão: informações necessárias ao sistema são omitidas, como exemplo a omissão de uma funcionalidade ou da capacidade de desempenho do sistema.

Defeito de fato incorreto: há informações nos artefatos do sistema que são contraditórios com o domínio da aplicação.

Defeito de inconsistência: a informação aparece mais de uma vez no artefato e de forma diferente em cada aparição causando incoerência.

Defeito de ambigüidade: a informação leva a múltiplas interpretações.

Defeito de informação estranha: uma informação que aparece no artefato e embora esteja relacionada ao domínio, não é necessária para o sistema em questão.

Os defeitos encontrados no código fonte podem ser classificados em:

Defeitos de Omissão: causado pelo esquecimento de algum elemento no programa, como um comando que atribui valor a uma variável por exemplo.

Defeitos de Comissão: um segmento de código incorreto, quando, por exemplo, um operador aritmético errado é usado em uma expressão.

Defeito de inicialização: inicialização incorreta de uma estrutura de dados.

Defeitos de computação: qualquer computação incorreta para a geração do valor de uma variável.

Defeito de controle: causa a execução de um caminho de controle errado para um valor de entrada.

Defeito de interface: quando um módulo usa ou faz suposições sobre dados que não fazem parte de seu escopo.

Defeitos de dados: uso incorreto de uma estrutura de dados..

1.1.1 VERIFICAÇÃO E VALIDAÇÃO

Técnicas de verificação e validação são aplicadas aos softwares durante e depois de seu desenvolvimento para garantir que ele atente sua especificação e fornece as