Desde quando RUP é Waterfall?

Rodolpho,

Quando vc diz que RUP é iterativo, voce diz como desenvolvedor ou consultor RUP?

Se for desenvolvedor (e iteratividade é algo realmente tão essencial!), entao explore esse fato, ganhe dinheiro e seja feliz!

Senão,

O máximo que posso fazer é entender sua posição.

Eu já havia pedido o mesmo na outra thread, mas nunca obtive resposta.
Mas acho que não precisava ter levantado novamente essa bandeira. Aquele tópico por si só já foi bastante inflamado.

Um processo iterativo usa o contato com usuários reais desde a primeira versão para extrair feedback e investir no refinamento da visão original do que o sistema deve fazer.

O próprio fanboy RUP (caraca, nem sabia que existia isso!) ai em cima, diz que no RUP, foco no usuário significa utilizar casos de uso!!!

Ué mochuara… se você se dá ao luxo de ser um troller contra o rup, por que não deixar ele ser também um fanboy?

Me intrometendo um pouco, acho que o problema não é bem o RUP, o problema é que as empresas criam processos SOBRE o RUP distorcendo-o de forma a parecer um processo waterfall… sujando a imagem do mesmo.

Mochuara,

Eu não disse que foco no usuário SIGNIFICA usar casos de uso. Eu disse: use casos de uso e foque no usuário. E quem diz isso não sou eu, mas o próprio RUP.

Sobre Iterações o RUP diz duas coisas:

1. O objetivo de toda iteração é produzir um produto de software testável. A única exceção admitida é na iteração de concepção (mais ou menos como na iteração 0 do SCRUM).
2. Ao final de toda iteração é feita uma “Avaliação da Iteração” onde o cliente/usuário/patrocinador pode conferir o resultado e dar feedbacks para que a equipe corrija o rumo se necessário.

Fonte: RUP

Você é sempre evasivo e obtuso nas suas respostas e parece que gosta bastante de ser irônico.

Pode, por favor, me dizer porque diabos você acha que o RUP não é iterativo e onde ouviu ou leu esse monte de bobagem?

Abraço,
Rodolpho

Samuel,

É. Mas o RUP tem sua parcela de culpa. Eu não gosto da maneira como o RUP é documentado: acho muito complicado e tira o foco do que é essencial. O SCRUM, por exemplo, tem uma documentação enxuta, objetiva e eficiente (O SCRUM Guide, por exemplo).

Minha opinião é que a maneira como o RUP está documentado (sobretudo os diagramas de atividade) induz as equipes/empresas/pessoas inexperiêntes ao erro.

Um abraço,
Rodolpho

Pois é ViniGodoy… eu percebi. Mas não dá pra aguentar ler tanta bobagem e ficar quieto.

Vamos ver onde isso dá…

Um abraço,
Rodolpho

O RUP em si é um processo iterativo e incremental.

[]s

rugolini:

Mochuara,

Eu não disse que foco no usuário SIGNIFICA usar casos de uso. Eu disse: use casos de uso e foque no usuário. E quem diz isso não sou eu, mas o próprio RUP.

Sobre Iterações o RUP diz duas coisas:

1. O objetivo de toda iteração é produzir um produto de software testável. A única exceção admitida é na iteração de concepção (mais ou menos como na iteração 0 do SCRUM).
2. Ao final de toda iteração é feita uma “Avaliação da Iteração” onde o cliente/usuário/patrocinador pode conferir o resultado e dar feedbacks para que a equipe corrija o rumo se necessário.

Fonte: RUP

Você é sempre evasivo e obtuso nas suas respostas e parece que gosta bastante de ser irônico.

Pode, por favor, me dizer porque diabos você acha que o RUP não é iterativo e onde ouviu ou leu esse monte de bobagem?

Abraço,
Rodolpho

Então vc esta dizendo que o RUP:

• possui iterações curtas

• ao final de cada uma, tem-se um release beta que consiste em software executavel, e

• cada release beta é validado pelo usuário final

Esse deve ser o Rodolpho Unified Process, porque o RUP não diz isso nos livros, muito menos na pratica.

No RUP o sistema não é validado pelo usuário final ao fim de cada iteração, apenas na fase de transição.

Não está ocorrendo confusão entre:

UP: Processo Unificado

e

RUP: Processo Unificado da Rational

???

Abraços

Mochuara: “No RUP o sistema não é validado pelo usuário final ao fim de cada iteração, apenas na fase de transição.”

Nossa Mochuara, você realmente não sabe o que está dizendo. Onde você leu isso? Pode, por favor me indicar (precisamente) a fonte?

Sobre suas colocações, vamos ver o que o RUP diz:

1. Mochuara: "possui iterações curtas"
   RUP: “The duration of an iteration will vary depending on the size and nature of the project, but it is likely that multiple builds will be constructed in each iteration. This is a consequence of the continuous integration approach recommended in the Rational Unified Process (RUP) […] each build itself represents a mini-iteration.” - CHECK

2. Mochuara: "ao final de cada uma, tem-se um release beta que consiste em software executavel"
   RUP: “An iteration encompasses the development activities that lead to a product release-a stable, executable version of the product” - CHECK!

3. Mochuara: "cada release beta é validado pelo usuário final"
   RUP: “Note that evaluation criteria are established when each iteration is planned. The release will have planned capability which is demonstrable.This allows us to demonstrate the application to end users and other stakeholders, or have them use the application directly, enabling them to provide rapid feedback on how we are doing.” - CHECK!

Sobre a fase de transição: “The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle.”

Aqui você pode ler e estudar (de graça) o RUP (em português ou inglês): http://www.wthreex.com/rup/

Mochuara, todo o texto acima foi tirado DO RUP (da Rational, não do Rodolpho). Portanto, recomendo que você leia e estude antes de afirmar coisas que não sabe. Isso é ruim pra todo mundo.

Tem muita gente, por exemplo, queimando o filme do SCRUM dizendo bobagens como: só pra times/projetos pequenos, etc.

Você me perguntou se falo como consultor ou desenvolvedor… falo como ambos: eu pratico e ensino RUP a mais de 10 anos. Uso-o nos meus projetos (que são pequeninos e com equipe idem) e utilizo como base para melhorar a eficiência de times de desenvolvimento de software de empresas de todos os tamanhos.

Ok?

Um abraço,
Rodolpho

luizSC,

Qual a diferença entre “UP: Processo Unificado” e “RUP: Processo Unificado da Rational” ? Um é a encarnação do outro.

O RUP é um produto formado por uma biblioteca de conhecimento e uma ferramenta para customização dessa biblioteca (Rational Method Composer). Mais informações em http://www-01.ibm.com/software/awdtools/rup/.

