DIAGRAMA

SUMÁRIO

1 - Introdução......................................................................................................................................... 03

2 - Objetivo............................................................................................................................................. 04

3 - Desenvolvimento............................................................................................................................... 04

3.1 - Diagrama.................................................................................................................................. 04

3.2 - Cardinalidade........................................................................................................................... 05

3.2.1 - Um para um................................................................................................................... 05

3.2.2 - Um para muitos............................................................................................................. 05

3.2.3 - Muitos para muitos........................................................................................................ 05

3.3 - Telas........................................................................................................................................ 05

3.4 - Metodologias............................................................................................................................ 06

3.4.1 - RAD............................................................................................................................... 06

3.4.2 - SCRUM.......................................................................................................................... 07

3.4.3 - RUP............................................................................................................................... 08

4 - Conclusão......................................................................................................................................... 11

5

- Bibliografia......................................................................................................................................... 12

03

1 - INTRODUÇÃO

Este trabalho objetiva o desenvolvimento de um programa para uma locadora de livros, onde todo o trabalho era manual e manuscrito, passando a ser informatizado, facilitando assim a vida tanto dos funcionários quanto dos clientes, pela praticidade adquirida através da informatização. Vamos identificar os casos de uso e fazer o seu diagrama através da ferramenta chamada ASTAH, permitindo visualizar todos os processos da locadora. Iremos verificar quais combinações existem entre livro e cliente, proporcionando a oportunidade de entendermos as combinações possíveis através da cardinalidade do relacionamento. As telas a serem elaboradas para a interface com o cliente serão definidas baseadas nos levantamentos e das necessidades de cada usuário. Será feito uma comparação entre as três metodologias de processo de desenvolvimento de software, com a finalidade de se verificar qual delas é mais apropriada para o desenvolvimento deste projeto.

04

2 - OBJETIVO

Diante da necessidade de nosso cliente, temos que levantar todos os requisitos e desenvolver um produto que venha a atender na sua íntegra as carências da loja, fazendo com que ela a partir deste momento, deixe de ser arcaica para ingressar na era da modernidade, para isto, é necessário mostrar aos funcionários que as mudanças que serão feitas através da informatização vem para facilitar a vida deles e não para dificultar, porque o ser humano é normalmente resistente a mudanças. Ao final deverá ser entregue um programa que verdadeiramente venha facilitar a vida de todos, pois é para isto que os programas são criados.

3 - DESENVOLVIMENTO

3.1 -

DIAGRAMA

05

3.2 – CARDINALIDADE

3.2.1 – Um para um

Um cliente pode locar apenas um livro.

3.2.2 – Um para muitos

Um cliente pode locar mais de um livro.

3.2.3 – Muitos para muitos

Mais de um cliente pode locar mais de um livro.

3.3 - TELAS

TELA ATRIBUTO

Cadastrar cliente Código do cliente

Nome

Sexo

Endereço

Número

Complemento

Bairro

Cidade

Estado

Telefone

Celular

CPF

CEP

Data de nascimento

e-mail

06

Cadastrar livro Código do livro

Titulo

Sinopse

Classificação

Valor

Páginas

Autor

Editora

Edição

Ano

Indicação

Disponível

Reserva

Classificar livro Código do livro

Classificação

Valor

Emprestar livro Código do livro

Título

Valor

Data do empréstimo

Data da devolução

Devolver livro Código do livro

Título

Valor

Data do empréstimo

Data da devolução

Multa

3.4 - METODOLOGIAS

3.4.1 - RAD

Rapid Application Development, ou Desenvolvimento Rápido de Aplicação, é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto que gira em torno de 60 a 90 dias.

Vantagens.

• Proporciona o desenvolvimento rápido e/ou a prototipagem de aplicações;

• Tem um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias);

• Cada função principal pode ser entregue para uma equipe RAD separada e então reunida e formar um todo;

• Criação e reutilização de componentes;

07

• Usado principalmente para aplicações de sistemas de informações;

• O desenvolvimento é feito em um nível mais alto de abstração;

• Visibilidade mais rápida através de protótipos;

• Grande flexibilidade (os desenvolvedores podem alterar o projeto facilmente);

• Envolvimento maior do usuário;

• Provável custo reduzido devido a sua rapidez, porque tempo é dinheiro;

Desvantagens

• O envolvimento com o usuário tem que ser constante;

• Comprometimento da equipe do projeto;

• Custo do conjunto de ferramentas e hardware

para rodar a aplicação;

• Mais difícil de acompanhar o estágio do projeto;

• Menos eficientes;

• Perda de precisão científica (falta de métodos formais);

