Approach to Formalizing Software Projects for Solving Design Automation and Project Management Tasks

Round 1

Reviewer 1 Report

The topic of this submission is proposal for a formalization of software projects concerning automation and project management tasks. The authors claim that proposed approach may help to automate the corresponding processes.

My problem with this submission is that, after reading it, I do not see how the various ideas presented may contribute to the realization of the declared goals.

 

The formalization mean by the authors is done using numerous formulas which can be seen at most as a specification of a type or of signature. Usually, the specifications consist of tuples of sets with very vague description. The simple formulas do not specify how the associated relations and functions are defined. Thus, their role is very restricted. The reader could equally good, or even better, grasp the concepts without presented types.

For example, there are many definitions like the following one:

“We describe the PB representation of a software project structure using the following definition:

PB = ⟨DP, FP, RP⟩,

where DP is a set of directories; 179

FP is a set of configuration files (if available) and files that contain the source code of a 180

software project; 181

RP is a set of relationships to form a hierarchy of files and directories of a software project. 182

The process of structural analysis of a software project directory is used to create the 183

PB representation of a software project structure [18].”

This definition does not help much in project automation or management.

Some definitions seem to be incorrect. For example, the following formula:

FTS(Bi, Period) → TS,

It seems to be a function type which is usually presented in the form: FTS : Bi x Period → TS. The authors may use another notation, but it should be explained.

On the other hand, the formal definitions are not used. The main part of the paper ends with subsection 4.3, where some quantitative and qualitative date is presented with no apparent relation to the introduced formulas.

 

Author Response

Thanks for your comments.

Q1: The formalization mean by the authors is done using numerous formulas which can be seen at most as a specification of a type or of signature. Usually, the specifications consist of tuples of sets with very vague description. The simple formulas do not specify how the associated relations and functions are defined. Thus, their role is very restricted. The reader could equally good, or even better, grasp the concepts without presented types.
A1: We have added more descriptions to the subsection 3.1 ‘Knowledge base model for formalizing of the experience of previous projects’.

Q2: For example, there are many definitions like the following one:
...
This definition does not help much in project automation or management.
A2: We have added some information about real life benefits of the proposed approach to the `Discussion' section.

Q3: Some definitions seem to be incorrect. For example, the following formula:
FTS(Bi, Period) → TS,
It seems to be a function type which is usually presented in the form: FTS : Bi x Period → TS. The authors may use another notation, but it should be explained.
A3: We have revised these definitions.

Q4: On the other hand, the formal definitions are not used. The main part of the paper ends with subsection 4.3, where some quantitative and qualitative date is presented with no apparent relation to the introduced formulas.
A4: We have added more clarification about using different knowledge base representations in `Results’ section.

Reviewer 2 Report

- the introduction is quite heavy to follow, with a lack of understanding of what was the motivation and background to conduct such research. The language must be more formal in order to give the possibility to readers to follow

- introduction section lacks proper references. There are just too few references that could support such work

- the authors must clearly define the research question in the introduction and in a few sentences give the scatch of their research

- the related work section looks much better than the introduction. However, the authors must describe the influence of the most important papers on their work

- material and methods section must be updated and expanded. Please add more details and please explain in detail the relation between different elements of your methodology

- results, discussion, and conclusion are the much better parts of the work. I would suggest expanding the result section with more aspects according to the proposed methodology

Overall, the paper looks very promising, but it must be rewritten in order to properly explain your idea.

The idea is excellent, the presented results are good and promising, the article structure is adequate, but please put an additional effort to improve description level and overall readability.

 

 

Author Response

Thanks for your comments.

Q1: Introduction:
- the introduction is quite heavy to follow, with a lack of understanding of what was the motivation and background to conduct such research. The language must be more formal in order to give the possibility to readers to follow.
- introduction section lacks proper references. There are just too few references that could support such work
- the authors must clearly define the research question in the introduction and in a few sentences give the scatch of their research
A1: We have improved the `Introduction' section.

Q2: the related work section looks much better than the introduction. However, the authors must describe the influence of the most important papers on their work
A2: We have described the influence of the most important papers on our work.

Q3: material and methods section must be updated and expanded. Please add more details and please explain in detail the relation between different elements of your methodology
A3: We have added more descriptions to the subsection 3.1 ‘Knowledge base model for formalizing of the experience of previous projects’.

Q4: results, discussion, and conclusion are the much better parts of the work. I would suggest expanding the result section with more aspects according to the proposed methodology
A4: We have added more clarification about using different knowledge base representations in `Results’ section.

Reviewer 3 Report

Thanks for submitting this paper to our journal. This paper targets a common and interesting problem: software projects development is not easy to estimate and manage, therefore, is it possible to refer to the prior experience in the similar projects and and collect some quantitative indicators for better understanding of the current project?

 

This paper focuses on this question and proposes a formalized model to help facilitate the management process of software development. While building the knowledge model, the authors considers the common workflow in github/gitlab to define the model attributes. During the evaluation, the authors tests the effectiveness: whether it can successfully extract these important indicators from the prior works.

 

I am fine with the design of this work. However, I am a bit concerned about the evaluation section. You are only showing that you can build your knowledge model based on prior projects. But how does the model work to benefit the ongoing project? For example, with your model, can it save the development time for the ongoing project, or can it save the monary cost? How should we measure the practical benefit of your solution in real life? I know such experiments are hard to conduct, but hopefully you can add a discussion section talking about that.

Author Response

Thanks for your comments.

Q1: I am fine with the design of this work. However, I am a bit concerned about the evaluation section. You are only showing that you can build your knowledge model based on prior projects. But how does the model work to benefit the ongoing project? For example, with your model, can it save the development time for the ongoing project, or can it save the monary cost? How should we measure the practical benefit of your solution in real life? I know such experiments are hard to conduct, but hopefully you can add a discussion section talking about that.
A1: We added some information about real life benefits of the proposed approach to the `Discussion' section.

Round 2

Reviewer 1 Report

The new submission is significantly better than the initial one. The authors removed countless signatures which did not provide any insight. The ideas are more clearly described.

Now it is clear that the authors have a particular case in mind. However, a particular case does not make science. Science is general, systematic knowledge of essential properties and causal dependences; it is not the knowledge of singular facts. 

I included more remarks in the attached PDF-file.

Comments for author File: Comments.pdf

Author Response

We are very grateful to the reviewer for his valuable and useful remarks and advice. We believe the article has become much better.

Q1: Your approach neither allows to formalize software projects nor presents a proper formalization. 
Formalization is much more. You need to construct mathematical models. Specify them in mathematical terms, and provide a function mapping the language of interest to the domain of the models. 
A2: We have added the definition of the proposed knowledge base model in the description logic notation. Also, we have moved the examples and description of the method for software project indexing to the Section 3.2 `Formalizing of the experience of previous project’ as the mapping function.

Q2: Page 3 - “You should add proper references here.”
A2: Fixed

Q3: All B_i are equal. Does it make sense?
A3: Fixed

Q4: Unclear, the same holds for the following explanations
A4: We have added the detailed explanation for each knowledge base representation.

Q5: Page 7 - “What is this figure meant for? This figure does not help much.”
A5: We have removed the Figure 3 and the Figure 4.

Q6: This formulas do not make much sense. What is B_i here? What is B dash? What do you quantify?
A6: We have simplified this definition and have added some explanations.

Q7: UC diagrams contain several other elements, not only roles and include relation. 
A7: We have added some explanations.

Q8: You should list and describe the other approaches, and explain the novelty of yours. 
A8: We have added some explanations.

Q9: What do you mean by other UML diagrams? They are plenty of them? 
A9: We have added some explanations.

Reviewer 2 Report

The updates are according to recommendations.

Except the figure 11 which is in a totally different style.

I would suggest accepting the paper in its present form.

Author Response

We are very grateful to the reviewer for his valuable and useful remarks and advice. We believe the article has become much better.

The Figure 11 was generated by the PlantUML system. We have added some explanations.

Round 3

Reviewer 1 Report

I have made remarks in the submission which should be addressed.

Comments for author File: Comments.pdf

Author Response

Dear Reviewer,

We sincerely thank you for the insightful comments and suggestions.

Please find our response to your reviews below.

Q1:
\sqsubseteq is not a description axiom but a relation called concept inclusion or class inclusion, if you like. 
Similarly for other relations. An axiom is a sentence which can be true or false. 
A ⊓ B ⊑ ⊥ is the disjoint classes axiom; 279
Well, it is a sentence which can be true or false depending on the mutual relation of classes  A and B. Do you really assume that all classes are disjoint?
At least the next is correct:
• A ⊓ B is the intersection or conjunction of ...
A1:
We have added the following explanation:
The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies.
The main component of an OWL 2 ontology is a set of axioms --- statements that say what is true in the domain \cite{ref-rudolph-2011,ref-owl2}. OWL 2 provides an extensive set of axioms, all of which extend the Axiom class in the structural specification. Axioms in OWL 2 can be declarations, axioms about classes, axioms about object or data properties, datatype definitions, keys, assertions (sometimes also called facts), and axioms about annotations.
We also have clarified the axioms list (line 282 - line 292).

Q2:
Milestone ⊑ ⊤ Issue ⊑ ⊤
Request ⊑ ⊤ Branch ⊑ ⊤
Commit ⊑ ⊤ Contributor ⊑ ⊤;
Isn't it always true? Why do you need it?
A2:
Fixed.

Q3:
hasMilestone is not a good name since the relations says that one thing is a milestone of another. Its invers would be easier to describe, i.e., by isMilestoneOf.
similarly for other relations of this kind. 
A3:
has* is the traditional name for object properties (roles) in an ontology (https://www.w3.org/TR/owl2-syntax/).

Q4:
hasDecription seems to specify the fact that a project has a description, not the description as such? Does it? 
A4:
has* is the traditional name for textual data properties (roles) in an ontology (https://www.w3.org/TR/owl2-syntax/).

Q5:
What do you mean by \sqcap  \sqcap  ? Why one \sqcap  does not suffice? 
A5:
\sqcap \sqcap is just the transfer of the definition operator to the next line

Q6:
What is the role of this equation? Is it really true? 
What do you mean by 1hasDescription.String? 
A6:
In the description logic the “<=1hasDescription.String” definition is describes the functional hasDescription property (role) with String data type.

Q7:
What do you mean by  hasCommit? 
A7:
"hasCommit" is the object property (role) for describing that a project has a commit.
The "hasBranch ◦ hasCommit ⊑ hasCommits" definition is defining the following transitive role: Project -[hasBranch]-> Branch -[hasCommit]-> Commit.