SISTEMA DE ENSINO PRESENCIAL CONECTADO ANÁLISE DE DESENVOLVIMENTO DE SISTEMAS

ALEXSANDER BAIAROSKI GONÇALVES

FUNDAMENTOS COMPUTACIONAIS

Corumbá

2012

ALEXSANDER BAIAROSKI GONÇALVES

FUNDAMENTOS COMPUTACIONAIS

Trabalho apresentado as disciplinas de Análise de Sistemas I, Engenharia de Software, Banco de Dados I, Linguagem e Tec. de Programação II e Seminários II da Universidade Norte do Paraná - UNOPAR

Prof(s). : Polyanna P. Gomes Fabris Roberto Y. Nishimura Luís Luis Cláudio Perini

Anderson Macedo

Corumbá

2012

SUMÁRIO

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

2 DESENVOLVIMENTO .........................................................................................6

2.1 PLANO DE DESENVOLVIMENTO...................................................................6

2.1.1 ENGENHARIA DE REQUISITOS ................................................................6

2.1.2 MODELOS DE PROCESSO DE SOFTWARE..............................................6

2.1.3 GERENCIAMENTO DE PROJETO DE SOFTWARE ...................................7

2.1.4 GESTÃO DO CONHECIMENTO ..................................................................7

2.1.5 MÉTRICAS DE QUALIDADE ........................................................................8

2.1.6 QUALIDADE DE SOFTWARE ......................................................................8

2.1.6.1 MODELO DE QUALIDADE - CMMI...........................................................9

3 REQUISITOS .....................................................................................................10

3.1 REQUISITOS FUNCIONAIS DO SISTEMA BIBLIOTECA .............................10

3.2 REQUISITOS NÃO FUNCIONAIS DO SISTEMA BIBLIOTECA.....................11

3.3 DIAGRAMA CASO DE USO...........................................................................11

4 PROJETO DE BANCO DE DADOS ...................................................................13

4.1.1 MODELAGEM CONCEITUAL.....................................................................13

4.1.1.1 DESCRIÇÃO DA TABELA DADOS_CLIENTE .......................................13

4.1.1.2 DESCRIÇÃO DA TABELA CADASTRA_LIVRO.....................................14

4.1.1.3 DESCRIÇÃO DA TABELA LOC_LIVRO ................................................14

4.1.2 MODELAGEM LÓGICA ..............................................................................15

5 PROTÓTIPOS DAS TELAS ...............................................................................17

5.1 PRIVILÉGIO DE ADMINISTRADOR ..............................................................18

5.2 PRIVILÉGIO DE CLIENTE COMUM .............................................................21

6 CONCLUSÃO ....................................................................................................23

REFERÊNCIAS .........................................................................................................24

1 INTRODUÇÃO

A utilização de softwares gerenciadores hoje já faz parte do cotidiano de muitas pessoas. Mesmo aquelas que pensam que nunca utilizaram um software, Internet, ou um computador, sem perceber se beneficiam dos avanços da informática e poderão sofrer as consequências de um erro, defeito ou falha de um software.

Atualmente, as fábricas de softwares atuam fortemente na qualidade de seus produtos onde a engenharia de software se foca.

"Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos". (BARTIÉ, 2002).

Este trabalho consiste em programar um SGBD ( sistema de gerenciador de banco de dados) para a informatização de uma locadora de livros. Levantado os parâmetros necessários, partiremos para a elaboração de um plano de desenvolvimento, ou seja, uma gama de conceitos e práticas da Engenharia de Software que atuam decisivamente na produção de software de qualidade.

2 DESENVOLVIMENTO

2.1 PLANO DE DESENVOLVIMENTO COM ÊNFASE NA QUALIDADE

A qualidade deve ser uma característica fundamental de qualquer produto existente. Porém, o seu desenvolvimento com a qualidade assegurada, dentro do prazo estabelecido e sem necessitar de mais recursos do que os alocados tem sido um grande desafio para a Engenharia de Software.

A seguir, estão relacionados os principais tópicos teóricos e práticos, que quando implementados garantem que o produto final atinja a excelência no desenvolvimento, ou seja, é a nossa visão de proposta ideal na construção de software de qualidade.

2.1.1 ENGENHARIA DE REQUISITOS

Os requisitos de sistema destinam-se a comunicar as funções que o sistema deve fornecer. É preciso entender e documentar de maneira clara e não ambígua os requisitos de um determinado problema, só assim, entenderemos de forma precisa o que deseja o cliente. Isto posto, poderemos começar a projetar e construir o sistema. Etapas do processo de engenharia de requisitos: concepção, levantamento, elaboração, negociação, especificação e validação.

2.1.2 MODELOS DE PROCESSO DE SOFTWARE

É essencial, antes do desenvolvimento de um produto, preparar um plano geral, ou seja, escolher um modelo de ciclo de vida. Este pode ser personalizado, se adaptando ao tamanho, complexidade e/ou

nível de confiabilidade/segurança do projeto, ou seja, um modelo para um processo de desenvolvimento é uma proposta teórica que junto com o planejamento deve determinar quais atividades devem ser realizadas, quando, como e por quem.

A escolha de um modelo envolve diversos fatores: se é um software

de banco de dados, um software de tempo-real, um software embutido, um sistema especialista.

Outros fatores importantes são: se a equipe de desenvolvimento é uma empresa de desenvolvimento (software house), uma fábrica de software (desenvolvimento em linha de produção) ou se é a equipe de engenheiros da própria organização que utilizará o produto. A maneira como o produto será vendido e

instalado também tem relevância: se o software é para ser vendido para um público amplo (software genérico) ou se será instalado em uma única empresa, sob encomenda.

São alguns exemplos de modelos de ciclo de vida: Prototipação, Espiral, Cascata, Extreme Programming, SCRUM, RUP.

2.1.3 GERENCIAMENTO DE PROJETO DE SOFTWARE

A gerência efetiva de projetos de softwares é a garantia de que o produto será entregue no prazo, dentro do custo e com os requisitos atendidos. Projeto é um processo único, consistido de um grupo de atividades controladas e coordenadas num determinado período. São algumas atividades do gerente de projetos: elaboração da proposta, planejamento e desenvolvimento do cronograma do projeto, custo do projeto, monitoramento e revisões do projeto, seleção e avaliação de pessoal e elaboração de relatórios e apresentações. O gerente também precisa planejar minuciosamente o progresso do projeto, prevendo problemas e dando soluções experimentais para esses problemas. O cronograma é uma das tarefas mais difíceis de serem executadas, pois os gerentes precisam estimar o tempo e os recursos para concluírem as atividades, organizando-as em uma seqüência coerente. A análise de riscos também deve fazer parte da rotina do gerente de projetos.

Algumas metodologias de gerência de projetos para auxiliar os profissionais: PDGA, PMBOX e SCRUM.

2.1.4 GESTÃO DO CONHECIMENTO

Problema enfrentado e solucionado, deve se transformar em conhecimento adquirido. Este conhecimento, deverá ser guardado de forma organizada e disseminado de maneira rápida e fácil quando necessário. Para isso, devemos nos preocupar com questões de treinamento e qualificação de pessoal,

resgate e transferência de conhecimentos dentro das organizações. Novos projetos têm suas atividades facilitadas com reuso de software, histórico de tarefas, estatísticas de erros e análise de indicadores. Ter acesso a estes dados é uma vantagem estratégica significativa para um gerente de projetos nas tomadas de decisões.

2.1.5 MÉTRICAS DE QUALIDADE

Para medirmos a qualidade de determinado processo ou produto, precisamos fazer uso de métricas de aferição, ou seja, meios para detectar áreas de problemas (internos), de forma que possam ser definidas soluções para que o processo seja melhorado. Essas medidas são coletadas pelos engenheiros de softwares e repassadas aos gerentes de softwares, que fazem as análises e avaliações. Métricas eliminam julgamentos subjetivos sobre o produto e dão à organização uma visão estratégica efetiva de seu processo de software.

2.1.6 QUALIDADE DE SOFTWARE

O gerenciamento de qualidade de software assegura que o mesmo tenha poucos defeitos e que atinja os padrões necessários de: funcionalidade, facilidade de manutenção, confiabilidade, portabilidade, usabilidade e eficiência. O engenheiro de software deve documentar um conjunto de procedimentos de garantia de qualidade em um manual de qualidade da organização.

Sendo assim, a busca constante pela qualidade não se faz apenas no começo do projeto ou no seu final realizando testes, mas sim e um processo que visa abranger toda a engenharia de software bem como a colaboração de todos os membros do time do projeto.

2.1.6.1 MODELO DE QUALIDADE - CMMI

Segundo os idealizadores do CMMI, a principalcausa dos problemas é a falta de um processo de desenvolvimento de software

claramente definido e efetivo. Conhecer os processos significa conhecer como os produtos e serviços são planejados, produzidos e entregues. O CMMI enfatiza a documentação dos processos, seguindo a premissa de que, para realizar alguma melhoria no processo é preciso primeiro conhecê-lo e entendê-lo, e que a qualidade de um produto é reflexo da qualidade e gerenciamento do processo utilizado em seu desenvolvimento.

Também pode ser considerado um conjunto de boas práticas para o desenvolvimento de projetos, produtos, serviços e integração de processos. Na prática, os processos, técnicas, ferramentas e métodos utilizados por uma organização serão influenciados pelos conceitos do CMMI.

O modelo CMMI é composto por cinco níveis de maturidade, utilizado na classificação das organizações. Cada nível de maturidade possui características bem distintas:

a) Nível 1 – Inicial: Processo de software caracterizado como “ad

hoc”. Poucos processos de desenvolvimento definidos e o sucesso depende de esforço individual.

b) Nível 2 – Repetível: As políticas de gerência de desenvolvimento de software são definidas e seguidas. É o nível mais difícil de alcançar por ser uma quebra de paradigma.

c) Nível 3 – Definido: O processo básico de software para as atividades de gestão e engenharia é documentado, padronizado e integrado em

um processo de software padrão para organização.

d) Nível 4 – Gerenciado: Medidas detalhadas do processo de software e da qualidade do produto são realizadas. O processo e os produtos de software e da qualidade do produto são quantitativamente compreendidos e controlados.

e) Nível 5 – Otimização: A melhoria continua do processo é proporcionada pelo feedback quantitativo do processo e pelas idéias e tecnologias inovadoras.

Vantagens na adoção do CMMI:

a) O desenvolvimento de software com qualidade, garantindo o cumprindo dos prazos e atendendo as necessidades do cliente, deixando mais satisfeito com o produto entregue pela empresa;

b) Eliminação de inconsistências e redução de duplicidade;

c) Utilização de terminologia comum e estilo consistente;

3 REQUISITOS

Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do cliente, e, em geral independem da tecnologia empregada na construção da solução sendo a parte mais crítica e

propensa a erros no desenvolvimento de software. São objetivos ou restrições estabelecidas por clientes e clientes do sistema que definem as diversas propriedades da solução. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.

Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não funcionais.

a) Funcionais: são a descrição das diversas funções que clientes e clientes querem ou precisam que o software faça. Eles definem a funcionalidade desejada do software. A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz.

