Bài giảng kỉ nghệ phần mềm

Khía cạnh công nghệ thường là cách thức kĩ thuật để tạo ra những sản phẩm cụ thể đã và đang được dạy tại các đại học, còn các khía cạnh khác của kĩ nghệ phần mềm, cho đến bây giờ vẫn là

Nhập môn

Kĩ nghệ phần mềm

Biên soạn Ngô Trung Việt Nguyễn Kim Ánh

Hà Nội 8/2002

499 500

Mục lục

Giới thiệu 9

Phần 1 Tổng quan về kĩ nghệ phần mềm . 11

1.1 Khoa học, kĩ nghệ và Thủ công 11

1.2 Kĩ nghệ phần mềm 16

1.3 Tiến hoá phần mềm 20

1.4 Qui trình phần mềm 23

1.5 Về cách giải quyết vấn đề 24

1.5.1 Từ lập trình đi lên… 24

1.5.2 Vấn đề, giải pháp và giải quyết vấn đề 29

1.5.3 Vòng đời 36

1.5.4 Chu kì và pha phát triển 41

1.5.5 Chu kì và pha lặp 43

Phần 2 Các mô hình phát triển phần mềm 46

2.1 Mô hình tiến trình phần mềm 46

2.1.1 Mô hình tuần tự tuyến tính 48

2.1.2 Mô hình làm bản mẫu 52

2.1.3 Mô hình RAD 54

2.1.4 Mô hình tiến trình phần mềm tiến hoá 57

2.1.5 Mô hình tăng dần 58

2.1.6 Mô hình xoáy ốc 60

2.1.7 Mô hình phát triển tương tranh 63

2.2 Phát triển dựa theo cấu phần 66

2.3 Kĩ thuật thế hệ thứ tư 68

Phần 3 Các khái niệm về quản lí dự án 74

3.1 Phổ quản lí 75

3.1.1 Con người 75

3.1.2 Sản phẩm 76

3.1.3 Tiến trình 77

3.1.4 Dự án 77

3.2 Con người 78

3.2.1 Người tham dự 81

3.2.2 Người lãnh đạo tổ 82

3.2.3 Tổ phần mềm 83

3.2.4 Vấn đề phối hợp và trao đổi 91

3.3 Sản phẩm 92

3.3.1 Phạm vi phần mềm 92

3.3.2 Phân tách vấn đề 93

3.4 Tiến trình 94

3.4.1 Trộn lẫn sản phẩm và tiến trình 94

3.4.2 Phân tách tiến trình 95

3.5 Dự án 96

Phần 4 Kĩ nghệ phần mềm truyền thống 98

4.1 Kĩ nghệ hệ thống 98

4.1.1 Hệ thống dựa trên máy tính 99

4.1.2 Hệ thống cấp bậc kĩ nghệ hệ thống 102

4.1.3 Kĩ nghệ tiến trình nghiệp vụ: Tổng quan 107

4.1.4 Kĩ nghệ sản phẩm: tổng quan 112

4.1.5 Kĩ nghệ yêu cầu 114

4.1.6 Mô hình hoá hệ thống 123

4.1.7 Tóm tắt 124

4.2 Nền tảng của phân tích yêu cầu 126

4.2.1 Phân tích yêu cầu 127

4.2.2 Lĩnh vực vấn đề 132

4.2.3 Kĩ thuật trao đổi 134

4.2.4 Nguyên lí phân tích 136

4.2.5 Làm bản mẫu phần mềm 140

4.2.6 Đặc tả 146

4.2.7 Kiểm điểm đặc tả 155

4.2.8 Tóm tắt 158

4.3 Phương pháp luận phát triển truyền thống 159

4.3.1 Vai trò của tổ chức phát triển hệ thống 159

4.3.2 Mô hình phát triển hệ thống 162

4.3.3 Vòng đời phần mềm 169

4.4 Phân tích yêu cầu và phương pháp thiết kế 184

4.4.1 Phương pháp lập biểu đồ 184

4.4.2 Lập biểu đồ phân tích/thiết kế 188

4.4.3 Phương pháp thiết kế

195 4.5 Ngôn ngữ lập trình 212

4.5.1 Thuộc tính chương trình 212

4.5.2 Kiểu dữ liệu 214

4.5.3 Cấu trúc điều khiển 215

4.5.4 Phân tích cú pháp 219

4.5.5 Phân loại về ngôn ngữ lập trình 226

4.5.6 Kiểu và đặc trưng của ngôn ngữ lập trình 233

4.6 Kĩ thuật lập trình 244

4.6.1 Mô thức lập trình 244

4.6.2 Phong cách lập trình 249

4.6.3 Dùng bộ xử lí ngôn ngữ 251

4.6.4 Môi trường lập trình 253

4.7 Kiểm thử 255

4.7.1 Tổng quan về kiểm thử 255

4.7.2 Kiểm thử đơn vị 256

4.7.3 Kiểm thử tích hợp 257

4.7.4 Kiểm thử hệ thống 266

4.7.5 Các kiểm thử khác 268

4.7.6 Kế hoạch và nhiệm vụ kiểm thử

269 4.7.7 Phương pháp kiểm điểm

276 4.7.8 Thiết kế kiểm thử và phương pháp quản lí 278

Phần 5 Kĩ nghệ phần mềm hướng sự vật 282

5.1 Giới thiệu về cách tiếp cận hướng sự vật 282

5.1.1 Khủng hoảng phần mềm 282

5.1.2 Cách tiếp cận hướng sự vật 291

5.1.3 Làm tài liệu về các lớp 306

5.1.4 Các hoạt động phân tích và thiết kế 307

5.1.5 Thiết kế cơ sở dữ liệu 312

5.1.6 Thiết kế giao diện con người 314

5.1.7 Tóm tắt 318

5.2 Tổng quan về UML 322

5.2.1 Kiến trúc 322

5.2.2 Siêu mô hình 328

5.2.3 Góc nhìn kiến trúc và biểu đồ 331

5.2.4 Cơ chế 333

5.2.5 Vấn đề, giải pháp và giải quyết vấn đề 338

5.2.6 Vấn đề và giải pháp 340

5.2.7 Giải quyết vấn đề 344

5.2.8 Chu kì lặp và pha 346

5.2.9 Chi tiết hơn về UML 348

5.2.10 Tiến trình sử dụng UML 374

Phần 6 Các chủ đề nâng cao trong Kĩ nghệ phần mềm 402 6 1 Phương pháp hình thức 402

Kĩ thuật đặc tả hình thức 403

6.2 Kĩ nghệ phần mềm phòng sạch 407

6.2.1 Cách tiếp cận phòng sạch 408

6.2.2 Đặc tả chức năng 410

6.2.3 Thiết kế phòng sạch 414

6.2.4 Kiểm thử phòng sạch 414

6.2.5 Tóm tắt 416

6.3 Kĩ nghệ phần mềm dựa trên cấu phần 418

6.3.1 Kĩ nghệ hệ thống dựa trên cấu phần 418

6.3.2 Tiến trình CBSE 419

6.3.3 Kĩ nghệ miền 421

6.3.4 Phát triển dựa trên cấu phần 422

6.3.5 Phân loại và tìm kiếm cấu phần 430

6.3.6 Tóm tắt 434

6.4 Kĩ nghệ phần mềm khách/ nguồnphục vụ 435

6.4.1 Cấu trúc của hệ thống khách/phục vụ 435

6.4.2 Kĩ nghệ phần mềm cho hệ thống khách /nguồn phục vụ 443

6.4.3 Thiết kế cho hệ thống khách/nguồn phục vụ 445 6.5 Kĩ nghệ Web 453

6.5.1 Các thuộc tính của ứng dụng dựa trên Web 453

6.5.2 Một khuôn khổ cho kĩ nghệ Web 455

6.5.3 Phát biểu/phân tích hệ thống dựa trên Web 456

6.5.4 Thiết kế ứng dụng dựa trên Web 459

6.5.5 Kiểm thử ứng dụng dựa trên Web 469

6.5.6 Vấn đề quản lí 472

Giới thiệu

Kĩ nghệ phần mềm là vấn đề thời sự và hiện đại cho những

người quản lí và hành nghề CNTT cần hiểu và áp dụng vào trong

thực tế phát triển các sản phẩm CNTT Kĩ nghệ phần mềm có thể

giúp cho con người có nhiều hiểu biết hơn, cung cấp những nền

tảng cần để xây dựng những sản phẩm và hệ thống chất lượng cao

trong thế kỉ thứ hai mươi mốt Có thể nói kĩ nghệ phần mềm là lĩnh

vực tri thức và kinh nghiệm được hệ thống hoá để giúp cho mọi

người có thể làm việc theo cách có phối hợp, có bài bản, có kỉ luật

trong các hoạt động sáng tạo ra sản phẩm mang tính kĩ nghệ, công

nghiệp

Sự phát triển của xã hội loài người đã đi từ nền sản xuất nông

nghiệp và tiểu thủ công qua sản xuất công nghiệp Đặc trưng chính

của bước phát triển này là việc đưa vào cách làm việc công nghiệp,

tạo ra các dây chuyền sản xuất trong đó máy móc đóng vai trò

chính làm ra sản phẩm hàng loạt và đều nhau, cung cấp sản phẩm

theo qui mô lớn cho xã hội Con người bị gắn vào các qui trình

công nghiệp và trở thành một bộ phận của nó

Ngày nay chúng ta lại đang chứng kiến việc chuyển biến trong

nền kinh tế chuyển từ nền sản xuất công nghiệp sang nền sản xuất

thông tin và tri thức Đặc trưng chính của bước phát triển mới này

là việc khôi phục trở lại vai trò sáng tạo trung tâm của con người

trong mọi hoạt động kinh tế và sản xuất Khác với nền sản xuất

công nghiệp lấy máy móc làm động lực chính cho sản xuất, nền

sản xuất thông tin và tri thức lấy con người sáng tạo làm động lực

chính cho việc thay đổi kết cấu của các tiến trình sản xuất máy

móc, để từ đó tạo ra sức sản xuất với qui mô toàn cầu và một trình

có một con mắt tổng quan khi tiếp cận tới vấn đề này Những vấn

đề có tính lí thuyết đã không được đề cập tới nhiều Tuy nhiên mộttài liệu tóm lược toàn diện các vấn đề của kĩ nghệ phần mềm là cầnthiết cho những người mới làm quen với lĩnh vực này

Tài liệu chính sử dụng để biên soạn cuốn sách này được rút ra

từ bài giảng trong khoá học Khởi động về kĩ nghệ phần mềm tiếnhành tại Khu công nghệ cao Hoà Lạc tháng 11/2001, một số tư liệutrong tài liệu đào tạo về kĩ sư CNTT cơ bản của Nhật và cuốn sách

“Kĩ nghệ phần mềm: cách tiếp cận của người thực hành” củaRoger Pressman

Chúng tôi hi vọng tài liệu này có thể cung cấp cho bạn đọc gócnhìn bao quát về một lĩnh vực quan trọng đang cần được triển khairộng rãi Việc biên soạn những vấn đề mới này không tránh khỏi cónhiều thiếu sót và hạn chế, mong được các độc giả và đồng nghiệp

bổ sung đóng góp thêm

Hà Nội tháng 8/2002

Khoa học (science) là hệ thống các tri thức được con người

khám phá ra từ các tiến trình tự nhiên hay chính các hoạt động của

mình Khoa học tập trung vào tìm hiểu các qui luật của thực tế,

nghiên cứu những khả năng mô phỏng các qui luật của thực tế để

từ đó nêu ra các nguyên tắc cho con người có thể chế tạo ra các

phương tiện thiết bị mới

Công nghệ (technology) nói tới cách thức, phương pháp nào

đó do con người phát minh ra để làm một việc gì đó, cụ thể hay

trừu tượng Công nghệ sử dụng các thành tựu của khoa học để tác

động vào thế giới vật chất và năng lượng, thông tin

Công nghệ, được hiểu như một tập hợp các kĩ thuật dùng

trong một ngành nào đó, có một cơ sở khoa học thống nhất Công

nghệ phần mềm được hiểu gồm nhiều loại công nghệ tạo ra phầnmềm khác nhau, mỗi công nghệ có thể có nhiều kĩ thuật làm phầnmềm khác nhau Công nghệ thông tin (CNTT) vẫn được hiểu baogồm một số vấn đề của công nghệ điện tử, công nghệ máy tính,công nghệ viễn thông, công nghệ phần mềm, công nghệ quản lí Một đặc điểm nữa của CNTT là việc các công nghệ đều dựa trêncác chuẩn và có những con người am hiểu những công nghệ đó sửdụng

Kĩ nghệ (engineering) nói tới một tập hợp các công nghệ được

bố trí theo một qui trình nhất định, được con người dùng cácphương pháp và thực hiện qua các công cụ để tạo ra những sảnphẩm nhất định

Kĩ nghệ là việc sử dụng phối hợp các công nghệ cần thiết để

sản xuất ra các sản phẩm của một ngành nào đó (nguyên nghĩa từ

kĩ nghệ cơ khí, engine là một cái máy)

Cần phân biệt công nghệ nói đến những kĩ thuật được pháttriển cho một loại vấn đề nào đó, còn kĩ nghệ nói tới các qui trìnhnghiêm ngặt phối hợp các công nghệ, phương pháp và công cụ đểlàm ra sản phẩm có chất lượng Triển khai tiếp một số khái niệmliên quan chúng ta có thể xét thêm: kĩ thuật và công nghiệp

Kĩ thuật (technique) có nghĩa hẹp nhất chỉ ra một cách thức tiến hành một công việc nào đó - kĩ thuật phần mềm bao gồm các

kĩ thuật như kĩ thuật viết hệ điều hành, kĩ thuật làm chương trìnhđiều khiển v.v

Công nghiệp (industry) là chữ bao trùm cả một ngành lớn, trong đó bên cạnh yếu tố kĩ nghệ còn có thêm những khía cạnh kinh tế, tài chính, tổ chức xã hội v.v Chẳng hạn trong công nghiệp

xe hơi, kĩ nghệ (sản xuất) - sản xuất để trong ngoặc vì kĩ nghệ là đã

hàm ý sản xuất rồi - xe hơi sử dụng đến cả các kĩ thuật đúc, hàn

của công nghệ cơ khí đến kĩ thuật làm lốp xe của công nghệ cao

su

Khía cạnh công nghệ thường là cách thức kĩ thuật để tạo ra

những sản phẩm cụ thể đã và đang được dạy tại các đại học, còn

các khía cạnh khác của kĩ nghệ phần mềm, cho đến bây giờ vẫn là

dùng các xemina ngắn ngày để bổ sung và dùng "việc huấn luyện

trong công việc" là chủ yếu, nói tới việc thực hành các tiến trình

sản xuất phần mềm theo qui tắc, kỉ luật và bài bản

Để chế tạo ra sản phẩm thích hợp, cần phải xác định ra các yêu

cầu về sản phẩm đó và từ đó xác định các tiến trình kĩ nghệ chế tạo

tương ứng Tiến trình kĩ nghệ tổ hợp các yếu tố con người và các

công nghệ trong những hoạt động quản lí chung để cuối cùng đưa

tới chế tạo ra sản phẩm đáp ứng đúng yêu cầu ban đầu đặt ra

Nhưng để có được sản phẩm thực tế, chúng ta cần có cách thức tổ

chức phối hợp sự hoạt động của một nhóm người cùng các nguồn

tài nguyên, tài lực, theo các tiến trình kĩ nghệ đó Cho nên điều cần

được đề cập tới khi nói tới kĩ nghệ phần mềm là việc quản lí các dự

án làm ra sản phẩm đó Và để quản lí được, để phối hợp các hoạt

động sáng tạo theo qui trình đã đặt ra, người ta cần có ngôn ngữ

chung mô tả cho mọi hoạt động trong tiến trình dự án này

Trong cuốn sách này chúng ta sẽ tập trung vào một loại sản

phẩm đặc biệt - phần mềm máy tính Từ vấn đề vừa được trình bầy,

rõ ràng để chế tạo ra sản phẩm phần mềm theo qui mô kĩ nghệ thì

những người tham gia vào quá trình này cần có các hiểu biết tối

thiểu về:

- tiến trình làm phần mềm

- cách quản lí tiến trình này

- cách thể hiện và ghi chép lại mọi kết quả phát sinh trong

Kĩ nghệ và thủ công

Đặc điểm chính của sản phẩm thủ công là không phức tạp, vàchất lượng không đều nhau Sản phẩm làm ra có thể rất tốt, chấtlượng rất cao, tuỳ người làm, và cũng có thể trung bình, có thểkém Mặt khác không thể nhiều người làm chung với nhau, hoặcnếu có nhiều người làm chung thì mỗi người đều cùng làm mộtviệc giống nhau, như hàng nghìn người đào đất đắp đê chẳng hạn.Như vậy công việc sản xuất ra sản phẩm thủ công không do nhiềungười làm, làm không nhanh và đầu tư ít

