Description:
The preceding figure illustrates the overall architecture of the RUP, which has two dimensions:
* The horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds.
* The vertical axis represents disciplines that logically group activities by nature.
The graph shows how the emphasis varies over time. For example, in early iterations you spend more time on requirements; in later iterations you spend more time on implementation.
[quote=mochuara][quote=Luiz Aguiar]
O RUP nunca foi “cascata”, o que aconteceu há algumas décadas em software foi que fizeram uma relação muito próxima e equivocada de engenharia de software com engenharia civil, então se partiu da prática que para construir um grande sistema deveria seguir as práticas que se usavam pra construir um prédio, dai vem a aplicação do processo cascateado para construção de sistemas, e a necessidade de se ter previamente tudo resolvido antes de colocar um tijolo, quero dizer, escrever uma linha de código.
Ai gente que foi formado com 100% de influência da engenharia civil, pegava o RUP, que por mais burocrático que seja, é um processo iterativo e incremental, e fez dele um cascatão gigante, onde o mundo todo praticamente só o souber usar assim.
E não se enganem, tem muita, mas muita empresa mesmo fazendo mini-cascata com Scrum e XP, achando que estão fazendo muita coisa diferente de RUP. Como diz o Yoshima, “agilidade é inspeção e adaptação”, e sem isso não importa o nome que vc use, não será um processo ágil eficiente.
[]s
[/quote]
Se cascata virou termo para referenciar o anti-pattern que é especificar todo o sistema antes de implementar como isso é diferente de RUP e seus documentos de requisitos?[/quote]
Estude o mínimo sobre RUP que vc vai ver que em nenhum lugar ele fala para especificar TODO o sistema antes de implementar. Se alguém pega isso e faz o oposto, a culpa é de quem?
Se vc tem essa informação contrária, de que na documentação do RUP ele obrigada a especificar 100% antes da implementação, por favor compartilhe conosco esse conhecimento com uma fonte oficial disso, do contrário, seu argumento não será válido.
Se ele manda especificar 100% ou 43% do sistema antes de implementar, isso não importa porque não estamos discutindo se RUP é incremental. A discussão se RUP é um processo iterativo. Eu nunca vi ninguém coletar requisitos durante a fase de implementação (equipes de analistas trabalhando junto com equipes de programadores) com sucesso, e acho que o RUP não prega isso, e durante a fase de teste e deploy faria ainda menos sentido não acha? Se não é antes qual hora seus estudos sobre o RUP sugerem como mais apropriada para especificar?
[quote=mochuara]
… Eu nunca vi ninguém coletar requisitos durante a fase de implementação (equipes de analistas trabalhando junto com equipes de programadores) com sucesso, e acho que o RUP não prega isso, e durante a fase de teste e deploy faria ainda menos sentido não acha? Se não é antes qual hora seus estudos sobre o RUP sugerem como mais apropriada para especificar?[/quote]
Você não está confundindo INTERAÇÃO com ITERAÇÃO né?
Você não é obrigado a levantar TODOS os casos de uso de uma vez, você pode separar eles por principais features da mesma forma como faria ao levantar User Stories (SCRUM) ou Most Important Features (XP) e sim o RUP prega isso sim, trabalho colaborativo em todas fases entre a equipe de análise e desenvolvimento. (Vide documentação do RUP).
Leia o post do iMasters e você vai entender o porquê da palavra Iterativo!
Pessoal, não adianta discutir com o mochuara. Sob pena de inutilizar esse tópico, como ele inutilizou o outro, por favor, não dêem atenção.
Ele tem mistura conceitos e não está nenhum pouco interessado em sequer ler o que vocês apresentam. Tudo isso já foi dito no outro tópico para ele, mas ele prefere ignorar, provavelmente por ter tido muitas experiências ruins no passado com alguma empresa que implementou um processo em cascata e chamou de RUP.
Como vocês podem ver, ele chama de “cascata” algo que está fora da nossa definição. Pois discutir se o processo é ou não cascata é o mesmo que discutir se ele é ou não incremental. Um processo em cascata, por definição, não é incremental.
Por dia, várias empresas falham na implementação de todos os processos. Isso não significa que o processo seja ruim. Isso geralmente significa que a empresa não soube implanta-lo (talvez até, pq nem devesse implanta-lo). Uma coisa que tenho visto em muitas empresas é a implementação do “Scrum” que se resume à Stand-up meeting. Da mesma forma, muitas empresas resumiam RUP a escrever casos de uso e fazer diagramas UML. Nenhuma delas estava realmente disposta a retrabalhar o ciclo, a comunicação, e gastar tempo no restante do processo.
Acho que do ponto de vista individual, o ciclo em cascata não é mesmo intuitivo.
Mas do ponto de vista empresarial, ele é sim. Primeiro, porque até o início dos anos 90, um dos modelos de projeto bem estruturado que tínhamos era mesmo o da construção civil. A analogia de um analista como um arquiteto, de um projetista como um engenheiro e de um programador como um operário era muito forte. Parecia lógico que a informática pudesse se organizar dessa forma. Vale lembrar que naquela época, nem tudo era tão ágil. Para você ter uma idéia, em 1997 trabalhei com um sistema que a compilação levava não menos de duas horas.
Em segundo lugar, o processo em cascata soa intuitivo pela forma que as empresas planejam seus orçamentos. Para o empresário, geralmente é importante ter uma noção exata do custo de um empreendimento antes de começá-lo. E esse processo promete que ao final da fase de análise (ou de projeto), você teria esse custo. Também é uma falácia, pois o empresário ansioso pretende ter esse custo antes mesmo de pagar pela fase de análise e projeto…
De qualquer forma, mesmo no início dos anos 90, já se pregava que esse modelo era fadado ao fracasso. Mesmo em mainframes, onde foi adotado, ele não funcionava. Um dos meus professores, coboleiro de longa data, comentou que faziam ciclos iterativos antes mesmo de enviar o programa no mainframe. Parte dos ciclos eram depurados na máquina, parte em testes de mesa.
Pessoal, tô aqui para agradecer a todos que deram sua contribuição. Foi de grande valor a opinião de vocês e me ajudou a tomar algumas decisões sobre o TCC. Muito obrigado.
Para os curiosos, vou colocar aqui meu TCC que foi aprovado.
De qualquer forma, mesmo no início dos anos 90, já se pregava que esse modelo era fadado ao fracasso. Mesmo em mainframes, onde foi adotado, ele não funcionava. Um dos meus professores, coboleiro de longa data, comentou que faziam ciclos iterativos antes mesmo de enviar o programa no mainframe. Parte dos ciclos eram depurados na máquina, parte em testes de mesa. [/quote]
Teste é uma das fases do waterfall, e vc não vai acreditar, é antes da fase de produção! rs
