HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA KỸ THUẬT ĐIỆN TỬ 1

BÁO CÁO BÀI TẬP LỚN MÔN THIẾT KẾ ĐIÊN TỬ TIÊN TIẾN
ĐỀ TÀI QUY TRÌNH THIẾT KẾ HỆ THÔNG (SDLC)

Giảng viên: Lương Công Duẩn

Nhóm thực hiện: 10
Thành Viên Nhóm: Đinh Văn Bắc-B10DCDT019
Đinh Tiến Danh-B19DCDT027
Nguyễn Trọng Dũng-B19DCDT031
Đoàn Quyết Thắng-B19DCDT227
Nguyễn Bá Minh -B19DCDT143

Hà Nội-2023

1
 MỤC LỤC
LỜI MỞ ĐẦU........................................................................................................................................3
Chương I. Tìm hiểu về quy trình thiết kế hệ thống (SDLC)................................................................4
1.Tìm hiểu về SDLC...........................................................................................................................4
1.1.KHÁI NIỆM............................................................................................................................4
1.2.LỢI ÍCH CỦA SDLC..............................................................................................................4
1.3.CÁC GIAI ĐOẠN SDLC.........................................................................................................4
2.Các phương pháp SDLC..................................................................................................................8
2.1.MÔ HÌNH THÁC NƯỚC (WATERFALL)............................................................................8
2.2.PHƯƠNG PHÁP AGILE........................................................................................................8
2.3.PHƯƠNG PHÁP LẶP LẠI (ITERATIVE)............................................................................8
2.4.PHƯƠNG PHÁP HÌNH CHỮ V (V-SHAPED).....................................................................9
2.5.PHƯƠNG PHÁP XOẮN ỐC (SPIRAL).................................................................................9
2.6.PHƯƠNG PHÁP BIG BANG.................................................................................................9
2.7.PHƯƠNG PHÁP DEVOPS....................................................................................................9
Chương II .Tìm hiểu về phương pháp Agile......................................................................................10
1.Khái niệm......................................................................................................................................10
2.Tổng quan về Agile........................................................................................................................10
3.Bốn tôn chỉ cần tuân thủ trong phương pháp Agile.......................................................................11
4.Nguyên tắc quan trọng trong Agile................................................................................................11
5.Đặc trưng của Agile.......................................................................................................................12
6.Mô hình SDLC Agile với Truyền thống.........................................................................................13
7.Mô hình Agile - Ưu và nhược điểm...............................................................................................13
7.1.NHỮNG ƯU ĐIỂM CỦA MÔ HÌNH AGILE:....................................................................13
7.2.NHỮNG NHƯỢC ĐIỂM CỦA MÔ HÌNH AGILE:............................................................14
8.Một quy trình Agile hoàn chỉnh.....................................................................................................14
8.1.AGILE PHÙ HỢP VỚI DỰ ÁN NHƯ THẾ NÀO?................................................................15
8.2.THÁCH THỨC KHI ÁP DỤNG AGILE:...............................................................................15
8.3.CÁC MẸO QUẢN LÝ DỰ ÁN DỄ DÀNG HƠN VỚI MÔ HÌNH AGILE..........................16
9.Kết luận........................................................................................................................................18
Chương III.Áp dụng Agile vào thực tế..............................................................................................18
1.Lập bảng kế hoach........................................................................................................................18
2.Thiết kế.........................................................................................................................................20
3.Kiểm tra và đánh giá.....................................................................................................................22
4.Triển khai sản phẩm.....................................................................................................................24
5.Bảo trì...........................................................................................................................................25
6.Một số hình ảnh liên quan đến dự án..........................................................................................26

2
 LỜI MỞ ĐẦU
Systems development life cycle-Vòng đời phát triển phần mềm (SDLC) là quy trình
hiệu quả về chi phí và thời gian mà các nhóm phát triển sử dụng để thiết kế và xây
dựng phần mềm chất lượng cao. Mục tiêu của SDLC là giảm thiểu rủi ro dự án thông
qua việc lập kế hoạch trước để phần mềm đáp ứng mong đợi của khách hàng trong giai
đoạn sản xuất và hơn thế nữa. Phương pháp này vạch ra một loạt các bước chia quy
trình phát triển phần mềm thành các nhiệm vụ mà bạn có thể chỉ định, hoàn thành và
đo lường. Việc phát triển phần mềm có thể gặp khó khăn trong việc quản lý do thay
đổi yêu cầu, nâng cấp công nghệ và cộng tác liên chức năng. Phương pháp vòng đời
phát triển phần mềm (SDLC) cung cấp một khung quản lý có hệ thống với các sản
phẩm cụ thể ở mọi giai đoạn của quy trình phát triển phần mềm. Do vậy, tất cả các bên
liên quan đồng ý trước về mục tiêu và yêu cầu phát triển phần mềm, đồng thời cũng có
kế hoạch để đạt được những mục tiêu đó.

3
Chương I. Tìm hiểu về quy trình thiết kế hệ thống (SDLC)
1.Tìm hiểu về SDLC
1.1.Khái niệm
SDLC là từ viết tắt của Software Development Life Cycle (vòng đời phát
triển phần mềm). SDLC là một quy trình phát triển phần mềm với chất lượng
cao nhất và chi phí thấp nhất trong thời gian ngắn nhất có thể.
1.2.Lợi ích của SDLC.
SDLC cung cấp một cái nhìn tổng thể về toàn bộ hệ thống, tài nguyên, dòng
thời gian và mục tiêu của một dự án phầm mềm. Các nhà phát triển phần mềm
hiểu họ nên xây dựng những gì và tại sao. Các lý do chính tại sao SDLC là cần
thiết để phát triển một hệ thống phần mềm:
 Đo lường sự tăng trưởng và chi phí của hệ thống đã phát triển.
 Tăng cường kiểm soát và giám sát các dự án quan trọng hoặc phức tạp.
 Đảm bảo độ tin cậy và chất lượng của giải pháp đã phát triển.
 Cung cấp tài liệu mở rộng về hệ thống.
 Nếu một thành viên chính của dự án rời đi, một thành viên mới có thể
tiếp tục nơi họ đã dừng lại.
 Đảm bảo bàn giao phần mềm chính xác và kịp thời cho khách hàng.
 Cải thiện tốc độ phát triển phần mềm
1.3.Các giai đoạn SDLC
1.3.1. Thu thập và phân tích thông tin (Requirement Analysis)
Giai đoại đầu tiên của SDLC là về việc quyết định những gì bạn sẽ phát triển. Có thể
nói giai đoạn này là quan trọng bật nhất của cả quy trình SDLC. Nếu bạn đang phát
triển cho khách hàng, giai đoạn này có thể sẽ bao gồm các cuộc họp để thảo luận về
nhu cầu, mục tiêu và kỳ vọng của họ. Nếu bạn đang phát triển một phần mềm nội bộ,
các việc có thể bao gồm phân tích thị trường hoặc phân tích đối thủ cạnh tranh, phỏng
vấn khách hàng và kiểm tra các mục tiêu của công ty bạn. Ở cấp cao, bạn cần biết
những vấn đề bạn đang cố gắng giải quyết và cách giải quyết.
Kết quả của giai đoạn này là tài liệu đặc tả yêu cầu phần mềm (Software Requirements
Specification hay SRS), đóng vai trò là điểm khởi đầu cho giai đoạn phát triển tiếp
theo. Điều quan trọng cần lưu ý là giai đoạn đặc tả và phân tích yêu cầu chỉ tập trung
vào những gì hệ thống phần mềm nên làm chứ không phải vào cách nó nên được thực
hiện. Nghĩa là các chi tiết triển khai không được phép ảnh hưởng đến giai đoạn
này. Yêu cầu phần mềm có thể được phân thành hai loại: yêu cầu chức năng và yêu
cầu phi chức năng, và SRS cần bao gồm cả hai loại yêu cầu này.
1.3.2. Lập kế hoạch (Planning hay Defining)
Giai đoạn này là đi tìm câu trả lời cho câu hỏi “Chúng ta muốn gì?”

4
Thông thường, bạn thực hiện quá trình lập kế hoạch sau khi phân tích yêu cầu sau khi
bạn đã có đầy đủ dữ liệu và chọn những gì cần phát triển.  Trong giai đoạn SDLC thứ
hai này chúng ta cần xác định một số yếu tố:
 Ai sẽ lãnh đạo dự án
 Kết quả đầu ra hoặc triển khai dự kiến
 Số lượng các developer cần thiết cho dự án
 Dự án sẽ mất khoảng bao nhiêu thời gian
 Ngân sách cần thiết cho dự án
 Mọi cân nhắc về dự án cụ thể khác
Kết quả đầu ra của giai đoạn lập kế hoạch bao gồm: kế hoạch dự án, thời gian thực
hiện chi tiết, ước tính chi phí và các yêu cầu mua sắm. Các tài liệu trong giai đoạn này
thường bao gồm:
 Project Management Plan
 Project Charter (điều lệ) document

1.3.3 Thiết kế (Designing)

Giai đoạn này chúng ta đi tìm câu trả lời cho câu hỏi “Làm thế nào chúng xây
được những gì chúng ta muốn?”
Giai đoạn thứ ba của SDLC tập trung vào việc thiết kế phần mềm mà bạn sẽ phát triển,
bao gồm:
Kiến trúc: 
Bạn sử dụng ngôn ngữ lập trình nào để xây dựng sản phẩm của mình? Các phương
pháp tốt nhất trong ngành mà bạn đang xây dựng là gì? Cũng bao gồm các câu hỏi
liên quan đến việc sử dụng các mẫu.
Giao diện người dùng: 
Bạn mong đợi người dùng tiềm năng sẽ tương tác với sản phẩm như thế nào? Làm
thế nào bạn sẽ làm cho điều đó dễ dàng hơn cho họ?
Nền tảng: 
Sản phẩm của bạn sẽ chạy trên nền tảng gì? Trong giai đoạn này, một nhà phát triển
trò chơi sẽ tự hỏi họ sẽ xuất bản bảng điều khiển nào, trong khi một nhà phát triển
thiết bị di động sẽ quyết định xem họ sẽ tạo ứng dụng cho Apple, Android hay cả
hai.
Lập trình: 
Bạn đã tìm ra ngôn ngữ lập trình, nhưng bây giờ bạn sẽ làm thế nào để vượt qua
những thách thức lập trình trong quá trình phát triển?

5
 Liên kết: 
Sản phẩm của bạn sẽ phải giao tiếp với những nội dung nào? Một máy chủ trung
tâm? Các ứng dụng khác? Làm thế nào điều này sẽ xảy ra?
Bảo mật: 
Bạn sẽ bảo vệ sản phẩm của mình như thế nào trước những nguy cơ tiềm ẩn? Bạn
có phải tuân theo các yêu cầu bảo mật nhất định không? Bạn có được truy cập vào
thông tin người dùng nhạy cảm cần được bảo vệ không? Việc thiết kế này gần giống
như việc tổng hợp các phương án kiến trúc và thiết kế nội thất của một ngôi nhà
mới trước khi bạn xây dựng nó.

Kết quả của giai đoạn thiết kế:

Vào cuối giai đoạn này, tài liệu thiết kế (Software Design Document – SDD) được
hoàn thành. SDD sẽ được xem xét bởi tất cả các bên liên quan (stackholders) và dựa
trên các thông số khác nhau như đánh giá rủi ro, tính lâu dài của phầm mềm, các
mô-đun thiết kế, hạn chế về ngân sách và thời gian, phương pháp thiết kế tốt nhất
được lựa chọn cho sản phẩm…

1.3.4. Phát triển (Development)

Là giai đoạn “Tạo ra những gì chúng ta muốn”
Giai đoạn phát triển là giai đoạn mà các developer thực sự viết code và xây dựng ứng
dụng theo các tài liệu thiết kế và các thông số kỹ thuật đã vạch ra, sử dụng ngôn ngữ
lập trình và framework đã được chọn. Các developer sẽ tuân theo mọi nguyên tắc viết
code của công ty và sử dụng các công cụ khác nhau như trình biên dịch, trình gỡ lỗi và
trình thông dịch. Các nhiệm vụ được chia thành các đơn vị hoặc mô-đun và được phân
bổ cho các nhà phát triển cụ thể.
Kết quả của giai đoạn phát triển: Các chức năng của phần mềm mà chúng ta cần xây
dựng, đạt được mục tiêu và kế hoạch đã đề ra.
1.3.5. Kiểm thử (Testing)
Giai đoạn này tập trung vào việc kiểm tra phần mềm để đảm bảo tính hoàn thiện, chất
lượng và tính ổn định của phần mềm. Nó bao gồm kiểm thử chức năng, kiểm thử hệ
thống và kiểm thử chấp nhận từ khách hàng.
Khi code hoàn tất, quá trình kiểm tra bắt đầu và các mô-đun được đánh giá và kiểm tra
để tránh bất kỳ lỗi nào. Phần mềm đã xây dựng được xem xét toàn diện trong quá trình
này và bất kỳ vấn đề nào được tìm thấy đều được giao cho các developers sửa chữa,
thay đổi.
Kiểm tra lại và kiểm tra hồi quy được tiến hành cho đến khi phần mềm đúng như kế
hoạch của người sử dụng. Tester thường tham khảo tài liệu SRS để đảm bảo phần
mềm phù hợp với tiêu chuẩn của khách hàng hay yêu cầu.
6
Kết quả của giai đoạn kiểm thử:

Sản phẩm hoàn thiện hơn sau các lỗi được chỉnh sửa hoặc các yêu cầu còn thiếu được
phát triển
 Testing report.
 User Acceptant Test…
1.3.6 Triển khai (Deployment)
Giai đoạn này tập trung vào việc triển khai phần mềm đã hoàn thành vào môi
trường thực tế. Nó bao gồm việc cài đặt phần mềm, đào tạo người dùng và hỗ trợ cho
việc triển khai phần mềm.
Ở giai đoạn này, mục tiêu là triển khai phần mềm tới môi trường production để người
dùng có thể bắt đầu sử dụng. Tuy nhiên, nhiều công ty chọn triển khai phần mềm qua
các môi trường triển khai khác nhau như môi trường thử nghiệm (testing) hoặc môi
trường dàn dựng (staging).

