Analise de sistema

SISTEMA DE ENSINO PRESENCIAL CONECTADO curso superior de tecnologia em análise e desenvolvimento de sistemas Produção textual interdisciplinar Garanhuns 2012 xxx Produção textual int orla to view nut*ge Trabalho apresentad Curso Superior de Tecnologia em An de Sistema da UNOPAR • Universidade Norte do Parana, para a produçao textual interdisciplina . Prof. (a): Paulo Nishitani Polyanna P. Gomes Fabris Sergio de Goes Barbosa Anderson Marcedo Marcio Chiaveli Garanhuns, PE SUMÁRIO l. INTRODUÇAO. „ 07 DADOS…. 5 5. PLANO DE 16 6. 9 INTRODUÇÃO…. 16 6. 10 6. 11 ESCOPO… 6. 12 RECURSOS _ 17 6. 3. 3 RECURSOS HUMANOS… 17 5. 13. 4 RECURSOS DO SISTEMA… . 17 6. 13 CUSTOS DO PROJETO. 18 6. 14 CRONOGRAMA DO 6. 15 GERENCIAMENTO DE RISCO… . 6. MODE OS ÁGEIS… 20 7. 16 ESPECIFICAÇÕES DOS MÉTODOS 21 7. 17. 5 .. 21 7. 17. 6 SCRUM . . . . . . . . 22 7. 17. 7 22 7. 17. 8 ASD…. • 22 7. MODELOS EVOLUCIONARIOS 24 8. 17 MODELO INCREMENTAL_. 8. 18 MODELO ESPIRAL.. 25 8. 19 MODELO DE MONTAGEM DE COMPONENTE…. 27 8. 0 MODELO DE DESENVOLVIMENTO CONCORRENTE 8. CONCLUSÃO… 28 9. REFERÊNCIAS BIBLIOGRAFICAS………. . „ 29 7 . INTRODUÇAO. A engenharia de software surgiu para corrigir problemas com elação ao desenvolvimento de projetos de software a partir desse surgimento os modelos de processos e guia de desenvolvimentos foram criados para otimização do desenvolvimento do software. Tanto a nível funcional quanto de dados, é um requisito fundamental para a obtenção de produtos de software de maior qualidade e confiabilidade.

Entretanto, percebe-se que cada vez menos profissionais têm dado a atenção devida ao processo de construção de modelos de suas aplicações. Isso provavelmente se deve às pressões por sistemas em prazos cada vez mais curtos e com menores custos e produção mas, por outro lado, acaba por prejudicar muito entendimento correto do problema e, consequentemente, a construção do sistema que atenda às reais expectativas do usuário.

Esta situação muitas vezes leva a sistemas de baixa qualidade, com elevada necessidade de modificação e de difícil manutenção. 2. DESENVO VIMENTO 3. Documentação de Caso de uso. Este documento mostra u dos requisitos do sistema PAGF RESPONSABILIDADE I USUARIO I Fornece os dados necessários para o cadastro de Alunos. * Abre o sistema. * Cadastra o aluno. * Envia os dados para validação. Emite o recibo de matricula. I SISTEMA Valida os dados cadastrados pelo usuário para posterior impressão do recibo de matricula. Valida dados. I 4. 2 TABELAS DE CASO DE USO A) UCOI -ABRIR SISTEMA Numero do Caso de uso I UCOI I Nome do Caso de Uso ABRIR SISTEMA I USUARIO USUARIO I Pre-condição I Sistema Instalado I Fluxo normal I Acessa a pagina de cadastro Fluxo alternativo Não há I Pós-Condição I Não há B) UC02 – CADASTRAR ALUNO Numero do Caso de uso I UC02 1 Nome do Caso de Uso CADASTRAR ALUNO I Ator principal I USUARIO I Pre-condição I Possuir CPFSolicitar os dados do aluno

Fluxo normal I Cadastrar os dados do aluno Fluxo alternativo Se existir o CPF do Aluno, renovar matricula I Pós-Condição I Preencher todos os dados solicitados I C) UC03 ENVIAR DADOS Numero do Caso de uso I UC03 1 Nome do Caso de Uso ENVIAR DADOS Pre-condição I Os campos obrigatórios foram preenchidos Fluxo normal I Enviar dados para o sistema Fluxo alternativo Se algum campo nao for aceito, retornar para o UC03.

