ANALISE ESTRUTURADA DE SISTEMAS

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

DISCIPLINA: ANÁLISE ESTRUTURA DE SISTEMAS

VALPARAÍSO DE GOIÁS / GO

2013

ATPS

Análise Estruturada de Sistemas

Atividade Prática Supervisionada, elaborada com o objetivo de aprovação na disciplina de Análise Estruturada de Sistemas, do curso de Tecnologia em Análise e Desenvolvimento de sistemas, da Universidade Anhanguera.

Valparaiso - GO

2013

SUMÁRIO

Etapa 1.............................................................................................................................. 4,5 e 6

Etapa 2................................................................................................................................. 7 e 8

Etapa 3............................................................................................................................ 8,9 e 10

Etapa 4........................................................................................................................ 10,11 e 12

Bibliografia ............................................................................................................................ 13

Grupo Coral

Controle de estoque de terreno

Diariamente a Incorporadora envia uma lista atualizada com os terrenos disponíveis para as Imobiliárias; estas, por sua vez, repassam a lista a seus corretores, mas, no decorrer do dia, esta listagem não é atualizada.

Para resolver este problema surgiu a necessidade de se obter um sistema que controle o estoque, para que determinado terreno não seja vendido para mais de um comprador, ou seja, um sistema de vendas com acesso via web, com sua infraestrutura instalada na Incorporadora, para que cada corretor possa, em tempo real, checar se o terreno está disponível ou não.

Sistema de vendas do Grupo Coral

Corretor Imobiliária Ordem de Venda Data/Hora da Venda

Edilço Fernandes 10 Data e Hora(anexo)

Elma Roto Ruter 8 Data e Hora(anexo)

Eduardo Mais2x 4 Data e Hora(anexo)

No processo de venda o corretor dever realizar as seguintes etapas:

• Preencher o cadastro do comprador

• Informar a reserva do lote incorporadora.

• Apresentar as normas e regras da empresa.

Ferramenta Case

A sigla CASE significa “Computer Aided Software Engeneering”, em português: “Engenharia de Software Auxiliada por Computador”.

Ferramentas CASE são ferramentas utilizadas como suporte para desenvolver um software. Essas ferramentas oferecem um conjunto de serviços, fortemente relacionados, para apoiar uma ou mais atividades do processo de desenvolvimento de software e podem minimizar o tempo de desenvolvimento do programa, mantendo o alto nível de qualidade.

As vantagens em se utilizar uma Ferramenta CASE é o aumento da produtividade, melhor qualidade, diminuição dos custos, melhor gerenciamento e a grande facilidade de manutenção.

Cada ferramenta tem propósitos diferentes, fornece serviços diferentes, mas possuem algumas características em comum.

As ferramentas CASE podem ser classificadas em:

• Horizontais: oferecem serviços utilizados durante todo o processo de software;

• Verticais: utilizadas em fases específicas do processo de software.

Elas também podem ser classificadas de acordo com os serviços que oferecem, dentre as quais, cita-se.

• Documentação;

• Planejamento e gerenciamento de projetos;

• Especificações formais;

• Comunicação;

• Análise e projeto de software;

• Projeto e desenvolvimento de interfaces;

• Programação;

• Gerenciamento de Configuração;

• Controle de Qualidade.

Ou ainda, categoricamente, elas podem ser:

• Lower CASE - ferramentas de codificação (front-end);

• Upper CASE - ferramentas de análise, projeto e implementação;

• Integrated CASE - união de Upper e Lower CASE.

Um dos componentes indispensáveis de uma ferramenta CASE é a modelagem visual, ou seja, a possibilidade de representar, através de modelos gráficos.

As ferramentas CASE automatizam uma grande variedade de tarefas: Geração de documentação, Testes, Geração de código, Geração de Relatórios para acompanhamento do trabalho entre outras atividades.

O DBDESIGNER é um exemplo ferramenta CASE de código livre que serve para a modelagem de dados, mais especificamente para a elaboração de diagramas MER (Modelo Entidade Relacionamento). Dentre as suas principais vantagens podemos citar a fácil geração de código SQL do modelo criado, a separação dos modelos Físico e Lógico, a sua simples interface gráfica e a sua portabilidade.

