Cite as fontes desta afirmação ou prove. E o monte de bons autores que existiram antes e depois deles? Estes 3 ficaram famosos juntos por terem se reunido e unificado algumas das metodologias existentes. E por terem criado a UML (método de Booch, OOSE do Jacobson e OMT do Rumbaugh, deixaram de fora as metodologias Fusion, Shlaer-Mellor e Coad-Yourdon cujos autores não se juntaram ao Booch na Rational). Muito mais gente se juntou ou influenciou o grupo dos 3 na criação da UML incluindo gente famosíssima como Peter Coad, Ward Cunningham (do manifesto ágil e dos CRC cards junto com o Kent Beck), Eric Gamma (gang of four, JUnit, Eclipse), Ralph Johnson (gang of four), Phillipe Kruchten, Bob Martin (manifesto ágil), Bertrand Meyer, Rebecca Wirfs-Brock (impossível ignorá-la), Edward Yourdon, Jeff Sutherland (co-criador do SCRUM) e outros.
Até hoje gosto dos CRC cards do Cunningham & Beck para descobrir as classes do sistema.
Aqui não vou pedir para provar porque TODO mundo sabe quem é o Kent Beck, criador do XP, realmente um digitador de algoritmo (o mais famoso deles é o JUnit).
Recomendo a todos que quiserem falar da história do desenvolvimento de sistemas que antes de qualquer coisa, visitem um site chamado google.com
E já está mais do que na hora de sumirem com o termop engenharia de software. Desenvolvimento de software é desenvolvimento de software. Que arranjem um nome específico para isto como existia antigamente o termo analista de sistemas (muito melhor do que engenheiro de software). Como engenheiro, ser racional, cartesiano, acostumado a trabalhar com fórmulas e métodos determinísticos, nunca vi nenhuma semelhança entre as atividades de um engenheiro com às de um criador de software que manipula grandezas empíricas. Para mim o termo engenheiro de software, apesar de consagrado, não representa nada do que já fiz na vida desenvolvendo sistemas.
Existem metodologias que seguem o modelo waterfall, assim como existem metodologias que seguem o modelo iterativo. Waterfall é um modelo de desenvolvimento, não uma metodologia.
Isso porque waterfall não define um conjunto de processos, como uma metodologia definiria.
Luca, o modelo unificado foi proposto pela primeira vez no livro The Unified Software Development Process, de 1999, escrito por Ivar Jacobson, Grady Booch e James Rumbaugh.
Foi do livro que acompanha este, isto é, The UML user guide de abril/99 que tirei o que escrevi. Mas nem precisava ter escrito tudo que escrevi. Acho que fica claro no U do UML que foi um processo de unificação do que já existia antes.
Foi do livro que acompanha este, isto é, The UML user guide de abril/99 que tirei o que escrevi. Mas nem precisava ter escrito tudo que escrevi. Acho que fica claro no U do UML que foi um processo de unificação do que já existia antes.
[]s
Luca[/quote]
Sim, com certeza. Eu comecei a estudar pelo livro do Grady Booch, que já definia uma metodologia própria. A idéia por trás da UML foi acabar com a “metodology war” que existia na época da estruturada, e que estava começando a surgir na OO. Você deve estar lembrado… uns adotavam Chris Gane, outros o próprio Booch… era uma bagunça.
Aí os metodologistas viram que era mais fácil (e lucrativo também), se juntar e fazer uma proposta só. E claro, abrir com isso uma consultoria, chamada Rational, para vender essa mesma consultoria.
[quote=ViniGodoy]
Existem metodologias que seguem o modelo waterfall, assim como existem metodologias que seguem o modelo iterativo. Waterfall é um modelo de desenvolvimento, não uma metodologia.
Isso porque waterfall não define um conjunto de processos, como uma metodologia definiria.[/quote]
RUP define modelagem e implementacao como fases separadas, isso é caracteristica de processo (ou seja la como vc chama) waterfall.
Todos aqui sabem que se vc precisa esperar a fase de implementacao para saber que o design existente em casos de uso e lindos diagramas UML funciona, entao nao ha avanco em termos de design do software num ritmo suficiente para chamarmos de iteratividade.
E o fato de RUP ser waterfall nao é algo necessariamente ruim. Waterfall é praticamente institucionalizada nas fabricas de software e empresas em geral, com exceçao de algumas consultorias mais descoladas que usam agile. Ou seja, existem muitas oportunidades para o profissional RUP no mercado!
Mochuara, quanto tempo você acha que dura cada fase daquelas? Os tempos são em torno de 1 semana, no máximo. Num ciclo RUP tradicional, você teria o ciclo completo em menos de um mês. É um ritmo próximo de algumas equipes Scrum.
Acho que você claramente confunde desenvolvimento iterativo com desenvolvimento ágil.
Iteratividade é o primeiro princípio básico do RUP. Então, você está falando de um processo que você claramente não conhece.
Mochuara, quanto tempo você acha que dura cada fase daquelas? Os tempos são em torno de 1 semana, no máximo. Num ciclo RUP tradicional, você teria o ciclo completo em menos de um mês. É um ritmo próximo de algumas equipes Scrum.[/quote]
Principalmente se nao houver aquelas reunioes matinais que sao um saco. Mas pelo menos a equipe como um todo colabora para analise e implementacao no SCUM. Nao substime o esforco necessario para fazer isso acontecer no RUP e em processos waterfall em geral, que possuem equipes diferentes para analise e implementacao e portanto precisam transferir esse conhecimento, geralmente por meio de modelos intermediarios extremamente ineficientes.
Aparentemente você teve uma péssima experiência pessoal em algum time que não usava o RUP, mas dizia que usava. Comunicação também é considerado um dos elementos chave de um time RUP de sucesso.
Aparentemente você teve uma péssima experiência pessoal em algum time que não usava o RUP, mas dizia que usava. Comunicação também é considerado um dos elementos chave de um time RUP de sucesso.[/quote]
O grande problema dessas experiências ruins do RUP ao meu ver é a sua utilização em projetos pequenos (e até alguns médios) , que não possuem esse tipo de necessidade, ou seja, o famoso usar uma bazuca para matar formiga.
Temos uma metodologia interna aqui na empresa onde trabalho que nada mais é do que uma cópia barata do RUP.
Para os projetos que pegamos, o que noto é realmente esse processo engessado e pesado que alguns descreveram, que acaba no final das contas não trazendo ganho nenhum de produtividade em troca de organização e “papéis bem definidos”. Agilidade cairia bem melhor neste contexto, mas quem sou eu para falar…
O Processo Unificado foi elaborado por quem entende de Análise e Projeto de Software. Na verdade por quem construi tudo o que voce entende por isso. São eles Ivar Jacobson, Grady Booch e James Rumbaugh. A Metologia Àgil surgiu primariamente no meio universitário, visto o XP, por digitadores de algoritmos (universitarios) e sua simplicidade visceral inspirou gente do mercado como Ken Schwaber do SCRUM que une o melhor dos dois: a filosofia KISS do XP e alguns dos formalismos metódicos e eficazes do PU.
Há muito gente escrevendo sobre Metodologias Àgeis, é uma ladinha sem fim, um blá blá blá. A grande maioria são textos enfadonhos pouco objetivos e concisos e recheados de erros técnicos e total desconhecimento sobre Engenharia de Software. Acho que essas pessoas não deveriam estar na área de exatas, e sim na humanas, por que parece que gostam de escrever para se por a vista.[/quote]
Vc precisa aprender os fatos antes de poder fazer esses comentários. Scrum nasceu do Lean criado pela toyota e não do XP. O XP nasceu do lean aplicado a desenvolvimento ( o scrum é aplicado a gestão). Ou seja, agil não nasceu no meio universitário. Nasceu da filosofia oriental numa fábrica de carros.
Acho que você fez uma simplificação grosseira. Primeiro, porque existem vários tipos de software. Segundo, porque existem várias situações diferentes de deploy, com custos diferenciados em cada uma.
[/quote]
não fiz não. Primeiro porque embora hajam vários tipos de software só existe um processo de software. Este processo é deterministico e baseado em causa-efeito. Vc não pode implementar regras de negocio sem saber quais são as regras de negocio. O processo de software nasce da recolha de dados do ambiente real (dominio) levado à abstração (analise) e depois condensado em codigo (design e programação).
Várias situações diferentes de deploy não interferem com a metodologia agil porque ela atua internamente à empresa , portanto o método de deploy é irrelevante, o que é relevante é que o produto está pronto a ser entregue. Vc está partindo da suposição errada ( e isto é comum, invelizmente devido a traduções simplistas e expliccações de 5 minutos) de que o stakholder final que recebe o produto de software é o consumidor. Não.
A palavra “Client” em inglês traduzido para “cliente” não significa o consumidor. ou seja, não significa aquele que vai usar o osftware e pagar por ele.
A palavra Client significa aquele que está à espera da entrega e a quem ela é devida. É como no sistema de mensageria que falamos em clientes e estes não são necessáriamente desktops finais. Enfim, o deploy é irrelevante para o uso de agil. A prova é que a industria de jogos usa agil e eles têm um processo bem complicado de deploy ( gravar discos, meter em caixas, transportar, etc… nada disso têm que ver com o software).
Por definição ela não serve para nada. Se vc tem um processo e nele existe uma necessidade de documentação de alguma coisa, isso é uma necessidade. Caso contrário é uma burocracia.
Isso simplesmente não faz sentido. A unica coisa que evita erros é o teste.
Se vc está querendo dizer que a documentação prévia evita erros, errado de novo. Apenas a comunicação evita erros desse tipo, e documentar não é comunicar ( porque falta garantir que alguem lê).
Sim.
não. um erro “não detectado” que pode representar o callback das placas.
Num processo de firmware o teste é conduzido sobre a placa. Considerando que a placa em si não tem erros, qq erro decorrente é do firmware e corrigido no momento. Vc tem 1 software e 1 placa em ambiente de teste. Vc não tem milhares de placas. Assim que esse firmware for exaustivamente testado na placa , passamos a outra bateria de testes com placas semelhantes. Etc… Em nenhum ponto deste processo o usuário da placa teve acesso a ela e em nenhum momento eu recolhi placas já entregues.
A iteratividade é feita durante o desenvolvimento do software. Por definição o desenvolvimento acontece antes do deploy. Vc está misturando as bolas…
Não. Não ajuda. Mas muitos (como você) acham que é uma boa desculpa para waterf… perdão, “processo burocrático”.
Lembre-se que Lean nasceu na toyota onde eles fazem carros numa linha de montagem gigante. O deploy está sendo feito continuamente já que quanto mais o carro se aproxima do fim da esteira mais perto está do deploy. Isto é só para mostrar que coisas de hardware tb podem seguir processos ageis.
[quote=“mochuara”]Elemento chave? Voce tirou isso do wikipedia tb?
Sim, estou falando de experiencias reais.[/quote]
Eu coloquei um link da wiki, mas caso você não tenha notado, o primeiro link era da IBM. Se quiser, posso linkar mais páginas que mostram que o processo unificado é iterativo. Ou talvez seja melhor você pegar um material impresso, como o já citado livro do Craig Larman.
Não sei de onde você tirou a idéia de que não estou falando de experiências reais. Pelo menos, foi o que você deu a entender na sua frase.
Eu trabalhei junto a uma empresa que não só utilizava, como dava consultoria no processo unificado. E, por sinal, as coisas funcionavam muito bem por lá.
Creio que você deve ter tido experiências ruins por uma coisa que o Sergio vive repetindo. As pessoas usam um processo pela metade e, quando as coisas dão errado, culpam o processo ao invés de culpar a si mesmas.
Você mesmo repetiu várias vezes práticas que são abominadas no RUP, como a falta de comunicação entre analistas e programadores, e waterfall. O RUP é um processo iterativo, comunicativo, baseado em práticas modernas de software. É mais burocrático? Sim, é sim. Mas não é um processo ruim, e há vários casos de sucesso que comprovam isso.
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.
Certo. E como você garante que os testes foram executados corretamente? Ou como você garante a cobertura dos testes? E como você rastreia os erros reincidentes e localiza suas causas? Ou os evita no futuro?
Confia apenas na palavra do programador? É claro que documentar não é comunicar, mas a documentação ajuda no processo comunicativo.
A maioria do material que você estuda nada mais é do que um documento, de alguém que entende do processo.
A documentação não precisa ser burra. Pode ser inteligente, com muito material gerado automaticamente. Na verdade, a própria escrita de testes, muitas vezes, é uma espécie de documentação, que é bastante efetiva associada ao relatório da ferramenta que analisa sua cobertura e descreve sua execução.
Como eu falei, o próprio processo unificado estimula que seja assim.
Se vai haver alguém para fazer a conferência, existe a necessidade de documentação, explicando como as coisas foram feitas.
Senão é impossível conferir e se certificar.
Isso é óbvio. Em qualquer processo, os erros devem ser detectados o quanto antes possível. E para isso, há que se garantir que os testes estão sendo executados devidamente. Sem documentação, é mais difícil dar garantias.
Você está falando aqui antes da primeira entrega. E, se você reler o que escrevi, foi quando falei que você realmente poderia ter um processo mais iterativo, que é “entre” as entregas. Entretanto, sua empresa terá que garantir o software da placa mesmo depois de entregue, na mão do cliente final. E é aí o momento em que o erro fica enormemente caro. E é aí que você terá que recolher placas. E, mesmo durante a fase de sustaining, existe desenvolvimento de software.
Eu trabalhei na indústria. E sei o quanto eles são extremamente paranóicos com esse processo. Recolher hardware ou atualiza-lo em campo pode ser catastroficamente caro. Assim como recall de automóveis. E, mesmo a indústria automobilistica e aeronáutica, que desenvolveram muitos dos processos ágeis, ainda são extremamente burocráticas.
Por isso, antes da geração do lote, é comum que hajam processos mais burocráticos. Relatórios que permitam a rastreabilidade, verificabilidade e cobertura dos testes. Documentos que permitam identificar erros de processo, para aquele produto que retorna. Identificar que falhas ele pode conter, e se será melhor repara-lo ou simplesmente atualizar seu software.
É lógico, para que eles sejam efetivos, é preciso gera-los corretamente. E também é importante gerar apenas os dados mais relevantes.
Também é importante diferenciar as coisas. O RUP considera as manutenções, mesmo após o deploy, como parte do ciclo de desenvolvimento de software. Afinal, isso existe. As empresas não viram as costas simplesmente e ficam isentas de compromisso. O software, mesmo depois de entregue ao cliente final, é analisado e permanece em desenvolvimento. Seja para a inserção de novos features ou correções de bug. É lógico que podem haver ciclos antes do deploy com clientes diferentes do final. Em momento nenhum negligenciei isso. Mas o objetivo final da empresa não é agradar a esse cliente, e sim, aquele que vai ser o mais chato, e que estará na ponta final do processo.
E não se pode negar que as coisas ficam muito mais fáceis quando esse cliente pode receber atualizações, sem nem mesmo perceber que isso aconteceu, como ocorre nos ambientes web hoje em dia.
Embora eu tenha repetido milhares de vezes que usa-se ciclos iterativos, sprints curtos, fases de poucos meses, você ainda insiste em dizer que defendo waterfall. Bom, a forma irônica como você falou, para mim é FUD, uma mostra que quando os argumentos acabam, é uma boa tentar ridicularizar aquele que fala.
Como eu já repeti dezenas de vezes, nenhuma empresa de software hoje em dia deve usar ciclo waterfall. Nenhuma. Eu não recomendaria ciclos de mais de 2 meses (que já considero extremamente longos) para a mais rígida e burocrática empresa de software existente. O problema de discussões desse tipo, é que se você desvia um milímetro da opinião dos “ágeis”, você estará falando de um processo “extremamente burocrático e 100% waterfall”. Será realmente que você não está lendo o que escrevi?
E, só para constar, eu trabava com Extreme Programming e hoje com Scrum. Ambos os processos ágeis, e ambos ótimos, na minha opinião.
Só um último comentário. Não é nesse sentido que estou usando a palavra burocracia. Você deu uma conotação pejorativa, que nada tem a ver com o que estou falando.
Acho que você fez uma simplificação grosseira. Primeiro, porque existem vários tipos de software. Segundo, porque existem várias situações diferentes de deploy, com custos diferenciados em cada uma.[/quote]
Eu concordo com você, Vinícius. Mas já me desvirtuei da conversa por motivos de falta de educação… Nem todos são gentlemen. Mas estou de acordo em praticamente tudo o que você falou.
[quote=ViniGodoy]
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.[/quote]
[quote=mochuara][quote=ViniGodoy]
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.[/quote]
:shock: :?: [/quote]
Exatamente. Aparentemente vc sofreu na mão de alguma chefia irresponsável. Alguma empresa que usava processo waterfall, tinha uma hierarquia que mais lembrava a do exército. E, para não dizer que a culpa era dos funcionários (não estou incluindo você, mas geralmente são os implantadores do processo “revolucionário”), falavam que “o RUP é assim”. E agora está descarregando sua frustração (consciente ou inconscientemente) aqui no fórum.
Infelizmente, estamos cheios de empresas assim. Eu mesmo já trabalhei numa (sorte que não por muito tempo), e tive diversos colegas que trabalharam também. No caso da minha, não era o RUP, mas atribuam a própria incompetência ao processo da Microsoft (aliás, alguém se lembra desse processo?)
[quote=ViniGodoy][quote=mochuara][quote=ViniGodoy]
O que você até agora tem falado são coisas que não são RUP. Não sei de onde você tirou, mas mostram claramente que você não tem nenhum conhecimento sobre o processo, nunca utilizou e está só descontando a frustração de alguma chefia que para fazer arbitrariedades, usava o nome desse processo como justificativa.[/quote]
:shock: :?: [/quote]
Exatamente. Aparentemente vc sofreu na mão de alguma chefia irresponsável. Alguma empresa que usava processo waterfall, tinha uma hierarquia que mais lembrava a do exército. E, para não dizer que a culpa era dos funcionários (não estou incluindo você, mas geralmente são os implantadores do processo “revolucionário”), falavam que “o RUP é assim”. E agora está descarregando sua frustração (consciente ou inconscientemente) aqui no fórum.
Infelizmente, estamos cheios de empresas assim. Eu mesmo já trabalhei numa (sorte que não por muito tempo), e tive diversos colegas que trabalharam também. No caso da minha, não era o RUP, mas atribuam a própria incompetência ao processo da Microsoft (aliás, alguém se lembra desse processo?)[/quote]
Assim como cara-palida? Estou falando de waterfall e agile, nao de empresas, e muito menos de experiencias especificas. Se a equipe é incompetente é uma outra discussao mas porque a impressao de que estou cacando culpados, ou ainda, descarregando frustacao? só estou esclarecendo pra vc como waterfall é diferente de agile, sem entrar no merito se metodologia X é boa ou ruim, é tao dificil pra vc discutir sem achar existe um complô da casa branca contra o RUP?
E a menos que haja uma nova definicao de RUP onde os requisitos sao especificados em testes executaveis por exemplo, o design definido no proprio codigo e nao em diagramas e documentos (que depois vao ser interpretados por digitadores de codigo), nao consigo ver RUP como sendo iterativo, mas sim uma versao incremental de waterfall.