SISTEMA DE ENSINO PRESENCIAL CONECTADO ANLISE DE DESENVOLVIMENTO DE SISTEMAS

ALEXSANDER BAIAROSKI GONALVES

FUNDAMENTOS COMPUTACIONAIS

Corumb 2012

ALEXSANDER BAIAROSKI GONALVES

FUNDAMENTOS COMPUTACIONAIS

Trabalho apresentado as disciplinas de Anlise de Sistemas I, Engenharia de Software, Banco de Dados I, Linguagem e Tec. de Programao II e Seminrios II da Universidade Norte do Paran - UNOPAR

Prof(s). : Luis Cludio Perini

Polyanna P. Gomes Fabris Roberto Y. Nishimura Lus

Anderson Macedo

Corumb 2012

SUMRIO

INTRODUO .....................................................................................................5

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 GESTO DO CONHECIMENTO ..................................................................7

2.1.5 MTRICAS DE QUALIDADE ........................................................................8

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

2.1.6.1

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

REQUISITOS .....................................................................................................10

3.1

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

3.2

REQUISITOS NO FUNCIONAIS DO SISTEMA BIBLIOTECA.....................11

3.3

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

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

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

4.1.1.1

DESCRIO DA TABELA DADOS_CLIENTE .......................................13

4.1.1.2

DESCRIO DA TABELA CADASTRA_LIVRO.....................................14

4.1.1.3

DESCRIO DA TABELA LOC_LIVRO ................................................14

4.1.2 MODELAGEM LGICA ..............................................................................15

PROTTIPOS DAS TELAS ...............................................................................17

5.1

PRIVILGIO DE ADMINISTRADOR ..............................................................18

5.2

PRIVILGIO DE CLIENTE COMUM .............................................................21

CONCLUSO ....................................................................................................23

REFERNCIAS .........................................................................................................24

1 INTRODUO

A utilizao 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 avanos da informtica e podero sofrer as consequncias de um erro, defeito ou falha de um software.

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

"Qualidade de software um processo sistemtico 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 informatizao de uma locadora de livros. Levantado os parmetros necessrios, partiremos para a elaborao de um plano de desenvolvimento, ou seja, uma gama de conceitos e prticas da Engenharia de Software que atuam decisivamente na produo de software de qualidade.

2 DESENVOLVIMENTO

2.1 PLANO DE DESENVOLVIMENTO COM NFASE NA QUALIDADE

A qualidade deve ser uma caracterstica fundamental de qualquer produto existente. Porm, 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, esto relacionados os principais tpicos tericos e prticos, que quando implementados garantem que o produto final atinja a excelncia no desenvolvimento, ou seja, a nossa viso de proposta ideal na construo de software de qualidade.

2.1.1 ENGENHARIA DE REQUISITOS

Os requisitos de sistema destinam-se a comunicar as funes que o sistema deve fornecer. preciso entender e documentar de maneira clara e no ambgua os requisitos de um determinado problema, s assim, entenderemos de forma precisa o que deseja o cliente. Isto posto, poderemos comear a projetar e construir o sistema. Etapas do processo de engenharia de requisitos: concepo, levantamento, elaborao, negociao, especificao e validao.

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 nvel de confiabilidade/segurana do projeto, ou seja, um modelo para um processo de desenvolvimento uma proposta terica 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 so: se a equipe de desenvolvimento uma empresa de desenvolvimento (software house), uma fbrica de software (desenvolvimento em linha de produo) ou se a equipe de engenheiros da prpria organizao que utilizar o produto. A maneira como o produto ser vendido e

instalado tambm tem relevncia: se o software para ser vendido para um pblico amplo (software genrico) ou se ser instalado em uma nica empresa, sob encomenda. So alguns exemplos de modelos de ciclo de vida: Prototipao, Espiral, Cascata, Extreme Programming, SCRUM, RUP.

2.1.3 GERENCIAMENTO DE PROJETO DE SOFTWARE

A gerncia 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 perodo. So algumas atividades do gerente de projetos: elaborao da proposta, planejamento e desenvolvimento do cronograma do projeto, custo do projeto, monitoramento e revises do projeto, seleo e avaliao de pessoal e elaborao de relatrios e apresentaes. O gerente tambm precisa planejar minuciosamente o progresso do projeto, prevendo problemas e dando solues experimentais para esses problemas. O cronograma uma das tarefas mais difceis de serem executadas, pois os gerentes precisam estimar o tempo e os recursos para conclurem as atividades, organizando-as em uma seqncia coerente. A anlise de riscos tambm deve fazer parte da rotina do gerente de projetos. Algumas metodologias de gerncia de projetos para auxiliar os profissionais: PDGA, PMBOX e SCRUM.

2.1.4 GESTO DO CONHECIMENTO

Problema enfrentado e solucionado, deve se transformar em conhecimento adquirido. Este conhecimento, dever ser guardado de forma organizada e disseminado de maneira rpida e fcil quando necessrio. Para isso, devemos nos preocupar com questes de treinamento e qualificao de pessoal,

resgate e transferncia de conhecimentos dentro das organizaes. Novos projetos tm suas atividades facilitadas com reuso de software, histrico de tarefas, estatsticas de erros e anlise de indicadores. Ter acesso a estes dados uma vantagem estratgica significativa para um gerente de projetos nas tomadas de decises.

2.1.5 MTRICAS DE QUALIDADE

Para medirmos a qualidade de determinado processo ou produto, precisamos fazer uso de mtricas de aferio, ou seja, meios para detectar reas de problemas (internos), de forma que possam ser definidas solues para que o processo seja melhorado. Essas medidas so coletadas pelos engenheiros de softwares e repassadas aos gerentes de softwares, que fazem as anlises e avaliaes. Mtricas eliminam julgamentos subjetivos sobre o produto e do organizao uma viso estratgica 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 padres necessrios de: funcionalidade, facilidade de manuteno, confiabilidade, portabilidade, usabilidade e eficincia. O engenheiro de software deve documentar um conjunto de procedimentos de garantia de qualidade em um manual de qualidade da organizao.

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

2.1.6.1 MODELO DE QUALIDADE - CMMI

Segundo os idealizadores do CMMI, a principal causa dos problemas a falta de um processo de desenvolvimento de software claramente definido e efetivo. Conhecer os processos significa conhecer como os produtos e servios so planejados, produzidos e entregues. O CMMI enfatiza a documentao 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.

Tambm pode ser considerado um conjunto de boas prticas para o desenvolvimento de projetos, produtos, servios e integrao de processos. Na prtica, os processos, tcnicas, ferramentas e mtodos utilizados por uma organizao sero influenciados pelos conceitos do CMMI.

O modelo CMMI composto por cinco nveis de maturidade, utilizado na classificao das organizaes. Cada nvel de maturidade possui caractersticas bem distintas: a) Nvel 1 Inicial: Processo de software caracterizado como ad

hoc. Poucos processos de desenvolvimento definidos e o sucesso depende de esforo individual.

b) Nvel 2 Repetvel: As polticas de gerncia de desenvolvimento de software so definidas e seguidas. o nvel mais difcil de alcanar por ser uma quebra de paradigma. c) Nvel 3 Definido: O processo bsico de software para as atividades de gesto e engenharia documentado, padronizado e integrado em um processo de software padro para organizao. d) Nvel 4 Gerenciado: Medidas detalhadas do processo de software e da qualidade do produto so realizadas. O processo e os produtos de software e da qualidade do produto so quantitativamente compreendidos e controlados. e) Nvel 5 Otimizao: A melhoria continua do processo proporcionada pelo feedback quantitativo do processo e pelas idias e tecnologias inovadoras.

Vantagens na adoo 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) Eliminao de inconsistncias e reduo de duplicidade;

c)

Utilizao de terminologia comum e estilo consistente;

3 REQUISITOS

Os requisitos expressam as caractersticas e restries do produto de software do ponto de vista de satisfao das necessidades do cliente, e, em geral independem da tecnologia empregada na construo da soluo sendo a parte mais crtica e

propensa a erros no desenvolvimento de software. So objetivos ou restries estabelecidas por clientes e clientes do sistema que definem as diversas propriedades da soluo. Os requisitos de software so, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software. Tradicionalmente, os requisitos de software so separados em requisitos funcionais e no funcionais. a) Funcionais: so a descrio das diversas funes que clientes e clientes querem ou precisam que o software faa. Eles definem a funcionalidade desejada do software. A especificao de um requisito funcional deve determinar o que se espera que o software faa, sem a preocupao de como ele faz. b) No funcionais: so as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e vrias outras. Normalmente estes requisitos so descritos de maneira informal. Descrevem as restries de tempo, do processo de desenvolvimento, padres e etc. Geralmente, so mais crticos do que os funcionais e se ignorados, podem transformar todo o sistema em algo intil.

3.1 REQUISITOS FUNCIONAIS DO SISTEMA LOCA LIVROS

a)

O sistema deve manter um cadastro de clientes;

b) line; c)

O sistema deve prover e controlar a renovao da locao de forma onO sistema deve manter um cadastro de livros;

d) O sistema deve controlar e disparar avisos sobre prazos de devoluo se esgotando a seus clientes; e) O sistema deve controlar o nmero mximo permitido de livros emprestados por vez para cada cliente.

3.2 REQUISITOS NO FUNCIONAIS DO SISTEMA LOCA LIVROS

a) O cadastro de clientes deve ser simplificado com: nome, endereo, telefone, email e senha; b) O sistema deve vetar locaes em caso de atraso confirmado e avisar ao cliente que comparea biblioteca para sanar as pendncias do referido emprstimo; c) O sistema deve limitar, para no mximo 4 (quatro) livros, os emprstimos 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 devoluo;

e) O cadastro de livros deve contemplar de forma obrigatria a localizao e a quantidade de exemplares por ttulo.

3.3 DIAGRAMA CASO DE USO

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

Cenrio: O cliente chega biblioteca e loca o livro de sua escolha. O funcionrio verifica no sistema a disponibilidade do pedido e cadastra o cliente(caso o mesmo nunca tenha locado na loja) e confirma a locao dando baixa no estoque. O cliente de forma on-line, poder efetuar a renovao do emprstimo segundo as regras impostas pelo sistema, bem como gerenciar suas pendncias de emprstimos.

O funcionrio tambm pode efetuar renovaes e gerenciar pendncias. O funcionrio mantm o cadastro dos livros informando sempre a localizao e o nmero de exemplares por ttulos.

Atores: Cliente e funcionrio.

Casos de uso: manter cadastro de cliente; manter cadastro de livro; controlar as locaes; cadastrar localizao do livro; cadastrar quantidade de volumes por ttulo; gerenciar pendncias de emprstimos.

[pic]

Figura 3 Diagrama caso de uso UML

4 PROJETO DE BANCO DE DADOS

Aps 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 trs tabelas (dados_cliente, cadastra_livro e loc_livro) e duas relaes entre elas (cadastro e emprestimo).

Figura 4 Modelo Conceitual

4.1.1.1 DESCRIO DA TABELA CLIENTE

Na tabela CLIENTE sero inseridos os campos para registros das informaes dos clientes atravs dos seguintes campos:

a)

Campo id_cliente: este o campo principal da nossa tabela.

Ser incluso um registro nico para cada cliente cadastrado. b) cpf_cliente: o cpf ser unico para cada cliente. c) Campo nome: onde conter o nome do nosso cliente. d) e) f) Campo endereco: registro do endereo do cliente. Campo telefone: registro do telefone do cliente. Campo email: registro do email do cliente.

Campo

g) Campo login: campo de registro nico para cada usuario h) Campo senha: registro da senha do cliente.

4.1.1.2 DESCRIO DA TABELA CADASTRA_LIVRO

Na tabela CADASTRA_LIVRO sero inseridos campos para o cadastro dos livros com suas principais informaes. Os campos que sero utilizados para o cadastro de livros so: id_livro, valor,titulo,qnt e classificacao. Para os cadastros desta tabela, s permitido cliente com privilgios de administrador.