Quadro 1 - Viabilidade Técnica do Sistema

Fonte: O Autor da ATPS

Requisitos Usuário Admin Tecnologia Vantagens Desvantagem Conclusão

Funcionais Usada

1. Gestão de Sim Não web Open source Necessita O software integrado a web, facilitam a atualização.

Vendas conexões

1.1. Definição Não Sim Mysql Open Source Nível Baixo Mysql, Open

Banco de de Segurança Source e

Dados Oracle Segurança Mão de obra capacidade

escassa de integração

SqlServer Suporte Não Potável

1.2. Definição Sim Sim PHP Facilidade Falta recursos PHP, pela integração com SGDB, e a conexões com a web.

Linguagem de Visuais

Programação desenvolver

Sim Não C++ Desenvolver Acesso a banco de dados

Análise de requisitos

Levantamento de Requisitos

1) Qual a dificuldade de comunicar a venda?

2) Quem gerencia os status de compras e vendas?

3) Como controlar as vendas?

5) A lista de venda disponibilizada pela incorporadora é atualizada de quanto em quanto tempo?

As necessidades das imobiliárias nas venda conceituam em formular um software que atendendo a necessidade de desfazer os erros de negócios da Incorporadora, para tanto as imobiliárias terá seus arquivos registrados em tabelas predefinidos os seus dados. Haverá uma data pré-definida para o fechamento da negociação do imóvel ou será realizado pelo departamento de venda a reabertura do imóvel vendido.

Tendo como base as entrevistas realizadas com clientes internos e externos obtivemos os seguintes requisitos:

• Requisitos Funcionais

Nome: Visualização de fotografias dos imóveis (RF1)|

Descrição: Os clientes poderão visualizar imagens dos imóveis, onde caso se interesse por determinado imóvel, irá verificar o endereço do stand de vendas daquele respectivo imóvel.

Nome: Usuário Master (RF2) |

Descrição: A incorporadora terá o usuário máster, onde ela irá cadastrar novos imóveis disponíveis a venda e terá acesso aos dados de todos os dados de venda dos imóveis, feitos pelas imobiliárias parceiras.

Nome: Usuário Corretor (RF3) |

Descrição: Os corretores das imobiliárias terão acesso apenas aos as informações referentes aos imóveis e as vendas que eles realizarem.

Nome: E-mail informativo (RF4) |

Descrição: Sempre um novo imóvel for cadastrado no sistema, o sistema deverá enviar um e-mail automático para todas as imobiliárias parceiras cadastradas.

Nome: Emissão de contrato (RF5) |

Descrição: Após efetuar a venda de um imóvel, o sistema irá gerar o contrato de compra e venda.

• Requisitos Não-Funcionais:

Nome: Validar CPF (NF1) |

Descrição: Ao efetuar o cadastro de um cliente, deverá verificar a autenticidade do CPF.

Nome: Cadastro de Devedores (NF2) |

Descrição: Após validar o CPF, o sistema deverá ser integrado aos sistemas de cadastro de devedores, e consultar se aquele CPF esta no cadastro.

Nome: E-mail Marketing (NF3) |

Descrição: Ao efetuar o cadastro, o cliente poderá escolher se deseja receber e-mail com imóveis disponíveis a venda.

Quadro 1 – Requisitos funcionais e Não funcionais

REQUISITOS FUNCIONAIS REQUISITOS NÃO FUNCIONAIS

Requisitos Descrição Prioridade Requisitos Descrição Prioridade

RF01 Slide das fotos dos imóveis Média RNF01 Validar CPF Essencial

RF02 Usuário Master Essencial RNF02 Cadastro de Devedores Essencial

RF03 Usuário Corretor Essencial RNF03 E-mail marketing Média

RF04 E-mail Informativo Alta

RF05 Emissão de Contrato Essencial

Diagrama de Fluxos de Dados (DFD)

O diagrama de fluxos de dados (DFD) é uma representação gráfica do "fluxo" de dados através de um sistema de informação, modelando seus aspectos de processo. Ele fornece apenas uma visão do sistema, a visão estruturada das funções, ou seja, o fluxo dos dados. Frequentemente, eles são uma etapa preliminar usada para criar uma visão geral do sistema que pode posteriormente ser elaborado. Os DFDs também podem ser usados para a visualização do processamento de dados (design estruturado).

