Nghiên cứu sơ bộ về xây dựng chương trình giảng dạy công nghệ phần mềm bằng phương pháp phát triển phần mềm hướng miền

Chia sẻ: Huyết Thiên Thần | Ngày: | Loại File: PDF | Số trang:14

Thêm vào BST

Báo xấu

18
lượt xem 0
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Vì một số lý do về lịch sử mà chương trình giảng dạy công nghệ phần mềm của HANU đã được thiết kế dựa trên phiên bản cũ hơn của chương trình khung. Trong bài báo này, tác giả nghiên cứu cách cập nhật chương trình này sử dụng phương pháp phát triển phần mềm hướng miền. Tác giả định nghĩa phương pháp cập nhật dựa trên một phương pháp tiếp cận hướng miền, được áp dụng để khái niệm hóa cấu trúc của chương trình giảng dạy CNPM. Tác giả áp dụng phương pháp để chỉnh sửa ba môn học nòng cốt của chương trình giảng dạy công nghệ phần mềm HANU. Mời các bạn cùng tham khảo chi tiết nội dung bài viết!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Nghiên cứu sơ bộ về xây dựng chương trình giảng dạy công nghệ phần mềm bằng phương pháp phát triển phần mềm hướng miền

NGHIÊN CỨU SƠ BỘ VỀ XÂY DỰNG CHƯƠNG TRÌNH GIẢNG DẠY CÔNG NGHỆ PHẦN MỀM BẰNG PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM HƯỚNG MIỀN Lê Minh Đức * Trường Đại học Hà Nội Tóm tắt: Giáo dục về công nghệ phần mềm (CNPM) đóng vai trò quan trọng trong việc phát triển các kiến thức nghề và học thuật của lĩnh vực CNPM. Sách chương trình khung giảng dạy của ACM/IEEE-CS gần đây giúp cung cấp cho các nhà thiết kế chương trình giảng dạy các hướng dẫn cập nhật và cần thiết. Tuy nhiên, vì một số lý do về lịch sử mà chương trình giảng dạy CNPM của HANU đã được thiết kế dựa trên phiên bản cũ hơn của chương trình khung. Trong bài báo này, tác giả nghiên cứu cách cập nhật chương trình này sử dụng phương pháp phát triển phần mềm hướng miền. Tác giả định nghĩa phương pháp cập nhật dựa trên một phương pháp tiếp cận hướng miền, được áp dụng để khái niệm hóa cấu trúc của chương trình giảng dạy CNPM. Tác giả áp dụng phương pháp để chỉnh sửa ba môn học nòng cốt của chương trình giảng dạy CNPM HANU. Từ khóa: Giáo dục công nghệ phần mềm, phương pháp công nghệ phần mềm, thiết kế định hướng miền. Abstract: Software engineering (SE) education plays an important role in advancing professional and academic SE knowledge. The recent ACM/IEEE-CS SE curriculum guidebook provides necessary and up-to-date guidelines for SE curriculum designers. However, for historical reasons, the current HANU’s SE curriculum was designed based on an older version of the guidebook. In this paper, we investigate an approach to update this curriculum using the domain-driven software development (DDSD) method. We define the update method based on a model-driven approach to conceptualise the SE curriculum structure. We apply the method to revise three core courses of the HANU’s SE curriculum. Keywords: software engineering education, software engineering method, domain-driven design. A PRELIMINARY STUDY ON IMPLEMENTING SOFTWARE ENGINEERING CURRICULUM USING THE DOMAIN DRIVEN SOFTWARE DEVELOPMENT METHOD I. INTRODUCTION There is no doubt that software engineering (SE) education has been playing a crucial role in consolidating, disseminating and advancing both the professional and academic knowledge and skills of the SE discipline. The first formal attempt to standardise the body of knowledge for the undergraduate SE education was a joint effort 116
from the world’s largest professional computing organisations: Association for Computing Machinery (ACM) and IEEE Computer Society. In 2004, an ACM/IEEE- CS joint task force released the first version (SE 2004) of the SE curriculum guidebook [1]. Ten years later, another joint task force from the two organisations was formed to revise the first guidebook and released an updated SE 2014 version [2]. The two guidebooks both recognise SE as a computing discipline and provide a set guiding principles and a body of knowledge for SE curriculum designers. Since its establishment in 2012, the Department of SE1 (Hanoi University, HANU) has been adopting the SE 2004 guidebook to design the SE courses that form part of the Faculty of IT’s undergraduate program. Initially, these include 6 core courses [3] that were taught in the first two years of the IT program. Since 2018, the curriculum has been undergoing an extensive revision and expansion to include a more complete set of courses. The aim is to teach these courses over the entire duration of the IT program. However, for historical reason, the foundation of the updated curriculum was still kept to the SE 2004. A question that can be asked, therefore, is whether or not this curriculum is up to date with regards to the SE 2014 guidebook. Our study of the literature concerning SE 2014 guidebook [2], [4], [5] reveals one of the key issues facing curriculum review is identify new and relevant course topics, which have emerged from state-of-the-art software development methods (e.g. service- oriented). It is important to note that the SE 2014 guidebook defines its knowledge elements as abstractions from the methods, techniques and tools that are performed in different phases of the software development process. The knowledge body is, however, designed to be independent from any particular software development methods. This provides curriculum designers with a flexibility to choose an implementation method suitable for their contexts. Hence, it is possible to argue for the application of an “abstract” and modern software development method to revise SE curriculum. The idea is to map the curriculum’s courses to components of the method and then analyse them for new knowledge elements that need to be added. Our goal in this paper is to investigate the application of the domain-driven software development (DDSD) [6]–[8] method to revise the HANU’s SE curriculum. DDSD has been proven in research and has successfully been applied in teaching and in practical software development. DDSD is based on the well-known domain-driven design (DDD) method [9], which has shown to be compatible with other contemporary software development methods, such as service- oriented software development. DDSD tackles two core problems in DDD-based software development: domain modelling and scalable software construction from this model. DDSD is practical in its use of high-level programming languages, such as Java and C#. 1 http://fit.hanu.edu.vn 117
Our approach is based on conceptual modelling and model evolution [10]. We first construct a conceptual model of the SE curriculum and then identify suitable DDSD-specific topics to match this model. Our main contribution is therefore a revised SE curriculum for HANU that incorporates state-of-the-art SE topics, identified based on the DDSD method. The rest of the paper is structured as follows. Section 0 reviews the background concepts. Section 0 explains the research method. Section IV discusses our application of the method to revise the HANU’s SE curriculum. Section V presents an evaluation of the result. Section VI concludes the paper and briefly discusses plan for future work. II. BACKGROUND This section reviews the background concepts concerning DDSD, SE guidebook and HANU’s SE curriculum. We describe the SE guidebook using a meta-model and SE curriculum as a model that realises the meta-model in a specific institutional context. A. Domain driven software development (DDSD) method The domain driven software development (DDSD) method [6]–[8], [11] has recently been proposed by this paper’s author in a collaborative research work with two researchers from the University of Engineering and Technology (Vietnam National University, Hanoi). DDSD was designed based on the classic domain driven design (DDD) method [9], [12], [13], but incorporates a number of useful modern SE Figure 4: The DDSD process model. features, such as iterative development and annotation-based domain specific language. In essence, DDSD is an iterative development method, whose process model (shown in Figure 4) consists in a sequence of three phases: (1) construct the domain model, (2) construct a module-based software from the domain model and (3) review the software. More recently, DDSD has been applied in teaching an SE course [14]. This is an advanced SE course, named Special Subject 2 (SS2), that is taught in the undergraduate IT program at HANU. B. Software engineering 2014 guidebook In this paper, we call to the SE curriculum guidebooks [1], [2] software engineering curriculum frameworks (SECFs). Our main focus is on the current SECF 2014 version. In addition, we will refer to a particular implementation of SECF in an SE undergraduate program (such as the one being offerred at HANU) as SEC model. In software design terminology, SECF is a specification (describing what content SEC models should have), while SEC model is a particular Figure 5: Knowledge map of SECF. Source: [2]. 118
implementation of this specificiation, describing how the content is realised in terms of one or more course sequences. The knowledge structure of SECF is organised into three levels: knowledge area (KA), knowledge unit (KU) and knowledge topic (KP). One KA consists of one or more KUs, each of which consists of a set of KPs. The knowledge map of SECF [2] (shown in Figure 5) consists of 10 KAs and their dependencies. The figures displayed within brackets are the required numbers of lecture hours of each KA. 1) SECF model Figure 6 shows a model for SECF, which is extended from the meta-model proposed in [4]. In this paper, we call this model SECF model. The three concepts on the left hand side of the figure form the software engineering education knowledge (SEEK) structure of SECF. The reflexive “precedes” association shows the dependency between the KAs. On the other hand, the three concepts on the right hand side form the structure of an Figure 6: The SECF model (Adapted from [4]). SE curriculum that implements SECF. The reflexive “precedes” association models course sequences. A curriculum is an SEC model that implements (realises) the SEEK. An SEC model is composed of one or more course sequences. Note from the figure that both KU and Course consist of some Learning Objectives (LOs). LO, which is treated as being synonymous to ‘outcome’ by SECF2, is the basic unit for mapping the courses of a curriculum to its KPs. 2) General learning objectives SECF [2] provides curriculum designers with a generic list of LOs that students of an SEC model are expected to obtain. To ease reference, the following list was reproduced from [2]: 1. Professional knowledge: acquire necessary software engineering knowledge, skills and professional standards 2. Technical knowledge: apply foundational theories, models, and techniques concerning problem identification and analysis, software design, development, implementation, verification, and documentation 3. Team work: work effectively as part of a team in a software development project 4. End user awareness: understand the importance of upholding professional working standards with stakeholders 2 curriculum guideline 2 (Section 5.2, Chapter 5) of SECF [2]. 119
5. Design solutions in context: design one or more domain-specific solutions using multi-faceted software engineering approaches 6. Perform trade-offs: resolve conflicts in project objectives within project constraints (cost, time, knowledge and organisational) 7. Continuing professional development: demonstrate the ability to learn new software engineering knowledge and skills It is observed that while LOs 1, 3, 4, 6 and 7 are fundamental to engineering curriculums in general, LOs 2 and 5 relate to the core SE technical knowledge areas. First, LO 2 summarises the SE’s KAs shown in Figure 5, while LO 5 highlights the essence of SE design (the DES KA). More specifically, the KAs of SECF were identified based on the core activities that are performed as part of a software development process [15]. These activities include overall project management and those that are performed at different phases of the development process. These phases include requirement definition, design, implementation, testing, operation and maintenance. Conceptually, PRF, PRO and QUA concern project management, MAA concerns requirement definition and design, REQ and V& V concern requirement definition, DES and V&V concern design. Note that these mappings are coarse-grained, because there are aspects of some KAs (e.g. SEC and QUA) which concern all phases. Second, LO 5 emphasises two aspects of design that are particularly relevant to the research question of this paper: domain-specific context and the multi-faceted software engineering approaches. This last observation raises an interesting prospect of applying the DDSD method to study SE at the undergraduate level. C. SEC-HANU: A SEC model for FIT- HANU In this paper, the concept of SEC model is applied to construct an SEC model of the SE curriculum, which is currently being taught at the Faculty of IT, HANU. Figure 7 shows the SEC model of this curriculum. In this paper, we call this model SEC-HANU. The arrowed lines in the model express the course sequences. They are instances of the “precedes” association on Course in Figure 6. The model includes a subset of courses, originally designed [3] based on the SECF2004 model [1], and a number of newly-developed courses. There are two main reasons why SEC-HANU is a valid model for SECF2014: (1) the designated teaching staff consulted SECF2004 to select and design the Figure 7: The SEC-HANU model. 120
new courses and (2) according to [5], the guiding principles and SEEK elements of SECF2004 are preserved in SECF. The first 9 courses of SEC-HANU are compulsory courses, which together form the required sequence. The remaining three courses are elective. The required courses are: 1. PR1: Programming 1 2. PR2: Programming 2 3. SS1: Special Subject 1 4. WPR: Web programming 5. SE1: Software Engineering 1 6. SS2: Special Subject 2 7. SQA: Software Quality Assurance 8. SE2: Software Engineering 2 9. SPM: Software Project Management The core sequence of SEC-HANU is a subsequence of the required sequence, which consists of these 5 courses: PR2, SE1, SQA, SE2, and SPM. The names of these core courses are highlighted in Figure 7. III. METHOD This paper argues that DDSD is suitable for implementing SEC model. There are two reasons for this. First, DDSD’s incremental and layered approach to software development is fits naturally with the knowledge acquisition process. More specifically, the courses relevant to the software development activities that are performed at one development layer can be taught in isolation from those at other layers. Further, the courses can be taught incrementally, allowing the students to gradually acquire the knowledge. Second, SECF [2] is designed to be software-process-model-independent, which allows different SDLC process models to be used to realise it. The overall goal of our research is to investigate the possibility of implementing an SEC model using DDSD. In this preliminary research, we examine how to apply DDSD to update the current SEC-HANU model. More specifically, we focus on updating the following three courses of the core sequence (presented in Figure 7): PR2, SE1 and SE2. The first two courses are taught by this paper’s author. The third course is taught by Mr. Nguyen, Dinh Tran Long, a teaching staff in the SE department. We will investigate the remaining courses of SEC-HANU in future work. Our method is based on the model-driven approach to conceptualise SECF (see Section B) and is inspired by model evolution theory [10]. We update the aforementioned courses as follows: 1. data modelling: to construct the curriculum structure model (as explained in 121
Section 0) 2. model match and merge: identify DDSD-specific topics that match the SEC- HANU model and add them to this model In step 2, the suitable DDSD topics are identified based on this paper author’s experiences in teaching and in DDSD research and curriculum design. Care is taken in order to not exceed the total number of credit hours of each course. The current HANU teaching guideline states that these can be measured from the lecture hours. As of this writing, the standard lecture hours of the three selected courses are 30. Each course has between 2 to 4 hours at the end (called the revision time) that are reserved for reviewing the course content. The objective is then to use a portion of these hours for the additional DDSD-specific topics. Each course is presented with two tables: one table listing names of the existing course topics and the newly proposed DDSD-specific topics (if any), the other table listing descriptions of these DDSD topics. The first table has a row that shows the total lecture hours of both the existing and the new topics. IV. REVISING SEC-HANU WITH DDSD This section describes the result of applying the method discussed in the previous section to revise the three core courses of SEC-HANU. Each course is presented in a separate subsection. A. Course module PR2 Since the PR2 course already uses a simplified version of the DDD specification approach [7] of DDSD, a necessary update to this course only involves making explicit the connection to DDSD. Table 1 lists the detailed update to the existing PR2 course topics. Table 2 lists the descriptions of the DDD-specific topics presented in Table 1. In Table 1, column “As-is” lists the existing course topic names, while column “DDSD- Specific” list the update. The total row shows that we can incorporate the new topics into the course without affecting its standard lecture hours. Specifically, the number of additional hours is 1.05, which is well within the revision time range of the course. Table 1: DDSD-specific update to the PR2 course Course topic Lecture hour No As-is DDSD-Specific As-is New Introduction: - Overview of programming - Overview of programming languages languages: 1 (+) Object-based 2 0.15 programming language [9] (0.15) The Java programming language: - - Syntax and semantics 2 3 - Java syntax: BNF-typed grammar rule, identifier, method, block, statement, 122
expression Operational principles of compiler: - - Compiler and virtual machine 3 2 - Operational principles of compiler and virtual machine Verifiable program: - Design specification of a - Concept of verifiable program verifiable, procedural 4 - Design specification of a verifiable, program: 5 0.1 procedural program (+) DDD and procedural - Coding a verifiable program program design (0.1) Object oriented program: - Concepts of and motivation - Concepts of and motivation for object for object oriented program: oriented program (+) OOP and DDD [9] (0.15) 5 - Comparison between OOP and 2 0.15 procedural program - Benefits of OOP - Design specification method Design and implementation of class: (+) DDD specification of OOP - Basic terminology [7] (0.15) 6 - Design specification method - Specifying class, field, 4 0.35 - Specifying class, field, method method - Implementing class, field, method (+) DDD specification of class, field, method [7] (0.2) Class design issues: (+) Applying DDD - Basic issues specification to address the - Private constructor design issues (0.15) - Derived attribute 7 4 0.15 - Cloning - Nested class - Recursive class - Basic generic class Object oriented design and (+) Applying DDD implementation of abstract data types: specification to design the - Overview of ADT ADT (0.15) 8 4 0.15 - Design method - Tree - List Object oriented design automation: - - What is and why OOP design automation? 9 2 - Design automation method: concepts, technique and tool - Method demonstration Total 28 1.05 Table 2: Descriptions of the DDD-specific topics for PR2 No DDSD-Specific topic Description (+) Object-based programming language - highlight the features of OOPL which 1 [9] make them suitable for solving real-world 123
problems (synthesised from Evans’s discussion on the suitable programming languages for DDD [9]) (+) DDD and procedural program design - demonstrate the benefit of domain- specific design specification of procedural 4 program (e.g. by using OpenJML to automatically verify a procedure’s code its design specification) (+) OOP and DDD [9] - explain the close correspondence between OOPL and DDD and why it is a better 5 candidate for DDD than procedural program (+) DDD specification of OOP [7] - make explicit the connection between 6 (+) DDD specification of class, field, DDD and the OOP design specification method [7] currently being taught (+) Applying DDD specification to address - explicitly use the design specification to 7 the design issues realise definition of the design rules for resolving the issues (+) Applying DDD specification to design - explicitly use the design specification to 8 the ADT design the ADTs B. Course module SE1 As shown in Table 3, the update does not violate the standard lecture hours of the SE1 course. The number of new lecture hours of the DDSD-specific topics is 1.85, which is less than half of the 4-hour revision time of the course. Table 3: DDSD-specific update to the SE1 course Course topic Lecture hour No As-is DDSD-Specific As-is New Advanced design: - Type hierarchy: - Type hierarchy (+) Applying DDD specification to - Exception design type hierarchy (0.25) 1 8 0.4 - Iteration abstraction - Iteration abstraction: (+) Applying DDD specification to design iteration abstraction (0.15) Testing and debugging: - Testing concept - Black box testing: - Testing procedural program 2 (+) Applying DDD specification to 4 0.15 - Black and white box testing design the test data (0.15) - Defensive programming - Debugging Software and requirement - Introduction to software engineering: engineering: 3 - Introduction to software 2 0.15 (+) Domain-driven software engineering engineering [9] (0.15) - Requirement engineering Requirement modelling and specification: (+) Domain modelling concepts and 4 2 0.25 - UML class and use case technique [7], [9] (0.25) diagrams 124
- Requirement specification Object oriented design: - Design overview - Design overview - Design principles and process 5 - Design principles and process: 4 0.5 - Design notebook (+) DDD principles [9] (0.5) - Case study: KEngine Implementation: - Implementation strategies: - Design evaluation 6 (+) Domain driven implementation 4 0.15 - Implementation strategies strategies (0.15) - Case study: KEngine Software testing: - Software testing methods - Development testing: 7 - Development testing (+) Domain driven testing strategy 2 0.25 - Test program design (0.25) - Case study: KEngine Total 26 1.85 Table 4: Descriptions of the DDD-specific topics for SE1 No DDSD-Specific topic Description (+) Applying DDD specification to design type hierarchy - make explicit that the existing design 1 (+) Applying DDD specification to design specification is DDD iteration abstraction - explain how BBT rules can be applied using the existing design specification (+) Applying DDD specification to design (DomainConstraint, DOpt) 2 the test data - demonstrate the benefit of the design specification by showing how the test data can automatically be generated from it - formally introduce DDD as a software 3 (+) Domain-driven software engineering [9] engineering method - relate requirement modelling and (+) Domain modelling concepts and 4 specification to domain modelling in technique [7], [9] DDD - formally introduce the DDD principles 5 (+) DDD principles [9] for design (+) Domain driven implementation - explain how the 3 implementation 6 strategies strategies can be adapted to DDD - explain how development testing method 7 (+) Domain driven testing strategy is adapted to DDD C. Course module SE2 As shown in Table 5, the update does not violate the standard lecture hours of the SE2 course. The number of new lecture hours of the DDSD-specific topics is expected to take up the 4-hour revision time of the course. Although this is acceptable, it would be recommended to adjust the existing course topics (e.g. by increasing the overlapping contents with the DDSD topics), so that the additional lecture hour time would be 125
reduced. This type of adjustment is expected because SE2 is a brand new course. Table 5: DDSD-specific update to the SE2 course Course topic Lecture hour No As-is DDSD-Specific As-is New Introduction to software architecture 1 - 4 - The concept of software architecture - Lifecycle and process models: Software development life cycle (+) DDSD process model - Lifecycle and process models [6]–[8] (0.25) 2 4 0.5 - Software project management - Software product lines: - Software product lines (+) Applying DDSD to develop software product lines (0.25) Architecture styles - Overall architecture: - Overall architecture: hierarchical, client- (+) Fundamental server, cloud-based, peer-to-peer architecture styles for 3 - Program-level architecture: control- DDSD [9], [13] (0.25) 4 0.25 based, dataflow, object-oriente - Model-Driven Architecture - Frame & Middleware Architecture Advanced UML design techniques - - Concurrency and distribution 4 - Some popular data types 4 - UML design diagrams: sequence diagram, activity diagram, state chart Design patterns (+) DDD patterns [9], [12] - Structural patterns: Bridge, Composite, (2) Decorator, Façade, Flyweight - Behavioral patterns: Observer, 5 Command, Visitor, Strategy, Chain of 4 2 responsibility, State - Creational patterns: Abstract factory, Factory method, Prototype, Builder, Singleton Software design for reuse (+) Module-based software 6 - Specification for API design development with DDSD 2 0.75 - Component-based development [6], [7] (1) Configuration management - - Version control systems: local version control, centralised and distributed version 7 2 control - Build management systems - Bug and issue tracking systems Quality assurance (+) QA issues with domain 8 - Software metrics: cost and reliability modelling and DDSD (0.5) 2 0.5 models 126
- Software quality assurance: principles of software testing, other methods of program verification Total 26 4 Table 6: Descriptions of the DDD-specific topics for SE2 No DDSD-Specific topic Description - introduce the DDSD process model from previous work. Demonstrate with the (+) DDSD process model [6]–[8] DomainAppTool 2 (+) Applying DDSD to develop software - explain how DDSD can be adapted to product lines produce software product lines. Demonstrate with the DomainAppTool (+) Fundamental architecture styles for - Highlight the architecture styles that are 3 DDSD [9], [13] suitable for DDD - explain the core DDD patterns proposed by Evans - introduce the patterns proposed by this 5 (+) DDD patterns [9], [12] paper’s author [16] - demonstrate the patterns using DomainAppTool - explain module-based software (+) Module-based software development development in DDSD that uses a 6 with DDSD [6], [7] module-based software architecture (recently proposed by this paper’s author) (+) QA issues with domain modelling and - explain how the QA issues are applied to 8 DDSD domain modelling and DDSD V. EVALUATION Technically, our evaluation seeks to answer the following questions about the research work presented in this paper: 1. Is the method presented in Section 0 correct? 2. Is SEC-HANU suitable for integrating DDSD into? 3. Was the method correctly executed? 4. Are the additional DDSD topics suitable for the course modules? 5. Is the updated SEC-HANU model feasible for teaching? The answers to the first two questions can be obtained from our discussion given in Section 0, where we discussed why we selected and scoped our method for integrating DDSD into SEC-HANU. For the first question, a previous work on SECF shows that modelling can be applied to model SECF. Our method applied model matching and merging theories to update a curriculum model. For the second question, we argued in Section III.B.2) how SEC-HANU, although designed based on the previous SECF 2004 version, is still a valid model for the current SECF. 127
The answers to the third and fourth questions come from the revision that we carried out in Section IV. It quite clearly showed that we systematically and sequentially analysed the topic plan of each of the three course models mentioned in the method. The as-in topics were used as the base for identifying and incrementally adding the DDSD- specific topics, where suitable. The suitability of each DDSD topic as an add-on to an as-is topic was determined based on a combination of the author’s experiences in teaching and in DDSD research and curriculum design. Indeed, DDSD was proposed and defined in recent work [6]–[8] by this paper’s author. The answer to the fifth question can be obtained qualitatively and/or quantitatively. Qualitatively, the feasibility of the updated SEC-HANU model comes from the (1) feasibility of DDSD as a software development method and (2) DDSD’s suitability for teaching. The former has been argued and demonstrated in the recent work [6]–[8]. The latter has recently been demonstrated in a course book [14] (written by this paper’s author) for teaching DDSD in the SS2 course module. Quantitatively, answer to the fifth question can be obtained from actually applying the model in teaching and then collecting and analysing the feedbacks from both the teaching staff and the students. We plan to perform this in future work. VI. CONCLUSION This paper presented the result of a preliminary study on implementing SE curriculum using the domain driven software development (DDSD). We scoped our study to the HANU’s SE curriculum and studied how DDSD is applied to update three core courses of this curriculum. The update concerns identifying and adding more up- to-date SE topics to the existing syllabi of these courses. We based the update method a recent model-driven approach to conceptualise the ACM/IEEE-CS SE curriculum structure. Our plan for future work includes: (1) adjusting the SE2 course of the HANU’s SE curriculum to increase the overlapping content with DDSD (this helps reduce the additional teaching time), (2) performing quantitative assessment of the updated courses by conducting experimental teaching and obtaining feedbacks from the students and teaching staff, (3) applying DDSD to update the remaining courses of the HANU’s SE curriculum. REFERENCES [1] R. J. LeBlanc and et al., “Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering,” IEEE Computer Society, 2006. [2] M. Ardis, D. Budgen, G. W. Hislop, J. Offutt, M. Sebern, and W. Visser, “SE 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering,” Computer, vol. 48, no. 11, pp. 106–109, Nov. 2015, doi: 128
10.1109/MC.2015.345. [3] D. M. Le, “Nghiên cứu và Xây dựng Khung chương trình đào tạo Nhập môn Kỹ sư phần mềm,” in Proc. Annual Faculty Research Conf., Hanoi University, 2013. [4] P. Bunyakiati and C. Phipathananunth, “Checking Software Engineering Curricula with Respect to SE2014 Curriculum Guidelines,” in Proc. 2017 Int. Conf. on Management Engineering, Software Engineering and Service Sciences, New York, NY, USA, 2017, pp. 44–48, doi: 10.1145/3034950.3034982. [5] D. Budgen, “Applying the SE2014 Curriculum Model,” in Proc. 2015 IEEE 28th Conf. on Software Engineering Education and Training, USA, 2015, pp. 17–20, doi: 10.1109/CSEET.2015.12. [6] D. M. Le, D.-H. Dang, and V.-H. Nguyen, “Generative Software Module Development for Domain-Driven Design with Annotation-Based Domain Specific Language,” Inf. Softw. Technol., vol. 120, pp. 106–239, Apr. 2020, doi: 10.1016/j.infsof.2019.106239. [7] D. M. Le, D.-H. Dang, and V.-H. Nguyen, “On Domain Driven Design Using Annotation-Based Domain Specific Language,” J. Comput. Lang. Syst. Struct., vol. 54, pp. 199–235, 2018, doi: https://doi.org/10.1016/j.cl.2018.05.001. [8] D. M. Le, “A Unified View Approach to Software Development Automation,” Vietnam National University, Hanoi University of Engineering and Technology, Hanoi, 2019. [9] E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2004. [10] P. A. Bernstein and S. Melnik, “Model Management 2.0: Manipulating Richer Mappings,” in Proc. 2007 ACM SIGMOD Intl. Conf. on Management of data, Beijing, China, Jun. 2007, pp. 1–12, doi: 10.1145/1247480.1247482. [11] D. M. Le, D.-H. Dang, and H. T. Vu, “jDomainApp: A Module-Based Domain-Driven Software Framework,” in Proc. 10th Int. Symp. on Information and Communication Technology (SOICT), 2019, doi: https://doi.org/10.1145/3368926.3369657. [12] S. Millett and N. Tune, Patterns, Principles, and Practices of Domain-Driven Design. John Wiley & Sons, 2015. [13] V. Vernon, Implementing Domain-Driven Design, 1st ed. Upper Saddle River, NJ: Addison-Wesley Professional, 2013. [14] D. M. Le, Object-Oriented Domain-Driven Software Development with DomainAppTool: A Software Engineering CourseBook. Hanoi: Hanoi University, 2019. [15] I. Sommerville, Software Engineering, 9th ed. Pearson, 2011. [16] D. M. Le, D.-H. Dang, and V.-H. Nguyen, “Domain-Driven Design Patterns: A Metadata-Based Approach,” in Proc. 12th Int. Conf. on Computing and Communication Technologies (RIVF), Nov. 2016, pp. 247–252, doi: https://doi.org/10.1109/RIVF.2016.7800302. 129