b) Não funcionais: são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal. Descrevem as restrições de tempo, do processo de desenvolvimento, padrões e etc. Geralmente, são mais críticos do que os funcionais e se ignorados, podem transformar todo o sistema em algo inútil.

3.1 REQUISITOS FUNCIONAIS DO SISTEMA ‘LOCA LIVROS’

a) O sistema deve manter um cadastro de clientes;

b) O sistema deve prover e controlar a renovação da locação de forma on-line;

c) O sistema deve manter um cadastro de livros;

d) O sistema deve controlar e disparar avisos sobre prazos de devolução se esgotando a seus clientes;

e) O sistema deve controlar o número máximo permitido de livros emprestados por vez para cada cliente.

3.2 REQUISITOS NÃO FUNCIONAIS DO SISTEMA ‘LOCA LIVROS’

a) O cadastro de clientes deve ser simplificado com: nome, endereço, telefone, email e senha;

b) O sistema deve vetar locações em caso de atraso confirmado e avisar ao cliente que compareça à biblioteca para sanar as pendências do referido empréstimo;

c) O sistema deve limitar, para no máximo 4 (quatro) livros, os empréstimos por vez para cada cliente;

d) O sistema deverá comunicar ao cliente, via email, quando faltar

1 (um) dia para se esgotar o prazo de devolução;

e) O cadastro de livros deve contemplar de forma obrigatória a localização e a quantidade de exemplares por título.

3.3 DIAGRAMA CASO DE USO

O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema, que será projetado.

Cenário: O cliente chega à biblioteca e loca o livro de sua escolha. O funcionário verifica no sistema a disponibilidade do pedido e cadastra o cliente(caso o mesmo nunca tenha locado na loja) e confirma a locação dando baixa no estoque. O cliente de forma on-line, poderá efetuar a renovação do empréstimo segundo as regras impostas pelo sistema, bem como gerenciar suas pendências de empréstimos.

O funcionário também pode efetuar renovações e gerenciar pendências. O funcionário mantém o cadastro dos livros informando sempre a localização e o número de exemplares por títulos.

Atores: Cliente e funcionário.

Casos de uso: manter cadastro de cliente; manter cadastro de livro; controlar as locações; cadastrar localização do livro; cadastrar quantidade de volumes por título; gerenciar pendências de empréstimos.

[pic]

Figura 3 – Diagrama caso de uso – UML

4 PROJETO DE BANCO DE DADOS

Após levantamento dos requisitos, e com a estrutura definida, passaremos agora para a modelagem do nosso banco de dados.

4.1 MODELAGEM CONCEITUAL

Para o nosso modelo conceitual foram verificadas a necessidade de três tabelas (dados_cliente, cadastra_livro e loc_livro) e duas relações entre elas (cadastro e emprestimo).

Figura 4 – Modelo Conceitual

4.1.1.1 DESCRIÇÃO DA TABELA CLIENTE

Na tabela CLIENTE serão inseridos os campos para registros das informações dos clientes através dos seguintes campos:

a) Campo id_cliente: este é o campo principal da nossa tabela.

Será incluso um registro único para cada cliente cadastrado. b) Campo cpf_cliente: o cpf será unico para cada cliente.

c) Campo nome: onde conterá o nome do nosso cliente.

d) Campo endereco: registro do endereço do cliente.

e) Campo telefone: registro do telefone do cliente.

f) Campo email: registro do email do cliente.

g) Campo login: campo de registro único para cada usuario

h) Campo senha: registro da senha do cliente.

4.1.1.2 DESCRIÇÃO DA TABELA CADASTRA_LIVRO

Na tabela CADASTRA_LIVRO serão inseridos campos para o cadastro dos livros com suas principais informações. Os campos que serão utilizados para o cadastro de livros são: id_livro, valor,titulo,qnt e classificacao. Para os cadastros desta tabela, só é permitido cliente com privilégios de administrador.

São os campos da tabela livro:

a) Campo id_livro: identificará o livro através de um único registro

b) Campo valor: armazena o valor do livro para locação.

c) Campo titulo: armezena o nome da obra do livro;

d) Campo qnt: armazena a quantidade de livros com o mesmo titulo e autor.

e) Campo classificacao: armazena a informação do local onde o livro se encontra.

Note-se que até este momento não nos preocupamos em definir quais as características que os campos devem conter.

Outra observação é que no modelo conceitual já podemos definir a sua regra de negócio - cardinalidade, que em nosso caso é de n:n em ambas tabelas, ou seja muitos para muitos. Na tabela cliente serão cadastrados vários clientes com permissões definidas que poderão cadastrar ou locar “n” livros.

4.1.1.3 DESCRIÇÃO DA TABELA LOC_LIVRO

Nesta tabela, temos dois campos identificadores de outas tabelas, o campo id_livro_locado da tabela CADASTRA_LIVRO e o campo id_cliente da tabela CLIENTE.

É nesta tabela que vamos ter o controle dos empréstimos dos livros, pois poderemos identificar facilmente qual cliente fez o empréstimo do livro com o código desejado. Outras informações tanto do cliente quanto do livro estão alocados em suas tabelas de origem.

Outro campo desta tabela é data_emplivro, na qual está destinada a receber a informação da data do empréstimo ou da renovação.

4.1.2 MODELAGEM LÓGICA

Na modelagem lógica vamos dar início às regras que cada campo deve conter, onde definiremos as principais características, informando se o preenchimento é obrigatório ou nulo, numérico, alfanumérico, boleano, etc.

