SISTEMA DE ENSINO PRESENCIAL CONECTADO Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas Marcelo Viatroski de Medeiros

NOSSA LOCADORA DE LIVROS

Camaqu 2012

MARCELO VIATROSKI DE MEDEIROS

NOSSA LOCADORA DE LIVROS

Trabalho apresentado ao Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paran, para as disciplinas do Segundo Sementre. Profa. Polyanna P. Gomes Fabris Prof. Luiz Cludio Perini Prof. Roberto Nishimura Prof. Anderson Macedo

Camaqu 2012

SUMRIO 1 INTRODUO...........................................................................................................3 2 OBJETIVOS...............................................................................................................4 3 DESENVOLVIMENTO...............................................................................................5 3.1 O Processo de Inspeo de Software:................................................................5 A Inspeo de Software um tipo particular de reviso que pode ser aplicado a todos os artefatos de software e possui um processo de deteco de defeitos rigoroso e bem definido. FAGAN (1976) desenvolveu o processo tradicional de inspeo de software, uma forma detalhada de se realizar uma reviso. Neste processo, existem seis atividades principais: ...........................................................5 a) Planejamento Um usurio, desempenhando o papel de moderador da inspeo, define o contexto da inspeo (descrio da inspeo, tcnica a ser utilizada na deteco de defeitos, documento a ser inspecionado, autor do documento, entre outros), seleciona os inspetores e distribui o material a ser inspecionado...............5 b) Apresentao Os autores dos artefatos a serem inspecionados apresentam as caractersticas destes. Esta fase pode ser omitida se os inspetores possuem conhecimento sobre o projeto e os artefatos que devem ser inspecionados...........5 c) Preparao Os inspetores estudam os artefatos individualmente, e eventualmente fazem anotaes sobre estes produzindo uma lista de discrepncias. O fornecimento de tcnicas de leitura pode facilitar a execuo desta tarefa................................................................................................................5 d) Reunio Uma reunio em equipe ocorre, envolvendo o moderador, os inspetores e os autores do documento. Discrepncias so discutidas, e classificadas como defeito ou falso positivos. A deciso final sobre a classificao de uma discrepncia sendo discutida do moderador. A soluo dos defeitos no discutida durante a reunio, que no deve exceder duas horas, uma vez que aps este tempo a concentrao e a capacidade de anlise dos inspetores costuma reduzir drasticamente. No caso em que uma reunio precisar de mais de duas horas, sugerido que o trabalho de inspeo continue no prximo dia..........6 e) Retrabalho O autor corrige os defeitos encontrados pelos inspetores e confirmados pelo moderador.....................................................................................6 f) Continuao O material corrigido pelos autores repassado para o moderador, que faz uma anlise da inspeo como um todo e re-avalia a qualidade do artefato inspecionado. Ele tem a liberdade de decidir se uma nova inspeo deve ocorrer ou no........................................................................................................................6 3.2 Verificao e Validao: .....................................................................................6 3.3 Testabilidade de Software: A Testabilidade examina as diferentes probabilidades e caractersticas comportamentais que levam o cdigo a falhar se alguma coisa estiver errada. Um programa tem alta testabilidade se ele tende a expor suas falhas durante os testes com entradas que geram defeitos. Um programa tem baixa testabilidade se ele tende a ocultar as falhas detectadas durante os testes, produzindo sadas corretas para entradas que geram defeitos.. 7 3.4 SGDB :.................................................................................................................7 3.5 LINGUAGEM DE PROGRAMAO:..................................................................8 3.6 MODELO DE PROCESSO PROPOSTO:...........................................................9 4 CONCLUSO...........................................................................................................10

5 REFERNCIAS........................................................................................................11

1 INTRODUO O Cliente Nossa Locadora de Livros, no qual o proprietrio Sr. Joo Carlos, contratou a nossa empresa Alunos da Unopar para criar um projeto de informatizao, para agilizar suas rotinas dentro de sua empresa, envolvendo Cadastro, Locao, Estoque, Classificao, Compras e Controle Financeiro, criando assim um controle total sobre seu estoque de livros e controle de seus clientes.

2 OBJETIVOS Criar um controle eficiente e gil para administrao da empresa Nossa Locadora de livros, deixando de lado o uso de programas distintos e utilizando-se de uma ferramenta que interligue todos os setores da empresa para assim obter maior lucratividade, agilidade, qualidade e controle.

3 DESENVOLVIMENTO

3.1 O Processo de Inspeo de Software:

A Inspeo de Software um tipo particular de reviso que pode ser aplicado a todos os artefatos de software e possui um processo de deteco de defeitos rigoroso e bem definido. FAGAN (1976) desenvolveu o processo tradicional de inspeo de software, uma forma detalhada de se realizar uma reviso. Neste processo, existem seis atividades principais:

a) Planejamento Um usurio, desempenhando o papel de moderador da inspeo, define o contexto da inspeo (descrio da inspeo, tcnica a ser utilizada na deteco de defeitos, documento a ser inspecionado, autor do documento, entre outros), seleciona os inspetores e distribui o material a ser inspecionado.

b) Apresentao Os autores dos artefatos a serem inspecionados apresentam as caractersticas destes. Esta fase pode ser omitida se os inspetores possuem conhecimento sobre o projeto e os artefatos que devem ser inspecionados.

c) Preparao Os inspetores estudam os artefatos individualmente, e eventualmente fazem anotaes sobre estes produzindo uma lista de discrepncias. O fornecimento de tcnicas de leitura pode facilitar a execuo desta tarefa.

d) Reunio Uma reunio em equipe ocorre, envolvendo o moderador, os inspetores e os autores do documento. Discrepncias so discutidas, e classificadas como defeito ou falso positivos. A deciso final sobre a classificao de uma discrepncia sendo discutida do moderador. A soluo dos defeitos no discutida durante a reunio, que no deve exceder duas horas, uma vez que aps este tempo a concentrao e a capacidade de anlise dos inspetores costuma reduzir drasticamente. No caso em que uma reunio precisar de mais de duas horas, sugerido que o trabalho de inspeo continue no prximo dia.

e) Retrabalho O autor corrige os defeitos encontrados pelos inspetores e confirmados pelo moderador.

f) Continuao O material corrigido pelos autores repassado para o moderador, que faz uma anlise da inspeo como um todo e re-avalia a qualidade do artefato inspecionado. Ele tem a liberdade de decidir se uma nova inspeo deve ocorrer ou no.

3.2 Verificao e Validao: Verificao: Envolve checar se o software cumpre com suas especificaes; Validao: um processo mais genrico. necessrio assegurar que o software atende s expectativas do cliente. Mostra que o software faz o que o cliente espera que faa, exatamente como foi especificado.

3.3 Testabilidade

de

Software:

Testabilidade

examina

as

diferentes

probabilidades e caractersticas comportamentais que levam o cdigo a falhar se alguma coisa estiver errada. Um programa tem alta testabilidade se ele tende a expor suas falhas durante os testes com entradas que geram defeitos. Um programa tem baixa testabilidade se ele tende a ocultar as falhas detectadas durante os testes, produzindo sadas corretas para entradas que geram defeitos.

3.4 SGDB : Baseado nas informaes relatadas at aqui, faz-se necessrio uma recomendao ao proprietrio da Nossa Locadora de Livros, sobre qual SGBD (Sistema Gerenciador de Banco de Dados) seria mais adequado implementar na soluo de informatizao. Aps anlises complementares foi sugerido ao proprietrio a implementao do SGBD gratuito PostgreSQL. O PostgreSQL pode ser utilizado, modicado e distribudo por qualquer pessoa para qualquer nalidade, seja particular, comercial ou acadmica, livre de encargos. E um dos lderes em tecnologia, conhecido como o banco de dados de cdigo aberto mais avanado do mundo. Ele tem desempenho excelente, indicativo de segurana magnco, rico em funcionalidades, fcil de usar, aprender e gerenciar. PostgreSQL timo para aplicaes de pequeno, mdio e grande porte sendo elas para processamento de transaes ou data warehouse. Com uma extensa comunidade de suporte gratuita, voc pode trabalhar com pessoas e empresas que preferir sendo elas consultores ou grandes vendedores. Por ser um SGBD gratuito, ele pode ser implementado em um servidor Linux, independente da distribuio, assim o cliente no ter a necessidade de pagar para obter um sistema operacional e um SGBD para o seu servidor.

