discussion - should software producers be registered

huangyhg

discussion - should software producers be registered?
in reading through the posts on "staad vs ..." and other software subject posts, i would like to get your thoughts on whether a software producer of analytical engineering software should be registered, first as an engineering business in at least their state of origin, and secondly, have their software validated and signed off by a registered professional engineer (on staff).  currently state laws require that we (end users) validate the software (which most of us would do whether required by law or not!).  while i think this is still necessary, i would also like to see some obligation on the part of the producer to understand engineering, not just numerical manipulation.
blast off!!......
check out our whitepaper library.
   definetly yes, they must guarantee what they seel for sometimes a huge amount of money, and in adition, not only the software but their users too:
(quoting myself)

    "i'm sure that everyone who are confident to sign a project must have this, because in fact we deal at last with lives, money are the minor question, we must assure that a structure is stable and strong enought to support the given loads..... (think about this).
  that's why i'm allways afraid about the  general use of design/analisys softwares, they make the things seems simple for the novice and tech confident engineer, i've seem so many examples around here that i guess that the user must first get a "drivers license" to use this softwares, they can be dangerous in wrong hands, even the good ones (softwares)."
best
   fred
i think that most software providers validate their own software to a certain degree (the good ones anyway) - it is unfortunate that the likes of research engineers exist and have so many users.  i too have read the posts in the staad vs.... forum and personally would never consider buying anything from re.
whether there should be some kind of registration format for these companies is tricky - one engineer will not have all the required knowledge to test every aspect of the program so you will have to have a committee and given that these programs are sold worldwide different validation will be required for the us as opposed the uk and europe fro example.  i think the software companies would regard this as a logistical (and resourcing) nightmare and would be loathe to support it unless it was imposed upon them - and who will do that??
there is some software on the market that inspires confidence and others that do not - maybe some sort of independent task group could be formed by engineers all using different software but testing against the same examples - like the nafems benchmark tests for fe software.
nice idea but too messy to implement i think.
a
i believe that software registration is like getting onto an nfc conference team, you have to be qualified to make it.  unfortunately in the nfc you don't have to have a college degree, so the standards are declining.  i think the same thing is happening with software developers.  you look at the manuals and wonder if these people can even speak english, then you call for technical support and find out they can't!
it is my experience that most of the larger software companies have engineers on staff either in qaqc or in the actual development of the software.  moreover, those software companies that profess to work under the umbrella of the nuclear or similar stringent industry are required to keep an overwhelming amount of documentation of the qaqc processes for the base program, updates, recent add-ins... everything!
obviously this isn't for every software manufacturer as the cost would surely go through the roof for even the simplest of design aids.  however, there might exist some middle ground or level certification that, at a minimum would provide or boost the desired user satisfaction/user confidence.  and i'm all for that!
like rookies vs. pros, another thing to consider:
how many of your college professors were licensed/registered professional engineers.  it's a sad state of affairs when the ones who do the teaching cannot even pass the examinations.  in addition, asce is pushing for a master's degree before licensing so that we can spend even more time with these clowns.
bengineer...good point.  some states now require engineering professors to be registered professional engineers.  i think it should be a minimum requirement.
q..i agree.  one problem though, is that many single practicing engineers don't get peer interaction and cannot afford to validate to the extent that those of us who have been in larger companies have been able to do.  currently, anyone with a bit of programming savvy can produce software, without any validation other than end use.  my guess is that this is what got re where it is today.
ron,
i think that it is proper and correct that the software written for a structural engineer be developed with either the full effort of, or participation/oversight of, a licensed engineer.  it only makes sense.  that said, i'm not sure it is appropriate for said licensed engineer to certify, seal, warrant, etc. the code.  he isn't "practicing" engineering, but simply producing a tool to assist other engineers in their practice.  
an engineer friend of mine was hired to review/qc a program that analyzes and designs bridge piers for a major software company.  she worked through numerous problems and reviewed some of the code structure and provided feedback to the programers.  however, she can't, and shouldn't, warrant that she caught every bug.  their purpose was not to certify their product, just improve it.
i think that the software companies face a similar insurance challenge that we engineers face.  namely, that we can only certify what we produce.  my structural designs can be "mis-used" by others in that my plans could be replicated for use on another site without my knowlege, or some rebar be left out of a concrete beam.  i can't be held liable for this and our insurance companies provide a lot of guidance on what is and is not good practice in terms of avoiding liability.  the software vendors product can also be mis-used...probably even worse than what we experience.
software vendors today, many times, emphasize that their programs are "written by and for engineers".  i would expect that many are already using engineers.   if they were required to "seal" their product, i'm sure they would still use a lot of boiler-plate language that would limit their responsibility as they do today.  
i am also concerned about the problem, and agree with what has been written above.  the points made by arniec are particularly relevant to those of us outside the us.  most of the structural software companies i know or have dealt with certainly do have experienced professional engineers on their staff.  this does not necessarily produce faultless software,  particularly when most software is in a state of continuous development.
the best engineering software companies should have
1) professional engineers writing or at least testing the software before release.
2) solid up-to-date references of clients using the latest version of their software.
3) rapid response to user problems, to fix bugs as soon as they are discovered.
4) user manuals that are understandable to ordinary mortals (engineers) and which provide enough background explanation that an engineer who has never done matrix inversions can still understand what they are doing with the software.
5) perhaps an external engineering auditor to check their work.
i doubt that any system of registration of software vendors can be made to stick, internationally.
as engineering users, perhaps the best we can do is to insist on criteria like those above, and additionally, always do broad-based spot checks on any analysis that is done.  for example, check that variation in stress and deflection can be explained by load variation across a structure, check overall stability, check that signs +/- of end reactions make sense, check member sizes and orientations make sense, and for any major structural   
the problem many software companies face is providing could quality and experienced support. some companies achieve it by employing engineers in support roles. i know of one company that will when told of a problem with the software go to the trouble of obtaining your data and verifying that the data as input is correct and that the job is setup right. they usually do this via email and normally within 24 hours.
what does this do? it gives the software company a chance to provide good support and improve customer relations. from the customers point of view they learn what they may have done wrong and are advised how to avoid the problem again.
remember just because software doesn't work the way you do doesn't mean that it can't do what you want, it may just have another way of doing it.
sc