Trong Unix, khi một file hay một thư mục được tạo ra thì quyền truy nhập đối với chúng (r, w, x) sẽ được xác định dựa trên hai giá trị là quyền truy nhập cơ sở (base permission) và mặt nạ (mask). Quyền truy nhập cơ sở là giá trị được thiết lập sẵn từ trước, đối với file là 666 (rw-rw-rw) và thư mục là 777 (rwxrwxrwx). Mặt nạ là giá trị đựợc thiết lập bởi người dùng bằng lệnh umask. Giá trị mặt nạ sẽ “che đi” một số bit trong quyền truy nhập cơ sở để tạo ra quyền truy nhập chính thức cho file (tương tự như cơ chế của subnet mask).

Cụ thể, quyền truy nhập chính thức được tính bằng cách lấy giá trị nhị phân của quyền truy nhập cơ sở AND với dạng biểu diễn bù 1 của mặt nạ. Ví dụ: Vì quyền truy nhập cơ sở của file là 666 (tức 110110110), nên nếu giá trị mask là 022 (000010010) thì quyền truy nhập chính thức của file sẽ là:

110 110 110 AND 111 101 101 = 110 100 100 = 644 (rw-r–r–)

Như vậy, các bit trong quyền truy nhập cơ sở ứng với các bit 1 của mask sẽ bị xóa. Cũng có thể tính quyền truy nhập chính thức đơn giản hơn bằng cách lấy 666 – 022 = 644.

Giá trị mặt nạ được thiết lập như thế nào?

Giá trị mask được thiết lập nhờ lệnh umask trên terminal hoặc bằng hàm hệ thống umask. Các file được tạo ra sau lệnh umask sẽ chịu tác động của giá trị mặt nạ mới.

Cơ chế làm việc của umask khiến chúng ta không thể tạo ra các file với quyền executable mặc định. Vì quyền truy nhập cơ sở của file là 666, tức các bit ứng với quyền executable đều bằng 0, nên bất kể giá trị mask bằng bao nhiêu thì quyền truy nhập chính thức của file đều không có executable. Chúng ta buộc phải cấp thêm quyền executable cho file sau khi chúng đã được tạo ra.

Quyền truy nhập file và một số lệnh phổ biến

- Lệnh cp: Khi được sao chép sang vị trí mới, quyền truy nhập của file được tính theo công thức trình bày ở trên với giá trị mask tại vị trí đích. Trong trường hợp trùng tên file thì quyền truy nhập của file ở vị trí đích sẽ được bảo lưu. Sử dụng tùy chọn –p để lấy quyền truy nhập của file nguồn

- Lệnh tar: Khi giải nén các file, lệnh tar lấy quyền truy nhập của từng file làm quyền truy nhập cơ sở cho file đó.

Một đội dự án XP làm việc cùng nhau trong một không gian mở không có các phòng riêng hoặc vách ngăn. Vào đầu mỗi vòng lặp, đội tổ chức một cuộc họp kéo dài từ 2 đến 4 giờ để tổng kết những công việc vừa hoàn thành và lập kế hoạch cho phần việc tiếp theo. Hàng ngày, cả đội tham gia một cuộc họp ngắn từ 5 đến 10 phút thảo luận về công việc trong ngày. Ngoài hai kiểu họp chính thức này, từng thành viên tự lập kế hoạch làm việc cho mình. Hình thức “tự tổ chức” (self-organization) là một đặc điểm chung của các dự án theo triết lí Agile.
Trong một dự án phần mềm, những hiểu biết về sản phẩm luôn được nắm giữ bởi nhiều cá nhân. XP thừa nhận thực tế này bằng cách tạo ra một nhóm làm việc hỗn hợp với đầy đủ các vai trò cần thiết. Một đội dự án XP thường bao gồm các thành viên sau đây:
Đại diện khách hàng (onsite customer): Chịu trách nhiệm xác định các yêu cầu (requirement) cho phần mềm. Công việc quan trọng nhất của người này là lập kế hoạch. Khi bắt đầu dự án, đại diện khách hàng xác định các tính năng (feature/story) cần có của phần mềm, tìm cách nhóm các tính năng này thành các phần nhỏ có thể phát triển và bàn giao lần lượt và định ra lịch trình bàn giao từng phần. Trong quá trình thực hiện dự án, đại diện khách hàng nhận phản hồi từ các thành viên khác và điều chỉnh kế hoạch cho phù hợp.
Nhiệm vụ thứ hai của đại diện khách hàng là giúp các lập trình viên hiểu các yêu cầu chi tiết cho sản phẩm. Trong các dự án XP, tài liệu đặc tả (SRS) chỉ là công cụ trợ giúp cho đại diện khách hàng mà thôi. Người này sẽ đóng vai trò một tài liệu “sống”, luôn sẵn sàng trả lời các câu hỏi từ các lập trình viên.
Đại diện khách hàng không nhất thiết phải là khách hàng thật mà chỉ cần là một thành viên hiểu rõ các yêu cầu của phần mềm. Thực nghiệm cho thấy giữa hai nhóm có chất lượng lập trình viên tương đương nhau thì nhóm có sự tham gia của khách hàng tạo ra sản phẩm tốt hơn hẳn. Nếu khách hàng không thể đến ngồi ở văn phòng của bạn, hãy đưa đội dự án của bạn đến ngồi cùng với khách hàng!
Thực nghiệm cũng cho thấy tỉ lệ hai đại diện khách hàng cho ba lập trình viên là phù hợp. Tất nhiên, tỉ lệ này phụ thuộc vào độ phức tạp của sản phẩm. Hãy ghi nhớ rằng khối lượng công việc của các đại diện khách hàng là rất lớn bởi họ luôn phải “chạy trước” các lập trình viên.
Người quản lí sản phẩm (product manager/owner): Người này chịu trách nhiệm định hướng cho dự án và sản phẩm, bao gồm các công việc: Xác định các tính năng của sản phẩm và thứ tự ưu tiên của chúng, hướng dẫn đại diện khách hàng, làm việc với các bên liên quan đến dự án (stakeholder), đánh giá tiến độ dự án và giải quyết các vấn đề về tổ chức. Ngoài ra, người quản lí sản phẩm còn chịu trách nhiệm đưa sản phầm ra thị trường, bao gồm các việc quảng cáo, bán hàng và hỗ trợ khách hàng.
Người quản lí sản phầm phải am hiểu thị trường và các lợi ích mà phần mềm sẽ mang đến cho khách hàng. Đồng thời, người này phải có khả năng cộng tác và thoả hiệp với các đòi hỏi đa dạng, nhiều khi mâu thuẫn nhau, từ các cá nhân có quyền lợi liên quan đến dự án. Người quản lí sản phẩm phải được trao đủ quyền lực để có thể nói không với các yêu cầu không phù hợp. Một dự án chỉ nên có duy nhất một người quản lí sản phầm nhằm đảm bảo tính thống nhất cho định hướng của dự án.
Các chuyên gia nghiệp vụ (Domain Expert): Các lập trình viên ít khi hiểu biết tường tận về một lĩnh vực cụ thể nào đó, ví dụ như tài chính hay hoá học. Bởi vậy, XP yêu cầu sự tham gia của các chuyên gia hiểu rõ lĩnh vực chuyên môn của phần mềm đang được phát triển, chẳng hạn như các chuyên gia phân tích tài chính hay các nhà nghiên cứu hoá học. Những người này sẽ nghiên cứu nghiệp vụ của phần mềm để sẵn sàng trả lời câu hỏi của các lập trình viên.
Trong các dự án nhỏ, người quản lí sản phẩm thường kiêm luôn vai trò chuyên gia nghiệp vụ.
Người thiết kế giao diện (Interaction Designer): Giao diện người dùng (user interface) là bộ mặt của sản phẩm. Người dùng thường đánh giá chất lượng phần mềm thông qua chất lượng giao diện mà họ tương tác hàng ngày. Nhiệm vụ của người thiết kế giao diện là tìm hiểu mong muốn của khách hàng cũng như thói quen làm việc thường ngày của họ và từ đó thiết kế bộ mặt của sản phẩm.
Đừng nhầm lẫn giữa người thiết kế giao diện và người thiết kế đồ họa (graphic designer). Người thiết kế giao diện nghiên cứu tương tác giữa người dùng và sản phẩm. Trong khi đó người thiết kế đồ họa tạo ra các thành phần cụ thể như âm thanh, hình ảnh hay cách bố trí giao diện (layout).
Lập trình viên (Programmer): Nếu nhiệm vụ của người đại diện khách hàng là tối đa hóa giá trị của sản phẩm thì nhiệm vụ của các lập trình viên là tối thiểu hóa chi phí bằng việc lập trình theo cách hiệu quả nhất. Nhiệm vụ của các lập trình viên trong dự án XP là:
Ước lượng thời gian và nguồn lực cần thiết để thực hiện các chức năng của phần mềm, từ đó trợ giúp đại diện khách hàng trong việc lập kế hoạch. Lập trình viên cũng trao đổi trực tiếp với đại diện khách hàng để làm rõ các yêu cầu của phần mềm.
Các lập trình viên làm việc theo cặp (pair programming) và sử dụng phương pháp phát triển dựa trên test (test-driven development). Mỗi lập trình viên có trách nhiệm viết test, viết và tối ưu hóa mã nguồn, thiết kế và liên tục cải tiến thiết kế của chương trình. Mã nguồn được xem là sở hữu tập thể, tất cả các lập trình viên đều có quyền và nghĩa vụ sửa các lỗi mà họ phát hiện ra, bất kể lỗi đó do ai gây ra. Chuẩn lập trình (coding standard) đóng vai trò thiết yếu hỗ trợ cho cách làm việc này. Các lập trình viên liên tục tích hợp mã nguồn vào hệ thống và test một cách cẩn thận nhằm đảo bảo rằng phần mềm đủ tiêu chuẩn để đóng gói và bàn giao cho khách hàng vào cuối mỗi chu kì phát triển. Các lập trình viên chỉ viết tài liệu khi cần thiết nhằm trợ giúp cho việc bảo trì phần mềm trong tương lai.
Trong đội lập trình cần có một số thành viên có kinh nghiệm thiết kế phần mềm, có trách nhiệm hướng dẫn các lập trình viên khác. Đội cũng cần các thành viên có kinh nghiệm về các lĩnh vực cụ thể như cơ sở dữ liệu hay bảo mật.
Thực nghiệm cho thấy một dự án XP nên có từ 4 đến 10 lập trình viên.
Tester: Các dự án XP nói chung không cần nhiều tester. Các lập trình viên được trông đợi sẽ chuyển giao các chương trình gần như không có lỗi cho tester. Các chương trình test tự động (automated test) cũng làm giảm số lượng tester cần thiết.
Các dự án XP thường có tỉ lệ tester/lập trình viên từ 1/4 đến 1/6. Một số dự án còn không có tester mà sử dụng đại diện khách hàng và lập trình viên vào vai trò này!
Quản lí dự án/Hướng dẫn viên (Project Manager/Coach): Là những người có kinh nghiệm về XP, làm nhiệm vụ giúp đỡ các thành viên khác thực hiện các quy tắc của XP cũng như giao tiếp với các cá nhân bên ngoài dự án.
Các thành viên khác: Hãy nhớ rằng có rất nhiều người có lợi ích liên quan đến dự án nhưng không làm việc cùng đội dự án. Họ là những người dùng cuối, lãnh đạo cấp cao, phòng nhân sự…(gọi chung là các stakeholder). Những người này dù không “lộ mặt” nhưng đều có ảnh hưởng đến thành công của dự án. Người quản lí sản phẩm phải thấu hiểu được những yêu cầu rất đa dạng của đội ngũ này.
Một dự án XP không nhất thiết phải có đầy đủ các thành viên nói trên, hoặc  ngược lại có thể sử dụng thêm các thành viên khác nếu cần. Một thành viên trong dự án có thể đảm nhiệm nhiều vai trò cũng lúc. Chẳng hạn, người quản lí sản phẩm có thể đồng thời là chuyên gia nghiệp vụ hoặc quản lí dự án. Đại diện khách hàng có thể kiêm vai trò thiết kế giao diện. Các lập trình viên có thể làm công việc của tester.
Một dự án XP thường có từ 4 đến 10 lập trình viên. Một dự án có 6 lập trình viên thường cần 4 đại diện khách hàng, 1 tester và 1 người quản lí sản phẩm, tổng cộng là 12 thành viên. Nếu số lập trình viên là 10, sẽ cần đến 6 đại diện khách hàng, 3 tester và một người quản lí sản phẩm, hợp thành một nhóm 20 người. Đây cũng là con số tối đa của một dự án XP thông thường.
Kích thước nhóm lớn sẽ gây khó khăn cho việc giao tiếp giữa các thành viên. Bởi vậy, XP khuyến khích tuyển dụng các thành viên có kinh nghiệm thay vì tăng số lượng người.

Tài liệu tham khảo
Sách: The Art of Agile Development by James Shore and Shane Warden.
Web: http://agilemanifesto.org/

Một tiến trình (process) trong Unix sở hữu 3 user ID sau đây:

Real user ID (user ID thật): Là user ID của người khởi động tiến trình.
Effective user ID (user ID hiệu dụng): Là một loại user ID được dùng trong những trường hợp sau đây:

• Khi tiến trình truy nhập một file, hệ điều hành kiểm tra xem effective user của tiến trình có quyền truy nhập file hay không.
• Khi tiến trình tạo mới một file, hệ điều hành lấy effective user của tiến trình làm chủ sở hữu (owner) của file.
• Khi tiến trình muốn gửi tín hiệu đến một tiến trình khác, hệ điều hành kiểm tra xem effective user của tiến trình gửi có quyền gửi tín hiệu hay không.

Saved user ID: Là giá trị của effective user ID được lưu trong bảng các tiến trình (process table). Mỗi tiến trình có một vùng dữ liệu tương ứng trong bảng các tiến trình. Saved user ID đóng vai trò như một bản backup cho effective user ID, được dùng khi tiến trình muốn quay lại effective user ID ban đầu.

Tương ứng với 3 loại user ID này là ba loại group ID: real group ID, effective group ID và saved group ID.

Vì sao cần effective user ID?
Effective user là một cơ chế quản lí truy nhập của Unix (access control hay authorization). Xem ví dụ sau đây: Alice là một kế toán và cô ta cần có quyền thay đổi file dữ liệu kế toán account_data của công ty. Tuy nhiên, để đảm bảo tính toàn vẹn dữ liệu, Alice không được phép thay đổi dữ liệu kế toán một cách thủ công mà phải thông qua một chương trình tên là account_program. Như vậy:

• Alice không có quyền ghi đối với account_data.
• account_program có quyền ghi đối với account_data.
• Alice có quyền chạy account_program.

Tuy nhiên, trong Unix chỉ có người dùng mới được coi là các chủ thể được cấp quyền sử dụng tài nguyên. Bởi vậy, giải pháp trong Unix là tạo ra một người dùng có quyền ghi đối với account_data, thiết lập effective user ID của account_program bằng ID của người dùng đó và trao cho Alice quyền chạy account_program.

Effective user ID được thiết lập như thế nào?
Giá trị của effective user ID được thiết lập bằng hai cách:

Thông qua bit suid: Mỗi một file chương trình có một thuộc tính gọi là suid. Nếu bit suid được thiết lập thì khi chạy file chương trình, tiến trình tương ứng sẽ có effective user và saved user là chủ sở hữu của file chương trình. Ngược lại nếu bit suid không được thiết lập, effective user và saved user của tiến trình sẽ là người khởi động tiến trình (chú ý rằng chủ sở hữu file và người chạy file thường là hai người dùng khác nhau).

Thông qua hàm setuid(): Hàm setuid() dùng để thay đổi effective user ID của một tiến trình trong thời gian chạy (runtime).

#include <sys/types.h>
#include <unistd.h>
 
int setuid( uid_t uid );

Tham số uid là giá trị user ID mới. Kết quả thực hiện setuid() là như sau:

• Trường hợp 1: Nếu effective user hiện thời của tiến trình là root, cả ba giá trị real user ID, effective user ID và saved user ID đều được gán giá trị uid.
• Trường hợp 2: Nếu effective user hiện thời của tiến trình không phải là root, effective user ID được gán giá trị uid nếu uid bằng real user ID hoặc saved user ID hiện thời của tiến trình. Nếu uid không bằng một trong hai giá trị này, setuid() trả về giá trị lỗi.

Hiểu một cách “nôm na” thì một tiến trình đang có effective user là root có thể “hoá thân” thành bất kì user nào. Trong khi đó một tiến trình “bình thường” chỉ có thể chuyển hoá qua lại giữa hai giá trị real user ID và effective user ID ban đầu mà thôi.

Một tiến trình cần thay đổi effective user ID nhằm đảm bảo nguyên tắc “đặc quyền tối thiểu” (least privilege – một trong 8 nguyên tắc đảm bảo tính bảo mật của phần mềm [2]), theo đó một người dùng hay một tiến trình chỉ được cấp quyền tối thiểu để thực hiện một nhiệm vụ nào đó. Bởi vậy, một tiến trình chỉ sử dụng effective user là root khi thực sự cần thiết mà thôi. Theo trường hợp 2 ở trên, khi một tiến trình chuyển từ effective user root sang một effective user thông thường, nó sẽ không thể lấy lại trạng thái root bằng hàm setuid().

Xem ví dụ minh họa sau đây (lấy từ [1]):
user1 và user2 là hai người dùng trong hệ thống có user ID lần lượt là 501 và 502. user1 và user2 lần lượt là chủ sở hữu của các file fuser1 và fuser2, chỉ chủ sở hữu mới có quyền đọc hai file này. File chương trình testsuid.c sau khi dịch thuộc quyền sở hữu của user2 nhưng user1 có quyền chạy.

Trước hết chúng ta kiểm tra giá trị của effective user ID trước khi gọi hàm setuid()

/* testsuid.c */
#include <unistd.h>
#include <stdio.h>
 
int main()
{
  int uid, euid, fuser1, fuser2;
 
  uid  = getuid();   /* get real UID */
  euid = geteuid(); /* get effective UID */
  printf( "uid: %d, euid: %d\n", uid, euid );
 
  return 0;
}

Dịch chương trình và lưu file chạy vào một thư mục chung sao cho user1 và user2 đều truy nhập được. Khi bit suid chưa được thiết lập, effective user ID luôn bằng real user ID:

Kết quả khi user1 chạy chương trình:

testsuid
uid: 502, euid: 502

Kết quả khi user1 chạy chương trình:

testsuid
uid: 501, euid: 501

Bây giờ chúng ta thiết lập bit suid cho testsuid như sau (thực hiện bởi user2):

chmod u+s testsuid
ls -l testsuid
-rwsr-xr-x 1 user2 users 5404 Jun  6 21:28 testsuid

Chữ s trong phần quyền truy nhập file cho thấy testsuid là một chương trình suid. Kết quả là effective user ID của tiến trình luôn bằng user ID của user2:

Kết quả khi user1 chạy chương trình:

testsuid
uid: 501, euid: 502

Tiếp theo, hàm setuid() được đưa vào testsuid.c như sau:

#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
 
int main()
{
  int uid, euid, fuser1, fuser2;
 
  uid  = getuid(); /* get real UID */
  euid = geteuid(); /* get effective UID */
  printf( "uid: %d, euid: %d\n", uid, euid );
 
  fuser1 = open( "fuser1", O_RDONLY );
  fuser2 = open( "fuser2", O_RDONLY );
  printf( "fuser1: %d, fuser2: %d\n", fuser1, fuser2 );
 
  setuid( uid );
  printf( "after setuid(%d), uid: %d, euid: %d\n", uid, getuid(), geteuid() );
 
  fuser1 = open( "fuser1", O_RDONLY );
  fuser2 = open( "fuser2", O_RDONLY );
  printf( "fuser1: %d, fuser2: %d\n", fuser1, fuser2 );
 
  setuid( euid );
  printf( "after setuid(%d), uid: %d, euid: %d\n", euid, getuid(), geteuid() );
 
  return 0;
 
}

Kết quả khi user1 chạy chương trình:

testsuid
uid: 501, euid: 502
fuser1: -1, fuser2: 3
after setuid(501), uid: 501, euid: 501
fuser1: 4, fuser2: -1
after setuid(502), uid: 501, euid: 502

Ban đầu real user ID của tiến trình bằng user ID của user1 (501) và effective user ID của tiến trình bằng user ID của user2 (502). Bởi vậy, tiến trình không đọc được fuser1 nhưng đọc được fuser2. Hàm setuid( uid ) gán effective user ID bằng real user ID (501). Do đó, sau lời gọi hàm, tiến trình đọc được fuser1 mà không đọc được fuser2. Lời gọi setuid( euid ) lấy lại giá trị ban đầu cho effective user ID (chú ý rằng euid đang được lưu trong saved user ID).

Kết quả khi user2 chạy chương trình là:

testsuid
uid: 502, euid: 502
fuser1: -1, fuser2: 3
after setuid(502), uid: 502, euid: 502
fuser1: -1, fuser2: 4
after setuid(502), uid: 502, euid: 502

Tiến trình không đọc được fuser1 vì effective user của nó luôn là user2.

Các chương trình suid trên Unix
Một trong số các chương trình suid sẵn có trong Unix là passwd, được sử dụng để thay đổi password cho người dùng.

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 19876 Jul 17  2006 /usr/bin/passwd

passwd thuộc sở hữu root, do vậy khi chạy sẽ có effective user là root. Người dùng không được phép ghi trực tiếp lên file password mà phải thông qua passwd.

Nhược điểm của effective user ID
effective user là một lỗ hổng bảo mật của Unix. Các lập trình viên thường viết các chương trình có effective user là root kể cả khi không cần thiết và đó là điểm yếu cho những kẻ phá hoại khai thác. Một số lời khuyên khi thiết kế các chương trình suid được trình bày trong [3].

Tài liệu tham khảo
[1] The Design of The UNIX Operating System của Maurice J. Bach.
[2] The Protection of Information in Computer Systems của Saltzer & Schroeder.
[3] Practical UNIX & Internet Security của Simson Garfinkel & Gene Spafford.

Extreme Programming (gọi tắt là XP, một số tài liệu tiếng Việt dịch là “lập trình cực hạn”) là một phương pháp phát triển phần mềm tuân thủ triết lí Agile. Trong số các phương pháp Agile thì XP là một trong các phương pháp hoàn thiện nhất và nhận được nhiều sự quan tâm nghiên cứu nhất. Một số phương pháp Agile khác là Scrum và Agile Unified Process (AUP).

Vòng đời của một dự án XP

Các hoạt động cơ bản của một dự án phần mềm là:

1. Lập kế hoạch (planning).
2. Phân tích yêu cầu (analysis).
3. Thiết kế (design).
4. Lập trình (programming).
5. Test.
6. Bàn giao sản phẩm (deploy).

Mô hình cổ điển thác nước (waterfall) sắp xếp các hoạt động này theo thứ tự tuyến tính, đầu ra của hoạt động này là đầu vào của hoạt động tiếp theo. Các mô hình lặp (iterative – chẳng hạn mô hình tăng trưởng hay mô hình tiến hóa) sắp xếp các hoạt động này xen kẽ lẫn nhau.

Hình 1: (a) Mô hình thác nước. (b) Mô hình lặp

XP hoạt động theo mô hình lặp. Sản phẩm được chia ra thành các phần tăng trưởng nhỏ, mỗi phần được phát triển trong vòng một hoặc vài tuần gọi là một vòng lặp (iteration). Với mỗi phần tăng trưởng, đội dự án thực hiện tất cả các hoạt động: lập kế hoạch, phân tích, thiết kế, lập trình, test và bàn giao. Ưu điểm của mô hình này là đội dự án nhanh chóng nhận được phản hồi từ phía khách hàng. Những thay đổi cần thiết sẽ được áp dụng ngay trong lần lặp tiếp theo.

Hình 2: Vòng đời của một dự án XP

Lập kế hoạch

Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên. Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng. Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án.
Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp. Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc.

Phân tích
XP không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu. Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm. Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này.
Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình. Một số dự án thuê người thiết kế giao diện riêng.

Thiết kế và lập trình
Trong một dự án XP, thiết kế của sản phẩm được cải tiến liên tục. Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development hay TDD). TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình.
Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng.
Mã nguồn được coi là sở hữu tập thể. Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra.

Test
Tất cả các thành viên trong dự án XP đều có trách nhiệm đảm bảo chất lượng sản phẩm. Các lập trình viên thực hiện unit test và integration test. Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các customer test. Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn.
Tất cả các regression test đều được thực hiện tự động (bởi code mới được tích hợp vào hệ thống một cách liên tục) và được chạy bởi các lập trình viên khi họ tích hợp code mới vào hệ thống.
Lập trình theo cặp góp phần làm tăng chất lượng công việc.

Bàn giao sản phẩm
Hệ thống được trình diễn nội bộ hàng tuần và được bàn giao cho khách hàng theo kế hoạch đã định trước hoặc theo nhu cầu của khách hàng.

Tài liệu tham khảo
Sách: The Art of Agile Development của James Shore và Shane Warden: http://jamesshore.com/Agile-Book/
Web: http://agilemanifesto.org/

(còn tiếp…)

Roles in Software Engineering

UML

The Semantic Web

Introduction to AOP

10 years of Agile Experiences

Software Components

Interview Erich Gamma

Introduction to Embedded Systems

Internals of GCC

eXtreme Programming

Agile là gì?

Agile là một triết lí (philosophy) cho việc phát triển phần mềm. Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm. Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm (method), chẳng hạn như Extreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile.

Mỗi phương pháp Agile bao gồm một tập hợp các quy tắc (pratice), chẳng hạn quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc trình diễn sản phẩm hàng tuần cho khách hàng.

Triết lí Agile được đưa ra trong một bản tuyên ngôn (manifesto) gồm 4 điểm và được làm rõ hơn bởi 12 quy tắc.

Vì sao chúng ta cần Agile?

Theo quan niệm truyền thống, một dự án phần mềm được coi là thành công khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng. Trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng.

Ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi là thành công khi thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty. Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm. Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của sản phẩm. Vị trí của nhóm sẽ được bảo đảm nhờ các thành công mà nhóm mang lại cho công ty. Các phương pháp Agile giúp cho dự án phần mềm đạt được ba thành công này.

Ba tiêu chí đánh giá thành công của một dự án phần mềm

Thành công ở mức công ty

Agile nhắm đến việc tạo ra giá trị cho công ty trong khi làm giảm chi phí. Đồng thời, Agile giúp sớm xác định các kì vọng đối với sản phẩm đang được phát triển. Nhờ đó, những dự án không mang lại giá trị như mong đợi sẽ được phát hiện sớm, tiết kiệm chi phí cho công ty.

Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc trực tiếp cùng với đội dự án. Các chức năng quan trọng nhất của sản phẩm được tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể. Các phiên bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào.

Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm. Chất lượng mã nguồn được cải tiến liên tục. Tiến độ dự án cũng được xem xét và đánh giá một cách thường xuyên.

Thành công về mặt kĩ thuật

Trong Extreme Programming, một phương pháp tuân theo triết lí Agile, các lập trình viên làm việc cùng nhau. Nhờ vậy, các chi tiết quan trọng sẽ không bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người. Các lập trình viên liên tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép một phiên bản mới của phần mềm được “ra lò” bất cứ khi nào nó góp thêm một giá trị đáng kể. Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một chức năng trước khi chuyển sang chức năng tiếp theo. Bởi vậy, tiến độ công việc được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thay đổi từ phía khách hàng.

Ngoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo ra các thiết kế và các đọan mã tốt. Chẳng hạn, quy tắc “phát triển dựa trên kiểm thử” (test-driven development) trợ giúp lập trình viên viết các chương trình thực hiện đúng chức năng mong muốn.

Thành công về mặt cá nhân

Mỗi thành viên trong dự án Agile, dù ở bất kì cương vị nào, cũng đều cảm nhận được một cách rõ ràng sự thành công của bản thân.

Các lập trình viên nhận thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của mình đối với dự án được nâng cao, chẳng hạn trong việc ước lượng và lập kế hoạch. Quyền tự chủ của đội dự án cũng được tăng cường.

Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng sản phẩm, đồng thời giảm được các công việc lặp lại một cách nhàm chán.

Nhà quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự án thực hiện đúng các cam kết và làm thỏa mãn khách hàng.

Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì điều kiển được hướng đi của dự án và các ý kiến được lắng nghe.

Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợi nhuận lớn cho công ty.

Bản tuyên ngôn 4 điểm cùng 12 quy tắc của Agile

Tuyên ngôn 4 điểm của Agile là:

1. Cá nhân và các tương tác quan trọng hơn quy trình và công cụ.

2. Tập trung làm cho phần mềm chạy được thay vì viết tài liệu.

3. Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng.

4. Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn.

Bản tuyên ngôn được cụ thể hóa bằng 12 nguyên tắc sau:

1. Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và liên tục.

2. Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai đoạn cuối.

3. Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì ngắn tốt hơn chu kì dài.

4. Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau hàng ngày.

5. Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng họ.

6. Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp.

7. Các chức năng đã họat động là thước đo chính cho tiến độ dự án.

8. Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản lí…phải có khả năng tham gia dự án một cách liên tục.

9. Liên tục cải tiến chất lượng thiết kế và mã nguồn.

10. Tính đơn giản giữ vai trò cốt yếu. Làm càng ít càng tốt.

11. Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ.

12. Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc.

Áp dụng Agile

Không phải dự án nào cũng nên áp dụng Agile. Nếu mục tiêu của bạn là tăng năng suất lao động, làm cho các lập trình viên làm việc nhanh hơn thì Agile có thể không phù hợp bởi các quy tắc của nó không nhằm tăng năng suất của đội dự án.Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu hỏi: liệu Agile có giúp bạn thành công hơn hay không?.

Các dự án có đặc điểm sau đây có thể phù hợp với Agile:

• Mức độ rủi ro thấp.

• Thành viên nhóm có kinh nghiệm.

• Yêu cầu thay đổi thường xuyên.

• Kích thước nhóm nhỏ. Các thành viên làm việc cùng một địa điểm.

• Văn hóa công ty ưa thích sự “không trật tự” (thrive on chaos).

Trái lại, những điều kiện sau đây là vật cản cho việc áp dụng Agile:

• Kích thước nhóm lớn ( hơn 20 thành viên bao gồm lập trình viên, tester,…).

• Các thành viên phân tán về mặt địa lí (ví dụ các dự án outsource).

• Văn hóa làm việc theo mệnh lệnh.

Tài liệu tham khảo:

Sách: The Art of Agile Development by James Shore and Shane Warden.

Web: Tuyên ngôn và các nguyên tắc của Agile

(Còn tiếp…)

]]> http://www.openandfree.org/blog/?feed=rss2&p=80 5 http://www.openandfree.org/blog/?p=78 http://www.openandfree.org/blog/?p=78#comments Sat, 22 Nov 2008 00:47:09 +0000 kiennguyen http://www.openandfree.org/blog/?p=78 Khi học Java, chúng ta thường bắt gặp những chương trình đơn giản về animation trong các sách dạy AWT và Swing, chẳng hạn như chương trình sau đây:

import java.awt.*;
import javax.swing.*;
 
public class Animation1 {
 
  public static void main( String[] args ) {
 
     Animation1 gui = new Animation1();
     gui.go();
 
  }
 
  private void go() {
 
     JFrame frame = new JFrame();
     frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
 
     panel_ = new MyPanel();
     frame.getContentPane().add( panel_, BorderLayout.CENTER );
 
     frame.setSize( 500, 500 );
     frame.setVisible( true );
 
     for( int i = 0; i < 400; i++ ) {
 
        x_++;
        y_++;
 
        panel_.repaint();
 
        try {
          Thread.sleep( 10 );
        } catch( Exception ex ) { }
 
     }
 
  }
 
  class MyPanel extends JPanel {
 
     public void paintComponent( Graphics g ) {
 
         g.setColor( Color.white );
         g.fillRect( 0, 0, this.getWidth(), this.getHeight() );
 
         g.setColor( Color.green );
         g.fillOval( x_, y_, 40, 40 );
 
     }
 
  }
 
  private JPanel panel_;
  private int x_ = 0;
  private int y_ = 0;
 
}

Chương trình này vẽ ra một vòng tròn trên một panel, tính toán lại tọa độ của nó rồi gọi repaint() để vẽ lại vòng tròn. Phương thức repaint() yêu cầu các component trên frame tự vẽ lại.Thao tác vẽ lại liên tục với các vị trí khác nhau sẽ tạo ra cảm giác vòng tròn chạy trên panel. Câu lệnh Thread.sleep(10) làm giảm tốc độ di chuyển của vòng tròn giúp người dùng dễ theo dõi.

Chúng ta thử sáng tạo thêm một chút bằng cách thêm vào frame một button dùng kể kích hoạt animation (học event handler và inner class luôn). Animation sẽ được kích hoạt khi người dùng ấn nút “Start animation”. Chương trình được cải tiến như sau:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
public class Animation2 {
 
    public static void main( String[] args ) {
 
	Animation2 gui = new Animation2();
	gui.go();
 
    }
 
    private void go() {
 
	JFrame frame = new JFrame();
	frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
 
	panel_ = new MyPanel();
	frame.getContentPane().add( panel_, BorderLayout.CENTER );
 
	button_ = new JButton( "start animation" );
	button_.addActionListener( new StartAnimationAction() );
	frame.getContentPane().add( button_, BorderLayout.SOUTH );
 
	frame.setSize( 500, 500 );
	frame.setVisible( true );
 
    }
 
    class MyPanel extends JPanel {
 
	public void paintComponent( Graphics g ) {
 
	    g.setColor( Color.white );
	    g.fillRect( 0, 0, this.getWidth(), this.getHeight() );
 
	    g.setColor( Color.green );
	    g.fillOval( x_, y_, 40, 40 );
 
	}
 
    }
 
    class StartAnimationAction implements ActionListener {
 
	public void actionPerformed( ActionEvent e ) {
 
	    for( int i = 0; i < 400; i++ ) {
 
		x_++;
		y_++;
 
		panel_.repaint();
 
		try {
		  Thread.sleep( 10 );
		} catch( Exception ex ) { }
 
	    }
 
	}
 
    }
 
  private JPanel panel_;
  private JButton button_;
  private int x_ = 0;
  private int y_ = 0;
 
}

Phiên bản mới nhìn qua thì rất “đẹp”, nhưng thực ra nó không chạy đúng như chúng ta mong đợi! Chúng ta không nhìn thấy vòng tròn di chuyển trên panel mà chỉ thấy nó nhảy từ vị trí ban đầu đến vị trí cuối cùng, các trạng thái trung gian đã bị mất. Vậy đâu là nguyên nhân của hành vi kì lạ này?

Thực ra, khi chúng ta đặt phương thức repaint() vào trong một vòng lặp, AWT sẽ trộn các lời gọi repaint() lại với nhau và chỉ có lời gọi repaint() cuối cùng được thực hiện. Bởi vậy chúng ta không thể nhìn thấy các trạng thái trung gian của vòng tròn trên panel.

Vậy làm thế nào giải quyết vấn đề này? Một giải pháp là đưa các lời gọi repaint() sang một thread khác như sau:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
public class Animation3 {
 
    public static void main( String[] args ) {
 
	Animation3 gui = new Animation3();
	gui.go();
 
    }
 
    private void go() {
 
	JFrame frame = new JFrame();
	frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
 
	panel_ = new MyPanel();
	frame.getContentPane().add( panel_, BorderLayout.CENTER );
 
	button_ = new JButton( "start animation" );
	button_.addActionListener( new StartAnimationAction() );
	frame.getContentPane().add( button_, BorderLayout.SOUTH );
 
	frame.setSize( 500, 500 );
	frame.setVisible( true );
 
    }
 
    class MyPanel extends JPanel {
 
	public void paintComponent( Graphics g ) {
 
	    g.setColor( Color.white );
	    g.fillRect( 0, 0, this.getWidth(), this.getHeight() );
 
	    g.setColor( Color.green );
	    g.fillOval( x_, y_, 40, 40 );
 
	}
 
    }
 
