ddiruscio/logseq
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto saved by Logseq

Browse Source
This commit is contained in:
Davide Di Ruscio
2025-06-02 17:15:13 +02:00
commit d9ea3d552d
6279 changed files with 711145 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pages/SCICO-D-24-00161.md
+111
View File
@@ -0,0 +1,111 @@
type:: [[REVIEWS]]
tags::
year:: 2024
venue:: [[SCP]]
full-title:: A Conceptual Review of the Relationship between ISO/IEC/IEEE 42010 and ISO/IEC/IEEE 42020
date-start:: [[30-08-2024]] - 02:26
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@SCICO-D-24-00161_reviewer]]
parent::
todoist:: https://app.todoist.com/app/task/scico-d-24-00161-6VgxxWh4q2VC4Hcc
- ### [[Highlights]]
-
- # Annotazioni
- (30/8/2024, 02:27:49)
- - “Although both standards are closely related and share essential concepts, it is important to note that they serve different purposes. While 42010 sets out general principles for describing architectures, 42020 provides” (“SCICO-D-24-00161_reviewer”, pp. -) #00b036
- - “While the latter specifies the content and expression of an Architecture Description, the former focuses on its development and management.” (“SCICO-D-24-00161_reviewer”, p. 1) #00b036
- - “The ISO/IEC/IEEE 42020 (42020 from here) is an international standard that provides guidelines for the development of software architectures and systems. The 42020 describes a set of processes for governance and management of a software architecture or a collection of software architectures, as well as for architecting their entities [1].” (“SCICO-D-24-00161_reviewer”, p. 2) #00b036
- - “Standards 42020 provides guidelines for developing software architectures using Architectural Description. However, 42010 does not address how an Architectural Description should be developed and managed throughout the lifecycle of an entity, which is the case of 42020.” (“SCICO-D-24-00161_reviewer”, p. 3) #f0ff00
- *Verbose and repetitive intoduction*
- - “this article aims to combine this knowledge, identifying and presenting new approaches to designing software architectures that impact the practices related to this activity, disseminating the results of an exploratory study based on bibliographic analysis.” (“SCICO-D-24-00161_reviewer”, p. 3) #f0ff00
- *Why is this study needed? What are the challenges to be addressed?*
- - “both standards” (“SCICO-D-24-00161_reviewer”, p. 6) #5fb236
- - “limits” (“SCICO-D-24-00161_reviewer”, p. 6) #5fb236
- - “critical analysis” (“SCICO-D-24-00161_reviewer”, p. 6) #5fb236
- - “confusion between architecture design” (“SCICO-D-24-00161_reviewer”, p. 7) #5fb236
- - “software or sys-tems design” (“SCICO-D-24-00161_reviewer”, p. 7) #5fb236
- - “software architecture design” concerns the conception and definitionof the fundamental structure of a software system, encompassing decision-making across various aspects of the system or software lifecycle” (“SCICO-D-24-00161_reviewer”, p. 7) #5fb236
- - “components” (“SCICO-D-24-00161_reviewer”, p. 7) #5fb236
- - “selection of architec-tural patterns and styles” (“SCICO-D-24-00161_reviewer”, p. 7) #5fb236
- - “software architecture design” (“SCICO-D-24-00161_reviewer”, p. 8) #5fb236
- - “software architecturedescriptions” (“SCICO-D-24-00161_reviewer”, p. 8) #5fb236
- - “discussion about architecture and design” (“SCICO-D-24-00161_reviewer”, p. 8) #ffd400
- *This is the main point of discussion, isn’t it ?*
- - “These standards were developed to address the need for standardizedterminology, methodology, and tools for designing and managing Software Architectures” (“SCICO-D-24-00161_reviewer”, p. 8) #a28ae5
- - “conceptual framework” (“SCICO-D-24-00161_reviewer”, p. 8) #a28ae5
- - “managing architectures” (“SCICO-D-24-00161_reviewer”, p. 8) #a28ae5
- - “Figure” (“SCICO-D-24-00161_reviewer”, p. 10) #ff6666
- *Some words in figure 2 are in Spanish.*
- - “The ISO/IEC/IEEE 42020and ISO/IEC/IEEE 42030 packages conform to the Architecture package by defining system or software architecture principles.” (“SCICO-D-24-00161_reviewer”, p. 10) #a28ae5
- - “By addressing these aspects, this article aims toprovide a comprehensive analysis of standards 42010 and 42020, enriching the understanding of software architecture practices” (“SCICO-D-24-00161_reviewer”, p. 10) #5fb236
- - “Architecture – a concept – what the act of architecting produces – a setof documents – and how to describe these documents – a standard – are notthe same thing” (“SCICO-D-24-00161_reviewer”, p. 11) #5fb236
- - “42020, which establishes afoundation for sound architectural practices and terminology” (“SCICO-D-24-00161_reviewer”, p. 11) #5fb236
- - “Standard 42010 is more focused on standardizing the structure and content of an Architectural Description document than on standardizing the process or methods for describing or documenting the architecture itself” (“SCICO-D-24-00161_reviewer”, p. 12) #ffd400
- *Said already many times.*
- - “Emphasis on Document Structures” (“SCICO-D-24-00161_reviewer”, p. 12) #5fb236
- - “Non-Standardization of Description Process” (“SCICO-D-24-00161_reviewer”, p. 12) #5fb236
- - “architecture description document” (“SCICO-D-24-00161_reviewer”, p. 12) #5fb236
- - “The 42020 expands the scope of42010 and addresses the processes and practices involved in creating andmanaging systems or software architectures” (“SCICO-D-24-00161_reviewer”, p. 13) #a28ae5
- - “Standard definition” (“SCICO-D-24-00161_reviewer”, p. 13) #5fb236
- - “Scope” (“SCICO-D-24-00161_reviewer”, p. 13) #ffd400
- *Why not processes?*
- - “governance, management, conceptualization,evaluation, elaboration, and enablement” (“SCICO-D-24-00161_reviewer”, p. 13) #a28ae5
- - “Purpose” (“SCICO-D-24-00161_reviewer”, p. 13) #5fb236
- - “Interconnection with other standards” (“SCICO-D-24-00161_reviewer”, p. 13) #5fb236
- - “Expanding the Role of Architecture:” (“SCICO-D-24-00161_reviewer”, p. 14) #5fb236
- - “Impact on the occupation and education” (“SCICO-D-24-00161_reviewer”, p. 14) #5fb236
- - “Role in standardization” (“SCICO-D-24-00161_reviewer”, p. 14) #5fb236
- - “Elaboration” (“SCICO-D-24-00161_reviewer”, p. 14) #a28ae5
- - “processes” (“SCICO-D-24-00161_reviewer”, p. 14) #ff6666
- *Among the scope isn’t it?*
- - “The Process of Describing an Architecture” (“SCICO-D-24-00161_reviewer”, p. 14) #ffd400
- *Only this section seems to be not enough to say that tha paper focuses on one specific standard because the whole paper presents and links together different standards with the same level of detail.*
- - “Architecture Elaboration” (“SCICO-D-24-00161_reviewer”, p. 15) #ffd400
- *What are the inputs/outputs from/to the other processes mentioned in the scope above?*
- - “This includes capturing the funda-mental concepts and properties of the architecture, aligning it with relevant requirements and design characteristics, and ensuring that it can guide the development and evolution of the entity being architected” (“SCICO-D-24-00161_reviewer”, p. 15) #a28ae5
- - “The specific objectives of this process in-clude [2]:” (“SCICO-D-24-00161_reviewer”, p. 15) #ffd400
- *So far the paper seems to be an annotated bibliography. It’s an overview of a specific area, which has been done by considering several seminal papers. At this stage of the paper (more than half) I’m still missing the motivation of the paper, its novelty, and it’s scientific*
- - “The standards 42010 and 42020, which are involved with software orsystem architecture, are closely related but serve different purposes in thecontext of developing and documenting a software architecture” (“SCICO-D-24-00161_reviewer”, p. 17) #ffd400
- *This is by design, isn’t it?*
- - “Table 2: Characteristic/Purpose of each standard” (“SCICO-D-24-00161_reviewer”, p. 18) #ffd400
- *This table could complement fig 2 as part of the overview content summarising the different standards and their relationships.*
- - “One of the main strengths lies in the complementarity between the stan-dards. Together, 42010 and 42020 provide a robust conceptual framework (42010) and a practical guide (42020) for creating and documenting systemarchitectures [3, 2]. Both standards are designed to be flexible and adaptable to different contexts and types of architecture [20]. This allows organizationsto choose relevant parts of each standard and adjust them according to theirspecific needs.” (“SCICO-D-24-00161_reviewer”, p. 19) #ffd400
- *This is also a repetition.*
- - “Making the most of these standards requires an investment of time in understanding and implementing the guidelines. This may result in a steep learning curve, especially for teams inexperienced in system architecture.Proper training can help mitigate this challenge” (“SCICO-D-24-00161_reviewer”, p. 19) #ffd400
- *Can you give some evidence supporting such a claim? There are many sentences like this that are missing factual data supporting the given messages from the authors.*
- - “Lack of coordinationcan lead to inconsistency and redundancy in architecture documentation” (“SCICO-D-24-00161_reviewer”, p. 19) #ffd400
- *Same comment like the previous one.*
- - “document? We have an approach, but it raises questions” (“SCICO-D-24-00161_reviewer”, p. 20) #ffd400
- *No tools are mentioned in the paper.discussing them as possibly supporting means of the different standards can make the paper concrete and more interesting even for practitioners.*
- - “Another point is the flexibility in selecting different types of architectures,such as systems, software, and enterprise” (“SCICO-D-24-00161_reviewer”, p. 20) #ffd400
- *Can some supporting tools be of any help for this phase and also for other ones?*
- - “While 42010 setsout general principles for describing architectures, 42020 provides detailedguidance on implementing these principles in practice” (“SCICO-D-24-00161_reviewer”, p. 21) #ffd400
- *What are reference tools that can be used to,support such activities?*
- ### [[Comments]]
- ### Overview
- This is a qualitative and explorative paper analyzing the interplay between two standards in software architecture: ISO/IEC/IEEE 42010 and ISO/IEC/IEEE 42020. The authors highlight the complementary nature of these standards, noting that while 42010 specifies the content and structure of an Architectural Description, 42020 focuses on the processes involved in its development and management. The study is intended to give particular emphasis on the Architecture Elaboration process outlined in 42020.
- ### Comments
- I have several concerns about the paper that are related to the following issues:
- 1. The paper is generally verbose and tends to repeat the same ideas without adding significant value. The distinction between ISO/IEC/IEEE 42010 and 42020 is reiterated multiple times without providing deeper insights or justifications. I suggest revising the paper by clearly articulating the unique contributions of each standard, minimizing redundancy.
- 2. The paper does not adequately explain why this study is necessary or what specific challenges it seeks to overcome. While the authors mention the need to re-evaluate the relationship between the two standards, they need to convincingly articulate the practical implications or the gaps in current understanding that this paper aims to fill. A more robust discussion on the motivation behind the study and the challenges it intends to address would strengthen the paper's impact.
- 3. Following my previous comment, the paper seems to be an annotated bibliography. It presents an overview of a specific area, which has been conceived by considering and referring to several seminal papers. The reader misses the motivation of the paper, its novelty, and its scientific contribution.
- 4. The paper claims to focus on the Architecture Elaboration process in ISO/IEC/IEEE 42020, but this focus is not consistently maintained throughout the text. Only one section is devoted to this process, even though the discussion in that section often refers to general comparisons between the two standards.
- 5. The paper makes several claims, such as the steep learning curve associated with implementing these standards and the challenges of coordination in large organizations, without providing empirical evidence or case studies to support these assertions. Incorporating data or examples from real-world implementations would enhance the credibility and relevance of these arguments.
- 6. Early in the paper, the authors discuss a UML package diagram presenting the relationships of the different standards. Later in the paper, Table 2 is given as part of the discussion to show the main characteristics of the considered standards. However, these visual aids could be better integrated. For instance, the table could be used to complement the discussion in Figure 2, providing a more precise overview of the relationships between the standards. Additionally, the presence of non-English words in Figure 2 should be corrected to ensure clarity for a broader audience.
- 7. The discussion around the practical application of these standards, especially regarding tool support, is lacking. The paper would benefit from exploring how existing tools can facilitate the processes outlined in the standards and whether there are gaps in tool availability that need to be addressed. This would make the paper more relevant to practitioners seeking to implement these standards.
- 8. The conclusion should propose concrete directions for future research. The current conclusion hints at the need for best practice guidelines and further empirical studies but lacks specificity.
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
collapsed:: true
- {{query (and [[ffd400]] [[SCICO-D-24-00161]] )}}
collapsed:: true
- ### ❓️Questions
collapsed:: true
- {{query (and [[question]] [[SCICO-D-24-00161]] )[[question]]}}
query-table:: true
query-properties:: [:block]