Trái lại, kĩ nghệ luôn luôn nhằm những sản phẩm phức tạp,nhằm tạo ra sản phẩm chất lượng cao nhưng không nhằm chấtlượng rất cao, do những cá nhân trung bình làm ra Kĩ nghệ nhằmđạt mục đích sản xuất nhanh những sản phẩm phức tạp, nhằm sảnxuất tập thể, theo qui trình chặt chẽ Kĩ nghệ sẵn sàng đầu tư caohơn nhiều so với thủ công Và kĩ nghệ có thừa hưởng một giaiđoạn lịch sử lâu đời là thủ công Cái máy dệt hiện đại nhất hiện nayvẫn sử dụng một số nguyên tắc mà người ta đã khám phá ra từ thờithủ công

biết khi nào "làm được" bằng những công nghệ hiện có Bộ môn

thiết kế cầu đã được kiến trúc sư và những kĩ sư cơ khí, các nhà

xây dựng hiểu rõ

Đặc điểm chung của các hoạt động kĩ nghệ là mọi người tham

dự vào một dự án kĩ nghệ đều phải có hiểu biết chung về phần

công việc của mình và mối liên hệ với công việc của toàn thể

nhóm Tất cả đều phải có khả năng đọc các tài liệu kĩ nghệ và quản

lí (bản kế hoạch tổng thể, biểu đồ công việc găng, bảng phân việc,

sơ đồ Gantt) Hoạt động kĩ nghệ đòi hỏi có mục tiêu/cột mốc được

thiết lập rõ ràng để có thể đạt tới được trong hoàn cảnh thông

thường

Mặt khác dự án kĩ nghệ chỉ có thể được thực hiện với một tổ

chức có các nhân viên có kĩ năng Điều này có nghĩa là cần tập

trung những con người có đủ phẩm chất về chuyên môn vào việc

hoàn thành các nhiệm vụ kĩ nghệ Do đó phát sinh nhu cầu phối

hợp hoạt động của nhiều người mang các chức năng và chuyên

môn khác nhau

Thường có hai loại người tham gia vào các dự án kĩ nghệ: kĩ

sư-kiến trúc sư và các nhà chuyên môn Trong các dự án kĩ nghệ

cần có các kiến trúc sư có bằng, được đào tạo bài bản, biết rõ các

nguyên tắc kĩ thuật cũng như qui trình làm việc: kĩ sư cơ khí/kết

cấu, kĩ sư dân dụng, người quản trị dự án v.v Mặt khác các dự án

kĩ thuật cũng cần các chuyên gia có chứng chỉ, nhưng người

chuyên môn trong các hoạt động sản xuất: thợ hàn, thợ bê tông

v.v

1.2 Kĩ nghệ phần mềm

Kĩ nghệ phần mềm là gì? IEEE - hiệp hội những người kĩ sư

điện và điện tử của Mĩ, năm 1990 đề nghị một định nghĩa kĩ nghệ

phần mềm như sau:

Kĩ nghệ phần mềm là sự áp dụng một cách có hệ thống và kỉ luật những phương pháp có thể định lượng được trong các khâu phát triển, vận hành, và bảo trì phần mềm Tức là áp dụng những nguyên tắc của kĩ nghệ vào phần mềm.

Tại sao lại có kĩ nghệ phần mềm? Thứ nhất là phần mềmngày xưa do một số nhỏ người viết, vài người viết trong vòng vàitháng Nhưng đến những hệ phần mềm lớn như hệ DOS của IBMhay hệ mềm dùng cho chương trình không gian của Mĩ, thì khôngphải vài người trong vài tháng nữa mà là hàng trăm người trongnhiều năm, trong mười năm Hệ mềm như chương trình điều khiểnviễn thông, một công ti quốc tế có thể có 3, 4 nhóm làm việc tại 3,

4 nước khác nhau, mỗi nhóm hai, ba trăm người Chương trìnhđiều khiển tổng đài điện thoại hiện bán khắp nơi trên thế giới đãđược phát triển trong vòng 5 năm, bao gồm hàng chục nghìn đơn vịngười làm

Số người tham gia phát triển đông tới vài trăm, thời gian pháttriển sản phẩm lâu nhưng thời gian sử dụng chúng còn lâu hơn nữa

Và phần mềm không bao giờ giữ nguyên cả, bao giờ cũng thay đổi.Nhu cầu của người sử dụng ngày càng tăng, máy móc thiết bị điện

tử ngày càng rẻ và ngày càng làm được nhiều chuyện Bởi vậyngười ta thấy cần phải có phương pháp tương đối kỉ luật và nhất làcần có ngôn ngữ chung để trao đổi khi làm ra các sản phẩm

Và như vậy cần có kĩ nghệ phần mềm vì khách hàng đòi hỏinhững phương pháp và ngôn ngữ ấy Nếu có một ngôn ngữ mô tảchung thì khách hàng cũng hiểu ngôn ngữ đó và như vậy nắm đượcsản phẩm tốt hơn

Kĩ nghệ phần mềm có ích lợi gì? Có một vấn đề rất quantrọng cho các nước đang phát triển là những nước đang phát triểnthì phát triển rất nhanh Và phát triển có nghĩa là thay đổi Nhữngqui trình sản xuất vật phẩm, quản lí những cơ sở thông tin của các

cơ quan, doanh nghiệp, trong các nước đang phát triển cần thay đổi

rất nhanh theo tiến độ thay đổi Và sự thay đổi đó muốn thay đổi

được nhanh thì nó phải sạch sẽ, nó phải vuông tròn đâu ra đấy

Thêm bớt cái gì thì không ảnh hưởng đến các chuyện khác Tức là

phải làm được những sản phẩm phần mềm sạch sẽ, đúng tiêu chuẩn

công nghệ

Một vấn đề khác là để làm gia công cho người khác thì phải

học hỏi cách làm của thế giới Nếu làm gia công cho người khác

thì cũng nên biết người khác chờ đợi ở người kĩ sư phần mềm

những hiểu biết gì, những phương pháp làm việc như thế nào

Người làm phần mềm từ hai ba chục năm nay trên thị trường

đã trở thành loại sản phẩm hiếm và quí Họ thay đổi công việc

luôn, họ tới một công ti tham dự chừng 4-5 năm, làm xong việc rồi,

lại chuyển sang chỗ khác, việc khác Sản phẩm họ để lại đó làm

sao người tiếp khác tiếp thu được? Cho nên phải có một ngôn ngữ,

một cách trình bày chung để làm sao sản phẩm độc lập với người

sản xuất Đó là một nguyên tắc tuyệt đối của kinh tế thị trường:

Sản phẩm và người sản xuất độc lập với nhau

Làm việc tập thể không phải là làm việc riêng của nhóm năm

mười người Sản phẩm phải phù hợp với yêu cầu chứ không phải là

sản phẩm do một người nào đó nghĩ ra rồi làm và bán được Trong

thực tế, cũng có trường hợp cá nhân xuất sắc nghĩ ra được sản

phẩm và sau đó sản phẩm này tràn ngập thị trường Ví dụ rất rõ là

những trang tính điện tử mà bây giờ người ta quen với cái tên là

Excel Đó là sáng tác của một cá nhân và người đó không phải là

một chuyên gia tin học, chỉ là một người làm kế toán Anh ta thấy

cần làm những việc mình vẫn làm nhưng trên máy tính, rất đơn

giản: chia cột chia hàng ra rồi thực hiện tính toán Một ý kiến hết

sức giản dị nhưng phải có một người đầu tiên nêu ra ý kiến này

Nhưng đấy là những trường hợp đặc biệt Thông thường muốn sản

phẩm phù hợp yêu cầu thì phải có công tác tiếp thị Phải tiếp xúc

với khách hàng mới lấy được yêu cầu của khách hàng Đấy là khâu

khó nhất trong áp dụng tin học, không phải là việc viết chươngtrình

Người ta làm gì trong kĩ nghệ phần mềm? Người ta có một

số phương pháp và những phương pháp đó hiện bây giờ chưa phải

đã là chuẩn hoá Mọi người đã học về tin học đều biết, máy tính làvạn năng Nó vạn năng trong ý nghĩa là nếu người ta nghĩ ra đượcmột cách giải quyết vấn đề nào đó thì máy tính cũng có thể làmtheo cách giải quyết đó Điều này đã được nhà toán học người AnhAlain Turing chứng minh Như vậy nếu nó là vạn năng thì bất cứmột vấn đề gì nếu mô tả được rõ ràng đều có thể giao cho máy tínhthực hiện

Tuy nhiên lại không có phương pháp vạn năng nào để theo

đó tự động máy tính giải được tất cả mọi vấn đề Máy tính chỉ tựđộng được khi người ta đã trao cho máy một mô tả cách làm rõràng Nhưng không có phương pháp vạn năng cho người để giảiquyết mọi vấn đề Nếu đã có một phương pháp vạn năng để viếtphần mềm thì khi đó không cần người làm nữa Như vậy, nói riêngkhông có phương pháp nào để viết ra được bất cứ phần mềm nào Phương pháp để viết phần mềm cho tính toán trong xây dựngkhác với phương viết phần mềm cho quản lí ngân hàng, khác vớiphương pháp viết phần mềm cho làm các trang Web chẳng hạn.Không có phương pháp tuyệt đối cho mọi phần mềm Và như vậycần nắm những phương pháp tuỳ theo kinh nghiệm cụ thể Cần làmmột số phương pháp trên một số miền vấn đề rồi sau đó người làmphần mềm có kinh nghiệm sẽ chọn lựa phương pháp thích hợp ởnhững bước đầu của dự án của mình

Tuy nhiên cũng có một điều tương đối tốt là một số nhà làm

về phương pháp đã họp với nhau và đồng ý với nhau để đưa ra mộtcái gọi là UML (Unified Modelling Language) - một ngôn ngữ để

mô hình hoá thống nhất Họ thống nhất với nhau, có 3-4 người vàbây giờ gần như là họ có được sự đồng thuận trong nghề với những

thống nhất của họ Ngụn ngữ mụ hỡnh hoỏ thống nhất UML là sự tụ

hội của nhiều cỏch thức mụ tả vấn đề, nú khụng cú cỏi thừa và cỏi

trựng lặp Nú phục vụ cho nhiều miền vấn đề, nhiều phương phỏp

1.3 Tiến hoỏ phần mềm

Tiến hoỏ phần mềm được xem xột trờn bốn gúc nhỡn trong

quỏ trỡnh tạo ra cỏc phần mềm: yờu cầu của vấn đề, đặc tả vấn đề,

thiết kế và cài đặt hệ thống phần mềm Bốn gúc nhỡn này cho

chỳng ta thấy được sự tiến hoỏ từ thấp đến cao theo chiều thời gian

của toàn bộ vấn đề

Phần mềm cú vào khoảng những năm 1955 đến năm 2000

hiện nay và cú thể được chia thành 3 giai đoạn Yờu cầu của giai

đoạn thứ nhất từ những năm 1955 đến khoảng 1965 - 1970 là tớnh

toỏn và quản lớ rời rạc, quản lớ nhỏ Đặc tả của những yờu cầu đúlỳc đú là dựng ngụn ngữ thường, viết ra: Tụi muốn cú 1 tệp dữ liệuchứa những điều này, điều này Mỗi ngày cập nhật nú mấy lần.Phiếu sản phẩm, bỏn mỗi sản phẩm và ghi vào phiếu bỏn những cỏi

gỡ thỡ chương trỡnh phải đọc để cho vào tệp dữ liệu đú v.v Thiết

kế lỳc bấy giờ nằm luụn trong việc người ngồi viết chương trỡnh vàhọc những giải thuật để viết chương trỡnh cho tốt Đọc dữ liệu vào,viết dữ liệu ra, sắp xếp, tỡm kiếm, xoỏ, cập nhật v.v Thời đú cỏcchương trỡnh đơn giản và thực hiện xử lớ theo lụ

Giai đoạn thứ nhỡ vào khoảng từ những năm 1970 đến 1985.Lỳc này đó cú cỏc nhu cầu về phỏt triển cỏc chương trỡnh thời gianthực, xõy dựng cỏc mạng cục bộ và nối cỏc cơ sở dữ liệu với nhau.Đặc tả thời đú chỳ trọng vào đặc tả đầu vào, đầu ra, và luồngchuyển dữ liệu Tức là dữ liệu chuyển từ đầu vào đến tệp nào rồi

nú xử lớ như thế nào đến đầu ra của một xử lớ, mà nú lại là đầu vàocủa một xử lớ khỏc Thiết kế thời đú chỳ trọng tới cấu hỡnh hệthống, system configuration, tức là đó phải cú mỏy tớnh, cú đĩacứng, cú mỏy đọc bỡa, và bắt đầu cú viễn thụng Một người làmchương trỡnh cho một cơ quan lớn thỡ vấn đề lớn đối với họ lỳc bấygiờ là cấu hỡnh hệ thống Giải thuật và dữ liệu lỳc đú cũng đặt ravấn đề cú cấu trỳc quan trọng, vỡ bắt đầu làm vấn đề lớn thỡ phải cúnhững mụ tả cú cấu trỳc cho dễ hiểu Về những phương phỏp càiđặt thời đú, người ta để ý đến hệ điều hành, như DOS của IBM hayUnix Và đó cú những cơ sở dữ liệu thường trực cú thể truy nhậpbằng viễn thụng được

Giai đoạn thứ ba bao gồm những vấn đề quen thuộc với mọingười Đõy là thời của mỏy vi tớnh PC, thời nối mạng tầm rộng,diện rộng, với Internet Đặc tả dự ỏn được biết nhiều là hướng sựvật, nhiều nơi gọi là hướng đối tượng Cụng cụ CASE (ComputerAided Software Engineering) là những cụng cụ mà người đặc tảvấn đề cần phải biết Tầng thiết kế để ý nhiều đến tớnh mụ đun, để

ý đến sự vật, để ý đến giao thức (protocol), và giao diện (interface)

55 60 65 70 75 80 85 90 95 2000

PC, Nối mạ ng tầm rộng, Internet

Dù ng lại PM đóng gói, ngôn ngữ

h ớ ng sự vật

H ớ ng sự vật, Vòng đời PM, CASE

Tính mô đun, Sự vật, Giao thức, Giao diện

Đ ầu vào + đầu

ra ; dòng chuyển dữ liệu

Thời gian thực, nối mạ ng cục bộ,CSDL

HĐ H, Hệ thống CSDL th ờng trực

Cấu hình hệ thống, cấu trúc GT và DL

Đ ặc tả

Thiết kế

Cài đặt

Yêu cầu

Về cơ bản dựa trờn mụ hỡnh liờn nối hệ thống mở OSI, cũn giao

thức và giao diện thỡ xỏc định ra việc trao đổi giữa cỏc sự vật Và

trong cài đặt thỡ dựng ngụn ngữ hướng sự vật là một đặc điểm Đặc

điểm thứ nhỡ là người ta chỳ trọng dựng lại những phần mềm đúng

gúi Chương trỡnh xử lớ văn bản hay trỡnh duyệt Nestcape hay

Internet Explorater, tất cả đều là phần mềm đúng gúi Vấn đề cài

đặt bõy giờ là làm sao tớch hợp những hệ mềm đúng gúi và vấn đề

riờng của từng nghiệp vụ thỡ dựng phần mềm được sản xuất theo

hướng sự vật

Trong lịch sử vào khoảng cuối những năm 60, 60-68, người

ta loan bỏo cỏi gọi là khủng hoảng phần mềm, cho tới nay vẫn cũn

khủng hoảng phần mềm Tỡnh trạng khủng hoảng bõy giờ là khủng

hoảng thiếu người Khủng hoảng thời bấy giờ là khụng biết cỏch

làm phần mềm cho tốt Bởi vậy đó cú những yờu cầu kĩ nghệ hoỏ

phần mềm từ thời ấy

Mười năm sau, theo kiểm tra của kế toỏn Mĩ thỡ: 50% hợp

đồng vượt quỏ ngõn sỏch, tức là những người làm phần mềm luụn

luụn chi tiền quỏ mức, khụng bao giờ chi ớt hơn 50% hợp đồng là

quỏ tiền, 60% là trễ, 45% là giao nộp nhưng khụng đỳng yờu cầu

khỏch hàng 22% trong 45% đú thỡ một nửa là khụng thể sửa chữa

nhỏ được nữa mà phải thiết kế lại toàn bộ Và 29% là thất bại hoàn

toàn, khụng bao giờ giao nộp

Năm 1979 theo thống kờ của Tom de Marco trong một cuốn

sỏch thỡ vẫn cũn là 25% hệ mềm lớn thất bại Thống kờ của Copers

Jones, 19 năm sau, 1991: trung bỡnh cỏc hệ thụng tin quản lý bị trễ

1 năm và vượt ngõn sỏch 100% Điều này núi lờn là người ta chưa