    class StartAnimationAction implements ActionListener, Runnable {
 
	public void actionPerformed( ActionEvent e ) {
 
	    Thread thread = new Thread( this );
	    thread.start();
 
	}
 
	public void run() {
 
	    for( int i = 0; i < 400; i++ ) {
 
		x_++;
		y_++;
 
		panel_.repaint();
 
		try {
		  Thread.sleep( 10 );
		} catch( Exception ex ) { }
 
	    }
 
	}
 
    }
 
  private JPanel panel_;
  private JButton button_;
  private int x_ = 0;
  private int y_ = 0;
 
}

Bây giờ thì chương trình của chúng ta đã chạy ngon lành. Để giải thích cặn kẽ về vấn đề gọi repaint() nhiều lần có lẽ cần đến những hiểu biết nhất định về thread trong Java. Bởi vậy “tác giả”, với trình độ còn rất hạn chế, đành tạm thời hài lòng với giải pháp nói trên

Tài liệu tham khảo: The repaint() method and the GUI thread

Giải pháp cho vấn đề này là cài đặt vim plugin cho IDE đang sử dụng. Một IDE đang được sử dụng rộng rãi là NetBeans. Để cài đặt vim plugin cho NetBeans, vào link dưới đây để tải về file cài đặt:

http://sourceforge.net/projects/viex/

Giải nén để nhận được file start-module-myvim.nbm. Từ menu của NetBeans, chọn Tools->Plugins->Downloaded->Add Plugins rồi chọn file start-module-myvim.nbm. Chúng ta sẽ thấy biểu tượng của vim nằm bên cạnh các icon khác như trong hình dưới đây. (Chú ý hình dáng của con trỏ, chúng ta đang ở chế độ lệnh của vim).

Bây giờ thì chúng ta đã có thể tận hưởng sự tiện lợi trong việc viết code bằng vim kết hợp với những tính năng phức tạp cung cấp bởi NetBeans. Tuy nhiên, plugin này vẫn chưa hỗ trợ một số thao tác edit trong vim như

- Không tự động indent khi xuống dòng bằng phím o.

- Không hỗ trợ shift-o

- Không hỗ trợ ctrl-r (redo).

- Không hỗ trợ xoá nhiều từ liền nhau (d 2 w, d 3 w, d $,…)

Tuy nhiên với những tính năng hiện có của plugin này thì công việc lập trình trên NetBeans đã trở nên thú vị hơn rất nhiều. Hi vọng những khiếm khuyết nói trên sẽ được khắc phục trong những phiên bản sau.

Một dự án phát triển phần mềm thường trải qua các hoạt động sau đây:

- Phân tích yêu cầu.

- Thiết kế và lập trình.

- Test.

- Bảo trì.

Mỗi mô hình phát triển phần mềm đưa ra một cách tổ chức sắp xếp khác nhau của các hoạt động này.

1. Mô hình thác nước (waterfall)

Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau.

Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có thể được phát hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai đoạn trước. Tuy nhiên ,hoạt động quay lui này chỉ nên được coi là các ngoại lệ mà thôi.

Mô hình thác nước có ưu điểm là dễ quản lí. Đây chính là mô hình ưa thích của các nhà quản lí dự án. Thời gian hoàn thành dự án thường được dự báo với độ chính xác hơn so với các mô hình khác. Các tài liệu đầu ra của từng giai đoạn cũng được xây dựng đầy đủ và hệ thống hơn. Tuy nhiên mô hình này có một số nhược điểm lớn là:

- Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách hàng. Yêu cầu này hiếm khi đạt được bởi khách hàng ít khi xác định được chính xác họ muốn gì ở ngay giai đoạn đầu của dự án, sở thích của họ cũng thay đổi khá thường xuyên. Việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi của khách hàng thường mất rất nhiều công sức và phá vỡ cấu trúc của phần mềm.

- Khách hàng cần phải kiên nhẫn. Họ chỉ được tham gia vào dự án ở giai đoạn phân tích yêu cầu và test mà thôi. Ngoài ra, sản phẩm sẽ chỉ được bàn giao khi tất cả các công việc liên quan đã được hoàn thành.

Mô hình thác nước chỉ nên được sử dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ khách hàng được xác  định rõ ngay từ đầu và ít có khả năng thay đổi. Hiện nay, mô hình thác nước vẫn được sử dụng rộng rãi do tính gần gũi với các mô hình phát triển trong các ngành kĩ thuật khác.

2. Mô hình tiến hóa (Evolutionary)

Mô hình tiến hóa được đưa ra nhằm giải quyết những khó khăn gây ra do yêu cầu của khách hàng không rõ ràng hoặc hay thay đổi. Ý tưởng của mô hình này là phát triển phẩn mềm qua nhiều phiên bản, mỗi phiên bản được đưa ra lấy ý kiến khách hàng, được sửa chữa, làm mịn cho đến khi đạt được phiên bản hoàn chỉnh.

Mô hình tiến hóa: Các phiên bản 1, 2, 3 có thể rất khác nhau!

Hai kiểu mô hình tiến hóa cơ bản là:

- Khám phá và phát triển (exploratory development): Đội dự án sẽ làm việc cùng khách hàng để khám phá các yêu cầu của họ. Dự án sẽ bắt đầu trước tiên với những yêu cầu đã rõ ràng. Các đặc tính khác sẽ được thêm vào dần dần dựa trên đề nghị của khách hàng.

- Làm bản mẫu để “vứt đi” (throwaway prototyping): Mô hình này được áp dụng cho giai đoạn phân tích yêu cầu. Theo đó, đội dự án sẽ làm các bản mẫu (prototype) để lấy ý kiến khách hàng nhằm kiểm chứng và làm rõ các yêu cầu chưa rõ ràng. Khi đã có một bản yêu cầu hoàn chỉnh, giai đoạn phát triển tiếp theo có thể sử dụng mô hình thác nước.

Mô hình tiến hóa cho phép khách hàng tham gia sâu hơn vào quá trình phát triển, nhờ đó sản phẩm cuối cùng thường phản ánh chính xác mong muốn của khách hàng. Tuy nhiên, mô hình này cũng có các nhược điểm là:

- Khó khăn trong việc thiết kế: Việc phát triển qua nhiều phiên bản có thể phá vỡ kiến trúc tổng thể của phần mềm.

- Khó khăn trong việc quản lí: Các nhà quản lí thích nhìn thấy sản phẩm làm ra trong từng gian đoạn để tiện cho việc quản lí tiến độ. Ngoài ra, các tài liệu mô tả cho từng phiên bản thường không được lập đầy đủ.

- Khó khăn do khách hàng gây ra: Khách hàng có thể nhầm tưởng rằng một bản mẫu có thể tốt gần như sản phẩm thật. Trong thực tế từ bản mẫu đến sản phẩm cuối cùng là một khảng cách xa. Ngoài ra khách hàng có xu hướng đưa thêm vào những yêu cầu không cần thiết.

- Khó khăn về địa lý: Mô hình tiến hóa đòi hỏi đội dự án phải ngồi gần khách hàng. Các dự án outsourcing khó có thể đáp ứng yêu cầu này.

