Posts

Showing posts from July, 2008

RUP é Igual a eXtreme Programming

Image
O título desse post pode chocar muito as pessoas :) . Mas de fato RUP é tão diferente de eXtreme Programming assim? O propósito desse post é estabelecer os aspectos em que essas duas metodologias tem em comum e também aqueles aspectos que ambas seguem a mesma idéia porem muitas vezes com abordagem totalmente distintas. Se você quiser conhecer mais o RUP pode começar lendo dois post anteriores que fiz sobre o assunto. Os links são estes: http://diego-pacheco.blogspot.com/2008/07/rup-importncia-dos-marcos.html http://diego-pacheco.blogspot.com/2008/07/rup-verdades-e-mitos.html De fato existe muito atrito quando falamos de metodologias/processos por que normalmente as pessoas tem um posição mais a esquerda (XP) ou mais a direita (RUP). Essa minha classificação de mais a esquerda ou mais a direita não é atoa e de fato não é minha :) A figura a cima demonstra o que estou falando. O RUP é mais formal do que o XP. Eu já mencionei isso antes nesse post . Todos já devem saber a recomendação q

5 Motivos para você usar REST ao invez de WS-*

Image
No dia 25/01/2002 Alguém se lembra o que aconteceu? Foi o dia em que as Atividades com Web Services iniciaram no W3C . De lá pra cá, muitas coisas aconteceram. Quem já não teve que escrever um Web Service? Foi divertido? Se as suas respostas foram SIM e NÃO continue lendo senão sai do post :) O que ocorre é que existe uma quantidade imensa de especificações WS-* que nem foram implementadas ainda. Existem vários problemas relacionados a questões relativamente simples em um sistema *local*, como por exemplo transação. Outro problema é a complexidade. É muito complexo e pouco produtivo trabalhar com Web Services. Ahh beleza vai vir um engraçadinho dizendo: "Ahh mas tudo pode usar Xfire ou até mesmo o AXIS", eu digo: "ok". Mas o que acontece na outra ponta? E a sua outra aplicação em C++ ou Smalltalk como fica? Mesmo com Xfire ainda assim existe muita complexidade por traís das especificações WS-*, sem falar em um outro problema o XML, e o custo de se fazer o parser

Chefe ou Lider: Como um GP deve ser?

Acredito que nos (profissionais de TI) já trabalhamos ou ainda estamos trabalhando com "chefes". Será que a disciplina de Gestão de Projeto ainda é utilizada de maneira imprópria mesmo nos dias de hoje? Sim, de fato é. O GP (Gerente de Projetos) tem um papel crucial no sucesso de um projeto de software. Gerente ou Dono do Projeto? Essa questão é mais abrangente, na verdade o ponto é "Gerente ou Dono". Isso se aplica para redes de computadores também. Quem nunca ouviu alguem dizer um Administrador de redes dizendo "É na MINHA REDE ninguém instala programas que não são padrões"? Na verdade esse tipo de "coisa" nos escutamos de gerentes de projetos também. O Gerente deve gerenciar o projeto isso significa manter o time na linha, servir como um motivador e facilitador da equipe, assim ele será um gerente não um dono. O PMI "diz" que o GP deve ouvir os "Subject Matters", ou seja, especialistas e com as informações do mesmo tomar as

RUP: A Importância dos Marcos

Image
Seguindo a linha do post anterior , vou descrever pra vocês um pouco mais dos marcos do RUP bem como o propósito e como eles podem ajudar em termos de gerência de projetos e colaboração entre a equipe. Ciclo de Vida O processo tem basicamente 4 marcos no seu ciclo de vida são elas: Iniciação, Elaboração, Construção e Transição, no RUP corporativo criado pelo Scott Ambler ele adiciona mais dois marcos que são: produção e desligamento. Dentro de uma empresa que mantém o produto de software por anos realizando ajustes referentes a Change Requests e mudanças de legislação e tudo mais o ciclo de vida do EUP(RUP Corporativo) é o ideal. Muitas empresas não utilizam esse tipo de cliclo de vida, algum tratam o 'fato' do sistema estar em produção como 'operação/manutenção' e acabam endereçando os problemas dessa fase com diversos problemas. Mas como o objetivo desse post não é falar de EUP (Fica para outro post) vamos voltar ao RUP. Na figura a cima você pode perceber as fases

RUP: Verdades e Mitos

Image
o Rational Unified Process é um processo de engenharia de software criado pela Rational que posteriormente foi adquirida pela IBM . O processo utiliza muito a UML bem como uma abordagem para projetos orientados a Objetos . Muitos Autores e profissionais da aérea questionam o uso de UML em projetos. Particularmente eu acredito que a UML traz muito valor para um projeto OO, porem devemos discernir quais diagramas são válidos para a realização da Análise de Requisitos, Design e Arquitetura. O próprio Scott Ambler questiona muito o uso "inicial" de ferramentas para a diagramação, a abordagem recomendada por ele é que após um determinado momento do projeto quando o Domínio já está mais maduro que seria interessante diagramar em uma ferramenta. Bom, voltando ao RUP, vou explicar um pouco mais o processo, talvez depois dessa explicação muitos mitos que você ouviu ou ainda ouve posam ser explicados. Caso a sessão a baixo não acabe com suas "Dúvidas, Angustias, Agonias e Tri