SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS CRISTINA PILGER MANFIO

PRODUO TEXTUAL INTERDISCIPLINAR- INDIVIDUAL

Frederico Westphalen 2011

CRISTINA PILGER MANFIO

PRODUO TEXTUAL INTERDISCIPLINAR- INDIVIDUAL

Trabalho apresentado ao Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas da UNOPAR Universidade Norte do Paran, para as disciplinas do segundo semestre. Prof. : Polyanna Gomes Roberto Y. Nishimura Lus Claudio Perini Anderson Gonalves

Frederico Westphalen 2011

SUMRIO 1 INTRODUO...........................................................................................................3 2 DESENVOlvimento...................................................................................................4 3 CONCLUSO..........................................................................................................21 REFERNCIAS..........................................................................................................22

1 INTRODUO

O Brasil um pas cujo desenvolvimento de produtos de software est entre os maiores do mundo, e a cada dia, aumenta o nvel de exigncia por parte dos clientes no que diz respeito qualidade e complexidade dos produtos. A partir deste ponto, podemos observar que as empresas esto buscando cada vez mais a maturidade nos seus processos de software para atingir padronizaes de qualidade e produtividade internacionais, que so essenciais para a sobrevivncia no mercado de TI. Para se desenvolver software de qualidade necessrio que se sigam metodologias de desenvolvimento. Estas guiam o processo de desenvolvimento de software atravs de regras e metas que atendem a pontos importantes para a criao de um produto de qualidade. Um problema muito comum em desenvolvimento de software sejam sistemas desktop ou sites e sistemas web, a garantia de que o produto realmente atende s expectativas do cliente. Diversas so as causas que podem dificultar com que os requisitos funcionais no sejam cumpridos a risca como o cliente esperava. Os principais fatores dizem respeito comunicao. Muitas vezes o cliente no consegue expressar da melhor forma possvel o que precisa e na maioria das vezes nem ele sabe exatamente o que precisa. O fato que isso no totalmente obrigao do cliente. fundamental que o consultor saiba extrair todas essas informaes do cliente. Porm esse trabalho no nada simples e depende de diversos fatores como, por exemplo, a personalidade do cliente em questo.

2 DESENVOLVIMENTO

1) Caso de Uso Controlar Usurio

Caso de uso: Descrio: Ator: Cenrio principal |1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 |Funcionrio solicita cadastro de controle de usurio |Sistema exibe o controle de usurio |Funcionrio escolhe a opo de incluso |Sistema atribui cdigo de cadastro |Funcionrio informa CPF do usurio |Sistema valida CPF digitado |Funcionrio informa os demais dados |Sistema solicita livro a ser emprestado | Sistema solicita data de devoluo | Funcionrio confirma cadastro | Sistema encerra o caso de uso | | | | | | | | | | | Controlar Usurio Fazer cadastro de usurio no sistema da biblioteca Funcionrio usurio

Cenrio Alternativo 3 |3.1 |3.2 |3.3 |3.4 |3.5 |3.6 |3.7 |3.8 |3.9 |3.10 |Funcionrio no escolhe a opo de incluso |Funcionrio digita CPF usurio |Sistema recupera dados do usurio |Sistema permite alterar |Funcionrio escolhe opo de alterar |Funcionrio informa dados a serem alterados |Funcionrio confirma alterao |Sistema atualiza os dados | | | | | | | | | |

|Sistema emite mensagem de confirmando alterao |Sistema encerra uso case (sistema volta pra o passo 8)

Cenrio Alternativo 6

|6.1 |6.2

|Sistema verifica que o CPF no vlido |Sistema permite nova digitao

| |

Cenrio Alternativo 7 |7.1 |7.2 |7.3 |7.4 |Sistema verifica os atributos no foram preenchidos | |Sistema emite mensagem, informando que os atributos no foram |Sistema permite informar os dados no preenchidos |Sistema volta para o passo 8 | |

preenchidos |

2) Tcnica de Modelagem Entidade Relacionamento Entidade: pode ser definida como qualquer coisa do mundo real, abstrata
ou concreta, na qual se deseja guardar informaes. ( Tabela, File, etc.. ). Exemplos de entidades: Cliente, Produto, Contrato, Vendas, etc.

Relacionamentos: estrutura que indica a associao de elementos de

duas ou mais entidades. o fato ou acontecimento que liga dois objetos do mundo real (entidades do modelo).

Cardinalidade: a quantidade de ocorrncias de entidades que podem

estar associadas a uma ocorrncia da entidade que se quer analisar. a regra de negcio entre as entidades envolvidas no relacionamento.

Atributo: a caracterstica ou propriedade, ou ainda o prprio dado

relevante que se quer manter de uma entidade ou at de um relacionamento. Toda entidade possui propriedades ou qualidades que so descritas por atributos e valores, que podem ser associadas a cada ocorrncia de uma entidade ou relacionamento. Atributo Determinante: o atributo que destaca, separa, diferencia uma ocorrncia de outra ocorrncia da entidade, tornando-se o atributo que determina a ocorrncia como nica, passvel de ser encontrada em ambigidade. Atributo Composto: o atributo que pode ser dividido em partes (outros atributos) para representar adequadamente o que se quer.

Atributo Derivado: um atributo cujo valor pode ser obtido atravs do valor de outros atributos. Atributo Multivalorado: um atributo que pode assumir um conjunto de valores para uma nica instncia de entidade. Atributo no Relacionamento: acontece quando o atributo s existe a partir do relacionamento entre entidades.

Administrador de Dados: o responsvel pelo projeto lgico de dados,

pelo conceitual tambm, pela interface entre analistas de sistemas e analistas de suporte e pelo gerenciamento do dicionrio de dados;

Modelo Conceitual: Descreve de forma simples e facilmente

compreendida pelo usurio final as informaes de um contexto de negcios, as quais devem ser armazenadas em um banco de dados. O foco deve ser sempre dirigido ao entendimento e representao de uma realidade, de um contexto.

Modelo Lgico: Descreve as estruturas que estaro no banco de dados,

mas sem considerar, ainda, nenhuma caracterstica especfica de um Sistema Gerenciador de Banco de dados - SGBD. Tem seu incio somente aps a criao do modelo conceitual. J utiliza chaves estrangeiras.

Modelo Fsico: construdo a partir do modelo lgico e descreve as

estruturas fsicas de armazenamento de dados. Descreve o tipo e tamanho dos campos.

3) Modelo do Projeto
Melhor tipo de projeto seria do Windows form aplication. O por que da escolha Windows form aplication? Achei mais pratico que outro modelo menos complicado e mais rpido. Componentes utilizados : Menu strip, para ter acesso as opes do programa como salvar, sair, imprimir, cadastrar, abrir, editar, excluir e pesquisar. Boton, para confirmar os acessos por meio do menu strip quando for confirmar ou concluir uma tarefa no caso de salvar quando acessado ter uma mensagem de sim ou no atravs do boton e para inicar a pesquisa ou confirmar impresso. Date time picker, para guardar a data de quando foi feito a incluso do usurio para facilitar a pesquisa.

Picture box, colocar para visualizar a foto do usurio para saber identificar melhor no somente pelo nome Ferramentas para visualizao de impresso no print dialog, print viewcontrol, print document. Diretory entry para acesso a diretrios no banco de dados Diretory search para facilitar a procura do usurio. List box para selecionar que tipo de livros o usurio locou ultimamente e suas preferncias.

4) Modelos geis e Modelos Evolucionrios

MODELOS GEIS Modelagem gil (AM) uma metodologia baseada na prtica pra modelagem efetiva de sistemas baseados em software. A metodologia AM uma coleo de praticas, guiadas por princpios e valores que podem ser aplicados por profissionais de software no dia a dia. AM no um processo prescrito, ela no define procedimentos detalhados de como criar um dado tipo de modelo, ao invs ela prov conselhos de como ser efetivo como modelador. Pense em AM como uma arte, no como uma cincia. Extreme Programming (XP) XP uma metodologia para desenvolvimento de software gil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prtica e a perseguio da mais clara simplicidade, aplicado ao desenvolvimento de software. Uma metodologia voltada para projetos cujos requisitos mudem com freqncia, utilizem desenvolvimento orientado a objetos, equipes de at 12 desenvolvedores e desenvolvimento incremental. A XP Busca o mximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espao de tempo o cliente ter um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido realmente o desejado. Por ser uma metodologia recente, a XP sofre mudanas em suas concepes e, portanto, comum encontrar variaes. A adaptao ao ambiente de desenvolvimento deve ser levada em conta, se um

