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/IEEECS 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. serviceoriented). 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 serviceoriented 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



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 FITHANU
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 SECHANU 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 “DDSDSpecific” 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
Introduction:
- Overview of programming languages
1

2

The Java programming language:
- Syntax and semantics
- Java syntax: BNF-typed grammar rule,
identifier, method, block, statement,

DDSD-Specific
- Overview of programming
languages:
(+) Object-based
programming language [9]
(0.15)
-

As-is

New

2

0.15

3

122


expression

3

4

5

6

7

8

9

-

Operational principles of compiler:
- Compiler and virtual machine
- Operational principles of compiler and
virtual machine
Verifiable program:
- Concept of verifiable program
- Design specification of a verifiable,
procedural program
- Coding a verifiable program
Object oriented program:
- Concepts of and motivation for object
oriented program
- Comparison between OOP and
procedural program

- Benefits of OOP

2
- Design specification of a
verifiable, procedural
program:
(+) DDD and procedural
program design (0.1)
- Concepts of and motivation
for object oriented program:
(+) OOP and DDD [9] (0.15)

Design and implementation of class:
- Basic terminology
- Design specification method
- Specifying class, field, method
- Implementing class, field, method
Class design issues:
- Basic issues
- Private constructor
- Derived attribute
- Cloning
- Nested class
- Recursive class
- Basic generic class
Object oriented design and
implementation of abstract data types:
- Overview of ADT
- Design method
- Tree

- List
Object oriented design automation:
- What is and why OOP design
automation?
- Design automation method: concepts,
technique and tool
- Method demonstration

- Design specification method
(+) DDD specification of OOP
[7] (0.15)
- Specifying class, field,
method
(+) DDD specification of
class, field, method [7] (0.2)
(+) Applying DDD
specification to address the
design issues (0.15)

(+) Applying DDD
specification to design the
ADT (0.15)

5

0.1

2

0.15

4

0.35

4

0.15

4

0.15

2

Total

28

1.05

Table 2: Descriptions of the DDD-specific topics for PR2
No
1

DDSD-Specific topic

Description

(+) Object-based programming language

[9]

123

- highlight the features of OOPL which
make them suitable for solving real-world


(+) DDD and procedural program design
4

(+) OOP and DDD [9]
5

7

(+) DDD specification of OOP [7]
(+) DDD specification of class, field,
method [7]
(+) Applying DDD specification to address
the design issues

8

(+) Applying DDD specification to design
the ADT

6

problems (synthesised from Evans’s

discussion on the suitable programming
languages for DDD [9])
- demonstrate the benefit of domainspecific design specification of procedural
program (e.g. by using OpenJML to
automatically verify a procedure’s code its
design specification)
- explain the close correspondence between
OOPL and DDD and why it is a better
candidate for DDD than procedural
program
- make explicit the connection between
DDD and the OOP design specification
currently being taught
- explicitly use the design specification to
realise definition of the design rules for
resolving the issues
- explicitly use the design specification to
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

1

2

3

4

As-is

DDSD-Specific

Advanced design:
- Type hierarchy
- Exception
- Iteration abstraction

Testing and debugging:
- Testing concept
- Testing procedural program
- Black and white box testing
- Defensive programming
- Debugging
Software and requirement
engineering:
- Introduction to software
engineering
- Requirement engineering
Requirement modelling and
specification:

- UML class and use case
diagrams

As-is

New

- Type hierarchy:
(+) Applying DDD specification to
design type hierarchy (0.25)
- Iteration abstraction:
(+) Applying DDD specification to
design iteration abstraction (0.15)

8

0.4

- Black box testing:
(+) Applying DDD specification to
design the test data (0.15)

4

0.15

- Introduction to software
engineering:
(+) Domain-driven software
engineering [9] (0.15)

2

0.15

(+) Domain modelling concepts and
technique [7], [9] (0.25)

2

0.25

124


- Requirement specification

5

6

7

Object oriented design:
- Design overview
- Design principles and process
- Design notebook
- Case study: KEngine
Implementation:
- Design evaluation

