Thiết kế xử lý Công nghệ phần mềm

Danh sách thành viên:

- Lê Thị Bích Liên

- Trần Văn Tiến

- Vũ Thị Thanh

Tổng quan

Quản lý công nghệ phần mềm có thể được định nghĩa là việc áp dụng các kế hoạch hoạt động quản lý, điều phối, đo lường, giám sát, kiểm soát và báo cáo để đảm bảo rằng các sản phẩm phần mềm và dịch vụ công nghệ phần mềm được phân phối hiệu quả, và đảm bảo lợi ích của các bên liên quan. Có những khía cạnh đặc trưng trong dự án phần mềm và chu trình phát triển của phần mềm, nó làm quá trình quản lý trở nên phức tạp bao gồm:

• Khách hàng thường là người không biết những gì là cần thiết, những gì là khả thi.
• Khách hàng thường thiếu sự đánh giá cao cho sự phức tạp vốn có trong công nghệ phần mềm, đặc biệt là về tác động của việc thay đổi.
• Sự hiểu biết và điều kiện thay đổi sẽ tạo ra các yêu cầu phần mềm mới hoặc thay đổi những yêu cầu của phần mềm.
• Phần mềm thường được xây dựng sử dụng một quá trình lặp đi lặp lại chứ không phải là một chuỗi các nhiệm vụ khép kín.
• Phần mềm kỹ thuật nhất thiết phải kết hợp sáng tạo và tính kỷ luật trong quá trình phát triển phần mềm. Duy trì một sự cân bằng thích hợp giữa hai bên là đôi khi là khó khăn.
• Mức độ của sự mới mẻ và phức tạp thường cao.
• Thường có sự thay đổi công nghệ rất nhanh chóng.

Hoạt động quản lý công nghệ phần mềm xảy ra ở ba cấp độ: tổ chức và quản lý cơ sở hạ tầng, quản lý dự án và quản lý các hệ thống đo lường. Trong chương này, sẽ tìm hiểu chi tiết về quản lý dự án và quản lý các hệ thống đo lường. Các vấn đề được trình bày trong chương này bao gồm:

1.Khởi tạo và định nghĩa phạm vi

Mục tiêu của các hoạt động này là xác định hiệu quả các yêu cầu của phần mềm sử dụng các phương pháp khác nhau, và đánh giá tính khả thi của dự án từ nhiều quan điểm. Một khi tính khả thi của dự án đã được xác định, thì nhiệm vụ tiếp theo là đặc tả yêu cầu và lựa chọn quy trình xử lý cho việc ra soát và xem lại các yêu cầu.
Quá trình khởi tạo và định nghĩa phạm vi sẽ theo tuần tự như sau: Xác định và điều chỉnh yêu cầu. Nếu khả thi thì xem xét và sửa đổi các yêu cầu.

• Xác định và điều chỉnh yêu cầu dựa vào:

  • Những yêu cầu được đưa ra.
  • Điều chỉnh yêu cầu với các bên liên quan
  • Dựa vào bản đặc tả yêu cầu SRS.
  • Phần mềm làm ra đáp ứng được nhu cầu của người sử dụng.

• Để đánh giá phần mềm có tính khả thi hay không, dựa vào các tiêu chí sau:

  • Được sử dụng trong thời gian dài mà hầu hết các lỗi ban đầu của nó đã được loại bỏ.
  • Giải pháp phân tích hoạt động của quá trình phát triển phần mềm.
  • Phân tích tài chính trên chu trình phát triển phần mềm.
  • Tác động xã hội, chính trị
• Xem xét và sửa đổi yêu cầu bao gồm như:
  • Thay đổi cách quản lý trong việc xem xét và sửa đổi các yêu cầu.
  • Đánh giá khả năng thành công với những yêu cầu thay đổi.

1.1 Đàm phán và xác định các yêu cầu

Đàm phán và xác định các yêu cầu, xác định các công việc định làm. Các hoạt động bao gồm các yêu cầu về sự khám phá, phân tích, đặc điểm kỹ thuật và xác nhận. Các phương pháp và kỹ thuật cần được lựa chọn và áp dụng, xét đến các quan điểm của các bên liên quan. Điều này dẫn đến việc xác định phạm vi dự án trong đơn đặt hàng để đáp ứng mục tiêu và đảm bảo ràng buộc.

1.2 Phân tích tính khả thi

Mục đích của việc phân tích tính khả thi là để phát triển một mô tả rõ ràng về mục tiêu dự án và đánh giá các phương án khác nhau để xác định xem dự án này là một lựa chọn tốt cho những hạn chế của công nghệ, nguồn lực, tài chính, và xã hội / chính trị. Một dự án ban đầu và việc trình bày phạm vi sản phẩm, phân phối dự án, hạn chế thời gian dự án, và ước tính nguồn lực cần thiết phải được chuẩn bị. Tài nguyên bao gồm một số lượng đủ của những người có những kỹ năng cần thiết, cơ sở vật chất, cơ sở hạ tầng, và hỗ trợ [bên trong hoặc bên ngoài]. Phân tích tính khả thi thường đòi hỏi ước tính gần đúng của nỗ lực và chi phí dựa trên các phương pháp thích hợp.

1.3 Quy trình về việc xem xét và sửa đổi yêu cầu

Các bên liên quan phải thống nhất về cách thức mà các yêu cầu và phạm vi cần được xem xét và sửa đổi. Phạm vi và yêu cầu sẽ không được “ấn định chính thức” nhưng có thể và nên được xem xét lại. Nếu thay đổi được chấp nhận, sau đó một số hình thức phân tích truy xuất nguồn gốc và phân tích rủi ro nên được sử dụng để xác định tác động của những thay đổi. Có nghĩa là phạm vi yêu cầu không phải luôn luôn được ấn định mà nó có thể thay đổi. Ví dụ, có thể thêm chức năng của phần mềm dựa vào việc phân tích các yêu cầu hoặc yêu cầu của khách hàng hoặc là tại thời điểm này thì ưu tiên công việc nào trước, nó thể thay đổi không cố định. Và nếu như những thay đổi đó được chấp nhận thì phải có phương pháp phân tích rủi ro để đánh giá mức độ rủi ro của việc thay đổi, xem xét xem việc thay đổi đó có hợp lý không.

2 Kế hoạch dự án phần mềm

Giai đoạn này yêu cầu thiết lập phạm vi công việc của dự án, điều chỉnh lại mục tiêu và xác định đường đi tới mục tiêu đó.Bước đầu tiên trong việc lập kế hoạch dự án phần mềm phải được lựa chọn mô hình chu trình phát triển phần mềm, và có thể thiết kế nó dựa trên phạm vi dự án, yêu cầu dự án, và đánh giá rủi ro.

Trong tất cả các chu trình phát triển phần mềm [SDLC], đánh giá rủi ro phải được lên kế hoạch từ ban đầu dự án. Và danh sách rủi ro phải được đem thảo luận và chấp nhận bởi các bên liên quan. Quy trình và chịu trách nhiệm về việc xem xét và sửa đổi liên tục các kế hoạch dự án và các kế hoạch có liên quan cũng nên được quy định rõ ràng và thống nhất.

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.

Một kỹ sư phần mềm thể hiện tính chuyên nghiệp thông qua việc tuân thủ các quy tắc đạo đức, ứng xử nghề nghiệp tới các chuẩn và thủ tục được thiết lập bởi cộng đồng chuyên môn. Cộng đồng chuyên môn thường được đại diện bởi một hoặc nhiều tổ chức chuyên môn [hội, nhóm nghề nghiệp]. Các tổ chức này công bố các chuẩn về đạo đức và quy tắc ứng xử nghề nghiệp được biết như là các tiêu chuẩn gia nhập cộng đồng. Các tiêu chí này là cơ sở cho việc các hoạt động công nhận, cấp giấy phép và được sử dụng như một thước đo năng lực kỹ thuật.

Một kỹ sư phần mềm thể hiện tính chuyên nghiệp thông qua việc tuân thủ các quy tắc đạo đức, ứng xử nghề nghiệp tới các chuẩn và thủ tục được thiết lập bởi cộng đồng chuyên môn. Cộng đồng chuyên môn thường được đại diện bởi một hoặc nhiều tổ chức chuyên môn [hội, nhóm nghề nghiệp]. Các tổ chức này công bố các chuẩn về đạo đức và quy tắc ứng xử nghề nghiệp được biết như là các tiêu chuẩn ra nhập cộng đồng. Các tiêu chí này là cơ sở cho việc các hoạt động công nhận, cấp giấy phép và được sử dụng như một thước đo năng lực kỹ thuật.

1.1. Kiểm định, chứng nhận và giấy phép

1.1.1. Kiểm định

Kiểm định là quá trình chứng nhận năng lực, thẩm quyền hoặc sự tin cậy của một tổ chức. Các chương trình kiểm định được đảm bảo tuân thủ các tiêu chuẩn cụ thể và duy trì chất lượng nhất định. Ở nhiều nước, các kỹ sư tiếp nhận kiến thức thông qua việc hoàn thành một khoá đào tạo kiểm định. Kiểm định kỹ thuật thường được thực hiện bởi các tổ chức chính phủ như bộ giáo dục, ví dụ Trung Quốc, Pháp, Đức, Isarel, Ý và Nga. Ở Việt Nam, để hoàn thành chương trình kiểm định, các kỹ sư phải hoàn thành các khoá học tại các đơn vị đào tạo thuộc bộ giáo dục. Tuy nhiên, ở một số quốc gia khác, quá trình kiểm định tách rời khỏi chính phủ và được thực hiện bởi các hiệp hội tư nhân. Một ví dụ điển hình như ở Hoa Kỳ, kiểm định kỹ thuật được thực hiện bởi tổ chức ABET. Là một thành viên của ABET, CSAB là một tổ chức tiến hành kiểm định và công nhận các chương trình đào tạo. Tuy quá trình kiểm định có thể khác nhau, nhưng ý nghĩa chung là như nhau ở các nước.

1.1.2. Chứng nhận

Chứng nhận dùng để xác nhận các đặc tính đặc biệt của một người. Một loại chứng nhận phổ biến là chứng nhận chuyên môn, chứng nhận xác nhận một người có khả năng nhất định trong việc hoàn thành một hoạt động ở một lĩnh vực cụ thể. Chứng nhận chuyên môn cũng được dùng để xác minh khả năng của chủ sở hữu có thể đáp ứng các tiêu chuẩn chuyên môn và áp dụng các kỹ năng chuyên môn trong việc giải quyết vấn đề. Ngoài ra, các chứng chỉ chuyên môn còn được dùng để xác minh các kiến thức được theo quy định, kinh nghiệm và mức độ thành thạo các kỹ năng trong nghề nghiệp. Một kỹ sư thường có được chứng nhận chuyên môn bằng cách vượt qua một kỳ thi kết hợp với các tiêu chí dựa trên các kinh nghiệm khác. Những kỳ thi thường được quản lý bởi các tổ chức phi chính phủ, chẳng hạn như các tổ chức chuyên nghiệp. Trong kỹ nghệ phần mềm, các chứng nhận dùng để kiểm tra trình độ chuyên môn của một kỹ sư phần mềm. Ví dụ, IEEE đã ban hành 2 chương trình chứng nhận [CSDA và CSDP] được thiết kế để xác nhận kiến thức của một kỹ sư phần mềm thông qua các chuẩn kỹ năng trong kỹ nghệ phần mềm. Từ tháng 10 năm 2000, chính phủ Nhật Bản đề xuất sáng kiến chuẩn hoá kỹ năng CNTT châu Á. Theo đó, có hai loại hình chứng chỉ là kỹ sư công nghệ thông tin cơ bản [FE] và kỹ sư thiết kế và phát triển phần mềm [SW]. Để có được các chứng chỉ này các kỹ sư phải vượt qua một kỳ thi đánh giá chuẩn kỹ năng. Cho đến nay đã có 11 nước công nhận hai chuẩn trên bao gồm Nhật Bản, Ấn Độ, Trung Quốc, Việt Nam, Malaysia, Hàn Quốc, Singapore, Philipin, Thái Lan, Đài Loan và Myanmar.

1.1.3. Giấy phép

Cấp giấy phép là hành động cấp phép cho một người được thực hiện một số loại hoạt động và chịu trách nhiệm về kết quả thực hiện. Giấy phép thể hiện thông qua việc cấp phép và tài liệu ghi nhận sự cấp phép. Để có được giấy phép sử dụng đòi hỏi không chỉ đáp ứng được một số tiêu chuẩn nhất định mà còn đáp ứng các tiêu chuẩn khi thực hiện. Nói chung việc cấp giấy phép nhằm đảm bảo quyền lợi cho các kỹ sư [so với các cá nhân không đủ tiêu chuẩn]. Ở một số nước, các kỹ sư không thể thực hiện công việc như một chuyên gia nếu không được cấp giấy phép. Khắt khe hơn, với các doanh nghiệp, các công ty không được phép cung cấp “dịch vụ kỹ thuật” nếu không có ít nhất một kỹ sư được cấp phép.

1.2. Quy tắc đạo đức và ứng xử nghề nghiệp

Quy tắc đạo đức và ứng xử nghề nghiệp bao gồm các giá trị và hành vi thực hiện chuyên môn và các quyết định của một kỹ sư chuyên nghiệp phải thể hiện. Các quy tắc ứng xử nghề nghiệp được các tổ chức, hội nghề nghiệp. Các quy tắc này tồn tại trong một bối cảnh nhất định và được điều chỉnh để được số đông cộng đồng chấp nhận, phù hợp với với chuẩn mực đạo đức xã hội và luật pháp của chính quyền sở tại. Khi được thiết lập, quy tắc đạo đức và ứng xử nghề nghiệp được thực thi bởi các tổ chức chuyên môn hoặc các tổ chức theo luật định. Các hành vi vi phạm đạo đức và quy tắc ứng xửử nghề nghiệp có thể kể đến như tiết lộ thông tin bí mật, làm sai lệch thông tin, hoặc xuyên tạc khả năng của một người. Một số hành vi khác như sự thiếu sót trong việc thông báo những rủi ro hoặc không cung cấp thông tin quan trọng, không miêu tả đầy đủ quyền lợi của khách hàng. Vi phạm các quy tắc đạo đức và ứng xử nghề nghiệp có thể dẫn đến hình phạt [theo quy định] và có thể bị tước bỏ việc công nhận sự chuyên nghiệp. Một quy tắc đạo đức và ứng xử nghề nghiệp cho phần mềm kỹ thuật đã được phê duyệt bởi Hội đồng ACM và IEEE CS vào năm 1999. Theo đó: “Kỹ sư phần mềm sẽ cam kết thực hiện các quá trình trong phát triển phần mềm gồm: phân tích, đặc tả, thiết kế, phát triển, thử nghiệm và bảo trì phần mềm là một nghề mang lại lợi ích và và được tôn trọng. Phù hợp với các cam kết của họ đối với sức khỏe, an toàn và phúc lợi của công chúng, kỹ sư phần mềm phải tuân thủ các nguyên tắc liên quan đến tám nguyên tắc bao gồm sự công khai, khách hàng và sử dụng lao động, sản phẩm, phán quyết, quản lý, nghề nghiệp, đồng nghiệp và bản thân.” Sau khi các quy tắc, tiêu chuẩn được đề xuất có thể được giới thiêu, sửa đổi hoặc thay thế, các kỹ sư có trách nhiệm cập nhật và tiếp tục học tập để phù hợp với các quy tắc nghề nghiệp mới.

1.3. Tính chất và vai trò của các hội nghề nghiệp

Các tổ chức nghề nghiệp bao gồm sự kết hợp của người trong nghề và các chuyên gia, các nhà nghiên cứu. Các tổ chức này thực hiện việc xác định, đề xuất và điều tiết các ngành nghề tương ứng của tổ chưc, hội. Các hội, tổ chức nghề nghiệp giúp cộng đồng trong nghề thiết lập các tiêu chuẩn chuyên môn cũng như các quy tắc ứng xử và đạo đức nghề nghiệp. Vì lý do này, họ cũng tham gia vào các hoạt động có liên quan, bao gồm:

• Xây dựng và ban hành nội dung kiến thức chung về chuyên môn
• Kiểm định, chứng nhận và cấp giấy phép;
• Ban hành các quy tắc chung cho cộng đồng nghề
• Thúc đẩy mở rộng cộng đồng thông qua qua các hội nghị, đào tạo, và các ấn phẩm.

Tham gia vào các hội nghề nghiệp, hỗ trợ các kỹ sư trong việc duy trì và phát triển kiến thức phù hợp với chuyên môn, đồng thời mở rộng và duy trì mạng lưới nghề nghiệp của mình.

1.4. Tính chất và vai trò của các tiêu chuẩn kỹ nghệ phần mềm

Các tiêu chuẩn trong kỹ nghệ phần mềm bao gồm nhiều chủ đề nổi bật. Các tiêu chuẩn cung cấp các hướng dẫn cho việc thực hiện các pha trong quy trình phát triển phần mềm. Bằng việc thông qua các nội dung thông qua sự đồng thuận của cộng đồng về các kiến thức và kinh nghiệm trong kỹ nghệ phần mềm, các tiêu chuẩn thiết lập các hướng dẫn cơ bản cho kỹ nghệ phần mềm. Các tiêu chuẩn này có thể được tiếp tục phát triển và hoàn thiện phù hợp với các điều kiện cụ thể. Những lợi ích của việc áp dụng các tiêu chuẩn mang lại rất nhiều cải thiện chất lượng phần mềm, giúp tránh sai sót, bảo vệ cả phía nhà phát triển và người sử dụng phần mềm, gia tăng tính chuyên nghiệp và thuận lợi trong việc chuyển đổi công nghệ.

1.5. Sự tác động của phần mềm đến nền kinh tế

Phần mềm ít nhiều có các tác động đến kinh tế của từng cá nhân, doanh nghiệp và xã hội. Một phần mềm "thành công" có thể được xác định bởi sự phù hợp của một phần mềm và việc được công nhận cũng như hiệu quả của nó khi áp dụng giải quyết một vấn đề nhất định. Ở cấp độ cá nhân, việc làm của một kỹ sư có thể tuỳ thuộc vào khả năng và sự sẵn sàng của họ trong việc hiểu và thực hiện nhiệm vụ trong đáp ứng nhu cầu và mong đợi của khách hàng hoặc người sử dụng lao động. Khách hàng hoặc tình hình tài chính của chủ sử dụng lao động có thể ảnh hưởng tích cực hay tiêu cực tới việc tiêu thụ phần mềm. Ở mức độ doanh nghiệp, phần mềm được áp dụng một cách hợp lý có thể giảm thiểu thời gian làm việc và gia tăng lợi nhuận khi làm việc. Hơn nữa, với các tổ chức sử dụng hoặc cung cấp phần mềm một cách hiệu quả cũng mang lại lợi ích cho xã hội bằng việc tạo công ăn việc làm và góp phần cải thiện chất lượng dịch vụ. Tuy nhiên, các chi phí phát triển và mua phần mềm cũng có thể tương đương đương với lợi nhuận kinh doanh của doanh nghiệp. Ở cấp độ xã hội, phần mềm sử dụng việc dự đoán tai nạn, cung cấp các loại dịch vụ xã hội. Sự tác động gián tiếp của phần mềm thông qua việc hiệu quả hoặc không hiệu quả của các đơn vị cung cấp hoặc mua phần mềm dẫn đến tăng hoặc giảm năng xuất lao động xã hội. Đồng thời, phần mềm còn ảnh hưởng đến một số lĩnh vực khác của cuộc sống như trật tự xã hội, thậm trí là cả các vấn đề tài chính...

1.6. Hợp đồng lao động

Dịch vụ kỹ thuật phần mềm có thể được cung cấp theo một loạt các mối quan hệ khách hàng-kỹ sư. Các công việc trong kỹ thuật phần mềm có thể được thực hiện thông qua các nhà cung cấp dịch vụ, tư vấn kỹ thuật, thuê hoặc thậm trí thông qua các tình nguyện viên. Trong tất cả các tình huống, khác hàng và nhà cung cấp đạt được sự đồng thuận về một sản phẩm phần mềm hoặc dịch vụ được cung cấp phải thỏa mãn một số tiêu chí nhất định. Trong kỹ nghệ phần mềm, mối lo ngại chung trong hợp đồng lao động là tính bảo mật. Người sử dụng lao thu được lợi nhuận từ lợi thế thương mại của sở hữu trí tuệ, vì vậy họ buộc phải bảo vệ quyền lợi của mình bằng việc đưa ra những quy định về tính bảo mật trong hợp đồng. Vì vậy, các kỹ sư phần mềm thường được yêu cầu ký không tiết lộ hoặc đồng ý với các quy định về sở hữu trí tuệ trong công việc. Một mối quan tâm khác của quyền sở hữu trí tuệ, các tài sản liên quan tới phần mềm bao gồm sản phần, sáng chế, phát minh và các ý tưởng có thể được cất giữ bởi người sử dụng lao động, khách hàng hoặc tuân thủ theo các điều khoản đã được quy định trong hợp đồng, nếu những tài sản thu được trong thời hạn của mối quan hệ các kỹ sư phần mềm với người sử dụng lao động hoặc khách hàng. Cuối cùng, hợp đồng cũng có thể chỉ định trong số các yếu tố khác vị trí mà tại đó công việc sẽ được thực hiện; tiêu chuẩn mà công việc đó sẽ được tổ chức; cấu hình hệ thống được sử dụng để phát triển; hạn chế của các kỹ sư phần mềm và sử dụng lao động trách nhiệm; một ma trận giao tiếp và / hoặc kế hoạch từng bước; và các chi tiết hành chính như lãi suất, bồi thường, giờ làm việc, và điều kiện làm việc.

1.7. Các vấn đề về luật pháp

Các vấn đề pháp lý đáng chú ý liên quan tới kỹ nghệ phần mềm bao gồm các vấn đề liên quan đến tiêu chuẩn, thương hiệu, bằng sáng chế, bản quyền, bí mật kinh doanh, trách nhiệm pháp lý, yêu cầu pháp lý, tuân thủ luật thương mại, và tội phạm công nghệ.

1.7.1. Các chuẩn

Như đã nhắc ở phần 1.4, các tiêu chuẩn trong kỹ nghệ phần mềm cung cấp các hướng dẫn cho việc thực hiện các pha trong quy trình phát triển phần mềm. Tiêu chuẩn có chức năng định ra các yêu cầu và hỗ trợ thực hiện các yêu cầu đó trong việc thực hiện các hoạt động thường xuyên trong kỹ nghệ phần mềm. Các tiêu chuẩn được đưa ra bằng cách liệt kê các đặc tính tối thiểu của các sản phẩm và quá trình thực hiện. Vì vậy, các doanh nghiệp, tổ chức phần mềm thường áp dụng các tiêu chuẩn như là một phần của chính sách tổ chức của họ. Hơn nữa, việc tuân thủ các tiêu chuẩn là một biện pháp đề phòng các rủi ro liên quan đến pháp lý và tránh khỏi những cáo buộc phi pháp.

1.7.2. Thương hiệu

Một thương hiệu liên quan đến bất kỳ từ, tên, biểu tượng, hoặc thiết bị được sử dụng trong các giao dịch. Thương hiệu được sử dụng "để chỉ ra nguồn gốc, xuất xứ của hàng hóa". Bảo vệ thương hiệu bảo vệ tên, logo, hình ảnh, và bao bì của doanh nghiệp. Tuy nhiên, nếu tên, hình ảnh, hay tài sản thương hiệu khác sẽ trở thành một thuật ngữ chung, sau đó bảo vệ thương hiệu là vô hiệu. Tổ chức Sở hữu trí tuệ thế giới [WIPO] là cơ quan đặt ra các quy tắc và quy định về thương hiệu, nhãn hiệu hàng hoá. WIPO là cơ quan của Liên Hợp Quốc dành riêng cho việc sử dụng tài sản trí tuệ như một phương pháp thúc đẩy sự đổi mới và sáng tạo.

1.7.3. Bằng sáng chế

Bằng sáng chế bảo vệ các quyền của một nhà nhà sáng chế trong việc tạo ra và bán các ý tưởng của mình. Một bằng sáng chế bao gồm một tập hợp các đặc quyền được cấp bởi một chính phủ có chủ quyền cho một cá nhân, nhóm cá nhân, tổ chức trong một khoảng thời gian nhất định. Tài liệu để được cấp bằng sáng chế đòi hỏi phải được ghi chép một cách cẩn thận trong quá trình dẫn đến các sáng chế. Các nhà sáng chế có thể sử dụng các đại diện sáng chế [luật sư đại diện] để bảo vệ các quyền lợi hợp pháp của mình về các quy định trong luật bản quyền. Lưu ý rằng, nếu sáng chế được thực hiện trong quá trình của một hợp đồng công nghệ phần mềm, chủ sở hữu có thể thuộc về chủ nhân hay khách hàng hoặc được phối hợp tổ chức, chứ không phải thuộc về các kỹ sư phần mềm.

1.7.4. Bản quyền

Bản quyền là thuật ngữ pháp lý mô tả quyền của người sáng tạo đối với các sản phẩm, tác phẩm văn học và nghệ thuật của họ. Bảo vệ bản quyền là tự động cho dù sản phẩm này có được đăng ký hay không. Ngay khi sản phẩm được viết ra, nó đã được bảo vệ.

1.7.6. Trách nhiệm pháp lý

Các kỹ sư phần mềm phải quan tâm với các vấn đề về trách nhiệm trong chuyên môn. Với một cá nhân cung cấp dịch vụ cho khách hàng hoặc nhà tuyển dụng, điều này có vai trò quan trọng việc tuân thủ các tiêu chuẩn và các quy định chung trong chuyên môn. Do đó, trách nhiệm pháp lý giúp phía người lao động và ngừoi sử dụng lao động tránh khỏi những cáo buộc hoặc thủ tục tố tụng hoặc liên quan đến sơ suất, bất cẩn, hoặc thiếu năng lực. Đối với kỹ sư, bao gồm kỹ sư phần mềm, trách nhiệm pháp lý có liên quan đến trách nhiệm sản phẩm.

1.7.7. Yêu cầu pháp lý

Kỹ sư phần mềm phải hoạt động trong phạm vi của các khuôn khổ pháp lý địa phương, quốc gia và quốc tế. Vì vậy, các kỹ sư phần mềm phải lưu ý các yêu cầu pháp lý:

• Đăng ký và cấp giấy phép bao gồm cả kiểm tra, học vấn, kinh nghiệm, và các yêu cầu đào tạo;

• Thoả thuận trong hợp đồng;

• Các vấn đề pháp lý ngoài hợp đồng;

• Các thông tin cơ bản về khuôn khổ luật pháp quốc tế được quy định bởi tổ chức Thương mại quốc tế [WTO]

1.7.8. Tuân thủ luật thương mại

Tất cả kỹ sư phải được nhận thức hạn chế của pháp luật về nhập, xuất, tái xuất sản phẩm dịch vụ và công nghệ trong các phán quyết của mình. Các cân nhắc bao gồm kiểm soát xuất và phân loại, thu hồi giấy phép cần thiết dành cho việc sử dụng phần cứng và phần mềm, dịch vụ và công nghệ. Các kỹ sư cần được tư vấn để được hướng dẫn chi tiết các việc cần tuân thủ.

1.7.9. Tội phạm công nghệ

Một số loại tôi phạm công nghệ có thể kể đến như gian lận, truy cập trái phép, spam, nội dung khiêu dâm, xúc phạm, đe dọa, quấy rối, trộm cắp dữ liệu cá nhân nhạy cảm hoặc bí mật thương mại, và sử dụng một máy tính để gây thiệt hại hay xâm nhập vào các máy tính khác trong mạng và hệ thống điều khiển tự động. Theo luật Việt Nam có một số quy định theo các điều 224, 225, 226 Bộ luật Hình sự.Phạm tội thuộc một trong các trường hợp sau đây, thì bị phạt tù từ ba năm đến bảy năm:

Phạm tội thuộc một trong các trường hợp sau đây, thì bị phạt tù từ năm năm đến mười hai năm:

1.8. Tài liệu

Cung cấp tài liệu hướng dẫn rõ ràng, kỹ lưỡng, và chính xác là trách nhiệm của mỗi kỹ sư phần mềm. Sự đầy đủ của các tài liệu được đánh giá theo các tiêu chí khác nhau dựa trên nhu cầu của các bên yêu cầu liên quan khác nhau. Tài liệu tốt phải đạt được các tiêu chuẩn và hướng dẫn. Đặc biệt, các kỹ sư phần mềm nên làm tài liệu tài liệu:

• Có sự liên kết
• Rủi ro trọng yếu và sự cân bằng, và
• Cảnh báo về những hậu quả không mong muốn hoặc nguy hiểm từ việc sử dụng hoặc sử dụng sai của phần mềm.

2. Tương tác nhóm

2.1. Lợi thế làm việc theo nhóm

Kĩ sư phần mềm sẽ làm việc với đội phát triển dự án, cũng như với các bên liên quan khác để đảm bảo dự án đi đúng hướng và đúng tiến độ. Các bên liên quan gồm:

• Người dùng: Gồm những người sử dụng cuối của hệ thống
• Khách hàng: Gồm những người đặt hàng sản phẩm phần mềm. Họ có quyền đưa sản phẩm của họ lên các cửa hàng phần mềm
• Nhà phân tích thị trường: Gồm những người phân tích nhu cầu thị trường.
• Bên pháp lý: Tùy theo tính chất của sản phẩm phần mềm, sản phẩm cần thỏa mãn các yêu cầu pháp lý cụ thể.
• Nhóm xây dựng phần mềm: Những cá nhân xây dựng sản phẩm phần mêm dựa theo yêu cầu phía khách hàng.

Các thành viên trong nhóm sẽ chia sẻ gánh nặng công việc với nhau, cũng như chia sẻ kiến thức dựa trên phẩm chất tôn trọng và trung thực. Quá trình giao tiếp giữa các thành viên có thể tiến hành qua giao tiếp trực tiếp [họp nhóm, trao đổi cá nhân], qua tài liệu [Ví dụ: mã nguồn]. Khi các thành viên trong nhóm phối hợp chặt chẽ với nhau dưới sự điều phối của người quản lý, sản phẩm phần mềm sẽ giảm đáng kể các lỗi phát sinh. Đồng thời, thời gian xây dựng sản phẩm sẽ được đẩy nhanh lên.

2.2. Nhận thức cá nhân

Một điều hiển nhiên đối với kĩ sư phần mềm là họ luôn phải đối mặt với các vấn đề phát sinh bất ngờ và liên tục trong quá trình xây dựng sản phẩm. Đối với những vấn đề đơn giản hoặc đã có hướng giải quyết từ trước, kĩ sư phần mềm dễ dàng vượt qua thử thách này. Tuy nhiên trong thực tế, các vấn đề nảy sinh thường không biết trước cách xử lí hiệu quả ngay lập tức. Bài toán làm sao giải quyết vấn đề một cách hiệu quả là một bài toán khó. Để giải quyết bài toán này, chúng ta sẽ tìm hiểu các yếu tố ảnh hưởng đến nhận thức cá nhân và các phương pháp để cải thiện nhận thức cá nhân.

Các yếu tố rào cản ảnh hưởng đến nhận thức cá nhân gồm:

• Thiếu kiến thức liên quan đến vấn đề phát sinh
• Dữ liệu phân tích từ vấn đề lớn
• Tâm lý lo sợ thất bại
• Thiếu khả năng biểu thị vấn đề
• Ảnh hưởng bởi môi trường làm việc
• Ảnh hưởng bởi trạng thái cảm xúc của cá nhân

Kĩ sư phần mềm cần rèn luyện cho mình khả năng tập trung để giải quyết vấn đề, hoặc nhờ các thành viên trong nhóm xem xét vấn đề cho mình. Bằng cách này, gánh nặng công việc đã vô tình chia sẻ cho các thành viên khác trong nhóm. Bằng các cách nhìn khác nhau với cùng một vấn đề, vấn đề được phân tích tỉ mĩ và thấu đáo.

Ngoài ra, kĩ sư phần mềm có thể giải quyết vấn đề sử dụng nỗ lực cá nhân bằng kĩ thuật giảm tải nhận thức. Một phương pháp phổ biến hay được sử dụng là kĩ thuật chia nhỏ vấn đề. Sau khi vấn đề được chia nhỏ, tại mỗi một thời điểm kĩ sư phần mềm chỉ giải quyết một bài toán con đó. Tổng hợp các bài toán con lại, kĩ sư phần mềm dễ dàng tìm lời giải cho bài toán lớn.

2.3. Giải quyết vấn đề phức tạp

Đa phần các vấn đề mà kĩ sư phần mềm vấp phải khá phức tạp và khó khăn để tìm hướng giải quyết toàn bộ hoặc giải quyết bởi một nhóm các kĩ sư phần mềm riêng rẻ. Khi những trường hợp tương tự như vậy xảy ra, hướng giải quyết thường dùng được thực hiện là làm việc nhóm và phân rã vấn đề.

Làm việc nhóm cùng nhau giúp giải quyết vấn đề phức tạp và vấn đề lớn bằng cách chia sẻ gánh nặng và nỗ lực dựa trên tri thức và óc sáng tạo của các cá nhân. Khi các kĩ sư phần mềm làm việc theo nhóm, các góc nhìn và khả năng khác nhau của từng cá nhân sẽ bổ sung lẫn nhau và giúp xây dựng phương án khả thi. Ví dụ một vài nhóm điển hình là lập trình theo cặp trong mô hình Agile và đánh giá mã nguồn trong SQA.

2.4. Tương tác với các bên liên quan

Sự thành công của một nỗ lực ngành kĩ thuật phần mềm phụ thuộc vào các tương tác tích cực với các bên liên quan. Họ cung cấp sự hỗ trợ, thông tin và phản hồi ở mọi giai đoạn trong vòng đời phát triển phần mềm. Ví dụ, trong thời kì giai đoạn đầu, khá quan trọng để nhận diện các biên liên quan và xác định sản phẩm ảnh hưởng đến họ như thế nào. Sau đó, sự xác định đẩy đủ về yêu cầu của các bên liên quan sẽ bắt được đúng và hoàn hảo.

Trong suốt sự phát triển, các bên liên quan có thể phản hồi về đặc tả và/hoặc các phiên bản sớm của phần mềm, sự thay đổi độ ưu tiên, cũng như làm rõ các yêu cầu phần mềm mới hoặc chi tiết các yêu cầu phần mềm. Cuối cùng, trong pha bảo trì phần mềm cho tới khi kết thúc hẳn dự án, các bên liên quan cung cấp phản hồi về sự tiến hóa hoặc về các yêu cầu mới cũng như các thông báo để phần mềm có thể kế thừa và cải tiến.

2.5. Giải quyết các vấn đề không chắc chắn và mơ hồ

Cũng như các kĩ sư ở lĩnh vực khác, các kĩ sư phần mềm thường phải đối phó và giải quyết sự không chắc chắn và mơ hồ trong khi hỗ trợ dịch vụ và phát triển sản phẩm. Các kĩ sư phần mềm này phải tấn công và giảm thiểu hoặc loại trừ bất kì sự thiếu rõ ràng vốn là một vật cản để thực hiện công việc.

Thông thường, sự không chắc chắn đơn giản là sự phản ánh của thiếu kiến thức. Trong trường hợp này, sự nghiên cứu các nguồn tài nguyên tới các nguồn chính thức như sách, tạp chí chuyên ngành, phỏng vấn với các bên liên quan, hoặc tham khảo các thành viên trong nhóm có thể giúp vượt qua vấn đề.

Khi sự không chắc chắn và sự mơ hồ không thể vượt qua dễ dàng, các kĩ sư phần mêm hoặc tổ chức có thể coi vấn đề này là một hiểm họa dự án. Trong trường hợp này, các ước lượng công việc hoặc chi phí được điều chỉnh để giảm bớt chi phí đoán trước được sao cho giải quyết vấn đề đó.

2.6. Đối phó với môi trường đa văn hóa

Môi trường đa văn hóa có thể có những tác động đến hành vi một nhóm. Điều này đặc biệt đúng khi nhóm bị phân chia bởi môi trường địa lý hoặc giao tiếp không thường xuyên. Quá trình giao tiếp thậm chí khá khó khăn nếu các thành viên có múi giờ khác nhau khiến cho tần suất giao tiếp càng ít hơn.

Môi trường đa văn hóa thấy khá nhiều trong kĩ nghệ phần mềm, có thể hơn cả các ngành nghề khác liên quan đến kỹ thuật. Nguyên nhân bởi vì xu hướng mạnh mẽ về outsourcing xuyên quốc gia và sự dễ gửi các thành phần phần mềm ngay lập tức trên khắp toàn cầu. Ví dụ, một cách thường thấy trong dự án phần mềm là chia nhỏ thành các vấn đề dựa trên biên giới văn hóa và dân tộc. Cũng khá thường thấy các thành viên trong một nhóm gồm các thành viên đến từ những nơi có nền tảng văn hóa khác nhau.

Để một dự án phần mềm thành công, các thành viên trong nhóm cần học sự khoan dung, công nhận những quy tắc dựa trên tiêu chuẩn xã hội. Hầu hết các giao tiếp bao gồm gặp mặt trực tiếp có thể giảm thiểu sự phân chia về mặt địa lý và văn hóa, đồng thời thúc đẩy sự kết nối và gia tăng năng suốt. Hơn nữa, cuộc trò chuyện có thể sử dụng ngôn ngữ mẹ đẻ của đối phương sẽ mang lại lợi ích rất nhiều để kết nối các cá nhân với nhau.

3. Kĩ năng giao tiếp

Đối với kĩ sư phần mềm, kĩ năng giao tiếp vô cùng quan trọng gồm kĩ năng nói, kĩ năng đọc và kĩ năng viết. Sự thành công của dự án bị ảnh hưởng trực tiếp bởi thông tin trao đổi giữa kĩ sư phần mềm, khách hàng, người giám sát, đồng nghiệp và nhà hỗ trợ. Giải quyết vấn đề một cách tối ưu có thể đạt được qua bước nghiên cứu, suy ngẫm và tóm tắt thông tin. Sự chấp nhận sản phẩm khách hàng và sử dụng sản phẩm an toàn phụ thuộc vào sự chuẩn bị của các khóa đào tạo và tài liệu liên quan. Sự thành công trong sự nghiệp của một kĩ sư phần mềm bị ảnh hưởng bởi khả năng giao tiếp bằng lời nói và khả năng viết sao cho hiệu quả.

3.1. Đọc, hiểu và tóm tắt

Các kĩ sư phần mềm có thể đọc và hiểu các tài liệu kĩ thuật. Các tài liệu kĩ thuật gồm sách tham khảo, hướng dẫn sử dụng, bài báo và mã nguồn. Kĩ năng đọc không phải là phương pháp chính để cải thiện kĩ năng, nhưng đó là phương pháp để thu thập các thông tin cần thiết để đạt được mục tiêu dự án. Một kĩ sư phần mềm chọn lọc thông tin qua lượng thông tin rất lớn, lọc lấy các mảnh thông tin mà họ cảm thấy hữu ích. Khách hàng có thể yêu cầu kĩ sư phần mềm tóm tắt kết quả của những thông tin đã được tập hợp lại cho họ, đơn giản hóa thông tin hoặc giải thích các thông tin. Mục đích của hành động này nhằm giúp phía khách hàng có thể đưa ra quyết định cuối cùng.

3.2. Kĩ năng viết

Kĩ sư phần mềm có thể xây dựng sản phẩm tài liệu được yêu cầu từ phía khác hàng. Những sản phẩm tài liệu này gồm mã nguồn, kế hoạch dự án, tài liệu yêu cầu dự án, phân tích hiểm họa, tài liệu thiết kế phần mềm, báo cáo kĩ thuật, biểu đồ, v.v. Viết sao cho rõ ràng và súc tích là một điều quan trọng vì đó thường là phương pháp chính để giao tiếp giữa các bên liên quan. Trong mọi trường hợp, sản phẩm được viết bởi kĩ sư phần mềm cần được xây dựng sao cho dễ hiểu, rõ ràng đối với người đọc.

3.3. Giao tiếp nhóm

Kĩ năng giao tiếp hiệu quả giữa các thành viên trong nhóm là cần thiết để đạt được mục tiêu dự án. Các bên liên quan sẽ được tham khảo để lấy ý kiến, các quyết định sẽ được tạo ra, và kế hoạch phải được xây dựng. Càng đông thành viên trong một nhóm, yêu cầu giao tiếp càng trở nên quan trọng. Một vài giao tiếp có thể thực hiện được qua kĩ thuật viết. Giao tiếp qua tài liệu phần mềm là một cách thay thế phổ biến cho tương tác trực tiếp. Giao tiếp qua email là cách khác rất hữu ích nhưng không đủ. Nguyên nhân bởi vì, khi một bên gửi quá nhiều tin nhắn, thì bên nhận rất khó để xác định đâu là thông tin quan trọng. Các tổ chức thường dùng các phần mềm cộng tác để chia sẻ thông tin. Thêm vào đó, việc sử dụng cửa hàng thông tin điện tử là khả thi đối với các thành viên trong nhóm. Thông tin được lưu trên cửa hàng gồm các chính sách của tổ chức, các chuẩn, các thủ tục kĩ nghệ phổ biến, thông tin về các dự án riêng biệt.

3.4. Kĩ năng trình bày

Các kĩ sư phần mềm dựa vào kĩ năng trình bày của họ trong suốt quá trình phát triển dự án. Ví dụ, trong trong pha xây dựng tài liệu đặc tả, các kĩ sư phần mềm sẽ cùng làm việc với bên khách hàng và đồng đội qua tài liệu đặc tả, qua xem xét yêu cầu. Khả năng truyền đạt của kĩ sư phần mềm trong một bài thuyết trình bị ảnh hưởng bởi sự hỗ trợ từ phía khách hàng, sự quản lý và sự chấp nhận sản phẩm. Ngoài ra, yếu tố này còn bị ảnh hưởng bởi khả năng phân tích của các bên liên quan và sự hỗ trợ của họ trong nỗ lực tạo ra sản phẩm. Những tri thức này cần được tài liệu hóa trong các mẫu sile, bài báo hoặc bất kì tài liệu nào khác tiên lợi cho việc tạo tri thức.

Group 10:

• Nguyễn Gia Dũng
• Nguyễn Ngọc Khánh

1.Software Quality Fundamentals

Software Engineering Culture and Ethics

Value and Costs of Quality

Models and Quality Characteristics

Software Quality Improvement

Software Safety

1.1 Software Engineering Culture and Ethics

Một nền văn hóa phần mềm lành mạnh bao gồm nhiều đặc điểm, bao gồm:

• Có sự cam kết về chất lượng của người lập trình, đảm bảo cân bằng giữa chi phí, tiến độ, chất lượng.

• Một sản phẩm phần mềm tốt là sản phẩm được báo cáo chính xác thông tin và các kết quả liên quan đến chất lượng.

• Do yêu cầu đảm bảo chất lượng phần mềm nên 1 số tổ chức đã tạo ra các bộ chuẩn về các nguyên tắc trong chất lượng phần mềm

Ví dụ: IEEE Computer Society and the ACM.

1.2.Value and Costs of Quality

CoSQ: Cost of software Quality [Chi phí chất lượng phần mềm] • Chuẩn tập hợp 1 bộ các phép đo đánh giá về giá trị kinh tế trong quá trình phát triển phần mềm và bảo trì. • Four cost of quality categories: [4 loại chi phí]

• prevention
• appraisal
• internal failure
• external failure

1.2.1. Prevention: Chi phí phòng ngừa

• Bao gồm các khoản đầu tư vào các nỗ lực cải tiến quy trình phần mềm, chất lượng cơ sở hạ tầng, các công cụ chất lượng, đào tạo, kiểm tra, đánh giá và quản lý.

• Các chi phí này thường không cụ thể cho một dự án

1.2.2. Appraisal: Chi phí thẩm định

• Phát sinh từ các hoạt động dự án mà tìm thấy lỗi.

• Phân loại: chi phí đánh giá thiết kế và chi phí kiểm thử [phần mềm kiểm tra đơn vị, tích hợp phần mềm, kiểm tra hệ thống cấp, kiểm tra chấp nhận]

• chi phí thẩm định sẽ được mở rộng cho các nhà cung cấp phần mềm hợp đồng phụ

1.2.3. Internal failure: Chi phí thất bại nội bộ

Là chi phí được phát sinh để sửa chữa những lỗi tìm thấy trong quá trình hoạt động thẩm định và phát hiện ra trước khi phân phối sản phẩm cho khách hàng

1.2.4. External failure: Chi phí thất bại bên ngoài

Bao gồm các hoạt động ứng phó với các vấn đề phần mềm phát hiện sau khi giao hàng cho khách hàng.

Summary: Kỹ sư phần mềm có thể sử dụng phương pháp CoSQ để xác định cấp độ chất lượng phần mềm và cũng có thể trình bày lựa chọn sao cho cân bằng giữa chất lượng và chi phí của sản phẩm

1.3 Models and Quality Characteristics:

Mô hình và đặc điểm của chất lượng

• Thuật ngữ mô tả đặc tính chất lượng phần mềm [hoặc mô hình của chất lượng phần mềm]

• Mỗi mô hình có các mức phân cấp và đặc tính khác nhau.

Ví dụ: ISO/IEC 25.010: 2011 bao gồm

• identifying software and system requirements [Yêu cầu của phần mềm và hệ thống]

• validating the comprehensiveness of a requirements definition [Tính toàn diện của hệ thống]

• identifying software and system design objectives [Yêu cầu thiết kế theo mục tiêu của phần mềm và hệ thống]

• identifying software and system testing objectives [Yêu cầu kiểm thử theo mục tiêu]

• identifying quality control criteria as part of quality assurance [Yêu cầu về tiêu chí quản lý chất lượng – là 1 phần của việc đảm bảo chất lượng]

• identifying acceptance criteria for a software product and/or software-intensive computer system [Các tiêu chí ở mức chấp nhận được cho 1 sản phẩm phần mềm]

• establishing measures of quality characteristics in support of these activities [Các biện pháp hỗ trợ cho đặc tính chất lượng]

1.4 Software Quality Improvement

Cải thiện chất lượng phần mềm

• Thông qua các quy trình phòng ngừa hoặc một quá trình lặp đi lặp lại các cải tiến liên tục, đòi hỏi có sự kiểm soát quản lý, điều phối, và thông tin phản hồi từ nhiều tiến trình đồng thời:

• [ 1 ] các quá trình trong vòng đời phần mềm.

• [ 2 ] quá trình lỗi / khiếm khuyết phát hiện, loại bỏ, và phòng ngừa.

• [ 3 ] các quá trình cải tiến chất lượng.

Ví dụ:

• Xây dựng chất lượng sản phẩm thông qua việc phát hiện phòng ngừa sớm các lỗi, cải tiến liên tục giữa các bên liên quan trong quá trình phát triển sản phẩm.

=> Các chuyên gia đã khẳng định: Chất lượng của một sản phẩm được liên kết trực tiếp đến chất lượng của quá trình phát triển và sử dụng.

• PDCA [Plan- Do- Check- Act]: Lên kế hoạch – thực hiện – kiểm tra – chỉnh sửa •• Evolutionary delivery: Khả năng tiến hóa•• QFD [quality function deployment]: Cải tiến chất lượng triển khai •

=> Cung cấp các kỹ thuật để xác định mục tiêu chất lượng sản phẩm và xác định xem họ được đáp ứng như thế nào.