Tải bản đầy đủ (.pdf) (165 trang)

Đề xuất mô hình sản xuất phần mềm theo Lean, một nghiên cứu tình huống tại thành phố Hồ Chí Minh

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.68 MB, 165 trang )

CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI 8
1.1 Lý do hình thành đề tài 8
1.2 Mục tiêu nghiên cứu và câu hỏi nghiên cứu 9
1.3 Phạm vi, giới hạn đề tài 11
1.4 Phương pháp nghiên cứu 11
1.5 Ý nghĩa của nghiên cứu 12
1.6 Bố cục luận văn 13
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 15
2.1 Phần mềm và các khái niệm liên quan 15
2.1.1 Phần mềm 15
2.1.2 Quy trình phát triển phần mềm 15
2.2 Tổng quan mô hình phát triển truyền thống 17
2.2.1 Mô hình thác nước (Waterfall) 17
2.2.2 Những thất bại của mô hình truyền thống 20
2.3 Các mô hình phát triển phần mềm linh hoạt 21
2.3.1 Tổng quan về phát triển phần mềm linh hoạt 21
2.3.2 Lập trình Scrum 24
2.3.3 Sự khác nhau giữa mô hình truyền thống và mô hình linh hoạt 25
2.3.4 Những điểm mạnh và điểm yếu của phương pháp truyền thống và linh
hoạt 27
2.4 Phương pháp sản xuất Lean 28
2.4.1 Triết lí Lean 29
2.4.2 Lean trong sản xuất các sản phẩm khác (không phải phần mềm) 30
2.4.3 Các lĩnh vực sản xuất áp dụng phương pháp Lean 30
2.5 Sản xuất phần mềm theo phương pháp Lean 32
2.5.1 Sự khác biệt giữa phương pháp Lean vàphương phápAgile 33
2.5.2 Các nguyên tắc Lean 34
2.5.3 Tổng hợp các nguyên tắc Lean trong SXPM 41
2.5.4 Các công cụ và thực hành Lean (Tool & Best Practice) 45
Trang 2


GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
2.5.5 Tổng hợp các nguyên tắc và thực hành Lean cho ngành SXPM 52
2.6 Cách thức triển khai Lean 54
2.6.1 Mô hình triển khai chuyển đổi Leancủa Phillip Magnier (2008) 54
2.6.2 Mô hình triển khai Lean 8 bước của Lonnie Wilson 2010 58
2.6.3 Mô hình triển khai Lean của tổ chức tư vấn CICC 60
2.6.4 Mô hình triển khai Lean của Anvari và cộng sự 2010 61
2.6.5 Mô hình của Kotter cho các doanh nghiệp CNTT 2011 62
2.6.6 Mô hình triển khai Lean tổng hợp của Avari và cộng sự 2011 64
2.6.7 Phân tích so sánh và lựa chọn mô hình 70
CHƯƠNG 3: PHƯƠNG PHÁP NGHIÊN CỨU 73
3.1 Chiến lược nghiên cứu định tính 73
3.2 Thiết kế nghiên cứu tình huống 74
3.3 Thiết kế nghiên cứu 77
3.4 Phương pháp thu thập dữ liệu 78
3.5 Phương pháp phân tích dữ liệu và lý giải 82
3.6 Xác minh 83
CHƯƠNG 4: KẾT QUẢ 84
4.1 Xem xét các nguyên tắc Lean áp dụng trong SXPM 84
4.2 Đánh giá tính khả thi của mô hình triển khai Lean 87
4.2.1 Giai đoạn điều tra ban đầu 87
4.2.2 Giai đoạn 1: Chuẩn bị 88
4.2.3 Giai đoạn 2: triển khai phương pháp Lean cho dự án thí điểm 89
4.2.4 Giai đoạn 3: Mở rộng cho toàn hệ thống 91
4.2.5 Giai đoạn 4: Tiến tới sự hoàn hảo 92
4.3 Về thời gian triển khai 95
4.3.1 Thời gian triển khai dự án thí điểm 95
4.3.2 Thời gian triển khai Lean cho toàn công ty 96
4.4 Khó khăn và thử thách khi triển khai phương pháp Lean 97
CHƯƠNG 5: KẾT LUẬN 101

Trang 3

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm

5.1 Trả lời câu hỏi nghiên cứu 101
5.2 Hạn chế của nghiên cứu 103
5.3 Hướng nghiên cứu tiếp theo 103
TÀI LIỆU THAM KHẢO 105
PHỤ LỤC 108
PHỤ LỤC 1: Thông tin chuyên gia Đoàn Đức Đề (mã CG1) 108
PHỤ LỤC 2: Thông tin chuyên gia Ngô Sơn Dương (mã CG2) 110
PHỤ LỤC 3: Thông tin Thạc sĩ Ngô Nguyễn Lộc Nguyên (mã ThS1) 114
PHỤ LỤC 4: Thông tin chuyên gia Trương Đắc Bình (mã CG4) 116
PHỤ LỤC 5: Nội dung thảo luận CG1 118
PHỤ LỤC 6: Nội dung thảo luận CG2 124
PHỤ LỤC 7: Nội dung thảo luận ThS1 135
PHỤ LỤC 8: Nội dung thảo luận CG4 146
PHỤ LỤC 9: Bảng câu hỏi bán cấu trúc 157
PHỤ LỤC 10: Bảng tổng hợp các nguyên tắc Lean 160
PHỤ LỤC 11: Những đề xuất cho nhà lãnh đạo khi chuyển đổi Lean 162

Trang 4

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
DANH MỤC HÌNH
Hình 2-1 Các mô hình sản xuất phần mềm được sử dụng rộng rãi 16
Hình 2-2: Mô hình thác nước (Waterfall) 18
Hình 2-3: Độ phân tán của dự án 20
Hình 2-4: Phương pháp phát triển linh hoạt (SCRUM) 25
Hình 2-5: Lịch sử phát triển các mô hình sản xuất 29

Hình 2-6: Các lĩnh vực áp dụng Lean và các thực hành được đề nghị 31
Hình 2-7: Các nguyên tắc Lean của Womack and Jones 2003 35
Hình 2-8: Ví dụ về hệ thống Kéo, Kanban trong SXPM 50
Hình 2-9: Mô hình chuyển đổi Lean của Phillip Magnier 2008 55
Hình 2-10: Ba giai đoạn và 21 bước triển khai Lean 62
Hình 2-11: Các giai đoạn chuyển đổi Lean trong ngành CNTT (Kotter 2011) 63
Hinh 2-12: Mô hình triển khai Lean tổng hợp của Avari và cộng sự 2011 66
Hình 3-1: Quy trình nghiên cứu 78
Hình 4-1: Các công việc được thể hiện trong một bảng Kanban 90
Hình 4-2: Mô hình chuyển đổi Lean sau điều chỉnh (Anvari và cộng sự, 2011) 94
Hình 4-3: Ví dụ về công cụ phần mềm “Kanban board” 100


Trang 5

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
DANH MỤC BẢNG BIỂU
Bảng 2-1: Lịch sử phát triển của phương pháp linh hoạt và các tác giả nổi tiếng 22
Bảng 2-2: Tuyên ngôn của phương pháp lập trình linh hoạt 22
Bảng 2-3: 12 nguyên tắc sau bản tuyên ngôn lập trình linh hoạt 23
Bảng 2-4: Sự khác biệt cơ bản giữa mô hình truyền thống và linh hoạt 26
Bảng 2-5: Đặc điểm, điểm mạnh và điểm yếu của SX truyền thống và linh hoạt 27
Bảng 2-6: Những thực hành hiện tại và đề nghị thực hành Lean theo lĩnh vực 31
Bảng 2-7: Sự khác biệt giữa Lean và Agile về triết lý cốt lõi 33
Bảng 2-8: Các Nguyên tắc Lean của Liker & Morgan 2006 36
Bảng 2-9: Các nguyên tắc sản xuất Lean trong sản xuất phần mềm 40
Bảng 2-10: Lãng phí trong sản xuất và lãng phí trong SXPM 41
Bảng 2-11: Các công cụ và thực hành tương ứng với các nguyên tắc Lean 47
Bảng 2-12: Tóm tắt các nguyên tắc Lean trong SXPM 53
Bảng 2-13: So sánh ưu, nhược điểm của các mô hình 71

Bảng 3-1: Các phương pháp nghiên cứu định tính (Myers, M.2000) 73
Bảng 3-2: Chiến lược lựa chọn tình huống đơn lẻ hoặc đa tình huống 74
Bảng 3-3: Sự khác biệt giữa thảo luận trong NC định tính và NC định lượng 79
Bảng 3-4: Các bước phân tích dữ liệu và lý giải 82

Trang 6

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
DANH MỤC TỪ/THUẬT NGỮ VIẾT TẮT
STT
Từ viết
tắt
Tiếng Anh
Tiếng Việt
1
ASDM
Agile software development
method
Phương pháp phát triển phần
mềm linh hoạt
2
CI
Continuous improvement
Cải tiến liên tục
3
CNTT

Công nghệ thông tin
4
CMMI

Capability Maturity Model
Integration
Mô hình đánh giá mức độ tăng
trưởng và năng lực tổ chức về
mặt quy trình
5
JIT
Just in time
Đúng thời gian
6
LSD
Lean software development
Phát triển/Sản xuất phần mềm
tinh gọn
7
LPO
Lean promotion Office
Một nhóm chuyển đổi Lean,
nhóm này cung cấp cho các nhà
quản lý giá trị dòng hỗ trợ kỹ
thuật với:
• Đào tạo Lean
• Tiến hành hội thảo kaizen
• Đo lường sự tiến bộ, tiến trình
8
SCRUM
Scrum
Tên một phương pháp phát triển
phần mềm linh hoạt
9

SDLC
Software development life
cycle
Vòng đời phát triển/sản xuất
phần mềm
10
SEP
Softwar engineering process

11
Software
Process
Goaloriented set of
interrelated or interacting
activities which transforms
inputs into outputs in the
context of engineeringstyle
software development
Thiết lập mục tiêu định hướng
các hoạt động liên quan hoặc
tương tác với nhau mà biến đổi
đầu vào thành đầu ra trong bối
cảnh phát triển công nghệ phần
mềm (ISO / IEC 12207)
Trang 7

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
(ISO/IEC 12207)
12
SXPM


Sản xuất phần mềm
13
PM
Software
Phần mềm
14
TPS
Toyota Production System
Hệ thống sản xuất Toyota
15
TSDM
Traditional software
development method
Phương pháp phát triển phần
mềm truyền thống
16
VSM
Value Stream Mapping
Sơ đồ chuỗi giá trị
17
XP
Extreme programming
Lập trình cực đại



Trang 8

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm

CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI

1.1 Lý do hình thành đề tài
Ngành công nghiệp phần mềm đã và đang đóng góp to lớn cho nền kinh tếViệt
Nam.Tổng doanh thu công nghiệp CNTT Việt Nam năm 2012 đạt 25,5 tỷ USD,
tăng tới 86% so với năm 2011, theo số liệu của Sách trắng về CNTT-TT 2013 vừa
được Bộ TT&TT công bố tháng 7/2013. Theo đó, công nghiệp phần mềm đối mặt
với nhiều khó khăn do ảnh hưởng của kinh tế trong nước và thị trường nội địa nên
tốc độ tăng trưởng năm 2012 không còn giữ được mức như các năm trước, chỉ tăng
3,1% so với năm 2011, đạt trên 1,2 tỷ USD. Quy mô ngành công nghiệp phần mềm
tính tới tháng 04/2011: có hơn 1.000 doanh nghiệp phần mềm, tăng gần sáu lần so
với năm 2000, tổng số lao động ngành công nghiệp phần mềm là 64.000 người. Một
số doanh nghiệp có trên 1.000 lao động như FPT Software, TMA Solutions, CSC,
GCS, Logigear, Harvey Nash, VinaGame
Theo công bố của viện công nghệ SEI (2013), Việt Nam đã có 4 doanh nghiệp đạt
chứng chỉ cao nhất về quy trình quản lý chất lượng sản xuất phần mềm quốc tế
CMMI mức 5, 23 doanh nghiệp đạt CMM mức 3.
Tuy nhiên trong bài phân tích “Công nghiệp phần mềm Việt Nam mười năm thăng
trầm” (Hồng Nhung-Tuyết Ân, 2011), tác giả đã phỏng vấn các giám đốc điều hành
của các công ty phần mềm lớn tại Việt Nam như: TMA, Global CyberSoft, FPT,
GSC, và nhận thấy thực trạng ngành phần mềm Việt Nam phát triển chưa tương
xứng với tiềm năng và kỳ vọng. Hiện Việt Nam chưa có doanh nghiệp phần mềm
đủ tầm để phát triển các sản phẩm phần mềm ở quy mô lớn và chuyên ngành, cũng
chưa có sản phẩm có thương hiệu xuất khẩu.Một phần lý do được đưa ra là phương
thức sản xuất chưa có sự thay đổi để đáp ứng với điều kiện kinh tế ngày càng cạnh
tranh.
Trong những năm qua, nhiều "Phương thức sản xuất phần mềm tốt nhất" đã xuất
hiện và biến mất. Một loạt các phương thức mới xuất hiện từ những năm 1990 là
Trang 9


GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
phương thức sản xuất linh hoạt (Agile methodologies) như AUP, Scrum, XP, RUP,
và Lean (2003). Phát triển phần mềm tinh gọn (Lean) là một mô hình mới nổi thừa
kế các nguyên tắc Lean trong sản xuất để giảm thiểu chi phí và nâng cao chất lượng
theo thời gian. Lean manufacturing đã được áp dụng thành công đối với các công ty
sản xuất, vậy đối với phát triển phần mềm thì như thế nào? Và liệu các nguyên tắc
và thực hành sản xuất linh hoạt Lean có phải là một phương thức sản xuất tốt để tạo
rasản phẩm phần mềm chất lượng trong điều kiện cạnh tranh ngày càng gay gắt?
Thật khó có thể đưa ra kết luận, phương thức sản xuất nào tốt phụ thuộcvào bạnso
sánh nó với phương pháp nào, trong hoàn cảnh nào.
Phương pháp truyền thống để phát triển phần mềm dựa trên các nguyên tắc sản
xuất. Sản xuất được định nghĩa là hành động của việc tạo ra hoặc sản xuất một cách
cơ học, hoặc sự biến đổi của nguyên liệu thô thành sản phẩm hoàn chỉnh trong khi
đó phương pháp sản xuất tinh gọn là một phương pháp mới nổi thừa kế các nguyên
tắc và kỹ thuật Lean trong sản xuất và các nhà nghiên cứu cũng như các chuyên gia
trong lĩnh vực phát triển phần mềm chưa có nhiều nghiên cứu quan tâm đến nguyên
tắc và kỹ thuật, công cụLean cho lĩnh vực này. Do đó, có một nhu cầu mạnh mẽ cho
các nghiên cứu thực nghiệm trong lĩnh vực này, đề tài “Đề xuất mô hình sản xuất
phần mềm theo Lean, một nghiên cứu tình huống tại thành phố Hồ Chí Minh”.
Bài nghiên cứu này có thể coi là điểm khởi hành vì nó tổng hợp và các công trình
nghiên cứu, những đóng góp quan trọng nhất được cập nhật cho tới thời điểm hiện
nay.
1.2 Mục tiêu nghiên cứu và câu hỏi nghiên cứu
Quá trình phát triểnphần mềmchung nhưCapability Maturity ModelIntegrated của
Viện Kĩ nghệphần mềm Mỹ (SEI)vàtiêu chuẩn ISO9000/9001đã đượchình thành
đểchuẩn hóa quy trìnhphát triển phần mềm, cũng như họ đã tiêu chuẩn hóa sản xuất
các sản phẩm truyền thống. Các nguyên tắc và tính chuyên nghiệp đã được mô tả
như là viên đạn bạc.Thật không may,sự tiếp tục của cuộc khủng hoảng phần mềm
Trang 10


GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
vào năm 1980 cho thấy việc tìm kiếm phương pháp phát triển phần mềm hoàn hảo
vẫn chưa kết thúc (Brooks 1986).
Phương pháp tiếp theo cho thấy triển vọng là các nguyên tắc của Nhật Bản về chất
lượng.Với việc bổ sung các nguyên tắc Lean, mô hình sản xuất truyền thống của
phát triển đã được hoàn thiện hơn (Mah 2008).Tuy nhiên, khi áp dụng Lean vào
thực tế đã chứng minh khác nhau, cải tiến trong việc phát triển phần mềm nhưng
các dự án hiện nay vẫn còn tồn đọng những vấn đề nghiêm trọng như trong những
năm 80 như giao hàng trễ hạn và yêu cầu khách hàng chưa được thực hiện (Mah.M,
2008). Hầu hết các nhà nghiên cứu đều cho rằng không có phương pháp duy nhất có
thể giải quyết tất cả sự phức tạp trong phát triển phần mềm (Brooks 1995). Điều đó
dẫn tới một câu hỏi là vậy phương pháp sản xuất nào đem lại hiệu quả tốt nhất?
Câu hỏi nghiên cứu
Mục đích của nghiên cứu này nhằm trả lời các câu hỏi nghiên cứu sau:
1. Sự khác biệt giữa các nguyên tắc và kỹ thuật, công cụ của mô hình sản xuất phần
mềm truyền thống và sản xuất phần mềm linh hoạt là gì?
2. Các nguyên tắc và thực hành (kỹ thuật, công cụ)Leantrong sản xuất phần mềm là
gì?
3. Làm thế nào để triển khai các nguyên tắc và thực hành Lean cho các công ty sản
xuất phần mềm tại thành phố Hồ Chí Minh?
Mục tiêu cụ thể
- Sự khác biệt giữa hai phương pháp sản xuất phần mềm: truyền thống và linh
hoạt.
- Đưa ra các gợi ý về nguyên tắc và thực hành Lean trong SXPM
- Đưa ra được mô hình chuyển đổi Lean và các khó khăn có thể gặp phải cho
một công ty SXPM tại thành phố Hồ Chí Minh sau khi lấy ý kiến một số
chuyên gia
Dựa trên các kết quả nghiên cứu của nhiều tác giả trên thế giới và đóng góp của
những cá nhân tham gia nghiên cứu chúng tôi sẽ đưa ra những nguyên tắc và mô
hình để giúp các nhà quản lý dự án có sự lựa chọn đúng đắn hơn