valor trouxer mais prejuzos do que benefcios necessrio reavaliar a utilizao desta metodologia. A XP organizada em torno de um conjunto de prticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. Um projeto XP atravessa algumas fases durante o seu ciclo de vida. Essas fases so compostas de vrias tarefas que so executadas. Abaixo ser dada uma explicao das principais fases de um projeto XP de modo a se ter uma idia de como o projeto flui ao longo do tempo. Um projeto XP passa pelas seguintes fases: 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 a viabilidade de tais solues. Os programadores elaboram possveis arquiteturas e tentam visualizar como o sistema funcionar considerando o ambiente tecnolgico (hardware, rede, software, desempenho, trfego) onde o sistema ir rodar. Com isso, os programadores e os clientes vo ganhando confiana, e quando eles possurem estrias suficientes, j podero comear a construir o primeiro release do sistema. A fase de planejamento inicial deve ser usada para que os clientes concordem em uma data para o lanamento do primeiro release. O planejamento funciona da seguinte forma: os programadores, juntamente com o cliente, definem as estrias (use case simplificados) a serem implementadas e as descrevem em cartes. Os programadores assinalam uma certe dificuldade para cada estria e, baseados na sua velocidade de implementao, dizem quantas estrias podem implementar em uma iterao. Depois, os clientes escolhem as estrias de maior valor para serem implementadas na iterao isso chamado planejamento iterao. O processo ento se repete at terminar as iteraes do release. O tempo para cada iterao deve ser de uma a trs semanas e para cada release de dois a quatro meses. Na fase das iteraes do release so escritos os casos de teste funcionais e de unidade. Os programadores vo seguindo mais ou menos o seguinte fluxo de atividades na seguinte ordem (em cada iterao): escrita dos casos de testes; projeto e refatoramento; codificao; realizao dos testes; e integrao. A medida que esse fluxo vai sendo seguido, o sistema vai sendo construdo segundo os princpios, valores e prticas. Depois de terminado o primeiro release, j se ter uma

idia melhor das tecnologias e do domnio do problema de modo que as iteraes podero ser mais curtas nos releases subseqentes e j se podem fazer estimativas mais confiveis com o que se aprendeu das iteraes passadas. A fase de manuteno pode ser considerada como uma caracterstica inerente a um projeto XP. Em XP voc est simultaneamente produzindo-nos funcionalidades, mantendo o sistema existente rodando, incorporando novas pessoas na equipe e melhorando o cdigo. Mecanismos como: refatoramento, introduo de novas tecnologias, e introduo de novas idias de arquitetura podem ser utilizados em um projeto XP. importante ressaltar que a manuteno dada em um sistema que j est em produo deve ser feita com muita cautela, pois uma alterao errada pode paralisar o funcionamento do sistema resultando em prejuzos para o cliente. A fase morte corresponde ao trmino de um projeto XP. Existem duas razes para se chegar ao final de um projeto, uma boa e outra ruim. A boa razo quando o cliente j est satisfeito com o sistema existente e no enxerga nenhuma funcionalidade que possa vir a ser implementada no futuro. A m razo para a morte em XP seria a de o projeto ter se tornado economicamente invivel, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros.

