QUY TRÌNH SẢN XUẤT PHẦN MỀM

Ngày 03/11/2009

Bảo cáo phân tích tóm tắt quy trình sản xuất phần mềm Agile software development process, WaterFall và XP

Lập trình linh hoạt hay phát triển phần mềm linh hoạt

(Agile software development hay Agile programming)

là một cơ chế thực hiện các dự án kỹ nghệ phần mềm, cơ chế này bao gồm và khuyến khích các thay đổi mang tính tiến hóa trong toàn bộ vòng đời của dự án.

Có nhiều phương pháp phát triển phần mềm linh hoạt. Đa số các phương pháp này cố gắng cực tiểu hóa rủi ro bằng cách phát triển phần mềm trong các khung thời gian ngắn, gọi là các bước lặp, mỗi bước lặp thường trong khoảng từ 1 đến 4 tuần. Mỗi bước lặp tự nó giống như một dự án phần mềm thu nhỏ, bao gồm tất cả các tác vụ cần thiết

để cho ra nâng cấp miFni của chức năng mới: lập kế hoạch, phân tích yêu cầu, thiết kế, viết mã, kiểm thử, và viết tài liệu. Tuy một bước lặp có thể không bổ sung đủ chức năng để đảm bảo sự ra đời của sản phẩm cuối cùng, nhưng một dự án phần mềm linh hoạt nhằm đến việc cho ra phần mềm mới khi kết thúc mỗi bước lặp. Trong nhiều trường

hợp, người ta đạt được mục tiêu này. Điều này đặc biệt đúng đối với phần mềm ứng dụng web. Cuối mỗi bước lặp, bất kể kết quả như thế nào, nhóm phát triển phần mềm cũng đánh giá lại các ưu tiên của dự án.

Các phương pháp phát triển phần mềm linh hoạt nhấn mạnh tầm quan trọng của giao tiếp thời gian thực, giao tiếp trực tiếp mặt đối mặt được đánh giá cao hơn giao tiếp qua các tài liệu viết. Hầu hết các đội phát triển linh hoạt được tập trung trong một môi trường có điều kiện thuận lợi cho việc giao tiếp, và các đội này bao gồm cả các lập trình viên và các "khách hàng" của họ (khách hàng là người định nghĩa sản phẩm; họ có thể là các quản lý sản phẩm, các nhà phân tích doanh nghiệp (business analyst), hoặc các khách hàng thực sự). Đội còn có thể bao gồm cả các chuyên gia test, thiết kế tương tác, những người viết tài liệu kỹ thuật, và các quản lý.

Các phương pháp phát triển phần mềm linh hoạt còn nhấn mạnh khả năng hoạt động của phần mềm như là phương thức chính yếu để đánh giá tiến độ. Cùng với việc đánh giá cao giao tiếp trực tiếp, các phương pháp tạo ra rất ít tài liệu khi so sánh với các phương pháp khác. Điều này dẫn đến phê phán rằng các phương pháp phát triển linh hoạt không có tính kỷ luật.

I. eXtreme Programming

Mô hình 1

Mô hình 2

1. Định nghĩa

- Phát triển sản phẩm một cách nhanh chóng: Với sự phát triển hiện nay của nền kinh tế dựa trên Công nghệ thông tin, doanh nghiệp nào đưa sản phẩm ra thị trường nhanh nhất sẽ chiếm được thị phần có lợi nhất. Phương pháp XP sẽ giúp cho các nhà phát triển phần mềm rút ngắn thời gian phát triển sản phẩm.

- Phát triển sản phẩm đúng theo yêu cầu của khách hàng: thực tế cho thấy rằng nhiều sản phẩm phần mềm tuy được phát triển một cách công phu nhưng lại không đáp ứng được nhu cầu của người sử dụng. Phương pháp XP đã đưa ra các cơ chế cho phép sản phẩm phát triển luôn phù hợp với yêu cầu của người sử dụng.

2. XP được thiết lập dựa trên bốn nguyên tắc sau:

12 cách làm việc của XP

Phương pháp XP đã đề ra 12 quy cách (practices) làm việc để thực hiện các nguyên tắc phát triển phần mềm đã nêu ở trên. Theo các chuyên gia trong CNPM, các quy cách làm việc đề ra bởi XP không có gì là mới. Thực chất, những quy cách này là những kinh nghiệm hay nhất thu được trong quá trình phát triển CNPM, đặc biệt là CNPM với công nghệ hướng đối tượng.

Lập kế hoạch (Planning process)
Với XP, khách hàng tham gia trực tiếp vào quá trình lập kế hoạch phát triển phần mềm. Vai trò của khách hàng và nhóm phát triển được định ra một cách rõ ràng.

Trách nhiệm của khách hàng:

* Phân loại các user story theo mức độ quan trọng từ quan điểm người sử dụng (dựa trên giá trị kinh doanh-business value). Từ đó sẽ định ra tính năng nào cần phải phát triển và phát triển theo thứ tự như thế nào.
* Định ra thời điểm và chu kỳ bàn giao sản phẩm

Trách nhiệm của nhóm phát triển:

* Ước lượng yêu cầu kỹ thuật (để phát triển) cho từng user story (ước lượng độ phức tạp).
* Ước lượng thời gian, nhân công cũng như giá thành để phát triển từng user story.
Với sự phân công trách nhiệm như vậy, bản kế hoạch sẽ luôn thỏa mãn được yêu cầu của khách hàng cũng như nhóm phát triển.

Bàn giao từng phần (Small releases)

