Báo Cáo Thực Tập Doanh Nghiệp Xây Dựng Hệ Thống Phần Mềm Erp.pdf

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA HỆ THỐNG THÔNG TIN BÁO CÁO THỰC TẬP DOANH NGHIỆP XÂY DỰNG HỆ THỐNG PHẦN MỀM ERP Công ty thực tập CÔNG TY CỔ PHẦN TẬP ĐOÀN WATA N[.]

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA HỆ

Trong quá trình thực tập tại Công Ty Cổ Phần Tập Đoàn WATA, em đã được trang bị những kỹ năng mềm, nâng cao và hoàn thiện kiến thức chuyên môn thông qua các công nghệ mới sử dụng cho lĩnh vực Project Manager cùng việc tiếp xúc dự án thật mà công ty đã thực hiện

Em xin chân thành cảm ơn ông Đàm Văn Thiện - Tổng giám đốc Công Ty Cổ Phần Tập Đoàn WATA, anh Ngô Vũ Quyền – Senior Software Engineering, anh Nguyễn Thanh Tuấn – Project Manager đã tận tình giúp đỡ em trong quá trình thực tập Những kiến thức và kinh nghiệm trong suốt thời gian qua đã giúp em dần hoàn thiện và có thêm kinh nghiệm về phân tích, phát triển phần mềm, hiểu thêm về các kiến trúc và công nghệ thịnh hành Tuy nhiên, do kinh nghiệm thực tiễn còn hạn chế, bài báo cáo không thể tránh những sai sót Chính vì vậy, em rất mong nhận được những ý kiến đóng góp của Thầy, Cô để em hoàn thiện bản thân tốt hơn

Thành phố Hồ Chí Minh, Tháng 4 năm 2022

Sinh viên thực hiện

Trần Thế Anh

NHẬN XÉT CỦA GIẢNG VIÊN

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

Mục Lục:

LỜI CẢM ƠN 2

NHẬN XÉT CỦA GIẢNG VIÊN 3

1 GIỚI THIỆU CÔNG TY CỔ PHẦN TẬP ĐOÀN WATA 8

1.1 Thông tin chung 8

1.2 Lĩnh vực hoạt động 8

1.3 Đối tác của công ty 8

2 QUÁ TRÌNH THỰC TẬP 9

2.1 Giới thiệu tổng quan dự án và yêu cầu công việc 9

2.1.1 Tổng quan các dự án 9

2.1.2 Bảng chi tiết từng tuần 9

2.2 Kết quả đạt được 10

3 CƠ SỞ LÝ THUYẾT 10

3.1 Kiến thức về xây dựng process management 10

3.1.1 Những quy trình quản lý dự án tham khảo 10

3.2 Các kiến trúc hệ thống 11

3.2.1 Event driven architecture 11

3.2.2 Microservice 13

3.2.3 Serverless 15

3.3 CORS 17

3.3.1 Khái niệm Same origin policy 17

3.3.2 Khái niệm CORS 18

3.3.3 Client - Side CORS 18

3.3.4 Server - Side CORS 20

3.4 Các kiến trúc server 22

3.4.1 Server là gì ? 22

3.4.2 Một số kiến trúc server phổ biến 23

3.5 Mô hình hóa UML 27

3.5.1 Khái niệm 27

3.5.2 Use-case diagram 27

3.5.3 Tài liệu đặc tả use-case 31

3.5.4 Sơ đồ lớp 32

3.5.5 Activity diagram 33

3.5.6 Sequence diagram 34

3.5.7 State chart diagram 34

4 Các công việc, dự án đã tham gia thực hiện và kết quả 35

4.1 Module HRM trong nền tản ERP 35

4.1.1 Quản lý nhân sự 35

4.1.2 Quản lý dự án 35

4.1.3 Quản lý nguồn lực ở các dự án 35

4.1.4 Thống kê lịch làm việc của nhân viên 35

4.1.5 Quản lý lịch nghỉ 36

4.2 Công cụ sử dụng 36

4.2.1 Jira 36

4.2.2 Slack 36

4.2.3 Google meet 36

4.3 Framework 36

5 ĐÁNH GIÁ NHẬN XÉT 37

5.1 Kết quả đạt được 37

5.2 Những hạn chế 37

6 TỔNG KẾT 38

1 GIỚI THIỆU CÔNG TY CỔ PHẦN TẬP ĐOÀN WATA

