1

SISTEMA DE ENSINO PRESENCIAL CONECTADO ANLISE DE DESENVOLVIMENTO DE SISTEMAS JHSODVHOISH

FUNLKJHASFOVHOIASH

Corumb 2012

LKASNOVIHASOIDBV

LJBAFOJVBOASFUBF

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). : Polyanna P. Gomes Fabris Roberto Y. Nishimura Lus Luis Cludio Perini Anderson Macedo

Corumb 2012

SUMRIO 1 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.6.1 3 3.1 3.2 3.3 4 4.1.1 4.1.1.1 4.1.1.2 4.1.1.3 4.1.2 5 5.1 5.2 6 INTRODUO .....................................................................................................5 DESENVOLVIMENTO .........................................................................................6 PLANO DE DESENVOLVIMENTO...................................................................6 ENGENHARIA DE REQUISITOS ................................................................6 MODELOS DE PROCESSO DE SOFTWARE..............................................6 GERENCIAMENTO DE PROJETO DE SOFTWARE ...................................7 GESTO DO CONHECIMENTO ..................................................................7 MTRICAS DE QUALIDADE ........................................................................8 QUALIDADE DE SOFTWARE ......................................................................8 MODELO DE QUALIDADE - CMMI...........................................................9

REQUISITOS .....................................................................................................10 REQUISITOS FUNCIONAIS DO SISTEMA BIBLIOTECA .............................10 REQUISITOS NO FUNCIONAIS DO SISTEMA BIBLIOTECA.....................11 DIAGRAMA CASO DE USO...........................................................................11 PROJETO DE BANCO DE DADOS ...................................................................13 MODELAGEM CONCEITUAL.....................................................................13 DESCRIO DA TABELA DADOS_CLIENTE .......................................13 DESCRIO DA TABELA CADASTRA_LIVRO.....................................14 DESCRIO DA TABELA LOC_LIVRO ................................................14 MODELAGEM LGICA ..............................................................................15 PRIVILGIO DE ADMINISTRADOR ..............................................................18 PRIVILGIO DE CLIENTE COMUM .............................................................21 CONCLUSO ....................................................................................................23

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

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

1 INTRODUO A utilizao de softwares gerenciadores h o j e j faz parte do cotidiano de muitas pessoas. Mesmo aquelas que pensam que nunca utilizaram um software, Internet, ou um computador, sem perfeceber se beneficiam dos avanos da informtica e podero sofrer as conseqncias de um erro, defeito ou falha de um software. Atualmente, as fbricas de softwares atuam fortemente 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 consistir em levantar informaes junto s fbricas de software e investigar como elas lidam dia a dia com a qualidade de seus produtos. Levantados os parmetros necessarios, partiremos para a elaborao de um plano de desenvolvimento com nfase na qualidade, ou seja, uma gama de conceitos e prticas da Engenharia de Software que atuam decisivamente na produo de software de qualidade. Falaremos ainda da importncia dos ferramenta requisitos, diferenas existentes entre requisitos funcionais e no funcionais e levantaremos os requisitos para o sistema proposto. Utilizaremos a Astah na modelagem do diagrama de caso de uso do sistema de biblioteca; o Brmodelo nos ajudar na criao do banco de dados conceitual e lgico deste sistema, bem como a linguagem PHP junto com o banco de dados Mysql nos permitir a criao das telas. na

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 umproduto reflexo 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, da qualidade de e gerenciamento do processo

10

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) O sistema deve prover e controlar a renovao da locao de forma on-line; c) O sistema deve manter um cadastro de livros; d) O sistema deve controlar e disparar avisos sobre prazos de devoluo se esgotando a seus clientes;

11

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 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 emprstimos. O pelo sistema, bem como gerenciar suas funcionrio tambm pode efetuar pendncias e de renovaes gerenciar atraso confirmado e avisar ao cliente que comparea biblioteca para

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.

12

Figura 3 Diagrama caso de uso UML

13

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) 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 endereo do cliente.

14

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 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,ti tu lo,qnt e classificacao. Para os cadastros desta tabela, s permitido cliente com privilgios de administrador. So os campos da tabela livro: a) Campo id_livro: identificar o livro atravs de um nico registro b) Campo valor: armazena o valor do livro para locao. 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 informao do local onde o livro se encontra. 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

15

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, somente para emprstimo. qual caminho tomar, se para o cadastro ou

Figura 5 Modelo Lgico

16

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 caracter, com preenchimento obrigatrio;

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 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 estrangeira importada da tabela CADASTRA_LIVRO do campo id_livro com todas as sua

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.

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.

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.

Figura 9 Pgina para consultar situao de cliente

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.

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

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