ĐẠi học quốc gia hà NỘi trường Đại học Công nghệ Nguyễn Việt Hà Bài giảng


Cái nhìn chung về kỹ nghệ phần mềm



tải về 454.68 Kb.
trang4/13
Chuyển đổi dữ liệu09.09.2017
Kích454.68 Kb.
#33014
1   2   3   4   5   6   7   8   9   ...   13

1.4 Cái nhìn chung về kỹ nghệ phần mềm


Tiến trình phát triển kỹ nghệ phần mềm chứa ba giai đoạn chính bất kể mô hình kỹ nghệ phần mềm được chọn lựa. Ba giai đoạn này là xác định, phát triển và bảo trì, được gặp phải trong mọi dự án phát triển phần mềm, bất kể tới miền ứng dụng, kích cỡ và độ phức tạp.

Giai đoạn xác định tập trung vào khái niệm cái gì. Tức là trong khi xác định, người phát triển phần mềm cố gắng tập trung vào xác định thông tin nào cần được xử lý, chức năng và hiệu năng nào là cần có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào hiện có và tiêu chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công.

Yêu cầu chủ chốt của hệ thống và phần mềm cũng được xác định. Mặc dầu các phương pháp được áp dụng trong giai đoạn xác định thay đổi tùy theo mô hình kỹ nghệ phần mềm (hay tổ hợp các mô hình) được áp dụng, có ba bước riêng vẫn xuất hiện dưới dạng:

1. Phân tích hệ thống: Phân tích hệ thống xác định ra vai trò của từng phần tử trong một hệ thống dựa trên máy tính, tức là vạch ra vai trò mà phần mềm (cần phát triển) sẽ giữ.

2. Lập kế hoạch dự án phần mềm: Một khi vai trò của phần mềm đã được thiết lập, rủi ro đã được phân tích, tài nguyên đã được cấp phát, chi phí đã được ước lượng thì phải xác định cụ thể các công việc cần thực hiện và lập lịch thực hiện chúng.

3. Phân tích yêu cầu: Trong bước phân tích hệ thống chúng ta chỉ xác định được vai trò chung của phần mềm. Sau khi đã chính thức quyết đinh phát triển phần mềm, chúng ta cần phải phân tích để xác định chi tiết lĩnh vực thông tin, các chức năng cũng như các ràng buộc khi vận hành của phần mềm.

Phân tích yêu cầu là khâu kỹ thuật quan trọng đầu tiên để đảm bảo chất lượng (tính đáng tin cậy) của phần mềm. Nếu xác định sai yêu cầu thì các bước kỹ thuật khác có tốt đến đâu thì phần mềm cũng sẽ không được đưa vào sử dụng.

Giai đoạn phát triển tập trung vào khái niệm thế nào. Tức là, trong giai đoạn này người phát triển phần mềm từng bước xác định cách cấu trúc dữ liệu và kiến trúc phần mềm cần xây dựng, cách các chi tiết thủ tục được cài đặt, cách dịch thiết kế vào ngôn ngữ lập trình (hay ngôn ngữ phi thủ tục) và cách thực hiện kiểm thử. Phương pháp được áp dụng trong giai đoạn phát triển sẽ thay đổi tùy theo mô hình nhưng có ba bước đặc thù bao giờ cũng xuất hiện dưới dạng:

1. Thiết kế phần mềm: Là quá trình “dịch” các yêu cầu phần mềm thành một tập các biểu diễn (dựa trên đồ họa, bảng, hay ngôn ngữ), mô tả cho cấu trúc dữ liệu, kiến trúc, thủ tục thuật toán và đặc trưng giao diện.

2. Mã hóa: Các biểu diễn thiết kế phải được biểu diễn bởi một (hay một vài) ngôn ngữ nhân tạo (ngôn ngữ lập trình qui ước hay ngôn ngữ phi thủ tục được dùng trong khuôn cảnh 4GT) mà sẽ tạo ra kết quả là các lệnh thực hiện được trên máy tính.

3. Kiểm thử phần mềm: Một khi phần mềm đã được cài đặt dưới dạng máy thực hiện được, cần phải kiểm thử nó để phát hiện các lỗi phân tích, thiết kế, cài đặt và đánh giá tính hiệu quả.

Giai đoạn bảo trì tập trung vào những thay đổi gắn với việc sửa lỗi, thích ứng khi môi trường phần mềm tiến hóa và sự nâng cao gây ra bởi sự thay đổi yêu cầu của người dùng. Giai đoạn bảo trì áp dụng lại các bước của giai đoạn xác định và phát triển, nhưng là việc thực hiện trong hoàn cảnh phần mềm hiện có. Có ba kiểu thay đổi gặp phải trong giai đoạn bảo trì:



1. Sửa đổi: Cho dù có các hoạt động bảo đảm chất lượng tốt nhất, vẫn có thể là khách hàng sẽ phát hiện ra khiếm khuyết trong phần mềm. Bảo trì sửa đổi làm thay đổi phần mềm để sửa các khiếm khuyết (lỗi lập trình, thuật toán, thiết kế...).

2. Thích nghi: Qua thời gian, môi trường ban đầu (như CPU, hệ điều hành, ngoại vi) để phát triển phần mềm có thể sẽ thay đổi. Bảo trì thích nghi thực hiện việc sửa đổi phần mềm để thích hợp với những thay đổi môi trường ngoài.

