Chapter 9: Software Engineering Models and Methods

Các phương pháp và mô hình công nghệ phần mềm

1. Giới thiệu

Các phương pháp và mô hình công nghệ phần mềm đặt lên cấu trúc trong phần mềm với mục đích làm cho phần mềm hoạt động có hệ thống và vận hành ổn định. Sử dụng mô hình cung cấp cách tiếp cận đến việc giải quyết các vấn đề, ký pháp hoặc quá trình xây dựng và phân tích mô hình. Phương thức cung cấp cách tiếp cận đến những đặc tả hệ thống, thiết kế, xây dựng, kiểm thử và kiểm nghiệm của sản phẩm phần mềm cuối cùng và những sản phẩm có liên quan.

Trong chương này, chúng tôi sẽ đề cập đến bốn chủ đề chính như sau:

2. Mô hình hóa

Mô hình hóa phần mềm đang trở thành một kỹ thuật phổ biến giúp những kỹ sư phần mềm có thể hiểu, bố trí và giao tiếp các vấn đề yêu cầu của phần mềm với các bên liên quan. Các bên liên quan ở đây là những người hay nhưng nhóm có quan tâm đến phần mềm (ví dụ như: người sử dụng, người mua hàng, người thiết kế, người phát triển, kỹ sư phần mềm,v.v)

Hiện nay, có rất nhiều các ngôn ngữ mô hình hóa, ký pháp, kỹ thuật. Nhưng tất cả chúng đều có những nền tảng và những khái niệm chung. Dưới đây là những nền tảng cơ bản về những khái niệm chung đó.

2.1. Nguyên tắc Mô hình hóa

Mô hình hóa cung cấp cho các kỹ sư phần mềm cách một tiếp cận có tổ chức, có hệ thống để thể hiện những khía cạnh quan trọng của phần mềm đang được phát triển, tạo thuận lợi cho việc ra quyết định về những thành phần của phần mềm và giúp cho trao đổi thông tin với những bên liên quan trở nên dễ dàng hơn. Có ba nguyên tắc chung để để mô hình hóa. Đó là:

• Mô hình hóa những thành phần thiết yếu: Một mô hình tốt sẽ là mô hình không thể hiện tất cả các thành phần, tính năng của phần mềm dưới mọi điều kiện có thể xảy ra. Mô hình hóa sẽ thường tập trung vào những thành phần quan trọng, trọng tâm. Việc làm này sẽ làm cho mô hình được quản lý dễ dàng hơn và trở nên hữu dụng.

• Cung cấp dưới nhiều góc nhìn: Mô hình hóa cung cấp các cách tiếp cận phần mềm bằng tập các quy tắc để biểu hiện mô hình. Chúng ta có thể tiếp cận phần mềm dưới nhiều cách khác nhau, đó là: tiếp cận theo cấu trúc, tiếp cận theo hành vi, tiếp cận theo cách tổ chức,… Các thông tin thể hiện ở các cách tiếp cận đó có thể là ký pháp, từ vựng, phương thức hoặc công cụ,…

• Hỗ trợ trao đổi thông tin hiệu quả: Mô hình hóa được thể hiện bằng các từ vựng, ngữ nghĩa và các ngôn ngữ mô hình hóa khác nhau. Nhưng phải đảm bảo được khi sử dụng chúng, thì mô hình phải trở nên dễ dàng tiếp cận đối với những bên liên quan.

2.2. Tính chất và cách thể hiện mô hình

Có ba tính chất để mô tả các đặc điểm của mô hình, đó là:

• Tính toàn vẹn: thể hiện mức độ mà các yêu cầu phần mềm đã được thực thi và xác nhận bằng mô hình.
• Tính nhất quán: thể hiện mức độ của mô hình không tồn tại các trường hợp mâu thuẫn về yêu cầu, ràng buộc hoặc mô tả các thành phần bên trong phần mềm,…
• Tính đầy đủ: thể hiện mức độ đúng đắn của mô hình đối với các đặc tả thiết kế, yêu cầu và không còn tồn tại các chỗ sai (free of defects).

Mô hình được xây dựng để đại diện cho các đội tượng thực tế, và những hành vi của chúng thể hiện cho cách thức phần mềm hoạt động dự kiến.Cách sơ cấp nhất để thể hiện các thành phần của một mô hình đó là sử dụng thực thể. Một thực thể là đại diện cho các sự vật cụ thể như: tiến trình (processor), cảm biến (sensor), robots. Các thực thể sẽ được liên kết với như bằng các đường thẳng liên kết, các ký pháp, hình ảnh. Cách tốt nhất để có thể thể hiện các mô hình đó là sử dụng hình ảnh gắn liền với mô hình đó. Như vậy, khi nhìn vào hình ảnh của mô hình, ta có thể biết ngay được ý nghĩa của mô hình là để làm gì.

2.3. Cú pháp, ngữ nghĩa và tính khả dụng.

Mô hình có thể dễ dàng bị hiểu nhầm một cách ngạc nhiên. Thực thế cho thấy rằng, một mô hình là một khái niệm trừu tượng với sự thiếu sót thông tin có thể dẫn người xem có cảm giác sai lệch của việc hoàn toàn hiểu rằng phần mềm là từ một mô hình duy nhất.

Rất khó khăn để có thể hiểu được ý nghĩa chính xác cấu trúc của một mô hình. Các ngôn ngữ mô hình hóa được định nghĩa bởi các quy tắc cú pháp và ngữ nghĩa.

Cú pháp

• Đối với ngôn ngữ văn bản, cú pháp được định nghĩa bằng cách sử dụng các ký hiệu ngữ pháp để định nghĩa các cấu trúc hợp lệ. Ví dụ: ta vẫn thường sử dụng ký hiệu BFS để định nghĩa cho giải thuật Breath First Search chẳng hạn.
• Đối với mô hình hóa bằng đồ họa, cú pháp được định nghĩa bằng cách sử dụng những mô hình hình ảnh để thể hiện, chúng được gọi là siêu mô hình (metamodels). Siêu mô hình này sẽ định nghĩa cách xây dựng lên được một mô hình hợp lệ.

Ngữ nghĩa

Ngữ nghĩa cho các ngôn ngữ mô hình hóa là việc chỉ ra ý nghĩa gắn liền với các thực thể và các mối quan hệ ở trong một mô hình.

Tính khả dụng

Như trong thực tế, lựa chọn ngôn ngữ mô hình hóa để có thể hiểu rõ nhất về ngữ nghĩa của mô hình phần mềm một cách cụ thể và cách mà ngôn ngữ mô hình hóa sử dụng để thể hiện các thực tể và mỗi quan hệ bên trong các mô hình đó. Ý nghĩa của mô hình vẫn được thể hiện ran gay cả khi thông tin không được đầy đủ. Như vậy, tính khả dụng của mô hình là mô hình cần phải thể hiện được ý nghĩa và đảm bảo sự trao đổi thông tin hiệu quả giữa các kỹ sư phần mềm trong quá trình phát triển

2.4. Tiền điều kiện, hậu điều kiện và khả năng bất biến

Khi mô hình hóa các hàm hoặc phương thức của một phần mềm, các kỹ sư phần mềm thuờng bắt đầu với tập các giả định về trạng thái của phần mềm trước, trong và sau khi hàm/phương thức được thực thi. Những giả định này là cần thiết để có thể vận hành đúng chức năng của các hàm/phương thức và chúng được nhóm lại thành ba nhóm đó là: Tiền điều kiện, hậu điều kiện và bất biến đổi .

Tiền điều kiện: là tập các điều kiện cần phải được đảm bảo trước khi thực thi các hàm/phương thức để nhận được kết quả đúng. Nếu các điều kiện này không được xem xét trước khi thực thi hàm/phương thức thì sẽ gây ra kết quả không chính xác.

Hậu điều kiện: là tập các điều kiện sẽ đạt được sau khi các hàm/phương thức được thực thi thành công. Hậu điều kiện sẽ thể hiện sự thay đổi trạng thái của phần mềm về các tham số, giá trị,…

Bất biến: là tập các điều kiện không bị thay đổi ngay cả trước và sau khi thực thi hàm/phương thức.

3. Các loại mô hình

Một mô hình (model) tiêu biểu bao gồm tập các mô hình con. Mỗi mô hình con là một mô tả bộ phận và được tạo ra với một mục đích cụ thể, rõ ràng. Nó có thể bao gồm một hay nhiều biểu đồ (diagrams). Tập các mô hình con được thiết kế bằng một hay nhiều loại ngôn ngữ mô hình hóa. Ngôn ngữ mô hình hóa UML (Unified Modeling Language) cho phép thiết kế nhiều loại biểu đồ của mô hình. Sử dụng những biểu đồ này cùng với ngôn ngữ mô hình hóa mang tới ba loại mô hình phổ biến: mô hình thông tin (information models), mô hình hành vi (behavioral models), mô hình cấu trúc (structure models).

3.1 Mô hình thông tin

Mô hình thông tin cung cấp một góc nhìn tập trung vào dữ liệu và thông tin. Một mô hình thông tin là một thể hiện trừu tượng mà xác định và định nghĩa tập các khái niệm, đặc tính, mối quan hệ và ràng buộc trên thực thể dữ liệu. Mô hình thông tin ngữ nghĩa hay mô hình thông tin khái niệm thường được dùng để cung cấp vài hình thức và khung cảnh tới phần mềm đang được mô hình hóa như góc nhìn từ mặt vấn đề mà không quan tâm tới việc thực tế mô hình này được ánh xạ tới việc cài đặt phần mềm. Mô hình thông tin ngữ nghĩa hoặc mô hình thông tin khái niệm là một trừu tượng hóa và chỉ gồm định nghĩa, thuộc tính, quan hệ và ràng buộc cần để định nghĩa góc nhìn thật của thông tin. Sau sự biến đổi của mô hình thông tin ngữ nghĩa hoặc mô hình thông tin khái niệm là sự xây dựng mô hình dữ liệu logic và sau đó và mô hình dữ liệu vật lý như sự cài đặt trong phần mềm.

3.2 Mô hình hành vi

Mô hình hành vi xác định và định nghĩa chức năng của phần mềm đang được mô hình hóa. Mô hình hành vi thường gồm ba dạng cơ bản: máy trạng thái, mô hình dòng điều khiển, mô hình dòng dữ liệu. Máy trạng thái cung cấp một mô hình phần mềm như tập của các trạng thái, sự kiện và phép chuyển đổi đã được định nghĩa. Phần mềm chuyển đồi từ một trạng thái tới trạng thái tiếp bởi một sự kiện chắc chắn hay không chắc chắn gây ra mà xuất hiện trong môi trường đã được mô hình. Mô hình dòng điều khiển thể hiện làm sao mà một chuỗi các sự kiện làm cho quá trình được hoạt động hay ngừng hoạt động. Hình vi trong dòng dữ liệu cụ thể là một chuỗi các bước mà dữ liệu chuyển qua quá trình hướng nơi lưu trữ dữ liệu.

3.3 Mô hình cấu trúc

Mô hình cấu trúc thể hiện cấu tạo vật lý hay cấu tạo logic của phần mềm từ nhiều phần của phần mềm. Mô hình hóa cấu trúc thiết lập nên một bao ngoài giữa phần mềm đang được cài đặt hay mô hình với môi trường mà nó thực thi. Vài cấu trúc xây dựng cụ thể được sử dụng trong việc mô hình hóa cấu trúc là tổng hợp, phân tích, tổng quát hóa, cụ thể hóa thực thể; xác định các mối quan hệ và yếu tố liên quan giữa các thực thể; và định nghĩa của quy trình hay giao diện chức năng. Biểu đồ cấu trúc cung cấp bởi UML cho việc mô hính hóa cấu trúc gồm: biểu đồ lớp, biểu đồ thành phần, biểu đồ đối tượng, biểu đồ triển khai, biểu đồ gói (packaging diagram).

4. Phân tích mô hình

Quá trình phát triển mô hình tạo điều kiện cho kỹ sư phần mềm một cơ hội để học, suy luận và hiểu cấu trúc, chức năng, cách sử dụng chức năng và xem như sự liên kết với phần mềm. Phân tích các mô hình đã xây dựng là cần thiết để đảm bảo những mô hình này hoàn thiện, nhất quán và chính xác đủ để phục vụ mục đích của nó cho người yêu cầu. Tiếp theo là mô tả ngắn về các kỹ thuật phân tích thường dùng với mô hình phần mềm để đảm bảo kỹ sư phần mềm và một số người yêu cầu liên quan có được những lợi ích phù hợp từ việc phát triển và sử dụng phần mềm.

