SISTEMA DE ENSINO PRESENCIAL CONECTADOANALISE E DESENVOLVIMENTO DE SISTEMAS

JULIO CESAR OLIVEIRA CORRER

ANALISE DE SISTEMAS IPRODUÇÃO TEXTUAL SOBRE O CONTEUDO TÉMATICO DA RECUPERAÇÃO

ANALISE DE SISTEMAS I

Piracicaba2012

JULIO CESAR DE OLIVERIA CORRER

ANALISE DE SISTEMAS IPRODUÇÃO TEXTUAL SOBRE O CONTEUDO TÉMATICO DA RECUPERAÇÃO

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

INTRODUÇÃO

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 APLICAÇÃO

CONCLUSÃO

REFERENCIAS

INTRODUÇÃO

Programar é uma coisa muito complexa, pior ainda é desenvolver algo do zero sem nenhum planejamento ou dissertimento da coisa l.

Ideias sobre programação, requisitos, e muita visão 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 : Análise de sistemas é a atividade que tem como finalidade a realização de estudos de processos a fim de encontrar o melhor caminho racional para que a informação possa ser processada. Os analistas de sistemas estudam os diversos sistemas existentes entre hardwares (equipamentos), softwares (programas) e o usuário final.

Os seus comportamentos e aplicações são desenvolvidos a partir de soluções que serão 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 análise [de sistemas] é frustrante, repleta de relacionamentos entre pessoas,

indefinida e difícil. Resumindo, é fascinante. Depois que você é fisgado, os velhos e

fáceis prazeres da construção de sistemas nunca mais serão suficientes para

satisfazê-lo”

Tom DeMarco, Structured Analysis and Systems Specification

DESENVOLVIMENTO

São descritos em texto, amplamente utilizadaspara levantar os requisitos de determinada solução de software. Descreve afuncionalidade de um sistema, deve desempenhar ou exibir, por meio da modelagem do diálogo que um usuário, um sistema externo ou outra entidade terá com o sistema desenvolvido. É representado por um diagrama que utilize os conceitos padrões da UML.

O aluno chega à biblioteca e faz seu cadastramento. O bibliotecário pede os documentos que a escola exige para efetuar seu cadastro no sistema cadastro e começa a alimentar o banco de dados com oas infomaçães desejadas. O sistema faz um consulta rapida se o usuario já tem cadastro se não tiver ele prossegue com o cadastro. O funcionario faz a impressão de duas vias. O aluno fica com uma e rubrica a outra bibliotecário armazena a outra . O sistema o sistemas automaticamente tem sua consulta, edição, bloqueio e exclusão 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 gestão 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.

Descrição :

Principal Cadastrar:

1)O Funcionario pede novo cadastro, após checar documentos obrigatórios. 2)O sistema solicita entrada de dados (RA do Aluno).3)O sistema checa, através do RA, base de dados interna de outro programa à procura se o cadastro já existe. 4) O sistema pede á entrada de mais dados (nome, endereço, 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 bibliotecário grava e o sistema arquiva no cadastro.

Exceções cadastrar:

1) Aluno com pendências na biblioteca. 2) Sistema avisa que existem pendências na biblioteca. 3)bibliotecário solicita impressão das pendências. 4)Sistema gera relatório e imprimi. 5)sistema salva estado do cadastro até que pendência seja resolvida.

Fluxo de confirmação principal consultar-alterar

1)O bibliotecário inicia a consulta. 2) O bibliotecário 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 informações. 7)O sistema grava.

Fluxo de não cadastrado:

1) Não cadastrado: sistema avisa que não há registro de cadastro. 2) –sistema pergunta se deseja cadastrar 3) –sistema chama módulo de cadastro

Fluxo de confirmação 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 exclusão. 7)O sistema pede confirmação para exclusão. 7) O bibliotecário confirma. 8)Sistema realiza a exclusão.

Fluxo de exceções consultar-excluir:

1)Não cadastrado.2)Sistema avisa que não há registro de cadastro. 3)Sistema pergunta se deseja cadastrar. 4) Sistema chama módulo de cadastro

Fluxo de confirmação 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 exceções consultar-bloquear:

1)Registro não encontrado. 2) Sistema avisa que não há registro de cadastro.3) Sistema pergunta se deseja cadastrar 4)Sistema chama módulo 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 técnica no ano de 1976, que foiadaptada positivamente ao passar dos anos. O MER (Modelo Entidade-Relacionamento), baseia-se na idéia de que o mundo real consiste de entidades ede relacionamentos entre essas entidades.

MODELAGEM DE DADOS

Quando pretendemos desenvolver aplicações que usam banco dedados relacionais devemos possuir os conceitos básicos sobre modelagem dedados. Não importa se a aplicação é muito simples; a correta modelagem dos seus dados irá com certeza tornar sua aplicação mais robusta e mais fácil de manter.Os

objetivos principais da modelagem de dados são:

a) Representar o ambiente observado;

b) Documentar e normalizar;

c) Fornecer processos de validação;

d) Observar

processos de relacionamentos entre objetos. Modelar implica em construir.

Modelo conceitual - Representa as regras de negócio semlimitações tecnológicas ou de implementação, por isto é a etapa mais adequadapara o envolvimento do usuário que não precisa ter conhecimentos técnicos. Neste modelo temos :

a) Visão Geral do negócio;

b) Facilitação do entendimento entre usuários e desenvolvedores;

c) Possui somente as entidades e atributos principais;

d) Pode conter relacionamentos n para m.

Modelo Lógico - Abordam limites impostos por algum tipo detecnologia de banco de dados (banco de dados hierárquico, banco de dadosrelacional ,etc.). Suas características são :

a)Deriva do modelo conceitual e via a representação do negócio;

b) Possui entidades associativas em lugar de relacionamentosn:m;

c) Define as chaves primárias das entidades;

d) Normalização até a 3ª forma normal;

e) Adequação ao padrão de nomenclatura;

f) Entidades e atributos documentados.

Modelo Físico - Leva em consideração limites impostos peloSGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos não funcionaisdos programas que acessam os dados Características:

a) Elaborado a partir do modelo lógico;

b) Pode variar segundo o SGBD;

c) Pode ter tabelas físicas (log , lider , etc.);

d) Pode ter colunas físicas (replicação).

ENTIDADES

São representações abstratas de alguma coisa do mundo real. Porexemplo: a placa de um carro, o número de um pedido num restaurante, o JoséRibamar funcionário da empresa, a disciplina de Ciências de uma escola, todos são entidades, que podem ser concretas, conceituais, fatos e etc.Ao agrupamento de entidades afins, damos o nome de Conjunto deEntidades. Por exemplo: todos os veículos ou todos os funcionários da empresa. Émuito importante saber que no MER, só se representam os Conjuntos de Entidades e nunca entidades individuais. Ainda, só merecem representação os conjuntos de entidades do mundo real que contenham dados de interessa da organização.

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:

Veículo: conjunto que engloba todos os meios de transporte de propriedade da empresa.

ATRIBUTOS

Para cada conjunto de entidades do modelo, guardam-se algumasinformações pertinentes relacionadas aos seus elementos.

Isto é feito através dos atributos. Exemplo: Veículo = (Placa + Marca + Cor + Data-aquisição +Quilometragem) ou Aluno = (Matrícula + Nome do Aluno + Data da Matrícula).

Nomes de atributos são diferentes de valores de atributos, porexemplo, Marca, é o nome, enquanto Ford, GM ou Fiat, são 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 informações diferentes. Por exemplo, o atributo Nome pode aparecer na entidade. Cliente onde ele indica nome do cliente, e pode também estarna entidade Funcionário, onde ele significa nome do funcionário.

Existem tipod de atributos de mode que se separam de duas formas compostos e simples também conhecidos como atomicos

Atributos compostos podem ser divididos em subpartes menores,que representam a maioria de atributos básicos com significados diferentes. Porexemplo, em uma entidade empregado, temos um atributo endereço que pode ser subdividido em EnderecoRua, Cidade, Estado, CEP. Os atributos que não permitem subdivisões são conhecidos como atributos :

- Os atributoscompostos podem formar uma hierarquia, exemplo: EnderecoRua, pode sersubdividido em três

- Simples (Atomicos) (Rua, Número e Apartamento)

MONOVALORADOS E MULTIVALORADOSA

maioria dos atributos tem um valor único para uma determinadaentidade, são denominados monovalorados.

Exemplo: Idade é um atributomonovalorado de uma pessoa.Atributos multivalorados são aqueles que têm maisde um valor. Exemplo: Titulação, pois uma pessoa pode ser graduada em dois oumais cursos. Atributos multivalorados devem ter limite inferior e superior pararestringir o número 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 funcionário 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 número de entidades queparticipam desse relacionamento. Temos o grau binário (2 relacionamentos) eternário (3). Podemos encontrar relacionamentos de mais graus, mas os maiscomuns são os binários. Um exemplo de relacionamento de grau ternário:

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 instância de relacionamento, e ajuda a explicar o significado dorelacionamento.

Quando determinada entidade participa mais de uma vez em umtipo de relacionamento em papéis diferentes, temos o relacionamento recursivo.Exemplo de relacionamento recursivo abaixo.

O tipo relacionamento Supervisão relaciona um empregado a umsupervisor, no qual ambas as entidades, empregado e supervisor, são membros domesmo tipo entidade Empregado. Assim, o tipo entidade Empregado participa duasvezes em Supervisão: uma no papel de supervisor (ou chefe), e outro, no papel de supervisionado.

CARDINALIDADE

São restrições impostas para limitar as possibilidades decombinações 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, teríamosportanto, de descrever essa restrição no esquema. Temos dois tipos principais derestrições.

A Cardinalidade para Relacionamentos Binarios especifica o número máximo de instâncias de relacionamento emque uma entidade pode participar. As razões possíveis para esse tipo de cardinalidade são: 1:1 –1:N –N:1 –M:N. Onde N representa qualquer número deentidades relacionadas (zero ou mais).

Determina se a existência de uma entidade depende de sua existência relacionada à outra entidade, pelo tipo relacionamento. Essa restriçãodetermina o número mínimo de instâncias de relacionamento em que cada entidadepode participar. Há dois tipos de restrições de participação: total e parcial.

ADMINISTRADOR DE BANCO DE DADOS (DBA)

O administrador de bancos de dados (DBA) executa uma funçãoestratégica na empresa, considerando que o maior bem de uma organização hojesão os dados, que estão sobre sua gerência. Para se entender o tamanho daresponsabilidade do DBA com os dados da organização, perdas ocasionais dedados, dependendo de seu volume e importância, podem causar sérios prejuízos à empresa e inclusive levá-la à falência. Podemos resumir sua atuação em 3 grandes grupos e breves descrições (as atribuições dentro desses escopos devem variar deorganização para organização), a saber:a) Criação/Manutenção de estruturas de bancos de dados:Segue metodologias de desenvolvimento pré-estabelecidas,interagindo com modeladores de sistema/dados, analistas de sistemas.b) Monitoração e otimização de performance:Inclui a otimização tanto lógica (implementação de novos processosde software, métodos de acesso a dados, entre outros) como a física(dimensionamento de hardware (servidores e interfaces de redes)c) Criação/Manutenção de políticas de segurança de acesso:Abrange a política de segurança da corporação, que deve sersolicitada ao administrador de segurança.

XPA OU EXTREMING PROGRAMING

XP foi desenvolvida por Kent Beck, dono e presidente da FirstClass Software Inc, onde seus dois maiores interesses e objetivos são padrões eprogramação extrema. A XP foi concebida a partir da ideia que desenvolver software é difícil, e desenvolver software de qualidade no prazo combinado é ainda maiscomplexo.“A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível,científica e divertidade desenvolver software” Kent Características marcantes.

As equipes de desenvolvimento trabalham diretamente com ocliente em ciclos muito curtos de uma a duas semanas, nomáximo.

As entregas de versões do software acontecem muito cedo e auma freqüência elevada para maximizar o impacto das reaçõesdos utilizadores

