SISTEMA DE ENSINO PRESENCIAL CONECTADO Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas Januario Sousa Lima Neto

LOCADORA DE LIVROS:
Informatizando a empresa

Palmas 2012

JANUARIO SOUSA LIMA NETO

LOCADORA DE LIVROS:
Informatizando a empresarial

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 (Anlise de Sistemas) Prof. Luiz Cludio Perini (Engenharia de Software) Prof. Roberto Nishimura (Banco de Dados I) Prof. Anderson Macedo (Linguagem e Tcnicas de Programao II)

Palmas 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 (Banco de Dados) RECOMENDADO:.....................................................7 3.5 LINGUAGEM DE PROGRAMAO RECOMENDADA:.....................................7 3.6 MODELO DE PROCESSO PROPOSTO:...........................................................8 4 CONCLUSO...........................................................................................................12

5 REFERNCIAS........................................................................................................13 6 APNDICES.............................................................................................................14

1 INTRODUO O Cliente Nossa Locadora de Livros, no qual o Sr. Joo Carlos, contratou a empresa Alunos da Unopar para informatizar suas rotinas empresariais, envolvendo: Locao, Estoque, Classificao, Compras e Controle Financeiro.

2 OBJETIVOS Tornar todas as operaes da empresa, que atualmente so feitas de modo no produtivo (Em programas separados) para um modelo gil e de fcil administrao, melhorando assim o atendimento ao cliente e a organizao.

3 DESENVOLVIMENTO Demonstraremos a seguir alguns processos de desenvolvimento de software. 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 (Banco de Dados) RECOMENDADO: 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 PostgreSQL. Tal recomendao ser faz por conta de que o PostgreSQL o Sistema Gerenciador de Banco de Dados (SGBD) de cdigo aberto (software livre) que possibilitou o desenvolvimento de solues corporativas com uma melhor relao custo x benefcio. Um ponto forte desse SGBD a sua capacidade de tratar grandes volumes de dados com alta performance e escalabilidade, ou seja, a sua arquitetura pode ser continuamente ampliada de acordo com a demanda dos usurios. Exatamente nesse contexto, entram as aplicaes na res de geotecnologias que necessitam de uma infra-estrutura robusta e em contnua expanso. Em estudos realizados em universidades e centros de pesquisa, o PostgreSQL tem apresentado performance, no mnimo, 20% superior aos SGBDs comerciais mais conhecidos. 3.5 LINGUAGEM DE PROGRAMAO RECOMENDADA: 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 DELPHI, por ser uma linguagem voltada ao desenvolvimento comercial de alto desempenho e de fcil utilizao por

parte dos desenvolvedores, pois foi criada seguindo o conceito RAD e seu ambiente de desenvolvimento IDE (Integrated Development Environment Ambiente de Desenvolvimento Integrado). Nesse ambiente a forma de construo, da interface dos programas, segue o padro de janelas com todas as facilidades que elas possuem. Assim durante todo o desenvolvimento o programador visualiza o formato de sua aplicao, podendo arrastar e soltar componentes que iro compor sua interface.

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, pois nesse modelo so executados o planejamento, anlise de risco, engenharia, construo e release, avaliao do cliente e comunicao com o cliente.

1 CENRIO PROPOSTO: O objetivo do sistema tornar as rotinas da empresa Nossa Locadora de Livros mais objetivas, tornando assim todos os departamentos mais geis. Para isso precisamos de um sistema enxuto, no qual no desperdisse os cliques dos usurios e tenham o mximo de informao relacionada disponvel no mesmo local, controlando somente a autorizao de edio dos campos. Sendo assim este sistema ter 9 telas: 1.1 Login: Ao acessar o sistema solicitado um login, este login (Usurio e senha), aps logar, o sistema redireciona automaticamente o usurio para a parte do departamento que ele tem o controle, no permitindo que usurios acessem informaes de um setor no qual no esto lotados; 1.2 Consulta: os departamentos de locao, estoque e compras, aps logar, tero acesso a tela de consulta, onde podero consultar os livros que j existem em estoque para efetuar outros procedimentos, a consulta pode ser feita por: autor, titulo ou classificao. ainda nesta tela ter os seguintes botes: 1.2.1 Pesquisar: Aps inserir dados em qualquer um dos campos acima, o funcionrio clica em pesquisar e obtm uma lista de livros relativos aos dados inseridos, com um boto Detalhes ao lado de cada opo da lista; seleciona o(s) livro(s) na lista e procede para Alugar ou solicitar Sugerir Compra. 1.2.2 Alugar: Aps pesquisar, procede para a tela de Locao do livro, utilizando os dados relativos a consulta efetuada 1.2.3 Sugerir Compra: Aps pesquisar, procede para a tela de Sugesto de compra do livro, utilizando os dados relativos a consulta efetuada. 1.3 Locao: Aps consultar, escolher a opo e clicar em Alugar, ser direcionado para a tela de Locao, onde aparecer o item(s) selecionado(s) um campo de pesquisa para pesquisar o Cadastro do Cliente (mesma tela), fornecendo parte do nome (campo: Nome) ou CPF (Campo: CPF). 1.3.1 Aps encontrar, seleciona, vinculando este Cliente ao(s) Livro(s) alugados.

Caso o sistema retorne mais de um cadastro de cliente, poder ser sanada qualquer dvida clicando no boto Detalhes, ao lado das informaes de cada cliente da lista, este boto levar para a tela onde ter todos os dados do Cliente. Aps o cliente digitar a senha, ser mostrada a tela com o Extrato. 1.4 Extrato: Nome do Cliente, Livro(s) alugado(s), Valor Unitrio, Valor Final, e um boto de Confirmar, que ao ser clicado gera a nota fiscal. 1.5 Sugesto de Compra: Se a consulta do livro for nula o boto Sugerir compra aparecer. Esta tema mostrara o(s) campo(s) digitado(s) preenchido(s) e poder adicionar algo mais no campo detalhes, aps detalhar, aparecer o boto Sugerir, encaminhando assim esta sugesto para o Departamento de Compras. 1.5.1 O Departamento de Compra tem acesso a mesma tela onde visualiza uma lista de todas as Sugestes feitas at o momento, cada uma ter um boto para Confirmar a compra e outro para Excluir a Sugesto. 1.5.2 Confirmando a Sugesto, a Solicitao de Compra encaminhada para o Departamento Financeiro. 1.6 Incluir: O Departamento de Estoque ter acesso a parte de incluso, podendo inserir ou deletar qualquer registro de Livros. A incluso ser feita alimento os campos: Ttulo, Autor (Mais de um separados com vrgula), Classificao (Diamante, Ouro, Prata, Bronze), e clicando no boto Incluir. 1.7 Comprar: O Departamento Financeiro: Recebe um relatrio da Solicitao de Compra, clica em Autorizar, para autorizar a compra do Livro ou Negar para negar a compra do livro 1.7.1 Aps o departamento Financeiro autorizar, nesta mesma tela, o Departamento de Compras poder visualizar quais foram autorizados e quais foram negados em uma lista. Procedendo com o contato com os fornecedores para a compra do material 1.8 Financeiro: O Departamento Financeiro ter nesta tela o seguinte controle: 1.1. Locao: Quantidade e valor de livros alugados

1.2. 1.3.

Compras: Quantidade e Valor de livros comprados Renda: Valor exato da renda diria das locaes e do gasto com

compras de livros, mostrando assim quanto a empresa lucrou, ajudando assim a prever os gastos e o potencial de lucro da empresa 1.9 Relatrio: O Diretor, alm de ter acesso a todas as outras telas, poder atravs desta tela imprimir um Relatrio de todas as Compras e Locaes feitas pela firma, podendo definir perodos: Mensal, Semanal, Anual. Possibilitando a anlise do dia a dia da empresa.

4 CONCLUSO Podemos concluir que, para criar uma soluo informatizada para a empresa preciso muito estudo de caso (Caso de uso). Para quem est cursando desenvolvimento de sistema, no basta somente saber programar, preciso ter uma grande noo de organizao e disciplina. Para entendermos as reais necessidades do cliente precisamos entrevist-lo, e at estudar o mercado que o cliente atua, podendo assim oferecer solues mais robustas ainda do que o cliente est pensando. Claro que primeiro temos que entregar o que o cliente quer, mas como, nos mtodos de desenvolvimentos vistos nesse trabalho, poderemos reutilizar componentes, ento entender suas aplicaes ou estender suas funcionalidades s trar benefcios para os Desenvolvedores. 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 tanto de telas e assim o tempo gasto no desenvolvimento, economizando assim recursos financeiros (Energia, Tempo), afinal, tempo dinheiro.

5 REFERNCIAS SOUSA LIMA NETO, Januario, Conhecimentos pessoais. 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 DELPHI http://pt.wikipedia.org/wiki/Embarcadero_Delphi

6 APNDICES

Wikipdia: maior enciclopdia livre do mundo. http://pt.wikipedia.org

IBM: Mquinas de Negcios Internacionais (International Business Machines): Empresa fundada nos Estados Unidos voltada para o ramo da informtica. http://www.ibm.com/br/pt/