So sánh chi phí phát triển phần cứng và phần mềm?

Bạn hiểu gì về thế giới phần mềm tất cả các khái niệm xung quanh? Hãy cùng Hybrid Technologies “nghiền ngẫm” bài viết dưới đây về tất tần tật những thứ liên quan đến “phần mềm” bạn nhé!

Phần mềm là gì?

Phần mềm là các chương trình máy tính và những tài liệu liên quan đến nó như: các yêu cầu, mô hình thiết kế, tài liệu hướng dẫn sử dụng… Do đó, chúng ta thấy rằng đặc điểm của phần mềm là trừu tượng và vô hình.

Các sản phẩm phần mềm được chia thành 2 loại:

  • Sản phẩm đại trà (Generic Product): Được phát triển để bán ra ngoài thị trường, đối tượng người sử dụng vì thế cũng tương đối đa dạng và phong phú.
  • Sản phầm theo đơn đặt hàng (Bespoke Product hoặc Customised Product): Được phát triển cho một khách hàng riêng lẻ theo yêu cầu. Ví dụ: Những hệ thống phần mềm chuyên dụng, hỗ trợ nghiệp vụ cho một doanh nghiệp riêng lẻ…

Như vậy một phần mềm mới có thể được tạo ra bằng cách phát triển từ đầu, thay đổi và điều chỉnh các hệ thống phần mềm đại trà hoặc tái sử dụng lại các phần mềm đã tồn tại.

Công nghệ phần mềm là gì?

So sánh chi phí phát triển phần cứng và phần mềm?

Công nghệ phần mềm là những quy tắc công nghệ (engineering discipline) có liên quan đến tất cả các khía cạnh của quá trình sản xuất phần mềm.

Các Software Developer nên tuân theo một phương pháp, một quy trình có hệ thống, có tổ chức trong công việc của mình. Đồng thời, một kỹ sư phần mềm thường ưu tiên sử dụng các công cụ và kỹ thuật có sẵn thích hợp với vấn đề cần giải quyết thay vì tự suy nghĩ các phương pháp của mình. Vì cơ bản, các phương pháp có sẵn đã được những người lập trình viên trước giải quyết hiệu quả vấn đề và được nhiều người công nhận, sử dụng.

Khác biệt giữa công nghệ phần mềm và khoa học máy tính:

  • Khoa học máy tính thường đề cập tới lý thuyết và những vấn đề mang tính giải thuật cao, còn công nghệ phần mềm đề cập tới các hoạt động xây dựng và đưa ra một phần mềm hữu ích.
  • Khi sự phát triển của phần mềm trở nên mạnh mẽ thì các lý thuyết của khoa học máy tính đã không còn đáp ứng, đóng vai trò là nền tảng hoàn thiện cho công nghệ phần mềm.

Khác biệt giữa công nghệ phần mềm và công nghệ hệ thống:

  • Công nghệ hệ thống (hay còn gọi là kỹ nghệ hệ thống) liên quan tới tất cả các khía cạnh của quá trình phát triển hệ thống dựa trên máy tính bao gồm: phần cứng, phần mềm, và công nghệ xử lý. Công nghệ phần mềm chỉ là một phần của quy trình này, nó có liên quan tới việc phát triển hạ tầng phần mềm (software infrastructure), điều khiển, các ứng dụng và cơ sở dữ liệu trong hệ thống.
  • Kỹ sư hệ thống phải thực hiện việc đặc tả hệ thống, thiết kế kiến trúc hệ thống, tích hợp và triển khai.

Quy trình phần mềm là gì?

So sánh chi phí phát triển phần cứng và phần mềm?

Quy trình phần mềm là tập hợp các hành động với mục đích là xây dựng và phát triển phần mềm. Những hành động thường được thực hiện trong các quy trình phần mềm bao gồm:

  • Đặc tả: Diễn giải, liệt kê những gì hệ thống phải làm và các ràng buộc trong quá trình xây dựng hệ thống.
  • Phát triển: Xây dựng hệ thống phần mềm.
  • Kiểm thử: Kiểm tra xem liệu phần mềm đã thoả mãn yêu cầu của khách hàng.
  • Mở rộng: Điều chỉnh và thay đổi phần mềm tương ứng với sự thay đổi yêu cầu.

Những loại hệ thống khác nhau sẽ cần những quy trình phát triển khác nhau. Ví dụ, hệ thống thời gian thực yêu cầu phải hoàn thành đặc tả hệ thống trước khi chuyển sang giai đoạn xây dựng nó. Nhưng với hệ thống thương mại điện tử, chúng ta có thể vừa đặc tả vừa xây dựng chương trình một cách đồng thời.

Tuy nhiên, nếu chúng ta không sử dụng một quy trình phát triển hệ thống thích hợp thì có thể làm giảm chất lượng của hệ thống và tăng chi phí xây dựng.

Mô hình quy trình phát triển phần mềm như thế nào?

Mô hình quy trình phát triển phần mềm là một thể hiện đơn giản của một quy trình phần mềm, và nó được biểu diễn từ một góc độ cụ thể.

Một số ví dụ về mô hình quy trình phát triển phần mềm:

  1. Mô hình luồng công việc (workflow): mô tả một chuỗi các hành động cần phải thực hiện.
  2. Mô hình luồng dữ liệu (data-flow): mô tả luồng thông tin.
  3. Mô hình Vai trò/Hành động (Role/action): chỉ ra vai trò của những người liên quan trong quy trình phần mềm và nhiệm vụ của từng người.
  4. Ngoài ra, còn có một số mô hình quy trình chung cũng được sử dụng như:
  • Mô hình thác nước (waterfall)
  • Mô hình phát triển lặp lại (Iterative development)
  • Mô hình công nghệ phần mềm dựa thành phần (Component-based software engineering).

Các phương pháp công nghệ phần mềm

Phương pháp công nghệ phần mềm bao gồm các mô hình hệ thống, các ký pháp, quy tắc, hướng dẫn thiết kế và quy trình để xây dựng phần mềm một cách dễ dàng, đảm bảo chất lượng cao và chi phí hiệu quả.

Một số phương pháp công nghệ phần mềm đã được đề xuất như:

  • Phân tích hướng cấu trúc: Tập trung vào việc xác định các chức năng cơ bản của hệ thống
  • Phương pháp hướng đối tượng: tập trung vào việc định nghĩa các đối tượng và sự cộng tác giữa chúng

Là một kỹ sư phần mềm giỏi, ngoài chuyên môn bạn cần có khả năng thích ứng, làm việc nghiêm túc, chuyên nghiệp, hiệu quả và tuân thủ quy trình phù hợp, dần dần tích lũy, dần dần phát triển, dần dần tạo ra càng nhiều giá trị. Chúc các bạn luôn thành công!

Một nhà máy ở Đài Loan đóng vai trò là nhà sản xuất cho nhà sản xuất dụng cụ thể dục của Hoa Kỳ bằng cách sử dụng dịch vụ xử lý kim loại chuyên dụng để sản xuất bánh đà. Mặc dù nhà máy có phòng thí nghiệm đo chuyên dụng để kiểm tra chất lượng bánh đà, nhưng phải mất hơn ba phút để hoàn thành mỗi lần kiểm tra. Để tránh ảnh hưởng tiêu cực đến tốc độ sản xuất và đảm bảo giao hàng kịp thời, dây chuyền sản xuất kiểm soát chất lượng sản phẩm thông qua kiểm tra ngẫu nhiên cùng với kiểm tra thủ công.

Thật không may, nhà máy đã nhận được một khiếu nại khi giao lô bánh đà gần đây nhất của mình cho công ty dụng cụ thể dục của Hoa Kỳ, người đã tuyên bố rằng chất lượng kém. Việc sản xuất này buộc phải tạm dừng và công ty Hoa Kỳ đã tìm cách bồi thường cho những khiếm khuyết.

