METODOLOGIAS

METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS1. Metodologias de Desenvolvimento1.1 Conceito de MetodologiaO termo metodologia, apesar de ser amplamente utilizado, no possui uma definio amplamente aceita. A nvel geral, entende-se como metodologia uma srie recomendada de passos e procedimentos que devem ser seguidos para obter-se o desenvolvimento de um sistema de informao (Yourdon, 1995, p. 97).

De acordo com Avison e Fitzgerald (1997, p.10), o conjunto formado por procedimentos, tcnicas, ferramentas e documentao que auxiliar os responsveis pelo desenvolvimento de sistemas em seus esforos na implementao de um novo sistema de informao. Uma metodologia consistir de fases, cada uma consistindo de sub-fases, que orientaro estes responsveis na escolha das tcnicas que devero ser mais apropriadas a cada estgio do projeto e tambm auxili-los a planejar, gerenciar, controlar e avaliar o projeto do sistema de informao.

Maddison apud Avison e Fitzgerald (1997, p.418) define metodologia como sendo um conjunto recomendado de filosofias, fases, procedimentos, tcnicas, regras, ferramentas, documentao, gerenciamento e treinamento para o desenvolvimentos de um sistema de informao. Verifica-se neste conceito a incluso, entre outros, de filosofias que so as teorias e crenas que norteiam os objetivos e procedimentos de uma metodologia.

As atividades de uma metodologia podem ser adaptadas a cada tipo de projeto, de acordo com o ambiente tecnolgico, complexidade e limitaes de prazo ou de natureza econmica.

O uso de uma metodologia significa basicamente que se estar seguindo um mtodo j testado, slido e consistente que proporcionar com qualidade e eficincia, documentos que representaro aspectos ou vises do problema relatado pelo cliente. sempre bom lembrar que o problema do cliente que fornece informaes a respeito do seu negcio, os requisitos para a soluo e como ela deve ser. A metodologia ajudar a manter o papel de analista do negcio, das atividades que o cliente desempenha e que preciso ser melhoradas, uma vez que ao longo do processo de construo da soluo, apoiando-se nas especificaes e documentos extrados da metodologia, pode-se com segurana e facilidade, determinar a melhor alternativa para aquela soluo, considerando as limitaes e expectativas que o cliente manifestou.

Existem vrias metodologias de desenvolvimento disponveis, como por exemplo:

Convencional ou cascata;

Incremental;

Iterativo;

Espiral;

Prototipao;

RUP;

Extreme Programming (XP).

1.2 Vantagens do uso de uma metodologia Ganho de Produtividade: eficaz em definir o problema a ser resolvido, esclarecendo para toda equipe atravs da documentao gerada, todo o escopo da soluo e seus aspectos relevantes. Documentao: Registra a memria do trabalho que est sendo desenvolvido, servindo para futuras revises e implementaes. Padronizao: Ao utilizar os padres citados na MDS, elimina-se os projetos em que s o fulano sabe como funciona. O conhecimento registrado entendido por qualquer outro tcnico habilitado da Empresa. Organizao: Seguir a metodologia substitui o processo artesanal e emprico de construo de sistemas.

1.3 O Modelo em Cascata

Desenvolvido no final da dcada de 1960 e comeo da dcada de 1970, o modelo Waterfall ainda hoje a abordagem mais praticada no desenvolvimento de sistemas de informao. Esta abordagem assume que um sistema de informao tem um ciclo de vida semelhante ao de qualquer produto, com incio, meio e fim. Cada etapa do ciclo de vida pressupe atividades que devem ser completadas antes do incio da prxima etapa.

Baseado nesta abordagem, Laudon e Laudon (1996, p. 439) apresentam seis estgios que compe o ciclo de vida de um sistema de informao:

Definio de Projeto: Busca-se compreender o motivo da necessidade do projeto de um novo sistema de informao. Determina se a organizao possui um problema e se este problema pode ser resolvido atravs da construo de um novo sistema de informao ou da modificao de outro j existente.

