5.1 MODELOS GEIS 5.1.

1 Extreme Programming O sucesso e popularidade adquiridos por XP se devem principalmente aos relatos de bons resultados obtidos em projetos, a motivao dos profissionais envolvidos com XP e tambm devido a sua natureza simples e objetiva por se basear em prticas que j provaram sua eficincia no cenrio do desenvolvimento de software. Essas prticas tm como objetivo entregar funcionalidades de forma rpida e eficiente ao cliente. Alm disso, XP foi criado considerando que mudanas so inevitveis e que devem ser incorporadas constantemente. 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, performance, 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 do projeto ter se tornado economicamente invivel, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros. A imagem abaixo mostrar o ciclo de vida do modelo Extreme Programming.

5.1.2 Scrum Foi desenvolvido inicialmente por Jeff Sutherland e por sua equipe no incio da dcada de 1990. O Scrum, usa um conjunto de padres de processo de software, que so adequados para projetos com prazos apertados e requisitos que mudam freqentemente. Cada padro de processo define um conjunto de atividades. O ciclo de vida do Scrum baseado em trs fases principais: Pr-planejamento (Pre-game phase): os requisitos so descritos e priorizados no Product Backlog. O planejamento inclui tambm a estimativa de esforo para cada requisito, definio da equipe de desenvolvimento, as ferramentas a serem usadas, os possveis riscos do projeto, as necessidades de treinamento e uma proposta de arquitetura de desenvolvimento baseada na lista de tarefas. Desenvolvimento (Game phase): o software desenvolvido sprints, que duram de acordo com o TIME-BOX, e na qual cada equipe recebe uma parte do backlog para desenvolvimento. Sempre apresenta um produto executvel ao final. a) Daily SCRUM: com durao estipulada, a qual gerenciada pelo lder de cada equipe e que tem como objetivo a maior integrao da equipe, rpida soluo de problemas e medida do progresso contnua. b) Reviso: Apresentao do produto ao cliente, tendo como finalidade a apresentao de resultados concretos ao cliente, integrao e testes de parte do software e motivao da equipe. Ps-planejamento (post-game phase): iniciada quando todos os tpicos so satisfatrios tempo, competitividade, requisitos, qualidade, custo). Atividades: testes de integrao, testes de sistema, documentao do usurio, preparao de material de treinamento, preparao de material de marketing.

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, chamadas Sprints. Antes de cada Sprint, realiza-se uma reunio de planejamento (Sprint Planning Meeting) em que os membros do time tem 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 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. 5.1.3 Feature Driven Development Feature-Driven Development (FDD) uma metodologia gil para o processo de engenharia de software, que foi elaborada com foco na entrega frequente de software funcionando para os clientes e na utilizao de boas prticas durante o ciclo de seu desenvolvimento. Uma caracterstica marcante da FDD o fato dela favorecer fortemente o envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software. Feature-Driven Development (FDD) um processo de desenvolvimento de software iterativo e incremental. Diferentemente de outras metodologias, a FDD no extremamente focada na programao ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos. O ciclo de vida da FDD composto de 05(cinco) prticas. So elas: Desenvolver um modelo abrangente: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto. Formar o time de modelagem: este time normalmente composto por especialistas de negcio e programadores, sendo facilitados por um arquiteto com experincia em modelagem. Conduzir o Domain Walkthrough(Estudo dirigido sobre o domnio): os especialistas de negcio apresentaro ao restante da equipe uma viso do produto. Aps isso, realizaro apresentaes focadas em pequenas partes do negcio. Estudar documentao: Dependendo da complexidade da rea de negcio apresentada, a equipe pode solicitar um intervalo para estudar a documentao fornecida pelo especialista de negcio.