Nesse modelo, podemos compreender melhor a relação entre as tabelas CLIENTE, CADASTRA_LIVRO E LOC_LIVRO.

A relação CADASTRO e a relação LOCACAO, recebem duas chaves identificadoras, cpf_cliente da tabela CLIENTE e id_livro da tabela CADASTRA_LIVRO. Estas relações é que definem as ações dos clientes através do cpf_cliente, qual caminho tomar, se é para o cadastro ou somente para

empréstimo.

Figura 5 – Modelo Lógico

Os campos da tabela CLIENTE foram definidos da seguinte forma:

a) id_cliente: será do tipo numérico, com valor máximo de 11 digitos, com incremento automático e será a chave primária da nossa tabela;

b) nome: será do tipo alfanumérico, com no máximo 60 caracteres, com preenchimento obrigatório;

c) endereco: será do tipo alfanumérico, com no máximo 60 caracteres, com preenchimento obrigatório;

d) telefone: será do tipo alfanumerico, com no máximo 10 dígitos, com preenchimento obrigatório;

e) email: será do tipo alfanumérico, com no máximo 60 caracteres, com preenchimento obrigatório;

f) senha: será do tipo alfanumérico, com no máximo 20 caracteres,

com preenchimento obrigatório;

g) login: será do tipo alfanumérico, com no máximo 20 caracteres,

com preenchimento obrigatório e será unico;

h) cpf_cliente: será do tipo numérico, com no máximo 11 caracteres, com preenchimento obrigatório e será único;

h) nivel: será do tipo numérico, com no máximo 2 caracter, com preenchimento obrigatório;

forma:

Já os campos da tabela CADASTRA_LIVRO, foram definidas da seguinte

a) id_livro: será do tipo numérico, com valor máximo de 10 dígitos, com incremento automático e será a chave primária da nossa tabela.

b) classificacao: será do tipo alfanumérico, com no máximo 20 caracteres, com preenchimento obrigatório

c) qnt: será do tipo numérico, com no máximo 10 dígitos, com preenchimento obrigatório.

d) valor: será do tipo numérico, com no máximo 10 caracteres, com preenchimento obrigatório.

e) autor: será do tipo alfanumérico, com no máximo 60 caracteres, com preenchimento obrigatório.

f) titulo: será do tipo alfanumérico, com no máximo 60 caracteres, com preenchimento obrigatório.

E finalmente para a tabela LOC_LIVRO:

a) id_locacao: será do tipo numérico, com valor máximo de 10 dígitos, com incremento automático e será a chave primária da nossa tabela.

b) cpf_usuario: chave estrangeira importada da tabela CLIENTE

com todas as características.

c) dt_locacao: será do tipo date, com preenchimento obrigatório. Em caso de renovação, este campo será alterado para a data atual.

d) id_livro_locado: chave estrangeira importada da tabela CADASTRA_LIVRO do campo id_livro com todas as sua caracteristicas;

5 PROTÓTIPOS DAS TELAS

Passamos agora para o nosso modelo de site que irá interagir com o nosso banco de dados.

Nessa fase nos preocupamos principalmente em apresentar gráficos ao requisitante do software para fazer-se compreender a funcionalidade do sistema.

Na página de autenticação o cliente (figura 6) que já é cadastrado vai inserir suas credenciais, e o sistema verificará seu tipo de privilégio através do

NIVEL.

Figura 6 – Página de Autenticação

5.1 PRIVILÉGIO DE ADMINISTRADOR

No caso do cliente com privilégios de um administrador, este será redirecionado para a página de cadastro de livros (figura 7), onde terá outros links para interagir com o cadastro de novos clientes além de controlar empréstimos.

A tela CADASTRAR LIVROS será apresentada assim que o cliente- administrador informar seu login e senha. Os campos para o cadastro do livro que já foram explicados na modelagem conceitual e lógica são obrigatórios e quando é efetuado o cadastro de um livro a página continua a mesma dando oportunidade para um novo cadastro.

[pic]

Figura 7 – Página de cadastro de livros

No link Cadastrar Cliente, o administrador é redirecionado para uma

nova tela onde conterá novos campos para cadastros de um novo cliente.

[pic]

Figura 8 – Página de cadastro de cliente

Assim como no processo de cadastro do livro, quando inserido um novo cliente, a página continua a mesma, informando através de uma mensagem na tela que o cadastro foi efetuado com sucesso.

No link Controlar Empréstimos o administrador informará o CPF do cliente que pretende gerenciar e na mesma tela retornará as informações dos

clientes junto com os livros que foram emprestados por este.

[pic]

Figura 9 – Página para consultar situação de cliente

[pic]

Figura 10 – Página de controle de empréstimos

No caso de livros com empréstimos vencidos, o sistema acusará qual o livro e quantos dias o empréstimo expirou.

5.2 PRIVILÉGIO DE CLIENTE COMUM

Por padrão, o nosso sistema tem o administrador e o cliente comum. O administrador tem permissão para cadastrar e gerenciar livros e clientes.

No caso do cliente comum que foi cadastrado pelo administrador do sistema, terá acesso a página de autenticação em comum com o administrador, mas o sistema se encarregará de redirecioná-lo para a página de empréstimos de livros

onde através do campo pesquisa o cliente escolherá o livro que procura.

[pic]

Figura 11 – Página de consulta de livros e locações realizadas

Caso o cliente deixe os campos em branco o sistema apenas mostrará sua situação junto a locadora de livros.

Em nosso exemplo mostramos que o cliente já fez 2 cadastros de livros e que um deles expira em 2 dias(imagem 12).

[pic]

Figura 12 –Busca do livro solicitado e os historicos do cliente

