Ứng dụng logic mờ giải bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình agile

TÓM TẮT LUẬN VĂN ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE Học viên: Lê Duy Tuấn Chuyên ngành: Khoa học máy tính Mã số: 8480101 Khóa: K33 T

ĐẠI HỌC ĐÀ NẴNG TRƯỜNG ĐẠI HỌC BÁCH KHOA

LÊ DUY TUẤN

ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƯỚC LƯỢNG

NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE

ĐẠI HỌC ĐÀ NẴNG TRƯỜNG ĐẠI HỌC BÁCH KHOA

LÊ DUY TUẤN

ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƯỚC LƯỢNG

NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE

Chuyên ngành: Khoa học máy tính

LỜI CAM ĐOAN

Tôi cam đoan đây là công trình nghiên cứu của riêng tôi Các số liệu, kết quả nêu trong luận văn là hoàn toàn trung thực và chƣa từng đƣợc ai công bố trong bất kỳ công trình nào khác

Tác giả luận văn

Lê Duy Tuấn

MỤC LỤC

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT 5

DANH MỤC CÁC BẢNG 6

DANH MỤC CÁC HÌNH VẼ 7

MỞ ĐẦU 8

CHƯƠNG I: CƠ SỞ LÝ THUYẾT 11

CƠ SỞ LÝ THUYẾT ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM 11

1.1 Tổng quan ước lượng phần mềm 11

1.2 Các bước cơ bản trong ước lượng phần mềm 12

1.3 Các phương pháp ước lượng 14

1.4 Tổng quan mô hình Agile 14

1.4.1 Mô hình phát triển phần mềm Agile 14

1.4.2 Tuyên ngôn phát triển phần mềm Agile và các nguyên lý 15

1.4.3 Các đặc trưng của mô hình Agile 16

1.5 Giới thiệu Scrum 18

1.5.1 Giới thiệu 18

1.5.2 Khung làm việc Scrum 19

1.5.3 Nguyên lý hoạt động của scrum: 24

CHƯƠNG II LOGIC MỜ VÀ ỨNG DỤNG 25

2.1 Cơ sở lý thuyết 25

2.1.1 Cơ sở lý thuyết về logic mờ 25

2.1.2 Cơ sở toán học của logic mờ 25

2.1.3 Khái niệm về tập mờ 26

2.1.4 Các phép toán của tập mờ 28

2.2 Logic mờ 31

2.2.1 Khái niệm 31

2.2.2 Biến ngôn ngữ 32

2.2.3 Mệnh đề mờ 32

2.2.4 Các phép toán của logic mờ 36

2.2.5 Biến ngôn ngữ 37

2.2.6 Các luật trong mô hình logic mờ 37

2.2.7 Qui trình hoạt động của Logic mờ 38

2.2.8 Một số ứng dụng 38

CHƯƠNG III: ỨNG DỤNG LOGIC MỜ VÀO BÀI TOÁN ƯỚC LƯỢNG NỖ LỰC

PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE 40

3.1 Mô hình tổng quan 41

3.2 Bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình Agile 41

3.3 Áp dụng logic mờ vào bài toán ước lượng nỗ lực phát triển phần mềm 43

3.3.1 Xác định độ phức tạp (nỗ lực) 44

3.3.2 Xác định vận tốc 50

3.3 Tóm tắt các bước thực hiện: 53

3.4 Ví dụ minh họa 54

3.5 Chương trình ứng dụng 56

KẾT LUẬN VÀ TRIỂN VỌNG 58

1 Kết quả đạt được 58

2 Hạn chế 58

3 Hướng phát triển 58

TÀI LIỆU THAM KHẢO 59

TÓM TẮT LUẬN VĂN ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƯỚC LƯỢNG NỖ LỰC PHÁT

TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE

Học viên: Lê Duy Tuấn Chuyên ngành: Khoa học máy tính

Mã số: 8480101 Khóa: K33 Trường: ĐH Bách Khoa – ĐH Đà Nẵng

Tóm tắt: Mô hình phát triển phần mềm linh hoạt (Agile Software

Development) gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm, mô hình này khắc phục được những hạn chế của các phương pháp phát triển phần mềm truyền thống, góp phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu khách hàng trong thời gian ngắn nhất với hiệu quả cao nhất Cũng như các mô hình phát triển phần mềm khác, trong mô hình phát triển phần mềm Agile khâu ước lượng cũng đóng vai trò quyết định đến sự thành công hay thất bại của dự án phần mềm Nghiên cứu này nhằm mục đích ứng dụng logic mờ vào bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình Agile để giảm thiểu được thời gian, chi phí cho quá trình ước lượng nỗ lực phát triển phần mềm, qua đó góp phần nâng cao hiệu quả cho dự án phần mềm

Từ khóa: Mô hình Agile, quy trình Scrum, ước lượng nỗ lực, công nghệ phần mềm, logic mờ

FUZZY LOGIC APPLICATION SOLVES THE ESTIMATION PROBLEM OF

AGILE SOFTWARE DEVELOPMENT EFFORTS

Abstract: Agile Software Development model has become very popular in

software development industry, this model overcomes the limitations of traditional software development methods, contribute to creating software that can meet customer requirements in the shortest time with the highest efficiency Like other software development models, in Agile software development model, the estimation also plays

a decisive role in the success or failure of software projects This study aims to apply fuzzy logic to the estimation of Agile software development efforts to minimize time and cost for the process of estimating software development efforts, thereby contributing improve efficiency for software projects

Keywords: Agile Software Development, Scrum, Software Effort Estimation, Software Engineering, Fuzzy Logic

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

1 SLOC Source Line Of Code: Dòng mã nguồn

2 FP Function Point: Điểm chức năng

3 OP Object Point: Điểm đối tượng

4 COCOMO Constructive Cost Model - Mô hình giá cấu thành

5 SP Story Point là đại lượng chỉ độ lớn tương đối của các user story

6 FR Friction: Hệ số ma sát

7 DF Dynamic Force: Yếu tố dao động

8 ES User Story Effort

DANH MỤC CÁC BẢNG

DANH MỤC CÁC HÌNH VẼ

Số hiệu

2.3 Độ cao, miền xác định, miền tin cậy của tập mờ 27

2.5 Hợp của hai tập mờ có cùng cơ sở theo qui tắc Max (a) và

MỞ ĐẦU

I Lý do chọn đề tài

Trong quản lý dự án phần mềm, khâu ước ước lượng được xem là vấn đề trực tiếp ảnh hưởng đến sự thành công hay thất bại của một dự án phần mềm Thực tế đã có rất nhiều dự án thất bại do trong khi thực hiện dự án quá trình ước lượng không chính xác dẫn đến kế hoạch bị phá sản Trong quá trình thực hiện dự án ta không thể tính toán, ước lượng chính xác tuyệt đối được chi phí để phát triển phần mềm, tuy nhiên nếu các con số dự đoán nằm trong khoảng cho phép sẽ góp phần giảm rủi ro cho dự án phần mềm Do đó, nếu ta có một phương pháp ước lượng phần mềm hiệu quả thì sẽ hạn chế được sự thất bại của một dự án phần mềm