So os campos da tabela livro:

a) b)

Campo id_livro: identificar o livro atravs de um nico registro Campo valor: armazena o valor do livro para locao.

c) d) autor. e) encontra.

Campo titulo: armezena o nome da obra do livro; Campo qnt: armazena a quantidade de livros com o mesmo titulo e Campo classificacao: armazena a informao do local onde o livro se

Note-se que at este momento no nos preocupamos em definir quais as caractersticas que os campos devem conter. Outra observao que no modelo conceitual j podemos definir a sua regra de negcio - cardinalidade, que em nosso caso de n:n em ambas tabelas, ou seja muitos para muitos. Na tabela cliente sero cadastrados vrios clientes com permisses definidas que podero cadastrar ou locar n livros.

4.1.1.3 DESCRIO 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 emprstimos dos livros, pois poderemos identificar facilmente qual cliente fez o emprstimo do livro com o cdigo desejado. Outras informaes tanto do cliente quanto do livro esto alocados em suas tabelas de origem. Outro campo desta tabela data_emplivro, na qual est destinada a receber a informao da data do emprstimo ou da renovao.

4.1.2 MODELAGEM LGICA

Na modelagem lgica vamos dar incio s regras que cada campo deve conter, onde definiremos as principais caractersticas, informando se o preenchimento obrigatrio ou nulo, numrico, alfanumrico, boleano, etc. Nesse modelo, podemos compreender melhor a relao entre as tabelas CLIENTE, CADASTRA_LIVRO E LOC_LIVRO.

A relao CADASTRO e a relao LOCACAO, recebem duas chaves identificadoras, cpf_cliente da tabela CLIENTE e id_livro da tabela CADASTRA_LIVRO. Estas relaes que definem as aes dos clientes atravs do cpf_cliente, qual caminho tomar, se para o cadastro ou somente para emprstimo.

Figura 5 Modelo Lgico

Os campos da tabela CLIENTE foram definidos da seguinte forma:

a) id_cliente: ser do tipo numrico, com valor mximo de 11 digitos, com incremento automtico e ser a chave primria da nossa tabela; b) nome: ser do tipo alfanumrico, com no mximo 60 caracteres, com preenchimento obrigatrio; c) endereco: ser do tipo alfanumrico, com no mximo 60 caracteres, com preenchimento obrigatrio;

d) telefone: ser do tipo alfanumerico, com no mximo 10 dgitos, com preenchimento obrigatrio; e) email: ser do tipo alfanumrico, com no mximo 60 caracteres, com preenchimento obrigatrio; f) senha: ser do tipo alfanumrico, com no mximo 20 caracteres,

com preenchimento obrigatrio;

g)

login: ser do tipo alfanumrico, com no mximo 20 caracteres,

com preenchimento obrigatrio e ser unico;

h) cpf_cliente: ser do tipo numrico, com no mximo 11 caracteres, com preenchimento obrigatrio e ser nico;

h) nivel: ser do tipo numrico, com no mximo 2 preenchimento obrigatrio;

caracter, com

forma: J os campos da tabela CADASTRA_LIVRO, foram definidas da seguinte

a) id_livro: ser do tipo numrico, com valor mximo de 10 dgitos, com incremento automtico e ser a chave primria da nossa tabela. b) classificacao: ser do tipo alfanumrico, com no mximo 20 caracteres, com preenchimento obrigatrio c) qnt: ser do tipo numrico, com no mximo 10 dgitos, com preenchimento obrigatrio. d) valor: ser do tipo numrico, com no mximo 10 caracteres, com preenchimento obrigatrio. e) autor: ser do tipo alfanumrico, com no mximo 60 caracteres, com preenchimento obrigatrio. f) titulo: ser do tipo alfanumrico, com no mximo 60 caracteres, com preenchimento obrigatrio.

E finalmente para a tabela LOC_LIVRO:

a) id_locacao: ser do tipo numrico, com valor mximo de 10 dgitos, com incremento automtico e ser a chave primria da nossa tabela. b) cpf_usuario: chave estrangeira importada da tabela CLIENTE

com todas as caractersticas.

c) dt_locacao: ser do tipo date, com preenchimento obrigatrio. Em caso de renovao, 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 PROTTIPOS 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 grficos ao requisitante do software para fazer-se compreender a funcionalidade do sistema. Na pgina de autenticao o cliente (figura 6) que j cadastrado vai inserir suas credenciais, e o sistema verificar seu tipo de privilgio atravs do

NIVEL.

Figura 6 Pgina de Autenticao

5.1 PRIVILGIO DE ADMINISTRADOR

No caso do cliente com privilgios de um administrador, este ser redirecionado para a pgina de cadastro de livros (figura 7), onde ter outros links para interagir com o cadastro de novos clientes alm de controlar emprstimos. A tela CADASTRAR LIVROS ser apresentada assim que o clienteadministrador informar seu login e senha. Os campos para o cadastro do livro que j foram explicados na modelagem conceitual e lgica so obrigatrios e quando efetuado o cadastro de um livro a pgina continua a mesma dando oportunidade para um novo cadastro.

[pic]

Figura 7 Pgina 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 Pgina de cadastro de cliente

Assim como no processo de cadastro do livro, quando inserido um novo cliente, a pgina continua a mesma, informando atravs de uma mensagem na tela que o cadastro foi efetuado com sucesso.

No link Controlar Emprstimos o administrador informar o CPF do cliente que pretende gerenciar e na mesma tela retornar as informaes dos clientes junto com os livros que foram emprestados por este.

[pic]

Figura 9 Pgina para consultar situao de cliente

[pic]

Figura 10 Pgina de controle de emprstimos

No caso de livros com emprstimos vencidos, o sistema acusar qual o livro e quantos dias o emprstimo expirou.

5.2 PRIVILGIO DE CLIENTE COMUM

Por padro, o nosso sistema tem o administrador e o cliente comum. O administrador tem permisso para cadastrar e gerenciar livros e clientes. No caso do cliente comum que foi cadastrado pelo administrador do sistema, ter acesso a pgina de autenticao em comum com o administrador, mas o sistema se encarregar de redirecion-lo para a pgina de emprstimos de livros onde atravs do campo pesquisa o cliente escolher o livro que procura.

[pic]

Figura 11 Pgina de consulta de livros e locaes realizadas

Caso o cliente deixe os campos em branco o sistema apenas mostrar sua situao 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 emprstimo vencido, o sistema lhe apresenta o livro que est expirado e no permite a renovao do mesmo. Para uma renovao do emprstimo, o cliente ter que comparecer a biblioteca para renov-lo.

6 CONCLUSO

Definitivamente, o uso da Engenharia de Software uma tarefa complexa e extensa, com abundncia de mtodos, que tornam sua utilizao uma atividade para especialistas.

A crescente importncia e massificao da computao na sociedade moderna tm aumentado o significado do conceito de qualidade de software. Assim, o desenvolvimento de softwares hoje uma tarefa fundamental e, em muitos casos, de misso crtica.

Para a construo de softwares de qualidade, uma srie de etapas precisam ser seguidas. Sistemas demandam vrios passos para o seu desenvolvimento, com uma detalhada anlise de requisitos, escolha de um modelo adequado, hardware e software para o auxlio do desenvolvimento e projetos bem definidos para que tudo, em conjunto, produza um software de qualidade, confivel e, assim, obtenha sucesso.

Vimos tambm, que os bancos de dados so de suma importncia nos grandes projetos de software e envolvem uma anlise bem aprofundada sobre o problema, mas inegavelmente, conferem ao mundo da computao o legado da informao precisa, rpida e inteligente.

O intuito deste trabalho foi mostrar a todos a importncia de utilizarmos os conceitos e prticas da Engenharia de Software e todas as prticas 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 informao.

REFERNCIAS

PERINI, Luis Cludio. Engenharia de Software: sistemas II / Luis Cudio Perini, Marco Ikuro Hisatomi, Wagner Luiz Berto: So Paulo: Pearson Prentice Hall, 2009.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise 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. So Paulo: Pearson Prentice Hall, 2009.