quản lớ được phần mềm, cỏch đõy 10 năm, tuy rằng những hiểu biết

về MIS (Management Information System) là đủ, ớt thất bại, nhưng

người ta luụn luụn bị vượt ngõn sỏch

Những tiến bộ cho đến bõy giờ là gỡ? Cỏc hệ mềm ngày càng

lớn, ngày càng tớch hợp Ngày xưa chạy đơn lẻ, bõy giờ thỡ chạy

thường trực Khụng những thường trực mà phần mềm cũn truynhập được ở khắp nơi trờn thế giới Thành ra người ta đó phục vụđược những yờu cầu ngày càng cao bằng những sản phẩm ngàycàng lớn Nhưng tỉ số thất bại, tỉ số mà vượt quỏ hạn quản lớ, quỏthời gian và quỏ hạn tiền thỡ vẫn như vậy Tiến bộ là ở đú, cỏc hệmềm ngày càng lớn và chất lượng ngày càng cao, vỡ chất lượng củamột hệ mềm thường trực 24 giờ trờn 24, 7 ngày trờn 7

Và như vậy năng suất lập trỡnh tớnh theo dũng lệnh vàokhoảng 6% một đầu người Hiện bõy giờ năng suất lập trỡnh bõygiờ khoảng 20-40 dũng lệnh một ngày tuỳ dự ỏn khú hay dễ.Nhưng 1 dũng lệnh bõy giờ bằng mấy chục lần dũng lệnh thời xưa

Đú là vỡ ngụn ngữ lập trỡnh ngày càng mạnh, thỡ tiến bộ ở chỗ đú

Và nú mạnh bằng hàng chục lần ngày xưa và ngốn tài nguyờn bằnghàng nghỡn lần ngày xưa

1.4 Qui trỡnh phần mềm

Một số điểm đặc biệt về quỏ trỡnh phỏt triển phần mềm cầnđược đề cập tới vỡ nú khỏc với quản lớ phỏt triển cỏc sản phẩmkhỏc Việc phỏt triển phần mềm cần tuõn thủ theo những qui trỡnhnhất định Một trong những qui trỡnh thường được lấy làm nền tảng

là qui trỡnh Thỏc đổ "Waterfall" Tuy rằng cú nhiều qui trỡnh phỏttriển phần mềm khỏc và sẽ được giới thiệu ở sau, nhưng chỳng đềudựa trờn qui trỡnh Thỏc đổ, bao gồm nhiều khõu nối tiếp nhau

Sử dụng Thử

Thực hiện

Thực hiện thế nào ? Cần làm

gì đó ?

Thứ nhất người ta cần đặt câu hỏi : cần làm gì? Sau đó đặt

câu hỏi: trước khi thực hiện thì cần suy nghĩ về cách thực hiện như

thế nào? Rồi mới thực hiện Thực hiện xong thì thử Thử xong thì

đưa vào sử dụng Qui trình này được gọi là "thác đổ" vì nó như

nước chảy xuống và người ta cố gắng không chảy ngược lên Tức

là mỗi giai đoạn nọ quyết định giai đoạn sau Đây cũng là một vấn

đề lí thuyết chứ trên thực tế thì không thể hoàn toàn như thế được

Nhưng dù sao cũng phải có khuôn mẫu để tuân theo

Xác định cần làm gì chính là việc lấy yêu cầu của người

dùng - user requirement Phân tích và thiết kế chia nhỏ vấn đề ra

như thế nào Chung quanh đó có 2 vấn đề bao trùm, ngôn ngữ

UML và quản lí phần mềm Ngôn ngữ UML bao trùm là vì nó mô

tả tài liệu chạy qua tất cả các khâu Và quản lí phần mềm cũng là

một vấn đề bao trùm Dĩ nhiên không phải đến đây ta mới đề cập

về vấn đề quản lí, quản lí phần mềm là một vấn đề cần đề cập tới

từ trước khi làm phần mềm

1.5 Về cách giải quyết vấn đề

1.5.1 Từ lập trình đi lên

Lập trình đã là trung tâm điểm của tin học trong suốt thời kì

đầu phát triển: xây dựng và hoàn thiện máy tính điện tử, công cụ

xử lí thông tin do con người tạo ra Mục đích ban đầu của lập trình

là làm ra các chương trình điều khiển máy tính hoạt động xử lí tính

toán Do đó đối tượng ban đầu của lập trình là các bài toán khoa

học kĩ thuật

Khi những tiến bộ kĩ thuật đã cho phép chế tạo ra các máy tínhđiện tử ngày một hoàn thiện hơn thì việc ứng dụng các máy tínhnày vào sản xuất kinh doanh cũng bắt đầu phát triển theo Từ đóđối tượng của việc lập trình bắt đầu có sự thay đổi, mặc dầu vẫnnhắm vào việc làm cho máy hoạt động tốt hơn và dễ dùng hơn,phần lớn việc lập trình chuyển sang nhằm giải quyết các bài toánứng dụng trong kinh doanh và quản lí trên máy tính

Yêu cầu của thực tế không ngừng nâng lên khi các máy tính

xử lí thông tin được đưa vào sử dụng trong sản xuất thường ngày.Vai trò của máy tính tham dự trong các hoạt động quản lí thông tincủa mọi tổ chức không ngừng tăng lên Điều này dẫn tới một sựdịch chuyển nữa từ việc lập trình cho các bài toán quản lí riêng lẻsang việc xây dựng các hệ thống phần mềm lớn mô phỏng cho các

hệ thống thực tế trong máy tính

Đi kèm với sự thay đổi về đối tượng của việc lập trình như vậy

là sự thay đổi tương ứng trong cách thức người ta nghĩ và giảiquyết vấn đề thông qua việc sử dụng máy tính Nếu như trongnhững ngày đầu của máy tính, việc lập trình là công việc chủ yếucủa một vài người, quan niệm toàn bộ mọi vấn đề và triển khai mọihoạt động lập trình, thì ngày nay mô thức làm việc ấy không cònthích hợp nữa Bây giờ thực tế yêu cầu cần có những hệ thống phầnmềm lớn mà việc tạo ra nó phải cần công sức của nhiều người cùnglàm việc, không ai một mình có thể xây dựng ra được các hệ thốngnhư vậy

Chúng ta sẽ xem xét ở đây về kĩ nghệ phần mềm, được pháttriển ra từ nền tảng lập trình trước đây Để nhìn một cách toàncảnh, chúng ta bắt đầu từ việc xem xét cách thức giải quyết vấn đềcủa lập trình và từ đó chuyển sang xem xét theo góc độ kĩ nghệ.Các tri thức chính liên quan tới lập trình là:

 Tri thức về cách hoạt động của công cụ xử lí thông tin, cách

thức máy móc làm việc, từ cụ thể tới trừu tượng, từ máy tính cụ

thể tới các ngôn ngữ lập trình cấp cao Nói cách khác đó là tri

thức về các vấn đề cú pháp và ngữ nghĩa của công cụ xử lí

thông tin Tư duy giải thuật, tư duy thuật toán chiếm vị trí chủ

yếu ở đây

 Tri thức về cách triển khai giải quyết vấn đề bằng máy tính,

cách thức con người làm việc với máy tính để giải quyết các

bài toán đặt ra Nói cách khác đó tri thức về cách thức triển

khai chương trình điều khiển máy tính hoàn thành một chức

năng, nhiệm vụ tính toán xử lí nào đó Tư duy hướng vấn đề, tư

duy hệ thống chiếm vị trí chủ yếu ở đây

Như vậy bất kì ai muốn làm chủ và sử dụng được hữu hiệu

công cụ xử lí thông tin máy tính cũng cần phải am hiểu đầy đủ hai

loại tri thức trên: tri thức về bản thân công cụ và tri thức về việc sử

dụng công cụ để giải quyết các bài toán, vấn đề thực tế Cả hai loại

tri thức này mỗi ngày đều một tiến hoá và cao cấp hơn Tri thức về

công cụ tính toán, về máy tính, thường do các tiến bộ của CNTT

trên thế giới đem lại Chúng ta được thừa hưởng những thành tựu

khoa học công nghệ lớn lao của cả nhân loại được cụ thể hoá trong

các thiết bị máy móc ngày càng mới này Nhưng điều quan trọng

hơn là chúng ta phải có tri thức vận dụng hữu hiệu những công cụ

này vào thực tế thì mới có thể đóng góp thêm phần tri thức gia tăng

của mình Nhìn rộng ra, nếu xã hội nào biết phát huy và thúc đẩy

việc sử dụng hữu hiệu công cụ mới thì sẽ phát triển nhanh hơn

Các tri thức về ngôn ngữ lập trình, về các vấn đề liên quan tới

việc tổ chức chương trình trong các ngôn ngữ lập trình đã là những

tri thức được đưa vào giảng dạy trong các giáo trình cơ sở về tin

học Đấy là loạt vấn đề liên quan tới bản thân công cụ máy tính,

cũng quan trọng nhưng chưa đủ

Nay một vấn đề cần được bàn luận chi tiết hơn là cách giảiquyết bài toán, vấn đề trên máy tính, thường vẫn được hiểu là việclập trình Thời kì đầu của việc phát minh ra máy tính, lập trình chỉ

là việc mã hoá một thuật toán theo ngôn ngữ lệnh của một máy nào

đó, rồi sau đó chỉnh chương trình để cho máy chạy được cho ra kếtquả Như vậy việc lập trình cho máy tính phải trải qua các giaiđoạn sau:

1 Nhận yêu cầu tính toán

2 Tìm hiểu bài toán đặt ra

3 Phát triển thuật toán giải bài toán đó

4 Chuyển thuật toán này thành chương trình của máy tính

5 Cho chương trình chạy trên máy để kiểm thử xem đãchương trình chạy đúng chưa và chỉnh cho chương trìnhchạy đúng

6 Thực hiện tính toán và chuyển giao kết quả tính toán chonơi yêu cầu

Tiến trình thực hiện việc lập trình này mang nặng tính chấtphụ thuộc vào máy tính Các yêu cầu tính toán thì không mấy bịphụ thuộc vào máy tính, nhưng các bước phát triển kế tiếp ngàycàng chứng tỏ sự lệ thuộc vào kết cấu hoạt động của máy móc Từtrình tự trên chúng ta thấy rằng việc lập trình nếu được xét theoquan điểm mã hoá thì thực sự chỉ là một bước (bước 4) trong toàn

bộ tiến trình giải quyết vấn đề Do vậy điều cần được đề cập tới ởđây là làm sao người ta có thể đi từ các vấn đề, yêu cầu của thực tế

để tìm ra giải pháp cho vấn đề và cuối cùng thực hiện giải pháp đótrên máy tính Như vậy hai khía cạnh khác nhau cần phải đượcxem xét tới: khía cạnh phát hiện vấn đề và mô tả vấn đề thực tế, vàkhía cạnh mô tả và thực hiện giải pháp cho vấn đề trong máy tính.Khi ứng dụng của tin học được mở rộng, không chỉ giải quyếtcác vấn đề tính toán khoa hoch kĩ thuật mà chuyển sang các vấn đề

về quản lí, kinh doanh, tổ chức và xử lí dữ liệu, thì có sự thay đổi

căn bản trong thái độ con người tiếp cận tới máy tính Máy tính,

mặc dầu vẫn được hoàn thiện thêm, không còn là mối quan tâm

nghiên cứu chủ chốt của tin học nữa mà trở thành công cụ giúp cho

con người nhận thức và làm chủ các tiến trình điều khiển trong các

hoạt động kinh tế và xã hội

Sự quan tâm của người ta chuyển dần sang việc xây dựng các

hệ thống hoạt động lâu dài trên máy tính, mô phỏng các hoạt động

quản lí và xử lí thông tin của con người trong thực tế Từ đó xuất

hiện nhu cầu cần chính xác hoá và làm rõ ràng thành những qui

trình kĩ nghệ để giúp cho con người khắc phục được độ phức tạp

của các bài toán thực tế Một điều ngày càng trở nên hiển nhiên là

các hệ thống mô phỏng trên máy tính ngày càng phức tạp, đòi hỏi

sự phối hợp hoạt động của rất nhiều người trong một thời gian dài

Do đó, song song với việc hình thành các qui trình phát triển hệ

thống, phần mềm thì cũng hình thành nhu cầu quản lí các tiến trình

phát triển phần mềm và nhu cầu phát triển ngôn ngữ chung để mô

tả cho mọi hoạt động phát sinh trong tiến trình này

Phân tích trình tự làm việc trên đây đối với máy tính, chúng ta

thấy có những điểm tương đồng với trình tự kĩ nghệ phần mềm

hiện nay Bước thứ nhất phản ánh việc nhận biết vấn đề, bài toán

thực tế, chưa động chạm gì tới cách giải quyết cũng như cách thực

hiện trên máy tính Bước này được đặc trưng bởi việc tìm hiểu và

mô tả được về yêu cầu đặt ra Theo ngôn ngữ hiện đại đây là bước

xác định yêu cầu hệ thống và phần mềm

Bước thứ hai đi sâu thêm một chút để có thể mô tả được vấn

đề là gì và xác định có thể tiến hành giải quyết được hay không

Theo ngôn ngữ hiện đại đây là bước phân tích hệ thống để tìm hiểu

khả năng giải quyết và phác thảo cách giải quyết

Bước thứ ba là việc xây dựng giải pháp, từ không gian vấn đề

đặt ra, chuyển sang không gian giải pháp cho vấn đề Theo ngôn

ngữ hiện đại thì đây là bước thiết kế hệ thống Thực sự bước này

bao gồm hai thành phần tương đối khác biệt: thiết kế kiến trúcchung của hệ thống, và thiết kế chi tiết Thiết kế kiến trúc thực hiệnphân chia ra các hệ con và xác định mối quan hệ trao đổi thông tingiữa chúng nhằm đưa ra một giải pháp tổng thể cho vấn đề, chưa bị

lệ thuộc vào các yếu tố chi tiết của máy tính Các thiết kế chi tiết

đề cập tới những thiết kế về dữ liệu, mô đun và giao diện xác định

ra cách thực hiện hệ thống trên máy tính

Bước thứ tư thường được mô tả là bước lập trình hay mã hoácho giải pháp, xây dựng một hệ thống thực hiện được trên máy tínhdựa theo các thiết kế đã được vạch ra Trước đây bước này vẫnđược coi là chủ chốt và chủ yếu nhất đối với các chuyên viên lậptrình Ngày nay, với một số ứng dụng tiêu biểu, đã có các công cụsinh chương trình, và mối quan tâm của người làm phần mềm đượcdồn nhiều hơn vào các bước thu thập yêu cầu, phân tích và thiết kế

hệ thống

Bước thứ năm là bước kiểm thử giải pháp, cho phép thẩm địnhlại tính đúng đắn của giải pháp được thực hiện trên máy tính theocác yêu cầu ban đầu đã đặt ra Có nghĩa là xem xét lại xem hệthống được xây dựng ra có đáp ứng đúng cho các yêu cầu ban đầuhay không Thường bước này được thực hiện trong hai pha Phathứ nhất là người xây dựng ra hệ thống trực tiếp kiểm thử đề đảmbảo hệ thống chạy thông và đáp ứng những yêu cầu thiết kế Phathứ hai là người thuê làm hệ thống trực tiếp kiểm thử xem hệ thống

có đáp ứng đúng cho yêu cầu của mình hay không

Bước thứ sáu tương ứng với bước cuối cùng là vận hành vàbảo trì hệ thống đã được xây dựng Với việc hiện nay các ứng dụngcủa máy tính không còn chỉ là giải quyết các vấn đề riêng lẻ màchủ yếu là mô phỏng và điều khiển các hoạt động thực tế, việc bảotrì phần mềm và hệ thống trở thành công việc chủ yếu và thườngxuyên, để đảm bảo cho hệ thống tiến hoá kịp với những thay đổicủa thực tế Do đó chính bước này dần trở thành rất quan trọng và

có ánh hưởng nhiều tới cách tiếp cận giải quyết vấn đề Việc xây

dựng hệ thống một lần rồi thôi là khác xa với việc xây dựng hệ

thống để hoạt động được lâu dài và luôn hữu ích

Chúng ta thấy rằng như vậy để giải quyết các vấn đề của thực

tế thì cần phải tiến hành theo trình tự trên đây, dù cho vấn đề là lập

trình hay rộng hơn, vấn đề mô phỏng thực tế trên máy tính Điều

này đưa tới việc chúng ta cần xem xét kĩ hơn về các vấn đề có liên

quan tới không gian vấn đề, không gian bài toán, không gian các

giải pháp và bước chuyển từ không gian vấn đề sang không gian

giải pháp, tức là việc giải quyết vấn đề Trên cơ sở xem xét qui mô

lớn này mà có thể thấy rõ hơn các vấn đề của phương pháp luận

1.5.2 Vấn đề, giải pháp và giải quyết vấn đề