O UP é o processo criado a partir do Objectory, processo criado pelo Jacobson na década de 80 e o Booch Method, criado por Grady Booch, com contribuições de Philip Krutchen, David Harel e James Rumbagh. O processo foi publicado no livro “The Unified Software Development Process” (http://www.amazon.com/Unified-Software-Development-Process/dp/[telefone removido]) - que recomendo fortemente ao Mochuara.

O RUP segue os princípios propostos pelo UP, entretanto existem outras variações de processo baseados no mesmo princípios, como:

Agile Unified Process (AUP), criada por Scott W. Ambler
Basic Unified Process (BUP), criada pela IBM que deu origem ao OpenUP (http://epf.eclipse.org/wikis/openup/)
Enterprise Unified Process (EUP), uma extensão ao Rational Unified Process
Essential Unified Process (EssUP), criada por Ivar Jacobson
Open Unified Process (OpenUP), o processo de desenvolvimento criado pelo consórcio Eclipse
Oracle Unified Method (OUM), criado pela Oracle
Rational Unified Process-System Engineering (RUP-SE), uma versão do RUP voltada para Engenharia de Sistemas.

Um abraço,
Rodolpho

rugolini:

Aqui você pode ler e estudar (de graça) o RUP (em português ou inglês): http://www.wthreex.com/rup/

Mochuara, todo o texto acima foi tirado DO RUP (da Rational, não do Rodolpho). Portanto, recomendo que você leia e estude antes de afirmar coisas que não sabe. Isso é ruim pra todo mundo.

Essa é a entidade oficial de RUP que vc cita como fonte? Um link cheio de google ads?

rugolini:

Você me perguntou se falo como consultor ou desenvolvedor… falo como ambos: eu pratico e ensino RUP a mais de 10 anos. Uso-o nos meus projetos (que são pequeninos e com equipe idem) e utilizo como base para melhorar a eficiência de times de desenvolvimento de software de empresas de todos os tamanhos.

Ok?

Um abraço,
Rodolpho

Que bom! Waterfall é um processo perfeitamente válido (mesmo não sendo iterativo) e bastante utilizado pelas empresas. Não tenho duvida que muitos projetos de sucesso são feitos usando RUP, por exemplo.

Mas RUP é waterfall por não proporcionar o design iterativo, não me lembro de ter dito que ele era ineficiente.

Cara, RUP é um processo iterativo sim e qualquer documentação a respeito do mesmo diz isso.
Se na prática as pessoas não o fazem iterativamente é outra estória.
Sua afirmação não tem fundamento e só está servindo para aumentar sua quota de mensagens

Mochuara, você disse: "Mas RUP é waterfall por não proporcionar o design iterativo. "

Você pode, por favor me indicar a fonte para essa afirmação? Onde você leu isso?

Extraído do RUP:

“In the RUP, the architecture evolves iteration after iteration to become refined and polished. As each iteration includes integration and test, the architecture is quite robust by the time the product is delivered.”

Se você tiver dificuldades com inglês, segue a tradução:

“No RUP, a arquitetura evolui iteração após iteração para tornar-se refinada e polida. Como cada iteração inclui integração e testes, a arquitetura torna-se bastante robusta quando chega a hora do produto ser entregue.”

Fonte: RUP, novamente aqui você pode LER o RUP http://www.wthreex.com/rup/smallprojects/index.htm)

Isso é: o Design no RUP é incremental. O RUP é um processo iterativo E incremental. Tudo é feito de maneira incremental: captura e definição dos requisitos, análise e design, implementação, testes e implantação. Tudo é incremental.

Ok?

Oi, não sei se é certo perguntar aqui mas, é pura curiosidade:

Quais grandes empresas utilizam o RUP?

Lucas,

Eu trabalho na IBM Rational e infelizmente não tenho autorização para publicar as referências sem autorização dos clientes.

Posso afirmar que dezenas de grandes empresas usam, em todos os segmentos, mas principalmente energia e petróleo, financeiro/bancário/seguros, governo e Jogos.

Este último é um ramo que eu gosto bastante de citar: ouço muito por aí que “RUP é pesado e burocrático” e “XIBRUTS é leve e ágil” (sinceramente foi a primeira vez que vi alguém advogando que o RUP é cascata e se existe uma indústria de desenvolvimento de software que precisa de processo eficiente é a de Games. Um dos processos de desenvolvimento mais bem sucedidos nessa indústria é o GUP - Game Unified Process, que usa como base o UP e mistura elementos do XP. Vale a leitura: http://www.gamedev.net/reference/articles/article1940.asp

E no Brasil foi criado uma variação desse processo, específicamente para jogos móveis (que tem como características equipes muito enxutas e prazos apertadíssimos). Vale MUITO a pena a leitura (alô Mochuara!): www.dominiopublico.gov.br/download/texto/cp000585.pdf

Se você ler o artigo do Kevin, vai perceber que o desafio de mudança cultural é sempre o mesmo: MINDSET. Eu sinto isso na pele todos os dias, principalmente em empresas médias e grandes.

É muito difícil mudar a maneira de pensar Waterfall para Iterativo. Costumo dizer a adoção de um novo processo ocorre em ondas: colocamos bastante energia para adotar novas práticas e no começo as equipes se empolgam, os resultados positivos aparecem. Depois de um tempo, a consultoria termina, as pessoas dos times vão sendo trocadas e a coisa recua, mas sempre para um patamar sempre superior ao do início da onda. Depois uma nova onda se inicia e o ciclo se repete.

Infelizmente, assim como tem o ScrumBut, existe o WUP: Waterfall Unified Process. Que acontece quando a empresa usa o vocabulário, os (malditos) templates de documentos, mas se mantém presa ao processo cascata.

Eu acredito que existam mais empresas grandes usando WUP do que RUP. Mas o movimento ágil renovou nosso gás, pudemos identificar problemas na abordagem inicial e continuar a perseguir nosso objetivo que é banir de vez essa praga chamada “abordagem em cascata”.

E nisso, eu acredito, estamos todos juntos. Sejam XisPêzeiros, SCRUMzeiros, Agilistas, RUPianos, LEANistas… Juntos chegaremos lá! :-))))

