2.

INTRODUO

Este trabalho est sendo desenvolvido baseado em um cenrio fictcio , denominado Nossa Locadora de Livros. Tem como intuito colocar na prtica toda a conceituao terica at o momento visto no curso. Prova que atravs de poucas aulas mas com a utilizao de tcnicas e conceitos modernos de anlise de sistemas, consegue-se criar, com um mnimo de planejamento e desenvolvimento, uma soluo com bom rendimento e operacionalidade. Procura-se nele resolver um problema de ordem econmico administrativo, conferindo agilidade e produtividade para o seu negcio , trazendo como conseqncia uma maior satisfao para os seus clientes.

3.

OBJETIVO

Exercitar o uso de tcnicas modernas de desenvolvimento de software complementando o ensinamento terico com a sua aplicao prtica.

4.

Desenvolvimento

4.1 IDENTIFICAO DOS CASOS DE USO

- Controlar financeiro -Controlar Compras - Controlar Estoques - Controlar Locao - Controlar cadastro de livros e classificao de gneros -Controlar Cadastramento funci/usurio

4.2

REGRA DE NEGCIO locao de livros

Todo cliente tem de ser cadastrado Um cliente pode alugar um ou mais livros Um cliente pode devolver um ou mais livros Um cliente pode devolver ou no o livro na data marcada O tempo de aluguel de cada livro, de 8 dias corridos Cada livro no devolvido na data marcada est automaticamente realugado Um livro s pode ser alugado a um cliente Nos Livros, realugados automaticamente, incidir um percentual de 10% ao preo normal de cobrana. Pode se entregar livros para usurios autorizados pelo cliente Cliente deve informar pessoas com sua autorizao para alugar livros/receber/entregar. Cliente deve ressarcir locadora por livros danificados, rasgados, faltando pginas, etc., pelo seu preo atual na editora. Se cliente no resgata livro em data reservada, esta, ser automaticamente cancelada.

4.3 TELAS NECESSRIAS P/FAZER UM PROGRAMA DE CADASTRO DAS INFORMAES.

Obs: Responder de forma prtica quais telas so necessrias justificando e identificando os campos de cada uma. Obs: cada caso de uso originar uma tela-no ser preciso desenh-la s comentar conforme acima.

4.4 COMPARAO ENTRE METODOLOGIAS DE PROCESSO DE

DESENVOLVIMETO DE SOFTWARE.

4.4.1

RUP

Processo considerado pesado ,preferencialmente aplicado a grandes equipes de desenvolvimento e a grandes projetos de qualquer escala. modular e automatizado e toda a sua metodologia apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM atravs de seus Rational Suites.Por ser flexvel e

configurvel pode ser utilizado em projetos de pequeno,mdio e grande porte.(Kroll e Kruchten 2003)mostra como o RUP pode ser utilizado em um projeto de uma semana com uma equipe de uma pessoa. ORUP um processo de engenharia de software bem definido e bem estruturado . O RUP define claramente quem responsvel pelo que, como as coisas devem ser feitas,e quando faz-las. Ele ataca os riscos cedo e continuamente, foca no software executvel, constri o sistema com componentes,trabalha junto como um time, faz da qualidade um estilo de vida e no algo para depois. O RUP tenta diminuir os riscos do desenvolvimento e efetivamente deixar o desenvolvimento mais eficiente, atravs de seis prticas bsicas(conhecidas por Best practices) Trata-se de um processo proprietrio, organizado em disciplinas(workflows) onde so distribudas tarefas e responsabilidades e gerados produtos de trabalho(artefatos). O RUP composto da unio de vrias metodologias, dinmico,esttico,e prtico, possui quatro fases e nove disciplinas. O RUP prova ser um processo de desenvolvimento robusto e definido , embora bastante complexo/trabalhoso para projetos de software de pequeno porte, ele pode ser bem aproveitado para projetos aonde preciso manter registro constante do fluxo do projeto.

4.4.2

SCRUM
a

um processo de desenvolvimento iterativo e incremental que pode ser aplicado

qualquer produto ou no gerenciamento de qualquer atividade complexa.Tem como caracterstica principal ser um processo emprico no definido. uma metodologia gil para gerenciamento de projetos, utiliza um controle descentralizado para lidar de forma mais eficiente com contextos pouco previsveis. uma metodologia cujo propsito trazer organizao ao processo desenvolvido de software, seu objetivo lidar com a desorganizao e o caos promovidos por determinados ambientes. Existe apenas trs papis no scrum: dono do produto, scrum mster e desenvolvedor.Teoricamente ele pode ser utilizado onde houver a necessidade de gerenciar um grupo de pessoas que trabalham juntas a fim de atingir um objetivo comum. O scrum dividido em trs fases : planejamento, sprints(ciclos) e encerramento. Ele contempla uma viso emprica baseada no controle de processos.

4.4.3

RAD

Como a principal caracterstica da metodologia RAD do produto ser desenvolvido de forma modularizada , necessrio que todos os requisitos estejam bem definidos e sejam o mximo possvel , independente entre eles. Pode ser dividido em vrios

mdulos independentes. Segundo Sommervile(2007) tambm um processo de desenvolvimento de software iterativo incremental para tipos de projetos mais curtos com ciclos girando em torno de 60/90 dias. Era conhecido pelo termo prototipao rpida . Evoluiu do modelo espiral e do evolucionrio. No aconselhvel para projetos quando riscos tcnicos so altos. Para o seu trabalho h necessidade de habilidades maiores dos desenvolvedores e suporte maior da gerncia e dos clientes. apropriado quando o escopo do projeto restrito , a distribuio do produto pequena e a performance no o mais importante. Nele existe uma perda de preciso cientfica.

5 CONCLUSO
Ao ler o trabalho pela primeira vez achamos que no iramos conseguir faze-lo, mas medida que as aulas avanam, os conhecimentos vo chegando de mansinho, e o otimismo comea a tomar conta. Apesar de seguir todos os conceitos destinados a soluo do problema em questo de frisar que dvidas aconteceram e ainda permanecem. Avalia-se que o exerccio poderia ter o seu prazo de entrega estendido por pelo menos 15 dias com a finalidade de ajustar a confeco do trabalho ao volume das matrias necessrias para seu entendimento, o que lhe conferiria melhor absoro dos conhecimentos. Poder-se ia ter aberto um frum exclusivo para se tirar dvidas respeito, entre alunos e professor e entre alunos dos plos. De qualquer forma sabemos que teremos erros e que eles sero sanados ao longo dos demais exerccios que viro. Fica o sentimento nico de estrearmos em um projeto pela primeira vez com o esprito de querermos sempre fazer o melhor.