Estudo dos Sistemas: Consiste na anlise detalhada dos sistemas existentes (manuais ou autmatos), identificando seus objetivos, pontos fortes e fracos, alternativas viveis para estes, e descrevendo as atividades das demais etapas do ciclo de vida que sero necessrias para este novo sistema de informaes.

Projeto: Esta etapa produz as especificaes de projeto fsicas e lgicas para a soluo.

Programao: Transforma as especificaes de projeto produzidas na etapa anterior em programas - softwares. Analistas de sistemas trabalham juntamente com programadores preparando para estes especificaes que descrevem o que cada programa dever fazer, o tipo de linguagem de programao que dever ser utilizada, as entradas e sadas deste, etc.

Instalao: Consiste na etapa final de colocao do novo sistema ou modificao de um existente em operao. Testes de validao de suas funes so atividades tpicas desta fase.

Ps-Implementao: Utilizao e avaliao do sistema aps sua instalao. Inclui atualizaes, correes, etc.

Outros autores, apresentam apenas quatro etapas: anlise, projeto, codificao e teste. Nesta situao, algumas etapas englobam atividades que Laudon e Laudon distriburam em duas, como por exemplo, a etapa da anlise consistiria da definio do projeto e estudo do sistema. Esta diferena encontrada nas atividades relacionadas a cada estgio em nada modifica o modelo Waterfall.

Mesmo sendo amplamente utilizado, o modelo em cascata apresenta algumas limitaes:

Confirmao tardia da resoluo de riscos crticos

Mede o progresso por meio de produtos que do uma previso de concluso pobre

Retarda e agrega integrao com testes

Impossibilita entrega a curto prazo de mdulos

Freqentemente resulta em iteraes grandes e no planejadas Uma vez que considera que uma etapa deve ser iniciada aps a concluso das atividades da etapa anterior, gasto uma quantidade razovel de tempo e esforos levantando informaes, especificando e documentando-as a cada etapa para sua posterior utilizao; este fato pode levar a demora na instalao do sistema tornando-o, muitas vezes, obsoleto quando efetivamente colocado em operao. Os resultados que so observados na etapa ps-implementao so demorados, isto , no ocorrero at que muitos passos tenham sido completados. A maioria das implementaes do ciclo de vida em cascata apia-se em fases seqenciais, o que significa que meses ou anos podem se passar antes que os usurios vejam qualquer evidncia tangvel de progresso. Disso decorre a sua utilizao de maneira no formal. A exigncia de uma formalidade volumosa, baseada em papel, leva a maioria das organizaes e a maioria dos profissionais da rea, que no tm tempo nem disposio, a praticar o ciclo de vida tradicional de um modo menos rigoroso e formal;

Devido a seu grau de formalidade que exige especificaes e documentaes para cada processo que o sistema de informao executa, alteraes so inibidas tornando este processo, muitas vezes, inflexvel mudanas O prprio processo de deteco de erros no ciclo de vida em cascata clssico reservado fase de teste formal do projeto. Neste estgio, a presso nas atividades finais de desenvolvimento do sistema como deteco de erros de anlise e projeto, levam a situaes onde torna-se difcil a correo destes tendo em vista o custo associado a eliminao dos erros;

Os processos de tomada de deciso exigem, na maioria das vezes, atividades no estruturadas, que no possuem procedimentos bem definidos. Esta realidade, dentro de uma abordagem tradicional - e formal - dificulta a definio das especificaes do sistema, dependendo de requisitos corretos e estveis. No ciclo de vida em cascata a qualidade da codificao depende da qualidade do projeto, e a qualidade do projeto depende do esforo de anlise. Se os requisitos do usurio tiverem sido mal interpretados ou mal entendidos, ou se o usurio alterar os requisitos durante a fase de projeto e implementao subseqente, o ciclo de vida poder no produzir resultados para o real problema determinado.

Uso da implementao bottom-up. A implementao bottom-up inicia seu trabalho testando os mdulos do sistema, depois subsistemas e finalmente o sistema. Assim, os erros mais srios (integridade do sistema) so encontrados ao final e no no incio da fase de testes.