1.1 Thông tin chung

Công Ty Cổ Phần Tập Đoàn WATA là một trong những công ty hàng đầu về Dịch

vụ giải pháp phần mềm có trụ sở tại Thành phố Hồ Chí Minh Đến với Công Ty Cổ Phần Tập Đoàn WATA, khách hàng sẽ có cơ hội làm việc với những thành viên trẻ trung, năng động, tài năng Khách hàng/Đối tác của chúng tôi đến từ Bắc Mỹ, Úc, Châu Âu, Nhật Bản, Singapore và Hàn Quốc Chúng tôi đang tìm kiếm ứng viên Kỹ Sư Cầu Nối (BrSE) cho các dự án mới của công ty, người sẽ chịu trách nhiệm thực hiện các công việc liên quan Được thành lập vào năm 2016, Công Ty Cổ Phần Tập Đoàn WATA đã phát triển nhanh chóng và trở thành công ty tiên phong cung cấp các giải pháp phần mềm chất lượng cao trong nhiều lĩnh vực và phục vụ nhiều khách hàng trong và ngoài nước như Bắc Mỹ, Singapore, Hàn Quốc và Nhật Bản

Sứ mệnh của công ty là cung cấp các dịch vụ quản lý và tư vấn đám mây chất lượng cao với giá cả phải chăng để giúp các công ty khởi nghiệp và công ty thuộc mọi quy mô hoàn thành các dự án ở mọi quy mô Công ty giúp các doanh nghiệp tận dụng các thế mạnh của họ và hỗ trợ họ cung cấp các sản phẩm và dịch vụ tuyệt vời để đảm bảo trải nghiệm tích cực cho người dùng cuối

1.2 Lĩnh vực hoạt động

− Phát triển và xuất khẩu phần mềm

− Cung cấp giải pháp phần mềm

1.3 Đối tác của công ty

Công Ty Cổ Phần Tập Đoàn WATA là đối tác chiến lược và cung cấp các giải

pháp về công nghệ,…

2.1.2 Bảng chi tiết từng tuần

Tuần Nội dung công việc

1 Tìm hiểu về quy trình hoạt động của QA/QC, trách nhiệm và những

nội dung cần trao đổi khi là 1 lập trình viên Hiểu được quy trình phát triển sản phẩm Tìm hiểu các tài liệu cần thiết trong quá trình phát triển sản phẩm

2-3 Đi sâu về các loại quy trình phát triển sản phẩm : Waterfall, Agile,

Thống nhất các technical point cần nghiên cứu trước Chuẩn bị timeline và lên kế hoạch cho sprint tới

Khởi tạo mã nguồn dự án, cài đặt môi trường

Thống nhất quy chuẩn code Thống nhất quy trình quản lý mã nguồn Tìm hiểu về các chỉ số đánh giá : burndown, velocity, bug, cost, workload,…

Tập trung phát triển hệ thống

Thực hiện phát triển sản phẩm theo mô hình Scrum : Daily standup meeting, Sprint planning, Sprint retrospective , Sprint review Phân tích requirement và đánh giá story point

Ổn định và cải thiện mã nguồn sau mỗi lần kết thúc sprint

18-22 Tập trung vào giai đoạn UAT

Hiểu được quá trình triển khai sản phẩm, hoàn thiện tài liệu Hiểu được những cập nhật và đưa ra quyết định bổ sung cập nhật tính năng trong giai đoạn UAT

Demo sản phẩm cho Project Sponsor, các stake-holder liên quan

23-25 Đánh giá những kĩ năng, kiến thức đã được đào tạo trong thời gian dài

hạn vừa rồi

2.2 Kết quả đạt được

− Nắm được các quy trình phát triển sản phẩm

− Phân tích được 1 sản phẩm

− Nắm được các tài liệu cần thiết ở từng giai đoạn

− Hiểu được các kiến trúc phát triển sản phẩm

− Thành thạo sử dụng các công cụ : Jira, Slack, github,…

− Áp dụng và phát triển sản phẩm bằng các framework : ReactJS, NextJS, NodeJS, NestJS, TypeORM, clean architecture, CQRS pattern, Ant Design, Tailwind css,…

3 CƠ SỞ LÝ THUYẾT

3.1 Kiến thức về xây dựng process management

3.1.1 Những quy trình quản lý dự án tham khảo