Các tổ chức tạo ra và chuyển giao sản phẩm và dịch vụ để đáp

ứng cho nhu cầu và đòi hỏi của khách hàng Các yêu cầu có thể

được đặc trưng là vấn đề hay bài toán Sản phẩm và dịch vụ giải

quyết cho những yêu cầu đó được đặc trưng là giải pháp Để

chuyển giao giải pháp có giá trị (chất lượng tối đa với chi phí tối

thiểu trong phạm vi thời gian tối thiểu), tổ chức phải nắm bắt (thu

nhận), trao đổi (dùng chung), và sử dụng tri thức Giá trị của giải

pháp được xác định bởi phẩm chất của sản phẩm hay dịch vụ, chi

phí của sản phẩm hay dịch vụ, và thời gian cần để tạo ra sản phẩm

hay cung cấp dịch vụ Các tổ chức giải quyết vấn đề cho khách

hàng của mình, các nhân viên giải quyết vấn đề cho người chủ lao

động, các bác sĩ giải quyết vấn đề cho bệnh nhân, vân vân Bên

trong những kiểu quan hệ này, tri thức là nhân tố thành công chủ

chốt

Các tổ chức dùng công nghệ để phát tán và trao đổi thông tin

để cho nhân viên của mình có thể giải quyết các vấn đề nghiệp vụ

Công nghệ chỉ là công cụ; không có con người biết cách áp dụng

nó và hiện thực hoá tiềm năng của nó, thì nó là vô dụng Bởi vì thếgiới nghiệp vụ và thế giới công nghệ là trong một luồng biến đồithường hằng, nên chúng ta được yêu cầu phải quản lí độ phức tạpđang tăng lên bên trong những nỗ lực đang tiếp diễn Tuy nhiên,chúng ta không nên quên rằng công nghệ là phương tiện cho mụcđích chứ không phải là bản thân mục đích

Để thực hiện việc giải quyết vấn đề, giữa khách hàng và ngườicung cấp giải pháp cần có một số văn bản pháp lí ràng buộc, dưới

dạng các dự án và hợp đồng Dự án là nỗ lực giải quyết vấn đề.

Chúng bao gồm việc hiểu hay quan niệm về vấn đề, giải quyết vấn

đề, và thực hiện hay hiện thực giải pháp Các thực thể người hay tổ

chức tham gia vào trong một dự án được biết tới là những người

tham dự Một số người tham dự là người mà vấn đề được giải

quyết cho Họ chịu trách nhiệm đóng góp tri thức của mình để hiểuvấn đề và kiểm chứng lại giải pháp Những người tham dự khácchịu trách nhiệm đóng góp tri thức của mình để thực hiện giải

pháp Kết quả của một dự án được biết tới như là việc chuyển giao

sản phẩm làm việc Chúng là các sản phẩm hay dịch vụ giải quyết

cho một vấn đề

Ta hãy xét một tổ chức gặp khó khăn trong việc phân bổ tối ưunhân viên của mình cho các dự án khác nhau Tổ chức muốn cómột hệ thông tin để duy trì thông tin về nhân viên và dự án Giảipháp phải cung cấp khả năng để phân bổ nhân viên cho các dự ándựa trên kĩ năng của họ và nơi họ có thể được sử dụng tốt nhất.Trong khi giải quyết vấn đề này, một cách tiếp cận tổng thể phải đềcập tới cách chúng ta sẽ hiểu và quan niệm vấn đề, suy diễn ra giảipháp cho vấn đề, và thực hiện hay hiện thực hoá giải pháp Cáchtiếp cận này sẽ xác định cách chúng ta xem xét vấn đề (mô thức)với mục đích để hiểu nó Chúng ta sẽ áp dụng tri thức của mình vềtình huống và các qui tắc cơ bản khác (trực cảm) thu được từ kinhnghiệm khác để suy diễn ra giải pháp này (thông qua các vậtphẩm) Nỗ lực của chúng ta sẽ được tổ chức (vòng đời) như một

chuỗi các bước (hoạt động) (có thể tương tranh) để cho nó có thể

được quản lí để phát triển sản phẩm có kết quả

Vấn đề xuất hiện bên trong một khung cảnh (miền hay không

gian) nghiệp vụ Giải pháp phải được thực hiện để khớp với bên

trong kết cấu nền (miền hay không gian) công nghệ thông tin của

tổ chức Vấn đề (hệ thống) nghiệp vụ phải được hoàn toàn hiểu rõ

dưới dạng các yêu cầu của nghiệp vụ, và sản phẩm hay hệ thông tin

phải được hiểu đầy đủ dưới dạng các cách thức nó đáp ứng cho

những yêu cầu đó Hệ thông tin kết quả hay sản phẩm phần mềm

cũng phải được tổ chức (kiến trúc) để khớp vào trong kết cấu nền

công nghệ của tổ chức Khi chúng ta quan niệm vấn đề và làm việc

hướng tới việc thực hiện giải pháp này thì chúng ta sẽ nắm được tri

thức (mô hình) về vấn đề nghiệp vụ và hệ thông tin, ra quyết định

(góc nhìn kiến trúc) về cách chúng ta sẽ đề cập tới các vấn đề khác

nhau, và nên có khả năng mô tả và trao đổi thông tin này (các biểu

đồ)

Phương pháp xác định ra cách tiến hành các nỗ lực giải quyết

vấn đề Chúng xác định cách tiếp cận giải quyết vấn đề và các cấu

phần của nó Chúng xác định cách vấn đề và giải pháp được xem

xét trong mối quan hệ với cách tiếp cận giải quyết vấn đề; điều này

được biết như khía cạnh mô tả của phương pháp vì nó mô tả cho

cách thức tri thức được nắm bắt và trao đổi đối với vấn đề và giải

pháp Các phương pháp cũng xác định ra cách tiếp cận giải quyết

vấn đề được dùng để giải vấn đề và suy dẫn ra giải pháp; điều này

được biết tới như khía cạnh qui tắc của phương pháp vì nó mô tả

cho cách thức tri thức được bẩy ra để giải quyết vấn đề Phương

pháp xác định về mặt mô tả cách thức vấn đề và giải pháp được

xem xét, và xác định về mặt qui tắc cách thức nỗ lực giải quyết vấn

đề có thể được thực tế hoá

Tiến trình là việc thực hiện của phương pháp Chúng dùng

cách tiếp cận giải quyết vấn đề của phương pháp để giải quyết vấn

đề và thực hiện giải pháp Các tiến trình được xác định bởi phương

pháp; điều này được biết như khía cạnh tĩnh của tiến trình vì nó là

mô tả về cách vấn đề có thể được giải quyết Các tiến trình áp dụngcác phương pháp bên trong dự án để giải quyết các vấn đề; điều

này được biết như khía cạnh động của tiến trình.

Vì các dự án có thể rất phức tạp nên các phương pháp nênđược dùng để cung cấp một kết cấu nền cho tiến trình giải quyếtvấn đề Chúng nên được xem xét như các gợi ý và khuyến cáo tổchức và tạo điều kiện cho tiến trình giải quyết vấn đề hơn là đượcxem xét như các qui tắc không linh động và cứng nhắc, hạn chế

nghệ thuật giải quyết vấn đề Phương pháp luận là việc phân loại,

hay tuyển tập có tổ chức tốt của các phương pháp có liên quan; do

đó, phương pháp có thể là một phần của phương pháp luận

Vấn đề thường được nói tới như những tình huống như là vì

chúng biểu diễn cho các điều kiện hiện tại; giải pháp tương tự được

nói tới như các tình huống sẽ là vì chúng biểu thị cho các điều kiện

đích mà chúng ta đang cố gắng đạt tới, xem Hình 1.1

Sử dụng

Đặc tả giải pháp thoả mãn cho yêu cầu

Các yêu cầu

do vấn đề áp đặt lên giải pháp

Thông minh

Mô tả

Mụ tả Giải quyết vấn đề

phỏp

Vấn đề con Vấn đề con phỏp conGiải phỏp conGiải

Vấn đề con Vấn đề con phỏp conGiải phỏp conGiải

Hỡnh 1.1 Gúc nhỡn chung về giải quyết vấn đề

Một tỡnh huống khụng gõy ra khú khăn cú thể vẫn được xử lớ

như một vấn đề để hiểu nú; tuy nhiờn, giải phỏp lại khụng là gỡ

khỏc hơn việc hiểu về tỡnh huống Điều này phỏt sinh trong việc

xỏc định cỏc đặc trưng, thay vỡ cỏc yờu cầu, của tỡnh huống và cung

cấp một gúc nhỡn mụ tả thuần khiết về tỡnh huống mà khụng cú bất

kỡ gúc nhỡn mụ tả hay qui tắc nào về giải phỏp Điều này thường

được tiến hành khi một giải phỏp cho vấn đề là tồn tại, và giải phỏp

hiện cú cần được hiểu hay được đỏnh giỏ Việc giải quyết vấn đề

(Hỡnh 1.2) bao gồm cỏc nỗ lực hay tiến trỡnh hợp tỏc giải quyết vấn

đề Những nỗ lực như vậy bao gồm cỏc điều sau:

 Quan niệm và biểu diễn vấn đề dưới dạng dễ uốn nắn và

trao đổi được Điều này cho phộp vấn đề được biểu diễn

trong một ngụn ngữ nào đú để cho nú cú thể được thao tỏc

và trao đổi với người khỏc

 Xỏc định cỏc yờu cầu do vấn đề ỏp đặt lờn giải phỏp của

nú, tức là, cỏc yờu cầu được gõy ra bởi vấn đề mà giải phỏp

của nú phải thoả món

 Đạt tới một mụ tả về vấn đề bằng việc nhắm tới cỏc cõu

hỏi sau: Vấn đề là gỡ? Cỏc yờu cầu về vấn đề mà giải phỏp

của nú phải thoả món là gỡ? Trong một dự ỏn, nếu cỏc vấn

đề này cú thể được trả lời tối thiểu với đủ mức chi tiết, thỡ

nỗ lực đó đạt tới gúc nhỡn mụ tả của vấn đề

 Nhận diện hay xỏc định giải phỏp thoả món cỏc yờu cầu dovấn đề ỏp đặt

 Đạt tới một mụ tả về giải phỏp bằng việc nhắm tới cỏc cõuhỏi sau: Giải phỏp là gỡ? Đặc tả cho giải phỏp thoả món cỏcyờu cầu do vấn đề ỏp đặt là gỡ? Bờn trong một dự ỏn, nếucỏc vấn đề này cú thể được trả lời tối thiểu với đủ mức chitiết, thỡ nỗ lực đó đạt tới gúc nhỡn mụ tả của giải phỏp

Hỡnh 1.2 Gúc nhỡn chi tiết về giải quyết vấn đề

Qui tắc

Nếu giải pháp không thể được định ra cho một vấn đề, thì các

yêu cầu do vấn đề ấn định lên giải pháp của nó được nhóm lại,

phân loại, và tổ chức thành các vấn đề cấp dưới, được giải quyết

tương tranh Một vấn đề cấp trên có thể được dẫn về hay phân tách

một cách đệ qui thành các vấn đề cấp dưới Các vấn đề cấp dưới có

thể được giải quyết tương tranh, và giải pháp cho vấn đề nguyên

thuỷ có thể được mở rộng hay hợp thành đệ qui từ các giải pháp

cấp dưới Tiến trình dẫn về tiếp tục cho tới khi giải pháp cho vấn

đề nguyên thuỷ được suy dẫn ra Bởi vì tiến trình này là đệ qui nên

góc nhìn mô tả được dùng để phát hiện ra góc nhìn qui tắc Hơn

nữa, việc phân tách cho phép rất nhiều việc giải quyết vấn đề song

song và tương tranh cho nên toàn bộ tiến trình được giải quyết

Việc giải quyết vấn đề tiếp tục như sau:

 Đạt tới việc qui định về các bước bên trong một giải pháp giải

quyết cho vấn đề bằng việc đề cập tới câu hỏi sau: giải pháp có

yêu cầu của riêng nó (hay các vấn đề phụ thuộc) được thoả mãn

như thế nào? Trong phạm vi một dự án, nếu những câu hỏi này

có thể được trả lời một cách tối thiểu với đủ mức chi tiết cần

thiết, thì nỗ lực đã được đạt tới một góc nhìn qui tắc về giải

pháp

 Thực hiện việc biểu diễn cho giải pháp trong một dạng cụ thể

và dùng được

Tri thức là cấu phần chèn lấp lên cần phải được thâu tóm (thu

nhận), truyền trao (dùng chung), và làm đòn bẩy (sử dụng) để tạo

điều kiện thuận tiện cho tiến trình này Toàn bộ tri thức được bao

gồm trong một nỗ lực như vậy có thể được phân mảnh ra thành

những nhóm, với mỗi nhóm được liên kết với một phần nào đó của

nỗ lực (quan niệm, vấn đề, giải pháp, việc giải quyết vấn đề hay

thực hiện) tại bất kì điểm nào trong thời gian đã nêu Mối liên kết

này có ý nghĩa khi các phần tử tri thức ảnh hưởng tới nỗ lực; tức là

khi các phần tử tri thức được thu nhận, dùng chung hay sử dụngbên trong nỗ lực giải quyết vấn đề

Thông minh là khả năng tiến hành tiến trình giải quyết vấn đềbằng việc tổ chức tri thức trong một phân loại và áp dụng tri thứcmột cách có chiến lược qua nỗ lực giải quyết vấn đề để suy ra giảipháp

1.5.3 Vòng đời

Cách tiếp cận giải quyết vấn đề được tổ chức (theo vòng đời)

để đưa ra viễn cảnh quản lí và viễn cảnh phát triển Hai viễn cảnhnày làm cho các nỗ lực phát triển hệ thống được quản lí và thựchiện

Vòng đời

Giai đoạnquan niệm

Kết thúc Khởi đầu

Pha lặp

Lập kế hoạch Thực hiện Kiểm soát

Giai đoạn tiến hoá

Vòng lặp

Giai đoạn dừng Pha phát

triển

Hình 1.3 Vòng đời

Vòng đời (Hình 1.3) có thể được chia ra như sau Vòng đời là

tuyển tập các giai đoạn phân chia nỗ lực thành nhiều giai đoạn nỗ

lực, quản lí và kiểm soát được Mỗi giai đoạn bên trong vòng đời

đều là phần rời rạc của một luồng logic duy nhất để giải quyết vấn

đề Mỗi giai đoạn đều có cái vào, cái ra và đòi hỏi áp dụng các

nguyên tắc, kĩ thuật và công cụ lên các cái vào để sinh ra cái ra; có

tiêu chuẩn vào cho việc đưa vào hay khởi đầu giai đoạn; có tiêu

chuẩn ra để đi ra hay kết thúc giai đoạn này Điều này làm nảy sinh

việc kiểm điểm sản phẩm có đạt chất lượng không và từ đó để ra

quyết định liệu có tiếp tục hay bỏ dở toàn bộ nỗ lực Nhìn chung

người ta phân là ba giai đoạn: giai đoạn quan niệm, giai đoạn tiến

hoá và giai đoạn dừng

Giai đoạn quan niệm bao gồm việc nhận ra vấn đề hay cơ hội

và cam kết giải quyết vấn đề

Giai đoạn tiến hoá bao gồm nhiều chu kì tiến hoá từ việc khởi

đầu, lập kế hoạch, thực hiện, kiểm soát và kết thúc nỗ lực

Giai đoạn dừng bao gồm việc nhận ra rằng một giải pháp

không còn được yêu cầu nữa và kết thúc việc áp dụng giải pháp

này theo một cách thức có trật tự

Riêng trong giai đoạn tiến hoá, các chu kì tiến hoá cụ thể của

nó là:

 Khởi đầu bao gồm việc nhận ra rằng một chu kì tiến hoá là cần

trong việc đề cập tới vấn đề mới hay hiện có

 Lập kế hoạch bao gồm thiết kế và duy trì một sự sắp xếp để

thực hiện việc giải quyết vấn đề

 Thực hiện bao gồm việc phối hợp các nguồn tài nguyên để tiến

hành kế hoạch và giải quyết vấn đề

 Kiểm soát bao gồm việc điều phối và đo tiến trình sao cho cácbiện pháp sửa đổi có thể được tiến hành khi cần

 Kết thúc bao gồm việc chính thức hoá chấp nhận chu kì hiện tại

và ra nghị quyết cho vấn đề để theo đó chu kì sau được khởiđầu

Giai đoạn tiến hoá bao gồm một hay nhiều chu kì phát triển (chu kìtiến hoá), nơi từng chu kì phát triển lại bao gồm một nỗ lực đượcphân phối giữa các cấu phần của chu kì phát triển Nó bao gồmviệc tiến hoá của một sản phẩm khi nó trưởng thành và chín muồiqua sự tồn tại của nó

1.5.4 Chu kì và pha phát triển

Chu kì và pha phát triển (xem Hình 1.4) có đặc trưng: Mỗi chu

kì phát triển bao gồm bốn pha (khởi đầu, soạn thảo, xây dựng vàchuyển giao) và làm phát sinh ra một thế hệ sản phẩm Góc nhìn

vòng đời này thường được gọi là viễn cảnh quản lí vì nó cung cấp

các chỉ báo mức cao về tiến độ dự án

Thực hiện

Quan niệm

Giải quyết Vấn đề

Thế hệ sản phẩm Chu kì phát triển

Khởi đầu Soạn thảo Xây dựng Chuyển giao

Hình 1.4 Các pha phát triển bên trong chu kì phát triển

Pha phát triển khởi đầu thường dùng một chu kì lặp và bao

gồm các hoạt động sau:

1 Xác định và định ra phạm vi giới hạn, các mục tiêu và các yêu

cầu

2 Thiết lập một trường hợp hay luận cứ nghiệp vụ, bao gồm việc

xác định tầm nhìn, xác định các tiêu chuẩn thành công, định giá

các rủi ro, ước lượng thời gian và chi phí, và xác định kế

hoạch

3 Hội tụ vào việc hiểu hay hình thành khái niệm về vấn đề và

luận cứ để giải quyết nó (định phạm vi và trường hợp nghiệp

vụ)

Pha phát triển soạn thảo (lập kế hoạch) thường dùng một chu

kì lặp và bao gồm các hoạt động sau:

1 Soạn thảo đặc tả về nỗ lực từ pha trước đó

2 Lập vạch ranh giới và phạm vi giới hạn đầy đủ, các mục tiêu và

yêu cầu

3 Lập vạch ranh giới trường hợp nghiệp vụ bằng việc làm đông

cứng góc nhìn, đông cứng tiêu chuẩn thành công, và làm dịu

bớt rủi ro cao nhất Lập vạch ranh giới kế hoạch với lịch biểu

4 Phân phối các yêu cầu trong nhiều chu kì lặp bên trong pha xây

dựng

5 Hội tụ vào việc hiểu hay hình thành một khái niệm về vấn đề

để xác định các yêu cầu mà vấn đề áp đặt lên giải pháp cho nó

(nắm bắt các yêu cầu và phân tích yêu cầu), thiết lập và kiểm

chứng nền tảng cho giải pháp toàn thể (thiết kế kiến trúc), vàphân phối các yêu cầu trong các chu kì lặp của pha phát triểnxây dựng (lập kế hoạch)

Pha phát triển xây dựng (thực hiện) thường dùng nhiều chu kìlặp và bao gồm các hoạt động sau:

1 Cập nhật các trường hợp nghiệp vụ bằng việc quản lí cácrủi ro đang xảy ra và duy trì kế hoạch và lịch biểu

2 Xây dựng và phát triển các sản phẩm bằng việc thực hiệnnhiều chu kì lặp

Pha này tập trung vào những điều sau:

 hiểu hay làm tiến hoá các yêu cầu mà vấn đề áp đặt lên giảipháp của nó (các yêu cầu) sao cho vấn đề có thể được soạnthảo và giải pháp có thể được xác định,

 soạn thảo đặc tả giải pháp (phân tích),

 cập nhật nền tảng cho giải pháp toàn thể (thiết kế kiến trúc)

và nền tảng cần để hỗ trợ cho giải pháp đặc biệt (thiết kếchi tiết) đối với các yêu cầu chu kì lặp,

 sinh ra giải pháp (cài đặt) cho các yêu cầu chu kì lặp,

 kiểm chứng giải pháp (làm hợp lệ và tích hợp) theo cácyêu cầu chu kì lặp, và

 đưa ra hay tích hợp (hay chuyển giao) giải pháp (triểnkhai) hay tập con của cái đó

Pha phát triển chuyển giao (đóng) thường dùng một chu kì lặp vàbao gồm các hoạt động sau:

1 Triển khai sản phẩm cuối cùng của nỗ lực hay giải phápcho vấn đề

2 Định giá và phân loại các sản phẩm chuyển tiếp của nỗ

lực

3 Tập trung vào việc cung cấp và tích hợp hay chuyển giao

giải pháp (triển khai)

1.5.5 Chu kì và pha lặp

Chu kì và pha lặp (hình 1.5) có các đặc trưng sau:

Hình 1.5 : Tập trung vào pha lặp bên trong chu kì lặp

 Mỗi chu kì lặp đều bao gồm hai cấu phần hỗ trợ (quản lí và hỗtrợ) và sáu cấu phần phát triển (yêu cầu, phân tích, thiết kế,thực hiện, làm hợp lệ và triển khai) Nó làm phát sinh ra việcphát hành sản phầm Cách nhìn vòng đời này thường được gọi

là viễn cảnh phát triển vì nó đưa ra những chỉ báo mức thấp về

và phân phối các yêu cầu trong các chu kì lặp của phaphát triển xây dựng (lập kế hoạch)

- Pha thiết kế (thiết kế kiến trúc) bao gồm việc thiết lập

và kiểm chứng nền tảng cho giải pháp toàn thể

 Bên trong pha phát triển xây dựng (thực hiện) các pha lặp sauđây được áp dụng:

- Pha yêu cầu bao gồm việc hiểu hay soạn thảo các yêucầu mà vấn đề áp đặt lên giải pháp của nó sao cho vấn

đề có thể được soạn thảo và giải pháp có thể được xácđịnh

- Pha phân tích bao gồm việc soạn thảo đặc tả giải pháp.Pha này xoay quanh việc áp dụng tri thức

Thực hiện

Quan

niệm

Giải quyết Vấn đề

Thế hệ sản phẩm Chu kì phát triển

Phân tích

Yêu

cầu

Thiết kế

Thực hiện

Kiểm chứng

Triển khai

Cấu phần phát triển

Cấu phần hỗ trợ

Quản lí

Hỗ trợ

- Pha thiết kế bao gồm việc cập nhật nền tảng cho giải

pháp tổng thể (thiết kế kiến trúc) và nền tảng cần để hỗ

trợ cho giải pháp đặc thù (thiết kế chi tiết) cho các yêu

cầu chu kì lặp Pha này xoay quanh việc áp dụng tri

thức

- Pha thực hiện bao gồm việc sinh ra giải pháp cho các

yêu cầu chu kì lặp

- Pha làm hợp lệ (và tích hợp) bao gồm việc kiểm chứng

giải pháp đối với các yêu cầu chu kì lặp

- Pha triển khai bao gồm việc cung cấp và tích hợp hay

chuyển giao giải pháp hay tập con của nó

Phần 2

Các mô hình qui trình

phát triển phần mềm

2.1 Mô hình tiến trình phần mềm

Để giải quyết các vấn đề thực tế trong khung cảnh công

nghiệp, người kĩ sư phần mềm hay một tổ các kĩ sư phải hợp nhất

vào một chiến lược phát triển bao quát cả các tầng tiến trình,

phương pháp và công cụ cùng các pha thực hiện tổng quát Chiến

lược này thường được nói tới là mô hình tiến trình hay mô thức kĩ

nghệ phần mềm Mô hình tiến trình cho kĩ nghệ phần mềm được

chọn lựa dựa trên bản chất của dự án và ứng dụng, phương pháp và

công cụ được dùng, và việc kiểm soát và việc chuyển giao được

yêu cầu

Mọi việc phát triển phần mềm đều có thể được đặc trưng như

chu trình giải quyết vấn đề (hình 2.1a) trong đó bốn giai đoạn phân

biệt được gặp phải: hiện trạng, định nghĩa vấn đề, phát triển kĩthuật, và tích hợp giải pháp Hiện trạng "biểu diễn cho trạng tháihiện thời của sự việc"; định nghĩa vấn đề nhận diện vấn đề đặc biệtcần giải quyết; phát triển kĩ thuật giải quyết vấn đề qua việc ápdụng công nghệ nào đó, còn tích hợp giải pháp thì chuyển giao kếtquả (như tài liệu, chương trình, dữ liệu, chức năng nghiệp vụ mới,sản phẩm mới) cho những người yêu cầu giải pháp Các pha kĩnghệ phần mềm tổng quát và các bước dễ dàng được ánh xạ vàocác giai đoạn này

Hiện trạng

Định nghĩa vấn đề

Định nghĩa vấn đề

Tích hợp giải pháp

Tích hợp giải pháp

b a

Hình 2.1 (a) Các pha của chu trình giải quyết vấn đề

và (b) Các pha bên trong chu trình giải quyết vấn đề

Chu trình giải quyết vấn đề này áp dụng cho công việc kĩ nghệ

phần mềm tại nhiều mức độ giải pháp khác nhau Nó có thể được

dùng tại mức vĩ mô khi toàn bộ ứng dụng được xem xét, tại mức

trung khi cấu phần chương trình được đưa vào bố trí, và thậm chí

tới mức lập trình Do đó cách biểu diễn lồng nhau có thể được

dùng để cung cấp một góc nhìn lí tưởng hoá về tiến trình Trong

Hình 2.1b, mỗi giai đoạn trong chu trình giải quyết vấn đề lại chứa

một chu trình giải quyết vấn đề giống thế, rồi bên trong nó lại chứa

chu trình giải quyết vấn đề khác (điều này tiếp tục tới một biên giới

hợp lí nào đó; với phần mềm thì tới dòng mã lệnh)

Trong thực tế, khó mà đóng gói được thật rõ rệt như Hình 2.1b

bởi vì có những việc đan chéo bên trong và xuyên ngang các giai

đoạn Vậy góc nhìn đơn giản hoá này dẫn tới một ý tưởng rất quan

trọng: bất kể tới mô hình tiến trình nào được chọn cho dự án phần

mềm, tất cả các giai đoạn - hiện trạng, định nghĩa vấn đề, phát triển

kĩ thuật và tích hợp giải pháp - đều cùng tồn tại đồng thời ở mức

độ chi tiết nào đó Với bản chất đệ qui của Hình 2.1b bốn giai đoạn

được thảo luận ở trên được áp dụng như nhau cho việc phân tích

ứng dụng đầy đủ và cho việc sinh ra các đoạn mã nhỏ

Trong mục sau đây nhiều mô hình tiến trình khác nhau về kĩ

nghệ phần mềm sẽ được thảo luận Mỗi mô hình biểu diễn cho một

nỗ lực để đem trật tự vào một hoạt động mang tính hỗn loạn có

sẵn

2.1.1 Mô hình tuần tự tuyến tính

Đôi khi còn được gọi là vòng đời cổ điển hay mô hình thác đổ,

mô hình tuần tự tuyến tính gợi ý một cách tiếp cận tuần tự, có hệ

thống tới việc phát triển phần mềm bắt đầu từ mức hệ thống và tiến

dần qua phân tích, thiết kế, mã hoá, kiểm thử và hỗ trợ Hình 2.2

minh hoạ cho mô hình tuần tự tuyến tính cho kĩ nghệ phần mềm.Được mô hình hoá theo chu kì kĩ nghệ qui ước, mô hình tuần tựtuyến tính bao gồm các hoạt động sau:

Kĩ nghệ và mô hình hoá hệ thống/thông tin Bởi vì phần mềm

bao giờ cũng là một phần của một hệ thống (hay nghiệp vụ) lớnhơn nên công việc bắt đầu từ việc thiết lập yêu cầu cho mọi phần

tử hệ thống và rồi phân bổ một tập con các yêu cầu đó cho phầnmềm Quan điểm hệ thống này là điều bản chất khi phần mềm phảitương tác với các cấu phần khác như phần cứng, con người vàCSDL Kĩ nghệ và phân tích hệ thống bao gồm việc thu thập yêucầu ở mức hệ thống với một lượng nhỏ thiết kế và phân tích mứcđỉnh Kĩ nghệ thông tin bao gồm việc thu thập yêu cầu tại mứcnghiệp vụ chiến lược và tại mức lĩnh vực nghiệp vụ

Hình 2.2 Mô hình tuần tự tuyến tính

Phân tích yêu cầu phần mềm Tiến trình thu thập yêu cầu được

tăng cường và hội tụ đặc biệt vào phần mềm Để hiểu được bảnchất của các chương trình phải xây dựng, kĩ sư phần mềm ("nhàphân tích") phải hiểu về lĩnh vực thông tin đối với phần mềm cũngnhư chức năng cần có, hành vi, hiệu năng và giao diện Các yêu

Lập trình

Lập trình Kiểm thử

Kiểm thử

Kĩ nghệ hệ thống/ thông tin

Phấn tích

cầu cho cả hệ thống và phần mềm cần phải được lập tư liệu và

kiểm điểm cùng với khách hàng

Thiết kế Thiết kế phần mềm thực tế là một tiến trình nhiều

bước tập trung vào bốn thuộc tính phân biệt của chương trình: cấu

trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ

tục (thuật toán) Tiến trình thiết kế dịch các yêu cầu thành một biểu

diễn của phần mềm có thể được định giá về chất lượng trước khi

giai đoạn mã hoá bắt đầu Giống như các yêu cầu, việc thiết kế

phải được lập tư liệu và trở thành một phần của cấu hình phần

mềm

Sinh mã Thiết kế phải được dịch thành dạng máy đọc được.

Bước mã hoá thực hiện nhiệm vụ này Nếu thiết kế được thực hiện

theo một cách chi tiết thì việc sinh mã có thể được thực hiện một

cách máy móc

Kiểm thử Một khi mã đã được sinh ra thì việc kiểm thử

chương trình bắt đầu Tiến trình kiểm thử hội tụ vào nội bộ logic

của phần mềm, đảm bảo rằng tất cả các câu lệnh đều được kiểm

thử, và vào bên ngoài chức năng; tức là tiến hành các kiểm thử để

làm lộ ra các lỗi và đảm bảo những cái vào đã định sẽ tạo ra kết

quả thống nhất với kết quả muốn có

Hỗ trợ Phần mềm chắc chắn sẽ phải trải qua những thay đổi

sau khi nó được bàn giao cho khách hàng (một ngoại lệ có thể là

những phần mềm nhúng) Thay đổi sẽ xuất hiện bởi vì gặp phải lỗi,

bởi vì phần mềm phải thích ứng với những thay đổi trong môi

trường bên ngoài (chẳng hạn như sự thay đổi do hệ điều hành mới

hay thiết bị ngoại vi mới), hay bởi vì khách hàng yêu cầu nâng cao

chức năng hay hiệu năng Việc bảo trì phần mềm phải áp dụng lại

các bước vòng đời nói trên cho chương trình hiện tại chứ không

phải chương trình mới

Mô hình tuần tự tuyến tính là mô thức cũ nhất và được sửdụng rộng rãi nhất cho kĩ nghệ phần mềm Tuy nhiên, những chỉtrích về mô thức này đã làm cho những người ủng hộ nó tích cựcphải đặt vấn đề về tính hiệu quả của nó Một số các vấn đề thỉnhthoảng gặp phải khi dùng mô hình tuần tự tuyến tính này là:

Các dự án thực hiếm khi tuân theo dòng chảy tuần tự mà môhình đề nghị Mặc dầu mô hình tuyến tính có thể cho phép lặp,nhưng điều đó chỉ làm gián tiếp Kết quả là những thay đổi có thểgây ra lẫn lộn khi tổ dự án tiến hành

Khách hàng thường khó phát biểu mọi yêu cầu một cách tườngminh Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khóthích hợp với sự không chắc chắn tự nhiên tồn tại vào lúc đầu củanhiều dự án

Khách hàng phải kiên nhẫn Bản làm việc được của chươngtrình chỉ có được vào lúc cuối của thời gian dự án Một sai lầm ngớngẩn, nếu đến khi có chương trình làm việc mới phát hiện ra, cóthể sẽ là một thảm hoạ

Trong một phân tích thú vị về các dự án hiện tại, Bradax thấyrằng bản chất tuyến tính của vòng đời cổ điển dẫn tới "các trạngthái nghẽn" mà trong đó một số thành viên tổ dự án phải đợi chocác thành viên khác của tổ hoàn thành các nhiệm vụ phụ thuộc.Trong thực tế, thời gian mất cho việc chờ đợi có thể vượt quá thờigian dành cho công việc sản xuất! Trạng thái nghẽn có khuynhhướng phổ biến vào lúc đầu và cuối của tiến trình tuần tự tuyếntính

Từng vấn đề trên đều là thực Tuy nhiên, mô thức vòng đời cổđiển có một vị trí quan trọng và xác định trong công việc về kĩnghệ phần mềm Nó đưa ra một tiêu bản trong đó có thể bố trí cácphương pháp cho phân tích, thiết kế, mã hoá, kiểm thử và bảo trì.Bên cạnh đó, Vòng đời cổ điển vẫn còn là một mô hình thủ tục

được dùng rộng rãi cho kĩ nghệ phần mềm Trong khi nó quả thực

còn điểm yếu, nó vẫn tốt hơn đáng kể nếu so với cách tiếp cận

ngẫu nhiên tới việc phát triển phần mềm

2.1.2 Mô hình làm bản mẫu

Thông thường khách hàng đã xác định một tập các mục tiêu

tổng quát cho phần mềm, nhưng còn chưa nhận diện được các yêu

cầu cái vào chi tiết, xử lí hay cái ra Trong các trường hợp khác,

người phát triển có thể không chắc về tính hiệu quả của thuật toán,

việc thích nghi hệ điều hành hay dạng giao diện người máy cần có

Trong những trường hợp này và nhiều trường hợp khác mô thức

làm bản mẫu có thể đưa ra cách tiếp cận tốt nhất.

Mô thức làm bản mẫu (hình 2.3) bắt đầu với việc thu thập yêu

cầu Người phát triển và khách hàng gặp nhau và xác định các mục

tiêu tổng thể cho phần mềm, xác định các yêu cầu nào đã biết, và

miền nào bắt buộc phải xác định thêm Rồi đến việc "thiết kế

nhanh." Thiết kế nhanh tập trung vào việc biểu diễn các khía cạnh

của phần mềm thấy được đối với người dùng (như cách đưa vào và

định dạng đưa ra) Thiết kế nhanh dẫn tới việc xây dựng một bản

mẫu Bản mẫu được khách hàng / người dùng đánh giá và được

dùng để làm mịn các yêu cầu đối với phần mềm cần phát triển

Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu được "vi chỉnh" thoả

mãn nhu cầu của khách hàng trong khi đồng thời lại làm cho người

phát triển hiểu được kĩ hơn cần phải thực hiện nhu cầu nào

Hình 2.3 Mô thức làm bản mẫuMột cách lí tưởng, bản mẫu phục vụ như một cơ chế để xácđịnh các yêu cầu phần mềm Nếu một bản mẫu làm việc được xâydựng thì người phát triển có thể dùng được các đoạn chương trình

đã có hay áp dụng các công cụ (như bộ sinh báo cáo, bộ quản lícửa sổ, v.v ) để nhanh chóng sinh ra chương trình làm việc

Nhưng chúng ta nghĩ về bản mẫu thế nào khi nó được dùngcho mục đích được nêu trên? Brook đã nêu ra câu trả lời:

Trong hầu hết các dự án, hệ thống đầu tiên hiếm khi sử dụng được Nó có thể là quá chậm, quá lớn, cồng kềnh trong sử dụng hay tất cả những nhược diểm này Không có cách nào khác là bắt đầu lại, đau đớn nhưng tinh khôn hơn, và xây dựng một phiên bản được thiết

kế lại trong đó những vấn đề này đã được giải quyết Khi một khái niệm hệ thống mới hay một kĩ nghệ mới được dùng, người ta phải xây dựng một hệ thống để rồi vứt đi, cho dù việc lập kế hoạch được thực hiện chu đáo nhất thì nó cũng không thể bao quát hết để chạy đúng được ngay lần đầu Do đó câu hỏi quản lí không phải là liệu chúng ta có nên xây dựng một hệ thống thử nghiệm và rồi vứt nó đi hay không Bạn sẽ làm như vậy Câu hỏi duy nhất là liệu nên lập kế hoạch trước để xây dựng một cái vứt đi hay để hứa hẹn bàn giao cái vứt đi đó cho khách hàng

Bản mẫu có thể phục vụ như "hệ đầu tiên" - cái mà Brook lưu

ý chúng ta nên vứt đi Nhưng điều này có thể là một cách nhìn lítưởng hoá Giống như mô hình tuyến tính tuần tự, việc làm bảnmẫu tựa như một mô thức cho kĩ nghệ phần mềm có thể trở thành

Khách hàng Khách hàng chạy thử

xô đẩy để cho nó làm việc thì chẳng ai xem xét tới chất lượng

phần mềm tổng thể hay tính bảo trì thời gian dài Khi được

thông báo rằng sản phẩm phải được xây dựng lại để cho có thể

đạt tới mức độ chất lượng cao, thì khách hàng kêu trời và đòi

hỏi rằng "phải ít sửa chữa" để làm bản mẫu thành sản phẩm

làm việc Thường như vậy việc quản lí phát triển phần mềm bị

buông lỏng

Người phát triển thường hay thoả hiệp cài đặt để có được bản

mẫu làm việc nhanh chóng Hệ điều hành hay ngôn ngữ lập

trình không thích hợp có thể được dùng đơn giản bởi vì nó có

sẵn và đã biết; một thuật toán không hiệu quả có thể được cài

đặt đơn giản để chứng tỏ khả năng Sau một thời gian, người

phát triển mới có thể trở nên quen thuộc với những chọn lựa

này và quên mất mọi lí do tại sao chúng lại không thích hợp

Việc chọn lựa không được theo lí tưởng bây giờ lại trở thành

một phần tích hợp của hệ thống

Mặc dầu vấn đề có thể xuất hiện, việc làm bản mẫu có thể là

một mô thức hiệu quả cho kĩ nghệ phần mềm Chìa khoá là định

nghĩa ra các qui tắc của trò chơi từ ngay lúc bắt đầu; tức là khách

hàng và người phát triển phải cùng đồng ý rằng bản mẫu được xây

dựng để phục vụ làm cơ chế xác định yêu cầu Thế rồi nó phải bị

bỏ đi (ít nhất cũng một phần) và phần mềm thực tại được đưa vào

kĩ nghệ với con mắt hướng về chất lượng và tính bảo trì được

2.1.3 Mô hình RAD

Phát triển ứng dụng nhanh (RAD) là mô hình tiến trình phát

triển phần mềm tăng dần nhấn mạnh vào chu kì phát triển cực kì

ngắn Mô hình RAD là thích ứng "tốc độ cao" của mô hình tuần tự

tuyến tính trong đó việc phát triển nhanh được đạt tới bằng việc

dùng kết cấu dựa theo cấu phần Nếu các yêu cầu đã được hiểu rõ

và phạm vi dự án được ràng buộc, thì tiến trình RAD tạo khả năngcho tổ phát triển tạo ra "hệ thống vận hành đầy đủ" trong một thờigian rất ngắn (60 đến 90 ngày) Được dùng chủ yếu cho ứng dụng

hệ thông tin, cách tiếp cận RAD bao gồm các pha sau:

Mô hình hoá nghiệp vụ Luồng thông tin giữa các chức năng

nghiệp vụ được mô hình hoá theo cách trả lời cho các câu hỏi sau:Thông tin nào hướng dẫn tiến trình nghiệp vụ? Thông tin nào đượcsinh ra? Ai sinh ra nó? Thông tin đó đi đâu? Ai xử lí nó? Mô hìnhnghiệp vụ được mô tả trong chương 10

Tổ #2

Mô hình hoá nghiệp vụ

Mô hình hoá nghiệp vụ

Mô hình dữ liệu

Mô hình dữ liệu

Sinh ứng dụng

Kiểm thử

và quay vòng

Kiểm thử

và quay vòng

Tổ #1

Mô hình hoá nghiệp vụ

Mô hình hoá nghiệp vụ

Sinh ứng dụng

Kiểm thử

và quay vòng

Kiểm thử

và quay vòng

Tổ #3

Mô hình hoá nghiệp vụ

Mô hình hoá nghiệp vụ

Sinh ứng dụng

Kiểm thử

và quay vòng

Kiểm thử

và quay vòng

60-90 ngày

Hình 2.4 Mô hình RAD

Mô hình hoá dữ liệu Luồng thông tin được định nghĩa như

một phần của pha mô hình hoá nghiệp vụ được làm mịn thành một

tập các sự vật dữ liệu được cần để hỗ trợ cho nghiệp vụ Các đặc

trưng (còn được gọi là thuộc tính) của từng sự vật đượcnhận diện

và mối quan hệ giữa các sự vật này được xác định

Mô hình hoá xử lí Các sự vật dữ liệu được định nghĩa trong

pha mô hình hoá dữ liệu được biến đổi để đạt tới luồng thông tin

cần cho việc thực hiện chức năng nghiệp vụ Các mô tả xử lí được

tạo ra để bổ sung, sửa đổi, xoá bỏ hay tìm kiếm sự vật dữ liệu

Sinh ứng dụng RAD giả thiết dùng các kĩ thuật thế hệ bốn.

Thay vì tạo ra phần mềm bằng việc dùng các ngôn ngữ lập trình

thế hệ ba qui ước thì tiến trình RAD làm việc để dùng lại các cấu

phần chương trình hiện có (khi có thể) hay tạo ra các cấu phần

dùng lại được Trong mọi trường hợp, công cụ tự động hoá đều

được dùng để tạo điều kiện thuận tiện cho việc xây dựng phần

mềm

Kiểm thử và quay vòng Vì tiến trình RAD nhấn mạnh tới

việc dùng lại, cho nên nhiều cấu phần chương trình đã được kiểm

thử Điều này làm giảm thời gian kiểm thử toàn bộ Tuy nhiên, các

cấu phần mới phải được kiểm thử và mọi giao diện phải được thực

tập đầy đủ

Mô hình RAD được minh hoạ trong hình 2.4 Hiển nhiên ràng

buộc thời gian bị áp đặt lên dự án RAD đòi hỏi "phạm vi đổi qui

- RAD đòi hỏi người phát triển và khách hàng phải cam kết tham

dự các hoạt động thực hiện nhanh cần thiết để làm cho hệthống đầy đủ trong khuôn khổ thời gian vắn tắt hơn nhiều Nếucam kết không đủ thì dự án có thể bị thất bại

- Không phải tất cả các kiểu ứng dụng đều thích hợp cho RAD.Nếu hệ thống không thể được mô đun hoá thì việc xây dựngcác cấu phần cần cho RAD sẽ thành vấn đề Nếu hiệu năng cao

là vấn đề và hiệu năng được đạt tới thông qua việc điều chỉnhgiao diện cho các cấu phần hệ thống, thì cách tiếp cận RAD cóthể không có tác dụng

- RAD không thích hợp khi rủi ro kĩ thuật là cao Điều này xuấthiện khi một ứng dụng mới dùng nhiều công nghệ mới hay khiphần mềm mới đòi hỏi mức độ liên tác cao với chương trìnhmáy tính hiện có

2.1.4 Mô hình tiến trình phần mềm tiến hoá

Có sự thừa nhận ngày càng tăng rằng phần mềm, giống nhưmọi hệ thống phức tạp khác, tiến hoá theo từng thời kì thời gian.Các yêu cầu nghiệp vụ và sản phẩm thường thay đổi khi sự pháttriển tiến hoá, nên việc vạch đường thẳng tới sản phẩm cuối cùng

là không hiện thực; hạn chế chặt chẽ của thị trường làm cho việchoàn chỉnh sản phẩm phần mềm thấu đáo thành không thể được,nhưng một phiên bản có giới hạn vẫn phải được đưa ra để đáp ứngvới sức ép cạnh tranh hay nghiệp vụ; một tập các yêu cầu sản phẩmhay hệ thống cốt lõi đã được hiểu rõ, nhưng chi tiết về việc mởrộng sản phẩm hay hệ thống vẫn còn chưa được xác định Trongnhững tình huống này và tương tự, người kĩ sư phần mềm cần một

mô hình tiến trình đã được thiết kế tường minh để phù hợp với sản

phẩm tiến hoá theo thời gian

Mô hình tuần tự tuyến tính (Mục 2.1.1) được thiết kế cho việc

phát triển theo đường thẳng Về bản chất, cách tiếp cận thác nước

này giả thiết rằng một hệ thống phức tạp sẽ được chuyển giao sau

khi một trình tự tuyến tính đã được hoàn tất Mô hình làm bản mẫu

(Mục 2.1.2) được thiết kế để trợ giúp cho khách hàng (hay người

phát triển) trong việc hiểu các yêu cầu Nói chung, nó không được

thiết kế để chuyển giao hệ thống sản xuất Bản chất tiến hoá của

phần mềm không được xét tới trong cả hai mô thức kĩ nghệ phần

mềm cổ điển này

Các mô hình tiến hoá là mang tính lặp Chúng được đặc trưng

theo cách thức tạo khả năng cho người kĩ sư phần mềm phát triển

các phiên bản ngày một phức tạp hơn cho phần mềm

2.1.5 Mô hình tăng dần

Hình 2.5 Mô hình tăng dần

Mô hình tăng dần tổ hợp các yếu tố của mô hình tuần tự tuyếntính (được áp dụng lặp lại) với triết lí lặp về làm bản mẫu Thamkhảo Hình 2.5, mô hình tăng dần áp dụng các trình tự tuyến tínhtheo kiểu so le khi thời gian lịch tiếp diễn Mỗi trình tự tuyến tínhlại tạo ra một "việc tăng" chuyển giao được của phần mềm Chẳnghạn, phần mềm xử lí văn bản được phát triển bằng việc dùng môthức tăng dần có thể chuyển giao việc quản lí tệp cơ sở, việc soạnthảo, và các chức năng sản xuất văn bản trong lần tăng đầu; việcsoạn thảo và những khả năng tạo văn bản phức tạp hơn trong lầntăng thứ hai; kiểm tra chính tả và văn phạm ở lần tăng thứ ba; vàkhả năng bố trí trang phức tạp ở lần tăng thứ tư Cũng cần chú ýrằng luồng tiến trình này cho bất kì lần tăng nào có thể tổ hợp môthức làm bản mẫu

Khi mô hình tăng dần được sử dụng, thì lần tăng đầu thường là

sản phẩm lõi Tức là, các yêu cầu cơ bản được đề cập tới, nhưng

nhiều tính năng phụ (một số đã biết, số khác chưa biết) vẫn cònchưa được chuyển giao Sản phẩm lõi được khách hàng dùng (haytrải qua xem xét chi tiết) Xem như kết quả của việc dùng hay đánhgiá, một bản kế hoạch được phát triển cho lần tăng tiếp Bản kếhoạch này đề cập tới việc sửa đổi sản phẩm lõi để đáp ứng tốt hơncho nhu cầu khách hàng và chuyển giao các tính năng và chứcnăng phụ Tiến trình này được lặp lại tiếp sau việc chuyển giaotừng lần tăng, cho tới khi sản phẩm hoàn chỉnh được tạo ra

Mô hình tiến trình tăng dần, giống như làm bản mẫu và cáccách tiếp cận tiến hoá khác, về bản chất mang tính lặp Nhưngkhông giống làm bản mẫu, mô hình tăng dần hội tụ vào việcchuyển giao sản phẩm vận hành với từng việc tăng lên Những việctăng ban đầu được trượt dần xuống phiên bản của sản phẩm cuối

Mã hoá Kiểm thử Phân tích Thiết kế

Mã hoá Kiểm thử Phân tích Thiết kế

Chuyển giao tăng 2

Chuyển giao tăng 3

Chuyển giao tăng 4

Thời gian lịch

cùng, nhưng chúng quả có cung cấp khả năng phục vụ cho người

dùng và cũng cung cấp một nền tảng cho người dùng đánh giá

Phát triển tăng dần đặc biệt hữu dụng khi nhân viên không có

sẵn để thực hiện đầy đủ theo hạn chót nghiệp vụ đã được thiết lập

cho dự án Những việc tăng ban đầu có thể được thực hiện với ít

người hơn Nếu sản phẩm lõi được đón nhận tốt, thì nhân viên phụ

(nếu cần) có thể được bổ sung để thực hiện việc tăng tiếp Bên

cạnh đó, việc tăng có thể được lập kế hoạch để quản lí các rủi ro kĩ

thuật Chẳng hạn, hệ thống chính có thể đòi hỏi việc sẵn có của

phần cứng mới còn đang được phát triển và ngày chuyển giao còn

chưa chắc chắn Có thể lập kế hoạch tăng sớm theo cách tránh việc

dùng phần cứng này, do đó tạo khả năng chức năng bộ phận được

chuyển giao cho người dùng cuối mà không bị chậm trễ bất

thường

2.1.6 Mô hình xoáy ốc

Mô hình xoáy ốc, ban đầu do Boehm đề xuất, là mô hình tiến

trình phần mềm tiến hoá cặp đôi bản chất lặp của làm bản mẫu với

các khía cạnh hệ thống và có kiểm soát của mô hình trình tự tuyến

tính Nó cung cấp tiềm năng cho việc phát triển nhanh các phiên

bản tăng dần của phần mềm Dùng mô hình xoáy ốc này, phần

mềm được phát triển thành từng chuỗi các lần đưa ra tăng dần

Trong những lần lặp đầu, việc đưa ra tăng dần có thể là mô hình

trên giấy hay bản mẫu Trong các lần lặp sau, các phiên bản đầy đủ

tăng dần của hệ thống được kĩ nghệ hoá sẽ được tạo ra

Mô hình xoáy ốc được chia thành một số khuôn khổ hoạt

động, cũng còn được gọi là vùng nhiệm vụ Về cơ bản, có từ ba tới