Theo Ian Sommerville trong cuốn “Software Engineering“, mô hình tiến hóa là mô hình phù hợp nhất cho các dự án vừa và nhỏ (dưới 500 000 dòng code). Các dự án lớn và phức tạp nên sử dựng một mô hình kết hợp giữa mô hình thác nước và tiến hóa. Trong đó, các bản mẫu được dùng để làm rõ các yêu cầu của khách hàng. Các yêu cầu đã rõ ràng được tiếp tục phát triển theo mô hình thác nước. Các yêu cầu chưa rõ ràng có thể sử dụng mô hình khám phá và phát triển.

3. Mô hình tăng trưởng (Incremental)

Mô hình tăng trưởng kết hợp những ưu điểm của mô hình thác nước và mô hình tiến hóa. Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng trưởng (được gọi là các increments) và phát triển, bàn giao chúng lần lượt cho khách hàng theo mức độ quan trọng. Phần tăng trưởng nào đến lượt được phát triển thì những yêu cầu tương ứng sẽ được phân tích. Chỉ những thay đổi từ phía khách hàng cho những phần chưa được phát triển mới được chấp nhận.

Theo Ian Sommerville, mỗi phần tăng trưởng không nên quá 20 000 dòng code và phải mang lại những lợi ích nhất định cho khách hàng. Còn theo Mike Cotterell và Bob Hughes trong “Software Project Management”, mỗi phần tăng trưởng nên chiếm từ 1% đến 5% của toàn dự án và không nên kéo dài quá một tháng.

Mô hình tăng trưởng có những ưu điểm sau đây:

- Rút ngắn thời gian chờ đợi của khách hàng. Khách hàng không phải đợi đến khi toàn bộ hệ thống hoàn thành mới được hưởng lợi. Những thành phần quan trọng nhất được bàn giao sớm và mang lại lợi ích sớm hơn cho khách hàng.

- Tăng chất lượng phần mềm. Thành phần quan trọng nhất của hệ thống được phát triển và đi vào hoạt động sớm nhất, bởi vậy nó được test nhiều nhất. Ngoài ra, những ý kiến của khách hàng cũng như kinh nghiệm phát triển các thành phần trước sẽ được áp dụng ngay lập tức cho các thành phần sau.

- Giảm bớt những yêu cầu không cần thiết từ khách hàng. Khi một tính năng chưa có mặt trong hệ thống, họ sẽ nghĩ rằng nó sẽ được tích hợp vào ở những lần bàn giao tiếp theo!

- Tăng năng suất lao động. Nhiều lập trình viên làm việc tốt hơn trong các dự án nhỏ mà họ sớm nhìn thấy thành quả lao động của mình.

Tuy nhiên, mô hình tăng trưởng cũng có nhược điểm là không phải dự án nào cũng có thể được phân chia thành các phần tăng trưởng nhỏ có thể được phát triển và bàn giao tuần tự. Nếu làm không tốt giai đoạn lập kế hoạch và phân tách hệ thống, xung đột giữa các thành phần có thể nảy sinh.

Các biến thể của mô hình tăng trưởng là Agile Development và Extreme Programming.

Ngoài các mô hình phát triển phần mềm cơ bản nói trên còn có các mô hình biến thể như mô hình chữ V (V-model), mô hình xoáy ốc (spiral) hay mô hình tái sử dụng CBSE (component-based software engineering).

Tài liệu tham khảo:

• “Software Engineering” của Ian Sommerville
• “Software Engineering: A practitioner’s Approach” của Pressman
• “Software Project Management” của Cotterell và Hughes

Linked list basic

Khai báo linked list:

struct node {
     int data;
     struct node* next;
};
struct node* head;

Hàm length() lấy số phần tử của danh sách

/*
 Given a linked list head pointer, compute
 and return the number of nodes in the list.
*/
int Length(struct node* head) {
    struct node* current = head;
    int count = 0;
    while (current != NULL) {
        count++;
        current = current->next;
    }
    return count;
}

Duyệt danh sách sử dụng một con trỏ local

struct node* current = head;
while (current != NULL) {
    // do something with *current node
    current = current->next;
}

Linked List Building

3 bước để thêm một node vào đầu linked list

struct node* newNode;
newNode = malloc(sizeof(struct node));
newNode->data = data_client_wants_stored;

newNode->next = head;

head = newNode;

Hàm Push()

Có vẻ từ 3 bước trên thì việc viết hàm Push() để thêm một node vào đầu danh sách rất dễ dàng. Hãy xem hàm sau và tìm chỗ sai trước khi xem lời giải.

void WrongPush(struct node* head, int data) {
     struct node* newNode = malloc(sizeof(struct node));
     newNode->data = data;
     newNode->next = head;
     head = newNode;
}

Thực ra sai ở dòng

head = newNode; // NO this line does not work!

Hãy sửa lại hàm Push() trước khi xem tiếp.

/*
Takes a list and a data value.
Creates a new link with the given data and pushes
it onto the front of the list.
The list is not passed in by its head pointer.
Instead the list is passed in as a "reference" pointer
to the head pointer -- this allows us
to modify the caller's memory.
*/
void Push(struct node** headRef, int data) {
     struct node* newNode = malloc(sizeof(struct node));
     newNode->data = data;
     newNode->next = *headRef; // The '*' to dereferences back to the real head
     *headRef = newNode;          
}

Với C++ thì có hỗ trợ truyền tham chiếu (reference &) vào hàm, nên hàm Push có thể viết như sau với C++

/*
 Push() in C++ -- we just add a '&' to the right hand
 side of the head parameter type, and the compiler makes
 that parameter work by reference. So this code changes
 the caller's memory, but no extra uses of '*' are necessary -- 
 we just access "head" directly, and the compiler makes that
 change reference back to the caller.
*/
void Push(struct node*& head, int data) {
     struct node* newNode = malloc(sizeof(struct node));
     newNode->data = data;
     newNode->next = head; // No extra use of * necessary on head -- the compiler
     head = newNode; // just takes care of it behind the scenes.
}

Techniques

Duyệt xuống (Iterate down)

struct node* current = head;
while (current != NULL) {
     /* Do sth here */
     current = current->next;
}

Có thể thay vòng lặp bằng

for (current = head; current != NULL; current = current->next) {

Đổi một pointer bằng một tham chiếu tới pointer (reference pointer)

Nhiều hàm cần phải thay đổi con trỏ head mặc dù nó được truyền vào hàm số theo kiểu pass-by-value. Để làm điều này trong C thì hãy truyền một pointer đến head pointer thay vì chỉ truyền head pointer. Kiểu pointer chỉ đến một pointer khác thường được gọi là reference pointer.

Hãy xem hàm ChangeToNull để cho con trỏ head trỏ vào NULL

// Change the passed in head pointer to be NULL
// Uses a reference pointer to access the caller's memory
void ChangeToNull(struct node** headRef) { 
     // Takes a pointer to the value of interest
     *headRef = NULL; // use '*' to access the value of interest
}

Build list sử dụng thêm node vào đầu bằng hàm Push

Phương pháp này làm cho đoạn mã xây dựng list rất ngắn và chạy rất nhanh

struct node* AddAtHead() {
	struct node* head = NULL;
	int i;
	for (i=1; i<6; i++) {
		Push(&head, i);
	}
	// head == {5, 4, 3, 2, 1};
	return(head);
}

Build list sử dụng con trỏ tail

Cũng có thể thêm một node mới vào cuối cùng của list. Chúng ta sẽ cần một con trỏ tail trỏ vào node cuối cùng của list và trường next của nó sẽ trỏ vào null. Khi thêm một node mới vào

newNode->next = NULL;
tail->next = newNode;
tail = tail->next;

Tuy nhiên thì có một trường hợp đặc biệt khi phần tử mới thêm vào danh sách là phần tử đầu tiên của list. Hãy xem xét tiếp các kỹ thuật sau.

Build list sử dụng con trỏ tail có xử lý trường hợp đặc biệt

Khi build một danh sách bằng cách thêm một node mới vào cuối danh sách thì điểm khó là node đầu tiên phải được thêm vào head pointer và các node khác thì được thêm vào sau node cuối cùng sử dụng tail pointer. Cách đơn giản nhất để xử lý cả điều này là viết hai đoạn code riêng rẽ xử lý chúng. Đầu tiên là đoạn mã thêm vào head pointer cho phần tử đầu tiên và tiếp đó là một vòng lặp sử dụng tail pointer để thêm tất cả các node khác. Trông nó có vẻ “xấu” nhưng đơn giản và chạy nhanh.

struct node* BuildWithSpecialCase() {
	struct node* head = NULL;
	struct node* tail;
	int i;
	// Deal with the head node here, and set the tail pointer
	Push(&head, 1);	
	tail = head;
 
	// Do all the other nodes using 'tail'
	for (i=2; i<6; i++) {
		Push(&(tail->next), i); // add node at tail->next
		tail = tail->next; // advance tail to point to last node
	}
	return(head); // head == {1, 2, 3, 4, 5};
}

Build list sử dụng dummy node

Một giải pháp khác là sử dụng một dummy node tạm thời ở đầu danh sách. Dummy node sẽ đóng vai trò là phần tử đầu tiên và tất cả các node “thực sự” sẽ được thêm vào sau dummy node.

struct node* BuildWithDummyNode() {
	struct node dummy; // Dummy node is temporarily the first node
	struct node* tail = &dummy; // Start the tail at the dummy.
	// Build the list on dummy.next (aka tail->next)
	int i;
	dummy.next = NULL;
	for (i=1; i<6; i++) {
		Push(&(tail->next), i);
		tail = tail->next;
	}
	// The real result list is now in dummy.next
	// dummy.next == {1, 2, 3, 4, 5};
	return(dummy.next);
}

Ở ví dụ trên ta thấy dummy node sẽ không ở trong list khi ra khỏi hàm. Nhưng có một vài cách thể hiện linked list luôn giữ lại dummy node trong suốt quá trình sử dụng nó. Với cách tiếp cận đó thì sẽ không bao giờ có một danh sách rỗng (empty list). Thay vì đó thì danh sách luôn có một dummy node ở đầu. Tuy nhiên thì tôi không khuyến khích phương pháp tiếp cận đó. Phương án sử dụng dummy node tạm thời nên được sử dụng hơn.

Build list sử dụng tham chiếu cục bộ (local references)

Cuối cùng đây là một giải pháp rất “mẹo mực” mà không phải sự dụng dummy node. Đó là sử dụng một local “reference pointer” mà luôn trỏ vào pointer cuối cùng của list chứ không phải node cuối cùng.

struct node* BuildWithLocalRef() {
	struct node* head = NULL;
	struct node** lastPtrRef= &head; // Start out pointing to the head pointer
	int i;
	for (i=1; i<6; i++) {
		Push(lastPtrRef, i); // Add node at the last pointer in the list
		lastPtrRef= &((*lastPtrRef)->next); // Advance to point to the
							// new last pointer
	}		
	// head == {1, 2, 3, 4, 5};
	return(head);
}

Kỹ thuật này rất ngắn nhưng bên trong vòng lặp thật “kinh hoàng”.

Cả hai giải pháp sử dụng temporary-dummy và reference pointer có hơi chút “không bình thường” nhưng nó rất tốt để chắc chắn rằng chúng ta hiểu về pointer bởi vì chúng sử dụng pointer theo cách “không bình thường”.

Các đoạn mã ví dụ

AppendNode()

struct node* AppendNode(struct node** headRef, int data) {
	struct node* current = *headRef;
	struct node* newNode;
	newNode = malloc(sizeof(struct node));
	newNode->data = data;
	newNode->next = NULL;
 
	// special case for length 0
	if (current == NULL) {
		*headRef = newNode;
	} else {
		// Locate the last node
		while (current->next != NULL) {
			current = current->next;
		}
		current->next = newNode;
	}
}

AppendNode() sử dụng Push()

struct node* AppendNode(struct node** headRef, int data) {
	struct node* current = *headRef;
	// special case for the empty list
	if (current == NULL) {
		Push(headRef, data);
	} else {
		// Locate the last node
		while (current->next != NULL) {
			current = current->next;
		}
		// Build the node after the last node
		Push(&(current->next), data);
	}
}

CopyList()

struct node* CopyList(struct node* head) {
	struct node* current = head; // used to iterate over the original list
	struct node* newList = NULL; // head of the new list
	struct node* tail = NULL; // kept pointing to the last node in the new list
	while (current != NULL) {
		if (newList == NULL) { // special case for the first new node
			newList = malloc(sizeof(struct node));
			newList->data = current->data;
			newList->next = NULL;
			tail = newList;
		} else {
			tail->next = malloc(sizeof(struct node));
			tail = tail->next;
			tail->data = current->data;
			tail->next = NULL;
		}
		current = current->next;
	}
	return(newList);
}

CopyList() with Push()

// Variant of CopyList() that uses Push()
struct node* CopyList2(struct node* head) {
	struct node* current = head; // used to iterate over the original list
	struct node* newList = NULL; // head of the new list
	struct node* tail = NULL; // kept pointing to the last node in the new list
	while (current != NULL) {
		if (newList == NULL) { // special case for the first new node
			Push(&newList, current->data);
			tail = newList;
		} else {
			Push(&(tail->next), current->data); // add each node at the tail
			tail = tail->next; // advance the tail to the new last node
		}
		current = current->next;
	}
	return(newList);
}

CopyList() With Dummy Node

// Dummy node variant
struct node* CopyList(struct node* head) {
	struct node* current = head; // used to iterate over the original list
	struct node* tail; // kept pointing to the last node in the new list
	struct node dummy; // build the new list off this dummy node
	dummy.next = NULL;
	tail = &dummy; // start the tail pointing at the dummy
	while (current != NULL) {
		Push(&(tail->next), current->data); // add each node at the tail
		tail = tail->next; // advance the tail to the new last node
		current = current->next;
	}
	return(dummy.next);
}

CopyList() With Local References

// Local reference variant
struct node* CopyList(struct node* head) {
	struct node* current = head; // used to iterate over the original list
	struct node* newList = NULL;
	struct node** lastPtr;
	lastPtr = &newList; // start off pointing to the head itself
	while (current != NULL) {
		Push(lastPtr, current->data); // add each node at the lastPtr
		lastPtr = &((*lastPtr)->next); // advance lastPtr
		current = current->next;
	}
	return(newList);
}

CopyList() Recursive

// Recursive variant
struct node* CopyList(struct node* head) {
	if (head == NULL) return NULL;
	else {
		struct node* newList = malloc(sizeof(struct node)); // make the one node
		newList->data = current->data;
		newList->next = CopyList(current->next); // recur for the rest
		return(newList);
	}
}

Other implementations

Hãy tham khảo thêm trong tài liệu