Meu post sobre Análise de Sistemas já teve 65 comentários (incluindo respostas, é claro). Acho que já descartei uns 20 comentários anônimos para este. Nem todos falavam da minha mãe, alguns tinham coisas interessantes mas infelizmente este blog não aprova comentários anônimos, sejam criticas interessantes ou xingamentos.
Esta manhã eu recebi um destes anônimos interessantes e, apesar de não o aprovar, gostaria de comentar trecho deste:
Francamente modelar com o código é o mesmo que fazer um projeto de uma casa com tijolo e cimento.
Este trecho me despertou o interesse porque há algum tempo fiz um experimento e gostaria de convidar vocês para repeti-lo. Como falei em posts anteriores Melbourne, minha cidade atual, é um lugar razoavelmente conhecido por suas boas universidades e centros de pesquisa. Como conheço alguns estudantes de graduação ou recém-formados (A ThoughtWorks possui um programa para contratar graduandos) eu conheci algumas pessoas que lecionam em universidade locais, entre eles uma simpática senhora que ensina disciplinas num curso de arquitetura e edificações local.
O dialogo foi sobre especificações, plantas e modelos.
- Imagine que a senhora pudesse, ao invés de criar um modelo em papel, construir seu projeto incrementalmente. Em dois dias a senhora tem o banheiro pronto, em três dias a varanda.
- Como numa maquete?
- Não, eles estão prontos mesmo. Você pode usar o banheiro, pode dormir no quarto, pode efetivamente utilizar o prédio.
- Mas e se eu precisar mudar algo? Isso iria ficar muito caro.
- Imagine que o custo é apenas o de dois dias de trabalho. Sem custo material. A cada dois dias você termina um pedaço da casa e mudar é tão simples quanto construir.
- Ok. Seria ótimo. Qual seu ponto?
- Isso ainda afaria requerer uma planta baixa, um modelo em papel ou AutoCAD?
- Precisaria porque eu preciso comunicar o projeto aos trabalhadores.
- Ah, sim, claro, mas imagina que construir não seja um trabalho braçal. Você tem, sei lá, robôs que sobem paredes e fazem o trabalho pesado, você só diz qual a dimensão, inclinação, que material, etc. e eles constroem. Você desenha no AutoCAD e os Robôs constroem imediatamente, daí você pode entrar no prédio e se tem algo errado em segundos você conserta. Você pode levar seu cliente para andar no prédio.
- Ok. Mas neste caso você não está eliminando o modelo gráfico.
- Não?
- Não, neste caso você automatizou a construção. O que você fez foi fazer com que o trabalho do arquiteto seja simplificado eliminando o custo da construção. Se qualquer coisa que eu mudar no modelo muda no prédio real imediatamente e sem custo o papel do modelo é ainda mais importante. Você não tem real diferença entre modelo e prédio. Você não tem transformação real entre um e outro. O modelo é o prédio.
Deste ponto eu comecei a explicar para ela como engenharia de software funciona. A conclusão que nós chegamos é que engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos e ainda assim usam as ferramentas de quem não tem este poder.
Arquitetos adorariam modelar com tijolos, paredes e coisas reais. Eles não podem. Nós podemos.
Dois pontos:
- “Sem custo material.”
Desenvolver software não possuir custo material como na construção civil mas por outro lado o custo de um pedreiro é muito menor do que o custo de um desenvolvedor. Ela te respondeu sem pensar nesse ponto.
- “…mudar é tão simples quanto construir.”
É simples mas pode ser caro.
Acredito no Manifesto Ágil e nos processos que o utilizam como base e acredito que o tempo e custo de um projeto será bem menor utilizando esses métodos mas o que não pode parecer - e sei que não foi sua vontade desse post - é que o cliente poderá ficar mudando de idéia o tempo todo em um projeto e isso não lhe custará $$$$$
Joel,
Há algumas décadas que quem faz a construção do software, do modelo entendível ao programador para o modelo executável, é um compilador ou interpretador. Esté é o trabalho que não tem custo (se você descontar energia elétrica, claro). No mais, na Australia um pedreiro ganha por hora um valor muito próximo, senão maior, que um programador médio.
Ao programador, como o engenheiro ou arquiteto, cabe criar o modelo que será transformado num executáel. o programador -geralmente- não entende de bits e bytes na arquitetura do processador X, o processador X não tem idéia do que aqueles bits e bytes singificam mas executa ordens sem pensar.
O que falei neste post não tem nada a ver com metdologia de desenvolvimento. Você pode ter modelos em papel sendo criados para depois serem ‘implementados” por code monkeys em metodologias ágeis, waterfall ou o que for. Este post fala diretamente sobre desenvolvimento, sobre converter um modelo lógico em físico -e sobre a completa futilidade desta.
[]s
“engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos e ainda assim usam as ferramentas de quem não tem este poder”
Entra pra eternidade
Bem, achei que o post tentou ser didático mais não conseguiu. Não dá para comprar a construção de software com a construção civil. Por isso, não faz sentido dizer que “engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos” porque não existe poder equivalente para os dois papéis. O custo da construção civil é alto e a falta de um modelo significa aumentar ainda mais esse custo. Na engenharia de software o custo é diferente porque tudo é intelectual.
Outro ponto que achei equivocado é dizer que a compilação é equivalente a construção propriamente dita. A construção do software é a escrita de código. É o que leva tempo, é o que aloca recursos, etc. Também não dá para dizer para alguém que existem “robores automáticos” fazendo um certo trabalho como uma forma de simplificar a explicação. A consistência entre o que é codificado e o resultado final é tão grande que a compilação é muito abstrata dentro do contexto de software para ser comparada com outras engenharias.
Hildeberto,
O ponto de que construção civil não pode ser comparada com construção de software ée xatamente a essência do post. Como eu disse no mesmo, se um engenheiro civil pudesse transformar um modelo (planta ou equivalente) em algo concreto (prédio) eles o fariam sorrindo. Nós podemos transformar nossos modelos (abstrações na forma de objetos, funções, etc.) em algo concreto (código executável) mas ainda assim preferimos seguir o caminho dos que não possuem esta possibilidade. No diálogo acima o que eu fiz foi exatamente perguntar a um arquiteto o que aconteceria se o custo da engenharia civil fosse apenas “intelectual”. Repare no trecho:
Quanto à construção, em ambas as disciplinas temos transformações de modelos. Engenharia civil (ou qualquer outra) vai gerar um modelo lóico que é transformado em um modelo físico (uma casa, um navio, etc.). Este trabalho é feito por um rupo de pessoas que sabe interpretar o modelo lógico e gerar o modelo físico.
A transformação de modelo lógico para físico em engenharia de software é feita por um compilador, algo que pega um modelo de alto nível (seja em Java, UML utilizando MDA ou o que for) e transforma em algo físico, código. Se você considerar código como construção vai assumir que o código é apenas um derivado de um modelo anterior, assim como uma casa é um derivado de um modelo expresso em uma planta. Eu, então, perguntaria: que modelo anterior é esse? Como eu afirmei no artigo que precede este, usando tecnologias atuais e considerando modelos comuns em aplicações comerciais não existe motivo para alguém ter um modelo que não seja expresso em código.
Resumindo o artigo não tenta equivaler as duas discilinas, pelo contrário. Ele fala exatamente que nós, engenheiros de software, temos algo que nos diferencia das outras engenharias. Se os outros engenheiros tivessem esta possibilidade eles não usariam (ou pelo menos repensariam) coisas como transormação manual de modelos, plantas e etc.
[]s
[]s
@Hildeberto Mendonça
Por isso, não faz sentido dizer que “engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos” porque não existe poder equivalente para os dois papéis.
Mas é justamente isso, engenharia de software tem poderes que as demais engenharias não possuem. (e vice-versa). O questionamento do Shoes está claro, se engenheiros de software tem esse diferencial por que alguns (a maioria ?) insistem em não usá-lo?
@Hildeberto Mendonça
A construção do software é a escrita de código.
Puts, se desenvolver software é só isso, então, por que eu perdi tempo estudando ? O cursinho de datilografia que fiz quando adolescente me tornaria um programador.
Colocando minha opinião agora.
Eu acho que isso é uma questão cultural. Nem tanto pelo fato de engenheiros de software se basear em técnicas das demais engenharias.
Me parece que engenheiros são vistos como donos da verdade. Eles definem, eles mandam, eles controlam. Os técnicos obedecem e apenas executam o que foi especificado.
Digo isso me baseando muito nas conversas que tenho com meu irmão, que é técnico mecânico. Na empresa onde ele trabalha os engenheiros ficam há 800km das máquinas, equipes pelas quais “são responsáveis”.
O que acontece, os engenheiros nem fazem idéia dos problemas que a área técnica resolve e eles que levam todo o crédito. (e muitas vezes esses créditos são créditos $$$$ mesmo).
Bem, voltando na questão cultural. Como engenheiros são os donos da verdade eles não podem sujar as mãos com código fonte, por isso adotam formas de modelagem mais limpas (UML?) e deixam o trabalho sujo com os datilografos.
É claro, toda generalização é burra. Não estou dizendo que todos engenheiros são assim, ainda há esperança.
Oi Phillip
Cara, eu tenho um pensamento bastante parecido mas, tentando subverter a mim mesmo, tentei sair de mim para observar as necessidades de documentação, digo, quando é necessário haver documentação.
Recentemente entrei para trabalhar em uma seguradora aqui no Rio, que tem o ambiente já conhecido por você, não serei prolixo. A rotatividade dentro da equipe é enorme, as pessoas conseguem outra proposta e saem no meio do projeto e continuam neste ciclo eternamente (só para você entender o perfil da equipe). As regras de negócio são até certo ponto complexas, a integração com o legado é problemática (tem gente até usando Visual Age para gerar código de integração com programas Cobol) e o conhecimento prévio, adquirido em outros momentos de evolução do software não existe, é perdido.
Tudo posto, é válido ressaltar que há um empenho em manter a documentação macro do sistema sempre atualizada. Há maneiras mais eficazes mas, reconhecidamente até por eles, é complicado modificar a cultura, conseguir vender idéias mais ágeis enquanto processo. Quando entrei para assumir um novo projeto, recebi alguns documentos (atas de reunião, casos de uso, requisito, etc) para tentar absover um pouco do que É e o que deve ser este novo sistema. Foi aí que me perguntei: E se não tivesse documento algum?
O código não me fala nada, é implementado sem o mínimo de qualidade e, ainda, não possui sequer um teste, algo típico daquelas grandes consultorias e fábricas de software com milhões de selos. Isso tudo é sabido por eles, ninguém é tão inocente. Eles seguem o caminho inverso, investindo em documentação macro do sistema e deixam a implementação ser feita quase de qualquer jeito, rapidamente (seguindo a arquitetura padrão do cliente).
O cliente não quer mudar pois “funciona” como está sendo feito. Ele não se importa no dinheiro que se perde ou mesmo se existe uma forma de economizar algo. Eles tem demais e não faz diferença, tendo em vista que o retorno está sendo obtido, vender seguros, ponto. Ele é feliz com seus documentos.
Quem vai convencê-los do contrário? A consultoria vai perder o cliente? Não, não vai. Mudanças internas, enquanto líder, são permitidas. Você pode guiar da forma que quiser (ou quase) seu projeto, eu tenho liberdade. É só não falar nomes novos, leia-se práticas do Lean e do Scrum e, ainda sim, gerando os artefatos que o cliente espera, os tais documentos.
Daqui há três semanas haverá a primeira entrega (pois há um período de levantamento de casos de uso, etc, enfadonha e só podeis desenvolvimento), e meu empenho será, paulatinamente, ir mostrando como as coisas podem ser mais rápidas, tanto em refactoring simples ou evoluções, até entregas em curto prazo.
Simplesmente o post é sensacional. Sintetiza a essência das discussões sobre paradigmas no desenvolvimento de software, de construção de sistemas. Isso ficou evidente com a qualidade dos comentários (e da discussão sadia que se iniciou). Acredito que podemos aproveitar um pouco dos dois mundos, daquilo que aprendemos com as engenharias anteriores, e daquilo que ficou conhecido como Manifesto Ágil. Acredito que desenvolvimento de software não pode ser facilmente comparado com engenharia civil por exemplo, apesar de ter suas semelhanças. Eu pertenço à uma geração que já nasceu conhecendo o Manifesto Ágil, mas que por questões de cultura e mercado continua usando de metodologias conservadoras (gosto de chamar de ortodoxas, por preferirem seguir à risca o que dizem os livros à tentar adaptar para a realidade vivada em nosso ofício). Parabéns pelo post!
“Arquitetos adorariam modelar com tijolos, paredes e coisas reais. Eles não podem. Nós podemos.” - A frase resume perfeitamente o artigo.
Modelar (pesar em uma solução) usando diretamente o código, tem vantagens bem defendidas aqui, e não tenho a pretensão de descordar.
No entanto, gostaria de defender que uma modelagem gráfica, em alguns momentos (pesar em uma solução com quadro branco, sem formalismo, por exemplo), pode contribuir, não apenas na comunicação, mas também na elaboração de alternativas mais rapidamente.
“No tempo que levaria criando o código para um design, você pode comparar três designs usando imagens” - Kent Beck, em Extreme Programming Explained
Acredito que seja perfeitamente possível viver sem uma modelagem gráfica atualmente - usando apenas para comunicação (gerar diagramas UML depois de codificar, por exemplo), mas ela ainda pode ser uma ferramenta útil para “pensar”, abstraindo o formalismo do código.
@fagner
Seu psot descreve a consequencia, creio. O codigo nao fala nada, logo precisamos de documentacao. Ora, precisamos de documentacao ou precisamos melhorar o codigo?
Eh muito dificil mexer em empresas com este tipo de pensamento, ‘ se nao esta quebrado nao conserte’. Como consultor eu sei que em alguns cenarios eh quase impossivel, o melhor eh chegar na empresa, fazer seu trabalho e sair sem tentar mudar muito de sopetao.
Trabalhando dentro destas empresas (ou sendo chamado para fazer um trabalho real de mudanca de paradigma e nao apenas implementar um sistema X). A coisa eh um pouco diferente. O mundo esta cheio de casos enormes de empresas que nao mudaram coisas ” que nao funcionam mas funcionam” e acabaram em posicoes horriveis por causa disso. Um bom exemplo recente eh a General Motors.
[]s
@Gustavo
Como falamos outro dia no GUJ, notacoes graficas nao executavies (i.e. UML) sao otimas como meio de comunicacao mas elas nao sao *O* modelo (ainda?). Beck, por exemplo, sugere spikes quando se deseja implementar este tipo de coisa.
Voce nao precisa viver sem modelos graficos, basta ter em mente que eles nao sao *O* modelo, sao apenas uma fotografia, rasunho ou descricao dele.
[]s
“Arquitetos adorariam modelar com tijolos, paredes e coisas reais. Eles não podem. Nós podemos.”
[[
mesmo podendo, quase nunca "ousamos".
]]
[...] as coisas assim. [Atualização: Além do post do Chapiewski sobre os problemas dessa analogia tem esse bem recente do Phillip Calçado]. Analogias alternativas como “Jardinagem”, [...]
Hum… o que vocês chamam de ‘modelo’?
Pra ser um modelo precisa detalhar, ou só ter o desenho macro (que dá uma idéia geral da estrutura, sem entrar nos detalhezinhos de implementação) já pode ser considerado um modelo?
E se for assim, ele continua sendo inútil, ou poderia servir de guia, para ‘conduzir’ os desenvolvedores e manter uma arquitetura coerente?
Qual o real problema aqui, os modelos ou as torres de marfim?
Tesuo,
Desenvolver software eh modelar um problema. O modelo eh a representacao deste. Em software orientado a objetos provavelmente voce vai ter um modelo de objetos que possivelmente vai ser um domainm model. A discussao do post eh se o modelo eh aquilo expresso em diagramas e outros artefatos nao-executaveis ou em codigo.
[]s
@Tetsuo
Hum… o que vocês chamam de ‘modelo’?
Modelo é a representação de uma determinada realidade através de uma notação. (pode ser uma equação matemática por exemplo).
Em nosso caso é uma linguaguem que pode ser UML, Java, C#, etc.
Agora, execute a UML para nós.
O máximo que você conseguirá é transformar essa notação para outra UML –> Java por exemplo. Agora sim você consegue executar.
A questão é: Por que perdemos tempo criando um modelo UML que não irá servir para nada?
É muito mais fluente criar o modelo usando a notação Java, afinal ela é uma linguaguem de Alto Nível na qual consigo expressar tudo o que é preciso e o melhor de tudo é executável, verificável, etc.
Não sou contra o uso da UML, pelo contrário, incentivo o uso adequado da mesma.
em resumo péssimo exemplo… e confuso também…
[...] 5 leitores devem ler o blog do Shoes, mas se alguém não o acompanha, vá nesse link e veja os argumentos definitivos nessa história toda sobre código e modelagem em [...]
“Não sou contra o uso da UML, pelo contrário, incentivo o uso adequado da mesma.”
Hum… mas qual o uso adequado da mesma?
Bem, eu ainda vejo bastante utilidade em modelos em diagramas, observando obviamente que eles servem principalmente para transmitir ‘princípios’ (modelos de nível bem alto) e idéias dificilmente expressas em código, e que programar por diagramas é estúp.. inviável. Não acho que testes unitários sejam documentação (como já ouvi muita gente dizer). BDD talvez, mas mais para funcionalidades, não para design. É muito mais fácil enxergar ‘o todo’ em um diagrama (bem feito) do que em mil linhas de código :)
Oi, Tetsuo,
Behaviour-Driven Development geralmente é utilizado para criar testes unitários, acho que você estava se referindo à TDD.
Se você prefere ver um sistema em diagramas basta fazer engenharia reversa utilizando sua ferramenta UML favorita. O que não há motivo para e ter o design do sistema como coisa separada da implementação, em qualquer linguagem moderna o design é a implementação (ou vice-versa).
Quando você fala “transmitir princípios” eu entendo “ferramenta de comunicação”, e é exatamente isso que este post e o seu antecessor falam da UML.
Tetsou,
A UML deve ser usada para alinhar o conhecimento da equipe acerca do que está sendo desenvolvido.
Quando eu preciso falar para outro programador como eu imagino o modelo de algo eu falo usando UML. ( No quadro branco de preferência).
Realmente, diagramas transmitem informação de forma eficaz, mas isso não quer dizer que primeiro vou modelar todo o sistema usando UML e depois codificar.
Resumindo, use UML mas programe (modele) em Java, C#, Ruby, etc.
Er… o que eu quis dizer foi que não acho que testes unitários no estilo xUnit possam ser usados como documentação (como eu já ouvi pessoas dizerem), mas testes no estilo BDD (given…when…then) talvez possam para alguns casos, já que unem uma descrição negocial com o teste da funcionalidade em código.
Mas putz, foi mal. Eu acabei pulando alguns comentários sem querer, e perdi a parte que você fala do uso da UML. A minha confusão foi que o que você está chamando de modelo não é o que eu estou chamando de modelo. :)
Bem, eu continuo a favor da criação e manutenção de uma modelagem essencial, que descreve o design como um todo, sem entrar em detalhes - o que facilita a comunicação e o entendimento do design -, e completamente contra ‘programação’ (detalhamento demasiado da implementação) em UML - o que daí sim, é um esforço redundante e pouquíssimo útil.
[]s
@Danilo
Concordo, mas modelar não é usar Waterfall :)
Profundo.
@philip
“Behaviour-Driven Development geralmente é utilizado para criar testes unitários, acho que você estava se referindo à TDD.”
Não se refere apenas a testes unitários não, ele também abrange o tema “eficiência na comunicação entre envolvidos”, entre outros, através de stories geradas a partir dos “testes”. sim, não são só testes unitários, enquanto conceito do TDD, são estórias, especificações..
Blog do Dan North (Jbehave) e do Dave Astels (rspecs), criadores:
http://dannorth.net
http://daveasltes.com
* Citei stories porque está dentro do tema do post: documentação, esta que é obtida sem esforço, com bdd.
Fagner,
Não entendi seu comentário. “Geralmente” é diferente de “somente”, eu estava explicando que dizer que “usar testes unitarios é pior que BDD” não faz muito sentido.
Eu conheço o trabalho do Dan North há algum tempo, inclusive o RSpec é algo bem citado neste blog (não gosto do JBehave mas o JBehave 2, em desenvolvimento, promete).
Acho que você está usando o termo “story” por causa do StoryRunner do RSpec mas é bom deixar claro que não necessariamente são equivalentes com User Stories (você não precisa de um para usar o outro, por exemplo). Ainda assim, você não precisa do StoryRunner para usar BDD, o RSpec puro já te dá esta possibilidade de maneira bem simples com describes e its.
É, eu sei que você já conhece há tempos, claro, já li várias coisas e vários debates sobre o tema onde você estava presente.. De qualquer forma, eu li “somente”.. rs.. Po, embora se você tem um teste unitário e segue os conceitos do BDD, não necessariamente utilizando algum framework como RSpec ou do JBehave, você tem consequentemente uma story fresquinha, se seguir a metodologia BDD, você tem sim. A não ser que QUEIRA não atingir o objetivo. .rs
Então, mas eu citei story me referindo a user stories mesmo, não pela ilusão dos nomes., tal qual a métrica sugerida por ele, como modelo, se apresenta: given, when, then.. Embora ele mesmo afirma que isto não é uma máxima você adapta se quiser (tu acha que ele iria amarrar o conceito? rs)
abs :-)
Genial Shoes!
Sou engenheiro e programador por hobby. As coisas que você escreve deviam ser colocadas em um livro.
Parabéns.
Jóai!!!
Vamos usar mais esse poder que temos nas mãos e deixar as velhas ferramentas um pouco mais de lado!!!
Só depende de nós!!! =)
É Phillip, com certeza, se pudessemos modelar nossos croquis em coisas concretas e reais a arquitetura seria ainda mais inovadora.
E o pior de tudo na arquitetura é fazer com que o cliente entenda o projeto, principalmente dimensões, muitas pessoas não conseguem, há não ser por meio de maquetes físicas, entender como funcionará sua casa.
Mais ao contrário do que você colocou:
“Ao programador, como o engenheiro ou arquiteto, cabe criar o modelo que será transformado num executáel. o programador -geralmente- não entende de bits e bytes na arquitetura do processador X, o processador X não tem idéia do que aqueles bits e bytes singificam mas executa ordens sem pensar.”
No caso do arquiteto, ao contrário do programador, não cabe apenas criar o modelo… temos que criar o modelo, desenhar com o máximo de detalhes possiveis (para isso temos que conhecer o material, a execução e o acabamento), passar as informações para quem irá executá-lo, e muitas vezes ensinar como se executa…
Acho isso incrivel, programadores conseguem fazer o projeto, executar, corrigir, obter o resultado final desejado e entrega-lo.
Na arquitetura, muitas vezes, quando o erro é descoberto é tarde de mais e o cliente sempre acha que o resultado final ia ser diferente (as vezes até o próprio arquiteto acha isso também)…
Com certeza gostariamos de ter esse poder que vocês tem.
Parabéns pelo texto :)
Abraços
@Tiago Albineli Motta i++;
[...] basta a desvalorização e os péssimos salários pagos aos desenvolvedores, e agora me vêm com analistas de sistemas retrógrados (oops!, pareço redundante) ? Por favor, me perdoem, mas as vezes acho que o mercado local está [...]
Caros,
O fato é que não há na “engenharia” de software a prova científica. Não conheço uma base estatística confiável de projetos de diversos níveis de complexidade (e este ponto é por si muito aberto) realizados por equipes independentes e tecnicamente equivalentes cujos resultados possam ser comparados em termos de $$$. Sem isto, o resto são teses e preferências pessoais.
Obviamente muitos dirão que na falta de tal base estatística deste tipo, o desenvolvimento de software já tem histórico suficiente para nos oferecer uma série de lições aprendidas, o que reforça algumas teses em algumas situações, mas o fato é que não temos a verdade absoluta para todos os casos. Há situações em que modelos de papel são essenciais pois simplesmente não há margem pra erros no código (pois os prejuízos seriam muito grandes) e há outros sistemas em que ir direto aos tijolos é a melhor abordagem.
O fato é que ninguém sabe com certeza em que situações cada abordagem é a melhor.
Paulo Crestani
Paulo,
Qual o problema dos dados dos CHAOS Report e das dezenas de pesquisas disponíveis por institutos de pesquisa e entidade como ACM?
[...] não seres humanos. Arquitetos não podem se dar ao luxo de construir o prédio errado (bem que gostariam de poder fazer isso), por isso precisam investir bastante tempo nas especificações para ter certeza de que tudo vai [...]
[...] reais necessidades. Sei que o post já está cheio de links, mas este post do Phillip Calçado, Analista Pedreiro, resume bem o que quero [...]
Phillip,
segue um comentário retardatário, mas acho que essa discussão ainda vai longe. Eu procurei referências sobre modelos e as encontrei em um livro de filosofia. No primeiro momento eu não considerei código-fonte como modelo do sistema, depois, trocando idéias com um visitante do meu blog acabei mudando de idéia, mas a questão ainda é a utilidade desse modelo para a análise.
Aí vai: http://www.kerber.com.br/portugues/?p=194
Abraço,
Kerber
Um comentário atrasado.
Na minha visão engenharia civil e engenharia de software têm muito em comum. O problema é que devemos usar engenharia quando precisamos da mesma, sendo mais claro, não é preciso um engenheiro para construir uma casinha de cachorro, mas, com certeza precisamos de um engenheiro se formos construir um edifício de 30 andares.
Precisamos de muita, muita engenharia mesmo na área de software, pois é muito fácil detonar recursos nesta área. A produtividade das pessoas varia muito - até 1000 %.
Fala rapaz. dá para vc escrever um livro com este blog..muito legal!
[...] Voltando ao assunto PLS607/07, que eu comentei uns parágrafos acima, eu gostaria de deixar bem claro, sou totalmente CONTRA essa lei. Para quem não sabe, esta lei dispõe sobre a regulamentação das profissões de analista de sistemas e programador. Ela diz que apenas pessoas com formação em Analise de Sistemas poderão exercer a profissão de analista de sistemas, uma profissão que por sinal está deixando de existir. Existem artigos muito bons na internet tratando sobre a profissão como podem ler aqui e aqui. [...]