Giai đoạn thiết kế

1GIAI ĐOẠN THIẾT KẾ ThS. Nguyễn Khắc Quốc IT Department – Tra Vinh University 24.1 Mục tiêu - Giai đoạn thiết kế nhằm: + Xác định chính xác hệ thống sẽ làm việc "như thế nào". + Xác định các bộ phận, các chức năng và các mối liên kết giữa chúng của hệ thống. 34.2 Các công việc Được tiến hành theo 3 mức: Mức tổng thể: + Được thực hiện ở cuối giai đoạn phân tích. + Nó cho thấy kiến trúc chung của hệ thống về cả phần cứng và phần mềm. + Sử dụng các mô hình khái niệm để minh hoạ. Mức giữa: + Tiếp tục việc chia nhỏ bản thiết kế ở mức tổng thể thành các thành phần nhỏ hơn. + Các thành phần của phần cứng được chi tiết đến mức các khối. + Các thành phần phần mềm được chi tiết đến mức các chương trình trong mỗi Môđun hoặc mỗi ứng dụng. + Sử dụng đến các mô hình lôgic để minh hoạ. 44.2 Các công việc (tt) Thiết kế Môđun: + Được tiến hành trong giai đoạn thực hiện) + Là mức hi tiết nhất, nhằm thiết kế ra các thành phần cơ bản tạo ra phần cứng, các chương trình con tạo thành các chương trình phần mềm ứng dụng. + Mức này thường do các chuyên gia phát triển làm trong giai đoạn thực hiện. + Các sơ đồ ở đây chi tiết đến từng dữ liệu và thao tác một. 54.2 Các công việc (tt) Các công việc của giai đoạn thiết kế bao gồm: - Thiết kế hệ thống mức giữa và phối hợp với kết quả thiết kế hệ thống mức tổng thể để viết tài liệu Đặc tả thiết kế (Design Specification - DS) - Soạn thảo tài liệu "Kế hoạch kiểm thử để chấp nhận" (Acceptance Test Plan - ATP). + Là tài liệu liệt kê tất cả các phép thử sẽ phải thực hiện để kiểm tra tất cả các chức năng của hệ thống cho người dùng thấy trong giai đoạn chấp nhận. - Mốc chính của giai đoạn này là tài liệu Đặc tả thiết kế được xem xét thông qua và được chứng tỏ là không sai sót. - Trong giai đoạn này người sử dụng có thể ký duyệt "Kế hoạch kiểm thử để chấp nhận”. 64.3 Một số chú ý - Vai trò và công sức của các nhà quản lý giảm. - Công việc chủ yếu liên quan đến các nhà thiết kế, các chuyên gia phát triển, các lập trình viên và những người xét duyệt. - Vai trò của nhà quản lý chủ yếu chỉ là giám sát và theo dõi. - Tuy nhiên để có thể làm nhà quản lý tốt, ta cũng nên biết được nội dung cơ bản của các công việc đang được tiến hành trong giai đoạn này. Ở đây chúng ta không đi sâu vào các phương pháp và công cụ thiết kế. - Trong giai đoạn thiết kế nên cố gắng phân chia dự án thành các dự án con. - Mỗi dự án con có thể đòi hỏi một người quản lý dự án và một đội thực hiện dự án riêng. 74.4 Đặc tả thiết kế - Là tài liệu mang tính chất kỹ thuật. - Viết để cho các lập trình viên đọc và hiểu để thực hiện. - Người sử dụng cũng có thể đọc song không nhất thiết phải hiểu tất cả. - Khi viết tài liệu này cần chú ý: + Sử dụng ngôn ngữ chặt chẽ, chính xác. + Nguyên nhân lớn thứ hai gây ra sai sót trong hệ thống phần mềm là do lập trình viên hiểu sai thiết kế (Nguyên nhân lớn gây ra sai sót là do nhà phân tích hiểu sai nhu cầu của người dùng). + Sử dụng các sơ đồ, các hình vẽ, các mô hình thiết kế chuẩn. + Nhất quán về ngôn ngữ trình bày, cả về lời văn lẫn các hình vẽ - một người viết toàn bộ. 84.4 Đặc tả thiết kế (tt) Nội dung: 1. Tổng quan về hệ thống thông tin + Các mục tiêu + Các sơ đồ thiết kế cấu trúc 2. Các chuẩn và các quy ước -Trong thiết kế cần thiết lập các chuẩn cho mỗi thành phần. * Phần cứng + Các thành phần: Các sơ đồ cấu trúc, máy chủ, máy trạm, mạng. + Các nhà cung cấp * Phần mềm + Các loại thành phần + Các nhà cung cấp + Các phương pháp thiết kế có cấu trúc + Các phương pháp lập trình có cấu trúc + Các phương pháp kết nối 94.4 Đặc tả thiết kế (tt) 3. Các thành phần chức năng - Liệt kê tất cả các thành phần chức năng, các môđun; - Quyết định làm, mua hay sửa đổi cho thích ứng - Chia thành các thành phần con - Liệt kê các thành phần 4. Các cơ sở dữ liệu, các file và các bảng - Liệt kê tất cả và đối với mỗi loại hãy chỉ rõ: + Mục đích + Sử dụng + Loại - Thiết lập dữ liệu ở mức vật lý + Tạo lập + Duy trì, cập nhật + Tổ chức + Kiểu dạng + Các giới hạn + Vị trí 10 4.5 Một số vấn đề trong quá trình thiết kế 4.5.1 Đội thiết kế - Nhà quản lý dự án phải chọn những người tốt nhất vào đội thiết kế: + Là những người có đầu óc tổng hợp, + Có thể hình dung tổng thể sự việc. - Tránh quan điểm cầu toàn, hoàn thiện trong đội thiết kế. - Có thể tìm ra cách tốt hơn để thực hiện dự án nếu có đủ thời gian và nguồn lực, nhưng cần phải nhớ là chúng ta bị hạn chế về thời gian và kinh phí. - Có nhiều sự so sánh lựa chọn phải làm trong thời gian thiết kế, do đó đội nên có một số lẻ người, hoặc ít ra phải có đội trưởng giỏi, để dễ dàng bỏ phiếu quyết định một vấn đề gì đó cần sự thống nhất. 11 4.5 Một số vấn đề trong quá trình thiết kế (tt) 4.5.2. Rà soát lại bản thiết kế - Cần tiến hành các cuộc họp để rà soát lại bản thiết kế trên khía cạnh kỹ thuật. - Cuộc họp gồm các đại biểu của đội dự án và có thể có thêm các đại biểu từ các nhóm khác. - Khi rà soát lại cần đảm bảo rằng thiết kế: + Đáp ứng tất cả các đặc tả chức năng đã đề ra. + Được chia thành các thành phần một cách lôgic. + Mọi vấn đề kỹ thuật được trình bày rõ ràng, dễ hiểu và nằm trong giới hạn về thời gian và giá cả. 12 4.6 Vấn đề chấp nhận dự án - Chấp nhận dự án nghĩa là người sử dụng khẳng định bằng văn bản rằng sản phẩm đã được cung cấp đúng như thoả thuận, nếu dự án được thực hiện dưới dạng hợp đồng thì cần tiến hành thanh toán hợp đồng. - Mặc dù chưa đến giai đoạn chấp nhận, song giai đoạn thiết kế là thời điểm tốt nhất để bắt đầu lập kế hoạch cho giai đoạn này. - Tại giai đoạn chấp nhận, lần đầu tiên người dùng thực sự mới được trông thấy và sử dụng sản phẩm. - Họ cần kiểm tra để xem có chấp nhận được sản phẩm đó hay không. 13 4.6 Vấn đề chấp nhận dự án (tt) 4.6.1 Phương pháp cổ điển - Giai đoạn chạy thử hoặc cho chạy song song - Giai đoạn chạy thử là giai đoạn đội dự án cài đặt hệ thống và cho người sử dụng chạy thử nghiệm. - Cho chạy song song là hệ thống mới được cài đặt song vẫn duy trì hệ thống cũ và cả hai hệ thống được hoạt động song song để có thể so sánh các kết quả. - Khách hàng sử dụng hệ thống mới trong một khoảng thời gian quy định. - Trong khoảng thời gian này nếu hệ thống hoạt động không nảy sinh vấn đề gì thì hệ thống được chấp nhận. - Nếu có vấn đề nảy sinh thì đội dự án phải sửa chữa, khắc phục và hệ thống lại được chạy thử nghiệm lặp lại một khoảng thời gian nữa. 14 4.6 Vấn đề chấp nhận dự án (tt) Ưu điểm: + Đơn giản, Dễ lập kế hoạch, Nhược điểm. + Phải chạy thử nghiệm lặp đi lặp lại nhiều lần nếu liên tục có nhiều vấn đề nhỏ nảy sinh đối với hệ thống. Đôi khi một hệ thống phần mềm phức tạp có thể không bao giờ sửa chữa hết lỗi được và ta phải biết cách chung sống với lỗi. + Khó tìm được nguyên nhân của những trục trặc nảy sinh. + Khi có nhiều người cùng hoạt động trên một hệ thống phức tạp gồm nhiều thành phần tương tác với nhau thì khi có trục trặc, có thể rất khó biết nguyên nhân tại sao. + Không có gì đảm bảo là các đặc tính cơ bản của hệ thống đã được kiểm tra đầy đủ trong thời gian chạy thử + Có thể để lại ấn tượng không tốt cho người dùng khi hệ thống sinh lỗi. 15 4.6 Vấn đề chấp nhận dự án (tt) 4.6.2 Phương pháp trình diễn hoặc kiểm tra lần lượt tất cả các chức năng + Phương pháp tốt hơn là đưa ra một chuỗi các phép thử để trình diễn và kiểm tra tất cả các chức năng đã thỏa thuận. + Quá trình chấp nhận sẽ tiến hành tất cả các phép thử này đối với khách hàng. + Các phép thử nghiệm thành công sẽ được ký nhận lần lượt. + Nếu phép thử nào thất bại, đội dự án cần khắc phục vấn đề nảy sinh, nếu vấn đề đơn giản thì sửa chữa ngay, nếu vấn đề nghiêm trọng thì quá trình thử nghiệm được hoãn lại cho đến lúc khắc phục xong. + Về nguyên tắc chỉ cần thử lại các phép thử không thành công, song người sử dụng có quyền chạy lại các phép thử đã được chấp nhận trước khi nảy sinh vấn đề. 16 4.6 Vấn đề chấp nhận dự án (tt) Các phương pháp: - Liệt kê tất cả các chức năng mà hệ thống cần phải thực hiện. - Xác định các phép thử nghiệm đối với từng chức năng. - Danh sách các phép thử chính là tài liệu "Kế hoạch kiểm thử chấp nhận". - Thực hiện lần lượt các phép thử nghiệm đối với người sử dụng - Chỉ chạy lại các phép thử nghiệm không thành công, các phép thử nghiệm thành công được người sử dụng ký nhận. 17 4.6 Vấn đề chấp nhận dự án (tt) Những lợi ích: - Có thể trình diễn tất cả các chức năng đã thoả thuận. - Dễ dàng nhận biết nguyên nhân gây ra các trục trặc. - Có thể lặp lại. - Người sử dụng thoải mái khi ký nhiều chữ ký cho từng phần hơn là ký một chữ ký cho toàn bộ. Những nhược điểm: - Phải mất nhiều công sức để viết tài liệu "Kế hoạch kiểm tra để chấp nhận” và thực hiện kế hoạch đó. Người sử dụng không quen với phương pháp này. 18 4.7 Xem xét lại các ước lượng - Tại thời điểm cuối của giai đoạn thiết kế, chúng ta tiếp tục xem xét lại kế hoạch dự án, đặc biệt là xem xét lại các đánh giá. - Mặc dù bây giờ chúng ta chỉ đánh giá bốn giai đoạn còn lại, song phần lập trình trong giai đoạn thực hiện có thể là tốn kém thời gian và công sức nhất trong toàn bộ dự án. - Thiết kế cho chúng ta biết số các môđun và ước lượng độ phức tạp của chúng. - Đồng thời bây giờ ta cũng đã biết ai sẽ là lập trình viên và có thể đưa năng suất của họ vào các đánh giá. - Như vậy, có thể dễ dàng đánh giá chính xác hơn lượng thời gian cần thiết để lập trình. - Thống kê đã cho thầy là vào cuối giai đoạn thiết kế, ước lượng thuộc loại lớp A (sai số ± 10%). 19 4.8 Kết luận Các mốc chính của giai đoạn thiết kế là: 1. Tài liệu đặc tả thiết kế được hoàn thành và thông qua 2. Soạn thảo tài liệu Kế hoạch kiểm tra để chấp nhận 3. Đánh giá lại các ước lượng 20 Câu hỏi thảo luận 1. Mục tiêu của giai đoạn thiết kế là gì? 2. Các mục của giai đoạn thiết kế là gì? 3. Các ưu điểm và nhược điểm của các phương pháp kiểm tra để chấp nhận dự án.