A equipe de desenvolvimento trabalha em colaboração total combase programação aos pares;

O código é testado e limpo ao longo de todo o processo dedesenvolvimento;

Indicadores permitem medir o adiantamento do projeto parapermitir a atualização 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 são: exploração, planejamento inicial, iterações do release, produção,manutenção e morte.

A fase de exploração é anterior à construção do sistema. Nela,investigações de possíveis soluções são feitas e verifica-se aviabilidade de tais soluções. Os programadores elaborampossíveis arquiteturas e tentam visualizar como o sistemafuncionará considerando o ambiente tecnológico (hardware,rede, software, performance, tráfego onde o sistema irá rodar).Com isso, os programadores e os clientes vão ganhandoconfiança, e quando eles possuírem estórias suficientes, jápoderá começar a construir o primeiro release do sistema.

A fase de planejamento inicial deve ser usada para que osclientes concordem em uma data para lançamento do primeirorelease. O planejamento funciona da seguinte forma: Osprogramadores, juntamente com o cliente, definem as estórias(use case simplificados) a serem implementadas e asdescrevem em cartões. Os programadores assinalam certadificuldade para cada estória e, baseados na sua velocidade deimplementação, dizem quantas estórias podem implementar emuma iteração. Depois, os clientes escolhem as estórias de maiorvalor para ser implementada na iteração isso é chamadoplanejamento de iteração. O processo então se repete atéterminar as iterações do release.c) Na fase das iterações do release são escritos os casos de testefuncionais e de unidade. Os programadores vão seguindo maisou menos o seguinte fluxo de atividades na seguinte ordem (Emcada iteração): escrita dos casos de testes; projeto erefatoramento; codificação; realização dos testes; e integração.À medida que esse fluxo vai sendo seguido, o sistema vai sendoconstruído segundo os princípios, valores e práticasapresentados nas seções anteriores. Depois de terminado oprimeiro release, já se terá uma idéia melhor das tecnologias edo domínio do problema de modo que as iterações poderão sermais curtas nos releases subseqüentes e já se podem fazerestimativas mais confiáveis com o que se aprendeu dasiterações passadas. Depois do final do primeiro release,considera-se o início da fase de produção onde cada releasesubseqüente do sistema, depois de construído, é colocado pararodar em um ambiente que simula o ambiente de produção paraver seu comportamento em termos de performance. Pode-sefazer testes de aceitação adicionais para simular ofuncionamento real do sistema no ambiente alvo.

A fase de manutenção pode ser considerada como umacaracterística inerente a um projeto XP. Em XP você estásimultaneamente produzindo novas funcionalidades, mantendo osistema existente rodando, incorporando novas pessoas naequipe e melhorando o código. Mecanismos como:refatoramento, introdução de novas tecnologias, e introdução denovas idéias de arquitetura podem ser utilizados em um projetoXP. É importante ressaltar que a manutenção dada em umsistema que já está em produção deve ser feita com muitacautela, pois uma alteração errada pode paralisar ofuncionamento do sistema resultando em prejuízos para ocliente

A fase de morte corresponde ao término de um projeto XP.Existem duas razões para se chegar ao final de um projeto, umaboa e a outra ruim. A boa razão é quando o cliente já estásatisfeito com o sistema existente e não enxerga nenhumafuncionalidade que possa vir a ser implementada no futuro. A márazão para a morte em XP seria o projeto ter se tornadoeconomicamente inviável, 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 década de 90, atécnica faz parte do modelo de desenvolvimento ágil de software que fornecemétodos para se definir o planejamento, os principais papéis de pessoas e a formade trabalho do time. A idéia do SCRUM é justamente definir papéis bem específicospara 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 papéis são:a) o ScrumMaster, que mantém os processos (normalmente nolugar de um gerente de projeto)b) o Proprietário do Produto, ou Product Owner, que representa osstakeholders e o negócioc) a Equipe, ou Team, um grupo multifuncional com cerca de 7pessoas e que fazem a análise, projeto, implementação, testeetc algumas caracteristicas do scrum são:

Processo ágil para gerenciar e controlar o desenvolvimento deprojetos, roupagem para outras práticas de engenharia de software.Como XP ou FDD, processo que controla o caos resultante de necessidades einteresses conflitantes, aumenta a comunicação e maximiza a cooperação, detecta e remove qualquer impedimento que atrapalhe odesenvolvimento de um produto, escalabilidade desde projetos pequenos ater grande projetosnas organizações.

O ciclo de vida do Scrum tem o seu ciclo composto por uma série deiterações bem definidas, cada uma com duração de duas a quatro semanas,chamada Sprints. Antes de cada Sprint, realiza-se uma reunião de planejamento(Sprint Planning Meeting) em que os membros do time têm contato com o ProductOwner (pessoa que define os itens que compõem 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 próxima fase é a execução da Sprint. Durante a execução o timecontrola o andamento do desenvolvimento realizando Reuniões Diárias (DailyMeeting) de não mais que 15 minutos de duração, e observando o seu progressousando um gráfico chamado Sprint Burndown.

Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão(Sprint Review), em que o time demonstra o produto gerado na Sprint e valida se oobjetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva (SprintRetrospective), uma reunião de lições aprendidas, com o objetivo de melhorar oprocesso para a próxima reunião

FDDA FDD

nasceu num projeto emCingapura,entre 1997 e 1999, apartir do Método Coad (uma metodologia completa para Análise, Desenho eProgramação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto deprojetos, utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema é"Resultados freqüentes, tangíveis e funcionais".

Fornece a estrutura suficiente para equipes maiores ele Enfatiza a produção de software de qualidade faz entrega resultados freqüentes, tangíveis e funcionais realiza trabalho significativo desde o início, antes de tornar-sealtamente iterativa fornece informação de estado e progresso de forma simples ecompreensível;f) Fácil aceitação de clientes, gerentes e desenvolvedores.

O Ciclo de vida da FDD Desenvolve um Modelo Abrangente podeenvolver desenvolvimento de requisitos, análise orientada por objetos,modelagem lógica de dados e outras técnicas paraentendimento do domínio de negócio em questão. O resultado éum modelo de objetos (e/ou de dados) de alto nível, que guiará

aequipe durante os ciclos de construção.b) Construir uma Lista de Funcionalidades: decomposição funcionaldo modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados daatividade (funcionalidades). O resultado é uma hierarquia defuncionalidades que representa o produto a ser construído(também chamado de product backlog, ou lista de espera doproduto).c) Planejar por Funcionalidade: abrange a estimativa decomplexidade e dependência das funcionalidades, tambémlevando em consideração a prioridade e valor para onegócio/cliente. O resultado é um plano de desenvolvimento,com os pacotes de trabalho na seqüência apropriada para aconstrução.d) Detalhar por Funcionalidade: já dentro de uma iteração deconstrução, a equipe detalha os requisitos e outros artefatospara a codificação de cada funcionalidade, incluindo os testes. Oprojeto para as funcionalidades é inspecionado. O resultado é omodelo de domínio mais detalhado e os esqueletos de códigoprontos para serem preenchidos.e) Construir por Funcionalidade: cada esqueleto de código épreenchido, testado e inspecionado. O resultado é umincremento do produto integrado ao repositório principal decódigo, com qualidade e potencial para ser usado pelocliente/usuário.

RATIONAL UNFIED PROCESS –RUP

O Processo Unificado é um processo de engenharia de softwaredesenvolvido por três dos principais gurus da indústria de software: Ivar Jacobson,James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos deexperiência acumulada. É o primeiro processo de desenvolvimento a explorarintegralmente as capacidades do padrão UML e baseia-se nas práticas comuns aosprojetos de software com mais alto ROI (retorno do investimento) do mercado.Processo de Software Unificado

(Rational Unified Process) =Processo + Métodos + Linguagem (UML).

