lOMoARcPSD|40651217

TÀI LIỆU CÔNG NGHỆ PHẦN MỀM

1. Mô hình phát triển phần mềm, ưu nhược, khi nào dùng:
   1. 1.Mô hình thác nước (Waterfall model):
      1. Đặc điểm:
         • Mô hình thác nước [Winston Royce] đưa ra vào năm 1970 nhằm thay thế cho phương pháp “code-and-fix”.
         • Được coi là mô hình phát triển phần mềm đầu tiên được sử dụng, là chương trình áp dụng theo tính tuần tự của các giai đoạn phát triển phần mềm, mỗi giai đoạn xác định tiêu chuẩn đầu vào và ra.
         • Đầu ra của giai đoạn trước là đầu vào của giai đoạn sau. Giai đoạn sau chỉ được thực hiện khi giai đoạn trước đã kết thúc. Đặc biệt không được quay lại giai đoạn trước để xử lý các yêu cầu khi muốn thay đổi.
      2. Phân tích mô hình:
         • Requirement gathering: Thu thập và phân tích yêu cầu được ghi lại vào tài liệu đặc tả yêu cầu trong giai đoạn này.
         • System Analysis: Phân tích thiết kế hệ thống phần mềm, xác định kiến trúc hệ thống tổng thể của phần mềm.
         • Coding: Hệ thống được phát triển theo từng unit và được tích hợp trong giai đoạn tiếp theo. Mỗi Unit được phát triển và kiểm thử bởi dev được gọi là Unit Test.
         • Testing: Cài đặt và kiểm thử phần mềm. Công việc chính của giai đoạn này là kiểm tra và sửa tất cả những lỗi tìm được sao cho phần mềm hoạt động chính xác và đúng theo tài liệu đặc tả yêu cầu.
         • Implementation: Triển khai hệ thống trong môi trường khách hàng và đưa ra thị trường.
         • Operations and Maintenance: Bảo trì hệ thống khi có bất kỳ thay đổi nào từ phía khách hàng, người sử dụng.
      3. Ưu điểm:
         • Mô hình dễ hiểu, dễ sử dụng, dễ tiếp cận, dễ quản lý.
         • Các giai đoạn và hoạt động được xác định rõ ràng.
         • Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm các lỗi.
      4. Nhược điểm:
         • Rất khó để quay lại một giai đoạn nào khi nó đã kết thúc.
         • Ít tính linh hoạt và phạm vi điều chỉnh của nó khá khó khăn, tốn kém.
         • Mô hình không thích hợp với những dự án dài, đang diễn ra, hay những dự án phức tạp, có nhiều thay đổi về yêu cầu trong vòng đời phát triển.
         • Khó đánh giá tình trạng của dự án, đánh giá kết quả của dự án ở thời điểm kiểm tra do việc tích hợp chỉ thực hiện ở giai đoạn cuối.
         • Tồn tại việc phải chờ (“delay”) trong nhóm làm việc.
         • Việc thực hiện trình tự không tự nhiên, tính lặp thường diễn ra trong thực tế.
      5. Khi nào dùng:
         • Khi xác định sản phẩm ổn định và những vấn đề về kỹ thuật đã biết rõ:
         • Nếu một công đã xây dựng một hệ thống như kế toán, bán hàng… thì những dự án xây dựng những sản phẩm tương tự có thể sử dụng mô hình thác nước
         • Tạo một phiên bản mới của một sản phẩm đang tồn tại trong đó những biến đổi (change) được xác định và kiểm soát
         • Các dự án nhỏ, ngắn hạn
         • Các dự án có ít thay đổi về yêu cầu và không có những yêu cầu không rõ ràng.

1.2.Mô hình tăng dần:

1.2.1. Đặc điểm:

• Các yêu cầu được xác định và phân loại theo độ ưu tiên, độ ưu tiên cao cho những chức năng chính và những chức năng có độ rủi ro cao
• Phân chia các yêu cầu cho các vòng và thiết kế kiến trúc của toàn bộ hệ thống
• Vòng đầu tiên tạo ra sản phẩm lõi (core product)
• Các bước sau bổ sung các chức năng khác và tích hợp vào hệ thống nhằm hoàn thiện dần sản phẩm
• Hệ thống tích hợp phải được kiểm tra đánh giá thường xuyên theo từng giai đoạn
• Các yêu cầu và kiến trúc của toàn bộ hệ thống sẽ được điều chỉnh dựa vào những sản phẩm phát hành theo từng vòng

1.2.2. Ưu điểm:

• Phát triển nhanh chóng.
• Mô hình này linh hoạt hơn, ít tốn kém hơn khi thay đổi phạm vi và yêu cầu.
• Dễ dàng hơn trong việc kiểm tra và sửa lỗi.
• Có thể thực hiện nhiều bước đồng thời.
• Nhân viên có thể thực hiện những công việc tương tự ở các vòng một cách liên tục.
• Những chức năng của hệ thống có thứ tự ưu tiên càng cao (chức năng chính, chức năng rủi ro cao) sẽ được thực hiện trước, do đó chúng sẽ được kiểm thử nhiều hơn, sản phẩm đươc hoàn thành phần cơ bản sớm.
• Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả cho khách hàng. Những kết quả này đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.

1.2.3. Nhược điểm:

• Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi xác định các vòng gia tăng (thác nước?)
• Phải xác định rõ các giao tiếp (interface) cho các module mà thời gian hoàn thành cách biệt nhiều
• Việc kiểm tra khó khăn hơn trên một hệ thống hoàn chỉnh
• Khách hàng khi thấy sản phẩm lõi có thể nghĩ là công việc đơn giản ít tốn kém
• Đòi hỏi phải có kế hoạch và thiết kế tốt, phân chia công việc hợp lý, các nhân viên phải cộng tác tốt
• Tổng chi phí cao hơn mô hình thác nước.

1.2.4. Khi nào dùng:

• Khi tất cả yêu cầu được hiểu khá rõ nhưng mong muốn có sự tiến hóa dần của sản phẩm
• Khi cần phải nhanh chóng đưa sản phẩm với chức năng cơ bản ra thị trường sớm

1.3.Mô hình xoắn ốc:

1.3.1. Đặc điểm:

• Đề nghị bởi Berry Boehm, 1988
• Mỗi vòng lặp đều có phân tích rủi ro, chỉ báo sớm những rủi ro không thể khắc phục với phí tổn không cao.
• Quy trình này áp dụng cho những dự án cần nhiều thời gian và có rủi ro từ trung bình đến cao.
• Mô hình xoắn ốc (Spiral model) có thể được xem là sự kết hợp giữa mô hình thác nước (Waterfall model) và mô hình mẫu (Prototype model) và đồng thời thêm phân tích rủi ro (Risk assessment).

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

• Các pha trong quy trình phát triển xoắn ốc bao gồm:
  • • Objective identification- Thiết lập mục tiêu: xác định mục tiêu, đối tượng cho từng pha của dự án.
    • Alternate evaluation- Đánh giá và giảm thiểu rủi ro: đánh giá rủi ro và thực hiện các hành động để giảm thiểu rủi ro.
    • Product development- Phát triển sản phẩm: Lựa chọn mô hình phù hợp để phát triển hệ thống.
    • Next phase planning- Lập kế hoạch: đánh giá dự án và lập kế hoạch cho pha tiếp theo.

1.3.3. Ưu điểm:

• Tốt cho các hệ phần mềm quy mô lớn.
• Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa.
• Đánh giá thực tế hơn như là một quy trình làm việc, bởi vì những vấn đề quan trọng đã được phát hiện sớm hơn.

1.3.4. Nhược điểm:

• Nó cần các kiến thức đánh giá rủi ro chuyên sâu. Việc đánh giá rủi ro tốn nhiều chi phí, không không thích hợp cho những dự án rủi ro thấp hay nhỏ
• Mô hình phức tạp, khó sử dụng
• Khó quản lý tiến trình và thuyết phục khách hàng - Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn. - Chưa được dùng rộng rãi.

1.3.5. Khi nào dùng:

• Được sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các giai đoạn nhỏ hoặc theo các phân đoạn.

1. 4.Agile (Phương pháp phát triển phần mềm linh hoạt):

1.4.1. Đặc điểm:

• • • Khác biệt dễ nhận thấy của PPPTPMLH đó là lượng giấy tờ tài liệu ít hơn và có thể nói là tập trung vào việc lập trình hơn. Nhưng ẩn đằng sau đó là hai khác biệt nền tảng quan trọng: “thích ứng thay vì dự đoán” và “hướng đến con người thay vì qui trình”.
    • PPPTPMLH đề cao tính chủ động và sáng tạo của các cá nhân tham gia, và đặc biệt là việc trao đổi thông tin giữa các thành viên.
    • PPPTPMLH không khước từ sự tổ chức nhưng nó cố gắng cân bằng giữa sự tổ chức và sự linh hoạt, cân bằng giữa việc không có qui trình nào cả và qui trình quá chi li và cứng nhắc.

1.4.2. Ưu điểm:

1.4.3. Nhược điểm:

1.4.4. Khi nào dùng:

• • • Có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng cần sự tham gia và tính tương tác của khách hàng.
    • Sử dụng khi khách hàng yêu cầu chức năng sẵn sàng trong khoảng thời gian ngắn.

1.5.

1. Yêu cầu (Requirement – IEEE) 2.1.Yêu cầu là gì?
   • • • Yêu cầu là điều kiện hay khả năng mà người dùng cần để hoàn thành mục tiêu của mình
       • Một điều kiện hay một khả năng mà một hệ thống hay một thành phần hệ thống đáp ứng hay sở hữu nhằm thỏa mãn một hợp đồng, một tiêu chuẩn, một đặc tả hay một tài liệu hình thức cần tuân thủ khác (formally imposed document) - Các loại yêu cầu:
         • Có những yêu cầu ngầm định (implicit)
         • Một yêu cầu có thể được nhận biết (known, spoken)/ không nhận biết (forgotten, unspoken…)
       • Dùng kỹ thuật yêu cầu (Requirements engineering) thay cho phân tích yêu cầu (Requirement Analysis)
       • Nhấn mạnh tới tính cộng tác và lặp lại.
         • Tạo tài liệu cho những kết quả khảo sát.
         • Kiểm tra.

- Nó còn nhấn mạnh tới vai trò của kinh nghiệm và tính xã hội.

2.2.Yêu cầu/Phân tích khả thi:

- Phân tích khả thi cho biết hệ thống với những yêu cầu xác định có thể thực hiện trong những điều kiện về kỹ thuật, tài nguyên, ngân sách… Một số vấn đề:

• • • • • Hệ thống có đóng góp vào mục tiêu của tổ chức hay không?
        • Hệ thống có thể được xây dựng bằng cách sử dụng công nghệ hiện tại, trong tiến độ và ngân sách cho phép?
        • Hệ thống có được tích hợp với các hệ thống khác đang sử dụng hay không?...

- Những câu hỏi đặt ra để phân tích khả thi: o Vấn đề xử lý hiện tại như thế nào? o Hệ thống đề nghị cung cấp những tiện ích gì? o Nếu hệ thống không được cài đặt thì sao? o Hệ thống đề xuất sẽ trợ giúp nghiệp vụ theo cách thức nào? o Những rắc rối về việc tích hợp là gì? o Có cần kỹ thuật mới không?

o Cần có những kỹ năng gì để thực hiện và sử dụng?

2.3.Đánh giá yêu cầu:

• • • • Xác định những yêu cầu được trình bày có phù hợp với những gì khách hành thật sự muốn
      • Chi phí cho những lỗi về yêu cầu rất cao: Chi phí cho việc sửa chữa lỗi yêu cầu sau khi xuất xưởng cao hơn nhiều lần chi phí sửa lỗi lúc cài đặt (implementation) - Tiêu chí đánh giá yêu cầu: o Validity – Giá trị. Hệ thống có cung cấp các chức năng hỗ trợ tốt nhất cho nhu cầu của khách hàng không?
        • Consistency – Toàn vẹn. Có tranh chấp yêu cầu không? o Completeness – Đầy đủ. Có bao gồm tất cả yêu cầu của khách hàng không? o Realism - Hiện thực. Các yêu cầu có thể được thực hiện với ngân sách và công nghệ có sẵn không?
        • Verifiability – Kiểm chứng được. Yêu cầu có thể kiểm tra được?

- Kỹ thuật đánh giá yêu cầu:

• • • • • Kiểm tra yêu cầu (Review): Phân tích thủ công có tính hệ thống o Tạo mẫu (Prototyping): Dùng mô hình có thể thực thi
        • Tạo tình huống kiểm tra (Test-case): Những tình huống kiểm tra khó hay không thể thiết kế tốt thì khó đánh giá.

1. Thách thức của công nghệ phần mềm:
   • • • Tính không đồng nhất (Heterogeneity)
       • Những thay đổi về nghiệp vụ và xã hội (Business and social change)
       • Bảo mật và tin cậy (Security and trust)
2. Thuộc tính của phần mềm:
   • • • Khả năng bảo trì (Maintainability): phần mềm có thể duy trì hoạt động, có thể điều chỉnh và mở rộng để thoả mãn những yêu cầu luôn thay đổi.
       • Mức độ tin cậy (Reliability-Dependability): phần mềm phải được tin cậy, bảo mật và chính xác.
       • Hiệu quả (efficiency): phần mềm không nên sử dụng lãng phí tài nguyên của hệ thống.
       • Khả năng được chấp nhận (acceptability-Usability): người sử dụng phải chấp nhận phần mềm. Điều đó có nghĩa là nó phải dễ hiểu, sử dụng được và tương thích với các hệ thống khác.