Quando o cliente estiver com algum empréstimo vencido, o sistema lhe apresenta o livro que está expirado e não permite a renovação do mesmo.

Para uma renovação do empréstimo, o cliente terá que comparecer a biblioteca para renová-lo.

6 CONCLUSÃO

Definitivamente, o uso da Engenharia de Software é uma tarefa complexa e extensa, com abundância de métodos, que tornam sua utilização uma atividade para especialistas.

A crescente importância e massificaçãoda computação na sociedade moderna têm aumentado o significado do conceito de qualidade de software. Assim, o desenvolvimento de softwares é hoje uma tarefa fundamental e, em muitos casos, de missão crítica.

Para a construção de softwares de qualidade, uma série de etapas precisamser seguidas. Sistemas demandam vários passos para oseu desenvolvimento, com uma detalhada análise de requisitos, escolha de um

modelo adequado, hardware e software para o auxílio do desenvolvimento e projetos bem definidos para que tudo, em conjunto, produza um software de qualidade, confiável e, assim, obtenha sucesso.

Vimos também, que os bancos de dados são de suma importância nos grandes projetos de software e envolvem uma análise bem aprofundada sobre o problema, mas inegavelmente, conferem ao mundo da computação o legado da informação precisa, rápida e inteligente.

O intuito deste trabalho foi mostrar a todos a importância de utilizarmos os conceitos e práticas da Engenharia de Software e todas as práticas das demais disciplinas, como elas podem ser decisivas no árduo e complexo universo de desenvolvimento de sistemas, enfatizando a melhoria da qualidade dos processos e produtos gerados, com o objetivo final de melhorar a qualidade do software desenvolvido e agregar facilidades para os clientes cada vez mais ávidos por tecnologia da informação.

REFERÊNCIAS

PERINI, Luis Cláudio. Engenharia de Software: sistemas II / Luis Cáudio Perini, Marco Ikuro Hisatomi, Wagner Luiz Berto: São Paulo: Pearson Prentice Hall, 2009.

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman,

2008.

NISHIMURA, Roberto Yukio. Banco de Dados I: sistemas II. São Paulo: Pearson

Prentice Hall, 2009.

FLORES, Emerson Ricardo. Linguagens e Técnicas de Programação II - Análise e

Desenvolvimento de Sistemas 2. São Paulo: Pearson Prentice Hall, 2009.

MACORATTI, José Carlos http://www.macoratti.net

André Koscianski e Michel dos Santos Soares http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/241804.pdf

Banas Qualidade http://www.asrconsultoria.com.br/downloads/pdf/A%20importancia%20da%20qualida de%20no%20desenvolvimento%20de%20software.pdf

-----------------------

[pic]

[pic]

[pic]

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? Validação: Estamos construindo o produto certo?”. Wallin (2002) diz

que o “propósito da verificação é garantir que o componente de software ou sistemas baseados nele cumpra suas especificações” e que o “propósito da validação é demonstrar que um componente de software ou um sistema customizado atinja o uso desejado em um ambiente desejado”. Pode-se notar que as definições acerca de Verificação e Validação são semelhantes e servem ao mesmo propósito, mas a V&V pode ser executada de diversas maneiras dependendo do campo de pesquisa. Ramos et al.(1999) usa ferramentas de verificação baseados em métodos formais para detectar anomalias em bases de conhecimento de Sistemas Inteligentes. Wallin (2002)faz uso de técnicas de Inspeções de Software e Testes de Caixa Branca e Caixa Preta em sistemas comerciais. Pressman ressalta que:

[...] há uma forte divergência de opinião sobre que tipos de teste constituem validação. Algumas pessoas acreditam que todo teste é verificação e que validação é conduzida quando requisitos são revisados e aprovados, e posteriormente, pelo usuário, quando o sistema estiver operacional. Outras pessoas consideram teste unitário e de integração como verificação e testes de alta ordem como validação (PRESSMAN, 2006).

John e Steve (2000) destacam, em um estudo de caso realizado na Administração Nacional de Aeronáutica e Espaço Norte Americana (NASA),que o uso de V&V é um dos fatores para garantir a qualidade de software em sistemas desenvolvidos por meio do Desenvolvimento de Aplicações Rápidas(RAD). A questão é usufruir das vantagens desse desenvolvimento, como aalta produtividade e o baixo custo, sem que os problemas levantados no estudo comprometam tais vantagens. Neste caso, a V&V fornece análises úteis ao grupo de projeto em uma contínua tarefa para monitorar a co-evolução das ferramentas CASE usadas e analisa os diferentes