sáu vùng Hình 2.6 mô tả cho mô hình xoáy ốc có chứa sáu vùng:

Trao đổi với khách hàng - nhiệm vụ đòi hỏi thiết lập việc

trao đổi có hiệu quả giữa người phát triển và khách hàng

Lập kế hoạch - nhiệm vụ đòi hỏi định nghĩa các tài nguyên,

hạn thời gian và các thông tin liên quan tới dự án

Phân tích rủi ro - nhiệm vụ đòi hỏi định giá cả những rủi ro

kĩ thuật và quản lí

Chế tạo - nhiệm vụ đòi hỏi xây dựng một hay nhiều biểu diễn

cho ứng dụng

Xây dựng và đưa ra - nhiêm vụ đòi hỏi xây dựng, kiểm thử,

thiết đặt và cung cấp sự hỗ trợ cho người dùng (như tài liệu vàhuấn luyện)

Đánh giá của khánh hàng - nhiệm vụ đòi hỏi thu được phản

hồi của khách hàng dựa trên đánh giá về biểu diễn phần mềm đượctạo ra trong giai đoạn chế tạo và được cài đặt trong giai đoạn càiđặt

Trao đổi với khách hàng

Trục điểm vào dự án

Đánh giá của khách hàng

Hình 2.6 Mô hình xoáy ốcMỗi một trong các vùng đều được đặt vào một tập các nhiệm

vụ, được gọi là tập nhiệm vụ, được thích ứng với các đặc trưng của

dự án được tiến hành Với các dự án nhỏ, số các nhiệm vụ công

việc và tính hình thức của chúng là thấp Với các dự án lớn, nhiều

căng thẳng hơn, thì mỗi vùng nhiệm vụ lại chứa nhiều nhiệm vụ

công việc được xác định để đạt tới mức độ hình thức cao hơn

Trong mọi trường hợp, hoạt động yểm trợ (như quản lí cấu hình

phần mềm và đảm bảo chất lượng phần mềm) sẽ được áp dụng

Khi tiến trình tiến hoá này bắt đầu, tổ kĩ nghệ phần mềm đi

vòng xoáy ốc theo chiều ngược kim đồng hồ, bắt đầu từ trung tâm

Mạch đầu tiên quanh xoáy ốc có thể làm phát sinh việc phát triển

đặc tả sản phẩm; các bước tiếp theo quanh xoáy ốc có thể được

dùng để phát triển bản mẫu và thế rồi các phiên bản phức tạp dần

thêm Mỗi bước qua vùng lập kế hoạch lại làm nảy sinh việc điều

chỉnh kế hoạch dự án Chi phí và lịch biểu được điều chỉnh dựa

trên phản hồi được suy từ đánh giá của khách hàng Bên cạnh đó,

người quản lí dự án điều chỉnh số việc lặp đã lập kế hoạch cần để

hoàn chỉnh phần mềm

Không giống như mô hình tiến trình cổ điển kết thúc khi phần

mềm được chuyển giao, mô hình xoáy ốc có thể được thích ứng để

áp dụng trong toàn bộ cuộc đời của phần mềm máy tính Một góc

nhìn khác có thể được xem xét bằng việc kiểm tra trục điểm vào

dự án, như được vẽ trong Hình 2.6 Mỗi hình hộp được đặt theo

trục có thể được dùng để biểu diễn cho điểm bắt đầu cho các kiểu

dự án khác nhau 'Dự án phát triển khái niệm" bắt đầu tại cốt lõi

của xoáy ốc và sẽ tiếp tục (nhiều lần lặp xuất hiện theo con đường

xoáy ốc mà gắn với vùng tô đậm trung tâm) cho tới khi việc phát

triển khái niệm là đầy đủ Nếu khái niệm này được phát triển thành

một sản phẩm thực tại, thì tiến trình tiến qua hình hộp tiếp (điểm

vào dự án phát triển sản phẩm mới) và một "dự án phát triển mới"

được khởi đầu Sản phẩm mới sẽ tiến hoá qua một số lần lặp quanhxoáy ốc, đi theo con đường gắn vùng có tô mầu sáng hơn vùng lõi

Về bản chất, xoáy ốc, khi được đặc trưng theo cách này, vẫn cònlàm việc cho tới khi phần mềm được cho nghỉ Có những lúc tiếntrình này ngủ, nhưng bất kì khi nào một thay đổi được khởi đầu, thìtiến trình này lại bắt đầu tại điểm vào thích hợp (tức là nâng caosản phẩm)

Mô hình xoáy ốc là cách tiếp cận thực tế cho việc phát triểncho các hệ thống và phần mềm qui mô lớn Bởi vì phần mềm tiếnhoá khi tiến trình tiến hoá, nên người phát triển và khách hàng hiểu

rõ hơn và phản ứng với rủi ro tại từng mức tiến hoá Mô hình xoáy

ốc dùng cách làm bản mẫu như một cơ chế làm giảm bớt rủi ro,nhưng điều quan trọng hơn, làm cho người phát triển có khả năng

áp dụng được cách tiếp cận làm bản mẫu tại mọi giai đoạn trongtiến hoá của sản phẩm Nó duy trì cách tiếp cận từng bước mộtcách có hệ thống do cách tiếp cận vòng đời cổ điển gợi ý, nhưng tổhợp cách tiếp cận này vào một khuôn khổ lặp lại, phản ánh đượcsát thực hơn thế giới thực Mô hình xoáy ốc đòi hỏi việc xem xéttrực tiếp các rủi ro kĩ thuật tại mọi giai đoạn của dự án, và nếuđược áp dụng đúng thì nó có thể làm giảm rủi ro trước khi chúngtrở thành vấn đề thực sự

Nhưng giống như các mô thức khác, mô hình xoáy ốc khôngphải là một liều thuốc bách bệnh Có thể khó thuyết phục nhữngkhách hàng (đặc biệt trong tình huống có hợp đồng) rằng cách tiếpcận tiến hoá là kiểm soát được Nó đòi hỏi tri thức chuyên gia đánhgiá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạtđược thành công Nếu một rủi ro chính không được phát hiện vàquản lí thì không nghi ngờ gì nữa vấn đề sẽ xuất hiện Cuối cùng,chính bản thân mô hình này cũng còn chưa được sử dụng rộng rãinhư mô thức trình tự tuyến tính hoặc làm bản mẫu Cần phải có

thêm một số năm nữa trước khi tính hiệu quả của mô thức quan

trọng này có thể được xác định với sự chắc chắn hoàn toàn

2.1.7 Mô hình phát triển tương tranh

Mô hình phát triển tương tranh, đôi khi còn được gọi là kĩ

nghệ tương tranh, đã được Davis và Sitaram mô tả theo cách sau

đây:

Người quản lí dự án, người theo dõi dấu vết tiến độ dự án dưới dạng

các pha chính [của vòng đời cổ điển] chẳng có ý tưởng gì về trạng thái của

dự án của mình Đây là những thí dụ về việc cố gắng theo dõi các tập hoạt

động cực kì phức tạp bằng việc dùng các mô hình quá đơn giản Lưu ý rằng

mặc dầu một dự án [lớn] đang trong pha mã hoá, có những nhân viên dự

án tham gia vào các hoạt động có liên kết điển hình với nhiều pha phát

triển đồng thời Chẳng hạn, nhân viên đang viết yêu cầu, thiết kế, mã

hoá, kiểm thử và kiểm thử tích hợp [tất cả đều cùng một lúc] Các mô hình

tiến trình kĩ nghệ phần mềm của Humphrey và Kellner đã chỉ ra sự tương

tranh tồn tại cho các hoạt động xuất hiện trong bất kì pha nào Công trình

mới đâycủa Kellner dùng sơ đồ trạng thái [một kí pháp biểu diễn cho trạng

thái của tiến trình] để biểu diễn mối quan hệ tương tranh tồn tại giữa các

hoạt động có liên kết với một biến cố xác ddịnh (như các yêu cầu thay đổi

trong sự phát triển về sau) nhưng lại không thâu tóm được sự phong phú

của tương tranh tồn tại xuyên qua mọi hoạt động quản lí và phát triển trong

dự án Phần lớn các mô hình tiến trình phát triển phần mềm đều bị thời

gian điều khiển; nó càng muộn thì bạn càng muộn trong tiến trình phát

triển [Mô hình tiến trình tương tranh] do nhu cầu người dùng quyết định

quản lí và kết quả kiểm điểm điều khiển.

Mô hình tiến trình tương tranh có thể được biểu diễn một cách

sơ đồ như một chuỗi các hoạt động kĩ thuật chính, các nhiệm vụ và

trạng thái liên kết của chúng Chẳng hạn, hoạt động kĩ nghệ được

định nghĩa cho mô hình xoáy ốc được hoàn thành bởi việc gọi tới

các nhiệm vụ sau: làm bản mẫu và/hoặc mô hình hoá phân tích,

đặc tả yêu cầu, và thiết kế

Hình 2.7 đưa ra một cách biểu diễn sơ đồ hoá về một hoạtđộng với mô hình tiến trình tương tranh Hoạt động này - phân tích

- có thể theo bất kì một trong những trạng thái đã được ghi lại vàobất kì lúc nào Tương tự, các hoạt động khác (như thiết kế hay traođổi với người dùng) có thể được biểu diễn theo cách tương tự Tất

cả các hoạt động đều tồn tại tương tranh nhưng nằm trong cáctrạng thái khác nhau Chẳng hạn, ban đầu trong dự án hoạt động

trao đổi với khách hàng (không được vẽ trong hình) đã hoà nthành

việc lặp đầu tiên của nó và tồ ntại trong trạng thái đợi thay đổi.

Hoạt động phân tích (tồn tại trong trạng thái không khi việc trao

đổi với khách hàng ban đầu đã được hoàn tất) bây giờ tạo ra một

phép chuyển vào trong trạng thái đã phát triển Tuy nhiên nếu

khách hàng chỉ ra rằng thay đổi trong yêu cầu phải được tiến hành,

thì hoạt động phân tích sẽ chuyển từ trạng thái đã phát triển sang

trạng thái đợi thay đổi.

Không

Đã phát triển

Đã xét duyệt Đợi thay đổi

Xong

Hoạt động phân tích

H×nh 2.7 Một phần

tử của mô hình tiến trình tương tranh

Đã xét duyệt

Tuyến cơ sở

Mô hình tiến trình tương tranh định nghĩa ra một loạt các biến

cố sẽ làm lẩy cò việc chuyển từ trạng thái nọ sang trạng thái kia

của các hoạt động kĩ nghệ phần mềm Chẳng hạn trong các giai

đoạn đầu của thiết kế, sự không nhất quán trong mô hình phân tích

được làm lộ ra Điều này sinh ra biến cố sửa mô hình phân tích lẩy

cò cho hoạt động phân tích từ trạng thái đã làm sang trạng thái đợi

thay đổi.

Trong thực tế, mô hình tiến trình tương tranh áp dụng được

cho tất cả các kiểu phát triển phần mềm và cung cấp một bức tranh

chính xác về trạng thái hiện tại của dự án Thay vì giới hạn các

hoạt động kĩ nghệ phần mềm vào một trình tự các biến cố, thì nó

định nghĩa ra một mạng lưới các hoạt động Mỗi hoạt động trên

mạng đều tồn tại đồng thời với các hoạt động khác Các biến cố

được sinh ra bên trong hoạt động đã cho hay tại chỗ khác nào đó

trong mạng hoạt động làm lẩy cò việc chuyển trạng thái của hoạt

động

Mô hình tiến trình tương tranh thường được dùng làm mô thức

cho việc phát triển các ứng dụng khách/nguồn phục vụ Hệ thống

khách/nguồn phục vụ bao gồm một tập các cấu phần chức năng

Khi được áp dụng cho khách/nguồn phục vụ thì mô hình tiến trình

tương tranh định nghĩa ra các hoạt động theo hai chiều: chiều hệ

thống và chiều cấu phần Vấn đề mức hệ thống được đề cập bằng

việc dùng ba hoạt động: thiết kế, lắp ráp và sử dụng Chiều cấu

phần được đề cập với hai hoạt động: thiết kế và thực hiện Tính

tương tranh được đạt tới theo hai cách: (1) các hoạt động hệ thống

và cấu phần xuất hiện đồng thời và có thể được mô hình hoá bằngviệc dùng cách tiếp cận hướng trạng thái được mô tả trước đây; (2)ứng dụng điển hình khách/nguồn phục vụ được cài đặt với nhiềucấu phần, mỗi cấu phần có thể được thiết kế và thực hiện tươngtranh

2.2 Phát triển dựa theo cấu phần

Công nghệ hướng sự vật cung cấp một khuôn khổ kĩ thuật cho

mô hình tiến trình dựa trên cấu phần cho kĩ nghệ phần mềm Môthức hướng sự vật nhấn mạnh tới việc tạo ra lớp bao bọc cả dữ liệulẫn thuật toán được dùng để thao tác dữ liệu này Nếu được thiết kế

và cài đặt đúng, các lớp hướng sự vật đều dùng lại được ngang quanhững ứng dụng khác nhau cũng như kiến trúc hệ thống máy tínhkhác nhau

Đánh giá của khách hàng

Kĩ nghệ xây dựng và đưa ra

Trao đổi khách hàng

rủi ro

Xác định cấu phần ứng cử viên

Xây dựng lần lặp thứ n của

hệ thống

Tra tìm cấu phần trong thư viện

Xây dựng lần lặp thứ n của

hệ thống

Đặt cấu phần mới vào thư viện

Xây dựng cấu phần nếu chưa có

Hình 2.8 Phát triển dựa trên cấu phần

Mô hình phát triển dựa trên cấu phần (CBD) (Hình 2.8) tổ hợp

nhiều đặc trưng của mô hình xoáy ốc Nó mang bản chất tiến hoá,

yêu cầu cách tiếp cận lặp tới việc tạo ra phần mềm Tuy nhiên, mô

hình phát triển dựa trên cấu phần thu xếp các ứng dụng từ các cấu

phần phần mềm đóng gói sẵn (được gọi là lớp).

Hoạt động kĩ nghệ bắt đầu với việc nhận diện các lớp ứng cử

viên Điều này được thực hiện bằng việc xem xét dữ liệu cần ứng

dụng thao tác và thuật toán, điều sẽ được áp dụng để hoàn thành

thao tác Dữ liệu và thuật toán tương ứng được đóng gói trong một

lớp

Lớp được tạo ra trong các dự án kĩ nghệ phần mềm quá khứ

được cất giữ trong một thư viện lớp hay kho chứa Một khi các lớp

ứng cử viên đã được nhận diện, thì thư viện lớp sẽ được duyệt tìm

để xác định xem liệu các lớp này có tồn tại hay không Nếu chúng

có tồn tại, thì chúng được lấy ra từ thư viện và được dùng lại Nếu

lớp ứng cử viên không nằm trong thư viện thì nó được chế tạo ra

bằng việc dùng phương pháp hướng sự vật Việc lặp đầu tiên của

ứng dụng được xây dựng vậy được soạn ra, bằng việc dùng các lớp

được trích ra từ thư viện và bất kì lớp mới nào được xây dựng để

đáp ứng cho nhu cầu duy nhất của ứng dụng này Luồng tiến trình

thế rồi quay theo xoáy ốc và cuối cùng sẽ vào lại việc lặp lắp ráp

cấu phần trong các bước sau qua hoạt động kĩ nghệ

Mô hình phát triển dựa trên cấu phần dẫn tới việc dùng lại

phần mềm, và tính khả dụng cung cấp cho các kĩ sư phần mềm một

số ích lợi đo được Dựa trên nghiên cứu về tái dụng, công ti QSM

Associate, Inc báo cáo việc lắp ráp cấu phần đưa tới giảm 70 phần

trăm thời gian vòng phát triển; và giảm tới 84 phần trăm về chi phí,

và chỉ số hiệu suất là 26.2 so với chuẩn công nghiệp 16.9 Mặc dầu

những kết quả này là một hàm số theo độ vững chãi của thư việncấu phần, gần như không có vấn đề là mô hình phát triển dựa trêncấu phần cung cấp ưu thế có ý nghĩa cho các kĩ sư phần mềm

Tiến trình phát triển phần mềm thống nhất là đại biểu cho một

số mô hình phát triển dựa trên cấu phần đã được đề nghị trong

công nghiệp Bằng việc dùng Ngôn ngữ mô hình hoá thống nhất

(UML), tiến trình thống nhất xác định ra các cấu phần sẽ đượcdùng để xây dựng hệ thống và giao diện sẽ nối các cấu phần đó.Việc dùng một tổ hợp phát triển lặp và tăng dần, tiến trình thốngnhất định nghĩa chức năng của hệ thống bằng việc áp dụng cáchtiếp cận dựa trên kịch bản (theo quan điểm người dùng) Thế rồi nógắn chức năng với khuôn khổ kiến trúc nhận diện hình dạng màphần mềm sẽ lấy

