SISTEMA DE ENSINO PRESENCIAL CONECTADO ANALISE E DESENVOLVIMENTO DE SISTEMAS JULIO CESAR OLIVEIRA CORRER

ANALISE DE SISTEMAS I
PRODUO TEXTUAL SOBRE O CONTEUDO TMATICO DA RECUPERAO ANALISE DE SISTEMAS I

Piracicaba 2012

JULIO CESAR DE OLIVERIA CORRER

ANALISE DE SISTEMAS I
PRODUO TEXTUAL SOBRE O CONTEUDO TMATICO DA RECUPERAO ANALISE DE SISTEMAS I

Trabalho apresentado ao Curso Tecnologia em Analise e Desenvolvimento de Sistemas da UNOPAR Universidade Norte do Paran, para a disciplina Analise de Sistemas I. Prof. Polyana P. Gomes Fabris

Piracicaba 2012

INDICE

INTRODUO DESENVOLVIMENTO ENTIDADE RELACIONAMENTO MODELAGEM DE DADOS ENTIDADES ATRIBUTOS MONOVALORADO E MULTIVLOROSA RELACIONAMENTO E CARDINALIDADE RELACIONAMENTO RECURSIVO CARDINALIDADE ADMINISTRADOR DE BANCO DE DADOS XPA OU EXTREMING PROGRAMINS O QUE SCRUM ? RUP MODELO DE PROTOTIPAGEM MODELO ESPIRAL MODELO INCREMENTAL E ITERATIVO DESENVOLVIMENTO DE APLICAO CONCLUSO REFERENCIAS

INTRODUO Programar uma coisa muito complexa, pior ainda desenvolver algo do zero sem nenhum planejamento ou dissertimento da coisa l. Ideias sobre programao, requisitos, e muita viso de um software de consistente, muito mais de implementar software preciso analisar , revercodigos , projetar e solucionar problemas existentes transaparecer o software da forma mais facil ao seu cliente , e ainda depois de tudo isso revisar novamente . Wikipedia A enciclopedia Digital. Diz : Anlise de sistemas a atividade que tem como finalidade a realizao de estudos de processos a fim de encontrar o melhor caminho racional para que a informao possa ser processada. Os analistas de sistemas estudam os diversos sistemas existentes entre hardwares (equipamentos), softwares (programas) e o usurio final. Os seus comportamentos e aplicaes so desenvolvidos a partir de solues que sero padronizadas e transcritas da forma que o computador possa executar Entende-se que quanto mais especializado um sistema mais ele menos ele capacitado a se adptar a circuntancias diferentes . ai que cabe ao analista de sistemas dar dinamisco a coisa. A anlise [de sistemas] frustrante, repleta de relacionamentos entre pessoas, indefinida e difcil. Resumindo, fascinante. Depois que voc fisgado, os velhos e fceis prazeres da construo de sistemas nunca mais sero suficientes para satisfaz-lo Tom DeMarco, Structured Analysis and Systems Specification

DESENVOLVIMENTO So descritos em texto, amplamente utilizadaspara levantar os requisitos de determinada soluo de software. Descreve afuncionalidade de um sistema, deve desempenhar ou exibir, por meio da modelagem do dilogo que um usurio, um sistema externo ou outra entidade ter com o sistema desenvolvido. representado por um diagrama que utilize os conceitos padres da UML. O aluno chega biblioteca e faz seu cadastramento. O bibliotecrio pede os documentos que a escola exige para efetuar seu cadastro no sistema cadastro e comea a alimentar o banco de dados com oas infomaes desejadas. O sistema faz um consulta rapida se o usuario j tem cadastro se no tiver ele prossegue com o cadastro. O funcionario faz a impresso de duas vias. O aluno fica com uma e rubrica a outra bibliotecrio armazena a outra . O sistema o sistemas automaticamente tem sua consulta, edio, bloqueio e excluso de dados cadastrais. Sintaxe do Diagrama: Atores: Alunos e Funcionario Inercia do Sistema: Alunos - Cadastrar-se e Locar livros Funcionario Efetuar o cadastro rapido e eficiente do aluno e para gesto e controle tanto dos livros como do cadastro de alunos Analise 1 Funcionario logado no sistema Analise 2 Funcionario cadastrar todos os dados do aluno no sistema para fins de controle de entrada e saida. Descrio : Principal Cadastrar: 1)O Funcionario pede novo cadastro, aps checar documentos obrigatrios. 2)O sistema solicita entrada de dados (RA do Aluno).3)O sistema checa, atravs do RA, base de dados interna de outro programa procura se o cadastro j existe. 4) O sistema pede entrada de mais dados (nome, endereo, CPF, RG, ,curso, email,telefone). 5)O sistema valida e confirma o cadastramento.6)O Funcionario