códigos gerados de acordo com a versão das ferramentas. Pode-se citar também o uso de V&V em Wallin (2002), o qual ressalta o sucesso e as vantagens do desenvolvimento de softwares baseado em componentes e diz que esta tecnologia requer, entre outras coisas, que o componente usado tenha alta funcionalidade, qualidade e que seja bem documentado, o que é obtido por organizações de software maduras com alta qualidade, fazendo uso de um processo que previnam problemas por meio da Verificação & Validação.A V&V pode se relacionar com o processo de desenvolvimento de diversas maneiras. A literatura trata essa forma de relacionamento como paradigma. Cada paradigma dita quais atividades e em que momento elas serão aplicadas. A especificação dos documentos ou artefatos de entrada e a apresentação dos resultados também são definidas. A Figura 3.1 mostra o paradigma de V&V apresentado pelo Manual de Engenharia de Sistemas (NAS, 2006) e sumariza as atividades de V&V da seguinte forma:1. Os Documentos de requisitos do sistema alimentam a validação.Durante as atividades de validação, uma tabela de validação é criada.2. Com os requisitos validados, a Tabela de Validação torna-se a base para as atividades de Verificação. Nesse momento as atividades deplanejamento da Verificação são iniciadas e o documento chamado dePlanos de Verificação Principal (MVP) é criado e será atualizada durantetodo o ciclo de desenvolvimento.3. As técnicas de verificação são especificadas para analisar cada requisitodescrito na Tabela de Validação. Neste momento, um documentochamado Matriz de Responsabilidade de Verificação é criado (VRTM).4. Depois que as atividades de verificação são concluídas, o VRTM éatualizado e o Documento de Cumprimento de Verificação dosRequisitos (RVCD) é criado para registrar a realização dos esforços deverificação.Figura 3.1 – Atividades de Verificação e Validação (Adaptada de NAS, 2006).Validação Requisitos do SistemaRequisitos do SistemaVerificaçãoPlanejamentoTécnicoDocumentodeRequisitosTabela deValidaçãoMVPVRTMDocumentodeRequisitosMVPValidaçãoEspecificaçãodaVerificaçãoVerificação123452Como mostra a Figura 3.2, o modelo proposto pelo Manual de Engenharia deSistemas aplica Verificação e Validação durante todo o processo dedesenvolvimento de software. Esse modelo propõe que a V&V seja aplicadaincrementalmente sob todos os requisitos durante o ciclo de desenvolvimento,seguindo a evolução natural e hierárquica da criação de software. Assim,quando cada incremento de requisitos é levantado e desenvolvido, eles sofremValidação e Verificação.Figura 3.2 – Diagrama em “V” da Engenharia de Sistemas (Adaptada de NAS, 2006).Ainda sobre a Figura 3.2, fica claro que o modelo proposto em NAS (2006) temdois momentos distintos na aplicação de V&V, onde a validação é aplicada àsfases iniciais e a verificação é aplicada no decorrer do ciclo dedesenvolvimento. Alguns autores como Sargent (2000) e Balci (1994) propõema aplicação de Validação em outras fases do desenvolvimento, criando umamaior evidência que o produto final está correto e que atende as necessidadesdo usuário. A Figura 3.3 mostra um paradigma clássico de V&V, onde fica claroque além da validação da especificação ou do modelo conceitual, existem asatividades de validação operacional e dos dados.53

Figura 3.3 – Modelo clássico de V&V (Adaptada de Sargent, 2000).Sargent (2000) descreve este modelo como: AEntidade Problema é umsistema (real ou proposto) de uma idéia, uma situação, uma política, ou umfenômeno a ser modelado; oModelo Conceitual é a representaçãomatemática/lógica/verbal da Entidade Problema desenvolvida por um estudoparticular; e oModelo Computacional é o Modelo Conceitual implementadoem um computador. O modelo conceitual é desenvolvido por meio de umaetapa deAnálise e Modelagem . O Modelo Computacional é desenvolvido como uso de um compilador na fase deImplementação . Logo, inferências sobre oproblema são obtidas por experimentos de computador aplicados ao ModeloComputacional na fase deExperimentos .Na Figura 3.3 pode-se notar que o Modelo Conceitual passa por uma fase deValidação.Na qual se assume que a conceitualização está correta e que omodelo representacional do problema está “razoável”3para o uso pretendido.Nota-se também que o Modelo Computacional passa pela fase deVerificação ,a qual garante que o programa de computador implementado está correto. NaValidação Operacional é definido como será garantido que o comportamento3Segundo Balci (1995), a exatidão dos resultados é julgada de acordo com os objetivos do estudo, porexemplo, em alguns casos 60% de exatidão é suficiente, em outros casos são exigidos 95%.EntidadeProblemaModeloComputacionalModeloConceitualValidaçãodo ModeloConceitualValidadede DadosValidaçãoOperacionalVerificação doModeloComputacionalImplementaçãoExperimentaçãoAnálise eModelagem54das saídas do modelo terá a exatidão desejada. É neste ponto onde muitos dostestes de validação ocorrem, sendo possível encontrar diferenças e apurar emquais das etapas do modelo apresentam falhas. NaValidade dos Dados édefinido como garantir que os dados necessários para a construção e avaliaçãodo software são adequados e corretos. É importante ressaltar que esseparadigma, apresentado na Figura 3.3, é aplicado durante todo o ciclo dedesenvolvimento de forma iterativa. Várias versões de softwares são criadas emelhoradas até que se obtenha um produto que satisfaça a exatidãopretendida.Os paradigmas apresentados por NAS (2006) e Sargent (2001)

mostrampontos em comuns e algumas dissonâncias. Este fato é comum entre osdiversos paradigmas e pode ser percebido em outros trabalhos como Bankset al.(1988) e Knepell e Arangno (1993). Mas, independente das diferenças,todos os paradigmas exigem que uma equipe de profissionais conduza asatividades de verificação e validação.Sargent (2001) aponta quatro formas diferentes ao se aplicar V&V em relação àequipe envolvida:1. A própria equipe de desenvolvimento toma as decisões de como osoftware é válido. Estas decisões são subjetivas e feitas baseadas nosresultados de vários testes e avaliações conduzidas como parte do processo de desenvolvimento do modelo.2. Outro método é ter os usuários do modelo fortemente envolvidos com otime de desenvolvimento para determinar a validade do modelo desimulação. Neste método, o foco de quem determina a validade dosoftware deve mudar dos desenvolvedores para os usuários, melhorando assim a credibilidade.3. O próximo método é conhecido como Verificação e Validação Independente (IV&V), onde uma empresa ou equipe independente dos desenvolvedores e dos usuários do software irão validá-lo. Este é um método aplicado quando existem várias equipes de desenvolvimento envolvidas no projeto e com desenvolvimento de sistemas em larga escala. É importante ressaltar que este método envolve um custoelevado e que pode ser feito de duas maneiras: de modo concorrente com o desenvolvimento do projeto ou quando o projeto estiver implementado ou concluído.4. O Modelo de Pontos é o último método apresentado por Sargent paradeterminar se um modelo é válido. Pontos (ou pesos) são determinados subjetivamente sobre as questões referentes ao processo de validação. Um modelo de sistema é considerado válido se o total geral dos pontos adquiridos de acordo com cada questão ultrapassarem a nota mínima, mas, segundo o próprio Sargent, este método é raramente utilizado na prática.

