Xây dựng và chuyển đổi hệ thống

Chia sẻ: Anh Vu Duong | Ngày: | Loại File: PPT | Số trang:46

Thêm vào BST

Báo xấu

74
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Xây dựng là sự triển khai tất cả các phần của hệ thống, trong đó chủ yếu bao gồm: Bản thân phần mềm HTTT. Lập tài liệu hệ thống. Thủ tục qui trình xử lý công việc mới. Trọng tâm của giai đoạn này là lập trình

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Xây dựng và chuyển đổi hệ thống

Xây dựng và chuyển đổi hệ thống 1
Xâ y d ựn g v à c h u y ển đ ổi HT Mở đ ầu  Quản lý lập trình Thiết kế kiểm thử Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống 2
1. Mở đầu • Xây dựng là sự triển khai tất cả các phần của hệ thống, trong đó chủ yếu bao gồm: Bản thân phần mềm HTTT. Lập tài liệu hệ thống. Thủ tục qui trình xử lý công việc mới. • Trọng tâm của giai đoạn này là lập trình, theo sau là kiểm thử (test) kết quả lập trình. • Một sai lầm thường thấy là nhiều lập trình viên xem thường việc kiểm thử và lập tài liệu hệ thống. 3
• Các tổ chức chuyên nghiệp sẳn sàng mất thời gian và tốn tiền cho việc kiểm thử và lập tài liệu HT nhằm ngăn chận những sai lầm có thể xảy ra sau khi HT được cài đặt. • Lập trình được đề cập nhiều ở các môn học lập trình. Do đó ở đây nhấn mạnh đến: Quản lý việc lập trình. Kiểm thử chương trình. Lập tài liệu hệ thống. 4
Xâ y d ựn g v à c h u y ển đ ổi HT Mở đầu Qu ản lý l ập t rìn h  Thiết kế kiểm thử Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống 5
2. Quản lý lập trình • Thông thường thì PTV không phải lập trình, các lập trình viên (LTV) sẽ lập trình. PTV sẽ quản lý việc lập trình của các LTV. • Quản lý việc lập trình liên quan đến: Gán các môđun cho LTV. Phối hợp các hoạt động. Quản lý lịch trình. 6
• Gán các môđun cho LTV. PTV nhóm các môđun liên quan với nhau và giao cho LTV. Trong nhiều công việc, nhiều người làm tốt hơn ít người làm và công việc sẽ xong nhanh. Đối với phát triển hệ thống (lập trình), nhiều LTV tham gia có thể làm chậm dự án. Tại sao? Nhiều LTV sẽ làm tăng các hoạt động phối hợp và còn ít thời gian lập trình. Dự án phức tạp đòi hỏi nhóm lớn LTV nên chia thành nhiều phần nhỏ độc lập. 7
• Phối hợp các hoạt động. Họp đều đặn, hiệu quả. Khuyến khích các LTV trao đổi các vấn đề trước khi chúng có thể trở thành những khó khăn, rủi ro. Trao đổi về những vấn đề phát sinh, những thay đổi về yêu cầu, các chuẩn và qui ước chung liên quan lập trình. Nhiều dự án tổ chức việc lập trình thành ba khu vực gồm khu vực phát triển (lập trình), khu vực kiểm thử và khu vực sản phẩm. 8
• Các khu vực hoạt động phối hợp như sau: Khu vực phát triển chịu trách nhiệm lập trình. Các chương trình hoàn thành được copy và chuyển đến khu vực kiểm thử. Khu vực kiểm thử chịu trách nhiệm test chương trình. Nếu không đạt sẽ được chuyển trở lại khu vực phát triển. Khi tất cả chương trình được test và sẳn sàng hỗ trợ HT mới thì sẽ được copy chuyển đến khu vực sản phẩm. Tại đây HT cuối cùng được hình thành. 9
• Ba khu vực này có thể ở ba thư mục khác nhau trên đĩa cứng server, ở ba server khác nhau, hoặc ở ba chỗ làm việc khác nhau. • Việc sao chép để giữ các files và chương trình ứng với tình trạng hoàn thành sẽ giúp PTV kiểm soát được sự thay đổi. • Một kỹ thuật quản lý khác là PTV có thể dùng program log. Đây là một form trên đó PTV ký nhận CT để viết, và ký xác nhận CT hoàn thành. • Khu vực lập trình và program log giúp PTV biết được sự làm việc của LTV và tình trạng các CT. 10
• Quản lý lịch trình. Luôn đối chiếu với thời gian được hoạch định trong dự án. Điều chỉnh thời gian thích hợp khi việc xây dựng HT bắt đầu tiến hành. Coi chừng vấn đề “scope creep” do sự phát sinh yêu cầu mới. Cần chống lại khuynh hướng giảm chất lượng lập trình để đúng với lịch trình dự kiến. 11
• Một trong những vấn đề gây khó khăn nhất cho việc quản lý lịch trình là yêu cầu HT thay đổi hoặc bổ sung trong quá trình xây dựng HT. • Tránh những lỗi “cổ điển” sau đây khi phát triển hệ thống: Phát triển HT chạy theo nghiên cứu. Dùng lập trình viên “lương thấp”. Mất đi sự kiểm soát mã lập trình. Tổ chức kiểm thử không phù hợp. 12
Xâ y d ựn g v à c h u y ển đ ổi HT Mở đầu Quản lý lập trình Th i ết k ế ki ểm t h ử  Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống 13
3. Thiết kế kiểm thử • Nguyên tắc kiểm thử. Sẽ nguy hiểm nếu như test các môđun quá sớm trong khi chưa có kế hoạch kiểm thử. Việc kiểm thử không có kế hoạch sẽ làm cho các test quan trọng có thể được xem xét không chi tiết và rất khó để tạo lại chuỗi biến cố gây nên lỗi sai. Việc kiểm thử phải được thực hiện một cách có hệ thống và các kết quả kiểm thử phải được lập tài liệu cẩn thận. 14
• Việc kiểm thử phải được bắt đầu bằng việc lên kế hoạch kiểm thử cho các tester. • Kế hoạch kiểm thử xác định dãy các test cần được tiến hành. • Mỗi một test trong kế hoạch kiểm thử phải có mục tiêu cụ thể, tập các test cases phải được mô tả rõ ràng và chính xác, phải dự đoán kết quả test, và ghi rõ kết quả test thực sự thu được. • Trong thực tế các test cases không thể vét cạn các tổ hợp có thể có. Do vậy cần phải chọn các test cases điển hình. 15
• Khi test không phải tất cả các môđun đều xong cùng lúc để có thể kết hợp khi test. Do vậy cần viết các stub đối với các môđun chưa hoàn thành để có thể tiến hành test. • Stub là nơi giữ chỗ cho môđun chưa hoàn thành. Một stub đơn giản có thể chỉ là một thông báo cho biết môđun làm công việc gì. • Ví dụ test môđun thực đơn, có thể các môđun công việc chưa viết xong. Khi test thực đơn thì lúc chọn công việc chỉ cần xuất ra màn hình thông báo công việc đó là gì. 16
Ví dụ kế hoạch kiểm thử. 17
• Phân loại các test. Test từng phần: Test các cấu trúc điều khiển trước khi môđun hoàn thành. Test đơn vị: Test từng môđun để bảo đảm nó thực hiện đúng chức năng. Test tổng hợp: Test sự tương tác giữa các môđun để bảo đảm chúng phối hợp được. Test hệ thống: Test nhằm bảo đảm phần mềm làm việc tốt (as part of overall system). Test chấp nhận: Test nhằm bảo đảm hệ thống đáp ứng nhu cầu của tổ chức. 18
• Test từng phần (Stub Tests). Có thể tạo các stub giữ chỗ cho các môđun để có thể test menu. 19
• Test đơn vị (Unit Tests). Kiểm tra xem đơn vị có thực hiện đúng chức năng đã xác định trong đặc tả CT không. Đơn vị có thể là môđun hoặc CT. Có hai cách tiếp cận để test gọi là hộp đen (blackbox) và hộp trắng (whitebox). Test kiểu hộp đen tức là xem chương trình như là hộp đen, vào input và test các output. Test kiểu hộp trắng tức là xem chi tiết các đoạn mã lập trình. Có thể không cần xem hết, chỉ xem các đoạn mã quan trọng. 20