gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
O que é Extreme Programming
Contribuído por js em 06-04-05 2:48
do departamento 01000001-01000010-01000011
Tecnologia Gama Franco escreve "Quando entrei para a faculdade ensinaram-me que para contornar um problema era necessário pensar um pouco sobre ele. Mais tarde..."
Mais tarde, conforme o curso foi progredindo acabei por ter cadeiras de análise onde me ensinaram metodologias de desenho de software. Com isto sempre me motivaram a pensar muito bem num assunto antes de começar a desenvolver código. Ensinaram-me também que os erros cometidos durante a fase de análise teriam um custo elevado durante a fase de desenvolvimento. É claro que no mundo de engenharia de software os requisitos iniciais acabam geralmente por ser alterados, e sempre me alertaram para o facto de ser importante a aplicação de um desenvolvimento iterativo. Isto implica que se estamos em fase de desenvolvimento e os requisitos são alterados, deveremos reflectir essas alterações para a análise e desenho.

É verdade que sempre que se começa um projecto novo estamos desejosos de meter as mãos no código. Será que as metodologias de análise são mesmo as mais eficazes? Será que quando existe uma alteração de requisitos, o facto de os termos que reflectir no desenho não está realmente a aumentar o preço de cada linha de código que estamos fazer?

Para responder a estas e outras questões começaram-se a fazer algumas investidas em técnicas que permitam minimizar o impacto da entropia gerada durante o ciclo de vida do software. Uma dessas técnicas tem o nome de Extreme Programming (XP).

Pode-se resumir a metodologia XP numa técnica que tem como filosofias centrais a simplicidade e o adiamento do desenvolvimento de requisitos até à altura em que eles são realmente necessários. Isto porque muitas vezes não temos o correcto conhecimento do que se quer para a aplicação... nem nós, nem o cliente. A metodologia (XP) permite que seja feita uma análise cuidada durante os primeiros passos do projecto, mas pouco mais que isso. Para termos a certeza de que o que estamos a fazer está realmente a seguir um bom caminho, costuma-se aplicar uma iteração de três passos por cada nova funcionalidade que se pretende desenvolver:

  1. Fazer os testes.
  2. Desenvolver código até os teste passarem.
  3. Refactoring.

O primeiro passo é realmente muito importante. Isto porque segundo esta técnica a única razão para se desenvolver uma linha de código é ter um teste que não passa. Se sempre que fizermos uma alteração no código conseguirmos correr todos os testes, temos a certeza que o programam continua tão coerente como estava. Podemos juntar a esta vantagem o facto de que, enquanto fazemos o teste estamos a pensar na estrutura do método que se pretende desenvolver.

No segundo passo aplica-se uma regra de minimalismo, desenvolver código apenas o suficiente para passar os testes. Isto porque ao desenvolvermos funcionalidades em excesso estamos a cometer dois erros. Em primeiro lugar poderemos estar a dar prioridade a um pormenor em favor de outros mais urgentes. Em segundo lugar o código adicional poderá nunca vir a ser necessário. Sendo assim porque haveremos de produzir funcionalidades antes de elas serem realmente necessárias?

O terceiro e último passo é de todos o mais importante. Refactoring consiste em reorganizar o código desenvolvido, ou seja, redesenhar o método. Existe um conjunto de regras muito rigidas que nos facilitam nesta tarefa. Por exemplo, se temos código repetido em vários métodos devemos encaplulá-lo num método privado.

Seguindo estes três simples passos estaremos a aplicar apenas um parte da metodologia XP. Com isto estamos a apostar numa técnica virada para o desenvolvimento, e os testes dão-nos a confiança necessária para saber que estamos no bom caminho. Mas nada melhor que o google para nos dar mais detalhes numa técnica que, a meu ver, fará um combate cerrado aos métodos orientados à análise. "

Linux e os limites de tráfego | Acrobat Reader 7  >

 

gildot Login
Login:

Password:

Referências
  • Mais acerca Tecnologia
  • Também por js
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Testes (Pontos:1)
    por JayavarMaN em 06-04-05 5:06 GMT (#1)
    (Utilizador Info)
    Este [1] artigo sobre testes e' interessante no contexto que descreves.

    [1] http://www.osteele.com/archives/2003/08/test-versus-type
    Grande método (Pontos:2)
    por Vx em 06-04-05 9:12 GMT (#2)
    (Utilizador Info)
    Eu uso uma versão modificada do método XP para programar. Tem algumas coisas que acho meias tontas como por exemplo haver apenas um computador para cada dois programadores para os manter "acordados". Enfim se calhar é uma boa ideia.. Mas eu não consegui aplicar isso. Agora as reuniões em pé de 30 minutos são um must :) e os testes e live cases são fabulosos. Mas isso é um método de RAD (Rapid application development) nunca usei para projectos grandes nem sei como se pode comportar.

    --
    Todos têm direito a serem imbecis. Alguns abusam do direito...

    Pair Programming (Pontos:1)
    por Coronel em 06-04-05 11:09 GMT (#4)
    (Utilizador Info)
    haver apenas um computador para cada dois programadores para os manter "acordados"

    Um artigo sobre Pair Programming.

    Exacto (Pontos:1)
    por rmachado em 06-04-05 10:04 GMT (#3)
    (Utilizador Info)
    Como trabalho no QA (vulgo testes), sei bem o que significa testar, mas infelizmente as mentes dos programadores são muito anti testes, pelo menos onde trabalho. Acho que nas Universidades não dão devida importância a Engenharia de Software e normalmente não dão cadeiras de Gestão de Processos em Software... E as pessoas depois não percebem que isso lhes faz falta... Mas isto sou eu que acho...
    DSDM and Agile (Pontos:2)
    por leitao em 06-04-05 15:40 GMT (#6)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Se estas interessado em XP entao deves ler sobre DSDM e (mais em geral) Agile Methodologies - XP e' apenas uma delas.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Sobre XP (Pontos:1)
    por X|r|X em 06-04-05 16:11 GMT (#7)
    (Utilizador Info)
    No ISCTE vai ter um seminário de metodologias ágeis. É nos dias 14 e 15 de Abril. Abraços X|r|X
    Re:Sobre XP (Pontos:2)
    por tourt em 06-04-05 22:00 GMT (#8)
    (Utilizador Info)
    Site oficial do evento: http://torga.iscte.pt/ageis/

    Cumprimentos
    Artur Martins

    ----------
    cat /usr/src/linux/arch/i386/boot/bzImage > /dev/dsp, and the voice of god will be heard.

    Re:Sobre XP (Pontos:2)
    por leitao em 07-04-05 9:05 GMT (#9)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    No programa, segundo um tal de Paulo Correia (e cito):

    Hoje em dia, segundo o Gartner Group, 80% a 90% dos projectos de IT fracassam.

    Nunca vi estes numeros, e tenho acesso ilimitado 'a pesquisa da Gartner.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Re:Sobre XP (Pontos:2)
    por [Cliff] em 07-04-05 9:11 GMT (#10)
    (Utilizador Info) http://www.yimports.com/~cpinto
    É daquelas estatísticas que se auto-perpetuam... como os 90% do IE, etc. Desde que os números agradem ao povo, ninguém contradiz :-)

    ---
    Este espaço pode ser seu...
    Re:Sobre XP (Pontos:1)
    por vaf em 08-04-05 13:15 GMT (#23)
    (Utilizador Info) http://students.fct.unl.pt/users/vaf12086/
    ...memes de sucesso que se propagam sem que ninguém lhes deite a mão.
    Re:Sobre XP (Pontos:2)
    por toze em 07-04-05 10:07 GMT (#12)
    (Utilizador Info) http://mega.ist.utl.pt/~tozevv
    Sim, essas estatísticas começam sempre nos 80% da lei da Pareto por alguma razão :P

    Tó-Zé 'Senador'
    Re:Sobre XP (Pontos:2)
    por 4Gr em 07-04-05 23:26 GMT (#18)
    (Utilizador Info) http://www.fe.up.pt/~ei02069/blog
    Bem, eu ouço ecoar por alguns professores de Engenharia de Software que o valor se situa nos 40 a 50%, tendo agora reduzido com a evolução da Engenharia de Software e da normalização dos métodos e estratégias de um problema de gestão de software (que é bem mais intangível e com tantas ou mais variáveis que um outro qualquer problema de gestão). Parecem-te valores razoáveis?

    Remember: If M$ has it now, someone had it before!
    Dominus vobiscum
    Re:Sobre XP (Pontos:2)
    por leitao em 08-04-05 9:02 GMT (#19)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Nao.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Re:Sobre XP (Pontos:1)
    por Coronel em 08-04-05 10:43 GMT (#20)
    (Utilizador Info)
    Então que valores é que achas que se aproximam da realidade?
    Re:Sobre XP (Pontos:2)
    por leitao em 08-04-05 10:51 GMT (#21)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Nenhum, porque ninguem consegue definir quando e' que um projecto "falha".


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Re:Sobre XP (Pontos:2)
    por [Cliff] em 08-04-05 13:02 GMT (#22)
    (Utilizador Info) http://www.yimports.com/~cpinto
    Isso é um mito ;-) Um projecto falha quando falta produtividade aos programadores ehehehe "quando a onda bate..."

    ---
    Este espaço pode ser seu...
    Re:Sobre XP (Pontos:1)
    por X|r|X em 08-04-05 15:30 GMT (#24)
    (Utilizador Info)
    Um projecto falha quando não cumpres prazos ou custos ou requesitos. Resumindo, falha quando o cliente não fica feliz.

    Aceitarias que quando um empreiteiro fosse fazer obras em tua casa, e estivesse sempre a adiar a entrega e estivesse sempre a pedir mais dinheiro?

    Não ias ficar feliz não é?

    A obra poderia chegar ao fim, mas já não foi no molde que foi acordado inicialmente, por isso falhou (seja qual for o motivo).

    O problema hoje com os projectos de software, não está na tecnologia, nem está nos programadores, e sim a nível de questões de gestão. Como o nível das competências entre empresas estão muito equivalentes, as empresas estão a ganhar projectos na base de prazos mais apertados. Isto tudo com base na lógica que 9 mulheres grávidas "produzem" um bébe por mês.
    Então um proj que duraria 6 meses, passa a ter que durar 3 meses. É só meter mais programadores...

    Enfim, acho que são conceitos de construção cívil aplicados à engenharia de software. Conceitos esses que não são correctos nem na construção cívil (vejam o exemplo da obra do metro na praça do comércio)

    O ppl é engenheiro, não é vidente e não consegue prever tudo.

    Abraços
    X|r|X


    Re:Sobre XP (Pontos:2)
    por [Cliff] em 07-04-05 10:06 GMT (#11)
    (Utilizador Info) http://www.yimports.com/~cpinto
    11:10h Utilização de métodos ágeis no Visual Studio 2005
    UH!??!? Querem lá ver que o Visual Studio faz drag'n'drop de XP? :-)


    ---
    Este espaço pode ser seu...
    Tem as suas coisas... (Pontos:1)
    por daem0n1x em 07-04-05 17:17 GMT (#13)
    (Utilizador Info)
    Pessoalmente, não me entusiasma muito, embora tenha conceitos excelentes, como os unit-tests. Depois de começar a desenvolver com unit-tests, já não quero outra coisa.
    Mas sou a favor de uma abordagem centrada na análise. Acho que se deve programar o menos possível. O pessoal com quem trabalho, no início dos projectos, normalmente já têm formigueiros nos dedos para começar a bater código. Acho que isso nunca leva a bons resultados, é um vício que se deve perder. Infelizmente, da parte das chefias vejo apoio para que se trabalhe desta forma desastrosa.
    Acho que o XP tenta, de certo modo, justificar e encorajar esta abordagem de "code monkey". Penso que isto só funciona em projectos de muito pequena dimensão, em que não há muito para pensar. Em projectos um pouco mais ambiciosos, acho indispensável que as pessoas se sentem, pensem e façam a especificação em UML antes de se meterem a bater código à parva. Há uma quantidade enorme de problemas que se prevêem e evitam assim. E há um monte de dúvidas que surgem e que convém perguntar ao cliente, na altura certa, que é quando se está a desenhar o software. Não é quando a aplicação já está meio feita e tem que se remexer toda de alto a baixo por causa de um pormenor em que ninguém pensou!
    Temos que meter na cabeça que o trabalho dos engenheiros é conceber coisas, não é batucar código. Em nenhuma área da indústria se manda os operários construir um produto sem ele ser todo especificado e desenhado. Apenas na indústria de software se procede assim, que ainda se assemelha mais a uma artesania que a uma indústria.
    Re:Tem as suas coisas... (Pontos:2)
    por [Cliff] em 07-04-05 17:37 GMT (#14)
    (Utilizador Info) http://www.yimports.com/~cpinto
    Estive a ler alguma (ergh, um bom bocado :-)) de papelada sobre XP, etc e se percebi bem, grande parte da XP cobre a "last mile" do desenvolvimento. O UML vem antes disso. Os requisitos vêm antes disso. Em projectos (de grande dimensão) se não tens um critical-path definido à partida mais vale estar quieto, com ou sem XP. NMO, o ideal será um mix de tudo, aliás, fiquei *bastante* curioso relativamente ao pair-programming e aos resultados que daí possam advir.

    ---
    Este espaço pode ser seu...
    Re:Tem as suas coisas... (Pontos:2)
    por [Cliff] em 07-04-05 17:53 GMT (#15)
    (Utilizador Info) http://www.yimports.com/~cpinto
    Need... some... sleep...

    Queria adicionar mais coisas :)

    Por ex. após teres o domínio público definido (interfaces publicas, etc), acho que se pode aplicar alguma da metodologia XP ao privado como o refactoring. Não consegui/consigo acreditar que o refactoring constante se consiga aplicar com sucesso a toda a aplicação (falha-me a tradução para cut through) e acho que isso seria um caminho para o insucesso que o XP tenta combater.

    Outra metodologia é o DSDM que o Leitão mencionou mais atrás e esta parece-me que se aplica ao nível do planeamento e que ser aplicada com sucesso em projectos de grande envergadura (big bucks).


    ---
    Este espaço pode ser seu...
    Re:Tem as suas coisas... (Pontos:2)
    por leitao em 07-04-05 21:07 GMT (#16)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Em projectos um pouco mais ambiciosos, acho indispensável que as pessoas se sentem, pensem e façam a especificação em UML antes de se meterem a bater código à parva.

    O UML e' mais uma daquelas ferramentas que parece ser uma grande ideia, mas que depois na pratica nao funciona sempre bem (ou muito raramente).

    O problema do UML e' que tenta ser tudo para todos, e a notacao tornou-se tao generica (e complicada) que ninguem a usa de forma consistente. Compras tres livros de UML, e cada um usa uma notacao ligeiramente diferente. Alem disso, a "learning curve" do UML e' gigantesca, e se aprenderes a notacao mal precisas de voltar ao inicio.

    Isto para nao falar de que quando mostras notacao UML a certos clientes, eles teem a mesma reaccao que ao olhar para Kanji - e' chines.

    Temos que meter na cabeça que o trabalho dos engenheiros é conceber coisas, não é batucar código. Em nenhuma área da indústria se manda os operários construir um produto sem ele ser todo especificado e desenhado. Apenas na indústria de software se procede assim, que ainda se assemelha mais a uma artesania que a uma indústria.

    Nao, a razao e' que desenhar qualquer coisa que nao seja software (circuitos integrados, potes, televisoes, you name it) e' comparativelmente facil. Um objecto e' "self contained", o software nao e'. Por isso e' que software e' mais uma arte do que uma engenharia.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Re:Tem as suas coisas... (Pontos:2)
    por [Cliff] em 07-04-05 23:26 GMT (#17)
    (Utilizador Info) http://www.yimports.com/~cpinto
    Para mim, e é um caso particular, o UML é um bom acompanhamento para as especificações feitas em texto. Lê-se um bocado e olha-se para o boneco para aliviar o stress :-)

    ---
    Este espaço pode ser seu...
    Re:Tem as suas coisas... (Pontos:1)
    por daem0n1x em 08-04-05 15:45 GMT (#25)
    (Utilizador Info)

    O UML e' mais uma daquelas ferramentas que parece ser uma grande ideia, mas que depois na pratica nao funciona sempre bem (ou muito raramente).

    UML pode não ser uma ferramenta perfeita, mas é o que existe, e é melhor usá-la do que não. A perfeição não existe. Acho um exagero dizer que só funciona muito raramente, acho que se justifica na maior parte dos casos.

    O problema do UML e' que tenta ser tudo para todos, e a notacao tornou-se tao generica (e complicada) que ninguem a usa de forma consistente. Compras tres livros de UML, e cada um usa uma notacao ligeiramente diferente. Alem disso, a "learning curve" do UML e' gigantesca, e se aprenderes a notacao mal precisas de voltar ao inicio.

    Não acho que seja assim tão complicado de aprender, a linguagem é relativamente simples. Os conceitos é que são importantes. Se aprenderes C++ mal também tens que voltar ao início. Não percebo o que pretendes dizer.

    Isto para nao falar de que quando mostras notacao UML a certos clientes, eles teem a mesma reaccao que ao olhar para Kanji - e' chines.

    Assustas os clientes com UML??? UML serve para projectar e desenhar software, não é para mostrar aos clientes! Não admira que não gostes da linguagem, a fazer disparates desses!
    Quando muito mostram-se ao cliente os use-cases, meu caro, para que é que o cliente quer ver um diagrama de classes ou de interacção? Tem dó!

    Nao, a razao e' que desenhar qualquer coisa que nao seja software (circuitos integrados, potes, televisoes, you name it) e' comparativelmente facil. Um objecto e' "self contained", o software nao e'. Por isso e' que software e' mais uma arte do que uma engenharia.

    Mais uma vez, não te percebo. Porque é que o software não é self-contained? O que é que impede o software de ser produzido industrialmente? Só as mentalidades!


    Re:Tem as suas coisas... (Pontos:2)
    por leitao em 08-04-05 16:27 GMT (#26)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    UML pode não ser uma ferramenta perfeita, mas é o que existe, e é melhor usá-la do que não. A perfeição não existe. Acho um exagero dizer que só funciona muito raramente, acho que se justifica na maior parte dos casos.

    Achas ? Entao nao posso fazer mais nada do que dizer-te para o usares, se funciona para ti, bestial. Mas nao assumas que funciona para todos.

    Não acho que seja assim tão complicado de aprender, a linguagem é relativamente simples. Os conceitos é que são importantes. Se aprenderes C++ mal também tens que voltar ao início. Não percebo o que pretendes dizer.

    Achas ? Quantos diagramas e' que usas ? E' que usar Class Diagrams e' relativamente simples, mas quando tens que usar a maioria dos diagramas (sequence, collaboration, deployment, etc.) e faze-los todos interoperar entao duvido que ainda aches "simples". Mas claro que 62% do pessoal pode estar errado.

    Assustas os clientes com UML??? UML serve para projectar e desenhar software, não é para mostrar aos clientes! Não admira que não gostes da linguagem, a fazer disparates desses!

    Hammm... a maioria dos projectos nao sao uma caixa preta em que entram requisitos e sai software. Tens que interagir com o cliente, e muitas vezes com pessoal tecnico do cliente, de outras empresas etc. A nao ser que toda a gente use e compreenda UML (e mesmo assim, teem todos que interpretar e usar UML da mesma forma) entao la' vai a vantagem do "Unified".

    Quando muito mostram-se ao cliente os use-cases, meu caro, para que é que o cliente quer ver um diagrama de classes ou de interacção? Tem dó!

    Deves ter uns clientes muito esquisitos... ou muito faceis, onde e' que os arranjas ?

    Mais uma vez, não te percebo. Porque é que o software não é self-contained? O que é que impede o software de ser produzido industrialmente? Só as mentalidades!

    O que impede o software de ser produzido industrialmente sao as pessoas e a complexidade. Se fosse possivel mecanizar a construccao de software acredita que ja' tinha sido feito, e se achas que vai acontecer nos proximos 10, 15 ou 20 anos entao "put your money where your mouth is" e vamos por uma aposta no Longbets.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Re:Tem as suas coisas... (Pontos:1)
    por daem0n1x em 08-04-05 17:02 GMT (#27)
    (Utilizador Info)
    Pronto, já vi que não simpatizas com a linguagem UML? Então apresenta lá a tua alternativa. Uma linguagem ad-hoc? Então inventas a roda em cada projecto. E é incompreensível entre equipas. Ou és daqueles que defendem que não se deve documentar e o "código é a documentação"?
    Re:Tem as suas coisas... (Pontos:2)
    por leitao em 08-04-05 17:16 GMT (#28)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Pronto, já vi que não simpatizas com a linguagem UML?

    Eu simpatizo com o UML quando faz sentido o usar - como disse antes, funciona em alguns casos, noutros nao. Na minha experiencia nao funciona mais vezes do que funciona.

    Então apresenta lá a tua alternativa. Uma linguagem ad-hoc? Então inventas a roda em cada projecto.

    Sim, em muitos casos uma linguagem ad-hoc ate' pode ser a melhor. Muitas vezes, e mesmo no caso de projectos de dimensao significativa o uso de documentacao bem pensada e um ou outro diagrama "informal" (ou mesmo o uso de alguns artefactos em UML) e' a melhor forma de modelar.

    Ou és daqueles que defendem que não se deve documentar e o "código é a documentação"?

    Nao, embora pense que um sistema bem desenhado precisa de muito menos documentacao e diagramas do que um mal desenhado.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    Re:Tem as suas coisas... (Pontos:2)
    por [Cliff] em 08-04-05 20:29 GMT (#30)
    (Utilizador Info) http://www.yimports.com/~cpinto
    Desculpa estar sempre a responder mas parece que nem de propósito estamos em sintonia lol

    Nao, embora pense que um sistema bem desenhado precisa de muito menos documentacao e diagramas do que um mal desenhado.
    E é importante não descurar a documentação *no* código porque especificações e bonecada UML ajuda em alto nível mas não são raras as vezes em que o sítio mais natural para documentar uma decisão tomada é o código.

    Como uma vez me pediram (curiosamente, só vi disto aí em Inglaterra): "make 1/3 of your code green".

    ---
    Este espaço pode ser seu...
    UML durante o ciclo de desenvolvimento. (Pontos:2)
    por dmaster em 09-04-05 18:44 GMT (#33)
    (Utilizador Info)
    Chamo a atenção para as novas ferramentas de IDE (notavelmente a família de produtos Together da Borland) com os quais é possível ter as vantagens do design do UML num ambiente dinâmico entre a análise e o desenvolvimento.

    O uso destas novas ferramentas, particularmente com o suporte directo para "design patterns" com um nível de controlo bastante interessante vai ser sem dúvida um dos caminhos futuros no mundo RAD.
    Re:UML durante o ciclo de desenvolvimento. (Pontos:2)
    por [Cliff] em 10-04-05 19:17 GMT (#34)
    (Utilizador Info) http://www.yimports.com/~cpinto
    O Together é porreiríssimo mas o preço é um pouco elevado. A versão Community é paupérrima e isso leva-me a considerar outros produtos ArgoUML ou o excelente Poseidon UML para utilização em projectos OSS.

    Mas se tivesse o $$$, certamente que preferia usar o Together p/ o Eclipse.

    ---
    Este espaço pode ser seu...
    Re:Tem as suas coisas... (Pontos:2)
    por leitao em 08-04-05 17:22 GMT (#29)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Esqueci-me de uma coisa, um colega meu que trabalha todos os dias com UML (ele e' um 'design authority' na BT) tem uma anedota que exemplifica bem o problema com linguagens formais de modelacao como o UML:

    In a typical project, 60% of the elapsed time is spent thinking how to map the design onto UML, and only 40% is spent on designing.


    I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.

    "código é a documentação" (Pontos:2)
    por dmaster em 09-04-05 18:37 GMT (#32)
    (Utilizador Info)
    Quase... O Meta-Data é que é a documentação. :)
    Seminário (Pontos:1)
    por Mojo_risin em 08-04-05 23:56 GMT (#31)
    (Utilizador Info)
    Vai haver um seminário sobre Metodologias Ágeis de Desenvolvimento de Software no ISCTE, em Lisboa. Vai até haver uma introdução ao XP, por Paulo Correia.
    O programa e mais detalhes estão acessíveis em http://torga.iscte.pt/ageis/. Quem está a organizar o evento é o Prof. Dr. Manuel Menezes de Sequeira e é patrocinado pela Microsoft. Não sei se a vossa religião vos permite ir, assim sendo :P

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]