ACKERMAN, A., BUCHWALD, L., LEWSKI, F., Software Inspections: AnEffective Verification Process, IEEE Software, Vol. 6 No. 3 p. 31-37, 1989.ASTELS D., MILLER G., NOVAK M., eXtreme Programming: Guia prático,Campus, Rio de Janeiro, 2002.AMARAL, E.A.G. Empacotamento de Experimentos em Engenharia deSoftware, Dissertação de Mestrado, Programa de Engenharia de Sistemas eComputação – COOPE/RJ, 2003.BALCI Osman. Validation, Verification, and Testing Techniques throughout theLife Cycle of a Simulation Study. Proceedings of the 26 th Winter SimulationConference, Blacksburg, Virginia. p 215-220, 1994BALCI Osman. Principles and Techniques of Simulation Validation, Verification,and Testing. Proceedings of the 27 th Winter Simulation Conference, Arlington,Virginia. p 147-154, 1995.BARCELOS, R.F., TRAVASSOS, G.H., Avaliando documentos arquiteturaisatravés de um checklist baseado em atributos de qualidade. In proceedings ofWorkshop de Teses e Dissertações de Engenharia de Software (WTES) –SBES, Uberlância, MG, 2005.BANKS, J., GERSTEIN, D., SEARLES, S. P., Modeling processes, validation,and verification of complex simulations: A survey, Methodology and Validation,Simulations Series, vol. 19 No. 1. The Society of Computer Simulation, 13 – 18,1988BECK K., Extreme Programming Explained. Boston, MA: Addison-Wesley,2000.

123

BIFFL, S., GROSSMANN, W., 2001, Evaluating the accuracy of objectiveestimation models based on inspection data from multiple inspeciont cycles.ACM/IEEE ICSE, Toronto, Canada, IEEE Comp. Soc. Press, 2001.BOEHM B., Software Engineering Economics, 1st edition. Prentice-Hall, 1981.BORGES E.P., PAULA, W.P. Um modelo de medição para processos dedesenvolvimento de software, SIMPROS, 2003.EJIOGU, Lem O. Five principles for the formal validation of models of softwaremetrics. ACM SIGPLAN Notices, vol 28, No 8, 1993.CHMURA, L. J., WICINSKI, T. J., and NORCIO, A. F. Evaluating softwaredesign processes by analyzing change data over time. IEEE Transactions onSoftware Engineering. vol. 16, p. 729–740, 1990COOK, Jonathan E., WOLF, Alexander L. Software Validation: QuantitativelyMeasuring the Correspondence of a Process to a Model. ACM Transactions onSoftware Engineering and Methodology. vol 8 No 2, p. 147-176,1999.COOK, C., VISCONTI, M. Issues in Software Process Assessment andValidation. Proceedings 21st ACM Computer Science Conference, IndianapolisIN, 1993.FAGAN, M.E. Design and code inspection to reduce Errors in ProgramDevelopment, IBM Systems Journal, v. 15, n. 3, pp 182-211,1976FERREIRA, B.; MOITA, G. F. Avaliação de técnicas para validação emprocessos de desenvolvimento de software. In: VIII Simpósio de MecânicaComputacional, Belo Horizonte: PUC MInas,. vol. 1. p. 1-15, 2008 aFERREIRA, B.; MOITA, G. F.The evaluation of different validation techniquesfor software development process. In: 8th World Congress on Computational

124Mechanics WCCM8, Veneza. Proceedings of the 8th World Congress onComputational Mechanics, v. 1. p. 1-2, 2008 b.FGV, Site da Fundação Getúlio Vargas acessado em 25/08/2008http://www.fgv.br/fgvportal/principal/idx_materia.asp?str_chave=11269&sessao=2,2008GARG, P. K., Process Modeling of Software Reuse, 1992. In Proceedings ofthe 5th International Workshop on Institutionalizing Software Reuse, Palo Alto.GILB, T., GRAHAM, D. Software Inspecion. Addison-Wesley, 1993.HUMPHREY, W. S. A Discipline for Software Engineering. Addison-Wesley.Reading-MA, 1995.IEEE, IEEE Recommended Practice for Software Requirements Specifications – Description, Standart 830, IEEE Press. 1998.JACOBSON, I.; RUMBAUGH, J.; BOOCH, G. The Unified SoftwareDevelopment Process. Addison-Wesley, Reading – MA, 1999.JOHN R. C., STEVE M. E. Verification and Validation in a Rapid SoftwareDevelopment Process, NASA Software IV&V Facility, 2000.JOHNSON, P. An Instrumented Approach to Improving Software Qualitythrough Formal Technical Review, in proc. 16thInternational Conference onSotware Engineering, Sorrento, Italy, 1994.KNEPELL, P. L., ARANGNO, D. C., Simulation validation: A confidenceassessment methodology, IEEE Computer Society Simulation, 1993.KALINOWSKI, M. Infra-Estrutura Computacional de Apoio ao Processo deInspeção de Software, Dissertação de Mestrado, Programa de Engenharia deSistemas e Computação – COPPE/UFRJ, Rio de Janeiro, 2004

125KRUSKAL, J. B. An overview of sequence comparison. In Time Warps, StringEdits, and Macromolecules: The Theory and Practice of Sequence Comparison.In Proceedings of SIAM 1983 -

Society for Industrial and Applied Mathematics.vol 25 No 2 p 201-237, 1983.LAITENBERGER, O., ATKINSON, C. Generalized Perspective BasedInspection to handle Object Oriented Development Artifacts, Proccedings ofICSE 99, p. 494-503., 1998LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projetoorientado a objetos e ao Processo Unificado. Trad. Luiz Augusto MeirellesSalgado e João Tortello. 2 ed. Porto Alegre: Bookman, 2004.LANUBILE, F., MALLARDO, T., CALEFATO, F., Tool support forGeographically Dispersed Inspection Teams, Software Process Improvementand Practice, Vol. 8: p.217-231 (DOI: 10.1002/spip.184)., 2003.MELLO, A.M.V. Processo de Desenvolvimento de Software: Uma abordagempara Melhoria Contínua da Qualidade.2004. Disponível emhttp://santafe.ipt.br/tede/tde_busca/arquivo.php?codArquivo=226Acesso em: 28de julho de 2008.MOOR, A., DELUGACH H. Software Process Validation: Comparing Processand Practice Models. In Contributions to ICCS 2005, Kassel, Germany. p 533-540, 2005NAS - System Engineering Manual – versão 3.1 fonte:http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/operations/sysengsaf/seman/SEM3.1/Section%204.14%20v3.pdf acessado em30/03/2008, 2006OBERKAMPF, W.L., TRUCANO, T.G., Verification and validation benchmarks,Nuclear Eng. Design, Validation and Uncertainty Estimation Department,Sandia National Laboratories, vol 238 p. 716-743, 2007.

126PAULA, W. P. Engenharia de Software – Fundamentos, Métodos e Padrões. 2ªed. LTC Editora. Rio de Janeiro - RJ, 2003.PEREIRA Jr, M. Concepção de um Processo Específico para SoftwareCientífico. Dissertação de Mestrado. Centro Federal de Educação Tecnológicade Minas Gerais – CEFET-MG. Belo Horizonte, 2007.PERRY, William. Effective Methods for Software Testing. John Wiley & Sons,1995.PRESSMAN, R. S. Engenharia de Software. 6ª ed. Rio de Janeiro: McGraw-Hill, 2006.PURRI, M. C. M. S; PEREIRA Jr, M.,; MOITA, G. F. PESC – Processo deDesenvolvimento Específico para Software Científico: Propostas Iniciais. XXVIICILAMCE – Iberian Latin American Congress on Computational Methods inEngineering Belém-PA, 2006PURRI, M. C. M. S. Estudo e Propostas Iniciais para a Definição de umProcesso de Desenvolvimento para Software Científico. Dissertação deMestrado. Centro Federal de Educação Tecnológica de Minas Gerais –CEFET-MG. Belo Horizonte, 2006.RAMOS, C., ZITA A., VALE, L., SANTOS, J., Aplicações Inteligentes emCentros de Controlo: Verificação e Validação, Jornadas Luso-Espanholas deEngenharia Electrotécnica, Salamanca, Spain, July 1997SARGENT, Robert G., Verification, Validation, and Acreditation of SimulationsModel, Proc. Of the 2000 Winter Simulation Conference. p. 50-59, 2000SARGENT, Robert G., Some Approaches and Paradigms for Verification andValidation Simulations Model, Proc. Of the 2001 Winter Simulation Conference.p. 50-59, 2001.

127SAUER, C., JEFFERY, D.R., LAND, L., YETTON, P. The Effectiveness ofSoftware Development Technical Review: A Behaviorally Motivated Program ofResearch, IEEE Transactions on Software Engineering 26, 1-14, 2000.SHULL, F. Developing Techniques for Using Software Documents: A Series ofEmpirical Studies, Ph.D. thesis, University of Maryland, College Park, 1998.SOMMERVILLE, I., Engenharia de

Software. 8ª ed. São Paulo: AddisonWesley, 2007.SVAHNBERG, M., A study on agreement between participants in anarchitecture assessment. In proceedings of the International Symposium onEmpirical Software Enginneering – ISESE, p 61-70, 2003.TRAVASSOS G. H., KALINOWSKI, M, SPÍNOLA R. O., Introdução à Inspeçãode Software – Aumento da qualidade através de verificações intermediárias,Engenharia de Software Magazine, Ano 1, 1ª edição, 2007.TICHY, W.F. Should Computer Scientists Experiment More? IEEE Software,Vol. 31, No. 5, p. 32-39, 1998.WALLIN, C. Verification and Validation of Software Components andComponents Based Software Systems. - Based Software Systems. ArtechHouse Publishers, 2002. fonte: http://www.idt.mdh.se/cbse-book/extended-reports/05_Extended_Report.pdf acessado em 01/11/2007.WHEELER, D.A., BRYKEZYNSKI, B., MEESON, R.N., Software Inspetion: NaInsdustry Best Practice, IEEE Computer Society, 1996.WOHLIN, C., RUNESON, P., HOST, M. OHLSSON, M.C., REGNELL, B.,WESSLEN, A. Experimentation in Software Engineering: an Introduction, 2000.WIKIPEDIA A enciclopédia livre. Disponível em: http://www.wikipedia.com.br.Acessado em 05/06/2008.

128