Điều này cho phép bất kỳ bên liên quan nào có thể trải nghiệm phần mềm một cách an
toàn trước khi đưa ra sử dụng chính thức. Bên cạnh đó, điều này cho phép mọi sai sót
cuối cùng được phát hiện và chỉnh sửa trước khi phát hành.

Kết quả của giai đoạn triển khai:

Giai đoạn triển khai hoàn thành khi phần mềm đã được đưa vào hoạt động thành công
và thỏa mãn tất cả các yêu cầu kinh doanh và kỹ thuật thông qua việc xem xét và ký
tên của các bên liên quan trong Implementation Report (báo cáo triển khai), và
Maintenance Manual (Sổ tay Bảo trì) đã được giao cho mhóm bảo trì phần mềm,
Training Manual (tài liệu đào tạo) đã được chuyển cho trainer/user và Tài liệu hướng
dẫn sử dụng đã được chuyển đến người sử dụng.

1.3.7. Bảo trì

Giai đoạn này tập trung vào việc bảo trì và nâng cấp phần mềm để đảm bảo tính ổn
định và tính bảo mật của phần mềm. Nó bao gồm việc sửa lỗi, cập nhật tính năng và
tối ưu hóa hiệu suất của phần mềm.
Diễn ra sau khi triển khai một sản phẩm trên một môi trường production. Bất kỳ vấn
đề nào xuất hiện cần được khắc phục hoặc cải tiến sẽ được đánh giá và triển khai.
Tóm lại, các giai đoạn của SDLC đóng vai trò quan trọng trong quá trình phát triển
phần mềm. Quy trình SDLC giúp đảm bảo rằng phần mềm được phát triển đáp ứng
các yêu cầu kỹ thuật và kinh doanh, đảm bảo chất lượng và tính ổn định của phần.

7
2.Các phương pháp SDLC
2.1.Mô hình thác nước (Waterfall)
Mô hình thác nước là một mô hình phát triển phần mềm theo hướng tuần tự,
trong đó các hoạt động của quá trình phát triển phần mềm được thực hiện theo một
trình tự cụ thể, từ giai đoạn này sang giai đoạn khác mà không quay lại giai đoạn
trước đó. Mô hình này được gọi là "thác nước" vì dữ liệu và hoạt động chảy tuần tự
từ trên xuống dưới, giống như nước chảy trong một dãy thác.
Là mô hình lâu đời nhất trong các phương pháp SDLC. Nó tuyến tính và đơn giản,
yêu cầu phải hoàn thành một giai đoạn của dự án trước khi chuyển sang giai đoạn
tiếp theo. Mỗi giai đoạn có một kế hoạch dự án riêng biệt và lấy thông tin từ giai
đoạn trước để tránh các vấn đề tương tự.
Nhược điểm là dễ bị trì hoãn bởi các chi tiết nhỏ chưa được hoàn thiện trong một
giai đoạn nào đó.
2.2.Phương pháp Agile.
Mô hình Agile là một phương pháp phát triển phần mềm linh hoạt và nhạy cảm với sự
thay đổi, dựa trên việc làm việc đội nhóm liên tục, tương tác với khách hàng hoặc
người dùng cuối, và học hỏi từ kinh nghiệm để cải thiện liên tục. Agile có các nguồn
gốc từ "Tuyên bố Agile" (Agile Manifesto), là một bản tuyên bố định hướng phát triển
phần mềm linh hoạt, được công bố vào năm 2001 bởi một nhóm các chuyên gia phát
triển phần mềm.
Mô hình Agile tập trung vào việc tạo ra giá trị cho khách hàng hoặc người dùng cuối,
đáp ứng nhanh chóng với sự thay đổi của yêu cầu, thường xuyên kiểm tra và đánh giá
kết quả, và tích cực hợp tác giữa các thành viên trong đội nhóm. Mô hình Agile được
thực hiện dưới dạng các chu kỳ ngắn gọi là "Sprint" hoặc "Iteration", trong đó các hoạt
động phát triển phần mềm được thực hiện theo một lộ trình linh hoạt, đánh giá liên tục
và điều chỉnh theo phản hồi từ khách hàng hoặc người dùng.
Hạn chế: Quá chú trọng vào tương tác với khách hàng có thể dẫn dự án đi sai hướng
trong một số trường hợp.
2.3.Phương pháp lặp lại (Iterative)
Phương pháp lặp đi lặp lại liên quan đến việc nhanh chóng tạo ra một phiên bản của
phần mềm và sau đó cải tiến nó lặp đi lặp lại trong các phiên bản tiếp theo. Bạn có thể
phát triển nhiều phiên bản trước khi bạn nhận được sản phẩm hoàn thiện. Điều đó làm
cho phương pháp này hơi khó để vạch ra trong SDLC, nhưng nó vẫn là một lựa chọn
ưu tiên cho các nhóm nhỏ, phát triển nhanh.Phương pháp này có vẻ tương tự như
Agile, nhưng nó có một vài điểm khác biệt. Đầu tiên, phương pháp lặp lại không liên
quan đến khách hàng bên ngoài trong các giai đoạn khác nhau. Ngoài ra, phạm vi của
mỗi lần lặp lại là cố định, tương tự như các yêu cầu trong mô hình thác nước.

8
2.4.Phương pháp hình chữ V (V-shaped)
Phương pháp luận này tương tự như mô hình thác nước; nó thể hiện sự phụ thuộc
của từng giai đoạn trong SDLC của bạn. Sự khác biệt chính là chúng được biểu
diễn dưới dạng hình chữ V chứ không phải là mô hình tuyến tính. Mọi giai đoạn
dẫn đến việc triển khai – thực hiện – sản phẩm phần mềm mà bạn đang làm việc
dẫn đến nhánh đầu tiên của V. Triển khai là một giai đoạn phẳng ngắn ở phía dưới,
trước khi dẫn đến kiểm tra, xác minh và bảo trì liên tục trên nhánh bên kia của chữ
V.Phương pháp luận này hoạt động tốt cho các dự án đòi hỏi nhiều sự kiểm soát và
có các yêu cầu được xác định rõ ràng và không thay đổi.

2.5.Phương pháp xoắn ốc (spiral)

Phương pháp tiếp cận Xoắn ốc (spiral) có thể là phương pháp phức tạp nhất trong
số các phương pháp SDLC nhưng cũng là phương pháp linh hoạt nhất. Hãy tưởng
tượng một hình xoắn ốc lặp lại trong đó mỗi vòng lặp đại diện cho một giai đoạn
của dự án của bạn. Trong phương pháp xoắn ốc, không phải mọi dự án đều có số
vòng lặp giống nhau. Khi bắt đầu mỗi vòng lặp hoặc giai đoạn, nhóm phải xem xét
lại các mục tiêu và rủi ro của dự án, phát triển phiên bản tiếp theo của sản phẩm,
sau đó xem xét và lập kế hoạch cho giai đoạn tiếp theo. Phương pháp xoắn ốc thậm
chí có thể xác định rằng cách tiếp cận Waterfall hoặc Agile là cần thiết cho các
vòng lặp cụ thể.

Bởi vì nó rất năng động và linh hoạt, việc kết hợp Spiral vào một SDLC có thể là
một thách thức. Bạn cần phải biết rõ ai phụ trách từng dự án, cách xác định số
lượng vòng lặp và giai đoạn nào cần được lặp lại.

2.6.Phương pháp Big Bang

Mô hình Big Bang cực kỳ linh hoạt và không tuân theo một quy trình hoặc thủ tục
nghiêm ngặt. Nó thậm chí còn không có kế hoạch chi tiết. Big Bang yếu được sử dụng
để phát triển các ý tưởng rộng khi khách hàng hoặc khách hàng không chắc chắn
những gì họ muốn.Đầu ra của phương pháp này có thể gần hơn hoặc xa so với những
gì khách hàng mong muốn. Mô hình này chỉ được sử dụng cho các dự án nhỏ. Không
có đội thử nghiệm và không có thử nghiệm chính thức nào được thực hiện, và đây có
thể là một nguyên nhân dẫn đến sự thất bại của dự án.

2.7.Phương pháp DevOps

DevOps là phương pháp mới nhất. DevOps mang đến sự kết hợp giữa phát triển (Dev)
và vận hành (Ops) ở tất cả các giai đoạn của quy trình SDLC. Sự hợp tác và chia sẻ
trách nhiệm này giúp đảm bảo rằng sản phẩm được phát triển vận hành tốt trong quá
trình phát triển.Trong mô hình DevOps, các nhóm Nhà phát triển và Vận hành làm
việc cùng nhau chặt chẽ để đẩy nhanh sự đổi mới và triển khai các chức năng và sản
phẩm phần mềm chất lượng cao hơn, đáng tin cậy hơn. Cập nhật cho các sản phẩm là
9
nhỏ nhưng thường xuyên. Kỷ luật, phản hồi liên tục và cải tiến quy trình cũng như tự
động hóa các quy trình phát triển thủ công là tất cả các điểm nổi bật của mô hình
DevOps.

Chương II .Tìm hiểu về phương pháp Agile.

1.Khái niệm

Agile (viết tắt của Agile Software Development) có nghĩa là phương thức phát triển
phần mềm linh hoạt, được ứng dụng trong quy trình phát triển phần mềm với mục tiêu
là đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

2.Tổng quan về Agile

Mô hình SDLC Agile là sự kết hợp của các mô hình quy trình Interative và gia tăng,
tập trung vào khả năng thích ứng của quy trình và sự hài lòng của khách hàng bằng
cách cung cấp nhanh chóng sản phẩm phần mềm đang hoạt động. Phương pháp Agile
chia sản phẩm thành các bản dựng nhỏ gia tăng. Các bản dựng này được cung cấp
trong các lần lặp lại. Mỗi lần lặp lại thường kéo dài từ khoảng một đến ba tuần. Mỗi
lần lặp lại liên quan đến các nhóm chức năng chéo làm việc đồng thời trên các lĩnh vực
khác nhau như:
 Lập kế hoạch
 Phân tích yêu cầu
 Thiết kế
 mã hóa
 Kiểm tra đơn vị và
 Kiểm tra chấp nhận.
Vào cuối quá trình lặp lại, một sản phẩm hoạt động được hiển thị cho khách hàng và
các bên liên quan quan trọng.
Đây là một minh họa đồ họa của Mô hình Agile:

10
Quá trình suy nghĩ Agile đã bắt đầu sớm trong quá trình phát triển phần mềm và bắt
đầu trở nên phổ biến theo thời gian do tính linh hoạt và khả năng thích ứng của nó.
Các phương pháp Agile phổ biến nhất bao gồm Rational Unified Process (1994),
Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software
Development, Feature Driven Development và Dynamic Systems Development
Method (DSDM) (1995). Chúng hiện được gọi chung là Phương pháp Agile, sau khi
Tuyên ngôn Agile được xuất bản năm 2001.
3.Bốn tôn chỉ cần tuân thủ trong phương pháp Agile.
 
 Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ: Trọng tâm đặt lên
con người, xây dựng tương tác và hỗ trợ giữa các thành viên trong nhóm. Những
thành viên có năng lực, chịu tương trợ nhau trong công việc sẽ mang đến thành
công cho dự án.
 Sản phẩm dùng được tốt hơn tài liệu đầy đủ: Tập trung thời gian để làm ra phần
mềm hoàn chỉnh đáp ứng hoàn hảo yêu cầu khách hàng.

 Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng: Hiểu được khách
hàng cần gì để tư vấn và điều chỉnh sản phẩm thay vì chỉ dựa vào các điều khoản
trong hợp đồng.
 Phản hồi thay đổi hơn là bám sát kế hoạch: Agile khuyến khích thích nghi với
sự thay đổi, đó có thể là thay đổi về công nghệ, nhân sự, deadline, ...
 
4.Nguyên tắc quan trọng trong Agile.
 
 Đáp ứng toàn diện nhu cầu khách hàng thông qua việc giao hàng sớm và sản
phẩm có giá trị.
 Thay đổi yêu cầu được chào đón, thậm chí là rất muộn trong quá trình phát triển.
 Giao phần mềm chạy được cho khách hàng một cách thường xuyên.
 Nhà kinh doanh và các kỹ sư phần mềm cần làm việc cùng nhau trong suốt dự
án.
 Xây dựng dự án xung quanh các cá nhân có động lực. Cung cấp sự hỗ trợ cần
thiết, môi trường làm việc và niềm tin để hoàn thành công việc.
 Trao đổi trực tiếp là cách truyền đạt thông tin hiệu quả nhất.
 Thước đo chính của tiến độ là phần mềm chạy tốt.
 Phát triển liên tục và bền vững.
 Cải tiến sự linh hoạt bằng cách quan tâm đến kỹ thuật và thiết kế.
 Nghệ thuật tối đa hóa lượng công việc chưa xong - Sự đơn giản là cần thiết.
 Nhóm tự tổ chức
 Thích ứng thường xuyên với những thay đổi.

11
5.Đặc trưng của Agile
 
 Tính lặp (Iterative): Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại
(Iteration hoặc Sprint), thường có khung thời gian ngắn (từ 1-4 tuần). Trong mỗi
phân đoạn, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế
hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử để cho ra các phần nhỏ
của sản phẩm.
 Tính tăng trưởng và tiến hóa (Incremental & Evolutionary): Cuối các phân
đoạn, nhóm cho ra các phần nhỏ của sản phẩm cuối cùng, thường là đầy đủ, có
khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng. Theo thời gian,
phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy,
lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. 
 Tính thích nghi (adaptive): Do các phân đoạn chỉ kéo dài trong một khoảng thời
gian ngắn và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi
trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định
hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp.
 Nhóm tự tổ chức và liên chức năng: Các cấu trúc nhóm này tự phân công công
việc mà không dựa trên các mô tả cứng về chức danh hay làm việc dựa trên một
sự phân cấp rõ ràng trong tổ chức. Nhóm tự tổ chức đã đủ các kĩ năng cần thiết
để có thể được trao quyền tự ra quyết định, tự quản lí và tổ chức lấy công việc
của chính mình để đạt được hiệu quả cao nhất.
 Quản lý tiến trình thực nghiệm (Empirical Process Control): Các nhóm Agile ra
các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các
tiền giả định. Agile rút ngắn vòng đời phản hồi để dễ dàng thích nghi và gia tăng
tính linh hoạt nhờ đó có thể kiểm soát được tiến trình, và nâng cao năng suất lao
động.
 Giao tiếp trực diện (face-to-face communication): Agile không phản đối việc tài
liệu hóa, nhưng đánh giá cao hơn việc giao tiếp trực diện thay vì thông qua giấy
tờ. Agile khuyến khích nhóm phát triển trực tiếp nói chuyện để hiểu rõ hơn về
cái khách hàng thực sự cần. Trong giao tiếp giữa nội bộ nhóm, Agile khuyến
khích trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng
nhau triển khai thành các chức năng theo yêu cầu.
 Phát triển dựa trên giá trị (value-based development): Một trong các nguyên tắc
cơ bản của agile là “sản phẩm chạy tốt chính là thước đo của tiến độ”. Nhóm
Agile thường cộng tác trực tiếp và thường xuyên với khách hàng để biết yêu cầu
nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án. 

12
6.Mô hình SDLC Agile với Truyền thống
Agile dựa trên các phương pháp phát triển phần mềm thích ứng, trong khi các mô hình
SDLC truyền thống như mô hình thác nước dựa trên phương pháp dự đoán. Các nhóm
dự đoán trong các mô hình SDLC truyền thống thường làm việc với kế hoạch chi tiết
và có dự báo đầy đủ về các nhiệm vụ và tính năng chính xác sẽ được phân phối trong
vài tháng tới hoặc trong vòng đời sản phẩm.
Các phương pháp dự đoán hoàn toàn phụ thuộc vào việc phân tích yêu cầu và lập kế
hoạch được thực hiện vào đầu chu kỳ. Bất kỳ thay đổi nào được kết hợp đều trải qua
quá trình quản lý và ưu tiên kiểm soát thay đổi nghiêm ngặt.
Agile sử dụng cách tiếp cận thích ứng khi không có kế hoạch chi tiết và chỉ có sự rõ
ràng về các nhiệm vụ trong tương lai đối với những tính năng cần được phát triển. Có
sự phát triển theo định hướng tính năng và nhóm thích ứng linh hoạt với các yêu cầu
thay đổi của sản phẩm. Sản phẩm được thử nghiệm rất thường xuyên, thông qua các
lần lặp lại phát hành, giảm thiểu rủi ro xảy ra bất kỳ lỗi nghiêm trọng nào trong tương
lai.
Tương tác với khách hàng là xương sống của phương pháp Agile này và giao tiếp cởi
mở với tài liệu tối thiểu là những đặc điểm tiêu biểu của môi trường phát triển
Agile. Các nhóm nhanh nhẹn hợp tác chặt chẽ với nhau và thường ở cùng một vị trí
địa lý.

7.Mô hình Agile - Ưu và nhược điểm

Gần đây, các phương pháp Agile đang được chấp nhận rộng rãi trong thế giới phần
mềm. Tuy nhiên, phương pháp này có thể không phải lúc nào cũng phù hợp với tất cả
các sản phẩm. Dưới đây là một số ưu và nhược điểm của mô hình Agile.
7.1. Những ưu điểm của mô hình Agile:
 Thực hiện thay đổi dễ dàng: Bởi vì dự án được chia thành các phần nhỏ, riêng
biệt, không phụ thuộc lẫn nhau, nên những thay đổi được thực hiện rất dễ dàng,
ở bất kỳ giai đoạn nào của dự án.
 Không cần phải nắm mọi thông tin ngay từ đầu: Phù hợp với những dự án chưa
xác định được mục tiêu cuối cùng rõ ràng, vì việc này không quá cần thiết trong
giai đoạn đầu. 
 Bàn giao nhanh hơn: Việc chia nhỏ dự án cho phép đội ngũ có thể tiến hành
kiểm tra theo từng phần, xác định và sửa chữa vấn đề nhanh hơn, nhờ đó việc
bàn giao công việc sẽ nhất quán và thành công hơn.
 Chú ý đến phản hồi của khách hàng và người dùng: Cả khách hàng và người
dùng cuối đều có cơ hội để đóng góp các ý kiến và phản hồi, từ đó họ sẽ có ảnh
hưởng một cách mạnh mẽ và tích cực tới sản phẩm cuối cùng.

13
  Cải tiến liên tục: Agile khuyến khích thành viên trong đội ngũ làm việc và
khách hàng cung cấp phản hồi của mình, khi đó các giai đoạn khác nhau của sản
phẩm cuối có thể được kiểm tra và cải thiện lại nhiều lần nếu cần.
7.2. Những nhược điểm của mô hình Agile:
 
 Khó lên kế hoạch dự án: Khá là khó để xác định rõ ràng thời gian bàn giao sản
phẩm cuối cùng, vì dự án được chia nhỏ thành các phần khác nhau và mỗi phần
lại có thời gian bàn giao riêng biệt. 
 Bắt buộc phải hướng dẫn và đào tạo chi tiết: Phương pháp Agile phức tạp hơn
nhiều so với phương pháp truyền thống. Họ sẽ cần phải trải qua đào tạo, hướng
dẫn thì mới có thể nắm được phương pháp một cách rõ ràng, đặc biệt là thời gian
đầu.
 Ít tài liệu hướng dẫn: Vì Agile thay đổi rất nhiều nên các tài liệu thích hợp cũng
thường bị bỏ qua, vì không xác định rõ được kỳ vọng và thành phẩm ngay từ
đầu. Mặc dù tài liệu không phải là yếu tố quan trọng nhất, nhưng chúng vẫn rất
cần thiết.
 Bắt buộc phải hợp tác để dự án thành công: Điều này đòi hỏi một sự cam kết về
thời gian từ cả hai bên trong suốt thời gian của dự án mà các cấu trúc quản lý dự
án khác không luôn yêu cầu. Phải có sự tham gia tích cực của người dùng và tiếp
tục cộng tác để nó hoạt động.
 Chi phí cao: Chi phí thực hiện theo phương pháp Agile thường hơn một chút so
với các phương pháp phát triển khác.

8. Một quy trình Agile hoàn chỉnh.

14
 