gera e imprimi, em duas vias, aguia de cadastro;7)) aluno assina e entrega uma via ao funcionario.8)O bibliotecrio grava e o sistema arquiva no cadastro. Excees cadastrar: 1) Aluno com pendncias na biblioteca. 2) Sistema avisa que existem pendncias na biblioteca. 3)bibliotecrio solicita impresso das pendncias. 4)Sistema gera relatrio e imprimi. 5)sistema salva estado do cadastro at que pendncia seja resolvida. Fluxo de confirmao principal consultar-alterar 1)O bibliotecrio inicia a consulta. 2) O bibliotecrio entra com NOME ou CPF. 3)O sistema procura o registro. 4)O funcionario seleciona o registro. 5)O sistema carrega na tela os dados 6)O funcionario edita as informaes. 7)O sistema grava. Fluxo de no cadastrado: 1) No cadastrado: sistema avisa que no h registro de cadastro. 2) sistema pergunta se deseja cadastrar 3) sistema chama mdulo de cadastro Fluxo de confirmao principal consultar-excluir: 1) Funcionario inicia a consulta 2)O Funcionario entra com NOME ou CPF 3)O sistema procura o registro. 4) O Funcionario seleciona o registro. 5) O sistema carrega na tela os dados. 6)O Funcionario solicita excluso. 7)O sistema pede confirmao para excluso. 7) O bibliotecrio confirma. 8)Sistema realiza a excluso. Fluxo de excees consultar-excluir: 1)No cadastrado.2)Sistema avisa que no h registro de cadastro. 3)Sistema pergunta se deseja cadastrar. 4) Sistema chama mdulo de cadastro Fluxo de confirmao principal consultar-excluir: 1)Funcionario inicia a consulta; 2) Funcionario entra com NOME ou CPF. 3) o sistema procura o registro 4) Funcionario seleciona o registro. 5) Ssistema carrega na tela os ados 6) Funcionario solicita bloqueio. 7) Sistema solicita o motivo; 8) Funcionario informa e confirma bloqueio 9)O sistema realiza o bloqueio. Fluxo de excees consultar-bloquear: 1)Registro no encontrado. 2) Sistema avisa que no h registro de cadastro.3) Sistema pergunta se deseja cadastrar 4)Sistema chama mdulo de cadastro;

ENTIDADE E RELACIONAMENTO (MER) Ela permite fazer um modelo conceitual dos dados do mundo real que estamosanalisando. Seu criador, Peter Chen, elaborou a tcnica no ano de 1976, que foiadaptada positivamente ao passar dos anos. O MER (Modelo EntidadeRelacionamento), baseia-se na idia de que o mundo real consiste de entidades ede relacionamentos entre essas entidades. MODELAGEM DE DADOS Quando pretendemos desenvolver aplicaes que usam banco dedados relacionais devemos possuir os conceitos bsicos sobre modelagem dedados. No importa se a aplicao muito simples; a correta modelagem dos seus dados ir com certeza tornar sua aplicao mais robusta e mais fcil de manter.Os

objetivos principais da modelagem de dados so: a) Representar o ambiente observado; b) Documentar e normalizar; c) Fornecer processos de validao; d) Observar processos de relacionamentos entre objetos. Modelar implica em construir. Modelo conceitual - Representa as regras de negcio semlimitaes tecnolgicas ou de implementao, por isto a etapa mais adequadapara o envolvimento do usurio que no precisa ter conhecimentos tcnicos. Neste modelo temos : a) Viso Geral do negcio; b) Facilitao do entendimento entre usurios e desenvolvedores; c) Possui somente as entidades e atributos principais; d) Pode conter relacionamentos n para m. Modelo Lgico - Abordam limites impostos por algum tipo detecnologia de banco de dados (banco de dados hierrquico, banco de dadosrelacional ,etc.). Suas caractersticas so : a)Deriva do modelo conceitual e via a representao do negcio; b) Possui entidades associativas em lugar de relacionamentosn:m; c) Define as chaves primrias das entidades; d) Normalizao at a 3 forma normal; e) Adequao ao padro de nomenclatura; f) Entidades e atributos documentados. Modelo Fsico - Leva em considerao limites impostos peloSGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos no funcionaisdos programas que acessam os dados Caractersticas: a) Elaborado a partir do modelo lgico; b) Pode variar segundo o SGBD; c) Pode ter tabelas fsicas (log , lider , etc.); d) Pode ter colunas fsicas (replicao).