1.4 O Modelo Incremental

Barry Boehm sugeriu, tendo em vista as limitaes da abordagem tradicional, que o desenvolvimento de sistemas de informao poderia ser administrado numa srie de incrementos. Assim, poderia haver uma srie de ciclos de vida tradicionais para cada incremento.

O Modelo Incremental foi desenvolvido atravs da combinao entre os modelos linear e prototipao. O desenvolvimento dividido em etapas, denominadas incrementos, que produziro incrementalmente o sistema, at a sua verso final.

Em cada incremento realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema j em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda no cobrir todos os requisitos.

O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos no esto claros inicialmente. Por exemplo: quando o Modelo Incremental utilizado, o primeiro incremento normalmente constitudo do ncleo do sistema. Isto , os requisitos bsicos so implementados, e os detalhes suprimidos. Esse produto ser entregue para uma avaliao, que poder detectar, inicialmente, problemas que poderiam ser de dimenses muito maiores se detectados somente na entrega do produto final.

Outra vantagem para o desenvolvedor que, em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os prximos incrementos, alm de contar com os servios da verso j produzida.

Outras vantagens so:

A construo de um sistema menor sempre menos arriscada que a construo de um grande;

Se um grande erro cometido, apenas o ltimo incremento descartado;

Reduzindo o tempo de desenvolvimento de um sistema, as chances de mudanas nos requisitos do usurio durante o desenvolvimento so menores.

1.5 O Modelo Espiral

Seguindo a mesma linha do modelo incremental,o modelo foi proposto o modelo EPS (Boehm, 1988) - Evolutionary Spiral Process. Este modelo baseia-se em quatro principais atividades:

Determinao dos objetivos, alternativas e restries;

Anlise de risco e prototipao;

Validao e verificao;

Planejamento da fase seguinte.

Esta concepo tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possvel.

Problemas do Modelo espiral O modelo em espiral, por suas caractersticas de avaliao e planejamento baseadas em risco, exige que se tenha gerentes e tcnicos experientes. As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais difceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas partes do projeto, cada uma sendo abordada de modo diferenciado. necessrio o uso de tcnicas especficas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

1.6 Prototipao

Baseado no desenvolvimento de um prottipo com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento feito obedecendo realizao das diferentes etapas de anlise de requisitos, o projeto, a codificao e os testes. No necessariamente estas etapas devem ser realizadas de modo muito explcito ou formal

A definio de todos os requisitos necessrios ao sistema pelo cliente ou usurio geralmente uma tarefa muito difcil. quase impossvel prever como o sistema ir afetar o funcionamento das prticas de trabalho, como ser a interao com outros sistemas e que operaes dos usurios devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessria a utilizao de um prottipo do sistema.

Um prottipo uma verso inicial de um sistema de software, que utilizada para mostrar conceitos, experimentar opes de projeto e, em geral, para conhecer mais sobre os problemas e suas possveis solues. O desenvolvimento rpido de um prottipo essencial para que os custos sejam controlados e os usurios possam fazer experincias com o prottipo no incio do processo de software.

Um prottipo de software apia duas atividades do processo de engenharia de requisitos:

Levantamento de requisitos - Os prottipos de sistema permitem que os usurios realizem experincias para ver como o sistema apia seu trabalho. Eles obtm novas idias para os requisitos e podem identificar pontos positivos e negativos do software. Eles podem, ento, propor novos requisitos de sistema.

Validao de requisitos - O prottipo pode revelar erros e omisses nos requisitos propostos. Uma funo descrita em uma especificao pode parecer til e bem-definida. Contudo, quando essa funo utilizada com outras, os usurios muitas vezes acham que sua viso inicial era incorreta e incompleta. A especificao de sistema pode ento ser modificada para refletir sua compreenso alterada dos requisitos.

Na maioria dos projetos, o primeiro sistema construdo dificilmente ser usvel. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os trs. A questo administrativa, no se deve construir um sistema-piloto e jog-lo fora. Isso ser feito. A nica questo se deve planejar antecipadamente a construo de algo que se vai jogar fora ou prometer entregar isso aos clientes.

O prottipo pode ser oferecido ao cliente em diferentes formas: prottipo em papel

modelo executvel em PC retratando a interface homem-mquina capacitando o cliente a compreender a forma de interao com o software;

prottipo de trabalho que implemente um subconjunto dos requisitos indicados

programa existente (pacote) que permita representar todas ou parte das funes desejadas para o software a construir

Vantagens da prototipao:

modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos

possvel demonstrar a realizabilidade atravs da construo de um prottipo do sistema

possvel obter uma verso, mesmo simplificada do que ser o sistema, com um pequeno investimento inicial

A experincia adquirida no desenvolvimento do prottipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido

Problemas da prototipao:

Quando informamos que o produto precisa ser reconstrudo, o cliente exige que alguns acertos sejam aplicados para tornar o prottipo um produto; muito freqentemente, a gerncia de desenvolvimento de software cede.

O desenvolvedor muitas vezes faz concesses de implementao a fim de colocar um prottipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opes e esquecer-se de todas as razes pelas quais elas so inadequadas - a opo menos ideal se tornou ento parte integrante do sistema.

1.7 Modelo Iterativo

Modelo concebido com base nas limitaes do modelo em cascata, combinando as vantagens deste com as do modelo Prototipao. A idia principal a de que um sistema deve ser desenvolvido de forma incremental, onde cada incremento vai adicionando ao sistema novas capacidades funcionais, at a obteno do sistema final. A cada passo realizado, modificaes podem ser introduzidas.No primeiro passo

uma implementao inicial do sistema obtida, na forma de um subconjunto da soluo do problema global

deve contemplar os principais aspectos que sejam facilmente identificveis no que diz respeito ao problema a ser resolvido

A lista de controle de projeto

contem todos os passos a serem realizados para a obteno do sistema final definindo quais tarefas devem ser realizadas a cada iterao

gerencia todo o desenvolvimento serve para se medir, num dado nvel, o quo distante se est da ltima iterao

Cada iterao do modelo

consiste em retirar um passo da lista de controle de projeto atravs da realizao de trs etapas ( projeto, implementao e anlise)

at que a lista esteja completamente vazia

Vantagens desta abordagem

facilidade em testar o sistema, uma vez que a realizao de testes em cada nvel de desenvolvimento mais fcil do que testar o sistema na sua verso final

obteno de um sistema (mesmo incompleto) rapidamente,o quw pode oferecer ao cliente interessantes informaes que sirvam de subsdio para a melhor definio de futuros requisitos do sistema (como na Prototipao)

O que uma Iterao?

Uma iterao abrange as atividades de desenvolvimento que conduzem liberaode um produtouma verso do produto estvel e executvel, junto com qualquer outro elemento perifrico necessrio para usar esse release. Portanto, uma iterao de desenvolvimento de certa forma uma passagem completa por todas as disciplinas: pelo menos Requisitos, Anlise & Design, Implementao e Teste. como um pequeno projeto cascata em si mesmo. Observe que os critrios de avaliao so estabelecidos quando cada iterao planejada. O release ter planejado a capacidade que demonstrvel. A durao de uma iterao varia de acordo com o tamanho e a natureza do projeto, mas provvel que vrios builds sejam construdos em cada iterao, da maneira especificada no Plano de Integrao do Build para a iterao. Isso uma conseqncia da abordagem de integrao contnua recomendada no Rational Unified Process (RUP): quando os componentes testados da unidade ficam disponveis, eles so integrados e, em seguida, um build produzido e fica sujeito ao teste de integrao. Dessa maneira, a capacidade do software integrado cresce quando a iterao continua, em direo s metas definidas quando a iterao foi planejada. Pode ser demonstrado que cada build representa uma mini-iterao por si mesmo; a diferena est no planejamento necessrio e na formalidade da avaliao realizada. Pode ser apropriado e conveniente em alguns projetos construir builds diariamente, mas eles no representam iteraes quando o RUP os defineexceto, talvez, para um projeto muito pequeno de uma nica pessoa. Mesmo em projetos pequenos com vrias pessoas (por exemplo, envolvendo cinco pessoas criando 10.000 linhas de cdigo), seria muito difcil alcanar uma durao de iterao de menos de uma semana.

1.8 Diferena entre o modelo iterativo e o modelo Incremental

Os modelos iterativo e incremental podem ser facilmente confundidos, mas so profundamente diferentes.

No modelo incremental, desenvolve-se uma primeira verso, sem se preocupar muito com o todo. Portanto, o desenvolvimento se inicia sem que haja um conhecimento amplo dos requisitos do sistema. Atravs do feed-back do usurio,os requisitos vo sendo elicitados e implementados nas verses subseqentes do sistema.

No modelo itrativo, tem-se uma viso inicial de todos (ou quase todos) os requisitos do usurio, mas no se implementam todos de uma vez: a cada iterao implementado um subconjunto de requisitos. Estes requisitos so ento apresentados ao usurio, que fica satisfeito ao ver que os trabalhos esto evoluindo. Eventualmente, um requisito pode ser at implantado e disponibilizado para uso. Admite-se que o levantamento inicial registre 80% dos requisitos do sistema. Os outros surgem durante o desenvolvimento. No vale a pena investir muito tempo para se esgotar todos os requisitos: perde-se tempo e corre-se o risco de levantar falsos requisitos (desnecessrios).

1.9 RUP

Desenvolvida na dcada de 70 e aperfeioada desde ento, o RUP a metodologia da companhia norte-americana Rational (adquirida pela IBM em 2002), chamada Rational Unified Process (RUP).

Representado graficamente, o RUP possui duas dimenses, que representam as fases e as disciplinas.

O eixo horizontal (fases) representa o tempo, o aspecto dinmico do processo e expressa em termos de fases, iteraes e marcos. Uma iterao descrita como uma passagem por todas as disciplinas. A partir da fase de elaborao, cada iterao deve produzir um mdulo do sistema. O projeto concludo quando todos os mdulos forem produzidos e interconectados como peas (componentes) de um quebra cabea (sistema). assim que funciona o processo iterativo e incremental do RUP. A cada iterao deve ser obtido um release executvel, o qual testado e aprovado pelo usurio. Dessa forma, o risco minimizado, pois eventuais falhas so identificadas j nas fases iniciais do projeto.

O eixo vertical representa as disciplinas, o aspecto esttico do processo, e descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papis do processo. O grfico da figura 1 demonstra o esforo que aplicado na disciplina ao longo do tempo. A disciplina de requisitos, por exemplo, requer mais trabalho nas fases iniciais (iniciao e elaborao), enquanto a de implantao praticamente no existe antes das fases finais (construo e transio).

O ciclo de vida de software do RUP dividido em quatro fases seqenciais Iniciao (ou Concepo), Elaborao, Construo e Transio cada uma concluda por um marco principal. Em cada final de fase executada uma avaliao para determinar se os objetivos da fase foram alcanados. Uma avaliao satisfatria permite que o projeto passe para a prxima fase.

Fase de IniciaoA meta da fase de iniciao atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. Nesse sentido, as atividades bsicas envolvem:

a)Formular o escopo do projeto: Capturar o contexto, bem como os requisitos e as restries mais importantes, para que seja possvel elaborar critrios de aceitao para o produto final.

b) Preparar o ambiente para o projeto, avaliar o projeto e a organizao, selecionar ferramentas e decidir quais partes do processo devem ser melhoradas. Fase de ElaboraoA meta da Fase de Elaborao criar a linha bsica (baseline) para a arquitetura do sistema a fim de fornecer uma base estvel para o esforo da Fase de Construo. Deve-se decidir basicamente sobre a organizao do sistema, a seleo dos elementos e seu comportamento.

Fase de ConstruoA meta da Fase de Construo esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura definida.

Fase de TransioO RUP possui ainda a fase de Transio, que consiste de vrias atividades com o objetivo de implantar o sistema no ambiente do usurio.

1.10 Extreme Programming (XP)