Các giai đoạn phát triển của sản phẩm sẽ được chia nhỏ ra thành những phần tăng
trưởng cụ thể mà người dùng có thể tương tác được. Nhờ đó sản phẩm sẽ có được phản
hồi cần thiết để tránh khỏi những vấn đề nghiêm trọng và được cải tiến tốt hơn.
Thêm vào đó, quy trình quản lý sản phẩm có tính chất lặp lại này còn giúp cho cả nhóm
có thể chuyển sang một phần tăng trưởng khác trong khi những vấn đề của phần tăng
trưởng hiện tại đang được giải quyết.
8.1. Agile phù hợp với dự án như thế nào?
Agile phù hợp với các dự án đòi hỏi sự linh hoạt và có mức độ phức tạp hoặc không
chắc chắn. Chẳng hạn, một sản phẩm hoặc dịch vụ chưa từng được nhóm xây dựng.
Agile được sinh ra trong lĩnh vực phát triển phần mềm. Các giai đoạn trong mô hình
Agile phù hợp với phát triển và kiểm thử phần mềm. Tuy nhiên ngày nay, triết lí Agile
đã vượt xa khỏi khu vực truyền thống của mình và đóng góp sự thay đổi trong cách
thức làm việc, quản lí, sản xuất ở bất kỳ ngành công nghiệp hoặc kinh doanh nào như
sản xuất, dịch vụ, sales, marketing, giáo dục và đạt được hiệu quả cao.
Tuy nhiên, không phải doanh nghiệp nào cũng phù hợp với mô hình Agile. Để áp dụng
thành công mô hình này cần một số điều kiện tiên quyết trong tổ chức: 
 Thứ nhất, các thành viên phối hợp, giao tiếp hiệu quả trong nội bộ. Kỹ năng giao
tiếp tốt giúp nhóm làm việc thấu hiểu khách hàng, hợp tác tốt với nhau đảm bảo
chất lượng và tốc độ. 
 Thứ hai, tính tự chủ của mỗi thành viên phải được đảm bảo để các nhóm tự quản lý
có thể vận hành một cách chủ động, trơn tru thay vì chỉ tuân thủ theo chỉ dẫn cấp
trên như trong các mô hình truyền thống. 
 Thứ ba, các hoạt động được module hóa thông qua những nhóm liên chức năng.
Những nhóm này có khả năng làm việc với tốc độ và chất lượng cao, với khách
hàng là trung tâm
 8.2. Thách thức khi áp dụng Agile:
 Thực tế có những doanh nghiệp đã áp dụng Agile từ 5-7 năm nhưng thực sự vẫn chưa
đạt yêu cầu và nhìn chung phần lớn vẫn trong tình trạng “bình mới mà rượu cũ”. Các
đội dự án vẫn muốn áp dụng Agile, tuy nhiên có nhiều đội chỉ áp dụng Agile để né
tránh hệ thống quy trình phức tạp của doanh nghiệp hay khối lượng tài liệu (document)
khổng lồ của dự án.
 

15
 
Điều này là không lạ, vì mặc dù Agile trông có vẻ đơn giản để hiểu, tuy nhiên rất khó
để thành thạo, đặc biệt trong một doanh nghiệp lớn. Một lý do chính đó là Agile tập
trung nhiều vào yếu tố con người bao gồm văn hóa, giao tiếp, hợp tác phối hợp giữa các
bên liên quan, khả năng làm việc nhóm. Và thay đổi văn hóa, hành vi con người thì
chuyện không bao giờ là dễ dàng.
 
Để giải quyết vấn đề này, việc thuê huấn luyện viên Agile (Agile coach) giỏi là điều rất
cần thiết. Chỉ có người có mindset đúng, hiểu sâu về Agile, có nhiều kinh nghiệm và kỹ
năng huấn luyện thì mới giúp doanh nghiệp hay đội dự án tiếp cận nhanh nhất với
Agile. Quá trình huấn luyện cần từ 3 tháng đến 1 năm hay dài hơn tùy nhu cầu.
8.3. Các mẹo quản lý dự án dễ dàng hơn với mô hình Agile.

 Kỹ năng chắt lọc thông tin khi thực hiện dự án.

Sự dư thừa thông tin, có quá nhiều thuộc tính không cần thiết hoặc sự phức tạp quá
mức sẽ khiến nguồn vốn thực hiện dự án bị đội lên, gây lãng phí cho tổ chức

Chỉ cung cấp cho khách hàng những gì họ yêu cầu bởi việc thêm quá nhiều tính năng
không cần thiết sẽ gây lãng phí nguồn lực, tiền bạc khiến lợi nhuận của doanh nghiệp
suy giảm

Chúng ta nên tránh sự phức tạp quá mức. Nếu không, các dự án của chúng ta sẽ có:
nhiều chi phí hơn, nhiều lỗi hơn, nhiều hiểu lầm hơn và nhiều rủi ro hơn. Và đôi khi,
những thứ đơn giản hơn lại mang lại nhiều giá trị hơn.

16
  Phải tôn trọng sản phẩm của khách hàng.
Việc tôn trọng các sản phẩm của khách hàng sẽ nâng cao tính cá nhân hóa sản phẩm,
gia tăng sự thân thiết đối với người tiêu dùng dịch vụ/ sản phẩm của doanh nghiệp.
Vòng đời nhân sự của doanh nghiệp luôn thay đổi, vì vậy, nhà quản trị phải liên kết
các hoạt động tiền nhiệm và kế thừa sao cho khách hàng nội bộ tham gia sớm vào quá
trình với nhóm đang làm việc trong hoạt động tiền nhiệm.

 Không lãng phí thời gian trong các cuộc họp.

Việc thường xuyên có các cuộc họp không chỉ gây lãng phí thời gian làm việc của
người lao động mà nó còn là một phần của nền văn hóa không nhanh nhẹn.

Các cuộc họp điều phối chỉ nên được thực hiện để tạo điều kiện thuận lợi cho việc thực
hiện dự án không bị gián đoạn. Trong các cuộc họp cộng tác, chỉ các vấn đề kỹ thuật
nên được thảo luận.

 Đo lường rủi ro trước khi thực hiện dự án.

Thực hiện phân tích rủi ro trước khi bắt đầu thực hiện dự án là chủ động bằng cách
giảm thiểu các vấn đề trong tương lai, điều này sẽ giúp bạn có được một dự án nhanh
nhẹn và hiệu quả hơn.

Nên lập các dự án dự phòng trong trường hợp rủi ro xảy ra. Tuy nhiên, có thể tối thiểu
hóa rủi ro thông qua việc sử dụng phần mềm quản lý rủi ro hay lập kế hoạch tốt, xác
định, phân tích định tính, phân tích định lượng, lập kế hoạch phản ứng, giám sát và
kiểm soát.

 Tập trung vào báo cáo theo dạng số liệu thay vì văn bản dài dòng.

Nên sử dụng các phương pháp đồ họa chắc chắn sẽ thu hút nhiều sự chú ý hơn: màu
sắc, hình ảnh, biểu tượng, bảng biểu, nguyên mẫu, v.v.

Chú trọng vào việc thông báo những ngoại lệ, những vấn đề mới, thay vì những điểm
tương đồng

 Tối ưu hóa và chuẩn hóa mọi quy trình mà doanh nghiệp có.
Việc tối ưu hóa và chuẩn hóa quy trình sẽ giúp quá trình làm việc của doanh nghiệp
được trơn tru hơn. Bên cạnh đó, việc tối ưu hóa quy trình còn giúp doanh nghiệp giảm
thiểu lỗi sai trong hoạt động sản xuất mà nguồn lực con người mang lại. Một quy trình

17
nếu được tối ưu hóa có thể tạo ra nhiều lợi ích với doanh nghiệp như. Những lợi ích
mà doanh nghiệp đạt được khi tiến hành tối ưu hóa quy trình:

 Nâng cao hiệu suất và hiệu quả làm việc của nhân viên
 Giảm thiểu lỗi sai sót khi thực hiện công việc
 Tiết kiệm thời gian, chi phí nhờ việc tự động hóa những việc đơn giản, mang
tính lặp đi lặp lại
 Nâng cao vị thế cạnh tranh trên thị trường

9.Kết luận.
Việc Agile tinh giản số lượng tài liệu quản lý đã giúp cải tiến tốc độ phát triển sản
phẩm. Thay vì sử dụng tài liệu dài mà không phải ai cũng có thời gian để đọc, Agile
tăng cường sự tương tác giữa các thành viên trong nhóm, với các phản hồi của khách
hàng, trí tưởng tượng, lập trình cùng những thử nghiệm và những ý tưởng mới. Những
yếu tố này sẽ góp phần tìm ra giải pháp phù hợp khi có sự thay đổi đột ngột thay vì nhất
nhất tuân theo một kế hoạch và không thể đối phó khi có tình huống phát sinh. 
 
Tuy nhiên, việc áp dụng Agile không hề dễ dàng, nó phụ thuộc rất nhiều vào sự linh
hoạt của chính nhà lãnh đạo. Đưa Agile vào doanh nghiệp không giống như một dự án,
nó là một sự thay đổi lớn đối với văn hoá doanh nghiệp và chiến lược phát triển nguồn
nhân lực.
Chương III.Áp dụng Agile vào thực tế.
1.Lập bảng kế hoach.

STT Công Việc Mô tả Nội dung

Thiết kế giao diện Ba khối hình chữ nhật riêng biệt Cùng trên
1 hiện thị thông tin một hàng. Phân biệt bằng màu sắc hoặc Icon
sensor theo chủ đề sensor
Bao gồm 3 đường dạng line. Màu sắc theo Thiết kế
Thiết kế giao diện đồ
2 sensor. Cột có giá trị thang giá trị. Vạch dưới phần mềm
thị
có mốc thời gian.
Thiết kế giao diện Có biểu tượng tương ứng với thiết bị điều
3
điều khiển khiển
Thu thập dữ liệu
4 Dùng esp/stm thu thập dữ liệu
sensor

5 Xử lý dữ liệu sensor Làm tròn đến một chữ số sau dấu phẩy Phần cứng

6 Xử lý gửi dữ liệu đi Thiết lập kết nối với server

18
 Xử lý dữ liệu điều
7 Nhận dữ liệu từ web bật tắt thiết bị
khiển thiết bị
Xử lý thao tác thời
8 Cập nhật thông tin liên tục theo thời gian thực
gian thực
Xử lý nhận dữ liệu từ
9 Nhận dự liệu từ server chung với phần cứng
server
Xử lý gửi dữ liệu lên Thiết lập
10 Gửi dữ liệu lên cơ sở dữ liệu
database kết nối
Xử lý gửi dữ liệu lên Gửi dữ liệu lên khung hiển thị và đồ thị ở
11
phần hiển thị giao diện hiện thị
Xác định các yêu cầu
Xác định sản phẩm được phát triển đúng và
12 và đặc điểm của sản
đạt được mục tiêu cốt lõi của dự án.
phẩm
Tạo ra các kế hoạch Xác định các quá trình phân tích, thiết kế và
13
kiểm tra mã của sản phẩm đang làm việc chính xác.
Phát triển các ca kiểm Đảm bảo rằng sản phẩm hoạt động đúng với
14
thử các yêu cầu đã đặt ra. Kiểm tra
Thực hiện các ca kiểm thử và xác định các lỗi và đánh
15 Chạy các kiểm thử
và trục trặc của sản phẩm. giá
Đánh giá và xử lý chúng để sản phẩm phát
Đánh giá và xử lý các
16 triển được hoàn thiện và đạt được tiêu chí
lỗi
chất lượng.
Xác định rằng nó hoạt động đúng với các yêu
17 Kiểm tra nghiệm thu cầu đã được đặt ra ban đầu và đáp ứng nhu
cầu của người dùng hay không.
Triển khai
18 Bàn giao sản phẩm Liên hệ khách hàng bàn giao sản phẩm
sản phẩm

19 Công bố sản phẩm Khách hàng quảng cáo sản phẩm

Nhận gửi thông tin

20 Gửi email thông báo sản phẩm
phản hồi
Kết hợp với khách hàng tổ chức sự kiện giới
21 Quảng bá sản phẩm
thiệu sản phẩm
Liên hệ với người dùng nhận thông tin phản
22 Khảo sát sản phẩm
hổi về sản phẩm
23 Phân tích sản phẩm Sử dụng thông tin người dùng phản hồi đưa

19
 ra đánh giá sản phẩm

24 Đánh giá sản phẩm Đưa ra các tiêu chí và thang đo đánh giá

Xác định các điểm Bao gồm các lỗi, thiếu sót hoặc các vấn đề về
25
yếu hiệu suất, tốc độ và tính bảo mật.

26 Cải tiến Sử lỗi, tối ưu hiệu suất, tăng bảo mật Bảo trì

27 Triển khai cải tiến Đưa ra cập nhật, phiên bản mới

Đánh giá lại sản

28 Thực hiện đánh giá lại sản phẩm
phẩm

2.Thiết kế.
2.1Thiết kế phần mềm.
Tiến Tiến Thời
Người Tổng
Công độ độ Tình Ghi gian
stt Mô tả chi tiết thực thời
Việc dự thực trạng chú cần
hiện gian
kiến tế thêm
Ba khối hình chữ nhật
riêng biệt gồm nhiệt độ,
Thiết kế
độ ẩm, ánh sáng cùng
giao Hoàn
trên một hàng. Phân biệt Đinh
diện thành
1 bằng màu sắc (Tạo màu Văn 3 3 3
hiện thị đúng
cho từng khối: nhiệt Bắc
thông tin tiến độ
độ'Đỏ', độ ẩm'xanh', ánh
sensor
sáng'vàng') và Icon theo
chủ đề sensor.
Tạo khối biểu đồ bên trái
giao diện web. Bao gồm
3 đường dạng line biểu
Thiết kế Hoàn
diễn cho 3 giá trị thu Đinh
giao thành
2 được từ các cảm biến. Văn 3 5 5
diện đồ chậm
Màu sắc đường line. Cột Bắc
thị tiến độ
có giá trị thang giá trị.
Vạch dưới có mốc thời
gian thực.

Thiết kế Tạo 2 khối bên phải giao Đinh Hoàn

3 1 1 1
giao diện web để điều khiển Văn thành
20
 diện bật tắt LED. Có biểu
đúng
điều tượng LED tương ứng Bắc
tiến độ
khiển với thiết bị điều khiển.
9

2.2Thiết kế phần cứng.

Tiến Thời
Người Tiến Tổng
Công độ Tình Ghi gian
STT Mô tả chi tiết thực độ dự thời
Việc thực trạng chú cần
hiện kiến gian
tế thêm
Dùng esp32 kết Hoàn
Thu thập Đinh
nối với các chân thành
1 dữ liệu Văn 3 4 4
cảm biến để thu chậm
sensor Bắc
thập dữ liệu tiến độ
Thiết lập kết nối
với server. Sau
Đinh Chưa
Xử lý gửi khi thu thập Họp
2 Văn 3 2 hoàn 3 5
dữ liệu đi được dữ liệu và nhóm
Bắc thành
dữ liệu lên trang
web
Kết nối esp32
Xử lý dữ với chân các Hoàn
Đinh
liệu điều LED để bật tắt thành
3 Văn 3 3 3
khiển LED. Nhận dữ đúng
Bắc
thiết bị liệu từ web bật tiến độ
tắt LED
Xử lý Hoàn
Cập nhật thông Đinh
thao tác thành
4 tin liên tục theo Văn 3 1 1
thời gian đúng
thời gian thực Bắc
thực tiến độ
13

2.3.Thiết lập kết nối.

Tiến Tiến Thời
Người Tổng
độ độ Tình Ghi gian
STT Công Việc Mô tả chi tiết thực thời
dự thực trạng chú cần
hiện gian
kiến tế thêm

21
 Nhận dự liệu từ
server chung với
phần cứng. Sau khi
Xử lý bấm nút bật/tắt
Đinh Chưa
nhận dữ LED trên trang Họp
1 Văn 5 3 hoàn 4 7
liệu từ web thì dữ liệu nhóm
Bắc thành
server được đưa trở về
esp32 để bật/tắt
LED trên phần
cứng.
Gửi dữ liệu lên cơ
sở dữ liệu. Cứ sau
Hoàn
Xử lý gửi 2s thì dữ liệu từ Đinh
thành
2 dữ liệu lên các cảm biến được Văn 5 3 3
chậm
database cập nhật. Các dữ Bắc
tiến độ
liệu này sẽ được
lưu trên Mysql.
Đưa dữ liệu của
nhiệt độ, độ ấm,
Xử lý gửi ánh sáng lên từng
Đinh Chưa
dữ liệu lên khối hiển thị đã tạo Họp
3 Văn 5 3 hoàn 2 5
phần hiển riêng biệt và đẩy nhóm
Bắc thành
thị các dữ liệu đó lên
đồ thị ở giao diện
đồ thị.
15

3.Kiểm tra và đánh giá

Tiến Thời
Người Tiến Tổng
độ Tình Ghi gian
stt Công Việc Mô tả chi tiết thực độ dự thời
thực trạng chú cần
hiện kiến gian
tế thêm
Xác định Xác định sản phẩm
Hoàn
các yêu cầu được phát triển Đinh
thành
1 và đặc điểm đúng và đạt được Tiến 1 1 1
đúng
của sản mục tiêu cốt lõi của Danh
tiến độ
phẩm dự án.

2 Tạo ra các Xác định các quá Đinh 1 1 Hoàn 1

22
 trình phân tích,
thành
kế hoạch thiết kế và mã của Tiến
đúng
kiểm tra sản phẩm đang làm Danh
tiến độ
việc chính xác.
Đảm bảo rằng sản Hoàn
Phát triển Đinh
phẩm hoạt động thành
3 các ca kiểm Tiến 1 2 2
đúng với các yêu chậm
thử Danh
cầu đã đặt ra. tiến độ
Thực hiện các ca Hoàn
Đinh
Chạy các kiểm thử và xác thành
4 Tiến 3 3 3
kiểm thử định các lỗi và trục đúng
Danh
trặc của sản phẩm. tiến độ
Đánh giá và xử lý
chúng để sản phẩm Hoàn
Đánh giá và Đinh
phát triển được thành
5 xử lý các Tiến 3 4 4
hoàn thiện và đạt trước
lỗi Danh
được tiêu chí chất tiến độ
lượng.
Xác định rằng nó
hoạt động đúng với
Hoàn
các yêu cầu đã Đinh
Kiểm tra thành
6 được đặt ra ban đầu Tiến 1 1 1
nghiệm thu đúng
và đáp ứng nhu cầu Danh
tiến độ
của người dùng
hay không.
12

4.Triển khai sản phẩm.

Tiến Thời
Người Tiến Tổng
Công độ Tình Ghi gian
stt Mô tả chi tiết thực độ dự thời
Việc thực trạng chú cần
hiện kiến gian
tế thêm
Bàn Liên hệ, gửi Email, Đoàn Hoàn
1 giao sản thông báo địa điểm, Quyết 1 1 thành 1
phẩm thời gian cụ thể cho Thắng đúng
23
 khách hàng bàn giao
tiến độ
sản phẩm
Giời thiệu và trình Hoàn
Công bố Đoàn
bày các tính năng thành
2 sản Quyết 1
theo yêu cầu khách đúng
phẩm Thắng
hàng tiến độ
Nhận
Tiếp nhận và phản Hoàn
gửi Đoàn
hồi lại đánh giá của thành
3 thông Quyết 1
khách hàng đối với đúng
tin phản Thắng
sản phẩm hoàn thành tiến độ
hồi
Tổ chức sự kiện, Hoàn
Quảng Đoàn
chương trình, ưu đãi thành
4 bá sản Quyết 7 7 7
đặc biệt cho việc đúng
phẩm Thắng
giới thiệu sản phẩm tiến độ
Tạo ra những cuộc
khảo sát trực tiếp
hay gửi Email bảng Hoàn
Khảo sát Đoàn
đánh giá trên thành Họp
5 sản Quyết 3 4 4
website cho người chậm nhóm
phẩm Thắng
dùng để nhận thông tiến độ
tin phản hổi về sản
phẩm
Sử dụng thông tin
Hoàn
Phân người dùng phản hồi Đoàn
thành Họp
6 tích sản đưa ra những chỉnh Quyết 3 5 5
chậm nhóm
phẩm sửa cụ thể cho sản Thắng
tiến độ
phẩm
17

5.Bảo trì
Tiến độ
Tiến công
Người Tiến Tổng
Công độ Tình Ghi việc
STT Mô tả chi tiết thực độ dự thời
Việc thực trạng chú chưa
hiện kiến gian
tế hoàn
thành
1 Đánh Khách hàng đưa ra Minh 1 1 Hoàn 1
24
 các tiêu chí và
thành
giá sản thang đo đánh giá
đúng
phẩm trong quá trình sử
tiến độ
dụng
Xác Khách hàng đưa ra
Hoàn
định các lỗi, thiếu sót
thành
2 các hoặc các vấn đề về Minh 2 3 3
chậm
điểm hiệu suất, tốc độ và
tiến độ
yếu tính bảo mật.
Khắc phục các lỗi Hoàn
Cải hiện có sửa lỗi, tối thành
3 Minh 1 1 1
tiến ưu hiệu suất, tăng đúng
bảo mật tiến độ
Đưa ra cập nhật,
phiên bản mới, có
Hoàn
Triển thể update trong
thành
4 khai suốt quá trình sử Minh 5 6 6
chậm
cải tiến dụng sản phẩm khi
tiến độ
khách hàng đưa ra
yêu cầu.
Cả nhóm cùng thực
hiện đánh giá lại
Đánh sản phẩm một lần Hoàn
giá lại nữa, khắc phục các thành
5 Minh 2 2 2
sản vấn đề còn tồn đúng
phẩm đọng, và đưa ra kế tiến độ
hoạch cho dự án
mới
13

6.Một số hình ảnh liên quan đến dự án.

25
26
27
28
29