Theo quy cách này, nhóm phát triển sẽ phát triển dần dần phần mềm, từ đơn giản đến phức tạp. Từng phần sẽ được chuyển giao cho khách hàng để có được ngay sự phản hồi của khách hàng. Từ đó sẽ có thể điều chỉnh ngay được sản phẩm cho phù hợp với yêu cầu của khách hàng. Khách hàng cũng có điều kiện để bổ sung hay thay đổi yêu cầu phần mềm.

Tham gia trực tiếp của khách hàng (On-site customer)

Với XP, khách hàng sẽ tham gia cách trực tiếp trong suốt quá trình phát triển phần mềm. Sự tham gia này sẽ giúp cho nhóm phát triển có điều kiện tham khảo trực tiếp ý kiến của khách hàng, trao đổi về hệ thống cần được phát triển, tránh được nhầm lẫn trong cách hiểu về hệ thống cần phát triển. Mục tiêu cuối cùng là sản phẩm làm ra phù hợp với yêu cầu của khách hàng.

Lập trình đôi (Pair programming)

Tất cả các phần chương trình do một hay nhiều nhóm hai người viết. Hai người này sẽ sử dụng chung một máy tính, cùng đồng thời viết chương trình. Quy cách này sẽ giúp cho có được giải pháp lập trình tốt hơn, chương trình sẽ có chất lượng và hiệu quả hơn.

Thiết kế đơn giản (Simple design)

XP khuyến khích tìm kiếm giải pháp đơn giản khi thiết kế phần mềm. Chỉ thiết kế phần mềm thoả mãn yêu cầu hiện tại của khách hàng, không nên tìm kiếm một giải pháp cho một hệ thống tương lai. Theo đó, chỉ cần một thiết kế làm sao cho chương trình chạy được và thỏa mãn yêu cầu của khách hàng.

Tổ chức lại chương trình (Refactoring)

Quan điểm của XP là chất lượng phần mềm được thể hiện bằng chất lượng của mã nguồn (code). Một chương trình được viết rõ ràng, đơn giản thì sẽ dễ bảo dưỡng và thay đổi. XP khuyến khích tổ chức (viết ) lại chương trình một cách đều đặn để nâng cao tính sáng sủa của chương trình, dễ bổ sung các chức năng mới, nâng cao hiệu suất của chương trình.

Kiểm thử (Testing)

XP yêu cầu rất cao trong khâu kiểm thử và kiểm định chương trình. Với mỗi phần của chương trình, lập trình viên phải viết chương trình kiểm thử cho phần đó trước khi thực sự bắt đầu khi viết chương trình (cho phần đó). Khách hàng sẽ chịu trách nhiệm thực hiện kiểm định sản phẩm.

Tích hợp liên tục (Continuous integration)

Việc tích hợp sẽ được tiến hành một cách liên tục. Khi một đoạn chương trình mới được phát triển, đã vượt qua phần kiểm thử, thì sẽ được tích hợp ngay vào hệ thống. Điều này sẽ giúp cho việc phát hiện và sửa lỗi thích hợp nhanh hơn và rẻ hơn. Trong một ngày có thể thực hiện nhiều lần tích hợp hệ thống.

Sở hữu tập thể (Collective ownership)

Tất cả mã nguồn đều thuộc quyền sở hữu của mọi thành viên trong nhóm phát triển. Theo đó, mã nguồn có thể được sửa đổi ngay khi cần. Với cách quản lý thông thường, mỗi phần mã nguồn thường do một người quản lý, nên khi cần sửa đổi thì phải cần sự thông qua chủ sở hữu, đôi khi điều này gây mất nhiều thời gian.

Chuẩn lập trình (Coding standards)

Để chương trình (mã nguồn) có thể hiểu được một cách dễ dàng, nhất là đối với các quy cách lập trình đôi và sở hữu tập thể, nhóm phát triển phải thống nhất cách viết chương trình. Cần phải có một quy định cụ thể, rõ ràng về cách viết (ví dụ, cách đặt tên biến, cách bổ sung chú thích, ..v.v.) để làm sao tất cả đều hiểu được.

Metaphor (Metaphor)

Nhóm phát triển XP dùng chung một hệ thống các thuật ngữ để biểu diễn hệ thống cần phát triển. Các thuật ngữ này sẽ được dùng trong khi trao đổi giữa các thành viên trong nhóm cũng như khi trao đổi với khách hàng.

II. Mô hình Waterfall

Mô hình 1

Mô hình2

1. Định nghĩa

Năm 1970, mô hình nổi tiếng và được áp dụng trong qui trình phát triển phần mềm tại phần lớn các công ty hiện nay ra đời: mô hình thác nuớc (Waterfall model). Mô hình này là kết quả của sự kết hợp các mô hình sản xuất từ các ngành kỹ thuật khác áp dụng cho công nghệ phần mềm. Mô hình Waterfall là một chuỗi qui trình phát triển như một luồng đều đặn từ trên xuống giống như một thác nước, bao gồm các giai đoạn: phân tích yêu cầu khách hàng, thiết kế, cài đặt, kiểm tra, tích hợp và bảo trì. Bạn sẽ thấy mô hình này giống hệt với qui trình xây một căn nhà: kiến trúc sư tìm hiểu yêu cầu của chủ nhà, thiết kế căn nhà, đưa cho đội ngũ thi công thực hiện, kiểm tra chất lượng và cuối cùng trao chìa khóa cho người sở hữu.

2. Waterfall được thiết lập dựa trên bốn nguyên tắc sau:

a. Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications):

là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.

b. Phân tích hệ thống và thiết kế (System Analysis and Design):

là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó.

c. Hiện thực và kiểm thử từng thành phần (Coding and Unit Test):

là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.

d. Kiểm thử (Test):

giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.

e. Cài đặt và bảo trì (Deployment and Maintenance):

đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống).