Analise De Sistemas 2 Semestre

SUMÁRIO

1 INTRODUÇÃO...........................................................................................................

2 PROCESSO DE INSPEÇÃO DE SOFTWARE...........................................................

2.1. 2.1 VERIFICAÇÃO E VALIDAÇÃO

2.1.1 VERIFICAÇÃO

2.1.2 VALIDAÇÃO

2.1.3 TESTABILIDADE DE SOFTWARE

3. SGDB (Banco de Dados)

3.1 MODELO DE PROCESSO PROPOSTO:

4 CENÁRIO PROPOSTO A LOCADORA

4.1 Login:

4.2 Consulta:

4.2.1 Pesquisar:

CONCLUSÃO

REFERÊNCIAS

1 INTRODUÇÃO

O objetivo desse trabalho é mostrar a importância da tecnologia da informação nas empresas, o principal passo é planejar o modo de trabalho, o segundo é implantar um bom sistema de informação, para guardar os dados da empresa, transformando em informação e gerar conhecimento para os profissionais qualificados que vai usufruir das informações da empresa, ter controle absoluto das informações, para poder usar da melhor forma, em busca do crescimento da empresa dentro da sociedade.

Os sistemas de informação são muito importantes pelo modo de armazenar e fornecer informações dentro da organização. Temos vários tipos de sistemas de informação, mas todos com o objetivo de gerar informação e conhecimento para os profissionais que utilizam essa ferramenta.

2. PROCESSO DE INSPEÇÃO DE SOFTWARE

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 utilizado 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.

2.2. VERIFICAÇÃO E VALIDAÇÃO

2.1.1 VERIFICAÇÃO

A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requisitos, funcionalidades e performance documentados foram implementados.

Verificação também pode ser realizada para especificação de sistemas, para avaliar se os requisitos estão sendo documentados como deveriam e ainda prever falhas ou inconsistências entre requisitos.

2.1.2 VALIDAÇÃO

A validação tem o objetivo de avaliar se o que foi entregue atende as expectativas. Ou seja, se os requisitos, independente do que foi planejado, estão implementados para atender ao negócio (cliente).

Validação final do sistema é realizada pelo cliente ou usuário.

2.1.3 TESTABILIDADE DO SOFTWARE

Teste é um processo de execução de um programa com a finalidade de encontrar um erro. Os testes podem ser planejados e projetados antes que qualquer código tenha sido gerado. Os primeiros testes planejados e executados geralmente concentram-se nos componentes individuais. à medida que o teste progride, o foco se desloca numa tentativa de encontrar erros em conjuntos integrados de componente e finalmente em todo o sistema.

A testabilidade de software é a facilidade com que o programa pode ser testado. Existem métricas que podem medir a testabilidade do software.

Quando o software para computador é considerado, teste caixa-preta refere-se a testes que são conduzidos na interface do software.

Um teste de caixa-branca é baseado num exame rigoroso do detalhe procedimental.

Caminhos lógicos internos do software são testados, definindo casos de testes que exercitam conjuntos específicos de condições ou ciclos. Teste caixa-branca completoé impossível para grandes sistemas de software. Um teste caixa-branca não deve, no entanto, ser descartado como não prático. Um número limitado de caminhos lógicos importantes pode ser selecionado e exercitado.

Há três motivos importantes pelos quais se deve usar testes caixa-branca:

• Os erros tendem a ocorrer em condições ou controle que estão