.Đánh giá chất lượng công việc

Một phần của tài liệu giao_trinh_nhap_mon_cong_nghe_phan_mem (Trang 125 - 129)

4.1 Hiện thực tăng cường

Ý tưởng cơ bản của việc hiện thực tăng cường gần với việc trộn giai đoạn thiết kế và cài đặt hơn là tách biệt hai giai đoạn này mà mơ hình qui trình phát triển phần mềm tuần tự cổ điển đề ra.

Điểm nhấn mạnh của phương pháp này được tìm thấy dựa trên thực nghiệm rằng những quyết định trong thiết kế và cài đặt có tác động lẫn nhau và vì vậy nếu tách bạch thiết kế khắt khe sẽ không đạt được mục tiêu. Trong nhiều trường hợp, chỉ có cài đặt mới quyết định việc phân rã cấu trúc của thiết kế chứng minh sự thõa mãn đầy đủ vấn đề.

Hiện thực tăng cường nghĩa là sau mỗi bước thiết kế có liên quan đến kiến trúc, kiến trúc phần mềm hiện hành được thẩm định dựa trên những trường hợp thực. Sự tác động qua lại giữa các thành phần hệ thống cụ thể trong thiết kế (trong hình thức đặc tả giao diện) được thẩm định. Để có thể làm được điều này, những thành phần hệ thống (hành vi xuất/ nhập của chúng) được mô phỏng hay thực tế hóa như khn mẫu. Nếu có những nghi ngờ liên quan đến tính khả thi của thành phần thì tiến trình thiết kế được ngắt và những thành phần được thực hiện. Chỉ khi hiện thực và nhúng chúng vào trong kiến trúc hệ thống trước đó được kiểm tra thì tiến trình thiết kế tiếp tục hay kiến trúc được chấp nhận tương ứng kiến thức thu được trong hiện thực thành phần.

Hiệu quả của phương pháp này phụ thuộc vào việc mở rộng vào khả năng tích hợp thành phần hệ thống mà được viết trong chuẩn mực khác nhau và được hoàn chỉnh ở nhữn cấp độ khác nhau, đối với toàn bộ hệ thống để thực hiện gần với thực tế. Một vài thành phần hệ thống, ví dụ giao diện người dùng và mơ hình dữ liệu được thể hiện dưới dạng khuôn mẫu, những thành phần khác từ thư viện thành phần có sẵn hay tồn tại như hiện thực hoàn chỉnh được thể hiện dưới dạng mã nguồn thực thi còn các thành phần hệ thống khác có sẵn như đặc

tả giao diện. Đối với sự hợp lệ của thiết kế hệ thống hiện hành, bất kỳ lúc nào giao diện người dùng triển khai thì tương ứng khn mẫu cần được kích hoạt.

4.2 Đánh giá lại thiết kế và chương trình (Design and Code Review)

Với việc xem lại thiết kế và chương trình, sẽ giúp hồn chỉnh chất lượng hiệu quả của công việc hơn là chúng ta chỉ điều chỉnh những thay đổi đơn lẻ trong quá trình phát triển phần mềm.Trong những chương trình lớn, địi hỏi xem xét lại những yêu cầu, đặc tả, thiết kế, và cả chương trình của chúng ta. Giúp điều chỉnh thiếu sót, logic, cấu trúc, tính sáng tỏ. Khi chương trình khơng rõ hay mơ hồ xáo trộn, thêm những ghi chú thì tốt hơn hay viết lại nó một cách đơn giản hơn sẽ làm cho chương trình dễ đọc và dễ hiểu. Việc làm này sẽ tạo cho chúng ta sự tự tin xuất bản hay trình bày cho bạn bè hay tập thể.

Mục đích của review để đảm bảo chương trình tạo ra đạt chất lượng cao nhất. Một trong việc review là kiểm duyệt, duyệt qua, xem xét mục riêng từ thiết kế đến từng dòng lệnh. Review có thể được dùng trên yêu cầu, thiết kế, hồ sơ tài liệu, hay bất kỳ yếu tố của sản phẩm.

Nhiều dự án phần mềm trãi qua nữa qúa trình phát triển ở giai đoạn kiểm thử. Điều này không hiệu quả. Review thiết kế và chương trình là những cách thức hiệu quả tìm và sửa chữa thiếu sót. Với review, chúng ta có thể tìm ra những thiếu sót trực tiếp, trong khi chúng ta chỉ có thể tìm ra những dấu hiệu. Khi chúng ta xem lại chương trình, chúng ta biết nơi và những logic gì giả sử phải được làm.Những sửa lỗi của chúng ta sẽ hoàn chỉnh và chính xác.

Cơng việc review cho phép quay trở lại bất cứ việc gì chúng ta đã làm. Nhóm phát triển nên ngồi lại với nhau để đọc lại mọi thiết kế và chương trình, nghiên cứu, hiểu nó. Sửa những sai sót: logic, cấu trúc, tính rõ ràng. Sau khi đã được xem xét và đánh giá, viết lại chương trình. Chỗ nào khơng rõ ràng hay lộn xộn, thêm ghi chú và viết lại hoàn chỉnh làm cho dễ đọc và dễ hiểu.

5. Ví dụ minh họa

Ví dụ: Xét phần mềm hỗ trợ giải bài tập phương trình đại só với 4 u cầu: Soạn đề bài, Soạn đáp án, Giải bài tập, Chấm điểm.

Nhằm thể hiện các giai đoạn thực hiện trong qui trình Giai đoạn 1: Xác định yêu cầu

ƒ Yêu cầu 1: Soạn đề bài với qui định về Soạn đề bài

ƒ Yêu cầu 3: Giải bài tập với qui định về Giải bài tập và biểu mẫu Giải bài tập ƒ Yêu cầu 4: Chấm điểm với qui định về Chấm điểm

Giai đoạn 2:

ƒ Sơ đồ luồng dữ liệu cho công việc Soạn đề bài

ƒ Sơ đồ luồng dữ liệu cho công việc Soạn đáp án

ƒ Sơ đồ luồng dữ liệu cho công việc Giải bài tập

ƒ Sơ đồ luồng dữ liệu cho công việc Chấm điểm Học sinh Giải bài tập D1 D4 D3 Giáo viên Soạn đáp án D1 D4 D3 Giáo viên Soạn đề bài D1 D4

Giai đoạn 3: Phân tích yêu cầu chức năng

Giai đoạn 4: Thiết kế phần mềm (đã trình bày trong phần kiến trúc phần mềm của chương Thiết kế phần mềm)

Giai đoạn 5: Thực hiện phần mềm

ƒ Hệ thống Lớp đối tượng: Tạo lập các lớp đối tượng SACH_BAI_TAP, BAI_TAP theo mô tả phần thiết kế trong môi trường cụ thể nào đó (VIsual Basic, Visual C++, Java ƒ Hệ thống giao diện: Tạo lập (vẽ) các màn hình giao diện (màn hình chính, màn hình

soạn đề bài, màn hình soạn đáp án, màn hình giải bài tập, màn hình chấm điểm) theo mơ tả của phần thiết kế trong một mơi trường cụ thể nào đó (Visual Basic, Visual C++, Java, v.v.)

Hệ thông lưu trữ: Tạo cấu trúc cơ sở dữ liệu (các bảng SACH_BAI_TAP, BAI_TAP, BAI_GIAI, BUOC_GIAI) theo mô tả của phần thiết kế trong một mơi trường cụ thể nào đó (Access, SQL Server, Oracle,. v.v)

Giai đoạn 6: Kiểm chứng phần mềm xem ở chương Kiểm thử Học sinh

Chấm điểm D1

D4 D3

Một phần của tài liệu giao_trinh_nhap_mon_cong_nghe_phan_mem (Trang 125 - 129)

Tải bản đầy đủ (PDF)

(174 trang)