Um abraço!
Rodolpho

PS: sobre as referencias, se estiver interessado em algo mais específico, pode me contactar diretamente.

@rugolini

Eu sinto muito mas ao mesmo tempo que concordo contigo eu tenho que alfinetar o RUP. Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Por isso que eu concordo com tudo que o meu amigo Rodrigo Yoshima diz no post abaixo e que com certeza já deve ter falado contigo sobre esse assunto:

Abraços,

Emerson Macedo:

Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Ambos sofrem do mesmo mal: eles querem seguir um manual, mas não querem refletir sobre o que estão seguindo.

Aliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.

Eu tenho certeza que uma equipe formada de seres pensantes trabalhando para melhorar a si própria, terá muito sucesso, independente do método que for adotar ou criar.

Carinha, que coisa bacana que você disse; parabéns!

Nada contra as metodologias porem quando o verdadeiro desafio se apresenta, certamente o que conta são a habilidade e a criatividade do individuo ou da equipe em questão.

=Bruno LaturnerAliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.

Isto que você disse já rendeu muita grana para consultorias e vendedores de cursos. Quem disse que burrice não rende dinheiro?

flws

Bruno Laturner:

Emerson Macedo:

Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Ambos sofrem do mesmo mal: eles querem seguir um manual, mas não querem refletir sobre o que estão seguindo.

Aliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.

Eu tenho certeza que uma equipe formada de seres pensantes trabalhando para melhorar a si própria, terá muito sucesso, independente do método que for adotar ou criar.

Calma lá, está dizendo que desenvolver software é uma atividade complexa e requer profissionais capacitados!?!? Então vc precisa receber a visita de um dos nossos consultores RUP ou especialistas agile!!!

Emerson Macedo:

@rugolini

Eu sinto muito mas ao mesmo tempo que concordo contigo eu tenho que alfinetar o RUP. Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Por isso que eu concordo com tudo que o meu amigo Rodrigo Yoshima diz no post abaixo e que com certeza já deve ter falado contigo sobre esse assunto:

Abraços,

Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.

Caro Mochuara, desculpe, mas eu desconfio é de quem faz afirmações falaciosas sem citar FONTES ou estudos que as comprovem.

Fantomas,

Qual o problema de render dinheiro a quem entrega cursos/treinamentos? E livros? E blogs?

Cuidado… será que não estamos invertendo as coisas? Qual o problema de ganhar dinheiro ao ensinar uma técnica nova ou melhor?

Outra coisa, você disse “Nada contra as metodologias porem quando o verdadeiro desafio se apresenta, certamente o que conta são a habilidade e a criatividade do individuo ou da equipe em questão.”

Metodologia, pra mim, é como ferramenta: serve pra ajudar. Ela sozinha não faz nada.

Uma frase que gosto demais é do Grady Booch: “Um bom time sem processo adequado sempre será superado por um bom time que aplica um bom processo.”

Um abraço.