FLORES, Emerson Ricardo. Linguagens e Tcnicas de Programao II - Anlise e Desenvolvimento de Sistemas 2. So 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 so amplamente utilizados para resolver problemas e tomar decises. Os usurios passam a acreditar e a trabalhar nos resultados apresentados por eles. Para isto, o software deve ser construdo atendendo s especificaes do projeto e o produto final deve servir s necessidades reais do usurio. A Verificao e a Validao, ou simplesmente V&V, tm respectivamente estes interesses (Oberkampf e Trucano, 2007).Em uma definio formal, Pressman (2006) afirma que Verificao se refere a um conjunto de atividades que garantem que o software implementa corretamente uma funo especfica e a Validao se refere a um conjunto de atividades diferentes que garante que o software construdo corresponde aos requisitos do cliente. Segundo o mesmo autor, a definio de V&V engloba muitas das atividades que so abrangidas pela Garantia da Qualidade de Software (SQA), como por exemplo: revises tcnicas formais, auditoria de qualidade e configurao, monitoramento de desempenho, estudo de viabilidade, reviso da documentao, entre outras. Boehm (1981) faz a seguinte definio. Verificao: Estamos construindo certo o produto? Validao: Estamos construindo o produto certo?. Wallin (2002) diz que o propsito da verificao garantir que o componente de software ou sistemas baseados nele cumpra suas especificaes e que o propsito da validao demonstrar que um componente de software ou um sistema customizado atinja o uso desejado em um ambiente desejado. Pode-se notar que as definies acerca de Verificao e Validao so semelhantes e servem ao mesmo propsito, mas a V&V pode ser executada de diversas maneiras dependendo do campo de pesquisa. Ramos et al. (1999) usa ferramentas de verificao baseados em mtodos formais para detectar anomalias em bases de conhecimento de Sistemas Inteligentes. Wallin (2002)faz uso de tcnicas de Inspees de Software e Testes de Caixa Branca e Caixa Preta em sistemas comerciais. Pressman ressalta que:
[...] h uma forte divergncia de opinio sobre que tipos de teste constituem validao. Algumas pessoas acreditam que todo teste verificao e que validao conduzida quando requisitos so revisados e aprovados, e posteriormente, pelo usurio, quando o sistema estiver operacional. Outras pessoas consideram teste unitrio e de integrao como verificao e testes de alta ordem como validao (PRESSMAN, 2006).

John e Steve (2000) destacam, em um estudo de caso realizado na Administrao Nacional de Aeronutica e Espao 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 Aplicaes Rpidas(RAD). A questo 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 anlises teis ao grupo de projeto em uma contnua tarefa para monitorar a co-evoluo das ferramentas CASE usadas e analisa os diferentes

cdigos gerados de acordo com a verso das ferramentas. Pode-se citar tambm 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 organizaes de software maduras com alta qualidade, fazendo uso de um processo que previnam problemas por meio da Verificao & Validao. 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 sero aplicadas. A especificao dos documentos ou artefatos de entrada e a apresentao dos resultados tambm so 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 validao.Durante as atividades de validao, uma tabela de validao criada.2. Com os requisitos validados, a Tabela de Validao torna-se a base para as atividades de Verificao. Nesse momento as atividades deplanejamento da Verificao so iniciadas e o documento chamado dePlanos de Verificao Principal (MVP) criado e ser atualizada durantetodo o ciclo de desenvolvimento.3. As tcnicas de verificao so especificadas para analisar cada requisitodescrito na Tabela de Validao. Neste momento, um documentochamado Matriz de Responsabilidade de Verificao criado (VRTM).4. Depois que as atividades de verificao so concludas, o VRTM atualizado e o Documento de Cumprimento de Verificao dosRequisitos (RVCD) criado para registrar a realizao dos esforos deverificao. Figura 3.1 Atividades de Verificao e Validao (Adaptada de NAS, 2006). Validao Requisitos do SistemaRequisitos do SistemaVerificaoPlanejamentoTcnicoDocumentodeRequisitosTabela deValidaoMVPVRTMDocumentodeRequisitosMVPValidaoEspecificaodaVerifica oVerificao1 234 52 Como mostra a Figura 3.2, o modelo proposto pelo Manual de Engenharia deSistemas aplica Verificao e Validao durante todo o processo dedesenvolvimento de software. Esse modelo prope que a V&V seja aplicadaincrementalmente sob todos os requisitos durante o ciclo de desenvolvimento,seguindo a evoluo natural e hierrquica da criao de software. Assim,quando cada incremento de requisitos levantado e desenvolvido, eles sofremValidao e Verificao. 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 aplicao de V&V, onde a validao aplicada sfases iniciais e a verificao aplicada no decorrer do ciclo dedesenvolvimento. Alguns autores como Sargent (2000) e Balci (1994) propema aplicao de Validao em outras fases do desenvolvimento, criando umamaior evidncia que o produto final est correto e que atende as necessidadesdo usurio. A Figura 3.3 mostra um paradigma clssico de V&V, onde fica claroque alm da validao da especificao ou do modelo conceitual, existem asatividades de validao operacional e dos dados. 53

Figura 3.3 Modelo clssico de V&V (Adaptada de Sargent, 2000). Sargent (2000) descreve este modelo como: A Entidade Problema umsistema (real ou proposto) de uma idia, uma situao, uma poltica, ou umfenmeno a ser modelado; o Modelo Conceitual a representaomatemtica/lgica/verbal da Entidade Problema desenvolvida por um estudoparticular; e o Modelo Computacional o Modelo Conceitual implementadoem um computador. O modelo conceitual desenvolvido por meio de umaetapa de Anlise e Modelagem . O Modelo Computacional desenvolvido como uso de um compilador na fase de Implementao . Logo, inferncias sobre oproblema so obtidas por experimentos de computador aplicados ao ModeloComputacional na fase de Experimentos .Na Figura 3.3 pode-se notar que o Modelo Conceitual passa por uma fase de Validao. Na qual se assume que a conceitualizao est correta e que omodelo representacional do problema est razovel 3 para o uso pretendido.Nota-se tambm que o Modelo Computacional passa pela fase de Verificao ,a qual garante que o programa de computador implementado est correto. Na Validao Operacional definido como ser garantido que o comportamento 3 Segundo Balci (1995), a exatido dos resultados julgada de acordo com os objetivos do estudo, porexemplo, em alguns casos 60% de exatido suficiente, em outros casos so exigidos 95%. EntidadeProblemaModeloComputacionalModeloConceitualValidaodo ModeloConceitualValidadede DadosValidaoOperacionalVerificao doModeloComputacionalImplementaoExperimentaoAnlise eModelagem 54 das sadas do modelo ter a exatido desejada. neste ponto onde muitos dostestes de validao ocorrem, sendo possvel encontrar diferenas e apurar emquais das etapas do modelo apresentam falhas. Na Validade dos Dados definido como garantir que os dados necessrios para a construo e avaliaodo software so adequados e corretos. importante ressaltar que esseparadigma, apresentado na Figura 3.3, aplicado durante todo o ciclo dedesenvolvimento de forma iterativa. Vrias verses de softwares so criadas emelhoradas at que se obtenha um produto que satisfaa a exatidopretendida.Os paradigmas apresentados por NAS (2006) e Sargent (2001)

