I found the paper to be a helpful combination of methodology and review, and hope to refer to it for future projects.

I enjoyed the delineation between functional vs non-functional requirements an important point. That said

I do have a number of issues with the current version of the paper.

Firstly, I found a great many typos and grammatical/phrasing errors. There are likely others, but I hope this helps:

"concrete examples of software projects from own work. "

"own work" -> "our own work"

"performed prior to through testing"

"through" -> "thorough"

"successful deployment the real time results should be evaluated" -> "successful deployment should the real time results be evaluated"

"then it will require to properly model the database schema" -> "then it will be required to properly model the database schema"

"existing already available" is redundant - just "existing" or "already available"

"which in return produce experimental data" should probably be "which in turn produce experimental data"

"enforce test trails"

"trails" -> "trials"

"reliable release was shared and tested in the scientific labs"

->

"a reliable release was shared and tested in scientific labs"

"is an own published scientific software" -> "is our own published scientific software"

"which estimates mass isotopomer distribution" -> "which estimates mass isotopomer distributions"

"For the most parts the requirement engineering and software design steps are followed until the final solution presented" ->

"For the most part, the requirement engineering and software design steps are followed until the final solution is presented"

(rather than "is presented" it might be better to say "is realized")

"It is a scientific software solution towards neurobiology and photobiology"

"towards" -> "for"

"It provides experimental data management system, circadian and diurnal rhythm generation, 3D visualization of system’s performance and experimentation details" ->

"It provides an experimental data management system, circadian and diurnal rhythm generation, and 3D visualization of system’s performance and experimentation details." (I added another and, because I assumed the 3d visualization is for both system performance and experimental details, but if I am wrong forget the additional "and" and use an Oxford comma to make it more clear: "3D visualization of system’s performance, and experimentation details"

"is a scientific software (computational) solution towards" I think you can remove "(computational)" to improve clarity and flow.

"for the experimental data entrance" -> "for experimental data entry"

" Based on filtered out the functional requirements" -> " Based on filtering out the functional requirements"

or " Based on filtered out functional requirements"

The following sentence is duplicated in two places: "It is very important to clarify with the users what will be the expected end-product because it is possible that the user may not like the output of the system after development. In this case, all the efforts will have been in vain."

Should Butterfly be added to table 1? Based on this statement "The goal for our “Butterfly” paradigm is a SDLC paradigm that fulfils all of the features regarding life cycle management of the resulting software.", presumably it should have a 'Yes' for all categories.

"If we search for “bioinformatics tools” over the web, thousands of entries can be found at one hit." - Although I can guess at what this means, it is a bit poorly worded in my opinion. Perhaps saying "If we search for “bioinformatics tools” on the web, thousands of results can be found."

Google tells me: About 865,000 results (0.42 seconds), so you could actually say hundreds of thousands (also true for Yahoo).

In Figure 4's legend, should " green the implementation and testing by the user" be " green the deployment and testing by the user"?

Figure 8 might be improved by adding arrows to illustrate the order of steps. Is it really a cyclic process?

Other thoughts:

"Finally, the backbone arrangement with a powerful middleware as well as all development elsewhere in the “Butterfly” stresses the interoperability of the software. It is developed by using well-defined and compatible output formats. Furthermore, below the middleware, well adapted, interoperable data schemes boost sustainable development of database structures, including efforts for scheme-less databases and other semantic web developments. " - Does this warrant another figure to actually depict the structure of a typical pipeline? These important points about the backbone, middleware, and data schemes don't seem to play a role in Figure 3. Is the backbone (abdomen & thorax) of the butterfly supposed to also represent middleware? If so this should be made clear in the figure.

In the section "Scientific Software Engineering and Scientific Methodology", the transition between the 2nd and 3rd (last) paragraph is confusing to me. The second paragraph is talking primarily about waiting for thorough testing to be done before deployment, while the 3rd paragraph (starting with "for instance") is talking about a very particular example of (in my opinion) database design - not testing. Perhaps

I am just unfamiliar with the "data normalization forms" and don't understand how they relate to testing. The very last sentence gives a hint at what is trying to be achieved: "Moreover, if the experimental data are well normalized, then in case of large datasets, they will expedite the processing speed and reduce time in searching and analyzing the elements"; this ties in with the previous paragraph where the author is talking about efficient solutions. In the second paragraph, the author also says "Only after successful deployment the real time results should be evaluated". I think part of the problem here is that it isn't clear in these two paragraphs if we are talking about results in terms of computational efficiency, biological/scientific validity, or both. The second paragraph seems to be more about validity, while the third paragraph is supposedly an example of the second, but seems to be talking more about computational efficiency. I would suggest either separating these two issues, or clarifying that they are both being considered simultaneously.

"Processing raw data is safe even if there are still some problems ..." I certainly don't think it should be called "safe", as who

knows what the end-result of erroneous research might be. But I believe you could say it is "not safety-critical" or "not life-critical":

https://en.wikipedia.org/wiki/Life-critical_system.

I was surprised to see UML mentioned for bioinformatics, as my understanding is that it is a bit overly complicated, possibly

for almost anyone, as well as having numerous other pitfalls (https://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html).

A note on which projects have open source (hopefully version controlled) repositories might be helpful for developers interested

in studying the technique used in more detail.

A helpful reference for any application involving significant domain-specific knowledge that the implementers do not possess

may be the jamboree approach: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2872611/

In order to prevent logical errors in the core of the system (parts implementing data-related or computation-related algorithms), strong type systems to prevent unintended errors may be useful, and it might be good to make the audience aware of such possibilities, even if they weren't

explored in the current work:

http://homepage.cs.uiowa.edu/~astump/papers/foser10.pdf

http://www.cs.bu.edu/~hwxi/academic/papers/arsec13.pdf

Perhaps it is out of the scope of the current article and too detail-oriented, but I think one of the biggest mistakes made

by most developers without formal training in software engineering (and even some with) is to not use version control (of software

and possibly data where applicable) while writing relatively scripts. This is a mistake, because in science reproducibility is always paramount.

When scheme-less databases and data formats used, particular example technologies, like JSON, should probably be mentioned to help readers.