Hiện nay mô hình phát triển phần mềm linh hoạt (Agile Software Development) gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm, mô hình này khắc phục được những hạn chế của các phương pháp phát triển phần mềm truyền thống, góp phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu khách hàng trong thời gian ngắn nhất với hiệu quả cao nhất Tuy nhiên, cũng như các phương pháp truyền thống khác, khâu ước lượng nỗ lực phát triển phần mềm theo mô hình Agile cũng đóng vai trò quyết định đến sự thành công của một dự án phần mềm

Dựa trên lý thuyết logic mờ và xét thấy có sự liên quan trong quá trình ước lượng nỗ lực đến logic mờ Do đó, tôi đề xuất chọn luận văn cao học:

"Ứng dụng logic mờ giải bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình Agile"

II Mục đích nghiên cứu

Xây dựng được ứng dụng hỗ trợ ước lượng nỗ lực phát triển phần mềm có ứng dụng logic mờ áp dụng vào mô hình Agile để giảm thiểu được thời gian, chi phí cho quá trình ước lượng nỗ lực phát triển phần mềm, qua đó góp phần nâng cao hiệu quả cho dự án phần mềm

III Mục tiêu và nhiệm vụ nghiên cứu

1 Mục tiêu:

- Nắm vững lý thuyết về công nghệ phần mềm và kiến thức về ước lượng nỗ lực phát triển phần mềm

- Nắm vững mô hình phát triển phần mềm Agile

- Nắm vững về lý thuyết logic mờ và áp dụng được logic mờ vào bài toán ước lượng nỗ lực phát triển phần mềm

- Xây dựng được ứng dụng để hỗ trợ ước lượng nỗ lực phát triển phần mềm

2 Nhiệm vụ:

- Nghiên cứu mô hình phát triển phần mềm linh hoạt ở thực tiễn

- Nghiên cứu lý thuyết logic mờ và tình hình ứng dụng logic mờ vào bài toán ước lượng nỗ lực phát triển phần mềm ở hiện tại

- Tìm hiểu và cài đặt thuật toán có ứng dụng logic mờ vào bài toán ước lượng

nỗ lực phát triển phần mềm

- Thực nghiệm và đánh giá giá kết quả theo yêu cầu mà đề tài đặt ra

IV Đối tượng và phạm vi nghiên cứu

- Mô hình phát triển phần mềm Agile

- Lý thuyết ước lượng nỗ lực phát triển phần mềm

- Lý thuyết Logic mờ và ứng dụng của logic mờ

V Phương pháp nghiên cứu

- Phương pháp lý thuyết

- Phương pháp phân tích và tổng hợp

- Phương pháp thực nghiệm

VI Ý nghĩa khoa học và thực tiễn

- Nghiên cứu và vận dụng được mô hình phát triển phần mềm Agile trong công việc quản lý dự án phần mềm

- Nắm vững phương pháp ước lượng nỗ lực phát triển phần mềm

- Nắm vững được lý thuyết về logic mờ và áp dụng được vào bài toán nỗ lực phát triển phần mềm

- Xây dựng được ứng dụng hỗ trợ ước lượng nỗ lực phát triển phần mềm để có thể áp dụng vào các dự án thực tế

- Kết quả nghiên cứu có thể làm tài liệu tham khảo trong quá trình ước lượng nỗ lực phát triển phần mềm cho các dự án phần mềm

VII Dự kiến kết quả đạt được

- Biết được mô hình phát triển phần mềm Agile

- Biết được kiến thức về logic mờ và ứng dụng kiến thức về logic mờ để áp dụng vào bài toán ước lượng chi phí

- Xây dựng được ứng dụng để minh họa cho nội dung luận văn

- Có kết quả thực nghiệm để đánh giá tính thực tế của đề tài

VIII CẤU TRÚC NỘI DUNG LUẬN VĂN

CHƯƠNG I: CƠ SỞ LÝ THUYẾT

CƠ SỞ LÝ THUYẾT ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM

1.1 Tổng quan ước lượng phần mềm

1.2 Các bước cơ bản trong ước lượng phần mềm

1.3 Các phương pháp ước lượng

1.4 Tổng quan mô hình Agile

1.5 Giới thiệu Scrum

CHƯƠNG II LOGIC MỜ VÀ ỨNG DỤNG

3.2 Bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình Agile

3.3 Áp dụng logic mờ vào bài toán ước lượng nỗ lực phát triển phần mềm

CHƯƠNG I: CƠ SỞ LÝ THUYẾT

CƠ SỞ LÝ THUYẾT ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM 1.1 Tổng quan ước lượng phần mềm

Ước lượng là công việc tính toán gần đúng một đại lượng nào đó dựa trên các tập dữ liệu liên quan đến đại lượng đó Cũng giống như bất cứ một dự án nào khác, dự

án phần mềm cũng cần phải ước lượng các đại lượng trên với mục đích:

- Dự toán chi phí hợp lý

- Sự chính xác cao

- Đảm bảo tiến độ

- Kiểm soát dự án tốt hơn

- Thể hiện được sự chuyên nghiệp

Ước lượng phần mềm từ lâu đã được xem là vấn đề cốt lõi có ảnh hưởng trực tiếp đến sự thành bại của dự án Ước lượng là một trong những nền tảng cho việc lập lịch dự án một cách hiệu quả Nhiều công ty phát triển phần mềm phải chịu thất bại hoặc bị mất lợi thế cạnh tranh do các ước lượng xấu

Khi phát triển phần mềm cần phải đưa ra một ước lượng về giá cả, nhân lực và thời gian thực hiện dự án một cách hợp lý Nếu ước lượng thiếu cho một dự án, quản

lý thiếu các nỗ lực đảm bảo chất lượng sẽ dẫn đến việc quá tải, vượt quá về khả năng

và thời gian làm việc Ngược lại nếu ước lượng dư cho một dự án sẽ dẫn đến việc phát sinh chi phí nhiều hơn so với mức cần thiết dẫn đến sự lãng phí đối với dự án

Trong suốt quá trình phát triển phần mềm, cho dù có sử dụng mô hình quản lý phần mềm nào đi nữa thì sau mỗi cột mốc phát triển phần mềm, các trưởng dự án thường phải hoạch định công việc cho cột mốc tiếp theo và tính toán lại những phần công việc đã thực hiện được ở cột mốc trước Điều đó dẫn đến việc ước lượng được tiến hành xuyên suốt quá trình thực hiện dự án, trải qua từng bước của quy trình phần mềm Ở giai đoạn đầu, dự án còn ở dạng đơn giản, thiếu thông tin, việc ước lượng trong giai đoạn này có độ chính xác không cao Càng về những giai đoạn sau, các chi tiết của dự án đã đầy đủ, độ chính xác của ước lượng sẽ tăng lên Hình 1 cho thấy quá trình ước lượng chính xác hơn sau mỗi giai đoạn của dự án phần mềm

Hình 1.1: Đồ thị hình nón không chắc chắn [1]

1.2 Các bước cơ bản trong ước lượng phần mềm

Các bước chính trong ước lượng dự án phần mềm là:

- Ước lượng kích thước, phạm vi dự án: Đây là thông số ước lượng rất được quan tâm là yếu tố về độ lớn phần mềm Một ước lượng chính xác về kích thước phần mềm là cơ sở cho một ước lượng có hiệu quả Ta cần thu thập các thông tin về phạm vi của dự án bắt đầu với những mô tả với những yêu cầu của khách hàng Tài liệu ước lượng cần phải được làm mới lại sau mỗi lần có thêm thông tin phạm vi ước lượng

Để ước lượng kích thước, phạm vi ta có thể dựa vào các dự án tương tự trong quá khứ (nếu như ta đã từng làm) Chúng ta có thể ước lượng cho dự án mới bằng cách dùng phép tính phần trăm của kích thước với phần tương tự của dự án trước đó, sau đó

sẽ tổng lại các kích cỡ đã được ước lượng

Ngoài ra ta có thể dùng phương pháp phân tích để ước lượng kích thước bằng cách đo độ lớn phần mềm bằng đơn vị dòng mã nguồn (SLOC – Source Line Of Code) Tuy nhiên trong khi phần mềm chưa hoàn thành, thông số này phải phỏng đoán nên không tránh khỏi những sai sót Để khắc phục tình trạng này người ta dùng đơn vị điểm chức năng (FP Function Point) Đơn vị này được tính toán dựa trên các yêu cầu

về chức năng và phi chức năng của một dự án nên mang tính thực tế hơn Hiện nay một đơn vị khác cũng được sử dụng là điểm đối tượng (OP – Object Point) Đây là đơn

vị được tính toán dựa trên yêu cầu về số màn hình và báo biểu của phần mềm Nó thường được dùng để đo độ lớn phần mềm trong giai đoạn sơ khai của sự án, lúc những chi tiết dùng để tính điểm chức năng chưa được làm rõ

- Ước lượng nỗ lực: Sau khi chúng ta đã có được một ước lượng kích thước, phạm vi của sản phẩm, chúng ta có thể tính toán được ước lượng nỗ lực từ nó Kích thước của phần mềm là yếu tố quan trọng nhất trong việc xác định bao nhiêu nỗ lực là cần thiết để xây dựng nó Tuy nhiên, kích thước cuối cùng thì không được biết khi dự

án vẫn còn đang được hình thành, và phần mềm chưa thực sự tồn tại Do đó, nếu kích thước được sử dụng cho một mô hình ước lượng nỗ lực, nó phải được ước lượng ngay

từ lúc đầu Có 2 cách để tính toán nỗ lực là dùng dữ liệu lịch sử và sử dụng mô hình tính toán

Dùng dữ liệu lịch sử tức là dựa vào các dữ liệu nỗ lực và kích thước của các dự

án trước đã sử dụng trong quá khứ để ước lượng cho dự án hiện tại Sau khi đã có được một nỗ lực tổng thể ta sẽ xác định các nỗ lực cho các hoạt động hoặc các giai đoạn bằng tỉ lệ phần trăm so với nỗ lực tổng thể

Trường hợp ta không có dữ liệu của dự án trong quá khứ chúng ta có thể tiếp cận một số thuận toán đã hoàn thiện và được công nhận rộng rãi (ví dụ mô hình COCOMO, COCOMO II) Các mô hình này có được từ việc nghiên cứu một số lượng lớn các dự án đã được hoàn thành từ nhiều tổ chức khác nhau để xem xét các kích cỡ

dự án so với tổng nỗ lực của dự án tổng Vì dữ liệu được thu thập từ nhiều dự án của các tổ chức nên có thể độ chính xác so với dữ liệu so với tổ chức của mình nhưng chúng có thể giúp chúng ta có được những ước lượng nỗ lực gần đúng

- Ước lượng tiến trình: Sau khi nỗ lực đã được biết hoặc đã được ấn định cố định ngay từ đầu, các thời gian biểu khác nhau có thể tính được tính, tùy thuộc vào số nhân sự được đưa vào để thực hiện dự án Ta sẽ ước lượng số lượng người làm việc trên dự án, họ sẽ làm những gì, thời gian bắt đầu làm, thời gian kết thúc Khi ta có được thông tin này ta sẽ phải tính toán để đưa vào lịch trình theo thời gian Ước lượng lịch trình cho một dự án là một vấn đề phức tạp vì phần lớn dự án đều trễ tiến độ nguyên nhân là do mất sự kiểm soát tiến độ dự án

- Ước lượng chi phí: Trong ngành sản xuất phần mềm yếu tố ước lượng được quan tâm là chi phí phần mềm Chi phí phần mềm bao gồm:

Chí phí sản xuất: Chi phí để phát triển phần mềm dựa trên số công thực hiện dự

1.3 Các phương pháp ước lượng

Ước lượng phần mềm là một quá trình phức tạp Đầu vào của quá trình ước lượng là các thông số, các thông số này ảnh hưởng đến công việc thực hiện của dự án,

có thể chia các thông số thành các loại sau:

- Thông số về sản phẩm: những yếu tố của sản phẩm phần mềm ảnh hưởng đến công thực hiện dự án: độ lớn, độ phức tạp, loại phần mềm

- Thông số về môi trường: gồm những yếu tố môi trưởng có ảnh hưởng đến công thực hiện sự án như: quy trình thực hiện, công nghệ triển khai

- Thông số về đội ngũ phát triển: trình độ, khả năng chuyên môn, kinh nghiệm Các phương pháp ước lượng nỗ lực có thể được sử dụng:

- Ước lượng dựa vào chuyên gia: Phương pháp này dựa vào các kinh nghiệm của những chuyên gia làm phần mềm, tuy nhiên phương pháp này mang tính chủ quan, không phải kết quả lúc nào cũng tin cậy

- Ước lượng dựa vào các dự án cũ: Phương pháp này sử dụng những số liệu của các dự án phần mềm trước đó, từ đó dự đoán ước lượng cho dự án hiện tại

- Ước lượng bằng các mô hình thực nghiệm: Phương pháp này sẽ sử dụng một

mô hình thực nghiệm cụ thể để ước lượng Tuy nhiên phương pháp này cần có các tham số về dự án

1.4 Tổng quan mô hình Agile

Phương pháp phát triển phần mềm linh hoạt được đưa ra vào giữa những năm

90 như là một phần của sự nỗ lực chống lại những phương pháp “nặng nề” – điển hình bởi những quy định khắt khe Ban đầu chúng được gọi là “phương pháp nhẹ” Đến năm 2001, 17 thành viên nổi bật của cộng đồng phát triển phần mềm linh hoạt đã gặp

gỡ tại Snowbird, Utah để thảo luận về cách thức tạo ra phần mềm linh hoạt hơn, nhanh hơn và hướng con người hơn Họ đã thông qua tên gọi chính thức “phương pháp linh hoạt”

1.4.1 Mô hình phát triển phần mềm Agile

Agile là mô hình phát triển phần mềm linh hoạt, dựa trên phương thức lặp (iterative) và tăng trưởng (incremental) Nó sẽ gắn kết khách hàng vào quy trình phát triển của phần mềm, mọi người cố gắng cho ra sản phẩm càng nhanh càng tốt Sau đó đưa cho khách hàng dùng thử và phản hồi lại, đội ngũ phát triển sẽ tiếp tục phát triển các giai đoạn tiếp theo Tùy vào dự án mà thời gian release ra sản phẩm dài hay ngắn (có thể 2 tuần, cũng có thể 1 tháng…)

Thuật ngữ "Agile" chính thức được sử dụng rộng rãi theo cách thống nhất kể từ khi “Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001 Nhờ tính linh hoạt,

đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm

1.4.2 Tuyên ngôn phát triển phần mềm Agile và các nguyên lý

Tuyên ngôn phát triển phần mềm Agile [1]

- Tuyên ngôn 1: Cá nhân và sự tương tác hơn là quy trình và công cụ

Không phải lúc nào mọi việc đều có giải pháp mà giải pháp chính là nằm bên trong công việc Đối với một số công việc để tìm giải pháp không chỉ tập trung vào lý thuyết mà phải trải qua thực tiễn Ở đây bản tuyên ngôn nhấn mạnh vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong nhóm phát triển phần mềm Nếu dự án có những thành viên có năng lực, luôn sẵn sàng chia sẻ kiến thức, hỗ trợ lẫn nhau trong công việc thì sẽ mang đến thành công Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn Ở Agile mọi người cùng làm việc trong nhóm, chia sẻ thông tin với nhau hơn là theo sát một quy trình hay công cụ nào đó

- Tuyên ngôn 2: Phần mềm chạy tốt hơn là tài liệu đầy đủ

Một phần mềm dù có tài liệu hướng dẫn tốt, chi tiết tới đâu nhưng vận hành không hiệu quả thì xem như không đạt, vì vậy việc tạo ra sản phẩm phần mềm trong trọng hơn và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một cách chính xác Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại Tất cả các phương pháp linh hoạt thể hiện ở Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định, Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là phần mềm chạy tốt, thường được biết như "Định nghĩa của hoàn thành" Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thức và có thể vận hành bởi người dùng cuối Ở mức thấp hơn, các nhóm phải vượt qua những kiểm thự đơn vị và kiểm thử hệ thống

- Tuyên ngôn 3: Cộng tác với khách hàng hơn là đàm phán hợp đồng:

Việc ký kết hợp đồng là quan trọng nhưng chưa đủ Một môi trường hợp tác tốt

sẽ giúp cho những người phát triển đưa ra những giải pháp tốt nhất cho khách hàng, khách hàng và những người phát triển phải tương tác với nhau để làm rõ các yêu cầu cũng như các vấn đề cần thiết Bản tuyên ngôn khuyến khích khách hàng cũng tham một phần của dự án hơn chỉ là viết hợp đồng

- Tuyên ngôn 4: Phản hồi với các thay đổi hơn là bám sát kế hoạch: Việc lập kế hoạch cho phát triển phần mềm là rất quan trọng Một bản kế hoạch tốt sẽ giúp công việc được định hướng tốt hơn Tuy nhiên trong thực tế có rất nhiều sự thay đổi và nếu như ta cứ bám sát và kế hoạch ban đầu mà không thay đổi theo thực tế thì sẽ dẫn đến

sự thất bại Vì vậy nhóm phát triển phần mềm phải luôn sẵn sàng đón nhận các sự thay đổi khi có yêu cầu

12 nguyên lý sau tuyên ngôn Agile [1]

- Ưu tiên cao nhất là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị

- Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng

- Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn

- Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án

- Xây dựng các dự án xung quanh những cá nhân có động lực Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc

- Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp

- Phần mềm chạy tốt là thước đo chính của tiến độ

- Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn

- Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt

- Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản

- Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức

- Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp

1.4.3 Các đặc trưng của mô hình Agile

Phát triển linh hoạt bản thân nó không phải là một phương pháp Nó là một thuật ngữ chung mô tả rất nhiều các phương pháp linh hoạt Tại thời điểm ký kết Tuyên ngôn Agile năm 2001, những phương pháp này bao gồm: Scrum, XP, Crystal, FDD và DSDM Mỗi phương pháp phát triển linh hoạt có một cách tiếp cận hơi khác

nhau để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile, cũng giống như các ngôn ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hướng đối tượng theo những cách khác nhau Phương pháp linh hoạt có những đặc trưng sau:

- Tính lặp: Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, 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ử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương pháp agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn

- Tính tăng trưởng và tiến hóa: Cuối các phân đoạn, nhóm phát triển thường cho

ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này 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 ngay 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 Sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành

- Tính thích nghi: 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 Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi

- Nhóm tự tổ chức và liên chức năng: Cấu trúc nhóm agile thường là liên chức năng và tự tổ chức Theo đó, các nhóm này tự thực hiện lấy việc 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 (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control)

- Quản lý tiến trình thực nghiệm: 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 giả định Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập

dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm 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: Mô hình Agile đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ Về yêu cầu của khách hàng, agile khuyến khích

nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ

sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này 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 Bản thân các nhóm agile thường nhỏ để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả Các nhóm phát triển thường tạo ra các thói quen trao đổi trực diện một cách thường xuyên Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting) Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự án

- Phát triển dựa trên giá trị: Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ

đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ

để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn cho dự án Nhờ đó các

dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng

Các phương pháp phát triển phần mềm linh hoạt hiện nay bao gồm: Extreme programming (XP), Scrum, Crystal family of methodologies, Feature Driven Development (FDD), The Rational Unified Process, Dynamic Systems Development Menthod (DSDM), Adaptive Software Development, Open Sourse Software Development, ngoài ra còn có các phương pháp khác

1.5 Giới thiệu Scrum

1.5.1 Giới thiệu

Scrum là một phương pháp Agile dùng cho phát triển sản phẩm Scrum là một khung quản lý dự án được áp dụng rất rộng rãi, từ những dự án đơn giản với một nhóm phát triển nhỏ cho đến những dự án có yêu cầu rất phức tạp với hàng trăm người tham gia, và kể cả những dự án đòi hỏi khung thời gian cố định Trong Scrum, công việc được thực hiện bởi nhóm Scrum thông qua từng phân đoạn lặp liên tiếp nhau được gọi

là Sprint Để hiểu được Scrum thì cần hiểu nguyên lý của Scrum, các Vai trò, Tạo tác,

Sự kiện và sự vận hành của một vòng đời Scrum

Cốt lõi của qui trình Scrum đó là Sprint, một vòng thời gian của một tháng hoặc

ít hơn, sự phát triển và tung ra sản phẩm có tiềm năng, hữu dụng được tạo ra Những Sprints tối ưu là sprint có thời hạn thông qua sự nỗ lực phát triển Sprint mới sẽ bắt đầu ngày sau khi Sprint trước kết thúc Trong mỗi Sprint:

- Không có sự thay đổi được thực hiện nhằm duy trì được kết quả của Sprint đó

- Chất lượng kết quả không được giảm và có thể làm rõ và thảo luận lại bởi chủ sản phẩm và đội phát triển

1.5.2 Khung làm việc Scrum

b) Thanh tra (Inspection): Công tác thanh tra liên tục các hoạt động trong scrum bảo đảm cho việc phát triển các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án Với việc truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và cải tiến liên tục trong Scrum

c) Thích nghi (Adaptation): Scrum là một trong những phương pháp phát triển rất linh hoạt Nhờ đó mang lại tinh thích nghi rất cao Scrum có thể phản hồi lại các thay đổi một cách tích cực nhờ đó mang lại nhiều thành công lớn cho dự án

ScrumMaster: Là người đảm bảo Nhóm Scrum hoạt động năng suất nhất thông qua việc áp dụng tốt Scrum ScrumMaster không phải là người quản lý của các thành viên Nhóm Phát triển, cũng không phải là quản lý dự án, trưởng nhóm, hay đại diện của nhóm Thay vào đó, ScrumMaster phục vụ Nhóm Phát triển; là người giúp loại bỏ

các trở ngại, bảo vệ Nhóm Phát triển khỏi các tác động từ bên ngoài, và trợ giúp Nhóm Phát triển ứng dụng các kỹ thuật phát triển hiện đại ScrumMaster cũng dạy, huấn luyện và hướng dẫn Product Owner

Để đạt được điều này thì ScrumMaster có thể sử dụng một số kỹ thuật như dạy, huấn luyện để nhóm am hiểu về triết lý cũng như áp dụng tốt các kỹ thuật thực tế sử dụng trong Scrum ScrumMaster cũng có nhiệm vụ loại bỏ tất cả các trở ngại mà nhóm gặp phải, bảo vệ nhóm trước tất cả những nguyên nhân gây ảnh hưởng tới công việc của nhóm

Nhóm Phát triển: Là tập hợp của từ 3 đến 9 thành viên chịu trách nhiệm trực tiếp tham gia sản xuất Hai tính chất quan trọng nhất của Nhóm Phát triển đó là tự-tổ chức và liên-chức năng Tự-tổ chức tức là các thành viên tự sắp xếp công việc, tự đưa

ra các quyết định để đạt được mục đích của nhóm mà không bị sự quản lý, điều khiển

từ bất cứ ai bên ngoài nhóm, kể cả các lãnh đạo Liên-chức năng có nghĩa là nhóm có đầy đủ tất cả các kỹ năng cần thiết để có thể độc lập hoàn thành tất cả các công việc

mà không cần chờ đợi ai khác từ bên ngoài Nhóm liên-chức năng tức là nhóm có đầy

đủ các kỹ năng chứ không phải là mỗi thành viên đều phải có hết tất cả các kỹ năng

Ngoài ba vai trò kể trên, còn có các bên liên quan khác đóng góp vào sự thành công của sản phẩm, bao gồm các nhà quản lý, khách hàng và người dùng cuối Một vài người liên quan chẳng hạn như những người quản lý chức năng (ví dụ, người quản lý

kỹ thuật) có thể thấy vai trò của họ nếu còn giá trị thì cũng thay đổi khi áp dụng Scrum Ví dụ:

Họ hỗ trợ Nhóm Phát triển bằng cách tôn trọng các quy tắc và tinh thần của Scrum

Họ giúp loại bỏ các trở ngại mà Nhóm Phát triển và Product Owner chỉ ra

Họ sẵn sàng đóng góp chuyên môn và kinh nghiệm của mình

c Năm cuộc họp: [6]

1 Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint (xem thêm phần Sprint bên dưới) Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm

2 Daily Scrum (Họp Scrum hằng ngày): Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint

3 Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua

và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm

4 Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua

và đề xuất các chỉnh sửa hoặc thay đổi cần thiết

5 Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm

d Ba công cụ: [6]

- Product Backlog: Khi một nhóm dự định chuyển sang Scrum thì trước khi có thể bắt đầu Sprint đầu tiên họ cần có một Product Backlog, đây là danh sách các hạng mục cần phát triển của sản phẩm Danh sách này được sắp xếp theo độ ưu tiên do Product Owner quyết định Product Owner là người chịu trách nhiệm quản lý Product Backlog, kể cả nội dung, đánh giá độ ưu tiên cho đến việc cập nhật Product Owner cần phải đưa ra các quyết định đánh giá ưu tiên xuyên suốt toàn bộ phạm vi, đại diện cho quyền lợi của các bên liên quan (bao gồm cả Nhóm Phát triển) Các hạng mục trong Product Backlog có thể là các tính năng mong muốn của sản phẩm, hoặc các cải tiến

kỹ thuật lớn, hoặc các lỗi kỹ thuật đã được phát hiện… Product Backlog tồn tại (và tiến hóa) trong suốt vòng đời của sản phẩm; nó cũng là lộ trình của sản phẩm

Một Product Backlog tốt cần đạt được tiêu chí DEEP

Detailed Appropriately (Chi tiết hợp lý): Các hạng mục có độ ưu tiên cao cần được làm mịn và chi tiết hơn so với hạng mục có ưu tiên thấp hơn vì chúng sẽ được lựa chọn để thực hiện trước

Estimated (được ước lượng) - Mỗi hạng mục cần có khối lượng công việc ước tính cùng một số thông số khác

Emergent (Tiến hóa) - Trong mỗi Sprint, các hạng mục có thể được thêm vào, xóa đi, hoặc thay đổi, chia nhỏ và thay đổi độ ưu tiên Product Backlog luôn được cập nhật bởi Product Owner để thể hiện các thay đổi trong nhu cầu của khách hàng, các ý tưởng hoặc hiểu biết mới, động thái của các đối thủ cạnh tranh, các rào cản kỹ thuật vừa xuất hiện v.v…

Prioritized (Sắp xếp theo độ ưu tiên), các hạng mục có độ ưu tiên cao hơn nằm

ở phía trên của Product Backlog Tiêu chí sắp xếp độ ưu tiên dựa trên Lợi ích tương xứng với đồng tiền bạn bỏ ra, nhiều lợi ích với ít tiền nhất Một lý do khác có thể dẫn đến tăng độ ưu tiên của một hạng mục là nhằm giải quyết sớm các rủi ro lớn trước khi chúng tấn công bạn

Để ước tính khối lượng công việc (Estimated), một kỹ thuật phổ biến đó là ước tính theo kích thước tương đối (hệ số nỗ lực, độ phức tạp và tính bất định) gọi là “story point” trong sự thống nhất, tương quan và mặt bằng chung của cả nhóm

Một lợi thế của Scrum là nhờ vào việc ước tính khối lượng công việc tốt, Product Owner có thể theo dõi lượng công việc hoàn thành trong mỗi Sprint: Ví dụ, trung bình Team hoàn thành 26 point cho một Sprint Với thông tin này, nếu giá trị trung bình được giữ nguyên và không có gì khác thay đổi, người ta có thể trù liệu được ngày phát hành (đợt Release) mà tất cả các tính năng (dự kiến sẽ ra mắt) đều được hoàn thành Giá trị trung bình này được gọi là “tốc độ” (velocity) Tốc độ được biểu diễn cùng đơn vị với ước tính kích thước của hạng mục Product Backlog

Các hạng mục lớn trong Product Backlog cần được làm mịn + chia nhỏ hơn trong buổi họp Sprint Planning Và các hạng mục nhỏ có thể được hợp nhất lại với nhau

Phần lớn thời gian của nhóm Phát triển là dành cho các mục tiêu của Product Owner chứ không phải là các công việc kỹ thuật nội bộ mặc dù nhóm Phát triển có quyền độc lập trong việc quyết định số lượng hạng mục được đưa vào trong một Sprint

Không nên mô tả tất cả mọi chi tiết có thể có của một hạng mục mà chỉ nên làm

rõ những gì cần thiết đủ để hiểu tốt hạng mục đó

- Sprint Backlog (tạo tác): Là danh sách chứa các hạng mục Product Backlog được lựa chọn cho Sprint hiện tại và các công việc cần thực hiện để hoàn thành các hạng mục đó Sprint Backlog có thể chứa thêm thông tin về các ước tính khối lượng

công việc của từng hạng mục và của cả Sprint Sprint Backlog được quản lý bởi Nhóm Phát triển

Phần tăng trưởng Sản phẩm (tạo tác): Đôi khi còn được gọi ngắn gọi là Phần tăng trưởng Là kết quả “hoàn thành” được Nhóm Phát triển chuyển giao sau mỗi Sprint Để được coi là “hoàn thành” thì các hạng mục Product Backlog phải thỏa mãn với Định nghĩa Hoàn thành đã được thống nhất trước đó Tính chất cốt lõi của Phần tăng trưởng đó là có khả năng chuyển giao được, tức là có thể đưa vào sử dụng ngay

mà không cần làm thêm bất cứ công việc nào nữa

Sprint: Là khoảng thời gian cố định mà ở đó Nhóm Phát triển thực hiện công việc phát triển sản phẩm Sprint được đóng khung thời gian ngắn hơn 1 tháng và thường thì không ngắn hơn một tuần Các Sprint có độ dài như nhau và diễn ra liên tiếp nhau mà không bị gián đoạn Sprint kết thúc khi thời gian đóng khung kết thúc, bất kể các công việc trong đó đã được hoàn thành hết hay chưa

Lập kế hoạch Sprint (sự kiện): Sự kiện diễn ra đầu Sprint để lên kế hoạch làm việc cho toàn bộ Sprint Sự kiện này được chia làm 2 phần với 2 mục đích rõ ràng: Phần 1 nhằm trả lời câu hỏi “Mình sẽ làm cái gì?”, còn Phần 2 nhằm trả lời câu hỏi

“Mình sẽ làm như thế nào?” Toàn bộ Nhóm Scrum (bao gồm Product Owner, ScrumMaster và Nhóm Phát triển) phải tham dự Phần 1 của buổi Lập kế hoạch Sprint Product Owner có thể vắng mặt ở Phần 2 nhưng phải đảm bảo sẵn sàng (có thể là qua điện thoại, công cụ chat…) để giải đáp các thắc mắc của Nhóm Phát triển nếu có Nhóm Phát triển có quyền quyết định lựa chọn những hạng mục mà mình sẽ làm, không ai được phép can thiệp và gán công việc cho nhóm, kể cả Product Owner hay các lãnh đạo khác Kết quả của buổi Lập kế hoạch Sprint là: Mục tiêu Sprint và Sprint Backlog

Mục tiêu Sprint: Là một hoặc một vài câu mô tả tổng quan về kết quả mà Product Owner mong muốn đạt được khi Sprint kết thúc Khi một Sprint diễn ra, Sprint Backlog có thể có thay đổi nhỏ nhưng Mục tiêu Sprint thì phải ổn định

Scrum Hằng ngày (sự kiện): Là buổi gặp mặt ngắn 15 phút hằng ngày của tất cả các thành viên Nhóm Phát triển để cập nhật thông tin và phối hợp giữa các thành viên trong nhóm Để giữ đơn giản và tạo thói quen thì các buổi Scrum Hằng ngày phải diễn

ra tại cùng một địa điểm vào cùng một khung thời gian Tại phiên làm việc này, mỗi thành viên sẽ trình bày câu trả lời cho 3 câu hỏi: “Mình đã làm những gì từ buổi gặp mặt hôm trước tới nay?”, “Mình sẽ làm những gì từ bây giờ cho đến buổi gặp mặt sau?”, “Tôi gặp phải khó khăn gì?” ScrumMaster không bắt buộc tham dự nhưng phải đảm bảo Nhóm Phát triển đang thực hiện tốt sự kiện này

Sơ kết Sprint (sự kiện): Diễn ra khi một Sprint kết thúc nhằm thanh tra và thích nghi sản phẩm Toàn bộ Nhóm Scrum (bao gồm Product Owner, ScrumMaster và Nhóm Phát triển) tham dự sự kiện này Product Owner có thể mời thêm những người khác cùng tham gia Hai nội dung quan trọng của sự kiện này là: Dùng thử phần sản phẩm vừa hoàn thành trong Sprint vừa qua và Trao đổi với tất cả mọi người để có những điều chỉnh hợp lý cho sản phẩm Product Baclog và Kế hoạch Phát hành có thể được điều chỉnh sau sự kiện này

Cải tiến Sprint (sự kiện): Diễn ra sau sự kiện sơ kết Sprint nhằm thanh tra và thích nghi quy trình làm việc Nói ngắn gọn, sự kiện này là để cải tiến cách làm việc Nhóm Phát triển và ScrumMaster bắt buộc tham gia sự kiện này Product Owner có thể tham gia hoặc không Nhóm Phát triển có thể mời thêm những người khác tham

dự Kết quả của buổi làm việc này là một danh sách các thay đổi về cách làm việc được đưa vào áp dụng ngay trong Sprint tiếp theo

- Burndown Chart: Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart) Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của

nó

1.5.3 Nguyên lý hoạt động của scrum:

Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống Các tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và đánh giá lại sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra

Hình 1.2 Quy trình hoạt động Scrum

CHƯƠNG II LOGIC MỜ VÀ ỨNG DỤNG 2.1 Cơ sở lý thuyết

2.1.1 Cơ sở lý thuyết về logic mờ

Năm 1965 đã ra đời một lý thuyết mới, đó là lý thuyết tập mờ (Fuzzy set theory) do giáo sư Lotfi A Zadeh ở trường đại học Califonia – Berkeley (Mỹ) đưa ra

Từ khi lý thuyết đó ra đời nó được phát triển mạnh mẽ qua các công trình của nhiều nhà khoa học trên thế giới Năm 1972 các giáo sư Terano và Asai thiết lập ra cơ

sở nghiên cứu hệ thống điều khiển mờ ở Nhật Bản Năm 1980 hãng Smith Co bắt đầu nghiên cứu điều khiển mờ cho lò hơi Từ những năm đầu thập kỷ 90 thế kỷ trước cho đến nay hệ thống điều khiển mờ (Fuzzy control system) được các nhà khoa học, các kỹ

sư và sinh viên trong mọi lĩnh vực khoa học kỹ thuật đặc biệt quan tâm nghiên cứu và ứng dụng trong sản xuất và đời sống

2.1.2 Cơ sở toán học của logic mờ

Logic mờ và xác suất thống kê đều nói về sự không chắn chắn Tuy nhiên mỗi lĩnh vực đưa ra một khái niệm khác nhau về đối tượng

Trong xác suất thống kê sự không chắc chắn liên quan đến sự xuất hiện của một

sự kiện “chắc chắn” nào đó Ví dụ: Xác suất mũi tên trúng đích là 0.6 Bản thân sự kiện “trúng đích” đã được định nghĩa rõ ràng, sự không chắc chắn ở đây là có trúng đích hay không, và được định lượng bởi mức độ xác suất (trong trường hợp này là 0.6) Loại phát biểu này có thể được xử lý và kết hợp với các phát biểu khác bằng phương pháp thống kê, như là xác suất có điều kiện chẳng hạn

Logic mờ lại liên quan đến sự không chắc chắn trong cách dùng ngữ nghĩa, trong ngôn ngữ của con người Đó là sự không chính xác trong các từ ngữ mà con người dùng để ước lượng vấn đề và rút ra kết luận Ví dụ như các từ mô tả tốc độ chạy

xe là “nhanh”, “chậm” hay “trung bình” sẽ không có một giá trị chính xác nào để gán cho các từ này, các khái niệm này cũng khác nhau đối với những người khác nhau (là nhanh đối với người này nhưng không nhanh đối với người khác) Mặc dù các khái niệm không được định nghĩa chính xác nhưng con người vẫn có thể sử dụng chúng cho các ước lượng và quyết định phức tạp Bằng sự trừu tượng và óc suy nghĩ, con người

có thể giải quyết câu nói mang ngữ cảnh phức tạp mà rất khó có thể mô tả toán học chính xác

Trong thực tế, ta không định nghĩa một luật cho một trường hợp mà định nghĩa một

số luật cho các trường hợp nhất định Khi đó những luật này là những điểm rời rạc của một tập các trường hợp liên tục và con người xấp xỉ chúng Gặp một tình huống cụ thể, con người sẽ kết hợp những luật mô tả các tình huống tương tự Sự xấp xỉ này dựa trên

sự linh hoạt của các từ ngữ cấu tạo nên luật, cũng như sự trừu tượng và sự suy nghĩ dựa trên sự linh hoạt trong logic của con người

Để thực thi logic của con người trong kỹ thuật cần phải có một mô hình toán học của nó Từ đó logic mờ ra đời như một mô hình toán học cho phép mô tả các quá trình quyết định và ước lượng của con người theo dạng thuật giải Dĩ nhiên cũng có giới hạn, đó là logic mờ không thể bắt chước trí tưởng tượng và khả năng sáng tạo của con người Tuy nhiên, logic mờ cho phép ta rút ra kết luận khi gặp những tình huống không có mô tả trong luật nhưng có sự tương đương Vì vậy, nếu ta mô tả những mong muốn của mình đối với hệ thống trong những trường hợp cụ thể vào luật thì logic mờ

sẽ tạo ra giải pháp dựa trên tất cả những mong muốn đó

2.1.3 Khái niệm về tập mờ [10]

a Tập kinh điển

Khái niệm tập hợp được hình thành trên nền tảng logic và được định nghĩa như

là sự sắp xếp chung các đối tượng có cùng tính chất, được gọi là phần tử của tập hợp

đó

Cho một tập hợp A, một phần tử x thuộc A được ký hiệu: x A Thông thường

ta dùng hai cách để biểu diễn tập hợp kinh điển, đó là:

- Liệt kê các phần tử của tập hợp, ví dụ: tập A1 = {xe đạp, xe máy, xe ca, xe tải}

- Biểu diễn tập hợp thông qua tính chất tổng quát của các phần tử, ví dụ: tập các

số thực R, tập các số tự nhiên N

Để biểu diễn một tập hợp A trên tập nền X, ta dùng hàm thuộc μA( x ), với:

A x khi 0

A x khi 1 ) x (

nhƣ trên sẽ không phù hợp với những tập đƣợc mô tả “mờ” nhƣ tập B gồm các số thực gần bằng 5:

5 x R x B

Khi đó ta không thể khẳng định chắc chắn số 4 có thuộc B hay không, mà chỉ

có thể nói nó thuộc B bao nhiêu phần trăm Để trả lời đƣợc câu hỏi này, ta phải coi hàm phụ thuộc μB( x ) có giá trị trong khoảng từ 0 đến 1 tức là: 0 μB( x ) 1

Từ phân tích trên ta có định nghĩa: Tập mờ B xác định trên tập kinh điển M là một tập mà mỗi phần tử của nó đƣợc biểu diễn bởi một cặp giá trị (x, μB( x ))

x

x

μB

0.5 1

4 5 6 0

Hình 2.2: Hàm liên thuộc của tập mờ

Khi đó x M và μB( x ) là ánh xạ Ánh xạ μB( x ) đƣợc gọi là hàm liên thuộc của tập mờ B Tập kinh điển M đƣợc gọi là cơ sở của tập mờ B

c Các thông số đặc trưng cho tập mờ

Các thông số đặc trƣng cho tập mờ là độ cao, miền xác định và miền tin cậy đƣợc thể hiện trên hình 2.3:

Hình 2.3: Độ cao, miền xác định, miền tin cậy của tập mờ

- Độ cao của một tập mờ B (Định nghĩa trên cơ sở M) là giá trị lớn nhất trong các giá trị của hàm liên thuộc:

) x ( μ Sup

M x

Một tập mờ có ít nhất một phần tử có độ phụ thuộc bằng 1 được gọi là tập mờ chính tắc (H = 1) Ngược lại, một tập mờ B với H < 1 gọi là tập mờ không chính tắc

- Miền xác định của tập mờ B (định nghĩa trên cơ sở M) được ký hiệu bởi S, là tập con của M có giá trị hàm liên thuộc khác 0:

0 ) x ( μ M x

- Miền tin cậy của tập mờ B (định nghĩa trên cơ sở M) được ký hiệu bởi T, là tập con của M có giá trị hàm liên thuộc bằng 1:

1 ) x ( μ M x

0 0.2 0.4 0.6 0.8 1

0.4

0 0.2

0.6 0.8 1

e)

0.2 0.4 0.6

d)

0

0.8 1

0.8

Hình 2.4: Các dạng hàm liên thuộc của tập mờ

Có rất nhiều cách khác nhau để biểu diễn hàm liên thuộc của tập mờ Dưới đây

là một số dạng hàm liên thuộc thông dụng:

- Hàm liên thuộc hình tam giác (hình 2.4a)

- Hàm liên thuộc hình thang (hình 2.4b)

- Hàm liên thuộc dạng Gauss (hình 2.4c)

- Hàm liên thuộc dạng Sigmoidal (hình 2.4d)

- Hàm liên thuộc hình quả chuông (hình 2.4e)

2.1.4 Các phép toán của tập mờ

a Phép hợp hai tập mờ

- Hợp của hai tập mờ có cùng cơ sở:

μB(x)

μA

x μ

Hình 2.5: Hợp của hai tập mờ có cùng cơ sở theo qui tắc Max (a) và theo Lukasiewiez

(b)

Hợp của hai tập mờ A và B có cùng cơ sở M là một tập mờ cũng xác định trên

cơ sở M với hàm liên thuộc đƣợc xác định theo một trong các công thức sau:

1 μA B( x ) max μA(x), μB(x)

2 μA B( x ) min 1 μA(x) μB(x) (phép hợp Lukasiewiez)

3

0 (x) μ (x), μ min khi 1

0 (x) μ (x), μ min khi (x) μ (x), μ max )

x ( μ

B A

B A B

A B

A

4

(x) μ (x) μ 1

(x) μ (x) μ (x) μ

B A

B A

và tập mờ B với hàm liên thuộc μB( y ) đƣợc định nghĩa trên cơ sở N, hợp của 2 tập mờ

A và B là một tập mờ xác định trên cơ sở M N với hàm liên thuộc:

y) (x, μ y), (x, μ max ) y x, (

trong đó μA(x, y) μA(x) với mọi y N và μB(x, y) μB(y) với mọi x M

b Phép giao của hai tập mờ

- Giao hai tập mờ cùng cơ sở:

Giao của hai tập mờ A và B có cùng cơ sở M là một tập mờ cũng xác định trên

cơ sở M với hàm liên thuộc μA B( x ) đƣợc tính bằng một trong các công thức sau:

1 μA B( x ) min μA(x), μB(x)

2 μA B(x) μA(x) μB(x) (tích đại số)

3

1 (x) μ (x), μ max khi 0

1 (x) μ (x), μ min khi (x) μ (x), μ min )

x ( μ

B A

B A B

A B

A

4 μA B(x) max 0, μA(x) μB(x) 1 (phép giao Lukasiewiez)

5

(x) μ (x) μ (x)) μ (x) μ ( 2

(x) μ (x).

μ (x)

μ

B A B

A

B A B

(x)

μB(x)

μA

x μ

- Giao hai tập mờ khác cơ sở:

Để thực hiện phép giao 2 tập mờ khác cơ sở ta cần phải đƣa về cùng cơ sở Khi

đó, giao của tập mờ A có hàm liên thuộc μA(x) định nghĩa trên cơ sở M với tập mờ B

có hàm liên thuộc μB(y) định nghĩa trên cơ sở N là một tập mờ xác định trên cơ sở

N

M có hàm liên thuộc đƣợc tính nhƣ sau:

y) (x, μ y), (x, μ min ) y x, (

trong đó μA(x, y) μA(x) với mọi y N và μB(x, y) μB(y) với mọi x M

c Phép bù của một tập mờ

Lôgic mờ (Fuzzy logic) được phát triển từ lý thuyết tập mờ để thực hiện lập luận

một cách xấp xỉ thay vì lập luận chính xác theo logic vị từ cổ điển Người ta hay nhầm lẫn mức độ đúng với xác suất Tuy nhiên, hai khái niệm này khác hẳn nhau; độ đúng đắn của lôgic mờ biểu diễn độ liên thuộc với các tập được định nghĩa không rõ ràng, chứ không phải khả năng xảy ra một biến cố hay điều kiện nào đó

Lôgic mờ cho phép độ liên thuộc có giá trị trong khoảng đóng 0 và 1, và ở hình thức ngôn từ, các khái niệm không chính xác như "hơi hơi", "gần như", "khá là" và

"rất" Cụ thể, nó cho phép quan hệ thành viên không đầy đủ giữa thành viên và tập hợp Tính chất này có liên quan đến tập mờ và lý thuyết xác suất

Ví dụ khác để minh họa cho Logic mờ

Nhìn ở hình vẽ trên, nếu như đối với Boolean Logic quy định tuổi dưới 23 mới được coi là “trẻ tuổi” thì ở Fuzzy Logic, có sự xác định mềm dẻo hơn khi không quy định khắt khe chính xác bao nhiêu tuổi mới là trẻ Điều này hợp hơn với thực tế bởi vì đôi khi tuổi tác còn do con người cảm nhận, có người coi dưới 23 tuổi là trẻ còn có người coi trên 23 tuổi một vài năm vẫn là trẻ, hoặc dưới 23 tuổi một vài năm đã không còn là trẻ nữa Qua đó ở ví dụ này ta thấy các giá trị Fuzzy mềm dẻo hơn rất nhiều so với Boolean Logic, phù hợp hơn với người dùng

Các luật trong hệ logic mờ mô tả tri thức của hệ Chúng dùng các biến ngôn ngữ như là từ vựng để mô tả các tầng điều khiển trong hệ Việc giải thích các luật mờ cũng

là việc trình bày cách tính các khái niệm ngôn ngữ

Khái niệm biến ngôn ngữ đã được Zadeh đưa ra năm 1973 như sau:

 Một biến ngôn ngữ được xác định bởi bộ (x, T, U, M)

trong đó: x là tên biến Ví dụ: “nhiệt độ”, “tốc độ”, “độ ẩm”,…

 T là tập các từ là các giá trị ngôn ngữ tự nhiên mà x có thể nhận

Ví dụ: x là “tốc độ” thì T có thể là {“chậm”, “trung bình”, “nhanh”}

 U là miền các giá trị vật lý mà x có thể nhận

Ví dụ: x là “tốc độ” thì U có thể là {0km/h,1km/h, …, 150km/h}

 M là luật ngữ nghĩa, ứng mỗi từ trong T với một tập mờ At trong U

Từ định nghĩa trên chúng ta có thể nói rằng biến ngôn ngữ là biến có thể nhận giá trị là các tập mờ trên một vũ trụ nào đó

2.2.3 Mệnh đề mờ

Trong logic cổ điển (logic vị từ cấp một), một mệnh đề phân tử P(x) là một phát

biểu có dạng “x là P” trong đó x là một đối tượng trong một vũ trụ U nào đó thoả tính chất P Ví dụ “x là số chẵn” thì U là tập các số nguyên và P là tính chất chia hết cho 2 Như vậy ta có thể đồng nhất một mệnh đề phân tử “x là P” với một tập (rõ) A = x

U | P(x)

Từ đó ta có:

P(x) = (x) Trong đó là hàm đặc trưng của tập A (x A  (x) = 1) Giá trị chân lý của P(x) chỉ nhận một trong hai giá trị 1 và 0 (true và false) tương ứng với sự kiện x thuộc A hoặc không

Trong trường hợp P là một tính chất mờ chẳng hạn như “số lớn” thì ta sẽ có một mệnh đề logic mờ phần tử Khi đó tập hợp các phần tử trong vũ trụ U thoả P là một tập

mờ B có hàm thuộc Bsao cho:

P(x) = B(x)

Lúc này P(x) có thể nhận các giá trị tuỳ ý trong [0,1] Và ta thấy có thể đồng nhất các hàm thuộc với các mệnh đề logic mờ

Ví dụ các mệnh đề mờ sau:

NẾU trời nóng THÌ tốc độ quạt lớn

NẾU nhiệt độ rất cao THÌ áp suất phải giảm rất thấp

Các mệnh đề trên là một ví dụ đơn giản về điều khiển mờ, nó cho phép từ một giá trị đầu vào x0 của mệnh đề điều kiện (hoặc từ độ phụ thuộc μA(x0) của x0 trên tập mờ A) xác định được hệ số thỏa mãn mệnh đề kết luận q của giá trị đầu ra y

P(x) Q(y) = min(P(x), Q(y))

P(x) Q(y) = max(P(x), Q(y))

P(x) =>Q(y) = P(x) Q(y) = max(1-P(x), Q(y))

P(x) =>Q(y) = P(x) (P(x) Q(y)) = max(1-P(x), min(P(x), Q(y)))

Như vậy, ta sẽ có mở rộng một cách tự nhiên từ logic cổ điển sang logic mờ với quy tắc tổng quát hoá dùng hàm bù mờ cho phép phủ định, hàm T-norm cho phép giao ( )

và S-norm cho phép hợp ( ) Sự mở rộng này dựa trên sự tương quan giữa mệnh đề logic mờ với hàm mờ và các phép toán trên tập mờ Ta có:

Trong đó C là hàm bù mờ (hay phủ định mờ), T là hàm T-norm, S là hàm S-norm

Phép toán kéo theo mờ

Các phép toán kéo theo có vai trò quan trọng trong logic mờ Chúng tạo nên các luật mờ để thực hiện các phép suy diễn trong tất cả các hệ mờ Do một mệnh đề mờ tương ứng với một tập mờ nên ta có thể dùng hàm thuộc thay cho các mệnh đề

 Sau đây là một số phép kéo theo quan trọng được sử dụng rộng rãi:

 Phép kéo theo Dienes – Rescher