3.1.1.1 Scrum process

− Scrum: là một quy trình phát triển phần mềm theo phương pháp Agile, vì thế

nó tuân thủ các nguyên tắc của Agile Scrum dựa trên 3 chân lý: Minh bạch, thanh tra và thích nghi

− Sprint: Quy trình phát triển được thực hiện thông qua các phân đoạn nối tiếp nhau được gọi là các Sprint Kết thúc mỗi sprint nhóm phát triển sẽ đưa ra 1 phần tăng trưởng của sản phẩm Mỗi sprint diễn ra trong vòng không quá 4

tuần được diễn ra liên tiếp mà không bị gián đoạn 1 sprint này bắt đầu ngay sau khi 1 sprint khác kết thúc

− Scrum master: là người có hiểu biết sâu sắc về scrum, đảm bảo nhóm làm việc hiệu quả với scrum Là người tháo gỡ các thắc mắc cho PO, dev, kiểm thử

− Product Owner: chủ sản phẩm: là người chịu trách nhiệm về sự thành công của dự án Là người biết rõ về tầm nhìn của sản phẩm Là người chịu trách nhiệm quản lý và đảm bảo sự minh bạch của product backlog

− Development team: Một nhóm liên chức năng tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống Đặc điểm của nhóm phát triển là: tự tổ chức và liên chức năng

3.1.1.1.1 Các tạo tác từ Scrum bao gồm

− Product backlog: là nơi lưu trữ các danh sách mong muốn của sản phẩm, danh sách này được sắp xếp dựa theo độ ưu tiên của từng hạng mục Độ ưu tiên cao sẽ được đặt lên đầu danh sách

− Sprint backlog: là bảng công việc được nhóm phát triển để quản lý quá trình sản xuất trong 1 sprint

3.1.1.1.2 Các hoạt động được thực hiện trong quy trình Scrum là:

− Sprint Planning (Lập kế hoạch Sprint)

− Daily Scrum (Họp Scrum hàng ngày)

− Sprint Review (Rà soát Sprint)

− Sprint Retrospective (Cải tiến Sprint)

− Kết quả: Kết thúc thời gian tìm hiểu, thực tập viên có hiểu biết về quy trình phát triển Scrum

− Tạo điều kiện để lên kế hoạch phát triển hệ thống trong kỳ thực tập này

3.2 Các kiến trúc hệ thống

3.2.1 Event driven architecture

3.2.1.1 Định nghĩa

− EDA là một dạng kiến trúc phần mềm được xây dựng trên luồng các event,

sử dụng event như là phương tiện giao tiếp giữa các thành phần hệ thống

− Ví dụ : Một module quản lý việc đăng nhập của user cần chứng thực thông tin của user vừa nhập xong nên tự phát sinh và gửi đi một event gọi là LoginEvent chứa thông tin user Event này sau đó được một module có khả năng thao tác với dữ liệu như WebServer, Database… bắt lấy, thực hiện việc kiểm chứng và sau đó trả lời kết quả thông qua LoginResultEvent để module đăng nhập bắt lấy Theo cách xử lý này thì module đăng nhập không cần biết module nào và sẽ làm thế nào để thực hiện việc kiểm tra, nó chỉ cần biết gửi yêu cầu và nhận kết quả sau khi kiểm tra và tất cả những gì nó quan tâm chỉ là các event được định nghĩa ở mức hệ thống Hơn nữa, event kết quả trong trường hợp trên có thể được quan tâm bởi nhiều module khác như module đảm nhận ghi log và do đó làm cho hệ thống càng mềm dẻo hơn

− Kiểm thử sẽ phức tạp nếu các Module liên quan đến nhau nhiều

− Khi 1 module bị fail, phải có các module chứa các file backup

− Microservice là một kiếu kiến trúc phần mềm Các module trong phần mềm

này được chia thành các service rất nhỏ (microservice) Mỗi service sẽ được

→

3.2.2.2 Phân tích ưu và nhược của Micro-service so với Monolith

3.2.2.2.1 Ưu điểm monolith

− Quá trình phát triển sản phẩm đơn giản, thay đổi code, build và deploy trên duy nhất 1 project Không mất nhiều công để set up môi trường

− Phát triển trên một ngôn ngữ duy nhất nên chỉ cần nắm sâu và chắc ngôn ngữ

đó là giải quyết được hầu hết vấn đề

3.2.2.2.2 Nhược điểm monolith

− Theo thời gian, source code phình to ra (requirement change, fix bug, fix conflig, ) dẫn đến việc người mới sẽ mất nhiều thời gian để tìm hiểu

− Không tận dụng được lợi thế của ngôn ngữ khác, tốn chi phí để thay đổi nếu dự án quá lớn

− Deployment sẽ tốn nhiều cost, do source code lớn nên thời gian deploy dài

− Scale up (Horizontal scale) đơn giản nhưng tốn chi phí cho những phần không cần scale trong hệ thống

3.2.2.2.3 Ưu điểm micro-service

− Vì chia thành nhiều bài toán nhỏ nên source code cũng nhỏ hơn, dễ dàng thay đổi và cập nhật Vòng đời phát triển sản phẩm nhanh hơn

− Deployment nhanh hơn, độc lập giữa các service Các team phát triển

nhanh và ít phụ thuộc lẫn nhau

− Các issue nếu xảy ra trong 1 service thì sẽ có ít ảnh hưởng hơn tới các service còn lại Các service còn lại vẫn hoạt đồng bình thường (tuy nhiên không đảm bảo hệ thống hoạt động đúng đắn, phải có các giải pháp để xử lý những vấn

đề này Điều này cũng tương tự với kiến trúc Monolithic)

− Tận dụng được điểm mạnh đa ngôn ngữ để áp dụng cho từng service một cách phù hợp

3.2.2.2.4 Nhược điểm micro-service

− Rất phức tạp để thiết kế và triển khai Yêu cầu kĩ thuật rất cao và đã có kinh nghiệm về hệ thống

− Performance chậm hơn do việc giao tiếp giữa các service

− Yêu cầu kiến thức về domain, business tốt để phân chia thành các service nhỏ sao cho phù hợp

− Vấn đề liên quan đến vận hành và xử lý, nếu một hoặc nhiều service down thì sẽ giải quyết thế nào

− Yêu cầu infrastructure phức tạp Không chỉ quản lý các service trong

Microservice mà phải quản lý cả các hệ thống liên quan khác

3.2.2.2.5 Khi nào sử dụng micro-service

− Một thách thức đối với việc sử dụng kiến trúc Microservices là khi nào nên

sử dụng nó

− Khi phát triển phiên bản đầu tiên của ứng dụng, bạn thường không gặp phải các vấn đề mà Microservices giải quyết Hơn nữa, sử dụng một kiến trúc phân tán, phức tạp sẽ làm chậm quá trình phát triển Đây là một vấn đề rất lớn đối với các start-up vì họ cần phát triển nhanh mô hình kinh doanh cùng

ứng dụng đi kèm

− Vì vậy, theo tôi, trừ khi bạn có một hệ thống quá phức tạp để quản lý bằng Monolithic Architecture, hoặc bạn xác định tương lai của ứng dụng sẽ trở nên như vậy Thì kiến trúc Monolithic vẫn đủ tốt đối với bạn

3.2.2.2.6 Ta có thể liệt kê một trường hợp nên sử dụng kiến trúc này

− Team size lớn và rất lớn, đủ nguồn nhân lực có kiến thức và kinh nghiệm

− Là framework giúp xây dựng các ứng dụng theo dạng serverless

− Serverless là mô hình thực thi điện toán đám mây mà các NCC sẽ quản lý việc phân bố tài nguyên, giá cả Có thể hiểu chúng ta xây dựng lên các ứng dụng khả dụng, sẵn sàng lắng nghe và phản ứng lại với các sự kiện được đưa ra bởi các dịch vụ

3.2.3.2 Serverless được xây dựng thế nào

3.2.3.2.1 Serverless được triển khai ở 2 mô hình chính

3.2.3.2.1.1 BaaS – Backend as a Service

− Phần code logic chúng ta sẽ chuyển về phía FE Còn BE sử dụng API có sẵn của bên thứ 3 Ví dụ 1 ứng dụng dự báo thời tiết thì ta sẽ lấy dữ liệu thời thiết

thì có thể sử dụng API được Public bởi các nhà cung cấp bên thứ ba như

Google Weather API

3.2.3.2.1.2 FaaS – Function as a Service

− Tự viết các API cho mục đích của mình Thay vì deploy nó lên server như

mô hình client-server thông thường, chúng ta deploy code dưới dạng RestAPI Với mô hình này, chúng ta chỉ việc code thôi, server và nơi lưu trữ code bên thứ 3 sẽ tự quản lý

− Đây là cách mà các hàm được viết và thực thi khi sử dụng Serverless:

o Dev viết 1 func: func sẽ thực hiện 1 chức năng cụ thể trong app

o Dev define 1 event: event sẽ trigger tới func được viết ở trên Event phổ

biến nhất là HTTP request

o Event đã được trigged: nếu event là 1 HTTP request, user sẽ trigger event

bằng cách click hoặc hành động tương tự

o Func được thực thi: nhà cung cấp cloud sẽ kiểm tra xem instance của func

đã được chạy hay chưa Nếu chưa, nó sẽ bắt đầu tạo 1 instance mới cho func

o Kết quả được gửi tới client: user có thể xem được các kết quả đã thực

3.2.3.2.1.3 Vì sao chọn Serverless

− Không cần tốn công sức bảo trì hệ thống

− Dễ dàng mở rộng quy mô Khi số lượng request tới ứng dụng của bạn tăng cao, các nhà cung cấp bên thứ ba tự mở rộng thêm các tiến trình và tài nguyên để cân bằng tải khi có nhiều request

− Có tính sẵn sàng và khả năng chịu lỗi cao

− Chúng ta không cần phải đau đầu suy nghĩ và quyết định architecture phù hợp vì nó được cung cấp mặc định bởi các nhà phát triển ứng dụng như Google , Amazone,

− Tiết kiệm chi phí, sử dụng tài nguyên bao nhiêu, chỉ cần trả tiền bấy nhiêu Nếu hệ thống không chạy thì chúng ta không mất phí Với các doanh nghiệp thì chi phí của serverless sẽ linh hoạt hơn so với việc thuê server với cấu hình mặc định

3.2.3.2.1.4 Khi nào sẽ sử dụng Serverless

− Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng

− Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,…

lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian chờ

3.3 CORS

3.3.1 Khái niệm Same origin policy

− Là 1 security concept quan trọng được thực hiện trên browser nhằm ngăn chặn JS có thể tạo những request tới những domain khác Hiểu đơn giản Same origin là protocol, domain và port của liên kết truy cập là giống nhau

− Dưới đây là cách để so sánh Same origin

− Tại sao same origin tồn tại, thì các bạn cứ nghĩ đơn giản, nếu các bạn vô

Facebook, trong khi đó ở một tab khác các bạn mở một trang web chứa mã độc Tab Facebook sử dụng JavaScript để request lên server, nếu không có same origin policy, JavaScript ở web chứa mã độc kia cũng có thể tạo request lên server của Facebook với resource của tab Facebook, vì thế trình duyệt phải có cơ chế để phân biệt JavaScript của nguồn nào thì được access vào resource của nguồn nào

3.3.2 Khái niệm CORS

− Là một cơ chế cho phép nhiều tài nguyên khác nhau (fonts, Javascript, v.v…) của một trang web có thể được truy vấn từ domain khác với domain của trang

đó

3.3.3 Client - Side CORS

− Vì lí do bảo mật, browser hạn chế các request HTTP giữa nhiều domain khác nhau Điều này có nghĩa là web app sử dụng api chỉ có thể gửi HTTP request từ cùng một miền nơi web app được tải Điều này gây ra không ít hạn chế cho việc giao tiếp giữa client và server dù chúng đều là những nguồn có thể tin tưởng được

− Trong quá trình phát triển web app, chúng ta thường truy cập data ở một domain khác hay còn gọi là tên miền chéo Để yêu cầu tài nguyên miền chéo một cách an toàn, browser sử dụng 1 cơ chế gọi là CORS Mặc dù browser cấm truy cập domain chéo theo mặc định, nhưng chúng ta có thể sử dụng

CORS để nới lỏng hạn chế này

3.3.4 Server - Side CORS

− Ta phải thêm 1 field vào response là Access - Control - Allow - Origin,

giá tri của field này chỉ ra những trang web có thể truy cập vào tài nguyên

− Sau khi thêm field ACAO Nếu https://www.mywebsite.com gửi request domain chéo thì nhận được response như sau

− Sau khi nhận phản hồi từ server, browser sẽ kiểm tra cơ chế CORS Access

- Control - Allow - Origin coi giá trị có bằng nhau hay không