Scrum
Scrum uma metodologia gil para gerenciamento de projetos, geralmente de software, mas pode ser utilizada para outros tipos, como desenvolvimento de produtos fsicos, ou projetos diversos. Foi criada por Jeff Sutherland, Ken Schwaber e John Scumniotales na dcada de 1990, baseada no Pensamento Lean ( Lean Thinking), desenvolvimento iterativo e incremental, e novas estratgias de criao de produtos. Sua aplicao no est limitada a projetos de software. O ciclo de vida do Scrum tem o seu ciclo composto por uma srie de iteraes 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 Product Owner para selecionar e estimar os itens do Product Backlog que acreditam conseguir entregar ao final da Sprint. A prxima fase a execuo da Sprint. Durante a execuo da Sprint, o time controla o andamento do

10

desenvolvimento realizando Reunies Dirias (Daily Meeting) de no mais que 15 minutos de durao, e observando o seu progresso usando 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 o objetivo foi atingido. Logo em seguida, realiza-se a Reunio de Retrospectiva (Sprint Retrospective), uma reunio de lies aprendidas, com o objetivo de melhorar o processo, time e/ou produto para a prxima Sprint.

Feature Driven Development

FDD (Desenvolvimento Orientado por Features) um processo de engenharia de software que tem por foco principal a entrega freqente de software funcional ao cliente. Por ser uma metodologia gil voltada ao desenvolvimento de software, a FDD favorece de maneira incisiva o envolvimento de clientes (internos ou externos) ao processo de planejamento e desenvolvimento do software, pois est baseada num processo de desenvolvimento de software iterativo e incremental. A FDD no foca a programao ou a abrangncia de um modelo bem definido, mas faz uso de um planejamento iterativo, que tem por objetivo abstrair e atender as principais necessidades do negcio, que determinar a forma de atuao da equipe de desenvolvimento. Os passos e o modelo adotado para o desenvolvimento de software pela SYS EVOLUTION so definidos pelas etapas abaixo e compreendem os seguintes processos: Desenvolver Modelo Essa fase definida por uma reunio de entendimento do problema (Planning Meeting), onde os membros da equipe (Scrum Master e Time) e do Cliente (Product Owner) definem o que ser produzido durante a Sprint. Nesse encontro, so definidos os requisitos que sero tratados, ficando a cargo do time a construo dos modelos, artefatos de negcio e User Histories. Os artefatos produzidos nessa fase so: Viso da FBS (Feature Breakdown Structure), Diagrama de Classes de Negcio, definio dos Critrios de Aceitao.

11

Construir Lista de Funcionalidades Nessa fase so construidas as listas de funcionalidades que sero tratadas durante a sprint e a respectiva FBS (semelhante WBS) refinada. Aps a obteno dessa viso, os responsveis por cada um dos modelos, agrupados por Features so nomeados, para que os trabalhos de anlise e desenvolvimento tenham incio. Os artefatos produzidos nessa fase so: FBS: Feature Breakdown Structure e Diagramas de Classe.

Planejar por Funcionalidade O Planejamento de como as funcionalidades sero desenvolvidas marcam essa fase, onde ser definida a sequencia do desenvolvimento das Features, quais as atividades de negcio so atribuidas a seus responsveis de acordo com a classe de desenvolvimento. Os artefatos produzidos nessa fase so: Viso da FBS (Feature Breakdown Structure), Diagrama de Classes. Detalhar por Funcionalidade O detalhamento por funcionalidade nada mais que a anlise do sistema, propriamente dito. Nessa fase, sero descritos os documentos e artefatos de desenvolvimento, juntamente com a documentao das classes e os respectivos Diagramas de Classes e Seqncia. Os artefatos produzidos nessa fase so: Refinamento dos Diagramas de Classes, Diagramas de Sequencia (Atividades, Maquina de Estados e Comunicao, se necessrios), Diagrama Entidade Relacionamento (DER) e Storyboard. Desenvolver por Funcionalidade Nessa etapa, efetuada a implementao das Classes e Mtodos. Como boa prtica, adotamos a reviso do cdigo e a respectiva gerao das evidncias de testes unitrios, antes que sejam aplicados os planos de testes integrados e de profundidade da aplicao gerada. Os principais artefatos gerados ao final dessa etapa so o Cdigo, Diagrama de Classes (Final), Telas Funcionais e Testes Unitrios.

12

Dynamic Systems Development Method

DSDM uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usurio. Seu objetivo entregar softwares no tempo e com custo estimados atravs do controle e ajuste de requisitos ao longo do desenvolvimento. O framework DSDM consiste em trs fases seqenciais: Pr-Projecto, Projecto e Ps-Projecto. A fase de Projecto do DSDM a mais elaborada das trs fases. Ela consiste em 5 nveis formados por uma abordagem passo-a-passo e iterativa no desenvolvimento de um SI. O Ciclo de Vida do Projecto:

Ciclo de Vida do Projecto nesta segunda fase da metodologia. Ela mostra os 5 nveis que a equipe de desenvolvimento ter de percorrer para criar um SI. Os dois primeiros nveis, o Estudo de Viabilidade e o Estudo de Negcio, so fases seqenciais que se complementam. Depois de estas fases estarem concludas, o sistema desenvolvido iterativamente e de forma incremental nos nveis de Anlise Funcional, Desenho e Implementao.

Crystal
O Crystal uma famlia de modelos geis de processo que podem ser adotados para as caractersticas especficas de um projeto. Como outras

13

abordagens geis, o Crystal adota uma estratgia iterativa, mas ajusta o rigor do processo de modo a acomodar projetos de diferentes tamanhos e complexidades. O ciclo de vida desta famlia baseado nas seguintes prticas: Staging: Planejamento do prximo incremento do sistema. A equipe seleciona os requisitos que sero implementados na iterao e o prazo para sua entrega; Edio e reviso (Construction Demonstration Review): Construo,

demonstrao e reviso dos objetivos do incremento; Monitoramento (Monitoring of Process): O processo monitorado com relao ao progresso e estabilidade da equipe. medido em marcos e em estgios de estabilidade; Paralelismo e fluxo (Parallelism and flux): Em Crystal Orange as diferentes equipes podem operar com o mximo paralelismo. Isto permitido atravs do monitoramento da estabilidade e da sincronizao entre as equipes; Inspees de usurios: so sugeridas duas a trs inspees feitas por usurios a cada incremento; Workshops refletivos: so reunies que ocorrem antes e depois de cada iterao com objetivo de analisar o progresso do projeto. Local matters: so os procedimentos a serem aplicados, que variam de acordo com o tipo de projeto. Work Products (Produtos de Trabalho): seqncia de lanamento, modelos de objetos comuns, manual do usurio, casos de teste e migrao de cdigo. Especificamente para o Clear: casos de uso e descrio de funcionalidade; Especificamente para o Orange: documento de requisitos. Standards (padres): padres de notao, convenes de produto, formatao e qualidade usadas no projeto.

14

Tools:

ferramentas

mnimas

utilizadas.

Para

Crystal

Clear:

compiladores,

gerenciadores de verso e configurao. Para Crystal Orange: ferramentas de verso, programao, teste, comunicao, monitoramento de projeto, desenho e medio de performance.

MODELOS EVOLUCIONRIOS Os Modelos Evolucionrios baseiam-se na idia de desenvolvimento de uma implementao inicial, expondo o resultado ao cliente e refinando esse resultado por meio de vrias verses, para que ento seja desenvolvido o sistema adequado.

Prototipao
Prototipao a montagem de prottipos, ela pode ser classificada de acordo com uma variedade de dimenses. A abordagem de prototipao tem um nmero de vantagens importante a oferecer, das quais ns indicamos a mais importante delas aqui. Primeira todo o requisitos de sistema no tem que ser completamente determinado antecipadamente e pode mesmo ser trocada durante o curso do projeto. Segundo, a entrega de prototipao clara, definies de sistema entendvel e especificaes para o usurio final. Como conseqncia, o envolvimento e satisfao do usurio final so fortemente aumentados. Finalmente, prototipao faz isso possvel para rapidamente testar o ambiente de desenvolvimento voltado para a funcionalidade, performance, interface com banco de dados, etc. (IBM, 2002).

15

Porm algumas desvantagens podem ser apontadas como, por exemplo, a modelagem iniciada suficientemente para a antecipadamente, sem ter uma analise de uma situao ateno e devotada desejada, corrente

reconhecimento do problema e formulao do problema que so pelo menos to importantes como a prpria soluo. Especialmente na prototipao evolucionria o perigo da falha do projeto existe: toda iterao ajusta o prottipo de uma forma que menos da funcionalidade desejada ou funcionalidade suprflua incorporada dentro do prottipo (IBM, 2002). Um perigo final que a prototipao pode lidar com entusiasmo do usurio final. O processo de prototipao pode dar ao usurio final a impresso que praticamente qualquer sugesto pode ser implementada, no importa qual estgio do processo de desenvolvimento se est. Alm disso, para os usurios no est claro o porqu da demora para entregar a aplicao final depois que uma verso demo do sistema foi exibida.

Modelo de processo de Prototipao

Modelo Cascata
Um dos mais antigos, e ainda um dos mais usados! Vrias atividades executadas de forma sistemtica e seqencial.

16

Fixa pontos especficos para a entrega de artefatos. simples e fcil de aplicar, facilitando o planejamento. Na prtica, existe uma interao entre as atividades e cada atividade pode levar a modificaes nas anteriores. Na maioria dos casos existe interao e superposio! Pressupe que os requisitos ficaro estveis Atrasa a reduo de riscos

Modelo Espiral
Tambm mescla o modelo seqencial linear com o da prototipagem. Oferece potencial para desenvolvimento rpido de verses incrementais do software. Nos primeiros incrementos podem ser usados papel ou prottipo. Durante os ltimos incrementos so produzidas verses cada vez mais completas do sistema submetido engenharia. So utilizadas as seguintes tarefas: 1. Comunicao com o cliente; 2. Planejamento - Tarefa necessria para definir recursos, prazos e outras informaes relacionadas ao projeto; 3. Anlise de risco; 4. Engenharia - Tarefa necessria para construir uma ou mais representaes da aplicao; 5. Construo e liberao - tarefas necessrias para construir, testar, instalar e

17

fornecer apoio ao usurio (documentao e treinamento); 6. Avaliao pelo cliente.

Modelo de processo em Espiral

Modelo RAD (Rapid Application Development)

Modelo de desenvolvimento incremental que enfatiza um ciclo de

desenvolvimento extremamente curto. O modelo RAD uma adaptao de alta velocidade do modelo linear que conseguido pelo desenvolvimento baseado em componentes. Se os requisitos so bem compreendidos (a podemos encaixar a questo do modelo de prototipagem, mas perderia a caracterstica de desenvolvimento rpido) e o objetivo do projeto restrito, o RAD permite criar sistemas plenamente funcionais dentro de perodos muito curtos (entre 60 e 90 dias - sistemas, no sites. Sites seriam menos tempo ainda). Usa as seguintes fases: Modelagem do negcio O fluxo de informaes entre as funes do negcio modelado visa responder as seguintes questes: Que informao dirige o processo do negcio? Que informao gerada? Quem a gera? Para onde vai a informao? Quem a

18

processa? (tem mais detalhes aqui no livro sobre modelagem do negcio). Modelagem de dados O fluxo de informaes definido anteriormente refinado num conjunto de objetos dados que so necessrios para dar suporte ao negcio. Os atributos de cada objeto so identificados e as relaes entre esses objetos so definidas (ainda anterior ao Use Case... como se estivssemos definindo os atores e os use cases sem definir a relao entre eles... - isso que eu entendi vendo o item seguinte). Modelagem do processo Os objetos de dados definidos na fase anterior so transformados para conseguir o fluxo de informao necessrio para implementar uma funo do negcio. Descries do processamento so criadas para adicionar, modificar, descartar ou recuperar um objeto de dados (acho que aqui monta-se propriamente o use case). Gerao da aplicao Ao invs de usar linguagens procedimentais, o RAD usa linguagens de 4 gerao (4GL um exemplo - permite que defina a especificao do projeto e a FRAMEWORK cria tudo... relatrios, cadastros, etc. - lembra da idia do gerador de sites? Acho que por a, mas para aplicaes mesmo). Seu desenvolvimento feito para reutilizar componentes (quando possvel) ou criar novos componentes reutilizveis. Em todos os casos ferramentas automatizadas so usadas para facilitar a construo do software. Teste e entrega Como o processo RAD tem foco nos componentes, muitos dos componentes j devem ter sido testados. Isso reduz o tempo total de teste. Porm novos componentes devem ser testados e as interfaces exaustivamente exercitadas. Se uma aplicao comercial pode ser modularizada de modo a permitir que cada funo

19

principal possa ser completada em menos de trs meses usando a abordagem anterior, ela candidata ao RAD. Cada funo pode ser tratada por uma equipe RAD distinta e depois integrada para formar um todo.

Modelo Incremental
Combina elementos do modelo seqencial linear com a filosofia interativa da prototipagem. Cada seqncia linear produz um incremento. Por exemplo: Se fssemos desenvolver um site, no primeiro incremento teramos as funcionalidades sobre a empresa, contato e produtos. Em um segundo incremento teramos acesso restrito para clientes, newsletter, enquete e assim se seguiria durante todo o processo de desenvolvimento. Quando este modelo usado, o primeiro incremento tido como o ncleo do sistema. Ele usado pelo cliente e ento necessrio fazer um plano para o prximo incremento como resultado do uso/avaliao. O plano visa melhorar o ncleo e adicionar novas funcionalidades, que por sua vez sero testadas e alteradas para adequarem s solicitaes do cliente e assim por diante. A grande diferena do modelo incremental para o modelo de prototipagem que a cada incremento o cliente j possui um modelo utilizvel e aprovado.

incremento 1: ANLISE -> PROJETO -> CODIFICAO -> TESTE incremento 2: ANLISE -> PROJETO -> CODIFICAO -> TESTE incremento 3: ANLISE -> PROJETO -> CODIFICAO -> TESTE

20

21

3 CONCLUSO A criao de um software muito importante, podemos estudar sobre o estabelecimento do cliente, trocar idias com os funcionrios, com os clientes da empresa, para poder obter mais informaes; Fazer reunies, com o cliente e funcionrios de reas diferente da empresa, para um conhecimento, melhor e poder desenvolver um software mais confivel e com menos erros. Ter conhecendo da tcnica usada e assim desenvolver um bom e confivel trabalho no desenvolvimento de um software, para que o cliente no tenha problema futuros com a perda de informaes, que hoje em dia o mais importante nas empresas, assim podendo escolher em desenvolver um software usando ou um modelo gil ou evolucionrio, assim o desenvolvimento poder, com certeza ser bem sucedido e deixar o cliente satisfeito. Para isso o profissional da rea tem que ser responsvel e seguir os passos por ele determinado na construo de um trabalho, executando com perfeio procurando o mximo de informaes possveis onde est sendo realizado o trabalho. Atravs do estudo de um Caso de Uso, temos a oportunidade de visualizar graficamente elementos do mundo real, observando a documentao necessria para compreenso do trabalho a ser realizado. A utilizao do modelo Entidade Relacionamento de suma importncia para representao grfica daquilo que queremos representar facilitando a compreenso daqueles envolvidos na construo do projeto. Os modelos geis e Evolucionrios que so apresentados nesse trabalho mostram a necessidade em eleger um modelo de ciclo de vida, pois influenciaria de forma significativa no desenvolvimento de um produto, onde o objetivo principal um resultado que demonstre qualidade, tanto no andamento, e principalmente no seu resultado final.

22

REFERNCIAS

http://pt.scribd.com/doc/56695853/16/Modelos-Evolucionarios http://www.vivaolinux.com.br/artigo/Modelos-de-desenvolvimento?pagina=1 http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software http://www.ime.usp.br/~gdaltonl/ageis/ageis_6pp.pdf

Nishimura,Roberto Yukio Banco de dados I: sistemas II / Roberto Yukio Nishimura.So Paulo : Pearson Prentice Hall, 2009 Tanaka,Simone Sawasaki Anlise de sistemas I :sistemas / Simone Tanaka. So Paulo : Pearson Prentice Hall,2009