Bài giảng Nhập môn công nghệ phần mềm - Phan Phương Lan

229 trang hapham 1200

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Nhập môn công nghệ phần mềm - Phan Phương Lan", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_giang_nhap_mon_cong_nghe_phan_mem_phan_phuong_lan.pdf

Nội dung text: Bài giảng Nhập môn công nghệ phần mềm - Phan Phương Lan

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM GIỚI THIỆU 1 Phan Phương Lan Nội dung z Phần I: Tổng quan về Công nghệ phần mềm z Chương 1: Giới thiệu về Công nghệ phần mềm z Chương 2: Các mô hình về tiến trình phần mềm z Chương 3: Quản lý phần mềm z Quản lí nhân sự và tổ chức z Quản lí chất lượng z Quản lí cấu hình z Quản lí dự án z Chương 4: Ước lượng giá thành z Phần II: Tiến trình phần mềm z Chương 5: Đặc tả yêu cầu z Chương 6: Thiết kế z Chương 7: Lập trình z Chương 8: Kiểm thử z Chương 9: Triển khai hệ thống z Chương 10: Bảo trì 2
Tài liệu tham khảo z Sách tham khảo chính: z Shari Lawrence Pleeger, Joanne M.Atlee, Software Engineering theory and practice, 3th edition, 2006. z Ian Sommerville, Software Engineering, 8th edition, 2006. z Sách đọc thêm: z Hans Van Vliet, Software Engineering principles and practice, John Wiley, 2000. z Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill, 5th edition, 2003. 3
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 1 – GIỚI THIỆU VỀ CÔNG NGHỆ PHẦN MỀM 1 Nội dung z Định nghĩa về CNPM z Các giai đoạn trong phát triển phần mềm z Những người tham gia trong dự án phát triển phần mềm z Các yếu tố chính làm thay đổi sự phát triển phần mềm 2
Định nghĩa về CNPM z IEEE: CNPM là (1) Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hóa trong phát triển, vận hành và bảo trì phần mềm; (2) Nghiên cứu các phương pháp tiếp cận được dùng trong (1) z NATO: CNPM là việc thiết lập và dùng các nguyên tắc công nghệ đúng đắn để thu được phần mềm một cách kinh tế nhất và chạy hiệu quả trên các máy thật. 3 Định nghĩa về CNPM z Mục tiêu của CNPM là làm sao để tạo ra phần mềm: z Có chất lượng cao z Đúng, thỏa yêu cầu khách hàng z Dễ khai thác, vận hành z Dễ bảo trì z Đúng kế hoạch thời gian z Trong phạm vi ngân sách dự kiến z Giá thành ngày càng hạ 4
Các giai đoạn phát triển phần mềm Định nghĩa & Phân tích yêu cầu Thiết kế Cài đặt Kiểm thử Phát hành 5 Bảo trì Các giai đoạn phát triển phần mềm z Định nghĩa & Phân tích yêu cầu: thu thập mô tả đầy đủ của bài toán z Chức năng/tính năng của PM z Khả năng mở rộng z Các loại tài liệu đòi hỏi z Thời gian đáp ứng hoặc các yêu cầu về chất lượng của hệ thống z Nghiên cứu khả thi z Thiết kế: thiết kế hệ thống và thiết kế chi tiết 6
Các giai đoạn phát triển phần mềm z Cài đặt: tập trung vào từng module riêng lẻ: z Giải thuật z Tài liệu z Coding z Kiểm thử (kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống): thử và xác nhận tính đúng đắn của z Tài liệu đặc tả z Thiết kế z Module z Chuyển tiếp giữa các giai đoạn 7 Các giai đoạn phát triển phần mềm z Bảo trì z Sửa lỗi sau khi phần mềm đã được triển khai z Đáp ứng sự thay đổi yêu cầu, sự thay đổi về môi trường, v.v 8
Các giai đoạn phát triển phần mềm z Công sức của từng giai đoạn: 40 – 20 – 40 Thiết kế 15% Cài đặt 20% Đặc tả 10% Xác định yêu cầu 10% Kiểm thử 45% 9 Các giai đoạn phát triển phần mềm z Công sức của từng giai đoạn – Giai đoạn bảo trì z Hoạt động bảo trì chiếm khoảng 50 – 70% toàn bộ công sức z Các loại bảo trì: Hoàn thiện, Phòng ngừa, Hiệu chỉnh và Thích ứng z Sự phân phối của các loại bảo trì Hiệu chỉnh 21% Hoàn thiện50% Thích ứng 25% Phòng ngừa4% 10
Những người tham gia trong dự án phát triển phần mềm z Những người tham gia: Khách hàng, Nhà phát triển và Người sử dụng. 11 Những người tham gia trong dự án phát triển phần mềm z Các thành viên trong đội phát triển phần mềm: z Nhà phân tích yêu cầu: làm việc với khách hàng để xác định và tư liệu hóa các yêu câu z Nhà thiết kế: tạo ra bản mô tả mức hệ thống về cái mà hệ thống phải thực hiện z Lập trình viên: viết mã lệnh cài đặt sự thiết kế z Nhà kiểm thử: bắt các lỗi z Người hướng dẫn: chỉ dẫn người dùng cách sử dụng hệ thống z Bảo trì viên: chỉnh sửa các lỗi khi hệ thống đã được phát hành và đáp ứng các thay đổi z Thủ thư: chuẩn bị và lưu giữ các tài liệu chẳng hạn như các đặc tả yêu cầu z Nhóm quản lý cấu hình: duy trì sự phù hợp giữa các thành phần được tạo ra 12
Những người tham gia trong dự án phát triển phần mềm z Các vai trò tiêu biểu được thực hiện bởi những thành viên trong đội phát triển phần mềm 13 Các yếu tố chính làm thay đổi sự phát triển phần mềm z Các yếu tố chính: 14
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 2 – CÁC MÔ HÌNH VỀ TIẾN TRÌNH PHẦN MỀM 1 Nộidung z Tiến trình z Các mô hình về tiến trình phần mềm z Mô hình thác nước z Mô hình chữ V z Mô hình bản mẫu z Mô hình phát triển ứng dụng nhanh z Mô hình gia tăng z Mô hình xoắn ốc z Mô hình RUP 2
Tiến trình (Process) z Tiến trình: một chuỗi các bước bao gồm các hoạt động, các ràng buộc và các tài nguyên mà chúng tạo ra kết quả được mong đợi z Tiến trình: bao gồm một bộ các công cụ và các kỹ thuật 3 Tiến trình z Các đặc trưng của tiến trình z Quy định tất cả các hoạt động chính của tiến trình z Sử dụng các nguồn tài nguyên, phụ thuộc vào tập các ràng buộc (chẳng hạn như kế hoạch làm việc) z Tạo ra các sản phẩm cuối cùng hoặc trung gian z Có thể được tạo thành từ các tiến trình con bằng hệ thống phân cấp hay các liên kết 4
Tiến trình z Các đặc trưng của tiến trình z Mỗi hoạt động của tiến trình có tiêu chuẩn vào và ra z Các hoạt động được tổ chức theo trình tự vì thế sự tính toán về thời gian là rõ ràng z Mỗi tiến trình có các nguyên tắc hướng dẫn, bao gồm các mục tiêu của từng hoạt động z Các ràng buộc có thể áp dụng vào một hoạt động, tài nguyên hay sản phẩm 5 Tiến trình z Tầm quan trọng của tiến trình z Áp đặt cấu trúc và tính bền vững lên một tập các hoạt động z Hướng dẫn ta hiểu, điều khiển, kiểm tra và cải thiện các hoạt động z Cho phép ta có được các kinh nghiệm 6
Tiến trình z Lý do để mô hình hóa một tiến trình z Hình thành một cách hiểu chung z Tìm ra sự không nhất quán, sự dư thừa hay sự bỏ sót z Tìm ra và đánh giá các hoạt động phù hợp để đạt được các mục tiêu của tiến trình z Cụ thể hóa một tiến trình chung cho một hoàn cảnh cụ thể 7 Tiến trình z Chu kỳ sống của phần mềm z Khi một tiến trình liên quan tới việc xây dựng một phần mềm, tiến trình có thể được xem như chu kỳ sống của phần mềm. 8
Các mô hình về tiến trình phần mềm z Mô hình thác nước z Mô hình chữ V z Mô hình bản mẫu z Mô hình phát triển ứng dụng nhanh z Mô hình gia tăng z Mô hình xoắn ốc z Mô hình RUP 9 Mô hình thác nước (Waterfall Model) z Một trong các mô hình đầu tiên về tiến trình phần mềm z Phù hợp với những bài toán được hiểu kỹ có rất ít hay không có các thay đổi về yêu cầu z Đơn giản và dễ giải thích với khách hàng z Nó biểu diễn z Một tổng quan mức rất cao của tiến trình phát triển z Một chuỗi tuần tự các hoạt động của tiến trình 10
Mô hình thác nước Phân tích yêu cầu Thiết kế hệ thống Thiết kế chi tiết Lập trình Kiểm thử đơn vị & tích hợp Kiểm thử hệ thống Kiểm thử chấp nhận Vận hành & bảo trì 11 Mô hình thác nước z Không có sự lặp lại trong mô hình thác nước z Thực tế, các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có lặp lại 12
Mô hình thác nước z Hạn chế của mô hình thác nước z Không có các hướng dẫn về cách thức xử lý những thay đổi về sản phẩm và hoạt động trong suốt sự phát triển z Xem sự phát triển phần mềm như một tiến trình sản xuất hơn là tiến trình sáng tạo z Không có các hoạt động lặp để tạo ra sản phẩm cuối z Phảichờđợilâutrướckhicósảnphẩmcuối 13 Mô hình chữ V (V Model) z Một sự biến đổi của mô hình thác nước z Sử dụng kiểm thử đơn vị để xác minh (verify) thiết kế chi tiết z Sử dụng kiểm thử tích hợp để xác minh thiết kế hệ thống z Sử dụng kiểm thử chấp nhận để thẩm định (validate) các yêu cầu z Nếu các vấn đề được tìm thấy trong suốt sự xác minh và thẩm định, phần bên trái của mô hình chữ V có thể được tái thực hiện trước khi việc kiểm thử phần bên phải được tái thực hiện 14
Mô hình chữ V 15 Mô hình bản mẫu (Prototyping Model) z Cho phép sự nghiên cứu về các yêu cầu và thiết kế được lặp lại z Giảm sự rủi ro và sự không chắc chắn trong phát triển z Sử dụng mô hình bản mẫu khi các yêu cầu chưa rõ ràng 16
Mô hình bản mẫu 17 Mô hình phát triển ứng dụng nhanh (Rapid Application Development: RAD) z Là tiếntrìnhpháttriểnphầnmềmgiatăng z Thời gian phát triểnphần mềm rấtngắn z Sử dụng các kỹ thuật thế hệ thứ tư z Xây dựng dựatrênhướng thành phầnvớikhả năng tái sử dụng z Gồmmộtsố nhóm, mỗi nhóm làm 1 RAD theo các pha: Mô hình hóa nghiệpvụ, Mô hình hóa dữ liệu, Mô hình hóa xử lý, Tạo ứng dụng, Kiểmthử và đánh giá ( Business, Data, Process, Application Generation, Testing) 18
Team #3 BusinessBusiness ModelingModeling Team #2 DataData Mô hình Business ModelingModeling Business ProcessProcess Modeling Modeling phát triển Modeling Modeling Team #1 DataData ApplicationApplication Modeling GenerationGeneration ứng dụng Business Modeling Testing & Business ProcessProcess Testing & TurnoverTurnover nhanh ModelingModeling ModelingModeling Data ApplicationApplication Data Generation ModelingModeling Generation TestingTesting & & ProcessProcess TurnoverTurnover ModelingModeling ApplicationApplication GenerationGeneration TestingTesting&& TurnoverTurnover 60 - 90 days 19 Mô hình phát triển ứng dụng nhanh z Cầnnguồnnhânlựcdồidàođể tạo các nhóm cho các chứcnăng chính z Yêu cầuhaibêncam kết trong thờigianngắnphảicó phầnmềmhoànchỉnh, thiếutráchnhiệmcủamộtbên dễ làm dự án đổ vỡ z RAD không phảitốtchomọi ứng dụng, nhấtlàvới ứng dụng không thể module hóa hoặc đòi hỏitính năng cao z RAD không phù hợp khi các rủi ro kỹ thuật cao 20
Mô hình gia tăng (Incremental Model) z Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu z Sản phẩm lõi cho những yêu cầu cơ bản nhất của hệ thống được phát triển z Các chức năng cho những yêu cầu khác được phát triển thêm sau (gia tăng) z Lặp lại quy trình để hoàn thiện dần 21 Mô hình gia tăng Phát hành lần 1 Phát hành lần 2 22
Mô hình xoắn ốc (Spiral Model) z Được đề nghị bởi Boehm (1988) z Kết hợp các hoạt động phát triển với sự quản lý rủi ro để giảm đến mức tối thiểu và kiểm soát các rủi ro z Thích hợp với các hệ lớn z Mô hình được trình bày ở dạng xoắn ốc trong đómỗi lần lặp được biểu diễn bởi một đường vòng gồm bốn hoạt động chính z Lập kế hoạch z Xác định các mục tiêu, các lựa chọn và các ràng buộc z Đánh giá các lựa chọn và các rủi ro z Phát triển và kiểm thử 23 Mô hình xoắn ốc 24
RUP – Rational Unified Process z Bổ sung cho UML z Cách tiếp cận lặp cho các hệ thống hướng đối tượng, bao gồm các use case để mô hình hóa các yêu cầu z Các giai đoạn của RUP z Inception: thiết lập phạm vi, giới hạn, các use case quan trọng, các kiến trúc ứng viên, các dự đoán về chi phí và kế hoạch làm việc z Elaboration: đạt được kiến trúc hoàn chỉnh, thiết lập sự hỗ trợ công cụ, có tất cả các use case, giải quyết tất cả các rủi ro chính z Construction: xây dựng tiến trình, một hay nhiều sự phát hành z Transition: phát hành ra cộng đồng người dùng, thường là một số phát hành 25 RUP 26
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 3 - QUẢN LÝ 1 NỘI DUNG z Qu¶n lý nh©n sù z Qu¶n lý chÊt l−îng z Qu¶n lý cÊu h×nh z Qu¶n lý dù ¸n (LËp kÕ ho¹ch vμ kiÓm so¸t dù ¸n) 2
Nội dung – Quản lý nhân sự z Chän nh©n sù z Thóc ®Èy nh©n sù z Qu¶n lý nhãm 3 Chän nh©n sù z Nh©n sù lμ thμnh phÇn quan träng nhÊt cña tæ chøc z ViÖc qu¶n lý nh©n sù kÐm sÏ dÉn ®Õn sù thÊt b¹i cña dù ¸n z C¸c yÕu tè qu¶n lý nh©n sù z Kh«ng ph©n biÖt ®èi xö z T«n träng z L¾ng nghe z Trung thùc 4
Chän nh©n sù z Mét c«ng viÖc qu¶n lý dù ¸n quan träng lμ chän nhãm lμm viÖc z C¸c th«ng tin cÇn cho sù lùa chän nh©n sù gåm: z Th«ng tin ®−îc cung cÊp bëi øng viªn z Th«ng tin do pháng vÊn vμ nãi chuyÖn víi øng viªn z Th«ng tin tõ th− tiÕn cö hay sù giíi thiÖu cña nh÷ng ng−êi biÕt hay nh÷ng ng−êi lμm viÖc víi øng viªn 5 Chän nh©n sù z Mét sè l−u ý trong viÖc chän nh©n sù z C¸c nhμ qu¶n lý trong c«ng ty kh«ng muèn mÊt ng−êi cho c¸c dù ¸n míi. V× vËy, ta ph¶i chÊp nhËn nh÷ng ng−êi chØ cã thÓ lμm viÖc b¸n thêi gian trong dù ¸n. z C¸c kü n¨ng cÇn thiÕt cho dù ¸n lμ khan hiÕm => kh«ng cã ®−îc nhiÒu øng viªn ®Ó chän. z Nh÷ng sinh viªn míi ra tr−êng kh«ng cã nhiÒu kinh nghiÖm cô thÓ nh−ng hä th−êng nhiÖt t×nh vμ dÔ häc c«ng nghÖ míi z Sù thμnh th¹o vÒ kü thuËt cã thÓ Ýt quan träng h¬n c¸c kü n¨ng x· héi 6
Chän nh©n sù z C¸c yÕu tè t¸c ®éng lªn viÖc chän nh©n sù z Kinh nghiÖm vÒ lÜnh vùc øng dông z Kinh nghiÖm vÒ nÒn t¶ng z Kinh nghiÖm vÒ ng«n ng÷ lËp tr×nh z Kh¶ n¨ng gi¶i quyÕt vÊn ®Ò z NÒn t¶ng gi¸o dôc z Kh¶ n¨ng giao tiÕp z TÝnh thÝch øng z Th¸i ®é z TÝnh c¸ch 7 Thúc đẩy nhân sự z Mét vai trß quan träng cña nhμ qu¶n lý lμ thóc ®Èy nh©n sù lμm viÖc trong dù ¸n z §éng c¬ thóc ®Èy lμ mét vÊn ®Ò phøc t¹p. z C¸c lo¹i ®éng c¬ thóc ®Èy ®−îc dùa trªn: z C¸c nhu cÇu c¬ b¶n (l−¬ng thùc, thêi gian ngñ, v.v); z C¸c nhu cÇu c¸ nh©n (sù t«n träng, lßng tù träng, v.v); z C¸c nhu cÇu x· héi (®−îc chÊp nhËn lμ mét thμnh viªn cña nhãm, v.v) 8
Thúc đẩy nhân sự Sù ph©n cÊp c¸c nhu cÇu cña con ng−êi 9 Thúc đẩy nhân sự z §¶m b¶o tháa m·n c¸c nhu cÇu vÒ: z X· héi z Cung cÊp c¸c ph−¬ng tiÖn giao tiÕp z Cho phÐp c¸c giao tiÕp kh«ng h×nh thøc z Sù quý träng z C«ng nhËn c¸c thμnh tÝch z C¸c phÇn th−ëng t−¬ng xøng z Sù ph¸t triÓn n¨ng khiÕu b¶n th©n z §μo t¹o – nh÷ng ng−êi muèn häc nhiÒu h¬n z Tr¸ch nhiÖm 10
Thúc đẩy nhân sự z §éng c¬ thóc ®Èy cßn quan t©m tíi c¸c kiÓu tÝnh c¸ch: z H−íng tíi c«ng viÖc z H−íng tíi b¶n th©n z H−íng tíi sù t−¬ng t¸c 11 Thúc đẩy nhân sự z TÝnh c¸ch h−íng tíi c«ng viÖc z §éng c¬ thóc ®Èy lμm viÖc chÝnh lμ c«ng viÖc z TÝnh c¸ch h−íng tíi b¶n th©n z C«ng viÖc lμ mét ph−¬ng tiÖn ®Ó ®¹t ®−îc c¸c môc tiªu c¸ nh©n z TÝnh c¸ch h−íng tíi sù t−¬ng t¸c z §éng c¬ thóc ®Èy chñ yÕu lμ sù hiÖn diÖn vμ c¸c ho¹t ®éng cña nh÷ng ng−êi cïng lμm viÖc 12
Thúc đẩy nhân sự z C©n b»ng ®éng c¬ thóc ®Èy z C¸c ®éng c¬ thóc ®Èy c¸ nh©n ®−îc t¹o thμnh tõ nhiÒu yÕu tè z Sù c©n b»ng cã thÓ thay ®æi tïy thuéc vμo hoμn c¶nh c¸ nh©n vμ c¸c sù kiÖn bªn ngoμi z Con ng−êi kh«ng chØ ®−îc thóc ®Èy bëi c¸c yÕu tè c¸ nh©n mμ cßn bëi viÖc trë thμnh mét phÇn cña nhãm hay v¨n hãa z Con ng−êi lμm viÖc v× hä ®−îc thóc ®Èy bëi nh÷ng ng−êi mμ hä lμm cïng 13 Quản lý nhóm z HÇu hÕt ho¹t ®éng phÇn mÒm lμ ho¹t ®éng nhãm v× mét dù ¸n phÇn mÒm kh«ng thÓ hoμn thμnh bëi duy nhÊt mét ng−êi z Sù t−¬ng t¸c nhãm lμ yÕu tè quyÕt ®Þnh then chèt sù thùc hiÖn cña nhãm z TÝnh linh ®éng trong kÕt cÊu nhãm bÞ h¹n chÕ do c¸c nhμ qu¶n lý ph¶i lμm c¸i tèt nhÊt mμ hä cã thÓ víi nh©n sù hiÖn cã 14
Quản lý nhóm z C¸c yÕu tè chi phèi ®Õn c«ng viÖc nhãm z KÕt cÊu nhãm z Sù g¾n kÕt nhãm z C¸c giao tiÕp nhãm z Tæ chøc cña nhãm 15 Quản lý nhóm z KÕt cÊu nhãm z Nhãm ®−îc t¹o thμnh tõ nh÷ng thμnh viªn cã cïng ®éng c¬ thóc ®Èy cã thÓ cã vÊn ®Ò z H−íng c«ng viÖc – mçi ng−êi muèn lμm c«ng viÖc cña chÝnh hä z H−íng b¶n th©n – mçi ng−êi ®Òu muèn l·nh ®¹o z H−íng t−¬ng t¸c – nãi qu¸ nhiÒu 16
Quản lý nhóm z KÕt cÊu nhãm z Mét nhãm hiÖu qu¶ ph¶i cã sù c©n b»ng cña tÊt c¶ c¸c tÝnh c¸ch z Ng−êi h−íng tíi c«ng viÖc th−êng m¹nh vÒ kü thuËt z Ng−êi h−íng tíi b¶n th©n th−êng thóc ®Èy sù hoμn thμnh c«ng viÖc z Ng−êi h−íng tíi sù t−¬ng t¸c gióp cho sù giao tiÕp trong nhãm thuËn tiÖn h¬n 17 Quản lý nhóm z KÕt cÊu nhãm z L·nh ®¹o nhãm z Tr¸ch nhiÖm cña l·nh ®¹o nhãm lμ: Cung cÊp c¸c chØ dÉn kü thuËt vμ c¸c qu¶n lý dù ¸n Ph¶i n¾m ®−îc c«ng viÖc hμng ngμy cña nhãm ®Ó ®¶m b¶o mäi ng−êi lμm viÖc hiÖu qu¶ vμ lμm viÖc víi nhμ qu¶n lý dù ¸n theo kÕ ho¹ch cña dù ¸n z Trong mét nhãm, cã thÓ cã c¶ 1 l·nh ®¹o kü thuËt vμ 1 l·nh ®¹o qu¶n lý z Sù l·nh ®¹o nhãm dùa trªn sù t«n träng, sù l·nh ®¹o d©n chñ hiÖu qu¶ h¬n sù l·nh ®¹o chuyªn quyÒn 18
Sự gắn kết nhóm z Trong mét nhãm g¾n kÕt, c¸c thμnh viªn xem nhãm lμ quan träng h¬n bÊt cø c¸ nh©n nμo trong nhãm z ThuËn lîi cña nhãm g¾n kÕt: z ChuÈn vÒ chÊt l−îng nhãm ®−îc ph¸t triÓn z C¸c thμnh viªn trong nhãm lμm viÖc cïng víi nhau v× thÕ c¸c h¹n chÕ vÒ sù kh«ng hiÓu biÕt gi¶m z C¸c thμnh viªn trong nhãm häc lÉn nhau vμ biÕt ®−îc c«ng viÖc cña nhau 19 Sự gắn kết nhóm z Ph¸t triÓn tÝnh g¾n kÕt z TÝnh g¾n kÕt bÞ ¶nh h−ëng bëi c¸c yÕu tè nh− v¨n hãa cña tæ chøc, c¸c tÝnh c¸ch trong nhãm z TÝnh g¾n kÕt cã thÓ ®−îc khuyÕn khÝch th«ng qua z Tæ chøc c¸c sù kiÖn x· héi z Ph¸t triÓn mét tªn riªng vμ mét lÜnh vùc cña nhãm z Thùc hiÖn c¸c ho¹t ®éng x©y dùng nhãm z TÝnh më cña th«ng tin lμ mét c¸ch ®¬n gi¶n ®Ó ®¶m b¶o tÊt c¶ c¸c thμnh viªn trong nhãm c¶m thÊy lμ mét phÇn cña nhãm 20
Sự gắn kết nhóm z Nh÷ng vÊn ®Ò cã thÓ x¶y ra trong c¸c nhãm g¾n kÕt: z Chèng l¹i ng−êi l·nh ®¹o míi ®−îc chØ ®Þnh tõ bªn ngoμi nhãm. z Gi¶i quyÕt: chän l·nh ®¹o míi lμ ng−êi trong nhãm z Suy nghÜ nhãm => c¸c kh¶ n¨ng phª b×nh bÞ xãi mßn z Gi¶i quyÕt: tæ chøc c¸c buæi häp chÝnh thøc vμ mêi chuyªn gia tõ bªn ngoμi phª b×nh c¸c quyÕt ®Þnh cña nhãm 21 Giao tiếp nhóm z C¸c giao tiÕp tèt lμ cÇn thiÕt gióp cho lμm viÖc nhãm hiÖu qu¶ z C¸c th«ng tin ph¶i ®−îc trao ®æi: t×nh tr¹ng c«ng viÖc, c¸c quyÕt ®Þnh thiÕt kÕ, nh÷ng thay ®æi ®èi víi c¸c quyÕt ®Þnh tr−íc ®ã z C¸c giao tiÕp tèt cßn lμm gia t¨ng tÝnh g¾n kÕt nhãm v× nã thóc ®Èy sù hiÓu biÕt 22
Giao tiếp nhóm z C¸c yÕu tè t¸c ®éng lªn tÝnh hiÖu qu¶ trong giao tiÕp z Qui m« nhãm z Nhãm cμng lín, mäi ng−êi cμng khã giao tiÕp hiÖu qu¶ víi c¸c thμnh viªn kh¸c trong nhãm z CÊu tróc nhãm z Sù giao tiÕp lμ tèt h¬n trong c¸c nhãm ®−îc tæ chøc tù do h¬n lμ trong c¸c nhãm ®−îc cÊu tróc ph©n cÊp z KÕt cÊu nhãm z Sù giao tiÕp lμ tèt h¬n nÕu nhiÒu thμnh viªn trong nhãm cã tÝnh c¸ch kh¸c nhau vμ cã c¶ nam vμ n÷ z M«i tr−êng lμm viÖc tù nhiªn z ViÖc tæ chøc n¬i lμm viÖc tèt cã thÓ khuyÕn khÝch sù giao tiÕp 23 Tổ chức nhóm z C¸c tæ chøc nhãm z Tæ chøc ph©n cÊp z Tæ chøc ma trËn z Nhãm lËp tr×nh viªn chÝnh z Nhãm SWAT z Nhãm lËp tr×nh nhanh 24
Tổ chức nhóm z Tổ chức phân cấp z Phân nhóm chức năng z Phản ánh cấu trúc tổng thể của dự án z Nhược điểm: Khoảng cách giao tiếp xa, thông tin nhiễu 25 Tổ chức nhóm z Tổ chức ma trận z Các nhóm bộ phận có chuyên môn sâu z Tham gia bán thời gian vào các dự án khác nhau z Người quản lí dự án chịu trách nhiệm cho sự thành công toàn bộ dự án và nâng cao kiến thức chuyên môn của nhóm. 26
Tổ chức nhóm z Nhóm lập trình viên chính z Hạt nhân của mỗi nhóm gồm 3 người: z Trưởng nhóm: thiết kế và cài đặt phần chính của hệ thống z Trợ lý: giúp việc cho trưởng nhóm z Người quản lí tài liệu z Cần có một trưởng nhóm giỏi kỹ thuật và năng lực quản lí tốt z Lưu ý: công việc không có cấu trúc, không có người phân tích, người thiết kế, lập trình viên 27 Tổ chức nhóm z Nhóm SWAT(Skilled With Advanced Tools) z Nhóm nhỏ: 4-5 người z Thường áp dụng trong tiến trình theo mô hình gia tăng z Dùng ngôn ngữ cấp cao, các gói dùng lại, các phần mềm sinh mã. z Nhóm trưởng là người giỏi 28
Tổ chức nhóm z Nhóm lập trình nhanh z Làm việc theo cặp z Người chính z Người phụ z Đổi vai trò 29 Nội dung – Quản lý chất lượng z Quản lý chất lượng phần mềm z Đảm bảo chất lượng và các chuẩn z Lập kế hoạch chất lượng z Kiểm soát chất lượng 30
Quản lý chất lượng phần mềm z Quản lý chất lượng phần mềm z Liên quan tới việc đảm bảo một sản phẩm phần mềm đạt được mức chất lượng được yêu cầu z Liên quan đến việc định nghĩa các thủ tục và các chuẩn chất lượng phù hợp và đảm bảo rằng tất cả các chuẩn và thủ tục này được tuân theo z Hướng tới phát triển một ‘văn hóa chất lượng’ nơi chất lượng được xem là trách nhiệm của mọi người 31 Quản lý chất lượng phần mềm z Phạm vi của quản lý chất lượng z Quản lý chất lượng là đặc biệt quan trọng đối với các hệ thống phức tạp và lớn. Tài liệu chất lượng là hồ sơ về tiến trình và hỗ trợ tính liên tục phát triển khi nhóm phát triển thay đổi. z Đối với các hệ thống nhỏ hơn, quản lý chất lượng cần ít tài liệu hơn và nên tập trung vào việc củng cố văn hóa chất lượng. 32
Quản lý chất lượng phần mềm z Các hoạt động chính của quản lý chất lượng z Đảm bảo chất lượng z Thiết lập thủ tục tổ chức và các chuẩn về chất lượng z Lập kế hoạch chất lượng z Chọn các thủ tục và các chuẩn phù hợp với một dự án cụ thể và hiệu chỉnh chúng khi cần z Kiểm soát chất lượng z Đảm bảo rằng nhóm phát triển phần mềm tuân theo các thủ tục và chuẩn z Quản lý chất lượng nên tách biệt khỏi quản lý dự án để đảm bảo sự độc lập 33 Quản lý chất lượng phần mềm z Chất lượng sản phẩm và quy trình z Chất lượng sản phẩm được phát triển bịảnh hưởng bởi chất lượng quy trình sản xuất z Một cách tiếp cận dựa trên quy trình để đạt được chất lượng sản phẩm 34
Quản lý chất lượng phần mềm z Chất lượng của sản phẩm và quy trình z Trong phát triển phần mềm, mối quan hệ giữa chất lượng sản phẩm và chất lượng quy trình là phức tạp vì z Việc áp dụng các kinh nghiệm và các kỹ năng cá nhân là đặc biệt quan trọng trong phát triển phần mềm z Các yếu tố bên ngoài như tính mới lạ của ứng dụng hay kế hoạch phát triển gấp có thể làm suy giảm chất lượng sản phẩm z Một số thuộc tính chất lượng phần mềm khó đo lường => khó đánh giá được cách mà các đặc điểm của quy trình tác động đến các thuộc tính đó 35 Quản lý chất lượng phần mềm z Quản lý chất lượng quy trình liên quan tới: z Định nghĩa các chuẩn quy trình như khi nào và bằng cách nào các xem lại (review) được quản lý, quản lý cấu hình, v.v z Giám sát quy trình phát triển để đảm bảo các chuẩn được tuân theo z Báo cáo quy trình phần mềm với quản lý dự án và khách hàng mua phần mềm 36
Đảm bảo chất lượng và các chuẩn z Các chuẩn z Là chìa khóa của sự quản lý chất lượng hiệu quả z Có thể là các chuẩn của tổ chức, của quốc gia hay của quốc tế z Các loại chuẩn: z Chuẩn sản phẩm Các chuẩn áp dụng cho sản phẩm phần mềm đang được phát triển. Chúng gồm các chuẩn như các chuẩn tư liệu, các chuẩn lập trình 37 Đảm bảo chất lượng và các chuẩn z Các chuẩn z Các loại chuẩn z Chuẩn quy trình: Các chuẩn định nghĩa các quy trình mà chúng nên được tuân theo trong suốt sự phát triển phần mềm. Chúng bao gồm các định nghĩa về những quy trình đặc tả, thiết kế, thẩm định và sự mô tả về các tài liệu được viết trong các quy trình đó 38
Đảm bảo chất lượng và các chuẩn z Các chuẩn quy trình và sản phẩm 39 Đảm bảo chất lượng và các chuẩn z Tầm quan trọng của các chuẩn z Là sự tóm lược thực tiễn tốt nhất z Cung cấp một khung để thực hiện quy trình đảm bảo chất lượng z Hỗ trợ tính liên tục nơi công việc được thực hiện bởi một người nay được giao cho người khác 40
Đảm bảo chất lượng và các chuẩn z Các vấn đề về chuẩn z Chúng có thể được xem là không liên quan và không được cập nhật bởi các kỹ sư phần mềm z Chúng thường đòi hỏi quá nhiều thực hiện rườm rà và có thể buồn tẻ 41 Đảm bảo chất lượng và các chuẩn z Để tránh các vấn đề về chuẩn, nhà quản lý chất lượng nên thực hiện: z Mời các kỹ sư phần mềm tham gia vào việc chọn các chuẩn sản phẩm z Xem lại và hiệu chỉnh các chuẩn để phản ánh các công nghệ đang thay đổi z Cung cấp các công cụ phần mềm để hỗ trợ các chuẩn nếu có thể 42
Đảm bảo chất lượng và các chuẩn z ISO 9000 z Một tập chuẩn quốc tế cho quản lý chất lượng z Phù hợp với nhiều tổ chức từ công nghiệp sản xuất tới kinh doanh dịch vụ 43 Đảm bảo chất lượng và các chuẩn z ISO 9000 và quản lý chất lượng 44
Đảm bảo chất lượng và các chuẩn z ISO 9001 z ISO 9001 phù hợp với các tổ chức thiết kế, phát triển và bảo trì sản phẩm z ISO 9001 là một mô hình chung của quy trình chất lượng mà nó phải được cụ thể hóa cho từng công ty bằng cách sử dụng các thủ tục và các chuẩn tổ chức mà công ty nên định nghĩa 45 Đảm bảo chất lượng và các chuẩn z ISO 9001 bao phủ các phạm vi sau 46
Đảm bảo chất lượng và các chuẩn z Các chuẩn tư liệu z Đặc biệt quan trọng vì tài liệu là cách hữu hình duy nhất để biểu diễn phần mềm và quy trình phần mềm z Ba loại chuẩn tư liệu z Chuẩn quy trình tư liệu: liên quan tới cách các tài liệu nên được phát triển, thẩm định và duy trì z Chuẩn tài liệu: chi phối nội dung, cấu trúc và sự trình bày của các tài liệu z Chuẩn trao đổi tài liệu: đảm bảo rằng tất cả các bản sao điện tử của các tài liệu là tương thích 47 Đảm bảo chất lượng và các chuẩn z Một mô hình về quy trình tư liệu 48
Đảm bảo chất lượng và các chuẩn z Chuẩn tài liệu z Các chuẩn nhận dạng tài liệu: cách các tài liệu được nhận biết là duy nhất z Các chuẩn cấu trúc tài liệu: cấu trúc chuẩn cho các tài liệu của dự án z Các chuẩn trình bày tài liệu: định nghĩa các font chữ, kiểu chữ, sử dụng các logo, v.v. z Chuẩn cập nhật tài liệu: định nghĩa cách các thay đổi so các phiên bản trước được phản ánh trong tài liệu 49 Đảm bảo chất lượng và các chuẩn z Chuẩn trao đổi tài liệu z Các chuẩn trao đổi cho phép các tài liệu điện tử được nhận, được gửi, v.v. z Các tài liệu được tạo ra bằng cách sử dụng các hệ thống khác nhau và trên các máy tính khác nhau. Thậm chí khi các công cụ chuẩn được sử dụng, các chuẩn được cần đến để định nghĩa các quy tắc sử dụng chúng 50
Lập kế hoạch chất lượng z Kế hoạch chất lượng trình bày các chất lượng sản phẩm được mong đợi và mô tả cách mà chúng được đánh giá cũng như định nghĩa các thuộc tính chất lượng quan trọng nhất z Kế hoạch chất lượng nên định nghĩa quy trình đánh giá chất lượng z Nó trình bày những chuẩn tổ chức nào nên được áp dụng và, khi cần thiết, định nghĩa các chuẩn mới 51 Lập kế hoạch chất lượng z Cấu trúc của kế hoạch chất lượng z Giới thiệu sản phẩm z Các kế hoạch cho sản phẩm z Các mô tả quy trình z Mục tiêu chất lượng z Rủi ro và quản lý rủi ro z Kế hoạch chất lượng nên là tài liệu ngắn gọn và súc tích 52
Lập kế hoạch chất lượng z Các thuộc tính chất lượng phần mềm 53 Kiểm soát chất lượng z Kiểm soát chất lượng đòi hỏi việc giám sát quy trình phát triển phần mềm để đảm bảo các thủ tục và các chuẩn đang được tuân theo z Hai cách tiếp cận kiểm soát quy trình z Các xem lại chất lượng z Sự đo lường phần mềm và sự đánh giá phần mềm tự động 54
Kiểm soát chất lượng z Xem lại chất lượng z Đây là một phương pháp cơ bản công nhận chất lượng của quy trình hay sản phẩm z Một nhóm kiểm tra một phần hay toàn bộ quy trình hay hệ thống và các tư liệu của nó để tìm ra các vấn đề tiềm ẩn z Mục đích của xem lại chất lượng là phát hiện ra các nhược điểm của hệ thống và các mâu thuẫn z Bất cứ tài liệu nào được tạo ra trong quy trình đều có thể được xem lại z Các nhóm xem lại nên tương đối nhỏ và các buổi xem lại nên khá ngắn 55 Kiểm soát chất lượng z Các kiểu xem lại 56
Nội dung – Quản lý cấu hình z Quản lý cấu hình (Configuration Management -CM) z Lập kế hoạch quản lý cấu hình z Quản lý sự thay đổi z Quản lý phiên bản và phát hành z Xây dựng hệ thống 57 Quản lý cấu hình z CM là sự phát triển và ứng dụng của các thủ tục và chuẩn để quản lý một sản phẩm phần mềm đang tiến hóa z CM có thể được xem là một phần của quy trình quản lý chất lượng tổng quan hơn z Khi được phát hành tới CM, các hệ thống phần mềm đôi khi được gọi là các baseline vì chúng là điểm bắt đầu cho sự phát triển xa hơn 58
Quản lý cấu hình z Thủ tục CM định nghĩa: z Cách lưu giữ và xử lý các thay đổi hệ thống được đề nghị z Cách liên kết các thay đổi này với các bộ phận phần mềm và các phương thức được sử dụng để nhận dạng các phiên bản khác nhau của hệ thống 59 Quản lý cấu hình z Các chuẩn của CM z Định nghĩa và sử dụng các chuẩn CM là rất cần thiết để xác nhận chất lượng z Các chuẩn có thể được dựa trên các chuẩn CM bên ngoài tổng quát và được điều chỉnh cho phù hợp với với môi trường cụ thể của tổ chức z Các chuẩn nên định nghĩa các thành phần (item) được nhận dạng, cách các thay đổi được kiểm soát và cách các phiên bản mới được quản lý 60
Quản lý cấu hình z Các phiên bản mới của các hệ thống phần mềm được tạo ra khi chúng: z Dùng cho các máy/ hệ điều hành khác nhau z Cung cấp các chức năng khác z Đáp ứng các yêu cầu đặc biệt của người dùng 61 Lập kế hoạch quản lý cấu hình z Kế hoạch quản lý cấu hình z Định nghĩa những cái được quản lý (thành phần cấu hình) và một sơ đồ được dùng để nhận dạng những thành phần đó z Định nghĩa người có trách nhiệm đối với các thủ tục CM và gửi các thành phần cấu hình tới nhóm quản lý cấu hình z Định nghĩa các chính sách để quản lý phiên bản và kiểm soát sự thay đổi z Xác định các công cụ mà ta nên sử dụng để quản lý cấu hình và quy trình sử dụng chúng z Định nghĩa cơ sở dữ liệu CM để lưu thông tin cấu hình và những thông tin khác nên được lưu trong CSDL đó 62
Lập kế hoạch quản lý cấu hình z Nhận dạng các thành phần cấu hình z Các dự án lớn thường tạo ra hàng ngàn tài liệu mà chúng phải được nhận dạng là duy nhất z Một số tài liệu này phải được bảo quản trong suốt thời gian sống của phần mềm z Sơ đồ phân cấp với với các tên đa mức có thể là một phương pháp uyển chuyển nhất 63 Lập kế hoạch quản lý cấu hình z Nhận dạng các thành phần cấu hình z Các thành phần cấu hình: z Các đặc tả z Các thiết kế z Các chương trình z Dữ liệu kiểm thử z Tài liệu hướng dẫn người sử dụng 64
Lập kế hoạch quản lý cấu hình z Phân cấp cấu hình 65 Lập kế hoạch quản lý cấu hình z Cơ sở dữ liệu của quản lý cấu hình z Tất cả các thông tin CM nên được lưu trong cơ sở dữ liệu cấu hình z Nó còn cho phép các truy vấn về quản lý cấu hình như: z Ai có một phiên bản hệ thống cụ thể? z Phần cứng và hệ điều hành nào được yêu cầu cho một phiên bản cụ thể? z Những phiên bản nào bịảnh hưởng bởi sự thay đổi của thành phần X? z Có bao nhiêu lỗi được báo cáo trong phiên bản T? 66
Lập kế hoạch quản lý cấu hình z Cơ sở dữ liệu của quản lý cấu hình z Có thể là một phần của môi trường được tích hợp nhằm hỗ trợ phát triển phần mềm z Cơ sở dữ liệu CM và các tài liệu được quản lý tất cả được lưu giữ trong cùng hệ thống z Các công cụ CASE có thể được tích hợp để liên kết một cách trực tiếp các thay đổi với các tài liệu và các bộ phận bịảnh hưởng bởi sự thay đổi z Một cách phổ biến hơn, cơ sở dữ liệu CM được lưu tách biệt vì nó rẻ hơn và linh động hơn 67 Quản lý sự thay đổi z Quản lý sự thay đổi z Các yêu cầu thay đổi đối với hệ thống phần mềm có thể bắt nguồn từ z Người dùng z Nhà phát triển z Áp lực thị trường z Quản lý sự thay đổi liên quan tới việc theo dõi các thay đổi này và đảm bảo rằng chúng được thực hiện theo cách hiệu quả nhất về chi phí 68
Quản lý sự thay đổi z Qui trình quản lý sự thay đổi 69 Quản lý sự thay đổi z Biểu mẫu yêu cầu thay đổi (change request form) z Sự định nghĩa của một biểu mẫu yêu cầu thay đổi là một phần của quy trình lập kế hoạch CM z Biểu mẫu này lưu sự thay đổi được đề nghị, người yêu cầu thay đổi, lý do tại sao sự thay đổi này được đề nghị và tính cấp bách của sự thay đổi z Nó còn lưu ước lượng về sự thay đổi, phân tích ảnh hưởng, chi phí thay đổi và các đề nghị z 70
Quản lý sự thay đổi 71 Quản lý sự thay đổi z Ban kiểm soát sự thay đổi z Các thay đổi nên được xem lại bởi một nhóm những người quyết định xem chúng có mang lại lợi nhuận hay không theo quan điểm chiến lược và tổ chức hơn là theo quan điểm kỹ thuật z Ban kiểm soát sự thay đổi nên là một nhóm độc lập của dự án 72
Quản lý phát hành và phiên bản z Phát triển một sơ đồ nhận dạng các phiên bản của hệ thống z Lập kế hoạch khi một phiên bản của hệ thống mới được tạo ra z Đảm bảo rằng các công cụ và thủ tục quản lý phiên bản được áp dụng một cách đúng đắn z Lập kế hoạch phân phối các phát hành của hệ thống mới 73 Quản lý phát hành và phiên bản z Phiên bản / Biến thể / Phát hành z Phiên bản (version): Một thể hiện của hệ thống mà nó khác biệt chức năng với các thể hiện khác của hệ thống theo cách nào đó z Biến thể (variant): Một thể hiện của hệ thống mà nó giống về chức năng nhưng khác về phi chức năng với các thể hiện khác của hệ thống z Phát hành (release): Một thể hiện của hệ thống mà nó được phân phối cho người dùng bên ngoài nhóm phát triển 74
Quản lý phát hành và phiên bản z Nhận dạng phiên bản z Các thủ tục nhận dạng phiên bản nên định nghĩa một cách rõ ràng việc nhận dạng các phiên bản của thành phần z Ba kỹ thuật cơ bản để nhận dạng phiên bản của thành phần z Đánh số phiên bản z Nhận dạng dựa vào thuộc tính z Nhận dạng hướng thay đổi 75 Quản lý phát hành và phiên bản z Nhận dạng phiên bản - Đánh số phiên bản z Sơ đồ đánh số đơn giản nhất sử dụng sự tiến hóa tuyến tính z V1, V1.1, V1.2, V2.1, v.v z Cấu trúc tiến hóa thực tế là một cây hay một mạng hơn là một sự liên tục z Các tên không có ý nghĩa 76
Quản lý phát hành và phiên bản z Nhận dạng phiên bản - Đánh số phiên bản 77 Quản lý phát hành và phiên bản z Nhận dạng phiên bản - Nhận dạng dựa vào thuộc tính z Các thuộc tính có thể được sử dụng để nhận dạng phiên bản z Các thuộc tính có thể là ngày, người tạo ra, ngôn ngữ lập trình, khách hàng, trạng thái, v.v z Cách làm này có thể gây ra các vấn đề: tập các thuộc tính phải được chọn để tất cả các phiên bản có thể được định danh duy nhất z Trong thực tiễn, một phiên bản còn cần một tên kết hợp để tham khảo dễ dàng 78
Quản lý phát hành và phiên bản z Nhận dạng phiên bản - Nhận dạng dựa vào thuộc tính z Một thuận lợi quan trọng của nhận dạng dựa vào thuộc tính là nó có thể hỗ trợ các truy vấn z Truy vấn chọn ra một phiên bản phụ thuộc vào các giá trị thuộc tính 79 Quản lý phát hành và phiên bản z Nhận dạng phiên bản - Nhận dạng hướng thay đổi z Tích hợp các phiên bản và các thay đổi được thực hiện để tạo ra các phiên bản đó z Được sử dụng để nhận dạng phiên bản của hệ thống hơn là phiên bản của thành phần z Mỗi một thay đổi được đề nghị có một tập thay đổi kết hợp được tạo ra để thực hiện thay đổi đó 80
Quản lý phát hành và phiên bản z Quản lý phát hành z Phát hành hệ thống: một phiên bản của hệ thống mà nó được phân phối tới khách hàng z Nhà cung cấp sản phẩm phần mềm thường chỉ đưa ra các phát hành mới cho các nền mới hay thêm các chức năng mới rất cần thiết z Các hệ thống hiện nay thường được phát hành trên đĩa quang hoặc các tập tin cài đặt có thể tải xuống từ trang web 81 Quản lý phát hành và phiên bản z Quản lý phát hành Phát hành hệ thống z Không chỉ là một tập các chương trình có thể thực thi được z Mà có thể bao gồm z Các tập tin cấu hình định nghĩa cách thức phát hành được cấu hình cho một sự cài đặt cụ thể z Các tập tin dữ liệu cần cho sự vận hành hệ thống z Một chương trình cài đặt hay một script tiện ích để cài đặt hệ thống lên phần cứng đích z Các tài liệu ở dạng giấy hay dạng điện tử z Đóng gói và quảng cáo liên quan 82
Quản lý phát hành và phiên bản z Quản lý phát hành Các vấn đề phát hành z Khách hàng có thể không muốn bản phát hành mới của hệ thống z Quản lý phát hành không nên giả sử rằng tất cả các phát hành trước đó được chấp nhận. Tất cả những tập tin cần cho một phát hành nên được tạo lại khi một phát hành mới được cài đặt 83 Quản lý phát hành và phiên bản z Ra quyết định phát hành z Việc chuẩn bị và phân phối một bản phát hành hệ thống là một quy trình tốn kém z Các yếu tố như chất lượng kỹ thuật, sự cạnh tranh, v.v tác động đến việc quyết định khi nào đưa ra một phát hành của hệ thống mới 84
85 Quản lý phát hành và phiên bản z Tư liệu phát hành z Ghi lại các phiên bản cụ thể của các thành phần mã nguồn được sử dụng để tạo ra mã thực thi z Lưu bản sao của mã nguồn, mã thực thi, tất cả dữ liệu và các tập tin cấu hình z Ghi lại phiên bản của hệ điều hành, thư viện, bộ biên dịch và những công cụ được sử dụng để xây dựng phần mềm 86
Xây dựng hệ thống z Xây dựng hệ thống là quy trình biên dịch và liên kết các thành phần của phần mềm vào một chương trình mà nó thực hiện trên một cấu hình đích cụ thể z Các hệ thống khác nhau được xây dựng từ các kết hợp khác nhau về các thành phần của phần mềm z Qui trình này hiện nay luôn được hỗ trợ bởi các công cụ tự động 87 Xây dựng hệ thống 88
Nội dung – Quản lý dự án z Các đặc trưng của dự án z Quản lý rủi ro z Các kỹ thuật kiểm soát và lập kế hoạch dự án 89 Các đặc trưng của dự án z Các lớp đặc trưng của dự án: z Đặc trưng của sản phẩm z Đặc trưng của qui trình z Đặc trưng của nguồn lực z Các đặc trưng có mức độ chắn chắn xác định 90
Các đặc trưng của dự án z Độ chặc chắn của sản phẩm: z Các yêu cầu rõ ràng, được biết trước: độ chắc chắn của sản phẩm cao z Các yêu cầu của người dùng thay đổi thường xuyên: độ chắc chắn của sản phẩm thấp z Độ chặc chắn của quy trình: z Biết nhiều về sựảnh hưởng của các hoạt động điều khiển: cao z Sử dụng các công cụ không biết: thấp z Độ chặc chắn của nguồn lực: z Phụ thuộc vào sự sẵn có của nhân viên có phẩm chất phù hợp, tiềm lực tài chính 91 Các đặc trưng của dự án z Các trạng thái kiểm soát điển hình z Realization: tất cả các độ chắc chắn đều cao z Allocation: độ chắn chắn của tài nguyên thấp còn lại đều cao z Design: độ chắc chắn của sản phẩm cao còn lại đều thấp z Exploration: tất cả các độ chắc chắn đều thấp 92
Các đặc trưng của dự án z Trạng thái kiểm soát Realization z Mục đích cơ bản trong kiểm soát: z Tối ưu hóa việc sử dụng tài nguyên, hiệu suất và kế hoạch z Kiểu quản lý / phối hợp: z Kiểu tách biệt, phân cấp, chuẩn hóa 93 Các đặc trưng của dự án z Trạng thái kiểm soát Allocation z Mục đích cơ bản trong kiểm soát: z Thu nhận và đào tạo nhân sự z Kiểu quản lý / phối hợp: z Sự chuẩn hóa sản phẩm và quy trình 94
Các đặc trưng của dự án z Trạng thái kiểm soát Design z Mục đích cơ bản trong kiểm soát: z Kiểm soát quy trình z Kiểu quản lý / phối hợp: z Sự chuẩn hóa quy trình 95 Các đặc trưng của dự án z Trạng thái kiểm soát Exploration z Mục đích cơ bản trong kiểm soát: z Cực đại kết quả và giảm thiểu rủi ro z Kiểu quản lý / phối hợp: z Kiểu quan hệ, giao phó và điều chỉnh lẫn nhau 96
Quản lý rủi ro z Các yếu tố rủi ro hàng đầu z Nhân sự thiếu z Lịch biểu / ngân sách phi hiện thực z Chức năng phần mềm sai z Giao diện người dùng sai z Phát triển những chức năng không được khách hàng yêu cầu z Các yêu cầu không ổn định z Các thành phần được cung cấp từ bên ngoài không đạt yêu cầu z Công việc đối ngoại dở z Yêu cầu thời gian thực không được đáp ứng z Môi trường không ổn định hay công nghệ mới, chưa được thử nghiệm 97 Quản lý rủi ro z Chiến lược quản lý rủi ro z Nhận dạng các yếu tố rủi ro z Xác định mức độ rủi ro z Phát triển các chiến lược giảm nhẹ các rủi ro z Quản lý các rủi ro 98
Quản lý rủi ro z Các loại rủi ro Mức quản lý low high customers and users scope and requirements ng low ọ (C1) (C2) quan tr environment execution high ự (C4) (C3) S Thứ tự quản lý: Đầu tiên C3, sau đó C2, sau đóC4vàC199 Các kỹ thuật kiểm soát và lập kế hoạch dự án z Cấu trúc phân chia công việc (Work breakdown structure - WBS) z Sơ đồ Pert z Sơ đồ Gantt z 100
Các kỹ thuật kiểm soát và lập kế hoạch z Cấu trúc phân chia công việc (Work breakdown structure - WBS) 101 Lập kế hoạch quản lý z Nguyên tắc chung z Chia nhỏ dự án thành các công việc kiểm soát được z Mỗi công việc có một mốc thời gian và nguồn lực có thể kiểm soát được tiến độ. z Các công việc thường được thực hiện theo một trật tự nào đó z Ta có thể lập bảng công việc & các biểu đồ như PERT, GANTT 102
Sơ đồ PERT theo công việc z Pert sử dụng hai yếu tố cơ bản là công việc và thời gian thực hiện công việc. z Công việc được biểu thị bằng một đỉnh z Thời gian thực hiện công việc được biểu thị bằng một cung. z Để vẽ sơ đồ PERT theo công việc ta phải sử dụng 2 nút giả là bắt đầu (Start) và kết thúc (End). 103 Sơ đồ PERT theo công việc Công việc Công việc Thời gian Chi phí z Ví dụ: Giả sử trước đó (tháng) (triệu đồng) sau khi phân chia và ước A - 4 5 lượng công việc B A 6 11 ta có bảng sau C - 4 3 D - 12 150 E B, C 10 10 F B, C 24 147 G A 7 18 H D, E, G 10 4 I F, H 3 2 104
Sơ đồ PERT theo công việc 4 F C 4 6 24 0 E 4 B 6 0 3 Start A I End 4 10 G 0 7 10 H D 12 105 Sơ đồ PERT theo công việc z Đường găng z Đường dài nhất (theo thời gian) trong sơ đồ Pert đi từ Start tới End. z Thời gian thực hiện dự án được tính bằng cách cộng dồn thời gian theo đường này 4 C F 4 6 24 0 E B 6 0 4 3 Start A I End 4 10 G 0 7 10 H 106 D 12
Sơ đồ PERT theo công việc z Công việc găng z Công việc nằm trên đường găng z Công việc mà thực hiện chúng chậm đi bao nhiêu thì toàn bộ dự án sẽ bị đẩy lùi đi thời gian đúng bằng bấy nhiêu 107 Sơ đồ PERT theo công việc z Thời gian sớm nhất để bắt đầu thực hiện công việc i được ký hiệu là ti z ti = maxj∈P(i) {tj + tji} trong đó z P(i) là tập hợp tất cả các đỉnh j đứng trước i z tji là giá trị hay độ dài của cung (j, i) 108
Sơ đồ PERT theo công việc 4 F C 10 0 4 6 E 24 0 B 6 10 4 4 Start 0 A I 3 End 0 0 4 34 37 G 10 0 4 7 10 H D 20 12 0 109 Sơ đồ PERT theo công việc z Thời gian trễ nhất để bắt đầu thực hiện công việc i được ký hiệu là Ti z Ti = minj∈S(i) {Tj -tij} trong đó z S(i) là tập hợp tất cả các đỉnh j đứng sau i z tij là giá trị hay độ dài của cung (i,j) 110
Sơ đồ PERT theo công việc 4 F C 10 10 0 6 4 6 E 24 0 B 6 10 14 4 4 4 Start 0 A I 3 End 0 0 0 0 4 34 34 37 37 G 10 0 4 17 7 10 H D 20 24 12 0 12 Thời gian để thực hiện toàn bộ dự án 111 là 37 tháng và kinh phí là 350 triệu Sơ đồ PERT theo công việc Công Công việc Thời gian Chi phí Thời gian thực Chi phí bỏ việc trước đó (tháng) (triệu đồng) hiện khẩn thêm khi rút trương có thể ngắn 1 tháng A - 4 5 2 5 B A 6 11 5 19 C - 4 3 2 4 D - 12 150 9 10 E B, C 10 10 8 5 F B, C 24 147 19 13 G A 7 18 6 12 H D, E, G 10 4 7 7 I F, H 3 2 2 3 Hãy rút ngắn thời gian thực hiện dự án xuống còn 28 tháng? 112
Sơ đồ PERT theo công việc z Rút ngắn thời gian thực hiện dự án z Lặp lại việc chọn công việc găng với chi phí cần bổ sung để đẩy nhanh thêm một đơn vị thời gian là rẻ nhất và giảm thời gian thực hiện công việc này tới tối đa cho đến khi: z Đạt được thời gian tối thiểu cần thiết để thực hiện công việc hay z Xuất hiện công việc găng mới z Nếu công việc găng cần rút ngắn nằm trên chu trình gồm nhiều công việc găng khác thì rút ngắn tối đa hai công việc găng nằm trên hai nhánh khác nhau của chu trình sao cho tổng chi phí bỏ thêm của chúng là ít nhất (so với các công việc găng còn lại và các cặp công việc găng trên các nhánh của chu trình) 113 Sơ đồ PERT theo công việc C 4 F 4 6 0 E 24 4 B 6 Start 0 A I 3 End 4 G 10 0 7 10 H D 12 37 tháng z Chọn các công việc găng A, B, F, I để rút ngắn z Chọn I đầu tiên vì chi phí bỏ thêm cho I là thấp nhất và rút ngắn I một tháng. C 4 F 4 6 0 E 24 B 6 Start 0 A 4 I 2 End 4 G 10 0 7 10 H 114 D 12 Còn 36 tháng
Sơ đồ PERT theo công việc C 4 F 4 6 0 E 24 B 6 Start 0 A 4 I 2 End 4 G 10 0 7 10 H Còn 36 tháng D 12 z Chọn các công việc găng A, B, F để rút ngắn z Chọn A tiếp theo vì chi phí bỏ thêm cho A là thấp thứ hai và rút ngắn A hai tháng. C 4 F 4 6 0 E 24 B 6 Start 0 A 2 I 2 End 2 G 10 0 7 10 H 115 D 12 Còn 34 tháng Sơ đồ PERT theo công việc C 4 F 4 6 0 E 24 B 6 Start 0 A 2 I 2 End 2 G 10 0 7 10 H Còn 34 tháng D 12 z Chọn các công việc găng B, F để rút ngắn z Chọn F tiếp theo vì chi phí bỏ thêm cho F là thấp thứ ba và rút ngắn F bốn tháng. C 4 F 4 6 0 E 20 B 6 Start 0 A 2 I 2 End 2 G 10 0 7 10 H 116 D 12 Còn 30 tháng
Sơ đồ PERT theo công việc z Khi rút ngắn F bốn tháng, ta có chu trình các công việc găng C 4 F 4 6 0 E 20 B 6 Start 0 A 2 I 2 End 2 G 10 0 7 10 H D 12 Còn 30 tháng 117 Sơ đồ PERT theo công việc C 4 F 4 6 0 E 20 B 6 Start 0 A 2 I 2 End 2 G 10 0 7 10 H Còn 30 tháng D 12 z Trong số các công việc găng còn lại và các cặp công việc găng trên các nhánh thì cặp F+E có chi phí thấp nhất nên ta rút F+E 1 tháng. C 4 F 4 6 0 E 19 B 6 Start 0 A 2 I 2 End 2 G 9 0 7 10 H D 118 12 Còn 29 tháng
Sơ đồ PERT theo công việc C 4 F 4 6 0 E 19 B 6 Start 0 A 2 I 2 End 2 G 9 0 7 10 Còn 29 tháng H D 12 z Cuối cùng, ta rút ngắn B một tháng. C 4 F 4 5 0 E 19 B 5 Start 0 A 2 I 2 End 2 G 9 0 7 10 H D 119 12 Còn 28 tháng Sơ đồ PERT theo công việc z Sơ đồ Pert cho kế hoạch khẩn trương 4 F C 7 7 0 3 4 5 E 19 0 B 5 7 7 2 2 2 Start 0 A I 2 End 0 0 0 0 2 26 26 28 28 G 9 0 2 9 7 10 H D 16 16 12 0 4 Thời gian để thực hiện toàn bộ dự án 120 là 28 tháng và kinh phí là 452 triệu
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 4 – ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM 1 Nộidung z Giíi thiÖu z ¦íc l−îng kÝch th−íc phÇn mÒm z ¦íc l−îng chi phÝ phÇn mÒm 2
Giíi thiÖu z C¸c yÕu tè cÇn −íc l−îng z KÝch th−íc phÇn mÒm z C«ng søc ph¸t triÓn z Thêi gian thùc hiÖn z Nguyªn t¾c −íc l−îng z Ph©n r· dù ¸n theo c¸c chøc n¨ng chÝnh vμ−íc l−îng tõng chøc n¨ng z Dùa trªn kinh nghiÖm, d÷ kiÖn qu¸ khø 3 ¦íc lượng kích thước phần mềm z ¦íc l−îng kÝch th−íc phÇn mÒm z Qua dßng lÖnh: ¦íc l−îng trùc tiÕp víi tõng module z Qua ®iÓm chøc n¨ng: ¦íc l−îng gi¸n tiÕp th«ng qua −íc l−îng input/output, yªu cÇu, 4
¦íc lượng kích thước phần mềm z Qua dßng lÖnh z Theo ®¬n vÞ mét dßng lÖnh LOC (Lines Of Code) z Theo ®¬n vÞ mét ngμn dßng lÖnh KDSI / KLOC (Thousand Delivered Source of Code / Kilo Lines of Code) z Phô thuéc ng«n ng÷ lËp tr×nh 5 ¦íc lượng kích thước phần mềm z C¸c vÊn ®Ò gÆp ph¶i víi c¸c ph−¬ng ph¸p LOC vμ KDSI z TÝnh to¸n kÝch th−íc t¹i c¸c giai ®o¹n kh¸c nhau: ph©n tÝch yªu cÇu, z Cμi ®Æt trªn c¸c ng«n ng÷ lËp tr×nh kh¸c nhau: C, Java, Lisp, z C¸ch tÝnh sè dßng m· lÖnh: m· lÖnh thùc thi, ®Þnh nghÜa d÷ liÖu, z Sinh m· tù ®éng, thiÕt kÕ giao diÖn trùc tiÕp (GUI) z Gi¸ thμnh cña s¶n phÈm phô thuéc vμo −íc l−îng LOC 6
¦íc lượng kích thước phần mềm z Qua ®iÓm chøc n¨ng (FP - Functional Points) z §éc lËp víi ng«n ng÷ lËp tr×nh z C¸c ®iÓm chøc n¨ng: z Input Item (Inp): Sè input cña ng−êi dïng mμ chóng thùc hiÖn c¸c thay ®æi trong cÊu tróc d÷ liÖu (xö lý), kh«ng ®iÒu khiÓn sù thùc hiÖn ch−¬ng tr×nh z Output Item (Oup): Sè output ®−îc kÕt xuÊt cho ng−êi dïng z Inquiry (Inq): Sè input (truy vÊn) ®iÒu khiÓn sù thùc hiÖn ch−¬ng tr×nh, kh«ng thay ®æi trong cÊu tróc d÷ liÖu z Master File (Maf) : Sè tËp tin ®−îc sinh ra vμ ®−îc sö dông, ®−îc duy tr× bëi hÖ thèng z Interface (Inf): Sè output ®i vμo øng dông kh¸c hay ®−îc chia sÎ víi øng dông nμo ®ã 7 ¦íc lượng kích thước phần mềm z B¶ng gi¸ trÞ c¸c ®iÓm chøc n¨ng theo ®é phøc t¹p tõ thÊp, trung b×nh ®Õn cao z C«ng thøc tÝnh sè ®iÓm chøc n¨ng th« UFP = a1 x Inp + a2 xOup + a3 x Inq + a4 x Maf + a5 xInf víi a , a , a , a , a lμ gi¸ trÞ c¸c ®iÓm chøc n¨ng theo ®é 1 2 3 4 5 8 phøc t¹p cho trong b¶ng trªn.
¦íc lượng kích thước phần mềm 9 ¦íc lượng kích thước phần mềm z C«ng thøc tÝnh ®iÓm chøc n¨ng FP FP = §iÓm chøc n¨ng th« x (0.65 + 0.01 x Tæng c¸c møc ®é ¶nh h−ëng cña c¸c hÖ sè kü thuËt ) z 14 hÖ sè kü thuËt (cã møc ®é ¶nh h−ëng n»m trong ph¹m vi tõ 0 (kh«ng quan träng hay kh«ng thÝch hîp hay kh«ng ¶nh h−ëng) tíi 5 (cùc kú quan träng hay cÇn thiÕt tuyÖt ®èi hay ¶nh h−ëng nhÊt) 10
¦íc lượng kích thước phần mềm z C¸c hÖ sè kü thuËt 1. Data communication 8. Online update 2. Distributed function 9. Complex processing 3. Performance 10. Reusability 4. Heavily used configuration 11. Installation ease 5. Transaction rate 12. Operation ease 6. Online data entry 13. Multiple site 7. End-user efficiency 14. Facilitate change 11 ¦íc lượng kích thước phần mềm z §iÓm chøc n¨ng FP cã thÓ ®−îc dïng ®Ó dù ®o¸n sè dßng lÖnh LOC LOC = AVC * sè ®iÓm chøc n¨ng FP víi AVC : yÕu tè phô thuéc vμo ng«n ng÷ lËp tr×nh ®−îc sö dông 12
¦íc lượng kích thước phần mềm 13 ¦íc lượng kích thước phần mềm z Bμi tËp: Mét s¶n phÈm phÇn mÒm ®−îc −íc l−îng cã 4 ®Çu vμo ®¬n gi¶n, 9 ®Çu vμo phøc t¹p, 17 ®Çu ra trung b×nh, 20 truy vÊn phøc t¹p, 13 tËp tin chÝnh ®¬n gi¶n, 15 giao diÖn trung b×nh vμ 7 giao diÖn phøc t¹p. 1. H·y tÝnh sè l−îng ®iÓm chøc n¨ng th«? 2. NÕu hÇu hÕt c¸c nh©n tè kü thuËt ®Òu kh«ng quan träng trõ hai nh©n tè dÔ cμi ®Æt vμ dÔ sö dông lμ rÊt quan träng th× sè l−îng ®iÓm chøc n¨ng lμ bao nhiªu? 3. H·y qui ®æi ra sè l−îng dßng m· lÖnh theo ng«n ng÷ lËp tr×nh C? 14
¦íc lượng chi phí phần mềm z ¦íc l−îng chi phÝ z Dùa trªn kÝch th−íc, ®é phøc t¹p z Dùa vμo d÷ liÖu qu¸ khø z Chi phí tỉ lệ với công sức (effort) phát triển phần mềm z Chi phí tính dựa theo công sức cho các giai đoạn phát triểm phần mềm: khởi đầu, phân tích, thiết kế, cài đặt, kiểm thử nhưng chưa tính đến giai đoạn bảo trì. z Đơn vị tính của công sức: người-tháng (hoặc người- ngày) 15 ¦íc lượng chi phí phần mềm z C¸c ph−¬ng ph¸p −íc l−îng chi phÝ phÇn mÒm z Theo ý kiÕn cña chuyªn gia z Theo gi¶i thuËt z B»ng sù t−¬ng tù Tù ®äc z B»ng luËt Parkinson z §Êu gi¸ (Pricing to win) 16
¦íc lượng chi phí phần mềm z Ý kiÕn cña chuyªn gia (Expert judgment) z Mét hay nhiÒu chuyªn gia trong c¶ lÜnh vùc øng dông vμ ph¸t triÓn phÇn mÒm sö dông kinh nghiÖm cña hä ®Ó dù tÝnh chi phÝ phÇn mÒm. Qui tr×nh nμy ®−îc lÆp ®i lÆp l¹i cho ®Õn khi ®¹t ®−îc sù nhÊt trÝ. z ThuËn lîi: Ph−¬ng ph¸p dù ®o¸n chi phÝ thÊp mét c¸ch t−¬ng ®èi. Cã thÓ chÝnh x¸c nÕu c¸c chuyªn gia cã kinh nghiÖm trùc tiÕp trong c¸c hÖ thèng t−¬ng tù. z Khã kh¨n: RÊt thiÕu chÝnh x¸c nÕu kh«ng cã c¸c chuyªn gia thùc sù! 17 ¦íc lượng chi phí phần mềm z ¦íc l−îng chi phÝ theo gi¶i thuËt z Mét sè m« h×nh −íc l−îng chi phÝ theo gi¶i thuËt z M« h×nh Walston vμ Felix z M« h×nh Bailey vμ Basili z M« h×nh COCOMO 18
Mô hình Walston và Felix z Mét trong c¸c m« h×nh gi¶i thuËt sím nhÊt (1977) z M« h×nh ®−îc ®Ò nghÞ sau khi nghiªn cøu 60 dù ¸n cña IBM z Cã 29 yÕu tè ¶nh h−ëng tíi hiÖu suÊt z C«ng thøc −íc l−îng c«ng søc E E = 5.2 x S 0.91 (ng−êi - th¸ng) Víi S lμ kÝch th−íc ®−îc −íc l−îng cña hÖ thèng (theo KDSI) z C«ng thøc −íc l−îng thêi gian thùc hiÖn T T= 2.5 x E0.35 (th¸ng) 19 Mô hình Walston và Felix z Mçi yÕu tè sÏ nhËn 1 trong 3 gi¸ trÞ tïy thuéc vμo sù t¸c ®éng cña nã tíi hiÖu suÊt z 1 (cao): lμm t¨ng hiÖu suÊt z 0 (trung b×nh): kh«ng ¶nh h−ëng tíi hiÖu suÊt z -1 (thÊp): lμm gi¶m hiÖu suÊt 20
Mô hình 1. Customer interface complexity 16. Use of design and code inspections Walston 2. User participation in requirements 17. Use of top-down development definition 3. Customer-originated program 18. Use of a chief programmer team và Felix design changes 4. Customer experience with the 19. Overall complexity of code application area 5. Overall personnel experience 20. Complexity of application processing 6. Percentage of development 21. Complexity of program flow programmers who participated in the design of functional specifications 7. Previous experience with the 22. Overall constraints on program’s operational computer design 8. Previous experience with the 23. Design constraints on the programming language program’s main storage 9. Previous experience with 24. Design constraints on the applications of similar size and program’s timing complexity 10. Ratio of average staff size to 25. Code for real-time or interactive project duration (people per month) operation or for execution under severe time constraints 11. Hardware under concurrent 26. Percentage of code for delivery development 12. Access to development computer 27. Code classified as open under special request nonmathematical application and input/output formatting programs 13. Access to development computer 28. Number of classes of items in the closed database per 1000 lines of code 14. Classified security environment 29. Number of pages of delivered for computer and at least 25% of documentation per 1000 lines of code programs and data 15. Use of structured programming 21 Mô hình Bailey và Basili z M« h×nh ®−îc ®Ò nghÞ n¨m 1981 bëi Bailey vμ Basili z M« h×nh nμy sö dông c¬ së d÷ liÖu cña 18 dù ¸n viÕt b»ng ng«n ng÷ Fortran t¹i trung t©m Goddard Space Flight cña NASA z C¸c nhãm yÕu tè ¶nh h−ëng tíi c«ng søc: ph−¬ng ph¸p, ®é phøc t¹p vμ kinh nghiÖm z C«ng thøc −íc l−îng c«ng søc ban ®Çu E E = 5.5 + 0.73 x S 1.16 (ng−êi - th¸ng) Víi S lμ kÝch th−íc ®−îc −íc l−îng cña hÖ thèng (theo KDSI) 22
Mô hình Bailey và Basili z Mçi yÕu tè ¶nh h−ëng tíi c«ng søc nhËn mét trong c¸c gi¸ trÞ tõ 0 ®Õn 5 Total methodology Cumulative complexity Cumulative experience (METH) (CPLX) (EXP) Tree charts Customer interface Programmer complexity qualifications Top-down design Application complexity Programmer machine experience Formal documentation Program flow complexity Programmer language experience Chief programmer Internal communication Programmer application teams complexity experience Formal training Database complexity Team experience Formal test plans External communication complexity Design formalisms Customer-initiated program design changes Code reading Unit development 23 folders Mô hình COCOMO 81 z M« h×nh COCOMO 81 ®−îc ®Ò nghÞ bëi Boehm z Dạng cơ bản: áp dụng cho nhóm nhỏ, môi trường quen thuộc z Dạng trung bình: áp dụng cho dự án khá lớn, có một ít kinh nghiệm z Dạng lớn: áp dụng cho dự án lớn, môi trường mới z Bảng mức độ khó khi phát triển sản phẩm (sử dụng mô hình COCOMO 81 trung gian) 24
Mô hình COCOMO 81 trung gian z C«ng søc E = ab x S^bb x EAF z ab vμ bb:®−îc x¸c ®Þnh dùa vμo b¶ng møc ®é khã khi ph¸t triÓn phÇn mÒm z EAF (effort adjustment factor): hÖ sè hiÖu chØnh c«ng søc. Nã ®−îc tÝnh b»ng tÝch cña c¸c hÖ sè ph¸t triÓn z S lμ kÝch th−íc ®−îc −íc l−îng cña hÖ thèng (theo KDSI) z Thêi gian T = cb x E^db 25 Mô hình COCOMO 81 trung gian z C¸c hÖ sè ph¸t triÓn 26
Mô hình COCOMO 81 trung gian z Bμi tËp: B¹n ®−îc giao tr¸ch nhiÖm ph¸t triÓn mét phÇn mÒm d¹ng lín cã 128000LOC. C¸c th«ng sè nh×n chung ®Òu ¶nh h−ëng ë møc b×nh th−êng nh−ng yªu cÇu vÒ ®é tin cËy cña phÇn mÒm lμ rÊt cao, s¶n phÈm cã tÝnh chÊt phøc t¹p vμ rμng buéc vÒ vÊn ®Ò l−u tr÷ chÝnh lμ v« cïng cao còng nh− yªu cÇu rÊt chÆt vÒ lÞch biÓu ph¸t triÓn. Ngoμi ra, ®éi ngò lËp tr×nh viªn ®−îc ®¸nh gi¸ cã kinh nghiÖm vμ cã kh¶ n¨ng tèt. Sö dông m« h×nh COCOMO 81 trung gian ®Ó tÝnh E vμT? 27 Mô hình COCOMO 2 z M« h×nh COCOMO 81 ®−îc ph¸t triÓn trªn gi¶ thiÕt r»ng tiÕn tr×nh ph¸t triÓn phÇn mÒm th¸c n−íc ®−îc sö dông vμ tÊt c¶ c¸c phÇn mÒm ®−îc ph¸t triÓn tõ ®Çu. z M« h×nh COCOMO 2 ®−îc thiÕt kÕ ®Ó thÝch øng víi nh÷ng c¸ch tiÕp cËn kh¸c nhau ®èi víi sù ph¸t triÓn phÇn mÒm 28
Mô hình COCOMO 2 z COCOMO 2 kÕt hîp chÆt chÏ c¸c m« h×nh con nh»m ®−a ra c¸c dù ®o¸n phÇn mÒm chi tiÕt z C¸c m« h×nh con trong COCOMO 2: z M« h×nh Application composition. M« h×nh nμy gi¶ sö r»ng hÖ thèng ®−îc t¹o thμnh tõ c¸c thμnh phÇn cã thÓ t¸i sö dông. M« h×nh nμy ®−îc thiÕt kÕ ®Ó −íc l−îng c«ng søc ph¸t triÓn b¶n mÉu. z M« h×nh Early design: ®−îc sö dông t¹i giai ®o¹n thiÕt kÕ kiÕn tróc khi c¸c yªu cÇu lμ s½n (vμ thiÕt kÕ chi tiÕt vÉn ch−a ®−îc b¾t ®Çu) 29 Mô hình COCOMO 2 z C¸c m« h×nh con trong COCOMO 2: z M« h×nh Reuse: ®−îc sö dông ®Ó tÝnh c«ng søc tÝch hîp c¸c thμnh phÇn cã thÓ dïng l¹i ®−îc vμ / hoÆc m· ch−¬ng tr×nh mμ nã ®−îc tù ®éng sinh ra bëi c¸c c«ng cô dÞch ch−¬ng tr×nh hay thiÕt kÕ. Nã th−êng ®−îc sö dông kÕt hîp víi m« h×nh Post - architecture. z M« h×nh Post-architecture:®−îc sö dông ngay khi kiÕn tróc hÖ thèng ®· ®−îc thiÕt kÕ vμ c¸c th«ng tin chi tiÕt h¬n vÒ hÖ thèng lμ s½n cã. 30
Mô hình COCOMO 2 31 Mô hình Application composition z §Ó −íc l−îng c«ng søc cÇn ®Ó lËp b¶n mÉu c¸c dù ¸n vμ cho c¸c dù ¸n ®−îc ph¸t triÓn b»ng c¸ch kÕt hîp c¸c thμnh phÇn s½n cã z §−îc dùa trªn sè l−îng ®iÓm øng dông (®èi t−îng) z C«ng thøc −íc l−îng c«ng søc E = ( NAP x (1 - %reuse/100 ) ) / PROD (ng−êi – th¸ng) z NAP: sè l−îng ®iÓm øng dông z %reuse: % m· lÖnh ®−îc t¸i sö dông tõ c¸c dù ¸n kh¸c z PROD: hiÖu suÊt. Nã phô thuéc vμo kinh nghiÖm vμ kh¶ n¨ng cña nhμ ph¸t triÓn còng nh− tÝnh tr−ëng thμnh vμ kh¶ n¨ng cña c«ng cô 32
Mô hình Application composition z B¶ng x¸c ®Þnh hiÖu suÊt PROD 33 Mô hình Application composition z Sè l−îng ®iÓm øng dông NAP phô thuéc vμo: z C¸c mμn h×nh riªng biÖt ®−îc hiÓn thÞ (giao diÖn ng−êi dïng) z C¸c b¸o c¸o ®−îc sinh ra bëi hÖ thèng z C¸c thμnh phÇn th− viÖn 34
Mô hình Application composition z TÝnh sè l−îng ®iÓm øng dông z §Õm sè l−îng mμn h×nh, b¸o c¸o vμ module z X¸c ®Þnh ®é phøc t¹p cho tõng thμnh phÇn (1 mμn h×nh hay 1 b¸o c¸o hay 1 module) theo b¶ng sau For Screens For Reports Number and source of data tables Number and source of data tables Number of Total 3 sections ( 3 contained server, server, server, >5 contained server, server, 3- server, 5 client) client) client) client) <3 simple simple medium 0 or 1 simple simple medium 3 - 7 simple medium difficult 2 or 3 simple medium difficult 8 + medium difficult difficult 4 + medium difficult difficult 35 Mô hình Application composition z TÝnh sè ®iÓm øng dông cho tõng thμnh phÇn khi ®· biÕt ®é phøc t¹p theo b¶ng d−íi ®©y Object type Simple Medium Difficult Screen 123 Report 258 3GL component 10 z TÝnh tæng sè ®iÓm øng dông cho tÊt c¶ c¸c thμnh phÇn 36
Mô hình Early design z ¦íc l−îng c«ng søc khi c¸c yªu cÇu ®· ®−îc chÊp nhËn vμ thiÕt kÕ hÖ thèng ®ang ®−îc thùc hiÖn z C«ng thøc −íc l−îng z C«ng søc E= axSb xMvíi z M: tÝch cña 7 hÖ sè nh©n z a = 2.94 z S kÝch th−íc ®−îc −íc l−îng cña hÖ thèng (theo KDSI) z b thay ®æi trong kho¶ng 1.1 tíi 1.24 tïy thuéc vμo tÝnh míi cña hÖ thèng, tÝnh linh ®éng trong ph¸t triÓn, c¸c ph−¬ng ph¸p qu¶n lý rñi ro vμ tÝnh tr−ëng thμnh cña tiÕn tr×nh 37 Mô hình Early design z C¸c hÖ sè nh©n ph¶n ¸nh kh¶ n¨ng cña nhμ ph¸t triÓn, c¸c yªu cÇu phi chøc n¨ng, sù hiÓu biÕt râ vÒ nÒn t¶ng ph¸t triÓn, v.v. z RCPX - product reliability and complexity z RUSE - the reuse required z PDIF - platform difficulty z PREX - personnel experience z PERS - personnel capability z SCED - required schedule z FCIL - the team support facilities z Gi¸ trÞ cña c¸c hÖ sè nμy n»m trong kho¶ng tõ 1 (rÊt thÊp) ®Õn 6 (v« cïng cao) 38
Mô hình Reuse z ¦íc l−îng c«ng søc tÝch hîp m· lÖnh ®−îc sinh ra hay cã thÓ t¸i sö dông z COCOMO 2 xem m· lÖnh ®−îc t¸i sö dông ë mét trong hai d¹ng: z M· t¸i sö dông hép ®en: m· lÖnh ®−îc t¸i sö dông mμ kh«ng cÇn hiÓu hay söa ®æi nã => C«ng søc ph¸t triÓn cho m· hép ®en ®−îc tÝnh lμ 0 z M· t¸i sö dông hép tr¾ng: m· lÖnh ph¶i ®−îc chØnh söa ®Ó tÝch hîp víi m· lÖnh míi hay c¸c thμnh phÇn ®−îc t¸i sö dông kh¸c => CÇn tÝnh ®Õn c«ng søc ph¸t triÓn 39 Mô hình Reuse z NhiÒu hÖ thèng cßn bao gåm c¸c m· lÖnh ®−îc sinh ra mét c¸ch tù ®éng tõ c¸c bé dÞch ch−¬ng tr×nh (mét d¹ng t¸i sö dông) z §èi víi m· lÖnh ®−îc sinh ra tù ®éng, dù ®o¸n c«ng søc ®Ó tÝch hîp m· lÖnh nμy: E= (ASLOC * AT/100)/ATPROD z ASLOC: sè dßng m· lÖnh trong c¸c thμnh phÇn mμ chóng ®−îc chØnh söa (t¸i sö dông hép tr¾ng) z AT: tû lÖ phÇn tr¨m m· lÖnh ®−îc chØnh söa mμ nã ®−îc sinh tù ®éng z ATPROD: hiÖu suÊt cña c¸c kü s− trong viÖc tÝch hîp m· lÖnh ®ã (kho¶ng 2400 c©u lÖnh nguån trong 1 th¸ng) 40
Mô hình Reuse z Dù ®o¸n sè dßng m· nguån míi t−¬ng ®−¬ng ESLOC víi sè m· lÖnh ®−îc t¸i sö dông z ESLOC tÝnh ®Õn c«ng søc hiÓu phÇn mÒm, t¹o ra c¸c thay ®æi ®èi víi m· lÖnh ®−îc t¸i sö dông, t¹o ra c¸c thay ®æi ®èi víi hÖ thèng ®Ó tÝch hîp m· lÖnh ®ã. Nã cßn tÝnh ®Õn sè m· lÖnh ®−îc sinh ra tù ®éng. ESLOC = ASLOC * (1-AT/100) * AAM z ASLOC vμ AT nh− tr−íc z AAM: hÖ sè nh©n hiÖu chØnh sù thÝch øng. Nã ®−îc tÝnh tõ c¸c chi phÝ söa m· lÖnh ®−îc t¸i sö dông, c¸c chi phÝ hiÓu c¸ch tÝch hîp m· lÖnh vμ c¸c chi phÝ ®Ó ra quyÕt ®Þnh t¸i sö dông 41 Mô hình Post-architecture z Sö dông cïng mét c«ng thøc nh− m« h×nh early design nh−ng cã tíi 17 hÖ sè nh©n z C«ng søc E = a x Sb x M víi z M: tÝch cña 17 hÖ sè nh©n z a = 2.94 z S kÝch th−íc ®−îc −íc l−îng cña hÖ thèng (theo KDSI) z b = 1.01 + 0.01 x ∑Wi 42
Mô hình Post-architecture z 17 hÖ sè nh©n M 43 Mô hình Post-architecture z KÝch th−íc m· lÖnh S trong m« h×nh nμy ®−îc tÝnh b»ng c¸ch céng ba −íc l−îng d−íi ®©y: z Sù −íc l−îng vÒ sè dßng m· nguån míi ®−îc ph¸t triÓn z Sù −íc l−îng vÒ sè dßng m· nguån t−¬ng ®−¬ng ®−îc tÝnh b»ng c¸ch sö dông m« h×nh reuse z Sù −íc l−îng vÒ sè dßng m· lÖnh ph¶i ®−îc söa ®æi do c¸c thay ®æi vÒ yªu cÇu 44
Mô hình Post-architecture z C¸c hÖ sè W 45 Mô hình Post-architecture z C¸c hÖ sè W 46
Mô hình COCOMO 2 z Bμi tËp: Nhãm cña b¹n ®−îc giao tr¸ch nhiÖm −íc l−îng c«ng søc thùc hiÖn mét phÇn mÒm cã kho¶ng 100KDSI b»ng m« h×nh COCOMO 2. §©y lμ mét d¹ng phÇn mÒm míi ®èi víi c«ng ty b¹n. §Ó thùc hiÖn nã, c«ng ty ®· tiÕn hμnh thμnh lËp c¸c nhãm. Nhãm cña b¹n thùc hiÖn viÖc −íc l−îng khi kiÕn tróc hÖ thèng ®· ®−îc thiÕt kÕ vμ c¸c th«ng tin chi tiÕt h¬n vÒ hÖ thèng lμ s½n cã. Nh×n chung, c¸c hÖ sè W vμ hÖ sè nh©n ®Òu ë møc ®é b×nh th−êng. Tuy nhiªn, c«ng ty ®Æc biÖt yªu cÇu rÊt cao vÒ sù cÇn thiÕt cña tμi liÖu vμ kinh nghiÖm trong viÖc sö dông c«ng cô vμ ng«n ng÷. 47
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 5 – ĐẶC TẢ YÊU CẦU 1 Nộidung z Quy trình xác định các yêu cầu z Thu thập các yêu cầu z Phân loại các yêu cầu z Các đặc trưng của yêu cầu z Các ký hiệu mô hình hóa z Các ngôn ngữ đặc tả và yêu cầu z Lập bản mẫu cho các yêu cầu z Tài liệu yêu cầu z Xác minh và thẩm định 2
Quy trình xác định các yêu cầu z Một yêu cầu là sự diễn đạt hành vi (behaviour) mong muốn z Một yêu cầu đề cập đến z Các đối tượng hay thực thể z Trạng thái của đối tượng hay thực thể z Các chức năng được thực hiện để thay đổi trạng thái hay các đặc trưng của đối tượng z Các yêu cầu tập trung vào nhu cầu của khách hàng chứ không phải tập trung vào giải pháp hay sự thực hiện z Chỉ định rõ hành vi là gì mà không nói cách thức mà hành vi đósẽ được thực hiện 3 Quy trình xác định các yêu cầu z Các yêu cầu là quan trọng z Các yếu tố hàng đầu làm cho dự án thất bại z Các yêu cầu không hoàn chỉnh z Thiếu sự tham gia của người sử dụng z Các mong muốn không thực tế z Thiếu sự hỗ trợ về quản lý z Thay đổi các yêu cầu và các đặc tả z Thiếu việc lập kế hoạch z Hệ thống không được cần nữa z Một phần nào đó trong quy trình xác định các yêu cầu bị liên quan đến hầu hết các nguyên nhân này z Các lỗi về yêu cầu có thể tốn kém nếu không được phát hiện sớ4m
Quy trình xác định các yêu cầu z Được thực hiện bởi nhà phân tích yêu cầu hay nhà phân tích hệ thống z Kết quả cuối cùng là tài liệu đặc tả các yêu cầu phần mềm 5 Thu thập các yêu cầu z Khách hàng không luôn hoàn toàn mô tả một cách chính xác họ cần cái gì và vấn đề của họ là gì z Nhà phân tích không luôn hoàn toàn hiểu nghiệp vụ của khách hàng z Sự thảo luận với các thành viên tham gia vào hoạt động thu thập yêu cầu là quan trọng z Sự thảo luận đưa đến sự đồng ý giữa các bên về các yêu cầu 6
Thu thập các yêu cầu z Các thành viên tham gia trong hoạt động thu thập yêu cầu z Clients: trả tiền cho phần mềm được phát triển z Customers: mua phần mềm sau khi nó được phát triển z Người dùng:sử dụng hệ thống z Chuyên gia về lĩnh vực:biết rõ vấn đề mà phần mềm phải tin học hóa z Nhà nghiên cứu thị trường:thực hiện các cuộc khảo sát để xác định các xu hướng tương lai và những khách hàng tiềm năng z Luật sư và kiểm toán viên:biết rõ các yêu cầu của luật pháp, chính phủ hay sự an toàn z Kỹ sư phần mềm và các chuyên gia công nghệ khác: đảm bảo phần mềm là khả thi về kinh tế và công nghệ 7 Thu thập các yêu cầu z Các cách thu thập yêu cầu z Phỏng vấn những người tham gia trong hệ thống z Phỏng vấn những người tham gia vào hệ thống theo nhóm z Xem lại các tài liệu có sẵn z Quan sát hệ thống hiện hành (nếu hệ thống tồn tại) z Theo người dùng để học về nghiệp vụ của họ một cách chi tiết hơn z Sử dụng các chiến lược xác định vấn đề như thiết kếứng dụng chung (Joint Application Design) z Vận dụng trí tuệ (brainstorming) của người dùng hiện tại và tiềm năng để có được các yêu cầu 8
Thu thập các yêu cầu z Các nguồn của các yêu cầu có thể có 9 Phân loại các yêu cầu z Phân loại các yêu cầu z Giải quyết các xung đột z Các loại tài liệu yêu cầu 10
Phân loại các yêu cầu z Các yêu cầu chức năng: mô tả các chức năng và dịch vụ mà hệ thống phải cung cấp z Các yêu cầu phi chức năng: mô tả một đặc trưng nào đóvề chất lượng nào mà phần mềm phải có; các ràng buộc thiết kế như chọn nền hay các thành phần của giao diện; các ràng buộc quy trình như sự hạn chế về các kỹ thuật và các tài nguyên được sử dụng để xây dựng hệ thống 11 Phân loại các yêu cầu z Các loại yêu cầu phi chức năng 12
Phân loại các yêu cầu z Giải quyết sự xung đột z Các thành viên khác nhau có các yêu cầu khác nhau => các yêu cầu xung đột tiềm ẩn z Giải quyết sự xung đột bằng cách sắp thứ tự ưu tiên cho các yêu cầu z Sự ưu tiên hóa phân tách các yêu cầu vào ba hạng mục sau z Cần thiết:phải được đáp ứng một cách hoàn toàn z Mong muốn: mong được đáp ứng nhưng không nhất thiết z Tùy chọn:cóthể được đáp ứng nhưng có thể bị loại trừ 13 Phân loại các yêu cầu z Các loại tài liệu yêu cầu z Định nghĩa các yêu cầu:một danh sách hoàn chỉnh về những thứ mà khách hàng muốn đạt được z Mô tả các thực thể trong môi trường nơi hệ thống sẽ được cài đặt z Mô tả các phép biến đổi hay các ràng buộc lên các thực thể đó z Đặc tả các yêu cầu:diễn tả lại các yêu cầu như một đặc tả về cách mà hệ thống được đề nghị sẽ hoạt động z Chỉ tham khảo tới các thực thể mà hệ thống có thể truy xuất chúng qua giao diện của hệ thống 14
Các đặc trưng của yêu cầu z Chính xác (Correct) z Nhất quán (Consistent) z Không mơ hồ (Unambigious) z Hoàn chỉnh (Complete) z Khả thi (Feasible) z Có liên quan (Relevant) z Có thể kiểm thử (Testable) z Có thể theo vết (Traceable) 15 Các ký hiệu mô hình hóa z Việc có các ký hiệu chuẩn để mô hình hóa các quyết định là quan trọng z Việc mô hình hóa giúp ta hiểu thấu đáo các yêu cầu z Các khuyết điểm trong mô hình bộc lộ cách hoạt động mơ hồ hay không được biết z Các kết xuất nhiều, xung đột nhau đối với cùng một nguồn vào bộc lộ sự không nhất quán trong các yêu cầu 16
Các ký hiệu mô hình hóa z Các ký hiệu mô hình hóa z Lưu đồ thực thể quan hệ (Entity Relationship Diagram - ERD) z Dò theo sự kiện (Event Traces) z Máy trạng thái (State Machines) z Lưu đồ dòng dữ liệu (Data Flow Diagram) z Các chức năng và quan hệ (Functions and Relations) z Logic 17 Lưu đồ thực thể quan hệ z Một lưu đồ ký hiệu dạng đồ thị được ưa chuộng dùng để biểu diễn các mô hình mức quan niệm z Các thành phần cốt lõi trong lưu đồ z Thực thể: được vẽ như một hình chữ nhật, biểu diễn cho tập các đối tượng trong thế giới thực mà chúng có chung các đặc điểm và cách hoạt động z Quan hệ: được vẽ như một cạnh nối hai thực thể, với hình thoi ở chính giữa cạnh xác định loại quan hệ z Thuộc tính: một diễn giải trong thực thể. Nó mô tả dữ liệu hay các đặc tính được kết hợp với thực thể 18
Lưu đồ thực thể quan hệ z Ví dụ: 1, N 1, N Tác giả Viết Sách z Lược đồ thực thể quan hệ là phổ biến vì z Nó cung cấp một cái nhìn tổng quan về vấn đề đã được xác định z Tính tổng quan là tương đối ổn định khi có thay đổi trong các yêu cầu z Lược đồ thực thể quan hệ có vẻ phù hợp để mô hình hóa vấn đề sớm trong quy trình xác định các yêu cầu 19 Lưu đồ thực thể quan hệ z Ví dụ: sơ đồ lớp của UML (UML Class Diagram) là một lược đồ thực thể quan hệ phức tạp 20
Lưu đồ thực thể quan hệ z Ví dụ: sơ đồ lớp của UML là lược đồ thực thể quan hệ phức tạp z Các thuộc tính và các phương thức được kết hợp với lớp hơn là với các thể hiện của lớp z Thuộc tính phạm vi lớp, được biểu diễn như một thuộc tính được gạch chân, là một giá trị dữ liệu mà nó được chia sẻ bởi tất cả các thể hiện của lớp z Phương thức phạm vi lớp, được biểu diễn như một phương thức được gạch chân, là một phương thức được thực hiện bởi lớp trừu tượng (hơn là bởi các thể hiện của lớp) trên một thể hiện mới hay trên toàn bộ z Liên kết (association), được đánh dấu như một đường nối giữa hai lớp, chỉ ra mối quan hệ giữa các thực thể của các lớp 21 Lưu đồ thực thể quan hệ z Ví dụ: sơ đồ lớp của UML là lược đồ thực thể quan hệ phức tạp z Liên kết kết tập (aggregation association) là một mối quan hệ “chứa đựng” về cấu trúc hoặc hành vi của một phần tử trong một tập hợp. Hình thoi rỗng được ký hiệu trên liên kết về phía lớp biểu diễn tập hợp chứa đựng. z Liên kết cấu thành (composition association) là một liên kết kết tập đặc biệt. Nó mô tả một sự chứa đựng về cấu trúc giữa các thể hiện. Hình thoi đặc được ký hiệu trên liên kết ở phía lớp chứa. z Liên kết tổng quát hóa z 22
Dò theo sự kiện z Mô hình thực thể quan hệ không nói gì về cách mà các thực thể hành xử z Dò theo sự kiện là sự mô tảởdạng đồ họa của một chuỗi các sự kiện mà chúng được trao đổi giữa các thực thể của thế giới thực z Đường dọc: đường thời gian của một thực thể riêng biệt; tên của nó xuất hiện trên đỉnh của đường z Đường ngang:một sự kiện hay sự tương tác giữa hai thực thể z Thời gian tiến triển theo hướng từ trên xuống z Mỗi đồ thị mô tả một đơn dò theo sự kiện, đại diện cho một trong một vài cách hoạt động có thể có z Các dò theo sự kiện phổ biến đối với nhà phát triển và khách hàng vì chúng tương đối chính xác, đơn giản và dễ hiểu) 23 Dò theo sự kiện z Ví dụ: biểu đồ trình tự thông điệp là ký hiệu dò theo sự kiện được cải tiến, với các phương tiện cho phép tạo ra hay hủy bỏ các thực thể, xác định các hoạt động và định thời, và tạo ra các dò theo z Đường dọc biểu diễn cho một thực thể tham gia z Thông điệp được vẽ bằng một mũi tên hướng từ thực thể gửi sang thực thể nhận. z Hoạt động được vẽ bằng hình chữ nhật được gán nhãn và được đặt trên đường thực thi của thực thể z Điều kiện là các trạng thái quan trọng trong sự tiến hóa của thực thể, được biểu diễn bằng hình sáu cạnh có gán nhãn 24
Dò theo sự kiện z Ví dụ biểu đồ trình tự thông điệp là dò theo sự kiện được cải tiến: biểu đồ trình tự thông điệp cho giao dịch mượn tài liệu của thư viện 25 Máy trạng thái z Sự mô tảởdạng đồ họa của tất cả các cuộc đối thoại giữa hệ thống và môi trường của nó z Nút (trạng thái)biểu diễn một tập ổn định các điều kiện mà nó tồn tại giữa các lần xuất hiện của sự kiện z Cạnh (dịch chuyển)biểu diễn cho sự thay đổi về hành vi hay điều kiện do sự xuất hiện của một sự kiện z Hữu ích cả cho việc xác định hành vi động và cho việc mô tả cách mà hành vi nên thay đổi để đáp ứng được lịch sử của các sự kiện mà chúng đã xuất hiện 26
Máy trạng thái z Đường đi: bắt đầu từ trạng thái bắt đầu của máy và đi theo các dịch chuyển từ trạng thái này sang trạng thái khác z Máy trạng thái hữu hạn: với mỗi trạng thái hay sự kiện, có một đáp ứng duy nhất 27 Máy trạng thái z Ví dụ: sơ đồ trạng thái của UML z Mô tả hành vi động của các đối tượng trong một lớp UML z Có một cú pháp phong phú, bao gồm sự phân cấp trạng thái, sự đồng thời và giao tiếp giữa các máy 28
Máy trạng thái z Ví dụ sơ đồ trạng thái của UML cho lớp Publication 29 Máy trạng thái z Ví dụ: mạng Petri z Ký pháp dịch chuyển trạng thái được sử dụng để mô hình hóa các hoạt động đồng thời và sự tương tác của chúng zVòng tròn biểu diễn cho các hoạt động hay các điều kiện zThanh ngang/ dọcbiểu diễn cho các dịch chuyển zCung nối kết một dịch chuyển với các hoạt động và điều kiện vào và ra của nó 30
Máy trạng thái z Ví dụ: mạng Petri cho mượn sách 31 Lưu đồ dòng dữ liệu z Lược đồ thực thể quan hệ phân rã vấn đề theo các thức thể z Dò theo sự kiện phân rã vấn đề theo kịch bản z Máy trạng thái phân rã vấn đề theo trạng thái điều khiển z Cả ba chỉ mô tả các hành vi mức thấp => rất khó nhìn thấy chức năng mức cao của mô hình 32
Lưu đồ dòng dữ liệu z Lưu đồ dòng dữ liệu mô hình hóa chức năng và dòng dữ liệu từ chức năng này sang chức năng khác z Hình elip biểu diễn cho quy trình hay chức năng: biến đổi dữ liệu z Mũi tên biểu diễn cho dòng dữ liệu (vào hay ra của chức năng) z Hai đường song song biểu diễn cho kho dữ liệu: lưu giữ các dữ liệu z Hình chữ nhật biểu diễn cho các tác nhân: các thực thể cung cấp dữ liệu vào và nhận kết quả kết xuất 33 Lưu đồ dòng dữ liệu z Lưu đồ dòng dữ liệu mức cao biểu diễn cho bài toán thư viện 34
Lưu đồ dòng dữ liệu z Thuận lợi: z Cung cấp một mô hình trực quan về chức năng mức cao của hệ thống được đề nghị và của các phụ thuộc dữ liệu giữa các quy trình khác nhau z Khó khăn : z Có thể làm tăng tính mơ hồ đối với nhà phát triển phần mềm người chưa quen với vấn đề đang được mô hình hóa 35 Lưu đồ dòng dữ liệu z Ví dụ: sơ đồ use case của UML z Các thành phần z Đường biên của hệ thống (được ký hiệu bởi hình chữ nhật) z Tác nhân (được ký hiệu bởi hình người hay >) z Trường hợp sử dụng – use case - (được ký hiệu bằng hình oval). Một use case biểu diễn một chức năng được yêu cầu nào đóvàbiến thể của nó z Quan hệ giữa tác nhân và use case hay giữa các use case (được biểu diễn bằng các đường hay đường nét đứt) 36
Lưu đồ dòng dữ liệu z Ví dụ lược đồ use case của UML: một số use case của thư viện 37 Các ngôn ngữ đặc tả và yêu cầu z Ngôn ngữ mô hình hóa hợp nhất (Unified Modeling Language - UML) z Ngôn ngữ mô tả và đặc tả (Specification and Description Language – SDL) 38
Các ngôn ngữ đặc tả và yêu cầu z UML (Unified Modeling Language) z Kết hợp nhiều sơ đồ ký hiệu z Các sơ đồ UML được sử dụng trong suốt sự định nghĩa và đặc tả các yêu cầu z Sơ đồ use case (Lưu đồ dòng dữ liệu mức cao) z Sơ đồ lớp(Lưu đồ thực thể quan hệ) z Sơ đồ tuần tự (Dò theo sự kiện) z Sơ đồ cộng tác (Dò theo sự kiện) z Sơ trạng thái (Mô hình trạng thái máy) 39 Các ngôn ngữ đặc tả và yêu cầu z Ngôn ngữ mô tả và đặc tả (SDL) z Xác định hành vi của các quy trình phân tán, đồng thời và thời gian thực mà chúng giao tiếp với nhau thông qua các hàng đợi thông điệp không giới hạn z Bao gồm z Sơ đồ hệ thống SDL (Lưu đồ dòng dữ liệu) z Sơ đồ khối SDL (Lưu đồ dòng dữ liệu) z Sơ đồ quy trình SDL (Mô hình máy trạng thái) z Kiểu dữ liệu SDL (Đặc tả đại số) z Thường được đi kèm bởi một tập biểu đồ trình tự của thông điệp 40
Lập bản mẫu cho các yêu cầu z Xây dựng bản mẫu z Để thu thập các chi tiết của hệ thống được đề nghị z Để cố gắng lấy được thông tin phản hồi từ người dùng tiềm năng về z Những khía cạnh nào mà họ muốn cải tiến z Những đặc tính nào là không quá hữu ích z Chức năng nào đang thiếu z Giúp xác định xem vấn đề của khách hàng có giải pháp khả thi hay không z Hỗ trợ trong việc thăm dò các chọn lựa để tối ưu hóa các yêu cầu về chất lượng 41 Lập bản mẫu cho các yêu cầu z Các cách tiếp cận để làm bản mẫu z Cách tiếp cận được làm ra để sử dụng một lần duy nhất (throwaway prototype) z Được phát triển để nghiên cứu thêm về vấn đề hay giải pháp được đề nghị , và không bao giờ được xem là một phần của phần mềm được phân phối z Cách tiếp cận tiến hóa (evolutionary prototype) z Được phát triển không chỉ giúp chúng ta trả lời các câu hỏi mà còn được kết hợp vào sản phẩm cuối cùng z Bản mẫu cuối cùng phải biểu thị các yêu cầu về chất lượng của sản phẩm cuối z Cả hai kỹ thuật này đôi khi được gọi là làm bản mẫu nhanh 42
Lập bản mẫu cho các yêu cầu z Sự khác nhau giữa lập bản mẫu và mô hình hóa z Lập bản mẫu zTốt khi trả lời những câu hỏi về giao diện người dùng z Mô hình hóa zTrả lời nhanh các câu hỏi về các ràng buộc theo thứ tự mà theo đó các sự kiện nên xuất hiện, về sự đồng bộ của các hoạt động 43 Tài liệu yêu cầu z Định nghĩa các yêu cầu - Các bước của quy trình z Phác thảo mục đích chung và phạm vi của hệ thống, bao gồm các lợi ích liên quan, các mục tiêu và mục đích z Mô tả nền tảng và nhân tố cơ bản ở sau sự đề xuất cho hệ thống mới z Mô tả các đặc trưng cần thiết của một giải pháp có thể chấp nhận được z Mô tả môi trường trong đóhệ thống sẽ vận hành z Phác thảo sự mô tả về đề xuất, nếu khác hàng có một đề xuất cho giải quyết vấn đề z Liệt kê bất cứ giả định nào về cách mà môi trường hoạt động 44
Tài liệu yêu cầu z Đặc tả các yêu cầu - Các bước của quy trình z Mô tả chi tiết tất cả các đầu vào, đầu ra, bao gồm z Các nguồn của đầu vào z Các đích của đầu ra z Các miền giá trị z Định dạng dữ liệu cho dữ liệu vào/ra z Các giao thức của dữ liệu z Tổ chức và định dạng của cửa sổ z Ràng buộc thời gian z Diễn đạt lại chức năng được yêu cầu dưới dạng các đầu vào/ra của giao diện z Đưa ra tiêu chuẩn phù hợp cho từng yêu cầu về chất lượng của khách hàng 45 Tài liệu yêu cầu z Chuẩn IEEE cho đặc tả các yêu cầu phần mềm 1.Introduction to the Document 1.1 Purpose of the Product 1.2 Scope of the Product 1.3 Acronyms, Abbreviations, Definitions 1.4 References 1.5 Outline of the rest of the SRS 2.General Description of Product 2.1 Context of Product 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 46
Tài liệu yêu cầu 3. Specific Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 3.3 Performance Requirements 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4. Appendices 47 Xác minh & Thẩm định z Thẩm định (validation) của các yêu cầu: ta kiểm tra xem định nghĩa các yêu cầu có phản ánh chính xác nhu cầu của khách hàng z Xác minh (verification): ta kiểm tra xem một tài liệu được tạo ra có tuân theo tài liệu khác 48
Xác minh & Thẩm định z Các kỹ thuật thẩm định 49 Xác minh & Thẩm định z Xác minh z Kiểm tra xem tài liệu đặc tả các yêu cầu có tương đương với định nghĩa các yêu cầu z Đảm bảo rằng nếu ta thực hiện một hệ thống mà nó đáp ứng sự đặc tả thì hệ thống sẽ đáp ứng các yêu cầu của khách hàng z Đảm bảo rằng mỗi yêu cầu trong tài liệu định nghĩa là có thể theo dõi qua dấu vết của đặc tả 50
Kiểm tra và xác nhận tính hợp lệ z Các kỹ thuật xác minh 51
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 6 – THIẾT KẾ 1 Nộidung z Định nghĩa về thiết kế z Các nội dung thiết kế z Một số vấn đề trong sự tạo ra thiết kế z Đặc trưng của thiết kế hoàn thiện z Tài liệu thiết kế 2
Định nghĩa về thiết kế z Thiết kế là quá trình sáng tạo thực hiện việc biến đổi vấn đề sang giải pháp z Sự mô tả của một giải pháp còn được biết như là thiết kế z Đặc tả các yêu cầu định nghĩa vấn đề z Tài liệu thiết kế xác định một giải pháp cụ thể cho vấn đề 3 Định nghĩa về thiết kế z Thiết kế là một quá trình tương tác gồm hai phần z Thiết kế mức khái niệm (Thiết kế hệ thống) z Thiết kế kỹ thuật 4
Định nghĩa về thiết kế z Thiết kế mức khái niệm nói với khách hàng những cái mà hệ thống phải làm: z Dữ liệu đến từ đâu? z Điều gì sẽ xảy ra với dữ liệu trong hệ thống? z Hệ thống trông giống cái gì? z Những lựa chọn nào sẽ được cung cấp cho người dùng? z Các báo cáo và màn hình giống cái gì? z Định thời gian cho các sự kiện 5 Định nghĩa về thiết kế z Thiết kế mức khái niệm Các đặc trưng của một thiết kế mức khái niệm hoàn thiện z Theo ngôn ngữ mà khách hàng có thể hiểu z Không có các từ kỹ thuật z Mô tả các chức năng của hệ thống z Độc lập với sự thực hiện z Được liên kết với các yêu cầu 6
Định nghĩa về thiết kế z Thiết kế kỹ thuật nói với lập trình viên những cái mà hệ thống phải làm như: z Các thành phần phần cứng chính và chức năng của chúng z Sự phân cấp và các chức năng của các thành phần phần mềm z Các cấu trúc dữ liệu và dòng dữ liệu 7 Định nghĩa về thiết kế z Sự khác nhau trong tài liệu thiết kế 8
Định nghĩa về thiết kế z Mỗi phương pháp thiết kế đều liên quan đến một dạng phân rã z Bắt đầu bằng sự mô tả mức cao về các thành phần chính của hệ thống z Tạo ra các mô tả mức thấp hơn về cách mà các đặc trưng và chức năng của hệ thống phù hợp với nhau 9 Định nghĩa về thiết kế z Những phương pháp tạo ra thiết kế z Phân rã theo mô đun z Phân rã hướng dữ liệu z Phân rã hướng sự kiện z Thiết kế trong ngoài z Thiết kế hướng đối tượng z Dù là phương pháp thiết kế nào, nó cũng phân rã hệ thống thành các thành phần hay mô đun 10
Các nội dung thiết kế z Nhà thiết kế thực hiện các công việc: z Thiết kế kiến trúc z Thiết kế dữ liệu z Thiết kế giao diện z Thiết kế thủ tục (thuật toán) 11 Thiết kế kiến trúc z Thiết kế kiến trúc z Phân rã hệ thống thành một tập các thành phần z Xác định các giao diện giữa các thành phần z Định nghĩa các hoạt động tạo ra hệ thống từ các thành phần z Cung cấp một cái nhìn tổng thể về hệ thống 12
Thiết kế kiến trúc z Các thành phần của hệ thống có thể được kết hợp với nhau theo các kiểu kiến trúc: z Đường dẫn và bộ lọc z Thiết kế hướng đối tượng z Sự dẫn chứng ẩn z Phân lớp z Kho chứa z Bộ phiên dịch z Kiểm soát quy trình z Khách – chủ 13 Thiết kế dữ liệu z Thiết kế dữ liệu z Các thành phần dữ liệu và bảng để tạo CSDL z Các cấu trúc dữ liệu z Các mức thiết kế dữ liệu z Thiết kế cấu trúc logic: các quan hệ chuẩn, các khóa, các tham chiếu, các cấu trúc thao tác dữ liệu z Thiết kế cấu trúc vật lý: các file, các kiểu, kích cỡ 14
Thiết kế giao diện z Thiết kế giao diện z Các form nhập liệu z Các reports và những kết xuất mà hệ thống mới phải sinh ra 15 Thiết kế giao diện z Các vấn đề then chốt được xem xét khi thiết kế giao diện z Các vấn đề về văn hóa (dân tộc, giới tính, nghề nghiệp, tuổi tác, vùng miền) z Sở thích của người dùng z Một số lưu ý khi thiết kế giao diện z Nên có sự đồng nhất giữa các giao diện (menu, lệnh, hiển thị ) z Đặt tên nhãn ngắn gọn, dễ nhớ z Tối ưu trong trình bày hộp thoại và di chuyển chuột 16
Thiết kế giao diện z Một số lưu ý khi thiết kế giao diện z Hạn chế nhập dữ liệu trực tiếp, nếu có thể, nên cho người dùng chọn lựa từ một số dữ liệu có sẵn z Yêu cầu xác nhận những tác vụ mang tính phá hủy (xoá dữ liệu) z Chấp nhận lỗi từ phía người sử dụng z Nên cung cấp feedback cho người dùng z Tạo ra thông báo lỗi có ý nghĩa z Cung cấp trợ giúp 17 Thiết kế thủ tục z Thiết kế thủ tục (thuật toán) z Giải thích quá trình xử lý từ input đến output. z Phương pháp biểu diễn z Lưu đồ giải thuật z Ngôn ngữ giả 18
Một số vấn đề trong việc tạo ra thiết kế z Thiết kế cộng tác z Hầu hết các dự án làm việc cộng tác z Các vấn đề trong thiết kế cộng tác z Ai là người phù hợp nhất để thiết kế từng bộ phận của hệ thống z Viết tài liệu thiết kế như thế nào z Làm thế nào để kết hợp các thành phần thiết kế thành một thiết kế hợp nhất z Các vấn đề trong việc thực hiện thiết kế cộng tác z Sự khác nhau về kinh nghiệm cá nhân, sự hiểu biết, sở thích 19 Một số vấn đề trong việc tạo ra thiết kế z Sự đồng thời z Các vấn đề z Tính nhất quán của dữ liệu được chia sẻ giữa các thành phần mà chúng thực thi tại cùng thời điểm z Đảm bảo rằng một hoạt động không can thiệp vào các hoạt động khác z Các giải pháp z Sự đồng bộ:phương pháp cho phép hai hoạt động thực hiện đồng thời mà không can thiệp vào nhau z Loại trừ lẫn nhau:một quy trình truy xuất một phần tử dữ liệu, không có quy trình nào khác ảnh hưởng tới phần tử z Giám sát:một đối tượng trừu tượng kiểm soát sự loại trừ lẫn nhau của một quy trình cụ thể 20
Các đặc trưng của một thiết kế hoàn thiện z Sự độc lập của thành phần z Sự ghép nối (coupling) z Sự gắn kết (cohesion) z Nhận dạng và xử lý các ngoại lệ z Ngăn chặn và chấp nhận các lỗi trong giới hạn cho phép z Chủ động z Bị động 21 Sự ghép nối z Các thành phần được ghép nối cao khi có một lượng lớn các phụ thuộc z Các thành phần được ghép nối lỏng lẻo khi có một sự phụ thuộc nào đó nhưng các quan hệ giữa các thành phần yếu z Các thành phần không được ghép nối khi không có các quan hệ nào cả 22
Sự ghép nối z Ta có thể đo sự ghép nối theo mức độ phụ thuộc 23 Sự ghép nối z Các loại ghép nối z Ghép nối nội dung: một thành phần sửa dữ liệu nội bộ của một thành phần khác hay một thành phần rẽ nhánh sang một thành phần khác z Ghép nối chung: các thành phần truy xuất và làm thay đổi dữ liệu chung z Ghép nối kiểm soát: một thành phần truyền các tham số để điều khiển hoạt động của một thành phần khác z Ghép nối cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để truyền thông tin từ một thành phần này sang một thành phần khác z Ghép nối dữ liệu: chỉ có dữ liệu được truyền từ từ một thành phần này sang một thành phần khác 24
Sự ghép nối z Ví dụ Ghép nối chung Ghép nối nội dung 25 Sự gắn kết z Một thành phần là gắn kết nếu tất cả các thành viên của thành phần được hướng tới và cần thiết để thực hiện cùng một công việc z Một số dạng gắn kết 26
FUNCTION A FUNCTION A TIME T0 FUNCTION A FUNCTION FUNCTION logic FUNCTION A’ TIME T0 + X FUNCTION B B C FUNCTION FUNCTION FUNCTION A” TIME T0 + 2X FUNCTION C D E Coincidental Logical Temporal Procedural Parts unrelated Similar functions Related by time Related by order of functions DATA FUNCTION A FUNCTION A FUNCTION A - part 1 FUNCTION B FUNCTION B FUNCTION A - part 2 FUNCTION C FUNCTION C FUNCTION A - part 3 Functional Sequential Functional Access same data Output of one part Sequential with is input to next complete, related functions 27 Nhận dạng và xử lý ngoại lệ z Các ngoại lệ:những tình huống mà nó ngược lại với cái mà ta thực sự muốn hệ thống làm z Không thực hiện được việc cung cấp một dịch vụ z Cung cấp dữ liệu hay dịch vụ sai z Làm hư dữ liệu z Các ngoại lệ có thể được xử lý theo một trong ba cách sau z Thử lại z Hiệu chỉnh z Báo cáo 28
Ngăn chặn và chấp nhận các lỗi z Phát hiện lỗi chủ động: định kỳ kiểm tra các dấu hiệu về lỗi hoặc cố gắng giải quyết trước khi lỗi xuất hiện z Phát hiện lỗi bị động: chờ cho đến khi lỗi xuất hiện trong suốt sự thực thi z Hiệu chỉnh lỗi: sự đền bù của hệ thống cho sự hiện diện của lỗi z Chấp nhận lỗi: cô lập những thiệt hại được gây ra bởi lỗi 29 Viết tài liệu thiết kế z Tài liệu thiết kế gồm: z Mục nêu lý do cơ bản của thiết kế z Phác thảo những vấn đề then chốt và các thỏa hiệp z Mục mô tả về các thành phần của hệ thống z Mục xác định cách mà người dùng tương tác với hệ thống z Tập các biểu đồ và ký pháp hình thức mô tả toàn bộ tổ chức và cấu trúc của hệ thống 30
Viết tài liệu thiết kế z Mục xác định cách mà người sử dụng tương tác với hệ thống z Các menu và các định dạng màn hình hiển thị z Giao diện người dùng: các phím chức năng, v.v. z Kết nhập: dữ liệu đến từ đâu, cách mà chúng được định dạng, chúng được lưu giữ trên phương tiện nào z Kết xuất: dữ liệu đến từ đâu, cách mà chúng được định dạng, chúng được lưu giữ trên phương tiện nào z Các đặc trưng chức năng chung z Các ràng buộc về sự thực thi z Các thủ tục lưu giữ z Cách phương pháp xử lý lỗi 31
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 7 – LẬP TRÌNH 1 Nộidung z Các chuẩn và thủ tục lập trình z Chọn ngôn ngữ lập trình z Nguyên tắc lập trình z Viết tài liệu 2
Các chuẩn và thủ tục lập trình z Chuẩn và thủ tục giúp lập trình viên z Tổ chức các ý định và tránh các lỗi z Các tài liệu theo chuẩn giúp ta quay lại công việc mà không mất dấu những gì đã làm z Các tài liệu theo chuẩn giúp ta định vị các lỗi và tạo ra các thay đổi z Dịch các thiết kế sang mã lệnh Các chuẩn và thủ tục lập trình z Chuẩn và thủ tục giúp các thành viên khác z Giúp các thành viên khác hiểu được mã lệnh (do lập trình viên viết ra) làm gì và làm như thế nào nhằm thực hiện việc: z Tái sử dụng (lập trình viên khác) z Kiểm thử (kiểm thử viên) z Hiệu chỉnh hay hoàn thiện hệ thống (bảo trì viên) z Ví dụ: Mỗi chương trình được tạo ra bởi một công ty phần mềm đều bắt đầu bằng đoạn chú thích mô tả các chức năng của chương trình và giao diện với các chương trình khác => giúp ích rất nhiều cho các thành viên khác.
Các chuẩn và thủ tục lập trình z Chuẩn và thủ tục giúp tạo ra sự tương ứng trực tiếp giữa các thành phần thiết kế và các thành phần cài đặt z Các đặc trưng của chương trình nên giống như các đặc trưng của thiết kế: ghép nối thấp, gắn kết cao và các giao diện rõ ràng => z Các giải thuật, chức năng, giao diện và cấu trúc dữ liệu có thể được dò theo từ thiết kế sang chương trình và ngược lại một cách dễ dàng 5 Chọn ngôn ngữ lập trình z Theo loại phần mềm z Phần mềm hệ thống: C, C++ z Phần mềm thời gian thực: C, C++, Assembly z Phần mềm nhúng: C++, Java z Phần mềm nghiệp vụ (HTTT): z CSDL: Oracle, MySQL, SQL Server z NNLT: VB, Foxpro, VC++ z Phần mềm trí tuệ nhân tạo: Prolog, Lisp z Phần mềm (dịch vụ) Web: PHP, ASP, Java Script z Theo đặc trưng của ngôn ngữ z Theo năng lực và kinh nghiệm của nhóm phát triển phần mềm z Theo yêu cầu của khách hàng 6
Nguyên tắc lập trình z Dù bất cứ ngôn ngữ lập trình nào được sử dụng, mỗi thành phần chương trình đều liên quan tới ít nhất 3 khía cạnh chính sau: z Cấu trúc điều khiển z Giải thuật z Cấu trúc dữ liệu 7 Cấu trúc điều khiển z Tạo ra mã lệnh dễ đọc Ví dụ: Cho đoạn chương trình benefit = minimum; if (age Rất khó đọc. Ta nên viết lại như thế nào? 8
Cấu trúc điều khiển z Ví dụ: Đoạn chương trình benefit = minimum; if (age < 75) goto A; benefit = maximum; goto C; if (AGE < 65) goto B; if (AGE < 55) goto C; A: if (AGE < 65) goto B; benefit = benefit * 1.5 + bonus; goto C; B: if (age < 55) goto C; benefit = benefit * 1.5; C: next statement Được viết lại: if (age < 55) benefit = minimum; elseif (AGE < 65) benefit = minimum + bonus; elseif (AGE < 75) benefit = minimum * 1.5 + bonus; else benefit = maximum; Cấu trúc điều khiển z Xây dựng chương trình từ các khối mô đun nhằm làm cho hệ thống dễ hiểu, dễ kiểm thử và dễ bảo trì z Viết mã lệnh có tính tổng quát nhưng không làm ảnh hưởng đến sự thực hiện và sự hiểu biết z Sử dụng các tên tham số và các chú thích để biểu thị sự kết hợp giữa các thành phần z Tạo sự phụ thuộc giữa các thành phần một cách rõ ràng 10
Giải thuật z Mục tiêu chung: tăng hiệu quả thực hiện (tốc độ) z Tính hiệu quả trong sự thực hiện có thể có các chi phí ẩn z Tốn thời gian để viết mã lệnh thực thi nhanh hơn z Tốn thời gian để kiểm thử mã lệnh z Tốn thời gian để người dùng hiểu mã lệnh z Tốn thời gian để hiệu chỉnh mã lệnh, nếu cần => Cân bằng thời gian thực thi với chất lượng thiết kế, chuẩn và các yêu cầu của khách hàng Cấu trúc dữ liệu z Ta nên định dạng và lưu trữ dữ liệu sao cho việc quản lý và thực hiện trên dữ liệu là không phức tạp z Các cấu trúc dữ liệu: danh sách, ngăn xếp, cây, v.v z Một số kỹ thuật sử dụng cấu trúc dữ liệu để tổ chức chương trình z Làm cho chương trình đơn giản z Sử dụng cấu trúc dữ liệu để xác định cấu trúc chương trình
Cấu trúc dữ liệu z Làm cho chương trình đơn giản Ví dụ: xác định thuế thu nhập z Với $10,000 thu nhập đầu tiên, thuế là 10% z Với $10,000 thu nhập tiếp theo (trên $10,000), thuế là 12% z Với $10,000 thu nhập tiếp theo (trên $20,000), thuế là 15% z Với $10,000 thu nhập tiếp theo(trên $30,000), thuế là 18% z Với bất cứ thu nhập nào trên $40,000, thuế là 20% 13 Cấu trúc dữ liệu tax = 0. if (taxable_income == 0) goto EXIT; if (taxable_income > 10000) tax = tax + 1000; else { tax = tax + .10*taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax + 1200; else { tax = tax + .12*(taxable_income-10000): goto EXIT; } if (taxable_income > 30000) tax = tax + 1500; else { tax = tax + .15*(taxable_income-20000); goto EXIT; } if (taxable_income < 40000){ tax = tax + .18*(taxable_income-30000); goto EXIT; } else tax = tax + 1800. + .20*(taxable_income-40000); 14 EXIT;
Cấu trúc dữ liệu z Xác định bảng thuế Bracket Base Percent 0 0 10 10,000 1000 12 20,000 2200 15 30,000 3700 18 40,000 55000 20 z Giải thuật được đơn giản hóa for (int i=2; level=1; i bracket[i]) level = level + 1; tax = base[level]+percent[level]*(taxable_income-bracket[level]); Cấu trúc dữ liệu z Sử dụng cấu trúc dữ liệu để xác định cấu trúc chương trình z Cấu trúc dữ liệu chi phối tổ chức chương trình z Cấu trúc dữ liệu có thể tác động đến việc chọn ngôn ngữ z Nếu cấu trúc dữ liệu đệ quy, chọn ngôn ngữ cho phép lập trình các thủ tục đệ quy z Nếu cấu trúc dữ liệu là danh sách, chọn ngôn ngữ Lisp z 16
Nguyên tắc chung z Cục bộ hóa input và output z Các phần đọc input và sinh ra output là những phần có khả năng phải thay đổi nhiều nhất khi phần cứng và phần mềm được sửa đổi z Chúng được tách riêng khỏi phần còn lại của mã lệnh nhằm giúp ta dễ hiểu và dễ thay đổi hệ thống hơn z Tái sử dụng z Tái sử dụng của nhà sản xuất: tạo ra các thành phần mà chúng được tái sử dụng trong các ứng dụng nối tiếp z Tái sử dụng của người tiêu thụ:tái sử dụng các thành phần mà ban đầu chúng được phát triển cho các dự án khác Nguyên tắc chung z Một số lưu ý khi lập trình z Bắt ngoại lệ z Quên cấp phát và thu hồi bộ nhớ z Vấn đề làm tròn số z Hạn chế gọi nhiều lần các hàm có qui mô nhỏ z Truyền tham số z Tránh dùng mảng nhiều chiều z Sử dụng các phép toán nhanh 18
Tài liệu chương trình z Tài liệu chương trình: một tập các mô tả giải thích với người đọc về các chương trình làm gì và chúng làm như thế nào z Các loại tài liệu chương trình z Tài liệu nội là mô tả được viết trực tiếp trong mã lệnh và được sử dụng bởi những người đọc mã lệnh z Tài liệu ngoại gồm những tài liệu khác và được sử dụng bởi những người không trực tiếp đọc mã lệnh Tài liệu chương trình z Tài liệu nội z Khối chú thích ở phần đầu của từng thành phần: ai, cái gì, tại sao, khi nào, như thế nào và ở đâu z Các chú thích khác giúp ta hiểu chương trình rõ hơn: thêm thông tin mới, không phải diễn đạt lại những gì đã rõ ràng z Nhãn cho câu lệnh và tên biến phải có nghĩa z Định dạng để gia tăng sự hiểu biết: thụt lề, khoảng trắng
Tài liệu chương trình z Tài liệu ngoại z Mô tả vấn đề: mô tả các lựa chọn được xem xét để giải quyết vấn đề và tại sao một giải pháp cụ thể được chọn z Mô tả giải thuật: giải thích từng giải thuật được sử dụng trong thành phần (công thức, ranh giới, các điều kiện đặc biệt, bắt lỗi, v.v) z Mô tả dữ liệu: từ điển dữ liệu
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM CHƯƠNG 8 – KIỂM THỬ 1 Nộidung z Phần 1 – Kiểm thử chương trình z Phần 2 – Kiểm thử hệ thống z Phần 3 – Ước lượng số lỗi và thời gian kiểm thử 2
Phần 1 - Nội dung z Các lỗi phần mềm z Các vấn đề trong kiểm thử z Kiểm thử đơn vị z Kiểm thử tích hợp z Lập kế hoạch kiểm thử z Các công cụ kiểm thử tự động 3 Lỗi phần mềm z Các nguyên nhân làm phần mềm thất bại z Đặc tả sai z Đặc tả thiếu z Yêu cầu không thể thực thi z Thiết kế không chính xác z Mã lệnh có thiếu sót 4
Lỗi phần mềm z Mục đích của kiểm thử: phát hiện ra các lỗi z Một kiểm thử là thành công chỉ khi lỗi được phát hiện z Nhận dạng lỗi là quá trình xác định lỗi nào đã gây ra sự thất bại z Hiệu chỉnh lỗi là quá trình tạo ra các thay đổi đối với hệ thống nhằm loại bỏ các lỗi 5 Lỗi phần mềm z Các loại lỗi z Lỗi giải thuật: các lỗi giải thuật điển hình z Lỗi giải thuật xuất hiện khi logic hay giải thuật của thành phần không tạo ra kết xuất đúng cho kết nhập xác định Rẽ nhánh quá sớm Rẽ nhánh quá trễ Kiểm thử cho điều kiện sai Quên khởi tạo giá trị ban đầu của biến hay đặt vòng lặp bất biến Quên kiểm thử cho điều kiện đặc biệt So sánh giá trị của các kiểu dữ liệu không phù hợp z Lỗi cú pháp 6
Lỗi phần mềm z Các loại lỗi z Lỗi về độ chính xác và tính toán z Sự thực hiện của một công thức là sai hoặc không tính ra kết quả với độ chính xác mong muốn z Lỗi tài liệu z Tài liệu không phù hợp với cái mà chương trình làm z Lỗi về quá tải hay dung lượng z Sự thực hiện của hệ thống là không thể chấp nhận khi đạt đến các ranh giới nào đó 7 Lỗi phần mềm z Các loại lỗi z Lỗi hợp tác và thời gian z Lỗi thực hiện z Hệ thống không thực hiện với tốc độ được mô tả z Lỗi quy trình và chuẩn z Lỗi phần cứng, phần mềm 8
Bài tập – Câu 1 z Cho đoạn chương trình sau int n; float x[1000]; x[i] = (1 - 2/(n-1)) * x[i - 1] + 2/(n-1) * x[i]; Đoạn chương trình này: a. Lỗi đường biên b. Lỗi thiếu khởi tạo c. Lỗi về tính toán / chính xác d. Lỗi b và c e. Lỗi a và b f. Không có lựa chọn nào đúng 9 Bài tập – Câu 2 List::~List(){ /* Xóa tất cả các phần tử trong danh sách */ for (int i=1; i < count; i++) delete list[i]; } Đoạn chương trình này: a. Lỗi thiếu khởi tạo b. Lỗi tài liệu c. Lỗi về tính chính xác d. Lỗi b và c e. Lỗi a và b f. Không có lựa chọn nào đúng 10
Bài tập – Câu 3 int list[10]; for (int i=0; i<=10; i++) list[i] = i; Đoạn chương trình này: a. Lỗi thiếu khởi tạo b. Lỗi về tính chính xác c. Lỗi về dung lượng / quá tải d. Lỗi a, b và c e. Không có lựa chọn nào đúng 11 Các vấn đề trong kiểm thử z Tổ chức kiểm thử z Kiểm thử đơn vị z Kiểm thử tích hợp z Kiểm thử chức năng z Kiểm thử sự thực hiện z Kiểm thử chấp nhận z Kiểm thử cài đặt 12
Các vấn đề trong kiểm thử z Các bước kiểm thử 13 Các vấn đề trong kiểm thử z Quan điểm kiểm thử z Lập trình bản ngã: các chương trình được xem như những thành phần của một hệ thống lớn hơn, không như tài sản của những người đã viết ra chúng 14
Các vấn đề trong kiểm thử z Người kiểm thử: nhóm kiểm thử độc lập z Tránh sự mâu thuẫn z Tăng tính khách quan z Cho phép kiểm thử và lập trình đồng thời 15 Các vấn đề trong kiểm thử z Tổng quan về các phương pháp kiểm thử z Kiểm thử hộp đóng hay hộp đen sử dụng chức năng của đối tượng kiểm thử để kiểm thử theo nhiều cách z Kiểm thử hộp mở hay hộp trắng sử dụng cấu trúc của đối tượng kiểm thử để kiểm thử theo nhiều cách 16
Các vấn đề trong kiểm thử z Kiểm thử hộp đen z Đặc điểm z Đối tượng kiểm thử như một hộp đen, thông qua giao diện để đưa dữ liệu vào và nhận dữ liệu ra Input Results Black Box z Độc lập với các ràng buộc bị tác động bởi cấu trúc bên trong và tính logic của đối tượng 17 Các vấn đề trong kiểm thử z Kiểm thử hộp trắng z Phương pháp thiết kế trường hợp kiểm thử sử dụng cấu trúc điều khiển của thiết kế thuật toán để dẫn ra các trường hợp kiểm thử Input hh Results hh 18
Các vấn đề trong kiểm thử z Các yếu tốảnh hưởng đến việc chọn phương pháp kiểm thử: z Số đường dẫn logic có thể có z Trạng thái của dữ liệu input z Số lượng tính toán có liên quan z Độ phức tạp của giải thuật 19 Kiểm thử đơn vị z Kiểm thử đơn vị: kiểm thử từng thành phần hay từng mô đun của phần mềm. z Các bước kiểm thử đơn vị z Xem lại mã lệnh z Biên dịch mã lệnh và loại bỏ bất cứ lỗi cú pháp nào còn lại z Phát triển các trường hợp kiểm thử để chỉ ra rằng input được chuyển đổi chính xác thành ouput mong đợi 20
Kiểm thử đơn vị z Xem lại (kiểm tra) mã lệnh z Đi qua mã lệnh (Code walkthrough) z Xem xét kỹ mã lệnh (Code inspection) 21 Kiểm thử đơn vị z Các bước chọn trường hợp kiểm thử z Xác định các mục tiêu kiểm thử z Lựa chọn các trường hợp kiểm thử z Định nghĩa một kiểm thử
Kiểm thử đơn vị z Tính toàn diện của kiểm thử z Kiểm thử câu lệnh z Kiểm thử rẽ nhánh z Kiểm thử đường đi z Kiểm thử sử dụng sự định nghĩa z Kiểm thử tất cả sử dụng z Kiểm thử sử dụng tất cả vị từ / kiểm thử sử dụng một số tính toán z Kiểm thử sử dụng một số vị từ / kiểm thử sử dụng tất cả tính toán 23 Kiểm thử đơn vị -Kiểm thử đường đi z KiÓm thö ®−êng ®i: KiÓm thö tÊt c¶ c¸c h−íng ®i cã thÓ z Thieát laäp ñoà thò doøng chaûy z Lieät keâ caùc ñöôøng thöïc thi ñoäc laäp cô baûn z Sinh caùc tröôøng hôïp kieåm thöû cho caùc ñöôøng thöïc thi ñoù 24