Metodologia adequada a equipes pequenas (at 10 pessoas), parte do princpio de que a melhor documentao o cdigo fonte: qualquer outra documentao fica logo desatualizada e por isso perde a confiabilidade.

Baseada em prticas, como programao aos pares, semana de 40 horas e reunies em p. Frases conhecidas: 1) Sem um processo, s uma pessoa excepcional consegue desenvolver um sistema... Com muito processo,pessoas excepcionais no conseguem desenvolver sistemas excepcionais 2) Uma boa equipe pequena produz mais que grandes equipesDesenvolvida em 1996 por Kent Beck, uma metodologia bastante nova que renega todos os paradigmas do desenvolvimento tradicional de software. Para a XP, a arquitetura do sistema uma metfora. A arquitetura na verdade desenvolvida ao longo do projeto onde todo o cdigo escrito constantemente reconstrudo para aumentar a simplicidade e objetividade do mesmo. A XP vem ganhando inmeros adeptos dentre os programadores mais experientes.

O manifesto gil

Estamos evidenciando maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar:- Indivduos e interao MAIS QUE processos e ferramentas; - Software em funcionamento MAIS QUE documentao abrangente; - Colaborao com o cliente MAIS QUE negociao de contratos; - Responder a mudanas MAIS QUE seguir um plano. Ou seja, mesmo tendo valor os itens direita, valorizamos mais os itens esquerda.

As Prticas do XP

The Customer is Always Available - O cliente est sempre disponvel para resolver dvidas, alterar o escopo de uma iterao e definir prioridades. Metaphor - O time se comunica sobre o software em termos de uma metfora, caso consiga encontrar uma boa.Planning Game - Os jogadores do jogo do planejamento so o cliente e os tcnicos. O objetivo: colocar em produo as funcionalidades de maior valor possvel durante o decorrer do jogo. Small Releases - O software entregue em pequenas verses para que o cliente possa obter o seu ganho o mais cedo possvel e para minimizar riscos. Acceptance Tests - So definidos pelo usurio e so os critrios de aceitao do software. Test First Design - Primeiro so escritos os testes, depois feita a implementao e por ltimo trabalha-se o design. Continuous Integration - Os diversos mdulos do software so integrados diversas vezes por dia e todos os testes unitrios so executados. O cdigo no passa at obter sucesso em 100% dos testes unitrios. Simple Design- O cdigo est, a qualquer momento, na forma mais simples que passe todos os testes. Refactoring - A cada nova funcionalidade adicionada, trabalhado o design do cdigo at ficar na sua forma mais simples. Pair Programming - Todo cdigo de produo desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor.

Move People Around - As duplas de programao so revezadas em mdia a cada 2h. Collective Code Ownership - E equipe como um todo responsvel por cada arquivo de cdigo. No preciso pedir autorizao para alterar qualquer arquivo.

Coding Standards - Todo cdigo desenvolvido seguindo um padro. 40 Hour Week - Trabalhar por longos perodos contraproducente.

Valores do XP

Simplicidade O design do software simplificado continuamente. isso que sustenta a premissa extrema. O processo em si tambm adaptado, a cada dia, se algum vir como torn-lo mais simples. Comunicao Prefira: chat a eMail, telefonemas a chat, conversar pessoalmente a telefonemas, trabalhar na mesma sala a ter salas isoladas, trabalhar em conjunto a revisar o resultado final. Coragem preciso coragem para: apontar um problema no projeto, parar quando voc est cansado, pedir ajuda quando necessrio, simplificar cdigo que j est funcionando, dizer ao cliente que no ser possvel implementar um requisito no prazo estimado, fazer alteraes no processo de desenvolvimento. Ou seja, fazer a coisa certa mesmo que no seja a coisa mais popular naquele momento.

Feedback Todo problema evidenciado o mais cedo possvel para que possa ser corrigido o mais cedo possvel. Toda oportunidade descoberta o mais cedo possvel para que possa ser aproveitada o mais cedo possvel.

Introduo a Engenharia de Software Prof. Wagner XantrePgina 13