According to this article Ivar J is tired of the moving target… that development teams are so quick to embrace new methods in search for the silver bullet. But as Ivar correctly point out there’s no silver bullet available. So now “he” (as co-founder of the SEMAT community) will create a new method for the development teams to embrace, a “standardized” process, a silver bullet.
If he succeed it will definitely be an accomplishment, but until then we will have to live with the irony.
Ok I guess I’m a bit harsh, and after reading through the comments of the article (where Mr Jacobsson comment himself) the article might be a bit over the top… but then after reading through the SEMAT webpage it still doesn’t taste like cake. It seems as a nice and pleasant idea alright but I can’t find any trace of real substance. And when reading through the limitations of the so called Kernel I can’t stop to wonder what’s left to include…
Hm and now after a couple of minutes writing about it I’m not sure if I agree to all the statements leading up to the “need” for SEMAT.
Is software engineering really “gravely hampered”? And if so is the problem really the “huge number of methods and method variants”? What do you think? For me I haven’t decided yet, if this would be a topic for a debate match I think I just as easily could play for the home as for the away team…
…when something is grey you can always make dramatic effects by turning it into something black and white.
I guess it’s not so much about incorrect methods/processes as it is how they are applied and who’s doing the work. Context and people. At least to me.
Visar inlägg med etikett engineering. Visa alla inlägg
Visar inlägg med etikett engineering. Visa alla inlägg
måndag 21 december 2009
tisdag 10 november 2009
Translative elaboration
Just opened up a new blank document to kick-off my analysis report on xtUML, even though the deadline is in December I’ve already started to see a draft in my head, in other words it is time to put it in print.
One of the more appealing differences with xtUML compared to other methods is the shift from an “elaborative” approach to a “translative” one. An issue though, for me, is that working translative on a systems engineering level is far from transparent… the technique seems much more easy to understand when discussing software engineering.
Ah, what wouldn’t I give for someone to bounce ideas with at the office today… any takers?
One of the more appealing differences with xtUML compared to other methods is the shift from an “elaborative” approach to a “translative” one. An issue though, for me, is that working translative on a systems engineering level is far from transparent… the technique seems much more easy to understand when discussing software engineering.
Ah, what wouldn’t I give for someone to bounce ideas with at the office today… any takers?
Etiketter:
elaborative,
engineering,
translative,
xtUML
Prenumerera på:
Inlägg (Atom)