RUP pode ser ágil?

Programação Arquitetura
#21

Bom,

O RUP não é um Framework, é um Processo de Engenharia de Software que pode, e deve ser customizado, para atender as necessidades de cada projeto ou de uma empresa, visando justamente agilizar e organizar o ciclo de vida do software garantindo qualidade.

É como a UML: na versão 2.0 temos 8 diagramas, mas quem usa todos em um unico projeto? Você tem um leque de opções baseadas em um segmento, basta escolher o que melhor atende a necessidade. É para isso que existem Engenheiros e Arquitetos de Software, para definirem essas coisas… geralmente são pessoas que possuem N certificações…

Ah, lembrando que, usando o RUP deve-se passar por todas as fases do ciclo (4 fases) e as disciplinas (são 9), só precismos escolher bem quais artefatos usarmos… (só não me lembro quantos mil artefatos possui o RUP)

[quote]No desenvolvimento do software, um Framework é uma estrutura de suporte definida em que um outro projecto do software pode ser organizado e desenvolvido. Tipicamente, um Framework pode incluir programas de apoio, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes do seu projecto[/quote].

#22

Bom, a ThoughtWorks nao eh nem fabrica, nem do Fowler :wink:

Nao tem nenhum projeto usando RUP. Se a premissa eh que TEM que usar RUP, a gente prefere pular fora do que ficar se torturando.

#23

Tem certeza?!? :roll:

http://www.thoughtworks.co.uk/profiles/Fowler,+Martin.html

Bom, não quis dizer que ele é o dono absoluto… e realmente, definir o que é fábrica de software também é bem difícil… :slight_smile:

#24

http://www-306.ibm.com/software/awdtools/rup/

[quote=coutinho]

Essa definição não está exata. Desenvolvimento de software é muito mais que codificação e construção de programas e ele faal apenas disso.

#25

Pessoal,

Desculpem se fui superficial, afinal nao gosto de postar nada sem uma explicacao razaovel, cientifica. Afinal, aqui neste forum so tem fera.

O problema que vi na pratica com o RUP, e que eu trabalhei numa empresa de software que aplicou RUP e passou anos fazendo modelagem de um sistema, sem implementar nada. Deve-se evitar esse extremo. (A propria empresa percebeu isso).

Na XP, codificar e desejado assim q se tenha uma ideia clara, apos uma boa conversa com o cliente, seguindo um processo bastante rigoroso.
O objetivo da XP nao e entregar qualquer codigo funcionando, mas um codigo de qualidade, por isso , usa-se testes automaticos, refatoring, etc.

Na minha opiniao , pode ser dificil integar RUP com XP, pelos seguintes motivos:
RUP e um processo baseado na engenharia de software tradicional, em que se acreditava que a documentacao deve ser extensiva e completada antes da implementacao.
(Se eu estiver errado me corrijam!)

Em processos ageis nao da pra fazer isso, devemos ser ageis!
Precisamos manter algum codigo funcionando que atenda as expectativas do cliente, e modificar esse codigo a fim de se obter qualidade.

Bem, se existem alternativas, seria adaptando as duas estrategias.
Tudo e possivel, nao devemos ver as coisas como opostos, afinal, isso e a base da sabedoria chinesa :slight_smile:

#26

Isto é um processo em waterfall, o RUP (quando usado ‘de verdade’ - e eu nunca vi isso) é iterativo incremental.

Lembre-se que o tem principal da thread é agilidade, não XP. RUP não precisaria se integrar com XP para ser ágil.

Falando nisso, ainda sobre o coutinho:

O ágil aqui é um pouco mais específico e baseado em:

#27

Tem certeza?!? :roll:

http://www.thoughtworks.co.uk/profiles/Fowler,+Martin.html[/quote]

http://www.thoughtworks.co.uk/profiles/Villela,+Carlos.html

(em outras palavras, sim, tenho certeza ;))

#28

[quote=cv]

