SISTEMA DE ENSINO PRESENCIAL CONECTADO ANLISE E DESENVOLVIMENTO DE SISTEMAS WLADMIR MORENO OLIVEIRA

TTULO DO TRABALHO:
2 Semestre do curso Anlise e Desenvolvimento de Sistemas

Sete Lagoas - MG 2011

WLADMIR MORENO OLIVEIRA

TTULO DO TRABALHO:
2 Semestre do curso Anlise e Desenvolvimento de Sistemas

Trabalho apresentado as disciplina do 2 Semestre do curso Anlise e Desenvolvimento de Sistemas da Universidade Norte do Paran - UNOPAR

Professores: Fbio Zanellato Luis Claudio Perini Roberto Nishimura Simone Tanaka

Sete Lagoas - MG 2011

SUMRIO

1 INTRODUO......................................................................................3

INTRODUO Esse portflio tem como objetivo

aprimorar o conhecimento obtido no curso Anlise e Desenvolvimento de Sistemas referente ao 2 semestre do curso, no qual so estudadas as disciplinas Engenharia de software, Banco de dados e Linguagens e Tcnicas de Programao, partindo de uma demonstrao de caso de uso ilustrado com uma imagem de diagrama, passando por alguns conceitos de bancos de dados como entidade e relacionamento, sendo encerrado com modelos de processos, explicando um pouco sobre processo gil e evolutivo, onde estaremos demonstrando os mais conhecidos e suas principais caractersticas.

2. Documentao do caso de uso Nesse diagrama Controlar matricula, teremos a seguinte situao um aluno quer se matricular em uma escola para estudar, que poder ser feita de duas maneiras. Ele pode fazer pelo site da instituio ou poder fazer pessoalmente atravs de um atendente. Como veremos no diagrama seguinte seguido do detalhamento de cada ao de quem faz o que. 2.1 Imagens do diagrama

2.2 Descries do caso de uso Nmero do caso de UC 001 uso Nome do caso de Registrar matrcula. uso Atores Aluno, atendente. Descrio Esse caso de uso e responsvel por registrar o aluno, onde solicita a verificao se o aluno j cadastrado para prosseguir. Pr-condio No h Ps-condio S far o cadastro se o aluno no for cadastrado. Cenrio principal 1. O sistema verifica se o aluno esta matriculado. 1. Ele esta matriculado. 2. O sistema lhe oferta a opo de mais um curso. 2. Ele no matriculado 3. Efetua o registro. Cenrio alternativo Excees Includes Extend Regra de negcios No h No h Uc 002- verifica se o aluno matriculado. Uc 004 escolhe o curso. No h No h

Nmero do caso de Uc 002 uso Nome do caso de Verificar se o aluno matriculado. uso Atores Atendente, aluno. Descrio Esse caso de uso e responsvel pela verificao se o aluno j matriculado em algum curso. Pr-condio Ter iniciado o uc 001 Ps-condio No h Cenrio principal 1.verifica se o aluno matriculado. 2. Aluno matriculado. 2.1 Envia uma mensagem como o aluno esta matriculado em determinado curso. 2.2 Lhe oferece uma lista de outros curso para se matricular. 3. Aluno no matriculado. 3.1 Lhe oferece uma lista de curso para se matricular. 4. Retorna ao caso de uso 001 para efetua a matricula

Cenrio alternativo Excees Includes Extend Regra de negcios

No h No h No h Uc003 Escolher mais um curso No h

Nmero do caso de Uc 003 uso Nome do caso de Escolher mais um curso uso Atores Aluno, atendente Descrio Esse caso de uso fica responsvel por ofertar os cursos adicionais. Pr-condio Se o aluno estiver matriculado em algum curso. Ps-condio Ter escolhido um curso Cenrio principal 1.listar os cursos ofertado 2.O aluno escolhe o curso. 3. Retorna para o uc001 para completar o registro. Cenrio alternativo No h Excees No h Includes No h Extend No h Regra de negcios No h Nmero do caso de Uc004 uso Nome do caso de Escolher o curso uso Atores Aluno, atendente Descrio Fica responsvel por listar os cursos ofertados. Pr-condio No h Ps-condio Ter escolhido um curso Cenrio principal 1.O sistema lista os cursos oferecidos 1.1 escolher o curso desejado 2. Retorna para registrar a matrcula. Cenrio alternativo No h Excees No h Includes No h Extend No h Regra de negcios No h Nmero do caso de Uc005 uso Nome do caso de Excluir matrcula uso Atores Aluno, atendente Descrio Esse caso de uso fica responsvel por efetuar e excluso da matrcula.

Pr-condio Ps-condio Cenrio principal

Estar matriculado No h 1. Aciona o caso de uso 002 1.1 Lista os cursos 1.2 Seleciona o curso 2. Executa a excluso.

Cenrio alternativo Excees Includes Extend Regra de negcios

No h No h Uc 002 verificar se o aluno matriculado. No h No h

3. Conceitos de banco de dados 3.1Entidade Entidade pode ser entendida como uma coisa ou algo da realidade modelada onde se deseja manter informaes no banco de dados (BD). Por exemplo, em um sistema escolar, algumas entidades podem ser os alunos, professores, horrio, disciplinas e avaliaes. 3.2 Relacionamento O relacionamento existe quando um ou mais dados de uma tabela esto relacionados de alguma forma com um ou mais dados de outra tabela. Por exemplo, temos uma tabela d usurios (users) e uma tabela de posts (posts), cada usurio pode publicar infinitos posts porm cada post poder ter apenas um usurio. Estas tabelas esto relacionadas. Existe tambm relacionamento de dados de uma tabela com outros dados desta mesma tabela. Um usurio (user) pode ter vrios amigos da mesma tabela (user), ento os dados esto relacionados com dados da mesma tabela. 3.3 Atributos Um atributo tudo o que se pode relacionar como propriedade da entidade. (coluna , campo , etc,..). Exemplos de atributos: Cdigo do Produto (Entidade Produto) , Nome do Cliente (Entidade Cliente). 3.4 Modelos conceituais

Representa as regras de negcio sem limitaes tecnolgicas ou de implementao por isto a etapa mais adequada para o envolvimento do usurio que no precisa ter conhecimentos tcnicos. Neste modelo temos: Viso Geral do negcio, Facilitao do entendimento entre usurios e desenvolvedores, Possui somente as entidades e atributos principais Pode conter relacionamentos n para m. 3.5 Modelos Lgicos Leva em conta limites imposto por algum tipo de tecnologia de banco de dados. (banco de dados hierrquico, banco de dados relacional, etc.). Suas caractersticas so: Deriva do modelo conceitual e via a representao do negcio. Possui entidades associativas em lugar de relacionamentos n:m. 3.6 Modelos Fsicos Leva em considerao limites imposto pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos no funcionais dos programas que acessam os dados. Caractersticas: Elaborado a partir do modelo lgico Pode variar segundo o SGBD Pode ter tabelas fsicas (log , lider , etc.) Pode ter colunas fsicas (replicao) 3.7 Administrador de bancos de dados O administrador de bancos de dados (DBA) executa uma funo estratgica na empresa, considerando que o maior bem de uma organizao hoje so os dados, que esto sobre sua gerncia. Para se entender o tamanho da responsabilidade do DBA com os dados da organizao, perdas ocasionais de dados, dependendo de seu volume e importncia, podem causar srios prejuzos empresa e inclusive lev-la falncia. 3.8 a escolha do projeto. Para esse tipo de projeto, o qual estamos nos referindo ao item um, que foi criado um caso de uso controlar

matrcula, onde o usurio pode ter acesso pela internet ou presencial. O ideal usar um sistema web. Hoje temos no mercado uma ferramenta poderosa que o visual estdio da Microsoft no qual tem suporte para a linguagem Asp.net .podendo ser criado uma aplicao de altssimo nvel no qual fica hospedado em um servidor e pode ser acessado via browser com segurana e confiabilidade, definindo o nvel de acesso de cada usurio. 4. Engenharia de Software 4.1 Modelos evolucionrios Modelo incremental Este modelo uma extenso do modelo espiral sendo, porm mais formal e rigoroso. O desenvolvimento de um produto comercial de software uma grande tarefa que pode ser estendida por vrios meses, possivelmente um ano ou mais. Por isso, mais prtico dividir o trabalho em partes menores ou iteraes. Cada iterao resultar num incremento. Iteraes so passos em fluxo de trabalho e incrementos so crescimentos do produto. O princpio subjacente ao processo incremental e iterativo que a equipe envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e mbito do sistema envolvido. Por exemplo, numa primeira iterao deve-se identificar a viso global e determinar a viabilidade econmica do sistema, efetuar a maior parte da anlis e e um pouco de desenho e implementao. Numa segunda gerao, deve-se concluir a anlise, fazer uma parte significativa do desenho e um pouco mais de implementao. Numa terceira iterao, deve-se concluir o desenho, fazerse parte substancial da implementao, testar e integrar um pouco, etc. Ou seja, a principal consequncia da aproximao iterativa que os produtos finais de todo o processo vo sendo amadurecidos e completados ao longo do tempo, mas cada iterao produz sempre um conjunto de produtos finais. A cada iterao so realizadas as seguintes tarefas: Anlise. Refinamento de requisitos, refinamento do modelo conceitual. Projeto. Refinamento do projeto arquitetural, projeto de

10

baixo nvel. Implementao. Codificao e testes. Transio para produto. Documentao, instalao... Vantagens do processo incremental e iterativo: Possibilidade de avaliar mais cedo os riscos e pontos crticos do projeto, e identificar medidas para elimin-los ou controlar. Reduo dos riscos envolvendo custos a um nico incremento. Se a equipe que desenvolve o software precisar repetir a iterao, a organizao perde somente o esforo mal direcionado de uma iterao, no o valor de um produto inteiro. Definio de uma arquitetura que melhor possa orientar todo o desenvolvimento. Disponibilizao natural de um conjunto de regras para melhor controlar os inevitveis pedidos de alteraes futuras. Permite que os vrios intervenientes possam trabalhar mais efetivamente pela interao e partilha de comunicao da resultante. Modelo espiral O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vrios conjuntos de fases se sucedem at se obter o sistema final. Um ciclo se inicia com a determinao de objetivos, alternativas e restries (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa, anlise e avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise de risco. Prototipao uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitvel, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto avaliado e se prepara para iniciar um novo ciclo. Variaes do modelo espiral consideram entre trs e seis tarefas ou setores da espiral, que podem ser: Comunicao com o cliente; Planejamento;

11

Anlise de risco; Engenharia; Construo e liberao; Avaliao do cliente. O modelo espiral , atualmente a abordagem mais realstica para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o servio, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considervel experincia na determinao de riscos e depende dessa experincia para ter sucesso. Vantagens deste modelo: O modelo em espiral permite que ao longo de cada iterao se obtenham verses do sistema cada vez mais completas, recorrendo prototipagem para reduzir os riscos. Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realstica, o processo de desenvolvimento. Desvantagens: Pode ser difcil convencer grandes clientes (particularmente em situaes de contrato) de que a abordagem evolutiva controlvel. A abordagem deste tipo de modelo exige considervel experincia na avaliao dos riscos e baseia-se nessa experincia para o sucesso. Se um grande risco no for descoberto, podero ocorrer problemas. Este tipo de modelo relativamente novo e no tem sido amplamente usado. importante ter em conta que podem existir diferenas entre o prottipo e o sistema final. O prottipo pode no cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido. O modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso necessrio o uso de tcnicas especficas para estimar e sincronizar cronogramas, bem como para determinar os

12

indicadores de custo e progresso mais adequados. Modelo espiral ganha-ganha As melhores noegociaes buscam um resultado ganhaganha. Isto , o cliente ganha obtendo um produto ou sistema que satisfaz maior parte das necessidades do cliente, e o desenvolvedor ganha trabalhando com oramentos e prazos de entrega realsticos e possveis de serem cumpridos. O modelo espiral ganha-ganha define um conjunto de atividades de negocia o no comeo de cada passagem, em torno da espiral. Ao invs de uma nica atividade de comunicao com o cliente,as seguintes atividades so definidas: Identificao dos principais interessados do sistema ou do subsistema. Determinao das condies de lucro do interessado. Negociao das condies de ganho do interessado para reconcili-las no mbito das condies ganha-ganha para todos os envolvidos. Alm da nfase na negociao inicial, o modelo espiral ganha-ganha introduz trs marcos de processo, chamados pontos de ancoragem, que ajudam a estabelecer quendo um ciclo completado em torno da espiral e fornecem marcos de deciso antes do projeto de software presseguir. Esses pontos de ancoragem so: Objetivos de ciclo de vida (life cycle objectives, LCO). Define um conjunto de objetivos para cada atividade principal. Arquitetura do ciclo de vida (life cycle architecture, LCA). Estabelece objetivos que precisam ser satisfeitos, medida que a arquitetura do sistema, e do software, definida. Capacidade operacional inicial (initial operational capability, IOC). Representa um conjunto de objetivos associado com a preparao do software para instalao e distribuio. Modelo de desenvolvimento concorrente O modelo de desenvolvimento concorrente representado como uma srie de grandes atividades

13

tcnicas, tarefas e seus estados associados. Ele define uma srie de eventos que podem disparar transies de um estado para outro, para cada uma das atividades da engenharia de software. freqentemente usado como um paradigma para o desenvolvimento de aplicaes Cliente/Servidor. Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma viso exata de como est o estado do projeto. Desenvolvimento baseado em componentes O desenvolvimento baseado em componentes incorpora caractersticas de tecnologias orientadas a objetos no modelo espiral. A atividade de engenharia comea com a identificao de classes candidatas. Se a classe existe, ela ser reutilizada. Se a classe no existe, ela ser desenvolvida nos moldes do paradigma de orientao a objetos. Modelo de mtodos formais O modelo de mtodos formais compreende um conjunto de atividades que determinam uma especificao matemtica para o software. Uma variante dessa abordagem denominada engenharia de software cleanroon (Sala Simpa). Utilizando mtodos formais eliminam-se muitos problemas encontrados nos outros modelos, como p.ex., ambigidade, incompletitude e inconsistncia, que podem ser corrigidas mais facilmente de forma no ad hoc, mas atravs de anlise matemtica. 4.2 Modelos geis 13 Ecrum No Scrum, os projetos so dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias geis de desenvolvimento de software so iterativas, ou seja, o trabalho dividido em iteraes, que so chamadas de Sprints no caso do Scrum. As funcionalidades a serem implementadas em um projeto so mantidas em uma lista que conhecida como Product Backlog. No incio de cada Sprint, faz-se um

14

Sprint Planning Meeting, ou seja, uma reunio de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela ser capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint so transferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunio (normalmente de manh), chamada Daily Scrum. O objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do prximo Sprint. Assim reinicia-se o ciclo

XP Extreme Programming (XP) uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da dcada de 90. Vem fazendo sucesso em diversos pases, por ajudar a criar sistemas de melhor qualidade, que so produzidos em menos tempo e de forma mais econmica que o habitual. Tais objetivos so alcanados atravs de um pequeno conjunto de valores, princpios e prticas, que diferem substancialmente da forma tradicional de se desenvolver software. Por se tratar de uma programao extrema o XP no deve ser aplicado a qualquer tipo de projeto. O grupo de desenvolvedores deve formar uma equipe de 2 a 10 integrantes, que devem estar por dentro de todas as fases do desenvolvimento. necessrio realizar vrios testes, s vezes, alterar o projeto em decorrncia destes. A equipe tem de ser bastante interessada e pr-ativa, para assegurar a alta produtividade, e o cliente deve estar sempre disponvel para tirar dvidas e tomar decises em relao ao projeto, porm uma boa opo pois a incluso do Extreme Programming no dia a dia do desenvolvimento de software enriquece a comunidade de programao independente do segmento das empresas nos quais os profissionais desempenham suas atividades, garantindo a evoluo dos negcios e garantindo dinamismo na economia atual. MSDM

15

A DSDM fornece uma framework para uma abordagem interativa e incremental de desenvolvimento de Sistemas de Informao (SI). Desenvolveu-se nos anos 90 na Inglaterra e foi aplicado pela primeira vez em 1995. Esta metodologia foi desenvolvida por um consrcio de vendedores e peritos no campo dos Sistemas de Informao, no qual partilharam e combinaram as suas melhores tcnicas. Assim, a DSDM surge como uma extenso do RAD (Rapid Application Development), focada em projetos de Sistemas de Informao caracterizados por prazos e oramentos apertados. A DSDM aborda os problemas que freqentemente ocorrem no desenvolvimento de informao que se prendem essencialmente com a falta de tempo, com oramentos mais apertados ou com outro tipo de razes para que o projeto falhe, tal como a falta de envolvimento dos encarregados do projeto ou dos utilizadores finais. A DSDM segue alguns princpios chave. Estes princpios delimitam as bases do desenvolvimento utilizando DSDM. O ponto fundamental desta metodologia prende-se com a entrega de um sistema que se aproxime das atuais necessidades de negcio. No uma metodologia to direta que fornea todas as necessidades de negcio, mas centraliza todo o potencial na concretizao final de todos os objetivo do projeto. Nenhum sistema completamente construdo na primeira tentativa. Num processo de desenvolvimento de um sistema informtico 80% da soluo pode ser desenvolvida em 20% do tempo necessrio para encontrar a soluo perfeita. Para aperfeioar a parte final poder ser necessrio que o projeto ultrapasse o seu tempo e oramento estipulados. Uma vez que a DSDM caracterizada por realizar exatamente o que a empresa necessita, muitas vezes desnecessrio chegar soluo perfeita. A entrega do projecto deve ser feita na data estipulada, dentro do oramento previsto e com boa qualidade (Fig. 2). As exigncias para o Sistema de Informao tm que ser flexveis. Tal como falaremos mais tarde, exigncias flexveis so tpicos importantes da DSDM. Esta metodologia apenas requer que cada etapa do desenvolvimento seja completada at que seja possvel iniciar o passo seguinte. Isto faz com que cada fase do projeto possa comear sem ter que esperar que as fases que comearam anteriormente sejam totalmente

16

terminadas. A comunicao entre todas as partes envolvidas (stakeholders) tambm um pr-requisito bastante importante para que o projeto corra com a eficincia desejada. O envolvimento dos utilizadores a chave para esta eficincia. As equipas responsveis tm que ser dotadas de um sentido de deciso, sendo este tambm um ponto fulcral na progresso do projeto. Tal como as equipes de desenvolvimento tambm as equipas de gesto do projeto esto incorporadas na DSDM. Aps o desenvolvimento do Sistema de Informao, a DSDM pode tambm Ser usado para expandir o Sistema obtido. Apesar da utilizao de uma metodologia gil no ser aconselhada para todos os tipos de projeto, a DSDM uma tima e segura base para equipas de desenvolvimento que tm em mos projetos com necessidade de execuo rpida e com requisitos flexveis. A partir desta metodologia, possvel construir um trabalho que agrade ao cliente graas ao cumprimento dos prazos e oramentos equipe de desenvolvimento que ter em mos um projeto organizado e com obrigao de cumprir apenas os requisitos necessrios execuo do sistema e aos utilizadores finais que tero a oportunidade de interagir com todo o desenvolvimento do sistema de informao, atravs das freqentes fases de testes. MSF A MSF foi criado em 1994, e originou-se da anlise de times de projetos e grupo de produtos, estas anlises eram constatadas com a indstria de prticas e mtodos. Estes resultados combinados eram consolidados em melhores praticas entre pessoas e processos. O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu mtodo para desenvolvimento de solues de software dentro da Microsoft e tambm para os milhares de clientes e parceiros da Microsoft em todo o mundo. A disseminao deste mtodo, agora na verso 5.0, normalmente induz as pessoas a compar-lo com outros mtodos da indstria, como o RUP, CMMI ou XP, entre

17

outros. importante entender, entretanto, o que so estes elementos antes de compar-los. O MSF para Desenvolvimento gil de Software um guia de procedimentos, uma coleo de boas prticas para projetos de desenvolvimento de softwares. Um projeto MSF regido por ciclos ou iteraes. A cada ciclo, cada componente da equipe executa suas funes e atualiza o resultado do seu trabalho conforme a necessidade. Os ciclos se repetem at que o projeto seja concludo ou cada verso seja lanada. Cada componente da equipe ser responsvel por um ou mais papis, dependendo do tamanho ou da complexidade do projeto 5. Referncia Tanaka,Simone Sawasaki Anlise de sistema l So Paulo Pearson Prentice Hall,2009 Perini,Luiz Cludio Engenharia de Software:sistema ll / Luiz Cludio Perini,Marco Ikuro,Hisatomi,Wagner Luiz Berto -- So Paulo Pearson Prentice Hall,2009.

PETERS, JAMES F., Engenharia de Software: Teoria e Prtica, Rio de Janeiro, Editora Campus, 2001. Nishimura,Roberto yukio Banco de dados l / Roberto yukio Nishimura -- So Paulo Pearson Prentice Hall, 2009. Arlow, Jim; Neustadt, Ila. UML and the Unified Process: Pratical Object- Oriented Analysis & Design. Great Britain: Addison-Wesley, 2002.