Many sciences have good explanations of their research strategies. These explanations include not only detailed guidance for researchers but also simplified views for the public and other observers. Acceptance of their results relies on the process of obtaining the results as well as analysis of the results themselves. Schoolchildren learn the experimental model of physics: hypothesis, controlled experiment, analysis, and possible refutation. The public understands large-scale double-blind medical studies well enough to discuss the risks of experimental treatment, the ethics of withholding promising treatment from the control group, and the conflicts of interest that are addressed by the blinding process.
Software engineering does not have this sort of well-understood guidance. Software engineering researchers rarely write explicitly about their paradigms of research and their standards for judging quality of results. A number of attempts to characterize software engineering research have contributed elements of the answer, but they do not yet paint a comprehensive picture. In 1980, I  examined the relation of engineering disciplines to their underlying craft and technology and laid out expectations for an engineering discipline for software. In 1984-5, Redwine, Riddle, and others [5,6] proposed a model for the way software engineering technology evolves from research ideas to widespread practice. More recently, software engineering researchers International Journal of Software Tools for Technology Transfer, 2002, vol. 4, no. 1, pp. 1-7. have criticized common practice in the field for failing to collect, analyze, and report experimental measurements in research reports [9,10,11,12]. In 2001 I  presented preliminary sketches of some of the successful paradigms for software engineering research, drawing heavily on examples from software architecture.
Scientific and engineering research fields can be characterized by identifying what they value:
The most common research strategy in software engineering solves some aspect of a software development problem by producing a new procedure or technique and validating it by analysis or by discussing an example of its use; examples of use in actual practice are more compelling than examples of use on idealized problems.
Another common research strategy provides a way to analyze some aspect of software development by developing an analytic, often formal, model and validating it through formal analysis or experience with its use.