http://www.thoughtworks.co.uk/profiles/Villela,+Carlos.html

(em outras palavras, sim, tenho certeza ;))[/quote]

Exibido! 8) É que realmente pensei que ele era o dono da padaria aí… :lol:

hshshshshs

#29

Um trecho de um artigo do Fowler:

#30

’

#31

Desculpe, mas a matéria não esta dizendo que o RUP é um framework, se sim, que o RUP com IBM® Rational® Method Composer (o framework em questão)

Vamos aos fatos, supostamente, simples perguntas e respostas:

  1. Qual framework é usado na empresa em que você trabalha?
    Possivel Resposta: HIBERNATE, VELOCITY, STRUTS, etc

  2. Qual Processo de Desenvolvimento é usado na empresa?
    Possivel Resposta: RUP, MDA, etc

Agora vamos responder como se o RUP fosse um framework

  1. Qual framework é usado na empresa em que você trabalha?
    Possivel Resposta: RUP, MDA, etc

  2. Qual Processo de Desenvolvimento é usado na empresa?
    Possivel Resposta: Nenhum, só tem framework lá…

[quote=pcalcado]
Essa definição não está exata. Desenvolvimento de software é muito mais que codificação e construção de programas e ele faal apenas disso.[/quote]

O que mais se aplica? se essas palavras não conseguem definir um framework… cite mais definições de framework… tenho curiosidade…

falows…

#32

MDA não é framework… que literatura defende isso?

Coutinho, o texto é claro ao dizer que o RUP é um framework de processo…

[]s

#33

[quote=rodrigoy]MDA não é framework… que literatura defende isso?

Coutinho, o texto é claro ao dizer que o RUP é um framework de processo…

[]s[/quote]

Exato! viu só como fica fora de contexto, é bem isso que eu quis mostrar, assim como MDA não é framework o RUP tb não é

Processo != Framework

#34

[quote=coutinho][quote=pcalcado]
The RUP process framework with IBM Rational Method Composer includes:

http://www-306.ibm.com/software/awdtools/rup/
[/quote]

Desculpe, mas a matéria não esta dizendo que o RUP é um framework, se sim, que o RUP com IBM® Rational® Method Composer (o framework em questão)
[/quote]

Desculpe, mas está sim, basta traduzir corretamente a frase:

“O framework de processo RUP com o IBM Rational Method Composer”, e o Composer é uma suíte da qual o RUP faz parte agora.

Outra página:

[quote=IBM]
IBM Rational Unified Process®, or RUP®, is not only software engineering process, but also an industry-wide platform for best practices. By adopting proven best practices and a customizable process framework, software development organizations are finding they are able to communicate more clearly and deliver higher-quality software more predictably. “Our biggest challenge is ensuring the communication on the respective levels on the team. I think where Rational has really helped us is that it has standardized a language of how the teams talk to each other,” says John Pritchard, Architect for Lockheed Martin.[/quote]

http://www-306.ibm.com/software/success/cssdb.nsf/CS/JENS-5WWRAH?OpenDocument&Site=rational

Ou outra:

http://www-306.ibm.com/software/awdtools/rmc/index.html

Mas se restar alguma dúvida faça esta pesquisa no Google:

http://www.google.com.br/search?hl=pt-BR&q=site%3Aibm.com+rup+framework&btnG=Pesquisa+Google&meta=

Repetindo: Frameworks não são apenas estruturas de programação como Hibernate, Spring e etc.

Framework é um conceito que pdoe ser aplicado em diversas áreas.


http://www.google.com.br/search?q=define:framework&hl=pt-BR&lr=&oi=definel&defl=en

É tudo uma questão de procurar.

#35

Não acho que seja uma questão de procurar, até porque eu já sei do que se trata e tenho minha opinião muito bem formada.

Bom, não vou questionar mais, senão vamos ficar aqui, paginas e mais paginas, uma dizendo que é e o outro dizendo que não é!