Desenvolver modelos de pequenos grupos: aps cada apresentao(ou estudo), a equipe dividida em pequenos grupos, que elaboraro uma proposta de modelo (sem detalhamento) para aquela parte especfica do negcio que foi apresentada. Desenvolver o modelo da equipe: as propostas so apresentadas e uma delas, ou uma combinao delas, escolhida por consenso para ser o modelo para aquela parte do negcio apresentada. Refinar o modelo abrangente: o modelo escolhido incluso no modelo abrangente do produto. Este modelo abrangente o resultado da juno de todos os modelos escolhidos para cada parte do negcio apresentada. Escrever notas: notas e observaes so includas no modelo abrangente. As atividades vo se repetindo at que tenhamos um modelo abrangente que cubra todas as partes de negcio previstas para o produto(ou release). Construir a lista de funcionalidades: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto. Formar o time da lista de funcionalidades: normalmente, este time composto unicamente pelos programadores chefes que participaram do processo anterior. Construir a lista de funcionalidades: as partes do produto, que foram identificadas e modeladas no processo anterior, so aqui identificadas como reas de negcio. Dentro de cada rea de negcio, o time deve conseguir identificar as atividades de negcio daquela rea especfica e, dentro destas atividades, as funcionalidades que a compem. Planejar por funcionalidades: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto. Formar o time de planejamento: normalmente este time composto pelo gerente de projeto, gerente de desenvolvimento e programadores-chefes. Determinar a sequncia do desenvolvimento: o time determina a seqncia do desenvolvimento baseando-se nas dependncias entre elas, na carga de trabalho da equipe de desenvolvimento e tambm na complexidade das funcionalidades a serem implementadas. Atribuir atividades de negcio aos programadores-chefes: cada programador-chefe fica responsvel por um conjunto de atividades de negcio. Ele ser o programador-chefe de todas as funcionalidades que compem suas atividades. Atribuir classes aos desenvolvedores: cada classe passar a ter um dono. Estedono, que um programador, ser o responsvel por qualquer manuteno necessria naquela classe. As classes so distribudas pelo time levando em considerao a experincia, carga e sequncia de trabalho de cada desenvolvedor. Detalhar por funcionalidade: este processo ser executado uma vez para cada funcionalidade.

Formar a(s) equipe(s) de funcionalidades: sabendo quais as classes que sero envolvidas no desenvolvimento de determinada funcionalidade, o programador-chefe convoca os desenvolvedores responsveis por cada classe envolvida para fazer parte da equipe. Conduzir Domain Walkthrough(Estudo dirigido sobre o domnio): dependendo do nvel de complexidade da funcionalidade e de quo clara ela est para a equipe, o programador-chefe pode convocar um especialista de negcio para promover uma apresentao detalhada daquela funcionalidade para a equipe. Estudar documentao relacionada: ainda dependendo do nvel de entendimento do time, pode ser reservado um perodo para ser estudada documentao de negcio e anotaes relacionadas quela funcionalidade. Desenvolver diagrama(s) de sequncia: o time desenvolve o(s) diagrama(s) de sequncia relacionado(s) quela funcionalidade. Refinar o modelo abrangente: j com um maior entendimento do negcio, o time se sente seguro em refinar o modelo abrangente, incluindo mtodos e atributos nas classes envolvidas no desenvolvimento da funcionalidade. Escrever prlogo de mtodos e classes: Com as informaes geradas pelo(s) diagrama(s) de sequncia, cada programador responsvel por criar os prlogos de suas classes. Isto inclui cabealhos de mtodos com tipagem de parmetros, atributos e outros. Vale lembrar que apenas os prlogos so criados aqui, nada de implementao deve ser realizado. Inspeo de design: o programador-chefe da funcionalidade deve convidar algum outro membro do time do projeto para avaliar o que foi feito em sua classe durante este processo. Desenvolver por funcionalidade: este processo ser executado uma vez para cada funcionalidade. Implementar classes e mtodos: cada desenvolvedor implementa suas classes e mtodos de acordo com a viso abrangente e detalhamento realizado nos processos anteriores. Inspecionar cdigo: cada desenvolvedor deve convidar algum outro membro do time(da funcionalidade ou do projeto) para avaliar o que foi feito em sua classe durante este processo. Teste unitrio: cada desenvolvedor responsvel por executar os testes de unidade nos mtodos de suas classes para garantir o alcance das necessidades do negcio. Promover a build: estando a classe inspecionada e testada, ela ento pode ser promovida a build.

