Quy trình phân tích yêu cầu phần mềm ở Fsoft Giai đoạn đầu tiên của Software EngineeingHình 6: Giai đoạn đầu tiên của Software EngineeringMục đích:Nhằm đảm bảo rằng các yêu cầu cho sản p
Những điều thu hoạch được từ tìm hiểu thực tế ở cơ sở thực tập
Tổng quan về công ty
Tên công ty: FPT software Co.,Ltd
Trụ sở : Tòa nhà FPT,đường Duy Tân,quận Cầu Giấy,Hà Nội,Việt Nam
Doanh thu: 513,6 triệu dollars(năm 2020)
Ngày thành lập: Ngày 13 tháng 1 năm 1999
Chủ tịch: Chu Thị Thanh Hà
Giám đốc: Phạm Minh Tuấn
Website: www.fpt-software.com
Hình 1: Cấu trúc tổ chức FSoft
Tầm nhìn FPT: FPT mong muốn trở thành một tổ chức kiểu mới, giàu mạnh bằng nỗ lực lao động sáng tạo trong khoa học kỹ thuật và công nghệ, làm khách hàng hài lòng, góp phần hưng thịnh quốc gia, đem lại cho mỗi thành viên của mình điều kiện phát triển tốt nhất tài năng và một cuộc sống đầy đủ về vật chất, phong phú về tinh thần.
Cho đến nay, Văn hóa FPT được miêu tả rõ nhất trong FPT Gen.
“Văn hóa STC”, thường được biết đến thông qua các bài hát STC, chỉ là một thành phần của FPT Gen.
FPT Gen = Văn hóa FPT, thể hiện trong “làm” và “chơi”, trong công việc và cuộc sống.
5 Thành phần của FPT Gen
“Sâu – sáng – tuyệt – thông – phong”
Quy trình chất lượng Định hướng khách hàng o Hiểu biết sâu sắc nhu cầu của khách hàng, kể cả nhu cầu tiềm ẩn, và đáp ứng một cách tốt nhất các nhu cầu đó.
Tham gia của mỗi thành viên o Mỗi người ở từng vị trí phát huy cao nhất năng lực và sáng tạo của mình. Nhất quán và đa dạng o FPT là một thực thể thống nhất trong mục tiêu nhưng đa dạng trong hành động.
Thước đo thực tiễn o Các quyết định và đánh giá dựa trên việc phân tích các dữ liệu và thông tin.
Cải tiến và đổi mới liên tục o FPT không ngừng nâng cao năng lực tổ chức và cá nhân, chất lượng sản phẩm và dịch vụ thông qua đổi mới, cải tiến và sáng tạo liên tục.
Cấu thành o Kiến trúc hệ thống o Hạ tầng ICT o Các trình ứng dụng
Các nguyên lý o Tin học hóa toàn diện và triệt để o Đảm bảo cao nhất kiến trúc tập trung và tính tích hợp o Hạ tầng ICT tiên tiến o Xây dựng các hệ hỗ trợ ra quyết định o Đảm bảo mềm dẻo, dễ mở rộng, nâng cấp o Đầu tư mạnh dạn và hợp lý
3 Cách làm việc trong một dự án ở Fsoft
3.1 Các hoạt động trong dự án phần mềm
Project Management(Quản lý dự án)
3.2 Vòng đời của một dự án phần mềm
Kế hoạch phát triển phần mềm
Hình 2: Kế hoạch phát triển phần mềm
Kế hoạch bảo trì phần mềm
Hình 3: Kế hoạch bảo trì phần mềm
3.3 Các trách nhiệm và vai trò của dự án
Hình 4: Tổ chức dự án
Kỹ thuật/Các trách nhiệm của trưởng nhóm
Các vấn đề & giải pháp o Thiết kế o Giải pháp kỹ thuật
Quản lý nhóm o Phân công nhiệm vụ o Theo dõi & Báo cáo o Cố vấn, đào tạo thành viên trong nhóm
Các trách nhiệm của DEV
Các trách nhiệm của Tester
QA-Quality Assurance(Dảm bảo chất lượng)
Xem lại các sản phẩn của dự án,các tài liệu
Xem lại các hoạt động quản lý dự án,các cột mốc,các tài liệuThực hiện kiểm toán,kiểm định cuối cùng
Bảo mật thông tin ở Fsoft
Các quy định bảo mật thông tin
1 Ra vào nơi làm việc
3 Sử dụng thiết bị ngoại vi
4 Sử dụng thiết bị ghi hình ghi âm
5 Sử dụng thông tin mật của công ty
6 Sử dụng thông tin cá nhân
7 Sử dụng mạng nội bộ, file server và intenet
Bảo mật thông tin theo ISO27001
FPT Software nghiêm khắc theo ISO27001 để bảo vệ thông truy nhập của của công ty,các khách hàng và các nhà cung cấp từ tất cả các mối đe dọa,cả bên trong lẫn bên ngoài,vô tình hay cố ý.
Hình 5: Bảo mật thông tin theo ISO27001
Quy trình phân tích yêu cầu phần mềm ở Fsoft
Giai đoạn đầu tiên của Software Engineeing
Hình 6: Giai đoạn đầu tiên của Software Engineering Mục đích:
Nhằm đảm bảo rằng các yêu cầu cho sản phẩm phần mềm được định nghĩa và hiểu rõ ràng. o Để biết yêu cầu của khách hàng là gì? o Hiểu những gì khách hàng cần và mong đợi Để tạo SRS- Thiết lập và duy trì các yêu cầu thỏa thuận với những người yêu cầu và các nhóm được tác động Để đảm bảo rằng các yêu cầu đã được tìm thấy
Các yêu cầu được lập thành tài liệu và kiểm soát để thiết lập a bước cơ bản cho phát triển phần mềm và sử dựng quản lý dự án.
Hình 7: Workflow Phát hiện và phân tích yêu cầu phần mềm
Thỉnh thoảng được gọi là khám phá các yêu cầu
Các yêu cầu không thường xuyên sẵn cho bạn,bạn phải phát hiện ra chúng.Phải làm việc với khách hàng và các bên liên quan để phát hiện ra: o Các dịch vụ mà hệ thống sẽ cung cấp o Các ràng buộc mà hệ thống sẽ phải đáp ứng
Phân tích yêu cầu hoàn thành để: oPhát hiện và xử lý các xung đột giữa các yêu cầu oKhám phát các giới hạn của phần mềm và làm thế nào nó tương tác với môi trường của nó. oXây dựng các yêu cầu hệ thống để lấy được các yêu cầu phần mềm.
Nguồn để phát hiện và phân tích yêu cầu phần mềm
Tiềm năng các bên tham gia
Các khách hàng của khách hàng
Kỹ sư sau này sẽ dùng phần cho khách hàng
Các tổ chức công đoàn
Tiến trình để phát hiện và phân tích yêu cầu phần mềm
Hình 8: Tiến trình phát hiện, phân tích yêu cầu phần mềm
Các vấn đề trong phát hiện và phân tích yêu cầu phần mềm
Các vấn đề về phạm vi
Giới hạn của các hệ thống các rủi ro được phát hiện
Các khách hàng/người dùng không cần thiết chi tiết kỹ thuật vì có thể nhầm lẫn giữa mục tiêu của các hệ thống
Các vấn đề về sự hiểu biết
Các khách hàng/người dùng không hoàn toàn chắc chắn những gì cần
Có một sự hiểu biết nghèo nàn về khả năng và giới hạn của môi trường tính toán của họ.
Không hiểu biết đầy đủ về vấn đề tên miền,có một số phiền toái cần giao tiếp của kỹ sư hệ thống.
Các kỹ thuật để phát hiện và phân tích yêu cầu phần mềm
Các kỹ thuật phát hiện o Nghiên cứu tên miền ứng dụng o Đưa ra câu hỏi và phỏng vấn o Hội thảo và thảo luận o Quan sát o Use cases
Các kỹ thuật phân tích o Mô hình hóa hệ thống o Tạo nhanh các mẫu
Các tài liệu yêu cầu-SRC
Tài liệu yêu cầu phần mềm là tài liệu chính thức của những gì được yêu cau cho hệ thống
Thông thường chỉ bao gồm các yêu cầu hệ thống nhưng thỉnh thoảng có thể cũng có các yêu cầu của người dùng
Nó không phải là tài liệu thiết kế.Miêu tả hệ thống sẽ phải làm gì hơn là sẽ phải làm như thế nào.
URD-User Requirement Definition Địa chỉ những gì người dùng cần để làm cho công việc của họ Được sáng tác tất cả các yêu cầu công việc,các nguyên tắc công việc và các ràng buộc khác.
Một tập hợp các yêu cầu phần mềm khi hoàn thiện,phù hợp và đúng khi có thể,từ quan điểm của các nhà phát triển. Tài liệu sau khi cơ bản,phổ biến tham khảo cho khách hàng,nhà phát triển,tester và PM(Project manager)
Lợi ích của một tài liệu tốt
Thỏa thuận cơ bản giữa các khách hàng và nhóm những gì sản phầm phần mềm làm.
Giảm các nỗ lực phát triển
Cung cấp một ước tính giá,lịch trình cơ bản.
Các hoạt động và các bước
Phân tích yêu cầu người dùng
Chuẩn bị danh sách Q&A để lọc những yêu cầu không ro ràng với khách hàng
Gọi/Phỏng vấn khách hàng nếu cần
Phát triển Use cases,yêu cầu hệ thống
Phát triển đặc tả các chức năng
Xem lại và phê duyệt SRS:
Mời hội thảo để xem lại
Ghi âm buổi hội thảo
Các kỹ thuật phát triển SRS
Xác định rõ các yêu cầu sử dụng “structured natural language” Các yêu cầu chức năng có thể được xác định rõ sử dụng mô hình hóa- một tập hợp các kí hiệu đồ họa và ngôn ngữ tự nhiên có cấu trúc Use cases
Các yêu cầu không chức năng không thể được mô hình hóa=>chỉ suer dugj ngôn ngữ tự nhiên có cấu trúc
Phát triển SRS-SRS Review Checklist Để xem lại các yêu cầu của chính khách hàng Đảm bảo khách hàng hoàn toàn hiểu rõ các yêu cầu
Chắc chắn rằng các yêu cầu miêu tả hệ thống mà khách hàng thực sự muốnCác lỗi về yêu cầu có giá rất cao,do đó validation là rất quan trọng Quy trình-Validate Requirement
Hình 9: Quy trình Validate Requirement
Các kỹ thuật-Validate Requirement
Xem lại các yêu cầu
Phân tích có hệ thống hướng dẫn của các yêu cầu
Liên quan đến các nhân viên phát triển,khách hàng và các bên liên quan
Sử dụng một mô hình có thể thực hiện được của hệ thống để kiểm tra các yêu cầu
Xác nhận chất lượng của các mô hình được phát triển trong khi phân tích
Triển khai kiểm tra các yêu cầu để kiểm tra tính có thể kiểm tra Quản lý các yêu cầu
Requirement Management Sheet,Exel sheet,được xử dụng để theo dõi tình trạng,quan hệ và những thay đổi trong toàn bộ dự án.
Một tài liệu bắt buộc(dynamic version of SRS)
Phân loại yêu cầu thành yêu cầu chức năng/yêu cầu không chức năng Để duy trì như một tài liệu chung cho các bên Để theo dõi tiến trình dự án(tình trạng của yêu cầu) Để theo dõi các thay đổi(bao gồm yêu cầu thay đổi) Để tập hợp các yêu cầu có số liệu liên quan cho việc báo cáo The sheet được tạo lần đầu tiên khi yêu cầu của khách hàng đến. Theo dõi yêu cầu
Tại sao theo dõi là cần thiết?
Các yêu cầu có thể thay đổi ở bất kỳ giai đoạn nào trong vòng đời của sản phẩm.
Nếu các yêu cầu được theo dõi,sau đó khi các thay đổi xảy ra,nó dễ dàng tìm thấy.
Hình 10: Theo dõi yêu cầu
Quản lý các yêu cầu thay đổi
Thay đổi các yêu cầu(CR-Change Request)
Các yêu cầu ưu tiên từ các quan điểm khác nhau thay đổi trong quá trình phát triển
Các khách hàng có thể xác định rõ yêu cầu từ một quan điểm công việc vì vậy xung đột với yêu cầu người dùng cuối
Môi trường kỹ thuật và công việc của hệ thống thay đổi trong khi nó phát triển.
Quá trình thay đổi các yêu cầu
Hình 11: Quá trình thay đổi các yêu cầu
PM/TL/BA đại diện đặc tả yêu cầu phần mềm cho các thành viên trong nhóm lam việc
Tự nghiên cứu tài liệu liên quan:cách tiếp cận top-down
Sử dụng FSOFT’s SRS review checklist
Phân loại các mục không rõ ràng,sử dụng Q&A
Thảo luận với các thành viên khác
Thông báo PM/TL/BA về
Tất các các yêu cầu xung độtCác thay đổi,so sánh với phiên bản cuối cùng
Quy trình thiết kế ở Fsoft
Khai thác các giải pháp yêu cầu
Tạo kiến trúc thiết kế,cấp cao và tài liệu thiết kế chi tiết
AD/HLD, DD:Các bước và các hoạt động o Xem lại và phê duyệt thiết kế ở mức cao:
Chuẩn bị cho việc xem lại HLD,báo và gửi tài liệu,các bản ghi tới người xem lại đó.
Review:Phương pháp thiết kế,kiến trúc hệ thống,tính khả thi của quá trình thiết kế chi tiết và coding
Hình 12: Tổng quan quy trình thiết kế
Phê duyệt HLD o Thiết kế chi tiết:
Thiết kế màn hình,báo cáo,các giải thuật và các modul khác. Tại tài liệu thiết kế chi tiết
Mục đích:Nó để thành lập kế hoạch thiết kế
Trigger:Dự án được mở và quản lý dự án được bổ nhiệm Đầu vào:
- Các yêu cầu của khách hàng
-Nghiên cứu yêu cầu thiết kế:các mẫu và mô tả;các chuẩn.các quy định,hướng dẫn,các thiết kế tương tự và có thể sử dụng lại,các công cụ.
-Nghiên cứu các đầu vào(hiệu năng và các yêu cầu chức năng;các quy định và các yêu cầu pháp lý; các yêu cầu khác),các quyết định yêu cầu chưa rõ ràng và chưa thống nhất
-Tạo kế hoạch thiết kế:Phạm vi và mục đích,các nhiệm vụ và kết quả,các gia đoạn và cột mốc,lịch trình và nguồn lực,các giao diện,các tiêu chuẩn thiết kế và tiêu chí. Đầu ra:
-Kế hoạch thiết kế được tạo và phê chuẩn:Quá trình thiết kế,nguồn lực cho thiết kế,các tools được sử dụng,lịch trình.
-Các chuẩn,mẫu và checklist được sử dụng cho thiết kế đã được thành lập.
Bước 2-Develop High Level Design
Mục đích: Để phát triển kiến trúc thiết kế
Kế hoạch cho thiết kế được phê duyệt Đầu vào:
-Nghiên cứu các tài liệu phân tích công việc và đặc tả yêu cầu người dùng -Định nghĩa các điểm chính của kiến trúc hệ thống như mô hình ky thuật,mô hình hoạt động,mô hình cơ sở dữ liệu,mô hình cấu trúc chương trình,nguyên mẫu(nếu cần)
Thiết kế dữ liệu Thiết kế các chương trình Thiết kế các giao diện Cài đặt các tool chi việc thiết kế Tạo tài liệu thiết kế kiến trúc Đầu ra:
-Các mẫu yêu cầu phần mềm
-Mô hình phần mềm,nguyên mẫu(nếu có)
-Các kết quả thiết kế chương trình
-Các kết quả thiết kế giao diện
-Các kết quả cài đặt của các tool cho việc thiết kế
-Tài liệu thiết kế kiến trúc
Bước 3-Review,Appove High Level Design
Mục đích: Để làm ro và xác nhận kiến trúc thiết kế
Kiến trúc thiết kế sẵn sàng để xem xét và phê duyệt Đầu vào:
-Tài liệu thiết kế kiến trúc
-Chuẩn,các yêu cầu thiết kế
-Chuẩn bị cho high level design review,thông báo và gửi tài liệu,các bản ghi tới người xem xét.
-Review high level design:Giải pháp thiết kế,các tool và các chuẩn,kiến trúc hệ thống,tính khả thi của quá trình thiết kế chi tiết và coding
-Phê duyệt high level design và thay đổi yêu cầu(nếu cần) Đầu ra:
-Review Report,yêu cầu thay đổi(nếu cần)
-Thiết kế kiến trúc được phê duyệt và các yêu cầu thay đổi của nó
Mục đích: Để phát triển thiết kế chi tiết
-SRS, URD,và các yêu cầu của khách hàng
-Tài liệu thiết kế kiến trúc
-Thiết kế các báo cáo
-Thiết kế các giải thuật
-Thiết kế các modul khác
-Tạo tài liệu thiết kế chi tiết Đầu ra:
-Tài liệu thiết kế chi tiết
Cung cấp các gói thiết kế cho giai đoạn tiếp theo
Các gói thiết kế là sẵn sàng để chuyển giao Đầu vào:
-Tổng quát hóa các kết quả thiết kế,xem lại các chú ý và định nghiiax thêm công việc.
-Xem xét và phê duyệt các sản phẩm thiết kế trước khi cung cấp cho khách hàng,nếu cần
-Cung cấp các sản phẩm thiết kế tới các đơn vị sản xuất,và tới khách hàng()nếu cần)
-Tạo báo cáo tóm tắt thiết kế Đầu ra:
-Các sản phầm thiết kế được cung cấp
-Báo cáo 2 tóm tắt thiết kế
Một High-Level Design cung cấp một cái nhìn tổng quan của một giải pháp,nền tảng,hệ thống,sản phẩm,dịch vụ,hoặc tiến trình.
Như một tổng quan quan trọng trong một multi-project phát triển để đảm bảo rằng mỗi hỗ trợ thiết kế thành phần sẽ tương thích với các thiết kế gần với nó.
Highest level solution design sẽ miêu tả tóm tắt tất cả các platform,hệ thống,các sản phẩm,các dịch vụ và các tiến trình mànó phụ thuộc và bao gồm mọi thay đổi quan trọng rằng cần để tạo ra chúng.
Một high-level design document sẽ thương bao gồm một biểu đồ kiến trúc high-level để mô tả các thành phần,các giao diện và các network rằng cần để xác định thêm hoặc để phát triển.
Tài liệu thiết kế chi tiết bao gồm các tài liệu dưới đây:
1.Tài liệu thiết kế màn hình
Chúng ta phải định nghĩa các item dưới đây:
Màn hình tiếp theo Danh sách các thành phần của màn hình Anh màn hình
2.Tài liệu thiết kế dữ liệu
Chúng ta phải định nghĩa các item dưới đây:
Biểu đồ quan hệ các thực thể Cấu trúc các bảng Cấc trúc các trường Cấu trúc các file Các định dạng thiết kế code 3.Tài liệu thiết kế Class
Chúng ta phải định nghĩa các item dưới đây:
Xử lý các lỗi và ngoại lệ
Gỡ lỗi,theo dõi,log
Cơ chế tối ưu hóa hiệu năngGiao diện bên ngoàiKhai báo các phương thứ
Tổng hợp quá trình học tập và công việc trong kì thực tập
Từ ngày 7/7/2021 - 10/7/2021: Thực hiện khóa học dayone của FSoft nhằm nắm bắt được các quy định về bảo mật, an ninh của công ty.
Ngày 11/7/2021: Được training trực tiếp với các anh, chị senior ở công ty: Làm quen các anh, chị đồng nghiệp, được giới thiệu và hướng dẫn cách thực hiện, mục tiêu và thời gian của khóa thực tập.
Quá trình thực tập và làm mock project:
Học cách sử dụng git và git tools trong dự án thực tế.
Git flow và best practice
Biết cách sử dụng git và git tools để quản lí mã nguồn
Biết cách sử dụng git trong dự án thực tế.
Overview về ngôn ngữ Kotlin.
Basic syntax, control flow, Lambda,
Kotlin OOP (class and interface, extension, data class, …)
Kotlin advanced concept (collection, null safety, annotation, call java from kotlin,
Automatic test với framework JUnit
Có khả năng sử dụng ngôn ngữ Kotlin.
Nắm chắc kiến thức về Kotlin OOP.
Hiểu biết về advanced concept trong Kotlin sử dụng đúng ngữ cảnh.
Có khả năng Unit test trong Kotlin.
Các pattern thường sử dụng trong android
Automated Unit Testing với Junit
Nắm được cơ bản các components chính trong android
Sử dụng service để làm 1 ứng dụng nghe nhạc cơ bản
Thiết kế giao diện cơ bản trong android
Hiểu biết cơ bản về các pattern trong android
Biết Unit Test trong android với Junit
Hình 15: Các assignment đã thực hiện được trong quá trình học Android Basic
Design Architecture (MVC, MVP, MVVM)
Inter Process Communication (IPC) trong android
Nắm cách các mô hình phổ biến để thiết kế 1 ứng dụng android. Thiết kế giao diện đẹp với Custom View và Animation.
Sử dụng Room Database để quản lí dữ liệu trong ứng dụng android. Giao tiếp giữa các module trong ứng dụng android.
Sử dụng các Jetpack component để thiết kế ứng dụng android.
Hình 16: Các assignment đã thực hiện được trong quá trình học Android Advance
Thiết kế 1 ứng dụng android cơ bản sử dụng những kiến thức đã học.
Em chọn thiết kế ứng dụng quản lý sinh viên trong trường học với những tính năng cơ bản như thêm/sửa/xóa thông tin sinh viên.
Nắm vững các kiến thức cơ bản để thiết kế ứng dụng android cơ bản.Được đánh giá có tinh thần học hỏi, kỷ luật trong công việc.
Hình 17: Project cuối khoá thực tập
Những kiến thức, kỹ năng học tập, vận dụng để hoàn thành nhiệm vụ
Hiểu biết và sử dụng được 4 thành phần chính trong android.
Một Activity được xem như một điểm tiếp xúc với người dùng Nó là một màn hình đơn với giao diện trên đó Ví dụ các bạn cài và chạy lên ứng dụng thì màn hình chạy lên các bạn sẽ thấy giao diện hiện thị cho chúng ta xem, đó là một Activity Activty giúp người dùng tương tác với hệ thống, thực hiện các chức năng cần thiết trên đó, chuyển đổi qua lại giữa các màn hình giao diện/ chức năng.
Thường thường khi sử dụng Activity chúng ta sẽ kết thừa từ lớp cha của nó là Activity ( tất nhiên hiện tại Android SDK ở các phiên bản mới đã có nhiều subActivity hỗ trợ chúng ta trong từng trường hợp thuận tiện ).
Service có chức năng giúp ứng dụng vẫn chạy được, nhưng không cần hiện thị trên giao diện (gọi là chạy ngầm bên dưới ) Ví dụ các bạn dùng các ứng nghe nhạc, mặc dù các bạn tắt ứng dụng rồi nhưng vẫn nghe được nhạc ( đó là vì nó đang chạy dưới nền /background ) Chúng ta có thể liên kết/ kết nối giữa một Activity với một service, ví dụ: khi download một file từ trên mạng, việc download thực hiện ở service, sau đó sẽ trả kết quả phần trăm download lên activity để hiện thị cho người dùng biết.
Chú ý: mặc dù service chạy ở chế độ background nhưng cần phân biệt giữa service và thread Service không phải thread, do đó tùy trường hợp mà chúng ta sử dụng và xử lý cho phù hợp để tránh trường hợp sử dụng service làm ứng dụng bị đơ/ chậm khi sử lý các luồng dữ liệu/ giao diện khác.
Khi sử dụng service chúng ta sẽ kế thừa từ lớp cha là: Service
Broadcast receiver được sử dụng trong nhiều trường hợp, ví dụ: chúng ta có thể chuyển dữ liệu từ service lên activity (ngoài sử dụng binding) chúng ta có thể sử dụng broadcast để gửi dữ liệu Hoặc trong các ứng dụng như hẹn giờ, khi đến giờ hẹn, ứng dụng sẽ sử dụng broadcast báo thức, tạo ra notification trên màn hình để báo cho người dùng biết. Khi sử dụng broadcast receiver chúng ta kế thừa từ BroadcastReceiver
Content provider quản lý các cách để ứng dụng có thể lưu trữ dữ liệu trên hệ thống Chúng ta sẽ biết cụ thể về thành phần này khi xây dựng các ứng dụng cần lưu trữ vào SQLite Ví dụ các ứng dụng từ điển, các bạn sẽ thấy dữ liệu, từ vựng chúng ta tra hiện thị, thì dữ liệu hiện thị đó được lưu trữ trong Slite và Content provider gọi để lấy ra cho người dùng xem Ngoài ra thành phần này còn thực hiện các chức năng, thêm, sửa, xóa dữ liệu…
Sử dụng những thành phần nâng cao trong android vào thiết kế ứng dụng Biết Debug và test ứng dụng Android.
Nắm được những pattern phổ biến trong android.
MVC, MVP, và MVVM là 3 mô hình thông dụng khi phát triển phần mềm Trong bài viết này, mình sẽ giới thiệu với các bạn 3 mô hình Model View Controller (MVC), Model View Presenter (MVP) và Model View View-model (MVVM) Tất cả những mô hình trên đều giúp đỡ chúng ta rất nhiều trong việc phát triển một ứng dụng dễ kết hợp, dễ kiểm thử và dễ duy trì Bài viết này mình sẽ viết trong hoàn cảnh là nền tảng Android.
Mô hình MVC chia ứng dụng ra thành 3 thành phần chính: Model, View và Controller.
Model nghĩa là các dữ liệu cần thiết để hiển thị ở View Model đại diện cho một tập hợp các lớp mô tả business logic (business model và data model) Nó cũng định nghĩa các business rules cho dữ liệu (nghĩa là cách mà dữ liệu thay đổi và được dùng)
View đại diện cho các thành phần UI như XML, HTML View sẽ hiển thị dữ liệu đã qua xử lý từ Controller Model và View tương tác với nhau qua Observer pattern.
Controller có trách nhiệm xử lý các yêu cầu (request) được gửi đến Nó sẽ xử lý các dữ liệu của người dùng qua Model và trả về kết quả ở View
Ví dụ : Áp dụng mô hình MVC cho Tic Tac Toe game, ta có luồng hoạt động: Đánh giá
MVC rất tốt trong việc phân chia model và view Chắc chắn sẽ dễ dàng test model vì nó không liên quan đến view và view không có gì nhiều để test (unit test) Tuy nhiên Controller vẫn còn nhiều hạn chế.
Mặt hạn chế của Controller
1 Khả năng kiểm thử (test) - Controller bị ràng buộc với Android API nên sẽ khó để thực hiện unit test.
2 Tính linh hoạt - Controller liên quan khá chặt chẽ với các view Nếu chúng ta thay đổi view chúng ta sẽ phải thay đổi lại ở controller.
3 Khả năng duy trì - Qua thời gian, controller sẽ ngày càng phình to ra do việc thêm code dẫn đến việc khó kiểm soát.
Mô hình MVP cũng gần giống với mô hình MVC Nó được kế thừa từ mô hình MVC, trong đó Controller được thay thế bới Presenter Mô hình này chia ứng dụng thành 3 phần chính: Model, View và Presenter
Model đại diện cho một tập hợp các lớp mô tả business logic (business model and the data model) Nó cũng định nghĩa các business rules cho dữ liệu (nghĩa là cách mà dữ liệu thay đổi và được dùng)
View là thành phần tương tác trực tiếp với người dùng như XML, Activity, fragments Nó không bao gồm bất kỳ việc xử lý logic nào.
Presenter sẽ nhận input của người dùng thông qua View, rồi xử lý dữ liệu của người dùng với sự trợ giúp của Model và trả kết quả về View Presenter giao tiếp với View qua interface Interface được định nghĩa trong lớp Presenter(với cái nó cần truyền dữ liệu) Activity/fragment hoặc các view component khác implement interface này và render dữ liệu.
Trong cấu trúc MVP, presenter thao túng model và cập nhật ở view View và Presenter tách biệt với nhau hoàn toàn và giao tiếp với nhau qua thông qua interface Vì nếu tách riêng từng phần ở view sẽ dễ dàng cho việc kiểm thử ứng dụng ở MVP hơn so với mô hình MVC.
Những kiến thức và kỹ năng cần bổ sung,cần học hỏi thêm để đáp ứng được nhu cầu thực tế
Qua việc thực tập và được tham gia vào một dự án thực tế, em thấy còn rất nhiều kiến thức và kỹ năng cần học hỏi.Cần trau dồi kiến thức về phân tích, thiết kế, đặc biệt về cách thiết kế 1 ứng dụng Android để có thể nâng cao tốc độ và chất lượng khi hoàn thành công việc Bên cạnh đó em cảm thấy bản thân cũng cần trau dồi và học hỏi thêm về kỹ năng như làm việc nhóm, kỹ năng lập tài liệu,báo cáo… Ý kiến đánh giá:
Người hướng dẫn Hà Nội, ngày tháng năm 2021 Đại diện đơn vị thực tập