• Pode acidentalmente levar ao retorno das práticas caóticas no desenvolvimento;

• Funções reduzidas (reuso, "time boxing");

• Funções desnecessárias (reuso de componentes);

• Problemas legais;

• Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes);

• Padronização (aparência diferente entre os módulos e componentes);

• Sucessos anteriores são difíceis de serem reproduzidos.

3.4.2 – SCRUM

É um processo iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. Não é um processo prescrito, ou seja, ele não descreve o que fazer em cada situação. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer. Apesar de ter sido destinado para

08

gerenciamento de projetos de software, ele pode ser utilizado em equipes de manutenção de software ou como uma abordagem geral de gerenciamento de projetos e/ou programas.

Vantagens

• Processo bem definido e com time boxing;

• Formação de profissionais auto-gerenciáveis;

• Maior envolvimento do cliente;

• Entregas frequentes;

• Desenvolvimento da equipe (liderança e auto-organização);

• Disseminação da prática de retrospectivas ou lições aprendidas através dos sprints;

• Foco no cliente;

• O cliente também se torna responsável nas alterações de escopo;

• Motivação maior dos programadores;

• Visualização do projeto;

• Diminuição dos bugs;

• Prioridades podem ser alteradas;

Desvantagens

• Projeto não documentado;

• Definição do prazo para entrega;

• Falta planejamento do escopo;

• Papéis indefinidos.

3.4.3 - RUP

Rational Unified Process ou Processo Unificado Racional é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento

de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento.

09

Usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém ser adaptado para projetos de qualquer escala. Para a gerência do projeto, provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software. É um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".

Vantagens

• Os maiores riscos do projeto são eliminados mais cedo;

• O desenvolvimento é iterativo e incremental, adaptando contantemente os rumos do projeto às mudanças das necessidades do cliente e dos usuários;

• O sistema desenvolvido passa a tolerar melhores mudanças de requisitos e alterações no produto;

• Os testes são também mais abrangentes, o que resulta em um sistema mais sólido e de maior qualidade;

• O sistema como um todo tende a apresentar maior confiabilidade e refinamento;

• Componentes desenvolvidos ao longo de um projeto podem ser reutilizados em outros projetos, diminuindo o tempo de desenvolvimento e os custos para o cliente;

• Captura muitas das melhores práticas do desenvolvimento de software moderno, de forma que possam ser adaptadas para uma grande variedade de projetos e de organizações;

• Desenvolver iterativamente;

• Gerenciar Requisitos;

• Usa arquitetura baseada em componentes;

• Modelagem Visual;

• Qualidade de software;

10

• Produtividade no desenvolvimento, operação e manutenção de software;

• Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade desejados;

• Estimativa de

prazos e custos com maior precisão;

• Grande investimento em ferramenta de Suporte.

Desvantagens

• Nas áreas de manutenção, gestão de métricas, gestão de pessoal, gestão de Engenharia de Software;

• A ferramenta é basicamente um sistema de hipertexto, não se encontra integrado a outras ferramentas;

• È necessário adequar às realidades da organização e de cada projeto desenvolvido, o que requer muito da intuição dos desenvolvedores do SI.

• Está dotado de uma perspectiva para desenvolvimento de software, pelo que não é prático para sistemas tipicamente manuais, embora possa ajudar na obtenção de requisitos.

• É um produto comercial, envolve custos para sua obtenção.

11

4 – CONCLUSÃO

Foram feitos todos os processos aonde foram identificados todos os participantes do sistema que foi implantado, fazendo com que a empresa tivesse um enorme ganho de tempo em pesquisa e controle dos empréstimos dos livros. Foram levantadas todas as necessidades e disponibilizadas através do programa utilizando suas telas que são a interface com o usuário e o banco de dados que é responsável pelo armazenamento das informações. Tudo ficou ao gosto do cliente, proporcionando uma praticidade enorme para todos os usuários. Após levar em conta todas as variáveis, tais como, agilidade, tamanho da empresa e agilidade no desenvolvimento, foi feita a escolha por utilizar a metodologia RAD, que nos proporcionou fazer a entrega do programa com a qualidade necessária em um tempo extremamente curto, fazendo com todos ficassem satisfeitos.

12

5 – BIBLIOGRAFIA

Análise de Sistemas I, Simone Sawasaki Tanaka, Editora ABDR.

Engenharia de Software, Luis Cláudio Perini, Marcos Ikuro Hisatomi, Wagner Luiz Berto, Editora ABDR.

http://astah.net/

http://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso

http://www.devmedia.com.br/tecnologias-de-banco-de-dados-e-modelagem-de-dados-parte-2/1871