Portfolio Individual 2 Semestre ADS

Sumário

1. Introdução 4

2. OBJETIVO 4

3. DESENVOLVIMENTO 4

3.1 Faça uma breve pesquisa nos livros indicados na biblioteca básica no plano de ensino e em seguida discorra sobre: 4

3.1.1 O Processo de inspeção de software 4

3.1.2 Verificação e Validação 5

3.1.3 Testabilidade de software 6

3.2 SGBD (sistema gerenciador de banco de dados) RECOMENDADO 7

3.3 Linguagem de programação RECOMENDADA para o uso com o SGBD PostgreSQL. 8

3.4 Modelo de Processo PROPOSTO 8

4. Conclusão 9

5. Referencias Bibliográficas 10

1. Introdução

Esse trabalho busca formar as bases para um sistema gerenciador de banco de dados SGBD, e todas as suas interações com a empresa denominada Locadora de Livros, bem como a escolha de um modelo de desenvolvimento de software e uma linguagem de programação para o uso com o SGBD. Visa o desenvolvimento de um sistema que controle a Locadora, seus usuários, estoque de livros, sistema financeiro dentre outras funções.

2. OBJETIVO

Compreender e buscar qual o melhor SGBD, Linguagem de programação e Modelo de desenvolvimento, para que com essa escolha eu traga para o meu cliente o melhor sistema, oferecendo alta performance com um ótimo custo x beneficio.

3. DESENVOLVIMENTO

3.1 Faça uma breve pesquisa nos livros indicados na biblioteca básica no plano de ensino e em seguida discorra sobre:

3.1.1 O Processo de inspeção de software

O processo de inspeção de software foi definido originalmente por Michael E. Fagan, em 1972, na IBM, Kingston, NY (FAGAN, 1986). Este processo consiste na subdivisão de uma tarefa em diversas atividades relacionadas com a transformação das informações de entrada em informações de saída, de forma organizada e que possa ser repetida (NUSEIBEH, 2002).

Esse processo é largamente utilizado e serve como base para vários outros processos de inspeções propostos. Neste processo, existem seis atividades principais:

• Planejamento. Determina se os materiais que serão inspecionados são satisfatórios, organiza as pessoas que irão participar da inspeção e o local onde serão realizadas as sessões de inspeção.

• Visão Geral. Inclui a apresentação do material a ser inspecionado aos participantes e a atribuição de funções a cada participante durante a inspeção.

• Preparação. Nesta etapa, os participantes são treinados para executarem as funções que lhes foram atribuídas, visando encontrar os defeitos constantes do produto ou artefato de software.

• Realização da Inspeção. Inclui sessões de trabalho, nas quais os participantes analisam o produto ou artefato de software enfocado, com o fim de detectar os defeitos existentes nesses produtos.

• Retrabalho. Nesta etapa, os defeitos detectados, devidamente documentados, são encaminhados ao autor do produto que foi inspecionado, para que seja providenciada a remoção destes defeitos.

• Revisão. Finalmente, o autor confere o produto revisado, juntamente com a equipe de inspeção, para assegurar-se de que todas as correções necessárias foram realizadas e que nenhum defeito novo foi introduzido.

3.1.2 Verificação e Validação

Softwares são amplamente utilizados para resolver problemas e tomar decisões. Os usuários passam a acreditar e a trabalhar nos resultados apresentados por eles. Para isto, o software deve ser construído atendendo às especificações do projeto e o produto final deve servir às necessidades reais do usuário. A Verificação e a Validação, ou simplesmente V&V, têm respectivamente estes interesses (Oberkampf e Trucano, 2007).Em uma definição formal, Pressman (2006) afirma que “Verificação se refere a um conjunto de atividades que garantem que o software implementa corretamente uma função específica e a Validação se refere a um conjunto de atividades diferentes que garante que o software construído corresponde aos requisitos do cliente”. Segundo o mesmo autor, a definição de V&V engloba muitas das atividades que são abrangidas pela Garantia da Qualidade de Software (SQA), como por exemplo: revisões técnicas formais, auditoria de qualidade e configuração, monitoramento de desempenho, estudo de viabilidade, revisão da documentação, entre outras.

Boehm (1981) faz a seguinte definição:

• Verificação:

- Estamos construindo certo o produto?

- O software deve estar de acordo com a sua especificação.

• Validação:

- Estamos construindo o produto certo?

- O software deve atender às necessidades dos usuários.

3.1.3 Testabilidade de software

A Testabilidade examina as diferentes probabilidades e características comportamentais que levam o código a falhar se alguma coisa estiver incorreta.

Um programa tem alta testabilidade se ele tende a expor suas falhas durante os testes com entradas que geram defeitos. Um programa tem baixa testabilidade se ele tende a ocultar as falhas detectadas durante os testes, produzindo saídas corretas para entradas que geram defeitos.

Requisitos incompletos, desatualizados, ambíguos ou contraditórios trazem baixa testabilidade. É muito difícil para um testador identificar problemas se não houver acesso a informações detalhadas sobre os critérios de teste.

É necessário ter um critério de teste para que a testabilidade passe a ser simplesmente “uma medida de quão difícil é satisfazer uma meta específica de teste”.

3.2 SGBD (sistema gerenciador de banco de dados) RECOMENDADO

Verificando todo o sistema a ser implementado na locadora de livros e levando todos os pormenores em conta, recomendei ao proprietário Sr. João Carlos o uso do