mostrampontos em comuns e algumas dissonncias. Este fato comum entre osdiversos paradigmas e pode ser percebido em outros trabalhos como Banks et al. (1988) e Knepell e Arangno (1993). Mas, independente das diferenas,todos os paradigmas exigem que uma equipe de profissionais conduza asatividades de verificao e validao.Sargent (2001) aponta quatro formas diferentes ao se aplicar V&V em relao equipe envolvida:1. A prpria equipe de desenvolvimento toma as decises de como osoftware vlido. Estas decises so subjetivas e feitas baseadas nosresultados de vrios testes e avaliaes conduzidas como parte do processo de desenvolvimento do modelo.2. Outro mtodo ter os usurios do modelo fortemente envolvidos com otime de desenvolvimento para determinar a validade do modelo desimulao. Neste mtodo, o foco de quem determina a validade dosoftware deve mudar dos desenvolvedores para os usurios, melhorando assim a credibilidade.3. O prximo mtodo conhecido como Verificao e Validao Independente (IV&V), onde uma empresa ou equipe independente dos desenvolvedores e dos usurios do software iro valid-lo. Este um mtodo aplicado quando existem vrias equipes de desenvolvimento envolvidas no projeto e com desenvolvimento de sistemas em larga escala. importante ressaltar que este mtodo envolve um custo elevado e que pode ser feito de duas maneiras: de modo concorrente com o desenvolvimento do projeto ou quando o projeto estiver implementado ou concludo.4. O Modelo de Pontos o ltimo mtodo apresentado por Sargent paradeterminar se um modelo vlido. Pontos (ou pesos) so determinados subjetivamente sobre as questes referentes ao processo de validao. Um modelo de sistema considerado vlido se o total geral dos pontos adquiridos de acordo com cada questo ultrapassarem a nota mnima, mas, segundo o prprio Sargent, este mtodo raramente utilizado na prtica. 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 prtico,Campus, Rio de Janeiro, 2002.AMARAL, E.A.G. Empacotamento de Experimentos em Engenharia deSoftware, Dissertao de Mestrado, Programa de Engenharia de Sistemas eComputao 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 arquiteturaisatravs de um checklist baseado em atributos de qualidade. In proceedings ofWorkshop de Teses e Dissertaes de Engenharia de Software (WTES) SBES, Uberlncia, 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: AddisonWesley,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 medio 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. 729740, 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. Avaliao de tcnicas para validao emprocessos de desenvolvimento de software. In: VIII Simpsio de MecnicaComputacional, 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 124 Mechanics WCCM8, Veneza. Proceedings of the 8th World Congress onComputational Mechanics, v. 1. p. 1-2, 2008 b.FGV, Site da Fundao Getlio Vargas acessado em 25/08/2008 http://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. 16 th International 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 deInspeo de Software, Dissertao de Mestrado, Programa de Engenharia deSistemas e Computao COPPE/UFRJ, Rio de Janeiro, 2004 125 KRUSKAL, 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 Padres: uma introduo anlise e ao projetoorientado a objetos e ao Processo Unificado. Trad. Luiz Augusto MeirellesSalgado e Joo 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 Contnua da Qualidade.2004. Disponvel em http://santafe.ipt.br/tede/tde_busca/arquivo.php?codArquivo=226 Acesso 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 verso 3.1 fonte:http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/operatio ns/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. 126 PAULA, W. P. Engenharia de Software Fundamentos, Mtodos e Padres. 2ed. LTC Editora. Rio de Janeiro - RJ, 2003.PEREIRA Jr, M. Concepo de um Processo Especfico para SoftwareCientfico. Dissertao de Mestrado. Centro Federal de Educao Tecnolgicade 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 Especfico para Software Cientfico: Propostas Iniciais. XXVIICILAMCE Iberian Latin American Congress on Computational Methods inEngineering Belm-PA, 2006PURRI, M. C. M. S. Estudo e Propostas Iniciais para a Definio de umProcesso de Desenvolvimento para Software Cientfico. Dissertao deMestrado. Centro Federal de Educao Tecnolgica de Minas Gerais CEFET-MG. Belo Horizonte, 2006.RAMOS, C., ZITA A., VALE, L., SANTOS, J., Aplicaes Inteligentes emCentros de Controlo: Verificao e Validao, Jornadas LusoEspanholas deEngenharia Electrotcnica, 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. 127 SAUER, 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. So 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, SPNOLA R. O., Introduo Inspeode Software Aumento da qualidade atravs de verificaes intermedirias,Engenharia de Software Magazine, Ano 1, 1 edio, 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 enciclopdia livre. Disponvel em: http://www.wikipedia.com.br.Acessado em 05/06/2008. 128