Commented [U1]: Nên viết cụ thể (theo kiểu mỗi mục tiêu là
một gạch đầu dòng)
Trang 11

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
1.3 Phạm vi, giới hạn đề tài
Bài nghiên cứu này sẽ tập trung vào tìm hiểu các phương thức sản xuất phần mềm
theo phương pháp truyền thống và phương pháp Lean, các nguyên tắc, thực hành và
công cụ triển khai Leanvà các nguyên tắc cũng như là các công cụ và kỹ thuật phù
hợp khi áp dụng Lean cho các công ty sản xuất phần mềm ở khu vực thành phố Hồ
Chí Minh.
Phân tíchtập trung vào quá trình chuyển đổi của một công ty SXPM từ phương pháp
sản xuất truyền thống sang sản xuất phần mềm tinh gọn (Lean software
development). Quá trình bàn giao vàduy trìsau khi triển khai sẽ không được phân
tích trong bài, đồng thời bài nghiên cứu cũng tập trung vào các nhóm phát triển
phần mềm chứ không phải làcách thiết kế phần mềm và kiến trúc hệ thống. Nghiên
cứu này cũng không phân loại các dạng dự án như phát triển hay duy trì mà chỉ tập
trung vào quá trình chuyển đổi sang phương pháp Lean của một công ty SXPM bất
kì tại thành phố HCM
1.4 Phương pháp nghiên cứu
Mục đíchcủa nghiên cứu này là cung cấp một điểm khởi đầu, một đánh giá định tính
các lý thuyết và mô hình nghiên cứu đi trước nhằm so sánh sự khác biệt và đưa ra
một mô hình tổng quát cho các công ty muốn triển khai áp dụng Lean để giảm thiểu
lãng phí,nâng cao năng suất và chất lượng theo thời gian.
Với thời gian cho phép, phương pháp thu thập dữ liệu cho bài nghiên cứu này là thu
thập các dữ liệu thứ cấp, các lý thuyết có liên quan cũng như các bài nghiên cứu
trước của các tác giả khác nhau để đưa ra mô hình chung nhất cho phương pháp
Lean trong phần mềm
- Đối với phương pháp truyền thống tôi sử dụngcác nguyên tắc của phát triển
phần mềm truyền thống theo tiêu chuẩn ISO và CMMI được Viện kỹ nghệ

phần mềm Mỹ (SEI) xây dựng và phát triển cho tới hiện nay
- Phương pháp Lean là mới trong lĩnh vực phát triển phần mềm và không có
nguyên tắc Lean tinh khiết vì vậy việc chúng tôi sẽ tập hợp các nguyên tắc
Trang 12

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Lean từ các tác giả nổi tiếng khác nhau có liên quan đến phần mềm pháttriển
và hợp nhất chúng lại được sử dụng cho nghiên cứu này.
Sau đó sẽ tiến hành so sánh, phân tích giữa phương pháp truyền thống và phương
pháp Lean có gì khác biệt vàđưa ra mô hình chung cho việc áp dụng phương pháp
sản xuất phần mềm theo Lean và sẽ thu thập dữ liệu sơ cấp bằng cách lấy ý kiến các
chuyên gia trong ngành phần mềm tại thành phố Hồ Chí Minh để xem xét khả năng
triển khai áp dụng Lean cho các công ty phần mềm khu vực này.
Cáctiêu chí lựa chọncác báo cáo, bài nghiên cứunhư sau:
• Các bài nghiên cứu,báo cáo liên quan đến phương pháp sản xuất phần mềm
tinh gọn
• Các bài báo, nghiên cứu về phương pháp sản xuất phần mềm truyền thống
• Các nguồnthông tinuy tín, bài báo cáo nghiên cứu được đăng trên các tạp chí
chuyên ngành
• Tài liệu tham khảotừ các chuyên giatrong lĩnh vực phần mềm
Không có dữ liệu thực nghiệm trong nghiên cứu này, tuy dữ liệu thực nghiệm có thể
làm cho kết quảnghiên cứu mạnh mẽ hơn nhưng đây là một mô hình mới, chưa
được triển khai tại Việt Nam nên phương pháp nghiên cứu định tính này sẽ làm nền
tảng cho các nghiên cứu sau trong lĩnh vực phần mềm tại Việt Nam.
1.5 Ý nghĩa của nghiên cứu
Nguyên tắc Lean cho các dự án phát triển phần mềm đã được các công ty trên thế
giới áp dụng từ hơn mười năm trước khi nghiên cứu đầu tiên của Alhastrom và cộng
sự năm 1996, 1998 và năm 2003 Mary và Tom Poppendiek cũng đã đưa ra những
khái niệm của mình về Lean trong SXPM. Và sau đó, nhiều tác giả đã thực hiện
nghiên cứu và triển khai áp dụng Lean trong phần mềm như Middleton và cộng