Ciclo de vida do RUP: O ciclo de vida adotado no RUP é tipicamente evolutivo. Contudo,uma forma de organização em fases é adotada para comportar os ciclos dedesenvolvimento, permitindo uma gerência mais efetiva de projetos complexos.a) Concepção: nesta fase, é estabelecido o escopo do projeto esuas fronteiras, determinando os principais casos de uso dosistema. Esses casos de uso devem ser elaborados com aprecisão necessária 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, énecessário levantar requisitos do sistema e preliminarmenteanalisá-los. Ao término dessa fase, são examinados os objetivosdo projeto para se decidir sobre a continuidade dodesenvolvimento;b) Elaboração: o propósito desta fase é analisar maisrefinadamente o domínio do problema, estabelecer umaarquitetura de fundação sólida, desenvolver um plano de projetopara o sistema a ser construído e eliminar os elementos deprojeto que oferecem maior risco. Embora o processo devasempre acomodar alterações, as atividades da fase deelaboração asseguram que os requisitos, a arquitetura e osplanos estão suficientemente estáveis e que os riscos estãosuficientemente mitigados, de modo a se poder prever comprecisão os custos e prazos para a conclusão dodesenvolvimento.c) Construção: durante esta fase, um produto completo édesenvolvido de maneira iterativa e incremental, para que esteja pronto

para a transição à comunidade usuária.

Transição: nesta fase, o software é disponibilizado àcomunidade usuária. Após o produto ter sido colocado em uso,naturalmente surgem novas considerações que vão demandar aconstrução de novas versões para permitir ajustes do sistema,corrigir problemas ou concluir algumas características que forampostergadas. É importante realçar que dentro de cada fase, umconjunto de iterações, envolvendo planejamento, levantamentode requisitos, análise, projeto e implementação e testes, érealizado. Contudo, de uma iteração para outra e de uma fasepara a próxima, a ênfase sobre as várias atividades muda, comomostra a figura 1, em que a cor preta indica grande ênfase,enquanto a cor branca indica muito pouca ênfase. Na fase deconcepção, o foco principal recai sobre o entendimento dosrequisitos e a determinação do escopo do projeto (planejamentoe levantamento de requisitos). Na fase de elaboração, o enfoqueestá na captura e modelagem dos requisitos (levantamento derequisitos e análise), ainda que algum trabalho de projeto eimplementação seja realizado para prototipar a arquitetura,evitando certos riscos técnicos. Na fase de construção, oenfoque concentra-se no projeto e na implementação, visandoevoluir e rechear o protótipo inicial, até obter o primeiro produtooperacional. Finalmente, a fase de transição concentra-se nostestes, visando garantir que o sistema possui o nível adequadode qualidade. Além disso, usuários devem ser treinados,características 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 construído. Assim, umaprévia avaliação tanto do cliente, quanto do desenvolvedor pode ser feita. Estemodelo pode ser usado como um modelo de processo independente, ou como umatécnica, 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 construído, quando os requisitos estão confusos seu modelo é

Utilizado quando o cliente não definiu detalhadamente osrequisitos de entrada, processamento e saída, possibilita ao desenvolvedor criar uma versão do software com um pequeno investimento inicial, prévia avaliação tanto do cliente, quanto do desenvolvedor, a construção do protótipo demonstra a viabilidade do sistema, e redução dos riscos e das incertezas do desenvolvimento.

O desenvolvimento começa com um conjunto simples de requisitosfornecidos pelos clientes e usuários. As alternativas são exploradas. Examinam-seas telas, tabelas, relatórios e outras saídas do sistema, diretamente utilizadas pelosclientes e usuários. Feita a decisão do que os clientes e usuários realmente querem,os requisitos são revisados. Havendo consenso de como deveriam ser os requisitos,o desenvolvedor se volta para as atividades de requisitos, afim de reconsiderar ealterar a especificação. Então, o sistema é codificado, e as alternativas, discutidas,de novo com uma possível iteração 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 características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses modelos.

Modelo iterativo e sistemático possui versões utilizáveis ao final de cada iteração além acompanhamento de toda vida do software, mesmo depois de entregue tem como fazer análise de riscos.

O ciclo se subdivide em regiões que abrigam conjuntos de tarefasque crescem proporcionalmente ao risco e ao tamanho do projeto. Iniciado oprocesso, ele passa por todas as regiões e depois volta à primeira, executandonovamente as regiões seguindo uma espiral até que se tenha o produto desejado.

a) Comunicação com o Cliente: mantém contato direto afim delevantar informações úteis ao sistema;

b) Planejamento: define custo e tempo de desenvolvimento, além de realizar uma análise de risco, onde estes são avaliados paraque o desenvolvimento não se torne inviável na próxima etapado modelo;

c) Modelagem: responsável pela criação da representaçãoconceitual da aplicação;

d) Construção: cuida da implementação e testes;

e) Implantação: responsável pela instalação, suporte e feedback doincremento desenvolvido.

MODELOS INCREMENTAL E ITERATIVO

Este modelo é uma extensão do modelo espiral sendo porém maisformal e rigoroso. Dividi-se o trabalho em partes menores ou iterações.Cada iteração resultará num incremento. Iterações são passos em fluxo de trabalhoe

incrementos são crescimentos do produto.O princípio subjacente ao processo incremental e iterativo é que aequipe envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e âmbito do sistema envolvido.

DESENVOLVIMENTO DA APLICAÇÃO

Dentro de uma aplicação de vídeo locadoras, encontramos váriasações praticadas por possíveis atores (atendente, gerente e cliente), lembrandosempre que, para ser um ator, é necessário que haja interação com o sistema. Asações são: locação, reserva, pagamentos, controle de fornecedores, controle declientes e,controle de Livros, este último, foco deste cenário de estudo.

Os componentes e controles são à base do desenvolvimento rápido de aplicativos. São objetos reutilizáveis que expõe um ou mais interfaces paraclientes de uma maneira padronizada.Nomear os componentes corretamente e de forma intuitiva é amaneira mais inteligente e fácil para evitar transtornos em futuras manutenções dosoftware.Exemplo: txbGenero.Text = “auto ajuda” (observem que neste caso estamos usando a propriedade Text. Para dar o nome, podemos usar a abreviaçãotxb de textBox, que referencia o tipo de componente mais o nome da finalidade dele,Gênero do Livro).

Menu Strip: destinado a criação de menus, com ele criamosnossa barra de menus principal do sistema (Cadastrar,Cadastrar/Alterar, Financeiro, Reservas e

Locações),StatusStrip: barra de status inferior, por meio da qual passamos valiosas informações ao usuário do sistema.

Formulário de Cadastro do Livro:a) Label: propriedade mais usada é Text, onde colocamos o nomeque aparecerá na tela de nosso formulário, identificando osconteúdos que deverão 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 vários, emnosso formulário, decidiremos se o Livro é coletania ou nãoe) ComboBox: lista de opções possíveis para selecionar,usaremos para informar a quantidade de Livros para cada títulocadastrado, seleção de fornecedores e o gênero do filme;f) Button: componente visual com finalidade de executar algumatarefa, em nosso programa, pode executar a inserção de umaimagem de capa, acionar o leitor de código de barras ou açõesbásicas de sistemas (gravar, editar, cancelar);g) PictureBox: exibição de imagens, mostrará a imagem de capaselecionada pelo atendente;Telas resultantes do Cadastro de Livro:

CONCLUSÃO

Nesse trabalho foram apresentadas algumas reflexões sobre a importância da análise dos requisitos de sistemas, principalmente como base para o planejamento da qualidade no desenvolvimento de softwares de apoio aos processos de controle de uma organização social. Foram apresentados também alguns princípios teóricos e outros conceituais, adotados atualmente para a análise de requisitos, bem como conceitos relacionados à qualificação 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 profissão exige-se um grande know-how de entendimento em varios segmentos da programação não é 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 técnica abordado neste semestre, Casos de Uso, Engenharia de Software, Banco deDados e Programação Orientada a Objetos, é dever e obrigação saber toda essa teoria, isso que nos dára 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 Técnicas de Programação II:sistemas. São Paulo: Pearson Prentice Hall, 2009.

Guedes, Luis Fernando. Engenharia de Software: A analise Completa.São Paulo: Editora Etica, 2007.

Alcantra, Maria. Análise de Sistemas - . São 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/analise-desenvolvimento-sistemas-602442.shtml.