3. Nâng cao: Khi phần mềm được dùng, khách hàng/người dùng sẽ nhận ra những chức năng phụ sẽ có lợi. Bảo trì hoàn thiện mở rộng phần mềm ra ngoài các yêu cầu chức năng gốc của nó.

Tổng kết: Phần mềm đã trở thành phần tử chủ chốt của các hệ thống máy tính. Phát triển phần mềm đã tiến hóa từ xây dựng một công cụ xử lý thông tin thành một ngành công nghiệp. Phần mềm là phần tử lôgíc cho nên việc kiểm soát nó khó hơn nhiều so với phần tử vật lý. Khó có thể tối ưu hóa đồng thời các tính năng cần có của phần mềm. Ví dụ, các tính năng như giao diện đồ họa dễ sử dụng và sự hoạt động hiệu quả, tích kiệm tài nguyên hệ thống trong hầu hết các trường hợp là loại trừ lẫn nhau. Thách thức lớn đối với việc phát triển phần mềm là chúng ta phải xây dựng phần mềm tốt theo một lịch trình và kinh phí định trước.

Kỹ nghệ phần mềm là một bộ môn tích hợp cả các phương pháp, công cụ và thủ tục để phát triển phần mềm máy tính. Có một số mô hình khác nhau cho kỹ nghệ phần mềm, mỗi mô hình đều có những mặt mạnh và điểm yếu, nhưng nói chung tất cả đều có một dãy các giai đoạn tổng quát là: xác định, phát triển và bảo trì.


Chương 2

Phân tích và đặc tả yêu cầu

2.1 Đại cương về phân tích và đặc tả


Phân tích và định rõ yêu cầu là bước kỹ thuật đầu tiên trong tiến trình kỹ nghệ phần mềm. Công việc ở bước này là tìm hiểu xem chúng ta phải phát triển cái gì, chứ không phải là phát triển như thế nào. Đích cuối cùng của khâu phân tích là tạo ra đặc tả yêu cầu, là tài liệu ràng buộc giữa khách hàng và người phát triển và là cơ sở của hợp đồng.

Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và người phân tích (bên phát triển). Khách hàng phát biểu yêu cầu và người phân tích hiểu, cụ thể hóa và biểu diễn lại yêu cầu. Hoạt động phân tích giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm, giúp cho đảm bảo chất lượng của phần mềm (phần mềm đáng tin cậy). Phần mềm đáng tin cậy có nghĩa là phải thực hiện được chính xác, đầy đủ yêu cầu của người sử dụng. Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu thì việc sửa chữa sẽ trở nên rất tốn kém. Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu như sai sót đó được phát hiện muộn, ví dụ như ở bước thiết kế hay mã hóa.

Việc phân tích, nắm bắt yêu cầu thường gặp các khó khăn như

- 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 có chuẩn biểu diễn

- Các hệ thống thông tin lớn có nhiều người sử dụng thì 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 phát biểu yêu cầu thường không chính xác

Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống. Yêu cầu là một đòi hỏi mà chúng ta có thể kiểm tra được còn mục tiêu là cái trừu tượng hơn mà chúng ta hướng tới. Ví dụ, giao diện của hệ thống phải thân thiện với người sử dụng là một mục tiêu và nó tương đối không khách quan và khó kiểm tra. Có nghĩa là với một phát biểu chung chung như vậy thì khách hàng và nhà phát triển khó định ra được một ranh giới rõ ràng để nói rằng phần mềm đã thỏa mãn được đòi hỏi đó. Với một mục tiêu như vậy, một yêu cầu cho nhà phát triển có thể là giao diện đồ họa mà các lệnh phải được chọn bằng menu.

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 yêu cầu nên dễ hiểu với người dùng, đồng thời phải chặt chẽ để làm cơ sở cho hợp đồng và để cho người phát triển dựa vào đó để xây dựng phần mềm. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau phục vụ cho các đối tượng đọc khác nhau. Các mức đó có thể là:

Định nghĩa (xác định) yêu cầu: mô tả một cách dễ hiểu, vắn tắt về yêu cầu, hướng vào đối tượng người đọc là người sử dụng, người quản lý...

Đặc tả yêu cầu: mô tả chi tiết về các yêu cầu, các ràng buộc của hệ thống, phải chính xác sao cho người đọc không hiểu nhầm yêu cầu, hướng vào đối tượng người đọc là các kỹ sư phần mềm (người phát triển), kỹ sư hệ thống (sẽ làm việc bảo trì)...

Các tài liệu yêu cầu cần được thẩm định để đảm bảo thỏa mãn nhu cầu người dùng. Đây là công việc bắt buộc để đảm bảo chất lượng phần mềm. Đôi khi việc xác định đầy đủ yêu cầu trước khi phát triển hệ thống là không thực tế và khi đó việc xây dựng các bản mẫu để nắm bắt yêu cầu là cần thiết.


Hình 2.1: Quá trình hình thành các yêu cầu.



tải về 454.68 Kb.

Chia sẻ với bạn bè của bạn:
1   2   3   4   5   6   7   8   9   ...   13




Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý

    Quê hương