4.1 Phân tích sự hoàn thiện

Để có được phần mềm hoàn toàn đáp ứng nhu cầu của người yêu cầu, tính hoàn thiện là cực quan trọng từ quá trình lấy yêu cầu tới việc cài đặt mã nguồn. Tính hoàn thiện là mức độ mà tất cả các yêu cầu đã được chỉ ra được cài đặt và kiểm chứng. Mô hình có thể kiểm tra sự hoàn thiện bởi các công cụ mô hình mà sử dụng kỹ thuật như phân tích cấu trúc và phân tích khả năng đạt tới không gian trạng thái (đảm bảo tất cả các đường đi trong mô hình trạng thái đều đạt được bởi vài tập đầu vào chính xác); mô hình cũng có thể được kiểm tra sự hoàn thiện bằng tay bởi việc sử dụng kỹ thuật duyệt (inspection) hay các kỹ thuật xem xét lại (review) khác. Lỗi và cảnh báo sinh ra bởi những công cụ phân tích này và được tìm thấy bởi việc duyệt hay xem xét lại thể hiện xác suất cần hành động sử lại để đảm bảo sự hoàn thiện của mô hình.

4.2 Phân tích sự nhất quán

Sự nhất quán là mức độ mà mô hình chứa các xung đột về yêu cầu, quyết định, rằng buộc, chức năng hay mô tả các thành phần. Điển hình, kiểm tra sự nhất quán là sử dụng một chức năng phân tích tự động với các công cụ mô hình hóa, mô hình cũng có thể được kiểm tra bằng tay sự nhất quán bằng kỹ thuật duyệt hay các kỹ thuật xem xét khác. Cũng như với sự hoàn thiện, lỗi và cảnh báo được sinh ra bởi những công cụ phân tích này và tìm thấy khi duyệt hay xem xét thể hiện cần có hành động sửa chữa những lỗi này.

4.3 Phân tích sự đúng đắn

Sự đúng đắn là mức độ mà một mô hình thỏa mãn tài liệu yêu cầu phần mềm và tài liệu thiết kế, đồng thời cũng không có lỗi và trên hết là đáp ứng được nhu cầu của khách hàng. Phân tích sự đúng đắn gồm việc kiểm tra sự đúng đắn về ngữ pháp của mô hình (là sự sử dụng ngôn ngữ mô hình hóa đúng ngữ pháp và cấu trúc) và kiểm tra sự đúng đắn về ngữ nghĩa của mô hình (là sử dụng ngôn ngữ mô hình hóa để thể hiện đúng đắn ý nghĩa của đối tượng đang được mô hình hóa). Để phân tích mô hình cho cả sự đúng đắn về ngữ pháp và ngữ nghĩa, có thể sử dụng các công cụ tự động (như là sử dụng công cụ mô hình để kiểm tra sự đúng đắn về ngữ pháp của mô hình) hay bằng tay (sử dụng sự kỹ thuật duyệt hay các kỹ thuật xem xét khác) để tìm ra các lỗi có thể và thực hiện sửa lỗi này trước khi phần mềm được đưa ra thực tế sử dụng.

4.4 Khả năng lần vết (traceability)

Phát triển phần mềm thường gồm việc sử dụng, tạo ra và sửa chữa rất nhiều sản phẩm như tài liệu kế hoạch, tài liệu về quy trình sử dụng, yêu cầu phần mềm, biểu đồ, thiết kế, mã giả, bản viết tay và các công cụ sinh mã nguồn tự động, các test case tự động hay bằng tay cùng các báo cáo, file và dữ liệu. Những sản phẩm này có thể quan hệ, liên kết qua nhiều mối quan hệ phụ thuộc (ví dụ như sử dụng, cài đặt và kiểm thử). Khi phần mềm được phát triển, quản lý, bảo trì hay mở rộng, ta cần sự ánh xạ và điều khiển những mối quan hệ có thể phải lần vết này để thể hiện yêu cầu phần mềm là nhất quán với mô hình phần mềm và nhiều tài liệu khác. Sử dụng khả năng lần vết thường cải thiện sự quản lý các sản phẩm phần mềm và qui trình quản lý chất lượng phần mềm. Nó cũng cung cấp sự đảm bảo cho khách hàng rằng tất cả yêu cầu đều được thỏa mãn. Khả năng lần vết cho phép phân tích sự thay đổi một khi phần mềm đã được triển khai sử dụng thực tế, vì các mối quan hệ giữa các sản phẩm phần mềm có thể dễ dàng lần ngược để đánh giá mức độ ảnh hưởng. Công cụ mô hình hóa thường cung cấp vài phương tiện tự động hay bằng tay để chỉ rõ và quản lý khả năng lần vết sự liên kết giữa yêu cầu, thiết kế, mã nguồn và/hoặc các thực thể test như là sự thể hiện trong mô hình và các sản phẩm phần mềm khác.

4.5 Phân tích sự tương tác

Phân tích sự tương tác tập trung vào quan hệ giao tiếp hoặc quan hệ luồng điều khiển giữa các thực thể để hoàn thiện một nhiệm vụ hay một chức năng cụ thể trong mô hình phần mềm. Sự phân tích này đánh giá các hành vi động của tương tác giữa các phần khác nhau của mô hình phần mềm, gồm các tầng phần mềm khác (như lớp hệ điều hành, lớp giữa, lớp ứng dụng). Trong vài ứng dụng phần mềm, việc đánh giá tương tác giữa phần mềm ứng dụng trên máy tính và giao diện người dùng của phần mềm cũng là quan trọng. Vài môi trường mô hình hóa phần mềm cung cấp sự mô phỏng các nhân tố để nghiên cứu các mặt của các hành vi động của phần mềm được mô hình hóa. Qua bước mô phỏng sẽ cung cấp một lựa chọn phân tích cho kỹ sư phần mềm để xem lại thiết kế tương tác và đảm bảo rằng các phần khác nhau của phần mềm làm việc được với nhau và cung cấp những chức năng mong muốn.

5. Các phương pháp phát triển phần mềm

Các phương pháp phát triển phần mềm cung cấp cách tiếp cận hệ thống và có tổ chức để phát triển một phần mềm hoàn thiện. Có rất nhiều phương pháp phát triển phần mềm hiện nay, điều quan trọng là các kỹ sư phần mềm phải chọn một hoặc một số phương pháp phù hợp cho nhiệm vụ phát triển cụ thể. Sự lựa chọn này sẽ có ảnh hưởng lớn tới sự thành công của dự án. Việc sử dụng những phương pháp phát triển phần mềm kèm theo các công cụ và nhân sự có kỹ năng cho phép các kỹ sư phần mềm thể hiện trực quan chi tiết của phần mềm cần hoàn thiện, từ đó chuyển hóa thành code và dữ liệu.

Một số phương pháp phát triển phần mềm chọn lọc sẽ được thảo luận dưới đây. Các chủ đề được tổ chức thành 4 nhóm: Nhóm các phương pháp suy nghiệm, Nhóm các phương pháp hình thức, Nhóm các phương pháp tạo bản mẫu, Nhóm các phương pháp Agile.

5.1. Các phương pháp suy nghiệm

Các phương pháp suy nghiệm là những phương pháp phát triển phần mềm dựa vào kinh nghiệm, gồm những phương pháp đã và đang được sử dụng rộng rãi thực tế trong ngành công nghiệp phần mềm.

Nhóm phương pháp này gồm 3 mục lớn: các phương pháp phân tích và thiết kế theo cấu trúc, các phương pháp mô hình hóa dữ liệu và các phương pháp phân tích thiết kế hướng đối tượng.

• Các phương pháp phân tích và thiết kế theo cấu trúc: Mô hình phần mềm được phát triển chủ yếu từ góc nhìn chức năng hay hành vi, bắt đầu từ cái nhìn mức độ cao của phần mềm, sau đó dần được phân tách thành các phần nhỏ hơn hoặc tinh lọc thông qua các bước thiết kế chi tiết hơn. Thiết kế chi tiết cuối cùng sẽ thể hiện những đặc tả hoặc chi tiết ở mức rất cụ thể của phần mềm. Những thành phần này sau đó sẽ được lập trình, build, kiểm thử và kiểm tra.

• Phương pháp mô hình hóa dữ liệu: Mô hình dữ liệu được xây dựng từ góc nhìn dữ liệu hoặc thông tin được sử dụng. Các bảng và các mối quan hệ dữ liệu định nghĩa ra mô hình dữ liệu. Phương pháp mô hình hóa dữ liệu này được sử dụng trong việc định nghĩa và phân tích yêu cầu dữ liệu, hỗ trợ thiết kế cơ sở dữ liệu hay kho dữ liệu, thường thấy trong những phần mềm mà dữ liệu được quản lý như một tài nguyên hệ thống nghiệp vụ.

• Phương pháp phân tích thiết kế hướng đối tượng: Mô hình hướng đối tượng được thể hiện như một tập hợp các đối tượng, chứa dữ liệu và các mối quan hệ, tương tác với nhau thông qua các phương thức. Các đối tượng có thể là các vật thật hoặc ảo. Mô hình phần mềm được xây dựng theo phương pháp này sử dụng các biểu đồ để thể hiện những góc nhìn chọn lọc của phần mềm. Quá trình tinh lọc dần những mô hình tổng quát sẽ tạo ra bản thiết kế chi tiết cho phần mềm. Thiết kế chi tiết sau đó sẽ được lập trình và đóng gói thành những sản phẩm cuối cùng, sử dụng cho việc phát hành và triển khai.

Ví dụ: : phương pháp phân tích thiết kế hướng đối tượng

Yêu cầu: thiết kế chức năng đăng ký môn học

Các biểu đồ thiết kế:

5.2. Các phương pháp hình thức

Các phương pháp hình thức là những phương pháp phát triển phần mềm trong đó việc đặc tả, phát triển và kiểm tra phần mềm được thực hiện thông qua việc ứng dụng ngôn ngữ và ký hiệu toán học một cách chặt chẽ. Thông qua việc sử dụng ngôn ngữ đặc tả, mô hình phần mềm có thể được kiểm tra về tính nhất quán, tính hoàn thiện, tính đúng đắn một cách hệ thống và tự động hoặc bán tự động. Chủ đề này thường liên quan tới mục phân tích hình thức trong khi tìm hiểu yêu cầu phần mềm.

Trong mục này, chúng ta sẽ tìm hiều về Ngôn ngữ đặc tả, Tinh lọc và chuyển hóa chương trình, Kiểm tra hình thức và Suy diễn logic.

• Ngôn ngữ đặc tả: Ngôn ngữ hình thức cung cấp cơ sở toán học cho phương pháp hình thức. Các ngôn ngữ hình thức là ngôn ngữ máy tính bậc cao, ở dạng hình thức, được sử dụng trong suốt giai đoạn đặc tả, phân tích yêu cầu và thiết kế để miêu tả hành vi đầu vào/đầu ra. Ngôn ngữ hình thức không phải là ngôn ngữ có thể chạy trực tiếp, chúng thường bao gồm những ký hiệu, cấu trúc và ngữ nghĩa cho các ký hiệu đó và một tập hợp các mối quan hệ cho phép của các đối tượng.

• Tinh lọc và chuyển hóa chương trình: Tinh lọc chương trình là một quá trình tạo ra đặc tả mức thấp, mức chi tiết hơn thông qua một chuỗi biến đổi. Nó là những chuỗi biến đổi liên tục mà từ đó những kỹ sư phần mềm có thể chuyển hóa thành dạng chạy được của chương trình. Những đặc tả có thể sẽ được tinh lọc, thêm chi tiết cho tới khi mô hình có thể được công thức hóa bằng ngôn ngữ lập trình thế hệ thứ 3 hoặc bằng thành phần chạy được trong ngôn ngữ hình thức được chọn. Việc tinh lọc đặc tả được làm bằng việc định nghĩa những đặc tả với các thuộc tính ngữ nghĩa chính xác; những đặc tả không chỉ phải dựng lên mối quan hệ giữa những thực thể mà còn phải thể hiện ý nghĩa chính xác của những mối quan hệ và quá trình hoạt động đó.

• Kiểm tra hình thức: Kiểm tra mô hình là một phương pháp kiểm tra hình thức; nó thường liên quan tới việc phân tích trạng thái để thể hiện rằng thiết kế phần mềm có hoặc đảm bảo những thuộc tính nhất định. Một ví dụ của kiểm tra mô hình là việc phân tích xem hành vi của chương trình có đúng không trong trường hợp đan xen các sự kiện hoặc tin nhắn đến. Việc sử dụng kiểm tra hình thức đòi hỏi mô hình phần mềm và môi trường hoạt động được đặc tả một cách chính xác; mô hình này thường được biểu diễn dưới dạng một máy trạng thái hoặc máy tự động.

• Suy diễn logic: Suy diễn logic là một phương pháp thiết kế phần mềm liên quan tới việc đặc tả tiền điều kiện, hậu điều kiện quanh một khối thiết kế, sử dụng logic toán học, phát triển những bằng chứng để thể hiện rằng những tiền điều kiện và hậu điều kiện đó đảm bảo cho tất cả các trường hợp đầu vào. Nó cung cấp cho các kỹ sư phần mềm một cách để dự đoán hành vi mà không cần phải chạy phần mềm.

Ví dụ: ngôn ngữ đặc tả Z-notation

Yêu cầu:

Cách thức mô tả:

5.3. Các phương pháp tạo bản mẫu

Tạo bản mẫu phần mềm là một hoạt động tạo ra những phiên bản ít chức năng và chưa hoàn thiện của ứng dụng phần mềm, thường được sử dụng để thử nghiệm những tính năng mới xác định, lấy yêu cầu phần mềm hoặc giao diện người dùng, hoặc cao hơn là thăm dò yêu cầu phần mềm, thiết kế phần mềm hoặc những lựa chọn cài đặt và những thông tin hữu ích khác về phần mềm. Kỹ sư phần mềm lựa chọn phương pháp tạo bản mẫu để tìm hiểu những khía cạnh hoặc những thành phần còn chưa được hiểu rõ của phần mềm đầu tiên; cách tiếp cận này ngược với việc phát triển thông thường là phát triển những thành phần đã rõ trước tiên. Về cơ bản, những sản phẩm mẫu sẽ không trở thành sản phẩm phần mềm cuối được nếu không được làm lại hoặc cải thiện một cách đáng kể.

Phần này sẽ thảo luận về các phong cách, mục tiêu và kỹ thuật đánh giá bản mẫu một cách ngắn gọn.

• Phong cách tạo bản mẫu: Có nhiều cách tiếp cận để phát triển bản mẫu. Các bản mẫu có thể được phát triển như là code dùng một lần hoặc sản phẩm giấy, như là một sự tiến hóa từ một bản thiết kế đang sử dụng, hoặc như là một đặc tả chương trình có thể chạy được. Những quá trình quản lý vòng đời bản mẫu khác nhau được sử dụng cho các phong cách bản mẫu khác nhau. Việc lựa chọn phong cách bản mẫu có thể dự vào loại kết quả mà dự án cần, chất lượng của kết quả hoặc độ cấp bách của kết quả.

• Mục tiêu tạo bản mẫu: Mục tiêu của hoạt động tạo bản mẫu là để tạo ra sản phẩm cụ thể đúng với yêu cầu. Những ví dụ về mục tiêu tạo bản mẫu bao gồm: đặc tả yêu cầu, các thành phần thiết kế kiến trúc, một thuật toán, hoặc một giao diện người dùng.

• Kỹ thuật đánh giá bản mẫu: Một bản mẫu có thể được sử dụng hoặc đánh giá theo nhiều cách bởi các kỹ sư phần mềm hoặc những người tham gia dự án khác, theo hướng chủ yếu dựa vào lý do dẫn đến việc làm bản mẫu. Bản mẫu cũng có thể được đánh giá và kiểm thử dựa trên phần mềm đã được cài đặt thật hoặc dựa trên tập hợp những yêu cầu đích.

*Mô hình phát triển bản mẫu:*

5.4. Các phương pháp Agile

Những phương pháp Agile được tạo ra vào những năm 1990 từ nhu cầu cần giảm những công việc nặng nhọc tại thời điểm bắt đầu dự án của các phương pháp dựa vào kế hoạch vốn được sử dụng trong những dự án phát triển phần mềm quy mô lớn. Các phương pháp Agile được xem như là những phương pháp nhẹ nhàng, đơn giản với đặc điểm bao gồm những vòng phát triển ngắn, lặp lại, những đội tự tổ chức, thiết kế đơn giản hơn, tổ chức code lại, phát triển theo hướng kiểm thử, có sự tham gia thường xuyên của khách hàng và nhấn mạnh vào việc tạo ra những sản phẩm làm việc có thể trình diễn được sau mỗi vòng phát triển.

Có nhiều phương pháp agile được sử dụng hiện nay, trong đó những phương pháp Raid Application Development (RAD), eXtreme Programming (XP), Scrum và Feature-Driven Development (FDD) là phổ biến hơn cả.

• RAD: Phương pháp phát triển phần mềm Rapid được sử dụng chủ yếu trong việc phát triển ứng dụng hệ thống nghiệp vụ, nặng về dữ liệu. Với những công cụ phát triển cơ sở dữ liệu mục đích đặc biệt, những nhà kỹ sư phần mềm có thể phát triển, kiểm thử và triển khai những ứng dụng nghiệp vụ mới hoặc sửa đổi một cách nhanh chóng.

• XP: Cách tiếp cận này sử dụng những câu chuyện hoặc những bối cảnh cho những yêu cầu phần mềm, phát triển những bài kiểm thử trước, có sự liên hệ trực tiếp của khách hàng với đội phát triển, sử dụng lập trình theo cặp và cung cấp việc tổ chức code lại và tích hợp một cách liên tục. Những câu chuyện được phân tách nhỏ thành những nhiệm vụ, sắp xếp độ ưu tiên, ước lượng thời gian, phát triển và kiểm thử. Mỗi vòng phát triển phần mềm được kiểm thử với những bài test thủ công hoặc tự động; một vòng phát triển có thể được phát hành thường xuyên, ví dụ như một vài tuần một lần hoặc gần như vậy.

• Scrum: Cách tiếp cận agile này là thân thiện với quản lý dự án hơn cả. Người quản lý Scrum quản lý những hoạt động trong các vòng phát triển dự án; mỗi vòng phát triển được gọi là một sprint và kéo dài dưới 30 ngày. Một danh sách PBI được phát triển mà từ đó những nhiệm vụ được xác nhận, định nghĩa, sắp xếp mức độ ưu tiên và ước lượng thời gian. Mỗi phiên bản làm việc của phần mềm được kiểm thử và phát hành sau mỗi vòng phát triển. Phương pháp này sử dụng những buổi họp hàng ngày để đảm bảo công việc tiến hành đúng như kế hoạch.

• FDD: Đây là cách tiếp cận phát triển phần mềm ngắn, theo vòng phát triển, hướng mô hình gồm 5 giai đoạn:

  • Phát triển mô hình sản phẩm để giới hạn miền phát triển
  • Tạo ra danh sách những nhu cầu hay tính năng cần phát triển
  • Xây dựng lên kế hoạch phát triển các tính năng
  • Phát triển thiết kế cho những tính năng theo từng vòng phát triển cụ thể
  • Lập trình, kiểm thử và tích hợp tính năng

FDD vừa tương tự với phương pháp phát triển phần mềm gia tăng (tức phương pháp phát triển phần mềm gồm nhiều vòng phát triển nhỏ, mỗi vòng phát triển thêm các tính năng mới cho sản phẩm) vừa tương tự với phương pháp phát triển phần mềm XP, ngoại trừ việc nhiệm vụ được giao tới từng thành viên chứ không phải từng đội. FDD nhấn mạnh vào cách tiếp cận theo kiến trúc tổng thể của phần mềm, thúc đẩy việc xây dựng tính năng đúng ngay lần đầu hơn là tổ chức lại code thường xuyên.

Có nhiều dạng khác nhau của phương pháp agile trên sách vở cũng như thực tế. Cũng cần chú ý rằng luôn có nhu cầu cho những phương pháp phát triển phần mềm dựa vào kế hoạch. Ngoài ra, có những phương pháp mới được tạo ra từ việc kết hợp phương pháp Agile và phương pháp dựa vào kế hoạch: những người sử dụng cố gắng cân bằng những tính chất tốt nhất trong cả 2 phương pháp này để phục vụ nhu cầu nghiêp vụ tổ chức.