5.1.4 Dynamic Systems Development Method O frameword DSDM consiste de 3 fases seqenciais, nomeadas de pr-projeto, ciclo de vida e ps-projeto. O ciclo de vida a fase mais elaborada das 3. Consiste em 5 estgios que formam

o passo-a-passo das iteraes aplicadas ao desenvolvimento do sistema.

Fase 1 - O Pr-Projeto: no pr-projeto so identificados os projetos candidatos, so definidos oramento e assinatura do contrato. Controlando estes critrios antecipadamente pode-se evitar problemas futuros e em estgios mais crticos. Fase 2 - O Ciclo de Vida

A imagem acima mostra um completo ciclo de vida do DSDM. Isto ilustra os 5 estgios que um projeto possui para o desenvolvimento de um sistema. Os dois primeiros estgios, Anlise de viabilidade e negcios so fases seqenciais que se completam entre si. Aps a concluso destas fases, o sistema desenvolvido iterativamente e incrementalmente segundo as iteraes do Modelo Funcional, desenho e construo, at implementao. Nvel 1: O Estudo de Viabilidade: durante este nvel do projeto, a viabilidade de utilizao da DSDM para este projeto examinada. Os pr-requisitos para o uso da DSDM so encontrados respondendo a questes como: Pode este projeto ir de encontro s necessidades de negcio apontadas?, , este projeto, adequado ao uso da DSDM? e Quais so os riscos mais importantes envolvidos?. As tcnicas mais importantes utilizadas nesta fase so os workshops. Para entrega ao cliente, so preparados neste nvel o Relatrio e o Prottipo de Viabilidade que dizem respeito viabilidade do projeto em mos. A estes, adicionam-se um esboo global do plano para o resto do projeto e um Registro de Risco que identifica os riscos mais importantes no projeto. Nvel 2: O Estudo do Negcio: o Estudo do Negcio incrementa todo o trabalho realizado no Estudo de Viabilidade. Depois do projeto ser declarado fivel para o uso da DSDM, este nvel examina o processo de financiamento, os utilizadores envolvidos e as suas necessidades e desejos respectivos. Uma vez mais, os workshops so uma das mais valiosas tcnicas. Workshops nos quais os diferentes stakeholders se renam e discutam o sistema proposto. A informao retirada destas sesses combinada numa lista de requisitos. Uma importante propriedade desta lista de requisitos a possibilidade de se definir prioridades. Estas prioridades so definidas utilizando uma perspectiva MoSCoW. Baseado neste escalonamento, um plano de desenvolvimento construdo como uma linha mestra para o resto do projeto. Uma importante tcnica utilizada no desenvolvimento do plano a tcnica de Timeboxing2. Esta tcnica essencial para serem atingidos os objetivos da DSDM, nomeadamente a imposio de tempo e oramento fixos, garantindo no entanto a qualidade desejada. Uma arquitetura de sistema outro meio para guiar o desenvolvimento do Sistema de Informao. No final deste nvel, devero estar prontos para entrega ao cliente: uma definio de rea de negcio que descreve o contexto do projeto dentro da companhia, a definio da arquitetura do sistema que fornece uma arquitetura global inicial do SI em desenvolvimento juntamente com o plano de desenvolvimento que reala os passos mais importantes no processo de desenvolvimento. Na base destes dois ltimos documentos est a lista de prioridades dos

requisitos. A lista define todos os requisitos do sistema, organizados de acordo com o princpio do MoSCoW. Por fim, o Registro de Risco atualizado com os fatos que foram identificados durante esta fase da DSDM. Nvel 3: Anlise Funcional: os requisitos que foram identificados nos nveis anteriores so convertidos para um Modelo Funcional. A Prototipagem uma das tcnicas chave dentro deste nvel, que ajuda no bom envolvimento do utilizador final com o projeto. O prottipo desenvolvido revisto pelos diferentes grupos de utilizadores. Para assegurar a qualidade do projeto, os testes so implementados em cada iterao da DSDM. Uma importante parte dos testes so realizados na Anlise Funcional. O Modelo Funcional pode ser subdividido em quatro sub nveis: Identificar Prottipo Funcional: determinar as funcionalidades a serem implementadas no prottipo que resulta desta iterao. Acordar Calendrio de Tarefas: definir como e quando desenvolver estas funcionalidades. Criar Prottipo Funcional: desenvolver o prottipo. Rever o Prottipo: procurar correes possveis no prottipo desenvolvido. Isto pode ser feito atravs de testes com utilizadores finais e revendo a documentao. Neste nvel, necessrio entregar ao cliente o Modelo Funcional e o Prottipo Funcional que, juntos, representam as funcionalidades que podem ser realizadas nesta iterao, prontas para serem testadas pelos utilizadores. Alm destes dois documentos, a Lista de Requisies atualizada, sendo apagados os itens que foram implementados e repensando as prioridades dos requisitos restantes. Nvel 4: Desenho: o ponto central desta iterao da DSDM a integrao das componentes funcionais do nvel anterior num sistema que satisfaa as necessidades do utilizador. Mais uma vez, os testes so uma das atividades mais importantes. O Desenho pode ser dividido em quatro sub nveis: Identificar Prottipo de Desenho: identificar requisies funcionais e no-funcionais que so necessrios no sistema testado. Acordar Calendrio de Tarefas: definir como e quando desenvolver estes requisitos. Criar Prottipo de Desenho: criar um sistema que possa, com segurana, ser fornecido aos utilizadores finais para um uso dirio. Rever Prottipo de Desenho: verificar a exatido do sistema desenhado. Mais uma vez, os testes e revises so peas fundamentais. Ao utilizador, sero entregues o Prottipo de Desenho para que estes efetuem testes ao produto-prottipo. Nvel 5: Implementao: No nvel de Implementao, o sistema testado e a sua documentao so entregues aos utilizadores finais que devero comear a ser treinados para a futura utilizao do novo SI. O sistema a ser entregue foi revisto para incluir todos os requisitos que

foram definidos nos primeiros nveis do projeto. O nvel de implementao pode ser dividido em quatro sub nveis: Aprovao do utilizador: os utilizadores finais aprovam o sistema testado para implementao e as linhas mestras para a implementao e uso do sistema so criadas. Treinar os utilizadores: treinar os futuros utilizadores no uso do sistema. Implementao: implementar o sistema testado no local de trabalho dos utilizadores finais. Rever Negcio: rever o impacto do sistema implementado no negcio, um problema central ser tentar compreender se o sistema vai de encontro aos objetivos definidos no incio do projeto. Dependendo disto, o projeto passar para a fase seguinte, o Ps-Projeto ou voltar a uma das fases anteriores para desenvolvimento posterior. No final deste nvel, o sistema dever ser entregue e instalado, pronto para o uso de todos os utilizadores finais e a Documentao de Utilizao do Sistema dever ser detalhada. Fase 3 - Ps-projeto: esta fase garante a eficincia e eficcia do projeto. Atravs de manutenes, melhorias e ajustes de acordo com os princpios do DSDM. A manuteno pode ser vista como um contnuo desenvolvimento. Invs de finalizar o ciclo de vida de apenas 1 vez, normalmente o projeto pode retomar fases/etapas anteriores a fim de refinar ainda mais o passo concludo. 5.1.5 Crystal A famlia Crystal inclui grande nmero de diferentes mtodos que so selecionados de acordo com as caractersticas do projeto a ser desenvolvido. Atualmente, tm-se quatro mtodos, e apenas dois dos mtodos mantm o desenvolvimento de novas prticas para cobrir diferentes tipos de projetos. Os membros da famlia Crystal so identificados por cores.Quanto mais escura for a cor do mtodo, maior a complexidade do projeto. Existem algumas caractersticas comuns famlia Crystal, como o desenvolvimento incremental com ciclos de no mximo quatro meses, grande nfase na comunicao e cooperao das pessoas, no limitao de quaisquer prticas de desenvolvimento, ferramentas ou produtos de trabalho e incorporao de objetivos para reduzir produtos de trabalho intermedirios e desenvolv-los como projetos evoludos. 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): sequncia 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. 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.

Ciclo de vida da famlia Crystal 5.2 MODELOS EVOLUCIONRIOS 5.2.1 Modelo Espiral 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 paradigmas. O modelo define quatro importantes atividades representadas por quatro quadrantes: 1. Planejamento: determinao dos objetivos, alternativas e restries. 2. Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos. 3. Engenharia: desenvolvimento do produto no nvel seguinte . 4. Atualizao feita pelo cliente: avaliao dos resultados da engenharia. Ele usa uma abordagem evolucionria engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipao como um mecanismo de reduo de riscos, mas, o que mais importante,

possibilita que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma considerao direta dos riscos tcnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos. O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as caractersticas positivas da gerncia (documento associado s fases do ciclo) do modelo de cascata com as fases sobrepostas encontradas no modelo incremental e, tambm,com as verses anteriores de um sistema do modelo de prototipao. O modelo em espiral parte do princpio de que a forma do desenvolvimento de software no pode ser completamente determinada de antemo. A prototipao vista como um meio de reduo de riscos, a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo caracteriza-se como um gerador de modelo de processo. Cada ciclo do modelo em espiral possui quatro atividades principais: - Elaborar objetivos, restries e alternativas para entidades de software. - Avaliar alternativas com relao aos objetivos e restries, e identificar as principais fontes de riscos. - Elaborar a definio das entidades de software em um projeto. - Planejar o prximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco.

5.2.2 Modelo Incremental Combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental interativo igual prototipagem, mais diferente a prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado. Esse modelo muito til quando a empresa no possui mo de obra disponvel no momento para uma implementao completa, dentro do prazo estipulado. 5.2.3 Modelo de Montagem de Componentes Desenvolvimento baseado em componentes ou component-based development (CBD) tambm conhecido como component-based software engineering (CBSE) ou simplesmente componente de software, no define o que um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientao a objetos baseando-se em uma classe como cdigo reutilizvel, ou seja, o componente. Em orientao a objetos uma classe encapsula dados e algoritmos e este ltimo tambm pode ser usado para manipular os dados.

Caracteriza-se esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criao de software. Atravs desta abordagem uma biblioteca de classes construda com as classes identificadas no desenvolvimento do software e a partir de ento toda iterao da espiral dever verificar o contedo da biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas na biblioteca para posterior reuso. Segue os seguintes passos implantados com uma abordagem evolucionria: 1. Pesquisa e avaliao de componentes disponveis para o domnio em questo. 2. Consideraes sobre a integrao de componentes. 3. Projeto de arquitetura de software. 4. Integrao dos componentes arquitetura. 5. Testes para garantir a funcionalidade adequada.

5.2.4 Modelo de Desenvolvimento Concorrente representado como uma srie de grandes atividades tcnicas, tarefas e seus estados associados. Define uma srie de eventos que podem disparar transies de um estado para outro, para cada uma das atividades de ES. utilizado para o desenvolvimento de aplicaes Cliente/Servidor. Pode ser aplicado a qualquer tipo de desenvolvimento de software e fornece uma viso exata de como est o estado do projeto.

5.2.5 Modelo Prototipagem Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construdo quando os requisitos esto confusos. Mais comumente usado como uma tcnica que pode ser implementada dentro de qualquer modelo. Prottipo: verso preliminar do software. Pode ser um programa ou no papel. Concentra-se na representao dos aspectos do software que so visveis para o cliente. Lay-out da interface Entradas e sadas

O cliente tem que concordar que o prottipo ser usado apenas para levantar requisitos. O software real ser desenvolvido com olho na qualidade. Clico de vida do modelo Prototipagem: Obteno dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos so conhecidos e as reas que necessitam de definies adicionais. Projeto Rpido: representao dos aspectos do software que so visveis ao usurio (abordagens de entrada e formatos de sada). Construo Prottipo: Implementao rpida do projeto Avaliao do Prottipo: Cliente e desenvolvedor avaliam o prottipo Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iterao que pode conduzir primeira atividade at que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito. Construo Produto: Identificados os requisitos, o prottipo deve ser descartado e a verso de produo deve ser construda considerando os critrios de qualidade.