3.5 LINGUAGEM DE PROGRAMAO: Com base em pesquisa de mercado em relao Linguagem de Programao recomendada para o desenvolvimento do sistema, foi sugerido ao proprietrio da empresa a utilizao da linguagem JAVA. Java depende de uma JVM, que gratuta. O programador depende de um compilador e do JDK, que tambm gratuto. Programadores costumam utilizar IDEs, como o Delphi ou o o Netbeans. Para Java, apesar de haverem IDEs pagas, as duas maiores IDEs do mercado (Eclipse e NetBeans) tambm so gratutas. H vrios frameworks e ferramentas para a implementao de sistemas em Java, e os mesmos tambm costumam ser gratutos. A documentao gratuta. Servidores so gratutos. Drivers de Banco de Dados so gratutos. Java interopervel, ou seja, funciona em vrias arquiteturas distintas, sistemas operacionais distintos e trabalha com paradigmas de programao distintos como desktop e web. Na web Java pode ser utilizado no servidor (JSP e Servlets) ou no cliente (Applets). Apesar de haver diferenas para a implementao (J2EE, J2SE e J2ME), a linguagem a mesma e o conceito o mesmo. Indo alm, Java permite tambm uma facilidade para internacionalizao com a utilizao nativa de arquivos Properties e definio automtica de valores financeiros, numricos, de data e texto. Alm disto, a utilizao de Unicode pode garantir a visualizao de textos em vrios alfabetos distintos.

3.6 MODELO DE PROCESSO PROPOSTO: Com base no estudo de caso, o Modelo de Processo proposto para o desenvolvimento do sistema foi o Modelo Espiral. O objetivo do modelo espiral prover um metamodelo que pode acomodar diversos processos especficos. Isto significa que podemos encaixar nele as principais caractersticas dos modelos vistos anteriormente, adaptando-os a necessidades especficas de desenvolvedores ou s particularidades do software a ser desenvolvido. Este modelo prev prototipao, desenvolvimento evolutivo e cclico, e as principais atividades do modelo cascata. Sua principal inovao guiar o processo de desenvolvimento gerado a partir deste metamodelo realizado com base toda a em anlise evoluo de do riscos e planejamento que durante

desenvolvimento. Riscos so circunstncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. So exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que no podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que sero utilizados no produto final, etc. A identificao e o gerenciamento de riscos hoje uma atividade importantssima no desenvolvimento de software devido imaturidade da rea e falta de conhecimento, tcnicas e ferramentas adequadas.

10

4 CONCLUSO Podemos concluir que, para criar uma soluo informatizada para a empresa preciso muito estudo de caso, para entendermos as reais necessidades do cliente precisamos entrevist-lo, estudar o mercado que o cliente atua, podendo assim oferecer solues mais robustas e simples. Para um Desenvolvimento gil e um software exato, precisamos diminuir ao mximo as etapas que os usurios do sistema tero que executar para qualquer funo, assim tambm diminuiremos o numero de telas e assim o tempo gasto no desenvolvimento, economizando assim recursos financeiros tanto para o desenvolvedor quanto para o cliente.

11

5 REFERNCIAS Processo de Inspeo de Software http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-inspecaode-software/8037 Verificao e Validao http://www.slideshare.net/ccalmendra/verificao-validao-e-teste-de-software Testabilidade de Software http://www.linhadecodigo.com.br/artigo/923/o-que-e testabilidade.aspx#ixzz26qnKtaPo SGBD PostgreSQL http://www.opengeo.com.br/?q=node/17 Linguagem JAVA http://pt.wikipedia.org/wiki/Java_(linguagem_de_programao)