Emerson Macedo:

@rugolini

Eu sinto muito mas ao mesmo tempo que concordo contigo eu tenho que alfinetar o RUP. Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Por isso que eu concordo com tudo que o meu amigo Rodrigo Yoshima diz no post abaixo e que com certeza já deve ter falado contigo sobre esse assunto:

Abraços,

Opa Emerson, concordo discordando: o RUP não é mau documentado. Na minha opinião ele é bem documentado DEMAIS. Tem tudo lá. E esse, ao mesmo tempo, é uma fraqueza e uma virtude.

Para iniciantes, documentação (do processo!) por documentação, fico com a do SCRUM: as simpler, the better.

Como sei RUP de trás pra frente, me dou muito bem com o bixo. Mas dificulta muito a vida de quem está começando.

Para esses, recomendo fortemente o livro do Philip Krutchen (um dos padrinhos e mantenedores da criança) “RUP Made Easy”. Eu aprendi direito por ele.

Um abraço,
Rodolpho

Bruno Laturner:

Emerson Macedo:

Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Ambos sofrem do mesmo mal: eles querem seguir um manual, mas não querem refletir sobre o que estão seguindo.

Aliás não é um problema só do desenvolvimento de software, essa pragua de desligar o cérebro e se deixar levar por outros é uma pandemia, vem desde a nossa educação na infância, de aceitar o que é repassado sem questionar.

Eu tenho certeza que uma equipe formada de seres pensantes trabalhando para melhorar a si própria, terá muito sucesso, independente do método que for adotar ou criar.

Concordo totalmente contigo. A um tempo atrás escrevi um post entitulado “Paranóia mMetodológica tem cura!”

Depois se tiver um tempinho dê uma lida http://j.mp/aQ1mGS

Um abraço!

mochuara:

Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.

Desconfie do quê? Diz aí… Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?

É culpa do RUP? Não. RUP é um bom processo.

rodrigoy:

mochuara:

Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.

Desconfie do quê? Diz aí… Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?

É culpa do RUP? Não. RUP é um bom processo.

Pra mim, o melhor e mais completo.

rodrigoy:

mochuara:

Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.

Desconfie do quê? Diz aí… Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?

É culpa do RUP? Não. RUP é um bom processo.

Isso não prova que RUP esta morto. Na verdade, o fato de haver pouca demanda por consultores para introduzir RUP nas empresa é de esperar dado que se trata de um processo estabelecido no mercado.

Ainda assim, isso tb não prova que RUP não esta sendo mais usado em novos projetos, já que vc não é o unico consultor RUP no mundo.

So pra constar meu apoio, RUP realmente não É waterfall.

Muita gente usa assim e pensa assim, mais nao é

pintofree:

So pra constar meu apoio, RUP realmente não É waterfall.

Muita gente usa assim e pensa assim, mais nao é

Muita gente usa assim porque assim que melhor se adequa às necessidades de comunicação da empresa. Ou seja, por mais que vc não goste de waterfall, seu chefe gosta, e é graças a ele que RUP foi amplamente adotado pela indústria como processo waterfall. Ninguém da a mínima se um acadêmico acha que é melhor usar de outro jeito.

sidzuza:

Cara, RUP é um processo iterativo sim e qualquer documentação a respeito do mesmo diz isso.
Se na prática as pessoas não o fazem iterativamente é outra estória.
Sua afirmação não tem fundamento e só está servindo para aumentar sua quota de mensagens

Sua afirmação que não tem fundamento. Processos são guias de como agir, se RUP não consegue ser traduzido na prática num processo iterativo (isto é, sem separação entre analise e implementação) então ele é waterfall e ponto.

Cara o RUP é interativo e incremental, inclusive na documentação do RUP existem modelos para implementação do processo em equipes agéis utilizando somente um conjunto dos artefatos.

Nesse mesmo capítulo, também existem exemplos e formas de implementar o processo em diversos tipos de projeto. Quem disse que a documentação do RUP é falha, é porque não a leu.

Para mim a diferença do RUP para as metodologias ágeis está mais relacionada a princípios, valores e práticas adotadas pela equipe do que em artefatos e documentação produzida.

Todo mundo levanta requisitos, implementa, testa, implanta e controla o processo no final das contas.

Quando saiu da Rational o Ivar Jacobson criou o Essencial Unified Process baseado na sua experiência com o RUP e lendo esse processo notei semelhanças com os modelos propostos na documentação do RUP que citei aqui no inicio.

Metodologia é uma ferramenta para auxílio no gerenciamento, cada um deve escolher as ferramentas que se adequam melhor a sua equipe.

Que RUP é iterativo na teoria porque assim diz a documentação já foi dito nessa thread, portanto seu post não agrega nada a discussão.

Mas essa afirmação me chamou a atenção:

“Todo mundo levanta requisitos, implementa, testa, implanta e controla o processo no final das contas.”

Quem “levanta requisitos” já parte do pressuposto que 1) não sabe o que deve ser construído, 2) quem sabe não faz parte da equipe, 3) e que, por isso, análise e implementação devem ser feitos separados.

Portanto entenda que levantar requisitos é o primeiro indicativo que seu processo não é iterativo.

Filho você sabe o significado de Iteração? O fato de ser haver um ciclo não quer dizer que o processo completo tem somente uma iteração.
Dai vem o fator incremental.

Primeiro ponto: User Stories ou Use Cases são modelos de requisitos levantados.

Segundo ponto: Saber e expicar o que vai ser construído faz parte das atribuições do analista/programador e participar do levantamento dos requisitos também. (Inclusive no RUP).

Você levantou o pré-suposto e pulou uma etapa do inicio de cada fase baseado em que? Que seu cliente ou analista de negócio vai levantar os requisitos (Inclusive Técnicos) sozinhos? Onde você leu isso isso no RUP?

Entenda casa fase(iteração) possui esses passos.

Clientes e analistas de negócio não precisam levantar requisitos, ora, eles sabem o que precisa ser construído, por isso são, advinha, especialistas no negócio…

Um projeto de software que não pode contar com a presença de especialista no negócio esta fadado ao fracasso antes mesmo de começar e quando podemos contar com as condições mínimas, que é a presença desses profissionais, não há porque levantar requisitos, porque eles já são conhecidos. Acontece que levantamento de requisitos no RUP, é na verdade, um pretexto para waterfall. Com o tempo gerentes aprenderam a dividir a cascata em fases porque descobriram que poderiam controlar melhor, e ainda fazer uso de um menor número de recursos. Assim surgiu o RUP.

Ou seja, a finalidade do “levantamento de requisitos” é para que gerentes tenham um papel entre os reais especialistas do negócio (clientes/analistas de negócio) e os reais implementadores (programadores), funcionando assim como intermediário e podendo exercer controle sobre uma parte importante do processo, sem que para isso precisem de avançado conhecimento técnico (sobre software ou sobre o negócio). Basta traduzir o que se sabe sobre as necessidades do projeto em instruções de alto nível, capazes de serem seguidas por programadores dispostos a executarem um trabalho medíocre, em nome de usuários que só existem na forma de diagramas de casos de uso e especificações incompletas.

Portanto, fica a dica, uma boa forma de identificar se o processo não é iterativo é se ele recomenda começar levantando requisitos.

Não sei aonde você leu isso, mas é justamente isso que a maioria das literaturas que falam a respeito do assunto “NÃO” pregam.

Acho sinceramente que você precisa tentar se informar melhor, sugiro começar pelo PMBOK para entender as fases certinhas de qualquer projeto.

Não sei aonde você leu isso, mas é justamente isso que a maioria das literaturas que falam a respeito do assunto “NÃO” pregam.

Acho sinceramente que você precisa tentar se informar melhor, sugiro começar pelo PMBOK para entender as fases certinhas de qualquer projeto.

PMBOK? Hmm… vc se identificou com o gerente no meu último post foi?