{"id":94,"date":"2011-10-22T20:39:23","date_gmt":"2011-10-22T23:39:23","guid":{"rendered":"https:\/\/www.semeru.com.br\/blog\/?p=94"},"modified":"2022-12-20T18:07:24","modified_gmt":"2022-12-20T21:07:24","slug":"as-metodologias-tradicionais-de-desenvolvimento-de-software","status":"publish","type":"post","link":"https:\/\/www.semeru.com.br\/blog\/as-metodologias-tradicionais-de-desenvolvimento-de-software\/","title":{"rendered":"As Metodologias Tradicionais de Desenvolvimento de Software"},"content":{"rendered":"

As metodologias tradicionais s\u00e3o tamb\u00e9m chamadas de pesadas ou orientadas a documenta\u00e7\u00e3o. Elas foram muito utilizadas no passado em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe<\/em> e terminais burros<\/em> Naquela \u00e9poca, o custo de fazer altera\u00e7\u00f5es e corre\u00e7\u00f5es era muito alto, uma vez que o acesso aos computadores eram limitados e n\u00e3o existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de c\u00f3digo. Por isso o software era todo planejado e documentado antes de ser implementado. Uma das metodologias tradicionais mais utilizadas at\u00e9 hoje \u00e9 o modelo Cl\u00e1ssico ou Cascata (SOARES, 2004).<\/p>\n

Cascata<\/strong><\/p>\n

Uma das primeiras metodologias criadas para minimizar os problemas destacados acima foi a metodologia Cascata. Ela representava um grande avan\u00e7o no desenvolvimento de software. Principalmente se levar em conta que antes do surgimento das primeiras metodologias existia o que ficou vulgarmente conhecido como \u201ccodifica arrebenta\u201d.<\/em> Onde o mal ou nenhum levantamento de requisitos levava a sucessivas corre\u00e7\u00f5es, debugs e muitas vezes ao fracasso do projeto.<\/p>\n

O Ciclo de Vida da Metodologia Cascata<\/p>\n

\"Engenharia<\/p>\n

Fonte: PRESSMAN, 2006<\/p>\n

A Figura acima representa a metodologia cascata, tamb\u00e9m conhecida como sequencial, ou linear, por se basear em uma sucess\u00e3o de etapas onde uma s\u00f3 \u00e9 iniciada ap\u00f3s o fim da imediatamente anterior a ela. Como se pode ver o desenvolvimento flui da parte de cima \u2013 Engenharia de sistemas \u2013 em dire\u00e7\u00e3o \u00e0 manuten\u00e7\u00e3o. Nessa metodologia, inicialmente procura-se compreender completamente o problema, a ser resolvido, seus requisitos e suas restri\u00e7\u00f5es; depois projeta-se solu\u00e7\u00f5es que atendam a todos os requisitos e restri\u00e7\u00f5es. Feito isto inicia-se a implementa\u00e7\u00e3o do projeto e quando toda a etapa de implementa\u00e7\u00e3o \u00e9 conclu\u00edda verifica-se junto ao cliente se a solu\u00e7\u00e3o atende aos requisitos estabelecidos e por fim \u00e9 efetuada a entrega do produto (KROLL e KRUCHTEN, 2003 apud LOUREN\u00c7O, 2011).<\/p>\n

A abordagem adotada pela metodologia cascata acaba trazendo alguns problemas. Dentre estes problemas merece destaque o fato de que os projetos reais dificilmente seguem o fluxo sequencial, o cliente quase sempre n\u00e3o consegue exprimir todas as suas necessidades al\u00e9m de ser exigida dele muita paci\u00eancia visto que o software s\u00f3 estar\u00e1 pronto para uso num ponto tardio do cronograma. E o maior dos problemas \u00e9 que se ocorrer um erro em qualquer uma das etapas o resultado pode ser desastroso e frequentemente caro (PRESSMAN, 2006).<\/p>\n

Algumas vezes o cliente define um conjunto de objetivos gerais que n\u00e3o esclarecem consistentemente os requisitos. Outras vezes o desenvolvedor n\u00e3o tem certeza da efici\u00eancia de parte do c\u00f3digo, da adapta\u00e7\u00e3o da aplica\u00e7\u00e3o ao sistema operacional ou mesmo da forma que intera\u00e7\u00e3o homem-m\u00e1quina deve ter. Visando fornecer melhores solu\u00e7\u00f5es \u00e0 casos assim surgiu a metodologia conhecida como prototipa\u00e7\u00e3o.<\/p>\n

Prototipa\u00e7\u00e3o<\/strong><\/p>\n

A Prototipa\u00e7\u00e3o \u00e9 uma metodologia surgida posteriormente \u00e0 Cascata. Ela possibilita a equipe de desenvolvimento a criar uma aplica\u00e7\u00e3o prot\u00f3tipo que pode assumir tr\u00eas formas distintas. A primeira delas \u00e9 um prot\u00f3tipo em papel ou mesmo no computador que retrate a intera\u00e7\u00e3o homem-m\u00e1quina. A segunda op\u00e7\u00e3o \u00e9 implementar uma funcionalidade que j\u00e1 est\u00e1 no escopo do software a ser desenvolvido. Por fim existe a possibilidade de utilizar-se de um software j\u00e1 pronto que tenha parte ou todas as funcionalidades desejadas. Esta forma \u00e9 mais comumente adotada em softwares que apesar de prontos ou parcialmente prontos possuem caracter\u00edsticas que precisam ser incrementadas ou melhoradas em um novo esfor\u00e7o de desenvolvimento (PRESSMAN, 2006).<\/p>\n

Geralmente o prot\u00f3tipo serve apenas como um mecanismo para identificar requisitos de software. Isto ocorre por que na maior parte dos casos o primeiro sistema constru\u00eddo n\u00e3o \u00e9 completamente us\u00e1vel. Normalmente ele possui uma s\u00e9rie de problemas que s\u00f3 ser\u00e3o corrigidos em uma vers\u00e3o reprojetada na qual as defici\u00eancias sejam corrigidas (BROOKS,1975 apud PRESSMAN, 2006).<\/p>\n

Assim como a metodologia Cascata a Prototipa\u00e7\u00e3o tamb\u00e9m apresenta os seus pontos negativos. Um deles, \u00e9 que o cliente pode acreditar que o prot\u00f3tipo j\u00e1 \u00e9 o software pronto ou em fase de t\u00e9rmino e come\u00e7ar pressionar para que se fa\u00e7a pequenos ajustes e entregue o software rapidamente. Diante de um quadro assim, muitas vezes, a equipe de desenvolvimento cede e a qualidade final, bem como a manutenibilidade podem ficar comprometidas. Outro ponto negativo \u00e9 que algumas vezes a equipe de desenvolvimento pode\u00a0 fazer concess\u00f5es tempor\u00e1rias a fim de colocar o prot\u00f3tipo em funcionamento que acabam permanecendo no software final.<\/p>\n

Apesar desses problemas, a prototipa\u00e7\u00e3o ainda \u00e9 uma eficiente metodologia de desenvolvimento de software. A fim de se obter sucesso no projeto, tanto cliente quanto desenvolvedor devem chegar a um consenso de que o prot\u00f3tipo servir\u00e1 apenas para ajudar na defini\u00e7\u00e3o dos requisitos (PRESSMAN, 2006). Apesar de resolverem muitos dos problemas do desenvolvimento de software alguns par\u00e2metros ainda n\u00e3o eram fornecidos pelas metodologias existentes.<\/p>\n

Espiral<\/strong><\/p>\n

A metodologia espiral foi concebida para englobar as melhores pr\u00e1ticas tanto do ciclo de vida cl\u00e1ssico quanto da prototipa\u00e7\u00e3o. Essa metodologia inovou ao trazer tamb\u00e9m um novo elemento, a an\u00e1lise de riscos. Al\u00e9m disso, foi uma das primeiras metodologias a adotar o conceito de itera\u00e7\u00e3o. Sucessivas itera\u00e7\u00f5es moldam aos poucos solu\u00e7\u00f5es mais completas do software (PRESSMAN, 2006).<\/p>\n

Na primeira itera\u00e7\u00e3o, os objetivos, alternativas e restri\u00e7\u00f5es s\u00e3o definidos e os riscos s\u00e3o identificados e analisados. O cliente avalia o resultado da itera\u00e7\u00e3o e baseado nos apontamentos do mesmo a pr\u00f3xima itera\u00e7\u00e3o \u00e9 iniciada. Isso possibilita ao cliente e ao desenvolvedor perceber e reagir a riscos em cada uma das etapas evolutivas. Entretanto a metodologia espiral exige consider\u00e1vel experi\u00eancia para avaliar os riscos e se baseia nela para obter sucesso. Encara-se que se um grande risco n\u00e3o for detectado indubitavelmente ocorrer\u00e3o problemas.<\/p>\n

Treinamentos relacionados com essa postagem<\/h2>\n


\n
\n<\/a><\/p>\n


\n<\/a><\/p>\n


\n<\/a><\/p>\n


\n<\/a><\/p>\n


\n<\/a><\/p>\n

Refer\u00eancias:<\/h2>\n

LOUREN\u00c7O, Marcelo. Obtendo Qualidade de Software com o RUP. <\/strong>Dispon\u00edvel em: < http:\/\/qualidade-de-software.blogspot.com\/2010\/03\/obtendo-qualidade-de-software-com-o-rup.html >\u00a0 acesso em 05 mar. 2011.<\/p>\n

PRESSMAN, Roger S.\u00a0Engenharia de Software\u00a0<\/strong>: 6 ed. S\u00e3o Paulo: McGraw Hill\/Nacional, 2006.<\/p>\n

SOARES, Michel dos Santos. Compara\u00e7\u00e3o entre Metodologias \u00c1geis e Tradicionais para o Desenvolvimento de Software. <\/strong>2004. Dispon\u00edvel em: < http:\/\/www.dcc.ufla.br\/infocomp\/artigos\/v3.2\/art02.pdf > acesso em: 04 abr. 2011.<\/p>\n

SOMMERVILLE, Ian.\u00a0Engenharia de Software\u00a0<\/strong>: 8 ed. Rio de Janeiro: Prentice-Hall, 2008.<\/p>\n

<\/div><\/div><\/div>","protected":false},"excerpt":{"rendered":"

As metodologias tradicionais s\u00e3o tamb\u00e9m chamadas de pesadas ou orientadas a documenta\u00e7\u00e3o. Elas foram muito utilizadas no passado em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros Naquela \u00e9poca, o custo de fazer altera\u00e7\u00f5es e corre\u00e7\u00f5es era muito alto, uma vez que o acesso aos […]<\/p>\n

\n
\n
<\/div>\n<\/div>\n<\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[35,45,44,36,32,37],"tags":[144,147,145,34,146],"_links":{"self":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts\/94"}],"collection":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/comments?post=94"}],"version-history":[{"count":7,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts\/94\/revisions"}],"predecessor-version":[{"id":1364,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/posts\/94\/revisions\/1364"}],"wp:attachment":[{"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/media?parent=94"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/categories?post=94"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.semeru.com.br\/blog\/wp-json\/wp\/v2\/tags?post=94"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}