Để tránh bị phạt trong tương lai do kiểm soát chất lượng kém, nhà máy đã quyết định triển khai hệ thống thị giác máy kiểm tra tất cả các sản phẩm mà không ảnh hưởng đến tốc độ sản xuất.

Mặc dù nhà máy cần nhanh chóng lấy lại niềm tin của khách hàng, nhưng việc triển khai một hệ thống mới thường cần thời gian phát triển sáu tháng (lập kế hoạch dự án sơ bộ, lựa chọn phần cứng, kiểm tra tương thích phần cứng, lập trình, xác định lỗi và kiểm tra, khởi chạy hệ thống và kiểm tra) và không thể được giải quyết kịp thời. Điều này đã khiến nhà máy mua một giải pháp tổng thể có thể hoàn thành trong một khoảng thời gian ngắn (dưới ba tháng), có thể thực hiện nhiều nhiệm vụ kiểm tra cùng một lúc, có thể thêm hoặc sửa đổi các mục kiểm tra và sản phẩm được kiểm tra, rất dễ dàng sử dụng và bảo trì, và tích hợp cả phần cứng và phần mềm.

Để mang đến một sản phẩm phần mềm chất lượng đáng tin cậy thì việc phân tích yêu cầu là khâu vô cùng quan trọng trong quá trình xây dựng phần mềm. Hoạt động này đòi hỏi sự phố kết hợp rất chặt chẽ giữa khách hàng và người phân tích để vạch ra được xem chúng ta phải phát triển cái gì

1 - Mục tiêu và yêu cầu của phần mềm:

Yêu cầu của phần mềm là tất cả các yêu cầu về phần mềm do người dùng nêu ra bao gồm các chức năng của phần mềm, hiệu năng của phần mềm, giao diện của phần mềm và một số các yêu cầu khác

Thông thường các yêu cầu phần mềm được phân loại dựa trên 4 thành phần của phần mềm như sau:

  • Các yêu cầu về phần mềm
  • Các yêu cầu về phần cứng
  • Các yêu cầu về dữ liệu
  • Các yêu cầu về con người

Mục tiêu quan trọng nhất đối với chất lượng phần mềm là phần mềm phải thỏa mãn được các yêu cầu và mong muốn của người dùng. Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Và việc của các kỹ sư phát triển phần mềm đó là phải giúp họ đưa những ý tưởng mơ hồ đó thành hiện thực và xây dựng được một phần mềm có đầy đủ các tính năng cần thiết thỏa mãn yêu cầu của người dùng. Hơn thế nữa, ý tưởng của người dùng thường xuyên thay đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được các yêu cầu thay đổi đó một cách hợp lý.

2 - Những khó khăn trong việc phân tích, nắm bắt yêu cầu:

2.1 - Những vấn đề từ phía người dùng:

  • Người dùng không hiểu họ muốn gì
  • Người dùng liên tục thay đổi yêu cầu ngay cả khi việc phát triển sản phẩm đã được bắt đầu
  • Người dùng không hiểu về kỹ thuật
  • Người dùng không hiểu về quy trình phát triển

2.2 - Những vấn đề từ phía nhà phát triển:

  • Ngôn từ của người dùng và nhà phát triển không khớp nhau
  • Nhà phát triển cố lái cho yêu cầu của người dùng khớp với một hệ thống hay mô hình sẵn có thay vì phát triển một hệ thống theo nhu cầu của khách hàng
  • Việc phân tích có thể do các lập trình viên thực hiện thay vì các nhân viên có kỹ năng phân tích để có thể hiểu được nhu cầu của khách hàng một cách đúng đắn

2.3 - Những vấn đề khác:

  • Các yêu cầu thường mang tính đặc thù của tổ chức đặt hàng nó, do đó nó thường khó hiểu, khó định nghĩa và không theo một tiêu chuẩn nào cả
  • Các hệ thống thông tin lớn có rất nhiều người sử dụng, do đó các yêu cầu thường rất đa dạng và có các mức ưu tiên khác nhau, thậm chí mâu thuẫn lẫn nhau
  • Người đặt hàng nhiều khi là các nhà quản lý, không phải là người dùng thực sự do đó việc đưa ra các yêu cầu thường không chính xác

3 - Các giai đoạn trong phân tích yêu cầu:

Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển. Tài liệu mô tả yêu cầu phải vừa dễ hiểu với người dùng vừa chặt chẽ để làm cơ sở cho việc lập kế hoạch. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau, nhiều giai đoạn khác nhau. Cụ thể như sau:

3.1 - Tìm hiểu các yêu cầu của phần mềm:

Các phương pháp để tìm hiểu các yêu cầu của phần mềm bao gồm:

  • Phỏng vấn, làm việc nhóm, họp và gặp gỡ đối tác...
  • Tìm kiếm các chuyên gia, người sử dụng có hiểu biết về hệ thống cần xây dựng để thu thập được nhiều ý kiến, đóng góp khác nhau

3.2 - Phân tích yêu cầu và thương lượng:

Sau khi tìm hiểu được các yêu cầu của phần mềm, chúng ta cần:

  • Phân loại các yêu cầu phần mềm, sắp xếp chúng thành các nhóm có liên quan đến nhau dựa trên yêu cầu và đòi hỏi của người dùng
  • Thẩm định từng yêu cầu phần mềm để xác định xem chúng có khả năng thực hiện được hay không
  • Xác định các rủi ro có thể xảy ra với từng yêu cầu
  • Đưa ra các đánh giá tương đối về giá thành và thời gian thực hiện của từng yêu cầu
  • Giải quyết các bất đồng về yêu cầu phần mềm với người dùng trên cơ sở thảo luận và thương lượng

3.3 - Mô hình hóa yêu cầu:

Một số phương pháp hay dùng để mô hình hóa yêu cầu đó là:

a - Biểu đồ luồng dữ liệu Biểu đồ luồng dữ liệu (Data Flow Diagram - DFD) là một kỹ thuật để biểu diễn luồng thông tin vào ra của một chức năng trong hệ thống

Các thành phần biểu đồ luồng dữ liệu bao gồm:

  • Các chức năng cần xử lý
  • Luồng dữ liệu
  • Kho dữ liệu
  • Tác nhân: bao gồm tác nhân trong và tác nhân ngoài

Các ký hiệu được dùng trong biểu đồ luồng dữ liệu như sau:

So sánh chi phí phát triển phần cứng và phần mềm?

Biểu đồ luồng dữ liệu có thể được dùng để biểu diễn cho một hệ thống hay phần mềm ở bất kì mức nào, từ tổng quát cho đến chi tiết. Trong thực tế, DFD có thể được phân chia thành nhiều mức biểu diễn. Sau đây là minh họa một DFD cho hệ thống bán vé tầu.

So sánh chi phí phát triển phần cứng và phần mềm?

b - Biểu đồ thực thể quan hệ

Mô hình quan hệ - thực thể ER (Entity Relationship Model) được sử dụng để thiết kế cơ sở dữ liệu ở mức khái niệm. Mô hình này được sử dụng như một công cụ để trao đổi ý tưởng giữa nhà thiết kế và người dùng cuối trong giai đoạn phân tích

Mô hình quan hệ - thực thể bao gồm ba phần tử cơ bản:

  • Kiểu thực thể
  • Mối quan hệ
  • Các thuộc tính

Sau đây là một ví dụ cho mô hình quan hệ - thực thể

So sánh chi phí phát triển phần cứng và phần mềm?

3.4 - Đặc tả yêu cầu:

a - Phân loại yêu cầu: Yêu cầu được chia thành nhiều loại:

  • Yêu cầu chức năng: Mô tả một chức năng cụ thể mà phần mềm cung cấp
  • Yêu cầu phi chức năng: Các ràng buộc về chất lượng, môi trường, chuẩn sử dụng, quy trình phát triển phần mềm
  • Yêu cầu về sản phẩm: Gồm tốc độ, độ tin cậy, bộ nhớ, giao diện, quy trình tác nghiệp,...
  • Yêu cầu về tiến trình phát triển: Gồm các chuẩn, phương pháp thiết kế, ngôn ngữ lập trình....
  • Yêu cầu khác: Gồm chi phí, thời gian, bản quyền,...

b - Đặc tả yêu cầu: Nếu như tài liệu xác định yêu cầu được viết bởi ngôn ngữ tự nhiên của khách hàng thì tài liệu đặc tả yêu cầu phải rất rõ ràng và được xây dựng theo hướng của người phát triển, tránh gây hiểu nhầm giữa khách hàng và người phát triển.

Có các phương pháp đặc tả như sau:

  • Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên
  • Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ đặc tả, công thức và biểu đồ
  • Đặc tả chức năng: Thông thường, khi đặc tả chức năng của phần mềm, người ta sử dụng các công cụ tiêu biểu sau: Biểu đồ phân rã chức năng (Functional Decomposition Diagram – FDD), Biểu đồ luồng dữ liệu (Data Flow Diagrams-DFD), Biểu đồ trạng thái,....
  • Đặc tả mô tả: Sử dụng các công cụ tiêu biểu sau: Biểu đồ thực thể liên kết (EntityRelationship Diagrams - ERD), Đặc tả logic (Logic Specifications), Đặc tả đại số (Algebraic Specifications)

Chất lượng cả bản đặc tả yêu cầu được đánh giá qua các tiêu chí sau:

  • Tính rõ ràng, chính xác
  • Tính phù hợp
  • Tính đầy đủ, hoàn thiện

c - Thẩm định yêu cầu: Sau khi các yêu cầu được xây dựng thì chúng cần được thẩm định xem đã thỏa mãn nhu cầu của khách hàng hay chưa. Nếu việc thẩm định không được thực hiện một cách nghiêm túc, chặt chẽ thì các sai sót sẽ có thể gây ra những hậu quả lớn cho các giai đoạn về sau.

Mục tiêu của việc thẩm định là xác định xem yêu cầu có thỏa mãn 4 yếu tố sau không:

  • Yêu cầu có thỏa mãn nhu cầu người dùng hay không?
  • Yêu cầu có mâu thuẫn với nhau hay không?
  • Yêu cầu có mô tả đầy đủ tất cả các chức năng và ràng buộc hay không?
  • Yêu cầu có đảm bảo các khía cạnh về kỹ thuật, kinh tế và pháp lý hay không?

d - Xây dựng bản mẫu:

Đối với các hệ thống phức tạp, nhiều khi chúng ta không nắm chắc được yêu cầu của khách hàng, chúng ta cũng khó đánh giá được tính khả thi cũng như hiệu quả của hệ thống. Một giải pháp được đưa ra là xây dựng bản mẫu. Bản mẫu vừa được dùng để phân tích yêu cầu vừa có thể tiến hóa thành sản phẩm cuối cùng. Bản mẫu phần mềm không phải nhằm vào việc thẩm định thiết kế (thiết kế của nó thường là hoàn toàn khác với hệ thống được phát triển cuối cùng), mà là để thẩm định yêu cầu của người sử dụng.

3.5 - Định dạng đặc tả yêu cầu:

Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS). Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm, các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm. Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng RSR thông dụng (theo chuẩn IEEE 830-1984).

So sánh chi phí phát triển phần cứng và phần mềm?

Trên đây là khái quát về bước phân tích và đặc tả yêu cầu trong quá trình phát triển phần mềm. Kết quả của việc phân tích là tạo ra bản đặc tả các yêu cầu phần mềm. Đặc tả cần được xét duyệt để đảm bảo rằng người phát triển và khách hàng có cùng nhận biết về hệ thống cần phát triển. Trong các bài viết sau, tôi sẽ mô tả chi tiết hơn về các phương pháp để mô hình hóa yêu cầu

Nguồn tham khảo: http://uet.vnu.edu.vn/~hungpn/class/ASE/Lec2_1.pdf https://truonganhhoang.gitbooks.io/swebok3/content/chapter_1_Software_requirements.html