ENTIDADES So representaes abstratas de alguma coisa do mundo real. Porexemplo: a placa de um carro, o nmero de um pedido num restaurante, o JosRibamar funcionrio da empresa, a disciplina de Cincias de uma escola, todos so entidades, que podem ser concretas, conceituais, fatos e etc.Ao agrupamento de entidades afins, damos o nome de Conjunto deEntidades. Por exemplo: todos os veculos ou todos os funcionrios da empresa. muito importante saber que no MER, s se representam os Conjuntos de Entidades e nunca entidades individuais. Ainda, s merecem representao os conjuntos de entidades do mundo real que contenham dados de interessa da organizao. Durante o processo de modelagem costuma-se conceituar cada conjunto de entidades de modo a definir claramente todas as entidades que possam pertencer quele conjunto. Exemplo: Veculo: conjunto que engloba todos os meios de transporte de propriedade da empresa. ATRIBUTOS Para cada conjunto de entidades do modelo, guardam-se algumasinformaes pertinentes relacionadas aos seus elementos. Isto feito atravs dos atributos. Exemplo: Veculo = (Placa + Marca + Cor + Dataaquisio +Quilometragem) ou Aluno = (Matrcula + Nome do Aluno + Data da Matrcula). Nomes de atributos so diferentes de valores de atributos, porexemplo, Marca, o nome, enquanto Ford, GM ou Fiat, so os valores do atributo. Um atributo s pode aparecer numa nica entidade do modelo. Todavia,nada impede que atributos de entidades diferentes tenham mesmo nome, embora representando informaes diferentes. Por exemplo, o atributo Nome pode aparecer na entidade. Cliente onde ele indica nome do cliente, e pode tambm estarna entidade Funcionrio, onde ele significa nome do funcionrio. Existem tipod de atributos de mode que se separam de duas formas compostos e simples tambm conhecidos como atomicos Atributos compostos podem ser divididos em subpartes menores,que representam a maioria de atributos bsicos com significados diferentes. Porexemplo, em uma entidade empregado, temos um atributo endereo que pode ser subdividido em EnderecoRua, Cidade, Estado, CEP. Os atributos que no permitem subdivises so conhecidos como atributos :

- Os atributoscompostos podem formar uma hierarquia, exemplo: EnderecoRua, pode sersubdividido em trs - Simples (Atomicos) (Rua, Nmero e Apartamento) MONOVALORADOS E MULTIVALORADOSA maioria dos atributos tem um valor nico para uma determinadaentidade, so denominados monovalorados. Exemplo: Idade um atributomonovalorado de uma pessoa.Atributos multivalorados so aqueles que tm maisde um valor. Exemplo: Titulao, pois uma pessoa pode ser graduada em dois oumais cursos. Atributos multivalorados devem ter limite inferior e superior pararestringir o nmero de valores permitidos a cada entidade individual. RELACIONAMENTOS E CARDINALIDADE Assim como as entidades, os relacionamentos desempenham papelimportante no MER. Eles acontecem quando um atributo de determinada tabela serelaciona com outra entidade. Por exemplo, o atributo Gerente, de Departamento,corresponde ao funcionrio que gerencia o departamento; o atributoDepartamentoControle, de Projeto, diz respeito ao departamento que controla oprojeto; o atributo Supervisor, de Empregado, refere-se a outro empregado (aqueleque supervisiona esse empregado); o atributo Departamento, de Empregado,corresponde ao departamento no qual o empregado trabalha, e assimsucessivamente. GRAU DE RELACIONAMENTO O grau de um tipo de relacionamento o nmero de entidades queparticipam desse relacionamento. Temos o grau binrio (2 relacionamentos) eternrio (3). Podemos encontrar relacionamentos de mais graus, mas os maiscomuns so os binrios. Um exemplo de relacionamento de grau ternrio:

RELACIONAMENTO RECURSIVO Cada tipo de entidade que participa de um relacionamento executaum papel particular no mesmo. O nome de papel significa o papel que uma entidadeexecuta em cada instncia de relacionamento, e ajuda a explicar o significado dorelacionamento. Quando determinada entidade participa mais de uma vez em umtipo de relacionamento em papis diferentes, temos o relacionamento recursivo.Exemplo de relacionamento recursivo abaixo.