sự(2005), Poppendieck& Poppendieck (2006), Kenji Hiranabe (2008), Naftanalla
Ionel (2009), Er.Kirtesh Jailia và cộng sự (2011), Joey Cho (2010), Mohammad
Shahidul Islam (2013). Hiện nay, Việt Nam cũng có một số các diễn dàn (Forum)
của các chuyên gia trong lĩnh vực phần mềm đã bàn bạc, thảo luận về các nguyên
Trang 13

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
tắc Lean như Hà Nội Scrum, Leansixsigma. Tuy nhiên về lĩnh vực nghiên cứu Lean
cho phần mềm tại Việt Nam theo tìm hiểu của chúng tôi thì vẫn chưa có. Vì vậy:
Về mặt lý thuyết, nghiên cứu này sẽ đóng góp thêm vào nền tảng kiến thức các
phương pháp phát triển phần mềm một phương pháp phát triển phần mềm mới đó là
sản xuất phần mềm tinh gọn (Lean software development), đồng thời đưa ra được
các nguyên tắc, công cụ và thực hành Lean một cách tổng quát.
Về thực tiễn, nghiên cứu này sẽ là một nền tảng để các công ty tại thành phố Hồ Chí
Minh có thể lựa chọn một mô hình triển khai bao gồm những nguyên tắc, thực hành
và công cụ phù hợp nhất của Lean trong ngành SXPM để tạo ra sản phẩm phần
mềm có chất lượng tốt hơn với chi phí, thời gian là thấp nhất.
1.6 Bố cục luận văn
Bài nghiên cứu này sẽ bao gồm 6phần
- Chương 1: Giới thiệu.
Phần này sẽ giới thiệu toàn cảnh ngành công nghiệp phần mềm Việt Nam
nhấn mạnh lí do tại sao có nghiên cứu này cũng như là mục tiêu nghiên cứu,
ý nghĩa nghiên cứu, đối tượng nghiên cứu, giới hạn, phạm vi đề tài
- Chương 2: Lý thuyết
Giới thiệu các khái niệm liên quan tới mô hình phát triển phần mềm.Các lý
thuyết về sản xuất tinh gọn (Lean manufacturing), các lý thuyết liên quan tới
phát triển phần mềm. Các nguyên tắc và thực hành phát triển phần mềm linh
hoạt (Lean) của các tác giả khác nhau trên thế giới và tổng hợp, đưa ra các
nguyên tắc và thực hành Lean chung nhất áp dụng cho sản xuất phần mềm
sau khi xem xét các nghiên cứu trước

Đưa ra và lựa chọn mô hình triển khai Lean cho công ty sản xuất PM
- Chương 3: Phương pháp nghiên cứu
Đưa ra mô hình nghiên cứu, cách thức thu thập, xử lí dữ liệu nghiên cứu
- Chương 4:Phân tích các nguyên tắc và mô hình triển khai Lean
Trang 14

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Đưa ra sự khác biệt giữa các nguyên tắc và thực hành sản xuất phần mềm
truyền thống và sản xuất phần mềm theo Lean
Phân tích và so sánh giữa kết quả phỏng vấn các chuyên gia trong lĩnh vực
phần mềm với kết quả của mô hình đưa ra từ nghiên cứu lý thuyết
- Chương: Kết luận
Đưa ra kết luận chung và hạn chế của nghiên cứu, đề xuất hướng nghiên cứu
tiếp theo, những thuận lợi và khó khăn khi triển khai Lean cho các công ty
SXPM tại thành phố Hồ Chí Minh
- Những phụ lục đính kèm
Trang 15

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
2.1 Phần mềm và các khái niệm liên quan
2.1.1 Phần mềm
Định nghĩa
Phần mềm là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được viết bằng
một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài
liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải
quyết một vấn đề cụ thể nào đó (Pressman, 1997, trích luận văn Mai Nguyen, 2006)
Đặc tính chungcủa phần mềm
 Là hàng hóa vô hình không nhìn thấy được
 Chất lượng phần mềm không mòn đi mà có xu hướng tốt lên sau mỗi lần có

lỗi được phát hiện và sửa lỗi
 Phần mềm vốn chứa lỗi tiềm tàng theo quy mô càng lớn thì khả năng chứa
lỗi càng cao
 Lỗi phần mềm dễ được phát hiện bởi người dùng
2.1.2 Quy trình phát triển phần mềm
Vòng đời phần mềm
Là thời kì tính từ khi phần mềm được tạo ra cho đến khi chết đi (từ lúc hình thành
đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không dùng nữa)
Quy trình phát triển phần mềm
Qui trình phát triển phần mềm (Software Development/Engineering Process - SEP)
là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm.
Quy trình phần mềm (vòng đời phần mềm) được chia thành các giai đoạn chính:
- Xác định yêu cầu
- Phân tích và thiết kế
- Phát triển
- Kiểm thử
- Bảo trì
Trang 16

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
SEP có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và
năng suất cao, có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần
mềm.
Do tính chất của phần mềm là một sản phẩm vô hình, phức tạp và rất khó để quản
lý, do đó việc nghiên cứu quy trình phát triển phần mềm là một trong những lĩnh
vực nghiên cứu quan trọng trong lĩnh vực này.Một quá trìnhphần mềm có thểđược
coi làmột bộ công cụ, phương pháp và thực hành được sử dụngđể sản xuất một sản
phẩm phần mềm (Humphrey, 2006). Theo thời gian, nhu cầu của khách hàng về
chức năng và chất lượng liên tục phát triển dẫn đến nhu cầu biến động cao đòi hỏi
các công ty phần mềm để có tính linh hoạt cao. Vì vậy, ngày càng nhiều công ty

phần mềm bắt đầu áp dụng phương pháp gia tăng và linh hoạt như Scrum, Lean
software development, Kanban, XP, Theo kết quả khảo sát của Forrester tháng 11
năm 2011, các phương pháp sản xuất được sử dụng rộng rãi nhất được thể hiện
trong hình sau:

Hình 2-1 Các mô hình sản xuất phần mềm được sử dụng rộng rãi
Forrester đã công bố kết quả nghiên cứu sau cuộc khảo sát mang tên “Làm thế nào
để thực hiện phát triển linh hoạt trong tổ chức của bạn?” Nghiên cứu này được thực
hiện thông qua khảo sát trực tuyến 205 công ty phần mềm đã và đang thực hiện
Trang 17

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
phần mềm linh hoạt trên thế giới, chấp nhận các câu trả lời có nhiều hơn một lựa
chọn. Cuộc khảo sát này đem lại một sự hiểu biết tốt về cách thức các công ty thực
hiện phát triển phần mềm linh hoạt trên thế giới chứ không chỉ là sự tiếp nhận mô
hình phát triển linh hoạt. Kết quả khảo sát đưa ra những con số khá thú vị, tỷ lệ các
dự án theo mô hình linh hoạt (224%) cao gấp đôi so với mô hình truyền thống
(102.9%), điều này chứng tỏ xu hướng phát triển của mô hình linh hoạt (Scrum,
TDD, Kanban, XP, LSD) đang dần chiếm ưu thế so với mô hình truyển thống
(Waterfall và lặp)
Định nghĩa thực hành tốt nhất (Best practice)
Mộtthực hành tốt nhấtcủa Lean Manufacturing/Lean software development được
định nghĩa là kỹ thuật của hệ thống tinh gọn,tức làmột công cụ, một thủ tục hoặc
một tập hợp các hành động nhằm cải thiện năng suất và/hoặc giảm chi phí. Do đó,
số lượng thực hành tốt nhất càng cao thì mức độ trưởng thành hệ thống Lean là
càng cao (Alessandro Incisa & Ruggero Moretto 2013)
2.2 Tổng quan mô hình phát triển truyền thống
SDLC còn được gọi là chu trình hay vòng đời phát triển phần mềm (SDLC –
Software Development Life Cycle). SDLC là tập hợp các công việc và quan hệ giữa
chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình

SDLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới như
bên dưới
2.2.1 Mô hình thác nước (Waterfall)
Là một mô hình của quy trình phát triển phần mềm cổ điển nhất, Royce (1970) đã
định nghĩa quá trình phát triển có cấu trúc và tuần tự trông giống như một dòng
chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui
hay nhảy vượt pha, bao gồm các giai đoạn phân tích yêu cầu, thiết kế, triển khai
thực hiện, kiểm thử, liên kết và bảo trì. Theo Dennis, Wixonm và Tegarden (2005),
giai đoạn lập kế hoạch thường chiếm khoảng 15% của tổng vòng đời phát triển
(SDLC), đây là quá trình cơ bản để xác định phạm vi của hệ thống/sản phẩm, hiểu
Trang 18

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
được lý do tại sao một hệ thống nên được xây dựng và làm thế nào các nhóm dự án
sẽ xây dựng thông qua tính kỹ thuật, kinh tế và tính khả thi.Giai đoạn phân tích
chiếm khoảng 15% của SDLC, phân tích hệ thống hiện tại, những vấn đề của hệ
thống và sau đó xác định cách để thiết kế các hệ thống mới thông qua các yêu cầu
thu thập được từ khách hàng. Giai đoạn thiết kế chiếm 35% của SDLC, quyết định
hệ thống sẽ hoạt động như thế nào về phần cứng, phần mềm và cơ sở hạ tầng mạng.
Giai đoạn thực hiện chiếm khoảng 30% của SDLC và là giai đoạn mã hóa thực tế
xảy ra. Giai đoạn kiểm thử (test) chiếm 15%, giai đoạn bảo trì chiếm 5% còn lại của
SDLC và tập trung vào lắp đặt, kế hoạch hỗ trợ, tài liệu hướng dẫnvà gỡ lỗi. Hình
dưới đây cho thấy một vòng đời thác nước điển hình

Hình 2-2: Mô hình thác nước (Waterfall)
1. Phân tích các yêu cầu:
Phân tích hệ thống dịch vụ, khó khăn và mục tiêu về sản phẩmmà người dùng mong
muốn, được hình thành bởi sự gợi ý về hệ thống của chuyên gia phân tích và hiểu
biết người dùng. Sau đó các yếu tố này được định nghĩa sao cho có thể hiểu được
bởi cả người phát triển và người sử dụng.

2. Thiết kế phần mềm và hệ thống
Trang 19

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Thiết kế hệ thống các quá trình, các bộ phận và các yêu cầu về cả phần mềm lẫn
phần cứng. Hoàn tất hầu như tất cả kiến trúc của các hệ thống này. Thiết kế phần
mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể được
chuyển dạng thành một hay nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm đơn vị:
Trong giai đoạn này, thiết kế phần mềm phải được chứng thực như là một tập hợp
nhiều chương trình hay nhiều đơn vị nhỏ. Thử nghiệm đơn vị bao gồm xác minh
rằng mỗi đơn vị thỏa mãn đặc tả của nó.
4. Tổng hợp và thử nghiệm toàn bộ:
Các đơn vị chương trình riêng lẻ hay các chương trình được tích hợp lại và thử
nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu của phần mềm
được thỏa mãn. Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng.
5. Cài đặt và bảo trì:
Thông thường (nhưng không bắt buộc) đây là giai đoạn lâu nhất của chu kỳ sống
(của sản phẩm). Phần mềm được cài đặt và được dùng trong thực tế. Bảo trì bao
gồm điều chỉnh các lỗi mà chưa được phát hiện trong các giai đọan trước của chu kì
sống; nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ
cho là các phát hiện vê yêu cầu mới.
Mô hình thác nước tinh khiết thực hiện tốt cho các sản phẩm với các yêu cầu
được hiểu rõ ràng ngay từ đầu dự án và các công cụ kỹ thuật, kiến trúc và cơ sở hạ
tầng. Điểm yếu của nó là không giao tiếp thường xuyên với khách hàng cũng như ít
giao tiếp trong đội dự án làm cho nó không linh hoạt khicần có thay đổi hoặc sản
phẩm cần sự phát triển một cách nhanh chóng khi yêu cầu chưa rõ ràng ngay từ đầu.
Nhận thấy những điểm yếu đó, năm 1981, Boehm có mở rộng và sửa đổi mô hình
thác nước tinh khiết thành mô hình thác nước sửa đổi sử dụng các giai đoạn tương
tự như cácthác nước tinh khiết nhưng cho phép các giai đoạn chồng lên nhau khi

cần thiết. Thác nước tinh khiết khi đó có thể chia thành các tiểu dự án ở giai đoạn
thích hợp.
Trang 20

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Điểm yếu của mô hình này là nó không linh hoạt, rất nhiều các tài liệu phải tạo ra
trong suốt quá trình phát triền của dự án như tài liệu đặc tả, tài liệu thiết kế kiến
trúc, tài liệu thiết kế chi tiết, các báo cáo kiểm tra chất lượng, các báo cáo của
trưởng dự án, nhân viên kiểm tra chất lượng, Các bộ phận của dự án chia ra thành
những bộ phận riêng theo giai đoạn. Hệ thống khi cài đặt đôi khi không dùng được
vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô hình này phản
ảnh thực tế công nghệ, đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển
phần mềm.
2.2.2 Những thất bại của mô hình truyền thống
Một nghiên cứu thú vị được thực hiện bởi Standish Group trong 8,380 dự án từ năm
2002 đến năm 2010 cho 2 phương pháp truyền thống và linh hoạt. Người trả lời đại
diện cho các công ty phần mềm lớn cho thấy chỉ có một tỷ lệ nhỏ các dự án (14%)
với các phương pháp truyền thống đã được hoàn thành đúng thời gian và kinh phí
với tất cả các tính năng và chức năng yêu cầu. 29% số dự án đã được hoàn thành
vượt ngân sách, vượt quá thời gian cho phép và cung cấp ít tính năng hơn,57% số
dự án đã bị hủy bỏ tại một số điểm trong chu kỳ phát triển hoặc thử thách (Standish
Group, 2010). Hình bên dưới hiển thị kết quả của nghiên cứu. Nghiên cứu này cũng
cho thấy một tỷ lệ khả quan hơn thuộc về các dự án linh hoạt, có 42% các dự án
công đã được hoàn thành đúng thời gian, về ngân sách và với tất cả các tính năng và
chức năng ban đầu được xác định. Hơn nữa, nghiên cứu cho thấy tỷ lệ thất bại là
9% thấp hơn 3 lần so với mô hình truyền thống là 29%.

Hình 2-3: Độ phân tán của dự án
Trang 21


GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Một số điểm mạnh của mô hình truyền thống
- Tạo ra một hình ảnh chung về hệ thống trước khi phát triển
- Dễ dàng cho các nhà phát triển hiểu hệ thống và làm theo
Một số vấn đề chính (điểm yếu) của mô hình truyền thống
- Thay đổi yêu cầu thì không được chào đón, việc thay đổi yêu cầu chỉ được
phép trong quá trình thu thập và phân tích yêu cầu
- Việc xác nhận thì không được thực hiện đầy đủ, lỗi của giai đoạn trước có
thể bị ẩn giấu và gia tăng trong các giai đoạn tiếp theo. Trong hấu hết các
trường hợp thì lỗi được phát hiện trễ trong giai đoạn kiểm nghiệm nên chi
phí sửa lỗi và làm lại là rất cao
- Nhận phản hồi của khách hàng chậm trễ dẫn đến làm không đúng yêu cầu,
không thỏa mãn được những thay đổi khách hàng.
Để giải quyết một số những sai phạm của các phương pháp truyền thống , phương
pháp linh hoạt đã được đề xuất (Beck và cộng sự 2001).
2.3 Các mô hình phát triển phần mềm linh hoạt
2.3.1 Tổng quan về phát triển phần mềm linh hoạt
Các mô hình phát triển linh hoạt được một nhóm các kỹ sư phần mềm đưa ra nhằm
khắc phục những hạn chế của mô hình SX truyền thống. SXPM linh hoạt là quy
trình mà trong đó cấu trúc khởi động ban đầu sẽ nhỏ nhưng linh động và lớn dần
của các đề án phần mềm nhằm tìm ra các khó khăn trước khi nó trở thành vấn đề có
thể dẫn tới những hủy hoại. Quy trình này nhấn mạnh sự gọn nhẹ và tập trung hơn
là các phương pháp truyền thống. Các quy trình linh hoạt dùng các thông tin phản
hồi thay vì dùng các kế hoạch như là một cơ chế điều khiển chính. William và
Cockburn (2003) đề cập đến việc lập trình eXtreme (XP), Scrum, Crystal và phát
triển phần mềm thích ứng (ASD) đã được phát triển ở Mỹ bởi Ken Beck và Eric
Gamma, Ken Schwaber và Jeff Sutherland, Alistair Cockburn và Jim
Highsmith Bảng dưới cho thấy tên các quốc gia và người sáng lập kết hợp với các
phương pháp sản xuất phần mềm linh hoạt khác nhau.
Trang 22


GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Bảng 2-1: Lịch sử phát triển của phương pháp linh hoạt và các tác giả nổi tiếng
Khu vực
Phương pháp linh hoạt
Tác giả (năm)
Châu Mỹ
Lập trình cực hạn
Extreme Programming (XP)
Kent Beck, Eric Gamma
(2001)

Scrum
Ken Schwaber, Jeff
Sutherland (2002)

Crystal Methods
Alistair Cockburn (2004)

Adaptive Software Development
(ASD)
Jim Highsmith (2004)

Lean Software Development
Tom and Mary Poppendieck
(2003)
Châu Âu
Dynamic Systems
Development Method (DSDM)
Dane Faulkner (1994)

Châu Úc
Feature Driven Development (FDD)
Peter Code, Jeff DeLuca
(1999)

Tuyên ngôn và nguyên tắc của lập trình linh hoạt(Beck và cộng sự, 2001)
Liên minh linh hoạt tin rằng cách tốt nhất để sản xuất ra sản phẩm phần mềm tốt là
đề cao các giá trị bên trái hơn so với các giá trị truyền thống bên phải
Bảng 2-2: Tuyên ngôn của phương pháp lập trình linh hoạt
Phương pháp linh hoạt
Phương pháp truyền thống
Cá nhân và tương tác
Quy trình và công cụ
Phần mềm làm việc được
Tài liệu hoàn chỉnh
Hợp tác với khách hàng
Hợp đồng
Đáp ứng với thay đổi
Một kế hoạch

Trang 23

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
Như thể hiện trong bảng trên, phương pháp linh hoạt tập trung(1) vào các cá nhân
và tương tác hơn là các quy trình và công cụ, (2) phần mềm làm việc hơn là tài liệu
hoàn chỉnh, (3) sự hợp tác của khách hàng nhiều giá trị hơn so với đàm phán hợp
đồng và (4) ập trung vào ứng phó với thay đổi hơn là lên một kế hoạch hoàn chỉnh.
Đó là bản tuyên ngôn của phương pháp sản xuất linh hoạt (Beck và cộng sự 2001)
Các đội dự án tập trung vàophát triểnlặp và tăng dần giá trị, những gì được chia sẻ
giữacác phương pháp là nơi mà yêu cầu và các giải pháp phát triển thông qua sự

hợp tác giữa việc tự tổ chức, các đội liên chức năng (Bjornvig và cộng sự 2010).
Một trong những nhà phát triển phương pháp linh hoạt, Kent Beck (2001) đã phát
triển tuyên ngôn linh hoạt thành mười hai nguyên tắc linh hoạt. Các nguyên tắc này
xác định các ý nghĩa cụ thể đằng sau bản tuyên ngôn. Các nguyên tắc cụ thể được
trình bày trong bảng sau:
Bảng 2-3: 12 nguyên tắc sau bản tuyên ngôn lập trình linh hoạt
(Beck và cộng sự 2001)
STT
Nội dung nguyên tắc
01
Ưu tiên cao nhất của chúng tôi là đáp ứng khách hàng thông qua giao các
phần mềm có giá trị sớm và liên tục
02
Hoan nghênh yêu cầu thay đổi, thậm chí trong giai đoạn cuối của sự phát
triển. Quá trình linh hoạt khai thác thay đổi cholợi thế cạnh tranh của khách
hàng.
03
Cung cấp phần mềm làm việc một cách thường xuyên, từ một vài tuần đến
vài tháng, với ưu tiên cho các quãng thời gian ngắn
04
Khách hàng và nhóm phát triển phải làm việc cùng nhau hàng ngày trong dự
án
05
Xây dựng các dự án dựa trên tôn trọng cá nhân. Cung cấp cho họ môi trường
và hỗ trợ mà họ cần và tin tưởng họ để có được công việc làm.
06
Phương pháp hiệu quả nhất trong việc truyền đạt thông tin trong một nhóm là
cuộc trò chuyện face to face (gặp mặt trực tiếp)
07
Phần mềm làm việc là thước đo chính của tiến độ dự án

Trang 24

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm
08
Quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà đầu tư, nhà phát
triển và người dùng sẽ có thể duy trì một tốc độ ổn định vô thời hạn.
09
Kỹ thuật tốt và thiết kế tốt giúp tăng cường sự nhanh nhẹn
10
Đơn giản là nghệ thuật để tối đa hóa số lượng công việc không thực hiện là
điều cần thiết.
11
Kiến trúc tốt nhất, yêu cầu và thiết kế tốt xuất phát từ tự tổ chức của nhóm
phát triển
12
Định kỳ, nhóm phát triển phản ánh về cách làm việc để trở nên hiệu quả hơn,
sau đó điều chỉnh hành vi của mình cho phù hợp

2.3.2 Lập trình Scrum
Scrum là một trong 2 phương pháp linh hoạt được biết đến nhiều nhất. Trong phát
triển phần mềm theo Scrum, các giai đoạn được xúc tiến trong các bước cực nhỏ và
liên tục so với các quy trình kiểu cũ. Bước đầu tiên (với chủ định là không hoàn tất)
cho đến các bước có thể chỉ tốn một ngày hay một tuần, thay vì phải tốn nhiều
tháng như trong phương pháp thác nước. Giai đoạn đầu người ta thực hiện việc thu
thập các yêu cầu và chia nhỏ ra thành cách tính năng, sắp xếp độ ưu tiên cho các
tính năng này. Kế đến là giai đoạn thực hiện những vòng lặp nhỏ (Sprint), mỗi vòng
lặp bao gồm các bước như chia nhỏ yêu cầu thành các công việc, thiết kế cấu trúc,
thực thi, kiểm tra và bàn giao tính năng theo độ ưu tiên lúc đầu. Thiết kế và kiến
trúc được điều chỉnh và nâng cao sau mỗi vòng lặp, một vòng lặp thông thường kéo
dài từ một đến bốn tuần. Hình bên dưới thể hiện một vòng đời phát triển theo

phương pháp Scrum.
Trang 25

GVHD: PGS.TS. Bùi Nguyên Hùng HV: Lê Thị Thanh Trâm

Hình 2-4: Phương pháp phát triểnlinh hoạt (SCRUM)
2.3.3 Sự khác nhau giữa mô hình truyền thống và mô hình linh hoạt
Có rất nhiều đặc điểm khác nhau giữa linh hoạt và truyền thống. Theo nghiên cứu
của Boehm (2002) có 9 sự khác biệt chính giữaphương pháp linh hoạt và truyền
thống thể hiện trong bảng bên dưới. Boehm cho rằng mục tiêu chính của việc sử
dụng mô hình linh hoạt là cung cấp giá trị nhanh chóng, trong khi mục tiêu chính
của mô hình truyền thống là về tính bảo đảm cao (thông qua hợp đồng, báo cáo, đặc
tả, cam kết, ). Theo ông mô hình linh hoạt là một lựa chọn tốt hơn khi yêu cầu chưa
biết đến lúc bắt đầu của dự án, hoặc thay đổi nhanh chóng, trong khi mô hình truyền
thống là tốt hơn khi yêu cầu được biết đến ở giai đoạn đầu của dự án và phần lớn ổn
định trong suốt thời gian của dự án. Liên quan đến sự tham gia của khách hàng,
Boehm cho rằng mô hình linh hoạt cần sự hiểu biết và hợp tác của khách hàng trong
khi mô hình truyền thống cần khách hàng tập trung hơn vào điều khoản hợp đồng.
Trong mô hình linh hoạt các nhà phát triển phải nhanh nhẹn, hiểu biết, đồng vị và
hợp tác. Trong mô hình truyền thống các nhà phát triển cần có kế hoạch định hướng
và có kỹ năng thích hợp để truy cập kiến thức bên ngoài. Hơn một sự khác biệt rất

×