Carla Câmara De Oliveira

R

SUMÁRIO

1 INTRODUÇÃO 3

2 DESENVOLVIMENTO 4

2.1 O PROCESSO DE INSPEÇÃO DE SOFTWARE 4

2.2 VERIFICAÇÃO E VALIDAÇÃO 6

2.3 TESTABILIDADE DE SOFTWARE 7

2.4 SGBD RECOMENDADO AO PROPRIETÁRIO DA LOCADORA DE LIVROS 10

2.5 LINGUAGEM DE PROGRAMAÇÃO UTILIZADA 11

2.6 MODELO ADEQUADO AO CENÁRIO 12

3 CONCLUSÃO 13

4. REFERÊNCIAS 14

1 INTRODUÇÃO

O presente trabalho destina apresentar uma visão descritiva, específica e real sobre planejamento na organização processual de base tecnológica perante o funcionamento de uma empresa, objetivando estabelecer um processo formal da ação na prática que resulta na diminuição do retrabalho, ganho na produtividade e consequente elevação da qualidade final do produto de software.

A sobrevivência no mercado depende da capacidade do mundo empresarial atender as necessidade de seus clientes, promovendo mudanças e solucionando problemas com agilidade de nível competitivo e qualitativo ao mercado.

Diante a base empresarial, ao visualizar uma análise conceitual tem total significado na administração de uma organização. Essa integração, sendo uma das principais ferramentas disponíveis ao processo de elaboração do sistema empreendedor garante um instrumento de trabalho fundamental que atenda as necessidades dos gestores diante à agilidade e confiança.

É importante definir os principais aspectos teóricos práticos e argumentar os fatos organizados de tal forma que adquirem valor adicional além do valor do fato em si, até chegar ao objetivo proposto de uma empresa estruturada, procurando atender melhor a clientela, oferecendo uma Informatização que garante a satisfação do cliente e facilidade do uso da prática naquilo que realmente executa com agilidade através da tecnologia.

2. DESENVOLVIMENTO

Com base nos conceitos propostos pelos modelos e técnicas, vários processos de desenvolvimento de software são criados para atender as diversas exigências do contexto em que são aplicados de modo processual o desenvolvimento com algumas características semelhantes, como as de serem leves e adaptativos, ao invés de exigirem muitos artefatos, criando uma atmosfera pesada (burocrática), e de serem preditivos, ao tentar planejar e prever as atividades em detalhes por um longo intervalo no ciclo de desenvolvimento.

2.1 O PROCESSO DE INSPEÇÃO DE SOFTWARE

O objetivo de inspeções de software é melhorar a qualidade de artefatos de software através de sua análise, detectando e removendo defeitos antes que o artefato seja passado para a próxima fase do processo de desenvolvimento de software

.

O processo de inspeção foi inicialmente elaborado por FAGAN (1976). Argumentos da literatura e estudos experimentais, visando avaliar este processo, vêm indicando reuniões assíncronas para inspeções de software. Tendo em vista as inspeções com reuniões assíncronas SAUER et al..., (2000), baseados em estudos experimentais, apresentam uma reorganização com mudanças para reduzir o custo e o tempo total da realização deste tipo particular de inspeção.

FAGAN (1976) desenvolveu o processo tradicional de inspeção de software, uma forma detalhada de se realizar uma revisão. Neste processo, existem seis atividades principais:

• Planejamento. Um usuário, desempenhando o papel de moderador da inspeção, define o contexto da inspeção (descrição da inspeção, técnica a ser utilizada na detecção de defeitos, documento a ser inspecionado, autor do documento, entre outros), seleciona os inspetores e distribui o material a ser inspecionado.

• Apresentação. Os autores dos artefatos a serem inspecionados apresentam as características destes. Esta fase pode ser omitida se os inspetores possuem conhecimento sobre o projeto e os artefatos que devem ser inspecionados.

• Preparação. Os inspetores estudam os artefatos individualmente, e eventualmente fazem anotações sobre estes produzindo uma lista de discrepâncias. O fornecimento de técnicas de leitura pode facilitar a execução desta tarefa.

• Reunião. Uma reunião em equipe ocorre, envolvendo o moderador, os inspetores e os autores do documento. Discrepâncias são discutidas, e classificadas como defeito ou falso positivos. A decisão final sobre a classificação de uma discrepância sendo discutida é do moderador. A solução dos defeitos não é discutida durante a reunião, que não deve exceder duas horas, uma vez que após este tempo a concentração e a capacidade de análise dos inspetores costuma reduzir drasticamente. No caso em que uma reunião precisar de mais de duas horas, é sugerido que o trabalho de inspeção continue no próximo dia.

• Retrabalho. O autor corrige os defeitos encontrados pelos inspetores e confirmados pelo moderador.

• Continuação. O material corrigido pelos autores é repassado para o moderador, que faz uma análise da inspeção como um todo e re-avalia a qualidade do artefato inspecionado. Ele tem a liberdade de decidir se uma nova inspeção deve ocorrer ou não.

A inspeção de software é uma importante técnica de V&V. Segundo Somerville (2007 p. 358), através de inspeções pode-se analisar as representações do sistema como documentos de