O tipo relacionamento Superviso relaciona um empregado a umsupervisor, no qual ambas as entidades, empregado e supervisor, so membros domesmo tipo entidade Empregado. Assim, o tipo entidade Empregado participa duasvezes em Superviso: uma no papel de supervisor (ou chefe), e outro, no papel de supervisionado. CARDINALIDADE So restries impostas para limitar as possibilidades decombinaes de entidades que podem participar do conjunto de relacionamentoscorrespondente. Se por exemplo, numa empresa, existe uma regra onde diz quecada empregado tem de trabalhar exatamente para um departamento, teramosportanto, de descrever essa restrio no esquema. Temos dois tipos principais derestries. A Cardinalidade para Relacionamentos Binarios especifica o nmero mximo de instncias de relacionamento emque uma entidade pode participar. As razes possveis para esse tipo de cardinalidade so: 1:1 1:N N:1 M:N. Onde N representa qualquer nmero deentidades relacionadas (zero ou mais). Determina se a existncia de uma entidade depende de sua existncia relacionada outra entidade, pelo tipo relacionamento. Essa restriodetermina o nmero mnimo de instncias de relacionamento em que cada entidadepode participar. H dois tipos de restries de participao: total e parcial.

ADMINISTRADOR DE BANCO DE DADOS (DBA) O administrador de bancos de dados (DBA) executa uma funoestratgica na empresa, considerando que o maior bem de uma organizao hojeso os dados, que esto sobre sua gerncia. Para se entender o tamanho daresponsabilidade do DBA com os dados da organizao, perdas ocasionais dedados, dependendo de seu volume e importncia, podem causar srios prejuzos empresa e inclusive lev-la falncia. Podemos resumir sua atuao em 3 grandes grupos e breves descries (as atribuies dentro desses escopos devem variar deorganizao para organizao), a saber:a) Criao/Manuteno de estruturas de bancos de dados:Segue metodologias de desenvolvimento pr-estabelecidas,interagindo com modeladores de sistema/dados, analistas de sistemas.b) Monitorao e otimizao de performance:Inclui a otimizao tanto lgica (implementao de novos processosde software, mtodos de acesso a dados, entre outros) como a fsica(dimensionamento de hardware (servidores e interfaces de redes)c) Criao/Manuteno de polticas de segurana de acesso:Abrange a poltica de segurana da corporao, que deve sersolicitada ao administrador de segurana. XPA OU EXTREMING PROGRAMING XP foi desenvolvida por Kent Beck, dono e presidente da FirstClass Software Inc, onde seus dois maiores interesses e objetivos so padres eprogramao extrema. A XP foi concebida a partir da ideia que desenvolver software difcil, e desenvolver software de qualidade no prazo combinado ainda maiscomplexo.A XP uma maneira leve, eficiente, de baixo risco, flexvel, previsvel,cientfica e divertidade desenvolver software Kent Caractersticas marcantes. As equipes de desenvolvimento trabalham diretamente com ocliente em ciclos muito curtos de uma a duas semanas, nomximo. As entregas de verses do software acontecem muito cedo e auma freqncia elevada para maximizar o impacto das reaesdos utilizadores A equipe de desenvolvimento trabalha em colaborao total combase programao aos pares; O cdigo testado e limpo ao longo de todo o processo dedesenvolvimento; Indicadores permitem medir o adiantamento do projeto parapermitir a atualizao do plano de desenvolvimento. O Ciclo de vida de um projeto XP:Um projeto XP atravessa algumas fases durante o seu ciclo de vida,que so: explorao, planejamento inicial, iteraes do release, produo,manuteno e morte. A fase de explorao anterior construo do sistema. Nela,investigaes de possveis solues so feitas e verifica-se aviabilidade de tais solues. Os programadores elaborampossveis arquiteturas e tentam visualizar como o sistemafuncionar considerando o ambiente tecnolgico (hardware,rede, software, performance, trfego onde o sistema ir rodar).Com isso, os programadores e os clientes vo ganhandoconfiana, e quando eles possurem estrias suficientes, jpoder comear a construir o primeiro release do sistema.

A fase de planejamento inicial deve ser usada para que osclientes concordem em uma data para lanamento do primeirorelease. O planejamento funciona da seguinte forma: Osprogramadores, juntamente com o cliente, definem as estrias(use case simplificados) a serem implementadas e asdescrevem em cartes. Os programadores assinalam certadificuldade para cada estria e, baseados na sua velocidade deimplementao, dizem quantas estrias podem implementar emuma iterao. Depois, os clientes escolhem as estrias de maiorvalor para ser implementada na iterao isso chamadoplanejamento de iterao. O processo ento se repete atterminar as iteraes do release.c) Na fase das iteraes do release so escritos os casos de testefuncionais e de unidade. Os programadores vo seguindo maisou menos o seguinte fluxo de atividades na seguinte ordem (Emcada iterao): escrita dos casos de testes; projeto erefatoramento; codificao; realizao dos testes; e integrao. medida que esse fluxo vai sendo seguido, o sistema vai sendoconstrudo segundo os princpios, valores e prticasapresentados nas sees anteriores. Depois de terminado oprimeiro release, j se ter uma idia melhor das tecnologias edo domnio do problema de modo que as iteraes podero sermais curtas nos releases subseqentes e j se podem fazerestimativas mais confiveis com o que se aprendeu dasiteraes passadas. Depois do final do primeiro release,considera-se o incio da fase de produo onde cada releasesubseqente do sistema, depois de construdo, colocado pararodar em um ambiente que simula o ambiente de produo paraver seu comportamento em termos de performance. Pode-sefazer testes de aceitao adicionais para simular ofuncionamento real do sistema no ambiente alvo. A fase de manuteno pode ser considerada como umacaracterstica inerente a um projeto XP. Em XP voc estsimultaneamente produzindo novas funcionalidades, mantendo osistema existente rodando, incorporando novas pessoas naequipe e melhorando o cdigo. Mecanismos como:refatoramento, introduo de novas tecnologias, e introduo denovas idias de arquitetura podem ser utilizados em um projetoXP. importante ressaltar que a manuteno dada em umsistema que j est em produo deve ser feita com muitacautela, pois uma alterao errada pode paralisar ofuncionamento do sistema resultando em prejuzos para ocliente A fase de morte corresponde ao trmino de um projeto XP.Existem duas razes para se chegar ao final de um projeto, umaboa e a outra ruim. A boa razo quando o cliente j estsatisfeito com o sistema existente e no enxerga nenhumafuncionalidade que possa vir a ser implementada no futuro. A mrazo para a morte em XP seria o projeto ter se tornadoeconomicamente invivel, devido a dificuldades de adicionarfuncionalidades a um custo baixo e devido a uma alta taxa de erros. O QUE SCRUM ?? Criado por Jeff Sutherland e Ken Shawaber na dcada de 90, atcnica faz parte do modelo de desenvolvimento gil de software que fornecemtodos para se definir o planejamento, os principais papis de pessoas e a formade trabalho do time. A idia do SCRUM justamente definir papis bem especficospara as pessoas envolvidas no projeto e como cada pessoa vai agir, ou seja, o quecada

uma vai ter que fazer para o projeto seguir em frente com sucesso.Os principais papis so:a) o ScrumMaster, que mantm os processos (normalmente nolugar de um gerente de projeto)b) o Proprietrio do Produto, ou Product Owner, que representa osstakeholders e o negcioc) a Equipe, ou Team, um grupo multifuncional com cerca de 7pessoas e que fazem a anlise, projeto, implementao, testeetc algumas caracteristicas do scrum so: Processo gil para gerenciar e controlar o desenvolvimento deprojetos, roupagem para outras prticas de engenharia de software.Como XP ou FDD, processo que controla o caos resultante de necessidades einteresses conflitantes, aumenta a comunicao e maximiza a cooperao, detecta e remove qualquer impedimento que atrapalhe odesenvolvimento de um produto, escalabilidade desde projetos pequenos ater grande projetosnas organizaes. O ciclo de vida do Scrum tem o seu ciclo composto por uma srie deiteraes bem definidas, cada uma com durao de duas a quatro semanas,chamada Sprints. Antes de cada Sprint, realiza-se uma reunio de planejamento(Sprint Planning Meeting) em que os membros do time tm contato com o ProductOwner (pessoa que define os itens que compem o Product Backlog) paraselecionar e estimar os itens do Product Backlog ((lista das funcionalidadespriorizadas do produto) que acreditam conseguir entregar ao final da Sprint.A prxima fase a execuo da Sprint. Durante a execuo o timecontrola o andamento do desenvolvimento realizando Reunies Dirias (DailyMeeting) de no mais que 15 minutos de durao, e observando o seu progressousando um grfico chamado Sprint Burndown. Ao final de cada Sprint, deve-se realizar uma Reunio de Reviso(Sprint Review), em que o time demonstra o produto gerado na Sprint e valida se oobjetivo foi atingido. Logo em seguida, realiza-se a Reunio de Retrospectiva (SprintRetrospective), uma reunio de lies aprendidas, com o objetivo de melhorar oprocesso para a prxima reunio FDDA FDD nasceu num projeto emCingapura,entre 1997 e 1999, apartir do Mtodo Coad (uma metodologia completa para Anlise, Desenho eProgramao Orientados por Objetos, desenvolvida por Peter Coad nas dcadas de1980 e 1990) e das tcnicas de gerenciamento iterativo, incremental e enxuto deprojetos, utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema "Resultados freqentes, tangveis e funcionais". Fornece a estrutura suficiente para equipes maiores ele Enfatiza a produo de software de qualidade faz entrega resultados freqentes, tangveis e funcionais realiza trabalho significativo desde o incio, antes de tornar-sealtamente iterativa fornece informao de estado e progresso de forma simples ecompreensvel;f) Fcil aceitao de clientes, gerentes e desenvolvedores. O Ciclo de vida da FDD Desenvolve um Modelo Abrangente podeenvolver desenvolvimento de requisitos, anlise orientada por objetos,modelagem lgica de dados e outras tcnicas paraentendimento do domnio de negcio em questo. O resultado um modelo de objetos (e/ou de dados) de alto nvel, que guiar

aequipe durante os ciclos de construo.b) Construir uma Lista de Funcionalidades: decomposio funcionaldo modelo do domnio, em trs camadas tpicas: reas de negcio, atividades de negcio e passos automatizados daatividade (funcionalidades). O resultado uma hierarquia defuncionalidades que representa o produto a ser construdo(tambm chamado de product backlog, ou lista de espera doproduto).c) Planejar por Funcionalidade: abrange a estimativa decomplexidade e dependncia das funcionalidades, tambmlevando em considerao a prioridade e valor para onegcio/cliente. O resultado um plano de desenvolvimento,com os pacotes de trabalho na seqncia apropriada para aconstruo.d) Detalhar por Funcionalidade: j dentro de uma iterao deconstruo, a equipe detalha os requisitos e outros artefatospara a codificao de cada funcionalidade, incluindo os testes. Oprojeto para as funcionalidades inspecionado. O resultado omodelo de domnio mais detalhado e os esqueletos de cdigoprontos para serem preenchidos.e) Construir por Funcionalidade: cada esqueleto de cdigo preenchido, testado e inspecionado. O resultado umincremento do produto integrado ao repositrio principal decdigo, com qualidade e potencial para ser usado pelocliente/usurio. RATIONAL UNFIED PROCESS RUP O Processo Unificado um processo de engenharia de softwaredesenvolvido por trs dos principais gurus da indstria de software: Ivar Jacobson,James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos deexperincia acumulada. o primeiro processo de desenvolvimento a explorarintegralmente as capacidades do padro UML e baseia-se nas prticas comuns aosprojetos de software com mais alto ROI (retorno do investimento) do mercado.Processo de Software Unificado (Rational Unified Process) =Processo + Mtodos + Linguagem (UML). Ciclo de vida do RUP: O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo,uma forma de organizao em fases adotada para comportar os ciclos dedesenvolvimento, permitindo uma gerncia mais efetiva de projetos complexos.a) Concepo: nesta fase, estabelecido o escopo do projeto esuas fronteiras, determinando os principais casos de uso dosistema. Esses casos de uso devem ser elaborados com apreciso necessria para se proceder estimativas de prazos ecustos. As estimativas devem ser globais para o projeto comoum todo e detalhadas para a fase seguinte. Assim, a nfasenesta etapa recai sobre o planejamento e, por conseguinte, necessrio levantar requisitos do sistema e preliminarmenteanalis-los. Ao trmino dessa fase, so examinados os objetivosdo projeto para se decidir sobre a continuidade dodesenvolvimento;b) Elaborao: o propsito desta fase analisar maisrefinadamente o domnio do problema, estabelecer umaarquitetura de fundao slida, desenvolver um plano de projetopara o sistema a ser construdo e eliminar os elementos deprojeto que oferecem maior risco. Embora o processo devasempre acomodar alteraes, as atividades da fase deelaborao asseguram que os requisitos, a arquitetura e osplanos esto suficientemente estveis e que os riscos estosuficientemente mitigados, de modo a se poder prever compreciso os custos e prazos para a concluso dodesenvolvimento.c) Construo: durante esta fase, um produto completo desenvolvido de maneira iterativa e incremental, para que esteja pronto

para a transio comunidade usuria. Transio: nesta fase, o software disponibilizado comunidade usuria. Aps o produto ter sido colocado em uso,naturalmente surgem novas consideraes que vo demandar aconstruo de novas verses para permitir ajustes do sistema,corrigir problemas ou concluir algumas caractersticas que forampostergadas. importante realar que dentro de cada fase, umconjunto de iteraes, envolvendo planejamento, levantamentode requisitos, anlise, projeto e implementao e testes, realizado. Contudo, de uma iterao para outra e de uma fasepara a prxima, a nfase sobre as vrias atividades muda, comomostra a figura 1, em que a cor preta indica grande nfase,enquanto a cor branca indica muito pouca nfase. Na fase deconcepo, o foco principal recai sobre o entendimento dosrequisitos e a determinao do escopo do projeto (planejamentoe levantamento de requisitos). Na fase de elaborao, o enfoqueest na captura e modelagem dos requisitos (levantamento derequisitos e anlise), ainda que algum trabalho de projeto eimplementao seja realizado para prototipar a arquitetura,evitando certos riscos tcnicos. Na fase de construo, oenfoque concentra-se no projeto e na implementao, visandoevoluir e rechear o prottipo inicial, at obter o primeiro produtooperacional. Finalmente, a fase de transio concentra-se nostestes, visando garantir que o sistema possui o nvel adequadode qualidade. Alm disso, usurios devem ser treinados,caractersticas ajustadas e elementos esquecidos adicionados. MODELO DE PROTOTIPAGEM A prototipagem um modelo de processo que possibilita ao desenvolvedor criar um modelo do software que deve ser construdo. Assim, umaprvia avaliao tanto do cliente, quanto do desenvolvedor pode ser feita. Estemodelo pode ser usado como um modelo de processo independente, ou como umatcnica, que pode ser implantada no contexto de qualquer um dos modelos deprocesso existentes. A vantagem da prototipagem auxiliar o engenheiro desoftware e o cliente, a entenderem melhor o que deve ser construdo, quando os requisitos esto confusos seu modelo Utilizado quando o cliente no definiu detalhadamente osrequisitos de entrada, processamento e sada, possibilita ao desenvolvedor criar uma verso do software com um pequeno investimento inicial, prvia avaliao tanto do cliente, quanto do desenvolvedor, a construo do prottipo demonstra a viabilidade do sistema, e reduo dos riscos e das incertezas do desenvolvimento. O desenvolvimento comea com um conjunto simples de requisitosfornecidos pelos clientes e usurios. As alternativas so exploradas. Examinam-seas telas, tabelas, relatrios e outras sadas do sistema, diretamente utilizadas pelosclientes e usurios. Feita a deciso do que os clientes e usurios realmente querem,os requisitos so revisados. Havendo consenso de como deveriam ser os requisitos,o desenvolvedor se volta para as atividades de requisitos, afim de reconsiderar ealterar a especificao. Ento, o sistema codificado, e as alternativas, discutidas,de novo com uma possvel iterao entre requisitos e projeto abaixo se gue um plano de prototipagem

MODELO ESPIRAL O modelo em espiral foi proposto por Boehm em 1988, como formade integrar os diversos modelos existentes poca, eliminando suas dificuldades eexplorando seus pontos fortes. Este modelo foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento - a anlise de riscos - que falta a esses modelos. Modelo iterativo e sistemtico possui verses utilizveis ao final de cada iterao alm acompanhamento de toda vida do software, mesmo depois de entregue tem como fazer anlise de riscos. O ciclo se subdivide em regies que abrigam conjuntos de tarefasque crescem proporcionalmente ao risco e ao tamanho do projeto. Iniciado oprocesso, ele passa por todas as regies e depois volta primeira, executandonovamente as regies seguindo uma espiral at que se tenha o produto desejado. a) Comunicao com o Cliente: mantm contato direto afim delevantar informaes teis ao sistema; b) Planejamento: define custo e tempo de desenvolvimento, alm de realizar uma anlise de risco, onde estes so avaliados paraque o desenvolvimento no se torne invivel na prxima etapado modelo; c) Modelagem: responsvel pela criao da representaoconceitual da aplicao; d) Construo: cuida da implementao e testes; e) Implantao: responsvel pela instalao, suporte e feedback doincremento desenvolvido. MODELOS INCREMENTAL E ITERATIVO Este modelo uma extenso do modelo espiral sendo porm maisformal e rigoroso. Dividi-se o trabalho em partes menores ou iteraes.Cada iterao resultar num incremento. Iteraes so passos em fluxo de trabalhoe

