|
Hi, I work for an integration company where we often attempt R&D-type projects requiring quite high sensing and algorithmic requirements. For these projects we've generally used Visual Basic .NET to create software which interfaces with our sensing technology and then analyses the data to create a meaningful result which is then sent to a robot etc. Since we're engineers and not an programmers, the development of this software has been quite ad-hoc which can lead to some very messy code. What I'd like to do is try to implement a software engineering policy which would outline the stages our software development has to go through (requirements planning, design etc) and what is required of each stage. I'd also like to include a best-practice coding guideline as part of this to ensure neat, efficient, readable code. I know this is quite common-practice for IT companies but I'm wondering if anyone's tried/had success with this in engineering companies such as ours, where our focus isn't really IT but software programming has become a part of what we do. I'm also wondering whether there are any official standards that anyone knows of that I should be using as a guideline for our industry? Also, I'm wondering whether Visual Basic .NET is the best language we should be going with. The reason we use it is because it's what the guys here have the most experience with (although it is limited) and it's quite easy to learn and use. I've looked at a number of alternatives and the main conclusion I keep coming to is that going with what you know is going to be the best bet. The only other clear alternative I've come across is LabView which I'd like to investigate due to its reputations for working very well with instrumentation. Sorry for the wall of text. Does anyone have any input by any chance? |
|
If you really want your software to rise above the 'hobby-bob' level, you will have to embrace 'software' and 'IT' as part of your business. It's actually a strategic choice that you as a company have to make. If you decide to do so then you'll have to build, what we call, 'a software factory'. This software factory is set of tools, templates, standard software architecture, instructions etc. that you'll need to produce applications. It will take quite some serious effort, a clear vision on what to achieve and money (ofcourse). It took us 'bout €50.000 and almost a year for a team of 5-6 software engineers. And like a real factory/production line you'll have maintenance to: to adapt it to new technologies, to expand it with new tools: 20% of our IT engineering effort is reserved for that kind of stuff. To give you an idea what our software factory is made of: Tooling: - Enterprise Architect (UML modelling and code generation) - Visual Studio .NET (code writing) - Mantis (dealing with changerequests) - NUnit, NCover (automated code testing) - SubVersion (code archiving and version management) Templates: - requirements document - technical/interface design document - FAT and SAT document - application maintenance and management agreement document Instructions:
... and probably some more. The CSIA supported V-model does give you an idea on what has to be covered. Note that building a (good) .NET solution will claim 80% of your engineers skills only to have them work with the development platform, leaving 20% to concentrate on the actual functionality. This is contrary to the PLC platform where you can use 80% of your skills to solve the actual functional problem and only need 20% to deal with the development platform. It just takes a lot more effort to build a reliable .NET solution then it takes to build a reliable PLC solution. You might consider an inbetween solution: IPC (embedded PLC) or LabVIEW ? (ah... you did) So... in short: proper .NET development doesn't come easy ... or cheap. HJ |