2.4 Kĩ thuật thế hệ thứ tư

Thuật ngữ kĩ thuật thế hệ thứ tư (4GT) bao gồm một phạm vi

rộng các công cụ phần mềm có một điểm chung: mỗi công cụ đềucho phép người kĩ sư phần mềm xác định đặc trưng nào đó củaphần mềm ở mức cao Rồi công cụ đó tự động sinh ra mã chươngtrình gốc dựa trên đặc tả của người phát triển Người ta gần nhưkhông còn bàn cãi về việc phần mềm có thể được xác định đối vớimột máy càng ở mức cao thì chương trình có thể được xây dựngcàng nhanh hơn Mô thức 4GT cho kĩ nghệ phần mềm tập trungvào khả năng xác định phần mềm bằng việc dùng các khuôn mẫungôn ngữ đặc biệt hay kí pháp đồ hoạ mô tả cho vấn đề cần đượcgiải quyết dưới dạng khách hàng có thể hiểu được

Hiện tại, môi trường phát triển phần mềm hỗ trợ cho mô thức4GT bao gồm một số hay tất cả các công cụ sau: ngôn ngữ phi thủtục để hỏi đáp CSDL, bộ sinh báo cáo, bộ thao tác dữ liệu, bộtương tác và xác định màn hình, bộ sinh chương trình, khả năng đồ

hoạ mức cao, khả năng làm trang tính và việc sinh tự động HTML

và các ngôn ngữ tương tự được dùng cho việc tạo ra trang Web

thông qua việc dùng các công cụ phần mềm tiên tiến Ban đầu

nhiều trong những công cụ đã được nhắc tới đó đã có sẵn chỉ cho

những lĩnh vực ứng dụng rất đặc thù, nhưng ngày nay môi trường

4GT đã được mở rộng để đề cập tới hầy hết các loại ứng dụng phần

mềm

Giống như các mô thức khác, 4GT bắt đầu từ bước thu thập

yêu cầu Một cách lí tưởng, khách hàng sẽ mô tả các yêu cầu và

các yêu cầu đó sẽ được dịch trực tiếp thành một bản mẫu vận hành

được Nhưng điều này không thực hiện được Khách hàng có thể

không chắc chắn mình cần gì, có thể có sự mơ hồ trong việc xác

định các sự kiện đã biết, có thể không có khả năng hay không sẵn

lòng xác định thông tin theo cách thức mà công cụ 4GT có thể tiêu

thụ được Bởi lí do này, đối thoại khách hàng/người phát triển được

mô tả cho các mô hình tiến trình khác vẫn còn là phần bản chất của

cách tiếp cận 4GT

Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước thu

thập yêu cầu sang cài đặt bằng cách dùng ngôn ngữ sinh thế hệ thứ

tư phi thủ tục (4GL) hay một mô hình bao gồm một mạng các biểu

tượng đồ hoạ Tuy nhiên với nỗ lực lớn hơn, cần phải phát triển

một chiến lược thiết kế cho hệ thống, ngay cả nếu có dùng 4GL

Việc dùng 4GT thiếu thiết kế (với các dự án lớn) sẽ gây ra cùng

những khó khăn (chất lượng kém, khó bảo trì, người dùng khó

chấp nhận) mà chúng ta đã gặp phải khi phát triển phần mềm bằng

cách dùng các cách tiếp cận qui ước

Việc cài đặt dùng 4GL làm cho người phát triển phần mềm

biểu diễn được các kết quả mong muốn theo cách là phát sinh tự

động chương trình tính ra chúng Hiển nhiên, một cấu trúc dữ liệu

với những thông tin có liên quan cần phải có sẵn và sẵn sàng cho

Giống như mọi mô thức kĩ nghệ phần mềm, mô hình 4GT có

ưu điểm và nhược điểm Những người ủng hộ cho là làm giảmđáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệusuất của người xây dựng phần mềm Những người phản đối cho làcác công cụ 4GT hiện tại không phải tất cả đều dễ dùng hơn cácngôn ngữ lập trình, rằng chương trình gốc do các công cụ này tạo

ra là "không hiệu quả," và rằng tính bảo trì cho các hệ thống phầnmềm lớn được phát triển bằng cách dùng 4GT vẫn còn là vấn đềmở

Có đôi điều lợi ích trong các luận điểm của cả hai phía và cóthể tóm tắt trạng thái hiện tại của cách tiếp cận 4GT như sau:Việc dùng 4GT là cách tiếp cận có thể tồn tại được cho nhiềulĩnh vực ứng dụng khác nhau Gắn với các công cụ kĩ nghệ phầnmềm có máy tính hỗ trợ và bộ sinh mã, 4GT cung cấp một giảipháp tin cậy được cho nhiều vấn đề phần mềm

Dữ liệu được thu thập từ các công ti có dùng 4GT chỉ ra rằngthời gian cần cho việc tạo ra phần mềm được giảm đáng kể đối vớicác ứng dụng vừa và nhỏ và rằng khối lượng thiết kế và phân tíchcho các ứng dụng nhỏ cũng được rút bớt

Tuy nhiên, việc dùng 4GT cho các nỗ lực phát triển phần mềmlớn đòi hỏi nhiều phân tích, thiết kế và kiểm thử (các hoạt động kĩnghệ phần mềm) để đạt tới việc tiết kiệm thời gian nảy sinh từ việcxoá bỏ mã hoá

Tóm lại, các kĩ thuật thế hệ thứ tư đã trở thành một phần quan

trọng của kĩ nghệ phần mềm Khi đi đôi với cách tiếp cận dựa trên

cấu phần, mô thức 4GT có thể trở thành cách tiếp cận thống trị cho

việc phát triển phần mềm

Phần 3

Các khái niệm về

quản lí dự án

Quản lí dự án là một hoạt động quản lí rất quan trọng mà mọi

người làm về quản lí nói chung đều cần phải nắm được Nó là công

cụ chủ yếu để người quản lí có thể liên kết lao động của nhiều

người lại theo những qui trình xác định và điều phối sự cộng tác

của cả nhóm người nhằm đưa ra được sản phẩm có chất lượng

trong khung thời gian và ngân sách đã định Do vậy việc quản lí dự

án thực chất bao gồm các công cụ, tri thức và kĩ thuật để tiến hành

xác định, lập kế hoạch, tổ chức, kiểm soát và kết thúc dự án

Nhưng trước hết, dự án là gì?

Dự án là một hoạt động có tổ chức của con người nhằm đạt tới

một mục tiêu nào đó, có một ngày bắt đầu và một ngày kết thúc

Mọi dự án đều phải bắt đầu tại một điểm xác định trong thời gian

và phải hoàn thành một lúc nào đó trong tương lai Cái gọi là "dự

án" mà không có ngày kết thúc thì không phải là dự án; chúng

không là gì khác hơn một sự liên tục vô tận của công việc thường

lệ Bảng 3-1 so sánh các đặc trưng của một dự án với các đặctrưng của hoạt động vận hành:

Hoạt động dự án Hoạt động vận hành

Tạo ra một sự chuyển giao đặcbiệt mới

Ngày bắt đầu và kết thúc xácđịnh

Tổ đa ngành

Tổ tạm thờiTính duy nhất của dự ánLàm việc theo kế hoạch bêntrong chi phí đã xác định

Bị xoá bỏ nếu các mục tiêukhông thể được đáp ứng

Ngày tháng kết thúc và chi phínhiều thách thức hơn so với dựđoán và quản lí

Chuyển giao cùng sảnphẩm

Liên tục

Kĩ năng chuyên dụng

Tổ chức ổn địnhLặp lại và đã được hiểu rõLàm việc trong ngân sáchhàng năm

Việc tồn tại liên tục gầnnhư được đảm bảo

Chi tiêu hàng năm đượctính toán dựa trên kinhnghiệm quá khứ

Bảng 3-1 Các hoạt động của dự án so với các hoạt động vận hành

Dự án bao gồm các hoạt động để chuyển giao một sản phẩmcuối cùng Con đường đi tới sản phẩm cuối này còn nhiều hơn việcsoạn thảo về các hoạt động để đi từ điểm A tới điểm Z Một sốbước phải được thực hiện theo trình tự logic, không ngẫu nhiên Đểlàm bước B, trước hết bạn phải làm bước A Dự án không có chỗcho trình tự phi logic bởi vì nó chịu một loạt các ràng buộc áp đặtlên nó, như chi phí, ngân sách và lịch biểu

Dự án phải chuyển giao một sản phẩm, hay "vật chuyển giao"vào lúc cuối Sản phẩm có thể là ô tô, ngôi nhà, chương trình phầnmềm ứng dụng, hay kế hoạch tiếp thị; nói cách khác, phải có kết

quả sờ mó được Nó phải đo được theo các nào đó để kiểm chứng

lại phẩm chất của sản phẩm

3.1 Phổ quản lí

Quản lí dự án (phần mềm) có hiệu quả hội tụ vào bốn chữ P

theo tiếng Anh: con người (people), sản phẩm (product), tiến trình

(process) và dự án (project) Trật tự này không phải là bất kì

Người quản lí nào quên mất rằng công việc kĩ nghệ phần mềm là

nỗ lực rất lớn của con người sẽ chẳng bao giờ thành công trong

quản lí dự án cả Người quản lí không cổ vũ việc trao đổi thấu đáo

với khách hàng ngay từ sớm trong tiến hoá của dự án sẽ gặp rủi ro

xây dựng ra một giải pháp khá hay cho vấn đề sai Người quản lí ít

chú ý tới tiến trình sẽ đi vào nguy cơ đưa các phương pháp và công

cụ kĩ thuật có hiệu lực vào chân không Người quản lí bắt tay vào

công việc mà không có kế hoạch dự án vững chắc gây nguy hiểm

tới sự thành công của sản phẩm

3.1.1 Con người

Con người là nhân tố cơ bản để đảm bảo sự thành công của bất

kì dự án nào và đưa tới những kết quả (sản phẩm) cuối cùng Con

người được phối hợp với nhau trong việc thực hiện dự án theo

những qui trình nhất định, với những kỉ luật chặt chẽ về thời gian

lịch biểu, chi phí, và chất lượng Trong kĩ nghệ phần mềm, con

người chính là yếu tố sản xuất đưa các tri thức mới vào các qui

trình tạo ra sản phẩm mới Do đó việc chú trọng vào cách tổ chức

con người làm việc theo các qui trình dự án là rất quan trọng

Việc phối hợp hoạt động sản xuất, sáng tạo của con người chủ

yếu dựa trên những qui định rõ rệt về nhiệm vụ, công việc mà từng

người phải hoàn thành trong khuôn khổ thời gian và ngân sách nhất

định Ngoài ra việc phối hợp đó, dự án còn cần được hỗ trợ và đảmbảo bởi một loạt tài liệu qui định khuôn khổ chất lượng công việcđược tiến hành Tri thức chung được cụ thể hoá thành những thôngtin điều khiển và hướng dẫn kiểm tra chất lượng công việc chotừng thành viên Việc tách biệt và rút ra các thông tin có tính chất

tổ chức trong các qui trình trí tuệ là nhân tố quan trọng xác địnhnên tính hữu hiệu của các dự án trong việc phối hợp tiềm năng chấtxám của nhiều người

Đây cũng là một khía cạnh mà khoa học về quản lí lao độngcon người trong thời đại thông tin và tri thức đang quan tâm pháttriển Nói riêng, việc trích rút ra các tri thức từ những lao động trítuệ mang tính thủ công để chuyển nó thành tri thức của tổ chứctrong sự phối hợp của nhiều người làm việc trí tuệ sẽ đưa tới nhữnghình thái tổ chức lao động mang tính kĩ nghệ nhiều hơn

Ngày nay trong ngành công nghiệp phần mềm thì công cụ sảnxuất là con người Đấy là một điều rất mới và nếu nói theo kháiniệm thời thượng thì đây là kinh tế tri thức Nó khác hẳn với côngnghiệp cổ điển mà công cụ sản xuất là máy móc, con người chỉ làmột bộ phận của guồng máy sản xuất Trong phần mềm thì công cụsản xuất là con người, con người sản xuất ra những thành phầnđiều khiển các dây chuyền sản xuất khác Bởi vậy những ngườiquản lí sản xuất phần mềm có vai trò rất quan trọng đối với phầnmềm và những người này phải có hiểu biết về tâm lí rất sâu sắcmới sử dụng được công cụ sản xuất này

Tâm lí con người trong quá trình tham gia vào các dự án làmột điều cần được nhấn mạnh Kĩ nghệ phần mềm là một vấn đề

mà trong đó khoa tâm lí học mang tới sự hỗ trợ trực tiếp Bởi vìcông cụ sản xuất là con người Vậy có thể sử dụng con người nhưcái máy được không? Một cái máy được làm hoàn chỉnh mà nókhông có dầu mỡ thì cũng chưa chạy được Cho nên áp dụng kĩ

nghệ phần mềm trong các dự án thì cần để ý rằng phải có những

chú ý về tâm lí không tránh khỏi

3.1.2 Sản phẩm

Trước khi một dự án có thể được lập kế hoạch, các mục đích

và phạm vi sản phẩm cần phải được thiết lập, các phương án khác

nên được xem xét tới, rồi các ràng buộc kĩ thuật và quản lí cần

được nhận diện Không có những thông tin này thì không thể nào

xác định được các ước lượng tính hợp lí (và chính xác) về chi phí,

định giá hiệu quả về rủi ro, phân chia hiện thực các nhiệm vụ dự

án, hay lịch dự án có thể quản lí được, cung cấp chỉ báo có ý nghĩa

về tiến độ

Người phát triển phần mềm và khách hàng phải gặp gỡ để định

nghĩa ra các mục đích và phạm vi sản phẩm Trong nhiều trường

hợp, hoạt động này bắt đầu như một phần của kĩ nghệ hệ thống hay

kĩ nghệ tiến trình nghiệp vụ và tiếp tục như bước thứ nhất trong

phân tích yêu cầu phần mềm Các mục đích xác định ra các mục

tiêu tổng thể cho sản phẩm (theo quan điểm của khách hàng) mà

không xem xét tới cách những mục tiêu này sẽ được đạt tới Phạm

vi xác nhận diện ra dữ liệu, chức năng và hành vi chủ chốt đặc

trưng cho sản phẩm, và quan trọng hơn, nỗ lực để gắn các đặc

trưng này theo cách thức định lượng

Một khi các mục đích và phạm vi sản phẩm đã được hiểu, thì

các giải pháp phương án được xét tới Mặc dầu rất ít chi tiết được

thảo luận, các phương án này làm cho người quản lí và người hành

nghề chọn ra cách tiếp cận "tốt nhất", trong những ràng buộc bị áp

đặt bởi hạn giao hàng, ràng buộc ngân sách, nhân sự có sẵn, giao

diện kĩ thuật và nhiều nhân tố khác

Cần thấy rõ sản phẩm phần mềm không phải chỉ là chươngtrình, sản phẩm phần mềm chính là tài liệu phát sinh toàn toàn bộqui trình làm việc Chương trình phần mềm là những cái cơ bản,cái cốt lõi của phần mềm, thường đã được dạy nhiều trong các đạihọc, nhưng rõ ràng chưa đủ khi đi vào thực tế Đối với sản phẩmphần mềm thì điều quan trọng nhất không phải là chương trình mà

là tài liệu, để người khác hiểu được chương trình, để người khác sửdụng được chương trình, để người khác kế thừa được chương trình

3.1.3 Qui trình

Qui trình phần mềm (Phần 2) cung cấp một khuôn khổ để từ

đó một kế hoạch toàn diện về phát triển phần mềm có thể đượcthiết lập Một số nhỏ các hoạt động khung là áp dụng được cho mọi

dự án phần mềm, bất kể tới kích cỡ hay độ phức tạp của chúng.Một số các tập nhiệm vụ khác nhau - nhiệm vụ, cột mốc, sản phẩmcông việc và điểm đảm bảo chất lượng - làm cho các hoạt độngkhung được thích ứng cho các đặc trưng của dự án phần mềm vàyêu cầu của tổ dự án Cuối cùng, các hoạt động yểm trợ - như đảmbảo chất lượng phần mềm, quản lí cấu hình phần mềm, và việc đo

sẽ chờm lên mô hình tiến trình Các hoạt động yểm trợ là độc lậpvới bất kì một hoạt động khung nào và xuất hiện trong toàn bộ tiếntrình

Phát triển theo qui trình kĩ nghệ thì phải tuần tự theo từng giaiđoạn Những giai đoạn đó có những phương pháp và kĩ thuật riêng

mà những người tham dự cần nắm vững Nhưng xuyên suốt quacác giai đoạn này, người ta phải dùng một ngôn ngữ trao đổi chungvới một tinh thần nhìn chung Điều này bao quát mọi kết quả trunggian của qui trình, không chỉ sản phẩm cuối cùng