incrementos so crescimentos do produto.O princpio subjacente ao processo incremental e iterativo que aequipe envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e mbito do sistema envolvido. DESENVOLVIMENTO DA APLICAO Dentro de uma aplicao de vdeo locadoras, encontramos vriasaes praticadas por possveis atores (atendente, gerente e cliente), lembrandosempre que, para ser um ator, necessrio que haja interao com o sistema. Asaes so: locao, reserva, pagamentos, controle de fornecedores, controle declientes e,controle de Livros, este ltimo, foco deste cenrio de estudo.

Os componentes e controles so base do desenvolvimento rpido de aplicativos. So objetos reutilizveis que expe um ou mais interfaces paraclientes de uma maneira padronizada.Nomear os componentes corretamente e de forma intuitiva amaneira mais inteligente e fcil para evitar transtornos em futuras manutenes dosoftware.Exemplo: txbGenero.Text = auto ajuda (observem que neste caso estamos usando a propriedade Text. Para dar o nome, podemos usar a abreviaotxb de textBox, que referencia o tipo de componente mais o nome da finalidade dele,Gnero do Livro). Menu Strip: destinado a criao de menus, com ele criamosnossa barra de menus principal do sistema (Cadastrar,Cadastrar/Alterar, Financeiro, Reservas e

Locaes),StatusStrip: barra de status inferior, por meio da qual passamos valiosas informaes ao usurio do sistema. Formulrio de Cadastro do Livro:a) Label: propriedade mais usada Text, onde colocamos o nomeque aparecer na tela de nosso formulrio, identificando oscontedos que devero ser inseridos nos TextBox;b) TextBox: armazena texto dos mais variados tipos;c) RichTextBox: indicado para texto maiores, podemos alterar otipo, estilo de letra;d) RadioButton: utilizado para selecionar um item entre vrios, emnosso formulrio, decidiremos se o Livro coletania ou noe) ComboBox: lista de opes possveis para selecionar,usaremos para informar a quantidade de Livros para cada ttulocadastrado, seleo de fornecedores e o gnero do filme;f) Button: componente visual com finalidade de executar algumatarefa, em nosso programa, pode executar a insero de umaimagem de capa, acionar o leitor de cdigo de barras ou aesbsicas de sistemas (gravar, editar, cancelar);g) PictureBox: exibio de imagens, mostrar a imagem de capaselecionada pelo atendente;Telas resultantes do Cadastro de Livro:

CONCLUSO Nesse trabalho foram apresentadas algumas reflexes sobre a importncia da anlise dos requisitos de sistemas, principalmente como base para o planejamento da qualidade no desenvolvimento de softwares de apoio aos processos de controle de uma organizao social. Foram apresentados tambm alguns princpios tericos e outros conceituais, adotados atualmente para a anlise de requisitos, bem como conceitos relacionados qualificao de softwares Bom no geral foi um trabalho bem arduo pois para se tornar um bom analista de sistema,tende-se dedicar muitas horas de estudo e muito mas muito conhecimento tecnico a profisso exige-se um grande know-how de entendimento em varios segmentos da programao no s saber programar em determinada lingugem ou pegar um apostila e achar que esta montando sistema apesar de ter pessoas com essas capacidades.Neste contexto, foi visto o tanto que importante os conceitos e tcnica abordado neste semestre, Casos de Uso, Engenharia de Software, Banco deDados e Programao Orientada a Objetos, dever e obrigao saber toda essa teoria, isso que nos dra base e saber para o sucesso de nossas empreitadas como analista de sistemas

REFERENCIAS TELE AULAS E BIBLIOTECA DIGITAL, UNOPAR FLORES, Emerson Ricardo.Linguagens e Tcnicas de Programao II:sistemas. So Paulo: Pearson Prentice Hall, 2009. Guedes, Luis Fernando. Engenharia de Software: A analise Completa.So Paulo: Editora Etica, 2007. Alcantra, Maria. Anlise de Sistemas - . So Paulo: Editora Escala, 2008. http://www.scielo.br/ http://pt.wikipedia.org/wiki/An%C3%A1lise_de_sistemas http://guiadoestudante.abril.com.br/profissoes/ciencias-exatas-informatica/analisedesenvolvimento-sistemas-602442.shtml.