Agora, só acho que deveriamos então, sugerir a IBM Rational alterar o nome do RUP (Rational Unified Process) para RUF (Rational Unified Framework)

Para finalizar, uma coisa é possuir frameworks, ser constituidos por, e outra é ser um framework.

Encerro por aqui meus argumentos. Não quero causar confusão

falows… desculpe qualquer coisa

#36

Sim, o UP pode ser ágil ! :smiley:

Os autores do UP não tinham a intenção de tornar o processo burocrático em meio a um infinidade de artefatos, isso porque ele tem um conjunto enorme de artefatos opcionais.

Para que você utilize UP agilmente , escolha um conjunto menor de artefatos e tarefas, buscando a simplicidade.

Como o desenvolvimento é iterativo, crie o Plano de Iteração de forma adaptável.

#37

Fabricio, releia o seu post, e identifique as falhas e furos com o Agile Manifesto :wink:

#38

Ok cv,

não percebi qualquer furo nele. Se você puder identificá-los … :wink:

Vc pode fazer uma analogia ao UP com uma farmácia, onde a farmácia dispõe de uma infinidades de medicamentos, e o paciente escolhe qual ou quais estarão sendo úteis para o seu tratamento, a mesma coisa com o UP, dispões de muitos artefatos opcionais, todos são opcionais, menos o código (claro). Desse ponto de vista como o processo é iterativo, e o manifesto ágil propõe isso, então estaria perfeitamente adaptável, lógico que no processo ágil você não vai colocar artefatos e atividades desnecessárias, você vai escolher aqueles que melhor se adequa a metodologia, se for 1 ou 2, ótimo,contato que siga estes principios:

:arrow: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

:arrow: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

:arrow: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

:arrow: Business people and developers must work together daily throughout the project.

:arrow: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

:arrow: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

:arrow: Working software is the primary measure of progress.

:arrow: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

:arrow: Continuous attention to technical excellence and good design enhances agility.

:arrow: Simplicity–the art of maximizing the amount of work not done–is essential.

:arrow: The best architectures, requirements, and designs emerge from self-organizing teams.

:arrow: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

#39

Voce tambem pode fazer uma analogia entre RUP e uma Kombi '79 que vende caldo de cana na feira: sempre tem um barulhinho aqui, uma peca faltando ali, e a ultima vez que o motor viu uma troca de oleo foi ha umas duas decadas. Mas enquanto o treco andar a mais de 20 por hora vc ta comemorando. Dai quebra, pega fogo ou nao funciona mais, e vc fica se perguntando o que aconteceu – mas, antes de realmente conseguir investigar, ja comprou outra Kombi.

Eu nao engulo esse papo de artefatos opcionais. Se todos artefatos sao opcionais, menos o codigo, entao cade a consistencia e a tao-chamada qualidade que os pregadores do RUP tanto pregam?

#40

[quote=coutinho]Não acho que seja uma questão de procurar, até porque eu já sei do que se trata e tenho minha opinião muito bem formada.

Bom, não vou questionar mais, senão vamos ficar aqui, paginas e mais paginas, uma dizendo que é e o outro dizendo que não é!

Agora, só acho que deveriamos então, sugerir a IBM Rational alterar o nome do RUP (Rational Unified Process) para RUF (Rational Unified Framework)

Para finalizar, uma coisa é possuir frameworks, ser constituidos por, e outra é ser um framework.

Encerro por aqui meus argumentos. Não quero causar confusão

falows… desculpe qualquer coisa

[/quote]

O que eu acho que está lhe faltando é uma definição correta do que é framework. Frameworks não são apenas “bibliotecas ao redor das quais você organiza e constrói seu projeto”, mas é uma estrutura pré-definida que ajuda a servir como guia para construir alguma coisa (dica: veja a definição de framework em http://dictionary.reference.com/search?q=framework ). Sendo assim, não vejo nenhum problema em considerar o RUP como um framework para processos de desenvolvimento. :wink: