One of the tensions that I have seen in teaching software engineering is whether something should be viewed as legitimate research or part of the craft of computer engineering.
It's a slippery slope that I myself didn't have a good articulation for.
I came across this in a newsgroup which I think is a pretty good description. The writer is referring to Researching Information Systems and Computing:
"According to the author, the major differences are that in the typical software industry is that the less that is learnt or the less that needs to be discovered the more successful the project is deemed to be. If all is going according to plan then using existing knowledge, avoiding backtracking and changing of design or avoiding having to redo analysis would be seen as a part success. Having to change your design, backtracking and redoing analysis are perceived as a negative risk which needs to be mitigated. These risks could overrun the project constraints such as time, budget etc. Therefore industrial practitioners often leave out risky or uncertain parts of a project.
A researcher on the other hand focuses on these risky and uncertain items because tackling these risks and uncertainties successfully would lead to new knowledge being created. Hence you can claim to be doing research rather than 'normal' design and creation through the risk taking of your software product or process. You can further claim justification for your design by using theoretical underpinnings such as mathematical formulas and or formal methods from the field. You should also be able to say how the knowledge aquired from your design can be applied generally to other situations.