Um DFD mostra que tipo de informação entrará e sairá do sistema, para onde os dados virão e irão e onde os dados serão armazenados. Ele não mostra informação sobre a temporização dos processos ou informações se os processos irão operar em sequencia ou em paralelo (o que é mostrado em um fluxograma).

Se estivermos desenvolvendo um sistema no qual os relacionamentos entre os dados sejam mais importantes que as funções, podemos dar menos importância ao DFD e dedicar-nos aos diagramas de entidade-relacionamento (DER).

Um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por “dutos” e “tanques de armazenamento de dados".

(Edward Yourdon)

Técnicas de Modelagem

Artigo: Modelo Conceitual VS Modelo Lógico

Os tipos de modelagem encontrados no referido artigo foram: Relacionamento “um-para-um”, Relacionamento “um-para-muitos”, Relacionamento “muitos-para-muitos”, Auto-relacionamento “um-para-muitos”, Auto-relacionamento “muitos-para-muitos”, Relacionamento Generalização/Especialização.

Modelagem de banco de dados não é uma ciência exata, assim como outros tipos de modelagem, portanto, não há verdade absoluta. Essas regras podem mudar de caso para caso. Mas é preciso ter atenção para quando quebrar essas regras. Precisamos ser muito criteriosos e fazer testes. O artigo estudado é muito útil, pois há uma quantidade enorme de erros de modelagem, por falta de conhecimento destas e de outras regras de modelagem em bancos de dados.

Passo 3 - Processos envolvidos no sistema

Identificação Processo Descrição da Função Local físico de onde é executada

ID 01 Compra de Terreno Plantão de vendas/web

ID 02 Localidade do Terreno Área do Terreno Disponível

ID 03 Disponibilidade do Terreno Área do Terreno Disponível

ID 04 Tamanho do Terreno No local onde será construído

ID 05 Compra Plantão de vendas/web

ID 06 Valor do Terreno Plantão de vendas/web

ID 07 Documentação Plantão de vendas/web

ID 08 Compra Plantão de vendas/web

ID 09 Pagamento Banco Credenciado

ID 10 Entrega do Produto Local destinado

Primeira Versão

Diagrama de Contexto do Sistema

Diagrama de Fluxo de Dados (DFD) de Nível 0 do sistema

DFD de Nível 0 resultante

O operador do plantão de vendas entra com os dados relativos ao terreno e o usuário que irá fazer o gerenciamento

No caso do terreno não estar disponível para compra por já estar vendido, o cliente terá que aguardar a disponibilidade de um novo terreno, onde o mesmo será notificado via e-mail por parte do plantão de vendas.

Neste período os plantonistas estão atentos a disponibilidade de um novo terreno a oferecer ao cliente nas proximidades da área em que o cliente havia se interessado.

Diagrama de Contexto

Neste caso será permitido identificar os limites dos processos, as áreas envolvidas com o processo e os relacionamentos com outros processos e elementos externos à empresa (plantão de vendas (ex.: clientes, fornecedores) e mostra as características do sistema como:

- Organizações/sistemas/pessoas que se comunicam com o sistema;

- Dados que o sistema absorve e deve processar;

- Dados que o sistema gera para o ambiente;

- Fronteira do sistema com o ambiente.

DFD de Nível 0 revisado, os DFD de Nível 1 e o Dicionário de Dados

BIBLIOGRAFIA

http://pt.wikipedia.org/wiki/Diagrama_de_fluxo_de_dados, acessado em: 24/11/2013

https://docs.google.com/a/aedu.com/file/d/0B7u8Pce2Xh_8MXZiTjFsdWRpUVE/edit

https://docs.google.com/file/d/0B7u8Pce2Xh_8RUR1THROZ0c3azg/edit?usp=s

haring, acessado em 24/11/2013

http://www.dimap.ufrn.br/~jair/ES/c4.html

SILVA, Nelson P. Análise e Estruturas de Sistemas de Informação. 1ª ed. São Paulo: Érica, 2007.