- Implementation strategies
- Case study: KEngine
Software testing:
- Software testing methods
- Development testing
- Test program design
- Case study: KEngine

- Design overview
- Design principles and process:
(+) DDD principles [9] (0.5)

4

0.5

- Implementation strategies:
(+) Domain driven implementation
strategies (0.15)

4

0.15

- Development testing:
(+) Domain driven testing strategy
(0.25)

2

0.25

26

1.85

Total

Table 4: Descriptions of the DDD-specific topics for SE1
No

1

DDSD-Specific topic

Description

(+) Applying DDD specification to design
type hierarchy
(+) Applying DDD specification to design
iteration abstraction

2

(+) Applying DDD specification to design
the test data

3

(+) Domain-driven software engineering [9]

4

(+) Domain modelling concepts and
technique [7], [9]

5

(+) DDD principles [9]

6

(+) Domain driven implementation
strategies

7

(+) Domain driven testing strategy

- make explicit that the existing design
specification is DDD
- explain how BBT rules can be applied
using the existing design specification
(DomainConstraint, DOpt)
- 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
engineering method
- relate requirement modelling and

specification to domain modelling in
DDD
- formally introduce the DDD principles
for design
- explain how the 3 implementation
strategies can be adapted to DDD
- explain how development testing method
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

1

2

3

4

5

6

7

8

As-is

DDSD-Specific

Introduction to software architecture
- The concept of software architecture

-

Software development life cycle
- Lifecycle and process models
- Software project management
- Software product lines

Architecture styles
- Overall architecture: hierarchical, clientserver, cloud-based, peer-to-peer
- Program-level architecture: controlbased, dataflow, object-oriente
- Model-Driven Architecture

- Frame & Middleware Architecture
Advanced UML design techniques
- Concurrency and distribution
- Some popular data types
- UML design diagrams: sequence
diagram, activity diagram, state chart
Design patterns
- Structural patterns: Bridge, Composite,
Decorator, Faỗade, Flyweight
- Behavioral patterns: Observer,
Command, Visitor, Strategy, Chain of
responsibility, State
- Creational patterns: Abstract factory,
Factory method, Prototype, Builder,
Singleton
Software design for reuse
- Specification for API design
- Component-based development
Configuration management
- Version control systems: local version
control, centralised and distributed version
control
- Build management systems
- Bug and issue tracking systems
Quality assurance
- Software metrics: cost and reliability
models

126

- Lifecycle and process
models:
(+) DDSD process model
[6]–[8] (0.25)
- Software product lines:
(+) Applying DDSD to
develop software product
lines (0.25)
- Overall architecture:
(+) Fundamental
architecture styles for
DDSD [9], [13] (0.25)

As-is

New

4

4

0.5

4

0.25

4

(+) DDD patterns [9], [12]

(2)

(+) Module-based software
development with DDSD
[6], [7] (1)
-

4

2

2

0.75

2

(+) QA issues with domain
modelling and DDSD (0.5)

2

0.5


- 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

2

(+) DDSD process model [6]–[8]
(+) Applying DDSD to develop software
product lines

3

(+) Fundamental architecture styles for
DDSD [9], [13]

5

(+) DDD patterns [9], [12]

6

(+) Module-based software development
with DDSD [6], [7]

8

(+) QA issues with domain modelling and
DDSD

- introduce the DDSD process model from
previous work. Demonstrate with the
DomainAppTool
- explain how DDSD can be adapted to
produce software product lines.
Demonstrate with the DomainAppTool
- Highlight the architecture styles that are
suitable for DDD
- explain the core DDD patterns proposed
by Evans
- introduce the patterns proposed by this
paper’s author [16]
- demonstrate the patterns using
DomainAppTool
- explain module-based software
development in DDSD that uses a
module-based software architecture
(recently proposed by this paper’s author)
- explain how the QA issues are applied to
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 DDSDspecific 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 upto-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: />[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:
/>[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:
/>
129