Pós-condi«ol Não há Principal USUARIO Pre-condlção I Não há Fluxo normal I Emitir recibo de matricula do aluno Pós-Condição I Recibo emitido com sucesso 4. ÉCNICAS DE MODELAGEM. 5. 3 entidade Tudo que pode ser definido como uma informação no aspecto real ou abstrata pode ser definida como uma entidade cujo informação é de interesse para o sistema. Ex. nome, placa, tlpo. 5. 4 RELACIONAMENTO Quando existe ocorrência entre entidade, devemos definir quem se relaciona com quem.

Neste caso, podemos usar o modelo E-R, que é representado por losango com o nome do relacionamento escrito em no seu interior. Relacionamento FIGURA 02 – Exemplo de Relacionamento E-R Existem três tipos de relacionamento para especificas as ocorrências entre entidades. *1 Relação 1:1 – um para um – Apenas uma entidade A se relaciona apenas com uma entidade B. – Relacionamento E-R – 1:1 FIGURA 03 um esclarecimento do uso, no levantamento dos dados podemos questionar de maneira simples o relacionamento existente.

Ex. Um setor quantos funcionários… – no minimo 1 e no máximo N. Ex. Um funcionário está trabalhando em quantos setores… no mínimo 1 e no máximo 1 No resultado final do relacionamento encontramos I:N. 5. 7 Administrador de Banco de dados É responsavel pela organização, manutenção e gerenciamento de dados de forma a atender as necessidades de acesso. Este profissional deve ter a habilidade de projetar, atualizar e protege os dados contidos no sistema.

Este profissional dedicar-se mais a segurança dos dados em si, (acessos indevidos, perdas, arquivos corrompidos) do que aos meios ffsicos onde estes estão armazenados e acessados. Dentre as principais características deste profissional, está: a) Agilidade na transferência de dados; b) Replicação de dados; c) Manter o banco de dados e assegurando a sua disponibilidade para os usuários; d) Controlando privilégios e permissões para os usuários do banco de dados; ) Desempenho do banco de dados de acompanhamento; f) Backup e restauração de dados; g) Segurança dos dados. . 8 Modelagem de projetos de banco de dados. A modelagem de banco de dados usa aplicações teóricas e práticas, objetivando construlr um modelo de dados que diminua os riscos de inconsistência, de redundância e que seja compatível com qualquer SGBD. Este recurso permite fazer um esboço do sistema, definindo todas as entidades e está divido em três partes: identificação de todas as entidades e relacionamentos entre eles.

Neste diagrama pode-se compreender como o banco de dados erá elaborado. Figura 06 – Exemplo do diagrama conceitual de dados. 5. 9. 2 modelo Lógico de dados Diferentemente do modelo conceitual, este já tem algumas limitações como padrões e nomenclaturas e deve ser criado levando em consideração o que foi feito no modelo anterior. Neste são criadas as chaves primárias e estrangeiras. Figura 07 – Exemplo de modelo conceitual de dados. 5. plano de Projeto 6. INTRODUÇAO Este projeto irá mostrar de uma maneira detalhada o desenvolvimento do sistema de gerenciamento para uma empresa de servlços em informática, para automatização das tividades internas corriqueiras tais como: cadastro de clientes, cadastro de equipamento, cadastro de funcionários, cadastro de peças, controle de entrada e saída de equipamentos. 6. 10 OBJETIVO Este projeto tem como objetivo abordar as situações que a empresa precisa automatizar.

Para acompanhar todo o cronograma o gerente terá detalhadamente todos os passos de como agir, definindo funções e responsabilidade, estipulando metas, definindo horários. O projeto em si terá uma série de vantagens em relação à organização de tempo num determinado período, porém, poderão ocorrer diversos contra tempo que ode fugir controle das m Estudante 01 | GERENTE I * Supervisiona o projeto * Analisa o projeto se está sendo desviado ‘k Analisa o tempo no cronograma * Modelagem * Codificação * Testes Estudante 02 | DESENVOLVEDOR I Elaboração do Documento de requisitos * Modelagem * Codificação *Teste 5. . 2 recuRSOS DO SISTEMA A) Hardware Computadores Acesso a internet B) software Sistema Operacional Linux NetBeans 6. 9. I MySQL 5. 1 Br Oficce OpenProj TortoiseSVN 1. 6. 1 5. 4 CUSTOS No geral não haverá custos para o projeto. Serão usadas as instalações da própria faculdade – POLO e os softwares são free. Os computadores serão dos próprios integrantes da equipe. 5. 5 CRONOGRAMA DO PROJETO O projeto terá as seguintes fases: * Estudo e Levantamento dos requisitos. k Planejamento do projeto, definição de funções. * Modelagem e diagramas. * Testes. * Entrega do sistema e i ferramenta NetBeans. Estudar a linguagem no tempo livre. 6. Modelos ágeis A partir da década de 90, começaram a surgir novos métodos sugerindo uma abordagem de desenvolvimento ágil onde os processos adotados tentam se adaptar às mudanças, apoiando a equipe de desenvolvimento no seu trabalho (BECK, eta al. 2001).

Estes novos métodos surgiram como uma reação aos métodos tradicionais de desenvolvimento de sistemas, ganhando com o passar dos anos um número cada vez maior de adeptos. Engenharia de software ágil combina a filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfação de cliente e a entrega incremental de software logo de inicio; isso envolve equipes pequenas, altamente motivadas; métodos informais; produto de engenharia de software mínimo e simplicidade global do desenvolvimento.

A “indústria do software” sempre contou com métodos cujos rocessos de desenvolvimento eram baseados em um conjunto de atividades predefinidas, descrltas como processos prescritivos (AMBLER 2004), onde muitas vezes, o trabalho começava com o levantamento completo de um conjunto de requisitos, seguido por um projeto de alto-nível, de uma implementação, de uma validação e, por fim, de uma manutenção (SOM MERVILLE 2003).

Com o intuito de definir um manifesto para encorajar melhores meios de desenvolver sistemas, em fevereiro de 2001 um grupo inicial de 17 metodologistas, entre eles, Robert C. Martin, Jim Highsmith, Kent Beck e outros, formou a Aliança para Desenvolvimento Ágil de Softw’are, que formulou um manifesto contendo um conjunto de princípios que definem critérios para os processos de desenvolvimento ágil de sistemas (AMBLER, 2004). os doze princípios (BECK, et. al. 001), aos quais os métodos ágeis devem se ade uar são: devem se adequar são: A prior idade é satisfazer ao cliente através de entregas continuas e frequentes; a) Receber bem as mudanças de requisitos, mesmo em uma fase avançada do projeto; b) Entregas com freqüência, sempre na menor escala de tempo; c) As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente; ) Manter uma equipe motivada fornecendo ambiente, apoio e confiança necessários; e) A maneira mais eficiente da Informação circular através de uma conversa face-a-face; f) Ter o sistema funcionando é a melhor medida de progresso; g) Processos ágeis promovem o desenvolvimento sustentável; h) Atenção continua a excelência técnica e a um bom projeto aumentam a agilidade; i) Simplicidade é essencial; j) As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas; k) Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz.

Com base nos princípios descritos acima, cada um dos métodos ?geis – incluindo os utilizados nesta comparação – apresenta um conjunto de atividades a serem adotadas durante o processo de desenvolvimento do sistema. É com base nestas atividades que é realizada a comparação apresentada neste trabalho. importante mencionar que antes de iniciar a comparação propriamente dita entre os métodos foi realizado um estudo detalhado de cada um dos quatro métodos (XP, Scrum, FDD e ASD). 7. 1 ESPECIFICAÇÃO DOS MÉTODOS ÁGEIS 7. 2. 1 XP A definição preliminar dos re uisitos é feita a partir da escrita das user stories pelos clie stories são descrições

Leave a Reply:

O seu endereço de email não será publicado. Campos obrigatórios marcados com *